Kaigi on Rails 2024の参加レポート

Posted by Ryo Hayakawa on November 11, 2024 · 4 mins read

NaClの早川です。
2024年10月25日(金)~2024年10月26日(土)に開催されたKaigi on Rails 2024に参加しました。
弊社からは小倉、早川の2名が参加しました。
本記事では参加レポートとして、私の参加したセッションと感想をまとめました。

Kaigi on Rails 2024

Kaigi on Rails 2024は、東京の有明セントラルタワーホール & カンファレンスで開催されました。

01_photo_booth.jpg

スポンサーブースも盛り上がっていました。
02_sponsor.jpg

基調講演 Rails Way, or the highway

Railsへの初コミットからちょうど10年の@palkanさんによる基調講演です。
Rails Wayの重要性、Rails Wayを道しるべとした拡張の方法を実際のコードを通して語られていました。
講演中にあった『RAILS WAY はあなたの導きの星だ』という言葉はとても印象的で、Railsの設計で迷ったときに思い返したいなと思いました。

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

五十嵐邦明さん(@igaiga)による、モデルの設計と育て方、分割のお話。
「ファットコントローラーを避けるためにモデルで書きましょう」はよく聞く話ですが、その結果大きくなったモデルはどうしたら?と思っていた私には分割のタイミングの話が響きました。
モデルを探す方法についてはRailsの練習帳を読んでください、ということでしたが、こちらも大変わかりやすく為になる内容でしたので、改めて読みたいと思います。

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

Asayama Kodaiさん(@asayamakk)さんによる、カラム追加で使用するメモリはどのぐらい増えるかというお話
integerをadd_columnすると224バイトのメモリが必要になるそうで、会場の挙手によるアンケートだと6割くらいの方が「少ない」と感じているようでした。
私も意外と少ないな、と感じたのですが、そこはいわゆる『ちりつも』で増えていくわけなので、メモリに対する意識を改めさせられる発表内容でした。

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

@yana-giさんによるGraphQLとCustom Connectionのお話。
GraphQLとは何か?という基本的な部分から始まり、後半はCustom Connectionの実践的な内容が解説されました。
私はGraphQLを「SQLのフォーカスをより絞って使えるもの?」くらいの知識でしたが、実際の業務でどのように使われているのかを知り、勉強になりました。

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

Naoyuki Kataokaさん(@katty0324)による、大量のERBファイルをViewComponentに自動変換するお話。
パーサーを駆使してERBファイルをViewComponentに置き換えていく、という内容だったのですが、『パーサーって業務で使うんだ!』という衝撃を感じました。
サブミッションとしてコツコツ進め、1年半かけて全てのファイルを変換したそうです。
実装にかかった時間は120時間ということで、1800ファイルを手作業で変換する時間を考えたらまさにエンジニアリングの勝利!という感じでとても感動しました。

Rails APIモードのためのシンプルで効果的なCSRF対策

@corocnさんによるAPIモードでのCSRF対策のお話。
Rails API + SPAの場合、無理やりトークンを使わずにリクエストの出どころから判断し、より安全にするためにCookieの自動送信を止めましょう、ということでした。
corocnさんは以前にRails SPAの為のCSRF対策について記事を書いていたそうですが、当時推奨したトークンを使用する方式はもう使わないでほしい!ということです。
記事を書いて満足せずにその後もより良い方針を探し、アップデートした情報を登壇して広める、エンジニアの鑑と言えるその姿勢を見習いたいと思いました。

現実のRuby/Railsアップグレード

Yuichi Takeuchiさん(@takeyuweb)によるRubyやRailsをアップグレードするにあたり現実で直面する問題のお話。
アップグレードした方がいいのはわかるけど、やりたくない理由もたくさんあるという状況から抜け出すための、具体的なテクニックが紹介されました。
ビジネス側に理解してもらうために信頼関係を築いておく、アップグレードの説明はエンジニアの説明責任であるという話を聞き、コードを書くだけがエンジニアの仕事ではないなと考えさせられました。

Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

@haruna-tsujitaさんによるReactからHotwireへ機能を移行するお話。
ReactからHotwireに置き換えられそうだけど、やってみたら全然旨味が感じられないという状況から、Hotwireの使い方を考え直すことで置き換えに成功したそうです。
昨年の大場さんの発表内容からヒントを得て解決に至ったというお話には『Kaigiって素晴らしい!』ととても感動しました。

作って理解するRDBMSのしくみ

Yudai Takadaさん(@ydah)によるRDBMSとデータ構造のお話。
RDBMSの全体像から始まり、データファイルの木構造が何故、どのように変遷していったかというお話でした。
様々な木構造がそれまでのものの弱点を克服して誕生していく、歴史を感じられてとても面白かったです。
2025年6月には京都で関西Ruby会議が予定されているということで、こちらも注目です!

