Monday, October 31, 2005
Hosting .NET Windows Forms Controls in IE
Resemble Java Applets:-)
但是Hosting .NET WinForm的最大问题是支持，仅仅Microsoft自己的IE6.0+.NET Framework才能够运行这些控件。太多的限制，难怪很少见到这项技术的实际应用。
Java Applet在浏览器上被Microsoft的压制，使得JavaApplet的局势越来越糟。
看样子Flash技术才是Web Rich Client的唯一解决方案。
如果能够出现Flash+.NET的解决方案，将一统Web端Rich方案。
但是Hosting .NET WinForm的最大问题是支持，仅仅Microsoft自己的IE6.0+.NET Framework才能够运行这些控件。太多的限制，难怪很少见到这项技术的实际应用。
Java Applet在浏览器上被Microsoft的压制，使得JavaApplet的局势越来越糟。
看样子Flash技术才是Web Rich Client的唯一解决方案。
如果能够出现Flash+.NET的解决方案，将一统Web端Rich方案。
Wednesday, October 26, 2005
About .NET
= 无聊的多语言支持 =
其实.NET对多种编程语言(C++,C#,VB, etc)的支持是一个无聊的把戏，没有太多的意义而带来的很多的麻烦。Microsoft对这些语言.NET版本的支持造成了成本上升，初学者常常为学习那种语言而苦恼，.NET开发人员也会因为使用的语言不同而造成communication overhead.
然后，计算机编程语言本身的差异性相对于编程平台的差异来说不大。一个熟练的开发人员要熟悉C#的语法一周就已经足够了。但是，要熟悉整个.NET Framework和相应的开发平台可能需要好几个月的时间。
然后为了避免这一周的学习，MS制造了如此多版本的.NET Computing Language可谓得不偿失。而且，VB6的开发人员要使用VB.NET也需要很长时间的学习。因为，就我遇到的几个VB6的开发人员学习情况来看是这个样的。
= 我想看到Source Code =
更加糟糕的是，你根本开不到.NET Framework是如何使用.NET Computing Language的。对于开发者来说，最好的学习工具和范本就是Source Code。如果，他能看到Framework的Source Code，那样就更加知道如何使用这些编程语言开发程序。
其实.NET对多种编程语言(C++,C#,VB, etc)的支持是一个无聊的把戏，没有太多的意义而带来的很多的麻烦。Microsoft对这些语言.NET版本的支持造成了成本上升，初学者常常为学习那种语言而苦恼，.NET开发人员也会因为使用的语言不同而造成communication overhead.
然后，计算机编程语言本身的差异性相对于编程平台的差异来说不大。一个熟练的开发人员要熟悉C#的语法一周就已经足够了。但是，要熟悉整个.NET Framework和相应的开发平台可能需要好几个月的时间。
然后为了避免这一周的学习，MS制造了如此多版本的.NET Computing Language可谓得不偿失。而且，VB6的开发人员要使用VB.NET也需要很长时间的学习。因为，就我遇到的几个VB6的开发人员学习情况来看是这个样的。
= 我想看到Source Code =
更加糟糕的是，你根本开不到.NET Framework是如何使用.NET Computing Language的。对于开发者来说，最好的学习工具和范本就是Source Code。如果，他能看到Framework的Source Code，那样就更加知道如何使用这些编程语言开发程序。
Tuesday, October 25, 2005
Reading: Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Reference Implementation
Author: Mauro Regio
Resource: Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Reference Implementation
Resource: Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Reference Implementation
Friday, October 21, 2005
敏捷实践12条原则 -- Martin Fowler
敏捷实践12条原则 -- Martin Fowler
Martin
敏捷实践12 条原则，它们是敏捷实践区别于重型过程的特征所在。
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件（working software ），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤
对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施（ infrastructure）代码的数量来度量开发进度的。
只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的清洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断的变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
结论
每一个软件开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。可是，我们的项目以令人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的，但是膨胀的过程方法对于我们的失败至少是应该负一些责任的。敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单的技术。
Martin
敏捷实践12 条原则，它们是敏捷实践区别于重型过程的特征所在。
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件（working software ），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤
对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施（ infrastructure）代码的数量来度量开发进度的。
只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的清洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断的变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
结论
每一个软件开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。可是，我们的项目以令人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的，但是膨胀的过程方法对于我们的失败至少是应该负一些责任的。敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单的技术。
Monday, October 10, 2005
开发团队的质量保证
开发团队的产品质量的依赖于2类主要的因素，一个是人员的素质，另一个是质量体系（包括软件流程）的规范和实施。
质量体系有一个主要的作用就是来弥补人的缺陷。但是，不能取代人因素。产品质量需要人的能力、责任感、热情的支持，否则再好的流程也难获得好的产品质量。好的质量体系可以提高人员的工作效率，弥补人的缺陷，并且能够避免容易重复犯的错误。能够协助团队的成长。
质量体系有一个主要的作用就是来弥补人的缺陷。但是，不能取代人因素。产品质量需要人的能力、责任感、热情的支持，否则再好的流程也难获得好的产品质量。好的质量体系可以提高人员的工作效率，弥补人的缺陷，并且能够避免容易重复犯的错误。能够协助团队的成长。
Saturday, October 08, 2005
Task-Oriented Project Management Relationship
Task-Oriented Project Management Relationship
Task input includes Artifact and Processor Task.
Task output includes the Artifact and Successor Task.
Task has Processor and Successor Task.
The lifecycle of Task includes Submit, Assign, Open, Resolve, Verify, Close, Duplicate and Monitor.
Types of Task include Defect, Enhancement, Requirement, Design, and Implementation.
Participations
The relationship between Tasks is Depends (Waiting), Include, Extend, Processor, and Successor.
Task input includes Artifact and Processor Task.
Task output includes the Artifact and Successor Task.
Task has Processor and Successor Task.
The lifecycle of Task includes Submit, Assign, Open, Resolve, Verify, Close, Duplicate and Monitor.
Types of Task include Defect, Enhancement, Requirement, Design, and Implementation.
Participations
The relationship between Tasks is Depends (Waiting), Include, Extend, Processor, and Successor.
