A summer storm

問題点

Rails でデファクトスタンダードとなっているページネーション gem に Kaminari というのがある。

kaminari/kaminari

kaminari/kaminari

kaminari - ⚡ A Scope & Engine based, clean, powerful, customizable and sophisticated paginator for Ruby webapps

github.com

めっちゃ最高便利で大好きなのだけど、巨大なテーブルに対して COUNT 文を投げると遅いという問題にぶち当たった。このような巨大なテーブルで Kaminari を使うために COUNT 文を発行しない without_count というメソッドが用意されている( Kaminari 1.0.0 でやってくる 5 つの大きな変更 - Qiita )が、これを使うと next_pageprev_pagetotal_pages が取れなくなる(当たり前)。次のページがあるかどうかはばくち状態になってしまう。

本当は DB のスキーマを見直すべき(インデックスがちゃんと効くようにスキーマ変更するべき)だが、 Rails からもレガシーアプリからも同時に同じ DB にアクセスしており、並行運用しているような状況ではなかなか大胆な変更は実行できない。

DB 構造をなおせないとなるとキャッシュを思いつく。 HTML も Rails でレンダリングするのであれば partial cache などでページャー部分だけをキャッシュすれば良いが、 API 選任野郎と化した Rails ではビューのキャッシュはできない。

どうしたか

total_count をキャッシュする。公開範囲を設定できるようなリソースだと全員同一のキーでキャッシュするわけにはいかないのでユーザーごとにキーを作ってキャッシュする必要あり。全ユーザーの全リクエストでスロークエリになってたやつが 5 分に一回スロークエリになるくらいだったら何とか許容できる。

例えば以下のようなコントローラーがあったとする。 HeavyModel には数千万レコードあって、普通に COUNT 文を投げると遅い。 Paginatable という名前でモジュールを定義して、 render メソッドを上書きし、ページネーションを間に挟み込む。

class HeavyModelController < ApplicationController
  include Paginatable

  before_action :login_required

  def index
    resources = HeavyModel.all
    render json: resources, paginate: true
  end
end

モジュールはこんな感じ。車輪の再発明をしている感はあるが、 COUNT 文の結果が current_user 、コントローラーのクラス名、アクション名のそれぞれをつなげたものをキーにしてキャッシュされる。

module Paginatable
  def render(*args)
    options = args.extract_options!
    resources = options[:json]
    if options[:paginate]
      resources, meta = paginate(resources, cache_total_count: options[:cache_total_count])
      options[:json] = resources
      options[:meta] ||= {}
      options[:meta].merge!(meta)
    end
    args << options
    super(*args)
  end

  def paginate(resources, options = {})
    parse_params_for_pagination
    paginator = Paginator.new(
      resources:         resources,
      page:              @page,
      per:               @per,
      cache_total_count: options[:cache_total_count],
      cache_key:         total_count_cache_key
    )
    [paginator.resources, paginator.meta]
  end

  def total_count_cache_key
    @total_count_cache_key ||= "#{current_user&.id}_#{self.class.name}_#{action_name}_count"
  end

  class Paginator
    attr_reader :cache_total_count

    UNCOUNTABLE = -1

    def initialize(resources:, page:, per:, cache_total_count: false, cache_key: nil)
      @_resources        = resources
      @page              = page.to_i
      @per               = per.to_i
      @cache_total_count = cache_total_count
      @cache_key         = cache_key
    end

    def resources
      @resources ||= if cache_total_count?
                       @_resources.page(page).per(per).without_count
                     else
                       @_resources.page(page).per(per)
                     end
    end

    def page
      @page.zero? ? 1 : @page
    end

    def per
      @per.zero? ? Kaminari.config.default_per_page : @per
    end

    def meta
      {
        current_page: current_page,
        next_page:    next_page,
        prev_page:    prev_page,
        total_pages:  total_pages,
        total_count:  total_count
      }
    end

    alias cache_total_count? cache_total_count

    def paginatable?
      !cache_total_count? && resources.respond_to?(:total_count)
    end

    def current_page
      resources.current_page || page
    end

    def next_page
      paginatable? ? (resources.next_page || UNCOUNTABLE) : next_page_fallback
    end

    def next_page_fallback
      return UNCOUNTABLE if page < 1
      return UNCOUNTABLE if per > resources.length
      total_count_fallback > current_page * per ? current_page + 1 : UNCOUNTABLE
    end

    def prev_page
      paginatable? ? (resources.prev_page || UNCOUNTABLE) : prev_page_fallback
    end

    def prev_page_fallback
      return UNCOUNTABLE if page < 2
      (total_count_fallback.to_f / per).ceil >= page ? current_page - 1 : UNCOUNTABLE
    end

    def total_pages
      paginatable? ? resources.total_pages : (total_count.to_f / per).ceil
    end

    def total_count
      paginatable? ? resources.total_count : total_count_fallback
    end

    def total_count_fallback
      @total_count_fallback ||=
        begin
          cached_total_count = Rails.cache.read(@cache_key)
          if cached_total_count
            cached_total_count
          else
            real_total_count = @_resources.page(page).total_count
            Rails.cache.write(@cache_key, real_total_count, expires_in: 5.minutes)
            real_total_count
          end
        end
    end
  end
