週刊Railsウォッチ: Railsコンソールの便利技、ruby-refrigerator gemほか（20250130）

こんにちは、hachi8833です。RubyKaigi 2025のSuper Early Birdチケットが早くも完売です。

Register now for RubyKaigi 2025 https://t.co/ykaJmjMkbe #rubykaigi

— RubyKaigi (@rubykaigi) January 28, 2025

早すぎん？？？ #rubykaigi pic.twitter.com/eNOLBKmbAF

— 🌾yamamoto🌾 (@yamako_inaka) January 29, 2025

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

• 公式更新情報: Ruby on Rails — Sorted Columns in Schema Dumper, Deprecations, and lots of fixes!

🔗 render locals:キーで渡した値をレイアウトファイルでレンダリングできない問題を修正

• PR: Action View: fix local variable access in layouts by flavorjones · Pull Request #54020 · rails/rails

renderに渡されたlocalsにレイアウトファイルからアクセスできるよう修正。

これによって、#31680（Rails 5.1のバグの再発）が修正される。

Mike Dalessio
同Changelogより

動機/背景

Rails 5.1頃から、レイアウトでlocalsにアクセスできなくなっていた。修正後はアクセス可能になる。

修正: #31680

詳細

これは元々、Rails 5.1のd6bac04で壊れていたことが報告されていた。このとき、テンプレートリゾルバキャッシュを最適化するために、レイアウト検索メソッドの一部からlocalsキーが削除されていた。

一方、テンプレートリゾルバキャッシュは Rails 7.0の4db7ae5で廃止され、検索キーでlocalsを使わないFileSystemResolverキャッシュに置き換えられた（ここにはバインドされていないテンプレートが保存されるため）。

したがって、この修正は基本的に、レイアウトリゾルバやレンダラスタックの多くのレイヤにキーを渡し、バインドされていないテンプレートが見つかって、そのテンプレートで#bind_localsが呼び出されたときに、適切なlocals名のセットでバインドされるようにする。

追加情報

これは、自分がAction Viewのレンダリングに関して最初に投げたプルリクである。これがベストな修正かどうかわからないので、フィードバックをもらえると助かる。他によい方法があれば喜んで試すつもりである。
同PRより

---

つっつきボイス:「ちょっとわかりにくかったけど、#31680にあるように、コントローラからrender locals:でlocals値をビューに渡したとき、レイアウトファイル側でlocalsの設定値が参照できなくなっていたということか↓」「アクションに対応するビューファイルでは参照できるけど、レイアウトファイルだけ参照できなかったんですね」

「ところで原文ではlocal variablesと書いているけど、localsに渡すキーバリューのことを言いたいと思うので、localsと表記する方が適切でしょうね」「たしかに」

# controllers/users_controller.rb
class UsersController < ApplicationController
  layout 'application'

  def index
    render locals: { user_name: 'John' }
  end
end

<!-- views/layouts/application.html.erb: エラーになる -->
<%= user_name %>

<!-- views/users/index.html.erb: エラーにならない -->
<%= user_name %>

「レイアウトファイルにlocalsで何かを渡すというのは普通あまりしないと思うけど、渡したい人もいると思うので修正しておくべき👍」

参考: § 5 パーシャルにlocalsオプションでデータを渡す -- Action View の概要 - Railsガイド

---

つっつきの後、Rails 8.0.0でこの問題を再現できました。たしかにレイアウトファイルでのみエラーが起き、index.erbでは起きませんでした。また、mainブランチでは修正されたことも確認できました。

🔗 schema.rbのテーブルカラムをアルファベット順にソートしてマージの競合を削減

• PR: Sort table columns by name when dumping schema by jduff · Pull Request #53281 · rails/rails

schema.rb内のテーブルカラムがアルファベット順でソートされるようになった。

従来は作成順にソートされていたため、2つのブランチが同じテーブルを同時に変更するとマージの競合が発生する可能性があった。

John Duff
同Changelogより

動機/背景

プロジェクトで複数の開発者がマイグレーションを作成していると、マイグレーションの実行順序が必ずしも整然とならないことがよくあり、そうなるとカラムが開発者のマシンごとに異なる順序で追加される。マイグレーションを実行するたびに、スキーマはローカルのデータベースに基づいてダンプされるため、スキーマ出力のカラム順序はマシンごとに異なり、ノイズの多い差分が発生し、全体的に違いがなくてもスキーマファイルで競合が発生する可能性がある。
例:

     t.string "county"
