大树底下

Visual Studio 11 beta支持C++硬件加速特性

大树 — Thu, 09 Feb 2012 10:24:06 +0800

微软周五宣布了C++ Accelerated Massive Parallelism (AMP)规范，它可以让C++开发人员编写出来的程序可以调用图形卡硬件加速，下一个版本也就是Visual Studio 11的beta版本中已经开始这项工作。C++ AMP是微软Visual Studio和C++编程语言的新扩展，用于帮助开发人员充分适应现在和未来的高度并行和异构计算环境。
之前微软在VS中完成的多核心运算支持已经让许多程序对CPU的利用率提升，而对GPU的支持度将是下一个要解决的课题。目前微软已经和AMD、NVIDIA等公司一道准备开放标准的细节，不久后开发人员就可以享受到更广泛的异构硬件加速支持。

2 comment(s) for this post:

Droopy:
09 Feb 2012 好家伙，，福音来了
大树:
09 Feb 2012 嗯，微软这几年在vs上下的功夫很大

写个评论

舞台

大树 — Wed, 08 Feb 2012 22:14:06 +0800

没有不下台的演员，
也没有不散场的观众，
一百零一次的鼓掌，
还是有一百零二次的落幕，
走吧，
雨总在无声地飘落，
泥土并不是它的墓园，只有长长的路，
才是真正的，
热情的，
真实的付出。

这是刘湛秋的一首诗，初三的时候看到的，很喜欢。今天浏览自己的博客的时候，又从老弟的留言里看到，读来依然很感动。
有些东西，是永恒的，就算经过很多岁月，依然能不经意地挑动你的心。
本来想发在人人上，感怀一下即将结束的研究生生活，踟躇甚久，最后还是存了草稿。
想想四年前，博客最热的时候，写一篇博客然后跟朋友们交流，很欢乐。如今却是浮躁了很多，状态了，微博了，却失了沟通了。

发在这里，权当纪念吧。

写个评论

何时使用元素，何时使用属性–探讨 XML 设计中的老问题

大树 — Thu, 26 Jan 2012 21:19:32 +0800

本文转载自：http://www.ibm.com/developerworks/cn/xml/x-eleatt/

作者：Uche Ogbuji (uche.ogbuji@fourthought.com), IBM首席顾问, Fourthought, Inc.

简介： 采用 XML 的人遇到的老问题是，在 XML 的设计中什么时候使用元素，什么时候使用属性。对于多数设计而言，这个问题很少有绝对的答案，但是开发人员也确实体会到缺乏明确的原则来帮助他们作出决策。本文中，Uche Ogbuji 就什么放在元素中什么放在属性中提供了一些指导原则。

发布日期： 2004 年 3 月 01 日

在 SGML 中，DTD 设计的几个经常要考虑的问题也遗留给了它的分支 XML。无论使用什么 XML 模式语言，您都需要问这样的问题：

什么时候使用元素，什么时候使用属性来表示信息位？
什么时候需要对元素排队，什么时候不需要考虑顺序？
什么时候需要对类似元素的序列使用包装元素？

根据我和 XML 用户打交道的经验，最常见的还是第一个问题。一些情况下答案是很明确的：

如果涉及到的信息本身能够用元素标记，就把它放在元素中。
如果信息适合采用属性的形式，但可能造成同一元素中有多个同名的属性，则改用子元素。
如果信息需要作为类似标准 DTD 的属性类型，如 ID 、 IDREF 或 ENTITY ，则使用属性。
如果信息不应该进行空白字符规格化，则使用元素。（XML 处理程序规格化属性的方式可能改变属性值的原始文本。）

不幸的是，设计决策很少能进行这种明确地划分。在灰色的区域中问题仍然是如何进行正确的选择。一般的答案是 没有单一正确的答案，取决于您的最佳判断。但这对于那些希望熟悉 XML 的人来说没有多少帮助。事实上，在某些情况下即使专家也不一定意见一致，但是这并不成为不能提供在元素和属性之间选择的一些基本原则的理由。

首先，我想提出曾经听到但不建议这样做的两条原则。我曾经听过 统统使用元素这样的建议。理由包括 属性使事情变得复杂以及 属性会影响可扩展性等等不一而足。但是如果不使用属性，就抛弃了 XML 强大功能的一个重要方面，您可能最好是改用某种分隔文本格式。

