n_plus_one_controlはrequest specで使うのが良いという話とrequest specでログイン後のリクエストを投げるための方法について

savanna.io の日報からの転載。ちゃんと整形したり説明詳しく入れてメインのブログで公開しようと思ってたんだけど時間がなさすぎた

  • palkan/n_plus_one_control: RSpec and Minitest matchers to prevent N+1 queries problem
    • N+1をテストで検出できて便利
    • 実際に同じテストを、DBレコード数だけ変えて複数回実行して発行したクエリ数を比較する
    • クエリ数が違うとN+1では？となりテストを失敗させることができる
  • N+1が起きるのは実際のユーザがアクセスしたときなので、システムスペックでは、と思いそうしていた
  • しかしsystem specだと、ajaxを利用しているページを表示したときにタイミング次第でajaxリクエスト処理時のSQLを計算に入れてしまいテストがコケる
  • 具体的にはturbo-frameで遅延ロードを追加ところこれが発覚したけど、turbo-frameに限らずajax使っているページでは起こり得る
  • 他になんかいい方法あるかな、と考えたがN+1をチェックするところはrequire specを使うのがいいんじゃないか、という結論に達した

request specでログイン後のリクエストを投げる

  • ↑ということでrequest specを久しぶりにちゃんと書こうと思ったらログインどうやるんだっけ？となったのでまとめた

1. allow_any_instance_of

  • 手っ取り早いがハック感ある
before do
  allow_any_instance_of(ApplicationController).to receive(:current_user).and_return(ログインさせたいユーザオブジェクト)
end

2. session

get root_path
session[:user_id] = user.id
get after_login_path
  • これはうまく動かなかった
  • 最初にroot_pathにアクセスしているのは、sessionメソッドが@requestが存在している前提で書かれており、最低一度アクセスしないといけないため
  • 昔はこれで実装していたような記憶がうっすらあるが、Rails5からはできなくなったのかも

3. ログイン用のリクエストを事前に投げる

  • request specもE2Eの一種と考えると、ちゃんとログイン用のリクエストを投げるのがお行儀が良いのでは、という気がする
  • dhhも推奨している方式
  • これはOmniAuthでtwitterログインしている前提
OmniAuth.config.test_mode = true
OmniAuth.config.mock_auth[:twitter] = OmniAuth::AuthHash.new(
  provider: 'twitter',
  uid: idをいれる,
  info: {
    nickname: ユーザ名をいれる
  }
)  
post '/auth/twitter'
follow_redirect! # OmniAuthはリダイレクト後にログインセッションを生成しているのでこれがないとログインできない

type="date"なフォームをcapybara+chromeでテストするには

Docker環境でRubymineを使う

  • Rubymineはコードジャンプがべんり
  • gemのソースコードにもサッとジャンプできる
  • しかしDockerで開発していると、gemのコードはコンテナの中なのでそのままだとジャンプできない
  • これまではやむを得ずホスト側でbundle installとかしてたけど、設定でコンテナ側のgemを参照できるのだった(当たり前)

やり方

Preferences→Languages & Frameworks→Ruby SDK and Gemsで+を選択、New remoteを選択して次のようにして新しい設定を作成し、それを選択してapplyすればOK(appとしているところは各自のrails用コンテナに読み替えてください)

f:id:willnet:20210223142323p:plain

USキーボード環境で英数キーを⌘+スペースに割り当てた

ずっと左コマンドを単体で押したときに英数、右コマンドを単体で押したときにかなとしていたけど、左コマンドキーを押してすぐキーをタイプするとミスってタブを閉じてしまったりなどすることがよくあった。

我慢して使っていたのだけど、だれかのツイートでコマンドとスペースを利用して切り替えるようにした、というのを見かけてこれ良いのでは？となったのでkarabinerの設定を↓のように変えた。左コマンドだけスペースが必要にしてみた。右コマンドは単体でしか押さないので従来どおり。