-    t.string "country_code"
     t.datetime "created_at", null: false
     t.datetime "updated_at", null: false
+    t.string "country_code"
     t.string "urn"

詳細

このプルリクは、テーブルダンプに出力する前にカラムをソートするオプションを追加する。MySQLに対してのみこれを実行する過去のプルリクを見つけたが、チームによってはこのオプションを実行したくないケースもあるかもしれないため (たとえばMySQLは既存のカラムを基準にしてカラムを追加できる)、オプションではベースとなるスキーマダンパーレベルでこれを行うことにした。

追加情報

このアプローチを受け入れてもらえるのであれば、これを設定するオプションを作成するのは良いアイデアだと思う。また、使っているデータベースによってはこれをデフォルトで有効にすると便利かもしれない（例: PostgreSQLとSQLite3ではデフォルトで有効にし、MySQLではデフォルトで有効にしない）。
同PRより

---

つっつきボイス:「先週もstructure.sqlの方のスキーマファイルでマージの競合を削減するプルリクがありました（ウォッチ20250123）けど、こちらはschema.rbの方でマージの競合を削減するんですね」「schema.rbの更新をマージしようとしてコンフリクトするのは、業務でRailsをやっていれば誰しも一度は経験するでしょうね: なおプルリクにも書かれているように、schema.rbはマイグレーションを実行するたびに作り直されます」「そうでしたね」

# activerecord/lib/active_record/schema_dumper.rb#L194
          # then dump all non-primary key columns
-         columns.each do |column|
+         columns.sort_by(&:name).each do |column|
            raise StandardError, "Unknown type '#{column.sql_type}' for column '#{column.name}'" unless @connection.valid_type?(column.type)
            next if column.name == pk

「しかしこの修正ではschema.rbでカラムの順序を作成順からアルファベット順にソートするように変えたということは、つまりschema.rb側のカラム順序はあくまで論理的な定義ファイルと割り切って、DB側の実際のカラム順序と違ってくるのもありということにしたのかな？う〜む🤔」「そういえば、MySQLやMariaDBだとDB側でカラム追加時の追加位置を指定できるけどPostgreSQLだと指定できないという話を思い出しました↓」

Rails: マイグレーションファイルでカラム位置を指定してみよう

「schema.rbのテーブルカラム名のアルファベット順ソートは、自分としてはできればして欲しくない」「プルリクでもこの変更はオプショナルにしてもいいかもと書いていますね」「schema.rbのカラムの並びと、DB側でDESCRIBE TABLEしたときのカラムの並びが違ってくるのは、それだけで違和感がある」

「エンタープライズ系のアプリだとDBのテーブルでカラムが100個ぐらいになることもざらにあるんですけど、スキーマのカラム順と、DBや仕様書に書かれているカラム順の対応付けがバラバラになると追いかけるのがつらくなるし、他にも困ったことが頻発しそうなので、アルファベット順ソートへの一律変更はして欲しくない気持ちがある」

「このプルリクにはコンフィグは含まれていないんですね」「競合を減らすためにアルファベット順ソートを使いたい人がいるのはわかるので、せめてデフォルトではアルファベット順ソートをオフにしたうえで、そのままDBのソート順を維持するかアルファベット順ソートにするかをコンフィグで選べるようににして欲しいですね」「話を聞いた感じではコンフィグ可能の方がよさそうですね」「この改修内容に変更されたら、特にエンタープライズ方面で困る人が出てきそうなので、少なくともRailsをアップグレードするときの注意事項に含めておく必要はあるでしょうし、流れによっては今後取り消されるかもしれませんね🤔」

🔗 NotificationAssertionsでペイロード全体ではなくサブセットだけのマッチも可能になった

• PR: Update NotificationAssertions's assert_notifcation to match against payload subsets and return matched notification by larouxn · Pull Request #54126 · rails/rails

動機/背景

このプルリクエストは、次の理由で作成された。

