Rails RESTful ActiveResource 先睹為快

在上一篇 Rails RESTful 相關工具 中有提到，ActiveReource 是一個針對 Rails RESTful APIs 所用的 client-side XML consumer，我們花了好幾篇學習為何 RESTful 跟如何用 map.resources 來架出 server-side provider，而具體的重大好處則會在 ARes 中體現出來，我們可以像對 ActiveRecord 的物件操作一樣來處理 ARes，只是它的內部運作對象變成 Resource 而不是 Database (你感覺不到你在用Web APIs :p)。

讓我們來試玩看看吧! 因為不只連 Rails 1.2 還沒 (最後關頭拉出 :p)，連 Edge Rails 版都還沒有，所以必須直接用 svn co

svn co dev.rubyonrails.org/svn/rails/trunk vendor/rails

我們用 irb 來開始實驗吧~

$ irb
> require ‘vendor/rails/activesupport/lib/active_support’
> require ‘vendor/rails/activeresource/lib/active_resource’

上回也提到 beast 是個用 RESTful 開發的討論區軟體，所以我們用 beast 來做操作對象: 閱讀全文〈Rails RESTful ActiveResource 先睹為快〉

Rails RESTful 相關工具

Update(2008/5): 事隔一年多，我對於 RESTful Rails 有完全不同的切入點，詳見 Practical Rails2 投影片。本篇的 Resource Generator 和 simply_helper 皆已內建在 Rails2 中。

Rails RESTful 系 列 彈 第四篇，我在這裡做些 Rails RESTful 工具介紹，相關文章有 REST tools for Rails 1.2。

Resource Generator

Rails 的 Generator 是最立即的學習教材，因此 RESTful 版的 generator 也有了，除了產生 model, controller, views, tests 之外，連 migration 也會產生。

ruby script/generate scaffold_resource person name:string age:integer created_at:datetime birthday:date

閱讀全文〈Rails RESTful 相關工具〉

Rails 的 lost MySQL connection 問題

不知道從什麼時候開始(Rails 1.2?)，我的 Rails 在跑 MySQL query 的時候，不定會出現 500 Internal Server Error，可是重新整理一次又可以用。看 log 檔也沒有紀錄。用 ruby script/server 直接觀察後發現 “Lost connection to MySQL server during query” 的錯誤訊息。

問了Google，發現要裝 gem install mysql。不過很奇怪都是說 Ubuntu 上要裝，在 FreeBSD 上都沒提到要裝?… anyway… 重開機之後就沒問題了。

Google Adsense for Content 支援繁體中文

終於正式開放了哩，可以在繁體中文的 Adsense for Content 設定了。之前小道消息不斷，都是用別的語系先偷跑，不過聽說這樣不合Google規定就是了。

anyway… 覺的蠻有趣的，我也試放看看能有多少收益，希望不會太影響視線… :p

有關 Google Adsense 的資訊可以參考 Adsense繁體中文觀測站。

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”。(貿然實施最佳化，是各種傷害的根源)