Google I/O 2012 Day 1

初日は美味しいけど高かったお肉を食べて、満腹感な状態でホテルに戻りました。さぁ、寝なければなりません。そう、「寝なくちゃ」と思えば思うほど、寝れません。不思議です。いや、不思議じゃありません。これが時差ボケってものなんです。

グダグダ何度も寝返りを打ちながら、おそらくちょっと寝て、でも起きちゃって、を繰り返していたと思います。そして、変な気分のまま、トイレに行き、戻ろうと思ってトイレの電気を消そうとした瞬間、

「パリン!」

という音が響き渡りました。一気に眠気は吹っ飛びます。そう、ガラスのコップを落として割ってしまったのです。

もー、勘弁してくれー!と100%自分が悪いのに、当たる場所もなく、仕方なく手を切らないように破片を集めてごみ箱に捨てます。そして、タオルで細かな破片を拭き取って、タオルごとごみ箱へ。さすがに割ったままHouse keeperに処理させるのもなぁ、と思って、後片付けは自分でやりました。そうじゃないと気になって寝れなくなるっていう理由の方が大きかったんですけど。

この一件でちょっと疲れたのか、その後すぐに寝ることができて、気がついたら朝でした。

入場パス、Macbook Air、各種スマートフォン、財布、パスポートを準備し、着替えて、いざ会場へ。昨年と全く同じで、サンフランシスコの朝はちょっとひんやりですが、とても気持ちいいです。

会場の前では、ドロイド君がかなり激しく踊っていました。「初日のKeynoteはAndroidからですよ!」とネタバレしちゃってる感じです。

初日のKeynoteの開始時間は9時30分から。僕が会場に着いたのは確か8時過ぎでした。1時間30分も前なのに、既に2F にあがるエスカレータの前には、行列ができはじめていました。昨年、一昨年はこんなことなかった。今年は総じてすごーく長い行列が毎日できていました。なんで急にモラルがあがったのか、よくわかりません。きっと、誰か並び始めちゃうと、みんなそれに従っちゃうんでしょうね。昨日の「日陰行列事件」が表しているように。

Google I/Oでは、毎朝朝食が準備されています。数多くの丸テーブルが置いてあって、参加者がいろんな話をしながら食べています。いくつかのパンと、フレークもあったかな。あとバナナなどのフルーツ。パンは基本超甘ったるく、でも今年はクロワッサン(ノーマルとチョコの2種類)があったので、僕的には幸せでした。

昨年まではテーブルに人が座れず、床に座って朝食を食べている人まで出ていましたが、今年はテーブルが満席にはなりませんでした。なぜなら、みんな並んでいたからです。すごく広い朝食の会場も、気がつくと行列が1周してしまっています。下の写真は、食堂の入り口(左側)から、ぐるっと行列が一周(右側)した様子の写真です。おそらく食堂になってる部屋は基調講演の半分くらいは広さがあるので、3000人以上は軽く入ります。

そんな中、日本人は余裕の貫禄を見せつけます。並びもせず、朝食をいただきます。

お、行列が動き出した。どうやら開場したっぽいので、日本人も動き始めます。食堂は1Fで、基調講演会場は3Fです。なので、エスカレータと階段で参加者は上に向かわなければなりません。しかし、その先には巨大な待ち行列が。。。

もちろん、気がつけば最後尾です。YouTubeの配信都合で、全員が会場に入る前に、Keynoteは始まってしまいました。格好いいカウントダウンは今年は見れませんでした。残念。ただ、ほんとにちょっとだけ席が空いている場所があり、ほぼ全員全く知らない外国人ばかりですので、遠慮せずに1席だけ空いていた場所に座って、落ち着いてKeynoteを見始めることができました。

Keynote day 1

Keynoteの様子は、他の多くのGoogle I/O参加者がレポートしていますのでそちらを是非ご覧頂きたいのですが、個人的にはKeynote day 1はAndroidのみだと思っていたので、Google+やProject Glassの話があったのはすごく意外でした。実はGoogle+の誕生日は、このGoogle I/O 2012 Keynote day 1と同じ日。もう1年経ったのですね。最初にVicはGoogle+の各種統計値を紹介し、その後モバイル端末の重要性の話に入っていきます。

最初はGoogle+のTablet向けAndroidアプリケーションのリリースが発表されました。Google+は、Webも今までそうだったのですが、写真を中心にかなりリッチなフィードの表示にこだわってUIデザインがされてきました。個人的には、文字を読むことが中心なTwitterやFacebookのフィードは、見ていて結構疲れます。Google+の視覚に訴えてくる表示は、とても好きです。Keynoteの中でも、Tablet版アプリの動画を流していましたが、独自にYouTubeに上げてみましたので、ご覧ください。

