2015年8月1日土曜日

進捗yabai勢に贈る圧倒的進捗術

原稿書いてますか?入稿間際ですか?このエントリを読んでるということは、あんまり進んでませんよね?

SNS=進捗の敵

SNSは割り込みの宝庫です。シンプルに言って進捗の敵です。
原稿をぼちぼち書き上げ(描き上げ)ないといけないのに今ひとつ進まない。進まないなーと思ってやる気を出すべくSNSを眺める。気付いたら数十分経っている。進捗やばい。焦る。進まない。こういうループはありがちです(特に、内容やクオリティ的にギリギリを攻めるほど)。
私がほぼ常時開いているSNSはこのへんです。
  • 私用のGmail(Hangouts含む)
  • 仕事のGmail
  • Facebook
  • ChatWork
  • Slack(2つ)
さて、ここでは人のアクションをストリームあるいは比較的手軽なポーリングで得られる仕組みは全部SNSと括ります。ChatWorkは、その特性から言って完全にSNSです。人によってはpixivやニコ動、Instagram、Tumblrも含まれるでしょう。なお、仕事中に私用のGmailやFacebookを開いていたり、仕事外でChatWorkを開くことに関する突っ込みは一定あると思いますが、まあそれはそれとします。
インターネットアクセスがあるかぎりSNSへアクセスするのは仕方ありません。しかし、作業に集中したければSNSをごっそり落とすしかありません。
SNSを落とすといっても、各所のサーバへアタックするのはいけません。各種サービスを頻繁に開いたり閉じたりするのも、ずいぶんと時間の無駄です。ウィンドウを分けてSNS系を片方へ仕分けするというのもアリですが、試してみるとイマイチ脳内の分離にはつながりません。
そういうわけで、メインのWebブラウザと、SNS類専用のWebブラウザを分けます。

SNS専用Firefoxの作り方(Mac用)

基本的に、標準機能を組み合わせて実現します。
Firefoxは、そうとう昔からマルチプロファイル利用をサポートしています。これを使ってメイン利用のブラウザとSNS専用のものを切り分けます。

FirefoxにSNS専用プロファイルを作成する

まず、Firefoxを一旦落として、ターミナルから
open -n -a Firefox.app --args -P
と叩いて実行します。
すると、あまり見慣れない(かもしれない)Firefoxのプロファイル選択画面が開きます(図1)。
図1 プロファイル一覧画面
通常はdefaultというプロファイルしかないはずです。こ左側の「新規プロファイルを作成…」からcommuという名前のプロファイルを追加します(上記のスクリーンショットは、追加後のものです)。
作成したら、「今後このプロファイルを使用する」のオプションを外して実行します。
以下、これをSNS専用のブラウザとして仕上げていきます。

SNS専用Firefoxに最低限の設定をする

新たに作成したプロファイルを指定して起動すると、メインブラウザの設定類が一切引き継がれない状態で起動します。これは重要ポイントです。あまり便利にしすぎると、SNS専用ブラウザを終了するモチベが湧きにくくなるため、「ほどほど不便な状態」にするのが大切です。
SNS専用ブラウザの設定事項は、以下をオススメします(図2)。
  • 一般→Firefoxを起動するとき: 「前回終了時のウィンドウとタブを表示する」
  • 一般→タブグループ: 「タブが選択されるまでページを読み込まない」をオフに
図2 SNS専用Firefoxの設定

SNS専用Firefoxを簡単に起動できるようにする

SNS専用Firefoxは、ほどよく楽に起動できる必要があります。これはAutomatorで実現します。
まず、SpotlightにAutomatorと打ち込んでAutomatorを開きます。
新規ドキュメントを作成し、図3のようにシェルスクリプトの実行ジョブを追加します。
図3 SNS専用Firefoxを起動するAutomator設定
ここで、ジョブの中身には
open -n -a Firefox.app --args -P commu
と書きます。
これをドキュメントディレクトリ以下に保存します。私はFxCommuという名前で保存しました。

起動確認

