見出し画像

mov と Kaigi on Rails 2024

movでEngineering Managerをしております、南谷(みなみや) @yuki3738 と申します。2024年10月25日、26日に開催されたKaigi on Rails 2024にエンジニア有志数名で参加してきました。

movとしてはGold Sponsorに協賛、2日目の夜にDrinkupを開催しました。
そしてエンジニアの@kaibaこと海馬沢が登壇しました。本記事では参加メンバーによる感想を綴ろうと思います。

会場

今回の会場は有明セントラルタワーホール & カンファレンスでした。

まだ新しい施設の用でかなり綺麗でした。良い会場でしたね〜。
特筆すべきは「わいわい部屋」と呼ばれる部屋で、参加者が交流できる部屋を用意してくれていました。ここではおぎじゅんさんによるコーヒーも提供されていて、とても居心地の良い空間でした。

ホワイトボードなどもあって交流のための工夫を施してくれていました。

movから@kaibaが登壇しました

movからは@kaibaが ActionCable なら簡単? 生成 AI の応答をタイピングアニメーションで表示。実装、コスト削減、テスト、運用まで。 というテーマで発表してきました。
Rails で ChatGPT のような文字が流れていくアニメーション(タイピングアニメーション)を実現するには、LLM の応答が Server Side Events で得られるので、それを ActionCable で送ればいいのですが、多くのハマりポイントがある、という内容でした。

口コミコムでは口コミを様々な条件で絞り込み、LLMで要約する機能があります。多くのお客様から定期会議のレポート作成の手間がなくなったと好評いただいております。 大量の口コミデータを要約する必要があるため、生成完了を待つと時間を要してしまい、耐えきれずリロードしてしまい、無駄にお金だけ掛かるという懸念がありました。そこで本発表で紹介したようなタイピングアニメーションはとてもよいUXになりました。
資料はこちらになります
簡単に動作するサンプルコードも公開していますので是非お試しください。

各位、印象に残ったセッションの紹介と感想

@kaiba

印象に残ったセッション: 約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話

mov も似たような状況にあり、カバレッジはいいものの、テスト時間はかかるし、Flaky test もあります。
銀の弾丸はなく、泥臭く対応し、計測し、改善するを繰り返していますが、非常に丁寧に計測されています。「なんとなく速くなった」ではなく、どの対策がどれくらい貢献したか調べて効果度合いとしてまとめているのが素晴らしいです。 本発表では Capybara を使った sysytem spec の改善が多く挙げられているのに対し、mov は system spec はあまりなく、ビジネスロジックの spec が充実していますが、活かせるポイントは多くありそうです。
このプレゼンがきっかけかどうかわかりませんが、先程 yuki3738 が突然2分のspecを2秒に縮めるspecを出してきました!

fujiwara

印象に残ったセッション: 作って理解する RDBMSのしくみ

数ヶ月前にパフォーマンス・チューニングしたときのことを思い出しながら聞いておりました。
indexの種類を調べたり、RDBMSの気持ちになってindexを使って内部的にどのように探索されるのかを頭の中でイメージしていたりしました。
チューニングするときの一番役立ったことは、どのように探索するとよいかを単純化した構造でいいので自分でイメージできることでした。
本発表ではそれが詳しく図示されていて、視覚的にわかりやすく知識の定着が進みました。
ありがとございます!

takemura

印象に残ったセッション: 現実のRuby/Railsアップグレード

Railsアップグレート作業で起こった際のトラブルのみならず、ビジネスサイドや経営側とのやりとりなど、日頃の業務にも通ずる話もあって、とても参考になりました。
アップグレートは直結的に利益に繋がらないため、ビジネスサイド的には優先度が下がってしまいがちですが、セキュリティ面やパフォーマンス改善においての重要性について、エンジニアの説明責任があるというお話しをされていて、身に詰まる思いで聴いておりました。

miyachi

印象に残ったセッション: Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?

自分がQAエンジニアであることもあり、生成AIを活用したテスト自動化の仕組みには非常に興味を持ちました。特にテスト作成から実行までが自然言語でできるようになると、テストにかかる手間が大幅に削減され、日々の業務が楽になると感じました。ただし、このシステムの精度がさらに向上し、実用レベルに達するようになれば、テスト自動化が進みすぎることで、QAエンジニアとしての仕事が不要になるのではないかという不安も抱きました。
一方で、以前から感じていた「テストのメンテナンスにかかる負担」という課題を解決する可能性がある点は、技術的な進歩を実感し、わくわくしました。AIを活用した新しいアプローチが実現すれば、テスト自動化の進展によってさらに高い効率化と正確さを追求できる未来が開かれるのではないかと期待しております!

yamada

印象に残ったセッション: Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング

Rails初学者でもわかりやすく、かつ中級者以上のレベルでも非常に参考になるセッションでした!
内容としては「Rails Wayに乗り続けるメリットと方法」を写真や実際の例をあげて説明してもらいました!
特に印象的だったのは「Service層のような新しい層を入れるのは相当な覚悟を持って挑む作業」と説明していたことです。
今まで私はapp配下にレイヤー(層)を追加するのは容認派でしたが
確かに今までの現場でもレイヤーが増えることで、この場合はmodels?forms?commands?serializers?とどこに書くか悩むことがあったことを思い出し
役割(レイヤー)を増やしすぎないことで、Railsの良さでもある密結合(modelsにある様々な役割を集約している)メリットを発揮していくという言葉に強く共感できました。
その他にもformsクラスを作るときのタイミングや方法などの話もあったので
ぜひ皆さんにもアーカイブを見てほしい超おすすめセッションでした

