@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

トップ > javascript

第38回HTML5とか勉強会 #html5j に行って来ました

event html5 javascript

多少遅れて行ったので、途中からですけれども。急遽サテライト会場も出来るくらい大盛況だったようです。

JavaScriptテスト最新事情 Why? What? How?

資料 → JavaScript Unit Test Why? What? How?

  • なぜJavaScriptでテストを書くのか？
    • 実践アジャイルテスト
      • ビジネス面⇔技術面 の軸
      • チームを支援する⇔製品を評価する の軸
    • 結合テストは左上の領域
      • ビジネス面を支援する、技術面のテスト
      • どんなサービスでも必要
      • 自動化が推奨
    • ユニットテストは左下の領域
      • チームを支援する、技術面のテスト
      • 開発者による開発者のためのテスト
      • 大規模では必須
      • 自動化が必須
    • TDDと黄金の回転
  • JavaScriptを取り巻く状況
    • 規模も大きくなって、大事になってきている
    • ロジックをJavaScriptで書くことも多くなった
    • テストをする環境も充実してきている
      • node.jsによる恩恵
    • MV*が流行っている
      • モジュール化の仕組みが成熟してきている
    • ユニットテストがしやすくなった
  • JavaScriptのテストの難しい理由
    • コードがViewと結びつきやすい
    • どうしてもブラウザで実行されるので扱いづらい
  • 解決策
    • コードがViewと結びつきやすい
    • どうしてもブラウザで実行されるので扱いづらい
  • MV*
    • 色々宗派はあるが、やりたいことは、ロジックとビューを分離することである
    • 分離さえ出来てしまえば、ロジックのテストが出来るはず
  • 例
    • メール一覧
      • Model:全件取得する、宛先絞り込み、タグで絞込み
      • View：受け取ったリストを表示する
  • Modelのテストをしよう！
    • Viewのテストは。。。
      • DOMのテストは書きにくい
      • ユーザビリティのテストは出来ない
      • 画面を見ながら試行錯誤が必要になる
      • ある程度できてきたらテストにチャレンジしてみれば？
  • テスト
  • テスティングフレームワーク
    • テストの記述と実行を担当する
    • 成熟してきているのでどれを選んでも間違いはないレベル
  • 実行環境が重要
    • 実ブラウザでテスト
      • 本物だけど、面倒くさい、遅い
    • ヘッドレスブラウザ（PhantomJS）
    • シミュレータ（jsdom, envjs）
      • 偽物だけど早い
  • リモートテストランナー
    • ブラウザをキャプチャリングして、リモートでテストを実行するツールです
      • 一般的な言葉ではないかも
    • 実ブラウザの欠点を補う
    • 同時に複数のブラウザでTDDが可能
    • Testem、Karma(旧名称 Testacular)、JsTestDriver、Buster.JSなど
  • DEMO
    • Jasmine + Testemを使うのが導入が簡単
    • 簡単なFizzBuzz
    • npm install testemで一発でインストール
    • コマンドでテストを実行する
      • TDDする、実行すると、実装が無いのでエラーになる
    • 実装を書いてあげる
      • テストが成功する
    • テストを追加していく
    • 特に設定ファイルとか書かなくても始められるので、お手軽
    • PhantomJSとも連携できる
  • それ以外
    • カバレッジ
    • 静的解析
    • Lint
    • 型チェク（Cloure、TypeScript
    • それらをまとめるGruntなど
  • まとめ
    • JSでもユニットテストは大事
    • モデルのテストからはじめよう
    • テスト関連ツールの深化がやばい
    • TDDで楽しい開発

いつやるのか？今でしょ！

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

jasmine

