1/30/2007

Ruby,Python,Perl,PHP 六種框架速度比較

先解釋一下最近在幹嘛,最近要考預官,所以沒時間寫 Blog,請多見諒。

剛剛看到這篇,裡面比較 Ruby,Python,Perl,PHP 幾種網頁框架的速度比較。參賽選手有
一看到這個陣仗,就知道這篇文章可能是(1)聞名古今,戰到天涯無怨尤的有名戰文(2)無關緊要的小測試。(1)的原因是因為原作者可能學富五車,精通各個框架的架設,並且擁有很高深的 benchmark 的經驗,耗盡心血做出一個舉世聞名的 benchmark。但是牽涉到太多 language 的顏面,所以贏家大肆宣揚,輸家拼了老命質疑,不管做得再好都會有人嫌,弱點都會被挑出來講,所以通常會成為戰文。(2)的話就是只做最不容易出問題的部分,比出來的部分根本就無關緊要。

這個 Benchmark 剛好在兩者之間,不過參考價值不大。

這篇文章一開頭就說
The Database in the test is not used, because it itself limits the speed important.
這個測試並沒有比較 Database,也就是根本沒有比到 Model 的效能,但是資料庫跟 Model 實做方式通常是效能的關鍵,那麼整體效能應該每個 Framework 都差不到哪裡去。也就是這個 Test 一開始就沒有太高的可參考性,但是依舊可以看到一些其他部分效能的差異(Routing,dispatch,view rendering之類的)。

排名是
  1. Dijango
  2. Rails 1.1.6 跟 TurboGear 並列第二
  3. Catalyst
  4. CodeIgniter
  5. Rails 1.2.1
  6. Symfony
Ruby on Rails 1.1.6 意外的拿下第二,沒輸給 Python 太多,還贏過普遍認知比 Ruby 快的 Perl 跟 PHP,真是令我驚訝。因為這種不比較 Model 實做的 benchmark,通常都是語言的速度佔最大因素,或許真的是 Project 實做出來的效能有差別吧。總之這個 benchmark Rails 拿下出乎意料的好分數。

不過值得注意的,Rails 1.2 比 Rails 1.1 來的慢,這倒是要好好去 check 一下。或許就跟文中講到,all this attests to possible error in the new version,剛剛出的版本,一些實做還不像 1.1 那麼的完善吧。

1/26/2007

[ 翻譯 ] Zed on Ruby, Rails, Mongrel, and More

去年三月 O'Reilly 訪問了 Mongrel 作者 Zed Shaw,想翻譯這篇的原因是因為 Javaeye 上面 alang 發表了簡體翻譯,本來想說直接翻成繁體就好了,不過發現到有些部份原翻譯者並沒有翻譯,順便多翻譯了一下,也幫忙潤飾一下文字成為台灣使用者比較習慣的文法。雖然有不少部份修改,但是本翻譯 50% 以上內容還是改自 alang 的簡體翻譯,並且訪談內容版權屬於 O'Reilly 所有,在此感謝,如有爭議請來信告知。裡面如果有那幾句忘了翻譯,也請指正。


感想:

在 去年三月時,Mongrel 作者 Zed Shaw 提出他想利用 Mongrel 補齊 Rails 在 Enterprise 那一塊的缺口,到現在 Mongrel 發表 1.0 版的同時,Reverse Proxy + Mongrel Cluster 已經是使用 Ruby on Rails 公司的基本配備,看起來 Zed 似乎已經完成當初的夢想了,恭喜 Zed ,Ruby on Rails 也因為有了他,成長才能夠如此迅速。

摘要:

Zed Shaw 在一開始指出有了 Mongrel 的 Ruby on Rails ,已經是一個 Enterprise Ready 的 Framework,並且他已經被許多使用者拿去 Run Real Business。他並且提出一些小故事,間接驗證 Mongrel 的安全性是很良好的。(Apache 擋不住的攻擊,但是被 Mongrel 擊退了)

他在文中也提出許多 Ruby and Rails 社群應該反省的事情
  1. Ruby 執行效能不應該被輕視,雖然我也是輕視的那一群
  2. Win 32 社群不該被輕視
  3. Ruby on Rails 已經有點擁種,該是輕量化的時候了
  4. Active Record 應該增加一些 Connection Pool 設計
並且他也開始著手構思繼續建制一個良好的 Cache Proxy。

本文開始

Zed Shaw 是一個在Ruby世界中漸漸聲名大噪的程式設計師,它是Mongrel的作者,因快速、穩定、安全而出名。在這個訪問中,他討論了Mongrel,Ruby,和他的創建良好程式碼的經驗。

問:你是怎麼進入Ruby世界中的?

答:多年前,我在開發一個怪異的控制工具--我叫它FastCST時--接觸到Ruby時。我試了一下Ruby,但是不得要領,馬上就回到了C語言了。當我讀了Curt Hibbs的文章時,才瞭解到,「Hey,他們在用這個東西在做DSL (domain specific languages )。」從那時起,我就開始開發一個Ruby版本的FastCST,但是很快就被其他的Ruby on Rails 的有趣 Project 所分心。

問: 當某人說他使用 Ruby 時,通常大家就直接連結到他在使用 Ruby on Rails. 你在 Ruby 上面的時間,以及 Ruby on Rails 的時間比是多少?

答:我必須說我在 Ruby 上面主要的工作,也就是 Mongrel ,就是為了支援 Ruby on Rails,以及其他使用 Mongrel 的 Project。但是我每天的工作就是使用 Ruby on Rails。

我喜歡 Ruby 的原因是因為你可以簡潔的表示你想要表示的東西,但是在可讀性上卻相當的清楚。當然有些不好的地方,但是 Ruby 以不可思議的速度加快了我開發的速度。這個語言不可思議的結合了 DSL 跟 OO 語言,並且讓我的開發程式,以開發程式雛型的速度,但是卻有產品的品質。


問:許多人都在說,Ruby和Rails對於「企業級應用」還沒準備好,你怎麼看這個問題?

答:在回答這個問題之前,我必須要明確人們所謂“企業級應用”的定義,可以概括為三點:
1、龐大、昂貴
2、可擴展性,性能,滿足我的服務需求
3、有保障的商業技術支持,用來保護潛在的損失。

問:OK,讓我們一點一點的來談,Ruby和Rails都是免費的,它們怎麼得到花費昂貴的人們的認可?

答:「企業級應用」意味著你要花費上百萬的金錢在硬體和軟體上,但是這個觀點是錯誤的。這麼多年來,他們一直在灌輸這個觀點,是因為他們要從中獲取你購買他們產品的利益。實際上你的解決方案要符合你的真實需求。如果你需要一個龐大的解決方案,是因為你並沒有真正瞭解你到底需要甚麼。Rails 顯示了這樣的「企業級應用」是個錯誤的想法,這些事情其實並不需要,而且 ROI (投資報酬率)也會很差。

Rails 正在做的事情就是證明你不用花一堆錢在「企業級應用」,依舊可以做大事情。Rails 可以做真正的 business。他已經讓一些企業家只花少許的基本投資,就可以實現他們腦中的想法,並且賺大錢。我知道紐約的一些小公司已經用很少的開發者,就可以建構起他們自己的站台。像這樣「減少開始創業的風險」足以證明 Rails 可以應付真正的 business。

問:那麼,Rails的可以擴展性呢?

答:那些企業級應用中的「擴展性」,我都可以用Mongrel來解決。首先,要把「可擴展性」與「高性能」要區別開來,同時要回到「資源的可以擴充性」上來。一旦你把「可擴展性」與「高性能」這二者區分開來,你就能兩者皆顧。

Rails的擴展性(指的是滿足需求的可擴展性),和其它的Web應用框架一樣好。Mongerl讓這個工作變得非常簡單,它非常快,基於HTTP。如果你以前用過Tomcat,Resin,WebLogic或者Apache+PHP,那麼Mongrel運行Rails會達到同樣的效果。

其實我是承認Ruby的效率不高的。Ruby的社區曾經有意的忽略了「高性能」重要的議題,他們必須正視這一點。現在已經有了一些成果,可以讓Ruby 變得快一些。但是還有許多問題要解決。有一個叫Rite的VM已經展示了一些成果(或是你可以講 YARV),對Ruby的加速已經可以和Java的解決方案相提並論了。

Ruby的強項不在於它的運行速度,而是在於它的開發速度。我可以證明這一點,我在Mongrel上花了三個月的時間,它已經是一個全功能、穩定、高效的web server,可以用它來支撐許多Ruby網站。如果不用Ruby,這是不可能的。

Rails的問題又不同於Ruby,因為Rails自己有著優秀的 cache 機制,這在一定程度上彌補了Ruby的龜速。Rails用「page caching」、「fragment caching」來加速應用。如果你善加良好的規畫你的 cache 方案,你可以得到和靜態頁面一樣的性能。甚至比Java或者PHP的做得還要好。

問:那麼,商業化的技術服務呢?

答:Rails現在還做得不夠好。我也了解很多組織在投資技術之前,他們會需要商業性的支援。但是,情況會越來越好。會有越來越的資金投入到這個Rails服務領域來的,他們會像PHP類似的眾多服務一樣做得很好的。如果你看看PHP,最開始只有Zend一家在做這個服務,後來有越來越多的大公司加入到服務的行列中來。

問:在開始做Mongrel之前,你在開發SCGI,說一說它們之間的相似之處,談談他們如何 play together(or not)

答:SCGI 是我的第一次取代FastCGI的嘗試。SCGI的目的是高效率的支撐純Ruby應用,目的已經達到了。但是,SCGI在很多web server中的支持是相當有限的,並且也不是那些web server 未來開發的選擇。Lighttpd的支源發來於對它的mod_fastcgi的修改,Apache的SCGI Module來自於Apache Project之外,並且Apache聲明過他們將對FastCGI的支援要多過對SCGI的支援。事實證明,許多人在Apache上使用SCGI與多個後台通信時都遇到了麻煩。SCGI看起來似乎不妙。

