Webで検索すると、ctrl - ] と ctrl - t は紹介されていますが、:ts はあまり出てないですね。
ctrl - ] では、とにかく同名の関数に飛んでくれますが、Javaでオーバー（ロード｜ライド）しまくっていると目的の場所に届かないことがままあります。そんなときに :ts です。
:ts とすると関数の候補が出ます。行きたい関数の数字を打てばOK。
eclipse だと結構探してくれますが、ctags では自分で候補を探す必要があります。（eclipseも完ぺきではないので、候補を自分で探す方が結果的に早いということもあります）
以上
2008年8月6日水曜日
はじめに（プロジェクトの人間学）
※ この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。
はじめに
システム構築プロジェクトに関係するステークホルダーには３つある。
ひとつは顧客である。プロジェクトの品質を要求し、正しいプロジェクト運営を求める。
もうひとつはマネジメントである。技術的なことはほとんど分からないのだが（それゆえにこそ顧客とマネジメントが対等なのであるが）プロジェクトを管理しようとする。
もうひとつは現場である。「マネジメントではない」存在として定義されたメンバーで構成されている。
前者二つは「こうであるべきだ！」「こうでないのはおかしい！」と声高に叫ぶ。そして管理という名の雑用を増やし、プロジェクトの混乱を促進する。現場はコンピュータが産む理不尽なトラブルと、マネジメントならびに顧客からの要求に耐え、絶望的に、だが粛々と作業を進める。「だったらお前がやってみろ」という呪いの言葉を飲み込んで。
筆者は現場の人間である。現場の視点からいくつかプロジェクトに関する本を読み、ほとんどすべてに対して「ウソだろ？」と顔をしかめてきた。デマルコなど一部を除いて。世のプロジェクト本は、それぞれの著者の脳内プロジェクトシミュレーションを扱っているに過ぎなかった。生きたプロジェクトを扱っている本はどこにもないように思えた。
現実のプロジェクトを対象にしたものでも、やたらと数値化を利用してプロジェクトを分析いる。だが大抵の場合は脳内のプロジェクトモデルにデータを寄り添わせるために数値を利用したに過ぎなかった。その計測方法も欲しいデータを得るために恣意的な切り口で計測したものが多かったように思う。つまりは自らのプロジェクト観を補強するために数字をもてあそんでいるに過ぎない。
あるいは中には無用にプロジェクトの悲惨さを訴えるものがある。悲惨さをユーモアとするにしても、戯画化されすぎていて、中途半端である。別の本では著者の方法論があまりに完璧なので、注意して管理すればプロジェクトの失敗などありえない、と述べる。また別の本では訳の分からないプロジェクト進捗（リスク）定量化ソフトウェアを使え、と言ってくる。どれもこれも全く生のプロジェクトを扱っていない。
筆者は現場で働きながらプロジェクトを扱った本を読み「プロジェクトを一度現場の視点で定義しなおす必要があるんじゃないの」とぶつぶつと考えてきた。考えた結果がこの本である。中にはマネジメント層や顧客層からは容認しがたい記述があるに違いない。しかし、これは偽らざる現場感覚である。ソフトウェア工学でプロジェクトを計測し、評価した結果が真実であると主張するのと、同じ権利を持って真実と主張できると筆者は自負している。
マネジメント層や顧客に訴える書籍が多いのはある意味で当然である。何故なら彼らには金があるから。彼らに気に入る理論でなければお金儲けは難しいに違いない。教授たちやコンサルタントがプロジェクトをサンプリングし、数値化、分析する。そして「プロジェクトはこうあるべきなんです」とマネジメントや顧客に訴える。それもよかろう。しかし、筆者は現場の人間である。敢えて現場から見たプロジェクトの真実を書きたい。
この著作がほんの少しでも現場エンジニアの喝采を浴びることができたら、筆者にとってはこれほどうれしいことはない。
では早速だが、まずプロジェクトを二元論的な観点から見てゆこう。
はじめに
システム構築プロジェクトに関係するステークホルダーには３つある。
ひとつは顧客である。プロジェクトの品質を要求し、正しいプロジェクト運営を求める。
もうひとつはマネジメントである。技術的なことはほとんど分からないのだが（それゆえにこそ顧客とマネジメントが対等なのであるが）プロジェクトを管理しようとする。
もうひとつは現場である。「マネジメントではない」存在として定義されたメンバーで構成されている。
前者二つは「こうであるべきだ！」「こうでないのはおかしい！」と声高に叫ぶ。そして管理という名の雑用を増やし、プロジェクトの混乱を促進する。現場はコンピュータが産む理不尽なトラブルと、マネジメントならびに顧客からの要求に耐え、絶望的に、だが粛々と作業を進める。「だったらお前がやってみろ」という呪いの言葉を飲み込んで。
筆者は現場の人間である。現場の視点からいくつかプロジェクトに関する本を読み、ほとんどすべてに対して「ウソだろ？」と顔をしかめてきた。デマルコなど一部を除いて。世のプロジェクト本は、それぞれの著者の脳内プロジェクトシミュレーションを扱っているに過ぎなかった。生きたプロジェクトを扱っている本はどこにもないように思えた。
現実のプロジェクトを対象にしたものでも、やたらと数値化を利用してプロジェクトを分析いる。だが大抵の場合は脳内のプロジェクトモデルにデータを寄り添わせるために数値を利用したに過ぎなかった。その計測方法も欲しいデータを得るために恣意的な切り口で計測したものが多かったように思う。つまりは自らのプロジェクト観を補強するために数字をもてあそんでいるに過ぎない。
あるいは中には無用にプロジェクトの悲惨さを訴えるものがある。悲惨さをユーモアとするにしても、戯画化されすぎていて、中途半端である。別の本では著者の方法論があまりに完璧なので、注意して管理すればプロジェクトの失敗などありえない、と述べる。また別の本では訳の分からないプロジェクト進捗（リスク）定量化ソフトウェアを使え、と言ってくる。どれもこれも全く生のプロジェクトを扱っていない。
筆者は現場で働きながらプロジェクトを扱った本を読み「プロジェクトを一度現場の視点で定義しなおす必要があるんじゃないの」とぶつぶつと考えてきた。考えた結果がこの本である。中にはマネジメント層や顧客層からは容認しがたい記述があるに違いない。しかし、これは偽らざる現場感覚である。ソフトウェア工学でプロジェクトを計測し、評価した結果が真実であると主張するのと、同じ権利を持って真実と主張できると筆者は自負している。
マネジメント層や顧客に訴える書籍が多いのはある意味で当然である。何故なら彼らには金があるから。彼らに気に入る理論でなければお金儲けは難しいに違いない。教授たちやコンサルタントがプロジェクトをサンプリングし、数値化、分析する。そして「プロジェクトはこうあるべきなんです」とマネジメントや顧客に訴える。それもよかろう。しかし、筆者は現場の人間である。敢えて現場から見たプロジェクトの真実を書きたい。
この著作がほんの少しでも現場エンジニアの喝采を浴びることができたら、筆者にとってはこれほどうれしいことはない。
では早速だが、まずプロジェクトを二元論的な観点から見てゆこう。
崖の上のポニョ（宮崎駿インタビュー）
昨夜ＮＨＫの番組で宮崎駿インタビューを見ました。
宮崎監督がイメージボードだか絵コンテを書きながら「子供たちにこの映画を通して生きていてもいいんだ、ということを伝えたいんだ」（正確ではない）とブツブツ言っていたシーンが凄みがありました。
言葉にしてしまうとありきたりですが、彼のつぶやきには彼の人生や、トラウマがしっかりと刻み込まれていました。それがこの言葉にただならぬ重さを与えていた気がします。
他には「僕は映画の奴隷だよ」という言葉も印象に残りました。
仕事や会社の奴隷なら普通にいますが、そうではありません。映画が「もっとできる。もっと凄いものが作れる」と彼を駆り立てるのでしょう。
夏目漱石の夢十夜だったか、木から仏像を作るのではない。仏が木に埋まっているのを掘り出すんだ、という話があったかと思います。
その人が頭で作るのではなく、その人にしか見えない何かがあって、その何かが人を動かすのです。芸術には芸術家を超えた何かがあるということなのでしょう。
しかし、宮崎監督の話は面白いですね。ポニョを見るのが楽しみです。
宮崎監督がイメージボードだか絵コンテを書きながら「子供たちにこの映画を通して生きていてもいいんだ、ということを伝えたいんだ」（正確ではない）とブツブツ言っていたシーンが凄みがありました。
言葉にしてしまうとありきたりですが、彼のつぶやきには彼の人生や、トラウマがしっかりと刻み込まれていました。それがこの言葉にただならぬ重さを与えていた気がします。
他には「僕は映画の奴隷だよ」という言葉も印象に残りました。
仕事や会社の奴隷なら普通にいますが、そうではありません。映画が「もっとできる。もっと凄いものが作れる」と彼を駆り立てるのでしょう。
夏目漱石の夢十夜だったか、木から仏像を作るのではない。仏が木に埋まっているのを掘り出すんだ、という話があったかと思います。
その人が頭で作るのではなく、その人にしか見えない何かがあって、その何かが人を動かすのです。芸術には芸術家を超えた何かがあるということなのでしょう。
しかし、宮崎監督の話は面白いですね。ポニョを見るのが楽しみです。
2008年8月4日月曜日
JavaMail は5年遅れている
このブログにしてはなかなかキャッチーなタイトルです。
JavaMailは現在バージョン1.4。1.1のリリースから10年近く経ちますが、本質的な機能は変わっていません。
つまり（かなりアクロバティックな展開ですが）JavaMailの本質は10年ほど変化していないのです。
言い換えると、
１．JavaMail 1.1 のリリースが10年近く前
２．JavaMail 1.4 と 1.1 の機能は本質的には変わっていない
３．ゆえに JavaMail 1.4 の機能は本質的には10年ほど変わっていない
すばらしく乱暴な展開ですが、私は結構確信を持ってこれを書いています。
なぜ確信を持っているか。
それは、JavaMailが依然としてクラサバ型のメールクライアントを意識した仕様だからです。
なぜそう思うか。
Folderがメッセージをキャッシュすべきである、とか、そもそも「フォルダー」という概念がクラサバチックなのです。
Swingで作るメールクライアントならFolderがメールをキャッシュするのもよいでしょう。しかしServletではどうするか。Folderがメールをキャッシュしたところで、じゃあそのFolderをどこにキャッシュするのか。FolderはSerializableではない（javax.mail.Messageすらも！）のでSessionにPUTすることはできません（してもいいけど仕様に反する）。じゃあServletContext？？それは何だかみっともないなあ。
それからgmailやdel.icio.usで採用されているような（「フォルダ」という概念ではなく）「タグ」という概念が、JavaMailでは実装不可能であること。つまり「フォルダ」という概念をそのまま「javax.mail.Folder」に落としてしまったという痛恨のミス。これらがJavaMailが5年以上前のレベルにとどまっている証拠だと私は思うのです。
3層Webアーキテクチャ（というのも古い言葉なのかな）でメールシステムを作るとすれば、JavaMailの仕様は結構無視してしまうしかない、と私は確信するものであります。
かなりマニアックな話題を中途半端に終わらせるのもなんですが、以上です。
JavaMailは現在バージョン1.4。1.1のリリースから10年近く経ちますが、本質的な機能は変わっていません。
つまり（かなりアクロバティックな展開ですが）JavaMailの本質は10年ほど変化していないのです。
言い換えると、
１．JavaMail 1.1 のリリースが10年近く前
２．JavaMail 1.4 と 1.1 の機能は本質的には変わっていない
３．ゆえに JavaMail 1.4 の機能は本質的には10年ほど変わっていない
すばらしく乱暴な展開ですが、私は結構確信を持ってこれを書いています。
なぜ確信を持っているか。
それは、JavaMailが依然としてクラサバ型のメールクライアントを意識した仕様だからです。
なぜそう思うか。
Folderがメッセージをキャッシュすべきである、とか、そもそも「フォルダー」という概念がクラサバチックなのです。
Swingで作るメールクライアントならFolderがメールをキャッシュするのもよいでしょう。しかしServletではどうするか。Folderがメールをキャッシュしたところで、じゃあそのFolderをどこにキャッシュするのか。FolderはSerializableではない（javax.mail.Messageすらも！）のでSessionにPUTすることはできません（してもいいけど仕様に反する）。じゃあServletContext？？それは何だかみっともないなあ。
それからgmailやdel.icio.usで採用されているような（「フォルダ」という概念ではなく）「タグ」という概念が、JavaMailでは実装不可能であること。つまり「フォルダ」という概念をそのまま「javax.mail.Folder」に落としてしまったという痛恨のミス。これらがJavaMailが5年以上前のレベルにとどまっている証拠だと私は思うのです。
3層Webアーキテクチャ（というのも古い言葉なのかな）でメールシステムを作るとすれば、JavaMailの仕様は結構無視してしまうしかない、と私は確信するものであります。
かなりマニアックな話題を中途半端に終わらせるのもなんですが、以上です。
GPL・・・
GPLというソフトウェアのライセンスがあります。
このページを見るような方であれば名前くらいはご存知かと思います。私も厳密には理解していないと思うのですが、大体以下のような特徴を持つライセンスです。
（１）著作権は書いた人にある
（２）GPLのソースコードは変更が自由である
（３）GPLは継承されなければならない
（４）GPLのライセンスを含むソースコード・ライブラリを含むアプリケーションのソースコードは無償で公開されなければならない
この（４）の制限が強烈です。
GPLとは言わば「ソースコード公開原理主義」です。GPLはソフトウェアの対価として金銭を受け取ることを認めてはいるものの、商用ソフトウェアでは事実上GPLのライブラリやソースを利用できないことになります。
結構厄介なもので、ちょっと気の効いた、自分では作るのがちょっと難しいようなライブラリがGPLだと、困ったことになります。GPLを含めるわけにはいかないので、既に優れた実装が存在するものをわざわざ0から自分で作る羽目になるのです。これはかなりの「しょうがねーなー」感があります。
LGPLやMITライセンスやApacheライセンスなど、もう少し利用しやすいライセンスが流行るのが当たり前だと思います。
学生の頃は「GPLいいじゃん」などと思っていたのですが、最近では「GPL困ったもんだね」派に傾いています。何につけても原理主義というのはよろしくないと思います。
このページを見るような方であれば名前くらいはご存知かと思います。私も厳密には理解していないと思うのですが、大体以下のような特徴を持つライセンスです。
（１）著作権は書いた人にある
（２）GPLのソースコードは変更が自由である
（３）GPLは継承されなければならない
（４）GPLのライセンスを含むソースコード・ライブラリを含むアプリケーションのソースコードは無償で公開されなければならない
この（４）の制限が強烈です。
GPLとは言わば「ソースコード公開原理主義」です。GPLはソフトウェアの対価として金銭を受け取ることを認めてはいるものの、商用ソフトウェアでは事実上GPLのライブラリやソースを利用できないことになります。
結構厄介なもので、ちょっと気の効いた、自分では作るのがちょっと難しいようなライブラリがGPLだと、困ったことになります。GPLを含めるわけにはいかないので、既に優れた実装が存在するものをわざわざ0から自分で作る羽目になるのです。これはかなりの「しょうがねーなー」感があります。
LGPLやMITライセンスやApacheライセンスなど、もう少し利用しやすいライセンスが流行るのが当たり前だと思います。
学生の頃は「GPLいいじゃん」などと思っていたのですが、最近では「GPL困ったもんだね」派に傾いています。何につけても原理主義というのはよろしくないと思います。
2008年7月28日月曜日
Ajaxなるもの
今回もゴミ投稿です。
地味に忙しい毎日です。
残念ながら世の悪いニュースも目立ちますし、楽しい話題というものが見当たりません。
最近JavaScriptでいろいろ試しているのですが、Ajaxは本当に大変ですね。
JavaScriptであれだけモノを作れるGoogleという企業のスゴさが分かります。
誰かエクセレントなJavaScriptフレームワークを作ってくれないかしら・・・（おまえが作れって？ムリムリ）
地味に忙しい毎日です。
残念ながら世の悪いニュースも目立ちますし、楽しい話題というものが見当たりません。
最近JavaScriptでいろいろ試しているのですが、Ajaxは本当に大変ですね。
JavaScriptであれだけモノを作れるGoogleという企業のスゴさが分かります。
誰かエクセレントなJavaScriptフレームワークを作ってくれないかしら・・・（おまえが作れって？ムリムリ）
2008年7月7日月曜日
トム・デマルコ 「デッドライン」
もう半年以上前に「デッドライン―ソフト開発を成功に導く101の法則」（日経BP社）を楽しく読んだのですが最近になってこの本に対する私なりの意見がまとまって来たので書評です。（遅いよ）
【この本のポイント】
プロジェクトで重要なのは人であり、コミュニケーションである。
重要な仕事（設計）に、集中してもらうこと。これがプロジェクト成功の秘訣。プレッシャーや残業は無意味！
プロジェクトでもっとも大きいコストは手戻り作業。故に当初の要求定義／設計作業に多くの時間リソースをつぎ込むべき。そうすればコーディング以降一気呵成に出来上がる。
【感想】
著者の人重視の姿勢には好感が持てます。本当にそうだと思う。
プロジェクトの運営論については設計フェーズをあまりに重視しすぎ。
・柔軟に対応できる設計と取り返しのつかない設計があると思う
⇒ 手戻り覚悟で進めた方が結果的に早い／コストが安い場合があります。設計が完全に固まるまでコードを書かないのではなく、覚悟してコードに着手してしまった方がよい場合もある。（もちろんセンスと経験が必要な賭けではありますが・・・）
・技術的な実現可能性（フィージビリティ）を机上で検証するより、作って見たほうが早い。その結果手戻りが発生してもそれはしょうがない、という割り切りも必要。
私の経験では、旧来のウォーターフォール型を緩やかに運営するのがベストと思います（凡庸な意見だけどね）。スパイラル型の開発はやはり手戻りが痛い（※）・・・小規模なプロジェクトで優秀なコーダーが揃っている場合はスパイラル型が有効かもしれませんが、ちょっと画餅っぽい気がします。
（※）手戻りに強いのがスパイラル型ではないのか、と疑問に思われるかもしれません。確かにJunitで再帰テスト可能なレベルのちょっとした変更ならば問題ありませんが、設計変更レベルの手戻りはやはり厳しいものがあります。
以上。
【この本のポイント】
プロジェクトで重要なのは人であり、コミュニケーションである。
重要な仕事（設計）に、集中してもらうこと。これがプロジェクト成功の秘訣。プレッシャーや残業は無意味！
プロジェクトでもっとも大きいコストは手戻り作業。故に当初の要求定義／設計作業に多くの時間リソースをつぎ込むべき。そうすればコーディング以降一気呵成に出来上がる。
【感想】
著者の人重視の姿勢には好感が持てます。本当にそうだと思う。
プロジェクトの運営論については設計フェーズをあまりに重視しすぎ。
・柔軟に対応できる設計と取り返しのつかない設計があると思う
⇒ 手戻り覚悟で進めた方が結果的に早い／コストが安い場合があります。設計が完全に固まるまでコードを書かないのではなく、覚悟してコードに着手してしまった方がよい場合もある。（もちろんセンスと経験が必要な賭けではありますが・・・）
・技術的な実現可能性（フィージビリティ）を机上で検証するより、作って見たほうが早い。その結果手戻りが発生してもそれはしょうがない、という割り切りも必要。
私の経験では、旧来のウォーターフォール型を緩やかに運営するのがベストと思います（凡庸な意見だけどね）。スパイラル型の開発はやはり手戻りが痛い（※）・・・小規模なプロジェクトで優秀なコーダーが揃っている場合はスパイラル型が有効かもしれませんが、ちょっと画餅っぽい気がします。
（※）手戻りに強いのがスパイラル型ではないのか、と疑問に思われるかもしれません。確かにJunitで再帰テスト可能なレベルのちょっとした変更ならば問題ありませんが、設計変更レベルの手戻りはやはり厳しいものがあります。
以上。
2008年7月1日火曜日
JavaScriptメモ
JavaScriptは厄介ですね。
Ajaxと呼ばれるモノを最初にコーディングした人は天才に違いない。
以下、個人的な私のしょうもないチョンボメモ。普通の人には常識に違いない。
■ フォームのエレメント名に"."が含まれる場合、以下の記述では動きません。FireFoxでは完全にダンマリ状態になります。
フォーム名:MY_FORM_NAME
エレメント名（テキストボックスなど）:INCLUDE.DOT.ELEM
駄目な例
正しくは
■ RADIO入力項目の値を取る時は添え字[i]を忘れないように！さもなければundefinedが返ります。
■ 親画面のJavaScriptを呼ぶ方法
Ajaxと呼ばれるモノを最初にコーディングした人は天才に違いない。
以下、個人的な私のしょうもないチョンボメモ。普通の人には常識に違いない。
■ フォームのエレメント名に"."が含まれる場合、以下の記述では動きません。FireFoxでは完全にダンマリ状態になります。
フォーム名:MY_FORM_NAME
エレメント名（テキストボックスなど）:INCLUDE.DOT.ELEM
駄目な例
document.MY_FORM_NAME.INCLUDE.DOT.ELEM.value = arg;
正しくは
document.MY_FORM_NAME.elements["INCLUDE.DOT.ELEM"].value = arg;
■ RADIO入力項目の値を取る時は添え字[i]を忘れないように！さもなければundefinedが返ります。
var hoge = RADIO_ELEM.value;
alert(hoge); // ← "undefined"
hoge = RADIO_ELEM[i].value;
alert(hoge); // ← "期待通りの値が戻る"
■ 親画面のJavaScriptを呼ぶ方法
window.opener.myFunction(arg);
2008年6月30日月曜日
Eclipseカスタマイズ
ほとんど個人的メモです。
Eclipseの新規作成メニューや右クリック"New"のコンテキストメニューが気に入らないときは、Window → Customize perspectiveで追加／削除ができます。
以上。
Eclipseの新規作成メニューや右クリック"New"のコンテキストメニューが気に入らないときは、Window → Customize perspectiveで追加／削除ができます。
以上。
2008年6月24日火曜日
大阪橋本知事の改革で気になること
「民間はもっと苦労している。公務員の方も理解して欲しい」というのがasahi.comで橋本改革関連のニュースでよく取り上げられている決めゼリフです。ネットを巡回していても（私の巡回範囲なぞ狭いものですが）この言葉を支持する書込みが多々見られます。
もう少しこのスローガンを補足すると「大阪は民間で言えば債務超過の大赤字であり、ほとんど倒産状態である。民間であれば潰れて皆が路頭に迷っていてもおかしくはない。公務員だからといって安穏とせず、リストラに協力して欲しい」といったところでしょうか。
大阪の公務員の方からすれば受け入れがたいロジックだと思います。民間民間ってこっちは公務員なんだから知らないよ。民間の人が苦労しているからって、それは民間企業を選んだその人の責任でしょうが。
一方で一部のWeb上での大阪公務員バッシングは激しいものがあります。「子供がいるから給料が貰えないと困るとはなんだ。民間でそんな理由が通用するか。こっちは金も時間もなくて子供すら作れないんだ」。公務員は甘い。民間じゃ考えられない。俺たちは大変な思いをしているのに。
それぞれの立場にはこれ以上は立ち入りませんが、私が気になるのはWeb上の公務員バッシングにどうしようもないルサンチマン（怨恨）が感じられることです。
そのルサンチマンが「民間は苦しいのに公務員が楽してはいかん」という単純な図式を強烈に支持しているように見えてしまう。
薄給でハードワークをこなしながら、会社が潰れやしないか、リストラされやしないか、と不安を抱えるサラリーマンや派遣社員の人が公務員を叩いている。この状況が悲しく見えてしまうのは私だけでしょうか。
民間は民間でそれなりの、公務員は公務員でそれなりの人生が送れる社会が、本来あるべき社会ではないでしょうか。今の社会がおかしいからルサンチマンを持たざるを得ない人が増えているのではないでしょうか。
何かによって搾取されている若い世代の人たちも、橋本改革の図式に表面的に感情移入するのではなくて、その裏にある本当の問題（それが何かは私にもはっきりとは分かりませんが）を考えてみてもよいのではないでしょうか。
もう少しこのスローガンを補足すると「大阪は民間で言えば債務超過の大赤字であり、ほとんど倒産状態である。民間であれば潰れて皆が路頭に迷っていてもおかしくはない。公務員だからといって安穏とせず、リストラに協力して欲しい」といったところでしょうか。
大阪の公務員の方からすれば受け入れがたいロジックだと思います。民間民間ってこっちは公務員なんだから知らないよ。民間の人が苦労しているからって、それは民間企業を選んだその人の責任でしょうが。
一方で一部のWeb上での大阪公務員バッシングは激しいものがあります。「子供がいるから給料が貰えないと困るとはなんだ。民間でそんな理由が通用するか。こっちは金も時間もなくて子供すら作れないんだ」。公務員は甘い。民間じゃ考えられない。俺たちは大変な思いをしているのに。
それぞれの立場にはこれ以上は立ち入りませんが、私が気になるのはWeb上の公務員バッシングにどうしようもないルサンチマン（怨恨）が感じられることです。
そのルサンチマンが「民間は苦しいのに公務員が楽してはいかん」という単純な図式を強烈に支持しているように見えてしまう。
薄給でハードワークをこなしながら、会社が潰れやしないか、リストラされやしないか、と不安を抱えるサラリーマンや派遣社員の人が公務員を叩いている。この状況が悲しく見えてしまうのは私だけでしょうか。
民間は民間でそれなりの、公務員は公務員でそれなりの人生が送れる社会が、本来あるべき社会ではないでしょうか。今の社会がおかしいからルサンチマンを持たざるを得ない人が増えているのではないでしょうか。
何かによって搾取されている若い世代の人たちも、橋本改革の図式に表面的に感情移入するのではなくて、その裏にある本当の問題（それが何かは私にもはっきりとは分かりませんが）を考えてみてもよいのではないでしょうか。
2008年6月19日木曜日
Hibernateはすごい！
今更ですがHibernateはすごいです。BeanとDBにマッピングするXMLを記載するだけでDAOが作れる。DAOだけなら別にどうってことはありませんが操作が直感的で、XMLにこう定義したからこうなったらいいなあ、という希望をビシビシ実現してくれます。
これはすごい。DAOはHibernateで止めを刺す、という印象です。
（しょうもない投稿ですが以上）
これはすごい。DAOはHibernateで止めを刺す、という印象です。
（しょうもない投稿ですが以上）
2008年6月17日火曜日
Spring Web Flow 1.0.5 でサンプルアプリの作成（中断）
一旦検証を中断します。
理由は優先度が下がったためです。
（もともとほとんど意地で取り組んだものだったし）
今のところの感想。
■デポーさんのページは非常によくできています。
■XMLに依存しすぎ
メソッドコールをXMLで定義するあたり「やりすぎ」という気がしますが趣味の問題かもしれません。SWFコアのデバッグ出力がしっかりしているので慣れてしまえば問題ないとは思います。
私の好みではInterfaceを定義してそれを実装する方が直感的でやりやすい（私だけじゃないと思うけどな・・・）。
以上
理由は優先度が下がったためです。
（もともとほとんど意地で取り組んだものだったし）
今のところの感想。
■デポーさんのページは非常によくできています。
■XMLに依存しすぎ
メソッドコールをXMLで定義するあたり「やりすぎ」という気がしますが趣味の問題かもしれません。SWFコアのデバッグ出力がしっかりしているので慣れてしまえば問題ないとは思います。
私の好みではInterfaceを定義してそれを実装する方が直感的でやりやすい（私だけじゃないと思うけどな・・・）。
以上
2008年6月13日金曜日
高コスト低リターンのテスト
低リターンのテストにやたらに体力を掛けてしまい、成果物の品質が悪くなる。そんなプロジェクトが珍しくありません。
なぜ低リターンのテストに体力が掛けられるような事態に陥ってしまうのか。その理由はプロジェクトが効率的に回っていないからです。
プロジェクトを効率的に回すためには、重要で効果の高いタスクに適切にリソースを配分し品質のよい仕事をさせることです。
重要な仕事を思いついてそこにリソースを回すくらい誰だって出来ます。だから効率的なプロジェクトとは、ちゃんと無駄な作業を定義しそれを行わないという判断ができるプロジェクトなのです。あるタスクを「行わない」とする判断こそが重要なのです。
言葉にすると簡単ですが、実行するのは実に難しい。普通のプロジェクトではタスクの優先付けをするのが精一杯だと思います。そこから一歩進めて「優先度の低いタスクを行わない」という意思決定ができるマネージャやリーダーはなかなかいません。それどころか「あれもこれも」とムダな作業を思いついてどんどんタスクを積み上げて行く人の方が多いくらいです。
人はとにかく作業に意味を見出したがりますし（そして大抵何らかの意味は見出せます）、自分の思いつきを他人から「意味がない」と言われることを嫌います。だからタスクは増える一方でなかなか減らない、ということになってしまいます。
話をテストに戻しましょう。
やるべきではないテストにはどのようなものがあるでしょうか。私が真っ先に思いつくのは以下の二つです。
１．OSのシステムクロック変更（時間を進めたり戻したりする）テスト
２．バッチ／オンラインカレンダー変更
まず１の時間を進めたり戻したりするテスト。
【無駄な理由１】システム的に無意味
まずシステムクロックは時間ではありません。UNIXを知っている方なら誰でもご存知かと思いますが、1970年1月1日、00:00:00からの秒単位のカウンターに過ぎません。
だから例えば「システムのカットオーバーが1年後だからシステム時刻を1年進めよう」という思いつきで時刻を進めたとしても、カウンターが数千万先に進んだ、というただそれだけの話なのです。しかも「カウンターを先に進める」というカットオーバー時にあり得ない設定変更を加えてテストをしている。
特にカウンターを意識してコーディングしなければ、プログラムはカウンターに依存せずに動きます。プログラムに関係のない設定変更をしてテストをするのは、全くのムダです。そんなことに体力を使うくらいだったらテストを2回した方がよほどましでしょう。
【無駄な理由２】時間の概念を全く考えていない
時間とは何でしょうか。昔から哲学者や物理学者が考えてきた深い問題です。生きられる時間。運動としての時間。物理学上のモデル化された時間。
時間というものを少し考えてみれば、システムクロックなどとは全く無関係であることにすぐ気がつくはずです。時間を進めることは人には不可能です。私にはこれほど自明なことはないと思えます。
システムクロックを先に進めて「今日は一年後だ」などと考えるのは、日めくりカレンダーを10枚めくって「10日たった」と考えるのにも等しい。進んだのは時刻ではない。単にカウンターを進めるというあり得ない操作をしただけです。あるいは日めくりカレンダーが10枚分余計にめくれた、それだけのことです。
これをテストの前提にするなど、全く意味がないと言えるでしょう。
【無駄な理由３】それこそ時間がもったいない
何台もあるサーバーの時間を変更する作業と、時間を戻してログをチェックする作業がもったいない。
２のバッチ／オンラインカレンダー変更。「明日は実際には水曜だけど日曜だ」というやつですね。それも人が勝手に思い込んでいるだけならいいのですが、システムに定義されているカレンダーを変更してまでテストをするから始末に悪い。
無駄な理由については先に述べたこととほとんど変わらないので割愛しますが、ようするに何をテストすべきかがちゃんと把握されていないために無駄なテストが行われてしまうことになるのです。
私はテストの計画時には以下の項目を押さえておくべきだと思います。
１．優先度を考慮すること
２．インターフェースを考慮すること
３．不安駆動や思いつき駆動になっていないか反省すること
１はテストに限らず重要なことです。無駄なテストは行わないこと。それによって時間と人という貴重なリソースを、例えばテストの結果照合やテスト手順の精緻化というもっと大事な仕事に回すことができます。それからテスト中に発生するであろう障害や問題に対応するための、余力も確保して計画しておくべきでしょう。
２はシステムに無関係なファクターをテストに持ち込まないことです。
オブジェクト指向という文脈でのインターフェースという言葉は、プログラミング以外のエリアでも有効です。すなわちインプットとアウトプットを明確に把握すること。システムに影響を与え得るファクター（＝インプット）は何か。そのファクターのうちでテストをしておくべきものは何か。そしてそのパターンは。期待されるアウトプットは何か。
システムクロックやカレンダーはほとんどのシステムではインプットにはなりません。そのような要素をテストに持ち込んでも意味はありません。
３は単なる思いつきや不安を、簡単にタスクに落としてはならないということです。不安のスコープと原因と解消、それぞれに道筋をつけた上で、さらに優先付けし、必要があれば切り捨てなければなりません。不安から生じた思いつきのタスクをいちいち持ち込んでも、現場が疲弊するだけなのです。
以上。今回はなんだか熱くなってしまいました・・・
なぜ低リターンのテストに体力が掛けられるような事態に陥ってしまうのか。その理由はプロジェクトが効率的に回っていないからです。
プロジェクトを効率的に回すためには、重要で効果の高いタスクに適切にリソースを配分し品質のよい仕事をさせることです。
重要な仕事を思いついてそこにリソースを回すくらい誰だって出来ます。だから効率的なプロジェクトとは、ちゃんと無駄な作業を定義しそれを行わないという判断ができるプロジェクトなのです。あるタスクを「行わない」とする判断こそが重要なのです。
言葉にすると簡単ですが、実行するのは実に難しい。普通のプロジェクトではタスクの優先付けをするのが精一杯だと思います。そこから一歩進めて「優先度の低いタスクを行わない」という意思決定ができるマネージャやリーダーはなかなかいません。それどころか「あれもこれも」とムダな作業を思いついてどんどんタスクを積み上げて行く人の方が多いくらいです。
人はとにかく作業に意味を見出したがりますし（そして大抵何らかの意味は見出せます）、自分の思いつきを他人から「意味がない」と言われることを嫌います。だからタスクは増える一方でなかなか減らない、ということになってしまいます。
話をテストに戻しましょう。
やるべきではないテストにはどのようなものがあるでしょうか。私が真っ先に思いつくのは以下の二つです。
１．OSのシステムクロック変更（時間を進めたり戻したりする）テスト
２．バッチ／オンラインカレンダー変更
まず１の時間を進めたり戻したりするテスト。
【無駄な理由１】システム的に無意味
まずシステムクロックは時間ではありません。UNIXを知っている方なら誰でもご存知かと思いますが、1970年1月1日、00:00:00からの秒単位のカウンターに過ぎません。
だから例えば「システムのカットオーバーが1年後だからシステム時刻を1年進めよう」という思いつきで時刻を進めたとしても、カウンターが数千万先に進んだ、というただそれだけの話なのです。しかも「カウンターを先に進める」というカットオーバー時にあり得ない設定変更を加えてテストをしている。
特にカウンターを意識してコーディングしなければ、プログラムはカウンターに依存せずに動きます。プログラムに関係のない設定変更をしてテストをするのは、全くのムダです。そんなことに体力を使うくらいだったらテストを2回した方がよほどましでしょう。
【無駄な理由２】時間の概念を全く考えていない
時間とは何でしょうか。昔から哲学者や物理学者が考えてきた深い問題です。生きられる時間。運動としての時間。物理学上のモデル化された時間。
時間というものを少し考えてみれば、システムクロックなどとは全く無関係であることにすぐ気がつくはずです。時間を進めることは人には不可能です。私にはこれほど自明なことはないと思えます。
システムクロックを先に進めて「今日は一年後だ」などと考えるのは、日めくりカレンダーを10枚めくって「10日たった」と考えるのにも等しい。進んだのは時刻ではない。単にカウンターを進めるというあり得ない操作をしただけです。あるいは日めくりカレンダーが10枚分余計にめくれた、それだけのことです。
これをテストの前提にするなど、全く意味がないと言えるでしょう。
【無駄な理由３】それこそ時間がもったいない
何台もあるサーバーの時間を変更する作業と、時間を戻してログをチェックする作業がもったいない。
２のバッチ／オンラインカレンダー変更。「明日は実際には水曜だけど日曜だ」というやつですね。それも人が勝手に思い込んでいるだけならいいのですが、システムに定義されているカレンダーを変更してまでテストをするから始末に悪い。
無駄な理由については先に述べたこととほとんど変わらないので割愛しますが、ようするに何をテストすべきかがちゃんと把握されていないために無駄なテストが行われてしまうことになるのです。
私はテストの計画時には以下の項目を押さえておくべきだと思います。
１．優先度を考慮すること
２．インターフェースを考慮すること
３．不安駆動や思いつき駆動になっていないか反省すること
１はテストに限らず重要なことです。無駄なテストは行わないこと。それによって時間と人という貴重なリソースを、例えばテストの結果照合やテスト手順の精緻化というもっと大事な仕事に回すことができます。それからテスト中に発生するであろう障害や問題に対応するための、余力も確保して計画しておくべきでしょう。
２はシステムに無関係なファクターをテストに持ち込まないことです。
オブジェクト指向という文脈でのインターフェースという言葉は、プログラミング以外のエリアでも有効です。すなわちインプットとアウトプットを明確に把握すること。システムに影響を与え得るファクター（＝インプット）は何か。そのファクターのうちでテストをしておくべきものは何か。そしてそのパターンは。期待されるアウトプットは何か。
システムクロックやカレンダーはほとんどのシステムではインプットにはなりません。そのような要素をテストに持ち込んでも意味はありません。
３は単なる思いつきや不安を、簡単にタスクに落としてはならないということです。不安のスコープと原因と解消、それぞれに道筋をつけた上で、さらに優先付けし、必要があれば切り捨てなければなりません。不安から生じた思いつきのタスクをいちいち持ち込んでも、現場が疲弊するだけなのです。
以上。今回はなんだか熱くなってしまいました・・・
2008年6月12日木曜日
Spring Web Flow 1.0.5 を試してみる
挫折して悪口を言っているだけでは悔しいので昔のSpring WebFlwo（以下SWF）バージョン（1.0.5）から勉強しなおしてみます。
なぜバージョン1.0台か。
SWF2.0からJSFやAjaxとの連携が教化された旨の情報をどこかで読んだからです。その画面＝Viewの対応強化にともなって設計の不透明さが増大したことは確かです。だとすれば1.0をみればSWFの設計コアがより分かり安いのではないか、と。
1.0には以下のような参考サイトもあります。かなりしっかり解説されていますね。大したものです。
Spring Web Flow解説(1)
2.0よりも少しは状況がマシではないかと期待しています。
（Spring WebFlowが今のままでは主流にならないという確信は変っていません。それでも勉強するのはほとんど意地です）
1.0.5はsourceforgeから辿って取得しました。
まずはphonebooksサンプルのビルドです。（パスが"/"なのはcygwinだからです。）
readmeにあったようにant distしてみます。
無事にtarget/artifacts/war/swf-booking.warが作成されました。（このあたりも2.0よりはずいぶんスムースな気がします）
すぐにtomcat6.0で動かすこともできました。DBも不要のようです。
サンプルはこうでなくちゃいけません。
今回はここまでとします。できれば次回以降でシンプルなアプリを作成し、SWF2.0につなげたいと思っています。
なぜバージョン1.0台か。
SWF2.0からJSFやAjaxとの連携が教化された旨の情報をどこかで読んだからです。その画面＝Viewの対応強化にともなって設計の不透明さが増大したことは確かです。だとすれば1.0をみればSWFの設計コアがより分かり安いのではないか、と。
1.0には以下のような参考サイトもあります。かなりしっかり解説されていますね。大したものです。
Spring Web Flow解説(1)
2.0よりも少しは状況がマシではないかと期待しています。
（Spring WebFlowが今のままでは主流にならないという確信は変っていません。それでも勉強するのはほとんど意地です）
1.0.5はsourceforgeから辿って取得しました。
まずはphonebooksサンプルのビルドです。（パスが"/"なのはcygwinだからです。）
readmeにあったようにant distしてみます。
[phonebook/] $ pwd
/spring-webflow-1.0.5/projects/spring-webflow-samples/phonebook
[phonebook/] $ ant dist
無事にtarget/artifacts/war/swf-booking.warが作成されました。（このあたりも2.0よりはずいぶんスムースな気がします）
すぐにtomcat6.0で動かすこともできました。DBも不要のようです。
サンプルはこうでなくちゃいけません。
今回はここまでとします。できれば次回以降でシンプルなアプリを作成し、SWF2.0につなげたいと思っています。
2008年6月11日水曜日
Spring Web Flowを試してみる（３）～ だめだこりゃ
※挫折・負け惜しみの記録です。
サンプルアプリ（swf-booking-mvc）は結局ほとんど役に立ちませんでした。
機能使いすぎ。どれがswf必須で、どれがオプションなのかが分かりません。しょうがないので０からアプリの作成に挑戦してみます。
（３日ほど経過）
ダメです。シンプルな画面遷移だけのサンプルすら作れません。
「Developing a Spring Framework MVC application step-by-step」のようなドキュメントがない。付属のbooking-mvcサンプルとリファレンスマニュアルをつきあわせて読んでみても、どう作ればいいのかさっぱり分かりません。
最後の手段でソースをごりごり読んでみましたが、さっぱり理解できない。設定ファイルをロードしておいて、リクエストのパラメータからコントローラとビーンを引っ張って処理をしているんだろうな、という程度の認識で読んでも全く分かりませんでした。Struts 1.0はシンプルで分かりやすかったのに・・・
【まとめ】
・サンプルひどすぎ。あんなリッチなサンプルではWebFlowの機能が全然見えません
・ドキュメント貧弱すぎ。リファレンスマニュアルだけじゃ作れっこない
このテクノロジーはいずれ消えるだろうな、というのが今のところの感想です。
サンプルアプリ（swf-booking-mvc）は結局ほとんど役に立ちませんでした。
機能使いすぎ。どれがswf必須で、どれがオプションなのかが分かりません。しょうがないので０からアプリの作成に挑戦してみます。
（３日ほど経過）
ダメです。シンプルな画面遷移だけのサンプルすら作れません。
「Developing a Spring Framework MVC application step-by-step」のようなドキュメントがない。付属のbooking-mvcサンプルとリファレンスマニュアルをつきあわせて読んでみても、どう作ればいいのかさっぱり分かりません。
最後の手段でソースをごりごり読んでみましたが、さっぱり理解できない。設定ファイルをロードしておいて、リクエストのパラメータからコントローラとビーンを引っ張って処理をしているんだろうな、という程度の認識で読んでも全く分かりませんでした。Struts 1.0はシンプルで分かりやすかったのに・・・
【まとめ】
・サンプルひどすぎ。あんなリッチなサンプルではWebFlowの機能が全然見えません
・ドキュメント貧弱すぎ。リファレンスマニュアルだけじゃ作れっこない
このテクノロジーはいずれ消えるだろうな、というのが今のところの感想です。
2008年6月10日火曜日
「障害を許さない」プロジェクトが破綻する理由（５）
■ システム障害はコントロールできない
ストア派の哲学者がかつて言ったそうです。「自分のコントロールできないものは諦めろ。自分がコントロールできる対象に集中しろ」と。
一応権威付けにストア派を持ち出してみましたが、実にまっとうな考えだと思います。
確かヤンキース松井だったと思いますが「不調の時いくらマスコミに叩かれても僕は気にしません。ぜなら僕はマスコミをコントロールできないから。自分がコントロールできること（つまり練習）をひたすらやるだけです」という旨のことをどこかで言っていた気がします。（例によってソースはありません）
まさにストイックな考え方ですね。自分がコントロールできる対象に集中すること。コントロールできないことは対象としない。
ではコントロールできないものとコントロールできるものとの違いはなんでしょうか。何を以って区別したらよいのでしょうか。
判断のセンスが問われるところです。
ヤンキース松井はマスコミをコントロール不能の対象としました。
でもひょっとしたらそう考えない人もいるかもしれません。悪口を言われたら言い返せばいい。論争によって黙らせることもできるかもしれない。裁判に訴えるという手もある。あるいはマスコミの指摘が正しいならばそれを受け入れてもいい。こっちがおとなしくなればそれ以上叩かれない可能性もある。
微妙なところですね。いずれも効果的ではないように見えます。それに挑発に乗らされていらぬ体力を使わせられている感もある。マスコミに迎合するのも美しくない。
マスコミをコントロールできないものとする判断には二つの価値観がキーになっているようです。
一つ目は美学。しょうもないバッシングにいちいち反応するのも迎合するのもカッコ悪い。
もう一つは経済学。マスコミをコントロールしようとして必死になっても、出来ることもその効果も限られているでしょう。それよりもひたすら自分が納得行くまで練習する方が効率的だし、体力の使い方としても有効です。
そろそろ本題に入りましょう。
システム障害がコントロール可能できるか。間違いなくコントロール不能です。コントロール不能という属性がシステム障害という概念に必然的に含まれていると言ってもよいでしょう。テストで意図的に障害を発生させる場合などを除けば、コントロール可能な障害という言葉がほとんど自己矛盾だからです。
システム障害は常に不意にこちらの意志とは無関係に発生するものです。そういう意味では天災に例えてもいいでしょう（世の中には富士山の噴火を止めるために日夜頑張っている人もいるそうですが）。
違和感を持つ人もいるかもしれませんね。システム障害は少なくとも人災であって天災ではない。コントロールできるのではないか。
では具体的に何ができるでしょうか。設計書を読み返す？プロジェクトのメンバーに「障害は許さない」とプレッシャーを掛ける？いずれも無意味です。
人は往々にして「将来をコントロールできる」と考えたくなるものです。そこには人間の本性に備わっている強い欲望がある。あるいは未来に対する不安を何とかしたい、という焦燥が隠されている。その不安に「原因と結果」というスキームを持ち込むとこうなります。
「今」は間違いなく次の瞬間につながっている。つまり、未来の原因は、今である。今が分かれば未来が分かる。
そもそも「原因と結果」というスキームが人間的な尺度に過ぎないことに気がつくべきです。あなたは自分がいつ死ぬのか、分かりますか？自分が死ぬ原因は今の自分に全て含まれている。本当でしょうか。それはただの人間的な解釈に過ぎないのではありませんか？
「原因と結果」は全て事後的な人間にとっての認識の枠組み＝解釈に過ぎないのです。生きるために必要な誤謬としての真理。もし運が良ければ、前提が変らなければ因果の法則通りに物事が進むこともあるかもしれません。しかし必ずしも物事はそうはならないことの方が多い。
もう少し穏当な表現を使えば「原因と結果」という枠組みは慎重に適用されなければならないし、その内容ももっと慎重に検証されるべきなのです。あくまで人間が長い進化の過程で培ってきた概念に過ぎない。極めて有効に働くこともあるかもしれませんが、そうでない場合だって多い。
「原因と結果」というスキームは常に事後的であることに常に注意すべきです。未来への不安を覆い隠すために安直に時系列を逆転させてはなりません。
未来は原因と結果という時系列で理解できるよりももっと豊かで、もっと不確実なものなのです。
少し脱線しました。
しかし明らかにシステム障害は好ましくない。ではそれを防ぐために何をしたらよいのか。
答えは明らかです。同じようなことを繰り返しますが「入念にテストをしておくこと」「システムの状態を常に把握できるようにしておくこと」それから別の次元になりますが「システム障害を業務の障害に直結させないように、システム障害を折り込んだ業務を準備しておくこと」。
障害はコントロールできない。そこがプロジェクトの出発点だと私は思います。
ストア派の哲学者がかつて言ったそうです。「自分のコントロールできないものは諦めろ。自分がコントロールできる対象に集中しろ」と。
一応権威付けにストア派を持ち出してみましたが、実にまっとうな考えだと思います。
確かヤンキース松井だったと思いますが「不調の時いくらマスコミに叩かれても僕は気にしません。ぜなら僕はマスコミをコントロールできないから。自分がコントロールできること（つまり練習）をひたすらやるだけです」という旨のことをどこかで言っていた気がします。（例によってソースはありません）
まさにストイックな考え方ですね。自分がコントロールできる対象に集中すること。コントロールできないことは対象としない。
ではコントロールできないものとコントロールできるものとの違いはなんでしょうか。何を以って区別したらよいのでしょうか。
判断のセンスが問われるところです。
ヤンキース松井はマスコミをコントロール不能の対象としました。
でもひょっとしたらそう考えない人もいるかもしれません。悪口を言われたら言い返せばいい。論争によって黙らせることもできるかもしれない。裁判に訴えるという手もある。あるいはマスコミの指摘が正しいならばそれを受け入れてもいい。こっちがおとなしくなればそれ以上叩かれない可能性もある。
微妙なところですね。いずれも効果的ではないように見えます。それに挑発に乗らされていらぬ体力を使わせられている感もある。マスコミに迎合するのも美しくない。
マスコミをコントロールできないものとする判断には二つの価値観がキーになっているようです。
一つ目は美学。しょうもないバッシングにいちいち反応するのも迎合するのもカッコ悪い。
もう一つは経済学。マスコミをコントロールしようとして必死になっても、出来ることもその効果も限られているでしょう。それよりもひたすら自分が納得行くまで練習する方が効率的だし、体力の使い方としても有効です。
そろそろ本題に入りましょう。
システム障害がコントロール可能できるか。間違いなくコントロール不能です。コントロール不能という属性がシステム障害という概念に必然的に含まれていると言ってもよいでしょう。テストで意図的に障害を発生させる場合などを除けば、コントロール可能な障害という言葉がほとんど自己矛盾だからです。
システム障害は常に不意にこちらの意志とは無関係に発生するものです。そういう意味では天災に例えてもいいでしょう（世の中には富士山の噴火を止めるために日夜頑張っている人もいるそうですが）。
違和感を持つ人もいるかもしれませんね。システム障害は少なくとも人災であって天災ではない。コントロールできるのではないか。
では具体的に何ができるでしょうか。設計書を読み返す？プロジェクトのメンバーに「障害は許さない」とプレッシャーを掛ける？いずれも無意味です。
人は往々にして「将来をコントロールできる」と考えたくなるものです。そこには人間の本性に備わっている強い欲望がある。あるいは未来に対する不安を何とかしたい、という焦燥が隠されている。その不安に「原因と結果」というスキームを持ち込むとこうなります。
「今」は間違いなく次の瞬間につながっている。つまり、未来の原因は、今である。今が分かれば未来が分かる。
そもそも「原因と結果」というスキームが人間的な尺度に過ぎないことに気がつくべきです。あなたは自分がいつ死ぬのか、分かりますか？自分が死ぬ原因は今の自分に全て含まれている。本当でしょうか。それはただの人間的な解釈に過ぎないのではありませんか？
「原因と結果」は全て事後的な人間にとっての認識の枠組み＝解釈に過ぎないのです。生きるために必要な誤謬としての真理。もし運が良ければ、前提が変らなければ因果の法則通りに物事が進むこともあるかもしれません。しかし必ずしも物事はそうはならないことの方が多い。
もう少し穏当な表現を使えば「原因と結果」という枠組みは慎重に適用されなければならないし、その内容ももっと慎重に検証されるべきなのです。あくまで人間が長い進化の過程で培ってきた概念に過ぎない。極めて有効に働くこともあるかもしれませんが、そうでない場合だって多い。
「原因と結果」というスキームは常に事後的であることに常に注意すべきです。未来への不安を覆い隠すために安直に時系列を逆転させてはなりません。
未来は原因と結果という時系列で理解できるよりももっと豊かで、もっと不確実なものなのです。
少し脱線しました。
しかし明らかにシステム障害は好ましくない。ではそれを防ぐために何をしたらよいのか。
答えは明らかです。同じようなことを繰り返しますが「入念にテストをしておくこと」「システムの状態を常に把握できるようにしておくこと」それから別の次元になりますが「システム障害を業務の障害に直結させないように、システム障害を折り込んだ業務を準備しておくこと」。
障害はコントロールできない。そこがプロジェクトの出発点だと私は思います。
2008年6月5日木曜日
Spring Web Flowを試してみる（２）
Spring Web Flowを試してみる（２）
eclipse3.3にswf-booking-mvc-2.0.1.RELEASE.warをインポートしてantのbuildファイルを作成しました。
あとはwarの中身の探検ですが、その前にbooking-mvcをdeployしてみました。動かないものをいじってもしょうがないので。
するとTomcat起動時にいきなりエラーが。まあ覚悟はしてましたけどね。DB関係の設定何もしてないし。
ログに出ていた[/WEB-INF/config/data-access-config.xml]をチェック。HSQLDBを使っているようなので、springサンプルで使ったDBのURLに編集しなおしました。
hsqlを起動して再チャレンジ。
当然のようにだめ。同じエラーがでます。DBが出来ていないことが原因だろうと推測。
hsqldbにテーブル群を作成してみます。（← 6/6追記：作成してはいけません。ダメです）
テーブルは insert.sql を参考にして適当に作りました。（割と嫌気がさしてきています。こんなのサンプルにつけておくべきでしょう）
（後記：動かなかったのは別の原因でした。ひょっとしたらdeployしたら自動で作ってくれるのかもしれません）
（6/6追記：自動で作ってくれます。しかも以下のテーブルを作ってしまうと動きません！）
hsqlの管理画面から上記テーブルを作成。
データのロードを実施。データロードにはantのタスク（spring mvcのチュートリアルからコピペ）を使いました。
結果はやはり失敗。
同じエラーが出ます。
googleで"No persistence units parsed from"で検索すると Error using JPAというページが引っかかりました。内容を読んでみると"WEB-INF/classes/META-INF/persistence.xml"がないとダメだ、とのこと。
eclipseにwarをインポートして、antでデプロイしていたのですが、"src/META-INF/persistence.xml"をtomcatにデプロイできていなかったことが判明しました。
上記をWEB-INF/classesにコピーする処理をbuild.xmlに追加。
無事にアクセスできました。
よかったよかった。
結論として、warファイルの中身はdata-access-config.xmlの"jdbc:hsqldb:mem:booking"を適切なものに変更し（本当は不要なのかもしれませんが）テーブルを作ればwarのデプロイに成功しました。
（6/6追記：テーブルは作成不要です。自動で作ってくれます）
日暮れて道遠しですが、とりあえずは一段落。
eclipse3.3にswf-booking-mvc-2.0.1.RELEASE.warをインポートしてantのbuildファイルを作成しました。
あとはwarの中身の探検ですが、その前にbooking-mvcをdeployしてみました。動かないものをいじってもしょうがないので。
するとTomcat起動時にいきなりエラーが。まあ覚悟はしてましたけどね。DB関係の設定何もしてないし。
2008/06/05 10:45:55 org.apache.catalina.core.StandardContext listenerStart
致命的: クラス org.springframework.web.context.ContextLoaderListener のリスナインスタンスにコンテキスト初期化イベントを送信中の例外です
org.springframework.beans.factory.BeanCreationException: Error creating bean with name '_rememberMeServicesInjectionBeanPostProcessor': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: ・・・
ログに出ていた[/WEB-INF/config/data-access-config.xml]をチェック。HSQLDBを使っているようなので、springサンプルで使ったDBのURLに編集しなおしました。
jdbc:hsqldb:mem:booking
↓
jdbc:hsqldb:hsql://localhost
hsqlを起動して再チャレンジ。
当然のようにだめ。同じエラーがでます。DBが出来ていないことが原因だろうと推測。
hsqldbにテーブル群を作成してみます。（← 6/6追記：作成してはいけません。ダメです）
テーブルは insert.sql を参考にして適当に作りました。（割と嫌気がさしてきています。こんなのサンプルにつけておくべきでしょう）
（後記：動かなかったのは別の原因でした。ひょっとしたらdeployしたら自動で作ってくれるのかもしれません）
（6/6追記：自動で作ってくれます。しかも以下のテーブルを作ってしまうと動きません！）
CREATE TABLE Customer (
username varchar(127),
name varchar(127)
);
create table Hotel (
id INTEGER NOT NULL PRIMARY KEY,
price decimal(15,2),
name varchar(127),
address varchar(127),
city varchar(127),
state varchar(20),
zip varchar(10),
country varchar(20)
);
hsqlの管理画面から上記テーブルを作成。
java -classpath ../war/WEB-INF/lib/hsqldb.jar org.hsqldb.util.DatabaseManager
データのロードを実施。データロードにはantのタスク（spring mvcのチュートリアルからコピペ）を使いました。
<target name="loadData">
<echo message="LOAD DATA USING: ${db.driver} ${db.url}"/>
<sql driver="${db.driver}"
url="${db.url}"
userid="${db.user}"
password="${db.pw}"
onerror="continue"
src="src/import.sql">
<classpath refid="master-classpath"/>
</sql>
</target>
結果はやはり失敗。
同じエラーが出ます。
googleで"No persistence units parsed from"で検索すると Error using JPAというページが引っかかりました。内容を読んでみると"WEB-INF/classes/META-INF/persistence.xml"がないとダメだ、とのこと。
eclipseにwarをインポートして、antでデプロイしていたのですが、"src/META-INF/persistence.xml"をtomcatにデプロイできていなかったことが判明しました。
上記をWEB-INF/classesにコピーする処理をbuild.xmlに追加。
<target name="build" description="Compile main source tree java files">
<mkdir dir="${build.dir}"/>
<javac destdir="${build.dir}" source="1.5" target="1.5" debug="true"
deprecation="false" optimize="false" failonerror="true">
<src path="${src.dir}"/>
<classpath refid="master-classpath"/>
</javac>
<copy todir="${build.dir}" preservelastmodified="true">
<fileset dir="${src.dir}">
<include name="**/*.xml"/>
</fileset>
</copy>
</target>
無事にアクセスできました。
よかったよかった。
結論として、warファイルの中身はdata-access-config.xmlの"jdbc:hsqldb:mem:booking"を適切なものに変更し
（6/6追記：テーブルは作成不要です。自動で作ってくれます）
日暮れて道遠しですが、とりあえずは一段落。
Spring Web Flowを試してみる（１）
Spring MVCは確かに優れたフレームワークなのですが、SimpleFormControllerとAbstractWizardFormControllerだけでは一般的に要求されるページ遷移を実装するのは難しいと思われます。
単に行ったり来たりするだけならば問題はありません。そうではなくブラウザの戻るボタンが押されたときに画面遷移を無効化したいとか、ブラウザリフレッシュ（リロード）を無効化したいという要件にSpring MVCで対応するのは厳しいようです。
SimpleFormControllerはformBackingObjectで画面出力し、画面入力をdoSubmitで受けて処理をし、redirectで返すという単発の処理に適したコントローラです。入力もセッションもその場限りで更新されるイメージです。
画面遷移を制御したい場合には、セッション管理やBeanを作りこみ、かつredirectではなくforwardで画面遷移を構成する必要がありますが、単にゴリゴリ書いて行くだけではSimpleFormControllerを実装したコントローラの肥大化を招くだけです。
AbstractWizardFormControllerは、Wizard形式の画面遷移を簡単に実装できる素晴らしいコントローラですが、同じく多数の画面（例えば５０画面）をこれで管理するのはムリがあります。
ということで、Spring Web Flowがどれほどのものか試してみたいと思います。
【途中経過】
思った以上にドキュメントが貧弱で苦労しています。
eclipse 3.3へのプロジェクトのインポートもreadme通りには行きませんでした。
とりあえずspring-webflow-2.0.1.RELEASE\projects\spring-webflow-samples\booking-mvcで
するとspring-webflow-2.0.1.RELEASE\projects\integration-repo\org.springframework.webflow.samples\swf-booking-mvc\2.0.1.RELEASE\swf-booking-mvc-2.0.1.RELEASE.war"が出来たようなので、ここから始めたいと思っています。
単に行ったり来たりするだけならば問題はありません。そうではなくブラウザの戻るボタンが押されたときに画面遷移を無効化したいとか、ブラウザリフレッシュ（リロード）を無効化したいという要件にSpring MVCで対応するのは厳しいようです。
SimpleFormControllerはformBackingObjectで画面出力し、画面入力をdoSubmitで受けて処理をし、redirectで返すという単発の処理に適したコントローラです。入力もセッションもその場限りで更新されるイメージです。
画面遷移を制御したい場合には、セッション管理やBeanを作りこみ、かつredirectではなくforwardで画面遷移を構成する必要がありますが、単にゴリゴリ書いて行くだけではSimpleFormControllerを実装したコントローラの肥大化を招くだけです。
AbstractWizardFormControllerは、Wizard形式の画面遷移を簡単に実装できる素晴らしいコントローラですが、同じく多数の画面（例えば５０画面）をこれで管理するのはムリがあります。
ということで、Spring Web Flowがどれほどのものか試してみたいと思います。
【途中経過】
思った以上にドキュメントが貧弱で苦労しています。
eclipse 3.3へのプロジェクトのインポートもreadme通りには行きませんでした。
とりあえずspring-webflow-2.0.1.RELEASE\projects\spring-webflow-samples\booking-mvcで
ant jar
ant publish
するとspring-webflow-2.0.1.RELEASE\projects\integration-repo\org.springframework.webflow.samples\swf-booking-mvc\2.0.1.RELEASE\swf-booking-mvc-2.0.1.RELEASE.war"が出来たようなので、ここから始めたいと思っています。
2008年6月4日水曜日
10年続けてみる
今朝ふと吉本隆明が言った「何事も10年続けるとモノになる」という言葉を思い出しました。
どういう文脈だったかは思い出せません。
いろいろつらいことも気に入らないこともあるだろうけど、まあとにかく10年続けてれば何かしら光明が見えてくる。体がそう成ってくる、という風に私は理解しました。
何事も10年続ければモノになる。
ありふれた言葉の要ですが、なかなか含蓄があります。
確かにある種の技量は幼いうちに素養を積んでおかないと、歳をとってからは厳しいと思います。
例えば楽器の演奏です。小さい頃に耳が出来ていないと、例えばバイオリンの学習は難しいでしょう。
しかし、上手く行かなくて難しくて大変だからこそ、10年続けることに意義があるのかもしれません。
すこし脱線しますが、「耳が出来る」ということを、私は養老猛司風に「脳に回路が出来る」と解釈しています。耳が出来るということは、脳に音階に対応した回路が出来る。耳からのインプットを受けて指が勝手に動くような仕組みが脳に出来て行く。そう考えるとなんだか楽しくなるので。
私の人生をふり返ってみても、とにかく頑張って仕事をしてきて、いろいろ外部の環境の変化もあったけれど、でも何とか仕事がモノになってきた。幸福か？人のことがうらやましくないか？という問いには簡単には答えられませんし、先の不安もないわけではありません。それにしてもまあこれまで何とかなったもんだな、という感慨があります。
楽器など趣味の世界でもそうですね。確かに小さい頃からみっちり練習してきたプロや音大／芸大出の方にはかなわない。でも趣味も10年続けていれば、それなりに自己満足できるところまでは行けると思います。
10年。長いようで短い期間です。30歳から本気で何かをやり始めたとして、50歳まで20年しかありません。しかし短い期間といえども続けるということはそんな簡単ではない。何かを続ける10年間は長くも短くもなるわけです。
そう考えると今の時間と、今10年後を見定めて何を始めるのか、という問いが非常に重いものであることが分かります。またその問いには自分を何かに投げかけるという生き方が示唆されている。ただ漫然と日々を過ごすのではなく未来へ向かって自分を投げ入れるという生き方です。そして10年という単位で人生を見たときに今の時間が非常に貴重であることに気がつかされます。
これからも大変なことはいろいろあるでしょうが、頑張って生きて行こうと思います。
（6/6追記）
asahi.comに『「ほぼ日刊」実はホントに日刊 「イトイ新聞」１０周年』という記事が出ていて、以下の文章がありました。（リンクが許可制なのでリンクなしです）
糸井さんは「１０年続けること」を目標にしてきた。文芸評論家の吉本隆明氏に「とにかく毎日、１０年続けたらものになる。ぼくが保証する」と言われたからだ。
微妙にシンクロしてうれしいです。こういうことってたまにある。
どういう文脈だったかは思い出せません。
いろいろつらいことも気に入らないこともあるだろうけど、まあとにかく10年続けてれば何かしら光明が見えてくる。体がそう成ってくる、という風に私は理解しました。
何事も10年続ければモノになる。
ありふれた言葉の要ですが、なかなか含蓄があります。
確かにある種の技量は幼いうちに素養を積んでおかないと、歳をとってからは厳しいと思います。
例えば楽器の演奏です。小さい頃に耳が出来ていないと、例えばバイオリンの学習は難しいでしょう。
しかし、上手く行かなくて難しくて大変だからこそ、10年続けることに意義があるのかもしれません。
すこし脱線しますが、「耳が出来る」ということを、私は養老猛司風に「脳に回路が出来る」と解釈しています。耳が出来るということは、脳に音階に対応した回路が出来る。耳からのインプットを受けて指が勝手に動くような仕組みが脳に出来て行く。そう考えるとなんだか楽しくなるので。
私の人生をふり返ってみても、とにかく頑張って仕事をしてきて、いろいろ外部の環境の変化もあったけれど、でも何とか仕事がモノになってきた。幸福か？人のことがうらやましくないか？という問いには簡単には答えられませんし、先の不安もないわけではありません。それにしてもまあこれまで何とかなったもんだな、という感慨があります。
楽器など趣味の世界でもそうですね。確かに小さい頃からみっちり練習してきたプロや音大／芸大出の方にはかなわない。でも趣味も10年続けていれば、それなりに自己満足できるところまでは行けると思います。
10年。長いようで短い期間です。30歳から本気で何かをやり始めたとして、50歳まで20年しかありません。しかし短い期間といえども続けるということはそんな簡単ではない。何かを続ける10年間は長くも短くもなるわけです。
そう考えると今の時間と、今10年後を見定めて何を始めるのか、という問いが非常に重いものであることが分かります。またその問いには自分を何かに投げかけるという生き方が示唆されている。ただ漫然と日々を過ごすのではなく未来へ向かって自分を投げ入れるという生き方です。そして10年という単位で人生を見たときに今の時間が非常に貴重であることに気がつかされます。
これからも大変なことはいろいろあるでしょうが、頑張って生きて行こうと思います。
（6/6追記）
asahi.comに『「ほぼ日刊」実はホントに日刊 「イトイ新聞」１０周年』という記事が出ていて、以下の文章がありました。（リンクが許可制なのでリンクなしです）
糸井さんは「１０年続けること」を目標にしてきた。文芸評論家の吉本隆明氏に「とにかく毎日、１０年続けたらものになる。ぼくが保証する」と言われたからだ。
微妙にシンクロしてうれしいです。こういうことってたまにある。
2008年6月3日火曜日
「障害を許さない」プロジェクトが破綻する理由（４）
■障害の予防にかけるコスト
障害が発生すれば当然コストがかかります。
障害によってはその損失額は膨大になるでしょう。また考えられる障害のケース毎に予想される損失額を加算して行くと、ほとんど無限とも言える額になると思います。
小は個々のコンポーネントの障害から、大きくは（昨今話題の銀行システムで言えば）ATMの障害や勘定系システムの障害、情報系システムの障害、あるいは顧客情報の漏洩、ブランドイメージの失墜などなど・・・
では、障害を予防するためにはどれだけコストをかけるべきか。
障害が発生した場合の推定損失額は無限だから無限にコストをかける？それはあり得ません。時間と金を無限にかけるシステムは決して完成することはないでしょう。
では適性なコストとは？
障害の根本的な原因は常に人だと私は思います。人が何か新しいことを始めればミスをする。そして運が悪ければそのミスの結果、障害が発生する。だから障害を発生させないためには、人に障害につながるようなミスをさせないような仕組みが必要です。
素晴らしい。これで障害を根絶できます。まさにノーベル賞ものの理論ではないでしょうか。
でも残念でした。そんなに簡単には行きません。
仕組みといってもシステム開発作業は決まりきったルーチンワークではありません。ルーチンワークならそれこそシステムに任せればいい（そのシステムも障害からは逃れられませんが・・・）。むしろ少なからずクリエイティブな作業です。機械的に定義できるようなものではない。従って運用や仕組みによってその成果を一定の品質に保つことはできません。成果物の品質は個人の能力に依存してきます。しかしいくら優秀な人間が作業をしても当然勘違いやミスは発生する（世の中に完璧な人生を送る人がいるでしょうか？）。そして事前に潰せるミスも少なからずある。ではどのようにしてミスを潰すか。例えばミスのチェック体制を作ることによって潰すことができますね。
ここで私は「ミスを起こさない／起こさせないためにどれだけ努力するか」という命題を「人をどれだけ信頼するか」という命題に差し替えます。
人を疑えばコストが掛かります。ある人の行動や成果を徹底的にチェックしようとすると、もう一人の人がいる（実は一人では足りないんじゃないか、という気もします。人が増えるとそれだけで仕事が増えますから）。じゃあ、そのチェックする人を信用するのか、という話も出てきます。つまり疑い始めればきりがないのです。
かといってメンバーを全面的に信頼するわけには行かない。プロジェクトに関わったことがある人ならお分かりだと思います。ウソを報告したりまずいことを隠したりメンバーもいるものです。
逆説的ですが障害やミスを発生させないように強いプレッシャーをかけるとメンバーがウソをついたり隠したりする傾向が強まります（むしろ当然？）。そうならないためには、かえって障害やミスを報告したメンバーを誉めてやるべきです。
ですから、プロジェクトの運営を通じて信頼度と技術力が見極めたら、信頼できるメンバーには基本的に任せる。そして技術力が疑わしいメンバーのタスクを減らし、その成果物をチェックする。これがもっとも効率がいい。別にウソをついているのではないか。信頼できない、と疑うってかかるわけではありません。それは却って逆効果でしょう。オーバーワークになったメンバーはえてして品質の悪いものを作ります。しかしその人が悪いわけではなく、追い込んだリーダー／マネージャの問題です。
とにかくここが出発点だと思います。まずは信頼できる人間を信頼すること。そして信頼できる人間が前向きに作業できる時間を確保した上で、チェック体制を作ること。チェックばかりに体力が行ってしまうと、行きつく先は品質の劣化に他なりません。
システム開発メンバの本業は何か。障害を潰すためのチェックではありません。障害を洗い出し、品質を向上させるのが本業のはずです。それを見失ってはならない、と私は思います。
障害が発生すれば当然コストがかかります。
障害によってはその損失額は膨大になるでしょう。また考えられる障害のケース毎に予想される損失額を加算して行くと、ほとんど無限とも言える額になると思います。
小は個々のコンポーネントの障害から、大きくは（昨今話題の銀行システムで言えば）ATMの障害や勘定系システムの障害、情報系システムの障害、あるいは顧客情報の漏洩、ブランドイメージの失墜などなど・・・
では、障害を予防するためにはどれだけコストをかけるべきか。
障害が発生した場合の推定損失額は無限だから無限にコストをかける？それはあり得ません。時間と金を無限にかけるシステムは決して完成することはないでしょう。
では適性なコストとは？
障害の根本的な原因は常に人だと私は思います。人が何か新しいことを始めればミスをする。そして運が悪ければそのミスの結果、障害が発生する。だから障害を発生させないためには、人に障害につながるようなミスをさせないような仕組みが必要です。
素晴らしい。これで障害を根絶できます。まさにノーベル賞ものの理論ではないでしょうか。
でも残念でした。そんなに簡単には行きません。
仕組みといってもシステム開発作業は決まりきったルーチンワークではありません。ルーチンワークならそれこそシステムに任せればいい（そのシステムも障害からは逃れられませんが・・・）。むしろ少なからずクリエイティブな作業です。機械的に定義できるようなものではない。従って運用や仕組みによってその成果を一定の品質に保つことはできません。成果物の品質は個人の能力に依存してきます。しかしいくら優秀な人間が作業をしても当然勘違いやミスは発生する（世の中に完璧な人生を送る人がいるでしょうか？）。そして事前に潰せるミスも少なからずある。ではどのようにしてミスを潰すか。例えばミスのチェック体制を作ることによって潰すことができますね。
ここで私は「ミスを起こさない／起こさせないためにどれだけ努力するか」という命題を「人をどれだけ信頼するか」という命題に差し替えます。
人を疑えばコストが掛かります。ある人の行動や成果を徹底的にチェックしようとすると、もう一人の人がいる（実は一人では足りないんじゃないか、という気もします。人が増えるとそれだけで仕事が増えますから）。じゃあ、そのチェックする人を信用するのか、という話も出てきます。つまり疑い始めればきりがないのです。
かといってメンバーを全面的に信頼するわけには行かない。プロジェクトに関わったことがある人ならお分かりだと思います。ウソを報告したりまずいことを隠したりメンバーもいるものです。
逆説的ですが障害やミスを発生させないように強いプレッシャーをかけるとメンバーがウソをついたり隠したりする傾向が強まります（むしろ当然？）。そうならないためには、かえって障害やミスを報告したメンバーを誉めてやるべきです。
ですから、プロジェクトの運営を通じて信頼度と技術力が見極めたら、信頼できるメンバーには基本的に任せる。そして技術力が疑わしいメンバーのタスクを減らし、その成果物をチェックする。これがもっとも効率がいい。別にウソをついているのではないか。信頼できない、と疑うってかかるわけではありません。それは却って逆効果でしょう。オーバーワークになったメンバーはえてして品質の悪いものを作ります。しかしその人が悪いわけではなく、追い込んだリーダー／マネージャの問題です。
とにかくここが出発点だと思います。まずは信頼できる人間を信頼すること。そして信頼できる人間が前向きに作業できる時間を確保した上で、チェック体制を作ること。チェックばかりに体力が行ってしまうと、行きつく先は品質の劣化に他なりません。
システム開発メンバの本業は何か。障害を潰すためのチェックではありません。障害を洗い出し、品質を向上させるのが本業のはずです。それを見失ってはならない、と私は思います。
登録:
投稿 (Atom)