azihsoyn's blog

技術のこととか釣りの事とか(書けたらいいなぁ)

Google I/O 2018 Day 3 雑感

Google I/O 2018 雑記

自分が参加したセッションの雑な感想まとめです(その3)

→ 1日目

azihsoyn.hatenablog.com

→ 2日目

azihsoyn.hatenablog.com

[Codelabs] Introduction to Sceneform

セッション予約してたのですが、day2の AndroidStudioで3Dモデル表示するやつが気になりすぎてcodelabに参加しました。

Introduction to Sceneform

デモだとコードが短く見えたのですが、実際は結構書くことが多かったです。

しかもこの御時世に何故かサンプルがJavaで書かれており、中途半端にkotlinでプロジェクトを作成しまったために読み替えながら進めるのに時間がかかりました。

実際にAndroidStudioだけでAR開発ができた時はテンション上がりました。

全然関係ないですが、この朝の時間のchrome OSのセッション参加者にchromebookの75%オフクーポンが配られていたらしいです。

欲しかった。。。

[Session] Build real world games with Google Maps

events.google.com

I/O開催前に発表されていた Google Maps Platformのデモです。

developers.google.com

すでにいくつかのゲームがリリース予定だそうです(ジュラシック・パークやゴーストバスターズなど)

ARゲームが作りやすくなる反面、ポケモンGoライクなアプリが増えそうなので独自性出すのが難しそうです。

Googleオフィス訪問

たまたまご縁があって、Googleのオフィスにお邪魔することができました。

オフィスというか町でした。

I/O食で満足できていなかったので、ジャンキーなランチを食べることができて最高でした。

f:id:azihsoyn:20180515230311j:plain

歴代ドロイド君像も見ることができ、一生の思い出になりました。

[Session] An overview of Cloud IoT Core

events.google.com

セッションの時間を間違えて参加してしまったやつ。

デモはやや手間取ってましたが、成功したときの拍手がすごかったです。

IoT系の開発は全くしたことがなかったのですが、Pub/Subは確かにいるよなぁと思いました。

お土産に貰ったAndroidThings Starter Kitで試してみたいです。

Cloud IoT Coreのロードマップもあったのですが、

AndroidThings Pluginってなんでしょうね？

[Session] Add Firebase to your cross-platform React Native or Flutter app

events.google.com

最後のセッションもflutterです。

ReactNative と flutterのコードにfirebaseのsdkを組み込んだデモアプリだったのですが、アプリの完成度が高すぎでした。

firehuntというscavenger huntのアプリでした。切実にコードの公開を望みます。。。🙏

デモの内容はfirebase predictionでプッシュの打ち分けと、remote configを使ってアプリのデザインを変えるみたいな実践的なものでした。(プッシュのデモは失敗でしたが)

firebaseがめっちゃ便利なのがわかりました。

また、flutterにはhot reloadがあるからなのか、ライブコーディングをするセッションが多かったです。

After Hour

は最終日はなく、セッションが終わったら終了です。特にアナウンスとか拍手とかはなかったです。

ジャンキーな食事もステーキも楽しんだので最終日はひたすら飲むことにしました。

f:id:azihsoyn:20180515232724j:plain

この後ワイン2杯ほどおかわりして帰りました。

以上で3日間の振り返りは終わりです。

やっぱり当日のうちにやっておきたいですね。

Google I/O 2018 Day 2 雑感

Google I/O 2018 雑記

自分が参加したセッションの雑な感想まとめです(その2)

→ 1日目

azihsoyn.hatenablog.com

[Session] Code beautiful UI with Flutter and Material Design

events.google.com

flutterのライブコーディング的なやつ。なにげにファイルの分割とか参考になった。

[Session] Microservices in the Cloud with Kubernetes and Istio

events.google.com

microserviceは辛い?みたいな導入だったのが印象的

Istio サービスメッシュ的なやつ。

デモだったけど結構失敗してた。

(他にもデモで失敗してるセッションもあったけど、Googleに勤めてる人も人間なんだなぁと思った)

yamlでルーティング設定できる。特定のヘッダーが付いたリクエストだけcanaryとかの設定とかもできる。

[Session] What's new in AR

events.google.com

ARCoreのアップデートの詳細

デモの完成度が高くARの可能性の高まりを感じた。

ARの使い所の説明もあった。

[Session] Design Actions for the Google Assistant: beyond smart speakers, to phones and smart displays

events.google.com

Actionのガイドラインみたいな話。

作る時は聞いたほうがよさそう。

いろんなデバイスでレスポンスが違う(Contextで変える)みたいな内容。

あとActionでどうやってブランドごとの特色を出すかみたいな。 f:id:azihsoyn:20180514224922j:plain

[Session] The future of the web is immersive

events.google.com

WebXRの話。WebXRの意義はVRデバイスを持ってない人のギャップを埋めるためみたいな話。

Chrome67 Canaryから対応(flags)。Webのコンテンツをリッチにするという話。

Chrome in VR内でWebXRを使うとシームレスに移行できるっぽい？。

標準化も進めているっぽい。

[Session] Pushing immersive learning beyond the classroom

events.google.com

これもWebXRの話。技術的な内容というよりは講演に近かった。

教育でもXRでという話。

最後にTour Creatorというサービスを紹介してた。

vr.google.com

Google Mapのストリートビューとかを組み合わせてツアーを作れるっぽい。

