令狐虫的无聊空间

【非BT群无视】豆瓣火星笑话小组专用脚本

Fri, 21 Nov 2008 16:25:00 +0800

家里的Linux中文输入法输入“【】”很麻烦，昨天就因为这个所以放弃了一篇火星笑话的共享。

想想老是去找“【】”两个字符来复制粘贴也不是个事。我这个人很懒的。于是就写了一个GreaseMonkey的脚本，首先当然是供自己用的，谁要是有兴趣就一起用吧。

前提条件是使用Firefox，并安装GreaseMonkey扩展。

然后点这里安装脚本。安装完之后在豆瓣火星笑话小组发言时，标题前面可以选择“火星/前冥王星/织女星系”。提交时会自动加到标题里。

就这么简单。代码也写得很烂，不拿出来炫耀了，有兴趣的自己看吧。

原文链接

Are you crazy?

Tue, 18 Nov 2008 12:48:00 +0800

杨佳袭警一案，已经过去很久了，连一审都过去了不少时间。在我看来，杨佳案也无甚特别之处，杀人者遭审判，天经地义。本不该受到太大的关注。

但不知道什么理由，Blog界里以此为题，讨论声不绝于耳，至今未绝。先是看到不少人说杨佳是挑战统治强权，心里颇不以为然。又看到有人对审判程序提出质疑，对杨佳母亲的去向表示关心，心里觉得赞同，但自己既然对这件事了解不多关心不够，也就不多说什么。

但是今天看到这样一篇blog，我忍不住想多说两句了。

文章中一段如此说：

其实说起来杨佳，我对他最佩服的地方就是凡事要一个说法。对他最不喜欢的地方是他用自己宝贵的生命就这么交换了几条贱命。这些为体质庸庸碌碌到死的家伙的命哪比的上凡事要一个说法的杨佳生命宝贵？老有人在这件事上说，难道被他杀的那些人生命就不宝贵嘛？要我说，当然不宝贵，一群行尸走肉，怎么比的上一个说真话的小伙子？

可惜，杨佳离开的太早了。只要他坚持凡事要一个说法，继续坚持下去，虽然他未必凡事都能得到有个说法的结果，但是至少会给相关责任人带来一些麻烦和损失。这就是有用的。最终一定会有一些事，一些人，因为他要说法的行为而改变。非暴力永远比暴力来的深远和有效，虽然见效比较慢。在这种行为模式下，他干掉的恐怕绝不仅仅几个精神上早已死掉的东西。而是给这个民族带来觉醒和向上的机会。

我实在不能理解，杨佳到底做了什么，能让人对他如此崇敬有加？就算他真的是为了“伟大的目的”去杀了几个警察，那也不能改变杀人犯这个事实。更何况他的杀人动机实在很难跟什么伟大的目的有所关联。

再看行文：“一群行尸走肉，怎么比的上一个说真话的小伙子”。好精英，好法西斯啊。是啊，只有坚持理想的伟大的人才能生存，我等行尸走肉，本无活着的权利。杀之如草芥，痛快啊痛快。但是你们不想想，这跟统治者正在做的事情有什么区别？就算你们来领导这个国家，也不过是换了一个皇帝而已。

“这些为体质（体制）庸庸碌碌而死的家伙”。你们啊，因为一个糟糕的体制而否定这个体制内的所有人，这跟你们所反对的体制有什么本质的区别？

我想说，杨佳不过就是一个个案，而且是一个糟糕的个案。这个案子里的主角，也许是真的有什么内幕或者受到了不公正的待遇，但他受到不公正的待遇并不意味着他做的事情就是正确的。

我想，你们希望这个社会变得更好，这个想法是对的。但首先你们应该学会独立的思想，以及接受各种各样的看法，无论是你们所认同的，还是你们所反对的。如果用“敌人的敌人就是朋友”这样简单的思路去解决问题，那么你们并不比你们所讽刺嘲笑的对象更高明。

原文链接

Python玩动态图像生成

Fri, 07 Nov 2008 16:42:00 +0800

TR发了这么一个帖子，感觉挺有趣的。于是就乘着中午休息的时间做了一个动态生成的版本玩玩。

首先当然是下载原图，然后把横幅上的字擦掉。形成一幅底图。测量一下横幅的位置，并记录下来。

然后用Python的PIL库加载这幅底图，然后用PIL的ImageDraw功能在上面画字。这里为了让所有的字都能显示在横幅里，我写了一个简单的自动选择文字大小的函数。

import Image, ImageDraw, ImageFont

def getFontInfo(str, size):
    "Choose an appropriate font size for output"
    fontname = 'wqy-zenhei.ttf'  #这个字体文件必须存在
    for s in range(8, 121):
        font = ImageFont.truetype(fontname, s)
        width, height = font.getsize(str)
        #当文字最终占的尺寸超过指定尺寸时，退出循环
        if width > size[0] or height > size[1]:
            break
   #然后用比刚刚那个小一号的文字大小
    fontsize = s - 1
    font = ImageFont.truetype(fontname, fontsize)
    strsize = font.getsize(str)

    return font, fontsize, strsize

然后再实现一个叠加文字到图像的函数：

def genPic(str):
    start = (117, 127)
    size = (720, 30)
    font,dummysize,strsize = getFontInfo(str, size)
    image = Image.open('background.jpg')

    draw = ImageDraw.Draw(image)
    draw.text((start[0]+(size[0]-strsize[0])/2,start[1]+(size[1]-strsize[1])/2), str, font=font)
    del draw 

    return image

这样生成图像的部分就写完了。最后再写一个cgi的前端：

#!/usr/bin/env python
#coding:utf-8

import gen
import cgi
import sys

import cgitb; cgitb.enable()
sys.stderr = sys.stdout

form = cgi.FieldStorage()
s = form.getvalue('s')
#这里用猜编码的方式尝试将文字转换为unicode。
try:
    s = unicode(s, 'utf-8')
except:
    try:
        s = unicode(s, "gbk")
    except:
        pass

image = gen.genPic(s)

#生成图像
print 'Content-Type: image/jpeg\n'
#输出结果到标准输出
image.save(sys.stdout, 'JPEG')

这样，一个动态生成图像的python脚本就写完了。将它放到带ExecCGI权限的目录中，并指定.py后缀为CGI脚本。就可以运行并得到输出了。

demo效果可以见我的实验室。

原文链接

升级完成

Sat, 01 Nov 2008 23:33:00 +0800

经过大半天的奋斗，我的服务器成功的升级到了Ubuntu 8.04。

一些用户尚未恢复——包括系统用户和svn用户。不过有些用户也许本来就是多余的。

一些组件换了。

原来因为服务器资源的问题，将HTTP Server由Apache 2换成了lighttpd，虽然资源的确节省了，但是带来了很多的问题，比如无法使用http协议的svn，等等。于是这次升级之后，仍然将HTTP Server换成了apache2。

svn也因此由原来的svnserve模式改成了http模式。

下载用的amule-daemon乘着这次升级换成了mldonkey——以后可以尝试在服务器上下载BT了。

其他的东西，以后逐步再恢复了。

原文链接

升级

Fri, 31 Oct 2008 17:14:00 +0800

计划周末对服务器做一次升级。blog及其他服务暂停2天。

原文链接

scons简介

Tue, 28 Oct 2008 23:00:00 +0800

云风在blog上写了一组《IDE 不是程序员的唯一选择》的文章。题目很吸引人，以至于我一直以为他要写什么鸿篇巨制，可惜到最后只出现了一组《GNU make入门指南》。（笑）

被IDE绑定的确是一件很悲哀的事情。作为一个程序员，当然应该搞清楚程序编译链接的整个流程，makefile给出了很好的一个路径，让我们能够了解这一点。

但是，如果觉得程序员就应该比拼“手写汇编代码”、“用记事本写程序”，那就大大的错了。程序员需要了解细节，但不意味着程序员都是傻瓜。为什么要放着好好的提高生产力的工具不用，一切从零做起呢？（当然了，上面这句话并不能成为使用盗版的理由。）所以寻找并了解一些优秀的工具，也是我们这些程序员所需要做的事情之一。

GNU make 当然是一个很好的工具，云风已经讲了很多，我就不啰嗦了。我今天想介绍另一个优秀的自动构建工具scons。

scons是一个Python写的自动化构建工具，从构建这个角度说，它跟GNU make是同一类的工具。它有什么好处呢？在它自己的网站上，当然写了一大堆了，快速、稳定、强大、跨平台、可扩展……。不过我们还是从自己的角度来看看它到底好在哪里。

刚刚提到scons从目的而言跟GNU make是同一类的工具。但是实际上，它的思想是跟GNU make完全不同的。GNU make的核心是“依赖关系”，我要做的事情，就是告诉系统，一个目标依赖什么东西，并且，当被依赖的东西发生变化时，我要做什么。这样做可以解决相当多的问题，但是也带来了一个最大的问题：我如何判别这个目标依赖什么？

对于一个两个，甚至十几个文件，我当然还比较容易搞清楚，谁依赖谁。但是当文件有成百上千个时，要分清楚谁依赖谁可就没这么容易了。尤其是C/C++头文件的依赖，如果手工分析的话，工程量可是不小。为了解决这个问题，GNU又提供了另外一套工具：Automake，使用程序来分析依赖性，然后辅助你产生makefile。

于是乎，就有人想了，既然如此，我干吗费那劲，用程序分析依赖性，然后生成一个文件，再交给另外一个程序去处理呢？既然依赖性需要用程序来分析，那么就直接交给构建工具本身去做不就好了吗？对的，这是一个非常自然的思路，于是，Java世界有了Ant，而Python世界有了scons。

scons就是这样一个构建工具：你告诉它要做的任务，以及完成这个任务需要的输入，以及这个任务产生的输出，怎么做这个任务（当然其中就包括依赖性分析），就交给工具本身完成。

说了这么多，我们来看看一个现实世界的scons是什么样子的。

我们假设有一个C程序，由三个文件组成：

//-----func.cpp
int add(int x, int y)
{
    return x+y;
}

//----func.h
#ifndef __FUNC_H__
#define __FUNC_H__
extern int add(int x, int y);
#endif

//-----main.cpp
#include <stdio.h>
#include "func.h"

int main()
{
    printf("2+3=%d\n", add(2, 3));
}

然后我们写一个SConstruct文件（类似于GNU make的Makefile文件，是scons的默认文件名）：

Program('add_main', ['main.cpp', 'func.cpp'])

然后执行scons，将会输出以下信息：

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o main.o -c main.cpp
g++ -o func.o -c func.cpp
g++ -o add_main main.o func.o
scons: done building targets.

这时，我们就会得到一个add_main的可执行程序。

如果执行scons -c，我们会看到：

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Cleaning targets ...
Removed main.o
Removed func.o
Removed add_main
scons: done cleaning targets.

生成的可执行程序连带中间结果都被清除了。

这里我们可以看到，scons只需要描述任务，并不需要指定依赖关系，甚至我们都没有指出头文件，但是你修改func.h的时候仍然会触发构建。这是因为scons内部有个scanner，可以帮助扫描包含文件的关系。（我们可以编写自己的构建任务，当然也可以编写自己的scanner，有兴趣的可以看帮助，这里就多说了）

我们还发现，这里我们根本没有指定编译器，也没有指定编译选项，但scons仍然很聪明的选择了g++（这是Linux上的结果，如果是Windows，默认会选择cl也就是Visual C++），并且给出了正确的编译选项。事实上，这是因为scons内置提供了很多编译器及其对应选项的选择，然后对于不同的平台，会有一个默认项。我们当然也可以自己选择编译环境，比如在Windows下，我同时安装了VC和mingW，但是我想用mingW来编译而不是VC，就可以这样指定：

