Kaigi on Rails 2024、お疲れさまでした！STORES からは18名（＋託児サポートとして4名）で参加、hogelogがランチタイムにワークショップをしたり、ykpythemindが登壇しました！ ゴールドスポンサーとして託児サポートを提供したり、女性Rubyist向けのランチイベントとしてSTORES CAFE for Women at Kaigi on Rails 2024も開催しました。
このブログでは、参加した各位が印象に残ったセッションについて感想を述べます。
印象に残ったセッション
hogelog
Rackを理解しRailsアプリケーション開発の足腰を鍛えよう
自分の実施したRackワークショップが一番印象に残っています。そういう話じゃないだろうと言われるかもしれない。
多くのRailsエンジニアがよく触れているが「実際Rackとはなんなのか」の認識がフワッとしていることも多いRackについて、手を動かしながら理解するワークショップを実施しました。
私のワークショップは「Rackとはなんなのか」伝える内容でしたが、Kaigi on Railsの他のセッションを見回すとRackサーバの内容について詳細に伝えるものがあったり、Rackミドルウェアとして動くライブラリの詳説であったり、カンファレンス全体でRailsを取り巻く様々な世界が伝わってくる良いカンファレンスなのではないかという気持ちになりました。Organizerのみなさんありがとうございました！
都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」
最近Rackサーバのパフォーマンスチューニングについて気持ちがのっているのでとても楽しく聴けました。漠然とした「IO待ちが多いアプリケーションならpumaを使うと高いパフォーマンスが期待できるよね」ぐらいの認識からだいぶ精度をあげられた気がします。
rails/rails#50450 の紹介といったフレームワークやライブラリのコア作者の考えが伝わるIssueの紹介など、多岐にわたって話が楽しい発表でした。
Shia
Keynote: Rails Way or the highway
1 to IPO、難しいのね〜という点では自分でもすごく思うのですが、その一つに回答を提示されてとても興味深かったです。もし実践したい、となるのであれば Rails の学習するという言葉の意味もだいぶ変わってくる気もするし人々がこれをどう受け入れていくのか楽しみですね。
phayacell
cXMLという電子商取引のトランザクションを支えるプロトコルと向きあっている話
cXMLという知らないプロトコルの話を聴いて、もしかしたら今後 STORES ネットショップ で役に立つかもしれない……というか商取引で苦いこと多すぎない？という気持ちになりました。 大ボリュームの仕様書、それでもはびこる各社の独自仕様、汎用的に使われるべく作られたgemさえも仕様漏れ。 戦ってきた多くの課題を共有してもらえて、勉強になりました。
Rails APIモードのためのシンプルで効果的なCSRF対策
もうトークンじゃない方法で検証できるのか！とびっくりしたセッションでした。 いまちょうどそのあたりについて調べなくちゃな〜と思っていた頃合いだったので、このセッションを聴けて本当に良かったです。 こういう仕組みって、一度作って運用が始まると（脆弱性が見つかったりしない限りは）なかなか変わらないもので、知識のアップデートが遅れていまた。 こうやるのが当たり前だ、って思っていることでも、ちゃんと調べて、よりシンプルで確かな方法がないかを見てみるべきだな〜、と思い改めるセッションでした。
Cache to Your Advantage: フラグメントキャッシュの基本と応用
キャッシュの気持ちが全然わからない状態だったのですが、このセッションを聴いて、ちょっとだけわかった気持ちになれました。 ActiveRecordではかなり良い感じに使えそうだったので、Mongoidの対応状況を調べてみなくちゃ。
OmniAuthから学ぶOAuth 2.0
普通に使うだけの開発者からしてみれば、隠蔽されていてなにがなんだかわからないうちにid_token, access_tokenが取得できるOmniAuthについて、こういう仕様でこう動いているんだよ〜っていうのをかんたんに理解できるセッションでした。 別のセッションでも言及されていましたが、中身がどうなっているかわからないけどとにかく機能させてくれるgemの中身を理解することで、カスタマイズせざるをえないときの力になりますし、カスタマイズが不要でも安心して使うことができるようになるので、知っておいて損はないな〜と思いました。
約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり
とにかく物量。 Flakyテストの改善方法テクニックもありましたが、どうしてもなくならないものはあるのでリトライ間隔を増やして再実行させる話もあり、やっぱりそういうだよな〜とかなしい気持ちに。 テスト高速化の取り組みも具体的な事例を示してくれたので、とても参考になりました。 逆に、こういうテストは遅くなるぞというアンチパターンの整理にもなった気がしています。
Sidekiq vs Solid Queue
Solid Queueくん、エアプだったのでとにかく情報を知れてよかったセッションです。 いまもっとも使われているSidekiqに対してどのようなメリットがあるのか、SidekiqではなくSolid Queueを選ぶ必要があるのはどういったケースなのかの一例を示していただけたので、今後の参考になりました。
Data Migration on Rails
最近、大規模なデータ移行プロジェクトをやったので、セッションタイトルに惹かれて聴いてみました。 わたしのやっていたデータ移行とは違って「データ修正」に関するものだったので当初の期待どおりではなかったですが、とても示唆深いセッションで感銘を受けました。 データ修正と一口に言っても方法はいくつもあり、それぞれにPros,Consがある。 しかも、Railsのバージョンアップによって示されていた事例に変化があったり、コミュニティの中でも流行り廃り（というか危険性がわかってみんな避け始めた？）があったり、しっかりとした調査とはこういうものなのだな〜と勉強になりました。
サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話
packwerkと言えば、依存性の排除という印象があったのですが、そうではないための使い方のセッションで印象に残りました。 あ〜あるある〜、と思うような認可ロジックの散在に対するアプローチとしてpackwerkを選定しており、その導入までの道程が示されていました。 セッションを聴いているだけではpackwerkでなくちゃいけない理由を腹落ちさせるところまではできませんでしたが、使い方のひとつの事例として勉強になりました。
Identifying User Identity
とても身近なUserについて、いろいろな気付きや感銘を受けたセッションです。 なるほどcredentialsはこうして分離することにメリットがあるのか、という部分は本当に強く印象に残っています。 Userは「いた」というアイデンティティを示すだけで良く、それに付随する情報はUserの周辺情報として切り分けられる。 その構造のおかげで、カラムのひとつとして状態を持たずともUserの状態を判別することができる事例が出てきたときにはめっちゃテンションが上りました。
ryoh827
Identifying User Identity
Userテーブルの設計及びデータの取扱についてなるほどな〜という納得感があり、早速使ってみたいなという気持ちになった。 そして、じゃあ STORES ネットショップ のMongoidだとどうするのかな〜など考えたりなど、色々と新たな気づきを得られました。
otariidae
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜
失敗談がこのような場で話されることで誰かの転ばぬ先の杖になるのって良いですよね。 軽い語り口で楽しく聞けました。
推し活としてのrails new
自分のつくったものが誰かの役に立つ尊さを再認識できて良かったです。
yaoyoshi
Rails APIモードのためのシンプルで効果的なCSRF対策
CSRF tokenを扱うのシンプルなCSRF対策の知見を得ることができて良かったです。これまでトークン方式が使われているのか？という背景理解もでき、新しいプロジェクト等で取り入れやすい内容だと感じました。
Sidekiq vs Solid Queue
STORES 予約 ではSidekiqを利用しているが、Rails 8.0でデフォルトとなるSolid Queueとどう付き合えばよいか？がわかる内容になっていて良かったです。しっかり比較が提示されており、どういうメリットが有るときに使えばよいのか、既存のSidekiqからの移行の必要性は？というところにも言及されており、Rails 8.0がリリースされた際に、自分たちのプロダクトもSolid Queueを使えば良いんだろうか？という問に対して参考になるセッションでした。
OmniAuthから学ぶOAuth 2.0
プライベートでGoogleでログインの仕組みを作ったことがあったのですが、改めてその裏側の仕組みについて復習するいい機会になりました。発表の最後で紹介されているTipsも実用的で好きです！
Data Migration on Rails
本番環境でのデータ移行に関するセッションでした。データ移行の方法をメリデメ付きで整理してあり、自分たちが普段行っているデータ移行はどれだろう、その方法のリスクについて考えるいいきっかけになりました。SmartBankさんでどういった意思決定を行ったかの紹介も非常に参考になり、改めて自チームでも合意形成し、記録を残すといいかもしれないと感じました。 maintenance_tasks という仕組みも紹介されており、後日試してみようと思っています。
nissy
Sidekiq vs Solid Queue
Solid Queueについて何も知らなかったですが、Sidekiqとの比較が丁寧にされていてとてもわかりやすかったです。Sidekiqと比較したメリット、デメリットが挙げられていたので、STORES のプロダクトの場合はどちらが適しているんだろうか、というのを聞きながら考えられて楽しかったです。
カスタムしながら理解するGraphQL Connection
業務でGraphQLをさわる機会はありますが、そういえばConnectionについてちゃんと理解していなかったなと気づけました。ページネーションは確かに工夫が必要そうな気がしたので、どこかのタイミングでCustom Connectionを実装してみたいなという気持ちになりました。
ima1zumi
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
こうやってタイトルを書くと、タイトル通りの話だったなぁという感慨があります。
自分の解釈では、「つよいプログラマ」を構成する部品を改めて見せてもらい、そこに至るレールを敷いてもらった話だなぁと思いました。自分は強いプログラマというのは手札を多くもっていて、環境や制約に応じてもっとも価値を出せそうなカードを選べる人のことだと思っています。また、手札が多ければ手札同士を比較することができるので別の案も検討できてより問題に対しての解釈を深めることもできると感じます。その手札を増やすにはどうしたらいいのかというと、知識を蓄えてと審美眼を鍛えようという話だったんだろうと思いました。たくさんのことに触れて、手を動かしていきたくなる活力をもらえる話でした。
ko1
Ruby on Railsをよく知らないので、セッションを聞く手前でわからんことが多くて難儀しましたが、わからないなりに、なるほどこういうのがあるのだなぁ、などと思って聞いていました。横にプロフェッショナルな人を置いて色々わからないことを聞きながら聞いてみたかった。もう少し常識を勉強してから次は臨んでみたいですね。あと、体調が悪くてすぐ咳きこんでしまって、全部通しで聞けたセッションが少なかったのは残念でした。
フィロソフィー的な話は「せやな」で終わってしまって、あんまり乗れないんだよなぁ。でも、そういうのを繰り返していくことが大事なんでしょうね。
hiromu
Tuning GraphQL on Rails
ここ最近、GraphQLを使用した開発プロジェクトに関わることが多く、他社がGraphQLのパフォーマンス改善にどのように取り組んでいるのか気になっていたので、今回発表はまさに自分にとってドンピシャな内容でした。発表内容は実践的で、すぐに自分の開発に取り入れられるものばかりだったので、今後の開発に積極的に活用していこうと思っています。
なつめ
Data Migration on Rails
アプローチのポイントが整理されており、自分はこの形でmigrationするのが良い、と思っていた内容が言語化された内容で腑に落ちた発表でした。 過去のディスカッションや自社での意思決定の流れなど、網羅性と整理がとても丁寧であり参考になりました。
Sidekiq vs Solid Queue
普段から馴染みあるSidekiqとの対比であることでSolid Queueの旨味がスッと入ってくる内容でした。
そしてSidekiqはお金はかかるがリッチで大きなサービスを運営するにあたっては非常に便利なことを理解できました。「SidekiqをActive Jobをかませずに直に使っていくぞ！」という気持ちになっています。
tommy
Tuning GraphQL on Rails
GraphQLは今仕事でも使っているので参考になるなと思って聞いていました。 N+1対策のところなど、似たような対応をしているところを感じたり、別の手段との比較などわかりやすかったです。 メトリクスに関しての部分も、他社の事例を聞いてもう少し改善できる余地があるなと思ったので、見直してみたいなと思いました。
Identifying User Identity
「User/ユーザーとは」というところの問題提起からはいり、具体的な実装例を提示してもらっていてすごくわかりやすい発表でした。 ユーザーにまるわる情報をどう整理して、どう分離していくべきか、というところに着目して考えていくことが、 サービス体験としてよりよいものになりつつ、システムとして扱いやすくなるということを感じ、参考になる発表でした。
ahogappa
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
最後の最後で完全にやられてしまいました。設計の話や未来のための変化の余地の残し方などを丁寧な語り口で解説していました。 楽しむことがビジネスやプロダクトづくりにおいても必要なことであるという話を聞いたときに、最近の自分に突き刺さるところがあり、なんかこう泣きそうになりました....。 そして本屋さんでサインをいただいたのですが、「楽しみましょう」と書かれており、ここにつながったのがさらに印象的でした。 改めて、楽しむことを忘れずにエンジニア活動していきたいと思いました。
ykpythemind
OmniAuthから学ぶOAuth 2.0 で発表しました。ある意味印象に残ったセッションは自分ので、30分人前でトークするの初めてだったので、思ったより喉乾いたりなど新鮮でした。
見たセッション全部おもしろかったので、Railsでものづくりする気持ちが高まっています！
11/14（木）19:00〜『STORES.rb Railsのはなし』
今回Kaigi on Rails 2024で登壇したykpythemind、ワークショップをしたhogelogと他2名のエンジニアがトークをするイベント『STORES.rb Railsのはなし』を STORES オフィスで開催します。STORES からの発表内容は下記を予定しています。ぜひご参加ください！
- 『RubyのWebアプリケーションを50倍速くする方法』
- 『graphql-ruby エラーの設計と実装』
- 『Custom Cop を用いて 保守可能な Railsアプリケーションを作成する取り組み』
- 『STORES サービスを跨いだシングルサインオンのためのテクニック』
Kaigi on Rails 2024 オーガナイザーのみなさま、素敵なカンファレンスをありがとうございました！来年も楽しみにしています！
