Part2続き
前回の記事では、2007年から2009年までの軌跡を振り返りました📙
今回は2010年から2012年までのRailsの軌跡についてまとめていきたいと思います！✍️
Railsの軌跡 - 第3章
2010年：Rails3.0のリリースと「現代的なコード」の幕開け
2010年8月29日にRails 3.0がリリースされました！
前年末からの「Merbとの統合」が実を結び、Merbの「モジュール性（部品の切り離しやすさ）」と「パフォーマンス」を取り入れたRailsはよりモダンで堅牢なフレームワークへと進化を遂げました。
Rails3.0リリース
| 機能 | 説明 |
|---|---|
Merbとの結合 |
内部構造がモジュール化（コンポーネント化）され、不要な機能をオフにしたり、特定のライブラリを入れ替えたりすることが容易に |
Active Recordの改善 |
クエリインターフェースが強化され、複雑なクエリをより簡潔にメソッドチェーンで直感的にSQLを組み立てる現在のスタイルが導入 |
Bundlerの標準採用 |
依存関係管理ツールであるBundlerが標準で採用され、Gemのバージョン管理と依存関係の解決が容易に。rails new をすると自動的にGemfileが作られる今のスタイルは、ここから始まった |
XSS対策の強化 |
クロスサイトスクリプティング（XSS）攻撃に対する防御機能が強化され、デフォルトで安全なHTML出力が行われるようになった |
Active Recordの書き方が今のスタイルに
- Before(Rails2.x)：巨大なハッシュで条件を指定していました
users = User.find(:all, :conditions => ["age > ?", 18], :order => "created_at DESC")
- After(Rails3.x〜)：現在のメソッドチェーンで条件を指定するスタイルに変わりました
users = User.where("age > ?", 18).order(created_at: :desc)
私😮「メソッドチェーンで直感的に書けるのは最初からじゃなかったんや😳アップデート感謝🙏」
スタートアップの主力に
-
Rails 3.0のリリースにより、Railsはスタートアップ企業の主力フレームワークとしての地位を確立しました。 - 2010年ごろには、
TwitterやHuluなどの巨大サービスがRailsを主要技術として活用しており、「プロトタイプ用」から「大規模商用サービス用」へとその評価を高めていきました。
2011年：Rails 3.1のリリースとフロントエンドへの挑戦
この年はRails 3.1がリリースされ、フロントエンド開発における重要な機能が導入されました！
Rails3.1リリース
2011年8月31日にリリースされ、下記のような新機能が追加されました。
| 機能 | 説明 |
|---|---|
| アセットパイプラインの導入 | これまでは、CSSやJSファイルを書いたらそのままサーバーに置いていたが、それを「加工してから配信する」という仕組みを標準化 |
| jQueryのデフォルト採用 | それまで標準だったPrototype.jsに代わり、世界的に普及していたjQueryがデフォルトのJSライブラリになった |
CoffeeScriptのサポート |
JavaScriptをより簡潔に書けるCoffeeScriptがサポートされ、JSコードをより効率的に記述可能に（※現在はJavaScript自体が進化したため、あまり使われなくなった） |
Sassのサポート |
CSSをより効率的に記述できるSassがサポートされ、スタイルシートの保守性が向上 |
アセットパイプラインとは？
-
Rails 3.1で導入されたアセットパイプラインは、CSSやJavaScriptなどのフロントエンドアセットを効率的に管理・配信する仕組みです。 - 開発者はファイルを細かく分けて整理しながら開発でき、本番環境では自動的に1つの高速なファイルとして配信され、この「開発のしやすさ」と「実行時の速さ」の両立は、当時のWebフレームワークとしては画期的な機能でした。
- 具体的には、下記を自動で行う仕組みです。
- 複数のCSS/JSファイルを1つに結合（結合）
- 不要な空白やコメントを削除してファイルサイズを縮小（圧縮）
- SassやCoffeeScriptなどのプリプロセッサをコンパイル
- キャッシュ制御のためのファイル名にハッシュを付与
私😲「フロントエンドの管理が楽になるのはありがたい！当たり前に使っているけど当時は画期的だったんだな〜」
2011年は、「アセットパイプライン」という概念を導入したことで、Railsが単なるサーバーサイドの道具ではなく、「フロントエンドのパフォーマンス管理まで責任を持つフルスタックフレームワーク」へと進化した重要な年だったと思います。
2012年：Rails 3.2のリリースとセキュリティ強化
Rails3.2リリース
2012年1月にリリースされ、以下のような新機能が追加されました。
| 機能 | 説明 |
|---|---|
| 開発モードの高速化 | 依存関係の解決ロジックが改善され、ファイル変更後の再読み込みが非常に速くなり、開発体験が向上 |
Active Recordのexplainメソッド |
クエリの実行計画を確認できるexplainメソッドが追加され、パフォーマンスチューニングが容易に |
「マスアサインメント脆弱性」とGitHubハッキング事件
- 2012年、
GitHubがハッキングされる事件が発生しました。この事件は、Railsアプリケーションにおける「マスアサインメント脆弱性」を悪用したものでした。 - マスアサインメント脆弱性とは、ユーザーからの入力を一括でモデルに割り当てる際に、意図しない属性まで更新されてしまう脆弱性のことです。
事件の詳細
- ロシアのプログラマー（Egor Homakov氏）が、GitHubのとある脆弱性を指摘しました。
- 彼は警告のために、Railsの「マスアサインメント」という仕組みの穴を突き、GitHubの公開リポジトリ（Rails本家のリポジトリ）の管理者権限を勝手に奪取して見せました（もちろん悪用はせず、すぐに報告しました）
- GitHubの問題ではなく
Railsの問題であったため、Railsを使用している多くのアプリケーションが影響を受ける可能性がありました。 - GitHubはこの脆弱性を修正し、Homakov氏のアカウントを一時停止した後、最終的に復旧させむしろ彼と積極的にこの問題を議論しました。
Strong Parametersの導入
- この事件を受けて「送られてきたデータをそのまま保存するのは危険すぎる」という認識が広まりました
- 対策としては、コントローラーで「どの属性を更新して良いか」を明示的に指定する
Strong Parametersが導入されました - これにより、意図しない属性の更新を防ぎ、セキュリティが大幅に強化されました
- 2012年にGemとしてリリースされ、後の
Rails 4.0で標準機能として組み込まれました
私😲「ストロングパラメーターがなかった時の脆弱性について、まさかGitHubで実際に証明されていたとは😂」
Part4へ続く
次回は2013年以降のRailsの軌跡についてまとめていきたいと思います！✍️
参考記事