qcon_从QCon伦敦2009中学到的主要知识点和教训

qcon

第六届QCon 大会（伦敦第三届年度大会 ）于今年3月举行，参加人数超过500人，比前一年略有下降，但考虑到经济环境，其表现仍然强劲。 在本文中，我们介绍了许多博客上 有关 QCon的博客的观点和观点，以便您可以体会QCon London的印象和经历。 您还可以在Flickr上看到众多与会者拍摄的QCon照片，以及通过Twitter发布有关QCon的数千条推文 。

QCon与众不同之处在于，它是由技术人员领导，架构师和项目管理人员共同参加的，由实践者主持的深入会议。 这次会议不仅提供及时的主题，还提供背景和观点：针对全面的软件工匠。 49％的参与者来自英国，37％的客户来自西欧，全球范围的14％。 在QCon旧金山举行的100多位演讲者中，包括Martin Fowler，Quicksort发明家和图灵奖获得者Tony Hoare，Erlang创作者Joe Armstrong，Spring创作者Rod Johnson等。 QCon将继续在每年的3月在英国运行， QCon San Francisco将在2009年11月再次运行， QCon Beijing和QCon Tokyo也刚刚运行。

目录

讲解
* 回顾展
* GET Connected：基于Web的集成教程
* 影响力策略
* 高级Ruby
* 美学编程
* 行为驱动的开发：编写重要的软件

主题演讲
* Tony Hoare爵士：计算科学与软件工程
* Zack Exley和Martin Fowler：民主政治技术革命
* Dion Hinchcliffe：以网络为平台的软件架构转型
* 游戏节目：这是靶心！ 与吉姆·韦伯

面试
* Scala和Lift
* FIT，TDD和敏捷
* REST for SOA：使用Web进行集成

网络平台
* 网络平台
* 云数据持久性
* 情况正常，一切都必须改变

企业中新兴的语言
* 实用的真实Scala
* Clojure
* 三年的现实世界Ruby
* 企业中JavaScript

六便士-敏捷开发的技术技能
* 您可以从这里到达那里：采用敏捷比您想要的难，但是比您想像的要容易
* 小型编程
* 测试驱动的开发：十年后
* 六便士-没有借口：每周兑现的概念
* 战es中的CI：现实世界中的持续集成挑战（以及应对措施）

真实世界的SOA
* 指导西北通道：开始实施SOA计划
* 用于金融业务服务的基于REST的集成体系结构

金融应用架构
* 行动中的AMQP
* 改变对帐流程

解决方案跟踪：性能和可伸缩性跟踪
* 为性能和可伸缩性进行架构设计：小组讨论
* 建立性能和可伸缩性：如何将性能管理集成到您的开发过程中
* 开放标准制定：机遇还是约束？

您一直想知道的架构
* 不断发展的Guardian.co.uk架构
* 开拓进取-将BBC扩展到Web / 2.0

敏捷的组织模式
* 敏捷性：在个人层面上的可能性
* 指导自组织团队

应用功能和并行编程语言
* 与Microsoft F＃并发编程
* 提升网络框架
* 永久数据结构和托管参考
* Erlang中的多核编程

领域驱动的设计与开发
* 从本书开始，我对DDD的了解
* 用DDD重建guardian.co.uk
* 价值的力量-域驱动设计中价值对象的力量使用

Java.Next-塑造Java未来的关键技术
* 适用于应用程序开发人员的Java模块化和OSGi
* 春天今天和明天

建筑师的体系结构
* 皮条客我的体系结构
* 关于通用与特定权衡的思考
* 战略设计
* 软件架构师的五个注意事项

历史上的坏主意
* 空引用：十亿美元的错误
* 标准很棒，但是标准化是个坏主意

永不停止的系统
* Erlang：一种用于对可靠系统进行编程的语言
* 改善Twitter上的运行组件

供应商

社会事件
* 云营

关于QCon本身的意见

外卖

结论

讲解

回顾展

Sam Aaron喜欢这个教程：

早上我参加了琳达·瑞辛（Linda Rising）的回顾教程。 琳达温柔而贴心的演讲风格非常适合传达如此精致的素材。 如果您有机会见到她，那么我强烈推荐您。 琳达有许多关键信息，我将在这里总结：

• 公司使用的迭代次数越来越小（例如，亚马逊有一天的迭代次数）
• 公司的回顾展也较小（2-3小时）
• 我们应该不断地测试知识-即在每次迭代的末尾而不是项目
• 经验提供数据而非知识
• 每次迭代应进行约3项具体更改（更多更改往往影响较小）
• 通常，人们有感觉和想法，但在正常的业务过程中没有表达它们的地方
• 回顾展是一个您可以谈论通常没有机会谈论的事情的地方
• 回顾有助于通过“全团队”反思来创建社区
• 通过驱使人们不希望参加会议的人员来创造安全感，以鼓励进行更开放和流畅的讨论
• 使用团队创建的迭代时间表作为讨论的媒介
• 提供赞赏

GET Connected：基于Web的集成教程

Ola Bini参加了本教程：

在星期一，我参加了Jim Webbers的名为GET connect的教程，该教程讨论了使用Web进行分发和分离功能的不同方式，其中REST风格的SOA是其中的一部分，还包括POX等其他东西。 这是一个非常丰富的信息会议，最后，Jim必须跳过一些我个人想了解的更多事情，例如处理安全性的不同方法等等。 归根结底，这是一个很好的教程，但是对于一天半的时间来说，材料确实太多了。

格伦·福特也出席了会议：

第一个教程是与Jim Webber一起使用Web作为集成平台的。 吉姆一如既往地自嘲，使事情变得轻松愉快。 （我认识吉姆已经有一段时间了，我给他起了个绰号叫安格里先生，而他给我起了绰号格鲁比先生-但这就是另一篇文章）

这实际上是一个很棒的会议，我唯一的失望是这不是一整天，因为肯定有足够的材料，吉姆不得不跳过最后三分之一到最重要的要点。 不过，对我来说，演示文稿特别好，因为它使我有机会思考一下利用Web的真正含义-还为我提供了一些一些想法，可以通过使用ATOMpub处理某些事件来解决当前问题。

影响策略

Martin Kneissl在这个会议上喜欢：

第一个教程是Linda Rising撰写的“影响力策略”。 本教程很棒：科学背景，实用的日常背景的完美结合，同时也充满了温暖和幽默。 本教程中讲授的技术非常适用，请当心！ 我可能会开始在您身上使用它们...

高级Ruby

格伦·福特（Glen Ford）上了本教程：由于我的Ruby知识非常有限（即仅略高于零），我认为选择上高级Ruby的教程有点雄心勃勃。 但是事实证明它非常好并且很有见地。 这是我第一次去语言教程，无论如何语法都不会陷入困境。 本教程从不同的编码方法（例如原型，基于类和功能）的角度介绍了该语言。 了解Ruby如何处理继承，闭包，在现有类上创建方法，检测丢失的方法等非常有用。它还为我提供了一个思考我使用的其他语言并更好地理解它们的机会。 Sam Aaron还讨论了他对本教程的看法：

在Ruby教程中，我对概念进行了高层次的概述，我相信这些概念是您可能偶然发现的大多数不错的Ruby代码的核心。 目的是避免语法，以便尽可能多地打包概念，这是我肯定会再次使用的技术。 奥拉·比尼（Ola Bini）参加了会议，并建议我可以改善涉及函数式编程的教程方面。 我完全同意可以更详细地处理这些概念，但是，大多数与会者之前没有使用闭包或块，因此我将更多精力放在介绍它们上。 希望随着越来越多的人接触到功能语言（今年QCon计划的主要力量），闭包之类的概念将与类和对象之类的概念一样明显和被理解。

审美编程

Sam Aaron在他的教程中谈到了他的想法：

下午，我做了一个非常开放的基于对话的编程语言美学教程。 我将沟通定为应用美感或美感的基础。 尽管可以说某种给定的编程语言很美很有价值，但我认为，辩论给定的某种编程语言传达信息的方式会更有用。 因此，这引入了通常可以忽略的关键因素：上下文，视角，受众和意图。 另外，作为对美学框架的一般介绍，我们都讨论了现代主义和Wabi-Sabi（两个明显不同的框架）之间的差异。 本质上，我试图传达的关键信息是，我相信概念效率至少与计算效率同样重要。 总而言之，呈现并参与其中非常有趣。

行为驱动的开发：编写重要的软件

格伦·福特（Glen Ford）非常喜欢：

这是我真的很期待的会议，Dan并不失望，他对这些东西的热情和活力真正体现了出来。 听到他对敏捷如何超越XP等事物的看法感到很有趣-我认为它在某种程度上变得更加务实和经验丰富，这确实让我思考如何超越TDD或他正确地指出了“示例代码” ”。

会议中提供了大量信息，非常吸引人。 回顾一下为什么我们在小团队中表现良好的理由真是太好了（我们的大脑很难在最多10人的小组中良好地工作-也许是史前家庭小组规模？）。 讨论诸如为何难以引入变更以及如何减少退回“旧方法”的可能性等话题也很有益。

试图总结Dan几乎是不可能的，如果有机会的话，值得听他谈这个话题。

主题演讲

Tony Hoare爵士：计算科学与软件工程

许多人谈论了这个主题演讲，包括Ulf Wiger ：

听查尔斯·安东尼·安东尼·霍尔爵士很高兴。 我是Hoare的忠实粉丝，并热烈推荐他的图灵奖演讲“皇帝的旧衣服” 。 那里有一些很棒的教训。

佩德罗·皮门特尔 （ Pedro Pimentel） ：

奇怪的是，伦敦Qcon的开场演讲来自科学家Tony Hoare （Quicksort的发明者），但他并未让我入睡。 Hoare谈到了学术实践和商业世界之间的分歧，并就“我是科学家，我是工程师”这个世界进行了许多比较和小笑话。

亚历克斯·斯考德利斯 （ Alex Scordellis） ：

首先是Tony Hoare爵士 。 没有计算机科学的背景，我没有房间一半的恐惧感。 他在软件工程（实用，寻求可靠性，短期观点）与计算机科学（完美主义者，寻求正确性，长期观点）之间进行了一些比较，这在很大程度上没有争议。 最后，事情变得有些有趣，他说了自己的看法：“有一天，软件将成为包含该产品的每个产品中最可靠的组件……因为编程科学与工程学研究的成功相互作用软件”，然后提出一些有趣的问题。 看来他将完整的规范视为测试的极限。 我离开时认为，重要的是让计算机科学家研究新的方法以使我们确定计算机软件的行为，并让软件工程师务实地决定哪些方法有用，什么剂量。 我不确定这是否会让我们回到托尼爵士的视野。

埃里克·约翰逊 （ Erik Johnson） ：