import os
env = Environment(ENV=os.environ, tools=['mingw'])
env.Program('add_main', ['main.cpp', 'func.cpp'])

这里出现了一个Environment的概念，Environment可以设置编译的环境。这是一个简介，所以对于它我们就不多说了，感兴趣的可以自行查阅资料。嘿嘿。

在这里我们看到了一句熟悉的语句：import os。是的，SConstruct文件就是一个非常标准的Python程序，所以，Python能做什么，scons就能做什么。很好很强大阿，哈哈。（这里顺便说一句，我们也可以认为Makefile是shell程序，但是因为shell有平台相关性问题，我们很难写出一个通用平台的Makefile，但是我们还是写的出一个通用平台的SConstruct的。）

Program只是scons支持的构建任务其中的一种，用于根据后缀名自动构建C、C++、D和Fortran的可执行程序。scons还支持另外几十种构建目标，这里可以查看支持的列表。如果这里找不到的，还可以自己编写Builder和Scanner。

接下来我想给出一个一直提但是一直没有给出结果的东西，就是对C++程序的单元测试。

还是以刚刚那个小例子为例。我们对add函数作一个单元测试。我们知道，单元测试不是程序的一部分，所以需要一个独立的main函数。而被测试的单元是一样的。

现在假设我们有一个测试函数：（用的是boost的test库，这个库的使用方法不再赘述）

//--------test_main.cpp
#include "func.h"
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MAIN
#include <boost/test/unit_test.hpp>

BOOST_AUTO_TEST_CASE( add_test )
{
    BOOST_CHECK( add(2, 2) == 4 );
}

然后我们写一个SConstruct：

#所有的需要测试的单元文件（去除两个主文件）
import glob
obj_files = glob.glob('*.cpp')
obj_files.remove('main.cpp')
obj_files.remove('test_main.cpp')

common = Object(obj_files)

Program('add_main', ['main.cpp'] + common)
Program('unittest', ['test_main.cpp'] + common, LIBPATH='/usr/lib', LIBS=['libboost_unit_test_framework'] )

Alias('test', 'unittest')
Default('add_main')

这里出现了几个新玩意儿，一个是Object，其实也很好理解，Object就是将指定的文件编译成目标文件（.o或者.obj），然后我们用了2个Program，表示要生成两个可执行文件。在生成的时候，我们将通用的common附加到构建输入中。另一个是Default，这是表示默认的构建。当我们输入scons时，将构建add_main，而我们输入scons unittest时，则构建unittest。但是输入unittest感觉不太方便，我们想输入scons test来编译，但希望输出的文件名仍然是unittest，于是我们增加了Alias，将unittest取了一个别名叫test，这时，我们输入scons test，仍然会构建unittest。

我们注意到构建unittest时，使用了附加的信息，比如额外的库、额外的路径等等。还有为了方便起见，我们使用了Python标准库的glob函数展开文件通配符。

从这个例子我们大约可以感受到scons的强大威力了。至于进一步的深入，就看各位自己的了。

原文链接

依赖性处理的Demo

Thu, 09 Oct 2008 16:49:00 +0800

这是我为了验证插件机制依赖性写的一个原型代码。本来想写一些文字说明的，后来发现实在没什么好写，就直接贴代码吧，如果有问题可以问。

class Element:
    def __init__(self, name, deps):
        self.name = name
        self.deps = deps

def getIndexFromName(elementList, name):
    for index, elem in enumerate(elementList):
        if elem.name == name:
            return index
    return -1

def dependProcess(elementList):
    stack = []
    for index, elem in enumerate(elementList):
        print "now processing Element %s[%d]" % (elem.name, index)

        tracker = []
        if elem.name not in stack:
            result = elementDependProcess(elementList, index, tracker, stack)
            if result == False:
                #circle dependence
                return None
        else:
            print "%s is already scaned, skip it" % elem.name

    #when elment duplicated in stack list, just keep the last one
    #and reverse it to make the dependency order right.
    stack.reverse()
    newstack = []
    for elem in stack:
        if elem not in newstack:
            newstack.append(elem)
    return newstack

def elementDependProcess(elementList, startIndex, tracker, stack):
    ins = elementList[startIndex]
    name = ins.name

    stack.append(name)

    print "curr element=", name, ", tracker=", tracker
    if name in tracker:
        print "%s is circle dependence" % name
        return False
    tracker.append(name)

    if ins.deps == None:
        return True
    else:
        for dep in ins.deps:
            index = getIndexFromName(elementList, dep)
            if index == -1:
                #Cannot find element in list
                print "Cannot find %s in elementList" % dep
                return False
            else:
                result = elementDependProcess(elementList, index, tracker, stack)
                if result == False:
                    return False
                else:
                    tracker.remove(dep)  #restore the init state
        return True

if __name__ == "__main__":
    elementList = [
                    Element("a", None),
                    Element("b", ["d"]),
                    Element("c", ["a", "b"]),
                    Element("d", ["a", "e"]),
                    Element("e", None)
                  ]

    loadList = dependProcess(elementList)
    print "Load List=", loadList

原文链接

The Diva Dance

Mon, 06 Oct 2008 13:51:00 +0800

昨天看了最新一期的《我猜》，看到有人居然又唱了《第五元素》里的《The Diva Dance》，虽然只有一句，不过还是勾起了我的回忆。忍不住要推荐一下这段音乐。

每个看过第五元素的人应该都会对那个蓝色的外星歌唱家Diva印象深刻。没错，她出场演唱的那段歌剧就是《The Diva Dance》。但是，这段歌剧实际上是由两个部分组成，第一部分是葛塔诺·多尼采蒂的歌剧Lucia di Lammermoor(拉莫莫尔的露西亚)第三幕中的一段，第二部分的花腔就是我们通常所说的The Diva Dance。

The Diva Dance实际上是一段虚拟的唱段，为了表现外星人的特别，唱段里使用了很广的音域以及快速的高低音变换，这种变换地球人是做不到的，所以没有办法真实的唱出来。事实上，电影中的这段唱，是人声+电脑辅助处理完成的，如果仔细的听，可以听到电脑处理的痕迹。（不知道10年之后的今天再做这段音乐的话能不能做得更加自然一点？）

网上传说俄罗斯的高音王子Vitas曾经翻唱过The Diva Dance。听过Vitas的Opera 2的惊艳表演之后，我倒是真的很期待听到真人版的The Diva Dance，可惜Vitas只翻唱了前一段Lucia di Lammermoor，我最期待的部分并没有出现。当然还是有人会尝试这段超高难度的花腔，但都做了或多或少的简化了。

这就是原始完整版本的The Diva Dance。在第二部分，中间有一段可以很明显的听出是电脑处理的。

这是潘美辰的翻唱，可以明显感受到高音部分很干涩并且有失音准（毕竟不是专业唱美声的），而且在高低音转换部分做了很多的简化。但是我觉得有勇气挑战这段就很厉害了：

这就是Vitas翻唱的Lucia di Lammermoor，他的高音很迷人，不过注意一下他的唱法并不是传统的歌剧唱法：

原文链接

2008苏州大闸蟹聚会纪要

Fri, 03 Oct 2008 21:45:00 +0800

第二届苏州大闸蟹聚会于2008年10月1日在TR家举行，为期一天。

今年聚会规模有所扩大，增加了从南京赶来的WingSun和尚在腹中的小刺猬。

今年聚会的形式也更多样，除了传统的XBox360上的甩牛和专业代关厕所门之外，还增加了Wii上的网球对打、BT的疯兔2还有装反d专用吉他英雄等。另外还有毫不起眼的NDSL、没怎么玩的iPhone、键盘超级难用的EeePC、1700元的耳塞、新鲜出路的House MD S05E02，以及Nikon、Canon、Sony单反相机若干。让各个层次的BT们都能找到自己的所爱。

今年聚会的主题更明确，在大闸蟹时间，众BT们快速讨论了狗屎皮计划、萝莉养成计划、新版群机器人计划、RPI远景计划等各项计划，明确了BT群下一阶段的工作。

今年聚会的成果更显著，我们解决了圣上的DocBook生成问题，研究了2F ssh连接速度慢的问题，升级了令狐的Wii。

这是一次关键的聚会，成功的聚会，胜利的聚会！祝贺此次聚会圆满落幕！（在我确实拿到自己的Wii之后）

附：

TR版聚会小记

原文链接

Communix分支表

Mon, 22 Sep 2008 17:09:00 +0800

仅供娱乐，不许联想。

原文链接

中秋快乐

Sun, 14 Sep 2008 22:08:00 +0800

今天是一年一度的中秋节。

作为BT群的一员，自然要想一点BT的方法祝福一下大家。

在看完了BT的F1蒙扎战之后，我想了一个BT的祝福短信，群发给了BT群的家伙们。

夏日芙蓉冬日娜
春夜闺中秋夜圆
祝众BT中秋快乐 :)
我发誓这真的是原创。。。

不出所料的，我收到了很多BT或者不BT的回应：

谢谢，中秋快乐

从水平而言我绝对相信是原创的

至少第一句不是。哈哈哈哈哈哈哈

太BT了，竟然看不懂... 中秋开心哈！

呵呵，是不是原创日后再说，中秋快乐才是王道！

哈哈可惜乌云遮月

支持BT原创，让原创来得更猛烈些吧。中秋快乐。

哈哈中秋快乐

自己来认领吧哈哈。再次祝所有人中秋快乐。

原文链接

2008 CSDN上海英雄会

Sat, 06 Sep 2008 01:01:00 +0800

今天参加了CSDN的上海英雄会。

9点到会场，与猛禽、三火碰头，领了嘉宾证和赠品，进入会场。

会场座无虚席，看起来人的确不少。我们兜了一圈，居然没找到座位，只好在最后站着。

会场中间一个大幅背景，写着“英雄会会英雄”。左右两边分别有两个屏幕，一个是演讲幻灯，一个是叽歪留言展示。后文会提到，这个叽歪留言俨然成了今天会议的亮点。

韩磊老大简短的开场之后，是今天最精彩的一篇演讲：Ivar Jacobson的“Be smart”。myan负责翻译。但是不得不说，myan这次显得很不称职，几乎只是站在一旁无所事事，几乎没有做任何翻译。好几次甚至是Ivar提醒他这句需要翻译，他才翻译一句。我的英文听力一般，加上边听边跟猛禽三火做些讨论，有不少精彩之处没有听清。只知道大概意思是说，我们应该做smart的事情，让事情尽量简单，但不要太简单。接着有几个论点：很多大公司认为工具比人重要，这是unsmart的，一个笨蛋就算用上好工具仍然是个笨蛋，不过是一个危险的笨蛋。囧。我们应该要关注人大于关注工具。另外在项目方面，批评了至今仍广泛使用的瀑布模型，认为它阻碍了各层对其他层的理解（做需求的不知道代码怎么写，写代码的不理解需求，诸如此类），所以敏捷是一个好的方案，不过smart不仅是敏捷。谈到架构时，举了两种unsmart的极端：只要代码不要架构，一切通过重构完善（这似乎就是极端的敏捷论），或者构建一个“完美的架构”。smart的做法是对一个骨架系统进行架构设计（骨架系统涉及全部关键业务但不涉及细节），然后通过重构逐步完善，成为一个真正的系统。后面的因为种种原因没有听清，很遗憾。我打算等CSDN开放下载时下载PPT再看一遍。

在Ivar快结束的时候用英文问了一遍：“你们中间有多少人仍从事软件开发？”举手者寥寥。他可能不信，让myan用中文又问了一遍，这次举手者十有八九。老家伙明显受刺激了，又用英文问：“你们有谁完全听懂了我的演讲？”这次更惨，举手的只有几个（我也没举手，因为我的确是没有完全听懂）。剩下的要不是确实没完全听懂，要不就是连这句话都没听懂。哎，真可怜。我觉得这要怪罪于主办方组织不力——要是myan能充分准备翻译的话，效果显然会好很多。

