Play! Framework勉強会第２回 in 東京に行ってきました

こんばんは。

第二回 #Playframework 勉強会 in Tokyo #play_jaに行ってきましたので、
その感想を。

一度Playframeworkを用いて内部向けのシステムを作ったことがあって、
その時に下記のような特徴があったため気になっていたFrameworkです。
・Entityを定義するだけでマスタメンテ画面が生成される
・サーブレットを使わず、リクエストに対してレスポンスを書くという非常にシンプルな書き方で書ける
・Javaをインタプリタ的に読み込むため、ホットデプロイが即、動的に可能
・設定ファイルに『おまじない』的なものが少なく、見れば何をしているか直観的にわかる

その勉強会が東京である、ということで行ってきました。
タイムテーブルは下記の通り。

■本編

時間	発表者	タイトル
15:05~15:35	@ikeike443 さん	「Play! の紹介」
15:35~16:05	@garbagetown さん	「playdocjaのこれまでとこれから」
16:10~16:40	@genki_ さん	「Play!で作る業務アプリケーション構成例」
16:40~17:10	@hagikuratakeshi さん	「Play! + GAEで作ったアプリをPlay! + Heroku で動かすとどうなるか」

■ＬＴ

発表者	タイトル
@daiksy さん	「大阪勉強会の続きのはなし」
@kara_d さん	「Play FrameworkでWebSocketを使ってSVGのビジュアルチャットを作ってGDD open call html5に応募してみたけど落ちました」
@mitsuhiro さん	「HerokuのPlay! 対応について」
@Masahito さん	「5分で説明するPlay-Scala」
@tan_go238 さん	「NettyはPlay!でどう使われてるのか的な話」
@ikeike443 さん	Play+JenkinsでCIをやる際の話

・・・とりあえず、ＬＴはあっという間に過ぎ去ってしまったので本編について書きます。
あ、後各々の節は前半まとめ　→　後半感想となっているので前半はそっけないです。

「Play! の紹介」

■基本思想
鈍重な開発サイクル、行き過ぎた抽象化、多過ぎる環境設定と言った伝統的なJava web開発の痛みを伴わない、最高のJavaプラットフォームを目指す
開発時間が限りなくゼロに近いとき、未来の開発に向けた抽象化に挑戦するのではなく、速やかにアプリケーションの機能開発や試験に向けて集中するべき。

■特徴

- 高い生産性
  - 決まりきったものは自動生成、設定ファイル最小限、動的デプロイ
- 素直なHTTPルーティング
  - サーブレットを排し、リクエストに対して生の文字列を返してページを形成することが可能
- シェアードナッシングアーキテクチャ
  - ステートレスＦＷ、その分シンプル
- 非同期I/O
  - Nettyを内包し、高速に動作

Playの特徴は上記の『基本思想』に集約されています。

実際に使った時も最初の駆け出しがやたらと高速にできるのと、
サーブレットが間に挟まっておらず、Renderに直接書き込めるので
RESTアーキテクチャ調でやり取りを書くのが非常に楽でした。

WebSocketも入ってくるので、
単に画面から操作するだけでなく他のインタフェースも設けやすいのが大きいですね。

「playdocjaのこれまでとこれから」

『これ面白い！』が先行して見ていてあまりまとめられていません（汗

Playドキュメントを和訳してGAE上で公開している方のセッション。
ドキュメント自体をフレームワーク上で公開してしまう辺りが面白かったです。
後は「http://dev.classmethod.jp/?s=play」をチェックしておこう。

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

■実現したい機能

- ログの取得（管理者／ユーザ向け）
  - インターセプタの機構があるため、そこにログ出力を仕込むことで基本全て可能。
- データグリッド
  - Jqgridと連携が出来るため、それでＯＫ。データ保存は若干工夫が必要そう。
- ソースコード自動生成
  - 調査中
- バッチ処理
  - Play Jobで定期的な処理などは可能

Requestクラスの拡張っぷりがとんでもなかったです（笑
request.isAjaxなんていうメソッドが普通に存在する。
黒魔術、と言われる所以が微妙にわかったりしました。ただ、現実的には非常に便利です。

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

■GAE→Herokuに移行した際の変更点

- SienaPersistentManagerを改造
- モデル名を変更
- GAE Moduleを排除

GAE→Herokuの移行話。
KVS→RDBに移る場合は結構あっさり終わるようです。
変更点も『当然出てくるよな』という内容で、流れも面白かったです（笑

後はMongoDBに対応してしまった辺りもよかったです。
この辺データアクセス周りをさしかえれば何でもできるという証明ですからねぇ。

結局のところ何に使えるのかな？

これまで作った経験と、今回の勉強会から、Playを作ったシステムは下記のようなのがターゲットになるのかな。

- システム規模は小〜中規模
  - データベースへのアクセス周りがシンプルな分、デフォルトの搭載機能では長大なSQLを処理するには向かないと思われるため
  - 別口で特定のFrameworkに依存しないORマッパー差し込めばどーにでもなりますが・・・
  - ぶっちゃけた話Playで多人数でチーム開発するようなイメージが見えない（笑
  - パッケージに対する制約（controllers直下以外使いたければフルで書けよ）がある関係上『パッケージ名で機能ブロックをわける』といった芸当が行いにくいため
  - 動的デプロイ、黒魔術的な機能を持つリクエストがある関係上性能面が他のフレームワークと比べて気になるので（＾＾；
- ブラウザからだけでなく、システム間ＩＦが必要
  - WebSocketでクライアントプログラムを通じてリアルタイム情報配信
  - REST インタフェースでデータを全てJson形式でやり取りしたりも普通にできる
- 完璧な完成度よりも早い段階で動かしたい
  - 今回のデモで思い知りましたが、やはり反則級のスタートダッシュの速さが大きいです

つまりは、個人でサービスを公開したり、社内システムを作るようなのかな。

他に全体を通してでてきたテーマが下記の２点。

- Scala対応（Play2.0からはScalaがメイン言語化、Javaも使える）、
- Heroku対応

両方大きいし、今後も期待できる。
Herokuは確認しておくか。。。

togetterでまとめられてもいるので、こちらもどうぞ。

夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想＝『夢』と、潰えた夢＝『ガラクタ』の集積場です。