一剑飞虹

一只鸡和一头猪在路上走，鸡对猪说：“你想不想和我一起开家餐馆？”
猪想了一想，答道：“好的，我很乐意。你想为餐馆起个什么名字呢？”

鸡回答道：“火腿和蛋！”
猪停步，犹豫了一下，说：“三思过后，我决定不和你开这家餐馆了。因为我得全身心付出，而你仅仅是牵涉入内。”

以此区分项目中的责任人。

1.安装JDK1.6.0_10。并在系统路径里加上JAVA_HOME指向jdk的安装路径，在Path里加上%JAVA_HOME%"bin。

2.下载CRUISECONTROL-BIN-2.7.3解压到指定目录。运行目录下的cruisecontrol.bat即可。

运行时如果在Starting HttpAdaptor时报错，可能是端口问题，可以修改bat里的“-jmxport 8000 -webport 8080 -rmiport 1099”的端口号。

cruisecontrol.bat     启动文件;
config.xml                 配置文件  (默认的配置文件名称);
apache-ant-1.7.0    是CruiseControl自带的ant环境，CruiseControl要借助ant完成一些指定的任务;
docs                          包括CruiseControl的使用文档和一个helloworld的使用范例;
lib                              是运行需要的jar包;
logs                          日志目录,构建时产生的log存储于此;
project                      需要构建的项目所在目录，也是checkout默认的目录,所有的构建项目在project均以项目名为目录;在project目录下，有一个自带的项目connectfour，包含了src、lib、test和build.xml。
webapps                web应用目录。CruiseControl内置了jetty作为web容器，可以通过web方式查看构建结果和手动创建项目;通过http://localhost:8080/
artifacts                    输出目录，集成后生成的jar就保存在这里。

3.配置

CruiseControl(以下简称 CC) 主要有两个配置文件：
一个是config.xml，是CC初始化、调度等任务参数的配置；

一个是build.xml，ant执行的配置文件，CC借助ant完成指定的任务，如checkout、compile、jar、test等。
学ant来这里http://ant.apache.org/manual/index.html

config.xml:

<schedule interval="30">:间隔时间，单位秒。

build.xml:

<project name="Hello world" default="compile">:最好指定一下default,这样直接运行ant就可以了。

<target name="compile" depends="init" description="compile the source files">：运行complie前，要求运行init。会自动调用。

时间戳

<target name="init" depends="" description="总控">
        <tstamp>
            <format property="BEGIN_TIME" pattern="MM/dd/yyyy hh:mm a" offset="-1" unit="minute" locale="en" />
        </tstamp>
        <echo>生成时间：${DSTAMP}-${TSTAMP}</echo>
        <echo>开始时间：${BEGIN_TIME}</echo>
    </target>

目录操作

删除<delete dir="target/website" failonerror="no" />

创建<mkdir dir="target/website/reporting/jsp" />

文件操作

拷贝 <copy todir="target/zip" overwrite="true">
            <fileset dir=".">
                <include name="**/*.html" />

                <exclude name="**/target/**" />
                <date datetime="${BEGIN_TIME}" when="after" />
            </fileset>
        </copy>

替换<replace dir="target/binzip" token="%%VERSION%%" value="${cc.release.label}">
            <include name="**/*" />
        </replace>

正则替换<replaceregexp match=""r"n" replace="" flags="g" byline="false">
        <fileset dir="${war.dir}/site/layouts/" includes="**/*.jsp" />
    </replaceregexp>

编译

<javac srcdir="${src.java}" destdir="${basedir}/WebRoot/WEB-INF/classes" classpathref="classpath.build" debug="true">
<compilerarg value="-Xlint:deprecation"/>
</javac>

 

有一年，一支英国探险队进入撒哈拉沙漠的某个地区，在茫茫的沙海里跋涉。阳光下，漫天飞舞的风沙像炒红的铁砂一般，扑打着探险队员的面孔。口渴似炙，心急如焚---大家的水都没了。这时，探险队长拿出一只水壶，说："这里还有一壶水，但穿越沙漠前，谁也不能喝。"

一壶水，成了穿越沙漠的信念之源，成了求生的寄托目标。水壶在队员手中传递，那沉甸甸的感觉使队员们濒临绝望的脸上，又露出坚定的神色。终于，探险队顽强地走出了沙漠，挣脱了死神之手。大家喜极而泣，用颤抖的手拧开那壶支撑他们的精神之水---缓缓流出来的，却是满满的一壶沙子！

