Some useful datasource of Facebook programming

Here are some useful datasource that I used in Facebook programming:

1. About the datatime object
   General operation of datetime - http://blog.ben.idv.tw/2008/06/google-developer-day-google-app-engine.html
2. About ASCII, Unicode, UTF-8 encode and decode
   Unicode and UTF-8 stream coverting - http://blog.wahahajk.com/2009/08/unicodedecodeerror-ascii-codec-cant.html
   Use unicode in source scripts - http://gradyli.wordpress.com/2008/12/10/python%E7%9A%84non-ascii-character-error/
   
3. About Django (template)
   Django v0.96 version - http://www.djangoproject.com/documentation/0.96/templates/

FYR

Single sign on solution in GAE and other Google services

The Google App Engine is launched for a while and many creative works have been developed. Since Google App Engine is provide by Google itself so it should be easy to process single sign on by using Google account. It's true for partial: according to the official document of GAE, developers could use User API to integrate with Google account easily.

However, if your application would like to communicate with other Google web services such as Google mail, Picasa Web, Google calendar ... etc, and tend to provide a single sign on interface to avoid too many authentication process for users then the solution of User API is totally not enough.

To achieve this goal, we need to use another Google API called "Account Authentication API". It's pretty much a Google version of Yahoo! BBAuth. The operation process to both solutions is very simular but Google's implementation provides better administrative interface.

Using the Datastore in Development Web Server of Google App Engine

一個朋友在開發 Google App Engine 的 app 時對於 Development Web Server 的 Datastore 操作有所疑惑，所以特別將 Official Website 上的說明翻譯在此，

Development web server 是以 local 檔案的方式來模擬真實狀況的 Datastore，這些 local 檔案在每次 web server 的服務期間均會保持，所以你所儲存的資料在下次 web server 啟動時依舊存在。如果 developer 想要強制清空這些已儲存的紀錄，必須於命令列下達『--clear_datastore』：

dev_appserver.py --clear_datastore myapp

在每次 developer 於命令列啟動 Development web server 時，作為 Datastore 的 local 檔案路徑會輸出於螢幕上，developer 可透過備份該檔案達到保存某特定資料儲存狀態的需求，在需要時隨時將備份的檔案覆蓋回原檔，即可回復當初的資料狀態。唯特別注意的是，執行上述的覆蓋動作之後，必須重新啟動 Development web server 才會生效。另外，developer 亦可使用『--datastore_path』選項來指定該 local 檔案的儲存路徑：

dev_appserver.py --datastore_path=/tmp/myapp_datastore myapp

當程式對 Datastore 發出 query 需求時，Development Web Server 會檢查該 query 動作是否有在應用程式的 index.yaml 設定檔案中被支援。若該 query 必須被註明在 index.yaml 檔案中而 index.yaml 此時沒有該筆設定，則 Development Web Server 會自動將該筆 query 的設定加入 index.yaml。Developer 亦可自行編輯 index.yaml 以加入那些沒有在測試中執行過的 query 條件。

index.yaml 檔案會在 Datastore 檔案建立或清空後的任何一次 query 動作發生時自動產生。而每次的 query 歷史紀錄均會記錄在一獨立檔案，developer 可以使用『--history_path』選項來更改歷史紀錄檔的儲存路徑（就跟更改 Datastore 檔案路徑類似）。

若想深入瞭解 indexes 或 index.yaml 設定檔，請參考 official document 的『Queries and Indexes』和『Configuring Indexes』部分的說明。

原文出處：http://code.google.com/appengine/docs/thedevwebserver.html

HTTP request solution in GAE

雖然 GAE 有提供 urlfetch 這個 API 達到 server side 的 HTTP request 功能，但是在仔細閱讀 GAE 的線上文件後，就不難發現這其實是個看到卻不好吃的功能，為什麼呢？以下這段但書節錄自 urlfetch API 的說明：

Since your application must respond to the user's request within several seconds, a URL fetch action to a slow remote server may cause your application to return a server error to the user. There is currently no way to specify a time limit to the URL fetch action.

從以上的敘述，不難發現 urlfetch 無法設定 timeout 值，任何耗時過長的 urlfetch 呼叫都會導致 GAE 回傳 HTTP 404 error 給使用者，又因為 Google 捨棄了很多 python runtime 功能以達到快速的 response time，包括無法在單一 request 中起始多個 thread，所以自然也沒有所謂的 callback function or method，呼叫 urlfetch 的 script 會一直處於等待回傳的狀態。

既然無法設定 timeout 且 GAE developer 又無法控制遠端服務的回傳時間，真不知 urlfetch API 有何實質用處？或許這是 Google 本身的陰謀：讓 developer 只使用 urlfetch 來取得 Google 本身的其他服務內容。畢竟，從 GAE 發出 HTTP request 給其他 Google Service 的回應時間絕對是最短的。

