丁宇 | blog

因为要跑税务局，于是邮件获得地址后，顺势想用鼠标选中这行字复制一下，以便在Google Map中看看怎么走。当我鼠标划过的一刹那，发现文字旁边出现一行虚线框－难不成Apple Mail连地址都能识别出来？电话、邮编识别都不稀奇，毕竟数字格式都比较规则，可地址也行？

点了一下，结果：

再按了“显示地图……”

整个过程之轻松惬意出乎意料！就这么一个小细节，却让人觉得很爽，细节决定成败啊！

09年10月16日：我把文章稍微改了一下，讽刺不能解决问题，还是多侧重一些好的设计吧。

有人写了一篇非常详尽且图文并茂的博客，介绍了25个常见的IE6的bug及其解决方法。如果你还在IE6的泥海中挣扎，不妨看看这篇"Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs"。

今天云天问了我一个问题，可把我难住了：Apple为什么把窗口控制按钮（关闭、缩放和最小化）放在左上角？

说实话我还真不知道。我不妨斗胆猜一下为什么Windows的在右上角：

在Apple的第一款带有GUI的电脑Lisa诞生后，Jobs曾经请Gates过来参观。Gates被优雅的Lisa深深震撼，回去闷头搞Windows。在Lisa诞生2年、Mac诞生1年后，Windows 1.0终于发布了。根据“硅谷海盗（Pirates of Silicon Valley）”一片的记载，Jobs在得知这个消息后对Gates大发雷霆，认为他剽窃了自己的MacOS的界面。虽然Gates大叔说出了那句著名的“我想应该说是，我们都住在一位名叫‘施乐’的富有邻居旁边，你闯进去偷电视，却发现我先到一步，然后还说：‘不，这不公平，原来是我要偷的！’”，但从片中Gates的反应来看，他多少还是有些内疚的。因此，学习和借鉴MacOS中的大部分设计、修改一些无关紧要的部分，也不失为避免内疚（以及专利纠纷）的一种方法。

这当然是我的胡乱猜测，有深喑这段历史并清楚上面问题答案的朋友不妨出来给我们解解惑。

时隔八年，Haiku团队终于发布了Haiku的第一个版本。虽然只是个alpha，但已经足够让我这个BeOS的爱好者小激动一下了。

老玩家应该对BeOS不陌生。这是由一群前Apple工程师所开发的一款商业操作系统，在上世纪90年代中后期，BeOS是当时最好的桌面操作系统之一（我觉得唯一能和它媲美的是Jobs的NextStep，可惜无缘一用）。BeOS命运多牟，2001年被Palm收购后就再无动静（再次bs一把Palm）。

我是从2000年的BeOS R5开始接触这个系统的，最初的目的是想寻找一款能够替代Windows的桌面系统，结果被BeOS那清新的界面和飞一般的速度所吸引。但这个系统上软件十分匮乏，中文支持也很有限，所以不得不放弃。后来陆续用过包括Zeta在内的几个BeOS衍生版，都由于前述原因作罢。这之后我成功地转移到Mac上来，因为这个软硬件系统十分地优雅好用，我也就不再像以前一样花很多精力在Haiku这样的系统上了。

老实说，在目前这样的情况下，基本上很难再出现一款新的、真正可用的桌面操作系统了。一是因为操作系统研发的复杂度已经是今非昔比，二是用户习惯已经广泛形成，三是上下游产业也已稳固。小公司没钱没实力去从头搞一个高质量的系统，大公司即使能搞出来用户也不一定愿意用。所以，虽然我最近数年都在关注OSNews，希望能够出现一个好用的第三方系统，但我越来越清楚这实际上已经是不可能的事了。

继续说Haiku。

启动和关机

开关机的速度一直是BeOS引以为豪的地方，Haiku当然也不例外。我给虚拟机分配了512M内存和一个CPU（2.3Ghz的Core 2 Duo），Haiku启动不会超过10秒。关机则更快，在没有程序运行的情况下，大概3-4秒就关了。不知道全新安装的Snow Leopard会有多快－虽然这两者并没有太大的可比性。

