陆离斑「博」

有备无患：浏览器端缓存（基于 jQuery）

2008-07-04T21:01:00.004+08:00

最近在翻《Ajax 设计模式》，所以想把其中的一部分模式实现出来练手 jQuery，今天写了一个简单的引入 LRU 算法的浏览器端缓存（Browser Side Cache）。

浏览器端缓存用来保留服务器返回的查询结果。这种缓存是一个 Javascript 里类似映射的对象，存储成对的查询结果；查询是缓存的键（Key），服务器返回的结果是缓存的值（Value）。因此，每当浏览器需要查询服务器时，先检查缓存。如果该查询是缓存中的一个键，则与键对应的值将被当作结果，而不必再向服务器查询。

LRU （Least Recently Used）是将存储在缓存中的自上一次获取之后，最长时间未被使用的项目（Item）丢弃的一种算法。可以用两个数组（Array）来实现，其一是用来存储查询结果的键值对（Key-Value Pairs），其二是一个先进先出（FIFO）的队列，每一个新项目被塞入队列的尾部，并随着后续项目的跟进，逐渐逼近队列的头部。当队列全满时，每次向尾部塞入一个新项目，就要从头部弹出一个旧项目。而每当一个项目被缓存查询时，它会被送回到队列的尾部，这样可以确保最长时间未被使用的项目总是在开头处。

另外，还有一种常用的缓存算法，LFU （Least Frequently Used），它将自上一次获取后最少被使用的项目丢弃。

顺便一说，下面贴出的代码是由代码发芽网生产的纯 HTML。代码发芽网是一个“无需插件支持 Blog 代码高亮，支持近百种编程语言，多种配色主题支持，代码版本管理”的代码片段管理网站。因为不是由 Javascript 脚本来高亮处理，所以在 feed 里也一样可以看到效果，这一点很赞。不过，由于用处不大的 id 和 class 也包含在生成的 HTML 里，所以体积偏大。比如说下面这段代码，在删除了多余的 id 和 class，套上代码专用的 pre 和 code 标签，并将   还原成空格之后，体积可以缩小一半仅17KB（原来35KB），更适合 blog 来贴代码。

cache.js

01 function Cache(size) {
02     /* A browser side LRU cache 
03      * Author: Wu Yuntao <http://luliban.com/blog/>
04      * License: GPLv3
05      *
06      * Usage:
07      * var cache = new Cache(10);   // create a new cache object
08      * cache.put('w', 'wiki');      // put an item into cache
09      * cache.get('w');              // get the value of item with key
10      * cache.remove('w');           // remove an item with specified key
11      * cache.initialize()           // re-initialize the cache
12      * cache.size(10)               // resize the cache
13      */
14     this.initialize(size);
15 }
16 
17 Cache.prototype = {
18     initialize: function(size) {
19         /* Initialize cache.
20          * ``size`` is the number of maxmium items this cache should hold.
21          * Default is maxium integer.
22          */
23         this._keys = new Array();
24         this._items = new Array();
25         this._size = size || this._size || Number.MAX_VALUE;
26     },
27 
28     is_empty: function() {
29         /* Check if cache is empty
30          */
31         return (this._keys.length == 0 && this._items.length == 0);
32     },
33 
34     size: function(size) {
35         /* Resize cache if ``size`` is specified, or return accual size of cache.
36          */
37         if (typeof size == 'undefined') return this._keys.length;
38         return this._size = size;
39     },
40 
41     put: function(key, value) {
42         /* Put a new item into cache, if the size of cache reaches limit,
43          * cache will remove the least recently used (LRU) automatically.
44          * ``key`` of an item should be a string.
45          * ``value`` of an item could be anything, string, array or object.
46          * If ``value`` is not defined, returns null.
47          */
48         if (typeof value != 'undefined') {
49             this._keys.push(key);
50             this._items[key] = value;
51 
52             if (this._keys.length > this._size) {
53                 this.remove_least();
54             }
55         }
56         return value;
57     },
58 
59     get: function(key) {
60         /* Retrieve an item by its key and move it to the tail of cache.
61          * If the item of ``key`` does not exist, returns null.
62          */
63         if (typeof this._items[key] == 'undefined') return null;
64         var used_key = this._remove_key(key);
65         this._keys.push(used_key);
66         return this._items[key];
67     },
68 
69     remove_least: function() {
70         /* Manually remove the least recently used item. */
71         if (!this.is_empty()) this.remove(this._keys[0]);
72     },
73 
74     remove: function(key) {
75         /* Remove an item by its key.
76          * If the item of ``key`` does not exist, returns null.
77          */
78         if (typeof this._items[key] == 'undefined') return null;
79         this._remove_key(key);
80         return this._remove_value(key);
81     },
82 
83     _remove_key: function(key) {
84         /* Remove the ``key`` in ``this._keys``.
85          */
86         var i = $.inArray(key, this._keys);
87         return this._keys.splice(i, 1);
88     },
89 
90     _remove_value: function(key) {
91         /* Remove the item in ``this._items``. */
92         var value = this._items[key];
93         delete this._items[key];
94         return value;
95     }
96 
97 };

有备无患：pinyin-urlify - 根据汉字自动生成拼音 URL

2008-07-02T19:41:00.002+08:00