さきほど作ったAutomatorの実行ファイルをFinderから実行してみます。うまくいけばSNS専用のFirefoxが表示されます。うまくいかなければ何か設定を失敗しているはずなので、見直してみてください。
もしうまくいかず、時間がもったいないことに気付いたら、落ち着いて原稿へ戻ってください。多分、トラブルシュートしている時間はないはずです。
うまく起動できたら設定はほぼ終わりです。ここでやったようにFxCommuという名前にしておくと、通常SpotlightやAlfredの検索からFxまで叩くとSNS専用Firefoxを開けるので、ほどほどに便利です。

SNS専用Chromeの切り分け方(Mac用)

Chromeでも多分似たようなことはできます。が、私はほぼFirefox使いなのでChromeでの手順は調べていません。読みたいという人が居れば追記するかもしれません。

進捗圧をかけるための仕上げ

私の場合、不幸なことにWebブラウザを開いていると、アドレスバーへ移動してKDDI ChatWorkのURL冒頭であるkcwと叩いてしまう癖がついています。fと叩いてFacebookを開くことも多いです。
これを逆手に取り、メインブラウザ側で以下のような設定をします。
RedirectorというFirefoxアドオンがあります。これは、ブラウザで開こうとしたURLのうちで、特定のパターンに一致するものを他のURLへとリダイレクトするものです。
これをインストールし、図4のように設定します。
図4 Redirectorでの強制リダイレクト設定
ここでは、リダイレクト先のURLをすべてomnifocus:としています。これは、タスク管理ツールのOmniFocusをアクティブ表示させるものです。なお、Facebookについては、各所に仕込まれているいいねボタンがごっそり引っかかるのを避けるために、*://www.facebook.com/plugins/*を除外URLにしています。
このように設定すると、メインのブラウザでGmail/Facebook/ChatWork/Slackあたりをうっかり開いたら、OmniFocusがフォアグラウンドへ出てきて進捗的なダメージを受けます。結果、作業が進みます。
リダイレクト先としてのomnifocus:設定は、OmniFocusをインストールしている人限定のものです。例えばWunderlistをタスク管理に使っている人やRemember the Milkを使っている人は、それぞれのURLをリダイレクト先に指定すると良いでしょう。

以上、あとは進捗するだけです

圧倒的進捗意識を持って進捗しましょう。

Twitterは呼吸である

ここまでで言及していませんが、TwitterはSNSというよりも呼吸なので専用クライアント(夜フクロウ)を常時開けっ放しです。多少は時間を持っていかれますが、いろいろ試した結果として「Twitterクライアントを切っていたほうが結果的に生産性が下がる」ことが分かっているのでこのままにします。

効能(個人差があります)

この方法を運用し始めてから数日間での所感を書いておきます。

FxCommuを開く回数はさほど多くない

完全起動(全タブの読み込み完了)までに15秒程度はかかるため、「見たいと思った瞬間に見れない」ことになります。
見たいと思った瞬間から概ね6-7秒も経てばあまり見たくなくなるので、起動中に欲望のピークをすぎることになります。この時間が体感として身についてくると、自然とSNSを開こうと思うケースが減っていきます。
なんか禁煙治療みたいですね(知りませんが)。

URLフィルタパターンについては考慮の余地あり

時折、Facebookのウィジェットを埋め込んでいるようなサイトへアクセスするとおもむろにOmniFocusがポップアップしてきて「ファァァ」となりますが、まあさほど頻度が高くないので許容しています。
この方法だと、Facebookログインを利用するサイトも軒並み使えなくなるので、少々面倒な感じがします。今のところFacebookログインが必要な場合はSNS用Firefoxを開くようにしていますが、利便性的には適切にホワイトリストをメンテしたほうがよさそうです。

もう少し通知を増やしても良いかも

私はこれまでモバイル側の通知をごっそりと切るようにしていたのですが、この仕組みの確立によってSNSにかける時間の比率がほどよく下がってきたので、この先はもう少しだけ通知を増やし、ChatWorkやSlackで自分へToが飛んできた場合のみモバイル端末へ通知を飛ばしても良いかな、と思うようになりました。

懺悔

