WordPress 用到今年，也第五年了。發現越來越不敷我的需求。
決定轉戰 Octopress。
原本是打算 host 在 Github 上，這樣比較炫（？）
後來考慮到要支援舊 blog 上的文章。所以最後還是放在 Heroku 上，用 rack-rewrite 對所有舊文章轉址。
舊文章會通通放在 http://wp.xdite.net （也就是這裡）。舊站的文章我就不繼續再更新了。feed 應該不受影響，本來就放在 feedburner 上。
至於迴響也會轉放在 disqus 上。
這是我最近看到算厲害（轟動！？）的行銷招數了。今天回家一看。社交網路上，滿山滿谷的都貼滿「Dropbox 舉辦抽終生 50GB 空間會員的機會」。
這個「印象」完全是一個錯覺。
1. 舉辦活動的是一個「Appsumo」的軟體 (Groupon-like) 網站。（我平常還在那邊買蠻多東西的）
2. 這個活動你必須要「輸入你的 email」。並將廣告連結傳給其他人，其他人若 follow 你的 link 進來也輸入 mail 的話，你的積分就可以變高。
比的機會是這個…
其實這跟一般的網路行銷手法沒有兩樣。「灑獎品」買「email 名單」。只不過網頁包裝的真很專業就是了。
而且仔細想想，其實這還蠻划算的就是了。
首先是獎品部分：
1. 10 名 Dropbox 50 GB 會員。（一年年費是 90 USD，共十人份，成本是 990 USD/year）
2. Lifetime 都是騙人的。網際網路上沒有永遠的公司，你不知道 Appsumo 什麼時候會倒，不知道 Dropbox 什麼時候會倒。假設樂觀估五年就好了。
總成本是 990*5 = 4950 USD。
老實說用這個數字，買到那麼多 email 真划算…
前幾天，我新開了一個網站 Upgrade2Rails31。專門放置我更新 Rails 3.1 的一些實戰心得文章。
在社群交流聚會中，我常發現人們對於 Rails 3.1 的 Asset Pipeline，還有它引進的一些新穎機制不是很瞭解。
諸如：
要清楚的了解這些關係，有時候必須 K 書或實際跳下去實戰，才能體會箇中奧妙。
這些問題，我因為解釋太多遍，回答到有一點懶了。乾脆做成 FAQ…XD。
我將之整理成四篇文章解釋：
閱讀前警告：
此四篇雖然名為淺談，但其實含了大量實戰應用知識，對有些讀者來說可能一點都不淺，請小心服用，以免看到一半睡著。
這是這禮拜最難抓到的一個問題，因為無跡可尋。在升級 T 客邦的過程中，我撞到一次過，有在 redmine 上記載下來。結果同事 @vincent 還是在另外一個站台升級時又繼續撞了一次。
它的錯誤訊息只有這樣：
ArgumentError: wrong number of arguments (1 for 0)
from /Users/username/.rvm/gems/ruby-1.8.7-p352@pah-rails3/gems/builder-3.0.0/lib/builder/xmlbase.rb:135:in `to_xs'
# 略...
在啟動 Rails 時或跑 Rake 時，一 initialize 就會出現，trace code 你完全不知道到底到底誰跟 builder 撞了…
用到 xml 的嫌疑犯很多，後來一個一個移掉檢查，發現是 hpricot 惹的禍。它自己定義了 to_xs 與 builder 撞到。
從 Rails 上的這個 issue 上 也 confirm 了這個猜想，Rails core team 成員 @tenderlove 的回應是「你應該去跟 hpricot 靠北，這是 freedom patches 的代價」然後就把這張票關掉了 XD。
所以現在就剩下這張 ticket 還活在 hpricot 上。不過 hpricot 超久沒更新，我想短期改善的希望也很渺茫吧….
最近在將手頭上的通通 project 升 Rails 3.1，其實當中遇到不少問題。
不過最值得記錄的我想應該是這一件事：
這兩個問題 （同事 vincent 處理）[Asset Pipeline] javascript uglifier 與 min.js 相衝的問題，（我處理） [Asset Pipeline] 處理 Asset Cache 導致的破圖問題。其實各自都花了我們很多時間。
但是真正的問題解決者，卻都是對方。（而且都各只花了 10 分鐘…）
在公司修 bug 和做功能時，我常常做一件事：如果 A 花了預期超過的時間做某一件事，當時間到（每日 standup 例行時間或臨屆 ticket deadline），卻還搞不定時。我會決定換人做。 而這通常也包括我自己的票。
乍看你可能無法理解這個決定：要 RD 放棄自己手頭已經 90% 的票，不是很傷自尊嗎？解不完的票就扔給別人做，不會不好意思嗎？不會很容易造成同事的誤會，誰比誰強，所以誰要負責收誰捅爛的簍子？
其實這才是一個心理陷阱。
在我自己過往解票時，常常出現一種狀況，今天往往解不出來的問題，加班加到死，還是鬼打牆。明天上班換了一顆全新的大腦，卻瞬間就解出來了…
我在運作團隊時，後來也發現這樣類似的情形。票在換手給別人做之後，別人往往瞬間就找到自己很蠢的錯誤，瞬間就 get things done。而我接手別人的票之後，也是瞬間就能把問題抓出來，把事情完成。
一次兩次，以為是功力差距和幸運。後來回家整理思緒，才發現是這樣的道理：
「一個人往往在越 close 終點時，因為心性變得浮躁，很容易就會因為失去耐性，而栽跟斗在極蠢的地方。而越解不開這個問題，就會讓他往往越鑽牛角尖，進度越慢。」唯有讓有著全新視野角度的旁觀者介入，才有辦法瞬間把這些煩人的絆腳石找出掃開。
當然，換手也不是沒有成本代價。如果你想採取類似手段，
我會建議你先做三件事：
1. 所有成員在解票時務必寫下詳細的筆記，並使用 version control system
2. daily standup，每日有 checkpoint 避免成員鬼打牆
3. 與成員溝通，強調：把事情「如期」「做完」才是最重要的事，而不是"誰去達到最後的 100% "，塑造：「適時放手求助才是最重要的事」的友善氣氛。
否則隨意換手，你也可能吃大鱉 XD
好不容易改好 asset pipeline 的東西，興致勃勃到 deploy staging / production。最常發生的掃興問題是，明明圖的路徑正確，但是圖卻破光光開不出來。
可能導致的原因有幾個：
如果你是使用 nginx 的話，這兩個選項務必要打開
# Specifies the header that your server uses for sending files config.action_dispatch.x_sendfile_header = "X-Sendfile" # For nginx: config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'
如果打開之後，重新 deploy 之後還是破圖
請清掉瀏覽器 cache 重新開啟
如果清掉瀏覽器 cache 還是無法開啟？
asset pipeline 預設有 write 到 Rack:Cache 上，如果你的 project 上有上 cache backend 如 memcached ，請記得將 server 上的 cache 清掉，瀏覽器 cache 也清掉，這樣多半就可以解決了....
這次的 Asset Pipeline 提供了 javascript uglifier 這項 feature，不只是壓縮而已，它也幫忙了將變數 uglify 掉。
不過這個功能實際使用時，我們發現一個問題。uglifier 提供的壓縮變數也是使用 a,b,c,d,e,f,g 等規則。
這會造成…
將 jquery.min , jquery-ui.min 大包的 library 丟進去與其他 js 一起壓時，壓出來的 js 是異常的。( xx is undefined )
因此有一些 function 就此爛掉…
解決方式：
別把 jquery 丟進去一起壓，使用 Google 提供的 jquery 另外載入。
至於自己手寫的才使用 uglifier 壓縮打包。
一般來說，簡單的 js plugin 還蠻好掛上 Rails 3.1 的 projects。但是複雜如 TinyMCE 這種套件呢？
相信我，一定可以把你搞到快往生。
因為 TinyMCE 是採用動態載入的形式，這也使 asset pipeline 提供的 precompile + fingerprinting feature 與它格格不入。
而一般的 TinyMCE 資料夾底下通常會放置了很多 plugins 與 themes，這也使得 assets pipeline 在 load assets 時格外困難。（你總不想很蠢的直接在 production.rb 裡面一個一個指名路徑吧。）
解法是：
安裝 digestion
然後在 Gemfile 下 enable 它
gem 'digestion'
* 請注意，別把它扔進 Gemfile 裡的 assets group 裡，這會使得這個 gem 在 production 一點作用也沒有。
然後在 production.rb 裡加入這兩行。
config.assets.digest_exclusions << "tiny_mce/*"
config.assets.precompile << "tiny_mce/*"
就能解決你的問題了...
===
P.S. 若你很懶惰的話，也可以直接安裝 tinymce-rails 這個 gem（感謝 @ihower提供 ，原理類似。只不過我們的狀況有太多 customized plugin，必須用 digestion 的方法繞過。
週末更新了自己的賣書網站。
如果你對網站後面的「寫作」技術有興趣的話：
我使用了兩份教材，和參考了一些網站做的改版。
1. Copywriting For Geeks
2. Kopywriting Kourse
賣東西真不是一門簡單的學問啊…
這是週末在觀看 Peter Cooper 新上市教學：The Ruby Walkthrough 時發現的工具。
這套影片主要是在講解關於 Ruby 1.8, 1.9.x 的行為屆時會有何不同。而 Peter 在他的教學影片中使用了一套自己開發的工具，鍵入一個指令，可以直接觀看不同 Ruby 版本的差異。
我從台詞中找到了這套工具 "irb3"，Peter 目前只把它放在一個 gist 裡，而不是一套 gem XDD。運行效果就如同截圖所示。