接下来是SAP的芮祥麟和51.com的庞升东的两个演讲。内容不甚精彩，与听众互动也不多，基本就是照PPT讲完了事。因此也没有用心去听去记。不过51.com在Geek圈的名声显然不好，在庞总演讲的时候，旁边的叽歪屏幕上居然好多次出现了讽刺51.com的内容。引得下面哄堂大笑。幸亏演讲者的位置看不到这个内容，否则不知会作何感想。

在庞升东演讲之时，我们仨去旁边的书摊转了转，买了韩老大翻译的《梦断代码》准备让他签名，我还多买了一本《Python源码剖析》——这本书我早有耳闻，再加上为他作序的limodou和Huang Dong都是Python社区大名鼎鼎的人物，想来这本书不会差到哪里去，看到了就买回来读一读。

买完书去找韩老大，他帮我们签了名，还领着我们到第一排雅座就座。hoho。有关系就是8一样。

然后坐着听了Google的OpenSocial和云计算介绍。这是上午的演讲中我感觉第二有价值的一场，它让我对Google的战略更加清楚了一些。Google绝不是在盲目的推出产品，他的产品都是有价值和野心的，OpenSocial是为了进一步收集用户习惯以便做推荐，而云计算平台则是为OpenSocial应用奠定了一个强大而且低门槛的基础——结合以前keso所做的分析，收集用户习惯果然是Google非常重要的一个手段。在有了充足的用户习惯数据之后，说不定google还会让我们大吃一惊的。

接下来是非常有趣的电梯演讲单元：几个演讲者各有特色，有的语速超快，有的风趣幽默，而叽歪的无厘头风格也从这里开始显现，几个演讲者在演讲时，叽歪留言妙语不断，俨然盖过了所有演讲者的风头。

但是电梯演讲有一个问题：我一直搞不明白这个演讲是面向我们开发者还是面向投资者。不仅我没搞明白，所有的演讲者显然都没有搞明白。你说他们是面向开发者吧，他们并没有多少涉及技术的内容，大多是介绍自己产品的功能以及如何填补了市场空白；你说他们是面向投资者吧，他们缺少了对自己产品的盈利模式分析和市场占有分析。目标不明确导致了他们的演讲两头都不讨好。只有庄表伟同学凭借搞怪的内容博得了一些喝彩和怪叫。因为几个演讲者出现了相同的毛病，我只好再次猜测这是组织者的问题。

自助午餐，一般般。不过我们值得骄傲的是提前出来，避免了排长队。

下午开始是myan的技术指数介绍。因为我们设想过一个RP指数，所以对这个指数特别关注了一下。这还是一个很初级的东西，很多地方还在调整。不过也让我在如何设计指数方面收获颇多。

接下来是一个IT人士的英语解决之道。基本上算是一个广告性质的演讲，但是张宏岩同学的洋洋洒洒让三火仿佛回到了新东方，而我则感觉是进了李阳的疯狂英语推广会。那个“Long time no touch”的例子让我觉得非常囧，我不相信这是真的，就是是中国人也不会说“很久没接触”吧。

下午大概是因为大家比较困，又大概英语的这个演讲让大家觉得无聊，叽歪的mop化达到了一个高潮，太多经典和搞笑的东西不断涌现，给枯燥的会场带来了无穷的乐趣。有人甚至说：“叽歪是本次大会最大的亮点。”

第二轮电梯演讲结束，开始论坛。所谓论坛就是几个人在台上侃大山，几百人在台下看。我们觉得聊的内容比较乏味，于是出了会场，在外面自己开起了小会。

我、猛禽和三火对会议的形式做了一番讨论，觉得今天这样的会议略显枯燥，我们比较倾向于barcamp那样并行小众的演讲。然后对上午的一些演讲内容做了一番讨论和分析，最后不该开发人员本性，又回到了具体的技术问题——我们讨论了XML的一些优缺点、应用和开发。

最后我们打算走之前，跟韩磊老大交换了我们先前讨论的会议形式的想法。韩老大原来也是有苦衷的：人家出了钱，当然要说话，但是他们不希望自己的演讲失去控制——这在民主的barcamp形式的小众演讲中是很难做到的。所以说角度不同看到的问题就不同，以后看问题还是要吸收不同方面的意见才行。

在聊天的过程中顺便听了一下创业论坛的讨论。说到企业底线这个问题时，大家都在支吾其辞，我听了也只能笑笑——在这样一个社会里，都不容易啊。

今天主要的收获：听了几场还算有价值的演讲，拿了一大堆赠品，看到了miniblog如何在会议中大显身手。

PS 今天回家时还发生了另外一个小插曲，请看这里。

原文链接

google day

Wed, 03 Sep 2008 11:30:00 +0800

今天Google一下子发布了两个软件：

Google Chrome和Picasa 3.0。

都还处于Beta状态。

Google Chrome试用感受：仅有基本浏览功能，但就这部分而言做的不错。页面打开的速度快得让人印象深刻。最希望增加的功能是广告拦截和高级的代理设置（像FoxyProxy那样的）。

Picasa 3试用感受：界面更华丽了，加强了与Online的联系（不过我基本不用Web Picasa所以没什么感受）。Photo Edit里增加了图章和文字两个工具，很有用，尤其是前者，那简直是MM修脸必备工具啊。有这个就可以进一步抛弃Photoshop和Gimp了。希望增加抠图和调整脸型的功能……（恩，妄想ing）。增加了Movie制作功能，可以将照片制作成WMV电影，这个功能非常有用，早该提供了。网上盛传的人脸识别功能，没有找到

Update: 刚发现Picasa 3自带的Photo Viewer效果也很酷，跟系统结合也很好。双击照片的时候会出来一个半透明的黑屏，照片居中显示。就像是系统自带功能一样，完全避免了打开软件窗口的感觉。而且速度也相当快，几乎感觉不到是用第三方软件打开的。我刚开始的时候吓了一跳，心想XP什么时候提供这种功能了，后来才意识到是Picasa的功能。非常赞。

Google在客户端市场沉默许久之后终于发力，两款软件可圈可点，虽然现在只是Beta版，但潜力巨大。（画外音：什么时候能升级一下Google Talk啊……）

今天真是一个Google day。

原文链接

终于找到了Total Commander的替代品

Tue, 26 Aug 2008 13:10:00 +0800

从很久很久以前，Total Commander就成为了我的必备工具。在我不再使用盗版软件之后，我一度曾经想去买一个TC的License，可惜不知道为什么，我的购买请求如泥牛入海至今没有回音。因此Total Commander就成为了我电脑上为数不多的没有License的非免费软件之一。

但是这么用着总感觉心里不爽，中间也曾经尝试过一些其他的选择，比如Free Commander之类，但始终觉得没有Total Commander好用。用了一段时间之后，又换回来了。

今天偶然中发现有人在推荐一个叫做Unreal Commander的玩意。推荐者甚至用了“Amazing”这个词表示对它的称赞。出于好奇，我也去下载来看了一下。

这一看不要紧，乖乖，这根本就是Total Commander的翻版嘛！看看界面，TC有的元素它一个没落下；试试快捷键，该有的都有；功能方面：FTP也有，批量重命名也有，压缩解压也有，工具栏拖放也有……，甚至连Option对话框看着都这么眼熟。我顿时泛起一种直觉：这应该就是我要的东东。

第一天的试用，感觉如下：

一些细节比Total Commander考虑得更完善，比如Option里有“Autorun at startup”可以直接配置成启动运行，而不用像TC那样还要自己搞。可以针对不同的文件类型设置不同的颜色（这个其实TC也可以，但需要手工修改ini文件而不能在Option里配置）。FTP可以设置服务器端的编码格式，F3呼出的那个Viewer比TC的强很多。

另一些细节不如Total Commander考虑得好，比如Hotlist（就是TC里的Favourite）不能分层。在TC里我可以将工作所需的目录和个人所需的目录分开两个组设置，UC里不行。工具栏也只有一个，不能像TC那样增加自己的工具栏。缺少TC中的分割、合并文件，以及MD5校验等功能，不过还好这些功能并不经常使用。批量重命名和文件搜索时不能使用正则表达式（这个影响较大，不过大多数复杂的重命名我现在都是写python脚本解决了）。另外，软件运行的速度跟TC差距较大，我不知道自己能不能忍受它的速度，需要进一步试用。

不管如何，这是我用过的免费工具中最接近TC的一个了。我认为还是值得推荐的。

原文链接

2008年8月25日

Mon, 25 Aug 2008 11:21:00 +0800

昨天，F1在全新的瓦伦西亚赛道上开赛。Kimi一如既往的那样低迷。排位赛只有第四，发车时还被Kovalainen反超落到第五。这次Kimi倒是很拼，但是偏偏这条全新赛道没有地方可以超车……。

第二次进站对于Kimi是一个噩梦：先是为了抢在Kovalainen前面出站提前发动，结果油枪还没拔下来造成事故，不但让可怜的加油人员坐上了担架，还让原本微弱的劣势进一步加大。但问题显然不在这里，出去之后才跑了一圈，就就就爆缸了……。我突然希望Kimi能够早点退役，不要再以悲情英雄的形象出现。其实悲情英雄，没有英雄，只剩悲情。

我不太喜欢的Alonso显然也运气不佳，在千百万的西班牙家乡父老面前，居然才跑了一圈就退赛了。不知道会不会有人说什么阴谋论，懦夫，诸如此类。

昨天同一时间，奥运闭幕式在北京举行。16天的奥运会就此完结。可惜我的注意力全在F1，错过了这场精彩也好，失败也好的盛会，只能去网上看看有没有NBC版的录像下载了。

无论事前说什么跟自己无关，这16天还是给我带来了很多，有惊喜，有遗憾，有欢乐，有愤怒。无论大家评价如何，这16天，注定会给我留下很多回味。不过，从昨天开始，结束了。

该过的日子还得过，该做的事情还得做。只是有些事情，是永远回不到以前了。

今天早上，被雷声吵醒。出门，发现天上暴雨滂沱，地上已成一片汪洋。堵车堵得厉害，上班比平时晚了足足半个小时。到公司门口的时候，积水齐膝。可怜我的脚要在湿漉漉的鞋子里浸泡一天。

用TR的占卜程序算了一卦：

讼，有孚窒。惕中吉。终凶。利见大人，不利涉大川。
讼，上刚下险，险而健讼。讼有孚窒，惕中吉，刚来而得中也。终凶；讼不可成也。利见大人；尚中正也。不利涉大川；入于渊也。
天与水违行，讼。君子以作事谋始。

原文链接

三言两语说刘翔退赛

Wed, 20 Aug 2008 09:23:00 +0800

最近刘翔退赛应该是最热门的话题了。

我简单说一下我的想法。

他的所做所为绝对称不上英雄。
但他绝对有退赛的自由。
他当然应该承担因为退赛而招致的指责、损失、名誉下降等一切后果。
但犯不着将此行为拔高至国家民族的高度。说句不好听的，除非刘翔的胜利可以让体育运动惠及大众，否则所谓的国家荣誉感跟我们没有半点关系。

阴谋论的说法很能满足大家的8卦心态，但我觉得这里是不是阴谋完全没有本质的区别。

原文链接

猴子的版权

Tue, 12 Aug 2008 10:14:00 +0800

奥运开始了。开幕式也看了，该称赞的称赞了，该揶揄的揶揄了。我想也不用多说什么了。聊点别的有趣话题吧。

在Solidot看到这样一个新闻：Debian会如何处理猴子写的代码的版权。于是引发了众BT的一番有趣的讨论。

