2012年6月9日

deviseを2.0にアップグレードするときのエラー

devise1.5系を使っていたのだが、いつの間にか、2.1にバージョンが変わっていた。
ちゃんと動くなら、別にかまわないのだが、どうも、rake db:reset、rake db:migrate してDBを作り直すとまともに動かなくなるようだ。
例えば、自分の作ったプロジェクトをgitにあげておいて、他の人がgit cloneして使うばあいに、問題が出る。こういうのって、ツールを公開するばあいには一般的だと思っていた。

出てくる問題は、rake db:migrateすると、 Database Authenticatableというメソッドはないというエラーだ。
この原因は、こちらに書かれているとおりdeviseを2.0系にアップデートした際、もともとのファイルにあった、Database Authenticatableなどのヘルパー(?)の利用を廃止した。
その結果、以前のmigrationファイルが動かなくなってしまった。

基本的に、あるプロジェクトのDBを新しく作るには、rake db:migrateではなく、rake db:schema loadが正しい処方らしい。
で、DBが変わるたびに、rake db:migrateして変更を追加していくわけだ。

引用するまでもないが、こんなエラーが出る
undefined method `database_authenticatable' for
#
しかしこれでは、いざというときに、migrationファイルが壊れていることになり、気持ちが悪い。
そこで、migrationファイルをいじることになる。
サイトがなくなると困るので、この記事の最後にべったりコピペしておこう。

なんとなくmigrationファイルをいじるのには抵抗がある。
しかし、中身が実質変わらないのならリファクタリングの一環ということで、よいという意見がある。



<migrationファイルの変更>
現状(1.5系)
create_table(TABLE_NAME) do |t|
  t.database_authenticatable :null => false
  t.recoverable
  t.rememberable
  t.trackable

  # t.encryptable
  # t.confirmable
  # t.lockable :lock_strategy => :failed_attempts, :unlock_strategy => :both
  # t.token_authenticatable
end
 2.0系
create_table(TABLE_NAME) do |t|
  ## Database authenticatable
  t.string :email,              :null => false, :default => ""
  t.string :encrypted_password, :null => false, :default => ""

  ## Recoverable
  t.string   :reset_password_token
  t.datetime :reset_password_sent_at

  ## Rememberable
  t.datetime :remember_created_at

  ## Trackable
  t.integer  :sign_in_count, :default => 0
  t.datetime :current_sign_in_at
  t.datetime :last_sign_in_at
  t.string   :current_sign_in_ip
  t.string   :last_sign_in_ip

  ## Encryptable
  # t.string :password_salt

  ## Confirmable
  # t.string   :confirmation_token
  # t.datetime :confirmed_at
  # t.datetime :confirmation_sent_at
  # t.string   :unconfirmed_email # Only if using reconfirmable

  ## Lockable
  # t.integer  :failed_attempts, :default => 0 # Only if lock strategy is :failed_attempts
  # t.string   :unlock_token # Only if unlock strategy is :email or :both
  # t.datetime :locked_at

  # Token authenticatable
  # t.string :authentication_token

  ## Invitable
  # t.string :invitation_token

  t.timestamps
end

2012年6月4日

Gmvaultを使って、Gmailをバックアップ

Gmailのアカウントが二つあって、扱いに困っていたところ、ちょうどGmailのバックアップツールであるGmvaultがLifehackerに紹介されていたので、利用してみた。
アカウントAは以前から使っていたもので、90%ぐらいの使用量になっていた。
で、最近職場のメールがGmailベースに切り替わったので、二つ目のGmailアカウントができた。(アカウントB)

アカウントBは容量がとても大きいので、いったんアカウントAのデータを全部アカウントBにPOP経由で移動した。
そのときは、今後はアカウントBを日常利用用に使おうと思っていたのだけれど、なんとこのアカウントが使えない!
一定時間が過ぎるたびにログアウトしてしまうのだ。
それもけっこう短時間で。

マシンをいったんスリープしたらもうアウト。
またログインからやり直しだ。
こんなのGmailちゃう!

ということで、仕事関係のメールはアカウントBに届くので、アカウントBに届くメールをすべてアカウントAに転送して、今までどおり、普通のGmailを普段使いで使っている。
この問題は、いったんメールを全部アカウントBに移動してしまったので、今年の4月以前のメールがないということ。
でもまあいいかと思っていたのだけれど、微妙に不便。

そこで見つけたのが、Gmvault
これを使って、2011年1月1日以降のメールをアカウントBからバックアップし、そのデータを、'before201204'というラベル付きでアカウントAにリストアした。
とりあえず、一年ちょい分のデータがあれば日常使用には耐えるので、こんな感じでしばらく運用してみよう。
使ったコマンドはこんな感じ。
./gmvault sync --type custom --imap-req 'Since 1-Jan-2011' アカウントA
./gmvault restore --label "before201204" -d ~/gmvault-db アカウントB
 この作業が終わった今は、全体を一度バックアップして、今後はcronで定期的にsyncしておこうかなと思っている。
が、それよりも、IMAP使って、ローカルにMaildirかなにかで保存した方が使い勝手は良いかもしれないなあ。。。