炎炎烈日下，茫茫沙漠里，真正救了他们的，又哪里是那一壶沙子呢？他们执着的信念，已经如同一粒种子，在他们心底生根发芽，最终领着他们走出了"绝境"。

事实上，人生从来没有真正的绝境。无论遭受多少艰辛，无论经历多少苦难，只要一个人的心中还怀着一粒信念的种子，那么总有一天，他就能走出困境，让生命重新开花结果。

人生就是这样，只要种子还在，希望就在。

版本库生成后，hooks目录下就存在一些钩子脚本的模板，用户可以作为参考。把pre-revprop-change.tmpl复制为pre-revprop-change.bat，再修改里面的脚本，钩子就设置好了。

 

只允许用户修改自己的svn日志的钩子脚本：

实现每人可以修改自己的log日志，而管理员li可以任意修改。

结束篇。

经过本周一，周二的扫尾，周三上午日会时就对系统进行了演示。
本系统关键点没有搞定，也就是说本次sprint目标没有实现。本次演示时，发现仍有若干功能的遗漏。

整体投入度比估计值还低。功能遗漏是我监管不力，其实是故意不去管的，就是测试我的故事列表是否写得够清晰，能让大家都看明白。实事证明这里是需要改进的。故事要细化，要有自己的主题。不能因为相似而合并不相关的故事。

故事的分解这次也做得不好，本身团队习惯按层级编码，但一个故事分三层做的话，又太小，合在一起又太乱。下次还是明确细分一下，以免遗漏。

本次测试驱动没有很好执行，下次改进，先写测试代码。

好的方面是已经搞定cc.net，能自动完成代码获取，编译，单元测试。web的自动测试还没有实现。

进入sprint时，人员的投入度要尽量提高，减少其它项目或任务的干扰。外部的因素要尽量减少它的依赖性，以保证项目的正常进度。

总之，这是我们第一次scrum的经历。

周三：A正常，B正常，C进展有些慢，没能很好分清主次。

公司动荡，时常开会。投入度低。
E，F 加入进来，第一天基本是熟悉一下项目。
今天分配下去的任务也很少。关键点还是卡着。

周四：C完成接口编码，总算完成了。其它一般。E,F刚开始了解。
途中跑，比较平稳。燃进图上，曲线在上方，催促着我们。

周五：关键点上仍然没有测通。开始另一个关键点（上周二的设计）的编码。
随着任务的减少，空闲人员开始自发地结对。

到这次日会，燃尽图上走到11点的位置。还剩余5点。下周还有2天，5人，周三演示。

第二周

A继续Dal相关的编码;B归位，进行UI及与Dal的对接;C进入新方案的接口编码。
世事难料，先是公司重组，将有人事变动。后是C有要事，得请假。整体投入度又要降低。
好在还有兵马好动，E,F已经完成其它项目，计划再加2人进入这次sprint。

不足的地方：如果对照目标的话，由于核心功能出现技术困难，本次sprint的目标没有太多进度。现在忙的都是些外围的辅助功能。

奥运圣火照耀着我们。中国13金了。

突然想把奥运会比做项目，4年计划，运作，决战于16天。然后又是一个全新的4年。这比赛的16天好比sprint的演示，这是个交答卷的日子。

周三日会，A仍然没有完成任务，B完成了功能设计，C开发中遇到难题
B的功能设计在周二时进行了集体讨论，计1d的工作,C计0.5d。燃尽图上向下走了1.5d。
A答应今天完成任务，B由于周四周五请假，就找个能在一天内完成的任务，C继续进攻难点，并寻求帮助。

周四日会，A完成数据库设计，C难题未解
A计1d,B的任务完成度不好估计，等他回来再计算。燃尽图上向下走1d。
A开始新的任务，dal层的编码与测试，C的任务是个难题，只好自己D出马试试水。

这两次会议都在15分钟内完成，毕竟才问询三个人的任务。感觉都没做多少交流。时间就到了。

周五日会，A在写测试代码时，比较手生，进度落后，C难题无解，D试水也无解。
难题无解只能另寻解决方案。C着手另一种方案的设计，A继续写dal与测试。燃尽图上没有向下走。

才从书上看到CruiseControl.Net，这就是我要的。日常工作中常做这个事，从svn下载源码，开Visual Studio，编译，运行测试。这个工具可以自动完成这一系列工作。还能生成报表，监视svn的改动等。

MSBuild在这个位置：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe

MSTest在这个位置：D:\Program Files\Microsoft Visual Studio 8\Common7\IDE\mstest.exe（视安装路径）

这两个工具是.net自带的，在msdn里有详细说明。