我也听说过 如果是希望在浏览器中显示的那类材料，就使用元素内容。这个原则的问题是鼓励人们根据表示考虑 XML 的内容设计，这两种问题不应混在一起。本文中也提出了一条非常相似的原则，但我是根据内容的用途而不是表示来阐述的。

本文的其他部分将提出一些指导原则，建议在元素和属性之间进行选择时采用。

推荐的指导原则

我把这些指导原则分解成了一些规则，希望能够从总体上说明元素和属性之间的选择。没有哪个规则是绝对的，可以将其作为经验规则使用，如果确实需要完全可以打破这些规则。

核心内容原则

如果认为要处理的信息属于用 XML 表示或传达的基本资料，就将其放在元素中。对于供人阅读的文档一般是指向读者传达的核心内容。对于面向机器的记录格式一般是指直接来自问题域的数据。 如果认为该信息对于传递的主要信息而言是外围的或者附属性的，或者单纯用于帮助程序处理传递的主要信息，则使用属性。这样可以避免把核心内容与辅助资料混在一起。对于面向机器的记录格式而言，这一般是指来自问题域主数据上的特定于应用程序的符号。

比如，我曾经看到过许多 XML 格式――通常是业务中自动生成的――文档标题被放在属性中。我认为，像标题这样的文档信息基本组成部分应该作为元素内容。另一方面，我也常常看到这样的情况，内部用的产品标识符被作为元素放在产品的描述记录中。其中的一些情形采用属性更合适，因为特定的内部产品代码不会成为多数读者或者文档处理人员关心的主要目标，尤其是如果 ID 非常长或者采用难以理解的格式。

您也许曾经听说过这样的一条原则， 数据使用元素，元数据使用属性。上述两段实际上表达的是同样的原则，只不过使用了更加慎重、更加明确的语言。

知名的例外

我曾经小心地指出，这些设计原则是很灵活的，肯定会找到一些理由打破这些原则。此外，您还会发现需要在不同原则的取舍之间平衡。在许多标准 XML 词汇表中，都有一些设计决策有意地违背了本文提出的一些原则。这是一些例子。

SVG 向量路径在单个属性中用一些空格分隔的数字表示，与 结构化信息原则 相抵触。之所以这样做是因为 SVG 对简洁性的要求很迫切，但是因为这样增加了 SVG 格式处理的复杂性而受到批评。
许多格式都允许在属性中使用级联样式表（CSS）样式（如 XHTML 1.0 和 XSL-FO）创建复杂的样式描述，混合使用多个面（ facet）和度量单位。这样做与 结构化信息相矛盾。有趣的是，在 XHTML 2.0 中这已经不再是一个问题了，因为这个版本只允许指定一个类标记来映射到单独的 CSS，不能再使用内联的样式属性。

结构化信息原则

如果信息用结构化的形式表示，特别是如果这种结构可能需要扩展，则使用元素。另一方面， 如果信息用原子记号表示则使用属性。元素是 XML 表示的结构之所以能够扩展的动力源。差不多所有的 XML 处理工具都围绕着这一事实设计，如果能够把结构化信息正确地分解到元素中，您就会发现处理工具可以与您的设计互补，从而提高的生产率并获得了可维护性。属性用于表示元素所表达信息的简单性质。如果违背了 XML 的基本结构，把结构化信息硬塞进属性，可能表面上您似乎获得了简练和便利，但可能要付出维护的代价。

日期是一个很好的例子，它有固定的结构，并且一般作为单个标记，因此作为属性非常合理（更适合用 ISO-8601 表示）。另一方面，我发现在个人姓名的表示中这一原则令设计者感到惊奇。我曾经看到许多放在属性中的姓名，但一直坚持个人姓名应该作为元素的内容。个人姓名有着令人吃惊的可变结构，在一些文化中，如果忽略了尊称或者姓名中各个部分的先后顺序，可能会造成混乱或者冒犯他人。个人姓名也很少作为原子标记，比如有时候会按照名称有时候则按照姓氏排序。还应该指出，如果把整个姓名完全塞进一个元素的内容中或者放在属性中一样会造成问题。因此：

