こんにちは!スマートバンクのサーバーサイドエンジニア koshiba です。
いよいよKaigi on Rails2024まで一週間と迫った10月17日に開催された、弊社CTO yuta と同僚 hirotea がオーガナイザーを務めるGotanda.rbの特別版 Reject on Rails 2024 に行ってきました。
今年のKaigi on Railsに応募されたプロポーザルはなんと193。このReject on Railsは惜しくも登壇の機会を逃された方に登壇してもらおうという会でした。いつもGotanda.rbに会場提供してくださるgifteeさんのイベントスペースには、8人の登壇者と特別ゲストKaigi on Railsオーガナイザーの大倉さん、そしてそのトークを楽しみに集まった50人以上の参加者という賑やかな会でした。
このブログでは当日のトーク内容を紹介します!
トーク紹介
【 LT① 】俺たちは雰囲気で scope をやっているけどもうちょっとなんとかならんのか? / tokai235
普段は関西で活動されていてGotanda.rb初参加なtokai235さんからは、Railsのscopeをclass methodと比較しながらscopeならではのメリットを解説。 scopeはメソッドチェーンでつなぐために、Active::Relationかnilを返すようにしようという利用上の注意点と、実際にmapやfilterで実装していたところをscopeに置き換えて、respose timeが1/2〜1/3改善した事例の紹介もありました。
【 LT② 】管理画面とユーザー機能の調和を取り戻す!クエリパフォーマンス改善の成功物語 / 大高光気
人生初登壇の大高さんからはDBのCPU使用率100%になってしまった問題に立ち向かった話でした。 100%になった原因は管理画面から発行されるクエリがDBのCPUが圧迫してしまっていたこと。ボトルネックとなるAPIを改修しつつ、max_execution_timeというMySQLのシステム変数を設定して100%になってしまうことを防ぐ方法を選択。SELECT実行のタイムアウト設定できるこの変数をどのように設定していったか事例の紹介でした。
発表中会場からはこんな声も。発表するとするとこういった関連する知見がもらえるところも嬉しいところですね。
Optimizer Hintsでクエリ単位でMAX_EXECUTION_TIME設定することもできるよᴖᴗᴖhttps://t.co/8Mj28lMI2I#rejectonrails
— Ryuta Kamizono (@kamipo) 2024年10月17日
【 LT③ 】created_at > ? のクエリを直感的に生成するactiverecord-pretty-comparator gemを作った / technuma
テーブルエイリアスの罠を回避できるgemを作ったtechnumaさん。
where(ends_at: (NOW + 1.second)...)
という書き方が直感的でないもののwhere('ends_at > ?', NOW)
だと、joinした場合、テーブル名を解決できない問題が出てしまう。このもやもやをかみぽさんに相談し、この実装とアドバイスを受け activerecord-pretty-comparator gem を作成するに至ったお話でした。綺麗に書けるし、テーブルエイリアスの問題を未然に防げる2つのことを1つの施策で解決できたところがお気に入りとのことです。
【 LT④ 】Active Recordの複数DB対応を活用して、Railsアプリケーションを統廃合する / フサギコ
これぞLTというライトニングなスピードで始まったフサギコさんからは10分間のトークで133ページの超大作。複数DB対応と言えば負荷分散と思われがちですが、今回は複数DB間のデータ移行とアプリケーション統廃合の事例でした。13の手順で進められた統廃合は、JST/UTCが混合してたり、トランザクションをどちらのDBで開いているかなど、はまりどころもありつつ、12と13について問題も解決しあとはやるだけ!のところまで辿り着かれたとのことで、ここまで聞いたら無事完了のトークも期待してしまいます。
【 Kaigi on Rails オーガナイザーセッション 】一人reject反省会 / 大倉雅史
ゲストトークとして今年1年で11本のプロポーザルを提出された大倉さんから、今後出す人予定に向けた人たちに向けて11本のプロポーザルそれぞれその時とったアプローチ、今思えばどうだったかの紹介でした。 プロポーザル書く時にまずは募集要項を読むことが大事。そしてトークの的を絞って、プロポーザルの分量は多く、そしてすでに実装しているなど成果を書くことがポイントだとまとめられてました。発表者だけでなく参加者の中にもリジェクトされた側の方もきっと多かったことと思いますが(私もです)これを聞いてまた次のプロポーザルにチャレンジしたくなった方も多いのではないでしょうか。
【 LT⑤ 】Rails に型を導入する 2024秋 / tk0miya
tk0miyaさんからは2024年のRBS進化について紹介。 RBS::InlineのVSCode拡張作り、発表ではデモも紹介され会場からは感嘆の声が上がっていました。型コメントがrubocopとコンフリクトしてしまう問題もあったものの、Rubocopへ初コントリビュートを果たしv1.67で解消されたとのこと。また、せっかく型コメントを書いたのにtypoのせいでただのコメントと解釈されてしまう悲しい事故を防ぐためのカスタムコップも作成されました。しかしこれで万事解決ではなく、Ruby自身、gem、Rails、DSLが勝手に作るものなどなどまだまだ型が不足しているので、これからも貢献を続けていく意気込みと不足を見つけたらLet's PRと呼びかけられてました。
デモはこちら
RBS::Inline と RBS helper を組み合わせると、こんな体験になります。 pic.twitter.com/q84nHl1FsZ
— tk0miya (@tk0miya) 2024年10月17日
【 LT⑥ 】複数の外部サービスデータの統合と変換を実現するRailsのインポートアーキテクチャ / END
初Kaigi on Rails CFP&初Gotanda.rb参加なENDさんからは、 Findy Team+ のデータインポートの紹介と、課題改善のために取り組まれた事例紹介。 複数の外部サービスのデータをインポートし、同じUIで可視化している裏側はクライアント、インポーター、トランスフォーマーの3層で構成されており外部サービスの差分を吸収しているものの、各層が密結合していたり、エラーハンドリングやリトライ処理が点在している問題を抱えていました。この問題に対し、各層の依存をなくし、責務が明確になるようにしていった過程を図解と共に紹介していただきました。
【 LT⑦ 】ActiveRecordの力でDBのメタデータを迅速に解析する / lni_T / ルニ
「仕様書書いていますか?」の問いかけから始まったlni_Tさんからは既存の資産をもとにDBの仕様書が作れないか取り込んだお話でした。 DBのスキーマからだけではわからないものに関しても、ActiveRecordに用意された各種機能を使うと定義を分析できることの紹介。そして100行程書けばモデル仕様の自動生成が可能なものの、100行書くのは大変だろうとDBの構造取得からドキュメント化してくれるschema_doctor gemを作成されました。今後はi18nから定義を拾ってDBドキュメントに反映させることを考えられてるそうですが、仕様書作成のユースケースも募集中ということで、会場からは「便利そう!」「ER図対応は?」などの声が上がってました。
【 LT⑧ 】今日で分かる!カスタムコップの作り方 / 寺井 省吾
寺井さんからはこれを聞けばカスタムコップが作れるようになるというカスタムコップの始め方のお話。 冒頭「カスタムコップ書いたことのある方〜」という質問に対し4分の1くらい手の上がった会場。 静的解析で解決できるような特有ルールはカスタムコップで解決しようと、実際に開発中にあった問題を解決しようと作った「参照形のアクションに対して、接続先をリードレプリカに変更するコールバックの書き忘れを警告する」カスタムコップの作成を例に6つのステップにわけて順を追って詳しく説明がありました。「あの問題カスタムコップを作れば解決するかも?」と浮かんだ方もいらっしゃるのではないでしょうか。
懇親会
意図せずDBとカスタムコップ祭となった今年のReject on Rails。終わった後の懇親会では早速トークの感想や質問、議論が活発に起きて時間が足りないくらいでした。名残惜しい気持ちを抑えつつ「また来週Kaigi on Railsで!」を合言葉に解散となりました。
今回スマートバンクはスポンサーとしてご飯の提供をしました。
gifteeさんからはオリジナルラベルのビールをご提供いただきました。
有明でお会いしましょう!
Kaigi on Rails 2024の2日目には弊社から ohbarye と osyoyu が登壇します。また、スマートバンクはGold Sponsorとして会場にブースも出します。楽しい企画を用意してお待ちしていますので空いた時間にぜひお立ち寄りください!
スマートバンクではサーバーサイドエンジニアを募集しております!どんな開発をしているかぜひブースでお話させてください!