2007年11月30日 星期五

flickr comment reader (apache module version)

從八月說要寫這篇, 現在都要十二月了, blah blah...
上一篇是用 php 來寫這個 reader,

而本篇, 我則改用 c++ 來做這件事情,

先期需求, 有 flickr api, rss reader, 拉 rss, template engine, data structure, memcache

  1. flickr api 的部份, 在 flickr 網站上, 沒有任何的推薦 library,

  2. 而 leeym 長輩很久以前, 有推薦過 flickcurl 這套, 感覺還不錯, c & libxml2 & curl 弄出來的東西,

    自己拉資料透過 curl, 並且 parse 之後, 吐你要的東西出來,

    不過缺少了某些東西, 例如 contact list 就沒有實做,

    因此我把這部份補齊之後, 送給了作者, 發現作者竟然也是 y 員工, 還是 leeym 去美國之後的同事, hello kitty media team 的,
  3. rss parser 還是用 mrss 這套,

  4. mrss 雖然可以直接給 url 拉 rss 回來 parse, 但是問題還是存在, 一次只能一個 http connection,
    當 contact list 很長的時候, 我們一樣要等 list * 2 + 2 + 1 的時間,
    所以我們只讓他 parse rss 就好, 拉我們自己去拉吧.
  5. rss 透過 curl multi 拉, 所以必須自己寫這段,

  6. template engine 還是堅持傳統, 使用 google ctemplate.

  7. data structure 特別拿出來講的原因,

  8. 是因為我從沒真的碰過 c++ vector 之類的東西, 這次仔細的用了 vector 來過一些簡單的東西, 感覺還不錯.
  9. memcache 的 client, 使用了 databases/libmemcache


東西都準備好之後, 我先做了一個 Reader.cpp 的 class, 這個就是我們的主體,
先寫好的原因, 是拿來當成 command line 用, 至少比較好 debug.

Reader.cpp 裡面就做幾件事情, set_data, prepare, execute, parse 然後就結束了.

prepare 會把 url 加進去 vector 裡面, 順便先檢查 memcache 理面有沒有資料,
有的話, 就不用透過 curl 出去撈一次,

execute 是真的透過 curl + multi 出去撈了,

parse 是將拉回來的資料, 不管是透過 curl, 還是從 memcache 裡面的,
用 mrss parse 過一次, 排序之後, 吐 vector 回去.

Reader 部份大概就這樣,

不過一整個 apache module 其實有三個 page,
index, callback, reader.

index 單純就是 redirect 到 flickr,
使用者在 flickr 登入後, 會導回我們的 callback page,
callback 會取得 token,
然後將使用者導去 reader,
reader 就取得 contact list, 拉 rss, 做 parse, 吐頁面..

應該沒有很難才是..

PS, 不過目前現在已經不是這個版本了..

2007年8月11日 星期六

flickr comment reader (php version)

上班上的頗煩,

所以 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

2007年2月13日 星期二

php extension

荒廢了好些時候的 cTemplate php extension modify for php5, 這幾天應該會開始拿出來改.

原本就已經改了一下, 但是沒有 work, 就扔在那邊不理他...

開始重看, 大概又得重頭學一下...