イケてるウェアララブルデバイス8選とその動画

ウェアラブルデバイスについて調べる機会があったのでこっちにも投稿しておく.ウェアラブルデバイスの市場は2016年までに60億ドルを超えることが見込まれてるんだとか.*1

 

面白いと思った8つの製品と,その動画を紹介する.内訳は,エクササイズ関連が3つ,ヘルスケア関連が2つ,ライフログ関連が2つ,セキュリティ関連が1つだった.

 

エクササイズ

両手がふさがっている状態でも使用できる,という意味でウェアラブルデバイスはスポーツ・エクササイズなどと相性が良い.

Fuelband (発売中)

FuelbandNikeが発売しているリストバンド型のデバイスで,あらゆる運動を独自単位Fuelによって測定する.ユーザは運動目標をデバイス上で設定することが出来たり,運動した結果を友人達とシェアできたりすることで,ユーザがよりアクティブになる手助けをしてくれる.

Run-n-Read (Waiting list)

Run-n-Readはユニークな形でエクササイズを後押ししてくれる.ヘアバンドに装着されたデバイスがランニング中の頭の揺れを測定し,iPad/Androidと通信をすることで,デバイス上の文字をユーザの揺れに対応して動かすことができる.これによって,ユーザはランニングマシンに乗りながら電子書籍やインターネット上の記事を読むことが出来る.

MOD Live (発売中)

Recon MOD LiveはAndroid内臓のスキー用ゴーグル.天気予報・マップ・ニュースのようなコンテンツを閲覧出来ることに加えて,スキー中の速度やジャンプの高さなどをリアルタイムで測定することができる.

 

ヘルスケア

ウェアララブルデバイスによって24時間365日体温等の情報を集めることが出来るため,健康管理や健康状態の記録などへの応用がいくつか提案されている.

 

OMsignal (Waiting List)

OMsignalはザ・ウェアラブルとでも言うべき,センサー付きのアンダーウェア.心拍数や呼吸などから,装着者の感情も分析することが出来,大切な人がストレスを感じた時にまわりが気づいてあげる,みたいな使い方もできるっぽい

 

Whistle (Pre-order)


ヘルスケアが必要なのは人間だけではない.Whistleは犬向けのウェアラブルデバイスで,首輪に小さなデバイスを取り付けておくだけで,大切な犬の健康状態をトラッキングしてくれて,携帯端末などから確認することができる.

 

 ライフログ

いつでもどこでも身につけているウェアラブルデバイスは,ライフログと相性が良い.

Narrative (Pre-order)

NarrativeはTシャツなどにクリップで挟める小型カメラ.身につけているだけで,1分間に2回,ジオタグとともに写真データが保存される.一日に1000枚以上の写真がライフログとして記録される計算だ.

 

Kapture (Pre-order)


Kaptureはあなたの身の回りの音声を録音する.普通の録音機と違って,Kaptureには停止ボタンがない.起動してる限り,周りの音を常にレコードし続ける.ユーザがKaptureをタップすると,直近60秒の音声データがスマートフォンなどに転送される.

 

セキュリティ

Nymi (Pre-order)


指紋などと同様に,心臓の鼓動も人によって違うらしい.Nymiは,脈拍を測定することで個人の認証を行うデバイスである.ユーザはもう鍵をあちこち持ち歩いたり,長ったらしいパスワードを覚えなくても良い.ただNymiを腕に巻いて,ドアに手を近づけるだけだ.さらにNymiにはモーションセンサーもついており,腕の動作と連動してドアを開ける,と言ったようなことが出来る.

 

参考リンク:

今後流行りそうな最先端ウェアラブルデバイス9個のプロモーションビデオまとめ | スマートフォンアプリ開発会社ディレクターブログ

【これからのハードウェアは装着型】注目のウェアラブルデバイス10選 | freshtrax | btrax スタッフブログ

 

複数のクレジットカードを統合できるwalla.by

複数のカードをひとつのカードにまとめることができるCoinに関する記事*1*2*3に対するはてブが盛り上がっている.同じくクレカをまとめる系のWallaby CardがHacker Newsで話題になっていた.

 

Wallaby Product Video

 

持っているクレカを予め登録した上でwallaby Cardを使えば,決済ごとに最適のカード(ポイント還元率が高いとか)に決済を自動・無料で振り替えてくれるというもの

 

