Kaigi on Rails 2024カンファレンスレポート【各講演の学び】
10/25~26に開催された「Kaigi on Rails 2024」にRIZAPメンバーが参加。ここでは、会期中に開催された数々の講演について、バックエンドエンジニアのメンバーが、それぞれの言葉で感想をまとめています。
（※以下、Web上で公開されている登壇資料を適宜引用させていただいております）
梅田智大の感想まとめ
「 Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング - 」
【概要】
登壇されたのは、RubyやRailsに関する数多くの著書を執筆している五十嵐邦明さんです。初心者向けの書籍も多く出版されており、私自身も「Ruby超入門」という一冊でRubyを初めて学びました！
▼著書の一覧はこちら
今年のKaigi on Rails 2024の開幕を飾った基調講演では、Palkanさんが「Rails wayとは」を熱く語っておりましたが、それに続くように、五十嵐さんは「Rails wayに基づくモデルの適切な分割方法」についてお話しされていました。
最初に「イベント型モデル」というアプローチが紹介されました。 例えば、ユーザーが商品をお気に入りに追加するケースを考えてみましょう。 この場合、ユーザーは複数の商品をお気に入りにでき、商品も複数のユーザーにお気に入りとして登録される可能性があります。しかし、ユーザーモデルと商品モデルだけでは、お気に入りの追加処理をどこに書くべきか迷ってしまいます。 もし、ユーザーモデルに「お気に入りに追加する」というアクションを増やすと、モデルの責務が増え、Rails wayから外れてしまいます。そこで「お気に入り登録」というイベント自体をモデル化し、Favoriteモデルのような専用のモデルを用意することで、お気に入りの追加や削除をこのモデルに集約し、複数モデルにまたがる処理を整理できるとのことでした。 このように、イベント型モデルの利点として、複数モデルにまたがるビジネスロジックの置き場所が明確になる点が挙げられていました。
次に「PORO（Plain Old Ruby Object）」についても解説がありました。これは、ActiveRecordを継承せず、データベースに保存しないクラスのことを指します。 テーブルに結びつかない「モデルらしいオブジェクト」が必要になった場合にPOROを作成することで、適切な処理の置き場を作ることができ、チームメンバーも一貫した実装がしやすくなると話されていました。 また、先ほどのイベント型モデルも、イベントを保存するテーブルが存在しない場合にはPOROを活用できるとのことです。 ただし、Rails wayを保つために、クラス名は返すオブジェクトに即した名詞を使用するなど、明確なルールを設けることが重要だと強調されていました。こうすることで、後からデータを保存したくなったときも、クラス名を変えずにActiveRecordを継承させることができます。
さらに、モデルを分割する判断基準についても詳しい解説がありました。モデルの分割を検討する際、コード量が増えたことを理由に分割を考えがちですが、Rails wayに従っていればコードが負債になることは少ないと五十嵐さんは説明していました。逆に、無理に分割してRails wayから外れた設計をすると、メンテナンスが困難になるケースがあるとのことです。では、どのようなケースで分割を検討すべきでしょうか……？
1つの指標として、バリデーションを条件分岐したくなった時に、モデルの分割を検討すると良いそうです。 モデルのバリデーションでは「フォームから入力された値の検証」と、「DBへ保存する値の検証」の２つの責務を持っており、通常はこの共有が上手く機能するそうです。しかし、DBへの入力とは異なるバリデーションをしたくなった場合に、フォームオブジェクトを作成し、フォームから入力された値の検証のみの責務を持ったクラスを作ると良いとのことでした。
【感想】
Railsの魅力は、複雑さを吸収し、開発者が判断基準をRailsに委ねることで快適な開発が可能になる点です。そして、RailsはMVCモデルに基づく原則があります。
処理をどこで行うかを考える場合、MVCの3択のどれかで迷い、3択のどれにも当てはまらない場合に、サービス層などの新たな選択肢を増やす決断をされる方もいらっしゃるかと思います。 それが悪いことではないですが、層を増やすことはRailsのメリットを壊すことであり、Rails wayから外れてしまいます。 MVCの3択のいずれかに当てはめつつ、MVCの中で適切に分割していくことでRailsの恩恵を最大限に受けられるのだと、本セッションを聞いて改めて感じました。
特にバリデーションに関しては、「DB用」と「フォーム用」の２つの役割を共有しているのはRailsのよくできたところですが、意識していないと無理やり共通化させてしまい、歪な条件分岐の発生でコードの可読性が落ちていくケースがあるなと感じました。
私も、バリデーションが持つこの２つの役割をごっちゃに考えていたので、明確に２つの役割を持っていることを意識して開発をしていこうと思いました。
「イベント型モデル」については、昨年のKaigi on Rails 2023で諸橋さんが詳しく解説しており、興味のある方はぜひ以下のリンクもご覧ください。
▼諸橋さんの講演
実は五十嵐さんも、この講演に感化され、今年のKaigi on Railsでの登壇を決意されたそうです！ 私も昨年諸橋さんの講演に感銘を受けた一人ですが、今回の五十嵐さんの講演を聞いて改めて昨年の動画を見直し、Rails wayへの理解が一層深まりました。 モデルの責務を明確に捉えるとともに、モデルの適切な分割をしていくことで、Rails wayに沿った開発ができるのだということを再認識できた素晴らしい講演でした！
大杉貫剛の感想まとめ
「Rails APIモードのためのシンプルで効果的なCSRF対策」
【概要】
フロントエンドとバックエンドを分離したアプリケーションの作成におけるCSRF対策について解説する内容でした。フルスタックフレームワークであるRailsは、トークンを発行してCSRFを対策しています。このRail wayに乗ることをお勧めしますが、APIモードでRailsを使用する場合には、このRail wayから外れることになります。その場合、フロント側へのトークンの送受を自身でコーディングする必要があり、非常に難解です。
この課題に対する対策方法は、リクエストの出どころを確認するということでした。ここで注目すべきは、Rails wayで採用されているトークン方式とは全く異なるアプローチであることです。これはブラウザが送信してくれるoriginヘッダーを利用することで、リクエスト元を確認し、制御する方法です。最近になって全てのブラウザにおいてoriginヘッダーが送信されるようになったことで、可能になった対策と言えます。
また、より安全に対策するならば、cookieが自動で送信されないようにすることも有効とのことでした。3rd party Cookieの制御目的で作られたCookieのSamesite属性を用いる方法で、一部のクロスサイトリクエストでのみcookieを送信するLaxを指定します。Rails6.1以降ではデフォルト値でLaxとなっていますが、自身でSamesite属性を指定することもできます（Railsガイドに詳細あり）。
【感想】
個人的にRailsというフレームワークを使っていると、まるで魔法のように意図せずとも上手い具合にできていると思うことが本当に多々あり、いつもRailsの凄さを実感します。Kaigi on Railsは、そんなRailsの魔法を業界のエンジニアの皆さんが、丁寧に紐解いて解説してくれる感覚があり、本公演もまさにRailsの魔法を紐解く内容でした。
APIモードでの利用時に直面する課題と解決策を学ぶ中で、CSRF対策を普段あまり意識せずとも、セキュリティが担保されていたのが、やはりRails wayに乗っ取っていたからであったことを再認識しました。翻り、今回のようにフルスタックでRailsを使用することなく、Rails wayから外れてしまうような場合に、いかに今回で言えばセキュリティ対策を自分自身で実装するかということが大切で、そのためにはやはりRailsの仕組みを正しく理解しておくことが重要であると感じました。
また、本公演で感銘を受けたのが、課題へのアプローチ方法です。Railsがトークンを発行して対策しているがゆえに、いかにこのトークン方式を再現するかという視点で解決策を考えてしまいがちですが、より柔軟に課題を捉え、トークン方式にとらわれない対策を紹介されていたことが印象的でした。
大塚和哉の感想まとめ
「Hotwire光の道とStimulus」
【概要】
Hotwireを用いたRailsアプリケーション開発を行う上で、Stimulusにフォーカスしたクライアントサイドの設計指針のお話です。 Hotwireとは、SPAライクなWebアプリケーションを開発することができる、Rails標準のフロントエンドフレームワークです。 このフレームワークを使えば、JSコードの記述量を大幅に削減することができる一方で、使い方を誤れば逆に記述量が増えてしまい、複雑な実装となってしまう可能性もあります。
セッションでは、Hotwireを活かせている設計指針のことを「光の道」と表現し、どのような考え方をすればその道から外れない実装を行うことができるのか、具体例を交えながらご説明されていました。
スピーカーの大場さんは、昨年のKaigi on Rails 2023でもHotwireについて講演されており、その時は「Web紙芝居」というのがキーワードになっていました。 「Web紙芝居」とは、一言でいうと「画面の制御はサーバーサイドに集めよう」というものです。これは今回の講演でも序盤に大原則として掲げており、その上でクライアントサイドではどのようにStimulusを扱うべきかを話されています。 詳細な説明は省きますが、一言でいえば「主な画面変更はサーバーサイド（Rails+Turbo）で行い、JSでしかできない画面変更だけをStimulusにやらせよう」というのがポイントになります。登壇資料でも、図をたくさん用いてとても分かりやすく解説されているので、ぜひご覧になってみてください。
【感想】
Hotwireと一口に言っても、実際はTurbo、Stimulus、Stradaという3つの要素から構成されており、またTurboに関してはさらにTurbo Drive、Turbo Frames、Turbo Streams...と多くの要素で構成されています。それぞれの「責務」を明確にさせないと、かえって以前より複雑な実装になってしまうのがHotwireの難しいところです（これはどの言語のどのライブラリにおいても同じことが言えますね）。
しかし、昨年と今年の2講演を通じて 、TurboとStimulusのそれぞれの責務や目的がかなり鮮明になり、光の道が見えてきたように感じます。 ぜひ実践でも使えるように、まずはRails+Turboでサーバーサイドに画面制御を寄せる意識を身につけていきたいです。
余談ですが、私は昨年の「Kaigi on Rails 2023」も当時内定者として参加しており、大場さんの講演も実際に会場で聴講していました。
▼私が昨年書いた講演レポートはこちら
昨年はHotwireに関する講演が他のカンファレンスも含めてかなり多かった印象で、まさしく「Hot」な話題だったのですが、私自身この辺に関してはかなり苦手意識があり、少し敬遠していたものでした。
しかし、実際に大場さんの講演を聴いてみると、「紙芝居」という表現を用いて、どうしてHotwireの実装が複雑になってしまうのか、その具体例を交えながら分かりやすく話されており、苦手意識が一気になくなったことを今でも覚えています。前回のアーカイブもありますので、ぜひ皆さんもご覧になってみてください（実はこの講演の最後に「Hotwireの光の道」という言葉が出てきます。1年越しの続編ということが伺えますね）。
▼アーカイブ
「紙芝居」や「光の道」など独特の表現で聴講者を惹きつけ、視覚的にも分かりやすく講演をしてくださる大場さん、今から既に次回の講演が楽しみです。
小林駿の感想まとめ
「作って理解するRDBMSの仕組み」
【概要】
RDBMS（関係データベース管理システム）の全体像とその一般的なアーキテクチャ、データ構造とアルゴリズムについて詳細に説明されていました。
まず、RDBMSの基本的な仕組みと動作を理解するための枠組みが提供されました。RDBMSの主要コンポーネントとしては、構文解析器、プランナ/オプティマイザ、クエリエクスキュータ、バッファプールマネージャ、ディスクマネージャがあり、それぞれが重要な役割を果たしています。構文解析器はクエリを解析してAST（抽象構文木）を生成し、プランナ/オプティマイザはASTを基に最適なクエリ実行計画を立案します。クエリエクスキュータは実行計画に従ってデータアクセスと操作を行い、バッファプールマネージャはメモリキャッシュ管理とページ置換を行ってディスクアクセスを最小化します。ディスクマネージャはデータの物理的な読み書きを管理し、永続化と整合性を保証します。
次に、データの格納方法や検索アルゴリズムについて解説されました。データファイルの構造にはヒープファイル、ハッシュファイル、インデックス構成表があり、それぞれ異なる方法でデータを格納します。ヒープファイルはデータが挿入順に格納され、ハッシュファイルはハッシュ関数に基づいてデータを格納します。インデックス構成表はデータがインデックス構造に格納されます。
インデックスの種類にはBtree、Hash、GIN、GiST/SPGiSTがあり、用途に応じて使い分けられます。Btreeは等価検索や範囲検索に適した一般的なツリー構造で、Hashは長い文字列データの等価検索に最適です。GINは多対多の関係を持つデータの検索に適しており、GiST/SPGiSTはさまざまなデータ型や演算子に対応可能です。
特に、B+treeの詳細な構造についても解説されました。B+treeはBtreeの一種で、データを全てリーフノードに格納し、内部ノードには索引だけが保存される構造です。リーフノードは連結リストでつながっており、範囲検索や順次アクセスが効率的です。B+treeの操作はO(log n)の時間で行え、範囲検索がさらに効率的です。利点としては範囲検索が高速である一方、挿入や削除にはオーバーヘッドが伴います。
B+treeの構造や意図を理解し、適切なインデックスを作成することが重要です。カーディナリティが低いカラムに対するインデックスは遅く、複合インデックスの使用方法にも注意が必要です。B+treeの構造を理解することで、効果的なインデックスの利用が可能になります。
【感想】
本セッションは、Kaigi on Railsの中で唯一、RubyやRailsの話が一切ないセッションであり、当社技術顧問の松田さんも「トランプのジョーカー」とおっしゃっていました。どんな内容になるのか、セッション前から非常にワクワクしていました。
セッションでは、RDBMSの全体像や主要コンポーネント、データ構造とアルゴリズムについて詳しく解説されました。特に、構文解析器やクエリエクスキュータ、バッファプールマネージャなどの役割と連携について学び、RDBMSがどのように効率的に動作しているのかを理解できました。また、B+treeの構造や効率性についても学び、データベースの設計や最適化に対する視点が広がりました。 RDBMSをただのデータストアとしてではなく、その内部構造や動作を意識しながら扱うことができるようになりました。
カンファレンスやセッションを通して、技術に対するモチベーションが大いに向上し、さらに知識を深めていこうという意欲が湧いてきました。今回のKaigi on Railsへの参加とセッションへの参加は、私にとって非常に有意義な経験となりました。学んだことを業務に活かし、より良いプロダクトを提供できるよう努めてまいります。
佐藤智希の感想まとめ
「約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり」
【概要】
約9000個の自動テストを50分から10分に短縮し、偽陽性率（Flakyテスト）を1%以下に抑えるための具体的な取り組みについて学びました。実際のプロジェクトでの経験を基に、さまざまな改善策が詳しく説明されました。本セッションに興味を抱いたのは、実務でMinitestをCIに導入したことがきっかけです。現在、自社ではCI実行時間が10分ほどで収まっていますが、将来的にテスト数が増加する可能性があるため、事前に予防策を模索するために参加しました。
2023年時点で、プロジェクトではテスト数が7800以上あり、CI実行時間が50分を超えていました。また、Flakyなテストも多数存在していました。理想は5分以内、遅くても10分以内に完了させることを目指して、以下の具体的な取り組みが行われました。その結果、CI実行時間を10分まで短縮することができました。
Capybaraの機能に任せてSleepを削除
Loadingを動的に待つHelperを作成し、Sleepを削除
test-profのbefore_allを使用してデータ作成を省略
test-profのlet_it_beを使用してデータ作成を省略
parallel_testsの並列実行を活かすためにファイルを分割
FactoryBot.create()ではなくFactoryBot.build_stubbed()を使用
分けなくていいテストは1つのit do ~ endにまとめる
不要な機能やテストの削除
Loadingを待つ処理も可能なら削除
KnapsackPro gemの利用
遅いテストファイル、遅いテスト、過去に失敗したテストをダッシュボード化
Next.jsのBuildをキャッシュ化
capybara-playwright-driverの追加
AllureReportの追加
GitHubのAllureReportのリンクBot
【感想】
登壇後、スピーカーの方に自社で使用しているMinitestでも同じ対策が可能かどうかを直接聞いてみたところ、Minitestでも同様の対策が可能であり、テスト結果をレポート化してLookerでダッシュボード化することや、E2Eテストを細かく分けることがCI実行の短縮に繋がるとアドバイスを頂きました。
私にとって、新卒でカンファレンスに参加し、実際のスピーカーと会話することは貴重な体験となりました。まだ知識が不足しているため、分からない用語が多くうまく質問することはできませんでしたが、スピーカーの方がこちらの言いたいことをうまく汲み取ってくださり、感謝しています。
セッションを通じて、多くの企業がCIで自動テストを実行している際に実行時間が10分を超えていることを知りました。また、Flakyなテストについても詳しく学びました。Flakyなテストとは、コードに変更がないにもかかわらず、テストが成功したり失敗したりと不安定な実行結果になるテストのことです。自社のCIにもFlakyなテストが数個存在しており、将来的に修正する際に工数が大きくかかってしまう可能性があるため、早急に修復しなければならないと感じました。
また、セッションやスピーカーとの会話を通じて、自社がMinitestを採用している理由が曖昧であったため再度調べてみました。自社のテストガイドラインでは、テストをシンプルに保ち、必要以上にテストを書かないことが強調されています。MinitestはRailsのデフォルトテストフレームワークであり、シンプルなテスト環境を提供します。これにより、テストの複雑さを避け、ビジネスロジックに集中できる利点があります。テストライブラリ一つ取っても多くの要因があることを実感するとともに、会社ごとのサービスや使用しているライブラリによってエンジニア文化が異なることを学ぶことができました。
昨年の「Kaigi on Rails 2023」に自主参加しており、その当時はどのセッションを聞いても全く理解できませんでした。今年の「Kaigi on Rails 2024」も理解できないのではないかと不安が大きかったですが、1年で成長を実感できるカンファレンスとなりました。全く分からない状態から少しは触ったことがあるレベルまで進歩し、自分の成長を感じることができました。来年はスピーカーのみならず、カンファレンスに参加している人々とフランクに技術的な相談ができるように知識を養っていくことと、スピーカーとして登壇できるよう邁進したいと思います。
金子良将の感想まとめ
「omakaseしないためのrubocop.yml のつくりかた 」
【概要】
ご登壇されたのは、リンカーズ株式会社のShu Oogawara(@expajp)さんです。
RuboCopは、コードスタイルをチームで統一するのに便利なツールです。一方で、その設定は個人の好みに依るところが大きく、物議を醸すことが多いのも事実です。登壇者のOogawaraさんのチームでも、同様の悩みを抱えられていたそうです。
本セッションでは、9ヶ月かけてその悩みを解消し、チームならではのrubocop.ymlを作り上げたその過程について大変有益で興味深いお話を伺うことができました。
【感想】
全体を通して大変有益で興味深い発表でした。その中でも、私が最も印象に残ったのは「そもそも.rubocop.ymlをつくるのはなぜ難しいか？」について言及された箇所です。
Oogawaraさんはこの問いに対して以下2つの理由を挙げられました。
直接は売上を生まないから
チームの文化を言語化・集約したものだから
これは個人的に、大変クリティカルな回答だと感じました。特に2つ目の「チームの文化を言語化・集約したものだから」ですが、私はここで「文化」という言葉を用いられたのがとても素敵だと感じました。
また、Oagawaraさんは上記2つの理由は具体的に以下の問題が原因だと言います。
売上を生まない → 時間の確保が難しい
文化の言語化・集約 → ファシリテーションが難しい
こうした問題に対して、Oogawaraさんのチームが採用した以下の方法は大変勉強になりました。
既存の定期MTGの中に時間を確保する
意見表明の幅は広く、採決ルールは細かく
私自身、今回のようなお話を聞かずに「.rubocop.ymlをつくろう」となった際には「早急に決めて実際の開発に時間を割こう」と考えるだろう、と容易に想像できます。 これに対して、そう考えがちな原因を言語化して「既存の定期MTGの中に時間を確保する」という方法を採られたのは非常にスマートだと感じました。ぜひ、実際に真似させていただこうと思います。
また、先述の通り.rubocop.ymlは「チームの文化」ですから、まずは一人ひとりの文化の違いを尊重し、その上で最終的には1つに決定しなければなりません。大変難しいところですが、これに対して「意見を尊重するため、表明の幅は広く。ひとつに決めるため、採決ルールは細かく。」とお話いただきました。
これも素直に、非常に文化的でとても良い方法だと感じました。仕事に限らずこうした難しい場面にはしばしば遭遇しますが、お話しいただいた言葉を思い出したいところです。
最終的に、Oogawaraさんのチームでは週次MTGで時間の余裕のあるときに淡々と決定していくことで、9ヶ月かけて自分たちの.rubocop.ymlを作り上げることができたそうです。9ヶ月と聞くと驚きますが、実際には週に15分ほどの時間を割くだけなので期間中に他の業務も圧迫されず、負荷はとても小さかったそうです。すごい……。
発表の最後に「.rubocop.ymlとはチーム文化の反映であり、チームの文化は必ず移り変わっていくものです。ならば.rubocop.ymlも移り変わらなくてはならない」という言葉がありました。この言葉通り、実際に9ヶ月かけて作ったら終わりではなく、定期MTGの中で継続的にメンテナンスされているそうです。
今回の発表では、スマートで持続可能な素晴らしい方法をご紹介いただきました。ありがとうございます！それだけでなく、終始登壇者のOogawaraさんの言葉選びが光る発表で、大変面白かったです。私もいつかこんな発表ができることを目指して、日々邁進しようと思えたセッションでした。
新井幸希の感想まとめ
「Identifying User Identity」
【概要】
登壇者は諸橋恭介さんです。サービスの利用者を「ユーザー」と一括りにしがちですが、実際には事業領域ごとに適切な呼び名を付けることが重要です。これにより事業領域の理解が深まります。システム要件としてのユーザーは、サービス上で「一人」の主体として識別される単位です。
架空の「ユーザー」管理機能の実装例を通じて「利用者」をあらわす「ユーザーのアイデンティティ」とは何か、そのデータをどう永続化させるか、ランタイムではどう見えるか、といったことを考察してきます。
まず、ユーザーのActiveRecordモデルUserを定義し、以下の三つのテーブルを作成します。
usersテーブル
必要なカラムは主キーとcreated_atだけで良い
主キーを見せたくない、UUIDなどの時は人間が見やすい代理キー（alternate key）はあってもよい
ほぼidだけにすることで、identityがあることそのものを表現できる
`belogns_to: user`データを作れる
user_credentials
秘密にしたいユーザーの情報(住所、メールアドレス、電話番号など)を管理する
退会したい時にこのデータを削除する
user_priofiles
そこまで秘密にしなくても良い情報（region、お気に入りなど）を管理する
これにより、usersテーブルに情報が残ったままユーザーの状態を表現できます。退会時にはuser_credentialsを削除するだけで、usersテーブルは変更せずに退会ユーザーを管理可能です。
次に、ログイン機能の説明がありました。ログイン機能は大きく二つに分かれます。「各機能にてログインしているユーザーを判別する機能」と「ログイン操作そのものの機能」です。
まず前者についてですが、リクエストの操作主体が、このアイデンティティを持った存在である、ことがわかれば良いと説明されていました。 Railsで何かしらの実装している人ならば馴染みの深い`ApplicationController#current_user`的なメソッドで、usersテーブルから検索しUserを検索し、Userインスタンスを取得します。これが非ログイン中ならnilを返して終わりです。この考え方はAPIでも同様で参照元がJWTやBearerトークンだけです。current_userを使って、各種機能内で当該Userのデータを読み書きできます。
代わって後者の「ログイン操作そのものの機能」の説明ですが、本人だけが入力できるパスワードやemailなどの情報を突合し、本人確認します。この信頼性の担保やバリデーションの対応が大変で、ライブラリやIDaaSをうまく使いたいよねと話されていました。確認できたユーザーのIDはセッションに保存します。
次に、ユーザー登録についての説明がありました。ユーザーのアイデンティティは、登録フローの完了時に生まれると考えます。登録フロー中はusersテーブルにレコードを追加せず、新しいモデルを用意します。これにより途中保存やバリデーションが可能になり、usersテーブルの検索時の状態管理が簡単になります。user_credentialsに関連した列のユニーク制約をすることができます。
また、仕様追加を想定して、特別な権限でのログインについての説明がありました。管理スタッフと一般ユーザーは異なるアイデンティティとして扱います。usersテーブルにカラムを追加するのではなく、アイデンティティプールを分けて実装します。これにより、権限の問題を別の実装として扱い、複雑さを減らせます。
セッションの終盤では、「ユーザー管理」は重要なエンティティであり、複雑さが存在しますが、原則に沿って整理することで、かっこいいコードが書けると話されました。これにより、サービスの目玉機能を伸ばす役にも立てられるとのことです。 status列がなくてもテーブルの連結やデータの存在チェックでユーザーの状態を表現できるコードを説明していただき、セッションは終了しました。
【感想】
これまで、ユーザーのアイデンティティで悩んだことは数知れず、権限の扱いでも様々な問題に直面し苦労してきました。セッションを聞きながら過去のプロジェクトで経験してきた問題を思い出していました。
usersテーブルにさまざまな情報を持たせたくなってしまう気持ちが生まれてしまうので、今回のセッションで見たusersのテーブルを3つに分けるのは、個人的にとても綺麗な構成に見えました。特に、契約関連のステータスをどうにかするために、状態を意味するカラムを持たせたくなるところを、scopeに落とし込めるのはいいなと思いました。Kaigi on Railsの他のセッションで「標準の道具、標準の方法、必要十分で作る」という話がありましたが、それに通じるものがあるなと感じました。自分も原則に沿って実装していきたいです。
＼あなたもRIZAPのエンジニアとして働きませんか？／
▽新卒採用
▽中途採用