資料 → Unit-Testing With Jasmine // Speaker Deck

  • jasmineを使ったユニットテストについて
    • BDDとは？
    • jasmineとは
    • それらについてくわしく
    • jasmineで使えるツール
    • クリスチャンヨハンセンの言葉
      • テスタビリティはグッドデザインである
      • もしテストするのが難しければ、それはコード自体が良くない
    • jasmineはBDDのツールです
  • BDDとは？
    • BDDはTDDから派生したもの
    • TDDの混乱や誤解の6個
      • どこから始めるのか
      • なにをテストするのか
      • なにをテストする必要はないのか
      • どの程度テストすれば良いか
      • テストを何と呼ぶか
      • テストが失敗した理由をどう理解するか
    • その回答
      • これから作成しようとしているプログラムに期待されている振る舞いや制約条件を記述する
      • アプリケーション全体ではなく、小さく1つのことのみ記述する
      • テストを文章のように記述する
      • ビジネスの観点を入れる
      • JasmineはBDDをJavaScriptで実践するためのツール
  • Jasmineとは？
    • ある仕様に対して、コードがどんな振る舞いをするべきかを表現するのを手助けしてくれるツール
    • ダウンロードすると、サンプルが含まれている
    • Jasmineは本当にシンプル
      • describe: Suite（スィート）と言う
      • it：Spec（スペック）と言う。プログラムの断片がおこなうこと
      • describeの中でdescribeを定義をすることもできる
      • expect：期待される振る舞いを書く。英語の文章のようになる。
      • toEqualのような比較することをMatcherと言う
      • ○○が含まれている場合のMatcherは、toContain
      • Matcherの一覧はドキュメントを参照
  • Jasmineについて詳しく
    • Before/After
      • beforeEach() / afterEach()
      • たいていの場合はセットです
    • Async
      • waitsFor
      • 指定の時間まで繰り返す
      • 1000ms以内に値を返さないと失敗とみなすなど
    • SPY
      • Test Double : UTのパターンのひとつ
      • 関数に成り代わって、その関数がどう呼び出されたのかを教えてくれる
      • 関数が呼び出されたか、何回、引数は？など
  • Jasmineまとめ
    • Jasmine単体で使えるわりには、色々出来る。
    • Jasmineは歴史があるので、様々な補助ツールがある
  • 厳選ツール
  • まとめ
    • テストを書くことは、デベロッパーズブロックに解消につながる
      • 文章がかけなくなることをライターズブロックと言う
      • 書くことでしか解決しない
    • ライターが推敲するように、デベロッパーはリファクタリングする
    • そのためにはテストが必要
    • アウトラインをテストで書くことでリファクタリングに強くなる
    • テストがあれば再利用しやすくなる

テスト駆動JavaScript

テスト駆動JavaScript

SinonJS

資料 → Sinon.JS

  • SinonJS
    • 神話の中のスパイの名前
  • Sinon.JSとは？
    • Test Doubleのライブラリ
    • QUnitやMochaなどと組み合わせて使用する
    • Test Doubleとは？
      • テストしずらい部品をしやすいものに置き換えてテストする
  • Spy
    • Queryのtriggerの例
      • 1回しか呼び出されないときは簡単だが、2回呼び出されたことをテストするのは面倒である
      • カウンターとかで判断しなければならないため
    • Spyはその面倒なことを解決してくれるもの
      • スパイオブジェクトを作る
      • スパイオブジェクトは、何回呼び出されたか、どんな引数で呼ばれたかを保持する
      • 通常であればカウンターを使って書いたものが、簡単に表現出来るよ
      • イベントは、発火していなくても通ってしまう不具合等が発覚しづらい
      • 書いた順に呼ばれるので、Spyであれば見やすい
      • callbackは記述の順番と実行の順番が異なるので見にくい
    • 既存のメソッドをSpy化することも出来る
      • jQueryのremoveメソッドをテストするのは面倒である
      • removeをスパイする
      • var spy = sinon.spy(jQuery.fn, 'remove');
      • 既存のメソッドをどのように呼ばれたかがわかるようになる
      • Spyは、書き換えてしまうので、Before,AfterでRestoreする必要がある
  • Stub
    • Spyを拡張しているのでSpyの機能を持っている
      • 元の関数を上書きする
      • 例えば、window.confirm等（書き換えないとテストしてられない）
      • スタブでwindow.confirmを上書きする
      • どう振る舞うかを設定することが出来る。例えば、必ずtrueを返す等
  • Mock
    • Stubを拡張しているので、Spy、Stubの機能を持っている
    • 予め、どう振る舞うかを定義しておく
    • mock.verify()を呼べば、振るまいが定義した通り動いたかを判定できる
    • MockとStubは同じ事が出来るので、使い分けすれば良い
      • Stubの方がわかりやすいかもしれない
  • Fake Timer
    • 日付に関するところが面倒である
      • 日曜日か判定するテストは、日曜日しか通らなくなる
      • UseFakeTimeで、日付を指定する
      • 必ずリストアすること
    • setTimeoutなどのTimerを変えることが出来る
      • 時間を進めることが出来る
      • clock.tick()関数を使う
      • 簡単に、同期的にテストをすることが出来ま
  • Fake XHR
    • リクエストがちゃんと飛んでいるかを確認する
      • 通信する部分をまるごと書き換える
    • 別の書き方で、FakeServerもある
      • 比較的直感的になる
  • まとめ
    • Sinon.jsとても便利
      • でも、使いすぎには注意しましょう
    • 何でもかんでも、MockやStubにするのはやめておこう
      • 何をテストしているのかわからなくなる
  • 宣伝
    • CodeGridのサービスをやっています
    • 週3回配信
    • 月額840円で、初回1ヶ月は無料

