ftofficer|张聪的blog

今天从随手翻看第七期的《程序员》，发现其中《险恶的中国互联网》一文的作者鲍志云，名字怎么看起来这么眼熟，翻到文章最后看到照片，Orz，就是他。去年他去美国之前，就坐在我附近。原来此人还有这种背景。遂将此发现告知周围的同事，某老manager云：当时我去面试他，他送我一份礼物，曰：“这是我大学时候翻译的一本书”。此书为《OOD启示录》。

这个世界不缺少牛人，缺少的是发现牛人的眼睛。嗯。

“就是要Always keep eyes and ears open，看和听周围的世界，然后有一些Action，很多事情就是这么做出来的。年轻人，大有前途。”

— 陪公司某Architecture吃饭，席间一席话，胜读十年书。

今天因为一个客户的问题，早上7点开始WebEx，只好6:20起床赶到公司。
清晨阳光不错，空气也不错。

而且美洲杯开始了，早睡早起。

本文源于byte在上面一篇blog当中回复，本来题目写成：《浏览器：Web时代的平台》，后来越来越觉得不对，然后改成了《浏览器：Web时代的用户接口》，最后写着写着，真的变成了杂谈，索性题目就改成了现在这个。

诚如byte所说，微软一定不会放弃浏览器这个市场。事实上，相信没有任何一个软件公司敢轻视浏览器，和人们从浏览器当中看到的东西：Web。

Google无疑是Web时代的一个最大的成功者，这个公司使用HTTP和HTML把自己销售到了全世界。因为Google,过去我们必须在机器上完成的工作现在几乎都可以使用Web完成，从邮件，新闻组，RSS这些传统的网络服务，到即时通讯这种传统上的富客户端系统，再到最传统的桌面办公软件和日程管理，似乎我们需要在单机上完成的很多操作，都可以在浏览器当中完成了。正如很多人所说：Google正在使用Web蚕食计算机桌面市场，需要在强劲的机器上本机完成的工作，似乎只剩下了游戏。

如果这样发展下去，通过浏览器也许可以做更加有意思的一件事情：通过浏览器架构的IDE和版本控制系统，我们甚至可以在浏览器当中写程序，编译提交，并且不在需要使用cvs/svn，一切的合作都可以在浏览器当中完成。也许更进一步，后台系统可以直接帮我们做了daily build，跑Automation测试，收集Bug Tracker，甚至直接帮我们把程序发布在托管服务器上（如果这是Web程序的话）。这种新的开发模式，相信会得到很多人的喜爱。而一旦这个系统可以完成，其背后将是庞大的开发者团队，和他们的代码，以及天然的在这个系统控制下的更多的系统。这个系统也许Google可以做到。

说起来这个idea的初步原型在一年半之前，我还在学校的时候就有尝试，只是后来临近毕业，杂事太多，慢慢的就遗忘了。我离开学校之后，msclub也把这个系统从服务器上面拿掉了。想想当时没有能够充分利用msclub这个平台真的比较失败。

我大三那年去微软参加夏令营，还有后来和微软的很多次接触都发现，微软对自己的定位很有意思：我是一个平台公司。这也是微软的聪明之处：把自己变成平台：越多的人需要依赖这个平台，微软就越能够稳定和壮大。但是“成为平台”绝对没有说说这么简单，这需要更多的应用的支持，谁来写这些应用？是开发者，事实证明微软一直在做的很多事情其实都是在取悦开发者：提供便利的IDE，提供完备的文档，提供强大的框架和大量的例程，甚至为了取悦开发者而牺牲标准（比如IE和C++/CLI当中的很多东西对开发者非常友好，但是都或多或少的造成了对标准的不兼容）。正是这些东西赢得了大量的Windows Only/IE Only的应用程序，这些程序推动了Windows平台的发展和普及，Windows平台的流行又反过来让更多的开发者加入，如此良性循环，微软才得以巩固其平台。

Google现在也在做着相同的事情：把自己变成平台。所以Google也需要拉拢开发者为他的平台开发应用程序。微软的平台是Windows和Office，那么Google的平台就是GFS和浏览器。GFS解决了大数据量的存储和处理的问题，而浏览器则提供了这个系统跟用户交互的接口。访问GFS的便利的接口Google正在一个一个的开放，即Google API，前面几篇blog当中提到的Google Safe Browsing API也是其一。然后就是浏览器。Google正在推Firefox这是众人皆知的秘密，原因也是因为Google需要一个能够控制的浏览器平台——这个当然不会是微软的IE或者苹果的Safari，而Firefox的开源属性和扩展性正符合了Google的需要，Google当然要推它。

