[Apple Watch] WatchKit AppがどれだけAndroid Wear Appと違うか。

　どうもどうも。

　WatchKitが公開されましたね。
　私はiOSアプリの開発は昔にちょっと遊んだ程度なんですが、最近Android Wearについてはわりと調べてるので、WatchKit AppとAndroid Wear Appのアーキテクチャを比較しつつApple Watchの将来を占いたいと思います。

TL; DR

 　結論からいきますと、

• Apple Watchではビューのみが動き、ロジックはiPhoneで動く。
• 対するAndroid Wearでは、Androidアプリとほぼ同じコードがガッツリ動く。

 ということです。
　つまり、スマホ本体を置き忘れたことを時計が感知して知らせる、というようなアプリは、Android Wearならたくさん転がってますがWatchKit Appでは不可能っぽい。

WatchKit AppはiPhone上で動く

　な・・・何を言ってるかわからねーと思うが（略）という感じですが事実なんです。

　Apple Watchでアプリを動かすためには、まずはiPhoneアプリが必要です。WatchKit Appは、ExtensionとしてiPhoneアプリにくっつけて配布する形になります。

　そしてiPhoneにApple Watchがつながっていると、Extensionの内容の一部がApple Watchにロードされるという仕組みのようです。

出典：WatchKit - Apple Developer

　このときApple Watchにロードされるのはビューの部分のみ。Controllerやその他のロジックはiPhoneに残って、Apple Watchからの連絡を待ちます。

　Apple Watchに表示されたビューに対してユーザがなにか操作すると、その情報が無線でiPhoneに伝えられ、Controllerが反応するというわけです。

出典：WatchKit Programming Guide

　いうなれば、Apple WatchはiPhoneの外部ディスプレイというか、シンクライアントのような動きをするわけですね。

Android Wear AppはAndroid Wear上で動く

　これはあたりまえといえばあたりまえなのですが。

　Android Wearは、Androidと連携はするのですが、アプリのアーキテクチャ的には独立というか、対等な立場なんですよね。

　そもそもAndroid Wearは、小さいナリをしてますがあれもAndroidの一亜種としてできていて、Android WearアプリはほぼAndroidアプリと同じコードで動きます。

　AndroidアプリとAndroid Wearアプリはそれぞれが独立で動く。で、必要があるときにだけOSのAPIを使ってお互いにメッセージをやりとりする。という世界観になっているわけです。

　とはいえこちらのほうも時計であまりムチャをやることは考えていなくて、ビューとしての機能＋アルファは時計でやりつつ、メインの処理はAndroidの方に投げるという実装方法が推奨されています。

開発者がうれしいのはどちらか？

WatchKit App vs. Android Wear App

 　できることが多いほうがうれしいに決まってんだろ！訴訟！という人はアンドロイダー向きかもしれません。
　少し書きましたが、しっかりした機能を求めるとなるとAndroid Wearの方も結局、重い処理を本体に移譲して結果を受け取るというパターンをとらざるを得なくなります。特にネットワークアクセスが必要な場合はかならずこのパターンになるので。

　そのあたりを隠蔽してしまってロジックの本筋だけ考えればいいようにしてくれるというのは、AppleっぽいというかiOSっぽい考え方だと思います。
　ただここまでスパッと割り切られると、ちょっとぐらい時計側で独立の処理が動く余地を残してくれてもよかったんじゃねえの・・・と思わないでもありません。

　あとは、このアーキテクチャの違いが電池の具合にどれだけ影響するかが見ものですね。

　また、Apple Watchには話題となった心拍センサをはじめいくらかのセンサがついているはずなのですが、そのデータをどうやって取得するのかは謎です。このアーキテクチャを見るに、iPhoneがApple Watchからデータを取ってくるような仕組みになるんですかねぇ・・・？

WatchKitの通知 vs. Android Wearの通知カード

　Android Wearのいいところの一つに、普通のAndroidの通知を出すと、それがいい感じにAndroid Wear向けの通知カードに変換されて表示されるという点があります。

出典：Android Developers

　WatchKitの仕組みで発表された通知機能のひとつ「Actionable Notification」は、動きかたは通知なのですがWatchKitで実装しないといけないのでひと手間増える感があります。iOSの普通の通知も、おそらくApple Watchにいい感じに表示されるんだろうとは思うのですが、もしそれがない場合は開発者にとってはちょっとめんどくさいですね。

雑感：超こまけぇApple Watchとユーザの器用さをなめているAndroid Wear

　アプリのアーキテクチャに関係ない話。

（出典：WatchKit - Apple Developer、Android Developers）

 　Apple WatchとAndroid Wearの画面を見比べると、Apple Watchには「どんだけユーザに細かい操作を求めんだ」Android Wearには「ユーザをゴリラかなんかと勘違いしとんのか」という正反対の感想が個人的にはでてきますが、みなさまはいかがでしょうか。

