2008年还有几个小时就过去了, 真是不平凡的一年

一月, 得到了一份 python 的职业, 开发django, 同时光荣的加入了传说中的 freelancer 的队伍.

四月, 从自由职业者上位, 帮助公司落地, 忙碌季节.

六月我我们家来了一只受伤的小可怜, 一只长毛虎斑猫(当时也不知道他毛这么长, 只有巴掌大, 后腿折了). 两周后开始正常走路, 并且不断跳上椅子, 桌子以及电冰箱... 招财猫!

八月, 乘着奥运会结束之后, 举行 GAE Camp, 地点在 Google 上海办公室.

九月, 度假, 去了一趟云南. 度假回来以后趁着好心情, 全心投入到公司的工作中.

十一月, GAE Camp 在 Google 上海办公室成功的又来了一次, 会场气氛相当的热烈.

十二月, 就是这个月, 有幸参加了 opensocial hackathon 上海站的活动, 自己的 opensocial app 在现场 coding 比赛中胜出.

完美的2008

Facebook Connect 和 Google Friend Connect 是 Facebook 和 Opensocial 的升级.

SNS 的作用有两点:
1. 它们至少起到一个 openid 的左右, 你只需要一个帐号遍可以使用 Facebook 中的所有 App. 既然只使用一个id, 所以添加好友的工作也只需要做一次.
2. 每一个 App 都可以使用到好友信息, 起到SNS传播的作用.

这里写一写 Facebook Connect 的原理.
首先说一说传统 Facebook App 原理:

1. 传统 Facebook App 的是采用 POST, 我们在 Facebook 的 canvas 里所有的操作, 都回转化为对自己 App Server 的 POST 请求.

2. 除了自己的应用程序的数据以外, 还有很多以 fb_sig_ 打头的 POST 数据... 这些数据告诉你用户id, 用户朋友id...等等

3. 为了不让任何Facebook以外的冒牌请求折腾你的App Server, Facebook 在 POST 里面加上了 fb_sig 的签名. 所有的数据按照特定的排列以后md5, 结果和签名相等才可以.

Facebook Connect 要求在你服务器上放一个 html 文件用于 callback (当然你也可以命名为.php结尾)

1. 用户在你的站点上, 使用 Facebook 帐号登录你的站点, 成功以后 Facebook 会 callback 放置在你网站上的 html 文件, 该文件中的js代码负责写一些 cookies 到你浏览器本地.

2. Cookies的用途和传统 Facebook App 中 fb_sig 打头的 POST 数据一样, 具有签名作用. 传统的 Facebook App 中 Facebook 可以直接 POST 请求 App Server. 这里只能采取间接的方式, Facebook 写 cookies 到本地浏览器, 浏览器提交cookies给App Server, App Server 则可以验证用户是否登录了 Facebook, 并且取得用户的好友信息.

为了验证这些 cookies, 使用 Facebook 官方的 PHP 库可以解决问题. 如果使用 minifb.py, 需要做一定修改, 这里有我修改过的 minifb.py 版本

validate(secret, params, apikey)

validate最后一个apikey是可选参数, 用来 valid cookies 的时候必须要加上这个参数. 需要注意的是, 如果在 GAE 上使用, 需要将 urllib2 替换为 urlfetch.

Shanghaionrails的朋友们开始搭建起hosting服务了

ZoomType(ZT) 听起来很像 (mt) Media Temple. 希望一个好名字, 希望能被国内的rails人士记住.

在虚拟主机方面, 国外的优秀产品数不胜数, 但是在国内就变成了垃圾服务盛行的行业. 大量的主机空间只停留在ASP和PHP的局限中, 对于最新的web技术发展漠不关心以及无视. 导致了在python/ruby的用户群中, 很多人都不得不购买国外的虚拟主机, 并且忍受龟速服务.

现在, 我们很高兴的看到, 国内也有越来越多优秀的服务商, 开始重视这一点.
ZoomType, 浪点, 这些服务商仅仅是一个开始.

上周的Opensocial hackathon, 我的 opensocial app Flickr Show 有幸成为上海站的胜利者.

相比北京的开发者, opensocial在上海的开发人数少了很多, 即便我本人也是在无数次听说过opensocial之后, 在hackathon开始的一个星期之前, 才第一次亲手制作自己的opensocial app.

客观的讲, opensocial并不是非常难学的东西. 但是在学习过程中, 遇到的问题远远不如想像中的简单.

首先, 传统开发者必须要从基于模板渲染html的思路中解放出来, 拥抱AJAX.
其次, 要面对opensocial的近乎离散的文档. Opensocial从Gadget API派生出来, 往往直接进入opensocial的初学者根本无从下手. 基本的文档已经分布在各个不同的网站了, 当面对不同的容器, 或许你需要穿梭在各个不同厂牌的文档站之间.
最后, 调试成本较高. AJAX程序的调试是天生的问题. 在FF下通过Firebug可以解决一定问题, 但是在opensocial下, 情况变得更加复杂, 必须有充分的经验和大量的dump数据作为基础.

另外, 在opensocial各个容器的不同差异也让开发者头疼不已.
如何解决这些问题, opensocial在新的一年中还有很多路要走.

最后, 得奖的app已经在myspace上率先发布了, 地址在http://home.myspace.cn/Modules/Apps/Pages/appdesc.aspx?id=101881, 欢迎大家安装, 请尽量使用Firefox或者Safari.

不使用 myspace 的朋友想要体验, 请点这里

Orkut平台也即将发布, 敬请期待.

OAuth 技术作为 OpenSocial 采用的 Auth 方案. 其中签名技术有 HMAC_SHA1 , RSA_SHA1 和 Plain 三种
其中 RSA_SHA1 的方法. 初一看没觉得有什么.
仔细想想, RSA是非对称密钥技术, SHA1是签名算法, 这两个放在一块是什么意思呢?

整理思路, 理解如下:
1. 当一个请求的数据到达到我的网站, 首先计算一下的请求中所有数据的SHA1值(除了签名以外)
2. 用RSA算法中的公钥来解开签名数据, 得到解密后的签名值
3. 比较两个值

如果两值相等, 说明发送请求的主机持有合法私钥. 是来自SNS网站.
(iGoogle 和 Orkut 当前使用这种签名技术, myspace 使用 HMAC_SHA1 签名)

回到于python的相关内容, 标准库中有SHA1的lib可以使用, RSA没有, 不得不求助于PyCrypto.
在GAE环境中, PyCrypto不能使用. 也不能将这个库整体上传, 那样太大了, 另外一个原因是它也包含很多 C ext.
由于iGoogle给我们的公钥格式是PEM格式(一种文件格式, 学名叫X509), PyCrypto不能解码得到我们所需的公钥.
解码这种格式需要 tlslite 这个 lib.

最后, 花了点时间, 从两个lib中提取到了10个py文件, 不需要依赖 C ext, 可以在GAE上使用, 在这里下载.