# config/routes.rb:
devise_for :users,
  controllers: {
    registrations: :registrations,
    omniauth_callbacks: 'users/identities'
  } do
    delete 'users/disconnect/:provider' => 'users/identities#disconnect_omniauth_provider', as: 'disconnect_omniauth_provider'
end
$ rake spec
(...)
DEPRECATION WARNING: Passing a block to devise_for is deprecated. Please remove the block from devise_for (only the block, the call to devise_for must still exist) and call devise_scope :user do ... end with the block instead. (called fr)

上記のようにdevise_forにblockを渡すスタイルはDEPRECATEDになった。

# config/routes.rb:
devise_for :users, controllers: {
  registrations:      :registrations,
  omniauth_callbacks: 'users/identities'
}

devise_scope :user do
  delete 'users/disconnect/:provider' => 'users/identities#disconnect_omniauth_provider',
    as: 'disconnect_omniauth_provider'
end

こんな感じでblockに渡してた部分はdevise_scopeを使うといいらしい。

sqlite3でhistoryや補完が聞かなくてウザい。

% which sqlite3
/Users/komagata/android-sdks/tools/sqlite3
% brew link sqlite3 --force
Linking /usr/local/Cellar/sqlite/3.7.17... 9 symlinks created
% which sqlite3
/usr/local/bin/sqlite3

Android SDKに入ってるのが使われてた。brew linkしたら行けました。

参照:あたま うじお - komagata

ko8(こーや)が何で

o)加速度センサー x)加速センサー

o)アシェルタ・イタリアン x)アシェルタン

のように名詞を雑に覚えてるのか気になってた。ちょっとした違いかもしれないけど、プログラマーがJavaを絶対にJAVAと書かないように、絶対ありえないタイプの間違えだと思う。

それが最近、すごくしっくり来る理由を思いついた。

たぶんko8は名詞を音の響きで覚えてる。

普通の成人は意味で覚えてる。“加速度”の“センサー”だなとか、“アシェルタ”という“イタリアン”なんだなという風に覚えてる。加速度とセンサーは個別にすでに知っているのでそれの組み合わせだと理解するわけだ。

しかしko8は音の響きで覚えてるのでまっさらな新しい単語として覚える。そして1音違うぐらいはたいした間違えではない。

子供のころは音で覚えてるものが沢山あったとおもう。言語を覚える時というのは最初はそういうものなんだと思う。俺も実家の近くにあった多摩御陵を「たまごりょう」という音で覚えてた。「たまご」はわかるけど「りょう」ってなんだろう?などとは思わなかった。

大人になって初めて多摩の御陵という意味で、陵というのは天皇の墓を示すというのを知った。意味で覚えていれば、“多摩陵”というような間違えはあるかもしれないが、“たまごろう”とかそいういう間違えはありえない。

音で覚えていると新しい名詞に出会った時に理解が遅い。何度も繰り返し耳にしないと覚えないから。音で覚えていると応用が効かない。

多摩御陵を意味で覚えているなら、XX御陵という他の墓が存在するだろうとか、天皇の墓というのであれば多摩御陵は何天皇の墓なんだろうとかもうすこし立体的に理解できる。

しかしko8は今日が誕生日だそうで(おめでとうございます)、今日ゼロ歳で生まれ変わったと言っていたので大丈夫だと思う。コーヤリボーン!

このブログのLokkaのテーマをslimにしてみた。

docs-komagata-org/public/theme/komagata/layout.slim at master · komagata/docs-komagata-org

以前はバグが多かった印象だけど最近rails案件で使って特に問題なかったので。

従軍記のLokka移行をやっていますが、それを実験台としてさっさとactive-recordブランチをmasterにしたい。あとちょっとなんですけどねー。datamapperからactive-recordへの移行になるからexport/import機能が必要になる。フォーマットはxmlかymlか?とにかくactiverecord化がまずは完了しないと何も進められないのでがんばろう。

@yandoさんから下記を教えてもらったのでやってみた。

Engine Yard Cloudでカスタムレシピを使う

本家に日本語の記事があります。

Chef レシピによる環境のカスタマイズ : Engine Yard Developer Center

最初全体像がつかめなかったんですが、要は環境毎にrecipeを保存してるサーバーがどこかにあって、アプリのコードとは別に、カスタマイズしたrecipesをey recipesコマンドでそこにアップできるそうです。

timezoneの変更