で、どっちが勝つの？

アップルじゃないすかねえ〜？（鼻ほじ

[Google I/O 2014] I/O 2014 2日目レポート

Google I/O、今年の開催は2日間のみ。すぐに最終日になってしまいました。

並びに並ぶ

今日も朝一番。午前7時の開場に向けて、おみやげをゲットしに会場に向かいます。

LGかSamsungかを選べたので、自分の欲しいほうが品切れにならないようにみんな急ぐかなーと思って早めに行ってみました。

行ってみるとちょっとは並んでいたんですが、

おみやげの配布はRegistrationの時に使った1階のカウンターで行っていて、一度に10人ぐらい処理できる状態だったので回転が早くて、すぐに希望のものをゲットできました。

私が選んだのはSamsungです。理由は、LGにはない心拍計があるから。まー別に使うわけじゃないですが、研究の幅が広がるかなと思いまして。

Samsungは高解像度＋心拍計、LGはスリムな本体＋バッテリーが36時間持つ、という感じでいい感じに特徴が分かれていて、周りを見ると人気はどっちも同じようにばらけている感じ。

Samsung Gear Live

 Gear Liveの実物を手にしてみると、スマートウォッチにしては垢抜けた印象でこれならまぁつけたってもええかなという感じでした。でも四角くてデカイのでガジェット感はありmoto360欲しいな〜と思いました。

朝ごはん会場でドーナツを食べたりGear Liveを開封の儀してみたりしていたんですが、間が持たなくなってきたのでセッション会場に向かおうとしました。
ところが2階以上に上がるエスカレータが封鎖されていて「9時にOpenするから並んで」と。
もしかしてまた行列ですかァ〜〜ッ！？ YES!YES!YES!

2階へのエスカレータ待ちの行列

並べというなら仕方ありません。洲崎西を聞きながら並びます。

「この列はおみやげの列？」「違うよ。おみやげは中ですぐゲットできるよ。」という会話を何度も聞きました。

Session: A 3D tablet, an OSCAR, and a little cash. Tango, Spotlight, Ara. ATAP.

ATAPというのは旧Motororaの技術開発部門で、Googleによる買収と売却の後にGoogleに残った組織です。

そこがいろんなProjectをやってるんですが最近特にアツいプロジェクトの紹介です。

Project Tango

Project Tangoは、ロボティクス分野の技術を現在のスマート端末のハードウェアに統合するというテーマのもと、深度カメラなどのハードウェアを組み込んだスマート端末で空間の状況を正確かつリアルタイムに把握するというもの。

深度カメラを含む3つのカメラを使って演算は本体の中だけで完結し、わざとゆっくりスキャンする必要もなく周囲の空間の状況を把握できるというもの。

下の動画は会場で実施されたデモの様子。演壇の周りをTangoタブレットを使って読み込んでいく。

Project Ara

Project Araはスマートフォンのいろんなハードウェアをモジュール化して交換できるようにするというもの。

実現の暁には、スマートフォンにいっぱいスロットがついていて、全部電池にして究極の長寿命端末にしたり、カメラ・加速度センサー・気圧計などのいろんなセンサーを思うがままにつけて行ったり、ハードウェアの技術はどんどん進化するので新世代のカメラが出たらモジュールだけ取り替えるたり、というふうに柔軟に使っていくことができます。

モジュールの仕様はオープンにしていろんなメーカーが参入できるようにする、とか、すべてのスロットが電気の供給も消費もできる、とか、いろいろと夢のある話です。

ただしモジュール化によるオーバヘッドはかなり大きく、FPGAによる試作品の段階では性能の65%ほどがオーバヘッドであると言っていました。

また、実際にAraのテスト機を起動してみるというデモが実施されたのですが、うまく起動しませんでした。Araが市場に出てくるまではもう少しかかりそうです。

Spotlight Stories

また、最近はリアルタイムレンダリングアニメーションにも取り組んでいるとのこと。

スマートフォンから覗くようにして見れるアニメーションを作ってるらしいです。

このへんは言葉じゃなかなか説明できないのでプロモーション動画をどうぞ。

Session: Material science: Developing Android applications with material design

Android Lで導入されるMaterialデザインをどう実装するかという話。

これを使うにはこのクラスを継承して、ということの紹介でした。このへんの情報は、ドキュメントをご参照ください。

Materialデザインは全体的に「動き」がUI部品に加わったんですが、意図としては動きによって意図をつたえるということのようです。

Session: The Dawn of Fast Data

Googleの社内では、すでにMapReduceを駆逐しているというCloud DataFlowの詳細についての説明でした。

