Seasar Conference に行ってきた。会場は法政大学ボアソナードタワー26F。
飯田橋駅構内でまた道に迷った。春に一度来た場所なのに。
会場は見晴らしがよい。
会場に着くとメイドさんが歩いていた。 予告 通り無料ドリンクサービスをやっているらしい。
50分×4コマのそれぞれにつき、5つのセッションを平行して催すのでどれにしようか迷ったけれども、どうにか絞り込んだ。
会場の様子
Seasar 2.4
ひがやすをさんから、前日にリリースされたSeasar 2.4と、これまで詳細が明らかではなかった"Chura"について。最近のweb開発には"agile"と"enterprise"の2つの大きな流れがあるけれども、seasarはその流れの中でどう進んでいくのがが説明された。
まずagileはRailsに代表されるもので、ひがさんはこれらをスピード感を出すために独自仕様も辞さずに突き進むものだとする。一方のenterpriseはEJB3/JPA/JSFに代表されるもので、大手ベンダーが仕様を練った上で提出されるものであり安心感を持てる技術であるけれども、その分、委員会てきな玉虫色なものになってしまいがちであるとする。
ひがさんは、一開発者としては独自仕様でイノベーションを追求したいけれども、ユーザーの立場を考えるとそれも善し悪しであるという。つまり、独自仕様で属人的な性質が強い製品はその人がいなくなった時が怖いし、教育コストという面でも標準化されたもののほうが嬉しいという。
そのような考えから、seasarではどちらの流れも捨てることはないそうだ。
- まずは、"super agile"として、agileの流れに乗って徹底した改善を目指す
- 一方で、"easy enterprise"として、標準技術の使いづらい点を直すとともに、"super agile"で得た技術や知見を還元していく
思想
"super agile"と"easy enterprise"の両路線に共通するのは3つだそうだ。
- All in one
- 規約重視
- さくさく感のある開発
All in one
All in oneはrails使いにはおなじみのフルスタックの利点ということである。これまでは問題領域ごとに様々なフレームワークが存在し、それらを組み合わせるのに独特のノウハウが必要であった。個々のフレームワークごとに思想の違いがあるので、そのギャップを如何に埋めるかも問題であった。例えば、HibernateとSpringの組み合わせはよく用いられるが、HibernateがAnnotationを重視するスタイルであるのに対し、Springは設定ファイルのほうを主に使用するスタイルであり、思想がこのレベルからして異なっている。
この状況は組み合わせの自由度があるということではあるが、ユーザーが迷うことも多い。そこでseasarではフルスタックのフレームワーク群"Chura"を提供し、一つの開発哲学をパッケージングして提供する。なお、Churaは沖縄方言で「美しい」という意味ということだ。seasarの慣例に従い、沖縄関連の名称である。
Churaは単一のフレームワークではなく、seasar 2.4を中心としてフレームワークをパッケージングしたものだそうだ。一連のフレームワークはEclipse拡張であるDoltengを通じて配布されるので、インストールや構成に悩む必要はない。
Super Agile向けにはSeasar 2.4, Teeda, Uuji, S2Dxo, Dolteng, Diiguを組み合わせる。Easy Enterprise向けには、これに加えてKuinaDao, S2Hibernate-JAP, Hibernate-JPAを用いる。
- Teeda : SeasarのDI + AOPと相性のよいJSF実装
- Uuji: 旧S2Daoを引き継いて、簡単にDAOを実装できるようにしたもの
- S2Dxo : ドメインロジックとビューのレイヤー間を橋渡しするDXO(Data eXchange Object)を、S2Daoと同様に宣言的に記述できるフレームワーク
- Dolteng: Chura開発を徹底的にサポートするEclipse Plugin
- Diigu: Javaの引数名情報をclassファイルに埋め込み、利用するもの。churaのスタイルでは、テープルのカラムと引数名を対応させてSQLテンプレート中のパラメータに対して一々引数を明示的に指定しなくても良いなど、引数名を積極的に利用する。通常classファイルには引数名情報が書き込まれていないのでそれを補う。
- KuinaDao: JPA(Java Persistence API)をより使いやすくするためのフレームワーク。JPQLを書かなくても宣言的にDAOを構築できる。
規約重視
これはSeasar 2.3のころからずっと言っている話だ。 未踏ソフトウェアの報告会 の席でも言っていた。
フレームワークは利用される様々な場面に応じて要求に応えられるよう、柔軟性を確保して作らねばならない。けれどもその結果として設定ファイルが随所に必要となり、大規模開発では設定ファイル地獄をもたらす。そこで、RailsでいうConvention over Configrationの思想を用いて設定の必要性を減らす。
あ、そういえば、Convention over Configurationという思想については、日経ソフトウエア2007年1月号に書かせていただいた原稿でちょっと触れてる。ひがさんのお話は原稿を書く前に聞きたかったね。
さくさく感
スクリプト言語の良さを取り入れる。
ひがさんによれば、スクリプト言語の良さの1つはファイルをサーバーに置けばすぐに認識される手軽さだということだ。その結果としてTry & Errorで開発できる。
一方、Java開発ではコンパイルして、jarやwarにパッケージングして、デプロイして、サーバーを再起動するという手間が必要となり、大変面倒である。手順が面倒なので最初からある程度完成度を上げておく必要があるけれども、現実には最初からきちんと動かすことは難しい。難しいことをやろうとするから心理的プレッシャーが掛かる。その結果として開発が楽しくない。
リブート中などに無駄な待ち時間が発生することで開発のリズムも悪くなる。思考が中断して、思いついたアイディアが失せてしまう。
スクリプト言語の生産性の高さとは、こういった問題がないことであろうとひがさんは指摘する。一方、Javaの良さとは何だろうか。
まずコンパイル時の最適化であるとか、静的な型チェックが挙げられる。Javaの堅さによって堅い開発が可能となっている。そして、IDEの支援もある。IDEと言語は直接は関係ないが、型が静的であることがIDEの実装を助けている面はある。IDEによって自動補完やリファクタリング支援、保存時の自動コンパイルなどが可能となる。
Javaは、さくさく感がない分は堅さでカバーしていると言える。では、そこにさくさく感をも加えれば更に良くなるであろうというのがひがさんの発想だ。Seasarはそれをサポートする。
- Hot Deploy: アプリケーションを稼働させたままクラスの変更を反映できる。classファイルを上書きすればそれだけで認識されるので、Eclipseでソースを保存すればすぐにアプリケーションに反映されることになる。
- ページ駆動開発: Goyaなどの開発プロセスに基づき、画面のプロトタイプに基づいてコード生成を積極的に使用する開発スタイル
- テープル駆動開発: マスターのメンテナンスのように、業務画面には直接は結びつかない部分を拾ってページ駆動を補う。既存のテーブル定義に基づいてコード生成を積極的に使用するスタイル。
実演
Webアプリケーションを3分で作って見せた。Doltengプラグインを活用する。
プロジェクトを新規作成
プロジェクトの種類としてChuraプロジェクトを選択
- メニューから、Tomcatにコンテキストを登録。
- Tomcat起動: Hot Deployがあるので、ここで起動してしまって良い。
- 既存のテープルからscaffold。従業員マスターに対する管理機能を作って見せた。Rails同様、モデルとなるテープルを選択するだけ。
動かしてみる
HTMLに対するメニュー項目拡張として、"view on server"などが追加されている。これでブラウザが起動してそのページを開くことができる。このような細かな点まで操作性を追求している。
Ctrl+5を押すとviewテンプレートと対応するJavaソースを行き来できる。
これまではある程度完成させないと動かせなかった。seasar 2.4では、とにかく動かして、機能を足せる。
以上はテープル駆動の場合の実例であった。一方のページ駆動の場合
- HTMLモックを作成
- 動的にしたい部分にid属性を与える。例えばspan要素に入れ込んだり。
Ctrl+5を押す
対応するJavaソースがないので、新規作成ダイアログが現れる。
- クラス名等はHTMLの名前に基づいて予め埋まっている。ユーザーは規約からは導出できない部分だけを指定すればよい。
idを振ってある要素は動的要素の候補として表示されているのでユーザーはそこから選択してbeanのプロパティを作成すればよい。
もちろん再起動する必要もなく、ブラウザ側でリロードすれば先ほどspanで括った部分がbeanプロパティの値に置き換わっている。
Dao/Dxo
ここで、先ほど従業員マスターEMPから作成したソースを見てみる。packge構成規約に基づき、プロジェクトのrootとなるパッケージの下、daoパッケージの下にDaoの定義がある。定義があると言っても実装までコード生成されているわけではない。只のインターフェースだ。
GenericDao interfaceを継承するEmpDao interfaceが生成されており、そこに規約に基づく名前のMap[] findAll()などがある。このように規約に基づいて命名し、interfaceだけ宣言しておけば実装はSeasarのAOP機構を通じてフレームワークが差し込んでくれる。ユーザーはDAOを実装する必要がない。
さて、ここではDao部分にUujiを使用している。Uujiの場合、findAllのように返り値の型はMapである。ページに流し込むだけならばMapのほうが柔軟だろうという判断によるが、Strong Typedな利点を用いる場合も考慮されている。MapからStrong Typedなクラスに変換するのがDXOの役目である。DXOもまた、S2Dxoでinterfaceさえ宣言しておけば実装はフレームワークが作成してくれる。
ちなみに、DXOはどう発音するのかと思っていたら、「だっくすおー」らしい。
このように、開発者が書くべきはHTMLテンプレートに値を渡すbean(Churaの用語ではPageクラス)だけである。しかし、PageクラスにしてもDoltengでHTMLモックからダイアログで作成するだけである。
