自從 Facebook 推出 Graph API 之後, 就開始把目標往 Facebook 之外的網站拓展, 透過 OAuth 2.0、Graph API 跟 Javascript SDK 就可以很容易自己的網站上整合 Facebook 的功能進來。 而 Facebook 上的 Application 也開始建議使用 iframe 取代 FBML, 因為透過新的 SDK 便可以達到原本 FBML 才能達到的功能。

而接下來 Facebook 打算把 App 的開發更 simplify, 他們把 Facebook 站內的開發跟站外的開發變成是同一件事! 因為除了 canvas 要改用 OAuth 2.0 之外, profile tab 也要改用 iframe 了!!!

我想都改用 iframe 之後, Facebook 的 server 也會輕鬆很多吧? 原本的 FBML 的作法會一直 fetch html 回來 parse, 以後似乎只剩下 <fb:serverFbml> 這件事了。

在 Facebook Platform Roadmap Update 這篇文章中提到以下幾點:

1. canvas 也將採用 OAuth 2.0 的新方式
2. profile tab 也將從 FBML 改用 iframe
3. 移除 user page 的 profile tab ( 粉絲頁當然還是保留 )
4. 拿掉 REST API, Data Store API 還有一些 social plugin 可以取代的 FBML tag

其實現在去看 application settings 就可以看到介面也整個簡化了, 左邊的 tabs 縮減成了 5 個, 也已經出現了 OAuth 2.0 for Canvas (beta) 這個選項。

我想今年年底一定又有一堆 Facebook 相關的開發者要哀號了, 沒事還是多看看 Developer Roadmap 先做好心理準備吧 XD 不過最快的是下禮拜的 profile tab 要變成 520px 的寬度了阿 …

Stashboard, 類似 Google 的 Apps Status Dashboard 及 Amazon 的 AWS Service Health Dashboard 的 Status page。

UI 看起來很不賴, 用 Python 在 Google App Engine 上面跑。 所以只需要下載 source code 回來改一下 app-id 就可以 deploy 上 GAE, 只需要不到一分鐘就可以架起來了。 而且有 REST API 喔!

不過我本來以為有自動監測這種功能說 XD

以前有看過一些文章說是把 django zip 起來, 然後用 zipimport 來跑 django, 不過其實除非你要用的是 django trunk, 否則 app engine 其實本身就內建了 0.96, 1.0 跟 1.1, 當然這邊指的是雲的那一端, 本地端還是得裝上要使用的 django 版本, 不過不用把 django 放進你的 app engine project 就是了。

像是下面這段, 即使你使用的是 webapp, 你仍然可以透過下面這段 code, 寫在 request handler 的最前方, 來使用 django 1.1 的功能, 而非老舊的 django 0.96

from google.appengine.dist import use_library
use_library('django', '1.1')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myaudiocast.settings'

至少 django 從 1.0 開始, template 的功能就大幅改進, 光 with 跟 escape_js 這兩個 template tag 就夠棒的了!

其實 google 「app engine django」就可以找到一堆教你如何在 app engine 使用 django 的文章, 不過我還是覺得 Google App Engine Helper for Django 最方便。只需要下載下來解開, 幾乎不用修改就可以開始使用。

而 Google App Engine Helper for Django 預設是使用 django 1.0, 不過只要修改 main.py 裡, 下面這一段就可以使用 django 1.1 了

InstallAppengineHelperForDjango('1.1')

當然改用 django 1.0 以上的版本, 除了 template 之外就是 form 也改進了很多, 雖然原本 app engine 就已經有提供 djangoforms 可以直接透過 datastore 的 model 來產生 form, 但是在 webapp get/post request 分開處理的狀況下, django form 在使用上顯得非常憋腳, 而且 djangoforms 用的是 django 0.96 的 form, 所以功能上的確差了許多。

以上是我對在 app engine 上使用 django 的感想。

上面這張圖是 myaudiocast 簡單的示意圖, 接下來就用這張圖來說一下關於 datastore 使用上的心得

單筆資料 ( one-to-one )

像是 User 對 Podcast 在我的規劃上是 one-to-one, 所以如果是 one-to-one 這類的資料就給定 key_name, 直接用 key_name 來抓單筆資料, 而不是先用 filter 之後在用 get 來取得單筆資料。 因為用 appstats 就發現後面這個方法常常是花最多時間的, 然而因為之前的資料都沒給 key_name 現在也來不及了 …

多筆資料 ( one-to-many, many-to-many )

像是 Episode 這類 one-to-many, 會有多筆的資料, 沒事就不用給 key_name 了, 因為通常都是透過 filter 來取出多筆資料, 所以只需要寫入時指定 parent, 讓 user 的 episodes 可以成為一個 entity group, 這樣抓取資料比較快。

盡量使用 memcache

datastore 其實並沒有很快, 甚至 model api 沒有 query cache, 而 memcache 的 quota 其實滿大的, 所以要盡量用 memcache。

避免在 template 透過關連取資料

像是 podcast 跟 episodes 都可以透過關連, 像是 user.podcast 跟 user.episodes 來取得資料, 所以因為寫 django 的經驗, 我可能就直接丟 user 變數進 template, 然後都用 user.podcast, 跟 user.episodes 來取得資料, 可是這在 app engine 則是要避免的, 因為 app engine 的 model 並沒有 query cache, 所以可能會像下面這樣的作法, 就會對 podcast 做兩次 query。

{{ user.podcast.title }}
{{ user.podcast.description }}

