Posts archived in CompSci

很多天前和 zuola 聊天, 偶然提到正则表达式, zuola 说, 会正则表达式的都是牛人. 我说, 其实不难, 买本书看看就会了. 这几天, zuola 又在我博客上留言说会正则表达式才是真的程序员, 因此我想, 还是写篇比较浅显的教程, 让 zuola 同学快速成为牛人吧.

对于普通人来说, 正则表达式是比较难的. 从我个人的体验来看也是一样. 这个难, 主要在于两方面: 1. 接受正则表达式的思维方式; 2. 熟悉表达式里面各种各样的符号的用法. 第一点的难度在于这是个新东西, 和以前的知识结构不一样; 第二点的难度在于各种各样的环境下都对最基本的正则表达式做了很多扩展, 引入了各种各样的新的符号, 这样, 就使得学的时候一下子面对太多的复杂度不知所措. 举例来说, 大多数教程把 ^$*+-[](){}|.?\ 这些符号全部放到一起讲, 全然不分他们的层次关系, 导致学习者云里雾里. 同时, 不同的工具又定义了自己的特殊规则, 使得学习曲线更加陡峭. 因此, 我打算把正则表达式的知识点, 分几个不同的层次, 一一剖析. 在这一部分中, 我把正则表达式琐碎的细节一一剔除, 希望看到这篇文章的, 愿意学习正则表达式的读者, 能够迅速从这些繁琐的细节中解脱出来, 掌握其本质.

首先说正则表达式是什么. 正则表达式是一种描述性的语言, 用来概括一类字符串 (或者说一个字符串集合). 我们当然可以用自然语言来描述一类字符串, 比如我们说, 以 “010 开头的电话号码”, “夹在HTML 的 <b> 和 </b> 中间的内容”, “含有 hello 的字符串”, “负数”, “IP地址” “邮箱地址”, 等等. 其实在实际应用中, 我们也常常有这个需求, 比如说提取一篇邮件中所有的 email 地址 (查找), 或者把提取某类电话号码, 升个位, 加个区号什么的 (替换). 人当然可以做这个事情, 但是这个事情重复且单调, 又并不需要太多的智力, 因此, 计算机是最好的工具. 但是问题是, 我们怎么能够告诉计算机, 我们对哪类字符串感兴趣呢? 计算机科学家就帮我们设计了一种让人能够简单的写出来, 表达我们人类想表达的含义, 而计算机又恰好能够很容易的理解和处理的一种表达式, 这就是正则表达式了. 从人和计算机的角度说, 正则表达式是一种人和计算机都能轻松处理的约定, 用来描述一类具有某个性质的字符串.

正则表达式它既有倾向于人的思考方式的一面, 也有倾向于计算机工作原理 (有限自动机) 的一面. 因此, 传统意义上, 如果想真正理解正则表达式, 就要从理解计算机原理入手. 所幸的是, 我们普通用户, 在日常使用中, 并不需要了解计算机的原理, 因为这么多年技术的发展给了正则表达式很多新特性, 让正则表达式越来越脱离计算机的局限, 变得更加适合复杂的任务, 但这样的代价是正则表达式的细节越来越繁杂了, 对于初学者来说更加难学了. 因此我们在这里, 先讲本质, 后谈细节.

最基本的正则表达式, 只有三句话:

一个字符串是一个正则表达式, 比如 aaa, 就是一个正则表达式, 它描述了一个字符串集合, 这个字符串集合里面只有 aaa 这一个元素

两个正则表达式可以直接串起来, 比如 aaabbb 其实, 是由六个正则表达式 a a a b b b 接起来组成的. 我们先笼统的说, 接起来就等于把描述的内容接起来, 等一下再详细解释接起来的含义.

两个字符串, 比如 aaa 和 bbb, 用 | 连起来, 变成了 aaa|bbb, 也构成一个正则表达式, 它描述的字符串集合是原来分别的并集, 比如 aaa|bbb 描述了一个集合, 这个集合里面有 {aaa, bbb} 两个字符串.

好了, 就这两三话, 就可以解释正则表达式最基本的思维方式了: 用一个表达式, 去描述一类字符串(或者说, 一个集合).

光有这两个, 还不够强大, 因为上面的正则表达式, 我写几个, 就描述了几个字符串, 也就是说, 描述来, 描述去, 都是有限的集合, 不能描述无限的集合. 而我们想要描述的整数啊, 域名啊, 邮箱地址啊, 都是一切就有可能的, 因此, 我们有必要引入一个新的记号, 能够描述无限的集合,

一个正则式 X 可以加上一个 *, 用来描述任意多个原来 X 描述的字符串拼起来的字符串.

这句话比较费解, 我们用例子来说明一下, 比如 a* 这个正则表达式, 我们知道 a 描述了一类字符, 这类字符里面只有一个 a, 所以, a* 描述了一个或者多个 a.

我们再看 a | b* , 按照定义, 这个正则表达式描述了 a 和 b, bb, bbb 等. 如果我们引入一个括号, 写成 (a|b)* , 那么 a|b 就变成一个整体, 描述了 a 或者 b, 这时候, (a|b)* 就是一切只由 a, b 组成的字符串. 这里的括号, 是为了避免歧义, 表示 * 是作用在 a|b 整体上的. 这时候, (a|b) 描述了 a 和 b, 整体加了一个 *, 意味者我们可以任意选 a 或者 b 一个接一个拼起来, 所以, aba, aab 都是在 (a|b)* 的那一类里面的. 注意, * 可以匹配 0 个, 就是说, 这里面包含了什么都没有. 比如说 ab*c 也描述了 ac, 因为中间可以有 0 个 b. 如果您想至少要一个b, 可以写成 abb*c.

为了帮助您理解接起来, 我们再看一个复杂的例子, o(n|ff). 我们知道, n|ff 描述了 n 或者 ff. 当我们直接把 o 接在前面的时候, 描述的是 on 或者 off. 就是说, 接起来的时候, 要把 o 和后面每种情况都组合一次. 我们再看 (a|o)(n|ff). 前面描述的是 a 或者 o, 后面描述的是 n 或者 ff, 接起来, 描述了 an, aff, on, off.

我们都知道, 正则表达式描述的是一类字符串, 所以, X 和 Y 在接起来变成 XY 以后, 自然的变成了描述 每一种 X 里面的字符串和 Y里面字符串接起来的情况. 同样, * 好像把 X 和自己接起来多次一样 (可以是任意次), 每次只要接起来的是X里面的字符串, 就一定被 X* 所表述.

(熟悉集合的朋友立即知道 正则表达式是用一个表达式代表了一个集合, X|Y 等价于两个集合的并集, 而 XY 拼起来等价于他们所有的元素 x, y 拼起来的集合).

好了, 恭喜您, 您已经学会正则表达式了. 真的, 你已经全部学会了正则表达式的知识. 不过不着急, 我们先回顾一下正则表达式的要点:

1. 正则表达式由普通的字符, 以及几个特殊的字符, 即 括号 (), 或者 | 和 星号 * 组成. 用来描述一类字符.
2. | 表示或者. 如果有两个正则表达式 X 和 Y, 那么 X|Y 就描述了原来 X 描述的和 Y 描述的.
3. 正则表达式可以接起来, 变成一个更长的, 描述了一个各个部分被那些被接起来的正则表达式描述的字符串.
4. () 是为了避免歧义.

我们上面说的这四个, 就是 100% 如假包换的正则表达式了. 以后的, 都是为了更加方便的使用正则表达式, 而又引入的一些扩展. 恰恰是这些扩展, 让初学者陷入了细节的泥潭. 我们在下一节, 一个一个的来对付诸如 +, [, -, ], ^, $, {m}, 等这些非基本的高级的功能. 需要强调的是, 这些高级的功能, 其实都只是为了人书写方便, 而且是完全可以用我们这里说的最基本的几个规则代替的. 这些高级功能, 我们下节再讲.

练习:
写出匹配以下性质字符串的正则表达式:

1. 字符串 2009

2. 周曙光同学有两个名字, 分别叫做 zola 和 zuola, 人们常常混淆. 请帮周曙光同学设计一个正则表达式, 可以帮他匹配自己的名字.

3. 二进制数字 (最少有一位, 但只含有 0 或者 1的)

4. 非零的十进制数字 (有至少一位数字, 但是不能以0开头)

练习软件:

有一些比较好的软件帮你学习正则表达式, 我推荐初学者用 egrep. 可以在 windows 下用, 具体用法是在命令行 打入 egrep “正则表达式” 文件名
egrep 会把文件里面和正则表达式匹配的行 (该行含有一个字符串, 被正则表达式描述了) 打出来. egrep -o “正则表达式” 文件名 的话就会只打出那个完全匹配的字符串, 而不是行. 另外, 在 Linux 下可以用 grep –color “表达式” 文件名, 这样, 匹配上的那个字符串, 会被高亮显示出来.

