外刊IT评论 » 心得体会

【外刊IT评论】代码覆盖率：80%，不能少

花非花 — Wed, 08 Sep 2010 16:21:52 +0000

一大早，一个年轻的程序员问大师：

“我准备写一些单元测试用例。代码覆盖率应该达到多少为好？”

大师回答道:

“不要考虑代码覆盖率，只要写出一些好的测试用例即可。”

年轻的程序员很高兴，鞠躬，离去。

之后没多久，第二个程序员问了大师同样的问题。

大师指着一锅烧沸的水说：

“我应该往这个锅里放多少米？”

这个程序员看起来被难住了，回答道：

“我怎么会有答案？这取决于要给多少人吃，他们饿不饿，有什么菜，你有多少米，等等。”

“完全正确，” 大师说。

第二个程序员很高兴，鞠躬，离去。

末了，来了第三个程序员问了大师同样的关于代码覆盖率的问题。

“百分之八十，不能少！” 大师一拳锤在桌子上，用严厉的口气回答道。

第三个程序员很高兴，鞠躬，离去。

回复完这个之后，一个年轻的实习生走到大师身边：

“大师，今天我无意中听到了你对同一个代码覆盖率问题给出了三个不同的答案。为什么？”

大师从椅子上站起来：

“给我泡点新茶，我们聊聊这个。”

当杯子里倒满了冒着热气的绿茶后，大师开始说：

“这第一个程序员是个新手，刚刚开始学测试。目前他有大量的程序都没有测试用例。他有很长的路要走；现在对他要求代码覆盖率只会打击他，没有什么用处。最好是让他慢慢的学会写一些测试用例，测试一下。他可以以后再考虑代码覆盖率。”

“而这第二个程序员，不论对编程还是测试都是十分的有经验。我以问作答，问她应该往锅里放多少米，使她明白决定测试用例多少的因素有很多，她比我更知道这些因素——毕竟是她自己的代码。对这个问题没有一个简单的、直接的答案。以她的聪明完全能明白这个道理，正确的完成任务。”

“我明白了，” 年轻的实习生说， “但是如果没有一个简单直接的答案，那你为什么告诉第三个程序员‘百分之八十，不能少’呢？”

大师笑的前仰后合，绿茶都喷了出来。

“这第三个程序员只想得到一个简单的答案——即使根本没有简单的答案 … 而且即使有答案她也不会按答案做。”

年轻的实习生和头发斑白的大师在沉思中喝完茶。

【外刊IT评论】我害怕老程序员，因为我也变老了

花非花 — Sun, 05 Sep 2010 16:24:04 +0000

作者 Dan McComas

今天是我的生日。生日让我烦恼——每年的这个时候，我都会为这些自己不能掌控但又无可避免的事情而焦虑。那就让我们聊聊这个吧。今天，我开始担心在事业上的前途，开始担心我作为一个web开发者对这种工作的热情。我可以坦白的承认：我害怕做老程序员。现在，我担心我正在成为他们中的一员。我的职业生涯将成怎样——14年后，当我50岁时？

过去的12年里我曾干过6份工作，再加上无数的辅助项目，跟我一起工作的都是一些年纪较大的程序员。而现在，我面对的却是一些让人困惑的中等年纪的经理，架构师，DBA，和软件工程师，但我就没遇到过一个优秀的中等年纪的程序员。（对于“老程序员”，我指的是奔50的，40岁左右的人）。不要误解我，我相信这种年龄上的优秀的程序员肯定是有的——只是我没有运气和他们一起共事和学习。

今天，我感觉像是走到了中途，正面对一个重要的抉择。我可以仍然沿着现在的道路走下去，仍然作为一个程序员。我知道这条路的前方会有什么：永不停息的长时间奋斗，努力的保持优势，学习那些如雨后春笋般出现的新技术和新语言，还有克服对年轻程序员的嫉妒，这个我感受太深了。另一方面，我也可以往管理层方面发展——一个同样令人恐惧的职业方向。这对我来说是一个新的，缺乏技术经验的方向。也许我能很好的适应管理工作，但我很难做出这个决定。

我估计很多人和我一样有相同的恐惧和想法，同样面对这样艰难的抉择，我希望能听听你们的意见！我希望关于这个主题的讨论能持续下去，数周，数月，一直到我50岁，我会一直以写博客为乐，会满足于在任何公司以一个专业人员的任何身份工作。现在，我开始努力去享受我的生日了。

【外刊IT评论】鲜为人知的编程真相

花非花 — Sun, 05 Sep 2010 03:47:37 +0000

当程序员的经历让我知道了一些关于软件编程的事情。下面的这些事情可能会让朋友们对软件开发感到惊讶：

一个程序员用在写程序上的时间大概占他的工作时间的10-20%，大部分的程序员每天大约能写出10-12行的能进入最终的产品的代码 — —不管他的技术水平有多高。好的程序员花去90%的时间在思考、研究和实验，来找出最优方案。差的程序员花去90%的时间在调试问题程序、盲目的修改程序，期望某种写法能可行。
”一个卓越的车床工可以要求比一个一般的车床工多拿数倍高的工资，但一个卓越的软件写手的价值会10000倍于一个普通的写手。“ — — 比尔盖茨

