Aiming study#6pdf

大規模 JavaScript その設計と実装と現実株式会社Aiming ソフトウェアエンジニア竹馬光太郎 2012/10/24@AimingStudy#612年10月24日水曜日

@mizchi / Koutaro Chikuba 2012/3/1- Aiming/Software Engineer * github https://github.com/mizchi * blog http://d.hatena.ne.jp/mizchi12年10月24日水曜日

Lord of Knights12年10月24日水曜日

Strategy & Card Game12年10月24日水曜日

Lord of Knights for iOS * Strategy Simulation * implemented by Unity3D12年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版開発チーム Aiming: JS:7~8 マークアップ:3 デザイナ:2 サーバーは既にあるものを利用 * Rubyの人(Web) or C#の人(Unity) が多い * JavaScript経験者少数12年10月24日水曜日

自分 * Web側のメンバーとして参加 * 入社前はWebSocketのMMOとか(mizchi/ws-netgame) * Nodeの経験で色々言ってたら、好き勝手やらせてもらえた12年10月24日水曜日

8月中頃…12年10月24日水曜日

できた12年10月24日水曜日

Unity3D 内政 HTML512年10月24日水曜日

Unity3D デッキ HTML512年10月24日水曜日

Unity3D マップ HTML512年10月24日水曜日

その苦労と楽しさについて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 * iScroll12年10月24日水曜日

とくに効果があったもの CoffeeScript 気持ちがいいシンタックス + OOP Backbone.js MVCパターンとイディオムの提供 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 GoodParts JavaScriptの良いパーツだけを使おうという本大事なのは、付録A「ひどいパーツ」付録B「悪いパーツ」 * JavaScript自体の言語仕様は小さい * なぜCoffeeScriptはそのコードを出力するか？という視点で読む12年10月24日水曜日

結果良かった点 * オブジェクト指向に慣れてる人は自然にCoffeeScript覚えた * JavaScriptの理解はCoffeeScriptが出力するものをみてれば * JSとCoffeeScriptに詳しい人が一人がいると便利 *チームで CoffeeScript は面白い言語と評判 * 面白いってのはモチベーション的に大事12年10月24日水曜日

1章まとめ 1. HTMLは普通の技術だから使いやすい 2. できるだけ新しい記事を参考にしよう 3. ダメなサンプル避ける為にJS GoodPartsを読もう 4. OOPやってたプログラマとCoffeeScriptは相性がいい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日水曜日

Nodeによるテスト環境 * Mocha + jsdom + sinon + should by npm/node.js * ブラウザレスで動く * 単体テストが簡単 example: https://github.com/mizchi/sample-node-client-test12年10月24日水曜日

Demo12年10月24日水曜日

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

Github & Code Review12年10月24日水曜日

OSSでは標準的なPull Requestフロー全員が中央リポジトリをフォーク -> PR 詳細は http://scottchacon.com/2011/08/31/github-flow.html12年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日水曜日

2章まとめ 1. JavaScriptでもテストを書こう 2. ペアプロはスキルの共有が効果的に広まるように 3. githubを使うことでコードがチーム全体の責任になる 4. Diffベースのレビューは設計の失敗を指摘できない12年10月24日水曜日

JavaScriptの設計12年10月24日水曜日

コンパイラとしてのRails Railsを使った理由 * Assets Pipeline * coffee-script, scss, erbの動的コンパイル * Ruby資産によるアセット管理やデプロイ * コンパイル手順をrakeのtask化 * Capistranoによるデプロイ12年10月24日水曜日

開発環境 APIプロキシ開発環境 Rails PHP .coﬀee 動的コンパイル .scss + キャッシュ12年10月24日水曜日

本番環境静的ファイルの生成 Rails 開発環境デプロイ本番 PHP * 本番にRailsはいない * 静的ファイルのみ12年10月24日水曜日

Output Railsが最終的に生成する静的ファイル * index.html * all_pc.js, all_mobile.js * all_pc.css, all_mobile.css12年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 with12年10月24日水曜日

Backbone/MVC ref. https://hacks.mozilla.org/2012/10/the-web-developer-toolbox-backbone/12年10月24日水曜日

Backbone MVC * Backbone.Viewはコントローラ * MVCのVに相当するのはHTMLそのもの * Backbone.ViewはBackbone.Modelを監視し、HTML を書き換える12年10月24日水曜日

MVCに従った結果同じJavaScriptを使用!12年10月24日水曜日

MVCに従った結果セレクタをえるだけで同じJavaScriptでMobile版とPC版を実装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 = 625012年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-scriptWikihttps://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS12年10月24日水曜日

次のJSプロジェクトがあるなら CoffeeScript * なんだかんだで使いやすい HaXe * 真っ当なOOP * 速度改善が見込める TypeScript * 型 + インターフェースで使ってて面白い * JS の悪い点引きずりすぎ12年10月24日水曜日

ご清聴ありがとうございました12年10月24日水曜日

http://d.hatena.ne.jp	3249
http://makoto-tanaka.com	2852
http://developer.aiming-inc.com	1108
http://ofsilvers.hatenablog.com	704
https://twitter.com	203
http://192.168.12.31	97
http://nptech.posterous.com	73
http://sc.dotbranch.com	44
http://ss.dotbranch.com	42
http://webcache.googleusercontent.com	21
http://s.deeeki.com	18
http://twitter.com	16
http://tweetedtimes.com	13
http://192.168.11.161	10
http://posterous.com	6
http://localhost	5
https://si0.twimg.com	3
http://133.242.3.32	3
http://nuevospowerpoints.blogspot.com.es	3
https://it.twitter.com	2
http://www.techgig.com	2
http://cache.yahoofs.jp	1
http://b.hatena.ne.jp	1
http://cyberxnetwork.blogspot.com	1
http://nuevospowerpoints.blogspot.com	1
http://onigra.posterous.com	1
http://nuevospowerpoints.blogspot.com.ar	1

Aiming study#6pdf

by Koutaro Chikuba on Oct 24, 2012

Accessibility

Upload Details

Usage Rights

27 Embeds 8,480

Statistics

Aiming study#6pdf Presentation Transcript