Postgres.appを9.2から9.3にアップデートした。

データベースの移行は以下のgistのような手順で行った。今回からアプリケーション名がPostgres93.appに変更になっているため、データベースファイルのパスなどもこれまでとちょっと違う。

求人の際に「自社のコードベースがどれくらい健全か」というのをアピールする視点を持つとよいのではないか、と思いました。

コードの総行数、テストのカバレッジ、TODOコメントの数、利用しているソフトウェアのバージョンなどがわかれば、入社後にどれくらい悲惨なコードと格闘することになるのかが想像しやすくなりますし、企業側にも技術的負債を返済するインセンティブとなります。

もちろんスタートアップ企業では成長と拡大が最優先なので技術的負債の返済が後回しになってしまう事情はありますが（ある程度ステージが進んだ状態なのであればそうも言っていられないでしょうけど）。

例えば、自社サービスがRailsで作られているのであれば、

• rake about
• rake stats
• rake notes

の出力を貼るだけでもアピールになると思うので（結果がよければ）、技術者を採りたい企業にはぜひ試してみてもらいたいです。

サンプル: Code statistics for qnyp.com application at Nov 19, 2013.

Logentriesがプラットフォーム化した。

• Logentries Partner Add-ons Program – Logentries Blog

Logentriesは、サーバー上のログをLogentriesに送ることで、Webインターフェースからインテリジェントにビジュアライズされた形でログを確認できるサービス（メールでのアラートもある）。単体のサービスとしてAWSなどのクラウド環境やオンプレミスなサーバーに導入するほか、Herokuアドオンとしても利用できる。

qnypではLogentriesをHerokuアドオンとして利用しているけれど、LogentriesはデフォルトでHerokuプラットフォームに固有のログパターンを検出できるように設定されており、これを導入するだけで大抵の障害パターンをメール通知してくれる。おかげで生のログ出力を確認することはほぼなくなった。

そんなLogentriesが今回アドオンプラットフォームとしての機能も持つようになり、まずはHerokuプラットフォーム上で

• Heroku Postgres
• Adept Scale
• CloudAMQP

の3つのサービスについて、ログ出力をもとにしたビジュアライズができるようになったようだ。

LogentriesがHerokuアドオンとして振る舞いつつ、Logentriesに対するアドオンも存在する、みたいなややこしい図式になっているけど、Herokuではログのストリームを活かしたサードパーティのアドオンも増えてきているし、「ログを元にビジュアライズを行う」という部分をプラットフォーム化して提供するのはなかなかいい着眼点だなと思う。

37signalsからの新しい書籍「REMOTE」のカバーデザインが決まるまでの話。

• Behind the scenes: Designing the REMOTE book cover by Jamie of 37signals

Signal vs. Noiseに、REMOTEのカバーデザイン過程に関するエントリが掲載されていた。

前著のREWORKが「丸めた紙くず」を表紙に用いていたことから、ネクタイやケーブルなどの実在するものをモチーフにしたりしつつ、最終的には「O」の文字を中心に「REMOTE」の文字が繋がるデザインになったことがわかる。

面白いのは著者であるJason FriedとDHHがともにこの表紙デザインを気に入った一方で、出版社や書店のバイヤーからは好まれなかったというところ。結局、著者の2人が押し切る形で出版されたとのこと。

Rubyにおけるraiseとfailの使い分けについて。

久々にrubocopを動かしたら、

app/models/user.rb:139:7: C: Use `fail` instead of `raise` to signal exceptions.
      raise Exceptions::AlreadyChecked, msg
      ^^^^^

こんな感じで、raiseじゃなくてfailを使え、みたいな警告が結構出た。

2つのキーワードの使い分けについてちょっと調べてみたところ、Exceptional Rubyというスライドの10枚目「raise (or fail)」にて、Jim Weirich氏による以下のようなコメントが引用されていた。

I almost always use the "fail" keyword… the only time I use "raise" is when I am catching an exception and re-reaising it, because here I'm not failing, but explicitly and purposefully raising an exception. – Jim Weirich

rescueなどで捕捉した例外を再度発生させる時には「何かがfailなわけではないので」raiseを用い、それ以外の場合はfailを用いる、というような使い分けのパターンがあるようだ。