微軟即將把IE6強制升級至 IE7

從大神那看到的，微軟將作一件功德無量的好事，他們即將在今年二月十二號，利用 Windwos Server Update Service 將系統裡面的 IE6 改成 IE7。

相信此一升級對於 IE6 only 網站來說是一個大震撼，恐怕也會有大幅度的網頁改版潮。但是對於任何一個網頁程式設計師，或是網頁美工來說，都是一個放鞭炮的消息。

Thin ：有可能超越 Mongrel 的 App Server

介紹

在Zed Shaw 離開了 Mongrel 之後，每個使用者人心惶惶，不知道 Rails 的 App Server 會不會出大問題。這時候，彷彿在跟 Zed 說「Rails 社群不會被打敗」，Thin 出現了。

Thin 是一個 Mashup App Server ，採用了作者認為 Ruby 當中數一數二好的 Lib

• Mongrel Parser：Mongrel 速度跟安全性的根本
• Events Machine：快速，穩定的 Network IO Lib
• Rack：Webserver 跟 Ruby 之間的 Interface

這幾個強大的 Lib，整合在一起分工合作，讓 Thin 成為安全，穩定，快速，好擴充的 Web Server。

當然，快速是他第一個優點。在他的測試中， Thin 超越了 Mongrel 跟 Event-Driven Mongrel。
JavaEye 網友的測試也發現，不論是 Ruby 1.8 ，Ruby 1.9，Thin 的速度也是超越 Mongrel 。Ruby 1.9 裡面 req/s 居然是 4154 : 1313 的可怕差距

Mongrel 1000 100 1313.19 0
Thin 1000 100 4154.67 0

安裝方式

用 gem 安裝即可

gem i thin

要執行 thin ，就是在 Rails 的根目錄下執行

thin start

可惜沒有 Cluster 版本，不過，對岸網友已經寫了一個應急的 rake file，只可惜沒有指定 Port 的 command，所以我稍微修改一下成為這樣

namespace :thin do

namespace :cluster do

desc 'Start thin cluster'
task :start => :environment do
`cd #{RAILS_ROOT}`
(ENV['SIZE'] ? ENV['SIZE'].to_i : 4).times do |i|
Thread.new do
port = ENV['PORT'].to_i + 1
str = "thin start -d -p#{port} -Ptmp/pids/thin-#{port}.pid"
str += " -e#{RAILS_ENV}"
puts "Starting server on port #{port}..."
`#{str}`
end
end
end

desc 'Stop thin cluster'
task :stop => :environment do
`cd #{RAILS_ROOT}`
Dir.new("#{RAILS_ROOT}/tmp/pids").each do |file|
Thread.new do
if file.starts_with?("thin-#{port_range}")
str = "thin stop -Ptmp/pids/#{file}"
puts "Stopping server on port #{file[/\d+/]}..."
`#{str}`
end
end
end
end

end
end

將這個東西貼在 Rails 根目錄的 Rakefile ，將它貼在最後面，然後執行下面指令啟動

rake thin:cluster:start RAILS_ENV=production SIZE=10 PORT=4000

灰色的代表可以自己填寫的選項，包含 Rails 啟動的 enviroment，執行幾個 thin ，還有從哪個 Port 開始 listen。有用過 mongrel_cluster 應該都很清楚。停止就是

rake thin:cluster:stop

他會砍掉 tmp/pids/thin- 開頭的 pid file。

Sun 買下 MySQL

今早看到的新聞，還蠻震撼的，Sun 買下 MySQL。此舉讓 Sun 成為 Open Source 廠商中數一數二的領導地位。BTW，nobody knows it will be good or bad.

SANTA CLARA, CA January 16, 2008 Sun Microsystems, Inc. (NASDAQ: JAVA) today announced it has entered into a definitive agreement to acquire MySQL AB, an open source icon and developer of one of the world's fastest growing open source databases for approximately $1 billion in total consideration. The acquisition accelerates Sun's position in enterprise IT to now include the $15 billion database market. Today's announcement reaffirms Sun's position as the leading provider of platforms for the Web economy and its role as the largest commercial open source contributor.

JRuby 1.1 RC1 Release

本文

