为着理想勇敢前进

《跑跑龟》是个很简单的桌游。基本上接触过桌游的人都玩过吧。看上去《跑跑龟》没啥策略性，输赢也就看运气而已。这么想你就错了，跑跑龟其实是个浅度策略游戏，如果你按以下方式玩，胜率可以达到80%。（注：本文是按“同时到终点时上面的乌龟赢”的规则来写的）

• 中前期没用的牌可以随便出，但有用的牌要留着。所有的牌按有用程度排序如下：
  1. 任意颜色乌龟前进两格
  2. 自己颜色乌龟前进两格
  3. 任意颜色乌龟前进一格
  4. 自己颜色乌龟前进一格
  5. 任意颜色乌龟后退一格
  6. 特定颜色乌龟后退一格
  7. 最后一名乌龟前进两格
  8. 其他颜色乌龟前进两格
  9. 最后一名乌龟前进一格
  10. 其他颜色乌龟前进一格
• 自己颜色乌龟前进两格的牌很宝贵，前期一般不会用。如果前期有人用了前进两格的牌，那么他多半不是这种颜色的乌龟。
• 在走完赛程一半之前，尽量要让自己的乌龟落后
• 过了赛程一半之后，要尽力让自己乌龟踩住别的乌龟而不要被别的乌龟踩住。如果前期你单独落后，那么只要你前进就能踩住别人。如果你被别的乌龟踩住，你就让自己头顶的乌龟前进或后退而把自己露出来。
• 如果对方乌龟移到了只剩最后两步的位置，一定要用自己的乌龟压上去。最好不要单独压上去，而是让自己脚下的乌龟驼着自己压上去。如果没有办法把自己的乌龟压上去，就用后退牌让对方乌龟退回来。
• 轮到你行动时，如果只剩两格了而自己的乌龟在顶上，那么用你先前憋的好牌冲线吧。

作者：Martin Odersky

译者：杨博

原文：Simple or Complicated ? 

哪边更简单？

哪边更简单？ 

哪边更简单？

左边的乐高得宝系列显然比右边的乐高科技系列简单，没错吧？ 
没错，但如果给你个任务让你造一个比较特别的东西，你用哪个系列？可能用得宝系列你也能造出来，但一定比用科技系列别扭。更有可能你需要用到得宝系列中根本没有的积木（比如绳状或胶状积木）。 
现在你该猜中了 :-) Scala更像科技系列而非得宝系列。相比别的语言，Scala能引导我们更简洁的解决问题。Scala还可以进行依赖注入（http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html），而别的语言则需要引入外部配置文件才能做到。 
显然，这意味着Scala每行代码干的活更多，所以你会提出Scala比那些代码冗长的语言更难理解。但有实验证明（http://infoscience.epfl.ch/record/138586）事实并非如此，最终程序员会更适应紧凑的代码而非冗长的代码。 
我希望我能让你相信，“简单还是复杂”的辩论本身就不简单。复杂度是个多维的矢量。在一场讨论中，水友们笔下的“复杂度”往往是指复杂度不同维度上的分量。

我想知道Java程序打日志有多少种方式配置，于是画了一个图：

尼玛Java真是太灵活了！！！！！！！

有C++经验的人往往知道，频繁在堆上分配对象对性能伤害很大。比如这样的代码就不是好代码：

void foo(int[] a) {
 WrappedArray* wrappedArray = new WrappedArray(a);
 wrappedArray->bar();
 delete wrappedArray;
}

然而在JVM（指HotSpot虚拟机）上完全不是这样的。尽管JVM不提供显式在栈上创建对象的功能，但JVM会自动通过逃逸分析找出生命周期在函数范围内的临时对象，然后运行时优化这个函数，把对象创建放到栈上。逃逸分析在JRE7里面已经默认开启了，对临时对象多的代码效果很大。

Scala的隐式类型转换特性很鼓励创建临时对象。标准库中就有大量的隐式转换，会生成许多临时对象，如WrappedArray、StringAdd、WithFilter等。我读标准库的源码时甚至感到他们已经把创建临时对象当成一种优化手段了。

