2015年7月31日金曜日

新MOVERIOな日々

記事タイトルは、大昔に使っていた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の消費電力を計測するところからスタートしたほうが良いかもしれませんね。参考(同僚がやっていた電力計測方法とその発表資料):

48日後…

思えば、あと1ヶ月半でモニター期間が終わります。作りたいアプリのネタはいくつかあるし、作りかけなので、形にしていきたいところです。
ざっくりと書いておくと、以下のエリアに興味を持っているのでそのへんをやります。
  • タスク管理やライフログに使ってみたい(せっかくGPSあるし、登山用のレコーディングにも一定使ってみたさがある。この場合は省電力追求がキモ)
  • Mac/Windowsから遠隔で入力を受け取れるようにしたい(adb無しでなんとかしたい。アプリ側に対応用SDKを用意するでも良い)
  • Android 4.0でMiraCastサポートしてるという特性を活かしたい気もする
  • Unity以外の環境からも3D触りやすくしたい
まずは、再来週に登山予定があるので、そこで何かしら使ってみようと思っています。取り急ぎ、乱視用コンタクトレンズを試用する手配をおこない始めました。
28日あれば世界が壊滅してることだってあるんだから、48日もあれば何かできるでしょう(慢心)。

2015年7月27日月曜日

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

入手から丸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を叩くぐらいが無難かなーという感じがしています。

2015年7月4日土曜日

Azure上のUbuntuにデスクトップ環境を整えてAtom+language-reviewを試す

どうもLinux環境のAtom+language-reviewで動作に怪しい箇所がちょいちょいあるらしいという電波を受けたので、環境を作ってみました。
完成図はこんな感じです(図1)。
図1 今回の完成図
手元のPCにUbuntu Desktop版を入れるのは嫌だなぁと思ったので、Azure上にUbuntu 14.04のインスタンスを新規に立てました。

2015年6月22日月曜日

OS Xで退席時に画面表示を消してバッテリ消費を削る話

Macを使っていて、退席時にホットコーナーを使ってスクリーンセーバー起動するという流れ*1でずっと使ってきたのですが、新MacBookを使うようになってから気になっていることがありました。
スクリーンセーバー、やたらMacが熱くなるしバッテリ減るのです。まあ考えてみると無駄にグラフィック描画をしているので無理もありません。
何かまともな方法無いかなーと考えて探してみた話です。
スクリーンセーバーの選択肢に黒背景表示(あるいは白背景表示)のみ、とかがあると良いかなーと思いましたが、探した限りは見つかりませんでした。
何か方法あるのでは、と思って少し調べてみるとOS X Mavericks: スクリーンセーバの入/切を切り替えるというエントリが見つかりました。
が、単純にホットコーナーの扱いについて書いているだけでした。
Turn Screen Saver Offというのがそれかなーと思い、試してみたのですが 特に効果ありませんでした。
できないのかなー、めんどいなーと思いながら、もう少しメニューを眺めたところ
図1 ホットコーナーの設定画面
一番下にPut Display to Sleepというのを見つけました(図1)。
これだ!と設定してみると、案の定画面端へマウスポインタを持っていくことで画面がオフになるようにできました。
適当にトラックパッドを叩くとスクリーンセーバー復帰と同様に画面が戻ってくるので、あってほしい挙動です。
OS Xよくできてた。
[*1] WindowsだったらWin+Lを叩いて退席するやつですね

2015年6月21日日曜日

弱Vim使いが中途半端な予備知識でGoを書き始めたら

ぬるま湯Vimおじさん

私は、自分が離れたプログラミング環境を忘れるのがとても早いです。VimでPHPコードをひたすら書いていた時期もあって、その頃はctags連携とかいろいろやっていた気がしますが、今では何一つPHPについて思い出せません。
Vim自体の使い方にしても、タブは使うけどウィンドウ分割は全然使わないという生活をしていた結果、C-w jhklC-w C-wすらすっかり忘れてました。思えばこの数年、vim -pでぶわーーっとタブを開いて、あとはほぼgtしか使わない生活でした。とりわけ、Mac上では割とMacVimも多用しているため、ウィンドウ移動をトラックパッドでまかなえるという事情もありました。
そんな私、実はgolangを勉強しては少々離れている間に忘れる、というループを既に数回繰り返しているので、今度は特に開発環境面のメモを残しながら進めてみようかと思って書いてみました。

2015年6月20日土曜日

Unreal Engine 4 ビデオチュートリアル記 #5

前回: Unreal Engine 4 ビデオチュートリアル記 #4
前回はベルトコンベア作りだった。
やっている時には結構つらいと思ったけれど、振り返ってみると辛かったのは慣れが剥落してUI体系を触り直しになったあたりで、やっていたことはシンプルだった。
コライダーで見つけた対象へと適切に力を加えるという話だった。
今回でBlueprint Jump Startsシリーズは終わり。概要によると「ゲームの機能群をモジュール化されたBlueprintableなコンポーネント群へと切り分ける方法を紹介する」ものということ。

Blueprintableコンポーネントでゲームの振る舞いを構造化する

Using Blueprintable Components for Game Behavior

18分ぐらい。
今回は、これまでのものとは趣が違った。ゼロからハンズオンやっていく形ではなく、ワークフローを観て学ぶ感じだった。
UE 4.7以上でメインとなったBlueprintable Componentsについて。UnityのPrefabみたいなやつ。
ステージ上に配置したオブジェクトにスプライトや既存のBlueprint群を割り当てていき、それを再利用可能なBlueprint Classへと変換するのが前半のところ。
変換後のものを編集するためには、他のBlueprint Classと同様に一旦BP Editorで開くことになる。
当然のようにサブコンポーネントとなったBPが変数としてエクスポートしているものはUEのレベルエディタ側で編集できる。