これは教育だけじゃなくていろんなことに使えそう。

[Session] Total mobile development made fun with Flutter and Firebase

events.google.com

これもライブコーディングしながらFlutterでできることを紹介する話。

サンプルのアプリはあんまりマテリアルっぽくなかった。

カルーセルもウィジェットがある。

音を流すとか簡単にできるっぽい。

個人的にはmainにasyncってつけられるのを知ったのが一番の知見

[Session] ML Kit: Machine Learning SDK for mobile developers

events.google.com

ML Kit のデモ。セッションの列がすごかった。

face detectionの判定めっちゃ早い Smart Reply APIも使えるようになるらしい。

今までもTensorFlow liteがあったけどそれだけでは大変だったので幾つか簡単に使えるようにしましたという話っぽい。

また、オフラインでも使えるようにモデルサイズを小さくしているため、サーバー上での判定とは結果が異なっていた。

ただし独自のモデルを別途ダウンロードすることも可能。

Fishbrainという釣りのアプリは魚の画像判定モデルサイズを80MBから860KBにしたらしい。

なぜかスライドのサンプルコードがJavaだった

[Session] TensorFlow in production: TF Extended, TF Hub, and TF Serving

events.google.com

これすごかった。

TensorFlowがめっちゃ身近になるというかfor Everyoneみたいな感じになってきた。

RestAPIとかもあるし、モデルのバージョン管理とかホスティングとかモジュール化とか。

どんどん実用のハードルが下がってるので勉強しなければ。。。 Swift for TensorFlowも発表されオンラインチュートリアルが充実してるらしいので試してみる。

[Session] Building AR apps with the Sceneform SDK

これは最初何が起きてるのかわからないぐらい驚いた。

android でUnityみたいなことができる(Codelabで触って理解した)。

とにかくすごいの一言。やばい。

Sceneform Overview  |  ARCore  |  Google Developers

jsonフォーマットで3Dのアセットを定義できる(幾つかのオブジェクトファイルから生成する感じ)

レンダリングの解説とかもあって勉強になる。

[Session] Best practices for text on Android

events.google.com

渋すぎるタイトル。新機能が多数リリースされている中でのtextの話。

事前に予約するときから異彩を放っていた。実際にガチの内容だった。

スライドの進みがめっちゃはやいのでyoutubeで一時停止しながらじゃないと追いつけないと感じた。

  • PreCompiledText
  • RecyclerView
  • android Pでの改善

などなど

After Hour

2日目もビールが飲めます。

しかもこの日はJusticeのコンサートがありました。

events.google.com

が、洋楽に詳しくない私は一杯だけ飲んで早々に帰り、I/O食で食欲が満たされていなかったので洋食を食べに行きました。

写真が微妙ですがスマイルさんに教えてもらったyelpで1位のお店です。

The Best 10 Steakhouses in Mountain View, CA - Last Updated May 2018 - Yelp

Sundance The Steakhouse - 775 Photos & 1118 Reviews - Steakhouses - 1921 El Camino Real, Palo Alto, CA - Restaurant Reviews - Phone Number - Menu - Yelp

幸せな気分でホテルに帰ってベッドの上で2日目の振り返りをしながら夢の世界に沈んでこの日は終わりました。

3日目(最終日)につづく

Google I/O 2018 Day 1 雑感

Google I/O 2018 雑記

自分が参加したセッションとかの雑な感想まとめです。 参加した当日に書けばよかったなと後悔してます。

pre keynote

events.google.com

AIが演奏(音楽生成)して人間がパラメータチューニングしてた？(実際AI系の発表が多かった)

あと

keynote

events.google.com

すごかった(語彙力)

  • Google Assistant

    • アシスタントの声増えるよ(日本人声優でも頼む)
    • アシスタントが電話
    • ディスプレイつきGoogle Home

  • グーグルニュースアプリ(新しいのリリースというよりアップデートかな？)

    • ニュースアプリ系のサービス大変そう
  • android
    • app actions
      • Google Assistantとの連携が強くなる
      • 将来的には全てのアプリがassistant上で動く感じになっていきそう(妄想)
    • ML Kit
    • Google MapでARで案内してくれる(めっちゃ欲しかったやつ...)
  • Waymo(自動運転)
    • これだけAIの進化見せつけられると絶対自動運転の時代来る、、、って思った

あとこの時点でめっちゃ日焼けしました

ランチ

1日目のメニュー f:id:azihsoyn:20180514020253j:plain

ROMANが人気すぎでした。どこも品切れ状態。 自分はCALI BIRDにしました

次のdeveloper keynoteまでのお土産買おうと思ったら、、、

反省点でした。

developer keynote

events.google.com

すごかった

  • android
  • PWA
  • chrome OS
    • linux対応
      • Intelのday 0 パーティでデモ見せてもらったので知ってたけど欲しくなった
    • android studioも動く！！
  • material theming
    • マテリアルデザインにしながらもブランドごとの特色を出せるようになる
    • そのためのツールも提供(Sketch Plugin)
  • ARCore
    • Augumented Image
    • cloud anchor
      • AR空間が複数のユーザーで共有できるやつ
      • 簡単に言うとポケモンカードARとか遊戯王ARができるようになる(誰か作って...)

アンドロイド開発順当にめっちゃ進化してた。

個人的にはflutterの発表も欲しかった。。。

