「第七回ありえるえりあ勉強会 - JSで大規模・エンタープライズ開発」へ行ってきました

JavaScript Event

面白かったです。

先日、どこぞでJSの話を聴かせて頂いた時は、ずっと頭に？が浮かんでいましたが、あれから1週間。jQueryでちょっと遊んだおかげか、前よりも内容が理解できて、楽しかったです。

とはいえ、バブリングの意味を知ったのも数日前という状態のため、メモしておいて後で試そう、と思ったことが、いっぱいありました（というか、ほとんどがそう）。

以下、自分用の偏ったメモです。

「JavaScriptで大規模ゲーム開発」渋川さん

AndroidにもiOSにも対応したゲームがJavaScriptで書けるゲームエンジン・ngCoreの紹介でした。

アーキテクチャ

サーバはPerl。でも、それ以外を使ってもOK。

データの持ち方
  • クライアント
    • ちょっとしたデータ
  • ゲームサーバ
    • アイテムやパラメータ、パラメータの計算等
  • mobageサーバ
    • ユーザ情報
ngCoreのコードはどんな感じか

ほか、印象的だったところは・・・

  • ダウンロード時はMD5を比較して、更新があったら取ってくる
  • 階層型のScene（というオブジェクト）を遷移してゲームが進む
  • ミッションの結果は配列で返る
  • クライアントは順番に再生するだけ
  • 新しいミッションの出目を追加するときはハンドラを1箇所に追加するだけ
  • サーバエラーがあるとホーム画面に強制で戻る

など。

開発まわり

ngGo/Builderのお話もありました。

  • Flow Editor
    • JSだと非同期コールバックが多くて全体の動きを把握しづらいが、このツールのおかげで便利に
  • git flowで開発している
  • CommonJSドメインのものは、いずれOSSで公開予定
デバッグ、テスト
  • デバッグメニューをゲームにつける
    • パラメータ変更可能にしたり、カットシーンを再生したり
  • デバッガもある
  • サーバ側にデバッグ用ページを用意する
  • サーバ側（Perl）のテストはTest::Moreで
  • クライアント側のテストはJasmineで

Webサイトから、SDKとngGo/Builderがダウンロードでき、開発情報も提供されているそうです。

また、エンサイクロペディアはSphinxをバリバリに使って書かれているので、Sphinxの書き方としてコードが参考になるというお話もありました。（しかし、検索しても辿り着けない。どこにあるのかな）

自分は電源を使うゲーム全般に疎いので、イメージや理解が追いつかない部分が多く、無念でした。聞くのに必死でノートもあまり取らず。

「オフラインWebアプリケーションの作り方」（白石さん）

約200ファイルのJavaScriptでオフラインWebアプリを開発されたご経験から、オフラインで読み書きできるアプリケーションのつくりかたについて、発表してくださいました。

「オフラインで読める」を実現する
  • HTML5のアプリケーションキャッシュを使う
    • 静的リソースのキャッシュ
    • 使うと起動が速くなる
    • キャッシュマニフェストで更新チェック
  • JavaScript APIを併用する
    • キャッシュの進捗状況をチェックしたり、明示的に更新したりできる
    • マニフェストファイルを書き換えないと、ローカルリソースは更新されない


「オフラインで書ける」を実現する

基本は次の２つ。

  1. ブラウザが備えているローカルストレージにデータを読み書き
  2. その後、DBの内容をクラウドと同期

1.は何とかできる。

  • Web Storage（カンタン）
  • Web SQL Database（死んでる）
  • Indexed Database API
    • ブラウザ組み込みのKVS
    • RDBのテーブルみたいなものがオブジェクトストアにあたる
  • File API

問題は2. 完全な双方向同期は難しい。次のような課題があってスゴク大変。

  • フェールセーフ（途中で切れたらどうするか）
  • 更新の衝突
  • 同期タイミング
  • 各データの状態管理
  • ネットワーク状態
  • ローカルDBのスキーマ管理（サーバDBのスキーマとの差異にどう対処するか）
  • ローカルDBのクォータ制限（5MB）

だから、割り切った仕様にして対処する。

・・・

最後の部分が一番聞きたかったので、ガーン…という感じでした。やっぱり難しいのでしょうか。できる範囲で、どうやって戦っているのかを、どこかで知りたいです。まあ魔法があるわけではないので、上のような課題を1コ1コ解決、あるいは、不具合が顕現しないレベルにまで問題を低減しているだけなのでしょうが。。。（その方法を知りたいなあ）

「スケールするUIについて」（monjudohさん）

"スケールする"とは、データ件数に対してスケールする、という意味。

クライアント側は、サーバ側と違って、3桁や4桁のデータ量でもすぐに破たんしてしまうので、それをいかにして避けるかというお話でした。

namespace付きイベントのunbindが重い

jQueryだとイベントにnamespaceを付けられて、イベントを剥がすときに便利。
しかし、重い。ループで外そうとしたりすると、もう大変。

Draggableが重い

jQueryのliveメソッドは、要素ではなく、cssセレクタに対してイベントを貼る。
これは、bindと違って、それより後に書いたものも対象にできる。

liveで貼ったイベントはスケールする。要素n件に対して処理が1回。
documentにdelegeteしたがごとく動くのがコレ。

要素に貼りたい場合は、.classname にliveイベントを貼り、そのclassを要素に振ればOK。
上の方のオブジェクト（liveの場合はdocument）がイベントの発火を検知する。

本当に必要になるまで重い処理をしない

表示項目を操作可能にする≒重い処理。
だから、表示されているものだけを操作可能にする。
たくさんの項目が表示されたとして、ユーザが実際にどれだけの項目を操作するのかを考える。
（たとえば、大量に項目があるとき、一画面に表示されている分だけをDraggableにして、setTimeoutで投げる）

要素の動的生成

表示するオブジェクトを再利用する。
たとえば、Twitterクライアントのタイムラインに何千個もtweetsがあるとき、実際のUIテーブルビューのオブジェクトは、十数個のセルを使いまわしている。

LTその1「JavaScriptのテスト事情」（os0xさん）

雑誌「WEB+DB PRESS」の次号にCoffeeScriptの記事が載るそうです。

  • JS部分が正しく動くかのテスト（ライブラリ向けテスト）以上に、JSとその周りのものが一緒に正しく動くかのテスト（インテグレーションテスト）が大事
    • 書くのもメンテも大変で、実行も遅いけど、確実に動いていることを保証できる（ように書ける）から

LTその2「Tinanium mobile」（masuidriveさん）

  • 特徴
  • リソース
    • 日本語の本も出てるし、技評のWebサイトに連載もある

お礼

というわけで、とても勉強になりました。

発表してくださった方、ありえるの皆さん、会場提供してくださったワークスアプリケーションズさん、ありがとうございました。