Transcript Googleが推奨

自社システムにおける
最適なフレームワーク
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はできるだけ使用しないよう考慮する