练习文件:

0108200920088964
zuola -d
zooooola
world hello -012012 2009
0909 zola zhou
0101001
zuola

(把这个文件存成文本文件, 用 windows 的朋友可以放在您的 “我的文档” 里面, 因为 cmd 就是从那里开始运行. 然后您下载一下 egrep 做实验)

答案:

1. 2009
2. z(|u)ola [或者您可以写成 zuola|zola]
3. (0|1)(0|1)*
4. (1|2|3|4|5|6|7|8|9)(0|1|2|3|4|5|6|7|8|9)*

你会看到第四题的答案很笨拙, 居然写了这么长. 后面的大部分细节, 就是为了诸如此类的写得更加简洁一点.

Update:

1. 按照 AW 的留言和他的博客上的读者留言, 这个在线网站可以在线测试正则表达式:

http://gskinner.com/RegExr/

2. 如果要论正则表达式方面的参考书的话, 我推荐 < 精通正则表达式>, 中文版余晟同学翻译的, 质量上乘. 这本书可能是正则表达式方面唯一的一本圣经了, 上次我也是直接推荐给 zuola. 本来我是想打算写完了所有的初级教程再推荐的, 所以在本文初稿中没有提到这本参考书.

3. 才和 zuola 聊天, 他说要讲点具体的 blogger 用到的例子. 其实我之所以没在这篇文章里面讲, 就是因为这样的例子, 都是和应用程序结合的, 需要 sed, htaccess, awk 或者 linux 管道的具体知识, 我就是想解开这些知识的耦合. 一下子看着天书一样的 sed 替换表达式, 是很难一下子学会的. 他的建议是非常有价值的, 可能在本系列最后, 我会补充一篇 blogger 常用的正则表达式用例.

如果我们能够重回1980年, 回望整个计算机编程语言领域, 特别是工业界编程, 打死也不会想到日后 Java 这种无名小卒, 以及 C++ 这个又面向对象又支持过程的双面间谍能够红得发紫. 当年最流行的语言, 当属 FORTRAN, C 和 Smalltalk. 前两个我们按住不表, 单说这个 Smalltalk. 我们现在的教科书基本都不介绍 Smalltalk, 或者就用一句: Smalltalk 是第一个纯面向对象的语言 概括过去. 其实 Smalltalk 中有很多的好的思想, 一直在今天都发挥着魔力. 

施乐当年的图形界面(来源: harding.edu)

为提起大家兴趣, 我先说血统和设计等八卦. Smalltalk 的血统是算得上高贵的, 来自当年超级牛逼的 施乐 PARC 实验室. 施乐的 PARC 干过很多事情, 比较著名的一个故事是说乔布斯同学去参观, 看见那边科学家已经做出了 GUI (图形界面程序), 于是偷偷的回家搞 Macintosh, 搞好之后在1984年发布, 卖得大大的好, 赚得盆满钵盈. 西雅图当时有个大学没毕业做软件的小伙子, 看见乔老师赚了大钱, 想想觉得自己的人生挺没意思的, 只是和 IBM 做订购 DOS 的生意, 于是起了自立为王的念头; 加上看到乔老师的苹果机一个窗口一个窗口的很好玩, 于是一激动就自己搞了一个 Windows. (这个作软件的小伙子就是比尔盖茨啦). 这小伙子很牛, 把乔老师的苹果机逼到了角落里. 乔老师是最不能咽下恶气的人, 于是连在 Stanford 演讲了时候还不忘提一下微软抄苹果. 法律上就更不要说了, 两家公司之间旷日持久的 GUI 专利权官司从1988年打到1994年. 两家公司都一步不让. 最后施乐火了, 跳出来大喊一声: 靠, GUI 乃是我发明的. 于是把苹果给告了. 所谓螳螂捕蝉, 黄雀在后, 苹果被施乐这么一搞, 自己抄别人的老底就被挖出来了, 告微软就显得特别勉强, 所以官司最后也没赢, 以苹果无理取闹失败为结果.

施乐不光用 GUI 引领了我们现在计算机图形界面, 还发明了以太网, 鼠标, 所见即所得的编辑器等. 要不是这几样东西, 现在的计算机说不定是另一个样子呢. 言归正传, 前有施乐 PARC 出品了这么多伟大产品, 后加上 Alan Kay 这种牛人主导设计, Smalltalk 的血统之好, 和出自 AT&T Bell 实验室的 C 是有一拼的. C 还是两个人无聊敲打出来的, Smalltalk 是正儿八经作为一项研究弄出来的产品.  

事实上 Smalltalk 的确也是划时代的产品. 我就说我知道的两个部分. 

第一是现代程序员耳熟能详的 MVC 结构以及整个 Design Pattern 的思想. MVC 出现在 Smalltalk 中并不是偶然的. 当年施乐开发 Smalltalk 主要是用来做图形界面编程的, 而图形界面的编程首先就是从施乐发明图形界面开始的. 试想一个程序员成天写命令行程序, 肯定是不会太在意 MVC 的分离. UNIX 世界中并没有MVC的对应物, 因为压根不需要. 而图形界面程序的复杂度比其他程序要高太多了, 因此自然的就产生了 MVC 这样解开功能模块耦合的自然的设计. MVC 的重要程度和流行程度可以从两个小事情看出来. 第一是著名的 GoF 书, 翻开第一章第二节就开始讲 MVC, 用 MVC 作为整本书的纲领章节, 可见其重要程度. 第二是众多的 Java 框架, 比如Struts, JSF, 里面的对象就很直白的叫做 XXModel 或者 XXViewer. 这些传统都是从 Smalltalk 开始的, MVC 的影响一直到今天还到处都是. Smalltalk 不光催生了 MVC, 也催生了 Design Pattern. 细心阅读 GoF 的 DP 书我们就会发现, 里面所有的 Pattern 大多是在设计一个所见即所得的编辑器的背景下提出来的. 而上面我们已经说了, 施乐是第一家搞这个玩意的. 如果我们追溯 Smalltalk 早期很多的论文, 很明显可以看出, 虽然没有用 Design Pattern 这个词, 开发的时候要遵循一定的”对象结构”的思想是随处可见的. 

第二是我认为非常重要的: 运行时类型信息支持, 或者叫反射. 简单的说, 就是一个对象在运行的时候能够知道自己的类型(类名称), 以及这个类有哪几个方法, 哪几个字段等等. 

关于反射的基本概念在脚本语言里面是屡见不鲜的了. 大家都知道, LISP 里面的 eval 后面可以加任何的字符串, 构造出一个运行时对象. 脚本语言实现反射也很简单: 本来就是解释执行的语言, 多一个 eval 等价于多调用一次解释器而已. 而编译型语言就麻烦了, 因为解释器已经在编译期用过了, 运行的时候解释器是不存在的. 这样, 就造成了编译型语言没有运行时信息这个本质困难. Smalltalk 用了一个巧妙的方法解决了这个问题, 也就是 Java 和 Python 等现代语言用的方法: 虚拟机. 能编译的代码被先编译, 需要解释的代码在运行时可以被虚拟机自带的解析器再解析. 除了加入一个小的解释器到虚拟机外, Smalltalk 更进一步, 把对象的元信息也抽象成一个对象, 这样运行时需要的一个对象的所有元信息都能在面向对象的标准框架下表达. 我们用类 Java 的语言来举例: 一个叫 a 的 Foo 对象, 包含一个 a.hello() 的方法, 这个方法既可以通过 a.hello() 来调用, 也可以通过 a.class 先得到 a 的类, 再通过 a.Class.findMethod(“hello”) 找到这个方法. 最后再通过 .invoke() 调用这个方法. 这样的流程在没有虚拟机的 C++ 里面是没法完成的. 

在1980年, 这个反射机制的划时代意义是怎么说都不为过的. 我以我熟悉的 JUnit 的进化史为例说明这个议题. 

现在做单元测试的框架, 一般都被称为 xUnit 家族. xUnit 家族最早的成员, 不是 JUnit, 而是 SUnit (Smalltalk Unit). SUnit 的历史比 Junit 悠久得多, 大约在1994年的时候, Kent Beck, 也就是 Junit 的作者之一, 写了 SUnit. 而后才有了 JUnit (1998). 所以, 在 SUnit 的网站上, 极其显摆的写着”一切单元测试框架之母” (The mother of all unit testing frameworks). 事实上这是大实话 — 所有单元测试框架里面的名词术语, 都从 Sunit 来的, 如 TestCase, Fixture 等等. 

既然 SUnit 和 Junit 是同一个作者, 而早在1996年, Java 就已经成为工业界炙手可热的语言, 为什么要等到两年之后, JUnit 才横空出世呢. 这里面的原因说简单也简单: 自动单元测试需要反射支持.  1998 年前的 Java 没有反射, 直到1998年 Java 1.2 发布, 反射才完整的被支持. 所以, 只有1998年之后, Java 才有办法做自动单元测试. 

