hotcopy

很多数据服务软件需要涉及hotcopy（或者hotbackup），就是在不停止服务的情况下做备份，要做一个"正确"的hotcopy不是很简单，主要是保证如何数据被修改时防止得到一个"不一致"的数据。
mysql的几个做法：
1) mysqldump提供了一些参数（--lock-tables），可以在dump期间lock整个database，这当然就没有问题了，但是导致备份时写操作不能做了。而直接拷贝数据文件的方式则是不安全的。
2)为了不限制写操作，可以使用mysql的replica，然后在lock slave的情况下做dump。

svn也一样，直接拷贝repository是不安全的，需要使用svnadmin dump命令，这个命令甚至可以做增量备份（从A版本到B版本），这个强啊。

svn的权限控制

分三种情况（访问svn的方式），总的看还是比较清晰的。

1. 如果使用 file:// 来访问svn（本地访问，或真网络共享），那么svn本身不提供任何额外的访问控制，完全依赖于文件系统的用户访问控制。

2. 如果使用svn://协议（即在服务器端单独运行svn的server），那么svn提供了基于用户/密码的基本访问控制，可以设置用户的权限为None，Read，Write，但不能针对目录设置权限。

3.  如果使用apache的mod_dav_svn来访问svn，也就是通过http来访问（sourceforge的方式），那么这个权限控制就可以搞的很复杂，是在apache里面设置，可以设置到目录一级。

似乎svn不能区分create,delete,write这几种权限，也就是说只要开了写权限也就可以创建和删除了，或许可以通过hook来做。。。

又一个TBD

TBD这个词确实时髦啊，比如To Be Determined，又如To Be Done，已经搞的我每次看到它时都心虚的查查字典，最新一次看到它，TDB家族又出了一个兄弟 -- Tracer Bullet Development（字典上可查不到）。

出自于《Ship It！》一书，指一种软件开发方法，类似于敏捷开发，强调快速，迭代和反馈，我基本上能认同这个方法，但这个名字确实让我看到时云里雾里，以为是一种什么新式的方法学。。。呵呵

顺便小赞一下这个书，从实践的角度解释了作者所推崇的软件开发方法/过程/工具，给出了一些实践，并分析了原因和应用方法，深入浅出，比什么CMM的虚无缥缈要实际多了。

Djangobook

Django book，又是一本免费的电子书，和Svnbook一样，内容很棒：
http://www.djangobook.com

除了内容之外，令我十分欣赏的是，Web版的Django book提供Cooooooool弊了的反馈系统，每个段落的左边都有一个按钮可以留下看时的意见，有一些段落我看的不太理解，点这个反馈系统就可以看到别人可能的同样的疑惑，以及看懂的人的留下的解释，有点P2P的意思，呵呵。

稍微有些困惑的是，如果章节段落调整了之后，这些comment怕是保不住了，不知作者是怎么处理的？

解析Javascript“乱码”

有些颇有心计的网站为了某些原因，会在Javascript上做手脚来"加扰"源码，典型的特征就是没有回车了，所有的代码揉成一行，相当壮观。我试过Linux下的一些编辑器来编辑这种源码，VIM和gedit都会被搞晕，变得很慢（当然是设置为Javascript代码时才会晕），KDE下的Kate表现的不错，可以非常快的高亮这种Javascript乱码，赞一个。但这几个编辑器都没有美化代码（重新排版）的功能，看起来还是头大的，不过网上有很多网站可以做这个事情。

还有一些加扰度更高的Javascript代码，它们是用代码生成代码，这样就可以用一个长长的字符串，通过移位，替换等运算再得到源码，这个重新格式化也不顶用，需要先写一个HTML文件嵌入这段代码来让它运行一下，以得到解码后的代码，然后就好办了。

还有更复杂的"加扰"方法吗？ 不过相信也是能对付的，毕竟JS是源码解释执行的。

gcc优化bug

#include <stdio.h>

int main () {
    int i=2;
    printf("%d\n", (-10) * abs((i-1)) );
}

这个代码在我的Linux下的gcc 4.1版本下居然居然。。。居然 输出 10，我晕了还是gcc晕了。。。。

搬出google，告诉我 这是一个优化的bug（为abs所做的优化），在编译时加上 -fno-builtin 可以禁止这个优化（gcc -fno-builtin a.c），就避免了这个bug，试了一下，果然灵验。

不过想想还是有些心惊，这是编译器啊，如果把一个系统比作大厦的话，这可是地基啊，怎么能有这个大的漏洞。。。。寒！

django II - 后台admin

