おまぬけ活動日誌

● 会場WiFiは朝ご飯の奥の方ならつながるのが朝の発見

● [io13] Android Protips 3: Making Apps Work Like Magic

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。 Reto Meterさんの講演は興味深い引用とかアニメとかあって良いような気がする。

年齢を、経過した年数ではなく、トランジスタ数で測ってみる。 (我々はICの上に載る程のトランジスタしか持っていないのだ。) これをムーア齢と読んでみる。 みんな知ってるように*1ムーア齢は22年ごとに2倍になるので、 ムーア齢は実年齢に対して片対数にプロットすると直線になる :D するとRetoさんの年齢はだいたい131,000年*2。 これは 直感的には理解できないくらい ちょっとした年数*3で、 対数で時間を測るのはあんまりみんなのやっていることではない。 わかりやすい例を見てみよう。 例えば私は、電話モデムの音が聞こえるとオンラインになるんだな、 と感じるくらい古い。 対数で測った時間は現在はもっともっと速く進んでいる。 高校に入ったころにはタイプライタはもう無くなっていたし、 携帯電話が登場し始めていたんだ。 テキストメッセージもやりとりできなかったし、 この他にも、今の携帯電話みたいな何もすごいことはできなかったけれど。 パーソナルコミュニケータを使ってたのはUSS Enterpriseに乗ってる人たちだけだった。 さて、これはアプリの開発とどう関係しているのか。

Any siginificantly advanced technlogy is indistinguishable from magic. (Arthur C. Clarke)

不可能の開発。

The only way of discovering the limits of the possible is to venture a little way past it into the impossible. (Arthur C. Clarke)

Is that actually doing anything, or is it jsut a mock? (A. N. Engineer)

他のアプリを眺めながら開発をする時に、 そのアプリが進化しないと仮定するのは間違い。 デバイス数はいつも増え続けている*4。

最良のアプリを全てのユーザーに届けよう。 例えば、Lock screen widgetを使っているアプリはまだそんなに無い。 また、今後は、 Context(Activity recognition＋Locatoin＋Google+アカウント)の利用は 重要なのではなく必須になる。 "Your phone knows you"*5。 Fused Location Providerを使ってください。

Geofenceの利用 - Geofence.builder。 Activity Recognitionの利用 - ActivityRecognitionIntentProvider、 ActivityRecognition.Result→歩いてる、止まってる、自転車、自動車…。 Google+ - mPlusClient.loadPeople()。

アプリケーションの不気味の谷。 (動画 22:40付近) 横軸をアプリが認識しているユーザーのコンテキストの量、 縦軸をアプリの素晴しさとすると、 コンテキストが増えていくに従ってアプリの素晴しさが増えていく (GalleryアプリからGoogle Mapへ)が、 あるところで谷が出現して、 それを越えるともっと素晴しいアプリ(Google Now)になる。 このために、 例えば電子メールアドレスを片方向ハッシュするなど、 ユーザーのデータはそのアプリがやっていることにだけは使いやすくするが、 その他のことには使えないようにする必要がある。

無意識、五感に訴えるアプリ。 scentairのように匂いを提供する企業も無いことはないが、 GoogleはAPIを用意してるわけじゃないけれど。 $5のコーヒーが提供する価値は色付きの水だけではない。 アプリに使えるのは視覚、聴覚、触覚だけではあるけれど、がんばる。 安全な領域に留まらずにリスクを取る。 アプリが何をやっているのか、ユーザーにしっかり知らせる。

Android Design。

視覚。UIのデザイン。

聴覚 (動画 31:50付近から)。Text to speech (TTS) tts.speak(text, TextToSpeech.QUEUE_ADD, null); 例えば、コンテクストを得て、自動車の運転をしている時だけ、 ニュースのヘッドラインを読んでくれる。 ユーザーに対して、自分だけのために特化してくれているという感覚を届ける。 音声認識。 RecognizerIntent.EXTRA_RESULT。 コンテキストを知っていれば、よりうまく認識できる。

触覚。48DP (7 mm)周期のリズム、片側 4DP の不感領域、 下にボタンを置いてナビゲートボタンとタッチミスしちゃうのを避ける。 触った時の色の変化によるフィードバック。

Simple Accessiblity Support。 <Button ... andoird:contentDescription="@string/my_button_description" /> このボタンは何をするのか。

Touch Gestures。10本の指を使ったmagic。

テスト。 Magicを演出するのに古典的な操作方法を変えなくちゃいけないことがある。 それで混乱する人もいる。そんな時に。 デベコンからアルファ版、ベータ版を使ってもらうユーザーの割合を選べるようになった。

統計を取る。デベコンで、アプリにトラッカーを仕込んで。

