DHH談Ruby效能

上次的這篇 Joel談Ruby效能 其實DHH(RoR發明人)也有文章回應(反擊?)，我覺得更為公允實在…:p。摘要重點翻譯如下:

Outsourcing the performance-intensive functions (把效能密集的程式外包出去)

每種程式語言本來就有不同擅長的地方，例如 Yahoo 跟 Amazon 就會使用 C++或 Java 來處理 back-ends，而在前台使用PHP或Perl。而在 Basecamp 中，縮圖程式長這樣

def thumbnail(temp, target)
  system(
    "/usr/local/bin/convert #{escape(temp)} -resize 48x48! #{escape(target)}"
  )
end

看起來有點作弊，Ruby竟然直接呼叫 imageMagicK 指令。但是這不就是為什麼叫做 scripting language 的原因嗎?我們不用發明縮圖程式，因為有人已經用C寫好更快的了，同理  Bayesian filter 也是，已經有人用其他更快的程式語言寫好，你只需要呼叫即可，而且這些常常都有人寫好 wrappers了，例如 RMagick、MySQL/Ruby。

你不必只限制在只能一種程式語言來開發，在大部分情況下使用有高度 productivity 的程式語言，然後把有瓶頸(bottlenecks)的部份外包(outsource)給已經用更快的程式語言寫好的套件(packages)，或是自己寫需要的擴充(extension)。

我們在 Campfire 也碰到明顯的瓶頸 bottleneck，上百個使用者每隔三秒就要同時要更新資料，本來用100行的Ruby code，後來改寫成300行的C。整個專案保持 90% 的 Ruby code，把瓶頸 bottleneck都外包給 C。假設為了獲得最大效能(performance)而全部用C寫，那大概會發瘋吧。

所以不要讓瓶頸 bottlenecks (不管是真的或想像中的瓶頸，通常還是後者) 來支配你的軟體開發環境選擇考量。有個詞這樣描述那樣的情況，稱作 “premature optimization”。(貿然實施最佳化，是各種傷害的根源)

網站企劃推薦書籍

我是個網站開發者，我一直幻想著開發一個新網站的時候，有個漂亮的OL(這不是重點)可以寫超讚的網站企劃給我，讓我一看就知道要做什麼網站，而不是每次都給我籠統的客戶需求，定規格跟如何設計都得自己來。早些時候我看了些UML，甚至買過一本Building Web Application with UML，不過都不適合企畫人員作為給網站企劃用途，太難了，尤其是這麼小的團隊… :p

我的夢幻企畫我想可以 based on 以下幾本書: 閱讀全文〈網站企劃推薦書籍〉

Rails RESTful 實作

Update(2006/12/4): 一些小修改跟 link_to 的 web accessibility 補充。

Update(2006/12/11): 請接著看系列文章下一集: Rails RESTful 相關工具。

Rails RESTful 系 列 彈第三篇，我想 David Heinemeier Hansson 的這篇投影片是很好的開場白:  Discovering a world of Resources on Rails

本來這篇想寫的仔細點，不過後來我發現AWDwR第二版講 Resource-Based Routing 的頁數還不少(十幾頁吧，還蠻詳細的)，要用 Rails 的人應該都去買一本，我想我這裡就不巨細靡遺了… :p

在 Rails 中是如何實作 RESTful 支援的? 首先是在 Resource Routes 上，在 routes.rb 加入

map.resources :users

這樣的宣告將在自動對應 URL路徑跟 Controller 的 action ，而有以下的結果 :

GET: /users => [:action => ‘index’]
GET: /users.xml => [:action => ‘index’, :format => ‘xml’]
GET: /users/1 => [:action => ‘show’, :id => 1]
GET: /users/1;edit => [:action => ‘edit’, :id => 1]
GET: /users/1.xml => [:action => ‘show’, :id => 1, :format => ‘xml’]
POST: /users => [:action => ‘create’]
PUT: /users/1 => [:action => ‘update’, :id => 1]
DELETE: /users/1 => [:action => ‘destroy’, :id => 1]

也就是使用 named routes 來實作出 verb-oriented controllers，單一個 resource 根據 HTTP verb 而有不同的行為。 閱讀全文〈Rails RESTful 實作〉

品書．書品

還蠻不錯的一本愛書人小書，語調輕鬆(比起如何閱讀一本書簡單多了，當然份量也不同啦~)，提供一些閱讀的觀念跟技巧等等。有些跟我本來的觀念一樣，像是有系統整理書單買書。有些我則做的不好，像我還蠻有剩菜症候群的，一但開始唸一本書就算很痛苦也盡量要念完… :p

書分五章:

如何找書

整理自己想唸的書單(List of Candidates)，寫下推薦念這本書的各種來源管道。整理自己的閱讀史。當你建立書單的同時，除了是寫下了興趣所在，也是設定了你的人生目標，你的每個目標都將透過閱讀的力量去達成。

別強迫自己去讀你不喜歡的書，這世上有成千上萬的好書，何必傻得把時間浪費在無法讓你愉快又受益的書上。很多人會覺得一旦開始讀一本書之後，就必須得要讀完，這種觀念就像不想浪費食物而吃光剩菜的心態，要學會放棄。要使自己精於閱讀，你必須挑選大量的入圍好書並抽樣試閱。

讀經典文學不怕晚: 隨著年紀與歷練成長，讀文學名著所吸收的養分會比年輕時加倍豐沛。

計畫性的閱讀才能提升知識品質: 只有當你藉由主動積極地尋找好書，考量更廣泛的閱讀領域，加上用心地精挑細選，使你涉獵的書籍大半都是有計畫性的閱讀，這樣你所獲得的知識品質才會提升，而且是大幅提升。 閱讀全文〈品書．書品〉

RESTful Design 雜談

看了上一篇可能會有些混淆: 整個 Wide World Web 可以概觀看成 REST 架構，但是微觀看 Web 就不完全是了。來看看 Rails 的 URL routes 設計: 指定Controller之後指定action，基本上它是個程序性(procedural)的框架，我們利用URI syntax來決定執行什麼動作。然而 Web 基本上不是個 procedural 環境，而是 RESTful 的，但是就像你在物件導向的環境中仍然可以寫 procedural code，你也可以在 RESTful 環境中作 procedural，只是很不幸的會失去一些RESTful的優點而已。

不過這不表示Rails不夠好，事實上目前任何 web application 框架要成功，都必須支援 procedural 的開發，這是因為基本上目前存在的主流框架都是 procedural 的，人們也都習慣於procedural開發。目前的潮流只有在部分需要做 web service 的地方，會在SOAP之外另外提供REST方法(提供XML格式)，在整個網站上使用RESTful仍不多見。因此除非看到有人率先做出成功的RESTful 網站吧，雖說 RESTful is right way，但是它的觀念與大家已經會的 procedural 有著根本上的差異，所以這種改變跟限制到底能提供多少實際好處呢? anyway… 走在時代尖端的 Ruby on Rails 註定會走這對的一步 (事實上是併行: 你可以用本來的方法設計，也可以用RESTful方式)。  閱讀全文〈RESTful Design 雜談〉