自社システムにおける最適なフレームワーク 2012/06/15 条件 • 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を想定 • 使用するフレームワーク等は全て無料であるが未来があるものを使用する • 作るにあたり最適なフレームワーク、ソフトを提供する • 画面はHTML5で作成することが前提 • PC、スマートフォンに対応できるような構成を考えること 2012/06の言語ランキング Position Jun 2012 Position Jun 2011 Programming Language Ratings Jun 2012 Delta Jun 2011 1 2 C 17.725% +1.45% A 2 1 Java 16.265% -2.32% A 3 3 C++ 9.358% -0.47% A 4 7 Objective-C 9.094% +4.66% A 5 4 C# 7.026% +0.18% A 6 6 (Visual) Basic 6.047% +1.32% A 7 5 PHP 5.287% -1.31% A 8 8 Python 3.848% -0.05% A 9 9 Perl 2.221% -0.09% A 10 12 Ruby 1.683% +0.20% A 【参考】http://www.tiobe.com/index.php/content/paperinfo/tpci/ Status 言語ランキングの考察 • C、C++はWeb系が少ないため除外 →CGIで使うことは可能だがいまさらという感じ • .NET系はツールが有償なので除外 →制限付で無料版ツールもあるけど • Objective-CはiPhoneアプリなので除外 • Web系で検討できそうな技術は「Java」、「PHP」、「Perl」、「Python」、「Ruby」となる • Perlはソース解析が難解のため除外 →記述する人によりソースに個性が出すぎる Java対スクリプト言語の比較 • スクリプト言語は開発環境において変更後に即時動作可能（コンパイル不要） →JavaでもTomcatなどではオートリロードを有効にすれば同様のことが可能 • PHP等は変数定義が不要（定義していない変数がいきなり使える。実行時の警告） →バグを生み出す原因。大規模では厳しい • スクリプト言語のスピードが問題 →TwitterがRubyからJavaに変更後、スピード5倍 →JavaScript+スクリプト言語は遅い【参考】http://www.publickey1.jp/blog/12/twitter51.html 言語の決定 • スクリプト言語をメインにするのは難しい • メインで使用する言語はJava言語 →JavaSE最新であるJDK7.0を使用する • ただし、BToBシステムではスクリプト言語が主流のため、Javaのみで行くのはどうか？ • Web全般はJavaとする • メイン以外の簡単な機能をPythonで作成 • JavaScriptは実行時にしかエラーがわからないためできるだけ使わない →必要（AJAX等）に応じて使用するがJSゴリゴリにはしない Pythonのメリット • Rubyより処理スピードが速い →ただし、Rubyのほうが案件は多い・・・。 • PHPは技術者が多い →PHP技術者はあふれている • PythonはGoogleが使用する三大言語のひとつである →Java、C++、Python • Python技術者がかなり少ない →競争相手が少ないためシェア獲得のチャンス MVCフレームワークの選定 • Struts1.X系はさすがに古い →既に使ったことある人がほとんど • Struts2.X系はActionSupportに依存しすぎである →依存を解消しようとするとStruts1.X系と同じような使い方となる →何より人気がないため使用するメリットが・・・ • そこで最近注目されている「Play Framework」を使用する • 1系、2系がある Play Framework • フレームワークを使うメリットとしてソース量を減少させたい →RoR、codeigniter等と同じく設定より規約のため、設定ファイルを減らせる →エンティティのカプセル化を非推奨 • 開発環境の整備が容易 →開発環境にJavaEEサーバが不要（JavaEEの非依存） →Unit試験が容易（付属でUnit試験できるツールが付属） • 標準でいろいろなフレームワークが付属しているため、コスト（ローカル設定）が容易 →ORM（JPA）、テンプレート、AJAX、WebSocketなど標準で使用可能 • サンプルドキュメントが比較的そろっている（英語）が日本語情報が少ない（1系はそれなりにある） →まだ、日本では使用頻度が低く、シェアを獲得するチャンスである • 2系は最近（2012/04）リリースされたばかりであり技術者が少ない【参考】 http://www.playframework.org/documentation/2.0.1/Home PlayFramework1系 or 2系 • テンプレートエンジンの差 →1系はGroovy、2系はScala（Groovyより高速） • 安定度 → 2系はバグが多く現状難しいという意見もある【参考】 http://blog.flect.co.jp/labo/ • 2系のScalaテンプレートはView作成時に切り離しにくい →モックから画面作成へ工数が増加する可能性あり • リクエストマッピングが異なる →1系ではアクションの引数、2系ではscala経由でマッピング • PlayFramework1系を選定する →ただし、ScalaとViewを上手く切り離せるなら2系とする →付属サンプルはViewヘルパーを使っていてHTML原形が薄画面側 • HTML5を使用することが前提 →入力チェックなどのフォーム技術を使用 • Groovyテンプレートを使用してデータ埋込 →Play Frameworkを利用 • 同じ画面を流用できる場合にはPC、スマートフォン切替を CSS3（Media Queries）で対応 →レスポンシブウェブデザイン（Googleが推奨） • JavaScriptはできるだけ使用しないようにする →パフォーマンス重視 • スマートフォン専用にはJQueryMobile1.1を使用 →スマートフォンGUIの開発が用意 →JQueryを使用していれば学習コスト低モジュール構成クライアント側【View】 HTML5、CSS3 JQueryMobile Play Framework 【Controller】【Model】 C-Mとの連携方法はSpring サーバ側 Webサーバ（HTTP）を検討 • HTTPサーバはApache、IIS、nginxが3大シェア • IISはWindowsサーバが必要なため除外 • Apache2とnginxの性能比較 →静的ページではnginxが圧倒的有利 →動的ページでは差がほとんどない（Apache2優勢） • nginxは動的ページを単独で動作できない → PHPを動作させたい場合はpfp-fpmが必要など • nginxを構築したことがある人が少ない → nginxのノウハウは会社としてプラス • HTTPサーバはnginx1.3.1とする APサーバの検討 • PlayFramework付属のAPサーバを使うべきか • 実案件として、付属のAPサーバを使う可能性が低い • では、WebSocketに対応したAPサーバは？ • Tomcat7.0.27からWebSocketをサポート →最近リリースされたばかり • APサーバはTomcat7.0.27とする →ローカル環境はPlayFramework付属のAPサーバ DBサーバの検討 • noSQL、RDBをどちらを使うべきか • 作成予定の機能「勤務表」、「自己評価」について、データ修正の可能性は高い →noSQLより、RDBのほうが有効 • RDBを使用することとする • MYSQL、PostgreSQLのどちらを使うか • 案件的にはMYSQLが圧倒的に多い →PostgreSQLは伸びる可能性低 • DBサーバはMYSQL5.5とする検討結果 • • • • VPSサーバ上のCentOS6を動作させる nginx1.3.1+Tomcat7.0.27を連携する DBサーバがMYSQL5.5を使用する WebシステムのメインはPlayFramwork1.2.4（言語はJava） →Scalaがクリアできれば2.0.1とする • 簡単な機能についてはPythonを使用 • スマートフォン向けのUIにJQueryMobileを使用 • JavScriptはできるだけ使用しないよう考慮する