<customer>
  <name>Gabriel Okara</name>
  <occupation>Poet</occupation>
</customer>

比下面这种表示强不了多少：

<customer name="Gabriel Okara">
  <occupation>Poet</occupation>
</customer>

我希望在将来的一篇文章中展开讨论关于姓名的处理。

可读性原则

如果信息是供人们阅读和理解的，则使用元素。一般而言，这一原则是把没有结构的信息放在元素内容中。 如果信息主要是方便机器理解和整理，则使用属性。一般来讲，这一原则是指把不是自然语言的信息标记放到属性中。

在一些情况下，人们可以解释所表达的信息但是需要机器正确地使用它们。URL 是一个很好的例子，人们已经学会了在 Web 浏览器或者电子邮件消息中显示的 URL，但是如果没有计算机获取引用的信息，URL 通常没有多少用处。一些数据库标识符也很容易理解（尽管已经建立的数据库管理最佳实践不鼓励使用带有业务意义的 ID），但是这类 ID 通常是机器处理的小道具。基于这些原因，我建议把 URL 和 ID 放在属性中。

元素/属性绑定原则

如果需要根据另一个属性改变它的值则使用元素。XML 在属性和包含它的元素之间建立了非常强的概念联系。属性提供了那个特定元素的一些特性或者修正。XML 处理工具往往都遵循这种概念，让一个属性改变另一个属性通常是可怕的想法。比如，如果要设计一种菜单格式，而且菜单上包括菜量，您可能认为这些信息对一般的菜单格式读者而言并不重要，因此应用 核心内容原则将其作为属性。第一种尝试就是这样：

<menu>
  <menu-item portion="250 mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion="500 g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

按照 结构化信息原则，您决定不把菜量和度量单位放在一个属性中，而是使用一个元素，于是选择以下格式：

<menu>
  <menu-item portion-size="250" portion-unit="mL">
    <name>Small soft drink</name>
  </menu-item>
  <menu-item portion-size="500" portion-unit="g">
    <name>Sirloin steak</name>
  </menu-item>
</menu>

现在属性 portion-unit 修正了 portion-size ，而我已经提到这不是一种好主意。元素 menu-item 上的一个属性应该修正那个元素，而不是其他的内容。应该改变这种方案而采用元素：

<menu>
  <menu-item>
    <portion unit="mL">250</portion>
    <name>Small soft drink</name>
  </menu-item>
  <menu-item>
    <portion unit="g">500</portion>
    <name>Sirloin steak</name>
  </menu-item>
</menu>

在这个例子中，我结合使用了 核心内容原则 和 可读性原则，决定把数量作为元素内容而把度量单位放在属性中。这是一种不那么固定的情形，其他的方案可能同样合适。这种方案也与最初的决策相抵触，本来按照 核心内容原则 菜量应该放在属性中。这说明有时候这些原则可能得出互相矛盾的结论，您必须根据自己的判断具体情况具体分析。

回页首

什么也不能代替学习和实践

XML 设计对于专业人员来说是一个问题，如果要从 XML 中获益就应该有志于研究 XML 的设计原则。许多开发人员承认编写代码能够从精心的设计中获益，但是对于 XML，他们却认为只要看起来能工作就够了。我曾经看到这种区别造成了真正的、痛苦的代价。学习那些合理的 XML 设计所能带给您的经验就是要注意这个问题。对专家设计的标准 XML 词汇表进行分析，记录下您自己的设计决策，评价每个决策在后续设计中的积极和消极影响。一旦取得了经验，您的直觉就会成为做出设计决策的最重要的工具。如果您发现自己在任何重要的领域使用 XML，您的努力也就获得了回报。

