Kaigi on Rails 2024 に参加した

2024.10.25 (Fri.) - 26 (Sat.) の2日間、有明セントラルタワーホール & カンファレンスで開催された Kaigi on Rails 2024 に参加してきました。

kaigionrails.org

Kaigi on Rails は初参加だったし、コロナ禍&家庭都合で大規模カンファレンス自体が数年ぶりのオフライン参加だったのだけど、プロポーザルが採択されて登壇することもできたし素晴らしいセッションばかりでとても貴重な経験をすることができたので熱が冷めないうちに参加レポート(主に拝聴したセッションの感想たち)を書き残します。振り返り&登壇後記は別記事に書く。 → 書きました Kaigi on Rails 2024 登壇ふりかえり - kozy4324の日記

スライドリンクは ruby-jp の Cosense にまとめられているので気になる方はそちらから辿ってもらうと良さそう。

Kaigi on Rails 2024 - ruby-jp

Day 1

Rails Way, or the highway

Palkan さんの基調講演。Rails way とは何か?から始まり、Rails アプリケーションをシンプルに保つための考え方や指針を示してくれたような内容だった。Rails フレームワークはアプリケーションを構成する要素 (building blocks) を提供してくれるけど、それだけでは現実のアプリケーションにおいては埋めるべき隙間ができてしまう。隙間を埋めることで Rails のフレームを歪めてしまい果ては「怪獣 on Rails」になってしまうという提言は身につまされる思いに至った。「Rails framework gives you structure. Rails way gives you guidance.」は声に出して読みたい英文だし、この guidance に「導きの星」と訳を付けてたのが良かった。「Rails を他のものと混ぜ合わせるのではなく、拡張しよう」というフレーズも最高だった。

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング

igaiga さんのセッション。Rails におけるモデルの設計をどう見つけ育てていくかという話が詰まっていて、そこら辺に常に悩んでいる自分にはめちゃくちゃ刺さる内容だった。「Service層を入れるのはできるだけやめてほしい」という主張は個人的にもめちゃくちゃ支持したい話。「モデルを分割するタイミングの1つはバリデーションを条件分岐したくなったとき」という考え方はとても分かりやすいし、自分が関わるプロジェクトの Rails アプリケーションでも適用してみようと思えた。

そのカラム追加、ちょっと待って!カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?

Asayama Kodai さんのセッション。1カラム追加することで実行時のメモリが何バイト増えるのだろう?という内容を掘り下げていった話。最終的には CRuby のメモリレイアウトまで確認しにいっており、CRuby 処理系の普段自分が意識しない部分の内容まであったので興味深く話を聞かせてもらった。機序を確認するために処理系の内部実装までみていくというスタンスは尊敬しかない。

Sidekiqで実現する長時間非同期処理の中断と再開

hypermkt さんのセッション。非同期処理における SmartHR 社の Real-world example が気になったので参加。長時間非同期処理で中断と再開をどう実現しているのか、またそれをどう実装しテストしているのかという話が具体的に語られていてめちゃくちゃ参考になった。Sidekiq Iteration なる新機能が Sidekiq v7.3.0 で導入されたという紹介が最後にあったけど、ではこれを使うと SmartHR の既存ユースケースが全部置き換えられるのか?っていう話はやってみないと分からんし、これから導入検討する価値があるということだったのでいつかどこかでここら辺の話が聞けるかもというのは楽しみにしたい。

カスタムしながら理解するGraphQL Connection

yana-gi さんのセッション。GraphQL ニワカ勢だったので勉強したいと思って参加。GraphQL とは何かから始まり、具体のプロダクトにおける事例の話があってとても参考になった。オフセットページネーション、カーソルページネーションの話はもっと広く認知されるべき内容だなと思った。

リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果

Naoyuki Kataoka さんのセッション。タイトルの「1800個」という数のインパクトが強くて、自分はこれを「数の暴力事案」と呼んでいるのだけど、興味を引く内容だったので参加。スクリプトを作って機械的に移行する方法を選択したのだけど、erb のパーサー的な何かを作っていたり、丁寧にカナリアリリースをしていたりで practical な話が満載で面白かった。

ActionCableなら簡単? 生成 AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。

kaiba さんのセッション。ActionCable の事案を聞きたくて参加。生成 AI の応答をリアルタイムに返却したいということで ActionCable を採用しているが、その中で遭遇した課題とそれをどう解決していったかという話でめちゃくちゃ勉強になった。あと LLM 周りの周辺開発ツールが整備されてきているんだなーという印象も持った。自分でも何か LLM に関するものを手を動かしてみたくなった。

デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜

izumitomo さんのセッション。他人のやらかしは蜜の味ということで参加。いうほど登壇者がやらかしたわけではなかった(前任者のせいでは?という話)のだけど、自分が踏んだ障害からエラー発生機序を深掘りし、そこから得た学びを組織に還元までしているという話。またそれが「新卒1年目」というラベルでインパクトのある内容になっていた。登壇までしているので組織どころかコミュニティにまで還元していて、ただ単純にスゴい!って圧倒された。疑問に思ったら深掘りして学びにまで繋げるという立ち振る舞いは尊敬できるし参考にもしたい。

Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?

