孟岩

[原]无题

myan — Thu, 04 Nov 2010 11:59:00 +0800

品牌建设并不是涂脂抹粉，而是脱胎换骨。你的品牌形象、用户关系、媒体关系、产业关系，并不是吹出来的，而是做出来的。把品牌目标、企业核心价值观这些东西制定出来以后，需要以巨大的决心和投入去转型，使公司实质与品牌相一致，把公司从一个单纯的经济机器，变成具有使命的社会组织，使你的存在和发展具有正义性。你与外部环境的关系和谐了，才能够得到越来越多的支持，实现长期可持续发展。否则不管多么风光一时，最终难免失道寡助，轰然倒地。

技术人建立的企业，往往都是一门心思搞产品搞技术，对于品牌的理解就是化化妆，登登广告。更傲慢一些的，不管表面上说多么重视用户，骨子里实际上觉得自己是大神，用户都是被自己的产品给控制了的低等贱人，只要自己产品做牛逼，这帮贱人一边骂也得一边用。本来这是个很糟糕的想法，更糟糕的是这个想法很多时候好像还是对的。所以一些企业养得规模很大了，品牌意识却只有小学水准，就更别提品牌建设了，只不过乱登广告而已。

平时看不出来，一掐架的时候，全暴露了。

作者：myan 发表于2010-11-4 11:59:00 原文链接

阅读：7009 评论：15 查看评论

[原]悼念 Benoit MandelBrot

myan — Sun, 17 Oct 2010 23:14:00 +0800

这个世界失去了一个卓越的大脑。

很多人都知道他，也知道他的主要贡献是分形几何，但是并不理解其重要性——不就是用来画万花筒的，有什么价值呢？

实际上，Mandelbrot的发现，可能具有如相对论一般的意义。

一大类自然现象遵循高斯分布，也就是我们通常所知道的正态分布，那个钟形的曲线。

而Mandelbrot的分形几何，可能解释另一些的自然现象，以及更重要的，人类社会现象——包括经济运行，社会状况，金融市场等等——的运动规律。

人类的社会活动无非是在不同的粗糙度上重复自己而已。

这是天才的观察，他开辟了一条路，可能改变人类未来的路。

Mandelbrot从小不善于解决数学难题，这令他身为数学教授的叔父感到失望。但是，他开辟了一个全新领域，而那些善于解题的工匠，只能在这条路上一寸一寸的前进。

作者：myan 发表于2010-10-17 23:14:00 原文链接

阅读：7558 评论：6 查看评论

[原]function/bind的救赎（上）

myan — Sat, 09 Oct 2010 00:04:00 +0800

这是那篇C++0X的正文。太长，先写上半部分发了。

Function/bind可以是一个很简单的话题，因为它其实不过就是一个泛型的函数指针。但是如果那么来谈，就没意思了，也犯不上写这篇东西。在我看来，这个事情要讲的话，就应该讲透，讲到回调（callback）、代理（delegate）、信号（signal）和消息传递（messaging）的层面，因为它确实是太重要了。这个话题不但与面向对象的核心思想密切相关，而且是面向对象两大流派之间交锋的中心。围绕这个问题的思考和争论，几乎把20年来所有主流的编程平台和编程语言都搅进来了。所以，如果详尽铺陈，这个话题直接可以写一本书。

写书我当然没那个水平，但这个题目确实一直想动一动。然而这个主题实在太大，我实在没有精力把它完整的写下来；这个主题也很深，特别是涉及到并发环境有关的话题，我的理解还非常肤浅，总觉得我认识的很多高手都比我更有资格写这个话题。所以犹豫了很久，要不要现在写，该怎么写。最后我觉得，确实不能把一篇博客文章写成一本20年面向对象技术史记，所以决定保留大的架构，但是对其中具体的技术细节点到为止。我不会去详细地列举代码，分析对象的内存布局，画示意图，但是会把最重要的结论和观点写下来，说得好听一点是提纲挈领，说的不好听就是语焉不详。但无论如何，我想这样一篇东西，一是谈谈我对这个事情的看法，二是“抛砖引玉”，引来高手的关注，引出更深刻和完整的叙述。

下面开始。

0. 程序设计有一个范式（paradigm）问题。所谓范式，就是组织程序的基本思想，而这个基本思想，反映了程序设计者对程序的一个基本的哲学观，也就是说，他认为程序的本质是什么，他认为一个大的程序是由什么组成的。而这，又跟他对于现实世界的看法有关。显然，这样的看法不可能有很多种。编程作为一门行业，独立存在快60年了，但是所出现的范式不过三种——过程范式、函数范式、对象范式。其中函数范式与现实世界差距比较大，在这里不讨论。而过程范式和对象范式可以视为对程序本质的两种根本不同的看法，而且能够分别在现实世界中找到相应的映射。

过程范式认为，程序是由一个又一个过程经过顺序、选择和循环的结构组合而成。反映在现实世界，过程范式体现了劳动分工之前“全能人”的工作特点——所有的事情都能干，所有的资源都是我的，只不过得具体的事情得一步步地来做。
对象范式则反映了劳动分工之后的团队协作的工作特点——每个人各有所长，各司其职，有各自的私有资源，工件和信息在人们之间彼此传递，最后完成工作。因此，对象范式也就形成了自己对程序的看法——程序是由一组对象组成，这些对象各有所能，通过消息传递实现协作。

对象范式与过程范式相比，有三个突出的优势，第一，由于实现了逻辑上的分工，降低了大规模程序的开发难度。第二，灵活性更好——若干对象在一起，可以灵活组合，可以以不同的方式协作，完成不同的任务，也可以灵活的替换和升级。第三，对象范式更加适应图形化、网络化、消息驱动的现代计算环境。

所以，较之于过程范式，对象范式，或者说“面向对象”，确实是更具优势的编程范式。最近看到一些文章抨击面向对象，说面向对象是胡扯，我认为要具体分析。对面向对象的一部分批评，是冲着主流的“面向对象”语言去的，这确实是有道理的，我在下面也会谈到，而且会骂得更狠。而另一个批评的声音，主要而来自STL之父Alex Stepanov，他说的当然有他的道理，不过要知道该牛人是前苏联莫斯科国立罗蒙诺索夫大学数学系博士，你只要翻翻前苏联的大学数学教材就知道了，能够在莫大拿到数学博士的，根本就是披着人皮的外星高等智慧。而我们编写地球上的程序，可能还是应该以地球人的观点为主。

1. 重复一遍对象范式的两个基本观念：

程序是由对象组成的；
对象之间互相发送消息，协作完成任务；

请注意，这两个观念与后来我们熟知的面向对象三要素“封装、继承、多态”根本不在一个层面上，倒是与再后来的“组件、接口”神合。

2. 世界上第一个面向对象语言是Simula-67，第二个面向对象语言是Smalltalk-71。Smalltalk受到了Simula-67的启发，基本出发点相同，但也有重大的不同。先说相同之处，Simula和Smalltalk都秉承上述对象范式的两个基本观念，为了方便对象的构造，也都引入了类、继承等概念。也就是说，类、继承这些机制是为了实现对象范式原则而构造出来的第二位的、工具性的机制，那么为什么后来这些第二位的东西篡了主位，后面我会再来分析。而Simula和Smalltalk最重大的不同，就是Simula用方法调用的方式向对象发送消息，而Smalltalk构造了更灵活和更纯粹的消息发送机制。