JSテストフレームワークの比較（QUnit、Mocha、Jasmine...）

資料 → Java script testing framework for around html5 studies-

講演者による座談会

  • テストをテスト未経験者に取り入れてもらうには
    • 佐伯さん
      • 自分の経験では、最初に訓練をうけたので、それが当たり前だと思っている
      • 開発標準を決めてしまう会社なので、盛り込んでしまえば良い
    • 斎藤さん
      • テストが楽しそうというところからはじまった
      • コードを書く上で大切なひとつのプロセスである
      • ペアプロでやっていくのがいいのかなぁ
      • 赤いものを緑にしたくなるゲーム性
      • 一緒にみていくのがいい
    • 佐藤さん
      • テストのスケルトンとか、生成するものを作ってくれた
      • 書き始めるまでが、よっこらしょだったのが、楽になった
      • とりあえず、コンストラクタまででいいから書けよがルール
    • 外村さん
      • ちょっとしたライブラリから始めたらいいのではないかな
      • いきなりアプリだと難しい
  • テストを書いていてよかったと思ったエピソード
    • 斎藤さん
      • テストがある状態のコードがあれば、いきなりリファクタリング出来る
      • まず、綺麗にしてからコーディングすることが可能
    • 佐藤さん
      • コードの書出しが苦しむところ
      • まずテストを書いてしまえば、滑り出しがよくなる
      • コメントで書いていたことをテストに置き換えた
    • 佐伯さん
      • テスト無しでリファクタリングはありえない
      • 途中で任された場合
      • ちゃんとメンテナンスされていれば、そこから仕様を読み取れるので良いですよね
    • 外村さん
      • 1年前に書いたコードをメンテナンスすることになった時に良かったと感じました
  • システムの規模は
    • 佐伯さん
      • 逆に聞きたいです
    • 斎藤さん
      • プロジェクトのしごとをあんまりしていないので、あんまりわかんないです
      • 100％書きたいですが、一旦メインで30％書いて、あとはドキュメンテーション
    • 佐藤さん
      • kintonを作っています、3年以上開発
      • JavaScriptだけで17万行あります
      • フレームワークにClosureライブラリを使っているので、冗長感はあります
      • テストコードは2万行強、カバレッジは計測していない
      • 結合テストも合わせてやっていた。結合テスト偏重だった
      • だんだん立ち行かなくなったので、UTを今増やしているところ
      • カバレッジは？
      • 30%くらいですかね
  • 結合テストはどこまでやっているか
    • 佐伯さん
      • やんなきゃいけない。Seleniumでやっている
      • Unitが足りてないので、片手落ち
    • 斎藤さん
      • Unitテストはやっているけど、結合テストはやっていないような状況
    • 佐藤さん
      • Seleniumはやっていると膨大な時間がかかってしまう
      • 受け入れテストレベルに限定すると、現実的な時間で終わるようになる
      • Seleniumは何を作るべきかを担保する
      • 中身については、Unitでやっていこうよ！となっています
      • Jenkinsで回しています
      • 対応ブラウザもろもろで
  • UI（View）のテストをどこまでやっているか
    • 佐藤さん
      • Viewの部分はあんまり書いていない
      • Renderで要素が入った・・・くらいまでしかやっていない
      • Clousureライブラリだと、JavaScriptの型チェックが出来る
      • よってビューのテストは型チェックだけ通ればOKだとおもわれる
      • それ以上のロジックが書かれていないことが前提
    • 斎藤さん
      • ロジックの部分がほとんどです
      • Renderに入ったとこくらいです
    • 佐伯さん
      • やってないっす
      • 導入する時に、ここまでやればいいんだよ！って決めてしまえばいいだけです
      • むしろ、ちゃんとアーキテクチャを設計するのが先で、後は、努力目標とすればよいと思います
  • TDD VS BDDについて
    • 外村さん
      • どっちでもいいと思います！
    • 佐藤さん
      • 違いが正直わかっていません
      • 書き方レベルで言うと、BDDの方が好きです
      • テスト名を文字列で定義出来るのがいいですね
      • 2重のフィードバック・ループを考えるとBDDになるのではないでしょうか。
    • 斎藤さん
      • 平和主義なので、どっちでもいいです
      • スタイルとしては、BDDの方が好みではあります
      • テストがあればいいよ
    • 佐伯さん
      • テストの見通しをもった上では、BDDの方がいいのかなとは思います
      • ペアプロでやるのでは、BDDの方がやりやすいかもしれないですね