Anneke Kleppe在《 软件语言工程》的序言中写道：“学术计算机科学正处于逐渐成为研究行业进步的经验领域的危险中”。 Web编程作为基本平台，开源和云计算运动已使软件生产民主化。 变革的发生速度比大多数学者和供应商能够跟上的要快-更不用说试图领导了。
[...]
QCon的门徒是Kleppe陈述的缩影，绕过了从计算机科学到工具包厂商，应用程序厂商再到用户的古老瀑布。 因此，对我来说，QCon的最大好处实际上是一位计算机科学学者，这有点讽刺。 图灵奖获得者Tony Hoare爵士发明了Quicksort（woo-hoo！）和NULL参考（doh！），并发表了杰出的主题演讲，将计算机科学与工程技术进行了对比。 他说，科学家追求一个伟大的故事，而工程师追求许多伟大的小故事。 让科学家在工程师创造可靠性的同时寻求正确性。 他期待有一天出现问题时，该软件将是最后一个可疑的原因。

马丁·克尼瑟 （ Martin Kneissl） ：

Tony Hoare在开幕式主题演讲中谈到了（计算机）科学家与工程师之间的频谱。 他强调了双方的不同目标和方法，以及双方进行交流以相互受益的重要性。 有趣的是，他提出主题的方式几乎与我昨天参加的Sam Aaron的研讨会相同。 当Sam试图在“现代主义”和“ wabi-sabi”之间分化时，Tony Hoare在“现代主义”（对于科学家）和“后现代主义”（对于工程师）之间进行了区分。

Tony的主题之一就是必须有正式的程序规范才能谈论程序的正确性，当然引起了关于如何实现正式规范的讨论。 一位与会人员建议使用测试驱动的开发作为形式化需求的方法，Tony Hoare以某种方式表示同意。

格伦·福特 ：

计算机科学与软件工程的对比-对我而言，这非常有趣，因为我经常在内部（有时是外部）就我的工作是否真正是工程学展开辩论。 我拥有电子工程学位，但是我一直在系统或软件领域工作。 我们所做的很多事情都可以被视为Craft.io-很高兴听到Tony说这是工程学早期生命周期的一部分。

太多的信息无法囊括，如果您有兴趣，我知道它会在不久的将来在QCon网站上发布。

Gojko Adzic ：

在主题演讲中，他解决了软件开发社区中不断出现的两个问题：计算是一门科学，软件是一门工程学科吗？

霍尔（Hoare）辩称，两个答案必须相同-如果其中一个答案正确，则另一个答案也必须相同。 他继续说，软件之所以在工程上完全是因为它利用了计算科学的成果。 同样，计算是一门科学，正是因为它的结果已被软件工程开发和证实。

奥拉·比尼 （ Ola Bini） ：

正确的QCon会议的第一天开始时，Tony Hoare爵士就计算科学与工程学之间的区别和重叠进行了主题演讲。 相当有趣，但是问题和答案却是有趣得多的东西。 Hoare提出的更有趣的观点之一是，在他看来，完整的规范是对测试的概括。

马克·埃丁顿 （ Mark Edgington） ：

是计算科学吗？ 是软件工程吗？ 托尼·霍尔 （ Tony Hoare）认为答案必须相同！

在极端情况下：

科学家

• 科学家对没有有限寿命的长期科学真理感兴趣。
• 理想主义，一般性理论和确定性（由多个证据支持的理论）
• 将工作分解成可以制定的单独元素
• 独创性和完美导致名望回报

工程师

• 工程师的工作时间固定，预算也可能固定，通常使用寿命有限。
• 妥协，基于风险管理所管理的特定情况
• 整合往往依赖经验和直觉的各种元素
• 最佳实践和充足的交付可带来经济利益

那么为什么要计算科学呢？

和克里斯·里默 （ Chris Rimmer） ：

这是关于计算机科学家和软件工程师之间差异的讨论。 他将前者描述为考虑一般性和长期性的理想主义者，而后者则是通常考虑短期性的实用主义者和专家。 这是一次哲学性的演讲，自从我进入后一个阵营以来，我希望可以拿走更具体的东西。 对于计算机科学可以为实践工程师提供什么，他似乎非常乐观。 实际上，他的报价是：

有一天，软件将成为包含该软件的所有系统中最可靠的组件。

尽管我的一位同事打趣说这只会因为引入了可靠性较差的组件而发生，但我们仍不清楚如何达到这一点。

Zack Exley和Martin Fowler：民主政治技术革命

Danny Lagrouw喜欢这个主题演讲：

[...]我唯一一次看到福勒在行动中（在白鹿特酒馆外面）是在演示奥巴马总统竞选所使用的软件，他与扎克·埃克利（Zack Exley）一起交付了该软件。 在一个鼓舞人心的演讲中（还考虑了聚会前一天的时间，星期三下午），他们讨论了ThoughtWorks如何将现有软件和新软件集成到一个可靠的运行系统中，该系统用于管理竞选工作者和志愿者。 福勒不愿透露这是否赢得了奥巴马的选举，但是很明显，奥巴马像在他之前一样没有候选人就利用了互联网。

正如马丁·克奈斯 （ Martin Kneissl）一样 ：

（他们）介绍了他们如何通过为支持者和志愿者提供IT服务来支持巴拉克·奥巴马的竞选活动。 我从美国选举制度中学到了很多东西，这与我们在德国的选举制度有很大不同（真的那么不同吗？必须考虑一下……）。 我想知道我是否喜欢这样的想法，即如果当事方是否雇用擅长创建网站的人员，将对它产生多大的影响？ 但这显然是政治运作方式的一方面。

Dion Hinchcliffe：以网络为平台的软件架构转型

包括Chris Rimmer在内的多人讨论了此演示文稿：

本主题演讲的主题是不断变化的应用程序开发格局以及云计算如何对其产生影响。 主要的兴趣点是，即使云计算可能意味着供应商必须锁定其丑陋的头颅，但成本优势仍将使其很难忽略。 他在ZDNet的博客中有很多相同的东西 。

佩德罗·皮门特尔 （ Pedro Pimentel） ：

Dion Hinchcliffe撰写的 “面向Web的体系结构”和他的另一篇演讲“以Web为平台转换软件体系结构”预测，显而易见的是，大多数应用程序将基于Web和面向Web，并且仍然遵循“始终beta”的哲学，因为“最好的产品永远不会完成”。 根据Dion所说，面向Web的体系结构强烈地基于REST，加上对mashup，集成和小部件的使用。 Dion说我们缺少应用程序的可移植性，因此他认为通过使用OPML交换数据，我们将以正确的方式适应面向Web的体系结构。

Gojko Adzic ：

Hinchcliffe首先说：“没有任何小系统就可以与更大的系统保持持续的联系，而无需从根本上改变”，并指出，既然Web现在比企业系统大得多，它对企业体系结构将产生重大影响。

Hinchcliffe引用Dare Obasanjo的话说：“我的网站比您的企业还大。” 最大的IT中心不在企业中，它们是网站。 如今，Web是一个比任何操作系统都要强大的软件平台，拥有50亿台主机，并且“拥有所有客户，所有竞争对手以及所有创意和创新”。 但是，辛奇克利夫（Hinchcliffe）认为“只有少数经过验证的长期竞争优势战略”，而社区直到现在才知道如何使用它。

马克·埃丁顿 （ Mark Edgington） ：

现在我们看到，没有任何小型系统可以经受住与大型系统的持续接触而无需更改。 通过迁移到SOA可以将其放大，但是这些原则确实存在复杂性问题-需要遵循许多框架。ÃREST已部分解决了复杂性，而REST是新首字母缩写WOA（面向Web的体系结构）的核心），但仍有路要走。 实际上，需要更新软件体系结构以反映我们现在的状况。 在网络奇异的时代，所有事物都是相连的。 而不是拥有最大系统的企业：

“我的网站比您的企业大”，企业中不再有最大的应用程序，例如Google，MySpace，Facebook，Amazon ...

格伦·福特 ：

这是上午的主题演讲。 它表现得很好，但是主要是一种“国家状态”的演讲。 对我来说，一些有趣的观点包括，出于各种原因，如何围绕您的站点/产品建立社交网络是非常有效和有益的，包括几乎将一些产品支持和测试转移给了该社区。

狄翁介绍了最大的技术公司如何成为硬件，然后发展为软件，现在是数据公司。 他提到台式机是我们拥有“商业软件”的最后领域之一，我认为这有些微了，我认为Open Source取得了长足的进步，并且在该领域一直在取得更多进步-我认为这是由于iTunes AppStore之类的优势，移动桌面现已成为商业软件的最佳选择。

他还介绍了云计算以及他如何感觉到我们有可能陷入我们相信数据的极少数大型参与者的风险中。

游戏节目：这是一个靶心！ 与吉姆·韦伯

Steve Vinoski喜欢这个小组：

最终的会议小组是迄今为止我参加过的最具创造力的小组。 以英国游戏节目“这是一个靶心！”为蓝本。 由吉姆·韦伯 （ Jim Webber）主持的比赛，观众中的参赛者都投掷Dart，才有资格获奖。 参赛者一旦具备参赛资格，Jim便会要求小组成员-Michael Nygard ， Ian Robinson ， Martin Fowler和我-在会议开始时或通过Twitter直播回答与会人员提出的问题。 根据我们的答案，如果观众喜欢答案，则观众举起绿卡，如果不喜欢，则举起红色，如果大多数是绿色，则参赛者将赢得一本书。 问题很难！ 我们每个人只有两分钟的时间回答，对于某些问题来说这似乎是永恒的，但是对于大多数问题来说却太短了。 无论如何，这是非常有趣的事情，考虑到经过三天艰苦的会议，听众有多少人，以及他们似乎在享受着多少乐趣，所以它非常非常好。

和Ola Bini一样 ：

当天的活动以完全荒诞的Bullseye小组结束，我完全疯狂的同事Dan North和Jim Webber在Michael T Nygard，Ian Robinson，Martin Fowler和Steve Vinoski的小组中主持了一场比赛，将Dart和滑稽的问题结合在一起。 许多重要时刻甚至开始描述，但如果我不得不选择其中一个，那可能是伊恩·罗宾逊斯（Ian Robinsons）回答的问题，即哪种科技最不适合人类。 Ian的回答基本上是说问题不是男人的胸部，但他实际上不能足够近地接触到它们而没有很多衣服挡住。 那里有可爱的隐喻。

面试

斯卡拉和电梯

克里斯·里默 （ Chris Rimmer ）参加了这次采访：

这是对Lift框架制造商的采访，该框架是基于Scala的Web框架。 它已被拍摄，并应在适当的时候出现在InfoQ （会议的联合组织者）上。 他在这个框架上的推销在许多方面与Rails相似，因为Java框架倾向于承受过多的样板代码，因为不可能轻易地传递代码块。 在Ruby和Scala中，这是可能的，因此可以消除这种重复。 实际上，Lift最初是从Rails到Scala的港口开始的。 至少他没有称它为Scails！