我们回顾一下 Junit 的工作流程: 继承一个 TestCase, 加入很多以 test 开头的方法, 把自己的类加入 TestSuite 或者直接用 TestRunner, 让测试跑起来. Junit 能够自动覆盖所有 test 开头的方法, 输出红棒绿棒. 这地方的关键是自动覆盖. 假如每个测试都是靠程序员自己写 printf 比较, 那不叫自动. 假如每个 TestCase 里面的每个 test 开头的方法都要程序员自己写代码去调用, 那也不叫自动. 所谓的自动, 就是在机器和人之间形成一定的规约, 然后机器就去做繁琐的工作, 最小化人的工作(RoR就是很好的例子). 

注意到我们的需求是 “让 Junit 自动调用以 test 开头的方法”, 而不需要自己很笨的一个一个自己去调用这些方法. 这意味着 Java 语言必须支持一个机制, 让 JUnit 知道一个测试类的所有方法名称, 然后还能挑出 test 开头的方法, 一一去调用. 这不就是反射么! 事实也证明了这一点: 目前互联网上找到的最早的 Junit 的源代码, 1.0 版的核心就只用了一个 Java 的标准库: reflect. 相反, 不支持反射的语言, 就得告诉单元测试的框架我要运行哪些. 比如说 C++ 的单元测试框架 CppUnit, 就很不方便–必须告诉框架我要测哪几个函数, 就算他们以 test 开头也不行. 还有一个好玩的例子是 J2ME 的测试框架. J2ME 是 Java 小型版, 不支持 reflect, 因此, JUnit 平移不上去. 如果细看所有的这些移植 JUnit 的尝试, 很容易发现, 移植出去的版本作用到有反射机制的语言上, 使用起来就很方便, 就比较成功, 比如NUnit; 没反射机制的就比较麻烦, 用的人也相对少, 比如 CppUnit 和 J2MEUnit. 反正任何对于 JUnit 的移植, 都绕不开”反射” 这个机制. 有反射者昌, 无反射者弱. NUnit 这个移植版本, 还曾经被 Kent Beck 夸设计好, 其原因, 与 C# 语言比 Java 更加良好的 attribute 和 反射机制, 是息息相关的. 

此外, 现代框架中流行的 依赖注射 (Dependency injection), 反转控制 (Inversion of control), 都是基于反射的. 这也就是为啥用传统的不支持反射的语言很多年的人很少听过这些名词的原因. 

有兴趣的读者可以继续阅读 wikipedia 关于反射元编程 这两篇文章, 相信会得到更加多的启示. 

Smalltalk 的IDE 开发环境 (来源: arstechnica.com)

Smalltalk IDE (arstechnica.com )

除了以上两点, IDE 和库的思想. 我们今天用的标准名词, 如”方法”, “字段”, 都是来自于 Smalltalk 的. 这些也都是划时代的工作, 因为我不熟悉, 也不敢不懂装懂的展开介绍了.  
有时候回看历史, 特别是回看编程语言的设计和进化的历史, 会发现很多散在的晶亮的珠玑. 

(完)

我用苹果 Mac OS X 两年了, 越用越觉得, 其他操作系统要从苹果的 Mac OS X 上学习很多东西. 特别是图形界面的统一的脚本化接口, 我认为这对未来的操作系统是一个很好的启示, 也是完全用命令行工作哲学在图形界面时代的一个不可缺少的部分.

起因是最近我在写一系列的中文文章, 因为几乎没有数学公式, 而我又喜欢纯文本的工作方式, 因此在排版上我选择了reStructuredText. 一般来说, 英文文本我都是直接在 vim 下工作. 可是苹果下的 vim 对中文的支持不是想像的那么好, 至少中文输入法打出来的常常有乱码. 名动天下的 TextMate 固然好, 显示中文却只有半个字那么宽, 看上去很不舒服. 其他的编辑器要么收费, 要么嫌大, 要么不顺手, 因此落到最后还是用了苹果的 TextEdit.

但是写技术文章的人都知道, 写文章不仅是打字这么简单. 特别是技术文章, 常常需要离开编辑环境跑脚本, 查Google, 看 wiki. (我不知道别人是不是这样, 至少我为了写出质量较好的文章, 写的时候也要做很多功课). 特别是因为我在用 reStructuredText, 一个最基本的需求就是处理当前文本生成 HTML/LaTeX 然后预览. 这些需求, 在 VIM 和 TextMate 中都是原生支持的, 很简单能做到. 但是在 TextEdit 这样的软件中, 乍一看, 毫无办法. 所幸的是, UNIX 家族的操作系统, 特别是苹果, 秉承了 简单的事情要有简单的解法, 复杂的事情要有可能的解法 这样的设计思路, 提供了不止一条解决问题的方法. 因为苹果设计了一个叫做”脚本化应用程序”的东西, 使得这些任务可以很简单的完成. 我研究了几天, 学到了一些东西, 拿出来和大家分享.

1. 最常常被忽略的菜单栏, Service 菜单.

用具体的例子来说可能更加简单. 用 Gmail 的各位都知道, 如果邮件里面有 90081243455 这样的数字串, 或者有 北京是西城区XX路YY号 这样的地址, Gmail 就很贴心的显示出 “使用 Google 追踪快递包裹” 或者 “使用地图查看地址” 这样的链接. 也就是说, Gmail 会识别出这些特定的样式, 然后给你一个上下文相关的(也就是说, 和你内容相关的) 服务. 这样的服务贴心舒适, 相信不少人都很喜欢. 一般我们把这个叫做上下文相关的服务.

再说 Firefox. 前不久 Firefox 出了一个很贴心的小插件, 叫做 Ubiquity, 我在 Firefox 下几乎离不开它: 选中任何一行地址, 只需要敲几个键, 就可以查 Google Map. 选中任何一个名词, 可以立即查 Wikipedia, 等等. 一般我们把也把这个叫做基于选定的服务.

苹果上的 Service 菜单, 就是这样的一个基于上下文相关和基于选定的服务. 举个最简单的例子, 如果你的机器上装有 Skype, 然后你选中了一串电话号码, 这时候你可以到 Service 菜单中选择 Skype -> Call this number. Skype 就会自动拨打这个电话. 或者选中一个单词, Service 菜单中就会自动出现: Look up in the Dictionary. 选中它以后, 你机器上的字典就会跳出来, 把单词的释义呈现给你. 所有的这一切, 都是基于苹果的一个叫做 System Service 的框架. 简单的说, 每个应用程序告诉系统: 在什么情况下, 你给我什么信息, 就可以让我做什么事情. 这样, 在选定的上下文符合条件的时候, 你就可以在菜单中选择这个服务. 这个东西方便无比. 比如说, 常常老板在邮件里面写: 你这周做啥啥. 我就可以选中整行句子, 按下 ⇧⌘ Y. 这样整行句子就被纪录到 Stickies 里面去了, 相当于随时写下一个便签.

现有的菜单栏固然好, 但是自己编写的更加好玩. 所幸的是, 你不需要会苹果的生涩的 Obj-C 才能编写菜单. 有一个强大的工具, 叫做 ThisService, 能够把 Ruby, Python, Applescript 和 shell 脚本都包装成 Services. 比如说我昨天就花了一分钟写了一个很简单的叫做 Translate 的脚本, 通过 Python 提交文本给 Google Translate, 返回中文. 在阅读有很多不认识的单词的新闻文章时候, 只要选中段落, 选择这个 Translate. 一个翻译成中文的窗口就出现了. 在这个软件的帮助下, 任何脚本都能点一下鼠标就变成一个服务: 具体我就不一一详述了.

总的来说, 我们可以注意到, 在日常使用计算机的时候, 一个应用程序中的一些内容(文本或者图像), 往往要作为另外一个程序的输入, 交给另外一个程序处理. 比如选中的单词查字典, 选中的地址查阅地图, 和选中的电话号码拨打, 选中的句子翻译等等, 这些需求都是存在的. Windows 家族解决问题的方法, 是通过程序切换和剪切板. 而苹果就是通过统一的接口来完成的, 思想和UNIX管道是非常相似一脉相承的 (当然, windows 家族从来就没有 UNIX 家族管道这个思想, 所以也就想不出统一接口这样的设计了).

在苹果下, 统一脚本接口可以用来处理像 Service 这样的程序之间通信的问题, 这个是 windows 家族从来没有想过的. 同时, 据我个人经验, 这个思想在 Linux/X11 家族也没有全部实现. 在 Linux 命令行下, 我们都知道, 不同的小工具之间是正交的, 一个程序的输出是一个程序的输入, 这个 UNIX 哲学长盛不衰. 直到今天, 正常的 Linux/UNIX 用户也会天天用管道做程序之间的通信. 可是在图形界面出现后, 这样的好传统在 X11 系统中似乎没有被继承. 比如, 不能选中一段文字直接送给 wc 计算字数. 究其原因, 是因为图形界面再也没有明显的输入输出这个概念了. 字符串和图像变成了要在程序之间传送的基本单位. 在这种情况下, 就需要不仅仅以文件为基本单位, 而是以被选中的那些字符串, 句子, 链接, 图片等为基本单位的通信. 在这个层面上, 苹果的确先行一步. (当然 Emacs VIM 等等也是可以通信和调用外部程序的, 但是毕竟不是整个系统都能这样).