QAタイム
  • テスト結果の出力は？
    • 佐藤さん
      • テストはCIツール（Jenkins）でやっています。
      • リポジトリにコミットするごとに動きます。
      • それで、エラーがあれば通知しています。
  • テストの工数はどうやってもらえますか？
    • 佐藤さん
      • 難しいので、誤解を恐れずに言えば、多めに工数を取ればよいです。
      • コードを品質を担保するためには、その工数を取ればいいです。やましいとかではないです。
      • 細かいこと言ってもしょうがないです。技術じゃない人に対して。
      • これを実装するなら、これくらいと言ってしまえば良いのでは。
    • 佐伯さん
      • お客さんに、最初に説明をしました。
      • その上で、納得して頂く。結構しっかりやっていたパターンです。
    • 外村さん
      • バグったらその分工数食うんだから、最初から取っておいてもいいのではないか

Googleのえーじさん

Effective JavaScript JavaScriptを使うときに知っておきたい68の冴えたやり方

book javascript

Effective JavaScript JavaScriptを使うときに知っておきたい68の冴えたやり方

Effective JavaScript JavaScriptを使うときに知っておきたい68の冴えたやり方

を読みました。

前半5章までは、普通にJavaScriptで実装していく上での注意点やベストプラクティスについて述べています。小規模の開発であればあまり問題にならないところも、規模もそれなりに大きくなって、複数人で開発していると困ったことになるあれやこれやの説明になっています。
6章では、さらに踏み込んで、ライブラリやAPIを書く時に注意しなければならない点に書かれていて、参考になることも多いですね。今後自分で作るときには気をつけようと思います。
7章では、並行処理でPromiseあたりの話ですね。非同期処理や、Callbackを考えるうえで非常に勉強になるかとおもいます。

目次

  • 第1章 JavaScriptに慣れ親しむ
  • 第2章 変数のスコープ
  • 第3章 関数の扱い
  • 第4章 オブジェクトとプロトタイプ
  • 第5章 配列とディクショナリ
  • 第6章 ライブラリとAPI設計
  • 第7章 並行処理

