梦想风暴

Fluorida是一个Flash的功能测试工具。如果你听说过Selenium，那么可以把Fluorida理解为它对应的Flash版本。

前不久，gigix对我说，他打算做一个Flash的功能测试工具。我说，从语言的角度来说，我不喜欢Action Script，因为它缺乏美感，但我喜欢这个方向，所以，我觉得这件事靠谱。

上周末的Open Party，听了Michael Chen一个关于Rich Client的session，顺便清理了一下关于Rich Client发展的思路。C/S年代，最大的问题在于部署，升级起来很困难，进入到B/S年代，浏览器的广泛存在解决了部署的问题，不过，简单的页面表现力受到了极大的限制，所以，才有Ajax这样技术的流行。把部署和UI表现力一下子都解决了，那么服务器和客户端的威力就可以得到极大的提升。显然，一些公司看到了这方向，比如MS，它们祭出了Silverlight，不过，从目前的状况来看，在这个领域的领跑者无疑是Adobe的Flash。因为几乎所有拥有浏览器的计算机都安装了Flash Player，这是一个压倒性的优势。

最初的Flash，是为设计者而存在的，所以，谈到Flash，人们首先想到的是“炫”，显然，这不是程序员的强项，所以，大多数开发人员并不会和Flash太亲近。Adobe认为Flash应该扮演更重要的角色，比如成为前面提到的新一代C/S结构的领军人物，但是，想做到这一点，必然需要大量开发人员的支持，所以，Adobe不断的让Flash进化着，比如，Action Script从2到3，发生了巨大的变化，用Action Script 3加入了面向对象，用它写程序，感觉和用通常的程序设计语言并无二致。Adobe甚至更近一步推出了Flex，实际上，它就是为开发人员提供的Flash。再在Eclipse的基础上，打造出Flex Builder，所有这一切都是为了亲近开发人员。Adobe AIR的推出，让Adobe在这方面野心显现无疑。可以看到的是，Adobe的脚步并未停止，它还打算让更多的语言运行在Flash上，显然，它们要提供的是一个新的平台，用以抗衡.NET和Java。

站在开发者的角度，我们更关心怎么让自己的开发工作更舒服一点。作为一个ThoughtWorker，没有测试的日子是让人难以忍受的。在之前的一个进行Flash开发项目中，FlexUnit成功填补了Flash开发拼图的单元测试框架这块，而功能测试这块却一直没有很好的做起来，有人尝试过FunFX，但总觉得不爽。

当gigix要写一个Flash集成测试工具的时候，我知道，参与过Selenium开发的他，对于功能测试应该是什么样子，心里应该很有数。事实就是这样，从接口上来看，Fluorida与Selenium如出一辙。

欢迎任何对这个项目感兴趣的人加入，0.0.1意味这个项目中有许多事可做，你可以给出你的建议、意见或是代码，甚至你觉得这个项目的名字不好也可以建议修改。因为这个项目最开始叫做Fluorine，由于与一个Remoting框架相同，gigix把它改成了现在的Fluorida。

俗话教导我们，在家千日好，出门一日难。

最近，因为工作需要，我有一段时间没有在自己办公室，而是在客户现场。按说，在那里，人家对我们客客气气的，尽可能帮助我们解决遇到的问题，而且，一般这种情况下，都是吃得好喝得好的，应该没有什么不舒服的。但是，无论如何，这些日子总是让人感觉很不爽。今天临下班的时候，当大家决定明天都回公司的时候，项目组的同事们几乎欢呼起来。

无论是在西安，还是在北京，甚至是在班加罗尔，只要是在ThoughtWorks的办公室，我都是感觉很放松，因为我是这里的人，在这里，我可以肆无忌惮。到了客户现场，下意识就会绷紧一根弦，无论说什么做什么都要小心翼翼，毕竟在外面，无论你愿意不愿意，你都代表着公司形象，为了不给公司丢脸，做什么都要经过一下大脑。所以，我觉得在客户现场，即便一天什么都不做，都会觉得很累。

其实，我早就知道，在别人的地盘不好玩。离开东软之前的最后一年，我就是被发配到北京的一家公司，进行现场的开发。按理说，那的物质条件比东软要好很多，而且，经常有机会参加那里组织的活动。但那一年，是我最为压抑的一年。在那里，虽然从来没有人故意另眼相待，但我总觉得自己不属于那里，虽然在那里工作将近一年的时间，却从未真正融入那里的圈子。或许，这种心灵上没有归属感坚定了我离开东软的信念吧！

我还听说过另一个关于在外工作的故事。我之前工作的一个部门，派了很多人到美国去做开发。在很多人看来，这些人有机会出国，而且拿着相对较高的补助。而事实是，那些去之前对美国无限向往的家伙，从美国回来之后，都对彻底那里失去了兴趣，甚至闻之色变。当然，这其中有很多故事。

总而言之，在外不如在家好。无论如何，明天要回办公室了！

我的程序人生是从微软的技术起步的。虽然那时已经是Windows的年代，但是目光的局限，让我依然还是在DOS上下了一些功夫。也是因为从DOS出发，后来顺理成章的进入了Windows开发的行列。那时候的我是很努力的，不断的探索着各种各样的技术实现，不断的阅读着各种各样的书刊杂志，也着实记住了一些所谓的技术。不过，有个问题一直困扰着我，我觉得自己记住的只是一些形，而非神，这些形的东西是很容易忘记的，所以，我一直觉得自己并没有真正的理解编程，我甚至一度怀疑适不适合做开发。

真正让我开始觉得心里踏实是以程序员为职业之后。我的职业之路起步于Java，做的是服务器端的开发。跨平台的Java让我的目光不在局限于微软的平台，而服务器端的开发，让我有机会更加关注软件设计本身，而并非花哨的表现形式。随着开发越做越多，我逐渐开始摸索到了一些共性的东西，对自己的程序人生充满了信心。

走不同的路，得到的结果差异会很大。从上面提到的我个人的经历反映出在不同的技术社区内的不同倾向。记得有人说过，微软社区更倾向于探究底层实现，而Java社区更关注设计架构。其实，差别并不只这些，比如，微软的技术社区倾向于追踪新技术，因为几乎差不多每隔几年，微软就要把自己的东西推翻了重来，从DOS到Windows，再到.NET的变化，而Java社区的人则是在一个稳定的基础上不断的发展。微软是为了商业上的发展，所以，它要不断推陈出新，而Java也有变化，比如EJB到without EJB，但决定因素多半是技术上的，而非商业上的。

如我前面所说，微软社区有很多人关注的是一些细节上的实现，所以，造成的结果是他们不得不在茂密的技术丛林中不断摸索，而无暇顾及其它。我们公司内部，有一个技能列表，上面记录着哪些人会哪些东西，比如Java、.NET、Ruby等等，这样方便做项目时进行资源调配。其中有一个有趣的现象，只拥有一项技能的开发人员大多都属于.NET阵营。而Java阵营的人，经过最初的探索，会发现原来自己学到的东西是可以用在很多其它的地方，于是他们的触角开始伸向其它地方，比如JavaEye这个以Java命名的网站上会有很多关于Ruby的讨论、关于函数式编程的讨论、关于Erlang的讨论，这些东西少有会对Java开发本身产生直接的帮助。

如果已经从最初的阶段突围而出，或许，这些差异并不重要，因为我们做事靠的是自己的方法和一些共性的东西。但对于刚开始成为程序员的人来说，并不知道这些差别的存在，一个人的见识有限时，他会认为自己见到的就是整个的世界，就像我刚开始编程那会儿。

其实，我觉得最适合编程起步的应该是Unix开发。这些年里，很多出自贝尔实验室的书，比如《Unix编程环境》、《程序设计实践》、《C程序设计语言》等等都是在探索软件开发本质的书，而Unix的诞生地正是贝尔实验室。Eric Raymond写过一本《Unix编程艺术》，品味之下，便不难发现，许多随着Unix而生的是做事的方法，而这些方法并不是把人限制在Unix这个具体的平台之上，而更多的是一种通用的软件开发理念，拥有了这些理念，即便进入了一个陌生的领域，只要稍加学习，从前的感觉便会回到身边。

起步固然重要，不过，即便起步并非一帆风顺，如果抱有一个开放的心和一个思考的大脑，最终，都会走上同样的开发之路。

休完了春节长假，回来上班了，整个人懒洋洋的，长假结束之后的正常反应。我给自己定下假期基调就是，尽可能让自己的脑子不去想太技术的东西，也算给大脑放一个假，所以，恢复到正常的工作状态，还需要调整一下，呵呵。

