Java KücheコミュのSuperAgileWebDevelopment wih Seasar2

に参加してきました。(2007.1.25）

ひがさんの説明を聞きながら、ぱーっとメモした内容です。私の勘違いなどがあるかも知れませんので、そこはご容赦ください。
---
Java開発のストレス
　- ある程度つくらないと、実際の動作を確認することができない。
　　- 最初に動くものをつくるのが大変。

RoR のメリットとデメリット
　- スタートアップは早いが、大規模は無理。
　- 生産性は高いのか？なにかやろうと思ったら、書くことは少なくない。
　　- 簡単なことは、簡単にできる。
　　- 難しいことも、簡単にできる？これが生産性に直結する。
　- 間違えなければ生産性が高いのでは？
　　- コンパイラ言語の Type safe なメリットは、大規模で生きてくる。
　　- Eclipse があること = Java のメリットかも...
　　　- 自動補完、型チェック
　- デプロイ不要
　　- これが Java のデメリットとして注目されているのでは？

Java のメリット
　- パフォーマンス
　　- コンパイル時の最適化がいきてくる。
　- Type safe な面
　　- 存在しないメソッドを呼び出すことはない。
　- 固い言語は、IDE が発達している。
　　- スクリプト言語は、天才プログラマー向け？
　　
Java の生産性向上の視点
　- デプロイ地獄を解消する
　- Type safe はそのまま活かす

Seasar のホットデプロイ
　- ソースコード保存だけ！
　　- ほぼスクリプト言語と同じ
　- アプリケーションサーバをリブートする必要がない！
　　- 通常の JVM 仕様では、クラスローダが読み込んだクラスは変更できない。
　　- Seasar はテクニックを使って、これを実現した。
　　　- VM は、クラスが置き換わったことを *知らない*
　　　- 他の DI コンテナにはない。
　　　　ホットデプロイという概念は、Java では、はじめて。

デモ
　- 3 分間クッキング：盛り上がる。
　　- Eclipse の「Create a Chura Project」で、プロジェクト名を入れるだけ。
　　- DB のテーブルを指定する
　　　- テーブルからソースコードを自動生成する。
　　- Tomcat を起動する。（事前に起動しておいてもよい）

　これだけ。

　生成された CRUD アプリの特徴：

　- table の colgroup を使っている。縦、横のスクロールを固定させている。
　- 日付を入力「19801217」して、カーソルを移動させると「1980/12/17」となる。

　一方「リソース」系データは簡単だが、お客さんのこだわりは「イベント系」にある。

ところが実際の開発は？
　- テーブルが出来上がっている？
　　- ありえない...（会場：笑）
　- 最初は、HTML のモックアップでしょう。
　　- HTML 項目を正規化してテーブルをつくることが一般的な開発では？
　- 「Page駆動開発」と「Table駆動開発」の併用が大切

　- DAO のソースはとても短いのが良い。

　- DXO （ダックスオー）オブジェクトには convert メソッドがある。
　　Java コードをかかずとも Aspect をつかって、ページクラスの内容を
　　Domain Entity (JavaBean) に変換し、これを DAO に渡す。

　　BeansUtil とかをつかってもいいが、この DXO オブジェクトをつかうと
　　一階層ネストまでは自動で構造変換してくれる。
　　
　　インタフェースをつくるだけで、実装コードは自動生成されるという
　　のが Seasar2 で多用されている。
　　
　　DAO 自体のコードもとても短い。

デモ（２）Page 駆動開発
　- Eclipse から hello.html を作成
　- 「Dolteng」の「view HTML」プラグインを使って、Eclipse から
　　すぐに IE を呼び出せる。
　- 「Teeda」を使っており、この HTML は JSF として解釈される。
　　- faces.config をさわっていない。

　- ここで（Eclipseから）「Ctrl + F5」キーを押して、Java クラスを作成させる。
　　- HTML内にある <span id="name">...</span> を解析して、
　　POJO なクラス HelloPage.java が自動生成される。
　　何のインタフェースも継承していない。

　　# ただしいくつかのメソッドは決まった形で自動生成される。

　- ここでリロードすると、画面が変わる。
　　コンパイルも自動でやってくれる。

　- Javaソースコードを保存するだけで、動作させることができる。
　　Tomcat のリロードも、行っていない。

　- 再び「Ctrl + F5」で、HTML と Java コードを相互切り替えできる。
　　しかも span id タグが Java と結びついているというマークが
　　（Eclipse上で）つく。これで Java とのマッピングを確認できる。

　！質問！
　span/@id タグは、Webデザイナが CSS として決めたいのではないか？

　　-> 事前に打ち合わせた上で、CSS にも Seasar のルールを適用させて
　　　　ほしい。

　　-> id タグは AJAX でも重要。なので（項目名と同じという）ルールを
　　　もたせた方がよい。

　- 次のデモ：画面遷移

　　<input type="text" id="name"/><br/>
　　<input type="button" id="goTextOutput" value="submit" onclick="location.href='textOutput.html';"/>

　　という HTML を用意する。

　　"go" + 「次の HTML 画面」という表記が重要。これで画面遷移をしてくれる。

　- Struts の問題点

　　サーバサイドで forward を行うと、Web ブラウザの「アドレスバー」に
　　表記されている URL と、実際の画面が「一つずれている」

　- Seasar の解決

　　リダイレクトベースで動くので、URL = 画面となる。

　　一方で、この場合はセッションにデータを保存しないといけない。
　　（request にはデータが残っていない）
　　これを嫌がる人はいる。

　　この対策として、画面遷移が終わると、セッション内のデータを
　　自動でクリアするようにした。なので安心できる。

　　JBoss Seam も同じアイデアがある。conversation scope という概念。
　　start と end を指定できる。
　　しかしこの問題は、想定した start と end 以外の動きをされると
　　メモリリークとなる。（Spring WebFlow や Shale も同じ仕組み）

　　例：複数 Web アプリサーバがあって、一つのメニューから別の
　　　　サーバに遷移するなど。

　　Seasar2 では、このような（複数サーバの）例でも自動認識して
　　セッション内の情報をきちんとクリアする。

　- POJO の説明

　　画面の変更に強い POJO とするため、Abstract クラスを生成させ
　　変更を吸収させることもできる。

　- バリデータの利用

　　コードは書かないで実現。アノテーションを使う。
　　setter メソッドにアノテーションを仕掛ける。

　　@Override
　　@Required
　　public void setName(String s) {
　　　...
　　}

　　エラーメッセージ情報は HTML に書く。

　　<input type="text" id="name"/>
　　<span id="nameMessage"/>　
　　<input type="button".../>

　　メッセージの国際化にも対応している。

　　label_ja.properties を作成する。
　
　　name=名前

　　Java のリソースプロパティは通常、キャッシュするが
　　Seasar の場合、これもカスタマイズしているので
　　プロパティファイルを変更すると、即座に変更が反映される。

　- ラベル

　　HTMLに label 要素を加える。

　　<label id="nameLabel"/>

　　このあと、プロパティファイルを加えるだけ。

　- ダイナミックプロパティ

　　HTML のタグを動的に変えたい。テーブルの値に応じて、あるタグの、ある値を変えたい。
　　これまでは JSP の中に、動的に変えたいロジックを埋め込んでいた。

　　できればロジックはすべて Java 側で書く。

　　JSP の問題は、保存しただけでは型チェックされないこと。
　　コンパイルされれば、わかるが... よりタイプセーフ指向なら、Java 側でやるべき。

　　input のボタンに「do + 処理名」（例：doSubmit）とすると、go と異なり
　　メソッドを呼び出せる。

　　自動生成された page クラスには「doSubmit」が用意されている。

　　しかも doSubmit の戻り値は、「return HelloPage.class;」と書ける。
　　これでタイプセーフが、より確実になる。
　　（String で返すより、もっと安全）

　　# RoR と違い、タイプセーフの良さを確保するのが Seasar のコンセプト。

設定ファイル：

　設定ファイルを書いていない。faces-config.xml にも遷移情報がない。
　その代わり、すべて規約ベースで動作する。

　DI コンテナの設定ファイルも、このデモにおいては空であった。

セッション管理：

　複数のウィンドウを開いても大丈夫。「ウィンドウID」をもっている。
　Seasar 側でウィンドウを開けば、「newwindow=true」といった属性を
　指定することで、追跡管理できる。

　しかし IE の「New Window...」は認識できない。これはイベントをとれない。

ホットデプロイ：

　本番環境ではオフにすること。（クールデプロイと呼ぶ）
　これでパフォーマンスを上げることができるだろう。

　設定ファイル env.txt に「ut」とかくと Unit Test = HotDeploy になる。

　# この値を、実は dicon ファイルで判定させている。
　<include condition="#ENV == 'ut'" path="hotdeploy.dicon"/>

　ただし、ホットデプロイも、実際にはそんなに遅くない。

　仕組み：リクエスト毎にクラスローダが違う。クラスをキャッシュさせない。
　　クラスのタイムスタンプをみているので全読み込みではない。
　　もし、最初にクラス情報を読み込んでリフレクションのためのテーブルを
　　つくるようなアプリであれば、適用できない。

　　しかも要求されたときに、はじめてクラスロードするので、一回の画面で
　　10 程度であれば、ほとんど時間差がない。これをオンデマンドホット
　　デプロイと呼んでいる。

　Tomcat のリローダブルとの違い：
　　自分がよみこんだクラスのタイムスタンプを知っている。
　　時間が異なった場合、クラスをすべて捨てて、すべてのクラスを再読み込み
　　する。Web コンテナを捨てるので、これは結構遅い。
　　WebAppClassLoader, これは war 単位。関連する jar ファイルもすべて
　　再読みこみ。よって起動時間がかかることがわかる。

質問（１）：

　HTML 作成 -> Java コード生成後に、再び HTML をカスタマイズした
　あと、Java コードはどうなる？

　-> 現在は手動メンテナンス。しかし将来、自動マージする案がある。（すごい！）

質問（２）：

　自動生成された POJO に initialize といったメソッドがあった。
　これは何かのインタフェースを implements していない。これが Seasar 流。

　一方で、もしこのメソッド名をうっかり間違えた場合、このメソッドが
　呼ばれなくなる。（規約エラー）
　これは、Type safe という視点でいうと、どうなのか？

　-> Seasar 流でいえば、インタフェースより規約を使う。
　　ただし、IDE を前提としているので、このメソッドは Seasar の規約
　　として認識されている、というマーキングをするといった
　　手は考えられる。

質問（３）：

　動作している最中のホットデプロイで、request に入っていた変数などは
　残るのか？

　-> 残る。（すごい！）
　-> ただし static 変数については、やらない。どうなるかわからない。

質問（４）：

　Spring についてどう思う？

　-> 設定ファイルを書いた方が安心という人は Spring がいいのでは？
　　実際に、それを望む人はいる。
　　プロダクト自体の優劣は、ないだろう。

質問（５）：

　ホットデプロイを使いたければ、Seasar ファミリーで固めるしかないか？

　-> Yes。

　ただし Seasar2 は、EJB3 のコンテナでもあるので、標準フレームワーク
　といえる。JSF + Stateless Session Bean + JPA + ホットデプロイを実現
　できる。これができるのは Seasar だけ。これを Easy Enterprise と呼ぶ。
　ただし、Seasar としては Super Agile をお薦めする。

　JPA の実装は Hibernate 3.2 を使っているが、遅い。
　Seasar でも独自に JPA 実装をつくろうと思っている。（構想）

　ただし今は Hibernate を使っているせいで、Entity の部分はホットデプロイ
　に対応していない。他のフレームワークを混ぜると、そういう問題もある。