はじめに
こんにちは！ @mterada1228 です。本記事は Kaigi on Rails 2024 の参加レポートです。
本記事ではこれからアーカイブやスライドを見よう！という方向けに、どういった読者がどのセッションを見ると良さそうか、まとめ記事的に書いていこうと思っています。
私が現地で聞けたセッションのみ、また、内容は私の主観を基に書いたものにはなりますが、この記事が一人でも多くの方にとって各セッションを見るきっかけになってくれればと思います！（ほんとにすばらしいセッションばかりなので…届け！）
Rails Way or the highway (keynote)
https://evilmartians.com/events/keynote-rails-way-or-the-highway-kaigi-on-rails-2024
こういった方におすすめ！
Rails でアプリケーションを構築する多くの方が、Fat Model, Fat Controller の問題に直面することになると思います。その一つの解決方法として、標準の MVC 以外にレイヤー（例えば FormObject）を導入するというテクニックがあります。
しかし、こういったレイヤーの追加は、あまりに自由度が高いためにかえってカオスな状況を生み出してしまうことも珍しくありません。
このセッションではレイヤーを追加するのに適したシチュエーションにはどういったものがあるか、レイヤーを追加する時にはどういったルールを設けるべきかを紹介し、適切なアプリケーションの育て方を知ることができます。
Railsの仕組みを理解してモデルを上手に育てる – モデルを見つける、モデルを分割する良いタイミング –
こういった方におすすめ！
keynote でも触れられていた Fat Model の問題を取り扱ったセッションで、併せて見ると理解が深まっていいと思います。
keynote はアプリケーションにレイヤーを追加して Model を分割することに軸を置いた話でしたが、こちらではデータモデリングの見直しといった、より広い視野でアーキテクチャの設計を見直す手法に触れています。
Rails に限らず応用できる知見が詰まったセッションで、フレームワークが提供する機能に頼らない、基礎原則に立ち返ることの重要さを思い出せてくれます。
そのカラム追加、ちょっと待って！カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?
こういった方におすすめ！
このセッションでは ActiveRecord を例に挙げて、Ruby のメモリ確保の仕組みを解説してくれています。タイトルだけ見ると難しそうな内容に思えますが、初学者に向けて作られた非常に丁寧な解説となっています。
現実にはメモリの使用量がボトルネックになる処理は存在するわけで、低レイヤーがわかる/わからないは、自分がこういった問題に対処できるがどうかに大きく関わってくると思います。
とはいえ何から始めたらいいのかわからない…という方にとって、このセッションはとてもおすすめです！
Sidekiqで実現する長時間非同期処理の中断と再開
こういった方におすすめ！
バックグラウンドジョブの活用は、高いワークロードが必要な処理をこなすために必要不可欠なアプリケーションの構成要素ですが、長時間の実行時間を必要とするジョブには様々な課題があります。
その一つがデプロイによるジョブの中断です。このセッションでは SmartHR で実際に取り入れられている安全にジョブを一時中断・再開するための仕組みが紹介されています。
決して個社にしか適用できない実装例ではなく、そのまま自分のアプリケーションに取り入れられそうな実装となっていました。同様の事例に悩みを持つ方は参考にしてみるとよさそうです！
JRubyのパワーを解き放つ：パフォーマンスと多様性向上のためのRailsアプリ
こういった方におすすめ！
Rails は CRuby で動かされることが一般的ですが、JRuby で動かすことも可能です。本セッションでは JRuby で動かすことによって得られるメリットと、実際に CRuby から JRuby にマイグレーションするために必要となるプロセスを紹介しています。
このセッションを聞くまでは、Rails を利用する際にインタプリタの技術選定を行う、というところまで考えたことは正直ありませんでした。もしかすると自分のアプリケーションに最適な構成は別にあるのでは？と考えるきっかけになると思います！
ActionCableなら簡単? 生成 AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。
こういった方におすすめ！
近年 Web アプリケーションにおいても LLM の API を利用したサービスを提供する機会が増えていると思います。LLM の API は従来の API に比べてレスポンスタイムが非常に遅いという欠点があり、そのまま扱うにはタイムアウトを避けるために一工夫が必要です。
本セッションではストリーミングでデータを受け取り、ActionCable を利用した WebSocket 通信で UI を逐次表示することでこれを解決する方法を提案しています。実装上の注意点に加え、LLM を利用している状況ならではの CI/CD の悩みと、その解消法についても紹介されています。
LLM を活用した Web アプリケーションは、固まり切った実装のテンプレートはまだまだないように思えます。とはいえ今後こういった機能の実装を求められる機会は多くなるはず。このセッションは絶対に聞いておいてよかった！となると思います。
現実のRuby/Railsアップグレード
こういった方におすすめ！
Ruby, Rails のアップグレードはセキュリティパッチの取り込みに加え、言語やフレームワークの進化を享受するためにも可能な限り行っておきたいものです。
とはいえ現実には、テストがなく動作保証ができない、使用しているライブラリによる制約がある等の様々な理由でアップグレードが進められていないアプリケーションが多くあります。このセッションではこういった状況で実際にRails5.0からRails7.1にアップグレードした事例をもとに、そこから得られた知見を紹介しています。
アップグレードは Ruby, Rails でアプリケーションを運用するにあたっては必須ともいえるテーマですし、ここで発生する悩みの多くはどのアプリケーションでも共通するものです。必ず自分のアプリケーションにとって得られるものがあると思います！
Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？
こういった方におすすめ！
人間がテストをするときは、「エラーが出たから必須項目を埋めよう」など、視覚的な情報から得たフィードバックを次のアクションに反映させます。ただ従来のテストコードは命令を逐次的に実行するのみでそういったことはできません。これを Capybara + 生成AIで、人間が手動でE2Eテストするようにテストさせてみた、というセッションです。
これを実装できるのもすごい…！と思いますが、何よりこの着目点には驚きを隠せません。E2Eテストにおいて何か新しい試みを試してみたい！という方にとってはこのセッションからインスピレーションが得られるはず！？
おわりに
初日はセッション後に隣のホテルにて懇親会が開かれ、美味しい料理と、お酒とともにとても楽しい時間を過ごすことができました。私は現在フルリモートのエンジニアとして働いているのですが、普段会えない職場の方々とリアルでお話しできて非常に嬉しかったです。
2日目も非常にいいセッションばかりでした。そちらについては別記事にて僭越ながら紹介させて頂ければと思いますので、引き続きよろしくお願いします！
コメント