Google I/Oの後で

Google I/Oの後に、技術者が集結したサンフランシスコで様々なイベントが開催されたようです。WebRTC関連として、Kranky Geek WebRTC Event というものがあり、そこでGoogleからWebRTC Updateと題した発表がありました。今回はその50分のセッション映像から、ハイライトをご紹介します。

掴みはcardboard

最初の掴みは、DataChannelで制御できるローバー（自走車）です。キーノートで配布されたcardboardに装着したAndroidでローバーの首を振ってカメラの向きを制御できます。カメラの映像は当然WebRTCで伝達され、cardborad越しに見ることができます。(3分40秒あたり）
※ぜひ体験してみたいですね。ちなみにcardboradはキーノートの最後に配布された、段ボールで組み立てるVRツールです。今回のI/Oの真の目玉とも言われています。

Chromeのロードマップ

次に、ChromeにおけるWebRTCのロードマップの説明が始まりました。（6分20秒あたりから）。10分ぐらいには、対応予定の一覧が出てきます。

Chrome 36

• Chrome 36 （2～3週間でリリース予定）では、Bandwidth Estimationを搭載
• 帯域推定、帯域制御を行い、HD映像も含めて圧縮を最適化

Chrome 37

• Chrome 37 （3Qリリース予定）では、カメラへのアクセス許可を求めるUIを分かりやすく改善
• カメラ/マイクへのアクセスだけでなく、位置情報や、ローカルストレージへのアクセスなど、ユーザの許可を得るためのUI全般を改善予定
• Opus改善、MacでのQTKitからAVFoundationへの変更
• Bitrate制御のための新しいAPIを導入。ストリーム毎に指定できるようにする予定

その先

• 2014年末までに、RTCSender/Receiverを導入。WebRTC 1.1や、ORTCにも繋がる仕様
• 2014年末までに、改善された動画コーデックVP9を導入。DataChannelでQUICサポートを追加
• 2014年末までに、録画/録音用のRecorderをサポートしたい

※個人的には、WebRTC1.1への準備と、録画機能のサポートに注目しています。

モバイルでの改善

20分50秒あたりからは、モバイルサポートのロードマップです。

Androidから

• Android “L” のWebViewがChromeベースになり、WebAudioと、WebRTCをフルサポート
• Bandwidth Estimation をモバイル用に改善(LTEなどを考慮）
• 64bit版に対応
• 映像のエンコーディングにGPUを活用
• 低価格のAndroid One でもWebRTCを使える様に

※WebViewからWebRTCが使えると、ネイティブアプリに組み込むのも容易になりますね。

iOSの話も

ネイティブアプリ用のライブラリが公開されていますが、その改善の話もありました。

• 現在は欠落しているDataChannelをサポート
• Bandwidth Estimation をモバイル用に改善(LTEなどを考慮）
• GPUを利用

※iOSでもAppleで公式にサポートしてほしいのですが、まずはオープンソース側で着実に前進することが重要だと思います。

AppRTCなど

• リファレンスであるAppRTCも、モバイル向けにUIなどを改善
• TURNサーバーをGoogle Compute Engineで動かすプロジェクトをgithubで公開中
• ネットワーク負荷を見てオートスケールさせる仕組みを盛り込むべく、GCEチームと協議中

※Google Compute Engineと言いながら、Google App Engine用です。良くみたら、”start and stop Google Compute Engine instances on demand” ということで、GCEのインスタンスを制御する、GAEのアプリでした。

WebRTC1.0、そして1.1に向けて

• WebRTC 1.0では完結した安定なAPIセットを提供する
• WebRTCは1.1へ進化する。1.0との互換性を維持しながら、新しい要素を取り込む
• ORTCで提唱されている新しい要素（RTPSender/Receiverなど）も取り込み、相互接続を実現する予定
• 面倒なことは裏側で自動的に処理されるが、自分でフルにコントロールできるAPIも同時に提供する

コーデックの話

• Googleは現時点ではVP8がベストだと考えている
• H.264用のパッチをサブミットするのは拒否しないし、自分で組み込めば使える。Chromeには入れないけどね
• 年末にVP9に対応する。来年はVP9がベストな選択肢になると思う

VP9について

• インターネットのトラフィックの61%が動画のストリーム
• 動画の伸び率ほど、ネットワークの帯域の伸びはない。そのためより効率がよいコーデックが必要
• Chromeで再生されるYoutubeのストリームの60%が既にVP9になっている（人気のある動画から変換している）
• VP9のエンコード速度は大きく改善されてきている
• AndroidではKitkatからVP9コーデックをサポート

One more thing…

最後にOne more thing..として、アナウンスがありました。

• Google Hangoutで、WebRTCを利用するようになる
• まずはChromeのDev版、そしてベータ版に入れる。ゆっくりロールアウトさせる
• 多人数での会議など、既存の機能を落とさないように慎重に取り組んでいる

※WebRTCのPeer-to-Peer構成で問題になるコネクション爆発を、何らかのサーバー(MCU)で解決しているのでしょう。それをGoogle Compute Engineで公開して欲しい……

他にも

Kranky Geek WebRTC Eventからは多くのセッション動画が公開されています。

• A brief history of WebRTC: WebRTCが登場するまでの流れ
• WebRTC tutorial: WebRTCとは何か。技術的なTutorialではなく概要の話
• WebRTC cookbook: IE/Sarafi向けのWebRTCプラグインで知られるTemasysのCTOによる、AWSでサーバーを動かす時の苦労話
• Architectures for a kickass WebRTC application: リモートワーク用コミュニケーションツールのSqwiggleのコファウンダーによる、サービスの作り方
• Scaling WebRTC audio for gaming: オンラインゲーム用のVoIPの仕組みをWebRTCで構築した話。フルメッシュではなくスター型にするため、自社開発のMCUを利用
• WebRTC in the real world: TokBokのCTOによる、実はWebRTCを利用しているハード、アプリ、サービスの紹介
• WebRTC and Firefox OS for mobile: Firefox OS 2.0ではWebRTCをサポートする
• Integrating WebRTC with your app: HipChatに1to1 ビデオチャットを組み込んだ体験談
• WebRTC Update: WebRTC 最新動向(今回の記事)
• Google Glass and WebRTC: WebRTCのネイティブアプリをGoogle Glassで動かす話
• Building a WebRTC app – LIVE!: WebRTCを使ったビデオチャットを(半)ライブコーディング

Google I/O本体にはWebRTCのセッションはありませんでしたが、サンフランシスコは盛り上がったようです。参加したかった……

この記事では2014年7月にGoogle I/Oで発表されたMaterial Designについて、どのようなコンセプトなのか、これまでのデザインガイドラインと何が違うのか、ポイントをおさえて紹介します。記事の後半では、Material DesignをWebで実現するためのPolymerとPaper Elementsに関しても説明します。

Material Designという視覚的言語

Material Designの目的は、ひとつの視覚的な言語（Visual Language）によって、あらゆるプラットフォーム、あらゆるスクリーンサイズのデバイスで、一貫性のある体験を提供することです。

それを実現するため、伝統的なグラフィックデザインとテクノロジーによる可能性を引き出して開発に取り組み、ガイドラインは生きたドキュメントとして更新され続けるとしています。

フラットな中に、自然な影や動きを取り入れた

Material Designは、フラットデザインを取り入れた他のデザインガイドラインと同様に、伝統的なグラフィックデザイン、たとえばタイポグラフィーやレイアウトの原則を取り込んでいます。文字やグラフィックを中心に構成された現在のアプリやWebに、はるか昔から積み重ねられてきたノウハウを融和させることで、優れたビジュアルが得られます。

しかし、単なるビジュアルのルールだけでは、スクリーンサイズの多様性の中で、UIや体験の一貫性を保つのはどこかで限界があるのかもしれません。そこでMaterial Designは、「Material is the Metaphor」というコンセプトを取り込んでいます。

http://googledevelopers.blogspot.jp/2014/06/this-is-material-design.html

規則性のある影や、連続性のあるモーションなどを、現実世界のメタファとして細部に取り込むことで、深いレベルで一貫性をもった世界を構築しようとしています。これらの表現に、現実の物質世界と同じ物理的性質をもたせることで、認知的な負担を少なくし、より自然にアフォーダンスを受け取れるようにしています。

例えば、フラットな面に影の表現を加えることで、オブジェクトの重なりやヒエラルキーが表現できます。強く影をつけた大きなボタンは、ユーザーの目にひときわ浮き立つプライマリなアクションとして認識されます。

このような影について、Android Lではリアルタイムソフトシャドウとして、現実世界のメタファを通して、より自然な振る舞いになるようエンジニアリングが発揮されています。モーションについても、直線的な動きではなく、現実世界の慣性に従った動きになるようにガイドラインで定められています。

Material Design Paper

Material Designのコンセプトについて詳しくは、PDFで9つの特徴にまとまっています。Google I/Oのデザインブースでは、このPDFの図画が、実際の紙にインクで印刷されたものが頒布されていました。

「具体的な」デザインガイドライン

Material Designのガイドラインとして、具体的にどのようなデザインを実現すれば良いかのドキュメントは、プレビュー版としてすでに公開されています。

以前のAndroid Designにおいても詳細な項目が用意されていましたが、今回のガイドラインでは、そこにアニメーションや陰影の深度に関する項目をはじめとして、多岐にわたり詳細な情報が掲載されています。特徴的なのは、文字のレイアウト、アニメーション、陰影の表現、画像のフェード効果など細部に至るまで、具体的な数値とサンプルをもって表現していることです。

ガイドラインの一例

さらにAndroidの開発ライブラリはもちろん、後半で紹介するPaper Elementsが、ガイドラインを体現した実装として存在しています。具体的なガイドラインと、それを反映した実装の2つが揃うことによって、Material Designのガイドラインは、他のデザインガイドラインよりも確かで、強固なものになっています。

Google I/O でのセッション

• Google I/O 2014 – Material design principles – YouTube
• Google I/O 2014 – Material design: Structure and components – YouTube
• Google I/O 2014 – Material design: Visual style and imagery – YouTube
• Google I/O 2014 – Material design: Motion – YouTube

キーノートの中で紹介されたMaterial Designですが、その後のセッションでもテーマごとに、詳細な内容の紹介がありました。より深く理解したい方は、これらの動画もチェックしてみると面白い話が聞けるはずです。（YouTubeでは英語字幕が表示されるので、聞きやすいです）

Webで実現するためのPolymerとPaper Elements

ここまでMaterial Designについて紹介しましたが、いよいよこのデザイン原則をWebの世界に取り込むため、PolymerとPaper Elementsについて説明します。

はじめにPolymerとは、Web Componentsが変えるWeb開発の未来で説明されたWeb Componentsをより強力に、より柔軟に使えるようにGoogleで開発されているラッパーライブラリです。Web Componentsが注目を集め始めたのと同時に、Polymerの話題も多く目にするようになっています。

Polymerには、そのラッパーとしての機能を活かして作成された、汎用コンポーネント群があります。それがCore ElementsとPaper Elementsです。このうち、Paper ElementsがMaterial DesignをWebで表現するための鍵になりますが、実際に開発するにはPolymer本体に、これらCore ElementsとPaper Elementsを組み合わせて利用します。

ここでは、Rob DodsonによるUnlock the next era of UI development with Polymerというセッション（SlideShare）の内容を参考に紹介していきます。

レイアウトを構築する

はじめにCore Elementsを使ったアプリケーションのレイアウトについて紹介します。Core Elementsには、一般的なナビゲーションパターンのレイアウトを、手軽に制御できるコンポーネントが用意されています。

たとえばcore-header-panelを利用すると、よくある固定ヘッダーとコンテンツ部分の管理ができます。これまで、普通にHTMLとCSSでレイアウトして、インナースクロール用のJavaScriptライブラリを組み込んで実現していたUIが、ひとつのコンポーネントをHTML内に取り込むだけで作れるようになります。

core-drawer-panel (参考スライドP27から引用)

上図のようなドロワーメニューを内包したレスポンシブなレイアウトも、core-drawer-panelを利用すると、drawerとmainという属性をそれぞれ持った要素を、子要素として追加すれば容易に制御できます。

もうひとつレイアウトするための強力な機能が存在します。それがLayout attributesです。これはPolymer本体に備えられた機能です。

layout属性 (参考スライドP35から引用)

このように、layout属性を付与して、要素を並べる方向（vertical, horizontal）や、子要素にflexなどの指定を行うことで、CSSを使わずにHTML側で基本的なレイアウトを制御できます。ここでは一例を紹介しましたが、詳細はPolymerのドキュメントを確認してみてください。

Material Designを使う

いよいよPaper Elementsが登場します。Core Elementsが基本的な機能と素朴な見た目しか持たない汎用コンポーネント群であるのに対して、Paper ElementsはMaterial DesignのガイドラインにおけるUIコンポーネントを、ビジュアルとインタラクションの両面において実装しています。

たとえばpaper-tabsは、次の画像のようなマークアップでMaterial Designで表現されたタブのUIを組み込むことができます。

paper-tabs (参考スライドP44から引用)

このようなPaper ElementsのUIコンポーネントはPaper Elements Samplerで動作デモを確認できます。

Material Designは影や波紋のようなエフェクトといったインタラクションも重要です。Paper Elementsの中にはそのような、特定のUIを表現するものではなく、エフェクトを適用するための要素も用意されています。

paper-shadow (参考スライドP47から引用)

paper-shadowは親要素に、z属性で指定されたコンテンツの深度に応じて、適切な影の表現をつけられます。Material Designでは、影を表現するために、深さを表現するKey Shadowと、オブジェクトの形態を示すAmbient Shadowの2つが使われています。このpaper-shadowもCSSのbox-shadowで2種類の影をかさねて表現しています。

前半で説明したとおり、Material Designにおける影は、ただの装飾ではなく、オブジェクトの階層やユーザーのフォーカスを得るための、意図的な表現です。多くのオブジェクトに、このようなエフェクトを積極的に使っていくことになります。

paper-ripple (参考スライドP46から引用)

paper-rippleは親要素に、clickやtouchしたときのエフェクトを適用できます。デモを見ると、それがどのような効果か分かりやすいはずです。このエフェクトは、親の要素と同じサイズのcanvasを展開して、その上で波紋のようなエフェクトを表現しています。

スタイルを適用する

Polymerの要素は、Shadow DOMが使われているため、従来どおりのCSSセレクタでは、内側の要素にスタイルを適用できません。ここではCSS Scoping Moduleとして定義されている、::shadowと/deep/セレクタを紹介します。

::shadowは、疑似要素としてShadow DOMのルートにアクセスできます。次の例では、Polymerで作られたx-fooが持つShadow DOM内のspanにアクセスして、color: redを指定しています。

<style>
x-foo::shadow span {
  color: red;
}
</style>

<polymer-element name="x-foo" noscript>
  <template>
    <span>Hi!</span> <!-- color: red -->
  </template>
</polymer-element>

<x-foo></x-foo>

/deep/は、::shadowと同じくShadow DOM内へのアクセスを可能にしますが、より強力にネストしたShadow DOMの奥深くまで適用できます。次の例では、x-helloの中にあるすべてのspanにcolor:blueを適用しています。::shadowの場合だと、x-worldの中のspanにはネストしたShadow DOMの境界を越えられず適用されません。

<style>
x-hello /deep/ span {
  color: blue;
}
</style>

<polymer-element name="x-hello" noscript>
  <template>
    <span>Hello</span> <!-- color: blue -->
    <x-world></x-world>
  </template>
</polymer-element>

<polymer-element name="x-world" noscript>
  <template>
    <span>World</span>  <!-- color:blue -->
  </template>
</polymer-element>

<x-hello></x-hello>

一方、Core ElementsにはPolymerの要素間でスタイルを共有するために、core-styleというコンポーネントが用意されています。

core-style (参考スライドP58から引用)

core-styleを使ってid属性が指定されたStyle Producerで定義されたスタイルを、ref属性を指定してStyle Consumerから参照することで、コンポーネントをまたいで特定のスタイルを共有できます。

トランジションを利用する

core-animated-pagesを利用すると、Single Page Applicationのように、ひとつのHTMLで複数のコンテンツを切り替えて表示するときに、トランジションを適用できます。core-animated-pagesも、対象の要素に属性を付与するだけで、トランジション効果を得られます。

<polymer-element name="animated-sample" noscript>
  <template>
    <style>
      section > div { color:white; height: 500px; }
    </style>

    <!-- コンテンツ切り替え用のタブ -->
    <paper-tabs id="tabs" selected="0">
      <paper-tab>ONE</paper-tab>
      <paper-tab>TWO</paper-tab>
      <paper-tab>THREE</paper-tab>
    </paper-tabs>

    <!-- コンテンツとトランジション付与 -->
    <core-animated-pages
      selected="{{$.tabs.selected}}"
      transitions="cross-fade-all">
      <section>
        <div style="background:red">
          <h1>ONE</h1>
        </div>
      </section>
      <section>
        <div style="background:blue">
          <h1>TWO</h1>
        </div>
      </section>
      <section>
        <div style="background:orange">
          <h1>THREE</h1>
        </div>
      </section>
    </core-animated-pages>
  </template>
</polymer-element>

<animated-sample></animated-sample>

core-aniamted-pagesのtransitions属性で、使いたいトランジションの種類を宣言すると、中のコンテンツが切り替わるときにトランジションが適用されます。

Paper Elementsのサンプルアプリ

Paper Elementsを駆使することで、Material DesignがWebでどのように表現されるのかは、Topekaというサンプルのクイズアプリが用意されています。スマートフォンにも対応しているので、モバイルデバイスでどの程度動いてくれるのかも、自分でさわって確かめてみると面白いはずです。

http://www.polymer-project.org/apps/topeka/

さいごに

今回はMaterial Designとそれを実現するPolymerとPaper Elementsについて、Google I/O 2014での情報をもとにご紹介しました。Material DesignもPolymerも、Preview版というステータスであり、まだ始まったばかりのプロジェクトです。これらが、今後どのように普及し、Webの世界にも影響を与えていくのか楽しみに思います。

先日開催された第49回HTML5とか勉強会でも「Material Design with Polymer」と題して、同じようなテーマについてご紹介しました。YouTubeとSpeakerDeckでそれぞれ当日の録画とスライドが公開されているので、こちらも合わせてご覧いただけると理解が深まるはずです。Material Designについて詳しく説明していたり、Paper Elementsを利用したオリジナルのデモを行っていたりもしますので、ぜひご覧ください。

今回お届けするのは、Jake Archibald氏とAlex Russell氏によるServiceWorkerのセッション「Appy Times with ServiceWorker – Bridging the gap between the web and apps」です。

Alex氏はService Workers仕様のEditorで、古くはDojoやChrome Frameに携わっています。TC39やW3CのTAGのメンバーとしても活動し、Extensible Web構想を推し進める一人です。 Jake氏はService Workers仕様の「ゴーストオーサー」だそうです。とても面白い人で、今回も彼のユーモアが炸裂、笑いに包まれた楽しいセッションとなりました。

不確かなリクエストの旅を助けるServiceWorker

セッションでは「ブラウザーランド」を舞台に、ブラウザがキャッシュやインターネットからデータを取ってくるまでのやりとりを、Jake氏とAlex氏が演じて説明するという寸劇から、ServiceWorkerの紹介が行われました。

「（AppCacheの森ではなく）HTTPキャッシュに向かい、忘れっぽい魔術師に尋ねるのだ」
「魔術師が知らなかったら？ほら、忘れっぽいわけですし」
「ならば不確かさの海を渡り、子猫が戯れるインターネットに赴くのだ」
「しかし、これまでにも多くのリクエストが戻ってきていません……」

ブラウザがリソースを取得するまでには様々な不確定要因があり、遅い・繋がらないといったことはユーザーエクスペリエンスに影響します。しかし、現在のWeb標準ではそれをコントロールする術が足りておらず、Webの持つ拡張性という良さを持ってないとのこと。これを解決するものとしてApplication Cacheが提案されましたが、宣言的な記法を導入したため、見た目のシンプルさとは裏腹に、制御不能な挙動や仕様の説明不足が問題となりました（こうした既存の技術で説明不可能な挙動は、“magic”と呼ばれてたりもします）。

しかし、Application Cacheが提供する「キャッシュ」「ルーティング」「バージョン」のという概念は、Webプラットフォームにはぜひ欲しい機能です。そこでこの3機能を持ち、その上で拡張性やデバッグのしやすさを取り込んだ仕様として、ServiceWorkerが提案されました。策定にはMozillaやSamsungをはじめ、多くの開発者も加わっており、実装もChromeとMozillaが競うように進めています。

ServiceWorkerを動かす

登録・インストールで準備

ServiceWorkerはWebアプリによって登録（register）され、ServiceWorkerがインストール（install）されて待機状態となります。インストール時にはinstallイベントが発火するので、このタイミングでアプリに必要なファイルをダウンロードできます。

// ServiceWorkerのスクリプト
this.addEventlistener('install', function (event) {
  // event.waitUntil()は中の処理が終わるまで終了を遅らせる
  event.waitUntil(
    // static-v1という名前のついたキャッシュを用意
    caches.create('static-v1').then(function (cache) {
      // キャッシュしたいリソースをCacheオブジェクトに追加
      // 追加すると自動で取得して、全部取得できたらresolveする
      return cache.add(
        '/',
        '/theme.css',
        '/polymer/polyer.js',
        // ...
      );
    })
  )
});

大活躍なES6 Promises

ServiceWorkerは複数のドキュメントから登録され、それらをコントロールします。ドキュメント主導ではなくイベント駆動であり、必要がなくなれば終了します。このため中の処理に動的なものは含められず、非同期処理が前提です。

こうした非同期処理にはコールバックやイベントなどさまざまなやり方がありますが、ServiceWorkerではECMAScript 6で定義されるPromisesというものを使います。Promisesを使うと、非同期の何かが成功した場合（resolveした）、失敗した場合（rejectされた）それぞれに対応する処理を一定のパターンで書けるため、コードの見やすさや処理漏れを防ぐことに繋がると期待できます。

// ES6 Promisesの例
// someAsyncOperation は非同期処理をPromiseオブジェクトとして返す関数
someAsyncOperation()
.then(success) // resolve（成功）時のアクションはthen()の第一引数の関数で処理
.catch(failure) // reject（失敗）時はcatch()内の関数で処理

Promisesについて解説すると、それだけで別な記事ができてしまうので、今回はJake氏によるPromisesに関するHTML5 Rocksの記事やJavaScript Promiseの本をお読みください。

fetchでリクエスト・レスポンスに介入

待機状態のServiceWorkerは、リソースの取得（fetch）やServiceWorkerのアクティベート（activate）などのイベントが発火すると動き出します。オフラインアプリにおいては、fetch時にキャッシュの確認や更新・反映や、フォールバックの提供が考えられるでしょう。

this.addEventListener('fetch', function (event) {
  // respondWith()でレスポンスを好きなようにできる
  // 引数にはResponseオブジェクトにresolveされるPromiseオブジェクトをとれる
  event.respondWith(
    // キャッシュがあればまずそれを表示
    caches.match(event.request)
    .catch(function () {
      // キャッシュにないものはふつうに取得する
      return event.default();
    })
    .catch(function () {
      // ネットワークに問題があるなどで取得不可能な場合はフォールバック
      return caches.match('/fallback.html');
    })
  );
}

参考：Cache APIって？

Cache APIは手軽に使えるキャッシュです。キャッシュと言ってもHTTPキャッシュとは完全に分離されており、さらには明示的な指示がない限り削除されない、ドメインを越えて共有されないといった大きな違いがあります。Cacheオブジェクトはcachesオブジェクトに複数格納できます。また、oninstall時のstatic-v1のように名前をつけて、参照しやすくもできます。

Cache APIのキャッシュは、適当なタイミングで消してやらなければいけません。ServiceWorkerは、自身の更新時にactivateイベントを発火します。このタイミングではfetchイベントが発生する前なので、キャッシュの削除はもちろん、データベースのスキーマ更新などに最適とのことです。

キャッシュを賢く使ってよいオフライン体験を

セッションでは、I/OのKeynoteで発表されたPolymerのPaper Elementsによるクイズアプリ「Topeka」に、ServiceWorkerでオフライン対応を施したアプリをデモしながら解説しました。

Topekaでは、クイズの得点を競い合うためのLeaderboard（スコア表）があります。クイズ本体はキャッシュさせたままでもオフライン動作に問題ありませんが、Leaderboardは順位が変動するのでインストール時にキャッシュさせることはできません。

というわけで、Leaderboardへのアクセスを他のアクセスと分けて処理します。URLのチェックには、URL APIを使うと少し楽です。

// こちらServiceWorkerのファイル
var workerURL = new URL(this.url); // URL APIきました

this.addEventListener('fetch', function (event) {
  var url = new URL(event.request.url);
  if (workerURL.origin === url.origin && url.path === '/leaderboard.json') {
    // leaderboardFetchにLeaderboardの処理を分岐
    event.respondWith(leaderboardFetch(event.request));
  } else {
    // その他はふつうにキャッシュがあれば使って、なければ取得するフローで
    event.respondWith(
      caches.match(event.request).catch(function () {
        return event.default();
      })
    );
  }
});

// 後ろのコードにつづく…

ここでJake氏は、Leaderboardについても常にリクエストするのではなく、キャッシュがあればまずそれを表示し、並行して最新のLeaderboardをリクエストし、取得後に反映するという、ネイティブアプリのオフライン対応でも使われる方法を提案しました。こうすると、新しいLeaderboardをリクエストしている間は画面が真っ白になるといったことがありません。

Leaderboardのキャッシュがあればそれを用い、その後で新しいLeaderboardを取得し置き換える処理を示すフローチャート

これを実装するとなると、キャッシュされているLeaderboardが最新のものかを確かめ、古い場合はキャッシュを更新しなければいけません。一体どうするのでしょうか。これはまずアプリから「キャッシュを使ってほしい」とServiceWorkerに伝えないといけません。

// こちらかわってアプリのJavaScriptコード
var showingLiveData = false;

// ふつうにネットワークから取得するPromiseオブジェクト
var liveDataPromise = fetchJSON('/leaderboard.json')
.then(updatePage).then(function () {
  showingLiveData = true;
});

// キャッシュを使うようにServiceWorkerに伝えるPromiseオブジェクト
// serviceWorker.controllerはページをコントロールするSWを返す
if (navigator.serviceWorker.controller) {
  // （fetchJSON()ってメソッドは仕様にないけど、fetch()に似た何かでしょう）
  var cachedDataPromise = fetchJSON('/leaderboard.json', {
    // てきとーなヘッダでタグづけ。これ重要
    headers: { 'X-Cache-Only-Please': 'yep' }
  })
  .then(function (data) {
    if (!showingLiveData) {
      updatePage(data);
    }
  });
}

// セッションのスライドにはなかったので以下勝手に追加
// たぶんこんなコードが入るはず
liveDataPromise.catch(function () {
  return cachedDataPromise
})

キャッシュを使わせるよう適当なヘッダをつけてリクエストします。ServiceWorkerはこのヘッダの有無を確かめ、キャッシュがない場合は新しいデータを取得し、キャッシュに追加します。これを処理するのが、ServiceWorkerのスクリプト側にあるleaderboardFetch関数です。

// こちらふたたびServiceWorker
function leaderboardFetch(request) {
  // タグづけされたリクエストの場合は、マッチするキャッシュをそのまま返す
  if (request.headers.has('X-Cache-Only-Please')) {
    return caches.match(request);
  } else {
    // そうじゃない場合はまずstatic-v1なキャッシュを取得し
    return caches.get('static-v1')
    .then(function (cache) {
      // 最新のleaderboardをとってきてキャッシュを更新
      return cache.add(request);
    })
    .then(function (responses) {
      // それだけじゃ何にもならないのでブラウザにも渡す
      return responses[0];
    });
  }
}

ServiceWorkerでいろいろしてみる

主にオフラインWebアプリの解決策として紹介されるServiceWorkerですが、要はクライアントサイドでプロキシを動かすようなものなので、その気になればかなりいろいろできます。

たとえば、新しい画像フォーマットを使うとして、対応してないブラウザではクライアントサイドでPNGに変換して返すなんてことができます。

this.addEventListener('fetch', function (event) {
  // request.contextにはいろいろあります
  // http://fetch.spec.whatwg.org/#concept-request-context
  if (event.request.context === 'image') {
    event.respondWith(
      // リソースを取得し、そのレスポンスのContent-Typeをみる
      event.default().then(function (response) {
        if (response.headers.get('content-type') === 'image/amazing') {
          // 謎メソッドでPNGに変換
          return transcodeToPng(response.body);
        }
        return response;
      })
    )
  }
})

こちらはもっと一般的（？）なユースケースでしょうか。あるクライアントサイドでテンプレートエンジンを動的に適用しその結果を返すといった、フレームワーク依存が強かったところも少し解決されます。

// importScriptsはWeb Workersのやつですね
importScripts('/template-engine.js');

this.addEventListener('fetch', function (event) {
  var url = event.request.url;
  if (event.request.context === 'navigation' && /\/article\//.test(url)) {
    event.respondWith(
      fetch(url + '.json').then(function (response) {
        // asJSON()はStreams APIに移動しそうだけど、いまはFetch仕様にて定義
        // http://fetch.spec.whatwg.org/#fetchbodystream
        return response.body.asJSON();
      }).then(function (json) {
        // JSONとれたらテンプレートを呼び出して
        return caches.match('/template.tmpl').then(function (response) {
          return response.body.asText();
        }).then(function (template) {
          // テンプレートを適用したものをHTMLにして返す
          return new Response(renderTemplate(template, json) {
            headers: {
              'Content-Type': 'text/html'
            }
          });
        })
      })
    );
  }
});

ネコ好きのJake氏は、木曜日になったらすべての画像を猫画像に差し替えてしまうコードを紹介して、拍手をもらっていました。

this.addEventListener('fetch', function (event) {
  if (event.request.context === 'image' && new Date().getDay === 4) {
    event.respondWith(
      caches.match('/kitten.jpg');
    )
  }
});

ServiceWorkerはキャッシュ、ルーティング、バージョニングの仕組みが分離さてているので、いろいろ応用がききますね。

また、ServiceWorkerはWeb Workersの拡張なので、postMessage()でメッセージの送受信が可能です。これを使って、「あとで読む」機能の仕組みを作れます。

// こちらアプリ
navigator.serviceWorker.controller.postMessage({
  action: 'read-later',
  articleId: 12345
});

// こちらServiceWorker
this.addEventListener('message', function (event) {
  if (event.data.action === 'read-later') {
    // articleIdを持つ記事のリソースを取得してキャッシュに追加する
  }
});

普通のJavaScriptとしてデバッグ可能

ServiceWorkerのパワフルさはお分かりいただけたかと思えますが、ほかにもいろいろ利点があるとのこと。まずAppCacheとは違い、JavaScriptコードなので、DevToolsでデバッグできるという点が大きいでしょう。Chromeでは、chrome://inspect/#service-workersや chrome://serviceworker-internals/といった、デバッグに便利なページも用意されています。また、現在Chrome Canaryで導入されているDevToolsの新しいエミュレーションモードでは回線状況のシミュレーションができるので、それを組み合わせると遅いネットワークを想定したテストもできるのでおすすめとのことです。このDevToolsの新しいエミュレーション機能については、Tomomi ImuraさんによるPaul Bakaus氏のセッションレポートで紹介されていますのでお読みください。

少し不便な点といえば、MitM attackを防止するためにHTTPSで提供されたページでしか動作しないことでしょうか。ただ、手元での開発への影響を抑える目的でlocalhostはその例外として機能するとのこと。

ネイティブとの差を埋めるためには

セッションのタイトルには、「Bridging the gap between the web and apps（『Webとアプリの差を埋める』）」とあります。キャッシュやルーティングによって必要なリソースをインストールさせてオフラインでも動作させるのも必要ですが、ネイティブアプリにあってWebにはまだ足りていないものがまだまだあるとのこと。その一例としてJake氏はプッシュやバックグラウンド同期を挙げ、それに対応するWeb標準（Background Sync, Push API, Web Notifications）を紹介しました。

Background Sync以外は策定中で、Notifications仕様については実装もあります。しかし、ServiceWorker対応はこれから。というわけでTopekaでどのようにServiceWorkerと同期・プッシュ・通知が実装されているかを紹介しました。Leaderboardのスコアを同期し、トップを奪われたら通知が来るという機能の実装です。

まずは同期です。ServiceWorkerがインストールされているかを確認し、スコアの同期をとります。

// app.js
sendScore().catch(function () {
  // serviceWorker.readyは常にresolveするPromiseを返す
  navigator.serviceWorker.ready.then(function () {
    // 同期はnavigator.syncに登録するらしいです
    navigator.sync.register('send-score')
    .then(success, failure);
  });
});

この同期は1回きりで終了しますが、特定の間隔で同期するタスクも登録。例として、1時間ごとに質問の更新をするタスクが紹介されました。

// app.js
navigator.serviceWorker.ready.then(function () {
  navigator.sync.register('update-questions', {
    minInterval: 1000 * 60 * 60
  }).then(success, failure);
});

minIntervalはあくまでヒントとして伝えられるだけのようで、ブラウザがもっと賢くスケジューリングするのも構わないと説明していました。

さて、ユーザーが同期を許可すると、ServiceWorkerにsyncイベントが伝えられます。複数の同期をスケジュールしていたので、イベントの idプロパティで処理を振り分けます。

// sw.js
this.addEventListener('sync', function (event) {
  if (event.id === 'update-questions') {
    event.waitUntil(syncQuestions());
  }
  else if (event.id === 'send-score') {
    event.waitUntil(sendScore());
  }
});

渡されたPromiseオブジェクトがrejectされた場合は、同期が再スケジュールされるとのことなので、また登録する必要はないとのこと。

スコアを送信する sendScore() 関数は、データベースからスコアを取得し、それをPOSTします。

// sw.js
function sendScore() {
  return getScoreFromDatabase().then(function (score) {
    // Fetch APIはもちろんPOSTもできます
    return fetch('/post-score', {
      method: 'POST',
      body: new FormData({score: score})
    })
    .then(function (response) {
      if (response.status !== 200) {
        throw Error('Failed to post score');
      }
    });
  });
}

プッシュメッセージについては、Google Cloud Messagingを使った実装でのやり方が紹介されました。

// app.js
var regID = '...'; // サーバーに送った登録ID

navigator.serviceWorker.ready.then(function () {
  navigator.push.register().then(function (regDetails) {
    if (regDetails.id !== regID) {
      return postToServer(regDetails);
    }
  }).then(success, failure);
});

GCMでは、プッシュの登録が完了すると、以前の登録したプッシュの詳細が返ってくるそうで、今回処理しようとしているものと同じでないかを確認してから、サーバーにメッセージを送っています。

ServiceWorkerでは、pushイベントが通知されます。これを拾ってNotification APIで通知を出します。

// sw.js
this.addEventListener('push', function (event) {
  if (event.message.data === 'lost-lead') {
    new Notification('Lead lost!', {
      body: 'You\'re no longer top!',
      tag: 'leaderboard',
      serviceWorker: true
    });
  }
});

デモでは2つのNexus 5を用意し高得点を競い、トップを奪われた方に通知が届きました。また、Android Wearでもその通知が表示されました。

大規模なカンファレンスにつきものなネットワークの悪さもあって、通知が来るまでに時間がかかりました。みんなそわそわしましたが、「オフラインWebアプリでも問題ないセッションが、デモのせいで失敗するとか…！」「ふー、このセッション自体も非同期とは」といったオフライン・非同期ジョークなどが飛び出し、会場を和ませました。

まだまだあるよServiceWorker

セッションで紹介されたServiceWorkerの機能は以上です。盛りだくさんでした。

このセッションでは、ServiceWorkerの更新については語られませんでした。これについてはJake氏がService Worker – first draft publishedという記事で紹介しています。

ServiceWorkerの実装は少しずつ進んでいますが、仕様の議論も並行しているため、今回紹介したコードが動かなくなる可能性は十分にあります。何かアップデートがあればまたServiceWorkerに関する記事が公開されるかもしれませんので、楽しみにしていてください。

Web Componentsが変えるWeb開発の未来

Google I/O 2014でEric BidelmanがPolymer and Web Components change everything you know about Web developmentというタイトルで、Web Componentsおよびその補完・拡張ライブラリであるPolymerについてセッションが行われました。

• 「なぜWeb Componentsが生まれたのか」
• 「Web Componentsが何を解決してくれるか」

この2点を上記セッションに沿って解説していきます。

HTML/CSSが持つ弱点

Webを構成していくパーツを作る際、今まではどのように行っていたでしょうか。<div>や<textarea>といったようなネイティブで用意されているタグに、CSSで見た目で装飾し、JavaScriptからDOMのAPIを操作してインタラクションを付与してきました。

しかし、このようにせっかく作った部品を再利用しようとすると、たちまちリスクを生んでいました。これはHTMLやCSSがスコープを持たず、既存のHTML/CSSを上書きし汚染してしまう可能性を持っていたためです。一般的なプログラム言語にはスコープが存在しますが、Cascading Style Sheetの名の通り、記述された内容は全て後勝ちで宣言されます。CSSのクラスはJavaScriptに例えるならば、全てグローバル変数のような存在であると言えるでしょう。

これに対して、開発者は様々な工夫を行ってきました。CSSに命名規則を設けてより強固な設計概念を作ったり、コンポーネント管理をJavaScript上で行うべくライブラリを作ったり…。しかしそれらは共通の構成を持っているわけでもなく、APIもバラバラです。つまりそのルールの元でしか通用せず、万人共通の解決策にはなりません。

Web Componentsあらわる

そこで生まれたのがWeb Componentsです。Web Componentsは以下の4つの仕様から構成されます。

• Custom Elements – Custom Elementsによってネイティブで実装されていない、新しいHTML要素を定義することが可能になりました。定義された要素はHTML中に書いたり、document.createElement('new-element')等、既存のタグと同じように使うことができます。
• Templates – Templatesはtemplateタグを使った、DOMベースで利用可能なテンプレートの仕様です。HTMLをテンプレートとして利用したいケースは多々ありましたが、それを実現するにはscript type='text/template'等の、ハックアイデアを使うしかありませんでした。
• HTMLImports – HTMLImportsはlinkタグを使った、HTMLをロードするための新たな仕様で、これを使うことで断片化したHTMLのロードを容易に行うことができるようになります。HTMLにおいて、サブリソースのロードは珍しくありません。画像であればimg、音声であればaudio、スクリプトであればscriptを使ってロードしますが、HTMLのロードはiframeを使う必要がありました。しかし、iframeを使ったロードは制限が多く、XMLHttpRequestを使う方法もコンポーネントのロードとしては利用し難いものです。
• Shadow DOM – 前述の通りHTML/CSSにはスコープが存在しませんが、Shadow DOMがそれを解決します。DOMのAPIとして追加されたcreateShadowRoot()を使うことで、Shadow Rootという他のDOMに干渉されないような新しいノードを生成します。

Shadow DOMとTemplatesを使って新たな要素を構成し、Custom Elementsを使って定義します。それらを集約したHTMLファイルをHTMLImportsを使ってロードすることで、晴れて新しい要素を使うことが可能になります。これがWeb Componentsの考え方です。

Web Componentsが解決してくれること

セッション中にBidelmanも触れているとおり、既存のHTML+CSSによるWebページの構築は、混沌とした状態を生み出してしまうことは周知の事実です。 以下はGmailの例ですが、アプリケーションが複雑化すればするほどDOMのネストは深くなり、セマンティクス性は皆無です。

でも、Web Componentsを使って要素を再定義して、もし以下のようにできたらクールではありませんか？

<mail-label-list>
  <mail-label type='starred'>スター付き</mail-label>
  <mail-label type='important'>重要</mail-label>
  <mail-label type='sent'>送信済みメール</mail-label>
  <mail-label type='draft'>下書き</mail-label>
</mail-label-list>
<mail-list>
  <mail-item title='...' to='...' from='...' datetime='...' label='...'></mail-item>
  <mail-item title='...' to='...' from='...' datetime='...' label='...'></mail-item>
  <mail-item title='...' to='...' from='...' datetime='...' label='...'></mail-item>
</mail-list>
...

また、命名規則やJavaScriptのライブラリに頼ったコンポーネント化とは異なり、 標準化を目指したブラウザの仕様である ことも重要なポイントです。これは、仕様の策定が進み各ブラウザの実装が追いつけば、ライブラリや方法論に依存せずコンポーネントを再利用することができることを意味しています。

Web Componentsが抱える課題等

ブラウザの対応状況

• 2013年時のブラウザネイティブ対応状況
• 2014年時のブラウザネイティブ対応状況
• PolymerのPlatform.jsのポリフィル利用時

Web Componentsの過渡期であった2013年の段階では、ChromeとFirefoxが、Templates・Custom Elements・Shadow DOMをそれぞれ部分的にサポートしている状態でしたが、2014年のGoogle I/O時点ではChrome、Firefox、Operaが大半をサポートしているというところまで来ています。そして、Polymerチームが開発しているWeb Componentsのポリフィルライブラリである Platform.js を使うことでSafari、Internet Explorerを含めたほとんどのブラウザでWeb Componentsを利用することが可能になりました。

パフォーマンス

実行速度面についてはもちろん、実際に動作するPC・モバイルといったデバイスによって異なるので一概には言えませんが、プロセッサやメモリの進化はネットワーク等に比べて早いのと、ブラウザのJITコンパイル等の最適化が進むに連れて、気にならないレベルになるかと予想（期待）しています。

また、Webパフォーマンスの初歩としてHTTPリクエストを削減するというアプローチが広く浸透していますが、Web Componentsを使ったリソースの断片化は相反する関係にあると言えます。先程のブラウザの実装状況や仕様の策定状況を考慮しても、しばらくはPolymer等のポリフィルライブラリを利用するのが現実的かと思います。従ってWeb Components同士にHTMLImportに加えて、ネットワークを介して必要になるリソースが、今までより多くなるのは間違いないでしょう。

Polymer/vulcanizeという、事前にWeb Componentsを結合するビルドツールもありますが、ネットワーク越しにあるコンポーネントをロードしたいケースも多々あるでしょうから、今後更なる最適化アプローチが現れるかもしれません。

Polymer Designerを使ったWeb Componentsの作成

Polymerを使ったコンポーネントの作成は、ソースコードレベルでももちろん可能ですが、今回はPolymer designer toolを使ってみます。これはブラウザ上で、Polymerの要素を組み合わせて新たなコンポーネントをGUIで作ることが可能なサービスです。ちなみに、このサイト自体がPolymerを使ったWeb Componentsで構成されており、非常に興味深いです。

yt-search-video + speech-mic

今回はyt-search-videoというYouTubeにある動画を検索し表示するコンポーネントと、speech-micというマイク入力を認識し扱うコンポーネントを組み合わせて、音声入力でYouTubeの動画を検索するコンポーネントを作成してみます。

コンポーネントの選択

画面右下のPALETTEにコンポーネントの一覧があります。使いたいものを選択し、画面左の方眼紙のようなキャンバスにドラッグアンドドロップします。今回はyt-search-videoとspeech-micを配置します。

配置されたコンポーネントは、TREEに一覧表示されます。 TREE中で選択している要素はキャンバス内でもハイライトされていたり、右上のPROPERTIES や STYLESの表示対象になったりと、直感的に使うことが可能です。

データバインディングの設定

マイクの入力値をYouTubeの検索クエリと紐付けたいので、その設定を行います。マイクの入力値はspeech-micのcompleteTranscriptなので、それをyt-search-videoのImFeelingLuckyとバインディングします。

完成！

これで完成です。画面左上の <> ボタンをクリックすると生成されたコードを見ることが可能で、実際の挙動もデザイナー上で確認することが可能です。生成されたコードや依存コンポーネントをインポートすれば、もちろん実際にmy-elementとして使うことができます。簡単な手順で作成可能ですので、よかったら試してみてください。

生成されたコードを見てみると、completetranscript="{{ $.yt_search_video.ImFeelingLucky }}"とPolymerのお作法通りにバインディングされています。このデータバインディングはWeb Componentsに備わっているわけではなく、Polymerが提供する強力な機能の1つです。

<link rel="import" href="../components/polymer/polymer.html">

<polymer-element name="my-element">

  <template>
    <style>    
      :host {
        position: absolute;
        width: 100%;
        height: 100%;
        box-sizing: border-box;
      }
      #yt_search_video {
        width: 300px;
        height: 300px;
        left: 280px;
        top: 160px;
        position: absolute;
      }
      #speech_mic {
        left: 640px;
        top: 290px;
        position: absolute;
      }
    </style>
    <yt-search-video id="yt_search_video"></yt-search-video>
    <speech-mic completetranscript="{{ $.yt_search_video.ImFeelingLucky }}" id="speech_mic"></speech-mic>
  </template>

  <script>

    Polymer('my-element', {
      
    });

  </script>

</polymer-element>

Web ComponentsおよびPolymerに関する資料

Polymer公式

• Getting started – Polymerの公式チュートリアルです。Web Componentsの基礎を抑えた後は、こちらをどうぞ。
• API developer guide – いざPolymerのデバッグをする時は、こちらを見ることになるかもしれません。

HTML5Rocks

　HTML5RocksにもWeb Componentsに関する記事がいくつもあります。えーじさんが日本語訳をしてくれてます。

• Shadow DOM 101 – Shadow DOMの記事
• HTML で利用可能になった Template タグ – クライアントサイドのテンプレートの標準化 – Templatesの記事
• Custom Elements – HTMLに新しい要素を定義する Custom Elementsの記事
• HTML Imports – ウェブのための#includeHTML Importsの記事

Others

ほかにも参考になるリソースがありますので紹介します。

• なぜ Web Components はウェブ開発に革命を起こすのか – えーじさんの記事です。Web Componentsの歴史やコンセプトおよび、仕様策定の現状などがわかりやすく書かれているので、一読することをオススメします。
• Web Componentsで行うHTMLのコンポーネント化 – こちらは私が以前会社のブログに寄稿したものです。Web Componentsの概要と利用方法を、コードまで落としこんで詳細に解説しています。
• Why Web Components Aren’t Ready for Production… Yet – 英語です。ブラウザの対応状況、Polymerが行っているポリフィルの仕組み、パフォーマンスについての言及など、様々な考察がされています。

まとめ

以上、簡単ではありますが、Web ComponentsとPolymerについて紹介しました。

Web Componentsが普及すれば、今までHTML/CSSが備えていなかったパーツの可搬性は解決され、コンポーネント（機能を含めたUIパーツ等）の流用は容易になり、今まで行っていた機能の再開発をする必要がなくなることも期待できます。

デザイナーがデザインし、ディベロッパーがHTML/CSSを組み、インタラクションをつける人がJavaScriptを書いているような分断されがちであったワークフローも徐々に境がなくなり、1つの機能単位でコンポーネントを実装するようなフローになっていくかもしれません。

今後もWeb Components/Polymerの動向に注目です。Web Components及びPolymerのより詳細な実装については、次回以降の記事で解説します。

概要

Google I/O 2014のセッションの1つ「Making music mobile with the Web」のレポート記事です。Officialに公開されているYouTubeはこちらです。

OpenWeb 技術であるWebRTC、Web Audio APIは一度は耳にしたことのあると思います。この2つの技術、そして標準化が始まったばかりのWeb MIDI API（電子楽器とブラウザを直接接続するAPI）を利用した音楽制作アプリケーション「Soundtrap」。これらを使って、実際にセッションのオーディエンス、遠隔地の人とコラボレーションをして、Google I/Oのテーマ曲を作成するデモンストレーション中心のセッションでした。本レポートと合わせて映像もぜひご覧ください！

このセッションでは、主にモバイル端末（Nexus 7、Nexus 5）を使って進行されました。Webアプリといえば、JavaScriptでの構築を想像される方も少なくないので意外でした。しかしながら、「Soundstrap」はDartで開発されていたところでした。(開発言語にDartを選択した理由も、後ほど説明していきます)

それでは内容を見ていきましょう。

※2014/7/4にDartは、ECMA標準仕様として承認されたと発表がありました。

音楽制作

音楽制作にはいろいろな進め方がありますが、このセッションでは以下の順で録音が進められました。

1. リズムの選択 (1:49-)
2. Bass の録音 (3:02-)
3. Guitar(メロディー)の録音 (15:11-)
4. Keyboard(伴奏)シーケンスの作成 (16:28-)
5. Vocal の録音 (23:30-)
6. Mix Down (34:55-)

1. リズムの選択

曲のベースとなるリズムを決めます。Soundtrapにあらかじめ用意されているLoop素材を追加し、リズムを聴きながら「ん～」とか「もっとRockしてるのがいいな～」とかコメントしながら選択を終えました。

2. Bassの録音

Bassの音はあまり耳には聞こえませんが、実は曲の重要な土台となる低音パートです。 Bassの録音をすると、リズムしかなかった曲の輪郭がモヤっと見えてきます。

Bassを録音する様子

Media Capture APIの1つである、getUserMedia()を使って録音します。

getUserMedia()は、マイクからのInput、WebカメラからのビデオStreamを取得する時に使います。マイクからのInputを取得する時は、スピーカーからの出力をマイクが拾わないようにAEC(Acoustic Echo Canceling)、またマイクからのInputのレベルを保つために AGC(Auto Gain Control)を行うことが可能です。マイク以外の入力を取得する場合（Line入力：ギター、シンセサイザー等）は必要ないので、今回もOffにします。コードは以下のように書きます。

navigator.getUserMedia({audio:{echoCancellation: false}}).then((stream) {
  // 実際の処理をここに書きます
});

then() が見慣れない書き方かもしれませんが、これはDartに実装されている Futureという並列処理デザインパターンです。streamを得た時にどんな処理をするのかを、then()の中に書きます。

3. Guitar（メロディー）の録音

Guitarで主旋律パートを録音します。主旋律ですので向かう方向がハッキリします。

Guitarの録音をする様子

Bassの録音と同じく、getUserMedia()を使って録音します。

特にギターの場合、エフェクターという専用の信号処理機械を通して音を作ることが多いです。エフェクトの種類は音を遅らすDelay、音程を微妙にズラすことで複数でコーラスをしているかのようなハーモニーを作るChorus、音を歪ませることで音に角を付け、いわゆるエレキギターと聞いて想像する音を作るFuzz、Distortion、Overdriveがありますが、これらのエフェクトもブラウザで行ってしまいます。（セッション内でのデモ）

これらのエフェクトは、以下のように接続します。

Input(getUserMedia()からのAudioStream)をWebAudioで作成したEffectsを通し、WebAudioでの音声の出力口であるDestinationに接続します。

Delayエフェクトの接続方法を例にとって、実際に説明をします。

Guitarの音(Input)を直接Destination、またDelayに接続します。Delayで任意の時間遅らせて発音した音を、Gainに接続して音量を絞ります。最後にDelayで遅らせ、音量を絞った音をDestinationに接続します。結果としてギターで弾いた音は、山に向かって「ヤッホー」と叫びやまびこを楽しんでいる人の隣で聞いているかのような効果、つまりEffectが得られるのです。

この接続をコードにすると、以下のようになります。

var context = new AudioContext();

// getUserMediaのAudioStreamをWebAudioに接続する
navigator.getUserMedia({audio:true}).then((stream){
  var guitar = context.createMediaStreamSource(stream);
  var speaker = context.destination;
  guitar.connect(speaker);
});

// Delayエフェクトの接続
var delay = context.createDelay();
guitar.connect(delay);

var gain = context.createGain();
delay.connect(gain);

// Delayエフェクトをかけた音を、出力口のSpeaker(Destination)に接続
gain.connect(speaker);

4. Keyboard(伴奏)シーケンスの作成

そして、Keyboardで伴奏パートのシーケンスの作成を行います。伴奏が入ると曲がハッキリし、各楽器通しでハーモニーが生まれます。

左下小窓がMoscone Center West、全体がGoogle San Francisco OfficeからWebRTC でStreamingしている様子

WebRTCを使って、上の画像のように遠隔地から行います。Google I/Oの会場であるMoscone WestとGoogleさんのSan Francisco Officeを接続し、シーケンスを直接Soundtrapに作成します。Keyboardの演奏はWeb MIDI APIを使い、Keybord（電子楽器）とブラウザを接続して演奏データはMIDI Messageの形式(音声データではなく、「どの音を、どの強さで鳴らせ/止めろ」というような指示を表現したメッセージ)で時間と一緒に記録（シーケンスの作成）を行い、再生する時には記録された時間通りにMIDI MessageをSoundtrap上にあるSoftwearシンセサイザーに送信して、Softwareシンセサイザーが音を出しています。

セッションの中で説明はありませんでしたが、Web MIDI APIを使って電子楽器とブラウザを接続するコードを以下に紹介させていただきます。

// 電子楽器と接続
navigator.requestMIDIAccess({sysex:true}).then(successCallback, errorCallback);
function successCallback(access){
　// 入力として利用可能な電子楽器のリストをConsoleに出力
　var inputs=access.inputs()
  console.log(inputs);

　// 入力として利用可能なindex=0の電子楽器から受信したMIDI MessageをConsoleに出力
  inputs[0].onmidimessage=function(event) {
    console.log(event.data);
  }

　// 出力として利用可能な電子楽器リストをConsoleに出力
  var outputs=access.outputs()
  console.log(outputs);

　// 出力として利用可能なindex=0の電子楽器にMIDI Messageを送信
  // A4(ラ：440hz、MIDI Key番号：0x45(69))を最大音量(7F(127)で発音させる例)
  outputs[0].send([0x90, 0x45, 0x7f]);
}
function errorCallback(msg) {
  // 何らかの問題で電子楽器との接続ができなかった場合、Consoleにエラーメッセージを出力
  console.log(msg);
}

※JavaScriptでの書式になります。 .then()に関して、書式はDartとJavaScriptで同じですが、Dartでは Futureという並列処理デザインパターン、一方JavaScriptではPromiseという並列処理デザインパターンですので、内容は正確にいうと異なりますのでご注意ください。

次に、WebRTCの接続についてです。WebRTCは、RealtimeにPeer to PeerでAudio、Video、Dataの3種類のStreamを使ったコミュニケションができるAPIです。接続には、PeerConnectionを使います。Soundtrapにてビデオチャットを行いながら音楽制作を行うためには、ビデオチャットを行うWebcam stream、音楽制作用に楽器のステレオ音声を送るStereo music streamが必要になります。

ビットレートはそれぞれStereo music Streamが128Kbps、Webcam streamがVP8 HD 2Mbpsで、PeerConnectionを使ってStreamしています。

5. Vocalの録音

録音の最後はVocalです。これで曲のメイン素材の録音、作成が完成です。

Nexus 5を片手に会場で歌声を録音する様子

Vocalの録音はNexus 5(携帯電話)を使用して、getUserMedia()を使って録音を行います。実際に歌うのはセッションのオーディエンスです！！（私の声も聞こえるかもです）マイクではなく、携帯電話をマイク代わりにして、Soundtrapに直接録音を行います。

6. Mix Down

「マスタリング」とも呼ばれ、各パート毎に音量の調節、音程の音量調節(Equalizing)、また残響(Reverb、Echo)の調節を行うことで各パートの音のバランスをとり、ハーモニーを深め、そして際立たせます。

SoundtrapはCloud型の音楽制作Webアプリケーションですので、インターネットに接続できる環境があればどこからでも音楽制作に参加することができます。もちろん、Mix Downをすることも可能です。セッションでは、Keyboard を弾いていた場所(GoogleさんのSan Francisco Office内で、セッションはMoscone Westです)でMix Downが行われました。

SoundTrap上に各パートが録音された状態

その結果、Google I/Oのテーマ曲はこのように仕上がりました。（下の画像をクリックすると視聴できます）

波形をWebGL表示した背景と共に再生されました

こちらは Soundtrap内に保存されている音源をそのまま視聴できます 。試聴する

開発言語にDartを選択した3つの理由

冒頭に、Soundtrapの開発にDartが採用されたことに触れました。以下の3点が、Dartを選択した理由だそうです。

親しみやすさ(Familiarity)

Dartはとにかく簡単に学べるようにと考えられて作られいて、Class や単一継承にセミコロン、中括弧を使うところがJavaScriptや、Java、C++にとても似ているので開発者にはとても親しみやすい。

拡張性(Scalability)

Webアプリの開発はとても小さなスクリプトから開始し、それが成長して大規模で複雑なアプリになっていく。従って大規模になった時のことを考えると、スケールアップができる環境で開発を開始することが望まれる。DartではそれをLibrary、またPackageという形で実現している。

Soundtrapの開発は、これらのDartの拡張性によってアプリが大規模になった時でも、開発のスピード（生産性）を落とすことなく進めることができたそうです。

生産性(Productivity)

Dartで開発する時は、Dart Editorを使うことができます。このEditorではコードを静的監視しているので生産性がとても高いです。例えば、静的監視されているので、アプリを動作させなくても、Unitテストを走らせなくても構文エラーをリアルタイムに知ることができるのできます。つまりDart Editorは、世の中にある熟れたIDEと同じような機能が搭載されているツールになっているので、不自由はなく、生産性高く進めることが可能です。

まとめ

Soundtrapは、OpenWeb技術であるMedia Capture、Audio Processiong、Real-time CommunicationのAPIの紹介にはとてもよいアプリケーションです。今回はChrome上で動作させて紹介しましたが、これらの技術はOpenWeb技術ですので、デスクトップ、モバイル環境にある別のブラウザでも動作させることが可能です（可能になるでしょう）。また、これらの技術を使うことのできる世の中のデバイス数は、以下の通りです。

• Web Audio 20億のデバイス（10億がモバイル）
• WebRTC 15億のデバイス（3億がモバイル）

そして Android LのWebViewではChrome V36相当になりますので、Web Audio、WebRTCがほぼすべてのAPIをサポートされた形で使えるようになります。30日でのアクティブユーザ数が10億のAndroidという環境ですので、ものすごく多くのユーザーに対して、これらを使ったアプリケーションの提供が可能になるため、そのインパクトは絶大です。

Q&Aで質問が出た項目

Q. Android LでのAudioのLatencyについて教えてください。

A. 数値の約束はできないが、改善に向けて真剣に取り組んでいる。ICS、JB、Kitkatで20msまでLatencyを短縮することはできた。しかしながら、我々としてもまだまだ満足はしていないので改善していくだろう。

Q. MIDIのサポートについてどこまで進んでいるのか教えてください。

A. Web MIDI APIはOpenWebStandardとして標準化が始まったばかりで、Chromeは先行して実装を行った。次期、またはその次のVersionでは全ての機能の実装を行い、さらにFlagの設定なしでの動作させる予定です。セッション内でSoundtrapで利用しましたが、もちろんセッション内だけなく、Soundtrap内ではMIDIの接続も利用することが可能です。
Chrome以外のブラウザでのサポートに関しては、現状様子見を行っています

Q. Mix Downはクライアントサイドで行っているのか、サーバーサイドで行っているのか教えてください。

A. 音源はクラウド上のサーバー側にあって、再生をクライアントで行っています。サーバサイドはJavaとScalaで利用可能なPlay Frameworkを使っています。クライアント側で再生する時は、サーバー側でMix DownしたMP3ファイルを作成し、それをSoundtrapというクライアントアプリ側で再生をするという仕組みになっています。

セッションを終えて感じたこと

Before Web Audio/MIDIの時代では、DAW（音楽制作用ソフトウェア）を購入し、Audio I/F、キーボード、マイク等のハードウェアを揃えながら満足できる音楽制作の環境を整えるまでには、いささか道のりが長く時間がかかるのが常識で、またそこを楽しむこともありました。

しかし、Webブラウザで、デスクトップはもちろん、モバイルデバイス上での制作、さらには遠隔地とつないで、誰でも手軽に音楽制作に手を伸ばすことのできる時代（味見も含めて）なのだなと改めて感じました。制作はもちろんですが、ツールの作成、エフェクトの作成等、少し頑張れば、かゆいところに手の届くいわゆるオレシステムを作り上げることもそこまでハードルは高くないと思います。

今やアマチュアバンドとはいってもホームページを持ち、そこには自ら制作した楽曲、さらに自らで制作したであろう、とはいえクロリティの高いプロモーションビデオまでも揃えて公開する時代。昔はインスピレーションを得たらその場でフレーズやパターンの作成ができ、モバイルできる音楽制作専用ハードが流行した時もありました。

これからはインスピレーションを得たらポケットからさっとモバイルな汎用デバイスを取り出し、ブラウザを立上げDAWのURLに接続をし、その場でフレーズのみならず全体の流れを録音し楽曲にまとめることも容易になるでしょう。そして、遠隔にいる友人にバッキング、Mix Downしてもらい、その場でプロモーションビデオまで制作する一連の流れを即興でできてしまう、なんていうアマチュアでもプロ顔負けの音楽制作環境を持てる、素晴らしい時代が確実に来るだろうと感じました。同時に、これらの音楽制作に欠かせない技術と他のOpenWeb技術を連携させることでどのような新しい表現方法、また価値、文化が生まれるのかワクワクを膨らませてきた次第です。

W3Cの一員として標準化を進めているWeb MIDI API。今回は少しだけ登場し、スライドとしての説明はありませんでしたが、音楽を制作をする上ではコアになる技術です。標準化までこぎつけられるように強く推進をしていかねばとも感じました。

紹介されたURL等

• Soundtrap：デモで使われたOpenWeb上に構築された音楽制作環境
• Getting Started with WebRTC：WebRTCのチュートリアル（英語）
• Getting Started with the Web Audio API：Web Audio APIのチュートリアル(日本語)
• Get Started with Dart：Dartのチュートリアル（英語）

今回のGoogle I/OはAndroidに特化していた傾向が強く、WebテクノロジーやChromeの扱いが比較的小さかったせいもあり、多くのWebフロントエンドディベロッパーは不満を感じた部分もありました。
そこでその中の数少ないChromeのセッションの中から、私が興味深く感じたクロスデバイス開発にはこの先欠かせなくなると思われる Chrome DevToolsの新機能についてレポートします。

このセッションを行ったPaul Bakaus氏（以下、ポール氏）は、かつてjQuery UIやAvesゲームエンジンを開発したことでも知られています。一時期日本に在住していたこともあるので、この記事を読んでいる皆さんには既になじみのある方かもしれません。現在はGoogle Chromeチームの一員であるポール氏。
今回この”Developing across Devices – DevTools in 2014″と題されたセッションでは、Chrome DevToolsの新機能と3つのワークフローについて、当日あったワールドカップのアメリカ対ドイツ（氏はドイツ人）戦のジョークをを交えつつ、とても面白く説明してくれました。

コンテントは水のごとし

「今の時代、モバイルWebを制する者がWebを制する！」と断言するポール氏。「Webコンテントは水のようにフローし（流れ）、どんなフォームファクター上でもフロー（描写）せねばならない」と、そのためのワークフローで重要な「Design」「Develop」「Iterate」の3つを挙げました。

Design（デザイン）は、はじめの重要な一歩。複数のフォームファクターを考えながらデザインをせねばなりません。

私たちディベロッパーは、マルチデバイス開発のためにブラウザのウィンドウの大きさを変えたりながらも、レスポンシブなWebを作り上げるのに大変な労力を費やしています。

この労力を軽減するためにChromeチームが開発し、そしてこの日初めて発表されたのがDevToolsのDevice Mode。現在 Chrome Canary(v38)のみに実装されているこのデバイスモードには、Nexus 5やSamsung Galaxyシリーズなどに多く使われているデバイスのプリセットが付属されます。そのため、各種のスクリーン解像度や高DPIスクリーンなどのエミュレーションが、今までよりも断然楽に行われるようになります。

デバイスモード

実際にこのデバイスモードを使ってみましょう。
まず、インスペクターウィンドウを開き、デバイスアイコンをクリックします。するとWebページの表示がデバイスモードに切り替わります。ここでは表示の幅を自由に変えられるほか、プリセットからデバイスを選択して、自動的にその解像度に合わせたサイズにすることもできます。オリエンテーションの変更も簡単に行えます。

そしてそのレスポンシブなデザインを実装する、フローその2はDevelop。

実際のデモで私たちオーディエンスをあっと言わせた、このMedia-queriesツールを使えば、メディアクエリのワークフローも今までよりさらに効果的に行えそうです。Device Modeの左端のMedia-queriesボタンをクリックすると、使用されているメディアクエリがルーラー上に表示され、さらにそれらを右クリックするとドロップダウンメニューにこのソースコードのパスが表示されます。これを選択するとSourceパネルにコードが表示されます。

そしてさらに新しい機能のWorkspaceを使えば、ここで変更されたメディアクエリをローカルのファイルシステムに直接反映させることもできます。

その他のエミュレーション機能として、タッチイベント、アクセラメーターなどのセンサーなどもエミュレーションすることができます。

ネットワーク環境のエミュレーション

一言でWifiコネクションといっても、会社のWifiのように快適だったり、カンファレンスのWifiのように人が多すぎて全く役に立たなかったりもすることもあります。例えば同じ高速道路でも、ドイツの速度無制限のアウトバーンとアメリカの制限速度55マイルのハイウェイを走るのとでは体感が全然違う、とポール氏は面白おかしく述べています。

そのような遅い回線コネクションをエミュレートすることは、特にモバイル開発では欠かせないものです。そこで DevToolsの新機能のコネクティビティエミュレータでは、3G回線での接続やオフライン状態といった様々な通信環境をエミュレートすることができます。例えば、モバイルのEDGE回線で開発中のWebがどうレンダリングされるか、そしてそのレンダリングがいかにユーザーをイライラさせるものかを、目で知ることができるのです。そういったユーザー・エンクペリエンスをテストするのは非常に大事なのです。

スクリーンキャストでリモートデバッグ

ワークフローの3つ目はIterate。エミュレーターは便利ではあるけれど、やはり実際のデバイスでテストしてみないことには分からない事実はいくつかあります。このプロセスで重要なのはこの3つ。

• パフォーマンス・プロファイリング
• 各デバイスに特化したバグや欠陥
• コンテクスト（外観と操作感）

このテストを快適に行うために、DevToolsのリモートデバッグを使いましょう。

その前に、まずChrome Canaryを最新バージョン（7月22日以降のビルド、38.0.2101.0もしくはそれより新しいもの）にアップデートしてください。それからchrome://flags/#enable-devtools-experimentsを”enable”にします。そして、DevToolsのSettings（ギアアイコンをクリック）> Experimentsからこの機能をオンにします。

AndroidデバイスのUSB Debugモードもオンにします。

そのデバイスをコンピューターにUSBでつなぐと、デバイスモードアイコンとは別にもう一つ小さなデバイスに「1」の数字がついたアイコンが表示されます。この数字はつながれているデバイスの数を示します。このアイコンをクリックすると、さらにデバイスパネルが下にあらわれます。

さらに、このパネルでTry Hereと表示されたボタンをクリックすると、実際のデバイス上のChromeの画面がChrome上にスクリーンキャストされるのです。デバイスで操作してみてください。動きがデスクトップブラウザのDevTools上に反映されるのがわかると思います。その逆も可能です。

これらのデバイス上での描写やレイヤーなどがDevTools上で可視化され、今までデスクトップで使っていたおなじみの機能をデバイスでも同じように使ってプロファイリングやデバッグすることが可能になります。

例えばこの3Dレンダリング。Layersパネルでレンダリングがレイヤーごとに可視化され、各レイヤーの様子も、レンダーオブジェクトをドラッグしながら360度各方向から見ることができます。さらにモバイルにありがちな描写の問題も、現在開発段階の新機能ペイントプロファイラを使ってピンポイントでどの描写に時間がかかっているとか、border-radius部分が極端に遅いなどとプロファイリングすることができます。

既存のProfilesパネルでavaScriptのCPUプロファイルを行ったり、Timelineパネルでグラフ化された描写速度を観察したりすることも、これまで通りモバイル上でも行えます。さらに、これらを同時にTimelineパネルで使えるようにするなど実験的に新機能も追加されるようです。これで視覚的にもさらに使い勝手のよいものになりそうです。

まとめ

これらのワークフローと、デバイスモードの機能のまとめを箇条書きにしてみます。

Design = Responsive Layouts 機能

• メディアクエリ・ビジュアルツール
• メディアクエリ編集ツール
• スタイル・フィルタリングツール
• インライン・エミュレーション

Develop = Rich Emulation 機能

• デバイス・プリセット
• ビューポート・エミュレーション
• センサー・エミュレーション
• ネットワーク・スロットリング

Iterate = Remote Debugging 機能

• プラグアンドプレイ
• パワーアップした既存の機能
• スクリーンキャスト
• ポートフォワード

最後に。この記事を書くにあたって私からの質問やバグについて答えてくれた、よき友人でもあるポール氏に感謝！ドイツのワールドカップ優勝おめでとう。

こんにちは、川田です。Googleはここ最近、デスクトップ向けWebに対して、ほとんどの関心を失っているように見えます。HTML5ブームも過ぎて、やることがなくなってしまったのでしょうか？……いえいえ、そうでもありません。昨今の待ったなしで進む技術革新の中で、彼らは「ある問題」と戦っているようです。

Webは「モバイル」中心の時代へ移っていく

Google Inc. First Quarter 2014 Results

すでにご存知の方も多いと思いますが、GoogleのビジネスモデルはWebに強く依存しています。2014年1Qの決算で、Googleは全売上の約68%が自社のWeb系サービスの広告収入であり、約22%はAdsenseなどの他のWebサイト向けの広告であると報告しました。Webに依存したビジネスが実に9割を占め、1日に約120億円の収入をWebから得ています。もっと簡単に言えば、Webだけで、タイの国民全員の給料分ぐらい稼いじゃってます。当然、Webの進化をやめてしまうなんてことは、考えにくいでしょう。

彼らにとって、利用者がどこからWebにアクセスするのかは、とても重要な情報となります。むしろ、Googleに限らず、Webでサービスを提供している全ての人にとっても重要なことでしょう。人々は普段、どんなコンピュータを使っているのか？どのようなデバイスからインターネットにアクセスするのか？そのことが、私たちのビジネスにとって大きな意味を持ちます。

そしてここ最近、Googlerがいろいろな発表の場でよく口にしているのが「モバイル」というキーワードです。これから先、Webの利用者はモバイルからやってくると、Googleは考えているようです。そのことを証明するかのように、現場の開発者からマーケティング・経営者まで一丸となって、これからやって来るモバイルの時代に向けた取り組みをアピールしています。

“AndroidとChrome、2つの巨大なオープンプラットフォームについて。スマートフォンは2013年4Qに、3.15億台の出荷があった。Androidは毎年利用者が倍増しており、現在は10億ものアクティブユーザがいる。将来的にはAndroidを、50億人にリーチしたいと考えている。” —— Google 経営者 Sundar Pichai (Google I/O 2014 – 2014.06.25)

“2014年1月に、ChromeのレンダリングエンジンであるBlinkをどう変えていこうかという話し合いをした。結果としては『モバイルが大事』ということになった。デスクトップよりもモバイルの方が売れているし使われる。しかし開発者の立場から見ると、残念ながらWebよりネイティブの方が多いという状況だ。我々はHTML5の問題点をヒアリングし、改善を進めている。” —— Google Chrome開発者 及川卓也 (HTML5 Night – 2014.06.14)

“アメリカの成人の34%にとって、主要のインターネットアクセスはスマートフォンだ。モバイルのトラフィックは増加しており、来年にも過半数のユーザがモバイルでインターネットを利用することになる。” —— Google Webコンテンツ開発者 Paul Lewis (Google I/O 2014 – 2014.06.26)

モバイルであることが前提の、Webとパフォーマンス

モバイルは、Web開発者/制作者にとっては厄介な存在です。動作環境が増えるのですから、デザインにコーディング、動作テストと、やらなくてはいけない作業も増えてしまいます。Googleは、その手間をできる限り省き、コンテンツ制作に専念できるようにしようと考えています。その成果の一つが、「Material Design(マテリアル・デザイン)」です。

UXの向上を図る上で、デザインは重要です。ただ、デザインだけではどうにもなりません。「パフォーマンス」も欠かすことのできない重要な要素なのです。Google I/Oでは、多くのエンジニアが「Polymer」「Material Design」「Android」など、宝物のような名前がついたキーワードに目を奪われました。実際にメディアでも、これらのキーワードが大きく取り上げられています。しかし、冷静に見るとそれなりの数の「パフォーマンス」をテーマとしたセッションが開かれています。パフォーマンス改善はすごく地味だけど、すごく重要な取り組みと彼らは認識しているのです。

Googleでは「PageSpeed Insights」と呼ばれるサービスを提供しています。イベントに参加していると、割と頻繁に目に入りました。Paul Lewis氏のセッション「Mobile Web performance auditing」では、その活用方法についてかなり具体的なアイデアと共に紹介しています。その内容を見てみましょう。

「PageSpeed Insights」とは、Webに公開しているページのURLを与えると、そのページの問題点、改善方法を提案してくれるGoogleのサービスです。競合するものとして、マイクロソフトの「modern.IE site scan」が挙げられますが、こちらはWebコンテンツのポータビリティを評価する方向に力を入れています。パフォーマンス改善という観点では、Google側の方がより尖っているという印象です。タブが「Mobile」が最初になっている点からも、彼らの作るツールがモバイルファーストの思考で動いているというのを感じとれます。

さっそく、私がはてなで運営しているブログをPageSpeed Insightsで評価してみたところ、Mobile-60点/Desktop-28点/UX-99点という結果でした。Paul Lewis氏いわく、それでは全然ダメとのこと。PageSpeed Insightsでのスコアは、大体目安として、Mobile-85点以上/Desktop-90点以上/UX-100点が望ましいそうです。いくつか日本のブログサービスでテストしてみたのですが、この条件が満足できているのを見つけることができませんでした。それどころか、Google自身が提供しているサービス「Blog Spot」ですら、この条件を満足できていません。そこまで頑張らなきゃいけないのかと、その必要性に疑いの目を持ってしまいます。

ところが、Paul Lewis氏いわく、200ミリ秒の遅延が0.3%の機会損失に繋がると。パフォーマンスの改善が、そのまま収益に結びつくのだと強く主張しています。Webは速ければ速いほど、価値を発揮するのです。もちろん、それを実現するにはそれなりにコンピュータ科学の知識を必要とするわけですが、私たちエンジニアによる純粋な技術による改善で、利用者の増加に貢献できることが残されているというのは、大変喜ばしいことでしょう。

パフォーマンスの問題について、Paul Lewis氏は「Page Speed」と「Runtime」の2つの観点から、その対策方法について紹介がありました。この2つを軸に、他のGoogle I/Oのセッションの内容も交えながらその考え方について見つめてみましょう。

Page Speedはどのように改善するのか？

Page Speedの改善とは何か？単純に言えば「Webページの表示を3秒以下に抑えよう」ということです。そのための方法として、Paul Lewis氏は以下の方法を提案しています。

1. リソースを最適化せよ(Optimize resources.)

Webページを構成するデータのうち、平均63%が画像ファイルです。最適化が必要となります。画像ファイルの圧縮を改善すると、データ量は大きく削減されます。CSS/JavaScriptについても、不要なスペースなどを削って圧縮(Minify)するとよいでしょう。

(補足：のちに説明がありますが、これらはプリプロセッサーの活用を習慣付けるとよいでしょう。人間の手でやっていてはキリがないので、徹底的に自動化させてしまうことです。)

2. リクエスト数を減らせ(Reduce the number of requests.)

リクエストはWebページの表示をブロックさせることがあります。リクエスト数が減るとそれだけ表示が速くなことを意味します。

(補足：SPDYやHTTP2.0が関わってくると、リクエスト数だけでなく、コネクション数も重要になってきたりしますね。いずれにせよ、少ないことはよいことです)

3. リダイレクトをやめろ(Avoid redirects.)

リダイレクトにはDNSの名前解決、TCPコネクションの接続など、Webページの表示までに要する時間が長くなります。パフォーマンスを意識するなら、リダイレクトさせてはいけません。

(補足：モバイルの場合、よくあるのは「m.〜〜」というURLにリダイレクトされるケースです。当然ですが、その処理を行うためにWebページ読み込みのパフォーマンスは劣化することになります。日本の場合は、モバイル網のDNSサーバのパフォーマンスが問題となることも少なくありません)

4. レンダリングの順序に優先度をつけろ(Prioritize for the critical rendering path.)

Webページ全てを読み込んだ時間よりも、見えている領域の読み込み完了(Visually Complete)に、利用者は関心を示します。そこに優先度を高く持っていくべきです。

(※補足：実際に、W3CのWeb-perf WGでも、Resource Prioritiesという仕様の検討が進められていますね。jQueryだと、LazyLoadプラグインがあり、画像ファイルの読み込み順序をコントロールすることができます)

一連の作業は、GruntやGulpが助けてくれます。利用してみるとよいでしょう。

Runtimeはどのように改善するのか？

Runtimeの改善とは何か？単純に言えば「Webページを60FPSで動かそう」ということです。一般的なディスプレイ(スクリーン)は約1/60秒周期で内容が更新されるため、アニメーションなどの処理はその特性に合わせていくことで、滑らかな動きを実現することができます。そのための方法として、Paul Lewis氏、Paul Irish氏は以下の方法を提案しています。

1. 変形や透過によるアニメーションは制限しろ(Restrict animations to transforms and opacity.)

処理コストの高い描画計算処理は控えるべきです。DOMの形状が変わるとLayout処理のコストは増大するし、透過処理などはPaint処理をコスト増大させます。このような「Expensive Animations」は、約1/60秒以下での処理に収まらないことがあり、注意する必要があります。

2. requestAnimationFrameを使え(Use requestAnimationFrame.)

画面のリフレッシュレートに合わせて、アニメーション処理は実行させるようにしましょう。例えば、setIntervalなどを利用し、16ms周期でコールバックさせ擬似的にリフレッシュレートを合わせようとすると、タイミングがズレて無駄が起きます。画面のリフレッシュレートに合わせるには、requestAnimationFrameと呼ばれるAPIを利用する必要があります。

3. レイアウトの値を読み込んでから書き出せ(Read layout values, then write.)

レイアウト(DOM)の値は変数のように扱ってはいけません。横幅などの取得が必要であれば、最初に取り出してキャッシュしておきましょう。読→書→読→書を繰り返すと、無駄なLayout処理が何度も発生するという「Layout Thrashing」という現象が起きます。読→読→書→書が理想です。

4. メモリ効率の高いJavaScriptを(Write fast, memory-efficiant Javascript.)

メモリを消費するようなJavaScriptの記述方法は、Garbage Collection処理が発生し、1/60秒以内での処理が完結しなくなることがあります。JavaScriptの書き方に、工夫が必要です。

モバイルChromeの解析は、「chrome://inspect/」でできます。お試し下さい。

難しくなってきている、なんて思いませんか？

これまではデスクトップPCが一つあればなんとかなっていたWeb開発も、作るための環境と動かすための環境が分離されて、どんどん複雑になってきているなぁという感触を得ています。プレゼンの時も、わざわざカメラを切り替えてモバイルのスクリーンを表示したりなんかしてて「エレガントさに欠るなぁ」「面倒くさいことやってるなぁ」なんて思ったりもしました。もっと言えば、デモしている姿を見てて「モバイル、めちゃくちゃ使いにくそうに扱ってますよね！」「本当はPCでやりたいとか思っていませんか？」なんてことも、率直な印象として感じました。

こういう不満を感じられることは、本当の本当に幸せに思えたりもします。Googleが悪いとかAppleが悪いとかMicrosoftが悪いとかじゃなく、IT業界全体として、まだまだ発展途上にいると感じさせられるのです。これからもっとよくしようと、動き出せるきっかけがいくらでもあるように思えるのです。もっともっと、進化しますよ！

みなさんはどう思いますか？私はWebの未来に、夢を見過ぎでしょうか？

2014年6月25日～26日、サンフランシスコのモスコーニセンターでGoogle I/O 2014が開催されました。Google I/Oは2008年からGoogleが年に一度開催しているイベントで、Googleの新規デバイスやソフトウェアの発表、Webやモバイルについての技術的な講演が行われ、毎回約5000~6000名のデベロッパーやデザイナーが参加します。

今年は2012年,2013年の3日間より一日短い日程での開催となりましたが、基調講演や小さなブースで行われるBox Talkを含めて200を越えるセッションが行われました。

本レポートではイベント前日から最終日まで、Google I/Oの様子＋αをかいつまんでお届けしたいと思います。

いざ会場へ

Google I/Oでは開催の前日より、参加証をもらうためのチェックインを会場で行うことができます。前日の午前中にサンフランシスコ入りした私も、ほかの日本人の方々と一緒に会場まで行ってきました。

とりあえず腹ごしらえ、ということで会場目の前のハンバーガー屋さんで遅めのお昼ご飯。同じお店にBidelmanを発見し、Google I/Oに来たことを実感します。

昼食後、会場へ向かいました。 14時からチェックイン開始ですが、すでに長蛇の列ができています。 イベント当日でもチェックインは可能ですが、基調講演やセッションなどの列にすぐに並べなくなってしまうため、前日に登録を行う人が多いようです。

20分ほどかかり、ようやく私の番となりました。ここではPhoto ID(パスポートなどの写真付きの証明書)が必要となります。

チェックインではGoogle I/O参加証のほかに、ボトル、Tシャツ、イベント初日の夜に行われるパーティ参加証を受け取りました。これで明日からこの会場に入場することができます。

サンフランシスコ観光

夜はI/O参加者の日本人の方々と晩ご飯を食べるため、ケーブルカーでフィッシャーマンズワーフに向かいました。

この時期のサンフランシスコは気温は15度程度、東京の3月くらいの寒さです。風が強いため、気温以上に寒く感じます。

サンフランシスコは海に面しているため、魚介類が豊富で美味しいです。くり抜いたパンを器にしたクラムチャウダーは、フィッシャーマンズワーフの名物になっています。

サンフランシスコの夜は遅くまで明るく、21時頃になりようやく暗くなってきます。奥に見えるのはアルカトラズ島です。

初日は明日からのイベントに備えて早めに寝ました。

Google I/O開始！

Google I/Oの初日の最初に行われる基調講演は、例年いくつもの新規デバイスやソフトウェアなどが発表されるイベントの中で最も注目度の高いセッションとなっています。少しでも良い席で聴講しようと多くの参加者が開始数時間前から並ぶため、私たちが2時間前に着いたときには既に長い列ができていました。

列を少し抜けて、中の朝食会場を覗きに行きます。

外とうってかわって、中はそれほど混雑していません。

ジュースやコーヒー、マフィンなどが置かれていました。

暖を取るためコーヒーを手に、また列に戻りました。朝ご飯はお預けです。

しかし、多くの参加者が外の列で待機することはGoogle側もよく分かっているようで、ワゴンでドーナツが配布されました。甘い！

8時半を廻り、ようやく列が動き出しました。

上へ上へ。

なんとか会場の真ん中辺りの席をゲット！

ステージには、なにやらピ○ゴラ○イッチのようなギミックが置かれています。

9時過ぎ、ついに基調講演開始です！

HTML5Expers.jpでは基調講演のライブレポートを行っていました。講演の内容については、 こちらの記事をご覧ください。

2時間半を超える今回の基調講演は、Material Design、Android L、スマートウォッチ、Android Auto、Android TV、そしてCardboardなど、盛りだくさんの内容でした！

基調講演のラストは『お土産』の発表。Google I/Oでは参加者全員に新規デバイスなどが配布されるのが恒例で、例年注目の的となっています。2012年はGalaxyNexusやNexus7、2013年はChromebook Pixelなどが配布されました。

今年はさっき発表された「SUMSUNG Gear Live」「LG G Watch」のどちらかのスマートウォッチをもらえることに！さらに、Google I/Oでは受け取れませんが、夏に一般発売予定のMotorolaの「Moto 360」ももらえるみたいです！

会場は大歓声に包まれました。

セッションや会場の様子など

基調講演後の時間は平行して10以上のセッションが行われるので、その中から好きなセッションを聞きに行きます。また、ブース展示も面白い物が多く、それらを見て回ったり、電源タップが完備されたソファー席で休んだりもできます。

セッション

Google I/O 2014ではAndroid, Polymer, Material Design, Google Play, Google Cloud Platform, Google Castなどなど、さまざまなセッションが行われていました。

各セッションは2~300名は入る大きな会場で行われます。ちなみにどの会場も電源タップの周りの席からすぐに埋まるとのこと。

セッションの中には参加者だけにデバイス等を配布するものもあり、そういったセッションは噂を聞きつけた人で大混雑します。 今回私もとあるセッションで『何か』がもらえるという噂を入手。その部屋に行ってみました。

部屋の前には長い長い列ができています。

ずいぶん待った後で無事入場！

そう、基調講演で発表があったばかりの、Android TVのセッションです！

Android TVのシステムやUIについての講演の最後で、参加者だけにAndroid TV用のアプリ開発キット「ADT-1」を配布するとの発表が！ 無事バウチャーを入手することができました。

聞きたいセッションが同じ時間に被ってしまっても、ほとんどのセッションはYouTubeで公開されるため、後から見ることができます。Google I/O 2014のビデオはこちらで公開されています。

Box Talk

Box Talkは小さなブースで行われるセッションで、Android, Chrome, Cloud, Dartなどのジャンルごとに分かれています。

席は数人分しか用意されていませんが、人気のセッションは2~30名は見に来るので、早めに行かないと人だかりで見えないということも。 講演者と聴講者の距離がとても近いので、質問やディスカッションが盛んに行われていました。

展示

会場の2,3階では、基調講演で発表があったデバイスや協賛企業の展示が行われています。

Android Wear。

Chromecastを使ったクイズゲームの展示。 富士山の高さは何キアヌリーブス？

答えは2030.11キアヌリーブスだそうな。

Android Auto。実際の車に乗って操作すると、前方のスクリーンが流れて運転しているように見えます。

LEGOブロック。

コミュニティラウンジ

コミュニティラウンジはソファーやテーブルなどが置かれていて、各国のGoogleコミュニティが自由に集まり交流できるスペースです。

日本、ヨーロッパ、アフリカ、アメリカなど各国のコミュニティのミートアップの他に、women meetupや、first-timers meetup、Robotics meetupなどが行われていました。

休憩スペース

会場では多くの参加者がソファーや床でPCを開いてくつろいでいました。ソファーには電源タップも用意されています。

新しいツールを試したり、手に入れたデバイスはすぐ触ってみたくなるので、こういうスペースはとてもありがたいですね。ソファー席の近くにはお菓子ブースもあり、腰を落ち着けるにはもってこいでした。

撮影

会場のいたるところでテレビ局と思われる撮影が行われていました。

貸し切りアフターパーティ

Google I/O初日の夜は、参加者だけのパーティが開かれました。広い公園を貸し切り、中のお店や出店は全て無料！おまけにバンドの生演奏まで行われました。

公園のあちこちに出店が出ています。

フィッシャーマンズワーフで食べそびれたクラムチャウダーも、ここで食べることができました。

たくさんの出店や演奏、催し物で会場は大変賑やかでした。

初日の夜はこうしてふけていきました。

二日目、お土産入手

2日目は朝からお土産を受け取ることができます。

「SAMSUNG Gear Live」か「LG G Watch」のどちらかの時計を選ばなければなりませんが、私の周りでは「LG G Watch」の方に若干軍配が上がっていました。しかし、脈拍を計測できるのは「Gear Live」だけ！少し悩んだ末に、「Gear Live」を受け取りました。

ついでにAndroid TV用の開発キット、「ADT-1」もゲット。

Nippon meetup

お昼頃に「Nippon meetup」が行われました。コミュニティラウンジに数十名の日本人が集まり、集合写真を撮影します。

こんなに日本人が！これでも全員ではなく、Google I/Oには200人ほどの日本人が参加していたとか。

このとき撮った写真がこちら。

セッション・会場の様子

午前中、なにやら人だかりができているエリアがありました。

近づいてみると、人々が見ているのはテレビ！ワールドカップの中継でした。

ちょうどアメリカ対ドイツ戦が行われていたようです。

さて、午後は面白いセッションがあると聞いて、「Making music mobile with the Web」が行われている部屋に参加しました。

会場全員で歌っています！ 歌っているのは「Theme for I/O」。そのときの録音がこちら。

このセッションではWebRTCやWeb Audioなどを使用して、演奏や歌のレコーディングやミックスを行うデモが中心でした。詳しくは後日公開される河合さんの記事をご覧ください。

Google I/O終了

午後5時。2014年のGoogle I/Oも、そろそろ終わりです。

2日間Google I/Oを満喫しましたが、思っていた通り、刺激や楽しさがいっぱい詰まったイベントでした。毎年セッションの様子はだいたいYouTubeで公開されていますが、いち早く新しいデバイスやソフトウェアに触れたり、同じ会場の参加者と盛り上がったり、開発者に直接質問をしたりなど、参加して初めて味わえることばかりでした。

Google I/O 2014のセッションの動画はこちらから公開されています。

来年は是非みなさんと現地でお会いできるといいですね！

それでは！

（写真提供：矢倉眞隆、河合良哉、仲裕介）

まもなくキーノートがはじまります！HTML5 Experts.jpでは、現地で取材中のエキスパート・編集部と連携し、ライブレポート形式にて本ページにて、最新情報をお届けいたします！

まずは、キーノート会場からご紹介です。

カウントダウンがはじまってます！

ピタゴラスイッチのような演出、そしてFlappy Birdの映像も流れてます。

Michael Gorman氏のスピーチではじまりました。 前回のGoogleIOはグローバルなイベントであり、547箇所で視聴している人がいます。早速、グローバルなスマフォの出荷数を見ます。全四半期では３億台以上が出荷されています。Androidを使っているユーザは毎年数が倍増しており、今年は１０億人以上のユーザが利用しています。

Androidユーザは9300万人が自分撮りをしています。我々の推定では、1000億会場もAndroidをチェックしています。

タブレットの話もすると、数は非常に伸びています。Androidのタブレットは世界市場の62%を占めています。これはkindleを含んでいません。また、利用状況を見ると、一年前はyoutubeを見る人は28%がyoutubeを視聴していましたが今は42%です。今年だけで、アプリケーションのインストールは200%以上増えています。また、10億人以上のAndroidユーザがいますが、50億人以上のユーザにリーチしたいと考えています。

本日はAndroidとChromeについてお話いたします。まずはAndroid “L” Developer Previewについてです。（編集部補足：Kit Katの次ですね。まだ正式名称は内緒のようで、単なるLとして紹介されてます。）

デザインは今日非常に重要です。Lではマテリアルデザイン（材料設計）を取り入れています。マテリアルデザインは、直感的に人々が理解できるようなデザインです。例えば、 影を作ることにより、どのように動くかについて意味をもたらすようなものです。また、Lのガイドラインにより、開発者は1つのデザインで、様々なデバイスのデザインを最適化できます。

（編集部補足：マテリアルデザインについてはこちらの動画をご覧ください。）

さらにLでは、Android開発者はシームレスなアニメーションを作ることができます。

昨年はPolymerを発表しましたが、マテリアルデザインの機能をPolymerを介して提供します。マテリアルデザインではスムースなアニメーションを作れます。具体的に、Lのユーザエクスペリエンスからお話します。Lには洗練されたノーティフィケーションもあります。Lの場合には即時的にロック画面から確認ができます。

Lではノーティフィケーションを優先度をつけて整理できます。さらにノーティフィケーションを、一回のスワイプで外すこともできます。またheads upというノーティフィケーション機能を導入しています。これは緊急度の高いものを通知する機能です。また新しいコンセプトとして、パーソナルアンロックという機能を導入します。

次はパフォーマンスです。

Androidのバーチャルマシンについて様々な意見を頂いてきました。今日、我々はLの新たな実行環境として、ARTを提供します。ARTは新たなガーベジコレクタも提供します。ARTは64bitアーキテクチャに対応しています。

また、Lでは、GPU性能も向上しています。（Lを用いたムービーが再生される）水の反射や煙のエフェクト、秋のリリースでPCレベルのものがポケットに収まるようになります。

最後にバッテリです。プロジェクトVoltaをはじめました。これにより持続時間を向上させています。バッテリ性能を確かめるには、まずは計測をしないといけないので、Battery histrianを作りました。これにより当時の状況を見ることができるようになりました。

そしてジョブスケジューリングAPIも新しくなっており、消費電力も効率化されています。

LではジョブスケジューリングAPIで、バッテリ接続していても自動的にバッテリを節約できます。

明日の午前中には、LのプレビューSDKを提供します。Nexus7で今日にでもはじめられます。5000の新たなAPIが提供され、パフォーマンスも向上しています。

これまでのAndroidのイノベーションを振り返ると、オープンプラットフォームで様々な技術革新を提供してきました

セキュリティアップデートもGooglePlayを介して利用できます。ファクトリーリセットプロテクションを使い、さらに安全に活用できます。 プライバシーもLの側面にあります。ユーザは個人情報の保護を確実にできます。

ユーザはマルチスクリーンの世界を生きています。例えば、車にのってもネットへ接続しています。

シームレスな形式で、どのデバイスを使っていても同様なエクスペリエンスを提供します。その一つとして紹介するのは

androidWearです。 Android Wearでは例えば、センサによってコンテキストを認識、必要な情報を提供します。ユーザはこのデバイスを常に身につけていることによります。世界中の人はAndroid Phoneを毎日125回以上チェックしていますが、このウェアラブルなウォッチを使えば、すぐに確認できます。まずはLGウォッチで紹介しましょう。

これにより、ウェアラブルな形で、流れるようなアニメーションで、フライト情報のような様々な情報を確認できます。

UIのモデルですが、Androidがどのように機能するか？まずは天気や通勤時間を確認できます。また、ウォッチから簡単にスマートフォンと連携できます。簡単にメモもとれます。とったメモはすぐにスマートフォンに同期されるのです。

例えば電話がかかってきた場合は、ウォッチに情報が表示されます。ウォッチを上下にスワイプすることによって、電話を拒否するようなこともできます。また下にスワイプダウンすれば、都合がよくなるまで割り込みを避けられます。

また、ウォッチで音楽もコントロールできますし、再生している最中のアルバム情報もチェックできます。また、その他の機能として、ジョギングの後の心拍数なども計測できます。AndroidWearSDKによって、開発者は様々なものを構築できます。色々なアプリケーションが何十億という通知を、自分の腕で確認できます。3月に開発者プレビューをリリースしています。

ユーザには、さらに良いエクスペリエンスを提供できるようになります。GmailやHangoutと統合できるようになります。eat24というアプリを紹介しましょう。

まずピザのオーダがウォッチからできます。

支払いもウォッチからできます。これだけで、ピザがあなたのもとに届きます。

ソーシャルレシピのような例もあります。レシピをウォッチで見ると、携帯にもすぐに同期されています。これは料理をしている間に身につけていてもOKです。防水処理されておりますので。タイマーもすぐできます。ウォッチさえあれば大丈夫。焼き過ぎなんてありえないです。

音声のアクションを色々とお見せしましたが、他のアクションにも応用可能です。Okay google, call me car　といえば、位置情報を確認して、車がついたらウォッチに通知してくれます。また目的地についたらウォッチに通知してくれるようなアプリも作れます。さて実際のウォッチですが、

今日の午後からLGウォッチをプレイストアで発注できます！またサムスンもAndroidwearファミリー人参加してもらいました！Samsung Gear Liveも午後から発注できます。また丸いUIのMoto3も夏から発売されます。(編集部補足：米国での発売情報です)

Android Wearはシームレスなデバイスすると述べました。次は車を考えてみましょう。

Open Automotive Allianceを発表し、Connected Carを現実にしたいと思います。

そこで、本日はandroid autoを発表します。android autoでは、Androidプラットフォームを自動車のために作りなおしました。運転中にも使えるようにしています。android autoはコンテキスト対応しており、的確な情報を必要なタイミングで必要な情報を出してくれます。また完全に音声対応されているので必要な情報を音声で使えます。

androidフォンを車に近づけると、android autoを車の画面にそれを表示させます。

そして車のコントロールするために、タッチスクリーンを使えます。しかし、アプリケーションはスマートフォンで動作していますよ。さらに、Google Play Musicの主な機能をコントロールできます。これを手を使わずにコントロールできます。

そうそう、皆様はGoogle Mapが好きですよね。android autoはもちろん対応していて音声が使えます。「ヤングミュージアムはいつからやっていますか？」と聞けば、「朝からやっています」ち答えてくれます。次に、「Navigate There」と言えば、ヤングミュージアムへのナビゲーションを開始します。また、その最中に届いたメッセージはheads upで通知でされます。このとき、マップの移動画面も出しながら、音声で返答できます。

android autoについてお話してきましたが、スマートフォンやタブレットと同じように開発できる、android auto SDKを今日発表します。

SDKがあれば音声を簡単に使えます。またメッセージングAPIもあります。これにより、Appをユーザへ提供しています。わずか数行のコードで車の中でも対応できます。

40の新しいpartnerがOpen Automotive Allianceに参加しています。

車をもっていない人もいますよね。そこで、次はTVです。TVは2006年からあまり進化していません。その結果スマートテレビは限定できでした。Androidtvを発表します！Androidtvでは音声入力を活用でき、バーチャルコントローラも使えます。例えば、生のTVが流れている上に、コンテンツをオーバレイできます。TVはコンピュータと違い、エンターテイメントのインターフェースがあります。

例えば、「2012年からオスカーを受賞した番組」と音声入力すると、一覧で表示できます。

リモートコントロールがない場合には、Android wear、ウォッチを使ってTVをコントロールできます。つまり、ウォッチをリモコンとして、TVをコントロールできます。

次はゲームの話です。これまでタブレット等でやっていたゲームを今度はTVで楽しめます。例えば、マルチプレイヤーゲームも楽しめます。

他にも、スマートフォンの映像を直接TVにキャストできます。ChromeCastの拡張のような形です。AndroidTVは複数のデバイスタイプ、つまりTV、セットトップボックス、ゲーム機にも対応しており、協業しています。

実際に、2014-2015年にSony、SharpがandroidTVを出します。最後ですが、ADT1というTV開発キットを提供します。これにより、今日から皆様も開発できます。

次はChromeCastを紹介します。ChromeCastは非常に販売が好調です。実はエレクトロニックデバイスとしては、Amazonで一番売上をあげているものです。このChromeCastははじまりにすぎません。この数ヶ月で6000人のデベロッパが登録しており、10000のアプリがGoogleCastReadyのアプリが生まれています。chromecast.com/appsからアクセスするとGooglecastのアプリケーションが簡単に使えます。

TVは使われていない時間が多いですが、それを活用しようと考えています。

例えば、フォトフレームのように使うこともできます。

次はChromebookの話です。我々な生活の中で重要なデバイスとして、まずはChromebookがありました。ユーザはこれを非常に楽しんでいます。

今、AmazonのレーティングでTop10のラップトップは、すべてChromebookです。

Chromebookに近づいてスマートフォンを持っていれば、chromebookに自動的にサインインできます。GoogleNowの通知も導入済みです。何かあれば、Chromebookでテキストメッセージも追加できます。

このようにChromebookは素晴らしいのですが、ここで我々が考えていたのは、AndroidアプリケーションをChromebookでも利用したいという点です。技術的には非常に難しいのですが、AndroidアプリケーションをChromebookで動かせるようにポーティングできています。

さて、次は法人（企業）の話もしましょう。企業では、個人携帯と会社携帯が別物でした。Lでは、両方のエクスペリエンスを統合して、使えるようになります。一つのデバイスで大丈夫になります。

データは完全に分離されており、セキュアな形になります。もうひとつ、よく要望される機能について紹介します。

Navie Office Editingも提供します。たとえば、皆様はEmailを使ってwordファイルを受信しますが、今まではそれをdocファイルに変換していましたが、これからはNativeな形式でofficeファイルとして使えるようになります。

次はGoogleDriveです。Google Drive for Workの機能を法人にも提供します。エンタープライズに対して、すべての機能を提供します。また、無制限のストレージを月10ドルで提供します。これからはAndroid、Chrome、Google Doc、Google Driveを統合的に使えます。

実際に、多くの企業・学校がすでに利用しています。

Googleの中で様々なインフラを作っています。ここでGoogleプラットフォームの話をしましょう。

Compute Engineを使っています。エクサバイトまで拡張するストレージも提供しておりますし、スケーラビリティも確保しています。

バックエンドを作るという意味においては、パフォーマンスがあり、簡単なツールが必要ですが、それはGoogleにしか無いと感がています。ここで4つの機能を紹介します。

一つのアプリケーションを使って説明します。codewalksは散歩の記録をするアプリです。散歩にいってコメントをシェアするアプリですが、これは情報をクラウドにデータを入れる必要があります。

デバッグのために、ブレークポイントを設定することもできます。

クラウドトレーシングという機能では、すべてのアプリケーションにおいて、どれだけ時間がかかったか、というのを表示してくれます。

最後はクラウドモニタリングです。これによりインフラのモニタリングをできます。例えば、どのようなサービスを利用しているかを確認できます。また数十のOpenSourceのサービスをモニタできます。例えば、こちらではRedisを確認しています。

いままで見てきたのは4つの機能であり、それぞれはCloud Save、Cloud Debugger、Cloud Trace、Cloud Monitoringができるようになりました。

次はデータに注目します。データといえば、もちろん分析が必要です。 その分析において、MapReduceが最適じゃない場合もあります。特にパイプラインを使う場合です。そこで、本日はCloud Dataflowを発表します。これによりデータのパイプラインを使えます。これにより、バッチでもリアルタイムでも分析結果を確認できます。

例えば、CloudDataflowでTwitterを分析してみます。これは、並列化された高速な分析が可能です。

ブラジルvsクロアチア戦の分析結果です。ポシティブネガティブな結果を表示しています。この例では、途中でレフリーについて物議を醸しているようです。

また話を技術的な部分に戻して、なぜMapReduceを使うのをやめたかというと、cloudパイプラインによってこれまで大変だったことが簡単にできるようになり、スピードも早くなるからです。我々自身の問題を解決できるようになったので、MapReduceを使うのをやめたのです。

次はGooglePlayについて話をしましょう。

GooglePlayで開発、配信、マネタイズについて話をします。

まず開発におけるテストです。テストは大変ですよね。appurifyはもっとも洗練されたテストです。appurifyにより、iOSでもAndroidでも活用できるテストが利用できます。また、特定の環境も擬似できます。

次にGoogleFitPlatformを紹介します。GoogleFitがない時代は、専用アプリを使う必要があり、その提供形式はサイロ型になっていました。GoogleFitでは統合した形で、包括的なアプリを活用できます。例えば、ユーザにはより良いレコメンデーションを提供します。具体的には、アディダスやナイキがGoogleFitのエコシステムに参加しています。このSDKはあと数週間で利用可能になります。

次は配信です。クロスプラットフォームのサービスとして、これまで、Google Play Gameを提供してきました。Google Play Gameも強化されます。

例えば、Game Profileにより、自分のアイデンティティをクラウドに保存でき、それをゲームで活用できます。

次はマネタイズです。よくある方法はキャリアにお金を払う方法です。実は今25ヶ国で利用できます。アプリケーションやゲームやムービを、携帯電話の請求書に載せて払えます。これによりユーザに請求を簡単にできます。

実際に前回のI/Oから50億ドルをユーザが支払っています。

次はお待ちかねのガジェットを見てみましょうか。（編集部補足：参加者へのお土産コーナーです）

カードボードや や を会場の皆様にはプレゼントいたします。

これでキーノートは終わりです。参加してくれてどうもありがとう！

Googleが主催する開発者イベントである Google I/O 2014 が、日本時間の6/26(木) 午前1時の基調講演を皮切りに始まります！HTML5 Experts.jpでは、現地で取材中のエキスパート・編集部と連携し、ライブレポート形式にて読者の皆様に最新情報をお届けいたします！

ライブレポートはこちらから！

1時よりキーノートがはじまりますが、まずはその前に会場画像をお届けいたします。

朝食会場です。

そして朝食画像です。