django将后台的管理功能，做为其一个"killer feature"，我自然试用了一下，这个后台数据库的管理功能是一行代码不用写的，只要在settings.py中将其加入APP，并赋予其一个URL即可：
- 最基本的插入，删除，修改自然是不在话下，并且有严格的校验。
- 各种类型字段都有不同的输入方式，比如在创建的记录中的外键字段，可以用列表选择，无需手动输入。
- 支持操作历史记录，并且保存了每条记录的修改历史（如何做到的？）。
- 可以管理用户和组，并针对用户和组赋予不同的管理权限。
- 良好的定制功能，可以定制后台中记录的显示方式，Filter，排序等。

从这些功能来看，用强劲不为过，可以让程序员集中精力放在前台，不过这个后台功能看起来并不是应用相关的（通用的后台不可能做到啊），而是Model（模型，或者说数据库）相关的，因此对某些应用可能并不是合适，但不可否认它的价值。

erLang I

变量只能赋值一次，且只能以大写字母开头，这是什么语言？是的，它确实存在，而且在快速发展中（虽然远未达到主流），它叫做erLang。

在学习PHP，Python，Java的时候，已经感觉不到初学C语言的那种新奇与陌生，而在erLang面前，这些感觉又回来了，这是如此奇怪的语言，但确实实实在在用于分布式系统中（起源于爱立信的一个项目），现在已经开源，在Ubuntu下可以一条命令安装它的开发环境：
sudo apt-get install erlang

然后用erl就可以启动它的shell，用于简单的表达式运算，Ctrl+G再q退出（同样奇怪。。。），就算不能用上它，看看这个语言如何用于分布式系统也是一件有意思的事情。

Django 印象 I

以前曾经用过PHP的框架Codeigniter，印象不错，当时就曾经想过不知有没有好用的Python框架，看了这篇对比之后，开始对Django有些兴趣，正好是周末，就试用一下看看：
在Ubuntu 7.10下可以直接安装django了，十分方便：  sudo apt-get install python-django,django的框架结构和codeigniter类似（可能Web框架看起来都很像），但细节还是有很多的差异，并且django比codeigniter要"重量级"一些，提供了更多的功能。

- 语言方面是最大的差异，Python的强势可能使得django要底气更足一些，但PHP在Web方面显然要更成熟一些，最简单的例子是，想找一个支持python的hosting都不是很容易。
- django的URL映射比codeigniter要复杂，使用了单独的正则表达式来完成URL到Python函数的映射，codeigniter则直接将URL对应到class function。两种方式我看不出哪种更好，似乎django的方式扩展性要好一些，而codeigniter的方式要简单一些。
- 模板方面，django有自己的模板语言（但不强制使用），而codeigniter直接用php，这两个比较的话，django的模板显得要稍清晰一些。
-  数据库方面，django支持还算广泛，它的一套对象映射机制（ORM）还没有看完，不过我想应该不会比codeigniter的简单映射要差吧。
- 在设计方面，django强调松耦合和MTV（这个术语好奇怪，别人都用MVC，意思基本上是一样的），这个松耦合还是做的不错的，各处都有体现。

这些是基本的感觉，不过没有用它写过代码是不能妄下结论的，希望我还能写第二篇。。。

Java字节码编辑

Jad和ForntEnd Plus可以很好的反汇编Java程序，但得到的反汇编Java源码不一定能再编译（有一些代码是可以的，所以我不知道为什么有些就不行），这给有些h**k工作带来了障碍，幸好还有直接的Java字节码编辑程序可以用，比如：
Jbe： http://cs.ioc.ee/~ando/jbe/ 这个是直接针对Java的，比较轻量级，它自己也是Java实现的。
IDA：这个可是重量级的工具了，针对各种语言和平台，不过5.0以后的版本才对Java有较好的支持。

有了这些工具，哈哈，为所欲为啊。。。

Javascript性能感受

每次我看到一个页面（主要是指我自己实现的）加载很慢时，我就想知道藏在背后的瓶颈是什么。

拜charles所赐，我可以容易的观察HTTP交互中的耗时，但今天的一个页面令我稍有意外，因为瓶颈是在客户端的Javascript的执行上（charles测不出来），非常明显，当我使用firefox的Web developer工具条中的disable javascript之后，流畅的感觉就回来了（快一倍左右），所以用Javascript的同学们，悠着点。。。

尽管大多的评测表明IE6的Javascript性能很差（IE7好一些），比如下面的这篇：
http://www.zimbra.com/blog/archives/2006/10/firefox_2_vs_ie_1.html
但我的实际感觉不是这样，我甚至认为IE6都要稍快于Firefox 2，难道是我的感觉系统出了偏差？

charles - HTTP瑞士军刀

嗯，得提一下这个非开源的charles软件，这是个让我惊讶的软件，我本想找的是一个可以监视http的软件，又不想动用Ethereal（后改名为WireShark）这样的牛刀（而且这个牛刀用来监视http也不好用），一番gooooooogle就发现了这个Java版的charles。

