Successfully reported this slideshow.

Aiming study#6pdf

224

Share

1 of 93
1 of 93

More Related Content

Viewers also liked

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Aiming study#6pdf

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

×