原始讨论中有这样一段话：

The actual author of this file (Edgar Toernig) refused to put any copyrights / licenses on it and claims that his monkey has written it, because international copyright law does not apply to animals' works. This way he wants to make is code completely free.

于是我就提出了这样一个有趣的假设：

如果一只的确会写代码的猴子，非法使用了包含版权声明的代码，写出了一个软件。软件的使用者可以声明自己并不知晓非法内容，所以无需受罚。而猴子呢？人类的国际版权法无法适用于猴子，所以猴子也不用受罚。那么，我只要养一只会写代码的猴子，那么一切版权问题不是都不存在了？

看来汉芯麒麟之流，最需要的是一只会写代码的猴子啊。

原文链接

奥运了

Fri, 08 Aug 2008 17:45:00 +0800

所有的中文网站都挂上了奥运的标志，很多产品也推出的奥运版本。奥运这个词泛滥到让人想吐。也许，从这个角度而言，禁用“奥运”做宣传用语是对的。

又听到几个谣言，告诉我们目前形势很紧张。

TR的网站没有备案，被警告了。几天后将暂时关闭。也许有一天我的网站也会遭遇相同的处境。

晚上的开幕式，很多人会看。很多号称要避运的人一定也会看，看完之后再上网一顿猛批。一定是这样的。

因为奥运开幕式跟奥运无关，这是一场全民娱乐。

奥运快点结束吧。

原文链接

Python 3.0

Tue, 22 Jul 2008 21:41:00 +0800

今天因为去银行做培训，结束之后闲来无事，又不能上网，于是在笔记本上把下载已久却一直无暇钻研的Python3.0beta1安装看了一看。

最让我眼前一亮的是Python 3.0的帮助文档。与Python 2的相比可以算是脱胎换骨了。在Library Reference中，结构被组织得更加清晰，非常容易阅读。再加上新增加的例子代码，我想对学习和使用会有相当大的帮助。我特地查阅了re（正则表达式）一章。以前那种迷糊的感受一扫而空。而从头至尾大致翻阅之后，我又发现了很多以前不知道的东西。

非常常用的print使用方法做了较大的调整。现在的print完完全全是一个函数而不像以前那样看起来像个命令。实际使用中，在命令行下输入感觉“不爽”了很多。然而增加的sep、end、file参数对程序的开发是有很大帮助的。

字符串处理增加了format函数，是对以前%格式化方法的一个增强。这种增强我觉得是非常方便的，比如对对象属性的引用等等。但是很显然这种增强针对的是程序开发而非命令行。

内部的字符串完全以Unicode做处理，并且string和bytes不再兼容。这个改变造成了我的一些程序在向wb方式打开的文件中写字符串时遇到了麻烦。

一些库被增强了，一些库被取消了。一些库中的函数或方法被改变了。这些改变造成了我相当多的程序无法在新版Python中运行通过。看来程序的迁移将不会是一个小动作。

还有很多列在What's New中的改进及增强还没有来得及试验，不过从描述来看，都是些很好的改变。

总的来说，我觉得Python 3.0做了一些非常好的增强，这些增强是很值得期待的。然而我的感觉是Python 3.0有了一些蜕变，它不再满足于做一个“脚本语言”，它希望变成一个真正的“开发语言”。从对命令行便利性方面的削弱，以及对大规模程序方面的增强就可以明显看得出来。然而我最早认识Python，是作为一门“方便的脚本语言”的。我平时在python的交互模式下的应用也不算少。因此，它的这种改动，是好是坏，我还真的难以下定论。另外，一些不向下兼容的改动，造成了代码迁移方面的很大工作量，虽然有2.6版做过渡，我仍然觉得这是很糟糕的体验。

只能在充满矛盾的心情中，期待Python 3.0正式版的到来。

原文链接

bblean的几个问题的解决

Thu, 17 Jul 2008 10:27:00 +0800

我的工作电脑，每天开机的时候要加载一大堆的东西，速度很慢。本来想精简一下，可是想来想去，没什么可以精简的：

邮件得收吧，Foxmail不能省。
工作得联系吧，MSN不能省。（当然，顺大便把gtalk也启动了，这个某种意义上对我而言更重要）
Total Commander，已经习惯了，不能没有它，所以一定要开的。
Firefox……
笔记本自带的启动程序，不想去动它了
工作需要的很多服务...

所以最后还是决定使用bblean，替换explorer。别说，用bblean之后启动速度的确是提高了相当多。不过有了一些新的不方便：

以前TaskBar的右键菜单没有了，于是呼不出任务管理器
没有Quick Launch栏。我的很多启动方式都是放在Quick Launch里的
最大化窗口会被bbSystemBar遮住
笔记本的音量条件按键失效

这几个问题还是挺影响使用的。所以一度又曾经放弃过bblean，但在忍受了几天explorer的龟速之后，我还是决定重新使用bblean，并且解决掉这些问题。

Google一番之后，终于还是都找到了解决之道。

任务管理器的问题其实很容易解决——只是我原先没有想到而已。bbLean自己有一个菜单，可以在bbSystembar的任意位置右键呼出，这个菜单是可以编辑的。只要在上面加入任务管理器的项就可以了。

我现在是使用Process Explorer代替Task Manager的，所以就配置成：

    [nop]
    [exec] (TaskManager) {"d:\Program Files\ProcessExplorer\procexp.exe"}

Quick Launch的问题，我增加了bbIconBox插件，它可以在桌面上增加指定目录的菜单面板。我增加了一个QuickLaunch的面板，放在侧边栏，自动隐藏，需要的时候鼠标晃过去就可以操作了。另外我还装了一个Lauchy软件，可以热键呼出之后输入几个字母就可以启动程序，避免打开开始菜单，更加方便了。我使用Launchy的原因是因为它是自动扫描软件项目而不需要手工配置，尤其适合我这样的懒人。呵呵

最大化窗口的问题原来是设置问题，只要将blackbox.rc里的session.screen0.fullMaximization: 由true改成false就行了

音量按键的问题有点麻烦，后来发现很多人都是装了一个叫做bbkeyhook的插件解决了。于是去找了一个，装上，果然OK了。

我现在的bblean使用了bbKeys、bbSystemBar、bbIconBox和bbKeyHook，去掉了bbSkin。我并不是想搞什么美化，只是想加快启动速度而已，所以操作习惯还是尽量跟Windows原来的接近。

原文链接

黎明到来

Tue, 15 Jul 2008 09:29:00 +0800

忙了这么久，终于感觉黎明的到来。

正好群里的项目也重新激活了。

Fighting Fighting！

原文链接

无地自容

Fri, 04 Jul 2008 23:24:00 +0800

因为小虫的缘故，找了三字经大概看了一看。顿时汗如雨下。

虽然说三字经是一本国学入门书，从内容上看也确实如此。但我居然也还有好多典故解不出来。

枉我还号称钻研过历史。无地自容ing。

原文链接

全民俯卧撑

Wed, 02 Jul 2008 12:43:00 +0800

最近因为工作忙已经错过了太多值得记录的事情。但如果把这件事也遗漏，就未免太说不过去了。

奥运新项目：俯卧撑。

原文链接

钱包被偷

Mon, 23 Jun 2008 12:07:00 +0800

今天早晨坐公车上班，下车的时候下意识的摸了一下口袋，钱包没了。

共计损失现金若干，银行卡若干，可报销的发票若干，其他不记名代币卡若干，公司证件一张，饭卡一张，身份证一张，小虫照片一张。

现金损失也就算了，证件和卡后续的手续让我感觉很头大。

心情沮丧。

其实平时坐车已经很小心了，今天不知怎么就大意了。

唉。

原文链接

再谈单元测试

Mon, 16 Jun 2008 14:52:00 +0800

最近一直比较忙，很久没有更新blog了。

今天收到一封信，问了我一个问题：

关于你提出的几点：1. 单元测试是一种测试，它不是代码的一部分；2. 单元测试是最低层级的测试，它只保证函数的可靠性，不保证其它；3. 单元测试应该能保证每一个函数的可靠性。

当今前端测试的问题在于仅仅对函数的输出进行验证并不能很好的确认其行为。因为js还需要对DOM进行操作，需要对CSS进行操作，IE,FF显示效果不一致等等。使得前端开发程序员不得不人肉进行测试，查看程序是否符合预期的显示效果。你们认为如何才能提高前端单元测试的有效性呢？

说实话这个问题是我刚刚接触单元测试的时候，也一直被困扰的一个问题，那就是，GUI界面如何单元测试？我记得在几年前，我还就这个问题特地咨询过gigix，当时他告诉我说“测试能测试的”。但是当时我对单元测试一知半解的时候，对于这个答案也是不甚了了。

今天我不敢说对这个问题已经理解得非常透彻了，但是我想把我的想法说出来，大家讨论一下。

在解释这个问题之前，我想重复一下我对单元测试的理解：单元测试是最底层的测试，它只保证函数的可靠性。

但是这里有一个重要的概念，我们需要进一步的说两句：什么叫“函数”？

从语法而言，函数就是语言概念上的一个语句块，这个语句块接收0个至多个输入，产生0个至多个输出。但是，所有的语言都没有规定函数需要有怎样的“语义”。于是，我们也不能在解释器或编译器层面阻止一个“坏函数”的诞生。例如，下面这两个函数，如何测试？

x = 1;

function a()
{
   global x = x+1;
   if (x < 10)
       setTimer(100, b);
}
function b()
{
    feed = time.now();
    diff = random(feed).getInteger(10);
    global x = x - diff;
}

函数a严重依赖于函数b，以及平台相关的定时器和一个状态未知的全局变量x。而函数b也依赖于平台相关的函数time和一个状态未知的全局变量x。这样两个函数要进行测试，难度是非常高的。简单的说，a几乎可以认为是无法测试的，因为它并不是一个我们所谓的“输入-处理-输出”函数，而是依赖于定时器这样的平台相关操作，定时器这种东西是很难模拟的，就算模拟出来意义也不大，因为真实的定时器几乎可以肯定不会跟模拟的定时器有相同的表现——而这个表现，正是我们编写这个函数的目的。函数b倒是可以测试，但你必须事先为它模拟好一个时间函数（类），一个随机数函数（类），和一个确定状态的全局变量x——这些工作在一些语言里可以做到但要付出很大的代价，在另一些语言里几乎可以说是不可能的任务。

那么，接下来的工作倒也变得很简单了：我们就要做一个价值上的衡量，我花很多时间精力去实现这些测试基础框架（对了，这些基础框架也需要测试），跟我整个系统的测试工作本身相比到底值不值？

其实在大部分时候，这个答案是“不值”。如果为了一个系统的单元测试要做如此多的工作，其难度不亚于开发一个新系统，那我们当然会选择不测试。

上面的例子说明了两点：1、函数并不是天然可测试的；2、不是所有的“函数”都是需要测试的。

等一下，我记得你说过“单元测试必须保证每一个函数的可靠性”这样的话？

对。所以我们必须明确一下单元测试里函数的定义，它跟语言上的函数稍有不同，实际上，是多了一段语义限制：函数，指的是接收0个至多个输入，进行逻辑处理，并产生0个至多个输出的代码块，它的输出受且仅受输入的影响。

符合这种定义的函数，是“可测试函数”，测试它们不需要花额外的精力。不符合这种定义的函数，则是“不可测试函数”。不可测试函数又分两种，一种是无法测试的，比如系统所需的回调函数(尤其是线程、定时器之类的回调)、随机函数等等，它的输出严重依赖于系统当时的状态，而这种状态难以复现，所以对他们的测试可以说是没有任何意义的。另一种是难以测试的，它也是输入-处理-输出这样的，但它的输出除了依赖于输入之外，还依赖于系统的状态，但这种状态是可以复现的。

