梦想风暴

从小喜欢相声，因为它能给我带来无限欢乐。我所熟知的相声演员中，能在我心目中算得上大师的有三人：马三立、侯宝林和马季。侯宝林先生早早远行，马老先生告别舞台后不久便仙逝，今天，我心目中最后一位相声大师离开了人世。

得知马季先生去世，我的第一感觉是震惊，瞬间脑子一片空白。之后是不信，因为十一在家看电视的时候，马季先生还笑容可掬的出现在大家面前，短短几个月，人就这么没了。当这个消息得到证实之后，心中充满了无限的忧伤。确实，这个消息太突然。

年纪的关系，给我留下印象最深的马季先生的段子是，《吹牛》、《五官争功》和《宇宙牌香烟》。还记得小时候，总是捧着收音机，反反复复的听这些名段，虽然有时候几乎是听了上句能立刻想到下句，却依然乐此不疲。“吹牛的人不要脸了”，各个器官都请求上调的脑袋，没有一个系列印完的系列产品。我喜欢相声，听相声的时候，可以让人忘却烦恼。大概也是因为如此，我从小养成了乐观的性格，再大的困难也不会压垮我，笑一笑，一切就会过去。还记得上小学的时候，班级里开晚会，我们几个同学组对说相声，虽然表演稚嫩，但同学们依然可以乐得前仰后合，有时候，我们就会说这些几乎能背下来的名段。

最近一些年，相声不景气，让我失去了很多开怀的机会。很多电视上的相声，虽然我知道明知道这个地方它是为了让人乐，可就是乐不出来。这一现象一直持续到今年，来北京之后，无意之间，我开始听郭德纲和德云社的相声，我又开始重新找到了听相声的感觉。周围的几个朋友受我影响，也开始听，此后，我们之间的交谈又多了这些段子中的内容。现在我们最大的心愿是听一回德云社的现场。

当我重新找到相声的乐趣，一位相声的大师却离开了我们。今后，我们只能在音像资料中，回忆这位“小眼睛、胖乎乎”的十大笑星之首，回忆这位站在台上就让人想笑的大师了。

马季先生，一路走好！

这是一本闻名已久的书，起初是漫天遍野的吹捧，接着是今年的Jolt入围名单。受到吹捧的书很多，但这样一本社科类书如何能够入围技术评选的Jolt名单，倒是让我对这本书有了一些兴趣。迟迟没有见到书店中出现这本书，于是，兴趣也逐渐淡了。有个出版社把作者之前的一部作品冠以同样的名字，显然是希望搭个顺风车。

初遇这本书，尘封的记忆被唤醒，兴趣驱动，翻看了几页。让我买下这本书的动力，并不是作者高屋建瓴般的趋势探讨，而是第二章《碾平世界的十大动力》，其中大量的篇幅探讨了IT相关的内容，比如互联网、比如工作流，比如开源，比如外包，比如Google。在作者的眼中，IT技术的发展极大推动了世界变平的趋势。我对作者如何在这本书的背景下讨论这些内容颇感兴趣，于是，这本书加入了我的藏书之列。在我看来，因为IT的内容占据了大量的篇幅，这本书才会悄然登上Jolt的入围名单。

如果仅仅是提出一个趋势，这本书不会爬上畅销书的排行榜。作者开篇便立论，世界正在逐渐变平。接下来，他用了大量的事实来探讨世界如何变平，随后，他分别讨论先行者、后进者以及公司如何应对世界变平的趋势，接着，他分析了这一趋势对社会发展造成的影响。作为一本畅销书，这本书读起来比较轻松，作者做了大量的调研，使得自己写起来底气比较足。

身为一个美国公民，作者把在这个过程中遇到的问题进行比较透彻的分析，但如译者在译后记所说，对于发展中国家的讨论显得过于乐观，从篇幅上可见一斑，美国占了五章，而发展中国家仅有一章。毕竟，他所了解的只是一些表面和从别人口中听到的东西，这些内容是不足以让他做出足够深刻的剖析。身处变化中的国家，我们可以看到不足，但我们也确实看到了进步。

阿拉伯世界在书中也抢占了不少的篇幅，不过，正面的形象比较少。没办法，分析事物需要两个方面，反面总要有人，加之美国人对恐怖分子的不良印象，阿拉伯世界自然成了一个反面典型。作者的剖析深入到宗教的思想根源，至于事实是否如此，我不知道。

一个变平的世界给所有牵扯其中的人带来的是并存的压力和机遇，IT领域的人站在这个变化的前沿，我们可以用行动做出自己的选择。

OpenJDK
https://openjdk.dev.java.net/

Mobile and Embedded Community
http://community.java.net/mobileandembedded/

Open Source Java
http://www.sun.com/software/opensource/java/

Sun Opens Java
http://www.sun.com/2006-1113/feature/index.jsp

Java Story
http://www.sun.com/2006-1113/feature/story.jsp

