其實後來的更新幾乎都是亂寫了，這次的更新也差不了太多。大抵上就是增加個 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
標籤：
file_column