[Session] Customize Material Components for your product

events.google.com

初セッション。だったけど発表内容がピンと来なかった。 matherial themingでどれぐらいカスタマイズできるかみたいな内容っぽい。

デザインツールはこれ material.io

[Session] An introduction to developing Actions for the Google Assistant

events.google.com

これよかった

  • actionsでどうマネタイズするか
  • action links
    • Google Assistantへのintentみたいなリンクをどこにでも置ける
      • 可能性広がりまくる、、、
      • アプリのFQAとかaction linkにしたら面白そう

16:00 Codelabs

初Codelab参加。先のセッションで刺激されてActionを作るやつをやりました。

Build Actions for the Google Assistant (Level 1)

手順通り進めたものの途中でエラー。 なんかドハマリしそうだったので手を上げて質問。 一瞬で解決してくれてCodelab最高かよ、、、ってなりました。

ちなみに原因はchromeでactionのシミュレートするときに権限みたいなのが幾つか必要で

ここでロケーション履歴とか音声アクティビティとかをOnにする必要があったみたいです。

[Office Hour] Flutter

events.google.com

flutterで作ったアプリのデモとか展示してあった。

flutterとネイティブViewの融合に可能性を感じた(マテリアルデザインのビューの後ろがゲーム画面みたいな)。

flutterでのdynamic routingについて質問した。 こんな感じで状態によって遷移する画面を分けたい時はFutuerBuilder使うといいみたい。(この例はいまいちだけど)

  Future<Widget> _routing() async {
    var user = await _auth.currentUser();
    if (user == null) {
      return new InitialPage();
    } else {
      return new HomePage();
    }
  }

return new MaterialApp(
        title: 'Demo',
        theme: new ThemeData(
          primarySwatch: Colors.blue,
        ),
        home: new FutureBuilder(
            future: _routing(),
            builder: (BuildContext context, AsyncSnapshot<Widget> snapshot) {
              switch (snapshot.connectionState) {
                // TODO splash
                case ConnectionState.none:
                  return new Text('Press button to start');
              // TODO splash
                case ConnectionState.waiting:
                  return new Text('Awaiting result...');
                default:
                // TODO error page
                  if (snapshot.hasError)
                    return new Text('Error: ${snapshot.error}');
                  else
                    return snapshot.data;
              }
            }));
  }

[After Hours] Firebase AppShip Launchpad & Flutter Hot Reload games

外でflutter hot reloadゲームとかやってた(というかやった) プレイしたけど意味は分からなかった。

events.google.com

flutter製かどうか聞けばよかった。

[Session] Modern Android development: Android Jetpack, Kotlin, and more

events.google.com

トークが面白い。スライドも面白いのでぜひ見て。

今後のandroidをどう開発するかっていう内容。

androidで辛かったやつが色々解決されるっぽい。

Android Architecture Componentはすでにいい感じのArchitectureになってれば無理して使う必要ないらしい。

19:00 - after hour

お酒たくさん飲んだ。 f:id:azihsoyn:20180514213030j:plain

お酒って昼間から飲めるんじゃないんですね。

食べ物はめっちゃ行列になる。

補充してる途中で貰おうとすると、普通にくれる人と列にならばないとだめって言う人がいて面白かった。

会場内もライトアップされて遊園地みたいです。

ドロイド君もテンション上がってました。

f:id:azihsoyn:20180514213232j:plain

この後ホテルに帰ってこの記事を書こうと思いながらベッドの上で気持ちよく寝落ちしていました。

1日目はそんな感じです。

2日目に続く

Google I/O 2018 に行ってきたので振り返り

Google I/O 2018 雑記 振り返り

帰りの飛行機でKPTやってます。 f:id:azihsoyn:20180513001056j:plain

イベント中はセッション回ったりお昼ごはん食べたり、イベント後はアフターパーティでお酒飲んだり、ホテルに戻ってご飯食べたりお酒飲んだりで忙しくて時間がありませんでした。各セッションの感想は別のエントリに書く予定なので、このエントリではそれ以外の良かったこととかこうしたら良かったというのをまとめておこうと思います。

Keep

参加できた

全てはこれに尽きます。昔から一度ぐらいはGoogle I/Oに参加したいよなぁと漠然と思っていて申し込んだり申し込まなかったりで過ごして来たんですが、ついに念願叶って参加することができました。 1日目は感極まってこみ上げてくるものがありました(泣いてはいないですが)。

また会社に費用を出してもらえることになっているのもとてもありがたいです。そのためにもアウトプットを頑張りたいと思います。

自分の興味を満たすように行動する

「(一応)会社を代表して参加してるので、業務に関係のあることとか使えそうなセッションを見ないとな。」

という考えは捨て去って行動してました。完全に自分が見たいセッションだけを見てました。セッションの感想は別のエントリにしましたが、大体

系のセッションを見てました。同じ時間帯に見たいセッションがいくつもあってそこは流石に取捨選択しなければいけませんでしたが悔いはない選択できたかなと思います。

また、Androidの新機能系のセッションはあえて避けるようにしました。日本からAndroidのスペシャリストが何人も参加していてきっとそういう人たちが参加するだろうと思ったからです。 ツイッターで #io18jp のハッシュタグ見てるだけでも知見が貯まるぐらいだったのでこれもなかなかいい決断だったなと思いました。