どうやって儲けるつもりなのかはよくわからなかったけど,昔はユーザに対する課金(50ドル/年)を検討してたっぽい. 決済額多くなってくると年50ドルくらいの価値はあるのだろうか.有料でも使いたいかはいまいち実感がわかないけど,自動で一番良いカードを使ってくれるというのはスマートな感じでよさそう.

Techcrunch Tokyo Hackathonに参加した話 / ハッカソンでエンジニアが考えるべき3つのこと

11月の11, 12日に行われたTechcrunch Tokyo・Mashup award併設のハッカソンに参加してきた.我々のチームは,会話中の表情をPUX画像認識APIを利用して解析し,アイコンの表情が変わるようなメッセージングアプリを開発した.発表直前にGCMが機嫌を損ねたりしてテンパったが,Tatsuoさんの圧倒的な発表により,AppSociallyさまから賞をいただくことが出来た.せめてもの恩返しとして記録を残しておこうと思う(AppSociallyの堤さんブログ書くべしとおっしゃってたし)

 

Andoridクライアント: daisy1754/DoyaChat · GitHub

サーバ: yutopio/DoyaChatServer · GitHub

発表資料

 

 

チーム紹介はTatsuoさんの記事にあるので割愛する.Yuto氏とは最近一緒にプロジェクトをやってるので,本当は同じチームになりたくなかったのだけど,チーム組む相手を探すときに自分と興味の方向が被りそうな人が見つからなかったし,企画出来る人・デザイナ・サーバ側エンジニアが揃ってるチーム構成が良さそうだと思って加わった.

 

チームは明るい人が多く,ブレストは盛り上がったけど,決定打はなかなか出なかった.初日の15時頃に全体に作るものを発表する時間があったのだけど,結局そのとき発表したものとは全く違うものを作ることになった.初日は8時に会場が閉まるとのことで,ほとんど作業時間がとれなかった.関係者の方がもしここを見ることがあれば,来年は夜通し使える会場を手配していただけると良いかもしれません.

 

画像認識のAPIが使えるということで,最終的に「会話中の相手の表情を画像認識で解析し,アバターの表情が変わるようなメッセージングアプリ」というアイディアに落ち着いた.チームの中でAndoridアプリの開発経験があるのが自分だけだったので,自然と自分がAndroidクライアントの実装を担うことに.良かったこと・良くなかったことあわせて「3つのこと」としてまとめておく.

 

個人プロジェクト等で"貯金"を持っておくべき

前述の通り,とにかく時間がなかったので,1日目の夜中にチャット機能や,カメラ画像のアップロード,サーバからのpushをもとにアバターの表情を変更するなど,クライアント側の機能を突貫工事でつくった.最近別のプロジェクトでGCMを使ったpushの扱いや,volleyを使ったネットワークまわりの処理を書いてたので,一晩でそこそこ動くものを作ることが出来た.短い期間でものづくりをするにあたり,普段やってきたことを流用出来るとだいぶショートカットになるし,エンジニアとして実装の貯金を持っておくことが大事なのだということを実感した.

 

デモを意識して開発すべし

せっかく動くものを作れたにもかかわらず,発表の前後で結構トラブルが出てしまった.プレゼンのために他人のマシンのエミュレータ上でアプリを動作させる必要があったのだけど,開発時は実機でやっていたためエミュレータ特有の問題に気づかなかったりだとか,優先度低いと思って放置してたバグをデモ中に踏んじゃったりとか.実装的には80%くらい完成させることが出来ていたのに,発表的には20%くらいの完成度しか見せることが出来なかった感じで,情けなかった.最後にデモをやるということを意識して,それにフォーカスした開発や,優先順位付けをするべきだった.

 

優先順位を意識すべし

上と同じ話だけど,2日という短い時間であれもこれも作るというのは難しい.なので,今回はチャット機能をとりあえず作って,そこの洗練に時間を使った.おかげでそれっぽいアプリが出来て開発のモチベーションは保てたけど,Mashup Awardという観点でいうと,チャット部分を作りこむ必要は薄かったようにも思う.むしろMashup部分である画像認識まわりを作りこむべきだった.デザイナさんがAndroid開発初体験だったこともあって,デザインの調整とかにエンジニアリソースをけっこう割いてたけど,結構アドホックに時間を使ってしまった感じはある.あるべき完成像から時間配分を決めてれば,もっと魅力的なデモができたかも.

 

 

上でいろいろ反省してる通り,本来あるべき姿を完全に見せきることが出来なかったのは悔しかったし,今後別のハッカソンとかでリベンジしたい.ただ,チームに恵まれたおかげで賞をいただくことが出来て良かったし,2日でアイディア出しからデモ出来るところまで作るスピード感は楽しかった.もし似たイベントがあればまた参加してみたいし,Techcrunchのハッカソンももっと盛り上がっていくと良いな,と思った.