具体的说，向一个Simula对象中发送消息，就是调用这个对象的一个方法，或者称成员函数。那么你怎么知道能够在这个对象上调用这个成员函数呢？或者说，你怎么知道能够向这个对象发送某个消息呢？这就要求你必须确保这个对象具有合适的类型，也就是说，你得先知道哦这个对象是什么，才能向它发消息。而消息的实现方式被直接处理为成员函数调用，或虚函数调用。

而Smalltalk在这一点上做了一个历史性的跨越，它实现了一个与目标对象无关的消息发送机制，不管那个对象是谁，也不管它是不是能正确的处理一个消息，作为发送消息的对象来说，可以毫无顾忌地抓住一个对象就发消息过去。接到消息的对象，要尝试理解这个消息，并最后调用自己的过程来处理消息。如果这个消息能被处理，那个对象自然会处理好，如果不能被处理，Smalltalk系统会向消息的发送者回传一个doesNotUnderstand消息，予以通知。对象不用关心消息是如何传递给另一个对象的，传递过程被分离出来（而不是像Simula那样明确地被以成员函数调用的方式实现），可以是在内存中复制，也可以是进程间通讯。到了Smalltalk-80时，消息传递甚至可以跨越网络。

为了方便后面的讨论，不妨把源自Simula的消息机制称为“静态消息机制”，把源自Smalltalk的消息机制称为“动态消息机制”。

Simula与Smalltalk之间对于消息机制的不同选择，主要是因为两者于用途。前者是用于仿真程序开发，而后者用于图形界面环境构建，看上去各自合情合理。然而，就是这么一点简单的区别，却造成了巨大的历史后果。

3. 到了1980年代，C++出现了。Bjarne Stroustrup在博士期间深入研究过Simula，非常欣赏其思想，于是就在C语言语法的基础之上，几乎把Simula的思想照搬过来，形成了最初的C++。C++问世以之初，主要用于解决规模稍大的传统类型的编程问题，迅速取得了巨大的成功，也证明了对象范式本身所具有的威力。

大约在同期，Brad Cox根据Smalltalk的思想设计了Objective-C，可是由于其语法怪异，没有流行起来。只有Steve Jobs这种具有禅宗美学鉴赏力的世外高人，把它奉为瑰宝，与1988年连锅把Objective-C的团队和产品一口气买了下来。

4. 就在同一时期，GUI成为热门。虽然GUI的本质是对象范型的，但是当时（1980年代中期）的面向对象语言，包括C++语言，还远不成熟，因此最初的GUI系统无一例外是使用C和汇编语言开发的。或者说，最初的GUI开发者硬是用抽象级别更低的语言构造了一个面向对象系统。熟悉Win32 SDK开发的人，应该知道我在说什么。

5. 当时很多人以为，如果C++更成熟些，直接用C++来构造Windows系统会大大地容易。也有人觉得，尽管Windows系统本身使用C写的，但是其面向对象的本质与C++更契合，所以在其基础上包装一个C++的GUI framework一定是轻而易举。可是一动手人们就发现，完全不是那么回事。用C++开发Windows框架难得要死。为什么呢？主要就是Windows系统中的消息机制实际上是动态的，与C++的静态消息机制根本配合不到一起去。在Windows里，你可以向任何一个窗口发送消息，这个窗口自己会在自己的wndproc里来处理这个消息，如果它处理不了，就交给default window/dialog proc去处理。而在C++里，你要向一个窗口发消息，就得确保这个窗口能处理这个消息，或者说，具有合适的类型。这样一来的话，就会导致一个错综复杂的窗口类层次结构，无法实现。而如果你要让所有的窗口类都能处理所有可能的消息，且不论这样在逻辑上就行不通（用户定义的消息怎么处理？），单在实现上就不可接受——为一个小小的不同就得创造一个新的窗口类，每一个小小的窗口类都要背上一个多达数百项的v-table，而其中可能99%的项都是浪费，不要说在当时，就是在今天，内存数量非常丰富的时候，如果每一个GUI程序都这么搞，用户也吃不消。

6. 实际上C++的静态消息机制还引起了更深严重的问题——扭曲了人们对面向对象的理解。既然必须要先知道对象的类型，才能向对象发消息，那么“类”这个概念就特别重要了，而对象只不过是类这个模子里造出来的东西，反而不重要。渐渐的，“面向对象编程”变成了“面向类编程”，“面向类编程”变成了“构造类继承树”。放在眼前的鲜活的对象活动不重要了，反而是其背后的静态类型系统成为关键。“封装、继承”这些第二等的特性，喧宾夺主，俨然成了面向对象的要素。每个程序员似乎都要先成为领域专家，然后成为领域分类学专家，然后构造一个完整的继承树，然后才能new出对象，让程序跑起来。正是因为这个过程太漫长，太困难，再加上C++本身的复杂度就很大，所以C++出现这么多年，真正堪称经典的面向对象类库和框架，几乎屈指可数。很多流行的库，比如MFC、iostream，都暴露出不少问题。一般程序员总觉得是自己的水平不够，于是下更大功夫去练剑。殊不知根本上是方向错了，脱离了对象范式的本质，企图用静态分类法来对现实世界建模，去刻画变化万千的动态世界。这么难的事，你水平再高也很难做好。

可以从一个具体的例子来理解这个道理，比如在一个GUI系统里，一个 Push Button 的设计问题。事实上在一个实际的程序里，一个 push button 到底“是不是”一个 button，进而是不是一个 window/widget，并不重要，本质上我根本不关心它是什么，它从属于哪一个类，在继承树里处于什么位置，只要那里有这么一个东西，我可以点它，点完了可以发生相应的效果，就可以了。可是Simula –> C++ 所鼓励的面向对象设计风格，非要上来就想清楚，a Push Button is-a Button, a Button is-a Command-Target Control, a Command-Target Control is-a Control, a Control is-a Window. 把这一圈都想透彻之后，才能 new 一个 Push Button，然后才能让它工作。这就形而上学了，这就脱离实际了。所以很难做好。你看到 MFC 的类继承树，觉得设计者太牛了，能把这些层次概念都想清楚，自己的水平还不够，还得修炼。实际上呢，这个设计是经过数不清的失败和钱磨出来、砸出来的，MFC的前身 Afx 不是就失败了吗？1995年还有一个叫做 Taligent 的大项目，召集了包括 Eric Gamma 在内的一大堆牛人，要用C++做一个一统天下的application framework，最后也以惨败告终，连公司都倒闭了，CEO车祸身亡，牛人们悉数遣散。附带说一下，这个Taligent项目是为了跟NextSTEP和Microsoft Cairo竞争，前者用Objective-C编写，后来发展为Cocoa，后者用传统的Win32 + COM作为基础架构，后来发展为Windows NT。而Objective-C和COM，恰恰就在动态消息分派方面，与C++迥然不同。后面还会谈到。

客观地说，“面向类的设计”并不是没有意义。来源于实践又高于实践的抽象和概念，往往能更有力地把握住现实世界的本质，比如MVC架构，就是这样的有力的抽象。但是这种抽象，应该是来源于长期最佳实践的总结和提高，而不是面对问题时主要的解决思路。过于强调这种抽象，无异于假定程序员各个都是哲学家，具有对现实世界准确而深刻的抽象能力，当然是不符合实际情况的。结果呢，刚学习面向对象没几天的程序员，对眼前鲜活的对象世界视而不见，一个个都煞有介事地去搞哲学冥想，企图越过现实世界，去抽象出其背后本质，当然败得很惨。