ただ盛り上がりが異常だったので少しぐらいは新機能系のセッションも参加してライブ感を楽しんでみても良かったかもしれません。

知り合い増えた

Google I/O参加者のプレパーティに参加しました。

googleioparty.connpass.com

ここで知り合った方と1日目のAfter Hourで一緒にお酒飲んだりできました。

また、たまたまご縁があってGoogleのオフィスにお邪魔した際にも他社の開発者の方と知り合えました。(しかも最終日に同じホテルに泊まっていたことが発覚した)。

あとは最終日にtwitterでシリコンバレー企業巡りする人に合流してアップルのビジターパークやfacebookに行ったりと、この数日の間にいろいろな人と知り合えたのもとても良かったです。

割りと英語困らなかった

自分は英語全くできない方ですが中学生ぐらいの英語レベルでもなんとか無事生き抜くことができました。自分が困ってなかった分現地の人が困っていたと思いますが。

移動はUber/Lyftで会話しなくても問題ありません(もちろん会話できるに越したことはないです)。セッションは英語わからなくてもスライド見ればなんとなく分かったり会場の雰囲気を感じる事もできます。あとツイッターのハッシュタグ見たりとか。

一応Google I/Oに参加できることになってから海外ドラマのフレンズを英語で1ヶ月ほど聞いてたりしました。効果があったのかはよくわかりませんが何もしてないよりは耳が慣れてたような気がします。

また、こちらの記事

tomoima525.hatenablog.com

を参考にhow are youを言うように頑張ってはみたんですが、実践するのは難しかったです。成功率40%ぐらいでした。想定外の返答があると一瞬フリーズしてしまう。。。

Project Fiが最強

ホテルや会場ではwifiがあるので問題ないのですが、ツイッターがないと呼吸できない自分みたいな人間にとっては常に快適な回線がないと辛買ったと思います。Zip Simも自分が立ち寄ったエリアでは品質は問題なかったのですが2GBで上限なので何かあると不安です。

Project FiはGoogleのMVNOで、6GBぐらいまで一定料金/容量 で使えるので大分安心感がありました。

fi.google.com

使える端末が少ないのと契約できる条件が厳しいのがネックですが。。。(日本だとアプリ自体落とせないのでミラーでアレをアレしてなんとか使えるようにしました)

もし他におすすめのsimがあったら教えてほしいです。

Problem

I/O グッズ一部買えなかった

今回一番の反省点かもしれません。

会社の同僚からいくつかお土産を頼まれていたのですが、1日目終わってから追加で頼まれたTシャツを2日目の終盤に買おうと思ったらサイズがなくなってました。。S, MがなくなっていてL以上しかない状態でした。

また、自分用のパーカーも1日目に買い忘れたのですが、2日目にはSがなくなってました。 まぁMでもそんなに困ってないですが。

めっちゃ日焼けした

1日目のキーノートがやばかったです。

サンフランシスコは日向はめっちゃ暑くて日陰はめっちゃ寒いみたいな気候で、事前情報として日焼け止めは塗ったほうがいいとかサングラス必須とかは知っていたのですが、セッションに夢中になって半袖のまま日向でプレゼンを見ていたら腕が真っ赤になりました。

参加者には水筒、サングラス、日焼け止めが配られるぐらいなので対策は本当にした方がいいです。

自分は日焼け止め塗るのが好きじゃないので次回は長袖のシャツで参加しようと思います。ただ日が落ちると一気に気温が下がるので寒さ対策も必須です。ユニクロのウルトラライトダウンが大活躍でした。

iPhoneでパケ死

日本でZip Simを買ってiPhoneに挿して運用していたのですが、到着3日目(I/O 2日目)で2GBを使い切ってしまいました。これは完全に原因不明です。SMSで7850宛にでbalanceって送ると使用量が確認できるのですが、2日目では500MBぐらいしか使っていなかったのに何故。。。 3日目の朝になんかネット遅いなーと思ってbalance見てみたら

You have used 2048 MB of
2048 MB of your data balance.

って返ってきた時は絶望しました。

可能性があるとしたら2日目の夜に外食した時に店でツイッターやslackを非wifi環境下で見てしまったからか、ホテルに戻ってwifiに繋がないまま寝てしまってバックグラウンド通信で天元突破したかぐらいしか思いつきません。

追記: あっ。。。

f:id:azihsoyn:20180512235833j:plain

写真のiCloudバックアップっぽい。。。 設定でoffにしておかないとですね。。。😇

こんなこともあるかと思ってPixel2の方でproject fiも契約していたので困ることはありませんでしたが、次は気をつけたいです。

観光についてノープランすぎた

折角なので色々観光すべきでした。 たまたま運良く最終日にいろんなIT系のオフィス観光に行けましたが。(ありがとうございました) デプロイ肉、食べたかったなぁ。。。

荷物多すぎた

iPadとPCどっちかで良かったです。ほぼブログとかメモとか文章書くぐらいにしか使ってなかったので。 スライドの写真を撮ってtwitterで実況するみたいな使い方だったらiPadの方が良いかもしれません。

