自社システムにおける 最適なフレームワーク 2012/08/03 前提条件 • 機能は「自己評価」、「勤務表」、「掲示板」、 「ログイン機能」を想定 • 使用するフレームワーク等は全て無料である が未来があるものを使用する • 作るにあたり最適なフレームワーク、ソフトを 提供する • 画面はHTML5で作成することが前提 • PC、スマートフォンに対応できるような構成を 考えること 先月までの検討内容 • Javaで開発だとスキルアップにならないのでは →PlayFramework1系では新しい要素が薄くない? →まして2系でてるのに1系っていまさらないでしょう・・・。 →じゃあ、他のフレームワークは? • Lift (Scala)ってどう?マイナーすぎないか。 →そもそもScalaってどうなの? • 対抗馬としてDjango(Python)はどう? →Google App Engineで使われているよ。 →でも、開発案件でPython使っているのほとんど無い →動的型付けだと実行時にバグ生みやすく大規模厳しい • とりあえず、PlayFramework2.02(Java)、Lift2.4(Scala)、 Django1.4(Python)で検討しましょう! 各フレームワーク比較 No 項目 1 言語人気 2 Playframework Lift Django ◎(Java) ×(Scala) △(Python) ドキュメント量(Web) ○ △ ◎ 3 画面モックの流用 △ ◎ ○ 4 画面レイアウト ○ ○ ○ 5 入力チェック ◎ △ ◎ 6 設定ファイル(少ないこと) ○ ○ ○ 7 使いやすさ ◎ △ ○ 総合点数 16 10 15 • • • • • 各種フレームワークを上記観点で比較。 詳しい説明については以下に記載。 HTML5を使用することを前提にしているため、ビュー周りを中心に評価。 個人的な主観も入っていると思いますので、激しい突っ込みは勘弁していただけると・・・。 総合点数は◎:3、○:2、△:1、×:0で採点 1. 言語人気(2012/07) Jun 2012 Jun 2011 1 2 2 Programming Delta Status C 18.331% +1.05% 1 Java 16.087% -3.16% 3 6 Objective-C 9.335% +4.15% 4 3 C++ 9.118% +0.10% 5 4 C# 6.668% +0.45% 6 7 Basic 5.695% +0.59% 7 5 PHP 5.012% -1.17% 8 8 Python 4.000% +0.42% ・・・ ・・・ ・・・ ・・・ ・・・ 45 ? Scala 0.237% ? 【参考】http://www.tiobe.com/index.php/content/paperinfo/tpci/ ※主要検索エンジンに検索された結果を元に算出しているようです。 2. ドキュメント量 No 項目 1 Web全体 960,000 5,710,000 2,580,000 51,100,000 2 日本語のみ 300,000 1,400,000 5,990,000 5,580,000 3 日本語+1年 14,100 6,480 31,900 33,000 4 日本語+1ヶ月 2,370 1,260 6,650 6,360 5 日本語+1週間 817 601 3,040 2,520 総合結果 ○ △ ◎ ー • • • • • • Playframework Lift Django Struts Googleを使用して測定(2012/07/30)、参考として「Struts」も記載。 検索キーは「Playframework」、「Scala Lift」、「Python Django」を使用。 「Playframework」は「Play」と略されることが多いため若干不利? Djangoは日本語のみのほうが全体より多い、何故・・・、誰か教えて?? 直近も全般もDjangoが3つの中では人気が高い。Strutsとほぼ同じ件数。 1年間で言うと「Lift」よりも「Playframework」のほうが人気。 3.画面モックの流用 • Web開発において、画面モックを流用できることは重 要。 →設計段階で画面モックを作成する →モックを流用できれば画面開発の工数削減 →ときどき、EXCELで画面作っている時代遅れな手法を 使う会社もあるけど・・・、ありえない、時間の無駄です。 →また、HTMLの原型を残せないとデザイナーが必要な 場合、工数が増大 • ではどういったテンプレートがいいか? →HTMLの原型をできるだけ残せること • 各種フレームワークについてみていきましょう! 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()) { <input type="text" name="name" value="@myForm("username").value“> <input type=“password" name=“password" value=""> } →Formタグの部分は微妙だがぎりぎり使えそう。 • もう少しいい方法があったら教えてください・・・。 3-2. モック流用(Lift) • Lift2.1以前では特殊なタグを使用していた。 <lift:HelloWorld.howdy> <span class="my_class">Welcome to app at<b:time/></span> </lift:HelloWorld.howdy> • しかし、Lift2.2以降ではCSSのclass属性経由でデータ更新可能 <span class="lift:helloWorld.howdy"> Welcome to your Lift app at<span id="time">Time goes here</span> </span> • これをスニペット側で操作できる class HelloWorld { def howdy = ".time" #>Helpers.formattedTimeNow } • つまり、ロジックを画面側に埋め込んでいない! →デザインとロジックの分離が可能 3-3. モック流用(Django) • 以下のHTMLに値を設定することが可能 <input type="text" name="name"/> <input type="text" name="email" /> • これをフォーム側で以下のように設定 def test(request): f = testForm({'name':'taro', 'email':'[email protected]'}) return render_to_response('test.html', {‘form1': f}) • つまり、ロジックを画面側に埋め込んでいない! →デザインとロジックの分離が可能 • ただし、リスト等は{リスト名}のようにロジックを記載す るため、Liftのように完全分離ではない。 • Strutsタグよりは分離できているためかなりいい! 4.画面レイアウト • Webサイトのほぼレイアウトが決まっている • 例えば、メニューが左側など。 • Strutsでいう、Tilesのような機能がないと画面 修正が入った段階で厳しい・・・。 • 選定した3種類とも実現可能なため問題なし。 →内容は想像できる感じなので省略 5.入力チェック • HMTL5により、クライアント側でチェック • ただし、Webシステムでサーバ側の入力チェック は必須であり、簡素に記述できることが重要 • また、独自に拡張できることも必須 →これについては3フレームワークとも可能 • Struts1系のようにActionクラスに記述したり、 XMLファイルに記述する方式は避けたい • 各種フレームワークについてみていきましょう! 5-1.入力チェック(Playframework) • チェックはコントローラで実施 Form<Test> testForm = form(Test.class).bindFromRequest(); if(testForm.hasErrors()) { // エラー処理 } • Test.class内のフィールドにチェックを記述 @Required @MinLength(4) public String username; @Required @Email public String email; • フォームに関連付けているエンティティにアノテーションを 記述 • 簡素でわかりやすい。Struts2系と似ている 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に慣れていないのもあるが・・・。 5-3.入力チェック(Django) • 入力チェックはデフォルトで必須チェックあり class TestForm(forms.Form): name = forms.CharField(required=False, max_length=20) email = forms.EmailField() • Play同様にシンプルでわかりやすい 6.設定ファイル • 基本的にどのフレームワークもCoC系であり、 設定ファイルが少ない • 細かい設定については省略 →マニュアル等を見てください・・・。 検討結果まとめ • 点数で言うと「Playframework(Java)」で決定? →スキルアップする要素が少ないのでNG。 • 次点の「Django(Python)」にする? →人気言語(Java等)からPythonへシフトする可能性 は低。大規模では厳しいのでNG。 • 最後の砦「Lift」で決まり? →日本での人気も微妙で難易度も低くないため、 日の目を見ないリスクが高いのでNG。 • ということでPlayframework2系(Scala)でどう? なぜ、PlayFramework(Scala)? • PlayはJava系で人気が出る可能性有り →JavaでCoC系は少ない(Struts2系もそうだが人気はぜんぜん出ていな い・・・。) →Play技術者は少ないので高メリット。(Googleで検索してもサンプルソースレ ベルばかり) • Scalaテンプレート評判悪くない? →使えなかった場合、「Groovy Templates plugin」で1系と同じ感じで可能。(2 系のコンパイル時にエラーが出せる思想が台無しですが・・) • そもそも、Scalaって人気無いでしょう? →関数型のスキルアップチャンス(気がついたら「Javaではこうだった」のにと 恥ずかしい人にならないために) • スクリプト系(PHP、Ruby)からScalaへ流れる可能性あり →海外サイトでは一部、そういった傾向あり • JDK8ではJDK7以前には無いScala同等の機能がある →Scalaで事前にスキルを身につけておくことで今後スムーズ! JDK8の機能って? • ラムダ式 →クロージャは微妙な実装みたいですが・・・。 • 高級関数 →高級関数を使用したコレクション処理は便利ですね。 →特にフィルタ機能はソースが簡素になっていい! • 関数連鎖 →俺が慣れてないだけかもしれませんが見にくい・・・。 • 仮想拡張メソッド →Scalaだと「trait」 • 上記の意味がわかってない人は勉強不足のため、少なく ても概要程度は調べておくことをお薦めします。 【参考】 http://www.infoq.com/jp/articles/java-8-vs-scala 最終結果 • WebシステムはPlayframework2系(Scala) →scalaテンプレートに問題がある場合は 「Groovy Templates plugin」を使用 • メイン処理以外の一部に「Python」 →バッチ処理等でPythonを使う • 将来、モバイル対応時には「JQueryMobile」 →勤務管理などはスマートフォン対応したい
© Copyright 2024 ExpyDoc