透明思考

Transparent Thoughts

  1. 教育大众还不如看看电影

    孟岩永远是那么忧国忧民，动不动就要把工作赚钱的事情上升到教育大众的高度。不过我真想问问孟岩，你到底要跟“大众”去沟通什么呢？猛禽把自己对开源的理解简明扼要地整理出来，孟岩你自己睁开眼睛去看看，开动脑筋去想想，你想沟通的“大众”，他们能看懂、想看懂这样的一个blog吗？你就别再骗自己了，这些“大众”连在苏宁电器买台电视机都不知道自己究竟接受了什么合同，你还跟他们说得上什么开源协议？

    但是专业人士一直在和大众沟通，一直在教育大众。对自己的工作缺乏自信吗？我会建议你去看梅里尔·斯特里普《穿普拉达的女王》，好好倾听剧中米兰达的下列台词：

    “你身上这件松垮的蓝色绒线衫，不仅仅是蓝色。它不是宝蓝色，也不是湖蓝色，而是天蓝色。2002年，奥斯卡设计过一系列天蓝色的晚礼服，然后——我猜——是圣罗兰设计出天蓝色的军式夹克衫，之后天蓝色就成了其他8位不同设计师的最爱，然后放入其名下的商店，最后慢慢渗入可悲的CasualCorner，才让你从她们的打折货中淘到。简而言之，那蓝色值几千万和数不尽的心血。滑稽的是，你以为是你选择了这个颜色，让自己远离时尚界，事实却是这屋子里的人帮你从一堆衣服里选了这件绒线衫。”

    所以这是给孟岩以及给我自己和所有ThoughtWorkers的忠告：如果你仍然认为自己是最优秀的专业人士，就不要再徒劳地去谋求与“大众”的对话。你应该做的是影响那些站在经济体系金字塔顶端的人，然后社会的自发力量——感谢资本主义——会在适当的时机以适当的方式将你的意见散布给所有的大众，让他们无知无觉、自觉自愿地接受你、跟随你。

    当然，撒泼骂街、声嘶力竭地与大众对话，这样的角色自有其存在的价值。但，如果你能够做一个最优秀的专业人士，还请你珍惜资源，别放低自己的身段和该有的专业形象。

    •

  2. 信号：Erlang正在靠近中

    很早就有朋友在研究Erlang，但一直认为这只是一场茶杯里的风暴，没有投入精力去关注。

    最近的信号是，PragmaticProgrammers出了一本《Programming Erlang》，同时还有一篇文章介绍。照以往的经验，PragmaticProgrammers从来不做曲高和寡的书。因为这个信号，我决定花一点工夫去了解一下。找到了Erlang China这个讨论组，另一个网站Erlang-China.org不知何故不能访问了。

    •

  3. Ruby on Rails走向企业

    我的标题不是一个问句。因为我已经相当确定，Ruby on Rails走向企业是早晚的事情。

    已经有太多的讨论围绕着“用Rails要快多少多少倍”展开。但是，对于企业级超复杂来说，开发的效率只是一方面。至少还有其他几个方面是必须关注的。

    1. 非功能性需求，也就是软件的-ilities：性能，并发吞吐量，伸缩性，安全，等等。
    2. 完整的生命周期支持：需求，设计，开发，配置管理，质量保证，部署，维护，升级。软件生命周期的各个环节是否有适当的工具和/或最佳实践来覆盖。
    3. 系统整合。与遗留系统是否能够协同工作。这主要体现在两个方面：（1）消息系统；（2）遗留数据库。

    实际上动态语言早已在各种企业IT系统中扮演胶水的角色，一些成熟的组织早已认识到它们并不止是急就章拼凑软件的法宝。动态语言本身的特点使得它们能够相当漂亮地描述各种领域，这正是为何Rails只会在Ruby上出现的原因。

    至于前面提到的、企业级超复杂所看重的三个方面。结合Apache、Mongrel和HAProxy的部署方案已经被证明具有轻松超过任何J2EE应用服务器的性能和吞吐量，无共享架构使其具有完全线性的水平伸缩能力；至于安全性，Unix本身就已经构造了完备而可靠的安全体系。在今年的RailsConf上，我们将看到关于“如何部署高性能企业级Rails应用环境”的产品和最佳实践。

    在生命周期方面，我们已经有了CruiseControl.rb和Capistrano；我们即将看到Mingle的正式亮相，以及基于这些工具的最佳实践。系统整合或许是目前最不明朗的一个领域：我们有ActiveMessaging，我们有复合主键支持，但是很明显这离着“方便的遗留系统整合”还有相当距离。在未来的一年中，这可能是“企业级Rails”最有看头的一个领域。

    总而言之，不难看到，即便是对于企业级超复杂的要求，Ruby和Rails也已经做好了——至少是大部分的——准备。即便客气一点不说“Rails比J2EE还要适合企业使用”这样的话，对于那些愿意承担一定风险来提升IT效率的企业而言，是的，Ruby和Rails整装待发。

    •

  4. Performance Review再次开始，以及相关随想

    一年两度的performance review，现在开始的是2007年第一次。这是我在ThoughtWorks最喜欢的事情之一，因为有那么多人给我提意见，告诉我什么地方做得不够好。

    关于ThoughtWorks的performance review，敏捷中国有一个讨论串值得一看：敏捷开发中的绩效管理。摘录我自己的一段话：

    “大家都明白，指出别人的不足之处是为了帮助别人成长和自我完善，而不是互相打击。就我个人而言，溢美之辞我听得太多了，但除了ThoughtWorkers之外没有别的人能如此直接而准确地指出我的缺点，这些对我帮助非常大——我把上次review收到的批评意见打印出来，过去的半年里一直放在书包里，随时提醒自己。就像我经常说的，一个好的批评者是一笔宝贵的财富。”

    那一次的批评意见，确实是前所未见的尖锐，刚才和Michael（Robbinson，我的sponsor）聊天也说到这件事。另外还说到的是“craftsmanship”和“journeyman”——在《软件工艺》整本书里，我最喜欢的两个词就是“reputation”和“journeyman”。我自己想做的，就是这样一个journeyman，旅行，学习，成长。我最想要的，是和那些master们一道工作，并在那之前做好准备向他们学习。

    每次的performance review，总让我看看自己是不是还在这条路上。迄今为止，走得还算稳。

    •

  5. 歪理斜说：放弃的才是拥有的

    我用上Ubuntu以后，经常劝别人也装。别人经常会说：“那我以前硬盘上积累的那么多东西不是都……”黄亮也拿这个当借口，拒不升级到7.04。而我是一直保持更新的，即使会冒着有时候突然不能启动的风险。

    因为在前后几次重装系统之后，就得出了一个理论：只有放弃过的，才是真正拥有的。

    比如硬盘上那么多东西，似乎觉得总有什么时候用得上，其实只是堆在那里白白占着空间。只有整理过以后，才知道哪些是应该刻盘的，哪些是应该放到网上去的，哪些是应该印出来的，哪些是应该删掉的，以及哪些是真正应该留在硬盘上的。

    还有书。多年前压箱子底的书，搬几次家以后也许还在压箱子底，却还是一次一次不辞辛劳的搬来搬去，心里暗想“说不定哪天就用得上”。其实以这样的概率，需要用的时候再买一本，也比来回搬的力气划算。（当然，书还有装饰房间的作用，所以上述评论只适用于“压箱子底”的书。）

    还有工作经验。还有别的很多。

    总而言之，舍不得放弃就不知道自己拥有，就只是杂乱的一大堆；放弃过，才会拥有真正有价值的。

    •

  6. 歪理斜说：不存在的体系

    InfoQ中文站：统一过程之父叫停新过程

    “作为解决方案，IvarJacobson认为我们应该交流实践，而不是过程，来自团队自己的软件过程的构造块是可以装配的。实践的描述是可以独立描述的，描述可以在过程中共享，因此这个团队与别人的过程上的异同就很容易看出来。”

    以前关注语言学的时候，我有一个理论（这句话将被作为“歪理斜说”系列的标志_）：所谓“语言的体系”是不存在的，存在的只是词汇、以及词汇的用法。譬如说，可能很难找出“英语的语法”这种东西，它是融入到词汇当中的。同样，对于——至少某些——计算机语言，语法本身是不重要的，重要的是其中的词汇可以如何使用。LISP、Smalltalk和Ruby都是这方面的例子。

    还有别的例子。例如MartinFowler说“业务逻辑就是业务没有逻辑”。所谓“业务逻辑的体系”，大抵就是一个你希望套用但基本上一定会套用错的体系。还有敏捷。开大会说“我们要实施敏捷”或者“我们已经实施了敏捷”都是没有意义的，相比之下迭代的周期和有没有持续集成显得更有参考价值。这就是IvarJacobson说的，“过程已经讨论够了，多说点实践吧。”

    *

    关于“歪理斜说”的补充说明

    人的眼睛都是会选择性失明的。我们看见我们想要看见的。换句话说，当你有一个理论时，你总能找到论据来支持它。

    但即便如此，如果你每周都能冒出两三个理论，其中总会有一些比较好玩的。

    这就是“歪理斜说”的由来了。好玩的理论，就算是歪理谬论，扔掉了也怪可惜的，不如就收集起来吧。

    （本来还想说“如果相信，责任自负”之类的话，不过细想想，其实别的文字又何尝不是一样呢？）

    •

  7. Create A Yum Repository

    1. Build yourRPMpackages. Refer to “MaximumRPM”. Assume you put yourRPMpackages in /path/to/RPMS/i386/*.rpm
    2. Create a yum repository.
      • cd /path/to/RPMS/..
      • createrepoRPMS
      • (Now there should be a /path/to/RPMS/repodata directory.)
    3. Publish your repository. I wanna publish it via Apache, so I do following:
      • ln -s /path/to/RPMS /var/www/RPMS
      • (Browse http://localhost/RPMS, there should be “repodata” and “i386”directories.)
    4. Enable your repository in client machine. Edit/etc/yum.conffile as following:
      [main]cachedir=/var/cache/yumdebuglevel=2logfile=/var/log/yum.log[my-repository]name = My Repositorybaseurl=http://localhost/RPMSgpgcheck=0

    Here we go! Invoke “yum list” and you should able to see allRPMpackages you built.

    •

  8. 歪理斜说：优秀的都是病态的

    我有一个理论——好吧，我有很多个理论，其中之一是：一切优秀的，都是病态的。

    实际上这只是同语反复，因为按照定义我们把“与大多数人相同的”称为“正常的”，而出类拔萃的，就像先天不足的一样，是“异常的”，因此是病态的。（ThoughtWorks给应试者所写的代码的最高评价就是“exceptional”。）和白痴一样，天才也是病，只不过表现的形式不同。

    就好像，最优秀的企业对于产品质量有病态的偏执。

    就好像，最优秀的团队对于自己的文化和工作方式有强迫症，一旦偏离就会表现出躁狂症状。

    就好像，最优秀的人会坚持自己的习惯和要做的事情，几年不变。

    一切优秀的，都是病态的。就好像我太太说的，“你们公司的人都不太正常。”

    •

  9. 不稳定，才伟大

    博弈论告诉我们，一群优秀的员工，在公司没有严格监管的情况下自觉地为公司尽力，这是对双方都最有利的一种局面。问题在于，第一，这是一个信任博弈；第二，这是一个非常容易搭便车的博弈。所以，博弈论指出，这样的情景虽然好，但它是不稳定的，因为懈怠的搭便车者会从中获益，并最终导致所有人懈怠，迫使公司不得不严格监管。

    不过，不稳定并不等价于不可能存在。

    广义来说，系统趋于稳定的过程即是熵增加的过程。所以，只要能够不断注入足够多的能量，就可以对抗熵增加，使不稳定的状态得以保持。Google，趋势，腾讯，ThoughtWorks……所有拥有精彩文化的团队，都是因为其中的每一个人不断地注入能量：拒绝懈怠，为团队做多一分贡献，装扮自己的办公室，参与招聘流程以免懈怠者混入……精彩的文化不是从天而降的，是靠一张张贴纸、一个个玩具积累起来、维护起来的。

    精彩的文化总是不稳定的，博弈论的原理已经证明了这一点。所以，更应该珍惜，更应该用心去维护它。

    •

  10. 几种常见的博弈形式

    协调博弈：在这种博弈情景下，局中人都希望别人知道自己将要做什么，最大限度的合作与信息分享将为所有人带来最大利益。典型的例子如交通灯博弈。

    信任博弈：局中人如果互相信任，则会双双获得最大利益；任何一方的怀疑会使双方都遭受损失；就连怀疑对方可能怀疑自己也会招致损失。

    猜硬币博弈：只要猜出对方的意图就会赢（并且让对方输）的博弈，其要点在于隐藏信息。

    斗鸡博弈：比较非理性的人会赢的博弈，如果你不能证明自己比对方更加非理性，可以考虑切断自己的退路。斗鸡博弈中的玩家应该欢迎对手打探自己的情况。

    固定和博弈（或者零和博弈）：一方的收获意味着另一方的损失。在某些时候甚至会成为负和博弈，因为赢的一方也因为不断压迫对方而感到心理不快。

    •