いまデータ処理を行おうとすると、分散はどういうふうにさせるのか、サーバのプロビジョニングはどうするのか、処理の順番はどうするのか、などなど、処理の本質とは違うところも考えないといけない。Cloud DataFlowはそのへんをぜんぶお守りしてくれますよということでした。

セッションでは、ツイートを分析してハッシュタグ情報をあつめておきハッシュタグの自動補完を行うという処理を題材に説明を行っていました。

Google Cloud DataFlowへのジョブの送信は、たとえば以下の様なコードを実行すればよい。

Pipeline p = Pipeline.create();
p.begin()
.apply(PubSubIO.Read.from("input_topic"))
.apply(Bucket.by(SlidingWindows.of(60, MINUTES)))
.apply(ParDo.of(new ExtractTags()))
.apply(Count.create())
.apply(ParDo.of(new ExpandPrefixes()))
.apply(Top.largestParKey(3)))
.apply(PubSubIO.Write.to("output_topic"));
p.run();

このコードは、これまた新しくリリース予定のサービスであるCloud Pub/Subを入出力にして、60分のタイムウインドウを設定して、ハッシュタグを抽出してリストを作り、再頻出の3候補を取り出すというものです。

ワークフローを投入した後はWeb GUIから現在の状況を確認可能とのこと。

これはかなりヤバいサービスだと思います。

Session: Nest for Developers

Nestはスマートサーモスタットなどを開発する企業。現在のところ、製品はスマートサーモスタットとスマート煙探知機があるんですが、そいつらをREST APIで統合的に扱えるよ、という話。
また、Nest製品だけでなく他者のスマート電球や車、スマート洗濯機などもNestのAPIに参加できるとのこと。
これを使えば、煙を探知したら電球を赤く点滅させる、車が家に向かっているとき、到着時間から推定して家の空調を入れてくれる、などとどんどん家電がつながっていくということです。

Innovate with the Glass Platform

Glassをroot化して（当然保証はなくなる）Glassを限界までハックしようというセッション。
去年に続きGlass Development Kitの開発者であるHYとPY（※どちらも人名）のコンビがお送りします。
今回紹介されていたのは、
Glassのタッチパッドからイベントを直接とれる、しかもマルチタッチもOK
スマートサッカーボールの状況をGlassから見る
GlassのUSBポートにWebcamを接続して、バックミラー代わりにする
というものでした。

Glassとはいえroot化して一皮むけばAndroidデバイスなので、けっこう好き放題なことができてしまうんですね。

Session: Robotics in a new world - Presented by Women Techmakers

最後のセッション。これを見てる途中に気づいたんですが、最後のコマはどこも技術的な内容というよりはお楽しみ枠という感じで、肩の力を抜いて楽しめるものになっていたようです。
というわけで、Googleのロボティクスに関して話が聞けると思って来てしまった身としてはけっこう物足りない感じ。
パントマイム的なことをやっていたセッションや時間で自動送りになるスライドを使ってLTするIgniteのセッションを見に行けばよかったかな。。。

---終了---

ということで、今年のGoogle I/Oは閉幕です。
おもにインテルのタブレットを逃したことなど思い残したこともありつつ、いろんな情報が流れこんできた目の回るような時間でした。
あとは日本人参加者の方ともすこし交流ができました。お世話になったみなさん、ありがとうございました。

最後の朝は、自分へのごほうびってわけじゃないですが、ジモティーに人気らしいLa Boulangeでフレンチトーストとオープンサンドイッチを買って食べました。

どちらも絶品でとくにフレンチトーストはプリンみたいに濃厚。

サンフランシスコもGoogle I/Oも、また、来たいなあ。

[Goolge I/O 2014] I/O 2014 1日目レポート

朝6時に起きて水圧のクッソ弱いシャワーを浴び、Moscone Westに向かいます。
朝食会場が7時からということなので、まああさめしでも食ってからKeynoteの列に並べばいいや、と。
ところが現地に着くとすでに長蛇の列。7時ですよ。えー。。。

しょうがないから何も食べずに並びます。
天候はくもり、高緯度地域の冷たい風が吹き抜けます。しかも並んだ位置が、運悪くビルとビルの谷間でビル風がすごい。
飢えと寒さで死にそうになりながら、洲崎西を聞きながら、ひたすら待ちます。
唯一の救いは、おねーさんがワゴンで引いてくるドーナツの配給。もちもちのシナモンシュガーミニドーナツがおいしかったですね。
そうしているうち、いま並んでいる列の隣に列ができてきました。何ぞ？と思っていると、どうやら列が長すぎて周回遅れになっているらしいということでした。恐るべしですね。

左側に列の2周目が伸びて来ている！

Keynote

死にそうな思いをして会場に入ると、機械式のカウントダウンタイマーみたいなものが端っこに表示されていて、ときどき車のクラクションのような音がしてました。

