悠言悠闲：火箭不死心还在

不死心还在。下午听到这首歌，真的很合适给今天的火箭当主题曲。即使被ESPN的所有“专家”一致通过必输爵士，即使被CCTV“内定”必输所以一场比赛都不转播，即使有一半以上的休斯敦球迷都不相信他们能通过第一轮，即使被世界所背叛，他们也会一步一步的走向胜利的日子。知道T-Mac接受采访时最常说的一句话是什么？我不在乎人们怎么说。只有甘于忍受寂寞和敢与世界为敌的决心，才是让休斯敦火箭，让 Tracy McGrady、Shane Battier、Luis Scola、Dikembe Mutombo、Bobby Jackson、Chuck Hayes、Aaron Brooks 以及 Rick Adelman，能够坚持与爵士为之一战的精神支柱。

有备无患：在 Google App Engine 上应用豆瓣 Python 客户端

Google App Engine 是 Google 四月初推出的一个网络应用开发平台，它提供了一体化的分布式服务器群、供快速开发的网络应用开发框架、最多500MB的数据存储，以及可自动升级的后台流量统计服务。换言之，App Engine 让开发人员专注于应用本身，Google 将提供应用运行及维护所需要的一切平台资源。

App Engine 目前只支持 Python 作为唯一的开发语言（wyt：谁让“Python 之父” Guido van Rossum 也在 Google 工作呢，近水楼台先得月）。所以，如果想在 App Engine 上利用豆瓣开放的书影音和用户数据，我们可以使用豆瓣提供的 Python 客户端来开发。另外，由于以前的 GData Python 客户端 都是用 httplib 模块来处理 HTTP 请求，而 App Engine 则规定必须通过其自带的 urlfetch 才能实现，所以为了让豆瓣 Python 客户端所必须的 gdata.service 模块能够正常的在 App Engine 上工作，我们还需要版本号大于1.0.12.1的 gdata-python-client。下面是具体步骤，如果有什么问题，还请留言告知。

1，下载 gdata.py-1.0.12.1.tar.gz
2，解压缩到当前目录，并编译 gdata

$ tar xf gdata.py-1.0.12.1.tar.gz
$ cd gdata.py-1.0.12.1/
$ ./setup.py build

3，将编译好的 atom 和 gdata 目录复制到项目目录 ~/doupye/

