
Ruby的开放类──或者:怎样避免动态打补丁
Ruby的开放类(Open Classes)功能强大,但很容易被误用。这篇文章关注于怎样减少使用开放类的风险,介绍了一些其他可替代的类似方法,并分析了其他语言如何实现类似的功能。

Ruby的开放类(Open Classes)功能强大,但很容易被误用。这篇文章关注于怎样减少使用开放类的风险,介绍了一些其他可替代的类似方法,并分析了其他语言如何实现类似的功能。
ODBMS.ORG在为教员、学员、专业人士,以及开源参与者提供的资源收集里面新增了持久化模式,该领域最初的资源由三个模式合集组成。网站将对2009年5月29日之前提交的模式评选出最佳持久化模式奖。
除了决定要用敏捷并为培训买单之外,接下来执行层的工作还有不少。要想让这个改造成功,执行层必须要一直提供支持。Esther Derby从在这些支持中选出了三项她觉得最重要的工作。
处于分布式环境之中,敏捷的采纳和执行就变得更为困难。由于地理位置分离、时区不同、文化差异等原因,分布式敏捷面临自己独有的问题。干掉一个分布式敏捷项目并不难。
Christian Gruber就TDD的代码覆盖率度量方面阐明了其态度。他谈到了代码覆盖率度量会告诉你什么以及不会告诉你什么,TDD是如何适应它的,同时还提到了我们如何能更好地使用代码覆盖率度量。

在本文中,Stefan Tilkov讲解了一些经常出现在自称“符合REST式设计”的应用中的反模式(比如:全部采用GET或POST,忽视缓存及响应代码,误用cookies,忘记超媒体与MIME类型,以及破坏自描述性等),并给出了避免这些反模式的对策。

Scrum中,产品负责人这个角色具有很大的影响力,能够带来很高的价值。但要想运用得当,可没那么轻而易举。成功的运作可以在客户/产品管理和开发者之间建立起全新而融洽的关系,甚至能够增加竞争优势。不过天下没有免费的午餐:为了发挥其作用,组织要经常要做出有针对性的调整。在这篇文章中,Roman Pichler将介绍成功的产品负责人需要具备的条件。
从琐碎小事到人间惨剧,每天我们都面临着误解带来的后果。在本文中,J. B. Rainsberger与我们分享了他的一个独门秘籍——萨提亚沟通模型。这是一个帮助我们分析沟通问题的思维工具,经过训练后我们可以更深入地理解我们周围的人,建立信任,迈开构建有效团队的第一步。

采用敏捷方法学的人越来越多,但是这也带来了新的挑战:当团队只是简单的把敏捷实践拷贝到项目中而不是在实践中逐步掌握,没有理解就直接加以实现,这又怎么谈得上敏捷呢?也许是时候该讨论一下如果没有正确的教授一些基本知识会对团队最重要的资产——诚实,守诺以及客户的信任——带来怎样的负面影响了。