一个好的程序员的效率会是一个普通的程序员的十倍之上。一个伟大的程序员的效率会是一个普通程序员的20-100倍。这不是夸张 — — 1960年以来的无数研究都一致的证明了这一点。一个差的程序员不仅仅是没效率 — — 他不仅不能完成任务，写出的大量代码也让别人头痛的没法维护。

伟大的程序员只花很少的时间去写代码 — — 至少指那些最终形成产品的代码。那些要花掉大量时间写代码的程序员都是太懒惰，太自大，太傲慢，不屑用现有的方案去解决老问题。伟大的程序员的精明之处在于懂得欣赏和重复利用通用模式。好的程序员并不害怕经常的重构（重写）他们的代码以求达到最好效果。差的程序员写的代码缺乏整体概念，冗余，没有层次，没有模式，导致很难重构。把这些代码扔掉重做也比修改起来容易。

软件遵循熵的定律，跟其它所有东西一样。持续的变更会导致软件腐烂，腐蚀掉对原始设计的完整性概念。软件的腐烂是不可避免的，但程序员在开发软件时没有考虑完整性，将会使软件腐烂的如此之快，以至于软件在还没有完成之前就已经毫无价值了。软件完整性上的熵变可能是软件项目失败最常见的原因。（第二大常见失败原因是做出的不是客户想要的东西。）软件腐烂使开发进度呈指数级速度放缓，大量的软件在失败之前都是面对着突增的时间要求和资金预算。

2004年的一项研究表明大多数的软件项目（51%）会在关键功能上失败，其中15%是完全的失败。这比1994年前有很大的改进，当时是31%。

尽管大多数软件都是团体开发的，但这并不是一项民主的活动。通常，一个人负责设计，其他人负责实现细节。

编程是个很难的工作。是一种剧烈的脑力劳动。好的程序员7×24小时的思考他们的工作。他们最重要的程序都是在淋浴时、睡梦中写成的。因为这最重要的工作都是在远离键盘的情况下完成的，所以软件工程不可能通过增加在办公室的工作时间或增加人手来加快进度。

【外刊IT评论】优秀的产品能得到用户，优秀的服务能赢得粉丝

花非花 — Wed, 01 Sep 2010 16:29:18 +0000

上周Amazon公司邮件通知我，一位负责S3的产品经理要跟我聊聊我们对他们的服务的使用情况。（我们使用Amazon的S3提供各种图片和视频的存贮服务）。看起来我们有个绝好的机会来跟Amazon里面的人谈谈我们遇到的问题和希望得到的功能。

一接通电话，我们就完全明白了，这个人完全不是来提供服务的。他只是想了解我们的想法，去计划如何提高销售额和留住客户。我不想在这上面浪费我的时间，也不想把购买计划告诉Amazon来让他们扩大业务。我在电话里直接表达了我的意思。

为什么不呢？因为他们的服务不好。Amazon并不在乎我，所以我也不在乎他们。他们有个好的产品，他们得到了我这个客户，但他们没有好的服务，所以他们不能使我成为粉丝。

当我们有问题时，他们并不是想着来帮助我们。他们想的是迫使我们付服务付费，这每月要花掉500美元或者产品购买额的20%，这可不少。随着我们业务的增长，这笔费用可承受不了。Amazon不但不关心他们最大的客户们，反而去惩罚他们。我们被迫离去。

我在电话中告诉那个人，要想留住我们这个客户，Amazon需要去做的应该是提供更好的服务。我们需要更好的工具来分析用户使用习惯。我们需要更好的工具来阻止误用。我们需要当有问题时直接跟Amazon取得联系。Amazon的业务代表看来并不在意这些，他太关注报价了。

我们使用的另外一个提供商是Rackspace。他们的做法正好相反，他们尽可能的提供最好的客户服务。他们想尽办法让我们满意。因为他们优秀的服务，我成了他们的粉丝。我总是介绍YC公司使用Rackspace。如果Rackspace需要帮助，我会随时准备帮助。我希望我能为他们做更多的事，因为他们很出色。

有大量的公司都为我所尊敬。Costco, American Express, Rackspace，还有其它许多公司，我一直的在向人们推荐，尽管我不从他们那里得到一分钱。我要这样做，因为喜欢这些公司，因为他们在意我。他们提供出色的客户服务。我是他们的粉丝。

创建一个成功的公司，你需要的不仅仅是大量的用户。你需要粉丝，由衷的祝福你成功的粉丝。要想做到这些，你需要给与他们出色的产品以及出色的服务。

【外刊IT评论】Android = Java

花非花 — Tue, 31 Aug 2010 16:08:39 +0000

作者opinali

最近整个Java阵营都陷于一场讨论Oracle和Google之间关于Android平台的专利诉讼官司的混战中。我已经在很多地方都发表过我的观点，但这确实是个重大的话题，需要在所有地方反复重申这个观点 … 所以，这篇文章就是要再次的完全的揭露事实真相。

第八大千禧年问题： Android = Java?

