本来周二电话里已经把人家拒了的，今天又接到电话，说要谈谈，让我有点觉得不好意思，看出来人家似乎还是挺有诚意的。不过小妞说，到时会给我画很大一个饼，让我觉得在那里会多有前途。小妞还说，反正是两边互相忽悠，没关系的。
　　我都想不好了，到底应该怎么选择呢！因为电话里说不清楚，于是约了明天晚上下班后去关内的一家咖啡厅里聊聊，唉，心好乱！

　　昨天就想把其中一段代码，一堆if...else比较字符串的代码替换成用gperf生成的hash来进行分派，但是昨天想了想我根本不会用gperf呀，晕死，于是想着回家上网找点资源。结果回到家还是什么都忘了，光顾着看小说和聊天了。
　　今天到公司里看到那段代码才想起来，昨天晚上堕落去了，于是有点儿沮丧。后来偶然发现，嘿嘿，在资料共享区有几篇关于gperf的文章，看来是我跟同事的唠叨发挥作用了。看了一下，发现它的输入格式虽然有点学了lex/yacc的样子，却比它们简单多了，而且我的需求也是非常简单，就是可能会有6种不同的字符串，我现在想让它能自动映射到一个枚举值。gperf的秉承了开源命令行软件的一贯作风，虽然只是那么小小一个功能，也提供了好几个命令行选项，幸亏有比较详细的中文说明，再加上功能实在不复杂，试了几次，就可以了。跟最新的flex/bison一样，我用了cygwin中版本号3.0.3的 gperf，它也支持输出C++代码，这是我比较喜欢的一点，毕竟C代码混在C++中还是感觉有点别扭的。
　　另外一点说不上技巧的小提示，如果对生成的hash函数不放心，可以写个单元测试用例，跑一遍就安心啦，而且这种hash函数一般的应用场合下不会有太多的映射关系，看人家ruby用在识别关键字上，也就是几十个而已，单元测试遍历一个所有的映射关系，写一遍就一劳永逸，不错不错，哈哈。
　　这个小工具值得推广，以后凡是遇到3个或以上字符串需要比较时，就可以考虑用gperf来做这种工作，不但代码运行效率高，而且代码可维护性也上去了，一举两得。

　　好不容易等到可以公开获取的修改版Cruise Control，装上来试了试，问题多多啊，还没有文档，这才是让人郁闷的，现在的我已经越来越习惯看文档行事了。
　　这个修改版的Cruise Control有一个好处是，集成了多种工具，比如代码行统计、代码风格检视、代码静态检查、代码复杂度度量、重复代码检查等等，如果光是执行一遍这些工具，用官方发布的Cruise Control也可以做到，只不过这个修改版可以对每种工具的运行结果生成一个xml格式报告，最后将这个报告merge到Cruise Control的log里去，然后又扩展了对log的解析，可以以统一的报表格式查看各种工具的运行结果。
　　但是这个Cruise Control集成的这些工具运行得并不稳定，首先代码行统计的好像没一次正常运行的，总是阻塞在那里，要手动杀掉进程才行，然后是复杂度度量的生成的日志因为太大，然后merge的时候老是有问题，还有就是这个改过后的Cruise Control不时地会出现运行不下去的情况，真是郁闷，当然最不爽的还数没有完整的文档，我发邮件给该项目的接口人，结果回了个邮件说还在某些产品线试用，等试点结束后让我去问各产品线的负责人，靠！

　　公司内部的论坛里看到coLinux的介绍，于是从论坛里随手下载了一个装上试了试，只有最基本的一个可用的系统，这个系统作为Windows上的一个应用程序来运行，但表现上看，又是一个Linux，在shell下可以运行各种命令，查看各种系统状态数据。可如果仅仅是这些东西，对我还没什么用处，我至少也要在Linux下写几行代码吧，不过这些都需要自己额外安装，在公司不通外网的苛刻条件下，几乎没有了继续下去的兴趣。
　　另外有个比较完整的发行版，叫andLinux的，还在beta阶段，这也是开源软件常有的现象，WINE不就beta了十几年嘛。andLinux似乎直接提供了大部分需要的软件，特别是那些GUI的是我比较关心的。但是后来想起来，其实我即使装了，现在也没多少用途，主要目标还是Windows下写写代码，最多最多以后，可能会需要在其他平台上，比如 Linux，很可能也有Mac，也有可能一些嵌入式设备上，但这不是目前要关心的了。所以这个coLinux对我来说，没啥用哈！

　　从David I的blog上看到，C++ Builder 2009会附带Boost 1.35.0一起发布。想起当初，我弃C++ Builder不用转向VC，其中一个原因就是Boost对编译器的支持上，VC远远好于C++ Builder，虽然几年前，都号称C++ Builder对C++标准的支持远远好于VC，但那也是2002年前的事了，当时就已经泛滥的VC6，虽然对标准的支持差了点，但还是很多人用，而 C++ Builder对标准的良好支持只是作为广告的谈资，实际上可能并没有为它带来多少用户。后来随着VC2002、VC2003的发布，VC的进步也是突飞猛进，而且从那时起，很多第三方C++库也把支持VC作为优先考虑的事项，从此Borland的C++编译器就更没落了。
　　其实以我个人狭隘的眼光看来，C++ Builder也没达到预期中的好的效果，有一个原因是，它使用了以Object Pascal写成的VCL库，而不是用C++写成，这样为它配合使用其他C++库，造成了一定的阻碍。虽然因为C++ Builder提供了一定的Object Pascal的支持，使得很多为Delphi设计的第三方组件，可以在C++ Builder上使用，但这并不是它使用VCL带来的好处。
　　这次附带Boost库的行为，我以为，并不会为C++ Builder带来多少市场占有率，就好像其他编译套件都没有默认附带Boost，但它们的用户如果确实需要肯定会去自行下载、配置、使用，而从编译器角度来讲，其实最需要做的是改进编译器，提高编译速度、改善最优化能力、增强兼容性，使其尽最大可能地支持Boost。
　　以后，在Windows平台上，会不会只有一个叫VC的主流C++编译套件了呢？

　　长训回来了。昨天去的时候，我第一个开，除了经验不足，有些时候有点手忙脚乱之外，自我感觉还是不错的，主要还是靠熟练，多开开，也就会了，就像带路的教练说的他有个学员，九选三之后就去自己买了个车，等到路考的时候就已经开了5000公里了，其实如果只是单纯作为代步工具来说，开车一点技术含量都没有，全靠熟练。
　　今天早上回来的时候，还是我第一个开，路上目睹了一起车祸的现场，面包车与摩托车，一个人已经脑浆涂地趴在路上，估计是那个开摩托车的，人的生命是如此脆弱。

　　学个车还真是麻烦啊，这回要跑去韶关，来回需要两天，于是明天又要请一天的假了，想起来上周四下午请的假还没有填请假电子流呢，记性真是越来越差了，难道真是因为没有休息好。
　　上路也才练过一次，还是跟江江两个人轮流开了一个小时，我总是集中不了精神，眼睛看着路，思想却不知道飘到哪里去了，于是车就方向乱转了，于是被教练骂了，于是我郁闷了！
　　也不知道路上会遇到什么，教练说那条路上车很少，就算是学员也可以开得很快。我没有什么想法，只是觉得这考个驾照怎么有这么多事啊，过了这趟，下次还要再请假去考路考，烦死人了！

　　这几天看google reader上Codegear blogs一栏上，不时地贴出Tiburon这个词，开始还没留意，直到过了两天，目光稍作停留，才发现，原来是Delphi 2009/C++ Builder 2009的开发代号！上wikipedia查了一下Tiburon，似乎是一个加州小镇的名字，也不知是不是说的同一个。软件以地名作为开发代号的例子数不胜数，Borland系的产品更是如此。
　　这两年是Delphi/C++ Builder的多事之秋，先是从Borland分离出CodeGear子公司，出了个Codegear RAD Studio 2007，之后就是将整条IDE产品线以两千多万美金的跳楼价甩卖给Embarcadero，一代传奇，以这样的方式终结，让人唏嘘。
　　Tiburon最大的改进是对Unicode的支持，说是所有的都是基于Unicode实现的，包括编译器、RTL、VCL、IDE、COM、 dbExpress等等等等。我也不知道到底用户对这个特性的需求有多强烈，只是感觉这太晚了点，如果早5～8年就有这个特性，也许情况会好一些。除此之外，增加了一些新的VCL控件，不过说实话官方VCL控件的个数多少其实影响并不是太大，好多第三方控件库，各种酷炫的控件都有。另外还有些其他的改进之处，比如对Delphi语言的修改，使其支持泛型、匿名方法等，还有IDE的增强。比较炫的是C++ Builder集成了UML建模工具，可以使代码和UML模型同步，来回在两边编辑，这个特性我比较感兴趣，一定程度上说，Borland系不愧是最会做开发工具的。
　　然而，我现在已经不用C++ Builder了，转用VC一年多，也只是工作需要，以后会慢慢转向那些开源免费的开发工具上去，或者自己做。现在或许只是因为身上有那么一丁点自己也不太愿意承认的Borland情结，关注一下最新的发展动态罢了。

　　想起一句老话，天下乌鸦一般黑。回头想想其实现在也挺好的，写写代码，拿点小钱，混个日子。于是突然又想起自以为很真理的一句话“最好的软件是自己写的”，客户为导向的策略告诉我们，最好的产品就是客户想要什么样的我们就做成什么样的，于是需求收集分析就是非常重要的环节，如何正确理解客户需求，满足客户无休止的要求，是我们制造业工人的头等大事。再回过来看，自己想用什么样的软件，当然自己最明白，所以省略了信息传递过程中信息损耗、变形的过程，最后可以得出前面提到的结论“最好的软件是自己写的”。

　　几天前突然想起Intel似乎是在网上可以直接申请指令手册的，大学的时候就申请过，不过都没看直接在毕业离校看给一个老乡师弟了。现在想起来可能会搞点跟汇编、CPU、指令集相关的东东，所以又想弄一套来。
　　先在Intel的网站上找了一下，没找到相关的链接，于是google一下，还真能搜出来，以前可以直接在网站上填张表格就申请好了，现在是只能发邮件。于是照着示例写了个邮件，马上就有一封回信了，大致意思说是申请已经提交了，等fedex寄出后，还会发个邮件。结果等了好几天都没什么邮件，还以为中途出问题了。又等了几天，收到一个邮件说7月7日就已经寄出了，但我去fedex的网站上却查询不到。
　　今天公司里，收到一封邮件，说我有快递，我猜也就只可能是这书了，跑去投递中心一看，果然是，好大一箱，比上次的还大，有点儿重。回家拆开看看，每本都是厚厚的，但重量却比想像的要轻不少，都是一棵棵的大树啊！
　　估计我还是不会怎么去看的吧！

　　平常经常抱怨，怎么也不见买什么东西了，怎么工作几年了还是没攒下钱来，真是太奇怪了。其实仔细算算，每笔钱的去向都是有据可查的，只不过我没有记账的习惯，更谈不上理财了，因此就有了所谓“你不理财，财不理你”的可悲下场。
　　今天又跑去华强北一趟，已经计划很久了要去买些平常穿的衣服和鞋子。照例没吃早饭，结果看小说看到连中饭的时间也过了，后来实在心里记挂得厉害，就随便收拾了一下便坐车到了华强北。
　　先跑去KFC里，吃掉￥36.5。
　　然后去红利多看键盘，家里那套微软的无线套装，键盘用得很不舒服，现在天热了，手放在本本上也觉得烫，所以也筹划了几个星期了想换个好点的外接键盘。红利多也没有多少可选择的余地，当初我曾还想过去万商那些小铺子里买个二三十的就行了，结果同事说还是得买个好点的像微软、罗技的，说实话，有了之前的经验教训，短期内我是不会再买微软的了，感觉性价比太低，而罗技的，从大学起，就一直没多少好感，尽管这牌子的键盘鼠标确实做得挺火的。最后选了个 LaVIEW，以前没用过，因为我其实只买过3次键盘，第一次是装第一台电脑时一起配的，大概就是30块钱的，不记得什么牌子了一直用得挺好的，直到大四时电脑搬回家，因为想减轻点分量，就把键盘丢下了，到了老家又买了个新的USB接口的，现在也不记得什么牌子了，因为本来就很少回家，所以用得少，印象极其不深刻，也不记得多少钱了，应该也不会超过100块吧，再后来就是在这里给本本买的微软无线套装了，除了无线这个看起来牛B哄哄的特性外，实在找不出它其他的优点了。今天买键盘，主要看手感和外观两方面，最后以129块的价格买了一个超薄的，手感跟本本键盘类似。
　　买了键盘就去茂业买衣服。先到adidas买鞋，我也算是龙浩的比较忠实的客户了，每次买鞋首先想到的就是ad、puma之类的。随便挑了双很轻看起来很透气的运动鞋，打了8折还要 576块。接着去买衣服，去杰克琼斯看看，好多人，因为在打5折，于是买了件T恤，也要124.5元。
　　采购完毕，回家，看看也很不起眼的几样东西，除掉路费不算，今天下午就是860多花出去了。钱就是这样花掉的！

　　睡得少，白天果然很吃力，这是已经亲身验证过无数遍了。
　　本来想着是上午给个新的编译版本让他们测试一下，结果发现，一个最最最基本的功能都不能用，直接弹出消息框。其实是COM接口抛了个异常，虽然我没有用try...catch来处理，但最后还是被我挂接的未处理异常过滤函数捕获到了，弹出个没有内容的消息框。
　　于是下午调了近2个小时来定位哪里出的错，因为我自己的电脑上无论怎么样都是正常的，而别人的电脑上无论怎么样都是不正常的。猜了几次，最后想到一个地方，Excel中的CShapes::SelectAll方法，不知道哪里吃错药了，只要一调用该方法，它就抛个异常出来，倒是可以用 try...catch捕获到，但却没有什么实际意义，因为我不知道这为什么错了，我以为这就是最正确的用法。
　　冥思苦想了1个小时，毫无进展，于是上楼去找老大诉苦，我当然不会指望老大知道怎么解决这个问题，而只是想让老大知道我很郁闷很痛苦。
　　再回到座位上，照老大说的，把自己的进展，遇到的困难写邮件抄送给所有相关人，这样至少让他们自己我还是在干活的。一直到下班的时间，质量部负责这事的人跑来跟我说，这二三四季度的绩效考评放到质量部来做了，我彻底郁闷了，成质量部的人了！不要逼我啊！

　　以前对这方面没有多少关注，只是偶然看到LuaEdit用了个叫madExcept的库，可以让Delphi程序在运行时如果崩溃了弹出个看起来比较牛的对话框，显示一些当前进程和当前系统的相关信息，并可以让用户选择是否将这份报告通过email发送回开发者。当时很好奇这是怎么做到的，很希望在自己的程序中也集成进这个功能，但很遗憾地发现，这个库只适用于Delphi，而我偏偏就不是用Delphi的。
　　后来，偶然，没错，以是偶然，看到公司网上有人说FileZilla有一部分这种代码，于是找来看了看，才大致了解了基本原理，并直接把这段代码抠出来用在了项目中，但到目前为了，这个功能虽然加进去了，却还没有发挥实际的功用。因为这段代码针对使用VC编译的程序会生成一个dump文件，该文件需要配合编译时的源代码以及编译器生成的pdb文件协同工作才会有实际用途，而我们的项目没有一个良好的机制把各个发布版本配套的源代码和pdb文件归档。
　　这些天看了《软件调试》，稍微了解了Windows的错误报告机制，觉得这是一种能很好改善用户体验，帮助开发团队改进软件的方法。
　　前段时间读Code::Blocks和CodeLite的源代码时，发现在Windows平台下编译时它们都动态装入了一个叫exchndl.dll的动态链接库，却只是装入，没做其他任何事情。根据代码注释中的只言片语，加上后来去down了Dr.mingw的源代码，发现这个dll就是做了捕获未处理异常，生成报告的工作。
　　于是，我就有了现在这个想法，也许这个想法就是微软的错误报告机制的简装版。首先，确定这套机制由三大部件协同完成：1、未处理异常捕获；2、反馈崩溃信息；3、分析处理崩溃信息。在具体实现时，可按这三部分分别处理，未处理异常捕获，就像exchndl.dll一样，只需要提供一个dll，应用程序只需要装入后，什么也不用管了；反馈崩溃信息，可以另外再写个客户端，将报告信息（文件）传送给服务器端；分析处理崩溃信息，也就放在服务器端了，可以自动作些简单的分析（像WinDBG那样的，配合对应的源代码和pdb，可以找到引起崩溃的代码行），根据这代码行，可以给用户显示个html页面，说明一下崩溃原因等等，当然这需要一定的人工介入，而且也是三部分中最复杂的。这些工作都可以通过微软提供的技术来实现，但还是有不小的工作量，比如像WinDBG那样结合pdb和源代码分析dump文件，这都是调试器的一部分功能了，另外再显示html页面，肯定是需要有先例通过人工编制一个页面。
　　而且这套机制似乎有个最大的不足，是只适用于VC编译的程序。也许其他的编译套件（Borland、DigitalMars、OpenWatcom、Intel……）也提供了类似的机制，但可能没有VC的完善，不需要人工分析即可定位到源代码行，这是何等方便啊！

　　今天看了一段CodeLite的源代码，很小一段，从app开始看，到Frame。因为想学习使用wxWidgets，阅读现成产品的代码一种比较有效的方法。我并不知道到底有哪些程序是用wxWidgets的，到目前为止了解到的有FileZilla和Code::Blocks，以及这个 CodeLite。
　　学习的主要目标是掌握如何创建各种类型的窗体，如果为窗体设置消息响应。如果在绝大多数情况下，都能比较快速熟练地解决这两个问题，那么基本上可以认为算是会用这个库了。
　　wxWidgets的处理形式跟MFC比较相似，都是有一个app类，代表当前程序，然后有frame类，表示主窗体，在frame类中再衍生出菜单、工具栏、状态栏等元素，也包括其他一些子窗体，比如CodeLite中，用到各种Pane，这些Pane通过wxAuiManager来管理，可在主窗体上依靠，或脱离主窗体浮动在外。CodeLite和Code::Blocks都用标签页（Tab）的形式作为主界面，也用标签页的形式做Pane，但两者在实现标签页时略有区别。Code::Blocks用了wxFlatNoteBook这个组件，而CodeLite则似乎是自己创建的一种组件，该组件将标签页头和页内容分成两个wxPanel来实现，标签页头部分又在这个wxPanel上使用Tab来展现出页头的效果。这样的好处是标签页头相比 wxFlatNoteBook有更多的可控制选项，坏处则是需要自己写不少代码。
　　现在我最大的困难就在于，还是没有完全搞明白，这个界面是怎么创建起来的，一旦这个框架建立起来了，那剩下的业务逻辑部分都是比较清晰明了的，至少知道大方向上应该怎么走了。

　　心血来潮地翻出照例买来即束之高阁的《C++网络编程》，尘封不止一年了，只记得还是在测试组时买的，而且确实连目录和序都没看过，汗！
　　这次也是因为项目里用到了ACE，看了一点《ACE程序员指南》（所谓的红宝书）中关于reactor中的一点内容，似乎勉勉强强可以凑出一个能用的系统了。才偶然想起，仅有的3本讲述ACE的翻译成中文的书我都有了。拿出这卷1和卷2，发现封面都泛黄了，这日子过得还真是让人哭笑不得！
　　不负责任地说一句，这两卷《C++网络编程》其实是套讲设计的书。书中以网络编程这个话题为目标，用C++这把究极神兵，辅以设计模式这高等心法，大刀阔斧地讲述怎样设计，为什么这样设计，最后凝结成ACE这套演示成果。
　　所以在我看来，这两卷最终成为学习使用ACE的入门及进阶的参考书籍，这样的效果只能说是原本功能的副作用而已。

　　从china-pub上买了本《软件调试》，厚达1000多页的大砖头。开始拿到的前面有8页是空白，到china-pub上去说了一下，该书的责任编辑通过email跟我协商，最后又快递了一本正常的过来，我再把有问题的那本快递给她，如此服务质量，也让人称心满意了。
　　难得原作者用中文写成，这样就可以让我们中文读者第一时间可以读到如此重量级如此深度的精品专著。
　　该书从CPU（Intel x86系）对软件调试的支持、操作系统（Windows）对软件调试的支持、编译器（MS VC）对软件调试的支持三大方面进行了讲述，中间结合VC、WinDbg等实例进行讲解。
　　昨天晚上躺在床上，快速地浏览了一遍，让我深深感叹Windows，噢不，应该是微软的强大。微软从操作系统到开发工具，都为软件调试支持了极其强劲而且方便的支持，窥斑见豹，微软做软件是多么认真，多么负责，微软帝国的崛起除了机遇外，其自身实力和不懈努力是起主要作用的。
　　翻完这本书，我禁不住想自己写一个应用层的调试器，像OllyDbg那样的。粗略想一下，一个调试器需要具有的最基本的功能：反汇编、CPU寄存器读写、内存读写、单步、断点，以及跟系统相关性比较大的装载模块、内存映射、符号信息读取。这些在Windows上绝大部分都有现成的API可以完成了，除了反汇编比较麻烦点（看看IDA Pro做成什么样了，当然动态调试器是不需要这么复杂的），其他的至少从原理上看，是很简单的，困难的是细节。
　　嗯，WIND Is Not Debuggger……

　　照着红宝书上讲的，用ACE写了TCP的服务器端和客户端进行文件传输，代码量真的很少，而且可读性也很好，虽然没经过测试，但我自以为应该不会有多少问题了。
　　ACE还算好用，呵呵。既然这样，以后就考虑一直用ACE来做这方面的应用了，又能满足我跨平台的需求。
　　另外，我还是想建一个图形库，像visio/rose那样的功能，也许功能没有那么强大，但是效果就是朝那个方向发展。

　　经过小小的思想斗争，最后我终于决定引入ACE，这个颇具盛名的跨平台网络库。犹豫是因为2个原因，一是我本来没有使用ACE的经验，如果在使用过程中遇到问题也没有求助途径，另一是以前在网上看到过有人说ACE跟MFC配合使用时会有内存泄漏的问题。
　　但是想了想，如果直接使用socket来写的话，开发效率更低，需要编写的代码更多，更容易出错。之前也是用了boost::asio，大概是因为没用好，反正不但代码写得难看，也没有能照预料中的那样正常工作。
　　同事在一个小程序中使用了ACE，虽然他用的是WTL，却仍然无形中给了我一种鼓舞，最终我还是决定用吧，泄漏就泄漏吧，反正只是个小程序，不会像服务器那样长时间运行的。稍微熟悉了一下reactor的使用方法，还算容易理解。它通过类继承，虚函数覆盖的方式来响应特定的事件。相比 boost::asio使用functor回调的机制，更OO一点，而对于我来说，boost::asio可能多了需要对各种对象进行管理的工作。
　　争取在剩下的两天里，完成点对点文件传输的功能！

　　虽然打算使用MinGW＋wxWidgets来写程序，似乎是可以抛弃VC＋MFC或者BCB＋VCL这类商业软件了，但是，实际上我发现我根本离不了VC，主要是离不了VAX，这个超级好用超级变态强悍的VC助手。
　　早先的时候，只用到VAX的智能联想提示功能和跳转到定义或声明的功能，自从看了Martin Fowler的《重构》，VAX的诸多重构功能也成了我目前最常用的功能，日常工作写代码，离了它简直痛不欲生。
　　写代码最好用的是VC＋VAX，但看代码最好用的，个人感觉还是Source Insight这个虽然不思进取，但基础确实不错的东西。Source Insight也可以用来编辑代码，不过比起VC＋VAX来还是弱太多了，而且它也是要买license的，最关键的一点易用性方面不足是，多少个版本推出来，还是不支持标签页浏览，真是不可理喻，而且对中文的支持也是一直都没任何改进。
　　所以最好的工具是能集VC＋VAX代码编辑功能和 Source Insight代码浏览功能于一身的。但是目前还没有找到能达到这种效果的软件，从免费到商业的，都没有。回到最开始提出来的，要用 MinGW＋wxWidgets来做开发，还是比较困难的，比较折中一点的办法是，先在VC里做debug版进行开发和调试，定期用MinGW生成 release版本进行测试，先打造一个好用的CppCoding工具。