新手學習 Ruby on Rails 必看的幾件事

寫這個Blog，我的 Email 信箱會遇到很多讀者的鼓勵，也會有很多新手的發問。但是我想說的是，我也是上班族，我很多時刻是在工作的，不回答你只是因為我在忙，不是我在生氣之類的。最重要的是，我覺得我要跟大家理清一下，學 Ruby on Rails 應該有的態度。

1. 學習 Rails 很簡單，但是你不肯花功夫下去去學就一點都不簡單。
   我遇到很多人連花點時間都不肯，就想直接問我找答案。用這種態度根本就學不到任何東西，不管是那一方面的學問都一樣。
2. 遇到問題時，先看看 Error log，嘗試去解決他，不行再去找答案。
   我在學 Linux 的時候，一個月上手，第二個月用 Debian 架出一個 Linux 桌面，第三個月開始管站。不是我行，是我遇到問題會嘗試去看 Error log，嘗試解決問題，就算解決不了問題，光是在解決的過程中，我就學到了更多東西。
   
3. Ruby on Rails 是用 Ruby 寫的 Framework，這代表你要花點時間去看 Ruby。
   有時候有些人問的問題，或是寫的 code 不對，就開始怪 Ruby on Rails。可是我後來發現大多數的問題，都是對於 Ruby 不熟悉所造成。我想問的是，你在學 Java時，會連語法都不去看就開始寫嗎？你在寫 C++ 時，會連要怎麼寫 C++ 都不知道，就去寫程式嗎？那為什麼遇到 Ruby on Rails ，你會連 Ruby 都沒花時間去看，就開始寫 Ruby on Rails 程式呢？
4. 不要好高騖遠，先用 Webricks 來當伺服器。
   有些人一定要一開始就架設好 Apache + Fcgi ，lighttpd+fastcgi，一定要一開始就將整個架設伺服器的架構都搞定，然後才開始學習 Ruby on Rails。但是這根本就本末倒置，一開始要學習的是熟悉 Ruby on Rails ，而非如何架設一個可以上線的系統。
   一個可以上線的系統需要的是 MIS 極為專業的技巧，但是 Ruby on Rails 專長是如何快速的開發程式，兩者不太一樣，都是需要時間去專精的東西，你在研發期應該作的是學習 Ruby on Rails，而非架設系統。我所認識一位矽谷公司老闆，他們就是先寫 Ruby on Rails 程式，然後程式直接放 Web Host 就好，等到流量夠大，有了足夠的資金，目前才在開始考慮請 MIS 來架站。其實到這個程度了，你也不用花時間學習架站，就多請幾個專業的MIS 來解決即可。
   
5. 想做就做吧，想寫就寫吧。等到問題出現再來解決吧。
   有些時候，我會問自己這樣作有沒有考慮到其他衍生的問題，然後一再反覆的討論，結果到最後時間不夠了，還沒開始寫程式。這是我以前寫 PHP 的習慣，因為程式進行重構本身是非常困難的問題，一重構可能要花個一天到一周不等的時間，所以與其花那麼多時間如此不如一開始考慮清楚。
   雖然這個立意是好的，但是目前現實就是『計畫永遠趕不上變化，變化永遠趕不上老闆的一句話』，有太多太多巨細靡遺的 spec 因為客觀環境情況改變了而胎死腹中。與其去考慮全盤的狀況，花了太多時間，結果最後連一點東西都生不出來。不如一開始有了想法就先作出一點東西，遇到問題在進行修改即可。
   當然有人會問，那麼重構的問題怎麼辦。PHP 或是 JAVA 我不知道，但是 Ruby on Rails可以把重構的時間極小化。我開發 Ruby on Rails 程式至今，曾經寫了一個 Project 裡面重大的重構了 10次以上，每次重構的時間是一個小時到三個小時不等。
   
   為什麼？
   
   因為 Ruby on Rails 本身 code 量就比其他語言來得少，大概是一般語言的 1/5 到 1/10。程式碼行數的多少會跟重構時間呈現絕對正相關。也就是說，Ruby on Rails 極為精簡的程式碼會大幅度的減少重構所需時間。加上 Ruby on Rails 開發速度快，所以重構的速度也超快。在加上 Convention over Configuration 的概念讓重構可以維繫一個統一的標準，DRY原則會讓重構的 cost 減少。這些東西都會讓人感覺到，DHH在設計 Ruby on Rails 時，他其實不是想設計一個開發快速的架構，他的目標是設計一個重構快速的架構。
   
   所以，寫 Ruby on Rails 程式不要想太多，寫了就是，有問題就改吧，沒啥大不了。
   

