2024年10月、Kaigi on Rails 2024に参加しました 🎉 初現地参加 🎉
はじめに
スタッフの皆さん、登壇者の皆さん、参加者の皆さん、チケットやその他諸々を支援いただいた会社にBig Thankです 🙌 お弁当やもくもく部屋、とってもありがたかったです！ 素敵な時間・体験をありがとうございました 🎉
カンファレンス
当日まで
Okinawa.rb
Kaigi on Railsの前月にOkinawa.rbのミートアップを開催しました🌴 Kaigi on Railsの予習も兼ねて、Rubyに関する話をしたり、どんなトークに興味があるのか共有できたのがよかったです 🙌
Okinawa.rbの開催でKaigi on Railsへのモチベーションも一層高まりました！
CFP
今回のKaigi on Railsではプロポーザルの提出もしましたが、残念ながら登壇叶わずでした 😭 しかし、初めてLT以外の形式でプロポーザルを出すことができ、とても良い経験になりました。 プロポーザルを作成する過程でも多くの学びがありました。発表内容をどう伝えるかを考えたり、どう整理するかを工夫したりする中で、自身の理解が浅い部分を含め様々な気づきを得ることができました。
今回のプロポーザル作成にあたっては、社内でたくさんのアドバイスをもらいました。Big Thanksです 🙌
また別の機会に発表できるチャンスがあればと思っています。その時には、今回の経験を活かして良い形でお届けできるように頑張ります 💪
Day1
基調講演
いくつかのプロダクトでさまざまなコード見てきましたが、どんな状況でも「Rails Way」をできる限り意識して進めていきたいと改めて感じました。 特に、Railsの抽象化をアーキテクチャレイヤーと照らし合わせながら進めていくことでよりよい設計になると感じています。 Railsの強みは活かしつつ、アーキテクチャレイヤーとの整合性を意識して設計していくことを、より良いプロダクトを作るための指針としてきたいです。
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
やっぱりPOROはいいですよね〜と改めて。 また、イベント型モデルで「〜する」という命名を使うことで、そのモデルの意図が明確になり、理解しやすくなったのが嬉しかったです。
Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜
トークの中でも言及がありましたが、Rails紙芝居が存分に活かされた内容でした。 フロントエンド(React)とHotwireの違いや使い所が、ハマった実例と併せて紹介されてるのがとてもわかりやすく参考になりました。
Day2
約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり
Flakyテストどうしても出ちゃいますよね... 自分も直近で書いてしまっていたので耳が痛かったです。 そういったFlakyテストをどのように減らすのか、また、実行時間の長いテストをどのように短くしていくのか知れてよかったです。 (実行時間が長いCIがFlakyで落ちて再実行するの辛い...)
Hotwire光の道とStimulus
Turboはあくまで結果の描画を担当する役割だと認識しておくことで、余計な状態管理まで任せたりすることなく設計していけるのかと思いました。 Stimulusもやたらめったら使えばいいものではないと再認識できました。 StimulusとTurbo・Railsとの棲み分けを意識して設計を進めていくことでHotwireを使いこなしていきたいです。
基調講演
Day1の基調講演からのつながりが心地よかったです。Day2最後の発表にも関わらず、会場全体が前のめりになっているのを感じました。 「概念圧縮」という言葉を初めて知ったのですが、普段考えていることを一つの概念として捉えられるようになりかなり楽になりました。
おわりに
現地参加できて本当に良かったです！ 紹介されていた書籍やコードベースを読んで、もっとスキルアップしていこう！という気持ちでいっぱいです。 次こそはプロポーザル通すぞ...！
(余談) 全然写真撮ってなかった… カンファレンスでトーク聞いたり、お話したり、思いついた実装するのに夢中で毎回忘れちゃうんですよね〜...
あと沖縄からの当日入りは体バキバキになるのでできるだけ避けましょう(未来の自分へ)
