Newest Blogs on Cellopoint

使用 Facebook 登入並取得個資

Hank Chen — Wed, 09 Nov 2011 17:58:39 +0800

facebook，簡稱 fb，一個社群網路服務網站。許多網站結合了 fb，來做行銷活動，或是快速新增會員人數。如何將自家的網站與 fb 結合，以下做個簡單的範例，讓新加入的會員，可以使用fb的登入，就可以登入自家網站，並取得會員資料。
1.API 選擇：
fb官方提供的 API，網頁部份有 javascript、php，手機部份則有 iOS、Android，但由於 fb 好吃新奇又好玩，所以，其它語言也各自開發相關的api，如 silverlight、flash、.net、java 等，而本次則是選用 javascript 做為範例。
2.事前準備：
2.1.申請 fb 帳號。
2.2.申請成為開發者人員，如何申請可參考如下網址
http://sofree.cc/fb-app-1/
3.開工
3.1.完成上述 2，進入新建立的應用程式，依序取得 App ID 與 App Secret ，如下圖紅框處，並設定相關資料，如下圖藍框處，本次的測試網站為me.cellopoint.com，故 App 網域與網站位址，分別填入 me.cellopoint.com 與http://me.cellopoint.com，設定好之後，按下儲存鈕

3.2.在 me.cellopoint.com 目錄下，新增 channel.html 與 index.html 兩個檔案，首先開啟 channel.html，裡頭只需加入一段 javascript code
<script src="//connect.facebook.net/en_US/all.js"></script>
3.3.開啟 index.html，貼上如下的 code，並做紅框處的修改，需注意的是javascript code 必須貼於 <body> 標籤內。
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:fb="http://www.facebook.com/2008/fbml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Login</title>
</head>
<body>
<div id="fb-root"></div>
<script src="//connect.facebook.net/en_US/all.js"></script>
<script>
window.fbAsyncInit = function() {
FB.init({
appId : 'xxxxxxxxxxx', // App ID，請輸入 3.1 所又得的 App ID
channelURL : '//me.cellopoint.com/channel.html', // 請輸入 3.2 所新增的 channel.html 網址
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
oauth : true, // enable OAuth 2.0
xfbml : true // parse XFBML
});
};
</script>
</body>
</html>
3.4.登入並取得會員資料
新增如下 javascript code，說明如下
a.userID：為個人在 fb 的 id 值，取得如下紅框處，如果個人網站利用fb登入，可以此判別會員。
b.如欲取得 email，則需設定如下綠框處
c.取得 name 與 email，使用 FB.api 的 me，如下藍框處
function FBLogin(){
FB.login(function(response) {
if (response.authResponse) {
alert('登入成功');
alert('UserID' + response.authResponse.userID);
FB.api('/me', function(response) {
alert('UserName' + response.name);
alert('UserEmail' + response.email);
});
} else {
alert('登入失敗');
}
}, {scope: 'email'});
}
3.5.登出：新增如下 javascript code
function FBLoginOut(){
FB.logout(function(response) {
alert('Logged out.');
});
}
4.如果要移除掉該應用程式，於個人的 fb 頁面的應用程式選項，找到該應用程式並移除掉即可。
5.以上參考出處自如下網址
http://developers.facebook.com/docs/reference/javascript/

閱讀全文

Libgtop

David Lee — Mon, 03 Oct 2011 11:10:14 +0800

如何寫一隻程式來判斷這隻程式在執行階段所佔用的 linux 系統資源，例如 CPU 和記憶體使用率呢? 可以去查看系統中的 /proc/<process id>/stat，或是藉由系統 shell 的 top 指令，但是這兩者都必須花費額外的功夫去分析檔案或介面中的資料。在這邊介紹一個 c 語言的開源函式庫: libgtop，可以幫助我們獲取系統或特定線程所佔用的資源量。

libgtop 是 GNOME 計畫中的一個函式庫，用來實現 GNOME 桌面環境中的”top”功能。它依賴於另一個GNOME 的函式庫 glib。目前最新的版本是 2.28，在安裝前必須先安裝 glib 2.6.0 以上版本以及 intltool 0.35.0 以上版本。

