Ling Zhang's Blog

先是Koders，然后是Krugle，现在是Google Code Search，程序员们要越来越开心了。其实借助搜索引擎找sample、写代码，很多人很早就开始用了，代码搜索把涉足的领地从社区论坛、新闻组转移到了CVS/SVN上。代码查询加速了知识传播，促进代码共享，但同时也带来了软件版权License的问题，这对每个商业软件公司都是一个敏感地带：程序员频繁的从网上copy代码到产品中，对商业软件（包括开源软件的clean development）来说是严重的隐患。

应该很快有人制造开发各类主流IDE（Eclipse，VS等）上插件工具，利用Web services集成代码搜索功能，作为“Code Assist”, "auto-complete"等代码辅助工具的高级特性了。

对一些特定的商品大部分普通老百姓也许永远也搞不清楚其价值与价格的关系，原因很简单，信息不对称。下面就是一些我自己一直没有搞太懂的商品，列举一下：

1. 阳澄湖的大闸蟹。我或许从来没有吃过正宗的阳澄湖蟹，因为事实上几乎没有可靠、定量的物理方法去判断一只蟹是原装蟹还是泡过阳澄湖水的洗澡蟹。吃蟹，成了情感消费；

2. 七浦路（被群众亲切的称为"Cheap Road"）的衣服。前天去了趟七浦路，市中心的位置、城乡接合部的风貌。在血光冲天的七浦路，一刀下去砍在脖子还是脚跟，学问很大：两军交锋，勇者胜；

3. 装修与建材。这是一个公认的水最深的消费领域之一，不是一般深，是相当的深；

4. 旅游景点的小商品。我去年在九寨沟买了一条很漂亮的围裙，结果没过多久就在上海看到了一摸一样的款式。我怀疑全国旅游景点的小商品都是从浙江义乌这样的小商品集散地进的货。几毛钱的东西几块、几十甚至几百的忽悠群众。

还有很多这样的例子，大家来补充:)

本周一刚放出的VMWare Converter Tool又向前迈进了一步：它可以把一台物理机器转换成一个virtual machine，重新部署到其他VM环境中去。我对VMWare下两步的期望包括：

1. 把一个VM转换成一台物理机器，实现测试环境到生产环境的快速转换；

2. 把一个“活”的VM备份下来，从数据角度看，不仅仅是文件系统，还包括内存snapshot、磁盘交换数据、寄存器等等，完完整整的把一个运行中的系统镜像到另外一个系统中去，像休眠和苏醒一样。调试，性能分析、负载均衡等多个应用都可能是受益者。

Virtualization是个越来越热门的话题，当然还有来自IBM的virtualization技术与相关产品（IBM Virtualization）。

利用假日空闲整理老物品，翻出了大学里用过的爱华收录机、磁带、一堆1.44寸软盘和光盘。这两盘带子至少有超过15年的历史了，也是我很喜欢的两张专辑。装了两节电池试听了一下，声音居然还挺清楚的。

听说Google Calendar出了本地化版本，出于对ajax localization实现手段的好奇，我读了一下它的JavaScritp代码，发现了蛮有趣的几个本地化语言翻译例子。

获取Google Calendar的JavaScript的方法很简单，"View Source"后定位到.js文件并下载即可（不能用download manager之类下载软件，因为calendar的JS文件与cookie绑定，只有认证后才可获得）。Calendar现在的JS文件从文件名上看像是动态生成的，比如叫“20060927154334doozercompiled__zh_cn.js”(在日历“设置”里切换语言，分别得到多份本地化JavaScript代码)。 这个JavaScript文件不小，所有的本地化消息都保存在里面，用类似Java语言里“\uxxxx”方式对非拉丁字符进行编码，无法直接查看。可以使用JDK自带的native2ascii.exe工具，执行"native2ascii -reverse source.js target.js"把文件中的字符编码转换成可显示的字符串。

下面是在文件里找到的几处翻译：

1. 英文：“e.g., Dinner with Michael 7pm tomorrow”

繁中：“例如：明晚 7 時與小李晚餐”

简中：“例如，明天晚上 7 点同王平一起吃饭”

2. 英文：“e.g., Breakfast at Tiffany's”

繁中：“例如，永和豆漿早餐”

简中：“例如，在蒂凡尼早餐”

3. 英文：“e.g., 7pm Dinner at Pancho's”