Mongrel最開始是作為一個SCGI的proxy,試圖解決上面的問題。我寫了一個Http的解析器,然後用C寫了一個代理程序來回應請求,再轉發給SCGI。做到一半的時候,我意識到這個解析器寫的是如此的完美,讓我決定跳過中間轉發的部份,直接寫用Ruby寫一個web server。大約一天之後, Mongrel誕生了。

我的對SCGI的計劃是,簡化它,只滿足最基本的要求。SCGI裡面目前有許多的DRb(分布式Ruby)管理代碼,還有一些其它人使用(濫用)的片斷, 但是,這對那些只是希望使用SCGI來工作的人來說沒有一點用處。為了支持那些目前使用SCGI的用戶,我將移植一些Mongrel的發明過去,比如 thread模型。要簡化SCGI,讓它回到最初的面目上去。

說了這麼多,我想你已經明白了我未來的工作主要是Mongrel,我認為它是支持Ruby web應用的比較power的方法。HTTP 跟 SCGI 相比,在支援跟開發 Rails 來說,都是一個比較好的 Protocol。

如果有任何人對接手SCGI的工作感興趣,我歡迎。或許那家公司可以在上面開發一個更好的產品。它在RubyForge上有個專案,有興趣和有能力的人來吧,我已經準備好了交出它的管理權。

問:你在Mongrel上的工作是如何影響你在Rails上的工作的?或者相反?

答:在Mongrel中,我必須用到的Rails代碼非常的少,這是為了讓Mongrel與Rails保持比較分離的結合,這樣當Rails在某個release版中改了甚麼東西並且讓程序崩潰時,Mongrel不受影響。

當我在用Rails上開發時,我積極的使用Mongrel,並且記下哪些方面要作改進。這讓我可以保證Mongrel的實用價值,而不是為了純粹的學術目的作的憑空想像。

舉個例子,我在windows平台上做開發,那簡直是不可思義的痛苦,主要的原因不在於windows本身,而是開發Rails的人從來沒有深入的使用過windows。Luis Lavena做的許多改進讓事情變得好了些。對於我這樣的、還有其它許多貧窮的使用windows的粗人來說,我要讓Ruby on Rails更容易使用些。

問:我知道你在為Rails和Nitro camps上能運行Mongrel而努力。目前最大的障礙是甚麼?

答:最好的事情是讓Mongrel變成「跟框架保持分離」的。我是唯一的一個能Rails與Mongrel合作的人。Rails核心開發團隊的一些傢伙主要是在開發時測試Mongrel,但是我自己,Luis Lavena,其他的幾個人,幾乎做了讓Mongrel產品化的全部工作。我和Luis是唯一被期待用Rails來做產品的人。

Nitro,camping,還有IOWA團隊的人,為我做了許多讓mongrel適應他們平台上的工作。他們下載Mongrel,閱讀文檔,初期會打擾我,但是大部分時候不要我插手。 我覺得我幫助Campng項目最多,但實際上管理Mongrel的代碼要歸功於Camping。它回饋給我的是放在了0.3.12.5發行版中一個大檔案的上傳/下載 Patch,。因為他說他是在給ParkPlace做DVD的上傳/下載時碰到了。


問:Mongrel給那些使用它的項目們回報甚麼了呢?

答:我認為有兩件最大的回報,一是安全性增強,二是win32平台的支持。

Mongrel的設計考慮了大多數HTTP服務器碰到過的安全問題,這些問題來自於過於鬆散的HTTP協議手工代碼處理。Mongrel使用了一個生成處理器(使用了Ragel),它非常穩固、優秀,可以阻擋大量的網路攻擊。因為這個保護是來自於HTTP協議層的,所以使用Mongrel的任何框架都可以自由的使用它。

在EastMedia/VeriSign計畫中,我們遇到了一波來自某「安全公司」的網絡攻擊。在這裡我不想指出這家公司的名字,以免給他們做了免費的廣告。他們在沒有事先通知我們的情況下,對還沒有發布的機器,使用了一些掃描軟件。

好在Mongrel在HTTP層就阻擋了所有的攻擊,沒有費一點事就把他們踢了出去。但是就在同時,Apache卻讓這次攻擊通過了 Proxy,一點報警都沒有。

當他們進行了自動掃描之後,我們知道了有一些在「安全公司」的「手寫代碼」攻擊的人,被Mongrel所做的深深吸引住了。

最有趣的部分是,Mongrel所做的全部,是使用了一個基於文法和解析生成器(Ragel)的正確的解析器。其它web server使用人工編寫的HTTP解析器,被證明是易受攻擊的、難於與真正的HTTP1.1 RFC規範相比較,維護起來也是非常痛苦的。使用了Ragel之後讓Mongrel非常的穩固,不需要創建特殊的攻擊探測邏輯,也能阻擋這些攻擊。

其它項目從Mongrel身上得到的第二個好處,是Luis Lavena所提供的Win32支持。從Mongrel在Win32平台上成功之後,我看到了一些說Luis讓其它項目獲得了Win32平台兼容性的好消 息。有謠言甚至說Luis和它的朋友們為Win32用戶打開了Ruby世界的整個大門。我希望對Daniel Berger的win32utils項目也有同樣的幫助。

問:在Mongrel背後的一個巨大力量是它速度快、幾乎是純Ruby代碼。你作了哪些優化工作?你使用了甚麼工具?

答:我在優化C程式碼時,使用的主要工具是valgrind和kcachegrind。這兩個都是非常奇妙的免費工具。但是 Ruby在valgrind下運行得並不好。事實上,valgrind光是hello world就吐出了3萬個error。後來我轉而使用kcachegrind。

效能檢測工具我使用httperf。當我在做了一個期待著能有性能提昇的改動後,但並沒有改觀時,我就用它重新檢測一下,再做一些其它可能有用的努力。

整個過程都用了比較科學的方法。因為我從Ruby得到的有關性能的消息非常少,我只有不斷的測試、評估、調整,不斷的重復這個過程,直到確認性能指數真的提高了。使用統計學測試真正有用的地方在於,確認每一次的變動的確有了一些不同,或者至少確保沒有帶來壞處。

我當然也使用Ruby的Profilling Library,但我只是在僅有Mongrel運行的地方作非常有限的測試。當Mongrel和其它的應用框架一起運行時,這些框架有可能拖慢了Mongrel的速度,用Ruby的Profilling Library就得不到任何有用的資訊。

舉一個例子,在一個簡單的測試中,我用YAML來回應HTTP請求,我不能使用Ruby的Profilling Library,因為所有的性能訊息都是有關YAML的。Mongrel的訊息只有一丁點兒。Rails或者Camping的性能測試也同樣的情況,Profilling 吐出來有關於框架自身的性能數據多過有關於Mongrel的。

當我對性能非常敏感的時候,我使用R工具來作有計劃的性能數據分析。


問:最近,你做了許多工作比如單元測試,好讓Mongrel穩定、安全。你能解釋一下你的方法論,和你使用的工具?

答:我非常贊同OpenBSD團隊所宣稱的,安全漏洞來自於一般的缺陷,而不是來自於你在源代碼裡面找到的那些特定的「安全漏洞」。這意味著我認為我修正了我所能找到的所有安全漏洞,並且積極的對待那些潛在錯誤之後,我會在這個過程中阻止許多漏洞。

在我的所有項目中,我拼命的做到以下幾點:

1、保證程式碼盡可能的簡單。
2、在發布我的代碼之前,做Code review,持續的發現
a、“丟失的斷言”-對於輸入輸出的不正確的假設
b、“丟失的else”-沒有覆蓋到所有的邏輯分支
c、“期待它會中止”-死循環或者短命循環錯誤
d、“檢查返回值”
e、“預料之外的異常”
f、“簡單、可讀”-用可讀性強的代碼替換奇技淫巧的代碼;對複雜的代碼寫好文檔以便其它人可以理解
3、盡可能的做單元測試
4、外部的破壞性測試和性能測試。用不正確的輸入讓你的系統崩潰,高負荷,停止中間流的干擾,隨機的拆開資源。總之想盡一切辦法搞爛你的系統。
5、用戶可用性評價。我認為如果一個系統是易於使用的,安全性問題就會少一些。但是我現在沒有實例來證明我的聲明。

最終的結果,Mongrel可以在HTTP協議層阻擋海量的攻擊。這也許不能說明Mongrel是固若金湯的,但是Mongrel正在朝這條路上走。

問:Mongrel要達到的下一個目標是甚麼?

答:最近的一個工作是改進Mongrel的安裝部屬文件。日前為止還只有一個配置Lighttpd,但次我們真正需要的是在各種平台上部屬Mongrel叢集的文件。一旦這些文件完成了,佈置Mongrel會更容易。特別是那些已經使用了其它應用服務器比如Tomcat的人們。

問:你是如何對待那些Mongrel的反饋和建議的?

答:這些反饋都是非常積極的。最關心的問題,也是最值得考慮的問題。

許多人都問到了布署問題,我將用良好的文檔來解決。其它人問到了叢級的管理,我希望Bradley Taylor(來自RailsMachine.com)將要提交的叢集插件能解決這個問題。其它一些人問到了licenses,我會在FAQs中說明。

有一些頑固的問題,是關於如何處理caching和多個複雜動態web網站時的負載均衡。對於這兩個問題我目前無能為力,我會想些好點子,我希望我的下一個項目能解決「緩存問題」。

問:Mongrel有甚麼障礙嗎?

答:我得說,Mongrel的最大障礙,是讓它被人們接受成為一個 production 的平台。開發Mongrel 已經變成非常美好的事情了。我每天都從社區中收到許多來信,說一他們認為Mongrel是多麼的多麼的棒。但就是沒有一點關於使用Mongerl作巨型productiong布署的消息。我覺得在未來的幾個月裡,情況會好起來的。

問:你最喜歡的5個 library 或者框架是甚麼(標準庫中的或者社區的都行)?

答:我要說說Camping框架。它有著太多的魔力,讓我不得提到它。Mongrel從它身上得到許多代碼和思想。

我使用webgen來管理Mongrel的網站。它可以非常容易的從一組簡單的wiki格式的頁面中生成靜態網站。

