h1. よくある質問

h2. <a>ここで答えられていない質問はどこにすればいいですか?</a>

"コミュニティ":https://www.playframework.com/community ページに Play について読み書きできる様々なサイトへのリンクがあります。一般的に、質問をするのに最適な場所は "play-framework Google グループ":http://groups.google.com/group/play-framework です。

h2. <a>X framework と比べて Play はどうですか?</a>

今日では、web アプリケーションを開発するにあたって非常に多くの選択肢があります。Play は web アプリケーションフレームワークなので、他の Java フレームワークと比較してみましょう。Play は 'share nothing' アーキテクチャに向けて作られた (ステートレスなフレームワークと考えてください) ので、Seam, Tapestry や Wicket のようなステートフルでコンポーネントベースの Java フレームワークとは大きく異なります。Spring MVC や Struts (または Struts2) に近いですが、もっと偏屈です。 

しかしながら、Play はユニークな Java フレームワークです。Play はいわゆる Java エンタープライズ仕様をまったく当てにしません。Play は Java を使いますが、Ruby On Rails, Django, Pylons, Symfony, Grails, Cake PHP などのスクリプト言語に基づいたフレームワークの良い部分を、すべて Java の世界に取り込もうとしています。私たちは、鈍重な開発サイクル、行き過ぎた抽象化、多過ぎる環境設定と言った伝統的な Java web 開発の痛みを伴わない、最高の Java プラットフォームを本気で手に入れようとしてきました。

h2. <a>'play' パッケージを 'org.playframework' に変更しないのですか?!</a>

あなたはポイントを押さえていません。Playは、Servlet コンテナに別途追加するようなライブラリではありません。スタンドアロンでアプリケーションを実行するフルスタックな Java フレームワークです。Java パッケージ命名規約は、いくつかのベンダーの異なるライブラリを使うときに、名前が衝突すること避けるために存在します。しかし、我々を信じてください。 @play.jar@ ライブラリを自分のプロジェクトに入れたりすることは決してないでしょう。これは Play を動作させる方法ではありません。Playは **プラットフォーム** です。心配しないでください。

h2. <a>なぜ Python が必要なのですか (Maven がいいのですが)?</a>

新しいアプリケーションを作成したり、実行したり、ブラウザを起動したり、などなど... Play アプリケーションを管理するために沢山のスクリプトが必要です。もちろん、これらを Java で直接書くこともできました。しかし、プロジェクト作成のような簡単な作業のために JavaVM を起動するのはとても遅いです。さらに、OS とのやり取りとなると、Java 自体は非常に制限されています。

Python では、これらのスクリプトを完全に可搬性のある方法で書くことができました。Python は高速に動作し、書き易く、ほとんどのシステムにおいて制限を受けずに利用可能です。Python は Windows にはインストールされていないので、私たちは Windows 用の Python バイナリをバンドルしています。

h2. <a>play は Groovy フレームワークですか?</a>

いいえ。たしかに Play のテンプレートシステムの基本的な技術として Groovy を使用していますが、完全に透過的です。アプリケーションのいかなる箇所 (コントローラ、モデル、または他のユーティリティ) も Groovy で書くことはできません。Groovy ベースのフレームワークを探しているなら、Grails を覗いてみてください。

h2. <a>あなたたちは Java プログラミングの作法すら分かっていない...</a>

私たちが Java の世界ではかなり珍しい選択をしていること、Play が Java のいわゆる '良い慣習' に則っていないことは百も承知です。しかし、 Play の全チームメンバーは非常に経験豊富な Java 開発者であり、行った選択と破った規則について完全に認識しています。

Java そのものはとても汎用的なプログラミング言語であり、初めから web アプリケーション開発に向けて設計されたものではありません。汎用的で再利用できる Java ライブラリを書くことと、web アプリケーションを作ることは、かなり異なる作業です。web アプリケーションそのものは再利用可能なように設計される必要はありません。行き過ぎない抽象化や少ない設定が必要です。web アプリケーションにおける再利用性は、言語レベルでの組み込みよりも、むしろ web サービス API を通して存在します。

開発時間が限りなくゼロに近いとき、未来の開発に向けた抽象化に挑戦するのではなく、速やかにアプリケーションの機能開発や試験に向けて集中するべきです。

h2. <a>Play は速いですか?</a>

はい。Play そのものは高速です。しかし、どれだけ特殊なアプリケーションでも速いという意味ではありません。組み込みの HTTPサーバ、基本的なルーティング、そしてコントローラ起動スタックは、とてもとても高速に動作します。昨今の JVM と JIT コンパイルを使用することで、毎秒数千リクエストを容易に捌くことができます。残念ながら、あなたがたのアプリケーションは、常にボトルネックとなるデータベースを使用することが多いでしょう。

現在、Play スタックで最も CPU を消費しているのは、Groovy ベースのテンプレートエンジンです。しかし、もしあなたが大量のトラフィックを捌かなければならないとしても、Play アプリケーションが容易にスケールする限り、大した問題にはなりません: 複数台のサーバで負荷を分散することが可能です。私たちは JDK7 と、その動的言語のこれまで以上のサポートによるパフォーマンスの向上を期待しています。

h2. <a>Play は製品としてのアプリケーションに使用できる段階にあるでしょうか?</a>

はい、既に "多くの方々":https://www.playframework.com/community/testimonials が Play を製品アプリケーションに使用しています。1.0 ブランチは現在、メンテナンスモードであり、バグ修正のみが行われ、API の互換性は保ち続けられます。

h2. <a>X ライブラリをサポートしていますか?</a>

Play は標準的な Java アプリケーションであり、一般的な Java ライブラリであればどのようなものでも容易に使用できます。ただし、Play がサーブレット API を使用しないことは忘れないでください (WAR エクスポート機能を使って標準的なサーブレットコンテナ上で動かせば、それすらも可能ですが) 。使用したいライブラリがサーブレット API に依存していなければ、とくに問題ないでしょう。 

h2. <a>どうすれば支援/貢献できますか?</a>

私たちは主な開発ツールとして "GitHub":http://github.com/playframework/play を使用しており、GitHub 自体がとてもオープンです。GitHub のアカウントを登録するだけでコードベースをフォークすることができます。"貢献者ガイド":http://play.lighthouseapp.com/projects/57987/contributor-guide を確認してください。

ドキュメント自体も "Textile":http://en.wikipedia.org/wiki/Textile_(markup_language%29 ファイルとしてフレームワークのソースコードリポジトリ中に管理されており、ソースコードと同じように、編集して寄稿することができます。