除了满足了我的http监视需求外，charles还是一个下载软件（它不仅监视http头部，还把所有的内容也截获下来了，所以可以下载，这个用途很多啊，省略省略。。。）,charles还可以显示XMLRequest的内容，也就是可以作为AJAX开发的调试工具，用于显示Browser-Server的交互过程。

charles的独特的设计是它并没有监视底层的数据包，而是直接通过浏览器的proxy来完成截获，这样就不影响所有的非浏览器网络应用，性能较好，也方便charles来解析http数据流。这个设计是charles的关键，它使得charles具备了上面的优点，同样它也有很大的缺点，比如只能检测http流，而且对于非浏览器的http请求很难处理（可以通过charles的反向proxy来解决这个问题，但不是很完美）。

由于charles基于浏览器的设计，对于firefox，需要安装一个插件，IE不需要，这样在使用charles时才能自动配置浏览器的proxy，不过易用性还是做的相当不错的，无需手动的配置，基本上是即装即用了，不错的说。

Docbook 编译

Docbook很好，我喜欢。所以了解它的"编译"过程是挺有意思的事，典型的两个方法是：
1）以Svnbook为例，它使用gmake来写makefile，基本上这个makefile还是很简单的，有几个关键的target和rule，分别用于生成各种目标文件类型，比如HTML，PDF等（为了生成pdf，需要先生成fo文件），还有几个公共的make target，比如version用于每次make时更新版本号，这个版本号会记录在一个xml文件中（ 比如version.xml），这个xml文件将被包含在最终的book中。用于格式转换的工具，是最基本的xsltproc（c实现的）和fop（用于将fo文件转换到pdf），可惜fop在中文处理上有些瑕疵（中文，哎），需要不小的调整。

2）Diveintopython则走了Java的路线，编译使用ant，格式转换使用Saxon，Java的东东我不太熟悉，也无意往下看了，不过它不用.fo格式，而是直接通过html生成pdf，转换工具是html2doc，无比遗憾的是，html2doc也不支持中文（中文真是永远的痛啊），也许将html转换为pdf不是很困难，但要比较完美的转换则不太容易（保持目录，链接等信息），再加上中文，那是相当的不简单啊。

看起来还是有些复杂，不过这些东东都只用写一次的，倒是蛮符合Docbook的精髓： Write Once, Read Anywhere!

Python代码-查询Baidu词典

Baidu词典（http://dict.baidu.com/）是我比较喜欢的一个网络词典，但不喜欢每次都用Web去查，写了下面一段代码可以实现Baidu词典的脚本查询：

#!/usr/bin/env python

import os,sys
import urllib2
import re

class BaiduDict:
    def __init__(self):
        pass
  
    def query(self, word):
        url = "http://www.baidu.com/baidu?ie=utf-8&ct=1048576&word= "
      
        try:
            data = urllib2.urlopen(url+urllib2.quote(word)).read()
        except:
            print "ERROR: can not connect to http://www.baidu.com/ "
            return None
      
        p = re.compile("<ol>.+$", re.M)
        data = data.decode('gb2312').encode('UTF-8')
        match = p.search(data)
        if match:
                result = data[match.start():match.end()]
                result = re.sub("</div>","\n",result)
                result = re.sub("<[^>]+>", " ",result)
        else:
                result = ""
              
        return result

if __name__ == '__main__':
    if len(sys.argv) > 1 :
        qword = sys.argv[1]
        print "================BaiduDict========================"
        baidu=BaiduDict()
        print baidu.query(qword)

如果要查多于一个单词的短语的话，需要在短语外加引号就可以了。

第三方代码管理

代码库里面如果有第三方的代码，可不是太好管理， 这里有一个比较不错的方法，但稍嫌复杂：
 
* 第三方代码单独分支存放，象一般代码一样进化版本，但过去的每个版本都打标签，这样就不用保存多个版本的拷贝了。
* 在其它分支上，不断修改第三方代码的bug，当第三方代码升级后，从其所在的特定分支，merge过来。

这里第一步的进化版本有点困难（相当于重建版本历史），可能需要一些非常规的手段，比如脚本等，当然也可以手工做，但比较复杂且容易出错。

还有其它简单有效的方法吗？ 如果有的话，给我留言，先谢过了。

Docbook

Docbook是做什么的？ Docbook是SGML的一种应用，用于科技书籍的撰写，现在已经得到广泛的应用了，比如Linux Document Project，以及ORilley出版的书很多都使用了Docbook格式。

Docbook的好处是纯文本格式以及内容与表示的分离，所以用Docbook写成的书，需要"编译"才能得到我们常见的格式，比如HTML，PDF，DOC等，这同时也是双刃剑，很多人难以理解Docbook的这种写作方式，我就花了一番google才弄明白Docbook的"编译"过程，我感觉Docbook也非常适合于软件开发项目中的文档写作。