所以得一開始就把 user 跟 podcast 丟進 template, 直接取得資料而不是透過物件關連。

不過有時候就是一定得透過關連來做, 那麼就請使用 django 1.0 以上的 template, 透過 with 這個 template tag 來避免多次 query, 或者是在 model 新增一個 property 然後用 memcache 來解決, 像是我的作法

class User(db.Model):
    ...

    @property
    def podcast(self):
        cache_key = 'user-podcast-%s' % self.key()
        p = memcache.get(cache_key)
        if not p:
            p = self.podcasts.ancestor(self).get()
            memcache.add(cache_key, p)

        return p

先前說過, 以前不懂忘記給 key_name, 現在只能這樣 query 了, 頂多加上個 ancestor (默)

結論

datastore 雖然不太需要擔心 scale 的問題, 可是在 run 之前卻得更仔細規劃, 否則效能低落, 花的只是更多錢阿 XD 而 memcache 則是一定得用, 否則跑起來的確是不夠快。

大概是這樣, 希望沒有哪裡有寫錯的, 如果有的話, 也請多多留言指指教, 謝謝 :p

按照文件把 appstats 裝好 run 起來後, 就可以在 app engine 後台的 log 上看到 appstats 添加的 link, 如下圖反白的網址

連過去這個網址就可以看到下面這個 bar chart

在 bar chart 上點選一個比較長的 bar 就可以看到下圖, appstats 幫你把吃掉比較多資源的 code 給標出來

超方便的! 真的很容易找出程式慢在哪。

這兩天都在改 MyAudioCast 的版型跟一些 code, 現在這樣看起來好多了 :D

然而這樣出現了一個問題, 沒辦法檢查上傳的檔案類型, 甚至知道檔案大小 ( 原本的作法是上傳完之後, 再去 s3 抓檔案大小的資料 ), 所以研究了一下用 swfupload 來做檔案進度顯示以及顯示, 並限制檔案的類型、大小, 同時也可以取得檔案的大小。

原本的 POST FORM 看起來像是下面這樣

<form id="upload_form" action="http://myaudiocast.s3.amazonaws.com/"
    method="post" enctype="multipart/form-data">
<input type="hidden" name="key" value="{{ key }}" />
<input type="hidden" name="AWSAccessKeyId" value="{{ AWS_ACCESS_KEY }}" />
<input type="hidden" name="acl" value="{{ acl }}" />
<input type="hidden" name="policy" value="{{ policy }}" />
<input type="hidden" name="signature" value="{{ signature }}" />
<input type="hidden" name="Content-Type" value="{{ content_type }}" />
<input type="hidden" name="Cache-Control" value="{{ cache_control }}" />
<input type="hidden" name="Expires" value="{{ expires }}" />
<input type="hidden" name="success_action_redirect" value="{{ success_action_redirect }}" />
...
</form>

基本上的作法就是把原本 policy conditions 當中的 success_action_redirect 改成 success_action_status, 也就是把轉址改成吐 201 的 status code, 然後在 policy conditions 移除 success_action_redirect, 並加上下面兩個項目即可。

["starts-with", "$Filename", ""],
["eq", '$success_action_status', "201"]

而 swfupload 的 PostParams 也是把原本要 POST 出去的欄位加上即可

swfu.setPostParams({
    'key': key,
    'AWSAccessKeyId': "{{ AWS_ACCESS_KEY }}",
    'acl': "{{ acl }}",
    'policy': "{{ policy }}",
    'signature': "{{ signature }}",
    'Content-Type': "{{ content_type }}",
    'Cache-Control': "{{ cache_control }}",
    'Expires': "{{ expires }}",
    'success_action_status': {{ success_action_status }}
});

然後 s3 bucket 那邊也得加上一個 /crossdomain.xml, 否則 Flash 會有 security error, 檔案內容如下。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
    "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*.myaudiocast.com" secure="false" />
</cross-domain-policy>

最後就是, 由於 Flash 接到 200 以外的 status code 都會視為失敗 ( 至少我查到的資訊都是這麼說 ), 所以 swfupload 接到 201 的 status code 也是會認為失敗, 所以就得再 uploadError 這個 handler 判斷 status_code 是否為 201, 如果 201 則是上傳成功, 所以這點得再注意一下, 我目前的作法是這樣。

這篇主要只是記錄一下, S3 真是好服務, 而 app engine 也很好, 不過限制太多, 得自己繞路就是了 XD

基本上是依我自己的需求來開發的, 記錄下來的推噗可以用每日以及日曆呈現, 然後可以搜尋, 以及用 hash tag 分類, 日曆的方式大概看起來像下面這樣

其實用來記錄推噗後, 可以回顧先前每天的訊息記錄, 可以很快就知道哪一天在幹嘛之類的, 就當成日記, 不過其實這也要看個人推噗的使用習慣啦。 另外透過 hash tag 來當書籤其實也滿好用的, 至少我自己覺得很不錯 XD

不過目前沒打算開放給太多人用, 畢竟有些人覺得沒這個需要, 所以有需要的人。 麻煩你在推特 follow 我, 並發送訊息下面這段訊息

小海 @tzangms 你好帥! 我要試用新玩具!

或者是

小海 @tzangms 我愛你! 我要試用新玩具!

甚至是你不想試用, 你也可以在你的推特發送下列訊息

小海 @tzangms 你超帥的!

我看到就會 DM 網址給你, 謝謝! XD