根据文章标题中的英语单词自动生成文章的 URL 是一个很好的体验，比如标题为“Girl's death sparks riot in China”，会被转换成“girls-death-sparks-riot-china”这样与之对应的 URL。这样既可获得 Cool URIs，又便于用户记忆，同时也有利于 SEO，Blogger 和 Wordpress 也都支持类似体验。而中文的文章标题，也可以先将其中的汉字转化为拼音后再组成相应的 URL，比如标题为“俯卧撑”，可以被转换成“fu-wo-cheng”。

pinyin-urlify 是我这几天写的能根据汉字自动生成拼音 URL 的 Python 脚本。它可以将汉字映射成有英语字母组成的拼音，和多种西方语言的字母（拉丁语、希腊语、俄语等）映射成相近的英语字母。要说明的是，汉字-拼音的映射表是从 pyzh 项目中获得，而其他西方语言的映射表则是从 Django 项目中获得，特表感谢。

pinyin-urlify 支持自定义停用词列表（stop words）和保留词列表（reserved words）。停用词列表中的单词都会被过滤，不会出现在生成的 URL 中。生成的 URL 如果和保留词列表中的某一个单词匹配，则会被替换成默认的 URL 字符串。pinyin-urlify 可以指定 URL 的最大长度。不过，如果遇到有较多汉字组成的文章标题的话，实际生成的 URL 可能会比限定的最大长度小一些。我希望能在以后修正这一点。

使用示例

>>> from urlify import urlify
>>> urlify(u'三个俯卧撑引发的血案', default='blog_post',
...        max_length=50, stop_words=[u'is', u'a', u'an'],
...        reserved_words=[u'new', u'edit'])
u'san-ge-fu-wo-cheng-yin-fa-de-xue'

欢迎大家用 svn 检出 pinyin-urlify 的副本来使用。欢迎任何意见或建议 :-)

$ svn checkout http://pinyin-urlify.googlecode.com/svn/trunk/ pinyin-urlify

有备无患：在 GitHub 上用不同的 SSH 公钥部署多个应用

2008-06-21T13:23:00.009+08:00

GitHub 是一个免费的基于 git 的开源软件仓库托管服务，包括 Ruby on Rails， Rspec，Prototype 在内的许多开源软件都在 GitHub 上架设了软件仓库。

如果你有两个或两个以上的 GitHub 仓库，并且想用不同的公钥／私钥来管理这些仓库的话，会遇到这样一个问题。当你 clone 第一个仓库的时候，git 会使用第一对公钥／私钥，这个时候仍然一切正常。可当你需要用另一对公钥／私钥来 clone 第二个仓库的时候，git 默认仍然会使用第一对公钥／私钥，然后 GitHub 就会返回一个授权错误。

要解决这个问题，首先需要在 ~/.ssh/ 目录下新建一个 config 文件，为不同的项目分别指定公钥／私钥

~/.ssh/config

Host project-1
    HostName github.com
    User git
    IdentityFile /home/wyt/.ssh/id_rsa_project_1

Host project-2
    HostName github.com
    User git
    IdentityFile /home/wyt/.ssh/id_rsa_project_2

然后用 ssh-keygen 创建对应的公钥／私钥。

$ ls -l ~/.ssh
total 24
-rw-r--r-- 1 wyt wyt  244 2008-06-21 13:18 config
-rw------- 1 wyt wyt 1675 2008-06-21 13:04 id_rsa_project_1
-rw-r--r-- 1 wyt wyt  392 2008-06-21 13:04 id_rsa_project_1.pub
-rw------- 1 wyt wyt 1675 2008-05-20 11:24 id_rsa_project_2
-rw-r--r-- 1 wyt wyt  392 2008-05-20 11:24 id_rsa_project_2.pub
-rw-r--r-- 1 wyt wyt  802 2008-05-24 22:44 known_hosts

将公钥上传到 GitHub 上之后，就可以用下面的指令 clone 相应的软件仓库了

$ git clone git@project-1:username/project-1.git
$ git clone git@project-2:username/project-2.git

参考页面

悠言悠闲：Firefox 下载日

2008-06-17T23:59:00.002+08:00

Firefox 3正式下载时间为北京时间六月十八日凌晨一点。下载日活动届时开始，请在北京时间六月十九日凌晨一点之前下载Firefox 3。

有备无患：增强豆瓣收藏对话框的 Greasemonkey 脚本

2008-05-27T21:00:00.015+08:00

经常使用 del.icio.us 的人，一定也很熟悉 del.icio.us 的跟随键盘输入自动提示标签（Tag Suggest）的功能。它为用户管理大量的标签带来方便，比如不必去费神记忆单词的拼写，避免为同一语义定义多个标签等。这是靠我们的大脑来记忆管理，或者类似豆瓣只提供10个最常用的标签，不能做到的。

这个 Greasemonkey 脚本的主要功能，是为豆瓣收藏对话框提供类似 del.icio.us 的标签提示功能。另外还重新布置了读过／在读／想读等按钮的布局，并添加了删除收藏的按钮。

目前脚本的版本为0.1，欢迎试用。有什么建议或意见，欢迎留言:-)

功能