一般來說，CPU 的使用率，是根據 CPU 花費在各種不同模式的時間所計算的。這些時間通常可分為user mode, nice mode, system(kernel) mode 和 idle mode，而使用 libgtop 的 API 可以獲取系統 boot 到目前為止，各種 mode 所佔用的時間(clock click 次數)。舉例而言，可以利用下面的程式碼來計算出系統 CPU 的使用率:

#include <glibtop>
#include <glibtop/cpu.h>

double cpu_rate;
int dt, du, dn, ds;
glibtop_cpu cpu_begin,cpu_end;
glibtop_get_cpu(&cpu_begin);
sleep(1);
glibtop_get_cpu(&cpu_end);
dt = cpu_end.total - cpu.begin.total;
du = cpu_end.user - cpu.begin.user;
dn = cpu_end.nice - cpu.begin.nice;
ds = cpu_end.sys - cpu.begin.sys;
cpu_rate = 100.0 * (du+dn+ds) / dt

注意 CPU 使用率的計算必須根據兩個時間點的 click 次數的差，所以必須截取兩次這個資訊後再相減。而memory 的觀測就比較單純，可以一次獲得。例如:

#include <glibtop>
#include <glibtop/mem.h>

double mem_rate;
glibtop_mem memory;
glibtop_get_mem(&memory);
mem_rate = 100.0 * memory.used / memory.total;

libgtop 可以觀測的資源種類相當多，除了上例中介紹的系統 CPU 和記憶體以外，還包括特定線程的 CPU 和記憶體、swap、檔案系統、網路介面等等。詳細的 API 及資料結構可以參考 GNOME 的官方網站： http://developer.gnome.org/libgtop/

閱讀全文

Google File System 介紹

David Lee — Tue, 02 Aug 2011 10:28:44 +0800

Google 之所以能獨霸搜尋引擎市場，一方面是依靠 PageRank 技術所提供的優良搜尋排序，另一方面則仰賴其文件儲存系統的優良效率。Google 設計了一套獨特的分散式檔案系統以滿足其龐大的儲存需求，也就是所謂的 Google File System (簡稱 GFS)。Google 並沒有將 GFS 當做開源軟體釋出，不過還是公布了一些技術細節，包含一篇官方論文。

與傳統的分散式檔案系統相比，GFS 有兩個主要的不同點。首先，設備的失效被視為正常的現象而非意外。所謂的失效包括了應用程式的錯誤、作業系統的錯誤、人為操作的錯誤、乃至於硬體或網路的問題。既然連昂貴的硬碟設備也不可能百分之百排除發生錯誤的可能性，Google乾脆使用多個廉價的磁碟機來組成他們的儲存設備。而為了對抗設備的失效，GFS 包含了監視、錯誤偵測、容錯以及自動修復的機制。

其次，資料大多只會被追加到文件的末端，鮮少會修改或刪除原本存在的檔案。已寫入的資料通常只需要可讀 (readable) 不需要可寫 (writable)，而且通常是按照順序且大規模的讀取，一次操作便可能讀取數百 KB甚至 MB 以上的資料。要特別注意到的是，GFS 預期所保存的檔案通常都是數百 MB 甚至 GB 以上的文件，小型的文件會被支持但不會被優化。

GFS 處理客戶端所下要求的方式是採類似 supernode (Master) 與分散式結點 (Chunkserver) 的架構。真正的數據資料儲存在 Chunkserver上，並且定期將其狀態報告給 Master。當客戶端需要讀取某個檔案時，要先向 Master 發出要求，Master 會考慮 Chunkserver 是否為閒置狀態，若為閒置則將 Chunkserver 的位置回報給 client，於是 client 就可以對 Chunkserver 中的檔案進行操作。

GFS 支持了必需提供超大文件量與超大流量的 Google 搜尋引擎服務，同時建構於 GFS 之上的 BigTable 資料庫技術也是 Gmail、Google Maps、Youtube 乃至於其他許多 Google 應用軟體或雲端服務的基礎，可以說是雲端時代的殺手級技術。

礙於篇幅，更多的 GFS 細節可以參考: http://labs.google.com/papers/gfs.html

閱讀全文

PHP 函數實作 Semaphore

Ruby Lin — Fri, 15 Jul 2011 19:07:43 +0800

Semaphore 是一個可變或抽象的資料型態，在並行計算環境中，若有多個行程對一個共用資源，將可提供簡單有用的控制存取。