2. 史上最简单的语言, AppleScript.

故老相传, 当年 Knuth 大神访问苹果, 总裁 乔布斯 同学发挥爱吹牛的光荣传统, 说: 高教授, 您来了. 我特别崇拜你, 您的书我都读过. 各位读者都知道, 要是Jobs 真的把高教授的书都读过, 全世界大学计算机系99%的教授基本上都要自杀让位给Jobs. 所以, 高爷子知道他吹牛皮. 以下的故事分两个版本, 第一个版本是硅谷的版本, 是高爷子当即就说: 斯蒂夫同学, 你又扯淡忽悠了. 第二个版本是我的版本: 说高爷子一听, 也不生气, 心想, 你我共同作为硅谷两个最懂字体设计的搞IT的, 我也不好得罪你, 且问你一道简单的问题, 看你读了我哪几本书. 于是高爷子眼珠一转, 题上心来, 问到: 乔布斯同学, 请问世界上最简单的编程语言是啥子呢? 乔布斯是个不懂技术的主. 想起当年和 Woz 合作的时候搞的东西叫做 BASIC, 听名字就觉得简单, 于是说道: 乃是 BASIC. 高爷爷说, 还有比这个更简单的么. (话说高爷爷心想, 我手里握着 TeX, Metafont, MIX, Literate Programming, CWEB 等几张王牌, 我就不信你说不出一个搭不上边的). 乔布斯同学哪能体会到高爷爷的良苦用心, 他又不会编程, 于是就杜撰到: 我们公司最近正在开发世界上最简单的一个语言: 叫做苹果脚本(AppleScript). 高爷爷一听就知道又是吹牛, 于是立即回复: 斯蒂夫, 你又扯淡忽悠了. 斯蒂夫同学哪服软, 于是要求开发部门开发一个连他都懂怎么用的语言. 于是 AppleScript 就被捣鼓出来了.
(以上故事纯属扯淡忽悠)

话说AppleScript 有多简单呢? 就和说话一样简单. 我曾经也写过介绍. 再这里再给一个例子:


tell application "TextEdit"
set filename to name of document 1
print filename
end tell

看, 明明就是英语嘛! 这么平铺直叙几乎没有语法的编程语言, 真的是世界上最简单的编程语言唉.

别看这个语言简单, 威力可不小. Mac 上几乎所有的应用程序, 都能够用这个语言去控制, 特别是 iTunes 甚至还有一个专门的网站, 专门就让你下载千奇百怪的控制脚本.

Applescript 还有两个好处: 1. 他是苹果原生支持的, 可以直接编译成苹果的应用程序来用. 因此, 简单的任务处理都可以用这个语言. 比如我们上面说的做成 Service 的, 也可以用 Applescript 来实现. 2. 他能够和其他应用程序交互. 其实在苹果系统中, 在脚本桥技术(Script Bridging) 出现之后, 理论上C/Javascript/Python/Ruby 都是可以和应用程序交互的. 可是AppleScript 的支持更加好, 更加直接. 比如取当前播放的iTunes乐曲名字, 可以用
AppleScript:

tell application "iTunes" to get the name of the current track

也可以用 Python

from Foundation import *
from ScriptingBridge import *
iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
print iTunes.currentTrack().name()

显然 Python 要显得笨重一些.

同时, AppleScript 也是苹果中小机器人 Otto 的底层技术, 因此在整个系统中发挥了基础性的作用. 虽然学习 AppleScript 显得很偏很不入流, 但是在苹果上做一些小任务有时候还是用得着的. 比如说我的让 TextEdit 支持 ⇧⌘ R 自动编译的例子, 就是先写了一串脚本, 取当前文件名, 然后使用 do shell script 这个指令调用 make. 这样, 调用这个脚本, 就可以完成自动编译. 用快捷键来调用脚本, 有两种方式, 一种是通过把脚本拷贝到应用程序的脚本目录并且添加一个菜单项. 另一种是用 QuickSilver 来帮忙了. 第一种方法应该最简单, 但是我没有尝试成功, 有兴趣的读者可以读这篇文章.

3. QuickSilver

我曾经间或的提到过 QuickSilver. 刚开始我并不能体会到他的魔力, 直到最近在玩脚本控制的时候才发现. 简单的说, QuickSilver 就是能让你用键盘控制程序的程序. 或者说, QuickSilver 就是键盘命令中枢. 比如说播放音乐, 只要一键激活 QuickSilver, 再打一下 play (有时都不要打全), 回车. iTunes 就放起音乐了. 上面我们说的任何控制系统的脚本, 都能够被 QuickSilver 控制. 我在拔掉你的鼠标一文中也提到, “你要是苹果用户又不用QuickSilver或命令行, 那你是把苹果当Windows用”.

QuickSilver 作为应用程序快速启动的功能大家想必都很熟悉. 控制 iTunes 大家也得心应手. 我就介绍一个被大家忽略的功能: 设置上下文相关的快捷键. 传统上, 快捷键是被应用程序定死的. 即使你写了一个扩展应用程序的脚本, 你也得点点鼠标去调用, 而不能设置键盘快捷键去调用. 解决的方法有三个, 第一个是我在第一部分讲的, 包装成一个 Service. 这样的好处是可以包装出一个快捷键, 坏处是这个Service 是全局都有用的, 不管你在哪个应用程序里面, 这个 service 都能用. 第二种是我在第二部分提到的我没有尝试成功的, 即添加一个菜单项目的方法. 第三个就是采用 QuickSilver 的 Trigger 功能了. QS 用户可以使用 ⌘’ 调出 trigger, 然后添加一个 Custom Trigger, 把目标指向自己写好的一个 AppleScript, 给这个 trigger 分配一个快捷键, 并且把使用的范围 scope 限定在一些应用程序中. 这样, 不费任何功夫, 只写一个简单的脚本, 您就可以在你的计算机上把你的 TextEdit 也改造成一个功能强大的编辑器了.

结语: 如我在拔掉你的鼠标一文中说的, 完全使用键盘能强迫人使用高效简洁和正确的工具. 随着图形界面和多媒体的出现, 鼠标的反而成了一个最常见的动作. 其实认真分析鼠标点选操作就发现, 无非是两种: 一种是用鼠标选择内容, 准备用一定的工具和程序处理这个内容, 还有一种是鼠标选择操作. 前者对内容的选择, 鼠标是高效的. 而后者对操作的选择, 鼠标是低效的 (因为键盘快捷键和命令行更加高效). 因此, 如果我们想要高效的工作, 就要避免后一种操作, 并且进一步解放前者.

对后一种的避免很简单: 拔掉鼠标, 强迫用键盘. 对前者的解放, 随着各种各样如 Service, Ubiquity 以及上下文敏感程序的兴起, 使得我们不需要在不同的程序之间拷贝来拷贝去, 而是直接通过程序之间的标准接口通信, 使得我们甚至不需要切换程序. 所有的都应该这些基于命令行和后台来完成, 而不是通过分散注意力切换程序来完成. 这些新的工具, 更加符合一个高效能的现代人的需求, 更加能够提升你的效率. 当然, 决定做事的效率的不仅仅是工具, 因此, 不要迷恋这些工具. 为了获得 1% 效率的提升, 而过于强调工具的各种淫巧, 反而降低效率. (警告: 这些工具都是非常迷人的, 很容易一用就爱上它们. 记住, 效率是最好的判断标准 :).

附 “完全用命令行工作系列” 文章一共五篇, 写了也不少了, 有些工具我一笔带过, 有些我花了几句话讲了一下. 基本上我介绍到的提到的, 都是我自己天天用的, 也是我认为非常有用的. 我写作的时候也都是带着 “Smart and Get Things Done” 的哲学, 只介绍干净的设计良好的软件. 各位想实践 GTD 的读者可以自行选择趁手工具. 有更多的 GTD 的完全用 键盘/命令行 工作的软件, 也不妨向我推荐.

完全用命令行工作-3: 常用工具

完全用命令行工作-2: 常用软件

完全用命令行工作-1: 拔掉你的鼠标

完全用命令行工作: 几条趁手语句

软件, 没有圣杯的荣耀, 只有梦萦的代码 — “Dreaming in Code”书评

code2.jpg当日我读完第三遍 “Dreaming in Code“,  是夜, 代码冰山入梦来. 我想, 应该整理一下我的读书笔记, 写一篇书评了.