类似 del.icio.us 的随输入自动提示标签（Tag Suggest）
重新安排了读过／在读／想读等按钮的布局，保证 UI 路径的一致性
增加了删除收藏的按钮

下载

2008-05-31 UPDATE

脚本更新至0.2，有下列更新

增加了对个人收藏页，标签页，豆瓣猜，TOP250等页面中的收藏对话框的支持
修正了之前脚本中已知的 BUG

有备无患：在 Gentoo 上部署 Git + Gitosis 服务器的笔记

2008-05-19T22:02:00.007+08:00

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的分布式版本控制软件（Distributed SCM）。Git 汲取了 Torvalds 在维护大型的分布式项目开发方面的经验和对文件系统性能的丰富知识，正如其文档所描述的，“是一个快速、可扩展的分布式版本控制系统，它具有极为丰富的命令集，对内部系统提供了高级操作和完全访问。”目前，Linux 内核、X.org 服务器和 Ruby on Rails 等开源项目的版本控制系统都已经切换到 Git。

Gitosis 是 Tommi Virtanen 为了更方便和安全的辅助 Git 架设和管理软件版本库 (Software Repository) 而开发的工具软件。虽然 Git 本身也提供 git-daemon 以架设版本库，但在用户访问控制上做的并不严格。而 Gitosis 允许单个用户帐号管理多个版本库，使用 SSH keys 管理用户认证，不需要 shell 帐号就可以解决多用户访问集中版本库的问题。

需要说明的是，我使用的 Gitosis 是 robbat2 为了部署新的 Gentoo Overlays 而开发的 Gentoo 分支版本 (Gentoo Fork Version)，和上游版本 (Origin Upstream Version) 相比有如下不同：

支持 git+ssh://HOST/REPO 风格的相对路径；
支持以命令行参数方式导入 keys，如 gitosis-init --adminkey=FILE --adminname=STRING；
智能处理 SSH keys，支持 SSH1 和 SSH2 keys；
将上游版本默认的目录权限 0750 更改为 0755，以便用 nobody:nobody 运行 git-daemon。

这篇文章详细记录了我在本地安装和部署 Git + Gitosis 的过程和遇到的问题，希望为大家提供一些参考。欢迎 Fix-Me :-)

安装 Git + Gitosis

安装 git 和 gitosis-gentoo。安装完后，Gentoo 会自动添加 git 用户和组，并将版本库的主目录设为 /var/spool/gitosis/repositories。

# echo ">=dev-util/git-1.5.5" >> /etc/portage/package.keywords
# echo ">=dev-util/gitosis-gentoo-0.2_p20080203" >> /etc/portage/package.keywords
# emerge -av git gitosis-gentoo

如果你的主机上没有装 SSH 的话，还要安装 openssh，以及 keychain 用来管理 ssh-agents（可选）。

# emerge -av openssh keychain

安装完后，启动 sshd，并加入默认启动。

# /etc/init.d/sshd start
# rc-update add sshd default

配置 Gitosis

首先生成一个 ssh key。

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/wyt/.ssh/id_rsa):（回车）
Created directory '/home/wyt/.ssh'.
Enter passphrase (empty for no passphrase):（直接回车）
Enter same passphrase again: （直接回车）
Your identification has been saved in /home/wyt/.ssh/id_rsa.
Your public key has been saved in /home/wyt/.ssh/id_rsa.pub.
The key fingerprint is:
dd:33:cc:99:33:00:66:77:ff:00:bb:99:00:22:55:88 wyt@gentoo

我把 ssh key 保存在默认的 ~/.ssh/id_rsa，你也可以选择其他地方。接下来把 id_rsa.pub 上传到服务器。其中的root@gentoo，root 是根用户名，gentoo 是主机名，可以从 /etc/conf.d/hostname 得知。

$ cat /etc/conf.d/hostname
hostname="gentoo"
$ scp ~/.ssh/id_rsa.pub root@gentoo:
Password: （输入 root 帐户密码）
id_rsa.pub                                    100%  392     0.4KB/s   00:00

上传完毕后，用 gitosis-init 初始化版本库。

$ sudo su -
# sudo -H -u git gitosis-init < ~/id_rsa.pub
Initialized empty Git repository in ./
Reinitialized existing Git repository in ./

上面第二条命令中，-u 表示 sudo 将切换至 git 用户，-H 表示 sudo 将切换至该用户的主目录。初始化完成后，将创建一个名为 gitosis-admin 的版本库，用于 Gitosis 的设置和管理。你需要把它 clone 到相应目录。

$ mkdir git
$ cd git
$  git clone git@gentoo:gitosis-admin.git
$ cd gitosis-admin
$ ls -lh
-rw-r--r-- 1 wyt wyt 80 2008-05-19 00:10 gitosis.conf
drwxr-xr-x 2 wyt wyt 80 2008-05-19 00:10 keydir

gitosis-admin 目录下有一个 gitosis.conf 文件和一个 keydir 目录。gitosis.conf 用来保存项目，用户和权限等版本库配置，而 keydir 用来保存用户的 ssh key。因为 gitosis-admin 也是 Git 的版本库，所以在修改完配置之后，只需要简单的 commit & push，就可以很快很方便的更新服务器的配置了。接下来就用 Gitosis 创建新版本库和添加授权用户。

创建新的版本库