可以把 semaphore 想成是一個記錄，有多少單位的特殊資源是可使用的，加上操作安全地(即沒有競爭危害)調整那個紀錄，且那是有需要等待的直到一個單位的資源變得可使用。

Semaphore是有用的工具來預防競爭危害和死鎖; 然而，他們的用途絕不是保證程式可以從這些問題中解脱。資源允許任意數量的 semaphore 叫 counting semaphores；值只有 1 或 0 的 semaphore (或 locked/unlocked、unavailable/available)稱 binary semaphores。

下面為 PHP 的 semaphore 函數
int ftok (string $pathname, string $proj) – 將可存取的路徑和方案編號轉換成 System V 可存取的 IPC key。

bool sem_acquire (resource $sem_identifier) - 向信號機要求，信號機會減少一個資源數，並進入臨界區。

resource sem_get (int $key [, int $max_acquire = 1 [, int $perm = 0666 [, int $auto_release = 1 ]]]) - 取得一個新的信號機。

bool sem_release (resource $sem_identifier) - 向信號機通知釋放一個資源數，並離開臨界區。

bool sem_remove (resource $sem_identifier) - 移除一個信號機。

resource shm_attach (int $key [, int $memsize [, int $perm ]]) - 回傳一個可以存取 system V 共享記憶體的編號。

bool shm_detach (resource $shm_identifier) - 中止對共享記憶體的連結。

mixed shm_get_var (resource $shm_identifier, int $variable_key) - 取得共享記憶體中指定的變數值。

bool shm_has_var (resource $shm_identifier, int $variable_key) - 檢查共享記憶體裡是否存在該鍵值。

bool shm_put_var (resource $shm_identifier, int $variable_key, mixed $variable) - 增加或修改共享記憶體中的變數值。

bool shm_remove_var (resource $shm_identifier, int $variable_key) - 移除指定的變數名稱。

bool shm_remove (resource $shm_identifier) – 移除共享記憶體。

閱讀全文

GNU libextractor

Shawn Lin — Mon, 04 Jul 2011 13:43:00 +0800

Introduction

GNU libextractor 是一個種用來從 file 中提取 meta data 的 library。他的設計為以輔助程式庫的方式來執行提取文件實際內容，Meta data 格式的資料有下列 (mime type, image dimensions, color depth, recording frequency)，GNU libextractor 主要是被我們用來提取 meta data 之用。目前，GNU libextractor 支持以下格式：HTML, PDF, PS, OLE2 (DOC, XLS, PPT), OpenOffice (sxw), StarOffice (sdw), DVI, MAN, FLAC, MP3 (ID3v1 and ID3v2), NSF(E) (NES music), SID (C64 music), OGG, WAV, EXIV2, JPEG, GIF, PNG, TIFF, DEB, RPM, TAR(.GZ), ZIP, ELF, S3M (Scream Tracker 3), XM (eXtended Module), IT (Impulse Tracker), FLV, REAL, RIFF (AVI), MPEG, QT and ASF. 此外，還有各種額外的 MIME 類型檢測。

GNU libextractor 是免費軟件，可以下載下來修改以及發布。
GNU libextractor 使用 plugin 來處理各種文件格式。從技術上講一個 plugin 可以支持多種文件格式，但大多數 plugin 只支持一個特定的格式。默認情況下，GNU libextractor 將使用所有在安裝目錄下發現的可用 plugin。應用程序可以要求使用特定 plugin 或只有排除某些 plugin。

Example for using dynamic library

// hello.c
#include <extractor.h>
int main()
{
struct EXTRACTOR_PluginList *el;
el = EXTRACTOR_plugin_load_defaults (EXTRACTOR_OPTION_DEFAULT_POLICY);
// ...
EXTRACTOR_plugin_remove_all (el);
return 0;
}

執行以下指令 compile
$ gcc \ -I/Library/Frameworks/Extractor.framework/Versions/Current/include \
-o hello hello.c \
-L/Library/Frameworks/Extractor.framework/Versions/Current/lib \
-lextractor

Plugin management

C Struct: EXTRACTOR_PluginList
建立一組 plugin

Function: void EXTRACTOR_plugin_remove_all (struct EXTRACTOR_PluginList *plugins)
刪除所有給定 plugin 列表

