幻灯片文档是幻灯片和文档的混合体。其理念是，您可以使用同一份幻灯片来进行演示，并在演示结束后将其作为讲义供人们阅读。问题是，这两种需求对幻灯片的要求截然不同，因此您无法同时满足它们。结果是，幻灯片文档通常无法同时满足这两种需求。

我们对持续交付进行了一个小时的概述。主题包括持续交付的理由、部署流水线、持续集成、DevOps 和部署策略。其中最精彩的是 Jez 将候选版本拟人化为希腊神话中的英雄。

几个月前，我收到了一台新的公司笔记本电脑——一台配备 Thunderbolt 接口的 Macbook Pro。我拿到它后，就开始漫不经心地考虑买一台 Thunderbolt 显示器。我听说过苹果显示器的好评，尽管它们价格昂贵，而且可以充当扩展坞的显示器也很吸引人。

2006 年，我的同事 Neal Ford 提出了“多语言编程”一词，以表达应用程序应该用多种语言编写，以利用不同语言适合解决不同问题的优势。复杂的应用程序结合了不同类型的问题，因此为工作选择合适的语言可能比试图将所有方面都纳入单一语言更有效率。

在过去的几年里，人们对新语言，尤其是函数式语言的兴趣激增，我经常忍不住想花时间钻研 Clojure、Scala、Erlang 等语言。但我的时间有限，我将优先考虑另一个更重要的转变，即“数据库解冻”。第一批客户和其他联系人已经开始出现这种情况，前景十分诱人。我可以自信地说，如果您要开始开发新的战略性企业应用程序，就不应该再假设您的持久化应该是关系型的。关系型数据库可能是正确的选择，但您应该认真考虑其他选择。

软件的好处之一是人们似乎想要它，而且想要得很快。组织通常会要求团队加快软件的生产速度，而且组织会不时地寻求以真正体现其承诺的方式提供帮助——花钱为团队增加人手。

从我开始谈论和撰写有关重构的文章之初，人们就问我应该如何将其纳入更广泛的软件开发流程中。软件开发生命周期中是否应该有重构阶段？迭代中应该有多少比例专门用于重构任务？我们应该如何确定谁应该负责重构工作？虽然有些地方需要进行一些计划内的重构工作，但我更倾向于鼓励将重构作为一种机会主义活动，在任何需要清理代码的时间和地点进行，由任何需要的人进行。

goto（前身为 JAOO）长期以来一直是我最喜欢的会议。多年来，他们在保持高质量内容的同时，还进行了高效而友好的组织工作。因此，虽然我过度参加会议通常会导致我害怕会议，但在前往奥胡斯进行 somewhat 复杂的旅程时，我仍然感到一种愉快的期待。

制作和编辑视频曾经是一项昂贵的活动，但现在摄像机和编辑软件都很便宜。因此，许多像我这样夸夸其谈的人开始制作视频来传播他们的想法。这样做有很多原因，这是一种具有很多可能性的媒介，它适合像我这样在舞台上讲话很好的人，而且有充分的证据表明人们愿意为视频付费——这对一个人的收入和证明人们认真对待它都有好处。尽管有这些原因，但我至今还没有迈出这一步。

不久前，我和辛迪以及几位邻居开始了一项漫长的探索，谁知道我们什么时候才能完成。我们的目标是观看莎士比亚的每一部戏剧，以每一种合理可用的视频版本。这很有趣，尽管我们无法涵盖我们想看的所有内容，因为我经常旅行。我们按照大致的时间顺序观看，刚刚看完了《仲夏夜之梦》。

当人们开始开发企业应用程序时，最早的问题之一是“我们如何与数据库对话”。如今，他们可能会问一个稍微不同的问题：“我们应该使用哪种数据库——关系型数据库还是这些 NoSQL 数据库中的一种？”但还有另一个问题需要考虑：“我们是否应该使用数据库？”

