Google Wave的使用時機

基本上……

1. 暫時不要拿Wave來討論私隱、秘密的話題，因為如果不小心把不相干的人加入Wave裏，仍未有辦法移除。

參考： remove contact from wave?

2. 資料不是百份百安全，我有一個Wave突然無法開啟，正好在討論GAE的對手 :X

3. 想當成Twitter/Plurk般使用是玩自己，因為未有Contact List的概念，每次開新Wave，都要逐個輸入，當你有超過50個朋友時……

4. 用Firefox開超過99條訊息的Wave是惡夢

但是……

1. 用來brainstorm idea、計劃真的好好用，可以修改自己或別人所打的文字，也可以針對論點來回覆，加上不同的Gadget令討論更有效率。

所以當…………

1. 我想談一些不算秘密、被人知道也沒有什麼大問題的東西的時候

2. 我想要跟別人brainstorm想法、計劃的時候

3. 我無聊的時候

就會考慮用Wave。

App Engine的優化技巧（一）- 避免ReferenceProperty讀取資料庫

Google App Engine是一項以CPU時間、資料庫存取次數及其他限制等作收費依據的服務，曾經有過每天CPU時間上限達到46小時的日子，後來降至6.5小時，吸引力的確大不如前，眾用戶變得要過著勒緊褲頭的生活，這時候優化的技術就十分重要。

官方文件中提過不少的技巧，這裏就說一說官方文件中沒有記載的，第一個是關於ReferenceProperty的自動載入、轉換。

參考以下代碼：

class Author(db.Model):
name = db.StringProperty()

class Story(db.Model):
author = db.ReferenceProperty(Author)

story = db.get(story_key)
author_name = story.author.name

ReferenceProperty類別的模型為金鑰值(db.Key())，指向其他的記錄。以上叫做Story的模型有一個叫做author的ReferenceProperty，代表該故事的作者，而作者的資料則記錄在Author模型中，這種做法在SQL資料庫裏也很常見，沒什麼特別。

story = db.get(story_key)

這句在BigTable中取得一項Story記錄(又或者叫做實體模型、Model instance)，要留意就是story.author_name所儲存的只是Key，並不包括作者的姓名等記錄在Author的資料。

author_name = story.author.name

當執行了以上的命令時，author_name儲存了什麼呢？答案是Author的實體的模型(model instance)，並非以上所說的Key值。

這是ReferenceProperty的「功能」，一項自動載入、轉換的能力，跟據說明文件：

「ReferenceProperty 屬性值可以當做被參考實體的模型實例來使用。若參考的實體不在記憶體中，使用其屬性做為實例時，會自動從資料存放區擷取該實體。

A ReferenceProperty property value can be used as if it were the model instance of the referenced entity. If the referenced entity is not in memory, using the property as an instance automatically fetches the entity from the datastore.」

Source : http://code.google.com/intl/en/appengine/docs/python/datastore/entitiesandmodels.html#References

故此在story.author_name被第一次存取時，GAE就會自動在資料庫中取出記錄，很方便的功能吧？但別忘了，這會存取資料庫，代表會消耗有限的配額。

如果真的需要到這項資料，消耗也是沒有辦法的，但如果在其他的query中已取得這項Author的實體模型，也就冤枉了。

另外有種情況也會造成無辜的消耗，就是創建URL時，現在很喜歡這樣的URL風格：

xxxxxxx/$author_id/$story_id

當author_id=768,story_id = 10045時，就會變成是：

xxxxxxx/768/10045

假設在你的程式裏，已經擁有一個Story的實體，然後你想輸出以上的URL，基於需要用到Author的ID，你可能會這樣寫：

author_id = story.author_name.key().id_or_name()

而很不幸地，雖然在Story的實體中有記錄Author的Key，但這種寫法會導至GAE進行一次資料庫存取 － 浪費了配額下載了你不需要的資料。

這時候需要迂迴一點的寫法：

property = getattr(Story, "author_name")
author_key = property.get_value_for_datastore(story)
author_id = author_key.id_or_name()

這樣就不會造成資料庫的存取，為你省下不少的配額。

註： getattr(story,"author_name")的結果也是會導至資料庫的讀取

Google App Engine缺乏備份工具的原因

一直都很奇怪，為什麼Google沒有為App Engine提供官方支援的備份工具呢？雖然Google一貫的做法是若有成熟的開源方案，就直接拿該方案來用，但唯一一套的gaebar有近半年以上沒有更新，跟新版SDK也不兼容，那為什麼仍未有動作呢？而且開源方案也實在太少了。

