Snippets

対抗して作ってみた。

禅とロードバイク修理技術

ながらく乗っているロードバイクが、周期的にカチャカチャ音がなって力が抜けるようになった。なんでかよくわからないままとりあえず家まで 5kmぐらいのって帰ったんだけど、もしかしてフリーホイールのラチェットが壊れてるのかなあ、とか嫌な方向に想像は膨らむ。

で、ちゃんと明るい場所でチェーンを観察してみたのが次の動画:

www.youtube.com

かちゃっと音がするところで、チェーンの間隔が長くなって、プーリーから飛び出てるようだ。これで音がなる原因は分かった。チェーンを繋ぎ直せばすむだろう。大したことがなくてよかった。

これを見て思ったのは、ちゃんと落ち着いて調べれば、原因はわかるものだなあ、ということ。正直、疲れて帰宅しようとした時にこの音を発見した時は、ちょっと上から見ただけじゃさっぱりわからず、もうこの自転車だめかと思ったものだ。でも、ちゃんと工学的産物であるロードバイクは、いざとなれば異常の原因を把握できる (そのための技術もいまのところ低い) ように作ってある。

同時に、高度な技術的産物の全体のバランスは、細部の調整で容易に壊れてしまうものである、ということも痛感した。チェーン全体はちゃんとつないであっても、その一つの長さが少しずれただけで力は正しく伝わらない。プログラムを書いているうえで日々苦労していたことも、ちょっと離れてみればこの微調整を繰り返してるようなものなんだろうなあ。

結構、ロード歴は長いけど漫然と乗ってきたところもあるので、こういった修理技術をちゃんと学んでいこうかな。他のエンジニアリングのためにもなりそうだし。

Ara勉強会と言いつつ

android

Ara勉強会 というものを目にした勢いで申し込んでしまったので行ってきました。

Project Araっつのは、Googleによる組み合わせ自由な携帯電話をつくろうっていう計画っす。

Project Ara: Part of it - YouTube

おもちゃみたいな部品を Uniproって端子でくっつけて組み合わせて使うっていう、レゴみたいな感じで自分好みの携帯が作れるっていうのでものすごく面白そうなわけです。中二心というより、秘密基地作っちゃうぞっていう小ニ心、そういやちょうどうちの子がその歳ですがレゴでいろいろからくりを作るのに苦心してる、そんなところにスマッシュヒットするわけです。ほんとにそんなにうまくいくのかよ、というのに疑問を持ちつつも興味を持っていました。

あと、一応仕事的には、Araの謳い文句として「60億人のための携帯」とか言ってるわけです。発展途上国向けの教育をやっている Quipperとしては、やはりこれはチェックしておかなければなるまい、という後付の理由もあります。まあ、これは聞いてみた結果、ちょっとどうかなあ、というのもあるのですが、そこはあとで書きます。

勉強会は 4つの講演 + 懇親会という成り立ちで、それぞれに考えたことがあったので、章を分けてだらだら書かせていただきます。それぞれ興味が有るところをお読みいただければ幸いです。

「PROJECT ARAとものづくりの未来」丸山不二夫

まず、Project ARAの立ち位置、ビジョン、社会的役割みたいな話です。ポジショントーク的な「ARAすごいぜ」って話が多くなります。

ARAっつーのは、「現在の携帯が向かっている、統合された SoC 的なアプローチを少しバラして、エンドユーザにも組み合わせをいじれるようにしよう」というのが、私のような組み込み出身技術者には最もしっくり来る説明でした。つまり、大量生産の SoCで、すべての人が同じ組み合わせを使うようでは、新しい技術 (特に狙いとしては世界とコミュニケーションするためのセンサとか) が入る余地がない。そこをバラすことで技術の革新を進められるのでは、ということだと理解しました。

とはいうものの、ARAは一般ウケするようにか投資家向けにかいろんな顔をもっていて、それぞれの人向けのプロジェクトの理解の仕方を許してる気がします。ファッショナブルな自分好みの携帯を作れるよ、っていう側面もあるし、まだスマフォ持っていない人向けにカスタマイザブルな安い携帯もつくれるよ、っていう社会開発的なストーリーもあります。そういうのがまとまって同床異夢してたりするのが Project ARA (というか今晩の勉強会) のようです。