Scala允许您使用类型推断来减少代码量。 但是，如果您希望记录所需的类型，也可以这样做。 他说，研究表明，每天在不同语言之间编写的代码行数差异很小。 这意味着我们应尽可能使用更具表现力的语言。

Lift本身使用了更多事件驱动的开发方式来避免HTTP请求/响应周期。 他将其描述为更像Visual Basic，在其中添加一个按钮，然后添加代码以处理被按下的按钮。

FIT，TDD和敏捷

马丁·克尼斯尔（Martin Kneissl）喜欢这次采访：

我偶然地参加了这次采访的录音，对此我感到很高兴。 在线观看视频时，他有很多话要说。 同时查看他的博客

REST for SOA：使用Web进行集成

Sebastien Auvray参加了这次采访：

为了完成最后一天，我决定参加Tony Hoare的访谈，以及另一篇有关REST for SOA：使用Web与Ian Robinson和Jim Webber 集成的访谈。 Ian和Jim除了是非常有魅力的人，还是非常务实的建筑师，Stefan向他们提出了完美的问题。

格伦·福特也出席了会议：

最后，我参加了Stefan对Ian Robinson和Jim Webber关于REST以及使用Web作为集成平台的采访。 很高兴听到他们对REST的看法以及将Web实用地用于机器-机器集成-我想很好，因为我同意他们的观点。

网络平台

网络平台

马克·埃丁顿（Mark Edgington ）详细介绍了此演讲的笔记，包括：

画布-HTML 5规范的一部分，使您可以在浏览器中获得惊人的图形和图像处理。 通过浏览器理解本机格式（例如视频），可以增强此功能。 为什么这比flash更好：

• 插件没有启动时间
• 今天可在手机上使用
• 排版（保真度）
• 无需桥接即可链接运行时，例如使用javascript和Flash时。
• 无需插件
• 尚未在IE中使用，但很典型，但可以使用一个插件使其正常工作； 尽管这带走了一些好处

本·加尔布雷思（Ben Galbraith）还解释了在演讲中看到的问题背后的原因：

迪翁和我本周在伦敦QCon的舞台上进行了Bespin演示。 在花了几分钟进行演示之后，强调了Bespin的执行速度，如何扩展到成千上万行，击败了基于DOM的编辑器方法（通常的说法是断言），我继续在键盘上进行混搭并演示了这一点。 Bespin的表现……在一百行文件中表现不错，而事实证明，在千行文件中表现为“糖蜜一样慢”。 （不过，谈话中最尴尬的时刻是稍后，当狄翁谈到他年轻时每天放学回家匆匆回家“搅动桨”时，这是另一个故事。）

就在几天前，贝斯平很快就邪恶了。 发生了什么？

我认为解释这种小的性能下降可能很有趣。

云数据持久性

丹尼·拉格鲁（Danny Lagrouw）参加了此次演讲：

云数据库是可以在Web上使用的数据库系统。 无需使用Oracle，您可以将数据存储在云数据库中。 对于某些人来说，这似乎是不可想象的，尤其是在例如您必须满足严格的安全性要求的情况下。 另一方面，许多应用程序不必处理此类要求，也不必寻找其他方法来处理它们。 对于那些应用程序，云数据库提供了一些吸引人的优势。 您无需对其进行维护或支持。 它们的大小几乎是无限的。 据说Google的BigTable（在Google之外尚不可用）包含800TB的表，分布在许多服务器上。 但是云数据库最有趣的方面是它们不是（始终）是关系数据库。 相反，它们通常具有某种类似于电子表格的单元格结构。 每个属性值最终都在其自己的单元格中。 您不必预先定义每个实体包含哪些属性。 并非每一行都必须使用相同的属性。 最棒的是，有时时间是一个单独的维度。 如果行的属性已具有值，则分配新值将不会覆盖旧值。 而是使用版本号或时间戳添加新值。 锁定已成为过去。 您将始终看到实例的最新版本（在检索时），但是您也可以在过去的某个时间点请求其状态。

Gojko Adzic详细介绍了此演讲，包括：

来自10gen的Geir Magnusson今天在2009年QCon伦敦会议上发表了题为“ 云数据持久性”或“我们正处于数据库重复使用-请注意”的演讲。他的演讲的主要内容是“当今技术的物理局限性与Linux的计算复杂性相结合”。传统的关系数据库正在将数据库带入新的令人兴奋的空间”，或者更简单地说，数据库的格局正在发生变化，我们应该保持对此的关注。

在介绍诸如Google的BigTable和Amazon Dynamo 之类的解决方案时，Magnusson说，分布式数据库使我们能够管理海量数据（BigTable是为PB表设计的），但是在跨多个系统分布的同时，高可用性问题带来了一系列通常需要的要求脱离关系模型并更倾向于键值或文档存储的解决方案。

马克·埃丁顿（Mark Edgington）也这样做，包括：

物理限制和计算复杂性正在将实现推向我们不习惯的新领域。 与首次发布多核时类似，许多人认为很多软件会考虑到多核，但这并没有很快发生，现在仍在发生。

对于使用大量数据库的社交网络，通常的解决方案是分片（在多个服务器之间分成多个块）。 但是请记住，这对于开发人员来说是有变化的，开发人员现在需要查找多个分片-您不能在分片上使用SQL JOIN，也不能保证唯一性和完整性。 我们还看到开发人员诉诸不自然的行为来处理大数据集的问题，即将MYSQL变成无密钥存储（Friendfeed）。 对他们来说是一个很好的解决方案，但是现在数据库不再是数据库。

情况正常，一切都必须改变

马克·埃丁顿（Mark Edgington ）从此次演讲中获得了详细的介绍，包括：

并非所有IT都是一样的，并非所有IT都像某些商品化的那样具有价值。 这是通过技术优势和模仿争夺战而发生的。 任何新事物都有竞争优势的机会，任何常见事物都是服务。 遵循与许多其他行业相同的路径，即电力创新->国家电网。 如果这发生在IT部门，它是否仍然具有战略价值？ 是的，因为不是所有的IT都商品化，它总是沿着创新->商品曲线前进，当他们到达那里时，他们就准备将其转变为服务。

这如何影响IT

• 颠覆性-通过SaaS行业的发展
• 创新-商品化实际上通过基础架构的稳定性（即组件化）促进了更多创新
• 关系-不同的服务模型* aaS改变了企业与其供应商交互的方式。 可以外包更多项目，只有一个供应商模型并不常见。
• 别无选择-当您将产品视为创新但市场将其视为商品时-红皇后假说（无所作为的风险）

企业中新兴的语言

Steve Vinoski整体上都很喜欢这首歌：

奥拉·比尼 （ Ola Bini ）在周三的“企业中的新兴语言”专题中进行了一些精彩的演讲，尤其是Rich Hickey的Clojure演讲。 Ola的渊博知识和对编程语言的热爱使他成为了该曲目的理想主持人，并且他汇集了出色的阵容。

Alex Cordellis参加了赛道介绍：

我跳入Ola Bini对新兴语言领域的介绍，看他解释为什么语言很重要。 我在这里的重点是Ola的观点，即沟通全都与交流有关，我们需要考虑将系统各部分与机器以及与其他人进行交流的最佳媒介（即语言）。 由于我们交流的目标发生了变化，媒体也应发生变化，这就是为什么我们需要不同的编程语言的原因。

务实的真实Scala

格伦·福特（Glen Ford）喜欢这个演讲：

非常有趣的基于JVM的语言，与Java很好地集成在一起。 提供了OO和功能编程的完美结合-从而提供了一条通向更多功能模型的清晰途径。 会议通过了一些语言功能，但是显示的最令人印象深刻的内容之一是用30行代码编写的Web聊天系统的演示。

可以在类或实例级别添加的特性的一个非常好的概念-太多的信息使我无望传达。 但是启发了我仔细研究。

Clojure

Glen Ford参加了此次演讲：

在JVM上运行的“ Lisp”功能语言。 这是一个非常有趣的演示，该语言具有一些非常有趣的功能，包括如何处理并发性。

和克里斯·里默 （ Chris Rimmer）一样 ：

Clojure是Lisp的一种方言，它在JVM上运行，而该演讲是由其创建者给出的。 他说，使Lisp成为Lisp的是代码和编译器之间的交互。 他确实试图说服我们Lisp括号没有问题，但事实证明他曾试图解决Clojure中的这个（非）问题，所以我不确定。 他谈到了功能语言的使用以及它们如何简化我们新的多核世界的编程。 Clojure通过对不可变对象的可变引用来解决此问题。 他给出了各种理由，说明为什么将面向对象视为问题，并说多态性很好，但是应该基于对象的运行时状态使用它，因为“您不是天生的父亲”。

三年的真实世界Ruby

Sebastien Auvray写道：

在三年的真实世界Ruby中，Martin谈到了他对ThoughtWorks上完成的64个（或63 ..我不记得了）项目的反馈。 马丁是一位出色的演讲者，他依靠出色的指标令人信服。

和Pedro Pimentel一样 ：

马丁谈到了人们如何与Ruby打交道，如何影响生产力以及将Ruby用于现实世界项目的许多其他考虑。 根据马丁的说法，有41个用Ruby制成的项目。 马丁说的一件事是，当人们需要回到Ruby以外的其他语言工作时的感受。 毫不奇怪（对我而言），大多数人不想再使用其他语言，主要是因为Ruby的易用性。 关于项目中的Ruby性能，Martin表示：“ Ruby速度很慢，但这并不是大多数应用程序的瓶颈。当今导致速度慢的最大原因是访问数据库”。 关于用ruby开发工具，再一次对我来说也就不足为奇了。 团队中没有人会觉得需要像Eclipse这样的IDE。 总而言之，他的演讲对我来说并不新鲜，但是听到像马丁这样的人总是很高兴的。

和Alex Scordellis ：

很高兴看到一些统计数据支持Ruby在企业中工作的想法。 ThoughtWorks在Ruby中进行的41个项目中的36个会再次使用它，而在5个不会使用的项目中，有4个表示原因是由于使人们适应Ruby的问题，而不是Ruby执行所需工作的能力。 一个有趣的趣闻轶事：Ruby项目的开发人员估计他们在项目早期的生产率提高了2-5倍（例如，超过Java），在后期提高了1.5倍，但在后来的时候又提高了2-3倍他们不得不回到Java并想起它有多糟糕！ 马丁是一位出色的演讲者，因此一如既往的有趣。

克里斯·里默（Chris Rimmer）也参与其中：

本讲座探讨了ThoughtWorks在实际项目中使用Ruby的经验。 一般而言，这似乎是成功的，即使不是成功的问题，问题也比技术更具有社会学意义。 看来，让一些经验丰富的开发人员了解动态语言也很重要。 一旦小型团队奠定了基础，就有可能扩大团队。 他建议这个想法（从小处开始，然后长大）将更广泛地适用。

