Kaigi on Rails 2024に参加した感想
はじめに
Inner Resource(以下、弊社)からはエンジニア4名がKaigi on Rails 2024に参加しました。
登壇者でもスポンサーでもないのに4名も参加させてもらったのは本当に感謝です。
著者自身はRails歴7年ほどですがKaigi on Railsには初参加だったため、感想なども交えながらKaigi on Rails 2024を振り返ってみたいと思います。
Day1
基調講演 Rails Way, or the highway
個人的には今回のセッションの中で一番印象に残った。
弊社でもMVC以外にService層が所々存在してしまっているため、設計を見直す良い機会にしたいと思います。
基調講演の中でも紹介されていた「Layered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications」は早速kindle版を買ってみたので頑張って読破したいと思います。
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
こちらも基調講演と同じくモデル分割のお話。
FormモデルやPOROは意識して書けるようになっていきたい。
そのカラム追加、ちょっと待って!カラム追加で増えるActiveRecordのメモリサイズ、イメージできますか?
CRubyの実装まで踏み込んだことはなかったのでとても参考になった。
Integerのカラムを1カラム増やした場合に増えるメモリサイズは224バイトだそうですが、個人的には予想より多かった。メモリサイズまで意識して実装していきたい。
cXML という電子商取引のトランザクションを支えるプロトコルと向きあっている話
偶然ですが業務でcXMLの実装をちょうど行っていたため、とても参考になりました。
リリースした後に問題が起きないように、セッションの内容も参考に設計やテストや丁寧に行いたいと思います。
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
ViewComponentは初見でしたが、erbよりも性能が良いというのはどういう理屈なんでしょう。
View helperとの棲み分けなども気になるので、個人的にはもう少し深掘りしてみたいセッション内容でした。
ActionCableなら簡単? 生成 AIの応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。
まだ本番でLLMやActionCableを使った実装経験がないので、LM StudioやVCRを用いたテスト手法などはとても勉強になりました。
Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
弊社ではRailsのフロントはslimもしくはReactという形で実装しています。
Hotwireの今後の動向などにも注視しながら、Slim内で一部JQueryを使っている部分をTurboに置き換えるなどは有りかも知れません。
とはいえ、セッション内でも「CRUDなし+JS」はReactが良いという結論になっていたため、いまいち使い所が難しいという印象。
Day2
Data Migration on Rails
データ修正などのデータマイグレーション手法にRails Wayがないというお話。
セッション内で紹介されていたmigration_tasksは初見だったので試してみたいと思いました。
omakaseしないためのrubocop.yml のつくりかた
9ヶ月にわたってチーム内でrubocop.ymlの作り上げたお話。
会社の輪読会で「良いコード/悪いコードで学ぶ設計入門-―保守しやすい-成長し続けるコードの書き方」をちょうど読んでいることもあり、輪読会が終わった後に社内のコーディング規約やLinterの設定も決めていきたいと思いました。
おわりに
この記事ではKaigi on Rails 2024に参加した感想などを振り返ってみました。
Kaigi on Railsが終わった後に社内で感想戦もやりましたが、みんな満足度が高かったように思いました。
サービスのリファクタリングやRailsへのモチベーションを向上させる良い機会になり、初参加でしたが参加して良かったです。
Discussion