これ、CarPlayのAndroid版くるんじゃね・・・と思いながら待ち。

話された内容としては、

Android One

インドなどスマホの普及が進んでいない地域で、Google監修のOEMスマートフォンを安価で提供

Android L: Androidの次期バージョンについて

Material Design

通知とロック画面の改善

マルチタスキングの改善、AppIndexingの一般開放

1台のAndroidでプライベート用、仕事用の独立したコンテキストを切り替えながら使える

Google Play Services

Android Wear

LGのデバイスは即日Playストアから購入可能（会場：オオー！）

Samsungも参入、こちらも即日Playストアから購入可能！（会場：ウオオオオオオーーー！！！！）

moto 360は・・・この夏リリース！（会場：Oh....（落胆））

という三段落ち。

Android Autoの発表

Android版CarPlay, パートナーもたくさん！三菱、ホンダ、スズキ、スバルなどの日本企業も名を連ねる。

Android TVの発表

SONYの4Kテレビとして発売

Google AppsでOfficeファイルを直接編集可能

Google Cloud Platform

Google Cloud DataFlowを追加。「MapReduce？Googleはもうそんなの使ってないよ（笑）」という感じらしい。

GCP上にデプロイしたアプリを、クラウドで動かしたままブレークポイントを打ち込んだり、オンラインでコードを直したりできる


・・・といった感じ。

Session: What's New in Android

やっぱ新しい機能はチェックしないとね♪と思ってこのセッションに来たんですが、失敗でした。山ほどの機能を書いた山ほどのスライドをもりもりめくっていくスタイル。Android 4.4に精通してる人なら「ほーここが変わったのね」というのをひと通り確認できて便利だったのかもしれません。

が、そうではないので早々に離脱。。。ブースをまわることにしました。

Sandboxes

厳密にはSandboxと呼ぶブースとそうでないブースがあるのかもしれませんが、とにかくブース展示です。いろんな企業のブースもあれば、Googleがやってる「Go」「YouTube」みたいなブースもありました。

ノベルティを配ってるとこもあり、缶バッヂとかTシャツが定番ななか、ドロイド君人形をくれるというブースがあったので、対価としてGooglePlay For Educationのニュースを受け取るフォームに登録してゲットしてきました。

企業ブースはNest以外あまり興味なくて、Googleのブースでいくつか質問したりしました。

Session: Polymer & Web Components

PolymerのWebComponents関連機能について解説した入門者向けのセッションでした。

Polymerについてはけっこう予習をしていったので「あー知ってる知ってる」という感じ。1コマ前の「Polymer and the Web Components revolution」のほうがアツい話を聞けたかもしれないっすね。

Session: Wearable Computing with Google

GlassやAndroid Wear端末を対象にアプリやサービスを実装するとしたら・・・という話。
Android WearアプリがGlassでも動くことがこのセッションで発表され（2014/7/19追記：聞き直してみたら、Glassで動くのはAndroid Wearの通知だけでした。Glassのアプリは現状のままGDKで作る必要があります）、以降GlassとAndroid Wearをほぼ同じものとして扱っていました。
実装上の大原則としては、さまざまなデバイス間で、統一感のあるUXを提供すること。

統一感のあるUXとは言ったけど、同じUIってだけじゃダメよ？

で、従来のソフトウェアに必要な作業は設計、実装、デバグ、って感じだったのが、ウェアラブル用に開発する場合は、実機でUXを確認して改善するというフェーズも必要になるという。

左が理想、右が現実（デバグが多い）、真ん中がウェアラブル

Session: Designing for Wearable

こちらもウェアラブル系のセッション。
「The world is experience」という標語が出てきて、ウェアラブルの登場によってみんながヴァーチャルの世界に行ってしまうんじゃないかという人がいるんだけど、ウェアラブルは現実の体験をさらにすばらしいものにするべきなんだろ、というふうに言ってました。

あとは、ウェアラブルのポイントは「コンテキストの把握」と「インタラクションの簡単さ」だと言っていて、コンテキストの把握は各種センサーなどからの情報を通じて、インタラクションの簡単さは音声入力によって担保するというのがGoogleのやりかただと。
なので、ウェアラブル用に開発する場合は「ユーザがどんなコンテキストにいるのか」「ゆーざになにをしゃべってもらうと、どう反応するのか」ということからいろいろと考えてみるのだ、と言っていました。

・・・セッションはそんな感じ。

After Hours

１日が終わったあとのおたのしみ。

会場の近くの野外パーティー会場みたいなとこで野外パーティーがありました。

飲んで、食って、踊って、帰ってきました。

無線ヘッドフォンで流れるDJプレイに合わせて踊る人々