で、正直まだまとめ方にARA、もとい粗があるな、というのが感想です。

特に、デバイスの民主化って話がよくあったのですが、やっぱりこんなのが起きるのは金持ちの国だけだと思います。発展途上国にはまだ民主化は早いのです。というと語弊がありますが、組み合わせの自由より、まずまともにそこそこ使えるデバイスです。同じものを大量生産したほうが安くて品質のいいものが作れるのです。アラブの春の後には梅雨が来るのです。アラブに梅雨はなさそうですが。というわけで、60億人のためのデバイスというのは眉唾だと思います。同じく Googleの Android ONEの方が可能性があると思います。

で、製造業が Makerのムーブメントで復活する、というようなアオリもあった気がしますが、多分、その結果は「復活」というようなものとは違うような気がします。少なくとも、高度成長期みたいにみんなに恩恵が行き渡る、というようなものではない気がします。地方でも力のあるところはそこそこ生き残っていけたりするのかもしれませんが、それは少量生産の好事家たちのものでしょう。東北大学が 試作コインランドリーっていう MEMSの開発ラインを一般開放してるという話はすこし wktkしたけど、やはりそれを使いこなす能力のある人だけですし。

というわけで、製造業が復活するというより、日本の製造業が洗脳社会のニーズに合わせて生き残るべくあがいてニッチを見つけつつある、というのが正しい気がしました。いわゆる、おじさんたちが言う意味での「ものづくり」とは違うと思います。

まあ、そういうわけで両手を上げて賛成といわずとも、いろいろ考えるネタのある話ではありました。

「ARAモジュール間インターフェースUNIPROについて 」　永井　健一

ガチ技術の話です。こういう低レベルの話からはしばらく遠ざかっていたんですが、結構面白く聞けました。

現在の UniProは 12本端子で、8本が上下2リンクずつの平衡伝送になってて、1リンクあたり 4.6Gb/sとか。バスじゃなくて UniPro switchとの P2Pになってると。LCDもこれ経由で接続することになるので 60fpsだせるのか心配になったりとか。将来は非接触の inductiveにしてやるとか。

Linuxにも少しずつ実装ができてきて Greybus というプロトコルスタックができつつあると。その上に I2Cや USBを載せることもできるらしい。

まあ、ここらへんは多分いじる暇はないだろうなあ、と思いつつも面白かったです。

「METAMORPHOSYSでできること」　佐々木陽

プロトコルができても実際に ARAのモジュールを作るのはどうするのか、というのに対する回答が METAMORPHOSYSのようです。

ここらへんは素人なんですが、いろいろモジュールを組み合わせて回路を起こして、それをレイアウトして、熱のシミュレーションをやって、さらに見積もりまでしてくれちゃうシステムらしい。それをマニュファクチャーにオンラインで発注するシステムまでつくってしまって、モジュールづくりを一気に民主化しようという意図を感じました。

でも、本体は Windows上でうごいているので、なつかしい組み込み開発環境を思い出しました。統合環境と言いつつ使いにくくて、結局は makeないのかなあ、とか探すやつです。

民主化とか言うなら、開発環境の民主化もしなきゃイカンだろ、というのをちょっと感じました。これは JavaScriptと Androidの開発の違いのようなものです。

Androidは、Googleが頑張って Eclipse上の ADTとか emulatorとか一式開発しましたが、あまり使い勝手のいいもんじゃありませんでした。最近では Android Studioで改善してきたけど、これは build systemを gradleに出して民主化した、という影響もあると思います。

それに対して JavaScriptの開発環境なんて、長い間あってなきが如しでした。Script kiddy用の言語と馬鹿にされてきました。でも、nodeやら phantom.jsやら coffeescriptやら (そしてそれを影で支える Githubやら) がそれぞれバラバラに開発されニッチを競い合って、それこそ民主的に無駄も多く進化してきたわけです。馬鹿にしてた開発環境が劇的に進化する様を見てしまったのです。

というわけで Metamorphosysはすごいけど、機能面でひと通り揃った開発環境を用意しただけで物事がうまく転がると思うなよ、という感じです。民主憲法を押し付けたからって民主的に国が発展するわけじゃないんだからな。日本は発展しちゃったけど。