繁中：“例如，晚上 7 時在福華飯店晚宴”

简中：“例如，晚上 7 点在必胜客晚餐”

大致可以看出Google基本采用传统方式翻译语言包，即首先产生英文包，然后分发到各译员手中分别翻译，各语言的翻译员单独工作，所以就有了对餐厅翻译的繁、简中文差异问题。繁体中文的翻译比较一致，无论早餐、晚餐，地点都换成了台湾民众熟悉的品牌（“福华饭店”我猜是台北比较著名的一个餐厅）；简体中文翻译比较有趣，早餐没换地方，估计翻译的人认为蒂凡尼早餐应该是common sense（其实并不是这样），而Pancho对国人太陌生，就换成了“必胜客”，呵呵。为什么不用“全聚德烤鸭”呢，本地化却本地化出了一个洋玩意，合理的解释大概是全球化的强劲已经削弱了本地化的特征，过度的本地化(over localization)反而不入时、不与时俱进。反映出的另外一个问题是国内没有知名的早餐连锁店。上海有“新亚大包”，估计北京人不了解；北京本地的早点品牌上海人不清楚，依我看，还不如也用“永和豆浆”，容易达成共识。

至于“小李”和“王平”的差异应该说是翻译彼此没有直接沟通造成的（虽然是在同一个大文化背景下），比较正常。不过下面这段有关数量级的本地化，繁中和简中却完全一致：