これ気付くのがもう2週間早ければ、締め切り守れたと思うんですよね(ぷるぷる)。けれど、導入しなければ多分原稿落としてたと思います。
それでは、よい原稿ライフを。

ソフトウェア開発者のFPGA入門 補足ノート1


の資料を補足するシリーズです。
途中でやったことや、参考情報を書いていきます。割と個人的メモです。

作りたいものがあるのは大事

まず、心構え的なアレですが、すぐに具体的なものが浮かばないにしても、「こういうジャンルのものを作りたい」ぐらいはあったほうが情報収集についても何にしても良さそうです。
私の場合はWebサービスやゲーム系のサーバサイドでFPGAを利用して何かできないかなーという興味が軸です。

FPGAを勉強し始める前段階


ハードウェアとソフトウェアの真ん中あたりへ攻めていくにあたり、ソフトウェア方面から来た人間には明らかにハードウェア方面の常識が不足しています。まずはこれを補っておいたほうが後がきっと楽です。
そういう場面で読むべき本として、「CPUの創りかた」は完全なる名著です。発刊から12年近くが経った現在でも売れ続けていることから分かるように、とても良い本です。私の場合は、元々ハードウェア系にとても弱いので、この本を何度か読んでからFPGAの領域へ来ました。

第0歩の直前: XilinxかAlteraか

そこそこの評価ボードを入手しやすく、開発キットをしっかり提供しているベンダーはXilinxとAlteraの2強です。FPGA自体の実装アーキテクチャは異なりますが、VerilogやVHDLで記述した定義をFPGAへ落として実行し、デバッグなどもできるという面ではあまり変わりません。
私の場合は、うっかりと両方のボードが手元にあります(当初購入したAlteraのチップを搭載したDE0というボード、そしてARMコアとFPGAのハイブリッド構成という楽しさに釣られて購入したXilinx系のMicroZed)。
評価ボードがない状態でもひとまず開発ソフトをダウンロードして試すことはできるので、ひとまず両方触ってみましょう。といいたいところですが、FPGAの開発用IDEはとにかくメニュー構造もワークフローもソフトウェア系と違ってなかなかに複雑です。しかも、XilinxのIDEは割と最近(といっても2-3年前ですが)にフルリニューアルし、過去版(ISE)に基づいたblogの入門記事類がごっそりとdeprecatedになっています。「どうせEclipseベースだから、触ればなんとかなるだろ」と思ってむやみに触り始めると心折れます。私は折れました。
まあ、AMD派?Intel派?という感じのふわっとした感じで適当に決めれば良いと思います。個人的印象では、Xilinxのほうがオンラインドキュメントが膨大にあってIntel風味なので好みです*1。x86 CPUベンダーと違って、「どちらのほうが比較的安い」みたいなのは無い気がします。
AlteraとXilinxどちらにするか決めたら、まずは安めのボードを物色します。雑誌付録にFPGAがついていたこともありましたが、最近は見かけないので えいやっと買ってしまうのが手っ取り早いです。
面白そうなボードや、入門の道を誰かが切り拓いてくれているボードがあれば、それに乗っかるのも良いと思います。今なら、$30で始めるFPGA(竹村さんの資料)に従って進める想定でBeMicro Max10 FPGA EvaKitあたりを買うのが楽なのではないでしょうか。ちなみに、これを買うとAltera閥へ入ることになります。おめでとうございます。
[*1] あっ、Intelが最近Alteraを買収したので、AlteraのほうがIntelっぽいというかIntelですね(紛らわしい表現)。

第0歩: 型を学ぶ


