GHawk

2006年1月10日 #

建议方正要是胜诉的话,为开源事业做点贡献

中国人民可以说是被盗版和Windows惯坏了。在Linux默认环境下的中文显示至今惨不忍睹。
看看现在一些主要的发行版本,默认设置下的日语的显示已经相当不错了。
作为汉字发祥地且拥有众多人口的中国,实在是有些悲哀。
文泉驿计划正在为实现这个目标努力。作为一个非盈利性组织,他们的贡献的确值得赞赏。
最近方正正在为字体的事情打官司,并提出了高额赔偿的要求。建议方正要是能够胜诉的话,贡献一些字体给开源组织,为弘扬汉语言文化多做点贡献。

posted @ 2007-08-23 15:01 GHawk 阅读(616) | 评论 (1)编辑 收藏

Maven2 用于度量和品质保证的插件


以上是一些常用的用于品质管理的插件。默认情况下都不用配置,相当方便。如果需要手动配置的话,根据网上的文档也相当容易配置。
apache的maven plugin页面: http://maven.apache.org/plugins/
codehaus mojo 页面: http://mojo.codehaus.org

posted @ 2007-05-28 14:32 GHawk 阅读(1520) | 评论 (1)编辑 收藏

Scripting in Mustang 的一点启发

2006 Sun Techdays Shanghai 的第2天下午有一个名为《Java Scripting: One VM, Many Languages》的Session。

Rags为大家展示了Mustang的一个新特性,Scripting in Java——脚本语言支持。

通过加入脚本引擎的支持,就能够在Java中解释Javascript,python,ruby等诸多脚本语言。

对于这个特性,想到的一个可能的应用就是在annotation中写脚本语言,然后在代码中用相应的脚本语言引擎解释执行。
保留到运行时的annotation可以用实现aop的功能,使用非inline的脚本就可以更灵活地控制aspect的行为。

比如:
//inline scripting
@ScriptBefore(script
="",language="javascript" )
public void foo() {
   
}

//non-inline scripting
@ScriptBefore(file
="scripts/logging.js",language="javascript")
public void bar() {

}

posted @ 2006-09-26 10:04 GHawk 阅读(1309) | 评论 (3)编辑 收藏

一个XPer提供的一些经验

前些天,和一位XPer进行了一次愉快的谈话。他向我讲述了一些感觉很有效的实践。

关于过程和迭代
他曾经参与过的项目的迭代是以月为迭代单位的,但事实上每周都会重复一个简单的过程。
在迭代过程中,他非常推崇Burn-Down Charts。这是一个Scrum的工具。通过Burn-Down Charts,能够把过程中间的变化记录下来,使过程高度可视化。等到一次迭代完成,回顾一下所有的Burn-Down Charts就能作为改进的判断依据。
KPT Meeting。所谓KPT Meeting就是 Keep-Prevent-Try metting。小组定期举行KPT会议(基本上是每周一次)。在KTP会议上,通过头脑风暴的方式每个人(不是某几个人)把各自认为前一阶段里做得好的方面写在Keep一栏里;做得不好的方面写在Prevent一栏里;希望尝试的写在Try一栏里。然后大家对这些项目进行评估和筛选。下一阶段中,Keep的项目继续保持,Prevent的项目应该杜绝,Try的项目进行尝试。

工具
在开展这些实践的时候,交流比较频繁。首推的工具是Mini white boardDC
选择Mini white board的原因并不是因为带有"mini"听上去会像 Mini Cooper 或者 iPod mini 那么cool。因为一块A3左右大小的白板非常适合个人或者结对使用,而且环保(省去了草稿纸)。虽然整个团队也有用于大规模交流的更大的白板,但那属于“竞争资源”,各自使用自己的白板更为方便。
交流结果产生后,为了不花不必要的时间去做精美的文档,一台轻便的DC往往是最合适的选择。当然,如果足够,手机上的照相功能也可以完成同样的任务。相比偷拍街上的MM,这些电子产品能够实现更大的价值。

关于结对
每天进行6小时的结对编程,分3次,每次2小时。每次和不同的成员组队。在结队的时候充分利用了上面提到的工具进行交流。如果出现两个人不能解决的问题的时候,会立即向整个团队提出,这样可能导致一次stand-up meeting。即使问题不能马上解决,至少也能确保每个人都知道这个问题。

posted @ 2006-08-24 15:45 GHawk 阅读(1423) | 评论 (0)编辑 收藏

关于locale的设定 (转)

 
locale是国际化与本土化过程中的一个非常重要的概念,个人认为,对于中文用户来说,通常会涉及到的国际化或者本土化,大致包含三个方面:看中文,写中文,与window中文系统的兼容和通信。从实际经验上看来,locale的设定与看中文关系不大,但是与写中文,及window分区的挂载方式有很密切的关系。本人认为就像一个纯英文的Windows能够浏览中文,日文或者意大利文网页一样,你不需要设定locale就可以看中文。那么,为什么要设定locale呢?什么时候会用到locale呢?

一、为什么要设定locale
正如前面我所讲的,设定locale与你能否浏览中文的网页没有直接的关系,即便你把locale设置成en_US.ISO-8859-1这样一个标准的英文locale你照样可以浏览中文的网页,只要你的系统里面有相应的字符集(这个都不一定需要)和合适的字体(如simsun),浏览器就可以把网页翻译成中文给你看。具体的过程是网络把网页传送到你的机器上之后,浏览器会判断相应的编码的字符集,根据网页采用的字符集,去字体库里面找合适的字体,然后由文字渲染工具把相应的文字在屏幕上显示出来。

 
在下文本人会偶尔把字符集比喻成密码本,个人觉得对于一些东西比较容易理解,假如你不习惯的话,把全文copy到任何文本编辑器,用字符集替换密码本即可。
 
那有时候网页显示乱码或者都是方框是怎么回事呢?个人认为,显示乱码是因为设定的字符集不对(或者没有相应的字符集),例如网页是用UTF-8编码的,你非要用GB2312去看,而系统根据GB2312去找字体,然后在屏幕上显示,当然是一堆的乱码,也就是说你用一个错误的密码本去翻译发给你的电报,当然内容那叫一个乱;至于有些时候浏览的网页能显示一部分汉字,但有很多的地方是方框,能够显示汉字说明浏览器已经正确的判断出了网页的编码,并在字体库里面找到了相应的文字,但是并不是每个字体库都包含某个字符集全部的字体的缘故,有些时候会显示不完全,找一个比较全的支持较多字符集的字体就可以了。
 

既然我能够浏览中文网页,那为什么我还要设定locale呢?
 
其实你有没有想过这么一个问题,为什么gentoo官方论坛上中文论坛的网页是用UTF-8编码的(虽然大家一直强烈建议用GB2312编码),但是新浪网就是用GB2312编码的呢?而Xorg的官方网页竟然是ISO-8859-15编码的,我没有设定这个locale怎么一样的能浏览呢?这个问题就像是你有所有的密码本,不论某个网站是用什么字符集编码的,你都可以用你手里的密码本把他们翻译过来,但问题是虽然你能浏览中文网页,但是在整个操作系统里面流动的还是英文字符。所以,就像你能听懂英语,也能听懂中文。
最根本的问题是:你不可以写中文。
 
