Google I/O 2017渡航記 I/O 3日目編

2018/1/9 503hit

ついにI/O最終日です。初日を考えるとボリュームたくさんだなぁと思うけれど、終わってしまうとあっさりです。最終日は夕方頃で撤収になるしセッション数も減るので2/3終わったというよりは4/5くらい終わった気がします。
今日でこのホテルは撤収。明日からは観光のためにサンフランシスコ市街地に移動します。
サンフランシスコ市街地ってホテルが高いイメージがあったのですが、I/Oの特別価格になっているサウスベイエリアより安い価格になっていました。
去年はI/O会場に荷物を預けることができたみたいなので、可能なら会場に荷物を預けて会場から直接サンフランシスコへ向かいたいところ。
という話をしながら朝食を食べていたら、別ホテルの人に止まっていて先にI/O会場についた人から連絡があり、I/O会場に荷物を預けられるとのこと。
よかった。こういう助け合いがあるのでI/Oはホント助かります。
ということで、荷物を持ってチェックアウトします。
このホテル、満足度高かったです。清潔感や新し感ではAloftに負けていますが、部屋の広さや防音設備、水回りの使い勝手などはこちらのホテルが上。そして何より朝食付きというのが実に良かったです。
朝食もわりと美味しかったのでアレコレ食べたくなります。
I/O会場につきました。駐車場部分に荷物を預け入れるところがあり行き先に連動して荷物を分けているようです。


受付付近に謎の日本語Tシャツを着ていた人がいたので写真を取らせてもらいました。

Machine Learning APIs by Exampleに行きたかったのですが、セッションの様子がおかしい。APIでの話もでてこないし例も出てこない。
ひたすらトークセッションが続きます。
とおもったら、Facebookで連絡が来て
暑いからMachine Learning APIs by Exampleは空調があるStage3に移動して、Past, Present and Future of AI / Machine Learningをアンフィシアターに移動になったよとのこと。
そんなんありなんです? というか予約システムはどうなってたんだろう、普通に予約ありで通れちゃったんですが・・・
トークセッションも悪くなかったんでしょうが、とりあえず事例が見たいと思って参加していたのですごく残念な気持ち。
他にも間違えている人が多かったみたいで会場全体がビミョーな空気に包まれていました。スピーカーの人たちかわいそう。
ただでさえ、見どころのない3日目の一発目を逃したことで意気消沈です。
急いで次のセッションの予約としてFind your apps' best users with Google's machine learning を取ろうとしたのですが1時間を切っているので予約を取れないとのこと・・・ うーん 3日目にしてハズレハズレです。

Introduction to Kotlin


キャパシティが多く予約なしでも入れるKotlinセッションへ移動。
このセッションとても良かったです。AndroidでKotlinを今から始めるという人はぜひ見るべしって言う内容。
なんでKotlinで書くの? Javaでいいじゃんという人にDataクラス以外にインパクトのある事例をいくつも見せてくれます。

Understanding Color


次に入ったのが色の話。
内容はかなり入門気味の色の話で、色は知覚であること、波と粒子の両面を持つこと、
電磁波やガンマ線、赤外線などとは波長の違いであることなど
そのうち可視化出来る範囲が色で、青緑赤を感じることができ、それぞれの波長幅や強さは違うということなどデザインとかをかじったことある人なら一番最初に教わる内容をざっくりという感じ。
ちょっと前にネットで話題になった人によって黒と青か白と金色に見えるドレスの事例を元に純粋な色をそのまま出すだけでは駄目で脳内での補正もかかることを説明。
既存のsRGBの色空間が90年代当時のハードウェアの性能に基づく狭いものであることを説明しadobe RGBなどのより帯域の大きな色空間を説明しそれらがAndroidで使えるようになることの説明がありました。
@ColorLongを使うことで64bit使ってRGBに各16bit、透明度に10bit、色区間に6bit割り当てるとのこと
フルカラーとかRetinaとかあくまで当時のハードウェアの性能に基づく限界を知覚の限界であるかのように見せるマーケットのせいで誤解されている感がありますが、視認性に関しては正直人間の知覚にハードウェアはまだまだ追いついていないように感じます。

Android Sensors & Location: What's New & Best Practices