前几天，有研究者宣称找到了P != NP的证据,这在编程界引起了不小的兴趣——至少为此狂热了好几天，直到开始有评论家指出证据中有很多的缺陷。我在做计算机科学系学生时研究过这个题目，但说实话，我的高等数学的水平还达不到看懂这些证据的水平（P = NP? 是克雷数学研究所提出的七个千禧年数学问题中的一个。）所以，还是让我们来讨论一个稍微简单点的问题：Android是否相当于Java？请注意，我并没有说相等，我说的是相当，就像P = NP里的那样。

相当的类/字节码格式

在很多层面上，Android和Java都有明显的相当。Android应用程序是用Java(TM)语言写成的，使用JDK的javac(或等效工具，例如ECJ)来编译。这个过程产生标准的Java字节码（.class文件）。这些文件再转化成Android的.dex文件，从使用的角度来看，它就是一种不同格式的Java class文件。不错，这是一种更优秀的格式；对Sun自从1994年以来的设计有了很大的改进。但就如你可以把一个GIF格式的图片转换成更高级的完美的完全等效的PNG格式，尽管它们的字节流完全的不同。

等效的文件格式在细节的实现上非常的不同，主要是为了优化。就好比，如果我们简单的满足于低效率的视频数据流，没有采用高端的、跨不同框架的压缩技术，那我们就可以避免跟MPEGLA视频解码专利做斗争的麻烦了。

Android特异的classfile设计有好几种动机；而为了避免和Sun的知识产权保护冲突显然是一个主要的因素。不管怎样，Google并没有走的离Java足够远。两种文件格式非常的类似。它们在特定的底层数据结构上有区别，但这些结构体在语法上一致的，存储完全相同的信息。我相信在JavaSE或JavaME VM里可以轻易的在它们的系统classloader里添加一个.dex分析器来加载”Android classes”。

Android SDK 依赖于.java -> .class -> .dex 转换的事实情况既微不足道也毫无损失。“毫无损失”的事实很重要：当GIF = PNG 时，跟受损的JPG文件就不等了 —— 它解码不出完全相同的信息。如果JVM和Dalvik都各自独立，你很难写出一个相对简单的工具将一种编译过的代码转换成另一种 —— 而且不做任何妥协：不丢失信息，不使用冗余来补偿某种特征在一种VM中是first-class而在另一种中却不是的情况，不需要额外的runtime层上在一种VM中实现另一种VM的核心API。

(我知道dx转换器有多么的复杂。我看过它的源代码。那个字节码转换器是一个巨大的，全功能的反编译/重编译器，通过SSA构造完成。但是这个转换器在概念上仍然是无足轻重的；从Java字节码到Dalvik字节码的映射在设计上是很平滑的。堆栈相对于寄存器架构中细节上进行了优化；而重要的东西，例如VM层的类型系统是完全一致的。)

VM相当

这Dalvik 和 JVM 的相当也是很容易看清楚的。并不只是源代码或字节码格式上的问题：它们的runtime对等物上也一样。一但一个”Android class”被加载到Dalvik VM里，它就会像Java class一样运行，像Java class一样工作。 如果你懂得Java编程(深入到高级的，底层的细节)，你也就懂得Android编程。你只需要学一些新的API和框架概念。他们是对等的系统。

是否记得微软的.NET? 当.NET刚出世时，Java阵营迅速的反击指责.NET是对Java的剽窃。我也是其中的一份子，但今天我看问题更清楚了。是的，它过去是个严重的剽窃产品；C# 1.0 就是一个… 区分一种语言和另一种语言最简单的方法就是看它们的惯用风格 —— 例如toString() 相对于 ToString()。但在最重要的VM规范里，微软做了很大的功课。它的CLR,CLI,和核心框架，都非常的不同于Java，所以我们不能说JVM = CLR这个等式。你不可能使用一个简单的文件格式转换工具把你编译好的Java class转换成能在.NET runtime上运行的代码。

要证据吗？你只需看一看IKVM就知道了。这是一个非常有趣的项目，它能够使Java和.NET跨平台兼容，于是，你的Java代码可以在不做修改的情况下在CLR（或者是等效的.NET runtime，比如Mono)上运行… 但IKVM并不是一个简单的、类dx的文件格式转换器。对Java class的转化、对Java核心API的适配，都是十分的复杂，即使对一个简单的HelloWorld程序也是这样。各个平台的内部机制，如反射，安全，并行，异常处理，字节码验证，I/O，以及其它核心API，特征上大致相同，但是在细节上完全不同，一些死胡同的情况会迫使IKVM不得不钻越一个又一个的火圈来让Java代码运行到了.NET VM上。它需要依赖于一个巨大的额外的runtime层，来适配从OpenJDK源代码里来的完整JavaSE API。我大致的关注IKVM的开发已经有数年了 —— 我阅读这精彩的IKVM 博客 – 所以我完全清楚他们为了让Java程序和JavaSE应用适配到.NET上所做的巨大的努力。(这项工作仍然没有完工；而且很多部分都需要以丧失某些性能为代价。)

