第二回Play framework勉強会にいってきました。

第二回Playframework勉強会にいってきました。
第二回 #Playframework 勉強会 in Tokyo #play_ja : ATND
かなり洗練されたframeworkだと感じました。
今回学んだことの中で、惹かれた部分は以下の3点。

  • Javaのシンタックスをそのままに、軽量プログラミングを実現している
  • 機能が豊富。Eclipseプロジェクト化が簡単で、テスト機能がframeworkに組み込まれている
  • PaaS側が続々とサポートしてきている。GAE, heroku, cloudbees。

圧巻なのは、Javaで軽量プログラミングを実現している点。
コーディングした内容を反映するのにいちいちコンパイルして、デプロイして・・・。
というステップを踏まなくても書いたコードがそのまま反映される。
噂には聞いていたけど、かなり素晴らしい。RubyPHPみたいなLLとしてjavaが使えるとは。。。

早速今回の発表内容を紹介していきます。

「Play! の紹介」 by @ikeike443

発表資料:What is play
Play初心者の自分としては一番タメになった。
ライブコーディングで、CRUDを持つユーザー管理システムをその場で作る様はまさにスバラシイの一言。
途中色々とexceptionが出てもそのたびにエラー内容がわかりやすく通知され、
デプロイコマンドいらずでコーディングした内容がそのまま反映されていくため、
非常に良いデモンストレーションになったと思う。

Node.jsとPlayframeworkの性能比較もあってすごくありがたかった。
今のところ、Renderingを省けばNode.jsよりもPlayのほうが性能は上だが、
Renderingまで入れるとPlayよりもNode.jsの方が上とのことでした。
詳しくは下記の表を参考にしてください。
f:id:yosuke_furukawa:20111009004238p:image
青がNode.js、赤がBlocking IOを利用したPlay、黄がNon-Blocking IOを利用したPlayです。
Node.jsも非同期IOなので、黄色と比較するとrenderingなしではPlayのほうが上ですね。

Renderingを入れると
f:id:yosuke_furukawa:20111009004514p:image
Node.jsの方が上になります。
参考サイト:Nodejs vs Play for Front-End Apps

ただ、これはPlayがGroovyベースのテンプレートを利用しているためであり、
今後のバージョンアップで改善が見込めるとのことでした。

「playdocjaのこれまでとこれから」 by @garbagetown

下記のPlay翻訳サイトの運営をしている方の発表。*1
Play framework - Home

最初はRoRライクなフレームワークだと知って猜疑心に溢れながら調査 -> 洗脳されて傾倒という流れを説明してくれた。
GAEに簡単にデプロイできる、Eclipseプロジェクト化が簡単にできるという点やプログラムエラーが分かりやすく
通知される点に惹かれてPlayの翻訳活動を進めたとの事でした。

最後のメッセージとして、Ruby on Railsと何が違うのか、RoRではなくPlayを選ばないといけない理由はなんなのかという点について
問題提起をしていました。

かなり印象に残るメッセージでした。
ただ、会社でJavaを使っている身からすると、ほとんど共通言語のようになっているため、新しいフレームワークを導入する際、
RoRの学び直さないといけない、作りなおさないといけないという部分は採用されにくいだろうなぁと思いました。

「Play!で作る業務アプリケーション構成例」 by @genki_

発表資料(PDF):
Play!で業務アプリを導入した例。
実際に利用するとなるとログが非常に重要視される。
Play上でlog4jを利用することもできる上にp6spyを利用するとSQLのログも出せるとのことでした。

また、日本で業務アプリを作成するとExcelライクなインタフェースが必要とよく言われるとおっしゃっていましたが、確かにそうだなぁと感じました。

jqgrid jQueryを利用してグリッドライブラリを使えば簡単に実現できるというライブラリ紹介までしてくれました。

「Play! + GAEで作ったアプリをPlay! + Heroku で動かすとどうなるか」 by @hagikuratakeshi

発表資料:2011/10/08_Playframework_GAE_to_Heroku
GAE-Heroku移行を実施した発表。
GAEとHerokuで最も違うのは永続化層がBigTablePostgreSQLになって異なっていること。
Herokuにするならそこを何とかしないとなぁと思っていたらSiena2.0からPostgreSQLもサポートされるようになっていたとのこと。

それでもTaskQueueやBlobなどGAEに依存している部分があったのでそこは依存性を排除して実現した様子。
データ移行は下記のサイトを参考に実施し、CSV化してエクスポート、インポートすることで対応。*2
2011-01-03 - ellerの日記

この方の最も素晴らしかったのは、SienaをMongoDBに対応してくれた部分です。
herokuで利用できるMongoDBに格納するようにSienaの永続化部分を自分で拡張し、MongoDBに入れられるように
しており、夢が広がる対応をしていました。

from scratch的感想

前回のエントリである7つの言語7つの世界でも書きましたが、
次のデファクトは関数型になると予言されています。Scalaのような洗練された言語がサポートされているため、今の時点では他のフレームワークよりも
一歩進んでいる印象を受けました。

一つ、性能面が他のフレームワークと比較して、気になるところですが、それを補って余りある
高い生産性と移行容易性、学習容易性を備えているため、今後勉強していこうと思います。

英語も勉強しているので、翻訳活動もしてみたいと思いました。

*1:実はだいぶ昔に先輩を通じて飲んだことがある方でした。その節はご迷惑を・・・。また飲みましょう。

*2:自分も洋書の読書履歴を管理するサイトをGAE上にアップしているので、これがあるとかなり助かる。