Reports

Twitter: @mtknnktm.

HTML5 Conference 2012メモ

  • ひたすらメモっただけ。

基調講演 - Web技術の過去・現在・未来（及川さん、白石さん）

  • 2004
  • 2007, 2008
    • GDD: Google Gears → アプリ用の道具（API）
      • Gearsは標準化への準備・試しの実装
      • Webのアプリ化に耐えられるブラウザ - Chrome
  • 2009
    • GDD: HTML5普及促進を明言
  • 2010
    • Apple が Flash 非サポートを明言。すべてをHTML5へ、という方針。
  • 2011
    • 最新ブラウザの普及率向上
  • 2012
    • Canvasなどからよりリッチに: WebGL, Device Access, Offline Access, WebIntents, Native Client, JS and DOM, WebRTC, Web Audio API
  • past - now
    • できなかったことをできるように。ネイティブに追いつくように
  • now - future
    • 妥協無く動くように
    • より簡単に実現できるように
      • WebIntents: アプリ間連携
      • WebComponents: DOMを部品化 //これは熱い！
  • ブラウザとは
    • もはやインターネット閲覧ソフトではない
    • クラウドアプリケーションのフロントエンド
    • いろんなデバイス（ロボットとか）がクラウドにつながる
      • → ブラウザは常に存在するコントローラにも
  • HTML5のこれから: 拡がる可能性・複雑化する技術・安全/安心への責任
感想
  • "安全/安心への責任" という一言が一番印象に残った。
  • もう "新しいことができるようになって楽しい" というフェイズではなく、ちゃんとしたシステムづくりの一環になるとだと再認識。

