第一回 JS-App勉強会@タネマキ LTメモ
こんにちは。
しばらく更新が停滞してしまいました。
今回は、第一回 JS-App 勉強会@タネマキという勉強会に参加させていただいたので、
勉強会内で行われた LT のメモを残します。
1, Knockout.js でさくさくアプリ開発 (@ken_zookie)
- ターゲット
- アプリに動きをもたせるエンジニア
- デザインも自分でやるエンジニア
- knockout.js
- linq.js
あたりを watch している
JavaScript = 開発者にやさしくない
- DOM 操作
- なんたら Element?
- ググりまくり
- Ajax
- ID 地獄、callback 地獄
- 画面の各パーツに ID,id, id…
- 画面の作り、見た目だけ変えたいのに、プログラムまで変わってしまう
何が問題なのか
開発したては特に問題なくさくさく実装できる。
出来立てのスパゲティは美味しい
ある日
度重なる仕様変更…
ID, コールバック地獄から抜け出したい
HTML から ID を消して、js 側でオブジェクトを持つ => MVVM
MVVM
- View
- HTML
- ViewModel
- js
- Model
- js その他
- ビジネスロジックもここに入る
- データバインディング
- コマンドバインディング が必要
=> Knockout.js
Knockout.js
- バインディングエンジン
- 宣言することで、HTML と ViewModel を紐付けて、同期させる
- ko.applyBinding
- HTML 要素と js のデータをバインディング
- ko.observable
- 変更通知プロパティ（ゲッタ、セッタ）
- 変更を監視して同期させる
- input だと blur 時に動機がかかる = リアルタイムじゃない
- 1 文字ごとに反映させる、リアルタイムにすることが可能
- ko.computed
- 依存しているデータを記憶し、それら全ての変更を監視してデータを更新
弱点
- Knockout.js = あくまでバインディングエンジン
- バインディングで解決できないことも有る
- Canvas は無理… タグのバインディングが出来ない手続き型
- SVG ならいけそう！ => ライブラリ製作中
MVVM はデザインに力を入れる、今の設計のあり方としてもっとも有力な候補
knockout = js-MVVM の叩き台として重要なポジション
2, AngularJS で勝機をつかむ(予定) (@Hivesbee)
あんぎゅら？
- 背景
- 業務は web アプリケーションの提案・拡販
- AngularJS を学習中
- 提案時の問題を絡めて、AngularJS を紹介する
- 提案
- モックが一番訴求力が有る
- 訴求力の有るモック
- 動きがある
- つたわらないなら、紙でいい
- 短期間で作成できる
- 客の熱が冷めないうちに
- 変更に柔軟に対応できる
- 動きがある
- jQuery
- DOM とイベントが強く結合している
- 汎用化しにくい => js フレームワーク
js フレームワーク
- サーバが受け持つ担務を吸収してくれる
- ルーティング
- 画面パーツ結合
- MVC の V と C をサーバから引き剥がす
- js 側の「脱 JSP」
- データバインド
- リスト
- フィルタリング・ソート => 今回はAngularJSを採用
AngularJS
※今回のゴールはモックを作るまで
- 低コスト
- Scopeという概念のおかげ
- シナリオテストが用意
- Google 提供のフレームワークだから継続性も安心？
Scope
- コントローラの制御範囲を表す * = DOM のスコープと一致した範囲
- コントローラの入れ子
- DOM とコントローラが 1:1 対応 _ ファイル単位で分割、要素ごとに分割が可能 _ 構造に依存しないため柔軟
e2eTesting
- シナリオテスト用のフレームワーク
- いくら提案用のモックとはいえバグは出したくない
開発効率を加速させるもの
- ルーティング、ng-View
- $Log（console.log の代替？）
向いてるもの
- 簡単なアプリ
- 業務系アプリ
向いてないもの
- UX を考慮したアプリ
- アニメーションとの連携
イケてないところ
- 実は学習コストはバカ高い
- 導入はたやすく、ある程度を超えると難易度が跳ね上がる
- Backbone.js より重い
まとめ
- 簡単なものなら簡単に作成できる * モックアップ向け
3, 設計ポイントの比較で知る Backbone.js @utwang
- Backbone * Rails の設計ポイント
- 破綻しない Web アプリ開発 _ 設計することで破綻を防ぐ _ 設計ポイントから Backbone の特徴を知る
Backbone.js
- RESTful な JSON インタフェースを備えた js ライブラリ
- Router, View, Model, Collection で構成される
- View がコントローラのような役割
“必要最小限”の設計
- チーム開発
- 調整が必要になったときの土台
- インクリメンタル設計
何を設計するか？
- システムのInput と Output が明確になれば振る舞いが検討できる
js での input と output
- HTTP リクエスト
- HTML
- DB への I/O
jsView 設計
- 動的/静的な DOM の分別
- Backbone の View と結びつける DOM 要素を定義する
Model
- 対応する REST API を 1 リソースとして扱う
- Model がやりとりする API エンドポイントを決める
- Model にエンドポイントを設定すると、REST クライアントのように振舞ってくれる
- API から受け取る JSON を元に Model に必要になるプロパティを決める * API から帰される JSON は必ずしも Model で扱いたいフォーマットとは限らない
Backbone での問題点
- DOM 要素単位での VIew クラスの割り当て _ View のネスト構造が複雑になる _ ファイル単位
Rails × Backbone
- サーバは JSON を返す API だけになるので、
Rails のようにサーバが重たいものは特に必要ない
4, CoffeeScript + Grunt
- 中野 稔@nenjiru
- カヤックの HTML ファイ部のひと
- Coffee を良い感じにコンパイルするgrunt-unite-coffeeを作った
5, Node.js + Arduino
duino
- Nodejs で Arduino をいじれるようにするライブラリ
- Arduino 用ファイルもあって、それを Arduino に書き込んでおくことで、js から API を叩ける
6, Cucumber による HTML5 アプリの受け入れテスト自動化 (@shida)
- ビー・アジャイル代表
cucumber
- いろんな言語で動く
回帰テスト？を自動化- リグレッションを恐れなくて済む
- コードに手を入れるのが怖くなる
- リファクタしてコードをクリーンに保てる
- 積極的に細かいバグ修正や仕様変更に応えられる
- テストコード自体が仕様書となる
- ドキュメントを書く手間を軽減できる
回帰テスト【リグレッションテスト】regression test
プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか確認するテスト。
もっとも一般的に行われるのは、プログラムのバグを修正したことによって、そのバグが取り除かれた代わりに新しいバグが発生していないかどうか、という検証である。
回帰テストとは 〔リグレッションテスト〕 〔退行テスト〕 – 意味/解説/説明/定義 ： IT 用語辞典
TDD って工数増えないの？ ？
- 過去のテスト用メソッドを流用できる
- コーディング工数は確かに触れるけども、
- 総合的に見れば工数が減る
- ドキュメントを書く工数
- テスト工数
- 引き継ぎや教育の工数
受け入れテスト？の工数
受け入れテスト（うけいれてすと） acceptance testing / 検収テスト / 承認テスト
納入されたシステムやソフトウェアの受け入れを判定するための公式テストのこと。
システムやソフトウェアの機能・性能などが本来的な目的や使用意図に合致しているのか、妥当性確認を行う。
一般に受け入れテストは、オファーしたものが所定の条件に適合しているかを確認する作業であり、次工程に進むことに承認を与える過程である。 原則として利用者や購入者が主体となって行うテストを指すが、元請けが下請けからの納品物を検収する作業をいう場合もある。
書き方
- 日本語で書ける
- お客様にとって可読性の高いテストが書ける
- １行＝１ステップ
- Selenium との連携もできる = ブラウザを操作することも出来る