提到了传统上与Ruby相关的一些问题。 他说，可以通过将所有这些更改放在一个地方，或者通过将新代码放入要包含在类中的模块中，来控制所谓的猴子补丁 。 在性能方面，他说Ruby确实很慢，但是在大多数情况下，您的应用程序无论如何都要与数据库绑定。

最后，他谈到了基于Rails的ActiveRecord测试代码的困难。 两个大项目为此采取了不同的方向。 一个决定只使用流程并让测试与数据库对话，而另一个决定使用动态模拟来避免这种情况。 事实证明，这种模拟导致测试变得脆弱，因此该项目现在正朝着使用数据库的方向发展。

企业中JavaScript

蒂姆·安德森（Tim Anderson）喜欢这个演讲：

伦敦QCon上最好的会议是小型会议，而不是大型会议。 昨天，我最喜欢的广告位是来自Attila Szegedi的企业版JavaScript。 他使用Mozilla Rhino进行服务器端开发。 这不是主流选择。 但他为此提供了理由，他说JavaScript的延续带来了巨大的好处，开发人员已经准备好了具备JavaScript技能的开发人员（尽管大多数都是基于浏览器的），并且JavaScript如此灵活以至于他可以克服任何限制。

Gojko Adzic也写了这篇演讲：

Attila Szegedi今天在2009年QCon伦敦会议的企业演讲中建议使用JavaScript作为服务器端JVM系统的脚本语言。 Szegedi将基于堆栈的延续命名为该方法的巨大优势。 基于堆栈的延续实际上是带有回调的异步调用，但是没有闭包，异步调用和回调通常随附的怪异代码。

基本上，这个想法是：

1. 中断调用，获取堆栈，异步存储和执行调用
2. 收到响应后，将堆栈拉出并继续工作
3. 物理线程可以自由地同时进行其他工作
4. 不要显式地编写此代码，请框架为您执行此操作，以使代码看起来像通常的过程程序

六便士-敏捷开发的技术技能

您可以从这里到达那里：采用敏捷比您想要的难，但比您想像的要容易

佩德罗·皮门特尔（Pedro Pimentel）参加了此次演讲：

Keith Braithwaite通过比较开发人员的成本和硬件成本，开始了他的演讲“采用敏捷比您想要的要难，但是比您想像的要容易”。 Keith展示了一些统计数据，说明人们如何通过使用更大的显示器来提高生产力，以及这些硬件成本与开发人员成本之间的关系。 据他说，如果您的公司没有给您提供出色的监控器，则由于生产力下降，他们正在浪费金钱。 他所做的其他评论是关于结对编程的，他一直在捍卫结对编程的使用，他说：“选择单独工作是为了选择代码质量较低的代码”。 在对Rockstars开发人员的骚动中，Keith说他们不应成为团队的一部分，而应被聘为顾问或承包商。 在结束讲话时，Keith提出了一些要考虑的点，以便了解敏捷方法是否在您的团队中起作用：估计会收敛，长期内质量仍然很高，团队本身会找到新的方法来更好地工作。

小型编程

克里斯·里默（Chris Rimmer）讨论了本次会议：

这是一个很棒的会议。 它变成了类似于60路重构会话的过程。 他们给出了代码示例，然后询问如何改进代码的想法。 它们的前提与“ 清理代码 ”一书中的类似，是您需要首先清理很小的东西。 排序后，更大的问题将变得更加明显并且更容易解决。

首先，删除无用的注释和不需要的代码，修复格式并重命名变量以说明其用途。 一个重要提示是将重新格式化本身作为修订进行检查，以免隐藏真正的更改。 下一步是删除重复项，简化条件，并在需要时使用微小的策略对象。 最后，寻找删除静态变量和NoJos并在可能的情况下在域对象中隐藏基元。

测试驱动的开发：十年后

亚历克斯·科德利斯 （ Alex Cordellis）写道：

然后，我决定去Michael Feathers和Steve Freeman谈论TDD的历史。 分别编写和共同编写了《有效地使用旧版代码和模拟角色，而不是对象》一书 ，我非常尊重这些人。 这些文字在我对良好的OO设计的理解中起了关键作用。 这次会议是一个有趣的历史课程，对核心原则的有用提醒，并包含一些有趣的轶事。 令我特别震惊的是，早期的测试从业者（Gerry Weinberg，Kent Beck）只是认为其他所有人也都在进行测试，因为他们认为这是从事专业工作的一部分。 再加上更改。

Gojko Adzic进行了详细记录，包括：

Feathers和Freeman在讲话中说，距TDD上市并开始获得广泛采用已经大约10年了，但是它的起源比大多数人认为的要早得多。 杰拉德·温伯格 （ Gerald Weinberg）在60年代从事打卡机的开发工作，必须尽快使之正确，因此他阐明了测试要求并指导了这些测试的开发。 Feathers引用Weinberg的话说：“只是假设任何专业人士都可以在这项活动中做得很好。” 七十年代后期， 沃德·坎宁安 （ Ward Cunningham ）正在研究Wyatt Software电子表格系统，在该系统中， 他通过将电子表格读取到一天编写的测试框架中来缩短开发过程 。 这帮助他的团队更快地生产了软件，但也受益于外部审核，以验证软件的正确性。 Feathers引用Cunningham的话说：“当一名审计师承认他已经看过测试浏览器之类的东西并且在午餐前通过了我们时，我们经历了五项重大审计。” 因此，人们以前做过与TDD类似的事情，但并未真正宣传它，因此并未得到更广泛的采用。

赚六便士-没有借口：每周兑现的概念

西蒙·贝克介绍了此演示文稿：

昨天在伦敦QCon上 ，Gus和Kris谈到了我们Energized Work 每周如何从概念变成现金 。 这确实是一条简单的信息。

保持移动：

• 通过至少每周一次将运行测试的功能“运送”到生产中来维持吞吐量并最大化利润。
• 使一切自动化，以实现移动性并不断投资以保持其便宜。
• 不要跟踪错误，请修复它们。
• 管理债务以保持快速发展。

保持工作：

• 通过始终进行配对编程，消除个人的焦虑并保持团队的弹性。
• 通过团队滚动每个故事的所有权，以促进集体所有权和知识转移。
• 通过个人纪律保持严格的测试驱动方法。
• 因为对话永远不会停止，所以要保持一致。
• 通过与专职现场客户反复交流，了解真正需要什么。

杰罗姆·皮梅尔 （ Jerome Pimmel）也写道：

值得回顾一下幻灯片（可通过[this]链接获得），以了解使用这些方法如何帮助实现以下目标

• 建立并维持一个充满活力，参与度高且有趣的开发团队
• 快速投入生产，每周部署到生产
• 全面的测试覆盖范围确保了最小的持续生产问题
• 持续的质量检查，客户/产品所有者的反馈确保符合要求
• 没有错误数据库意味着->总是立即杀死所有错误
• 持续环境：开发团队创建，管理和支持所有环境，无论是测试，质量保证还是生产（为什么？没有孤岛，例如：系统管理员团队）
• 跟踪根据财务指标发布的已发布功能
• 向客户展示项目在每个每周发布中都使利润最大化，从而使他们兴奋

战中的CI：现实世界中的持续集成挑战（以及如何应对）

克里斯·里默（Chris Rimmer）参加了这次演讲：

讨论始于观察到持续整合是人类的活动。 在服务器上安装CruiseControl ， TeamCity或任何其他工具还不够。 如果开发人员不经常检查，则不会发生。

讨论了如何通知已损坏的构建以及如何标记构建。 他指出，将Subversion修订版号用作构建标签存在危险，因为在执行存储库维护时，它们可能很脆弱。 应该标记可部署的内部版本，但是不应将此类大二进制文件保留在版本控制中 。 常春藤存储库是替代方法。

真实世界的SOA

指导西北通道：开始实施SOA计划

Alex Scordellis喜欢这个演讲：

这是我今天的选择。 这些演讲之一使您考虑对工作领域采用全新的方法。 我挑选了一些关键信息。

• 我们应该专注于实现带来收益（什么）的结果的能力，而不是为了服务而服务（如何）。 这使我们能够专注于提供使我们的业务与竞争对手区分开来的那些功能。
• 谁负责业务能力和谁负责保持Web服务之间存在关键区别。 与第一类人员互动将有助于产生一种主人翁感和紧迫感，并最终导致我们建立更多以价值为导向的系统。 例如，伊恩（Ian）建议以责任为中心的故事 ，我负责 ，可提供 ）以帮助识别这些人及其责任。 从我最近的经验中，我可以证明，让这些业务能力所有者参与通常是一个巨大的挑战，特别是在大型公司内部，我希望利用Ian的想法来帮助我做到这一点。
• 即使不同的业务功能使用相同的数据，也需要不同的服务实现。 不要总是假设您的业务实体采用相同的形式并使用相同的服务。 特别是，我们使用和代表实体的方式在该实体的整个生命周期中可能会发生重大变化（考虑签署新客户并代表该客户执行日常金融交易时所涉及的不同功能）。 更新：请参阅下面Ian的评论以进行澄清。
• 使用消费者驱动的合同来减少服务提供商和消费者之间的耦合。
• 拥有长期存在的能力交付团队来负责业务能力，但是要利用新的利用这些能力的项目中的额外资源和知识来增强他们。

和格伦·福特一样 ：

对启动大型项目（尤其是在已经运行的系统中）非常有深刻的洞察力-很高兴看到SOA被称为SOA（方法），而不是SOA作为购买最新金锤的供应商。

金融业务服务的基于REST的集成架构

格伦·福特参加了这次演讲：

这次演讲使我感兴趣，因为它是关于从WS- *到REST的迁移以及使用ATOM / ATOMpub之类的。

必须承认，现在已经开始动脑筋了，我还没有完全理解。但是听到菲利普的观点很有趣-在接口边界使用REST，但不要尝试在内部使用它，因为延迟级联会咬你。

金融应用架构

行动中的AMQP

Gojko Adzic详细介绍了此演讲，包括：

在伦敦QCon 2009大会上的AMQP行动会议期间，演讲者介绍了似乎是非常有趣的解决方案，它可能是当今消息中间件中最大的问题-互操作性。 面向消息的中间件（MOM）通常在API级别（例如JMS）进行标准化，但是各个实现在协议级别上不兼容，因此它们无法彼此配合使用，从而经常导致供应商锁定。 摩根大通（JPMorgan）的约翰·奥哈拉（John O'Hara）说，当今的主流消息解决方案是专有的，对于日常使用而言过于昂贵，并且无法互操作，从而导致现有的停滞。 这产生了许多临时的自制解决方案。 AMQP（高级消息队列协议）试图通过提出开放的通用标准来解决此问题。

改变对帐流程

Martin Kneissl参加了这次演讲：这是一个很棒的演讲，涵盖了对帐的功能要求，困难之处以及如何使用数据网格来改善情况。 asdf也出席了会议：

