Kaigi on Rails 2024参加レポート
はじめに
2024/10/25〜2024/10/26に行われた「Kaigi on Rails 2024」に参加してきました！ 去年に続いて2回目の参加です。
聴講したセッションの中でとても印象に残ったものを紹介していきます。
基調講演
まずはじめのセッションはPalkanさんによる基調講演です。
日々成長を重ねるRailsアプリケーションにおいて、Rails Wayに従った設計に関するお話でした。
講演内容： 講演資料：
ブログ：
講演の内容を軽く要約します。
アプリケーションが成長するにつれてMVC(Model, View, Controller)という3つのレイヤーでは不足することがあります。
その際、Rails Wayは導きの星となり(Rails Way gives you guidance)、「Railsを習得し、拡張する」することが重要です。
「Railsを習得する」とはRailsの設計パターンを学び、規約の原則を受け入れることです。
また、「Railsを拡張する」とはRailsの開発者の目線で新しい抽象レイヤーを導入していくことです。
講演の最後にはこれらの話の実践例として、複数画面に渡る入力フォームをFormオブジェクトを用いた実装を紹介していました。
適切にレイヤーを分けてRails Wayに沿うことで、シンプルな設計で複雑な仕様を実践しており、感動しました。
Palkanさんの書籍に詳しく載っているようです。 詳しく知りたい方は、ぜひ読んでみてください。
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング
講演内容： 講演資料：
保守性が高いアプリケーション開発で重要なモデル設計に関するお話でした。
基調講演の内容にも関連していたので、理解が深まりました。
モデルの設計をする際に「イベント型モデル」という「行為」を記録・処理するモデルを見つけると良いそうです。例えば「会議に参加するモデル」（=Attendモデル）などです。
複数のモデルにまたがる処理を担うことで、ロジックがコントローラにはみ出すことを防げます。
また、モデルを分割するタイミングとしてはコード行数ではなく、「バリデーションを条件分岐したくなったとき」だそうです。
アプリケーションが小さいフェーズでは、DBに保存するためのバリデーションとユーザーの入力に関するバリデーションをどちらもモデルが担っています。
しかし、アプリケーションが大きくなるにつれてバリデーションを条件分岐する必要が出てくることがあります。
validates :name, presence: true, if: ->{ フォームからの入力 }
このようなコードが出てきた際がモデルを分離させるヒントであり、ユーザーフォームに特化したFormクラスを作ることで、バリデーションを分離させることができます。
スピーカーの五十嵐さんが書いている「Railsの練習帳」に詳しく載っているようです。
Identifying User Identity
講演詳細： 資料：
ほとんどのシステムで登場する「ユーザー」をどう表現すれば良いか、一つの設計アイデアに関する発表でした。
諸橋さんが提案する「ユーザー」とはなんと「idカラム（+created_at）しか持たないUserモデル」でした。
「メールアドレスとかパスワード、名前とかはどうするのか？」と思いました。
が、認証情報はUserCredentialsモデル、名前などのプロフィール情報はUserProfileモデルなど別のモデルとして定義するようです。
（引用：https://speakerdeck.com/moro/identifying-user-idenity?slide=22）
サービスの主要な機能を使っている間にプロフィールや認証情報を参照するシーンは実は少ないので、このようなモデル設計でも十分に機能するようです。
このUserモデルを基軸にして、サービスの登録、ログイン、利用、退会に関する処理をシンプルに実装することができるようでした。
私はこの講演を聴いて、Userモデルにほぼidしか持たせないことに非常に驚きました。
アプリケーションが大きくなるにつれてUserモデルには様々なカラムが追加されがちです。
idしか持たせないという一種の規約を設けることでシンプルな設計にできることを知り、モデル設計の大事さを痛感しました。
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜
講演内容： 講演資料：
ブログ：
デプロイでやらかしてしまった話とそれらにどのように対応したかという講演でした。
デプロイによって実行中だったSidekiqのジョブが消し飛んでしまったという話があり、自分たちのサービスは問題ないだろうか不安がよぎりました。
自らの失敗に対処するだけでなく、他のサービスや他のチームに影響がないかを確認する姿勢がとても素晴らしいです。
Sidekiqで実現する長時間非同期処理の中断と再開
講演内容： 講演資料：
ブログ：
Sidekiqで実行に長時間かかるジョブを中断したり、再開したりするための実装方法に関する講演でした。
Redisに進捗状況を保存しながら処理を進めることで中断処理と再開処理を実現できるようです。
理論だけでなく、具体的なコードも紹介していただいたのでとても分かりやすく勉強になりました。
Sidekiqの新しい機能であるSidekiq Iterationでは今回のような中断処理や再開処理が実現できるようなので、ウォッチしておこうと思います。
Sidekiq vs Solid Queue
講演内容： 講演資料：
ブログ：
以前所属していた会社で技術顧問をしていただいていたwillnetさんの講演でした。
バックグラウンドワーカーとして有名なSidekiqとRails 8で標準となったSolid Queueを比較しながら解説した講演でした。
様々なバックグラウンドワーカーが誕生した歴史を紹介していただいたので、SidekiqやSolid Queueが生まれた背景を知ることができ、Solid Queueの特徴についても勉強になりました。
簡単に違いをまとめると以下のようです。
| 観点 | Sidekiq | Solid Queue |
|---|---|---|
| ストレージ | Redis | RDB |
| インターフェイス | Active Job経由でも直接利用でも可（直接利用したほうが機能が多い） | Active Job経由 |
| 機能 | バッチ処理やレート制限、暗号化などSolid Queueにない機能がある | 標準的な機能は備わっている |
また、「今使っているSidekiqからSolid Queueに移行するべきか」という疑問に対して一つの考え方を示していただき、とても参考になりそうです。
さいごに
今年のKaigi on Railsもとても楽しかったです！
様々な発表を聴き、やっぱり技術って深みがあって面白いと感じました。
懇親会などでお話させていただいた皆さんありがとうございました。
最後の基調講演にもありましたが、日々の開発を楽しんで過ごしていきたいですね。
来年こそはCFPを提出して、発表したいぞ！！
Discussion