rack-mini-profiler 0.9.0.preの話。

Railsアプリで使っているrack-mini-profilerの設定を変更して、

• デフォルトでは無効
• URLに?pp=enabledを付ければ以降のセッション中は有効

という挙動にするため、GitHub上にあるREADMEのConfiguration Optionsを参考にconfig/initalizers/mini_profiler.rbに

# Have Rack::MiniProfiler start disabled - you can use query string option to re-enable later
Rack::MiniProfiler.config.enabled = false

と記述してみたところ、

NoMethodError: undefined method `enabled=' for #<Rack::MiniProfiler::Config:0x007ff12a1305b0>

と例外が発生してしまう。

ソースコードをよく見てみるとHEADのREADMEで言及されているオプションは2013年12月5日にリリースされた0.9.0.preから利用可能になったもののようで、今のところのstable releaseである0.1.31では使えないみたい。

なので、Gemfileを

gem 'rack-mini-profiler', '0.9.0.pre'

と書き換えて最新版を使うようにしたことで、上記の設定が使えるようになった。

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コマンドで設定しておけばよいことがわかった。

• bundle config

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

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

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

• Evaluating a redesign by Jason Fried of 37signals

Jason Fried曰く、

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

とのこと。

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

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

$ /Applications/Postgres93.app/Contents/MacOS/bin/pg_upgrade \
  -b /Applications/Postgres.app/Contents/MacOS/bin \
  -B /Applications/Postgres93.app/Contents/MacOS/bin \
  -d ~/Library/Application\ Support/Postgres/var \
  -D ~/Library/Application\ Support/Postgres93/var

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok
Checking for reg* system OID user data types                ok
Checking for contrib/isn with bigint-passing mismatch       ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 ok
Checking database user is a superuser                       ok
Checking for prepared transactions                          ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting files from new pg_clog                             ok
Copying old pg_clog to new server                           ok
Setting next transaction ID for new cluster                 ok
Setting oldest multixact ID on new cluster                  ok
Resetting WAL archives                                      ok
Setting frozenxid counters in new cluster                   ok
Restoring global objects in the new cluster                 ok
Adding support functions to new cluster                     ok
Restoring database schemas in the new cluster
                                                            ok
Removing support functions from new cluster                 ok
Copying user relation files
                                                            ok
Setting next OID for new cluster                            ok
Sync data directory to disk                                 ok
Creating script to analyze new cluster                      ok
Creating script to delete old cluster                       ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
    analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
    delete_old_cluster.sh

$ ./analyze_new_cluster.sh

$ ./delete_old_cluster.sh

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

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

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

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

• rake about
• rake stats
• rake notes

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

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