miuchee を heroku 環境に移行した

miuchee を heroku に移行したメモです。

移行理由

  • @mkouhei さんのサーバ(さくら)を仮想マシン環境で使わせてもらっていた
    • さくら環境要因で時折メンテが必要になっていた
  • 現状の heroku なら無料で使えそうな状況である
    • sendgrid は無料で毎日400通メールが送れる
    • 無料で一日 18h までしかサーバが動かせないが、基本バックグラウンドで動かすサービスなのでそれほど問題ない
  • (個人的に) カジュアルに Ruby のバージョンをあげたり、デプロイしたりできる環境の方が扱いやすい

移行メモ

  • 移行前、 Ruby 1.9.3, Rails 3.2.12 であった
  • そのままのバージョンで heroku に移行しようかと思ったが、そもそも Ruby 1.9.3 環境をローカルに用意するのも大変
    • Ruby のバージョンを上げると gem も動かなくなったりする
  • どうせ手間がかかるなら最新にするのが心の健康によい
  • RSpec のバージョンアップ、yujinakayama/transpec が活躍した
  • 段階的に Rails 4.0, 4.1, 4,2 と上げていった
  • 4.0 に上げた時点で、Rails がActiveRecord の size メソッドの落とし穴 - おもしろwebサービス開発日記チラシの裏 に書いてあるような仕様に変わったようで関連する箇所が壊れた
  • テスト通す → warning消す → バージョン上げるの繰り返し
  • あとは gem 関連でいくつかハマった気がするけど、基本的にgemを最新にしたら直った気がする
  • ついでなので CI 環境や自動デプロイ、バックグラウンド用にRedis を用意したり、サーバを puma にしたりなど今どきの環境に合わせた
    • どっちかというとこっちのほうが時間かかったかも

所感

それほど大きいサービスではないのもあるけど、Rails 3.2 から 4.2 へのバージョンアップはそれほど苦ではなかった印象。RSpec も transpec 使えばそれほど大変じゃない。

ただいきなりではなく、少しずつバージョンアップしていくのが一番いいと思います…><教訓を活かして packsaddle/ruby-saddlerwillnet/herobu で定期的に bundle update するようにして現状対応しています

Intellij で Rails 開発をするときの注意点

vendor/bundle を使わないこと。

  • 検索に gem のコードが交じる
  • gem に jruby用のコードがあると、java 系のプロジェクトとして判断されるようで普通の Rails アプリとして認識しない

vendor/bundle を無視する設定にすればよいかと思いきや、gem を認識しないのでコード解析的なやつがうまく動かない

IntelliJに挫折中

デバッガを使いたくて、IntelliJを試しています。

がどうもすんなりと移行できません…。

全部入りであるということに魅力を感じて、RubyMine でなく IntelliJ で試しています。ただそうするとプロジェクトがなぜか JRuby on Rails と判断されていろいろうまく動かず。SDK に rbenv は設定しているのですが。

欲張って IntelliJ を使わず、RubyMine を使ったほうがいいのかもしれないですね。

追記

"Open" から進めていくのではなく、Import から進めていくことでうまくいきました。

vue.js で DOM の更新を同期的っぽく行う

vue.js は DOM の更新を非同期で行っている。

同期的にするには全体の設定でVue.config.async = false とする方法があるがこれは微妙。

もう一つの方法としては、Vue.nextTick(callback)を使用してDOMの更新が終わってからの処理をコールバックで記述する方法がある。

参考

Directives - vue.js

draper vs active_decorator

active_decorator はよく使ってるけど draper は README 読んだだけの状態で比較しています。

active_decorator

メリット

  • 実装が比較的シンプル
  • 使い方もシンプル
  • 自動的に model を decorate してくれる

デメリット

  • decorator のメソッドを生やす条件が限られている
    • controller 中にインスタンス変数として定義する
    • partial template の引数として渡す
  • なので、インスタンス変数の関連オブジェクトに対して decorater を適用するのが場合によっては面倒

draper

メリット

  • 関連オブジェクトへの対応がある
  • 複数の decorater を使い分けたり、decorater に変数を渡して挙動を変更したりできる
  • collection に対しても decorator を設定できる

デメリット

  • 基本的に、毎回明示的に decorate するためのメソッドを書く必要がある
  • active_decorator と比較して覚えることが多い

どっちを使ったらいいか

ケースバイケース。draper の方が利用できるシーン自体は多そうだけど、学習コスト高めですね( ˘ω˘)"

schema が変更された時に自動で erd.pdf を更新する

rails-erd、便利なんだけど実行を忘れて古いままでほったらかしてることが多いので、rake db:migrate したら勝手に更新するようにしてみた。

Rake::Task['db:migrate'].enhance do
  Rake::Task[:erd].invoke
end

lib/tasks/erd.rake などを作って書けばおk。