gitosis.conf 里有 gitosis-admin 的默认配置，只要依样画葫芦创建一个新版本库即可。下面举例创建 local_test 版本库，把下面这段 code 追加到 gitosis.conf。

gitosis.conf

[group localteam]
writable = local_test
members = wyt@gentoo

这段 code 定义了新的版本库，包括开发小组的名称 "localteam"，版本库的名称 "local_test"，以及拥有写权限的小组成员 "wyt@gentoo"。接下来把新的版本库所配置 commit & push 到服务器上。

$ git commit -a -m "添加新的版本库 local_test"
$ git push

接下来在本地创建版本库，然后将其上传到服务器

$ mkdir local_test
$ cd local_test
$ git init
$ git remote add origin git@gentoo:local_test.git

# add & commit 一些文件，然后……

$ git push origin master:refs/heads/master

添加成员用户

添加版本库的成员用户的步骤可以分为两步。一是将用户的 SSH 公钥复制到 keydir/ 目录。二是编辑 gitosis.conf，将这些用户的名字加入 "members"。

$ cd gitosis-admin/
$ cp ~/zhangsan@gentoo.pub keydir/
$ cp ~/lisi@gentoo.pub keydir/
$ git add keydir/zhangsan@gentoo.pub keydir/lisi@gentoo.pub

编辑 gitosis.conf

gitosis.conf

[group localteam]
writable = local_test
members = wyt@gentoo zhangsan@gentoo lisi@gentoo

接下来，将设置提交到服务器

$ git commit -a -m '添加 local_test 版本库成员：张三、李四'
$ git push

选择需要输出的版本库

输出所有版本库

编辑 /etc/conf.d/git-daemon

GITDAEMON_OPTS="--syslog --base-path=/var/spool/gitosis/repositories/ --export-all"

选择输出版本库

编辑 /etc/conf.d/git-daemon

GITDAEMON_OPTS="--syslog --base-path=/var/spool/gitosis/repositories/"

然后在每个选择输出的版本库目录中，添加一个 git-daemon-export-ok 文件

$ sudo touch /var/spool/gitosis/repositories/local_test.git/git-daemon-export-ok

启动 git-daemon

# /etc/init.d/git-daemon start
# rc-update add git-daemon default

如果一切正常的话，我们应该已经大功告成，完成部署 Git + Gitosis 服务器了。现在可以试一下远程 clone。

$ git clone git://169.254.64.95/local_test.git

参考链接

2008-05-20 UPDATE

clone 只读版本库：

$ git clone git://169.254.64.95/local_test.git

clone 可读写版本库：

$ git clone git+ssh://git@169.254.64.95/local_test.git

创建新的可读写版本库：

$ git remote add origin git+ssh://git@169.254.64.95/new_local_test.git
$ git push origin master:refs/heads/master

有备无患：绕过 GHS 用自定义域名发布 Blogger

2008-05-10T16:24:00.009+08:00

2007年1月，Google Blogger 的自定义域名功能推出不到一个星期，就被 GFW 给废了。原因就是 GFW 隔断了国内用户对 Google 的免费主机托管服务 ghs.google.com 的访问。

今天试着将 App Engine 应用部署到自己域名的时候，发现 App Engine 不需要将 CNAME record 指向 ghs.google.com，从而可以避开 GFW。而同样的方法也可以适用于 Blogger。方法如下：

把 Blogger 的发布方式切换成“自定义域名（Custom Domain）”。在“你的域名（Your Domain）”一栏中填上域名，比如，py.thonic.org。保存设置（Save Settings）。
在你的域名注册商那里，修改域名（thonic.org）的 DNS 设置。为子域名（py）添加一条 A record，指向下面四个 IP 地址的其中之一。举例来说，就是添加这样一条记录：py.thonic.org 86400 IN A 216.239.34.21。
- 216.239.32.21
- 216.239.34.21
- 216.239.36.21
- 216.239.38.21

DNS 设置的改动需要一段时间来完成，一般不会超过24小时。这样就可以重新使用 Blogger 的自定义域名功能了，只是，这次又可以持续多久呢？

2008-06-26 UPDATE

我把上面的 IP 绑定到自己的域名了，ghs.luliban.com。以后也可以像 ghs.google.com 一样，添加一条 CNAME 记录到 ghs.luliban.com 来绑定 Google Blogger 或者 Google Apps 了。

有备无患：在 Google App Engine上应用豆瓣 API 的授权认证

2008-05-09T11:01:00.008+08:00

上次说到了在 App Engine 上应用的豆瓣的 Python 客户端，但是那个版本（0.1.1）的客户端并没有包括 OAuth 授权认证的功能。如果想要让用户授权，以访问那些受保护的资源，以及添加、修改或删除用户的收藏，需要从豆瓣 Python 客户端的 SVN 中获取最新的开发版本（r22）。据豆瓣的开发人员 hongqn 说，OAuth Client 基本开发完毕，已经进入内测 bug 的阶段。

和 GData Python 客户端一样，开发版本的 OAuth Client 也是用 Python 自带的 httplib 模块来处理 HTTP 请求，所以原始的客户端不能直接在 App Engine 上使用，必须先将 httplib 替换成 urlfetch。现在只需要修改两个函数，但是豆瓣如果能像 GData Python 客户端一样把使用 httplib 的部分封装起来，甚至提供一个使用 urlfetch 的替换模块就更好了，希望豆瓣能采纳这个建议。下面是具体步骤，如果有什么问题，还请留言告知。

