0
大規模 JavaScript    その設計と実装と現実                         株式会社Aiming                     ソフトウェアエンジニア                           ...
@mizchi / Koutaro Chikuba       2012/3/1- Aiming/Software Engineer               * github https://github.com/mizchi       ...
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    * sha...
12年10月24日水曜日
!?12年10月24日水曜日
状況    MobageとYahoo! Mobageに          同時リリースできないか?    * 既存のコードをUnity版書き出せないか?       *そもそもiPhone以外に書き出すことを想定していない    * HTML5...
Lok-html版開発チーム               Aiming:               JS:7~8 マークアップ:3 デザイナ:2               サーバーは既にあるものを利用    * Rubyの人(Web) or...
自分    * 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日水曜日
今日のテーマ            1章 普通のWeb技術でリッチなゲームを            2章 開発チームと環境            3章 JavaScriptと設計            4章 HTML5の実際12年10月24日水曜日
「普通」のWeb技術で        リッチなゲームを12年10月24日水曜日
「普通」である理由      普通のWeb技術とは何か?      * 最も知られている、ウェブサイトを組み立てる技術      * HTMLは「最も普及したGUIライブラリ」     「普通でない」もの     * 用途に特化したゲームエンジ...
「普通」である理由     * 普通の知識はググれば見つかる     * 普通の知識はキャッチアップが簡単     * 普通の知識だから人員追加に耐えられ     る!!!12年10月24日水曜日
普通のライブラリを使う12年10月24日水曜日
今回使用したライブラリ               * CoffeeScript               * jQuery               * Backbone.js               * undrscore.js  ...
とくに効果があったもの      CoffeeScript      気持ちがいいシンタックス + OOP      Backbone.js      MVCパターンとイディオムの提供      underscore.js      関数型言語...
「もう最初からCoffeeScriptでいい  んじゃないかなー」    * チームにJS経験者がすくない(Rubyist, C#er)    * オブジェクト指向(っぽい)    * 「BadPartsでない」JavaScriptを出力する1...
The Little Book on CoffeeScript を読もう!http://arcturo.github.com/library/coffeescript/(日本語版もある)coffeescriptはシンタックスの拡張なので既存技術...
JavaScript の現況      JSはウェブ上の学習資料が豊富      ただし…          * 2005年までのJSサンプルは基本的に参考にならない               * AJAXによるパラダイムの変化       ...
真っ当なプログラマなら   JavaScript: The Good Parts で大体は察するはず…12年10月24日水曜日
12年10月24日水曜日
JavaScript: The GoodParts    JavaScriptの良いパーツだけを使おうという本    大事なのは、    付録A「ひどいパーツ」    付録B「悪いパーツ」    * JavaScript自体の言語仕様は小さい ...
結果      良かった点      * オブジェクト指向に慣れてる人は自然にCoffeeScript覚えた        * JavaScriptの理解はCoffeeScriptが出力するものをみてれば        * JSとCoffeeS...
1章 まとめ          1. HTMLは普通の技術だから使いやすい          2. できるだけ新しい記事を参考にしよう          3. ダメなサンプル避ける為にJS GoodPartsを読もう          4. O...
今日のテーマ            1章 普通のWeb技術でリッチなゲームを            2章 開発チームと環境            3章 JavaScriptと設計            4章 HTML5の実際12年10月24日水曜日
2章          開発チームと環境12年10月24日水曜日
最初にやったこと      VMware Imageの配布       * 非WebエンジニアはLinux環境が苦手          → Rails/Node 環境を整えたVMイメージを配布       * 環境構築手順を解説したスクリプトを...
JavaScriptのテスト12年10月24日水曜日
JSerはテストを書く文化が希薄       どうする?       ↓       無理矢理お膳立てして       とにかくテストが書きやすい環境を用意しよう12年10月24日水曜日
Nodeによるテスト環境       * Mocha + jsdom + sinon + should by npm/node.js       * ブラウザレスで動く       * 単体テストが簡単       example:      ...
Demo12年10月24日水曜日
結果     * モデル層に近いピュアJSなコードが充実          * ゲームはそこが大事     * DOM強依存コードはやはりテストできず          HTMLは頻繁に変更される          高度に発達したHTMLはデザ...
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を使うことでコードがチーム全体の責任になる         ...
今日のテーマ            1章 普通のWeb技術でリッチなゲームを            2章 開発チームと環境            3章 JavaScriptと設計            4章 HTML5の実際12年10月24日水曜日
JavaScriptの設計12年10月24日水曜日
コンパイラとしてのRails     Railsを使った理由     * Assets Pipeline       * coffee-script, scss, erbの動的コンパイル     * Ruby資産によるアセット管理やデプロイ  ...
開発環境                              APIプロキシ        開発環境            Rails        PHP           .coffee                    動的コン...
本番環境                  静的ファイルの生成         Rails                        開発環境                 デプロイ                 本番         ...
Output          Railsが最終的に生成する静的ファイル            * index.html            * all_pc.js, all_mobile.js            * all_pc.css...
結果         * 開発時のストレス低減         * Ruby資産を有用に使い回せた         * 開発ツールの追加が簡単         * 最終的に依存が切れてスッキリ!12年10月24日水曜日
ディレクトリと                名前空間12年10月24日水曜日
ディレクトリと名前空間  * ディレクトリ設計は重要に    名前空間は実装をインスパイアする  * 適切な名前空間は正しいアフォーダンスを生む  * 大規模JavaScriptは前例が少なかったので慎重にやった12年10月24日水曜日
sprocketsによる依存管理(Rails)   * //= require hogehoge で、ファイルが連結される   * 擬似インポートのように使う      * 素のJSはインポート機能がない   * 相対requireは禁止   ...
Directories::   app/assets/javascripts/lib    * views/       Backbone.Viewを継承するクラス    * models/       Backbone.Modelを〃    ...
名前空間       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      ...
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...
HTML5で出来ないこと * 3D表現     * 無理にやる必要はない     * WebGLを実投入できる時期は早くて3~4年 * 細かいパフォーマンスチューニング     * 頑張ればパフォーマンス(たとえば60FPSの     アニメー...
例えば12年10月24日水曜日
マップ実装の話12年10月24日水曜日
マップ実装の話               * 選択タイルの点滅したかった               * 周辺に描画が走って激重               * やむなく白の透明タイルに               * モバイルでのドラッグが...
改善               工夫               * 一度生成したDOMを使いまわす               画面遷移 2.5s -> 0.1s               * クオータービュー(斜め見下ろし)      ...
パフォーマンスに               影響を及ぼす二つ * CSSのGPU負荷 * DOMツリー構築コストとそのタイミング12年10月24日水曜日
CSSのGPU負荷   再配置や再描画を抑制   描画がかかるタイミング/領域をできるだけ減らす   example:   ダイアログの場合   隠す -> 背面で要素書換 -> 表示12年10月24日水曜日
DOMツリーの構築コスト    $(‘body’).html(“<div>big .... text ... insertion</div>”)    * テキスト挿入後、バックグラウンドでDOMを再構築        * 大きな文字列をDOM...
ブラウザ互換の現実12年10月24日水曜日
ブラウザ互換の現実(PC)          Chromeが快適なのでChromeで開発してしまう          → 大抵他で動かない               * 動かない箇所から逐一潰す               * Chromeか...
ブラウザ互換の現実(Mobile)               iOS Safari               対応策が出回ってるので対処しやすい               Android Webkit Browser           ...
教訓         * 早くする方法はあるが面倒くさい               * 現実的にどこまでやれるか決める         * マルチプラットフォーム対応はプロジェクトの3割以         上を見込んでおく          ...
全体のまとめ               * JavaScriptもテストは書こう               * コードレビューしよう               * ちゃんと設計しよう               * JSのMVCはサーバー...
楽しかったこと       * 超実験的なプロジェクト          既存コード一切無し          ライブラリ選定が自由       * 新卒なのに色々やらせてくれた          一部やりすぎた感はある       * カリカ...
最後にaltjsの話12年10月24日水曜日
altjs とはJavaScriptにコンパイルされる言語一般のことList of languages that compile to JS · jashkenas/coffee-scriptWikihttps://github.com/jas...
次のJSプロジェクトがあるなら               CoffeeScript               * なんだかんだで使いやすい               HaXe               * 真っ当なOOP        ...
ご清聴    ありがとうございました12年10月24日水曜日
Upcoming SlideShare
Loading in...5
×

Aiming study#6pdf

57,707

Published on

大規模JS その設計と実装と現実

3 Comments
227 Likes
Statistics
Notes
  • I'm making $86 an hour working from home. I was shocked when my neighbour told me she was averaging $95 but I see how it works now. I feel so much freedom now that I'm my own boss. This is what I do, Buck6.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • CofeeScriptそんなに気持ちいいのかぁ、次何か実装するとき使おうかな。
    後、HTML5や各種開発、それぞれの利点がわかりやすく載っていて読みやすかった。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 設計周りの考え方・ノウハウが非常に参考になります。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
57,707
On Slideshare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
282
Comments
3
Likes
227
Embeds 0
No embeds

No notes for slide

Transcript of "Aiming study#6pdf"

  1. 1. 大規模 JavaScript その設計と実装と現実 株式会社Aiming ソフトウェアエンジニア 竹馬光太郎 2012/10/24@AimingStudy#612年10月24日水曜日
  2. 2. @mizchi / Koutaro Chikuba 2012/3/1- Aiming/Software Engineer * github https://github.com/mizchi * blog http://d.hatena.ne.jp/mizchi12年10月24日水曜日
  3. 3. Lord of Knights12年10月24日水曜日
  4. 4. Strategy & Card Game12年10月24日水曜日
  5. 5. Lord of Knights for iOS * Strategy Simulation * implemented by Unity3D12年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 内政 HTML512年10月24日水曜日
  16. 16. Unity3D デッキ HTML512年10月24日水曜日
  17. 17. Unity3D マップ HTML512年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 * iScroll12年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-test12年10月24日水曜日
  41. 41. Demo12年10月24日水曜日
  42. 42. 結果 * モデル層に近いピュアJSなコードが充実 * ゲームはそこが大事 * DOM強依存コードはやはりテストできず HTMLは頻繁に変更される 高度に発達したHTMLはデザインと分離しにくい12年10月24日水曜日
  43. 43. Github & Code Review12年10月24日水曜日
  44. 44. OSSでは標準的なPull Requestフロー 全員が中央リポジトリをフォーク -> PR 詳細は http://scottchacon.com/2011/08/31/github-flow.html12年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.css12年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 with12年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 = 625012年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-scriptWikihttps://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS12年10月24日水曜日
  92. 92. 次のJSプロジェクトがあるなら CoffeeScript * なんだかんだで使いやすい HaXe * 真っ当なOOP * 速度改善が見込める TypeScript * 型 + インターフェース で使ってて面白い * JS の悪い点引きずりすぎ12年10月24日水曜日
  93. 93. ご清聴 ありがとうございました12年10月24日水曜日
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×