能產生 trac wiki 語法的 WYSIWYG editor plugin
今天看到的，讚：TracWiki WYSIWYG Editor Plugin。
能夠真正產生 Trac 的 wiki 語法存在資料庫裡，故能完美地與 Trac 協同合作。不像 TinyMce Wiki Plugin 會存入 html，造成相容問題。
經測試，能夠直接從 word 把內容複製貼上，樣式會盡可能地保留[1]。
雖然不甚完美，但毋須苛求了。 ↩
練習寫 TracMacro - [[TicketStatus]]
因為我們常要寫 wiki page 以便追蹤專案的進度、列出待辦事項等等，由於在 Trac 裡寫 #1 只會顯示 ticket number，往往我們必須要手動把 ticket summary 加在後面，當 ticket 有所變動時，wiki 與 ticket 兩邊就會不同步，維護起來非常麻煩。所以剛剛練習寫了一個 WikiMacro，取名為 TicketStatus.py，列出 ticket number、summary、status 與 owner，開會時一打開，所有事情一目了然。
WikiMacro 不難寫，不過因為我不太熟 python，所以比較麻煩的地方在於怎樣抓取資料。可能是由於 dynamic language 的特性，很難直接從原始碼追蹤，了解手上可以用的參數，其型別與屬性分別可以輾轉得到哪些資料。不過這對熟悉 python programming 的人，應該不是問題。因為多半有現成的工具，如 ipython 等，幫助我們直接取得、分析、追蹤整個物件結構。
TicketStatus.py 的原始碼如下：
"""
Display status and summaries of specified ticket numbers. Useful for listing
TODOs.
Example:
{{{
[[TicketStatus(#1,#7,#31)]] [...]
RoR vs. PHP？談 web 開發技術的未來？
本文拖太久了，斷斷續續寫，寫到後來都忘記本來想寫什麼了。不過我發現，好像 thegiive 自己分多次，把很多我要寫的都寫完了。:-p
剛剛看到這篇《Twitter , Rails , Scalibility...More》，我哈哈大笑三聲。所謂的 scalability，就是「有沒有能力在短時間內應付突然爆增的流量成長」嘛！結果 thegiive 最後的結論竟然是：
那麼一時之間無法解決也是非常正常的事情。所以，他們應該也不是太懶惰，只是成功的太突然，沒辦法吃下來。…至於 Ruby 是不是真的太慢，Rails 是不是真的不夠 Scalibilty 呢？這個問題我也不知道…
既然這樣子，那我也沒辦法了，寫再多，又有何用，情人眼中出西施咩。所以剩下的我也就懶得寫了，各位看官自行斟酌吧。
這篇是為了回應 thegiive 的這篇《簡單的回應 JeffHung 的文章》，thegiive 對於我在《COSCUP2006》裡對 RoR 的一些意見，不表認同。不過在談技術之前，我想先澄清一點的是，這種很明顯地就是會沒有結論，甚至容易陷入 flame war 的問題，其實並不適合在那種場合提出 challenge，因為不會解決任何事情。用 challenge 這個字眼，其實也不太對，COSCUP 是個可以讓大家 up up 的場合，真的沒有必要白刀子進紅刀子出。事後的交流，也是可以產生火花，而且更為持久，一切由心，端看我們怎麼想，個人覺得實在是沒有必要那麼亢奮。
再好的 template engine，也解決不了套版的問題
我們先來看看套版的問題好了。也許是雙方對「套版」兩字的定義不同吧？我的意思是，在一般網站的開發過程中，程式設計師將動態網頁的功能寫好時，通常網頁的畫面是「素」的，非常陽春不經任何裝飾。接下來要做的就是，將轉交給版面設計師，也就是俗稱的美工，所設計好的華麗版面，套在這個「素」的版面上。對於程式設計師來說，這個「套版」的過程，通常是非常痛苦無聊的，但又不可能交給版面設計師處理，因為通常版面設計師，並無法處理到「碼」的層級。面對美麗的美工姊姊，小小工程師只好乖乖地與複雜的 HTML 混碼奮鬥。
更恐怖的是，通常來說，這個過程不會只做一遍，通常會形成一個循環，程式改好後套版，版面或程式稍微改寫之後，又要重新套版，循環不休。這當然是因為，在專案進行的過程當中，通常不可能很幸運地可以一條鞭式地順著瀑布溜下來。
對於套版問題，目前已經成熟的技術，是各式各樣的 template engine，如 PHP 的 Smarty。除了解決了 security-concern、separate-from-login 與 caching 等需求之外，簡單的語法，也讓套版的困難度，降低了少許。但無論如何，template 仍然是以「碼」的形式存在，要處理套版，仍然是只能讓程式設計師會版面設計，或者是讓版面設計師會寫點程式。
幸好，這個世界有在慢慢地改善，隨著 CSS/W3CStd. 的普及，以及 Ajax 的流行，套版的問題，將可以得到相當大的改進。如果網頁是功能性的，像 Gmail 那樣，比較好的解法會是使用如 ZK、GWT 這類的 Ajax [...]