為了這個問題，做了些許的研究，發覺……原來又是BigTable的問題。

BigTable跟一般SQL的關聯式資料庫的概念非常之不同，那是分散式的資料庫，所以用法跟SQL相去甚遠。

例如說一項記錄的ID，BigTable有三種不同的表達方法，頭二種是numeric ID及key name，key name是由用戶設定的文字，在模組中是唯一的存在，而當記錄沒有被賦予key name時，BigTable就會為記錄加入numeric ID，故名思義那是一個數字，但這個數字的值並不連貫，所以也不能用來計算有多少記錄存在。

無論是numeric ID還是key name，最後都可以編碼成為最後一種表達方法 － 一個50位元的字串，那才是真正的ID。

問題是出於numeric ID，那是資料庫賦予的，用戶沒有辦法指派numeric ID予新建的記錄，就算有那個50位元字串也不能，唯一例外的是key_name。那麼使用了numerc ID的記錄，在備份後，是沒有辦法還原至原來的numeric ID的，那麼備份系統亦無法建立……

gaebar的解決方法是把numeric ID轉成key name（在numeric ID前面加入"id"字串），但這造成二個問題

1) 備份系統會修改資料庫內容，或許會令網站無法使用。
2) numeric ID及key name衝突又如何解決呢？（在Deployment server上應該不會發生，但development server是一定會的)

怎樣才可以設計出GAE合用的備份工具呢？頭痛啊。

Google Reader的Twitter/Plurk化？為Wave鋪路？

玩了Plurk這micro blogging平台有一段時間了，已經成為了我網上閒聊的主要場所，不過對於始祖的Twitter，我依然對其生態感到不可思議……

在某次會議中，有人問我什麼是Twitter，我解釋了一遍，對方始終不得要領，甚至反問這有什麼特別嗎？費了很多唇舌，結果我還是沒辦法說出能打動對方的Twitter吸引之處。但無論如何，以現時用者數量來說，證明了有大量用戶接受Twitter的模式，這亦引來了其他網站的仿效。

跟其他潮流物一樣，成功以後會首先引來直接的模仿者 － 打正Micro blogging名號的網站，跟著是在概有的產品中引入相關概念的改良性產品。

在云云眾多的網絡服務之中，其中有一個我留意了許多，認為是很有機會成為像Twitter/Plurk般的社交網絡，那就是Google Reader，而最近有些改動隱若顯示出Google有這個想法，看來是在為Wave鋪路之中。

Twitter與一般論壇有明顯的分別，論壇是主題導向的，先有網站再來各個話題的看板，人們通常會集中瀏覽自己有興趣的話題上，久而久之就成為站友、板友；而Twitter是以人本身主導的，用者所追蹝留意的不再在是看板而是人本身，Twitter的模式會比較著重在社交這一項上。比起字數限制，我認為這種交友模式才是micro blogging的精髓。

而主要用途作為RSS Reader的Google Reader，相比起其他offline的RSS Reader，除了能在數部電腦間分享文章外，同時也俱備社交的能力：

1. 最初先建立了friend的機制，你可以把文章分享給其他朋友，其他人亦可以訂閱你所分享的文章。

2. 跟著你可以為分享文章加入說明。

3. 接著連其他人都可以為該文章加入個人意見。

去到階段3的時候，一個簡單的Plurk式的分享討論平台已經成形（Plurk的形式沒Twitter那麼極端，即使沒有看板還是有討論串的存在），最大的分別是一定要以分享的文章為主題，變相只能發表跟文章有關的意見，然後等他人加入。

老實說，這樣並不太吸引……

而最近有些改動，又朝這個方向踏出了一大步。

4. Friend改名變成了People you follow

這個當然是不含技術考慮的改動，不過是變得很有Twitter的味道。


5. 用家可以直接在Google Reader上發表主題


現在按People your follow後會出現一個對話框，有一項字寫著：“Have some thoughts to share”，用家可以在這裏像Twitter/Plurk般打入自己的想法，然後追蹝你的用家就會看到，也可以給予意見。

除了交友制度不同、沒有爬龍舟式的界面，其他的用法跟Plurk已經相去無幾了……

現階段會把Google Reader當成是microblogging式平台的用家並沒有多少，但當日後加入了Google Wave的協作式討論的能力時，情況又會否有所改變呢？

到時會變得吸引許多，而且有不少blogger都喜歡把Twitter/Plurk當成是新作的發佈平台，他們受樂的話亦會成為一股推動的力量。

