自社システムにおける 最適なフレームワーク 2012/08/03. 前提条件 機能は「自己評価」、「勤務表」、「掲 示板」、「ログイン機能」を想定 使用するフレームワーク等は全て無料で あるが未来があるものを使用する 作るにあたり最適なフレームワーク、ソ フトを提供する 画面は HTML5 で作成することが前提.

Presentation on theme: "自社システムにおける 最適なフレームワーク 2012/08/03. 前提条件 機能は「自己評価」、「勤務表」、「掲 示板」、「ログイン機能」を想定 使用するフレームワーク等は全て無料で あるが未来があるものを使用する 作るにあたり最適なフレームワーク、ソ フトを提供する 画面は HTML5 で作成することが前提."— Presentation transcript:

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

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

3 先月までの検討内容 Java で開発だとスキルアップにならないのでは →PlayFramework1 系では新しい要素が薄くない？ → まして 2 系でてるのに 1 系っていまさらないでしょ う・・・。 → じゃあ、他のフレームワークは？ Lift （ Scala ）ってどう？マイナーすぎないか。 → そもそも Scala ってどうなの？ 対抗馬として Django （ Python ）はどう？ →Google App Engine で使われているよ。 → でも、開発案件で Python 使っているのほとんど無い → 動的型付けだと実行時にバグ生みやすく大規模厳しい とりあえず、 PlayFramework2.02(Java) 、 Lift2.4(Scala) 、 Django1.4(Python) で検討しましょう！

4 各フレームワーク比較 No 項目 PlayframeworkLiftDjango 1 言語人気◎（ Java ） ×(Scala) △ (Python) 2 ドキュメント量（ Web ） ○ △◎ 3 画面モックの流用△◎ ○ 4 画面レイアウト ○○○ 5 入力チェック◎△◎ 6 設定ファイル ( 少ないこ と ) ○○○ 7 使いやすさ◎△ ○ 総合点数 161015 各種フレームワークを上記観点で比較。 詳しい説明については以下に記載。 HTML5 を使用することを前提にしているため、ビュー周りを中心に評価。 個人的な主観も入っていると思いますので、激しい突っ込みは勘弁していただけると・・・。 総合点数は◎： 3 、 ○ ： 2 、△： 1 、 × ： 0 で採点

5 1. 言語人気（ 2012/07 ） Jun 2012Jun 2011ProgrammingDeltaStatus 12C18.331%+1.05% 21Java16.087%-3.16% 36Objective-C9.335%+4.15% 43C++9.118%+0.10% 54C#6.668%+0.45% 67Basic5.695%+0.59% 75PHP5.012%-1.17% 88Python4.000%+0.42% ・・・ 45?Scala0.237%? 【参考】 http://www.tiobe.com/index.php/content/paperinfo/tpci/ http://www.tiobe.com/index.php/content/paperinfo/tpci/ ※主要検索エンジンに検索された結果を元に算出しているようです。

6 2. ドキュメント量 No 項目 PlayframeworkLiftDjangoStruts 1 Web 全体 960,0005,710,0002,580,00051,100,000 2 日本語のみ 300,0001,400,0005,990,0005,580,000 3 日本語 +1 年 14,1006,48031,90033,000 4 日本語 +1 ヶ月 2,3701,2606,6506,360 5 日本語 +1 週間 8176013,0402,520 総合結果 ○ △◎ー Google を使用して測定（ 2012/07/30 ）、参考として「 Struts 」も記載。 検索キーは「 Playframework 」、「 Scala Lift 」、「 Python Django 」を 使用。 「 Playframework 」は「 Play 」と略されることが多いため若干不利？ Django は日本語のみのほうが全体より多い、何故・・・、誰か教え て？？ 直近も全般も Django が 3 つの中では人気が高い。 Struts とほぼ同じ件 数。 1 年間で言うと「 Lift 」よりも「 Playframework 」のほうが人気。

7 3. 画面モックの流用 Web 開発において、画面モックを流用できること は重要。 → 設計段階で画面モックを作成する → モックを流用できれば画面開発の工数削減 → ときどき、 EXCEL で画面作っている時代遅れな手法 を使う会社もあるけど・・・、ありえない、時間 の無駄です。 → また、 HTML の原型を残せないとデザイナーが必要 な場合、工数が増大 ではどういったテンプレートがいいか？ →HTML の原型をできるだけ残せること 各種フレームワークについてみていきましょう！

8 3-1. モック流用 (PlayFramework) Form template helpers が用意されている @helper.form(action = routes.Application.submit()) { @helper.inputText(myForm("username")) @helper.inputPassword(myForm("password")) } →HTML の原型が無く、使い物にならない・・・。 他にやり方ないの？ @helper.form(action = routes.Application.submit()) { } →Form タグの部分は微妙だがぎりぎり使えそう。 もう少しいい方法があったら教えてくださ い・・・。