Try

  • 来年も申し込む
    • 当選するかは運ですが、絶対また参加したいです。
  • Google I/Oのグッズは1日目に買う
    • 欲しいものを確実に買うなら並んででも朝イチで買ったほうがいいかもしれません。
  • 持ち歩く荷物は極限まで少なくする
    • この境地にたどり着いたのは3日目でした。荷物が多いと余計に疲れるので少なくするに越したことはないかなと思います。来年参加できたら手ぶらで1日目から回れるようにしたいです。ポケットの多い服を着るのが良いかもしれません。水筒が配られましたが、会場内で水は飲み放題なのでなくても大丈夫です。(1日目のキーノートが鬼門)。モバイルバッテリーだけあれば自分的には事足りました。
  • Codelabsクリアする
    • 4回Codelabsをクリアすると翌年のGoogle I/Oの無料チケット抽選権が得られるらしいです。ただでさえ倍率が高いので少しでも当選確率を上げるにはコンプリートした方がよさそうです。1日目は空いてるらしいです(実際空いてた気がする)。
  • セッションは最前列に座る
    • 理由はいくつかあって、
      • セッション後に質問に行きやすい(質問に行って良いんだって気づいたの最終日でした)
      • スライドの写真撮っても後ろの人の邪魔にならない
      • スライドの写真撮ってる人が邪魔にならない
      • 荷物置ける
      • 足伸ばせる あたりでしょうか。人気のセッションだとそもそも最前列に座るのが難しいかもしれませんが、遠慮してなのか最前列は意外と空いてたりします。最前列を目指していきましょう。
  • 英語もっと頑張る
    • 旅行中もっと英語できたらなぁと思わなかったシーンがないぐらい無力さを味わったので次の機会までに上げておきたいです。相槌のパターンは一杯持っておきたいです。自動翻訳で英語力不要になる世界はいつか来ると思いますが、そのいつかまでは頑張らないとなと思いましたまる
  • Office Hour / App Reviewを活用する
    • 英語もそうですが、自分は業務ではアプリ開発担当ではないのでせっかく専門家に聴く機会があるのにあまり活用しませんでした。会社のアプリをビルドする環境を作っておいて質問するなり個人開発でアプリ作るなりして色々聞けるとようにしたいです。
  • 復習/アウトプットする
    • 多分全てのセッションがyoutubeに上がってるので見れなかったやつとか見ないといけないですね。実際に手も動かさないと何の意味もないのでcodelabやります。
    • 得たものを整理するためにもアウトプットもしていかないとなーと思ってます。twitterで登壇者を募集してるのをたまたま見つけたのでこちら

firebase-community.connpass.com

で発表することにしました。これから頑張って資料作ったりします。

  • ものをなくさない
    • はい。以後気をつけます。こちら

azihsoyn.hatenablog.com

に書いたので禊は済んだと思ってProblemに入れませんでした。

こう見るとTry多いですね。。まぁ

ということで。

その他細かい知見

  • 綿棒大好き人間なので綿棒持ってきてよかった
  • トイレットペーパーがやすりというのを聞いて念のためふわふわなトイレットペーパーを1ロール持ってきたけど使わなかった
  • スーツケースは自分の荷物を持っていくというよりもお土産を持ち帰るものとして考えて大きいもののほうがいい
    • お土産を考慮しなくて良いのなら大きめのリュックでも過ごせそうな感じでした。
  • I/O参加前に rehash.fm #44 で話した(2018/5/13現在未公開)店頭のチップの話がめっちゃ役に立った。

  • ホテル普通に良かった(初アメリカなので比較対象がないけど)。 www.booking.com

  • I/O会場付近は車が混んでるのでホテルから会場までUberで行くよりも、ホテルからマウンテンビュー駅までUberで行ってシャトルバスで会場に向かうのが良い気がします。帰りはその逆で。

おわりに

この記事が来年の参加者に少しでも役に立ったら嬉しいです。

あとスマイルさんとやっているポッドキャスト rehash.fm でもGoogle I/Oとかその他について話す予定なので良かったら聞いてみて下さい。

また、聞きたいことがあればtwitterで気軽に質問していただければ答えられる範囲で答えます。

繰り返しになりますが輪番変わってくれたり仕事引き継いでくれたり出張費出してくれた会社に深く感謝します。あとGoogle I/Oに参加することを快諾してくれた妻にも感謝してます。

頑張ろう。

Google I/O 2018のためにアメリカに来てiPhoneをなくしてその日のうちに回収した話

雑記 Google I/O 2018

なんの知見も得られないただの失敗談です。

TL; DR

  • Uberはめっちゃ便利
  • Zip Simもめっちゃ便利
  • iPhoneを探すはまじで優秀

全容

さて、今私はGoogle I/Oのためにアメリカに来ているわけですが、イベント前日からやらかしました。

Uberの車にiphoneを忘れる

という大失態。 空港でたまたま一緒になったゆきさんと一緒にインテル博物館観光したあと、Google I/O Zero Day partyにUberで移動した後のことでした。アメリカに着いてから移動手段は全てUberで油断していたのかもしれません。時差でウトウトしていたからかもしれません。原因がなんであれ、パーティ会場のDevil’s Canyon Brewing Companyに到着してすぐのことでした。

あれ、iphoneなくね？

自分はPixel2とiPhoneXを2台持ちにしてズボンの同じポケットに入れるのですが、写真を撮ろうと手を突っ込んでもPixel2の感触しかない。。。

sim入れ替えのためにリュックに入れてたかな？とかいろんな可能性を考えましたが、旅行用に買ったユニクロのズボンがめっちゃスマホ滑り落ちるなと思っていたので多分今乗ってきた車に忘れたんだろうなと、割と冷静に結論付けました。

