Apache HTTP Server 2.4 + PHP-FPM + mod_proxy_fcgi

You may use mod_fastcgi to integrate with your php-fpm.

Unfortunately, it seems not support Apache 2.4 at the moment.
Alternatively, you can use ByteInternet/libapache-mod-fastcgi

Or use mod_proxy_fcgi instead.

Configuration for DocumentRoot

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/path/to/your/documentroot/$1

For virtual hosts, please add ProxyPassMatch for each virtualhost

<VirtualHost *:80>
    DocumentRoot /path/to/your/documentroot/wordpress
    <LocationMatch ^(.*\.php)$>
        ProxyPass fcgi://127.0.0.1:9000/path/to/your/documentroot/wordpress
    </LocationMatch>
    ServerName somewhere.com
</VirtualHost>

Reference:
http://wiki.apache.org/httpd/PHP-FPM

Media Temple 小感想

原本的網站(不是這個 blog)放在國內某家知名的主機商,因為每個月都在付超流費,再加上曾經傳出客戶資料外流的問題,所以我們就決定把現在的網站搬到 Media Temple。流量跟 storage 一次到 1000GB 跟 100GB,一年刷下來 200 美金,乾脆省事。

從 9 月底租到現在,大概也差不多三個月了,覺得他還算穩定,還可以讓我用 SSH 連進去,再用 rsync 去 deploy 一些東西(也方便用 rsnapshot 去備份)。再加上可以依照 domain 開不同的帳號,讓我們把 admin 帳號跟 domain 帳號隔開,對於現在的使用上其實也很方便。

不過最近爆出來的一些 security issue 讓人覺得很無言,像是官方 blog 的這兩個 issue
#1047 Cluster.05 Storage Segment 1
#1026 (gs) Security Advisory

Twitter 也有爆出來
http://twitter.com/macgillavry/status/6497221013
http://twitter.com/mdravnieks/status/6491481100

然後因為放在美國的關係,過去大概也要 150ms,對於 response time 來說是蠻高的,就現在來說,我也只能對 YSlow 有的東西修一修,支援一下 deflate,把 expire 設定起來,然後 CMS 能做 cache 的先上一下,要 compress 的 js 跟 css 丟給 Closure 看看會不會好一點。

不過最近 web 偶爾就給我連不上,不知道是怎麼樣,也許弄個 mtr 跟 httping 來監控看看吧。

現在我們把影音的流量也分一部分到 vimeo 上,也許一年之後再評估看看,到底哪邊比較適合我們吧。

Discogs: 一個社群性的唱片資料庫

不知道你有沒有這種經驗,買了一張 CD 回家,興高采烈的想要轉成 MP3 或是 FLAC,結果 freedb 壓根子找不到,最後還得到官方網站去把曲目資訊一個一個的重新 key 進來。其實這也不能責怪任何人,畢竟把唱片的曲目資訊整理進 freedb 本來就不是什麼理所當然的事情,這大概只得靠社群性中唱片擁有者的熱情才能做到。

我曾經跟幾個朋友說,為什麼 CD 市場中比較少像是 aNobii 般的社群網站呢?你可以給予評分、可以交換、也可以在資料庫中新增最新發行的 CD 資訊,在這個社群中每個人都可以是審核者(Moderator),能審核一張專輯資訊的正確性,也同時是貢獻者(Contributor),提供專輯的所有資訊,可能包括類別、製作人、發行日期、甚至每首歌曲的詞曲創作等。而這些資訊可以被應用在各種地方,像是數位音樂的標籤(Tag)上,以及專輯資料的數位化上。

Discogs 就是這樣的一個網站。最早留意到這個網站是在 Mp3tag 的使用上,他能夠從 Amazon.com 以及 Discogs 取得曲目資訊,並幫你 Tag 到音樂檔中。

以前來說,我總覺得 freedb 就已經夠好用了,但總有一些意外,例如 Sarah McLachlan 最新的專輯 Closer: The Best of Sarah McLachlan 似乎就會因為某些曲目的刪減(因為發行的地域性,日本專輯格外容易出現這種事情),造成 freedb 找不到專輯資訊。這點 Discogs 就顯得人性化許多,你可以搜尋一張專輯,然後視情況改變其對應關係。像是

foo_discogs screenshot

就可以把最後三個 DVD 的資訊給移除掉,讓 Discogs 把前 13 首歌的資訊寫到對應的檔案上。

我覺得 Discogs 比較人性化的地方上是,他並不是用曲目上的「時間」資訊來判斷專輯的,而是靠著使用者輸入說「這張專輯是哪個歌手」、「專輯名稱大概是什麼」,再讓使用者從資料庫裡的資料來標記音樂檔。因此,使用者也更有彈性,能夠選擇適合他語系的資訊、適合手邊專輯版本的資訊進行標記。對開發者而言也顯得更相當友善的是,他也把 API 開發出來供大家使用,目前 Perl 也有 WWW:Discogs 可以使用。