「3Dプリンター、過去、現在、そして少し先の未来」　原 雄司

ARAと一番関係ない話でした。それだけに雑学的に楽しめました。

Perfumeやマツコ・デラックスをスキャンした話とか、水族館で自分の描いた魚が泳ぐのを見て、チームラボかと思ったらライゾマティクスだったりとか。

一番びっくりしたのは 3Dプリンタで導電性の部分も一緒に作って、回路まで同時に作っちゃうとか。

まあ、最初の話の、製造業の民主化のはなしの具体例みたいなことですが、事例が面白かったです。

懇親会

さほど書くこともないっす。久々に A社で一緒に仕事をしてたすずきさんにあったぐらいでしょうか。お元気そうで何よりでした。

まとめ

まとめとしては、今の仕事に直接役立ちそうにないけど楽しめました。

うーん、でも ARAの教育用モジュールとかできないかな。三角定規モジュールとか。そういうニッチにもいけるのが ARAのいいところだよなあ。

Nexus5のマイク不調が直った

android

嫁にお古の Nexus5を使わせてたんだけど、電話が不調ということでいろいろ 文句をいわれていた。とはいうものの、再現性が低く、自分が実験するとうまくいったりしてたので、なだめながら様子見をしていたのだ。けど、電話だけじゃなくて、動画撮影しても音が入らないといわれて、8割ぐらいの再現性になってしまったので重い腰を上げて調べてみた。

なにしろ、Lollipopに上げたり、IIJ Mioの SIMにしたりと、いろいろ思い当たるフシがありすぎる。嫁は SIMが怪しいという。でも SIMじゃ録画機能まで影響でないだろうと、まずは Kitkatに下げてみた。Lollipopでマイクが使えなくなった という人も多数いるみたいだし。

しかし、4.4に下げても変わらなかった。直るはずだと信じてたのに。隣で見ている嫁の顔が険しくなるのが見えた。

しかし、SIM仮説もだめだった。自分の持ってる bMobileの SIMに差し替えてもやはり動画の音が入らない。おかしい。

で、いろいろ調べて辿り着いたのが Product forum。みんなやっぱり、Lollipopが悪いとか、プロパティを変えたら直ったとかいってるけど、効いたのはこれ。

In short, after I pressed hard at the back of the phone, about 3/4 inch below the camera lens, now my mic issue is gone.

つまるとこ、裏面、カメラレンズの下、2cmぐらいのところを押したらマイクの問題はなくなった

いや、だまされたと思ってやってみたらほんとに直ってしまった。直った瞬間には笑ってしまった。こんなアナログな原因で直るなんて。

まあ、自分が携帯電話のエンジニアであるので、やっぱり自分の持ってる道具 (アップデートとか SIMカードとか) で解決したくなるのは、金槌を持ってれば釘に見えてくるのとおりだなあ。

対症療法的ではあるので、また不調になったら押さねばならないかもしれないけど、これなら嫁にもできるので簡単である。しばらくはこれで使ってみよう。

新年の抱負だったものについてまとめてみる

大晦日です。今年もいろいろあったような気がしますけど、実はそんなになかった気もします。仕事も変わってないし、いくつかプロダクトは出したけどここに書けるような成果は出してないし。 そういうなか、新年の抱負なんてものを一応書いたので、どうなったか追ってみたいと思います。

息子の囲碁初段へのコーチング

これは達成しませんでしたが、1級までは来ました。結構いい線まで行ったと自負してます。 途中スランプがあって 4級になるのに時間がかかったのだけど、高尾の中盤入門 を読ませたりして着実に実力を上げていったようです。 ちなみに、自分は認定されてるのは 3級なので、逆転されてしまいました。実際、数日前には黒を持たせてもらったものの、負けてしまいました。言い訳させてもらえれば、わざと難しい手を打ってみたりしたというのもあるけど、着実に打ってても勝ってたかは謎です。うーむ。

オープンソースプロジェクトへの参加

これはさほど参加してないっす。幾つかアイディアはあったけど、ダブってるのを発見したりしてやめちゃったり。 唯一誇れるのは RxAndroidにちょっと Contributeできたこと。まあ、本質的なものじゃなくて build errorを直したってだけですが。

