Kaigi on Rails 2024 参加してきました！
Qiita からは自分を含め3人が現地参加してきました。
聞いたセッション (の一部) の紹介
めちゃくちゃ面白いものが多かったので、全部は書ききれないですが、たくさん書いてます。
2日目ガス欠気味だったので、1日目が多めです。
基調講演: Rails Way, or the highway
Rails は 「Rails scales from HELLO WORLD to IPO」と呼ばれるが、その長い期間 (特に、動くアプリケーションから IPO に至るまで) でアプリケーションをどう育ててくれるか、Rails の隙間をどう埋めるかという事に対して、ヒントを与えてくれる発表でした。
Rails の隙間を埋めるための原則として、Rails の設計パターン、規約、構成要素を学びながらそれらに似た抽象化を行う、抽象化レイヤーの間に明確な境界を引く、介入より抽出、関心事と複雑さの分離、がサンプル実装を交えながら紹介されていました。
Qiita も10年以上 Rails アプリケーションとして開発されていて、 Rails の隙間を埋めることに苦心しているのですが、今後もやっていくための助けとなるような発表でした。
↓ の本としても書かれているようなので、今度読んでみようと思います 
また、この発表の内容が他のセッションでとても良く触れられていて、今年の Kaigi on Rails のテーマを位置づけるような発表でした。
RailsのPull requestsのレビューの時に私が考えていること
Rails の Contribution Guide のエッセンスやコミッター側の考え方について、実例を交えながら解説してくれました。
聞いていて、「レビュアーに伝えるのに必要十分な情報になっているか」「(変更を行うときには) それに Real world use case があるのか」が徹底されていると感じたのと、「そのユースケースは Rails で解決するべきものか」という問い掛けについては、なるほど確かにと感じました。エンジニア間でスムーズに仕事を進めていくためのサンプルとしても使えるかも？ということを思いました。
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
ViewComponent の解説と、ViewComponent にいかに移行するかについてです。個人的にも ViewComponent はよくできたライブラリだと感じるのですが、 ViewComponent へコード変換を行って移行する過程が非常に楽しく聞けましたｗ (Rubyist みんなコード作るの大好き説)
コード変換で一気に置き換えるの、中途半端な手動移行で一貫性がない状態になることへの対案として良さそうだなと思って、今後似たような機会があれば参考にしたいです。
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜
スピーカーのトークの上手さと、緻密なデバッグ能力に舌を巻きっぱなしでした。アーカイブ公開されたらもう一回見たい 
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
Real World プロトコル…って言う感じで楽しくニコニコ聞いていたのですが、微妙に仕様からズレてるとことかはみ出してるとことかを上手く吸収していくのは、仕組みとかシステムの設計として確かに力量が求められそうですね。非常に面白そう(同時に多分つらそう)。
Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？
ブラウザテストは、欲しいんだけど維持が面倒なものの代表格みたいなやつなので、なんとかなると嬉しいな〜〜〜っていう気持ちで聞いていました。あくまで実験的な試みではあるそうですが、これをベースになんか試してみたくなる感じで、非常に興味深かったです。
作って理解する RDBMSのしくみ
RDBMS にクエリを投げて、実行計画立てて、インデックス使いながらデータ取ってくる…あたりまで解説されています。このへん、インデックス設計するときとかによく考える箇所なのですが、聞いてて、ふんわり理解しているところの隙間が埋まっていく感じで面白かったです。
この発表段階ではまだ途中だそうですが、実際に作ってみるの面白そうですね。SQL パーサー書くは面倒そうなのでなんか上手く既存のやつ使って、データ取ってくる周りに集中したいとは思うのですが…。
Sidekiq vs Solid Queue
Solid Queue は、Redis 要らないので新規に使う分には良さそうだが、今動いている Rails アプリケーションではどうなんだ？？？ってかなり疑問に思っていたので、数字などを出しつつそのへんに回答が出されていて非常にありがたかったです。
あと、ジョブワーカーのバックエンドで DB が避けられてた背景とか、ジョブワーカーのライブラリの変遷など、知らないことが多く、学びになりました。
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
実は Qiita でも packwerk (+ packs-rails) を使い始めている (そろそろ知見が溜まってきているのでどこかで話したい) のですが、 packwerk の良い点 (既存のコードに影響を極力与えずリファクタリング出来る) は非常に頷きながら聞いていました。これらのライブラリは、静的解析と zeitwerk を上手く活用していてアプローチとして面白いと感じます。
各社 packwerk でどう切り出しを行っているかとかも結構興味があります…！
スポンサーセッション
様々なスポンサー企業の方が、バリエーション豊かなトークをしてくださったのですが、一番印象に残ったのは
終わりに
今回、Kaigi on Rails には、「各社が複雑化した Rails アプリケーションに対し、どう立ち向かうか」を知れれば or 意見交換できればと思って参加してました。
これらに関して、大きく得られるものもあったのですが、それ以上に Rails Way に立ち返って深堀りしていく話が多く、もっと深く考えていくヒントになりそうで非常に参考になりました。
スピーカーの皆さん、運営の皆さんありがとうございました！
余談 (ネットプリントでアイコン刷ってくると便利)
オフラインイベントだと「インターネットとリアルアバターが一致しない現象」があるのですが、これ対策として、アイコンをコンビニのネットプリントで印刷して持ってきました。
…が、Lサイズの写真プリントだと、かなりどでかいサイズになってしまいました…。
一応名札とかには入るサイズではあるのですが、相当ギリギリなので、証明写真プリントの方のほうが良いかもしれないです。(これもコンビニで出来るのでその場で印刷できて便利)