end

これで 5 分間はキャッシュが効くようになる。

Say Farewell to Fat Model.png

ルビーオンレイルザーの皆さん、 Fat モデル対策やってますか。 Fat モデル対策と言えば Concern ですね。 app/models/concerns/ ディレクトリに module を置いてモデルに include させるというアレです。

Put chubby models on a diet with concerns

Put chubby models on a diet with concerns

Different models in your Rails application will often share a set of cross-cutting concerns. In Basecamp, we have almost forty such concerns with names like Trashable, Searchable, Visible, Movable, Taggable. These concerns encapsulate both data access and domain logic about a certain slice of re…

しかしただ module を作って Fat モデルのコードを移動し、元のモデル側に include させるだけでは結局モデルのインスタンスに生えるメソッドの数に変わりはないので臭いものに蓋をしてるだけになります。 Rubocop の Metrics/LineLength 警告を逃れるためだけの module 乱立はあんまり意味がないでしょう。間違って別の module で同名のメソッドを定義してしまい意図しない挙動になってしまうことも考えられます。

最近自分がやってるのは、 include される module に定義するメソッドはせいぜい一つか二つにして、このメソッドから別クラス( Plain Old Ruby Object)に定義したメソッドを呼び出す(委譲する)というものです。モデルに得体の知れないメソッドが増えないので便利。

例えば以下のようなモデルがあるとします。

  • app/models/entry.rb
  • app/models/comment.rb

両方ともレコードの新規登録があったときに通知を行いたい。共通の処理なので Notifiable モジュールを作ってそれを Entry モデルと Comment モデルでそれぞれ include しましょう。ここまでは皆さんよくやると思います。

  • app/models/concerns/notifiable.rb
module Notifiable
  private

  def notify
    # do something
  end
end
class Entry < ApplicationRecord
  include Notifiable
  has_many :comments
  after_commit :notify, on: :create
end
class Comment < ApplicationRecord
  include Notifiable
  belongs_to :entry
  after_commit :notify, on: :create
end

しかし Entry と Comment では通知内容が異なるので単純に #notify メソッドを callback で実行すればよいというわけではない。通知用パラメーターを生成する処理をモデルに書くとよいのですが、そういうのを繰り返した結果が Fat モデル地獄なので通知内容を生成するクラスを別に作ります。こんな感じ。

  • app/models/concerns/notifiable/entry_notification.rb
  • app/models/concerns/notifiable/comment_notification.rb

Base クラスを作って共通処理をまとめ、継承させると便利でしょう。

  • app/models/concerns/notifications/base_notification.rb
module Notifiable
  class BaseNotification
    def initialize(object)
      @object = object
    end

    def perform
      NotificationJob.perform(notification_params)
    end
  end
