刚才打了博客网的客服电话，说明了英文字符被过滤的问题（居然没人报过），客服人员自己试了一下，确实不能发英文。

等吧，从现在开始看多久能修好。

105.7交通台晚上7点钟有档节目叫“淳子咖啡馆”，每期都有个主题，淳子在伤感怀旧一番后放一首歌，叙述一段后继续放歌。我平时能在下班的公交车上听完这个节目的上半部分。

今天晚上听歌的时候忽然想到一个技术问题：这些直播或者非直播的音乐节目中，往往要完整的播上几首歌曲，这些节目的录音资料是仅包含主持人说话的部分呢，还是连这些完整播放的歌曲一起被重新录制进去了。比如一个小时的“咖啡馆”，主持人说话的时间加起来可能只有20分钟，剩下40分钟全是歌曲，这个1小时的节目最后存档或者未来重播的时候是保存了完整的1小时资料，还是仅仅保存主持人的部分，在重新播放的时候由电台调度当场从曲库中找歌来播。

这是个有关存储空间与执行效率的问题，就是by reference和by value的区别。如果是by value，每首被播出的歌会无数次的被复制到各个音乐节目声音资料中，浪费了大量的存储资源（经典热门歌曲可能被复制到成百上千卷的磁带中）；如果用by reference，虽然节省了存储空间，但在重播的时候需要有人在主持人话音结束的时候找到CD，定位track，再播放，太复杂了。不用说，电台一定用的是by value的做法，一来容量不是问题，二来资料的整理存档很容易。这好比做一个网页，要链接别人的一段内容，假如仅嵌入一个超链接的话，很难保证这个超链接未来还是否继续有效，与其这样不如copy & paste到自己的页面里，完全脱钩的自主管理和维护。

另外一个引起思考的问题是DJ们如何快速找到CD曲目（尤其是在直播节目中），电台内部是不是有一个可以直接供DJ使用的搜索引擎，根据歌手名、年代、曲名、歌词等搜索？？我不知道。昨天中央5套“豪门盛宴”里张路介绍了一个点球技法 － “勺子球”，让我觉得更加有趣：体育部的人如何在这么短的时间内找到了这么多“勺子球”的录像（大概有10个左右），这些录像有的来自联赛，有的来自世界杯，而且不少都上了年头。这些视频资料在电视台是如何管理、分类、标签、检索的呢？可以想到的是给每场球赛加多角度的分类，然后加入一些tag，如“乌龙球”、“误判”等供方便日后检索，但像“勺子球”这样的关键词也会被资料管理员们tagging吗？我很怀疑，难道是全靠懂球的人回忆起来的，没太可能。。。。我猜Web 2.0这些东西，放到中央台估计会被仓库管理员鄙视的。。。

Ding Feng曾经研究过Dublin Core在图书馆学中的应用，现在看至少在视频的metadata标注上还是太粗粒度了。对于球赛来说，要不就把比赛解说词用语音识别转换成文字，然后把这些文字连同录像一起保存归档，文字部分供搜索之用（以后在引用06年意大利vs澳大利亚的录像资料时，只需要输入“灵魂附体”就可以了）。

收到同事邮件，邀请我加入CSDN IBM开发者圈子。对于这个比较官方的blog，我唯一的顾虑是在选题上的谨慎，谈论的内容要会窄一些，更偏重于技术，尤其是IBM相关技术。

所以我打算同时维护两个博客（CSDN上的尚未开通），把有关技术的内容镜像到CSDN的圈子里；一些闲谈杂想仍旧放在此处。

为了简化镜像的工作量，我花了点时间考察了目前可用的blog客户端工具，这些工具可以离线的写作并自动发布到网站（多个）上而不需要用浏览器登录。blog客户端使用了一些常用的API，如Blogger API，MovableType等。

经研究，博客网（Bokee.com）支持的是Blogger API，其发布URL是http://publishblog.blogchina.com/xml-rpc，详细说明在此。