接下来的就很明显了：决定Google和MS在Web时代的生存的，也许就是他们控制的浏览器能够有多大的可扩展性，以及他们的后台服务能够多容易的被使用了。至少就目前来说，Google似乎走在了前面。当然微软的服务器操作系统平台，以及新版本的IE，也有迎头赶上的趋势。去做后台，这个并非我等可为，但是抓住浏览器这个平台做点事情，也许会颇有前途。

一个壳子加上一坨的XUL+JS+CSS组成的。
请在地址栏输入：
chrome://browser/content/browser.xul
看看效果。

很多的功能，比如标签浏览和菜单其实都是通过XUL+JS的模式形成的，可扩展性增加的同时，速度难怪如此的慢。

一个是为了能够在切换标签的时候自动切换输入法。因为我现在有英文、中文和日文三个输入法，经常不同的标签页当中需要输入不同的语言，因为目前Firefox似乎做不到自动记住各个标签页的配置并切换输入法，所以感到不太方便（也许是我土，有谁知道有什么方法的告诉我一声）。我期望这个东西可以这样工作：我正在写space的标签页面当中，现在是中文输入法，当我切换到别的页面的时候，或者当我按下了Ctrl+D，或者用鼠标移动到地址栏的时候，自动切换成英文输入法。一旦我在一个页面上面把输入法切换成了非英文，这个输入法就可以记录下面，下次我换到这个标签页页可以自动的切换成相应的输入法。这还是很方便的。

另一个是因为VeryCD上面的资源更新。因为我经常会追一些新的动漫，想要知道一个发布页面是不是已经更新了还是比较麻烦的——VeryCD的索引页虽然有但是毕竟经常雪崩似的出一大堆更新，然后一页放不下，可能会错过很多。后来我就把这些发布页面放在收藏夹当中，然后一个个点开看，原来数据量小的时候还好搞定，后来越来越多，麻烦的一米，加上我又很懒，考虑是不是可以在我打开Firefox的时候或者点了某个菜单项的时候直接去检查所有的这些页面有没有更新，然后自动把更新的页面打开。

研究一下Firefox的Extension，看看有没有可能。第二个想起来应该不难实现。

翻看自己space的统计信息，发现了两个来自于搜索引擎的来源：

Google struct tm mktime
Baidu 超级玛丽.nes

而且排名都比较靠前，尤其是前者，帖子早上发的，现在就已经排到了google结果的第一位。这种事情在csdn和blogdriver上面都是不曾有过的。

嗯，大树底下好乘凉。

http://www.microsoft.com

看来真的如传言所说，微软已经将自己的官方网站架构在Windows Server 2008 Beta 3上面了。没准微软真的打算在这个上面投入点大精力了。

不过，Windows Server 2008 Beta 3的Server Core安装模式真的很诱人~。

昨天连同今天，仍然继续培训，每天从下午两点到晚上八点。昨天主要讲Pool Allocation（这个东西权且算是一个Pattern吧，但是我觉得算不上Design Pattern），今天下午仍然是Pool Allocation。到了晚上主要是Command模式。

Pool Allocation这个东西我觉得没有什么太值得研究的，今天讲的一些比较出名的实现（Loki，SGI STL和boost）所用的算法都很简单且有效，基本上一个可用的pool就是这样写出来的。本来这种内存当中的pool一般不太在意尽可能减少随机访问，但是前些天工作需要写过一个基于文件的pool，用来管理流过MTA的所有邮件或者HTTP Proxy的所有content，因为需要把他们存下来扫描。基于文件的原因是我们必须保持这个信息在程序crash之后的可恢复性。这个pool对于随机访问就很敏感了，这种东西的算法，也许可以总结一下。

其实这三天最大的收获在于，N本书拿过去签名，然后还有最后的一张合影。

应该是公司花了不少钱请来的，虽然据他说他和趋势一直保持着良好的关系。

今天第一天，后面还有两天，题目关于Design Patterns。第一天总体感觉不错，jjhou确实是一个文字的高手，也可能是看得多了，翻得多了，写得多了，讲得多了也就自然成了高手。旧的东西从新的人口中讲出来，往往可以有更多的认识。

今天主要讲的是一些比较简单的OO概念和几个简单的模式，讲模式从Template Method开始，引出重用的基石：延迟实现；然后从其不足引出Strategy，然后解释OO当中的delegation。这个门入的非常cool。我们也在做Design Patterns的讨论班，从Factory模式开始，结果发现非常难于入门——不太熟悉的人都在问：为什么我们要用Factory来创建对象？今天发现，结构型模式，尤其是Template Method确实是一个不错的切入点。而且jjhou也说，Factory一定程度上也是由于Template Method产生的——当算法骨架当中需要创建object的时候。