最近のAndroidがいかに電源について意識しているかについてからの紹介。
それまでのAndroidは自由度が高い反面バッテリーの使用量についてはアプリ任せという点が強く、バッテリー使用量を可視化することでユーザーにバッテリー使用量が高いアプリを淘汰させる方針を取っていましたが、それがうまく機能しなかったという結果を受けてAndroid6以降はアプリ側に規制が入ってバッテリーを消耗する処理が行えなくなってきています。
AndroidOではバックグラウンド処理に大幅にメスが入っていて出来ることが大幅に制限されるので既存アプリのエンジニアとしては結構怖い感じです。
バックグランドアプリでは位置情報を求めても更新頻度が遅くなるそうです。もっともバックグラウンドアプリで高頻度に位置情報を取得するようなアプリはマナーが良いとは思えないのでこの変更は仕方がない気がします。
位置トラッキング系のアプリではフォアグラウンドサービスにすることが求められますが、もともとバックグラウンドアプリはいつ終了されてもおかしくない状態にあるためそういうのをバックグラウンドアプリとすること自体どうかと思います。
さらに単純なトラッキングアプリは位置情報の取得をまとめて後から取得することも出来るとのこと
現在の行動を取得する機能は取得できる行動がかなり増えていることが紹介されていました。
例えば車に乗っているなら、それは自分の車か、他人の車か、手に持っているか車内においているかなどが計測できるみたい。
機械学習で精度が上がり前後の行動パターンから適切と思われる行動パターンに訂正できるのだとか
車と電車の区別もできるようになったとのこと。
AndroidWearデバイスと連携して筋トレの回数とかも計測できるのだとか

Android Animations Spring to Life


アニメーション周りについて幾つかの修正が入り、特に速度に関して使いやすくなるそうです。
物理ベースのアニメーションということで、既存は開始値、終了値、速度でアニメーションを指定していたのが、物理ベースのアニメーションでは速度を指定できるようになる。
加えてスワイプの速度をリスナーで取得できるようになるのでスワイプで弾いた物体がスワイプの指の速度を継承してアニメーションを続けるみたいなことや、目的地が変更された時に既存のアニメーションの慣性を継承してなめらかに繋がるようなアニメーションが作れるとのこと
バネでつられているオブジェクトを引っ張るといったアニメーションもライブラリーで用意されるのだとか。
同時に動くアニメーションとかも定義しやすそう。
発表の最中に突然会場中のアラームが鳴り響きました。
もしかして緊急地震速報?かとおもったら誘拐警報。

米国はこんなことが起きるんですね。
誘拐が起きることが想定されているという事実や、それをこうやってエリア配信するという子供を保護しようという気持ち(サンフランシスコと会場までは車で1時間以上の距離なのでかなりの範囲です。)、そこまでしても誘拐事件が発生したことなど、いろいろが衝撃的でした。(※この事件は夜に犯人は逮捕され誘拐された子供は保護されたとの報道がありました。)

Android Wear UI development best practice


Android Wearに関してはぱっとしない一年でしたね。去年のI/Oほど興奮する内容のものはなく、Wearの発表も2.0のフィードバックという感じ。
2.0のアップデートに失敗してそのフォローもまだ間に合っていない状況。1.X系の時のスピーディーなアップデートと比べるとかなりスローに見えます。
実利用として2.0をベータ時から触っていますが、長文を読みやすくなったとか見た目がおしゃれになったとかいう長所以上に通知が見えにくくなったという短所が目立っていてスマートウォッチをスマートウォッチらしく使えなくなりました。
このあたりは本来ComplicationAPIを利用することでWatchFace側でフォロー出来るようになっていてそれに期待していたように見えますが、Wearのマーケットの小ささと2.0での変更の大きさで対応する妥当性が難しい感じ。
そこへのフォローとしてサポートライブラリーが充実してComplicationAPIを作りやすくなりそうです。
一方でハードウェアビジネスの方は確実に進化していて、デザイン面でも価格面でも様々なバリエーションから選べるようになりました。
デザインで他を突き放していたモトローラが撤退したことは残念ですが、その穴を埋めるようにFossilが精力的な商品展開をしていて今後に期待したいです。
発表内容で新鮮だったのはランチャーアイコンを複数用意してもいいよ ってところでした。
もちろんAndroidスマートフォンにおいてもそれは可能なのですが一般的に言えばタブーな方法とされている気がします。
Wearの場合は手数を減らすためにそういう方法もあるよねと言うかたちで説明されていました。
個人的にはまだ受け入れられていません。

