Scott等就ASP.NET MVC 1.0编写了Professional ASP.NET MVC 1.0一书，并提供了免费的第一章、第二章下载。其中，第一章以一个完整的案例NerdDinner讲解了如何使用ASP.NET MVC技术对网站进行开发。这个一篇指导意义非常强的教程，对于ASP.NET MVC的初学者是最合适不过的教学案例了。第一章提供了html版和PDF版，EntLIb论坛对 这些内容进行了翻译，提供了比较完整的HTML中文版。HTML网页固然方便，但毕竟过于零散，不如PDF文档显得正式和统一。此外，EntLib对 Scott的案例作了少量的修改，增加了EntLib的标识。同时，该网站还省略了教程中集成地图的部分，我觉得略有遗憾。所以，我在EntLib的基础 上，完善了整个文档的翻译，还原了英文版的本来面目，并提供了PDF格式的文档。
内容包括：
1、创建MVC Web Application
2、创建数据库
3、创建Model模型
4、控制器和视图
5、创建、更新、删除记录
6、模型绑定的安全性
7、ViewData和ViewModel
8、Partials和Master页面
9、认证和授权
10、AJAX实现RSVP响应
11、集成AJAX地图
12、单元测试
13、依赖注入
完整文档下载：ASP.NET MVC Step by Step中文版
在WS-*标准和规范中，WS-Discovery是在2008年才加入了OASIS标准。WS-Discovery在标准被定义为Web Service Dynamic Discovery，其目的是为定位服务定义Discovery协议，主要应用在为客户端动态搜索一个或多个目标服务。OASIS为WS- Discovery提供了两种操作模式：ad hoc和managed模式。
ad hoc模式根据类型在托管目标服务的范围内查找目标服务。客户端会以多播的形式发送一个Probe（探测）消息，如果服务匹配该信息，则以单播方式直接将响应发送到客户端。为了能够根据名称定位目标服务，客户端会以相同的多播组发送一个Resolve（解析）消息，同样的，匹配该消息的服务会直接以单播方式响应客户端。消息交换的流程如下图所示：
全文阅读>>
最 佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的 团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估， 并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。
自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成 员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的 技术特长，开放的平台则能够保证协作的效率。一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。
自我组织的团队建立在团队个人能力的基础之上。它其实是一把双刃剑。如果团队成员个人能力有限，或者自我约束能力较差，而管理人员又无法把握松散管理的度，就很可能出现一些问题。例如：
1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式；
2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；
3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间。
如 何解决这三个问题？对于第一个问题，基本无解，除非你有足够的煽动力或超凡的演讲能力，改变这些开发人员的思想，乃至于开发习惯。最佳方式是循序渐进，并 对自我组织的方式进行改进，例如和传统的管理方式结合起来。或者就放弃敏捷的管理方式吧。如果说敏捷是鱼，只能在水中生活，你怎么能让它上岸呢？
对于第二个问题，需要动用团队的力量。例如对任务的评估，我们可以利用计划游戏，或者设计计划纸牌对任务工作量进行估算。总之，我们应尽量让团队对任务工作量的估算不要出现太大的偏差，使任务的开发在可控的范围内。此外，及时召开回顾会议，也是杜绝这类问题的一件利器。
第三个问题需要团队的管理者建立某些准则，例如对技术问题的讨论设定时间的限制。一旦超出该时间，就应该把问题放在一边，或者由管理者利用自己的权威和经验下定结论，而不能无限制的争执下去。
自 我组织的团队管理者需要因时因人而置宜。Larry L. Constantine在《人件集》中提到：“对于开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分 析、设计和系统构建。”例如在Scrum中，团队角色就是一个自我组织的团队，由团队来确定每个Sprint的工作内容。而Scrum Master就不再是控制者，而是指导者；不是上司，而是教练。他必须理解自组织团队的重要性。
自我组织是敏捷管理的精髓，也是敏捷管理成败的关键！
秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。
1、拥抱变化
Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断 说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选 美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。
传统的软件开发过程由于过分强调文档的完整，重视与客户的谈判与签订合同。 所以，开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字，需求就确定下来，不可更改。若要更改，必须经过需求变更委员会，走非常严格的需求变 更流程。如果软件开发真能如此，倒也算是我们开发人员的幸事。但现实总是残酷的，需求总是会变化。变化的原因有以下几种：
1）业务发生了变化；
2）客户对业务的理解发生了变化；
3）需求分析人员对需求的理解出现了偏差，需要修正。
对于第一点，或许我们还能够根据合同与客户讨价还价，而对于后两点，尤其是第三点，我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求，针对变化给出相应的解决方案。
如何拥抱变化呢？我想可以通过如下方式来实现：
1）现场客户
很 多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无 论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法，但有了和现场客户的及时沟通，我们才能够在 发生变化的初始就能够获得第一手的资讯。如果事情总要发生，早解决绝对比晚解决要好，而且要好得多。
如果在开发中，没有办法让客户成为团队 的一员，那么我们也应该指定一位客户代表，退而求其次，也应该在团队中指定一位业务专家负责业务事宜，也就是Scrum中Product Owner的角色。总之，我们需要在项目开发中，能够让开发人员在对需求理解发生困惑时，能够明确地知道由谁来负责。而一旦需求发生变化，也必须有专门的 角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定，也必须由这个角色指定。
2）定期迭代和小版本交付
不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint，持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。
敏 捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以 信心，另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了，那就是我们的客户。如果没有现场客户， 则小版本的交付则显得尤为重要，因为它给了我们及早修订错误的机会。
3）持续改进
开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。
在 Scrum中，每个Sprint完成并结束了评审会议之后，都会召开一个回顾会议，即使总结优秀经验，检讨错误与教训，团队方能够从错误中成长起来。此 外，回顾会议还能够帮助团队正确地认识自己，帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议，可以让客户更直观地了解团队，比提出自 己的看法，有助于在后面的开发过程改善合作的质量。
设计模式最经典的书籍自然是GOF的《设计模式》，但很多人的反应是这本书太难理解了，并不适合初学者阅读。这话说得在理。一方面，本书使用的C++示例难倒了一大群Java和.NET的开发人员；另一方面，这本书的风格过于专业化，更偏向于学术论文的风格（事实上，本书的雏形就是来源于GOF中Erich Gamma的博士论文），因此就显得有些晦涩难懂了。
基本上，本书可以作为我们参考的标准，是经常查阅的文献资料。如果你对某个设计模式还有困惑不解之处，阅读本书，然后细细品味，总会给你一些豁然开朗的感觉。夸张点说，这本书可以说是设计模式的红宝书，即使人手一册，也不为过。说句题外话，我还是喜欢外版书的封面设计，给人一种艺术的美感，让人看着就有想买的冲动。国内专业书籍的装帧与设计，做得好的，真的很少。
全文阅读>>
本讲义主要包括以下三部分：面向对象三要素、面向对象五原则和面向对象六视点。面向对象三要素包括：封装(Encapsulation)、继承 (Inheritance)、多态(Polymorphism)。五原则自然是众所周知的OO五原则：单一职责原则、开放封闭原则、Liskov替换原则、依赖倒置原则和接口隔离原则。前面两部分内容是大多数OO设计都需要掌握的内容，在讲解中虽然加入了我的一些理解，但讲义中并无太多新鲜的东西。最后一部分则是我这段时间对面向对象的认识与思考，分别包括：复用、扩展、分离、变化、简约和一致。这些内容是我的第二本著作的雏形，当然讲义中展现的内容仅仅是冰山一角，不过大体框架已经具备了。
讲义下载：OOD.pdf
Mediator模式有一种本事，就是可以让本身需要互相协作的对方，可以不用知道彼此，而把两者之间的联系，转交给Mediator来处理。换句话说，Mediator模式解除了需要互相协调的对象之间的依赖。这也是Mediator（调停者）模式名字的由来。一个颇为形象的例子是聊天室。进入聊天室的用户总是要彼此通信的，这些对象如果直接进行交互，就会彼此连接，最后织成一张纷繁复杂的大网。要分清彼此之间的关系，真可以说是“剪不断理还乱” 了。所以，引入一个聊天室对象来管理用户间的交流，就势成必然。
全文阅读>>
站立会议对于Scrum的意义，就像我们每天早上起来总是希望看看报纸，听听新闻，了解每日时事，关心国计民生。站立会议有助于Scrum Master以及整个团队了解项目进展情况，以便于控制项目进度，掌握团队成员的开发效率，促进成员之间的交流与沟通，并使所有成员对整个项目能有一个全面的认识。
站立会议的重要性不言而喻。如何遵循Scrum的原则开展好每天的站立会议呢？我在推行的Scrum实践中，发现站立会议总是会随着项目的进展，慢慢地发生变形，最后甚至会变得物事人非。幸运的是，每日的会议却没有理由地达成了Scrum的目的。那么，在Scrum开展站立会议是否一定要极为死板地遵循Scrum的原则？我认为未必。以下是我在推行Scrum过程中的一些粗浅认识。
全文阅读>>