$ cp build/lib/* ~/doupye/

4，下载 douban-python-0.1.1.tar.gz
5，解压缩到当前目录，并编译 douban-python

$ cd ..
$ tar xf douban-python-0.1.1.tar.gz
$ cd douban-python-0.1.1/
$ ./setup.py build

6，将编译好的 douban 目录复制到项目目录 ~/doupye/

$ cp build/lib/* ~/doupye/

7，修改豆瓣的 Python 客户端文件 service.py

$ cd ~/doupye/douban/
$ gvim service.py

service.py

import gdata.service
# 添加下面两行，让所有的 HTTP 请求调用 App Engine 的 urlfetch (?)
import gdata.urlfetch
gdata.service.http_request_handler = gdata.urlfetch

演示网页

http://doupye.appspot.com/demo/douban_python_client/

有备无患：订阅所有豆瓣用户的广播

以前写过输出单个用户的友邻广播 feeds 的脚本，后来豆瓣把原来的“友邻”一分为二成双向的“朋友”和单向的“关注”，那个脚本就过时了。所以我重写了 pydmb.py，并让它能够输出多层友邻关系的豆瓣广播 feeds 的 OPML 文件。根据六度分割理论，平均只需要六层关系就可以联系到任何两个互不相识的人。那么，从任何一个豆瓣用户出发输出六层友邻关系的广播，是不是最终也可以得到几乎所有豆瓣用户的广播呢？我没有试过，因为即使只输出了两层友邻关系的广播，我已经得到 8825个 feeds，如果输出六层的话会吓到人的。

使用方法

1，下载 pydmb.py

2，解压缩到当前目录。

3，运行脚本。这里举一个例子，比如你想获得 keso 和阿北的三层朋友（不包括他们关注的人）的广播 feeds，可以输入命令：

$ ./pydmb.py keso ahbei --friend --depth 3

4，需要帮助可以运行命令：

$ ./pydmb.py --help
Usage: python pydmb.py [-fc] [-d DEPTH] user1 user2 ...

Options:
  -h, --help            show this help message and exit
  -f, --friend          output douban miniblog rss of your friends
  -c, --contact         output douban miniblog rss of your contact
  -d DEPTH, --depth=DEPTH
                        the depth of relationship to output

2008-04-18 UPDATE:

NullPointer 留言说想看看六度连接的试验结果，我也很感兴趣，所以昨天先试了试二度和三度的连接。结果从阿北出发的二度空间能连接到10214个人，三度空间能连接到117113个。

>>> from pydmb import *
>>> graph = UserGraph('ahbei')
>>> graph.search(2, 'fc')
>>> len(graph.dict.keys())
10214
... ...
>>> graph.search(3, 'fc')
>>> len(graph.dict.keys())
117113

结果还算理想，可是用的时间比较厉害，二度连接还好只用了十几分钟，但三度连接用了将近八个小时。照这样推算，分析六度连接（理论上说，就是要分析将近140万豆瓣用户的朋友和关注的人）可能会超过800个小时。所以用这个脚本来做就不太现实了，如果要做的话，最好把 urllib2 和 BeautifulSoup 换成更快的库，然后用两个线程分别来抓取和分析网页，这样效率会高一些。

南言北哲：你最想看哪些季后赛的首轮对局？（三）

昨天火箭大胜太阳之后，在常规赛季只剩下最后三场的情况下，有四支球队距离西部冠军只有少于等于1场。这就像在银石跑到第60圈，Kimi、Hamilton 和 Alonso 从 Luffield 弯出来之后，三辆赛车并驾齐驱以超过时速280公里的速度冲向终点一样不可思议。

。。。我滴妈呀，太刺激了～～～（wyt：请模仿德云社李菁的嗓音进行想象。云里雾里的同学可以参考本文最后的郭德纲相声：）

虽然我也期待一个戏剧性的 ending，比如火箭最终夺冠之类的，但是如果常规赛就此结束，那么今天的排名将最接近我想要看到的季后赛首轮对局，小牛（7）对湖人（2），太阳（6）对马刺（3），以及接下来将讨论的火箭（5）对爵士（4）。这样其实也不错。

第三局：火箭 vs 爵士

——从哪里跌倒，就要从哪里爬起来

去年，火箭的第一场和最后一场常规赛都在盐湖城和犹他爵士比赛，两战皆墨。今年，火箭的第二场和倒数第二场常规赛又都在盐湖城，火箭赢了前一场，而后一场在4月15日。去年，火箭在季后赛第一轮的七场大战中输给了爵士，让爵士闯到西部决赛。今年，稳居西部第四的爵士仍然是火箭的季后赛第一轮的对手最有可能遇到的对手。

事实上，我也希望它是。去年11月2日以105-96战胜爵士之后，27投17中砍下47分的 T-Mac 看来很平静，“这不能说明什么，这仅仅是赛季的第二场比赛。”可姚明似乎“出卖”了他，“我们像是在打第八场系列赛，我们得到胜利之后才能开始新的赛季。”如果爵士真的再一次成为火箭的季后赛对手的话，那么无论是对T-Mac，还是对火箭队，都是时候来证明自己了，IT'S TIME FOR A REVENGE，是时候报仇雪恨了！

附：郭德纲相声《李菁开车》（口不对声，听听就行）

悠言悠闲：root敢死队

原来平时那么爱用sudo，还真不觉得。

$ history |awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
99 sudo
62 todo
52 python
49 eix
38 mysql
38 cd
32 ls
19 tda
16 vi
15 tde

有备无患：用 AideRSS + Google Reader 辅助阅读

前几天我计算出自己的 FRER（Feed 阅读效率评价）为15.14，这意味着在 Google Reader 读到的大约85%的文章，至少对我来说，是噪声。这里所浪费的时间，虽然不能直接推算，但估计至少有三分之一。为了更有效率的利用这些时间，我尝试用 AideRSS 为 Google Reader 设计的 Firefox 扩展来辅助阅读。

AideRSS 原本是一款在线的 feed 过滤工具。它通过分析 PageRank，文章评论和 Trackback 的数量，以及文章被 del.icio.us 和 Digg 用户收藏的次数等指标，计算出相应的 AideRSS PostRank（从1.0到10），并以此为用户过滤 feeds 减少信息过载带来的困扰。而 AideRSS 的这个 Firefox 扩展将 PostRank 整合到 Google Reader 中，我们可以在每一篇文章的标题左侧看到相应的 PostRank，在末尾看到相应的评论、Trackback、del.icio.us 和 digg 收藏的具体数目。另外，我们还可根据 PostRank 的高低过滤出 Good，Great 和 Best 的文章来选择阅读。

几天使用下来，AideRSS 确实能提高一些阅读的命中率，特别是在读流量大更新快的 blogs 的时候，比如CrunchGear，LifeHacker 等。另外读那些只输出摘要的 feeds 的时候，比如新闻类的 feeds，del.icio.us 上的 linux tag 等，我也可以根据 PostRank 快速过滤掉一些文章。

另一方面，AideRSS 对草根 blogs 不会像豆瓣九点那么“势利眼”——死盯着订阅数不放，不用去担心 PostRank 会不会把草根的声音屏蔽了的问题。PostRank 的算法中，似乎流量较少的草根们反而更“容易”拿到高 PostRank。举例子来说，我的《有备无患：为Blogger传统模板（FTP发布）添加标签云》只有4个 backlink，2条评论和2个 del.icio.us 收藏，被评到8.3分，而 LifeHacker 的《Bind Papers Together Without Staples or Clips [How To]》有39条评论，7次 del.icio.us，5次 digg，却只有5.3分。

虽然 AideRSS + Google Reader Firefox Extension 还在 private beta 阶段，虽然会拖慢 Google Reader 的响应速度（wyt：要通过 AideRSS 的服务器取数据），虽然还和 Firefox 上最流行的扩展之一 GreaseMonkey 有冲突（wyt：AideRSS 另外提供了一个 GM 脚本，实现和扩展同样的功能），它还是值得去试一试。不过，真正的结论还要等几个星期以后，看看我的 FRER 有没有因此而提高了。

有备无患：怎样评价Feed阅读效率

Feed阅读早已超过订购报纸和浏览网页，成为互联网时代获取信息的最重要的渠道之一。但随着信息的大量聚合，噪声、冗余和陈腔滥调的信息也不可避免的混杂其中，谓之“信息过载”。其实，“信息过载”也是“信息欠缺”的形式之一，后者是说绝对的信息缺乏，前者是指相对于噪声的有用信息的缺乏，即“信噪比”过低。

提高信噪比的办法有很多。比如专注于最感兴趣的feeds，删除那些不错但无关紧要的（我们不想了解整个互联网）。比如删除那些热衷于速译国外blogs 却不能自己提供内容的feeds（文字还是原汁原味的好）。又比如用标签为feeds分级，分为必读的A List，选读的B List和爱读不读的ZZ List（人工智慧还不能为我们过滤文章的时候，只能先凑合一下“工人智慧”:-）。等等。

可是还有一个问题：如果我们采取了上述这些措施，怎样才能知道“信噪比”是升高了还是降低了，怎样才能量化的评价自己的阅读效率呢？

为此我略微改变了一下自己的阅读习惯，把每一条值得一读的信息在Google Reader中打上星号，以及每隔半个月记录一次自己的feed订阅数。然后用FRER（Feed阅读效率评价）来了解自己最近的阅读效率。FRER是一个通过大多数Feed阅读器都会提供的统计数据（订阅数，已读数，收藏数和推荐数）来计算最近30天的Feed阅读效率，换言之“阅读信噪比”的计算公式。

FRER = (Sub / aSub) * (StI + ShI) / RdI * 100

说明：
    FRER - Feed Reading Efficiency Rating，Feed阅读效率评价
    Sub - Subscription，当前订阅数
    aSub - Average Subcription，历史平均订阅数
    StI - Starred Items，内向型“收藏”的文章
    ShI - Shared Items，外向型“推荐”的文章
    RdI - Read Items，所有已读的文章

举例来说，我在Google Reader上订阅的feeds共有381个，这几个月平均的订阅数是373.3个，最近30天我阅读了11246篇文中，其中被我打上星号收藏的文章有1422篇，分享出去的文章有250篇。那么通过FRER计算可以得出我最近一个月的Feed阅读效率是15.14。

南言北哲：你最想看哪些季后赛的首轮对局？（二）

半个星期之前，我还说最想看到小牛排第八挑战西部老大的西部季后赛首轮对局。半个星期之后，失去Nowitziki的小牛连输两场关键的比赛（105-118负掘金，104-114负勇士），战绩滑落到45胜28负，和掘金与勇士并列西部第七。我猜，主教练Avery Johnson多少会怀念一下小牛曾经的最好的没有之一的突破防守球员，Devin Harris，因为他们刚刚被勇士的Monta Ellis砍下30分，而本赛季之前两次对阵，Ellis总共也才拿到不过25分。NBA WHERE AMAZING HAPPENS...

Mark Cuban也许还不至于后悔交易来Jason Kidd。像这样的重量级交易，除了结果（总冠军戒指）以外似乎没有其他的评判标准。可今年六月，或者五月之后（坏笑）会怎样就很难说了。相比之下，全明星周末的另外一宗大交易的主角，Phoenix Suns的小日子却过得相当的滋润。度过了3胜6负的阵痛期之后，交易来“大仙人掌”Shaquille O'Neal的太阳9胜2负，更重要的是他们干掉过去几年萦绕在头上的噩梦——Tim Duncan和他的卫冕冠军球队San Antonio Spurs。

第二局：太阳 vs 马刺

——Steve Kerr，你究竟是天才还是蠢货，让我们第一轮就见分晓吧！

太阳和马刺比赛的精彩之处不用多说。但往年，同处上半区的太阳和马刺不得不等到第二轮以后才能碰面。而今年，神奇的07-08赛季，给了这两个冤家在第一轮解决战斗的机会。尤其在太阳在全明星周末前豪赌一把，用Shawn Marion和Marcus Banks换来了Shaquille O'Neal之后，太阳总经理Steve Kerr也立下“军令状”，“我猜，如果我成功了，我就是天才。如果没有，那么我就是蠢货。”

太阳目前49胜24负，和火箭并列西部第五，可接下来的赛程相当艰苦。今明两天背靠背战掘金，Melo将考验Marion走后留下的最大漏洞，侧翼防守。算上4月7日主场战小牛，太阳还有一趟名为“德州7日游”的车轮战等着他们，最后两场比赛是为季后赛资格而拼命的勇士和心气颇高的开拓者。在John Hollinger的季后赛预测中，太阳只有22%的机会赢得分区冠军，这也意味着他们很有可能以第五，或者第六种子的身份进入季后赛。

同样赛程艰苦的还有马刺。尽管在经历了近几年最长的四连败之后，马刺似乎已经进入了PO Mode（季后赛模式），昨天20分狂扫火箭之后已经是7连胜。不过，马刺剩下的8场比赛中，将有五支季后赛资格球队，勇士、爵士（2次）、湖人和太阳。考虑到湖人和黄蜂的赛程很轻松，加上马刺的主教练Popovich向来无视常规赛冠军的虚名，似乎马刺夺冠的机会并不大。我认为，他们很有可能排名西部第二，或者第三。

如果，太阳最终排第六而马刺排第三，那么，我们就有机会在第一轮就提前验证O'Neal的大交易是否成功以及Steve Kerr究竟是天才还是蠢货了。欢迎大家留言，说说你心目中最期待的季后赛首轮对局。