稿子是 2009 年底寫的，本來想一口氣連 SOA 的部份一起整理 (對 SOA 有興趣的話，可以看我之前的投影片 91 頁 ~ 119 頁)，不過一直拖到現在。雖然內容還是有點些雜亂，而且現在流行 NoSQL (?)，不過還是就貼出來吧。

這本 2009 年底的書，趁著轉職的空檔終於一口氣讀完了。有些重要的背景知識，如果你一直追所謂的最新技術，反而是學不到。這本書其實講 Rails 不多，前一大半都是在講 RDBMS 關聯式資料庫，後半則是 SOA 架構。

像 RDBMS 裡面的 referential integrity、composite key、DB View、triggers、materialized View 這些東西，因為身為 MySQL 使用者很少用到、Rails 也沒有內建支援，實際寫 code 好像也都在 application layer 應用層處理掉了，所以到底要幹嘛用的呢? 他們被發明一定有原因吧? 是在什麼情境上使用呢?

第四章 Database As a Fortress

作者非常強調資料庫的重要，一家企業最重要的資產是資料，而不是員工 (資料不見就全完了，員工沒了再找就有了)。Framework 會變、程式會有 bug、可能也不會只有 Rails 會去存取 DB (所以只用 ActiveRecord Validation 並不可靠)，總之只有你的 RDBMS 可以保障資料的正確性，data integrity 長存。

PostgreSQL 也比 MySQL 適合企業應用，因為很多 SQL 標準 MySQL 並不支援 (很多直到 5.0 後才支援)。PostgreSQL 會輸掉市佔率的原因是 1. MySQL 背後有一家商業公司支持 2. PostgreSQL 有很長一段時間不像 MySQL 有提供 Windows 安裝包 (話說這本書對 MySQL 其實還蠻揶揄的)。

作者也不建議使用 migration，因為它沒有支援所有的 DDL (Data Definition Language)。反正只有跑一次，不像 DML (Data Manipulation Language) 會一直用，用 ORM 比較方便。

作者持續強調 referential integrity 對企業層級的上線應用程式非常重要。會說不重要的，一定是該死的 MySQL 使用者(died-hand MySQL users)，千萬別因為你的工具(i.e. MySQL, Rails)沒有這個功能，就說不重要。

隨著資料越來越多，你的老闆會想要知道一些數據分析報表，這裡作者點出一個重要的議題：你的報表會害了你的網站!! 你越常去產生你的報表，你的網站就會越來越慢。”Report are killing your site!!” 為什麼呢? 因為去 DB 撈大量的資料做報表，是非常龐大複雜的 SQL 操作，你的 DB 的效能會被拖慢，整個網站的效能就跟著 down 下來。該怎麼解呢? 撈 report 的 queries 不要對 production database 做就沒事了吧?

這裡作者又對 MySQL users 揶揄了：因為大多數的 MySQL users 第一個想到的方案就是使用 master/slave 來解決，也就是讓 query report 對 slave DB 做，但是即時如此不會影響到 production 運作，也沒辦法解決 query 查詢很慢的問題。

