はじめに
2023/10/27-10/28に開催された Kaigi on Railsに参加しました。
kaigionrails.org
Ruby関連のカンファに参加するのは今年の松本でのRuby Kaigiに引き続き2度目です。
前回のRuby Kaigiでは弊社のブース担当として参加していましたが、
今回はブースのお仕事がないので発表を聞くのに専念できる・・・！ということで、ワクワクしながら参加してきました。
Voice Pocochaブース出してます！
— やや (@yayamochi) 2023年5月12日
顔出しなしのライブ配信、ということでアイマスク配ってます🙌#rubykaigi pic.twitter.com/6rc1c4HaO7
発表
自分が特に印象に残っている発表は以下の2つです。
やさしいActiveRecordのDB接続のしくみ
私が業務でConnectionPool周りにパッチを当てている部分を修正する機会(※)があり、内部実装を見にいった経験がありました。
当時、内部の仕組みを理解するのが複雑で苦戦していたので、非常に楽しみにしていた発表です。
登壇者の方はrdbgでブレークポイントを貼り、DB接続に関しての主要なクラスをあぶり出し、図解で説明してくださいました。
自分で実装を追っていった際に概要を掴むまでにしばらく時間がかかっていたのですが、本当ににこの発表がわかりやすく業務で担当する前に見ておきたかったです。笑
※自分が業務で触った内容は、AWS AuroraのFailover時にConnectionPoolで古い接続を取ってきてしまう影響でDB接続できなくなる不具合の解消のために上記の実装を追ってました。
下記の記事でも紹介のある、mysql2-auroraというgemを使うことで解決しています。(上記の接続ができないときのエラーメッセージをハンドリングして再接続するgem)
qiita.com
32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方
オンラインDDLの対象操作を整理・挙動の注意点を説明し、実際のアプリケーションのデプロイフローなどを考慮すると
カラム追加 → 値の同期 → バックフィル → Not Null制約 …(略)… → カラムの削除
のように丁寧に一個ずつ手順を踏んでリリースしていくしかないね、というお話です。
最後にあった「モデルの拡張性・柔軟性について」の話はとても共感しました。
「将来的にはこうなりそう」と予想して不確実なものを設計に組み込むよりも、今ある情報で確実に設計していくべき。
テーブル変更定義は大変で危険だが、安全にリリースするためのDBの機能や実践例はたくさんあるし、それらを学んで行き、その技術を身に着けておくことが大事。
私自身、業務での新規機能開発の頻度は高く、テーブル設計の際には、企画者に対して「将来こういった機能の実装予定はありますか！？」という質問を投げかけて困らせがちだったり、機能を拡張する際にテーブル設計がしんどくて実装が辛くなったりすることも経験として多くありますが、上記思想は大事にしていきたいし、勉強していきたい。
補足
当日の発表については下記のブログに掲載されていました🙌
qiita.com
まとめ
今回Kaigi on Railsに参加してみて、自分の興味軸としては、フレームワークのRailsがどうこう、っていう話ももちろん面白いけど、そもそもの根本のテーブル設計やDBあたりの話に結構向いているかも？と思って聞いてました。
また、学生時代にインターン先でお世話になった方や、前回のRuby Kaigiで知り合った方とも再会でき、とても嬉しかったです。
ほんとこれです。
カンファレンスの参加回数を重ねるごとに知り合いが増えて、「お久しぶりです！」って言えるのが嬉しい#kaigionrails
— 井上 周/ INOUE Amane (@isaka1022) 2023年10月27日
自分はこれからもRubyにお世話になることが増えていきそうな予感だし、自分もアウトプット出していきたい。