我也很喜歡 Simple 這個用 Java 寫成的又小又快速的 Web Server。當我開始開發 Mongrel 時,我從 Simple 得到很多,並且採用 Simple 的 Handler 實做方式。Simple 有很多有趣的特色,像是他會去解析並且校正 response,但是儘管如此,他還是相當的輕巧跟快速。如果我要拿 Rails 來跟 Java 比較,Simple 應該是處於兩者中間的。

網路性能測試工具,我只選httperf。它是唯一的一個能夠精確的統計分析,打斷整個的request/response鏈,精確的報告socket錯誤,每一個分析項都有精確的定義,容易使用的分析工具。

我也非常的喜歡Lua語言,我把它當成Ruby的一個輕量級的替代者。它非常快,簡潔,非常容易的就能embed到其它程式中去。有著和Ruby相似的、並不陌生的語法。

問:Ruby,Rails,Mongrel和Zed,它們各自的下一步計劃是甚麼?

答:關於Ruby的這得去問Matz,Rails的要去問David。我能說的是,我希望Ruby和Rails將會是甚麼樣子。

關於Ruby,我希望看到兩個結果。第一個是它能簡單的運行在valgrind下。讓它穩定、保持簡潔還要走很長的路。第二點是集中那些致力提高Ruby效率的人們的分散力量,到Ruby1.9的VM項目上來。

對於Rails,我希望它能少些臃腫,並且我希望ActiveRecord能有一個比較像樣的的connection pool系統。對於「臃腫」這件事情,我相信DHH已經計劃著把一些東西(類似Active Web Service)移出 core 到 plugins中去。對於ActiveRecord,需要作一些重構,讓資料庫 connection pool看上去和Hibernate的一樣。這對那些按資料庫連接數付license費使用的商業資料庫使用者來說尤為重要。

Mongrel的未來看起非常光明。我將在發布第一個production版本時。像Java將每個做的很好的產品都加入一個「Enterprise Editions」的名字一樣,我會取個「Mongrel 0.4 Enterprise Edition 1.2」的名字。我也會幫助更多公司佈署 Mongrel Server,或是將 Mongrel 加入他們的新產品中。

我的下一個目標,可能是一個caching proxy服務器,目的是讓所有的動態web 程式性能更好、更快。當我在開發 Mongrel 時,我發現到 HTTP 1.1 整體的 cacheing 非常的老舊。我想我已經有一些改進的想法,並且希望能夠給很多 web application 更快的效率進步。

----

Zed A. Shaw 是一個專業的軟體開發者。他已經開發 13年程式了,並且參與的產業範圍從政府,學校,商業產品。產品的範圍包括安全,網路,網頁程式設計。他也涉獵了系統管理,產品開發,可用性研發,顧客服務。他的閒暇時間也喜歡寫自己的自傳,大家認為他實在是一個很 cool 的人。


延伸閱讀

1/23/2007

Mongrel 1.0 Release

在大家引頸期盼下,Mongrel 終於 Release 1.0 版了,恭喜 Mongrel 正式邁向象徵 Stable 的1.0 ,往邁向商業 Production 使用的環境前進。到目前為止,Mongrel 依舊是 Ruby on Rails 裡面最穩定的 Application Server 選擇,並且在設定方面也相當的簡便。


安裝方式
gem i mongrel -y

至於眼尖的使用者可能發現 Mongrel 是 1.0.1 的版本的,難道他跟 Rails 1.2 一樣,Release之後馬上出問題嗎?

No!!!根據 Zed Shaw 的冷笑話

What happened to 1.0?

We decided to follow official Rails Configuration Management Board Standards and do a silent 1.0 followed by an official 1.0.1. There weren’t any bugs in 1.0 but we didn’t want to break with tradition by not offering a 1.0.1. (Yes, this is a joke.)

So,看的懂的人就看的懂,看不懂的人就恭喜 Mongrel Team 好了XD

利用 File_column 來做到縮圖

圖片上傳,縮圖製作這幾個功能可以說是 Web App 做到爛掉的東西,我們之前遇到縮圖,都是使用我們公司 Team 自己開發的 RMagick Image Upload API。當我最近著手 某個 Project 的時候,我想說「既然大家都推薦 File Column ,我這次不用自己寫的 API ,也來用用看 File Column 好了」。一不用則以,一用 File Column ,我還是感到相當的 shock.....................

「怎麼可能,製作縮圖怎麼可能可以做到那麼簡單。」

File Column 就是一個結合 Rmagick ,並且將圖片依照自己的機制存在 public 資料夾下面的 Plugin,License 是 MIT 。下列範例直接抄 File_column 的範例,小技巧來自airport 的 整合File-Column和Rmagick功能实现图片上传

安裝

因為 file column 是基於 Rmagick,所以必須先安裝 Rmagick。安裝好 Rmagick 之後可以到file column 官方網站下載 tarball ,或是直接使用 plugin 安裝
./script/plugin install
http://opensvn.csie.org/rails_file_column/
plugins/file_column/trunk
基本上傳

1. 設定

首先,你必須在某個 Model 加入一個 column,這裡叫 Entry Model ,Column 叫做 image 好了。
   class Entry < ActiveRecord::Base
file_column :image
end
好,這樣已經把設定弄好了。

2. 上傳圖片的 Form Helper

以前 image upload 都是用
    <%= file_field "entry", "image" %>
現在請在 view 裡面使用 file_column_field
    <%= file_column_field "entry", "image" %>
3. 顯示圖片

要顯示圖片,還是使用 image_tag 來顯示,不過 image url 必須採用 url_for_file_column
    <%= image_tag( url_for_file_column("entry", "image") ) %>

4. 完成

如何,file column 真的很簡單吧。設定,顯示,上傳都各一行即可。


縮圖

但是上面的功能只能說基本,要夠好用,必須可以做到縮圖。要作縮圖的時候,上傳 file_column_field 完全沒有任何改變,所以這裡就不解釋。

1. 設定

設定方面,你加入你想要加入的縮圖 size ,我這邊設三種縮圖的版本,最小的縮圖是 thumb 25x25 ,medium 是 150x150,large是 300x300 。
   class Entry < ActiveRecord::Base
file_column :image , :magick => {
:versions => { "thumb" => "25x25", "medium" => "150x150" , "large" => "300x300" }
}
end

2. 顯示圖片

要顯示縮圖的圖片,只需要加入剛剛作縮圖的版本,剛剛設定的是 thumb, medium, large

Thumb:
    <%= image_tag( url_for_file_column("entry", "image", "thumb" ) ) %>
Medium:
    <%= image_tag( url_for_file_column("entry", "image", "medium" ) ) %>
Large:
    <%= image_tag( url_for_file_column("entry", "image", "large" ) ) %>
原圖:
    <%= image_tag( url_for_file_column("entry", "image") ) %>

小技巧

這邊還有出自airport 的 整合File-Column和Rmagick功能实现图片上传 的一些小技巧
"thumb" => "25x25!" : ! 代表就是要縮成 25x25 ,也就是會根據這個比例作破壞性的壓縮
"thumb" => "25x25>" : > 代表假設這個圖本身就小於 25x25,就不作縮圖了。

如果要限制上傳的圖形格式,就使用 validate_format_of 即可
  class Entry < ActiveRecord::Base
validates_format_of :image, :with=>/^.*(.jpg|.JPG|.gif|.GIF)$/
file_column :image , :magick => {
:versions => { "thumb" => "25x25", "medium" => "150x150" , "large" => "300x300" }
}
end
file column 上傳的圖片到哪裡去了

如果 Model 已經 save 好了,你可以仔細看看 public 資料夾,裡面找你使用 file column 的 Model 名字的資料夾,你會發現他放到那個資料夾的 image 資料夾下面去了,裡面每個資料夾都是某個 model emtry 的 id。在這裡的例子裡,Entry model 的 image 是他會放到 public/entry/image/ 底下。

如果是image 已經上傳到 Server,Model 還沒有 save 的情況,他會放在 public/entry/image/tmp/ 底下。


延伸閱讀

1/19/2007

Rails 1.2 Release

看到這一張圖 , 應該大家都知道發生了什麼事情了吧 .
Rails 1.2 正式發布


並且也在同時發布 Prototype 1.5 , 並且 Prototype 1.5 boundel 進入 Rails 1.2 . ( 因為 Prototype 作者 Sam Stephenson 其實就是 Rails Core Team 成員) . 雖然馬上就有災情產生 , 但是 Rails Tema 馬上又發表了 1.2.1 XD

更新方式請按
gem i rails -y
即可 . DHH 也寫了一個 Rails 1.2 的新 Feature , 介紹多了什麼東西 . 對岸那邊似乎對於連線到美國速度非常的緩慢 , 所以我包了一份 ZIP 在 JavaEye 上面 , 裡面有所有 Rails 1.2 相關的 gem , 對岸朋友可以自行下載 . 台灣這裡似乎不用 Mirror 一份吧 ? 我下載速度都不錯 .

為了紀念這一刻 , 特別把 gem update 的 log 紀錄下來
> gem i rails -y
Attempting local installation of 'rails'
Local gem file not found: rails*.gem
Attempting remote installation of 'rails'
Updating Gem source index for: http://gems.rubyforge.org
Updating Gem source index for: http://gems.rubyforge.org
Updating Gem source index for: http://gems.rubyforge.org
Updating Gem source index for: http://gems.rubyforge.org
Successfully installed rails-1.2.1
Successfully installed activesupport-1.4.0
Successfully installed activerecord-1.15.1
Successfully installed actionpack-1.13.1
Successfully installed actionmailer-1.3.1
Successfully installed actionwebservice-1.2.1
Installing RDoc documentation for activesupport-1.4.0...
Installing RDoc documentation for activerecord-1.15.1...
Installing RDoc documentation for actionpack-1.13.1...
Installing RDoc documentation for actionmailer-1.3.1...
Installing RDoc documentation for actionwebservice-1.2.1...

恭喜 Rails Team

1/18/2007

Ruby Song



Kaiser Chiefs 是一個英國樂團。2007年他們推出了一個新曲,就叫做 Ruby。