在我们撰写敏捷宣言 10 年后，我们这些作者受邀参加了 Agile 2011 大会期间举行的一场特别活动，以庆祝这一周年纪念日。17 位作者中有 15 位出席了会议，我们举办了一场公园长椅小组讨论会，回答了观众的提问和评论。我认为我们都对再次见面感到惊讶，也对我们如此轻易地恢复到舒适的合作和讨论状态感到惊讶。我们的讨论内容包括敏捷宣言的撰写背景、回顾过去十年中我们感到满意和不满的事情、敏捷的未来发展以及敏捷与精益之间的关系。

我认为，在我认识的软件开发领域的人中，几乎每个人都对专利及其在我们领域的使用方式深恶痛绝。我的待办事项清单上很久以前就有一篇关于这个主题的文章，在听了《美国生活》一篇特别棒的调查性新闻报道后，我终于决定动笔写这篇文章。简而言之，虽然专利（甚至是软件专利）在原则上是个好主意，但在实践中，它们已经变成了一场彻头彻尾的灾难，最好废除。

几周前，一位朋友问我推荐什么播客。我花了一段时间才想好答案，但我认为这是一个好机会，可以推荐我喜欢听的内容。

那些听过我和我的同事谈论功能分支的人都知道，我们不是这种模式的忠实粉丝。我们反对的一个重要原因是，我们观察到分支很容易，但合并却很难。我们不时听到的一种说法是，现代版本控制工具使合并变得足够容易，因此功能分支是值得的。

我最近一直在研究 JavaScript，令我震惊的一件事是，人们习惯于对 getter 和 setter 使用相同的函数名。因此，如果您想在 jQuery 中查找横幅的高度，可以使用 $("#banner").height()，如果您想更改高度，可以使用 $("#banner").height(100)。

我对这种约定很熟悉，因为它在 Smalltalk 中使用。您可以使用 banner height 获取值，并使用 banner height: 100 更改值。知道这是一种 Smalltalk 约定就足以让我喜欢它，因为我对这种语言有着遥远而持久的热爱。但即使是最好的东西也有缺陷，我无法掩饰我对这种编码风格的厌恶。

我最喜欢的一句妙语是：如果它让你感到痛苦，就更频繁地去做它。它有一个令人愉快的特点，那就是表面上看起来毫无意义，但当你深入挖掘时，它会产生一些有价值的意义

CQRS 代表命令查询职责分离。这是我第一次听到 Greg Young 描述的一种模式。它的核心是，您可以使用与读取信息所用模型不同的模型来更新信息。在某些情况下，这种分离可能很有价值，但要注意，对于大多数系统来说，CQRS 会增加风险复杂性。

最近，通过博客、推文或互联网上的其他信息，我看到了 Andrew Abela 撰写的关于极限演示的免费书籍《演示文稿》。这是一本简短易懂的书，概述了一种特定的演示风格。我喜欢他概述的方法。如果您对演示技巧感兴趣，尤其是如果您要进行演示以说服一小群人采取行动，那么我认为这本书值得一读。

LMAX 是一个全新的零售金融交易平台。因此，它必须以低延迟处理大量交易。该系统构建在 JVM 平台之上，核心是一个业务逻辑处理器，可以在单个线程上每秒处理 600 万个订单。业务逻辑处理器完全使用事件溯源在内存中运行。业务逻辑处理器被 Disruptors 包围 - Disruptors 是一个并发组件，它实现了一个无需锁即可运行的队列网络。在设计过程中，团队得出结论，使用队列的高性能并发模型的最新方向与现代 CPU 设计根本不一致。

有一段时间，我一直对我的 数码单反相机 的镜头设置感到满意：适马 18-200 作为通用相机镜头，佳能 10-22 用于广角拍摄，佳能 50 f1.8 和 100 f2 用于弱光人像和窄景深拍摄。这是一套很好的设置，帮助我拍摄了许多我喜欢的照片。

但是，像我这样的大多数痴迷的业余爱好者都知道，总是渴望拥有更好的设备。我听说像 18-200 这样的消费级镜头不如更好的镜头清晰，我可以获得自动对焦更快、更安静的镜头，也许我的长焦镜头比我认为的要软一些？

我不够酷，没有收到第一波邀请，但我现在已经加入了 Google+，这可能是社交网络的下一个大事件。通过写一点关于我迄今为止如何使用社交网络，以及对 Google+ 影响的一些未经证实的猜测，来纪念这一重要时刻似乎是合适的。