然后是Adapter。本来我一直认为Adapter非常的简单，因而从来没有深入的考虑过Adapter更深层的东西。今天jjhou的例子却让我打开了一个新看待Adapter的视角：STL的functor adapter（事后查了一下《STL源码剖析》，发现其中有讲）。其实interface不一定是纯虚基类，std::unary_function也是一种interface，考虑template meta programming，当中的typedef也是一种interface！cool。原来adapter真的无处不在。

吃过晚饭一直在讲Reference Counting，传说中的来自于More Effective C++。这本书在大二的时候浏览过一番，后来就再也没有重读（那个时候还不知道什么是Design Patterns）。现在回头再去读一下，发现确实有一些不同的收获。一个Reference Counting的东西讲了这么久是因为例子。例子应该还是来自于他的《STL源码剖析》，源于SGI STL（古老的用于写书的那个版本）当中的string实现，中间穿插有copy on write。整个讲述的过程当中思路非常好，如果思路跟的上（其实以他讲的速度基本上都可以跟得上），听起来的确有趣，和他的书一个风格，从故事开头娓娓道来，深入浅出。不过我一直在考虑这个东西用在string上面的意义。Reference Counting用在string上面的最大问题在于非透明性——尤其对于遗留下来的代码的复用：试想一个用C实现的程序需要一个char*指针，如果这个时候传入了一个用Reference Counting实现的string.c_str()得到的东西，那么十有八九会出现问题。遗留下来的C程序并不知道这个东西是不是被share了，或者他的Reference Counting是多少。有人说“你不用c代码不就行了”，没错，非常好，但是在大型项目当中几乎做不到：大型项目有很多遗留代码和无法控制的第三方库，你可以在重写和复用之间权衡，但是一旦选择了复用，想要不出问题，概率大概和南京一整天不出现车祸的几率差不多（大概<0.1%）。所以VC8的std::string已经彻底抛弃掉了Reference Counting，大概也就是因为Windows平台上如此多的遗留程序和软件造成的。

但是string的Reference Counting的问题不足以掩盖Reference Counting的价值。但是一个好的Reference Counting的代码太难写了，尤其是要保证线程安全的时候（比如CComObjectRoot和CComMultiThreadedModel）。感觉还是非侵入式的Reference Counting比较安全一点，例如shared_ptr，这个应该明天会讲。

仔细想想为什么Reference Counting + Copy on Write这么难搞定，直接原因是因为现实和理想之间的差距：因为c风格的字符串处理函数无处不在——虽然guru们建议我们不要用它们，但是那之前的历史更长。而c风格的字符串处理函数有一个假设，即字符串的二进制布局：以单字节零结尾的连续内存空间。但是string没有这个假设。至于这种对于二进制布局的放弃，确实增加了string的灵活性，但同时也增加了互操作性的难度。我感觉在现在的环境当中来看，在C++程序员对于“用const引用替换传值调用”已成为一种思维定势，并且编译器有了更强的优化能力的情况下，在string上面使用Reference Counting真的是弊大于利。Reference Counting解决的是减少复制string对象的内存分配开销，而一旦使用了Reference Counting，为了保持string的行为，修改两个共享存储的string对象当中的任何一个都必须使用Copy-on-Write。但是，当C++程序员复制一个string对象的时候，他的目的在绝大多数时候都是为了修改它（我相信对于大多数有经验的C++程序员来说，这个命题基本成立），如果这个假设成立的话，Reference Counting的作用其实并不太大。不过仍然存在着其他的可能性，例如作为类成员的string object。不过我认为这种东西不应该会是性能的瓶颈：如果人们需要频繁的拷贝一个具有string成员变量的类实例，这种设计往往就有问题，有经验的C++程序员应该会避免的。剩下的能够从string的Reference Counting当中得利的，也就是很少的一部分case了。这种时候去寻找一个用Reference Counting实现的专用版本的string，看起来似乎更加合理。

在我看来，C++从一开始就放弃对二进制和线程模型的标准化也许是一个错误（虽然这样确实让C++可以在更多的平台上发挥作用）。因为没有二进制和线程模型，C++才不得不在编译期做文章，于是才有了模板元编程和很多的编译期优化手段。但是对于强调运行期的可配制性的产品，编译期的手段很难有用武之地。这种环境当中，更加动态的，可以在运行期变化的方案更受欢迎。这么来看，介于编译型语言和脚本语言之间的方案会很有前途，比如.NET的IL+JIT。