ERubis ：快三倍的 ERB

從這個網頁看到的好東西。一個語言一開始速度不佳沒關係，只要一紅起來，一定會有人幫你加快速度的。JAVA 一開始是這樣沒錯，看起來 Ruby on Rails 漸漸要開始脫離速度尚可的名聲了。Webrick 太慢了，所以 Zed Shaw 寫了 Mongrel 。ERB 速度尚可，就有人寫 Erubis ，讓你的 ERB 可以飛快的執行沒有負擔。

Erubis 是用 Ruby 寫的，但是速度居然比用 C 寫的 eruby 還要快。最重要的是，他可以不用改寫現有的 Rails code ，就直接讓 Rails 使用，這就相當的可怕了。下圖是 ERB 跟 Erubis 的比較圖我們可以發現到他的速度幾乎是 ERb 的三倍快。

安裝

至於安裝方式的部份，我們用 gem 來安裝

gem i erubis

1. 你可以在 application.rb 或是 config/enviroments/ 裡面加入

   require 'erubis/helper/rails'
   suffix = 'erubis'
   ActionView::Base.register_template_handler(suffix, Erubis::Helper::RailsTemplate)
   #Erubis::Helper::RailsTemplate.engine_class = Erubis::EscapedEruby ## or Erubis::PI::Eruby
   #Erubis::Helper::RailsTemplate.default_properties = { :escape=>true, :escapefunc=>'h' }

2. 將你的 .rthml 改成 .erubis
3. 最後要注意，layout 裡面 yield 的部份要改成以前的 @content_for_layout

測試結果

根據我的測試，的確感覺比較快，但是快多少很難說，畢竟 render 所佔的部份不重。相容度的地方，目前一般頁面完全沒有問題， 除了 @content_for_layout 跟修改 template 檔名以外
，完全不用改寫 code 。Cache 跟 AJAX 的部份還不確定有沒有問題，如果沒問題，那這個東西一定會大紅起來。

題外話，這個東西給我的感覺，想做成一個 Univeral 的 template engine ，不只支援 Ruby ，PHP，JAVA ，Javascript，C，Scheme 都有支援，不過支援程度還很小兒科啦＠＠！

Rails 的 High Traffic 負載度

看了對岸的 《程序员》10期特别策划：Web开发之华山论剑裡面的評論，裡面有一段（原文為簡體，我直接翻譯成繁體）

如果你打算用 Rails 給自己寫個 Blog 或是小型的 Web 2.0 應用很合適，比如 37 Signal 開發的 Basecamp.com 和 Robot Co-op 開發的 43Things.com 採用 Rails，這些Web2.0 的小應用每天頁面訪問幾十萬，數據庫紀錄數不到百萬，負載是比較輕的。

看完真是無言，43Things 最好 Traffic 那麼少，根據 Alexa 的數據，43Things.com 的 Daily Reach 每天大約是 600 Million 。雖然 Alexa 的數據準確性有很多人質疑（我是很質疑這個數字啦），不過這個流量數要硬說成只有幾十萬也差太多了吧。

我列一下一些用 Ruby on Rails 的高 traffic 站台。我之所以用 Alexa 的原因是因為我不可能拿到下面站台的 Traffic 營運資料，所以我只能使用看似不是很準的 Alexa 來比較。

1. A List Part：Alexa 上面的數字最高衝到 1500 Million Day Reach ，已經是流量很不錯的站台了，Daily Reach 今年一度到達國內 Webs TV 網站的一半。
2. Penny Arcade：Alexa 800 Million Daily Reach，數字是蕃薯藤新聞的兩倍。
3. 43Things.com：今年上半年 Daily Reach 跟 A List Part 差不多，Alexa 數字是 600 Million Daily Reach，依照比例大概比蕃薯藤新聞多了一點Daily Reach。
4. Odeo.com：這個站依照 Alexa 大概也跟蕃薯藤新聞差不多，不過少了一點。他是 Podcast 聲音檔案的網站，頻寬的消耗度是相當可怕。（雖然 Ruby on Rails 的覆載度跟 Handle 頻寬的能力，沒有直接關係XD）
5. jobster：一個找工作的 Social Network，平常上去的人不多，只有一二月跟八九月特別多人（找工作的旺季），流量大的時候跟現在的樂多差不多流量。
6. Basecamp：讓 Ruby on Rails 誕生的指標性網站， Daily Reach 大致上跟 Odeo.com 差不多。我有使用過一段時間，他的權限系統相當的複雜，不用 Ruby on Rails 那麼簡單的東西寫會很難寫。
   