其实C++问世之后不久，这个问题就暴露出来了。第一个C++编译器 Cfront 1.0 是单继承，而到了 Cfront 2.0，加入了多继承。为什么？就是因为使用中人们发现逻辑上似乎完美的静态单继承关系，碰到复杂灵活的现实世界，就破绽百出——蝙蝠是鸟也是兽，水上飞机能飞也能游，它们该如何归类呢？本来这应该促使大家反思继承这个机制本身，但是那个时候全世界陷入继承狂热，于是就开始给继承打补丁，加入多继承，进而加入虚继承，。到了虚继承，明眼人一看便知，这只是一个语法补丁，是为了逃避职责而制造的一块无用的遮羞布，它已经完全已经脱离实践了——有谁在事前能够判断是否应该对基类进行虚继承呢？

到了1990年代中期，问题已经十分明显。UML中有一个对象活动图，其描述的就是运行时对象之间相互传递消息的模型。1994年Robert C. Martin在《Object-Oriented C++ Design Using Booch Method》中，曾建议面向对象设计从对象活动图入手，而不是从类图入手。而1995年出版的经典作品《Design Patterns》中，建议优先考虑组合而不是继承，这也是尽人皆知的事情。这些迹象表明，在那个时候，面向对象社区里的思想领袖们，已经意识到“面向类的设计”并不好用。只可惜他们的革命精神还不够。

7. 你可能要问，Java 和.NET也是用继承关系组织类库，并进行设计的啊，怎么那么成功呢？这里有三点应该注意。第一，C++的难不仅仅在于其静态结构体系，还有很多源于语言设计上的包袱，比如对C的兼容，比如没有垃圾收集机制，比如对效率的强调，等等。一旦把这些包袱丢掉，设计的难度确实可以大大下降。第二，Java和.NET的核心类库是在C++十几年成功和失败的经验教训基础之上，结合COM体系优点设计实现的，自然要好上一大块。事实上，在Java和.NET核心类库的设计中很多地方，体现的是基于接口的设计，和真正的基于对象的设计。有了这两个主角站台，“面向类的设计”不能喧宾夺主，也能发挥一些好的作用。第三，如后文指出，Java和.NET中分别对C++最大的问题——缺少对象级别的delegate机制做出了自己的回应，这就大大弥补了原来的问题。

尽管如此，Java还是沾染上了“面向类设计”的癌症，基础类库里就有很多架床叠屋的设计，而J2EE/Java EE当中，这种形而上学的设计也很普遍，所以也引发了好几次轻量化的运动。这方面我并不是太懂，可能需要真正的Java高手出来现身说法。我对Java的看法以前就讲过——平台和语言核心非常好，但风气不好，崇尚华丽繁复的设计，装牛逼的人太多。

至于.NET，我听陈榕介绍过，在设计.NET的时候，微软内部对于是否允许继承爆发了非常激烈的争论。很多资深高人都强烈反对继承。至于最后引入继承，很大程度上是营销需要压倒了技术理性。尽管如此，由于有COM的基础，又实现了非常彻底的delegate，所以 .NET 的设计水平还是很高的。它的主要问题不在这，在于太急于求胜，更新速度太快，基础不牢。当然，根本问题还是微软没有能够在Web和Mobile领域里占到多大的优势，也就使得.NET没有用武之地。

8. COM。COM的要义是，软件是由COM Components组成，components之间彼此通过接口相互通讯。这是否让你回想起本文开篇所提出的对象范型的两个基本原则？有趣的是，在COM的术语里，“COM Component ” 与“object ”通假，这就使COM的心思昭然若揭了。Don Box在Essential COM里开篇就说，COM是更好的C++，事实上就是告诉大家，形而上学的“面向类设计”不好使，还是回到对象吧。

用COM开发的时候，一个组件“是什么”不重要，它具有什么接口，也就是说，能够对它发什么消息，才是重要的。你可以用IUnknown::QueryInterface问组件能对哪一组消息作出反应。向组件分派消息也不一定要被绑定在方法调用上，如果实现了 IDispatch，还可以实现“自动化”调用，也就是COM术语里的 Automation，而通过列集（mashal），可以跨进程、跨网络向另一组件发送消息，通过 moniker，可以在分布式系统里定位和发现组件。如果你抱着“对象——消息”的观念去看COM的设计，就会意识到，整个COM体系就是用规范如何做对象，如何发消息的。或者更直白一点，COM就是用C/C++硬是模拟出一个Smalltalk。而且COM的概念世界里没有继承，就其纯洁性而言，比Smalltalk还Smalltalk。在对象泛型上，COM达到了一个高峰，领先于那个时代，甚至于比它的继任.NET还要纯洁。

COM的主要问题是它的学习难度和安全问题，而且，它过于追求纯洁性，完全放弃了“面向类设计” 的机制，显得有点过。

9. 好像有点扯远了，其实还是在说正事。上面说到由于C++的静态消息机制，导致了形而上学的“面向类的设计”，祸害无穷。但实际上，C++是有一个补救机会的，那就是实现对象级别的delegate机制。学过.NET的人，一听delegate这个词就知道是什么意思，但Java里没有对应机制。在C++的术语体系里，所谓对象级别delegate，就是一个对象回调机制。通过delegate，一个对象A可以把一个特定工作，比如处理用户的鼠标事件，委托给另一个对象B的一个方法来完成。A不必知道B的名字，也不用知道它的类型，甚至都不需要知道B的存在，只要求B对象具有一个签名正确的方法，就可以通过delegate把工作交给B的这个方法来执行。在C语言里，这个机制是通过函数指针实现的，所以很自然的，在C++里，我们希望通过指向成员函数的指针来解决类似问题。

然而就在这个问题上，C++让人扼腕痛惜。

作者：myan 发表于2010-10-9 0:04:00 原文链接

阅读：22528 评论：107 查看评论

[原]周鸿祎，高司令

myan — Tue, 28 Sep 2010 00:41:00 +0800

还是感到有必要将自己的一些想法快速记下来。

首先是对周鸿祎新员工演讲的看法。

就说实话这一点来说，周鸿祎比很多人强。所以我比较喜欢引用他的话，确实比较实在，不装逼。

至于一个公司招人的风格，是公司自己定的，别人也无权评价。有人说周是画大饼，忽悠员工卖命。废话，难道新员工讲话还有别的目的吗？

但我不认为周的选人思路在别的公司可以通行。原因是这样的：近十几年来，我们听到很多人有类似的说法，比如我们公司不要平庸的人，不要没想法的人，不要混日子的人，我们公司只要有野心的人，要有创业精神的人，等等等等。

结果按照这种原则来招人的公司，很多都会遇到麻烦。

其实一个有战斗力的团队，就像混凝土骨料一样，得讲究级配，大石块要有，小石子也要有，有的时候放一些鹅卵石进去也是有好处的。一个有效率的团队，各种不同特质的人都要有，关键是最后能配合到一起。没想法但是有水平、没想法但是够认真的人，团队里一定要有。没有那些平庸的执行者，那些精明的创业家们的力量和能力就无法放大和增强，稍微大一些的想法也就没法实现。我见过一些公司，格子间里全都晾着一些名校牛人，各个都特有想法，彼此之间谁都不服谁，最后也没见作出了不得的东西。

其实很多东西最后做出来了，跟最初那个想法完全不一样了。如果仔细分析一下，究竟是有想法的人贡献大，还是没想法的人贡献大，很难讲。只不过有想法的人通常会忽悠，让外界以为功劳都在他身上。

Java之父高司令被Oracle清退一事。我跟高司令面对面谈过三次，印象最深就是他的说话方式，嘟嘟囔囔，嘤嘤嗡嗡，有如唐僧念经，又如苍蝇群舞，让人昏昏欲睡而不能。这么说吧，就讲话的水平而言，高司令的反义词就是希特勒。但是那又怎么样，高司令是计算机科学家，编程大牛，世界顶尖的，别说他说话像苍蝇，就是他长得像苍蝇，他也是世界上最流行编程语言的创造者。