当你决定要写什么东西的时候,首先要决定的一件事情是用那种语言,对于计算机来说就是你要是用哪一种字符集,你就必须告诉你的linux系统,你想用那一本密码本去写你想要写的东西。知道为什么需要用GB2312字符集去浏览新浪了吧,因为新浪的网页是用GB2312写的。
 
为了让你的Linux能够输入中文,就需要把系统的locale设定成中文的(严格说来是locale中的语言类别LC_CTYPE ),例如zh_CN.GB2312、zh_CN.GB18030或者zh_CN.UTF-8。很多人都不明白这些古里古怪的表达方式。这个外星表达式规定了什么东西呢?这个问题稍后详述,现在只需要知道,这是locale的表达方式就可以了。
 
二、到底什么是locale?
locale这个单词中文翻译成地区或者地域,其实这个单词包含的意义要宽泛很多。Locale是根据计算机用户所使用的语言,所在国家或者地区,以及当地的文化传统所定义的一个软件运行时的语言环境。
 
这个用户环境可以按照所涉及到的文化传统的各个方面分成几个大类,通常包括用户所使用的语言符号及其分类(LC_CTYPE),数字(LC_NUMERIC),比较和排序习惯(LC_COLLATE),时间显示格式(LC_TIME),货币单位(LC_MONETARY),信息主要是提示信息,错误信息, 状态信息, 标题, 标签, 按钮和菜单等(LC_MESSAGES),姓名书写方式(LC_NAME),地址书写方式(LC_ADDRESS),电话号码书写方式(LC_TELEPHONE),度量衡表达方式(LC_MEASUREMENT),默认纸张尺寸大小(LC_PAPER)和locale对自身包含信息的概述(LC_IDENTIFICATION)。
 
所以说,locale就是某一个地域内的人们的语言习惯和文化传统和生活习惯。一个地区的locale就是根据这几大类的习惯定义的,这些locale定义文件放在/usr/share/i18n/locales目录下面,例如en_US, zh_CN and de_DE@euro都是locale的定义文件,这些文件都是用文本格式书写的,你可以用写字板打开,看看里边的内容,当然出了有限的注释以外,大部分东西可能你都看不懂,因为是用的Unicode的字符索引方式。
 
对于de_DE@euro的一点说明,@后边是修正项,也就是说你可以看到两个德国的locale:
/usr/share/i18n/locales/de_DE@euro
/usr/share/i18n/locales/de_DE
打开这两个locale定义,你就会知道它们的差别在于de_DE@euro使用的是欧洲的排序、比较和缩进习惯,而de_DE用的是德国的标准习惯。
 
上面我们说到了zh_CN.GB18030的前半部分,后半部分是什么呢?大部分Linux用户都知道是系统采用的字符集。
 
三、什么是字符集?
字符集就是字符,尤其是非英语字符在系统内的编码方式,也就是通常所说的内码,所有的字符集都放在/usr/share/i18n/charmaps,所有的字符集也都是用Unicode编号索引的。Unicode用统一的编号来索引目前已知的全部的符号。而字符集则是这些符号的编码方式,或者说是在网络传输,计算机内部通信的时候,对于不同字符的表达方式,Unicode是一个静态的概念,字符集是一个动态的概念,是每一个字符传递或传输的具体形式。就像Unicode编号U59D0是代表姐姐的“姐”字,但是具体的这个字是用两个字节表示,三个字节,还是四个字节表示,是字符集的问题。例如:UTF-8字符集就是目前流行的对字符的编码方式,UTF-8用一个字节表示常用的拉丁字母,用两个字节表示常用的符号,包括常用的中文字符,用三个表示不常用的字符,用四个字节表示其他的古灵精怪的字符。而GB2312字符集就是用两个字节表示所有的字符。需要提到一点的是Unicode除了用编号索引全部字符以外,本身是用四个字节存储全部字符,这一点在谈到挂载windows分区的时候是非常重要的一个概念。所以说你也可以把Unicode看作是一种字符集(我不知道它和UTF-32的关系,反正UTF-32就是用四个字节表示所有的字符的),但是这样表述符号是非常浪费资源的,因为在计算机世界绝大部分时候用到的是一个字节就可以搞定的26个字母而已。所以才会有UTF-8,UTF-16等等,要不然大同世界多好,省了这许多麻烦。
 

四、zh_CN.GB2312到底是在说什么?
Locale 是软件在运行时的语言环境, 它包括语言(Language), 地域 (Territory) 和字符集(Codeset)。一个locale的书写格式为: 语言[_地域[.字符集]]. 所以说呢,locale总是和一定的字符集相联系的。下面举几个例子:
 
1、我说中文,身处中华人民共和国,使用国标2312字符集来表达字符。
zh_CN.GB2312=中文_中华人民共和国+国标2312字符集。
 
2、我说中文,身处中华人民共和国,使用国标18030字符集来表达字符。
zh_CN.GB18030=中文_中华人民共和国+国标18030字符集。
 
3、我说中文,身处中华人民共和国台湾省,使用国标Big5字符集来表达字符。
zh_TW.BIG5=中文_台湾.大五码字符集
 
4、我说英文,身处大不列颠,使用ISO-8859-1字符集来表达字符。
en_GB.ISO-8859-1=英文_大不列颠.ISO-8859-1字符集
 
5、我说德语,身处德国,使用UTF-8字符集,习惯了欧洲风格。
de_DE.UTF-8@euro=德语_德国.UTF-8字符集@按照欧洲习惯加以修正
 