7. Eins.de：雖然比他流量大的網站還很多，但是 procs.net 在這篇文章有特別講到他的架構。軟體使用純 Open Source 的架構，硬體使用光華商場叫的到的貨色，一天可以服務 1.2 Million 動態網頁。對 Ruby on Rails 的高覆載度有問題嗎，這篇文章可以打破你的疑惑。
8. Hemidemi：我所知道國內第一個 Ruby on Rails 網站，站長是我學長 XD，這一兩個月成長開始爆發。
9. JaveEye：我最常舉的例子，根據通过JavaEye2.0网站看ruby on rails性能這篇的說法，JavaEye 只用到一台光華商場買的到的機器，也就是 Web Server ，DB Server ，Mail Server ，Search Server 都在同一台。純 Open Source 的架構，一天處理個 50 萬應該沒問題。

如果這些網站，還無法堵住『如果你打算用 Rails 給自己寫個 Blog 或是小型的 Web 2.0 應用很合適』這樣的嘴，那麼我也沒話說了。因為 Ruby on Rails 很年輕，所以用 Ruby on Rails 開發的站台大多營運時間只有一年不到，一個新興網站其實有上面那麼多流量其實已經很嚇人了。如果再過個一年，或許會有流量更驚人的 Ruby on Rails 網站出現。

最後，當網站負載度到達一定程度，任何語言都不能可能承擔這樣的流量，所以網站的負載度還是看彼此的架構好壞，不是取決於語言本身，絕對沒有一個站台只靠 PHP 或是 CGI 就可處理所有Request 的。語言或是框架對於乘載度的差別在於『轉換高流量負載架構的彈性』，這點 Ruby on Rails 作的真的不差。

PS. Measure Map 是用 Ruby on Rails 寫的，已經被 Google 買下來。

TIOBE 11月排行：Ruby 大邁進

終於出爐了，出處在此。這個月果然如上個月預料超越了 SQL 成為第 12 名，不過根據上個月的推測，本來以為可能會多花點時間從 1% 上升到 2%。結果這一個月的上升的幅度高達 0.635%（注1）。這個上升幅度實在是相當的驚人，TIOBE 的標題也用 Ruby is rocketing skywards來形容這個月 Ruby 的大邁進。照這個上升率，說不定下個月就直接三級跳，幹掉 SAS ，Delphi，Javascript 成為第九名。只要晉升到前十名，名單上大概都是赫赫有名的程式語言，也正式宣告 Ruby 進入主流語言的行列。下面的表是這周的排行，下面的圖是今年 5 月 Ruby 進入前 20 名之後的上升圖。

注1：上個月的佔有率是 1.082%，這個月大幅度升高到 1.717 %

Position Nov 2006	Programming Language	Ratings Nov 2006	Delta Nov 2005	Status
1	Java	20.400%	-1.87%	A
2	C	17.198%	-1.16%	A
3	C++	11.055%	+0.25%	A
4	(Visual) Basic	9.470%	+1.89%	A
5	PHP	9.209%	-1.57%	A
6	Perl	6.228%	-0.91%	A
7	Python	3.641%	+0.87%	A
8	C#	3.023%	-0.26%	A
9	JavaScript	2.310%	+0.43%	A
10	Delphi	2.252%	+0.79%	A
11	SAS	2.210%	+1.03%	A
12	Ruby	1.717%	+1.28%	A
13	PL/SQL	1.223%	+0.15%	A

Comet For Ruby on Rails and Mongrel

Comet 這個詞出自於 Dojo 作者 Alex Russell 在 2006/3/3 發表的 Comet: Low Latency Data for the Browser 。簡單來說就是讓 Browser 跟 Server 作一個長時間不斷線的連線，然後我們要在 Web 撰寫 Rich Client 的程式就相當的容易。有人推測這可能是一個超越 AJAX 的技術。

Comet 跟一般常用的 AJAX Polling 作法有相當的不同。Polling 簡單來說就是每過一段時間，去問 Server 有沒有變化，這個作法的好處是不更改現行的 Web Server 架構即可做到，缺點是會造成 Server 跟頻寬相當大的負擔。下面有一份 Alex 畫的 AJAX 與 Comet 之間流程比較圖



至於 Comet 的目的是讓 Client Server 保持連線，Server 狀態一有改變，就傳一份給 Client。作法有 HTTP_Streaming、Server Push，HTTP Streaming 我還沒有 survey ，不過 Server Push 技術我發現 vgod 的文章講的很好，也很清楚

