得浏览器者得天下

网络世界争雄，谁是决定胜负的重要棋子？有人会说是内容，有人可能说是搜索引擎。也许都有道理，但在我看来，浏览器将会是争霸天下的一个重要决定因素。

为何msn.com稳坐北美以及西方极乐世界的第一，原因可能很多，但是不可否认一点就是，每一台新装了windows操作系统的机器，它的IE浏览器必然指向msn.com。这也正说明了为何现在maxthon浏览器将其首页指向自己的网站，而google更是投资给mozilla，确保firefox的首页指向google给firefox定制的网站。

第一印象的重要，不亚于一见钟情对人的冲击。

现在微软正在紧锣密鼓的制作自己新一代网络入口，live.com，而这个网站毫无疑问需要浏览器的支持。很多特殊的或者重要的功能，只有微软的浏览器才能发挥出来，这种策略在微软过去的二十多年里已经充分表露出来。如果选择了微软的网络服务，那就一定要选择微软的浏览器。

微软的死对头毫无疑问就是Firefox，它身材虽小但是力量巨大，一点点地蚕食着微软的领地，尤其它的OpenSource原则，保证了自己生存的最基本的条件。微软的那些对手，比如Sun家族，或者是Linux家族，都会很愿意接受这个强有力的伙伴。

FireFox更加咄咄逼人的是它开放的架构，任何一个开发人员都可以为它定制自己喜欢的功能，而且插件的升级非常方便。也许不远的将来，就会有特意为FireFox定制的企业应用软件，OpenSource开源降低了二次开发的难度。

当然还有很多浏览器的选择，比如KDE平台上的浏览器以及现在专注于手持系统的Opera。多样化竞争的世界才是美丽的世界，也许有些残酷，但是有选择的自由更让人心动。

这是FireFox源代码下载的地址
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/

相声与软件开发

最近比较喜欢郭德纲的相声，突然之间有些想法，尤其是听了《论相声五十年之现状》。
郭德纲有一句话很有意思，“很多别的行混不下去的，都跑来说相声了。”另外郭德纲与其他人有一个很不同的言论，就是相声一定要从小学起，基本功很重要。

其实软件开发也是如此，没有什么速成的东西，两三年成为软件架构师，半年成为游戏开发专业人员，怎么可能呢？就好比只学了三四个月的医学，就敢称自己是老中医，谁能相信这样的大夫呢？

看到不少广告上写专招数学系或者电子系搞软件开发，不知道这样的非专业是不是能搞好软件开发，我是学计算机软件的，跑到电子制造行业，企业可能会要我么？为何软件开发就与众不同呢？

很多开发人员一些基本的软件开发基础都不了解，比如操作系统、离散数学、数据库等等。可是没有这些，学习了某种高级的开发语言加上强大的软件开发工具，也可以混的很好，真是一个很好蒙的行业啊。郭德纲经常说一个比喻，某某芭蕾舞团，解散了，去市场上找一批学木匠的、炒菜的等等，来跳芭蕾，谁都会说这些人是外行。可是到了相声（或者是软件开发），大家都会觉得很正常。

看着郭德纲的相声，又发了这些牢骚，嘿嘿。

如何考核软件开发的水平呢？出几道程序代码的填空题？真是一个很值得思考的问题啊。^_^

在c++项目中使用opensource library

前两天，cleveland的开发组发来一封群信，意思是说公司的法律顾问已经研究通过了，允许在公司产品中使用boost库。

对于这件事当然是高兴加上赞成。不过也有一些个人看法。

boost号称是c++标准库的预备役，因为里面不少library的质量相当高，比如正则表达式和智能指针，还有线程库socket库等等。不过强大的武器需要操作它的人更加有能力，也就是说，如果不十分熟悉这些库的优点缺点局限性，到时候会出大问题的。

我就在工作中遇到过很搞笑的设计。一个读取配置controllogix gateway信息的dll，将底层通讯部分剥离到另一个dll中，这种设计本身没有大问题，关键是使用了COM的连接点connection point技术，但是数据却使用内存指针直接传递。我只能对设计这种方案的人举双手赞成，实在是高，真没有想到COM技术与内存直接共享都能放到一起。

当初的设计方案毫无疑问是只能启动一个dialog，这时候负责界面的dll和负责通讯的dll都活的好好的，可是总有不如意的地方，有的用户发现竟然能同时启动多个对话框，还认为这是应该的，于是我的噩梦就来了，修改这个设计方案费了我好大的劲，其实可以做的很简单，使用一个线程去进行通讯工作，去掉所有不必要的COM设计，保证稳定。

从DDE到COM技术，到现在的DotNET Platform，我都无法信任它们，能不用就不用。最根本的原因是这些库或框架的代码不开放，出现问题以后，在COM与调用代码之间就形成了无法跨越的障碍。到底是COM的局限？还是我们代码写的有问题？无法进一步跟踪下去，只能想方设法的查找MSDN或者修改COM相关的代码。我就遇到过COM延迟二十几秒的恶心问题，频繁的调用接口的初始化就会导致COM初始化的失败，大约要停止20多秒。这应该是类似于内存碎片这样的问题，就是不能频繁调用new/delete申请释放小块内存，具体原因应该是操作系统自身的毛病，可是不能修改COM方面的代码，只能想法修改自己的。

有人看过Windows2000泄漏出来的代码，里面大多数都是用c写就。也就是说，没有c++的继承多态，当然更不可能有什么COM了。主要的原因应该不难猜测，C++与COM不可控制的东西太多了，而对于操作系统来说，不可控制因素的存在是致命的。当然，对于应用软件来说，这些就不太算是问题，不过用的不熟练的，还是不如不用。（我也见过用的相当熟练的设计方案，简直是帅呆了，自叹不如啊，比如custom moniker，没听说谁用过，潘爱民的书里介绍的也是简单，但是我们一个组件里就大量的使用了这些高级的COM概念，而且设计相当稳定）

回到boost这个话题，如果大连campus有C++标准库的大牛，使用boost肯定会提高代码质量，提高开发水平。但是现状是大家对STL用的都不熟，如果加上Boost，那只能是另一个噩梦的开始。另外，boost毕竟不是标准，稳定性和向后兼容性要差一些，这对于商业软件来说，都是值得仔细考虑的地方。

我的建议是用熟STL，在熟练的基础上再去尝试Loki或者Boost，但是不要将其引入legacy project，可以把它用在一些单独组件中，将其不可预知的风险降低到最小。

这也只是想想而已，就如郭德纲说的那样，谁认识我呀。