昨晚突然想到, 應該弄一下 php ctemplate 的 win32 binary,
因為 google ctemplate 原本就是 win32 ready, php 也是, 那為甚麼不順便做一下 php ctemplate php extension for win32 呢?
測試了一下, 東西已經丟上 github 了.
有需要的自己弄一份吧, binary 的話, 私下講吧.
pcre 是 unix 上被使用的很頻繁的 regex library, 原本是 exim (一套 sendmail like 的 mail) 想要做 perl compatible regex library,
最後一堆軟體都不小心有用到, php 的 preg_* 後面就是 pcre.
最近把一個工作上, 其他同事慣用的 php template library 改成 php ext,
為甚麼要這樣做呢?
因為 coder & designer 已經用習慣, 叫他們改, 大概會殺人吧.
所以只好退而求其次, 一樣用他們習慣的 rule & style 去做.
而該 template library, 其實就是一堆 preg_match & preg_replace 組成的,
php ext 也照圖說故事, 該用的地方就用一下.
我是用 c++ 來改寫的, 所以一堆原本 php 的 array, 直接用 stl 就可以很快樂,
preg_* 的 function, 也是可以直接用 pcre c function 來做,
但是, 但是.
google 約在 2006 年左右, 貢獻了一個 c++ binding 給 pcre, 所以如果願意的話, cpp binding 用起來更爽快點.
http://www.toplee.com/blog/533.html
這兩個都是大陸人, 說要寫 base on libmemcached 的 php extension 的網頁,
第一個寫一半就沒寫了,
第二個寫出來了, 不過我仔細看了一下 code, 殺雞焉用牛刀, 根本沒有用到 libmemcached 好用的地方.
所以我就自己寫了, 不過是替公司寫的, 目前也沒可能放出來吧.
除了 non blocking connection, 還有 consistent hash 的各種算法, 都已經做進去了.
set/get 也都可以吃任意的 php object type, 反正進去就幫你 serialize/unserialize 一下.
在 php 上面要產生 qrcode,
大部分的人都是用某日本人寫的 pure php 套件,
據說要 include 一堆東西, 才能使用.
其實, 我在 2007/04 就寫好了 pecl-qrencode, 他是 base on libqrencode 的 php extension,
FreeBSD 使用者可以在 ports/graphics/pecl-qrencode 下面找到,
用法也很簡單,
先產生一個 qrencode resource, 然後用 qr_save 把圖檔吐出來,
可以選擇要不要給檔名, 沒有直接吐到瀏覽器上.
$qr = qr_encode ('test for qrcode'); if (is_resource ($qr)) qr_save ($qr, '1.png');or you can output direct to stdout.$qr = qr_encode ('test for qrcode'); if (is_resource ($qr)) { header ("Content-type: image/PNG"); qr_save ($qr); }
最近幫朋友弄 vmware iso, 裡面裝 php, 跑他們的東西,
原本他們是用 apache20 + mod_php4, 我把他改成用 lighttpd + fastcgi + php4,
不過馬上就出現問題了, realpath () 會出現不一樣的結果,
他們用 realpath 去組合一些路徑, 然後這些路徑有可能是尚未存在的,
原本用 apache20 的時候, 是正常的 (當然是他們覺得正常)
而用 lighttpd 的時候, 傳回值都是 false,
我看了一下, 原來狀況就是 ZTS 造成的呀,
當 php 有 ZTS enable 的時候, 他是用 zend 裡面自己實做的 realpath (),
如果沒有 ZTS, 而系統又有 realpath(3) 的時候, 就直接用系統的 realpath(3),
那都沒有的時候呢? 直接 strcpy(3)…
那到底系統的 realpath(3) 跟 zend 自己搞得有什麼不同呢?
系統的 realpath(3) 組出字串之後, 還會叫一下 lstat(3) 去檢查該目錄或者檔案是不是真的存在,
不存在一樣 return false.
zend 的應該是根本不管, 組出來就回傳了…
我該說是誰的錯呢?
[Update] 今天又仔細看了一下, ZTS 其實最後還是叫 access() 出來檢查, 所以要符合這需求,
最簡單就是 non-ZTS + 修改 freebsd’ realpath, 把 lstat () 拿掉,
朋友信誓旦旦的說, 他們一直都這樣用, 但是從 cvs log 看來, 起碼 2003 年就已經都會檢查了呀.
之前在 Yahoo 已經幹過一次這種事情了,
現在還想幹一次, 台灣大概沒人像我這樣搞了吧.
現在的想法是, 用 c++ 寫個 daemon,
每次 tick 都從資料庫撈到要處理的資料, 然後讓 embed php 跑,
php 這邊應該會有的是, 一個 init function, 去註冊所有的 callback function,
然後 callback function 是從 c++ 去跑, 根據每次要處理資料不同而不同,
也只管 callback function return value 就好,
一切的一切, 就讓 callback function 自己處理呀!!!.
上班上的頗煩,
所以 jeff 前幾個星期給了我一個作業,
他說他每天在 flickr 上面, 翻閱所有好友的 comments 很累, 因為必須要一個一個去看,
flickr 介面只會提供, 你在別人那邊的留言, 別人在你這邊的留言,
不會提供你朋友在別人那邊的留言, 更不用說別人在你朋友那邊的留言… (有點繞舌)
所以他想要有一個介面, 想要一次撈出所有的朋友名單, 一次就把這些 comment 從最新排到最舊, 省的花很多時間去找尋.
大概中午十一點多接到這個作業, 約下午六點前, 已經把 proto type 做給他了.
用 php + flickr api + mrss + curl 就完成.
不過第一版非常慢, 他是拉出好友名單之後, 一個一個去拉到 rss, 然後根據時間排序, 過濾掉重複的.
才顯示出來,
http connection 數量約是, (好友數量 * 2) + 2 + 1
然後一個一個排隊連線, 假設我有 25 個好友,
我的連線數量就是 25 * 2 + 2 + 1, 1 是原本的 flickr api rest, + 2 是我也要拉到我自己的.
這樣會有 53 個 connections, 每個只花一秒鐘的話, 從 request 這頁開始, 我要等 53秒以上, 頁面才會出現, 因為還要加上排序等處理.
因此第二個版本, 使用了 curl 特殊搞法, multi interface, 他可以一瞬間, 就把要開的 connections 一次開滿, 一次拉回來.
這個改法, 我自己約 25 個好友的狀況下, 從 53 秒以上, 拉低到 4 ~ 5 秒就出現結果.
但是還是有瑕疵, 因為每次, 都要真實的開那麼多 connections 出去, 可能一拉就是 500k, 但是經過過濾之後,
只有吐給使用者 30k 的資料而已.
怎麼辦呢? cache 吧. php 可以直接使用 apc, 將每次的 rss result 存個幾分鐘,
當使用者短時間內重複拉取同樣的 rss 時, 可以直接從 cache 中拉出, 不必浪費資源出去抓.
這次目前 php 版本的狀況, 也順便感謝某同事的支持, 弄了個漂亮簡單的頁面, 讓東西瞬間看起來有質感多了.
該版本的 url 是 http://www.alive.tw
最近…
前老闆那個廢材, 逃走了…
所以我得接手他留下來得爛攤子, 一個內部所有人都不想碰的東西,
看了架構之後, 發現前老闆真的是個爛貨, 他接手的時候, 就知道自己要走了
一堆東西都隨便搞, 接手的大概只有死…
也因此, 我便開始研究了 php embed, 想要用 c++ 整個把他的架構翻掉,
而一些美國或者印度 team 用 pure php 寫的東西, 可以直接用 php embed 來處理掉.
目前已經有個 php embed 的成果,
y 社有個 replication 機制, 可以寫 plugin 去做資料的處理,
比較大的問題是, 一定得用 c++ 寫,
現在一堆新人, 都只會 php/perl, 要他們用 c++ 根本是刁難他們,
所以我搞了這個 plugin in php 的搞法, 效能看起來也還不錯.
這算是 php embedding & extending 同時搞在一起的玩法, 不錯.
荒廢了好些時候的 cTemplate php extension modify for php5, 這幾天應該會開始拿出來改.
原本就已經改了一下, 但是沒有 work, 就扔在那邊不理他…
開始重看, 大概又得重頭學一下…
昨晚把 apache20 改用 lighttpd,
wp 還是有幾個地方要改一下, 有參考了 dk 的 設定
看起來直接用 404 handler 在我的狀況是不太行的.
有空來學學 lighttpd module 怎樣寫好了.
不過我還是覺得 apache module 比較強大…