這個方法一開始還是由client先對server建立連線，但是server在建立起連線後，送出的header中要把content-type設為” multipart/x-mixed-replace”，意思是server之後要分好幾次送出許多片段資料，請client保持連線不要中斷，並且把每 次拿到的新片段取代之前的舊片段。接著，client就只要在這條保持不斷的HTTP連線上等著收server送過來的資料就好了。

Comet 的好處是不用像 Polling 一樣耗費太多不必要的頻寬，壞處是 Web Server 架構要修改程式成 Comet 的運作方式，在Browser 部份也有問題要修改，因為 IE 不下載完成就不顯示網頁，必須使用 iframe 或是 Flash 來幫忙做到抓取即時資料的任務。在目前來說，因為缺乏 Server 大環境的支援，短期內大流行的機率不高。目前已經有 Lightstreamer 的即時財經訊息，感覺很不錯。（下圖為 lightstreamer 裡面的即時股市資訊）
這是目前使用 Comet 技術的公司已經有

• GMail’s GTalk integration
• Jot Live
• Renkoo
• cgi:irc
• Meebo

介紹完 Comet 了之後，你認為這還只是構想而已嗎？我發現到 Ruby on Rails 社群對於 Comet 是相當接受，現在已經有 Comet 的 Plugin : Juggernaut 。這個 Plugin 附帶了一個用 Ruby 寫的 Push Web Server，在 Browser 端使用 Flash 6 來接收 Server Push 過來的資料，可以說是實做相當的完整。這裡也有一份簡介。另外也有人寫了一份擁有 Comet 功能的 Mongrel 。看到這邊，已經很興奮了。我們可以使用 Juggernaut 的 Flash 6 Client ，然後 Server 端使用 Reverse Proxy 轉到 Mongrel Cluster當作 Web Server ，這樣環境架設問題似乎都解決了。



仔細看看這種作法， Reverse Proxy + Mongrel Cluster 幾乎也是 Ruby on Rails 社群的標準作法，不論速度或是穩定度都表現都相當不錯。而且這種搭配方式可以用最少的伺服器轉換成本（不用改寫 Apache 或 Lighttpd），而達成 Comet 的目標。也就是說，Comet On Rails 已經不是只聞樓梯響的階段了，只要 Comet Mongrel 進入 Stable 階段，隨時可以給企業使用。

參考閱讀

1. Comet: Low Latency Data for the Browser
2. Comet : 超越 Ajax 的新技術?
3. comet server push turbogears
4. Juggernaut: Comet for Rails?

YARV 還在進步

雖然上一篇本人基於 YARV 的單打獨鬥，對於他的未來產生質疑。不過今天 JavaEye Suninny又提出一篇關於 11/1 svn 版本的 YARV 的 Benchmark ，11/1的版本不論執行時間或是Memory耗費都有一定程度的進步，讓我馬上把對 YARV 發展速度的質疑都吞了回去。底下是測試數據，Test Case 在這裡有詳述。

A 實驗，在Ubuntu 下面測試，YARV SVN : 9/17 vs 11/1
執行時間
9/17 : 3.36 sec
11/1 : 3.10 sec
Memory
9/17 : 91M
11/1 : 64M

B 實驗，在Ubuntu 下面測試，YARV SVN : 9/17 vs 11/1
執行時間
9/17 : 4.11 sec
11/1 : 3.73 sec
Memory
9/17 : 3.2M
11/1 : 2.2M


我個人是比較看好 JRuby 的發展，畢竟商業的力量才是推動世界進步的主力。但是 YARV 才是我內心真心為他搖旗吶喊的 VM ，加油呀。（我 C 超級差，沒辦法幫上忙寫Code >_<）

Ruby Thread

JavaEye 有一篇文章 Ruby的伪线程，講述的是 Ruby 在 Thread 的問題。在目前為止，Ruby 的 Thread 還不是 native thread ，所以根據 jack 的說法

这样做的确使得Ruby的Thread很容易控制，程序也不容易产生类似死锁这类严重的线程问题。但是效率始终无法提高，因为在ruby进程中，实际上只 有一个真实的线程在运行，同样的代码在那么多核或者多cpu的电脑上运行效率和单核cpu的电脑上的效率并不会相差多少。

當然 Thread 對於 Performance 對於效能的進步是有很大的幫助啦。不過目前 Ruby 上面最有希望的 Native Thread Virtual Machine ：YARV 目前處於緩步狀態。（一個人作實在太操了）並且 YARV 到目前並沒有完整的計畫支援 continuation 的計畫，這實在對 Ruby 社群更加減少了使用 YARV 的動力。