Google+ Tablet applicationよりも大きく取り上げられていた新しい機能が、Google+ Eventsです。

これは、Google CalendarとGoogle+との連携プロダクトであり、Google+を積極的にユーザに使ってもらうための仕掛けとして機能します。イベントを作成し、サークルをうまく使ってそのイベントに知人を招待します。これらがBeforeの話。そしてイベントの当日は、Google+アプリをパーティーモードにして、撮った写真はすぐにそのイベントのタイムラインにアップされていきます。これがDuring。イベントが終了した後は、想い出としてアップされた写真やコメントを見ながら、その当日の雰囲気を味わえます。これがAfter。つまり、Google+ Eventsは、ユーザの想い出を一箇所に効率良く集約することを助けてくれます。また、+1やコメントの量が多い写真がHighlightとしてまとめられますので、更に想い出話に花を添えることになります。

Keynoteは、その後Sergayが登場して、スカイダイビングへと流れていきます。Keynote day 1の中で、個人的にはGoogle+関連の話は面白かったけど、他の多くの人にとっては、もしかしたら中休み的な印象だったかもしれません。もちろん、Project Glassとプレゼントの話でこのあと最高潮になるんですけどね。

ちなみに、僕はタバコはとうの昔にやめたのですが、たまたま知り合いと待ち合わせるためにテラスに出たら、KeynoteでGoogle Glassをデモしていたお姉さんがタバコを吸っていました。

「それには何が映ってるの?」と聞いたのですが、まだ開発中なので教えられない、とのこと。僕らも写真を撮られたのですが、その時に目線が上に動いたんですよねー。何かしらは表示されてそうなのですが、詳細は闇の中です。

Keynote day 1が終わり、セッションを聞きに行きます。昨年はソーシャル関連がほとんどなくて寂しい思いをしましたが(その分他の分野のセッションで楽しんだわけですが)、今年は「Google+」というトラックがあり、どのセッションに出るか迷う必要はなさそうです。しかし、今年は別の興味であるWeb Intentsも注目したいという目的があります。Web Intents絡みのセッションには、Google+から浮気して優先することに決めていました。

Google+ Platform Basics

記念すべき最初のセッションです。知り合いのGooglerから事前に「Google+ Platform Basicsを聞けば、今年のGoogle I/Oで話される内容が一通りわかると思うよ」と助言を得ていたので、外せないセッションです。

スピーカーは、Google+のDeveloper AdvocateであるAde Oshineyeと、Google+のEngineering managerのJulie Faragoの二人です。

まずはJulieからGoogle+ Stream(ポストされたものがどれだけ他のユーザにバイラルしたかを視覚的に見ることができる機能)、+1ボタンがGoogle SearchやGoogle Adsに採用されていること、の紹介から入りました。ソーシャルアノテーションがついた広告は、CTRが5〜10%増加したそうです。そして、+1 Button Recommendationsという新しい機能のリリースが発表されました。Julieにとっては、チームが夜遅くまで、あるいは週末まで働いてリリースした経緯があるらしく、かなり興奮気味にこの機能を紹介しています。

これは、+1ボタンが置かれたWebページと同じようなWebページをレコメンドする機能です。+1ボタン上でマウスカーソルを乗せると、自動的に表示されます。関連していて、ポピュラーであり、そして似たWebサイトをレコメンドする、という言い方をしていました。具体的なアルゴリズムまでは紹介はなかったですね。

Adeにバトンタッチした後は、Google+ Platformで何を狙っているのか、という大きな話が始まりました。Google+ Platformは以下の利益をもたらすもの、と定義されています。

  • あなたのサイトに訪問者をつなげることによって、トラフィックが増加する。

  • あなたのサイトの魅力を引き上げる。

  • あなたのサイトで(タグ)スニペットを制御することによってCTRを増加させる。

  • Google+上であなたのコンテンツが再シェアされる回数を増加させる。

これらの目的を達成するために、更に別の疑問に対するソリューションの紹介、という形態で、このセッションは進んでいきます。最初の質問は「あなたのコンテンツを表現するために、あなたはどのように(タグ)スニペットを制御するか?」です。これの回答として、最近GoogleではSchema.orgが採用され始めています。これは、HTML5で加わったHTML Microdataという仕様に基づく情報記述の種別と属性項目が規定されたものです(詳しくは こちら参照)。セッションでは、このSchema.orgを使ってWebページにメタ情報を記述することで、Google検索の結果の表示や+1ボタンが押された結果のフィードの内容などがリッチになり、上記の目的の達成に寄与することが説明されていました。また、Schema.orgの記述が正しいかを確認するために、 Rich Snippets testing toolの紹介もありました。 Snippet config toolなんてものもあります(これは知りませんでした)。