1，从 trunk 中 checkout 最新的豆瓣 Python 客户端开发版本

$ svn co http://douban-python.googlecode.com/svn/trunk/ douban-python/

2，修改客户端的 OAuth Client

$ cp douban-python/douban ~/doupye/douban -rf
$ cd ~/doupye/douban/
$ gvim client.py

client.py

# import httplib
from google.appengine.api import urlfetch

class OAuthClient:
    ... ...
    def fetch_token(self, oauth_request):
        # 被注释掉的是原来使用 httplib 的部分
        # connection = httplib.HTTPConnection("%s:%d" % (self.server, 80))
        # connection.request('GET', oauth_request.http_url,
        #     headers=oauth_request.to_header())
        # response = connection.getresponse()
        # r = response.read()
        url = oauth_request.http_url
        result = urlfetch.fetch(url, headers=oauth_request.to_header())
        r = result.content
        ... ...

    def access_resource(self, method, url, body=None):
        ... ...
        # connection = httplib.HTTPConnection("%s:%d" % (self.server, 80))
        # connection.request(method, url, body=body,
        #     headers=headers)
        # return connection.getresponse()
        result = urlfetch.fetch(url, payload=body, method=method, headers=headers)
        return result.content

3，使用 OAuth 授权的过程如下，在 App Engine SDK 提供的控制台（Interactive Console）中运行：

from douban.client import OAuthClient

client = OAuthClient(key=MY_API_KEY, secret=MY_SECRET)

# 获取未授权的Request Token
key, secret = client.get_request_token()
print key, secret
>>> c14023315549fe3743c17993ff4dfaa5 91af6245103ec3b7

# 获取请求用户授权的页面的 URL
url = client.get_authorization_url(key, secret)
print url
>>> http://www.douban.com/service/auth/authorize?oauth_token=a9e487ac36e0ba9efdba970534a22fce

# 将 URL 复制到浏览器中，用户可以选择同意或者拒绝授权

# 用户完成授权后，使用授权后的 Request Token 换取 Access Token
key, secret = client.get_access_token(key, secret)
if key:
    # 使用 Access Token 登录
    login = client.login(key, secret)
    print login
>>> True

# 访问受保护资源
collections = client.access_resource(method='GET',
    url='http://api.douban.com/people/wyt/collection?cat=book')
for entry in collections.entry:
    print entry.title.text
>>>
听过 人として軸がぶれている
想读 Antipatterns
想读 新企业的起源与演进
看过 .hack//G.U. Trilogy
想听 ワイルドストロベリー
在听 The Flower Book
在听 E=MC²
听过 越长大越孤单
想读 Investing 101
想读 The Ecology of Commerce

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

2008-04-22T20:34:00.005+08:00

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

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

2008-04-21T17:27:00.009+08:00

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/

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

2008-04-16T20:14:00.010+08:00

以前写过输出单个用户的友邻广播 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 换成更快的库，然后用两个线程分别来抓取和分析网页，这样效率会高一些。

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

2008-04-12T22:35:00.006+08:00

昨天火箭大胜太阳之后，在常规赛季只剩下最后三场的情况下，有四支球队距离西部冠军只有少于等于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敢死队

2008-04-11T15:17:00.009+08:00

原来平时那么爱用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 辅助阅读

2008-04-09T01:37:00.005+08:00

前几天我计算出自己的 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阅读效率

2008-04-05T17:04:00.008+08:00

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。

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

2008-04-01T03:00:00.005+08:00

半个星期之前，我还说最想看到小牛排第八挑战西部老大的西部季后赛首轮对局。半个星期之后，失去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究竟是天才还是蠢货了。欢迎大家留言，说说你心目中最期待的季后赛首轮对局。

有备无患：用Vista字体配置Sun JDK 1.6

2008-03-31T23:19:00.003+08:00

也许是升级JDK的时候，把原本配置好的fontconfig.properties给冲掉了，今天emerge OmegaT之后，发现“方框字”又重现江湖。重新在Google上搜了一番，用Bitstream Vera的英文字体，和Windoze Vista的繁日韩字体——正黑，Meiryo和Malgun，重写了fontconfig.properties，直接复制到/opt/sun-jdk-1.6.x/jre/lib/即可。

fontconfig.properties：

# Version

version=1

# Component Font Mappings

allfonts.chinese-gb18030=-microsoft-microsoft jhenghei-medium-r-normal--0-0-0-0-p-0-gb18030.2000-0
allfonts.chinese-gb18030.motif=-microsoft-microsoft jhenghei-medium-r-normal--0-0-0-0-p-0-gb18030.2000-0
allfonts.chinese-big5=-microsoft-microsoft jhenghei-medium-r-normal--0-0-0-0-p-0-gb18030.2000-0
allfonts.chinese-big5.motif=-microsoft-microsoft jhenghei-medium-r-normal--0-0-0-0-p-0-gb18030.2000-0
allfonts.lucida=-bitstream-bitstream vera sans-medium-r-normal--0-0-0-0-p-0-iso8859-1

