Update：這個站倒了 XD 只剩下 screenshot 可以看了...
這個實在太讚了 XD
從 Google Blogoscoped 看到「Yuil」這篇，有人用 Google App Engine，拿 Yahoo! Search BOSS 的結果，與 Cuil 的介面的 Mashup !!!
我覺得搜尋的結果比 Cuil 準多了啊 XD
Month: July 2008
SimpleCDN
SimpleCDN 是最近看到的一個 service，就實際的情況看起來，他不是真正的 CDN，不過他的價位還算 okay，而且有免費的 15 credits (也就是 USD$15) 可以玩。
SimpleCDN 主要有三種模式，第一種是 Pay Per File，也就是對檔案付一次費用就可以一直下載。第二種是第一種的加強，強調會自動處理抓取檔案並收取費用。第三種是 Reverse Proxy 模式，收費是 0.07 credits/GB。
第三種模式跟 Giga 的 WebAMP 其實很接近，不過 SimpleCDN 的好處在於依照使用的量計費，不像 WebAMP 是每天有固定的量可以讓你用。速度上，從 HiNet 過去幾乎都是透過 PAIX 轉 HE 進去，速度還不錯。
不過缺點是價錢比 WebAMP 貴，另外因為要走國際線路，連線速度會比 WebAMP 慢。(不過... 這倒未必 XD)
另外一個不會使用 SimpleCDN 的考量是 Pay Per File 的部份，我覺得這個模式天生就做不起來啊...
FreeBSD 上的 MySQL 6.0
年初的時候 MySQL 6.0 把 libevent 匯入 source tree 裡，用 libevent 處理 connection pooling (之前似乎是 poll？)。
FreeBSD 剛把 MySQL 6.0 納入 ports 裡 (databases/mysql60-server)，可以用 WITH_THREAD_POOL=yes 把這個功能打開。
理論上，使用 libevent 後在 Web 端用 persistent connect 連 MySQL 應該不會影響到效能。
附上年初時看到的資料：MySQL 6.0, Libevent。
頻寬
Perl on Google App Engine
Python 是第一個可以在 Google App Engine (GAE) 上執行的程式語言，而下一個很有可能是 Perl。
Brad Fitzpatrick 在他的 Blog 上說，他被 GAE team 允許對外公佈「我可以使用 20% 的時間開發 Perl on GAE」：Perl on App Engine。
這是 GAE 支援其他程式語言的消息中，第一個被正式公開的。在 Brad Fitzpatrick 的文章裡面有一些藍圖，關於他大概會怎麼做的想法。我們應該可以期待他認真起來的戰鬥力 :p
PS：Brad Fitzpatrick 是 LiveJournal 的創辦人、memcached 的作者、OpenID 的制定人。
WordPress 輸出 Extended RSS (Export) 時的問題
WordPress 有自己的輸出格式可以當作備份檔使用，但輸出的檔案並不是正確的 XML，要做很多處理。
- 首先他並不保證是 UTF-8 valid，所以要強制轉成 UTF-8 valid。在 PHP 裡可以用
$str = iconv('UTF-8', 'UTF-8', $str);處理。除此之外，還要把某些特殊字元處理掉：$str = preg_replace('/[\x00-\x08\x0b\x0d-\x1f]/', '', $str);。 - 使用了 <excerpt:encoded> 但卻沒有在開頭定義 xmlns:excerpt。如果需要用到 excerpt:encoded 可以硬轉成 content:excerpt 處理；如果不需要，可以直接拿掉：
$str = preg_replace('/<excerpt:encoded>.*?<\/excerpt:encoded>/', '', $str);。 - wp:meta_value 沒有 encode 過，所以像 & 這類的字元會因為沒有 encode 而造成 XML library 抱怨，如果沒有使用到這些欄位，可以照上面的方法拿掉。如果有用到的話可以拿 htmlspecialchars() 處理後加回去。
把這三件事情處理完後似乎可以解決 WordPress 輸出的 Extended RSS 不合法的問題，用 PHP DOM 也不會跳錯誤訊息了。
其中第三個很明顯是 bug，晚點確認是 WordPress 問題並生出 patch 後得去開 ticket 修正。第二個也很嚴重，但是這個問題已經有人提出來，一直沒解：「WordPress Import Fix for Post Excerpts」，得去 ticket system 上檢查是不是有被提出來討論過。
Firefox 下載時的資訊...
可能是 bug...
PHP 5.3 將會有 Lambda Function 與 Closure
剛剛從「php: rfc: closures」這篇看到 PHP 5.3 將會有 Lambda Function 與 Closure 可以用：Request for Comments: Lambda functions and closures。
寫習慣 Perl 的 sort {...} keys %hash; 這類 code 後，在 PHP 裡面一直覺得很彆腳，有 Lambda Function 與 Closure 後可以解決不少問題...
關於 MySQL 的 --with-fast-mutexes
「ports/125616: Add --with-fast-mutexes to databases/mysql51-server」這個 PR 中所提到的 --with-fast-mutex 在 ale@ commit 後，他也順便問是否有變快 (或是變慢)。我回了他一封信，MyISAM 在十個 clients 的模擬測試下有快一些，大約 6%。
不過這是 Super Smack 測試的結果，如果沒有其他比較好的工具，拿來當參考還可以，把結果當作事實就有點偏頗了。我打算複製一份 real data 到其他空機器上，再測試一次看看。
下面這是 Super Smack 測試的結果，最後面的單位是 qps，愈高愈好。
(without fast mutexes) $ repeat 10 super-smack -D/tmp \ /usr/local/share/super-smack/select-key.smack \ 10 2000 | grep ... select_index 40000 0 0 56503.40 select_index 40000 0 0 55638.24 select_index 40000 0 0 55750.29 select_index 40000 0 0 56229.37 select_index 40000 0 0 55770.81 select_index 40000 0 0 56083.44 select_index 40000 0 0 56411.05 select_index 40000 1 0 55156.36 select_index 40000 0 0 56268.21 select_index 40000 0 0 55059.18 (with fast mutexes) $ repeat 10 super-smack -D/tmp \ /usr/local/share/super-smack/select-key.smack \ 10 2000 | grep ... select_index 40000 0 0 59652.25 select_index 40000 0 0 58040.66 select_index 40000 0 0 57937.60 select_index 40000 0 0 58511.95 select_index 40000 0 0 57319.65 select_index 40000 0 0 58308.02 select_index 40000 0 0 58514.35 select_index 40000 0 0 58493.64 select_index 40000 0 0 57937.01 select_index 40000 0 0 59348.24 The first one is 55887 qps (avg), the second one is 58406.3 qps.
Google Video Search 的發展
Google 拿美國總統大選的影片，透過語音辨識轉成文字後讓大家搜尋：Google Lets You Search for Text in Some Videos。
如同 Philipp Lenssen 所說的，如果 Google 把這個技術推廣到所有的影片上，就有很多可行性可以做，像是與 Google AdSense 的配合、與 Google Search Quality 的配合。
比起直接對影像處理，對聲音處理似乎是條可以走的路... (就目前的語音辨識)