Sooey

2013-12-04 22:41:43 +0900

Bundlerでgemに固有のビルドオプションを指定する方法。

libv8を利用しているRailsアプリケーションで、Mavericksにしてから改めてgemのビルド&インストールを行おうとすると(Mountain Lion時代にビルドしたgemが使えている限りはおそらく問題に遭遇しない)、libv8のビルドがこんな感じで失敗する。

Installing libv8 (3.11.8.13)
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

    /Users/juno/.rbenv/versions/1.9.3-p484/bin/ruby extconf.rb
creating Makefile
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Unable to find a compiler officially supported by v8.
It is recommended to use GCC v4.4 or higher
Using compiler: g++

(snip)

Gem files will remain installed in /Users/juno/src/railsapp/vendor/bundle/ruby/1.9.1/gems/libv8-3.11.8.13 for inspection.
Results logged to /Users/juno/src/railsapp/vendor/bundle/ruby/1.9.1/gems/libv8-3.11.8.13/ext/libv8/gem_make.out

Mavericks上でlibv8のビルドを成功させるには、

$ gem install libv8 -v '3.11.8.17' -- --with-system-v8

というように--with-system-v8オプションを指定すればいいのだけど、Railsアプリでbundle installした時のインストール先をbundle install --path vendor/bundleのようにプロジェクトローカルなパスに指定している場合、普通にgem installしたgemは参照することができない。

そこで、bundle installした時にもgemに固有のビルドオプションを指定する方法を調べていたところ、あらかじめbundle configコマンドで設定しておけばよいことがわかった。

最終的に、Mavericksでlibv8をbundle installで正しくビルド&インストールするには以下のようにすればOKだった。

$ bundle config build.libv8 --with-system-v8
$ bundle install --path vendor/bundle

2013-12-03 12:08:36 +0900

サイトデザインをリニューアルする際に「旧デザインと較べてどうか」という手法をとるのはよくない、という話。

Jason Fried曰く、

  • 旧デザインが作成されてから、事態がそれほど変化していないのであれば比較には意味がある
  • 比較をすることでどうしても旧デザインの影響が出てしまう
  • それなりに時間が経過して新しいデータが集まっていたり新しいゴールが設定されているのであれば、「新デザインが何のために、何を目指して」行われているのかを知ることから始めたほうがよい

とのこと。

2013-11-19 17:46:07 +0900

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

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

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ではログのストリームを活かしたサードパーティのアドオンも増えてきているし、「ログを元にビジュアライズを行う」という部分をプラットフォーム化して提供するのはなかなかいい着眼点だなと思う。