Category: 原《冷月无声》

差点忘记昨天是向雷锋同志学习的纪念日。

42年了，这些离开雷锋的日子。

树立了一个令大多数人无法企及的道德高标，而结果却是这四十多年来社会道德水平的不断下降。

我始终坚持认为，靠道德高标是不行的，只有作为最低强制标准的法律，才有可能是最大多数人的保障。

刚从95927那里看一个好消息是：山西煤矿企业领导必须每个月下矿井。这个想法我去年也提过，现在要真能付诸实施那就太好了。

BTW：关于刺猬的一个八卦明天再说，今天先预告一下。

这几天都八技术，没8挂。

其实也没什么好8的。想想还好家里没有宽带，我现在一上网就没完没了的。经常在公司里不知不觉就下班了，却没做到什么事。检讨的结果就是全浪费在网上了。

每天到公司开机的第一件事就是刷新Sage，看看订阅的RSS有什么新内容。然后一个个看过去，特别是KESO的昨日新闻，把那些链接点过去就能看上半天。

这些都看完以后就开始焦虑了，因为没有新的信息可看了。开始干手头的工作，但总是做一段时间，又会手痒去刷新一下，一看到有新的信息到来，就两眼放光，口水横流……唔，夸张了一点。

没信息可看还只是这种焦虑症的一个方面，另一个方面是信息太多。特别时当Sage刷出很多新信息，还没来得及一一看过来时，MSN和QQ上的消息又铺天盖地而来，这时就手忙脚乱，不知道先看什么才好，焦虑ing。

等把这些也看完了，差不多也下班了。

这种毛病估计除非断网，否则无药可治。

昨天令狐对我的《[技术贴]关于Rich Client的一点个人看法》提了一点意见，特别是指出了其中的一些错误，我已经在那里改正，非常感谢。

后来我们就XUL（Gecko）和RIA（Flex）两项技术作了一番比较，因MS的技术依赖于.net平台，故Smart Client不在讨论之列。以下为讨论内容，引用部分为令狐语：

>不过Gecko这个也还不错的，它的思路跟Flex不是很一样。XUL关注的是前端，后端只要是Web Service就行。据我所知Flex后端的服务器是专用的。

是的，flex需要一个即时编译后端，用于在第一次访问时把服务端的MXML和ActionScript编译成FLASH。在这点上（指不需要专用的服务端）XUL的确不错，但必须承认，XUL在客户端能做的事远远少于RIA，还是很多事要靠服务端来做。

>这一点你说错了。支持XUL的实际上是Gecko这样一个渲染器。像FireFox这个软件本身就是利用XUL作出来的。XUL在客户端可以做事情的，不过不是通过http协议，而是一个专用的chrome协议，通过这个协议，XUL可以访问本地资源。

 这个协议我知道，它可以访问本地资源吗？

>可以的，你想想FireFox不是可以读取本地配置文件么。呵呵。不过chrome协议需要配置和安装RDF文件，这个比较麻烦（就像Fx的扩展那样，不装是不能用的）。

还有就是对图形/媒体的支持，XUL跟FLASH相比还是有差距的吧。

>对媒体的支持毫无疑问是Flash强了。

总的来说，XUL的复杂性还是大些，并且它不能通过装插件之类的方式使别的浏览器支持，这也是个很大的问题。

>XUL其实一方面是可以做Rich Client，另一方面，它可以做像FireFox这样的桌面程序。这一目标跟Avalon倒是比较接近。

要把GECKO集成到LINUX上去

>呵呵，好像现在是有人在做这事啊。准备把Gecko集成到Gnome里（两个项目名字倒有点像 -_-||）。

用Delphi实现动态代理(2)：设计说明

接下去的工作比较麻烦了，单就一个Remoting就不好处理，主要是ServerSide没有一个好的机制，除非跟Container一起做。工作量就大了。

BTW：本来想发在CSDN的，结果发现CSDN不支持PNG格式，而且今天居然还当掉了。

上午跟516就这个问题聊了一会，觉得有点用，就整理记录一下吧。

我觉得Rich Client的目标是要在Thin Client和Fat Client之间找到一个中间点。今年的《程序员》第2期有一个RIA（这里用的是广义的RIA概念，包括几乎所有RC技术）的专题讨论得已经比较全面了。

现在主要的RC技术有几个派别：

• Microsoft的基于.net技术的所谓Smart Client，秉承MS一贯的概念混乱的传统，Avalon/XAML大概也可以网罗在其中。
• Macromedia基于Flash的RIA，主要是如Laszlo 及 Macromedia Flex这样的实现。
• Mozilla的基于Gecko浏览器核心的XUL，目前好像只有FireFox浏览器支持FireFox本身就是用XUL写的一个在Gecko上运行的应用（多谢令狐指正）。
• Java的Applet/WebStart，Applet已经是赶不上趟，WebStart大概也差不多了。
• 最后是基于已有技术的实现，主要是用DHTML实现的，如Bindows、Isomorphics。

以上主流的RC技术（前三个）中有一些共同点：

以XML为核心，基本上就是用XML来代替Thin Client中HTML的地位，辅以少量的客户端脚本，通过SOAP/WebService与服务端交互，提供比Thin Client更多的功能，以及接近于Fat Client的更好的用户体验，并保留Thin Client易于发布等优点。

所以说它是Thin Client与Fat Client之间的一个中间点。

以目前的情况来看，最有希望的是前两项技术，基本上都可以达到上述兼备Thin Client/Fat Client优点的程度。XUL虽然比那二者要轻量得多，但功能相对来说也差得多，还是比较接近于Thin Client。Java技术则是比较接近于Fat Client，而且开发复杂性较高。至于DHTML，本质上还是完全的Think Client，功能都是靠大量的客户端脚本来模拟，在客户端占用资源过多，功能略差，而且存在浏览器兼容问题，个人不看好它。