いろいろ反省点はありますが、手頃な問題を発見する能力が劣っているせいでしょうか。つい大物狙いに行って企画で挫折する風がある。

オープンソースプロジェクトではないですが、potatotipsには何回か参加させてもらいました。おかげで、ネタ探しのくせはちょっと見つけられた気はします。

海外生活への布石

いや、これはこんなこと書いたなあ、といまさら思い出したぐらい何もしてなかった。多分その場の乗りで書いたんじゃないんでしょうか。

Ingress Guardian Black medal

いや、実は、数時間前、144日間維持してたポータルを破壊されたのです。イングレスやってる人ならこの意味がわかる と思います。よりによって大晦日に!!! あと1週間足らずだったのに!!!

ということがあったので、新年の抱負には書いてなかったけどこの節を追加しちゃいました。

実のところ、今年のことを語るのに Ingressを外すわけには行かないと思うんで。2月ぐらいにつらつらはじめて見て、A8には割と簡単になってつまんないなあ、といってたのが 4月ぐらいだったと思います。それからレベルキャップを外されてからが本当のゲームでした。

会社近辺で大きなフィールドを夜中に作って遊んでたらライバルが出現してきたり、中野の方のメンツに誘われて FF (みんなで集まってアイテム集め) したり、iPhone版が出現してカオスになったり、あとは Darsanaに参加して緑の腐海の雄大さと怖さを実感したり。自転車通勤と組み合わせて健康維持の原動力にもなりました。そのせいで、出勤、帰宅が遅くなったりもしたけど。

話を戻すと、Guardian black medalに関しては特に反省点はありません。壊れるものは、いつかは壊れるのです。Platinumもってるだけで、最近の Agentからすれば贅沢かもしれません。うーん、でも悔しい。

まとめ

どうもだめでしたね。やっぱり、思いつきで抱負を作ったのがいけないのでしょうか。そもそも一年の抱負という形式がこのアジャイルな社会にふさわしいのでしょうか。よくわからなくなってきましたが、これもみんな Guardian Portalが壊されたせいだ、ということにしてこの場は終わりたいと思います。畜生。

Darsana感想戦

一昨日 12月13日、Darsana TokyoというIngressのイベントを Resistance (青組) として戦って、負けてきました。 それの個人的なまとめです。

Darsanaとはなんであるのか

いちおう、少しは Ingressに詳しくない人も巻き込もうと、こんな節を設けてみましたが、詳しいところがいくつもあるのでとりあずそちらを紹介しときます:

端的にいうと、指定されたポータルを決まった時刻に数千人で取り合い、囲み合う紳士淑女の遊びです。

何が起こったか

dageziが知りうる、何が起こったか、ということを書いてみます。あくまで一兵卒の知り得たことであり、実際にはもっとたくさんの作戦、思惑がうごいていたんだろうと思います。

試合開始まで

dageziが属する Resistance では 1ヶ月以上前から秘密のコミュニティを G+上で作り、準備をしてきました。個人的にはそこまで準備する必要があるのかなあと思いつつも、当日後悔しないために必要だという先人たちの教えを聞き、キーを捨てて寒空の下指をかじかませながら Power Cubeを集め、地元を蹂躙する緑を「いつか見てろよ」と横目で睨んでバースターを節約していました。

そんな中、Elightmentが圧倒的に少ないという情報が流れてきます。

なんとなく、青の中では (というか自分の周りでは) 楽勝だな、緑弱すぎてつまんないんじゃ、という雰囲気も流れます。

また、Darsana前日の夜、緑のファーム (アイテムをいっぱい集められるところ) にいった青からは「今夜は壊さないでくれ、と緑に懇願された」という報告をうけました。「前日になって慌ててアイテム集めてるなんて pgr」という感はいや増していきます。

そして、当日、日比谷公園野外音楽堂にあつまった数も、どう見ても青が多い。さすがに 4000対600とかじゃないけど、6対4以上で青でしょうか。押しきれる感増します。

今から考えると、これはすでに緑の流す情報に踊らされてたんだなあ、と思います。

試合開始直後