Function: struct EXTRACTOR_PluginList * EXTRACTOR_plugin_remove (struct EXTRACTOR_PluginList *plugins, const char*name)
刪除給定 plugin 列表例如 mime 中的 mpeg

Function: struct EXTRACTOR_PluginList * EXTRACTOR_plugin_add (struct EXTRACTOR_PluginList *plugins, const char* name,const char* options, enum EXTRACTOR_Options flags)
增加給定 plugin 列表

Function: struct EXTRACTOR_PluginList * EXTRACTOR_plugin_add_config (struct EXTRACTOR_PluginList *plugins, const char* config, enum EXTRACTOR_Options flags)
根據 config string load 或是 unload 或是修改已存在的列表

Function: struct EXTRACTOR_PluginList * EXTRACTOR_plugin_add_defaults (enum EXTRACTOR_Options flags)
載入所有在 plugin 資料夾下的預設 plugin 列表

Example for a minimal extract method

以下範例告訴我們如何利用 plugin 解讀出 MIME type

int
EXTRACTOR_mymime_extract
(const char *data,
size_t data_size,
EXTRACTOR_MetaDataProcessor proc,
void *proc_cls,
const char * options)
{
if (data_size < 4)
return 0;
if (0 != memcmp (data, "\177ELF", 4))
return 0;
if (0 != proc (proc_cls,
"mymime",
EXTRACTOR_METATYPE_MIMETYPE,
EXTRACTOR_METAFORMAT_UTF8,
"text/plain",
"application/x-executable",
1 + strlen("application/x-executable")))
return 1;
/* more calls to 'proc' here as needed */
return 0;
}

Internal utility functions

有些實用的內部開發 API
“convert_numeric.h” 定義了各種數字的轉換功能（特別是轉換為浮點數）。
“unzip.h” 定義了一個訪問壓縮文件的 API。
“pack.h” 可以把有 integer 的 struts 分解順便也可以把 big/little endian 轉成 host byte order。
“convert.h” 提供了一個函數進行所需之字符集轉換。
Function: char * EXTRACTOR_common_convert_to_utf8 (const char *input, size_t len, const char * charset) 可以用來方便地從任何字符集轉換為 UTF - 8 文本。

Conclusion

總之，對於訊息解析平凡的我們來說，GNU libextractor 不只幫助了我們找到檔案的正確格式，還可以撰寫各種 plugin 工具，分析各種文字格式，找到相對應的 MIME type。這對 email 這塊領域而言，可說是不可或缺的一項工具。

閱讀全文

What is memcache?

HH Tu — Thu, 23 Jun 2011 16:52:17 +0800

今天我要介紹一個對於存取資料庫相當有用的技術 - Memcache.

Memcache 是一種分散式記憶體快取系統，對於現在熱門的雲端系統也是相當有用的。它最基本的概念式用 key-based 的資料結構來存取資料到記憶體內部。原先這個概念來自於 Brad Fitzpatrick，他最早用在一家叫做 LiveJournal.com(2003) 的公司，因為效果不錯，而又加以發揚光大。現在有更多的大公司有在用這項服務：LiveJournal、Wikipedia、Flickr、Twitter、Youtube、Digg、WordPress.com…etc. 它的好處在，可以縮減大部分存取資料庫的時間轉而到存取記憶體上面，就算資料沒有在記憶體上面對於要到後方存取資料庫也是相當的容易設計。雖然它有 key-based 快取還有分散式記憶體功能，但是對於存取限制這點必須由建構者自己決定。這項技術效果最好的地方當然就是把常用的資料寫到記憶體內部，那麼下次存取的時候就近乎不用等待時間。這概念有點像是當你上網的時候，網站會將網站大部分的圖片資料先暫存到你電腦內，等你下次又再存取這個網站的時候，速度會大幅提升是一樣道理。Memcache 也是用一樣的概念，它拿你電腦的記憶體來加速存取，它可以拿整個網路的空閒記憶體來存取，讓你可以在同一個網路架構下共同存取使用到，另外一個特點就是你想要增加多少記憶體使用就可以增加多少(當然你需要充足的記憶體)，甚至它會將所有記憶體區塊視為同一個記憶體，這就結合著前面所敘述著，網路上的記憶體只要你可以用你就可以將全體合併執行。而理論上它的設計這些行為應該都在 O(1) 可以完成。