SVN，现在是1.5了。

主要还是CruiseControl.Net的配置。

---

一、下载CruiseControl.Net，我用的是zip版，解压到安装目录。内有４个文件夹：

cctray：托盘程序，监视当前服务的运行结果
examples：一些示例的配置文件
server：服务程序

webdashboard：web版的监视程序，可查看服务的状态，及历史运行结果。

监视用的是remote，数据用xml+xsl展示。

---

二、配置ccnet.config

我配置后的结果：

行2 project:CCNet可以监视多个项目，每个项目配置一份project;

行4 sourcecontrol:源码控制，这里用svn。还有其它十多种可以选择。配置好svn源，工作区。用远程时还需要用户密码。

行8 tasks：本项目要运行的任务

行42 publishers:默认这样子先

行45 triggers：触发条件。当前是30秒运行一次。当buildCondition="ForceBuild"时，每次编译，它的默认值是IfModificationExists，表示有代码改动时编译。

---

三、重点是task内的配置

msbuild节：

executable：程序位置

workingDirectory：工作位置

projectFile：项目文件

logger：编译信息的记录员

targets：msbuild的动作

buildArgs：编译参数

exec节：

exec可以运行任何命令行的程序。

这里用它来做文件删除，运行mstest。

merge节：

把mstest运行后的结果xml文件，合并到本次运行的结果文件中。这样在webdashboard中就可以看到mstest的结果了。

周一日会，ABC三名开发人员中，C临时请假，缺席。
首先明确Sprint的目标，资源情况，日会时间，演示日期。（这些本该是上周计划会时定的）
在查资源情况时，发现ABC的投入度都比较低，从原来的0.5降到了0.3。开发周期从8天变成了13天。试行Scrum,先宽松些，感觉好点。
之后进行系统的简单设计，定义了下初步的架构方案。
在做任务分解时，会议被打断。留下AB自己进行任务分解，选择任务。A选择数据库设计，B选择UI原型。
 

周二日会，A忙其它，没有完成任务，B完成了UI的框架编码，C回来了

昨天用的记事贴，贴在玻璃上，好多掉下来了。最后还是在玻璃上先贴上白纸， 记事贴再贴到白纸上。明天看效果。

布置任务板占用了一些时间。由于实际情况，任务板贴在会议室里，有条件的话，应该贴在工作区内，大家都能实时看到的地方。

目前对backlog没有做详细的任务分解。做一点分解一点。A继续做初步的数据库设计，BC进入功能点的开发。B的功能比较复杂，需要进行UML的分析。

燃尽图上向下走了一个点。

 

 

在看了N遍之后，N>10。越觉得Scrum的可行性很好，就准备先拿一个小项目来试试。

 

首先这个DMM项目只有功能需求，无操作界面需求，提供的文字没超过两行。

之前的做法：做系统设计，数据库设计，UI设计。

Scrum的做法：编写产品backlog,做Sprint计划会。

编写产品backlog是我看这本书的一大亮点，一直以来就为这个如何演示所困扰。因为不清楚这回事，有需求来了就开工，完全不知道如何结束。做到满意为止，当然是个美好的愿望。但做为一个开发人员来说，一个功能反反复复得修改，工作得不到认同，会有失落感。backlog的如何演示解决了这个问题。一个业务需求，配上如何演示，就有了衡量开发是否完成的标准。

操练第一步：编写产品backlog

backlog看书上说得这么轻巧，就列了一下字段。真要写个如何演示出来，还是有难度，它有点象测试用例。不过在编写的时候，有个感觉很好，如何演示就象已经在做好的系统上操作一样，想象着去测试各个功能。自己在写的过程中，还是不自觉得开始罗列一些对象，属性。不知道有没有停留在业务层次上。然后我就列了12个backlog。照书上的方法打印成卡片。

操练第二步：Sprint计划会

虽说书看了N遍，一召集人马开会，就全忘光了。我把卡片往桌上一摊，先让大家看。然后讨论功能，对优先级做了些调整。之后就开始做估计值了。因为之前团队里玩过几次计划纸牌游戏，对这个熟啊。在估计过程中，对几个功能相近，用时偏小的backlog进行了合并。最后得出7个backlog，估计值16。

在做完这些之后，我居然宣布散会了。回来一整理，才发现什么sprint周期，目标，演示日期等提都没提。晕啊。好在我说了下周一来了做任务分解。

整理后，按3个开发人员计算，70%的投入度，得出8天的开发周期。考滤这个项目次要，大家手上还有其它重要的项目在做，这个投入度还得再降一降。下周日会再汇总一下意见，订个目标，演示日期出来。

 

