请原谅这几天的blog更新不是很频繁,是因为这天比较郁闷。我一直担心的日子,可能就要快来临了。
前几天开会传达上级指示,要求各单位加强保密工作。其中的一项措施,就是信息发布服务必须备案。一想到要跑到领导那儿,登记我要建立一个个人主页性质的blog,除了显得有些滑稽不够严肃之外,即使开恩批准,我也受不了这种被身边的人浏览自己的感觉。
所以,我一直担心的blog关张,可能就要来临了。如果有一天,这儿突然不能访问了,那就是这儿关张了。虽然,我将尽可能地提早提醒大家。
cron来自希腊语的chronos(时间)一词。在linux中,通过运行crontab -e就可以设置在特定的时刻自动运行你指定的程序。每个用户的自动运行程序,都放在/var/spool/cron/目录下,以自己用户名命名的文件中。在这些文件中,每一行都设置一个自动指行的命令,以及其运行的时间。每一行都由7个字段构成,相邻的字段以空格相间,每个字段的含义如下:
| Field | Meaning |
|---|---|
| 1 | Minute (0-59) |
| 2 | Hour (2-24) |
| 3 | Day of month (1-31) |
| 4 | Month (1-12, Jan, Feb, etc) |
| 5 | Day of week (0-6) 0 = Sunday, 1 = Monday etc or Sun, Mon, etc) |
| 6 | User that the command will run as |
| 7 | Command to execute |
参考文献:
今天开会路过北大清华,见到成群结队的学生,从年龄看似乎为初中生或高中生,有组织地参观清华、北大。人数之多,超乎想象,在清华的西门和二校门,以及北大的西门,照相的人站的满满的,交通都受到了影响。
说明:图中底部的一行是图例,用以说明上面的各部分的。
inline模型与box模型一起,并称css2.0的两个基本模型,前者主要控制一行内的某些字符的显示,后者主要控制页面上某块信息的显示及页面的整体布局。
一行的高度,是根据下列信息决定的:
inline模型,在《web重构》中并没有提到,因其重要而单列于此。
参考文献
Eric Meyer, CSS 2.0 Programmer's Reference
今天见wired上有人说,就顺着它提供的网址去看了看,原来是朝鲜计算机中心。
说实话,这是我第一次见到朝鲜的网站。什么时候能有机会,跟他们的计算技术人员聊聊,也了解一下他们现在技术力量和水平。
听说他们也搞特区了,估计早就有了公开网站,并且随着他们的经济的发展,在将来也会越来越多。
Checkstyle如名所示,是检查java程序源代码编码风格的,是java程序员不可或缺的工具,用以检查自己的编码习惯是否符合公司的要求或sun的约定。当然如果你用了ide,那里可能有相应的功能或插件来帮助程序员来完成这项工作。
也如checkstyle其名所示,它只检查,不进行beautifier操作。所以,它应比较适合用于项目管理,用于dailybuild.如果你想借助工具来beautifier你的java源代码,可以参考我写的jalopy安装使用.
下载安装
wget http://umn.dl.sourceforge.net/sourceforge/checkstyle/checkstyle-3.4.tar.gz
tar zxvf checkstyle-3.4.tar.gz
cd checkstyle-3.4
此时,checkstyle自身及其所需的jar包都在这个目录,平常我们只用checkstyle-all-3.4.jar一个包就可以了。子目录contrib下有几xsl文件,是用于检查结果的样式文件。
<!DOCTYPE project>
<!-- ANT make file checkstype --><!-- See http://jakarta.apache.org/ant for info about ANT -->
<project name="checkstyle" default="checkstyle" basedir=".">
<target name="init">
<tstamp/>
<!-- CheckStyle配置,这里你替换成你实际的环境 -->
<property name="project.docs.dir" value="${basedir}/contrib" />
<property name="project.src.dir" value="/path/to/your/source/codes" />
<property name="project.checkstyleReport.dir" value="${basedir}/build" />
<property name="checkstyle.jar" value="${basedir}/checkstyle-all-3.4.jar"/>
<property name="checkstyle.config" value="${project.docs.dir}/mycheck.xml"/>
<property name="checkstyle.report.style" value="${project.docs.dir}/checkstyle-noframes.xsl"/>
<property name="checkstyle.result" value="${project.checkstyleReport.dir}/checkstyle_result.xml"/>
<property name="checkstyle.report" value="${project.checkstyleReport.dir}/checkstyle_report.html"/>
</target>
<!--CheckStyle脚步-->
<taskdef resource="checkstyletask.properties" classpath="${checkstyle.jar}" />
<target name="checkstyle" depends="init" description=" 对java源代码进行检查并产生检查报告. ">
<checkstyle config="${checkstyle.config}" failOnViolation="false" failureProperty="checkstyle.failure">
<formatter type="xml" tofile="${checkstyle.result}"/>
<fileset dir="${project.src.dir}" includes="**/*.java"/>
</checkstyle>
<!-- 生成报告,其格式取决于${checkstyle.report.style} -->
<style in="${checkstyle.result}" out="${checkstyle.report}" style="${checkstyle.report.style}"/>
</target>
<!-- 当有不规范的情况发生时将检查结果发送到 -->
<target name="checkstyle-nightly"
depends="checkstyle"
if="checkstyle.failure"
description="Sends email if checkstyle detected code conventions violations.">
<mail from="发信方的email"
tolist="收信方的email"
mailhost="发信方email的服务器"
subject=" checkstyle result from project reports"
files="${checkstyle.report}"/>
</target></project>
记得第一次见到对句话的正面提法,是在记者报道前国家足球队主教练米卢时,引用米卢的原话。当时,觉得有文革遗风,甚不以为然。
随着工作时间的增长,看到身边的同事,虽然都是在写代码,其差别之大,并不完全由能力所致,更多的是责任心不够,才忽然觉得有点明白了“态度”的重要性。
冰云在他的blog中,列出了学习技术的几个要素:
兴趣,就是要有本身的能动性,对技术新知识感兴趣,而不是别人灌输其中,首当其冲的是兴趣,有兴趣自然有积极的态度。
信息,就是能够利用各种工具(google, maillist, forum),找到资料,找出有用资料
交流,是能够和别人讨论,问有价值问题,但是不依赖别人
思考,能独立思考,能有创新,善于总结,能够摸索着前进
实践,要动手,要验证自己的想法,要实战学来的技术
Zebra是一个高性能的、通用的,对结构化文本进行索引和检索的引擎。它支持的输入数据格式包括 email, XML, MARC等。通过提交精确的布尔检索式,可以得到按相关性排序的全文检索结果。
它本身带着一个z39.50服务器程序,如果你是在图书情报界工作,就会知道有这么一个服务器是多么方便。但,这也许是它没有提供很多的API的缘故,相比lucene、MG来说,就有所不足了。
它本身按GPL协议发布,能让人轻松地使用它。
下载安装zebra
wget http://ftp.indexdata.dk/pub/zebra/idzebra-1.3.15.tar.gz
tar zxvf idzebra-1.3.15.tar.gz
cd idzebra-1.3.15
./configure
make
make check
su
make install
cd examples/gils
zerbraidx update records
zerbrasrv @:2100
yaz-client localhost:2100
Z> find surficial
Z> show 1
Z> find sutrs
Z> show 1
Z> find grs-1
Z> show 1
Z> find xml
Z> show 1
Z> elements B
Z> show 1----------------------------
cd examples/zthes
make records/dino.xmlvi zebra.cfg
profilePath: .:../../tab
recordType: grs.sgmlzebraidx update records
zebrasrvyaz-client @:9999
Z> find
Z> format xml
Z> show 1vi Zthes.abs
attset zthes.att
attset bibl.att
xpath enable
systag sysno none
xelm /Zthes/termID termID:w
xelm /Zthes/termName termName:w,title:w
xelm /Zthes/termQualifier termQualifier:w
xelm /Zthes/termType termType:w
xelm /Zthes/termLanguage termLanguage:w
xelm /Zthes/termNote termNote:w
xelm /Zthes/termCreateDate termCreateDate:w
xelm /Zthes/termModifiedDate termModifiedDate:w
xelm /Zthes/termModifiedBy termModifiedBy:wZ> format xml
Z> f @attr 1=4 Eoraptor
Z> s
1)Font Family Matching
(1)Font Family: a collection of font faces given a common name
(2)Font Face: a variant on the default font in the font family
(3)Matching Order: font family-->font face-->character
(4)CSS 2.0 rules for advanced handling of font family matching
参考资料:
Eric Meyer , CSS 2.0 Programmer's Reference

