コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『Kaigi on Rails 2023』の二日目に行ってきたよメモ

行ってきたメモ Rails

『Kaigi on Rails 2023』の2日目に参加してきたので見たセッションメモ ちなみに1日目はこちら

各発表の感想

※資料スライドは見つけたら貼ります。

Railsの型ファイル自動生成における課題と解決

speakerdeck.com

感想

  • Railsアプリケーションに段階的にRBSを導入していくアプローチに関しての紹介。 怪しいセミナーではない。
  • orthoses (読み：オーサーシーズ) とその関連gemで解決していくアプローチ
  • もともとRailsの備えているものに関しては自動でカバーできる範囲が多いが、自前のアプリケーションに関してのアプローチも考えらえており、RBSの基礎を叩き込んだあとにいざ導入！というときに見直したい資料でした。
  • rubocop-yard はチーム内のYARD矯正ギブスとしても使えそうだし、明日から導入したいgemだった。

関連リンク

Fat Modelを解消するためのCQRSアーキテクチャ

感想

  • ReadとWriteの分離をするCQRSの考え方ををRailsアプリケーションに持ち込んだ話。
    • CQRSというとイベントソーシングも合わせて語られることが多いが今回はイベントソーシングではない事例だった
  • Commandが出来上がってもCommandを叩くControllerがFatになりがちだが、そこをUseCase層を持ち込むことで、純粋なRDBの処理部分を逃がせたのはなるほどなと思った。
  • APIなら割とやりやすい方向性だが、通常のWebページのactionの場合はどうするのかなというのは気になった。
  • ルールに沿わないコードを検知し辛いので、チームへの浸透とワンセットの考え方と感じたが、その点どうやて活動しているのかも合わせて気になった

関連リンク

32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方

感想

  • 無停止でいかにカラムの変更を行うかの話
  • かなり雰囲気でMySQLを使っているフシがあるので、こうやって事前調査を入念にやるということは大事だなと改めて感じる。事前にオンラインDDLになるかどうかのチェックができるノウハウは良い知見だった。
  • RailsReleaseにおける db:migrate と Railsソースの更新タイミングの問題はどこでもつきまとう問題だなと聞いていた。
  • 今回の事例はinsertオンリーのテーブルの事例だったので愚直にやれば課題感がなかったけれど、updateを伴うカラムのほうはもっと大変だろうなと感じる

関連リンク

テーブル分割で実現するdeviseの責務の分離と柔軟な削除機構

speakerdeck.com

感想

  • Deviceをうまく扱うためのテーブルの分割方法のお話
  • 削除の考えかたに関してもActiveなものを表現するテーブルとして作るという考え方
  • Userというドメインをちゃんと分解して取り扱わないとしくじるので、そーだいさんの事例を思い出すなどしました。

関連リンク

管理機能アーキテクチャパターンの考察と実践

感想

  • 管理機能をどう構築すべきかという引いた目線での話
  • 過去経験上刺さる部分が多く、かなり共感できる部分も多かったので、何かアーキテクチャの検討に入ったときにはスッと出したくなる資料
  • エンドユーザ向けが現状どうあるかと対比して選ぶパターンを紹介していたのもよかったです。
  • この資料のすごいところは発表内容もさることながら、参考資料のデータが非常にバラエティに富んでいたのでよかったです

関連リンク

自分の道具を自作してつくる喜びを体感しよう、Railsで。 〜4年続いたPodcastを実例に〜

感想

  • Podcastを通じて自分の道具になるツールをつくっていく話
  • ステップアップの過程がよかったのと、単発サービスと継続できるものの差が勝たれていてよかった
  • サイドプロジェクトを使って好循環を生み出すのは本当にいいなと思った

関連リンク

ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜

感想

  • ソロプロにおける課題感と、それをペアプロで解消する方法やペアプロ時の問題に対しての解決アプローチの話。
  • ペアプロのやり方はよく聞くが、実践した場合の難しさの知見があったのがよかった
    • ドライバーをタイピストと言い換えるのは単純ながら効果はありそうだった
  • ライブコーディングを見ながら、良いなと思ったポイントは以下
    • issue着手前にissue内容の点検をタイピストが司会進行となって、疑問点がないかを確認する
    • issueからすぐにコードの変更に取り掛かるのではなく、タスクリスト的に作業順番を明文化して実施する
    • ナビゲーターが沈黙モードに入ったらタイピストが声掛けをする
    • 全体的に相槌と確認をこまめに挟みながら進める
  • 前半のissueの確認に関してはプロダクトバックログからスプリントバックログに起こす過程に似ているなと思いながら見ていました。

関連リンク

ActiveSupport::CurrentAttributes: すっごく便利なのに嫌われ者？！

スライドは見つけたら貼ります

感想

  • ActiveSupport::CurrentAttributesの紹介と使い方の話
  • なんで必要となったんだっけ？という背景も含めて説明があったのでタメになった。
  • 要するにグローバル変数なので、グローバル変数に関する所々の問題がはらんでいるし、Rails特有の問題もあるので使うときはその点気にしながら利用しましょう。

関連リンク

コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話

感想

  • コードカバレッジの話とそれをどうやって改善に組み込んだかという話
  • 条件網羅について語られることがないので、ここで語られたのはよかった
  • 前回の登壇で実はこのあたりまで喋りたかったので、こういう話どっかでできればなーとは思っています

関連リンク

A Decade of Rails Bug Fixes

感想

  • ふたつのBugfixのエピソードからどうやってデバッグをしていったという話。
  • ひとつめはRailsのカウンターキャッシュの話
    • 社内で問題になっているところを起点に、調査を進めて、手元で再現するものを見つけ出してPRを出していったエピソード
    • ここではバグの修正PRだけではなく、バグの対しての再現方法やそのバグがなぜ困るかのコンテキストを含めてちゃんと伝えることの大切さに触れられるエピソードだった。
  • もうひとつはMastodonの修正の話
    • Mastodonのバグに関しての話を目にし、最初は安易なバグだろうと思って取り掛かっていったら根が深いことだったという話
    • こちらは自分自身がバグで困っている当事者ではないケースだったので、バグ報告には意義があるということや仮説が立てにくいなかどうやってバグ修正を進めていくかということに触れたエピソードだった。
  • どちらの話もRubyやRailsというOSSを使っている際に少しの報告が誰かの一助になるんだろうなということを考えさせられるエピソードだった

関連リンク

2日間を通しての感想

  • 会場としては大きなホールと、小さな会議室、加えて十分な量の休憩スペースなどもあり過ごしやすい空間になっていてよかったです。
  • Railsを使った仕事の話、Railsにまつわる技術の話、Railsを使ってよかったことの話、さまざまなRailsの話があり去年以上にバラエティに富んでいたと思いました。
  • 複数トラックあったので聞きたかったなというトラックもあったんですが、アーカイブを即日見れるのはすごい助かりました。
  • 懇親会でも色々話させて頂いて楽しかったです、来年はスピーカーとして出れるように精進します。。
    • ちなみにどの日本酒もめっちゃ美味しかったです。 （下記は別の方のツイート）