nobo's blog

プログラミング、日常、etc...

Kaigi on Rails 2025 参加してきました

Kaigi on Rails2025に参加してきました。その参加レポートです。

1日目

高度なUI/UXこそHotwireで作ろう

speakerdeck.com

所感

Hotwire Anecdota でHotwireについて学びを深めたり、kamalを学ぶ際にzennの記事でお世話になっています。

以前はReactを使用して開発を行なっていたので、「複雑なUI/UXはReactじゃないと作れないよなぁ」という考えだったのですが、今回の発表を聞いて「いや、そんなことないな。なんならHotwireで作った方がjson管理しなくて良いしシンプル作れそう」と考えをアップデートすることができました。確かにjson管理大変だよなぁ。

また、HotwireでのStimulusやTurboがどのような範囲で使用されているのかを解説している資料が分かりやすいので、読んでみてほしいです。

個人的にはReactのone-way data flowをStimulusでも実現しようという考えが面白く、実現したいことはなんとなく見えているのですが、stateの管理がまだイメージできていないです。(value stateとZustandを理解すれば良さそう)

Railsアプリケーション開発者のためのブックガイド

speakerdeck.com

所感

「みんなが同じものを読める」「共有財」として書籍を活用できる。ということを含めて書籍を読んでいなかったので、新しい視点を得られました。

紹介された本は読んだことがあるものから、知っているものまで多くありました。

個人的には最近オブジェクト指向設計について興味を持っているので、「ドメイン駆動設計」や「実践ドメイン駆動設計」を読んで学びを深めようと思います。

Web Componentsで実現する Hotwire とフロントエンドフレームワークの橋渡し

speakerdeck.com

所感

Angular UIコンポーネントWeb Componentsで橋渡しにすることで、Rails Hotwireとして導入することでができることがわかりました。

実際の例を踏まえての解説がとてもわかりやすく、「ユーザー入力を連携するもの」の段階的なアプローチが学びになり、さらにWeb Componentsの理解が深まりました。

今後はReact, VueのUIコンポーネントをWeb Componentsを橋渡しにして実装するのを試してみようと思います。

あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』

speakerdeck.com

所感

去年に引き続き、自然言語Capybaraドライバの開発について聞くことができて楽しかったです。

以前はスクリーンショットから入力フォームの位置(座標)を割り出してテストを実行していたことから、最近のBrowser UseやPlaywrite MCPで使用しているアクセシビリティツリーの実装を取り入れることで性能UPしたことに感動しました。

個人的には以前サークルでアクセシビリティに関しての書籍を出したこともあり、アクセシビリティツリーに関しては少し馴染みのあるものでした。音声読み上げツールがサイトのdomをどう解釈するのかを意識することと少し似ているな。と感じました。

Browser UseやPlaywrite MCPの実装を追っていくことで、アクセシビリティツリーに辿り着く過程がすごく痺れました。

Kamalって便利?社内プロジェクト3つをKamal + AWSで運用した体験談

kaigionrails.org

所感

自分が所属しているソニックガーデンの先輩プログラマのyappuさんの発表です。Kamalについては個人的なアプリをデプロイするときに使ったりしたこともあり、できることについては大体把握していました。

しかし、実際にAWS ECSで社内プロジェクトを運用していくにあたり、自動デプロイや名前解決について工夫が必要ということは初めて知りました。

スライドにあったように、デプロイを毎回お願いしていたこともあり、その時を思い出して感慨深くなってしまいました。すごく学びになりました。

かっこよかったです!発表お疲れ様でした!

Railsによる人工的「設計」入門

speakerdeck.com

所感

設計体得できていない状態では、より具体的なコードから考えてしまう。というのはあるあるだと思い、それは設計ではなく「手順」を考えているのでは?ということについてはそうだよなぁと感じました。

今回の発表では設計するということを落とし込み、人工的にメソッドとして「使える」状態まで言語化しており、今の自分に刺さった内容でした。

おそらく、この発表通りの人工的メソッドを丸々使用しても難しい箇所があると思うので、自分なりに試してフレームワークを確立するのがベストかと思いました。

そのために自分が普段どのように設計をしていくのかを1つずつ振り返ることが必要であり、自分なりに論理的に考えられているのかを洗い出していきます。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

speakerdeck.com

所感

サービスクラスは使ったことがなく、Fat Modelを避けるための手法として認識していたのがですが、それをチームとしての共通認識として揃えることに関しては割と難しいのだろうな。と感じました。

また、現実的な折衷案としてFormクラスがあるということは知れたのですが、なぜそう考えたのか、という思考まではまだまだ理解できていません。スライドにある通り、DDDやRDB、モジューラモノリスといったことを理解し、なぜそれが必要なのか?ということを自分自身で解釈できないと理解ができないなぁと感じました。

今回の発表を聞き、設計というかRailsのベストプラクティスを自分の頭で考えるために何が必要な要素を知ることができました。

2日目

履歴 on Rails : Bitemporal Data Modelで実現する履歴管理

speakerdeck.com

所感

履歴管理の代表的な手法として、バージョン型と有効期限型が存在することは理解していたのですが、「従業員を起点とした変化」をどう扱うかという視点でパターンを洗い出し、Bitemporal Data ModelをRailsで使えるようにするためにgemを作るのがプログラマとしてカッコ良いな。と思いました。なければ作る姿勢は自分も見習っていきたいです。