以下是他們這首曲子的歌詞片段,還沒聽過不知道好不好聽,不過歌詞看起來挺蠢的 XD

Ruby, Ruby, Ruby, Ruby
Ahaa-ahaa-aaaa
Do ya, do ya, do ya, do ya
Ahaa-ahaa-aaaa
Now what ya doing, doing to me?
Ahaa-ahaa-aaaa
Ruby, Ruby, Ruby, Ruby
Ahaa-ahaa-aaaa
Do ya, do ya, do ya, do ya
Ahaa-ahaa-aaaa (Da da da, da da da)
What ya doing, doing to me?
Ahaa-ahaa-aaaa, aaaa (Da da da)
本篇文章所有圖片跟歌詞版權都屬於 Kaiser Chiefs 所有,如有疑慮請來信告知。

延伸閱讀

1/17/2007

Happy 200 篇!!!

自從 10/30 慶祝 100 篇以來,今天我又要慶祝本 Blog 正式達成 200 篇。上次我花了兩個半月寫了第一百篇文章,這次我也花了兩個半月寫了第兩百篇文章,速度十分穩定,產量也很可怕,平均一天寫了1.33篇文章,以一個上班族來說,非常的驚人。在這個值得紀念的時刻,有幾件事情要宣佈
  1. 方向調整
  2. 個人動向
  3. 新人加入


Blog 方向要調整

自從本 Blog 第一篇開始,我就講了一下本 Blog 的目的
Lighty RoR 是我為 Lighttpd + Ruby on Rails + SQLite 取的名字
意思就是輕薄有力的Web Programming 套件

lighttpd 是目前最好的輕量化 web server
Ruby on Rails 是目前研發速度最快,code也可是最少的 Framework
SQLite 是目前最輕巧,但是功能跟速度都屬上乘的 Database

這個Blog的目標就是介紹這組我最喜歡的組合給大家
時至今日,過了五個月,大家很明顯的發覺到幾件事
  • SQLite 文章沒幾篇,因為我還是比較常使用 MySQL,並且 MySQL 真的比 SQLite 穩定。
  • Ruby on Rails 文章佔了絕大多數,我也相信這是大部分人來本站的原因
  • Lighttpd 文章很多,但是我也開始花時間碰其他的 Web Server
所以以後走向會調整為
  1. Ruby on Rails 繼續深耕
    Ruby on Rails 絕對絕對是本 Blog 主力,我還是會花絕大多數的時間去撰寫。

  2. SQLite 不再強調
    我悄悄地把 SQLite 從 Slogan 移開,原因是因為「我認為我沒時間寫 SQLite 的文章,不能這樣名不副實」,也就是以後我除非工作需要有接觸 SQLite ,否則不會撰寫 SQLite 的文章了。

  3. 加入許多其他 Web Server
    Lighttpd 的確是一個很好的 Web Server ,但是他不是絕對的。Mongrel,Apache,Nginx....有太多的好 Web Server。如果有需要,我會寫其他 Web Server 文章。

  4. 加入 Javascript 的介紹
    是的,我很小心眼,我就是對不尊重 Scripting Language 的人不爽。既然我都說了如果這個世界所有語言都要毀滅,只有一個語言留下來,那一定是 Javascript」這種話,那我就要讓證明給別人看看到底 Javascript 是不是真的只是小菜一碟。

    原則上我會以介紹跟 Ruby on Rails 有關係的 Javascript 為主。一開始以 RJS 為主,順便介紹 Prototype 跟 script.aculo.us 這兩個 Lib,但是如果我想,也會介紹其他的 AJAX 以及 Javascript。

個人動向

本人會因為生涯規劃的原因,在農曆年後離開樂多( 絕對不是有了什麼理念上的不合,純粹只是想去看看更廣的世界)。沒有意外的話應該會在今年七月去當預官,直接去當兵,不去國防役了,在此非常感謝某家公司提供給我非常好的國防役工作環境,不去你們那邊真的只是生涯規劃問題,您的誠意我銘感五內。二到七月之間,我應該會到處走走,充電一下,也會在幾個 Conference 主講 Ruby on Rails 的東西。

沒錯,我已經知道你在問什麼了。我 7月去當兵了,這個 Blog 怎麼辦?這其實讓我傷腦筋很久。我之所以想去國防役,80%是因為放不下這個 Blog。

但是,其實佛家裡面「放下」才是最高深的智慧。

我又覺得當兵不失為一個很好的充電環境,至少可以鍛鍊一下我貧弱的體力,以及讓眼睛好好休息一下,不要常看電腦。如果在軍中有時間看書的話,我還想充實自己外語能力,並且終於有點時間看看我從來就沒時間看的 Design Pattern Agile Programming。但是只要一天我還有寫這個 Blog ,我想我就沒這樣的時間繼續充實自己。

This is not so bad.

新人加入

基於這個因素,我私底下問了幾個我覺得程度不錯的朋友,問他要不要也來這個 Blog 投稿。畢竟這個 Blog 創立起來實在不容易,要一手放掉實在略嫌可惜了點。目前已經確定一個常駐的客座人選,他也首肯了。

將將將,讓我們歡迎小布,他是我寫 Ruby on Rails Project 的 Partner。他的專長在於 Database Design,Semantic Web,Ruby on Rails ,還會 Python。他的文章走向大致上是 Ruby on Rails 的應用性。

至於其他常駐人選,我會在篩選一些能力跟文筆都不錯的人之後,一一宣佈。如果有想投稿的人,非常歡迎單篇投稿或是系列投稿,聯絡方式就是 Email 到我的信箱。

最後,我想說的是,我成立這個 Blog ,寫了那麼多篇文章,不是因為對於 Ruby on Rails 的狂熱,只是因為

這個世界太過於複雜,我們需要簡潔有力的東西。

謝謝大家這五個月來的支持,我會繼續努力的。

1/16/2007

[ 工商服務時間 ] ZK 徵人

雖然之前那麼多風風雨雨,不過我對任何程式語言還是沒有任何偏見的,我認為所有的 Web Framework 都是「兄弟登山,各自努力」的狀況。大家一起加油,一起努力吧。

言歸正題,我的朋友 Anw 他所屬的公司要找 JAVA 程式設計師,他們公司正是研發 ZK 這套 SourceFroge上面排行第一的 Java Open Source Web Framework ,機會難得,對於 Open Source 有興趣的人可以寄履歷到 Mr. HenriAnw


ZK 需要對寫程式有熱情, 熟 Java 及會英文的程式設計人才.
歡迎有興趣的朋友加入, 一起努力!

工作地點: 台北
ZK : #1 Ajax project in SourceForge.net

請將履歷寄到 Mr. Henrime

PS. 我在 COSUP 2006 ,也有幸跟他們老闆 Henri 在同一個 Section 一起 present Web Framework,沒機會聊天,不過感覺是蠻 nice 的人。

Faster CSV:做報表的好幫手

FasterCSV 是 Ruby 當中一個處理 CSV 檔案的 lib。顧名思義,他做 CSV 處理速度比 Ruby standard Lib 快。這裡介紹怎麼連結 Active Record 產生報表,並且每天寄一份 Email 報表給管理者。本篇參考自How to email reports from Rails



安裝
gem i fastercsv
即安裝完成,要在程式使用請先 require
require 'rubygems'
require 'faster_csv'
跟 Active Record 連結,並且產生報表

我們假設我們想要把 User 資料庫裡面的東西作成 CSV 檔案
FasterCSV.open("report.csv", "w") do |csv|
fields = User.content_columns.inject([]) do |result,column|
result << column.name
end
csv << fields.map {|f| f.titleize }
User.find_all.each do |row|
csv << fields.map {|f| row[f] }
end
end
其中 csv << 代表塞入一次塞一行,如果還沒做好之前,先用一個 Array 來暫存。最後在用
csv << temp_array 來塞入比較好。

如果寄 Email 報表

我就直接用How to email reports from Rails 的範例。
class Notifier < ActionMailer::Base
def sales_for_yesterday
require 'FasterCSV'

@from = 'someone@example.com'
@recipients = 'someone@example.com'
@sent_on = Time.now
@yesterday = 1.day.ago
@body = { :yesterday => @yesterday }
@subject = "Sales Report"

attachment :content_type => "text/csv", :filename => "sales_#{@yesterday.to_date}.csv" do |a|
a.body = FasterCSV.generate do |csv|
csv < < (fields = ["artist", "product", "variant", "unit price", "qty sold", "total"]).map {|f| f.titleize }
Report.sales_for_date(@yesterday).each do |row|
csv << fields.map {|f| row[f] }
end
end
end
end
end
其中這段是代表附帶一份檔案,並且 a.body assign 給剛剛產生的 CSV Object 即可
attachment :content_type => "text/csv", :filename => "file_name.csv" do |a|
a.body = FasterCSV.generate do |csv|
# 填入剛剛的 code 即可
end
end

至於中間,就填入剛剛寫的跟 Active Record 連結的 code 即可。

至於要每天寄一份 Email 報表,請用 Crontab + Rails 裡面的 Runner 即可。

商業性語言?

剛剛又回去看這篇文章,發現作者的回應實在好歡樂呀。
還有 PHP 在 WIKIPEDIA 上被歸類為工業程式語言,並不屬於 script language。
原來如此,程式語言還可以這樣分工業程式語言跟 Scripting Language XD ,作者居然還振振有詞的這樣強調。而且 PHP 居然是工業編程語言而非 Scripting Language,真是大出我的意料之外,我居然沒聽過這樣的分類。


我得先翻翻看工業編程語言的定義,直接看原作者怎麼講的
Java 屬於工業編程語言

程式設計語言,通常簡稱為編程語言,是一組用來定義電腦程式的語法規則。它是一種被標準化的交流技巧,用來向電腦發出指令。一種電腦語言讓程式設計師能夠準確地定義電腦所需要使用的數據,並精確地定義在不同情況下所應當採取的行動。

程式設計語言原本是被設計成專門使用在電腦上的,但它們也可以用來定義演算法或者資料結構。正是因為如此,程式設計師才會試圖使程式代碼更容易閱讀。