IT 部门中的一个常见问题是，是通过构建定制软件还是购买软件包来提供功能。自从我开始编程以来，关于如何做出选择的争论就一直在激烈进行。我在这方面的基本立场是基于 实用与战略二分法。归根结底，这意味着，如果您所支持的业务流程是您竞争优势的一部分，那么您应该构建定制软件；如果不是，则应该购买软件包并调整您的业务流程以适应软件包的工作方式。

尽管我的观点非常出色，但似乎没有多少公司这样做。他们经常忽略这种二分法，这是一个问题。但我在这里想要关注的问题是他们在购买软件包时常见的陷阱。

在这段视频（12 分钟）中，Mike Mason 和我谈论了 功能分支 及其替代方案的弊端。

我最近决定升级我的家庭 媒体服务器，并购买了一台 惠普 N36L。到目前为止，我对它很满意。

标志参数是一种函数参数，它告诉函数根据其值执行不同的操作。假设我们要预订音乐会门票。有两种方式可以做到这一点：普通和高级。要在这里使用标志参数，我们将得到一个方法声明，如下所示

三个演讲部分：测试中的非确定性、软件开发的经济学、敏捷宣言发布 10 年。

人们的演示文稿中常见的一个问题是，他们将文本和图表做得太小，以至于只有坐在房间前面的人才能清楚地看到它们。为了减少这种情况发生在我身上的几率，我做了一件简单的事情 - 当我撰写演示文稿时，我将视图大小设置为 50%。如果我在 50% 的情况下无法轻松阅读，那么观众也会很吃力。

Thoughtworks 是一家非同寻常的公司，这就是为什么像我这样怀疑企业的人在这里待了十年。Thoughtworks 的一个重要特征是，我们对自身目标的看法比单纯的商业实体更广泛。在过去的几年里，我们一直使用三支柱模型来描述我们喜欢看待自己的方式。

使用 Web 服务的好处之一是，它可以帮助您解耦系统的各个部分。人们可以在一定程度上分离的情况下处理不同的代码库。虽然您获得了一定的解耦，但您不能完全消除耦合，因为服务仍然必须通过其接口相互通信。可悲的是，许多团队使这种耦合比应有的程度更糟糕。

我拥有第一台电子书阅读器才一年多一点。现在，只有在不得已的情况下，我才会购买纸质书。我写上一本书的时候，主要是把它当作一本纸质书来写的，但这将是最后一次了，在未来，电子版将是我的首选。这些变化将彻底改变书籍的面貌，但除此之外，下一步该怎么做还不清楚。

SD Times 对敏捷宣言发布 10 周年的采访

PowerPoint 不是在中世纪发明的，当时骑士们身穿盔甲在战场上冲锋陷阵。但今天的幻灯片与那些古代骑士有一个共同的特点。两者都需要能够从远处清楚地区分符号。我们可能没有泥浆和灰尘，但许多投影仪在对比度方面并不是很好。

随着如此多的移动平台的兴起，每个平台都有不同的用户界面，许多人都在关注跨平台工具包。这些工具包允许您编写一次移动应用程序，然后将其部署到各种移动设备上。这些工具包值得使用吗？

昨天，我查看了一个代码库，查看了代码的领域模型部分。在浏览代码库时，我喜欢做笔记，以帮助我记住我学到的东西。对于某些代码库，特别是领域模型，我发现绘制 UML 类图很方便。

演示出错的可能性与受众的重要性成正比。

模块提供的所有服务都应该通过统一的符号来访问，而不能暴露它们是通过存储还是计算来实现的。

-- Bertrand Meyer

Bertrand Meyer 在他极具影响力的著作 面向对象软件构造 中提出了这一原则。

该原则的要点是，如果您有一个 person 对象，并且您询问它的年龄，那么无论年龄是对象的存储字段还是计算值，您都应该使用相同的符号。这实际上意味着 person 的客户端既不应该知道也不应该关心年龄是存储的还是计算的。

