Luliban blog

有备无患：一个 jQuery 的时间选择插件

noreply@blogger.com (wyt) — Tue, 05 Aug 2008 22:29:59 -0500

Yet another jQuery time picker plugin. Google 上兜了一圈，没找到中意的时间选择（Time Picker）插件，于是自己写了一个。timepicker 是一个弹出式的对话框，分为上下两个部分，上半部分是可以分别设定时分秒的计数器，下半部分提供一些常用的时间选项，比如“Now”，“Noon”，“8 p.m.”等。通过聚焦（focus）到相应的 input 控件，可以激活 timepicker。选择好时间后，点击对话框底部的 Close 按钮会将结果保存到 input 控件中，而点击 Clear 按钮会清除 input 控件中已存的时间。键盘上的 Tab 键和 ESC 键也有与之对应的功能。

这是我的第一个 jQuery 插件，欢迎大家使用，我也会继续完善这个插件。如果有任何的 Bug，建议和意见，欢迎在文章后留言，或者 Email 给我，或者在插件的主页写下你的评论。:-)

使用方法

$('#time-picker').timepicker();

截图

演示

演示网址

下载

你可以选择下载压缩档。

或者用 Git 从架设在 GitHub 的软件仓库中检出源代码使用。

$ git clone git://github.com/wuyuntao/timepicker.git

有备无患：Google Reader 风的豆瓣广播 widget

noreply@blogger.com (wyt) — Sun, 03 Aug 2008 22:47:20 -0500

最近，豆瓣连续发布了几个重要的 API 更新，包括了备受期待的友邻和广播相关的接口。特别是广播的 API，自从用豆瓣广播取代了 Twitter 当作吐口水的工具之后，我一直期待广播也有像 TwitterFox 一样的客户端，有个 widget 可以在 blog 上显示最近的状态，而这些都是要以广播的 API 为基础的。

言归正传，我写了一个类似 Google Reader 的分享阅读剪辑（Shared Item Clips）风格的豆瓣广播 widget，可以放在 blog 的侧边栏。使用的方法很简单，只需要将下面这段代码插入到你的 blog 模板中。（wyt：如果不知道怎么操作的话，可以参考豆瓣秀指南。）

<script type="text/javascript" src="http://luliban.com/scripts/miniblog.js?username=wyt&amp;maxresults=16&amp;style=blue"></script>

注意上面代码中粗体的部分，首先我们要将``wyt``换成自己的用户名；``maxresults``为 widget 显示的广播条数（最大值为50，默认为10，可以省略）；``style``表示 widget 的配色，和 Google Reader 分享阅读的配色基本一致，包括：black、blue、gray、green、khaki、pink、slate 和 none。默认为 green，如果输入的 style 不在上述配色中，则返回 none。none 为不带任何 style 的原始 HTML，适合希望自定义广播风格的 blogger。

最终效果如下图。想看看实物 demo 的话，可以点击这里。要说明的是，看得到漂亮的圆角效果的只有 Firefox 用户（wyt：这也是 Google Reader 的风格之一，:p），IE、Opera 和 Safari 用户对不住了。如果有任何的建议或意见，欢迎留言 :-)

有备无患：在 Django 上使用 reCAPTCHA 生成验证码

noreply@blogger.com (wyt) — Fri, 18 Jul 2008 03:47:54 -0500

reCAPTCHA 是由 CAPTCHA 的原作者，也是人类计算学（Human Computation）的专家 Luis von Ahn 所设计一个免费的 anti-bot 服务，它在随机提取的单词上加上一些扭曲和可阻碍电脑自动识别的噪声，以利用人类远强于电脑的图形识别能力来检查屏幕前坐着的是人类，还是 bot 或自动脚本。因此，reCAPTCHA 经常被用于生成网站注册或者文章评论的验证码。

除此之外，reCAPTCHA 还有一项非常公益的设计。虽然 OCR （全称 Optical Character Recognitio，中译光学字元识别）早已被投入使用，但是对那些印刷模糊或分辨度不足的实体书籍而言，OCR 的识别率难说完美。而 reCAPTCHA 将这些上无法由电脑自动识别的单词扫描下来，以图片的形式存入数据库，并在网络上以验证码（CAPTCHA）的形式交由人类来破译，而破译的结果将被用于帮助世界上的实体书加快数字化的进程。

你可能会问，既然电脑无法识别这些单词，那么 reCAPTCHA 系统又怎么知道用户填写的是正确的验证码呢？reCAPTCHA 的网站上有详细的解释。

一个不能被 OCR 正确识别的新单词，总是会和另一个已知答案的单词一起提交给用户。接下来用户需要同时识别这两个单词。如果用户正确识别出其中已知答案的那个单词，系统即假设用户所识别出的未知答案的新单词也可能是正确的。如果其他的用户也识别出相同的答案，系统则逐步提高这种可能性。最终当这种可能性超过某个阈值时，系统就可以将其认作已知答案的单词了。

言归正传，reCAPTCHA 有丰富的 API，包括对 PHP、JAVA、Ruby，自然还有 Python 的支持。如果要在 Django 上使用 reCAPTCHA，我们可以从 PyPI 下载 reCAPTCHA 的 Python 客户端，或者直接用 easy_install 安装。

# easy_install recaptcha-client

