Kaigi on Rails 2024 協賛・参加レポート

こんにちは!ROUTE06 でソフトウェアエンジニアをしている @sasamukuです。

Kaigi on Rails 2024 に参加してきましたのでレポートをお届けします!

前回に引き続き、ROUTE06 は Silver Sponsors として協賛させていただきました。

弊社からは4人のメンバーが現地参加しました!

参加レポート

@MH4GF

- Kaigi on Rails は二度目の参加、オフラインは初
- Software Engineer
- Rails 歴は5年ほど

今年もKaigi on Railsに参加し、初めてオフラインでの会場を体験しました。あちこちからRailsに関する話題が飛び交う場はやはり貴重で、Railsへの熱意を肌で感じることができました。 また公式の懇親会にも参加しました。過去に一緒に働いた方々と久しぶりに再会し近況を語り合うことができましたし、新しいつながりも広がりました。このような機会が用意されているのは本当にありがたいです。

運営の皆様や登壇者の皆様のおかげで、とても充実した1日を過ごすことができました。お疲れ様でした、そしてありがとうございました!


@hoshinotsuyoshi

- Kaigi on Rails 3~4回目?の参加・オフラインは初
- Software Engineer
- Rails 歴は8年ほど

1日目はオフライン参加、2日目は家族の小学校イベントとカブったためオンラインでの部分的参加になりました。Kaigi on Railsはいつもオンラインでの環境が充実していてありがたいです 🙏 また、個人的には首都圏での開催はありがたいです。企業ブースは個人的にはいつか出展したいなと思っており、興味深く眺めていました。大盛況で、今年も抽選だったそうで、各社熱がこもっていました。


@ynndino88

- Kaigi on Rails 昨年に続き2回目の参加
- Community Manager / People Relations
- Rails 書いてないけどRailsエンジニアさん大好き歴は2年ほど

今年も圧倒的熱量でとても楽しい時間を過ごさせていただきました!!

1日目セッションの「推し活としてのrails new」ではお困りごとからプロダクトが生まれ育つ過程を小気味よいテンポで紹介されており、エンジニアさんが周りの人たちをハッピーにする様子をしみじみと感じ、やっぱりエンジニアさんすげぇ〜〜とこの業界でお仕事させてもらうことに改めて誇りを持てました...!

また、「デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜」ではなかなか見れない他社様の障害のケースを見せていただき大変感謝です🙏自分より先輩ばかりの環境でも、気になったことは臆せずに聞いて・伝えてみようという、シンプルだけどとても大事なシメに大きな拍手を送らせていただきました。

このように非エンジニアの自分でもプロダクト開発の流れやチームのあり方、さらにエンジニアリングの考え方や手順についてキャッチアップできるのがKaigi on Rails(以下: KoR)のありがたいところだなと思っております。ブースでもさまざまな企業の方とお話しさせていただき、これまで解像度の低かった企業様について色々しれたのもよかったです✨

何よりも、去年のKoRぶりにお会いできた方や、沖縄でのRubyKaigiぶりにお会いできた方と近況を語れたのが嬉しかった〜〜😌 所属先や打ち込んでいる事業・プロダクトが変わってもフラットに楽しくお話しできる場として、枠組みを超えた交流ができるのがKoRだな〜とひしひしと感じました。運営の皆様、スポンサード企業の皆様に心よりのお礼を申し上げます!!

懇親会では、初めましての方やXでよくお見かけするあの方...!とたくさんお話しさせていただき、新たな#RubyFriendsの輪が生まれて幸せな気持ちでした🫶 本当にありがとうございました!二日目は家庭の事情で参戦できずでしたが、たくさんパワーをいただきました❤️‍🔥

改めて運営の皆様、登壇者の皆様、スポンサー企業の皆様、そして参加されたすべての皆様!おつかれさまでした!また来年お会いできますように🙌


@sasamuku

- Kaigi on Rails 初参加
- Software Engineer
- Rails 歴は2年ほど

RubyKaigi は過去に参加したことがあり Ruby コミュニティの雰囲気は知っていたものの Kaigi on Rails もそれに違わぬ高い熱量がありました!RubyKaigi は言語そのものをテーマに扱いますが、Kaigi on Rails は実務寄りの内容が多く、明日からの開発に活かせる知見を持ち帰ることができました。

懇親会や Drinkup ではたくさんの方々とお話できとても貴重な時間になりました。私が所属するチームでは新規プロダクトを開発中であるため、そのサービスに対する所感やアドバイスをいただくこともできました。お話してくださった皆さんありがとうございました!

セッションレポート

Keynote: Rails Way, or the highway

speakerdeck.com

palkanさん による基調講演 Rails Way or the highway に参加しました。

トーク内容は、「Rails Way」から逸脱せずにどこまで行けるか?Rails Way の基本やその進化、階層的設計を通じた応用と強化方法について考察するものでした。設計パターンの習得から、他のライブラリや独自のビジネスロジックを取り入れるのではなく、Rails自体を拡張するアプローチが示されていました(参照ページ)。このページに示された4つの原則は非常に重要だと感じ、実践例も具体的でわかりやすかったです。アーカイブ動画が公開されたら、ぜひ再度見たいと思います。(余談ですが、東京住まいの私としては、東京の車窓(会場近くのゆりかもめかな!)が背景動画になってるスライドがとても楽しかったです!🚝)