JRuby 1.1 RC1 Release!!!。正如之前所看到的消息，JRuby 1.1 跟 JRuby 1.0 最大的改進就是在 Performance 的不同，速度上比起 1.0.2 約有 27% 的改善，主要的改進有兩個

1. JRuby 可以用 Ahead Of Time (AOT) 或是 Just In Time (JIT) 兩種模式進行 compile。
2. JRuby 使用 Oniguruma 的 JRuby porting Juni，當作 Regular Expression 的 Engine。

總之，恭喜 JRuby Team。

下載：http://dist.codehaus.org/jruby/



本文結束後的講古，爆米花請準備好

說到 JRuby 的 regular expression ，可有說不完的故事（可以看 InfoQ版本）。

早期 JRuby 原本使用 Java 1.4 以後內建的 regex ，雖然很簡單，但是以一個目標是 Ruby 1.8 compatiable 的 project 來說，Java 內建的 regex 不合用。為了解決這個問題， JRuby Team 改採用 JRegex ，並且也納入了 JRuby 1.0 裡面。

但是 JRegex 某些細節跟 Ruby Regex 不太類似，依舊傷害了JRuby 對於 MRI Ruby 的兼容性 ，而且 JRegex 以 Java 的程式來說，已經算很快了，但是依舊不夠快速。 JRuby Team 在測試JRuby 跑 Rails 的時候，他們發現 regular expression 成為顯著的 Bottleneck。

And I found that there was one in particular that had really interesting performance when comparing MRI to JRuby. In fact, it was between 200 and a 1000 times slower. What's worse, the performance wasn't linear.

所以他們決定使用更快的 Regular Expression Engine 來徹底解決 JRuby on Rails 的效能問題。他們選中了 Oniguruma 這個 Ruby 的 regular expression Engine，這是 Ruby 1.9 內建的新 Regular Expression Engine。

Oniguruma 看來難念，其實是日本字，意思是鬼車，不過比起鬼車，我比較喜歡對岸的講法 XD

O ni guru ma
哦 , 你 咕噜 吗？

真的好記很多。Oniguruma 支援多個 charset 的 regular expression，已經是一個成熟的 regular expression engine。所以 JRuby Team 選擇了 Oniguruma 當作新的目標，將他 Porting 成 JRuby 版本，並且將他改名為 Juni。後來發現 Juni 相對於 JRegex ，的確對於 JRuby 帶來了顯著的效能上升。

Ruby 跟 Python 本質上不同

前言

對岸高手孟岩最近寫了一篇「Ruby 1.9不会杀死Python」，裡面提到 Ruby 1.9 一出，彷彿 Ruby 已經邁向完全體，所有的缺點都已經消失了。彷彿已經要一統武林

有人认为，这下子不得了了，Ruby要称霸动态语言了。你想想，Ruby已经几乎拥有了所有梦幻般的语言特性，神奇的动态能力，强大的支持库，内置的跟Perl可以比肩的正则表达式，Smalltalk级别的纯而又纯的面向对象特征，简洁明快的风格，跨语言整合也非常容易，唯一的缺点就是速度慢。现在连这个缺点都被弥补了，Ruby还能挡得住吗？其他的动态语言都该歇菜了。

然後他又提到一個很有趣的分類，Ruby 是魔幻語言，Python 是簡約語言。Robbin 老大也出來講了Ruby为什么会受程序员的欢迎？。一整篇看下來，實在是很過癮。

簡約語言

簡約語言是什麼呢？大致上是 C、PHP、Python和Lua，C# ，Java。他的大概意含可以由Python 的中心思想 EIBTI 可以略知一二

Explicit is better than implicit.

看不懂的話，用更白話的方式來解釋，The Zen of Python 裡面有提到

There should be one-- and preferably only one --obvious way to do it.

也就是，Python 有意的限制語言的表示方式，使得不好的 coding 習慣都不能 Compile 過，有意的強制使用者養成良好的習慣。

這雖然極端了點，但也不超乎其他簡約語言的中心思想。簡約語言不關心語言的表述方式，他們在乎的是「解決問題」。以工程來看，簡約語言在大專案裡面的協同工作上面較為吃香。

魔幻語言