現在我來給一個簡單的範例來敘說有 Memcache 使用上的差異我們每天從一台電腦存取資料，如果我們想加入就會想要再加一台機器，但是要怎樣才會有效率?

圖片1，我們有兩台機器兩個分開的記憶體，為了確保兩台資料相同不會有不一致情形發生，所以我們會讓兩台記憶體都存取一樣的資料，結果導致只是電腦 CPU 運作很快，但是記憶體沒有有效率的使用，這種設置效率很差。

圖片2，我們有兩台機器，但是透過 Memcache 來結合兩邊的記憶體，所以我們記憶體是共存使用的，不用擔心不一致的情形，而且空間還加倍使用，整個生活變得更美好了!!

那我們到底該怎樣使用 Memcache 比較好? 以目前較有意義的使用方式是，如果你的存取資料庫充滿著”SELECT * from XXX”，表示你常常要所有的資料而且量不少，而且如果又是常常重複的資料，那你就可以使用Memcache使用的相當快樂。這邊給一個簡單的分析，你如果要用 Memcache 必須要考慮幾個要點：1. 搜尋的時間 2. 擊中率 3. 檔案存在時間，當然你需要花費額外的人力時間去寫程式來增加這段效率，不過比較起結果，這算是常態時間 (Constant time) 的考量吧?

我再給予一個簡單的流程來說明要如何建構你的系統跟 Memcache 還有資料庫運作假設你現在有很多台伺服器，現在想要連結這幾台伺服器有更有效率的應用記憶體。以下是一個簡單的流程: 你的客戶們來詢問伺服器資料，你的伺服器一開始會先去詢問 Memcache，如果資料不存在於 Memcache，這時候在去詢問 Database，等到找到資料的時候，記得要將資料再寫回去 Memcache，這就是一個簡單的標準流程。系統剛開始跑或許會有陣痛期，等只要時間久了，整體速度應該是向上提升才對。

再上面的例子其實你可以看的出來 Memcache在實做上是一個網路的 daemon 大多數人會配合著 PHP或是 C/C++來跟 Memcache 溝通我使用的 Linux 系統，如果你想要用 C/C++ 來建構，基本上你必須先安裝幾個程式：1. libevent 2.Memcache 3. libmemcache

想要了解更詳細的操作跟內容請參造 Memcache官網: http://memcached.org/

閱讀全文

甚麼是 Node.js?

Paul Chien — Fri, 17 Jun 2011 10:19:43 +0800

傳統上，JavaScript 只在網頁瀏覽器執行，但由於 CommonJS 專案，最近已經有相當多的興趣也把它拿到伺服器端。其他伺服器端 JavaScript 環境，包括 Jaxer 和 Narwhal。然而，Node.js 有點不同於這些解決方式，因為它是事件基礎 (event-based) 而不是執行序基礎 (thread based)，像 Apache 這種被用來服務 PHP 和其他 CGI 語言的網頁伺服器是執行序基礎，因為它們為每個近來的需求產生一個系統執行序。雖然這對很多應用程式是沒問題，但執行序基礎在很多諸如為了服務及時應用程式需要長久的 (long-lived) 連線，像 Friendfeed 或 Google Wave，並沒有很好地擴展。

Node.js 使用事件迴圈取代執行序，且能夠擴充到同時有上百萬的連線，它利用伺服器花最多的時間在等待讀取與寫入操作的事實，像從硬碟讀取檔案、存取額外的網頁服務或等待檔案上傳完成，因為這些作業比記憶體作業慢很多。每個讀取與寫入操作在 Node.js 是非同期，意指當讀取與寫入操作發生時，伺服器能夠繼續處理進來的需求。JavaScript 是非常適合事件基礎的程式設計，因為它有匿名函數 (anonymous functions) 和封絕 (closure)，且 JavaScript 開發者已經知道如何以這種方式編程，這種事件基礎模式讓 Node.js 很快，且讓擴充及時應用程式很容易。

http://docs.pylonsproject.org/projects/pyramid/1.0/narr/introduction.html

閱讀全文

LDAP

David Lee — Thu, 09 Jun 2011 10:14:35 +0800

