Play! Framework
日本 Playframework ユーザー会
  池田尚史 @ikeike443
自己紹介
• 池田尚史(いけだたかふみ)
• 株式会社シャノン Product Manager
• @ikeike443
• Play! Framework コミッター
• 日本 Playframework ユーザー会
• 『 Jenkins 』オライリージャパン 寄稿
• 勉強会、翻訳等々やってます
Ajenda
• Playframework って何?
• コアメンバー、歴史
• Play1 と Play2
• Playframework の特徴
• デプロイの選択肢
• 利用事例など
そのまえに。。。
• 質問させてください
あなたのメイン言語は。。。



• Java?
• Scala?
• それ以外?
Playframework について。。。




• 聞いたことある方
Playframework について。。。




• 触ったことある方
Playframework について。。。




• Play1?
• Play2?
Playframework について。。。




• 何か作ってみた方
Playframework について。。。




• Play1?
• Play2?
Playframework について。。。




• プロダクションで使った方
Playframework について。。。




• Play1?
• Play2?
• ご協力ありがとうございます
Ajenda
• Playframework って何?
• コアメンバー、歴史
• Play1 と Play2
• Playframework の特徴
• デプロイの選択肢
• 利用事例など
Playframework って何?
• Java/Scala 用 Web フレームワーク
• フランスの Zenexity 社が開発
• 現在は Typesafe 社の Typesafe Stack の一部でも
  ある
• Rails ライク
    ●
        フルスタック
    ●   CoC
Playframework って何?
• Web 開発者の Web 開発者による Web 開発者の
  ための Web フレームワーク