東京Node学園 8時限目 #tng8 に行ってきました

event nodejs javascript

と言うことで、メモを投下。

Param Tuner

資料 → ParamTuner 東京Node学園#8
しばらく中に入れなくて、聞けてませんでした。
統計解析の話だったようです。資料見て自習します。

  • QA
    • JavaScriptで統計解析やるにあたってデータの量とかはどうなんですか？
      • 実際にはHadoopで裏でやっていますが、その前段階の傾向を見るのに使っています
      • なので、そんなにデータは多くはないです。

Nodeとプロミスと時々、関数型

資料 → Node, Promises and Functional Programming // Speaker Deck

  • ことの経緯
  • 非同期処理を書く時に何を考えるのか？
    • タスク同士の依存関係を考える
    • 必要な操作の順序を考える
    • 最後に、その制御フローを考える
  • コールバック VS プロミス
    • コールバックの良くないところ
      • 処理をモジュール化したり組み立てたりするのが難しい
      • 逐次処理か並列処理かを明示的に制御する必要がある。
      • あと、ネストが深くなってしまう問題があるけど、重要な論点ではない。
  • 例
    • 複数のファイルを並列的にfs.statしてmtimeを取り出す処理
    • 複数ファイル全ての結果が揃ったら次の処理を行う
    • この実装をした後に、追加の処理を入れたいとする
      • 1つ目のファイルからサイズを取り出したい処理を追加
    • 単純に追加すると、ファイルに2度アクセスすることになり効率が悪くなる
    • 正しい順序で、効率良く処理させると、実装がかなり複雑になる
    • 結果
      • 正しくコードを書くのが大変
      • 設計の意図が明確にならないので、メンテナンスが大変
      • 逐次処理か並列処理かで、後続の処理を実装する方法が変わってしまう
  • プロミスとは
    • 完了していないかもしれない計算の結果が入っている箱
    • プロミス自体も値なので、関数の間で受け渡しが出来る
    • 計算が完了すると特定の処理を呼び出したりする（ものが多い）
  • しかしながら
    • 必ずしも全てのプロミスが関数型ではない
    • 言語やライブラリによって異なる
  • 関数型とは？
    • あらゆるものを値として扱うことで問題を解く手法
    • 命令型はHowを記述して伝える
    • 関数型はWhatを値同士の関係によって記述して伝える
      • 関数は、値同士の依存関係を定義するもの
    • 関数は、引数を得て、戻り値を返す
      • 複数の関数を合成して、大きな関数にする
      • 別の関数への入力として、パイプラインを作る。
  • 関数型プログラミング
    • あらゆるものを値として扱い、
    • 値同士の依存関係を関数で表現し、
    • 複数の関数を合成してより大きな関数を作る
  • 先の例で言うと
    • 複数の非同期計算を合成して大きな計算をする
    • 後で処理を追加したいときには
      • thenを使う
      • thenは、プロミスに依存する別の非同期処理を記述する
      • thenで記述された処理は、値がいつ利用可能になり、どんな順番で処理するかを気にする必要がない
  • プロミスとthenを使うと
    • 記述された依存関係を元に実行順序を自動的に解決するので、
    • 依存関係でプログラミング出来る
  • 結果を待ちたい場合
    • プロミスの配列をリストに対するプロミスにする
    • これによって待合せが表現できる
  • 課題に戻って
    • プロミスを使うと、必要な操作の順序を考えなくても良い
    • なので、非常にシンプルにプログラミングが出来る
  • プロミスは難しい
    • 先のブログに対する反論記事
    • プロミスを使うと
      • thenやlistで意味的に隠蔽してしまうので、認知的コストが大きい
      • プロミスを使ったものは、学習コストがかかる
  • 反論に対する反論
    • 簡単であるかよりも、シンプルであるかを問うべき
    • やりたいことが変わった時に、コードの変更が少なくて済む
  • 結局
    • どちらもただしいと思う
    • コストとメリットを天秤にかける
      • ただ、非同期プログラミングのコストの支払期限は意外と早いのでは？
  • まとめ
    • コールバックはとっつきやすい
    • 変更に強くするならプロミス
  • メッセージ
