Kaigi on Rails 2023 2日目のセッションを視聴しました
Kaigi on Rails 2023 2日目にオンラインで参加しました。（1日目は仕事で参加できず...）
いくつかのセッションについて感想などを記録したいと思います。
事業の試行錯誤を支える、コードを捨てやすくしてシステムをシンプルに保つ設計と工夫
概要
スライド
感想
変化に強いWebアプリケーション開発についての発表でした。新規立ち上げ段階ではリリースした機能も不要になることが多いので、削除を前提に設計されていて、その取り組みについて関心を持ちながら発表を聞いていました。
Webアプリケーションを開発している新規立ち上げではなくても、不要と思われる機能が出てくると感じていて、その際に削除しやすい設計になっていると大変ありがたいので、新規立ち上げ段階ではなくても削除を前提に設計することは良いなと思いました。
以下、印象に残ったものです。
-
ARとテーブルは密結合しているので、１つのテーブルを使い回すのでなく用途に対してテーブルを作成する。テーブルごとファイルを削除することで、思いもよらぬ影響を避けることができる。
-
種別などを表すカラムを追加してテーブルを共有する方法は、ある種別に対して表示したいことが変わって、ロジックの分岐が多くなることが多い。特に新規立ち上げフェーズでは追加した種別が不要になることが多いので、テーブルを分けておくと捨てやすい。
-
minispecを書いて解決すべき課題や規模感を事前に把握している。捨てる判断を決めておく。
返金処理を通して学ぶ、カード決済電文の沼バトル
概要
スライド
感想
クレジットカード決済の返金処理についての話ということで、自身がクレジットカードやポイントシステムの返金処理を扱うこともあるため、興味を持って聞いていました。発表で上がっていた以下のことを考慮すると、かなり複雑な仕様で考えることが多くて大変そうだ...となりました。
- 売上・返金の到着パターンがバラバラのため、取引明細の作成が難しい
- 全額返金と一部返金が存在する
- 海外事務手数料（売上と返品にそれぞれ掛かる）
- 為替変動（内部でドルを円に変換している）
これらを踏まえて実装をするために、コードの流れを書き出す（既存のビジネスロジックを事前調査する）や電文到着全パターンを書き出すという地道な方法で対応されたそうです。私も複雑な仕様と戦う時が来たら書き出して整理を行い、地道に対応していこうと思いました。
32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方
概要
スライド
感想
いかに安全にテーブル定義変更を行うかの話で、オンラインDDLの注意点やテーブル定義変更の方法についての発表でした。
私がテーブル定義変更をする場合も発表者と同じ方法でやりそうだなと共感しながら聞くことができました。オンラインDDLについては理解が足りていないので、勉強します...!
りリースで意識したこととして、1つ1つのPRを小さくすることで、抜け漏れ・見落とし防止、レビューコスト低下、障害発生時の影響範囲や切り戻しが容易になることを言っていて、自身も普段意識していることではありますが、改めて意識しようと思いました。
また発表にあった次のフレーズが、とても良いなと思いました。
テーブルの定義変更は大変なことが多く、事故もおきがち
一方で安全にリリースするためのDBの機能や実践例は多く、過度に恐れる必要はない
Hotwire的な設計を追求して「Web紙芝居」に行き着いた話
概要
スライド
感想
Hotwire聞いたことはあるけど、どういうものかよく知らないし使ったことはないレベルだったので聞いてみました。（万葉さんはHotwireを積極的に使っているとのことです。）
Hotwireでフロントエンドを作る際には部品的アプローチと画面的アプローチ（紙芝居）が考えられて、部品的アプローチの設計は責務が分離されていて美しいが...Hotwireの相性はよくないとのことでした。その理由としては画面の制御のためにJSが増えて、RubyとJSの二重処理が増えていく。結局SPAに回帰したくなるからです。そこでWeb紙芝居の設計をするとJSが増えなくなります。つまりサーバーサイド（Ruby）で全部処理する超古典的なウェブアプリケーションになるのですが、Turboのおかげで綺麗な画面（体験の良い画面）を表示できるとのことでした。
私自身今のところHotwireを使う機会はないのですが、もし使う機会があればまた見返したい知見がまとまった発表内容でした。
また、MVPなどスピード感を重視した開発や、社内システムではHotwireで画面を作るのが良いかもと思いました。（社内システムの場合はActive Adminで充分という説もありますが）
自分の道具を自作してつくる喜びを体感しよう、Railsで。 〜4年続いたPodcastを実例に〜
概要
スライド
感想
サイドプロジェクトであるポッドキャストのためのツール開発を通じて、技術的な成長ができたという話でした。
ツール開発で運用のための知見を学んでいたり、Railsのさまざまな機能をつかって生産性高く開発を進めていたのが印象的でした。
私も砂場になるアプリケーションが欲しいと思いながらも作りたいものがなかったので、趣味のためのツールを開発するのは良いなと思いました。今はジョギングにハマっているので、ジョギング関連のツールを作りたいです...!
数十億のレコードを持つ5年目サービスの設計と障害解決
概要
スライド
感想
運用しているアプリケーションで起きた障害と解決した方法についての発表でした。
Railsのアップデートを行なったら利用していたキャッシュが引けなくなった障害についての話では、キャッシュが引けないことはRSpecで気付けないものだったので、開発環境で定期的にキャッシュを作って監視する仕組みを導入して、事前に気づけるようにしたとのことです。
お気に入りを全件表示することでスロークエリが発生して、レスポンスが帰ってこない状態になった障害の話では、お気に入りを使うユーザーの傾向をデータから分析して、お気に入りは100件表示してページネーションするという対応方法を決めているのがとても良いと思いました。
BIGINTの対応漏れによる障害では、テーブル規模が大きくマイグレーションが厳しかったので、新規テーブルを作成して乗り換える対応方法を紹介されていました。その後、auto_incrementの上限が迫っているものがないか監視する仕組みを導入していて、再発防止策をきちんと取れているのが良いなと思いました。また、auto_incrementの上限は人ごとではない気持ちになりました。
最後に
Kaigi on Railsはアーカイブ配信されているようなので、1日目や別のルームで行われていたセッションを視聴して楽しもうと思います。
運営者 & スピーカーの方々、素敵なイベントの開催ありがとうございました。
Discussion