ftofficer|张聪的blog

既然有人要看，那就贴上来吧。

一如既往地不上相，竟然还把眼睛闭上了。

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

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

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

看起来不错。

http://kupu.oscom.org

What is Kupu?

Kupu is a ‘document-centric’ open source
client-side editor for Mozilla, Netscape and Internet Explorer.
Inspired by Maik Jablonski’s Epoz editor, it was written by Paul
Everitt, Guido Wesdorp and Philipp von Weitershausen (and several other
contributors, for a complete list refer to the CREDITS.txt file) to improve the JavaScript code
and architecture, pluggability, standards support, support for
other webservers than Zope (which was the original target platform
for Epoz), configurability and a lot of other issues.

一个教程：
Rich Web Text Editing with Kupu
教程的作者还是个生物学家。

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

今天第一天，后面还有两天，题目关于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。

First OpenOffice virus emerges

技术没什么新意，也许可以看作是宏病毒思想在OpenOffice上面的移植。而且作者也似乎不打算搞破坏——毕竟OpenOffice用户这么少，搞破坏也没什么意义，偷也偷不来什么。但是这个消息这也许可以让很多信奉“抛弃Microsoft的产品就是换取安全”的人们仔细考虑考虑自己的信仰了。不过这个问题是谁之过？在宏病毒已经肆虐了N年之后，OpenOffice还允许脚本来访问宿主的文件系统，所以这个东西才可以放一些别的文件在系统当中以便实现传染的功能，这难道不是一个安全漏洞么？不过如果换一个说法：OpenOffice的StarBasic脚本支持将当前的文件转换成你所需要的格式并存储在磁盘上，这是不是又是一个很cool的feature呢？

进而联想到在Linux新闻组当中经常可见的批判Windows的文章当中，总是说Linux比Windows安全，因为Linux下面没有病毒。对于这种文章我只能看看就算了——在我看来，Linux下面没有病毒的唯一原因是大家不想写Linux下面的病毒而已，根本原因也许是就是在实际应用中的广泛程度了——写Linux下面的病毒除了会让你身败名裂之外得不到什么太大的好处，毕竟用这个系统的人太少。如果Linux到了和Windows一样广泛的被使用的时候，也许就是遍地都是Linux的病毒了。我还是一贯的态度：如果用户是一个小白，当Linux到了他的手里，不见得比Windows更安全。

安全是一个有很多事情可以做的系统工程。嗯。

Web2.0盈利模式逐渐清晰 互联网巨头热捧社区

虽然很多人在骂周鸿伟，说他先做流氓再做警察云云。不过不能不承认它是对中国的互联网的脉号得最清楚的人之一，此人最大的优势了解怎么搞定小白。其实口碑营销也不是他的创新，最有名的口碑营销就是Google刚起来的那阵子，完全靠口口相传的宣传。更近一点的例子就是kaspersky和360两个东西了，不过两个东西之间还有很多的不一样：kaspersky靠的是其自身的质量和“以用户安全为本”的口号，逐渐赢得信任并且蔓延开来；而360似乎更像一个典型的“营销”方式，我不知道是不是那帮家伙真的去找了很多的网络写手在各种社区里面做宣传，但是似乎真的是一夜之间很多地方都开始推荐360，然后很多人就开始跟着起哄，于是很多没用过的先入为主地认为这个东西不错，就算有点什么乱七八糟的毛病大家也就可以容忍了，然后随着时间的推移，大家的思想就真的认为说“这个东西不错”，然后开始向别人推荐，于是营销的目的就达到了。

记得五一长假回合肥的时候跟一些老同学聊天，有人颇为义愤填膺的说现在“大侠”太多了，他们最喜欢的就是评论某个软件怎么怎么样，有时候还搞得对这个东西很熟的样子，其实很多时候完全不是这么回事，但是小白们对于他们却是唯马首是瞻，影响太坏了…… 没错，这是事实，不过小白们不听他们的能去听谁的呢？这个市场上90%以上的计算机用户都是小白，怎么去影响他们的选择，才是一个软件怎么卖得好的根本。正出于这个原因，才有了口碑营销这种东西——小白们不知道怎么去搞定一个问题的时候，他们需要的，仅仅就是一个建议而已，至于好坏，他们才没有能力区分。