对于可测试函数，我们没什么好说的，单元测试教材上这样的例子比比皆是。但我们必须说，现实远没有这样理想化，完全不依赖外部环境的函数，非常少见。难道说我们就没有办法做单元测试了不成？

当然也不是这样。但是正如我上面提到，函数并不是天然可测试的。随随便便的拿一个系统就要对它做单元测试，要么是不可能的，要么是难度很大的。为了让一个系统可测试，可单元测试，我们还是要做一些工作的。

最重要的一件工作，当然就是让函数尽可能变成可测试的，再不济也应该是难以测试的，而尽量减少无法测试的函数。这些无法测试的函数，留作功能测试去测（使用人工手段或者其他的测试手段）。

举个例子来说，按上面的定义，线程回调函数是无法测试的，因为它严重依赖调用时的时间点和当时系统状态。如果你把所有的业务逻辑都直接写在回调函数中，那么整个业务逻辑就变成了无法测试的。但是这些逻辑里肯定是有一些是可以剥离出来作为固定输入固定输出的逻辑，那么就把它剥离出来，这样，至少这一部分就变成可测试了，这个经过测试的部分就可以做到一定的保障，减少上一层功能测试的压力。

第二件工作，就是做好Mock Object。纯可测试的函数是很少见的，绝大部分函数都会像上面的那个函数b一样，多多少少要用到一些基础设施，比如时间、随机数、数据库、网络等，这些东西在真实环境中是不稳定的，我们需要构造一个“虚假的”环境，为测试提供一个稳定的基础（稳定的基础当然包括“稳定出错”的情况），这样才可以为测试提供一个稳定结果。这个Mock的工作通常也是很大的，有很多东西需要虚拟，如果是一个小的系统，我们不值得去构造这样一个虚拟环境，可以尽量把其中环境依赖的部分剥离出来，对环境独立的部分单独测试，对环境依赖的部分用人工测试。然而在一个大的系统中，环境依赖部分太多，人工测试变得不可能，这时我们还是有必要认真做一下Mock这个工作的。

当然还有其他的一些工作，包括对软件过程的制定，项目配置，都会随着单元测试的引入而需要做变动，但这不是我们这次讨论的重点，暂且忽略。

说了这么多，总结一下：像显示效果这样的测试，靠单元测试是做不到的，只能用人工或者其他测试手段。但是如果你的系统是按照易于测试的原则实现的话，可以测试那些能够测试的部分，这样会给你的人工测试减轻很多压力，因为很多东西通过单元测试之后，人工测试就可以认为他们一定是正确的了。这就是我前一篇文章所提到的“分层测试”原则。

另外，测试并不是万能良药，对任何系统都可以简单而方便的实施。为了做到易于测试，还是需要在前期（如需求阶段、编码阶段）做一番努力的。

原文链接

Simpblog 测试中

Sun, 08 Jun 2008 00:30:00 +0800

Simpblog，一个用Pylons搭建的简易blog系统。初步完成了。

使用的框架是Pylons+SQLAlchemy+SQLite3。

前台使用Mako渲染，使用了Jonas John创作的CSS风格模版。

管理界面使用AuthKit做权限验证。

没有使用可视化的编辑器，使用了CreoleWiki语法，并使用MoinMoin的Creole Wiki分析脚本及HTML generator产生对应的HTML代码。

RSS使用PyRSS2Gen生成。

目前该系统还在内部测试阶段，如果发现bug，欢迎及时回报。

------------这是胡言乱语的分割线-------------

Pylons的开发还算是很快捷的，我从打算到开始动手到测试不过几天的时间。当然这跟SimpBlog的模型简单也有关系。

最初的设想是做一个庞大的框架，可是真正动手的时候，想法变了很多，我希望这个东西是能够尽快出来然后边测试边修改边增强功能，如果实现太复杂太庞大，可能在我激情消退之前都还出不来。于是就尽量快的写了一个。说它是原型也好，如果真的投入使用，也是可以不断调整的──事实上在开发过程中数据模型和想法已经做了很多改变──改变并不是坏事，我觉得。

这次在开发中尝试了AuthKit。发现AuthKit并没有想像中的复杂。如果使用得当，是可以轻易的实现很强大的授权和验证工作的。我喜欢。

Pylons的部署和开发，真是两个完全不同的概念。为了简化部署动作，我在服务器端也安装了完整的Pylons环境及其它支撑库。然后通过svn直接check代码到目标路径，用一个脚本自动运行。这样做的确是省了很多事，但令我意想不到的是，使用lighttpd的proxy之后，由于不是根目录，我的很多代码出现了问题。

首先需要解决的是一个共性问题：如何将带路径的url自动映射。幸好Pylons使用的部署工具PasteDeploy已经考虑到了这个问题。只要在development,ini的[app:main]小节增加

filter-with=proxy-prefix

并增加[filter:proxy-prefix]小节：

use = egg:PasteDeploy#prefix
prefix = /testblog

就可以了。

但是不久就发现还是有很多路径错误，原来Pylons里所有的路径都必须经由h.url_for封装，才能被prefix过滤器处理，直接写的URL是不会被处理的。于是又将模版中所有路径改写成h.url_for形式的。终于大功告成。

原文链接

19周年

Wed, 04 Jun 2008 08:45:00 +0800

对于19年前的事，真的不想多说什么。是非对错后人评吧。

写出来只是提醒自己别忘记这件事的存在。

原文链接

打算写一个新的blog

Mon, 02 Jun 2008 23:45:00 +0800

今天因为genshi的擅自修改代码的问题，以及搜索资料后发现的令人吃惊的渲染速度，我决定关注一下mako。

我想启动一个小项目：写一个简单的blog系统，来尝试一下mako模版。

根据我自己对现有blog的使用来看，很多功能其实我是不用的，比如上传文件/照片的功能，tag功能，等等。而有些功能我并不满意，比如我在群里不止一次抱怨过的编辑器。

所以我想借这次机会，实现一个我心目中的单人blog。

它要很简单，只有写blog的功能，其它什么也没有──我不需要一个完整的CMS，只要一个能写文字的东东。其它的东西，我会将它们分布到我认为合适的服务上──他们更专业。
它要有足够的扩展性，当我突然想需要一个功能的时候，我不需要到处折腾，只要修改或增加一点儿代码就能做到。
它要足够快，起码不能比现在的慢──其实我也是想看看pylons+mako到底能快到什么地步。
它要有一个对我来说好用的编辑器：不需要写一堆的<p></p>，但我想加HTML tag的时候，请给我这样的自由而不需要额外的工作。
支持回复并有效阻止垃圾评论。
纯文本，没有数据库。

当然，目前而言这肯定是一个试验性质的项目，我仅仅考虑自己的需求，而不会考虑任何产品化方面的易用性需求。但是，不排除如果真的还不错的话，我也许真的会用它替换掉现在这个，并且好好的产品化它。

原文链接

苍老与新生

Mon, 02 Jun 2008 09:36:00 +0800

很久没有发摄影类的文了。原因很简单，拍得少了，拍得让自己满意可以见人的更少了。

不过昨晚在检查照片的时候看到这张，是去江苏参加叔叔葬礼的时候，奶奶和小虫的合影，突然觉得有点感动。

奶奶年纪大了，女儿们早已嫁入夫门，作为大儿子的父亲又从小离家，叔叔成了她唯一的依靠。这次叔叔的突然去世，给她带来的打击不是我们能想像的。办丧事的几天，奶奶常常伤心得不能自己。

奶奶很喜欢小虫，小虫来到她身边的时候，她会把小虫紧紧抱住，仿佛那是她生命中的一点籍慰。那情形让人看着心碎。只有小虫的灿烂笑容，才会给全家悲伤的气氛带来一点生机和活力。

拍的时候说实话我只是随手按下了快门。可是出来的结果，我感觉是恰如其分的表现了我所感知到的那种心情和氛围。我第一次觉得有一张照片就是我想要的。

从技术角度而言，这张照片完全没有做处理。即使有什么瑕疵，我也不想使用技术手段做什么处理，我觉得我有必要保持这张照片的原汁原味，因为我自己的感动，也是建立在这份原汁原味之上的。

原文链接

六月一日

Sun, 01 Jun 2008 17:21:00 +0800

六月一日，说四件事。说给自己听，说给小虫听，也说给每个人听。

一、祝小虫儿童节快乐。

二、祝四川小朋友儿童节快乐。

三、纪念去年厦门的黄丝带。

四、传递今年汶川的黄丝带。

原文链接

[翻译]Python模式──优化轶事

Thu, 29 May 2008 00:33:00 +0800

原文见http://www.python.org/doc/essays/list2str.html

翻译：令狐虫

前几天，一个朋友问了我一个看起来很简单的问题：将一个整数列表转换成一个字符串的最好方法是什么，假设这些整数都是ASCII值。例如，列表[97, 98, 99]应该被转换成字符串'abc'。我们假定要写一个函数来做这件事。

我写出的第一个版本相当的直观：

def f1(list):
    string = ""
    for item in list:
        string = string + chr(item)
    return string

这一定不是最快的方法，朋友说，这个怎么样：

def f2(list):
    return reduce(lambda string, item: string + chr(item), list, "")

这个版本使用了与第一个完全相同的字符串操作集，但去除了for循环的开销，转用更快的reduce()函数中的隐式循环。

当然，我回答，但它这样做会在每一个列表项中产生函数调用（lambda函数）的成本。我跟你打赌它会更慢，因为在Python中，函数调用开销比for循环开销更大。

（OK，其实我已经做过比较了。 f2() 比 f1() 多花了60%的时间。你瞧，我说的没错吧：-）

唔，朋友说，我得让它再快点儿。好吧，我说，这个版本如何：

def f3(list):
    string = ""
    for character in map(chr, list):
        string = string + character
    return string

让我们俩都感到吃惊的是，f3()比f1()快了整整两倍！令我们吃惊的原因是双重的：第一，它使用了更多的存储空间（map(chr, list)的结果是另一个相同长度的列表）；第二，它包含了双重循环而不是单重（一个是map()函数中的隐式循环，一个是for循环）。

当然，空间换时间是一个众所皆知的代换方法，所以对于第一点我们不该感到吃惊。然而，为什么双重循环比单重循环还要更快呢？两点原因。

第一点，在f1()中，内置函数chr()在每次迭代中都要被查找，而在f3()中它只被查找了一次（作为map()的参数）。这个查找代价比较昂贵，我告诉朋友，因为Python的动态作用域规则意味着它首先查找当前模块的全局字典（不会成功），然后再找内置函数字典（这里找到了）。更糟的是，因为哈希链表的工作原理，不成功的字典查找（平均）要比成功查找慢一些。

第二点f3()为什么比f1()更快的原因在于对chr(item)的调用，被字节码解释器执行时，要比被map()函数执行慢一些。字节码解释器必须在每次调用时执行三条字节码指令（load 'chr'， load 'item', call），而map()函数在C代码里做这些。

这里让我们做一个折衷，不要浪费额外的空间，但是加速一下对chr()函数的查找：

def f4(list):
    string = ""
    lchr = chr
    for item in list:
        string = string + lchr(item)

如我们所期，f4()比f3()要慢，但只慢了25%；它仍然比f1()快差不多40%。这是因为本地变量查找比全局或内置变量查找要快得多：Python“编译器”对大多数函数体进行了优化，因此对于本地变量，不需要进行字典查找，一个简单的数组索引操作足够了。跟f1()和f3()比较而言，f4()的相对速度暗示了为什么f3()是一个更快选择的全部原因，但第一个原因（更少的查找）比较重要一点。（要得到关于这一点更精确的数据，我们将不得不深入研究一下解释器。）