不過開放的平台最大的問題也莫過於「管理」以及「社群貢獻」上,目前 Discogs 的中文資料應該非常少吧,前幾天我也才剛把陳綺貞的「太陽」送上去,但目前還沒有人 Vote(還是非常戒慎恐懼……)。所以說,如果你買了一張正版專輯,也許你也可以考慮把專輯資訊送上去,讓更多的人能夠使用你所貢獻的資料,也讓這些資料在十年、二十年之後還能繼續留存下來。也許就像 OpenStreetMap 的概念相似吧,開放而美好。

忘了說,目前支援 Discogs 的軟體有

個人私心推薦 foobar2000 的 foo_discogs,也許下次當你買了一張專輯,正煩惱找不到專輯資訊時,試試 Discogs 吧,也許會有意想不到的收穫!

YousableTubeFix 給你高畫質的 youtube

YousableTubeFix 是一個 Greasemonkey 的 script,他做的事情還蠻多的,除了能幫你下載 youtube 的影片之外,最好用的莫過於以下拉式選單讓你選擇 standard Low Quality FLV, MP4, High Quality FLV or High Quality MP4 這幾種格式,讓這個 HD 的世代能有比較好的影音體驗。

雖然你還是可以用老方法,手動去改 fmt 成 18 或者 22 看看,不過我還是喜歡用這個 script。而且你可以比較一下畫質上的差異,第一張是一般品質,第二張則是 High Quality MP4,我想應該高下立判吧!

KOH+ 最愛,一般品質

KOH+ 最愛,fmt=22

不過 fmt=22 的狀況下,你的電腦也需要強力一點的 CPU 才放得動,以我現在這台 Pentium-M 1.3G + 512MB 的機器,實在很沒辦法阿….

Jollen 寫的「Linux 驅動程式的中斷處理」系列文章

正在等開會,原本應該 18:30 就要結束的事情,我現在還沒被抓進去 XD,就趁這個時候寫一點東西吧。

因為工作的關係,我必須開始看關於 Linux Kernel 關於網路的部份。我的主管介紹我兩本書可以參考,一本是 O’ReillyUnderstanding Linux Network Internals,另一本則是 PearsonLinux Networking Architecture ,我大概花了三四天的時間讀了 Understanding Linux Network Internals 的前九章,他的文字淺顯易懂(讓我不太用查字典),觀念解釋的也不錯,唯一的缺點大概就是太貴了 XD

不過最近有新的工作要作,就沒時間好好讀書了。不過,我最近拜讀了 Jollen 所寫的「Linux 驅動程式的中斷處理」相關文章,這個系列真的寫的很不錯。先前讀到 tasklet 的時候,也一直在找關於這方面的中譯文章,但這方面的資源比我想像中要少很多。現在有這些文章的出現,我想那對於我們這些初學 Linux Kernel 的人們,一定有很大的助益吧 🙂

咦,為什麼還沒換我去開會,我想回家吃晚餐啊~~

Updated: 果然還是自己敲門進去比較快 XD

檢查 OPML 的 feed 是否有效

過去我從 Bloglines 跳槽到 Google Reader ,原因就不講了,在使用 Google Reader 幾年下來,我覺得 Google Reader 的優點莫過於優良的搜尋、能以 Star 保存重要的 item、讀過的 item 才會 Mark(那個 Friends’ shared items 實在很雞肋);而缺點則常是介面上的,諸如 feed 的標題不會更新、沒有手動排序、List View 不好用、不能針對單一的 feed 設定等。反過來說,Bloglines 就沒有 Star,對讀過的 item 的 mark 上做的也沒有 Google Reader 好。

除了上述那些缺點之外,Google Reader 還有一個不太好的地方,他不會提醒 feed 已經失效了,這點 bloglines 就會用 [!] 來告訴你。那我近 300 個 feed 到底有哪些是失效的?Google Reader 不會和你說,就只能自己手動檢查了。我寫了一個小程式來判斷 Google Reader 輸出的 OPML 有哪些 feed 還活著。 Continue reading “檢查 OPML 的 feed 是否有效”

從 Nokia 6120 classic 談錯誤訊息

Nokia 6610 & Nokia 6120c

一切都從換了 Nokia 6120 classic 開始。

很早開始我就是 Nokia 的忠實愛用者,而這段時間的手機操作歷程以來,我只有一隻手機是 Motorola,其餘全都是 Nokia,換機的理由很簡單:「我不小心壓壞螢幕了」,這也不是廠商的問題,畢竟我是如此暴力使用手機的人,手機在汰換前總得承受個百來次的墜機、外加無數次背包雜物的擠壓,他就只得赤裸裸地以塑膠外殼承擔這一切悲慘,直等到心力交瘁(電池充不飽)以及顏面崩壞(螢幕爆裂)才能夠電磁波戰場前線中退了下來。趁著結訓假,我去中華電信續約,也從原本的 2G 門號升級成 3G,手機的選擇的確是個問題,但最終我還是克服心中敗家慾望的惡魔,那對於 6500 Slide 質感的嚮往,也順道忘卻當年在 Symbain S60 上開發遊戲悲痛的經歷,我還是選擇那經濟實惠的 Nokia 6120 Classic。