serif.plain.japanese-x0208=-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0
serif.plain.korean=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
serif.plain.korean.motif=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
serif.plain.latin-1=-bitstream-bitstream vera serif-medium-r-normal--0-0-0-0-p-0-iso8859-1
serif.plain.latin-1.motif=-bitstream-bitstream vera serif-medium-r-normal--0-0-0-0-p-0-iso8859-1

serif.bold.japanese-x0208=-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0
serif.bold.korean=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
serif.bold.korean.motif=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
serif.bold.latin-1=-bitstream-bitstream vera serif-bold-r-normal--0-0-0-0-p-0-iso8859-1
serif.bold.latin-1.motif=-bitstream-bitstream vera serif-bold-r-normal--0-0-0-0-p-0-iso8859-1

serif.italic.japanese-x0208=-microsoft-meiryo-medium-i-normal--0-0-0-0-p-0-jisx0208.1990-0
serif.italic.korean=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
serif.italic.korean.motif=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
serif.italic.latin-1=-bitstream-bitstream vera serif-medium-i-normal--0-0-0-0-p-0-iso8859-1
serif.italic.latin-1.motif=-bitstream-bitstream vera serif-medium-i-normal--0-0-0-0-p-0-iso8859-1

serif.bolditalic.japanese-x0208=-microsoft-meiryo-bold-i-normal--0-0-0-0-p-0-jisx0208.1990-0
serif.bolditalic.korean=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
serif.bolditalic.korean.motif=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
serif.bolditalic.latin-1=-bitstream-bitstream vera serif-bold-i-normal--0-0-0-0-p-0-iso8859-1
serif.bolditalic.latin-1.motif=-bitstream-bitstream vera serif-bold-i-normal--0-0-0-0-p-0-iso8859-1

sansserif.plain.japanese-x0208=-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0
sansserif.plain.korean=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
sansserif.plain.korean.motif=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
sansserif.plain.latin-1=-bitstream-bitstream vera sans-medium-r-normal--0-0-0-0-p-0-iso8859-1
sansserif.plain.latin-1.motif=-bitstream-bitstream vera sans-medium-r-normal--0-0-0-0-p-0-iso8859-1

sansserif.bold.japanese-x0208=-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0
sansserif.bold.korean=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
sansserif.bold.korean.motif=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
sansserif.bold.latin-1=-bitstream-bitstream vera sans-bold-r-normal--0-0-0-0-p-0-iso8859-1
sansserif.bold.latin-1.motif=-bitstream-bitstream vera sans-bold-r-normal--0-0-0-0-p-0-iso8859-1

sansserif.italic.japanese-x0208=-microsoft-meiryo-medium-i-normal--0-0-0-0-p-0-jisx0208.1990-0
sansserif.italic.korean=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
sansserif.italic.korean.motif=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
sansserif.italic.latin-1=-bitstream-bitstream vera sans-medium-o-normal--0-0-0-0-p-0-iso8859-1
sansserif.italic.latin-1.motif=-bitstream-bitstream vera sans-medium-o-normal--0-0-0-0-p-0-iso8859-1

sansserif.bolditalic.japanese-x0208=-microsoft-meiryo-bold-i-normal--0-0-0-0-p-0-jisx0208.1990-0
sansserif.bolditalic.korean=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
sansserif.bolditalic.korean.motif=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
sansserif.bolditalic.latin-1=-bitstream-bitstream vera sans-bold-o-normal--0-0-0-0-p-0-iso8859-1
sansserif.bolditalic.latin-1.motif=-bitstream-bitstream vera sans-bold-o-normal--0-0-0-0-p-0-iso8859-1

monospaced.plain.japanese-x0208=-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0
monospaced.plain.korean=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
monospaced.plain.korean.motif=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
monospaced.plain.latin-1=-bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-1
monospaced.plain.latin-1.motif=-bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-1

monospaced.bold.japanese-x0208=-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0
monospaced.bold.korean=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
monospaced.bold.korean.motif=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
monospaced.bold.latin-1=-bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-1
monospaced.bold.latin-1.motif=-bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-1

monospaced.italic.japanese-x0208=-microsoft-meiryo-medium-i-normal--0-0-0-0-p-0-jisx0208.1990-0
monospaced.italic.korean=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
monospaced.italic.korean.motif=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
monospaced.italic.latin-1=-bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso8859-1
monospaced.italic.latin-1.motif=-bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso8859-1

monospaced.bolditalic.japanese-x0208=-microsoft-meiryo-bold-i-normal--0-0-0-0-p-0-jisx0208.1990-0
monospaced.bolditalic.korean=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
monospaced.bolditalic.korean.motif=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
monospaced.bolditalic.latin-1=-bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso8859-1
monospaced.bolditalic.latin-1.motif=-bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso8859-1

dialog.plain.japanese-x0208=-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0
dialog.plain.korean=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
dialog.plain.korean.motif=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
dialog.plain.latin-1=bitstream-bitstream vera sans-medium-r-normal--0-0-0-0-p-0-iso8859-1
dialog.plain.latin-1.motif=bitstream-bitstream vera sans-medium-r-normal--0-0-0-0-p-0-iso8859-1

