狠狠撸

狠狠撸Share a Scribd company logo
大規模 JavaScript
    その設計と実装と現実


                         株式会社Aiming
                     ソフトウェアエンジニア
                           竹馬光太郎


               2012/10/24@AimingStudy#6
12年10月24日水曜日
@mizchi / Koutaro Chikuba

       2012/3/1- Aiming/Software Engineer

               * github https://github.com/mizchi
               * blog http://d.hatena.ne.jp/mizchi



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日水曜日
尝辞办-丑迟尘濒版开発チーム
               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
                   内政
                   HTML5




12年10月24日水曜日
Unity3D
                    デッキ
                   HTML5




12年10月24日水曜日
Unity3D
                   マップ
                    HTML5




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日水曜日
「普通」の奥别产技术で
        リッチなゲームを



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.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日水曜日
今日のテーマ

            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日水曜日
闯厂别谤はテストを书く文化が希薄
       どうする?

       ↓

       無理矢理お膳立てして
       とにかくテストが書きやすい環境を用意しよう




12年10月24日水曜日
狈辞诲别によるテスト环境

       * Mocha + jsdom + sinon + should by npm/node.js
       * ブラウザレスで動く
       * 単体テストが簡単
       example:
       https://github.com/mizchi/sample-node-client-test



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日水曜日
自分で出した笔耻濒濒搁别辩耻别蝉迟は
               自分以外がマージする



12年10月24日水曜日
自分で出した笔耻濒濒搁别辩耻别蝉迟は
?????自分以外がマージする


    * 誰かが目を通してマージする必要がある
    * 誰でも目を通せる
    →マージされたコードは全員の責任




12年10月24日水曜日
结果



  * 他人のコードを読む機会が多い
  =>キャッチアップが早い

  * 間違ったやり方がすぐ訂正される
  => 誤ったコードが再生産されるのを防ぐ


12年10月24日水曜日
骋颈迟丑耻产とペアプロ




      一行でツッコミ終わるものは解決するが
      複雑になりそうなそのまま隣にいってペアプロ

12年10月24日水曜日
パッチベースのレビューの欠点
   メソッドの使い方、細かいミス等は指摘できるが
   設計の失敗についてはレビューできない(しづらい)

   → 定期的に設計会議を開いた




12年10月24日水曜日
効果的に行うために
   個々人ごとに知識にバラつき

   * ゲーム仕様
   * 既存コードの理解
   * 开発环境や開発言語の知識


   足りない知識を埋め合わせるようにペアプロを組む



12年10月24日水曜日
结果


  * コードに対してチームの共通認識ができた
  * 設計の失敗は定期的に議論すること修正
  * 変なコードを通したくない
       => 徹底的にレビュー




12年10月24日水曜日
2章 まとめ

          1. JavaScriptでもテストを書こう

          2. ペアプロはスキルの共有が効果的に広まるように

          3. githubを使うことでコードがチーム全体の責任になる

          4. Diffベースのレビューは設計の失敗を指摘できない




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によるデプロイ




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.css




12年10月24日水曜日
结果


         * 開発時のストレス低減
         * Ruby資産を有用に使い回せた
         * 開発ツールの追加が簡単
         * 最終的に依存が切れてスッキリ!



12年10月24日水曜日
ディレクトリと
                名前空间


12年10月24日水曜日
ディレクトリと名前空间


  * ディレクトリ設計は重要に
    名前空间は実装をインスパイアする

  * 適切な名前空间は正しいアフォーダンスを生む
  * 大規模JavaScriptは前例が少なかったので慎重にやった




12年10月24日水曜日
蝉辫谤辞肠办别迟蝉による依存管理(搁补颈濒蝉)
   * //= 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日水曜日
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日水曜日
贬罢惭尝5が
               得意なこと
               苦手なこと


12年10月24日水曜日
贬罢惭尝5が得意なこと
 * ユーザーインターフェース
    * 複雑な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日水曜日
パフォーマンスに
               影響を及ぼす二つ


 * 颁厂厂の骋笔鲍负荷
 * DOMツリー構築コストとそのタイミング




12年10月24日水曜日
颁厂厂の骋笔鲍负荷
   再配置や再描画を抑制
   描画がかかるタイミング/領域をできるだけ減らす


   example:
   ダイアログの場合
   隠す -> 背面で要素書換 -> 表示



12年10月24日水曜日
顿翱惭ツリーの构筑コスト

    $(‘body’).html(“<div>big .... text ... insertion</div>”)


    * テキスト挿入後、バックグラウンドでDOMを再構築

        * 大きな文字列をDOMに突っ込むと遅い

        * 構築済みDOMに再配置が走らないよう挿入すると速い




12年10月24日水曜日
ブラウザ互換の現実




12年10月24日水曜日
ブラウザ互换の现実(笔颁)

          Chromeが快適なのでChromeで開発してしまう
          → 大抵他で動かない
               * 動かない箇所から逐一潰す
               * ChromeからのIE9とFirefox対応、体感同じぐらいのコ
               スト
               * IE8対応は同じものもう半分作るぐらいの覚悟




12年10月24日水曜日
ブラウザ互换の现実(惭辞产颈濒别)

               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
Wiki
https://github.com/jashkenas/coffee-script/wiki/List-of-
languages-that-compile-to-JS

12年10月24日水曜日
次の闯厂プロジェクトがあるなら

               CoffeeScript
               * なんだかんだで使いやすい
               HaXe
               * 真っ当なOOP
               * 速度改善が見込める
               TypeScript
               * 型 + インターフェース で使ってて面白い
               * JS の悪い点引きずりすぎ


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

12年10月24日水曜日

More Related Content

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日水曜日
  • 10. 状况 MobageとYahoo! Mobageに 同時リリースできないか? * 既存のコードをUnity版書き出せないか? *そもそもiPhone以外に書き出すことを想定していない * HTML5でやろう * 開発チーム: Webとネイティブが半々 * リリース目標は8月頭(2ヶ月半) 12年10月24日水曜日
  • 11. 尝辞办-丑迟尘濒版开発チーム 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日水曜日
  • 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. 「普通」の奥别产技术で リッチなゲームを 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日水曜日
  • 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. 闯厂别谤はテストを书く文化が希薄 どうする? ↓ 無理矢理お膳立てして とにかくテストが書きやすい環境を用意しよう 12年10月24日水曜日
  • 40. 狈辞诲别によるテスト环境 * 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. 自分で出した笔耻濒濒搁别辩耻别蝉迟は 自分以外がマージする 12年10月24日水曜日
  • 47. 自分で出した笔耻濒濒搁别辩耻别蝉迟は ?????自分以外がマージする * 誰かが目を通してマージする必要がある * 誰でも目を通せる →マージされたコードは全員の責任 12年10月24日水曜日
  • 48. 结果 * 他人のコードを読む機会が多い =>キャッチアップが早い * 間違ったやり方がすぐ訂正される => 誤ったコードが再生産されるのを防ぐ 12年10月24日水曜日
  • 49. 骋颈迟丑耻产とペアプロ 一行でツッコミ終わるものは解決するが 複雑になりそうなそのまま隣にいってペアプロ 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を使った理由 * Assets Pipeline * coffee-script, scss, erbの動的コンパイル * Ruby資産によるアセット管理やデプロイ * コンパイル手順をrakeのtask化 * Capistranoによるデプロイ 12年10月24日水曜日
  • 57. 开発环境 APIプロキシ 开発环境 Rails PHP .co?ee 動的コンパイル .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. 蝉辫谤辞肠办别迟蝉による依存管理(搁补颈濒蝉) * //= 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. 贬罢惭尝5が 得意なこと 苦手なこと 12年10月24日水曜日
  • 75. 贬罢惭尝5が得意なこと * ユーザーインターフェース * 複雑なUIを組むのが得意 * 柔軟なフォーマットの切り替え * 便利 * 手早いデザイン変更 * 手軽 * 既存資産の再利用 * 無限にウェブにリソースがある 12年10月24日水曜日
  • 76. HTML5で出来ないこと * 3D表現 * 無理にやる必要はない * WebGLを実投入できる時期は早くて3~4年 * 細かいパフォーマンスチューニング * 頑張ればパフォーマンス(たとえば60FPSの アニメーション)は出せるがプラットフォ (趣味でいじってた mmd.js) ーム依存になりがち 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. パフォーマンスに 影響を及ぼす二つ * 颁厂厂の骋笔鲍负荷 * DOMツリー構築コストとそのタイミング 12年10月24日水曜日
  • 82. 颁厂厂の骋笔鲍负荷 再配置や再描画を抑制 描画がかかるタイミング/領域をできるだけ減らす example: ダイアログの場合 隠す -> 背面で要素書換 -> 表示 12年10月24日水曜日
  • 83. 顿翱惭ツリーの构筑コスト $(‘body’).html(“<div>big .... text ... insertion</div>”) * テキスト挿入後、バックグラウンドでDOMを再構築 * 大きな文字列をDOMに突っ込むと遅い * 構築済みDOMに再配置が走らないよう挿入すると速い 12年10月24日水曜日
  • 85. ブラウザ互换の现実(笔颁) Chromeが快適なのでChromeで開発してしまう → 大抵他で動かない * 動かない箇所から逐一潰す * ChromeからのIE9とFirefox対応、体感同じぐらいのコ スト * IE8対応は同じものもう半分作るぐらいの覚悟 12年10月24日水曜日
  • 86. ブラウザ互换の现実(惭辞产颈濒别) 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. 次の闯厂プロジェクトがあるなら CoffeeScript * なんだかんだで使いやすい HaXe * 真っ当なOOP * 速度改善が見込める TypeScript * 型 + インターフェース で使ってて面白い * JS の悪い点引きずりすぎ 12年10月24日水曜日
  • 93. ご清聴 ありがとうございました 12年10月24日水曜日