我们最近在南部城市萨凡纳和查尔斯顿度假了一周。我听说过这两个城市在美丽和历史名胜方面的优点 - 我可以证实这些优点。这两个城市都值得花几天时间四处游览。

自动化回归测试套件在软件项目中可以发挥至关重要的作用，它不仅对减少生产中的缺陷很有价值，而且对演进式设计也至关重要。在与开发团队的交谈中，我经常听到关于非确定性测试的问题 - 有时通过而有时失败的测试。如果不加以控制，非确定性测试会彻底破坏自动化回归测试套件的价值。在本文中，我将概述如何处理非确定性测试。最初，隔离有助于减少它们对其他测试的损害，但您仍然需要尽快修复它们。因此，我将讨论非确定性的常见原因的处理方法：缺乏隔离、异步行为、远程服务、时间和资源泄漏。

有时我会被介绍为“敏捷宣言的签署人”。通常，他们的意思是我是 敏捷软件开发宣言 的作者之一，因此也是其最初的签署人之一。但实际上，签署人远不止 17 位作者，我上次查看时，数量已经达到 10,104 人。如果您愿意，也可以加入该名单。

许多程序都需要使用创建和维护成本高昂的资源。数据库连接和线程就是例子。资源池提供了一种管理这些资源的好方法。

我的大多数朋友和同事都对软件开发中的认证计划持非常负面的态度，我也有同样的蔑视。这并不意味着我认为软件认证本质上是坏的，只是我们看到的几乎所有认证都未能通过一项基本测试。

我最近决定升级我们的家庭服务器设置。我在这里发布了一些关于我打算做什么的想法，现在我已经用我所做的更新了这个页面。

当我第一次改用 数码单反相机 时，我特意买了一台比较便宜的相机 - 佳能 Rebel XTi/400D。我这样做部分原因是为了把更多的钱花在镜头上，但也因为我知道技术会进步，几年后我会考虑更换机身。

我经常遇到一些沮丧的开发人员，他们抱怨“管理层只想要更多功能，根本不关心质量”。每当听到这种话，我都会感到难过，因为我知道开发人员、管理层和他们的客户都已经失败了。他们的失败是由于将这种情况框定在*可交易质量假设*的框架内造成的。

我使用*皮下测试*来表示在应用程序用户界面下方运行的测试。这在对应用程序进行功能测试时特别有用：当您想要测试端到端行为，但很难通过用户界面本身进行测试时。

Daniel Terhorst-North 最近发表的关于软件工艺的博文引发了许多博客讨论（如果您感兴趣，我在下面进行了总结）。内容非常丰富，但其中一个主题特别引起了我的共鸣，因此有了这篇文章。

我经常听到这样的说法：某些技术将允许用户编写自己的软件，而不再需要程序员。每当听到这种说法，我都会想起 COBOL 的目标也是如此——我们都知道结果如何。

使用测试替身最常见的情况之一是与外部服务通信时。通常，此类服务由不同的团队维护，它们可能会受到网络缓慢、不可靠以及自身不可靠的影响。这就是测试替身很方便的原因，它可以防止您自己的测试变得缓慢且不可靠。但是，针对替身进行测试总是会引发这样的问题：替身是否确实准确地表示了外部服务，以及如果外部服务更改了其契约会发生什么？

此网站的大部分内容，包括此博客，都是使用 XML 到 HTML 的转换过程构建的。我用自己的 XML 词汇编写文章和博客条目，然后将这些源代码转换为您正在阅读的 HTML。当我回到 2000 年开始做这件事时，我使用的是 XSLT。虽然我非常擅长使用 XSLT 编程，但我得出的结论是，我还没有自虐到想要继续使用它的地步。在一次短暂的实验中，我在飞往班加罗尔的航班上用 Ruby 编写了博客转换器，之后我切换到使用 REXML 库的 Ruby。现在是时候将核心库更改为 Nokogiri 了。

在印度期间，我们在安达曼群岛度过了一周的假期，主要是为了潜水。我们大部分时间都在哈夫洛克岛度过，从布莱尔港的主要中心乘坐渡轮需要几个小时。以下是一些我们经历中可以分享的内容。