All Stories
今天旁边的同事突然问我有没有空一起去吃饭，本来还以为算是几个同事的年终聚餐，结果到了餐桌上才知道，原来他马上要离职了，就在这三四天里会办完手续。 这样自发地跟项目组里的同事出来吃饭，我还是第一次。我真是个很奇怪的人，当年在测试组时，第一年，也是不跟测试组的人一起活动，直到后来搬了家，才开始慢慢和他们一起玩。发现自己其实很势利啊。 今天喝了一点啤酒，话也多起来了。平常跟同事说的话也不多，而且脾气也挺坏的。说了很多公司的事，有点惆怅，也许跟我这几天心情本就不好有关吧。 人来人往，没有终点。
今天又看了一下wxLua，其实很简单一回事只要把用CVS下载来的wxLua源代码编译一下，生成一个wx.dll文件（当然是在Windows平台下的），该文件依赖于wxMSW的两个dll，分别是wxmsw28u.dll和wxmsw28u_stc.dll，如果用不同的编译器，或者编译选项，可能会有不同的文件名后缀（注，不是扩展名）。我是用MinGW最新扩展4.3.2 TDM-2来编译的，把编译出来的dll放到搜索路径下，用lua.exe就可以直接运行wxLua自带的几个例子程序了，比如auidemo.wx.lua。 开始时，还在想到底是嵌入一个纯粹的Lua解释器，还是嵌入wxLua。其中的区别就是嵌入wxLua可能会需要多点C/C++代码加到工程中，作为胶水代码连接lua代码和wxWidgets。现在发现，其实不用管这么多了，只要嵌入一个纯粹的Lua解释器就够了，再设定好搜索路径，即package.cpath，就可以自由地装载wxLua了，其他的第三方库也可以用了，比如LuaXML、LuaZip等等。 我仰天长笑，接下来的问题是，如何让外部的Lua脚本识别出各个scintilla控件。MDI界面必定会有多个Scintilla视图，怎么能让脚本方便自主地获取到自己需要操作的那个视图呢？
不知不觉，2008已经过去，又是一事无成的一年，凄凉到我有点不堪回首。 12月31日是江江的生日，江江居然邀请我到她家去吃火锅，这让我有点受宠若惊。记得30日时她发邮件，我还没反应过来，一直到31日上午才明白，于是思量着送点什么小玩意儿意思一下。一直到下午快下班的时候才跑到孙同学那里去，抢了她放在机箱上的娃娃。说受宠若惊，不是夸张，而是有原因的。一是我自以为跟江江并不那么熟络，二是我知道江江有BF但她却一直吞吞吐吐，这么邀我去，不就让我什么都知道了吗。不过太多的猜测，或者说心里搞得太明白，反而会让生活变得累人，所以还是不管那么多了。到了江江家，是一套七八十平的两室两厅，有点温馨的感觉。江江的BF似乎有点眼熟，可能是以前哪里见过，但我一点都记不起来，但是他说见过我，汗！火锅味道不错，还有很多肉和丸子，是我很喜欢吃的东西。吃过火锅又打麻将，一直到午夜12点，真是心旷神怡啊！没想到这次新年钟声响起时，我是在打麻将，哈哈。以前的各次印象已经差不多全没了，只记得有一年，大三吧，居然是在自习，欢呼声传出时，我刚刚走出二教大门。 1号，也就是昨天，在家宅了一天，连饭也没正常吃。先是捣鼓了一阵wxLua，它的出现让我犹豫，我是只嵌入Lua，还是嵌入wxLua呢。用嵌入wxLua的好处是，除了用脚本来表达业务逻辑外，界面的一部分也可以方便地用脚本来做了。但从网上看到的一些文章看来，wxLua的评价并不高，而且最大的问题可能是绝大部分开源软件都有的问题，技术支持太少，出了问题不知从何下手寻找解决方案。从CVS下载下来最新代码，直接用MinGW编译还不过，要改下makefile才行，而用vc9编译，则完全不知道如何下手修正了。然后出去吃了个KFC，修剪了一下头发，就看小说去了，看到后半夜！ 2号了，好些天前就跟猫猫约好去看电影，起床玩了一会儿电脑，掐着时间出去坐335，到中信广场。来深圳这么久，看电影只去过1次CocoPark的百老江，去过3次东海太平洋。这次不知猫猫从哪里弄来的电影票，刚好去看看新南国的环境怎么样。先去吃了顿泰国菜，然后晃悠上去。片子还是不错的，冯小刚作品，葛优，舒淇主演《非诚勿扰》，有点搞笑，中间有点悲伤和无奈。看完电影，去购书中心晃了一个多小时，跑去喝鸭血汤作为晚饭，然后打道回府！ ……
昨天遇到一个问题，用MSXML操作XML时，删除一个子节点，可是死活删不掉。后来想到一个变通的办法，把这个子节点的标志性属性值改掉，这样其他处理过程就认不出这个节点了，就相当于删除了，很黄很暴力。 今天再去定位这个问题时，发现原来那子节点真的被删掉了。进一点试验发现，只要在删除该子节点前，先随便改一下这个子节点的一个属性值，下面的删除操作就正常了，但如果没有那个修改操作，就删不掉，真是怪事！ 我当时还以为是不是因为子节点下面还有其他孙子节点，还想是不是要修改一下删除子节点的封装方法，递归地删除掉所有子孙节点呢！看来不必了！
今天在公司看到一个同学在用e，有点好奇，早听闻它有“Windows下的TextMate”之称，以前也下载来装过，只看到界面很简单，功能也很简单，于是就没下文了。今天又有点兴趣，就让同事共享给我再试用一下。 还是老样子，界面上没什么改进，也许比之前我试用时功能上有所增强，但以我目前的眼光看来，它还是太简单了。总的说来，只有一个特色功能，就是bundles。不过可能TextMate赖以成名的就是bundles了，e就是全盘照抄了，从网上看到，说e的作者和TextMate的作者是老乡，两人协商过，让e可以直接使用TextMate的bundles。所有的人都说，e只有TextMate的一小部分功能，这我也是相信。但是最让人受不了的是，e运行极其不稳定，随便点几下就是挂起，或者崩溃。这么烂的程序居然也来卖，而且听同事说可能卖得还不错，我想这全沾了TextMate的光啊！因为说，它的一切思想，无论是从程序开发的角度，还是用户体验的角度讲，都是很好的，但这一切都是TextMate赐予的，e里唯一有点自己特色的是，用类似异步可插入协议的方式来修改配置。我没用过TextMate，不晓得它在这方面是怎么做的。 看了e后，另外一个同事就说，我们现在的Impeller应该也好卖吧，有语法结构树，有自动完成，有调试执行，我笑！
昨天晚上跑去KTV唱歌，后来唱歌腻了他们就放起的士高来，我是不会蹦迪的，可是看着那些人在那跳得那么起劲，我也有点蠢蠢欲动了，于是去胡乱蹦了几个。结果，今天就显效了，虚脱了，背痛，下午一下就睡着了，好久没在家里睡过午觉了，醒来的时候发现天灰蒙蒙的，还有雨声，还以为睡到天亮了，心里不禁大喊，天呐，我居然从前一天下午睡到第二天早上，还没吃晚饭！后来挣扎着要不要起床，看了一下时间，才18点，心里顿时安定了不少，原来还没到第二天啊，刚刚还郁闷着这周末就不知不觉地让我睡过去了呢！ 再说点正儿八经的事。话说我一直想要设计一个基于C++ GUI框架的脚本扩展架构，不过到目前，还没有一个完整的清晰的思路，我只有一个大致的目标。一直想着，这样的架构实现后，只要C++部分实现一些基本的底层支撑，剩下的脚本就可以直接拿出复用，实现所有业务逻辑。为了证明这个架构的通用性，我觉得自己似乎有点儿贪心了。我希望在MFC+XTP的基础上、WTL+TabbingFramework的基础上，以及wxWidgets的基本上都实现一遍。MFC的是因为工作上的需要，WTL则是因为想写一个WIND，而wxWidgets的则是想写一个通用的跨平台IDE。今天只想到一点，所有的逻辑处理都应该交由脚本实现，C++部分只提供最基本的底层（原子）操作。
昨天偶然发现，我的程序根本检测不到Excel文档的修改，太让人郁闷，之前完全没料到这个结果啊！后来回想一下也想通了，Excel文档那么复杂的一种文件格式，不使用像txt之类的修改方式，完全是可以理解的。不过理解归理解，问题变得棘手了，怎么才能实现那个需求呢！ 今天没写代码，倒是在自己建的wiki上写了几篇文档，有关于设计方案的，也有关于使用说明的。我要开始准备撤退了，出于道义上的，或者说职业道德上的考虑，也是为了让自己以后少被人骚扰，我要输出尽量能解释清楚我目前所做的一切的文档。 写文档也是个很累人的体力活啊，也许是因为几乎从来不写文档，让我觉得很多事情都不知道从何说起。心中很清楚明白其中的每个细节，却不能用文字表达出来，或者说即使能零碎地写些文字出来，却不能有效地串连起来，形成完善的文档。 今天质量部的老大把我叫去，谈了一下之后的计划，我刚好趁此机会明白地告诉他，我对之后的维护性质的工作实在没多少兴趣的，而他居然出乎我意料地说，如果是这样的情况，可以换个人，而且还肯定了我之前所做的，这让我心里比较高兴，哈哈，仰天长笑！
今天做另外一个工具的一点维护工作，需求是通过用户输入的宏名，宏值，类名，函数名以有函数返回值，工具要能自动到指定的文件中找到指定的位置，自动插入生成代码。本来这个需求是上个版本就已经实现了的，今天只是对需求有略微一点修改。可是最大的问题是，今天发现以前实现的这个根本不能用啊，文件是能找到，可是位置却是错的，根本毫无联系。 调试了很久，实现过程是首先利用MSR的greta来找到参考标记，取得标记的位置，然后插入生成的代码。一开始怀疑是取得标记的位置不对，其实冷静地想想，这种可能性几乎不存在。不过我还是傻傻地加入代码，看标记位置取回的字符串内容，毫无疑问，肯定是对的。接着怀疑是Scintilla的插入方法有问题，同样事后想想，这种可能性也微乎其微。不过我也不死心地，加入代码，看该位置的Scintilla文本，果然已经是不正常的内容了。 正在束手无策之时，突然不知怎的，灵光一闪，可能是因为看到其他一个项目中使用多字节编码的greta，觉得可能是这里引起的问题。greta在匹配文本时，在unicode情况下，一个中文字符和一个英文字符都是一占一个长度，而此时Scintilla还是以多字节方式处理，一个中文字符占两个长度，所以greta算出的位置对scintilla来说并不能对应上。想通了这一点，立即将工程编译选项切换到多字节方式编译，果然就正常了。 这次遇到这个问题，也能为以后实现相关需求，或者解决类似问题，提供了极大的参考价值。
老大叫我整理一份项目组内成员的C++相关内容的培训计划。我还是兴冲冲地去弄的，不过基本上是参考我自身的情况制订的，内容方面不是我比较熟悉的，就是我比较欠缺但又在工作中比较需要的。 主要分了8大类，分别是C++对象模型、C++模板、STL、Boost、面向对象程序设计、Windows API、MFC、COM。每一类，都又划出好几个培训课程，我还根据自己所了解的，分别给每一类都备注了参考资料，每一类的的参考资料大多只是两三本经典书籍，比如COM类的，我就写了《COM本质论》和《深入解析ATL》，而Windows API类我就写了《Windows程序设计》和《Windows核心编程》，等等。 等我把这份列表发给老大，老大又转给更大的老大，更大的老大则回复说，内容太多了，要分轻重缓急。我觉得很有道理，这样的培训是很耗费资源的，当然应该拣最有用的来。不过他列出的前3位是Windows API、MFC和COM，对于我来说，就有点兴味索然了。虽然这些方面我也远远说不上精通，甚至连熟悉都不够，但我自以为，应付工作上的要求是够了。比COM举例来说，我虽然排斥COM，但必须用地方还是会用的，我会调用COM服务器，同时我也写过COM组件，我觉得自己够了。 既然不能把这份列表作为组内的培训计划，我看了看，觉得依照这些列出的参考资料，也可作为我自己的增强计划。这8类我都有所了解，在实际工作中也都或多或少地有所运用，但我不禁要考虑，学到什么程度算是够？ 我个人倾向于学习和使用一些比较通用的技术，比如STL、Boost之类平台无关的知识我就很有兴趣，而COM则是有点深恶痛绝的感觉，MFC稍微好过一点，不过也不是很喜欢。这不是我研究了这些东西后主动有了喜恶观念，而是不知不觉在一个比较长时间内养成的兴趣倾向，直到后来自己总结的时候才发现这个规律。 其实我根本没多少想法，要尝到什么程度，目前而言，我只好给自己暂订个目标，STL、Boost、C++模板和对象模型，以及面向对象程序开发，是能学多少算多少，而其他的，则是够用就行。