次の疑問は「あなたのサイトの訪問者にどのように情報発信とつながりを作っていくか?」です。この答えはもちろん、Google+ Pageです。そして「訪問者が簡単にGoogle+ Pageを発見しフォローするには?」という疑問に対しては、Google+ Pluginとして提供されているGoogle+ Badgeが使えます。訪問者はBadgeを使うことで、対象のページを簡単にフォローすることができます。次の疑問として「あなたのサイトへの訪問者は、あなたのコンテンツをどのように支持し推薦する?」です。これは簡単です。+1ボタンがまさにその用途に向けたプロダクトになります。+1ボタンは「これはいい!」とボタン押下者が思って押すボタンになりますが、そこまで「いい!」と思わなくても、単に他の人に共有したいだけの場合もあります。そのとき向けに、シェアボタンも提供されていることが説明されました。最後に「全ピクセルを制御し、何ぴとたりともLatencyを悪化させたくないんだ!」という人向けに、Shareボタンを単純な画像のリンクとして配置する方法が紹介されていました。実際に、Webページは複雑化が進んでいて、表示スピードの劣化は深刻な問題となります。このソリューションによって問題を解決できるサイト運営者は少なくないでしょう。

Q&Aで面白かったのは、Google+をエンタープライズ向けにどう考えているのか?という質問でした。回答としては、すでに3万人以上を抱えるGoogle社内でGoogle+は使われていて、多くの利益を生んでいるという事実があり、これはGoogle+がエンタープライズ向けにも使えるということだということでした。更に、数カ月前に企業向けにGoogle+を提供し、その結果導入企業は社員同士が部署を超えてつながり、Google+に追加した機能は、そのままエンタープライズ向けにも有効だった、という考えでした。

What’s Next for Chrome Extensions?

次に聞いたセッションは、Chrome拡張機能についてです。いくつかリリースしてたりするので、これからどうなるか興味があって聞いてみましたが、内容は期待していた「こんなAPIが出たよ!」という感じではなく、今までのChrome拡張機能が 抱えている問題点と、それを解決するための新しい機構の紹介を行ったセッションでした。

スピーカーは、Mike West。ChromeのDeveloper Advocateです。

あげられた問題は、以下です。

  • ちょっとしたことでも、Chrome拡張機能がユーザに要求するパーミッションが大きくなってしまっている。

  • Chrome拡張機能が要求するリソースが大きくなってきている。

  • Chrome拡張機能はセキュアであるが、実際にはバギーであり、(悪いことをする対象として)魅力的である。

これらに対応するために、Manifest version 2をChrome拡張機能はサポートする必要があります。

Chrome拡張機能の多くが、HTTPスクリプト(?)やインラインスクリプトを禁止するだけで、全弱性の94%を防ぐことができるという調査結果があり、そのためManifest version2においてはそのような制限が加えられています。セッションで紹介されたものとしては、

  • backgroundページについて、HTMLは必須ではなくなった。その代わり、パッケージ外部から任意のJavaScriptファイルを読み込むことができないので、scripts属性を使ってmanifestファイル内で明示的に「これを読み込む」と指定しなければならない。

  • Web Accessible Resourcesによって、明示的に指定されたリソース(画像やJavScriptファイルなど)以外は全てChrome拡張機能からは見えなくなる。

  • デフォルトのContent Security Policyは、script-src ‘self; object-src ‘self’ となる。つまり、Extension外部からのJavaScriptやFlash、インラインJavaScript、eval関数が使えない。ただし、Sandboxなどいくつかの回避策はある。

などがあげられました。Manifest version 1が完全に使えなくなるのは、2013年のQ3です。それまでには(実際にはもっと早い段階で)Manifest version 2に移行する必要があります。僕も早く移行に着手しなくちゃ。

次の問題解決のネタは、Chrome拡張機能が利用するリソースの増大についてです。多くのChrome拡張機能が常駐し、メモリを消費していきます。特に定期的に処理を繰り返し行いたい場合に、その消費量は大きくなります。これを回避するために、Event Pagesという機構が新たに追加されました。これはGoogle I/O 2012のちょっと前に公開されたものです。

Event Pagesにより、backgroundにライフサイクルを与えることができ、それに応じて生成されたり破棄されたりすることになります。また、chrome.alarmsにより、cron的なこともできるようになります。

あとは、keybindingの定義ができるようになったり、Chrome拡張機能からの通信をフックできるWeb Request API、Active Tab Permissionの話と続きました。Active Tab Permissionは、例えばGoogleが提供している辞書拡張機能では、ユーザが今まさに見ているページにContent scriptを埋め込む必要があり、その場でBrowser actionにより単語の定義を表示する、という状況を考えます。多くの拡張機能は、同じような動きをする機能を提供していることでしょう。これを行いたい場合、ユーザにWeb全体を許可してもらう必要が出てきますが、Active Tab Permissionという名前の通り、今まさに開いているタブに関して、テンポラリでそのページに許可を与えてContent scriptの埋め込みなどをBrowser actionなどで実行できるようになり、その結果パーミッション要求のベースレベルをかなり引き下げることに寄与できるということです。