诺顿的误杀导致Windows XP崩溃，这已经成为这两天的技术类头条新闻了，俨然是诺顿的594事件。搞笑的地方竟然是这篇帖子来自瑞星，还有这么一句话：“瑞星公司表示，截至中午12点已有超过7千名个人用户和近百家企业用户向瑞星客户服务中心求助，更多用户由于系统繁忙无法打入电话。”，诺顿的问题为什么去找瑞星？这让人感觉瑞星有点那个：盯着竞争对手的产品，终于抓出来一个bug，然后开始宣传。

不过从用户的影响来看，诺顿的这次事故似乎比594更严重——594事件只是导致CPU的使用率过高，这只是一个可用性的问题，并没有损坏什么，但是这次诺顿的问题似乎就是比较严重的损坏了——让一个公司的所有人每个人用故障恢复盘来恢复系统，一个公司能有多少张故障恢复盘？估计一旦中招，不用一两天很难恢复正常。

这又牵涉到误报率的问题了。现在几乎所有的反病毒软件都会在病毒码当中加上一个白名单，包含的基本上就是系统文件的特征码（比如md5之类的）来降低误报率，尤其对于那些使用了比较激进的手段的反病毒软件：我当时用过的某款激进的反病毒软件就直接把我自己编译出来一个交换键盘右边ctrl和win键的驱动程序当成keylogger，估计就是由于不在其白名单当中。可是这种方案的问题也很明显：必须保证这个白名单是与时俱进的。这是一个成本巨大的工作，不过对于依赖病毒码生存的反病毒公司来说，这个成本，似乎也不能省，否则也许，下一个594，或者下一个误杀门，就发生在你的头上。

关键还是：反病毒的技术，真的已经很多很多年没有什么激动人心的进展了，大家除了拼谁的服务反应快，拼谁的病毒码全，拼谁的白名单大，就剩下一些概念性的东西了。

sigh，照这样发展，我们真的还需要这个产业么？

水瓶座 01/20 – 02/18

有效日期: 2007-05-17
综合运势: ★
爱情运势: ★★
工作状况: ★
理财投资: ★★
健康指数: 40%

然后，今天晚上踢球撞破了眉骨，缝了三针。

下次看来务必小心星星少的时候 。

应该就是攒人品了，是因为我以前做了什么伤人品的事情还是接下来要有好事情了呢？

hoho，权当娱乐。

http://www.surfcontrol.com/Default.aspx?id=3845&mid=42

这是怎样的一个消息啊。

五一回合肥的时候，和某mm聊起动漫，mm强烈推荐我去看《交响情人梦》，称值得一看，回来之后发现有真人版和动画版，鉴于柯南和Death Note真人版对我心灵的损伤，决定还是去看动画版。遂花了几天从骡子上拖下来，观赏一番后，总结一下。

典型的少女漫，美型男加花痴女加一点别的调味品，慢，而且有点拖沓，常规模式，除了背景换成了音乐学院。难怪mm们会喜欢（不过我竟然把已经出的15集看完了，，越来越向无聊男的方向发展了）。其实剧本还不算太坏，故事背景的设定有点意思，对于音乐小白（像我这样的）有一定的普及作用。配乐（其实不能算配乐了，除了剧情当中的音乐之外配乐基本上可以无视）以钢琴和交响乐为主（剧情就是这样的……），可以拿来听一下，虽然大多数都是音乐大师们的经典之作，听烂的旋律，但是用这种方式展现出来还有点意思。只是画面不够敬业，画面除了正常的动漫帧之外，基本上由两种方式构成：半静态的全景和实景拍摄出来的乐器特写，半静态的全景的结果就是画面和音乐脱节严重，画面缺少随着音乐而动的节奏感和交响乐的气势；本来应该出彩的特写镜头用实景描出来的结果就是，要么只能看到人（还是半静态的）但是看不到手，要么只能看到手看不到人，缺少画面的整体感。所以简单的总结就是偷懒。当然了，有人会立即跳出来说我这只是在追求感官刺激，确实，这也是resource有限的结果，毕竟不能期望所有的动画都能像老宫崎那样12秒的小提琴要画半年——半年出一集，会有mm等么？