第二回 渋谷Javaに参加してきた

第一回渋谷java まとめ - Togetter

第二回 #渋谷Java まとめ - Togetter

 

7/27にビズリーチで行われた渋谷JavaというJava関係のLTイベントに参加してきた.

参加者のうちで学生は自分だけだった.若者のJava離れが叫ばれる.あと,自己紹介で好きなWebサービスを聞かれたので,はてなブックマークを挙げておいた.はてなブログもまあまあ好きです.Tシャツください

 

16人くらいの参加者のうち,8人がLTをしてくださった.

Final狂の詩  @numa08さん

不変な変数は最初からfinalで宣言しましょうね,という話.メンバの値を変えるときは,新しいインスタンスを作りましょう,みたいな話をしてて,関数型っぽい考えだなあと思って聞いていたら,案の定Scalaのステマだったw8/3に麹町でScalaの会があるらしいです.

 

Apache commonsに関する話 @mystelynxさん

Apache commonsという便利ライブラリ集の,特にlangパッケージに関するお話.別の人の発表で「自分が欲しいとおもうものは他の誰かも欲しい,だから探せばある」みたいなことを言ってたけど,まさにその実例だと思う.自分は便利ライブラリ系だとGoogle guava推しだけど,Apache commonsもどういうクラスあるか見てみよう,と思った.

 

昔のJavaの話 @iwaminさん

Javaユーザ歴12年ほどになる(!)Iwaminさんによる,Javaの昔話.自分は下手したら小学生とかである...

「200*年ごろ〇〇が登場 → パフォーマンスに問題」みたいなつらみのある話が多かったwそんな時代が…!という感じでとてもおもしろい話だった.あと,今普通に使われているものも,出現自体は結構昔だったりするのだなあと思った.

 

Eclipseプラグインを作った話 ルウシィさん

実際にEclipseプラグインを作ってみてあれこれ,という話.Eclipseプラグインの作り方,というよりは,問題にぶちあたったらこうしましょう,というノウハウ集みたいな感じだった.Eclipseプラグインは昔自分も作りかけたけど,ドキュメント少ない(公式のドキュメントも必要な情報が探しにくい)し,世の中の情報はバージョンが違ってたりするし,で思いの外大変だった記憶がある.「とりあえず動くものを作って,後でその意味をしらべる」というのは,なるほどなやり方だと思った.

 

Javaアプリサーバ とりあえずの監視 @chonasoさん

Javaのアプリサーバを運用・監視するお話.監視の基本はやっぱり可視化なのですねえ.綺麗な解決は必ずしも必要なくて,とにかくサービス継続を念頭におかれているところが,現場からの生の声という感じだし,あるべき姿であると思った.

 

なんでもタイプセーフリーンスタートアップ @jfluteさん

Javaってゴテゴテしてるように思われがちだけど,IDEは良いのがたくさんあるし,型から自明な記述を自動生成したり,あるいは必要な変数もフレームワーク側で自動生成することで,型安全性を生かした「コンパイルが通れば実行時にコケない」ということはやりやすいよね,という話.ある程度当たり前の話ではあると思うのだけど,流れるようなライブコーディングもあいまって,とても説得力があった.

 

わかる!ワイルドカード総称型 @yubaさん

ワイルドカード周りの話は,わかるようなわからないようなで,毎回プログラム書くときに混乱するので,どこかでちゃんと整理したい.C#とかでこのへんの話がどう扱われているか知らなかったので勉強になった.ライブラリ作る側の視点からするとC#みたいな共変性の宣言のほうが良さそうな感じがしますな…

 

じっくりコトコト煮込んだJavaのスープ @seri_kさん

スープをソースに空目していて,秘伝のソース的な話かと思ったら全然違った.あるURLから必要な情報もってくるにはJsoupというHTMLパーサ(+HTTPクライアント)が便利だよ,というお話.同じ状況だったら自分はWebDriverを使ってたかな,と思うけど,単にURLから情報引っこ抜くだけだったらJsoupのほうが良さそう.

JavaのHttpUrlConnectionがイケてないという話があって,完全に同意するのだけど,なぜ標準にもっとベターなものがないのだろう.JavaScriptも状況が似ていて,標準のXMLHttpRequestはとても使いにくく,普通の人はjQueryとかの提供するラッパーを使っている.言語側は最低限のビルディングブロックだけ提供して,あとは勝手に拡張すべし,ということなのだろうか.兎にも角にも通信する世の中なので,HTTP通信まわりくらいもう少しまともな標準クラスがあって良いように思う.

 

 