假期里，看了《疯狂的程序员》。以前，很爱看这种程序员的故事，尤其刚刚开始学习编程的时候，特别想了解一下别人是怎么一步一步提高的，因为那时候，我并没有体会到真正做个程序员是怎样的感觉，于是，总是希望可以从那些故事里面得到一些值得借鉴的地方。可以说，这种故事中体现的那种激情是鼓励着我不断前进的动力。如今，我做程序员已经开始奔向第六个年头，逐渐有了一个相对清晰的发展方向，做一个程序员的酸甜苦辣也品尝了不少。如今，再看这种程序员拼搏的故事，更多的是为了怀念一下自己的青涩年代。

虽然，彼此的故事不同，但初学编程时那种努力、那种奋进是相同的。还记得刚开始工作的时候，我硬生生的照着协议写出一个SMTP的实现，所有的代码都放到一个文件里面。现在，依稀记得成功把一封邮件发送出去的时候，自己那种激动的心情，用我现在的说法形容，那时候的我，生猛。随着工作经验增多，做事更多的是在找最短路径，如果现在再让我去实现一个SMTP，我笃定是找一个已有的实现。青涩的自己，虽然很笨，却是最有干劲的，也是那时候培养出对程序的激情和热爱，让我可以在程序设计这条路上不断走下去。

刚刚回来，看到一个Da Vince Machine的项目，简而言之，为JVM增加更多的功能，主要是为了支持动态语言的特性。虽然并非这个项目的所有内容都会最终进入JVM，但它确实是一个有益的尝试。

其实，这个项目算不上新项目，关注这个项目领导者John Rose有一段时间了，因为他为在JVM上增加动态语言特性做了很多工作。之所以注意到这个项目，是因为InfoQ的一篇报道。这篇报道中，不仅仅提到了JVM，还提到DLR。

从文章的叙述来看，DLR是建立在CLR之上的。这种做法给我的感觉是，它类似于XRuby的做法，在JVM上自己建立运行时。虽然不是不可以，但这种做法的性能肯定不如直接修改虚拟机，毕竟还差着一个层次。这是一种半调子解决方案，如果是站在平台之外来看，这种方法还不错，但是，作为平台开发者的微软，这么解决问题，就显得有些不靠谱了。也许它只是为了尽快的推向市场，赚些噱头吧！毕竟这种做法可以在尽可能小的影响现有系统的情况下实现。从长远来看，如果DLR能够在未来取得一定进展，如果它还想好的话，它会转向修改虚拟机这条路的。

又是一年，开始工作了！

PreferDesignSkills
InfoQ评论英文版：Prefer Broad Design Skills over Platform Knowledge
InfoQ评论中文般：丰富的设计技能胜过特定于平台的知识

我对程序设计语言有着偏好，所以，我喜欢不断接触各种新语言，喜欢研究语言背后的实现。

最近一段时间，我做的项目用到的几乎都是对我而言的新语言：C#、ActionScript、PHP……，这等价于我要不停的学习自己新语言。

我很享受学习新语言的过程，因为它们会带给我一些不同的体验。每一种语言都有自己不同的适用范围，这一点在学习像ActionScript和PHP这种有很强领域色彩的语言时，体现得尤为明显。运用这些语言写程序的过程中，很容易体会到语言作者在设计时的侧重。

学习新语言，某些情况下也有一些让人难受的地方。经常是，程序出现了语法错误，却瞪眼看不出来，突然意识到错误所在，原来自己用的是熟识语言的语法，不禁莞尔。有时，语言或程序库与自己熟悉的习惯不相一致，经常会被绊住一段时间。

好吧！回到开头，Martin说，设计技能更重要。我想说，设计技能只是很重要的一方面，更多的还是自己做事的方法和习惯。跨越语言时，对此体会会更加深刻。

最近是在写一些PHP代码，我完成一个功能的过程大致如此；弄清楚自己要做的是什么，想一下大概应该如何实现，用PHPUnit编写测试，然后完成功能，运行所有测试，确保这个实现正确以及没有破坏任何已有的东西。把PHP换成其它语言，相信过程是类似的。

如果你有机会像我一样在语言之间穿梭，在度过最初的痛苦期之后，你会发现一切会回到自己熟悉的轨道上。设计、编码、查文档、测试，没有什么不同，所做的一切，都是把自己的想法落实成代码，只不过，由于语言的差别，落实成具体的代码，形式上略有差别而已。

当然，我们不是教条主义者，不只是简单粗暴的知识映射。语言和语言之间是有差别的，所以，学习语言时，我们会注意到语言为我们提供的便利，比如，动态语言的特性，比如，函数的抽象等等，这样我们可以更好更优雅的完成我们的工作。