Atom.io に乗り換えられなかった

きっかけは些細なことだった。 Emacs で RSpec のテストケースを書いていて、全体的に動作がのろくてイライラさせられた。どうやら ruby-mode だか ruby-electric だかが悪さをしているらしいが、何年も前に .emacs.d に放り込んだもので、どんな風に設定するのかも覚えていない。最新バージョンに入れ替えてみたら、手元でちょろっとカスタマイズしていた改行時のオートインデントだか何かの挙動が変わってしまい、気になってコーディングどころではなくなった。

もともと Emacs Lisp は読むのも書くのも苦手で嫌々ながらも騙し騙し付き合ってきたが、このときばかりは心底うんざりして、もうこんな古代のツールに頼るのはやめにしよう、自分の仕事は高度に知的な作業であるはずのプログラミングであって多彩で変態的なキーボード操作を駆使してテキストを編集しまくることではない、ならばもっと仕事内容にふさわしい道具を使うべきじゃないのか—そんな風にして、乗り換えを決意した。

IDE に興味があり、この機会にチャレンジしてみようと思ったものの、細かいことばかり気になる面倒な性格のせいで IntelliJ IDEA と RubyMine のどちらを購入するべきなのかで迷い、結局どちらもお試し版すらインストールすることなく、とりあえずもうちょっとなじみやすそうなのを...と妥協して Atom.io を使い始めたのが一月半ほど前のことだっただろうか。

なぜ Sublime Text ではなく Atom なのかというと、 Atom のユーザーインタフェースのほうが多少洗練されていて気に入った、というのがひとつ。そしてもう一つは、そもそも乗り換えた動機が「なるべくカスタマイズに労力をかけたくない」だったので、パッケージ管理の仕組みがデフォルトで提供されている Atom を選ぶほうが理にかなっている、と思ったからだ。

それから一ヶ月ほど、いくつかのパッケージを試したりやめたりしつつ、 Emacs に慣れきった両手の指で真新しいキーバインドをたどたどしく練習しつつ、仕事でもプライベートでも Emacs を一切起動することなくコードや文章を書いてみて、最終的にこれは無理だと観念して Emacs に出戻った。

Atom を使っていてどうしても我慢がならなかったこと。それは、一つのウィンドウで一つのディレクトリ配下のツリーしか開けないことだ。

仕事で扱うリポジトリは複数あり、しかも相互に行き来してコードリーディングをしながらの作業が頻繁に発生するため、 Atom のこの仕様は自分のユースケースとはとても相性が悪かった。上記のスクリーンショットでいうと、 mongomapper と plucky のファイルは頻繁に相互に見比べたいので、ウィンドウごと切り替えていたのでは手間がかかりすぎる。右側のウィンドウのように親ディレクトリを対象に開けば一つのウィンドウ内で全てのファイルを開けるが、親ディレクトリ配下に数十ものディレクトリ（リポジトリ）がある場合、ノイズが多いし動作も遅くなってしまった。

他にも不満はたくさんあったが、もう一つだけ自分のユースケースと合わなかったことを挙げるなら、コマンドラインから Atom を開くときの動作の遅さにはずいぶん時間を無駄にさせられた。 Git のコミットログを書く際にいちいち Atom の起動で待たされるのには辟易した。

Atom をほんのお試しではなく、それなりに真面目に使ってみて良かったこともある。 Tree view は素の dired に比べるとずっと見やすいし、 Line diffs （いわゆる GitGutter）は地味だが想像以上に便利だった。当然これらに類似した機能は Emacs でも—そう、有志の手による拡張 Emacs Lisp パッケージとして—利用でき、出戻りのタイミングで Emacs のカスタマイズを整理しなおしたついでに Atom で経験した便利機能を Emacs のカスタマイズでも取り入れ、結果として Emacs がより便利になった。単に Emacs カスタマイズの情報収集を怠っていただけ、ともいえる。

結局いまだに RubyMine は試していないが、趣味で Java のオンライン学習コース（無料）を勉強しはじめて IDE の雄である Eclipse に触れる機会も作れるようになったことだし、ヌーに左手の小指を呪われた運命を受け入れてもう死ぬまで Emacs でいいかな...。

vc-git の vc-annotate をコンパクトな見た目にする

vc-annotate は Emacs のキラーフィーチャーと言っても過言ではない便利な機能だが、 vc-git でパスの深い位置にあるファイルを annotate すると肝心のコードが隅に追いやられてしまって見づらい。 v キーでアノテーションのオンオフをトグルできるが、キーバインドを忘れがちだし、 author と変更日時まで隠れてしまうとそれはそれで困る。

vc-annotate は内部的に git blame コマンドを利用しているが、引数もろとも vc-git.el でハードコードされており、残念ながらここをカスタマイズする標準的な方法は提供されていない。幸いコマンドを実行する部分が個別の関数になっているので advice で上書きできる。