原文出處 - Wikipedia - Programming Language


原來如此,原來這就是工業編程語言,我懂了。為了輸人不輸陣,我決定

公告:以後 Ruby 正式成為商業編程語言

商業編程語言,通常簡稱為騙錢語言,是一組用來定義如何快速而有效率瞎掰的語法規則。它是一種被標準化的詐騙技巧,用來向老闆發出虎爛。一種騙錢語言讓程式設計師能夠準確地定義搞定這個案子所需要使用的時間,並精確地定義要謊報多少金錢才能獲得這個專案。

商業編程語言原本是被設計成專門使用在快速開發上面的,但它們也可以用來應用在如何有效率的偷懶或者不被老闆發現的摸魚。正是因為如此,某些素性不良的程式設計師才會試圖使商業性語言更發揚光大,甚至寫一些嘴泡的極點的 Blog來推廣商業性語言。

原文出處 - thgiivepedia - Programming Language


我想說的是

最後作者終於在回應時,出來解釋他這句話
我還是要強調,Java 這類工業程式語言,並不是 script language 可以比較的。因為,拿香蕉跟芭樂比!?你要怎麼比!
我看過組合語言一樣可以做出小畫家,我學生時代也曾經用 Perl 寫一個很簡單的 C Compiler 。只要機器是跑在 tuning machine 的架構下,任何一種程式語言都可以做到其他語言做得到的事情,所以語言當然可以互相比較,有什麼不行?

程式語言就跟真實世界的語言一樣。你用啥語言寫 code 跟你用哪國語言講話一樣,都只是一個選擇而已。我選擇用 Ruby 寫程式,跟我選擇用中文講話一樣,都只是我這樣選擇而已。

Java 背後的專業性,應用範圍,絕對不是 JavaScript 那種 SCRIPT 語言可以比較的」,這句話就跟法國人一直強調的「講法語就是比講英語來的優雅」一樣可笑,充滿著不可思議的傲慢跟無知。我實在不懂用 Java 的人就比較有專業性?用 Scripting Language 就比較沒有專業性?專不專業這跟用什麼語言任何有關係嗎?一個教授的學術地位高低跟他用哪個國家的語言有關係嗎?

程式語言本身並沒有高下之分,程式設計師才有高下之分。

下面是網友的反應。

[2007/01/17]

  • 引述 :『Scripting language 的家族實在龐大,特性也各不相同。本文僅就 Python、Ruby 等語言的特性和 Java 做比較。其實,鄙視的行為人人都會,不單是阿西犘一人。我也常鄙視 MS 陣營的某 V 或某 B 語言,但是,這種事還是放在心裡就好,或私底下說。公開陳述,只會引發這種效果。』
  • 引述 :『這篇文章的用意, 只是想說一下, 每個程式語言都有他的應用的地方, 並不是說 Javascript 不嚴謹、應用範圍不廣, 就是 Java 被巴到連渣都不剩! 當初的 Java applet 紅透半邊天, 但是現在卻是 AJAX 當道。現在的 Java 應用是真的很廣, 如: 手機遊戲、電冰箱…等等,還有很多,但是現在人家真的要製作網頁上的動畫, 人家當然用 Flash + Actionscript, 而不是用 awt 在那邊苦的要命, 在 Linux 下作 routine task 用 shell 或 perl, 在 Mac 下也可以用 Apple script, 寫 kernel 用 C/C++,大部分的情況當然都可以用 Java 來取代,但是,還是不要沒事找自己麻煩的好。』
  • 引述 :『我覺得等到實做許多程式語言後,會慢慢跳向另一個角度,也就是設計。然而講設計,也不過像是在大家再爭論語言或技術一樣,可能會吵得更凶,不過比起直接討論語言的實做問題,又是再抽象化一層。我的組長可能角度更高階(接近使用者),總是在看需求,創意。我總是認為,真正有價值的工程師應該不會去限定自己解決問題的方法與理解範圍,而能夠瞭解每一個環節,原理,並善用其他技術取補足你正在使用的技術的不足。』
  • 引述 :『寫該篇沒有要打嘴砲,只是希望大家可以對javascript可以多一點認識,多一點了解。』
  • 引述 :『把 Python 分類到 dynamic language,看起來就比 scripting language 專業!』


1/15/2007

Scripting Lanuage 就比較不專業?

今天看到這篇文章,裡面提到
懂了嗎!? 不要再把 JavaScript 當成 Java 來看了。說真的,每次看到人家犯這種誤解,真的讓阿西摩感覺到我的專業被人家當成垃圾看待。因為 Java 背後的專業性,應用範圍,絕對不是 JavaScript 那種 SCRIPT 語言可以比較的!
我是不知道這位作者有多專業啦,不過寫出這樣的話,看來也專業不到哪裡去。

光是「絕對不是 JavaScript 那種 SCRIPT 語言可以比較的!」這句話,就會被 PHP / Perl / Python 社群罵死,根本不用 Ruby 來補這一刀。Javascript 雖然瀏覽器支援度亂了點,Debug 能力差了點,但是其他的功能也不差。現在最紅的 AJAX ,裡面的 Javascript 程式恐怕沒一定程度連看也看不懂,更別說寫了。

我常常對我朋友說一句話
如果這個世界所有語言都要毀滅,只有一個語言留下來,那一定是 Javascript
為什麼?在所有軟體開發漸漸走向 web framework 的同時,所有的語言都漸漸走向「可以被取代」,因為他們都是躲在 backend ,只要回傳的結果正確,誰管你用 C 還是 Ruby on Rails 。

但是 Web 是 Client Server 架構,很多功能需要前端的 Browser 也能夠可程式化。這時候,除了 Flash 以外,就是 Javascript 了。Flash 有很多因素讓他無法成為瀏覽器端最成功的前端語言,也就是說,現在 Javascript 呈現不可思議的獨大,並且無可取代。因為你要取代 Javascript ,你得說服 IE 、Firefox、Safari 都支援你的 Language,這簡直是不可能的任務。

也就是說,如果你不想學 Ruby on Rails ,也請你學學 Javascript 。你會了 Javascript,你可以在使用任何一種語言的網路公司任職,並且當你的公司系統更換架構( 類似 Java -> Ruby on Rails 之類)時,你也不用重新學習。

最重要的是,只要你的 Javascript 真的很厲害,二十年後應該還是不怕找不到工作。

Peepcode Screencast



Geoffrey Grosenbach 做了一連串的 Peepcode 的 screencasts,這一系列是有關於 Capistrano 的。有些是要錢的,有些是 Free 的。今天花了點時間看了 Free 版本的 Building a Full Rails Stack on Ubuntu 6.06,看完之後感想是

「還好沒花錢買」

一開始就花很長的時間,講解 Mac 上面怎麼用 Parrell Desktop 來安裝 Ubuntu,一直到 Ubuntu 灌好 ssh server 重開機,已經花了 2/3 時間。剩下的時間就是怎麼用 Capistrano 來安裝Rails 。真是令人失望的 Screencast。




1/11/2007

加強 Active Record 的關連性

很多時候我們會使用 Active Record裡面的條件式關連性,但是有時候會覺得使用的關連性似乎有點太多了、太繁雜了。




像是這樣,有兩個 User 有很多 Email ,但是我們想用 Email 的 status cloumn 來判斷是已讀還是未讀。

基本寫法

通常我們會這樣寫
class User < ActiveRecord::Base
has_many :emails, :dependent => :delete_all
end
我們可以使用來找出那些狀態是未讀,或是已讀的 email
a = User.find(1)
a.emails.find_all_by_status('read')
a.emails.find_all_by_status('unread')
比較好的寫法

但是這樣的壞處在於,假設今天資料庫要重構,我們要將 status 改成 read_status 的時候。我們得將所有的 code 改成
a.emails.find_all_by_read_status('read')
a.emails.find_all_by_read_status('unread')
這樣就變得一點都不 agile 了。所以我們應該這樣寫
class Email < ActiveRecord::Base
def read
@read ||= find(:all, :conditions => "status = 'read'")
end

def unread
@unread ||= find(:all, :conditions => "status = 'unread'")
end
end
如此就可以達成這樣的效果
a.emails.read
a.emails.unread
這樣的寫法。

更好的寫法

上面的好處是他可以簡單的達成不錯的型態,但是這也代表你會在 Email 這個 Model 裡面種入 read / unread 的資訊,當我們使用 Emails 的其他用途,read / unread 的資訊依舊可以使用。但是有些 function 其實是跟著 relationship 來走的,單獨使用並不恰當。這時候我們可以把將 function 值入在 relation function 裡面
class User < ActiveRecord::Base
has_many :emails, :dependent => :delete_all
has_many :read_emails, :class_name => "emails" ,:conditions => "status = 'read'"
has_many :unread_emails , :class_name => "emails" ,:conditions => "status = 'unread'"
end
這樣的作法可以達成下面的效果
a = User.find(1)
a.read_emails
a.unread_emails
另外一種方式

雖然方便,但是也意味著光是一個 Email 我們就建立了三個以上的 relationship,並且假設 table 裡面真的有一個叫做 read_emails 的 table ,那不就衝突了嗎?並且如果這個 function 太過複雜,我們是不是一定得在 :conditions 裡面放入更長的判斷 SQL ,有沒有其他的方式可以將 function 種入 relationship 裡面呢?

當然有,這裡有一篇文章講到一些 Active Record relationship Tips ,我最喜歡他的第二個 tips。

class User < ActiveRecord::Base
has_many :emails, :dependent => :delete_all do
def read(reload=false)
@read = nil if reload
@read ||= find(:all, :conditions => "status = 'read'")
end

def unread(reload=false)
@unread = nil if reload
@unread ||= find(:all, :conditions => "status = 'unread'")
end
end
end
在 relationship 後面,加入這樣的方式,可以做到
a = User.find(1)
a.emails.read
a.emails.unread
如此只需要一個 relationship 就可以做倒類似的事情。你或許會發現這個作法好像比之前的方式還要來得繁雜,但是當 :conditions 過於複雜的時候,這個作法就可以很簡潔的做到這件事情。

