muo-notes

新MOVERIOな日々

2015年7月31日金曜日

記事タイトルは、大昔に使っていたHyperhyde ExrougeというIOデータのMP3プレイヤー(通称ポケベル)の界隈で有名だった方のblogタイトルのオマージュです。わかりづらいですね。
さて、2015/03/17におこなわれたEngadget・エプソン主催のMOVERIO体験会へ参加し、MOVERIO(BT-200AV)を6ヶ月間の無料モニターとして借り受けました。本記事は、無料モニターとその関連記事です。
この1ヶ月間は、MOVERIOをケースへしまいこんで触らない日々でした。なぜでしょう。

なぜ1ヶ月間触らなかったのか

MOVERIOがないと困るか、と言われるとそんなことはありません。常用しているスマフォがあれば事足ります。しかし、それは最初から分かっていることです。
一方、MOVERIOがあったほうが嬉しい/楽しいか、と言われると、やっぱり楽しいです。
つまり、そもそも現時点のMOVERIOに高い実用性を求めているわけではないので、触らなかった理由はそれ以外にあるはずです。以下では、この理由を考えた際に思い当たったものをいくつか挙げてみます。

利用機会

日常の中では移動時に使い、それ以外ではなにかのイベントのタイミングで使うイメージです。
Android系のイベントへ出かけていく際に持っていくと少し良い感じですが、気付いたらABC 2015 Summerが終わっていたので、機を逸した感です。多分、ABCへ行っていたら持って行っていました。
利用機会の多寡は生活パターンや原稿進捗の影響を受けやすいので、今月については仕方ない感でした。

視力

Oculus Rift DK1/2やGear VR、それにMeta 1を触った際にも感じて、薄々やばいなーと思っていたのですが、ゴーグル系のものは乱視との相性がとても悪いです。物理的に60cm先のディスプレイで黒背景白文字が表示されていても特段問題なく読めますが、MOVERIO上のKindleで読書をおこなっていると文字周縁ボケによる目の疲れを強く感じます。このあたりを考えると、動画をざっと眺める用途やTumblrの画像系未読をひたすら消化するような用途が向いていそうです。
私はこれまで視力矯正手段のお世話になったことはない(JINS PCほか、度なしの眼鏡を除く)のですが、MOVERIO+Kindleの本来の実力を知るために、そろそろ使い捨ての乱視矯正用コンタクトレンズを一度試してみようかな、という気持ちが湧きました。

季節要因

目の周りを覆う端末という特性上、季節要因を(主に悪い方面へ)受けやすいです。

梅雨は端末を濡らしたくないので留守番させがちになる
夏は暑いので留守番させがちになる

用途を掘ってみる

使わなかった理由を考えた結果、特にMOVERIOに対するがっかり感のようなものは湧いてこなかったので、この先はどういう用途を掘って、実現していくかという話になります。
基本的にアクティブな操作をする用途には向いていないので、「多めの情報から、自分に必要な情報を拾いだして何かしら軽いアクションをする」用途に振るのがよさそうです。
たとえば

移動中のソーシャルなフィード消化(Facebook、Twitter、Gmail、ChatWork、Slack)に特化
- これこそスマフォで良い気もする
移動中の動画フィード消化に特化
- (その昔、はてなが運営していたRimo.tvというのがイメージ近いかもしれない)

このへんでしょうか。時計系の端末でひたすらソーシャルなフィードを消化するというのはそもそも全てが間違っている感じですが、MOVERIOは「全数消化」向きだと感じます。あまり読まないメルマガをぽちぽちアーカイブしたり、ChatWorkの未読チャット数を0にしたり、GitHubのコミット通知やPR通知を読んでToDoへ雑に突っ込んだり、といったPCでおこなう作業を代替できそうな気がします。
しかし、やはり「それ普通のスマフォでよくね?」と感じます。普通のスマフォのほうが複雑なアクションをおこなえますし。
そうなると、ニコ動の積み動画をMOVERIOで観ながら普通のスマフォでソーシャルなフィードを消化するのが最強ということになって、実際そのへんが実用上の落とし所かなーと感じます。EPSON自身がTwonky Beamにある程度の力を入れているのもそういうことでしょう。
個人的な欲としては、ニコニコ動画のお気に入りユーザの新着動画などを移動中に消化したい感がありますね。
これ以外では、あまり実現可能性を調べていませんが登山のお供としてGPSレコーダ利用できるかが気になっています。MOVERIOの挙動的に、画面をオフにするとあまり時間を置かずにバッテリ節約モード(スリープ状態)へ落ちます。そうなると、この状態から定期復帰(1分ごとなど)させるのは割とつらそうです。
しかしMOVERIOは電源ボタンのスライドでスリープに落とした時と端末の右側をトントン叩い(ミュートノック)てAVミュートへ落とした時で挙動が異なっていて、後者の場合はスリープしません。これをうまく使うと、そこそこ消費電力を抑えつつGPSロガーとして使い、時折視界に情報をオーバーレイ表示するという使い方ができるかもしれません。
スリープ時にはWi-Fiも切断されるのですが、AVミュート時には電波出しっぱなしになる(バッテリを使い続ける)ので、何かしら制御はしたいところです。
GPSの精度と消費電力についてもある程度の厄介さがあります。過去経験上、2013年前後のAndroid端末でGPSまわりの良い思い出がないので、MOVERIOのベース端末世代を考えると結構厳しいのではないかと。これについては、iPhone 5sのM7を活かして「iPhoneでGPSその他周辺環境ログを取得。データは定期的にMOVERIOへ投げるか、スリープからの復帰時にまとめて送信。MOVERIOはビジュアライズに専念」という策もありそうです。
これと直接はあまり関係ないのですが、AVミュート中に本体側の物理ボタンを押すと復帰してくる挙動が微妙に気に食いません。しかしデフォルト挙動としては正しいですね(インジケータは水色になってるけどディスプレイがつかない! 故障?? となる)。欲を言えば物理操作ロック用のスライドボタンがあると最高ですが、まあないでしょう(せいぜい、メニューでの提供かなぁ)。
この方面での実用性を考えていく場合、まずはMOVERIOの消費電力を計測するところからスタートしたほうが良いかもしれませんね。参考(同僚がやっていた電力計測方法とその発表資料):