就这么个老兄，居然因为自己被炒的事，冲记者发出这么一大堆尖酸的牢骚来，还真是出乎我意料。但其实他老人家的抱怨，没有踩到点上。

高司令原来在Sun的时候，是个有职无权的副总裁。待遇高，但是手下其实不管人。很简单，计算机科学家管不好人，他只要做好Java，当好宗师、偶像就行了——当然，我还是想再强调一下，如果他不开口说话的话，挺偶像的，一开口说话，就呕像了。

但是Oracle的体系，搞纯技术的上不到那么高的位置，所以就变着法把老高头赶走了。

讽刺的是，Oracle并不是不重视技术的公司，虽然埃里森跟爱迪生一样都是自大狂，而且私生活跟埃里克松一样going down，但这不代表他不重视技术。Oracle的技术其实好得不得了。

换句话说，在Oracle，再好的技术人员也得不到副总裁待遇，但并不影响这公司的技术水平。

为什么？因为互联网时代到来以后，程序员提高自身技术水平变得容易多了，这导致高水平程序员的供应增加，水平提高，价格降低。

程序员圈子里流传什么“优秀程序员效率超过平庸程序员100倍”之类的说法。我猜编出这种傻话的人，动机是良好的，希望恫吓一下管理层，给程序员阶层多争取一点利益。但是其实这没有任何用处。现实情况并不是把你跟100头蠢驴放在一起让老板挑，而是把你跟另外一些水平比你差一点，薪水要求只有你一半的人来比。也许你很聪明、算法很好，精通底层，拿过这个那个竞赛名次，还做过一点什么可以炫耀的东西，但是在互联网时代，其实另一个看上去比你平庸、薪水只有你几分之一的人，一旦放到那个角色上，放到那个环境里，只要智力正常、够认真、肯下功夫，有个三四年锤炼，完全可以在性价比方面达到和超过所谓“高手”的水平。我见过不少这样的情况，初看上去平庸的程序员，经过几年实践，成长为公司技术骨干。反而是那些刚进来时罩着光环的人，很快就觉得自己好像也显不出什么优势来。有一个我熟悉的高手，不久前困惑地对我说，以前自己花了三四年修炼得到的东西，现在的新人一年就掌握了，让他感到很危机。

其实这就是编程这个领域一个特有的事情——互联网对于开发知识和经验的传播实在太有帮助了。如今解决一个问题、掌握一方面知识，最好的办法不是看书，也不是自己苦思冥想，而是google搜索。我对此体会非常深刻，很多困扰我很多年的问题，最后都是通过搜索到若干篇文章、帖子、博客得到彻底解决。老实讲我也很困惑，我不知道自己当年花在这些问题上的不计其数的小时是否还有意义。至少在编码上来说，现在的新手如果能够读到这些文章，那么当他们遇到相同的问题时，也许体会和理解没有我深，但写出来的代码不会比我差。

高司令虽然牛，但作为工程师来说，性价比不高。在Oracle看来，完全可以以低得多的代价找到水平接近的工程师，照样让Java发展得很好。所以动了杀心。就是这样。

对于程序员来说，这意味着什么呢？这意味着你不能把你的职业优势完全放在编程技术上，而是要在另一个领域也建立互联网无法冲击的优势。这真的是个大问题，每个开发人员都要好好想想。

作者：myan 发表于2010-9-28 0:41:00 原文链接

阅读：31063 评论：186 查看评论

[原]回复几个问题

myan — Tue, 14 Sep 2010 22:41:00 +0800

这几天写了两篇博客，很多老朋友关切，问了一些问题。

比如说，怎么又有时间关心技术了？是不是没那么忙了？我说，其实一样的忙，只不过兴致所致，牺牲一些休息时间罢了。说不定一个猛子扎下去，又是长时间潜水。

再比如说，怎么还在搞C++？我说，我没搞C++，一直以来都是C++在搞我们，我只不过发表一点被搞以后的感想。

有人问，你要讲的那三个C++特性，网上资料一大堆，你就免了吧。我说，如果我有时间，我会写的跟网上所有人的写法都不一样。比如说，讲 function/bind/lambda/closure，我会从 callback 讲起，回顾一下 C++中的 virtual function和成员函数指针，MFC中的message mapping，Borland C++Builder中的event handling，WTL的 CRTP 模拟虚函数，然后谈谈为什么 Java 需要加入 inner class，为什么C#把 delegate 作为first class citizen，以及 Qt 是如何用 meta-object 系统打造出迄今为止C++最漂亮的GUI框架，以及所有以上一切，在简单的 C 前是多么的多余和废柴。比如说，如果讲 rvalue reference，我会从孤魂野鬼似的匿名临时对象讲起，从 const T&，讲到 RVO/NRVO，说不定还会触及 expression template。

但是，我知道我没那么多时间来把这些东西都写下来，写下来也用处不大。这些东西已经不是今天技术的主流。“why”现在越来越不重要，“how”压倒一切。

“既然如此，你怎么还在鼓吹C++的那些奇技淫巧？你没看到C++已经越来越边缘了吗？”

这个，得容我自辨几句。

首先，我现在只有在业余时间看看技术，所以当然选自己最熟悉的领域。

其次，我不认为C++就没有用武之地了。C++会长期存在下去，而且在一些特殊的领域里仍然充当主角。比如，我们不应该小看 Qt 在移动开发中的发展空间，而在一系列我称之为“对抗性应用”的领域，C++还将占据优势，直到出现真正的替代者——肯定不是D，比较有希望的是Go。只是希望Rob Pike老人家坚持到底，不要跟当年plan 9一样，easy come easy go.

第三，最重要的，我鼓吹的不是奇技淫巧。相反，我可能比那些没学过C++或者被C++难倒的人都更讨厌C++中那些奇技淫巧，因为它曾浪费了我大量的时间、精力和热情。

为了讲清楚这个问题，我得谈谈C++的风格，这个老掉牙的话题。

上周末跟老朋友聚会，谈到技术的时候，有一个共识，软件开发方面真正有价值的进步，应当是有利于用户、有利于项目管理、有利于解决领域问题，而不是有利于程序员。多年以来，主流语言和系统的很多改进，其目的都是为了让写程序的人感觉更爽，而与用户、管理和解决问题毫无关系。C++在这方面是带了一个很坏的头，又要追求强大的表达能力，又要追求不打折扣的效率，结果搞出一大堆诸如操作符重载，template meta-programming之类的东西。老实讲，我也觉得：

Matrix4f a, b, c; c = a * (b – a);

要比：

Matrix4f a, b, c; c = a.mul(b.sub(a));

更清爽，但是就算是第二种形式，又能怎么样呢？无非多敲几个字而已，能有多大不了的事？哪个合格的程序员敢说无法理解？可为了让程序员的视觉更清爽一点，C++花了n年时间，弄出来一大堆奇技淫巧，再与之前之后诸多特性相互干扰，复杂度成倍增加，

有人可能会跳出来反驳说，如果表达能力不重要，那么你干脆回去写汇编好了。

所以我得把话说全了。程序的表达能力，只有在反映了其抽象能力的提高时，才是重要的，否则就是自娱自乐。

抽象是程序开发的全部意义所在。之所以C比汇编是一个伟大的进步，是因为C建立了一个机器抽象，把诸如寄存器、cache、寻址方式、位对齐之类的细节都透明掉了，由此而带来的表达能力提升，当然是伟大的。但是你看看上面我举的那个例子，有抽象层次的提升吗？没有！有的只是YY暗爽值的提升。这种表达能力提升，如果得来全不费工夫，当然也无伤大雅，如果是呕心沥血，伤人一万，自损三千，窃以为大可不必也。