(老的Visual J++ Visual J# 也不是一个简单的 Java-to-.NET 转换器。我不想讨论它，但我们完全可以说Visual J# 对Java的兼容并不比最早期的IKVM强多少。)

我把P = NP引进来了讨论；有些人把图灵等效(Turing-equivalence)理论引进来，说任何图灵完备的平台/语言/VM都是相互等价的。这也没错，但与本论题无关。图灵模型这种方式太泛化了；使用这种表面价值来考量会把更个软件专利系统摧毁(尽管这不是个坏事！)。我们需要在地上为JVM等效画条线，一条更接近实用需求而远离图灵等效的线。按我的观点，这微不足道的二进制格式转换，穷尽的高层源代码和runtime的兼容，使Android明显的处于Java等效的这条线内。

APIs 和 Runtime 相当

Android使用了一个相当大的JavaSE APIs子集。这些APIs (来自于Harmony项目)都是全新的实现，但它们是以JavaSE为模子。如果不是因为TCK许可证问题，Harmony完全可以取得JavaSE认证。但这并没有改变这样的一个事实：Harmony 和 JavaSE APIs是 完全的等效的 —— 这是特意的，不是偶然的。就像Charles Nutter——有名的JRuby人物——最近写道:

Android支持一个不完整的（但相当大的）Java 1.5 类库子集。这个子集大到一个复杂的JRuby项目几乎不经任何修改就能在Android上运行，很少有限制情况。

看起来Dalvik对JVM是如此的接近，它不得不完全兼容大部分的JVM规范，包括完全详细的JMM (就像Android支持Java风格的线程和并发，已经深入到了高级的java.util.concurrent包里了)。可为什么有如此多的”Dalvik是个新VM“或”Dalvik不能运行Java类“的说法呢(90%的讨论这场诉讼的论坛和博客都持这种观点)。

最后的思考

这篇博客并不是关于Oracle和Google诉讼官司的法律依据的。我将会忽略（我会删除掉）那些跑题的评论（跟Android = Java不相关的话）。我只是讨厌那些”Android跟Java完全没关系“的胡说八道;Google和 Android的拥护者必须要找一个更有意义的论据。

(我将拭目以待这场官司的进展，带着我所有的预见，直到所有细节和最终结果都出来。除非你有内部消息（我没有），不要太天真。 保持冷静。我们并不知道Oracle的 —— 或 Google的 —— 真正的全部动机和计划。我们并不知道这荧幕背后的故事，自从2007年Google首次宣告Android的诞生(这导致了JavaME生态环境的崩溃), Sun就痛恨不已，但最后还是不得不夹着尾巴行事。我不相信任何一个有10亿美金的股东控股公司会有利他主义的动机：Google不会，Oracle不会，即使我喜爱的老的Sun公司也不会。我们等着看吧。)

我不相信Google没有能力创造出一种既不背离Java太远，又以Java风格为基础的平台（就像.NET做的那样）。 Dalvik，以及Android框架，它们可能是在权衡了与大量的现有的Java程序，类库，Java天才，和Java工具链高度兼容的愿望的最后结果。微软在一咬牙一跺脚后放弃了现成移植Java带来的好处，创造了全新的.NET。Google没有这样做。

这个Android = Java等式显然并不是包括所有的东西（不是一一对应的）。每种平台都有自己一些独特的API，当然，Android是一个完整的操作系统，包括一个 Linux-based的内核，图形系统和电信堆栈，等等。很显然，我只是谈论其中最常用的部分：Java为中心的用户使用区/依赖于Java源代码、 Java classes（切不管什么格式）、Java APIs（包括成千上万的常用JavaSE APIs)和出色的类Java的虚拟机的应用框架。对于Android和其它的Java平台之间的关系有个准确的说法，就是使用版本的概念。我曾记得有个博客说过这样的话”Android里没有’J’“。那么，我现在说也不晚：我建议把Android改名为Java GE（Java Google Edition）。这样一来就再也不会导致混淆了。

【外刊IT评论】证据就在代码里

花非花 — Tue, 24 Aug 2010 15:55:40 +0000

招聘一个程序员，唯一对你有意义的是他能写出好程序的能力。 很少人像这样去招人，他们更喜欢去挑剔程序员的个人癖好和性格缺点。

我一说出这样的话，人们大量的评论就会批评道：你错了，错了，完全的错了。 好的程序员需要具备沟通交流的技能，他们要有跟他人一起合作的能力。团队里不止你一个人! 事实上，人们会说：最好折中一下对技术上的要求，这样可以找出更能适应企业文化的人。

你不如这样说更合适：找不到那种技术上又好、又能适应企业文化的人，我就等着，一直找到为止。
我们很少有敢这样奢侈的公司，也许Google可以这样，就是Google这样的公司也一直处于一个“对招聘程序员感到绝望”的状态中。如果你决定去等，我可以预见到每招到一个程序员你都要等待一个漫长的时期，同时业务会因为缺乏程序员而崩溃，火烧眉毛。

那么，那种更好呢？

让我们来考虑要那些中等或下等的程序员，他们和蔼可亲，而且努力工作。 他们的程序写的不好 – 他们的程序根本不是按照他们想的那样工作，即使他们做到了，那也是烂程序，很难去维护。他们在基本的功能上挣扎探索，更不解决不了复杂的问题。但是他们却能跟上团队，项目进度每天点都在更新，可以看见他们每天都在座位上奋斗。一切都很好，你的经理会很高兴，因为整个团队看起来在平稳的向前推进。