James Gosling's Letter to the Java Community
http://www.sun.com/software/opensource/java/gosling_letter.jsp

CSDN报道
http://blog.csdn.net/programmer_editor/archive/2006/11/14/1383027.aspx

喊了好长时间的口号，Java终于开源了。这次主要是SE和ME，加上之前的EE，算是凑足了一条完整的线。

和很多朋友一样，我有一个疑问。JDK的源码很早就可以得到了，开源的差别在哪呢？想来想去，根源可能在于我们对于开源的理解。我们一直认为有源码就叫开源，其实，开源的意义并不只是在代码开放，还有一个参与反馈的过程。原来的Java，我们可以从中学习，但并不能把自己的想法回馈到Java中，所以，算不得真正的开源。如果想参与，现在有机会了，因为Java开源了。

不过，有一点需要清楚，实际上这里的开源只是开放SUN的Java实现，而并非Java语言，平台API和规范。这些东西依然控制伟大的JCP手中，这么多年了，JCP的办事效率大家都很清楚。所以，这种开源方式对Java而言，不会伤筋动骨，但是，想大踏步的前进也是不可能的。

SUN对Java的开源采用了GPL 2，也就是说，可以发布自己的Java版本，但所做的改动要反馈回这个项目之中，SUN希望借此保持Java的纯正。谈及这次开源的意义，SUN把GNU/Linux也列了出来，至少以后发布的Linux发行版中加入Java可以名正言顺了，Richard Stallman可是最在乎名义的。

SUN有做好事的传统，Solaris、NetBeans、OpenOffice等等全都送到了开源阵营中，这次是Java。SUN是商人和技术人矛盾的组合，它做出的东西都很不错，只是无法给自己带来足够的价值。SUN不傻，能赚钱的东西，它是不会开源的，送到开源社区也是无奈之举。

顺便说一下，Java那个可爱吉祥物Duke也开源了。
https://duke.dev.java.net/

记不清是哪一年的《程序员》杂志上，采访Java之父James Gosling，文章的最后介绍了几本他推荐的书，其中一本是《Barbarians led by Bill Gates》（中文版《比尔·盖茨的野蛮兵团 》）。我着实没有想明白，为什么Java之父会推荐一本介绍微软的图书。事隔多年，一个朋友把这本书送给了我，于是，这个藏在心底的迷解开了。

很简单，这不是一本给微软歌功颂德的书。

虽然同之前读过的许多微软故事一样，这本书也是在描述微软一些产品的开发过程，但它并不是像那些公关人员刻意在为微软塑造形象，而是站在一个普通员工的角度在叙事，我们甚至可以看到一些典型的“愤青”语言。这本书的作者之一曾是微软的技术员工，经历了很多产品的开发，所以了解更多实情。

从这本书中，我们看到的是一个更加真实的微软，一个奋斗中的微软，因为很多事情的发生并不像官方描述的那么美好。如果不是看到这本书，我不会知道Windows险些夭折，因为当时微软的精力都在OS/2上，只是不经意间，一个员工让Windows跑在保护模式下，才让它生存了下去，Windows 3.0的大卖才让微软真正认识到Windows的价值。在这本书里，我们可以看到技术人员和管理人员之间的矛盾，可以看到不同团队之间的矛盾，就连微软精心为比尔·盖茨打造的完美形象也不再完美，准确的说，这本书里描述写的比尔·盖茨是我所读到最为接近普通人的。

记得和一个朋友聊天，头脑风暴的结果是得出一个奇怪的结论，领导是用来添乱和忽悠人的。不知道这个结论的适用度，至少从这本书的内容来看，它适用于微软，其中扮演证明角色的领导就是比尔·盖茨。在Windows的开发过程，比尔同志总是不断在给Windows开发组施压，让他们把东西做得再像Mac一样，事实上，二者底层的差距让相似并不那么容易，而比尔同志只是要求这样，而不去理会具体如何行事，最终的结果是Windows 1.0的发布一拖再拖。在手写输入开发过程中，Bill为了让大家更有积极性，总是会鼓励大家要开发最好的系统，而这些鼓励在老员工的心里已经起不到任何作用，对于老板的糖衣炮弹已经有了足够的抵御能力。不知道这种事是不是就发生在你我身边呢？

我从前看过一些微软的书，基本上的思路都类似，90年代之前的微软，描述得更多的是其中的人，一个奋斗的过程，让人看了心潮澎湃，之后的微软更多的转向了微软在市场上的攻城略地，却少了几分人气。通过这本书，不难看出，如果之前微软是个小公司的话，那么之后膨胀之后的微软更像过去人们口中的IBM，个体所起到的作用越来越不明显。从作者的口吻中，我们可以读出一个技术人员对此的无奈。

这本书写作的年代尚早，原书出版1998年，所以，没有后来很多有趣的大事，因为作者在1995年便离开了微软。幸好这本书流传并不广，没有对微软的声明造成太大的影响。不知道多少年后是否还会有微软员工站出来写出自己心目中的微软，估计得等他们离开了微软，因为身在其中，公司不会让他们破坏公司精心营造的完美形象。