或許將來提及Twitter/Plurk時，還得加上Google Reader，不過當然不再是以micro blogging稱之（Plurk的字數限制其實很多餘)，可能會有新的名詞。

慢慢削減免費服務的Google

金融海潮不可能對Google沒有影響，問題是有多大，以及有多少會影響到服務本身，當中比較為人所知的是本年一月時，Google宣布了有幾項服務將會停止開發或關閉，其中包括曾經是我最愛的Notebook，其餘還有Video、Catalogs、Dodgeball、Mashup editor等等。

除此以外，Google Apps － 針對網域的免費的電郵、網頁、文件等等的服務，標準版本來可以伸請到200個帳戶（或許更多，我未試過），由一月起只餘下50個名額，再多就要轉昇級版（教育版不受此限），50個對於小型公司、組織來說問題不大，介乎這些之間，卻又沒有經費的組織就慘了些，例如我正在搞的某計劃 >_<

然後接下來將會收緊的免費服務是 － Google App Engine。

以前的免費限額為：

CPU Time: 46.30
Bandwidth: In/Out 10.00 GBytes
Stored Data: 1.00 GBytes
Recipients Emailed: 2,000.00 Emails

在2009年5月25號以後：

CPU Time: 6.5 hours of CPU time per day
Bandwidth: 1 gigabyte of data transferred in and out of the
application per day
Stored Data & Email Recipients: unchanged

CPU及Bandwidth的免費限額將降至本來的十分之一左右，幅度相當之驚人！

雖然如此，但對低流量的網站來說還不至於有什麼影響，情況跟Apps相同，最麻煩是較高流量但又沒有收入的網站，又不知如何是好。

一般為Google App Engine所開發的軟件，是不能直接用於其他平台上，問題在於App Engine所提供的資料庫BigTable，並不是一般的關聯式資料庫，是分散式的資料庫，對於一般習慣使用關聯式資料庫的程式師來說，BigTable已經不能光用「奇特」來形容……

至於已經有一定收入的網站呢，讓Google賺這筆錢吧，它的收費又真的不算貴……

以上的服務還不至於十分影響一般的用家，但當經濟越來越差時，我們已經習以為常的免費服務，會否能夠持續下去呢？或許我們要要考慮一下分散風險的做法。

GSoC 2009結果出來了！

早前寫過一篇文章介紹GSoc，希望能推動多些香港學生參與，而現在GSoC 2009的結果出來了，在此恭喜KS Chan通過評審，成為GSoC 2009計劃的其中一員！(下句是請食飯？)

List all accepted organizations

以上為成功伸請的團體名單，按團體名字就會顯示出成功受理的學生名字及計劃詳情。

不知道還有沒有其他香港學生成功呢？遲些GSoC會以KML(Google Earth格式)再發達一份學生名單及其所在區域，到時自有分曉。

另外，Sammy Fung發現了原來Anthony Fok有登記成為其中一位Mentor，他所主持的是"Creating a new MIPS N32 ABI port for Debian"，嗯……看來是與龍芯有關的。

推動學生參與Google Summer of Code

由2005年開始，每年Google都會為大學生們舉辦一項名為Summer of Code的活動，津貼他們參加開源軟件的開發，讓他們得到開發的經驗外，亦能加深對開源軟件的認識，同時亦能成為各開源軟件的助力。

津貼的金額為$5,000美金，其中$500會撥給該開源計劃，其餘$4500則由學生領取(若為港幣三萬五千元）。

計劃目的：

• Get more open source code created and released for the benefit of all;
• Inspire young developers to begin participating in open source development;
• Help open source projects identify and bring in new developers and committers;
• Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits (think "flip bits, not burgers");
• Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).

能在參與開源計劃、貢獻世界的同時，獲得金錢的利益，要是我當年讀書時代有這麼有意義又好康的事，不參加才是奇怪呢。

但世事往往就是這麼神奇，翻查2005至2008的記錄，除了2005年那屆有一位香港學生成功外，之後就再沒有來自香港的大學的學生成功參與計劃。

參加這項計劃真的有那麼困難嗎？我想問題不關審查事，而是香港報名參與的人數實在太少。

要是有這幾屆的學生反對，說曾經參加而失敗的話，我很樂意修正這篇文，怎麼說我都離開學界都有一段時間了。但若然沒有的話，那麼我很疑惑為什麼沒有學生參加呢？

可能原因：