理論上,新手機總是特別完美的,外加 Nokia 還提供極度友善的 Nokia PC Suite 這套工具,他可以將我那歷經滄桑 Nokia 6610 內所有通訊錄、簡訊,一切私密而珍貴的條目無一不漏的轉換至新的手機上,那真是貼心至極啊。我想我是做了正確的選擇,正當我這樣想時,我才發現那所有匯入 SMS 訊息聯絡人寫的不是個國字,也不是個英文字,全部都是 +886 開頭的字串,我只得傻眼這 2007 年出廠的手機也會忘記查詢通訊錄……。

fine!也總會有人注意到這種問題,也該會有新的韌體出現來解決這種鳥事吧!Nokia 還是不會辜負大家的期待,他還有一套叫做 Nokia Software Updater 的好東西,只是他果不其然的又出包了……。

Nokia Software Updater error

啥?Connected Phone was not recognized?自家的軟體不認識自家的手機?這真是見鬼了!我把英文版的軟體換成中文版,檢查過所有的連接線、驅動程式,翻了各大討論區還有一些有的沒有的,直到我看到 Nokia Europe – News – Device software update 這個 link 我才明白。

Nokia 6120 Classic software removed – 8 January 2008

Due to a number of problems with updating the Nokia 6120 Classic, we have temporarily removed Nokia 6120 Classic support from the Nokia Software Updater service. Other Nokia products are not affected. We apologize for any inconvenience caused, and will endeavour to release the software again as soon as possible.

原來是因為種種更新的因素,所以暫時把 6120 classic 的更新拿掉,%@#%@#^@^@^。可是,你知道 Nokia Software Updater 顯示的訊息又是什麼呢?在我的例子上,我就花上更多的力氣在找出問題點上,某些程度而言,這也造成我對於 Nokia 品牌形象的一種幻滅。

回到主題上,不管是 Nokia Software Updater 的設計缺陷也好,或是維護伺服器更新資訊的工程師腦殘也好,就這個例子而言,對一個「正確使用」的使用者來說,他所關心的事物勢必是他在操作這些軟體時,他所獲得的資訊是否能夠「確實指出問題點」,讓使用者能夠適切的解決問題。回到設計的角度來看,某些錯誤訊息的產生,是否該由服務者端,適情況而有彈性的產生呢?換句話說,對於 client side 而言,他不應該只是從 server 端得到一個「well-known」的 error code,並在「本地端」從這個 error code 產生一個 error message。在這個例子上,反而應該是由 server 端明確的告訴 client 端

因為種種因素,所以我們把這個更新先拿掉,你可以參考 blah blah……

那麼,還有什麼錯誤訊息是我覺得有待改進的呢?我想比較多的狀況是源自使用者關閉 cookie 的使用上面,自從使用 FirefoxPermit Cookies 這個 addon 之後,有許多需要登入的頁面就變得不同了,常常打了密碼之後就沒啥反應,沒有錯誤也沒有登入,一切就這樣悄然無息。你可能會爭議的一點,關閉 Cookie 的使用是「合理」的嗎?我想這的確是,基於許多安全的考量,我們並沒有義務要開啟 JavaScript 與 Cookie 。

flickr 就做的很漂亮,他告訴你已經正確的 login,不過忘記開 cookie 啦,ooops!

flickr no cookie

但也有一些有趣的狀況發生,這發生在台灣花旗銀行上面。因為花旗卡看電影很便宜(心),所以我幾乎每個月都會搜尋一次「郵局帳號繳納花旗卡費」的方法,就如這個 link 所述,但只要我一沒開啟 cookie,卻又被告知我必須打開 cookie 的使用權。這著實令我訝異,為什麼「常見問題與解答」要使用 cookie 呢?

我想這篇文章不是爭論些什麼,而是提醒自己許多東西的設計上必須多為使用者著想一點,使用者可能會以怎麼樣的環境使用你的產品,會不會完全跳脫設計者的思維呢?當自己是 QA 時應該要怎麼去思考問題,以及身為 RD 時要怎麼避免問題的產生,並在設計的當中提供適合的錯誤資訊。有時候多做了一點功夫,受惠的不是別人,是那個總在 bug 苦海中浮沈的自己。

來試用 Google Adsense

最近逛的幾個 blog 常常會出現「世界展望會」的公益廣告,就很多層面而言,我非常認同世界展望會的事工。而這些廣告大部分是由部落客廣告聯播所提供。我申請了帳號,但是卻覺得這樣的單位有些不可靠。那又為什麼不用大家常用的 Google Adsense 呢?就如同我在現實世界的作法一樣,像是發票,我會把中獎的金額捐獻給指定的單位。

現在已經正式上線啦,我不知道結果會如何,只是我想以後我會稍微多寫一點東西吧 XD