Kaigi on Rails2023に参加してきました
2023/10/27（金）と10/28（土）に開催された「Kaigi on Rails 2023」に参加してきたので、その内容と学んだことを共有します。
Kaigi on Railsとは
Ruby on Railsに限らず、Web開発に関する技術イベントで、初学者も対象になっています。
コンセプトは以下です。
Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています。
Railsと私
Ruby on Rails歴1年未満の初学者（開発経験も1年未満）で、今は社内SEとして開発、運用しています。
今は、Ruby以外にE2Eテスト自動化をやっていたこともあり、Pythonも触っていました。
ソフトウェアテスト系のイベントはいろいろ参加していましたが、今回のような開発系のイベントは初めてでした。
聴講したセッションの概要と所感
私が実際に聴講したセッションの概要と所感を共有します。
1日目
基調講演 準備中
【講演メモ】
zakkさんがRailsと歩んできたこと共有しながら、OSSに貢献するメリットやRailsをより理解する方法などを共有していただきました。
OSSのドキュメント修正ははじめの一歩としてよい
zakkさんはRailsガイドの修正を行った
rubocop-mdやmarkdownlintなどを使う
Railsを理解するためにはRuby on Rails BlogやTechRacho、プルリク、動画等を眺めるとよい
プルリクではバグレポートの書き方やバグの特定の仕方なども勉強になる
【所感】
Ruby on Railsについて、より理解を深めるにはRuby on Railsに直接貢献することが一番良いということとまだまだ自分は知らないんだなと感じるセッションでした。
HTTPリクエストを手で書いて学ぶ ファイルアップロードの仕組み
【講演メモ】
サンプルを動かしながら、ファイルアップロードで使われるHTTPリクエストの仕組みついて説明していただきました。
アップロードするファイルをいろいろあるが、結局はバイナリファイルであり、処理フローも同じである
ファイル送付をするときはHTTPリクエスト（POST or PUT）を使用する
送付時はバイナリを直接埋め込むかエンコードでテキストベースに変換して送付する
【所感】
自分もなんとなくPOSTで送付したり、application/JSONで指定していたりしていたなと感じていたため、今回のセッションはとても勉強になりました。
また、サンプルを作ることで理解が深まる（例示は理解の試金石）という部分は非常に共感しました。
生きた Rails アプリケーションへの delegated types の導入
【講演メモ】
あるテーブルを共通テーブルと固有テーブルに分ける時に使用するDelegated Typesについて、説明していただきました。
Delegated TypesはSTIの代替として使える仕組みであり、Rails6.1から導入されている
ポリモーフィック関連で共通テーブルと紐づけることができ、横長いテーブルやNULLが多く生まれるテーブルを避けられる
ただし共通テーブルに外部キー制約ができなくなるため、注意が必要
移行する際はRails Consoleで小さく試すのがポイント
【所感】
Delegated TypesやSTIについては知らなかったため、非常に勉強になりました。
データ周りの変更は注意深くやらないといけないのだなと改めて感じることができました。
Exceptional Rails
【講演メモ】
Railsにおける例外処理の付き合い方について、説明していただきました。
例外は必要なもの（異常系および準正常系）だけ、発生させるべきである
例外が入るとフローが複雑になるため
例外処理は遅くなる傾向がある（ベンチマーク結果では10倍以上も差があった）
例外をどのようにresucueするか
例外を発生させるケースは上位にresucueを置くことでコードがすっきりする
それ以外は早めにresucueを用意する
例外をどのように開発者に通知するか
不具合を特定しやすくするため、内容は具体的にし、begin~resucueの範囲も狭くすること
エラーページをユーザにどう表示するのか
汎用的なものはRack等のミドルウェアに任せた方が良い
静的なページを推奨
【所感】
例外処理について、そこまで深く考えられていなかったなと感じるセッションでした。
とくに例外処理の書き方については現場業務でも活かせる内容だと思うため、早速改善したいと思います。
初めてのパフォーマンス改善〜君たちはどう計測す(はか)るか〜
【講演メモ】
パフォーマンス（アプリケーションの応答速度）改善の流れと学んだことを共有していただきました。
パフォーマンス改善の流れ
調査
優先順位付け
本格調査、改善
経過観察
パフォーマンス改善作業のポイント
調査では深追いしすぎず、原因っぽい所までで止めること
優先順位付けは開発者目線、PO目線などさまざまな目線から優先順位を考えること
本格調査時は調査したことはまとめておくこと
原因を推測したら、必ず計測すること
本番環境でしか起きない要因があるため、パフォーマンスが劣化しても落ち込まず、次に活かすこと
【所感】
パフォーマンスまわりはもっと学習したいと思っていたため、とても勉強になりました。
調査するときに深追いしすぎる癖はあるなと感じているため、優先順位を決めるということは意識してやっていきたいと思います。
Simplicity on Rails - RDB, REST and Ruby
【講演メモ】
Railsをよりシンプルにするためのプラクティスを共有していただきました
※ここでいうシンプルはサービスでやりたいことと、記述するコードの差が少ない状態を指します。
Railsのシンプルな設計≒Scaffold
DB設計ではイベントエンティティを見出すこと
スキルとユーザーには登録するという動作があるので、registration等を付ける
リソースをhas_many throughでつなぐこと
昔はhas_and_belongs_to_manyだったけど今はこっち
イベントをRESTのリソースとして捉えること
例）ログイン
ログイン画面：new
ログインする：create
ログアウトする：destroy
不要なRESTは使わなければ良い、必要になったら使う
登録確認画面など
コトをCRUDするとき、UIとイベントエンティティの構造がちがっている場合、Rubyを使ってActive RecordやActive Modelで柔軟に開発すること
【所感】
DB設計が課題だなと思っていため、とても勉強になりました。
また、紹介していただいたAMoも全然知らなかったのでもっと学習したいなと思った。
Turbolinksアレルギー患者に捧げるTurbo & Stimulusでの時短実装術
【講演メモ】
Hotwireは悪い奴じゃない（Turbolinksとは違うよ）よというお話でした。
HotwireはサーバーからJSONではなく、HTMLを渡すものであり、JSをあまり使わなくてすむ
ただし、複雑なJS処理などは行えないため、アプリの用途や処理から判断すべき
iOS14では公式な記法で動かない
ReactやNext.jsみたいに複雑な処理は記載できない
【所感】
Hotwireについて、あまり良いイメージを持っていなかったため、今回のセッションで印象は良くなりました。
試せる場があれば、導入してみようかなと思います。
2日目
事業の試行錯誤を支えるコードを捨てやすくして、シンプルなシステムの設計と工夫
【講演メモ】
事例を紹介しながら、Railsでスピード感のある開発を進めるためのポイントを共有していただきました。
新規事業に求められるソフトウェアの特性の1つに直ぐに変更に対応できることがある
不要な機能を残したままだと、逆にユーザーからの満足度が下がってしまう
コードや機能を捨てやすくし、システムをシンプルに保つ方法
削除することを前提に開発することで、コードや機能を捨てやすくする
用途ごとにテーブルを作る（小売企業ユーザーとメーカーユーザーのテーブルを分ける、データ集計）
機能を捨てやすくするために、運用も工夫が必要
Feature Flag（段階的に公開する）
mini spec（捨てる基準を決める）
利用状況を把握（ログとDBから定性・定量的に分析する）
【所感】
私も社内アプリを作っていて、利用状況がわからないため、「ほんとに使われているのかな。。」と思っていることがあったため、やはりログとDBを活用した分析が必要なんだなと感じました。
また、mini specは今の業務でも活用したいと思いました。
Fat Modelを解消するためのCQRSアーキテクチャ
【講演メモ】
サンプルコードを交えながら、CQRS（Command Query Responsibility Segregation）アーキテクチャの紹介をしていただきました。
CQRSアーキテクチャは更新と参照の責務を分離するアーキテクチャ
ControllerからCommandもしくはQueryを呼び出して、Modelのデータを参照/更新を行う
株式会社YOUTRUSTでは更新の前にUseCaseを作っている
メリット
ModelやControllerの肥大化を防ぎ、可読性やメンテナンス性を向上することができる
データソースの分割がより簡単になる
単体テストが書きやすくなる
【所感】
とても勉強になるセッションでした。
CQRSアーキテクチャにDDD要素を付け加えたものと理解しました。
確かにテストは書きやすくなるだろうし、肥大化しないなと思ったため、試して作ってみたいなと思いました。
E2E testing on Rails 2023
【講演メモ】
実演を交えながら、Node.jsベースのテストランナーを活用するためのプラクティスを共有していただきました。
RailsのデフォルトではCapybara + Seleniumでシステムテストを実装するがお世辞にも開発体験がよいとは言えない
世の中の流れはNode.jsベースにのテストランナーなってきた（PlaywrightやCypress）
Rackミドルウェアでエンドポイントを指定すると、Node.jsベースのテストランナーでシステムテストを実装することができる
cypress-railsやsimple_stubを活用
CapybaraでPlaywrightが使えるようにgemを開発中
【所感】
個人的にはCapybaraの動作やPlaywrightの仕組みを知れてとても勉強になりました。
システムテストの解剖学もみてみたいと思います。
gem deviseのusersテーブルの分割による拡張性、安全性の向上
【講演メモ】
いろんな責務が入ってしまうUsersテーブルの分割方法について、共有していただきました。
Deviseは認証機能を簡単に作成でき、またさまざまオプションを追加できるものだが、その分Usersテーブルに多くカラムを追加してしまう
認証に必要なものだけを別テーブルに分割すると、Usersテーブルがすっきりする
ユーザー情報を削除する時、過去の履歴の削除有無やユーザー復元などを考慮する必要がある
Usersの状態（退会済み、ロック中）を別テーブルで管理することで、柔軟に対応できる
【所感】
テーブル分割の方法というところは、今注力しているところなのでとても勉強になりました。
ただテーブルが多くなると、実装周りの工夫も必要になるのかなと思ったので、そこはどのようにしているか気になりました。
管理機能アーキテクチャパターンの考察と実践
【講演メモ】
管理機能を題材にして、アーキテクチャ（フロントエンドとバックエンドのソースコード構成）を選択するときのポイントを共有していただきました。
アーキテクチャの定義は一意的な定義は存在しない
アーキテクチャの選択に正解はないため、以下を考慮して選択する必要がある
どんなことを実現したいのか
実現する機能の特性
選択肢ごとのトレードオフ（メリデメ）
対象のドメイン
【所感】
アーキテクチャと言われて、ふわふわっとしたイメージしかなかったため、今回のセッションでアーキテクチャについての理解が進みました。
アーキテクチャ設計はいろいろ考えることが合って、面白そうだなと思いました。
数十億のレコードを持つ5年目サービスの設計と障害解決
【講演メモ】
過去の失敗事例（障害）から、学んだことやアンチパターンについて共有していただきました。
キャッシュ起因のバグは発生しやすいため、事前に検知できる監視体制が必要
開発環境ではアクセスが少なく、キャッシュが溜まりにくい特性があるため、見つかりにくい
キャッシュ容量を確認できる仕組みやキャッシュの読み込みが行えるテスト等を用意するべき
実際の利用状況を確認して、ムダに多いデータ通信を行わないようにすること
履歴系周りのテーブルでは、bigint型を用いること
データ型の数値範囲オーバーを事前に検知する監視体制を整えること
運用中のテーブルでALTER TABLE出来ない場合は、RENAME TABLEで代用できる
余裕があれば、テーブルのカラムを再検討すること
【所感】
自分が開発しているwebシステムはそこまで大規模なアプリではないため、紹介していただいた事例は起きていませんでしたが、見落としていた部分が見つかったので、良い気づきになりました。
こういう運用パターンを教えていただけるのはとてもありがたいなと思いました。
コードカバレッジ計測ツールを導入したらテストを書くのが楽しくなった話
【講演メモ】
コードカバレッジツールを用いて、テストを書く文化を浸透させようとしたお話でした
コードカバレッジはソースコードがテストされた割合であり、テストの品質を保つための指標の1つとして使うと良い
計測方法はさまざま（C0カバレッジ ~ MMC）だが、講演者はC0,C1を85%~90%以上を推奨
コードカバレッジツールを導入することで、どの部分がテストされていないか、どのモジュールがテストされていないかが視覚的にわかる
実際に浸透させるにはテストの優先順位をあげるのではなく、バグ修正や新規機能（追加機能）時の既存コードを確認すると同じタイミングでテストを書いてもらうようにした
結果的にテストを書いてもらえるようになり、今はテストの優先順位も上げてもらえるようになっている
【所感】
私もテスト大事だけど、今取り組んでいるのに精一杯な部分がありましたが、確かに既存コード見てる時にテスト書いたらいいなと思いました。
コード理解ができているという意味でテストを書く≒アウトプットになるので、より既存機能の理解が深まって良い取り組みなのではと思いました。
ちょっと意識的に取り組んでみようと思います。
A Decade of Rails Bug Fixes
【講演メモ】
RailsとRubyのバグを修正する中でデバックの教訓を共有していただきました。
デバックのサイクル
バグを調査する（再現）
信頼できる再現がデバックの最初の一歩
仮説を立てて、ローカル等で観察する
うまく出来なかったら、また仮説を立てるというサイクルを回す
OSSデバックのポイント
OSSの大きな利点、自力でデバックすることができる
コミュニケーションが大事
相手とコンテクストを合わせる必要がある
下のレイヤーに行くのを恐れないこと
動作原理を理解するためには必要だが、多くの学びを得られる
【所感】
RailsやRubyは初学者で深い内容まで理解出来なかったですが、デバック方法については非常に勉強になりました。
もともとテストエンジニアだったので、再現が大事だったな～と思い出しました（笑）
どこに行ってもコミュニケーションは大事なんだなと感じるコトができてよかったです。
今後開発を進めるとバグに出会うことが多いんだろうなと思うので、今回のお話を参考にしていきたいと思います。
参加してみた感想
開発系のイベントははじめてで内容について行けるか心配でしたが、なんとかついていけて良かったです。
初学者でもすぐに業務に活かせることを学べて、とても有意義な時間を過ごすことが出来ました。
来年はもっとRailsについて理解を深めて、今度は議論できるぐらいになりたいなと思いました。
リアルタイムで聴講していないセッションはアーカイブ動画で見てみたいと思います。
この記事が気に入ったらサポートをしてみませんか？