Kaigi on Rails 不参加記 Part1

Kaigi on Rails 不参加記とは

Kaigi on Railsには参加してないけど最近Rails周りなんもキャッチアップしてないと焦っている人間による、公開されている資料を見ての適当な感想を書く記事です。
運営の方々、発表者の方々、資料まとめてくださっている@hassanさん、その他皆々様ありがとうございます！！！！！！！

資料ごとの感想

スケーラブルActive Jobs with Sidekiq Enterprise (Kaigi on Rails 2023 Day 1 スポンサーLT2)

  • 非同期処理をマネージするプロセスって終了する時がむずいよね…むずいと思ってるだけで僕がなにかしたことあるわけじゃないんだけどね…。
  • 時間がかかる非同期処理を高頻度で実行しているプロダクトってデプロイとかどうしてるんだろう？
  • クラウドとかDocker周りでシグナルがいい感じに送れないみたいな問題をみたことがある。

BulletmarkRepairer: auto corrector for N+1 queries

  • まず作ってるGemがすごい〜知恵の結晶だ。
  • includesどこに書くか問題だけど、N+1が問題になるのってだいたいview周りなので、コントローラに書くなぁ。
    • モデルに書く時ってasoociationコレクションを全部みてなにか判定する時とか？（特異メソッドにはありそう）
  • メモリを気にするほどの環境にいたことがないので大体includes呼んじゃいますね…。多分今の社だとちゃんと考えたほうが良い。
  • 大量のデータを返す公開APIとかはちゃんと意識してpreloadとeager_loadを使い分けたい。
  • 発行されるSQLの変化を確認して、自分の知らない隠された仕様がないか確認する。
    • これちゃんとやってる人すごいよなぁ。かくありたい。

HTTPを手で書いて学ぶ ファイルアップロードの仕組み - Speaker Deck

  • 実際に検証しててすごい。
  • ブラウザってすごいよね。
  • Railsってどこでmultipart/form-dataをパースしてるんだろう？
    • Rackの諸々使ってるのかな
    • テストまでみて探索をやめた。

生きた Rails アプリケーションへの Delegated Types の導入 (Kaigi on Rails 2023)

  • 基本的にSTIするくらいならポリモーフィック関連を作って共通した振る舞いは(別モデル ≒ 別テーブル)に切り出しがち。

    class Smartphone < ApplicationRecord
  belongs_to :smartphonable, polymorphic: true
end

class Pixel < ApplicationRecord
  has_one :smartphone, as: :smartphonable
end

class IPhone < ApplicationRecord
  has_one :smartphone, as: :smartphonable
end

  • delegated_typeってこの関連に、色々便利メソッド（#iphone?的なクラス判定とか）を追加してくれているだけであってるよね？

  • この構造はよく使うので、共通認識として名前がついて便利メソッドがついてくるのは良さそう。

  • この資料のすごいところは実際に運用中のサービスの構造を変化する過程まで書いてくれていること。

  • あとdeploy_history_basesのPKをそのままecs_deploy_historiesやlambda_deploy_historiesのPKに使っているの良さそう。

    • 僕だったらdeploy_history_bases.deploy_historyable_idみたいなカラム作っちゃうと思う。余計なカラム一つ減らせて良さそう。
    • RailsのAPIドキュメントだと現状deploy_history_bases.deploy_historyable_id的なカラムを作ることを想定してそう。
      • どっちも突き詰めたら違うメリットあるのかも。

Asynchronous Ruby With Fiber And Async

  • Thread
    • GILがあるもののIO待ちが多い処理では並行処理の効率は良さそう。（IO待ちの間に他のスレッドが動いているのは並列処理と呼んでいいのだろうか?）
  • Fiber
    • ユーザーレベルスレッドってやつだよね？Elixirで言うところのプロセス、Goで言うところのゴルーチンみたいなやつ。グリーンスレッドって呼ばれたりもするやつ。
  • PumaもIO.selectつかってた気がする。Reactorパターンというやつらしい。
  • 上のpumaのやつもそうだけどスケジューリング的なコードは確かに複雑になりがち。
  • 正直AsyncGem仕組みは全然わからん
  • Trilogyってたまに聞くけどMySQLのクライアントライブラリなんすね。
    • 名前カッコ良すぎる。
  • とりあえずThreadもFiberもRactorも全然わからん…
    • 昔、Ractorを使おうとしたことがあったけど、定数周りとかちゃんとRactorセーフ？にしないと行けないので大変だった記憶がある。
    • その時にRactorとFaradayで検索してたら面白いアプローチしているGem見つけたので貼っておきます。
      • https://github.com/dazuma/ractor-wrapper
      • Ractor間で共有できないオブジェクトをRactorでラップして共有するぞというやつ。
      • 既存のGemをRactor対応させるのに使えそう。
    • 脱線してしまった。

Exceptional Rails

  • 僕が勝手に師匠だと思っている人は言いました。バックエンドが例外処理を丁寧にやることがユーザー体験につながると。
    • はい。
  • 起きうるエラーを考えて適切にエラーコードなりメッセージを出したい所さん。
  • コントローラ内の例外、rescure_fromで拾ったりアクション内でresuceしたり色々カオスになりがち。
  • ErrorReporter初めて知りました！神機能！！！！
  • rackミドルウェアになにもかも任せてぇ…

やさしいActiveRecordのDB接続のしくみ

  • コネクションプールの中でアダプターオブジェクトつくってるんですね。
    • アダプターオブジェクトがコネクションプールを持ってるイメージだった。
  • 私的には最後の知見の言語化がすごい資料だと思った。
    • 解明した事実を役立ちそうな知見にまで言語化しててすごい。

まとめ

Kaigi on Railsの資料はどれも日々の業務に活かせるものばかりで参考になりますね。 当たり前だけど、RubyKaigiはRubyってスゲー！ってなるのが多くて、Kaigi on RailsはRails開発ってスゲー！ってなるのが多い。
今回はここまで！多分part2も書きます！次回は絶対参加するぞ！