比如C++常见的pimpl模式往往会让用户代码持有一个包装对象的指针，包装对象的内部有一个底层实现对象的指针。这种做法在Scala里面就完全不被主张，而更鼓励长期持有底层对象，而在需要用时再临时包装成对外接口。

Scala的Array对应Java中的数组，功能很少，但Array可以隐式转换为功能全面的ArrayOps，使用ArrayOps上的函数时会生成多个临时对象。试看如下代码：

val myArray = Array("foo", "bar", "baz")
for (element <- myArray if element.contains('a')) { println(element) } 

Scala编译器会把上述代码转换成这样：

val myArray: Array[String] = Array.apply("foo", "bar", "baz")
new (new ArrayOps[String](myArray)).WithFilter(
 new AbstractFunction1[String, Boolean] {
 override def apply(element: String): Boolean = {
 return new StringOps(element).contains('a')
 }
 }).foreach(new AbstractFunction1[String, Unit] {
 override def apply(element: String) {
 println(element)
 }
 }) 

颤抖吧骚年，这一小段代码中居然有五处new，创建了ArrayOps[String]、ArrayOps[String]#WithFilter、AbstractFunction1[String, Boolean]、StringOps、AbstractFunction1[String, Unit]整整五个临时对象。

Scala宁愿创建这么多临时对象也不用pimp模式是因为pimpl模式比直接持有底层对象多保存一个包装对象。如果在容器中保存大量包装对象时，额外的内存开销就会多起来，而pimp模式还会导致每次函数调用也多一次间接寻址的开销。另一方面，只持有底层对象的话，虽然原则上每次使用都会生成临时对象，但是这些临时对象经过JVM的逃逸分析、标量替换和内联优化后是零开销的。

但临时对象的开销取决于JVM的优化，然而JVM要在运行时优化，而且只有频繁运行的代码才会被优化。所以如果一个程序创建很多临时对象，那么刚启动时它的性能会很差，而运行一段时间后会慢慢变好。这也是为什么我们经常会感觉Java程序启动慢的原因之一。

我小学时有一篇课文说讲了个故事，大意是

1. 人的头盖骨很坚硬
2. 生命生长的力量更大，只要把种子塞到头盖骨里面让种子发芽，头盖骨就被撑开了

我觉得这是胡扯嘛，同样是生命生长的力量，女人裹小脚时怎么没听说过撑破裹脚布的？

再说，按课文的意思，头盖骨如此坚硬，生命生长的力量如此大，那么可以推论，头盖骨生长的力量应该是世界上最大的力量了吧。于是印第安人就用自己的头做实验，用木板夹一夹，看看世界上最大的力量能否顶穿木板。

后来他们发现了真相：顶不穿的……

为了纪念他们为科学献身的精神，他们被称为扁头族（Flathead）。

刚看了第五季第14集生活大爆炸，上面提到海地和列支敦斯登参加1936年奥运会的时候，发现两国国旗相同。

于是，为了避免冲突，他们回国以后就开始着手把各自的国徽加到国旗上。

列支敦斯登人画了一个网页，在CSS中设置background-image为原来的国旗，然后找了个PNG格式的列支敦斯登国徽素材，做了个<img>标签把国徽放了进去。最后用谷歌浏览器打开这个网页，按Ctrl+P把网页打印出来，就去参加下一届奥运会了。

海地人也画了一个网页，在CSS中设置background-image为原来的国旗，然后也找了个PNG格式的海地国徽素材，做了个<img>标签把国徽放了进去。最后用Internet Explorer 6打开这个网页，按Ctrl+P把网页打印出来，就去参加下一届奥运会了。

后来他们又在下一届奥运会中碰面了。以下是他们的新国旗：

列支敦斯登的新国旗	海地的新国旗

列支敦斯登看到海地的国旗就笑了：“小样儿，用IE6的吧？”

海地：“靠！这你都知道？”

列支敦斯登两手一摊：“用IE6也就罢了，连科比都不知道就敢参加奥运会？”