ActiveRecord SQLインジェクションクイズ (Rails 7.1.3.4)

Koji NAKAMURAさん(@kozy4324)による、SQLインジェクションクイズと正しい対策の解説です。
SQLインジェクションと一般的な対策の解説がされた後、脆弱性があるコードを選択するクイズが出されました
4問目を正解できた人はかなり少ない印象でしたが、Breakmanはこの問題をすべて正解できるということです。
Breakemanは偽陽性も出すとはいえ、人間の見落としを防ぐ為にも上手に使っていきたいと思いました。

OmniAuthから学ぶOAuth 2.0

@ykpythemindさんによる、OmniAuthは何をしているのか?というお話。
OmniAuthが隠蔽している部分を実際に実装することで認証、認可の裏側に迫ります。
認証と認可とは?という基本的な話からOAuth2やOpenID Connectの規格、明日から使えるTipsと、初学者にも現在使っている人にも学びのある発表でした。

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

hatsuさん(@hatsu38)によるCI上のテストのパフォーマンス改善のお話。
テストの時間短縮、Flakyなテストの削減について具体的な手段と効果量について解説されていました。
テストの時間短縮は個人的にとても気になるトピックだったので、大変参考になりました。
Flakyなテスト対策で紹介されたcapybara-playwright-driverはテスト中の動画も見られるということで、助けられる場面が多そうだと感じました。

Hotwire光の道とStimulus

Yasuko Ohbaさん(@nay)によるHotwireの設計原則のお話です。
昨年は『Hotwire的な設計を追求して「Web紙芝居」に行き着いた話』をされていましたが、さらに研究を重ね設計指針が見えてきたということでした。
haruna-tsujitaさんの発表でも感じましたが、Hotwireは今までのRails + JavaScriptの常識を一度捨てないと本当の良さに触れることはできなさそうです。
それにしても、情報の少ないHotwireの設計原則をここまで言語化できているのは本当にすごいと思いました。

Data Migration on Rails

@ohbaryeさんによるデータ移行、変更のお話。
既に存在しているデータの移行や変更をどのように行うか、代表的なアプローチとその選定のポイントが解説されました。
Rails consoleからデータ操作するというのは「そんな恐ろしいことを何故?」と思っていましたが、緊急時にスピードを最優先すれば選択肢として上がるのかも、と解像度が上がりました。
まだRails公式のツールや手法は確立されていないということなので、今後期待したい分野ですね。

omakaseしないための.rubocop.yml のつくりかた

Shu Oogawaraさん(@expajp)による自分たちのチーム用に.rubocop.ymlを作るためのお話です。
どのようにコードスタイルのルールを決めるか、そのためのリソースをどう確保するかというマネジメントよりの話だったのですが、大変興味深かったです。
問題に取り掛かる前に取り組み方やチームの意識に目を向け、確実に成功するための仕組みを作ったことが成功の要因となるのですが、マネジメントってかっこいい仕事だなぁと感じました。
定期MTGに組み込む手法は色々な場面で役に立ちそうなので、参考にしたいと思いました。

Identifying User Idenity

MOROHASHI Kyosukeさん(@moro)によるユーザーのアイデンティティに関するお話。
架空のユーザー管理機能を題材にユーザーアイデンティティについての考察、よりよいテーブル設計の提案がされました。
usersテーブルにはIDだけを置き、個人情報やサービスに使う情報はそれぞれ別のテーブルに分けましょうという提案と、管理者は「ユーザーとして」いるわけではないというお話、どちらも「なるほど!」と感じました。
日頃そういうものだと思って作っているものにも目を向けて考える大切さを感じました。

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

島田浩二さん(@snoozer05))による、基調講演です。
Railsと出会ったばかりの「これからのアプリケーション開発者」へ向けて、設計する際に大事だと考えていることが語られました。
システム全体を考えること、シンプルさを保つように修復していくことが重要であるというお話があり、最後は『DON'T FORGET TO HAVE FUN!』というメッセージで締めくくられました。
初日のPalkanさんの基調講演でも使われた『Rails Wayは導きの星』という言葉が再び使われ、まさにKaigi on Rails 2024の締めくくりという感じのする、素晴らしい基調講演でした。

まとめ

私は昨年はオンラインで視聴していて、絶対次は現地に行こう!と思っていたので、参加できてとても嬉しかったです。
会場ではたくさんの人とお話し、出会いと知見に溢れた楽しい2日間を過ごすことができました。
次回は2025年9月25日~9月26日の開催が決定しているということで、是非また参加したいと思います!

03_next_date.jpg