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の障害や勘定系システムの障害、情報系システムの障害、あるいは顧客情報の漏洩、ブランドイメージの失墜などなど・・・
では、障害を予防するためにはどれだけコストをかけるべきか。
障害が発生した場合の推定損失額は無限だから無限にコストをかける？それはあり得ません。時間と金を無限にかけるシステムは決して完成することはないでしょう。
では適性なコストとは？
障害の根本的な原因は常に人だと私は思います。人が何か新しいことを始めればミスをする。そして運が悪ければそのミスの結果、障害が発生する。だから障害を発生させないためには、人に障害につながるようなミスをさせないような仕組みが必要です。
素晴らしい。これで障害を根絶できます。まさにノーベル賞ものの理論ではないでしょうか。
でも残念でした。そんなに簡単には行きません。
仕組みといってもシステム開発作業は決まりきったルーチンワークではありません。ルーチンワークならそれこそシステムに任せればいい（そのシステムも障害からは逃れられませんが・・・）。むしろ少なからずクリエイティブな作業です。機械的に定義できるようなものではない。従って運用や仕組みによってその成果を一定の品質に保つことはできません。成果物の品質は個人の能力に依存してきます。しかしいくら優秀な人間が作業をしても当然勘違いやミスは発生する（世の中に完璧な人生を送る人がいるでしょうか？）。そして事前に潰せるミスも少なからずある。ではどのようにしてミスを潰すか。例えばミスのチェック体制を作ることによって潰すことができますね。
ここで私は「ミスを起こさない／起こさせないためにどれだけ努力するか」という命題を「人をどれだけ信頼するか」という命題に差し替えます。
人を疑えばコストが掛かります。ある人の行動や成果を徹底的にチェックしようとすると、もう一人の人がいる（実は一人では足りないんじゃないか、という気もします。人が増えるとそれだけで仕事が増えますから）。じゃあ、そのチェックする人を信用するのか、という話も出てきます。つまり疑い始めればきりがないのです。
かといってメンバーを全面的に信頼するわけには行かない。プロジェクトに関わったことがある人ならお分かりだと思います。ウソを報告したりまずいことを隠したりメンバーもいるものです。
逆説的ですが障害やミスを発生させないように強いプレッシャーをかけるとメンバーがウソをついたり隠したりする傾向が強まります（むしろ当然？）。そうならないためには、かえって障害やミスを報告したメンバーを誉めてやるべきです。
ですから、プロジェクトの運営を通じて信頼度と技術力が見極めたら、信頼できるメンバーには基本的に任せる。そして技術力が疑わしいメンバーのタスクを減らし、その成果物をチェックする。これがもっとも効率がいい。別にウソをついているのではないか。信頼できない、と疑うってかかるわけではありません。それは却って逆効果でしょう。オーバーワークになったメンバーはえてして品質の悪いものを作ります。しかしその人が悪いわけではなく、追い込んだリーダー／マネージャの問題です。
とにかくここが出発点だと思います。まずは信頼できる人間を信頼すること。そして信頼できる人間が前向きに作業できる時間を確保した上で、チェック体制を作ること。チェックばかりに体力が行ってしまうと、行きつく先は品質の劣化に他なりません。
システム開発メンバの本業は何か。障害を潰すためのチェックではありません。障害を洗い出し、品質を向上させるのが本業のはずです。それを見失ってはならない、と私は思います。
2008年6月2日月曜日
「障害を許さない」プロジェクトが破綻する理由（３）
■障害と不安
以前にも不安とプロジェクトの関係について述べましたことがありますが、今回は障害と不安との関係に焦点を当てて考えてみたいと思います。
障害は常に不安を煽るものです。なぜでしょうか。それは障害がわれわれを（未だ来ぬ）未来の可能性へと差し向けるからです。
普段われわれは特にその瞬間瞬間の可能性と直面することなく日常を過ごしています。先のことは全て予定表に入っている。つまり日常の時間にあるのは「未だ来ぬ」未来ではなく「将に来たるべき」将来です。これが普通日常に生きているわれわれの時間意識です。
具体的に言えば、例えば明日、いや次の瞬間にも大地震がおきてわれわれは死ぬかもしれない。あるいは車にぶつかって死ぬかもしれない。残念ながらそれは本当のことです。しかしそれを普段本気で考えている人はいません。健康な人であっても時折自分の死について考えることがあるかもしれません。しかし「次の瞬間死ぬかもしれない」と一瞬一瞬常に真剣に考えている人はほとんどノイローゼでしょう。
もう少し踏み込んで言えば、われわれは日常的な営みによって未来という巨大な不安を覆い隠しているのです。
そして障害は予期されない不愉快な事象として、われわれの不安を顕わにします。だからこそわれわれは障害を前もって、あらかじめ知りたいと思うのです。
しかし残念ながら障害の発生日は手帳には書いていません。予定通りに発生する障害というのはほとんど言葉の矛盾です。
ところが障害の原因が判明した事後からふり返ってみれば、その発生が必然であったことが分かる。
ここである種の人の中で時系列が逆転します。あのときこういう対応をしておけば障害は未然に防ぐことができた。なぜそれができなかったのか。
ある意味正しい反応です。好ましくない事象が発生したときにその原因を究明し次のアクションを取る。ヘビに噛まれて痛かったのならば次はヘビに噛まれないように用心する。しかし残念ながらシステム障害に対応するための方法論としてはいささか貧弱過ぎる。システムはあまりに複雑だし、人はあまりに不完全だからです。
障害に対応するためにはまずは人の不完全さを受け入れる必要があると私は思います。つまり事前に潰そうといたずらに体力をかけるのではなく（これは経済学の問題です）、事前に障害を出来るだけ出して直しておくこと。そして障害が発生したときの運用を確立しておくこと。それがもっとも効率的に障害に対処する方法だと私は思います。
以前にも不安とプロジェクトの関係について述べましたことがありますが、今回は障害と不安との関係に焦点を当てて考えてみたいと思います。
障害は常に不安を煽るものです。なぜでしょうか。それは障害がわれわれを（未だ来ぬ）未来の可能性へと差し向けるからです。
普段われわれは特にその瞬間瞬間の可能性と直面することなく日常を過ごしています。先のことは全て予定表に入っている。つまり日常の時間にあるのは「未だ来ぬ」未来ではなく「将に来たるべき」将来です。これが普通日常に生きているわれわれの時間意識です。
具体的に言えば、例えば明日、いや次の瞬間にも大地震がおきてわれわれは死ぬかもしれない。あるいは車にぶつかって死ぬかもしれない。残念ながらそれは本当のことです。しかしそれを普段本気で考えている人はいません。健康な人であっても時折自分の死について考えることがあるかもしれません。しかし「次の瞬間死ぬかもしれない」と一瞬一瞬常に真剣に考えている人はほとんどノイローゼでしょう。
もう少し踏み込んで言えば、われわれは日常的な営みによって未来という巨大な不安を覆い隠しているのです。
そして障害は予期されない不愉快な事象として、われわれの不安を顕わにします。だからこそわれわれは障害を前もって、あらかじめ知りたいと思うのです。
しかし残念ながら障害の発生日は手帳には書いていません。予定通りに発生する障害というのはほとんど言葉の矛盾です。
ところが障害の原因が判明した事後からふり返ってみれば、その発生が必然であったことが分かる。
ここである種の人の中で時系列が逆転します。あのときこういう対応をしておけば障害は未然に防ぐことができた。なぜそれができなかったのか。
ある意味正しい反応です。好ましくない事象が発生したときにその原因を究明し次のアクションを取る。ヘビに噛まれて痛かったのならば次はヘビに噛まれないように用心する。しかし残念ながらシステム障害に対応するための方法論としてはいささか貧弱過ぎる。システムはあまりに複雑だし、人はあまりに不完全だからです。
障害に対応するためにはまずは人の不完全さを受け入れる必要があると私は思います。つまり事前に潰そうといたずらに体力をかけるのではなく（これは経済学の問題です）、事前に障害を出来るだけ出して直しておくこと。そして障害が発生したときの運用を確立しておくこと。それがもっとも効率的に障害に対処する方法だと私は思います。
2008年5月29日木曜日
Spring 2.5 AbstractWizardFormControllerを使ってみる（３）
Validatorを使ってみます。
【手順概要】
InputValidatorを追加します。
SimpleWizardControllerでprotected void validatePage(..)をオーバーライドします。
page1form.jsp、page2form.jspにform:errorsタグを入れ込みます。
springapp2-servlet.xmlにvalidatorの定義を追加します。
【手順詳細】
InputValidatorを追加します。
SimpleWizardControllerでprotected void validatePage(..)をオーバーライドします。
page1form.jsp、page2form.jspにform:errorsタグを入れ込みます。（太字部分）
（page2form.jspは省略しています）
springapp2-servlet.xmlにvalidatorの定義を追加します。（太字部分）
以上。
【手順概要】
InputValidatorを追加します。
SimpleWizardControllerでprotected void validatePage(..)をオーバーライドします。
page1form.jsp、page2form.jspにform:errorsタグを入れ込みます。
springapp2-servlet.xmlにvalidatorの定義を追加します。
【手順詳細】
InputValidatorを追加します。
package springapp2.service;
import org.springframework.validation.Errors;
import org.springframework.validation.ValidationUtils;
import org.springframework.validation.Validator;
public class InputValidator implements Validator {
public boolean supports(Class clazz) {
return AllValueForm.class.isAssignableFrom(clazz);
}
public void validate(Object obj, Errors errors) {
validateFirstPage((AllValueForm) obj, errors);
validateSecondPage((AllValueForm) obj, errors);
}
public void validateFirstPage(AllValueForm form, Errors errors) {
int id = form.getFirstId();
if (id == 0) {
errors.rejectValue("firstId", "", null,
"ID required (Other than 0).");
}
ValidationUtils.rejectIfEmpty(errors, "firstValue", "",
"Value required.");
}
public void validateSecondPage(AllValueForm form, Errors errors) {
ValidationUtils.rejectIfEmpty(errors, "nextValue", "",
"Value required.");
}
}
SimpleWizardControllerでprotected void validatePage(..)をオーバーライドします。
@Override
protected void validatePage(Object command, Errors errors, int page,
boolean finish) {
AllValueForm form = (AllValueForm) command;
InputValidator validator = (InputValidator) getValidator();
// errors.setNestedPath("order");
switch (page) {
case 0:
validator.validateFirstPage(form, errors);
break;
case 1:
validator.validateSecondPage(form, errors);
}
}
page1form.jsp、page2form.jspにform:errorsタグを入れ込みます。（太字部分）
（page2form.jspは省略しています）
<table width="95%" bgcolor="f8f8ff" border="0" cellspacing="0" cellpadding="5">
<tr>
<td align="right" width="20%">First id:</td>
<td width="20%">
<form:input path="firstId"/>
</td>
<td width="60%">
<form:errors path="firstId" cssClass="error"/>
</td>
</tr>
・・・略・・・
<form:errors path="firstValue" cssClass="error"/>
springapp2-servlet.xmlにvalidatorの定義を追加します。（太字部分）
・・・略・・・
<bean name="/page1form.htm"
class="springapp2.web.SimpleWizardController">
<property name="sessionForm" value="true" />
<property name="commandName" value="allValueForm" />
<property name="commandClass" value="springapp2.service.AllValueForm" />
<property name="validator">
<bean class="springapp2.service.InputValidator"/>
</property>
</bean>
<bean name="/page2form.htm"
class="springapp2.web.SimpleWizardController">
<property name="sessionForm" value="true" />
<property name="commandName" value="allValueForm" />
<property name="commandClass" value="springapp2.service.AllValueForm" />
<property name="validator">
<bean class="springapp2.service.InputValidator"/>
</property>
</bean>
・・・略・・・
以上。
「障害を許さない」プロジェクトが破綻する理由（２）
■「障害を許さない」スローガンの分析
ではなぜ障害は好ましくないと考えてしまうのでしょうか。今回は少し毛色を変えて「障害は許さない」という精神状態について分析してみましょう。
まず障害とは何でしょうか。
「常に予定外の出来事として発生するもの」
「通常の運用や業務を阻害するもの」
「不安を呼び覚ますもの」
「上司の思いつき」というのも一種の障害であることがよく分かりますね。
障害の原因という観点から整理してみましょう。
「ハードウェアの故障」
「ソフトウェアのバグ（時限系／タイミング系）」
「ソフトウェアのバグ（設計ミス）」
「ソフトウェアのバグ（ロジックの問題）」
「設計書のミス」
一次的にはそんなところでしょうか。
原因追求についてもう少しレベルを深くしてみましょう。
われわれ人間には実にさまざまな愛すべき欠陥があります。
「コミュニケーションミス」
「単純作業ミス」
「勘違い」
「思い込み」
「忘却」
「理解不足」
整理すると「人間の欠陥により」⇒「ハード／ソフトに欠陥が生じ」⇒「それによって予定外の通常業務を妨げる事象が発生し、不安を呼び覚まされる」ことが障害である、と言えます。
しかしこうしてみると「なあんだ。障害が起こるのなんてあったりまえのことじゃないか。所詮は人がやることでしょ」というふうに見えませんか？見えない？それは困った。
以上の文脈から言えば「障害が許せない」という人は「人間は確かに誤りを犯す。しかし障害は許せない」という考え方を持っていることになります。この考え方を二つに分けてみましょう。
（１）「自分のことはさておき他人の起こした障害は許せない」
（２）「自分の起こした障害だからこそ許せない」
（１）について。まあ確かに（例えば、ですよ）原子力発電所の運用をおろそかにされたりすると、これはちょっとけしからんと私でも思います。他人の安全を守るような仕事はきっちりやって頂きたい。
これを「他者糾弾タイプ」と定義します。
（２）は少し気の毒な考え方ですね。これを生真面目につきつめる人はうつ病まっしぐらかもしれません。適度な責任感を持って頂きたい。
こちらを「自己破滅タイプ」とします。
両者の資質を併せ持っているのが普通だと思います。後はそれぞれの傾向が強いかによってその人の性格を定義できるのではないでしょうか。
順列組み合わせによって４つのタイプが存在します。
タイプＡ【前者が強く、後者が弱い】
⇒ 自分のことは棚に上げて人のことをあれこれ言いつらうタイプ。
Ｂ【前者が強く、後者も強い】
⇒ 自分にも他人にも厳しいタイプ。
Ｃ【前者が弱く、後者も弱い】
⇒ テキトーな感じ。
Ｄ【前者が弱く、後者が強い】
⇒ 気の毒な感じですね。周りから利用されそう。
残念ながら悲惨なプロジェクトを推進する人には（また出世する人には）ＡやＢのタイプが多いような気がします。いずれにせよある意味で正義感が強く、間違ったことが許せないタイプと言えるでしょう。こうしてみると、プロジェクトがどんどん悲惨になって行くのもむべなるかな、という気がしないではありません。恐らく短期的には「失敗が許せない」と胸を張っていうような人こそがはびこり「だって人間だもの」と弱々しい声でつぶやく人はどんどん駆逐されてゆくでしょうから。
とまあ今回はなんだか救いのない話になりましたが、実は私は希望を失っていません。短期的には他者糾弾傾向の強い人が幅をきかせるかもしれませんが、そのような人がプロジェクトを破壊する可能性もまた高い。長期的には妥当な判断が出来る人が成功すると私は信じています。
次回は「不安」という観点から「障害を許さない」というスローガンについて考えてみたいと思います。
ではなぜ障害は好ましくないと考えてしまうのでしょうか。今回は少し毛色を変えて「障害は許さない」という精神状態について分析してみましょう。
まず障害とは何でしょうか。
「常に予定外の出来事として発生するもの」
「通常の運用や業務を阻害するもの」
「不安を呼び覚ますもの」
「上司の思いつき」というのも一種の障害であることがよく分かりますね。
障害の原因という観点から整理してみましょう。
「ハードウェアの故障」
「ソフトウェアのバグ（時限系／タイミング系）」
「ソフトウェアのバグ（設計ミス）」
「ソフトウェアのバグ（ロジックの問題）」
「設計書のミス」
一次的にはそんなところでしょうか。
原因追求についてもう少しレベルを深くしてみましょう。
われわれ人間には実にさまざまな愛すべき欠陥があります。
「コミュニケーションミス」
「単純作業ミス」
「勘違い」
「思い込み」
「忘却」
「理解不足」
整理すると「人間の欠陥により」⇒「ハード／ソフトに欠陥が生じ」⇒「それによって予定外の通常業務を妨げる事象が発生し、不安を呼び覚まされる」ことが障害である、と言えます。
しかしこうしてみると「なあんだ。障害が起こるのなんてあったりまえのことじゃないか。所詮は人がやることでしょ」というふうに見えませんか？見えない？それは困った。
以上の文脈から言えば「障害が許せない」という人は「人間は確かに誤りを犯す。しかし障害は許せない」という考え方を持っていることになります。この考え方を二つに分けてみましょう。
（１）「自分のことはさておき他人の起こした障害は許せない」
（２）「自分の起こした障害だからこそ許せない」
（１）について。まあ確かに（例えば、ですよ）原子力発電所の運用をおろそかにされたりすると、これはちょっとけしからんと私でも思います。他人の安全を守るような仕事はきっちりやって頂きたい。
これを「他者糾弾タイプ」と定義します。
（２）は少し気の毒な考え方ですね。これを生真面目につきつめる人はうつ病まっしぐらかもしれません。適度な責任感を持って頂きたい。
こちらを「自己破滅タイプ」とします。
両者の資質を併せ持っているのが普通だと思います。後はそれぞれの傾向が強いかによってその人の性格を定義できるのではないでしょうか。
順列組み合わせによって４つのタイプが存在します。
タイプＡ【前者が強く、後者が弱い】
⇒ 自分のことは棚に上げて人のことをあれこれ言いつらうタイプ。
Ｂ【前者が強く、後者も強い】
⇒ 自分にも他人にも厳しいタイプ。
Ｃ【前者が弱く、後者も弱い】
⇒ テキトーな感じ。
Ｄ【前者が弱く、後者が強い】
⇒ 気の毒な感じですね。周りから利用されそう。
残念ながら悲惨なプロジェクトを推進する人には（また出世する人には）ＡやＢのタイプが多いような気がします。いずれにせよある意味で正義感が強く、間違ったことが許せないタイプと言えるでしょう。こうしてみると、プロジェクトがどんどん悲惨になって行くのもむべなるかな、という気がしないではありません。恐らく短期的には「失敗が許せない」と胸を張っていうような人こそがはびこり「だって人間だもの」と弱々しい声でつぶやく人はどんどん駆逐されてゆくでしょうから。
とまあ今回はなんだか救いのない話になりましたが、実は私は希望を失っていません。短期的には他者糾弾傾向の強い人が幅をきかせるかもしれませんが、そのような人がプロジェクトを破壊する可能性もまた高い。長期的には妥当な判断が出来る人が成功すると私は信じています。
次回は「不安」という観点から「障害を許さない」というスローガンについて考えてみたいと思います。
Spring 2.5 AbstractWizardFormControllerを使ってみる（２）
「戻る」ボタンを実装します。
【手順概要】
page2form.jspにボタンを追加します。
confirmform.jspにボタンを追加します。
これだけ（！！）
【手順詳細】
page2form.jsp
formタグの中に以下を記載します。
confirmform.jsp
formタグの中に以下を記載します。
以上。素晴らしい。
＃補足
前回投稿のspringapp2-servlet.xmlで、下記をコメントアウトしても問題なく動きました。
逆にSimpleWizardControllerの以下をコメントアウトするとダメでした。
少し直感に反するなあ・・・
【手順概要】
page2form.jspにボタンを追加します。
confirmform.jspにボタンを追加します。
これだけ（！！）
【手順詳細】
page2form.jsp
formタグの中に以下を記載します。
<input type="submit" value="Previous" name="_target0">
confirmform.jsp
formタグの中に以下を記載します。
<input type="submit" value="Previous" name="_target1">
以上。素晴らしい。
＃補足
前回投稿のspringapp2-servlet.xmlで、下記をコメントアウトしても問題なく動きました。
<bean id="simpleWizardController"
class="springapp2.web.SimpleWizardController">
<!--
<property name="pages">
<list>
<value>page1form</value>
<value>page2form</value>
<value>confirmform</value>
</list>
</property>
-->
</bean>
逆にSimpleWizardControllerの以下をコメントアウトするとダメでした。
setPages(commands);
少し直感に反するなあ・・・
登録:
投稿 (Atom)