@koichik さんから
  • 3年ほど前はnode.jsでもプロミスを使っていました
  • しかしながら、あんまり評判が良くなかったようです。
  • プロミスが嫌われていたのは、プロミス自身ではなくて、JavaScriptでのプロミス自身がいけていなかったから。
  • 先の例で言うと、実際にはエラー処理をしなければならないが記述されていない
  • エラー処理を実装すると、結局冗長にせざるを得ない
  • 現在、node.jsではメカニズムとして一番シンプルなコールバックのみ提供している
  • プロミスの実装は、別のモジュールで色々な人が作っている
  • node.jsのスタンスとしては、モジュールとして好きなものを作っていいよということが現在のスタンス

LT

LET IT CRASH!?

資料 → 東京Node学園#8 Let It Crash!?

  • Let It Crash?
  • 堅牢なコードを書くには？
    • ディフェンシブプログラミング
      • 失敗する可能性があるものは失敗するので、失敗に備えておこう
      • 引数などはチェック、例外を捕まえる
      • アプリがエラーから回復する
      • 通常処理とエラー処理が混在する
    • Let it crash
      • 失敗に備えない
      • 例外を捕まえないで、スーパーバイザがエラーから回復する
      • 通常の処理と分離出来る
  • スーパーバイザ
    • 1つクラッシュすれば、それだけリトライ。One4One
    • 1つクラッシュすれば、関連を全てリトライ。All4One
  • You! さっさとクラッシュしちゃいなよ!
    • process.on('uncaughtException')
      • OnErrorResumeNextとは違うのですよ。
    • domain.on('error')
      • エラーを無視するな
      • エラーが起きたら、プロセスをシャットダウンしなさい

といった所でLTタイム終了しちゃいましたが、まだ半分までです。
domainのAPIドキュメントを見てね！

LT2 Object.defineProperty

資料 → 不明

  • Object.defineProperty
var obj = {};
Object.defineProperty(obj, 'prop', {
    // ここにプロパティのオプションを書く
});
  • オプション
    • configure
      • falseを設定すると、上書きとか削除とかできなくする
    • enumerable
      • for inのループで出てこなくなる
    • wraitable
      • 上書きできなくなる。
      • 定数とか。厳密には定数とは違う。現状のJavaScriptで実現出来る方法。
    • get, set
      • getter / setter が定義が出来る
  • 複数のプロパティをまとめて定義することも可能
Object.defineProperty(obj, {
    'prop1': {
         // オプション
    },
    'prop2': {
        // オプション
    }
})

サーバサイドJavaScript Node.js入門

サーバサイドJavaScript Node.js入門

メンテナブル JavaScript

book javascript

を読みました。
第I部はスタイルガイドラインで、コードスタイル的なところです。有名所のスタイルガイドラインに沿って説明されています。ある程度コード書いていると、それなりに実践しているようなところではないかなと思います。
第II部は実際にコードを描く時のことです。小さいアプリであれば気にしないところでも、大規模になって大人数で開発する上では非常に重要になってくるところかと思います。是非気をつけたいところではありますね。
第III部は、Antでのビルドのところですね。AntでJavaScriptをビルドする方法について、各タスクについて詳細に書かれているので参考になるのではないかなとは思います。が、Antでやるのが良いのかは正直よくわかりません。RubyやNodeをベースにしたツール等の方が最近ではよく使われているんじゃないかなぁとも思いますし、実際のところはどうなんでしょうかね？とは言え、自動化はしなくてはならないことだと思いますし、JenkinsでCIを行えるのは魅力の一つではあるかと思います。

メンテナブルJavaScript ―読みやすく保守しやすいJavaScriptコードのための作法

メンテナブルJavaScript ―読みやすく保守しやすいJavaScriptコードのための作法