当发布日期不得不往后推迟，产品Bug多的没法使用，人们会哀叹说软件本来就是很难做，于是投入更多的和蔼可亲的平庸的程序员去修复问题。 事情的结果我想大家都知道。

对于程序员，没有太多的事情可以用和蔼来解决。一个友善的平庸的程序员可以成为业务分析师，技术性的销售员，或着其它的能够利用他的和蔼和他的一点点的技术知识来工作的职位。这样的工作他们会很满意，但这都是在茶话会工作上的，可不是去找出有效的办法做出好的软件。

另外一个选择是，找个程序员，他能做出好的程序，但也许不善于和他人相处，或者老是迟到，或其他。他能开发出按照设计运转的软件，他能把复杂的问题抽象成一个简单的问题。软件好使，可维护，你随时可以按要求修改。

这个世界很真实，有太多的方式都会让我们把事情搞砸，但至少我们是有机会的。人可以给人留下不错的印象。团队可以建设的不错。员工在长时间的为你工作，不错。大量的业务没有按照预定的设计工作，但还是成功了，不错。但是绝对不会有伟大的软件会在平庸的程序员手下实现。.

证据就在代码里。 就这些。

【外刊IT评论】嗨，兄弟，做不成有钱人完全没什么

花非花 — Mon, 23 Aug 2010 16:01:37 +0000

作者 Sasha Pasulka

我有个很亲密的男性朋友，是搞技术的，他痴迷于发财致富。
他很聪明，受过很好的教育，是个吃苦耐劳的人，但是，说实话，他很可能就不是一个能干成大事业的料。他能轻松的在任何一个大公司里获得一个小六位数的薪水，但是他有一个根深蒂固的想法，就是要创办一个科技公司，获得巨大的成功，挣到无数的钞票，这才能幸福。我看着他慢慢的失去健康，失去理智，失去信任和一次次的失去女朋友，都是由于这个信念。“你这个想法最终会害了你的，”我对他说，“你必须马上停下来。”

但是他不会停下来。

后来，不止一个其他的男性朋友向我透露了他的金融危机感：“我感觉，如果没有挣到足够多的钱，我就不能算是个成功者。”

我可以打包票的说，从来没有一个女性朋友对我说过这样的话。我的女朋友们和我当然也都想成功；我们都想在自己的领域里取得重大的成就，我们对那些还没有实现的目标都倍感压力，但是没有一个人特别的关注如何发财致富。我们几乎很少谈论到钱。

再说了，这个世界也不必在乎我究竟挣了多大的钱。如果我想要很多的钱，而我又很苗条，足够漂亮，那我找个富人结婚就行了，不是吗？

看见了吧，我知道男人是如何体验渴望金钱上的成功所带来的压力的。我知道当走进一间屋子、发现我是这里最没有吸引力的女人时的感受，环顾四周，其他的所有女人都比我漂亮 –– 骨感，长发飘飘，傲慢的胸部，丰满的嘴唇，皮肤白嫩 — 想马上消失，感觉到惊恐，感觉鸡立鹤群，感觉到生命中做曾做的和正在做的事情都毫无意义了，因为此时的感觉太真实了。

但是，对于每张那些极富魅力的骨感的封面女郎照片，都会有成千上万的文章来告诉你女人真正需要的是什么，那是心灵上的东西。每当我感觉身体某处不符合某种标准时，总会感觉周围响起那些媒体尖叫的声音：“她化妆了！她做过整容手术！她有一个二十人组成的美发美容专业团队！你有一亿项其它的优秀品质，不要把时间浪费在外表上。”

可对男人们却不是这样。每当福布斯报道一个商业大亨时，内容总是讲他的公司如何成功，他的22岁的超级模特女友，他的欧洲的八套房子，没人去跑到电脑旁发布一个篇文章告诉大家不要把这要挣取荒唐数目的财富的压力放到男人身上，这些压力给了男人们的妻子和孩子慷慨的”特权“，男人还像历史上那样做唯一出去工作的人。没有人会冲着那些计划要开创下一个Facebook的人发出阻止的尖叫，同样，我想，明天醒来，又会蹦出一个跟西班牙影星Penelope Cruz长的极像的人。

我想这就是问题所在，我想有必要再次重申：我们给了男人太大的压力，让他们去建立一个王国，让他们挣钱建这个王国。男人深受其害，就像一个年轻的女人想拥有苗条的身材。我们并没有说什么。我们没有真正去阻止男人往这方面想。

为什么？

我认为，这种不平衡来自于一种单边的“女权主义”文化，总是强调在任何方面女人都是受害者，同时又无视现代男人们在感情上的挣扎。“你们很可怜，”我们总是对女人这样说，“这个世界是平等的，而你们总是能被轻易的伤害。”

我们从来就不该对男人说这样的话。当我们在谈论求美的压力对女人如此伤害时，就不要刺激男人那些固有的弱点。
财富的困扰通常是默默的到来，容易被伪装，容易被焦距，容易被激化，从来不像一个追求美丽的女人遇到的饮食不调或整容失败带来的痛苦那样明显。

