WEB3.0标准发起人

无法忍受MSN BLOG的速度。真的太慢，占客户端资源太多。

换新浪BLOG了。地址是……

1,<script>Js脚本被动态载入updatePanel后，将不起作用，除非加Defer，但不兼容firefox。
2,updatePanel的嵌套会引发一系列js错误。比如up1里面有个Treeview,up1放入up2中，则Treeview的展开折叠等一系列js失效。所以，尽量不要嵌套UpdatePanel

这个世界的Internet发疯了，

对手总是没有理由地出现、追赶你

并在你大意的时候超过你。

 

所以我们也没有理由停下来孤芳自赏。

唯有不断学习、努力，才能永远立于不败之地。

 

活到老，学到老，亦有一番乐趣。

 

与世无争的思想，不适合这个时代，我想也不适合任何时代。

 

From:http://hi.baidu.com/fhzjgd/blog/item/c85b8e8bd6d4ecd3fc1f1008.html

一、深入浅出理解索引结构

　　实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别：
　　其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
　　如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
　　通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

二、何时使用聚集索引或非聚集索引

下面的表总结了何时使用聚集索引或非聚集索引（很重要）：

动作描述	使用聚集索引	使用非聚集索引
列经常被分组排序	应	应
返回某范围内的数据	应	不应
一个或极少不同值	不应	不应
小数目的不同值	应	不应
大数目的不同值	不应	应
频繁更新的列	不应	应
外键列	应	应
主键列	应	应
频繁修改索引列	不应	应

　　事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。

三、结合实际，谈索引使用的误区

　　理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。

1、主键就是聚集索引
　　这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。
　　通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。
　　显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。
　　从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。
　　在办公自动化系统中，无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。
　　通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，通过“日期”这个字段来限制表扫描，提高查询速度。如果您的办公自动化系统已经建立的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。
　　在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即使您在“日期”这个字段上建立的索引（非聚合索引）。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现（3个月内的数据为25万条）：

（1）仅在主键上建立聚集索引，并且不划分时间段：

Select gid,fariqi,neibuyonghu,title from tgongwen

用时：128470毫秒（即：128秒）

（2）在主键上建立聚集索引，在fariq上建立非聚集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen
where fariqi> dateadd(day,-90,getdate())

用时：53763毫秒（54秒）

（3）将聚合索引建立在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen
where fariqi> dateadd(day,-90,getdate())

用时：2423毫秒（2秒）

　　虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有1000万容量的话，把主键建立在ID列上，就像以上的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。得出以上速度的方法是：在各个select语句前加：

declare @d datetime
set @d=getdate()

并在select语句后加：

select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

2、只要建立索引就能显著提高查询速度
　　事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同；不同的仅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。所以，并非是在任何字段上简单地建立索引就能提高查询速度。
　　从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。

3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度
　　上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要，我们可以把他们合并起来，建立一个复合索引（compound index）。
　　很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）：

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5'' 

查询速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen 
　　　　　　　　　　　　where fariqi>''2004-5-5'' and neibuyonghu=''办公室''

查询速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=''办公室''

查询速度：60280毫秒

　　从以上试验中，我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的，甚至比用上全部的复合索引列还要略快（在查询结果集数目一样的情况下）；而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。当然，语句1、2的查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。

四、其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快
　　下面是实例语句：（都是提取25万条数据）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''

使用时间：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

使用时间：4470毫秒

这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。

2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

用时：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

用时：18843

　　这里，用聚合索引比用一般的主键作order by时，速度快了3/10。事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。

3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个：

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-1-1''

用时：6343毫秒（提取100万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>''2004-6-6''

用时：3170毫秒（提取50万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=''2004-9-16''

用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen 
　　　　　　　　　　　　where fariqi>''2004-1-1'' and fariqi<''2004-6-6''

用时：3280毫秒

4、日期列不会因为有分秒的输入而减慢查询速度
　　下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精确到日；之前有数据50万条，有5000个不同的日期，日期精确到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen 
　　　　　　　　　　where fariqi>''2004-1-1'' order by fariqi

用时：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen 
　　　　　　　　　　　　where fariqi<''2004-1-1'' order by fariqi

