Kaigi on Rails 2022に参加しました！（１日目レポート ）
本日は、Kaigi on Rails 2022 の１日目でした！
早速素敵なトークが満載でしたので、レポートを書いてみたいと思います🙌
Kaigi on Rails 2022 とは？
Kaigi on Rails のコアコンセプトは 「初学者から上級者までが楽しめる Web 系の技術カンファレンス」 です。 Kaigi on Rails は技術カンファレンスへの参加の敷居を下げることを意図して企画されています。また、名前の通り Rails を話題の中心に据えるカンファレンスではありますが、広く Web に関すること全般（例えばフロントエンドやプロトコルなど）についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています
公式サイト より
各トークについてのレポート、感想など
（一部都合により聴講できなかったものは抜けてます）
基調講演：あなたと Rails by Yasuo Honda
Railsのメンテナンスポリシーを解説した上で、Railsへのコントリビュートの一つの方法として、手元のアプリケーションのRailsを最新ブランチに合わせて、バグがあればそれを報告するissueをあげたり、修正PRを送るという方法が紹介されました！
Railsへのコントリビュートってめちゃくちゃハードルが高い印象でしたが、確かに最新のRailsがうまく動かないユースケースを報告するというのは比較的簡単そうです。
メンテナンスポリシーも普段ちゃんと見たことなかったですが、例えば今なら6.1.z以下のブランチではバグ修正はなく、セキュリティ対応のみなどのポリシーが設定されているそうです。
今回のトークをヒントに、いつかコントリビュートしてみたい・・・！
お隣さんの API のデータを Rails らしく、しなやかに扱う by Daisuke Aritomo (@osyoyu)
RailsではAPIサーバーを作成する方法はある程度確立されているが、クライアント側の実装についてはまだ確立されているものがないということで、「いい感じのクライアント（≒外部サービスからのデータ取得などをActiveRecordっぽいインターフェースで行えるようにする）の作り方」を解説していただきました！
まずはAPIクライアントとなるクラスを定義してfindメソッドでデータ取得できるようにするところから始めて、eager loading的なことをするために内部でリクエストをキューイングする仕組みを追加していくとのことでした。
そしてさらに発展させAPIクライアントを本物のActiveRecordにしてしまうことで、has_manyなどのアソシエーションも使えるようにするという方法が紹介されました。
最後のは正直あまりイメージできなかった部分もあるのですが、外部からのデータフェッチをActiveRecordっぽくしていくのは確かに良さそうと感じました！
RBS と Steep で始める型のある Rails 開発とその運用 by Shunsuke Yamada
新しいマイクロサービスの開発にRBSを取り入れるために行なったことや、取り入れた結果どうだったかについてのお話でした。
RBS導入にあたり、コストを抑え恩恵を高めるために、ドキュメント整備や自動化といった工夫を行なったとのことでした（とはいえこれらは普段の開発でも行なっていたとのこと）。
また、RBSを自前のコードのもの、gemのもの、RBS Railsにより生成されるものといった具合に分類し、それぞれのメンテナンス方法なども具体的に解説してくださいました。
導入してみて、思ったより低コストでメリットの方が大きいと感じているとのことでした！
私も早く使っていかねば・・・・
システム開発を支えるメタプログラミングの技術 by Haruka Oguchi
deviseのコードを実際に読みながら、メタプロで実現されている機能を読み解いていく方法が解説されていました！
deviseは自前のクラス名に応じてcurrent_xxxなどのメソッドを提供してくれますが、それらはメタプログラミングによって実現されています。
発表の中では、こうした機能の定義元の探し方などが説明されたり、devise以外にもメタプログラミングが活用されている事例などが紹介されていました。
メタプログラミングはどうしても怖く感じてしまい、これまで敬遠してしまってましたが、「ユーザーごとにちょっと違う」「項目数などが増減する」みたいな状況を共通化できるのは確かに便利そうなので、もう少し歩み寄ってみたいと思いました！
7 つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン 3 選 by Shohei Mitani
7種類もの外部サービスとの連携を実装する中で得た知見として、状態管理という観点から見た場合の設計パターンを3つにまとめ、それぞれのポイントなどが解説されていました！
パターンとしては、リアルタイム型（決済操作がアプリ内で完結して即時決済される）、事前予約型（アプリ内では支払い予約のみが行われ、後からユーザーがコンビニ支払いなどを行う）、完全非同期型（決済操作は外部サイトにリダイレクトしてそちらで行われる）という3つに分かれるとのことでした。
それぞれ注意すべきポイントがあるのですが、実は事前予約型以外の二つは決済フローの大枠としては事前予約型の一部分とみなせるとのことでした。
トランザクションをどう区切るべきかなど実践的な内容で、とても参考になりました！
森羅万象に「いいね」するためのデータ構造 by Natsuko Nadoyama
WEBアプリとしてよくある「いいね」機能について、いいね対象が異なったり、いいねする側が異なったり（ログインユーザー or 非ログインユーザー）する状況でどういう設計がいいのかというお話でした！
当初はいいねをする側といいね対象の組み合わせごとにテーブルを分けて実装していたものの、結局それらが異なっても「いいね」の振る舞いとしては変わらない上、集計バッチで漏れが発生するなどの問題が生じてしまい、ポリモーフィックを使ってテーブルを共通化するというリファクタリングをおこなったとのことでした。
当初の設計は問題があったものの、実際つくってみたことで「いいね」が単純な構造だったということに気づけたとのことで、やはりまず作ってみるというのも大事なんだなと思いました！
大量塩基配列登録申請システムができるまで by Keita Urashima
研究者が塩基配列のデータ（GB単位の大容量データ）を公開データベースにアップロードしたり、フロントでパースしてブラウザ上に情報を表示するためのアプリを作成したというお話でした！
一般的なWEBアプリに比べてはるかに大きな容量のデータをブラウザ上で扱うという難題に対し「創意工夫とパワープレイ」で乗り越えたというとてもアツいお話でした・・・！
アップロードはActiveStorage のダイレクトアップロード機能で比較的すんなり実現できたとのことですが、ファイルの中身をパースしてブラウザ上のフォームを自動で埋めるような機能を求められ、その実現のために、Streams API、Web Worker、WASMといった技術を活用して工夫を凝らしたとのことでした。
実際デモも見せていただけたのですが、9GBいう大きなファイルを二個同時にアップロードしてもブラウザが固まったリせず、パースも高速（30秒くらい）で処理されていました！
「今まで無理だったもの、諦めていたものを、新しい技術でぶちのめすのがソフトウェア開発の中で最高に気持ちいい瞬間の一つ」と語られていました！
エンジニアとして本当に尊敬します・・・！
実例で学ぶ Rails アプリケーションデバッグ入門 〜ログインできちゃってました編〜 by Masatoshi Moritsuka
フィヨルドブートキャンプ＆前職で先輩として大変お世話になった森塚さんの発表です！
業務で携わったアプリで実際に遭遇したホラー話として、「退会したはずがログインできてしまう」という現象について、サンプルアプリを通じてそのデバッグ方法を解説されていました！
コミットごとの動作確認から始まり、source_locationメソッドなどを駆使してwardenの実装まで遡って確認されていました。
原因としては、deviseのcurrent_xxxメソッド使用時に意図せず認証処理が行われていたことだったらしいです。
deviseはよく使ってるだけに怖いですね・・・！よく覚えておこうと思います。
あとsource_location活用していきたい！
3rd Party API on Rails by Tomohiro Suwa
Railsでサードパーティ向けのAPIサーバーを作る際の適切なAPIスコープ設計についてのお話でした。
OAuth2.0にスコープというものがあり、それによってユーザーがアクセスできる範囲を制限することができるそうです。
そのスコープの情報をAPIに載せる必要があるようですが、例えばTwitterやGitHubなど一般的なサービスではリソース＋権限（アクション）で区切られていることが多いとのことで、このようなスコープ設計をするにあたってRailsのcontroller_name, action_nameが便利だったとのことでした。
ちょっとついていけなかったところが多いですが、認証ありの公開APIを作る際はとても参考になりそうな内容でした！
Balance Security and Usability in the Field of 3D Secure by Masato Ohba
WEB上でカード決済を行う際のプロトコルである3D Secureについて、その概要や歴史について解説されていました！
3D Secureの歴史は古く、V1.0が登場したのは20年近く前になるそうです。
当時はまだカード決済に認可の仕組みしかなく、本人認証が行われていなかったとのことです。
しかしv1.0はユーザービリティが低く、普及もいまいちだったらしいです。それが改善されたのが2017年に登場したv2.0で、ここからOTPや生体認証も使えるようになりました（そして今年、v1.0はサポートが終了したとのこと）。
3D Secureによる決済の流れも説明していただきましたが、登場人物が多く、かなり複雑な仕組みになっているようです（登場人物が3つのドメインに分類されるので3D Secureという名前になっている）。
「数千数万の企業がこれだけ複雑なプロトコルに従っていて成立しているのが驚き」とおっしゃっていて、確かにと思いました。
他にも取引のリスク評価のために決済金額などをモニタリングし続ける必要があることなどが説明されていました。
普段よく使っているのにあまり知らなかったカード決済について、少しだけ仕組みを理解することができました！
歴史あるプロジェクトのとある技術的負債を隙間プロジェクトの 210 PullRequests で倒しきった話 by makicamel
7年間運用されてきたサービスについて、隙間時間で技術的負債を返却し続けてとうとうやり切ったというお話でした！
具体的には、アプリの初期段階で導入されていたcrud_controllerというものを撤廃したとのことなのですが、多くのコントローラで使われていた上、暗黙的なコールバックなどもたくさんありかなり手強いものだったようです。
やり切るために、修正をスクリプト化して短い時間かつ断続的でも進められるようにしたり、ボーイスカウトルールをあえて破ってでも変更リスクを減らしたり、みんなの関心ごととなるようにレビュー依頼を出して仲間を増やしたり、進捗の見える化や自ら発信して褒めてもらってモチベーションを保ったり・・・と、いろいろな工夫をされたそうです！倒し切ったの本当にすごい・・・！！
リファクタリングとかついつい後回しにしてしまいますが、大きいものはやはり継続してやっていくしかないし、負債が大きくなりすぎる前に返却していくことが大事だと改めて思いました！
1日目のレポートは以上です！明日も楽しみ！