“var tn={"零":0,"〇":0,"零":0,"壹":1,"一":1,"弌":1,"貳":2,"贰":2,"二":2,"弍":2,"兩":2,"两":2,"叄":3,"叁":3,"三":3,"弎":3,"參":3,"参":3,"肆":4,"四":4,"伍":5,"五":5,"陸":6,"六":6,"柒":7,"七":7,"捌":8,"八":8,"玖":9,"九":9,"拾":10,"十":10,"什":10,"念":20,"貳拾":20,"廿":20,"卄":20,"二十":20,"叄拾":30,"卅":30,"三十":30,"肆拾"
:40,"卌":40,"四十":40,"佰":100,"百":100,"仟":1000,"千":1000,"萬":10000,"万":10000,"百萬":1000000,"億":100000000,"京":1000000000,"吉":1000000000,"垓":1000000000000,"太":1000000000000,"兆":1000000000000,"拍":1000000000000000,"艾":1000000000000000000,"泽":1.0E21,"皆":1.0E21,"尧":1.0E24,"佑":1.0E24,"分":0.1,"厘":0.01,"釐":0.01,"毫":0.0010,"毛":0.0010,"微":1.0E-6,"塵":1.0E-9,"奈"
:1.0E-9,"纳":1.0E-9,"漠":1.0E-12,"皮":1.0E-12”

说实话，上面的变量定义的确厉害，极有可能是通过辞海查出来的。这又是一个over localization的例子，有多少中国人知道"拍"、"皆"、"尧"呢。从翻译流程上看，这些变量的翻译是简、繁双方通过气以后达成共识双方共用的。

IBM今天正式对外发布新的专利政策，包括通过技术社区开放式审核，提高专利质量；放弃对特定商业方法的专利申请等具体措施。

"...avoid filings that cloak authorship under the name of an individual or dummy company.."

"..will publish its patent filings on the Web for public review.." 

"..so-called business methods alone...without technical specifics...should not be patentable." 

"..intended as a step toward improving the quality of patents issued in general.." 

全文：Hoping to Be a Model, I.B.M. Will Put Its Patent Filings Online

又到了每年的吃蟹季节。周末在菜场买了8只大闸蟹（雄），每斤27块钱，虽不是阳澄湖的，味道也还不错。这种普通蟹价格便宜，吃起来没有心理负担，又免去了别人问你今年吃过大闸蟹没有的尴尬，同时满足了物质上和精神上的需求。

ICU是实现Unicode标准最好的开源类库（没有“之一”），目前有ICU4C和ICU4J两个主要版本。IBM作为ICU最重要的支持力量，为它多年的发展做了很大贡献。坦白说，在设计新的编程语言的时候，internationalization往往被放在相当次要的位置，被人忽略。即使像Ruby这种由日本人发明的语言，其国际化支持也十分有限（不得不承认，掌握、精通Unicode是很挑战的工作，而且需要相当的耐心与毅力）。

既然有了ICU这么好的实现，在为各类新兴语言打国际化补丁的时候自然成为最重要的参考，由此可以派生出ICU4A-Z来。

我在Krugle里输入"ICU" 查了一下，发现了针对Ruby和Python语言实现的ICU扩展：icu4r和PyICU。现在脚本语言这么多、这么热，新的ICU4?扩展随时可能出现。假如，我是说假如，JVM被越来越多的用来运行这些脚本语言，是不是有可能简化这样的扩展，充分利用JVM上可能提供的ICU服务做一层简化的映射层，实现脚本语言的globalization。当需要要添加新的脚本语言支持时，根据contract写一个特定的映射库放到JVM上跑就好了。不过说说简单，该怎么实现，没想过。

好消息是，更多的人开始重视国际化，这是新兴脚本语言的机会，也是ICU的机会。

Code Review就是通过审查代码，发现代码中可能存在的问题并给予纠正，这些问题可能包括设计上的、实现上的或者编程风格等多方面。目前做code review一是靠人读代码，二是借助于一些工具。人工阅读效率慢，但有深度，可以解决设计上的问题；工具利用模式匹配做静态分析找到不合适函数调用，速度快但缺乏context无法进行深层分析。目前Rational的“Code Review"插件提供了上百条规则对Java代码进行分析。

有关人工review和机器review的关系，可以讨论好几天。两者相同之处都是发现问题，不同之处是人工review侧重内在逻辑和实现方法，避免框架性质的错误（宏观＋部分微观）；机器review关注细节、可重现，对于典型错误的处理很有帮助（微观）。

我喜欢用现实生活的例子来解释技术，尤其是在从去年build了装修的domain knowledge后。基本上可以说，人工review好比房屋设计、机器review好比选材。选材很重要，装修过的人都知道开关选“西蒙”、“梅兰日兰”，水管选“皮尔萨”、龙头选“高仪”，水槽选“皇冠”、“弗兰卡”、水泥选“象"牌、电线选“熊猫“、刷子选“大师”...“没有好材，再好的戏也出不来”。选材容易之处在于从不知道变成知道门槛很低，久而久之就会慢慢熟起来，变得有经验，象我现在这样。设计则不然，就是同一套房子，两次设计也是会有差别，而且没法定量评价 - 人对美与和谐的追求无止境。出好的设计需要时间和经验磨练，与之相关的知识的传递比起checklist形式的静态分析规则更难。同样，没有好的设计（譬如在马桶对面的墙上镶一面镜子会怎么样？这是装修里常见的一个bad practice），再好的材料堆砌在一起也是无用的。

没有经过静态分析的程序可能跑起来不错，而实际上可能像一块奶酪一样，满身是漏洞，问题一出现就很严重而且直接面对问题的是可能是最终用户；没有经过人工review的代码跑起来也可能不错，只是潜在的问题，如性能、扩展性能会在需求变更的时候显现出来，直接面对麻烦的可能是程序员。

上周面试实习生的时候，我问了一个问题，.NET平台上存在多种语言，如果你来设计一个静态分析工具的话，该怎么做，需要考虑哪些因素？（参考：FxCop） 其实现在的Java也开始支持其他脚本语言，为了适应JVM之上的多种语言，未来基于Java平台的代码分析工具也会从源代码转向bytecode的分析，那是JVM唯一能听懂的语言。

大家都说苹果的东西好，可我觉得iTunes做的很差，难用程度可以和索尼的SonicStage媲美（SS 4.0比iTunes还好用点）。好多人说IBM的软件难用，我看iTunes易用性比WebSphere、DB2差很多 - 想想看，iTunes可是为最普通的用户设计的。

iTunes的问题在于没有按正常人的思维设计软件。iPod连上后，很自然就是从磁盘里拖文件往iPod图标里放，不灵；然后尝试“曲库”，“导入”，各种模式切换来切换去，不知它想干什么。这类灌歌软件最怕有中间状态：从source转到用户不知道的中间状态，再转到target设备上，加上很多选项、对话框设计的一塌糊涂，简直是场噩梦。

我以前说给电视机频道重新排序需要理工科本科学历，而学会从iTunes上导入音乐到iPod上需要计算机科学硕士以上文凭。我真不知道其他iPod用户花了多少时间才能把CD和硬盘上的mp3成功导进来的。以讹传讹害死人。

苹果和索尼这两家出产最优秀硬件的公司在软件（至少是iTunes和SonicStage）上表现令人失望。