谈到RIA时，516说他“好不容易和公司的平面设计师想出个flash/java的方案，想不到人家已经做到这个地步了”。

所以说，及时了解国外最新技术的动向是很重要的。

这个日倒是形象生动：3.3就像一对耳朵。

《人体漫游》中介绍过，耳朵里的听骨是人体中最小的一块骨头。

今年春节晚会上最值得了一看的节目就是《千手观音》。不过节目结束后那个白痴主持人还特地说了一下她们是聋哑人，她很感动云云。感觉就像刚吃完一顿盛宴后，又端来的一碗漂着死苍蝇的涮锅水汤一样。春晚就是酱紫被糟蹋鸟。

据说全国的聋哑人中，有相当一部分是因为在幼儿时期不当使用抗生素所致。去年七月一日，国家将所有抗生素列入处方药。不幸的是，那些对儿童不当使用抗生素的通常不是儿童的父母，而是医生。以药养医式的医疗产业化如何能够避免以后再出现此类悲剧？

中午吃完饭回来，等电梯时人多，有个老外很厚道地让我们一帮人先了，他自己在外面等下一趟。

在电梯里除了我们公司的人以外，还有几个是楼上别的公司的。他们在谈到那个老外时，开玩笑说刚才应该问问那个老外：

Are you going down?

偶就在一边很猥琐地笑乐。

最近在学习Python。不过因为Python2.3不支持GB2312编码，而我的程序需要用到中文，只好用了标准的UTF-8编码。

用了一个月也没有发现什么问题，不过周一时，当我需要通过minidom修改一个XML文件中的TextNode里的中文文本时，在保存时就会出错。查来查去找不到问题所在，令狐说Python有一个SIG(特别兴趣小组)专门处理XML的，有一个PyXML。于是我又下载了这个东东装上，但是还是有问题。

不过倒发现这个PyXML里面带了一个XPath的实现，简直是太好了，有这个东东我可以省很多代码。

因为正则表达式处理的需要，我要先把原始字符串从GB码转成UTF-8：

content = unicode( content, "mbcs" )
content = codecs.getencoder( "utf-8" )( content )[0]

这样的串在内部是以UTF-8编码的ASCII串存在的。当写入XML的TextNode时，就会把它当作ASCII编码转成UNICODE，因为它原来已经是UTF-8编码的，这样在XML保存时，就会再进行一次ASCII到UTF-8的转换，因为UTF-8的代码范围超过ASCII的范围，所以被当作错误ASCII码导致异常。

解决的办法也很简单，就是在写入XML的TextNode时，把要写入的内容指定为UTF-8编码的UNICODE：

node.replaceChild( doc.createTextNode( unicode( newtext, "utf-8" ) ), node.firstChild )

当然，保存为XML文件时也要注意，不能直接以ASCII文件的方式保存，而要指定成UTF-8编码的文件，方法如下这样通过codecs：

def saveToFile( file_name, content ) :
    f = codecs.open( file_name, "w", "utf-8" )
    f.write( content )
    f.close( )

最后，如果要保存前面那个UTF-8编码的ASCII串content，同样需要转换为UTF-8的UNICODE才行：

saveToFile( "content.htm", unicode( content, "utf-8" ) )

更多关于Python中用UNICODE处理中文的技术细节，参考令狐推荐的这篇《[Python学习]Unicode及编码处理心得》

八卦消息报道：信息产业部于2月23日下午3时终于出台了中国高清碟机行业目前惟一的指导性标准：《高密度激光视盘系统技术规范》，确定了张宝全所代表的EVD阵营在此次标准大战中，获得了胜利。

在DVD的时代，因为专利费的问题，我们已经吃了很大的亏，这一次是一个机会，无论如何不能让日本鬼子再次占到领先地位。

但是……

>据阜国数字副总裁刘丹介绍，早在1月10日，阜国就破解了凯诚高清的HDV算法实际上是Divx技术只修改了8个字节的而来。

不知道是不是真的。如果是真的，那么HDV的竞争者EVD和HVD又是什么样的内幕，就不得而知了。也还好这次获胜的不是HDV。

张宝全是个精明的投资人：

“谁也别指望地产能一辈子赚钱，但EVD却能。因为我投资的是标准。”

他知道，只要垄断了高清碟机的标准，他不用生产就可以坐地收钱，比做房地产还爽。所以当信产部对该标准的出台拖拖拉拉时，他不惜以状告信产部“不作为”相威胁。另一方面，他也借此得到相当广泛的支持，搞得信产部跟中国足协差不多了，甚至还不如，简直就像是卖国贼。

张宝全果然很强。

关于不作为的事，我想到上周末的《七分之一》，其中就说到东北某镇民政部门工作人员，因为没有及时行使法定的救助义务，导致一个流浪人员死亡，被当地检察机关以“不作为”起诉。虽然最后他被免于刑事处罚，但他想不通：

罪犯都是干了坏事才会被检察机关起诉，什么都没干怎么也会成了被告？

信产部这次被张宝全告也是如此。

作为政府机构/公务员，什么都不干也是犯罪。因为你们在花着纳税人的钱。

当我们的政府机构/公务员都有这样的意识的时候，那才会是人民幸福的时候。

在《一句话八卦》的回复里，色色说：

希望散伙后，可以找到各自的生活重点！～

所以我还是回头搞技术吧。^O^

技术贴：

用Delphi实现动态代理(1)：概述