注意不是de_DE@euro.UTF-8,所以完全的locale表达方式是
[语言[_地域][.字符集] [@修正值]
 
生成的locale放在/usr/lib/locale/目录中,并且每个locale都对应一个文件夹,也就是说创建了de_DE@euro.UTF-8 locale之后,就生成/usr/lib/locale/de_DE@euro.UTF-8/目录,里面是具体的每个locale的内容。
 
五、怎样去自定义locale
在gentoo生成locale还是很容易的,首先要在USE里面加入userlocales支持,然后编辑locales.build文件,这个文件用来指示glibc生成locale文件。
很多人不明白每一个条目是什么意思。 其实根据上面的说明现在应该很明确了。
 
File: /etc/locales.build
en_US/ISO-8859-1
en_US.UTF-8/UTF-8
 
zh_CN/GB18030
zh_CN.GBK/GBK
zh_CN.GB2312/GB2312
zh_CN.UTF-8/UTF-8
 
上面是我的locales.build文件,依次的说明是这样的:
 
en_US/ISO-8859-1:生成名为en_US的locale,采用ISO-8859-1字符集,并且把这个locale作为英文_美国locale类的默认值,其实它和en_US.ISO-8859-1/ISO-8859-1没有任何区别。
 
en_US.UTF-8/UTF-8:生成名为en_US.UTF-8的locale,采用UTF-8字符集。
 
zh_CN/GB18030:生成名为zh_CN的locale,采用GB18030字符集,并且把这个locale作为中文_中国locale类的默认值,其实它和zh_CN.GB18030/GB18030没有任何区别。
 
zh_CN.GBK/GBK:生成名为zh_CN.GBK的locale,采用GBK字符集。
zh_CN.GB2312/GB2312:生成名为zh_CN.GB2312的locale,采用GB2312字符集。
zh_CN.UTF-8/UTF-8:生成名为zh_CN.UTF-8的locale,采用UTF-8字符集。
 
关于默认locale,默认locale可以简写成en_US或者zh_CN的形式,只是为了表达简单而已没有特别的意义。
 
Gentoo在locale定义的时候掩盖了一些东西,也就是locale的生成工具:localedef。
在编译完glibc之后你可以用这个localedef 再补充一些locale,就会更加理解locale了。具体的可以看 localedef 的manpage。
 
$localedef -f 字符集 -i locale定义文件 生成的locale的名称
例如
$localedef -f UTF-8 -i zh_CN zh_CN.UTF-8
 
上面的定义方法和在locales.build中设定zh_CN.UTF-8/UTF-8的结果是一样一样的。
 

六、locale的五脏六腑
 
刚刚生成了几个locale,但是为了让它们生效,必须告诉Linux系统使用那(几)个locale。这就需要对locale的内部机制有一点点的了解。在前面我已经提到过,locale把按照所涉及到的文化传统的各个方面分成12个大类,这12个大类分别是:
1、语言符号及其分类(LC_CTYPE)
2、数字(LC_NUMERIC)
3、比较和排序习惯(LC_COLLATE)
4、时间显示格式(LC_TIME)
5、货币单位(LC_MONETARY)
6、信息主要是提示信息,错误信息, 状态信息, 标题, 标签, 按钮和菜单等(LC_MESSAGES)
7、姓名书写方式(LC_NAME)
8、地址书写方式(LC_ADDRESS)
9、电话号码书写方式(LC_TELEPHONE)
10、度量衡表达方式(LC_MEASUREMENT)
11、默认纸张尺寸大小(LC_PAPER)
12、对locale自身包含信息的概述(LC_IDENTIFICATION)。
 
其中,与中文输入关系最密切的就是 LC_CTYPE, LC_CTYPE 规定了系统内有效的字符以及这些字符的分类,诸如什么是大写字母,小写字母,大小写转换,标点符号、可打印字符和其他的字符属性等方面。而locale定义zh_CN中最最重要的一项就是定义了汉字(Class “hanzi”)这一个大类,当然也是用Unicode描述的,这就让中文字符在Linux系统中成为合法的有效字符,而且不论它们是用什么字符集编码的。
 
LC_CTYPE
% This is a copy of the "i18n" LC_CTYPE with the following modifications: - Additional classes: hanzi
 
copy "i18n"
 
class "hanzi"; /
% <U3400>..<U4DBF>;/
<U4E00>..<U9FA5>;/
<UF92C>;<UF979>;<UF995>;<UF9E7>;<UF9F1>;<UFA0C>;<UFA0D>;<UFA0E>;/
<UFA0F>;<UFA11>;<UFA13>;<UFA14>;<UFA18>;<UFA1F>;<UFA20>;<UFA21>;/
<UFA23>;<UFA24>;<UFA27>;<UFA28>;<UFA29>
END LC_CTYPE
 
在en_US的locale定义中,并没有定义汉字,所以汉字不是有效字符。所以如果要输入中文必须使用支持中文的locale,也就是zh_XX,如zh_CN,zh_TW,zh_HK等等。
 
另外非常重要的一点就是这些分类是彼此独立的,也就是说LC_CTYPE,LC_COLLATE和 LC_MESSAGES等等分类彼此之间是独立的,可以根据用户的需要设定成不同的值。这一点对很多用户是有利的,甚至是必须的。例如,我就需要一个能够输入中文的英文环境,所以我可以把LC_CTYPE设定成zh_CN.GB18030,而其他所有的项都是en_US.UTF-8。
 

七、怎样设定locale呢?
 
设定locale就是设定12大类的locale分类属性,即 12个LC_*。除了这12个变量可以设定以外,为了简便起见,还有两个变量:LC_ALL和LANG。它们之间有一个优先级的关系:
LC_ALL>LC_*>LANG
可以这么说,LC_ALL是最上级设定或者强制设定,而LANG是默认设定值。
1、如果你设定了LC_ALL=zh_CN.UTF-8,那么不管LC_*和LANG设定成什么值,它们都会被强制服从LC_ALL的设定,成为 zh_CN.UTF-8。
2、假如你设定了LANG=zh_CN.UTF-8,而其他的LC_*=en_US.UTF-8,并且没有设定LC_ALL的话,那么系统的locale设定以LC_*=en_US.UTF-8。
3、假如你设定了LANG=zh_CN.UTF-8,而其他的LC_*,和LC_ALL均未设定的话,系统会将LC_*设定成默认值,也就是LANG的值 zh_CN.UTF-8 。
4、假如你设定了LANG=zh_CN.UTF-8,而其他的LC_CTYPE=en_US.UTF-8,其他的LC_*,和LC_ALL均未设定的话,那么系统的locale设定将是:LC_CTYPE=en_US.UTF-8,其余的 LC_COLLATE,LC_MESSAGES等等均会采用默认值,也就是LANG的值,也就是LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=zh_CN.UTF-8。
 
所以,locale是这样设定的:
1、如果你需要一个纯中文的系统的话,设定LC_ALL= zh_CN.XXXX,或者LANG= zh_CN.XXXX都可以,当然你可以两个都设定,但正如上面所讲,LC_ALL的值将覆盖所有其他的locale设定,不要作无用功。
2、如果你只想要一个可以输入中文的环境,而保持菜单、标题,系统信息等等为英文界面,那么只需要设定LC_CTYPE=zh_CN.XXXX,LANG=en_US.XXXX就可以了。这样LC_CTYPE=zh_CN.XXXX,而LC_COLLATE=LC_MESSAGES=……= LC_PAPER=LANG=en_US.XXXX。
3、假如你高兴的话,可以把12个LC_*一一设定成你需要的值,打造一个古灵精怪的系统:
LC_CTYPE=zh_CN.GBK/GBK(使用中文编码内码GBK字符集);
LC_NUMERIC=en_GB.ISO-8859-1(使用大不列颠的数字系统)
LC_MEASUREMEN=de_DE@euro.ISO-8859-15(德国的度量衡使用ISO-8859-15字符集)
罗马的地址书写方式,美国的纸张设定……。估计没人这么干吧。
4、假如你什么也不做的话,也就是LC_ALL,LANG和LC_*均不指定特定值的话,系统将采用POSIX作为lcoale,也就是C locale。

posted @ 2006-08-16 10:45 GHawk 阅读(738) | 评论 (0)编辑 收藏

PostgreSQL的主机认证配置

转自 http://www.linuxsir.org/bbs/showthread.php?t=32116

pg_hba.conf 文件
客户端认证是由 $PGDATA 目录里的文件pg_hba.conf 控制的,也就是说, /usr/local/pgsql/data/pg_hba.conf. (HBA 的意思是 host-based authentication:基于主机的认证.) 在initdb初始化数据区的时候,它会 安装一个缺省的文件.

文件 pg_hba.conf 的常用格式是一套记录, 每行一条。空白行或者井号(“#”)开头的行被忽略。一条记录 是由若干用空格和/或 tab 分隔的字段组成。

每条记录可以下面三种格式之一

local database authentication-method [ authentication-option ]
host database IP-address IP-mask authentication-method [ authentication-option ]
hostssl database IP-address IP-mask authentication-method [ authentication-option ]

各个字段的含义如下:

local
这条记录适用于通过 Unix 域套接字的联接.

host
这条记录适用于通过 TCP/IP 网络的联接.请注意,除非服务器是 带着 -i 选项或者等效的配置参数集启动的,否则 TCP/IP 联接将完全被禁止掉.

hostssl
这条记录适用于试图建立在 TCP/IP 上的 SSL 之上的联接. 要使用这个选项,服务器必须带着 SSL 支持编译.而且在服务器启动的时候, 必须用 -l 选项 或等效的配置设置打开 SSL.

database
声明记录所适用的数据库。值 all 表明该记录应用于所有数据库, 值 sameuser 表示于正在联接的用户同名的数据库。 否则它就是某个具体的 Postgres 数据库名字.

IP address, IP mask
这两个字段以各主机的 IP 地址为基础, 控制一条 host 记录应用于哪个主机. (当然,IP 地址可能会被欺骗(spoofed),但是这个考虑 超过了 Postgres 的考虑范围.) 准确的逻辑是,对于匹配的记录

(actual-IP-address xor IP-address-field) and IP-mask-field
必需为零.

authentication method(认证方法)
声明一个用户在与该数据库联接的时候必须使用的认证方法. 可能的选择如下,详细情况在 Section 4.2.


trust
无条件地允许联接.这个方法允许任何有登录客户机权限的用户以任意 Postgres 数据库用户身份进行联接.

reject
联接无条件拒绝.常用于从组中“过滤”某些主机.

password
要求客户端在尝试联接的时候提供一个口令, 这个口令与为该用户设置的口令必须匹配.

在 password 关键字后面可以声明一个可选的文件名. 这个文件包含一个用户列表,列表记录的是那些适用口令认证记录的用户, 以及可选的候选口令.

口令是以明文的方式在线路上传输的.如果要更好的保护,请使用 crypt 方法.

crypt
类似 password 方法,但是口令是用一种简单的 口令对应协议加密后在线路上传送的.这么做在密码学理论上是不安全的, 但可以防止偶然的线路侦听.在 crypt 关键字后面 可以有一个文件,文件里包含适用口令认证记录的用户列表.

krb4
用 Kerberos V4 认证用户.只有在进行 TCP/IP 联接的时候才能用. (译注:Kerberos,"克尔波洛斯",故希腊神话冥王哈得斯的多头看门狗. Kerberos 是 MIT 开发出来的基与对称加密算法的认证协议和/或密钥 交换方法.其特点是需要两个不同用途的服务器,一个用于认证身份, 一个用于通道两端用户的密钥交换.同时 Kerberos 对网络时间同步 要求比较高,以防止回放攻击,因此通常伴随 NTP 服务.)

krb5
用 Kerberos V5 认证用户.只有在进行 TCP/IP 联接的时候才能用. (译注:Kerberos V5 是上面 V4 的改良,主要是不再依赖 DES 算法, 同时增加了一些新特性.)

ident
服务器将询问客户机上的 ident 服务器以核实正在联接的用户身份. 然后 Postgres 核实该操作系统用户是否被允许以其请求的数据库用户身份与数据库联接. 只有在使用 TCP/IP 联接的时候才能用这个选项. 跟在 ident 关键字后面的 authentication option 声明一个 ident map(身份映射), 该文件声明那些操作系统用户等效于数据库用户.见下文获取详细信息.


authentication option(认证选项)
这个字段根据不同的认证方法(authentication method)有不同的 解释.

认证时使用与联接请求的客户端 IP 地址和所要求的 数据库名字匹配的第一条记录. 请注意这里没有 “fall-through(越过)” 或者 “backup(备份)”:如果选定了一条记录但认证失败, 那么将不会继续考虑下面的记录.如果没有匹配的记录,则拒绝访问.

在每次联接的请求时,文件 pg_hba.conf 都会被重新读取.因此很容易就能在服务器运行的时候修改访问权限.

在 Example 4-1 里是 pg_hba.conf 的一个例子. 阅读下文理解不同认证方法的细节.

Example 4-1. 一个 pg_hba.conf 文件的例子

# TYPE DATABASE IP_ADDRESS MASK AUTHTYPE MAP

# 允许在本机上的任何用户以任何身份联接任何数据库
# 但必须是通过 IP 进行联接

host all 127.0.0.1 255.255.255.255 trust

# 同样,但用的是 Unix-套接字联接

local all trust

# 允许 IP 地址为 192.168.93.x 的任何主机与数据库
# "template1" 相连,用与他们在自己的主机上相同 ident 的用户名标识他自己
# (通常是他的 Unix 用户名)

host template1 192.168.93.0 255.255.255.0 ident sameuser

# 允许来自主机 192.168.12.10 的用户与 "template1" 数据库联接,
# 只要该用户提供了在 pg_shadow 里正确的口令.

host template1 192.168.12.10 255.255.255.255 crypt

# 如果前面没有其它 "host" 行,那么下面两行将拒绝所有来自
# 192.168.54.1 的联接请求 (因为前面的记录先匹配
# 但是允许来自互联网上其它任何地方有效的 Kerberos V5 认证的联接
# 零掩码表示不考虑主机 IP 的任何位.因此它匹配任何主机:

host all 192.168.54.1 255.255.255.255 reject
host all 0.0.0.0 0.0.0.0 krb5

# 允许来自 192.168.x.x 的任何用户与任意数据库联接,只要他们通过 ident 检查
# 但如果 ident 说该用户是 "bryanh" 而他要求以 PostgreSQL 用户 "guest1" 联接,
# 那么只有在 `pg_ident.conf' 里有 "omicron" 的映射,说 "bryanh" 允许以
# "guest1" 进行联接时才真正可以进行联接.

host all 192.168.0.0 255.255.0.0 ident omicron

posted @ 2006-06-07 10:42 GHawk 阅读(1181) | 评论 (0)编辑 收藏

UP & XP之争,意义何在?(续)

虽然我没能去参加BEA的活动,但是相关的资料已经下载并且浏览过了,确实收获不少。所以,对于庄兄的这些想法我很理解。

相信不只你我,大部分的人都比较认同敏捷化的过程,希望使过程变得敏捷。的确,这是个好东西,之前我也说过“敏捷过程是三赢的”这样的话。

我所关心的问题是“如何能够用好XP?”。

庄兄认为“汤的味道,不需要什么过程控制”,我也会认同。为什么?因为你我都是中国人。大部分中国人不会认为汤的味道需要什么过程控制。但是想想看,如果你在不同地方买到的肯德基炸鸡味道各异;同一批次生产的同型号的汽车形状各异;银行里取出来的一叠百元大钞大小不一,你不会觉得奇怪么或是有那么一点点愤怒么?

西方人(甚至学习西方的日本人)对品质的重视程度却完全不同。他们不允许肯德基炸鸡的味道有很大偏差(即便你觉得无所谓);“2毫米工程”不允许整车的总装长度发生2毫米以上的偏差(即便你觉得无所谓);百元大钞……(我想谁都不会无所谓)。

所以,一切质量都有标准,一切标准都应该被度量!这就是工程学的目标之一,为了实现更严格的质量标准,就需要过程控制和度量。

庄兄所说,用测试用例保证代码的质量其实还是采用了“测试用例”作为度量的标准。唯一的问题是:“如何确保测试用例的质量”。显然,我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢?“结对编程”么?嗯,这是一个不错的方式,那么最终该信赖谁呢?是Pair中的A还是B呢?或者,是Leader么?那么又是谁提出的要求呢?是老板么?还是客户?政府?法规?市场?……问题没有终结了。

不要学习哲学家的方法,提出一层又一层无法解决的问题。我们是工程师,应该试图解决问题才对!解决问题的关键在于,XP同样需要标准!为了制定标准,必要的文档是不可以少的。而且,标准本身的质量是严苛的。因为,作为标准,他不可以含糊其辞、模棱两可。在标准的基础之上,我们才可以谈什么TDD、Pair Programming之类的实践。

回到争论的开端。我引用了林先生的话“UP是正楷;XP是草书。要先学好UP才能学好XP,先学XP会乱套。”我对这句话的理解如下:这句话并没有批判UP或是XP,只是指出了一个学习的顺序。我认为这句话是有实践依据的,因为UP强调的是一种经典的工程方法。软件工程本来就源于其他行业的工程实践经验。UP利用大量的文档对开发活动进行约束和记录。正是这种重量级的过程规范了规范了从PM到Coder的所有活动,有问题可以参照文档,看看自己应该怎么做。文档也可以作为日后评估这个过程的依据。随着整个团队和每个个人的经验不断积累,开发活动中的日常行为渐渐形成了一种职业习惯。然后可以通过对UP的配置,逐渐减少文档的使用量,一些没有必要的文档就可以省去,更具团队的实际能力调整过程。UP是可配置的,不必要的文档没有存在的理由,这一点UP和XP没有什么两样。当然,随着大家的职业习惯越来越好,经验越来越丰富,个人和团队就可以采用更敏捷更轻便的过程,逐渐过渡到XP上去。

反过来,如果一开始就没有详尽的文档,很多活动(比如设计、版本控制)往往会脱离控制,进入一种无序的、混乱的状态。没有文档可参考,就意味着很多问题只能问人,而不同人的回答可能各异,同一个人对同一个问题的两次回答也可能不同!当然,如果整个团队的工程素养和个体的职业习惯都比较好的情况下可能不会发生类似的情况。但是这种工程素养和职业习惯从哪里来,可能单靠的XP是不足以培养出来的。

“UP是正楷;XP是草书。要先学好UP才能学好XP,先学XP会乱套。”这句话表明了UP和XP在一定程度上是存在冲突的,并且提出了一条路线去降低和避免这个冲突。

再次需要强调的是庄兄所提到的“XP是一种思想”,这点我认同。但是我认为这个除了思想之外,还是一种“文化”。这种思想和文化也是出于软件工程多年来的实践,其中也不免有UP等其他过程。不能简单地认为“我们只要吸取历史的教训,提出新的思想和文化就不会再犯同样的错误了。”很多时候历史总是一次又一次地重演着。新的思想和文化如果不能被准确地理解和运用,它所带来的可能仍然是它原本想解决的问题。只有我们具备了引入这种文化的基础,才能把它变成自己的文化,否则这仍然是挂在嘴边行于表面的一种不求精髓只求模仿的伪文化、伪思想。这一点对于UP和XP的实践者来说没有什么两样。

posted @ 2006-04-25 15:03 GHawk 阅读(2026) | 评论 (4)编辑 收藏

UP & XP之争,意义何在?

不光是做软件,凡是做产品,最后关注的总是产品的质量

举个例子,比如你做一锅汤:
今天你状态很好,做完后尝了尝,感觉很美味,你的家人尝了以后也有同感,喝完后感觉心情舒畅、意犹未尽。
隔了一个礼拜,你做同样的汤给家里人喝。做完后你尝了尝,感觉依然美味,盼望着得到家人的赏识,然而他们却说味道咸了点。你很奇怪,为什么同样自己尝过了,家里人却感觉不一样呢?是不是最近加班多了,休息不好,味觉不准了?
一个月过后,你要去国外出差,给家里请了个临时保姆。一天,他也做了这么个汤,做完后,他也尝了尝,感觉口味很不错,可是端上桌,家里人说这汤太辣了。原来这保姆才从湖南老家出来不久……

因此,只把焦点放在最后的产品上往往是不够的。需要对“做汤的过程”加以控制。所以工程界会比较关注过程的管理,在软件领域也称作“软件生命周期管理”。

再来看看UP和XP。它们都属于软件过程,只不过各有特色。

再拿刚才那个做汤的例子:
大家都听说过德国人的厨房像化学实验室,天平、计时器、量杯……装备齐全,再配上精确的菜谱,严谨的德国人能够确保不用尝那最后一口都做出口味基本一致的汤。
换了中国人,大部分人都不会模仿德国人做菜的方式。解决方案很简单,让你的太太和孩子都尝那最后一口,再根据反馈调整几次,同样能做出全家人满意的汤。

这个例子也许不太贴切,但是可以联想一下:德国人做汤倾向于UP;中国人做汤倾向于XP

UP和XP最终目的都是为了保证产品的质量,不同的是,两个过程所强调的方法不同。我想,没有人会说“UP的目的在于变态地追求文档的完美”、“UP是为了要程序员学会写各种各样文档”……之类的话。同时,也没人会说“XP就是不要文档只要代码”、“XP就是要变态地追求完美的代码”……这样的话。

这些不正确的看法,只是人们对于这两种过程的误解。或许是来自于开发人员和项目经理的那些“不堪回首的经历”。

“UP害惨了整个软件行业,让开发人员没完没了地写文档而忽略了代码,XP才是王道”这样的话,我不敢苟同,仍然有很多企业使用着UP这样的重型软件工程,就好比德国人依然喜欢把厨房弄得像个实验室。

XP固然是个好东西。但是,不知道大多数人对于XP的热衷是出于对XP文化的理解,还是国人惯有的“一窝蜂”似的行为。不晓得一个“能够熟练阅读代码的Leader”是不是能够真正运用好XP,确保他的团队能够尽可能少地出现"Over engineering"这种违背Agile精神的东西,或是能够让他的团队保证“每周只工作40小时”这样的基本实践?

对于不同的技术和过程,应该给予冷静的分析和慎重的选择。每个过程和技术都不能以“正确”或“不正确”来定性,只能以“合适”和“不合适”来定性。因为正确或不正确是要严格证明的,而合适不合适是来源于工程实践的结果。所以,COBOL依然在金融领域起着举足轻重的作用,科学家们仍不忘Fortran,汇编和C仍然健在……

另外不得不提的是文化上的差异。为什么很多时候,我们学习国外的先进技术,购买了整套生产线,引进了全套图纸,请国外专家做了详细的全程化培训,国人生产出的产品品质依然不如国外原产的?这是每个中国人都应该思考的问题……

 

posted @ 2006-04-23 18:28 GHawk 阅读(1874) | 评论 (4)编辑 收藏

对"UP是正楷,XP是草书"的反思

“UP是正楷,XP是草书。先学好了UP,才能学好XP;先学XP再学UP就会乱套。 ”

老师曾这么说。最近,对这句话有了深刻的体会。

软件过程是一个以人为中心的活动。人是项目中最难确定和控制的因素。休息的质量、情绪的起伏都会影响整个活动。为了尽可能地约束这种个体的不确定行为和减少开发过程中不必要的误会。"UP"采用了大量的文档来对整个开发过程进行控制。这些文档主要分为以下几类:

  • 计划文档——项目的开发计划、迭代计划、测试计划等。
  • 技术文档——项目的设计文档、某个操作的说明文档等。
  • 记录文档——日常的会议纪要、每日进度反馈、评估报告等。

文档成了UP活动的主要部分。在UP中,往往大量的资源用于文档的制作。这些文档的目的是为了尽可能减少不必要的沟通成本和误会,也为了在发生问题的时候能够尽快确定原因找到解决方法。

而正是因为如此繁重的资源消耗,导致真正的设计和代码只占到了总开销的很少部分。这对很多人来说不可理解,甚至觉得本末倒置。于是很多敏捷方法诞生了,最具代表性也是对UP思想最具颠覆性的就属XP了。

对外,XP以快速的反应速度来响应客户的需求;对内,XP以高质量的代码和设计来确保尽可能不产生不必要的文档和资源开销。

从表面上看,在当今,XP确实是一种非常理想的开发过程。

但是,从没有过程到XP往往会非常失败。这是为什么?问题的关键还在于人。

  • 无过程-->UP -->XP

UP利用文档来约束和规范人们的开发活动。当一个没有经验的团队经历UP后,就等于把性格各异、习惯差别不同的人统一成了“相对较一致的开发人员”。

他们有一致的编码习惯,有共同的用语,有严格的规则。随着经验的积累,这个团队间的默契越来越高。此时,如果过程由UP向XP切换,付出的代价就会相对较低。

  • 无过程-->XP-->UP

XP主张快速反应。如果一个没有经验的团队在一开始就尝试XP,那么后果可能是惨痛的。因为一个没有经验的团队其成员间的相互了解颇少,对于一件事,往往十个人有十种想法。当缺少文档约束时,在以代码和设计为中心的活动中,成员之间往往因为水平的参差不齐导致无休止的讨论甚至争论,代码被不必要地频繁改动。这是因为,在团队建设早期,成员之间往往连最基本的尊重和信任都不存在。 这种无意义的活动往往会严重影响项目的正常进行。

所以,学习和应用过程不仅仅是个体的事,而是整个团队的事。只有当团队采用严格文档化的过程并且经过磨合后,才能渐渐向轻量级的过程迁移,逐渐将不必要的文档删减掉,采用更灵活的过程。但是,此时并不是“没有文档”而是“心中有文档”。

posted @ 2006-03-01 16:25 GHawk 阅读(1636) | 评论 (4)编辑 收藏

加载Classpath中的文件(转)

   URL url = this.getClass().getResource("EJBConfig.xml");
        
try {
            File xmlFile 
= new File(URLDecoder.decode(url.getFile(),"UTF-8"));
            
if(xmlFile.exists())
                System.out.println(
"OK");
        } 
catch (UnsupportedEncodingException e) {
            e.printStackTrace();  
//To change body of catch statement use File | Settings | File Templates.
        }

posted @ 2006-01-19 22:07 GHawk 阅读(751) | 评论 (0)编辑 收藏

敏捷软件开发 读书笔记 (4)——OO五大原则(3.LSP——里氏替换原则)

OCP作为OO的高层原则,主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构,维持设计的封闭性。

“抽象”是语言提供的功能。“多态”由继承语义实现。

如此,问题产生了:“我们如何去度量继承关系的质量?”

Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说,当一个子类的实例应该能够替换任何其超类的实例时,它们之间才具有is-A关系。

该原则称为Liskov Substitution Principle——里氏替换原则。林先生在上课时风趣地称之为“老鼠的儿子会打洞”。^_^

我们来研究一下LSP的实质。学习OO的时候,我们知道,一个对象是一组状态和一系列行为的组合体。状态是对象的内在特性,行为是对象的外在特性。LSP所表述的就是在同一个继承体系中的对象应该有共同的行为特征。

这一点上,表明了OO的继承与日常生活中的继承的本质区别。举一个例子:生物学的分类体系中把企鹅归属为鸟类。我们模仿这个体系,设计出这样的类和关系。

 lsp-fig1.jpg

类“鸟”中有个方法fly,企鹅自然也继承了这个方法,可是企鹅不能飞阿,于是,我们在企鹅的类中覆盖了fly方法,告诉方法的调用者:企鹅是不会飞的。这完全符合常理。但是,这违反了LSP,企鹅是鸟的子类,可是企鹅却不能飞!需要注意的是,此处的“鸟”已经不再是生物学中的鸟了,它是软件中的一个类、一个抽象。

有人会说,企鹅不能飞很正常啊,而且这样编写代码也能正常编译,只要在使用这个类的客户代码中加一句判断就行了。但是,这就是问题所在!首先,客户代码和“企鹅”的代码很有可能不是同时设计的,在当今软件外包一层又一层的开发模式下,你甚至根本不知道两个模块的原产地是哪里,也就谈不上去修改客户代码了。客户程序很可能是遗留系统的一部分,很可能已经不再维护,如果因为设计出这么一个“企鹅”而导致必须修改客户代码,谁应该承担这部分责任呢?(大概是上帝吧,谁叫他让“企鹅”不能飞的。^_^)“修改客户代码”直接违反了OCP,这就是OCP的重要性。违反LSP将使既有的设计不能封闭!

修正后的设计如下:

 lsp-fig2.jpg

但是,这就是LSP的全部了么?书中给了一个经典的例子,这又是一个不符合常理的例子:正方形不是一个长方形。这个悖论的详细内容能在网上找到,我就不多废话了。

LSP并没有提供解决这个问题的方案,而只是提出了这么一个问题。

于是,工程师们开始关注如何确保对象的行为。1988年,B. Meyer提出了Design by Contract(契约式设计)理论。DbC从形式化方法中借鉴了一套确保对象行为和自身状态的方法,其基本概念很简单:

  1. 每个方法调用之前,该方法应该校验传入参数的正确性,只有正确才能执行该方法,否则认为调用方违反契约,不予执行。这称为前置条件(Pre-condition)。
  2. 一旦通过前置条件的校验,方法必须执行,并且必须确保执行结果符合契约,这称之为后置条件(Post-condition)。
  3. 对象本身有一套对自身状态进行校验的检查条件,以确保该对象的本质不发生改变,这称之为不变式(Invariant)。

以上是单个对象的约束条件。为了满足LSP,当存在继承关系时,子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松;而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格。

一些OO语言中的特性能够说明这一问题:

  • 继承并且覆盖超类方法的时候,子类中的方法的可见性必须等于或者大于超类中的方法的可见性,子类中的方法所抛出的受检异常只能是超类中对应方法所抛出的受检异常的子类。
    public class SuperClass{
        
    public void methodA() throws IOException{}
    }


    public class SubClassA extends SuperClass{
        
    //this overriding is illegal.
        private void methodA() throws Exception{}
    }


    public class SubClassB extends SuperClass{
        
    //this overriding is OK.
        public void methodA() throws FileNotFoundException{}
    }

  • 从Java5开始,子类中的方法的返回值也可以是对应的超类方法的返回值的子类。这叫做“协变”(Covariant)
    public class SuperClass {
        
    public Number caculate(){
            
    return null;
        }

    }


    public class SubClass extends SuperClass{
        
    //only compiles in Java 5 or later.
        public Integer caculate(){
            
    return null;
        }

    }

可以看出,以上这些特性都非常好地遵循了LSP。但是DbC呢?很遗憾,主流的面向对象语言(不论是动态语言还是静态语言)还没有加入对DbC的支持。但是随着AOP概念的产生,相信不久DbC也将成为OO语言的一个重要特性之一。

一些题外话:

前一阵子《敲响OO时代的丧钟》和《丧钟为谁而鸣》两篇文章引来了无数议论。其中提到了不少OO语言的不足。事实上,遵从LSP和OCP,不管是静态类型还是动态类型系统,只要是OO的设计,就应该对对象的行为有严格的约束。这个约束并不仅仅体现在方法签名上,而是这个具体行为的本身。这才是LSP和DbC的真谛。从这一点来说并不能说明“万事万物皆对象”的动态语言和“C++,Java”这种“按接口编程”语言的优劣,两类语言都有待于改进。庄兄对DJ的设想倒是开始引入DbC的概念了。这一点还是非常值得期待的。^_^
另外,接口的语义正被OCP、LSP、DbC这样的概念不断地强化,接口表达了对象行为之间的“契约”关系。而不是简单地作为一种实现多继承的语法糖。

posted @ 2006-01-18 18:12 GHawk 阅读(3950) | 评论 (2)编辑 收藏

敏捷软件开发 读书笔记 (3)——OO五大原则(2.OCP——开闭原则)

开闭原则很简单,一句话:“Closed for Modification; Open for Extension”——“对变更关闭;对扩展开放”。开闭原则其实没什么好讲的,我将其归结为一个高层次的设计总则。就这一点来讲,OCP的地位应该比SRP优先。

OCP的动机很简单:软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。

为什么要OCP?答案也很简单——重用。

“重用”,并不是什么软件工程的专业词汇,它是工程界所共用的词汇。早在软件出现前,工程师们就在实践“重用”了。比如机械产品,通过零部件的组装得到最终的能够使用的工具。由于机械部件的设计和制造过程是极其复杂的,所以互换性是一个重要的特性。一辆车可以用不同的发动机、不同的变速箱、不同的轮胎……很多东西我们直接买来装上就可以了。这也是一个OCP的例子。(可能是由于我是搞机械出身的吧,所以就举些机械方面的例子^_^)。

如何在OO中引入OCP原则?把对实体的依赖改为对抽象的依赖就行了。下面的例子说明了这个过程:

05赛季的时候,一辆F1赛车有一台V10引擎。但是到了06赛季,国际汽联修改了规则,一辆F1赛车只能安装一台V8引擎。车队很快投入了新赛车的研发,不幸的是,从工程师那里得到消息,旧车身的设计不能够装进新研发的引擎。我们不得不为新的引擎重新打造车身,于是一辆新的赛车诞生了。但是,麻烦的事接踵而来,国际汽联频频修改规则,搞得设计师在“赛车”上改了又改,最终变得不成样子,只能把它废弃。

OCP-fig1.JPG

为了能够重用这辆昂贵的赛车,工程师们提出了解决方案:首先,在车身的设计上预留出安装引擎的位置和管线。然后,根据这些设计好的规范设计引擎(或是引擎的适配器)。于是,新的赛车设计方案就这样诞生了。

 OCP-fig2.JPG

显然,通过重构,这里应用的是一个典型的Bridge模式。这个实现的关键之处在于我们预先给引擎留出了位置!我们不必因为对引擎的规则的频频变更而制造相当多的车身,而是尽可能地沿用和改良现有的车身。
说到这里,想说一说OO设计的一个误区。
学习OO语言的时候,为了能够说明“继承”(或者说“is-a”)这个概念,教科书上经常用实际生活中的例子来解释。比如汽车是车,电车是车,F1赛车是汽车,所以车是汽车、电车、F1赛车的上层抽象。这个例子并没有错。问题是,这样的例子过于“形象”了!如果OO设计直接就可以将现实生活中的概念引用过来,那也就不需要什么软件工程师了!OO设计的关键概念是抽象。如果没有抽象,那所有的软件工程师的努力都是徒劳的。因为如果没有抽象,我们只能去构造世界中每一个对象。上面这个例子中,我们应该看到“引擎”这个抽象的存在,因为车队的工程师们为它预留了位置,为它制定了设计规范。
上面这个设计也实现了后面要说的DIP(依赖倒置原则)。但是请记住,OCP是OO设计原则中高层次的原则,其余的原则对OCP提供了不同程度的支持。为了实现OCP,我们会自觉或者不自觉地用到其它原则或是诸如Bridge、Decorator等设计模式。然而,对于一个应用系统而言,实现OCP并不是设计目的,我们所希望的只是一个稳定的架构。所以对OCP的追求也应该适可而止,不要陷入过渡设计。正如Martin本人所说:“No significant program can be 100% closed.”“Closure not complete but strategic”

(下一篇就要讲LSP了,我觉得这是意义最为重要的OO设计原则,它直指当今主流OO语言的软肋,点出了OO设计的精髓。)

posted @ 2006-01-18 00:26 GHawk 阅读(7554) | 评论 (7)编辑 收藏

开源 Java 测试框架(转)

from  http://blog.csdn.net/wangyihust/archive/2006/01/02/568616.aspx

 JUnit   

JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架(regression testing framework)。Junit测试是程序员测试,即所谓白盒测试,因为程序员知道被测试的软件如何(How)完成功能和完成什么样(What)的功能。Junit是一套框架,继承TestCase类,就可以用Junit进行自动测试了。

http://www.junit.org/

 Cactus   

Cactus是一个基于JUnit框架的简单测试框架,用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法如HttpServletRequest,HttpServletResponse,HttpSession等。

http://jakarta.apache.org/cactus/

 Abbot   

Abbot是一个用来测试Java GUIs的框架。用简单的基于XML的脚本或者Java代码,你就可以开始一个GUI。

http://abbot.sourceforge.net/

 JUnitPerf   

Junitperf实际是junit的一个decorator,通过编写用于junitperf的单元测试,我们也可使测试过程自动化。

http://www.clarkware.com/software/JUnitPerf.html

 DbUnit   

DbUnit是为数据库驱动的项目提供的一个对JUnit 的扩展,除了提供一些常用功能,它可以将你的数据库置于一个测试轮回之间的状态。

http://dbunit.sourceforge.net/

 Mockrunner   

Mockrunner用在J2EE环境中进行应用程序的单元测试。它不仅支持Struts actions, servlets,过滤器和标签类还包括一个JDBC和一个JMS测试框架,可以用于测试基于EJB的应用程序。

http://mockrunner.sourceforge.net/index.html

 DBMonster   

DBMonster是一个用生成随机数据来测试SQL数据库的压力测试工具。

http://dbmonster.kernelpanic.pl/

 MockEJB   

MockEJB是一个不需要EJB容器就能运行EJB并进行测试的轻量级框架。

http://mockejb.sourceforge.net/

 StrutsTestCase   

StrutsTestCase 是Junit TestCase类的扩展,提供基于Struts框架的代码测试。StrutsTestCase同时提供Mock 对象方法和Cactus方法用来实际运行Struts ActionServlet,你可以通过运行servlet引擎来测试。因为StrutsTestCase使用ActionServlet控制器来测试你的代码,因此你不仅可以测试Action对象的实现,而且可以测试mappings,from beans以及forwards声明。StrutsTestCase不启动servlet容器来测试struts应用程序(容器外测试)也属于Mock对象测试,但是与EasyMock不同的是,EasyMock是提供了创建Mock对象的API,而StrutsTest则是专门负责测试Struts应用程序的Mock对象测试框架。

http://strutstestcase.sourceforge.net/

 JFCUnit   

JFCUnit使得你能够为Java偏移应用程序编写测试例子。它为从用代码打开的窗口上获得句柄提供了支持;为在一个部件层次定位部件提供支持;为在部件中发起事件(例如按一个按钮)以及以线程安全方式处理部件测试提供支持。

http://jfcunit.sourceforge.net/

 JTestCase   

JTestCase 使用XML文件来组织多测试案例数据,声明条件(操作和期望的结果),提供了一套易于使用的方法来检索XML中的测试案例,按照数据文件的定义来声明结果。

http://jtestcase.sourceforge.net/

 SQLUnit   

SQLUnit是一个单元测试框架,用于对数据库存储过程进行回归测试。用 Java/JUnit/XML开发。

http://sqlunit.sourceforge.net

 JTR   

JTR (Java Test Runner)是一个开源的基于反转控制(IOC)的J2EE测试框架。它允许你构建复杂的J2EE测试套件(Test Suites)并连到应用服务器执行测试,可以包括多个测试实例。JTR的licensed是GPL协议。

http://jtrunner.sourceforge.net/

 Marathon   

Marathon是一个针对使用Java/Swing开发GUI应用程序的测试框架,它由recorder, runner 和 editor组成,测试脚本是python代码。Marathon的焦点是放在最终用户的测试上。

http://marathonman.sourceforge.net

 TestNG   

TestNG是根据JUnit 和 NUnit思想而构建的一个测试框架,但是TestNG增加了许多新的功能使得它变得更加强大与容易使用比如:
*支持JSR 175注释(JDK 1.4利用JavaDoc注释同样也支持)
*灵活的Test配置
*支持默认的runtime和logging JDK功能
*强大的执行模型(不再TestSuite)
*支持独立的测试方法。

http://testng.org/

 Surrogate Test framework   

Surrogate Test framework是一个值得称赞单元测试框架,特别适合于大型,复杂Java系统的单元测试。这个框架能与JUnit,MockEJB和各种支持模拟对象(mock object )的测试工具无缝给合。这个框架基于AspectJ技术。

http://surrogate.sourceforge.net

 MockCreator   

MockCreator可以为给定的interface或class生成模拟对象(Mock object)的源码。

http://mockcreator.sourceforge.net/

 jMock   

jMock利用mock objects思想来对Java code进行测试。jMock具有以下特点:容易扩展,让你快速简单地定义mock objects,因此不必打破程序间的关联,让你定义灵活的超越对象之间交互作用而带来测试局限,减少你测试地脆弱性。

http://www.jmock.org/

 EasyMock   

EasyMock为Mock Objects提供接口并在JUnit测试中利用Java的proxy设计模式生成它们的实例。EasyMock最适合于测试驱动开发。

http://www.easymock.org/

 The Grinder   

The Grinder是一个负载测试框架。在BSD开源协议下免费使用。

http://grinder.sourceforge.net/

 XMLUnit   

XMLUnit不仅有Java版本的还有.Net版本的。Java开发的XMLUnit提供了两个JUnit 扩展类XMLAssert和XMLTestCase,和一组支持的类。这些类可以用来比较两张XML之间的不同之处,展示XML利用XSLT来,校验XML,求得XPath表达式在XML中的值,遍历XML中的某一节点利DOM展开。

http://xmlunit.sourceforge.net/

 Jameleon   

Jameleon一个自动化测试工具。它被用来测试各种各样的应用程序,所以它被设计成插件模式。为了使整个测试过程变得简单Jameleon提供了一个GUI,因此Jameleon实现了一个Swing 插件。

http://jameleon.sourceforge.net/index.html

 J2MEUnit   

J2MEUnit是应用在J2ME应用程序的一个单元测试框架。它基于JUnit。

http://j2meunit.sourceforge.net/

 Jetif   

Jetif是一个用纯Java实现的回归测试框架。它为Java程序单元测试以及功能测试提供了一个简单而且可 伸缩的架构,可以用于个人开发或企业级开发的测试。它容易使用,功能强大,而且拥有一些企业级测试的重要功能。Jetif来源于JUnit, JTestCase以及TestNG的启发,有几个基本的概念直接来自于JUnit, 比如说断言机制,Test Listener的概念,因此从JUnit转到Jetif是非常容易的。

http://jetif.sourceforge.net/

 GroboUtils   

GroboUtils使得扩展Java测试变得可能。它包括用在Java不同方面测试的多个子项目。在GroboUtils中最常被到的工具是:多线程测试(multi-threaded tests),整体单元测试(hierarchial unit tests),代码覆盖工具(code coverage tool)。

http://groboutils.sourceforge.net/

 Testare   

TESTARE是用来简化分布式应用程序(比如:在SERVLETS,JMS listeners, CORBA ORBs或RMI环境下)测试开发过程的一个测试框架。

https://testare.dev.java.net/

posted @ 2006-01-10 10:41 GHawk 阅读(1238) | 评论 (0)编辑 收藏