魔法の種明しをしないこと。 例えば、いつでも表示を最新にしておくようにして、同期ボタンを無くす。 Google Cloud Messaging (GCM)。 サーバからの更新をGCMを通じてアプリに届ける。 クロスデバイスな更新が可能。GoogleCloudMessagin.get(context)。 アプリから更新内容を送る。SyncAdapterの実装 (動画 49:50付近)。AbstractThreadSyncAdaptorをextendして。

● Cognitive Science and Design。部屋に入れなかった。後で見る。

● [io13] Big Data Mashups: Enabling Next Generation Analytics Using BigQuery

Googleによる録画。ShutterflyさんによるBigQueryの使用例。BigQueryとのやりとりはPythonでやっているようだ。周囲の処理も含めてシェルスクリプトからPythonを起動しているのが意外だった。

● [io13] All the Ships in the World: Visualizing Data with Google Cloud and Maps

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

75,000隻の船の4億点のデータをどう扱うか。

船には現在位置を放送する仕組み (VHFで送信するAIS) がととのっている。 船どうしの衝突を避けるのが最初の目的。 2012年5月から 人工衛星による中継で全世界のデータ(76k隻の40M点)を受けられるようにしたのが、 SpaceQuestなどの会社。 この他、NOAAによる2005年からの9k隻の364M点のデータもある。 先週から Google San FranciscoやSydeneyの開発者も最近受信機を買ってデータを集めはじめて、 現在、それぞれ、171隻の240k点、48隻134k点のデータがある。 これらのデータの可視化。

チャレンジは、データの大きさ、GPSの状態に依存するデータの質、データの重複。

データの保管には、Google Cloud Storageを利用する。 アクセルコントロールが効き、4PBほどまでスケールし、 データセンター内だけで操作をするには非常にレイテンシが小さいのが良い。

AISからのデータはエンコードされているので、まずは、 C++で書いたライブラリでcsvに変換した。 libc++ on Compute Engine。 Bucket APIのBucket Notificationでデータが来たのを知り、 解析のキューに放り込む。

データの提供。Bucket NotificationからGAE経由でBigQueryへ。 BigQuery Rest APIを利用してApp EngineでJava Scriptへ*1。

● [io13] Google Cloud Messaging

Googleによる録画 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

c2dmと呼ばれていたサービスがGCMになった。メッセージの種類は2種類。 Send to syncはアプリのサーバからhttpsでGCMのサーバにメッセージを送り、 GCMサーバからアプリにメッセージを送り、それを受けて、 アプリがアプリのサーバに接続する。 Send dataでは、ペイロードを含めたメッセージを、 アプリのサーバからGCMサーバ経由でアプリに送る。

APIで下記のような項目を指定できる。詳細はGoogle Cloud Messaging for Android

• Time to live - 一定時間の間にアプリに到達しなければ消える
• Delay while idle - ?
• Multiple senders
• Message multicasting
• その他

[NEW] XMPPエンドポイント。 これまでhttpsでシーケンシャルに送っていた場合、 レイテンシは60msec、スループットは30message/secくらいだった。 XMPP経由では、4000msessage/sec送れる。 Persisitentにする場合、アプリのサーバからGCMサーバにXMPPでメッセージが到達した場合、ACKが返ってくる。 ACKの返ったメッセージの同定のため、 送信時に送信先のRegistration IDだけではなくメッセージIDを指定する。 なお、XMPPで送る場合にはmulticastはない。

[NEW] Upstream messaging*1。 アプリからGCMサーバ経由でアプリのサーバにメッセージを送ることができる。 アプリからGCMサーバまではGoogleによって信頼できる経路がある。

アプリはGoogleCloudMessagingのインスタンスに、 PROJECT_IDを渡してメッセージを送信する。 端末内のGCMフレームワークがメッセージを受け取りローカルに保存してから GCMサーバに送り、到達が確認できたローカルのコピーを消す。 GCMサーバからアプリサーバへの通信も同様。 Time to live もある(0秒から4週間)。0秒の場合はすぐに送る。 接続が無い場合はエラーになる。

電池消費の最適化。 GCMフレームワークはいろいろなアプリの動作を知っているので。

Google Play ServicesはForyo以降の全ての端末で利用可能*2。

User Notigications。 アプリのサーバからGCMサーバへ、ユーザー名等のハッシュを送ると、 GCMサーバはNotification keyを付けて、そのユーザーのすべての端末に Notificationを送る。 どれかの端末でユーザーがNotificationを読むと、 その情報がNotification keyと一緒にGCMサーバに伝わるので、 他の端末のNotificationも消すことができるし、 アプリのサーバにも知らせることができる。