試想兩個不同的問題：其一，一個上千人的龐大組織，擁有許多不同的部門與 IT 資源，要如何維護一個便於更新且組織成員們易於查詢的線上通訊錄? 其二，一個必須同時維護多個不同系統 (可能包含 linux 登入、apache、samba、mail service 等等) 的 MIS 人員，要如何維護多組不同的帳號密碼，甚至必須定期更新它們? 這兩個問題看來毫不相干，可是都可以使用同一個方案來解決：LDAP (Lightweight Directory Access Protocol)。

LDAP 是一個參考線上目錄服務 (Directory Service) 的協定，其經由 X.500 改造而來，省略了 X.500 許多繁瑣的細節，成為了一個能夠建構於 IP 網路上、彈性而方便的網路協定。對前文的問題一而言，LDAP 充滿彈性的設計讓我們能夠將組織資源整理成目錄型式的資料庫；而對於問題二而言，LDAP 提供了一個標準化的介面供不同的應用程式參考，因而很容易整合多種不同應用服務的組態配置 (configuration)。

以宏觀的角度來看，LDAP 將多筆資料以樹狀結構做儲存，稱為 DIT (Directory Information Tree)。整個 DIT 可以切割成許多子樹，每個子樹都可以儲存在不同的 LDAP 伺服器上，以達到分散式架構的目的。其中，每一筆資料都會有一個獨一無二的 Distinguished Name (DN)，就像是一般檔案系統中的「絕對路徑」，用來標記這筆資料在 DIT 中的位址。

以微觀的角度來看，LDAP 中每一筆資料都符合一種特殊的schema，並且可以轉換成 LDIF (LDAP Data Interchange Format) 格式以便閱讀 (注意實際上資料的儲存方式可能是binary 的)。在 LDIF 格式中，每一筆資料都會擁有多個不同的「屬性」，每種屬性則會擁有一到多個不同的「值」。一筆資料可能擁有哪些屬性，必須根據它所屬的物件類別 (objectClass)。例如，類別為「員工」的資料可能會有「姓名」、「所屬部門」、「郵件位址」等屬性，而類別為「部門」的資料則可能有「主管」、「所屬員工」等屬性。其中，每一筆資料都一定會有 DN 和 objectClass 這兩個屬性，至於其他「應有」和「可有」的屬性，則由其 objectClass 而定。

要在 LDAP server 上查詢資料時，可以把查詢 (query) 包裝成LDAP URL 的格式:

ldap://" [ <host> ]"/" <dn> [ "?" <attributes>[ "?" <scope> "?" <filter> ] ]
<host> ::= <hostname>[ ":" <port> ]
<attributes> ::= NULL | <attributelist>
<attributelist> ::= <attributetype>| <attributetype>[ "," <attributelist> ]
<scope> ::= "base" | "one" | "sub"

● host: server 的 IP 位址
● dn: 搜尋起點的 dn
● attributes: 希望回傳的屬性有哪些
● scope: 搜尋的範圍(單一節點、第一代的子節點、或是整個子樹)
● filter: 搜尋條件

例如: ldap://cellopoint.com/ou=rd,ou=unit,ou=company,dc=cellopoint,dc=com?mail?sub?uid=david
會回傳 cellopoint 公司中、rd 部門下、id 為 ”david” 的員工的email。

目前最常被使用的兩個 LDAP 軟體為 openldap 和 Microsoft Active Directory。前者是 open source 的軟體，對 LDAP 有興趣者不妨測試看看，也許就會發現一些原本很繁瑣的 MIS 工作頓時變得輕鬆不少喔！

閱讀全文

Web Application Frameworks

June Huang — Tue, 31 May 2011 14:32:46 +0800

由於網路以及網路服務的使用率越來越大，網站在 Web 2.0 時代不再只支持靜態內容。網站的內容已成為動態讓使用者可以操作實時的工作，例如檢查和發送郵件。我們的網絡工程因為不斷添加新功能讓它的規模變的龐大和複雜。

Web Application Frameworks 提供軟體結構的模型，幫助我們分類和管理網路應用程式不同的組件。他們還提供一些有用的 libraries，例如：訪問數據庫，呈現模板和 session 管理。

