Kaigi on Rails 2025には3本のプロポーザルを提出しましたが、全て不採用だったので公開します。誰かの参考になると嬉しいです。
1本目
これは関西Ruby会議08に送ったプロポーザルとほぼ一緒です。ほんのわずかしか変わっていません。
タイトル
Solid State Survivor
概要
Rails 8 では、rails new をしたときにSolidQueue、SolidCache、SolidCableという3つのgemが標準で有効化されるようになりました。これらSolidの名を冠するGemは、それぞれActiveJob、ActiveSupport::Cache、ActionCableのバックエンドにデータベースを使用します。このデータベースはSSD上で動作していることが期待され、Solidという名前の由来もSSDからきています。また、Rails 8 からはProduction環境でのSQLite利用が推進されています。そしてこのSQLiteとSolid gemsのシナジーが、Railsの生産性をさらに加速させてくれます。このトークでは、SolidとSQLiteを使用することで、0->1開発の景色がどれだけ変わるかを皆さんにお伝えしたいと思います。
詳細
SolidQueue、SolidCache、SolidCableだけではなく、ActiveRecord::SessionStore、ActiveStorageDBを使い完全にSolidなRailsアプリケーションを開発体験をお伝えしたいと思います。 Railsはかなり容易に0->1ができるフレームワークですが、一方でRails 7 までは本番環境の構築にはRailsが動く実行環境に加え、PosrgreSQL/MySQLとRedisがほぼ必須のミドルウェアとして要求されていました。しかし、Rails 8の登場で本番環境でのSQLiteが推奨され、さらにSolid gemsが標準化されたことで、本番環境にRailsが動く実行環境以外のミドルウェアは基本的に必要なくなりました。このトークでは、さらにSessionStoreとActiveStorageもDB化することによって、真にSQLite以外を必要としないRailsの開発体験の話をします。本番環境でのインフラ構築に悩まないことが、どれだけ開発におけるマインドシェアを奪われず開発に集中することができるかを伝えたいと思います。 また、SQLiteを使うことによって生じるデプロイの難しさや、環境の制約についてもお話しします。特にクラウド環境でSQLiteを使う場合、複数のインスタンスにDBファイルが存在することは基本的にできず、取り回しが非常に難しいです。なるべくサーバレスサービスを使わず、同じくRails 8 で標準化したデプロイツールであるkamalを使うことが現状ではベストプラクティスになるという結論です。 このトークの対象者は、まだRails 8でrails newをしたことがない人たちです。新しいプロダクトを思いついたとき、難しいインフラ構成を考慮せず最速で本番環境まで持って行ける体験の良さを、まだSolidを使ったことが無い多くの人に伝えたいです。
このトークは、次のテックブログにて書かれているRubyKaigiのスケジュールアプリ構築の話をベースとします。 https://tech.smarthr.jp/entry/2025/04/17/185354
ピッチ
Rails 8 は、DHHが言うとおり0->1からIPOまでを全てこなせるフレームワークです。その真の実力を少しでも伝えることで、聴講者の中にいるアプリケーションを作りたいというやっていきの気持ちを燃やすことができる、これこそがトークを採択すべき理由です。私は実際に数百人が利用するRubyKaigiのスケジュールアプリを完全にSQLiteだけで運用した実績があり、その良さと悪さは十分に知っています。ゆえに私だからできるトークであり、私が公演するにふさわしい理由です。
2本目
タイトル
Hotwire (not)vs React
概要
現在、モダンなWeb開発のフロントエンドにおいて最も大きなポジションを得ているのは、ReactとReactを用いたNext.jsで間違いないと思います。Reactは、その宣言的なUI記述によってこれまでの状態管理の難しさから感じていた苦痛を軽減してくれます。それに対して、Hotwireはどの程度開発者の苦痛を取り除いてくれるのでしょうか？ このセッションでは、主にStimulusに焦点を当てながら、HotwireとReactを比較し、Hotwireがどの程度我々の苦痛を取り除いてくれる選択肢になるかを検証してみたいと思います。
詳細
Reactの強みは、コンポーネント化された宣言的でリアクティブな設計で、管理すべき状態の責任を小さくしてくれる点です。副作用や状態遷移が一つのコンポーネントの中に閉じており、他のコンポーネントの状態による影響を受けないようにして、状態管理の難しさを軽減しています。 一方でStimulusは、比較的ナイーブなJavaScriptの実装であり、Reactほどに強力なルールを強制することはできません。ですが、StimulusもまたHTMLのDOM要素とその子要素のみに変数をバインドするコンポーネント指向のJavaScriptライブラリであり、複雑さの軽減という意味では強い力を持っています。 Stimulusの動きは、SPAフレームワークとしてのReactではなく、コンポーネントとしてのReactと非常に近い感覚を持っています。StimulusだけでSPAを作ることは困難ですが、副作用が特定のDOMに閉じた小さなコンポーネントとして再利用することは容易です。そしてViewComponentを使うことにより、より明確にコンポーネント化したStimulusを扱えることを示します。 RailsでReactを使う場合、Viewとのつなぎ込みで大変な困難が伴います。ですが、StimulusはRailsにビルトインで、シームレスに扱えます。Reactの力は強力ですが、Stimulusもまた十分に力があることを示すことで、複雑ではない out of the box なRailsの魅力をより感じることができます。Hotwireは、Railsに最初から組み込まれているフレームワークで、0->1で強力な力を発揮します。まず最初にHotwireで書き始め、プロダクトを素早く形にする大切さを聴講者に伝えたいと思います。そしてHotwireを捨てて次のステップに進む日が来たとしても、それまでは十分にメンテナンスができるHotwireの書き方を提示します。
ピッチ
これまで2つの完全HotwireなRailsアプリを二つ作成し、公開しています。Hotwire、特にStimulusのDOMグループにバインドするJavaScriptのパーツは、移植性や再利用性が高く、汎用的に使えるものだということをそのときに体験しました。実際に作成し、利用されているアプリケーションでの実例を交えながらお話しできるのが、私とこのトークの強みです。
3本目
タイトル
その依存、異存ありませんか？
概要
依存するものが少ない方が良いという命題は、大抵の物事には当てはまると思います。プロダクトコードもまたその一つです。あなたのGemfileには、一体いくつのgemが書かれていますか？ 依存するメリットは、楽になることです。これも大抵の物事に当てはまると思いますが、プロダクトコードにおいては自分で書くコード量を劇的に減らせることができます。またOSSの場合は、必ずしもメンテナンスを自分でやらなくても、有志がコードを育ててくれます。 依存するデメリットは、やめられなくなることです。これもまた大抵の物事に当てはまると思いますが、プロダクトコードにおいてはアップデートによるインターフェイス変更への追従、関連gemのバージョンアップによるテストの崩壊、別々のgemが同じgemの別バージョンに依存している、などの地獄があります。現実世界と同じで、強い依存はいずれ破滅を招きます。 このトークでは、当然の様に依存しているライブラリを自分で作ってみて、依存をなくしてみることを目指します。依存することのメリットと、自分で作ることのメリット、どちらの方が良いかを考えてみる機会としていかがでしょうか。
詳細
faradayや、deviseなど、誰もが当然の様に依存しているライブラリを、何となく手で書いてみることで、本当に依存が必要かどうかを問うという内容でお話しする予定です。もちろん、主題として依存をなくして全部自分で書こう、ではなく、選択肢として自分で書くというのもあるよ、くらいのニュアンスです。この話は、以前から既存のライブラリの再実装を趣味でしていることや、DHHがRails8にAuthenticationのジェネレーターを追加したことにインスパイアされています。DHHは、認証機構は魔法でも何でも無く、自らの手で書けるということを示すためにAuthenticationのジェネレータを追加したといいました。私も、何も知らないマジックとしてのGemへの依存では無く、中で何が動いているのかを自ら知り、本当に依存する必要があるのかどうかを問い直すという内容でお話しします。
ピッチ
今のところまだ実コードがfaradayやActiveModelの置き換えコード程度しかないので、プロポーザルが受理されたら締め切り駆動開発が始まります。お楽しみください。