だいぶ掲載がおくれましたが、１日目はこんな感じ。。。

[Google I/O 2014] I/O 2014 0日目レポート

こんにちは。

いよいよやってきましたGoogle I/O 2014。
本番は明日からなので、今日はその0日目です。

成田空港ではしれっと出発ゲートが変わっていたりしながらも大して遅れることなく無事離陸。
この飛行機に乗ってる若い男子って全員Google I/Oに行くんじゃないの？とか思ってたら、隣の席になった日本人男性に話しかけられて、「Google I/Oですか？」「そうです」「わたしもです」みたいな会話をして確信を深めました。
お話を聞くと現地でアメリカ支社からの参加者さんと合流されるそうで、やっぱ一人じゃ限界があるよなあ・・・としみじみ思いました。

そしてサンフランシスコ国際空港に到着。
ホントはBARTに乗ってみようかと思ったんですが、ものすごく疲れていたので大人しくタクシーに乗ります。
ホテルには公称のチェックイン時刻よりだいぶ早く着いたのですが、ダメ元でフロントに話してみるとあっさりOK。これで身軽な状態でRegistrationに向かえます。

ただ今回は、ひょっとしたらRegistrationより重要かもしれないことがあります。現在のところUS在住者のみ注文することができるGoogle Glass Exproler Editionですが、会場で、US在住でなくても、手渡しで購入することができるんです。
会場のスタッフさんに買えるのか聞いてみると、「買えるけど、だれが担当かわからない。。。詳しい人に聞いてみるね。」といってつかまえた詳しいとされる人が、「購入手続きやってる人知らない？知らない？」とまわりのスタッフに聞いてくれ、やっと購入を司るスタッフの方とお話しすることができました。

購入が済んだら、暴漢に襲われないようにしっかり抱えてホテルまで戻り、開封の儀を執行（サンフランシスコは近年シリコンバレーのIT企業のベッドタウンと化したことにより家賃が高騰。そういう企業は昔からの住民に良く思われていない）。
ただ、気付かなかったわけじゃないんですか、普通のメガネをかけてるとGlassを使うのはかなり無理矢理感がありますね。

それから、ケーブルカーに乗ってフィッシャーマンズワーフまで行き、クラムチャウダーを食べ、水族館を見、ケーブルカーで帰ってき、ホテルで一休みしていました。

この時点で、実は今回の旅が今後順調に推移すれば最悪となるであろう失敗を犯してしまっていたのです。。。

その後、Twitterで知り合った日本人参加者の方と酒でも飲もうという話に。
イベントについていろいろ語っていたところ、IntelがDJパーティーを開いていて、そこでハイスペックタブレットを配布していたということが判明。
わたしはタブレットが配られていたことを知らず、会った方は誰でも入れたことを知らないというまさかのすれちがい。
これは痛いなー。。。


という苦い思いを抱えて、明日からの本番にのぞみます！
余裕があれば、このブログとツイッターアカウント@neko_machiでどんどん状況をお伝えしたいと思います！

[jQuery] 車輪の再発明（GETパラメータをJavaScriptで取得）

ふとGETパラメータをJavaScriptで取得したくなって、
jQueryを使ってるので$.getParameters()とかやれば一瞬でしょ！とか思ったら
あの偉大なるjQueryさんにもそんな機能はないんだとか。

ぐぐってみると出るわ出るわ、世界各地、各時代において腕利きのジャバスクリプターがぼくのかんがえたさいきょうのgetParameters()を披露しまくってました。
StackOverflowではトップの回答に対して「こんな回答に+1すなボケが！スクロールして下まで読むこともできんのか！」みたいなコメントがあったりしてすげーことになってます。
jQueryが公式で実装してくれりゃ苦労はないのに。

でもまー他人の書いたコードなんて信用できないぜってことで自分で車輪の再発明をしてみたので自分用にメモしておきます。
jQuery必須です。MITライセンスとしますので使いたいという奇特な方は自由に使ってください。

function getUrlParamters() {
 var parameters = window.location.search.substring(1).split('&');
 var result = {};
 $.each(parameters, function(i, parameter) {
  var keyValue = parameter.split('=');
  var key = keyValue[0];
  var value = keyValue[1] || "";
  if (!key) {
   return true;
  }
  if (result[key]) {
   result[key].push(value)
  } else {
   result[key] = [value]
  }
 });
 return result;
}

GETパラメータをオブジェクトに格納して返します。
同じキーに複数の値があることを想定して、値は配列で入れてあります。のでそう思って取り出してください。
キーだけのパラメータ（?a&b&cみたいな）の場合、値として空文字列が入ります。

以上！

[Google I/O 2014] 今年のGoogle I/OはPolymerがアツいっぽいよ。

当選！

