こちらに参加しての所感
TDC : 第3回Seasar勉強会 in Sendaiを5/30に開催します！
http://tohoku-dev.jp/modules/news/article.php?storyid=18
参加動機と会場について
正直、SAStrutsの勉強よりも勉強会ってどんなものだろうか？ってのを体感したくて参加してみました。あと、自分は社内で勉強会を開いたり、前でしゃべる機会もある方みたいなのですが、いつも「これでいいのかな？」って思いながらやっている。そんなワケで、どんなしゃべり方、進め方をすればよいか見て参考にするため。
会場は以外と狭くて、１つのテーブルで２人、２つのテーブルをくっつけてお互いのテーブルの人が向かい側に座る構成。単に机を講師に向けて座るよりこうしたほうが、分からないときにお互いに聞きやすくなるんだろう。（聞く人が１人から、３人に増える）ただ、初めて会う方が多いのに向かい合って座るこういった状況はすごく緊張する。あいている場所で一応「ここいいですか？」って言って座る。駄目って言われたらどうしよう・・・とか思いながら。ここで以前仕事で一緒になった方に会う。あとはぜんぜん知らない人ばかり。正直この人には嫌われていたと思っていたけど、それでもちょっとは気が楽になった。普通に対応してくれて感謝。こういった勉強会は参加するメンバーの固定率が高くなるのかな？自分以外はなんか知り合いって感じがした。
事前にインストールするソフトウエアなどもあったので、行ったらネットにつなげない環境になるのかなと思ったけど、LANが完備してあって随時必要なものはネットに取りに行けたし、なによりインストールすべきソフトを運営側がUSBで提供してくれていたので、安心でした。こういった勉強会は勉強したくて来るので自分のＰＣ持って来いって言われても何の違和感も無いし、自分のＰＣ使うほうが楽なんだけど、人によっては家ではスペックの低いマシンでメールするぐらいって人もいるだろうから、貸し出しＰＣも用意されるともっと敷居が低くなるんではと感じた。（無理なお願いですけどね）
Slim3についての紹介（ひがさん講演）
ひがさんの講演はSlim3の紹介。ブログの方でいろいろ書いていたような気がするけど、正直頭に入っていなかった。講演という形で紹介されると結構わかったような気がしてくるのは不思議。Slim3はGoogle Apps上で実行できるアプリケーションを作るためのフレームワークみたいなものって認識しました。これでよいんだろうか？また、Slim3の開発にはブランクアプリケーションが用意されているので、これを修正、追加する形で作成していく方式。たとえば、Slim3Controlerというクラスがあるので、これを自分で作るアプリケーションにあわせた名前に変えていくとか。
※ Slim3は、Seasar2の後継となるコンテナーとのこと。紹介の中でGoogle Appsと一緒の形で紹介されていたのでGoogle Appsのものを作るためのものかと勘違いしてしまった。ちなみにSimple less moreという言葉から来ているらしく、スリムスリーと呼ぶらしい。
Slim3はMVC
Slim3はMVCで出来ていて、リクエストはControlerが受け取るということで、１リクエストに対し、１Controlerが必要。でもそのControlerを作るために手でシコシコ書いていくのではなくて、Antで自動生成するとのこと。なるほどこうやって作る人の手間と間違いの元を省いてくれるとな。
Google AppsのBigTable
Google AppsはRDBMSではなくBigTableというDBを使うけど、そのときにjdoかjpaのどちらかでアクセスするんだけど、お勧めはjdoだそうな。理由はjpaっていうのはRDBMSを意識して作ってあるのに対し、jdoはデータの格納先を意識しないつくりになっていて、たとえば格納先がXMLだろうがRDBMSだろうが、ファイルだろうが意識しなくてもいいようになっている。さらに言うとGoogle Appsを開発している人たちがjdo好きが多いからだそうな。
Slim3とTDDと自分なりの所感
ブランクアプリケーションにはテストのフォルダもあり、 TDD（テスト駆動開発）についても説明があった。今作ろうとしている小さな部分を頭で整理して小さなテストを書いてからコードを組むんだけど、最終的にはテストは全体のテストを行う集合体になる。作っているうちに前に作ったテストでコケるって言うことは、今作ったものが前作ったメソッドなどの使い方を間違っているかもってことが一目瞭然になる。
管理者的には「製造」と「テスト」が分けられなくて日程組めないんでは？とか疑問に思うかもしれないけど、この方法をとれば、逆に作るものの日程の「見える化」ができるんではないかと思った。たとえば「ｘｘ画面」製造３日、テスト４日って組むんではなくて、「ｘｘ画面のｙｙ処理」１日、「ｘｘ画面のｚｚボタン」４時間ってな具合に、作るものを細分化していくことが可能。だけど、普通は開発効率は上がっていくって日程を組むんだろうけど、この場合は前に作ったテストでコケるのは単純に今作ったものが悪いからではなくて、調査する時間も必要になるし、その調査する時間は増えていくと思われるので、その辺を考えて日程を組む必要があるのかなぁと感じた。
Slim3への所感
ちょっと紹介された程度なので、いい感じなんだけど実際の開発の際には、Controlerの基底クラスなんか作りたいってなるかもしれない。その場合はAntをちょっといじるだけで済むんだろうか。テンプレートファイルがあってそっちを変更する程度なんだろうか？それとも大規模な変更が必要（Slim3自体を変更してコンパイルしなおすとか）なんだろうか・・・その辺を調べる必要があるなと思った。（※下記追記参照）最後にGoogle Appsにデプロイする方法もやってくれて、Eclipse上からボタン１個でデプロイできた。あまり迷わなそう。実は仕事上こまごまとした空き時間ができてきて、RubyかPHPかGoogle Appsのどれかの調査をしようと思っていたけど、こうなったら決まりね。Google AppsとBigTableを勉強することに決定。その方法としてSlim3を使ってみる。こうして自分の中のJava比率が高まってJavaしか知らない使えない人になっていくのでした。
2009/06/08追記
http://blog.takeda-soft.jp/blog/show/339を見ていて、ひがさん本人からのコメントを発見！
ひが 2009/06/04 ControllerとTestCaseの継承元を任意のものに 変える機能をslim3-blankにコミットしました。 build.xmlのsuperclassNameとtestCaseSuperclassName を適当に書き換えてください。
で、該当するbuild.xmlのプロパティ(superclassName、testCaseSuperclassName)の値を書き換えればいいようですね。下記はhttp://slim3.googlecode.com/svn/trunk/slim3-blank/build.xmlから参照。
<project name="slim3it" default="gen-controller" basedir="."> ・・・省略 <property name="superclassName" value="org.slim3.controller.Controller" /> <property name="testCaseSuperclassName" value="org.slim3.tester.ControllerTestCase" /> ・・・省略
なるほど〜！
SAStruts勉強会
本日のメインイベント。SAStrutsの勉強会。SAStruts、S2JDBC、Doltengを体感するのが目的らしい。SAStrutsはSuper Agile Strutsの略らしい。Strutsなのに設定ファイルを書かないとか、SeasarなんでHot Deployとか。S2JDBCは可読性の高さとIDEの補完機能を有効に活用できるので生産性が高くなりますよということ。
Doltengでは、プロジェクトを作成すると自動的にブランクアプリケーションみたいなディレクトリ構造を作ってくれるので、これに変更を加えていく開発方法。MFCのウィザードとスケルトンを思い出したのは自分だけだろうか。あと、データベースはすでにH2が組み込まれてあるので、楽だよということ。ローカルＰＣにデータベースが組まれているので、データはもちろん、テーブル自体を変更する必要がある場合などに、ローカルＰＣで検証してから全員に反映することも可能になるので開発効率がいいよと言うこと。その際のローカル側のテーブル変更とか、それに伴うプロジェクト側のエンティティの変更とかもAntで一発なので楽ということと、マイグレーションする際に保存してあったデータなんかも復元してくれるらしい。
SAStrutsでもStrutsと同じくActionクラスを作るんだけどStrutsが１URLに対し１アクションなのに対し、SAStrutsでは１ユースケースあたり１アクション（ｘｘ画面を使うとか）になるとのこと。この辺は１アクションクラスにイベントが集まるようになるので、分かりやすいなと思う。通常設計書としてはｘｘ画面とか１まとまりにすることが多いし、フレームワーク非依存（そんなの実は本当に可能かってのは置いといて）に書く場合なんかはｘｘ画面＝ｘｘクラスって書かれることが多いけど、そういった場合の設計書との乖離も少なくなると思われる。ActionクラスもたとえばLoginActionクラスとかを作ると、URL上でも「コンテキストパス/login」となるとか、/で終わると、index()が呼び出されるとか、login/xxxxでxxxxがメソッド名になるとか確認が想像しやすいという感じ。
SAStrutsでは設定ファイルを書かない
そういえば設定ファイルぜんぜん書かないって事に気がついた。struts-config.xmlだのvalidation.xmlだの。全部アノテーションとして表現してる。スゲー。内部ではどんな風に動いているんだろう。アノテーションをガリガリ書かせるってのはなんかJavaじゃないような気がして自分では好きな方ではないけど、POJOで表現する場合にはこういった方法が合っているんだろうなぁ。
Hot Deploy
あと、Hot Deployだけど、普通Webアプリを作っていて、コンテキストをreloadable=trueにしていれば、クラスを変更するとそのアプリケーションだけ再起動して変更が反映されるよね。Hot Deployってどう違うの？って思っていたけど、なるほどこれはすごいね。サーバを再起動しないといけないようなものもそうだけど、アプリケーションの再起動する時間（サーバが変更を感知して再起動するまでの時間）すらないので、すぐに確認ができる。コレか？
参加して
Slim3もSAStrutsもだけど、開発する際のディレクトリは実際に実行されるアプリケーションのディレクトリ構造とは異なっていてちょっと面食らう。なんでこう複雑になるかは理由は分かっているんだけど、自分が講習でやるときはWebアプリ未経験者を対象にすることが多いので開発ディレクトリ構成＝アプリケーションディレクトリ構成になるようにしてた。そのほうが単純で想像しやすいから。でもこれに関しては、いろいろなAntやDoltengなどの便利ツールの集合体なので、会社で勉強会をやるときは「こんなもんだ」「とりあえず、今日はココは見ないでね」とか、講習の対象者に見る部分を限定させてやるしかないかなと感じた。（見ないでといっても見えてしまうのが人間だから、そこで迷うかもしれないけど、その辺を考える必要があるなと感じた）
今回はSAStrutsを触ったことが無い人を対象に「使い方」を勉強した。でも「使い方」よりも内部でどんな風に動いているかって方に興味があって、その辺をやってほしいなと思う。オープンソースなので「ソース見ろ」って感じになるけど、その辺を一人で苦労しながら寂しく見るより、みんなで集まって有識者から教えられるベースでコードリーディングすれば、覚えるべき部分が一本の線になるので良いと思う。なにより内部の動きなんかの知識が増ると言うことは、開発の際の色々な調査の元ネタになるので。
懇親会はヘルニアの調子がおかしくなってきたので辞退させていただきました。次は行ってみたいと思います。運営の皆様、お疲れさまでした。開催することにも興味があるので、次は何かしらスタッフとしても協力できたらと思います。
P.S LLで、Tracで萌えな話とか、Seasar勉強会なのにWicketとかClickの話をして怒りを買ってみたいとか思った自分がいた。
