- バンドのセットリスト管理アプリ(setlist.rocks) を作る中で、久しぶりにRuby on Rails開発の楽しさを再発見
- 最新のRails 8は従来のMVC構造を保ちながら、Hotwire(Stimulus・Turbo) ベースの「no-build」フロントエンド、Solid Cache/Queue/Cable などによってモダン化
- SQLite は基本設定だけでも本番サービスに適用できるほど最適化され、Kamal デプロイツールによりコンテナベースの無停止デプロイが簡単に
- Railsの「設定より規約」哲学と豊富なgemエコシステムにより、アイデアからプロトタイプまで素早く実装可能
- RubyとRailsの人気は以前より下がったが、今なお成熟して一貫性のあるOSSフレームワークとして開発の楽しさを提供
サイドプロジェクトとRailsへの回帰
- バンドのセットリストと曲のノートを管理するためにWebアプリを自作し、既存のスプレッドシートやチャットより効率的な方法を追求
- 開発の過程でRailsのシンプルさと生産性を改めて実感し、近年の複雑なWebエコシステムと比べて「純粋な開発の楽しさ」を感じたと言及
- Rubyは今でも自然な文法と表現力により、思考をコードへ移しやすい言語として評価される
- Stack Overflow 2025調査によればRubyとRailsの人気は低下したが、個人プロジェクトでは今なお好まれている
Rails 8の変化とフロントエンド
- Rails 8は既存のMVC構造を維持しつつ、Hotwire(Stimulus・Turbo) ベースのフロントエンド統合を提供
- Turboはリンククリックやフォーム送信を横取りし、SPAレベルの応答性を提供
- Stimulusは必要な部分にだけJSの動作を加え、最小限のJavaScript記述でインタラクティブなUIを実現可能
- Importmap の導入により、WebpackやnpmなしでJSライブラリをCDNから直接読み込める
- AIツールを活用してUIを生成したが、創作とコードの芸術性の間で葛藤も示した
開発ワークフローと生産性
- Railsの「設定より規約(Convention over Configuration) 」哲学により、モデル・ルーティング・コントローラ・ビューを素早く構成できる
- 例として
Tagモデルの生成、RESTfulルーティングの自動化、JSONレスポンス処理の流れを実演
- ERBテンプレートとライブリロードで高速なプロトタイピングが可能
- 豊富なgemエコシステムにより、CSVやPDFなど多様な機能を容易に統合できる
バックエンド改善: Solid*シリーズとSQLite
- Solid Cache/Queue/Cable がRails 8に標準搭載され、Redisなしでキャッシュ・ジョブキュー・WebSocket処理が可能
- Solid CacheはDBベースのキャッシュによりRAMの節約と単純化を実現
- Solid QueueはDBベースのバックグラウンドジョブ管理で、
SOLID_QUEUE_IN_PUMA=1 設定だけで実行可能
- Solid CableはDBベースのAction Cableアダプタとしてリアルタイム機能を支援
- SQLite は
database.ymlのpragmas:設定により、WALモード、NORMAL同期などの最適化が標準適用
- 別途DBサーバーがなくても小規模な本番環境で実用的に利用できる
デプロイ自動化とKamal
- 過去のCapistrano・Ansibleベースのデプロイの複雑さに触れつつ、Kamal をRails 8の標準デプロイツールとして紹介
- コンテナのビルド→プッシュ→サーバー配備→ヘルスチェック→無停止切り替えの流れを自動化
- kamal-proxy がトラフィック切り替えとSSL処理を担当
.kamal/secrets ファイルにより、環境変数ベースの安全なシークレット管理を支援
- GitLab CIと連携すれば、
git push だけでデプロイが可能で、かつてのHerokuのシンプルさを再現
認証とその他の機能
- Rails 8は組み込み認証ジェネレータ(auth generator) を提供し、Deviseよりシンプルな認証システムを構築可能
- Deviseは今なお豊富な機能とドキュメントで有用だが、Rails標準認証のシンプルさも魅力として評価
Railsエコシステムの現在と持続性
- RubyとRailsの人気は低下したものの、Shopify・Basecamp・SoundCloud・GitHub など主要サービスで今なお利用されている
- 多くのgemはメンテナンス段階にあるが、Railsは毎年安定したリリースサイクルを維持
- 「新しい開発者層の流入は減ったが、それでも楽しく開発できるフレームワーク」と評価
結論
- Railsは最新トレンドとは距離を置いているが、開発の楽しさとシンプルさを取り戻させてくれるツールとして強調
- 人気よりも作る楽しさと創造性を重視し、「もう一度Railsを試してみてほしい」というメッセージで締めくくられる
4件のコメント
Rails って「設定より規約」じゃなくて「規約より設定」だったと記憶しているのですが...
> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails threw all that away and introduced the notion of “convention over configuration”
LLMが語順を変更せず、入力順のまま出力したようです。原文では正しくなっています。
LLMでもこういうのは間違えるんですね。修正しておきました。ありがとうございます
Hacker Newsの意見
Railsは本当に大好きだけど、大規模な動的型付けコードベースで働いた経験をして以来、個人プロジェクト以外でRailsに戻るのは難しくなった
型のない大規模コードベースは、RubyMineのような強力なIDEがあっても保守が悪夢レベル
最近Sorbetがどれほど進化したのか、特にRoRとの相性が気になる
Railsの哲学をうまく踏襲しつつ、Rustの学習を容易にしてくれる
週末に試してみる価値はある
実際の本番データをローカルに複製したり、サーバーにSSH接続してREPLで状態を調べたりしなければならない
IDEでのデバッグは地獄のような体験だった
Rubyは本当に好きだったけれど、ライブデバッグを経験してからは厳しくなった
もはやRubyやPythonをあえて選ぶ理由はない
PythonはML分野でしばらく持ちこたえるだろうが、いずれ消えていく気がする
私もこういう考えを公に言ってくれてうれしい
最近は過剰なマイクロサービスアーキテクチャにうんざりしている
夜は余計な構造なしに、単純に問題を解決するプロジェクトに触っている
昔はPHPの構成を多く扱っていたが、RailsもPHPも結局は問題解決のための道具にすぎない
昔のデスクトップIDE開発のように、「箱の中で」すべてが回っている感覚がある
Web開発の複雑な構成要素の管理から離れ、生産性中心のシンプルさを取り戻した気分だ
しかもTypeScriptを書かなくていいのが最高。TypeScriptは冗長で不要なボイラープレートの塊だと思う
私たちは2007年からRailsアプリを本番環境で動かし続けている
Railsの長寿の秘訣は年齢ではなく、その安定性と実用性にある
バックエンドでJavaScriptを使えば効率が上がるという主張は、すでに反証されている
技術スタックの変化の大半は履歴書最適化やトレンドへの不安によるもので、実際のエンジニアリング上の要請ではない
Railsは静かに本物のビジネスを動かし続けてきた
NPMの310万パッケージがRubyGemsの19万個より多くの機能を提供していると考える人はいないだろう
Inertia + Vue.jsへ移行中だが、バックエンドの変更がほとんど不要なほど強力な組み合わせだ
生産性の向上によって採用の難しさも相殺できている
ユーザー数が多いほどエコシステムは健全になる
ただしRubyGemsにも古いパッケージが多いので、単純比較は難しいと思う
RoRやDjangoの**「バッテリー同梱」という哲学は良いが、古いプロジェクトの保守には時間がかかる
5〜6年物のプロジェクトを更新するには依存関係の管理が大きな負担になる
そのため最近はGo**でシンプルなフレームワークを使うか、あるいは何も使わずに開発する方を好んでいる
本当に必要なライブラリだけを使えば保守は容易だ
セキュリティパッチ以外で、わざわざ更新しなければならない理由があるのだろうか
この1年半で5つのメジャーバージョンを上げたが、それでも比較的簡単だった
初期に慎重に構成すれば、長い間ほとんど手を入れずに済む
アップグレード体験は過小評価されていると思う
Next.jsはメジャーバージョンごとに構造が完全に変わるが、Railsは段階的廃止(deprecation)のサイクルが遅く、はるかに安定している
製品を継続的にリリースするなら、最新のパラダイムよりもインターフェースの安定性の方がはるかに重要だ
Next.jsのpages → app router移行は、実質的に全面的なリプラットフォーム級の変化だった
一方Railsには文書化されたアップグレードパスと予測可能な廃止サイクルがある
Rubyのバージョン管理もrbenv/asdfのおかげで環境不一致の問題をほとんどなくしている
私は10年以上RailsでDevOpsから一人Web開発者までやってきたし、やり直しても同じ選択をすると思う
Railsはすべてが揃ったクリーンで生産的なフレームワークだ
Stack Overflowの調査でも、依然として「次のプロジェクトで使いたいスタックTop 5」に入っていた
インフラ構成まであまり気にする必要がなく、デプロイも簡単だ
結局重要なのは他人の目ではなく、自分に合った道具を使うことだ
Djangoより1年早く登場した
調査リンク
昔はRuby/Railsがほとんどの問題に対する最適解だと思っていたが、今でもやはりそう思う
Railsは使ったことがないが、最近のWeb開発環境の混乱には共感する
だから私は未来を見据えてElixirとPhoenixを選んだ
次のプロジェクトではぜひ試してみるつもりだ
Elixirの何がそこまで魅力的なのか、最初に触れるときに注目すべき点が気になる
10年前、スウェーデンの大手放送局のストリーミングフロントエンドをRailsで構築した
Herokuで100万人以上の同時接続を処理したが、本当にうまく動いていた
その後はストリーミングインフラ、API、AI/MLなど別の分野へ移ったが、Railsが失敗したからではなく、問題の性質が変わったからだ
Railsはデータモデルとビジネスロジック中心の問題に向いており、並行性やインフラ中心の問題には別の言語の方が合っている
Rubyは今でも美しく表現力のある言語であり、懐かしさが大きい
ただ、好きな言語に対する個人的なバイアスを完全に捨てるのは難しいと感じる
次のプロジェクトではどの言語を選んだのか気になる
静的型付けの欠如を惜しむ人には、Sorbetのような優れたソリューションがある
Rubyの生産性と静的型付け、LSP統合を同時に享受できる
ShopifyのおかげでRailsでもSorbetのサポートは充実している
私は今でもRailsで働きたいと思うほど、このエコシステムが大好きだ
AIツールの進化のおかげで、今や想像力の大きさだけが限界だと思う
これをベースに、24時間店舗監視とSlack通知を行うeコマースエージェントを作った
AI関連のプロジェクトをするなら、selzee.com/openclawはぜひ確認してみる価値がある