技术奇异点

对于词典软件来说，发音是个必需具备的基本功能，而且 dict.cn 的 Web API 提供了 MP3 格式的单词（短语）发音，所以从开始写 Dict Mac 的起，发音就被列入计划加入的功能。0.02 版完成之后，也就是从 5 月 25 日左右开始准备实现发音功能。

最初的问题是找到合适的 API，花了一个晚上，从 blog 和论坛的帖子堆里发现无数名称，逐一在 Apple 的文档里查找印证，最后终于锁定 Audio Queue Service 这个 framework。有了 framework 的确切名称后就不必再流连于 Stackoverflow 之类的网站，开始专心阅读 Apple 的文档。

花了一个晚上草草看了一下《Audio Queue Service Programming Guide》，感觉不是很好。这个 framework 功能比较强大，设计得比较灵活，相对来说也就没有提供傻瓜化的播放 API，即使是播放一个 MP3 文件也要 400 多行代码。好在这些代码在 programming guide 里都已经直接给出。但是一来我不喜欢这种 copy/paste 代码的方式，二来如果这些代码有 bug（当然 programming guide 里的代码本身有 bug 的可能性不大，但是和 Dict Mac 的 code base 集成的时候很可能引入问题），也要花不少时间解决，而且很可能要重读 programming guide 甚至查阅 API reference。

另外的问题是选择把 dict.cn 的 MP3 文件 download 到本地文件系统之后再打开文件播放的方式，还是直接播放网络的流数据的方式。从尽量减小暴露给用户的复杂度的角度说，稍稍倾向后者。但是考虑到今后还要实现本地缓存，以及尽早实现功能，还是决定先写出把 MP3 文件按照单词作为索引存储在本地文件系统的代码。花了两个晚上写好了这些代码后，第二天白天我脑子里突然冒出一个问题：OS X 会不会有现成的播放 MP3 的命令行工具？从以往的经验看，OS X 的命令行工具还是相当强大的。Google 了一下，果然有一个 afplay。这样一下子把实现发音功能的剩余工作从至少两个晚上变成了一个小时 —— 只要 fork 一个新进程运行 afplay 即可。

其实刚开始写 Dict Mac 的时候就考虑过是不是把必要的 UI 之外的其它功能都做成一个后端独立进程。最后决定当前阶段还是写成一个进程。不过 afplay 至少让发音功能成为了一个独立的进程。一开始我还在抱怨为什么 Mac OS X 不能直接提供一个播放 MP3 的傻瓜接口，其实这样的傻瓜功能应该做成工具而不是 API，像 Audio Queue Service 那样灵活的接口才值得作为 API 的形式提供。这个事情上 OS X 继承了 UNIX 的精髓，也是像 Windows 这样的不管底层功能还是傻瓜功能一股脑的做成 API 的非 UNIX 类的 OS 最缺乏的文化。

Diff 是程序员最重要的工具之一。不过，除了在 mail 里发送 patch，我很难忍受传统 diff 的字符输出。在任何系统上开发软件，第一件重要的准备工作就是寻找趁手的 GUI diff 工具。GUI diff 工具的优势在于 side-by-side 的比较方式即能显示变化的部分，又不影响对每个版本的连续阅读。Linux 上比较好的是 KDE 的 kompare，也是我见到的第一种 GUI diff 工具。因为先入为主的看到 kompare 使用曲线来联系变化的对应关系，所以任何使用空行填充或者直线来显示对应关系的 GUI diff 工具对我来说也是比较勉强的 —— 可以暂时使用，但是仍然会不断寻找替代品。

平时工作用 Perforce 管理代码，它有个自带的 GUI diff 工具 P4merge。功能很强大（而且免费，虽然 Perforce 是商业软件，但是它的 client，包括 P4v 和 P4merge 都是免费的，而且 P4merge 可以完全脱离 Perforce server 独立使用），除了普通的比较两个文件（版本）之外还可以 3-way 比较（一般用来做人工的 branch merge，分别比较 branch fork 之前的原始版本，main branch 上的修改版本，和其它 branch 上的修改版本）。和 editor 不同的是，diff 工具操作的不仅仅是 check-out 的 version，而是 version repository 里的任意版本。所以 diff 工具要想和 version control 系统配合，简单的文件操作是不够的，一个成熟的 version control 系统必须在设计中考虑如何与外部的 diff 工具协作。

从上周开始用 Git 管理 Dict Mac 的 code base。用到昨天终于感到缺省的『 git diff 』不好用（类似『 diff -u 』的输出）。简单的 Google 一下就找到了答案：

git difftool …

原本以为只有在 Linux 上才会有缺省配置好的 GUI diff 工具和 Git 协作。在 Mac 上试过发现 OS X 上已经配置好了 opendiff 可以让 Git 直接使用。OS X 的 out-of-box 用户体验确实不是只用来蒙初学者的。连 developer 的工具也能准备齐全。但我还是最习惯 P4merge。于是试着配置：

git config –global diff.tool p4merge
git config –global \
difftool.p4merge.cmd /Applications/p4merge.app/Contents/MacOS/p4merge

然后运行『 git difftool 』，P4merge 是调用起来了，但是没有内容。原来 Git 缺省不会向 diff 工具传递参数，必须写到命令行配置里：

git config –global \
“difftool.p4merge.cmd \
/Applications/p4merge.app/Contents/MacOS/p4merge \”\$LOCAL\” \”\$REMOTE\””

这里还有一个陷阱，在某些 shell 里，『 $ 』是不用加转义的。不过在 OS X 的 bash 里必须加。

把 Dict Mac 介绍给同事们之后遇到最多的回应是『怎么是 10.6 only 的？』我喜欢用最新的东西，加上在家里测试 10.5 也并不方便，所以开发的时候没多想就选了 10.6 SDK。没想到连公司同事这些 Mac 的重量级用户还有不少没升级到 10.6，于是今天中午花了一个小时把最低平台需求降到了 10.5。其间遇到了几个小问题。

第一是 NSApplication 的 delegate 在 10.5 之下没有类型，在 10.6 下则正式定义为 NSApplicationDelegate 接口。不过真正起作用的 selector 都没有变化。把 delegate 的基类从 NSObject <NSApplicationDelegate> 变成 NSObject 之后就解决了问题。第二个问题是 NSTextView 的背景色设置成 [NSColor clearColor] 在 10.6 下工作的很好，到了 10.5 下就变成了黑色，变成 [NSColor windowBackgroundColor] 才行。虽然效果相同，但是从正常思路来说我是希望让控件的背景透明，而不是让它『碰巧』和窗口同色，而且遇到那些背景色可以在运行的时候定制的窗口，非透明的控件还要多写代码来同步颜色。

上面两个问题解决之后，Dict Mac 就可以正常的用 10.5 SDK 编译了，在 OS X 10.6.2 上运行也一切正常。之后遇到的问题最离奇，程序在 OS X 10.5 上启动后就会崩溃，crash log 报告 selector [DictWindow awakeFromNib] 不存在。Google 之后发现遇到类似问题的人不少，唯一找到的 workaround 是把 [DictWindow awakeFromNib] 里的 [super awakeFromNib] 去掉（完全莫名其妙的改法，这是一个人记得刚刚升级到 Xcode 3.2 的时候并没有这个问题，然后从自己的 version control 找到当时的代码才得到的解决方案）。

降级 SDK 总会遇到一些小麻烦。也能从中看到 SDK 的每次升级都确实给开发工作减轻了不少负担，唯一遗憾的是用户们升级得没有那么快，新 SDK 的推出带来的好处要过上一段不短的时间才能让开发者受益。