aiming study#6pdf

大規模 JavaScript

その設計と実装と現実

株式会社Aimingソフトウェアエンジニア

竹馬光太郎

2012/10/24@AimingStudy#6 12年10月24日水曜日

2012/3/1- Aiming/Software Engineer

* blog http://d.hatena.ne.jp/mizchi

* github https://github.com/mizchi

@mizchi / Koutaro Chikuba

12年10月24日水曜日

http://d.hatena.ne.jp/mizchi




Lord of Knights


Strategy & Card Game


Lord of Knights for iOS

* Strategy Simulation* implemented by Unity3D


2012/5 中頃 ....

これをさー移植したいんだよねー


Lord of Knights for Mobage and Yahoo! Mobage

* refine UI for PC and SmartPhone* implemented by HTML5* share same resource for pc and mobile

新企画12年10月24日水曜日

!?


状況MobageとYahoo! Mobageに同時リリースできないか？

* 既存のコードをUnity版書き出せないか？*そもそもiPhone以外に書き出すことを想定していない

* HTML5でやろう* 開発チーム: Webとネイティブが半々

* リリース目標は8月頭(2ヶ月半)


Lok-html版開発チーム

* Rubyの人(Web) or C#の人(Unity) が多い

* JavaScript経験者少数

Aiming:

JS:7~8 マークアップ:3 デザイナ:2

サーバーは既にあるものを利用


自分

* Web側のメンバーとして参加

* 入社前はWebSocketのMMOとか(mizchi/ws-netgame)

* Nodeの経験で色々言ってたら、好き勝手やらせてもら

えた


8月中頃…


できた


Unity3D

HTML5

内政


Unity3D

HTML5

デッキ


HTML5

Unity3Dマップ


その苦労と楽しさについて


1章普通のWeb技術でリッチなゲームを2章開発チームと環境3章 JavaScriptと設計4章 HTML5の実際

今日のテーマ


「普通」のWeb技術でリッチなゲームを


「普通」である理由

普通のWeb技術とは何か？* 最も知られている、ウェブサイトを組み立てる技術* HTMLは「最も普及したGUIライブラリ」

「普通でない」もの* 用途に特化したゲームエンジン

* Flashから出力する系とか* HTML5の特定技術にロックインしすぎてる系


* 普通の知識はググれば見つかる* 普通の知識はキャッチアップが簡単* 普通の知識だから人員追加に耐えられる！！！

「普通」である理由


普通のライブラリを使う


今回使用したライブラリ

* CoffeeScript* jQuery* Backbone.js* undrscore.js* Mustache* iScroll


とくに効果があったもの

CoffeeScript気持ちがいいシンタックス + OOP

Backbone.jsMVCパターンとイディオムの提供

underscore.js関数型言語が好きなメンバが多かったので


「もう最初からCoffeeScriptでいいんじゃないかなー」