用时：6453毫秒

五、其他注意事项

　　“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。
　　所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。
　　当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。

采用Microsoft Web Deployment Projects可以在Visual Studio 2005（也适合中文版本VS2005）中生成唯一程序集的方法.参见这位大哥的妙文。

 

如果编译后，运行网站出现了CS0030的错误，基本上是名称混淆的问题。记得在VS2005的page页加上命名空间（VS2005默认给去掉了，我个人觉得这可是大退步。为了兼容1.1?）看看这篇文章《当控件基类与页面基类名称相同时 CS0030》

大旗网可能是去年风头最劲的互联网创业公司之一，不过随着大旗网今年业务的收缩，以及总裁兼总编辑马晓霖的离职，不少人认为，这代表Web 2.0的一面大旗倒了。

但大旗网能代表Web 2.0吗？我不这么认为。大旗选择了正确的方向，却选择了错误的方法。近年来，互联网社区受到追捧，并成为增长最快的领域之一。从Craigslist被大量模仿，到Myspace被新闻集团5.8亿美元收购，再到YouTube以16.5亿美元被Google吞并，互联网社区正在成为一个被资本发现的新大陆。大旗选择在社区内容上寻求机会，方向没问题。但它以新浪的模式，雇佣大量的编辑来做社区内容，这个方法却大有问题。

新浪在特定时期，重新组织传统媒体的内容，以海量、快速的内容服务，满足中国网民的新闻需求，迅速奠定了中国互联网第一门户的地位。但这个历史窗口已经关闭，内容不再是互联网上的稀缺资源，而以广告支持的内容编辑模式，新浪、搜狐、网易、乃至腾讯都可以做，但他们所做的，也只是分流同一块广告资源，而不是创造新的广告或其他商业模式。以新浪模式做社区内容，必须承担新浪的成本，却无法获得新浪的收益，这是大旗的死结。

选择传统媒体的运作思路，来运作遍地丛生的社区内容，新奇固然新奇，但却无法建立用户的认知和归属感。而用户的认知和归属感，是社区赖以存在的前提。所以，尽管有人猜测，大旗将建立自己的社区。不过王定标一再否认这种说法，因为他很清楚，经营一家成功的社区，肯定不是雇佣一批编辑就可以做到的。

大旗所面临的困境，代表在风险投资的压力之下，单纯做流量、抓眼球的做法，是没有出路的。Web 2.0将整个互联网平台化，用户，而不是编辑，成为在这个平台上活动的主角。所以，即使大旗真的倒下，也只是某种经营思路的挫败，而不是Web 2.0理念的失败。

（原发Donews）

很多朋友不太明白web3.0图中那5条。特简单阐释一下。

WEB3.0标准的核心条例如下：

l         继承WEB2.0的所有特性。比如：以用户为中心，用户创造内容，广泛采用Ajax技术，广泛采用RSS内容聚合，表现为BLOG大行其道，互联网上涌现大量的个人原创日志。

l         帮助用户实现他们的劳动价值。目前的WEB2.0，几乎都是让用户免费劳动，让他们免费生产内容娱人娱己。用户很难通过WEB2.0网站把自己辛辛苦苦生产的内容换成真实货币。WEB3.0首要任务就是让他们不再浪费劳动力，实现他们的劳动价值。

l         网站无边界，遵守WEB3.0标准的网站可以方便地在数据、功能上实现彼此的互通、互动。未来的互联网是合作、共赢、资源互补、互促的互联网。分久必合，有相关利益的网站会联合起来，趋向于一体化。一个强有力的、方便的对外交互的标准，是每个WEB3.0网站都必须实现的。

l         具备更清晰可行的盈利模式。现在的WEB2.0网站大部分没有清晰可行的盈利模式，这是商业网站的致命弱点。有些WEB2.0网站有一些广告收入来源，但是规模不够，收入只是杯水车薪，一开始规模太大，烧钱太多，入不敷出，注定要成饿死的骆驼。

l         非仅限于互联网应用。这是WEB3.0标准的外延。WEB3.0的外延思想，可以应用到其他非互联网行业领域。

标准都很简单。

实现却不是那么容易。