「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」という本で学んでいったという話です。
これは、XilinxのZynqというアーキテクチャのZedBoardという評価ボードの利用を前提にした本です。
出た当初はこの本高いなぁ、Web上にある情報でなんとかならないかなぁ、と思っていました。
しかし、途中でIDEの扱い方に心が折れ、諦めて買いました。
本の範囲としては、旧世代のIDEの利用が多いのですが、一応新世代のIDEをカバーした章もあり、グラフィックス出力から自前のコア構築、チューニング可能なポイントの洗い出しから実際にチューニングしてみるまでの本当に多彩なトピックをカバーしています。
とても良い本です。ただ、誤植がものすごく多いのが難点です。見つけた誤植は「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」の誤植一覧(150箇所)にまとめました。
ここでの学び: ツール群の扱い方がざっくりと身につかないと、他のことが頭に入ってこない。まずはこういう本に従ってひと通りを体験するの大事(しかしISEベース...!)
この本、ひとつひとつしっかりやっていくと各小項目で1冊ずつ本が書けそうな幅広さです。
特に、さわりが載っていたことが個人的に嬉しかった項目を挙げておきます。
  • ISEとVivadoの両方を使っての話展開
    • ちょっと古い記事やチュートリアルを眺めると、結構ISEベースの話がある。こういう時に怖がらず読めるようになった
      • まあ、PlanAheadとかXPS?とかいくつかのツールが、どういうふうに再編してVivadoになってるかという雰囲気が掴めるのが大きい
  • Linuxのデバイスツリーに関する話と実際に自分で書く話
  • PSとPLの間のデータ転送
    • AXI系
      • AXI4-Lite
      • AXI4
      • AXI4-Stream
結果、この本はだいぶ読み込みました。軽く遠出するときに電車の中で読んだり、家でも何度か読んだり。
2-3ヶ月FPGA方面から離れて、頭のなかから色んなものが抜けた状態で再度スタートしようというときに、頭をFPGAへ引き戻すためにも有効でした。
惜しいのは前述の通り、誤植が多いことです。やはり、頭が乗ってきて読み進めている時に、技術用語が誤った領域を踏むと脳が例外を吐いて止まってしまうので悲しいところです。売れに売れて重版で誤植が直ったら、多分もう一冊買うと思います。

Zynqの雰囲気

本やオンラインのドキュメントを読んでいて感じた、ARM+FPGAというZynqアーキテクチャにまつわる雰囲気を書いてみます。

"7"シリーズは断絶の壁

前述のように、XilinxはISEシリーズから新しいIDE(Vivado)へと移行しました。この移行期にぴったりぶつかったのが、いわゆる"7"シリーズです。ZedBoard/MicroZed/ZYBOに使われているZynq-7000シリーズもこのひとつです。
ISEにはZynq-7000シリーズの開発用定義ファイルがありません。古いチュートリアル(書籍も!)は割とISE前提で書かれています。

「ARM無しのFPGA単体で使いたいんですけど?」→「Artixでも使えば^^」

  • Zynqなシステムの利用にあたっては、Linuxを使うか否かは別として、チュートリアル的にARMは普通使うぽい
    • なので、Zynqのチュートリアルを探していくと、「単純な論理回路をまずは組んで動かしてみよう!」という感じの伝統的なFPGAチュートリアルっぽいのがあまり出てこない
  • Xilinxの人の、Zynqをシステム要素として使う際の設計スタンス http://news.mynavi.jp/articles/2012/02/22/zynq-7020/002.html
    • ARM側の電力削りたければ100MHzでも10MHzでも好きにクロック落とせ
    • RTOSが必要なら、ARM側をSMPではなくAMP構成にして1コアを低クロック動作させて使え
    • Cortex-R系はひとまずやる気ない
      • ※そう言いつつ、3年後にはMPSoCという新世代のアーキテクチャはCortex-A53ベースとCortex-R5ベースの2ラインに割れたので大変趣深い

MicroZed/ZedBoardの起動手段は使い分けたほうが便利

  • JTAGは初期の開発へ利用
    • デバッガをアタッチしたい場合などに大変便利
  • FPGA部分が固まってソフト開発へと段階が移ってきたらSDカードに書き込んで起動
    • いくつかのバージョンを別カードへ保持して差し替えやすい
    • 数十MB〜数GBのファイルも置ける
  • ファームがしっかり固まってきたらQSPIへ焼く
    • 起動がSDカードより速い
    • 16MBまでしかアクセスできないので、起動用ファイル以外のデータ群はどのみちSDカードになるはず

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を勉強しては少々離れている間に忘れる、というループを既に数回繰り返しているので、今度は特に開発環境面のメモを残しながら進めてみようかと思って書いてみました。