* チームにJS経験者がすくない(Rubyist, C#er)

* オブジェクト指向(っぽい)

* 「BadPartsでない」JavaScriptを出力する


The Little Book on CoffeeScript を読もう！

http://arcturo.github.com/library/coffeescript/(日本語版もある)

coffeescriptはシンタックスの拡張なので既存技術と重ならない


http://arcturo.github.com/library/coffeescript/




JavaScript の現況JSはウェブ上の学習資料が豊富ただし…

* 2005年までのJSサンプルは基本的に参考にならない* AJAXによるパラダイムの変化* JITによる高速化

* 行儀が悪いサンプルを見抜く力が必要


真っ当なプログラマなら

JavaScript: The Good Parts で大体は察するはず…


JavaScript: The GoodPartsJavaScriptの良いパーツだけを使おうという本

大事なのは、付録A「ひどいパーツ」付録B「悪いパーツ」

* JavaScript自体の言語仕様は小さい* なぜCoffeeScriptはそのコードを出力するか？という視点で読む


結果良かった点

* オブジェクト指向に慣れてる人は自然にCoffeeScript覚えた* JavaScriptの理解はCoffeeScriptが出力するものをみてれば* JSとCoffeeScriptに詳しい人が一人がいると便利

*チームで CoffeeScript は面白い言語と評判* 面白いってのはモチベーション的に大事


1. HTMLは普通の技術だから使いやすい

2. できるだけ新しい記事を参考にしよう

3. ダメなサンプル避ける為にJS GoodPartsを読もう

4. OOPやってたプログラマとCoffeeScriptは相性がいい

1章まとめ



今日のテーマ


2章開発チームと環境


VMware Imageの配布* 非WebエンジニアはLinux環境が苦手→ Rails/Node 環境を整えたVMイメージを配布

* 環境構築手順を解説したスクリプトを公開→ わかる人は勝手に同等の環境を組んでいい

最初にやったこと


JavaScriptのテスト


どうする？

↓

無理矢理お膳立てしてとにかくテストが書きやすい環境を用意しよう

JSerはテストを書く文化が希薄


* Mocha + jsdom + sinon + should by npm/node.js* ブラウザレスで動く* 単体テストが簡単example: https://github.com/mizchi/sample-node-client-test

Nodeによるテスト環境


https://github.com/mizchi/sample-node-client-test

https://github.com/mizchi/sample-node-client-test

Demo


* モデル層に近いピュアJSなコードが充実 * ゲームはそこが大事* DOM強依存コードはやはりテストできず HTMLは頻繁に変更される高度に発達したHTMLはデザインと分離しにくい

結果


Github & Code Review


OSSでは標準的なPull Requestフロー全員が中央リポジトリをフォーク -> PR

詳細は http://scottchacon.com/2011/08/31/github-flow.html


http://scottchacon.com/2011/08/31/github-flow.html

http://scottchacon.com/2011/08/31/github-flow.html

Githubでのルール


自分で出したPullRequestは

自分以外がマージする


* 誰かが目を通してマージする必要がある* 誰でも目を通せる→マージされたコードは全員の責任

自分で出したPullRequestは　　　　　自分以外がマージする


* 他人のコードを読む機会が多い =>キャッチアップが早い

* 間違ったやり方がすぐ訂正される=> 誤ったコードが再生産されるのを防ぐ

結果


Githubとペアプロ

一行でツッコミ終わるものは解決するが複雑になりそうなそのまま隣にいってペアプロ


パッチベースのレビューの欠点メソッドの使い方、細かいミス等は指摘できるが設計の失敗についてはレビューできない(しづらい)

→ 定期的に設計会議を開いた


効果的に行うために個々人ごとに知識にバラつき

* ゲーム仕様* 既存コードの理解* 開発環境や開発言語の知識

足りない知識を埋め合わせるようにペアプロを組む


* コードに対してチームの共通認識ができた* 設計の失敗は定期的に議論すること修正* 変なコードを通したくない => 徹底的にレビュー

結果


1. JavaScriptでもテストを書こう

2. ペアプロはスキルの共有が効果的に広まるように

3. githubを使うことでコードがチーム全体の責任になる

4. Diffベースのレビューは設計の失敗を指摘できない

2章まとめ



今日のテーマ


JavaScriptの設計


Railsを使った理由* Assets Pipeline

* coffee-script, scss, erbの動的コンパイル

* Ruby資産によるアセット管理やデプロイ* コンパイル手順をrakeのtask化* Capistranoによるデプロイ

コンパイラとしてのRails


開発環境

Rails PHP開発環境.coffee.scss

APIプロキシ

動的コンパイル+ キャッシュ


本番環境

PHP本番

* 本番にRailsはいない* 静的ファイルのみ

Rails開発環境

静的ファイルの生成

デプロイ


Railsが最終的に生成する静的ファイル

* index.html* all_pc.js, all_mobile.js* all_pc.css, all_mobile.css

Output


* 開発時のストレス低減* Ruby資産を有用に使い回せた* 開発ツールの追加が簡単* 最終的に依存が切れてスッキリ！

結果


ディレクトリと名前空間


ディレクトリと名前空間

* ディレクトリ設計は重要に名前空間は実装をインスパイアする

* 適切な名前空間は正しいアフォーダンスを生む* 大規模JavaScriptは前例が少なかったので慎重にやった


sprocketsによる依存管理(Rails)* //= require hogehoge で、ファイルが連結される* 擬似インポートのように使う

* 素のJSはインポート機能がない* 相対requireは禁止* デプロイ担当から「#ifdef ほしい」との声も…


Directories::app/assets/javascripts/lib* views/

Backbone.Viewを継承するクラス

* models/Backbone.Modelを〃

* namespace.js名前空間の初期化


名前空間namepspace.js で定義

名前空間を事前に予約※ Rubyのmoduleの真似したかった

グローバル汚染は最小限にかつ明示的に


* JSの依存管理ができた* 意図不明なファイルがなくなった* MVC的な構成が整った

結果


JavaScript MVC with


ref. https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/

Backbone/MVC


https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/

https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/

* Backbone.Viewはコントローラ* MVCのVに相当するのはHTMLそのもの* Backbone.ViewはBackbone.Modelを監視し、HTML

を書き換える

Backbone MVC


MVCに従った結果

同じJavaScriptを使用!


セレクタを揃えるだけで同じJavaScriptでMobile版とPC版を実装

MVCに従った結果


1. 普通のWeb技術でゲームを2.開発チームと環境3.設計とディレクトリ4. HTML5の実際

今日のテーマ


4章 HTML5の実際


HTML5が得意なこと苦手なこと


HTML5が得意なこと* ユーザーインターフェース

* 複雑なUIを組むのが得意* 柔軟なフォーマットの切り替え

* 便利* 手早いデザイン変更

* 手軽* 既存資産の再利用

* 無限にウェブにリソースがある


HTML5で出来ないこと* 3D表現

* 無理にやる必要はない* WebGLを実投入できる時期は早くて3~4年

* 細かいパフォーマンスチューニング* 頑張ればパフォーマンス(たとえば60FPSのアニメーション)は出せるがプラットフォーム依存になりがち

(趣味でいじってたmmd.js)


例えば


マップ実装の話


* 選択タイルの点滅したかった* 周辺に描画が走って激重* やむなく白の透明タイルに

* モバイルでのドラッグが…

* iScrollの対応が半端で動いたり動かなったり* 諦めてページャーで対応

* 初期化が重い…

* 大量のdivを生成するがゆえに重い

マップ実装の話


工夫* 一度生成したDOMを使いまわす画面遷移 2.5s -> 0.1s

* クオータービュー(斜め見下ろし)

回転行列が固定(π/4)

手計算で解いた近似値をハードコード

* 端末ごとにDOM生成数を調整Mobile: 10 × 15^2 = 2250 (div)　PC: 10 × 25^2 = 6250

改善


パフォーマンスに影響を及ぼす二つ

* CSSのGPU負荷

* DOMツリー構築コストとそのタイミング


CSSのGPU負荷

再配置や再描画を抑制描画がかかるタイミング/領域をできるだけ減らす

example:ダイアログの場合

隠す -> 背面で要素書換 -> 表示


DOMツリーの構築コスト

$(‘body’).html(“<div>big .... text ... insertion</div>”)

* テキスト挿入後、バックグラウンドでDOMを再構築

* 大きな文字列をDOMに突っ込むと遅い

* 構築済みDOMに再配置が走らないよう挿入すると速い


ブラウザ互換の現実


ブラウザ互換の現実(PC)

Chromeが快適なのでChromeで開発してしまう→ 大抵他で動かない

* 動かない箇所から逐一潰す* ChromeからのIE9とFirefox対応、体感同じぐらいのコスト* IE8対応は同じものもう半分作るぐらいの覚悟


ブラウザ互換の現実(Mobile)

iOS Safari対応策が出回ってるので対処しやすい

Android Webkit Browser機種ごとに全く新しいバグが出る

* Galaxy系バグるが同じ対応で全部直る* Xperia系新しいやつほど変な挙動* テレビと同じブランド基本的にヤバイ本当にヤバイ


* 早くする方法はあるが面倒くさい* 現実的にどこまでやれるか決める

* マルチプラットフォーム対応はプロジェクトの3割以上を見込んでおく

* Androidは一部を切り捨てることが前提* HTMLはUIを作るのに最適

教訓


全体のまとめ* JavaScriptもテストは書こう* コードレビューしよう* ちゃんと設計しよう* JSのMVCはサーバーのMVCと違う* HTMLはUIを作るのに最適* パフォーマンスはトレードオフ


楽しかったこと* 超実験的なプロジェクト既存コード一切無しライブラリ選定が自由

* 新卒なのに色々やらせてくれた一部やりすぎた感はある

* カリカリパフォーマンスチューニングするの楽しい* ゲーム作るの面白い


最後にaltjsの話


altjs とはJavaScriptにコンパイルされる言語一般のこと

List of languages that compile to JS · jashkenas/coffee-script Wikihttps://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS


次のJSプロジェクトがあるなら

CoffeeScript* なんだかんだで使いやすいHaXe* 真っ当なOOP

* 速度改善が見込めるTypeScript* 型 + インターフェースで使ってて面白い* JS の悪い点引きずりすぎ


ご清聴ありがとうございました


aiming study#6pdf

Documents