Yoshioriさんのターン。お姉さんが「僕が君を」のあたりを読み上げるときに班笑いになっていたのが面白かった。ステートフルのお話だけどRESTと競合したり敵対するものじゃないよというお断りから。というか受付で資料を受け取って驚いた。トナーがー

httpプロトコルはステートレス。COOKIEとかGETパラメータとかPOSTパラメータとか他のヘッダとかを使って擬似的にステートフルにできている。あとsessionにnullgwdocomoと書くと端末情報を入手できるのらしい。

ステートレスだけで処理しようとすると問題が起こる。[入力]→[確認]→[完了]と画面が推移するとき、ユーザが入力した情報をhiddenパラメータなどでクライアントに返してしまうと、確認の前と完了の前とで2回データチェックする必要が出てくる。

HTTPプロトコルがステートレスなのにアプリがステートフルを要求している。いまさらHTTPプロトコルは変えようがない。そこのギャップをフレームワークがうまく解決してくれる。

クライアントに値を返すとバリデートが2回必要になるとか、戻るボタン対策やダブルサブミット対策やマルチウィンドウ対策やF5対策などの問題をフレームワーク側で引き受けてくれるので、ビジネスロジックに注力できるようになる。逆にデメリットとしては学習コストがかかったり、選択肢が少なかったり、session乱発でメモリ使いまくりで負荷分散が大変だったりする。でもきょうび32ギガメモリとかフツーなので平気ですよね^^

次にJBoss Seamの話。JBoss SeamはJBossによるはじめてのフレームワーク。SeamはJSF(VとC)とEJB3(M)をつなぐGlue(糊)の役割。みんな大好きぎゃびんきんぐ。

そしてWicketの話。Swingのようなコーディングができて良い感じ。VとC。コンポーネント指向。HTMLとJavaだけで完結。XML使わないの最高。書いてると分かりやすい。

さてこれらのフレームワークに移行すべきだろうか。まずステートフルフレームワークの存在を認識してほしい。これらのフレームワークはかれた技術の集合であるRoRとは対極にあるものだ。ステートフルフレームワークを抽象的に理解することが大事。「具体的なこと」は本質を表していないことが多い。「すごい速い馬が欲しい」と顧客に言われたら車を用意するのがエンジニア。本質は「速く移動すること」だから。

最後のメッセージがとても心に残った。「みなさん発表しましょう! 間違えはマイナスにならない。文句よりどうしたいかを言うようにしよう。」ブログでもjava-jaや1000speakersなどのカンファレンスでも。そして「彼らを何とかする」