参加了QClub：当SOA遭遇现实归来。地主已经把活动图片放出来了：QClub 杭州站成功在支付宝举行

支付宝首席架构师程立的分享很精彩。讲述了支付宝几年走过的架构历程。《程立谈架构、敏捷和SOA实践》

 

截止到2008年5月6日，使用支付宝的全球用户已经超过8000万，支付宝每日交易总额超过3.5亿人民币，日交易笔数超过150万笔。 对于这样一个系统，支付宝也是从简单三层的应用开始的。面对不断变化的业务，海量的数据，系统内产生了上千个类的情况，给开发维护都造成极大的困难。之后开始应用SOA,对系统进行封装，将功能做成服务，每个服务都可以应用集群进行支撑。

分布的业务，分布的数据，海量的访问。

对事务的处理，提到了两个概念：ACID(原子，一致，隔离，持久)和BASE(基本业务可用，柔性状态，最终一致)。

支付宝对BASE的实现有一个TCC模型（try-试执行,cancel-取消,confirm确认）。

在之后的讨论中，有幸程立和我们在一个小组。对分布式系统中的事务处理，及在SOA中的应用引起了大家的关注。ACID被称为刚性事务，BASE被称为柔性事务，这个叫法很快被认同，也很好理解。讨论很快集中到最终一致上。因为大系统应对大并发时，必然会采用柔性事务，以保证基本业务可用。之前自己做的一个系统里也遇到过这种问题，刚开始的时候采用刚性事务，在小数据量的时候好象没什么问题，当数据量大了之后，一次刚性事务就会占用系统极大的资源，对用户的响应和并发都造成影响。之后改用柔性事务的处理，把请求放到一个队列里执行，这样就避开了并发，只是用户操作的结果不是即时有效，有系统处理的延时，也就是最终一致。不过当时开发的时候不知道ACID,BASE的概念。

支付宝是7*24小时运行的系统，其中各种服务上百个。这样的系统开发，维护都是一个大问题。先说开发，编码之后的测试，光环境就需要上百台机器，这可不是每个开发人员都能得到了。然后是维护，系统需要更新，但服务不能停，怎么办。例如有50台机器需要更新组件，就先停25台进行更新，然后开启，再更新另25台。这就要求组件的向下兼容性要好，更新的过程要严谨。

随便提一下支付宝的开发模式，以产品线为组织形式，各产品线每周提交一个更新包进行系统改进。新加的项目周期控制在3个月以内。没有严格的模式定义，比较倾向于敏捷。目前开发人员在200左右。

整体来说，现在的支付宝架构良好，开发有序，前程一片光明啊。

反观自己，架构还在初级阶段，开发混沌，路漫漫兮其修远 吾将上下而求索。

google codejam 2008开始报名了。地址：http://code.google.com/codejam/

在网上搜了一下，发现相关资料很少。也没找到对应的讨论版块及网站。

朋友们有相关网点链接的话，欢迎回复一下。



后记：错过一步，就成了观望了。这个比赛是有严格时间控制的。必须按规定时间参加。不但要提前报名，还要在指定时间来做题。不过比赛题目不错，事后也可以做题，只是没有成绩。权当练习。

新建项目：选择windows服务，自动生成 Service1 : ServiceBase
在Service1的设计视图，右键菜单－添加安装程序，生成ProjectInstaller : Installer
ProjectInstaller里自动添加了
        private System.ServiceProcess.ServiceProcessInstaller serviceProcessInstaller1;
        private System.ServiceProcess.ServiceInstaller serviceInstaller1;

serviceInstaller1：
  Description  获取或设置服务的说明。
  DisplayName  指示向用户标识服务的友好名称。
 ServiceName  指示系统用于标识此服务的名称。此属性必须与要安装的服务的 ServiceBase.ServiceName 相同。
  StartType    指示启动此服务的方式和时间。 （手工，自动，禁用）

serviceProcessInstaller1：
Account: -运行的帐户 LocalSystem

安装：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\installutil your.exe
卸载：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\installutil /u your.exe

ps:没啥好写，记一点容易忘记的东西。添加安装程序这步就又找了好久。

asp.net里的Menu控件是个树型菜单控件。可以配置使用多种数据源。常与SiteMapDataSource配合使用，读取Web.sitemap里的数据。也可以自定义数据提供类。

