Seasar Conference 2008 Autumn に行ってきました。
Seasar Conference 2008 Spring のときと同じ会場だと勘違いして、時間に余裕を持って到着してベンチで寛くぜーとかやってたら、なんか人少ないなーと気付いてケータイで調べたら、会場別の場所なことに気付いて慌ててダッシュしたのが俺。前回 は雨に降られてコンビニまで傘買いに走ったりと、Seasar Conference はよほど俺にダッシュさせたいらしい。
セッションごとのレポートに入る前に、気になったこといくつか。
あの会場の椅子、ビミョーに座り辛かった。ちょっと体勢を前に傾けると、お尻が浮いてガクッとなるんだよね……俺だけ？
これは会場に来た人しかわかんないだろうけど、アンケートで笑った場所が一点。他の人は軒並み「○○のプロダクトを使ってみたくなりましたか？」「○○に興味を持ちましたか？」なのに、某セッションだけ「差をつけたくなりましたか？」でお茶吹いた。
各セッションごとのレポート冒頭に、はてな id や blog の URL 分かってる人については書いてます。省略してる場合は、単に知らなかったり調べてなかったりと手抜きしてるので、ご容赦願います。
以下、トークセッションの内容について＆毎度のお断り文句。自分の所感・意見と登壇者の発言やプレゼン資料の内容ごちゃ混ぜに書くので、読みにくい点が多々あると思います。日本語崩壊してる部分も多々です。自分用の備忘録的な意味合いの強いエントリなので、そのあたりの読みにくさについてはご容赦願います。
SAStruts と S2JDBC の最新機能
スピーカーは id:higayasuo と id:taedium によるセッション。
まず、SAStruts & S2JDBC を開発するに至った背景として、Seasar2 の歴史のカンタンなおさらいから。Seasar 2.4 のころは Teeda + S2Dao で売っていたが、使い続けている内に様々な問題が出てきた。サクサク感が出せてないなぁ、とひがさんが感じた、というのが一番の問題*1、と俺は受け取った。
2008/9/8 1900 頃追記
ひがさんに突っ込まれました。
かなり間違って受け取ってるなぁ。確かに、オラクルでS2Daoを使うと、データベースのメタデータを毎回とりに行く部分が遅いので、HOT deployがさくさく行かないという話はしたけど。
TeedaとS2Daoは、基本的に規約ベースのフレームワークです。規約を知っていれば、本当にさくさく開発できます。でも、規約ベースなので、規約を知らないと、何にもできなくなっちゃう。この辺が、大規模開発には向かないところ。
小規模で、みんなで気楽に質問し合えるような環境だと、知らないときは、誰かが答えてくれるんでいいんだけどね。
SAStrutsとS2JDBCは、大規模案件にも耐えられるように最初から設計されています。
（中略）
しまった、肝心なこと書き忘れてるんじゃん、俺 orz 「SAStrutsとS2JDBCは、大規模案件に耐えられるように作ったのです」は理解してるつもりだったけど、これはひどい文章になってる。なので、これはひどい文章はそのまんまにして、指摘していただいた部分をそのまんま引用しておきます。
2008/9/8 1900 頃追記部分ここまで
そして、Seasar 利用者からの意見や、ひがさん自身が収集した情報を分析した結果、S2Struts の代わりに SAStruts、S2Dao の代わりに S2JDBC を開発した、とのこと。キーワードは、大規模な開発に耐えられる Web アプリのフレームワーク。ねらいは、Web アプリのフレームワークの学習コスト削減。学習コスト削減の一例として、SAStruts は struts-config.xml レス、S2JDBC は、lazy loading を意図的に簡素化、などを挙げていた。
SAStruts の新機能について。scaffold の実装。scaffold とは、最近の LL 系フレームワークや Teeda 触った人にはおなじみなんだけど、DB テーブルの CRUD というかマスターメンテナンス系機能を、画面周りのコードから DB アクセスまでを自動生成してくれるもの。
S2JDBC の新機能について。S2JDBC-Gen の実装。Java のエンティテクラスと DB のテーブル構造を自動でマッピング取ってくれる代物。Rails の Migration に近いものを Java で実現してくれる（予定？）モノのようだ。
ちなみに、デモで個人的に喜んだ点が一つ。それは Dolteng の改良。presentation と persistence が別々に選べるようになっていた。知らなかった俺乙、って感じなんだが、これは地味ながら喜んでる人多いと思う。Teeda + S2JDBC や SAStruts + S2Dao を選択したい人は少数ながらも居ると思うんだよね。自分で設定すればいいとはいえ、それを Dolteng がプロジェクト作成の時点でサポートした点は個人的に評価している。
scaffold のデモ。scaffold は Database View から選んで……といった感じだったので、Teeda と似たような流れなのかな？
次に、S2JDBC-Gen のデモに入る前に S2JDBC のカンタンな説明。Java のクラスに @Entity のアノテーション、プロパティに @id とか付ける。使い方は、jdbcmanager.from("").where(""); とか、そんな感じ。
DB の管理に関する問題について。データベーススキーマとかの変更と Java のクラスをマッピングの整合性を取る作業には、人為ミスの入り込む余地があるため、そこが問題である、と。
S2JDBC-Gen について。Java コードを中心として開発を可能とするツール。DB のテーブルを変更して Java のクラスを変更して……ではなく、Java のエンティティクラスを変更するだけで、あとはツールが DB との整合性を取ってくれる、というイメージ。
S2JDBC-Gen のデモ。Ant ターゲットを実行すると、まず Entity クラスなどが自動生成される。次に、Java の Entity クラスにプロパティを追加する。この状態で、もう一度 Ant ターゲットを実行。そうすると、DDL*2の自動生成と、その時テーブルに入っていたデータが CSV でダンプされる。この状態で、Ant の migrate ターゲットを実行するとテーブルも変更される。この時、先にダンプされた CSV に、追加したプロパティ用のデータを追加しておけば、初期データも復元＆追加できる。そして、Java と自動生成された DDL と、ダンプされた CSV をバージョン管理システムで管理する。
次に、こうしたツールを使う場合、従来とは少々異なる開発体制を取ることになる、といった点について。各開発者ごとの PC に開発用 DB 入れる必要があるけど、これはマシンスペック上それほど問題にはならないだろう、と。
大きいのは、DBA の役割が変わってくる点、とのこと。テーブルの変更を、開発者が DBA に変更依頼するんじゃなく、開発者が Java コードをいじるだけになる。
……てことは、テキトーなリリースのタイミングで DBA がテーブル構成の確認とるだけ、になるのかな？ うーん……日本だと欧米と違って、DBA とチームリーダーがゴッチャになってるケースが多いらしいから、悲観的な態度取るリーダーだと受け入れてくれないかも。こういう考えの人たちって、良くも悪くもプログラマーを信用してないから。良くも悪くも、って書いたのは「テーブルはグローバル変数のようなもんなんだから、早々簡単に変更入れちゃダメだろ」って思想のことね。あー、俺って結構悲観的な思想の持ち主なんだなぁｗ Jiemamy の記事読んだ時に「DB テーブルも積極的にリファクタリングしちゃおう YO!」なノリに SUGEEE と思いつつ、どこか懐疑的だったのはこういう考えが奥底にあるせいみたいだな。
Jiemamy は構成管理というべきか、プロジェクトのライフサイクルにより重きを置いてるイメージ（データベースもアジャイル開発に対応したい！ のみを読んでのイメージ）だけど、S2JDBC-Gen は、よりコードに重点を置いて「開発をラクにする」を実現しようとしているように感じた。
T2 - WEB 2.0 Connector -
スピーカーは id:shot6 によるセッション。
T2 だとはてなキーワードなどで映画の「ターミネーター」とかもひっかかってしまうので、スピーカーは、主に T2Framework で観測しているとのこと。そのため、blog 等では T2Framework で書いて欲しい、と前置きしていました。
T2 とは？ 部品化指向、フルスタックの逆の考え方。小さいフレームワークを組み合わせて使うほうが、現場では使いやすいのじゃないだろうか、と。T2Framework は Web のフロント部分に特化している。Servlet だけではプリミティブすぎることもあり、キレイな URL など Web2.0 的なところにもフォーカスを当てている、とのこと。また、あまりガチガチに REST の原則に従い過ぎると逆に開発し辛くなるのでは？ 的な発言もしていた。
T2 がやることとは？ Web のフロントをリッチにする。特徴は、ステートレス、マルチビューフレームワーク、保守性など。ステートレスにしたのは、ステートフルにするかどうかは相当悩んだとのことが、ステートレスの上にステートフルの皮をかぶせるのは比較的ラク、だが逆は難しいのでは？ との判断をした、と。マルチビューフレームワークとは、Flex や Silverlight など、個別のテンプレートエンジンには依存しない。保守性とは、T2Framework は規約よりアノテーションを重視する。規約は多すぎるとと覚えきれなくなり、逆に制御が困難になる、といった自身の経験からそうした、と語っていた。
T2 がやらないこととは？ Web と接続するところ以外はやらない。挙げていたのは、バリデーション、自動コンバーション、リッチコンポーネントの開発。バリデーションについては、エラーメッセージ表示等が代表的なように案件ごとの差異が多いため、そもそも共通フレームワークは作りづらいのではないか？ と。自動コンバーションは、HTTP で通信される値はすべて文字列なので、基本的にはユーザー任せにすべきなのではないか、と。ただし、マッタクやらないのはそれはそれで非効率的なのでバランスが重要、このため、アノテーションで明示的に示されない限りはしないようにした、と。リッチコンポーネントの開発は、要は、すごい DataGrid みたなのは作りませんよ、という意味。
RIA 時代の到来について。時代は再びクライアントサイドテクノロジーが注目される時代へ。ただし、昔と違うのはあくまでも Web のテクノロジーをベースにしてる点。フロントエンドは、旧来の HTML ベース, Flex/AIR, Silverlight, ExtJS など様々なテクノロジーがあり、通信形式も REST/JSON/POS/AMF と多種多様。つまるところ、クライアント資源の有効活用が再び脚光を浴びるフェーズに入っている。……なぁんか、業務アプリ汎用機から VB などのクラサバ、そしてオープン系（死語）に移行してった流れを思い出しますよねぇ。Web を基盤技術に置いてる、という違いはあれどもね。
RIA 時代のアーキテクチャと T2Framework の目標。HTTP,AMF,XMLHTTPRequest など、多様な形式のリクエストを抽象化し、サーバーサイド側（しかも既存の―特に HTTP ベースの―とも折り合わせの出来る）と接続する。
T2Framework の基本モデル。基本は、URL と POJO をマッピングする。アノテーションでマッピングを指定する。アノテーションの種類は、HTTP の各メソッドに対応するもの、@ActionPath @ActionParam @Default などの説明をしていたが、つまるところ URL とメソッドとの対応付けの制約をつけるもの、と考えてよさそうだ。@Ajax, @Amf は XMLHTTPRequest を処理するもの。ワザワザ別物にしたのは、Ajax 的なものは HTTP 的なものとは異なり、より細かい制御―即応性などのパフォーマンス―が求められるのでは、と考えたため。
引数の解決・メソッドの戻り値について。Forward, Redirect, Direct, JSON とか。まぁ、この辺はみたまんまだと思うので省略。
残りの時間でデモ。以下、デモ見ての個人的な意見色々。Flex-Java の通信のとこは、S2BlazeDS なみにラクになってほしいなー、てか既になってるっぽいなぁｗ ガワが Silverlight（+C#） でも サーバサイド側は Java っての驚いたりした。
ところで。超個人的な意見だが、現状 Seasar 関連テクノロジーで Flex-Java 使いたいなら……
- S2Flex2 - Flex 2 なら（タブン）コレ使うしかないんだが。ハイパー安定性重視ならコレ。主として業務アプリで使われてるせいか、Web にはアンマリ情報出てないっぽいけど。なので、それなりに枯れてるようです。
- S2BlaseDS - Flex 3 ならこっち。おそらくまだ採用案件は少ないだろうけど、BlazeDS の激薄ラッパーに過ぎない―jar のサイズ的にも―から、安定はしてると思う。ただまぁ、デカい案件の場合は Adobe さんにお金払いましょうｗ
- T2Framework - 個人的には、将来的にはコレかな、と思う。サーバー側に比べて流行り廃りが激しいフロントエンド側を移行しやすい点を視野に入れてる点が魅力的だしね。
Seasar の中の中
この時間帯、どこいこうか迷ったんですけどね…… java-ja 的な意味で。差をつけたくもなったし、ノート PC が爆発する様子も見たかったし、わんくまの人の話も聞きにいきたかったし。あと、みんな各セッション中に twitter しすぎだから！
それはさておき。
本セッションは、Javassist - Java バイトコード変換器、の説明が主体になる、とのこと。Javassist は、S2Container(主に S2AOP で) の実行時に Java のバイトコード書き換える部分に使われている。
最近、バイトコード変換を行うソフトウェアが増えている。S2Container を始めとして、Hibernate, JBoss, JRuby など。これらは非常に便利なんだけど、バイトコード変換部分はブラックボックスである。内部を意識せずに便利なものが使えるようになるのは良いことなのだが、技術者としては不安＆好奇心が沸く部分でもある。
そこで、Javassist を理解すれば、Javassist を使用している S2AOP のブラックボックスの理解の一助、トラブルシューティング、チューニングに役立つ…かもしれない。あと、なんか面白そうですよねーといったところが、本セッションのきっかけになった、とのこと。
S2AOP でどのように Javassist が使われているか、について。大まかな流れは、指定されたクラスネームのバイトコードを新規作成、コンストラクタのバイトコードを生成してクラスに追加、メソッドのバイトコードを生成してクラスに追加、クラスのバイトコードをバイト列に変換、といった手順をとる。Javassist 使用部分のコードを示していたが、API によってバイトコード変換・編集を意識させないのが Javassist のすごいところ。
API の見た目は Reflection API っぽい。……うーん、フツウの Java コードで透過的にバイトコード変換・編集できるのがスゴいところ、ってところかな？
Javassist の CtClass について。CtClass は Compile-time Class の略。1 つの class ファイルを表現するためのクラス。ユーザーは、このクラスのオブジェクトを通して、バイトコードを生成・編集する。また、同クラスはクラスファイルの構造も保持している。
ClassPool について。CtClass オブジェクト生成の API で、CtClass オブジェクトのコンテナ的位置づけ。クラスファイルの探し先は、無論、-classpath で指定されたのが検索パスになる。
CtMethod について。新規メソッドをクラスに追加できるんだけど、メソッド宣言をソースコードで書ける。つまり、String 表現のメソッド宣言を動的にクラスに追加*3できる。また、Javassist は独自の簡易コンパイラを持っている。
続けて Javassist の深いところ話してたんだけど、ちょっとついていけなくなってしまったので以下省略（情けなや
Teeda 再考 - 使い方から拡張方法まで -
卑猥なパンの人のセッションをあえてスルーしてこっち聞きにきました。*4
スピーカーは id:yone098 によるセッション。
Teeda について。ここは Seasar2によるスーパーアジャイルなWeb開発 (WEB+DB PRESS plusシリーズ) の本読むのが良いと思うので省略。書くのメンドイとも言うが。ただ、Teeda は日本［初|発］の JSF 実装、というのは知らなかった。
PRG(Post Redirect Get) パターンについて。これは、URL と実際に表示される html がズレないようになる、などの利点がある。
Teeda でのハマりどころについて。Page クラスのメソッドが呼ばれない現象の原因の一つに、親クラスが abstract になってないとだめ。独自ファイルを作った場合は、ちゃんと dicon に自分で登録しないとだめ、などなど。*5
メモリリークについて。S2ContainerFactory.create() をリクエストの度にコンテナ生成はやってはいけない。これは、雑誌・書籍の例をそのまんまやってるんだろう、と安易なコピペが及びす危険性を指摘してました。解決策としては―こういうことをしたいケースはほとんど無いだろうと前置きしつつ― S2Container のインスタンスを DI してもらいましょう、と。
Teeda のライフサイクルについて。JSF と絡めて理解しようとすると厄介だけど、フツウに使う分には、とりあえず脇に置いておけば良い。
Teeda の多機能性について。ダブルサブミット防止は、doHoge を doOnceHoge に変えるだけ。バリデーション―@Required とか―/コンバータのボタン指定は、target で指定した id のボタン押下時のみに設定できる。
Teeda in Ajax について。メソッド名は ajaxHello みたいに prefix を ajax にする。javascript 側からは、サブアプリケーション名 + "_" + Pageクラス名 + "_" + メソッド名、で呼ぶ。
Teeda の DI について。Cookie や HTTP のヘッダー情報 も HttpServletRequest みたいに、public Map cookie, public Map Header っていう public 変数を定義すれば DI してくれる。
どうしても現象がわからん場合の Tips について。blog に書く、ML で聞く、2ch にカキコ。
Teeda の拡張について。気合入れれば色々拡張できますよ、とのこと。挙げていたのは、独自バリデーション/コンバーション、フェーズへの処理差込方法、TeedaAjax の拡張、SMART Deploy を使わない、Oval でバリデーション、カスタムコンポーネント作成。
独自バリデーション/コンバーションには、Web に情報が結構あるらしい。フェーズへの処理差込方法は、PhaseListener ってのを使って、phases.config.xml に登録する、とかなんとか。TeedaAjax の拡張は、prototype.js 使う場合とかは send_param で呼ぶメソッド指定する、jquery でも似たような感じでイケるようだ。SMART Deploy を使わないについては、要は Seasar 2.4 で SMART Deploy を使わないというこで、つまり Seasar 2.3 のやり方を使う、という意味のようだ。やり方は、AutoNaming を作って add.dicon に設定、詳細は省略。Oval でバリデーションは、コンバート/バリデーションエラー時に Page クラスの値が更新されないのがイヤな場合に使うものらしい、詳細は省略。カスタムコンポーネント作成は、JSF のカスタムコンポーネントの作成の意。すごい DataGrid とか、ああいうのを作る場合のこと。ここは JSF を知らないと厳しいところがあるようだ。
……なんつーか、アレですね。Teeda in Action みたいな本が欲しいですね。
……うーん、このセッションか誰のセッションか他の場所で聞いたか忘れたけど「Teeda は取っ付きやすいが、ハマりやすい」的なことを言ってたと思う。規約に頼りすぎると何が起こってんのか分かり難い、という文脈で。いやまぁ、何かを抽象化する技術ってそんなもんかもしれないなーとも思うんだけど。
ウチの社内でも、Teeda を見たある人が「（規約ベースの部分とか見て）コレ便利だけど、ハマった時のコストがバカんならん可能性があるからちと怖いな」とか言ってて、俺が「ただし、開発しやすいっていうリターンが大きいのも事実だし。ソレナリに枯れてるんで Web で調べれば情報そこそこ出てくるし、ある程度のリスクは許容範囲内かと」て言ったら「そらーお前はそうかもしらんが、他の連中に同じ水準求めるのは厳しいんだよな」ってな事もありまして。まぁ下請けの技術水準乙といえばそうなんだけど、そりゃひがさんも SAStruts + S2JDBC 作るわな、とか妙な感慨にふけってたのを思い出したｗ
ちょっと話が思い出にブッとんだけど。アノテーション重視の流れは、ある種先祖がえりというか回帰というか。この辺の妥協点探りは中々答えが見えないよなぁ。
Lightning Talk
今回の LT の盛り上がりはすさまじいものがあったが、会場のすさまじい蒸し蒸し度も無視しがたいものがあった。
Swing をもっと手軽に - S2Swing の紹介を
スピーカーは id:kaiseh によるセッション。EatSpot, TopHatenar, HatenarMaps の中の人。
NetBeans IDE 6.1 は、かなり Swing の開発がやりやすくなったようだ。Swing Application Framwork + Beans Binding の紹介をしていた。特に注目なのは Beans Binding だろう。ものすごく大雑把に言えば、Swing で双方向バインディングやってくれる代物なので、その便利さは Swing 触ったことある人ならそれだけで分かってくれるだろう。
S2Swing のデモ。POJO と画面のコードを同期・バリデーション・フォーマッティング表示・変換・入力項目と連動しての画面表示を切り替え、を披露していた。
……Flex, Silverliget, WPF*6 と、最近の RIA と言われるテクノロジーのキモの一つはデータバインディングのやりやすさにあると俺は思う。しかしながら、Swing でもこういうのが出てきたり、Uruma なんてのもあったりして、既存の Java テクノロジーをベースにして UI まわりを開発しやすくする代物も出て来るあたりが面白いよなぁ。
ついにオープンソース化！ TERASOLUNA フレームワーク
スピーカーはひがさんと決闘したりとかした中の人によるセッション。
TERASOLUNAフレームワーク（読み方:てらそるな） は NTT データが sourceforge で公開してる OSS のフレームワーク。特徴は、Web アプリ、バッチアプリ向け、Ajax 用、.NET のフレームワークなどを含んでいること。
見所は何といっても TERASOLUNA バッチフレームワークだろう。OSS でバッチ周りのフレームワークというのはかなり異色。スピーカーによると、ドキュメントも充実、NTT データ内で結構使われてる、とのこと。ただし、ジョブスケジューリング機能は提供してないので、そこは他プロダクトとの合わせ技が必要、と語っていた。
全ては定時退社のために
スピーカーは id:EnogunoCap によるセッション。
目的は、OSS 活動のための時間捻出、IT 業界のイメージアップ。定時退社によって win-win の関係になろう、ってフレーズが良いと思いました。
定時退社のメソッド色々。ことあるごとに定時退社に関して熱く語る、見積もりをしっかりとやる（「どのくらいでできる？」に即答せず、いったん考えてから答える）、見積もりを使う（最低限すべきことの明確化、出来るだけすばやくレスポンスを返す）、量より質を大事にする（たくさんやり過ぎると「やつを帰すな！」とかになっちゃう。なので、自分がいなくてもなんとかなる状態を作る）、全体に目を配る（自分だけでなくみんなが順調に回っていることが大事）
スピーチの基本はゆっくり話すこととは言われるけど、このセッションはとにかく早い語り口だったのが印象に残っている。だが、LT はこういうアツイトークが許される―むしろ推奨されてる感すらあるのだが―ところが面白い。
Sabotter 開発でさぼった
スピーカーは、LT の雰囲気作りに定評のある yamashiro によるセッション。
さぼったーとは、twitter と wassr のクライアント。これらが 1 つのクライアントで同時に両方見れるのが特徴、とのこと。
また、プレゼンツールとしても使える。本 LT では実際にその様子をデモで示していた。更に、Eclipse プラグインとしても動作するため「実によく Eclipse になじんでいる」。これは Eclipse 使いには嬉しい限りだろう（仕事しながら twitter & wassr 的な意味で
さぼったーは、CodeRepos でコード公開しており、コミッター募集してます、とのこと。開発体制はユルユルを目指してるので、コミット権はカンタンにプレゼントしちゃうよーとアピールしていました。
あと、あのアイコンは俺は良い思うんだ。twitter & wassr のクライアントってのがゼンゼンわからん点はアレだろうけどｗ
Web コンテナの活用法再考 - new から始まる Web コンテナ
トリを努めるに相応しい LT でした。内容的にも時間オーバー無視して話続ける暴虐ぶり的な意味でもｗ 司会の人が控え室で見せてもらったところによると「Tomcat よりもすげーんじゃねーの」とのことでしたが、俺もそう思いました。
SDLoader という、オレオレ実装簡易 Web コンテナの紹介。動機は、CATALINA_HOME なにそれ？ と言われたり、お客様のところでスタンドアローンで Web アプリを動かしたい、Web アプリのサンプルのセットアップ方法がわかんねと言われた、というのがきっかけ、とのこと。そこで、tiny な Web コンテナが欲しかったので、Servlet API を実際に実装してしまった、とのこと。すごすぎる……
特徴は、Jar 1 個で動くこと。また、空いてるポートを探して起動させたり、main ルーチンで new して起動するなどなど、他にもスゴい機能があるんだけど、とにかくお手軽に Web アプリが起動できる点がスゴい。
まさに「その発想は無かった」と思わされる、すごい LT でした。