幸運にも、Google I/O 2014のチケットが当選したので参加できることになりました。
今年は開発者向け情報ページの各所に、秘密のチケットにつながるURLが隠されてたみたいですね（URLを探しまくった英語圏の人のブログ）。

周りの人はみんなダメだったので、一人旅になります。不安だ。。。
とりあえず、現地からはこのブログかツイッター（@neko_machi）にてできるだけ状況を垂れ流してみたいと思います。
日本から参加される方、ことに同じような境遇の方、どうぞ仲良くしてください。

さ〜て、今年のI/Oは？

さて、セッションスケジュールが公開されたので中身をざらっと見てみました。
おおまかに、以下のようなテーマが幅を利かせてるようです。

• UX(Design)
• Wearable(Android Wear, Glass)
• Polymer
• Performance
• How to Success with Your Apps

あとはまあ、言うまでもなくAndroid、Chrome、GCPなどの製品ですね。
公開されたセッションスケジュールについて論評している記事としては、以下の記事がいい感じかもしれません。
http://arstechnica.com/gadgets/2014/05/google-io-schedule-mentions-android-wear-and-camera-api-disses-google/

各所で言われているのは、前までのGoogle+推しはどこ言ったんだ？ってことですね。まー、流行らなかったんじゃないすかね。。。

本命：Wearable

やっぱり今一番注目されてるのはウェアラブルですよね。

ただセッションスケジュールを見るに、ここ何年もバズりまくったGoogle Glass、ではなくてAndorid Wearをメインに据えてくる雰囲気。

Android Wearとはその名の通りウェアラブル端末用のGoogle印のOSで、既に発表されているLGのG WatchやMotorolaのMoto 360などの時計型デバイスに搭載されるもの。

それってGlassに載ってるやつ？と聞きたくなるんですが、いまのところは違うそう。

GlassがiOS／Androidデバイスとはわりと疎な関係であるのに対し、

Android WearはAndroidデバイスと常にペアリングして動作することを想定していて、子機というか出先機関として動くみたいですね。

Googleによるプロモーションビデオは一見の価値ありです。

ウェアラブルってスマホじゃだめなの？というもっともな疑問に対する答えのひとつがここにある気がしますね。iWatchはどう出てくるんでしょうか。。。

対抗：Polymer

私はジャバスクリプターなので、ウェアラブルの次にアツいのはこれだと思います。
一口に言えばHTML5のWebComponents（と同じ動作）をクロスブラウザで実現するライブラリ・・・だと思う（まだきちんと調べてない）。
WebComponentsは、何年か前からWeb界隈を騒がせてきたHTML5のWebXxxsシリーズの中でもわりと最近出てきたニューフェイスです。

最近流行りのJavaScriptリッチなWebページを作成しようとすると、どうしてもHTMLやらJavaScriptやらCSSやら、いろんな記述が跳梁跋扈する複雑怪奇なものになりがちで、
それを整理するためにBackbone.jsをはじめとしたJavaScript画面フレームワークが出てきたわけなんですが、
そういうごまかしじゃなくて、HTMLやDOMそのものを構造化・コンポーネント化されたものにしようというための機能がWebComponentsですね。

WebComponentsについては、このあたりに敏感なLIGさんとこのブログにわかりやすく書かれています。
http://liginc.co.jp/web/html-css/html/58267

ただ、他のWebXxxsシリーズがそうであったように、WebComponentsもまだまだモダンブラウザの最新バージョンに暫定的な実装があるという程度なので、
そのへんを吸収しつつ、WebComponentsに関係する便利な機能を提供するのがPolymerの役割ということのようです。

おみやげはMoto 360を所望

I/Oへのチケットを手にした幸運な開発者にとっての、そしてそれを見守る世界中のギークたちにとっての毎年のお楽しみ、GoogleからのI/O土産。

去年はGoogle Glassへの期待が盛大にふくらんでいたところにChromebook Pixelがきて、（それ自体はけっこう高価なものなんですが）ズコーッというずっこける音がネット上のいろんなところから聞こえてきた気がしたんですが、

今年もたぶん、Google Glassはもらえないんじゃないかなーと思っています。

まだまだちょっと早すぎる気がするんですよね。あと1回はハードウェアのアップデートが必要だと思います。

そのかわり、

• セッションスケジュールにおけるAndroid Wearの推しっぷり
• 初のAndroid Wear搭載機Moto 360は7月上旬発売
• https://www.google.com/events/io/sandboxの中程、いろんなデバイスが並んでるところにしれっとMoto 360とおぼしき丸い輪郭のAndroidウォッチが

というところから今年のおみやげはMoto 360！と予想しておきます。

てか、単純にMoto 360欲しい。。。

でもって、こいつはAndorid4.3機がないとほぼ役に立たないので、なにかAndorid端末がセットになっていると嬉しいですね。