でも大丈夫！Uberはドライバーとメッセージのやり取りができるからね

ただし、乗るまでは なんですよね。少なくとも目的地に着いて決済が完了してしまうとドライバーと連絡を取る方法はなさそうでした。(もしかしたら電話番号を登録しているドライバーなら履歴から辿って連絡できるかもしれません。)

この時点でめっちゃ焦る。。。アプリの履歴から色々操作してみますが直接連絡を取る方法はありませんでした。一応自分の番号を送って折り返しかけてくれるサポート機能もあるのですが、かかってきたのは自動音声っぽいよくわからない電話だけでした。

なくしたのに気づいてからすぐ車を追いかけてたら気づいて止まってくれてたかもしれないとかどうしようもないことを考えてました。

この時点で半分以上諦めかけていて、パーティ楽しんでお酒飲んで忘れようとか考えてましたがちょっと無理でした。

また、クレジットカードの保険とかで新しいの買えれば別にいいんじゃないかと前向きなことも考えてみましたが、紛失は基本対象外っぽいことを知り更に絶望を深めてました。

しばらく諦めてIntelの展示品の紹介を聞いてたりしたのですが、ゆきさんの「iPhoneを探すを使ってみてはどうか」という発言を思い出し、パーティ会場でmacbookを広げてwebのiCloud Sign in to iCloud - Appleから探してみたら、

あるじゃん！！！

見つかった場所はインテル博物館からパーティ会場の中間ぐらいの距離の場所でした。しかも移動してないっぽい。車から落とすわけはないのでそこにUberで乗った車が止まってるっぽいことがわかりました。

もしかしたらUberの客待ちでしばらくしたら移動してしまうかもしれないとも思いましたが、パーティ会場から20分ほどの距離のところだったので最後の希望に縋ってUberで直行しました。

向かう途中、車があっても駐車場から持ち主の家の場所わからなくね？とか思いましたが、アメリカは戸建てが多いので家の近くに止めてある可能性の方が高いんじゃね？とか考えてたりしました。

無事目的地に着いたら、まさにパーティ会場まで移動したときに乗った車が見つかり、

これでもう終わった、、、

と思ったのですが、結局持ち主探し問題にぶち当たりました。

集合住宅の用になっていて、道の至る所に車が止めてあります。一応一番近くの家のチャイムを押してみたのですが反応がない、、、。

iPhone探しから車の持ち主の家探しに変わった瞬間でした。

その後も何件かチャイム鳴らしたり、すれ違う人に持ち主わかりますか？って聞いたりしてはいたのですが全く見つからず。。。時間も18時過ぎていたので大分日が落ちてきて更に寒くなってきてで途方にくれていました。

トイレもずっと我慢してたので近所のセブンイレブンでトイレを借りて、手紙挟んでおいて連絡してくれるのに賭けようかなぁとか考えながら、いざドライバー探しを再開しようとしたところ、最初の方に話しかけた妙齢の女性(スーザン)に話しかけられました。

「車の持ち主見つかったの？」

「まだです...」

「911に電話する？」

「(911ってアメリカの警察だっけ？？？)うぅ...」

「私がかけてあげるから電話かして」

スッ(スマホをわたす) スーザン電話をかける

「日本からの旅行者が車にiphoneを忘れてしまったみたいで」

…色々喋ってるけど全然聞き取れない…

「1時間後ぐらいに来るから座って待ってなさいよ」

とスーザンの家の前で座って色んな話をしながら待ってたところ、テレビで見たことあるパトカーっぽい車が到着しました。

(本当に色んな話をしました。というかスーザンの息子がドラ息子というかドラッグをやってる息子らしく、スーザンの怒りや愚痴を聴きながらたまにリアクションするだけでしたが。。本当に肌寒いのに上着を羽織ってまで一緒に待ってくれたのはありがたかったです。あとスーザンはUberの価格は高いとか、もう使わないほうが良いわよとも言ってました。でも便利なんですよね。本当に。)

「Uber使ったときにiPhoneを中に忘れてしまって…」

「大体わかった」

といって集合住宅の奥の方に進んでいきました。(ちなみに車が駐めてあった場所からは大分離れてました。自力で探すのは完全に無理です。)

10分ほどしてから警察の方と一緒に夕方乗せてもらったUberのドライバーの人が出てきて、今度こそほんとに終わったと思いました。

車の鍵を開けて、すぐにiPhoneを見つけてくれてお礼と謝罪を何度もして受け取りました。

ちなみに最後は、

「君はどこに滞在してるの？そこにどうやって戻るの？」

「全然考えてませんでした。…Uberですかね？」

「Perfect」(本当に言ってた)

みたいなアメリカのホームドラマみたいなやり取りをして終了しました。 上のやり取りの後はスーザンに深い感謝と謝罪を伝えて挨拶をして別れました。

今はUberでホテルに帰ってきて、日本から持ってきた揚げ餅を食べながらこのブログを書いてます。登場人物が全員いい人だったので奇跡的に戻ってきましたが、本当に気をつけないとですね。。。

大変だったというか自分が馬鹿なだけでしたが、1日目(Google I/O 0日目)で解決できて良かったです。明日からは気をつけてイベント楽しみます。。

goaでマイクロサービス間のI/Fを共有する

goadesign golang