1/10/2007

「易遊」使用 Ruby on Rails 的原因


易遊是一個對岸開發,類似 delicious 的網站,他們公開宣佈使用 Ruby on Rails 來開發全部程式。並且也一一公布一些使用 Ruby on Rails 的原因。



他們使用的是 Linux + Apache 2.2 + Ruby on Rails(九成九是 Mongrel 啦)+ MySQL 5.0。一共六個人,採 xp 的開發方式,大概開發了三個月左右。

至於為何要使用 Ruby on Rails 呢?他們提出了相當接近我的想法的說法

我们inu的开发团队原本基本上都是Java的忠实追随者。从Struts + JDBC到Spring + Hibernate,我们一直都在尝试寻找一种比较成熟而又快速敏捷的Web解决方案。

在inu网络收藏夹的项目开始,我们团队内部也展开了激烈的讨论,究竟Java的严谨框架和卓越安全性是否能给inu带来我们所期望的生命力? 经过深入的学习和调查后,我们认为像Ruby这样的动态语言可能较之静态语言更适合我们的要求。

首先,硬件本身的进步给动态语言创造了发展的基础,在硬件比较弱的年代里,语言本身执行的速度是一个项目的根本,因此C和C++这样的语言得以广泛使用。 然而如今,当硬件的成长遵循摩尔定律突飞猛进的时代,语言本身的执行速度越来越不是一个项目所担心的根本。像Ruby这样的动态语言所带来前所未有的敏捷 性,大幅度提高了项目的开发速度和测试便捷性。这一切都创造了项目随心所欲的重构可能。这对一个随同网络不可预知的潮流共同进退的Web项目而言,无疑是 带来了更多的成功可能。

Web 上面太多變化,一切世事都太過詭譎,沒有人可以宣稱他一定可以抓到世界的潮流,也沒有人可以宣稱他們這個時間訂的 spec 就一定符合所有的需求,所以重構速度是相當相當重要的關鍵。與其將籌碼壓在訂定一個完美的 spec ,還不如加碼在加強重新調整程式的速度來的實際。

再来,由动态语言本身独特的“弱类型”,“反射”等所带来的独特敏捷性而创造的Web框架更给一个网络项目带来了无限可能。Rails的出现无疑给了 Ruby一个广泛为世人所知的机会。作为一个以“敏捷”为根本口号的Web框架,不论是从其Convension优先的配置,还是yml轻数据源的应用, 等等等等无时无刻不渗透出其作为敏捷开发领先框架的优势。

我们团队在将近3个月的开发过程当中,深刻地体会到Rails框架和以往框架项比较的不同。inu的开发经历了无数次大大小小的重构和改动,在Rails 简便的Unit Test,Functional Test的支持下,重构变得异常便捷和舒畅。Active Record扮演着原来Hibernate的角色,无须任何xml的配置让Model一层的开发变得非常快速。作为一个典型的MVC框架,他在整体的部 署、测试和重构的便捷性上都超越了Spring+Hibernate这样当下比较流行的开发方式。虽然不得不承认Rails在速度、安全性和本地化方面都 存在着他的不足,但是作为一个新兴的网络框架加上新兴的动态语言,他所具有的独特敏捷性无疑是当下发展飞速的互联网最需要的开发工具。
一切都在於這個 Project 需要的特色是什麼?而不是這個開發框架是不是完美的。Web 需要的是快速反應世界的潮流,所以 Ruby on Rails 才會那麼的吃香。相比較其他完整的 Java Framework,或許他有些不足之處,或許他有些不利之處,但是 Web Framework 亟需 Ruby on Rails 的長處, Ruby on Rails 的短處在他的優點太過明顯之下,全部都被極小化。

美國的路又大條路程又超遠,所以家家戶戶都需要汽車,台灣普遍路程在 15分鐘以下,大街小巷的機會超級多,所以機車才在台灣那麼普遍。這不是說機車比汽車好,而是機車比汽車更適合台灣。同理選擇 Framework 不是考試,不需要選出一個第一名,一切都在於這個 Project 需要的特色是什麼?這才是重點。

1/08/2007

如何用 svn 開發 Ruby on Rails

Subversion 是市面上最常用的 version controller 的系統,這篇主要是介紹如何用 Subverison 開發 Ruby on Rails 程式。其實開發 Ruby on Rails 程式就跟開發其他的程式一樣,你依舊可以用任何你以前用過的 svn 技巧,但是 Ruby on Rails 也跟 Subverison 作了相當好的整合,不用實在可惜。

