萬眾矚目的 Ruby 1.9.1 終於發佈了，公告詳見 Ruby 1.9.1 is released。這個版本是 1.9 系列的第一個穩定版本，大大提昇了 1.8 令人詬病的效能 (請見 Antonio Cangiano 的 benchmarks )，非常令人期待它的商業應用。
要在 Mac 上安裝起來玩玩看的話，可以這樣做與本來的 Ruby 1.8 共存 (參考自How to compile and install Ruby 1.9.1 on Mac OS X Leopard)：
curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.bz2 -o ruby-1.9.1-p0.tar.bz2
tar xjf ruby-1.9.1-p0.tar.bz2
cd ruby-1.9.1-p0/
autoconf
./configure --program-suffix=19
make && sudo make install
這樣就會有 ruby19, irb19, gem19, rake19 等指令可以用了（Ruby 1.9 內建了 rubygems 跟 rake 囉)。不過目前還很多 Gems 沒有跟上 Ruby 1.9 的腳步，尤其是需要 native build 的 Library（例如 mysql 跟 mongrel 都裝不起來）。
Update(2009/4/5) 使用 Rails 2.3.2 就不需要以下 patch 了，裝起來就可以跑了。MySQL 可以改裝 http://tmtm.org/en/mysql/ruby/ 這個 Ruby 1.9.1 相容版本。
如果有研究興趣想把 Ruby on Rails 跑起來，除了需要用 Rails edge 版本( 2.2.2 的話，需要 patch active_support/deprecation.rb 227 行用 begin … rescue LoadError; end 把整段 test 包起來)，還需要至少裝 rack 跟 sqlite3-ruby gems，另外 Webrick 也需要自己手動 patch 如下(這是因為 Ruby 1.9 把 String #each 拿掉了)：
class String
def each
self.split($/).each { |e| yield e }
end
end
成果是 Ruby 1.9 on Rails 有圖有真相：
一般在台灣簽軟體開發合約，最常見的就是固定價格、固定規模的合約（最晚何時要交出符合這些規格的軟體和文件），但是碰到的問題就是兩造雙方都覺得需求定不清楚，而陷入對立的情形。接案的希望少做、出錢的希望多要一點，所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途客戶又不斷加規格、需求頻繁變更或是任何意外，往往就就會開始 Delay，一旦專案延遲，第一個犧牲的就是開發品質了，例如省掉測試作業等。變成開發範圍太大 -> 無法如此交貨必須加班 -> 品質降低的惡性循環。
但是要採用敏捷開發，這種合約要怎麼寫啊？敏捷開發不就說專案一開始不需對規格詳細內容做決定嗎？
XP 方法論提出四個互相影響的專案變數：成本、時間、品質、開發範圍。也就是如果定死價格、時間和範圍，品質就會變成可犧牲的變數。XP 派別認為這四個變數，最常、最應該可以變動的就是開發範圍，也就是定好價格、時程和品質，但是要做什麼再談。回到合約上看，也就定期限、定總價但不定規格，例如 Kent Beck 建議的：『供應商將提供八個程式設計師為顧客服務，並且兩個月的金額是 $1,000,000。規模每兩週協商一次，協商時根據 XP 方法進行』。
但是不定規模對顧客而言最大的擔心，就是他想要知道他花了 $1,000,000 到底可以得到什麼，因此在台灣還很難接受這種合約方式，照 Kent Beck 的說法，只能玩成價格固定、交期不變、規模求個大概。例如我們和多就使用 User Story (註)的方式來定規模，保留與客戶溝通及實作的彈性，又有可以拿來估價的基準。雖然都會將專案時程切到至多三個月（一季）來做最大的估價範圍，不過還是會有一開始低估規模而造成專案 delay 風險（所以加強專案的估計技巧也是個努力的方向）。
另一種在台灣常見合約的作法，是分成兩次簽約跟報價，第一次簽約預備開發期，目的是要完整討論出需求跟規格，這部份就會先收取一次費用。第二次簽的約才根據詳細規格再報一次總價。不過這種方式基本上就把敏捷開發一開始『規格不確定也無妨』的優點給犧牲掉了。
還有一種簽法就是計時合約（顧問費），花了多少時間就請多少款，但是基本上這跟固定價格、固定規模型的合約還是有一樣的利益矛盾問題：供應商為了多賺點錢，會希望多加人、多加班多報一點時數。客戶則想要在人力、時間盡可能少的情況下，做出盡可能多的功能。
各位接案的前輩們，你們是怎麼做的呢？
註：
User Story(使用者情節)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶需求，因為實做細節將延後至開發時才會確定。
幾個 User Stories 的範例如下：
- 使用者可以在網站上張貼履歷
- 使用者可以搜尋有哪些工作
- 公司可以張貼新工作
- 使用者可以限制誰可以看到他的履歷
參考資料：
- 極致軟體製程 (Kent Beck)
- 規劃極致軟體製程 (Kent Beck)
- Extreme Programming 理論與實務 (Japen eXtreme Programming User’s Group)
- 同人的生活派對 » 合約與需求變更
- User Stories Applied (Cohn)