至此，我们最好的版本，f3()，也只比我们的最直观的版本f1()快了2倍。我们还能做得更好吗？

我怕那些算法的二次行为（译注：指算法时间非线性增长的行为）会搞死我们。目前为止我们已经用到了一个256个整数的列表作为测试数据，因为那是我朋友对此函数的需求。但如果把它用在一个两千个字符的列表上呢？我们将会拼接越来越长的字符串，每次一个字符。很容易看到，除了时间开销之外，用这种方法建立一个长度为N的列表，一共有1 + 2 + 3 + ... + (N-1)个字符需要被复制，也就是N*(N-1)/2，也就是0.5*N**2 - 0.5*N。除此之外，有N个字符串内存分配操作，但对于非常大的N来说，公式中包含的N**2将会超过限度。甚至，对于一个8倍长度的列表（2048项）来说，这个函数需要花费的时间远远超过8倍；事实上，是接近于16倍。我没敢尝试64倍长的列表。

有一个通用的技术可以避免像这样的算法二次行为。对于正好是256项的字符串，我做了如下编码：

def f5(list):
    string = ""
    for i in range(0, 256, 16): # 0, 16, 32, 48, 64, ...
        s = ""
        for character in map(chr, list[i:i+16]):
            s = s + character
        string = string + s

不幸的是，对于256项的列表，这个版本比f3()要慢一些（20%以内）。由于写一个通用版本只会让它慢更多，我们就不费心在这条路上继续下去了。（除此之外我们也跟另一个没有使用map的变种做了一比较，当然那更慢了。）

最后，我尝试了一种完全不同的激进方法：仅使用隐式循环。注意到整个操作可以作如下描述：应用chr()到每一个列表项；然后将结果字符连接起来。我们已经在第一部分使用了一个隐式循环：map()。

幸运的是，在string模块中有几个用C实现的字符串连接函数。特别是string.joinfields(list_of_strings, delimiter)连接一个字符串列表，在每两个字符串之间放置一个选好的分割符。你瞧：

import string
def f6(list):
    return string.joinfields(map(chr, list), "")

这个函数跑起来比我们最快的竞争者f3()要快4-5倍。更重要的是，它没有像其它版本那样的二次行为。

获胜的是……

第二天，我想起了Python的一个犄角旮旯：array模块。它用于从一个Python整数列表生成一个单字节长度的整数数组，并且每一个数组可以作为二进制数据结构写入一个文件或一个字符串。这就是应用这些操作实现的函数：

import array
def f7(list):
    return array.array('B', list).tostring()

这比f6()大约快三倍，也就是比f3()快12-15倍！同时它使用了更少的中间存储空间──它只分配了2个N字节的对象（加上固定长度的额外空间），而f6()开始分配了N项的一个列表，实际占用4N字节（64位机器上是8N字节）──假设字符对象在程序的其它地方共享相同的对象（就像小整数，Python在大多数情况下，将它们缓存在长度为1的字符串里）。

够了，朋友说，在你得到负倍数之前──这对我的程序而言已经够快了。我同意，不过我还是想尝试多一种方法：将整个函数用C写。这可以做到最小存储空间需求（它可以分配正好N长的字符串）以及在C代码中节省据我所知在array模块中存在的一些指令，因为它的通用性（它支持宽度为1、2和4字节的整型）。然而，它不能避免每次从list分解出一项，以及从项中分解出C整型，这两项都是Python-C API中的耗时操作，因此我预期跟f7()相比最多只能得到适度的加速。跟编写和测试扩展所做的努力（对比那些快速完成的单行python代码），以及对非标准Python扩展的依赖，我决定不再继续这个选择……。

结论

如果你感受到对速度的需要，首选内置函数──你无法打败一个用C写成的循环。检查内置函数库手册，找到你想要的。如果没有，这里是一些优化循环的指南：

第一规则：仅当速度被证实是瓶颈时才优化。仅优化最内部的循环。（这条规则是独立于Python的。不过它再怎么重复也不过分，因为它能节省大量的工作：-）
小就是美。既然Python已经有了完备的字节码指令和变量查找的管理，于是很少会达到这样的一种平衡，即为了省下一些工作，而增加额外的测试。
使用内置操作。map()中的隐式循环比显式的for循环要快。使用显式循环计数器的while循环更慢。
不要在你的内部循环中调用Python写的函数。包括lambda。在内部循环中内联代码（译注：这里指的是类似C++中inline函数，将代码在调用处展开）将节省很多时间。
本地变量比全局的要快；如果你在循环中使用一个全局常量，在进入循环前将它复制到一个本地变量。并且，在Python中，函数名（全局的或内置的）也是全局常量！
尝试使用map()、filter()或reduce()替换显式for循环，但仅在你可以使用内置函数的时候：使用内置函数的map胜过for循环，但使用内联代码的for循环胜过使用lambda函数的map()！
检查算法的二次行为。但要注意更复杂的算法只对大的N有利——对于小的N，复杂不会带来什么好处。在我们的例子中，256算是够小的了，一个更简单的版本也还是很快。你的情况可能不同——这是值得去调研的。
最后但并非最不重要的：收集数据。Python优秀的profile模块可以快速的显示你代码中的瓶颈。如果你决定尝试一个算法的不同版本，在一个密集循环中用time.clock()函数测试它。

顺便说一句，这是我所使用的计时函数。它以a为参数，调用一个函数f n*10次。并打印出函数的名称后面跟着他所用的时间，四舍五入到毫秒。10个重复的调用是为了让计时函数本身的循环开销降到最低。你可以更进一步，做100次调用……。另外要注意表达式range(n)的计算是在计时段的外面——另一个让计时函数本身开销降低的小技巧。如果你确实很在意这种开销，你可以通过调用计时函数测量一个什么都不做的函数来进行校准。

import time
def timing(f, n, a):
    print f.__name__,
    r = range(n)
    t1 = time.clock()
    for i in r:
        f(a); f(a); f(a); f(a); f(a); f(a); f(a); f(a); f(a); f(a)
    t2 = time.clock()
    print round(t2-t1, 3)

尾声

几天后，我的朋友又带着问题回来了：如何做一个相反的操作？也就是说，通过一个字符串建立一个整数ASCII值的列表。哦不，又来了，这个念头在我脑海中一闪而过……。

不过这次，相对来说没什么痛苦。有两个候选者，直观的：

def g1(string):
    return map(ord, string)

和不那么直观的：

import array
def g2(string):
    return array.array('b', string).tolist()

计时显示，g2()差不多是g1()的5倍快。但这里有一个值得注意的地方：g2()返回整型的范围是-128..127，而g1()返回整型范围是0..255。如果你需要正整型，g1()会比g2()更快，无论你用什么方法对g2()结果做事后处理。（注意，在本文写作过程中，类型值'B'被加入了array模块，它保存非负字节码，所以再没有任何理由选择g1()了。）

示例代码

（略）

原文链接

这一次，我是亲历者

Tue, 27 May 2008 20:38:00 +0800

这次灾难似乎正在离我们远去。但我总觉得有些事情没有做。

虽然之前我曾经做了一些事情，关注新闻，捐款，捐物，搞各种悼念活动。可我总是难以将自己代入，仿佛自己是个旁观者，带着同情和怜悯以及些许的优越感，帮助着他们。

但事实上，我也是一个亲历者！

虽然只有短短几分钟的头晕目眩有惊无险，但毕竟我感受着的，正是千里之外的那场灾难。

只是这一次，我比他们幸运。

叔叔的葬礼正好在这次灾难过程中举办，我同时体会着失去亲人和灾难发生的双重悲痛，感受特别深。我想，我可以体会那种感觉。

我突然特别希望能够真真切切的帮助一个人，帮助他一起成长。而不是对着抽象的死亡数字发出空洞的哀伤，捐出一笔不知道会到哪里的钱就心安理得。

我是亲历者，我要跟亲历者一起，走出灾难的阴霾。

很感谢zola，他提供了一些孩子的资料，让我可以真正面对具体的人，而不是一些抽象的图像。

很感谢BT群的每一个人，他们愿意跟我一起，完成大家共通的心愿。

原文链接

全国哀悼日

Mon, 19 May 2008 19:03:00 +0800

今天是全国哀悼日的第一天，今天下午的2:28，全国人民默哀三分钟。原本我还担心一个人站着会不会太突兀，没想到一到时间，公司里大部分的人都站了起来，默默哀悼。非常感动。

可惜仍然有些人在议论和窃窃私语，破坏了原本肃穆沉重的场面。但我觉得我也能理解，毕竟这是第一次全国性的哀悼活动，不是每个人都能很快习惯和适应的。

今天工作很忙，但仍然花了一点时间将整个页面改成了黑底白字。这个风格将持续3天，也算是对全国哀悼日的一个小小的响应吧。

不和谐的声音：

随着救援艰难时刻的过去，很多我们熟悉的东西又回来了。并且可能比平日更加严苛。

一些不和谐的声音和画面也开始逐步的浮出了水面。隐约的看得到一些与主流媒体不同的画面。

这些东西让我感觉到，这次灾难很可能只是一个特例，奢望因为这次灾难推动整个国家大踏步前进，还是不太可能的。灾难过后，尘归尘土归土，一切又将恢复平静。

我只希望这次灾难过去之后，能留下一些什么，不要让所有的进步都随着灾难的消失而灰飞烟灭。另外，我特别希望那些那些出来混的，把该还的还了。几万人的生命，难道还不够换一个良心么？那些发灾难财、成为间接凶手的人们，你们就不怕冤魂缠身么？

沉痛悼念在地震中失去生命的同胞们

原文链接

该做的终于都做了

Sun, 18 May 2008 22:26:00 +0800

不管做得早还是晚，总比不做要好

中国地震局已将汶川地震震级从7.8级修订为8级

国务院公告：5月19日至21日为全国哀悼日

为表达全国各族人民对四川汶川大地震遇难同胞的深切哀悼，国务院决定，2008年5月19日至21日为全国哀悼日。在此期间，全国和各驻外机构下半旗志哀，停止公共娱乐活动，外交部和我国驻外使领馆设立吊唁簿。5月19日14时28分起，全国人民默哀3分钟，届时汽车、火车、舰船鸣笛，防空警报鸣响。

北京奥组委决定：奥运圣火19日起停传3天

原文链接

灾难

Fri, 16 May 2008 13:41:00 +0800

叔叔去世没几天，丧事还在继续的时候，地震发生了。

这是一场更大的灾难，已经有万余人失去了生命。处于双重悲痛中的我，感触特别深。只是在老家无法上网，不能上blog写下自己的感受，不能为灾区尽一份力，也是非常惭愧。只能通过手机短信的方式，先捐上有限的几元钱，表达自己的一份心意。

今天终于回到公司，又可以上网。比较欣慰的事情是现在救灾情况已经开始慢慢好转，不像初期那样艰苦，救出的人也在慢慢的增加。我也没有什么可做的，再捐些钱，希望能帮助到灾区的人们。

希望这就是今年最坏的情况了。天佑中华。

另外我想说，这次地震的确暴露出很多的问题，但现在追究有些太早了。目前还是把精力关注在救助上吧，那些问题日后可以慢慢追究慢慢反思。出来混，迟早要还的。

爱心行动：

爱德基金会

寻找灾区的亲人

一切为了孩子．msn彩虹行动

原文链接

天灾

Tue, 13 May 2008 08:58:00 +0800

四川7.8级强震近万人死亡

为大地震的死难者默哀。

原文链接

胡言乱语

Thu, 08 May 2008 23:44:00 +0800

叔叔突然走了。非常突然。

下午1点多的时候他还给我奶奶打了电话，十几分钟之后，单位就发现他晕倒在位子上，赶紧送医院，已经回天乏力。