許多 Web Application Frameworks 使用 Model-View-Controller（MVC）的結構來定義網路應用程式邏輯上的組件。以下是 model，view 和 controller 的解釋：

Model
應用程式的 model 是用來處理系統的數據。換句話說，它包括數據和用來處理數據的函數。Controllers 和 views 會透過 model 獲取和更改數據。

View
View 是呈現給使用者看到的應用程式組件，換句話說，使用者界面。使用者要使用這個界面與應用程式互動。

Controller
Controller 是用來處理使用者的 request 並返回 response 給使用者。它會透過 model 獲得所需要的數據，把數據準備成一個合適的格式，插入到 view 裡和呈現 view 給使用者。

一個典型的 request 到服務器的情況如下：使用者透過界面發送一個 request 到服務器。主 controller 會處理這個 request 將它委託給適當的 controller 和把控制傳給這個 controller。被委託的 controller 會跟 model 互動來獲取或更改數據，呈現 view，並將控制還給主 controller。主 controller 會返回呈現的 view。使用者與界面互動並發送新的請求時，這循環就會重複。

References:
[1] Web application framework. (2011, May 28). In Wikipedia, The Free Encyclopedia. Retrieved 15:23, May 30, 2011, from http://en.wikipedia.org/w/index.php?title=Web_application_framework&oldid=431373642
[2] Model–view–controller. (2011, May 26). In Wikipedia, The Free Encyclopedia. Retrieved 17:12, May 30, 2011, from http://en.wikipedia.org/w/index.php?title=Model%E2%80%93view%E2%80%93controller&oldid=430946706

閱讀全文

Protocol Buffers (Google 專用的通訊協定)

Shawn Lin — Thu, 19 May 2011 10:12:35 +0800

Introduction 簡介
Protocol buffers 是一個靈活的，高效的，有自動機制(可能指編解碼)工具用於序列化結構數據。
類似 XML，但是更小、更快、更簡單。你定義你的結構化資料，然後就可以使用工具生成的特殊代碼方便的使用各種語言 (c++ python java)
從各種數據流中讀寫你的結構化資料。你甚至可在不打斷已經部署的程式的情況下重新更新你的資料結構（熱部署）。

Why not just use XML? 為什麽不使用XML?
protocol buffer 有很多 XML 不具備的優點：
1.簡單；
2.小巧：3-10倍
3.效率高：20-100倍
4.無雙重義意
5.有自動工具生成

How do they work? 如何開始運作?
你只需要安裝 google 的 protocol buffer
編輯 .proto 檔
執行 protoc –cpp_out=. 檔名

Example: 範例 1
package tutorial;
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;

enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
message AddressBook {
repeated Person person = 1;
}

Three type 三種資料型態
required：必須提供字段值，否則對應的 message 就會被認為是“未初始化的。“
optional：字段值指定與否都可以。如果沒有指定一個可選的字段值，它就會使用默認值。
repeated：字段會重複 n 次（可以為0）。重複的值的順序將被保存在緩衝區中的協議。

Required 是永久性的：在把一個字段標識為 Required 的時候，你應該特別小心。

Start working 開始

protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/addressbook.proto

這會產生以下文件
addressbook.pb.h：聲明你生成的 class 的標頭檔。
addressbook.pb.cc：你生成的 class 的實作檔。

Example: 範例 2
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);

fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

Entire message, including: 內部 API
bool IsInitialized() const;：檢查是否全部的required字段都被設置（set）了值。
string DebugString() const;：返回一個可讀的訊息表示形式，對讀取特别有用。
void CopyFrom(const Person& from);：用外部訊息的值，覆寫調用者訊息内部的值。
void Clear();：將所有項回復到空狀態（empty state）。
bool SerializeToString(string* output) const;：將消息序列化並儲存在指定的字符串中。注意裡面的內容是binary 的；我們只是使用字符串作為一個很方便的容器。
bool ParseFromString(const string& data);：從给定的 string 解析訊息。
bool SerializeToOstream(ostream* output) const;：将訊息寫入到给定的 C++ ostream 中。
bool ParseFromIstream(istream* input);：從给定的 C++ istream 解析訊息。

http://code.google.com/intl/zh-TW/apis/protocolbuffers/docs/overview.html
http://www.cppprog.com/2010/0908/207_4.html

閱讀全文