我计划在将来的文章中像本文一样继续讨论 XML 的设计原则。我还将在我的 Thinking XML 专栏中继续简要地触及 XML 设计原则。如果您对 XML 设计有什么想法和问题，请在 Thinking XML讨论论坛上发表。

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文.
看一看知名的 Cover Pages，它提供了关于该主题的一些信息，集中在以下页面上： SGML/XML: Elements versus attributes, 1998 年 4 月和 SGML/XML: Using Elements and Attributes。
阅读 Elliotte Rusty Harold 的 Effective XML （Addison-Wesley, 2003）。根据我的体会，作者非常精通 XML 设计和最佳实践。您可以在线阅读部分章节，包括“ Store metadata in attributes”和“ Make structure explicit through markup”，它们都与本文的内容有直接的关系。
可以在 developerWorks XML 专区找到更多 XML 资源。特别是在我的 Thinking XML 专栏中有时也触及一些问题。您还可以在 XML 实用技巧中找到许多这样的文章。
IBM WebSphere Studio Application Developer 是一种支持使用各种不同的技术（如 XML、JSPTM、sevlet、HTML、Web 服务、数据库和 EJB ）构建多种应用程序的开发工具。
在 developerWorks Developer Bookstore上可以找到大量关于 XML 的书籍。
了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。

关于作者

Uche Ogbuji 是 Fourthought Inc.的顾问兼创始人，该公司是专为企业知识管理提供 XML 解决方案的软件供应商和咨询公司。 Fourthought 开发了 4Suite，这是一个用于 XML、RDF 和知识管理应用程序的开放源代码平台。Ogbuji 先生也是 VersaRDF 查询语言的主要开发者。他是一位出生于尼日利亚的计算机工程师和作家，在美国科罗拉多的博耳德生活和工作。可以通过 uche.ogbuji@fourthought.com和 Ogbuji 先生联

2 comment(s) for this post:

北京温泉:
06 Feb 2012 喜欢旅游的朋友路过
行业报告:
07 Feb 2012 这写的。。。

写个评论

美国国债是怎么回事儿

大树 — Sat, 24 Dec 2011 06:43:20 +0800

中国持有美国国债达10000多亿美元，这句话的含义是什么？

美国国债是如何形成的？这要从美元这种债务货币说起。所谓债务货币，就是指以举债的方式获得信用，并基于此信用发行的货币。

简单地说，美国向他国借来各种信用抵押品（黄金、货币、产品），然后以此作为抵押，发行美元。到一定的期限时，归还此抵押。

基本上，美国当前有多少国债，它便发行了多少美元。

那么中国购买了10000亿美元的美债，究竟意味着什么？

假设当前人民币兑换美元是6：1，中国一次性购入10000亿美元的美债，那么意味着中国拿来60000亿人民币，交给美国。

美国拿到这60000亿人民币以后，它就发行10000亿美元的新货币。

此时假如中国出口商品到美国，那么，美国就可以使用这10000亿新美元进行支付购买。

表面上看，是美国使用中国给的钱买中国的东西，中国亏大了。

实际上，中国确实是亏的。不过没有亏在这里。

我们继续上面的场景。假如我们卖了10000亿美元的产品给美国，此时我们将持有这10000亿美元，然后我们又从美国买了10000亿美元的电子产品。

这时候发生了什么？中美两国交换了价值10000亿美元的产品，此外什么都没有发生。

美元在这里，就是起到了一个最基本的交易手段作用。

那么我们拿给美国的60000亿人民币呢？美国会定期归还本金和利息，到一个期限后还清。

也就是说，我们在一段时间内抵押了60000亿人民币给美国，美国回报给我们一定的利息——借人民币，还美元。

这桩买卖划不划算，取决于利息的高低和美元相对于人民币是否贬值。

那么，为什么美国要支付利息给中国？理由是中国为美国提供了信用，进而使得美国可以发行美元以提高交易效率。也就是说，所有使用美元的人、公司和经济体实际上都受益于中国提供的信用，也就是说所有使用美元的人都应该支付此利息。而事实上，只有美国为此支付利息。因此，理论上当美元发行量够大的时候，美国每年的GDP会还不起美债的利息，然后美国会破产。

当然以上都是理想情况，就是说美国每一次美元发行都有相应的抵押品，而不是随意发行美元。

但实际上，美国做不到这一点。大名鼎鼎的”量化宽松“政策，使得美国可以光明正大地凭空印钞，然后美元贬值，从而将利息压力直接转嫁给别国——包括中国自己。这个东东，术语叫做”铸币税“。