在web.config里配置使用其它数据提供类：

    <siteMap defaultProvider="MyXmlSiteMapProvider">
      <providers>
        <add
          name="MyXmlSiteMapProvider"
      type="your Class"
          siteMapFile = "web.sitemap"//对应的map文件
          securityTrimmingEnabled="true" />//启用角色认证
      </providers>
    </siteMap>

MyXmlSiteMapProvider：XmlSiteMapProvider

public override bool IsAccessibleToUser(HttpContext context, SiteMapNode node)

重写IsAccessibleToUser，就可以使用自定义的权限配置功能，来实现动态菜单。

 

使用NHibernate进行项目应用一周。单表的增，删，改没有问题。

一对一：在NHibernate中有两种设置，第一种A表，B表使用相同的主键。第二种A表，B表中使用Aid做外键。现使用第二种的设置：

A表.hbm.xml:

<one-to-one name="TheB" class="classB" property-ref="TheA" outer-join="false" cascade="delete" />

B表.hbm.xml:

<many-to-one name="TheA" column="Aid" class="classA" unique="true" />

在读A时，TheB会随后读出。试了网上的几种延时加载的配置，没有实现。

读B时，TheA会延时加载。在使用TheA.id时，不会引发加载。

一对多：

A表

    <bag name="TheBs" table="B" lazy="true" inverse="true" cascade="all">

      <key column="AId"/>

      <one-to-many class="ClassB"/>

    </bag>

B表

    <many-to-one name="TheA" column="AId" class="ClassA" />

TheBs,TheA都可以延时加载。

第一次看到EXT，就被它的UI给震撼了。虽然它的身材有400K之巨。不过提供的js控件可是相当丰富。经过一个小项目的应用，就更切实得感受到它的魅力。能把js写成这个规模，这样规范，这么面向对象，提供重载，事件。把数据源与展示的分离。怎一个服字了得。

再一次感慨语言没有高下之分，重要的还是设计，应用。

陈伟锭：我们是非常希望员工能够做到最好，因此激励至关重要。在英特尔，有一些比较基本的激励方式。

首先，我们相信，给员工提供非常具有挑战性的职位，是一种很好的激励。给员工极具挑战性的工作，让他去尝试、去完成，使之感受到自己在公司的价值，员工会产生高度的成就感。

其次，及时认可员工的成就。认可的形式可以多种多样，有时是即时的、随机的。比如，一个团队成员做了一个非常成功的项目，这个团队的每一个人都可以及时地给他一种鼓励 、认可、表扬。当然，我们还有国家、地区或者全球层面的表彰。举个例子，我们中国公司有一个教育创新部门，该部门的工作是推动教育创新项目，而不是卖芯片，以便体现出英特尔作为一个企业有著长远的教育使命和战略。这个团队与公司其他部门很不相同，他们是从企业的高度进行工作，也非常需要激励。他们在前不久刚刚获得了我们亚太区和全球的表彰，中国教育部也给英特尔颁发了一项对中国教育的杰出贡献奖。在英特尔全球的内部网上也列出了该团队所取得的业绩，如我们的未来教育计划、培训教师的项目、为中学生举办的科学竞赛活动以及与大学的合作，等等。因此，这个团队的成员在我们公司变得越来越有名，与其他员工见面时都不需要做自我介绍 ，大家都知道他们。

第三，英特尔作为一家技术领先的公司，我们的员工认为给他们提供最好的技术、最好的工具，也是一种很好的激励方式。比如，我们的工程师可以利用最先进的技术、最先进的方法来创造、创新。

第四，我们的员工都能够非常及时地了解到公司各个层面业务的进展，这也是一种很好的激励。员工可以通过我们定期的季度业务汇报会，或者通过“一对一”的方式很方便地获取这些信息。“一对一”方式也是英特尔比较独特的沟通方式，是由员工向主管或者经理 要求一对一的交流，谈话的主题也由员工确定，它不是自上而下，而是自下而上的沟通方式。我本人每天至少收到四个“一对 一”沟通的请求，并基本都会满足这种要求，而我 40% 的工作时间都用在和员工的“一对一”交流上。

管理者的工作就是让手上的人按照自己的意志去完成交待的任务。
在我看来，管理的最高境界就是设定目标，分配任务，审核任务的完成情况。
要达到这种境界，就需要管理者如何使手上的人发挥自己的天赋，克服自己的毛病。
当达到这种理想情况时，管理者的目标可以实现，员工的价值得到了体现，同时还能够克服自身的缺点，提升自我，那么这时，工作会变成一种快乐，企业运作，内部士气，上下级关系都达到一种和谐的状态。

顺势而为，齐心协力。