end
module Notifiable
  class EntryNotification < BaseNotification
    def notification_params
      {
        recipient_ids: @object.subscriber_ids,
        title: @object.title
      }
    end
  end
end
module Notifiable
  class CommentNotification < BaseNotification
    def notification_params
      {
        recipient_ids: @object.thread_joiner_ids,
        title: @object.body.truncate(25)
      }
    end
  end
end

Notifiable モジュールはこんな感じになります。

module Notifiable
  private

  def notifiy
    notification.perform
  end

  def notification
    "#{self.class}Notification".constantize.new(self)
  end
end

図にするとこんな感じ。

Rails Fat Model Strategy.png

この Notifiable モジュールを include しても Model には #notify メソッドと #notification メソッドしか追加されず、通知処理の実装をモデルから分離することができます。 Entry クラスも Comment クラスも #notify メソッドより先のことは何も気にしなくてよくなる。リソースが追加されたときに #notify メソッドを実行することだけに責任を持てばよいし、通知を飛ばすという処理自体は Notifiable::EntryNotificationNotifiable::CommentNotification クラスの責任になります。

私はこれで Fat モデルのコードを concerns ディレクトリにしまい込んで臭いものに蓋をするような対応におさらばしました。よろしければお試し下さい。またもし他に良い方法をご存じであれば教えて下さい。

去年の年末に Rails に大掃除も年賀状もやらずに Rails に Pull Request を出してた。

ActionMailer のプレビューで locale が複数ある場合に指定できるようにするというもの。 Kaizen Platform の Rails アプリにはこの機能付いてて多言語対応のメールをプレビューするときにめっちゃ便利だった。調べたところ Rails 4 時代にそういう Pull Request 出してた人がいて Merge 寸前まで行ってたんだけど commit が複数に分かれてたのを「 squash してくれない?」とレビューされたところでプルリク主の意欲が燃え尽きたっぽくて Merge されずにコンフリクトして死んでた。

Add locale selector to email preview by plus3x · Pull Request #19923 · rails/rails

Add locale selector to email preview by plus3x · Pull Request #19923 · rails/rails

@rafaelfranca Fix of #19922

github.com

Rails 5 でも動くようにコンフリクトを解消してテストケースも追加したのが以下。

Add locale selector to email preview by morygonzalez · Pull Request #31596 · rails/rails

Add locale selector to email preview by morygonzalez · Pull Request #31596 · rails/rails

Summary This Pull Request make it possible to select location on ActionMailer Preview. Just like below. This is a rework of #19923. #199...

github.com

動作イメージはこんな感じ。

34454066\-f8bf06ec\-eda5\-11e7\-82ba\-1c2a0961b6b8\.gif \(833×768\)

ただ Merge 後にバグってるのを指摘されていま直してるところです。

Fix locale_selector JS bug in ActionMailer Preview by morygonzalez · Pull Request #31750 · rails/rails

Fix locale_selector JS bug in ActionMailer Preview by morygonzalez · Pull Request #31750 · rails/rails

Summary Fix bug arise from the Pull Request #3159 . locale_select only appears in I18n.available_locales.count &gt; 1. So if users have...

github.com

頭良くないのでこういうしょぼい Pull Request でしか contribute できないけど自分にできる範囲で貢献していきたい。

追記 2018-01-24

問題を修正する Pull Request も Merge してもらったんで多分 Rails 5.2 にこの機能入ります

Rails 5.1 から入った Encrypted Secrets というのがある。 OAuth の client_secret などパスワード的なやつを暗号化して保存する仕組み。この手のやつはこれまで環境変数などにして dotenv などの機能を使ってそれぞれの環境ごとに .env ファイルを置く、というのがベストプラクティスだったと思うけど、 Encrypted Secrets を使えば秘密情報も暗号化してリポリトリに放りこめるので管理対象が少なくなって便利になる。暗号化するときの鍵は RAILS_MASTER_KEY という環境変数に格納するか、 gitignore した上で config/secrets.yml.key という名前で配置すると Rails がいい感じに読み取ってくれる。