最近会社のAPIサーバーがgoaを使って実装されることが多くなってきています。設計とドキュメンテーションが同時にできる上にボイラープレートの省略(バリデーションとかレスポンス定義とか)ができるので使わない手はないですね。

それはいいのですが、今まで単体のAPIサーバーでgoaを使っていた時には気づかなかった問題に遭遇しました。

下のような構成を考えてみます。

client -> gateway API -> user API

gatewayAPIが内部のuser APIからデータを取得してクライアントにレスポンスを返すとします。マイクロサービスアーキテクチャでよくある構成だと思います。user APIのレスポンスだけをclientに返すのであればproxyすればいいのですが、gatewayで構造を変える場合はいい感じにレスポンスの構造体に詰める必要があります。

// こんなイメージ
type User struct {
    ID int
    Name string
}

type Response struct {
    Page int
    Users []*User // この部分はマイクロサービス通信
}

愚直にuser APIのレスポンス構造体をgateway側にコピペ定義してあげてもいいのですが、ネストした構造だったり更新が多かったりすると辛いところです。また、どうせBのレスポンスを返すんだからAny (interface{})でいいじゃんという気持ちもあるのですが、なんでも突っ込めるフィールドになってしまうのが悩ましいところです。

そこでgoaを活かした解決策がないか考えてみました。

1. user APIのdesignをimportする

goaのdesign DSLはgoで定義します。つまりgo getできるということです。 user APIのdesignをgo getしてgatewayのdesignで同じものを使うようにしてgenerateすれば同じ構造のstructを作ることができます。gRPCのprotoファイルのような使い方ですね。 goは1.8から同じstructの構造であれば簡単にキャストできるようになったので変換もすぐできます。 Go 1.8 Release Notes - The Go Programming Language

// user api
package media_types

import (
    . "github.com/goadesign/goa/design"
    . "github.com/goadesign/goa/design/apidsl"
)

var User = MediaType("application/vnd.user+json", func() {
    Description("user")
    Attributes(func() {
        Attribute("id", Integer, "ID of user", func() {
            Example(1)
        })
        Attribute("name", String, "Name of user", func() {
            Example("test")
        })
        Attribute("created_at", DateTime, "Date of creation")
        Required("id", "name", "created_at")
    })

    View("default", func() {
        Attribute("id")
        Attribute("name")
        Attribute("created_at")
    })
})

// gateway
package design

import (
    . "github.com/azihsoyn/goa_microservice_sample/user_service/design/media_types"
    . "github.com/goadesign/goa/design"
    . "github.com/goadesign/goa/design/apidsl"
)

var Complex = MediaType("application/vnd.complex+json", func() {
    Attributes(func() {
        Attribute("users", CollectionOf(User)) // user_serviceのUserを使う
        Required("users")
    })

    View("default", func() {
        Attribute("users")
    })
})

2. user APIでgenerateしたモデルを使う

1でもある程度問題は解決できるのですが、同じ構造のstructの配列はそのままcastできません。

package main

type A struct {
    ID int
}

type B struct {
    ID int
}

type ArrA []*A

type ArrB []*B

func main() {
    a := []*A{&A{1}, &A{2}, &A{3}, &A{4}, &A{5}}
    var b ArrB
    b = ArrB(a)
}

// ./cast.go:18:10: cannot convert a (type []*A) to type ArrB

愚直に変換してあげてもいいのですが、どうせならuser APIの構造体をそのまま使いたいところです。 以前

azihsoyn.hatenablog.com

というエントリで書いた方法と同じなのですが、Metadata DSLを使います。

var Complex = MediaType("application/vnd.complex+json", func() {
    Attributes(func() {
        Attribute("users", CollectionOf(User), "list of user", func() {
            Metadata("struct:field:type", "app.UserCollection", `github.com/azihsoyn/goa_microservice_sample/user_service/app`)
        })
        Required("users")
    })
})

と書くと以下のように

import (
    "github.com/azihsoyn/goa_microservice_sample/user_service/app"
    "github.com/goadesign/goa"
    "time"
)

type Complex struct {
    // list of user
    Users app.UserCollection `form:"users" json:"users" xml:"users"`
}

と、user APIの型そのままでgenerateすることができます。 これでgateway → user API間のstructの構造とレスポンスの構造を再利用できるようになりました。

ただこの方法も幾つか制限があり、

  • design, appがinternalパッケージになってると使えない
  • 1つのAPIから接続するマイクロサービスの数が2つ以上になるとappパッケージがバッティングする(Metadata DSLはnamed importできない模様)
    • ので、generateする際のディレクトリ名を変更する(デフォルトapp)
  • designをimportするときにapi_definitionが重複するとgenerateできないのでimportされる側はパッケージを分ける必要がある
  • designをimportするときにMediaTypeのidentifierが重複するとgenerateできないので識別子はユニークにする

と気軽には使えないかもしれません。

せっかくgoa実装のAPIが増えてきたので連携もいい感じにできたら嬉しいんですけどね。。

こんな感じにやってるなどの知見があればアドバイスいただけるとうれしいです。

素直にI/F用のパッケージ置き場を作ったほうがいいんだろうか🤔

// こんなイメージ?
gateway -(import)-> I/F packages <-(import)- user api

サンプルはこちらに置いておきます。

github.com

エンジニアリング組織論への招待を読んで

雑記 読書感想文

