aiming study#6pdf
DESCRIPTION
大規模JS その設計と実装と現実TRANSCRIPT
大規模 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日水曜日
Lord of Knights
12年10月24日水曜日
Strategy & Card Game
12年10月24日水曜日
Lord of Knights for iOS
* Strategy Simulation* implemented by Unity3D
12年10月24日水曜日
2012/5 中頃 ....
これをさー移植したいんだよねー
12年10月24日水曜日
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日水曜日
12年10月24日水曜日
!?
12年10月24日水曜日
状況MobageとYahoo! Mobageに同時リリースできないか?
* 既存のコードをUnity版書き出せないか?*そもそもiPhone以外に書き出すことを想定していない
* HTML5でやろう* 開発チーム: Webとネイティブが半々
* リリース目標は8月頭(2ヶ月半)
12年10月24日水曜日
Lok-html版開発チーム
* Rubyの人(Web) or C#の人(Unity) が多い
* JavaScript経験者少数
Aiming:
JS:7~8 マークアップ:3 デザイナ:2
サーバーは既にあるものを利用
12年10月24日水曜日
自分
* Web側のメンバーとして参加
* 入社前はWebSocketのMMOとか(mizchi/ws-netgame)
* Nodeの経験で色々言ってたら、好き勝手やらせてもら
えた
12年10月24日水曜日
8月中頃…
12年10月24日水曜日
できた
12年10月24日水曜日
Unity3D
HTML5
内政
12年10月24日水曜日
Unity3D
HTML5
デッキ
12年10月24日水曜日
HTML5
Unity3Dマップ
12年10月24日水曜日
その苦労と楽しさについて
12年10月24日水曜日
1章 普通のWeb技術でリッチなゲームを2章 開発チームと環境3章 JavaScriptと設計4章 HTML5の実際
今日のテーマ
12年10月24日水曜日
1章 普通のWeb技術でリッチなゲームを2章 開発チームと環境3章 JavaScriptと設計4章 HTML5の実際
今日のテーマ
12年10月24日水曜日
「普通」のWeb技術でリッチなゲームを
12年10月24日水曜日
「普通」である理由
普通のWeb技術とは何か?* 最も知られている、ウェブサイトを組み立てる技術* HTMLは「最も普及したGUIライブラリ」
「普通でない」もの* 用途に特化したゲームエンジン
* Flashから出力する系とか* HTML5の特定技術にロックインしすぎてる系
12年10月24日水曜日
* 普通の知識はググれば見つかる* 普通の知識はキャッチアップが簡単* 普通の知識だから人員追加に耐えられる!!!
「普通」である理由
12年10月24日水曜日
普通のライブラリを使う
12年10月24日水曜日
今回使用したライブラリ
* CoffeeScript* jQuery* Backbone.js* undrscore.js* Mustache* iScroll
12年10月24日水曜日
とくに効果があったもの
CoffeeScript気持ちがいいシンタックス + OOP
Backbone.jsMVCパターンとイディオムの提供
underscore.js関数型言語が好きなメンバが多かったので
12年10月24日水曜日
「もう最初からCoffeeScriptでいいんじゃないかなー」
* チームにJS経験者がすくない(Rubyist, C#er)
* オブジェクト指向(っぽい)
* 「BadPartsでない」JavaScriptを出力する
12年10月24日水曜日
The Little Book on CoffeeScript を読もう!
http://arcturo.github.com/library/coffeescript/(日本語版もある)
coffeescriptはシンタックスの拡張なので既存技術と重ならない
12年10月24日水曜日
JavaScript の現況JSはウェブ上の学習資料が豊富ただし…
* 2005年までのJSサンプルは基本的に参考にならない* AJAXによるパラダイムの変化* JITによる高速化
* 行儀が悪いサンプルを見抜く力が必要
12年10月24日水曜日
真っ当なプログラマなら
JavaScript: The Good Parts で大体は察するはず…
12年10月24日水曜日
12年10月24日水曜日
JavaScript: The GoodPartsJavaScriptの良いパーツだけを使おうという本
大事なのは、付録A「ひどいパーツ」付録B「悪いパーツ」
* JavaScript自体の言語仕様は小さい* なぜCoffeeScriptはそのコードを出力するか?という視点で読む
12年10月24日水曜日
結果良かった点
* オブジェクト指向に慣れてる人は自然にCoffeeScript覚えた* JavaScriptの理解はCoffeeScriptが出力するものをみてれば* JSとCoffeeScriptに詳しい人が一人がいると便利
*チームで CoffeeScript は面白い言語と評判* 面白いってのはモチベーション的に大事
12年10月24日水曜日
1. HTMLは普通の技術だから使いやすい
2. できるだけ新しい記事を参考にしよう
3. ダメなサンプル避ける為にJS GoodPartsを読もう
4. OOPやってたプログラマとCoffeeScriptは相性がいい
1章 まとめ
12年10月24日水曜日
1章 普通のWeb技術でリッチなゲームを2章 開発チームと環境3章 JavaScriptと設計4章 HTML5の実際
今日のテーマ
12年10月24日水曜日
2章開発チームと環境
12年10月24日水曜日
VMware Imageの配布* 非WebエンジニアはLinux環境が苦手→ Rails/Node 環境を整えたVMイメージを配布
* 環境構築手順を解説したスクリプトを公開→ わかる人は勝手に同等の環境を組んでいい
最初にやったこと
12年10月24日水曜日
JavaScriptのテスト
12年10月24日水曜日
どうする?
↓
無理矢理お膳立てしてとにかくテストが書きやすい環境を用意しよう
JSerはテストを書く文化が希薄
12年10月24日水曜日
* Mocha + jsdom + sinon + should by npm/node.js* ブラウザレスで動く* 単体テストが簡単example: https://github.com/mizchi/sample-node-client-test
Nodeによるテスト環境
12年10月24日水曜日
Demo
12年10月24日水曜日
* モデル層に近いピュアJSなコードが充実 * ゲームはそこが大事* DOM強依存コードはやはりテストできず HTMLは頻繁に変更される 高度に発達したHTMLはデザインと分離しにくい
結果
12年10月24日水曜日
Github & Code Review
12年10月24日水曜日
OSSでは標準的なPull Requestフロー全員が中央リポジトリをフォーク -> PR
詳細は http://scottchacon.com/2011/08/31/github-flow.html
12年10月24日水曜日
Githubでのルール
12年10月24日水曜日
自分で出したPullRequestは
自分以外がマージする
12年10月24日水曜日
* 誰かが目を通してマージする必要がある* 誰でも目を通せる→マージされたコードは全員の責任
自分で出したPullRequestは 自分以外がマージする
12年10月24日水曜日
* 他人のコードを読む機会が多い =>キャッチアップが早い
* 間違ったやり方がすぐ訂正される=> 誤ったコードが再生産されるのを防ぐ
結果
12年10月24日水曜日
Githubとペアプロ
一行でツッコミ終わるものは解決するが複雑になりそうなそのまま隣にいってペアプロ
12年10月24日水曜日
パッチベースのレビューの欠点メソッドの使い方、細かいミス等は指摘できるが設計の失敗についてはレビューできない(しづらい)
→ 定期的に設計会議を開いた
12年10月24日水曜日
効果的に行うために個々人ごとに知識にバラつき
* ゲーム仕様* 既存コードの理解* 開発環境や開発言語の知識
足りない知識を埋め合わせるようにペアプロを組む
12年10月24日水曜日
* コードに対してチームの共通認識ができた* 設計の失敗は定期的に議論すること修正* 変なコードを通したくない => 徹底的にレビュー
結果
12年10月24日水曜日
1. JavaScriptでもテストを書こう
2. ペアプロはスキルの共有が効果的に広まるように
3. githubを使うことでコードがチーム全体の責任になる
4. Diffベースのレビューは設計の失敗を指摘できない
2章 まとめ
12年10月24日水曜日
1章 普通のWeb技術でリッチなゲームを2章 開発チームと環境3章 JavaScriptと設計4章 HTML5の実際
今日のテーマ
12年10月24日水曜日
JavaScriptの設計
12年10月24日水曜日
Railsを使った理由* Assets Pipeline
* coffee-script, scss, erbの動的コンパイル
* Ruby資産によるアセット管理やデプロイ* コンパイル手順をrakeのtask化* Capistranoによるデプロイ
コンパイラとしてのRails
12年10月24日水曜日
開発環境
Rails PHP開発環境.coffee.scss
APIプロキシ
動的コンパイル+ キャッシュ
12年10月24日水曜日
本番環境
PHP本番
* 本番にRailsはいない* 静的ファイルのみ
Rails開発環境
静的ファイルの生成
デプロイ
12年10月24日水曜日
Railsが最終的に生成する静的ファイル
* index.html* all_pc.js, all_mobile.js* all_pc.css, all_mobile.css
Output
12年10月24日水曜日
* 開発時のストレス低減* Ruby資産を有用に使い回せた* 開発ツールの追加が簡単* 最終的に依存が切れてスッキリ!
結果
12年10月24日水曜日
ディレクトリと名前空間
12年10月24日水曜日
ディレクトリと名前空間
* ディレクトリ設計は重要に名前空間は実装をインスパイアする
* 適切な名前空間は正しいアフォーダンスを生む* 大規模JavaScriptは前例が少なかったので慎重にやった
12年10月24日水曜日
sprocketsによる依存管理(Rails)* //= require hogehoge で、ファイルが連結される* 擬似インポートのように使う
* 素のJSはインポート機能がない* 相対requireは禁止* デプロイ担当から「#ifdef ほしい」との声も…
12年10月24日水曜日
Directories::app/assets/javascripts/lib* views/
Backbone.Viewを継承するクラス
* models/Backbone.Modelを〃
* namespace.js名前空間の初期化
12年10月24日水曜日
名前空間namepspace.js で定義
名前空間を事前に予約※ Rubyのmoduleの真似したかった
グローバル汚染は最小限に かつ 明示的に
12年10月24日水曜日
* JSの依存管理ができた* 意図不明なファイルがなくなった* MVC的な構成が整った
結果
12年10月24日水曜日
JavaScript MVC with
12年10月24日水曜日
ref. https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/
Backbone/MVC
12年10月24日水曜日
* Backbone.Viewはコントローラ* MVCのVに相当するのはHTMLそのもの* Backbone.ViewはBackbone.Modelを監視し、HTML
を書き換える
Backbone MVC
12年10月24日水曜日
MVCに従った結果
同じJavaScriptを使用!
12年10月24日水曜日
セレクタを揃えるだけで同じJavaScriptでMobile版とPC版を実装
MVCに従った結果
12年10月24日水曜日
1. 普通のWeb技術でゲームを2.開発チームと環境3.設計とディレクトリ4. HTML5の実際
今日のテーマ
12年10月24日水曜日
4章 HTML5の実際
12年10月24日水曜日
HTML5が得意なこと苦手なこと
12年10月24日水曜日
HTML5が得意なこと* ユーザーインターフェース
* 複雑なUIを組むのが得意* 柔軟なフォーマットの切り替え
* 便利* 手早いデザイン変更
* 手軽* 既存資産の再利用
* 無限にウェブにリソースがある
12年10月24日水曜日
HTML5で出来ないこと* 3D表現
* 無理にやる必要はない* WebGLを実投入できる時期は早くて3~4年
* 細かいパフォーマンスチューニング* 頑張ればパフォーマンス(たとえば60FPSのアニメーション)は出せるがプラットフォーム依存になりがち
(趣味でいじってたmmd.js)
12年10月24日水曜日
例えば
12年10月24日水曜日
マップ実装の話
12年10月24日水曜日
* 選択タイルの点滅したかった* 周辺に描画が走って激重* やむなく白の透明タイルに
* モバイルでのドラッグが…
* iScrollの対応が半端で動いたり動かなったり* 諦めてページャーで対応
* 初期化が重い…
* 大量のdivを生成するがゆえに重い
マップ実装の話
12年10月24日水曜日
工夫* 一度生成したDOMを使いまわす画面遷移 2.5s -> 0.1s
* クオータービュー(斜め見下ろし)
回転行列が固定(π/4)
手計算で解いた近似値をハードコード
* 端末ごとにDOM生成数を調整Mobile: 10 × 15^2 = 2250 (div) PC: 10 × 25^2 = 6250
改善
12年10月24日水曜日
パフォーマンスに 影響を及ぼす二つ
* CSSのGPU負荷
* DOMツリー構築コストとそのタイミング
12年10月24日水曜日
CSSのGPU負荷
再配置や再描画を抑制描画がかかるタイミング/領域をできるだけ減らす
example:ダイアログの場合
隠す -> 背面で要素書換 -> 表示
12年10月24日水曜日
DOMツリーの構築コスト
$(‘body’).html(“<div>big .... text ... insertion</div>”)
* テキスト挿入後、バックグラウンドでDOMを再構築
* 大きな文字列をDOMに突っ込むと遅い
* 構築済みDOMに再配置が走らないよう挿入すると速い
12年10月24日水曜日
ブラウザ互換の現実
12年10月24日水曜日
ブラウザ互換の現実(PC)
Chromeが快適なのでChromeで開発してしまう→ 大抵他で動かない
* 動かない箇所から逐一潰す* ChromeからのIE9とFirefox対応、体感同じぐらいのコスト* IE8対応は同じものもう半分作るぐらいの覚悟
12年10月24日水曜日
ブラウザ互換の現実(Mobile)
iOS Safari対応策が出回ってるので対処しやすい
Android Webkit Browser機種ごとに全く新しいバグが出る
* Galaxy系 バグるが同じ対応で全部直る* Xperia系 新しいやつほど変な挙動* テレビと同じブランド 基本的にヤバイ 本当にヤバイ
12年10月24日水曜日
* 早くする方法はあるが面倒くさい* 現実的にどこまでやれるか決める
* マルチプラットフォーム対応はプロジェクトの3割以上を見込んでおく
* Androidは一部を切り捨てることが前提* HTMLはUIを作るのに最適
教訓
12年10月24日水曜日
全体のまとめ* JavaScriptもテストは書こう* コードレビューしよう* ちゃんと設計しよう* JSのMVCはサーバーのMVCと違う* HTMLはUIを作るのに最適* パフォーマンスはトレードオフ
12年10月24日水曜日
楽しかったこと* 超実験的なプロジェクト既存コード一切無しライブラリ選定が自由
* 新卒なのに色々やらせてくれた一部やりすぎた感はある
* カリカリパフォーマンスチューニングするの楽しい* ゲーム作るの面白い
12年10月24日水曜日
最後にaltjsの話
12年10月24日水曜日
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
12年10月24日水曜日
次のJSプロジェクトがあるなら
CoffeeScript* なんだかんだで使いやすいHaXe* 真っ当なOOP
* 速度改善が見込めるTypeScript* 型 + インターフェース で使ってて面白い* JS の悪い点引きずりすぎ
12年10月24日水曜日
ご清聴ありがとうございました
12年10月24日水曜日