2010年1月22日金曜日

Play framework is a full stack framework

Play frameworkで楽しんでます。
フルスタックとはテンプレート、データベース補助があるだけでは不足

clean url routing, test, fixture, message after redirect, background job, cache, i18n程度あたりがそろっていないとFullとは言えない時代だと思う。
Playはその点、完璧だろう。
reverseまで持ってるんだから、私は当然お気に入り。

ただ、欠点もある。

background jobがスレッドで走ってしまうので、重くなる。
Hibernateとは別れたい。
ほかには、先日書いた内容など。

やはり私はpublic fieldを積極的に使いたい。
メソッドではなくフィールド
redirect(BookPage.find, 1)とかでリダイレクトしたいし、
tx(BookService.reserve, 2)とかでトランザクションを開始したい。

Routingもフィールドを使えばリファクタリング効くしね。

メソッドをフィールド扱いできるScalaには期待しています。

2010年1月21日木曜日

ANA-Amex

JALが沈没したのでクレジットカードを整理することにしました。

次はANA-AMEXにします。
アメリカン・エキスプレス

12月までは大盤振る舞いだったようだけど、まだ大丈夫か

1. 100円で2マイル
3ヶ月間ポイントが倍

2. 入会2000+1000マイル

3. オンライン明細で1000マイル
ただし、入会時は紙にしておいて、入会したあとに変更すること

4. 公共料金や電子マネー、携帯などの引き落としでそれぞれボーナス
合計すると10000マイルの予定

5. Edyチャージでポイントがつく
ただし6ヶ月間

6. 年会費がAMEXにしては安い
5250円

スルガ銀行ANA支店

2010年1月15日金曜日

Hello, Play framework

Play frameworkを使ったことがある人はどれぐらいいるんだろうか。
こんなに面白いフレームワークとは思わなかった。
いや、フレームワークというより、プラットフォームです。

まえにJava on Railsなんて宣伝を見てしまったせいでスルーしていた。
たしかに「Rails使いに媚びてDjangoをJavaにポートした」と言えないこともないけど。
ためしてから宣伝してください。迷惑です。
見所はコマンドラインなんかじゃない。まあ、Python for Windowsがついてくるのは確かに面白いけど。
なんといってもJavaの使い方が革命的に面白い。

なんと表現すればいいのか。
「コンパイルさえ通せば、あとはまかせとけ」
といったところか。
staticメソッドを積極的に使い、記述をシンプルにすることが使命であるようだ。

まずはこの三つの機能を見てみます。
1. Bind an HTTP parameter to a Java method parameter
リクエスト引数をメソッド引数に名前で結びつけちゃいます。
メソッド引数名ですよ?
アノテーションなんて不要です。
まさしく名前つき引数なのです。

routesに
GET  /show/{name}  Application.show
とあったとして、
/show/Tom?page=2
にアクセスがあったならば
public static void show(String name, Integer page)
では、nameにTomが入り、pageは2になるのです。
型や順番や偶然を使っているわけではありません。
引数名を見ているのです。

2. Redirect to an action by calling the corresponding Java method
一度でもDjangoのreverseを使ったことがあれば、URLなんて直接書きたくないと思うことでしょう。
この場合ならばControllerのメソッド名で指定したいところ。
しかし、文字列でredirect(reverse("Books.list", page))では芸がない。
redirect(Books.list, page)と書くことができればいいけど、残念ながらコンパイルエラーになるでしょう。
Javaのメソッドとフィールドの名前空間と同じであれば、もっとまともなフレームワークを作れたのですけどね。
そこでPlayは突き抜けました。
Books.list(page)
と書けば勝手にリダイレクトされます。

staticメソッドだからといって気を抜いてはいけません。
フォワードではなく、間違いなくブラウザにResponseがかえります。

3. Don’t Repeat Yourself when passing Java objects to templates
Spring MVCではデフォルトの名前というものが存在します。
User => user, List<User> => userList
というように、型から名前をつけてくれるので、テンプレートに名前をつけながら渡す必要がありません。
しかし、Playでは1と同様に型ではなくローカル変数名を取得します。
ローカル変数名ですよ。
pythonでもrender(article=article, user=user)と書かなきゃいけないってのに。
bytecode enhanceってレベルじゃないですね。
ただ、残念ながら実行時に解決なので、いっそコンパイラを作って変数名をbytecodeに埋め込んでほしいと思います。


以上のようにJavassistの黒魔術を駆使して理想郷を追い求めます。

だがちょっと待ってほしい。
この黒魔術
まさにDIでやっていることそのままではないか。
DIの黒魔術を許してこれを許さないなんて、なんという傲慢。
フィールドに準備しておくか、staticで呼び出すかの違いしかない。
ルールを決めておけばOKとはどの口が言ったものか。
Mockitoを見て便利だといっていたじゃないか。
staticであればコードがそのまま追えるなんて、いつまで20世紀にしがみついているんだ。
もうそんな時代じゃないんだ。
EJB2信者なんて、もういないでしょ?

DIに飼いならされた開発者たちなら、ルールだと説得すればすぐ納得するね。
賭けてもいい。
逆に、「Proxyを使って実現できるDIとは違う」と反論するような人が相手なら、
メリットを比較してあげれば、いずれは「ひでえ」といって納得するはず。

残念なところもいくつか挙げておく。

1. アプリの構造が貧弱
Djangoのアプリを引き継いでほしかった。
一定以上の規模のものを作れるのだろうか。
心配です。
2. formが貧弱
ModelとはべつにFormクラスを作ってください。
ModelべったりのFormだと画面や権限に応じてValidationや項目を変えづらい。
3. Bytecode拡張される範囲が不明
Bytecode拡張される範囲が明確でないため、自分で拡張しようとすると
なかなか恐ろしい。
たとえば、もう少し複雑で動的なFormがあって、複数のControllerで共有したいとすると、
自分で独自のクラスを作りたくなるけど、どこまで拡張してくれるのか試すまで、
いや、試してもよくわからない。
returnをなくそうとしたり、Javaの言語仕様をとことん無視しようとしているので、
なかなか機能拡張は難しそう。

まとめ

二週間以内で作るものにはちょうどいいかも。
どうしてもJavaがいい。
Javaじゃなきゃいやと根拠なく言われたときに使うことを考えてもいいかもしれない。
Springの起動が遅くて、決別したいとは常々思っているので、
こういうアプローチが流行ってくれば面白いとは思っています。
Bytecode拡張以外は使いやすく、わかりやすい機能がてんこ盛りなのでお勧めです。
Bespinとうまく連携すれば、全文検索つきのCMSが結構簡単に作れるかも。