我很喜歡這個詞。魔幻語言的代表有 C++、Perl、Javascript和Ruby。中心思想可以由 Perl 的 TMTOWTDI 來表示

There's More Than One Way To Do It.

魔幻語言的擁護者思考的東西，這位孟岩老大也描寫的很傳神

他们写的代码是一种谜语般的艺术，出谜语和猜谜语的人们都能从中获得巨大的精神满足

但是，請不要輕易的把 Ruby 歸於「華而不實」這一派。Robbin 老大也在這裡講到

C++的魔幻语法会导致代码的可读性变差，而Ruby的魔幻语法会导致代码的可读性大大提高。

不论是matz本人，还是整个Ruby社区，Rails社区诸多开源项目的作者，抑或整个Ruby和Rails开发者社区，在一个编程哲学问题上是高度统一的，这就是：

强调程序员的快乐编程，追求人性化编程，在代码的可读性上面有偏执的追求，拒绝难以阅读的代码和难用的API。也就是所谓的coding for fun!

Ruby 奇妙的手法，以及 DSL 的技巧，都是為了達到跟 Python 同樣的 Promise Land ，那就是「code 可讀性」。只是兩者作法不同而已。

兩者的不同

兩者最大的不同是在「開發者的審美觀以及開發風格」上。不是語言的不同，是使用者個性上的不同。

回到开头的话题，Ruby是一个典型的魔幻语言，而Python则是简约派的代表。两个语言的支持人群在审美观念和开发风格方面差距非常大。初学Ruby和Python的人，都会感受到一种欣喜和兴奋，但是原因却不太一样。Ruby的学习者会惊喜于很多新的表达方式，比如 :attr_accessor 之类的魔幻特性，而Python学习者则会惊喜于实现具体功能的简洁性。可以说从一开始他们追求的就是不同的东西。随着学习的深入，Python开发者当然也会发现Python中的不少深入的特性，不过却并不倾向于滥用它们。长次以往，Python人群对任何语言的魔幻面都会产生一种厌恶感。我认识的一个Django开发者，就明确表示，就算RoR比Django开发效率高一点，也绝不使用Ruby，因为Ruby这个语言充满了“不必要的小聪明”。

高手果然是高手，好露骨的講法。Python 人對於「語言的魔幻面」，或是你要稱為「奇技淫巧」有種本質上的厭惡感，很多 Ruby 人引以為傲的東西，都會被視為「惡魔」。儘管 Python 也可以玩出些好玩的把戲，但是他們的中心思想讓他們「選擇不去作」。

而 Ruby 正如上面所說得，Ruby 人會被鼓勵使用「語言的魔幻面」，並且從中獲得相當的精神上的樂趣。但是跟「華而不實」最大的不同，是在於 Ruby 是利用語言的炫技，達到超乎想像的開發效率跟可讀性。最後，偉大的傑作誕生了，Ruby on Rails 用本身的「魔幻面」，反而達成了比PHP 這種 Web 專用的簡約語言的更高的可讀性。

本質上的不同？還是人的不同？

人的 tone 不同，才是真正的問題所在。或許雙子座的我，永遠不會欣賞 Python :p

奇想

不知道為什麼，寫這篇文章的時候，總是把魔幻語言想成魔法師，簡約語言想成戰士。所以腦中一直圍繞著 Ruby 是魔法技能點數 10 的魔法師，前面還有一個血防加到滿的戰士在前面罩著（Java），然後組隊一起打怪。

恭喜 Python 成為 programming language of 2007

TIOBE 原文，翻譯文在此。值得稱讚的是，Python 首度超越 Perl 。

這年頭 Scripting Language 當道，Ruby 是2006 年的年度語言，Python 成 2007年的年度語言。明年 Ruby 再把這個殊榮拿回來吧 :p

ludy 0.0.9 released

其實後來的更新幾乎都是亂寫了，這次的更新也差不了太多。大抵上就是增加個 C++ TR1 style 的 bind... 用起來的味道大概是這樣：（如果熟 C++ TR1/boost bind 的話，一眼就知道了）

