160 likes | 215 Views
自社システムに おける 最適 なフレームワーク. 2012/06/15. 条件. 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を 想定 使用するフレームワーク等は全て無料であるが未来があるものを使用 する 作るにあたり最適なフレームワーク、ソフトを提供 する 画面は HTML5 で作成することが 前提 PC 、 スマートフォンに対応できるような構成を考えること. 2012/06 の言語ランキング. 【 参考 】http ://www.tiobe.com/index.php/content/paperinfo/tpci/. 言語ランキング の考察.
E N D
自社システムにおける最適なフレームワーク 2012/06/15
条件 • 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を想定 • 使用するフレームワーク等は全て無料であるが未来があるものを使用する • 作るにあたり最適なフレームワーク、ソフトを提供する • 画面はHTML5で作成することが前提 • PC、スマートフォンに対応できるような構成を考えること
2012/06の言語ランキング 【参考】http://www.tiobe.com/index.php/content/paperinfo/tpci/
言語ランキングの考察 • 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を使用していれば学習コスト低
モジュール構成 クライアント側 サーバ側 Play Framework 【View】 HTML5、CSS3 JQueryMobile 【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はできるだけ使用しないよう考慮する