软件搞了60年，我认为真正被实践证明了的抽象，一共有四个半，分别是：

1. 机器抽象，或者称语言抽象，构造一台新的计算机或程序语言，使其能理解领域特定的语言，从而最妥帖地解决问题。这是最有力的抽象，是软件开发中的“火箭科技”。

2. 过程抽象，把一件事情看成是一系列嵌套和串接执行的标准化过程的总和，就像流水线一样。这是极为有力的抽象，因此C语言无所不能。但是层次偏低，规模增大以后带来一些挑战。

3. 函数抽象，最玄妙的一种，这个我不多说，有兴趣的去看 Structure and Interpretation of Computer Programs.

4. 面向对象抽象，把一件事情看成是一组各负其责的对象彼此之间相互收发消息，根据消息相互协作完成工作的过程。这个抽象也极为有力。

4.5 僵化的面向对象抽象，把世界看成是由层次分明、庞杂万端的类型体系“实例化”而出的对象组成的，把事情看成是这些对象之间互相收发消息、协作而成的过程。

问题出在这最后一个抽象上。由于面向对象早期的主要应用场合是 GUI 和仿真，是特别适合于建立类型体系的应用领域，结果人们误以为这种抽象模型可以应用于所有领域。成长于这个时期的C++受了这种思想的毒害，建立了一个极其严苛、吹毛求疵的类型系统，自以为这样可以在编译时发现更多错误，没想到其结果是在编码时和运行时引起更多麻烦。动态面向对象语言的实践已经证明，所谓没有严格的类型检查就无法有效地发现错误这一说法，在今天这个时代已经不符合实际了。

事实上，后来的实践表明，拿静态的类型系统去套多姿多彩、变化万千的现实世界，纯粹是人类的狂妄自大。除了在少数几个完全是人造出来的领域（典型的就是GUI，什么窗口、控件、菜单…，完全是人自造的）还是可以的，在很多其他领域则是无力的。所以只能算半个抽象。

C++就是被这个半吊子抽象所害，以至今天，积重难返。至于用template泛型去放松类型的约束，实属亡羊补牢。template可谓毁誉参半，其中的精妙之处固然令人激赏，其中诡异无聊之处也令人愤懑。现在boost和其他一些C++库之中，把template舞得虎虎生风，我也不知道抽象到几天云外去了，但是仔细看来，往往是自取其乐，跟实际效果并无干系，反而有碍管理与交流。

无论如何，C++已经走到了今天。作为一个提供了较强抽象能力，同时性能又不打折扣的语言，还是不失其地位。

以上是个人观点，仅供参考。

作者：myan 发表于2010-9-14 22:41:00 原文链接

阅读：9807 评论：38 查看评论

[原]C++0X的三件好东西（零）

myan — Sat, 11 Sep 2010 11:01:00 +0800

先说一些废话，可以跳过不看。

我主张，在具备基础之后，学习任何新东西，都要抓住主线，突出重点。对于关键理论的学习，要集中精力，速战速决。而旁枝末节和非本质性的知识内容，完全可以留给实践去零敲碎打。

原因是这样的，任何一个高级的知识内容，其中都只有一小部分是有思想创新、有重大影响的，而其它很多东西都是琐碎的、非本质的。因此，集中学习时必须把握住真正重要那部分，把其它东西留给实践。对于重点知识，只有集中学习其理论，才能确保体系性、连贯性、正确性，而对于那些旁枝末节，只有边干边学能够让你了解它们的真实价值是大是小，才能让你留下更生动的印象。如果你把精力用错了地方，比如用集中大块的时间来学习那些本来只需要查查手册就可以明白的小技巧，而对于真正重要的、思想性东西放在平时零敲碎打，那么肯定是事倍功半，甚至适得其反。

因此我对于市面上绝大部分开发类图书都不满——它们基本上都是面向知识体系本身的，而不是面向读者的。总是把相关的所有知识细节都放在一堆，然后一堆一堆攒起来变成一本书。反映在内容上，就是毫无重点地平铺直叙，不分轻重地陈述细节，往往在第三章以前就用无聊的细节谋杀了读者的热情。为什么当年侯捷先生的《深入浅出MFC》和 Scott Meyers 的 Effective C++ 能够成为经典？就在于这两本书抓住了各自领域中的主干，提纲挈领，纲举目张，一下子打通读者的任督二脉。可惜这样的书太少，就算是已故 Richard Stevens 和当今 Jeffrey Richter 的书，也只是在体系性和深入性上高人一头，并不是面向读者的书。

最近我闲逛各技术社区，最深的一个感受，就是开发者的niubility value也跟中国社会的 income distribution 一样，呈现严重的两极分化状态。所以我建议那些老鸟们，多做一点提纲挈领的总结工作，把真正紧要的东西总结出来，给社区一些贡献。

我现在只在业余时间看看技术，写写程序，聊以自娱，对于最近一年多的风起云涌，了解有限。下面所说，如果有错误，请指出。

言归正传。

C++0X出来之后，网上对它的讨论已经很丰富，大大小小几十个新的特性，如果详细论述，当然又是一本（平庸的）厚书。但在我看来，其中很多特性是不用花太大精力的。分这么几类：

1. 亡羊补牢的，早就应该有，没有就该遭雷劈的。比如unordered_table, shared_ptr/weak_ptr, regexp, auto/decltype。

2. 锦上添花，可有可无的。比如 tuple, array container, range-base for, initializer lists, delegate/inheriting constructors, nullptr等等。

3. 犄角旮旯，库开发专用工具，一般不推荐使用的：如static_assert、可变模板参数等。

4. 还不成熟的，没有完全想清楚的：主要是 thread，其中的 future, promise等抽象，勇气可嘉，但有早产嫌疑，仍需留院观察。

那么C++0X中真正的主角，值得你投入精力去学习的，有可能对你的编程实践构成重大影响的，我认为就三个东西：

1. Rvalue reference;

2. function/bind;

3. Lambda expression and closure.

这三个东西，网上的讨论也已经有很多了。我也来凑凑热闹，会陆续写三篇简明扼要的东西，介绍它们的厉害。

作者：myan 发表于2010-9-11 11:01:00 原文链接

阅读：27018 评论：87 查看评论

[原]几点想法，权作网志

myan — Sat, 04 Sep 2010 11:52:00 +0800

随便说一些事情，微博体。

1. 看到CSDN在讨论程序员是不是已经死了。对于这个问题本身，我没有啥想法，因为本质上只不过是把一个一直在讨论的问题用尼采体重新表达了一下。其实这个话题既不是职业规划问题，也不是技术方向选择问题，就是个心态问题。按照立论者的标准，只有在职业中达成了自我实现的人才算是活着，那么人生不如意者十之八九，这个世界上绝大多数人都是死人。只不过人家死了都不叫一声，你程序员要死没死的还老是哼哼，这说明什么？说明程序员这个职业还是不错的，至少让你心存一丝妄念。有感觉才知道疼，这个世界上许许多多的人已经没有感觉了。

2. 这样的讨论，十年以来结论都没有变过，无非是说说程序员要走出圈子，扩大视野，仔细规划自己的人生路线。我以前也是这么认为的，现在大不以为然。人生路线是规划得了的吗？成功是计划出来的吗？几年前在CSDN英雄会上，周鸿祎就说得很透彻了，所谓人生规划，绝大多数是倒叙出来的。