● [io13] High Performance Apps with Go on App Engine

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

GoはApp Engineでスタートも実行中も最も速いランタイム。 GoはApp Engineではバイナリのネイティブコードとして走る。 App Engineは自動的にスケールしてくれるしメンテナンスの必要も少ないので良いです。

2011年11月のTurkey DoodleはGoで動いていた。 Goの初級者が24時間ほどで完成させたもの。 2012年12月のSanta trackerも。毎秒5000個のクエリに耐えた。

パフォーマンスのボトルネックを見つけるには。 測定を最初から、繰り返すことが大事。 appstatsを利用する。 それはそうとGo 1.1はずいぶんパフォーマンスが良くなりましたよ。

高速化のテクニック。 Defer work。appengine/taskqueueとかappengine/delayを importして、速度のいらない処理をうつす。 例えば、メールを送信する処理。 Batch。Get→ GetMulti、Put→PutMulti。 Cachnig。 データストアはレイテンシ20msecくらいと遅いので、 memcache (1msec)とかローカルなメモリ(1us)とかを使うのが速い。 途中で消える可能性があるのに注意が必要。 Concurrency。 Control Variance。かかる時間に差がある。 "The Tail at Scale", By Jeffrey Dean, Luiz André Barroso Communications of the ACM, Vol. 56 No. 2, Pages 74-80。 これを制御したい*1。 memcacheを非同期にして、ハンドラが通る時にAPI Callがキャンセルされるように。 コンカレントにしてdoneチャンネルに完了を知らせる。タイムアウトありにする。

● [io13] From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application

Googleによる録画。 この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

Mobile Backend Starter。 https://cloud.google.com/console よりGet startedを辿って、 APIをEnableしてAPI Keyをもらってください。

サンプルのゲストブックを作ってみる。 デバイスの中にMobile backend Server Client Libraryが入る。 アプリはbackendとやりとりをして、 backendはGAEのMobile Backend Starterと通信する。 ゲストブックに書いたメッセージが端末に届く。 アプリが新しいメッセージをもらうのにポーリングを使うのは 電池的にもネットワーク的にも高価。GCMを使う。

GeekSelendipityアプリ (bradabrams/GeekSerendipity-io13、 Geek Serendipity on Google Play)。 登録しているGeekの位置から自分の近くのGeekを探してくれます。 setOnMyLocationChanged()からsendMyLocation()する。 cloudEntityを作って、getCloudBackend().update()すればよい。 このためには、CloudBackendActivityをextendする。

GAEサーバ。対応するAndoridアプリからのみ使えるようにlockdownする。 アプリへの署名を使って同じpublisherであることを確かめる。 Android Client IDをアプリのPackage nameと署名鍵の指紋から作って設定して、 oAuth Client IDをアプリとGAEの両方に設定して、 GAEとアプリと同じユーザーであることを確かめる。

GAEサーバでGeekの場所を探す。 Continuous Queries。 データが来るたびにクエリを発行して結果が返れば、 GCMでアプリに「近くに居るよ」メッセージを送る。 アプリはGAEにqueryGeeks()クエリを発行して、 結果を表示する。

Endpointを足す。 GAE側。Pyhon等で書いてデプロイ。API Explorerから見える。 Android側。Google Play Services for EclipseでGenerate Cloud Endpointすると ライブラリを作ってくれるので、ビルドパスに追加して、 ThreadからAsyncに呼ぶ。 service.logs().log(messae).execute()みたいに。

● [io13] IGNITE

Googleによる録画。去年は部屋に入れなかったのではやめに並びました。整数をらせん状に並べて素数に印をつけるとなんだかパターンがうかびあがる、というのは鳥肌ものだった。

● Pitch nightに参加する

Google I/Oの参加案内に関連行事としてPitch Night! Powered by Startup Weekend and Google Developer Groups Startup Weekend Organizationというのが紹介されていました。たぶん、アイディアを発表して良いものにご褒美がもらえる。ぼっちプログラマとしては勇気を出して参加してきました。バスが行っちゃったので知らない参加者の方々にタクシー相乗りさせてもらったよ。

Google San Franciscoでご飯をいただきながら、アイディアの分野にわかれてそれぞれのアイディアを発表しあい、グループの代表が本戦に出場という順に進んでいきました。いろいろな経歴の人たちと話をできるのは楽しかった。

僕のアイディアはボツになったけれど、いつか自分で実装してみたい。価値があるのはアイディアを実現することだし。

● 宿への帰りは深夜の金融街。怖い地域かと思ったけれどそうでもなかった。元だけあって、Google Mapsのナビゲーションに助けられながらバスで無事に帰投しましたとさ。