dialog.bold.japanese-x0208=-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0
dialog.bold.korean=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
dialog.bold.korean.motif=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
dialog.bold.latin-1=itstream-bitstream vera sans-bold-r-normal--0-0-0-0-p-0-iso8859-1
dialog.bold.latin-1.motif=itstream-bitstream vera sans-bold-r-normal--0-0-0-0-p-0-iso8859-1

dialog.italic.japanese-x0208=-microsoft-meiryo-medium-i-normal--0-0-0-0-p-0-jisx0208.1990-0
dialog.italic.korean=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
dialog.italic.korean.motif=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
dialog.italic.latin-1=-bitstream-bitstream vera sans-medium-o-normal--0-0-0-0-p-0-iso8859-1
dialog.italic.latin-1.motif=-bitstream-bitstream vera sans-medium-o-normal--0-0-0-0-p-0-iso8859-1

dialog.bolditalic.japanese-x0208=-microsoft-meiryo-bold-i-normal--0-0-0-0-p-0-jisx0208.1990-0
dialog.bolditalic.korean=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
dialog.bolditalic.korean.motif=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
dialog.bolditalic.latin-1=-bitstream-bitstream vera sans-bold-o-normal--0-0-0-0-p-0-iso8859-1
dialog.bolditalic.latin-1.motif=-bitstream-bitstream vera sans-bold-o-normal--0-0-0-0-p-0-iso8859-1

dialoginput.plain.japanese-x0208=-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0
dialoginput.plain.korean=-microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
dialoginput.plain.korean.motif=--microsoft-malgun gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1
dialoginput.plain.latin-1=-bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-1
dialoginput.plain.latin-1.motif=-bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-1

dialoginput.bold.japanese-x0208=-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0
dialoginput.bold.korean=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
dialoginput.bold.korean.motif=-microsoft-malgun gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1
dialoginput.bold.latin-1=-bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-1
dialoginput.bold.latin-1.motif=-bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-1

dialoginput.italic.japanese-x0208=-microsoft-meiryo-medium-i-normal--0-0-0-0-p-0-jisx0208.1990-0
dialoginput.italic.korean=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
dialoginput.italic.korean.motif=-microsoft-malgun gothic-medium-i-normal--0-0-0-0-p-0-iso10646-1
dialoginput.italic.latin-1=-bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso8859-1
dialoginput.italic.latin-1.motif=-bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso8859-1

dialoginput.bolditalic.japanese-x0208=-microsoft-meiryo-bold-i-normal--0-0-0-0-p-0-jisx0208.1990-0
dialoginput.bolditalic.korean=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
dialoginput.bolditalic.korean.motif=-microsoft-malgun gothic-bold-i-normal--0-0-0-0-p-0-iso10646-1
dialoginput.bolditalic.latin-1=-bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso8859-1
dialoginput.bolditalic.latin-1.motif=-bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso8859-1

# Search Sequences

sequence.allfonts=latin-1
sequence.allfonts.Big5=latin-1,chinese-big5
sequence.allfonts.GB2312=latin-1,chinese-gb18030
sequence.allfonts.x-euc-jp-linux=latin-1,japanese-x0208
sequence.allfonts.EUC-KR=latin-1,korean
sequence.allfonts.GB18030=latin-1,chinese-gb18030
sequence.fallback=lucida,chinese-big5,chinese-gb18030,japanese-x0208,korean

# Exclusion Ranges

exclusion.japanese-x0208=0390-03d6,2200-22ef,2701-27be

# Font File Names
filename.-microsoft-microsoft_jhenghei-medium-r-normal--0-0-0-0-p-0-gb18030.2000-0=/usr/share/fonts/TTF/msjh.ttf
filename.-microsoft-microsoft_jhenghei-bold-r-normal--0-0-0-0-p-0-gb18030.2000-0=/usr/share/fonts/TTF/msjhbd.ttf
filename.-microsoft-meiryo-medium-r-normal--0-0-0-0-p-0-jisx0208.1990-0=/usr/share/fonts/TTF/meiryo.ttc
filename.-microsoft-meiryo-bold-r-normal--0-0-0-0-p-0-jisx0208.1990-0=/usr/share/fonts/TTF/meiryob.ttc
filename.-microsoft-malgun_gothic-medium-r-normal--0-0-0-0-p-0-iso10646-1=/usr/share/fonts/TTF/malgun.ttf
filename.-microsoft-malgun_gothic-bold-r-normal--0-0-0-0-p-0-iso10646-1=/usr/share/fonts/TTF/malgunbd.ttf

filename.-bitstream-bitstream_vera_sans-medium-r-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/Vera.ttf 
filename.-bitstream-bitstream_vera_sans-bold-o-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraBI.ttf 
filename.-bitstream-bitstream_vera_sans-bold-r-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraBd.ttf 
filename.-bitstream-bitstream_vera_sans-medium-o-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraIt.ttf 
filename.-bitstream-bitstream_vera_sans_mono-bold-o-normal--0-0-0-0-m-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraMoBI.ttf 
filename.-bitstream-bitstream_vera_sans_mono-bold-r-normal--0-0-0-0-m-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraMoBd.ttf 
filename.-bitstream-bitstream_vera_sans_mono-medium-o-normal--0-0-0-0-m-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraMoIt.ttf 
filename.-bitstream-bitstream_vera_sans_mono-medium-r-normal--0-0-0-0-m-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraMono.ttf 
filename.-bitstream-bitstream_vera_serif-medium-r-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraSe.ttf 
filename.-bitstream-bitstream_vera_serif-bold-r-normal--0-0-0-0-p-0-iso8859-1=/usr/share/fonts/ttf-bitstream-vera/VeraSeBd.ttf 