3. 再说跳出程序员圈子——这是个好主意。程序员应该跳出圈子，多看看外面的世界。倒不是说这样你就能变得多高瞻远瞩，就能YY出一个NB的人生，而是给你一个机会，让你明白，其实大家都活得不容易。所以如果你真的适合做程序，就别那么多废话，别那么多唧唧歪歪顾影自怜，写好你的程序吧。

4. 每过几年，程序员圈子就会竖起一个新的偶像派职业。十年前是项目经理，五年是架构师，现在是产品经理。其背后的实质是一样的，就是那样一个职业——拿着马克笔在白板上点点画画，喷几口唾沫星子，把SB老板侃得一愣一愣的，昏厥之前来个白帝城托孤，任由你小手一挥，指挥身后一堆小厮掩杀过去，尸横遍野之后，你老再过去剪彩领奖。

5. 六七年前，项目经理普及了，程序员们一看，这家伙不好干，有责没权，上下受气，担惊受怕，吃不好饭，睡不着觉，喝凉水也塞牙。于是“项目经理”这块牌子臭了；三四年前，架构师普及了，程序员们一看，这家伙不好干，满世界飞，到处救场，到处被challenge，说话没人听，出了乱子全都是“架构问题”，还要提防着每隔几年一次的“颠覆性架构变革”，一不小心就人老珠黄。于是“架构师”这块牌子又臭了。现在流行“产品经理”，这块牌子什么时候臭掉？Let’s count down…

6. 其实不怪程序员们。不得不说，2010时代的中国知识工作者（几年前微软引入的词儿），总体上是个杯具。但是这个杯具，是一连串的国家大事小事造成的，短期内没解。而至于你个人的杯具，存在改变的机会，但很大程度上要靠你的坚持和运气，而不是靠你的职业规划。

7. 金融危机以后，世界已经进入了变幻莫测的时代。某些人不信，以为印些钞票就确定了，或者买些房子就确定了，实际上只是报应没来而已。如果你听说伯南克要采取“非常规的货币政策”，还没吓得魂飞魄散，那要么你的存在本身是个悲剧，要么你就是可以靠演讲赚钱的tmd经济学家。

8. 在未来的日子里，确定性比黄金更珍贵。写代码跟种粮种菜修鞋理发一样，是这个世界上为数不多的几个有确定性的事情。

9. 所以程序员还算不错的。

10. 最后再老生常谈一下，程序员最好懂行业，懂了行业就不一样了。

作者：myan 发表于2010-9-4 11:52:00 原文链接

阅读：14506 评论：91 查看评论

[原]对于近期博客状况的说明

myan — Sun, 03 May 2009 11:33:00 +0800

最近常有朋友问我，为什么四个多月不更新博客。现简单说明一下。

我已经于今年2月离开了工作近6年的CSDN，加入了另一家公司，因此必须遵守该公司对于员工发表博客的指导原则。由于目前我还没有确切地了解到这些指导原则，在无法掌握言论尺度的情况下，只能暂时缄默。一旦我详细地了解了有关原则之后，会及时恢复在CSDN博客上的正常活动。

感谢各位的关心和支持。

作者：myan 发表于2009-5-3 11:33:00 原文链接

阅读：12325 评论：40 查看评论

[原]推开云端计算的视窗——微软互联系统部门全球副总裁Robert Wahbe揭秘Azure服务平台

myan — Mon, 22 Dec 2008 11:18:00 +0800

Windows Azure及Azure 服务平台可能是微软近年来最重要的战略性产品，对于云计算的发展也具有重要的意义。此文发表于《程序员》杂志2008年第12期，对于帮助大家了解Windows Azure及Azure服务平台有一定帮助。由于是涉及厂商产品的合作文章，言辞多有修饰痕迹，请大家专注技术本身，同时保持批判态度。

10月27日，微软首席软件架构师Ray Ozzie在PDC大会上发布了Windows Azure和Azure服务平台的技术预览版。整个研发过程相当保密，并且得到微软最高决策层的高度重视，将原本分布在很多其他团队的技术精英集中投入该项目研发。在业内有观点认为，这是微软自2002年发布.NET以来最重要的技术进步，同时也是整个软件技术发展史上的最具标志性的里程碑事件之一。这究竟是实事求是的评价，还是言过其实的吹捧，或者仅仅是一种公关辞令？11月14日，微软互联系统部门全球副总裁Robert Wahbe来到微软中国研发集团在上海的服务器与开发工具事业部,看望他在中国的研发团队，我本人也代表CSDN和《程序员》杂志借此机会就Azure服务平台的有关情况与Robert Wahbe进行了充分的对话。互联系统部门是微软最具战略意义的部门之一，统管微软涉及网络和设备互连以及新计算模型的平台与技术研发，著名的BizTalk、WCF、WF等技术和产品都出自该部门， Azure服务平台中.NET Services则是这个部门的最新成果。事实上，我们这次采访的中国研发团队就在其总经理陈耀文先生的带领下直接参与了.NET Services的开发。可以说，在中国恐怕没有比他们更了解Azure服务平台的团队，也没有比Robert Wahbe更适合讲述Azure服务平台的人。尽管这一重大产品及其所代表的软件技术新时代才刚刚拉开序幕，现在就要对其进行完整和客观的论述还为时尚早，但是通过与该团队和Robert Wahbe本人的深入交流，我相信Azure服务平台确实值得整个软件产业高度关注，它所代表的技术浪潮具有重塑整个产业面貌的巨大力量。

1. 云计算模型和微软的云计算战略

“Azure”是一个法文词，其意义是“天空的蓝色”。微软采用这一命名的用意不难猜测，就是希望Azure这片蓝天能够成为“云”计算的依托和背景。尽管这个名字起的够浪漫，但是Azure能否真的不负众望，则还需要有赖于诸多因素。首要的因素就是微软对于云计算的战略规划是否清晰。因此，我们首先谈到了微软的“云端计算”概念和“软件+服务”战略。

问： Azure服务平台的推出与微软去年提出的“软件+服务”战略之间是什么关系？

答：我们早就注意到近年来软件领域出现的一个重大趋势，那就是将软件作为服务来交付，也就是所谓的SaaS。但是我们同时也发现，用户喜欢SaaS，但也希望能够在各种设备上以很好的交互体验访问服务。我这里有一个例子：建筑甲方经常在会议上要求建筑师修改设计方案，而方案修改之后，重新渲染三维建筑场景是一项计算密集型任务，通常单台PC或笔记本电脑无法快速反映修改后的效果。而一个CAD厂商开发了一个CADSpace服务，允许前端CAD软件将渲染任务传给云计算，后者由数千台机器组成，可迅速完成渲染任务并且将结果返回给前端的CAD软件，这样甲方当场就可以看到方案修改后的效果。这就是“云”+“端”各展所长达成的良好效果。

因此微软认为，未来的软件应用是服务与软件的优化组合。支持这种模式的基础设施，将由前端数以亿计的PC和移动设备与后端的服务器共同构成。Azure服务平台是微软新推出的云计算平台，也是后端服务的支撑平台之一。因此，可以说Azure服务平台是“软件+服务”战略的重要支点。

问：那么是否可以说微软打算把“软件+服务”中的“服务”交给以Azure服务平台构造的云计算来完成？

答：这是一种过分简单化的看法。首先，微软确实认为，云作为一个服务器、PC和移动设备之外新出现的计算“层（tier）”，具有重大的意义，是提供服务的重要的一层，但并不是唯一的一层。传统意义上的现场部署服务器设施（on-premises）在提供服务方面仍然具有重要的意义。微软认为，用户有权利也有理由同时采用现场服务器和云计算(in-the-cloud)来构造自己所需的服务和应用。

