週刊Railsウォッチ: Active Recordのattribute更新系メソッド比較リスト、Railsリファクタリングガイドほか（20220425前編）

こんにちは、hachi8833です。RuboCopが10歳になりました🎉

• 元記事: RuboCop Turns 10 | Meta Redux（Hacklinesより）
• アニバーサリー版: Release RuboCop 1.28 (a.k.a. The 10th Anniversary Edition) · rubocop/rubocop

🔗Rails: 先週の改修（Rails公式ニュースより）

今回の改修はかなり件数が少なかったので範囲を広げて見繕いました。小粒揃いです。

• コミット差分: Comparing @{2022-04-08}...main@{2022-04-21} · rails/rails

🔗 config.enable_reloadingを追加

• PR: Define config.reload to be !config.cache_classes by fxn · Pull Request #44870 · rails/rails

config.cache_classesを設定するたびに、この設定が正しいかどうかいちいち考え込んでしまう。無駄に考えさせる設定。
一方、config.reload = trueという記述を見れば、アプリケーションがリロードされるであろうことは考えるまでもなく一瞬でわかる。
人は「リロードは有効なのか無効なのか？」と機能に沿って考えるものだ。しかもRubyプログラムでは、クラスが「キャッシュされる」という言い方はしない。必要なのは、カスタムのリロード機能を表す語だ。
このリファクタリングについて解説する。

unless config.cache_classes && config.eager_load    ⇔ (unlessは「if !」と同じ)
    if !(config.cache_classes && config.eager_load) ⇔ (!(A && B) は !A || !Bと同じ) 
    if !config.cache_classes || !config.eager_load  ⇔ (!config.cache_classes は config.reload と同じ)
    if config.reload || !config.eager_load

config.cache_classesはずっと前からあるので、今さら非推奨化するのは実用的ではないと思う。それよりも、新しいアプリを生成するとこの新しいconfig.reloadを使うようにし、これが現在の推奨フラグであることをドキュメントに書いて推奨しつつ、config.cache_classesを非推奨化せずに引き続きサポートすることを提案したい。Rails 8になったら非推奨サイクルを開始してもいいかもしれないが、この点は議論の余地がある。
同PRより

---

つっつきボイス:「config.cache_classesというコンフィグの意味がわかりにくいので、config.enable_reloadingというコンフィグを追加したらしい」「!config.cache_classesと同等なんですね」「たしかにconfig.enable_reloadingの方がいい名前👍」

より直感的な名前にするために、config.enable_reloading（!config.cache_classesと同じ）が定義された。今後はconfig.enable_reloadingとconfig.reloading_enabled?が推奨されるが、後方互換性のためconfig.cache_classesも引き続きサポートする。
Xavier Noria
同Changelogより

🔗 config.enable_dependency_loadingが非推奨化

• commit: Deprecate config.enable_dependency_loading · rails/rails@cbfe735

config.enable_dependency_loadingを非推奨化。このフラグは（Zeitwerk以前の）classicオートローダーの制約を正すためのものだが現在は無効。この非推奨化メッセージを修正するために、この参照を削除して欲しい。
Xavier Noria
同PRより

# railties/lib/rails/application/configuration.rb#L300
+     ENABLE_DEPENDENCY_LOADING_WARNING = <<~MSG
+       This flag addressed a limitation of the `classic` autoloader and has no effect nowadays.
+       To fix this deprecation, please just delete the reference.
+     MSG
+     private_constant :ENABLE_DEPENDENCY_LOADING_WARNING
+
+     def enable_dependency_loading
+       ActiveSupport::Deprecation.warn(ENABLE_DEPENDENCY_LOADING_WARNING)
+       @enable_dependency_loading
+     end
+
+     def enable_dependency_loading=(value)
+       ActiveSupport::Deprecation.warn(ENABLE_DEPENDENCY_LOADING_WARNING)
+       @enable_dependency_loading = value
+     end

---

つっつきボイス:「上に続いてZeitwerkの@fxnさんによるコミットです」「これもRailsのオートロード関連ですね」

参考: Classic から Zeitwerk への移行 - Railsガイド

🔗 ドキュメント: host_configurationをhost_authorizationに修正

• PR: fix: config.host_authorization reference by ShaneBoyer · Pull Request #44869 · rails/rails

# guides/source/configuring.md#L509
You can exclude certain requests from Host Authorization checks by setting
-`config.host_configuration.exclude`:
+`config.host_authorization.exclude`:

# Exclude requests for the /healthcheck/ path from host checking
-Rails.application.config.host_configuration = {
+Rails.application.config.host_authorization = {
  exclude: ->(request) { request.path =~ /healthcheck/ }
}

When a request comes to an unauthorized host, a default Rack application
will run and respond with `403 Forbidden`. This can be customized by setting
-`config.host_configuration.response_app`. For example:
+`config.host_authorization.response_app`. For example:

-Rails.application.config.host_configuration = {
+Rails.application.config.host_authorization = {
  response_app: -> env do
    [400, { "Content-Type" => "text/plain" }, ["Bad Request"]]
  end
}

---

つっつきボイス:「英語版のRails Guidesの設定パラメータが間違っていたのが修正されたのか」「host_configurationというコンフィグは見たことないですね」「早速Railsガイドにも修正プルリクを投げました↓」

参考: configuring.mdを修正 by hachi8833 · Pull Request #1233 · yasslab/railsguides.jp -- マージ済み

🔗 ドキュメント: primary_keyに関する不要な記述を削除

• PR: Remove unnecessary note for primary_key in the guide by pocke · Pull Request #44911 · rails/rails

# guides/source/active_record_migrations.md#L354
By default, `create_table` will create a primary key called `id`. You can change
-the name of the primary key with the `:primary_key` option (don't forget to
-update the corresponding model) or, if you don't want a primary key at all, you
-can pass the option `id: false`. If you need to pass database specific options
-you can place an SQL fragment in the `:options` option. For example:
+the name of the primary key with the `:primary_key` option  or, if you don't
+want a primary key at all, you can pass the option `id: false`. If you need to
+pass database specific options you can place an SQL fragment in the `:options`
+option. For example:

---

つっつきボイス:「これもドキュメント修正で、@pockeさんが英語と合わせて日本語↓も修正してくださいました🙇」「ありがたい🙏」

参考: Remove unnecessary note for primary_key in AR migration guide by pocke · Pull Request #1232 · yasslab/railsguides.jp

🔗 issue: マルチプルDBでnon-primary DBのマイグレーションのステータスがdownでもActiveRecord::PendingMigrationErrorが発生しない

• issue: ActiveRecord::PendingMigrationError is not raised when non-primary database migration is down with multi-db · Issue #37524 · rails/rails

再現手順
マルチプルDBでprimary以外のDBマイグレーションのステータスがdownでもActiveRecord::PendingMigrationErrorが発生しない。

# config/database.yml
development:
  backbone:
    <<: *default
    database: backbone_development
  library:
    <<: *default
    database: library_development
    migrations_paths: db/library_migrate

以下を実行してhttp://localhost:3000/users か http://localhost:3000/books を開く。

bin/rails g scaffold User title
bin/rails g scaffold Book title --db library
bin/rails db:create db:migrate
bin/rails s
# 別のコンソール
bin/rails g migration add_published_at_to_books published_at:datetime --db library

期待される動作
add_published_at_to_booksマイグレーションのステータスがdownなのでActiveRecord::PendingMigrationErrorが発生する。

$ bin/rails db:migrate:status

database: backbone_development
 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20191022014341  Create users

database: library_development

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20191022023152  Create books
  down    20191022023755  Add published at to books

$ rails db:abort_if_pending_migrations
You have 1 pending migration:
  20191022023755 AddPublishedAtToBooks
Run `rails db:migrate` to update your database then try again.

実際の動作
エラーが発生しない。
システム構成
Rails 6.0.0
Ruby 2.6.5
同issueより

---

つっつきボイス:「あ〜、たしかにnon-primaryのDBでマイグレーションがpendingなのにPendingMigrationErrorエラーが出ないのはつらい」「まだ修正プルリクは出ていないみたい」「ちなみに以下のマイルストーンで見つけたissueです↓」

参考: 7.0.2 Milestone

「このissueは発生の条件が少し厳しくて、マルチプルデータベースでprimaryとnon-primaryの両方を同じRailsリポジトリで管理しているときに発生するっぽい」「なるほど」「マルチプルデータベースを本格的に使っていないとなかなか踏まないバグかも」

参考: Active Record で複数のデータベース利用 - Railsガイド

「DBのロールバックって普段あまりやらないかも」「マイグレーションがどのぐらいちゃんと書かれているか調べないとロールバックするのは怖いです」「ロールバックする可能性がありそうな箇所なら時間をかけてでも検証しますけどね」

🔗Rails

🔗 GitHubが行ったRailsのパフォーマンス改善（Ruby Weeklyより）

Latest from the GitHub Engineering Blog... learn how we made 50ms+ savings in response times by moving telemetry code out of the critical path. https://t.co/LfZaexljT3

— GitHub (@github) April 11, 2022

---

つっつきボイス:「へ〜、rack.after_replyなんてのがあるのね」「rack.after_replyは元々Pumaの拡張で、リクエストが完了したあとでコールバックを呼び出す機能らしい」

「GitHubはWebサーバーにPumaではなくUnicornを使ってると書かれてる」「そういえばGitHubはUnicornをマルチスレッド・マルチプロセスで使っているという話を昔見たような気がしますけど、今もUnicornを使ってるんですね」「Pumaのrack.after_replyを使いたいけどUnicornには実装されていなかったので、Unicornにパッチを投げたそうです」「その気持わかる」「GitHubは技術ブログを着実に更新していていいですね👍」

# 同記事より（改行を削減）
class AfterResponse
  def initialize(env)
    env[“rack.after_reply”] ||= []
    env[“rack.after_reply”] << -> do
      self.call
    end

    @to_perform = []

  end

  # Calls each callable defined via #perform
  def call
    @to_perform.each do |block|
      begin
        block.call(self)
      rescue Object => e
        Rails.logger.error(e)
      end
    end
  end

  # Adds given block to the array of callables that will
  # be called after the user has received the response.
  def perform(name, &block)
    @to_perform << block
  end
end

🔗 Rails 7版: Active Recordのさまざまなattribute更新系メソッドの比較リスト（Ruby Weeklyより）

• 元記事: Different Ways to Set Attributes in ActiveRecord (Rails 7)

---

つっつきボイス:「お、定番のActive Record attribute更新系メソッドの挙動比較表」「コールバックを呼ぶものや呼ばないものかあったりしますね」

同記事より

「upsert_allはタイムスタンプがセットされないみたいな点は注意が必要」「そうそう、コールバックとタイムスタンプ更新は連動するので、コールバックが呼ばれないメソッドではActiveRecord::Timestampが呼ばれない」「たしかに」「この表を丸覚えするよりは、挙動を理解する方が覚えやすいでしょうね: いい情報👍」

「Rails 6以前向けの記事リンクも記載されていました↓」「こういう記事はこまめに更新しないといけないのが大変」「たまに記事が間違ってたり古かったりするとハマりますよね」

• 元記事: Different Ways to Set Attributes in ActiveRecord (Rails 6)
• 元記事: Different Ways to Set Attributes in ActiveRecord (Rails 5)
• 元記事: Different Ways to Set Attributes in ActiveRecord (Rails 4) -- 別サイト記事
• 元記事: Different Ways to Set Attributes in ActiveRecord (Rails 3) -- 別サイト記事

「assign_attributesはattributes=のエイリアスなのね」

参考: ActiveModel::AttributeAssignment

「そういえばQiitaにも以前似たような記事があった気がします」「そうそう、これですね↓」

参考: ActiveRecord の attribute 更新方法まとめ - Qiita

---

そういえばupdate_attributesとupdate_attributes!はRails 6.1でそれぞれupdateとupdate!に移行したのでした↓。

参考: Deprecate update_attributes and update_attributes! by elebow · Pull Request #31998 · rails/rails
参考: Rails 6 deprecates update_attributes and update_attributes! | Saeloun Blog

🔗 Railsリファクタリングガイド

Ruby - Zenn 脱Rails初心者のためのリファクタリングガイド https://t.co/BzhyESAF4A

— tomi rss (@tomirss) April 17, 2022

---

つっつきボイス:「リファクタリング記事は定番ですね」「慣れていない人は読んでおくといいと思います👍」

「『リファクタリング時にspecも一緒に作る』、その通り！」「そうそう」「何をするにもspecを揃えてから作業すべき」

「テストがないコードは、そもそもテストしにくかったりできなかったりすることもよくある」「その場合は、まずテストを書いて正しく動くようにコードを改修するところから始めないといけない」「ああ、それつらいヤツです」

「この記事を書いた方はフリーランスのエンジニアなのか」「フリーランスの場合、プロパーとしてチームに常駐する人とはアプローチが異なってくる面もありますね: プロジェクトのメンバーや特性などでも変わってきますが」

「フリーランスの場合、最初の1か月である程度の成果を出すことを求められることもよくあると思いますけど、足りないテストを増やすというタスクは、そういうときに少しずつでも成果を出せるのが嬉しい」「少なくともテストを増やすことで既存のコードが悪くなる心配はないですよね」「既存プロジェクトへの途中参加案件で直近取り組める手頃なサイズのタスクが無い場合に、進捗を刻んで開発の流れに乗っていくためにまずテストを書くことを提案することもあります」

🔗 環境変数でテストが壊れやすくなる問題（Ruby Weeklyより）

• 元記事: How environment variables make your Ruby test suite flaky

---

つっつきボイス:「環境変数で挙動が変わる部分のテストを書いたら思わぬ挙動をしたという記事だそうです」「近年は環境変数でアプリの挙動を変えることが増えていますけど、どこまで環境変数でやるのかは悩ましいところ」「そうそう」

「記事では、問題を起こす環境変数をメソッドで渡すように変えることで、環境変数によって挙動が変わらないようにしたんですね」

「たとえば外部APIに依存するアプリで、APIをスタブモードに切り替えるのに環境変数を使ったりしますよね」「APIが有料だったり、顧客のプライベートなネットワークでしかアクセスできないような場合は、そうやって環境変数で切り替わるようにしないとローカルで開発できない」「ついこの間まさにそういうコードを書きました」「おそらくダミーのAPIサーバーを立ててそちらにアクセスする方がいいんでしょうけど、工数が増える」「そうなんですよ」「環境変数で挙動が変わる部分はテストを書いておきたい」

「ちなみに今やっているプロジェクトの環境変数は、開発環境向けのものなので数は抑えているんですが、それでもかなり多い」「そうなりますよね」

---

追いかけボイス: 「RSpecのbefore do の中でENV['hoge'] = 'piyo'のようにENVを設定してしまうと、ENVの値はafterで元の値に復元されたりunsetされたりしないので、テストの実行順序が変わると落ちるようになってしまうことがあります: これを回避するにはbeforeで環境変数を一時退避してafterで戻すなどの対応が必要になりますが、マルチスレッドが絡むとさらにおかしくなることもあります」

🔗 Webpackerからimportmap-railsへの移行

• 元記事: Webpacker から importmap-rails に移行した - Qiita

つっつきボイス:「Webpackerからimportmap-rails、大変そう」「疲れさまです」「ぼくも同じような記事書いたんでした↓」「こういう知見はありがたい👍」

• 元記事: Rails6のアプリをRails7にして、hotwireとimportmapを有効にする | srockstyle

「大規模なRailsアプリでimportmapを使っているところはまだ少なそう」「Webpackerはやめたけどwebpackは残しているところも多いんじゃないかな」「webpackを剥がすのは大変だと思います」

Rails 7: importmap-rails gem README（翻訳）

🔗 その他Rails

もうすぐリリースされる Ubuntu 22.04 には OpenSSL 3.0 しか存在しないので公式パッケージのみだと Ruby 3.1 以降しかビルドできません。 https://t.co/uz1toC051C

— Hiroshi SHIBATA (@hsbt) April 13, 2022

つっつきボイス:「古いRubyを使わないといけないときとかでつらいヤツだ」「compat_openssl的なものは出ないんだろうか」「そういうのがないとRuby以外の言語でも困りそうですし、公式でなくても誰か作ると思いたい」「自分たちがUbuntu 22.04にアップデートするのはもう少し先になると思いますが、あって欲しい」

参考: Ubuntu 22.04 その3 - OpenSSL 3.0への移行計画 - kledgeb

「Dockerを使うときにUbuntuのバージョン指定をlatestにしている人は要注意ですね」「う、latest普通に使っちゃってます😅」「latestにするとアップデートで死ぬのでバッドプラクティスです、マジで」「そうでした、ちゃんとバージョン指定しなきゃ...」「この分だとしばらくの間あちこちで悲鳴が上がるかも」

参考: Ubuntu - Official Image | Docker Hub -- latestは既に22.04になっています

---

前編は以上です。

バックナンバー（2022年度第2四半期）

週刊Railsウォッチ: RubyのGCコンパクション改修、jemalloc、ReDoSの自動検出修正ほか（20220419後編）

• 20220418前編 RailsConf 2022が5月17〜19日開催、認可機能解説記事ほか
• 20220412後編 HashieでRubyのハッシュを強化、最近のRubyコア解説記事ほ
• 20220411前編 Turbo Railsチュートリアル、Active Recordの「Leaky Abstraction」を削減ほか
• 20220406後編 RBS関連記事、Ruby formatterプロジェクト、Google Cloud Runほか
• 20220404前編 Ruby 3.2.0 Preview 1リリース、Rails向けDocker環境ジェネレータ、scientist gemほか

今週の主なニュースソース

ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSやruby-jp SlackやRedditなど）です。

Rails公式ニュース

Ruby Weekly

Hacklines