感想

「UnityのPrefab、UE4ではどう扱うんだろう?」と思っていたところの実際の動きを眺めながらふんわり掴めるので良いチュートリアルビデオだった。
なお、前回の最後に書いていた動画再生とUE4操作のバランス取りについて、今回は実際に手を動かして編集するフェーズがなかったので次回へ持ち越し。

2015年6月18日木曜日

夏コミ(C88)原稿を書き始める、その前に

進捗どうですか

技術系サークルの皆さまこんにちは。夏コミ原稿書いてますか?
私はまだです。
文章を書く心構えや書き方という話については他の人々が書いている技術的な文章を書くための1歩、2歩、3歩技術的な文章を書くための第0歩 ~読者に伝わる書き方~を読んでもらうとして、ここでは文書フォーマットとエディタについて書きます。
文章を書く際にフォーマット選びは重要です。
私はこの2年ぐらい、雑誌原稿や技術同人誌、書籍原稿など技術系の文章に関わる際には多くの場合Re:VIEWというフォーマットで書いてきました。

Re:VIEWというフォーマット

Re:VIEWをご存知ない方も多いかと思います。ここでは簡単に紹介します*1
「Sphinxでよくね?」という方は多分それで良いので、タブを閉じて原稿へ戻りましょう。原稿しろ。
「Wordでよくね?」という方、一人で作業してかつレビュアーも立てない場合にはそれで良いので、タブを閉じましょう。原稿しろ。
複数人で分担して書くサークルや、書いたものを誰かにレビューしてもらうような場合は、原稿を書く前にもう少しお付き合いください。
Re:VIEWは、Markdown(含GitHub-flavored)よりもしっかりとした構文を持ち、入稿用PDFなどを比較的作りやすい、技術文書に適したプレーンテキストフォーマットです。
@kmutoさん、@takahashimさんを中心に、オライリー・ジャパン刊の書籍/電子書籍や達人出版会刊の電子書籍の執筆にて多くの利用実績があります。
多分Sphinxに近い立ち位置だと思っていますが、なにぶんSphinxについてほとんど知らないのでイメージだけです。
個人的には
  • 技術文書でよくあるレイアウト面の需要にほどよく応えてくれる程度に表現力のある構文
    • 行番号付きリストとか、コマンド入力ブロックとか、図版の番号振りと参照自動更新とか、章/節間の参照とか脚注あたりが特にラクで良いです
  • PDF、HTML、EPUBへの出力がサクッとできる点
  • Wordよりもdiffを確認しやすい点
    • GitHubのprivate repoに原稿を置いて、コミットされたRe:VIEWのファイルをピアレビューしたり、原稿のpushをトリガーとしてPDFの自動ビルドをおこなっている同人サークルもあると聞きます
  • 適当にフィルタしてざっくり情報を拾い出すのが簡単な点
    • 表記ゆれを疑った時に雑にgrepで確認できるのはとてもラクです
が気に入っています(手軽さの面では確実にMarkdownへ軍配が上がります)。
他にもメリットは多いのですが、そのあたりの一部はblogをRe:VIEWで書くことを考えるを参照してください。
ちなみに、このblogもRe:VIEWで書いて(図1)HTMLへ変換したものをBloggerへ流し込んだものです。
図1 Re:VIEWで書いたblogの原文
Re:VIEWの基礎から同人誌作成向けのtipsもまたRe:VIEWで書かれたものがあります(FirstStepReVIEW)。私は執筆に関わっていませんが、良いドキュメント(今でもたまに読み返します)なので気になった方は読んでみてください。はじめてのReVIEWでダウンロード販売もされていますね。
さて、あるフォーマットで文章を書く際に環境は重要です。
[*1] Re:VIEWはやっぱりぐぐらびりてぃが低いので、詳細は「kmuto review」でぐぐるのが定番です。

文章を書く環境の重要性

しばらく前まで、私はRe:VIEWでの文章作成にMacVim+Vim用シンタックスハイライト+保存時フックでのHTML出力(自前)+Firefox(HTMLプレビュー用)を使っていました。
しかし、ここ半年ほどはAtomとAtom用のRe:VIEW構文サポートパッケージであるlanguage-review(@vvakame作)を使っています(図2)。
図2 Atom+language-reviewで文書編集している様子
リアルタイムにRe:VIEWの文法違反を指摘してくれる点、各種インライン構文の自動補完をほどほど賢くやってくれる点、右ペインに文章のプレビュー表示をおこなってくれる点が特に気に入っています(図3)。Atomをインストールしていればパッケージ一覧画面からlanguage-reviewと叩くだけでインストールできてお手軽ですしね*2
図3 Atom+language-reviewがLintをかけてくれるところ
[*2] コマンドラインからは適当に apm install language-review で入るようですね

環境に手を入れられることの重要性

Atomは「21世紀の、ハックできるエディタ」を標榜するだけあって、かなり深いレイヤまで簡単にソースコードを追えます。
そして、language-reviewはオープンソースで開発されていて、誰でもソースへアクセスできます。
私も、しばらく前からlanguage-reviewの中身を調べ、手を加えてはPRをこさえるようにしています。この話は長くなるので別のエントリにまとめますが、いじるの自体がなかなか楽しく、そして実用的という一粒で二度美味しい感じです。
まずは使ってみて、なんじゃこりゃーーーーと思った箇所についてはぜひissueを立ててください。きっとよくなっていきます。

そういうわけで

楽しい原稿ライフを!