我们都看到，一个男人失掉工作后，杀了妻子和孩子，然后自杀，这样的事情过去、现在都有。“多可怕的精神问题患者呀，”我们会这样说，我们会数天的谈论压力是如何把男人推向边缘，但我们的生活中却没有留下足够的空间来同情和讨论这种极端事情。

没有明显的观点，足够的根据，能证明这跟媒体的宣传有关。所以我们也就不在谈论，一些精神上崩溃的男人在这种压力下会感到非常的孤独。

我们有些人要开办公司，因为我们喜欢开公司 – 我们喜欢做自己的老板，定下自己的目标，那是一种白手起家的兴奋。而有些人开办公司是因为看到有人从中得到了大量的财富，我们也想成为富人中的一员。这两种都没有对错之分。

我就是要把这些情况说出来，我希望有人去说：嗨，兄弟，富不富真的没什么。就算你从来都没富过，那也没什么。生活中有很多比挣钱更有价值的东西，生活中那个你真正想得到的人知道这些。

而且，如果你变富了，你还会为我花钱做吸脂手术吗？

【外刊IT评论】我的丈夫是个程序员

花非花 — Sun, 22 Aug 2010 16:05:05 +0000

我在11年前认识了的我丈夫。当时是南缅因州大学新生入校的日子，我带着吉他去宿舍。他饶有兴趣的盯着我的吉他。之后他敲响了我的房门，自我介绍道：“嗨，我叫Adam，我就住在走廊的对面。我是个计算机程序员！”

他做了一很勇敢的决定。 10年前当程序员并不像今天这么“火”，这个行业并不被社会重视，他似乎也根本不在意这些。不管怎样，我们相爱了。我当时并不懂编程，但却被他那义无反顾的精神和毫不在意被人当作怪人的态度打动。是发现了他也弹吉他使我们走到了一起。如果仅是他住在走廊我的对面，命运也不会做出这样的安排。

在随后的一周周，一月月，一年年，他慢慢的吸引了我的注意力，他会对着他的游戏机的硬件清单大发雷霆，他能在虚拟世界里的游戏竞赛中为我独尊，他在ColdFusion平台上制作了他的毕业论文项目，他会用长篇大论来解释他的编程理论。我会安静的坐着，惊奇的看他把一台PC机拆成零碎。我听他讲编程上的问题，看他开发网站。与此同时，我还只是朦胧的感觉到我未来的职业应该是跟科技和英语有关，但我着实对Adam的生活发生了兴趣。

几年以后，我很自然的就知道了，“Ruby”并不是指的七月的生日石，而“Ruby on Rails”也不是邻区的新潮人在火车轨道上举行的敬拜珍贵宝石的奇怪活动。几年时间里，我事实上也培养出了他的同样的兴趣。2005年末他深深的喜欢上了Ruby，我全力支持他，而且也知道Ruby的不可思议之处。几年后，当我决定了开始学习Ruby，我在博客上写了一篇关于Ruby社区的文章。很多人都很奇怪为什么一个像我这样的Ruby新手会对Ruby社区有如此的了解。答案是，我在决定学习Ruby编程之前已经关注这个社区很久了。在我曾经打开TextMate编辑器、保存第一个.rb文件之前，我就知道了这个社区里有那些大人物，Ruby的发展趋势，和历史事件。

当你的伴侣开始跟你讲编程的问题时，或讲最新的测试框架时，你的眼神里是否显露出一种呆滞和恍惚？事情并不是你想象的单调乏味。问他问题，尝试着去理解！如今当我遇到女人们时，我并不回避给她们谈我的工作，谈我喜欢的电脑游戏，谈我着迷于 D&D 游戏以及其它这样的荒诞事情。通常我得到的回复是这样的几句：“编程？我想我丈夫做的好像也是这方面的。”对于此，我总是问道：“哦，真的吗？他用的是什么编程语言？”她们的回答每次都一样：”语言？哼，我可不知道。不止一种吗？我并不真正知道他在干什么。我对这些东西没兴趣。“

这每次都让我感慨万分。你嫁给了一个人，可是你对这个人花去将近40-50%的时间去做的事情一无所知——除了工作名称。我们是否可以把今天的高离婚率和他们对配偶的生活缺乏兴趣之间画一条危险的关联线呢？当两个人第一次相遇时，一个人很容易根据自己的”看法“而坠入爱河。但我认为如果配偶不能够对对方的爱好和生活工作有真正的了解，那么这两个人将很难经受的住生命的各种起起伏伏，艰难和考验，要知道，生活中每天都有挑战。如果你对配偶的每周40小时的工作内容没有一个基本的理解，你们就不能成为一体。

我并不是在建议当你遇到钟情的对象时要放弃自己个性和个人兴趣。而是要你睁大眼睛，用你的伴侣的视野去体验这个世界。我承认，有时Adam会在某天晚上对元数据编程谩骂个没完没了，此时我也就跟他的思想走不到一起了。但通常情况下我会投入到他的兴趣当中。而且为什么不呢？我爱他，这就要求我去了解他。而了解一个人就是要你们去相互讨论和理解对方的兴趣。 Adam会花数百小时艰难的听
Ani Difranco, Dar Williams, 和 Iron & Wine 唱片，我会在一旁神经质的给他解释所有的歌词。在我的鼓励下他学会了打网球，尽管现在不得不忍受每次被他打败的结果。在大学里他看过我的芭蕾舞表演，他甚至都知道了不少其中的姿势的叫法了。下面的照片是我和Adam在徒步翻越缅因州Tumbledown山时拍的。它见证了Adam自愿从计算机旁走开，参加到我喜欢的户外运动中的事情。他很顽强。

徒步旅行 hiking up Tumbledown Mountain in Maine

参与到你的伴侣的兴趣中并不是一件难事。如果你觉得很难，那你也许要思考一下自己是不是太自我了。即使朋友之间，我也努力的聆听和理解他们的兴趣和爱好。我经常会听到一些新奇的东西，经常我会为自己找到了一些新爱好。

就我来说，如果当Adam在奇怪的跟计算机大喊大叫时，我只是发呆，那我就不会有今天的生活。
那是无数的小时的一起玩视频游戏，一起深夜编写手册，一起为新应用做头脑风暴式的讨论，一起野营旅行，一起听乡村音乐才铸就了我们之间的关系。即使你跟你的伴侣在事业上并不是相似的道路，通过对他工作和喜好的了解，你也可以使他为你打开他的心扉。这能扩大你的视野，帮助你减少生活中的不愉快。你们应成为一起工作的一体。我并不是像Adam那样做职业编程的；我也没有向那方面发展。我懂编程，但不幸的是，自小就没人给我积木做训练，在学校和家里也从来没人鼓励我学数学。工程学和解决问题的才能从来就没有培养出来。所以，当我想对编程感兴趣时，这对我的难度看起来比其他人大。但我的强项是写作，编程方面和技术方面的题材对我是个巨大的兴趣
– 所以，能得到Intridea社区管理员的工作让我的世界真正的兴奋起来。我关注着我喜爱的世界，我能感受到它的脉搏，我所做的一直给我带来回报，给我快乐。

所以，如果你和新朋友们在一起，想办法培养自己对他们爱说的事情的兴趣。如果你和老朋友在一起，通过询问他们的工作、倾听他们的回复来再次发掘你的生活爱好。不要假装爱好。不要做那种连她丈夫使用什么编程语言都不知的女孩子。你要做那种让你的丈夫的朋友吃惊于你还知道Java时什么的酷妻子，不做那种在讨论Ruby社区里的自由派时说出“亲爱的，我不知道你原来还是个珠宝商哪！”的妻子。

【外刊IT评论】云计算的可伸缩性迫使App服务无状态化

花非花 — Wed, 18 Aug 2010 16:43:26 +0000

场景内容

云计算因其软件上的按需付费模式而大获成功，它创造了一种伸缩性模型：

如果有两个公司，它们正好在相反的时区里，白天都需要10台服务器，晚上减少到1台。那么一个云计算服务商需要11台服务器就能同时为这两个公司提供服务——在任何一个时间点，拿出10台给一家公司用，1台给另一家。
如果这两家公司都使用自己的机器，他们每家都要买10台（总共20台）。其中9台机器会在夜里闲置。
时区可不是来共享这些闲置资源的唯一理由：
- 运算需求同样是一个很好的应用场景。有些公司会在圣诞节时需要很强的运算能力，而另外一些公司则是在财政年度结束时需要，等等。
- 有些公司很可能是不能预知何时需要多少资源。例如slashdot效应。不管是哪种情况都是通过共享来让他人使用你的空闲资源。这就使按需付费成为可能。
你可以把这种概念扩展到整个平台成本上——应用程序服务器，数据库和应用。

关于伸缩性的最重要的一点就是——根据负载的情况，白天给公司提供服务的9台机器在夜间自动缩减到1台。而这一台之外的其它8台机器开始给其它公司提供服务。云计算的这种能够允许两个租户（或更多）共享业务处理能力的特性就叫做过程共享的多重租赁。

那么为什么要无状态的系统架构呢？

假设个场景，就说白天时间有1000个用户分布在10台机器上，每台机器大概服务100个用户。在一个有状态的系统结构中，每台机器都只为在本机登录并产生了会话(session)的那100个用户服务。这个由http负载均衡来实现，叫做会话粘连(session stickiness)。

当夜间到来时，让我们假设有900个用户退出系统，其他的100个用户仍然在线。理想情况下，只需1台机器就可以为所有的这些人提供服务。然而，这100个用户可能会分布在所有的这10台机器上，每台10人。所以，缩减到一台机器是不可能的，这样一来，伸缩性就给限制了。

解决这个问题的一个方法就是把10台机器的所有会话状态都复制到一起。这样一来，任何一台机器都可以为这些用户服务。但每台机器就会用掉10倍的内存来保留所有用户的会话状态。这些会降低服务器的可用性，因为一旦有更多的用户使用时，集群中就需要加入更多的服务器。当你共享多重租赁的应用中的租户突然暴增时，你就没法应付了。

无状态化后情况会如何变化?