1. 現在、NotificationAssertionsのassert_notificationを使うには、通知ペイロード全体（すべてのキーバリュー）を網羅的に指定しなければならないが、これは必ずしも現実的ではなく、むしろ不可能。そのため、デフォルトでサブセットと照合している。網羅的な照合が必要な場合は、次の方法（ポイント 2）か手動通知キャプチャで手動で行うことは可能。
2. 現在、一致した通知に対してさらにカスタムアサーションを行いたい場合、assert_notificationで必要なアサーションのほとんどをカバーできる場合でも、より低いレベルに移動してcapture_notificationsを実行しなければならない。こうすることで一致した通知を返す。これは、Minitestのassert_raisesの方法に似ている。

ポイント1に関する1つの例として、ジョブの通知のペイロードにさまざまなキーバリューが含まれているため、以下のテストでは現在assert_notificationを利用できず、1つに対してのみアサートする必要がある。

# https://github.com/rails/rails/blob/1b327ad4ed0fe5e8c2f1f795e2cf63f90a9833b5/activerecord/test/activejob/job_runtime_test.rb#L15-L21
 test "job notification payload includes db_runtime" do 
   ActiveRecord::RuntimeRegistry.sql_runtime = 0.0 

   event = capture_notifications("perform.active_job") { TestJob.perform_now }.first 

   assert_equal 42, event.payload[:db_runtime] 
 end 

ここで、上記のアサーションが失敗し、ペイロードのキーバリューのリストが公開されるが、ここで重要なのはそのうちの1つだけである。

vscode ➜ /workspaces/rails/activerecord (main) $ bin/test test/activejob/job_runtime_test.rb 
Using sqlite3_mem
Run options: --seed 23503

# Running:

