先月から月1回のペースで始まった本日の「JavaナイトセミナーVol.2」は、ひがさんによる「Super Agile Web Development with Seasar2」です。
夜6時30分より、ビールで乾杯から始まりました。
「最近Javaが元気ないね」から始まり、Ruby on Railsが持ち上げられているポイントを3点整理し、JavaでもJavaの言語のよさを含めて高いWebアプリケーション開発の生産性をSeasar2で実現していますよ、という内容でした。
Webアプリケーション開発にはほとんど携わったことがないので、今回の話はかなり新鮮かつ細かいところは分からない部分ありました。ですが、高い生産性の鍵としてひがさんのいうところの「ステップ by ステップ開発」をフレームワークやEclipseプラグインの合わせ技で実現しているSeasarの思想にはとっても共感しました。
セミナー内容のメモ
JavaでWebアプリケーション開発にあたってLL（Light Weight Language：スクリプト言語)に比べて生産性が悪いと言われる最大の理由が「デプロイ地獄」とのことです。Webアプリを修正して実行し結果を確認するには、ビルドしてアプリケーションサーバーにデプロイするので時間がかかって効率が悪いのが現状です。Seasar2.4では、このデプロイ地獄を解消するために、ホットデプロイ機構を設けて、アプリケーション・サーバーを再起動したり、Webアプリケーションを再デプロイし実行しなおすことなく、修正したクラスを差し替えて動作継続できるようにしています。
スクリプト言語については、間違えなければ素早く開発できるが、大規模に作ればどうしても間違いが入ってしまう。エラーの修正は固いJavaに比べると大変です。Javaはタイプセーフにより間違いを動かす前にコンパイル時（Eclpiseなどのツールなら保存時に！）検出できます。
Seasarでは、RDBMSのテーブルからスカフォルド（アプリケーションが動くための土台）を自動生成する「テーブル駆動開発」と、HTMLに仕込んだタグ属性から同様にスカフォルドを生成する「ページ駆動開発」が用意されており、適材適所で使い分けられるようになっています。
この威力は、とにかく動く仕組みを短期間で（デモでは3分間で）作り上げ、あとは動かしながら開発していくスタイルを取ることで開発者の生産性を押し上げることにあります。テーブル駆動の開発ではテーブルからCRUDアプリを一発で作れます。
それまでのJavaでは、一生懸命プロジェクト設定・ライブラリの組み込み・JSPとBeanを記述してさあビルド・デプロイして動かしてみると、大抵は悲しいエラー画面でデバッグから始める
ことになるという逸話で違いをイメージアップできるよう紹介していました。
テーブル駆動はRuby on Railsと同様の仕組みでデモ効果も高いですが、Webアプリケーション開発の多くは画面モックを顧客に見せて、そこからデータをDBへ落としていくので、テーブル駆動開発が当てはまるのはリソース系（マスターデータ？）であり、イベント系はHTMLから作っていくページ駆動が適しているとのことでした。
ここまでで、最初にテーブル駆動開発のデモ、ページ駆動開発のデモが行われています。さっと作ってさっと動かすことの威力は、実際に見てみないと実感できないので、このようなセミナーなどで見るのはよい体験になります。
デモでは、開発便利機能（テクニック）もちりばめられており、生産性向上にはフレームワークだけでなく開発環境も重要というメッセージが伝わってきました。
あとは技術用語の羅列になりますが、
- HTML上にID属性を付け、そこからJavaのコードを生成するやり方。Javaクラス生成ウィザードでID属性で指定した名前をフィールドに追加する
- TeedaフレームワークはJSFを使っているが、JSFを意識しないでJSFのコンフィグファイルは記述不要
- HTMLに画面遷移機能を持たせることができる(サーバへ問い合わせずに）
- JavaのソースコードをEclipse上で保存した時点で起動中のWebアプリケーションに反映（アプリケーションサーバの再起動不要、再デプロイ作業不要）
- HTMLとJavaのEclipse上での表示切換はキー一発
- Eclipse上でJavaソースのHTMLと結びついている属性が確認できる
- 顧客との画面仕様調整時を主とした画面モックで画面遷移を実現する仕組みがあり、サーバーがなくてもHTMLリンクをたどった遷移が可能
- forwardだとWebブラウザのURL表示は変わらないまま画面が変わるので、redirectベースで遷移（セッション経由で次の画面にデータをつなぐ）
- 必須入力はアノテーションで指定（フィールドに@Required）
- バリデーションエラー出力箇所の指定はHTMLで（span）
- JSPはHTML中にロジックが入るためタイプセーフを生かせずデメリット大。SeasarはJava側にロジックを持つ
- 処理をはさみたい場合は、HTML側にIDでdoXXXを記述、ページ遷移はgoXXXを記述。Java側ではdoXXXの戻り値にClass型を指定可。そのクラスのページに遷移する。
- JSFConfigも書いていない
- ウィンドウまで把握しているので、違うウィンドウ・違うブラウザの認識可（Cookieで実現）
- ホットデプロイは本番環境ではOFFにする想定。
- ホットデプロイの実現は、リクエスト毎にクラスローダーを変更しているが、オーバーヘッドを小さくするため血みどろの努力が裏にある
- Tomcatもリローダブルだが、Tomcatはクラスローダーでロードしたクラスのタイムスタンプを全部覚えておき１つでも変更があると全てを捨て再構成している（war単位）。サーブレットだけなら軽いが、DIコンテナを使っているとコンテナ全ての初期化も必要となってしまう。
- Javaクラスのウィザード生成後、HTMLを修正したら今は手でJava側を修正する必要がある
-
：
