GHawk

2006年3月1日 #

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

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

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

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


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

posted @ 2007-05-28 14:32 GHawk 阅读(1530) | 评论 (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 阅读(1316) | 评论 (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 阅读(1432) | 评论 (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 阅读(746) | 评论 (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 阅读(1201) | 评论 (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 阅读(2031) | 评论 (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 阅读(1884) | 评论 (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 阅读(1640) | 评论 (4)编辑 收藏