Droid kaigiプレゼン from Suguru Oho

48日後…

思えば、あと1ヶ月半でモニター期間が終わります。作りたいアプリのネタはいくつかあるし、作りかけなので、形にしていきたいところです。
ざっくりと書いておくと、以下のエリアに興味を持っているのでそのへんをやります。

タスク管理やライフログに使ってみたい(せっかくGPSあるし、登山用のレコーディングにも一定使ってみたさがある。この場合は省電力追求がキモ)
Mac/Windowsから遠隔で入力を受け取れるようにしたい(adb無しでなんとかしたい。アプリ側に対応用SDKを用意するでも良い)
Android 4.0でMiraCastサポートしてるという特性を活かしたい気もする
Unity以外の環境からも3D触りやすくしたい

まずは、再来週に登山予定があるので、そこで何かしら使ってみようと思っています。取り急ぎ、乱視用コンタクトレンズを試用する手配をおこない始めました。
28日あれば世界が壊滅してることだってあるんだから、48日もあれば何かできるでしょう(慢心)。

MacBook Early 2015をプログラミングに使うための軽量化tips

2015年7月27日月曜日

入手から丸3ヶ月経ったところで、前回(Retina MacBookを使い始めて2ヶ月近く経ったので実用性などをまとめてみた)からの差分です。重めの開発系作業をほとんど捨てる想定でMacBookを買ったのですが、結果いろいろあって日々プログラミングに使っています。圧倒的CPU不足というほどCPUが遅いわけでもないので、「中途半端になんとかなる」のがイマイチです。こういう状態だと、各所の微妙な遅さの影響が最終的にとても大きく効いてきます。意識して日々の作業ボトルネック解消に努める必要があります。
今回はMacBookを使った日々のプログラミング作業を効率化するためのtipsをいくつか紹介します。まあ、あれこれ言いつつ単なる今月のMacBook日記です。

Xamarin Android Playerの壁紙を変えてCPU消費を手軽に低減する

Androidアプリの開発にあたっては、Xamarin Android Playerが割と良いスピードで動くため、好んで使っています。しかし、これなかなか重量級です。速いといっているのに重いとはどういうことか、という感じですが、要はスタンバイ状態でのCPU消費が激しいのです。
エミュレータ起動後、内部の初期化が一段落ついたタイミングでのCPU消費は図1のようになります。

図1 Xamarin Android Playerのスタンバイ時CPU消費

何もしていない状態でも22%を切ることはほぼありません。CPU消費の主要部分はVirtualBox側でおこなわれているので、Xamarin Android Playerのウィンドウが背後に回っていても特に軽くはなりません。この状態で、MacBook自体も徐々に熱をもっていきます。夏には辛い感じだし、バッテリ稼働時間も縮むのでイマイチです。
あるとき、しばらくCPU消費状況をボーっと眺めて、「これ、Live Wall Paper(ライブ壁紙)のアニメーションをCPUでひたすら頑張って重いのでは?」と思いました。そこで、壁紙の設定を図2のように変えてみると、

図2 Xamarin Android Playerに壁紙を設定する

図3 Xamarin Android Playerにライブでない壁紙を設定した

見事にスタンバイ時のCPU消費率が2.8%程度まで下がりました(図3)*1。これで日常的に使っていると、明らかに発熱が少ないのを感じます。

[*1] アクティビティモニタ上で2つのVBoxHeadlessがみえるのは、Xamarin Android PlayerのものとDocker用のものです。Docker用のものはスタンバイ時CPU消費率が安定しているので、切り分けて考えました。

Docker利用にはdocker-machine+VMware Fusionを使う