I/Oが終わって

ということで、今年もI/Oが終わりました。
例年通りながら、終わってみるとあっさりです。フィナーレ的なことはやらないんですよね 最終日には売店も撤収していたので今年はI/Oスペシャルドロイド君を買いそびれました。
例年、GoogleI/Oは偶数年があたり、奇数年はハズレと言われていましたが今回のI/Oは奇数年ながらあたりだったと思います。
なんといっても、一番刺さったのがAndroidの広がりとGoogleAssistantの存在。
これ、現在はまだ兆しだけで多くの人は気がついていないかもしれませんが、今後大きな潮流の変化になるかもしれません。
特に私達モバイルアプリ開発者にとってこれは大きな転換になる可能性があります。
それはGoogleがService Firstの環境を作ろうとしているということ。
もちろん以前から予兆はあって。例えば2012年にはGoogleがChromeをAndroid対応にした時に、同時にiPhoneにも対応すると発表して会場を驚かせました。
AppleとGoogleと言うとiPhone vs Androidで仲が悪い印象がありますが、Googleに取ってみたらAppleは脅威でもなんでもないわけです。
Appleにとっていちばん大切なのはiPhoneを売ることで、iPhoneに付随するサービスやアプリはiPhoneの魅力を増すために作られています。
一方でGoogleにとっていちばん大切なのはサービスを使ってもらうことで、AndroidもiPhoneもどちらもその入口でしかありません。
なので、Appleは原則的に自社のサービスやアプリをAndroidに展開していませんが、GoogleはiPhone向けのアプリをAndroidと遜色なく展開しています。
Googleにとって大切なのはiPhoneとAndroidのシェアではなく、スマートフォン全体の普及率ということです。
GoogleがAndroidを作っているのはiPhoneだけでは世界中のマーケットをすべて賄える柔軟性がないことを知っていることと、iPhoneはAppleが強権すぎるのでその対策という面が大きいように思います。
そして、Android Thingsの存在。
実は、今回のI/Oに来るまでAndroid Thingsに対してあまり良い印象を持っていませんでした。
Android Thingsのような組み込みデバイスにおいてはAndroidというプラットフォームは巨大すぎて大げさすぎるように思えたのです。
ところが、その目的が互換性のためにあるといわれると納得してしまいます。
つまり既存のサービスをAndroid端末で提供している会社はAndoid Thingsを使ったIoTデバイスを使うことで殆どソースコードを流用してIoTデバイスでも自社サービスを提供できるようになります。
これはAndroid Thingsならではのメリットと言えます。
TVやAuto、WearとAndroidプラットフォームに乗っかることで労力を殆どかけずに自社サービスの入り口を増やすことが出来るというわけですが、その力をGoogle自体が実際に発揮してみせたのが今回のGoogle Assistantsの展開だといえます。
AndroidとiPhone、Google Home向けに開発するだけでこれだけ多様なデバイス向けのサービスに提供できる実例をGoogle自らが示したといえます。
そしてより重要なのはそのGoogle Assistantsと連携するAPI.AIです。一度API.AIでサービスを書けばGoogle Assitantsの機能によりAndroidスマートフォン、iPhone、Wear、Auto、TVなどのデバイスからアクセス可能になり、さらにはGoogle Assistantsにとどまらず、LINEやFacebookとも連携できてしまう。
こうなってくると、自社サービスを展開する上でWeb、アプリに加えて、Google Assistantという重要な選択肢が出てくることになります。
つまり、自社サービスを使わせたいという要求に対して、従来のようにアプリを開発して自分たちのやり方で戦うか、それともAPI.AIに乗っかるか。
前者であってほしい気がする反面、後者が盛り上がった時に前者では勝ち目がない気もします。
この大きな流れに伸るか反るかの判断、かつて国内の携帯メーカーたちもAndroidに対して同じような悩みを感じたのでしょうか。

