一週間ほど遅れたけれども、5月21日に Rails勉強会@東京第6回 に行ってきたのでレポートする。今回も会場は秋葉原で、30人弱が参加した。
連絡事項
- 会場の確保でいろいろ無理をしていて、これから先確実に確保できるとは限らないので、どこか他の場所を提供してくれる人を探しているそうです。完全に非営利なので公民館などの公共の施設を無料もしくは安く借りる手もあるのだけれども、問題はそういうところは予約が埋まっていて定期開催がとても難しいということだという。10人ずつ別室でも良いので毎月定期的に30人ほどの集まりができるような場所に、どなたか心当たりはありませんか?
日本Rubyカンファレンスで、ボランティアで音響機器の操作（発表者のマイク調整と、セッションの録音程度）をしてくれる人を急募するそうです。バンドやっているとか、ちょっとでも音響関係の経験のあるカンファレンススタッフを募集中です。
知り合いに心当たりが数人いたけれども、全員、カンファレンスの日は都合がつかなかった。
前半セッション
4つのテーブルに分かれた。
私は「SeasarでRailsを作れるか」のオーナーをやった。セッション数が足りていなかったので割とネタ気分で言ってみたのだけれど。あとから「Changelog」なんかも出てきたので「誰も来ないかもしれないけれど、それはそれで良し」と思っていたら、 id:moro さん、 id:yad-EL さん、 井上さん 、 安藤さん 、ソフトバンクの杉山さんと、なんだか凄い人達が集まってしまった。
先日の Seasar Conference でHot DeployとかS2Axis2とか面白い技術を沢山見て、ここまで柔軟になればそろそろJavaでもRailsを本格的に実現可能じゃないか、とぼんやり思ったのが元ネタ。
RailsにインスパイアされたJavaのフレームワークとしては trails が実在するけれど、言語の限界からなかなかRailsの動的さ加減は実現できていない。そこでSeasarですよ、と。バイトコード操作や種々のテクニックによるJVM上への動的性質の導入に関してはSeasarプロダクトはなかなかのものだ。しかも、"Less Configuration = Convension over Configuration + Convension by Exception"を宣言している。Hot Deployまで揃った今月のSeasarの力で、どこまでRailsを再現できるか、1つ思考実験をしてみようじゃないか、とみんなで考えてみた。
Railsのすごいところ
まずは軽くSeasarプロダクトのまとめ。それから、「じゃあRailsの差別化要因って何?」というのを洗い出してみた。
ログに色が付く
ある意味よくやった。
ActiveRecord
別にActive Recordパターンの実装自体はどうということはない。Rails ARの良い所は属性をいちいち宣言する必要が無いことだ。DB schemaがそこにあるんだから、データモデルはいちいち書かなくてもFramework側で察して欲しい。
そう、察してほしいのだ。私はConvension over Configurationをいろんな言葉で言い替えるのが好きだけれども、その1つは「つーか空気嫁 >>framework」だ。
Routeによるdispatching
URLをカスタマイズできることや、特にPATH_INFOを簡単に取り扱えるところは嬉しい
generator
最近のフレームワークでは結構ありがちだけれど、これは大切。特にscaffold。
- モデルを定義したら、あとは極めて安価にモデルに対するいい感じのUIが手に入る。 いいもの使ってる感 がある。
- プロジェクト開始後5分から継続的ビルドを実践可能。継続的ビルドに載ってしまうと、何しろ自分の作ったものが動いて見られるのだから、プロジェクトに貢献しているのを肌で感じられる。でも、新規開発では継続的ビルドに至るまでにちょっとした時間が掛かりがちだ。scaffoldがあればすぐに始められる
- テストケースのスケルトンまで書いてくれる。もうこれは、TDDしろと。そして、"red, green, refactor"な快感を味わえと。
こういうところでgeneratorは開発者のモチベーション維持に多大なる貢献をしている。
テストがすぐ走る
generatorのお蔭で。そしてRakeによるサポートも大きい
Rake
ビルド言語はプログラミング言語でなければならないと偉い人が言ってたね。誰だっけ? ファウラー?
Antタスクを書くのにもう疲れたよ。
Action Web Service
弊害を心配 しなければならないほど簡単だ。システム同士を繋げて発展させていくための心理的障壁を無くしていく。
validation
宣言的に書けるという嬉しさ。設定が分散しない利点
View
Viewテンプレートのための式言語が結局複雑化していくなら、始めからERBでいいじゃないか
Active Support
WebにはWebのための定番の処理があって、それを汎用言語に組み込んでしまうと多用途において邪魔だ。だからそれはライブラリとして実現する。
でも、いやしくもOOPLであるならば、文字列のための処理はStringオブジェクトのメソッドであってほしい。そこでActive Supportだ。
言語
Rubyの表現力。「至高の言語Ruby」(by id:secondlife)
S2を中心とした実現
上のような特徴を、Seasarを中心としてJava技術でどれだけ実現できるか考えた。
ログに色が付く
やればできる。
ActiveRecord
Hibernateがもうかなり近い所までやって来ている。
特にTigerのannotationを使うと設定ファイル生成もいらないし。XDocletは結局はannotationがない世界におけるbad know howだったと思う。
S2Hibernateがあればセッション管理まわりで定型コードを書く必要もない。あとはバイトコード生成してSchemaからクラス定義を作ってくれればそれで良いよねという話になった。セッションのときはとっさに出てこなかったけれど、良く考えてみたら既に 無定義Hibernate がある。
このあたりを組み合わせて、Hot Deployで実行時の差し替えも可能にすればActiveRecordは再現可能である。
Route
単一のサーブレットに*をマッピングしてdispatchさせればできる。というか、既存のフレームワークでも結構ありがちな機能。あとはPATH_INFOの使いかたぐらいだけれども、これもやればできる。
generator
generator自体は技術的に特に難しい点はない。Railsの良い所は、一連のgeneratorセットをきちんと用意した所、scaffoldするセンスであって、後追いは難しくない。
Rake
ビルド言語はプログラミング言語でなければならず、できれば親しんだ言語が良い。これには賛同するので、そのうち暇ができたらJava版Rake（Jakeとでもいうのか）を作ろうという気持ちはある。既存のものがあるのかどうかは知らない。問題はRakeを再現するにはJavaはsyntaxがpoorなことだけれども、これは言語のところに書く。
Action Web Service
Webサービスサポートについてだけは、S2Axis2がAction Web Serviceを超えている。Java自体に型があるし元々interface定義のための語彙もあるから、言語内DSLで改めてinterface定義をするような手間も必要ない。
Apache Axisを直に使うにはちょっとした作業は必要だけれども、S2Axis2ならdiconファイルに1行書くだけでメソッドをWebサービスとして公開可能だ。
Validation
括弧を省略できないというJava言語のシンタックスの問題は置いておく。それは別として、宣言的validationの実装については既にid:moroさんが挑戦し、問題点を明らかにしてくれていた。
Javaで実装する上での問題は、JavaにおいてはクラスとClassオブジェクトは異なるということだ。クラスがそれ自体はオブジェと出ないために、クラスメソッド（staticメソッド）はpolymorphicでない。このためにインスタンスと異なり、クラスに対してはTemplate Methodパターンやその変形が使えない。これがActiveRecord::Base.validateの実現を阻む。
やはりJavaではAnnotationを使うのが王道ではないかということになった。Annotationならパラメータの名前渡しもできるし、それなりに可読性があるので悪くはない。
View
ERB相当が欲しいならJSPでいいよね。あとはHelperだけれども、Javassistを使えばメソッドを他のクラスにコピーするのは難しくないから、これも実現可能だよね、と言った。
そうしたら、「いやもっと欲張ってもよい」と言われた。SeasarプロダクトにはMayaaもありS2JSFもありTeedaもある。Viewに関してはJavaはRailsを超えることができる。
Active Support
Groovyを使うかなぁとか。あれはコアクラスに対してメソッドを追加しているようにみせかけて、内部ではユーティリティクラスの呼び出しに書き換えていた筈。
あるいは、Railsを志す以上フレームワークとしての全体の結合度が高くなるのは避けられないから、開きなおってシステムクラスローダを書き換えて、rt.jar内のクラスを書き換えてしまうというのも考えた。
ちょっと前まで、AspectJはコアクラスにはweaveできなかったと思ったけれど、id:moroさん情報では最近は限定的ながらweave可能とのこと。
言語
Rubyには言語内DSLを実現する記述力がある。Rake然り。Routing然り。AWS然り。Javaにはそれがない。
最近Pythonを勉強していて、やはりメソッドに対応するオブジェクトを簡潔な式で取得できるのは羨ましいと思った。Rubyは括弧をを省略可能な文法の為に instance.method_name という式ではメソッドを取得できない。これではメソッド呼び出しになってしまう。Methodオブジェクトを簡単に取り出せないというのは純粋OOPLとしてはちょっと情けないところだ。
しかし、これが言語内DSLを生み出す力の源であるからには、メソッドオブジェクトの問題はトレードオフとして許容できるかなと思う。
そしてJavaを見てみるとどうしようもなく表現が貧しい。でもJavaにはGroovyがある。JSRに上がったせいで最近のGroovyは随分「Java的」になってしまい魅力が薄れたらしいけれど、だったら昔のGroovyを使えば良い。Groovy + Hot DeployはRubyにかなり近いのではないか。
まとめ
Java on Railsというのか、Seasar on Railsというのか、S2Railsというのか知らないけれど、そういうものを仮に作るとして、「SSeasarの力をもってすれば、やってやれなくはない」というのが結論である。そして、Railsの魅力を再発見した。
他のセッション
-
Rubricks 。Railsで書かれたかっこいいUIのCMS。そういうのを実現しようとして大量にJavaScriptが混じったhelperを書くことになって訳わからなくなっているので、結局こういうところのView LogicはGizaのようにpure JavaScriptで書くのが嬉しいのかな、というお話でした。
Typoの改造
Changelogをたんたんと読むよ
Rails 1.0の機能はAWDwRでみんな知っているけれど、1.1以降の機能はあまり知られていないものもあるのでそのあたりを勉強したらしい。このあたりの情報の日本語によるまとめが必要だね、というお話。
後半セッション
3つのテーブルに分かれた。
私は、id:moroさんがオーナーのvalidationのところに参加した。ここでは基本に戻ってActiveRecordのvalidationメソッド群を一通り眺めた。
まあ、これらのメソッド群は大部分が名前そのまんまの機能なんだよね。特に何か書くべき事があるのはこんなもんか。
- validates_numericality_ofはデフォルトでは小数を通してしまう。整数に限定するには :integer_only => true する。
- validates_associatedは、関連先のオブジェクトがvalidであるかどうかを判定する。けれども、self.leafがinvalidだったとして、self.errorsには"leaf is invalid"としか記録されない。子項目への入力についても、selfへの入力と同じように詳細なメッセージを出すためには、ActiveRecordHelper::error_message_forを上書きして頑張ってなんとかするしかない。
- not nilであるだけでなくnot blankであることが必要な場合、nilかどうかの判定はvaidates_presence_ofに任せて、他のvalidaionでは :allow_nil => true したほうがよい。たとえば整数値の必須入力項目において入力しなかったとき、「入力されていない」と「整数でない」が両方エラーとして表示されると混乱する。
- validates_eachは名前がわかりづらいけれど、blockを渡してイレギュラーなvalidateをするために使える。
Testing
途中、抜け出して「テストの章」の方にも顔を出してきた。こちらは、行ってみたらAWDwRの1st ed.と2nd ed.のTestingの章の違いを探す企画になっていた。AWDwR 2nd ed.はRails 1.1に対応しているから結構違いがあったようだ。
Integrationテストが重視され、その分Functionalテストの記述が減っている。
従来Functionalテストで無理矢理やっていたようなテストもIntegarationテストでより適切に行える。
1st ed.ではTestingの章だけ、それまでのDepotアプリケーションの話から離れて、つながりが分かりづらくなっていた。2nd ed.では前章と話がつながっている。
- has_and_belongs_to_manyの記述がバッサリと削られている。多対多関連はモデル化するっていうことで、habmは使ってほしくないんだろう。
- 全体としてこれからRailsが向かおうとしている方向が見えてくる構成になっている。
懇親会
後半セッションの途中で帰ってしまったお2人がいて、あれは誰だったんだろうという話になった。RubyやJavaで開発を仕事にしているという感じでは無いし、ちょっと研究者っぽい雰囲気で不思議に思っていた。
そうしたら、年配の男性の方はJIS X 0218やなんかのときの符号化文字集合調査研究委員会の委員長をやっていた芝野さんだということが判明。高橋会長以外は誰も芝野さんの顔を知らなくて、高橋さんは「知ってる人は知ってるだろう」と思って何も言わなかったらしい。みなで「本にサインしてもらいたかった」と後悔することしきり。
id:ogijun さんの周りで数学の話で盛り上がった。折紙で任意角の三等分ができる理由を教えてもらったり。抽象代数学の魅力をみんなに伝えようとしてみたり。
お昼を食べていなくてお腹が空いていたので、ご飯がとてもおいしかった。