諸般の事業が重なって,LTしない・かつ終了後逃げるように帰る,という感じになってしまったけど,楽しかった.LTイベントに参加することが初めてだったので新鮮だった.次回も都合が合えば行きたい.話すほうが楽しそうなので,機会があれば発表もやってみたいな,と思った.

 

 

謎解きゲームのようなものを企画・実施したのでまとめる

 

所属する組織の合宿というか集会というかそういうものがあって,そこでの出し物として謎解きゲームのようなものを企画した.後に似たようなことを企画する人のためにここに記録を(適度に改変しつつ)公開しておく.なお,企画段階では過去に自分が参加したリアル脱出ゲームや,Web上で見られるそれらの参加記録(ネタバレ)を大いに参考にした.以下にあげる問題のいずれにおいても,私は一切の権利を主張しないし,Web上に似たようなものが転がっていたら,私がそれを転用したと思ってもらって差し支えない.

背景

多少の予算が出ているので,チームビルディング演習,というようなお題目で企画を立てて,実態は謎解きゲームを行った.企画段階では横文字が使いたくて「スカベンジャーハント」とか言っていたが,実態としてはリアル脱出ゲームと最近言われているものに近い,謎解きゲームのようなものになった.また,非日本語ネイティブが居る関係で,問題文はすべて英語で用意してある.

利用可能範囲 合宿先ホテル敷地内(駐車場などを含む)
参加者数 30名程度
想定所要時間 2時間程度程度
運営 私と他に二名(仮に佐藤,鈴木としておく)

また,設備としてカラオケを利用した

概要

5人一組のチームに分かれてもらい,以下に示す5 + 1の問題に取り組んでもらった.ある問題の回答になっている場所に行ったり,回答で示唆されるアクションを取ると次の問題が順次提示されるようになっている.問題Iによって,各チームを分散させ,またその後の各問題に取り組む順番を変更させることで,なるべく個々のチームが別々にとりくめるようにした.

出発

問題Iと会場の地図を渡した.
本企画は「Mr.Xからの挑戦」と題しており,地図にはX "Hotel Map"と書かれている.

I. “Visit http://goo.gl/****" (***の部分には,実際にはチームごとに違う文字が書かれており,記載のURLにアクセスすると,会場内のどこかを写した写真が表示される)

問題(II~V, およびFinal)

II. "Enter into..."question 2 Hint for question2

III. “Go to the intersection of F-O and I-S" (注: この問題は地図の存在を前提としているので本記事読者には解答できない)

IV. “Take a photo with Suzuki at 1234567" f:id:nkazuki:20130718095842p:plain

I. "Sing a song at karaoke" f:id:nkazuki:20130718095845p:plain

Final. f:id:nkazuki:20130718095849p:plain

解説

問題II

チームビルディングの体なので,輪になって考えてもらった時に,反対から見ている人のひらめきを期待.手書きの文字らしきものを反対から見ると数字のように見える.

f:id:nkazuki:20130718095851p:plain

ホテルの715号室にあらかじめ次の問題を用意しておく.

問題III

地図を利用するもの.地図上の施設名のうち,イニシャルがF, O, I, Sであるものをそれぞれさがし,それらを結ぶ直線の交点に向かうと,スタッフ佐藤が待機しており,次の問題をくれる.

問題IV

問題文に記載の各箇所に,簡単なクイズがそれぞれ配備されており,それを解答欄に埋めていく.バラバラな箇所に配置されているクイズを集めるのに班員で協力してとりくんでほしいところ.クイズ自体は簡単なものでよいが,今回は組織に関するものや,参加者ごとに得手不得手のありそうなものを出題し,チームビルディングらしくした.

クイズの解答を埋めていくと,Parkingという文字が導けるようになっている.駐車場に行くと,鈴木の顔写真をでかでかとプリントした紙が鈴木の車に貼付されていて,そこで集合写真をとってもらう.顔写真はいわゆる変顔になっていて,ここで笑顔で集合写真をとってもらおうという腹づもり.顔写真下に本イベント用のメールアドレスが書いてあり,ここまで集合写真を送ると次の問題が提示される.

問題V