おや、そういえばそろそろNexus6のうわさがありますが、これはもしや・・・？

アホか！と言われそうですが、個人用にAndroid端末を所持していないので（林檎信者なもので）、紳士のたしなみとしても1台持っておきたく、そのへんも期待しちゃいます。

という感じで、いまから皮算用をしているわけです。

さあ、幸せな気分で、無事に帰ってこれることを祈りましょう。南無。

[Gremlin] OrientDBをGremlinから使うとaddEdgeしても反応がない！？

OrientDBは、オープンソースのグラフDB（かつドキュメントDB）である。

グラフDBといえばNeo4jなんだけど、やんごとなき事情によりOrientDBを使ってみることにしたらタイトルの件でハマった。

簡単な用語説明

グラフとは？：

Excelのアレではなく、点と点を線が結ぶアレ。

グラフDBとは？：

いわゆるDBであるところのRDB（MySQLとか）は、データを表形式として扱うようデザインされている。
グラフDBは、データを点と点と線の繋がりとして扱うようにデザインされている。
データの一覧を上から下まで流し見るようなクエリは苦手だが、あなたの買った本を買ったユーザが買った本の・・・みたいに、繋がりをずるずると解決していくようなクエリが得意。

Gremlinとは？：

グラフ処理関連製品を黙々と開発し続ける謎の開発者集団TinkerPopがリリースしたグラフクエリ言語（正確には、スクリプト言語的にグラフクエリを行うためのフレームワークって感じ）。
夜に食べ物を与えてはならず、水を掛けてはいけないアレが名前とキャラクターのモチーフのようだ。

事象

VertexとEdgeをいくらか作成するようなGremlinスクリプトを流すと、Vertexはきちんと増えているんだけど、Edgeの数（g.E.count()の結果）が0と出る。またg.Eの結果がなにも帰ってこない。

公式サイトから落とせるバイナリのバージョンがまだrcなのでバグなのか！？とか、

もしやVertexとEdgeでパーミッションが別で、Edgeの書き込み権限だけないのか！？とか、

いろいろ想像と調査をめぐらした結果、ずばりの事象についてGitHubのWikiに書いてあることがわかった。

https://github.com/orientechnologies/orientdb/wiki/Troubleshooting#why-i-cant-see-all-the-edges

要約すると、OrientDBで、設定がデフォルトの状態で、propertyを含まないEdgeを追加した場合、
直接参照できない"LightWeightEdge"、つまり「見えないEdge」が作成されるというのである。

Edgeは追加されていないのではない。見えないだけなのだ。えぇー・・・。

もっと正確に言えば、Gremlinのg.Eから参照できないというだけで、たとえばg.V.outEとかやると、g.Eに期待する結果と同じものが取得できたりする。

回避策

この状況を回避するためには、「見えないEdge」を作ってくれるおせっかいモードを以下のようにオフにすればよい。

g.setUseLightweightEdges(false)

これはaddEdgeするとき等、書き込む場合に効く設定なので、すでに「見えないEdge」を作ってしまった状態でこれを実行しても見えるようにはならない。
この設定を入れた状態でaddEdgeをすると、propertyが空でもg.Eで参照できるEdgeができるというわけだ。
また、この設定は現在のセッションにだけ有効なので、気になる場合には

g = new OrientGraph(...)
g.setUseLightweightEdges(false)

のようにGraphインスタンスの生成とセットにしておくと良いかもしれない。
ただし、propertyのないEdgeを大量に作成するようなスクリプトを流す場合は、この設定は入れないほうが速い。
でもそうすると作成されるのはLightWeightEdgeになっちゃうから痛し痒しである。


以上。なかなかやらかしてくれるわい。

[WWW2014] TwitterはSNSなのか情報基盤なのか

WWW2014のTwitterソーシャルグラフに関する論文を読んだよ。

Information Network or Social Network? The Structure of the Twitter Follow Graph

Twitterのフォロー関係をソーシャルグラフにしたときの各種特徴量を計測して、

その値がSNSっぽい値なのか、そこから外れているのかを評価していくというもの。

その中で、日本のユーザにだけすごく特徴的な結果が出ているものがあるらしいってので読んでみました。
論文の内容で気に止まったものをメモがてら書きます。

そもそもグラフとは

頂点とそれを結ぶ辺からなる情報構造のこと（グラフ理論 - Wikipedia）。

そしてグラフ構造で人付き合いのようすを表現したものがソーシャルグラフですね。

ユーザを頂点とし、フォローしあっているユーザを矢印で結ぶとTwitter上のソーシャルグラフができます。

評価の方法

分析対象データは2012年下半期のある時点のフォロー関係をスナップショットとして保存したもの。