综上所说，基本上你可以认为美国是借债少给利息、不给利息，甚至连本金都给你缩水的类型。这才是中国持有美国国债亏本的地方。当然如果某一天美元贬值到0，那中国也就血本无归了，这就真的亏大了。

货币发行权是最高的经济权力，这话一点都没差。

写个评论

货币体系的稳定性和货币币值的稳定性分析

大树 — Sat, 24 Dec 2011 05:39:58 +0800

货币币值稳定的定义。本定义是指，是指同样数量的货币，在时间点t1和时间点t2，其购买能力一致。

在此我们假设商品只有一种，那么具有良好价值尺度功能的货币，在任何时间点购得的商品数量一致。

这种假设意味着货币既不能升值也不能贬值。

货币体系的可行性定义：在满足良功能的前提下，保持货币体系稳定。

金本位货币的定义。所谓金本位货币，是指以黄金为抵押发行的货币，货币可以按照一定比例兑换抵押物。

金本位货币的可行性定义：满足良功能，同时抵押品不会被兑换完。

Question：

金本位货币是否具有可行性？如果是，那么其限制条件是什么？

My Answer：

假设以100单位的黄金作为抵押，发行10000个单位的货币，同时社会总财富（含抵押品）为10100单位。

此时一单位货币兑换一单位商品，或兑换0.01单位的黄金。我们假定此时是稳定状态，即0.01单位的黄金，其价值==1单位商品。此时如果所有人将货币兑换为黄金，则货币作废，同时黄金全部被兑换，两清。

一年后，社会总财富增长10000单位，到20100单位。

此时如果增发10000个单位货币。一单位货币将仍兑换一单位商品，实现稳定币值。但一单位货币只能兑换0.005单位黄金。即1单位黄金==2单位商品。假设社会总财富预期仍将增长，则可认为当下黄金价值被低估，持有黄金将获益，因此黄金将被大量兑换，货币体系无法维持。

如果增发10100个单位的货币，则单位货币能兑换的商品不足一单位，意味着货币贬值。

金本位货币的可行性不足。在经济增长的前提下，要么持续贬值，要么体系崩溃。

债务货币的定义。债务货币是指通过举债方式，获得抵押品，并据此发行的货币。同样，货币可以兑换抵押品。债务货币不同于金本位的特点有二：一是债务规模可变，二是债务可能需要付利息。注意，这里如果抵押品不是黄金等只有价值而基本无使用价值的商品，则造成使用价值的损失。

Question：

债务货币是否具有可行性？

My Answer：

根据借债对象的不同，分为两种。一种是在本经济体内借债，一种是对外部经济体借债。

根据借债规模的不同，分为两种。一种是债务规模小于社会总财富，一种是债务规模等于社会总财富。

对内借债且债务规模等于社会总财富。此方案实际无法实现——一个经济体不可能将其所有财富用于抵押。不过实际上不采用抵押方式，而采用强制力保证货币的兑换，却是可行的，这就是法币，这里不赘述。

对外借债且债务规模等于社会总财富。此情况下肯定要付给借债方利息。因为抵押品由外部提供，所以币值稳定肯定可以保证（只需按社会总财富提供即可，当然这里假设借债方的抵押品足够）。假设借债方规模无限的情况下，此体系同样不会崩溃。理论上此体系可行。但是现实中基本不可行——抵押品不可能太多，利率常常超过社会财富增长速度，从而导致经济负增长。

对内借债且债务规模小于社会总财富。假设初期为平衡状态，即社会财富的一半被抵押。假设社会总财富20000，抵押10000，使用中10000，发行10000货币。一年后，使用中财富增长20%，即社会总财富为22000。此时如增发2000货币，即总流通货币12000，可维持币值稳定，且不增加举债规模，但这同金本位一样，会引起抵押品被挤兑。如增发1000货币，同时增加1000举债，则可维持币值稳定——但同样不可行，因为这样的话举债规模始终占社会总财富的一般，浪费太大。

对外借债且债务规模小于社会总财富。这个情况没什么意义，抵押失效。

债务货币和其类似体中，只有法币是理论上可行的。

写个评论

Facebook，F8大会，Web 3.0和新鲜的屎