以下是讀者們常問我的新手問題，我希望大家如果在遇到問題時先看看這篇，相信可以避開 90% 的問題。

1. 我一開始就出現 Application Error，那是什麼問題？
   Ans ：這是一個所有人都會遇到的問題，簡單的回答就是某些目錄（tmp,log）使用權限設定錯誤，你可以請參照這篇的回答。
2. 要是出現下面的 Error，那是什麼問題？
   WARN TCPServer Error: Address already in use - bind(2)
   /opt/local/lib/ruby/1.8/webrick/utils.rb:73:in `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
   Ans：這是另外一個幾乎每個人都會問的問題，但是這個問題總是會讓我很不爽，因為這代表你不看 Error Message，還有基本觀念不足。Address already in use 就是你今天要啟動一個 port，但是之前已經有其他程式將這個 port 註冊走了，所以你的作法就是關掉之前聽這個port的程式 ，或是換個 port 即可。
3. 為什麼我的Rails無法連結 MySQL？
   Ans：通常 80% 的原因是你的 config 沒寫，或是沒寫正確。50% 的原因是你沒安裝 Ruby 的 MySQL Client，請用 gem i mysql 來安裝。
4. 為什麼我的 Rails 連結到 SQL Server 有問題？
   Ans：我聽說 Rails 或是 PHP 對 SQL Server 支援不好。不過因為我沒有花錢買 SQL Server，我手邊沒有 Windows的機器，我寫程式暫時也不會去使用 SQL Server，所以我無法測試他的相容度好還是不好。
5. 為什麼我的 Rails 出現 application error？
   Ans：如果第一個問題已經解決了，但是有時候寫的一半還是出現 Application Error。那代表你寫了一些 code 讓 Rails 不爽，請先看過 error log ，去 google 一下，去討論區問問，等到都沒解答，你可以嘗試來問我。
   

滿紙荒唐言，一把心酸淚

滿紙荒唐言，一把心酸淚，都言作者癡，誰解其中味 ....曹雪芹

有時候覺得自己好像寫了個不可思議的 Blog，目前 Google 排行穩居 Ruby on Rails 類繁體中文第一名，你怎麼查 Ruby on Rails 第一頁幾乎都會看到我的文章。

那又如何！

Grouping Controller 這篇我連查詢『是不是 Grouping Controller 已經被建議不使用』都沒查詢。Rails 1.2 + REST : 討論 Rails 的核心價值 這篇更是可笑，我連REST 的好處都不甚了解，就大張旗鼓的吹 REST 的好？還在 JavaEye 上面被人提醒說

谈的太虚了，或者说什么都没谈

哎呀，您說對了，我真的都沒有談，一點技術含量都沒有，那篇我覺得我寫得很差，我在 murmur。很多時刻，我覺得我在將 JavaEye 的文章簡轉繁，就算一篇。有時候我覺得我把 Ruby Planet 的文章英翻中，也是一篇。與其說我在寫 Ruby on Rails 的文章，還不如說我在轉錄眾人的文章還比較好。甚至更慘的是，有些時候我還會偷懶看別人翻譯好的文章，而不去看原文，天呀，我居然如此的偷懶跟怠惰。

其實我不是不想寫流芳百世的文章，只是我寫不出來

其實事情就是這樣，很多時候對於一些高手來說，我其實寫一些沒有太多意義的東西，我甚至越寫越覺得我該停了，我在自取其辱。夠了，讓真正的高手來引導我們吧。奇怪的是，以前的我完全不這們覺得，總覺得自己還蠻有點料的，我覺得我學問深度跟廣度都夠，天呀，我真是個無知的人。反而是我研究 Ruby on Rails 的越深，越覺得自己的渺小。或許我是漸漸踏入了學問的山，爬的越高，越覺得山的偉大。走的越遠，越覺得自己的渺小跟無知。

更奇怪的是，以前罵 Java 跟 PHP 罵的最重的我，漸漸不批評 Java 跟 PHP 了。有時候覺得技術沒有絕對的高下，你有優點就有缺點，通常你的優點就是你最大的缺點。像是 Java 兼容並蓄，彈性十足，自然就會為了這些優點付出了入門困難，繁瑣難耐的缺點。PHP簡單好用，上手容易，自然帶來了難以維護，結構不佳的缺點。但是這也只是通論，看過一些高手的 code 之後我發現，沒有技術高下之分，只有作者有高下之分。

我似乎漸漸開始領悟一些東西，雖然無法掌握全貌，但是我真的漸漸開始掌握了什麼。奇怪的是，這都是在我學習 Ruby on Rails ，用這個 Blog 去紀錄他之後發生的。或許我寫了許多東西，或許我啥真正的好東西都沒寫。但是似乎有些人藉由這個 Blog 得到了點東西，我也藉由這個 Blog 獲得了許多東西。

舉個最深刻的例子，Rails 1.2 + REST : 討論 Rails 的核心價值 這篇文章裡面寫到我無法掌握 REST 真正的好處，被 JavaEye 某位版友抬愛，轉錄過去後，馬上就有一位 cvu 大大開示我

REST的意义不在于做一个网站，而在于网站间的互相调用变得异常直接。网站间的调用，也可以理解成不同系统间的调用。

比如一个公司的CRM、workflow、财务系统、website...可以是一套大系统，那样太繁杂，也可以是分别几个独立的系统（decoupled systems），但是互相调用metadata就会非常不方便。一般有这么几种方式实现（从差到好排序）：
1、A系统直接调B系统的数据库
2、用程序访问B系统的网页，取出A系统需要的东西
3、各系统把经常要访问的功能写成web service
4、各系统做一套api
5、REST

上面的例子说的是公司系统，大众网站也是如此，如果大家都用REST，mashup也会更容易，好的应用会更多。

之前對於 REST 的好處不太了解，但是藉由他的文章我的確有收穫，也開始稍微掌握了點 REST 的神髓。

雖然我沒寫什麼真正了不起的東西，但是我的確從『撰寫Blog』這件事獲得許多收穫。以後這個 Blog 我會報持著『雖然我無法寫出什麼好文章，但是還是希望這個 Blog 能夠為讀者們帶來些什麼』這樣的心態繼續下去。感謝各位，感謝上蒼。

Something really close

最近一周 Blog 都沒時間寫，實在很汗顏。因為 Ruby on Rails 的專案即將上線，這周的每天都在 tune performance ，修改Bug，寫文件，還有找出頁面忘記加入那些連結。最近的感覺就跟馬拉松要最後衝刺的心情一樣

『快成功了，不過還差一點』

到目前為止，程式研發時間大概是 2.5 個月 * 2 人。但是扣掉Partner 是學生，一周大概只有 2 人天，我一周上班時間本來就大概 3~4 人天，9~11 月之間我還配合公司行銷專案，隨手開發了 2 ~ 3個小專案。（因為這些案子我都用用 Ruby on Rails ，我才能『隨手』開發 =.=）所以總開發時間大概是 2 ~ 2.5 人月比較正確。

身為 Ruby on Rails 推廣者，我總是會被問到『國內有那些公司用 Ruby on Rails？』。雖然我花很多時間寫文件 。不過到最後發現，比起寫一百篇文章，推廣的效果還不如自己寫一個網站所帶來的效益來得高，也比較有說服力。LAMP 獲得尊敬也是等到 Wikipedia，Flickr，Digg 等網站規模起來了，才獲得商業公司廣泛的肯定以及採用。這個案子如果真的可以起來，相信會給國內 Ruby on Rails 界一個大大的振奮。

這個案子結束後，我該思考兵役的問題了～～～

PS. 最近壓力測試發現 Mongrel 真的很穩。