Transcript 自社システムにおける 最適なフレームワーク 2012/08/03 前提条件 機能

自社システムにおける
最適なフレームワーク
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」
→勤務管理などはスマートフォン対応したい