assert_equal [9,8,7], ([1,2,3].map &(lambda{|lhs, rhs| lhs-rhs}.bind 10, :_1))
assert_equal [3,2,1], (lambda{|a,b,c| [a,b,c]}.bind :_3, :_2, :_1)[1,2,3]
assert_equal [1,9,3], (lambda{|a,b,c| [a,b,c]}.bind :_1, 9, :_3)[1,2,3]
assert_equal [9,2,3], (lambda{|a,b,c| [a,b,c]}.bind 9)[2,3]
assert_equal [9,4,2], (lambda{|a,b,c| [a,b,c]}.bind 9, :_3)[2,3,4]

不過我總覺得 ludy 應該可以繼續走下去才對。所以我想在下次做一次 major update, 版本號大概就是 0.1.0 吧。會做的改變大概如下：

1. 整理 project directory structure, 現在根本就是亂七八糟。我想大概會用 gem bones 去做吧。其實我是比較 prefer hoe, 但是 bones 的 rake task 有 namespace 比較漂亮... 如果 hoe 會更新到使用 namespace 的話，我再 switch 過去。現階段，我想 bones 是個不錯的選擇。

使用這種東西的好處，當然就是不用去設計 directory structure... 而且自己寫 gemspec 老實說也真的是滿麻煩的，bones 和 hoe 都有 rake task 幫我 build gem 檔，甚至還有 publish, 多方便。

2. 思索 puzzle_generator 的未來。其實他跟 ludy 一點關係都沒有，只是我為了使用 svn server 所以才把他加到 ludy 上的。到底 puzzle_generator 應該分出來，還是在 ludy 中找到一個位子？分出來的話，又該分去哪裡？

3. ruby 1.9 compatibility, 我剛剛稍微測試了一下，有幾個比較髒的東西在 ruby 1.9 是跑不起來的。這個應該要想辦法修掉，ruby 1.9 很棒的。除了效能好很多以外，多了很多我想要很久的功能，能早點轉過去就早點。可惜的是 1.9 問題還很多，而且很多 gem 沒辦法在上面跑，所以 1.8 還是必備的。現階段會讓 1.8 和 1.9 都相容，等 1.9 夠穩了，就不會考慮支援 1.8 了。

4. require path 的麻煩問題。去看看 facets, 他們對於 require path 大概也很頭痛吧。從 2.0.0 就整個把 require path 翻修過，結果還有大 bug, 害我完全沒辦法用。果然很快就推出 2.0.1 了...。還是 2.0.1 ~ 2.0.2 的階段，我忘了。反正就是很可笑的狀況，名稱衝突之類的。bug 期間我是暫時 monkey patch.

再看看 rubygems, 一開始有個 require_gem. 而我，卻也弄了個 require_ludy. 沒辦法，因為很難寫一個在任何情況下都有效的 require, 所以才搞出那種東西。但是現在我覺得，還是應該多為 user 想想，畢竟連 rubygems 都捨棄 require_gem, 我也不該繼續使用 require_ludy 才對。

無奈這真的是個很大的問題，可能勢必得做得不要那麼 general 吧？大致問題如下：
a. 使用 gem install 時可以正常 require.
b. 把東西全部 copy 到 project path 時, 讓 -I 可以 work.

其實簡單地說，就是希望不要 gem install 也可以輕鬆放到專案中使用。不過也許得放棄這個要求吧？因為實際在寫時，就會發現很多問題都跟這有關。如果能「假設」gem 一定有安裝起來的話，很多考量就可以不用做了。

事實上，不需要安裝 gem 也能 work, 對於開發也很有用。因為我可以改改程式就測試最新的結果，而不必自己裝一份。所以，還是再看看吧。還是希望能有好方法。

5. unit testing. 既然是 unit testing, 當然就要有能夠分開 test 的動作。我希望可以 ruby test/tc_bind.rb, 也可以 rake test 測試所有的 unit test. 之前因為沒在用 rake, 我自己寫了個 ts_ludy.rb, 大概就是做這件事。所以 ruby test/ts_ludy.rb 就可以跑所有的測試。

而我發現，如果照 unit test 原先的設計，把所有東西都 require 起來再跑，執行效能會變得很爛很爛。原因我不是很清楚... 所以後來我改變作法，變成一個個去跑每個 unit test, 然後把輸出結果蒐集起來，再報告出去。這樣的好處就是跑得速度真的快太多了，好幾倍的差別。缺點當然就是，這樣做挺詭異的...

