🛤️

【イベント参加レポート】Kaigi on Rails 2024

2024/10/28に公開

2024/10/26, 27 に行われたKaigi on Railsの参加レポートになります。

kaigi_on_rails_2024

10/26

基調講演:Rails Way, or the highway

感想

  • Rails WayはWebアプリケーションを構築する方法論に止まらず、哲学であり、導きの星である
  • Railsを拡張するためにはRailsを習得し、Railsの抽象化に沿って拡張することが重要
  • OSI参照モデルとTCP/IPモデルの対応図のようなLayed ArchitectureとRailsの抽象化の対応図が印象に残りました
  • 抽象化は一朝一夕で身につくものではないと思うので、Rails Wayという哲学を頭に置きながらRailsを学び続けたい

参考

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

感想

  • POROのユースケースやルール作りの話が勉強になりました
    • 「クラス名には返すオブジェクトの名前を名詞でつける」
  • 複数のテーブルにまたがる複雑な処理の場合に安易にServiceクラスを作っていたが対応を考え直したいと思います
  • Serviceクラスが何故望ましくないかを基調公演の内容も踏まえて理屈で理解することができました
  • POROを使用してRails Wayに沿った設計を意識したり、新規にテーブルを追加するケースではイベント型モデルを探しだすようにしたい

参考

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

感想

  • 処理が長い非同期ジョブを実装したことがないため、中断や再会処理を意識したことはないが実装方法が勉強になりました
  • Sidekiq Iterationを初めて知りました
  • Sidekiqは複雑だが、機能が充実しているため、再度触る際にはドキュメントを改めて熟読したいと思います

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

感想

  • スクリプトを組んでViewComponentを自動生成する考え方が勉強になりました
  • フィーチャーフラグやカナリアリリースを活用して段階的にリリースして安全性を確保している点も勉強になりました

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

https://x.com/kaiba/status/1849729753865125982

感想

  • 困ったらRailsガイドを読む
  • VCRで記録したレスポンスを修正する考えはなかったのでユースケースとして覚えておきたい
  • ローカルでLLmを実行できるLM Studioを初めて知った

参考

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

感想

  • 障害が発生した際の対応とその後の原因究明の話を明確にわかりやすく言語化できている点が素晴らしかったです
  • アプリケーションの実装に意識が向きすぎていてECSの設定や仕組みの理解が疎かになりがちなので注意したい

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

感想

  • 仕様書やドキュメントを元にE2Eテストを自動化する考えはLLMが流行り始めたときから抱いていたので興味がありました
  • LLM関連のmeetupでスクリーンショットを元にブラウザを自動操作させる話を聞いたことがあり、その延長線上で理解できました
  • 挙動のランダム要素がまだあるため実際に使えるレベルにはないが、近い将来に実用化される可能性があると感じました

10/27

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

感想

  • ActiveRecordでDB操作を行う際にどのケースがSQLインジェクションになるか曖昧に覚えていたので知識を再確認できました
  • Brakemanを初めて知ったので導入方法や使い方を調べてみたいと思います

参考

OmniAuthから学ぶOAuth2.0

感想

  • 外部認証を実装する際に使用するOmniAuthの仕組みについての発表
  • コードを読みながら自前で実装するプロセスをを通して外部認証の裏側の仕組みを大まかに理解できました

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

感想

  • 自動テストの実行時間の長さが開発者体験を低下させていたので短縮する方法を知りたかったので勉強になりました
    • 会場のアンケートでも自動テストの実行時間が20分以上という声が多かったです
  • まずはtest-profを導入してbefore_alllet_it_beがどの程度使用できるかを検証してみたいです
  • Allure Report及びVercelにhtmlをデプロイしてテスト結果をレポートする方法も勉強になりました

参考

Sidekiq vs Solid Queue

感想

  • Rails8.0からデフォルトになるSolid Queueの話
  • SidekiqはActive Jobを経由しないで使用した方が良いという説の事情やSolid Queueが導入された経緯について歴史的な背景を知ることができ勉強になりました

The One Person Framework 実践編

感想

  • The One Person Frameworkという概念を初めて知りました
  • ブログ記事に記述はありましたが、「一人分の脳に収まる程度の情報量でアプリを記述できるように」という表現がわかりやすかったです
  • 「居住可能性」という表現も興味深かった
    • 心地よく自信を持って変更を加えられる
  • それを更にチームの枠組み拡張するアプローチが興味深かった
  • The One Person FrameworkもRailsの哲学としてアプリケーション開発及びマネジメントに活かしていきたい

参考

Data Migration on Rails

感想

  • データマイグレーションの運用を見直す良い機会になりました
  • メリット・デメリットを整理やサーベイの確認、各アプローチの評価項目を整理して検討する方法が横展開できるので参考になりました

参考

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

感想

  • Rubocopのルールを決める際にチーム内でコンセンサスを取るまでの取り組み方についての発表でした
  • 定期的なMTGと合わせて実施することで取り組みやすくする工夫やテンプレートを作成して議論を進めやすくする方法が参考になりました

参考

Identifying User Identity

感想

  • 登壇者の方の前の発表や前日のRailsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -と内容が繋がる箇所があり、Railsのモデル設計についての理解が深まりました
  • Userのような普遍的なモデルは様々な箇所で参照されるとともに役割を多く持つため、Fatになりやすいですが今回の発表の考え方が勉強になりました
  • 最後のスライドでstatus列を参照することなく状態を表現する方法が興味深かったです。DBで参照するたびにテーブル内の状態を確認するのではなく、関連テーブルとの結合で状態を取得する方法が大変勉強になりました

参考

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

感想

  • 設計する際に選択する権利を持つことが大切であり、Railsは権利をサポートしてくれるフレームワークである
  • 修復が必要な箇所を見つけるためには、システムを複雑にせず認知負荷を減らすことが大切
  • 「楽しさとはビジネス価値がある」フレーズを念頭に置いて設計と修復を続けていこうと思いました

参考

全体を通して

Rails Wayはただの開発手法ではなく、哲学であることを実感しました。
1日目の基調公演が理想的な基調公演だったことを懇親会などで話しましたが、
2日目の発表でもこの基調公演の内容に早速触れられている方が何名かおり、
最後の基調講演でも再度触れられていたので、
Rails WayがRailsの開発者にとって重要なものであることを改めて認識しました。

GitHubで編集を提案

Discussion