ms IE5误解了width的含义,结果把width定义成了content+border的宽度之和。下列两行的定义显示是相同:
Eric Meyer在她的"CSS 2.0 Programer's Reference"一书中,更为详细地画出了box模型结构图。

参考文献:
思路非常简单:根据trackback ping中的url,将发送ping的页面除回来,然后解析其编码,如果是gbk或gb2312,则进行gb2312--->utf-8的转换。(注:我的blog用的是utf-8编码)
代码如下:
#################convert gb2312 into utf-8 if necessary#######
require Text::Iconv;
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $req = HTTP::Request->new(GET => $url);
my $res = $ua->request($req);
if ($res->is_success) {
my $content=$res->content;
if ($content =~ /text\/html.*charset=.*gb.*>/gi ){
my $converter = Text::Iconv->new("GB2312","UTF-8");
$excerpt = $converter->convert($excerpt);
$title = $converter->convert($title);
$blog_name = $converter->convert($blog_name);
}
}
##############end convert gb2312 to utf8##################
将上述代码,加入到$MTHOME/lib/MT/App/Trackback.pm的ping函数中
my $ping = MT::TBPing->new;几行的前面即可。
$ping->blog_id($tb->blog_id);
$ping->tb_id($tb_id);
$ping->source_url($url);
$ping->ip($app->remote_ip || '');
早上起来,看到没有列日当头,临时决定和朋友一起去爬香山新红楼。一路挥汗如雨自是不提,到红楼已是13点左右。坐护林人家的遮阳棚下吃喝时,忽发现山间浓雾越来越浓,且四处弥漫开来,不一会儿就看不见脚下的那些山头了。清凉的山风吹过,雾气也澎湃着从山梁的一侧涌过山脊,冲入到另一侧的雾中。
下山途中,浓云低垂,隐约可见闪电,可闻雷声。越往山下走,雨也越发大了起来。及至进入植物园,电闪雷鸣,大雨滂沱,小集成河,游人都在亭中、店前避雨。担心赶不上回程bus,我和朋友冒雨前行,开始还顾及不要湿鞋,后来见坡上雨水下泄,宽阔的路上水流成河,便也只求不要湿了太多衣服了。
好容易登上回程的733路bus,不曾想却遇到了罕见的大堵车。初始车行一路顺畅,直到4环路。西四环南去方向,主路和辅路,都是堵车。每等5、6分钟,bus方能小移一步。辅路上本是两车道,愣是并行着三排车。除了不时因一些bus出故障停大路边,阻挡了交通以外,每至交叉路口,车行只能蠕动。不断前行,方发现堵车远比想象中严重,四环路上,堵车之多,不见道尾。
及至进城,可见大街小巷,但凡可通车之路,皆堵,大有2001年百年大堵车之状。更有雨水在路边奔流,人行道上时见地面陷落,不由得行路分外小心。更见有水泵,从某楼地下室中,不停地泵出碗口粗的水柱,让人觉得骇然。
到21点多,才得以回到宿舍。从电视得知,城内17-20时暴雨,有车淹、有房倒。
Body { font-family: Verdana, sans-serif; }P, td, ul, ol, ul, li, dl, dt,dd { font-family: Verdana, sans-serif; }<link rel="StyleSheet" href="/styles/mystylesheet.css" type="text/css" media="all />
或
<style type="text/css" media="all">
@import "/styles/mystylesheet.css";
</style>
或
<style type="text/css" media="all">
@import url("/styles/mystylesheet.css");
</style>
注:@Import 法只有5.0以上的浏览器支持。。。 <head> 。。。 <style type="text/css"> <!- ….. --> </style> ….. </head> …..使用嵌入的原因:
增加结构的通用机制
mport java.io.IOException;
import java.net.UnknownHostException;
import java.net.URL;
import java.util.List;
import java.util.Date;
import java.util.ArrayList;
import java.io.BufferedWriter;
import java.io.Writer;
import java.io.FileWriter;
import com.sun.syndication.feed.synd.SyndFeedI;
import com.sun.syndication.feed.synd.SyndContentI;
import com.sun.syndication.feed.synd.SyndFeed;
import com.sun.syndication.feed.synd.SyndEntry;
import com.sun.syndication.feed.synd.SyndCategory;
import com.sun.syndication.feed.synd.SyndContent;
import com.sun.syndication.io.SyndFeedOutput;
import com.sun.syndication.io.SyndFeedInput;
public class RssCreator
{
public RssCreator()
throws TRIPException, UnknownHostException, IOException
{
}
public boolean genRss(String filename)
{
try
{
。。。connect to database and locat the latest 15 records....
String outputType = "rss_1.0";
String outputFile = filename;
Writer outWriter = null;
try{
outWriter=new BufferedWriter(new FileWriter(outputFile));
}catch (Exception e){
//deal exception
}
SyndFeedI feed = new SyndFeed();
feed.setFeedType(outputType);
feed.setTitle(converttoISO(" 你的站点的名称 "));
feed.setDescription(converttoISO("描述一下站点吧。"));
feed.setAuthor("author name");
feed.setLink("http://www.yoursite.com");
List entries = new ArrayList();
feed.setEntries(entries);
for (int i=0;i<15;i++) {
SyndEntry entry = new SyndEntry();
record = search.record(hits-i);
tfield=record.field("AUTHORS");
sfld = chkValue(tfield.getValue());
entry.setAuthor( sfld );
tfield=record.field("SUBCLASS");
sfld = chkValue(tfield.getValue());
List cats=new ArrayList();
SyndCategory cat=new SyndCategory();
cat.setName(sfld);
cats.add(cat);
entry.setCategories(cats);
//entry.setContents("什么内容呢?");
tfield=record.field("ABS");
sfld = chkValue(tfield.getValue());
SyndContentI desc=new SyndContent();
desc.setValue(sfld);
entry.setDescription(desc);
tfield=record.field("URL");
sfld = chkValue(tfield.getValue());
entry.setLink(sfld);
tfield=record.field("TITLE");
sfld = chkValue(tfield.getValue());
entry.setTitle(sfld) ;
//long ldate=(long)1079511514653;
tfield=record.field("ID");//我数据库中,ID用的是系统时钟
sfld = chkValue(tfield.getValue());
Date pdate=null;
pdate=new Date(new Long(sfld).longValue());
entry.setPublishedDate(pdate);
entries.add(entry);
}
SyndFeedOutput output = new SyndFeedOutput();
output.output(feed,outWriter);
outWriter.close();
...close database....
return true;
}
catch(Exception exception)
{
close database
close file
return false
}
return true;
}
private String chkValue(String s){
if (s==null) return "";
return s;
}
public static String converttoGB(String s)
{
try
{
byte abyte0[] = s.getBytes("ISO-8859-1");
return new String(abyte0, "gb2312");
}
catch(Exception exception)
{
return s;
}
}
public static String converttoISO(String s)
{
try
{
byte abyte0[] = s.getBytes("gb2312");
return new String(abyte0, "ISO-8859-1");
}
catch(Exception exception)
{
return s;
}
}
}
可能会遇到一些编码问题,所以可能要用到转换函数,写了几个放在代码末尾。
摘自《紫光阁》2004年第7期任敏的文章。我把引诗全文抄下来,以红字表明引用的句子。
赴戍登程口占示家人 林则徐
力徽任重久神疲,再竭衰庸定不支。
苟利国家生死以,岂因祸福避趋之。
谪居正是君恩厚,养拙刚于戍卒宜。
戏与山妻谈故事,试吟断送老头皮。
新制绫袄成感而有咏 白居易水波文袄造新成,绫软绵匀温复轻。
晨兴好拥向阳坐,晚出宜披蹋雪行。
鹤氅毳疏无实事,木棉花冷得虚名。
宴安往往叹侵夜,卧稳昏昏睡到明。
百姓多寒无可救,一身独暖亦何情。
心中为念农桑苦,耳里如闻饥冻声。
争得大裘长万丈,与君都盖洛阳城?
竹 郑板桥
衙斋卧听萧萧竹,疑是民间疾苦声;
些小吾曹周县吏,一枝一叶总关情!
我爱这土地 艾青假如我是一只鸟,
我也应该用嘶哑的喉咙歌唱:
这被暴风雨所打击着的土地,
这永远汹涌着我们的悲愤的河流,
这无止息地吹刮着的激怒的风,
和那来自林间的无比温柔的黎明…… ——然后我死了,
连羽毛也腐烂在土地里面。为什么我的眼里常含泪水?
因为我对这土地爱得深沉……
春愁 丘逢甲
春愁难遣强看山,往事惊心泪欲潸;
四百万人同一哭,去年今日割台湾。
| 产品 | 推出时间 | 支持HTML/XHTML | 支持CSS1 | 支持CSS2 | 支持ECMAScript/DOM |
| Opera 7 | 2002 | 支持 | 几乎全部 | 大部分 | 支持 |
| MSIE5+/Mac | 2001 | 支持 | 全面支持 | 部分 | 支持 |
| Netscape 6+ | 2001 | 支持 | 全部 | 大部分 | 基本上支持 |
| Mozilla 1.0 | 2002 | 支持 | 全部 | 大部分 | 基本上支持 |
| Safari | 2002 | 支持 | 大部分 | 一部分 | 基本上支持 |
| MSIE6/Win | 2001 | 支持 | 大部分 | 部分 | 基本上支持 |
| MSIE5.5/win | 2001 | 支持 | 大部分有大bug | 不太支持 | |
| MSIE5/win | 1999 | 支持,有漏洞 | 一点点有大bug | 一点点 | |
| Netscape 4 | 1997 | 部分支持 | 几乎不支持 | 不支持 | |
| MSIE4 | 1997 | 比NS4小 | 比NS4小 | 不支持 |
XHTML是一个基于XML的置标语言,看起来与HTML有些想像,只有一些小的但重要的区别。可以这样看,XHTML就是一个扮演着类似HTML的角色的XML。本质上说,XHTML是一个桥接(过渡)技术,结合了XML(有几分)的强大功能及HTML(大多数)的简单特性。
----Jeffery Zeldman
切换到XHTML的10个理由:
Web标准是指结构化的语言(如XHTML和XML),解释性语言(如CSS),对象模型(W3C DOM)和脚本语言(ECMAScript)。 ----Jeffery ZeldmanWeb标准的最初目标,是为了统一同一网页在各种浏览器中的显示,结束浏览器显示web页面的任意性,保证站点为更多的人和更多的平台工作。Web标准承诺:“写一次,即可发表在任何地方”。
Web标准把网页分成三个独立组成部分:
Web标准至今汉有对外观审美做任何指导方针和戒律,对站点的外观和感觉没有做任何限制,它们只不过使浏览器能够正确地表现设计师创建的站点,帮助客户根据公司的市场需求和用户分析来制定目标。
Web标准可以做到:
使用web标准的原因:
作者Jeffer Zeldman为“制作网站的人们”开办了一份在线杂志ALA,里面有很多很有价值的文章(虽然网站的logo总让我联想起一个不雅的手势:)。
“For people who make websites”
A List Apart Magazine (ISSN: 1534-0295) explores the design, development, and meaning of web content, with a special focus on techniques and benefits of designing with web standards.
----via www.alistapart.com
语法 ======php_value name value
-- This sets the value of the specified variable.php_flag name on|off
-- This is used to set a Boolean configuration option.
php_admin_value name value
-- This sets the value of the specified variable.
"Admin" configuration settings can only be set from within
the main Apache configuration files, and not from .htaccess files.php_admin_flag name on|off
-- This is used to set a Boolean configuration option.例程
========
<IfModule mod_php4.c>
php_value include_path ".:/usr/local/lib/php"
php_admin_flag safe_mode on
</IfModule>
<IfModule mod_php3.c>
php3_include_path ".:/usr/local/lib/php"
php3_safe_mode on
</IfModule>常用
=========
php_flag expose_php Off
php_flag register_globals Off
#variables_order EGPCSauto_prepend_file string
auto_append_file string
default_charset string
include_path
我对php不熟悉,今天才知,这些参数的运用,可以更加灵活地进行网站建设。举例如下:
可以在apache输出的每个html或htm页面后追加执行文件file.php.
AddType application/x-httpd-php .html .htm
php_value auto_append_file /path/to/file.php
参考文献:
http://worldhello.net/doc/website_howto/apache-conf.html
mvm的“75条”,读来深以为然,特转载于此。
1. 你们的项目组使用源代码管理工具了么?
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
2. 你们的项目组使用缺陷管理系统了么?
应该用。ClearQuest太复杂,我的推荐是BugZilla。
3. 你们的测试组还在用Word写测试用例么?
不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
4. 你们的项目组有没有建立一个门户网站?
要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
5. 你们的项目组用了你能买到最好的工具么?
应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。
6. 你们的程序员工作在安静的环境里么?
需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。
7. 你们的员工每个人都有一部电话么?
需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。
8. 你们每个人都知道出了问题应该找谁么?
应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。
9. 你遇到过有人说“我以为…”么?
要消灭“我以为”。Never assume anything。
10. 你们的项目组中所有的人都坐在一起么?
需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。
11. 你们的进度表是否反映最新开发进展情况?
应该反映。但是,应该用Baseline的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
12. 你们的工作量是先由每个人自己估算的么?
应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。
13. 你们的开发人员从项目一开始就加班么?
不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
15. 值得再多花一些时间,从95%做到100%好
值得,非常值得。尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。
16. 登记新缺陷时,是否写清了重现步骤?
要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。
17. 写新代码前会把已知缺陷解决么?
要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。
18. 你们对缺陷的轻重缓急有事先的约定么?
必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
19. 你们对意见不一的缺陷有三国会议么?
必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
20. 所有的缺陷都是由登记的人最后关闭的么?
Bug应该由Opener关闭。Dev不能私自关闭Bug。
21. 你们的程序员厌恶修改老的代码么?
厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。
22. 你们项目组有Team Morale Activity么?
每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。
23. 你们项目组有自己的Logo么?
要有自己的Logo。至少应该有自己的Codename。
24. 你们的员工有印有公司Logo的T-Shirt么?
要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。
25. 总经理至少每月参加次项目组会议
要的。要让team member觉得高层关注这个项目。
26. 你们是给每个Dev开一个分支么?
反对。Branch的管理以及Merge的工作量太大,而且容易出错。
27. 有人长期不Check-In代码么?
不可以。对大部分项目来说,最多两三天就应该Check-In。
28. 在Check-In代码时都填写注释了么?
要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。
29. 有没有设定每天Check-In的最后期限?
要的,要明确Check-In Deadline。否则会Build Break。
30. 你们能把所有源码一下子编译成安装文件吗?
要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么?
当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。
32. 你们公司有没有积累一个项目风险列表?
要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。
33. 设计越简单越好
越简单越好。设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。
34. 尽量利用现有的产品、技术、代码
千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。
35. 你们会隔一段时间就停下来夯实代码么?
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。
36. 你们的项目组每个人都写Daily Report么?
要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。
37. 你们的项目经理会发出Weekly Report么?
要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。
38. 你们项目组是否至少每周全体开会一次?
要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
39. 你们项目组的会议、讨论都有记录么?
会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。
40. 其他部门知道你们项目组在干什么么?
要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。
42. 为项目组建立多个Mailing Group
如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。
43. 每个人都知道哪里可以找到全部的文档么?
应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。
44. 你做决定、做变化时,告诉大家原因了么?
要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。
45. Stay agile and expect change
要这样。需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。
46. 你们有没有专职的软件测试人员?
要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。
47. 你们的测试有一份总的计划来规定做什么和怎么做么?
这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。
48. 你是先写Test Case然后再测试的么?
应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。
49. 你是否会为各种输入组合创建测试用例?
不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。
50. 你们的程序员能看到测试用例么?
要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。
51. 你们是否随便抓一些人来做易用性测试?
要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。
52. 你对自动测试的期望正确么?
别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。
53. 你们的性能测试是等所有功能都开发完才做的么?
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。
54. 你注意到测试中的杀虫剂效应了么?
虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。
55. 你们项目组中有人能说出产品的当前整体质量情况么?
要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。
56. 你们有单元测试么?
单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。
57. 你们的程序员是写完代码就扔过墙的么?
大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。
58. 你们的程序中所有的函数都有输入检查么?
不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。
59. 产品有统一的错误处理机制和报错界面么?
要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
60. 你们有统一的代码书写规范么?
要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么?
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。
62. 产品各部分的界面和操作习惯一致么?
要这样。要让用户觉得整个程序好像是一个人写出来的那样。
63. 有可以作为宣传亮点的Cool Feature么?
要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
64. 尽可能缩短产品的启动时间
要这样。软件启动时间(Start-Up time)是客户对性能好坏的第一印象。
65. 不要过于注重内在品质而忽视了第一眼的外在印象
程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。
66. 你们根据详细产品功能说明书做开发么?
要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。
67. 开始开发和测试之前每个人都仔细审阅功能设计么?
要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么?
要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么?
不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。
70. 你们的程序员写程序设计说明文档么?
要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。
71. 你在招人面试时让他写一段程序么?
要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。
72. 你们有没有技术交流讲座?
要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。
73. 你们的程序员都能专注于一件事情么?
要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。
74. 你们的程序员会夸大完成某项工作所需要的时间么?
会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。
75. 尽量不要用Virtual Heads
最好不要用Virtual Heads。Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对Resource Manager的。
一般认为,简体中文网页上,汉字采用9pt(约12px)或10.5pt(约14.7px)的宋体,英文数字采用verdana 和Arial字体,看起来最舒服。同时,为了保证不同浏览器上字号保持一致,字号建议用点数 pt 和像素 px 来定义。
还有,行距则多用百分比来表示,常用的两个值是120%和150%。我见isaac在固定了字号以后,用16pt做行距,感觉也还不错。
还有,个人认为,不允许用户通过浏览器文字大小,来变动显示的文字的大小,也有些不太人性化。
font-size功能:用各种度量单位控制文本字体大小。
数值:有四种数值方式
绝对尺寸- 用具体字号表定义字体大小,可以取下列数值之一:xx - small, x-small, small, medium, large, x-large, xx-large。不同字体有不同的数值。
相对尺寸 - larger, smaller,产生的尺寸是相对于父容器字号而言的。
长度 - 用毫米(mm),厘米(cm),英寸(in),点数(pt),象素(px),pica(pc),e x(小写字母x的高度)或em(字体高度)作为度量单位。
百分比 - 相对于其父元素字体大小的百分比。
letter-spacing
功能:控制文本元素字母间的间距,所设置的距离适用于整个元素。
数值:
normal - 正常间距,将字符间的间距复位为所有字体和字号的正常间距。
长度 - 设置字间距长度,正值表示加进父元素中继承的正常长度,负值则?去正常长度。在数字后指定度量单位如下:mm, cm, in, pt(点数), px(象素), pc(pica), ex(小写字母x的高度), em(大写字母M的宽度)。line-height
功能:设置元素中文本的行间距。
数值:
normal - 正常高度,通常为字体尺寸的 1-1.2倍,这是缺省设置。
数字 - 设置元素中?行文本的距离为字体尺寸乘以这个数字。例如字体尺寸为1
0点,设置line-height为2,则间距20点。
长度 - 用标准度量单位设置间距,有些是绝对的,有些是相对的详见letter-spacing中的说明
百分比 - 也字体尺寸的百分比设置间距。
文后参考文献1,对有建立网站具有普遍的参考意义,同时在网上搜到一篇word文档,与参考文献1内容一致,放在这儿供下载。
参考文献: