Kaigi on Rails 2025に参加しました!

9/26(金)、9/27(土)にKaigi on Rails 2025に参加してきましたー!

kaigionrails.org

今回の会場はJPタワーホール&カンファレンスでした。東京駅丸の内南口から徒歩1分というとてもアクセスが良い場所でした!

事前準備

これまでKaigi on Rails 2023, 2024に参加してきたのですが、事前準備は特にしていませんでした。今年のRubyKaigi 2025の参加前にたくさん準備をしたことによって、初参加でしたが技術的な内容も楽しむことができました。
その経験がきっかけとなり、「Kaigi on Railsも事前準備をした方がもっと楽しめるんじゃないかな?」と思って参加前に以下のことをしました。

このおかげで、セッションで話される内容について少し知識がある状態でお話を聞けたので今までよりはセッション内容が理解できてより楽しめたように思います。

特に印象に残ったセッション

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

kaigionrails.org

タイトルの通りRailsアプリケーション開発者向けの本紹介のお話でした。紹介された本の分野が膨大で、「これらの本を全て読まれているのか...」とびっくりしました。
本の紹介の前に冒頭でRailsでサービスを作るときに必要なもの、現代でも書籍を読む理由についてお話をされていた内容が印象に残りました。

  • Railsでサービスを作るには、ソフトウェア、チーム、文化を作る必要がある
  • ここでの文化とは、個々人を超えたチームで良いアプリを開発し続けるための知識や習慣のこと
    • チームメンバーはずっと固定ではないので文化が必要になる
    • 不明な箇所について過去のチームメンバーに聞くことはできない
    • 未来のメンバーとも会話はできない
  • 書籍は「みんなが同じものを読める」というメリットがある
  • 情報の鮮度が不要、あまり知らない領域について学ぶ時に書籍が有用

「事前のおことわり」で「文章が読める速度を超えてページをめくることがある」と書かれていたのですが、本当に読めないスピードでスライドが進んでいました! これだけの量の本を読んで、紹介までできるのが凄すぎます。
セッションには関係ないことですが、スライド作りの際にいつも高橋メソッドを使っているので、ご本人の登壇が見れたのが嬉しかったです

2分台で1500examples完走!爆速CIを支える環境構築術

speakerdeck.com

並列処理によりRSpecの実行速度を早くする方法についての話でした。

  • parallel_tests gemを使ってテストを並列実行
  • 論理DBに分けて複数プロセスによりテストが実行されるけど、バラツキが発生するため一番遅いプロセスに律速されてしまう
  • Knapsack Proを使うことで最適な分割をしてもらう
  • EC2のEBSのデフォルトは3,000IOPSなのでDB書き込みでIOが飽和する
    • IOPS(Input/Output Per Second): 1秒間にできる読み書き回数
  • メモリ上にファイルシステムを構築できるtmpfs

最後に、ハイスペックな物理マシンにしてCIが爆速になったのがめちゃくちゃ面白かったです! つよつよ物理マシンを組み立てて爆速でテストを終わらすのにロマンを感じました😃

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

speakerdeck.com

Serviceクラスについて、いつからどのように使われたのか、joker1007さんがどのように考えていたか、今はどう考えているかをお話されていました。

  • 『エリック・エヴァンスのドメイン駆動設計』の影響を少なからず受けて、サービスクラスという名前が使われ始めた
  • Fat Modelが問題になってきていた
  • 『パーフェクトRuby on Rails』では、サービスクラスの利用時には適切な命名が必要と説明していた
    • 乱用は危険とも書いていた
  • 乱用についての度合いが人によって違う
  • Fat Modelに対応するための折衷案としてのFormクラス
    • ただし、サービスクラス同様ActiveRecordをうまく整理しないといけない
  • RDBと向き合うことが大事
  • 重要なのはドメインコンテキストの理解

DDDについてほとんど知らないためお話しされていた内容自体の理解度は低いと思うのですが、自分の理解では「まずドメインについて理解して、同じ文脈で話せるサブセットに分割してそれぞれの依存関係を整理したうえで、社内で役割が違う人でも通じるような命名を行う。そのうえで、そのドメインを自然に表現できるようなRDBの設計を行う。」ということかなと思いました。
一言に要約すると「ドメインの整理ができてない状態でServiceクラスを使うな」ってことかなと思いました。
最後のページに書かれていた「正解は無い、一緒に考え続けましょう」「ソフトウェア設計は継続的な営み」という言葉が印象に残りました!

さいごに

今年で3回目のKaigi on Rails参加になったのですが、過去一いろんな方とお話ができてとても充実した2日間になりました!
イベントを通じて技術の話で盛り上がったり、その話がきっかけとなり関連イベントを立ち上げることになるというKaigiEffectもありました。
去年は参加できなかったKaigi on Rails事後勉強会にも参加する予定なので、楽しみですー!
今年のKaigi on Railsも最高のカンファレンスでした!運営の皆様やお話していただいた方々ありがとうございましたー!!