創立一個新的 Project
請在一個 svn 的目錄下面,創立一個 rails project ,叫 abc 好了
rails abc
進入 abc,將所有程式加入 version controller
cd abc
svn add . --force
將新增的 Project 送到 svn 資料庫
svn ci -m "Starting a Rails Project"
log 跟 tmp 資料都是放些暫存的檔案,不需要進 svn 資料庫,將 log 跟 tmp 排除 svn 資料庫
svn remove log/*
svn remove tmp/*
svn propset svn:ignore "*.*" log/
svn propset svn:ignore "*.*" tmp/
svn ci - m "removing log and tmp files”
Generator 時順便加入 svn 資料庫
ruby script/generate 任何東西時,因為一次會產生很多程式碼,記得加入 -c 或是 --svn 這個選項,順便加入 svn 資料庫。

Destroy 時順便移除 svn 資料庫
ruby script/destroy 任何東西時,因為一次得砍掉很多程式碼,記得加入 -c 或是 --svn 這個選項,順便將要移除的東西移出 svn 資料庫。



1/07/2007

網頁版面大改

慶祝新 Domain:http://lightyror.thegiive.net 開張,我開始準備調整本 Blog 所有功能,並且加入一些 wiget,希望能夠達到更佳的瀏覽效果,大家有意見可以跟我講。

另外一點,右邊的連結是我認為目前市面上最好的服務,跟我在哪家公司工作以及我跟誰很熟沒有任何的關係。


本Blog使用 Module
  1. Email Icon Generator
  2. Blogger 繼續閱讀簡單版
  3. 將Blogger Beta的Label作成Label Cloud
  4. RGB 色彩轉換器
  5. FeedButton

newgem:方便打包 gem 的東西

當我看到KDr2這篇简单漂亮的打包GEM的時候,心裡想到的是「這真的解決了我許多問題」。有些程式碼其實我想打包成 gem code 來方便再利用,卻不知道該怎麼包 gem(其實是自己懶)。現在可好了,有 newgem 這個神兵利器,以後可沒藉口不包 gem 了。以下是參考KDr2简单漂亮的打包GEM


使用方式:

1. 安裝 newgem

gem i newgem

2. 產生 gem package 的資料夾結構
假設我們要包的 gem 名字叫做 abc
newgem abc
3. 我們的 code 放置點
假設我們要包的 gem 名字叫做 abc ,那麼我們的 code 就放在 這裡裡面
lib/abc.rb
依照 module 方式來撰寫

4. 打包 gem file
rake package
這時已經打包好了,放在 pkg/abc-0.0.1.gem

5. 修改版本號碼
預設是 0.0.1 ,如果你想修改 gem version number ,請修改
lib/abc/version.rb
  1. module MapByMethod #:nodoc:
  2. module VERSION #:nodoc:
  3. MAJOR = 0
  4. MINOR = 0
  5. TINY = 1

  6. STRING = [MAJOR, MINOR, TINY].join(’.')
  7. end
  8. end
修改裡面的數字即可

延伸閱讀



1/06/2007

新域名 http://lightyror.thegiive.net 開張

因為 Blogger 已經改成可以自訂 Domain Name,所以我馬上去註冊了一個個人 Domain 叫做 thegiive.net。本站原來網址 http://lightyror.blogspot.com/ 正式改成 http://lightyror.thegiive.net/

主要更改有幾個 issue
1. Feed 有兩個
  • feedburner的 feed 完全沒有變化,依舊是 http://feeds.feedburner.com/LightyRor
  • 另外一個原本的 Feed http://lightyror.blogspot.com/feeds/posts/default 已經改成 http://lightyror.thegiive.net/feeds/posts/default,雖然我想原本的 feed 連結新的文章應該也沒有問題,不過還是希望大家使用 feedburner 的 feed。
2. 所有連結應該會自動從 http://lightyror.blogspot.com/ 轉成http://lightyror.thegiive.net/ ,我想應該沒有任何改變。

Google 這次啟動 Blogger 自訂 Domain 的服務,到目前為止我還沒遇到任何問題,包括 Feed 跟連結都可以完全無誤的轉換,實在是太厲害了。



[轉錄] 世界喜愛 Ruby 的理由 - 專訪松本行弘(摘要)

這是日経 BP主辦的「次世代開發論壇」時的訪談 Matz (Ruby 作者),於 2006 年 12 月底刊載的。原文在スペシャルインタビュー 世界がRubyを愛する理由,PTT 的 ericyu 進行翻譯以及中文哉要,出處在此。本人在獲得 ericyu 書面同意下,進行轉錄的工作。本圖以及文章版權屬於日經 BP 所有,如本文章發佈形式有版權問題或是不妥,請來信告知。



看完之後的感覺

這篇主要講的是 Ruby 的歷史,但是 Matz 也提到他認為未來語言的趨勢在於多CPU的平行化,個人認為他的想法非常的正確。或許最快10年後,所有的程式語言都得加入平行化處理的技巧,不然被淘汰只是遲早的事情。

原文開始

在 Ruby 的 mailing list 上,英語討論量約為日語的十倍。Ruby 的 conference (Ruby Conference) 也是國外先,例如美國 (RubyConf) 2001,歐洲 (Euruko) 2003,日本 (RubyKaigi, [報導] [網站]) 2006。

Ruby 的英文相關書籍已有 30 本以上,2000 年在美國的 Programming Ruby 是第一本。目前銷售量甚至超越 Perl 及 Python。

Rubyforge 上也有超過 2500 件專案,這些專案幾乎都是以國外開發者為中心。

為何創造出 Ruby?

本來就喜歡語言,原本想設計一種自然語言,不過不太行,後來覺得如果是程式語言的話自己就作得到。大學進入程式語言研究室,光只有構想的語言就有好 多,如果連只有想到名字的也算大約有 11 個 (笑)。實際動手的只有 2 個。學生時所作的是幫 C 加上 Eiffel 風格的 OO。

會想做 Ruby 是因為同事(石塚圭樹)「Perl 寫來方便但讀起來很難。如果有好的 OO Scripting 語言就好了」。雖然當時有 Python,不過沒有內建 regular expression,寫起來不像 Perl 那樣快速。因此想寫一個能兼有 Perl 的快樂及 OO 美感的語言。

1995 年 12 月 Alpha 版在 newsgroup 上公開。收到了很多 bug report,為了修正 bug,睡眠時間都變少了。

為何很快就擄獲了最開始的使用者?

希望能很方便的處理文字,寫 script,大概是這樣的使用者吧。此時對於感到 Perl 極限的使用者選擇有三個: Perl5,Ruby,Python(按: Perl 5 於 1994/10 released)。Python 剛提過沒內建 regular expression,而 Ruby 比 Perl OO 得更徹底。

很多使用者送來 patch 或應用。譬如有天送來一個 patch,發現只要 patch 後,就能讓 Ruby 支援 UTF-8。

海外的使用者是如何擴大的?

Programming Ruby 開始。

創造 Smalltalk 的 Alan Kay,創造 Objective-C 的 Brad Cox,以及提倡重構 (refactoring) 的 Martin Fowler 也注意到 Ruby。

2004 年推出的 Web Application Framework - Ruby on Rails 使得 Ruby 廣泛備用在商業上。O’Reilly 站內文章提到生產力是 Java 十倍,雖然是否有十倍尚有爭議,但實際寫程式的量只有十分之一。RoR 作者 David Heinemeier Hansson 說 Ruby 是「能寫出美麗的程式碼,能使程式員快樂的語言」。

要怎樣能寫出普及世界的軟體呢?

回頭看 Ruby 的例子,覺得是因為累積了很多的幸運。不過,一開始就有想到「不要只有侷限在日本」。1997 年開始有英文 mailing list,ChangeLog 也附了英文,集結 Ruby 應用的 Ruby Application Archive 也希望日本使用者用英文登錄。

日本也有很多有趣的技術,但缺乏英文文件等有很大的語言隔閡。

回到 Ruby,當初是追求「要怎麼作才能讓自己能快快樂樂寫程式」,而將自己想要的東西具體化。Ruby 並沒有作出什麼其他語言沒有的創舉,而是相信程式員的感受,從現有程式語言中選出對使用者來說好用的東西。這就是 Ruby。

想要的是能將自己的工作立刻變為程式語言。最好是能這樣:將腦中所想到的演算法給記下來,就能直接變成程式跑。為了讓程式動,往往要經過一大堆繁雜的程序。不過,我們不是為了電腦而工作,而是要讓電腦替我們工作。所以要能夠快樂寫程式,我是這樣想著而創造 Ruby 的。

之後程式語言會如何進化呢?

多核心是現在注目的焦點。不久將來可能大家電腦都是 64-core,128-core,task 的分配就不可能以 thread 進行,而不得不自動化。程式語言的平行化處理能到什麼地步呢?說不定不是 C 或 Ruby 這種 procedural language,而是 functional language 存活也不一定。

我認為必須要有更多程式語言被創造出來才行。無數的應用程式創造出了 design pattern,就像(圍棋的)定石一樣。相較之下,目前也有幾千幾萬種程式語言了吧?但是程式語言的 know-how 仍未確立。希望年輕的工程師們來挑戰程式語言的開發。

2006年12月21日 ITpro

關於まつもと ゆきひろ (Matsumoto Yukihiro,松本行弘)

中學二年級時,在父親的口袋型電腦 Sharp PC-1210 上以 Basic 寫了第一個程式。1984 年進入筑波大學第三學群資訊(情報)學類。大學其中兩年休學,從事基督教傳教工作。大學時在程式語言研究室,1990 年畢業。1993 年以來,一直從事物件導向程式語言 Ruby 的設計與開發。

1997 年開始,在「株式會社 Network 應用通信研究所」擔任特別研究員,專注開發 Ruby。著書: 「物件導向 Script 語言 Ruby」(與石塚圭樹共同著作),「Ruby Desktop Reference」,「軟體工匠(ソフトウェアの匠)」等。自稱「語言 otaku」 (語言宅男?)。在家中是三個女兒與一個兒子的爹。




1/05/2007

Rails 1.2 RC 2 出了

Rails 1.2 RC 2 出了,安裝方式參考 RC1 。這個月之前能不能出來 Rails 1.2 Release 呢?很好奇。

[整理] Windows 上面跑 Apache 2.2 + Mongrel

Windows 上面 Ruby 效能不佳,所以我曾經建議不使用 Windows 作為 Service 環境。但是如果你真的要用 Windows 作為 Server ,你可以看這一篇。

不過請注意,我在之前就講過,我沒有 Windows 可以測試,只能整理別人的文章。尤其參考最多的是 Robbin 寫的 在Windows平台使用Apache2.2和Mongrel运行Ruby on Rails,雖然沒有照著翻譯,但是你依舊可以視這篇文章為 Robbin 本文的繁體中文整理翻譯版,榮耀是歸於 Robbin 的。

安裝 Ruby on Rails and Mongrel
下載Windows版的Ruby來安裝,安裝時請記得裝 RubyGems。再來請用 gem 安裝下列三個套件
gem i rails mongrel mongrel_service –y
啟動 mongrel_service
mongrel_service 就是 Windows 上面 Win32 Service 的 plugin。我們要先將 Mongrel 登記為其中一個 Windows Service。
mongrel_rails service::install -N service_name -c c:\rails\service -p 3000 –e production
  • -N :win32 service 名字
  • -c:Rails 程式 root 目錄
  • -p:聽的 port
  • -e:Rails 環境
仔細去看Win32 的service list,你會發現出現了一個你剛剛登記的 service_name。啟動的話就是
mongrel_rails service::start -N service_name
停止就是
mongrel_rails service::stop -N service_name
取消 service 登記就是
mongrel_rails service::remove -N service_name
如果你想 Windows 啟動,自動啟動 Mongrel Service,請按下
sc config service_name start= auto
如果你想說順便一起啟動 Mongrel Service 跟 MySQL,請按下
sc config service_name start= auto dependency= MySql

Mongrel_cluster ?
大家一定很懷念 Mongrel Cluster 這樣的神兵利器吧,很可惜,Windows 上面沒有 Mongrel Cluster,所以大家要啟動 3000 ~ 3009 就得這樣搞
mongrel_rails service::install -N service_name1 -p 3000 –e production
mongrel_rails service::install -N service_name2 -p 3001 –e production
mongrel_rails service::install -N service_name3 -p 3002 –e production
...
mongrel_rails service::install -N service_name4 -p 3009 –e production
笨嗎?蠢嗎?所以才跟你說 Ruby on Rails 不適合用 Windows 咩。
安裝 Apache 2.2
去 Apache 網站下載 Apache 2.2 Windows 版本。然後在httpd.conf enable module
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
使用 config file 就如同我這個網頁寫的方式,或是直接看 Robbin 寫的也可以。


延伸閱讀


Ruby 快速參考表

有些關於 Ruby 的小東西,隨著我的需要會使用他,為了怕忘記,所以特別寫一個網頁來記載他。隨著我寫 Ruby 的需求慢慢增加,這個網頁會一直不斷低更新。


事先定義好的 Global Constant
  • ENV :一個記載所有環境變數的 Hash
  • ARGV:一個記載所有 Command Line Argument的 Array
範例:
今天有一個 ruby a.rb 123 456
那麼他的 ARGV[0] = 123,ARGV[1] = 456

Ruby Regular expression modifier
範例在 Ruby 的 Regualr Expression Modifier
  • /i :大小寫 case insensitive
  • /m :原本是只 match 單行, m就是開到多行模式
  • /o :當進行取代時,只取代第一個 match pattern 。當沒有使用 o ,他會取代所有 match 的 pattern
執行 shell command
  • exec "command"
  • `command`:要注意裡面的`是第二個是鍵盤左上角,esc 下面的 `
延伸閱讀

Robbin 所提供的 spwan-fcgi shell script

Robbin 提供一個 spwan-fcgi 的 shell script,我記錄下來,相信對於 Lighttpd + fastcgi 的使用者很好用。以下是 Robbin 所提供的 script

#!/bin/sh  
DISPATCH_PATH=/yourailsapp/public/dispatch.fcgi
SOCKET_PATH=/tmp/lighttpd/socket
RAILS_ENV=production
export RAILS_ENV

case "$1" in

start)
rm -rf $SOCKET_PATH/javaeye.socket-*
for num in 0 1 2 3 4 5 6 7 8 9
do
/usr/local/lighttpd/bin/spawn-fcgi -f $DISPATCH_PATH -s $SOCKET_PATH/javaeye.socket-$num
done
;;

stop)
killall -9 dispatch.fcgi
rm -rf $SOCKET_PATH/javaeye.socket-*
;;

restart)
$0 stop
$0 start
;;

*)
echo "Usage: dispatch.sh {start|stop|restart}"
;;

esac

exit 0

啟動前,Ruby Fastcgi ,Socket Path ,Rails Enviroment 部份要設定正確,要啟動就打
sh script-name start
即可。



[筆記] 我觀 Roobin的「在Linux平台上安装和配置Ruby on Rails详解」

Roobin 寫了一篇 在Linux平台上安装和配置Ruby on Rails详解,裡面不只寫到一些基本的程式碼 make 的基本技巧,還提出許多性能上面的議題,實在是一篇好文章,下面有一些我看這篇文章所作的筆記記錄下來。

1. GC Path
Ruby解析器的GC Patch 這段介紹
根据他的评测表明,使用GC Patch并且设置了合适的GC参数之后,Ruby GC次数下降到原来的十分之一,有效的提高了Ruby在高并发情况下的吞吐能力
還有
这里值得一提的是,使用GC Patch和设置相应的参数之后,每个Ruby FCGI进程耗用的驻留内存是原来的两倍,因此除非你的服务器物理内存非常多,否则要慎用,避免Ruby FCGI吃光你的服务器内存。
這裡從來不知道有差,真的是長了智慧,

2. 請多安裝 mysql-ruby
rails发行包中已经自带纯ruby的MySQL数据库适配器,然而对于生产环境来说,我们仍然应该下载安装C版本的数据库适配器,以达到更好的性能。
我也聽說 ruby-mysql 比 mysql-ruby 來得慢。

3. 安裝 MySQL Ruby Patch
Stefan Kaes在这篇博客中提供了MySQL适配器的patch文件,根据他的评测,可以提高数据库访问30%左右的性能,因此建议用户下载使用该patch文件,那么安装过程改为:
tar xzvf mysql-ruby-2.7.3.tar.gz
cd mysql-ruby-2.7.3
patch < ../ mysql-ruby-2.7-less-string-copies-in-each-hash.diff ruby extconf.rb --with-mysql-dir=/opt/mysql5 make && make install

可以試試的 Patch。
4. 啟動 Fastcgi 數量要慎選
一般而言,不需要启动数量很多的FCGI进程,一个FCGI进程类似于一个Java应用服务器,启动10个FCGI类似于启动10个Java应用服务器了。由于Web Server和FCGI请求处理的网络速度差异,以及Web Server需要处理大量静态资源,经验数据表明:10个Web Server并发连接,仅仅需要1个FCGI并发进程。因此10个FCGI进程可以支撑100个Web Server的并发请求了,大约可以达到每天30万PageView。不过如果考虑到峰值并发,可以适当增加FCGI进程数量。
這裡的經驗法則很值得參考。

5. OS 選擇
另外我个人也不建议用ubuntu或者gentoo作Linux Server的OS来跑,作为一个服务器操作系统来说,要求是稳定可靠,硬件,软件,应用的兼容性好。

當然啦,我對於 OS 的選擇沒啥意見啦,這是使用者口味的不同,所以不加評論。我只能說我喜歡用 Ubuntu 來跑 Server,而樂多跑 Gentoo Linux 來跑得蠻穩的。大家都是 Linux ,Kernel 都一樣,使用套件也都差不多,穩不穩定,還有相容度好不好只是管理者功力的問題。

延伸閱讀
  1. Railsbench 官方網站
  2. MySQL-Ruby
  3. Stefan Kaes 提到的 Ruby-MySQL Patch



唉,實在不想提,但是還是得提出來

某些事情我必須要提出來講,仔細看一下本網頁的右下角,跟最下方,本網頁內容均採用Creative Commons 姓名標示-非商業性-相同方式分享 2.5 台灣 授權條款授權。這代表幾件事情

  1. 請標示我的姓名
  2. 不要拿去作商業使用
  3. 要分享,請用相同的 License 分享
只要不違反這三件事情,我的東西隨便你用。

至於標示姓名,請標示在文章的前頭,像是
這是出自 thegiive 的 blog ,裡面寫到 .....
我想我的 Google Page Rank 在中文 Ruby on Rails 分類裡面算很前面的, Ruby on Rails 的圈子不大,有人違反這個 License 的話,我想會去看的人都心知肚明「你在搞什麼」。


1/04/2007

Ruby 的 Regualr Expression Modifier

Ruby的 Regular Expression Pattern 是參照 Perl 的模式的,他的格式分為
/pattern/modifiers

pattern 就是 regular 的 matching pattern,這裡的部分 Programming Ruby 介紹很多了,所以就不再介紹了。而 modifier 就是一些重要的選項,主要分為
  • /i :大小寫 case insensitive
  • /m :原本是只 match 單行, m就是開到多行模式
  • /o : 當 matching pattern 裡面有 #{variable_name} 變數的時候 , 他只會產生一次 regex object , 隻後如果有重複利用到這個 regex object 的時候 , 他會直接利用原來的 object , 而不會判斷裡面的 #{variable_name} 是不是其他的值 . 原因是因為這樣可以增加效率的因素 .
  • /uunicode support
範例:

1. case insensitive
irb(main):020:0> puts 'Match' if 'AbC' =~ /abc/
=> nil
irb(main):020:0> puts 'Match' if 'AbC' =~ /abc/i
Match
=> nil

2. 多行模式
irb(main):033:0> puts 'Match' if "abc\nd" =~ /a.*d/
=> nil
irb(main):034:0> puts 'Match' if "abc\nd" =~ /a.*d/m
Match
=> nil
3. /o 比較難理解 , 我第一次也理解錯誤了 . 幸好有 gugod 指証 , 再次感謝 . 這個例子改自 gugod 提供的例子 , 我覺得會比較清楚情況如何 .
["abc", "foo"].map do |a|
regex = /#{a}/o
puts "regex object id with o modifier is #{regex.object_id} and content is #{regex.inspect}\n"
end

["abc", "foo"].map do |a|
regex_no_o = /#{a}/
print "regex object id without o modifier is #{regex_no_o.object_id} and content is #{regex_no_o.inspect}\n"
end
出現訊息如下
regex object id with o modifier is -605885768 and content is /abc/
regex object id with o modifier is -605885768 and content is /abc/
regex object id without o modifier is -605885898 and content is /abc/
regex object id without o modifier is -605885958 and content is /foo/

有 o 的 regex 雖然變數 a 改變了 , 但是 object_id 依舊相同 , 內容也是一樣的 , 證明有 o 的 regex 不會更改其內容 . 但是預設的 regex 還是會重新產生一個新的 regex

4. /u 就是 unicode support ,這裡有一個蠻好的實做方式可以做到 unicode 截字
  1. strs = str.scan(/./mu)
  2. strs[0,400].join
這裡面 /mu 就是 multiline 模式下使用 unicode 模式,先將他們拆成每個字一個 array ,然後再將array 前 400 個 element 取出來 join 成一個字串。


延伸閱讀



最近忙的事情

最近在忙一些小行銷專案,其實發現對 Rails 有心得之後,很多案子簡直是瞬殺。

博客來百大投票

Esquire 2007男女婚姻觀調查


TIOBE 1月排行:Ruby 進入十大!!!

本週的 TIOBE 排行出來了,結果是 Ruby 進入十大!!!,並且當選 TIOBE 2006 Programming Language of the Year。該怎麼形容這一刻的感覺呢?
是的,Ruby 的確成為走向主流了
Ruby 在沒有大公司支援,只靠社群跟網路的推廣下就拿下了十大語言之一,並擁有 2006 年最高的成長率(2.15%),Programming Language of the Year 當之無愧。根據 TIOBE 的報導,Ruby 跟 Javascript 都是本年度最 Hot 的語言,他們代表了
Both languages are boosted by their corresponding frameworks, Ruby On Rails and Ajax. This might be a new trend. In the recent past it was necessary to have a large company behind the language to get it in the spotlight (Sun with Java, Microsoft with C#), but nowadays a killer app appears to be sufficient. Viral marketing via the Internet works!
以往要推程式語言都得靠 Java 或是 C# 模式,有大公司在背後撐腰,但是Ruby,Javascript 這兩個語言都只是靠 Framework 就可以獲得那麼多 spotlight,這在以前的程式語言世界是不可思議的事情。
The winners of the last 2 years, PHP and Java, are the losers of this year. Other trends that are observed are the growth of dynamically typed languages and the fact that the difference in popularity between languages is getting less.
PHP 跟 Java 是前兩年(2004~2005)的大贏家,但是很明顯在2006年,這兩者成為今年的輸家。另外一個重要的趨勢是,動態 Scripting 市場正在成長。

寫Blog這段時間,隨著讀者來信的增加,還有許多市場上詢問度變高,我相信我對 Ruby on Rails 的付出是正確的。我認為下個階段的 Ruby 的引爆點在於
  1. Rails 1.2 的推出
  2. JRuby 1.0 的推出
相信這兩個版本的推出應該都是殺手級的震撼,加油吧,Ruby and Ruby on Rails。

Position
Jan 2007
Delta in
Position
Programming
Language
Ratings
Jan 2007
Status
1 Java 19.160% A
2 C 15.807% A
3 C++ 10.425% A
4 (Visual) Basic 9.123% A
5 PHP 7.943% A
6 Perl 6.237% A
7 C# 3.521% A
8 Python 3.502% A
9 JavaScript 2.845% A
10 11 * Ruby 2.519% A

TIOBE 趨勢圖首次出現 Ruby 的蹤跡




1/03/2007

Ruby 中文使用者聯播 wiget



新年來個新禮物,我用 FeedBurner 跟 Spring Wiget 燒了一個中文 Ruby 使用者聯播的 wiget ,包含繁體中文跟簡體中文的 Ruby and Rails Blogger。

RSS feed 是來自我整理的 中文 Ruby 使用者星球 ,Feed Url 是使用 Feed Burner
http://feeds.feedburner.com/chineseruby,想加入聯播請來信告知。如果你想要在 Blog 加入這段 flash ,請把下面的code 加入

<embed src="http://downloads.thespringbox.com/web/wrapper.swf" flashvars="file=http://downloads.thespringbox.com/widgets/RSS Reader.sbw¶m=http%3A%2F%2Ffeeds.feedburner.com%2Fchineseruby|http%3A%2F%2Ffeeds.feedburner.com%2Ftwruby|http%3A%2F%2Ffeeds.feedburner.com%2Fcnrubypodcast&memberId=thespringbox" quality="high" wmode="transparent" width="250" height="300" align="middle" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed><div style="font:11px/12px arial;width:250px; text-align:center;"><a href="http://www.springwidgets.com/widgetize/23/?param=http%3A%2F%2Ffeeds.feedburner.com%2Fchineseruby|http%3A%2F%2Ffeeds.feedburner.com%2Ftwruby|http%3A%2F%2Ffeeds.feedburner.com%2Fcnrubypodcast&">Get this widget!</a></div>
要調整大小,請按下聯播器下面的 Get this wiget ,調整 wiget 的大小即可。

延伸閱讀