一个人从生到死，需要多久？

而我在做什么？

晚上还在跟同事聚餐，说一些开心的笑话。接到消息后赶回家，居然还打开电脑，一条条的看着Google Reader上的消息，在SNS网络里检查，回复，仿佛没事人。

狼心狗肺的家伙。一个声音对我说。

事实上，我跟叔叔感情并算不深。我从小在杭州长大，他在江苏。我们的生活没有任何交集，只是从父母的嘴里知道我的老家在江苏，江苏有奶奶，有叔叔婶婶。然而当时，他们对于我而言，只是一个称谓。

稍大一些的时候，我转去江苏念书，寄宿在奶奶家，于是才跟叔叔有了来往。然而这种来往仍然并不十分频繁，短短三年之后我又离开江苏回到杭州，从此除了回老家拜年，叔叔又变成了一个抽象概念。直至今日，我甚至说不出我印象中的叔叔究竟是个什么样子。

然而很快的，还是有一股悲意涌上了心头，让我决定写下这篇blog。是的，虽然叔叔对我而言，更多的只是一个称谓，然而毕竟他是我的亲人。我知道在不远的地方，有这样一个人，他关心着我的成长，见面的时候会给我祝福和鼓励，他有自己独立的思想，我可以跟他讨论各种问题，从而产生碰撞的火花。即使他的轮廓如此模糊，我依然真切的感受到，他存在着，我们会见面的。

然而突然，他不再存在，我们也永远不能再见。我真的失去了一位亲人。在风雨飘摇中，我突然之间少了一份依靠，哪怕这依靠更多是凭空幻想而得，但毕竟是一份依靠。

叔叔的儿子正在准备考试，还不知道这件事，家人怕影响他没有跟他说。我觉得这是一个非常残忍的决定，但却又无可奈何。死亡这件事说大不大说小不小，对于逝者，只是一瞬间的事，而对于生者，则意味着很多很多。

是以为凭。

原文链接

默哀说一句话

Tue, 29 Apr 2008 10:43:00 +0800

胶济铁路火车相撞70人死亡416人受伤

幸运的姜大宝

老詹

当我们面对数字已经麻木，是时候关心一下出现在事件中的具体的人了

原文链接

单元测试

Mon, 28 Apr 2008 13:36:00 +0800

周五跟猛禽聊了几句关于单元测试的问题。正好最近参与的一个项目里我也把单元测试放到很重要的位置并且也发现了一些问题。顺便整理一下。

这不是一篇严谨的技术文章。只是一些个人不成熟的感想。

在实际开发过程中，我发现在单元测试代码中经常会出现两种情况：第一种就是在测试代码中炫耀编程技巧，第二种就是敷衍了事，你不是让我通过测试么？好，我就写一个用例，一定能通过的那种，然后告诉你，OK，我的测试通过了。我觉得，这就是对单元测试的意义没有真正理解的表现。

到底单元测试是做什么用的？我想，在说明这个问题之前，我先说说我所理解的测试到底是做什么用的。

所谓的测试，是一种产品质量保证的手段。我按照需求规格说明书制造了一件产品，那么谁来确保这个产品符合了需求规格的要求呢？就是测试。它会根据需求规格说明书设计一系列的场景和用例，来对产品进行测试，看看产品是不是真的符合所期望的需求。

要达到这个目标，其实并不十分的容易，因为一个真正的系统，情况十分复杂，里面充满了数不清的分支、异常、边界条件，甚至运行环境，将这些东西组合起来，产生的需要测试的点将会是一个天文数字，在有限的时间内做完一个充分而可靠的测试，是不可能的。

为了将充分测试变得可能，一个比较好的途径就是分层测试。我在做运行测试或性能测试的时候，有一个前提，就是假设整个系统的集成运行已经没有问题了，在运行测试或性能测试时，我将不再考虑“系统无法正常运行”这种场景。那么如何保证集成运行没问题呢？我们用集成测试来检验。但是在做集成测试的时候，我们同样要基于一个假定，就是各个模块的功能都能够如期正常工作。而这一点，又是通过模块自身的功能测试来完成的。……这样一层层往下推，每个层次就假设它所依赖的层次没有问题，这样就可以减少很多场景以及由这些场景引出的额外的分支。将原先一个几何级数的测试用例分解成可以接受的若干层次的算术级数的用例。这样一来测试就变得有可能做好了。

而单元测试，正是这些测试的最低层次——保证每个函数/方法，或者说最小功能模块的正确性的一种测试。

通过上面的描述，我们至少清楚了这样几件事情：1. 单元测试是一种测试，它不是代码的一部分；2. 单元测试是最低层级的测试，它只保证函数的可靠性，不保证其它；3. 单元测试应该能保证每一个函数的可靠性。

单元测试是一种测试，所以，我们应该以一种测试的眼光去面对它——我们要测试正常情况，边界条件，要对它的测试目标——函数做黑盒分析，白盒分析，选择合适的测试数据，构建测试场景和测试环境——总之，一切测试应该做的事情，单元测试都不应该省略。

理论上来说，单元测试和其他测试一样，也是可以纯手工完成的：我们可以写一段某函数的测试代码，然后输入我们的测试输入，观察测试输出，并跟期望值做比较——事实上这种人工测试，写了一段时间代码的人应该都不会陌生。但是，单元测试有一点特殊性，就是在一个系统中，函数会非常非常的多，变化也比软件的功能频繁的多。面对这么多的函数，这么频繁的变化，纯手工测试是不现实的。所以，我们必须要引入单元测试框架进行自动化测试。注意，这里的单元测试框架只是实现自动化测试的一个手段，对单元测试本身并不产生任何影响——没有单元测试框架，单元测试一样也是可以进行的，只是会痛苦很多。

单元测试框架引入的目的只是为了自动化单元测试，简化单元测试的步骤。所以，对于测试代码的编写，我们的重点应该是：1、如何搭建测试环境、测试场景；2、如何选择测试用例；3、如何校验测试结果。对于测试代码本身，应该尽可能的简单，能不要使用技巧尽量不要使用，我们的目的在于测试，如果测试本身过于复杂，我们不能保证测试的正确性，测试这个工作就白做了。

另外，刚刚提到单元测试是对函数的测试，因此，测试必须是以函数为单位的。每个函数应该拥有自己单独的一个测试，但是在这个测试中，我们应该针对这个函数的各个方面：正常的、异常的、边界的……等等，各个方面进行完善的测试，这样我们才能保证这个函数的功能是如我们所愿的。但是单元测试不需要负责函数的组合工作情况。那应该是(低层次)功能测试的工作，而不是单元测试的工作。这个功能测试就是在假定所有函数都工作正常的基础之上，对这些函数组合形成的功能模块进行测试。这种测试，视情况而定，可以使用单元测试框架，也可以使用其他自动化测试方法或者甚至是使用纯人工测试。

另外，我还想讨论一下单元测试的编写和运行。

绝大部分时候，单元测试的编写，是由开发人员做的。我们在以前某次对单元测试的讨论中，甚至有人认为，单元测试必须由开发人员完成，而不应该由独立的测试人员完成。对于这个问题，我是这样看的：测试是一种针对需求的验证工作。如果这个需求非常清晰，清晰到开发人员之外的人都可以轻易掌握（有些日本外包发出来的函数说明书就能达到这一点），这时单元测试可以由独立的测试人员完成。但是大部分情况下对于函数级别，做不到这一点。这时最清楚函数需求的人就是开发人员本人，在这种情况下当然就应该是开发人员自己编写测试用例。但是开发人员必须搞清楚自己身兼两个不同的角色：运动员（实现代码）和裁判员（检验代码），在编写测试用例的时候绝不能假定任何函数的实现，而应该完全按照它应该有的需求来做。这样才能做好单元测试这件事。很多时候单元测试形同虚设，就是因为开发人员没有很好的转换自己的角色造成的。

单元测试的运行，目前我们这个Python的项目比较容易，直接运行模块就是该模块的单元测试，而以模块形式import就是实际使用。对于像C++或者其他的一些语言来说，可能没有这样方便的形式。我们可以把测试写在独立的文件中，然后用makefile组合不同的项目和主函数来做到这一点。另外还有一点就是，实际运行过程中可能会有一些环境，这些环境在测试时难以获得，或者增加上去之后，就难以测试（比如网络环境、数据库环境等等），这时我们可以采用一些虚拟的环境来做到。我们把运行时需要的环境做一个简化的虚拟版本，然后以这个版本作为测试环境进行测试，对于Python来说，我们可以实现这样的一个库在测试时import进来并且同时做一些环境初始化工作，在C++里，我们可以专门为测试写一些运行库，在实际运行编译和测试编译时，链接不同的库。这在自动化测试技术中有个专门的名称叫做 Mock Object。关于这个，我就不再深入了。

原文链接

[补记]418群P小记

Mon, 21 Apr 2008 17:01:00 +0800

话说饭否猛禽、京京互相扭捏几日，约在4月18徐家汇群P。

下班后匆匆忙忙赶往群P地点，到目的地后，发现猛禽京京已经在一起了【注：不许联想】。不久，MK、女王陆续赶到。商量FB事宜。

在MK的推荐下，一行人等走啊走啊走啊走啊走了很久，最后来到超没创意的葡京煲煲好坐定。

点完菜没有上的时候，MK突然掏出两大坨东西说是送给京京的礼物。结果原来是二者择一。据说另一枚要送给表妹？京京选好正开心的准备拿走之时，MK大喝一声“慢”，遂从袋中掏出一物，众人定睛细瞧，原来是AA电池两付。再打开礼物，只见一只小毛驴做张牙舞爪状。装上电池，MK温柔地捏了一下小毛驴的手，那小毛驴居然疯狂扭动起来。众人崩溃。

送礼物仪式完毕后正式上菜，只记得有猛禽最爱的豆腐以及让大家很囧的包裹着芥末的炒青菜。席间边吃边聊，倒也收获无限。

京京贡献了女仆装、BL、同人、攻、受等很黄很暴力的词若干。

MK贡献“一个鬼子三百块”经典语录一句。

女王贡献学漫画的表妹一个，故作纯情状一份。

猛禽贡献信用卡一张，照片若干。

令狐虾米也没有贡献。很傻很天真的笑了一晚。

饭毕想群P MBA未遂。在地铁站分手后猛禽和京京独处，后续事宜不得而知。【注：不许联想】

原文链接

坚决你的立场，宽容你的态度

Tue, 15 Apr 2008 14:30:00 +0800

最近因为西藏以及奥运火炬的事情，网上显得特别热闹。有些人骂有些人汉奸卖国贼，有些人骂有些人愤青低能儿，有些人想一边呆着吧，结果被人骂冷血胆小鬼。总之无论你站在哪个立场，基本上都不会避免被攻击的命运。如此景象实在是很难不让我联想起40年前极其相似的一幕。

最近又有人因为奥运火炬传递在法国的遭遇，呼吁大家抵制家乐福超市。于是乎因为抵制不抵制的问题，又吵得不亦乐乎。

我不知道为什么很多人会有这样一种想法：世界上只存在一种正确答案，除此之外的答案都是错的。并且很多人会不厌其烦的试图去纠正别人“错误”的想法。其实这么做，跟他们所痛恨的洗脑、填鸭式灌输有什么本质的区别呢？

世界上的很多事情都不止只有一种正确答案。我们要坚持自己所认为的那个正确的答案，并找到足够的证据去维护它，不要轻易的被他人左右。另外，我们也应该宽容对待其他的答案，因为他们也有可能是正确的。不是么？