目次

  • 第I部 スタイルガイドライン
    • 1章 基本フォーマット
    • 2章 コメント
    • 3章 文と式
    • 4章 変数、関数、演算子
  • 第II部 プログラミング実践
    • 5章 UI層での疎結合
    • 6章 グローバル変数／関数を作らない
    • 7章 イベント処理
    • 8章 nullとの比較を避ける
    • 9章 設定データをコードから切り離す
    • 10章 自前のエラーを投げる
    • 11章 所有していないオブジェクトを変更しない
    • 12章 ブラウザ判定
  • 第III部 自動化
    • 13章 ファイルとディレクトリの構成
    • 14章 Ant
    • 15章 バリデーション
    • 16章 ファイルの連結
    • 17章 ミニファイと圧縮
    • 18章 ドキュメンテーション
    • 19章 自動テスト
    • 20章 統合する

第4回.js系開発技術勉強会 #techbuzz に行ってきました

event javascript

今回もメモを投下しておきます。

入門enchant.jsでゲームを作ろう

資料 → -入門- enchant.js でゲームを作ろう

はじめようBackbone.js

資料 → はじめよう Backbone.js

  • 目的
    • Backbone.jsがどんなものかわかる
    • Backbone.jsのメリデメがわかる
    • 聞いたからと言ってすぐに出来るようになるわけではない
    • 他のフレームワークの比較は作ってない
  • Backbone.js
    • JavaScriptのMVCフレームワーク
    • 大規模開発で効果を発揮する
    • 割りと知名度は高い
    • RailsやCacePHPなどとは異なる
    • オブザーバーパターン
    • JavaScriptはイベントを関しするイベント駆動プログラミング
    • Backboneではオブジェクトの状態変化も観察する

ーMVC

    • View
      • DOMの監視と操作
    • Model
      • データの取得、保存、更新、削除
    • Collection
      • Modelの集合、Controllerではありません。
    • Router
      • URLを監視する
    • History
      • Routerの履歴を監視する
    • Controllerと言うオブジェクトは存在しません
    • M:Model, Collection
    • V: View
    • C: Router, History
    • MとVが大事
  • 具体的
    • ViewがModelとColletionを監視する
    • ユーザがクリックなどの操作でイベントを発生させると、Viewが反応する
    • 反応したViewがModelへ処理を移譲する
    • Modelが通信などを行う
    • Modelが状態変化すると、Viewが状態変化を監視しているので、表示処理などを行う
    • Collectionは？
      • 一覧を扱うのがCollectionになります。
      • ModelとCollectionで相互に関しする感じになります。
  • ここまでのまとめ
    • Viewが、ユーザ、Model、Collectionのイベントを監視する
    • データを取得更新すると、Viewがイベントを動かす
  • デモとソースの解説
    • WEBAPIを叩いて、週間天気を表示する
    • jQuery, underscore.js, Backbone.jsを読み込む。
      • Backbone.jsはunderscore.jsに依存しているので必要
      • underscore.js単体で使っても便利
    • ・・・Viewで使う
    • 作ったViewとModelのJavaScriptを読み込む
    • 最後に、ModelとViewを実体化する
  • Model
    • defaults で初期値を設定する
    • url: で APIのURLを定義
    • sync: JSONPの設定をするためにオーバーライドしている
    • parse: syncの直後にparseが呼ばれる
      • データを整形する
      • returnしたデータがModelの属性になる
  • View
    • el: にHTMLの要素を指定する。
    • events で監視イベントを設定する、 イベントとどこ？を設定
    • initialize: 初期化を行う
      • listenToでモデルを監視する
      • model のchangeイベントを監視し、this.renderを呼び出す。
    • this.model.set(値, {slint: true});
      • 第2引数のsilentは、モデルに値を設定するとchangeイベントが発生してしまうが、発生させないようにするため
  • 最後に
    • BackboneJSでは大規模開発で有効なので、このデモくらいであれば使わない方が早いですよ。

はじめて学ぶ enchant.jsゲーム開発

はじめて学ぶ enchant.jsゲーム開発