Q&Aで面白かったのは、Androidなどではアプリがエラーを吐いた時などにそれを開発者が見れる仕組みがあるのですが、そういったエラーレポートをChrome拡張機能では利用できないのか?という質問でした。もちろん現在はChrome extension frameworkではそういった機構はなく、エラーが出た場合はそれをローカルに貯めておいて、あとで開発者のWebサイトに送れば?Open Webなんだし、的な回答でした。とりあえず自分でなんとかせぃ、ということですね。実際に僕が公開しているChrome拡張機能でも「動かないよ」ってフィードバックのみで実際何が起きているか全くわからずに対処のしようがない、という状況を経験してたりするので、Framework側で何とか実装されるととても嬉しいんですが。そして「AndroidがChrome搭載になったら、Android向けChrome拡張機能もいけるの?」って質問には、残念ながら「It’s difficult. And it’s difficult.」という回答でした。「他のブラウザでもChrome拡張機能が動けばいいよね、プランは?」という質問には、「拡張機能はWebブラウザの結構深いメカニズムに依存してるし、難しいだろうなぁ」って感じの回答でした。

How we Make JavaScript Widgets Scream

1日目最後のセッションは「Google+ PlatformのWidgetが如何に配置されるWebサイトにご迷惑をおかけしないようにしてきたか」をテーマにしたセッションでした。つまり、Widgetのパフォーマンスチューニングについてであり、Google+トラックではありますが、完全にエンジニア向けでJavaScriptなどのテクニックについての紹介でした。

スピーカーは、Malte UblとJohn Hjelmstadの二人。どちらもSoftware Engineerです。

セッションは具体的に採用してきた速度向上のためのテクニックを次々と解説しながら、全体のどこを改善したのか示しながら進みました。結局のところ、手順としては以下となるとまとめられています。

  • 実際のプロダクトに対して、速度などを実測する。

  • HTTPリクエストを減らす。

  • もし可能なら並列化する。

  • 感覚(体感?)を最適化する。

最初の実測には、Google Analytics、Chrome Timeline Viewなどのツールを使うことができます。これらを使って、どこがどれだけ時間を使っているのかを正確に把握していきます。そして、HTTPリクエストを減らすことを考えます。これは、例えば今後であればSPDYを使うという選択肢が取れるでしょう。しかし現状では、2つのリクエストを1つにできるだろうか、キャッシュを使うことができるだろうか、そしてCSSをインラインで記述してしまうことはできるだろうか、といったことがHTTPリクエストの削減に対して実施できることでしょう。そして、リソースを並列に読み込むことを試みます。画像、JavaScriptファイルなどを、Chrome Timeline Viewによってどのように読み込まれているかを把握し、iframeをうまく使って並列化を行う、Bootstrapのレンダリングアプローチを適用する、などのテクニックを使って、できるだけ並列で読み込まれるようにしていきます。Bootstrapレンダリングによって、親のJavaScriptコードの読み込みと、Widgetのiframeの読み込みを並列にできます。

体感の向上に寄与するものとして、JavaScriptの評価を遅延させる、という手が使えます。JavaScriptを読み込んですぐに評価してしまうと、それだけユーザを待たせることになります。eval関数をうまいタイミングで使って、JavaScriptの解釈を遅らせることで、表示を優先させるなどの体感を向上できる可能性があります。処理コストの削減にはなりませんが、ユーザに「速い!」と騙すことは十分に価値のあることです。

他にもいろいろなテクニックが登場してきましたが、これらを駆使して、最適化前は、

という処理のウォーターフォールが、

というようにすっきりさせることに成功した、という話でした。


Nexus7などのプレゼントは15時に開始され、その時点でセッションを聞きに行かずに並んでいる参加者がものすごく多くいたのを記憶しています。僕は急がず、最後のセッションを聞き終えてから並びました。結構その時には空いていて、ストレスなくサクッとゲットできました。

その後、After partyと続きます。今年はバンドが2組来て、ライブ会場と化していました。日本人は今年も「入り口から入って左前の壁際」に陣取り、斜め横からライブを見ながら駄弁る、という毎年恒例の行動をとった次第でございます。

すんごい人だかりです。

ここでも食事が出るので、夕食として食べて、今日は早く休もうと思ってホテルに戻りました。が、Midnight付近になって知り合いのGoogler二人とホテルの1Fで1時間ちょいほどお茶をして、結局布団に入ったのは2時過ぎとなりました。この日は「枕をしない」というソリューションがなぜか有効に働き、すぐに眠りにつきました。

続く。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて