1 / 16

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

自社システムに おける 最適 なフレームワーク. 2012/06/15. 条件. 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を 想定 使用するフレームワーク等は全て無料であるが未来があるものを使用 する 作るにあたり最適なフレームワーク、ソフトを提供 する 画面は HTML5 で作成することが 前提 PC 、 スマートフォンに対応できるような構成を考えること. 2012/06 の言語ランキング. 【 参考 】http ://www.tiobe.com/index.php/content/paperinfo/tpci/. 言語ランキング の考察.

mikhail-casimir
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 自社システムにおける最適なフレームワーク 2012/06/15

  2. 条件 • 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を想定 • 使用するフレームワーク等は全て無料であるが未来があるものを使用する • 作るにあたり最適なフレームワーク、ソフトを提供する • 画面はHTML5で作成することが前提 • PC、スマートフォンに対応できるような構成を考えること

  3. 2012/06の言語ランキング 【参考】http://www.tiobe.com/index.php/content/paperinfo/tpci/

  4. 言語ランキングの考察 • C、C++はWeb系が少ないため除外 →CGIで使うことは可能だがいまさらという感じ • .NET系はツールが有償なので除外 →制限付で無料版ツールもあるけど • Objective-CはiPhoneアプリなので除外 • Web系で検討できそうな技術は「Java」、「PHP」、「Perl」、「Python」、「Ruby」となる • Perlはソース解析が難解のため除外 →記述する人によりソースに個性が出すぎる

  5. Java対スクリプト言語の比較 • スクリプト言語は開発環境において変更後に即時動作可能（コンパイル不要） →JavaでもTomcatなどではオートリロードを有効にすれば同様のことが可能 • PHP等は変数定義が不要（定義していない変数がいきなり使える。実行時の警告） →バグを生み出す原因。大規模では厳しい • スクリプト言語のスピードが問題 →TwitterがRubyからJavaに変更後、スピード5倍 →JavaScript+スクリプト言語は遅い 【参考】http://www.publickey1.jp/blog/12/twitter51.html

  6. 言語の決定 • スクリプト言語をメインにするのは難しい • メインで使用する言語はJava言語 →JavaSE最新であるJDK7.0を使用する • ただし、BToBシステムではスクリプト言語が主流のため、Javaのみで行くのはどうか？ • Web全般はJavaとする • メイン以外の簡単な機能をPythonで作成 • JavaScriptは実行時にしかエラーがわからないためできるだけ使わない →必要（AJAX等）に応じて使用するがJSゴリゴリにはしない

  7. Pythonのメリット • Rubyより処理スピードが速い →ただし、Rubyのほうが案件は多い・・・。 • PHPは技術者が多い →PHP技術者はあふれている • PythonはGoogleが使用する三大言語のひとつである →Java、C++、Python • Python技術者がかなり少ない →競争相手が少ないためシェア獲得のチャンス

  8. MVCフレームワークの選定 • Struts1.X系はさすがに古い →既に使ったことある人がほとんど • Struts2.X系はActionSupportに依存しすぎである →依存を解消しようとするとStruts1.X系と同じような使い方となる →何より人気がないため使用するメリットが・・・ • そこで最近注目されている「Play Framework」を使用する • 1系、2系がある

  9. 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

  10. 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原形が薄

  11. 画面側 • HTML5を使用することが前提 →入力チェックなどのフォーム技術を使用 • Groovyテンプレートを使用してデータ埋込 →Play Frameworkを利用 • 同じ画面を流用できる場合にはPC、スマートフォン切替をCSS3（Media Queries）で対応 →レスポンシブウェブデザイン（Googleが推奨） • JavaScriptはできるだけ使用しないようにする →パフォーマンス重視 • スマートフォン専用にはJQueryMobile1.1を使用 →スマートフォンGUIの開発が用意 →JQueryを使用していれば学習コスト低

  12. モジュール構成 クライアント側 サーバ側 Play Framework 【View】 HTML5、CSS3 JQueryMobile 【Controller】 【Model】 C-Mとの連携方法はSpring

  13. Webサーバ（HTTP）を検討 • HTTPサーバはApache、IIS、nginxが3大シェア • IISはWindowsサーバが必要なため除外 • Apache2とnginxの性能比較 →静的ページではnginxが圧倒的有利 →動的ページでは差がほとんどない（Apache2優勢） • nginxは動的ページを単独で動作できない → PHPを動作させたい場合はpfp-fpmが必要など • nginxを構築したことがある人が少ない →nginxのノウハウは会社としてプラス • HTTPサーバはnginx1.3.1とする

  14. APサーバの検討 • PlayFramework付属のAPサーバを使うべきか • 実案件として、付属のAPサーバを使う可能性が低い • では、WebSocketに対応したAPサーバは？ • Tomcat7.0.27からWebSocketをサポート →最近リリースされたばかり • APサーバはTomcat7.0.27とする →ローカル環境はPlayFramework付属のAPサーバ

  15. DBサーバの検討 • noSQL、RDBをどちらを使うべきか • 作成予定の機能「勤務表」、「自己評価」について、データ修正の可能性は高い →noSQLより、RDBのほうが有効 • RDBを使用することとする • MYSQL、PostgreSQLのどちらを使うか • 案件的にはMYSQLが圧倒的に多い →PostgreSQLは伸びる可能性低 • DBサーバはMYSQL5.5とする

  16. 検討結果 • VPSサーバ上のCentOS6を動作させる • nginx1.3.1+Tomcat7.0.27を連携する • DBサーバがMYSQL5.5を使用する • WebシステムのメインはPlayFramwork1.2.4（言語はJava） →Scalaがクリアできれば2.0.1とする • 簡単な機能についてはPythonを使用 • スマートフォン向けのUIにJQueryMobileを使用 • JavScriptはできるだけ使用しないよう考慮する

More Related