大树 — Thu, 13 Oct 2011 12:42:28 +0800

晚睡晚起的时候，脑子总是清醒的像一坨新鲜的屎一样，明艳、活泼、有力。

我不准备跟你解释原因，因为我决定趁着这屎还够新鲜的时候，把脑子里的一些东西记下来。

起因是早上看到了一篇文章，《从2011年F8大会看Facebook的野心》。于是又顺路关注了一下F8大会：http://tech.sina.com.cn/z/f82011/index.shtml。

简言之，Facebook继续推进他们在去年提出的Open Graph理念，将外部内容和服务整合进Facebook的页面。有点像百度提出的“框计算”。

此举很明智。理由如下：

1.只有给用户提供价值的产品和服务才能存活

2.SNS提供的基本价值是更新用户的社交信息，但这点价值不足以支撑任何一个SNS平台的存活

3.SNS必须不断获得更新、更深入的用户信息才能提升服务

4.分享新鲜事的热情下降以后，用户必然寻求有价值的信息和服务，而不是继续产生垃圾信息

5.引入外部内容和服务后，Facebook既能提供给用户更多有价值的信息和服务，又能获得更深入的用户信息

我记得李彦宏刚提出框计算的时候，就有那么一撮人叫嚣：炒概念，没技术含量，百度的搜索做得差。这种人，你把“给用户提供价值”这样明艳、活泼、有力的一坨屎放在他的面前，他都会勇敢地踩上去。你看百度像是打算好好做搜索的公司么？

百度明显就是要做社区的么！

我突然又想起一点，那就是即使同样提供有价值的内容和服务，那你以什么的样的形式提供，也是非常要紧的。比如说最近涌现出来的各种问答社区，何其地传统，何其地循规蹈矩，何其地像他娘的百度知道！

既然是问答社区，难道不应该像人类之间的问答一样么？一个框就够了，我输入问题，如果能找到答案，立即显示；否则，就立即把问题post出去，推给有可能知道答案的人。

所以你看，有两个很关键的点，一个是立即，一个是推送。

当然，现在的问答社区有点推送的模样，但是远远不够即时。我来请教个问题，不想等到黄花菜都凉了。

最后，我认为用户价值就是两点：第一，有用；第二，用得爽。

我觉得这个总结也是非常明艳、活泼、有力，像一坨新鲜的屎一样。

题外话：你看马克的手势，刚好和乔布斯的标准演讲手势相反，马克内敛、乔布斯开放。其实，乔布斯的意思是，你们赶快来用我的产品，所以他要用推的手势；马克的意思是，你们丫的都来我的平台帮我整内容啊，所以，他要用抱的手势。

3 comment(s) for this post:

知识海:
19 Oct 2011 施主也是。。。
减肥方法:
28 Oct 2011 写得很好啊，非常有同感。减肥方法www.xbyzxkafei.com/
灰指甲的治疗方法:
29 Oct 2011 你们丫的都来我的平台帮我整内容啊

写个评论

Steve Denning在Agile2011上谈“让客户愉快”

大树 — Tue, 06 Sep 2011 12:04:47 +0800

在Agile2011大会上，图书作者和管理咨询师Steve Denning作了两次演讲：“让整个组织敏捷起来”和“让客户愉快”。

第一个演讲中，他先回顾了为什么有那么多好想法在大组织中都会失败，一一审视了很多“20世纪方式管理”的企业中发起的诸多运动，比如知识管理、精益制造、大市场想法、创新等等。他指出：传统企业依赖5条互相紧密联系的原则：

公司的目的是要制造产出，赚取金钱。
管理者扮演个人控制者的角色。
工作由组织层级和官僚关系协调。
“效率是王道”。
沟通靠指令。

他认为：对于组织来说，这5条原则在21世纪已经不再高效；实际上，它们是有害的，会让一直坚守这5条原则的组织最终走向失败。他的中心思想简单明了：传统管理方式已经失效！接下来，他又引用了一些证据来支持自己的观点：

自1965年开始，资产回报率已经下跌了75%。
财富500企业的平均寿命已经降到15年，而且正在向5年跌落。
每5个工人中只有1个工人能够全情投入。

（来源：德勤领先创新中心：2009变换指数）