読書感想文です。 久しぶりにマンガ以外の本を読んだ気がします。(この前は1年前ぐらいに実践DDDとかだと思う)

本を読んだ感想を書くのもいつぶりだろうって感じです。

twitter.com

って思ったのが4年前なのでそれぐらいは書いてない気がします。(本当に小学生とか中学生の宿題以来かもしれない)

さて、この本を読んだ感想ですが、「めっちゃわかる、、、」のオンパレードでした。仕事上で起きるトラブルやストレス、上手くいかないことが具体的な例とともに紹介されています。それが何故起きるのかを心理学などで解き明かしていくのがこの本です。

ざっくりあらすじ

不確実性の削減をテーマに個人から組織に登場人物の規模が大きくなるように構成されています。

1章ではどういった思考がうまくいかない状況を生み出すのかをいろんな引用を用いて説明しています。個人についてフィーチャーしてます。

2章では相手が出てきてコミュニケーションの課題や改善方法などが書かれています。

3章では更に人数が増えてチームでどうすべきかが書かれています。ここでアジャイルなどの歴史や誤解なども説明されます。

4章ではチームに顧客の概念が追加されます。ここでスケジュールやゴールの認識不足など誰もが一度は経験したことのあるような例が出てきます。

最終章の5章でいよいよ組織全体の話になってきます。評価の話や情報の透明性など解決の難しい問題についても触れられています。

感想

一番最初に感じたのは、答え合わせだ、、、みたいな感想でした。社会に出てから9年(もう！？)経っているので仕事でもそれなりに色々な経験をしてきたつもりではありますが、大体上手くいかないことって

人間が悪い

で片付けられるなと思ってるんですよね。合理性に欠ける考え方をしてしまったりとか感情に任せた振る舞いをしてしまったりだとか、何気ない一言が誰々を傷つけてしまったりだとか、例を上げればきりがありませんが。 そういった経験にもとづいて自分の中に出来上がっていた価値観が整理されるというかラベル付がされるというか、そんな感じの本でした。

ただ、この本では人間が悪いで終わりにするのではなく(そもそも人間が悪いとは一言も書いてませんが)、「人間はそういう生き物なので、それでも上手くやっていくならこうするのが良いんじゃないか」みたいな、現実的な解決方法を提示してくれています。

ある意味理想論で、それが完全にできるってことは逆に人間性を捨てた完全な世界なのでは？と思わなくもないですが、少し意識するだけでも変わるのかもしれません。

また、1〜5章までの構成や情報量など、数冊の本を一気に読んだような達成感がありました。

ただこの本を読んだだけでは当然何も変わらないので、自分の意識を少し変えるなり、業務に活かしてみるなりしてみたいと思います。

ハイライト

kindleで読んで気になったところにチェックしたりツイートしたりしてたので折角なのでまとめておきます。

Chapter. 1

何か問題を感じたり、不安を感じたりしたときに、人は知らず知らずのうちに、「コントロールできないもの」をコントロールしようとして、さらに思考が混乱するとか、ストレスに感じてしまいます。

これは納得感が高かった

同じ目的をもった人々は、本来対立するはずがないのです。にもかかわらず、何かの対立が発生したときというのは、その対立の当事者全員が、少しずつ正しく、少しずつ間違っています。

Chapter. 2

何かを伝えるということは、「論破すること」とは違います。

わかる...

Chapter. 4

「間に合うか、間に合わないか」ではなく、「スケジュール予測が収束していくかどうか」を管理するようにしなくてはならないというアドバイスです。

なるほど

そもそもスケジュール不安が大きくなってしまう理由は、「見積り」自体が、「ノルマ」や約束のようになり、防衛的な見積りを行ってしまうというエージェンシースラックによるものでした。

なるほど

よくなんでスケジュールが先に決まってるんだよ、、、ってシーンがあると思いますがほんとこれなんですよね。

Chapter. 5

エンジニア組織の改善に必要なことは、組織全体のコミュニケーションの改善です。そして、それは個々人のマインドとしては、第1章の考え方が重要です。

つまりみんなが頑張らないといけないということですね。

権限が明示的でないことが意味しているのは、上司の胸先三寸で権限について差配できるということです。これは実質、すべての権限が上司にある状態と変わらないのです。

ほんとこれ。ほんとこれ。

これはなるほど感が高かった

複数の部門の意思決定者が毎週寄り集まって会議をするが、何も決まらず、それぞれがそれぞれのセクションの利害を要求するばかりで、意思決定が遅いといった「ありがち」な事態は、なぜ発生するのでしょうか。それは、本来組織の内部として、同じ目的意識・同じ利害をもっているはずの組織同士が、独立した「限定合理性」をもって、調達・交渉・監視の「取引コスト」を支払ってしまっているからです。

なるほどなぁ。

宣伝

折角なので最後に宣伝を

rehash.fm

スマイルさん@smile_0yenと二人で(というか自分はゲストの気持ちでいますが) rehash.fmというpodcastをやっているのですが、先日初めて本を読んでその感想を言うみたいな企画をしてみました。 自分から言いだした企画なのですが、この時は読了率50%ぐらいでスマイルさんには迷惑をかけてしまいましたが、よかったら聴いてみて下さい。

あとアマゾンのリンクも置いておきます。

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

やはり小並感になりました。読書感想文は大人になっても難しいということがわかりました。 以上です。