两打程序员, 三年的时间, 4,732 个 Bug, 以及一个愿望: 打造一个卓越的软件. 这就是 “Dreaming in Code” 所描述的故事. 而这个故事, 却没有 “新机器的灵魂 (The soul of a new machine)” 那样波澜壮阔, 甚至没有 “人月神话 (The Mythical Man-Month)”  那样告诉你一个明确的教训. 单论情节,  这就是一个沉郁到极点的故事. 没有英雄人物, 没有情节跌宕, 所有的人草草的出场, 草草的收场. 可是依旧一个梦在那里. 这个梦让全世界的程序员心动, 萦绕每个敲下过 Hello World 的人 — 怎样打造卓越软件.

软件难做,  高德纳 (D. E. Knuth) 这样写道. 为何难, 他没有回答. 而 “Dreaming in Code” 带来了一个具体的例子, 一个鲜活的, 几乎失败了的例子. 一个有资金, 有优秀程序员, 有开放的管理文化和明确的雄心的项目, Chandler, 曾经如恒星一样耀眼, 又如流星一样湮没. 不禁要问: 为什么? “幸福的家庭是相似的, 不幸的家庭各有各的不幸”. 这句话用来解释失败的项目再合适不过了.  如 Fred Brooks 那个著名的论文 “没有银弹 (No Silver Bullet)”[PDF] 揭示的一样, 这个问题, 没有一个明确的答案.

即使没有答案, 人们也在求索. 这本书, 和 “人月神话” 一样, 都是探索怎样打造优秀软件的著作. 不同的是 “人月神话” 近似于总结, 而这本书, 却只有问题,  无数的问题: 为什么不能像架设桥梁一样打造软件? 为什么构建软件不能像搭乐高积木一样? 为什么一个创造奇迹的人不能再次创造奇迹? 为什么有的开源软件成功了, 有的却失败了? 太多的为什么, 太多的问题. 而这个问题的答案, 不在书上, 确在书的字里行间, 在读者的思考里.

我是个天天写代码的程序员, 也是个常常在开源社区参与项目的程序员, 说起来再熟悉不过代码这个东西了. 可是怎样编写代码来组建卓越的软件, 我没有答案, 谁都没有答案. 可是这本书能帮助你找答案. 我极其推崇这本书的原因是, 读完之后, 你能问自己一些问题, 答案是这个么, 是那个么? 这本书本身, 不是答案, 而是获得答案的钥匙. 随着记者特有的写实的文风, 你会在书的字里行间, 跟着作者找到这把钥匙.

对于想找钥匙的人, 这本书有两个优点. 一是提出问题多, 资料多. 都说提出问题是解决问题的一半, 这本书在这一半做得相当好. 问题的另一半, 也就是答案, 这本书没有具体给出. 但是这就给了读者独立思考的余地. 有人会说是因为没有风险投资的压力, 有人说是前期需求不明确, 有人认为管理混乱. 无论怎样的答案, 你都会找到翔实的资料来佐证, 或者推翻. 这是一部活生生的不带评论的记录片. 这样的一手资料, 是极其有价值的.  第二个优点是故事的本身. 这是一个让人郁闷的故事, 一个失败的故事. 成功的故事通常激动人心, 但成功的光环往往掩盖了很多问题. 在成功的耀眼光芒下, 即使钥匙就在阳光下, 也很难找到光闪闪的它. 而在失败的废墟和尘土中, 钥匙如小钻石一样藏着, 细微的光芒引导勇敢的探索者, 并给他高价的回报. 失败总是比成功, 更加容易获取教训.

这是一本文笔优雅, 细节具体的书. 可是缺点也是显而易见的. 最明显的就是琐碎八卦太多. 作者是一个知识面很广的人, 能够从日历软件扯到图灵机和停机问题, 也称得上科班出身. 但是有时候可能也是为了显示知识面宽广吧, 把不相干的概念堆砌在一起到了没有边际的程度了. 比如第九章, 完全就是软件工程领域的最最基本的知识, 从软件工程到GOTO大战, 再说到 Ajax 和 Google 的崛起, 这之间的逻辑线就完全是天马行空了. 任何一个称得上关心现代开发技术, 或者科班出身的开发人员, 对于书里面提到的这些琐碎的事情, 都是烂熟于心的. 概念的过分堆砌和琐碎事情的描述至少占了这本书的1/2. 幸好这本书是值得读很多遍的, 再次阅读的时候, 跳过去就好了.

如果这篇书评能有副标题的话, 我愿意写上: “五个月的时间, 三遍阅读, 三十二页的读书笔记和无数的批注, 以及一个萦绕在脑海中的思考: 如何打造卓越的软件?” 这就是我这个读者的故事. 这本书国内的翻译是韩磊老师做的. 他翻译做 “梦断代码“. 我更加喜欢 “梦萦代码” 这个名字 (Dreaming 翻译成梦萦, 意音俱佳).  当年希尔伯特被问起, 五百年后若是他重回世间, 第一件事情是什么. 他说, “我要一定问黎曼猜想有没有被证明”. 相似的是, 宋朝僵卧孤村壮志未酬的陆游, 当年眼见收复中原无望, 梦里恍惚见到铁马冰河,  一梦醒来后对子女说: 王师北定中原日, 家祭无忘告乃翁.  无数的开发者梦萦代码, 一梦醒来, 就想问一个问题: 软件工程有没有找到银弹? 这个银弹之梦, 打造卓越软件之梦, 会一直萦绕着开发人员, 直到永恒.

情系软件, 梦萦代码

几天前, 偶然看到 SUN 公司 CTO Greg PapadopoulosIT 产业红移学说. 慢慢思考, 做了很多笔记, 有几条写下来.

所谓的红移学说, 就是 IT 公司的计算能力需求是指数增长的. 这个结论没什么奇怪的, IT 产业的摩尔定律说, 每18个月微处理器的计算能力就能翻一翻了. 除此之外, 存储能力, 带宽需求等等, 都是指数增长的, 有供给就有需求,这一点原没有什么大惊小怪的.

但是仔细分析, 对计算能力需求的那些应用里, 是不是所有的需求都是同样的指数增长的呢, 不是. 那么, 有快有慢的时候, 就必然有超摩尔定律增长的和低于摩尔定律增长的. Greg 把超摩尔定律增长的定义为红移, 把低于摩尔定律增长的定义为蓝移. 并且从SUN自身角度指出, 为了让 SUN 跟上 IT 产业的发展大潮, SUN 必须找到那些超摩尔增长的子领域, 把产品销售给超摩尔的应用, SUN 才不会被摩尔定律谋杀.

Greg 的立论基于互联网带宽的超摩尔, 高性能计算需求的超摩尔和软件作为服务的超摩尔速度. 我个人的见解是, 至少目前有5+1 个领域是超 Moore 的. 第一, 复杂的关系计算的发展是超摩尔的. 比如 Netflix 的推荐系统, Google 的 AdSense 系统. 这些关系计算的增长速度, 是超过 2倍/18个月的. 处于提供这些服务的行业, 对计算能力的需求必然是超摩尔的. 因此, 他们必须购置新的 IT 设别, 更新软件效率. 第二, 海量数据的处理的发展是超摩尔的. 互联网数据目前的翻倍速度是 30%/年. 其他领域的数据也有如此的指数规律. 一般情况下来说, 这个速度是低于摩尔律的. 但是任何一家公司海量数据处理的, 都是从无到有发展起来的. 大如 Google, 也不敢说覆盖互联网所有信息. 因此在这十年中, 海量数据处理(特别是搜索, 爬虫, RSS) 将经历从无到有的过程, 其增长, 肯定是超摩尔 的. 第三, 海量带宽的发展是超摩尔的. 以 Flickr YouTube 和 Twitter 为例, 他们的带宽翻倍速度是以天为单位的. 在网络基础设施领域, 中国移动等网络服务商也曾超摩尔发展, 以此为契机很多网络设备服务商如思科华为都超摩尔发展的. 第四就是海量的交互是超摩尔发展的. 网游, 信用卡服务系统都是这方面的例子, 就不一一例举了. 第五可能不为大家熟悉, 就是海量的高性能计算. 这10年内, 世界超级计算机的发展速度是超过摩尔定律的. 在科研领域, 我们清楚的看到高性能计算的需求远远超过 Intel 每年提供的增长, 多达千个万个节点的超级计算机在美国的国家实验室已经很平常. 还有一个额外的是海量的多媒体处理, 全球的电影业, 多媒体业的发展, 横跨前面提到的五个上面, 对每个领域都有超过 摩尔律速度的需求.

这几年这几个子领域的超 Moore 发展, 造成了几个非常有意思的现象.

1 . Google 在超摩尔发展