horiuchi

印象に残ったセッション:[Sidekiqで実現する 長時間非同期処理の中断と再開 / Pausing and Resuming Long-Running Asynchronous Jobs with Sidekiq - Speaker Deck]

こういった発表ではスゴイ人がスゴイことをやってるなーみたいに聞いてしまうことも多いのですが、こちらのセッションは、決して魔法のようなことをしているわけではなく、停止前の進捗状況を保存しておき、中断したところから再開する処理を書いていくというお話で、とてもわかりやすかったです。 一見どうやるのかわからないような処理でも、愚直に一つ一つ自分で実装していけば実現できるという気付きがありました。

@yuki3738

印象に残ったセッション: Hotwire or React? 〜Reactの録画機能をHotwireに置き換えて得られた知見〜

DHH信者であり、Javascriptに嫌われていてReactに挫折した私はこういった事例を砂漠の中でオアシスを求める遭難者のごとく求めていました。実際、「管理画面程度の少しリッチにしてあげると使いやすいよね」程度のUIにはもう絶対Turboが良いだろと考えています。
こちらのトークはTurboを使うための考え方を捉え直し、結果的にstimulusも上手に使うことができ、Reactの実装を置き換えることに成功するとこまでの顛末の話でとても楽しく聞かせていただきました。Hotwireの思想をしっかり理解することによって、ある程度のUIはReactより簡潔に実装可能というお話でした。
とはいえReactよりHotwireの方が優れていると言うわけではなく、大抵のことはHotwireでできるがより複雑でリッチなUIにはReactだよね、適材適所だよね。とまとめられていました。最近Xではフロントエンド界隈の人にRailsが下げられていて心が傷んでいましたがとても癒やされました。
Tsujitaさんのトークでは昨年の大場さんのトークが言及されていました。これは大場さん嬉しいだろうなぁと思っていたらやっぱり喜ばれていました。

大場さんとは公式懇親会で少しお話できたのですが嬉しすぎて大興奮!な、お顔がとても印象的でした。

そして翌日の大場さんのトークで早速Tsujitaさんのトークが触れられていました。Rubyistの繋がりを見ることができてとても胸が熱くなりました。

最近めっきりコードを書く時間が減ってTurbo, stimulusを書く機会は全然ないのですがキャッチアップ・習熟を頑張らねばと思わせてくれるトークでした。

@yaboojp

印象に残ったセッション:Identifying User Idenity

個人的に一番エモかった。
ユーザーのidentityは存在することで、それを表現するのは主キーとtimestampだけのレコードが存在することで表現できる、と。

これを自信を持って主張するに至るには、数々のプロジェクト・プロダクトにおける経験を踏み台にした悟りにも似た凄みを感じた。


「ユーザーは必ずemailを持ってるのでそれでパスワード認証するからUserにemail/passwordカラム追加でOK!」
「状態はそんなに増えないからUserにAdminフラグのboolフラグを付けとけばOK!」
自信を持ってこう言えるから、とUserテーブルをどんどん拡張したことは誰しもがあると思う。
そして幸いにも(不幸にも?)ビジネスが伸び、その自信に反してどんどん複雑化するビジネス要件、Userテーブルはただただ肥大化してビジネスロジックも複雑化して絡まっていく。そんなを屍を超えていこうという強い意思を感じた。
また、ユーザーの状態をstatusカラムではなく、事実ベースで別テーブルに残していくとSQLで状態を表現できるようになるという具体的な設計ノウハウもよかった。これも堅牢で変更に強いユーザー管理を実現できる道を示していて良かった。

関連エントリとしてはセッション中にjokerさんが自身でポストしてたものや、そーだいさんのブログにあるので合わせて読むと良さげです。

もう一本。
印象に残ったセッション: Data Migration on Rails

data migrationという地味なんだけど、サービス運用やDevOpsでは欠かせない大事なテーマにフォーカスを当てていてよかった。
というか、弊社もrails consoleによる実行が結構デファクトになってて課題感あったので各種手法の比較はただただ有益of有益だった。
data-migrate, data_migrator, migration_data…などなど gem名の類似品の多さには笑ったw
最終的に@ohbaryeさんのところではAirflowをベースにした運用をつくったとのことでしたが、maintenance_tasksがめちゃめちゃ良さそうだったので弊社での導入検討をリアルに考えようと思った。

各位の感想は以上です。改めて登壇者の皆様にリスペクトと感謝を。お疲れ様でした。

Day1 公式懇親会

すごく楽しかったけど全然写真残ってない!何故なのか…!

かろうじてあった日本酒の写真…。

南谷は久しぶりに前職のエンジニアとの旧交を温めていました。
温めすぎて会はあっという間に終わってしまいました!もっと大勢の人に絡みたかった!
スタッフの皆様準備から運営までありがとうございました!

Day2 mov DrinkUp

movは2日目のDrinkupを開催しました!
我々としてはメインのイベントと言っても過言ではない…!(幹事はいつも大変なのです)

ちょっとしたハプニングはありつつも、お店の協力もあって無事終わりました。別記事にてレポートしておりますので良かったらこちらもご覧ください。

まとめ

やはりRuby関連のカンファレンスは楽しいですね…(しみじみ)
movは今後ともRubyを始めとしたOSSのコミュニティを支援していきます。
お会いした際はぜひ仲良くしてやってください。

最後に

movではエンジニアの採用、絶賛強化中です!少しでも関心をお寄せいただいた皆様、カジュアル面談でぜひお話させてください!採用情報はこちら👇

いいなと思ったら応援しよう!