在QCon London的“金融应用体系结构”一书中 ，Oracle 提出了一种有趣的解决方案，该解决方案试图将对帐流程从固有的批处理流程转换为增量事件驱动的异步流程。 他们提出了一种基于Coherence的解决方案，其数据网格通过在服务器之间分散交易来解决容量挑战，并通过Coherence支持的连续复制的弹性来应对可用性挑战。 作为演示的一部分，基于Coherence的解决方案涉及一种重要的范例，甚至可以在基于外部网格的体系结构中采用该范例，以提高系统性能和吞吐量。

解决方案跟踪：性能和可伸缩性跟踪

为性能和可伸缩性进行架构设计：小组讨论

丹尼·拉格鲁（Danny Lagrouw）参加了小组讨论：

在我当前的客户进行性能调整活动之后，我渴望在周三早上收听“性能和可伸缩性的架构设计”小组。 诸如Cameron Purdy（Oracle）和Kirk Pepperdine（独立顾问）之类的知名人物，以及诸如Eoin Woods（一个大型投资集团的建筑师）之类的知名度较低的品牌，讨论了与绩效相关的各种主题。 像这样的讨论很容易在各个方向上展开，只留下几个声音。 尽管它们非常简单，但它们仍然值得深思。 例如：

• 关于延迟的战争将比执行性能分析更为重要。
• 如果必须调整9到5的系统，请记录白天的用户操作。 您可以在晚上使用它们来模拟系统上的代表性负载。
• 为了调优，您必须进行基准测试。 标杆管理本身必须被视为一个项目。 基准测试可能比向系统中投入更多的硬件更加昂贵。
• 如果使用“新”语言（JRuby，Groovy等）导致性能问题，则将解决这些问题。 就像Java一样。
• 在SOA中封送XML的问题不是（反）序列化XML所花费的时间。 这是在同一请求中多次对XML进行反序列化的时间。

马丁·克尼斯尔 （ Martin Kneissl ）也在场：

对我来说，这次讨论中的掘金是

• 当您拥有可扩展的体系结构时，线性收益/惩罚不会改变最终极限（但会增加成本...）
• 尽管语言可能会改变您对问题的思考方式，但是语言的实现通常只会线性地影响性能（然后参见上文）
• 在进行SOA时，请注意那些为重要消费者提供过多数据的服务，因为网络是瓶颈。
• 在进行性能测试时，请使用真实数据，因为人工测试数据可能过于随机或以与真实数据不同的方式聚集，从而导致数据对齐方式/索引/使用任何其他方式导致错误结果。

非常高兴有Cameron Purdy参加小组会议，他确实提出了一些建议...

建立性能和可伸缩性：如何将性能管理集成到您的开发过程中

格伦·福特参加了这次演讲：

概述了许多性能问题的原因，以及检测这些问题的非常高级的方法-但是这里没有新内容，也没有方法的实际演示，也没有硬数据。

我在这个领域非常熟悉，曾花时间在“战es中”处理这些问题，并花了一些时间开发有助于缓解这些问题的方法。 因此，我感到很失望-我觉得这个主题还有很多，特别是我可以很容易地采取步骤介绍在过程中尽早发现性能偏差的方法和手段。 不需要昂贵的大型工具集即可开始此过程（或我认为完全不需要）。

开放标准的发展：机遇还是约束？

马克·埃丁顿（Mark Edgington）参加了小组讨论：

标准化对于堆栈的某些部分至关重要，那些项目更改最少，即堆栈中的位置较低。 堆栈中较高的位置需要经常更改，因此标准化会扼杀创新。 我们需要记住，达到一个标准需要花费很多时间，而且与标准相比，开放源代码作为一种开发工具总是很容易被使用。

开源标准也可以帮助开源，因为许多公司对使用开源项目不感兴趣，除非它有赞助商或者是知名组织（例如Apache）的一部分。 但是，它确实需要启动开源并转向开放标准，只是试图成为一个标准通常会导致错误的人群参与标准流程。 所有这些都引起了政治上的混乱，并且在功能上发生了马交易。 但是，对于小型公司和个人而言，朝着标准迈进也可能是不可能的，而对于Oracle和其他公司（由员工全权负责）则很容易。 标准也会感觉好像他们在决定我们应该如何工作，当我们已经很好地工作时，这可能会引起一点忧虑; JPA比Hibernate更好吗？

您一直想知道的架构

彼得·马斯 （ Peter Maas ）对整个赛道进行了评论：

今天我学到的东西（或再次听到但认为对保持提及很重要）：

• 英国广播公司（BBC）的计划与我为荷兰广播公司VPRO所做的计划非常相似。 上面是一个面向REST的服务层，上面有轻量级的小部件/混搭渲染，下面是适用于问题域的工具。 它们仅比我们目前稍远。
• Guardian.co.uk构建它们的应用程序的方式与我设计/开发Cinema.nl的方式非常相似，除了缓存中的一些细节。 他们很高兴，但是也转向了面向REST的体系结构以减少耦合。
• 建筑师从高耸入云，开始越来越使用常识技术（例如HTTP，RSS，ATOM，REST），并且放弃了“企业”模式和工具（例如JEE，Portal，SOAP等）。
• 新架构通常更多地是在社会方面，而不是技术方面

不断发展的Guardian.co.uk架构

Nik Silver参加了此演讲：

Mat的演讲围绕多个月的guardian.co.uk重建，并处理了各个阶段提出的可伸缩性问题。 这些见解中有一些是以故意挑衅的方式提出的，例如：

开发人员试图使事情复杂化； 建筑师简化了它们。

对于第一部分，我并不完全确定，但可以肯定的是，过度设计比缺乏工程设计是更常见的特征。 不过，第二部分非常重要。 这是我一直都知道的，但从来都不是那种精妙的方式。 这是一个有用的短语，可供将来参考。

马克·埃丁顿 （ Mark Edgington）作了详细记录，包括：

到2007年，那里的现有vingnette体系结构已不复存在。 于是进入了18个月的重新设计。

• 敏捷构建
• 4开发团队
• 2>百万个页面要迁移
• 许多新功能。
• 建立在Java堆栈上（Spring，Hibernate，EHCache和Velocity）
• Endeca作为搜索引擎

要处理的问题

• 与现有站点并行开发
• 零停机时间-逐节迁移-使用Apache mod允许从中选择要服务的后端
• 随着系统的发展，体系结构-从旅行14k的文章开始-将适合RAM，因此可以减少对DB的担心，可以通过停止缓存超时来关闭DB，从而可以进行升级。
• 托管在曼彻斯特和伦敦的托管托管

开拓进取-将BBC扩展到Web / 2.0

Nik Silver ：

Dirk-Willem谈到了重新设计BBC网站以实现更大的可伸缩性和动态内容的计划。 在BBC如此庞大和复杂的组织中，与技术相比，您需要花费更多的时间来思考人。 他的第一批幻灯片之一通过介绍OSI模型的七个层（具体取决于应用程序）强调了这一点，然后说

但是大多数人忘记了这之上有两层：组织的第8层和目标和目的的第9层。

从那时起，他一直指的是“ L8问题”或“ 9级问题”。 这有力地提醒我们，技术工作远不止技术。

敏捷的组织模式

敏捷性：在个人层面上的可能性

佩德罗·皮门特尔（Pedro Pimentel）参加了这次演讲：

在其95％的时间里，她谈到了咖啡因及其对人健康的影响。 毫无疑问，这是一次愉快的谈话，琳达当然知道如何吸引人们的注意力。 她试图传达的信息是，敏捷可能与“咖啡因”对我们的健康一样（不好），因为敏捷会使您感到精力充沛，受刺激，沉迷于工作，并使工作变得很有趣，但是我们的身体和头脑还没有为这种“能量”做好准备。

格伦·福特也出席了会议：

我选择参加Linda的演讲，因为有机会，有几个人建议听她的演讲。 我必须说，我很高兴自己不仅为内容，而且为她轻松和引人入胜的演讲风格所做。

因此，这主要是关于毒品，咖啡因以及世界上首选的毒品的讨论，显然，世界上约有90％的成年人每天以某种形式或其他方式消费毒品，这几乎没有其他可比性。

我的演讲确实围绕着工业时代以及我们如何按照当时的方式行事和生活。 我知道很多有趣的事实，因为水中的细菌会导致喝啤酒，但是我从来没有将精确的时间片和茶/咖啡同时出售-工业革命时期。 沏茶/咖啡的过程当然需要将水煮沸。 因此，人们需要在工厂轮班前醒来，他们要喝茶/咖啡而不是啤酒，因为开水是安全的。

指导自组织团队

Pedro Pimentel撰写了有关此演示文稿的文章：

约瑟夫·佩林 （ Joseph Pelrine）在“辅导自组织团队”中，讲的是如何使人们做事情而不直接告诉他们。 这是实现正确行为的全部问题，对于约瑟夫而言，这是人与环境的关系。 自组织团队具有紧急行为，并且通常以“最适合模式匹配”为条件。 这意味着，他们根据自己的经验做出决定。 这种团队需要在行为方面具有多样性，以激发团队不断发展的行为。 一个团队不仅是一群一起工作的人，而且还需要“热量”来移动和更好地工作。 据约瑟夫说，当人们尽力而为时，它接近“混乱”。

应用功能和并行编程语言

Sebastien Auvray对整个曲目进行了评论：

我第二天参加了Francesco Cesarini领导的“ 函数式和并行编程语言应用程序”课程 。 当天最重要的时刻是Rich Hickey的演讲，内容涉及持久性数据结构和有关状态，过程，身份以及Clojure的应用程序的托管参考 。 Erlang中的多核编程也很有趣。 整个过程说服了我，使我对Clojure有了更深入的了解，但也证实了我在2009年选择学习功能语言的原因，这就是为什么我带着《 Real World Haskell》书包回到巴黎（是的，我知道，Erlang是很酷，并且在QCon上得到了很好的报道，但一位朋友建议我看看Haskell。 最后，我学到了许多可用于我的日常工作或副项目的概念和想法。

和史蒂夫·维诺斯基 （ Steve Vinoski）一样 ：

我在去年的QCon伦敦遇到了弗朗切斯科（Francesco），他像乌尔夫（Ulf）一样是世界上最大的Erlang开发人员之一。 他为这次会议筹划了一条很好的轨道，Rich和Ulf的背对背谈话远远超过了任何认为多核不是问题的开发人员，而这些开发人员认为今天的并发处理方法将继续有效。精细。 祝您好运！

与Microsoft F＃并发编程

蒂姆·安德森（Tim Anderson）参加了此次演讲：

今天，我刚刚参加了由Amanda Laucher主持的有关Microsoft F＃的会议。 F＃是一种功能语言，将作为Visual Studio 2010的一部分发布。直到今天，我对它还是一无所知。 Laucher以汽车保险业为例，在代码繁重的演示中探讨了F＃中的并发性如何能够大大提高执行速度。

和Ola Bini一样 ：

