/note/tech

Rails is done

要約:

■ 1. Railsをフォークする理由

  • Railsのコア:
    • 時の試練に耐えてきた
    • 現在もWebアプリケーションを構築する優れた手段
  • DHHとの根本的な非互換:
    • DHHの世界観は自分の世界観と根本的に相容れない
    • そう感じているのは自分だけではない
  • 実現しなかった公開書簡:
    • 約1年前、自分を含む多数の人々がコアチーム宛の公開書簡に署名した
    • 内容はDHHとの関係を断ち、Railsをハードフォークすることの要求
    • それは実現しなかったため、自分たちの手でフォークを行う時期に来ている
  • 新しいリーダーシップが必要な背景:
    • 1年前のDavid Celisの記事と数週間前のPaul Battleyの記事がその理由をまとめている
    • 信じ難いことに、状況はそれ以降さらに悪化している

■ 2. Railsは完成しているという判断

  • フォーク維持の実現可能性:
    • Railsは巨大なコードベースで、多数のエンジニアが業務時間を投じて改善している
    • 少人数が余暇でフォークを維持できる理由は、Railsが完成しているという事実
  • 変更の継続的な観測:
    • The Rails 5 WayをRails 6、さらに7と8へ更新する過程でRailsの変更を注視してきた
  • コアの範囲:
    • rails new --minimalで生成されるのはフレームワークのコア部分のみ
    • 内訳はrailties、actionpack、activesupport、activemodel、activerecord、actionview
  • コアgemの停滞:
    • 2019年のRails 6.0でZeitwerkオートローダーが導入されて以降、コアgemに大きな変更はない
    • ただしActiveRecordは例外
    • ActiveRecordの改善も大半は2020年の6.1に集中している
      • 例外はat-work encryption、非同期クエリ読み込み、一部の認証方式、複合主キー
  • 以降に追加されたもの:
    • 好みで追加できるgemやnpmパッケージにすぎない構成要素ばかり
    • 一連のアセットパイプライン
    • Railsでも他のRuby/PHP/Javaのフレームワークでも使えるJavaScriptライブラリ群
    • コンテナ化されたWebアプリケーションを配備できるデプロイツール
    • Goで書かれたリバースプロキシ
    • ActiveJob、ActionCable、キャッシュのバックエンドとなる新しいデフォルトgem
  • 完成していることの価値:
    • Railsは小規模から大規模までのWebアプリのニーズを満たし、付け加えるべきものはない
    • 追加可能な任意のgemを除きコアだけをフォークすれば、対象は安定する
  • フォークの実務:
    • Railsリポジトリを監視してセキュリティパッチをフォークへ移植する
    • 性能改善や小さな改善を探し、取り込むかを評価する
    • 挑戦的ではあるが実行可能

■ 3. Mosscapプロジェクト

  • コードネームの変更:
    • 本記事の初版ではプロジェクトのコードネームであるAmikoに言及していた
    • AmikoとMosscapは同一のプロジェクト
  • 現在の状況:
    • Matrix上に良好なコミュニティが形成されつつある
    • フォークの動作方式に関するスパイクを進めている
    • 関心があれば入口から参加できる
  • 主目標:
    • Rails 8.xのLTS版を提供すること
    • ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しない人々のコミュニティが構築し維持する
  • 移行方法:
    • 既存のRails 8.xアプリケーションはgemを差し替え、いくつかの検索置換を行えば動作する
    • 依存関係もフォークされたgemを使うよう、巧妙なaliasハックを用いる
  • 目指す性格:
    • Mosscapは退屈で親しみやすいものにする

■ 4. 加える変更

  • 互換性の範囲内での修正:
    • 互換性を壊さずに実施できるなら、Railsの欠陥にも取り組む
  • アセットパイプラインの混乱:
    • 2021年のBasecampの崩壊でコアチームがフロントエンドの知識を失った
    • それ以降、半端にしか動作しない十数個の手法が併存する絶対的な混沌状態にある
  • mosscap newの設計:
    • コマンドのあり方も議論した
    • シェフが全員に同じ料理を出すのはomakaseではなくファストフードであると理解していない人物が設計したものは踏襲しない
  • 変更の規模:
    • Rails 6/7/8で慣れ親しんだものからの変更はわずかにとどまる

■ 5. Hanakaiとの関係

  • Ryan Biggによる異論:
    • Mosscapの目標に反対するブログ記事を書いた
    • Hanakaiに全員が参加すべきだという提案
  • ミッションへの賛同:
    • ある意味ではHanakaiに参加している
    • Hanakaiのミッションとコアバリューには合流する
    • その価値観は、あらゆる背景と経験レベルの人が尊重され、共有し成長でき、誇りと安全を感じられる場であること
    • ナチ、トランスフォビア、レイシスト、あらゆる偏見を許容しないという点も共通
  • モノカルチャーの拒否:
    • Tim Rileyと同じく、Rubyはモノカルチャーではなく繁栄するエコシステムであってほしい
    • 彼のキーノートに強く触発された
    • 理想的なジョブキューはMosscap、Hanami、Rodaのいずれでも動作する
  • Mosscapの位置づけ:
    • 数多くの素晴らしい選択肢のなかの一つ
    • 大規模なRailsアプリを抱えHanakaiへ書き換えられない人にとって特に良い選択肢を目指す
    • Railsの設計は好きだがそのリーダーシップは好まない人にとっても同様
  • 他の選択肢の紹介:
    • Railsとまったく異なる設計を望むならHanakaiコミュニティの取り組みを勧める
    • サーバサイドロジックを追加できる静的サイトジェネレータを望むならBridgetownを勧める
      • この個人サイトもBridgetownで構築している
    • MosscapをWebフレームワーク、Romをデータ層、Dry::Operationを業務ロジックの整理に組み合わせればokonomiの体現となる

■ 6. 結論

  • 共存の願い:
    • 全員が共に繁栄できることを望む
  • 目的:
    • Rubyエコシステムに選択肢を一つ加えること
    • あらゆる性別、肌の色、性的指向、経験レベル、背景の人々のために作る他のグループに加わること
  • 排除の姿勢:
    • ナチ、トランスフォビア、レイシストが悲鳴を上げて逃げ出すことを望む
    • 立ち去らないなら追い出す
  • 動機:
    • 後ろめたさを感じずにWebアプリケーションを作り続けたい