# AWT X11 font paths

awtfontpath.latin-1=/usr/share/fonts/ttf-bitstream-vera
awtfontpath.chinese-big5=/usr/share/fonts/TTF
awtfontpath.chinese-gb18030=/usr/share/fonts/TTF
awtfontpath.japanese-x0208=/usr/share/fonts/TTF
awtfontpath.korean=/usr/share/fonts/TTF

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

2008-03-27T03:02:00.006+08:00

狂野的西部。每个真－NBA球迷都说，这是二十年来最好看的常规赛季，可对身在其中的教练和球员们就不是那么一回事了。正徘徊于鬼门关口的掘金主帅 George Karl把它称作“哈雷彗星年”，“这种情况可能每99年才能遇到一次。我只是想知道为什么霉运会落在自己头上呢。”

掘金战绩为目前43胜28负，仅落后勇士（43胜27负）半个胜场，排名西部第九。他们还有两场和勇士的比赛。所以，机会仍然掌握在他们自己手中。只是西部球队的官子阶段无比惨烈，很有可能有一只球队会达到50胜，或48胜却被挡在大门之外。

这样激烈的常规赛，不禁让我们更加期待季后赛的到来，让我们数数看哪些球队的捉对厮杀最值得期待？

第一局：小牛 vs 湖人

——去年我们被“黑八”了，今年我们要缔造自己的“黑八神话”

刚才说了掘金和勇士，其实还有一只球队也在悬崖边，达拉斯小牛。小牛现在45胜26负，领先勇士一个半胜场，排名西部第七。

可在全明星周末之前，小牛35胜18负，高居西部第三。一夜之间，联盟顶级控卫Jason Kidd重回达拉斯，风云突变，小牛18战仅10胜，面对季后赛球队8战全负。更糟糕的是，他们在和马刺的比赛中失去了主将Dirk Nowitziki。而在Nowitziki可能缺席的两周时间里，小牛赛程并不轻松，他们将先后挑战勇士（2次），掘金，湖人和太阳，稍有不慎小牛可能会落到西部第八。

如果他们最终以第八顺位进入季后赛，那会变得非常有意思。去年，Nowitziki捧得常规赛MVP的奖杯，率领球队打出联盟最佳战绩，但是小牛却在第一轮被勇士4比2击败，一切的荣耀化成了新世纪第一个“黑八神话”的背景。而今年，他们将很有可能会碰到湖人或者黄蜂，以及今年的两个常规赛MVP的最热门人选Kobe Bryant和Chris Paul。

你明白我的意思了吧：去年被“黑八”的常规赛MVP今年将尝试“黑八”今年的常规赛MVP候选。这像绕口令。另外我建议，如果David Stern犹豫不决于把常规赛MVP颁给谁，Kobe or Paul，不如给和小牛对阵的那位，这样也许会创造另一个被“黑八”的常规赛MVP，hoho。

如果在湖人和黄蜂之间，为小牛挑一个季后赛首轮的对手，我更想选湖人。（wyt：这是不是暗示Kobe应该是MVP？呵呵，I have no idea...）

本赛季至今小牛和湖人的三场比赛都异常激烈。在一月份的一场比赛中，小牛凭借第三节的高潮以112比 105战胜了湖人。在Kidd交易完成后的两场比赛中，其中一场打成加时湖人以108比104侥幸取胜，而另一场小牛在落后25分的困境下奋起直追，但最终以100比102遗憾告负。

除了比赛精彩以外，教练的斗智也是经典系列赛不可缺少的一部分。

在去年的季后赛首轮对阵自家师傅Don Nelson的时候，小牛的主教练Avery Johnson排出了怪阵，他将常规赛轮转阵容的两大中锋Erick Dampier和DeSagana Diop死死摁在板凳上，试图以Nowitziki为中锋的小个阵容对抗勇士的速度，而结果就是小牛还是输了。但小牛换走Diop和Devin Harris换来Kidd，看来将在小个阵容上越走越远。

但湖人的Phil Jackson可能是全联盟最不怕所谓的“小个阵容”的主教练，自从2005年Jackson重回湖人，他对勇士队取得了10胜2负，包括Don Nelson作为主教练的6胜2负。“这些年我与Nelson对阵，他总想抛出错位进攻的法宝。”Jackson说，“他总想让你排出小个阵容跟他的小个阵容比赛。这些年每当我遇到他，我总是告诉自己千万不能这样做。很多教练陷入其中，那就像一个蜘蛛网让你陷进去。事实上如果你排出5个小个子，你的进攻会有麻烦。”

所以，今年季后赛首轮我最期待的对局之一，就是达拉斯小牛(8) vs 洛杉矶湖人(1)。欢迎大家留言，说说你心目中最期待的季后赛首轮对局。
请继续阅读《你最想看哪些季后赛首轮的对局？（二）》