Report by @hoshinotsuyoshi

Capybara+生成AIでどこまで本当に自然言語のテストを書けるか?

speakerdeck.com

capybara-playwright-driver の作者の方による、生成AIを活用した自然言語テストの実現性についてのトークに参加しました。

トーク内容は、

  • 前提条件(additional_instruction部分)として、自然文でWebサイトの概要を入力
  • 個別のテスト内容(it部分)も自然文として入力

といった形で、これだけでE2Eテストが実行できるのか? という仮説を元に実証されたものでした。

こんなことができたら面白いと思いませんか?

(以下のコードは README.md より引用)

before do
  # ...
  page.driver.additional_instruction = <<~MARKDOWN
  * このページは、3ペイン構造です。ユーザが仕事を探すためのページです。
  * 左ペインには仕事の絞り込みができるフィルター、中央ペインが仕事(求人)の一覧で、30件ずつ表示されます。
  * 左ペインにマウスを置いてスクロールしても、中央ペインはスクロールされません。一覧をスクロールしたいときには、中央ペインの座標を確認し、その中央にマウスを置いてスクロールしてください。
  * 右ペインは、広告エリアです。検索条件に応じた広告が表示されます。
  MARKDOWN
end

it 'should work' do
  page.driver << <<~MARKDOWN
  * 仕事の一覧が表示されたら、左ペインでサーバーサイドエンジニアで「Ruby on Rails」の仕事に絞り込みをしてください。
  * 左ペインで絞り込んだら、中央ペインにRuby on Railsに関する仕事が表示されていることを確認してください。
  * Ruby on Railsに関係のない仕事が、検索結果件数の半分以上あるばあいには、このテスト「検索結果不適合」として失敗としてください。
  MARKDOWN
end

it部分では、画面上の要素位置などを自然言語で記述し、CSSセレクタなどの技術的な指定は不要という点がユニークです。

さらに興味深かったのは、誤ったタブを一時的に選択してしまった場合でも、Capybaraが自律的に誤りに気づいて、正しいタブを再選択しようとする挙動を見せたことです1

もしこれが実現できれば、サイト構造が多少変わったとしても、入力する自然文を変えずにテストを継続できる可能性があります。また、そこまでいかなくても、テスト実行時のCapybara DSLや入力内容を保管しておけば、将来的には自動テストスクリプトの生成ツールとしても活用できるのではないかと思いました。

Report by @hoshinotsuyoshi

モノリスでも使える!OpenTelemetryでRailsアプリのパフォーマンス分析を始めてみよう

speakerdeck.com

OpenTelemetryをRailsアプリに導入する実践的な方法を解説するトークでした。必要なgemの導入とinitializerの設定だけで始められ、トレース機能を使ってパフォーマンス問題の特定が容易になることをデモを交えて説明されていました。分散トレーシングの強みはテレメトリの関連付けということで、デモでもボトルネックの特定後関連するログに即座に遷移する様子を紹介されており、これはすごいぞ!と改めて感じました。私の所属するチームでもOtelの導入を進めているため、アーカイブ動画が公開されたら改めてチームメンバーにも紹介したいです。

Report by @MH4GF

推し活のハイトラフィックに立ち向かうRailsとアーキテクチャ

speakerdeck.com

ハイトラフィックなグッズ販売システムで、どのように在庫管理・決済を実現しているのかを貴重な知見を学ぶことができました。1レコードにアイテム ID と在庫数を持つのが一般的な設計ですが、一斉に購入者が集まる状況下では行ロックによるタイムアウトが頻発してしまいます。TwoGate 社では、1在庫1レコードという斬新なテーブル設計によりこの問題を回避していました。そんなアイデアがあるのか!と脱帽する思いでした。また、外部決済SaaSのレートリミット問題に対しては「正しく諦める」ことでユーザビリティをしっかりと確保していくという決断をされていました。苦悩の末に導いた現実解という印象がして非常にリアルでした。

Report by @sasamuku

Data Migration on Rails

speakerdeck.com

Rails におけるデータマイグレーションの選択肢を整理した上で、選定のポイントをまとめられていました。個人の経験としては rake task を実行することがほとんどで、たまに SQL を直接実行することもありました。それ以外の手段を考えたことがなかったので、db:migrate や専用 Gem があること、それらの pros/cons を学べたことが貴重でした。Shopify が開発している maintenance_tasks gem はタスク作成だけでなく管理画面も提供しており、個別にワークフローエンジンを導入しなくてよいのが魅力的でした。

Report by @sasamuku

終わりに

Rails コミュニティの温かさと活気を肌で感じた2日間でした。ここで得た知見や繋がりを大切にしながら、これからも日々の開発に取り組んでいきたいと思います。そして、新たな知見をコミュニティで共有することで、Rails をさらに盛り上げていきたいですね!

カンファレンス開催にあたりご尽力いただいた運営スタッフの皆様、そしてイベントに協賛いただいたスポンサーの皆様に心より感謝申し上げます。

来年の Kaigi on Rails でまた皆様とお会いできることを楽しみにしています!