不知道为什么，虽然安装成功了，但是我不能导入 recaptcha 模块（wyt：import captcha 或 import recaptcha 都没有用，哪位如果顺利导入过的话，能不能分享一下你的经验呢？先谢了），所以我是把 egg 中的脚本直接复制到我的 Django 项目目录下了。

接下来，我们需要在 reCAPTCHA 注册并申请一对公钥／私钥，并将其保存在 settings.py 中。

settings.py

1 # reCAPTCHA keys
2 RECAPTCHA_PUBLIC_KEY = "6LdqgAIAAAUSHDmo4IIBmsjUsduAUMUoBDZc3J_T"
3 RECAPTCHA_PRIVATE_KEY = "6LdqgAIAAbjsJKLbj2KOjPO6D4isfJ_AzLSO_256"

然后，我们要为注册表单添加验证码了。在 Django Snippets 上，oggy 已经将 reCAPTCHA 抽象成一个 RecaptchaForm 类，所以我们只要让注册表单（Registration Form）继承这个类，就可以为注册表单添加验证码的功能了。由于 Django newform 默认是根据 field 的定义顺序来生成表单，所以在继承 RecaptchaForm 的时候，也应该把它放在最后继承。

recaptcha/forms.py

01 from django import newforms as forms
02 from django.newforms import ValidationError
03 from django.conf import settings
04 from recaptcha import captcha
05 
06 
07 class RecaptchaWidget(forms.Widget):
08     """ A Widget which "renders" the output of captcha.displayhtml """
09     def render(self, *args, **kwargs):
10         return captcha.displayhtml(settings.RECAPTCHA_PUBLIC_KEY)
11 
12 class DummyWidget(forms.Widget):
13     """
14     A dummy Widget class for a placeholder input field which will
15     be created by captcha.displayhtml
16 
17     """
18     # make sure that labels are not displayed either
19     is_hidden=True
20     def render(self, *args, **kwargs):
21         return ''
22 
23 class RecaptchaForm(forms.Form):
24     """
25     A form class which uses reCAPTCHA for user validation.
26    
27     If the captcha is not guessed correctly, a ValidationError is raised
28     for the appropriate field
29     """
30     recaptcha_challenge_field = forms.CharField(widget=DummyWidget)
31     recaptcha_response_field = forms.CharField(widget=RecaptchaWidget, label='')
32 
33     def __init__(self, request, *args, **kwargs):
34         super(RecaptchaForm, self).__init__(*args, **kwargs)
35         self._request = request
36 
37     def clean_recaptcha_response_field(self):
38         if 'recaptcha_challenge_field' in self.cleaned_data:
39             self.validate_captcha()
40         return self.cleaned_data['recaptcha_response_field']
41 
42     def clean_recaptcha_challenge_field(self):
43         if 'recaptcha_response_field' in self.cleaned_data:
44             self.validate_captcha()
45         return self.cleaned_data['recaptcha_challenge_field']
46 
47     def validate_captcha(self):
48         rcf = self.cleaned_data['recaptcha_challenge_field']
49         rrf = self.cleaned_data['recaptcha_response_field']
50         ip_address = self._request.META['REMOTE_ADDR']
51         check = captcha.submit(rcf, rrf, settings.RECAPTCHA_PRIVATE_KEY, ip_address)
52         if not check.is_valid:
53             raise ValidationError('You have not entered the correct words')

user/forms.py

01 from myproject.recaptcha.forms import RecaptchaForm
02 
03 class RegistrationForm(forms.Form):
04     """
05     Form for registering a new user account.
06      
07     """
08 
09 class RegistrationFormWithRecaptcha(RegistrationForm, RecaptchaForm):
10     """
11     Subclass of ``RegistrationForm`` and ``RecaptchaForm`` which can tell whether its user
12     is a human or a computer.
13 
14     """

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

noreply@blogger.com (wyt) — Fri, 04 Jul 2008 08:31:25 -0500

最近在翻《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

noreply@blogger.com (wyt) — Sun, 06 Jul 2008 06:31:06 -0500

根据文章标题中的英语单词自动生成文章的 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 公钥部署多个应用

noreply@blogger.com (wyt) — Sat, 21 Jun 2008 03:36:06 -0500

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 下载日

noreply@blogger.com (wyt) — Tue, 17 Jun 2008 11:06:27 -0500

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

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

noreply@blogger.com (wyt) — Sun, 01 Jun 2008 01:47:35 -0500

经常使用 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 服务器的笔记

noreply@blogger.com (wyt) — Sat, 21 Jun 2008 03:31:21 -0500

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

noreply@blogger.com (wyt) — Thu, 26 Jun 2008 07:01:01 -0500

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 的授权认证

noreply@blogger.com (wyt) — Thu, 08 May 2008 23:57:05 -0500

上次说到了在 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

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

noreply@blogger.com (wyt) — Tue, 22 Apr 2008 08:29:02 -0500

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

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

noreply@blogger.com (wyt) — Wed, 07 May 2008 20:58:19 -0500

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/

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

noreply@blogger.com (wyt) — Fri, 18 Apr 2008 00:17:45 -0500

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

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

noreply@blogger.com (wyt) — Wed, 16 Apr 2008 03:30:26 -0500

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

noreply@blogger.com (wyt) — Fri, 11 Apr 2008 02:36:40 -0500

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

noreply@blogger.com (wyt) — Sun, 11 May 2008 03:35:25 -0500

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

noreply@blogger.com (wyt) — Mon, 07 Apr 2008 06:44:47 -0500

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。