问：既然如此，云计算对于用户来说有什么优势可言呢？

答：首先，云计算使大量用户能够共享基础设施，从而提升资源的应用效率。我们做过调查，大部分企业中计算机的使用率是10%左右，这是严重的资源浪费。在云计算模式下，每个用户根据需求获取计算、存储、带宽等资源，资源的整体使用效率大大提升。其次，云计算环境将各种计算资源虚拟化，从而能够动态调度。例如，当你的业务刚刚起步的时候，你可能只需要几台机器，而当你的业务迅速发展时，如果采用现场服务器模式，你就需要添置硬件设备，做大量工作提升计算能力，这很麻烦。而使用Windows Azure操作系统，你需要做的只是修改配置文件，甚至连修改都不需要，Windows Azure会自动为你调配充足资源，保证你的应用顺利执行。这种动态性，以及由此带来的可延展性，是传统模式无法比拟的。第三，云计算模式可以使你以更低的成本获得更高的性能和可靠性。一般来说，企业应用对于性能和可靠性的要求很高，但获取它们的代价不菲——不但意味着更多的硬件设施，更要建立和维持一支高水平的运维团队，一旦遇到问题，解决起来难度和开销都很大。而云计算模型使得普通的用户可以比较容易地获得高性能、高度可靠性的应用系统。最后，也是最重要的，云计算平台支持一种新的软件付费模式——按需支付（pay as you go）。在这种模式下，你用多少服务，就付多少钱，开销被优化到最佳状态。而在提供方，将形成云计算托管服务商+应用提供商的模型，同样实现更好的分工，软件租用的新的商用模型将建立和发展起来。

2. 独一无二的Azure服务平台

问：提到云计算，目前Amazon已经在这个领域已经颇有建树，其EC2、S3等一系列服务已经开始产生收入。另外，Google的AppEngine也已经发布，那么微软的Azure服务平台与它们相比有什么不同？

答：我可以说Azure服务平台是独一无二的。首先，微软采纳云计算趋势的策略是独一无二的，我们不是一下子要求用户跳跃到云计算模式上来，而是允许用户自主决定在现场服务器和云计算之间取得折中。让我说得具体一点，假设你是一个创业公司，你需要部署你的产品，你没有钱买强大的服务器设备，昂贵的存储和带宽，那你可以完全将你的应用部署到基于Windows Azure的云计算中，只付出低廉的租金。而当你的业务成长起来，有足够的资金负担计算设备，那么你可以选择将一部分服务放在云计算中，另一部分服务放在现场服务器中，具体怎样配置，完全可以由用户决定自由组合。Windows体系中，现场服务器架构和云计算并不矛盾，而是互相补充，这是Azure服务平台最独特的策略。其次， Azure服务平台在产品与技术的宽度和广度上都是独一无二的：

你可以看到，Windows Azure是一个在云端的操作系统，包括计算、存储、管理等，，在这一层之上，还有非常丰富的功能和服务。Live Services是以用户为中心的，提供诸如联系人信息、博客、图片等服务；.NET Services提供应用开发所需要的通用服务，比如服务总线、访问控制和工作流服务等，用户可以不必一遍又一遍开发重复的功能和基础设施；SQL Services提供了数据管理的服务；SharePoint Services提供协作服务，而CRM Services则提供类似Salesforce的应用级的服务。你可以看到，这个平台所提供的服务是非常丰富的，而你的应用可以基于这些丰富的服务而建立，可以想象，无论在开发效率、成本、可靠性和可扩展性各方面， Azure服务平台都将为开发人员带来非常大的优势。

问：Windows Azure是一个.NET环境，是吗？我必须用.NET才能在其上开发部署应用，是不是这样？

答：不是的，Windows Azure将同时支持.NET应用和原生（native）程序，你可以用C、C++、Python、Ruby、PHP写程序，然后运行在Windows Azure上。当然，.NET在Azure这个平台上更是如鱼得水。对多种开发平台提供支持，目前Azure服务平台也是独一无二的。

问：我自己想用Windows Azure搭建一个云计算，可以吗？还是说世界上只有一个Windows Azure云计算，我们都只能用它提供的服务？

答：这又是Windows Azure的一个独特之处。微软将会建立自己的基于Windows Azure宿主环境，并对外提供云计算服务，这是无疑的。但是，微软也会允许第三方使用Windows Azure搭建他们自己的云计算服务平台，并且为他们提供支持。

问：很多人会问，把我们的商业秘密信息放到云里，我的隐私如何保护？信息安全性和访问控制如何解决？

答：这种担心很大程度上可能是一种误解。我一直认为，当前云计算的一个示范性应用就是电子邮件，诸如Hotmail、Gmail、Yahoo电子邮件等巨型的电子邮件服务商一刻不间断地向数亿用户提供电子邮件服务，用户则可以用各种方式使用这些服务。如今大家每天使用这一云计算服务，而大量隐私信息也在其中流转，并没有人觉得这是很大的问题。我相信，假以时日，人们会发现云计算模式能够对他们的隐私提供充分的保障。当然，从云计算平台提供者的角度来看，这个问题是必须认真对待的。Azure服务平台在这方面做了充分的研究，提供了可信赖的解决方案。Azure对于安全认证、访问控制等问题的解决方案，是建立在此前Windows平台多年研究成果的基础之上，在实践中已经充分证明了其先进性和可信性。比如完全由在这里的中国团队开发的Access Control(访问控制)功能，可以与现有商用电子身份认证服务，如Windows Live ID或Active Directory通过WS-Federation协议联盟起来，并通过规则的方式进行权限管理。我们相信在这些方面， Azure服务平台是目前的领先者。再退一步说，即使是高度机密的数据，不能放入云里，与Azure也并不矛盾——别忘了， Azure服务平台支持现场服务器与云计算的自由配置，你可以将这些数据放在完全自主控制的环境里，这没有问题。

3. 走入云计算时代的开发者

问：开发云计算软件与传统服务器软件有什么不同？我们的编程思想是否要发生根本变化？

答：不需要。你之前为Windows Server写的应用程序，只需要在配置文件里修改一行代码，就可以被部署到Windows Azure上，就是这么简单。这也算得上是Windows Azure的一个重大优势——你的应用程序可以自由地在传统服务器和Windows Azure环境之间迁徙。你知道，这对于软件的开发、测试、部署都带来巨大的好处。从另外一个方面来说，编写高性能服务器软件，需要掌握一些新的模式和方法，比如MapReduce，从而获得更好的可扩展性。但这只是一种软件编写模式，在现场服务器中也需要用到。因此，开发Windows Azure应用并不需要你大幅度的更新知识。更何况，开发Windows Azure应用的整个工具环境都是大家熟悉的Visual Studio，还是基于.NET Framework，服务开发模型还是基于WCF，我们相信开发者迁徙到Windows Azure上将相当轻松。

问：这些年微软的技术进步速度太快，很多开发者抱怨说他们不得不气喘吁吁地跟上微软。现在Azure服务平台又出来了，作为开发者，到底应当怎样在这场追逐中保持良好的心态？

答：微软是一家不断创新的公司，现在是一个需要快速创新和变革时代，这或许能解释为什么我们这几年的步伐如此之快。但是对于开发者来说，微软相当重视保证他们知识的可延续性和稳定性，你仍然使用的Visual Studio，.NET Framework虽然在不断进化，但是其基本内容保持不变，知识更新成本并不高。我相信你必须专注于你的具体工作，这样你会享受技术进步的乐趣，而不是感到疲惫不堪。微软会尽力帮助开发者做必要的提升，但是我们不会因为有这些抱怨而停止我们创新的脚步。