Rails のエコシステムには config (旧 rails_config )という gem もあって、こいつも設定系の情報を入れておく用途によく使う。秘密系の情報と設定系の情報でどちらに値が入っているかを意識するのがめんどい& Rails.application.secrets.foo_bar とか入力するのが長い& Encrypted Secrets は YAML をネストさせられないのがだるいので、 config.gem の config/settings.yml の中で以下のようにしたら便利ではないかと思ってやってみた。

foo:
  bar: <%= Rails.application.secrets.foo_bar %>

呼び出し側の before after はこんな感じ。

Before

bar = Rails.application.secrets.foo_bar

After

bar = Settings.foo.bar

「めっちゃ最高便利じゃん」と思っていたけど、これをやると副作用がでかい。なんと Rails.application.secretsfoo_bar が見つからなくなる! というか Rails.application.secrets がほぼほぼ空になる!!!、!

[3] pry(main)> Rails.application.secrets
=> {:secret_key_base=>"xxx", :secret_token=>nil}

config/settings.yml から Encrypted Secrets を参照しているコードを取り除くと見えるようになる。

結論

というわけで config/settings.yml の中に Rails の Encrypted Secrets を混ぜて使うと危険っぽいです ☢️

九州新幹線

関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分も Pull Request 送ったりしたのでやったことを書いときます。

1. session に注意

Rails 4 から Flash メッセージ(ログインしましたとか)を格納する session のオブジェクトが普通の Hash になってる。 Rails 3 ではこれは FlashHash とかいうやつ。

Rails 3 から Rails 4 へのアップグレードで一旦 Rails 4 を出してやっぱりやめて Rails 3 に戻したりとか、ロードバランサーに Rails 3 と Rails 4 で動くサーバーを混ぜてリクエスト捌いたりするとまずいことになる。

Rails 4 のサーバーで session 出来た人が次にリクエストしたときに Rails 3 に当たるとログイン後とかに session に残っているメッセージを消そうとする処理とかで NoMethodError が発生して落ちてしまう。しかもたちが悪いことに Rack 層で死んでしまったりするから皆さんよく使ってると思われる ExceptionNotification とかで気づくことが出来ない。これはつらい。

対処法としては Hash クラスをオープンしてモンキーパッチするというのがある。こういうの。

Rails 4 FlashHash Upgrade Gotcha | Jason Neylon's Blog

↑のだと #alert とか #notice が呼ばれたときにエラーになるので自分は以下のようにした。

# NOTE Rails 4 と Rails 3 を混ぜて使うと Hash#sweep が見つからなくてエラーに
# なるようなのでモンキーパッチします。
# 参照: http://jasonneylon.wordpress.com/2014/08/27/rails-4-flashhash-upgrade-gotcha/

class Hash
  def now
    Rails.logger.warn "Stubbing now during upgrade"
    {}
  end

  def keep
    # stub keep for upgrade purposes
    Rails.logger.warn "Stubbing keep during upgrade"
  end

  def sweep
    # stub sweep for upgrade purposes
    Rails.logger.warn "Stubbing sweep during upgrade"
  end

  def alert
    Rails.logger.warn "Stubbing alert during upgrade"
    self[:alert]
  end

  def notice
    Rails.logger.warn "Stubbing notice during upgrade"
    self[:notice]
  end
end

ただこれもパーフェクトではなくて、何もしないように上書きしているだけなのでログイン後のメッセージとか削除後のメッセージが消せなくなったりする。それでも 500 エラーになるよりかはましなのでどうしても Rails 3 と Rails 4 を混ぜて投入したいみたいときなんかは有効。

2. 絵文字に注意

