自社システムにおける最適なフレームワーク

2012/06/15

条件• 機能は「自己評価」、「勤務表」、「掲示

板」、「ログイン機能」を想定• 使用するフレームワーク等は全て無料であ

るが未来があるものを使用する• 作るにあたり最適なフレームワーク、ソフ

トを提供する• 画面は HTML5 で作成することが前提• PC 、スマートフォンに対応できるような構

成を考えること

2012/06 の言語ランキングPositionJun 2012

PositionJun 2011

Programming Language

RatingsJun 2012

Delta Jun 2011 Status

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/

言語ランキングの考察• 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 、 CSS3JQueryMobile

【 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 はできるだけ使用しないよう考慮する