根據 Another Year, Another Interpreter 這篇文章，更是拋下一個震撼彈

And then Matz and Koichi dropped the bomb: Ruby 2.0 would support neither continuations nor green threads.

真是太慘了，看來 Thread 在 Ruby 還是遙遙無期。這時候，Ruby 社群應該把重心投入在 YARV 上面，還是剛剛傳出大捷報的 JRuby 上面呢？畢竟 JRuby 是 Native Thread 的，目標也是可以在 JVM 上面跑 Ruby on Rails （目前 JRuby 確定可以跑 Active Record ）。這似乎是一個好選擇，不過 Ruby 社群是不是願意將所有籌碼壓寶在 JRuby 呢？JRuby 現在可是由SUN 這家商業公司所主導的。

當然就算 Ruby 支援 Thread ，也會有很多問題要解決。Rails 本身不是 Thread Safe 的，Zed Shaw （Mongrel 作者）也說 Meta Programming 有很多 Thread Safe Probelm 。總之，Thread on Ruby 是一個難題，短期內也應該不會有很好的解法。

簡單的回應 JeffHung 的文章

偶然看到JeffHung 一篇文章

我還是不了解 RoR 好在哪裡。Web application 的問題一直都在套版與 scaling。套版問題將會隨著 CSS 的普及，以及如 ZK 這類 framework 的出現，而得到解決；而 scaling 則要看工程師們所施展出來的種種藝術。但我認為 RoR 根本沒有解決這些重要的事。

Ruby on Rails 的好處在於開發時間的大幅度縮短，以及程式碼的量大幅度減少，關於這兩點我想我 COSUP 講得很清楚了。至於套版的問題？老實說我無法抓到這個點。或者說，我根本不知道目前 Web Application 有啥樣板的問題，所以就不回應了。

Scaling 的問題很重要，但是這不是 Ruby on Rails 或是 PHP 應該作的事情，這是 Web Server ，DB Server ，Application Server 要作的事情。沒有任何一個大網站可以只用一個語言就可以 Handle 所有的 request ，一切都還是要歸功於 CIO/MIS 背後架構規劃，軟硬體設定的功力，這是任何一家公司躲不掉的付出。如果你希望一個框架就可以解決 Scaling 問題，不如先去問小叮噹比較快。

你所選用的框架或是語言能夠為 Scaling 所做出的付出，就是隨時保留 Scale 的彈性，這點 Ruby on Rails 可以使用 Mongrel ，Memcache Client，Capistrano ，View Cache ，Multi DB 等等 Solution ，都賦予Ruby on Rails 相當大的彈性去作到 Scale。如果你想看範例圖的話，proc.net 這一篇文章裡面圖的部份就很清楚，或是使用 Reverse Proxy 的動作來作 Scale 的議題。這次 COSUP 的 Talk ，我將重點鎖定在開發時間，但是並不代表 Ruby on Rails 只有開發時間強。很多東西要講真的可以講的很細很繁瑣，如果真的要花時間講出來，相信大家也覺得很無味，所以我選擇不討論。

RoR 可以大幅簡短開發時間？任何一個資深的 PHP programmer 大都早已自己實做了一套自用的 RoR，以應付那些層出不窮的小型資訊系統專案，差的只是包裝好壞罷了。

究竟有那套 PHP 寫出來的東西，或是那個資深 PHP Programmer 寫出來的 Framework ，開發時間可以媲美 Ruby on Rails ，請拿出來，我很想看看。Framework市面上一堆，但是開發時間像 Ruby on Rails 那麼神奇的，抱歉，我認為目前沒有。（個人用過 Symfony 跟 CakePHP ，對於他的優缺點都略有了解）如果 PHP 真的已經有那麼好的框架，那那麼多人一窩蜂花時間去學名不見經傳的 Ruby 是嫌時間太多嗎？

在理想上，若 rails 做得好的話，可以在內部搞定。但這是理想，rails 還這麼「年輕」，我不認為可以搞定 Complex/optimized SQL statement construction from object-oriented context 這件事。

