Part2続き

前回の記事では、2007年から2009年までの軌跡を振り返りました📙
今回は2010年から2012年までのRailsの軌跡についてまとめていきたいと思います！✍️

Railsの軌跡 - 第3章

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の書き方が今のスタイルに

users = User.find(:all, :conditions => ["age > ?", 18], :order => "created_at DESC")

users = User.where("age > ?", 18).order(created_at: :desc)

私😮「メソッドチェーンで直感的に書けるのは最初からじゃなかったんや😳アップデート感謝🙏」

スタートアップの主力に

Rails 3.0のリリースにより、Railsはスタートアップ企業の主力フレームワークとしての地位を確立しました。
2010年ごろには、TwitterやHuluなどの巨大サービスがRailsを主要技術として活用しており、「プロトタイプ用」から「大規模商用サービス用」へとその評価を高めていきました。

この年は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が単なるサーバーサイドの道具ではなく、「フロントエンドのパフォーマンス管理まで責任を持つフルスタックフレームワーク」へと進化した重要な年だったと思います。

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の導入

私😲「ストロングパラメーターがなかった時の脆弱性について、まさかGitHubで実際に証明されていたとは😂」

次回は2013年以降のRailsの軌跡についてまとめていきたいと思います！✍️