.{:job=>#<JobRuntimeTest::TestJob:0x00007f80d3efa000 @arguments=[], @job_id="59c22946-0730-4db4-a63f-b71b72804a51", @queue_name=#<Proc:0x00007f80d40a4978 /workspaces/rails/activejob/lib/active_job/queue_name.rb:55 (lambda)>, @scheduled_at=nil, @priority=nil, @executions=1, @exception_executions={}, @timezone=nil, @_halted_callback_hook_called=nil>, :adapter=>#<ActiveJob::QueueAdapters::TestAdapter:0x00007f80d3e42388>, :db_runtime=>42.0, :aborted=>nil}
.

Finished in 0.002990s, 668.9259 runs/s, 1003.3888 assertions/s.
2 runs, 3 assertions, 0 failures, 0 errors, 0 skips

上記のペイロードのサブセットに対してアサーションできるようになれば、このテストはよりクリーンかつシンプルになるだろう。

以下はフォローアップ:

• #53065
• #53700 （gemのプルリクとしてマージ）
• #54084
• #54113 （具体的にはこのやりとり、心から感謝🙏）

CC: @seanpdoyleと@yishus （このプルリクを見たいかもしれないので）

詳細

このプルリクは、NotificationAssertionsのassert_notificationメソッドを、デフォルトでペイロードサブセットと照合し、一致した通知を自動的に返すように変更する。これにより、開発者は必要に応じて、それに対してさらにアサーションを実行可能になる。

さらに、メインのassert_notificationメソッドがテストのユースケースをサポート可能になったため、手動でcapture_notifcationsベースのテスト+アサーションを実行していた多数のテストがクリーンアップされるようになった。

（なお、#54084で見落としていた、この変更とは無関係の通知テストの更新も更新した。必要ならば別のプルリクにに抽出してもよい。）

追加情報

自分はしばらくの間、assert_notificationでペイロードサブセットの照合をサポートする方法について考えていた。これは、元のNotificationAssertionsのプルリクの範囲内でサポートしたい機能だったが、今までは思ったように動かなかった。今回の刷新にこのやりとりで多大なインスピレーションを与えてくれた@byrootに大いに感謝したい。
同PRより

---

つっつきボイス:「これはInstrumentationのアサーションを改良したんですね」「プルリクに書かれているように、通知ペイロードの中にオブジェクトハッシュのようなものが入ってくる可能性もあって、通知ペイロード全体でのアサーションがやりにくいので、特定のサブセットだけに対してアサーションできるようにしたということのようですね」

「ペイロードの中にどんなオブジェクトが入ってくるかを事前に網羅するのは難しいということですか？」「そうそう、たとえば通知ペイロードにスレッドIDが入ってくる場合だと、そのスレッドIDはテストのアサーションで書きようがないんですよ」「なるほど、そういうシチュエーションに対応するためなんですね」「ActiveSupport::Notificationsを使いまくっているアプリだと、テストで決められない値を無理矢理モックやスタブするようなハックで切り抜けることが多かったと思うので、この改修はありがたいでしょうね👍」

参考: Active Support Instrumentation で計測 - Railsガイド

参考: Rails edge API assert_notification -- ActiveSupport::Testing::NotificationAssertions - Ruby on Rails API
参考: Rails edge API capture_notifications -- ActiveSupport::Testing::NotificationAssertions - Ruby on Rails API

🔗 アプリ起動時にActive Storageのプラグインを読み込むよう修正

• PR: Load configured Active Storage plugins during boot by skipkayhil · Pull Request #45100 · rails/rails

概要

従来のActive Storageでruby-vipsやmini_magickやimage_processingを利用する部分では、これらのgemを使う場合にのみgemを読み込もうとしていた。この戦略は、これらの機能を必要としないアプリでは気軽に無視できるので、不要なgemに依存する必要がなくなり、問題なく機能する。

ただしこの戦略は、リクエスト中にコードを読み込む必要があることと、潜在的なエラーメッセージがリクエストログに出力されるため起動時にすぐに表示されないことが欠点である。

このコミットは、VipsとImage Magickトランスフォーマー/アナライザの設定を再構成して、必要な依存関係とともに起動時に読み込まれるようにする（設定されている場合）。

現時点では、Active Storageの:variant_processorとして:vipsや:mini_magickが指定され、しかも必要なgemがGemfileにない場合は、エラーではなく非推奨警告が出力される（多くのアプリが現在このように構成されている可能性が高い）。

その他の情報

このアプローチに関する意見を求む。テスト/ドキュメント/変更ログなどについては後ほど追加する。

クローズ: #44991

cc: @byroot（他の問題での議論に関連するため）
同PRより

---

つっつきボイス:「Active Storageのプラグインを実際に使うときになってから初めて読み込むとアプリが遅くなりがちなので、Active Storageでプラグインを使うならアプリの起動時に読み込んでおくように変えたということですね: こういう改修は高速化に有効👍」「なるほど」「使う可能性のあるものはワーカーがforkする前に全部読み込みを完了しておく方が、後から別のメモリ空間にプラグインを読み込まなくて済むし、コピーオンライトも効いてメモリ効率もよくなる: production環境を想像してみればそうしたくなるのはわかりやすいと思います」「なるほど」

参考: コピーオンライト - Wikipedia

🔗 最近のRailsはメモリを食わなくなってきている

「そういえば昔のRails 3.xとか4.xの頃は遅かったしメモリも結構食っていましたけど、最近のRailsになるほど、軽いアプリならメモリを食わなくなってきていますね（もちろん重量級のアプリはそれなりに重くなりますが）」「お〜、そうなんですね」「細かくは覚えてないけど、たとえばAWS Fargateでメモリ256MBみたいな環境は昔のRailsならまず起動できなくて、起動するなら512MB以上は必要だったのが、今のRailsなら256MBでも一応起動するようになっていますね」「Railsがそんなにスリムになっていたとは知りませんでした」

参考: AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS

🔗 collection_checkboxesで非表示のinput要素にhtml_options[:form]が反映されなかったのを修正

• PR: Use the given form in html_options for the hidden field in collection_check_boxes by 3v0k4 · Pull Request #51746 · rails/rails
  • issue: collection_check_boxes hidden field ignores :form option · Issue #51606 · rails/rails

collection_checkboxesがtype="hidden"の<input>を生成する場合にhtml_options[:form]を尊重するよう修正。

Riccardo Odone
同Changelogより

---

つっつきボイス:「シンプルなバグ修正ですが、プルリクメッセージがあっさりしているので、issue #51606に書かれている問題のdiffを以下に貼っておきました↓」

# https://github.com/rails/rails/issues/51606より
 <form id="myform" action="http://localhost:3000/parents" accept-charset="UTF-8" method="get">
   <input type="search" name="search[name]" id="search_name">
   <input type="submit" name="commit" value="Save Search" data-disable-with="Save Search">
 </form>

-<input form="myform" type="hidden" name="search[parent_ids][]" value="" autocomplete="off">
+<input type="hidden" name="search[parent_ids][]" value="" autocomplete="off">  <!-- form="myform"がない -->
 <input form="myform" type="checkbox" value="1" name="search[parent_ids][]" id="search_parent_ids_1">
<label for="search_parent_ids_1">Parent_1</label>

「今まではhtml_optionsにformというオプションを渡してもform="myform"が生成されなかったということのようですね」

# actionview/lib/action_view/helpers/tags/collection_helpers.rb#L107
          def hidden_field
            hidden_name = @html_options[:name] || hidden_field_name
-           @template_object.hidden_field_tag(hidden_name, "", id: nil)
+           options = { id: nil, form: @html_options[:form] }
+           @template_object.hidden_field_tag(hidden_name, "", options)
          end

参考: Rails edge API collection_checkboxes -- ActionView::Helpers::FormOptionsHelper - Ruby on Rails API

「ちなみにこれは<form>タグではなくてformという名前の属性ですね: HTML5では任意の属性名を使えるとはいえ、何だかどこかでぶつかりそうであんまり使いたくないかも」「普通に紛らわしいですよね」

参考: HTML5 - Wikipedia

🔗 ビューテンプレートのstrict localsのエラーでArgumentErrorではなくActionView::StrictLocalsErrorをraiseするようになった

• PR: fix: ArgumentErrors raised during template rendering by flavorjones · Pull Request #54133 · rails/rails

テンプレート内の引数エラーのうち、strict（厳密な）localsに関連するものはActionView::StrictLocalsErrorをraiseし、その他の引数エラーはそのまま再度raiseされるようになった。

従来は、テンプレートのレンダリング中にraiseしたArgumentErrorはstrict localsエラーの処理中に飲み込まれてしまっていたため、strict localsに関連しないArgumentError（誤った引数で呼び出されたヘルパーメソッドなど）が無関係なバックトレースを持つ同様のArgumentErrorに置き換えられてしまい、テンプレートのデバッグが困難になっていた。

修正後は、strict localsに関連しないArgumentErrorが再度raiseされるようになり、開発者向けに元のバックトレースが保持されるようになった。

また、ActionView::StrictLocalsErrorはArgumentErrorのサブクラスであるため、ArgumentErrorをrescueする既存のコードは引き続き機能する。

修正: #52227

Mike Dalessio
同Changelogより

---

つっつきボイス:「これは何の話かなと思ったらstrict localsのエラー処理の修正か」「strict localsは、以下のようにパーシャルの<%# locals: -%>というマジックコメントで、そのパーシャルに渡していいものを指定する機能でしたね↓」「必須の引数を定義するアノテーション機能ですね」

<!-- strict localsの例 -->
<%# locals: (article:, theme: "light") -%>

参考: §5.8 厳密なlocals -- Action View の概要 - Railsガイド

「修正前はstrict localsのエラーと単なるヘルパーエラーが区別できなくなっていたのを、StrictLocalsErrorを追加してstrict localsのエラーを処理できるようにしたんですね」「なるほど」

「どちらもArgumentErrorになってしまうと区別しにくくなってデバッグがやりづらくなるけど、Railsはそのためのエラークラスとエラー処理をこうやって丁寧に増やし続けているところはやっぱり凄いと思いますね👍」

参考: Rails アプリケーションのエラー通知 - Railsガイド

「ところで、このstrict localsはRailsガイドではひとまず"厳密なlocals"↓と訳しているんですが、エンジニア的にはどうでしょうか？」「localsの部分は訳してはいけないけど、この場合のstrictは一般的な語なので訳してもよさそう」「なるほど、ちなみにRailsガイドでは初出の用語を基本的に"厳密なlocals（strict locals）"のようにかっこ書きで両方書くようにすることで、どちらでも検索できるようにしています」「両方で検索できるのは助かる👍」

参考: § 5.8 厳密なlocals -- Action View の概要 - Railsガイド

🔗 Active Storageが不要なコマンドでActiveStorage::Blobを読み込まないよう修正

• PR: Don't load ActiveStorage::Blob when validating the service by rafaelfranca · Pull Request #54142 · rails/rails

Active Storageを必要としないassets:precompileなどのタスクを実行したときに、Active Storageが誤ってそのタスクで構成されてしまうことがある。サービス構成を検証するためだけにActive Storageの振る舞い全体を読み込むべきではない。

修正: #54139
同PRより

---

つっつきボイス:「bin/rails assets:precompileみたいなタスクを実行するときにActive Storage関連の機能は不要なので、そういうときは読み込まないようにする: これはわかりやすい修正」「assets:precompileはどんなときに使う機能でしたっけ？」「JavaScriptやCSSのアセットをビルドするRailsコマンドですね↓」

参考: §3.3.2 アセットのプリコンパイル -- アセットパイプライン - Railsガイド

🔗 String#mb_charsとActiveSupport::Multibyte::Charsが非推奨化

• PR: Deprecate String#mb_chars and AS::Multibyte::Chars. by byroot · Pull Request #54081 · rails/rails

これは、RubyのStringがエンコードを認識していなかったRuby 1.9以前の時代の名残りにすぎない。2025年にこのAPIを利用するのは大いに疑問。
同PRより

---

つっつきボイス:「String#mb_charsとかActiveSupport::Multibyte::Charsが非推奨ということですが、使ったことないな〜: Ruby 1.9でエンコーディングの扱いが変わる前の仕様に依存した機能は、さすがに今は使わない方がいいでしょうね」「使っている人っているんでしょうか？」「古いRailsプロジェクトで使われていることならあるかもしれませんが、この機能が今後どうしても必要なプロジェクトなら、きっと自分でモンキーパッチ当てるでしょうね」

参考: Rails API mb_chars -- String
参考: Rails API ActiveSupport::Multibyte::Chars

Rubyの内部文字コードはUTF-8ではない...だと...？！

🔗Rails

🔗 Railsコンソールの便利技（Ruby Weeklyより）

• 元記事: Useful things you can do with Rails console

---

つっつきボイス:「Railsコンソールでこんなこともできるというtips記事です」

「ログを有効にしておいてtouchするとSQLクエリをさっと確認できる↓」

# 以下同記事より
User.find_each(&:touch)
# User Load (0.6ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT 1000
# TRANSACTION (0.2ms)  BEGIN
# User Update (1.7ms)  UPDATE "users" SET …

「_で直前の結果を参照するのは定番の技↓」「これは有名ですね」

3.3.6 :001 > 4 + 4
=> 8
3.3.6 :002 > _
=> 8

「そうそう、cdでコンテキストに移動できるのは割と最近の機能だったかな↓」「シェルっぽい命名が面白いですよね」

cd user.address.location
latitude # => some value

「lsもあるんですね↓」「こちらはinspect機能にlsと命名したんですね、cdと同じタイミングで実装したのかな」「inspectより短いのがいいですね」

user = User.last
ls user                     
# User#methods: name
# instance variables: @association_cache @attributes @destroyed
# @destroyed_by_association

「yコマンドでyamlを出力できるのは知らなかった↓」

users_data = [ { first_name: 'John', last_name: 'Doe' }, { first_name: 'Tim', last_name: 'Doe' }]
y users_data
---
- :first_name: John
  :last_name: Doe
- :first_name: Tim
  :last_name: Doe

「これは？」「なるほど、Userクラスのメソッドを上書きするのではなくて、インスタンスのuserオブジェクトにdef user.some_callbackで特異メソッドを定義している↓: これはRuby自体の機能ですね」

user = User.last

def user.some_callback
  puts "modified callback"
end

user.perform_action
# => "modified callback"

another_user = User.first
another_user.perform_action
# => "original callback"

「さらに以下のようにすればprivateメソッドにもできる↓」

def user.some_callback
  "modified callback"
end

user.singleton_class.class_eval { private :some_callback }

「お、こういうふうにコンフィグで書いておくと、Railsコンソールだけで使いたい機能を設定できるんですね↓」

Rails.application.console do
  puts "Loading custom initializer #{__FILE__}"

  def main_user
    User.find(10)
  end
end

「そうそう、Railsコンソールではデフォルトでhelperからヘルパーメソッドにアクセスできる↓」「これたまに欲しくなるんですが忘れがちでした😅」

helper.full_name("John", "Doe") # => "John Doe"

「コード変更をreload!で読み込むのも定番↓」

helper.some_method
# => undefined method
reload!
# => Reloading ...
# => nil
helper.some_method
# => true

「source_locationでソースコードの場所を探したり.source.displayでソースコードを表示するのは使ったことがあるけど、$コマンドを使うとこんなふうにソースコードを表示できるんですね↓」

$ User.new.full_name

# From: /app/models/user.rb:27:
#
# def full_name
#   "#{@first_name} #{@last_name}"
# end

「connection.tablesで全テーブルを表示する機能があるんですね↓: 自分はActiveRecord::Base.connection.execute('SHOW TABLES')などでやってますが」

ActiveRecord::Base.connection.tables

「一度読んでおくとよさそう👍: ちなみにここには書かれていなかったけど--sandboxでサンドボックスモードにできる機能もいいですよ↓」「そうそう」

参考: §2.3 bin/rails console -- コマンドラインツール - Railsガイド

🔗 shoryuken gemがメンテナンスモードに

---

つっつきボイス:「この間の東京RubyKaigiのスポンサートークでshoryukenを取り上げていて↓、そのときにshoryukenのリポジトリがアーカイブされてしまって悲しいというお話をされていたんですが、その後リポジトリが復活した代わりにメンテナンスモードに変わっていた、という流れです」

昇竜拳ってこちらか！#tokyorubykaigi

minneのShoryuken活用　Kaigi on Rails 2024 スポンサーLT https://t.co/9CCrnNch56

— nikkie(にっきー) / にっP (@ftnext) January 18, 2025

shoryuken gem のアーカイブ化が解除されているみたい? 一方で、末尾に不穏な一文増えてない? / ruby-shoryuken/shoryuken: A super efficient Amazon SQS thread based message processor for Ruby. This project is in MAINTENANCE MODE. https://t.co/Gb6TmovJFh

— tk0miya (@tk0miya) January 20, 2025

A super efficient Amazon SQS thread based message processor for Ruby. This project is in MAINTENANCE MODE.
Update README.md · ruby-shoryuken/shoryuken@5442f47より

「shoryukenは相当昔からあるgemですね: 自分で使った覚えはないけど、これを知ってるRailsエンジニアは相当古株だと思うし、これだけ古いとメンテナンスも滞りそう」「リリースタグは昨年のものもいくつかあるので、そこそこメンテはされているみたいですね」「でもmainブランチのCIは落ちてる（その後CIエラーは解消していました）」

「ところでshoryukenはAWS SQSを使えるそうですが、SQSってRedis的なサービスでしたっけ？」「RedisよりはRabbitMQあたりの方がSQSに近いと思いますが、汎用的なメッセージキューのエンジンですね」「なるほど」

参考: Amazon SQS（サーバーレスアプリのためのメッセージキューサービス）| AWS
参考: RabbitMQ: One broker to queue them all | RabbitMQ

🔗 rubocop-railsにRails/StrongParametersExpectが追加

RuboCop API: Rails/StrongParametersExpect -- Rails :: RuboCop Docs

---

つっつきボイス:「以下のissueをたまたま見かけて、Rails/StrongParametersExpectというcopがrubocop-railsに入っていることを知りました」

参考: Rails/StrongParametersExpect can break working code - this should be documented · Issue #1418 · rubocop/rubocop-rails

Rails 8: strong parametersにexpectと二重配列構文が追加された

🔗Ruby

🔗 ruby-refrigerator: Rubyのコアライブラリを丸ごとfreezeする（Ruby Weeklyより）

---

つっつきボイス:「Jeremy Evansさんが作ったgemだそうです」「Rubyのコアライブラリを変更不可にする、つまりコアにモンキーパッチを当てられないようにするということかな」

# 同リポジトリより
require 'refrigerator'
Refrigerator.freeze_core

「これはproductionで使うというよりは、Railsアプリのconfig.ruとかに書いて、自分が把握していないモンキーパッチがこっそりRubyコアに当たっていないかどうかをあぶりだすのに使える感じですね👍」「なるほど、そういうときに便利そう」

🔗 その他Ruby

#tokyowomenrb #1 のイベントページを公開しました！ そして本イベントではなんと！基調講演を鳥井雪さん@yotii23に、招待講演をしおいさん@coe401_に、それぞれお話しいただきます。お二人のプロフィールはイベントページをご覧ください。 どなたもご参加をお待ちしています！https://t.co/fXcw9ZwEdh

— TokyoWomen.rb (@tokyowomenrb) January 23, 2025

---

つっつきボイス:「3月に開催されるTokyoWomen.rb第1回のお知らせです🎉」「登壇者は女性のみだけど参加は性別不問枠もあって費用も同じなんですね」

---

今回は以上です。

バックナンバー（2025年度第1四半期）

週刊Railsウォッチ: RailsガイドがRails 8.0.1に対応ほか（20250123）

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

Rails公式ニュース

Ruby Weekly