基本上，如果這個 Framework 是針對 MySQL 或是特定一個 DB，這是有可能做到的。但是 Ruby on Rails 身為一個跨 DB 平台的 Framework ，他本身設計上，就不應該存在著 Complex/optimized SQL statement 的概念，因為每個 DB 對於 SQL optimize 的方式都有相當大的不同。但是 Ruby on Rails 在設計上面就已經有optimized SQL statement 容許的彈性 。如果單純是用在 retrive 上面的話，find_by_sql 加上 Active Record 去處理 Bottleneck SQL 已經相當夠用。如果是其他 SQL ，在 Ruby on Rails 裡面，我們還是可以做到針對特定 DB 進行內部 SQL 實做的 Optimize ，而且因為 Ruby 語法 Open Class 的關係，很容易實做出來。

我絕對不反對有人提出質疑，討論時白刀子進紅刀子出比較容易跑出更好的結論。所以，你可以在這個 Talk 過程中 Challenge 我，我很喜歡這樣，因為通常會激出一些新的火花。或許你也可以私底下問我，寫信給我討論，如果是 Web Design 或是 Ruby on Rails ，我最起碼還回答得出一些東西。但是如果你不問我，也不去試著去了解 Ruby on Rails，就因為rails 還這麼「年輕」這個理由，就給予『我覺得RoR作不到...』這樣的批評。這不是一個很好的方式，也不是一個很好的求知態度。

為你的 N:M Join Table 加入屬性

原本的設計

N:M Join Table 一般來說，通常只有兩個 Column ，兩個都是另外兩個 table 的 Foreign Key。舉例來說，假設今天有兩個 Table ，一個是 people ，另外一個是 firend_relations。人跟人之間的朋友關係由 friend_relations 來描述，所以 friend_relations 裡面的欄位應該有

1. person_id
2. friend_person_id
   

根據 Agile Web Development with Rails這本書，裡面有一段話

Active Record automatically includes all columns from the join tables when accessing rows using it. If the join table included a column called id, its id would overwrite the id of the rows in the joined table.

如果 join table 裡面，加上 id 這個欄位的話，當我們使用

Person.find(1).friends.each do |friend|
puts friend.id
end

這裡的 i.id 不是朋友在 people 這個 table 裡面的 id ，反而是 Join Table friend_relations 的 id 。也就是說，Join Table 裡面除了 Foreign Key 以外的欄位，都會覆蓋掉所有關聯性 Table 的欄位。這在 Coding 時，很容易造成混淆，必須盡量避免。

好處？

但是有時候這個特性很好用，假設有一需求。我想知道我跟你之間的朋友關係是啥時建立的？我們如果將這個時間 created_at 寫在 Join_Table frined_relations 裡面，那麼

Person.find(1).friends.each do |friend|
puts frined.created_at
end

這裡的 i.created_at 就是 freind_relations 裡面的 created_at （朋友關係建立的時間），而非 people 裡面的 created_at （person 資料建立的時間），因為已經被覆蓋掉了。的確，當你使用到 person.friends 的時候，通常你在使用 朋友關係 的資料，而非 這個人的基本資料 ，所以他被覆蓋過去也是很合理的。

我們還可以在 friend_relations 加入 relation 這個 column ，裡面放 '點頭之交' ，'朋友' ，'好友'，'密友' 之類的關係，可以作出

Person.find(1).friends.each do |friend|
puts friend.name+'是'+friend.relation
end

結果就會出現

小李是好友
小王是點頭之交
小陳是朋友

之類的結果，可說是相當方便的特性。

Bug? 還是特色？

不過今天發現了一個問題，HABTM 的 Table 在 Ruby on Rails 裡面是 read only ，我們無法寫入 Attribute （因為他沒有相對應的 Model），並且當我們使用 << 傳入 HABTM 關係時，我發現到假設 JOIN Table 有任何 column 跟傳入的 Column 同名，他會直接寫入 JOIN Table 裡面，也就是說假設，friend_relations 跟 people 都有 created_at 這個 column

a = Person.find(1)
b = Person.find(2)
a.friends << b

這個時候，friend_relations 裡面的 created_at 的確有新的值輸入，但可惜不是創造關係的時候的時間，而是 b 的 created_at 時間。如果我在 friend_relations 加入一個 Person 原本就有的
column，像是 name 好了 。我發現到執行上面的程式他會直接將 b 的 name 欄位直接寫進去，這真是太有趣了。

根據 Rails 的 Many-to-Many 討論 這篇的講法

主要來說 has_and_belongs_to_many 比較簡單，但是那個 join table 不適合再加欄位值，比如說該關聯建立的時間之類的，雖然 push_with_attributes 這個方法可以塞資料進去，但是卻是很亂的糟方式，已經不被推薦使用。