Rails 3 の頃は ActiveRecord が絵文字を DB に保存することが基本的になかった。ユーザーが POST してきたフォームの中に絵文字が含まれてたら絵文字のところでテキストをぶった切って DB に保存するような挙動だった。しかし Rails 4 からは ActiveRecord は絵文字を素通りさせるようになってしまったので困ったことになる。

絵文字を DB に保存するためには、 MySQL の場合は DB のテキストエンコーディングを utf8mb4 というやつにしてないといけない。ただの utf8 だと保存時に Mysql2::Error: Incorrect string value というエラーが出て DB に保存できない。emojimmy のような gem を使えば utf8mb4 でない DB でも使えるけど、 stores_emoji_characters :column_name を忘れずにモデルに定義しないといけない。たとえば購入時に購入した製品のスナップショットを注文テーブルに取るような DB 設計だと、製品テーブルのカラムは stores_emoji_characters してたとしても注文テーブルのカラムを stores_emoji_characters し忘れていて死亡、というような悲劇が起こり得る。

いまはスマートフォンの時代で、ユーザーが入力してくるフィールドには必ず絵文字が含まれると思っておいた方がいい。スマートフォンをメインで使ってる人たちは開発者が想定しないようなフィールド(名前の敬称とか)に平気で絵文字を使ってくる。下手すりゃ住所や名前にも絵文字を入れて送ってくるかも知れない。アスキー文字しか受け付けないようなフィールドは JavaScript やサーバーサイドでバリデーション行ってると思うけど、マルチバイト文字列を受け付けるフィールドの場合はせいぜい長さくらいしかチェックしてないと思う。チェックを入れて絵文字を弾くことも可能だけど、スマートフォンの時代の流れに反しているしユーザーを失うことになりそう。これから新規でサービスを作ってデータベースに MySQL を使う場合はエンコーディングは utf8mb4 にしておいた方がいい。

他にも script/rails が bin/rails に変わってること忘れてて rails runner なバッチ処理が動いてなかったとか、 paranoia.gem の Rails 4 対応バージョンで物理削除のときに呼び出すメソッド名が変わっててはまったとかいろいろあったけど大きなところは上の session と絵文字だった。開発環境で使ってるときには気がつかず本番に出すまで気がつきにくいという意味で非常にやっかいな現象だと思う。

これから Rails 4 に上げる皆さんは頑張ってください。応援しています。

あるモデルがあって、#save が実行されたときに同一モデル内で複製したインスタンスも一緒に保存したかった。一個目の #save が走る前にコールバックメソッドを使って複製したインスタンスを保存するようにした。コードだと以下のような感じ。

class Model
  before_validation :method_one
  before_create :method_two

  def method_one
    ...
  end

  def mothod_two
    Model.reset_callbacks(:validation)
    Model.reset_callbacks(:create)

    @model = Model.new
    @model.save
  end
end

なんで reset_callbacks 呼んでるのかというと二回コールバックメソッドを走らせないため。一回目の #save (コントローラーから呼ばれる)が呼ばれたときだけコールバックメソッドを実行して、二回目の #save (モデルのコールバックメソッド内で呼ばれる)では実行したくないから。

しかしここではまってしまった。なんとコールバックメソッドで複製したドキュメントを DB 内で確認すると created_at が空になっている。なんじゃこりゃ。

どうも reset_callbacks(:create) がいかんかったみたい。ORM が実行する create 周辺のコールバックメソッドも軒並みリセットされてしまう模様。

そういうわけで以下の様にして解決した。

class Model
  before_validation :method_one
  before_create :method_two

  def method_one
    ...
  end

  def hoge
    Model.skip_callback :create, :before, :sell
    Model.skip_callback :create, :after, :send_notification
    Model.reset_callbacks(:validation)

    @model = Model.new
    @model.save
  end
end

callback、便利だけど奥が深い。ちなみにこれら skipp_callback とか reset_callbacks とかは ActiveModel や ActiveRecord (僕はMongoidで開発してます)などの OR マッパーのメソッドではなく、 ActiveSupport::Callbacks のメソッドだったりします。ActiveSupport も奥が深い。