EYCのinstanceに入ってtimezoneを確認してみるとUTCになっています。
$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 25 May 17 19:13 /etc/localtime -> ../usr/share/zoneinfo/UTC
$ date
Sun Aug  4 02:54:45 UTC 2013
timezoneのrecipeはengineyardが用意してるrecipeに元々あるので、それを読み込んで変数を変更してやればいい。(recipeはforkして使う)
% git clone git@github.com:fjordllc/ey-cloud-recipes.git
% cd ey-cloud-recipes
% git diff -U0
diff --git a/cookbooks/main/recipes/default.rb b/cookbooks/main/recipes/default.rb
index 5bbd736..f9d39b0 100644
--- a/cookbooks/main/recipes/default.rb
+++ b/cookbooks/main/recipes/default.rb
@@ -148,0 +149,2 @@
+
+include_recipe "timezone"
diff --git a/cookbooks/timezone/recipes/default.rb b/cookbooks/timezone/recipes/default.rb
index e62ec33..b0de8de 100644
--- a/cookbooks/timezone/recipes/default.rb
+++ b/cookbooks/timezone/recipes/default.rb
@@ -4 +4 @@
-timezone = "UTC"
+timezone = "Asia/Tokyo"

僕はsunzi派ですがchefも触っておいて良かった。

ey recipesでupload, applyする。

% ey recipes upload -e jp_production    
Loading application data from Engine Yard Cloud...
Recipes in cookbooks/ uploaded successfully for jp_production
% ey recipes apply -e jp_production 
Loading application data from Engine Yard Cloud...
Uploaded recipes started for jp_production

ちゃんとtimezoneが変わってるかどうか確かめる。

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 30 Aug  4 12:06 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo
$ date
Sun Aug  4 12:08:20 JST 2013

うん。変わってる。DBサーバーの方もちゃんと変わってました。appサーバーだけ変更する場合にはroleを指定するとか何かあるんでしょう。多分。

これってTokyoリージョン使う場合は必須の作業ですね。

% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl` --with-readline-dir=`brew --prefix readline`" rbenv install 2.0.0-p247
% rbenv global 2.0.0-p247
% ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]
% gem install bundler rbenv-rehash

Engine Yard Cloudに限りませんがちょっとハマったので。

UTCで動いてるサーバーで、例えば日本からのアクセスが大半で一番空いてる時間が朝5時(よくある)の場合、JST 5時はUTC 20時(前日の)なので集計バッチなどは上記の用な感じにしておく。

herokuのbamboo stackからcedar stackへのアップグレードは無理なので新規に作ってDBを移行後ドメインを切り替えた。

tapsを使ったdb:pull/db:pushはruby1.9.2とruby.19.3の間のmarshal互換性の断絶で無理なので(このbamboo stackはruby1.9.2で動いてる)pgbackups(pg_dump)を使う。

pgbackupsを使ってpg_dumpを取得したあと、postgres.heroku.comの下記の右側にある矢印アイコンのメニューの中のpg_restoreを選ぶとrestoreコマンドが親切に出るのでそれでさっきのdumpを読み込んで完了。

Lokkaももうちょっとドラスティックに変えていこうかなと思っています。仕事外の時間でちまちまと進めます。

Mailがいちいち立ち上がってウザいのでmailto:ハンドラを処理するデフォルトのメーラーをGmailにしたい。

Google Notifierを入れてデフォルトメーラーに設定すればOK。

ただ、内容が長すぎるとURLに全部はいるのでエラーになってしまうのが使い辛い所。

undefined method `render_partial_with_logging'というエラーが時々出る。調べてみるとkaminariのthreadsafe系のissueが上がってた。ちょうどrails4アプリのweb serverをpumaにした所だったのでまさにコレっぽい。(heroku + rails4のアプリをpumaにしたらかなり速くなった)

undefined method `render_partial_with_logging' for class `#<Class:0x617ead84>' org/jruby/RubyModule.java:2256:in `alias_method' · Issue #214 · amatsuda/kaminari

上記のissueが修正されたのが4 months ago、kaminari最新の0.14.1がリリースされたのが去年。masterを指定するのは怖いので最後のcommitのrefを指定してアップ。

# Gemfile:
gem 'kaminari',
  git: 'git://github.com/amatsuda/kaminari.git',
  ref: '2ed8adfe378594ae1585ac4a457a6d01f04478eb'