而 has_many :through 功夫多一些，結構更完整，用新增一個 join model 的方式來建立關聯資料。自己有一個 model class，因此使用上也比較豐富。就像一般 model 一樣，先 new 一個出來，assign 好那兩個關聯物件，再填好其它資料，最後 save 即可。

還有 Many-to-many Dance-off! 讓我新發現到 has_many :through 這個方式。我正在仔細思考重構的方式。不過在 Project 重構之前，我先使用 push_with_attribute 進行簡單的 Bug Fix

class User < ActiveRecord::Base
def add_friend user
firendss.push_with_attributes( user , :created_at => Time.now )
end
end

如此最起碼可以使用

a = Person.find(1)
b = Person.find(2)
a.add_friend(b)

達成最起碼的 BUG Fix。

結論

這個特性已經 缺點多於優點了 ，不推薦。雖然 push_with_attributes 可以寫入，但是不能修改，所以只能作一次性的寫入，像是 created_at 還能用，其他的就有問題了。

中文 Ruby 使用者星球

11/1
因為手邊的機器不能拿來亂用，所以只好找上只有 PHP 的學校機器來架設台灣 Ruby 使用者星球，目的是所有台灣 Ruby on Rails 使用者的 Blog Feed Aggreator 。今天更新了 Mollio 佈景主題，真是太漂亮了。

11/7
我增加了對岸的Ruby 社群的 Feed ，並且改名叫做中文 Ruby 使用者星球，不過首頁主頁看到的還是台灣的文章。

如果有哪位網友想加入的，可以在這篇留個回應給我，我看到就會馬上加入的。

Windows 上面安裝 Ruby on Rails

其實不太想寫 Windows Tutorial的原因是因為

1. 我手邊沒有 Windows，無法測試正確性
2. Windows 安裝很簡單，也不太需要寫 Tutorial

是的，我沒有 Windows ，不是因為反微軟，只是單純覺得 MAC OSX 桌面使用比較好用，Linux FreeBSD 架站比較好用，那我幹麼用比較難用的系統？

我可以寫 Ubuntu ，Gentoo，FreeBSD，Fedora ，MAC OSX，原因是因為我都有機器可以測試，不過我就是沒有 Windows。但是因為太多人問我了，連我同事都問我＠＠！，我還是寫一篇解救一下我的 Gmail 收件夾吧。以下文章均是來自其他網頁報導，我本人沒有機器可以測試，錯了請見諒。

首先在 Windows 上面安裝 Ruby on Rails 很簡單，有兩種方式

1. 一次大雜燴全部安裝好
2. 分批安裝

我們來看看第一個方法，也應該是最快的方式，使用 Instant Rails 來一次全部弄好，Instant Rails 網頁上簡介是

Instant Rails is a one-stop Rails runtime solution containing Ruby, Rails, Apache, and MySQL, all preconfigured and ready to run. No installer, you simply drop it into the directory of your choice and run it. It does not modify your system environment.

所以安裝他一次就可以將所有 Ruby on Rails ，Apache ，MySQL 都裝好，有種 Appserv 的感覺。並且你還可以額外安裝 Typo, SCGI, Mongrel, 和 HighLine ，最近他連 Rad Rails 都有附，真是太簡便了。這裡有一個 Tutorial 有關於 Instant Rails ，可以看看。

其次的安裝方式是先裝 Ruby ，再用 gem 安裝其他東西。要在 Windows 上面安裝 Ruby 就使用Ruby oneclick Installer 來安裝即可，聽他的名字就知道他只需要 one click 即可安裝。等到安裝完 Ruby ，Ruby oneclick Installer 會順便裝好 gem ，再利用

gem i rails -y

安裝 Ruby on Rails 就好啦。不過安裝 apache ，mysql.....東西，就可能要你自己好好的 survey 一下。ONLamp 有一篇 Rolling with Ruby on Rails 是一篇不錯的 Tutorial ，可以試試看，這裡也有一篇在winxp中手工安装Ruby on Rails 笔记可以試試看，這裡也有 Robbin 寫的
在Windows平台使用Apache2.2和Mongrel运行Ruby on Rails。

至於大家關心的 IDE 部份，我推薦 RadRails ，這是從 Eclipse 改的 Ruby on Rails IDE，可能是 TextMate 以外最好的 IDE，Instant Rails 已經有附，直接拿來用即可。

至於我用啥 IDE 呢？抱歉，我不用 IDE ，我用 VIM 。


補充 Mirror：我這裡 Mirror 了一份最新的 RadRails ，以及最新的 InstantRails。