Google 是一个及其有野心的企业. 首先, 它站在这个时代最快的超摩尔的领域, 海量数据的处理. 它同时还拥有复杂关系计算[Orkut, AdSense], 海量带宽处理 [YouTube] 和海量交互处理 [Talk, Gmail, Google Maps] 三个方面. 这个方阵中的每一个模块, 都是行业的翘楚. 各位读者应该在最近的三个月内都用过Google的不少服务, 而且使用Google 各项服务的总次数相比一年半前肯定是翻倍了. Google 的超摩尔发展和它的策略, 即整合人类所有信息并使之可用 是分不开的. Google 的心大, 舞台就大, 现在爬虫能爬到的信息, 远在人类可用信息之下. 因此, Google 为了完成目标, 必须远快于信息生产速度. 总有一天, Google 抓完了互联网, 增长速度和网络信息的速度一样了, 那Google 也就变为今天的微软了. 20年前或许一人一台计算机是最大的幻想, 谁能想到20年后整合人类信息是不是一定达不到呢. 不过 Google 是善于开创和培育新领域的公司, 因此至少在10年内, Google 依然会超摩尔发展下去.

2 . 超摩尔企业控制了整个产业的需求, 联盟的瓦解和重新结合是常态.

摩尔定律既规定了半导体企业的光明前途, 又是半导体企业的魔咒. 因为半导体的速度提高速度太快, 如果耗用半导体的应用没有发展起来, 或者在18个月内需求量没有更新一倍, 那么, 半导体和硬件制造企业就不会喜欢这样的公司. 想当年 Windows 如日中天的时候, 平均三年就推出一个新版本, 而且每推出一个版本, 能支持前一个版本的硬件都几乎不能完美支持后一个版本. 因此, 操作系统和应用软件在超摩尔发展, 反过来拉着 Intel 超摩尔发展. 而 XP 以降, 微软花了 5 年时间才更新到 Vista, 而且消费者还不喜欢. 个人计算机的增长速度和操作系统的需求速度已经慢于摩尔率. 这时候, Wintel 联盟的瓦解早就是预料中的事情了. 这时候 Intel 和其他硬件制造商, 不需要依靠微软, 也能存活. 为什么呢? 原因是, 他们在 IT 产业链中, 发现了除了软件企业以外的其他的超摩尔的东西, 这个东西, 就是上面说到的5+1, 而最重要的, 是网络计算.

3 . 传统软件企业被摩尔律超过

在解释网络计算之前, 我先解释一下为什么传统的软件企业被摩尔律超过. 一个产业, 如果不是新兴产业, 那么正常的发展速度应该是和国家的 GNP 发展速度相当的. 即使在发展速度最快的中国, 目前也只能做到 120% / 18 月. 这一点, 是摩尔律所不能容忍的. 软件产业, 和其他信息产业一样, 都是社会服务业. 其终极形态, 应当是和 GNP 发展等速的. 简单的说, 有多大的经济需求, 就有多大的软件服务需求. 但是, 产业从来就不是均等的. 当一项新的需求被发现的时候, 因为没有现存的应用, 巨大的需求缺口会拉着原本应该正常发展的产业超速发展. 比如中国的移动电话, 石油产业等等, 都是如此的例子. 在 70-90 年代, 所有的行业都在走信息化的道路. Office, 电算, 电子商务, ERP, CRM 等耳熟能详. 他们的需求缺口相比于产业所能提供的, 都是几个数量级的高. 这种所谓的蓝海让任何跳进去的公司都能发财, 而且发展速度都超过摩尔律. 在此情况下, 硬件企业作为市场的支撑, 也在蓬勃的发展. 到了1999年左右的时候, 互联网的第一次泡沫前, SUN, HP, IBM 等公司靠出售硬件, 大赚了一笔.

然而, 好景不长, 2000年问题解决以后, 发达国家原来轰轰烈烈信息化的公司基本上已经完成基础设施建设了, 软件的需求一下子放缓了. 电子消费品的出现使得个人电脑发展开始放缓, 各大公司因为网络泡沫的破碎也开始紧缩 IT 投资. 软件企业的需求在源头上被紧缩. 另一个致命的打击来自开源软件. 1999 年的互联网泡沫客观上促使了一样东西的普及, 就是开放源代码软件. 传统的软件企业的定价策略是一台计算机安装算一个价钱. 在互联网泡沫时候, 网站需要以超过摩尔律的速度购买计算机, 但是这样就会同样把指数级别的投资送给微软和 Oracle. 因此, 很多公司在购置硬件的同时, 缩减软件投资, 采用免费的开放源代码的软件. 这样, 软件的需求就是一个常数, 这一点一下子拉开了硬件商和软件商地位上的差距. 虽然互联网产业发展了, 软件公司却没有跟着超摩尔发展. 等到微软和 Oracle 等传统软件公司回过神来的时候, 超摩尔的互联网已经把他们扔在了车轮之后. 那么, 应对开源大潮和超摩尔的网络计算, 硬件公司在做什么呢?

4 . SUN, IBM 等硬件提供商放下身段生产平民硬件

如果我们观察从 99年到 2007 年, 这些硬件行业的大哥大做了什么, 我们就能清晰的看到一个个放下身段的巨头. 我们知道, 超摩尔的互联网必然以超过摩尔律的速度需要硬件. 哪个硬件商能赶上此大潮, 就能做弄潮儿. Intel 芯片商要做的, 是提供更加强力的处理器; 存储商做的, 是开发大容量的存储器. 而 SUN 和 IBM 这些系统商来说, 选择就是从阳春白雪走向平民硬件. 当年的 IBM 和 SUN, 固守自己的 RISC CPU 生产线, 投入大量资金开发专有 UNIX 操作系统. 昂贵的售价使得超摩尔的企业不愿采购他们的系统. 此时, 要不固守阵地, 要不另找出路. 我们看到, 他们都开始另找了出路: 出产便宜的基于 x86 架构的硬件, 支持开源的基于服务收费的软件. 他们知道, 只有把硬件做便宜了, 超摩尔速度才能眷顾他们, 否则出路就是 SGI 和 DEC. 只有把软件开源免费送出去, 超摩尔的软件需求才能最后通过软件服务的形式让他们受益. 而一个机器一份拷贝的那种传统软件商业模式, 已经不再实用. 短短几年内, IBM SUN Novel 包括苹果, 都拥抱开源, 拥抱 x86. 我想这不是没有原因的.

5. 如何抓住超摩尔律, 投入新兴 IT 市场?

A. 硬件

硬件厂商在这场互联网浪潮当中扮演了极其重要的角色. 首先, 他们联合了新兴的开放源代码社区, 透过降低了硬件系统的总体成本. 因为此, 硬件商既不需要自己投入大量经费研发软件并把成本转嫁给新兴产业, 又能避免自己口袋中的利益流向传统软件企业. 而网络服务商, 消费类电子制造商和设备提供商, 这些年都是活在超摩尔里的. 如 CISCO, 中国移动, Apple 都是时势造就, 不发财都不行. 当然, 硬件的制造需要较大的投入,除拥有一流的技术外, 尚需要一流的设计和制造. 目前这两点在中国都不具备.

B 软件作为服务/ 软件作为基础设施

前面已经提到传统软件企业, 比如微软, 正在被硬件厂商, 软件服务商, 开源社区合力绞杀. 那么, 做软件就不赚钱了么? 非也. 既然软件已经变成基础设施和服务, 那就应该发挥基础设施和服务的作用. 软件作为服务, 如 Gmail, Facebook, 如 Amazon 的 SimpleDB, 如 Google 的 Documents, 都作为某种服务提供. 前面提到, 因为软件不能按照一台机器一台钱卖掉了, 所以落后于 摩尔律. 虽然这么说, 实际上网络应用对软件的使用需求依然是超摩尔律的. 因为超摩尔的速度造成计算机数量的增长, 系统越来越大, 很多硬件瓶颈就随之出现. 这时候, 传统的单机软件无法解决所有的问题, 必须有一个支持大系统的软件系统出现. 作为提供给网络计算系统的软件, Google 是自产自销, 自己解决基础设施问题. Amazon 和 SUN 则是提供如 EC3, SimpleDB 等工具, 以便把超摩尔的需求转化为自身产品的超摩尔发展. 开源社区也分立出很多创业公司, 提供一揽子的软件解决超摩尔的方法.

我个人看好的是作为软件咨询和软件服务的服务提供商. 机会可以在提供海量信息处理系统, 提供海量带宽处理系统, 提供海量关系处理系统等方面入手. Amazon 的经验让我们看到, 这些软件服务都是可以从系统应用中剥离分立并且产品化的. 在面向互联网的软件服务方面, 我挺看好银杏的.

结尾语: 写完这些, 突然悟到, 所谓的蓝海, 不就是一个超过行业平均水平的新兴子产业么. 想要不陷入和 GNP 一样发展速度的的红海, 就要找到超过行业发展速率的新兴子产业.

[Disclaim: It's evil, don't use it unless you are fighting with some even more evil software.]

Short Intro. [Skip it if you don't know much about OS or aren't interested in the technical detail ]