在DSL领域，Amanda Laucher很好地概述了什么是奥斯陆以及为什么要使用它。 我在这里寻找的只是对技术的了解，以了解这是否值得投入更多时间。我的结论是，在目前的时间点上，它似乎并没有给我带来什么新的帮助我。 Especially the Mgrammar stuff seemed to be a not-invented-here copycat of Antlr. Martin corrected me about that, though, by pointing out that Mgrammar actually handles GLR grammars. My intuition is that ANTLRs LL(*) would be able to handle most of the same parses, but that's not something I would bet money on. Mgrammar also doesn't need semantic predicates to avoid left recursion, which can make the grammars more readable.

Lift web framework

Ric Smith wrote about this presentation:

What struck me most about the talk is how well Scala lends itself to the concept of the real-time Web-a concept that we try hard to evangelize at Kaazing. With Lift, many of the view components are Comet enabled which allows for real-time Web platform. Very cool, I must say. Even cooler, if we can sprinkle a little bit HTML 5 on there. ;-)

Persistent Data Structures and Managed References

Several people wrote about this talk, including Ulf Wiger :

This time, I was preceded by Rich Hickey's talk on Persistent Data Structures and Managed References in Clojure. I was greatly intrigued by this talk and made a note to take a closer look at Clojure. Interestingly, Rich stressed that Clojure Agents are not actors a la Scala or Erlang. Part of my talk was to illustrate how Erlang processes are not "fibers" , and trying to use them for data-parallel algorithms can be problematic. Nice setup.

Attila Szegedi :

A problem with staying in a profession for long years is that there's less and less things that can truly excite or surprise you as the time passes. That's why I was particularly delighted to experience a moment of sudden enlightenment while listening to Rich Hickey talk about "Persistent Data Structures and Managed References" last thursday at QCon in London. The title of the talk might not sound exciting, but I have to tell you, if this were the only talk I attended, it alone would have been worth attending. I don't say this often. Slides are here , although you're missing out Rich's incredibly good verbal presenting style if you just read them, obviously.

Danny Lagrouw :

According to many visitors, the best QCon 2009 talk was Rich Hickey's: Persistent Data Structures and Managed References. Hickey truly is a gifted speakers who knows how to get a point across. He is the creator of Clojure, a Lisp variant running on the JVM. On Wednesday, Hickey had already talked about Clojure itself, explaining why he had developed Clojure, why it's running on the JVM (libraries, resource management, type system), and why we'll more and more be needing functional languages like Clojure. The latter was worked out in more detail in the Persistent Data Structures talk. Hickey said mutable, stateful objects are the new spaghetti code. Mutable stateful objects are objects that don't always return the same answer to the same question (like "person.getProfession()"). This is bad because it may cause problems in a multithreaded environment, with which we'll have to deal a lot more often, thanks to today's multicore processors. Two separate threads might try to change the object's state at the same time. You might prevent this with locking, but it's hard to get locking right. Using this argument, Hickey discards the entire object oriented programming model: functional programming FTW! Still he must concede that state remains necessary to develop a useful system, and that you'll have to be able to change that state as well. His solution to this is Managed References.

And Ola Bini :

This was without doubt the best presentation at QCon this year. Rich spent lots of time talking about identity, state and value. It was very good - you should go to http://qconlondon.com/london-2009/schedule/thursday.jsp and take a look at the slides for it. It is pretty deep stuff. I heard many other people share my opinion of the quality of this talk. QCon and JAOO could do much worse than getting Rich back for the next time.

Multicore Programming in Erlang

Steve Vinoski enjoyed this presentation:

I also finally got to meet Ulf Wiger , Erlang developer extraordinaire, in person. He's a laid back guy, quite well-informed and a deep thinker who can cover a wide variety of topics in amazingly useful detail. His talk on multicore programming in Erlang covered cutting edge Erlang development and presented some very difficult concurrency issues.

领域驱动的设计与开发

What I've learned about DDD since the book

Chris Rimmer wrote up a detailed sumary of this talk, including:

Something that was in the book that he thought could be left out was Large Scale Structure, which doesn't come up too often. On the other hand, he suggested a couple of new context patterns:

• Partners - Mutually Dependent and Cooperative
• Big Ball of Mud - Common. Know that you can't do sophisticated modelling within and accept that.

Danny Lagrouw also wrote about this talk:

Eric Evans, author of Domain-Driven Design, looked back on the five years that had passed since the book came out. One thing he would have wanted to emphasize more was mapping of contexts and context boundaries. Evans considers a domain model to have boundaries based on its context: an entity (like Person) might have a whole other meaning from one domain to the next. Also, he feels that the building blocks for designing a domain model (eg Entity, Value Object, Factory, Repository) are often overemphasized. It's not about the building blocks, it's about the principles of DDD. 我完全同意。 Nevertheless, Evans described a new building block that isn't mentioned in the book: Domain Events. Domain Events should not be confused with technical events; they're events in the domain that have meaning to domain experts. A DDD architecture can benefit from using Domain Events, because they offer a way to decouple subsystems. Also they may result in a better performing system, even though people often think otherwise.

Gojko Adzic also covered a lot, including:

• Creative collaboration of domain experts and software experts is essential. When most projects get their hands on the domain expert they don't utilise their time properly. Starting with a requirements document and going through the boring list of requirements will drive domain experts away and they will become "too busy" to help. Like anyone else, domain experts don't like to do things that they don't see value in. We need to use their time efficiently and really show how valuable their participation is. Instead of going through an itemised list of boring requirements, Evans suggests using their time to explore the domain, prototype, make it a creative process and ensure that the value is evident.
• Exploration and experimentation is essential. Teams usually stop when they get a first useful model that does the job. Evans said that with this, "you are leaving so many opportunities on the table". Exploring models is cheap if you're brainstorming at the whiteboard or prototyping, and "If you get nothing but good ideas in a modelling session, you're not being very creative ". Evans suggested rule not to stop modelling until we have produced three bad models.
• Shaping and reshaping the ubiquitous language with emerging models shaping is essential.
• Expressing context boundaries is essential. This is covered in chapter 14 in the book and Evans said that this is one of the few regrets he has about the way he wrote the book and that he would do it differently if he had to do it again. Putting effort into defining contexts and boundaries is essential to get to good models. Evans said that "the reality is that there is always more than one model" and mapping these models out is crucial to setting the stage for success of a DDD project.

Rebuilding guardian.co.uk with DDD

Nik Silver attended this talk:

Phil talked about the role domain driven design has played for us. He also pointed out various lessons that there were learnt along the way, such as the importance of value objects, and the fact that "database tables are not the model - I don't know how many times I can say this."

But it was only a day or two after his presentation that I was struck by a remarkable thing: Phil referred so many times to specific members of the team, and talked about contributions they had made to the software design process, even though the people he was talking about were generally not software developers. He put their pictures up on the screen, he named them, he told stories about how they had shaped key ideas. This was an important reminder to me that being close to our users and stakeholders on a day-to-day basis is incredibly important to the health of our software.

Mark Needham also discussed it:

• Phil started by explaining the reasons that they decided to rebuild their website - tedious manual work was required to keep the site up to date, they were struggling to hire new developers due to their choice of technology stack and it was difficult to implement new features.
• They were able to get domain experts very involved with the team to help define the domain model and trusted the domain expert to know best. I think the difficulty of making this happen is underestimated - none of the projects that I've worked on have had the domain expert access that Phil described his team as having. The benefit of having this was that they had times when the business pointed out when the model was getting over complicated. The takeaway comment for me was that we should ' strive to a point where the business can see and comprehend what you're trying to achieve with your software '
• Entities are your stars but we need to also think about value objects . Entities have the maintenance overhead of having life cycle that we need to take care of so it makes sense to avoid this wherever possible. Phil showed an example of an entity class with around 50 fields in which could have been severely simplified by introducing value objects. Every time I heard value objects being mentioned it reminded me of micro/tiny types which are not exactly the same but seem to be fairly similar in their intent of improving expressiveness and making the code easier to work with. The importance of value objects was also mentioned in Eric Evans talk .

The Power of Value - Power Use of Value Objects in Domain Driven Design

Chris Rimmer enjoyed this talk:

This was an entertaining talk on value objects in DDD, which seem to be the poor relation compared to entities. Lots of this was just good old fashioned object oriented design, with a domain driven slant. Value Objects differ from Data Transfer Objects since DTOs are a technical construct, whereas VOs are true domain objects.

He showed how pulling Value objects out simplifies the code and helps to avoid bugs, awkwardness and duplication. It also helps the business logic concentrate on just that, without getting bogged down in other issues. He worked through some examples, with his credit card exchange rate example particularly compelling. Having orthogonal classes means that in general m+n tests will be needed where previously m*n would be required.

Mark Needham also enjoyed it:

• We started out with a brief description of what value objects are not which I found quite amusing. To summarise, they are not DTOS, not Java beans and not objects with public fields . The aim with value objects is to swallow computational complexity from our entities. Creating what Dan termed 'compound value objects' provides a way to do this. The benefits of doing this are reduced complexity in entities and code which is more extensible, more testable and has less concurrency issues .
• I found myself quite intrigued as to how you would be able to spot an opportunity in your code to introduce a value object and almost as soon as I wrote down the question Dan covered it! Some opportunities include strings with format limitations, integers with limitations or arguments/results in service methods. The example used was a phone number which was being passed all over the place as a string - refactoring this allowed the code to become explicit - before the concept existed but it was never properly spelled out - and it pulled all the functionality into one place .

Java.Next-塑造Java未来的关键技术

Java Modularity and OSGi for Application Developers

Chris Rimmer went to this presentation:

This was an introductory talk on modularisation using OSGi. He started by saying that while jars have dependencies, these are implicit. OSGi uses modules, which are just jars plus dependency metadata. He had a tongue-in-cheek dig at SOA by pointing out that since we can't use classes in isolation due to the dependencies we have to call them remotely instead. I was surprised to find out that Spring-OSGi had to be renamed Spring-DM ("Dynamic Modules") due to pressure from the OSGi Alliance. The takeaway message was that you need to use something like Spring-DM to take care of OSGi for you and don't code directly to services.

Spring Today and Tomorrow

Gojko Adzic wrote detailed notes, including:

Probably the most important infrastructural change is that from version 3.0, Spring will work only on Java 5+ platforms. The project layout will change slightly, moving to Maven style finer grained system of projects, which will be built using the the new Spring build system ("as known from Spring web flow 2.0″) which is OSGi based.

In terms of new features, Johnson pointed out the following innovations:

• Expression language for configuration
• Comprefensive REsT support
• support for Portlet 2.0
• Declarative model validation
• Early support for Java EE 6

建筑师的体系结构

Pimp my architecture

Danny Lagrouw liked this talk:

North's idea of an architect is someone who collects stories, someone who's able to hear out the history of the shanty town, who will understand decisions that have been made, even if he would have done it otherwise. When he's heard enough, he won't push through the necessary changes regardless and all at once. It is possible to take smaller steps, use transitional architecture, to get people used to the new ideas and to see how the changes turn out. Dan North comes across as an architect who's just as concerned with the social aspects of software development as he is with the technical side of things.

As did Mark Edgington :

Start by doing nothing, listen, listen and listen some more. But, take into account that all you hear may no be true.Now it's time to set a strategy for the future (give yourself air cover), once you have a strategy:

• make sure you are moving on and not just re-hashing the old, but you may need an interim architecture to get you to utopia.
• make sure the team are with you and change the culture as appropriate - rotate roles - encourage coaching - future ambassador/architects
• keep to the strategy and use the right technology stack
• introduce bounded contexts and shape to the codebase/services
• make it easy to share knowledge - make sure the stand-ups are effective, not just news.
• if it's not working be honest so you can get it right

Note: pairing is just helping, easier to sell in.

And Glen Ford :

Dan has a great presenting style, and during this presentation he emphasised the importance of the team Shaman, the team story-teller - and I think he proved himself to be one of the best through this presentation.

I really enjoyed this presentation, as it emphasised the importance of the oral tradition within a development team. And I do feel that is important, the best teams I have worked in have always had this, it meant that new team members came up to speed quickly on the quirks and history of a project, and really helped build the team.

I also enjoyed his 'Shanty Town' pattern - as opposed to the 'big ball of mud'. The truth is as he rightly points out, you just can't rush in and bulldoze, the people have to live somewhere - but you can work to improve it, piece by piece. You can build scaffolding or temporary architectures in the process of rebuilding the town.

Too much to convey it all or even a fraction, but I must say if you get the chance to hear Dan speak it is worth it, his energy and passion are contagious.

Thoughts on the generic-vs.-specific trade-off

Ola Bini enjoyed this presentation:

I saw Stefan Tilkov do a very deep presentation on his thoughts on the balance between generic and specific in architecture and development. Stefan shared his long experience in a funny and thoughtful way that contained lots of interesting insights.

Glen Ford also enjoyed it:

Stefan's talk was great, in particular my favourite snippet from his talk was:

The wise architect ...
question: *
answer: It depends.

And its so true.

Summing up his talk is difficult, as the two sides tend to cancel out, ie it depends. But it was good and he covered a lot of good specific versus generic examples.

战略设计

Mark Edgington took detailed notes, including:

Not all of a large system will be well designed and this can pull your attention in multiple directions. The goal is to have the most important part s of the system well designed - strategic design.

Take two loosely coupled systems that have grown independently, but are starting to move toward interaction. The decision was to move towards a new system, by

• A series of steps - But, it's never going to work like that. 为什么？ as the old business logic is taken there will be more and more parts of the old system that take inadvertent amounts of time. This will lead to just porting sections of code, without re-design and this cannot be well tested. Which, means your new system ends up partitioned into old and new sections - coupled with changes to the original system can mean the project will just end. What are the alternatives:
• Refactoring - keep the system running and change parts by increments. You have the danger here that the best people work on the new items and the others work on system updates, but do everything they can to work on the potentially good stuff.
• Note - the real mess is made by the 2nd worst dev on the team , as everyone is watching the worst like a hawk.
• Lets Hack - this will just end up in an almighty mess

But, whichever of these 3 approaches is taken you are prone to end up with the Lets Hack endpoint. So is there a potential solution? How about Domain Design and the core principle 'Distilling the core domain'.

Glen Ford was also in attendance:

Another really good talk, Eric covered some interesting perspectives on dealing with legacy systems, and the approach you could take in a pragmatic and progressive way. And along the way discussed various issues you need to deal with.

The strategic design comes from, making sure the most important parts of the system are well designed.

Some good points he made ..

• One irresponsible programmer will keep any 5 top-notch programmers busy cleaning up after them.
• The quality of the code is equiv to the second worst programmer on the team. (Not the worst, he is watched like a hawk)
• Remember, the core domain is what makes the system worth writing.
• Heroes work in the core domain (they make the system features the business needs and wants).

Why do irresponsible programmers so often become heros? Because they don't waste their time making other people more productive, they don't clean up other peoples mess, but they do produce new capabilities no matter the impact.

Five Considerations for Software Architects

Glen Ford liked this presentation:

Well today turned into a treat, Kevlin was another good presenter, with a lot of information and some good techniques covered. The presentation was based around a visit to a pub where he and a couple of others (poor memory, cannot remember their names) and tried to distill 5 things every architect should take into mind. These distilled down to:

• Economy - economy in code, in design and in architecture
• Visibility - understanding not just the end product but how it came about
• Spacing - the interesting thing is the space between the components not necessarily the components themelves
• Symmetry - makes things easier to understand and maintain
• Emergence - understand the emergent properties of the problem and the solution

历史上的坏主意

Null References: The Billion Dollar Mistake

Several people wrote about this presentation, including Sebastien Auvray :

I followed most of the Historically bad ideas track. This track was a very original good idea . But as Aino Corry stated, convincing speakers to participate to such a track was far from being a piece of cake (we all have our egos

), unless... Sir Tony Hoare would be part of the track. His

Null References: The Billion Dollar Mistake session was a good historical overview of what lead him to introduce Null References.

史蒂夫·维诺斯基 （ Steve Vinoski） ：

Sir Tony Hoare 's talk about the null reference being his "billion dollar mistake" was great because of all the detail he recounted from some of the early days of computing. He was both informative and entertaining. I was also impressed with Ulf during this talk, whom Professor Sir Hoare invited to come up to the front and present what turned out to be a pretty convincing argument in favor of the null reference.

And Ola Bini :

After the presentation, Hoare asked me if I was interested in being part of a panel during his after-lunch presentation. The presentation was about null references, which Hoare calls his billion dollar mistake. To be fair, I think it was one of those inevitable things, that would have happened sooner or later anyway. Ulf Wiger became part of the discussion, and presented a much better defense than my point about inevitability.

Ola also was inspired to delve further into this area of discussion :

On the Friday of QCon, Sir Tony Hoare held a presentation about the null reference. This was interesting stuff, and it tied into something I've been thinking about for a while. Namely, the similarities and differences in the role of null/nil in static and dynamic languages.

At the surface, a null reference in a statically typed language seems to be a value of a bottom type. Since null is still a value, that cannot be true - since according to the formal definition, a bottom type can have no real value.

Standards are Great, but Standardisation is a Really Bad Idea

Steve Vinoski attended this talk:

Paul Downey 's talk on the downsides of standardization was by far the most humorous talk I heard, perfect to close out t he track , but it also presented a number of hard-won useful lessons about the perils of standardization efforts.

永不停止的系统

Erlang: A language for programming reliable systems

Sebastien Auvray enjoyed this talk:

He introduced Erlang and why he invented it (for Ericsson Telecom Infrastructures). Relying on quotes from prestigious sources , Joe outlined the six laws Erlang is based on:

• 隔离
• 并发
• Must Detect Failure
• Fault Identification
• Live Code Upgrade
• Stable Storage

If you need all this, Erlang should be a good candidate for you. The presentation was one of the best I attended and Joe made it a very pleasant moment.

Ola Bini also enjoyed it:

This talk was focused on systems that never stop, and Joe's presentation was based on this, which changed the focus a bit. Sir Tony Hoare was in the audience during this talk, and one amusing moment was when he asked Joe a question about the tradeoff between timeouts and failing fast. Great stuff. This only happens at QCon and JAOO. (As an aside, the evening before I got the chance to sit down and have beers with Steve Vinoski, Joe Armstrong and Rich Hickey. This never happens at other conferences either.)

Improving Running Components at Twitter

Gojko Adzic wrote detailed notes about this presentation, including:

A very interesting observation during the talk was that Twitter started up with a CMS model and that they gradually moved towards a messaging model. I've seen this in a few applications so far, including a casino system, where the messaging model seems to fit best an application intended to power massive community of online users, it seems regardless of what the application actually does business wise. Applications start out completely different, but then more and more functionality gets bolted on top of user messaging capabilities that the whole architecture on the end gets refactored to utilise the messaging channels as the core information transport. With Twitter, I'd expect this to be more obvious from the start as it was intended to help people notify each other.

For every incoming tweet, the messaging system gets notifications for all the folowers, which are then processed asynchronously. One of the most important changes they introduced to improve performance in the last nine months is moving from a Ruby messaging middleware to a custom build JVM-based messaging middleware written in Scala.

Richard Watson also wrote about it:

Twitter's approach to solving their performance and scalability issues is a great example of thinking big while taking small steps. The team set about iterative removal of bottlenecks. Firstly they tackled multi-level caching (do less work), then the message queuing that decouples API requests from the critical request path (spread the work), then the distributed cache (memcached) client (do what you need to do quickly). Evan was asked about strategic work to take them to the next 10x growth. His responded that they were so resource constrained (can you believe there are only 9 in the services engineering team) and so under water with volume that they have to work on stuff that gives them most value (take small steps). But crucially, they create solutions to the bottlenecks making sure that whatever they fix will not appear on the top 3 problem list again (which is thinking big - well, as big as you can when you're growing like a hockey stick).

供应商

Martin Kneissl was interested by a Microsoft Surface which was present:

I had the pleasure of trying out this giant iPod touch at the Microsoft booth. It's a huge difference seeing this thing on the web and trying it out in reality. I'm quite convinced that this is a technology that could have real value if it becomes affordable.
[...]
If we had a Microsoft Surface and a "tolerant" UML tool, we could try things without the need to manually transfer the result from / into the computer. By "tolerant" I mean a tool that supports incremental development of the model with relaxed model checking to ease "playing" with the model. Basically what I liked in Booch notation: cloudy, incrementally drawable notation that incrementally can be made more precise and formal.

社会事件

Steve Vinoski enjoyed the social events at the conference:

I introduced Rich to Joe Armstrong at the conference party Wednesday evening and they spent the next few hours talking at length about functional programming, their respective languages, VM implementation issues, concurrency issues, etc. Ola jumped in as well. They also continued the conversation the next day. I just sat back, listened, and learned.

Cloud Camp

Guido Schoonheim attended Cloud Camp:

An interesting way to look at these different models is that if you move down the list you get a lot more freedom from concerns. At PaaS you already do not worry about everything connected to your application logic. You have a container interface that is provided and you just do not want to know about the rest. This could help speed up your development a lot. 可能吧 也许。 The cost associated is that you are very proprietary and tied in to you provider!

This tie in might not seem so bad untill you look at the example of CogHead. This PaaS platform was bought up by SAP recently. However SAP did not buy the clients and did not continue the public service. That means that these people have received a legal notice that they have 3 weeks to move off the platform before service is discontinued. Now, can you rewrite your entire business in 3 weeks? And handle a migration? 可能不是！

