Kaigi on Rails 2024 - Railsがまたちょっぴり好きになりました
2024年10月25-26日とKaigi on Rails 2024に参加してきました🤚
Kaigi on Rails 2024に参加してみて
最後に、を最初に書くスタイルなんですが、2日間参加できてめちゃ楽しかったです！主催の皆様、スピーカーの皆様、スポンサーの皆様、会を作ってくれた皆様、本当にお疲れ様でした！＆ありがとうございました！
子育てとかもあって勉強会とかでかいカンファレンスとかからも少し離れていたんですが、この前のTokyuRuby会議15に参加して、やっぱこういうの好きだな〜と思って、チケットが再販されたタイミングでKaigi on Rails 2024への参加を決めたんですが、マジで来てよかった・・・。
今の会社でrails new されたのが2015年で、Rails4.2とかそこら辺で、Rails tutorialを3周やるところから始まったRuby on Railsでの開発で、こんなに遠くまで来ると思ってなかったけど、今回参加してまだまだうちのアプリケーションを支えていけるな、という自信とこんなにもみんなRailsを使ってるんだ・・・！という心強さを手に入れました笑
普段の業務で活かせそうなこともたくさんあったし、普段の業務では意識しない、触れないものもあり、Railsの広さと深さを感じて、もっとRuby on Railsが好きになりました❤️
Day1
Railsの仕組みを理解してモデルを上手に育てる
- モデルを見つける、モデルを分割する良いタイミング -
Railsで長年運用してくると肥大化してくるモデルの話。イベント型モデルの見分け方、とかの話がめちゃわかる話だった。
うちだと取引をTradeモデルとして定義してやってて昔はそれでよかったんだけど、「注文の前に見積もりするよ？」とか「顧客から発注は受けたけど、社内決裁降りてないよ？」とか色々増えていった。現実世界の中で発生するイベントとそれによって変わる状態、状態で同じレコードでも呼び方や捉え方が違うなどあって、割と複雑なので、ここら辺はモデルを分割することで、誰が何の責務を担ってるか、とかをもうちょっと見通しよくしたいなーと思って聞いてました。
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
partialの中にローカル変数とインスタンス変数が混在してたり、やっぱ少し違うから同じようなファイルが生成されたり・・・とわかりみが強かった。
1800個のERBと向き合った時に、自動化すっかとなったのマジですごいと思うし、これぞエンジニアだな〜〜と思いました👏
うちも一部ViewComponentを入れる取り組みを試したことはあるので、複雑怪奇になってきたView側もうまく整理していきたい😢
現実のRuby/Railsアップグレード
ちょうどというか、今年中にRails7.0に上げるか〜という感じで進んでいるので、頷きまくりだった・・・。
結構大事なところのテストはしっかりかけてるのと、Railsのメジャーバージョンアップだとだいたい1ヶ月ぐらいdevサーバーの方で走らせてからやってるので事故ったことはほぼないんだけど、とはいえ置き去りにしてるgemとかもいるのできちんと整えていかないとな・・・と背筋が伸びました🫡
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ～俺のやらかしを越えてゆけ～
うちもデプロイのタイミングをミスると、実行中のJobとか確かに飛んでしまいそう・・・というか飛ぶわ。ちょっと見直しが必要です。ありがとうございます🙏
若かりし頃に、デプロイしてCSS全部ぶっ飛ばすとか、環境ぶっ壊す、みたいなこともやらかしたことあるので、先輩がいるところでやらかせて、なおかつそれをきちんと報告や相談できて解決していける環境良いな、と思ったので、うちにいる若い子にもそろそろ本番のデプロイをたまにはお任せしようかな（そのうちに同じようなタイトルでスライドになるかも🤔）
この日は、奥様が飲みかイベントで夜いなかったので、ここら辺で退出して、公式の懇親会も参加せずでした🙏
Day2
都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」
単純な理論値というよりかは、Webのリクエストに合わせてIOとCPUの割合調整してテストしたりするの、めちゃ実践〜〜〜って感じでよかった。
CPUとIOとGVL waitとか意識してなかったので、ちょっと隙間ができたら計測してThread数の調整をしてみます🙏
「それでも Ruby と生きていきたい」は刺さりますね。
推し活の ハイトラフィックに立ち向かう Railsとアーキテクチャ
うちのも在庫管理系の機能があって、Orderが確定したら在庫数から引く、というをやってるんだけど、これ見積もり段階で在庫を確保するけど、出庫はされてない、みたいなのとかを将来的にやらないといけないだろうし、そうなると数字の足し引きだけじゃできないんだろうな〜と思ってたので、SKUのその先の1つずつ分けるよって話は超納得でした。
ちなみに、在庫の数字の管理は数年前のKaigi on RailsのSmartHRさんの発表であったBi-temporal Data modelを参考に作ってます、ありがとうございます🙏
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
ちょっと前までFlakyなテストが結構あって解消したけど、まだ解消しきれてない、かつ12000ケースぐらいあって並列10台で10分以上かかってるので、めちゃ聞きたいやつでした。
test-prof は入れてないので、ぜひ今度調査したいし、before_allとか結構効きそう。let_it_beは使えるところと使えないところありそうなので、要確認っぽい。
分割は、うちはtimingで適度に分割してて、そこまで実行時間に偏りはないかな、という感じなので、後回しになりそう。
ごく稀に落ちるテストで特定の時間を跨ぐ時だけ落ちるテストとかあるので、なかなか発見するのむずいよなぁ・・・うちだと、アジアとかアフリカのtimezoneを設定した上でデータ作ったりとかしつつ、dailyの集計のモジュールのテストとかしたりすると、ごく稀に・・・というのがあったりした（気がする）。
全体的にやるぞ！という気合いがめちゃ感じられるし、テスト周りにしっかり時間取れる組織もすごいなと思いました👏
Hotwire光の道とStimulus
HotwireとStimulus周りは、いつかうちにも取り込んで今のものをリプレースしていきたいんだけど、工数と売上に貢献するんかい！というところでなかなか取り組めてないんだけど、大場さんのHotwireのお話はワクワクしちゃうので、どうにか個人のプロダクトか何かにでも導入したり触って、感覚をつけておきたいな、と思いました🙏
Data Migration on Rails
うちは
2. rails conosle
3. db:migrate と同時に実行
4. rake task
という感じで data migration をしていて、特にそこに何の疑問も持ってなかったので、すごく良い機会でした！めちゃ参考にしたいけど、まだ飲み込みきれてないけど、ぜひうちにも導入してきちんとデフォルトにしたいな〜と思ってるので、もうちょっと時間かけて読んで検討してみます！
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
この話、ずっと愛の話を聞いてる感じでほんわかしました。
僕らが使ってるのはRubyでありRailsであり、設計手法やデータモデリングや色々あるけど、そのすぐ外にはそれを使う人がいて、業務や現象があって現実世界が広がっていて、さらにその中に僕らエンジニアもいるんだよな、という感じがして、それぞれが少しずつ変わっていく中で、誰がどう適応するか、僕らが手を入れる必要があるシステムはどう適応させてあげるか、ということなんよね。
僕は、技術の変化にはよりも、使ってるユーザーとかその先にあるビジネスの中にある「システムの立ち位置とその働き」に興味関心が強くて、そのための技術どうしますか、という感じで立ち戻ってくるので、ここら辺は意図的に技術の話は取り込んでいかないとな、と思いました。とはいえ、Rails書くのは大好きなので、これからも楽しくRailsを書いていきたいです :)