Web系に限らず、最近はDockerを使うことがとても多いです。遠隔地のサーバ上での利用はもちろんですが、ローカル環境に比較的高速に動作するDocker環境があると便利なシーンもあります。
そういうわけでMac上では通常boot2dockerを使ってVirtualBoxベースの仮想マシン上にDockerホストを持ちます。
しかしこのVirtualBox、ホスト側とのディレクトリ共有におけるI/O性能が今ひとつ高くありません。
ここで登場するのがdocker-machine+VMware Fusionです。docker-machine自体はboot2dockerの派生物のようですが、様々な面で強化されています。VMware Fusionとの連携サポートもそのひとつで、dockerの--volume(-v)オプションを使ってホストマシンとDockerホストとのデータ共有を簡単におこなえます。
VMware Fusion本体部分のCPU利用効率の良さ*2に加えて、VMware Fusionの共有ディレクトリもそこそこ高速です。手元での多少極端な例ですが、1回のプログラム実行で1,000ほどのファイルを読み込むケースがあるものでの動作速度が20倍ぐらい速くなりました。このように、VMware Fusionの利用はCPUの非力なMacBookでもパフォーマンスの底上げと消費電力低減(=バッテリ持ちの改善)に役立ちます*3。
もちろんVMware Fusionは有償のプロダクトなので、コスト負担するか否かという選択があります。私の場合は、以前利用していたMacBook Proでの作業用に購入したライセンスが宙に浮いていたので、これを活用しました。
おまけとして、boot2dockerとdocker-machineでの簡単なコマンド対応付けを記載します。ここではdocker-machineで作成するVMの名前をdevとしています。

Dockerホストイメージの作成
$ boot2docker init
$ docker-machine create --driver vmwarefusion dev

Dockerホストの起動
$ boot2docker up
$ docker-machine start dev

VM上のDockerホストに割り当てられたIPアドレスのチェック
$ boot2docker ip
$ docker-machine ip dev

dockerコマンドからの接続用シェル変数設定
$ eval "$(boot2docker shellinit)"
$ eval "$(docker-machine env dev)"

Dockerホストの停止
$ boot2docker down
$ docker-machine stop dev

docker-machineは複数のDockerホストを管理する前提で作られているので、管理下のDockerホスト一覧機能などもあります。

$ docker-machine ls
NAME   ACTIVE   DRIVER         STATE     URL                         SWARM
dev             vmwarefusion   Running   tcp://172.16.142.128:2376

という感じです。管理下のDockerホスト同士でファイルをscpする仕組みなどもあって、なかなか面白いのですがまだあまり使っていません。Docker Hub無しでdocker buildコマンドに食わせる設定データをやり取りしたい場合などに便利そうですね。

[*2] 手元環境でざっくりとアクティビティモニタを眺めた感じでは、VMがスタンバイ状態にある時のCPU利用率がVirtualBoxよりもVMware Fusionのほうが結構低いものでした。

[*3] VirtualBoxベースのboot2dockerを利用していると、Macのスリープを挟んで別のネットワーク環境へ移動後に作業を再開した直後にOS Xを巻き込んでクラッシュする不具合に行き当たることも多かったので、これも乗り換えの強い理由でした。

nodebrewではバイナリ利用オプションを使う

大きめのアプリをソースからインストールする行為は、回数少なければ良いのですが日常的にやるのは避けたほうが良いです。とくに、Node.js/io.jsのアップデートのような頻発作業はバイナリを選ぶのが無難です。

$ nodebrew install-binary <インストール対象>

これは、前回のポエムを書いた後で@vvakameが教えてくれました(一応前回のポエムに追記もしました)。

Re:VIEW原稿書きの校正フェーズではAtomのlanguage-review適用を外す

これはプログラミングに直結するものではありませんが、関連作業として記載します。だいたい日本語テキストが500行を超えてくると、Atom+language-reviewの動作速度が結構辛い感じになってきます。校正フェーズはVimでやるとか、ファイル自体を分割するというのも手ですが、そうしづらい事情(例: 迫り来る締め切り)があればひとまず Atomの右下にあるステータスバーからRe:VIEWの指定を外してPlain Textに変えましょう。サクサクになります。language-review自体に、シンタックスハイライトのみをおこなう軽量モードがあるとよさそうですね。

C++コードのコンパイルにはccacheを活用する

Clangがあればccacheなんて不要!と思っていた時期があったのですが、大きめのC++プロジェクトを頻繁にビルドする際には、やはり相応に有効です。もちろん、コードのビルドでどっかミスるのではないかという一抹の不安はあるので、いわゆる本番用ビルドには利用しないようにしています。ccache自体についてはあちこちに解説があるのでそちらをあたってください。Android NDKでもばっちり使えます。

未解決の課題

Javaコード類のビルドがやたらと遅いのは依然として未解決です。distccあるいはccacheのような仕組みが欲しい…。Mac上のEclipseやIntelliJ IDEAから接続して使える、Android用にも使えるいい感じのJavaリモートビルドの仕組みをご存知の方がいれば教えてください。JRebel for Androidが用途的にはそのへんなのかなぁ。
今のところ、手近なDockerマシンにソース差分をrsyncしてGradleを叩くぐらいが無難かなーという感じがしています。