Docbook是有一个规范的，版本一直在升级，现在已经基本转到XML了（XML是SGML的简化），主要就是定义了DTD（定义Docbook格式）和XSL（定义Docbook表示），还有一些Docbook的变种，比如Docbook lite，显然是Docbook的简化。

在网上可以注意到一些书是用Docbook编写的，并可以下载源文件和"编译"工具，我知道的有两个：
http://diveintopython.org/ 和 svnbook

关于Docbook的细节，可以参考一本ORilley的书：
http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html

Python dictionary实现

一直对这个蛮有兴趣的，其实只要去看一下源码就可以了，而实际上不用看源码，源码中的注释就已经解释了核心的实现细节：

* 这个hash表的hash算法是看不到的（起码在上面链接的这个文件中看不到），这涉及Python对象的hash处理，但对于int和string，Python居然使用了最最简单的hash算法，这确实让我跌碎眼睛啊。
* 发生冲突时的解决方法很有意思，冲突时不是使用链表，而是使用Open Address方法，即按照一个给定的计算方法计算下一个存储位置，这样的好处应该是可以省去链表带来的内存申请和释放。而这个计算方法也很奇怪，不是+1（这个最简单啊），而是
j = (5*j) + 1 + perturb;
perturb >>= PERTURB_SHIFT;
这个看起来确实是有些复杂，Python的注释解释了， 5*j+1是保证了2**N元素表中可以遍历所有元素（这个怎么证明？），但如果只有5*j+1则生成的遍历顺序总是相同的，意味着冲突可能会累积，所以加上perturb来达到一定的随机效果，当然每次perturb要右移以保证一定次数后，perturb会成为0，这样才能保证遍历性，而perturb的初值就是hashcode。

这叫一个绕啊，今天算是发现我数据结构与算法的知识已经基本上还给亲爱的大学老师了，怎么这些东西好像从未学过的样子啊。。。

《Pragmatic Version Control》

最近是被SCM缠上了，又看了两本书 《Pragmatic Version Control》和《Subversion Version Control》，巧的是，都是讲Subversion的，看来Subversion确实很红啊。

不要仅仅通过目录来判断一本书，从目录上看《Subversion Version Control》要比《Pragmatic Version Control》丰富很多，内容也确实要多一些（360页vs240页），但看下来，我更喜欢后者，它给我的感觉象是一个经验丰富的Subversion用户在将自己使用SVN的经验娓娓道来，而前者更像是一本面面俱到的参考手册，可惜暂时我缺的不是参考手册，那是给老手们准备的。

Windows 下的 StatusIcon

在Windows下测了一下gtk.StatusIcon，如我担心的一样有点小问题:
- 在我用PNG做图标时，我的彩色的PNG到了Windows的Tray上变成了灰度图，为啥子哦？
- 在图标上右键出来的菜单似乎因为超出了屏幕的边框，而被变成了压扁的上下导航箭头，就不知道自动挪一下位置嘛？
除此之外的功能还都正常，也能算是跨平台了吧，虽然跨到Windows下没跨好，跨出了点bug。。。

http://bugzilla.gnome.org/show_bug.cgi?id=493042

Trac初探

Trac是软件开发项目管理工具，实际上它是Wiki/Issue/Subversion的综合体，也就是提供了小型项目需要的最重要的几个项目管理工具，虽然这几个东西的思想都不是Trac原创，但Trac创造性的将它们很好的实现并综合了起来（Subverion需要外部安装），并提供Web使用界面，用起来非常方便。很多著名的开源项目都在使用Trac，比如ruby，cakephp，wordpress。

在Trac里面Wiki无处不在，你可以在Subversion的comments里面输入wiki格式，也可以在Issue（bug或requirement）的说明里面使用wiki，而wiki本身又可以简单的引用svn文件和issue，所以在Trac里，Wiki/Issue/Svn是高度关联的，而不是独立的（如果是独立的，Trac也就没有存在的必要了）。

虽然可以在很多平台下运行Trac（Trac使用Python），但在Ubuntu下可是相当的方便：
* 先安装 sudo apt-get install trac
* 创建一个Trac project，使用trac-admin /path/to/project initenv. 这一步要输入一些project的基本信息，不过除project name外的信息都可以回车带过。
* 运行 tracd --port 8000 /path/to/project，这是运行一个独立的Trac服务（含Web服务），Trac也可以和Apache配合，但方法稍有不同。
* 现在就可以在浏览器里面打开 127.0.0.1:8000 来访问Trac了。
我测试了一下，非常容易上手，对中文的支持也非常好，从Wiki到搜索都支持中文。

trac-admin还提供了一组管理命令可以在命令行下面对Trac project进行一些配置，总之对Trac的印象相当的好！