試合始まって麻布十番で反応しないサーバにイライラしながらレゾネーターを挿していたところ、スマフォの画面が緑に覆われました。麻布十番が緑に囲われ、緑に +40%のボーナスポイントがつくということです。その時は、「くそっ、うまくやりやがったな。でもすぐに壊れて、次のラウンドには普通に戦えるだろう」と思ったぐらい。一兵卒としては、全体のことを考えず局地戦に集中するのが最適ですし、目の前のポータルに集中しました。

その10分間の第1ラウンドはポータルを守り切って、ほっとしたところで intel mapをみたチームメンバーから驚嘆の声が上がりました。「日本全部緑になってる!」

その様子はいくつものブログなどで記事になってるので (ingress速報など) 知っている人も多いでしょう。緑が襟裳岬、遼東半島、グアムを結ぶ巨大 CFをつくったのです。東京にいる現地エージェントには手も足も出ません。

巨大フィールド物語

これほどの巨大フィールドを作るには入念な準備が入ります。

リンクを貼るためには、リンク先の鍵準備する必要があります。鍵は人同士が会って受け渡しせねばならず、物理的に運ばねばなりません。このクラウド時代に!!

また、リンク先、元のポータルとも 8本レゾネータを挿しておく必要があります。それが作戦時間に壊れていてはいけないので、敵に壊されないよう維持しなければなりません。さらに長距離のリンクを貼るためには、ポータルのレベルを上げておかねばなりません。今回、襟裳岬にあった レベル7のポータルを作るには最低限 3人その場に集まる必要があります。

そして最も大変なのが邪魔リンクの排除です。Ingressではリンク同士は交差できません。つまり、リンクを張ろうとしている2つのポータルの間に別のリンクを張ってしまえば、リンクを阻止して、フィールドが作られるのを防げます。特に長大なリンクでは間にリンクを挟む場所はいっぱいあります。そこを相手の手を読み合って、世界各地にエージェントを派遣したり、協力したりしてリンクを張ったり壊したりするわけです。

そして、そういった作戦は全エージェントに知らされるわけではありません。味方を混乱させないためもあるし、情報が敵にもれないようにするためもあります。

今回にも実際東京を覆った巨大フィールドの他にもいくつかの妨害リンクとかがありました。もちろん、自分はそれを知ってたわけではなく、終わった後いろいろ情報集めてそういうことがあったんだ、と知ったぐらいです。

青側が行った妨害リンクプロジェクトは LukewarkSAGARAと名付けられていたようです。かっこいい。 そこらへんの情報は Google+ で見ることができます。

https://plus.google.com/explore/LukewarmSAGARA

今見たところ、青側の Kazzy Katoさんのポスト が一番全体像つかめるとおもいます。いろいろ虚々実々の駆け引きがされているのがわずかながらわかります。

潮崎-沖縄リンクについては、リンクを張った青の SolidStakeさんのポストと、それを壊した緑の おさかなさんのポスト がそれぞれの視点で面白いです。

最後に、吹雪の中、襟裳岬までポータルを破壊しにいった青側の英雄 Amacatさんの一連のポスト も涙なしでは読めません。はオーバーにしても、吹雪の中、100km以上のドライブをしてくださって感謝です。

まとめ

巨大フィールドは目につきますが、それだけが敗因だったわけではありません。Volatile portalという高得点なポータルに重点的に戦力を配分するとか、先に書いた情報戦とかいろいろあります。多分、自分がまだ知り得ていない要因もあるんだと思います。

負けた直後は釈然としなかったのですが、こうして情報を集めてみると、自分が知らない中でいろいろお互いにあがいた結果こういう風になったんだなあ、と納得した気分です。緑は、実際に東京では勢力少ないなか、見事な作戦を成功させて勝利をもぎとったことにあっぱれです。悔しいのは変わりませんが。

今のプロジェクトで使ってるライブラリとか

仕事で作っていたアプリがリリース出来たので祝杯を上げながら書いてみる。自己満足的なものです。

そんなに奇をてらってものは使ってないけど、参考になればうれしいっす。

lombok

http://projectlombok.org/

Javaの冗長な記述を Annotationを使って短くしてくれる。Setterとか自動生成してくれて楽。 なによりソースが短いままなのがいい。