然后，他提供了21世纪的管理5个势在必行的目标：

组织要有新目标
管理人员的新职责
新的协调机制
从单一价值观向多元价值转换
新的沟通方式

接下来，他对这些目标做了详细阐述：

组织的新目标必须是“让客户愉快”。如果组织希望在与客户的每次交互中都能让客户愉快，必须要知道：仅仅满足客户的需要是不够的，组织中的所有人应该表现出：“我们希望了解并帮您解决您的问题”，并尽全力找出让客户愉快和兴奋的方法。这一点的重要性超越了采纳新实践（可以有所帮助），超越了新的营销方法（可以有所帮助），超越了效率（可能有帮助，但常常变成障碍）。他指出：

目标是“一直让客户愉快”。“赚钱”不是目标，“持续敏捷”不是目标，“可工作的软件”不是目标，敏捷、Scrum和可工作的软件是达成目标的手段。所有人都要以此目标为中心。

他引用了一些组织的例子，这些组织关注让客户愉快，由此带来强烈的客户忠诚度和增长的利润。Zappos是其中一个例子，这是一家在线售鞋的公司。他说：

Zappos以24×7的方式运作它的库房，这不是运作库房的有效方式。客户们很高兴享受免费配送，当他们在美国东部时间半夜下单，并能在8个小时候的拿到鞋子的时候，他们非常愉快。

另一个方法是简化产品和服务，而不是追求海量功能（想想iPod简单的控制，再看看DVD播放机有107个按钮的遥控器，家里没人会正确使用）。解决正确的问题，而不是试图同时解决过多问题，却由此造成困扰。

尽早交付是另一个重要原则：客户的愉快常常来自尽早得到更瘦的解决方案，而不是等很久才能拿到“完整的”产品。

阅读客户的心态，预期他们的需要，而不是等待焦点调研小组和调查。“没人让苹果做iPod、iPhone或是iPad。”

要评估客户的行为，而不是他们的言词。他在这里讨论了“新的可乐”：焦点调研小组报告说它喝起来更可口，应该卖得更好；但现实是，无数声音要求换回旧口味。

让你的客户与你一起创造。客户定制和产品配置能在市场中让客户愉快，今天的计算机技术很容易可以做到这一点。

不再做无法增加价值的事情——消除浪费，把重心放在能让客户愉快的东西上。

度量——客户的愉快可以度量。这里他提到“净推荐值（Net Promoter Score）”【译注】，这个概念来自Fred Reichheld的书《终极问题》，还指出：组织能够度量客户对他们的满意度非常重要。

总结“让客户愉快”，他将其描述为“以流的方式持续不断地为客户提供附加值，并尽早交付这些附加值流。”

敏捷技术有助于让客户愉快，今天，聚焦于让客户愉快的组织正在赚取大笔金钱。他以Amazon.com、苹果公司和Salesforce.com作为例子，并指出这些企业的成果是赚取了大量利润。

聚焦于让客户愉快，需要其他4条原则到位，它们一起承担了企业运行完全不同的方式。

管理人员的新职责：从控制人们的行动变成让团队自组织。

新的协调机制： 从层级官僚体系向动态连接转换，以客户驱动响应活动，并在短时间周期内完成。

从单一价值观向多元价值转换： 从只关注利润的心态，转变为持续改进和高度透明。

新的沟通方式： 从“命令与控制”向“成人与成人/同侪与同侪”平等对话转变。

他说明：这些转换互相联系，并能自我强化。一次只选一个点、只做小改变是不行的。如今，真正成功的组织会同时全部采纳这些原则。

他指出：实施敏捷实践，已经开始了这五种转换中的三种；敏捷运动做有成效，但说到转变为让客户愉快，以及从命令转向对话这两方面，还有很多需要改进。

在演讲结尾，他号召敏捷推动者们：

领导革命！

自1965年开始，资产回报率已经下跌了75%。

做变更的榜样

成为战略（而不是支持战略）

以领导力的方式讲故事

挑战管理人员，让他们一起共创未来

鼓励有共同愿景的其他人

掌控未来

第一个演讲的PDF可以在这里找到。

