2022年10月24日に『ふりかえり Kaigi on Rails 2022』と題してイベントを開催しました。イベントでお話した内容を文字起こしレポートでお届けします。
自己紹介
kwappa：そろそろ「ふりかえりKaigi on Rails 2022」を始めます。みなさん、こんにちは。
みんな：こんにちは。
kwappa：Kaigi on Rails、みなさんお疲れ様でした。楽しかったでしょうか？このイベントは、STORES 株式会社のエンジニアを3人もKaigi on Railsの登壇者に送り込むという快挙に成功しましたので、ぜひその登壇者を集めて振り返りながら、また来年も楽しみだなという気持ちになっていくというイベントです。まず、登壇者のみなさんから一言ずつ自己紹介をもらいましょうか。藤村さんからお願いします。
藤村：藤村です。僕はRailsを10年ぐらいやってました。Kaigi on Rails 2022では、CTOが新しいRailsアプリを触るときに何を見ているのかという話をしました。よろしくお願いします。今は、WebフロントエンドとWasmに興味があります。
Shia：シムです。ネットだとShiaと名乗っています。Kaigi on Railsの発表では、差分ベースで効率的にテストを選択して実行する方法みたいなものを提案しました。今日はよろしくお願いします。
hogelog：hogelogです。僕はDay2に、セッションストアの移行みたいな話をしました。サーバーサイドエンジニアをやりつつ、インフラ周りも触っているので、その辺の作業の一環として実施した内容を話しました。
kwappa：司会進行はHolyGrailさんです。
HolyGrail：HolyGrailと言います。STORES のバックエンドエンジニアで、RailsやRubyとかその辺の色んな改善をしています。こんな感じで出社しているんですけど、特にみんな何も言わず当たり前に接してくれるいい会社です。そしてこの姿で出社してくれる人を増やしたいなと思いながら活動しています、よろしくお願いします。
kwappa：STORES のエンジニア陣でお送りします。では、司会進行HolyGrailさん、お願いします。
HolyGrail：振り返り感想戦をやっていこうかなと思うんですけど、今日はトークテーマを用意しています。各3名の発表したセッションの内容、気になったセッション、来年の話と STORES とRubyやRailsですね。
内部品質の改善に時間を使うべきかは明確な意思決定が必要
HolyGrail：まずは、各発表者のセッションについて聞いていきたいなと思うんですけど、せっかくなので発表順にしましょうか。藤村さん、発表してみて色んな反応があったと思うんですけど、どうでしたか？
藤村：ちょっとどうでもいい話ですけど、30分ちょうどで終わったのがすごいなって自分でも思いました。
HolyGrail：そうですね。この3名だと、唯一のリアルタイム発表でしたね。
藤村：あの発表は台本とか一切なくて、スライドしかないんですよ。気持ちと勢いを整えてセッションに臨むことが一番重要だったんですけど、そういう気持ちを伝える部分に関してはみなさんの反応を見るとよかったのかなって。何かしら役立ちそうな話ができたかなと思えたので、そこはよかったですね。
hogelog：何か整え作業をしたんですか？
藤村：佐山 聡ってプロレスラーがいるんですけど。佐山 聡が自分で自分のアドレナリンを出すのも技術のうち、と話している動画があって、あれを見てから臨みましたね。
hogelog：なるほど。発表内容には含まれてない、いいTipsだった。
HolyGrail：藤村さんは実例を含めて発表されていたので、なるほどなぁっていう感じの反応が多かったですね。
藤村：僕自身もずるいなと思ったのは、これを一緒にやっていたのが卜部さんなんですよ。PMIの秘訣は卜部さんを用意するって話だと全部終わっちゃうなと思って。ちょっとチートですよね。
Shia：いい話。強いエンジニアを突っ込めば何とかなる。
藤村：そうですね。最初にPMIの心構えみたいなのを書いたんですけど、これは多分戦術レベルみたいな感じなんですけど。
藤村：もっと大きいレベルだと、エンジニアの投入を惜しまない、一番強い人をPMIのプロジェクトに入れるのは重要なんだろうなって思いましたね。それでうまくいかなかったらもう無理なんだなっていう諦めもつくじゃないですか。でも、諦めることって多分なくて、解決できるようにすると思うんですけど。経営判断という観点で言うと、新しく入ってくるチームをよくしたり、エンジニアリングをよくしたりするのに最初から一番いい人を入れるっていうのは重要なのかなと思いましたね。
HolyGrail：そういう判断ができたのは藤村さんがCTOとして、そこに対する最強の裁量を持っていたからというのは大きかったし、そこが大事なんだろうな。
藤村：そうですね。あとは、そうしたほうがいいよねってコンセンサスを経営チームでも持つというか。うちでいうと、CEOとエンジニアの組織でもっておくのが重要なのかなと。
あとは意外と反応がなかったけど、僕が重要だと思ったのは、内部品質の改善に時間を使うか使わないかって明確に意思決定が必要になると思ってて。
藤村：改善に時間を使うか使わないかって判断しないとできないと思うんですよ。スクラムで何パーセント分は内部品質の改善に使いますという話はしやすいと思うんですけど、一旦全部をそちらに向けますという判断が場合によっては必要だと思うんですよね。で、その判断は多分現場ではできないんですよ。1つのプロダクトや事業で考えると、きっと経営レベルの意思決定に近いものになる。それをエンジニアがちゃんと入れるようにしとく、ちゃんとやる。やれなかったとしても、この状態だと無理だから絶対そうした方がいいと話を持っていく。それは重要だなって思いますね 。
内部品質の改善にめっちゃ時間を使いますっていう意思決定を正当化するためには、t_wadaさんのスライドを読むのが重要だよていうのは、もうちょっと強調してもよかったかな。意思決定しないと、少しずつよくし続けていくが、別にパフォーマンスはよくないみたいなのがずるずると続いちゃうと思うので。判断が必要。判断は必要だけど、判断するって結構難しいなっていうのもあるので。
Shia：エンジニアとして内部品質があまりいい状況ではないというのは直感的にはわかるんだけど、それをちゃんと言語化して周りの人を説得していくっていうのが結構難しくって。そういう意味だと、t_wadaさんのスライドはめちゃくちゃ参考になりますね。
hogelog：t_wadaさんの話、内容としてはそうだよなって感じだと思うんですけども、それをちゃんと言語化してくれてるんで便利な語彙をいっぱいありがとうございますって感じですよね。
藤村：社内でも和田さんに1度来てもらって、話してもらったんですけど、事前の打ち合わせで「ぜひエンジニア以外の意思決定に関わる人も呼んでください。その効果が実は大きいです」って話をしてて、なるほどねと思いましたね。あと僕はエクセルに簡単なモデルを作って、内部品質にどれぐらいの時間を使うと、いつブレイクイーブンするみたいなグラフを書いたりしてましたね。自分の中で肌感覚を得るために数字にしてみるとかはやってたりしたなぁ。
hogelog：こういうことを言うと、一部のエンジニアの人には煙たがられるかもしれないですけど、内部品質だけを上げ続けることが価値を生むわけじゃない。これをこれぐらいやることで、よくなるメリットを得られるみたいなところと、内部品質を上げても直近のビジネス価値自体は伸びないよねっていうところは、いいエンジニアの人だと自然と感じるところだと思うんですけど。そこへの共感、そもそもそれを理解して飲み込んで、でも今はこれをやるべきみたいな話をちゃんとできるのが大事だよなと思いました。
藤村：Twitterを見てて思ったのは、僕は技術的負債って言葉を1回も使わなかったんですよね。それに意図があったかというと、なくて単純にその言葉自体を忘れてただけなんですけど、そもそもあんまりこのPMIで技術的負債と言う言葉を自分が積極的に使わないようにしてましたね。言葉の感じがつらいじゃないですか。
hogelog：絶対悪みたいな感じが。
藤村：経営みたいな面で見て経営って結局事業が数字でどうなってるんですかって話で、その中で負債って言葉も出てくるんですけど、そのデットとニュアンスが違うので、混乱するから自分としてはあんまり使わない感じになってますね。
hogelog：藤村さんの発表は、上から目線でいうと（笑）、ちゃんとまとまっているし、ちゃんとやってるなぁ藤村さんって。Railsアプリケーションがあって、開発に入っていく時にやることがしっかりとまとまっていた。藤村さんはCTOになる前に、業務委託とかでファイヤーファイターをやってきた経験が多数ある。そういう経験も効いてるんだろうなぁって感じました。
藤村：僕、ここ数年で何回デプロイを自動化したか覚えてない。
hogelog：Rails Criteriaみたいなね。なんだったらrubocopのfujimuracopとか作ってそうだなって。
藤村：GitHub Actionsのyamlまで見るみたいな。楽しく発表できたし、自分の中でも何やったのかを整理できたのでありがたかったですね。
テスト実行時間を短くしたい
hogelog：シムさんの話をしていきますか。
HolyGrail：テストの話ですね。
Shia：前職時代からファイルというか、テストの数が結構多くて、並列テストをしがちなので、どうすれば楽できるかというのを3年ぐらい考えた結果、動的分析でないと間に合わないだろうって。当時はTracePointを実際に使ってみたらめちゃくちゃ遅かったので、一回諦めて、2日目に発表があったPackwerkのようにちゃんと置き場を利用してパッケージみたいな扱いをして、その中で変更されたら、そこだけテストすればいいんじゃないかと考えてたんですね。実はそうだったんですけど、Shopifyでは動的分析でやっているという話を見て、やればできるのかっていう気持ちになって1年ぐらい頭を使って最終的に出来上がったのがこんな感じでした。
時間の都合で流してしまったんですけれども、実はこのスライドはもともと50ページくらいあったんです。30分枠があったなということに後になって気付いたんですけど、変えることができないので、背景を削ってるんですね。例えばテストをなぜするのかも、初心者向けであればその辺も書いた方がいいなって思って最初は書いてました。静的テスト、動的テストの扱いの違いも説明すべきだったなとか、ファイルの差分の計算も1例しか出してないんですけれど、説明する時間がなくて飛ばしたり、動的ベースを選ぶしかなかったっていう説明を全部飛ばしたり。背景を全部ぶっ飛ばしまくったという悲しい話があります。
hogelog：CI、テストとかって職を変えるたびにまた面倒を見てる。parallel_rspecも面倒を見てあげる必要があるし、CircleCIとかパラレル実行とか、若干楽になるけども、金で殴っている感じにもなったりするし。
Shia：なりますよね。
hogelog：いつまで我々はテスト実行時間について頭を悩ませ続けなければ…みたいなね、あるんですよね。
Shia：それで実際差分テストをやってみると、どうなるのかっていうのを頑張って試した。結論として今入れてるかというと、我々は入れてないんですけど。
HolyGrail：そうですね。
hogelog：Kaigi on Railsで今回話しましたが、仕上がったらRubyKaigiでもいけるかもって思いました。
Shia：どうなんでしょう。それはShopifyが話す内容なのでは、という気がするんですよね。
hogelog：まあね、それってRubyKaigiあるあるで。私たちはこれをやっている、いやあの会社でもやっているけど、別のを作ったぜっていうのはある。MJITの話、YJITの話、俺俺JITの話みたいなのがいっぱいあるRubyKaigiらしい話なわけで。盛り上がってきたらちょっとあるかもしれないですね。
Shia：それで言うとあれですね、カバレッジで1回試してみたい気持ちはありますね。全部終わってから気付いたんですけど、めっちゃくちゃすごいなと思ったのが、カバレッジって高度の実行追跡するためのツールなので、実はそれで全部取れるんじゃないかということに2年経ってから気づいてしまった。その凄さも説明をしたかったんですけど、時間の都合でぬるっと飛ばしてしまいました。カバレッジはすごい。
hogelog：それもワンショットで済む用途ですよね？
Shia：これはワンショットだとダメですね。1回記録すると次のテストの時は記録できなくなるので、ちゃんと通った回数をカウントする普通のカバレッジじゃないとダメでした。それでも十分早いんでね。
hogelog：笹田さんのcallereeは収録時には壊れていたけど、発表時には修正されていたみたいな話でしたっけ？
Shia：はい。ちゃんと中身を理解しているわけではないんですけど、新しいスレッドを生やして、そのスレッドの中に対してトレースができなくて、Iseqが取れるべきところでIseqが取れてなかったみたいな話があったと思いますね。なのでそれをスキップすべきなんだけれども、されてなくて死んでいたという辛い話なんですが。callereeを使ってみたかったのはrotoscopeとアプローチはほぼ一緒ではあるんですけど、callereeでは
呼び出し先の情報を自動で取ってくれるので何も頑張らなくて済むからです。
一方でrotoscopeは何を頑張らないといけないかっていうと、クラスメソッドなのかインサンスメソッドなのかみたいな情報を一緒に提供してくれるんですが、実際のメソッドとの置き場を教えてくれないんですよ。なのでそれからメソッドオブジェクトを真面目に取ってきて、メソッドの中で何をしているのかとか、その中の差分ってどうなってるのかみたいなことを考えなきゃいけなくなって大変。実は最初は全部やってました。渡した情報を見て真面目に取っていたんですけど、呼び出し元のロケーションがわかれば全てがまかなえることに気づいてしまい、そこを頑張らなくなってしまったという悲しいオチがあります。実際呼び出し元がわかれば大体解決してしまうんですよね、Rubyは全てメソッド呼び出しなんで。標準ライブラリとか gemを見にいくことになれば、大体自分たちの実装は通り過ぎる道にあるので頑張らなくてもよかった。
hogelog：これ系の話をやっている人っているのかな？差分ベースでテストを実行しているんですよってAsk the Speakerで話している人とかいましたか？
Shia：なかったですね。40%ぐらいテスト実行が早くなくなるのであれば熱い、熱くないっていう話はしていたけど、実際やってましたっていう話は聞いていないですね。
hogelog：そうですよね。
Shia：40%が実行早くなりますって言われて嬉しいかというと、個人的にはあんまり嬉しくないなっていう。
hogelog：40%ね。全部実行するのとは違う仕組みを入れた上で40%の時間削減…なかなか悩ましい感じがしますね。
Shia：コスト的には安いとは思うんですけど。
hogelog：人間のコストを無視すれば。
Shia：でも実際40%の実行がほぼなくなるって考えると、例えばGitHub Actionsは使っただけ課金じゃないですか。課金量がほぼ半分になるので、お金的には嬉しい。
hogelog：別に用意するものもそんなにないですかね？データをどこかに置いておけばいい？
Shia：ないですね。GitHub Actions内部で使うので、他の CI も一緒なんですけど、キャッシュさえ使えればそれで済む話なので。
hogelog：なければ全部実行されるみたいな感じで。
Shia：そうそう。
hogelog：やってみて走らせておいて大丈夫そうみたいなのを様子を横目で見つつ、しばらくやって導入できるのかなぁっていう感じですね。
Shia：まあ…って感じですね。そこは自分たちのテストに対する信頼が必要だなっていう話にはなるんですけど。実はちゃんと通ってませんでしたっていう話とかですね。
hogelog：それが気になりますね。
Shia：実際これを試してても、1ヶ月か2ヶ月か使ってみて、CIは通ってしまいましたが障害になりました。CIが通ったんだけれども、デプロイしてみたら障害になりました。ただしそれは全件テストすれば CI は通りません、ってみたいなケースを収集しないといけないわけですが、それがそうそう起きることかというとあんま起きないしっていう話なんですよね。なので確認するためには1年ぐらい動かしてみないと自信を持って言えないという。
hogelog：それこそプルリクエストテストからこっちにしてみるのはありなんじゃないですか？
Shia：そうですね。最後にこれくらいはやってもいいんじゃないですかっていう話をしています。
hogelog：PR実行時だけやる。
藤村：超単純なルールベースのやつも結構いけそうな気もしません？
Shia：割といけるかなと思いつつ、一部やばいやつ。STORES だったら、商品とかストアとかそういう概念のやつをどうするのって話になってきて、それだったら全件実行しますみたいなルールしか書けなくなるので。
hogelog：今は特に特別対応のルールを入れる仕組みは入れてないんですよね?
Shia：そういうものは何もないです。
藤村：思ったのはヘルパーが変わったとかだったらモデルのテストを確認しないでいいだろうって思うんですけど。ヘルパーはだいたいインクルードされてるんですよね 。
Shia：はい、コントローラ側にインクルードされてっていう話はありますね。
藤村：モデルにヘルパーがインクルードされてる事例があるじゃないですか。
Shia：ありますね。
藤村：そう簡単にいかないんだろうな。
Shia：一応でも入れようと思えば入れられるのか。差分計算をした上で、store.rbとかが含まれていれば全件実行しますみたいなことはできそう。これはあくまで差分から影響されてるテストを返しているだけなので。
hogelog：現実的に組み込んでいくことを考えるとほしくなりますね。
藤村：メーラーの下変更しても何も起きないだろうと思ったら、意外とっていうのが基本的にはほぼ全部起こっているのがプロダクションコードですもんね。
Shia：はい。ちょっと話はそれるんですけど ヘルパーは本当に良くない。良くない状態になりがち。
r7kamuraさんのコメント「includeとかの依存関係を統率するCopと組み合わせると信頼性高まるかもしれませんね」
実はですね、そのrubocopも書いてるんですよね、昔書いていて。これとは関係なく別の用途で使ったやつがありましたね。
hogelog：GreppableじゃないRailsのコード、いっぱいあるもんな。
藤村：GreppableRails、人類の夢じゃないですか。
Shia：これはrubocopのルールで、コントロール内でヘルパーをインクルードするなっていうルールがありますね。ヘルプの中でインクルードするなっていうルールとかもある。
藤村：モデルの中でURLを読むなとかですよね。
Shia：これは STORES にも入れたい気持ちがややあります。一旦これをなくしておけば、Greppableになるので。ではこの辺にしておいてhogelogさんの話に行きますか。
データは自分たちの手元に置いていた方がいい
hogelog：セッションストアの移行の話をしたんですけども。
HolyGrail：これは大変でしたね。
hogelog：どうなんだろう、大変だったのかなというのが若干あって。自分のやったことって大体自明になるじゃないですか。だからセッションストレージをCookieStoreからRailsに移行しただけなんだよなって気持ちになってて、これ意味のある話になるかなって。CfP書くときには「こういう意味で価値があります」って書いて出したんですけど、直前では自明なんじゃねえかな、みたいな気持ちになってたんですけど。ホラー枠とか怖いみたいなリアクションがいっぱいあったので、やってよかったんだなって思いました。
HolyGrail：リアクションはよかったですね。障害の話はウケがいい。
hogelog：みんな大好き障害の話っていうね。CookieStoreは便利っていう話とそれを移行しなきゃいけないときのベストプラクティス。サーバーサイドに置くのがいいですよに対して、「なんでですか？」みたいなリアクションもちょいちょいあったんですけど、そこは僕が頑張って言語化するよりもOWASPなどのセキュリティ専門の人たちが、Railsのデフォルトはよくないのでやめようなみたいなこと書いてるのを読んでいただければと。
Shia：それともう1個ありますよね。ドメインモデルのオブジェクトをマーシャルにしてCookieStoreに突っ込むみたいなこともあった気がするな。CookieStoreに入れると何年も消せないんじゃないですか。
hogelog：CookieStoreは大変なんですよ。自分たちでコントロールできないのに、そこになんとなく入れちゃったもののせいで大変になることがしばしばあるわけで。やっぱりデータは、すべてのことにおいて、データケアとかのことを考えると自分たちの手元に置いていた方がいいですよね。最後の方でCookieStoreも悪くないって弁明しましたけど、とはいえ手元に持っておいた方がいいんですよね。
藤村：これを見て思ったのが、最近Edge Runtimeとかにすごい興味あるんですけど。クラウドフレアのD1、D2、何番か忘れた。Edgeで動くストレージよりもやばいじゃんみたいな、Cookieのほうが最強の分散ストレージだと思って。
Shia：それは確かにそうかもしれない。
藤村：Edgeを超えてるじゃんみたいな。
hogelog：改めて考えるとCookieが強いって。ユーザーがいくら増えても大丈夫なんですよ。ユーザーが300億人になってもセッションは溢れないんですよ。
藤村：世界で一番容量多い気がする、永続化レイヤーとしては。
hogelog：超すごい分散ストレージですね。
藤村：最高だ。
Shia：実質あれですよね。ブラウザにWasmでSQLiteを動かしておいて、レプリだけしまくるっていうクラウドDB。
hogelog：r7kamuraさんからコメントがあって
「Rails準拠のsession storeを2つ使うダブルライトの実装って、double_session_stores gemみたいに汎用化できそうですか?」っていうのはやってできないことはないと思いますけど、僕はやりたくないし、多分みんなやりたくない。
それを使って大丈夫ですよっていう保証をするのがとてもしんどいんですよね。例えば現バージョンのRails 7.0でちゃんと動くように作ったとしても将来壊れるか怪しいですし、現7.0で壊れない、大丈夫って保証するのも嫌だなと思います。
藤村：そのライブラリのメンテ、つらそうですよね。
hogelog：Rails本体がやってくれるならまあ…。Rails本体もそこのメンテはやりたくないんじゃないかなという感じで、ダブルライトという話はよく出てくるけども、OSSになって出てこないのはそういう理由かなという気がしますね。
HolyGrail：今回みたいな、このケース以外でダブルライトし続けたいみたいな、あんまりないですよね？
hogelog：素朴なレイヤーだとダブルライトのものとかが、普通に世の中に出てるものとかあったり。例えばなんか Percona toolkitとかで、オンラインスキーマーチェンジ(pt-osc)とかテーブルダブルライトしてみたいなことを普通にやってますし、ミドルウェアレイヤーのもののダブルライトしてくれるシステムみたいなのはある気がしますけど。Railsレベルは嫌ですね。やる人はいるかもしれないけど、なかなかいないんじゃないですかねという感覚です。
Okuraさんが「強制ログアウトとかも簡単ですし」と、データをサーバーサイドにセッションを持っておきたい話のコメントだと思いますけど、それはまさにって感じで。CookieStoreだと簡単には強制ログアウトの仕組みはできないわけですよ。
扱いたくないし、分散したいからCookie側に追い出してるはずが、特定 Cookieを受け付けない設定をデータ側に持っていてみたいな複雑なことになるので。だったらデータをサーバーサイドに持っておけっていう話で、それを消すだけで済みますからね。
r7kamuraさんコメント「どちらかと言うとものすごくジェネリックにしてRailsに入れたいですね、Railsはバージョン間でダブルライトする実装を持ちがちなので (Cookieの署名のルールが変わるとか)」
Railsに入ってくれると便利なのかな？Railsに入っていて、安定して使えるんだったら、確かに使いたいかもしれないですね。
Shia：まあでも、使いたいって思う瞬間って、1プロジェクトに対して1回くらいしか来ないんじゃないですかっていう気もして。
hogelog：はい、そうですね。えいっとやる時だけなんですよね。事故った話もちょいちょいあったりしたんですけども、なぜ事故ったかの話で実は書いてない、ちょっとメタい話としては、移行作業がすっと一瞬で終わらせられなかった時期があるんですよね。その時にまさちょっと事故になったり、事故った時に原因究明にちょっと時間がかかってしまったりみたいなところがあるので、移行作業なんていうのはすっと終わらせるに越したことはない。
Okuraさんコメント「ActiveSupport::DualWriterとかですかねえ」
確かに、ActiveSupportレイヤーでそれっぽい処理が入ると便利なんですかね。Redisからあっちに追い出すとか、ダブルライトで移行していくのはよくある作業なんで、ある話かもしれない。振り返りで、ダブルライトなんてやめとけみたいなことも書いたりしたんですけど。
藤村：そういうことですよね。リセット許容ってできたのかなというのは、僕たちも反省点というか。
hogelog：反省しつつも、ダブルライトできるなっていう感触も得てしまったので、結局またその業務が目の前にあった時にダブルライトやらないかちょっと怪しいなって。やればできるよなって思って、やっちゃうかもしれないなって思ったりしました。
Shia：タイミングが難しいですよね。
hogelog：ものとそれの影響と。redis-rails gemに関しては時差問題があって、僕が収録した時にはアクティブではないというふうに言い切って、そんなに問題ないかなって感じだったんですけど。発表動画を収録した後に僕もなんかこうredis-rackとかこの辺にちょっとプルリクエストをぽいっと。CI がtravis-ci.orgだったので、GitHub Actionsに置き換えるみたいなプルリクを送ったら、アクティブな人もちょっとやる気になって、メンテナンスしてくれたりissueに転換してくれたりしたので、発表してる時は割と動いてましたっていう。ちょっと言い過ぎたなっていうのを反省しました。
Shia：自分がメンテしてるgemのプルリクって、定期的に確認しないと割と漏れるなって思いませんか？
hogelog：特にissueだけポイっと投げられてもなかなか大変なんですよね。これとかもすごいコンテキストフルなことを書いて、その後コミュニケーションしてるんですけど。しっかり読み込んで返事してくれてるなって感じです。一瞬で返事できないようなissueを上げているんでなかなかね。でもちゃんと動いてくれてるんでありがたいです。ちょいちょい手を出していこうかなと思ってます。
藤村：ミッションクリティカルなgemだが、民間の人が見ている。これはやる方も辛いですよね。
hogelog：OSSって本当に人々のやる気で動いてるなっていうのは、あらためて感じましたね。Rails Contributorsとか、Railsはコントリビュートしてる人いっぱいいるなって気持ちになりますけど、よくよく見てみると上位の人たちでほぼ動いてるわけですよね。
藤村：そうね。redisを使ってお金儲けしてるクラウドベンダーの人たちが手を動かしてほしいですよね。ぼくらもそれでお金も儲けてるから手を動かすべきなんですが。
hogelog：そうですね。
藤村：プラットフォーマーがやればいいのでは、みたいな勝手なことを思ったりしました。
Kaigi on Rails 2022で気になったセッションは？
hogelog：僕らの発表以外の発散した会話でもしていきますか。
HolyGrail：気になったセッションについて聞いてみたいなと思うんですけど。
藤村：これかな。
このトーク、すごいよかったなぁと思って。RSpecの書き方を学んだ後に、いわゆる一般的なテスト技法を学ぶみたいな話になってるけど、逆やぞっていつも思うんですよね。もともと手動テストをめっちゃやって、Excelにスクショを貼っていた人間としては、まずはテスト手法を勉強してから自動テスト書けよってのがすごくあって、この話はよかったな。
hogelog：今時のちゃんとテストを書いてるWeb企業育ちの人とか、テスト書くのはすべて正義みたいな感じでちょっと無駄にテスト書きまくったりというのもあるので、テストはそもそも何をすべきかっていう話はいいですね。
Shia：いい話。
藤村：研修とかでやってほしいなって思っています。うちでもやりたいですね。
hogelog：しんくうさんの話をさらっと流してしまって申し訳ないですが、ちょっと残り時間が少ないので、いろんな人のセッションに触れていきたいなと。Closing KeynoteのNateさんの話。
Shia：よかったですね。
藤村：すごくよかったですね。
hogelog：理解できてないところをいっぱい説明してくれていたので、すごいよかった。
Shia：個人的には、今ちょうどECS移行をやってるじゃないですか。タスク側のキャパシティプランニングをどうしようかなって毎回迷うわけで、そういう意味で役に立つ話でしたね。
藤村：めちゃくちゃ実践的、かつすぐ持ち帰って使えるやつでよかったですね。
hogelog：さすがスピードショップ。Rails Performanceコンサルタントなんですよね。
Shia：それでいうと現実で人々の役に立ちそうだなって思ったやつは、osyoさんのActiveRecord::Relationの発表ですかね。
hogelog：我々が雰囲気で使ってるActiveRecord。
Shia：ちゃんとこれがわかれば悪いことじゃないっていうのが理解できる。初心者にも優しい発表だったと思うし、振り返りとしてもよかったなと思いましたね。
hogelog：RelationはArrayじゃないっていうのを持ち帰ってもらえればだいぶいいですね。
藤村：あとはPostgreSQLの話もすごいよかった。
Shia：PostgresSQLをそんなに使ってない側の人としては知らないものがいっぱいあるなと思いながら見てましたけど。
藤村：JSONとかすごいんですよ、JSON-Bってインデックスが効きますからね。そういう謎テクが超あるから面白い。
hogelog：僕とシムさん、HolyGrailさんは STORES のスポンサーブースでパブリックビューイングみたいにペチャクチャ喋りながら聞いてたんですけど。僕とシムさんはMySQL育ちなんで、それRDBMSでやるんだ、RDBMSやりたくないなみたいなことを。MySQLと言うとかちょっとリレーションとかいろいろジョインとかができる便利なキー・バリューストアと思ってる人としてはなかなか。でも確かに言われてみると、データベースのデータってアプリケーションコードより寿命が長かったりするんですよね。
藤村：僕とかバリデーションとかもPostgresで書きたいですもん、チェックも。
Shia：Postgresトークはノーカット版があるらしいですね。見ないと。
藤村：楽しみ。あとはね、僕はこの話もよかったです。makicamelさんの筋肉の話。
スクリプトにして、誰でも実行できるようにして倒すのは本当にそうって感じで、自分もよくやってるんですよ。スクリプトを書いてコードを直すってやつ。出てくるコードがまじでこれ書くわーってのしか出てこなくて、親近感を覚えましたね。
Shia：前職で、FactoryBotを使う前のライブラリとしてMachinistっていうgemがあるんですけど、それ使っていてそれとFactoryBot両方使ってる状態になっているプロジェクトがあってですね。これ絶対書き換えられるだろうと思ってASTをパースして、Machinistの呼び出しを全部ファクトリボットに変えるスクリプトとか書いてましたね。これ見ながら筋肉〜て思い出してました。
hogelog：Machinist懐かしい。書き味は結構よかったんですけどね。
藤村：懐かしすぎる。
Shia：悪くはない。
hogelog：FactoryBotに飲まれて。
Shia：メンテされなくなってしまいましたね。モデルにクラスメソッドを生やすのは邪悪だったと思います、Rubyっぽい書き方だなと思うけれど、邪悪だなっていう。
藤村：あとはこういう変更の時に、ついでにボーイスカウトルールみたいな感じでコードを直すと事故るっていうのは本当にそう。
Shia：その通りですね。ここまでは頑張る、ここからは頑張らないっていう、境界があるのはめちゃくちゃいい話だった。
藤村：あとUrashimaさんの話すごかったですね。塩基配列登録システム。あれは面白かった。
Shia：いい話でしたね。話は変わるんですけど、個人的にはこれ転送で圧縮ちゃんとしてるのかなというのだけ気になってました。4GBくらいになったら圧縮しておかないとめんどそうだなと思ってたんですけど。
HolyGrail：読んだ先からパースをするから、ネットワークレイヤーでそのまま読めるようにした？
Shia：通信状態の圧縮してるのかなって。アップロードの時に、マルチパートアップロードすると思うんですけど、その時のコンテンツエンコーディングとして、gzipを選んでおくともっと早かったのかなと思うんですけど。
hogelog：アプリケーション上は何も変更しなくてもできません？
Shia：バックエンド側の handshake でつかえるコンテンツエンコーディング返して、Rails側が対応しないとできなかった気がするんですけど。Rails上で gzipで通信したことないので、自分でもわかってないんですけど。
hogelog：プロキシレイヤーでできるんじゃないかなって。
Shia：ブラウザがそれに対応しないといけないから、通信はどうなってるんだろうというのが気になっていました。
hogelog：上流にあげる時にそれができるのかは知らないです。できてほしい。
Shia：できてほしいなと思ったんですけど。それ以外はやってるなぁって感じでしたね。
hogelog：うなすけさんがね、Kaigi on Rails 2022運営記をあげてくれてますけど。うなすけさんは、RubyKaigiで発表しながら、イベントの運営もしていて、がんばってますよね。RubyKaigiぽいネタを仕事している中で積み上げていくのは難しいけど、Kaigi on Railsは仕事のあのへんを切り出して共有できる、みたいな感じで。仕事でやった話を発表しているだけなので。ありがたいなぁって思いますね。
藤村：そうですね。
hogelog：スポンサーブースはむずかしさがある。大倉さんが参加されている前で言うのもあれですけど。ちょっと前にRubyKaigiでオフラインを体験したので。オンラインは難しいよなぁって未だに感じるところはあります。次回、ライブと録画、どうしたいですか？
Shia：録画でもいいかなと思っていて。〆切が近い以外のデメリットはない気がしてます。
hogelog：ライブ感出したいなと思うけど、出せるかなと思うところもあって。でも、佐山 聡の動画を見て臨めばできるかもしれない。
Shia：オンラインだったら録画でいいし、オフラインは登壇の方がいい。
hogelog：たしかにオフラインだったら登壇したい。
藤村：オンラインならではの、動画として作り込むのも考えてみればありだなって。メディア・アートとしてやっちゃえばいいんじゃんって。
Shia：3Dセキュアの話はよかったですね。
HolyGrail：ちゃんとやろうとするとめちゃくちゃ手間がかかるんですけど。
藤村：僕の今回の話はオフラインで人の前で話したかったなぁ。オンラインで気持ち系の話をするのは相当気持ちを高めないとできない。
HolyGrail：来年はリアル会場を抑えた上で開催できそうという話もあったので、その辺を期待しつつ。ただ、オンラインとオフライン両方やるつもりでKaigi on Railsは覚悟を決めているそうなので。
Shia：両方を一緒にやるのはめちゃくちゃ大変そう。
hogelog：運営のうなすけさんが「やれんの？」て書いてますね。Okuraさん「やりたい」
kwappa：残り1分なのでそろそろ締めに入りましょう。今回は運営のみなさんにもたくさんご参加いただいているので、あらためてありがとうございました！また、本イベントに参加いただいたみなさんもありがとうございました。（完）
STORES では一緒にはたらくエンジニアを募集しています。採用サイトもぜひご覧ください！