所以關於 testing 的部份，也還需要再整理一下。大致就是希望能單獨跑也能一起跑。另一方面，我要求 testing 所使用的 lib 應該要是相對路徑下的，而不是 gem 上的。理由同 require path 上面的描述。

其實對於 require path 和 unit testing 的部份，我花了不少功夫，不過成果其實還滿差的。當時看是沒什麼感覺，現在看覺得實在很醜。

6. 去掉 shebang, 那很蠢。（那時候對 shell 太不熟了）

7. ludy_ext.rb
這東西，本來是想放各個沒在 Ludy module 下的東西，不過這樣成長太噁心了。應該學學 facets, 一個 method 一個檔才對。所以這部份也要切開，整理一下。

8. 整合之前為了 shooting-cubes 做的一些 rake task, 還有 erb meta-programming 的一些相關 method. 這個，和 puzzle_generator 一樣好像有點尷尬，不太屬於 ludy 的範疇。
不過在整個 ludy 東西還很少的狀況下，我希望盡量整合一些 lib.

9. 儘快整合 multi, 那個 multi-method 的 lib. 我在想，我可能自己實作一份，就不要直接把他吃進來。multi 是 MIT license, 我想我直接吃進來應該沒問題，只是整個感覺就很怪，而且他的程式有些部份我不太滿意，所以也許我自己做一份還是比較好，這樣也不用想怎麼合併。

如果確實做出來了，那大概就只留一份 NOTICE 或感謝之類的，就不保留原本的 require path 了。不然，我真的覺得那樣很醜，像是分裂的個體似的。

10. 修改一些文字說明，包含 README, CHANGES, description 之類的。現在的格式已經有點接近亂寫了。另一方面，也希望稍微修改一下 rubyforge 上的 release 結構。

11. 撰寫 rdoc, 完全沒 doc 其實也有點奇怪...

*

所有的 source code 都採用 Apache License 2.0, 希望下次的更新可以涵蓋以上幾點。

btw, bind 實作只有 13 行（含註解）

安裝：
gem install ludy

取得所有程式：
svn checkout http://ludy.rubyforge.org/svn/
or
svk mirror http://ludy.rubyforge.org/svn/ //mirror/ludy

Rails Is A Ghetto

先說好，Mongrel 是一個 Team ，所以 Zed Shaw 的離開不代表 Mongrel 的停擺，不過該開始尋求更好的 Application Server 摟。

Zed Shaw （Mongrel 的作者）在去年的 12/15號宣告他封鍵盤，不再 Coding 了。然後又在去年的最後一天發表了一篇攻擊性言論相當強的文章，Rails is a Ghetto。裡面提到許多 Rails 社群的不良行為，並且用相當攻擊性的語氣來批評這些行為。這對 Rails 社群的確有很大的傷害，不過有多大那很難說。

Zed Shaw 宣佈他不是 Ruby Guy，並且想轉向 Python，Factor，Lua 等語言看看。

"This is that rant. It is part of my grand exit strategy from the Ruby and Rails community. I don't want to be a 'Ruby guy' anymore, and will probably start getting into more Python, Factor, and Lua in the coming months. I've got about three or four more projects in the works that will use all of those and not much Ruby planned. This rant is full of stories about companies and people who've either pissed in my cheerios somehow or screwed over friends. I can back all of them up from emails, IRC chat logs, or with witnesses. Nothing in here is a lie unless it's really obviously a lie through exaggeration, and there's a lot of my opinion as well."

大家想看去看原文吧 :) 。你不用去期待裡面有啥技術，Performance ，語言架構的比較。裡面只罵人跟公司（ThoughtWork）。我很不喜歡這篇文章，因為語氣不只是差，還有許多人身攻擊

Dave Thomas Ain’t No Sammy Sosa (He’s Just Fat)

之類的話語。更讓我覺得 Zed Shaw 的 EQ 似乎不是很好。

不過，Zed Shaw 對於 Ruby on Rails 的社群貢獻是毋庸置疑的，至少讓我對你唱一句

Goodbye My Love，我的愛人再見

