Kaigi on Rails 2025に参加した

tech kaigionrails

今年は記事があります*1。期間中のTwitterまとめ＋αです。

セッション感想

dynamic!、入門 FormObject、今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

これまでの経験が小規模のチームでの開発が大多数であることもあってみんなFormObjectとかServiceクラスとかお行儀いい開発してるなあというのが前からこの手の話について思ってることだが、結局FormObjectもServiceクラスもfat controller/model問題をすべて救ってくれるわけではなく最後は自分で考えて現実と向き合わないといけない。"soft"wareをやってる限りはstaticな構造物であることはできず、ハードウェア組み込みとかの人は違う意見を持つかもしれないが特にWebアプリケーション開発においては理論上は即時デプロイ即時アップデートが可能なハズなので、我々も日々考えてアップデートを続けていかなければいけない。これをコミュニティのシニアな人が言ったことは意義深く、思考を止めたい人はシニアな人から答えが降ってくることを求めその答えにすがりたくなるが、その「希望」を切り捨てたことはとてもよかった。言い訳の余地はなくなった。やっていきましょう。

これが1日目に固まっていたのはオーガナイザーのタイムテーブル構築の妙を感じる流れだった。

ドメイン指定Cookieとサービス間共有Redisで作る認証基盤サービス、rails g authenticationから学ぶRails8.0時代の認証

Kaigi on Rails恒例s01氏失職シリーズ。

ついにrodauthを使っている事例が出てきたことに感動している。「おすすめはしない」というコメントはあったけれど単に茨の道なだけで、rodauthの与えてくれる「最もモダンなパスワードストア」は他には替えられない強みなので、もっと事例が出てきて使い方が洗練されてくることを期待している。

そのうえで rails g authentication ができたからと言ってRailsの認証が解決したかというとそんなことは全くない、という話。Deviseでつらいって言ってる人は今でもいるし、だからといって rails g authentication も救ってくれない、rodauthも茨の道、結局考えなきゃいけないことは多く、意外と4年前のスライドは今でもrelevantなのではという気がしてきた。

speakerdeck.com

ActiveSupport::CurrentAttributes はセッションについてこういう命名を可能にしてくれるのすごい。そういえばこれについて2023で話されてたのを今気づいたのであとで見よう。

Railsアプリから何を切り出す？機能分離の判断基準

認証基盤があると他の機能は認証を任せられるようになるので機能分割がしやすくなるんですよね〜〜〜〜なおその難しさについては上記の黒曜さんのトークで語られており

最近マイクロサービスvsモノリシックvsモジュラーモノリスについて議論することがあったので「必ずしも分離すればいいのではないのだよ」ということについて実例とともに語ってくれて言語化するヒントが得られた。

非同期処理実行基盤、Delayed脱出〜SolidQueue完全移行への旅路。 、非同期jobをtransaction内で呼ぶなよ！絶対に呼ぶなよ！

uvb-76.hatenablog.com

後者をタイムテーブルで見てこれを思い出した。去年のKaigi on Railsで enqueue_after_transaction_commit についてのクイズで当時思うことがあったので id:uvb_76 と廊下で話をしたのだけど当時何考えてたんだっけ…多分当時の業務と関連があってのことだと思うけど去年ブログ記事残してないし…。確か他の言語/フレームワーク*2を長く使っていて、Railsが暗黙にトランザクションと非同期実行の順序関係を並べてくれるガードレールを用意すると他の環境に行ったときにトラップ引きそうだなーと思ったからと思うが…。その点では after_commit_everywhere を使って明示的に書くほうが私はfanだったりする。

Solid Queueが速すぎて障害になることあるんだ…というのが衝撃的だった。

Railsアプリケーション開発者のためのブックガイド

呼びました？

この世のすべてすぎて、ちょっと前に話題になったこのtweetを思い出した（Kaigi on Railsとは直接関係はない）:

5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム

例によって資料が毎回めちゃくちゃ丁寧でわかりやすい。規制産業の情報は当事者からしか聞くことができないのでとても貴重。PCI-DSSが面倒っていうのはセキュリティ屋をやってるとよく聞くのだけど、こういうときにPCI-DSSの規制のかかる部分だけマイクロサービスにして分離してしまい残りはそうでないサービスとしてやるっていうのはマイクロサービスの使いどころとしていい話だと思った。

Building and Deploying Interactive Rails Applications with Falcon

この世のすべて2。ground-upで並行処理の仕組みとWebサーバーを再実装しそれをRailsと組み込めるようにしてShopifyレベルの大規模サービスでも使えるようにするって、この世のすべてですよ…。Claudeに"You're on stage for Kaigi on Rails"っていうプロンプトを渡すのが微笑ましかった。

廊下

これの相談を何名かにすることが今回わざわざ行った目的の一つ。近く明らかになります。

なんか廊下で話してる間に東京に用が2つできたので旅程が1つ生えた。

クイズ屋しぐさをしてるのが晒されてしまった。ボタンの上に指置いて問題聞いてるところがわかりやすいと思います*3。

それ以外

Day1開始前

飛行機をジャーしかけた。

Day2終了後

日暮里でビール飲み放題案件を見かけたのでついていった。帰りに日暮里の改札通ろうとしたらyancyaさんとうなすけ君がPOPしてその後秋葉原でもうちょっと飲んでた。

otoge.rb

RubyConf Taiwanのとき*4に @ioquatix *5 がDDRをやるということでKaigi on Rails後にotoge.rb活動やるか〜〜〜〜というので立てた。が:

RubyKaigi 2026でもやります。Day0の昼頃を予定。ruby-jp Slack の #music_game チャンネルで告知します。よろしくねよろしくね

おわりに

Kaigi on RailsはRubyKaigiと違って実務の話、みたいに言われるけど、多分それよりももっといい言語化がある気がしてきている。然るべきタイミングが来たら書きます。

来年も楽しみなのでちゃんと生存して参加したいですね。

*1:昨年はなかった。sha256を投下した場所とその中身を明らかにした記事

*2:具体的にはElixirのAntikythera（非同期実行機構はそれのAsyncJobという機能）を長いことシバいており、データストアとして自前Firebaseみたいなやつを利用していた

*3:競技仕様のスイッチだと反応点寸前まで押し込むっていうやつをやりますがこのボタンはそれがなかったのでボタンの上で指を構えておきます、こうするとわかったときにボタンの外から指を動かす分の時間だけ早く押せます。このへんは『ナナマルサンバツ』っていう漫画を読むとわかりやすい

*4:そういやまだ記事書いてない！！！

*5:この表記なのは今回来てくれた人のもうひとりが違う苗字のSamuelさんなので