Well，解決辦法也不是沒有，就是將 HTTP request 從 server side 搬到 client side 去，在 web 開發漸漸朝向 AJAX 靠攏後，似乎也沒有必要在 server side 執行 HTTP request 了。下圖的紅色資料流即是 server side HTTP request 的資料流，綠色部分則是 Yu-Chao 所建議的 HTTP request 方式，亦即透過 client side javascrip 發出 HTTP request。

覺得寫 AJAX 很麻煩嗎？可是在 GAE 又無法使用 Microsoft AJAX.NET 這種傻瓜開發法（效能不佳），那 Yahoo 的 YUI library 倒不失為一好的解決方案。

Advanced GAE development Tips

在 Google 2008 programming day 的 advanced GAE developing section 中，主講人特別針對 Datastore API 的相關主題做了深入淺出的介紹，並提供了幾個十分具有參考價值的範例。第一個重點，也是此次活動不久前 Google 才為 GAE 加入了 memcache 這個機制：

results = memcache.get('cache name')
if results is None
　results = db.GqlQuery('...').fetch(10)
　memcache.add('cache name', results, 60)

講白一點，就是 cache 快取，但是 GAE 的 memcache 是架構在 Google 的整個全球分散式 web hosts 叢集上，有了 Google 強大的硬體支援做後盾，我想運算速度再怎麼強大、記憶體再怎麼多的一般伺服器也難望其項背吧！（Yu-Chao 依稀記得前陣子於工作中身陷 Microsoft ASP.NET 應用程式的效能問題，因為該應用系統是架構於一 Open Source 的 package，在該系統使用者逐漸增多，而客製化的模組又快速成長且缺乏良好的規劃之下，系統的效能瓶頸逐漸顯現，最後只好藉由增大 cache 來解燃眉之急，不過 .NET runtime 的 cache 機制的不穩定性眾所皆知，除非透過轉存 database 的方式，否則記憶體的耗用程度把伺服器搞 crash 是很容易的事情。）

第二點，就是清楚的說明了寫入和讀取的效能差異性，一次性的 disk seek 所耗用的平均時間約為 10ms，也就是每秒最大的 disk seek 數約為 100 次，所以在使用 Datastore API 撰寫相關程式邏輯時，就必須考量到昂貴的寫入成本。相較於寫入，讀取成本則非常低廉，透過 Google 的 bigtable 架構，可達每秒平均 4GB 的讀取量，十分驚人！

再來的重點，就是重新強調了 entity 的 key feature 以及 transaction 和 entity group 的關係，主講人 Brett Slatkin 給了大家一個時分貼切的形容：將整個 bigtable 看做一個大型的 hashtable，透過給定特定 key 值的方式，使得讀取（query）的時間耗用可以降到最低（hash 運算之故），而 transaction 和 entity group 的說明大致上不拖 online document 所提及的內容，不過卻提到了一個開發上的重點，因為 transaction 會 lock 整個 entity group，所以有效的限制 entity group 的規模就很重要，思考如何依據開發需求以設計出有效降低寫入成本的 datastore model，便是 GAE 開發的關鍵點。

Brett Slatkin 提到的第一個範例程式 counter，就說明了分散式的 bigtable 架構的特殊之處，以往的 RDBS 可透過 SQL 命令來計算 query 的筆數，但是在分散式架構中，GAE 無從得知資料的總比數，所以我們必須額外建立一個儲存加總值的 global entity，透過不斷更新該 entity value 的方式來獲得加總值，不過這時又會遇到寫入時的 transaction 問題，如果加總的頻率過高，很可能導致寫入/ transaction 失敗的情形發生。此時，最好的 model 就是建立多個計數的 global entity 在不同的 entity group 中，於加總時動態隨機挑選其中一個 entity 做加總，在最後欲得知總數時，再透過 query 這些 entities 得到的多個 values 加總而得。

第二個範例則說明了相同的 global entity 如何應用在 blog 系統上，在面對需要排序處理的例子時，此範例說明了如何透過單一的 global entity （因為對於 blog 系統來說，張貼文章的速度以及急迫性並未像 counter 來的高）搭配 fetch method 來實作分頁（paging）功能，另外針對 comment 的實作方式，也充分說明了 timestamp 在分散式的 bigtable 上並未能保持絕對的一致，因此針對 timestamp 欄位做排序並未能真正獲得實際的資料產生順序，此時可以透過為每個使用者分別保存各自的 index entity 和 comment entity group 來達成排序的正確性（但非時間上的絕對正確性），此範例實為一 bigtable 上的經典 pattern！若能精通此範例於 Datastore 的應用 concept，就絕對能設計出符合分散式 bigtable 的 datastore model，值得有心鑽研 GAE 的人反覆研究。

Official page of Google developer day 2008:
http://sites.google.com/site/developerdaytaiwan/

Advanced GAE section video:
http://tw.youtube.com/watch?v=YbsU90iGySk