诸君多努力，

多思考，

说不定你就是第一个实现新标准的成功者。

是从Paypal.com发过来的。

订单处理在新加坡，然后绕道纽约发来。

赚赚美金，纯属娱乐。

和北京比，

地小，街道脏，空气还有点臭。

车少，名牌车多，宝马、奔驰很常见，20辆汽车里面有一辆宝马，第3产业林立。

鞋厂遍地开花。

作坊经济。

暂时还没找到好玩的景点。

记得那首歌你为我唱过。

是那种至纯至美的爱情，让我长地感动。

人生有一次那样的真爱就足够了，就是那种偶然心动的爱情。

再次重听这首歌，仍是很美。

远方的你，这些年还好吗？

————————————————————

你我素不相识
爱从偶然心动开始
一心做你想做的事
扮成你喜欢的样子
散开我的发丝
是想缠住你的影子
模仿你说话的手势
追问你话里的意思
疼爱一次 挂念一世
甘心从此让感情驱使
不再有我自己的日子
和那些爱过以后才懂的事
疼爱一次 挂念一世
在我心里最好的位置
放着我给你起的名字
和那些爱过才懂的事

————————————————————

知道什么是快闪吗？看这个，12人当街向MM求婚，比行为艺术有过之而无不及，独特之处在于 其闪得光速……

Win2003服务器环境，安装：

先WSS，后装SPS，最后装Project 2003 Server.

 

安装好之后，进入SPS管理中心（左侧包含了WSS管理连接），WSS管理界面中，扩展某个虚拟目录，这个虚拟目录专门用来放PWA用的“文档、问题、风险”的。这个虚拟目录，最好自己在IIS中重新建一个空网站当作“虚拟目录”。

 

虚拟目录扩展好了之后。运行Project 2003 Serve 安装光盘里面的“Windows Sharepoint Server 配置向导”，配置该虚拟目录，给WSS装上Project用的网站模板，名为“项目工作环境”，同时为PWA建立了一个公用文档的网站（http://serve:80/sites/MS_ProjectServer_PublicDocuments）。配置完后，会显示2条URL信息，注意记下来。

 

OK，返回PWA，用管理帐号登录，进入“管理”－“管理 Windows SharePoint Services”，添上上一步记录的2条信息。保存，就可以初步完成讲SPS与PWA结合起来了。

原来是SQL脚本不兼容问题。

 

需手动建立ProjectServer数据库。

 

在公司服务器上装的这个软件，应该足够让一部分人羡慕了

钓翁之意不在鱼，在乎山水之间也。

发现野外的风景真是不错。

虽然和几个同事3根钓竿大半天才钓了3条鱼（其中2条鲫鱼比较大，还跑了2条喔），

但是狠狠地呼吸了一天的新鲜空气，并且一饱山水景色，眼睛很是受用。

更有趣的是，我上树摘了7、8来个野梨，哈哈，虽然个头不大，味道真不错。鲜！还有野枣，甜！

 

小旃真不是盖的，骑车来回60多公里，身体倍儿棒！学习ing!

小张想必下次也想骑车去了。:D

XP在很多方面都和我们传统意义上的软件工程不同，同时，它也和传统得管理和项目计划的方法不同。

这些方法在软件工程和其他管理活动中都有借鉴意义。

特点如下：
不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布的软件开发的全过程。每个周期都进行充分的测试和集成。这样的好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的风险。

在软件设计中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件的合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中的熵值。

在专业分工中，提出在开发团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。

也有专门的软件架构的设计师，首先进行软件整体架构的设计。这种设计一般使用UML语言。

在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验，这样，可以获得客户的更多的反馈，使需求可以在开发前确定。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。通过不断的测试来保证软件的质量。在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。

在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。

在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长，适应自己的情况。当然，在每个问题上都要有唯一的决策人，同时，也要经过充分的交流和沟通。角色轮换就是在项目中，一个人在不同的周期中担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，要对整个项目的完成负责，任何人都可以对工作的任何部分提出自己的建议。任何人都可以从事任何工作。任何人都要对整个项目熟悉。这样做的优点是可以充分的锻炼人、可以发挥每个人的积极性、可以使项目不依赖于某个特定的人，方便今后的软件的维护，通过工作内容的变换可以提高人工作的兴趣。通过角色轮换还可以使每个人都劳逸结合，方便相互理解，避免由于不理解而造成的各种配合问题。

