Layzie/2012-09-08-html5_conference.md

## 2012-09-08-html5_conference.md

      
    Raw
  

              2012-09-08-html5_conference.md
            
          
    HTML5 Conference

基調講演

Google 及川さん / シーエーモバイル 白石さん
イベントテーマ

「Web技術者の祭典」
Web技術の過去・現在・未来


2004 WHATWG

2004 Gmail/Google Map


2007 Google Developer Day 2007

Google Gears

ローカルデータベース
ローカルサーバー
ワーカーズ


2008 Google Chrome
2009 HTML5の普及が開始
2010 Apple Shock

Flashから脱却
スマホの普及


2011 モダンブラウザが普及
2011 ~ 2012 HMTL5の技術

Canvas
WebGL
WebIntents
Web Audio


過去・現在・未来

過去

ネイティブに追いつく
現在

パフォーマンス向上
未来

より簡単に、よりスケールする
コンポーネントの考えをWebに適用する

Web Intents
Web Components

Shdow DOM


各ベンダーが力を入れてる
ブラウザに対する考え方


ネット閲覧からクラウド環境のフロントエンドへ
オフラインでも各ブラウザと連携

もっと低レイヤーのAPIも。

Raw Socket API
Message API

Webプラットフォームの進化と実装 ~ Web技術の現在と未来 ~

Mozilla Japan 浅井さん@dynamis
ふぉくすけ可愛い
スライド
Web Platform

Web is Platform
HTML5への期待

HTML
CSS
ECMAScript
通信割り
これからオーディオなど

HTML5はもう古い


HTML5 = 安定ブランチ
HTML = 最新のHTML
HTML != HTML5

既存の独自プラットフォーム

ブラウザ戦争は過去の話。
今は単独ベンダー vs Web Platformの競争
Web OS

"HTML5"プラットフォーム


Window8、RT、 Phone
Blackberry 10
Tizen
Firefox OS

Windows 8, RT, Phone

HTMLでモダン？アプリ

感覚はHTML開発とは違う
XAMLの方がマシなんじゃ…。
MetroはWebと非互換

Webと違い過ぎて残念
Blackberry 10


HTMLでも開発可能
W3C仕様があるものは実装
無いものは実装追加・標準化

Tizen


HTMLでも開発可能

メインはEFLのネイティブ？


W3C仕様があるものは実装
無いものは実装追加・標準化

Firefox OS


Webがネイティブ

アプリ開発はThMLのみ
OSのUIも全部HTML


PC/スマホも同じアプリ

Web API

Webではできなかったこと

システムステータス
各種センサー
低レベルハードウェア制御

モバイルがWebに向かないならWebをモバイルにしていく！
Mozillaカッコいい
実装済みAPI


SMS
電話
コンタクト

実装中のAPI


WebRTC
Web Activiteies
Push Notification
Power Management
TCP Socket

実装見込みのAPI

仕様のない実装もないし、実装のない仕様もダメ
Firefox OS

Web技術がネイティブ
> HTML/CSS/JavaScriptでガリガリ書ける
> ホーム画面もネイティブで
開発パートナーと製品化
> 最初はブラジルで発売予定
アプリストアはネイティブっぽくダウンロードできたりする。
何か普及してほしいOSだわー。とても面白い。本当の意味でWeb技術で
アプリが作れるのは素晴しい。
実践Sass - 10を越えるプロジェクト運用で得たノウハウ

NHN Japan 上村さん・富田さん
スライド前編
スライド後編
NHN Japan でのSass導入


ME6-7割がMac
エディターバラバラ
導入はCUI

コンパイル設定の共有


Wikiで共有
今後はCompassで解決していく

config.rbでの設定すれば、compass watchで大丈夫
CUIが苦手な人向け


GUIツールの導入
GUIツールとCUIが混在しても問題ない

SCout


無償
config.rbが読めない

GitHubからダウンロード


Sass3.2の対応が遅かった

Compass.app


$10
インストール不要
Dropboxに入れておけば、環境またいで利用できる

複数MEへの対応


作業者毎にファイル分割
分割する際にはパーシャルで作る
パーシャルファイルをインポート
ファイル分割すると上書き/コンフリクトが発生しない

CSSを直接触りたい

関係者全員へのSassインストールの徹底は難しい
CSSディレクトリにSass管理外のCSSを作って解決。
放置するとカオスになるので、定期的にマージ。
修正箇所の見つけ方

問題のSassコードがどこにあるか分からない
--line-commentsをつけてコンパイルして解決
Compressedの注意点

コンフリクトがCSSで頻発するので複数人での作業時はexpandにしておく
コーディング時の注意

色値の扱い

@colorにカラーコード入れるとカラーネームに変換される
回避策


存在しないカラーコードを入れる
文字列型にする

uniqueにするか#{}にする


出力をcompressedにする

状況によって分けておく
コードの保守性を上げる


@importや@mixinなんかをフル活用して保守性を上げる
変数を使っておく

コメントをSassに残しておく


コンパイル後を意識する

@mixinや不要なネストや@importなどの使い過ぎに注意


@extendを有効に使う

使うと修正が怖いので運用でカバー。プレフィックスにextendを付ける
不要なCSSが吐かれてしまうので代わりにプレースホルダーを使っていく


ライブラリ作成

ライブラリ導入のきっかけ

Compassの導入はムダなCSSが吐かれたり、未対応のCSSがあったりしたから
ライブラリ構造

_utility.scssのようにする
実際のコード


inline-block

IE6/7対応に無駄なCSSが出てくるので、グローバル変数でフラグを立てておく事で対応


link-underline

@mixinで指定


font-family

@mixinで指定


place holder
@contentを使う
Minor CSS Hack

ライブラリの作り方


毎回書いて面倒なコードを見つける
@mixinにする
引数に変数を入れられるようにする

グローバル変数に命名規則を作る
軽快なウェブアプリケーション開発教室

Cookpad 太田さん
凄く…立ち見出てました。
スライド
なぜ軽快か

将来が不安

将来が不安な要因。

IT業界は歴史が浅い
新しい技術がどんどん出てくる

慣れと記憶の関係


転職・引越しなどの環境の変化
記憶量が増え、体感時間が長くなる傾向
ジャネーの法則

繰り返しのメリット

繰り返す事による経験
軽快であるために

トレンドを知る


英語が読めるようになること

技術情報を得られる程度の英語力はそんなに難しくない


コミュニティに参加する

自分の興味を知る


iOSやAndroidでは個人だし、ソーシャルゲームなんかは大規模になってる
グラフィックから統計まで様々
自分の興味とマッチして利益になるのが最善

失敗を恐れない


一番怖いのは何もしないこと

簡単に満足しない


簡単な方法(ライブラリなど)と簡単ではない方法
浅い知識はそれ以上ではない

実践編

トレンドを試す


jsdo.it
jsfiddle
jsperf

効率的な方法を知る

開発ツール

CoffeeScript / JSX / Hase / Dart
Sass / Stylus

開発環境

Mac
node + npm
Closure Linter

エディタ

WebStorm
Sublime Text2

テストやドキュメント(ブログ含む)を書く

アウトプットは非常に大切
JavaScriptのテスト

フレームワーク

Jasmin
Mocha

Headlessな実行環境

capybara-webkit
phantomjs
jasmin-headless-webkit

CL

jenkins
travis.ci

RailsにおけるJavaScriptのテスト


Rails
capybara
capybara-webkit
jonacha (or jasmine)

単体テストか結合テストか


単体テスト←ライブラリ向き
結合テスト←アプリ向き

konacha(mocha ~ chai)で単体テストよりに

これらがCIで動く事により、JavaScriptを使ったアプリの開発サイクルを高速化
まとめ


将来分からない
柔軟に動ける環境を作ろう
広く浅くではない
自分の得意と好きの重なる部分を伸ばしていこう

次世代Web技術を切り開くゲーム開発者たち(前半)

DeNA 城戸さん / Gree 坂本さん / UEI 清水さん / バスタイムフィッシュ 村岡さん / フリー 秋葉さん
HTML5でゲーム開発する場合に一番重視した事


動くように

低スペックAndorid端末などでもちゃんと動くようにする
FlashからCanvasに移行する際にどのように書き出すのか
やっぱりAndroidなどは一般的にはDOMじゃなくCanvasの方が速い


Android 2.2/2.3やiOS4以下でもスムーズに動かすようにする
PCとモバイル向けで、どちらでも違和感無いようにラッパーを作る事

Androidだと機種依存が激しいので、そこの吸収が問題
ゲームデザイン上の問題(右クリックだと、モバイルでは使えない)


HTML5ならではのしんどかった話は何か


アニメーションの問題

決定的なオーサリングツールが無い


新しいブラウザやOSが出るたびにバグが出るかもしれない

同じ端末なのにズームした状態でCanvasのclearRect()を呼ぶと、ほぼ止まる


webkitのNightly Buildでは移動と回転が一緒になると、どちらか動かない
WebGLで変数が多いシェーダーを書くとブラウザが落ちる
MicroSoftがHTML5の話をすると席を立つw

MSのプレフィックスを付け過ぎ


WebGLがIEに入らないのはActiveXのせい

HTML5やったことでどんなメリットがあったか


インストールが無い
アップーデートがスピーディー
開発コストが少なくなる

全体的な傾向としては、Canvas > CSS3の順番で速度は出る


関数型プログラミングが実用的にJavaScriptで使える
コード量が劇的に減る

5万行のiOSネイティブのシューティングのコードが、JavaScriptでは700行で済んだ
ゲームとしては、CanvasとJavaScriptだけでも問題ないくらい
HTML5ではコードを隠せないのが素晴らしい。MITライセンスに必然的になるので再利用が出来る


これからのゲーム政策で期待できる新しいHTML5仕様は


indexedDBやlocalStorageなんかのキャッシュの強化
WebGL

表現力が高くなる
CSS3があるのがWebGLが使えないんじゃ…


立体視
DRM
カメラ・音声

次世代Web技術を切り開くゲーム開発者たち(後半)

今まで専用機がプラットフォームだったゲーム業界と比べてどう変わる？


新しいフィールドが出て別の側面での収益になるんじゃないか
ネットワークが繋ってる事が前提でゲームを作れる
コンテンツダウンロードなんかの新しい形態が出てる
Webゲームとコンシューマーではゲームバランスが違うので、ツライ

チームフォートレスのWebGLでの移植版は16GBのメインメモリが必要とかw


ユーザー体験としては、新しい大剣になるんじゃないか
ソーシャルゲームがドル箱だよね

Web製作と違うゲーム製作


実際にそのゲームを体感してみる

ゲーム製作に参加するたのアドバイス


Web製作者とかゲーム製作者のくくりは関係ない
変わった人が良い

感想としては、清水さんのお話が面白過ぎる