ヒントの数字は,一つの数字がアルファベット一文字に対応している.1->a, 5->e, ...のような対応になっており,数字nはアルファベットのn番目の文字を表す.すなわち,ヒントの数字列はeveryoneとなる.ホテル内のカラオケ(スタッフ鈴木が待機)に向かい,全員で何らかの歌を歌ってもらえば次の問題を提示する.

最終問題

最後の問題のため,今までの問題および地図を利用する.しかし,問題のナンバリングと実際に問題に取り組んでもらう順番をチームごとにかえたこともあって,なかなか問題番号に着目するということに気づいてもらえなかったようだ.最初にイントロダクションをするときに「最後に今まで解いた問題が必要になります」くらいのことをは言及しても良かったかもしれない.

ローマ数字とアラビア数字の組が,ひとつのアルファベットに対応する.例えばI-3は,問題Iの問題文の3文字目,つまりSになる.この調子で復号を行うと,See Sato, say Hatenaとなり,佐藤の元に向かい,「はてな」といえばクリア.

所感

2時間を想定していたが,最初の5問に要するのがほぼ1時間くらいであった.尚,今回の参加者層はいわゆる高学歴の若者たちが中心であった.その後は最終問題で詰まるチームが多く見られたので,最終問題に対してはもう少しヒントを出すべきであったようだ.

参加者にはそれなりに楽しんでもらえたようで,企画側としてはやったかいがあった.この記事が他の方の助けになれば幸甚である.

Week 13

最終週であった.第12週に引き続き,ようやく自分のやってることに対する周りのサポートが強くなっていて,インターンが終わるまでにやったことをきっちり片付ける週だった.その結果,自分と直接働いていない社内ドッグフーダーなどもプログラムの仕様を把握することになり,いろいろフィードバックをもらったり,やっぱこれいらないね,みたいな感じで書いたプログラムを軒並み削るなどした.これには不満もあったけれど,多くの人が使うサービスはやっぱり世に出すまでに何度もイテレーションを重ねるべきだとは思うし,これがインパクトのあるプロダクトの裏側なのだろうと思う.なんだかんだで自分がやったことの一部は世に出ることができそうなので,その点では幸運な部類だったかもしれない.

コミュニケーションに苦労した面もあったけれど,やはり離れるとなると寂しい.アメリカの人はなんであんなにオープンで爽やかなのだろうか.気持よく最後の日を迎えることが出来たし,ここで働くことが出来たのはとても貴重な経験であった. 

 

記憶が新しいうちに,インターン先企業について感じたことをつらつらと書いておく.

お金と人材に恵まれたスタートアップで,シリコンバレーの大企業へと変貌を遂げている,という感じだった.充実した食堂や,おかし,ビリヤードなど職場を快適にする工夫があちこちにあり,社員には当然のように最新のパソコンやデバイスが与えられた.キャンパスと呼ばれる広大なオフィスにあまり背の高くない建物がいくつも立ち並び,それらに囲まれる中庭を毎日のように日差しが照らしている様は,まさにシリコンバレーという感じがした.

 

スタートアップ的な部分には当然悪い面と良い面があった.

会社全体がとても若く,どんどん新卒社員が入ってきていて,インターンにも十分な権限があって,ソフトウェアの品質保証という面ではどうなのだろうと思う点もあった.また,意思決定が天下り式でないことを誇りにしている反面で,意思決定の方法が確立されてないため各々が好き勝手をいって統制が取りきれていないような部分もあった気がする.自分がインターンとして潜り込めてしまったこともそうだし,業界的に人材不足の中急成長しているので,必ずしもすごいひとばかりが働いているわけではないのかなあというような印象も受けた.まあグーグルだけでも社員数万人いるらしいので,社員全員がすごいというのは普通に考えればありえない話だとは言える.

 

一方で,先輩/後輩の概念なくガンガン意見を言えて,対等に働けるのはアメリカらしくて良いなあと思ったし,結果として全員が自信や誇りを持って働いているような感じではあった.あと,自分のチームに限っていえば全体的にとてもよく働いていた.皆が残業をするというわけではないけれど,家に帰って家族の時間をとったあとまた家から仕事をしているという時間の使い方をしている気がした.

Week 12

この週は仕事が進んだ.というのも,チーム内のいろいろな締め切りが片付いてきて,自分のやっているタスクに人々が目を向けだしたという外的要因によるもの.元々プログラム自体は書いてあったものを,ようやくレビューしてもらえたり,push出来たりした.その過程でぽろぽろ詰めが甘いところというか,ここはどうするんだっけみたいな部分がいろいろ出てきて,効率の悪い進め方をしたよなとか思ってた.