GIMP，GNU Image Manipulation Program的缩写，一个图像处理程序，熟悉Linux的人对这个名字应该不陌生，几乎所有Linux的发行版中都有它的身影，它的功能相当于Windows的Photoshop。工作需要，最近开始跟它打交道，悲喜皆有，于是有了一些胡思乱想。

关于C程序的安装
在*nix下，标准的安装过程是./configure, make, make install。

屏幕上闪过一片片让人眼花缭乱的命令。幸福总是相同的，编译成功。不幸的却各有各自的不幸：不幸中的幸运是缺少东西，至少没有立刻宣判死刑，踏上未卜的前路，寻找拼图缺失的一角；更为不幸的是编译错误，稍微幸福一点的见错知意，手到病除，最为不幸的是只有对着屏幕发呆，一个陌生的程序，一大堆令人费解的错误。

最初拿到GIMP，我试图在Cygwin下编译，我的Cygwin对于它来说并不那么完整。于是翻开INSTALL，寻找缺少的部件，未曾料到竟一路找了下去，GTK+、Glib、ATK、Pango、Cairo……。到最后，我停在了一个不知从何入手的编译错误上。这时，我想到了GIMP的INSTALL上的一句话：除非你对从源码构建软件非常有经验，否则不要尝试自己构建所有这些库。果然是经验之谈！遂转到Linux上，支撑环境的健全使得构建一次成功。

对比Java的经验，从源码构建应用，C这套方法麻烦更多一些，当然，我这里指的是出问题的时候。因为Java出的问题多是缺少相应的类，一般都可以很容易找到，通常发布的会有源码和JAR两种形式选择，不愿意从头构建，就选择JAR。而对于C，一旦出了编译错误，基本上都很难解决，毕竟不是自己熟悉的。即便是缺少组件，因为C发布的大多是源码，而从源码开始构建本身就是一种风险，不要忘了，我们来自一个没有从源码构建成功的项目。现在各种各样的包管理器试图去协助解决这个问题，但标准的方法是根源，也是应用的最为广泛的形式，所以，问题很难得到完全的解决。

关于移植性
找几个C的项目来，你会发现稍微大一些的项目里面都有很多相同的东西，比如对于数据类型的定义，比如内存管理函数的封装，比如对多线程的封装……。这不是偶然，一切都来自C的可移植性。C当年凭借着自己的可移植性成功击溃了汇编语言，成为了一代语言霸主。平台的千差万别都要通过C来屏蔽，最初的时候，没有统一的标准，所以，每个项目都要通过自己的努力来做倒这些，所以，我们会看到类似的数据类型定义，类似的内存管理，类似的多线程……，以致于C程序员认为这是一种天经地义，于是有些年轻的项目一上来也是定义一套属于自己的东西。在程序设计的世界中，Java成功的解决了这些问题，它用虚拟机去解决平台问题，于是，C语言的这些问题随之烟消云散。当然，这并不是说Java世界就那么完美，社会在进步，所以同样的问题在Java世界以更高级的形式体现出来，君不见那么多的Web框架、那么多的持久化手段，那么多的DI解决方案。再造轮子不是坏事，新轮子总会拥有一些旧轮子不具备的东西，而旧轮子如果不甘心退出舞台，那就拿出更好的表现来。人们的选择是最好的评判。

与Java的跨平台方式不同，C的跨平台常常是通过宏定义对平台的差异进行枚举。枚举的问题显而易见，稍不留神，便会遗漏。所以，对于Java那样，几乎一个平台编译没问题别的平台基本就没什么问题，而对于C，只要编译平台未能覆盖到，就可能出现编译错误。就像bug一样，找到的越多，也许剩下的就越多。

顺便说一下，C用得越多，我越喜欢宏，它几乎就是一种元语言。现在DSL的概念开始流行，宏是一个不错的DSL载体。当然，它是一把双刃剑，所以，在实际开发中，我也不便多用。

关于插件结构
GIMP是一个基于插件的架构，我知道，熟悉Java的人脑子里出现了Eclipse。Eric Raymond在他的《Unix程序设计艺术》中讨论模块化时谈到了它。从我了解的情况来看，对于那些跨越时间的程序都有很强的可扩展性，比如TeX，比如Emacs，比如Unix。时间会改变一切，再好的设计师也无法预测未来的所有变化，与其费尽心力去完成不可能的预测任务，倒不如敞开大门，让程序拥有可扩展性，让未来的人来编写代码满足自己的需求。从这点上来看，Eclipse已经有了很好的基础，至于它是否能够跨越时间，慢慢来。

设计是为了应对变化，如果不变，再好的设计也是枉然。看过那么多关于设计的书，了解了那么多设计的原则，不妨再向这些拥有悠久历史的软件学习，它们真正体现了程序设计之道。