Yusuke Iwaki さんのセッション。Capybara による E2E テスト記述を自然言語で書くという試み。PoC レベルのものはもうできていてデモもされていたが、全然関係ない要素へのアクションした後に正しい要素へのアクションへと試行錯誤していく実行ログが流れているのをみて「こいつ...動くぞ!」というワクワクした感情が湧き出てきたのが印象に残っている。動くものを見せるのは正義ですね。

Day 2

都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」

osyoyu さんのセッション。「推測するな、計測せよ」を体現されていて、仮説を立て計測をして解釈を得ることを繰り返されているなという印象を強く持った。参考にすべき立ち振る舞いでエンジニアこうありたいよなと強く感じさせてくれる内容だったと個人的に考えています。 IO-bound な状況であれば Go と Ruby のランタイムで性能差は大きくないけど、CPU-bound になると Go がやはり優勢になるよなという話からの N+1 をガンガン書いたほうがいいのでは?というフリは最高だった。ISUCON で過去 Ruby で優勝したチームが1つだけあるがそれはそれで気になる。

約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり

hatsu さんのセッション。これも「数の暴力事案」ということで参加。遅く Flaky な テスト/CI をいかに改善していったのかという話だった。実用的で具体的な改善策が詰め込まれていて、それを実際のプロダクトでやりきって成果までもっていくのは素晴らしい話だった。

Hotwire光の道とStimulus

Yasuko Ohba さんのセッション。業務で Hotwire 使っているけどまだ悩むことが多いのと、前回の Hotwire 登壇内容を実際に参考にさせてもらっていたのでその続編と期待して参加。「光の道」と表現している設計・実装指針を抽出して言語化されているのは流石だなぁと感じながら話を聞きました。Hotwire の実装がハマるとめちゃくちゃ快適なのは共感しかない。資料を繰り返し読むのと実装とを行き来して解釈を深めていこうかと思います。

Data Migration on Rails

ohbarye さんのセッション。アンケートなども行い Survey Report 風に data migration の現状をまとめられており、体系的かつ実用的な話が満載な内容になっていたと感じた。私も rails console で migration を実行したことある勢でした。各方法のメリット・デメリットがまとめられており、講演者の選択と実践という内容で Real-world example が書かれていたりもするので、data migration においてチームでどういったことに優先順位をつけてどう意思決定するかという会話を始めるための必要十分な情報になっていると思います。

30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法

Ryosuke Uchida さんのセッション。ActionCable の Real-world example 事案。各技術の選定における意思決定の観点やどういった問題に遭遇し解決していったのかという話が具体的でとても参考になる話でした。話のスタート地点として us-central1 リージョンにしかないサービスがボトルネック、ということで現実世界にはいろんな事例があって複雑なんだよなぁと改めて思った(なので事例の話が個人的に好きということでもある)

Identifying User Identity

moro さんのセッション。ほとんどの Rails アプリケーションで出てくるであろう User モデルの設計について、しっかりと概念レベルから何であるのか、どうあるべきなのかを深く考えて切り込んだ話だと解釈した。「探求」という表現にふさわしい内容だとも思った。理想だけを語るのではなく現実世界の課題もしっかりと解決する例も提示しつつ、個別に発生するであろうアプリケーション要求にも開いているような、まさに「設計」というべき所業を見せつけられたような内容だった。個人的には最後のスライドに書かれている ActiveRecord が提供する 内部DSL を使った表現の美しさに感動を覚えるレベルだった。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

島田さんの基調講演。2日間の最後を締めくくるにふさわしい内容だったと思う。自分の人生の中での最高の基調講演が2つになって、1つ目は2010年 YAPC::Asia の miyagawa さんのクロージングキーノートだったのだけど、今回のお話はそれと同じぐらい Empowerment したという話。「設計とは現実世界の問題を1つずつ解いていくこと」でありその結果現れるのがシステム全体の構造なんだという話がとても印象に残っている。具体と全体を行き来することの重要性なんだよなぁと。変化を内包する (Embrace change) の話も首がもげそうな勢いでうんうんしながら聞いていました。また明日から目の前の課題解決とソフトウェアの実装を1つずつ頑張っていこう、そう強く思える内容だったなとこのブログを書きながら思い出しています。

全体を通して

Kaigi on Rails は初めての参加で、大規模 Ruby カンファレンスになるとそれこそ10年ぶりとかそんなレベルになるのだけど、たくさんの Rubyist たちの熱気と情熱を改めて感じ取ることができる2日間でした。最高の経験と最高のカンファレンスを提供してもらった運営・オーガーナイザー・コミュニティの方々の尽力があっての会だったと強く感じています。感謝の気持ちしかない。今後もコミュニティに参加して、自分からも誰かに何かを贈れるような、そんな Rubyist の1人になれるように頑張ってやっていきたいなとも強く思いました。感謝!ありがとうございました!!