Where SaaS obviously has a similar problem, the IaaS models seems safe enough. You do everything the way you want, probably creating images with the usual platforms that you can get anywhere, also in non cloud environments. The most risk here is your data. There are a number of examples of people with a client base that now have so much data going into Amazon S3 that there is no way to get it out again in a reasonable timeframe. And then there is the safety of data and regulations which is creating the discussion about public and private clouds (shared usage or just for your company) and hybrid models between your infra and the cloud.

As did Tim Anderson :

I've just attended my first cloudcamp unconference, held during QCon London. We ended up debating how you would explain cloud computing to a non-technical audience. The problem is that different people mean different things by the term. [...] I suppose it is appropriate that the cloud term is fluffy. To some it is synonymous with the Internet; to others it means SAAS applications; to others it means virtual servers running who knows what; to others it means a hosted application platform (platform-as-a-service or PAAS).

The problem with vague terms is that they make discussion difficult.

My favourite usage: cloud computing means exporting IT infrastructure to the Internet.

关于QCon本身的意见

Many people expressed opinions about the conference as a whole, including Sebastien Auvray :

To make it short, it was a great moment of thoughts and convivial discussions. It is by far the best conference and IT event I attended so far for different reasons:

• It covers an extremely broad spectrum of the IT World. With 5 main tracks at the same time during the whole days, the content is well diversified: Languages (functional, mainstream, ...), Architecture, SOA, Agile, Performances, Finance and a newly very original track about Historically bad ideas.
• The panel of speaker is incredible: Sir Tony Hoare (Quicksort inventor and much more), Martin Fowler , Joe Armstrong (father of Erlang ), Rich Hickey ( Clojure inventor), Ola Bini (JRuby developer and more), Rod Johnson (Spring Inventor), Dan North , Eric Evans (Mister DDD), and many more... Now you have an idea of the amount of experience and research accumulated by such a group of people.
• It is not polluted all around with commercial presentation with stuff to sell.

Steve Vinoski:

QCon is always very, very good, but QCon London 2009 last week was the best one yet.
[...]
If you have any interest at all in leading edge software and computing topics being presented by the world's most knowledgeable speakers in a fun atmosphere, go to QCon. I guarantee you won't be disappointed.

Gojko Adzic ：

QCon London 2009 took place last week at the Queen Elisabeth II conference centre, reconfirming QCon's place as the undisputed champion of IT conferences in the UK. With a really fantastic line-up of speakers and very strong technical content at the bleeding edge of software development today, the conference managed to attract quite a large audience. I don't know the official figures but my impression was that 400-500 people were constantly there, which is a real achievement especially since very few companies have money to spend this year on conferences.

Sam Aaron :

This week I was privileged enough to attend QCon London and now I'm finding myself in the unfortunate position of attempting to representatively summarise the vast enormity of wonderfully exciting moments that constituted the event. Essentially the conference as a whole is a superlative occasion chock full of super interesting people, conversations and experiences.

The conference attracts Software experts from all walks - language designers (such as Joe Armstrong, Ola Bini and Rich Hickey), agile coaches (such as Linda Rising and Gabrielle Benefield), SOA experts (such as Jim Webber, Ian Robinson and Stefan Tilkov) and just a ton of really interesting people and subjects. One of the great aspects of the conference is that it is divided into tracks, each lasting a day and each having a curator who selects and organises the speakers for that track. I think that this is a really great way of organising things and provides a much more consistent feel to the event as a whole.

奥拉·比尼 （ Ola Bini） ：

All in all, QCon London this year was amazing. I find it interesting that from the first time I attended QCon I thought they were exceptionally good. And every time they keep getting better. Of course, it is fantastic to be able to meet all these great people at the conference, and you get lots of chances to hang out with them, ask questions and have discussions. But if you take a look at the presentations offered, they all feel very fresh and the quality is consistently of a very high level.

Peter Maas :

All in all, QCon 2009 was probably the best conference I've ever visited. I've learned tons of really useful stuff. Not only from a technological point of view, but from a social point of view is well. It is delightful to hear how other people are solving or have solved the same problems as I am. I really hope to visit QCon 2009 next year as well!

Kirk Wylie :

I'm back at my cash money day gig after spending yesterday at qCon London , where I gave a presentation on RESTful approaches to financial data integration . Before I went, I have to say that I was a little down on the conference thing in general, having attended (and spoken at) way too many that were either just Vendor Drivel ("Got a problem? Buy my solution!") [1], or Preaching To The Converted ("Technology/Methodology X is great! Aren't we all so clever for noticing it?"). qCon has largely restored my faith that it's possible to put together an excellent technical conference that's relevant for the way we communicate about technical subjects today.

Danny Lagrouw :

Looking back, I'm very much impressed by these three days of QCon London 2009. Biggest plus of the conference was its small scale. With just about 400 visitors, you're likely to run into speakers during breaks, so it's easy enough to talk to some of them informally. Likewise, sessions are smaller scaled, the conference rooms are smaller, you're quite close to the speakers. But more importantly: these speakers all proved to be excellent. Subjects that were covered weren't limited to Java, or to some vendor, but seemed to come directly from day-to-day experiences of professional architects and developers. That made them recognizable and means you can learn from them. And I've even had to miss many more interesting - parallel - sessions. My conclusion on the whole: I'm looking forward to next year's QCon!

Nik Silver :

I didn't get to see as much at QCon as I'd like to have done, although I dare say most people will say that, even if they went to as many sessions as was physically possible. But what I did see was fascinating and thought-provoking, even when it came from people I work with every day.

埃里克·约翰逊 （ Erik Johnson） ：

QCon is special because of its focus on solutions and practices without the usual vendor gravity. Sure, there is some hype lurking in the rafters. But the presenters are genuine problem solvers and conversations are intense, productive, and technical. The conference studies emerging topics in software development that people actually exploit. Those with traction, like functional programming, REST, and agile development gain industry velocity and become a bigger part of following conferences.

Richard Banks :

It's been a really enjoyable conference so far and everyone I've talked to has been really friendly, plus it's been great to meet and chat to a few of the people in the industry I really respect (I'm resisting the urge to do some name dropping). It's got quite a different feel to a Tech.Ed conferencce. 没有好坏，只是有所不同。 Firstly the numbers are smaller so it feels more intimate, and there are people from the Java, Ruby and even Erlang communities here so there's a much broader view of some of the topics, plus there are no IT Pro's here - it's all just developers.

And InfoQ co-founder Alexandru Popescu :

I know I may be accused of being subjective (as I am one of the InfoQ co-founders which is the co-organizer of the event), but people that know me and those that have participated at least once at QCon will know that what I'm going to write stands true.
[...]
You might wonder why I do think that QCon is better than other events to connect with people. The reason is that most of the people participating at QCon (speakers included) are spending their time at the conference (as opposed to just flying in, delivering the presentation and leaving), correlated with the fact that the conference is not , plus the venue, plus the parties will offer you enough time to get to these guys. All you need to do is just come and have the guts to walk to whoever you want to meet and say Hi!

外卖

In addition to talking about the conference itself, several people wrote about things that happened as a result of discussions or presentations at QCon, including Sebastien Auvray :

• It's funny to see the success of retro-engineering and empiric architectures or languages: REST, Erlang. Compared to Sun's first-specify-then-implement approach.
• QCon is a tasty moment for a computer science enthusiast like me but well it's so frustrating to see the IT enterprise reality: java, java and java and the rest only for the Happy Few ... And in big structures even when you would be pushing to adopt more suited solutions discovered at QCon (or wherever: blogs, ...), there will always be a higher ranked guy who is reluctant to changes and everything it implies.

[...]
So well, as soon as the videos are out on InfoQ , you must absolutely have a look at the following presentations:

• Opening Keynote: The Science of Computing and the Engineering of Software by Sir Tony Hoare,
• Null References: The Billion Dollar Mistake by Sir Tony Hoare,
• Erlang: A language for programming reliable systems by Joe Armstrong,
• Persistent Data Structures and Managed References by Rich Hickey.

And interviews:

• REST for SOA: Using the Web for Integration with Ian Robinson & Jim Webber.

Peter Maas :

• Stories are important, teams need a 'Shaman' who is capable of explaining why specific choices where made in the past
• Wise architects only need to have one answer to be capable of anwering any question: it depends...
• Architects and developers tend to try to solve problems in far to generic ways. Generic systems don't tend to deliver the best end-user experience.
• 300 messages a second on twitter doesn't sound like a lot. They are however send to a lot of followers!
• On the question of why twitter decided to built their own messaging queue instead of using an existing one (ie. JMS) they answered: well, our current solution is about 1200 lines of scala and perfeclty fits are needs. No other product could offer us that.

Kirk Wylie :

[...] There's still value in qCon for those who don't attend. Slides are online immediately; people blog about it during and after; interviews are performed and posted to web sites; presentations are filmed and trickled out over the course of the year; interesting points from most talks are tweeted out. You can still benefit from qCon even if you don't attend, but if you do, you're just a greater part of it, as you're at the core. And that's precisely how qCon to me seemed extremely relevant in the internet communication era.

蒂姆·安德森 （ Tim Anderson） ：

I was here last year, and my observation is that last year there was considerable angst about the idea that the SOAP stack was failing to deliver and that new stacks based on REST were the thing to do. This year this same statement feels more widely accepted and people are moving on, based on that assumption.

Danny Lagrouw :

Overall, Scala played a somewhat strange role during the conference. It was mostly in the air. Nobody was explicitly fanatical about Scala; even the speakers doing the Scala talks were most enthusiastically watching Hickey's Clojure sessions. And of course, in Hickey's view, Scala must be evil, as it's still object oriented (besides the functional elements it does contain). On the other hand, more and more people I talk to are convinced that Scala would be the best sequel to Java; and less and less people think the more complex and extensive possibilities of the language will be too high a barrier.

亚历克斯·斯考德利斯 （ Alex Scordellis） ：

In conclusion, I enjoyed all the sessions and heard some interesting things. But the biggest lesson I'll take away is to go to talks about things I don't know about, not things I do. I'm sure I'd have learnt a lot more new ideas in Rich Hickey's Clojure presentation than in Michael and Steve's TDD history. Not through any fault of Michael and Steve (and I certainly don't want to pick on them), but because I've read a lot of that stuff before. There were also a number of talks on web architecture and RESTful services that I'd like to have caught. I also wish I'd taken notes in more of the sessions; as well as helping me take more of the information on board it would have helped me writing this post!

And Mark Needham :

One of the big takeaways for me from the Domain Driven Design track at the recent QCon London conference was that the organisational patterns in the second half of the book are probably more important than the actual patterns themselves.

结论

QCon London was a great success and we are very proud to have been able to offer such a conference. 它将继续是伦敦和旧金山的年度盛会，下一届QCon将于明年同一时间在每个地点举行。 This year also marks the first year that we are bringing QCon into other regions which InfoQ serves, namely China and Japan . Thanks everyone for coming and we'll see you next year!!!!

翻译自: https://www.infoq.com/articles/qconlondon-2009-summary/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

qcon