As you might know, every program on Linux system runs on the kernel instead of directly contacting with actual machine. For modern operation systems like Linux, BSD(Mac) and Windows, a mechanism called system call is used to request the system resources via operation system so that operation system has the full control of all programs. In brief, when user program need call a function in library, e.g. print in stdlib, library function forwards (usually library function is a light-weighed wrap of the system call) the request to operation system. Since the system is highly hierarchical and user program is built on the top of libraries and OS kernel, it’s possible to insert some layers in between program and OS to intercept the request. Don’t panic about the nerdy name. Actually this strategy is commonly used on Window platform in anti-virus software as well, because anti-virus software want to monitor every system resource usage for any program and prevent the malicious resource requests.

Here, we simply want to intercept a system call named “TIME” so that every time a program request the current time (so that it can verify whether the licence has expired), we feed the program with a fixed (fake) time. By fooling the program around, you can literally use a program forever. God, doesn’t this mean I can use all software forever? The bad news is for some OSs like Windows, it’s very hard to do system call interception as all the APIs are undocumented and software might have other ways to prevent this. The good news is lots of software on Linux and Mac are simply reading system time. Actually, only top developers and Microsoft partners know how to do system interception. However, for Linux, since the system itself is open source from bottom up, there is no way to prevent such kind of interception (Now you know why some software companies don’t like Linux :).

Approach 

On Linux, tons of methods are around. Here I just introduce three of them briefly under the assumption that you don’t have the source code of that software. [Otherwise you can just modify the source code]

Method 1: Intercept library call in linking time.

Sometimes you have a library (A) that can be used as a part of your program and you want to intercept the library call of that library (A). The best way and the easiest way is to write a fake function and link it in the compile time. This method is totally harmless to your system and very neat. If you can do some modification in makefile, then this procedure is totally transparent to both developer and user.

Method 2: Intercept system call in the run time

If you’ve already got a execute program, then there is no way to intercept the system call in compiling time. To intercept the system call in the run time, there are two ways. The first approach is putting the target program in a designed container. Typically, a container fork/create/call the target program as child process. Since in OS, parent process has accessibility to the child process, it can intercept syscalls easily via ptrace toolset. The second method is to hack the kernel, namely, to tell the Linux kernel to response syscall in a certain way. Since now Linux supports kernel module, a very convenience approach is to compile a program as kernel module and install it on the fly. However, this method is less flexible then the previous method as now all the syscall are intercepted, even for system calls from other programs. [Sure, you can restrict the module only applicable to a certain process via a pid comparison, but then you need to feed the kernel module with PID, it's awkward ]

In my implementation, I use ptrace/container method. I’ve tried kernel module method but failed as there were not so much well-formed documents on Linux 2.6 kernel.

Here is my code, it’s self-explanatory, have fun with hacking. [Download the C file]

/* Faketime wraps a user program and feed it with user-specified fake system time
   so that it can be used forever without any "licence expired" problem
	 
    Copyright (C) 2007 Eric You XU, Washington University ( youxu [@T] wustl.edu ) 
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA 

*/

#include <sys/ptrace.h>
#include <asm/ptrace.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/syscall.h>
#include <linux/user.h>

/*
Register layout defined linux/user.h, but actually in 
 asm-$(arch)/user.h
struct user_regs_struct {
        long ebx, ecx, edx, esi, edi, ebp, eax;
        unsigned short ds, __ds, es, __es;
        unsigned short fs, __fs, gs, __gs;
        long orig_eax, eip;
        unsigned short cs, __cs;
        long eflags, esp;
        unsigned short ss, __ss;
};
*/

/* Note that EAX now is RAX in x86-64
 	we can also find the actural offset for any register
 	from <asm-$(arch)/ptrace-abi.h>
#define RAX 24
*/

#define ORIG_RAX 44
/* ORIG_RAX stores the number of syscall */

#define SYS_TIME 13
/* Machine specific syscall number is defined in 
	unistd.h */

#define back_to_future 1175737392

/* Time is stored as a long interger in C, you can get 
	current time via time(NULL). Thus, it's very easy to 
	get a long integer denoting some time in the past. 
	
	Python/Java can also be helpful in figuring this out 
	
	If you don't know how, just keep in mind that 
	Dec. 1, 2007 is about 1196476452. 
	One day interval = 60*60*24 = 86400 [Time flies fast]
*/

char* host_program = "your program name here";
char* arglist = "your program fake list here";
/* Make modifications for these two lines, then 
	compile it via
		gcc faketime.c -o faketime
	use it via 
		./faketime
*/

int main()
{   pid_t child;
    long orig_rax, eax;

	 struct user_regs_struct regs;
	 int status;
    int insyscall = 0;
    child = fork();
    if(child == 0) {
        ptrace(PTRACE_TRACEME, 0, NULL, NULL);
        execl(host_program, arglist, NULL);
          }
    else {
       while(1) {
          wait(&status);
          if(WIFEXITED(status))
              break;
          orig_rax = ptrace(PTRACE_PEEKUSER,
                     child, ORIG_RAX, NULL);

          if(orig_rax == SYS_TIME ) { /* Intercept SYS_TIME syscall */
             if(insyscall == 0) { /* Syscall entry */
                insyscall = 1;
             			  }
         	 else { /* Syscall exit */
					ptrace(PTRACE_GETREGS, child, 0, &regs);
				   	/* We can also use ptrace(PTRACE_SETREGS, child ,RAX, &back_to_future); 
						but it doesn't work. There might be some tricky here */
					regs.eax = back_to_future;
					ptrace(PTRACE_SETREGS, child, 0, &regs);
            	                 }
          } // End if with SYS_TIME 
       ptrace(PTRACE_SYSCALL, child, NULL, NULL);
        }
    }
    return 0;
}

我一直很推崇使用 Python, 但是推崇不是迷信, 今天就说说几个 Python 相对于 Java 和其他语言的缺点, 以及初学者要注意什么.

1. 文档不完善, 最少惊奇原则不适用

很多 C++ 和 Java 开发者都知道, MSDN Java Doc 堪称技术文档的典范. Java 更是充分体现 Knuth 提出的 Literate Programming 的精华, 用一个专门的叫 javadoc 的工具自动提取程序元信息, 生成交叉引用的 JavaDoc 文档. 任何复杂的类, 框架, 在javadoc 的统一管理下, 可以生成非常漂亮的文档. 如果再配合设计模式中的 facade 模式, 一个复杂的框架很简单就可以上手. 这方面, Hibernate, Lucene 都是优秀的典范. 当然, 交叉引用的文档也有明显的缺陷, 就是极其庞大冗长, 因此 JavaDoc 和 JDK 是独立的两个部分. MSDN 更加绝了, 直接出几张光盘, 你爱装不装. 虽然冗长, 好处就是在面向对象的汪洋大海中顺着链接, 永远不会丢失. 而 Python 的文档还远远不够细致. 所有的对象方法, 只是简单介绍. 如果一个对象方法返回另外一个不熟悉的对象, 则必须手工定位新对象的位置, 而不能顺着文档继续前进. 为了搞清楚一个包, 完成一个小任务, 可能要多次搜索文档. 对于黑客级别的用户来说, Python 文档言简意赅, 喜闻乐见, 只要记住了每个对象的每个函数, 写程序如行云流水. 对于初学者和用 Python 写稍大项目的人来说, 这就是最恐怖的噩梦. 因为以介绍单个函数功能为组织方式的文档, 对于刚上手的用户来说, 很难顺着对象调用关系,通过文档指引完成任务. 即使著名的框架比如 django, 也缺少交叉引用的细致的文档. Python Library Reference 只能说是一个完成了 50% 的README. 在这种情况下, 除非对一个框架很熟悉, 否则这个框架对于初学者来说简直是”惊奇的噩梦” — 一般用户只能看例子然后顿悟到: 哦, 原来是这样用的.

除此以外, 因为语言的动态性, 使得 IDE 能给的帮助特别少. 对于 Java 程序员来说, 很多时候都是靠着 Eclipse 的提示去选择正确的方法调用. 而因为 Python 的动态性, 变量的类型到运行时才能确定, 因此能够给的提示相对变少. Python 既是动态的, 又是强类型的, 所以代码的阅读者必须要一步一步手工追踪中间对象的类型, 并且查阅对象方法文档, 才能搞清楚到底一段代码做得什么. 而这一切, 偏偏是没有 IDE 帮助的. 对于开发者来说, 如果不熟悉对象的可用方法, 用 Python 开发也会事倍功半, 因为要常常停下来去 Google.

当然, 文档不够完美, IDE 不支持的现状, 根本是因为 Python 的动态性: 谁让 Python 返回值不规定类型呢? 我的建议是, A. 对于现成已知的一些对象方法上, Python 社区应该注意文档的维护. B. 对于不熟悉对象的可用方法这个问题, 要买一本 Pocket Reference. 或者下载一些 cheet sheet. 在刚接触 Python 或者 刚接触 Python 框架的时候, 一本薄薄的可供快速查阅所有对象的所有方法的小书, 无比重要. 这也间接的说明, 和 shell 脚本, 正则表达式语法等一样, 脚本语言必须要很熟悉才能发挥魔力.

(– 附实例,对Java 不熟悉的可直接跳过: 我曾经做过一个游戏, 这个游戏类似于推箱子, 其中的一个核心是要把多幅带alpha 通道的图像拼成一个图像, 然后显示在窗口中. 打开 API Doc, 简单的搜索一下, 发现有 java.awt.Image 类. 不过这个是抽象类, 没关系, 文档下面就明明白白写着两个可以直接用的类, 一个是 BufferedImage, 另一个是 VolatileImage. 看上去 BufferedImage 更像, 于是点进去, 正是想要的. 看看构造函数, 一个空白的图像就构造好了. 顺着方法向下看, 看到 createGraphics() 方法, 返回 Graphics2D 方法, 说明中写着这个可用做在 Image 上绘图, 正是想要的, 点返回值, 是 Graphics2D, 有方法叫 drawImage. 任务完成, 轻松自然.

回到 Python. 我遇到过一个需求, 是用 Python 提取所有一个 Zip 文件的注释. Google Zip+Python 定位到 zipfile 模块. 找到 ZipFile 对象. 读文档没发现可以往外读注释, 只能碰运气, 开一个解释器尝试. 看上去 getinfo 可以. 因为没有交叉引用, 只能搜索ZipInfo 这个对象. 终于看到一个方法是 comment. 不知道类型, 仍然需要自己在解释器下先 type 测试一下, 才能在程序中写下一行完整的语句.–)


2. 文档上有, 但是你不能用

我用 Ubuntu/MacOSX系统, Python 是自带的. 以为万事大吉, 实际上, 因为 Python 所有的库都是运行时装载的, 所以有些库在有些系统上是缺失的, 而文档则是所有标准安装的超集. 因此即使文档上有, 你也没法用.

这个问题对于 Java 程序员和 .Net 程序员来说是不能接受的. 对于任何一个良好设计的 SDK, 文档和实际可用的应该具有同等的覆盖面. 在 Java 中, 有一个包就是有, 没有就是没有, 绝对不会出现标准文档中提到了, 实际中却不可用的情况. 对于可选包, 用户也能理解需要下载模块. 而对于 Python, 开发人员很难理解为什么标准文档中提到了, 实际中却缺这个组件缺那个组件. 一个潜在的伤害就是, Python 的跨平台能力没那么强. 试想, 开发的机器上有一个模块, 而用户没有. 而标准文档偏偏又认为这个是一个标准组件, 那么, 在装载的时候,找不到这个组件了, 让用户根本就无从下手. 我的建议是 A. Python 应当有更好的 import 报错机制, 对于不是每台机器都安装的模块, 应当给出平台中立的更加友好的帮助信息, 而不是简单的 ImportError. B. 应当在 Python 语言中支持更加强大的内省机制, 对于系统当前可用的包, 应当有一个全局的缓存. 这样, 用户才能知道哪些可用哪些不可用, 不可用的时候怎么办. C. 对于用户来说, 只能求助于Google 或新闻组, 或者从 Python 源代码中找线索. 一个较好的办法是在 Python 源代码上 执行 make test, Python 会汇报哪些模块已经编译, 哪些模块被跳过了.

(–实例: 前几天想写个程序抓Google Reader. 认证的时候要用到 SSL. 因此找到 Python 文档, 照着例子 import urllib2, 然后直接连 Https 服务器. 出错了, 原因是没有 ssl 支持, 不能访问 https. 所有的 Python 在线文档都说, 这个是标准模块. 对呀, Python Library Reference 里面都有的模块, 怎么能有问题呢? Google 搜索也帮不了什么忙, 因为 Python 是跨平台的, 不同的平台有不同的解决方法. 所有的在线帮助只能提示到 _ssl.o 这一层. 于是, 只能翻看 Python 源代码, 在 Modules/_ssl.c 中看了一圈, 发现需要 openssl/ssl.h 等文件, 这才意识到, 需要安装 openssl 和 libssl-dev. 在 Ubuntu 上, 同样的问题还存在于 sqlite3 模块, tk 模块 和 bz2 模块. 分别需要安装 libsqlite3-dev, tk-dev 和 libbz2-dev, 再重新编译 Python 系统. 使用 make; python setup.py install 来安装 –)

3. Python 是胶水语言, 用是简单的, 模块开发是痛苦的

Python 用到一定程度以后, 一个自然的需求就是把其他语言, 特别是C语言写的库包装成 Python 库. 这个问题说复杂也不复杂, 在 Python/C Reference Manual 中也提到了所有必要的信息. 只是层次太细. Boost.Python 有更加好的实现, 不过需要对 C++ 模板很熟悉才行. 当然, Python 的模块开发的痛苦比起 JNI 复杂的 JNIEnv 对象, Lua 的 基于栈的 Push Pop 已经是大大轻松了. 相比较于 Ruby 的自动生成 makefile, 也算各有千秋. 只是模块开发设计到的技术细节太多, 要对 Python/C API 了然于胸才行. 因此我的建议是: 不要从轮子造起. 如果有这样的模块, 就用. 如果没有, 而又非要用特定功能的模块不可, 那就暂时先不要考虑用 Python. 相比较于其他更加成熟的语言, 比如 Java, Python 的可用模块还是显得少了一点. 因为 Jython 的出现, 这个情况已经大大缓解. 不过工业界历来喜欢用最稳定的东西, 所以可以想象, 多少 Web2.0 公司是为了用 Lucene 才用 Java 服务器的, 而每天又有多少新的公司投入 Java 的怀抱 :)