在即将迎来我参与的第一个专业店铺 —— 一家开在21楼的桌游吧 —— 开业一周年时，我还只是个刚下海的新手。那就像坐过山车一样令人兴奋。内容全部整合好了，而且游戏看起来很棒。只有一个问题：卫生间使用量超出了预计。

因为大部分卫生间都是被xu-xu和poo-poo用掉的，所以我们和店长一起删减零食供应以节省xu-xu次数。我们缩小零食份量，大量删除饮料，压缩咖啡浓度。有些做法店长可以接受，有些就只能推倒店长才得以实行了。

我们删了一个又一个，经过几天艰苦的努力，我们抵达了某种临界 —— 再也没有什么可以删的了。除非我们砍掉游戏的一些主体内容，不然再没有任何办法可以削减卫生间使用量了。我们精疲力尽地统计了当前的卫生间用量，发现还是多出150人次！

这时，我们这里最有经验的合伙人之一 —— 一个曾在“美好的久远年代”混迹开发领域数年的前辈 —— 决定接手这件事。他把我叫进他的办公室，我心想又要来一场劳心伤神的卫生间争夺战了吧。

可是，他只是走到一个包厢然后指着其中一堵墙，上面写着：

I am the bone of my sword.
Steel is my body, and fire is my blood.
I have created over a thousand blades.
Unknown to death, nor known to life.
Have withstood pain to create many weapons.
Yet, those hands will never hold anything.
So as I pray,
Unlimited Blade Works... 

说，“看到了吗？”然后轻轻一按，推开了这面墙。搞定！

也许是察觉到我眼中的震撼，他向我解释说他在装修的早期阶段封印了这个卫生间。经验告诉他删减xu-xu到预计卫生间之内总是非常重要的，很多桌游吧因此几近失败。所以现在，作为一种常规做法，他总是留一个小卫生间，到真正需要的时候再释放它。

他走出办公室，然后宣布他已经把卫生间使用量减至上限之内，后来他被看作是这个桌游吧的英雄。

尽管被这种野蛮的做法“震惊了”，我还是不得不承认我对他的做法很感兴趣。我还没想到在哪里可以用上这招，但我知道了在有些时候，当你面对障碍时，为了应对困境而事先藏起一些卫生间真的非常有意义。时间和经验带来的改变可真是有趣。

向写程序的黑暗英雄致敬。

今天看了看韩寒和方舟子的论战，这不就是囚徒困境吗？

想象一下可能发生的各种情况：

在网络论战这种囚徒困境中，韩寒和方舟子两人的最优决策都是对抗到底，最终必定导致两败俱伤的结果。

近来发生了一件悲剧。某村村民因为一些合法诉求搞了两次游行示威，游行过程中难免有点暴力行为。官府事后算账，拘留了几个村民，其中一个村民被拘留死了。

如果理解游行示威的意义，这样的悲剧就不会发生了。 游行示威的意义并非向外界展示力量。若要向外界展示力量的话，集体签字或拍集体照就够了。 游行示威的意义在于让参与者产生激情，给参与者洗脑，提高参与者的凝聚力。

然而，游行示威并非洗脑的最佳做法。如果有合法的集体诉求，最佳手段是办法律讲座。法律讲座要低调的办。地点应选择很大的室内场地。人数是多多益善，把能通知到的人都叫上。

法律讲座的要点是讲诉求涉及的相关法条和诉讼流程，引导观众齐声朗读相关条文，就像疯狂英语那样干。 在中华人民共和国境内朗读中华人民共和国的法律，总不能说是颠覆国家安全的行为吧。最好一开场就全场朗读三遍《刑法》第一百零五条第二款，给参与者壮胆。 除此之外。还要讲类似诉求的成功案例（在案例汇编的书上找，书店里面多的是）。讲案例是为了鼓励观众，让观众觉得中国是讲法律的，自己站在法律有利的一方，给观众信心。

做法律讲座之前必须备好课，规划好兴趣曲线。还要事先私下通知少量核心成员当托，以在讲座时调动场上气氛。