9 3-2. モック流用 (Lift) Lift2.1 以前では特殊なタグを使用していた。 Welcome to app at しかし、 Lift2.2 以降では CSS の class 属性経由でデータ更新可能 Welcome to your Lift app at Time goes here これをスニペット側で操作できる class HelloWorld { def howdy = ".time" #>Helpers.formattedTimeNow } つまり、ロジックを画面側に埋め込んでいない！ → デザインとロジックの分離が可能

10 3-3. モック流用 (Django) 以下の HTML に値を設定することが可能 これをフォーム側で以下のように設定 def test(request): f = testForm({'name':'taro', 'email':'test@test.com'}) return render_to_response('test.html', {‘form1': f}) つまり、ロジックを画面側に埋め込んでいない！ → デザインとロジックの分離が可能 ただし、リスト等は { リスト名 } のようにロジック を記載するため、 Lift のように完全分離ではない。 Struts タグよりは分離できているためかなりいい！

11 4. 画面レイアウト Web サイトのほぼレイアウトが決まってい る 例えば、メニューが左側など。 Struts でいう、 Tiles のような機能がないと 画面修正が入った段階で厳しい・・・。 選定した 3 種類とも実現可能なため問題な し。 → 内容は想像できる感じなので省略

12 5. 入力チェック HMTL5 により、クライアント側でチェック ただし、 Web システムでサーバ側の入力 チェックは必須であり、簡素に記述できるこ とが重要 また、独自に拡張できることも必須 → これについては 3 フレームワークとも可能 Struts1 系のように Action クラスに記述したり、 XML ファイルに記述する方式は避けたい 各種フレームワークについてみていきましょ う！

13 5-1. 入力チェック (Playframework) チェックはコントローラで実施 Form testForm = form(Test.class).bindFromRequest(); if(testForm.hasErrors()) { // エラー処理 } Test.class 内のフィールドにチェックを記述 @Required @MinLength(4) public String username; @Required @Email public String email; フォームに関連付けているエンティティにアノテー ションを記述 簡素でわかりやすい。 Struts2 系と似ている

14 5-2. 入力チェック (Lift) 各フィールドに対して記述（今回は desc ） object desc extends MappedPoliteString(this, 128) { override def validations = valMinLen(3, "Description must be 3 characters") _ :: super.validations } Play 、 Scala に比べわかりにくい → Scala に慣れていないのもあるが・・・。

15 5-3. 入力チェック (Django) 入力チェックはデフォルトで必須チェッ クあり class TestForm(forms.Form): name = forms.CharField(required=False, max_length=20) email = forms.EmailField() Play 同様にシンプルでわかりやすい

16 6. 設定ファイル 基本的にどのフレームワークも CoC 系であ り、設定ファイルが少ない 細かい設定については省略 → マニュアル等を見てください・・・。

17 検討結果まとめ 点数で言うと「 Playframework(Java) 」で決 定？ → スキルアップする要素が少ないので NG 。 次点の「 Django(Python) 」にする？ → 人気言語 (Java 等 ) から Python へシフトする可能 性は低。大規模では厳しいので NG 。 最後の砦「 Lift 」で決まり？ → 日本での人気も微妙で難易度も低くないため、 日の目を見ないリスクが高いので NG 。 ということで Playframework2 系 (Scala) でど う？

18 なぜ、 PlayFramework(Scala) ？ Play は Java 系で人気が出る可能性有り →Java で CoC 系は少ない (Struts2 系もそうだが人気はぜんぜん出ていな い・・・。 ) →Play 技術者は少ないので高メリット。 (Google で検索してもサンプル ソースレベルばかり ) Scala テンプレート評判悪くない？ → 使えなかった場合、「 Groovy Templates plugin 」で 1 系と同じ感じで可 能。 (2 系のコンパイル時にエラーが出せる思想が台無しですが・・ ) そもそも、 Scala って人気無いでしょう？ → 関数型のスキルアップチャンス ( 気がついたら「 Java ではこうだっ た」のにと恥ずかしい人にならないために ) スクリプト系 (PHP 、 Ruby) から Scala へ流れる可能性あり → 海外サイトでは一部、そういった傾向あり JDK8 では JDK7 以前には無い Scala 同等の機能がある →Scala で事前にスキルを身につけておくことで今後スムーズ！

19 JDK8 の機能って？ ラムダ式 → クロージャは微妙な実装みたいですが・・・。 高級関数 → 高級関数を使用したコレクション処理は便利ですね。 → 特にフィルタ機能はソースが簡素になっていい！ 関数連鎖 → 俺が慣れてないだけかもしれませんが見にくい・・・。 仮想拡張メソッド →Scala だと「 trait 」 上記の意味がわかってない人は勉強不足のため、少な くても概要程度は調べておくことをお薦めします。 【参考】 http://www.infoq.com/jp/articles/java-8-vs-scala

20 最終結果 Web システムは Playframework2 系（ Scala ） →scala テンプレートに問題がある場合は 「 Groovy Templates plugin 」を使用 メイン処理以外の一部に「 Python 」 → バッチ処理等で Python を使う 将来、モバイル対応時には 「 JQueryMobile 」 → 勤務管理などはスマートフォン対応した い