1. 不知道什麼是Google SoC
2. 不明白、不清楚什麼是OSS
3. 怕困難而不敢參加
4. 得知活動時……已經是大學最後的暑假了
5. 對OSS完全沒有興趣

點1及2只要多點的宣傳，學生們的困惑不難去解決，至於點3，總會有不怕困難勇於挑戰的學生吧？要是有這樣的學生，卻因為點4的原因而悔恨的話，那就真是一件跟點5同樣可惜的事。

距離計劃開始到報名結束，還有若一個月左右的時間，所以我想借這個機會向各院校的學生，推介一下這個計劃，不要錯失這個機會。(暫時我已經把資料寄了給相熟的教授，亦已有所回應。)

活動詳情及建議

雖然是暑期的活動，不過準備的工作現在就得展開，開源專案的團體需要在3月9日至13日期間遞交他們的伸請及Idea List，包括想找學生去改良或加入的功能、模組，獲選名單會在3月18日公佈。(這個我開始準備)

學生們需要在3月23日到4月3日期間遞交伸請及計劃書，然後各個團體會就計劃書評分，Google則會在4月20日公佈獲選名單。

若果真有興趣參與的話，我會建議先看清楚有什麼開源項目參加了計劃，找出自己有興趣的項目（沒有就算了），再看Idea List裏有什麼是想挑戰的。雖說這是一項有金錢津貼的活動，若只為酬勞而強逼自己去參加的話反而失去計劃的意義，開源軟件開發應該是一件快樂的事才對。

而在寫計劃書之前，最好先到有關團體的mailing list、forum裏，找相關的開發人員詢問有關的細節及介紹自己的想法，這樣對伸請的成功會有一定的幫助。

雖然我未參加過這個計劃，但若果你有什麼問題關於OSS的問題的話，也歡迎找我商量。

相關資料：

計劃網頁：http://code.google.com/soc/

時間表： http://code.google.com/intl/zh-TW/opensource/gsoc/2009/faqs.html#0_1_timeline_5354032302481437_

Debian的SoC計劃匯報 : http://www.milliways.fr/

海報及推擴材料(Thanks Anthony!)：http://code.google.com/p/google-summer-of-code/downloads/list

Google Maps 正式登陸香港、Blogger聚會

望穿秋水，等了又等，Google Maps終於正式登陸香港！即是說原本不盡齊備的本地資訊將會變得完善，例如會有詳盡的街道地圖、駕駛路線，以及其他資訊供應商的資料，像是OpenRice的餐廳評價等。

看來沒有再使用中原地圖的必要了。（謎之聲：為什麼不支持本地網頁？）（因為對Firefox的支援差！）

Google為宣傳這個事情，特別搞了一個blogger的聚會，以下是部份相片：

Google展示了本地幾個不同的Google Maps應用，最有趣的竟然是馬會的作品，可以在瀏覽器上重現各場賽事的競賽實況，就像是遊戲機中心的賽馬遊戲那樣！

更多相片

Google Notebook支援Label?

今日打開Google Notebook時發現左下角多了個Label欄，風格跟Gmail的一樣，可是按了Edit後就只有幾句訊息，不能建立Label，害我空歡喜了一場……

說起來Google Notebook算是我繼搜尋器及Gmail後，使用得最頻繁的服務，沒法子，誰叫有實在太多的資訊要記住。在之前主要是靠Bookmark去記錄，但久 而久之，所記下的條目數量竟大得令Google Sync無法處理，5MB多的書籤就算扣減favicon也塞不上去，只好轉過去用Foxmark，但每次同步都花掉大量的記憶體，只好忍痛把大量東西刪 除。

用了Google Notebook後，情況是改善了不少，要把記錄的東西找回來亦比起用Bookmark更方便，可是很快老問題又出現－就是開了太多的Notebook 了。管理漸漸開始變得麻煩，新增資料到底要加到那個notebook處呢？我曾經試過同時開了3個叫OpenOffice的notebook。

希望Label的支援快些完成，不要放個沒用的框框吊我們癮吧！

2007-11-02 18:03 修改：原來這個Label是用在Note上，而不是用在Notebook上，只要在該Note的右上角叫出選單，會有”Add labels”的選項。之後在主畫面的Label框內，按Edit Label，那裏可以remove label。

不能用在Notebook上實在很可惜……

2007-11-07 20:07 修改： 在Google Notebook裏終於見到new features這個字樣了！可是………… 我之前建立的LABEL全都沒了！！(過了幾天又回來)