西方媒体错了，不等于中国政府做得对；同样的，中国政府做错了，也不等于西方媒体就正确。有人想抵制这个抵制那个，我觉得没问题，但是并不代表不抵制的人就不爱国不正确。烧杀抢掠是犯罪行为，当然是要反对的，但如果认为对方犯了罪因此自己就可以对他烧杀抢掠，这就不对了。

说到这里我重申一下我的立场：作为中国人我反对藏独，但我可以接受在中国之外的和平示威的行动。我也更加支持中国人无论在国内和国外，以任何形式的和平示威表达自己政治立场的行为。但我反对任何形式的暴力行为，无论是藏独者还是爱国者，也无论是肢体暴力还是言语暴力。

原文链接

生命未必是用来浪费的，但……它是你自己的

Thu, 10 Apr 2008 14:56:00 +0800

猛禽写了一篇《生命是用来浪费的》，写得深于我心有戚戚焉。不过，我觉得还是有点话要说。

我想说话之前，总得先定义一下什么是浪费，否则在一个意义不明的基础上讨论，总有点鸡同鸭讲的味道。

根据猛禽在文中的描述，我想，这里的浪费应该指的是：花时间在某件事上，却没有实质性的回报。(实质性是指给自己带来名、利或其它普遍意义上的好处)

我曾经碰到过一些人，他们从不做“浪费”的事情。他们所做的每一件事，都是精心计划的——赚钱，投资，赚更多的钱，提升自己的生活品味，交更好的朋友，利用人脉，做更有野心的事……。闲情逸致对他们而言是没有意义的，并不是说他们不活动，他们很会休闲，很会玩，但是他们是当作一种感情投资在做这种事的。

他们有房有车，有钱有闲，但他们并不像我们认为的那样奔波劳累，生活枯燥。事实上他们一样活得很开心。因为这些事情就是他们的追求，就是他们快乐的源泉。

这又有什么不好呢？

诚然，我们无法理解和认同他们的生活，他们同样也不可能理解和认同我们的生活。但是，两种人都有自己存在的理由。我们无需也不该因为自己站在某一边而去BS另外一边的人。

每个人都有自己的想法和活法。关键还是要活着开心。毕竟，生命是你自己的，你有权也有责任把握它。不是么？

原文链接

裸奔之后

Thu, 10 Apr 2008 13:47:00 +0800

昨天听说是CSS裸奔节。于是就跟风了一把。

结果：

裸奔之后页面还算蛮整齐的。
发现Skip to content功能有bug，修正之。
N多人问我的blog怎么了，是不是坏了。

装相反的D的感悟：

我对页面标准还是有点概念的。得益于Firefox为我打开的那一扇窗。
有些问题会被华丽的外表所掩盖，只有剥去层层包装，问题才能得以显现。
虽然从本质上而言，核心内容才是最重要的，外表展现不过是对内容的包装，但真的将核心内容赤裸裸的暴露在大众面前，很多人会无法接受。因此，适当的包装对于很多人来说，还是很必要的。
一切外表大过的内容的东西，难以长久。

原文链接

听说今天是CSS裸奔节

Wed, 09 Apr 2008 13:17:00 +0800

我也凑凑热闹，裸奔一天

附页面截图：

From babyfish:

第三届CSS裸奔节来了，今年（CSS Naked Day ‘08）的时间定在4月9日。

活动目的CSS裸奔节的目的是推动Web标准。简洁为美。使用正确的(x)html，语义标记，良好的层次结构。暂时把页面设计抛弃，直接展示<body>吧。

原文链接

假日观影

Mon, 07 Apr 2008 11:23:00 +0800

清明放假三天，彻底的放下了工作。补习了几部电影。

《长江7号》

之前看过听过很多对它的恶评，以至于看的时候心有惴惴。不过看完之后感觉还好。

说实话，这是一部挺幼稚的电影。对于电影本身，没什么可说的。但是看的时候，我突然想到些别的。

很多大人对着小孩子，都会要求那小孩子“来，笑一个”，“来，亲一个”，“来，走路看看”……。小孩真的那样做了，大人就会哈哈大笑。

小孩长大了，有自己的想法，开始玩过家家了。大人于是就无聊的走开，心里想着，这种无聊的小孩子玩意，谁要在乎呢？

殊不知小孩子自己是在乎的。他是在很认真的做着一件很幼稚的事情。我们应该尊重小孩子的这种认真。

小孩子不是为了逗大人开心而活。他们也有属于他们自己的想法和生活

在我看来，周星驰早期的电影，正是扮演了逗大家开心的角色。现在的他很认真的做了一部电影，虽然幼稚，但很认真。我们还是应该给予足够的尊重。

《罗拉快跑》

很早以前，看过海报。对罗拉的一头红发印象深刻。这次终于看完了这部电影。说实话，被《蝴蝶效应》近乎疯狂的多线结局熏陶之后，我对多线结局已经有了足够的免疫能力。因此对三段结局还没有感觉到太震撼。不过非常喜欢罗拉奔跑时的配乐和镜头运用。那是一种不同于好莱坞式镜头的新鲜体验。

尤其喜欢对每个人的那些闪回镜头。短短几秒钟就交待了一个完整的故事，在震撼之余，会忍不住想。我在路上碰到的每一个人，会有怎样的属于自己的画面呢？

结尾颇感意外。一直处于焦点位置的10万元，到最后突然失去了存在的意义。也许人生就是如此反复无常，你追求毕生的东西，也许到头来就是一场空。谁知道呢。也许我们应该享受这追求的过程，不是么？

《BeeMovie》

典型的好莱坞动画。但好笑的是居然让我看到了一些政治隐喻。那个被拉倒的熊罐，分明像极了萨达姆铜像。

将自己对世界的认知应用到他人的世界，由此带来严重的后果，这难道就是好莱坞对于伊战的反思么？

但愿是我曲解了影片本身。也许这个电影就是一个庸俗的动画片而已吧。

《牯岭街少年杀人事件》

要看完一部长达4个小时的电影，是颇需要下点决心的。

尤其杨德昌的电影，总是在不紧不慢的叙述中，将思想慢慢的输送给你，让你在乏味的体验之后，回头想想，感觉到背脊发凉。

不出所料，电影的前一个半小时，什么也没有发生。

要不是那些青涩、青春和叛逆勾起了我对往日的回忆，我几乎就要放弃了。

然而在枯燥背后，也隐隐的感觉到了一些什么。

果然，一个半小时之后，事情开始慢慢的显现出来了。

开始死人，开始流血。少年的世界，渐渐被成人的世界侵蚀。

最后小四用刀捅向小明的时候，我掩面长叹。

一部黑色的电影，没有光明的电影。这电影里其实谁都没错，那么到底是谁错了呢？

我突然很庆幸我居然活到了今天，还没有发疯。

原文链接

历史上的今天

Tue, 01 Apr 2008 10:22:00 +0800

不用大家提醒，我也注意到了今天是愚人节。

也许有些人会觉得愚弄别人很开心，但因为曾经有被愚弄到留下心理阴影的前车之鉴，我并不太喜欢这个节日，更不希望在今天被人愚弄。

说点其他的吧。

1998年3月31日，愚人节的前一天，Netscape公司发布了Netscape Communicator 5.0的源代码，并成立mozilla.org。几经周折之后，2002年，Firefox从这里浴火重生。也许Firefox并不能称得上是一个完美的浏览器，但是正是因为它的出现，让那些原以为IE就是一切的用户们，知道了什么叫“web标准”，知道了更多更好的页面开发技术，也推动了停滞不前已经很久的IE又再次奋起直追，IE 7.0和即将推出的IE 8.0，也因此把对标准的支持，放到了一个很重要的位置上。原先存在很久却无人问津的ACID页面标准化测试，又被翻出来作为炫耀的卖点。

2004年4月1日，Google推出Gmail。在当时各个邮箱供应商纷纷缩减邮箱空间，甚至嚷嚷着说“收费才是唯一出路”的时候，免费的1G邮箱无疑是一个重磅炸弹。一年之后的又一个4月1日，Gmail又推出了“容量无限大+1”的概念，容量自动增长。到今天，Gmail的容量已经6G多了。虽然现在几乎所有的邮箱都跟当时的Gmail一样有超大的容量，有方便的用户界面，甚至做的可能比gmail更好。但是，正是Gmail，才让大家跳出了一个思维的定式，意识到“邮箱还可以是这样的”。

其实很多伟大的产品，它的伟大之处并不在于他自身有多么的优秀。再优秀的创意，总有一天可能会被人超越。但是当你接触了它之后，你的面前会开出一面窗，让你接触到原先你并不会去留意的美丽风景。也许想接触这美丽并不容易，你需要自己付出很多努力。但是，当你真的触摸到了窗外的美丽，你还愿意回到当初，面对四壁白墙么？

原文链接

休假归来

Mon, 31 Mar 2008 10:32:00 +0800

假期结束，恢复到上班状态。

突然发现今天居然是3月的最后一天了，而明天则是传说中的愚人节。希望不要有人来愚弄我，我不喜欢这种感觉。

在休假期间主要还是把精力放在了g4p方面，做了代码的Code Review并且提交了自己的代码。看着这个项目的代码渐渐的多起来，虽然还没有到可以初步运作的程度，还是觉得很高兴。

昨天跟g4p项目组的人员碰了一下面，交流了一下目前项目的进展和问题。解决了一些问题之外，大家对当前的项目进度还算满意。毕竟刚刚开始，而且面对如此松散的团队，没有具体的激励形式，大家对开发语言和工具的掌握还有待改善的情况下，不能对项目的要求过于严厉。后期可以逐步的加快进度。另外还初步的讨论了一下网站的定位和发展的问题。不过我们都觉得现有的目标不做大的改动，把想法都记录下来，等到我们有东西出来之后再考虑。

当然，秉承BT群聚会一向的BT风格，海阔天空仍然是免不了的。在项目讨论之外，我们还讨论了一些创意想法、黑客技术、IT业界以及其他河蟹及不河蟹的话题。其中有人提到说现在李开复和唐骏都属于那种没做什么事的人，为什么还在那个位置上呆着。结果今天一早来就看到了唐骏离职的消息。为BT群深厚的BT威力囧一个。也为开复Lee以及我们提到的另两家知名网站捏一把汗。

原文链接

休假

Wed, 26 Mar 2008 12:09:00 +0800

休假三天，下周一上班。

基本安排：

睡觉、吃饭、带小虫
聊天、打屁、狗屎皮

原文链接

永远有多远

Mon, 24 Mar 2008 14:19:00 +0800

最近忙，没有及时读朋友的blog。今天看到了Jessie的可不可以不联系，突然想起了自己的年少时光。

虽然没有Jessie MM这样丰富的人生，但少年时也免不了有些天荒地老海誓山盟。可是现在想想，其实也没有很多年，那些永远的誓言，转眼间就成为了天边的浮云。

回首过去，物似人非，自己身边的朋友，竟然变化了一茬又一茬。一路走来倒还不觉得，一回想还真让自己吓了一跳。曾经的那些死党，现在发现竟然连联系方式都不曾留下，唯一留下的，只有那些曾经的记忆片段了。

曾经以为永远很遥远，曾经以为朋友是一辈子的。现在看来并非如此，我们总也不知道明天会发生什么，总也不知道未来会怎样。锵锵的誓言今天看起来是如此的虚无缥缈。目前我们能做的，只能是把握好现在的每一天，把握好身边的每一个人，把握好我们一起做的每一件事。日后当真天各一方之时，至少可以拥有一个美好的回忆：

想当年啊，我曾经有这样一个朋友……

原文链接

[一句话]我们不仅要看他说什么，还要看他做什么

Tue, 18 Mar 2008 14:41:00 +0800

今天听了温总理的记者见面会，记住了这样一句话。本来是送给达赖的，我想也应该送给温总理自己以及各级政府官员们。

原文链接