サンフランシスコへの移動

今晩はサンフランシスコのホテルに宿泊します。
会場からシャトルバスがハイアットリーゼントの前まで出るそうなのでこれに同乗してサンフランシスコ市街地まで連れて行ってもらいます。
パイセンは今日一日中、コンピューター歴史博物館に行っていたそうでギリギリの合流となりました。
こういう自由さもI/Oの楽しいところ。
シャトルバスはミルブレー経由で1時間45分もかかりました。
こちらではWazeというSNS要素がある投稿系の交通情報共有アプリがよく使われていて、渋滞情報が視覚的にわかります。

一般的な渋滞アプリだと、渋滞していると書いてあっても渋滞していなかったり、日頃からの渋滞なのか突発的な渋滞なのかわかりにくかったりしますが、Wazeは情報が共有されることで体感的な渋滞情報が共有されるのでより人間のフィーリングなった結果が得られている気がします。
それにしてもまぁ動かない動かない
こんなことならミルブレーのホテルにしておいたほうが正解だった気がします。
ハイアットリーゼントからは手荷物を持ってmuniでパウエルストリートまで移動します。
パウエルストリートまでの間muniもBARTも並走するのですが、BARTは来た時に乗ったのでmuniに乗ることにします。
muniは地下を走るのに路面電車だけあって装備はBARTよりやや簡素で乗客は混雑していて治安もちょっと悪そう。
今回は人数がいるから良いけれど、少人数だとあまり利用したくないですね。
今晩からのホテルはVilla Florence Hotel
パウエルストリートに面した交通の便が良いホテルです。
部屋の雰囲気はなかなか良い感じで広告に偽りなし

ただし、水回りが決まって汚れているのは米国ですね、

アメリカはグレードが良いホテルから悪いホテルまで決まって水回りは何かしら汚れていて、これは日本とは水事情が違うのか、美的感覚の違いなのか、一体何なんでしょう。
そういえば、Google本社も日本では考えられないくらいピカピカしているんですがトイレだけはあまりキレイじゃないんですよね。
ホテルの目の前に有るTAD’Sステーキハウスで今夜は晩御飯です。
この店何故か毎年来てしまうのですが、セルフ式のステーキハウスで量はそこそこなんですがサンフランシスコにしては値段が安く味も結構マトモです。
でもいつかはアメリカの美味しいステーキを食べに行ってみたい。

ホテルからは夜景が良い感じ。近くのストリートミュージシャンがトランペットでシンデレラとゴッドファーザーをずっと繰り返しています。
それしか演奏できないんだろうなぁ 勘弁して欲しい。
あと、やはり夜遅くまでウルサイですね。私は平気ですが音が苦手な人は辛いかと思います。
深夜遅くまでケーブルカーが走行していてこの走行音がかなりのレベル。
主観ですがサンフランシスコの治安は二年前よりかなり悪くなっているように思いました。
2年前までは行く度に治安が良くなっていると感じていたので今回始めて治安が悪くなっているのを実感しました。(去年はそもそもほとんどサンフランシスコに滞在していなかったのであまり印象がない)

サンフランシスコってシリコンバレーバブルで極端な物価向上とそれに伴う格差社会の発生、そして市街地から貧困層が経済的に締め出されそれが治安の改善に結果的に繋がったと聞いていたのですが、事情が変わってきたのでしょうか?
格差社会の問題がクローズアップされると同時にGoogle I/Oに続いてAppleのWWDCもサンフランシスコからベイエリアへ会場を移していてなんとなく、サンフランシスコに対するITのイメージがやや後退しているようにも思います。
さて、明日はMakerFaire bay areaに訪問し、明後日はそのサンフランシスコを観光してみます。
Google I/O 2017渡航記 I/O 3日目編
去年に引き続き今年もMaker Faireの日程がGoogle I/Oと重なっていてどちらも楽しむことが出来ます。

前:Google I/O 2017渡航記 I/O 2日目編 次:GoogleI/O 福岡からサンフランシスコへ行く飛行機を調べてみた 2018年版

関連キーワード

[Android][写真][旅行][IT][イベント]

コメントを投稿する

名前URI
コメント