8/25/2008
作为一个工程师，不能不佩服老谋子。闭幕式的一大难点就是全部资源都被开幕式挤占。团体操肯定还是要的，不仅场面还得宏大，动作也还得上难度。然而，演员并没有多少时间来排练，也缺乏场地——鸟巢要用于比赛，没什么空闲供排练闭幕式之用了。缺乏排练的后果大家今晚也看见了，连个同心圆圈都拉不圆，更复杂的动作就不用想了。在这样的硬约束条件下，老谋子是怎么解决问题的呢？
老谋子的对策就是把问题变换一下形式，向三维空间要场地。闭幕式团体操中一个重要的舞台就是那座巴别塔，高大，醒目，但是水平面积并不大，完全可以在一个小得多的场地上架起来。因此，在北京各主要场馆全部用于各项赛事的情况下，老谋子可以找一个不咋地的小地方把这座塔架起来，复杂的团体操动作全在塔上完成。等到闭幕式上，再把这座塔架一遍，塔上进行各项复杂动作，塔下则作为绿叶——找一些训练不足的演员重复一些简单的动作，队形也不用讲究，圆圈阵就好，只要把空地全部占满就行。应该说，老谋子的对策是成功的，巴别塔撑住了一个宏大的场面。
8/7/2008
在上海博物馆看青铜器的时候，对上面的金文发生了兴趣。比如说，我注意到叠字很早就出现了，例如“子子孙孙”、“世世子孙”、“穆穆翼翼”。更让我惊讶的是，叠字的简写符号々我一直以为是不规范汉字，没想到却在老祖宗传下来的青铜器上发现了。
另外一个有意思的事情就是合体字，就是把两个汉字合写成一个方块字，例如“贝[廿朋]”和“[武王]”。可惜当时还没有拿到相机，iPhone在馆内表现不佳，就没有拍下来。
7/6/2008
女人为什么啰唆？为什么这么嗲？最近看到一种
解释：
那么，除了吃奶之外，为了开发基因里的各种可能性，母亲还该做些什么呢？举个例子。八十年代中期，语言学家调查了英国、瑞典和俄国的“妈妈语” （Motherese），发现三国的女人都会用很夸张的声调对婴儿发出Ａ、Ｉ、Ｏ三个基本元音，使婴儿的听力有一个较大的“元音三角区”，从而将来能学会辨别较多的语音。儿童的学习是分阶段的，心理学和语言学称之为“学习窗口”（learning windows）。“元音三角区”的形成窗口在出生至六个月之内。这段时间内，母亲（和别的女性）向婴儿所表达的爱声，对婴儿是否能在一岁左右开始说话，有很重要的影响——而语言能力又是人生竞争的决定性能力。
兄弟十二、三岁开始扮酷装男人时，见到女同学抱着亲戚家的孩子，摇头晃辫子地叫，“宝宝啊（Ａ）——，笑笑呢（Ｉ）——，好看喔（Ｏ）——”，觉得很可笑，女孩子就是这样嗲溜溜的没出息。语言学课上听了教授的讲解，却不由额手称庆，庆幸自己出生在乡下大家庭，母亲之外，村子里还有一大帮婶子嫂子堂姐姐。
看来，女人的啰唆和嗲都是自然选择的产物。当然，性选择对于嗲很可能也有贡献。
2/26/2008
Allen54
noted a followup to yesterday's story about Pakistan's decision to
block YouTube. He notes that "The telecom company that carries most of
Pakistan's traffic, PCCW, has found it necessary to shut Pakistan off
from the Internet while they filter out the malicious routes that a
Pakistani ISP, PieNet, announced earlier today. Evidently PieNet took
this step to enforce a decree from the Pakistani government that ISP's
must block access to YouTube because it was a source of blasphemous
content. YouTube has announced more granular routes so that at least in
the US they supercede the routes announced by PieNet. The rest of the
world is still struggling."
Read more of this story11/15/2007
前天晚上熬到四点钟，居然还被同事堵在网上问了一道数学题，据说是从他的项目中抽象出来的。（我也不知道他做的什么项目...）
问题：
有 N 个盒子和 C 个小球，每个盒子中可装小球的数目无限制。现将所有小球分别独立地随机装入盒中，问装有小球的盒子数其数学期望值是多少？
计算：
N 个盒子、C 个小球的情形可自 N 个盒子、C-1 个小球的情形推出，得到概率分布的递推公式：
P(N, C, x) = P(N, C-1, x) * x/N + P(N, C-1, x-1) * (N-x+1)/N
不必计算概率分布，可直接自上式得到数学期望的递推公式：
E(N, C) = E(N, C-1) * (N-1)/N + 1 + P(N, C-1)(0)
纳入边界条件，进而得到：
E(N, C) = [N^C - (N-1)^C] / N^(C-1)
特例分析：
当 N >> C 时，有 E(N, C) = C
当 N << C 时，有 E(N, C) = N
当 N >> 1，C/N -> k (>0) 时，有 E(N, C) = N(1 - exp(-k))
宝刀不老，hiahia！
9/15/2007
You may stop here if you don't have an iPhone.
Updated on Sept 14, 2007.
==============================================================================
Versions:
- Mac OS X 10.4.10
- iTunes 7.4.1
- Firmware 1.0.2
- Installer.app 3.1 (2.63?) http://iphone.nullriver.com/beta/
Steps:
- Change SIM card
- Restore & upgrade firmware using iTunes
- Installer.app
- Activation: youtubescript
- Install OpenSSH and change root password (default: dottie)
Must-haves:
- Summer Board
- iPhone Apper: turn URLs into standalone apps
Development:
- Heavenly (OS image)
- Copy from iPhone?
- Or decrypt:
- Use vfdecrypt
- Fnd decryption key with the ramdisk dmg:
strings 009-7662-6.dmg | grep "^[0-9a-fA-F]*$"
Look at the strings that come out. One of them is very long.
- Toolchain
Makefile header:
CC=/usr/local/arm-apple-darwin/bin/gcc
CXX=/usr/local/arm-apple-darwin/bin/g++
CFLAGS=-fsigned-char
LDFLAGS=-Wl,-syslibroot,/usr/local/arm-apple-darwin/heavenly -lobjc -ObjC -framework CoreFoundation -framework Foundation -framework UIKit -framework LayerKit -framework CoreGraphics -framework GraphicsServices -framework Celestial -framework MusicLibrary
LD=$(CC)
Tricks:
- icon order: DisplayOrder.plist
9/7/2007
选择多多是好事还是坏事？这个问题并不容易回答。用户自可以选择他们喜欢的操作系统，但是对于开发者来说，要让一个图形界面的软件运行在不同的操作系统之上，着实是一项艰巨的任务。事实上，即使是将目标客户局限在Unix一族，跨平台开发也非易事，何况还要扯上Windows、Mac乃至于各种嵌入式操作系统呢。
--------------------------------------------------------------------------
如何面对这一挑战？Java的回答是虚拟机，一次编译，到处运行。乍看上去这倒是一颗解决跨平台开发问题的银弹。然而，正如C++之父一针见血地指出的那样，"Java不是平台无关的，Java本身便是平台"——而且是一个缓慢、丑陋的平台。这后半句是我说的。在我念书那会儿，一个软件是不是用Java语言写的一眼就能够看出来：但凡用Java开发的图形界面程序，总免不了蜗牛般的启动速度，闪烁的硬盘灯，特别是标志性的简陋界面。几年过去，今天的Java无论在速度上还是在Look & Feel上都大有改观，但毕竟长江后浪推前浪，它在跨平台图形界面软件开发领域的机会恐怕已经过去了。
当我还在为我的硕士学位课题搜寻适当的开发工具时，我非常讨厌Java。速度问题尚在其次，主要是它的图形界面实在是太难看了，当时也就是凑合着能用的程度。Java程序在所有的操作系统上看起来都一个样，这种思路不能说错，但你应该向Mac看齐啊，怎么能比Solaris还不如呢。
其实我也明白，我的指责未必有道理。美不美完全是个人的主观感受，也许对于Java的铁杆粉丝来说，Java程序的界面才是最美最美的。这就带出了另外一种思路：既然大家口味各有不同，与其强求一致，何不顺应各人的习惯？让Windows用户看到Windows风格的界面，而让Mac用户看到Mac风格的界面，不是挺好吗？换言之，不必像Java那样reinvent the wheel，重新设计出一整套图形界面组件，简单地封装一下各个操作系统已有的组件就好。应该说选择走这一路线的有很多。应用软件中有Firefox、Open Office等，我相信Adobe Reader、Real Player等也都是这样做的。纯粹的开发库也颇不少，wxWidgets（当时叫wxWindows）可谓是其间的佼佼者，它也成为我硕士学位课题的选择。
我为什么选择wxWidgets？从最终用户的角度来看，它生成的图形界面完全是Native的，没有任何不适应之处，这是它胜过Java的地方。（微软在我结题之前推出了Windows XP，我很容易就鼓捣出了Windows XP新风格的图形界面，将屏幕截图收入学位论文。要是我一开始选择了Java什么的，我就不知道该怎么办了。）从开发者的角度来看，它的使用相当简洁、方便（事实上它用起来很像MFC），文档齐备，而且作为一个开源项目，它的开发与维护一直相当活跃，各式组件极大丰富并持续增加，很容易就搭出相当漂亮的界面，这是它胜过其余走Native路线的开发库的地方。wxWidgets主要支持C++，口号是一次编写，到处编译、运行；等我学会Python，才注意到原来它也支持用Python、Perl等脚本语言开发，这一来连编译这一步都省掉了，开发起来比Java还快，这是后话。
然而Native路线也有其问题。还在我刚开始留意wxWidgets的时候，我就看到有人批评说，走Native路线，就需要处理每一种平台上每一种组件的每一个bug。我当时并未将这一警告放在心上，几年下来，越来越觉得这是真知灼见。比如我用wxPython（Python + wxWidgets）写了一个日记程序，就遇到无数稀奇古怪的问题。最近解决的一个问题是这样的：我发现在MaxOSX平台上运行时，程序某窗口上大部分组件都不能用鼠标点击，查了差不多两个钟头，最后发现是某wxWidgets组件在MacOSX上对Z-Order有严格要求，而这个问题在Windows平台上就不存在。这样的事情多遇上几次，很能陶冶情操。
--------------------------------------------------------------------------
就在我琢磨如何开发跨平台图形界面软件的时候，问题本身却正在发生变化。十几年来，Netscape鼓吹的网络计算机失败了，Sun鼓吹的Java Applet失败了，微软鼓吹的ActiveX也失败了，然而，就在一夜之间，AJAX诞生了，Web 2.0的时代到来了。从技术上讲，Google于2004年愚人节推出的Gmail令人信服地证明了Web应用不是什么二等公民，它完全可以与桌面软件同样精彩。后知后觉的我，还在三台机器之间将自己的日记倒来倒去，而比我更年轻的程序员们已经专注于开发运行在浏览器之内的软件了。现在，重要的是跨浏览器（Internet Explorer、Firefox、Opera或Safari），而不再是跨操作系统（Windows、Mac或Linux）。而Google的GWT——AJAX开发的利器，也随之成为最热门的开发工具。
今天，我通过浏览器收发邮件，通过浏览器排定日程，通过浏览器在线聊天，通过浏览器编辑文档，通过浏览器购物订座......随之而来的，是桌面软件的作用日益淡化。短短几年之前，浏览器还不过是诸多桌面软件之一，而今却变得比操作系统还要重要；而桌面软件也都争先恐后地和因特网攀上亲戚——即使不支持网络存储、发表或同步什么的，至少也该检查一下更新吧。仿佛就在昨天，浏览器还在一个组件一个组件地模拟着桌面软件的界面；而今天，继Java不成功的尝试之后，万维网接过火炬，业已确立起一整套统一的丰富的图形界面标准，成为越来越多的桌面软件参考乃至遵循的对象......Adobe推出了Air，允许开发者使用AJAX、Flash等Web技术来开发桌面软件。这个世界颠倒过来了。
6/20/2007
最近老有同事抱怨被蚊子骚扰，然后我就捂着嘴偷笑......以下据说是最新的科研成果：
能为蚊子带来丰富胆固醇和维生素B的人最受蚊子青睐......以下人士就是蚊子最喜欢的人：肺活量大的人、汗腺发达经常流汗的人、肥胖者、孕妇及月经期间的女性、做完激烈运动的人、白天穿着深色衣服的人、赤脚穿鞋的人、化妆后“香气四溢”的女性。
http://science.solidot.org/article.pl?sid=07/06/13/1525212
5/4/2007
Below are my comments on Philips Photo Digital Display model 7FF1M4/37 to be published on Amazon:
Buggy. Don't buy it.
I bought one and got surprised that it didn't work well. After days of testing I found that I can only store up to 1023 photos in my memory stick. If I go beyond that limit, the frame goes blank at exactly the 8th photo when playing sequentially in slides mode. It also goes blank when playing randomly in slides mode, but then the timing of going blank is also random, and it is impossible to tell which photo triggers the bug.
I found a workaround: when turning on the frame, switch it to thumbnail mode and switch it back to slides mode. Then everything goes smoothly. Or let me say so far so good. I am still doing more tests.
I believe it is a software bug. I would like to see Philips releases a new firmware and fixes it. Hey Philips, I trusted you and your brand. Don't let me down again.
(I use a 256M Sony Memory Stick Pro Duo with its Memory Stick adapter. I upgraded the firmware to 7FF1B207.)
5/18/2006
空门是一个奇怪的家伙，写小说、演话剧、穿旱冰鞋爬楼梯、拒M$的Offer。几年没见，没曾想这家伙还在鼓捣数学，他对我谈起他的伟大梦想，眼中闪耀着晶莹的泪光；顺便提醒大家一句，过十字路口时不要和他同行，他喜欢斜穿。像他这样一个人，无论是如愿以偿拿到图灵奖，还是被违背本人意愿地送到安定医院，我都不会吃惊。
为民间数学家服务
应空门同学的要求，发表本文，读者千万不要寻根问底，这家伙是个精力过剩的民间数学家。
-------------------------------------------------------------
空门声称完成了一份对计算机语言、软件工程意义深远的手稿：
手稿中利用拓扑学的理论对计算机程序进行建模和分析，用一种直观地方式展示了纯函数式语言和面向对象的编程模型之前的区别，以及它们各自的优点与缺点。手稿从拓扑学的基本原理出发，提出了
一种全新的基于因果性的计算模型，它能够在很大程度上区分算法和数据，并且能够直观地展示出来。这套计算模型中引入了一些高层次的类型系统和安全机制，使它的表达能力和安全性超越了流行的基于面向对象的计算模型。
这份手稿中的理论可以用于实现高层次的开发工具，实现软件的设计的可视化和自动化。这套工具允许将手稿中提到的计算模型具体化，对应到现有的计算机语言，例如 C、C++和Java，因此具有很强的实用性。同时，这套工具允许对实现（例如 C 代码）和设计进行验证，使得自顶向下的软件过程得到彻底地实施。
作者正在将这份手稿的内容形式化，并设计相关的原型和工具，不愿意将晦涩的手稿公开。此外，为了产业化过程中投资人的商业利益，作者也不便于将手稿中的内容公开。作者为了证明自己完成了这
些工作，只能将手稿打包加密后保存在安全的媒介中，并公开相应的数字签名。
最后，作者必须感谢相信自己并公开本申明和数字签名的朋友。
--------------------------------------------------------------
Nullgate claimed that he has a manuscript which could be a great impact to the theory and practice of both programming languages and software engineering. It follows:
The manuscript uses topology as a primary tool to analyze and model the computer program. The inuitive approach shows the essential difference between pure functional methodology and object oriented methodology. The manuscript follows the principle of topology and proposes a new computing model based on causal relations, which could distinguish algorithm from data. There are high level type systems and soundness in the new computing model, making it extremely expressive and robust, which is seldom possible in prevailing object-oriented programming.
The theory in the manuscript can be utilized as methodology and implemented as software developing tool, visualizing and automating the software process. The practice could be language neutral, which means designers can translate high level designs into prevailing languages like C, C++ and Java. The theory also
makes the verification between design and implementation possible, which is a great help to top-down software process.
The author is formalizing the manuscript into a better format, solving the trivial problems and implementing the prototype. So the author do not intent to disclose the content of this manuscript. Neverthless, in order to protect the interest of the future investors, the author is not allowed to disclose the manuscript. The author decides to unleash the digital digest of the manuscript, and store the encrypted manuscript in the secured media. Thus the author could prove he have already finished this manuscript.
The author is obligated to those who believed in him and published this announcement and the related digital digest.
-----------------------------------------------------------------
数字签名使用 GNU Crypto (Java) 实现，其源代码和可执行文件请向空门索取，他的信箱是 nullgate [at] gmail . com
nullgate.jar [original]
Length = 3023025
SHA160 = FD642629D6A79524C56B8C1BB79C6FA5354CCB
MD-5 = 14AE674F52BEDCC8AE4B52A44EE71
nullgate.jar.rar [encrypted]
Length = 3023124
SHA160 = 472159758F4FA2CB553B41F137452971EC5B257
MD-5 = 5967A235EA6955DB87D2FEE064FA182B
3/7/2006
- 不支持用script直接重写script，即，这样的代码不能正常工作：
document.write("<script>...</script>");
- substr()不支持负数作参数，即，s.substr(-2)将返回s本身。
- 利用<a>嵌套<span>来做tooltip时，必须设置text-decoration:none，莫名其妙。
如果大家都用Firefox，这个世界将会多么美好啊！
1/17/2006
看到MorningFool在
预测未来，我决定反其道而行之，发发思古之幽情。今天来谈谈PWC的故事。
我是在做硕士课题时发现PWC (Philips WebCam)的，它是Linux上的USB摄像头驱动，支持几乎所有基于Philips技术的USB摄像头，换言之，也就是几乎所有USB摄像头。其作者是荷兰人Nemosoft Unv，这显然是网名。PWC模块一经推出即大受欢迎，很快就进入Linux kernel。
可惜好景不长，在2002年，作者与Alan Cox发生激烈的争吵。事情是这样的：作者在PWC中加入了一些通用图像处理函数，比如裁剪、缩放等等。在AC看来，这都是user space的工作，不应该放在驱动里，要知道驱动可是要工作在kernel space的，因此将其全部删除，事先并未通知作者（这是符合GPL的）。作者非常恼火，愤怒之下甚至威胁要中止这一项目。然而AC到底是Linux大佬，虽然说话温和，给作者留足了面子，但一步也不退让。作者牢骚发尽，终究无可奈何，一场风波不了了之。
两年后，又一场风暴骤起，终于宣判了PWC的死刑。原来，PWC还有一孪生兄弟PWCX，前者是GPL的，后者则包含着Philips公司的技术机密，受作者与Philips公司签订的保密协议保护，因此仅以二进制形式发布。PWC可以单独工作，但只能提供低分辨率、低帧率的视频采集能力，需要加载PWCX才能提供高分辨率、高帧率能力。为使两模块能协同工作，PWC提供了一套API接口（hook），专供PWCX使用。
PWC/PWCX的架构一直是这个样子的，这在2002年没有问题，但在2004年就成了问题。随着Linux在商业化道路上日益成功，越来越多的公司为自己的硬件设备提供Linux驱动，然而它们常常封闭源代码而仅提供二进制版本，这就违背了自由软件的理念，在Linux kernel开发社区中激起越来越强烈的反弹。在这样的背景下，PWC的hook机制是否合法，是否是以这样的方式帮助PWCX绕过GPL，就突然成为一个有争议的问题。负责USB部分的Linux kernel开发者断然删除了PWC的hook，这一次，又没有和作者商量。
作者宣布自己受够了。他称这一次的事件是“压垮骆驼的最后一根稻草”，并终于将以往的威胁变为现实，宣布中止对此模块的支持，同时要求将其从Linux kernel删除，一时之间掀起轩然大波。对此，Linus亲自作出反应，他敦促Linux kernel开发者都回去干正事去，别陪着这个“稻草人”灌水；既然作者自己要求，那就将PWC从kernel中拿掉呗。硝烟散尽，没有赢家，令人扼腕叹息。
其实，如果能将PWCX开源，整场争端就都烟消云散了。那么，PWCX为什么不能开源呢，Philips公司到底有何技术机密需要隐藏？从一开始就有人怀疑所谓技术机密完全是Philips公司的虚张声势，这个怀疑很快就得到证实。有个项目需要优良的信息熵发生器，其开发者灵机一动，利用视频采集作为熵源。让人大跌眼镜的是，经他试验，用PWC/PWCX采集的高分辨率、高帧率的视频与仅用PWC采集的低分辨率、低帧率的视频相比，其信息熵不仅没有增加，反而略有下降。结论如何，不言自明。挑起一番混战、牵动这么多根神经的、Philips公司精心维护的所谓技术机密，原来就是这样一个笑话，一场骗局！
12/23/2005
OK，我的Code Jam之旅也走到了尽头，现在是盘点时间。最大的教训，就是冰箱里一定得备酒，否则悲伤的时刻无可逃避。最大的经验，就是多交几个铁杆的朋友，焦虑时有人支持，失意时有人安慰。
一开始听到Code Jam的时候并没当真，毕竟不是自己的强项。过了几日，经不住
有人撺掇，这才下水。既然要作贼，总不能马马虎虎，刀片之类称手的工具总得事先齐备，还得多练练二指禅。某些人比赛比到一半出去和邻居吵架，就属于准备做得不到家。我可是花了好几个晚上和周末的时间来琢磨这些事情，慢慢地还品出了味道，以往敬而远之的动态规划与图论，现在看来似乎也没那么难了。
一开始练习，真的是不习惯。做了这么多年的实际项目，看到TopCoder高手们在两分半钟之内草草写出的丑陋的代码，恶心得差点儿而没吐出来。不过，既然要加入这场游戏，就不能不接受它的游戏规则，而且还要喜欢它。“欲练神功，挥刀自宫”，诚哉斯言。
控制住反胃之后，我慢慢也琢磨出一些门道。一个Professional要玩TopCoder，需要注意以下四点：第一，不必考虑代码的结构。第二，不必考虑代码的可读性。第三，对于前项条件可作极强的假设（Design by Contract？据我所知，这是一个颇有争议的观点）。第四，不必优化平均性能，只需考虑最坏情况。
闲话少说，还是来盘点实际比赛的进程吧。12月12日的资格赛，最考验人的地方不在于编程能力，而在于联网条件。我虽然有心理准备，但横竖登不上服务器，心里还是暗暗吃惊，这比赛的组织工作有很多可以改进的地方呢。索性等到转钟，我琢磨着学校里的孩子们都睡下了，这才正式登录，虽然不是很流畅，至少也没有断线。准备了这么久的动态规划，莫了却与wordpath擦肩而过，遭遇了PlayCards。我用广度优先搞定，自己还在傻乐呢，没想到超时判负。关键倒不在于深度优先还是广度优先，而在于我以整手牌（矩阵）作为状态，把系统给压趴下了，要知道成功人士可都是一张张地算点数的。最终结果，我在1000分的满分中才拿到180。好在这次中国赛事与TopCoder的国际比赛相比，其水平似乎相距甚远，100分即可过关。
资格赛之后，除了继续苦练算法，还做了两件事情：第一，测量了一下TopCoder服务器的性能，发现其在两秒钟之内可作4*10^9次定/浮点乘/除法，这一数据可作为以后比赛中估计计算复杂度的参照。第二，给组委会写信，抱怨网络联不上，他们回信建议我换个地方上网-_-！
周末赶上TopCoder的单轮比赛，我熬到凌晨一两点参乎了一把，长长经验值嘛。平日里没事的时候，周末晚上怎么都睡不着，现在好容易来点儿正事，我却困得不行，人怎么这么贱呢。前两道小题我倒是轻松搞定，就是在第三道大题上折了牙齿。事后诸葛亮，应该用二分法，但我当时的第一个思路就是集合演算，结果最后死人地推不出来，毕竟不是阿基米德呀。
第一轮淘汰赛是在星期一，500进250。要当二百五还不简单么，刨掉联不上网或者中途断线的，刨掉作弊的，刨掉被赛事赞助商的Offer砸死的，最后拿到正分也就三百人出头，只要稍微有那么点儿底子，随便拿点儿分数也就过关了。我第三道大题没做出来，就靠着两道小题和两次成功的挑战，居然也排到45，这极大地刺激了我的野心。
比赛到了这里，我注意到两点：第一，除了资格赛中出了一个wordpath，其它题目都没用到什么现成的复杂算法（贪婪不算），考的就是分析能力。看来我的动态规划与图论都是白看了，但我还不能不继续准备，谁知道下一关会遇到什么，再说我也不能将自己的眼光局限在这一场赛事。第二，我感到前两道小题都不在话下，就是对最后一道大题有些罩不住，这个关卡不攻下来，命运就不在自己的掌握。
第二轮淘汰赛就在今晚，250进50，大屠杀，过了关就有iPod nano发。和往常一样，第一题轻松搞定。可是第二题却让我碰得头破血流，这完全在我的意料之外，一时间也有些乱了方寸。我甚至考虑是不是放弃这题算了，赶紧进到下一题。但我很快得出结论，只有三题全对才能见到可爱的iPod nano，这一题不啃下来，肯定会被淘汰，事实也确实如此。于是我咬紧牙关，花了四五十分钟的时间，总算把这题给解了出来，得到了这一题上也许是全场最低的分数。
这个时候，我意识到自己已经是一个死人，而死人是不会紧张的。我平静地打开最后一道大题，此时时限只剩下十分钟多一点儿。这一次，我又大吃一惊：这道题目很简单。我又看到了一线曙光！我的速度也许从来没有这么快过；可是时间啊，时间，你永远是我的敌人。我在读秒声中测了两个用例，实在来不及继续测下去，在倒计时数到最后两秒时按下了提交键。当最后的钟声敲响时，我甚至不知道自己的提交有没有成功。
我的提交竟然成功了，这真是一个奇迹，连同一房间的赛手们也觉得不可思议。我趁着休息时间执行完余下的几个用例，居然完全正确，其后有人试图挑战，也落得个自讨没趣，这是又一个奇迹。一时间，我甚至有些侥幸甚至妄想。可是奇迹发生一次就已经够多，我们不能指望它持续发生。再一次地，前两道小题都pass了，第三道大题则在第一个系统测试用例就卡住了——计算最大公约数时，我没有想到辗转相除法，在时间恐慌之中也没有力量去做素数表，只能硬着头皮穷举，结果超时判负。但是在这一题上我已经做得足够好了，这差不多已经是几轮比赛中我最神勇的一次发挥；如果说它的结果还不能令人满意，最终还是没能通过系统测试，那也是李代桃僵。
侠被追兵堵进了死胡同，在嘈杂的呐喊与摇曳的火把中，他纵身一跃，竟飞上十丈高的屋脊，甚至连追兵也看得呆了，禁不住叫一声好；可是话音未落，大侠摇晃两下，又掉了下来。故事的结局就是这样。
9/24/2005
Do more with less.
——微软北京TechEd 2005主题演讲
前两天Sun轰轰烈烈地搞了一个Java大会，公司里很多Java程序员都跑去参加，令我眼红不已，找到组织的感觉真的是太好了。正巧Microsoft也要发英雄帖开神仙会，俺于是也硬着头皮跑过去，重在参乎嘛。给微软的朋友们挂了一圈电话，却忘了在我是凑热闹，在他们却是冷冰冰的工作，谁有闲心陪我玩来着。在Intel的展台前喝了杯蓝色的甜酒，我问侍者是否是Intel的正式员工，得到否定的答复。Microsoft的主题演讲是以精彩的棍棒表演拉开帷幕的，一下子就将场面气氛推向最高潮，不知道这精彩的创意是否出自我认识的人，又不知那些少林和尚是否是微软工程师？
栾跃的项目管理的课程与讨论耗去我整个下午的时间。我感觉他对微软的自我评价过高，不过胜利者是不受谴责的。另外，他似乎没有听说过我现今所在的这家公司，这让我大为惊讶，我们好歹也是一家大公司呀，你不至于这么孤陋寡闻吧。再说我之前邂逅过的几个北美归来的华人都知道我们公司的名号：“知道，当然知道，怎么会不知道，我想忘都忘不掉——我现在还捏着你们公司的股票呢。”
说点正经的。总的来说，微软的产品生命周期管理与项目开发流程同我们公司大同小异，看来这一套应该是传统项目管理的基本实践。最重要的区别在于项目管理工作的重要程度和与研发工作的结合。在微软，开发团队总是小型的（不超过五十人），团队中包括项目管理、开发与测试三个小组。以栾跃工作过的嵌入式操作系统（WinCE？）团队为例，整个团队一共四十人，其中项目管理小组八人，其余开发与测试各半。在我们公司，开发团队与测试团队是截然分开的，这与我们“软硬兼施”的产品线有关。与微软形成鲜明对比的是，我们一百人的开发团队，仅仅配备一名项目管理经理，而且连这个职位也是刚刚才设立的。虽说万里之外的counterpart team也许具备足够强大的项目管理能力，而且我们的开发经理们分担了相当程度的项目管理职能，但恐怕仍然不够。这也许能解释一些事情，比如我何以会收到“禅”文档（尚未出世，只有临时标题），还得装出读完了读懂了的样子。
另一个微软比我们强的地方是他们的工程师估计工作以天为单位。说到这里我简直想哭，丢不起这人哪。
还有一些小的差别也值得在下面提一提。只是不同而已，不一定谁比谁强。
微软现在有一些团队试行测试驱动开发（TDD）方法。我原来的理解是TDD仅限于个人软件开发流程，今天才知道原来可以应用于整个开发/测试联合团队。看来书不能只读半本，剩下的几章等我国庆节找时间读完吧。仔细想想，其实这一年来我们所用的流程也可以归到TDD的名下。微软TDD的典型迭代周期是1-2周，我们则是6-8周，这与我们的团队规模与测试复杂度有关。
在微软，Change Request的investigation和fix是分离的，由不同的人员进行。另外，其severity/priority是在项目管理、开发与测试小组的“三角会议”上决定的，据说这样可以避免争论。我觉得这些措施都是有利有弊吧。
最后，整理一下我从栾跃那里收集到的一些经验，人家毕竟也在微软的项目管理这一块干了八九年呀。
- 发挥团队的主观能动性，重视人与人的交往。
- 栾跃认为签字画押是很管用的办法，由不得你事后不认账。当然，这一招太狠了，一定的公司文化是先决条件，可不能滥用，比如就不能轻易地用到客户的身上（我忘记这个故事的来源了）。
- Manage communication. Manage expectation. Manage without authority.
- 当不能按时完成计划中的全部功能时，按时完成至少部分功能，而把其余功能推迟到下一版本。这样可以保持团队的士气，要知道推迟里程碑总是令人沮丧的。
总的来说，与其说我新学到了什么，莫若说我借着这样一个机会检验了自己在过去两年时间里业已学到什么。我突然意识到自己到了“知道自己知道”的阶段。在讨论会上听到了很多简单乃至幼稚的问题，我一开始感到好笑，后来才想到这样不对，人家并不比我差，只不过恰好没有这方面的经验或机会。我在小公司看到了问题，然后在大公司学习解决这些问题。有人遇到问题但不知道如何解决，有人遵循流程却不知道为了什么，就这个意义上说，我比他们都幸运。
Tools 
Help
