自社システムにおける 最適なフレームワーク 2012/06/15
条件 機能は「自己評価」、「勤務表」、「掲 示板」、「ログイン機能」を想定 使用するフレームワーク等は全て無料で あるが未来があるものを使用する 作るにあたり最適なフレームワーク、ソ フトを提供する 画面は HTML5 で作成することが前提 PC 、スマートフォンに対応できるような 構成を考えること
2012/06 の言語ランキング Position Jun 2012 Position Jun 2011 Programming Language Ratings Jun 2012 Delta Jun 2011 Status 12C17.725%+1.45%A 21Java16.265%-2.32%A 33C %-0.47%A 47Objective-C9.094%+4.66%A 54C#7.026%+0.18%A 66(Visual) Basic6.047%+1.32%A 75PHP5.287%-1.31%A 88Python3.848%-0.05%A 99Perl2.221%-0.09%A 1012Ruby1.683%+0.20%A 【参考】
言語ランキングの考察 C 、 C++ は Web 系が少ないため除外 →CGI で使うことは可能だがいまさらという感 じ.NET 系はツールが有償なので除外 → 制限付で無料版ツールもあるけど Objective-C は iPhone アプリなので除外 Web 系で検討できそうな技術は「 Java 」、 「 PHP 」、「 Perl 」、「 Python 」、「 Ruby 」と なる Perl はソース解析が難解のため除外 → 記述する人によりソースに個性が出すぎる
Java 対スクリプト言語の比較 スクリプト言語は開発環境において変更後に即時 動作可能(コンパイル不要) →Java でも Tomcat などではオートリロードを有効に すれば同様のことが可能 PHP 等は変数定義が不要(定義していない変数が いきなり使える。実行時の警告) → バグを生み出す原因。大規模では厳しい スクリプト言語のスピードが問題 →Twitter が Ruby から Java に変更後、スピード 5 倍 →JavaScript+ スクリプト言語は遅い 【参考】
言語の決定 スクリプト言語をメインにするのは難しい メインで使用する言語は 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 )リリースされたばかりであり技術者が少ない 【参考】
PlayFramework1 系 or 2 系 テンプレートエンジンの差 →1 系は Groovy 、 2 系は Scala ( Groovy より高速) 安定度 → 2 系はバグが多く現状難しいという意見もある 【参考】 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 サーバは? Tomcat から WebSocket をサポート → 最近リリースされたばかり AP サーバは Tomcat とする → ローカル環境は PlayFramework 付属の AP サー バ
DB サーバの検討 noSQL 、 RDB をどちらを使うべきか 作成予定の機能「勤務表」、「自己評価」に ついて、データ修正の可能性は高い →noSQL より、 RDB のほうが有効 RDB を使用することとする MYSQL 、 PostgreSQL のどちらを使うか 案件的には MYSQL が圧倒的に多い →PostgreSQL は伸びる可能性低 DB サーバは MYSQL5.5 とする
検討結果 VPS サーバ上の CentOS6 を動作させる nginx1.3.1+Tomcat を連携する DB サーバが MYSQL5.5 を使用する Web システムのメインは PlayFramwork1.2.4 (言語は Java ) →Scala がクリアできれば とする 簡単な機能については Python を使用 スマートフォン向けの UI に JQueryMobile を使 用 JavScript はできるだけ使用しないよう考慮す る