祝你在新的社群有好的發展，還有 Ruby 社群沒有加蓋，你在外面受到不好的遭遇可以游回來呀。

用 Blogger 寫技術類型文章的優勢

我當初選用 Blogger 寫 LightyROR 這個技術類型的 Blog ，就是看在

1. 技術人員都用 Google
2. Google 「應該」會對 Blogger 作技術文章搜尋結果作最佳化

請注意，是應該，而不是肯定。我「猜」 Google 當然會對自家產品稍微愛護一下，而看我 Blog 的人應該都是用 Google ，所以我選擇 Blogger 。

結果今天發生了一件事情，我四點寫了一篇 CentOS 5.1 + RMagick works，結果一個小時後我 Google 搜尋「CentOS RMagick」文章的時候，發現已經進入 Google Search資料庫，並且排名第二名

雖然不能說 Google 有對 Blogger 的文章有特別愛護，但是寫完文章後，一個小時進入搜尋搜尋資料庫，也算是另類的優勢。

CentOS 5.1 + RMagick works

昨天，我要在 CentOS 上面灌 RMagick。我 google 了一下，發現有位卧得罚先生寫關於 CentOS 下面安裝 RMagick 的辛酸跟血淚，洋洋灑灑六到七頁，最後成功了還不忘加句「CentOS Sucks」。我發現到 XDite 也又 twitter 「CENTOS 裝 rmagick ...困難重重....」，這讓我非常的好奇，一心想看看在 Fedora 跟 Ubuntu 安裝都是瞬殺的 RMagick ，到底在 CentOS 上面出了啥問題。結果發現這條路好漫長，大概搞了半天以上吧......結論其實很簡單

CentOS 預設 FreeType Lib 是爛掉的，重新 compile 即可。

一開始我想看看RubyWorks ，因為他們有懶人包一次包好所有 Ruby on Rails 的東西。我發現到他們網站上面 Optional Package 宣稱他們有包好 RMagick
rubygem-rmagick (librmagick-ruby in Debian/Ubuntu repository.) – interface between the Ruby programming language and the ImageMagick® and GraphicsMagick image processing libraries.
但是我在 RubyWorks 的 yum 中找不到，所以就當沒有這東西存在。然後，使用 yum 安裝 ImageMagick ，再用 gem 安裝 RMagick ，發現 CentOS ImageMagick 的版本太舊，RMagick 2.0 不支援。

下載最新的 IMageMagick ，然後用 gem 安裝 RMagick 看似沒問題，但是當我想測試一下，按下
ruby -rrubygems -e "require 'RMagick'; puts Magick::Long_version;"
就發現有許多 Error 等著我。當我把這些 Error 放到網路上，結果發現沒有幾個回答。大部分都是叫我回去看 RMagick 的 Install Note。

當然啦，別人叫我們看Install Note，就是代表「你並不了解這個東西」，所以我乖乖的看了一下我發現 RMagick 需要

1. FreeType
2. Ghostscript fonts
3. JPEG
4. PNG
5. WMF

這幾個 Image Lib ，當我確認過 CentOS 都有安裝這些 Lib 之後，很可惜的，Error 一再的出現，就這樣陷入了一再重複的地獄。最後我從這個網頁發現到

CentOS 預設 FreeType Lib 是爛掉的。

這就是最後的解答。So，請下載 FreeType 的 Lib ，重新 compile ，然後 RMagick 就會成功。

以下是 Step by Step 安裝

我在一台乾淨的 CentOS 上面安裝成功過。下面安裝版本，CentOS 5.1 + gcc 4.1.2 + ImageMagick 6.3.7 + FreeType 2.3.5 + rmagick 2.0 或是 rmagick 1.15.12。

1. 安裝 GCC / G++
yum install gcc-c++ compat-gcc-32 compat-gcc-32-c++

2. Install 相關 lib
yum install glib glib2 zlib-devel libpng libjpeg libtiff ghostscript

3. 下載 FreeType 2.3.5 ，make

4. 下載 ImageMagick，make
你可以用 convert --version 確認是否安裝成功

5. gem i rmagick
你可以用
ruby -rrubygems -e "require 'RMagick'; puts Magick::Long_version;"
確認是否安裝成功。