Sooey

2013-11-19 12:42:55 +0900

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

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

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

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

  • rake about
  • rake stats
  • rake notes

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

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

2013-11-14 19:11:07 +0900

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

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

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

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

  • Heroku Postgres
  • Adept Scale
  • CloudAMQP

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

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

2013-11-14 19:00:42 +0900

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

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

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

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

2013-11-10 22:08:22 +0900

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を用いる、というような使い分けのパターンがあるようだ。

2013-11-03 16:51:38 +0900

Foursquareのサイトを見ていたら、チェックインの英語表記についてこんな説明があった。

「check-in」 または「check in」?

どちらにも使えます!動詞として使う場合は「check in」(例えば、「ここで‘check in‘しますか?無料メッセージの特典があります。」)です。名詞として使う場合は「check-in」(例えば、「今までで一番最高の’check-in’だったよ。無料メッセージをもらったなんて最高!」)。そして、「checkin」は使用禁止です。使われるたびに社員は心で泣いています。

Foursquareについて