~/.config/karabiner/karabiner.json を以下のように編集した

               "rules": [
                    {
                        "description": "右コマンドキーを単体で押したときに、かなキーを送信する",
                        "manipulators": [
                            {
                                "from": {
                                    "key_code": "right_command",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "parameters": {
                                    "basic.to_if_held_down_threshold_milliseconds": 100
                                },
                                "to": [
                                    {
                                        "key_code": "right_command",
                                        "lazy": true
                                    }
                                ],
                                "to_if_alone": [
                                    {
                                        "key_code": "japanese_kana"
                                    }
                                ],
                                "to_if_held_down": [
                                    {
                                        "key_code": "right_command"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    },
                    {
                        "description": "左コマンドキーとスペースを押したときに英数キーを送信する",
                        "manipulators": [
                            {
                                "from": {
                                    "key_code": "spacebar",
                                    "modifiers": {
                                        "mandatory": [ "left_command" ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "japanese_eisuu"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    }
                ]
            },

追記

右コマンドキーは単純にかなキーに入れ替えたほうが安定したので、結局上記の右コマンドキー側の設定は削除しました。

家のインターネット環境を安定させた

自宅で作業するのが増えた結果、インターネットが遅くなったり、ルーターとの接続が切れたりするのに気づくことが増えた。ので設定を変更してなんとかしたぞというメモ

前提

  • niftyのv6プラスを利用済み
    • ルータの近くだと20~30Mbpsくらいでる
    • v6プラス以前は1Mbpsとか。ひどい有様だった…
  • 有線は部屋の配置の問題でケーブルをひくのが難しいので無線でやるしかない
  • PCは窓際なので、外の電波に影響を受けている可能性が高そう

やった(やっている)こと

  • 5GHz帯を使う
  • 利用チャンネルを動的に変更するように設定を変更
    • 時間によって接続が不安定になった&&ルーター近くだと安定していたので、外の電波と関係があるのではと推測
  • チャンネルを束ねて高速化する機能をオフにした
    • 有線でも20~30Mbpsしかでないのにチャンネルを束ねる必要はなかった
    • 束ねた結果、外の電波と干渉して接続を失ったのではないかと推測

Railsのbelongs_toによるバリデーションと外部キー制約って重複しているような気がする

表題のとおりなのですが。

class Post < ApplicationRecord
  belongs_to :user
end

↑のように書いたときに、Rails5からは自動でvalidation_presence_of :userとしたのと同じになります。postをバリデーションするときにuserの存在をチェックする必要があるので、userが未ロードであればクエリが発行されます。一度にたくさんのpostを保存するようなケースでN+1が発生して困った経験がある人もいるのではないでしょうか。

./bin/rails g model post user:references のようにした場合は、次のように外部キー制約とbelongs_toが両方定義された状態になりますね。

class CreatePosts < ActiveRecord::Migration[6.0]
  def change
    create_table :posts do |t|
      t.references :user, null: false, foreign_key: true

      t.timestamps
    end
  end
end

class Post < ApplicationRecord
  belongs_to :user
end

しかし、PostからUserへ外部キー制約を貼っていればvalidation_presence_of :userは不要では？という気がします。むしろ無駄にクエリが発行される分マイナスなような気もする。

次のようにすればOKではあるけれど、実際は必須なのにoptional: trueと書かなければいけないなのが大変微妙。

class Post < ApplicationRecord
  belongs_to :user, optional: true
end

と、ここまで書いていて気がついたけど論理削除のようなしくみを採用していた場合は外部キー制約では不十分ですね…とりあえず今回のケースではそれは考慮しないとします…＞＜

このへん、みんなどのように解決しているのでしょうか？コメントほしいです(\( ⁰⊖⁰)/)

  1. 外部キーを使っておらず、belongs_toによるバリデーションを利用している
  2. Railsが生成するデフォルトのように、外部キーとbelongs_toによるバリデーションを両方使っている
  3. 外部キーのみ使用しており、belongs_toによるバリデーションはオフにしている
  4. その他

追記