他的第二个演讲是1个小时长的工作室项目，其中有12个练习，参加者们要基于他在演讲中提到的一系列原则和工具，识别出让客户愉快的方法。相关PDF可以在这里找到。

我们能把“让客户愉快”作为组织一心一意要达成的目标吗？您的组织这么做了吗？效果如何？

译注：净推荐值（NPS）又称净促进者得分，是一种计量某个客户将会向其他人推荐某个企业或服务可能性的指数。它是最流行的顾客忠诚度分析指标，专注于顾客口碑如何影响企业成长。通过密切跟踪净推荐值，企业可以让自己更加成功。可参考这里。

写个评论

伦敦和硅谷缺少软件工程师

大树 — Tue, 16 Aug 2011 13:00:28 +0800

最近看到的两篇报道：

伦敦缺少软件工程师

http://www.telegraph.co.uk/finance/businessclub/8688707/Lack-of-software-engineering-talent-could-derail-Londons-Tech-City.html

硅谷软件工程师缺乏

http://www.nytimes.com/2011/03/26/technology/26recruit.html?_r=2

Google和Facebook最近都提升了员工工资（20%）。

高质量的软件工程师确实匮乏，而国外的教育体制加剧了软件工程师供不应求的状况。在教育体制改革在短期内无法产生效果的情况下，可以预期，中国的软件外包业务以及海外工作中介业务将会有较多机会。

7 comment(s) for this post:

美女图片:
17 Aug 2011 嗯，三军易得，一将难求
香港保险:
30 Aug 2011 我只懂html。。
英语笑话:
31 Aug 2011 伦敦缺少软件工程师我没有那个心学
大树:
05 Sep 2011 懂html不错了……
高档手表:
19 Sep 2011 少壮不努力，老大作IT。呵呵，还是有道理的。

写个评论 | View 2 more comment(s).

您可能也喜欢：
Microhoo-微虎搜索诞生	VS2010 Pro Power Tools	C#和C++混合编程的一些tips	微软发布Windows Mobile 7操作系统
来自无觅网络的相关文章：
如梵软文赚钱培训博客的用户体验分析 (@cuike)	3C城比价网的用户体验分析报告 (@cuike)	微软必应（Bing）优化小技巧 (@cuike)	关于SEO最经典的十句大实话 (@cuike)
无觅

您可能也喜欢：
程序员写博客的利器—Google Prettify	The 200th	换了空间	分享几个腾讯微博邀请码
来自无觅网络的相关文章：
牛B博客的用户体验分析报告 (@cuike)	大懒猫博客的用户体验分析报告 (@cuike)	博客赚钱网站的用户体验分析报告 (@cuike)	经营博客的十大秘诀 (@cuike)
无觅

您可能也喜欢：
如何设计出色的ppt	Rokey-设计贴士	数据库基准测试系统通用模型设计	PostGreSQL多版本实现中的几个问题
无觅

您可能也喜欢：
从Google购物关键字看用户网上购物习惯	春哥传19-灵阳霸气	春哥传30-烽烟再起	中国地方债已上升至7万亿
无觅

您可能也喜欢：
抗通胀，不收货币万万不能	CQRS体系结构模式	春哥传15完整版-战·肆	地瓜熊老6的囧生活（四）
无觅

您可能也喜欢：
罗杰·迈克奈米:社交网络已经完结	百度数据：3C电子商务平台的用户竞争主要发生于同类平台之间	地瓜熊老6的囧生活（3）	地瓜熊老6的囧生活（8）
无觅

您可能也喜欢：
提高工作效率的方法	管理之思考：放权，不放权	测试安卓客户端的地理信息博文	【转载】让员工受不了的上司
来自无觅网络的相关文章：
力点客户管理软件官网的用户体验分析报告 (@cuike)	Nginx的客户端/服务端双向SSL证书认证配置 (@jamiesun)	推荐Twitter的聊天客户端Joint和国内的青芝网络正式推出微博语音通话助手应用 (@luoyundeng)	教你如何组织网站内部链接结构 (@cuike)
无觅

您可能也喜欢：
管理者与工程师	人人赴美IPO 历年财务数据详细解读	地瓜熊老6的囧生活（四）	春哥传第九话9：赤血溅，马王现
无觅