尾记： Azure服务平台的内容非常丰富，Wahbe先生的介绍也相当详实，然而受篇幅限制，我只能择其大略，希望能令开发者对崭新的云计算平台的全貌和特色有初步的认识。我个人是云计算的忠实信徒，我相信云计算将成为未来的主流计算模型，并彻底改变IT的面貌。因此， Azure的重要性应当与PC时代的DOS和Windows，C/S时代的Windows NT相提并论。随着云计算时代的到来，软件开发模式和商业模型都将进入全面开放组合的新时代，我相信面对这一未来，一部分人会兴奋不已，而另一部分人则可能垂头丧气。但是，诚如Wahbe先生所言，单纯地为技术的进步而雀跃或者忧心忡忡都是没有必要的，作为开发者，关注自己的业务，把自己的工作做好，那么你会发现， Azure服务平台所代表的云计算时代一定是值得期待的。

作者：myan 发表于2008-12-22 11:18:00 原文链接

阅读：10333 评论：13 查看评论

[原]SD2008会后反思云计算

myan — Tue, 09 Dec 2008 13:27:00 +0800

今年SD大会最重要的官方话题毫无疑问是云计算。作为主办方，我们正是看到了这一趋势的颠覆性力量，才迫不及待地将它作为今年的主角，尽量地予以强调和渲染。事实证明，这有揠苗助长的嫌疑。不少参会的朋友反映大会的主题未能很好的扣合当前的具体问题，显得有些超前。这是我们应该检讨的。去年的SD把握住了“高负载Web站点设计”这样一个当期热点，给参会者留下了深刻印象。今年在这方面我们确实有失误，应当向感到失望的朋友们检讨。明年的SD，在策划时将会更多咨询业内朋友的意见，力争把握好当时的热点，做到务实，确实能给大家带来收益。

尽管如此，我仍然认为，云计算确实是值得每一个人充分注意的最重要的技术发展趋势。这次SD大会，我有机会与Jeff Barr以及其他的朋友进一步交换了对云计算的看法，其中一些有启发性的收获，愿在这里与大家共享。

第一，为什么云计算是真正的“重大技术趋势”？

IT产业每年都能制造出一打“重大趋势”，其中大部分只不过是镜花水月，过后甚至都没有人想得起来，只有一小部分会持续引起关注，成为技术圈子里的常用术语。而真正能够引起产业面貌发生重大变化的，几年才会出一个。对于IT人来说，对于这种具有重大影响力的IT技术变革，务必要保持谦虚谨慎戒骄戒躁的关注态度，否则，一个不留神你和你的组织就可能落后。然而对于那些明明是忽悠大众的概念，你也务必要具有免疫力，错投猪胎后果也是很严重的。

问题在于，怎样判断一个技术趋势是真的很靠谱，还是仅仅属于忽悠型？我在媒体内，对于一项技术背后的市场宣传推广动因比较清楚，对于媒体在其中的作用也有自己的看法。坦率地说，对于普通技术人员来讲，想要通过媒体雾里看花水中望月分辩哪句是真哪句是假哪一句是情思凝结，难度还是蛮大的。根本上，对于技术趋势的判断还是要倚靠自己的慧眼和心思。我认为有以下几个方面可供参考：

1. 其所带来的好处对于最终用户来说是否一目了然，不言自明？这里所说的最终用户，是指非技术的利益相关人士。假如一项技术的好处对于最终用户来说一目了然，那么它很可能是靠谱的。反之，如果你需要磨破嘴皮，用尽威逼恫吓的手法才能让人家勉强而又不无迷惑地点头，或者只有那些“高级架构师”才与你心有戚戚，那么它很可能是扯淡的。例如，互联的好处每个人都显而易见，搜索的方便性一目了然，B/S模型具备零部署成本的优点大家用脚趾头也能想明白，这些技术大行其道也就不奇怪了。云计算也是这样的，任何一个有点经营头脑的人只要想到，自己不用一开始就为了一个还不知道是死是活的项目花钱买机器域名带宽，不用天天半夜担惊受怕机器崩溃，不用整天老想着什么Load Balancer、CDN、Cache之类与business无关的东西，不用每过一段时间就到处打电话问有没有正处于失业状态的网站架构高手这样弱智的问题，就会毫不犹豫地给云计算模型投上一票。

2. 是否配合计算拓扑模型的变革？是否导致一些新的硬件设施的诞生和发展？作为搞软件的人，我们不愿意承认也得承认一个事实，那就是从大的尺度上来说，硬件和基本计算模型的变革才是推动IT改朝换代的根本力量，软件的进化只是在一朝一代内部的焚香净手、请客绣花、温良恭俭让式的改良主义，只有硬件（包括网络）的变革才是暴烈的、令任何个人和企业不得不屈从的天翻地覆的革命。因此，一项技术趋势，如果不配合计算模型和硬件的变革，它的影响力就是有限的，反过来，你就绝对不能忽略之。PC的革命，互联网的革命，大家耳熟能详。如今人们讨论最多的移动计算，已经显露曙光的机器人，都是如此。云计算实际上也是这样，这一模型将逐渐实现互联网上计算资源的集中化，建立超级庞大的计算中心（天网？Matrix？），毫无疑问是顺应革命形势的，具有革命的暴烈性。虽然在改革三十周年的时候，“革命”不是一个受欢迎的词汇，但是在技术领域里，革命时期是重新分配利益格局，从而也是快速发家致富的最佳时机，没有人能够抵御其诱惑。

3. 是否具有足够低的相对介入门槛和介入风险？是否能充分动员草根力量？普通人畏惧风险，讨厌门槛，介入的门槛和风险越低，参与者越积极，人数越多，势头越猛。云计算平台的开发门槛是非常高的，但是由于竞争的存在，其介入门槛将会非常之低，越来越低，趋近于零，从而也充分降低草根阶层的进入风险。我相信，迟早我们可以免费注册云计算服务，根据收益与平台商分成，从而从一开始就保持零投入、正产出。就IT而言，这样的模型可以说让风险低得不能再低了。一旦云计算大行其道，你会发现几乎每个程序员、甚至每个会操作计算机的人都会在云上发布他们自己的服务，建设自己的站点，这种如潮水般的群众力量将会冲垮一切试图阻遏它的东西。

4. 是否具有清晰可行的盈利模型？这一模型是否导致利益链条的重分配？是否具有“先到先得”、“赢家通吃”的特点？凡满足以上几个条件的技术趋势，将制造一种“顺我者昌，逆我者亡”的局面，从而逼迫玩家争先恐后地进入。云计算的盈利模型很清楚，用户以信用卡支付，按使用付费，收入在平台提供商和服务提供商之间分成，广告客户为起到推广效果，可以替用户支付费用。保险公司为云计算平台的稳定性提供担保，保费可间接用以支持平台服务商不断改善服务质量。这一盈利模式兼容之前的“使用者付费”和现在互联网上的广告盈利模式，在金融领域具有良好的支撑模式，具有清晰性和可行性，并且导致利益的重分配。不但如此，云计算是一个天然集中垄断的概念，少数几家云计算平台提供商通吃市场的局面是必然形成的。因此，所有各方在局势初步明朗的情况下，会从各自不同角度争先恐后地投入其中。

以上几点并不全面，但是已经可以充分说明问题。我的观点非常鲜明，云计算是真正重大的技术趋势，将会深刻影响IT产业的面貌，以及我们每个人的生活和思考方式。

(待续)

作者：myan 发表于2008-12-9 13:27:00 原文链接

阅读：11225 评论：16 查看评论

孟岩