目前可以找到对bokee支持最好的免费工具是blogBuddy和Zoundry Blog Write。blogBuddy处理Bokee很顺，没有中文编码问题，它最大不足是没有WYSIWYG编辑器和多站点配置功能。Zoundry的功能很全，可偏偏无法正确支持除UTF-8以外的编码（bokee用的是GB2312），此外其发布功能的bug也很多。

图：Zoundry的帐户配置和多协议支持：

对于CSDN Blog，我还不能确信它是否支持某种特定的Blog API（搜索了一圈也没找到）。不过凭CSDN在技术上的偏执，API的事情迟早会解决。

在公司内部新闻组上看到Lotus EasySync 4.2.4 for Windows Mobile 5的Beta版在内部开始提供下载。去年底我在Dell X51上装4.2.3报错，在论坛上看到很多人报这个兼容性问题，现在支持WM5的新版本终于出来了。

基于WM5的标准开发工具是VS.NET 2005，它用新的MFC 8.0 for Device代替了老版本的MFC 3.0 for Devices。所以用老版本eVC开发的项目如果引用了MFC 3.0的类库，在移植到VS.NET 2005后就会出现编译错误。而就目前情况看，预装了Windows Mobile 5.0的Pocket PC设备其内置的MFC类库版本仍然是3.0。

从Pocket PC 2003移植到Windows Mobile 5是相当痛苦的过程，尤其对developer来说。

在这期《程序员》杂志上看到Sourceforge 5月份的最佳项目：Stellarium。Stellarium是和Google Earth反其道而行之的工具，后者是从天上往地上看，前者是从地上往天上看。

在上海看到清朗美丽的夜空太难了，城市内部汇集的光源在夜色中遮蔽了来自太空的光线。有了Stellarium可以坐在家里好好看看星空了。

星空图（缺省位置：上海）

Stellarium对中文支持有点问题，虽然有切换语言的选项但转到中文后所有文字都变成方框。

想到这个题目是因为今天读到一个在中国出差的日本员工在自己博客上写了昨晚看CCTV-5世界杯日本对澳大利亚这场比赛的一些感受。他是用日文写的，我copy下来用在线机器翻译转成了英文，读上去很不通顺，只能抓住几个动词和名词。

这个想法在晚上789路公交上进一步发展，就是如果多次在两种语言之间做机器翻译，翻译结果会一直变化（规律或无规律），还是在双向翻译次数达一定数量时，翻译出的文字内容开始收敛，并最终稳定下来，不再变化。

我做了一个小小的实验（因为实验数据很有限并且只考察了谷歌的在线翻译工具，不足以证明这一命题），摘取了新浪科技上的一篇文章中的几句话，先翻译成英文，再翻译成中文、再翻译成英文…在大概3－4次重复后，结果便固定下来，无论怎样继续，文字不在变化。当增大样本为一大段文字时，基本上5-6次后开始结果开始稳定。

我猜想在机器翻译领域这个问题一定有人研究过，只不过圈外人不知道罢了。

Dojo Toolkit是一套纯JavaScript的函数库，提供了基于JS的widget和AJAX类库。IBM目前是这个open source JavaScript 类库的支持者之一，并且已经或即将贡献部分代码给Dojo。

Dojo的widget很cool，尤其是那个FishEye，很炫。这里之所以没有直间给出FishEye demo的链接，是我想谈的另外一个问题，就是大量的JavaScript造就了许多1 page网站：除了首页外无法看到当前内容的URL，所有都是JS代码动态加载的，想copy个link发给别人也做不到。这好像是昨天那个内容隐藏的又一个解决方式。

我喜欢AJAX，但也喜欢完整、可复制、长期稳定、可以从地址推测出内容的URL。没有URL的网站和HTTP协议一样，是无状态的，如果没有cookie，所有对话都要重来。还是多给AJAX几块甜饼吧。