GreenDao

http://greendao-orm.com/

Android用 ORマッパーですね。速くて軽いのが売りらしい。 生成したコードも読みやすいので理解しやすい。

Retrofit

http://square.github.io/retrofit/

Squareの作ってくれた JSON APIのラッパーですね。楽ちんです。 でもリクエストのキャンセルとかできなさそう (できるなら教えて下さい)。 もしかして Volley使ったほうがよかったのかなあ、と思いつつも、そこらへんはごまかしながら使ってます。

okhttp

http://square.github.io/okhttp/

Retrofitと組み合わせて使う、HTTPクライアントっす。 ちなみに、テストでは付属の MockWebServer も合わせて使ってる。便利。

ButterKnife

http://jakewharton.github.io/butterknife/

Jake神の作った、Viewの Injectionやってくれるやつですね。素直で便利。

AssertJ

http://joel-costigliola.github.io/assertj/

Assert周りでいいのないかとおもってぶち当たったのがコレ。 コレクション周りの Assertが強力に書ける。

Mockito

https://code.google.com/p/mockito/

前職からのなれでつい。いまとなっては、Captorとかで値を受け取ってもにょもにょする、とか面倒くさいんだけど、そこらへんもっと楽にできるのないのかしらん。

ProgressMenuItem

http://hotchemi.github.io/ProgressMenuItem/

hotchemi さん作の、ActionBarにぐるぐるまわる Progressアイコンを出すためのライブラリ。簡単に導入できました。

Genymotion

超高速エミュレーターですね。これがないと、テストとか面倒くさくてやってられん。

まとめ

そんなところかしらん。 あと、CIは CircleCIつかってます。Buildするたびにテスト結果や Proguardの mapとかを残して置けて便利。

今後は、RxAndroidつかってみたいとか、そんなところでしょうか。

4枚カード問題のわかりにくさ

心理学的な話。

くねくね科学探検日記 の 地頭は存在しない(その1) に、日常的なことには推論がしやすい、という例として以下の話が乗っている:

４枚カード問題というのは、

　机に「Ａ」「Ｋ」「５」「８」と書かれた４枚のカードが並んでいる。 　この４枚において「カードの片面に母音（Ａ、Ｅ、Ｉ、Ｕ、Ｏのどれか）が書いてあれば、裏の数字は必ず偶数」という法則が成り立っていることを確かめるには、最低限、どのカードをひっくり返せばいいだろうか？

という問題と、

片面に酒を飲む人とお茶を飲む人の絵が描かれ、その裏にはそれを飲む人の年齢が印刷されている。そんでもって、「16歳」「40歳」「お茶を飲む人」「酒を飲む人」の４枚のカードがあるとしよう。このカードが「18歳未満の飲酒は禁止」というルールに違反していないかどうかを調べるには、どのカードを裏返せばいいか。

という二つの問題を比べると、論理構造は全く同じなのに、後のほうが圧倒的に簡単ってものだ。

でも、これは日常的だからわかりやすいんじゃないんじゃないか。論理構造が (脳みそにとっては) 違うだけじゃないか。 例えば、最初の4枚カード問題を以下のようにしてみる:

　机に「Ａ」「Ｋ」「５」「８」と書かれた４枚のカードが並んでいる。 　この４枚において「母音（Ａ、Ｅ、Ｉ、Ｕ、Ｏのどれか）のカードの裏の数字は奇数であってはならない」という法則が成り立っていることを確かめるには、最低限、どのカードをひっくり返せばいいだろうか？

こうすれば、正解の「A」と「5」を出すのが簡単になるのでは。実際に実験したわけじゃないので確信はないけどそういう気がする。いや、俺がこの問題を考えすぎて変になってるかもしれないけど。

つまり、日常的な問題だから考えやすいんじゃなくて、ルールが否定形 (「してはならない」) だからわかりやすいんじゃないか。抽象的な問題でも、そう考えればきっととけるのでは。

あと、個人的な感想として「母音のカードの裏の数字は奇数ではない」というルールにすると、また少しわかりにくくなる気がする。要は人間は「してはならない」という禁止の形に素早く反応するようにできているのかもしれない。

ここらへん、実験した人いないのかなあ。