保证8小时工作制，避免加班。

（我加几条：要有充分的培训、要有每个人的提升空间、制定报酬要根据对企业的贡献大小，而不是职位的高低，允许下属比上级薪酬更高，薪酬的高低取决于绩效评定，同时绩效评定要尽可能量化。并且推行淘汰制。同时有有效的招聘制度。有强有力的后勤保障制度和轻松的企业文化。）

提出了成对编程的思路，就是每个模块的编码都是两个人一起干，共用一台电脑。这样，一个人编码时，另一个人就可以检查代码，或对编码的思路进行思考，写文档等。不再有另外的测试人员，两个人同时完成代码的测试，并且使先写测试程序然后再编程。这样避免了编程人员和测试人员的矛盾。也解决了一个人自己检查的局限性。两个人共同检查可以避免大多数的错误。在共同编程中还可以进行经验的交流和传授。也避免了将一个工作一直干下去的无聊，交流增加了情趣。并且两个人共同工作也增加了工作量的弹性，使项目计划的瓶颈工作能尽快解决。根据成对编程的思路，开发小组也可以分为两个小组，一个小组进行开发，另一个小组作改进和bug修正等工作。也有同样的效果。

在人员的分工上要灵活，要保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。

每天或隔天，开一个站立会议（保证开会时间尽量短），来解决工作时间不一致和相互打扰工作的情况。在每个迭代周期也有一个计划和分工等的全体大会。

XP的实施方法就要求能适应工作中出现的问题，不断对xP进行改进，而不能照搬套用。

XP的目标就是发挥人的最大积极性，保证充分的交流。

XP得优势是能很好得适应需求得更改、设计框架得更改。

XP采用和建立一个通常框架相反得方法来适应需求，而是尽量简单。

刚开妹儿，就发现一连串的问题，够猛。

 

好歹大学英语派上了用头，一边看，一边查金山词霸，然后一边回忆古老的英语句法……

 

踉踉跄跄总算回复了，迫不及待点了foxmail的"Send"。

 

嘟……

 

回头一看，错了3处:

use打成了user

needn't any spending打成了needn't any spend spending

DAL and BLL打成了DLL and BLL

 

完了，要被老外笑咱文盲了

可惜，现在中国的开发者，基本上是既当爹又当妈，开发＋顾问一起做。

 

这样两件事情集中在乙方一人说辞上，往往让甲方对开发者（乙方）不信任。

 

盼……适合中国的本土解决方法出现。

准备了那么久，花了那么多时间和精力。。。却得来这个结果，心里头多少还是有点失落的，虽然于朋友面前我表现得很无所谓。

 

btw：今天开MSN BLOG，居然发现功能更新了，

 

哈哈，今天也算有喜有忧了。

一天跑两趟客户

 

回来还要写和西门子的合同草稿呢……

 

还有N多方案

 

很想有个KAI.MA来帮我

 

全美教育的杨先生那天还说“不想做这个行业的老板”，现在明白了，太累贝。

 

 

 

为了申请用友的伙伴关系，忙着准备资料。

公司简介、公司案例、案例截图、文档编写、主要成员简介……

发现什么都要自己来，这个经理当得可真够累喔～～～

 

为了让公司网站早日上线，手下的人做的东西虽然不错，不知道为什么就达不到我想的那个意境呢，没办法啊没办法，只好自己亲自操刀做了大部分的设计（以后这样的事情，咱肯定不自己来了，太累了，分工合作才是正途）。

 

LOGO，自己重新亲自设计了的公司LOGO，多年前努力自学的CI知识总算派上用场了

我自己比较喜欢这样的布置。

原载某网友文

 

 

 

为什么在此独论第七？很简单，相时而动、随机应变者，的确是人杰喔。

 

人的成长过程，会有很多结论、信条。这些结论，信条，我认为几乎没有几条可以是放之四海而皆准的。

 

因此有了成长之后相对未成长之前的异同。