Webプラットフォームの進化と実装 〜Web技術の現在と未来〜（浅井智也）

  • HTML5への期待
    • 次世代プラットフォーム
      • マルチデバイス（スマフォ、タブレット、PC）で高度なアプリ開発・組版（レイアウト）技術
  • html5: バラバラだった機能を拡張・標準化、組版（CSS3）の向上
    • → これから: デバイス連携、
  • html5という仕様はもう古い（標準化は時間がかかる）（W3C）
  • Working Groupでより新しいことを
  • 既存の独自プラットフォーム
    • iOS, Android, FB, Chrome（単独ベンダ）
    • VS Web プラットフォーム
    • オープンなWebプラットフォームでいきたい
  • ほんとに可能か？
  • win8: メトロ。htmlは形式的に使うだけ。div祭り & 独自data属性が多い。JS APIも独自
    • 無理に合わせてるだけなので使いにくいし、使い回しできない。
    • しかもIE10とメトロは非互換(´・ω・`)
    • セキュリティ上の制限も違う
    • 非常に拡張されているので便利といえば便利
    • windows store: UIガイドが厳しい。Webアプリ読み込みだけというのは不可
    • 囲い込みが強いように見える。
    • Webと違うならHTML使う意味ない。
  • Firefox OS
    • Webがネイティブ
    • アプリ開発はHTMLのみ。OSのUIも全部HTML。
    • 実装と並行して標準化
    • Webアプリがそのまま動く（PC・スマフォ同じ）。セキュリティモデルは同じ。
  • iOS
    • ネイティブ限定
    • 独自ブラウザエンジンは不可
    • WebViewは可
      • JIT無効の低速JS（Mobile Safariよりかなり遅い）
      • 機能制限が強い
  • Android
    • ネイティブ限定
    • 独自ブラウザエンジンは不可
    • 制限もなし
    • WebViewも可
  • Webでは出なかったこと
    • システムステータス（通信方式、wifiのon/off）
    • センサー
    • 低レベルH/W制御（USB/NFC/BlueTooth）
    • このへんMozillaがんばってますよ
      • モバイルがWebに向かっていない → Webをモバイルに。
  • FirefoxOS（android端末とかにインストール可）
    • カーネルの上にWeb Engineが直で乗ってる(・∀・)
    • すべてWeb技術で。アイコンとかもCSS。
    • 発展途上国でも売れる値段で提供できるようにする（H/Wベンダと組んでる）
  • デスクトップアプリもWeb技術で。
    • ブラウザの枠に縛られない、Webアプリ。
  • IDEは用意する？
    • 純粋なWebアプリなので不要。MozillaにはAdobeが協力表明をしている。
感想
  • 「Pure HTML5 で行く。そうでなければWebは発展しない。」というMozillaのビジョンがよくわかった。
  • 確かにWindows 8のように中途半端にHTML5を採用しても余計に大変になるだけだと思うし、その煽りを食らいそうでいまからガクブルしている…

WebIntentsにより拓かれる次のWeb（小松健作）

  • 資料: 探し中
  • Webはクラウドだけではない
    • デモ: webからテレビを操作する
  • カメラ、テレビ、etc… も全部Webにつながる
  • クラウドもローカルも全部Web
    • 全部シームレスに普通に使えるように
  • Webアプリ同士をつなげる仕組み
  • Android のインテンツとよく似ている
  • ユーザがこのアプリこういうふうに使いたい（名詞・動詞のペア）
    • e.g.: Twitter (Facebook) で記事をシェアしたい
    • registration & invokeで実現
  • regiastration（Twitter がブラウザに宣言）
    • 「何（名詞: mine-type）」に対して「これ（動詞: share, view, edit, etc…）」ができる と宣言
    • htmlにタグを書く。
      • （プラウザが対応していれば登録される）
      • chrome extensionでmanifestファイルでも宣言できる
  • invoke
    • アプリからjsで実施し、registrationされたアプリ（twitter）を呼び出す
      • Device API -> in-device Web Server Model
  • 2つのWGが関わっている
    • オープンにしなければならないが、特許に抵触するためあまり実装がされていない
    • → デバイスがローカルにWebサーバを持ち、そこにむかってAPIを叩く形で連携する
  • サービス選択の自由
    • どのサービスを使用するかはユーザの自由
    • 状況にあわせて選択する（公/私とか）

  • 検索のモデルがWebアプリにマッチしていないのではないか？
    • 使いたい時に連携しているアプリの情報をだすようにしたい
  • local network devicesへの拡張
    • そもそも必要？→実はすでに組み込まれている
    • DLNA - SOAP: TVなどのデバイスをリモート操作
    • UPnP: IP multicastを行い自動発見
    • → JSから叩いてやれば操作可能。普通のTVでもブラウザからAPIを叩くことで可能。
    • → クラウドもローカルもシームレスに繋ぐことができる！！１
    • 限定的な状況なら実現可能。すぐそこの未来。W3Cで検討中。
感想
  • デバイス類がシームレスに連結してシステムとして動作するというのは、システム屋としてたまらない未来。
  • そうなるとPure HTML5でほとんどのことができるということが非常に重要になってくると思う。
  • すでに受け手としてのTVにはその準備ができていることが意外で、某スマホ・クラウド洗濯機も壮大なビジョンに基づいた一手なのではないかと勝手に妄想w

Web最先端、エキスパートたちの視点から（白石さん、小松さん、羽田野さん、及川さん、新野さん）

振り返り
  • ここ数年で変わったところ
    • 白石: 2009年 - html5j 立ち上げ。その頃はここまで波が来るとは思わなかった。
      • 新野: MS/AdobeはHTML5は無視/軽視してた状態だった
    • 小松: すごいものだと思ったが、仕事でR&Dでやることになるとは思わなかった。
    • 羽田野: html5.jp は5年前に立ち上げ。誰も注目してなかった。
      • web業界以外の人たちがHTMLに注目している点がこれまでのHTMLと違う点
      • 注目されてきた点: Canvas/映像や音-> Device
    • 及川: Chrome立ち上げ。最初はなぜgoogleがそんなものを。とも思ったが、あれがまさにWebの起爆剤になった。
Webの成功
  • Flashなどの強力な競合があったにもかかわらずなぜHTML5がここまでになったか？
    • 及川: 開発者・ユーザが勝手に作って、それが標準に取り入れられていった、オープンなプロセスがあったから。今後もどんどん変わっていくと思う。そしてもっといろんな分野に適用されていき、どんどん変わっていくと思う。
      • スマフォがwebkitのみだったから（実際は差があるが）。画像を使わずにCSSで軽量なページが開発ができるようになったから。
    • 新野: 新しく出てきたときは基本的に貧弱。それを皆で成長させていくプロセスが面白いと思う。
    • 羽田野: 1.（冷めた言い方をすると）Apple。2. ベンダのコントロールを受けずにビジネスができるから。
    • 小松: これまであったブラウザで急速にできるようになったことが開発者を刺激した。
    • 白石: 技術者が持っている期待感。他のプラットフォームは実装→仕様。HTML5は仕様から先に決まることが多い。
これからどうなる。3年先。
  • 白石
    • よりWeb/html5/jsが使われるようになる。
  • 小松
    • クラウド、デバイスのシームレスな連携がより進む。デバイスの話が出た途端にステークホルダーが増える（プレイヤーが増える）。TV, カーナビ, etc… 今では想像もつかないことが始まってるはず。
  • 羽田野
    • あらゆる表示画面がWebでできているかも。そのため機能面ではなく安定性などの非機能が重要になるのでは。
  • 及川
    • どんどんWebの範囲は広がっていく。認証して必要なものが増える。
    • クラウドではなくランデブーでつながないと遅くてやってられないものが増える（テレビとリモコンなど）。アーキテクチャは非常に複雑になる。
    • ステークホルダーが増えることによるスピード感をなくしてしまわないようにしなければならない。
感想
  • 3年後の話、HTML5は生活のいろんな所に実用的な形で入ってくると考えると、いろいろ取り巻く問題の種類が変わってくるということについて、今から準備しとかないとまずそうだと思った。
  • きっとHTML5関連技術を扱う人にもフロントだけでなくデバイス・インフラの技術が必要。

HTML5によるタフなモバイル開発の最前線（紀平さん）

  • 資料: 探し中
  • 今回の話の対象は、モバイルブラウザで「今」できること
モバイルHTML5の基礎
  • リッチといえばFlashだった（ガラケー時は非常に普及していた）
  • スマフォではFlash使えない
  • そこでHTML5が注目された
モバイルHTML5うれしいこと
  • ブラウザ間の互換性を保って使える機能が増えた
  • 曲線のある図形の描画ができるようになった、アニメ能力の向上
  • Webアプリ機能の向上
    • Application Cache, localStorageなど

しかし、ネイティブにはかなわない

  • 3D: iOS6ならもしかして。
  • 音楽: androidはOKだが、iOSがプア。クリックしないと再生しないとか。Winも貧弱。
  • 速度: 描画速度が特に。
    • Canvas, CSS3。モバイルHTML5の最前線は如何にCanvas/CSS3で描画速度を上げるかが最も熱い

Canvas VS CSS3

  • Canvas: 低レベル部分で言えばFlashでできることは代替できる
    • メリット
      • 最近のOSはGPUを使うので高速
      • APIがシンプルなので端末間の挙動の違いが小さい
    • デメリット
      • ただでさえろくでもない言語であるJSを書きまくるハメになる
  • ngCoreはCanvasベース。ネイティブに見える。
  • CSS3
    • メリット
      • 記述が簡潔
      • 基本的にGPUを使うので高速
      • CSSなのでデザイナーも書ける（JSerじゃなくても書ける）
    • デメリット
      • 細かいアニメの同期がとれない（JSでやらないといけない。ゲームには向かない）
      • ハマると異常に遅くなる。DOMが増えると遅くなりやすい。
      • 【端末間の互換性が絶望的】
        • Galaxy S3でビルドNoが同じなのに挙動が違うことも…
解決策
  • iOS: 端末間の差が少ないのでCSS3を使う
    • iOS4/5, 3GS/4/4Sだけ
    • そもそも互換性が高い
  • Android
    • これまではFlashだった
    • 今後は…課題
DeNAのCanvas
Canvasのノウハウ
  • DeNAのWebゲームではCavasをフルに使ったページが起動しっぱなし
  • 普通に使う場合に比べて、速度、メモリ、電池で課題が発生しやすい
  • 高速化
    • オンメモリCanvasの有効活用
    • GPUのサポートにより、drawImageが高速になった。
    • DOMに属さないCanvas要素をcreateElementで作成して、キャッシュすると高速化できる
    • GC対策
      • Androidは世代別GCを利用のでstop the worldが起こる（0.1秒ぐらいだがアクションゲームでは致命的）
      • 長期保存するメモリと短期メモリ を区別する
      • 最初に可能な限りオブジェクトをプールしてメモリ確保自体を減らす
  • メモリの問題
    • スマフォではメモリを使い過ぎると落ちる
    • 実機の使用量は動的に調査
      • iOS6からできるかも。Androidはデバッグブリッジでやれる。
      • WebViewで表示して調べることも一般的。ただMobile SafariとWebViewではJITの有無が違うので正しい判断が難しい（JITはメモリを食うので）。Jail Breakしたらもしかしたら…
    • メモリリークを検知。Chrome Developer Tool: snapshot
      • domのイベントの解除忘れ
      • console.log（デバッグ中だけメモリリークが発生する…）
      • グローバルオブジェクトのヒモ付
  • 電池の問題
    • CPU使用率と相関
    • 描画のCPU使用率は高い
    • 描画しなくていい場合はとにかく描画しない
    • 前のフレームで描いた描画結果を利用して描画範囲を絞る（dirty rect）
今後のモバイルHTML5
  • ネイティブ VS HTML5
    • 一長一短
    • インストールなく実行できる（twitterのリンクからすぐ実行できる）
    • データの保存・速度は勝てない
  • html5らしいwebアプリはごく少数
    • iOS: gmail, twitter, Facebook
    • 優れたwebアプリの登場によって滋養今日は簡単にひっくり返る
  • きっと…
    • iphone/androidでちゃんと動く
    • ページ遷移なし
    • 瞬時に起動・オフラインで快適に使用
感想
  • 講演のように現状、HTML5のアニメーションの基盤技術は非常に貧弱。
  • 紀平さんような専門の技術者（チーム）による整備が必要だと思った。
    • 持っているノウハウがすごい。

ブラウザを介した新しいリアルタイムコミュニケーション（あんどうやすしさん）

  • テーマ: WebRTC
  • 資料: 探し中
Webのリアルタイムコミュニケーション

1. Ajax/Comet

  • Cometは技術の組み合わせ - WebRTCは標準技術

2. Server Side Event

  • サーバからのpush用 - WebRTCは双方向

3. WebSocket

  • サーバのプロセスとWebアプリの双方向通信
  • WebRTCはWebアプリ同士の双方向

- RTC (Real Time Communication)

    • 現状は音声/ビデオコミュニケーションができるだけ（P2Pとかはまだ）
  • ブラウザからカメラの情報を受け取って表示したりストリームをリモートピアに送信・受信できる
  • おいおいは「任意のデータ」をP2Pで通信できる
  • getUserMedia でカメラの映像を取り込んでいじれる
  • media stream -> ネットワーク or 画面
感想
  • 個人的に今後一番楽しみなところ。ブラウザで任意のP2P通信とか、いろんなデバイスとブラウザがつながるようになったらとても楽しそう。

HTML5&CSS3デザインブック (ステップバイステップ形式でマスターできる)

HTML5&CSS3デザインブック (ステップバイステップ形式でマスターできる)

HTML&CSS標準デザイン講座 【HTML5&CSS3対応】

HTML&CSS標準デザイン講座 【HTML5&CSS3対応】