后面所有图片点击放大。

软件支持

这个版本的系统很小，压缩包只有160M出头，解开以后也不到600M，开发者已经明确指出说这个版本主要是为了开发测试，而不会集成很多的应用程序，不过实际上基本的东西已经有了，比如音视频播放器（曾经是BeOS的强项）、文本编辑器、邮件系统（BeOS的特色之一）和PDF阅读工具等等。

但基本上你就只能获得这些软件了，由于用户量太小，极少有人原意为BeOS/Haiku开发软件，BeOS最大的软件站点BeBits上的软件基本上都老得可以，新程序几乎没有。唯一值得庆幸的是，Haiku团队成功地把Firefox移植过来，虽然只是Firefox 2，但应付一般的浏览是没问题的。如果你愿意折腾的话，你也可以在浏览器上云一把，把写代码、编文档和发邮件这样的工作通通拿到浏览器上来，这样就不会觉得原生软件少了……

中文支持

这还用说嘛，现阶段Haiku的中文支持基本等于没有。虽然官方于2006年就声称拿到了作者捐献的BeCJK的源代码，并提到说已经开始寻找合适的中文字体，甚至期待“在将来能输入和显示中文”，但实际上几乎不可用。

默认安装的系统中貌似是没有中文字体的，我拷贝了雅黑进去，然后在Firefox里面设置一下，奇怪的是除了xampp首页的中文可以显示，其它页都是乱码，搞不明白是什么原因，也没那么多时间去搞。

时间的关系，我没怎么深入的赏玩Haiku。不知我的读者们有人喜欢这些系统吗？

读了老鱼的《前后端分离开发模式初体验》，暂时没有和他见面详聊的机会，所以就把读后感和想法写在这里。

08年春天我离开支付宝之前，曾和资金线的同事（主要是夏天）讨论过这种做法，即把view的部分完全交给前端开发，java程序员只需给出逻辑、接口、变量和数据。双方以接口文档为工作基础，用统一的开发平台（Eclipse＋SVN）来协调工作。另一方面，前端开发则不断地将Velocity/HTML封装成一个个的helpers，从而提高代码的可重用性，并以此降低编码难度（关于封装helpers这点，我曾在一次技术分享中谈过，不知老鱼是否还有印象）。我给这套方案起的名字是“开往中国的慢船”，在《为什么网页设计不应强调分工 2》一文中，我简要的介绍过。

从支付宝的情况来看，这种做法有比较大的可行性，既可以提高开发效率，又能把双方的工作边界定义的比较清楚。不过我当时即将离职，也就没有推动下去。这次看到老鱼的项目实践，很高兴。对于他说的那4点问题，我觉得：

1. 不知道这个白板究竟“白”到了什么程度？做html的时候运行调试ajax了吗？有没有和开发约定好往返的数据内容及格式？
2. 这个问题确实比较头疼，因为系分阶段根本不可能细化到变量名都定下来的程度。可能的解决办法有三个：一是考虑周全所有的流程分支，不能遗漏；二是管后台程序员要需要的数据，而不是被他的数据追着跑。比如这篇Creating Reusable Elements with requestAction所介绍的方法，就是让view在程序中占有了一个比较重要的位置（有点像web service）；三是逐渐把复杂的逻辑从view中提出来，返回到后台去，简言之让view变得更单纯一些。我觉得如果有必要的话，甚至可以引入“数据源”（datasource）的概念，把数据统一交到数据源中去处理，然后再让数据源和view交互。可以参考SproutCore的做法。
3. 问题C和D基本上基本上可以靠沟通和协调解决。另外对于问题D，或许前端开发可以考虑转到Eclipse上来。

简言之，“开往中国的慢船”这套方案的核心之一，就是把view让前端开发来创建和管理，在项目的前期及中期，前端开发就已经利用test fixtures创建出可以正常运行、几近真实、但又只包含view的应用程序来。

注：“开往中国的慢船”来自于村上春树的同名作品。我发起的项目或技术方案都以村上的作品作为代号，个人习惯。