在无状态的应用中，你可以在任何一个地方执行用户的请求——会话粘连(session stickness)不再是个问题。当用户从1000减到100后，你可以立即释放9台服务器，调给其它公司使用，只用1台为这100个用户服务。.

这听起来很简单。而实际操作起来却不是那么容易。所有的应用都需要状态。如果应用服务器不去处理这些状态，你就必须想其它的办法。数据库就是一个明显的问题。当前的数据库已经在扩展问题上遇到了足够的麻烦了，再加上状态管理，那是绝对不可行的。所以NoSQL才要“分布式”存储。

在PaaS服务商中你会看到这是一种常见的架构模式：

Google App Engine – 无状态请求 + Big Table
Microsoft Azure – web角色 + Azure存储/SQL
当然了，还有我们公司 – OrangeScape，它是运行在GAE/Amazon EC2 之上的。
我估计VMforce也是这样的 – Spring stateless session beans + Force.com DB

那就都云计算吧！有状态的应用+SQL数据库已成昨日黄花了。(抱歉！实在忍不住。)

【外刊IT评论】Scala是个有趣的语言

花非花 — Tue, 17 Aug 2010 16:08:38 +0000

经常读我的博客的人应该知道，我最喜欢的编程语言是Haskell。我喜欢函数式编程，Haskell是一个能把函数式编程推向极致的语言。虽然如此，我仍然时刻关注着其它新兴的和即将产生的编程语言，特别是函数式的编程语言，所以，当Scala诞生之初我就知道了这种语言。当时，我粗略的对它了解了一下，并不是很喜欢；我感觉它的那些语法对于我的口味来说过于甜腻，而且这种语言看起来异常的复杂。然而，一些我很尊敬的人都喜欢这种语言，所以我就再次的看了看。我的评论并不是基于对这种语言的一个全面的了解之上，只是我通过几周的阅读和实验得到的收获。不管怎样，我已经有足够的认识来声明，Scala是个有趣的语言，值得去研究，特别是当你有Haskell编程背景的情况下。我使用的是一本“阶梯教程”(Programming In Scala by Odersky et al)，这本书写的非常好，我全力的推荐大家读一下。

我想学一种新的编程语言主要有两个原因。一个是我想找一种跟目前我使用的语言不同的语言，我想寻找一种另外的编程体验。另一个是我想找一种具有很多我从没见过的有趣的新特征的语言。Scala的出现完全满足了我的苛求。.

本质上来讲，Scala是一种运行在JVM之上的语言，它很快，使用它我可以做图形界面编程，web编程（用它的Lift框架），和移动设备编程（使用Android，我也知道让Scala程序在Android上运行并不是一个很容易的事）。Scala在这些领域出现的时间比Haskell早的多。我期望Haskell能最终赶上，但是我现在就已经喜欢上了写这些类型的程序了。

从理论的角度来看，Scala的诉求是静态类型背景下的函数式编程和面向对象编程的组合。这可不容易做到。在动态语言里倒是容易些（例如Lisp使用CLOS），而静态类型会使事情变得非常的复杂，尤其是子类型化和继承方面。Haskell可部分的支持面向对象编程（特别是使用类型类和现有类型），但我在Haskell里没有发现面向对象风格的继承模型，尽管这是十分有用的。Scala有一个非常复杂的面向对象系统，还包括一些诸如显式sub-和supertype标记，协方差(covariance)和反变(contravariance)标记,等等。这些都超越了我所见过的其它的面向对象的编程语言。实际上，Scala实现了把所有的函数性特征都作为对象，所以把它称作一种对象-函数式语言并不准确，不如称作为超级面向对象语言更合适。

我认为Scala的面向对象不是Haskell能比的；它是对于它的这种范式上的一个最佳案例。（我这里忽略掉了那些类型依赖的函数式语言，诸如Agda/Coq/Epigram，我知道它们，但基本上它们已经不再被当成一种用来做普通编程的语言了。）对于在静态类型的环境中，是否对象已经超过函数变成一种更基础的结构，我并不清楚。在动态类型语言中，你可以由函数得到对象（可以假设函数就是闭包），或者你可以由对象得到函数，所以两种观念是可以相互转换的。不论这是不是一种使用静态类型的案例，我想，用两种语言从不同的方向来考虑这个问题是件很有趣的事情。另一方面，我曾学习过Smalltalk的面向对象特征，我不得不说，我从没见过第二个静态类型的语言具有Smalltalk这样优雅的简单消息传输模型。再一方面，我更希望用Scala而不是Smalltalk来写一个大型程序。(并且，如果你真的想直接进行消息传输时，Scala也有Actors类库来支持你。)

另一个Scala里我喜欢的东西，也是Haskell共有的东西，就是他们都有学院理论根源。当你在设计一种具有深奥的类型系统的语言时，了解一些类型理论会非常的有帮助。Scala和Haskell的设计者都清楚这一点，这也就是在这些语言里有很多高质量的特性的原因。我希望有一天那些把希曼式实用主义当作理论基础的人会闭嘴，因为事实证明通过学院派设计出来的语言才是解决现实问题的上上之选。

我会一直关注着Scala，我希望能对它了解的更多。但我仍然喜欢Haskell，我从来不会打算放弃它。