讲座结束前，观众整整齐齐排一个方阵，拉出诉求的横幅，拍张照。一定要排整齐有气势，不要搞行为艺术，也不要学毕业照那种摆法。散会后，大家把学到知识用上，遵守法律走法律流程。拍好的照片需要精心设计，配合煽情的文案，写成一篇催人泪下图文并茂的文章，然后放到网上，发动集体疯狂转载。如果在网上流传得当，会给当局一些社会压力，迫使他们遵守法律不耍流氓。

法律讲座既合法，又安全，还提高了集体凝聚力，社会影响力也并不差，比游行示威强多了。连搞传销的人都懂得这个道理，天天办讲座。只有比信传销的傻子还蠢的人才游行示威，还瓜兮兮的跑去公安局登记。

github有Fork功能，Google Code一样有Clone功能。但是github上的项目比Google Code上的项目社区更活跃，Google Code上大家普遍懒得自己Clone、Hack并贡献补丁。为什么？

这是因为二者的界面设计不同。

github一个项目的首页内容主要就三样：仓库地址、源代码目录、README（内容通常是编译指南），你要是不去点右边大大的Fork按钮你都觉得不好意思。

再比较一下导航条：

• github： Code | Network | Pull Requests | Issues | Wiki | Stats & Graphs 
• Google Code： Project Home | Downloads | Wiki | Issues | Source

看到没有，github功能的顺序基本上和Google Code是颠倒的。至于Downloads这种让用户不劳而获的栏目，github才不要有呢。

1. 不灵活。尽管Maven本身已经包罗万象拥有了很多功能，但想要增加点自定义的编译时干的事情，就很麻烦。你必须另外建立一个Maven插件项目，然后用Java写一坨插件代码，最后再到另一个项目中去引用那个插件项目，把插件的执行注入到构建的某个步骤中。哪怕你想干的事情只是简单的一句 echo yyy=$XXX > xxx.ini，你都得写个插件。
2. 依赖的库难以修改。尽管Maven提供了开源的仓库，但你使用他们的方式却是下载二进制包，这实在太不给力，如果你发现别人的东西有bug要修复，那你改了之后那个依赖的库就有两个版本，一个是官方版本，一个是你的修改版本，你就得hack你本地的Maven库缓存让他用你的修改版本，一旦官方版本更新，你就又要蛋疼了。
3. 太慢，除了依赖于网速要下载大量东西以外，本身执行速度也很慢。

• 第一个问题只要不用xml格式做配置文件，而把配置文件格式换成某种图灵完备语言，用这种语言本身作为DSL即可. 比如maven的替代产品buildr、sbt的配置文件格式分别是JRuby、Scala。在buildr、sbt中如果想定制编译时操作，直接用那种语言写就得了。顺便插一句，尽管shell也是图灵完备语言，但太弱，所以make也有类似的问题。
• 第二个问题其实这年头分布式版本管理系统已经解决得很好了。公共仓库和本地缓存应该都换成git或mercurial，不要傻逼兮兮的用什么HTTP。然后仓库里面要放源码，方便用户自己hack. 这区别就好像Debian和Gentoo的区别一样。（PS: 大家用Maven或者Debian的时候，发现别人写的代码有问题，自己改好了还得装孙子求着别人合并回主干啊，有木有有木有！！）（继续PS: 话说遇到Github上的项目就不用装孙子，俺自己Fork出来改改改改改，改好了给你丢个Pull Request，你爱接受不接受！！霸气有木有！！！）
• 第三个问题分为两部分解决。
  1. 网速问题，改用git或mercurial的协议之后就可以大大改善了。
  2. 本身执行速度慢，这是因为Java加载速度太慢，加载类时的文件IO极为可观，此外再加上Java虚拟机JIT还有些开销。尽管对一个长久运行的进程来说启动慢一点没有关系，但对于构建管理这种一个进程只存活几秒钟的应用来说，启动慢就不能忍了。其实如果要用JVM语言做构建系统，不应该每次执行都启动一个Java进程，而应该做成守护进程，每次执行只启动一个客户端来戳一下守护进程。守护进程和客户端进程之间通讯协议用ssh就好了嘛。 守护进程用Scala或者Java编写，客户端就不用写了，用openssh就行。人家openssh是C写的，启动速度超快。

用Java打log时，最不爽的一点就是即使你把log禁用了，只要打log的那行代码还在，每次执行到那一行还是有开销！尼玛Java没有宏啊，不能像C++那样做个编译选项不输出log时就直接跳过嘛。况且就算Java有宏，搞Java那帮道貌暗忍的人渣们也不会用的，他们只用XML和Annotation 来配置，感受不到编译选项带来的爱。Scala就有个-Xelide-below的编译选项可以排除掉不需要的函数调用，直接被搞Lift的混蛋们无视了，照样用着天杀的slf4j.

那么用slf4j打log到底有多大开销呢？这取决于slf4j的后端，不管用什么后端，真正输出log是需要IO的，一般都要几十上百微妙，也就是几万或者几十万纳秒，这部分开销是省不了的。我刚才抱怨的是那些被过滤掉的log，这些log的开销根据参数的复杂程度，要消耗从几个纳秒到上百个纳秒不等。

纳秒什么的最讨厌了，上百个纳秒，听起来好多！我一个纳秒都不想浪费！于是我就写了个pico-logger，pico-logger对org.slf4j.Logger包装了一下，但用pico-logger比直接用org.slf4j.Logger快得多。

如果一条log没被过滤掉，需要实际IO输出，用pico-logger和用slf4j一样快。但是slf4j打一条复杂log时，即使被过滤掉了，也需要消耗上百纳秒，而pico-logger过滤掉log时一纳秒都不浪费。无论多复杂的log，pico-logger在JVM优化后执行时间都不超过2个时钟周期，在我2.1GHz的CPU上只要952皮秒，一纳秒都不到。如果传给pico-logger的参数是没有额外变量的字符串字面量，执行时间为零。零执行时间的意思是你在任何深层循环输出log，只要一禁用掉，都对性能完全没有影响。

以下是在Scala中PicoLogger的用法：

object Foo extends PicoLogger(org.slf4j.LoggerFactory.getLogger(classOf[Foo]))
{
 def foo() {
 // 用PicoLogger，当trace级别被禁用时，零执行时间
 trace("string literal")
 
 // 用org.slf4j.Logger，当trace级别被禁用时，消耗4纳秒左右。不同后端性能稍有差异。
 logger.trace("string literal")
 }

 def bar(p1: Int, p2: Double, p3: Long, p4: Byte, p5: Boolean) {
 // 用PicoLogger，当trace级别被禁用时，2个时钟周期，在2GHz以上的CPU时不到1纳秒
 trace("p1=" + p1 + ", p2=" + p2 + ", p3=" + p3 + ", p4=" + p4 + ", p5=" + p5)
 
 // 用org.slf4j.Logger，当trace级别被禁用时，消耗约100纳秒
 logger.trace("p1={},p2={},p3={},p4={},p5={}", Array(p1, p2, p3, p4, p5))
 }
}

顺便做了个benchmark，对比了一下slf4j和pico-logger的性能。在下列表格中，每一项的单位是时钟周期，即以java -server方式运行，并经过充分优化后执行需要消耗的CPU时钟周期。在我2.1GHz的CPU上，每个时钟周期是0.476纳秒，即476皮秒。与slf4j中用格式化字符串的代码对应的pico-logger用例是拼接字符串。

slf4j整数参数会变慢，是因为slf4j需要为非引用的参数装箱。每次装箱就要消耗大约20个时钟周期，因为装箱涉及内存分配，所以每次装箱消耗的时钟周期数不等。上述表格中的数字都是取最好的结果，实际上平均成绩还会比这个最好成绩消耗更多的CPU时间。字符串字面量下面的“0”表示如果输出的这条log会被过滤掉，那么哪怕连写10遍，JVM优化后都是直接跳过这些代码的压根不作任何判断。