A little bit history

Being in the academical area for years, one of my dreaming tool is an online collaborative paper reader . You can say it’s YouTube with documents, or Digg with pdf files–name actually doesn’t matter. The ultimate goal for this system is to support collaborative document reading/organization for professors and Ph.D. students. Since we now have Ajax (more interactive than before) and Flash(as powerful as PDF), I would expect an light-wighted solution. arXiv and Citeseer do really good jobs in storing and linking all the documents, but the ultimate goal for me is to read.

On winter 2006, I expanded my ambition to a larger project: read the f source code and read the f books (Here of course the f word means fine :). I launched my domain name rtfsc.org [now redirected to Apache.org]. Our team members thought that rtfsc was easier than rtfm because we only need to deal with text information instead of PDF file. However, we set ourselves on the wrong track. It turned out that if we let the users upload and update their codes all the time, we have to implement a Subversion or even a Sourceforge. For us, an online code-reading community without code management and code search is terrible, but we don’t have that much time to finish all these ambitions. The other obstacle comes from my lacking experiences of Ajax development. Anyway, at last, we gave up. We stopped the development after Christmas. On that week, I was the person of the year 2006.

New motivation

I have been thinking about this project for nearly one year without any action. Lots of similar projects were there during this year, for example, flashpaper, edocr and scribd. But none of these are my dreaming tool. I took a retrospect about our project again and found that nobody actually wanted to do that except us because they didn’t actually understand our requirements. Their goals are usually becoming the next DocTube thing, while my goal is to have a handy system open for academical research. Also, I found some open source tools that were really inspiring. These make me interested in the project again.

Technical aspects:

1. PDF to SWF is not so that hard, there is an open source tool: PDF2SWF.

2. I thought that I can’t control the converted SWF as there is no API exposed as Flashpaper, but I was wrong. Actionscript can control it directly. What I need to do is to learn Actionscript, which is not so that hard.

3. I was thought that Flashpaper use some undocumented APIs which we could never know, but I got SWFmill today and now I can study the code of Flashpaper. [Disclaimer: I didn't say anything about how to decompile flashpaper or violate the EULA of flashpaper]

4. I thought Ajax + Flash development was hard and had a very steep learning curve, but again I was wrong. On hacking Google Finance these days, I found the Flash Ajax Integration Package, which is very handy to use for some newbie like me without any Ajax/Flash developing experiences.

Proof of concept

Here is a proof of concept product. I convert my PDF version CV to swf and then combined it to a controller I wrote based on the default controller provided in PDF2SWF. (This CV has two pages, you can proceed to next page by click the red arrow)

cv.swf

Final Word

What I need is an sophisticated viewer which can be as powerful as flashpaper can communicate with other Ajax components on that webpage. So for developers, if you find this idea interesting and you are good at Ajax/Flash, feel free to take this idea and do it, as I might not have time to do it or it will take me a long time to finish it. I desperately need an Ajax style flash-based document reader with inline comment support. If you can do thing and get your own startup based on the idea, my only request is letting me be your user.

BTW, if there was some lessons in this project, I would say, choose the handy tools before you get start.