TestDirector是全球最大的软件测试工具提供商Mercury Interactive公司生产的企业级测试管理工具，也是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。
电子商务正影响着许多公司制定计划和建立自己的IT系统。很快，一个Web应用软件就能被创建，开发并立即展现在您的客户、供应商或合作伙伴的面前。然而，由于紧凑的开发计划和复杂的系统基构，Web应用软件的测试经常是被忽视的。为了与新经济同步， 您必须开发经过系统测试的高品质的网络应用软件。
您需要设立一个中央点来管理测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库。由于测试人员分布在各地，您需要一个集中的测试管理系统能让测试人员不管在何时何地都能参与整个测试过程。IT部门增长地会非常快，人员也会不断流动。您必须以最快的速度培训新的测试人员，教会他们所有与测试有关的知识技术。重点在于管理复杂的开发和测试过程，改善部门间的沟通，加速您测试的成功。
TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开发人员或其它的IT人员通过一个中央数据仓库，在不同地方就能交互测试信息。TestDirector将测试过程流水化——从测试需求管理，到测试计划，测试日程安排，测试执行到出错后的错误跟踪——仅在一个基于浏览器的应用中便可完成，而不需要每个客户端都安装一套客户端程序。
程序的需求驱动整个测试过程。TestDirector 的Web 界面简化了这些需求管理过程，以此您可以验证应用软件的每一个特性或功能是否正常。通过提供一个比较直观的机制将需求和测试用例、测试结果和报告的错误联系起来，从而确保能达到最高的测试覆盖率。
一般有2 种方式可将需求和测试联系起来。其一，TestDirector 捕获并跟踪所有首次发生的的应用需求。您可以在这些需求基础上生成一份测试计划，并将测试计划对应与您的需求。例如，您或许有25 个测试计划可对应同一个应用需求。您一定能方便地管理需求和测试计划之间可能存在的一种多配多的关系，确保每一个需求都经过测试。其二，由于Web 应用是不断更新和变化的，需求管理允许测试人员加减或修改需求，并确定目前的应用需求已拥有了一定的测试覆盖率。它们帮助决定一个应用软件的哪些部分需要测试，哪些测试需要开发，是否完成的应用软件满足了用户的要求。对于任何动态地改变Web 应用，必须审阅您的测试计划是否准确，确保其符合最当前的应用要求。
测试计划的制定是测试过程中至关重要的环节。它为整个测试提供了一个结构框架。TestDirector的Test Plan Manager 在测试计划期尖，为测试小组提供一个关键要点和Web 界面来协调团队间的沟通。Test Plan Manager 指导测试人员如何将应用需求转化为具体的测试计划。这种直观的结构能帮助您定义如何测试您的应用软件，从而您能组织起明确的任务和责任。Test Plan Manager提供了多种方式来建立完整的测试计划。您可以从草图上建立一份计划，或根据您用Require-ments Manager所定义下的应用需求，通过Test Plan Wizard 快捷地生成一份测试计划。如果您已经将计划信息以文字处理文件形式，如Microsoft Word 方式储存，您可以再利用这些信息，并将它导入到Test Plan Manager。它把各种类型的测试汇总在一个可折叠式目录树内，您可以在一个目录下查询到所有的测试计划。例如，你可以将人工和自动测试，如功能性的，还原和负载测试方案结合在同一位置。
Test Plan Manager 还能进一步的帮助您完善测试设计和以文件形式描述每一个测试步骤，包括对每一项测试，用户反应的顺序，检查点和预期的结果TestDirector 还能为每一项测试连加附属文件，如Word ，Excel ，HTML ，用于更详尽的记录每次测试计划。
Web 网络应用日新月异，您的应用需求也随之不断改变。您需要相应地更新您的测试计划，优化测试内容。即使频繁的更新，TestDirector 仍能简单地将应用需求与相关的测试对应起来。TestDirector 还可支持不同的测试方式来适应您公司特殊的测试流程。
多数的测试项目需要一个有人工与自动测试的结合，包括健全，还原和系统测试。但即使符合自动测试要求的工具，在大部分情况下也需要人工的操作。启用一个演变性的而非革新性的自动化切换机制，能让测试人员决定哪些重复的人工测试可转变为自动脚本以提高测试速度。
TestDirector 还能简化将人工测试切换到自动测试脚本的转化，并可立即启动测试设计过程。
一、安装前需知
1. 安装前环境配置
TD的WEB服务容器为IIS，必须得先安装IIS环境
TD的后台数据库默认为Access以选择使用Sybase、 MS-SQL Server、 oracle。
TD也支持邮件服务，可以选择安装邮件服务或则暂时不安装。如果需要安装则在安装前做好邮件服务器的相关配置。
2. 安装事项
在安装时，要对系统进行一些安装设置，以下对一些关键设置进行简单解释。
1）数据库连接设置
设置数据库连接时，Access为默认必选，可以选择另外一种合适的数据库做为TD的连接数据库，该数据库可以在创建TD项目时，选择作为项目的数据库。
2）虚拟目录设置
其中的虚拟目录名TDBIN下将保存TD的一些运行文件。
3. 安装注意
安装TD时，系统资源消耗比较大，容易造成安装失败或错误，所以在安装时，尽量不要进行其他的系统操作，等待安装完成。
4. 安装后配置
1） 汉化
在安装目录TDBIN/Install/下存放的是一些为连接服务的客户端加载的系统文件。其中的tdclientui80.xco文件，该文件会自动加载到客户端的C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下，并生成为tdclientui80.ocx文件。
注意其中两个文件的后缀名区别。文件后缀可通过更改方式变换为OCX或XCO。
由于Mercury并未发行官方的汉化包，所以采用第三方的资源包进行汉化。汉化方式，把得到的汉化资源dclientui80.xco文件粘贴到服务器TDBIN/Install/目录下，覆盖掉原文件即可。
在之前访问过服务器的客户端，在下次连接时由于不再加载更新后的数据，所以必须得删除客户端下的C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下覆盖tdclientui80.ocx文件，使再次访问时自动加载汉化后的新组件。
也可以通过在客户端C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下覆盖tdclientui80.ocx文件达到汉化的目的。
2） 设置MS-SQL的数据库连接
对数据库的“客户端网络实用工具”进行配置。选择协议Named Pipes与TCP/IP，别名设置最好选择本机计算机名。
对数据库的安全性设置--身份验证，设置为SQL Server和WINDOWS。
设置后，在后台PING连接数据库，如果成功，则可正常创建该类数据库的项目。
3） IE7.0兼容性
安装TD后，并不能顺利支持IE7.0的客户端浏览器。此时可以用记事本等打开服务器TDBIN/目录下的start_a.htm源文件，然后进行编辑。
查找” var fMSIE3456”
然后在该行的末尾处分号前添加一段语句”|| (ua.lastIndexOf('MSIE 7.0') != -1)”
保存即可。
***********************************
1.这个代码不一定要粘在“|| (ua.lastIndexOf('MSIE 6.0') != -1) ”后面,因为是或的关系,你只是添加一个条件而已.因为放在哪里都无所谓,只要在条件语句中就可以了.
2.只需要在条件中加上一个条件(ua.lastIndexOf('MSIE 7.0') != -1) 而且是或的关系即"|| ",相信做测试的人对这个应该会懂的,仔细看一下其它条件语句就会明白的.
3.另外,如果只修改此文件的话site administrator还是打不开的.具体做法修改相同目录下SiteAdmin.htm文件,方法同start_a.htm
***********************************
4）TD系统信息修改
在C:\Program Files\Common Files\Mercury Interactive\目录中的DomsInfo文件夹，该文件夹中保存TD系统的关键信息，其中有TD系统配置信息的数据库doms.mdb文件，该数据库文件已默认被加密，密码为tdtdtd。在Templates文件夹中的文件为初始化生成的项目模板文件，包括TestDir.mdb，该文件为生成项目的初始数据库表。这样的话我们，就可以在每次创建项目时初试化出我们想要的，预定好的数据库表和相关数据来。就可以避免每次创建项目时重复的手工定义字段了，我们可以定制自己的项目数据库模板。
如当遗忘ADMIN的密码时，可以通过往doms.mdb的ADMIN表中的ADMIN_PSWD字段更换写入“456711”，登陆时输入密码“test”即可进入。
2009年5月14日星期四
2009年4月29日星期三
设计模式简述
程式设计是思维具体化的一种方式，是思考如何解决问题的过程，设计模式是在解 决问题的过程中，一些良好思路的经验集成，最早讲设计模式，人们总会提到 Gof 的著作，它最早将经典的 23 种模式集合在一起说明，对后期学习程式设计，尤其是对从事对象导向程式设计的人们起了莫大的影响。
后来设计模式一词被广泛的应用到各种经验集成，甚至还有反模式（AntiPattern），反模式教导您如何避开一些常犯且似是而非的程式设计思维。
这边的话将整理一些设计模式学习心得，实例的部份是使用Java，因而您会看到一些与 Gof 模式不同的图及实例方式，这是为了善用一些Java本身的特性，至于C++的实例方面，Gof 的书已经给了不少的例子。
在一些模式的实例上，您会发现我用了接口（interface）来取代抽象类别（Abstract class），这与原先的Gof书中的范例会不尽相同，这是因为在C++中没有接口，一个完全没有实例任何方法的抽象类别，根据当时描述的主题特性，可以 的话会将之换为接口，在语义上会较符合Java语言的特性，但是您要知道的是，接口与完全没有实例任何方法的抽象类别在某些时候是可以互换的。
在这边所看到的 UML 图都是使用 Jude 绘制的，Jude 是一个纯 Java 撰写的 UML 工具程式，可运行与 Windows、Linux 等多个平台，体积小，使用简易。
Gof 模式
以下的设计模式则是我个人从 Gof 学习中的个人体会与实例，并增加几个导入或衍生的简单模式。
Creational 模式
对象的产生需要消耗系统资源，所以如何有效率的产生、管理 与操作对象，一直都是值得讨论的课题， Creational 模式即与对象的建立相关，在这个分类下的模式给出了一些指导原则及设计的方向。
Simple Factory 模式
Abstract Factory 模式
Builder 模式
Factory Method 模式
Prototype 模式
Singleton 模式
Registry of Singleton 模式
Structural 模式
如何设计对象之间的静态结构，如何完成对象之间的继承、实 现与依赖关系，这关乎着系统设计出来是否健壮（robust）：像是易懂、易维护、易修改、耦合度低等等议题。Structural 模式正如其名，其分类下的模式给出了在不同场合下所适用的各种对象关系结构。
Default Adapter 模式
Adapter 模式 - Object Adapter
Adapter 模式 - Class Adapter
Bridge 模式
Composite 模式
Decorator 模式
Facade 模式
Flyweight 模式
Proxy 模式（一）
Proxy 模式（二）
Behavioral 模式
对象之间的合作行为构成了程式最终的行为，对象之间若有设 计良好的行为互动，不仅使得程式执行时更有效率，更可以让对象的职责更为清晰、整个程式的动态结构（像是对象调度）更有弹性。
Chain of Responsibility 模式
Command 模式
Interpreter 模式
Iterator 模式
Mediator 模式
Memento 模式
Observer 模式
State 模式
Strategy 模式
Template Method 模式
Visitor 模式
多线程模式
在很多应用中都会使用多线程，尤其是在Web应用中，多线程以 Gof 整理的模式为基础，考虑多线程环境中，如何组合这些基本模式来完成多线程安全要求。
Guarded Suspension 模式
Producer Consumer 模式
Worker Thread 模式
Thread-Per-Message 模式
Future 模式
Read-Write-Lock 模式
Two-phase Termination 模式
Thread-Specific Storage 模式
参考资料
以下是以Java实例设计模式的介绍网站，从下面的连结开始，当中您可以找到更多设计模式的资源。
Huston Design Pattern
The Design Patterns Java Companion
板 桥里人的 Java 设计模式学习心得
UML 软件工程组织
后来设计模式一词被广泛的应用到各种经验集成，甚至还有反模式（AntiPattern），反模式教导您如何避开一些常犯且似是而非的程式设计思维。
这边的话将整理一些设计模式学习心得，实例的部份是使用Java，因而您会看到一些与 Gof 模式不同的图及实例方式，这是为了善用一些Java本身的特性，至于C++的实例方面，Gof 的书已经给了不少的例子。
在一些模式的实例上，您会发现我用了接口（interface）来取代抽象类别（Abstract class），这与原先的Gof书中的范例会不尽相同，这是因为在C++中没有接口，一个完全没有实例任何方法的抽象类别，根据当时描述的主题特性，可以 的话会将之换为接口，在语义上会较符合Java语言的特性，但是您要知道的是，接口与完全没有实例任何方法的抽象类别在某些时候是可以互换的。
在这边所看到的 UML 图都是使用 Jude 绘制的，Jude 是一个纯 Java 撰写的 UML 工具程式，可运行与 Windows、Linux 等多个平台，体积小，使用简易。
Gof 模式
以下的设计模式则是我个人从 Gof 学习中的个人体会与实例，并增加几个导入或衍生的简单模式。
Creational 模式
对象的产生需要消耗系统资源，所以如何有效率的产生、管理 与操作对象，一直都是值得讨论的课题， Creational 模式即与对象的建立相关，在这个分类下的模式给出了一些指导原则及设计的方向。
Simple Factory 模式
Abstract Factory 模式
Builder 模式
Factory Method 模式
Prototype 模式
Singleton 模式
Registry of Singleton 模式
Structural 模式
如何设计对象之间的静态结构，如何完成对象之间的继承、实 现与依赖关系，这关乎着系统设计出来是否健壮（robust）：像是易懂、易维护、易修改、耦合度低等等议题。Structural 模式正如其名，其分类下的模式给出了在不同场合下所适用的各种对象关系结构。
Default Adapter 模式
Adapter 模式 - Object Adapter
Adapter 模式 - Class Adapter
Bridge 模式
Composite 模式
Decorator 模式
Facade 模式
Flyweight 模式
Proxy 模式（一）
Proxy 模式（二）
Behavioral 模式
对象之间的合作行为构成了程式最终的行为，对象之间若有设 计良好的行为互动，不仅使得程式执行时更有效率，更可以让对象的职责更为清晰、整个程式的动态结构（像是对象调度）更有弹性。
Chain of Responsibility 模式
Command 模式
Interpreter 模式
Iterator 模式
Mediator 模式
Memento 模式
Observer 模式
State 模式
Strategy 模式
Template Method 模式
Visitor 模式
多线程模式
在很多应用中都会使用多线程，尤其是在Web应用中，多线程以 Gof 整理的模式为基础，考虑多线程环境中，如何组合这些基本模式来完成多线程安全要求。
Guarded Suspension 模式
Producer Consumer 模式
Worker Thread 模式
Thread-Per-Message 模式
Future 模式
Read-Write-Lock 模式
Two-phase Termination 模式
Thread-Specific Storage 模式
参考资料
以下是以Java实例设计模式的介绍网站，从下面的连结开始，当中您可以找到更多设计模式的资源。
Huston Design Pattern
The Design Patterns Java Companion
板 桥里人的 Java 设计模式学习心得
UML 软件工程组织
测试驱动开发
测试驱动开发（Test-driven development）是现代计算机软件开发方法的一种。利用测试来驱动软件程序的设计和实现。测试驱动开始流行于20世纪90年代。测试驱动开发是极限编程中倡导的程序开发方法，方法主要是先写测试程序，然后再编码使其通过测试。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。
测试驱动开发的比喻。开发可以从两个方面去看待：实现的功能和质量。测试驱动开发更像两顶帽子思考法的开发方式，先戴上实现功能的帽子，在测试的辅助下，快速实现正确的功能；再戴上重构的帽子，在测试的保护下，通过去除冗余和重复的代码，提高代码重用性，实现对质量的改进。可见测试在测试驱动开发中确实属于核心地位，贯穿了开发的始终。
测试驱动开发中测试的特征
测试驱动开发中需求分析和详细设计的范畴，在代码基本完毕以后，这些测试也成为单元测试的一个部分。
应用领域
新软件的开发，历史系统的维护。
测试驱动开发相关讨论
正面评价
可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
可以让开发者在开发中拥有更全面的视角，避免过度实现带来的浪费。
负面评价
开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
会放慢开实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。
测试驱动开发的比喻。开发可以从两个方面去看待：实现的功能和质量。测试驱动开发更像两顶帽子思考法的开发方式，先戴上实现功能的帽子，在测试的辅助下，快速实现正确的功能；再戴上重构的帽子，在测试的保护下，通过去除冗余和重复的代码，提高代码重用性，实现对质量的改进。可见测试在测试驱动开发中确实属于核心地位，贯穿了开发的始终。
测试驱动开发中测试的特征
测试驱动开发中需求分析和详细设计的范畴，在代码基本完毕以后，这些测试也成为单元测试的一个部分。
应用领域
新软件的开发，历史系统的维护。
测试驱动开发相关讨论
正面评价
可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
可以让开发者在开发中拥有更全面的视角，避免过度实现带来的浪费。
负面评价
开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
会放慢开实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。
XP的价值标准
最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
1、沟通
2、简单
3、回馈
4、勇气
5、尊重（最新添加的价值）
沟通
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
简单
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。
反馈
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。
来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。
反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”
勇气
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
尊重
尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。
1、沟通
2、简单
3、回馈
4、勇气
5、尊重（最新添加的价值）
沟通
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。
极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
简单
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。
反馈
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。
来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。
反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”
勇气
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。
尊重
尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。
XP 核心的实践
极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。
1、小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。
2、规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。
3、现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。
4、隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。
5、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。
6、重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。
7、测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。
8、持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。
9、结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。
10、代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。
11、编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。
12、每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。
在第二版的Extreme programming explained中，在主要实践之外，还列出了一系列延伸的实践。
核心实践源自被广泛接受的最佳实践，并且被推向极至：
开发人员和客户之间的交互是有益的。因此，一个极限编程的小组从理论上要求需要一个软件使用者在身边，这个使用者制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）.
如果学习是好的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。
简单的代码更可能工作。所以极限编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。
如果简单的代码是好的，那么把变得复杂的代码改写成简单的。
代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。
测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先变好的自动化测试方式来保证它的确有作用。参看 测试驱动的开发。
一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为统一软件程序更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。
1、小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。
2、规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。
3、现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。
4、隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。
5、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。
6、重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。
7、测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。
8、持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。
9、结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。
10、代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。
11、编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。
12、每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。
在第二版的Extreme programming explained中，在主要实践之外，还列出了一系列延伸的实践。
核心实践源自被广泛接受的最佳实践，并且被推向极至：
开发人员和客户之间的交互是有益的。因此，一个极限编程的小组从理论上要求需要一个软件使用者在身边，这个使用者制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）.
如果学习是好的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。
简单的代码更可能工作。所以极限编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。
如果简单的代码是好的，那么把变得复杂的代码改写成简单的。
代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。
测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先变好的自动化测试方式来保证它的确有作用。参看 测试驱动的开发。
一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为统一软件程序更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。
2009年4月28日星期二
RUP：Rational Unified Process，统一过程
Rational统一过程(RUP)是Rational软件公司（现在Rational公司被IBM并购）创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。
在软件工程领域，与RUP齐名的软件方法还有：
净室软件工程（重量级）
极限编程（extreme programming）和其他敏捷软件开发（agile methodology）方法学（轻量级）
产品生命周期中的指导方针和模版
RUP为项目成员定义了在一个产品生命周期中如下指导方针和模版。
迭代式开发
给定的时间内，开发一个大型的复杂的软件系统，定义问题并构建解决方案是不可能一蹴而就的。在项目的开发过程中，由于体系结构方面的约束，客户的需要或对原始问题更精确的理解，需求会经常地变更。迭代式开发允许通过后续的细化产生对项目更好的理解，并在每个迭代的阶段，把项目的最高风险的事项作为最高优先级的任务集中精力解决。理想的，每一次迭代都以一个可执行的发布为结束，这样可以减少一个项目风险，更多地允许客户的交互并帮助开发人员集中精力。
管理需求
对于任何大型项目来说，一个文档框架是必不可少的；因此RUP描述了如何描述功能性，约束，设计决定和业务需求。
用例和场景是过程规定的制品的例子，在贯穿系统整个开发和部署的过程中，用例和场景在捕捉功能需求和提供一致的线索上是非常有效的。
使用基于构件的体系架构
基于构件的体系架构（CBA）创造了容易扩展的系统，并提升了软件的重用性和可读性。一个构件经常与面向对象程序设计中的一个对象有关。
RUP提供了构建这种系统的一个系统化的方法，关注于在把所有资源投入到一个项目之前，开发出一个早期的可执行的体系架构。
这些构件通过一些基础平台，如CORBA和COM组装在一起。
软件的可视化建模
将你的程序设计从代码上抽象出来，并用图形化构件块展现出来是得到解决方案的全面意象的一种有效方法。这对于项目的技术人员来说，一方面，能够更容易地勾画出如何最好的实现一个给定逻辑集合的轮廓，另一方面，能够更容易地构造在业务过程和实现业务过程的实际代码之间的中间物。
统一建模语言（UML）是表示项目的产业标准方法，因此经常被RUP使用。
验证软件质量
质量评估是所有软件项目中最经常的失败所在，因为通常这样项目的仅仅在项目总结中进行质量评估和甚至由另外的团队来进行质量评估。 RUP在规划质量控制和评估方面有所帮助，并把质量控制和评估包括在每个项目成员都参与的整个过程中。
控制软件的变更
在所有的软件项目中，变更是不可避免的，RUP定义了控制和监控变更的方法。一个表面上很小的变更可能以完全不可预计的方式对应用程序产生影响，这一点对一个成功项目至关重要。RUP同时定义了安全的操作环境，保证一个程序员对另一个系统的修改将不会对他系统地修改。这一点与基于构件的体系架构有很大的关系。
迄今为止，这些指导方针是通用的，可以在一个项目的生命周期中遵守。为了把握一个项目的时间尺度，RUP把一个项目分为四个不同的阶段：
构思阶段
细化阶段
构建阶段
移交阶段
在软件工程领域，与RUP齐名的软件方法还有：
净室软件工程（重量级）
极限编程（extreme programming）和其他敏捷软件开发（agile methodology）方法学（轻量级）
产品生命周期中的指导方针和模版
RUP为项目成员定义了在一个产品生命周期中如下指导方针和模版。
迭代式开发
给定的时间内，开发一个大型的复杂的软件系统，定义问题并构建解决方案是不可能一蹴而就的。在项目的开发过程中，由于体系结构方面的约束，客户的需要或对原始问题更精确的理解，需求会经常地变更。迭代式开发允许通过后续的细化产生对项目更好的理解，并在每个迭代的阶段，把项目的最高风险的事项作为最高优先级的任务集中精力解决。理想的，每一次迭代都以一个可执行的发布为结束，这样可以减少一个项目风险，更多地允许客户的交互并帮助开发人员集中精力。
管理需求
对于任何大型项目来说，一个文档框架是必不可少的；因此RUP描述了如何描述功能性，约束，设计决定和业务需求。
用例和场景是过程规定的制品的例子，在贯穿系统整个开发和部署的过程中，用例和场景在捕捉功能需求和提供一致的线索上是非常有效的。
使用基于构件的体系架构
基于构件的体系架构（CBA）创造了容易扩展的系统，并提升了软件的重用性和可读性。一个构件经常与面向对象程序设计中的一个对象有关。
RUP提供了构建这种系统的一个系统化的方法，关注于在把所有资源投入到一个项目之前，开发出一个早期的可执行的体系架构。
这些构件通过一些基础平台，如CORBA和COM组装在一起。
软件的可视化建模
将你的程序设计从代码上抽象出来，并用图形化构件块展现出来是得到解决方案的全面意象的一种有效方法。这对于项目的技术人员来说，一方面，能够更容易地勾画出如何最好的实现一个给定逻辑集合的轮廓，另一方面，能够更容易地构造在业务过程和实现业务过程的实际代码之间的中间物。
统一建模语言（UML）是表示项目的产业标准方法，因此经常被RUP使用。
验证软件质量
质量评估是所有软件项目中最经常的失败所在，因为通常这样项目的仅仅在项目总结中进行质量评估和甚至由另外的团队来进行质量评估。 RUP在规划质量控制和评估方面有所帮助，并把质量控制和评估包括在每个项目成员都参与的整个过程中。
控制软件的变更
在所有的软件项目中，变更是不可避免的，RUP定义了控制和监控变更的方法。一个表面上很小的变更可能以完全不可预计的方式对应用程序产生影响，这一点对一个成功项目至关重要。RUP同时定义了安全的操作环境，保证一个程序员对另一个系统的修改将不会对他系统地修改。这一点与基于构件的体系架构有很大的关系。
迄今为止，这些指导方针是通用的，可以在一个项目的生命周期中遵守。为了把握一个项目的时间尺度，RUP把一个项目分为四个不同的阶段：
构思阶段
细化阶段
构建阶段
移交阶段
2009年4月9日星期四
java关于23种设计模式的有趣见解(转)
创建型模式
1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory
工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）
原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。
结构型模式
6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)
适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。
享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。
12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。
行为模式
13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接
起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”，:-(
命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。
15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。
解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。
Mary：“想要我跟你结婚，得答应我的条件”
我：“什么条件我都答应，你说吧”
Mary：“我看上了那个一克拉的钻石”
我：“我买，我买，还有吗？”
Mary：“我看上了湖边的那栋别墅”
我：“我买，我买，还有吗？”
Mary：“你的小弟弟必须要有50cm长”
我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”
……
迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。
调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。
18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。
备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。
19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。
状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。
21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。
策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；
模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。
23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；
访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory
工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）
原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。
结构型模式
6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)
适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。
享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。
12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。
行为模式
13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接
起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”，:-(
命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。
15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。
解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。
Mary：“想要我跟你结婚，得答应我的条件”
我：“什么条件我都答应，你说吧”
Mary：“我看上了那个一克拉的钻石”
我：“我买，我买，还有吗？”
Mary：“我看上了湖边的那栋别墅”
我：“我买，我买，还有吗？”
Mary：“你的小弟弟必须要有50cm长”
我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”
……
迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。
调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。
18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。
备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。
19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。
状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。
21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。
策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；
模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。
23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；
访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
2009年4月7日星期二
MS Project 2007快速课程要点
课程简介：
主要讲解Microsoft Project 2007专业版和服务器版软件的实践应用，是一门融合项目管理知识和项目管理实际应用的实战课程，结合项目管理知识，工程及研发项目的特点和典型项目案例，讲述如何实现项目计划编制与进度管理、项目资源分配与管理、成本管理、项目动态跟踪、分角色协作、项目的沟通和协调管理，项目状态报告、项目文档管理、项目风险管理等功能，实现团队及企业的项目管理。
课程大纲：
1、项目管理的相关知识
项目的特点 项目管理九大知识领域 项目的生命周期
项目管理的特点
工程及研发项目运作的几种模式介绍和特点
Project软件中蕴含的项目管理技术介绍
2、Project 2007 功能
Microsoft Project 2007 的界面及工作环境
Microsoft Project 2007产品分类、协作及主要功能
实现基于project2007 的企业综合项目管理的解决方案EPM
3、项目计划的创建与制定
项目日历、任务日历、资源日历、日历共享、
工作结构分解WBS的实现和规则
周期性任务、从Excel导入任务,
设置任务工期、计划评审技术（PERT）、弹性工期
建立任务关联性、任务层次划分
里程碑计划的实现、识别关键路径、压缩工期的策略和方法
4、项目资源分配
资源库的分类和建立、从outlook中导入资源信息
资源的分配策略资源工作表 资源使用状况 共享资源库
资源使用效率及分配冲突分析及解决办法
5、项目成本管理
项目成本划分 资源成本管理体系与任务成本管理体系
成本信息计算、成本公式自定义 现金流量
资金计划的分配、分类统计费用明细
6、项目的跟踪与控制 变更管理
设置项目比较基准任务执行 进度跟踪
项目的动态跟踪 采集任务完成的实际数据 成本跟踪
项目控制机制 项目执行状况分析
项目计划调整 项目风险分析
盈余分析、BCWS、BCWP、ACWP等指标
项目S曲线的绘制与分析
7、通过视图和报表管理项目
甘特图、网络图、跟踪图、日历图、任务及资源的分配状况图人工时统计 项目总工时和费用支出时间曲线
视图自定义 筛选器和分组技术的应用 制作项目报表技巧PROJECT2007全新的可视化图表
8、多项目管理
项目文件合并，主/子项目管理；
多项目工作环境保存 项目之间关联设置 项目间共享资源
项目群管理，多项目信息汇总、分析，项目状态报告管理
9、思考练习与上机练习
Project2003/2007的环境设置
结合WBS分解使用Project2007编制项目计划及优化工期
如何利用project 跟踪控制项目进度、盈余值分析
实例作战、建立企业项目资源库
思考及训练将以具体项目为例从头到尾将项目管理知识贯穿到Project2007的使用当中。
10、企业项目管理平台EPM(第三天)
*EPM企业项目管理平台的实施与部署
重点从企业项目管理层视角来实现研发企业项目管理标准化，管理多项目，企业资源在多项目团队的管理和工作评估，基于团队的项目信息分享和工作配合，基于项目的文档、风险、问题、成果管理等
*企业项目建立与管理
创建企业项目、设置项目基本信息
设置工作时间、企业日历、保存项目、设置基于项目、任务和资源的图表视图
签入/签出项目、删除和备份、还原企业项目
*企业资源综合管理
企业资源库、签出和删除企业资源
配置资源的组织分解结构RBS
确立资源的角色、定义资源的技能和角色
按部门管理人员及工作状况、解决多项目环境下资源过度分配问题
*基于Project Server 2007项目跟踪管理
项目的草稿与发布、项目基准计划发布
检查项目进度、查找和分析进度差异、项目变更
项目完成进度跟踪、每日工作量跟进
*项目成员工作与任务跟进和管理
接受项目任务工作安排
反馈任务进度、问题和文档
填报细分的每日工作时间及事物完成状况
临时性工作管理、请假和培训管理
*企业多项目管理
按部门、按区域管理项目、按项目的类别和级别进行管理
*项目协作和沟通
使用Outlook查看和报告任务
委派任务/拒绝任务/添加新任务/任务更新
每周项目状态报告、配置项目协作环境
*风险管理与问题、交付成果管理
风险评估、风险危害估计、风险应对计划
提交、查看和编辑风险、将项目的风险、问题、文档与任务相关联
提交问题、查看和编辑问题
可交付成果清单、将可交付结果与项目任务紧密结合
*文档管理
添加项目文档、文档库的分类和权限管理
查看和编辑文档、项目文档版本管理、文档的审批
*项目绩效管理
分析企业多个和单个项目的成本、评估企业单个和多个项目的工作量
评估分析企业项目成员的工作量、通过挣值分析评估研发人员绩效
*Project2007&Server用户及安全管理功能
管理用户和组、配置组员和权限
管理安全和视图权限性
企业自定义域
主要讲解Microsoft Project 2007专业版和服务器版软件的实践应用，是一门融合项目管理知识和项目管理实际应用的实战课程，结合项目管理知识，工程及研发项目的特点和典型项目案例，讲述如何实现项目计划编制与进度管理、项目资源分配与管理、成本管理、项目动态跟踪、分角色协作、项目的沟通和协调管理，项目状态报告、项目文档管理、项目风险管理等功能，实现团队及企业的项目管理。
课程大纲：
1、项目管理的相关知识
项目的特点 项目管理九大知识领域 项目的生命周期
项目管理的特点
工程及研发项目运作的几种模式介绍和特点
Project软件中蕴含的项目管理技术介绍
2、Project 2007 功能
Microsoft Project 2007 的界面及工作环境
Microsoft Project 2007产品分类、协作及主要功能
实现基于project2007 的企业综合项目管理的解决方案EPM
3、项目计划的创建与制定
项目日历、任务日历、资源日历、日历共享、
工作结构分解WBS的实现和规则
周期性任务、从Excel导入任务,
设置任务工期、计划评审技术（PERT）、弹性工期
建立任务关联性、任务层次划分
里程碑计划的实现、识别关键路径、压缩工期的策略和方法
4、项目资源分配
资源库的分类和建立、从outlook中导入资源信息
资源的分配策略资源工作表 资源使用状况 共享资源库
资源使用效率及分配冲突分析及解决办法
5、项目成本管理
项目成本划分 资源成本管理体系与任务成本管理体系
成本信息计算、成本公式自定义 现金流量
资金计划的分配、分类统计费用明细
6、项目的跟踪与控制 变更管理
设置项目比较基准任务执行 进度跟踪
项目的动态跟踪 采集任务完成的实际数据 成本跟踪
项目控制机制 项目执行状况分析
项目计划调整 项目风险分析
盈余分析、BCWS、BCWP、ACWP等指标
项目S曲线的绘制与分析
7、通过视图和报表管理项目
甘特图、网络图、跟踪图、日历图、任务及资源的分配状况图人工时统计 项目总工时和费用支出时间曲线
视图自定义 筛选器和分组技术的应用 制作项目报表技巧PROJECT2007全新的可视化图表
8、多项目管理
项目文件合并，主/子项目管理；
多项目工作环境保存 项目之间关联设置 项目间共享资源
项目群管理，多项目信息汇总、分析，项目状态报告管理
9、思考练习与上机练习
Project2003/2007的环境设置
结合WBS分解使用Project2007编制项目计划及优化工期
如何利用project 跟踪控制项目进度、盈余值分析
实例作战、建立企业项目资源库
思考及训练将以具体项目为例从头到尾将项目管理知识贯穿到Project2007的使用当中。
10、企业项目管理平台EPM(第三天)
*EPM企业项目管理平台的实施与部署
重点从企业项目管理层视角来实现研发企业项目管理标准化，管理多项目，企业资源在多项目团队的管理和工作评估，基于团队的项目信息分享和工作配合，基于项目的文档、风险、问题、成果管理等
*企业项目建立与管理
创建企业项目、设置项目基本信息
设置工作时间、企业日历、保存项目、设置基于项目、任务和资源的图表视图
签入/签出项目、删除和备份、还原企业项目
*企业资源综合管理
企业资源库、签出和删除企业资源
配置资源的组织分解结构RBS
确立资源的角色、定义资源的技能和角色
按部门管理人员及工作状况、解决多项目环境下资源过度分配问题
*基于Project Server 2007项目跟踪管理
项目的草稿与发布、项目基准计划发布
检查项目进度、查找和分析进度差异、项目变更
项目完成进度跟踪、每日工作量跟进
*项目成员工作与任务跟进和管理
接受项目任务工作安排
反馈任务进度、问题和文档
填报细分的每日工作时间及事物完成状况
临时性工作管理、请假和培训管理
*企业多项目管理
按部门、按区域管理项目、按项目的类别和级别进行管理
*项目协作和沟通
使用Outlook查看和报告任务
委派任务/拒绝任务/添加新任务/任务更新
每周项目状态报告、配置项目协作环境
*风险管理与问题、交付成果管理
风险评估、风险危害估计、风险应对计划
提交、查看和编辑风险、将项目的风险、问题、文档与任务相关联
提交问题、查看和编辑问题
可交付成果清单、将可交付结果与项目任务紧密结合
*文档管理
添加项目文档、文档库的分类和权限管理
查看和编辑文档、项目文档版本管理、文档的审批
*项目绩效管理
分析企业多个和单个项目的成本、评估企业单个和多个项目的工作量
评估分析企业项目成员的工作量、通过挣值分析评估研发人员绩效
*Project2007&Server用户及安全管理功能
管理用户和组、配置组员和权限
管理安全和视图权限性
企业自定义域
使用AJAX
var request;
function createRequest() {
try {
request = new XMLHttpRequest();
} catch (trymicrosoft) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (othermicrosoft) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error initializing XMLHttpRequest!");
}
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/\n/g, "<br />");
} else if (request.status == 404) {
alert ("Requested URL is not found.");
} else if (request.status == 403) {
alert("Access denied.");
} else
alert("status is " + request.status);
}
}
function getSalesData() {
// Create a request object
createRequest();
alert("Ready state is: " + request.readyState);
// Setup (initialize) the request
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var xmlDoc = request.responseXML;
var showElements = xmlDoc.getElementsByTagName("show");
for (var x=0; x<showElements.length; x++) {
// We know that the first child of show is title, and the second is rating
var title = showElements[x].childNodes[0].value;
var rating = showElements[x].childNodes[1].value;
// Now do whatever you want with the show title and ratings
}
}
}
}
function createRequest() {
try {
request = new XMLHttpRequest();
} catch (trymicrosoft) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (othermicrosoft) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error initializing XMLHttpRequest!");
}
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/\n/g, "<br />");
} else if (request.status == 404) {
alert ("Requested URL is not found.");
} else if (request.status == 403) {
alert("Access denied.");
} else
alert("status is " + request.status);
}
}
function getSalesData() {
// Create a request object
createRequest();
alert("Ready state is: " + request.readyState);
// Setup (initialize) the request
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var xmlDoc = request.responseXML;
var showElements = xmlDoc.getElementsByTagName("show");
for (var x=0; x<showElements.length; x++) {
// We know that the first child of show is title, and the second is rating
var title = showElements[x].childNodes[0].value;
var rating = showElements[x].childNodes[1].value;
// Now do whatever you want with the show title and ratings
}
}
}
}
2009年3月31日星期二
PM实战心得（转）
本人做项目经理工作多年，感到做这个工作最要紧的就是要明白，什么叫因地制宜、因势利导，就是说只有最合适的，没有什么叫对的，什么叫错的，项目经理的工作就是利用有限的资源把事情做到客户期望的水平，企业的根本目的就是赚钱，不是研究机构，所以，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。
以下是本人一些做项目经理的个人体会，写出来供大家指点，在讨论过程中共同提高水平。由于本人的经历主要是做和软件开发相关项目的管理工作，所以，这些经验可能不适合用在工程项目管理领域。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为"办公自动化"的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统。你前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。
2. 这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的。
就像二战时候的英国首相邱吉尔，他是个典型的反苏反共分子，但是在苏联进行几大保卫战的时候，他冒着德国潜艇的炮火，忍受路途运输损失一半的代价，把大量的坦克、飞机、军用卡车送到了苏联军队的手中，因为他那时候最主要的任务就是打击纳粹德国。所以，在项目的最初阶段，根据各个方面的情况，经过平衡后得出一个项目大致目标并获得其他人的认可，这个是一个成功项目的第一步。
3. 基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。一般说来，领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；
4. 在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间。所以，项目经理不仅要和客户有很好的沟通，熟悉自己公司内部的各种办事流程，知道如何和人事、财务部门打交道，也是一个很重要的方面；
5. 现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，做出对策，那么就只能去当烈士了。
7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧；
8. 现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。
下面的东西看起来无聊，其实还是很管用的：
第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。
第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记"好记性不如烂笔头"的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正认可了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。
首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果可以用例如甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。
好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：
“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”
王局长：“……(*&$@@”
和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。
和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己整理结果，写文档，做决定。会议上大家的面子都被照顾了，自然实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。
另外，你还可以采用一些专业的方法论来解决这种讨论问题，比如著名的六顶思考帽。你可以按照不同的帽子颜色来组织大家思考，如在白色帽子里讨论客观的事实；在黄色帽子里讨论做这个事情的好处；在绿色帽子里发挥创新，看看这个事情能做成什么样子，发挥想象力；在蓝色帽子里讨论做事情的逻辑、步骤；在黑色帽子里讨论未来的风险和预防措施；在红色的帽子里谈谈大家对这个事情的主观感受。这样会议才不会失控，观点也被罗列得很清楚。
在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，拿到钱，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比如销售、行业顾问等，其出路反而比开发人员的路要宽得多。
接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。
所以，对于这种需求天天变的客户，你就一定要事先做好规矩：
一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；
二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：
给客户做培训前，多注意一些表面功夫。很多程序员认为，既然很多系统采用原型法，有一个由粗到精的过程，那么系统的逻辑核心是否正确才是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题；而且培训的时候也是空手上台、信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西，否则，仅仅因为一些无关紧要的报错就让客户第一印象觉得系统不稳定，那你就真的比窦娥还冤了。如果工作再做得详细一点，可以做一些类似Flash的东西，把一些你要强调的重点用通俗易懂、轻松愉快的方式表达出来。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备、培训时所举的例子是否有代表性都是很关键的因素，第一炮打不响，以后就麻烦很多。
上面讲的是培训的时候，丑媳妇要化妆好再去见公婆的问题。其实，项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。根据我的分析，一般项目中的客户都可以分为三类：支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形：支持的和抵触的人少，观望的人多（如果你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。很简单，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是因为新系统而消失？传统的利益格局因为新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才能团结那些支持你的人，消减那些抵触你的人。项目经理是一个很奇怪的角色，属于典型的责任大、权力小的角色，他能做的只有借力打力，不管在自己公司还是在客户那里，一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你，哪些人会因为什么而抵触你，你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统，其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就可以散布一些"谁抵制新系统就说明自己屁股上有屎"这类的论调去压制他们，减弱他们的影响。总之，团结积极分子，打压敌对分子，带动大多数是你的基本策略。
还有一个体会和大家分享：千万不要觉得对方的领导（中层干部）是应该配合你工作的，特别是一些国营单位，多一事不如少一事，他干吗要帮你？我的经验是：对方领导如果没有拿你的事情作为内部斗争的武器而从中作梗（当然，他针对的不一定是你），那已经是算合作的了，记住，他不捣乱就是帮你忙了。
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。一般说来，项目经理在考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，把项目控制在一个合适的范围内，让客户从理想回到现实也是项目经理的分内工作。
验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，一个公司做事情必定有流程，所以搞清楚流程十分关键。比如验收、付款这些你极其关心的事情，客户那边的流程是怎么样的，谁牵头组织、哪些人参加，要什么文件、走什么程序、哪些人签字、最后出什么文档等等，都要搞清楚，特别要事先分析和打听哪个环节容易卡壳，做好事先的准备。
我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了个Windows还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。
最后，我想谈谈如何评价项目经理的绩效的问题，我认为，项目经理有以下几个档次：
*最差的项目经理：项目过程中总是出现意外，然后自己又解决不了，结果成为烈士；
*二流的项目经理：项目也经常出现意外，但是他一马当先，奋勇向前，解决了一个又一个问题，最后，勉强算把项目结束了，获得了领导的一致好评；
*一流的项目经理：平时很少见他做具体的事情，整天找人聊天，然后就是写报告、做计划，最后项目顺利结束，整个过程平淡无奇；
项目管理到底是一门科学还是一门艺术呢？所谓科学就是经过反复论证，输入和输出有必然规律的东西，种瓜得瓜；而艺术就是思想火花的闪耀，主要靠灵感。项目管理这个东西，据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感染能力等东西。看明白了PMBOK，学会了一些做事情的方式，只是搞懂了那个20%的科学的东西，还有80%的空间，属于见仁见智的领域了。所以，加强很多方面的个人能力，如练就出色沟通能力、提升自己的个人魅力对于项目经理来说是多么重要啊，无论是对内还是对外。作为一个一流的专业人士，在顺利让客户签字的同时，如何让自己的领导知道你的价值，这也是体现自己能力的一种途径。
以下是本人一些做项目经理的个人体会，写出来供大家指点，在讨论过程中共同提高水平。由于本人的经历主要是做和软件开发相关项目的管理工作，所以，这些经验可能不适合用在工程项目管理领域。
项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候，首先要尽可能地多从各个方面了解项目的情况，如：
1. 这个项目是什么项目，具体大概做什么事情，是谁提出来的，目的是解决什么问题。在国内很多客户都很不成熟的情况下，千万不要根据项目的名称望文生义地去想象项目的目标。一个名为"办公自动化"的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统。你前期了解情况的工作越详细，后面的惊讶就越少，项目的风险就越小。
2. 这个项目里牵涉哪些方面的人，如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等，很多项目里除了业主单位的结构很复杂以外，还有一些其他单位也会牵涉进来，如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望，可以让你在做项目碰到问题的时候，就每件事情分析哪些人会在什么方面支持你，哪些人会出于什么目的反对你，从而提前准备联合朋友去对抗敌人，让事情向你所希望的方向发展。没有永远的朋友，也没有永远的敌人，只有一致的利益，这句话作为项目经理是一定要记住的。
就像二战时候的英国首相邱吉尔，他是个典型的反苏反共分子，但是在苏联进行几大保卫战的时候，他冒着德国潜艇的炮火，忍受路途运输损失一半的代价，把大量的坦克、飞机、军用卡车送到了苏联军队的手中，因为他那时候最主要的任务就是打击纳粹德国。所以，在项目的最初阶段，根据各个方面的情况，经过平衡后得出一个项目大致目标并获得其他人的认可，这个是一个成功项目的第一步。
3. 基本了解了客户的情况后，下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视，这个决定了你在需要资源的时候，公司是否会根据你的要求提供最有力的支持。一般说来，领导口头肯定是说支持的，你需要做的是了解公司对这个项目的实际期望，是想把项目越做越大还是想赚钱？是想做样板工程还是干脆想敷衍了事，公司领导对项目的态度决定了你做这个项目的战略，而这个战略方针将对你做项目计划产生直接的影响；
4. 在做整体项目计划前，还要大致计算一下你手上的资源。首先是时间，现在市场竞争激烈，往往很多项目要求在几乎不可能的时间范围里完成。对于这一点，你在做项目的风险控制计划的时候要充分考虑。其次是人员，根据项目预算和已往经验，大致计算一下未来的项目小组有多少种角色，每个角色目前公司是否有人，是否能完全归这个项目使用，是否需要另外招聘一些人员，招聘的准备工作要尽早启动。最后就是一些设备的准备，项目所需大件关键设备要尽早预定，以后不管发生设备等人还是人等设备的情况，浪费的都是你的时间。所以，项目经理不仅要和客户有很好的沟通，熟悉自己公司内部的各种办事流程，知道如何和人事、财务部门打交道，也是一个很重要的方面；
5. 现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚（主要是讲做什么，而不是说怎么做），而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情，也让客户的业务人员（一般不懂技术）知道项目做成什么样就算完成了。简单地说，项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。
6. 是到做总体计划的时间了吗？不，你现在已经知道了客户的目标和你手上的资源，那么做计划以前，你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的，你需要写一份报告，详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话，将发生什么样的后果。如果资源不够，就要高层改变策略，增加对这个项目的投入。甚至在条件许可的情况下，有些公司会放弃这个项目。总之，没有人能完成一个不可能完成的任务，如果项目经理不能尽早发现风险，做出对策，那么就只能去当烈士了。
7. 明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略，现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语，结果搞得客户一头雾水，反过来，他还指责客户不懂技术。其实，明白自己想做什么的客户已经是很好的客户了，不知道自己要做什么，更不懂怎么做还要指手画脚的客户到处存在，但是要明白，是客户选择了你，而不是你选择了客户，有了客户你才有工资拿，心平气和一点吧；
8. 现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要，那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则，如果你在一个部门时间做长了，对这些规则的运用觉得是一件理所应当的事情，但是，你现在面对的是多个部门甚至多个单位，不把沟通规则说清楚，你以后就会吃亏。
下面的东西看起来无聊，其实还是很管用的：
第一个是规定信息的流动方式和介质，是推还是拉。推的意思就是项目经理将主动发布信息，不管通过电话、邮件还是书面方式，保证将信息传达到每个人。这种情况适合小项目，人少；拉的意思就是项目经理就是一个类似web服务器，你自己需要什么信息就去问他。当然，没有项目经理把自己搞得那么累，他会用发布信息到公共介质的方式公布信息，简单的是白板，复杂一点的是项目的公共信息交互区，潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊，其实里面牵涉信息传达不完全的责任问题。当然，这些都是指一般的方式，而且不要绝对化，一般情况下，主动沟通和被动访问是同时存在的，尤其是对领导，项目经理更加应该主动去和领导沟通。
第二个问题就是文档问题，很多人怕写文档，但是项目经理一定要牢记"好记性不如烂笔头"的道理。有理有时候为什么会说不清呢？就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的，比如项目经理的项目日志，每个星期至少让客户签字，另外所有达成共识的东西，比如会议纪要，甚至领导的讲话记录，都要写成文档，双方签字，这样以后扯皮的时候，就能做到有据可查。记住：说了的就和没说一样，只有写下来大家签字后才算真正认可了的。还有一些问题，比如你提交的报告，给领导（包括本方领导和客户领导）做一个选择题，结果领导压住不批，让你无所适从，结果拖延了进度。这时候，你可以等，但是注意要留记录，标明是谁的责任；另外，如果你在开始阶段就和领导商定：如果批示提交三天后没有得到领导答复就算对方同意，这样你就会主动很多。再比如不同事件的审批流程问题：什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到，以后的工作就越主动。
好了，做了很多前期工作，定义了一些游戏规则，现在是坐下来做计划的时候了。这一节，任意找一本项目管理的书都会说得比我好，所以我就少写一点，说一些自己的体会就是了。
首先是找几个关键组员，比如客户业务专家、系统分析员等等，做一下项目模块划分工作。项目分成几块去做，每一块完成什么，模块之间的信息如何交换等等。需求定义的是做什么的问题，而这里说的是怎么做的问题。这里要强调一点：完成一个目标有很多种方式，你要选一种你最熟悉的，而不是看上去最完美的，这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动，坚持要你采用那种新技术，你就应该告诉他：你选我做这个项目，就应该容许我采用自己最喜欢的方式做事情，新技术之所以有诱惑力，就是因为吃亏的人还不多，我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确，比如用微软的Project软件，你填写完表格以后，就可以知道这个项目有多少件事情要做，每件事情需要什么资源，他们之间的前后关系如何，消耗的时间有多长，完成后有什么标志等。所有的结果可以用例如甘特图的形式表现出来。你做完这个表以后会惊奇地发现，甘特图上项目的结束时间会远远落后于你的计划结束时间（签合同的人永远不会先征求你的意见的）。当然，学过项目管理的人会大谈什么WBS、优化路径之类的东西，但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题，在我恭喜你挑了一个轻松活之前，请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候，你就要考虑牺牲一些任务的时间（也意味着质量）了。按照什么标准牺牲？这个项目的战略！我们在第三节提到过的战略。我的经验是如果你什么都赶进度，其结果可能就是十件事情你一件也没做好，想想多么失败啊。所以，把资源投到你熟悉和有把握的事情上，最后的结果是十件事情，你有三件做成了精品，三件完成，还有四件因为某些原因延误，成绩单是否靓丽了很多呢？战略决定优先级，而正确排列事情的优先级是一个项目经理能力的主要体现。
好，现在项目已经完成了前期工作，了解了项目的目标、搞清楚了手上的资源，制定了项目的策略，然后编制了项目的整体计划，项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的时候，不像前期的时候项目经理要象记者一样到处和不同的人接触，搞清楚他们在说什么，努力猜测他们在想什么和他们的真正目的，那才是最累人的事情。当然，小项目的项目经理往往自己也是一个资源，要做很多事情，这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：
“王局长，最近项目进度还算正常，就是JVM经常发生一些内存泄漏的情况…”
王局长：“……(*&$@@”
和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。
和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强（如果总结得不对，欢迎大家拍砖），所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，现象是完全不同的，想想盲人摸象的故事吧。这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的。你的长处是掌握事情的优先级，评估各个方面的轻重缓急，从而根据他们的意见得出一个合适的（而不是正确的）方案。所以，在会议上，你要充分尊重每一个人和他的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论（你要让大家知道事情不是非黑即白的，而是多元的，唉，我们的教育惹的祸…）。会后，你自己整理结果，写文档，做决定。会议上大家的面子都被照顾了，自然实施起来的阻力就小，如果还有意见的，你就私下找他聊，如果还不能说服他，你就要让他明白，因为你负责这个项目、你担当风险，所以，这个优先级应该你来判断。组织中的高层，并不见得水平会比一般的成员高，但是，他要承担组织的风险，加之信息的不对称性，所以，对事情的优先级的判断肯定比下属强。
另外，你还可以采用一些专业的方法论来解决这种讨论问题，比如著名的六顶思考帽。你可以按照不同的帽子颜色来组织大家思考，如在白色帽子里讨论客观的事实；在黄色帽子里讨论做这个事情的好处；在绿色帽子里发挥创新，看看这个事情能做成什么样子，发挥想象力；在蓝色帽子里讨论做事情的逻辑、步骤；在黑色帽子里讨论未来的风险和预防措施；在红色的帽子里谈谈大家对这个事情的主观感受。这样会议才不会失控，观点也被罗列得很清楚。
在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，拿到钱，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。另外我插一句：我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流，很容易引起冲突和矛盾（技术人员的本性决定的）。我的做法是项目经理和项目实施人员到现场，软件开发人员还是在公司做项目。项目实施人员就是初级项目经理，他们了解自己的产品，懂得一些客户的业务，关键是在于他们具有良好的沟通能力，俗称“皮厚”。他们是客户和研发人员的桥梁，其职业方向也是很机动灵活，以后可以有很多方向可以转，比如销售、行业顾问等，其出路反而比开发人员的路要宽得多。
接着，我们再谈谈最让人头痛的需求变更问题。变更通常分为两种：一种是部分更改了原先的目标，即需求变更；另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类。碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么注意下面几点：
1. 确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
2. 和客户坐下来，自己探讨他修改的根本目的是什么，是不是有同样能达到相同目的，但是对你来说有代价更小的选择？
3. （项目初期的工作）明确更改流程，一般是客户指定一人签字（否则客户每个领导都有权力来插一杠子，你就废了），以正式项目文件的方式提交给你，然后，你做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果（这个东西先写出来，后面如果真的发生了，至少不是你的错）。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。
所以，对于这种需求天天变的客户，你就一定要事先做好规矩：
一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中；
二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
*有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的；
*便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目的；
*对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了；
系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：
给客户做培训前，多注意一些表面功夫。很多程序员认为，既然很多系统采用原型法，有一个由粗到精的过程，那么系统的逻辑核心是否正确才是关键，至于界面如何，界面上的用词是否准确，那是无关紧要的问题；而且培训的时候也是空手上台、信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。我的体会是，给客户做培训的版本，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求，那么，你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等，总之不要让客户看到一些他不该看到的东西，否则，仅仅因为一些无关紧要的报错就让客户第一印象觉得系统不稳定，那你就真的比窦娥还冤了。如果工作再做得详细一点，可以做一些类似Flash的东西，把一些你要强调的重点用通俗易懂、轻松愉快的方式表达出来。文档方面，准备至少两个文档：用户手册和培训手册。这两个文档的内容很多都是一致的，但是角度完全不同。用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备、培训时所举的例子是否有代表性都是很关键的因素，第一炮打不响，以后就麻烦很多。
上面讲的是培训的时候，丑媳妇要化妆好再去见公婆的问题。其实，项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说，客户是懒的，这就是他花钱找你做事情的原因。一个项目的成败，和客户的配合程度很有关系。根据我的分析，一般项目中的客户都可以分为三类：支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形：支持的和抵触的人少，观望的人多（如果你接了一个人人都抵触你的项目，那你还是不要做了）。首先，分析一下那些人为什么支持你和抵触你。很简单，于公于私两个方面分析，上了新系统，谁的工作量有所变化？谁的潜在利益是否受到威胁？谁的岗位是不是因为新系统而消失？传统的利益格局因为新系统的使用而发生怎么样的变化，这些东西，都是项目经理必须去了解的，这样，你才能团结那些支持你的人，消减那些抵触你的人。项目经理是一个很奇怪的角色，属于典型的责任大、权力小的角色，他能做的只有借力打力，不管在自己公司还是在客户那里，一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你，哪些人会因为什么而抵触你，你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统，其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了，这样，有些人肯定就要捣乱，到处诋毁这个系统。这时候，你就可以散布一些"谁抵制新系统就说明自己屁股上有屎"这类的论调去压制他们，减弱他们的影响。总之，团结积极分子，打压敌对分子，带动大多数是你的基本策略。
还有一个体会和大家分享：千万不要觉得对方的领导（中层干部）是应该配合你工作的，特别是一些国营单位，多一事不如少一事，他干吗要帮你？我的经验是：对方领导如果没有拿你的事情作为内部斗争的武器而从中作梗（当然，他针对的不一定是你），那已经是算合作的了，记住，他不捣乱就是帮你忙了。
作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。一般说来，项目经理在考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，把项目控制在一个合适的范围内，让客户从理想回到现实也是项目经理的分内工作。
验收前，除了做好文档工作，即可交付成果以外，多花时间搞清楚客户的做事情流程是很重要的事情，一个公司做事情必定有流程，所以搞清楚流程十分关键。比如验收、付款这些你极其关心的事情，客户那边的流程是怎么样的，谁牵头组织、哪些人参加，要什么文件、走什么程序、哪些人签字、最后出什么文档等等，都要搞清楚，特别要事先分析和打听哪个环节容易卡壳，做好事先的准备。
我对验收最大的体会就是举证问题。即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做了个Windows还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。另外，认为系统完美了才能验收的想法也是错误的，软件开发合同里一定要注明验收以后维护期的费用问题，否则，客户担心一旦验收就得不到你们的支持，自然不配合验收，那么，你这个项目经理就很难交功课了。
最后，我想谈谈如何评价项目经理的绩效的问题，我认为，项目经理有以下几个档次：
*最差的项目经理：项目过程中总是出现意外，然后自己又解决不了，结果成为烈士；
*二流的项目经理：项目也经常出现意外，但是他一马当先，奋勇向前，解决了一个又一个问题，最后，勉强算把项目结束了，获得了领导的一致好评；
*一流的项目经理：平时很少见他做具体的事情，整天找人聊天，然后就是写报告、做计划，最后项目顺利结束，整个过程平淡无奇；
项目管理到底是一门科学还是一门艺术呢？所谓科学就是经过反复论证，输入和输出有必然规律的东西，种瓜得瓜；而艺术就是思想火花的闪耀，主要靠灵感。项目管理这个东西，据一个前辈说，在国外是科学，80%是有规律可循的；在国内是艺术，主要靠个人魅力、感染能力等东西。看明白了PMBOK，学会了一些做事情的方式，只是搞懂了那个20%的科学的东西，还有80%的空间，属于见仁见智的领域了。所以，加强很多方面的个人能力，如练就出色沟通能力、提升自己的个人魅力对于项目经理来说是多么重要啊，无论是对内还是对外。作为一个一流的专业人士，在顺利让客户签字的同时，如何让自己的领导知道你的价值，这也是体现自己能力的一种途径。
2009年3月17日星期二
开源脑图软件Freemind
脑图(mind-mapping)，不是脑电图，是一种整理、组织和记录想法、观点以及信息的方式。一个脑图软件可以帮助你或者你的团队完成一次头脑风暴、规划一个新的项目、跟踪一个项目的发展、整理为一篇论文而搜集来的资料等等很多用处。
脑图(mind mapping)是一种整理思路，启发创造性和寻求解决方案的实用技能。通过脑图，你可以很快将凌乱的信息结构化，以一种易写易读的方式组织起来，帮助你理解问题本身。
脑图可以用于完成下列工作：
总结归纳信息
汇总来自不同资源的信息
辅助思考复杂问题
展示问题的主要框架
脑图因为非常形象，还很适合于辅助记忆。
下面是一个脑图的简单例子：
将一个问题化解成一个脑图，可以按照下面的步骤：
在中间写下问题的标题。
将主题分解成若干子问题，作为主题的分支。
如果子问题还可以化解，或者某些信息属于子问题，还可以继续产生下一级分支。
对于相关的事实或者产生的想法，都可以标注在相关节点周围，层层发展下去。
每出现新的情况、信息或者想法，很容易将它们添加到脑图合适的位置。一个完整的脑图就是以主题为中心放射性发展的结构。子主题或者相关信息都是一个个的分支。
一旦你开始熟悉脑图的实用方法，就可以自己总结一些技巧和使用习惯。这里有一些建议：
尽量使用简洁的文字来描述信息。
字迹清晰。如果用脑图软件应该没有这个问题。
使用不同的颜色区分不同的想法。
善用符号和图标。
对于不同部分有关联的内容可以使用交叉连接。
脑图是一种非常有效的记录整理工具，不仅可以展示事实，还可以表现它们之间的关系，甚至发现你本来没有发现的联系。
Freemind是一个基于java的开放源码脑图软件，支持Windows、Linux和Mac多种操作系统，曾被评为sourceforge 2006年二月当月软件。如果你也经常感到思维发散，头绪繁多，可以试试脑图软件。
http://freemind.sourceforge.net/wiki/index.php/Main_Page
2009年3月11日星期三
test.java, customer.java
// test.java
import org.hibernate.*;
import org.hibernate.cfg.*;
public class Test {
public static void main(String[] args) {
try {
SessionFactory sf =
new Configuration().configure().buildSessionFactory();
Session session = sf.openSession();
Transaction tx = session.beginTransaction();
for (int i = 0; i < 200; i++) {
Customer customer = new Customer();
customer.setUsername("customer" + i);
customer.setPassword("customer");
session.save(customer);
}
tx.commit();
session.close();
} catch (HibernateException e) {
e.printStackTrace();
}
}
}
// customer.java
public class Customer {
private int id;
private String username;
private String password;
public int getId() {
return id;
}
public String getPassword() {
return password;
}
public String getUsername() {
return username;
}
public void setId(int id) {
this.id = id;
}
public void setPassword(String password) {
this.password = password;
}
public void setUsername(String username) {
this.username = username;
}
}
import org.hibernate.*;
import org.hibernate.cfg.*;
public class Test {
public static void main(String[] args) {
try {
SessionFactory sf =
new Configuration().configure().buildSessionFactory();
Session session = sf.openSession();
Transaction tx = session.beginTransaction();
for (int i = 0; i < 200; i++) {
Customer customer = new Customer();
customer.setUsername("customer" + i);
customer.setPassword("customer");
session.save(customer);
}
tx.commit();
session.close();
} catch (HibernateException e) {
e.printStackTrace();
}
}
}
// customer.java
public class Customer {
private int id;
private String username;
private String password;
public int getId() {
return id;
}
public String getPassword() {
return password;
}
public String getUsername() {
return username;
}
public void setId(int id) {
this.id = id;
}
public void setPassword(String password) {
this.password = password;
}
public void setUsername(String username) {
this.username = username;
}
}
Customer.hbm.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping
PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="Customer" table="CUSTOMER">
<id name="id" column="CID" type="java.lang.Integer">
<generator class="increment" />
</id>
<property name="username" column="USERNAME" type="java.lang.String"/>
<property name="password" column="PASSWORD" type="java.lang.String"/>
</class>
</hibernate-mapping>
<!DOCTYPE hibernate-mapping
PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="Customer" table="CUSTOMER">
<id name="id" column="CID" type="java.lang.Integer">
<generator class="increment" />
</id>
<property name="username" column="USERNAME" type="java.lang.String"/>
<property name="password" column="PASSWORD" type="java.lang.String"/>
</class>
</hibernate-mapping>
hibernate.cfg.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory name="java:/hibernate/HibernateFactory">
<property name="show_sql">true</property>
<property name="connection.driver_class">
com.mysql.jdbc.Driver
</property>
<property name="connection.url">
jdbc:mysql://127.0.0.1:3306/javatest
</property>
<property name="connection.username">
javatestor
</property>
<property name="connection.password">
secret
</property>
<property name="dialect">
org.hibernate.dialect.MySQLDialect
</property>
<mapping resource="Customer.hbm.xml" /> <!-- 指定Customer的映射文件 -->
</session-factory>
</hibernate-configuration>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory name="java:/hibernate/HibernateFactory">
<property name="show_sql">true</property>
<property name="connection.driver_class">
com.mysql.jdbc.Driver
</property>
<property name="connection.url">
jdbc:mysql://127.0.0.1:3306/javatest
</property>
<property name="connection.username">
javatestor
</property>
<property name="connection.password">
secret
</property>
<property name="dialect">
org.hibernate.dialect.MySQLDialect
</property>
<mapping resource="Customer.hbm.xml" /> <!-- 指定Customer的映射文件 -->
</session-factory>
</hibernate-configuration>
apache build.xml for a hibernate demo
<?xml version="1.0" encoding="utf-8"?>
<project name="build.xml" default="build">
<!-- path -->
<property name="src.java.dir" location="src"/>
<property name="build.classes.dir" location="classes"/>
<property name="hibernate.lib.dir" location="C:/java/hibernate-distribution-3.3.1.GA"/>
<property name="mysql.lib.dir" location="C:/java/mysql-connector-java-3.1.14"/>
<!-- classpath -->
<path id="project.classpath">
<pathelement location="${build.classes.dir}"/>
</path>
<path id="library.path">
<fileset dir="${hibernate.lib.dir}/lib">
<include name="**/required/*.jar"/>
</fileset>
<fileset dir="${hibernate.lib.dir}">
<include name="hibernate3.jar"/>
</fileset>
<fileset dir="${mysql.lib.dir}">
<include name="mysql-connector-java-3.1.14-bin.jar"/>
</fileset>
</path>
<!-- action -->
<target name="init">
<mkdir dir="${build.classes.dir}"/>
</target>
<target name="build" depends="init">
<javac srcdir="${src.java.dir}" destdir="${build.classes.dir}">
<classpath refid="project.classpath"/>
<classpath refid="library.path" />
</javac>
<copy todir="${build.classes.dir}" >
<fileset dir="${src.java.dir}" >
<exclude name="**/*.java"/>
</fileset>
</copy>
</target>
<target name="run" depends="build">
<java classname="Test" fork="true">
<classpath refid="project.classpath"/>
<classpath refid="library.path" />
</java>
<echo>If you see this,it works!!!</echo>
</target>
<target name="clean">
<delete dir="${build.classes.dir}"/>
</target>
</project>
<project name="build.xml" default="build">
<!-- path -->
<property name="src.java.dir" location="src"/>
<property name="build.classes.dir" location="classes"/>
<property name="hibernate.lib.dir" location="C:/java/hibernate-distribution-3.3.1.GA"/>
<property name="mysql.lib.dir" location="C:/java/mysql-connector-java-3.1.14"/>
<!-- classpath -->
<path id="project.classpath">
<pathelement location="${build.classes.dir}"/>
</path>
<path id="library.path">
<fileset dir="${hibernate.lib.dir}/lib">
<include name="**/required/*.jar"/>
</fileset>
<fileset dir="${hibernate.lib.dir}">
<include name="hibernate3.jar"/>
</fileset>
<fileset dir="${mysql.lib.dir}">
<include name="mysql-connector-java-3.1.14-bin.jar"/>
</fileset>
</path>
<!-- action -->
<target name="init">
<mkdir dir="${build.classes.dir}"/>
</target>
<target name="build" depends="init">
<javac srcdir="${src.java.dir}" destdir="${build.classes.dir}">
<classpath refid="project.classpath"/>
<classpath refid="library.path" />
</javac>
<copy todir="${build.classes.dir}" >
<fileset dir="${src.java.dir}" >
<exclude name="**/*.java"/>
</fileset>
</copy>
</target>
<target name="run" depends="build">
<java classname="Test" fork="true">
<classpath refid="project.classpath"/>
<classpath refid="library.path" />
</java>
<echo>If you see this,it works!!!</echo>
</target>
<target name="clean">
<delete dir="${build.classes.dir}"/>
</target>
</project>
2009年3月5日星期四
epoll为我们带来了什么
Q：网络服务器的瓶颈在哪？
A：IO效率。
在大家苦苦的为在线人数的增长而导致的系统资源吃紧上的问题正在发愁的时候，Linux 2.6内核中提供的System Epoll为我们提供了一套完美的解决方案。传统的select以及poll的效率会因为在线人数的线形递增而导致呈二次乃至三次方的下降，这些直接导致了网络服务器可以支持的人数有了个比较明显的限制。
自从Linux提供了/dev/epoll的设备以及后来2.6内核中对/dev/epoll设备的访问的封装（System Epoll）之后，这种现象得到了大大的缓解，如果说几个月前，大家还对epoll不熟悉，那么现在来说的话，epoll的应用已经得到了大范围的普及。
那么究竟如何来使用epoll呢？其实非常简单。
通过在包含一个头文件#include 以及几个简单的API将可以大大的提高你的网络服务器的支持人数。
首先通过create_epoll(int maxfds)来创建一个epoll的句柄，其中maxfds为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有操作将通过这个句柄来进行操作。在用完之后，记得用close()来关闭这个创建出来的epoll句柄。
之后在你的网络主循环里面，每一帧的调用epoll_wait(int epfd, epoll_event events, int max events, int timeout)来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd为用epoll_create创建之后的句柄，events是一个epoll_event*的指针，当epoll_wait这个函数操作成功之后，epoll_events里面将储存所有的读写事件。max_events是当前需要监听的所有socket句柄数。最后一个timeout是epoll_wait的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。
epoll_wait范围之后应该是一个循环，遍利所有的事件：
for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) { //如果是主socket的事件的话，则表示有新连接进入了，进行新连接的处理。
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client); // 将新连接置于非阻塞模式
ev.events = EPOLLIN | EPOLLET; // 并且将新连接也加入EPOLL的监听队列。
注意，这里的参数EPOLLIN | EPOLLET并没有设置对写socket的监听，如果有写操作的话，这个时候epoll是不会返回事件的，如果要对写操作也监听的话，应该是EPOLLIN | EPOLLOUT | EPOLLET
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
// 设置好event之后，将这个新的event通过epoll_ctl加入到epoll的监听队列里面，这里用EPOLL_CTL_ADD来加一个新的epoll事件，通过EPOLL_CTL_DEL来减少一个epoll事件，通过EPOLL_CTL_MOD来改变一个事件的监听方式。
fprintf(stderr, "epoll set insertion error: fd=%d0,
client);
return -1;
}
}
else // 如果不是主socket的事件的话，则代表是一个用户socket的事件，则来处理这个用户socket的事情，比如说read(fd,xxx)之类的，或者一些其他的处理。
do_use_fd(events[n].data.fd);
}
对，epoll的操作就这么简单，总共不过4个API：epoll_create, epoll_ctl, epoll_wait和close。
A：IO效率。
在大家苦苦的为在线人数的增长而导致的系统资源吃紧上的问题正在发愁的时候，Linux 2.6内核中提供的System Epoll为我们提供了一套完美的解决方案。传统的select以及poll的效率会因为在线人数的线形递增而导致呈二次乃至三次方的下降，这些直接导致了网络服务器可以支持的人数有了个比较明显的限制。
自从Linux提供了/dev/epoll的设备以及后来2.6内核中对/dev/epoll设备的访问的封装（System Epoll）之后，这种现象得到了大大的缓解，如果说几个月前，大家还对epoll不熟悉，那么现在来说的话，epoll的应用已经得到了大范围的普及。
那么究竟如何来使用epoll呢？其实非常简单。
通过在包含一个头文件#include 以及几个简单的API将可以大大的提高你的网络服务器的支持人数。
首先通过create_epoll(int maxfds)来创建一个epoll的句柄，其中maxfds为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有操作将通过这个句柄来进行操作。在用完之后，记得用close()来关闭这个创建出来的epoll句柄。
之后在你的网络主循环里面，每一帧的调用epoll_wait(int epfd, epoll_event events, int max events, int timeout)来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为：
nfds = epoll_wait(kdpfd, events, maxevents, -1);
其中kdpfd为用epoll_create创建之后的句柄，events是一个epoll_event*的指针，当epoll_wait这个函数操作成功之后，epoll_events里面将储存所有的读写事件。max_events是当前需要监听的所有socket句柄数。最后一个timeout是epoll_wait的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。
epoll_wait范围之后应该是一个循环，遍利所有的事件：
for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) { //如果是主socket的事件的话，则表示有新连接进入了，进行新连接的处理。
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client); // 将新连接置于非阻塞模式
ev.events = EPOLLIN | EPOLLET; // 并且将新连接也加入EPOLL的监听队列。
注意，这里的参数EPOLLIN | EPOLLET并没有设置对写socket的监听，如果有写操作的话，这个时候epoll是不会返回事件的，如果要对写操作也监听的话，应该是EPOLLIN | EPOLLOUT | EPOLLET
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
// 设置好event之后，将这个新的event通过epoll_ctl加入到epoll的监听队列里面，这里用EPOLL_CTL_ADD来加一个新的epoll事件，通过EPOLL_CTL_DEL来减少一个epoll事件，通过EPOLL_CTL_MOD来改变一个事件的监听方式。
fprintf(stderr, "epoll set insertion error: fd=%d0,
client);
return -1;
}
}
else // 如果不是主socket的事件的话，则代表是一个用户socket的事件，则来处理这个用户socket的事情，比如说read(fd,xxx)之类的，或者一些其他的处理。
do_use_fd(events[n].data.fd);
}
对，epoll的操作就这么简单，总共不过4个API：epoll_create, epoll_ctl, epoll_wait和close。
2009年2月19日星期四
VGA2USB
VGA捕捉卡，可以把PC输出到VGA显示器的信号作为视频源输入进PC，从而可以用于视频会议文档共享等特定的目的。目前VGA捕捉卡的价格普遍都比较昂贵，网上查来的报价大概都在7000-9000RMB左右，这未免太过昂贵了。
这是一款可以VGA视频捕捉的设备，接口是USB2.0的，价格是$299.95，折合2000RMB，相比下来便宜了不少，而且接口方面是USB的，不占用插槽空间。
Technical Specifications
Interface USB 2.0
Dimensions 3.54" x 2.36" x 0.91"
90 x 60 x 23 mm
Connectors One VGA D type connector, one USB mini B type connector
Maximum Sample Rate 230 Mpixels per second
Color Resolution 16 bits per pixel / 5:6:5 format
Supported Video Modes
640x350 at 60, 85Hz
640x400 at 60, 85Hz
720x400 at 70, 85Hz
640x480 at 60, 70, 72, 75, 85Hz
800x600 at 56, 60, 70, 72, 75, 85Hz
1024x768 at 60, 70, 72, 75, 85Hz
1152x864 at 60, 70, 75, 85Hz
1152x900 at 66, 76Hz
1280x960 at 60, 85Hz
1280x1024 at 60, 70, 75, 85Hz
1600x1200 at 60, 65, 70, 75, 85Hz
1920x1200 at 60, 70, 72, 75, 85Hz
2048x1536 at 60, 70, 72, 75, 85Hz
Update Rate While results are typically around 10 updates per second, here are actual results under varying conditions:
Resolution Win XP FPS 1
640 x 480 28.0
800 x 600 20.6
1024 x 768 10.0
1280 x 1024 5.6
1600 x 1200 4.3
1920 x 1200 3.1
2048 x 1536 2.0
这家公司还有很多相关的其他产品：
http://www.epiphan.com/
这是一款可以VGA视频捕捉的设备，接口是USB2.0的，价格是$299.95，折合2000RMB，相比下来便宜了不少，而且接口方面是USB的，不占用插槽空间。
Technical Specifications
Interface USB 2.0
Dimensions 3.54" x 2.36" x 0.91"
90 x 60 x 23 mm
Connectors One VGA D type connector, one USB mini B type connector
Maximum Sample Rate 230 Mpixels per second
Color Resolution 16 bits per pixel / 5:6:5 format
Supported Video Modes
640x350 at 60, 85Hz
640x400 at 60, 85Hz
720x400 at 70, 85Hz
640x480 at 60, 70, 72, 75, 85Hz
800x600 at 56, 60, 70, 72, 75, 85Hz
1024x768 at 60, 70, 72, 75, 85Hz
1152x864 at 60, 70, 75, 85Hz
1152x900 at 66, 76Hz
1280x960 at 60, 85Hz
1280x1024 at 60, 70, 75, 85Hz
1600x1200 at 60, 65, 70, 75, 85Hz
1920x1200 at 60, 70, 72, 75, 85Hz
2048x1536 at 60, 70, 72, 75, 85Hz
Update Rate While results are typically around 10 updates per second, here are actual results under varying conditions:
Resolution Win XP FPS 1
640 x 480 28.0
800 x 600 20.6
1024 x 768 10.0
1280 x 1024 5.6
1600 x 1200 4.3
1920 x 1200 3.1
2048 x 1536 2.0
这家公司还有很多相关的其他产品：
http://www.epiphan.com/
2009年2月17日星期二
Windows Mobile开发环境搭建指南
内容简介
本文描述了如何搭建典型的Windows Mobile开发环境。介绍了相应的IDE、SDK及辅助开发工具的安装及常用配置，并对Windows Mobile下一代开发环境的发展前景做出展望。本文适合初次接触Windows Mobile开发的开发人员。
Windows Mobile开发简介
Windows Mobile是微软公司操作系统产品线上重要的一环。与Windows 9x/NT/XP/2003相比，Windows Mobile作为完整产品线出现在公众面前的时间非常短，但它的发展却异常迅速，而在这一发展过程中，开发人员提供了绝对关键的推动力。现在，越来越多的开发人员（特别是.NET开发人员）希望能尽快进入Windows Mobile的开发领域，而他们所面临的首要问题，除了熟悉Windows Mobile平台特性之外，便是如何搭建适合的开发环境。因此，本文就将从如何搭建一个Windows Mobile开发环境入手，对Windows Mobile平台的开发特性进行概要描述，以期帮助开发人员迅速进入Windows Mobile开发领域。
在展开本文的内容之前需要说明的一点是，Windows Mobile平台开发主要包含以下两方面内容：
l 平台级开发
l 应用级开发
因为Windows Mobile平台构建于微软的Windows CE系列操作系统之上（当前正式商用版本为Windows CE .NET 4.21），而Windows CE操作系统具有非常良好的模块化特性，因此开发人员，特别是手机设备厂商，可以通过微软提供的Platform Builder及eMbedded Visual C++（以下简称为eVC）非常方便地定制自己所需的操作系统。这对应的是上面所说的平台级开发。
然而，绝大多数的开发人员并不需要去构建一个全新的、个性化的系统，他们只需要关心如何构建能够运行在Windows Mobile设备上的应用程序。为此，微软按主要智能设备自身硬件设备特性的不同以及用户体验的差异，定制出了Windows CE .NET 4.x系列操作系统的两个主要分支，分别安装在不同的Windows Mobile硬件设备中，从而也就构成了我们通常所说的Pocket PC和Smartphone。以下内容中的Windows Mobile开发，除特指之外，均表示Pocket PC/Smartphone开发。
本文中提供的大量开发工具，除单独标出的以外，均可在http://msdn.microsoft.com/mobility/downloads/default.aspx下载。
迅速搭建开发环境
为了进行Windows Mobile开发，我们需要搭建相应的开发环境。所幸的是，这一环境搭建起来非常简单。
安装Visual Studio .NET 2003
为了降低Windows Mobile的开发难度，提高开发人员的开发效率，微软把.NET Framework移植到了Windows Mobile设备上，针对Windows Mobile设备及Windows CE .NET操作系统设计了.NET Compact Framework（以下简称.NET CF）。而Visual Studio .NET 2003正是开发.NET CF应用程序的最佳IDE。在Visual Studio .NET 2003的安装中默认集成了.NET CF 1.0，同时提供了Pocket PC 2002的开发模板，可以直接用来开发Pocket PC 2002应用程序。
您也可以选择Visual Studio 2005作为开发工具，目前最高版本为Beta 1 Refresh。在Visual Studio 2005中，默认提供了Pocket PC/Smartphone 2003 SE（第二版）的开发模板，同时将Pocket PC 2003 SE开发使用.NET CF版本升级到2.0 (beta)。
安装eVC (可选)
以上环境已经完全可以基于.NET CF开发Windows Mobile应用程序。但如果您想使用C/C++语言来进行native开发，或者想在Windows Mobile设备上开发COM组件及应用，那么可以选择eVC作为开发工具。目前eVC的最高版本为4.0 + SP4，请确保安装了最新的补丁包。
也许您会问：既然已经有了Visual Studio .NET环境，为什么还要使用eVC作为开发工具呢？这主要是因为，当前的.NET CF功能相对而言还很不完整，有很多Windows CE .NET操作系统的核心功能没有被封装入.NET CF，如：加密/解密、网络底层通讯、COM互操作、RAPI等等。为了完成上述操作，我们或者使用平台调用(P/Invoke)以托管方式开发，或者使用eVC直接针对系统底层进行native开发。对于COM互操作，目前.NET CF还不提供COM互操作(Interop)机制，只能使用eVC进行C/C++ COM开发。好消息是，在.NET CF 2.0中将提供功能强大的COM互操作特性支持，同时也将在Visual C++ 2005环境中同时提供managed及native开发功能，这样所有的开发工作将完全整合在Visual Studio 2005同一环境中。
安装Pocket PC/Smartphone 2003 SDK
为了开发Pocket PC 2003或Smartphone 2003应用程序，您还需要安装Pocket PC 2003 SDK或Smartphone 2003 SDK。值得注意的是，这两款SDK中所包含的模拟器均为英语环境，如果您想使用简体中文环境的模拟器，请去微软网站上单独下载。
如果您使用Visual Studio 2005开发Windows Mobile应用程序，则不需要单独安装相应的SDK，因为SDK已经被默认集成至了Visual Studio 2005环境中。
SQL Server CE (可选)
这是Pocket PC上推荐使用的嵌入式数据库产品，它与SQL Server桌面版之间可以实现良好的数据同步及互操作，目前正式版的最新版本为2.0。在SQL Server 2005 Beta 2测试版中，包含有SQL Server CE 2.0的升级版本SQL Server 2005 Mobile Edition——不过该版本目前只支持Pocket PC 2003系统。预计SQL Server Mobile Edition在下一个版本中才能提供对Smartphone的支持。
ActiveSync环境搭建
在完成了上述开发环境的搭建之后，您就可以在Visual Studio .NET中开发和调试应用程序，并在设备/模拟器中进行部署。但是，如果您还需要进一步执行下述操作，那么请按本节所述继续搭建ActiveSync环境。可能的执行操作包括（但不限于）：
l 向设备/模拟器中复制文件
l 从设备/模拟器中删除文件
l 与设备/模拟器同步数据
l 开发和调试包含RAPI (Remote API)功能的应用
l ……
安装ActiveSync
ActiveSync是一款管理Windows Mobile设备连接、与PC进行数据同步的工具。如果您开发时使用的是真实设备，则最好事先安装ActiveSync使之与PC机连接。如果您使用的是模拟器，则除了安装ActiveSync以外，还需要安装下述工具。
安装Connect Emulator with ActiveSync
如果您使用的是模拟器软件，除了安装ActiveSync外，还必须安装Connect Emulator with ActiveSync这款工具软件。它将使您可以直接通过ActiveSync连接到模拟器上。
辅助工具介绍
除了上述基本开发工具以外，在Windows Mobile开发社区中还存在着大量的辅助工具，包括应用程序框架、工具、控件等等。其中有一些由于定位准确、制作优良、使用方便，已经成为Windows Mobile开发不可或缺的好助手。以下列出其中的一部分，更多的还存在于Windows Mobile开发者社区及互联网上，等待着您去发现。
OpenNETCF.org Smart Device Framework
由几位长年活跃于Windows Mobile开发者社区的MVP共同开发的OpenNETCF.org Smart Device Framework (以下简称为SDF)，几天前刚刚获得了Pocket PC Magazine评出的2004年度最佳.NET开发框架大奖。熟悉SDF的开发者都会认为，对于这一奖项，OpenNETCF的确当之无愧，因为SDF几乎已经成了Windows Mobile开发者不可或缺的工具。他们对.NET CF的不足给出了及时的弥补，在SDF中，您可以找到Configuration、XML Serialization、 Notification、Interop Services、WSE 2.0等一系列.NET CF当前版本尚未提供的功能，以及诸如ListBoxEx等优秀的控件。更值得一提的是，SDF是一项完全免费的开源项目。这几位MVP为整个Windows Mobile开发者社区所做的贡献也许真的无法用金钱来衡量。
下载地址：http://www.opennetcf.org。
Windows Mobile Developer Power Toys
这是微软继Pocket PC/Smartphone 2003 SDK之后为开发人员提供的另一套开发辅助工具集。其中包含不少非常值得一用的优秀工具，如：
l ActiveSync Remote Display：把连接在PC上的智能设备影像通过PC屏幕放大显示
l CECopy：以命令行的方式向所连接的智能设备传输文件
l Hopper：用于Pocket PC 2003的用户输入压力测试工具
l PPC Command Shell：用于Pocket PC 2003的命令行工具
l TypeIt：用于Smartphone 2003的辅助文字输入工具
l ……
Mobile Application Development Toolkit 2004
这是微软近期推出的Windows Mobile开发工具及资料集，其中包含上述所有产品及工具，以及一系列相关的文档、教程及参考资料。
结束语
好了，对于如何搭建Windows Mobile的开发环境就介绍到这里了。可以肯定地说，随着微软公司支持力度的增加和Windows Mobile开发者社区的成熟，Windows Mobile开发将面临越来越有利的良好环境。
本文描述了如何搭建典型的Windows Mobile开发环境。介绍了相应的IDE、SDK及辅助开发工具的安装及常用配置，并对Windows Mobile下一代开发环境的发展前景做出展望。本文适合初次接触Windows Mobile开发的开发人员。
Windows Mobile开发简介
Windows Mobile是微软公司操作系统产品线上重要的一环。与Windows 9x/NT/XP/2003相比，Windows Mobile作为完整产品线出现在公众面前的时间非常短，但它的发展却异常迅速，而在这一发展过程中，开发人员提供了绝对关键的推动力。现在，越来越多的开发人员（特别是.NET开发人员）希望能尽快进入Windows Mobile的开发领域，而他们所面临的首要问题，除了熟悉Windows Mobile平台特性之外，便是如何搭建适合的开发环境。因此，本文就将从如何搭建一个Windows Mobile开发环境入手，对Windows Mobile平台的开发特性进行概要描述，以期帮助开发人员迅速进入Windows Mobile开发领域。
在展开本文的内容之前需要说明的一点是，Windows Mobile平台开发主要包含以下两方面内容：
l 平台级开发
l 应用级开发
因为Windows Mobile平台构建于微软的Windows CE系列操作系统之上（当前正式商用版本为Windows CE .NET 4.21），而Windows CE操作系统具有非常良好的模块化特性，因此开发人员，特别是手机设备厂商，可以通过微软提供的Platform Builder及eMbedded Visual C++（以下简称为eVC）非常方便地定制自己所需的操作系统。这对应的是上面所说的平台级开发。
然而，绝大多数的开发人员并不需要去构建一个全新的、个性化的系统，他们只需要关心如何构建能够运行在Windows Mobile设备上的应用程序。为此，微软按主要智能设备自身硬件设备特性的不同以及用户体验的差异，定制出了Windows CE .NET 4.x系列操作系统的两个主要分支，分别安装在不同的Windows Mobile硬件设备中，从而也就构成了我们通常所说的Pocket PC和Smartphone。以下内容中的Windows Mobile开发，除特指之外，均表示Pocket PC/Smartphone开发。
本文中提供的大量开发工具，除单独标出的以外，均可在http://msdn.microsoft.com/mobility/downloads/default.aspx下载。
迅速搭建开发环境
为了进行Windows Mobile开发，我们需要搭建相应的开发环境。所幸的是，这一环境搭建起来非常简单。
安装Visual Studio .NET 2003
为了降低Windows Mobile的开发难度，提高开发人员的开发效率，微软把.NET Framework移植到了Windows Mobile设备上，针对Windows Mobile设备及Windows CE .NET操作系统设计了.NET Compact Framework（以下简称.NET CF）。而Visual Studio .NET 2003正是开发.NET CF应用程序的最佳IDE。在Visual Studio .NET 2003的安装中默认集成了.NET CF 1.0，同时提供了Pocket PC 2002的开发模板，可以直接用来开发Pocket PC 2002应用程序。
您也可以选择Visual Studio 2005作为开发工具，目前最高版本为Beta 1 Refresh。在Visual Studio 2005中，默认提供了Pocket PC/Smartphone 2003 SE（第二版）的开发模板，同时将Pocket PC 2003 SE开发使用.NET CF版本升级到2.0 (beta)。
安装eVC (可选)
以上环境已经完全可以基于.NET CF开发Windows Mobile应用程序。但如果您想使用C/C++语言来进行native开发，或者想在Windows Mobile设备上开发COM组件及应用，那么可以选择eVC作为开发工具。目前eVC的最高版本为4.0 + SP4，请确保安装了最新的补丁包。
也许您会问：既然已经有了Visual Studio .NET环境，为什么还要使用eVC作为开发工具呢？这主要是因为，当前的.NET CF功能相对而言还很不完整，有很多Windows CE .NET操作系统的核心功能没有被封装入.NET CF，如：加密/解密、网络底层通讯、COM互操作、RAPI等等。为了完成上述操作，我们或者使用平台调用(P/Invoke)以托管方式开发，或者使用eVC直接针对系统底层进行native开发。对于COM互操作，目前.NET CF还不提供COM互操作(Interop)机制，只能使用eVC进行C/C++ COM开发。好消息是，在.NET CF 2.0中将提供功能强大的COM互操作特性支持，同时也将在Visual C++ 2005环境中同时提供managed及native开发功能，这样所有的开发工作将完全整合在Visual Studio 2005同一环境中。
安装Pocket PC/Smartphone 2003 SDK
为了开发Pocket PC 2003或Smartphone 2003应用程序，您还需要安装Pocket PC 2003 SDK或Smartphone 2003 SDK。值得注意的是，这两款SDK中所包含的模拟器均为英语环境，如果您想使用简体中文环境的模拟器，请去微软网站上单独下载。
如果您使用Visual Studio 2005开发Windows Mobile应用程序，则不需要单独安装相应的SDK，因为SDK已经被默认集成至了Visual Studio 2005环境中。
SQL Server CE (可选)
这是Pocket PC上推荐使用的嵌入式数据库产品，它与SQL Server桌面版之间可以实现良好的数据同步及互操作，目前正式版的最新版本为2.0。在SQL Server 2005 Beta 2测试版中，包含有SQL Server CE 2.0的升级版本SQL Server 2005 Mobile Edition——不过该版本目前只支持Pocket PC 2003系统。预计SQL Server Mobile Edition在下一个版本中才能提供对Smartphone的支持。
ActiveSync环境搭建
在完成了上述开发环境的搭建之后，您就可以在Visual Studio .NET中开发和调试应用程序，并在设备/模拟器中进行部署。但是，如果您还需要进一步执行下述操作，那么请按本节所述继续搭建ActiveSync环境。可能的执行操作包括（但不限于）：
l 向设备/模拟器中复制文件
l 从设备/模拟器中删除文件
l 与设备/模拟器同步数据
l 开发和调试包含RAPI (Remote API)功能的应用
l ……
安装ActiveSync
ActiveSync是一款管理Windows Mobile设备连接、与PC进行数据同步的工具。如果您开发时使用的是真实设备，则最好事先安装ActiveSync使之与PC机连接。如果您使用的是模拟器，则除了安装ActiveSync以外，还需要安装下述工具。
安装Connect Emulator with ActiveSync
如果您使用的是模拟器软件，除了安装ActiveSync外，还必须安装Connect Emulator with ActiveSync这款工具软件。它将使您可以直接通过ActiveSync连接到模拟器上。
辅助工具介绍
除了上述基本开发工具以外，在Windows Mobile开发社区中还存在着大量的辅助工具，包括应用程序框架、工具、控件等等。其中有一些由于定位准确、制作优良、使用方便，已经成为Windows Mobile开发不可或缺的好助手。以下列出其中的一部分，更多的还存在于Windows Mobile开发者社区及互联网上，等待着您去发现。
OpenNETCF.org Smart Device Framework
由几位长年活跃于Windows Mobile开发者社区的MVP共同开发的OpenNETCF.org Smart Device Framework (以下简称为SDF)，几天前刚刚获得了Pocket PC Magazine评出的2004年度最佳.NET开发框架大奖。熟悉SDF的开发者都会认为，对于这一奖项，OpenNETCF的确当之无愧，因为SDF几乎已经成了Windows Mobile开发者不可或缺的工具。他们对.NET CF的不足给出了及时的弥补，在SDF中，您可以找到Configuration、XML Serialization、 Notification、Interop Services、WSE 2.0等一系列.NET CF当前版本尚未提供的功能，以及诸如ListBoxEx等优秀的控件。更值得一提的是，SDF是一项完全免费的开源项目。这几位MVP为整个Windows Mobile开发者社区所做的贡献也许真的无法用金钱来衡量。
下载地址：http://www.opennetcf.org。
Windows Mobile Developer Power Toys
这是微软继Pocket PC/Smartphone 2003 SDK之后为开发人员提供的另一套开发辅助工具集。其中包含不少非常值得一用的优秀工具，如：
l ActiveSync Remote Display：把连接在PC上的智能设备影像通过PC屏幕放大显示
l CECopy：以命令行的方式向所连接的智能设备传输文件
l Hopper：用于Pocket PC 2003的用户输入压力测试工具
l PPC Command Shell：用于Pocket PC 2003的命令行工具
l TypeIt：用于Smartphone 2003的辅助文字输入工具
l ……
Mobile Application Development Toolkit 2004
这是微软近期推出的Windows Mobile开发工具及资料集，其中包含上述所有产品及工具，以及一系列相关的文档、教程及参考资料。
结束语
好了，对于如何搭建Windows Mobile的开发环境就介绍到这里了。可以肯定地说，随着微软公司支持力度的增加和Windows Mobile开发者社区的成熟，Windows Mobile开发将面临越来越有利的良好环境。
2009年1月30日星期五
UMC逆向思维
* UMC（Ultimate Media Center）如何定位？
（1）家庭媒体中心 UMC Home
（2）企业会议室 视频会议终端 UMC Pro
（3）手持移动娱乐设备 UMC Mobile
* 家用需要哪些特性？
娱乐：电影（高清）、电视（IPTV）、音乐、照片、游戏、
监控：定时、监控、录影、存储、
通讯：可视电话、VoIP、应答机、短信
信息：浏览网页、Google/百度、新闻
* 企业需要哪些特性？
通讯：视频会议、VoIP、文档演示、多方会议
安全：安全、权限控制、加密
可靠：负载均衡、冗余备份、监控、应急恢复
适应：严格网络（443/80）、与办公系统（Outlook、Lotus）集成、与用户系统（AD、LDAP）集成
管理：用户、分组、权限、授权
系统：整体方案（网络、服务器、终端、管理、配套周边、环境）
复杂需求：多层架构、轮询、可定制
* 这些版本有哪些共性？
视频会议、VoIP
高清视频、语音清晰、无噪音回声
界面友好、易于使用
采用SIP/H.323标准协议，可以和标准或者第三方IMS系统集成
支持Windows/Linux/Mac，跨平台
支持多语言，易于国际化
* 硬件成本是否过高？
基于i386架构的HTPC的配置，典型款为￥2100，超薄机型￥4500。相比于其他娱乐终端，XBOX360的￥1800、PS3的￥3000、Wii的￥1400，价格高出不少。
* 周边设备配套是否不够齐整？
全新原装飞利浦 2.4G 无线键盘+鼠标+MCE遥控器 ￥299
Logitech/罗技 疾风战斧PC版 游戏手柄 全国联保 ￥239
全新高科技 PHILIPS SRM7500 支援Vista SideShow万能遥控器 ￥1998
* 配套的摄像头产品是否价格过高？
高端产品:
SONY视频会议 BRC-H700 数字3CCD高清一体化摄像机 ￥20W
SONY视频会议 EVI-HD1 高清一体化摄像机 ￥5W
SONY EVI-D100P视频会议专用摄像机 ￥5500
SONY视频会议 EVI-D70P议普通可倒置摄像机 ￥6800
中级产品：
深圳麦德科技 TAC30U PTZ摄像机 USB2.0接口 视频会议专业摄像头 ￥1500
PTZ 罗技 Logitech QuickCam Orbit AF (黑色) ￥1377
蓝牙技术的无线摄像头产品：罗技 QuickCam Cordless ￥1299
罗技合金版摄像头 Pro 9000 蔡司镜头 全新盒装行货 ￥655
低端产品：
USB2.0 摄像头 某些低价产品低至￥40
（1）家庭媒体中心 UMC Home
（2）企业会议室 视频会议终端 UMC Pro
（3）手持移动娱乐设备 UMC Mobile
* 家用需要哪些特性？
娱乐：电影（高清）、电视（IPTV）、音乐、照片、游戏、
监控：定时、监控、录影、存储、
通讯：可视电话、VoIP、应答机、短信
信息：浏览网页、Google/百度、新闻
* 企业需要哪些特性？
通讯：视频会议、VoIP、文档演示、多方会议
安全：安全、权限控制、加密
可靠：负载均衡、冗余备份、监控、应急恢复
适应：严格网络（443/80）、与办公系统（Outlook、Lotus）集成、与用户系统（AD、LDAP）集成
管理：用户、分组、权限、授权
系统：整体方案（网络、服务器、终端、管理、配套周边、环境）
复杂需求：多层架构、轮询、可定制
* 这些版本有哪些共性？
视频会议、VoIP
高清视频、语音清晰、无噪音回声
界面友好、易于使用
采用SIP/H.323标准协议，可以和标准或者第三方IMS系统集成
支持Windows/Linux/Mac，跨平台
支持多语言，易于国际化
* 硬件成本是否过高？
基于i386架构的HTPC的配置，典型款为￥2100，超薄机型￥4500。相比于其他娱乐终端，XBOX360的￥1800、PS3的￥3000、Wii的￥1400，价格高出不少。
* 周边设备配套是否不够齐整？
全新原装飞利浦 2.4G 无线键盘+鼠标+MCE遥控器 ￥299
Logitech/罗技 疾风战斧PC版 游戏手柄 全国联保 ￥239
全新高科技 PHILIPS SRM7500 支援Vista SideShow万能遥控器 ￥1998
* 配套的摄像头产品是否价格过高？
高端产品:
SONY视频会议 BRC-H700 数字3CCD高清一体化摄像机 ￥20W
SONY视频会议 EVI-HD1 高清一体化摄像机 ￥5W
SONY EVI-D100P视频会议专用摄像机 ￥5500
SONY视频会议 EVI-D70P议普通可倒置摄像机 ￥6800
中级产品：
深圳麦德科技 TAC30U PTZ摄像机 USB2.0接口 视频会议专业摄像头 ￥1500
PTZ 罗技 Logitech QuickCam Orbit AF (黑色) ￥1377
蓝牙技术的无线摄像头产品：罗技 QuickCam Cordless ￥1299
罗技合金版摄像头 Pro 9000 蔡司镜头 全新盒装行货 ￥655
低端产品：
USB2.0 摄像头 某些低价产品低至￥40
2009年1月28日星期三
P2P SIP原理和应用
摘要：SIP协议是当前VoIP和IM等多媒体协议的呼叫建立协议。P2P技术提供了分布式的网络架构中通信节点之间得对等通信能力，P2P网络架构经历了集中目录式网络架构、纯P2P网络架构、混合式P2P网络架构和结构化P2P网络架构。通过引入P2P技术，SIP网络的能力可以得到增强。P2PSIP网络主要有两个重要的操作：对P2P节点的操作和用户层面的操作。
1 SIP网络
会话发起协议(SIP)是互联网工程任务组(IETF)制定的多媒体通信应用层控制协议，用于建立、修改和终止多媒体会话。SIP协议借鉴了超文本传输协议(HTTP)、简单邮件传输协议(SMTP)等，采用基于文本协议控制方式，支持代理、重定向、登记定位用户等功能[1]。
SIP凭借其简单、易于扩展、便于实现等诸多优点而得到了广泛应用。3GPP等标准化组织已经选择SIP作为下一代网络(NGN)和3G多媒体子系统(IMS)中的通信协议，业界已广泛应用了多种基于SIP的多媒体业务[2]。
SIP网络采用客户端/服务器(C/S)的网络架构，按域划分用户。每个域的SIP服务器管理着本域内的用户，用户在使用SIP业务时，需要注册到SIP服务器。各用户之间的通信需要由SIP服务器来进行路由，因此存在SIP服务器的“单点故障”和“性能瓶颈”等问题。
目前有多种提升SIP服务器处理能力的方案，如采用高处理能力的服务器、采用多服务器间的N+1或热备份方案，或者采用多服务器负载均衡技术。
2 P2P技术在互联网上的应用
P2P技术本身并不是新的概念或技术，它的原理是将网络上的通信节点作为平等的通信终端，任意两个通信节点之间既互为“服务器”又互为“客户端”。这一点与互联网的基础协议TCP/IP一致，TCP/IP也没有服务器或客户端的概念，任意两个节点之间是平等通信的。随着互联网应用的扩展，P2P技术得到了广泛的应用。P2P网络采用分布式对象定位机制，使得信息或媒体流在节点之间直接传送，降低了中转开销，从而提高了网络的可扩展性，节省了网络带宽。
很多基于P2P技术如共享MP3格式音乐文件的Napster服务、SETI@Home计划，尤其是Skype应用的成功，使得P2P技术成为业界关注的焦点。
3 P2P网络架构
P2P 网络的技术核心是解决分布式节点之间的资源定位，这需要合适的网络架构，发展至今共经历了3代网络架构。
3.1集中目录式网络架构
最早出现的P2P应用模式就是集中目录式P2P网络，Napster是该架构模型最典型的代表。用户需要登录到中心目录服务器，通过目录服务器查询存储各个节点的资源信息。这种结构的最大特点是所有的资料都是存贮在各个用户节点中。用户获取资源时，节点根据网络流量和延迟等信息选择合适的节点建立直接连接，而不必经过中央服务器。
3.2纯P2P网络架构
纯P2P网络架构采用的是广播式的P2P模型。在这种架构下，没有集中的中央服务器，每个用户节点随机接入到网络，并与自己相邻的一组节点通过端到端连接构成一个逻辑覆盖的网络。节点之间的内容查询和内容共享都是直接通过相邻节点以广播方式接力传递。为了避免循环搜索现象，每个节点会记录其搜索轨迹。
Gnutella模型是现在应用最广泛的纯P2P网络架构，采用泛洪式的节点搜索算法，解决了网络结构中心化的问题，扩展性和容错性较好。但是Gnutella网络可用性较差，易被病毒攻击，并且极大地消耗了网络带宽，很容易造成网络拥塞与不稳定。
3.3混合式P2P网络架构
混合式P2P网络在纯P2P网络架构基础上加入了超级节点的概念。在这种网络下，将节点按能力 (计算能力、内存大小、连接带宽、网络滞留时间等)不同区分为普通节点和超级节点两类。超级节点与其临近的若干普通节点之间构成一个自治的簇，簇内采用基于集中目录式的P2P模式，而整个P2P网络中各个不同的簇之间再通过纯P2P的模式将超级节点相连。有时甚至也可以在各个超级节点之间再次选取性能最优的节点，或者另外引入一新的性能最优的节点作为索引节点来保存整个网络中可以利用的超级节点信息，并且负责维护整个网络的结构。
普通节点的文件搜索先在本簇内进行，只有查询结果不充分时再通过超级节点之间进行有限的泛洪。同时，每个簇中的超级节点监控着所有普通节点的行为，从而确保一些恶意的攻击行为能在网络局部得到控制，也在一定程度上提高了整个网络的负载平衡。
混合式P2P网络架构综合了集中目录式P2P快速查找和纯P2P去中心化的优势，Kazaa模型是P2P混合模型的典型代表。
然而，由于超级节点本身的脆弱性也可能导致其簇内的节点处于孤立状态，因此这种局部索引的方法仍然存在一定的局限性。这导致了结构化的P2P网络模型的出现。
3.4结构化P2P网络架构
结构化P2P架构采用纯分布式的消息传递机制，根据关键字进行节点查找定位。目前结构化网络的主流查询定位方法是采用分布式哈希表(DHT)技术，这也是目前扩展性最好的P2P路由方式之一。
DHT将节点管理的资源或文档作为“关键字”，将节点的IP地址作为“数值”，组成关键字-数值对，并能根据关键字查找数值。DHT技术中的存储和查询是分布在多个节点上进行的，对单一节点的依赖性低，容易实现网络上任一节点的无序加入或退出，对整个网络性能影响较低。
DHT各节点并不要维护整个网络的信息，只需存储其临近后继节点信息，因此通过较少的路由就可以到达目标节点。DHT又取消了泛洪算法，有效地减少了节点信息的发送操作数量，增强了P2P网络的扩展性。
在实际应用中，出于冗余度以及延时的考虑，大部分DHT总是在节点的虚拟标识与关键字最接近的节点上备份冗余信息，这样也避免了单一节点失效的问题。
但是基于DHT的网络拓扑结构的维护和修复也比Gnutella模型和Kazaa模型等无结构的系统要复杂得多，有时甚至出现“绕路”的问题。
目前基于DHT的研究项目主要还集中在具有相同能力的较小规模的网络中，对于大规模的Internet部署还在研究中。同时大量实际的P2P应用还大都是基于无结构的拓扑和泛洪广播机制，采用DHT方式的P2P系统缺乏在Internet中大规模真实部署的成功实例。
4 P2PSIP网络架构
P2P网络[3]的优点是没有中心服务器，节点间直接通信、交换资源和文档，并且可以扩展到分布式的负载分担网络。从理论分析看，P2P网络可以降低C/S结构网络中的“单点故障”和“性能瓶颈”问题。作为C/S结构网络一种的SIP网络也可以利用P2P技术来实现，并且具有以下特点：
去中心化，避免中心SIP服务器的单点故障隐患；
增强SIP网络的扩展性，降低网络中的存储、计算、带宽等性能瓶颈；
提高网络的高可用性，采用P2P网络全分布的架构来提高网络的健壮性；
降低成本，充分利用节点闲置的处理能力、存储和带宽资源。
P2P SIP网络利用SIP协议的扩展和承载来完成P2P层叠加网络节点的加入、定位、查找和路由，降低P2P私有协议带来的扩展性和兼容性问题，实现不同P2P网络的互通。
P2P SIP网络以SIP协议为基础，无需大规模改动现有设备，并且无需改动VoIP终端设备，只要升级现有SIP服务器的软件，即可实现SIP网络的P2P化，提升网络的处理能力和可用性。
在P2P SIP网络中，原来管理一个域的单节点SIP服务器变成多台P2P SIP服务器(称为PN节点)，PN之间通过P2P机制互联，彼此分担负载，构成一个逻辑上的重叠网络。每个节点将和它相连的下一节点当作下一跳PN可以承担原来服务中压力最大的部分，比如注册、代理和计费。用户连接到任一PN，都可以有效使用服务。部分PN的宕机或故障不会影响到整个P2P SIP网络的正常运行。当需要扩大P2P SIP网络的容量，加入新的PN就可以了[4]。
P2P SIP网络有两个重要操作：一是对P2P节点的操作，包括节点注册和离开，实现重叠网络的维护[5]；另一个是用户层面的操作，包括用户的注册、资源定位、会话建立等。
4.1P2PSIP节点操作
P2P节点在地理上散布各处，逻辑上根据选用的P2P机制的不同可以是环形的(Chord协议)、矩阵的(CAN协议)、网状的(Pastry协议和Tapestry协议)。基本的P2P节点至少包括注册和代理两种功能。从运营角度出发，还需要部署全局认证服务器、全局账务服务器和网管服务器等等，用于管理全部用户和所有节点。
每个节点在网络中都有一个节点ID号，该ID号由节点IP地址和端口号进行哈希运算获得，节点信息被存储在一张DHT表中。每个节点负责存储对应信息，如用户注册信息等。
当一个节点申请加入网络中时，先定位一个缺省的网络节点，并发送SIP REGISTER消息给该缺省节点，申请加入网络。如果该缺省节点是负责对应区域的节点，则响应200OK消息，并允许新加入节点加入网络。响应消息中包含邻近节点的信息。
如果缺省节点不是负责对应信息区域的节点，则通过SIP 302响应提供新加入节点前转的网络节点。新加入节点向前转节点发送SIP REGISTER消息，申请加入。前转节点根据自己是否是负责该区域的节点对REGISTER消息进行处理。上述过程一直持续到找到对应的节点为止。
当新加入节点成功加入网络后，新加入节点存储所需要负责的用户信息如用户注册信息，同时通知网络中其它节点更新自己的信息。
4.2P2PSIP用户注册操作
在P2P SIP网络中，每个用户被看成是一个资源，以资源ID标识，资源ID由资源名称经哈希运算获得。
当用户申请注册时，首先生成对应的资源ID。用户所在的节点通过查找路由表，找到一个资源ID和节点ID最接近的节点，并向该节点发送REGISTER消息。如果该最近节点是负责该资源ID的节点，它会将用户名称和IP地址存储在注册表中，并回送200OK消息给用户节点。
如果该最近节点不是负责该资源ID的节点，则通过302消息通知用户节点需要注册到下一节点。下一节点按照和上一节点同样的方式进行处理，直至找到对应的处理节点。对应的处理节点发送200OK消息给用户节点，并存储用户的名字和IP地址。
4.3P2PSIP会话建立操作
用户注册成功后，可以和其他用户进行会话。在会话前，会议发起方需要确定会话接收方的地址。发起方首先生成接收方的资源ID，并确定一个和资源ID最近的节点。然后发送INVITE消息给该最近节点，直到查找到负责接收方的节点。如果接收方用户没有注册，则负责节点通知发送方停止会话；如果接收方已正常注册，负责节点将接收方用户的IP地址通过302响应通过发送方。
在获得了接收方的IP地址后，发起方和接收方就可以按照传统SIP协议的方式建立会议。
5 结束语
利用P2P技术的分布处理和无中心的架构来建设SIP网络是网络发展的一个重要方向。从现在的P2P SIP网络的应用和实践看，这种结合方案还有很多挑战，主要表现在：
P2P技术还不成熟，资源动态分布的优化，资源恢复技术还在进一步研究中。现有的P2P应用主要还是集中在非实时的互联网数据应用上，对于实时的通信节点，以及资源的快速分配定位，还有很多需要P2PSIP网络研究的领域。
P2P的成功应用目前还只是在互联网领域的非实时应用，对于SIP应用，特别是实时通信要求高的呼叫处理而言，基于P2P的SIP网络还需要进行优化。P2PSIP网络利用在去中心化的节点群集来代替原SIP网络中的服务器，现有的P2P技术发现，在P2PSIP网络中对等通信方的查找时间原大于普通SIP网络的对等通信方查找时间。实验发现，两种网络的查找实验时间比超过4倍。
P2P对于带宽和资源的消耗，路由效率低下是P2P技术取得成功应用的难点。现有的成功的P2P应用大都利用“免费”的互联网资源，包括带宽、存储、计算能力等。对于一个可运营可管理的P2PSIP网络而言，需要提高P2P网络技术对资源的使用效率。
P2PSIP网络结构复杂，对于运营商的管理带来了很大的困难。如何实现可运营可管理的P2PSIP网络是目前业界的一个重要课题。
1 SIP网络
会话发起协议(SIP)是互联网工程任务组(IETF)制定的多媒体通信应用层控制协议，用于建立、修改和终止多媒体会话。SIP协议借鉴了超文本传输协议(HTTP)、简单邮件传输协议(SMTP)等，采用基于文本协议控制方式，支持代理、重定向、登记定位用户等功能[1]。
SIP凭借其简单、易于扩展、便于实现等诸多优点而得到了广泛应用。3GPP等标准化组织已经选择SIP作为下一代网络(NGN)和3G多媒体子系统(IMS)中的通信协议，业界已广泛应用了多种基于SIP的多媒体业务[2]。
SIP网络采用客户端/服务器(C/S)的网络架构，按域划分用户。每个域的SIP服务器管理着本域内的用户，用户在使用SIP业务时，需要注册到SIP服务器。各用户之间的通信需要由SIP服务器来进行路由，因此存在SIP服务器的“单点故障”和“性能瓶颈”等问题。
目前有多种提升SIP服务器处理能力的方案，如采用高处理能力的服务器、采用多服务器间的N+1或热备份方案，或者采用多服务器负载均衡技术。
2 P2P技术在互联网上的应用
P2P技术本身并不是新的概念或技术，它的原理是将网络上的通信节点作为平等的通信终端，任意两个通信节点之间既互为“服务器”又互为“客户端”。这一点与互联网的基础协议TCP/IP一致，TCP/IP也没有服务器或客户端的概念，任意两个节点之间是平等通信的。随着互联网应用的扩展，P2P技术得到了广泛的应用。P2P网络采用分布式对象定位机制，使得信息或媒体流在节点之间直接传送，降低了中转开销，从而提高了网络的可扩展性，节省了网络带宽。
很多基于P2P技术如共享MP3格式音乐文件的Napster服务、SETI@Home计划，尤其是Skype应用的成功，使得P2P技术成为业界关注的焦点。
3 P2P网络架构
P2P 网络的技术核心是解决分布式节点之间的资源定位，这需要合适的网络架构，发展至今共经历了3代网络架构。
3.1集中目录式网络架构
最早出现的P2P应用模式就是集中目录式P2P网络，Napster是该架构模型最典型的代表。用户需要登录到中心目录服务器，通过目录服务器查询存储各个节点的资源信息。这种结构的最大特点是所有的资料都是存贮在各个用户节点中。用户获取资源时，节点根据网络流量和延迟等信息选择合适的节点建立直接连接，而不必经过中央服务器。
3.2纯P2P网络架构
纯P2P网络架构采用的是广播式的P2P模型。在这种架构下，没有集中的中央服务器，每个用户节点随机接入到网络，并与自己相邻的一组节点通过端到端连接构成一个逻辑覆盖的网络。节点之间的内容查询和内容共享都是直接通过相邻节点以广播方式接力传递。为了避免循环搜索现象，每个节点会记录其搜索轨迹。
Gnutella模型是现在应用最广泛的纯P2P网络架构，采用泛洪式的节点搜索算法，解决了网络结构中心化的问题，扩展性和容错性较好。但是Gnutella网络可用性较差，易被病毒攻击，并且极大地消耗了网络带宽，很容易造成网络拥塞与不稳定。
3.3混合式P2P网络架构
混合式P2P网络在纯P2P网络架构基础上加入了超级节点的概念。在这种网络下，将节点按能力 (计算能力、内存大小、连接带宽、网络滞留时间等)不同区分为普通节点和超级节点两类。超级节点与其临近的若干普通节点之间构成一个自治的簇，簇内采用基于集中目录式的P2P模式，而整个P2P网络中各个不同的簇之间再通过纯P2P的模式将超级节点相连。有时甚至也可以在各个超级节点之间再次选取性能最优的节点，或者另外引入一新的性能最优的节点作为索引节点来保存整个网络中可以利用的超级节点信息，并且负责维护整个网络的结构。
普通节点的文件搜索先在本簇内进行，只有查询结果不充分时再通过超级节点之间进行有限的泛洪。同时，每个簇中的超级节点监控着所有普通节点的行为，从而确保一些恶意的攻击行为能在网络局部得到控制，也在一定程度上提高了整个网络的负载平衡。
混合式P2P网络架构综合了集中目录式P2P快速查找和纯P2P去中心化的优势，Kazaa模型是P2P混合模型的典型代表。
然而，由于超级节点本身的脆弱性也可能导致其簇内的节点处于孤立状态，因此这种局部索引的方法仍然存在一定的局限性。这导致了结构化的P2P网络模型的出现。
3.4结构化P2P网络架构
结构化P2P架构采用纯分布式的消息传递机制，根据关键字进行节点查找定位。目前结构化网络的主流查询定位方法是采用分布式哈希表(DHT)技术，这也是目前扩展性最好的P2P路由方式之一。
DHT将节点管理的资源或文档作为“关键字”，将节点的IP地址作为“数值”，组成关键字-数值对，并能根据关键字查找数值。DHT技术中的存储和查询是分布在多个节点上进行的，对单一节点的依赖性低，容易实现网络上任一节点的无序加入或退出，对整个网络性能影响较低。
DHT各节点并不要维护整个网络的信息，只需存储其临近后继节点信息，因此通过较少的路由就可以到达目标节点。DHT又取消了泛洪算法，有效地减少了节点信息的发送操作数量，增强了P2P网络的扩展性。
在实际应用中，出于冗余度以及延时的考虑，大部分DHT总是在节点的虚拟标识与关键字最接近的节点上备份冗余信息，这样也避免了单一节点失效的问题。
但是基于DHT的网络拓扑结构的维护和修复也比Gnutella模型和Kazaa模型等无结构的系统要复杂得多，有时甚至出现“绕路”的问题。
目前基于DHT的研究项目主要还集中在具有相同能力的较小规模的网络中，对于大规模的Internet部署还在研究中。同时大量实际的P2P应用还大都是基于无结构的拓扑和泛洪广播机制，采用DHT方式的P2P系统缺乏在Internet中大规模真实部署的成功实例。
4 P2PSIP网络架构
P2P网络[3]的优点是没有中心服务器，节点间直接通信、交换资源和文档，并且可以扩展到分布式的负载分担网络。从理论分析看，P2P网络可以降低C/S结构网络中的“单点故障”和“性能瓶颈”问题。作为C/S结构网络一种的SIP网络也可以利用P2P技术来实现，并且具有以下特点：
去中心化，避免中心SIP服务器的单点故障隐患；
增强SIP网络的扩展性，降低网络中的存储、计算、带宽等性能瓶颈；
提高网络的高可用性，采用P2P网络全分布的架构来提高网络的健壮性；
降低成本，充分利用节点闲置的处理能力、存储和带宽资源。
P2P SIP网络利用SIP协议的扩展和承载来完成P2P层叠加网络节点的加入、定位、查找和路由，降低P2P私有协议带来的扩展性和兼容性问题，实现不同P2P网络的互通。
P2P SIP网络以SIP协议为基础，无需大规模改动现有设备，并且无需改动VoIP终端设备，只要升级现有SIP服务器的软件，即可实现SIP网络的P2P化，提升网络的处理能力和可用性。
在P2P SIP网络中，原来管理一个域的单节点SIP服务器变成多台P2P SIP服务器(称为PN节点)，PN之间通过P2P机制互联，彼此分担负载，构成一个逻辑上的重叠网络。每个节点将和它相连的下一节点当作下一跳PN可以承担原来服务中压力最大的部分，比如注册、代理和计费。用户连接到任一PN，都可以有效使用服务。部分PN的宕机或故障不会影响到整个P2P SIP网络的正常运行。当需要扩大P2P SIP网络的容量，加入新的PN就可以了[4]。
P2P SIP网络有两个重要操作：一是对P2P节点的操作，包括节点注册和离开，实现重叠网络的维护[5]；另一个是用户层面的操作，包括用户的注册、资源定位、会话建立等。
4.1P2PSIP节点操作
P2P节点在地理上散布各处，逻辑上根据选用的P2P机制的不同可以是环形的(Chord协议)、矩阵的(CAN协议)、网状的(Pastry协议和Tapestry协议)。基本的P2P节点至少包括注册和代理两种功能。从运营角度出发，还需要部署全局认证服务器、全局账务服务器和网管服务器等等，用于管理全部用户和所有节点。
每个节点在网络中都有一个节点ID号，该ID号由节点IP地址和端口号进行哈希运算获得，节点信息被存储在一张DHT表中。每个节点负责存储对应信息，如用户注册信息等。
当一个节点申请加入网络中时，先定位一个缺省的网络节点，并发送SIP REGISTER消息给该缺省节点，申请加入网络。如果该缺省节点是负责对应区域的节点，则响应200OK消息，并允许新加入节点加入网络。响应消息中包含邻近节点的信息。
如果缺省节点不是负责对应信息区域的节点，则通过SIP 302响应提供新加入节点前转的网络节点。新加入节点向前转节点发送SIP REGISTER消息，申请加入。前转节点根据自己是否是负责该区域的节点对REGISTER消息进行处理。上述过程一直持续到找到对应的节点为止。
当新加入节点成功加入网络后，新加入节点存储所需要负责的用户信息如用户注册信息，同时通知网络中其它节点更新自己的信息。
4.2P2PSIP用户注册操作
在P2P SIP网络中，每个用户被看成是一个资源，以资源ID标识，资源ID由资源名称经哈希运算获得。
当用户申请注册时，首先生成对应的资源ID。用户所在的节点通过查找路由表，找到一个资源ID和节点ID最接近的节点，并向该节点发送REGISTER消息。如果该最近节点是负责该资源ID的节点，它会将用户名称和IP地址存储在注册表中，并回送200OK消息给用户节点。
如果该最近节点不是负责该资源ID的节点，则通过302消息通知用户节点需要注册到下一节点。下一节点按照和上一节点同样的方式进行处理，直至找到对应的处理节点。对应的处理节点发送200OK消息给用户节点，并存储用户的名字和IP地址。
4.3P2PSIP会话建立操作
用户注册成功后，可以和其他用户进行会话。在会话前，会议发起方需要确定会话接收方的地址。发起方首先生成接收方的资源ID，并确定一个和资源ID最近的节点。然后发送INVITE消息给该最近节点，直到查找到负责接收方的节点。如果接收方用户没有注册，则负责节点通知发送方停止会话；如果接收方已正常注册，负责节点将接收方用户的IP地址通过302响应通过发送方。
在获得了接收方的IP地址后，发起方和接收方就可以按照传统SIP协议的方式建立会议。
5 结束语
利用P2P技术的分布处理和无中心的架构来建设SIP网络是网络发展的一个重要方向。从现在的P2P SIP网络的应用和实践看，这种结合方案还有很多挑战，主要表现在：
P2P技术还不成熟，资源动态分布的优化，资源恢复技术还在进一步研究中。现有的P2P应用主要还是集中在非实时的互联网数据应用上，对于实时的通信节点，以及资源的快速分配定位，还有很多需要P2PSIP网络研究的领域。
P2P的成功应用目前还只是在互联网领域的非实时应用，对于SIP应用，特别是实时通信要求高的呼叫处理而言，基于P2P的SIP网络还需要进行优化。P2PSIP网络利用在去中心化的节点群集来代替原SIP网络中的服务器，现有的P2P技术发现，在P2PSIP网络中对等通信方的查找时间原大于普通SIP网络的对等通信方查找时间。实验发现，两种网络的查找实验时间比超过4倍。
P2P对于带宽和资源的消耗，路由效率低下是P2P技术取得成功应用的难点。现有的成功的P2P应用大都利用“免费”的互联网资源，包括带宽、存储、计算能力等。对于一个可运营可管理的P2PSIP网络而言，需要提高P2P网络技术对资源的使用效率。
P2PSIP网络结构复杂，对于运营商的管理带来了很大的困难。如何实现可运营可管理的P2PSIP网络是目前业界的一个重要课题。
2009年1月20日星期二
UMC硬件配置
Hiper高清HTPC
http://item.taobao.com/auction/item_detail-null-fde23b2cb31b145abee90c57f08664d2.jhtml
TAC30U PTZ USB摄像头
技术参数：
视频指标: CMOS感光片 35万有效像素 640x480最高分辩率、30帧全速率
接口标准USB2.0, 兼容USB1.1
视频格式 QCIF/CIF/VGA/1280*1024, 压缩编码 I420/RGB24/YUV2
通讯指标: TAC自有通讯协议，开放式API及开发文件
功能指标: 水平转动 300°，左右各 150° 垂直转垂直转动 90 °，上60°/下30°
遥控功能: 电源休眠、PAN/TILT 转动控制
* Microsoft XP和VISTA操作系统免驱动
Phoenix Duet Speaker Phone
http://item.taobao.com/auction/item_detail-null-fde23b2cb31b145abee90c57f08664d2.jhtml
TAC30U PTZ USB摄像头
技术参数：
视频指标: CMOS感光片 35万有效像素 640x480最高分辩率、30帧全速率
接口标准USB2.0, 兼容USB1.1
视频格式 QCIF/CIF/VGA/1280*1024, 压缩编码 I420/RGB24/YUV2
通讯指标: TAC自有通讯协议，开放式API及开发文件
功能指标: 水平转动 300°，左右各 150° 垂直转垂直转动 90 °，上60°/下30°
遥控功能: 电源休眠、PAN/TILT 转动控制
* Microsoft XP和VISTA操作系统免驱动
Phoenix Duet Speaker Phone
2009年1月15日星期四
UMC todo list
1, bugfix (memory leak), video display, stable version, 1.0
2, interface, logo, icon, picture, brand: umc = Ultimate Media Center
3. call in accept/deny/auto (config in settings), answer machine (in future)
4. play wave on event (call in/out, later error[n] -> lang)
5. conference, add "quick call", input digit number, then call out with default protocol (config in settings)
6. change bandwidth = connection, add upload/download bandwidth
7, http://<url>/?cdkey=<>&ver=<>&lang=<>
<xml utf-8>
<modules>
<module key=video/audio/picture/conference value=on/off>
...
</modules>
<messages>
<message key="" value="text">
...
</messages>
</xml>
2, interface, logo, icon, picture, brand: umc = Ultimate Media Center
3. call in accept/deny/auto (config in settings), answer machine (in future)
4. play wave on event (call in/out, later error[n] -> lang)
5. conference, add "quick call", input digit number, then call out with default protocol (config in settings)
6. change bandwidth = connection, add upload/download bandwidth
7, http://<url>/?cdkey=<>&ver=<>&lang=<>
<xml utf-8>
<modules>
<module key=video/audio/picture/conference value=on/off>
...
</modules>
<messages>
<message key="" value="text">
...
</messages>
</xml>
2009年1月7日星期三
高清媒体播放机产品分析
由于工作需要，把市面上常见的高清、标清媒体播放器做了一个简单的梳理。
以下分析，以国内市场上的媒体播放机为主
—
以存储介质划分：
主要有三种：DVD式、硬盘式和读卡器式；
以芯片类型划分：
1. 以AmLogic，C2，JZ等国产芯片为主
RMVB播放器；成本低；画质一般；以标清输出的机顶盒(最高可达720p)／少数有HDMI输出/立体声音频，手持MP4播放器为主；读卡器式；大概最低售价在300～500元（不含存储）。少数高端产品使用Analog Devices’s Blackfin 或 TI’s daVinci；
产品主要有：汤姆逊高清播放机、联想 RMVBBOX720、英唐舒影硬盘播放器、创维酷开电视等等……
2. 以Sigma Designs，少数使用Broadcom，ST，NXP，Conexant，TI芯片；
HD播放器；成本略高，画质好；高清1080P输出/5.1声道音频/HDMI输出；支持H.264 VC-1；通常不支持RMVB；
大概最低售价为1200（不含存储）；大部分以硬盘为存储介质，少数采用DVD光驱；
Sigma Designs的方案也有8620/8622/8623/8624（广告机/高清播放器）；8634/8635（高清播放机/蓝光播放机）；8654（蓝光/高清）；
产品主要有：联想 P100；开博尔 K007/K008; 高清锐视 HDVISION N1; TVIX HD M-7000A；TVIX HD M-6500A；亿格瑞 EG-M31A，EG-M31B；MEDIAGATE MG-350HD；宇脉 limHD310A；
HiMedia HD8； Buffalo LT-H90LAN；飞利浦DVR2008/93；Haidee1000；少数产品内置SATA 带USB Slave功能，如亿格瑞EG-M31A；
3. 以x86为主
使用VIA的小型主板或者市场上带HDMI输出的小型主板构造的HTPC产品；格式支持完整，高清输出；少数带5.1声道音频；DIY价格大概在3000左右，基本上是一台电脑，大多数跑Windows；NetVii提供了一个软件解决方案，跑在Linux+x86的系统上，有点意思。
以软件类型划分：
1. SYABAS (http://www.syabas.com/)
专门为Sigma Designs开发固件的协力厂商；Syabas中间件公司开发的NMT固件, NMT是Networked Media Tank的缩写，这是绝大部分小品牌厂或山寨厂产品中采用的固件；Syabas公司没有生产自己品牌的产品；
各项功能完备，UI基于浏览器；新版本带有BT下载功能，但操作繁琐，大部分用户不了解使用；
总部在Fremont, California, USA
UI可见：http://zone.it.sohu.com/forums/thread-2641181-1-1.html
采用Syabas固件的产品包括：
爱视达 (iStar) 主页：http://www.hdinlife.com 论坛：http://bbs.hdinlife.com 产品有：iStar Z4, iStar Mini HD Player;
开博尔（Kaiboer）主页：http://www.hdtvplayer.cn 论坛 http://bbs.hd-tv.cn/forum-71-1.html 产品有：K007, K008；
PopCorn Hour 主页 http://www.popcornhour.com/onlinestore/ 产品有：A100；
Dune HD Ultra 主页 http://www.dune-hd.com/ ;
顶鼎(TOP) 主页 ：http://www.hdtv-china.cn 产品有：顶鼎Feeling 2008（S版本）, M版 （顶鼎Top M版固件中的M应该是英文单词“Modified”的缩写，相信是Top购买了Syabas的SDK，自己在Syabas的公版(Standard Version)固件基础上再次研发而来的）
高清之星(HDX Player) 主页：http://www.hd-1080.com 产品有：HD-X Player X900 参考：http://www.pany.idv.tw/3c/webhdx900/index.htm
高清锐视 HDVISION N1;
亿格瑞 EG-M31A，EG-M31B；
这些产品都是使用Syabas的NMT固件，所以功能和界面都是大同小异，差别都不大，感觉不同的是不同的厂商在硬件上各自的侧重点（外观、接口等）不一样而已。
虽然都使用Syabas的固件，应该是不能通用互刷的，相信这也是Syabas设计的初衷，Syabas每次出的都是工程版固件(Engineering firmware)，然后再分发给不同的OEM厂商作一些定制（比如默认菜单语言、厂商Logo等），且会用一些特征标识固件，这样就不能互换了。不过如果通过硬件写ROM的方法来刷新固件的话，应该是可以互换的，但这需要太多的条件也要冒很大的风险。
2. 厂家自主固件：
以韩国品牌以及部分国产品牌为主。
1) 宇脉：http://www.tomacro.com 产品有：LimHD200i, LimHD210s,limHD310A 等
2) TVIX HD ：韩国DViCo公司，http://www.tvix.co.kr 或 http://www.tvxhd.com.cn/main.htm 产品有：Tvix M-4100SH, Tvix M-5100SH, Tvix M-6500A
3) Lenovo: 联想/闪联，P100产品
4) MEDIAGATE： MG-350HD
其他相关机顶盒厂商及产品：
Apple TV：HD Contents+iTunes+Apple TV
21CN
天柏：推出高清机顶盒、媒体播放、游戏机顶盒于一体的媒体中心/希望打造成苹果那样的商业模式，而不是简单地卖机顶盒
MYKA
汉辰：仅不成熟的技术方案，无产品
GoBox
Vudu
TiVo
盛大
Netflix+LG/Roku
Amazon…
Xbox Live Marketplace
SONY Movie + PS3
Sezmi Box(GodBox)
Netflix
Panasonic Viera
SONY：Internet Video Link HD
iPVD
NetVii
以上内容转载自 http://www.vvcast.cn/2008/11/products-analysis-on-high-definition-media-player/
以下分析，以国内市场上的媒体播放机为主
—
以存储介质划分：
主要有三种：DVD式、硬盘式和读卡器式；
以芯片类型划分：
1. 以AmLogic，C2，JZ等国产芯片为主
RMVB播放器；成本低；画质一般；以标清输出的机顶盒(最高可达720p)／少数有HDMI输出/立体声音频，手持MP4播放器为主；读卡器式；大概最低售价在300～500元（不含存储）。少数高端产品使用Analog Devices’s Blackfin 或 TI’s daVinci；
产品主要有：汤姆逊高清播放机、联想 RMVBBOX720、英唐舒影硬盘播放器、创维酷开电视等等……
2. 以Sigma Designs，少数使用Broadcom，ST，NXP，Conexant，TI芯片；
HD播放器；成本略高，画质好；高清1080P输出/5.1声道音频/HDMI输出；支持H.264 VC-1；通常不支持RMVB；
大概最低售价为1200（不含存储）；大部分以硬盘为存储介质，少数采用DVD光驱；
Sigma Designs的方案也有8620/8622/8623/8624（广告机/高清播放器）；8634/8635（高清播放机/蓝光播放机）；8654（蓝光/高清）；
产品主要有：联想 P100；开博尔 K007/K008; 高清锐视 HDVISION N1; TVIX HD M-7000A；TVIX HD M-6500A；亿格瑞 EG-M31A，EG-M31B；MEDIAGATE MG-350HD；宇脉 limHD310A；
HiMedia HD8； Buffalo LT-H90LAN；飞利浦DVR2008/93；Haidee1000；少数产品内置SATA 带USB Slave功能，如亿格瑞EG-M31A；
3. 以x86为主
使用VIA的小型主板或者市场上带HDMI输出的小型主板构造的HTPC产品；格式支持完整，高清输出；少数带5.1声道音频；DIY价格大概在3000左右，基本上是一台电脑，大多数跑Windows；NetVii提供了一个软件解决方案，跑在Linux+x86的系统上，有点意思。
以软件类型划分：
1. SYABAS (http://www.syabas.com/)
专门为Sigma Designs开发固件的协力厂商；Syabas中间件公司开发的NMT固件, NMT是Networked Media Tank的缩写，这是绝大部分小品牌厂或山寨厂产品中采用的固件；Syabas公司没有生产自己品牌的产品；
各项功能完备，UI基于浏览器；新版本带有BT下载功能，但操作繁琐，大部分用户不了解使用；
总部在Fremont, California, USA
UI可见：http://zone.it.sohu.com/forums/thread-2641181-1-1.html
采用Syabas固件的产品包括：
爱视达 (iStar) 主页：http://www.hdinlife.com 论坛：http://bbs.hdinlife.com 产品有：iStar Z4, iStar Mini HD Player;
开博尔（Kaiboer）主页：http://www.hdtvplayer.cn 论坛 http://bbs.hd-tv.cn/forum-71-1.html 产品有：K007, K008；
PopCorn Hour 主页 http://www.popcornhour.com/onlinestore/ 产品有：A100；
Dune HD Ultra 主页 http://www.dune-hd.com/ ;
顶鼎(TOP) 主页 ：http://www.hdtv-china.cn 产品有：顶鼎Feeling 2008（S版本）, M版 （顶鼎Top M版固件中的M应该是英文单词“Modified”的缩写，相信是Top购买了Syabas的SDK，自己在Syabas的公版(Standard Version)固件基础上再次研发而来的）
高清之星(HDX Player) 主页：http://www.hd-1080.com 产品有：HD-X Player X900 参考：http://www.pany.idv.tw/3c/webhdx900/index.htm
高清锐视 HDVISION N1;
亿格瑞 EG-M31A，EG-M31B；
这些产品都是使用Syabas的NMT固件，所以功能和界面都是大同小异，差别都不大，感觉不同的是不同的厂商在硬件上各自的侧重点（外观、接口等）不一样而已。
虽然都使用Syabas的固件，应该是不能通用互刷的，相信这也是Syabas设计的初衷，Syabas每次出的都是工程版固件(Engineering firmware)，然后再分发给不同的OEM厂商作一些定制（比如默认菜单语言、厂商Logo等），且会用一些特征标识固件，这样就不能互换了。不过如果通过硬件写ROM的方法来刷新固件的话，应该是可以互换的，但这需要太多的条件也要冒很大的风险。
2. 厂家自主固件：
以韩国品牌以及部分国产品牌为主。
1) 宇脉：http://www.tomacro.com 产品有：LimHD200i, LimHD210s,limHD310A 等
2) TVIX HD ：韩国DViCo公司，http://www.tvix.co.kr 或 http://www.tvxhd.com.cn/main.htm 产品有：Tvix M-4100SH, Tvix M-5100SH, Tvix M-6500A
3) Lenovo: 联想/闪联，P100产品
4) MEDIAGATE： MG-350HD
其他相关机顶盒厂商及产品：
Apple TV：HD Contents+iTunes+Apple TV
21CN
天柏：推出高清机顶盒、媒体播放、游戏机顶盒于一体的媒体中心/希望打造成苹果那样的商业模式，而不是简单地卖机顶盒
MYKA
汉辰：仅不成熟的技术方案，无产品
GoBox
Vudu
TiVo
盛大
Netflix+LG/Roku
Amazon…
Xbox Live Marketplace
SONY Movie + PS3
Sezmi Box(GodBox)
Netflix
Panasonic Viera
SONY：Internet Video Link HD
iPVD
NetVii
以上内容转载自 http://www.vvcast.cn/2008/11/products-analysis-on-high-definition-media-player/
订阅：
博文 (Atom)