1 / 20

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

自社システムに おける 最適 なフレームワーク. 2012/08/03. 前提条件. 機能は「自己評価」、「勤務表」、「掲示板」、「ログイン機能」を 想定 使用するフレームワーク等は全て無料であるが未来があるものを使用 する 作るにあたり最適なフレームワーク、ソフトを提供 する 画面は HTML5 で作成することが 前提 PC 、 スマートフォンに対応できるような構成を考えること. 先月までの検討内容. Java で開発だとスキルアップにならないのでは → PlayFramework1 系では新しい要素が薄くない？

steven-meyers
Download Presentation

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

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/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. 各フレームワーク比較 • 各種フレームワークを上記観点で比較。 • 詳しい説明については以下に記載。 • HTML5を使用することを前提にしているため、ビュー周りを中心に評価。 • 個人的な主観も入っていると思いますので、激しい突っ込みは勘弁していただけると・・・。 • 総合点数は◎：3、○：2、△：1、×：0で採点

  5. 1. 言語人気（2012/07） 【参考】http://www.tiobe.com/index.php/content/paperinfo/tpci/ ※主要検索エンジンに検索された結果を元に算出しているようです。

  6. 2. ドキュメント量 • 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()) { <input type="text" name="name" value="@myForm("username").value“> <input type=“password" name=“password" value=""> } →Formタグの部分は微妙だがぎりぎり使えそう。 • もう少しいい方法があったら教えてください・・・。

  9. 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 } • つまり、ロジックを画面側に埋め込んでいない！ →デザインとロジックの分離が可能

  10. 3-3. モック流用(Django) • 以下のHTMLに値を設定することが可能 <input type="text" name="name"/> <input type="text" name="email" /> • これをフォーム側で以下のように設定 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<Test> 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」 →勤務管理などはスマートフォン対応したい

More Related