2009年06月26日

ThinkPadのトラックポインタでWPFのスクロールができない

ThinkPadのトラックポインタでWPFのスクロールができないって問い合わせた件の結果がやっと返ってきた。

以下がメールの抜粋。
抜粋の仕方は微妙だけど、文意には問題ないと思う。

WPF ウィンドウのスクロール
機能のサポートが加わった最新版UltraNav ドライバーが発表されましたので
ご報告致します。

「UltraNav ドライバー (Windows Vista 32 ビット/2000/XP)」
http://www.ibm.com/jp/domino05/pc/download/download.nsf/jtechinfo/MIGR-42487

バージョン: Ver. 12.2.3.1
リリース日: 2009/06/26

入れてみた。再起動してみた。

動かなかった(ρ_;)
posted by そら at 16:18| 日記

2009年06月21日

mixi Javaコミュニティ:デザインパターン再入門勉強会

mixi Javaコミュニティ:デザインパターン再入門勉強会に行ってきた。
もう、昨日の話だけど。

自分にとって、初めてのネットで知った勉強会への参加だ。
というか、外部研修?みたいなものすら初めてな気がする。

自分なりに気になったポイントをまとめておく。
自分流解釈なので間違ってても趣旨と違っても知りません。



「オブジェクト指向における再利用のためのデザインパターン」
と言う本を持っている人が多かった。

雰囲気としては、コレを読まないとダメでしょ〜って感じだった。
えぇ、わたしは読んでませんよっと。
わたしは、結城さんの本を読んだ系(?)だけど、
「やっぱ結城さんの本だけじゃなくて、コレを読まないとダメでしょ〜。」
って感じだった。そう思ってないひともいたみたいだけど。

結局、デザインパターンって「ソフトウェアに関するよく使う構造につけられた名称」で、
共通認識としてコミュニケーションをとるための道具ってことらしい。

その為の辞書という意味では、どの本でも良いと想う。

上に書いた本が紹介されて、ふと気になったことが、「再利用」だ。
本読んでないからわからないのか知らないけど、何が「再利用」なんだ、と。

他の人と話して感じたというかダイレクトに言われた(?)のは、
出来たものを再利用するって言うことだけじゃないんじゃないか、と。
パターンってひな形であり、何度も当てはめるんだから、ソレが再利用ってことじゃないの?
と言うことらしい。

たしかに、改めてデザインパターンは知識体系の一種なんだなと認識した。
知識体系は言い過ぎか。



まぁ、デザインパターンは、過去の経験をまとめたものだ。
PMBOKとかの知識体系って呼ばれるものも、確かそうだったと想う。たぶん。
これらって、実際に導き出した人とか、実践中に知識として追加した人は問題ない人もいるかもしれないが、
これから学ぶってひとは、絶対に実践しなければ身にならない。
実践して失敗とかして調整して初めて身につくものだ。

この辺は、だいたいみんな感じてるみたい。
セッション3をやっていたひろさんとか、その辺一生懸命話してたけど、
自分の経験とあわせてもまさにその通りって感じだった。

間違って覚える方法の回避とかいろいろでてたけど、
要は、「実践しろ」ってことだと想う。
コレは別に仕事に限らず、個人的な開発?みたいなものでも良い。
個人で学んだりしてる人が強いのはここなのかなぁ。



デザインパターンって今時代必要なのか?
って言う話も今回の勉強会のテーマの一つだったようだ。
この発想はなかった。

特にGoFの23個について不要なのはないかとか簡単に検討してみたけど、
自分の中の結論としては不要なデザインパターンはない。
だって、最初に書いたように、一種の辞書的内容だから、
不要になるのはもっと先の話だと想う。

ただし、条件によって不要って言うのはあると想った。

デザインパターンは、クラス構造を疎結合にしていく考え方だと想ってる。
必要な結合を最小限にしたり局所的にする。
コレにより、「そのクラス」を作る側は、メンテナンスしやすくなる。
「そのクラス」を使う側は、利用しやすくなる……のかは正直わたしにはよくわからない。
たぶん、使う側は全く意識してないだろう。

今、アプリケーションを一人で作り上げることはまず無い。
Javaには標準ライブラリがあるし、他のフレームワーク、ライブラリ、いくらでもある。
現在主流と思われるWeb系の開発者の多くは、それらを利用して、ユーザーに「作ったアプリを使ってもらう」。
この中では、デザインパターンを使う側となることが多く、メリットを享受する機会は少なめだと思う。

何と比較してって、フレームワークとかライブラリを作る側だ。
それらの直接のユーザーは開発者で、「作ったライブラリ等を使ってアプリを作ってもらう」。

なんか直接的な理由になってないな。

アプリには、処理の流れを構成する部分と、処理の具体的な内容を書く部分があると思う。
フレームワーク、ライブラリは前者の部分で、ある程度パターン化出来る範囲を含んでいると想う。
後者の部分は、そのアプリとかに特有の部分を指す。具体的にドコって言うと難しいけど。

その区分けをきっちり分けるのは難しい。
ただ、本当に後者の特有部分だけ書いてあるのであれば、パターンなんか無いってことだし、明らかに不要に想う。
こういうところの人たちには、きっとデザインパターンは不要だろう。
でも、現実の開発では、きっちり分けられてないので、やっぱり前者の部分もやる必要がある。
技術者のスキルとしてレベルが分かれるところの一つになるかもしれない。
まぁ、その範囲が少しずつ明確になっていって、最終的に完全分離されるのかもしれないが。

どちらにしろ、デザインパターンは、知識として持つことに意味があると思うが、
それ以上に、実際に使える(使う)ことが重要なことは強調しておきたい。
posted by そら at 22:19| Comment(0) | TrackBack(0) | 日記

不定期になんとなく

気づいたこととかまとめていけたらいいかなと思う。
続かない気もするけど、まずは始めてみよう……。
posted by そら at 21:22| Comment(0) | TrackBack(0) | 日記