ihower { blogging }

實戰敏捷開發 Practices of an Agile Developer (2) 需求篇

這一章是 Delivering What Users Want。我們總是幻想客戶一開始就確切告訴我們需要什麼，然後做完收工拿錢即可。不過事實總是中途加入一開始沒有提到的功能跟規格變更。敏捷開發不去試圖”擊敗”這些變更，而是把重點放在如何快速辨認及適應這些改變，並在時程及預算內做出真正符合用戶需求的軟體。
閱讀全文〈實戰敏捷開發 Practices of an Agile Developer (2) 需求篇〉

使用 Passenger (a.k.a mod_rails) 開發 SSL 網頁

承上一篇使用 mod_rails 當做開發環境，要在 local 開發測試 SSL 網頁，使用 mod_rails 是最方便的選擇，以下是我在自己 Mac Leopard 上的安裝步驟：

首先是產生 SSL Keys


Generate certificate

openssl req -new > server.csr openssl rsa -in privkey.pem -out server.key openssl x509 -in server.csr -out server.cert -req -signkey server.key -days 365

然後把產生出來的 server.key 跟 server.cert 放到 /etc/apache2/ 下，然後都 chmod 成 400 唯讀。

編輯 /etc/apache2/httpd.conf，打開 Include /private/etc/apache2/extra/httpd-ssl.conf
刪除 /etc/apache2/extra/httpd-ssl.conf 從 SSL Virtual Host Context 以下的所有設定
編輯之前設定好的 <VirtualHost *:80> 區段整個複製一份，並改成 443。然後在其中加入以下：

SSLEngine on SSLCertificateFile /etc/apache2/server.cert SSLCertificateKeyFile /etc/apache2/server.key

至此就裝好了，重開 apache 即可，還蠻簡單的。

實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇

敏捷軟體開發一直是我們內部開發的核心概念，強調個人、合作、回應和使用工作軟體(wiki, version control, unit testing, build automaion)，2001年由一群軟體開發者發表宣言如下：

個人及互動勝於流程與工具
可用的軟體勝於詳盡的文件
與客戶合作勝於合約談判
回應變化勝於墨守計畫

軟體開發是連續(continuous)的，不是最後才測試，也不是最後才佈署，更不會停止收集需求跟feedback。正是因為開發軟體是如此複雜的活動，任何種類的錯誤如果不儘快修正，往往最後就會無法控制的失敗，因此唯有每天不斷的一點一滴的去修正，每天解決一些比較小的問題而不是最後脫韁野馬的大問題，這才是解決的辦法。

何謂 Agility 的定義，作者給了：
“Agile development uses feedback to make constant adjustments in a highly collaborative environment.” (敏捷開發是一種在高度合作的環境中不斷根據回應來做修正的開發方式)

透過經常性地建構出可以實際使用的軟體，我們持續得到 feedback。程式碼會因為需求擴充而不斷地被修改重構演進。工作的流程被拆成一至四周的短 iterations，每次透過 demo 得到 feedback，確保方向正確。

敏捷開發最大的不同到底是什麼呢? 這本書不談方法論流程(XP、Scurm等)，而是談人本身，談團隊本身，談如何成為一個敏捷的開發人員。書的每一章由數個 Tips 組成，整本書共45個 Tips 來敘述什麼是敏捷的做法。這本書也得到2007年的 Jolts Productivity Award。

前兩章 Beginning Agility 跟 Feeding Agility 講的是基本的專業態度：

閱讀全文〈實戰敏捷開發 Practices of an Agile Developer (1) 專業態度篇〉

RailsConf 2008 投影片選

一年一度的盛事結束了，大概翻了一遍目前可供下載的 RailsConf 2008 Presentation Files，我自己最喜愛以下四份投影片，談如何寫出更好的 Rails/Ruby 程式碼：

Advanced Active Record Techniques Best Practice Refactoring
用一個實際的例子，告訴你如何正確運用 Active Record 機制，將大部分的 Controller 移至 Model。
The Worst Rails Code You’ve Ever Seen (and how not to write it yourself)
挺有趣的投影片，舉例一些有點誇張的爛code。結論是請把 Ruby 基礎學好啊，跟厲害的人一起 co-work，多唸點書 (啊啊~可是講者的 Rails Way 一書好厚啊~)。
Refactoring Your Rails Application
Rails 重構型錄 Paper 真是不錯，如果再搭配 Martin Fowler 重構一書服用，保證你對如何寫出漂亮的code超有想法。
“Design Patterns” in Ruby
引述結論： “traditional” design patterns rely heavily on structure to solve problems, dynamic languages use language facilities to create simpler solutions.

使用 httperf 做網站效能分析

Update(2008/7/8): 推薦Topfunky’s bong搭配使用，非常簡單。

做網站效能調校，一件重要的事情就是量測(measure)。調之前測一次，調之後再測一次才知有沒有藥效。

“Server 回應 requests 的速度有多快？” 就是一個最基本的問題。這技巧也叫做黑箱分析(Block-box analytic)。Advanced Rails 一書中給了幾點特別要注意的事項：

有台 front end server (Apache,Nginx等)先測試 static files，這個數據是一個上限。Rails 不會比這更快了。
找近一點的地方測，減少網路 latency 的變異性
不要用 server 同一台測試，雖然 CPU 不太會是問題，但是 I/O 可能會有影響。

觀測的數據除了平均，更要看標準差跟計算信賴區間，因為除了平均之外，低變異也很重要。基本的統計學告訴我們，相差平均一個標準差可以涵蓋 68% 的資料，相差兩個標準差就可以涵蓋 95% 的資料。因此我們可以算出 95% 的信賴區間，也就是 95% 發出的 requests 中，可以在幾秒到幾秒內回應。基本的統計知識是做 analytic 必備，Zed Shaw 為此還寫了篇Programmers Need To Learn Statistics Or I Will Kill Them All。

在 Mac 上透過 MacPorts 安裝 httperf 很簡單，輸入 `sudo port install httperf` 即可。

httperf 的用法

基本用法是指定 Server、Port、URL和總共要發出多少個 requests：
httperf --server project1.local --port 3000 --uri /events --num-conns 1000

其中最重要的 output 資訊就是 Reply rate 有平均和標準差的那一行。要注意的是 httperf 是每五秒抓一次樣本(sample)，根據 httperf 的建議是希望至少有 30 個樣本數才能得到準確的標準差，因此當 sample 數太少的時候，要記得把 –num-conns 往上加。

另一種算壓力測試，也就是去測試“Server 每秒可以承受多少 requests？”。請再加上 –rate 跟 –hog 參數：

httperf --server project1.local --port 3000 --uri /events --num-conns 5000 --rate 500 --hog

逐步把 rate 往上調，直到 server 超過極限時，就會開始少 replies (有 requests 被 drop off 了) 並出現 Errors。

Rails 的相關設定

有幾項設定可以增加更多相對比較數據：

透過 config.action_controller.perform_caching = false 的設定可以在 production mode 也把所有 caching Page, Action, Fragment 暫時關掉
暫時註解掉 before_filter 中的權限檢查
透過 session :off 關掉 session