また、Bitemporal Data Modelレコードの挙動や、従業員が入社→異動した際の具体的な例まで解説していたところが分かりやすく、説明が入ってきやすかったです。

Sidekiq その前に:Webアプリケーションにおける非同期ジョブ設計原則

speakerdeck.com

所感

長時間リクエストが発生するとプロセス/スレッドが占有されてしまい、サーバが詰まっている状態になる。というWebサーバの仕組みから丁寧に解説していたので、非同期ジョブが必要な背景(理由)がスッと入ってきました。

「それなら大体非同期ジョブでいいじゃないか」という気持ちになるのですが、それだと考慮点が増え、意思決定をすることが増えてしまうという「トレードオフ」が発生するよね。ということから、バッチ処理でもよくない?という提案ができ、非同期ジョブの設計原則・指針を見出すことができる。という流れを分かりやすく解説していて分かりやすかったです。

処理を非同期ジョブにする観点が自分の中で増えたので、今後この設計原則・指針を元に判断していこうと思います。

Introducing ReActionView: A ActionView-Compatible ERB Engine

speakerdeck.com

所感

HerbはErbのParserというイメージだったのですが、FormatterやLinterを行えるようになっていたり(おそらくpreview)と、自分が思っていた以上に強力なライブラリに成長していると感じました。

しかし、それ以上にReActionViewというgemはTemlateView Errorsをかなり分かりやすくしてくれたり、開発者ツールでViews Partials Componentsを表示させ、そこのソースコードを表示することができ、さらに選択した画面に遷移することができるらしく、開発がかなり楽になる予感しかありません。

実際にデモを見た時に会場で「おおおーー!!」という声が上がり、熱気がありました。

今後はStimulus LSPでHTML側からStimulus Controller名を確認できたり、その他いろいろ...(スライド見てみてください)。すごくワクワクして応援したい!と思えるような発表でした。ワクワクしました。

非同期jobをtransaction内で呼ぶなよ!絶対に呼ぶなよ!

speakerdeck.com

所感

非同期ジョブ内で起きるエラーの原因調査が難しい。というあるあるを丁寧に解説していて、transactionがいつDBへのcommitをしているか?非同期ジョブをいつスタートされるのか?を具体例も用いて解説してくれました。

ActiveRecord::RecordNotFoundとActiveJob::DeserializationErrorが起きる原因を特定し、3つの対策を提示してくれました。

自分もハマったことがあるので、「わかる〜」と思って聞いてたのですが、このように何が原因でどのように対策すれば良いのか、までは言語化できていなかったので、今後の開発に生かせそうです!

Rails on SQLite: exciting new ways to cause outages

speakerdeck.com

所感

SQLiteRailsアプリケーションで使用することによる注意すべき点などを話していたんだと認識しています。

個人的にはこのスライドでユーザーごとにファイルを分けるという発想がなかったので、これだとマイグレーション失敗時にはロールバックできるのだろうか?という疑問などが出てきました。実際の発表でどのような観点で話していたのか曖昧なので、動画を見直してみます...。

rails g authenticationから学ぶRails8.0時代の認証

speakerdeck.com

所感

Rails8.0で認証ジェネレーターが追加された背景(理由)から、認証ジェネレーターを使うとどのようなことができるのか?を解説していました。

実際のアプリケーションで認証ジェネレーターを使用する場合にどのような点を考慮すべきか、ということを解説しながら、認証やセキュリティについて学ぶ題材に良い。ということで、ソースコードを追っていきました。

rate_limit, has_secure_password, start_new_session_for, タイミングアタック...という実装と用語について深く理解していなかったので、「知らなくては...」という気持ちになりました。また、認証ジェネレーターで生成されたSessionやCurrentモデルが何をしているのかを把握することで、何をしているのかを大まかに把握することができました。

社内で勉強会開いてみたいな。

Keynote: Building and Deploying Interactive Rails Applications with Falcon

スライド見つからず...

所感

Falcon入れたらめちゃくちゃサーバー負荷が軽減される。ぐらいの理解をしています。gem remove puma gem install falcon のスライドが印象的でした。

今後はpumaではなくfalconが使用されていく事例が増えていくんだろうな。と感じ、次個人で作るRailsアプリケーションはFalconで動かしてみようと思います。

実際にFalconをインストールするデモが面白く、動いているものを見ると自分でも試しちゃいますね。

全体の所感

Kaigi on Rails2024から参加したのですが、以前よりも「確かにな〜」「わかる〜」と思えることが増えてきました。それに伴い「こうした場合はどうなるのだろう?」という自分の意見が少しずつ言語化でき、社内で気になる発表や技術に関してあれこれ議論することができています。

また、去年よりも「設計」というか「概念」など、抽象的な話を理解することができ、自分自身の中でRailsのらしさが少しずつ見えるようになってきたんだと思います。特にServiceクラスについてはかなり考えさせられて、議論が発展していきました。

やはり、現地に行って肌で熱量を感じることが一番の学びになると思っているので、今年も参加できたことを感謝しています。

運営の皆様、登壇者の皆様、行かせてくださった会社の皆様、本当にありがとうございました。

今年のKaigi on Railsも最高でした。