(defadvice vc-git-annotate-command (around vc-git-annotate-command activate)
  "suppress relative path of file from git blame output"
  (let ((name (file-relative-name file)))
    (vc-git-command buf 'async nil "blame" "--date=iso" rev "--" name)))

advice 適用前。表示部分の多くの部分をファイルパスが占めており、肝心のコードがほとんど見えない。

advice 適用後。オリジナルの引数から "-C" "-C" を抜いた。これでファイルパスが表示されなくなった。

git blame の --date オプションを変更して日付部分を短くするのも試してみたが、 vc-annotate がコードの各行を色づけする際に利用しているパーサーの正規表現と相性が悪いようで色がつかなくなってしまったので、日付はデフォルトのままで我慢している。

Say hello from Philippines

#philippines #manila #sunset

先週の日曜から出張でフィリピンに来ている。 Quipper のマニラオフィスが首都マニラのビジネスエリアであるマカティにあり、一週間ほど滞在している。

目的はマニラオフィスのスタッフとの交流、そして学校訪問だ。 Quipper は現在 Quipper School という、学校の先生と生徒に向けた学習プラットフォームを提供している。マニラ勤務のスタッフは頻繁にフィリピン中の学校を訪問し、サービスを紹介したり先生や生徒が利用し始めるステップを手助けしたりしているが、開発者も自分たちが作っているサービスが現場でどのように使われているのかその目で確かめ、より良いプロダクトを作る糧としよう、というのがこの出張の趣旨だ。

学校訪問は人生屈指の印象に残る出来事だった。僕は海外経験に乏しく、東南アジアを訪れたのもこれが初めてだったが、どんな場所か想像もつかなかった海の向こうの国で、先生たちが Quipper School に強い関心を持ち、生徒たちがとても楽しそうに我々のサービスを使って算数の問題を解いたりしている様子を間近で見られたことは、非常に良い経験になった。

Quipper School はフィリピンだけでなく、インドネシア、タイ、ベトナム、イギリス、ロシア、トルコ、スペインでサービスを展開しているが、特にフィリピンとインドネシアでの成長が顕著で、会社としてもマニラを拠点として東南アジアでのサービス拡大を目指し、ここマニラで Ruby デベロッパを積極的に採用し始めている。せっかく東京から開発者が来ているタイミングなので、マニラでのプレゼンスを高めるべくデベロッパ向けのセミナーイベントを開催した。

Web Developer Seminar -- “Working at a global startup in search for better careers as a web developer”

https://speakerdeck.com/kyanny/web-developer-seminar

英語でのスピーチは初めてで、お世辞にもいい出来だったとは言えないが、参加してくれたたくさんのデベロッパたちと交流することができた。マニラオフィスで働いている二人のデベロッパとも、このイベントを通じてオフラインでコラボレーションできたのも良い経験になった。

Book: JavaScript Ninjaの極意 ライブラリ開発のための知識とコーディング

jQuery の John Resig （とテキサス在住の白ひげのおじさん）が書いた JavaScript の中上級者向けの本。タイトルと表紙の奇抜さが気になって読んでみた。

独特すぎて評価が難しい本。独自の assert 関数を全てのサンプルコードの実行結果に使うのにはおどろいた（console.log でいいじゃん）。全体的に、一般的でない手法を採用していて異質な印象を受けた。「関数的」とか、用語も奇妙。仕事で必要なので JavaScript を習得したいという人には薦めない。高度な内容も少なくないが、そういうトピックは Effective JavaScript を読めばいい。

独特なのは意図したもののようにも感じられた。一般的なプログラミングの専門書（実用書）と比べるとセオリーに沿っていないように感じられる部分が多いが、逆に言えば「お約束」に頼っていないということ。十分な前提知識を持っていない読者にも JavaScript という言語を丁寧に説明しようとして、あえて一風変わった教え方を試みたのかもしれない（入門編にあたる章の話）。

John Resig は Khan Academy で Computer Science の学部長をつとめているそうだ。 Khan Academy はその理念からしておそらく、仕事を得るために技能を身につける職業訓練校のような性質のものではないだろう。となると John Resig の Khan Academy での仕事は、趣味や教養としてプログラミングを学ぶ人のためのものであるはずだ。そういう思想がこの本になにがしかの影響を与えた結果、ふつうのプログラミング書籍と比べて風変わりに仕上がったのかもしれない。

テクニック面では、ブラウザ検出よりも機能検出やオブジェクト検出を利用したほうが未来の変更に対して強いコードになる、という話がためになった。こういう話題こそ忍者にふさわしい。もっと踏み込んでもよかったと思う。終盤のイベント、DOM、CSSセレクタの話題はだいぶ駆け足で、やっつけ仕事な印象を受けた。 jQuery のソースコードを読む手引きにはなるかもしれない。

クセの強い本にもかかわらず、訳者はとてもよい仕事をしたと思う。訳注はたいへん丁寧で、参考文献やオンラインのリソースを細かく添えて本文を補い、補足が必要な訳語についてもしっかり解説している。 Effective JavaScript も翻訳した方らしい。この人の訳書なら名前買いしてみてもよさそうだな、と思った。

JavaScript Ninjaの極意 ライブラリ開発のための知識とコーディング (Programmers’ SELECTION)

Submitted CFP for #rubykaigi 2014

RubyKaigi 2014 の Call for Presentations に応募した。昨年に引き続き bundle update ネタ。またかよと思われそうだけど、動機の説明からして面倒くさいこのニッチな領域にここまで強い関心を抱く人はあまりいそうにないので、「いま自分にしか出せない CFP」にはなったと思う。

応募内容を清書するのは締め切りぎりぎりになってしまったけど、常日頃から考えていることなので書くべき内容には困らず、応募後（特に reject されちゃった場合！）に「もっとこうしておけばよかった」と後悔することはないだろうな、と自信を持って Submit ボタンを押せたので満足。

My CPF is accepted. I became a speaker!