這裡觀念上要區分的是 OLTP (Online Transaction Processing) 和 OLAP (Online Analytical Processing 這兩種類型的 query，前者是一般的讀/寫/更新，這種是會讓使用者可以馬上等結果，大部分的前台網站就是屬於這種。後者則是一個 query 就須需要收集上百萬的資料去分析，例如：有多少客戶買了產品A，又買了產品 B，依照地點跟時間。

因為 OLTP 和 OLAP 是如此不同，沒道理 database 的設計也相同。OLAP 要快，就必須使用 denormalized 非正規化的方式來存放資料。但是將正規化資料和逆正規化資料混雜在同一個 DB，則非常容易造成資料的混亂不同步，寫出 buggy 有臭虫的程式。

要解決這個問題的領域是使用獨立的 data warehouse 存放 denormalized 的資料。(書就到此打住了，作者推薦了 The Data Warehouse Toolkit: The Complete Guide to dimensional Modeling by Ralph Kimball 一書)

第五章 Building a Solid Data Model

Data layer 層級的 constraint 才保證一定正確，因為應用層的 Model validation 可以跳過，放在 code 裡也容易被改掉。作者也示範了這兩者都可以寫單元測試。

referial constraint 如果只用 Model 做，destroy 時就會失效。而 Model 要做 referial constraint 只能用 has_many :depentent 但是如果誤用了 :delete 就 orz 了。因此最保證的作法還是 data layer 做。

資料庫記得加 index 在 1. foreign key 2. 任何有 SQL where 條件的地方

第六章 Refactoring to Third Normal Form

3NF (三階正規化) 能做到 DB 資料不重複：只要不是 primary key、不是 foreign key、不是 intrinsic data(eg. name)、不是 measured value (例如 time, temperature)，而是一個 literally bound data，都應該正規化出來新建一個 table。不先做，後來要加會十分痛苦，尤其在一個已經有資料的 production db 上。

範例中的有很多 table 都有相同的地址欄位定義：Postgres 支援 multipie inheritance，可以處理重複的 DDL，再搭配上 Rails 可用 plugin mixin 處理重複的 code。

這裡留下一個第八章才回答的問題，只有一個 primary key 沒辦法一次撈出 has_many 的 has_many 資料。多保留一個 foreign key 又可能造成 direct 和 in-direct 的資料不一定一致。

第七章 Domain Data

Domain data (指網站預先就有的必要初始資料，又叫做 seed data) 也應該使用 table 存，因為 1. 保持 referential integrity 2. 維護 3ND 跟擴充彈性。實作上則可以做成常數形式。

strategy patterns with domain tables 這招示範了將 Order PAYMENT_TYPE 變成 domain tables 來做，除了變成 constant object，情境是如果不同 payment_type 會有不同的 validation。首先變成 constant 後，可以順利將 validation code 都從 order 搬走。而再進一步 rails single table inheritance 和 template method 將 validation 分散到個別的 domain model。總之，作者將 domain data 的彈性做了非常好的示範。

雖然正規化會導致大量的 table 和 model，但是也因為如此每個都很小非常容易測試，bugs 也就容易集中在小區域容易找到。

第八章 Composite Keys and Domain Key/Normal Form

這章討論 composite key 的優缺，以及如何使用。

ID column 系統的優點 1. Rails 內建 2. 簡單，除了 primary key 之外皆可修改，物件的 primary key 一定不變 3. 提供與真實資料的間接性，因此也不需有修改 primary key 的機會。 4. unique key 好做

composite key 的優點就沒這麼顯而易見，也不一定用的到。他的用途在於提供一種特別的 data integrity。table 中不一定可以發現有 natural composite key, 但是如果有而你忽略他，可能會有大問題。這個情境就是：

只有一個 primary key 沒辦法一次撈出 has_many 的 has_many 資料，如果只是加上一個 reference key, 可能導致 refential integrity hole. 這時 composite key 才是唯一解決之道。

DFNF 比 3NF 更近一步保證 referential integrity 在複雜的 relationship 中。不能因為工具沒有，就覺得不重要。因為 Rails 沒有內建，導致很多人不知道 DK/NF or natural keys 等這些已經發展成熟的資料庫基礎理論，在設計 schema design 上而有很大的缺陷。

先來檢討 single column ID 是否應該用 Rails 內建的數字，首先找有沒有別的 unique column，再來覺得它是否不會 或 不常變更，特別是連編輯介面都沒有的 domain data 特別符合這個條件，如果是，則可以用 set_primary_key 換掉，移除不必要重複 id column。不過，如果不是 domain data, 我們就必須產生這個 primary key，用法是寫在 before_create 裡，另外要注意還是使用 self.id。一個額外的好處是，這些可能被當做 foreign_key 的 nature key，也是有用的資訊，不像本來的數字 id 一定還要去本來的 table 查。

這裡我有個疑問是 Is there a REAL performance difference between INT and VARCHAR primary keys? ，在我碰到的例子是，很多人擔心非 integer 當 key 會影響效能 :/ (題外話，很多人愛用 type code，但都被我建議改成 string constant ) 但是我想這差距的微乎其微，尤其在你沒有上百萬的資料列。重點還是，你選的 nature key 不需要有被修改的可能 :>

Rails 要支援 composite keys 有兩個方法，一個是使用 Dr. Nic Williams 的 plugin，一個是本書作者的 Rails-DK/NF hybrid 法：

具體的作法是，保留 ID column 欄位，但是 DB 還是加上 composite key 的 foreign key referential integrity 限制。好處在 Rails 裡面不方便改 primary key, 當有修改的需求時，使用 hybird 法就不錯簡單(不需要裝plugin)。但是回過頭想，如果你需要修改 nature key，可以先想想是不是最好的作法應該是刪掉舊的，插入新的。

一個小技巧是附寫掉本來的 writor，這樣就不需要手動設定 composite key 的值了。如果要改已經被 reference constraint 限制的 composite keys 怎麼辦? 直接改會爆，這時候需要使用 deferrable constraints 的機制和 transaction。

不過 hybrid 法的缺點是 1. 因為維護兩套 index key 的關係, 新增修改刪除的 index cost 比較高。 2. 需要多寫上述的 code 才能省掉手動設計的麻煩。

書沒寫哪個最好，看起來是如果非得有修改 nature key 的需求才只用 hybrid 法。

第九章 Guaranteeing Complex Relationships with Triggers

stored procedure 和 triggers
使用 PL/pgSQL 做例子。

第十章 Multiple Table Inheritance

Rails 的 polymorphic associations 功能讓你可以定義兩個 table 的關係，不需要事前知道是哪一個 table。

不過，polymorphic associations 違反了 referential integrity !! 原因很簡單，既然不知道 _id 會指到哪個 table，自然也就沒辦法在 DB layer 加上 foreign key constraint

什麼是多型?

要達成多型的方式，實作上要考慮的是 STI 或 MTI：前者 Rails 有內建，後者 Rails 有用了 polymorphic 方式來達成 XOR relationships，也算是一種簡易的 MTI。

這本書用了 logical 和 physical models 來分別描述概念上和實際上的切法

STI 適用於 subclass 共用很多 data。如果共用的不多，除了浪費 table, model 也會被 getter 和 setter 污染。另外因為 class name 寫在 table 了，如果要修改 class name 會很麻煩。

這裡提的 MTI 作法是，還是為了要用到的 foreign key 開欄位，並且也為每個關係加上 belongs_to，但是允許 null 值，因為要做 XOR on columns: 要用 boolean 做 XOR，兩個還好做，超過三個就複雜了。這裡的作法很聰明，轉成數字再相加，只要檢查是不是等於 1，用這樣的方法做 database constrant check。

都加了 belongs_to，要怎麼做到多型。這裡作者使用了 reflection 和 inheritance relationship 的技巧，在 parent object 上實作了 getter 和 setter method，厲害。我們也可以實作一個 Factory method 在 parent 上，來建構適合的 sub-class。

第11章 View-Backed Models

有些複雜的 join 和 conditions 單靠 active record 寫不出來(畢竟簡單好用的東西，畢竟是犧牲一些不常使用的功能)，而必須寫一些很醜的 SQL 混雜 active record，但是這樣就失去使用 active record 的意義(與DB-independent)。如果要漂亮，只能先盡可能先撈出來，然後再從 application layer 層過濾資料，但是這樣又失去效能，畢竟撈資料是 DB 的專長。

解法是 view-backed model，materialized view。

database view 有兩個定義 1. named subquery 2. a table that is defined by an algorithm
後者的實作是，我們先用 SQL 定義 DB view，然後就可以用 ActiveRecord 代表那個 view/table，更 cool 的是，還可以加上 association!! 當然，這是 read-only 的，記得不要加 destroy。

subquery 的定義也表示，你不能對 view/ view-backed models 操作 insert/update/delete/reference/constraint/index。
references 也不需要，如果你要 reference，就表示你應該加到 view 裡，constraint 也是。

indexing 也無，畢竟是 just-in-time 撈出來的資料。但是本來的 index 欄位當然還是有作用。別氣餒，畢竟本來使用 View 的目的不是效能，而是為了讓 AR 更簡潔清楚。如果真的需要效能，下一章的 materialized view。

第12章 Materialized Views

materialized view 就是 cached 的 view。既然是 cache，就一樣有 cache 的議題: 資料的更新，何時由誰 expire?

materialized view 是 cache-complete copy of view, 也是全部都有留資料，不像 memcached 會把不常用或超過記憶體的資料移除。

幾個重點: 1. materialized view 既然是實體的 table，也就可以加 index 2. 要加上 refresh function 當偵測到 base table 有修改 3. 或是 invalidation function 如果不想馬上更新 4. 在 base table 加上 triggers 以偵測修改 5. auxiliart view, reconciler view 隱藏實作細節

不過看完還是覺得使用 materialized view 真是挺難的!! XD

故事可以從上個禮拜，Yehuda 把 Rails 2 的 Metal 移除了(commit)，根據 commit 的說明，Rails 2 的 Metal 在 Rails 3 裡面，可以用 1. 放在 Route 之前的 Rack middleware 或 2. 放在 Route 之後的一個 Rack endpoint，而這個 Rack endpoint，除了自己實作 Rack app，我們也可以用 ActionController::Metal 來實作出自己的客製化 Controller。

Rails2 發明 Metal 原因是，有些事情不需要完整的 Controller 功能，希望能夠越快越好，例如 XML/JSON API 等。而 Rails2 的 Metal 雖然非常快，但是沒什麼彈性，完全不能使用 Controller 的功能，例如用 Layout, Template, Sessions 等，基本上就跟單純的 Rack middleware 沒什麼兩樣。但是在 Rails3 中，可以透過自繼承 ActionController::Metal 做出白紙般的客製 Controller，可以有非常快的速度，如果有需要用到 Controller 的功能，也可以任意選擇組合加入，十分彈性。

例如，我們來實作一個超級精簡的 Static Controller：

# lib/static_controller.rb
class StaticController < ActionController::Metal
  include ActionController::Rendering

  append_view_path "#{Rails.root}/app/views"

  def about
    render "about"
  end
end

# config/route.rb
match '/about', :to => "static#about", :as => :about

這個範例有接近於 Metal 的速度，並加入了 Controller 的 Template 功能 (你可以參考 ActionController::Base 這是擁有全部功能的版本)。其中 “static#about” 是 StaticController 的 about action 縮寫，而在 Rails3 中，controller action 也都是一個 Rack app。

除了我的這個簡單範例，在 The Powerful New Rails Router 和 Upgrading a Rails 2 App to Rails 3 的影片中，也有分別舉例。

總而言之，如果你在 Rails3 中不需要全部的 Controller 的功能，想要盡量拉高效能，有幾種推薦作法：

* 寫成 Rack Middleware，然後在 config/application.rb 中插入 config.middleware.use YourMiddleWare
* 寫成 Rack App，在 config.route.rb 中將某個對應的網址指到這個 Rack App
* 繼承自 ActionController::Metal 實作一個 Controller，其中的 action 也是一個 Rack App

其中的差異就在於後兩者會在 Rails Route 之後（好處是統一由 route.rb 管理 URL 路徑），如果繼承自 ActionController::Metal 可以有彈性獲得更多 Controller 功能。原則上，我想我會推薦 ActionController::Metal，寫起來最為簡單，一致性跟維護性較高。

另外，還有個小玩意， ActionController::Middleware 是 Controller 層級的 Rack Middleware，讓你可以在放入到某個特定 Controller 之中(也就是只有該 Controller 使用這個 Middleware)。不過呢，這個功能我到現在還沒看到任何實用的例子就是了。

最後，Yehuda 提供了一個 參考數據：

fast: through middleware inserted at 0
slwr: through middleware inserted via @use@
rotr: through endpoint sent via the router
bare: through ActionController::Metal with self.response_body
cntr: through ActionController::Base with self.response_body
text: through ActionController::Base with render :text
tmpl: through ActionController::Base with simple render :template
layt: through ActionController::Base with render :template with layout

         real     rps
fast   0.004271   2900 Rack 極限
slwr   0.067029   2200 使用 config.middleware.use YourMiddleware
rotr   0.088085   2000 經過 Rails Route 之後
bare   0.103868   1900 使用 ActionController::Metal 的最快速度
cntr   0.355898   1070 使用 ActionController::Base 的最快速度
text   0.557127    825 使用 ActionController::Base 加上 render :text
tmpl   0.639581    765 使用 ActionController::Base 加上 render :template
layt   1.678789    375 使用 ActionController::Base 加上 Template 跟 Layout

Bundler 是一套為了 Rails3 所打造的全新 Gem dependencies 管理工具：一套基於 Rubygems 的更高階套件管理工具，適合讓 Application 管理多套 Gems 依存關係的複雜情境。而你在 Rails3 中 (Bundler 不只用在 Rails3，其他例如 Sinatra 或是 Rails2 也都可以使用) 要使用的 Gems，也都必須宣告在它的 Gemfile 裡，沒寫在裡面的話，就算手動 require 也找不到。這跟已往你可以直接 require 任意 rubygems 不同，在使用 Bundler 的環境中，要 require 什麼 rubygems 必須透過 Gemfile 管理。

Gemfile 的寫法大致如下：

  # 第二個參數可以指定版本
  gem "rails", "3.0.0.beta3" 

  # 如果 require 的檔名不同，可以加上 :require
  gem "sqlite3-ruby", :require => "sqlite3"

  # 可以用 Git 當做來源，甚至可以指定 branch, tag 或 ref。
  gem 'authlogic', :git => 'git://github.com/odorcicd/authlogic.git',
                            :branch => 'rails3'

  # 可以直接用電腦裡的其他目錄
  gem "rails", :path => '/Users/ihower/github/rails'

  # Group 功能可以讓特定環境才會載入
  group :test do
    gem "rspec-rails", ">= 2.0.0.beta.8"
    gem "webrat"
  end

設定好 Gemfile 之後，我們有一些指令可以用：

• bundle check 可以檢查目前缺少哪些 rubygem，然後你可以手動透過 sudo gem install 安裝到系統裡。
• bundle install 安裝所有需要的套件。如果系統已經有裝了，就用系統的，不然會裝到 $BUNDLE_PATH 下，預設是你家目錄 ~/.bundle (因此請不要用 sudo 執行 bundle install)。如果來源是 git (例如上述的 authlogic)，每次執行 bundle install 就會自動 git pull 更新，十分方便。
• bundle lock 和 bundle unlock 會做 snapshotting 記錄下目前所有套件的版本在 Gemfile.lock，建議這個檔案也一起 commit 出去。適合要佈署或多人開發時，可以確保大家的版本都一致。
• bundle package 如果你的 Server 沒聯外網路，或是怕 rubygems.org 連不上，可以用這個指令把所有套件都打包到 vendor/cache 下。基本上，跟以往 Rails 1.X 2.X 時代佈署時會建議你盡量打包依存套件並 commit 出去，在使用 Bundler 後已經大大地不需要了，因為透過 bundle lock 我們就可以確保每台機器上執行的套件版本一致。
• bundle exec 因為 Bundle 可以說是獨立出一個套件環境，所以如果有非 Rails 的指令需要執行，而且你的系統 Gems 又沒有安裝，那就會需要透過 bundle exec XXX 來執行。例如 bundle exec cucumber。
• bundle show gem_name 可以查看這個 gem 的目錄位置
• bundle open gem_name 可以用編輯器打開這個 gem 的目錄

開發 Rails3 實際用一陣子之後，發現很偏好將套件裝成 Gem 了(如果有提供 Gem 版的話)，之前 Rails 1.X 2.X 時代會比較喜歡裝成 Plugin，因為想說別人要裝 Gem 可能會有問題，以及佈署也怕出包。但是有了 Bundler 之後，只要 Bundle install 就可以裝好並確保大家的版本一致會動。不像已往的 rake gems:install 超不可靠。可以透過 Bundle 裝這些依存套件也減少了需要 commit 出去的 vendor/plugin 檔案，讓你的專案 repository 變乾淨了。另外，我也超喜歡的 Bundler 可以支援 Git 來源，只要 bundle install 就會更新，不需要額外的管理工具去煩惱更新 plugins。

其他推薦閱讀:

• Library Management Gets an Update in Rails 3: 一般性介紹
• ASCIIcasts 201: Bundler : 一般性介紹
• Using the New Gem Bundler Today: 有 Bundler 的設計目標，推薦看第一段即可。
• Using Bundler in Real Life: Bundle 的使用情境介紹，非常推薦一看
• Some of the Problems Bundler Solves: 深入舉例 Bundler 要解決的問題，為什麼單靠 Rubygems 和之前的 config.gem 做不到。有時間的話，也推薦一看。

  例如，其中最主要解決的問題是，目前的 Rubygems 同一時間只能 require 一個版本，所以如果你有兩個套件有不同版本的需求，例如一個套件指定需要 rspec 1.1.12，另一個指定需要 1.2.0。那就爆炸了，會出現 can’t activate rspec(= 1.1.12 runtime), already activated rspec-1.2.0 的錯誤。

• Named Gem Environments and Bundler: 深入解釋了 Bundler 如何處理 dependency 問題
• The How and Why of Bundler Groups: 深入解釋 Group 功能
• Yuhada 在 RubyConf 2009 的演講： Polishing Rubygems

完整的公告詳見 Ruby Wednesday 定期聚會，我每週三晚上會出現在生態綠，如果有意外的話(例如：那天我沒空)，請注意我的 Twitter。

這週三 (2010/5/5) 晚上我在台大有一場 “Meet Ruby on Rails” 的演講，是由 OSSF 和台大資工系學會所合辦的工作坊。

不同於上次在清大的校園課程，這次只有安排 talk，沒有安排電腦教室給學員實作。給大學生講這個題目，我目前想要多準備一點軟性題目，少談一點程式碼。像是介紹 Web 軟體開發產業、為什麼採用 Web framework、為什麼用 Rails? 為什麼用 scripting 動態語言? 為什麼用 Ruby? 以及除了學校課程以外，我認為作為一個 Web-based 軟體設計師，可以學習的方向。當然，還有 Rails 的 live demo。

某方面來說，雖然題目是遇見 Ruby on Rails，但是我希望也可以讓聽眾遇見 Web application 軟體開發的樂趣。台灣的資工系學生畢業之後，大部分都投入硬體相關產業吧 (不同於美國的軟體業產值超過硬體，台灣的軟體業產值只有硬體的九分之一，真是九牛一毛啊 :~ )。如果這場演講可以讓他們多了解 Web 軟體產業，無論是不是喜歡 Ruby 或 Rails (就算是喜歡上 Python, Perl 也不錯)，那就達到我演講的目的了。

而我這篇接下來要示範的是，如果我們想要自己寫一個 helper，可以接受 block 參數要怎麼寫? 例如在 ERB 中，我們希望這樣的程式可以輸出 header blah footer 字串：

# Rails2
<% my_helper do %>
    blah
<% end %>

在 Rails2 的話，如果有包 Block 無論如何都必須用 <% 而不能用 <%=，不然一定會有錯誤訊息。而這個 helper 最常寫成這樣:

# Rails2
def my_helper
  concat("header")
  yield
  concat("footer")
end

或是:

# Rails2
def my_helper(&block)
   tmp = with_output_buffer(&block)
   concat("header #{tmp} footer")
end

在 Rails2 中，我們得用 concat 表示輸出到 ERB (這算是一個密招，沒人教還真的不會)。但是在 Rails3，則被改成比較直覺的:

# Rails3
<%= my_helper do %>
  blah
<% end %>

以及

# Rails3
def my_helper(&block)
  tmp = with_output_buffer(&block)
  "header #{tmp} footer"
end

在 Rails3 就不需要用 concat 了，helper 的回傳值透過 <%= 就會輸出在 ERB 上。

時間: 2010/4/13（週二）晚上七點到九點。

地點: 台北市 果子咖啡

報名網頁: http://registrano.com/events/ruby-tuesday-11

關於 Performance，有四個最好不要做的事情:

• 過早最佳化
• 亂猜哪裡慢
• 到處做快取
• 與 Framework 過不去，硬要 Hack 它

然後有五條關於 Performance 的須知:

• 演算法的改良永遠勝過硬擠程式碼
• 一般來說，程式碼維護性的重要性勝過效能
• 只最佳化最需要的部份 (80/20法則)
• 測量再測量，最佳化前、最佳化後都要測量
• 必須與程式碼彈性做平衡。有時候做了最佳化之後(例如快取)，會犧牲掉一些彈性。

其他就看投影片吧。這份投影片主要還是關注在 Web application layer，也就是 Ruby 程式語言和 Ruby on Rails 上。有點小可惜的是篇幅和準備時間所限，關於 Front-end performance、NoSQL: Key-value stores 和 HTTP Caching 這三個主題是我覺得可以多講一點的東西。

有了效能，也許你會想進一步知道如何做 Scaling? 不同於 Performance 探討單一台 application server 可以服務多少 requests，Scaling 要探討的問題是如何擴展架構到多台伺服器上來服務更多流量。當然 Performance 會是做 Scaling 的一個重要的因素，不過 Scaling 需要考量的地方又更多了，包括:

• Asynchrony Processing (Message queue)
• Partition Component using SOA
• HTTP Reverse Proxy Caching
• Distributed Filesystem/Database

其中 Asynchrony Processing 和 SOA 的部份，我在 Distributes Ruby and Rails 的演講有分享過。

xdite 也有針對 Scaling Rails Site 這個主題寫了一系列的 Scaling Rails Site: Reading Material 來介紹: #1, #2, #3, #4, #5

Ruby on Rails 要談的 Security 網站安全，主要在 Web application layer 的範圍(這也是最容易被攻擊的部分)，像是 XSS、CSRF、Session Hijacking 跟 Fixation、SQL Injection 等等都是所有 Web 應用程式必須處理的問題。也有一些是 Rails 為了程式方便性而製造出來的問題，像是 Mass assignment、Unscoped finds、Controller Exposing methods 等等。

會講的內容看投影片就可以了，這裡我想特別提一下我的開場跟一個觀念:

我的開場引用了 PHP Security Guide: Overview 介紹什麼是 Security，我很喜歡：

1. 安全性是相對的，不是一個功能。碰過太多客戶要求 “網站要絕對安全，不能被 HACK”，這實在太強人所難了。安全性就跟溫度一樣，相對熱、相對冷。安全性也是相對安全、相對不安全的，而不是像功能說有或沒有。
2. 承上，要越安全，就給花越多成本去做。不過呢，不需要多花什麼錢，就可以很簡單做到足夠地安全。如果要非常非常安全，就會非常非常貴了。所以請考量你的預算。
3. 必須要與使用性(usability)做平衡。很多時候，安全性跟使用性會是衝突的，想要越多安全性，就給犧牲掉一些使用上的方便性。
4. 安全性必須是網站程式設計過程中的一部分，而不是最後才加上去。

而想提的寫程式觀念是我看 Security on Rails 一書裡面介紹的 Fail Close，底下第一段是用 Fail open 觀念寫的程式，第二段是用 Fail close。

# fail open way, it’s bad
def show
  @invoice = Invoice.find(params[:id])
  unless @user.validate_code( @invoice.code )
    redirect_to :action => 'not_authorized'
  end
end

# fail close way
def show
  @invoice = Invoice.find(params[:id])
  if @user.validate_code( @invoice.code )
    redirect_to :action => 'authorized
  else
    redirect_to :action => 'not_authorized'
   end
end

其中的端倪就是，在撰寫驗證安全性程式碼的時候，請用 Fail close 的觀念：”如果條件成功，才允許進行，不然就不允許”。而不是 Fail open：”如果條件不成功，才不允許，不然就允許。”。這個簡單的撰碼觀念，可以減少我們寫出漏洞程式碼的機會。

別猜了!! 公說公有理，婆說婆有理。讓使用者的實際體驗跟統計結果來告訴你吧。a/b testing 的作法是: 1.輪撥這些選項 2. 設定追蹤點(goal) 3. 一段時間後，觀察哪個選項達成的 goal 比較多。

而 A/B testing 工具可以幫助你很容易做好這些事情: 1. 針對不同人提供不同選項 2. 但讓同一個人看到的都是同一個選項(這是一個重點，不然測試就不準了)，例如透過 cookie 或使用者ID 3. 提供後台報表，並提供分析告訴你這些數據是否有統計學上的顯著差異 4. 方便安裝及使用 5. 夠快，不會對 production site 造成效能負擔

對 Rails 來說，目前有兩套可以考慮使用: A/Bingo 和 Vanity。A/Bingo 很容易安裝使用，功能比較陽春，使用 ActiveRecord 搭配快取(memcached) 來記錄資料。Vanity 功能比較豐富，願景也比較大，提倡了一整套的 Experiment Driven Development 開發方式。它使用了 Redis 來記錄資料。不過他的使用文件似乎沒有跟上程式的更新速度，所以不太好安裝，得去翻 source code。如果你現在就想試試，我會先推薦 A/Bingo 比較容易上手。

如果你不想改 server side 的程式(或是你是不會寫程式的行銷人員)，也可以透過 Google Website Optimizer 這套工具來做 a/b testing。Google 的方式就單純用 JavaScript 來記錄: 你先告訴 Google 你有哪幾種頁面，例如 Original page、Variation page 1、Variation page 2 三種選項，接著提供 Conversion page 是指達成 goal 的頁面，然後將 Google 會給你 control script 貼到 Original page 去(讓使用者可以輪撥到其他頁面)，以及 tracking script 貼到各個頁面。

最後，A/B Testing 當然也不是萬能的: Why A/B testing of web design fails。

ActiveSupport::Concern 是 Rails3 做 Modularity 的一個重要的小工具。他的任務是讓管理 modules 之間的 dependencies 變得容易。

假設我們有兩個 Modules 有依存關係，module Bar 依存於 module Foo，然後有一個宿主 Host 類別希望 include Bar 的功能，我們可以這樣寫:

module Foo
   # self.included 這個函式會在 Foo 被 include 時執行
    def self.included(base)
        base.send(:do_host_something) # 對宿主做某些操作，例如增強功能等等
    end
end

module Bar
    def self.included(base)
        base.send(:do_host_something)
    end
end

class Host
  include Foo, Bar
end

這有個討厭的缺點就是，我們必須在宿主中同時 include Foo 跟 Bar，也就是要把所有依存的 modules 都 include 進來。這很糟糕啊，為什麼我們需要在 Host 裡面知道這些 modules 的依存關係呢 :/

我們希望能夠將 modules 的依存關係寫在 module 中，而宿主 Host 就只要使用就好了。所以我們試著改寫成:

module Bar
  include Foo # 因為 Bar 依存於 Foo，所以我們在這裡 include 它

  def self.included(base)
    base.send(:do_host_something)
  end

end

class Host
  include Bar # 只要 include Bar 就好，不需要知道 Bar 還依存哪些 modules
end

這樣乍看之下好像沒問題，但是卻有個嚴重的問題導致無法執行，因為 Foo 變成是由 Bar 所 include，所以對 Foo 的 self.included 來說，他的參數 base 變成了 Bar 了，所以他就沒辦法存取到宿主 Host 的任何函式及變數，do_host_something 時就會失敗。

Okay，ActiveSupport::Concern 就是來幫助解決這個難題，我們希望宿主可以不需要知道 modules 之間的 dependencies 關係。dependencies 關係寫在 module 裡面就好了。

require 'active_support/concern'

module Foo
    extend ActiveSupport::Concern
    included do
        self.send(:do_host_something)
    end
end

module Bar
    extend ActiveSupport::Concern
    include Foo # 因為 Bar 依存於 Foo，所以我們在這裡 include 它

    included do
        self.send(:do_host_something)
    end
end

class Host
  include Bar # 只要 include Bar 就好，不需要知道 Bar 還依存哪些 modules
end

如此就搞定了。One more thing，如果你有定義 module ClassMethods 和 module InstanceMethods 在裡面的話，它也會自動幫你載入到宿主裡面去，就不用自己寫 send(:include, InstanceMethods) 跟 send(:extend, ClassMethods) 了。用法舉例：

module Foo
    extend ActiveSupport::Concern
    included do
        self.send(:do_host_something)
    end

   module ClassMethods
      def bite
        # do something
      end
   end

   module InstanceMethods
      def poke
         # do something
      end
   end
end

想知道 ActiveSupport::Concern 到底怎麼實作的話，請看 /activesupport/lib/active_support/concern.rb，只有 29 行，而且 ActiveSupport::Concern 也沒有再依存其他東西了，嘿。

例如:

link_to 'Logout', session_path, :method => :delete

產生出來的是:

<a href="/session" data-method="delete" rel="nofollow">Logoout</a>

例如

link_to 'Ajax delete', person_path(person),
      :remote => true, :confirm => "Are you sure?"

產生出來的是

<a href="/people/1"  data-confirm="Are you sure?" data-method="delete"
              data-remote="true" rel="nofollow">Ajax delete</a>
# 點下去會向 Server 要求 JavaScript 內容執行

Rails3 預設還是使用 Prototype.js，要換成 jQuery 非常簡單。首先在產生 rails 專案時，可以輸入 rails your_project -J 就不會產生 Prototype.js 的檔案。

修改 /public/javascripts/rails.js 這個檔案，內容換成 http://github.com/rails/jquery-ujs/blob/master/src/rails.js 這個官方提供的 jQuery js driver。

在 Rails layout 的 HTML head 中加入:

<%= csrf_meta_tag %>
<%= javascript_include_tag "http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js" %>
<%= javascript_include_tag 'rails' %>

其中 csrf_mate_tag 產生的是做 CSRF 防禦的 authenticity_token，以往這也是 inline 在 HTML 中，現在則是先宣告在 HTML head 中。

另外要提醒你，如果你有使用 RJS 的話，Rails3 的 RJS 還是只會產生 prototype.js 的版本。所以如果非得用 RJS 的話，目前恐怕還是得裝以往 Rails2 用的 jRails，這好像有點蠢。也許是時候把 RJS 徹底揚棄，直接寫 jQuery 好了(?)

例如上面的 Ajax delete 例子，它的 controller 跟 js 可以這樣:

# people_controller.rb
  def destroy
    @person = Person.find(params[:id])
    @person.destroy

    respond_to do |format|
      format.html { redirect_to(people_url) }
      format.js # destroy.js.erb
    end
  end

# destroy.js.erb
jQuery("#<%= dom_id(@person)%>").remove();