第二回 #Playframework 勉強会 in Tokyo #play_ja に参加させていただきました

第二回 #Playframework 勉強会 in Tokyo #play_ja
に参加しました。

勉強会の要約は下記を参照いただければと思います。

• 第二回 Playframework 勉強会 in Tokyo やりました #play_ja – 複雑系スパゲティソース(はてな版) 
• Playframework勉強会#2まとめ（スライド）

Playframework勉強会に参加したきっかけ

自分自身、普段はJavaの受託開発をしています。JavaEEは使わず、Webの部分のフレームワークは、Struts＋Spring＋iBatisを使用しています。（他にバッチのフレームワークもあります...）

近頃は受託開発ビジネスの規模が縮小し、現場でも生産性向上をしないと採算が取れない状況になっています。

生産性向上といっても、必ずしもフレームワークを使用すれば生産性が向上するわけではありませんが、開発環境および基盤（共通部分のプログラム、実装方式）を構築する工数は馬鹿になりません。工数以上に、開発環境構築というのは、開発のボトルネックとなりやすい部分でここで時間がかかったりすると、損失コストが「エンジニアの単価」×「人数」となってしまいます。（ここでいう開発環境は、実装、単体試験、ビルド・デプロイまでを意味しています。）

開発環境を構築するときに一番難しいのは、フレームワークの組み合わせです。
限られた時間内にフレームワークを組み合わせて開発環境を構築する作業自体が難易度が高い。
さらに、メンバーにフレームワークを使って構築した基盤を習得してもらう期間が無視できません。
プロダクトコードだけでなく、テストコードもメンバーに習得してもらうとなると、慣れるころには、プロジェクトが終わっている...といっても過言ではありません。


今後、こんな面倒なことを解消する方法って何かないのかなぁ、と思っていたときに出会ったのがplayframework scalaでした。


playframeworkの勉強会をやっていないか検索したら、上記勉強会があるということを知りました。申込時は、キャンセル待ちで「playframeworkってこんなに人気があるのか。」と改めて、Java開発者がWEB開発に現状不満をもっていて、playframeworkに期待していることを実感しました。



playframeworkの魅力


playframeworkの魅力は以下３点だと思います。

• 環境設定ファイルがシンプルであること（xml地獄にならないこと）
• 様々なフレームワークを組み合わせる必要がないこと
• 実装、単体試験、ビルド・デプロイがセットになっていること

個人的には、playframework 2.0のscalaに期待です。

scalaでDBを参照、更新するサンプルコードを動かしてみたのですが、ゼロからはじめて半日で動かし、テストコードも書いて検証することができたのは、playframeworkが初めてでした。

WEBとバッチ双方でModelを共有できればなぁと思っています。

あと、メーリングリスト（英語）の投稿数が半端じゃないです。１日に数十通メールが飛んでいます。

特にscalaの内容が多いと思います。playframework scalaの今後に期待です。

playframeworkのSpringFrameworkモジュールを使用した感想

勉強会で、さまざまなmoduleを組み込むことができますと教えていただいたので、SpringFrameworkモジュールを組み込んで、遊んでみました。

DI自体は簡単にできましたが、playframeworkのspringモジュールは、単純なJavaのロジックのDIしかできません。DBのデータソースやトランザクション管理のモジュールは入っていません。トDBのデータソースやランザクション管理の必要性がないからでしょう。（私は、DBのデータソースやトランザクション管理のモジュールをlib以下に組み込んで使用してみましたが、大したメリットはないです。）

Springを使用するのは、ビジネスロジックをDIしたい場合だけでしょう。

最後に

勉強会を開いていただいた @ikeike443 さん、スポンサーとなっていただいたイージフさま、シャノンさま、ありがとうございます。セミナー、および懇親会で様々な方と情報交換をさせていただき、自分にとって大きな刺激になりました。