分析処理はTwitter社内のHadoopクラスタでPigを使って実行した。

Pigか。。。統計量の算出とかがメインで、グラフのトラバースとかはやってないんだろうな。

参照する先行研究としては

• Facebookのソーシャルグラフを分析したThe Anatomy of Facebook Sochial Graph
• MSNメッセンジャーのソーシャルグラフを分析したPlanetary-scale views on a  large instant-messaging network
• SNSのソーシャルグラフではこの特徴量はこうなるというのを調べた研究

（どれも読んでません！！）

など。TwitterのソーシャルグラフはFacebookやMSNメッセンジャーと比べてどうなのか、それは「SNSっぽい」値なのか、を検討しています。

フォロー／フォロワー／相互フォロー数による分析

フォロー／フォロワー／相互フォロー数の規模ごとにどれくらいのユーザが分布しているのかを分析しています。

Twitterはスパムアカウント対策として、2000件以上フォローするにはフォロワーが2200人以上必要という仕様になっているんだそうな。
ということで、フォロー数の分布は2000人の所でがっくりとギャップができています。

3つの分布を比べると、だいたいのユーザはフォロー数のほうがフォロワー数よりも多いらしい。まぁ、そうですわな。。。

論文ではこのセクションを「ソーシャルグラフにしてはフォロー／被フォローの規模が多きすぎるのでSNSっぽくない」と結論づけています。

Facebookについて語る時にも言われることなんですが、人間が友人関係をきちんと保てるのは同時に150人が限界、それはSNS上でも同じ、ということで、
フォロー何千というユーザがもりもりいるような状態はSNSっぽくないということのようです。

ただ、データの載ってる表から分位数のところを見ると、75%のユーザはフォローが121以下、相互フォローは50以下ということになるので、充分SNSっぽい数字じゃね？と思うわけですが。

クラスタ係数による分析

クラスタ係数とは、自分の友達が友達同士である割合のことです。
厳密には、共通の頂点Aと繋がっている頂点Bと頂点Cがあったとき、頂点Bと頂点Cが繋がっている割合ということですね。
これを折れ線グラフにしたものがおもしろいんです。

論文より引用

ふつうの人間関係であれば、自分の友達が友達同士である割合は高いと思います。
でもTwitterにはフォロー／フォロワーが鬼のようにいる人もいます。Twitterを「個人のつながり」のツールとして使ってない人々、たとえばパリスヒルトンやらオバマ大統領やら、企業のアカウントやら、そいういうアカウントのことです。

ということで、相互フォローの規模が大きいユーザほど、必然的にクラスタ係数も落ちてきてしまいます。
ところが日本のユーザに限っては、相互フォロー数が100から1000に伸びるにつれてクラスタ係数が上がるんですね（グラフ(b)の緑色の系列）。
つまり日本にだけ、みっしりしたアルファツイッタラークラスタ的なものがあり、それがグラフのしっぽを押し上げているということです。

これのせいで全体の値（グラフ(a)）もちょっと形が変わってしまっています。
他にも論文では、

• 日本人は、アメリカ・ブラジルと比較してクラスタ係数が高い
• ていうか日本人は地球上で一番クラスタ係数が高い
• 日本人はリフォロー率が高い

ということを指摘しています。

なお、論文中でクラスタ係数を評価して得られた結論は、「TwitterはSNSっぽい」だったようです。

結論

その他の特徴量はざっくり飛ばします。
いろいろ評価した結果、「TwitterはSNSっぽい」となる指標もあれば「SNSっぽくない」となる指標もでてきます。

全体の結果を受けて論文では、Twitterユーザがフォロー／フォロワーを増やしていく様子として以下のような行動を想定したようです（おおいに意訳含む）。

• Twitterをはじめたてのユーザはなんだかよくわからないので有名なアカウントをフォローする。
• いくらか歴が長くなってくると、アルファツイッタラーだからといってホイホイフォローするようなことはなくなる。
• そのうち知人と「Twitterやってんの？フォローしてよ！」みたいなことになったり、自分の居心地のいいクラスタを見つけてそこに溶けこむようになるSNS的な使い方がはじまる。
• やがて、有名人だからといってフォローしたアカウントはフォローから外す。

論文をきっちりと読み込んでないのでわかんないのですが、この想定がデータだけから出てきたんだったらすごいですね。「たしかにそうだなあ」という感じしますよね。

私はTwitterを始めたきっかけがモブストライクというソシャゲーだったので、初期のフォロワーはモブストライクで仲間がほしい同士の普通の知らない人だったわけですがｗ

フォロー関係だけでなくリストに入れているかどうかというのも分析すると面白そうだと思いますね。きっとリストでできる関係は、SNSというよりは情報基盤的な形をしているんじゃないかと思います。

以上。それでは。