参加しました。
普段の仕事では主にGo/TypeScript/Reactあたりを書いています。Rails周辺のぼんやりとした世界観は知ってるかも、ぐらいの立場です。
よかったトーク
推しVTuberのために匿名質問サービスを高速に作り、仲間を集める、という流れが非常に美しく、懐しさすら感じさせる発表でした。こういう勢いをたぶん失っているんだろうな、とも……。
どこのプロダクトでも長時間の非同期ジョブに悩まされているのだ、と知れて勇気づけられました。非同期ジョブの実装側でlong-runningなジョブを中断・再開できるようにする仕組みは面白かったです。一方で、ジョブをじゅうぶん小さな単位に分割して並列実行したのち結果をマージする、といった手法も考えられないか？ と思い、そのあたりを懇親会で議論できたのでよかったです。
スループットを上げるために1行1在庫で管理する、逆に決済システムのレートリミットを考慮してスループットをあえて下げるなど、正しくパフォーマンスと向き合っている、と感じました。1行1在庫だと行数が爆発しないか？ と思ったけど、一時的なイベントなら不要になった行は消せるし、200万在庫をさばいた実績がある、とのこと。
ActiveJobやSidekiq、そしてSolid Queueができるまでの歴史の話が面白く、TheSchwartzやFireworqを使っているプロダクトが身近にあるのでなかなか遠くないところの話のようにも感じました。最近だとAWS SQSを使った仕組みを手作りするなどの事例があるのですが、「非同期処理」と一口に言ってもいろいろあるし、Sidekiqのwikiを一度読んでおくといいんだろうな、と思いました。
データマイグレーションの決定解みたいなの、Rails界ならあるでしょって勝手に思っていたけど意外とまだないんですねえ。手元からスクリプトを打ってデータを修正した経験は自分もあるけどいまいちだし、かといって最強の仕組みを作るほど手をかけづらい場合もあって悩ましい。サーバーレスかつ安全にonetimeスクリプトを実行する最強の環境セットがあるといいのか？？
最終日の基調講演です。修復とは元に戻すことではなく変化に適応しつづけること、という言葉が目から鱗でした。これはフレームワークもそうだし、長寿プロダクトとかにも言えることになりそう。
Railsエンジニアじゃない立場から見た「Rails way」
冒頭で述べたように、普段はサーバーサイドの実装言語としてGoを使っています。昔はPerlも書いていました。
Railsに対して、やっぱり道具がひと通り揃っているのは強いだろう、ということをよく思います。重厚よりは簡素なフレームワークを選び、足りない道具があれば自分で実装する、というのを仕事でよくやっているのですが、一方でRailsの方を見て、こういうのは数行ぐらいで完成するんだろうな*1……と思うことは少なくありません。密結合で高速に走れる、という言葉を耳にしたことがあります。
一方で、Rails wayにうまく乗れないと気持ちのいい開発体験が損われがちで、そのあたりのノウハウが模索されている部分もあるんだろうな、とも感じました。モデル設計やHotwireなど、うまくハマるといいけどちゃんと考えないと苦しくなる面はありそうで、Railsだから思考停止でいい、ということはなさそう。「隣の芝は青い」みたいな感じで、どこにいてもちゃんと考えてプロダクトを作っていかないといけない、ということですね。
今の仕事にRails wayをそのまま取り込めるかは分からないけど、ある種のヒントは得られたかもしれません。とくに、最後の基調講演での話はRailsと関係なく普段から意識できるとよいのだろうな、と思いながら聞いていました。
おわりに
Railsは普段書いてない、という立場で参加しましたが、けっこう学びになるトークが多かったと思います。見れていないトークも興味深そうなものがいくつかあるので、資料を見返しておきます。一方、もっと深掘りできるとよさそうだけど15分トークだとギリギリすぎるか、ということも思ったので悩ましいですね。
来年も何もなければ参加します。会場が東京駅直結になるっぽくてすごい。
写真コーナー
🙃 #kaigionrails自分だけ撮影してそうな写真展 pic.twitter.com/FMJBCH7Rg4
— うたがわきき (@utgwkk) 2024年10月27日
*1:実際には数行では済まないかもしれないけど
