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