• 決して JEE のフレームワークではない
• JEE の規約に則っていない
• Servlet を使っていない
• XML 不要
Play はシンプル
• 従来型の JEE アーキテクチャ              • Play のアーキテクチャ

    Facelets
    Facelets             EJB
                         EJB


       Java Server Faces
       Java Server Faces


           Servlet API
           Servlet API               Play! Framework
                                     Play! Framework


   JEE Container (JBoss など ))
   JEE Container (JBoss など


    Http Server (Tomcat とか ))
    Http Server (Tomcat とか          Http Server (Netty)
                                    Http Server (Netty)
JEE の難しさ
• JEE は抽象化レイヤーが多すぎる
• JEE は将来出現するかもしれない Web ではない
  何かにも対応するべく高度な抽象化をしようと
  している??
• その何かってなんだ?
• Java の Web 開発は難しい!
• そもそも前スライドの図が正しいかどうかも分
  からない
Play は Web フレームワークであ
る
• 多すぎる抽象化レイヤーは悪
• Web フレームワークは Web の開発が出来れば
  よい
• Web にフォーカスしよう
• HTTP を変に抽象化するのはやめよう
Heroku 曰く
• Developers with experience in both Java and Ruby
  web development often ask the question: Why is
  web app development so complicated in Java, and
  so much simpler in Ruby, with Rails?
• Java と Ruby の両方を経験している Web 開発者
  はしばしば疑問に思うことがある。なぜ Java
  の Web 開発はこんなにややこしいんだ? 
  Ruby, 特に Rails で開発するとこんなにシンプ
  ルなのに。

            http://blog.heroku.com/archives/2011/8/29/play/
            http://d.hatena.ne.jp/ikeike443/20110830/p1
Play コアメンバー曰く
• 鈍重な開発サイクル、行き過ぎた抽象化、多過
  ぎる環境設定と言った伝統的な Java web 開発
  の痛みを伴わない、最高の Java プラット
  フォームを目指しているのが Play! というフ
  レームワーク
Play コアメンバー曰く
• 開発時間が限りなくゼロに近いとき、未来の開
  発に向けた抽象化に挑戦するのではなく、速や
  かにアプリケーションの機能開発や試験に向け
  て集中するべきです。
デモ動画
• プロジェクトの新規作成
• 起動〜 Welcome ページ
• 変更〜 Hello World!
• Json レスポンス
デモ動画
どうでしたか?
• Servlet は出てきませんでした
• XML の設定ファイルもありませんでした
• サーバ再起動なしで変更が反映されました
app              → アプリケーションのソースコード
└ assets             → アセットのソースファイル
└ controllers        → アプリケーションのコントローラ
└ models             → アプリケーションのビジネスロジック層
└ views              → テンプレート
conf             → 設定ファイル
└ application.conf    → メイン設定ファイル
└ routes             → ルート定義
public           → 公開アセット
└ stylesheets        → CSS ファイル
└ javascripts        → JavaScript ファイル
└ images             → 画像ファイル
project          → sbt 設定ファイル
└ build.properties    → sbt プロジェクトの基本ファイル
コアメンバー
Playframework の歴史
2007 年頃 (ver0.x)




• 社内フレームワークの時代
• Servlet / JSP
2009 年末〜 2010 年頃 (ver1.0)




• OSS 化
• Groovy テンプレート , Python シェル
• この頃から既に非同期 I/O を実装
2011 年頃 (ver1.2)




• ネットワーク周りを Mina から Netty へ
• Websocket サポート
• Scala サポート
現在 (ver2.0.1)




• 全体を Scala で書き直し
• Netty+Akka で非同期 I/O の徹底
• 基本的な思想は 1 系と同じ
Play1 と Play2
• Play1
 Java で書かれた Java のフレームワーク
 Scala はプラグインでサポート

• Play2
 Scala で書かれた Scala/Java のフレームワーク
Play1 と Play2
• 基本的な設計思想は同じ
• 完成度を取るなら Play1
• 未来への成長を取るなら Play2
Play1 と Play2
• Play1 が好きな人から見ると、 2 はデグレード
  したように見えており、少しもめていた
• Play1 は今後もサポートされることを発表し、
  メンテナーを増員した(それが私)
• Play1 が好きな方も安心してください
コミュニティの成長
• 2010 年初頭、 ML の登録数は 400 人ほどだった
• 2012 年 5 月現在、 5900 人超
• Java の Web 開発に風穴を開けた印象
• ML を見ていると熱狂的なファンが多い
• 日本で Seasar が出た時の雰囲気に似てるかも?
Play の特徴
Play の特徴
•   高生産性かつ楽しい
•   Web フォーカス
•   ステートレス
•   広範囲な型安全
•   ノンブロッキング
•   リアクティブ
•   高いテスタビリティ
•   プラグイン機構
高生産性
高生産性かつ楽しい
• なによりもセットアップの手間がない
• フレームワークを DL して、 unzip するだけで
  もう使える
• XML を書かなくていい!!
高生産性かつ楽しい
• コードのホットスワップ
    ●
        明示的なコンパイル不要
    ●   まるで LL のように
• Evolution(Rails の Migration のようなもの ) でス
  キーマ変更も自動的に行える
• サーバの再起動なしで開発をすることができる
高生産性かつ楽しい
• CoffeeScript, LESS のサポート
• assets ディレクトリに格納しておくと、それぞ
  れ Javascript, css にコンパイルし、静的コンテン
  ツとして扱ってくれる
• Rails3 のアセットパイプラインと同じ
• もちろん自動コンパイル
• Google Closure Compiler も内蔵してるよ
Web フォーカス
Web フォーカス
• Servlet API を使わない
• HTTP へのフルアクセスが可能
Web フォーカス
• もしあなたが Servlet API や Strtus のような
  Java の Web フレームワークを使っているな
  らば、 HTTP プロトコルを Java の奇妙な
  API やコンセプトで抽象化したビューを使って
  きたことになります。
• Web アプリケーションフレームワークは
  HTTP とそのコンセプトに対して完全かつ容易
  なアクセス手段を提供すべきです。これが Play
  とその他の Java web フレームワークの根本的
  な違いです。
ステートレス
ステートレス
• Play には HttpSession はない
• Play の session の実体はただの Cookie
• セッション管理には Memcached を使うのがお
  すすめ
• セッションレプリケーション? なにそれ美味
  しいの
ステートレス
• ステートフルでコンポーネントベースの Java Web フレーム
  ワークは、自動的にページの状態を保持するのを容易にします
  が、他に多くの問題をもたらします : ユーザがふたつ目のウィ
  ンドウを開いたら何が起こるでしょう?ブラウザの戻るボタン
  を押したら ?
• Share Nothing アーキテクチャは、 PHP に始まり、 Ruby on
  Rails や Django など数多くの Web フレームワークで奨励さ
  れています。ブラウザがどんどん強力になっていくにつれて、
  今や Ajax やオフラインストレージを使って、クライアントサ
  イドで状態保持の問題を解決することが容易になっています。
• もう Web に紛い物の状態を再構築するために HTTP モデル
  をハックする必要はありません
ステートレス
• クラウド時代( IaaS, PaaS )の Web 開発はス
  テートレスであるべきではないか
• キャパシティプランニング→サーバ調達→デプ
  ロイ、という時代ではない
• まずデプロイ→ニーズ・状況に応じて即時ス
  ケールアウト、という時代ではないのか

• Play はステートレス養成ギブスであり、時代
  の要請にマッチしている!
広範囲な型安全
広範囲な型安全
• HTTP ルーティング、 HTML テンプレー
  ト、 Javascript に至るまですべてコンパイル
  し、静的にエラーを検出できる
• コンパイルエラーは瞬時にブラウザに表示され
  る
アプリケーションコード
Javascript も




    ※ Google Closure Compiler 内蔵
テンプレートも




 ※ テンプレートは Scala の関数
  として実装されている
Routes も
広範囲な型安全
• LL っぽく柔軟に書けるフレームワークであり
  ながら、同時にあらゆるものを静的に検査して
  くれる型安全性
• 型安全だが、堅苦しくない絶妙なバランス
• Scala の型推論と Play のホットスワップ機能の
  合わせ技!
ノンブロッキング
ノンブロッキング I/O
• Play はありとあらゆる部分でノンブロッキン
  グ、非同期処理を手軽に書けるように考えられ
  ている
• なぜか?
Play はこう考える
• これから先はリアルタイム Web の時代
• Web フレームワークには完全な非同期 HTTP
  プログラミングモデルをサポートすることが求
  められる。 (node.js の流行 )
• Comet 、 WebSocket 、 SPDY 等、コネクション
  は長い間保持されるものになっていきがち。
• Web プログラミングはイベント駆動モデルへと
  進むべきでは。
ノンブロッキングの実現
• Netty による非同期 I/O の実現
• Akka による継続プログラミングモデルの実現
• 場合によっては node.js より速いかも
    ●   1.2(Netty+Javaflow) のときは node.js といい勝負
          だった
Netty とは
• JBoss のネットワークフレームワーク
•   Java NIO のラッパー
•   非同期イベント駆動型
•   高スケーラビリティを誇る
•   Twitter が採用していますね
• Play が Servlet API を使っていない理由の一つ
Netty とノンブロッキング I/O
• 詳細は下記参照
  http://d.hatena.ne.jp/fatrow/20110208/netty
 http://www.slideshare.net/tanago3/netty

• Play は Netty のラッパー。利用者は特に意識せ
  ずとも Netty のパワーを享受できる。
• これだけで十分速い
Akka による非同期処理
• Akka とは、 Scala 製の Actor ベース非同期処理
  フレームワーク
• Actor とはメッセージベースの並列計算モデル
  のこと
• Erlang などが有名
• 詳細は Wikipedia...
Actor のイメージ

            message
            message
   Actor1
   Actor1             Actor2
                      Actor2




   Actor1
   Actor1             Actor2
                      Actor2



                      処理
                      処理


            message
            message
   Actor1
   Actor1             Actor2
                      Actor2
Play の Actor
• ActionInvoker
     ●   FW がルーターからコントローラを呼ぶ部分で
• PromiseInvoker
     ●   利用者が明示的に Promise を利用する時に
• WebsocketAgent
     ●   利用者が明示的に Websocket を実装する時に
PromiseInvoker の例 (Scala)

def index = Action {             別の Actor( ワーカースレッド)へ

    val promiseOfInt = Akka.future { longComputation() }
    Async {
        promiseOfInt.map(i => Ok("Got result: " + i))
    }              Promise が返却されるまでの間、スレッドを
}                  ブロックしないで待ってくれる


         Akka の設定を変更すると、アプリケーションコード
         を変更せずに、 longComputation を別クラスタに移譲
         するようなこともできる( Akka remote )
PromiseInvoker の例 (Java)
public static Result index() {
 Promise<Integer> promiseOfInt = Akka.future(
  new Callable<Integer>() {
      public Integer call() {
          longComputation();
      }
  }
 );
 async(
  promiseOfInt.map(
      new Function<Integer,Result>() {
          public Result apply(Integer i) {
ノンブロッキングまとめ
• Netty で意識することのないノンブロッキング
  I/O
• Akka のヘルパーを使って気軽に手続き的に非
  同期処理を書く事ができる
• Akka remote を使って重たい処理をバックエン
  ドに飛ばすことも簡単
• Websocket も使えるよ
リアクティブ
リアクティブ
• Iteratee, Enumlator, Enumlatee
• Haskel からヒントを得た IO モナドの実装
• ストリーム処理を抽象化し、イベントドリブン
  に処理できるようにしている模様
• 巨大なファイルアップロードを一度に大量に受
  け付けることなどを想定している?
• Guillaume と Sadek が Qcon で詳しく説明してく
  れています
 http://www.infoq.com/presentations/Play-I-ll-See-Your-Async-and-Raise-Y
高いテスタビリティ
テスタビリティ
• Specs2 : BDD フレームワーク
• 組み込みのテストフレームワークとして採用
  http://etorreborre.github.com/specs2/
• Play2 はあらゆるものが Scala の関数であるた
  め、テストしやすい
• Selenium WebDriver も組み込んでいてブラウザ
  を通した受け入れテストも簡単に書ける
テスタビリティ
• テンプレートもただの関数→ View をテスト可

"render index template" in {
    val html = views.html.index("Coco")
    contentType(html) must equalTo("text/html")
    contentAsString(html) must contain("Hello Coco")
}
テスタビリティ
• コントローラもテスト可能

"respond to the index Action" in {
    val result = controllers.Application.index("Bob")(FakeRequest())
    status(result) must equalTo(OK)
    contentType(result) must beSome("text/html")
    charset(result) must beSome("utf-8")
    contentAsString(result) must contain("Hello Bob")
}
テスタビリティ
• HTTP サーバを起動して Selenium WebDriver
 (FluentLeniumを採用している )
 "run in a browser" in {
     running(TestServer(3333), HTMLUNIT) { browser =>
         browser.goTo("http://localhost:3333")
         browser.$("#title").getTexts().get(0) must equalTo("Hello Guest")
         browser.$("a").click()
         browser.$("#title").getTexts().get(0) must equalTo("Hello Coco")
     }
 }
テスタビリティ
• テストフレームワークが組み込みで用意されお
  り、特に準備することもなく即 TDD に取り掛
  かることができる
• CI を組むのが簡単
• アジャイル開発にとてもマッチするフレーム
  ワーク!
プラグイン機構
プラグイン機構
• フレームワーク全体にプラグイン機構を採用
• DB 層や Akka などはプラグインとして実装さ
  れている
• 1.x ほどのバリエーションはまだない
  が、 MongoDB, Redis, Memcached, Spring, Guice
  など、続々プラグインがリリースされている。

 http://www.playframework.org/documentation/2.0.1/Modules
利用事例
Klout
• ソーシャルスコアリングで勢いのあるベン
  チャー
• 検索コンポーネントと、 Klout API の部分を
  Play+Scala で構築している

 http://corp.klout.com/blog/2012/03/sexy-api-from-klout/
英ガーディアン
• コンテンツ API の実装に Play2 Scala を採用して
  いる
• github で実装を公開もしている
 https://github.com/guardian/frontend
Minecraft
• ネットで旋風を巻き起こしたインディーズゲー
  ムの Web サイト
多数のスタートアップ
• Mashape: www.mashape.com
• Ocado: www.ocado.com
• ollaa: www.ollaa.com
• Komli Mobile: www.komlimobile.com
• LikedBy: www.likedby.com
• Docracy: www.docracy.com
• Masterbranch: masterbranch.com
• Valraiso: www.valraiso.net
• eXpress-Board : www.express-board.fr
• CMesDonnees : www.cmesdonnees.com
• Venarc : www.venarc.comEdit
その他
• Verizon
• Fannie Mae
• Freddie Mac
• Foreclosure.com
国内
• 情報が少ないのが正直なところ
• 金融機関などでも使われているという噂はあり
• ちなみに私が関わった案件はすべて Play
     ●   某大手研修サイトの一部機能
     ●   某大手不動産業者サイトのコンテンツ API
     ●   某大手生保スタッフサイトの一部機能
     ●
         某イベントの受付フォーム
デプロイ
デプロイは苦労知らず
• Servlet コンテナを使わない
• 開発環境と本番環境の差異がほぼ発生し得ない
• リポジトリからチェックアウトすればデプロイ
  完了
即時スケールアウト可能
• ステートレスなフレームワークであるた
  め、 IaaS や PaaS と相性が良い
• Java が使える環境であれば、普通のレンタル
  サーバでも特に問題はない
PaaS の選択肢

• Heroku
• Cloudbees
      ネイティブサポート
• OpenShift
• Cloudfoundry
• Google AppEngine
• DotCloud
• Amazon Beanstalk
どうですか?




• Play! Framework って楽しそうじゃないです
  か?
日本 Playframework ユーザー会
• https://groups.google.com/forum/?fromgroups#!forum/play_ja
日本 Playframework ユーザー会
• 不定期に勉強会をやってます
• 次回は 7 月 14 日(土)です!
• http://playframeworkja.doorkeeper.jp/events/1231-%E7%
• 将来的にはコアメンバーたちを日本に呼ぶこと
  も構想しています!!
• その実現のためには、みなさんのご参加が!!
日本 Playframework ユーザー会
• ドキュメントの翻訳も行っています!
• 現在は 2.0.1 の翻訳を進めています。
• 興味のある方はぜひ ML でお知らせください。
ご静聴
ありがとうございました!

Play jjug2012spring