All Stories
今天在公司网上看到一人发了个Komodo IDE，装来看了看，猛然发现它是基于Mozilla XUL技术实现的，有点诧异，居然还真有用XUL技术开发的商业软件。然后就跟公司里的另外一个人讨论了一下，那人比较了解XUL，在去年还做过技术选型工作。 从中我了解到，有一种叫Remote XUL的技术，可以使得通过Firefox浏览某个页面，界面效果跟通用的桌面软件差不多，但实际上却真真实实是部署在远程服务器上的。其他能达到类似的效果的有JAVA Applet，或者MS的ActiveX，好像Adobe现在在搞的AIR也差不多，有种让人惊艳的感觉。看来该是有必要学一点这方面的新技术了，一直以来觉得跟Web相关的，都不是很感冒，但现在看来，它混淆了B/S和C/S，即桌面和浏览器的概念，很有意思啊，比如，假设有一种能适应各种浏览器的这类技术，那么做一个Web版的IDE什么的也不是问题了。 除了这种远程部署的界面技术，还有其灵活的可扩展框架也是让我感兴趣的。那人的胶片中对Eclipse RCP和Mozilla XUL进行了简单的比较，结论是更看好XUL的，不过我个人的观点看来，两者单纯从可扩展性上讲，各有优缺点，不相上下吧。XUL体系使用C/C++实现具体的界面控件，然后用XML描述界面布局和事件响应，用JavaScript完成实际的业务逻辑，响应XML中定义的事件，调用C++代码作出具体的动作。XUL要创建出新的界面控件比较困难，只能用已有的控件组合成新控件，所以像Firefox就实际上提供了扩展和插件两种不同的机制，扩展就完成只使用XML和JavaScript实现，而插件就可以实现比较高级的像内嵌Flash播放器之类的功能。总之，简单看来，相比Eclipse的实现方案，XUL并没有哪里特别不如，或哪点特别突出，只能说也是一种不错的机制。倒是让我多了解了一种扩展方式，自己设计可扩展的软件架构时，倒是要好好考虑一下了。
虽说好久好久以前就认识到设计模式的重要性，也好几次都决心要认真系统地学习一下，但是每次都没能坚持下来，每次看到GoF的书，立马一个头变成两个大，实在是枯燥乏味啊。倒是总能看到那么多人，学这么枯燥的东西津津有味的样子，然后头头是道是品头论足，心中不免有一丝的羡慕，什么时候自己也能那么熟悉并熟练地应用这些设计模式该有多好啊！ 当兴趣渐渐从纯粹的编程语言技巧转移到架构设计、软件工程方面上来时，就有意无意地拿起《重构》、《敏捷软件开发》、《重构与模式》等书看。这些书有一个比较有趣的特点，就是互相引用，于是，我发现不懂设计模式已成为我前进道路上最大的障碍。我要进步，就必须要清除所有的阻碍，所以我要再次开始学习设计模式。 仔细考虑一下，为什么之前我每次都会放弃，是因为GoF那书太枯燥抽象了。所以要去找几本通俗易懂的书来先补充一下这方面的不足。《设计模式解析》第二版似乎还算入门级的，从公司图书馆中借到一本，抽空要快速看一遍。看网上的评论，《Head First Design Pattern》更加适合初学和进阶，所以要看看。另外，看到这些书中都提到了Christopher Alexander写的书， 有中文版《建筑的永恒之道》和《建筑模式语言》，这是关于建筑学的书，但是软件架构设计就跟建筑学有类似的地方，而且设计模式的起源据说就是从Alexander的研究中开始的，就当开阔眼界也好，也买来看看。 我并不是想做一个软件架构师，我只是想能轻松地写出结构优美，弹性十足，易于维护的程序来。
今天有个项目部的主管来找我，问我那流程平台工程做得怎么样了，他们部门目前新员工多，觉得这个工具或许可以解决当前的问题。我比较诧异啊，居然还有人想试用这东西，说实话现在这边的状况是，尽量快点甩手，从此解脱。我早就不胜其烦，厌倦了没完没了在上面投入。那位主管说得很有理，说这东西做好了很有价值。这个我当然也知道，如果做好了，当然有价值，关键是上头的决心有多大，愿意投入的成本有多少。一直就是我一个人在折腾，一个人折腾么，给我足够的权力和资源也好，偏偏也没有，要指手划脚地作些不合适的决定。 今天我突然想到，要是早知道会拖到5月底这么久，早期的设计就可以做得好一点，2个月有2个月的做法，3个季度有3个季度的做法，唉，这应该可以算是一个失败的案例了。 回顾检讨一下失败的原因：1、前期的规划没做好，开始以为时间不足，就迫使强制采取了些不良设计；2、用户需求一直不明确，以及用户需求实现比较困难；3、我做为唯一的开发人员，心理上有所抵制，积极性不高；4、开发编码工作没有计划和任务跟踪；5、缺少测试支持等额外资源的投入；6、现在看来，因为其他因素的影响，似乎开发投入人力也不够。 暂时只想到这几点，不过也很难过了，唉！
晚上去练车了，这是我第一次摸车，比较不习惯，总是记得一头忘记另一头。比如想着踩离合器和刹车的时候，就会忘了摆方向盘，或者又不记得挂档了。 据说天黑是不能练车的，因为看不到桩。确实，如果没有灯的话，我连边线都看不清，有双夜视的眼睛该多好呀！ 一般说来，习惯成自然，只是平时没有碰车的机会。要流畅熟练地手脚并用，还需要多多练习。 因为是第一次，所以只是教了下怎么挂档，怎么用离合器控制速度，怎么摆方向盘，怎么前进倒退。除了我，还有另外一个人一起，两个人轮换着控车，大概总共搞了1个小时多一点点吧，不过瘾啊，要攒钱自己买台车才行，呵呵！
嗯，这个活动在上个月的时候就筹划过了，不过我并没怎么投入，呵呵，都是bobo在那里捣鼓说五一3天假期里可以抽一天出来，然而，bobo组织不力，3号那天上午我迷迷糊糊发了个短信给bobo，最后结果是cancel掉了。 这次好像是猫猫牵头联系了其他人的，在公司里是一点风声都没有，只是有一天晚上在QQ群里猫猫跟我提了一下，要到我家里来烫火锅，其他时候则是只字不提，联系都没有。 直到今天上午10点多了，我发了个短信喊猫猫起床，她才给我打电话，说11点在我们小区对面的超市门口见，叫了某某和某某。等我11点10分跑去，也才看到舒蕊一个人在那里等着，这个猫猫越来越不像话了，都没有时间观念啦。又过了一会儿，才见大部队浩浩荡荡从天桥那边走过来，猫猫、江江、bobo、大牛和他媳妇。一共7个人，到超市里买菜，这种感觉还不错。买了盒装的肥牛和羊肉，贡丸、虾丸，还有很多素菜。又买了些碗筷，本来家里是有一些的，不过这次人多了，不够用，所以要再添点。 买了回家，我就没怎么动手了，只是找出椅子等必需用品，收拾一下东西。这次买得多了一点，后来刘献文也来了，9个人把肉类都吃掉了，素菜却剩下不少。总的说来，我对火锅的味道要求很低，我几乎感觉不出什么好差来，呵呵，所以这次也吃得比较满足，关键是一群同事一起玩，有一份惬意。 可惜，相机没电了，不然也可以留下点什么留念，一大遗憾啊～
虽然几年前就知道SWIG了，但一直以来都没真正用过，又是一次叶公好龙。 今天在公司里跟同事偶然谈起项目里嵌入的Ruby解释器的问题，于是回来兴致高涨，决定研究继续研究一下CryptTool遗留下来的问题。 首先介绍一下CryptTool。这是一个可以使用多种算法计算文本或文件内容的hash值的小工具，最早的原型是几年前还在大学时写的一个计算文件md5的小程序，去年做一体化平台时，有一项内容是要用一个单向散列值来近似唯一地标识一个文件，所以顺便找了一个几种常用的hash算法源代码，包括md2/4/5、SHA1/224/256/384/512、haval3/4/5、CRC、GHash、Gost3/5、RMD128/160/256/320、Adler32、FCS等。回家用MFC写了一个，完成了多种算法计算的功能，当时突然兴起，觉得可以嵌入脚本解释器，实现外部插件扩展。结果只是实现了搜索指定目录下的脚本文件，并添加相应的项到主菜单中，通过菜单项激活脚本执行。连脚本执行都没实现，因为当时贪心，又觉得好玩，打算把Python、Ruby、Lua都嵌入进来，确实都链接进来了，却没有实际的功能。 再简单介绍一下SWIG。早先，我只知道它是用于嵌入和扩展脚本解释器的，但具体详细的作用却并不清楚。现在，我有了新的认识，SWIG主要作的是扩展脚本解释器时，将C++代码做一层封装，实现自动向脚本解释器注册相关的信息（如函数、变量、模块等等）。说起脚本解释器的扩展，大多数的资料，甚至连SWIG的帮助文档里，都是说的将C++代码编译生成动态链接库，然后官方的脚本解释器会载入该动态链接库，并在解释执行脚本时使用动态链接库中的内容。而我现在的需求，前面已经略有提及，是把我自己的exe程序里嵌入的脚本解释器扩展了，并且我要的是实现该扩展功能的代码是exe的一部分，而不是独立的动态链接库。两年前，用C++ Builder写过一个用于数据处理的小程序，其中就花了不少精力实现了嵌入Python、TCL、Lua，并扩展了几个函数，当时全部都是通过手工编写代码，按照标准的官方推荐通用作法实现，以至于连续近2个月几乎每天都是后半夜2点才睡，到后来精疲力竭，连上WC掀马桶盖都觉得异常吃力。 现在用VC实现嵌入和扩展理论上应该也不会有多少差别，只不过扩展部分是用SWIG完成的。先写一个后缀为.i的文件，定义扩展的模块名和扩展的函数原型，如果有变量也写上。然后在命令行中运行SWIG，用法行简单，命令行参数也很简单，因为是放在MFC工程中，所以理所当然地把输出限定为C++类型的代码。这里值得提一下的是，指定输出的文件名，用.h文件比较合适，它里面是一堆函数的实现，但并没有单独的原型声明，所以在实际工程中，只要直接include该文件就行，而不是当成源代码.cpp添加到工程，不然编译会比较麻烦。另外还有一点是，写在.i文件中的变量类型，不要用宏定义，而是用实际的标识法，开始我用LPCSTR和LPSTR分别表示const char *和char *，结果在脚本调用时，就会报类型不匹配，直接写成const char*和char *就没有问题了。再有一点，SWIG生成的代码中，会有一个初始化的函数，该函数完成各个扩展的登记注册功能，在EXE内嵌入脚本解释器后，需要自己调用这个函数。而且从该函数可以看出，Lua的就需要一个lua_State指针，说明Lua是能支持进程内嵌入多个解释器的，而Ruby和Python都是没有参数的，说明一般说来只提倡一个进程内嵌入一个解释器。 曾经看到有人（似乎是SWIG的作者吧）说，SWIG生成的代码可读性很差，今天我看了看，觉得还可以，需要关心的部分还是能大概猜出一点意思的，而其他的都是辅助性的代码，也就是完成实际的接口转换工作的。除了这个问题，还看到网上有人说过，SWIG实现的粘合层，在效率上会不如直接手工写的那种，今天我看这些生成的代码，觉得此种言论是立不住脚的，因为完成实际接口转换工作的代码都是固定的，应该也是SWIG的开发人员先手工写好的，在效率问题上并不是值得纠缠的。 用SWIG扩展exe内嵌入的脚本解释器，可以大大减少工作量，降低出错的机率，实在是一种值得推广的工具。比如最近在考虑的，在C++程序中实现一套仿Eclipse的插件机制，使用外部脚本实现程序的业务逻辑，这时用SWIG就可以直接将大量内部核心接口转换成内嵌的脚本解释器可接受的形式，极大地提高工作效率，对于使用COM接口的方案，真的是不太感冒！
中午离12点还差10分的时候，突然接到疯丫头的电话，叫我拿100块钱去给她。翻出钱包才发现，空空如也，急忙问旁边的同事借了100块钱，又急忙坐电梯到1楼，还以为这样会比走楼梯快一点，再急忙坐穿梭巴士，巴士开得慢悠悠的，我急不可耐地让司机可不可以开快点，不得地看时间，好不容易在6分钟内赶到A10，进了大门看到一着正装的MM站那儿，本还打算上去问一下她101房在哪里，走近一看才发现，这正装MM居然就是疯丫头，哈哈，她也会有穿得这么正式的时候啊！ 差不多有一个月没见过她了吧，跟着她领完东西，刚好就是吃饭时间了，于是去A8吃饭。路上偶然发现，她左边下巴上的那些东西还没抹散，呵呵，这个丫头这一上午走来走去，不知让多少人偷偷笑过了。 A8的饭菜感觉就是比F2的要好吃，我还是打了两个素菜。一边吃，她还一边给我讲她新岗位上要做的事，现在在客工部实习，下午就要去接待客户。像以前一样，我很快吃完了，看着她吃，互相讲些自己最近的情况。 吃完饭，慢慢走回来，她就回G1去了。她还说，如果干几个月，觉得不好干，就辞职。我猜，可能还有其他原因吧。唉，人就这样一个一个都走了，我的心就是这样一点一点被敲碎的。
写个围棋打谱程序，这个想法好多好多年前就有了，上高中的时候就有了。大概是因为当时对围棋有点点感兴趣，纯粹的叶公好龙型的，虽说感兴趣，却没有认真学过，只是知道大致的规则而已。这些年，看StoneBase的发展，觉得挺有趣的，不过它的实现不是我喜欢的方式，所以我突然又决定自己写一个，而且想了想打算用WTL来写。 开始是有点犹豫用MFC还是WTL的，因为MFC相对较熟悉一点，而且有Xtreme Toolkit Pro可以用，做炫酷的界面确实方便。但是后来想想用WTL就看中它生成的可执行文件体积小巧的优点，看看StoneBase当前最新的4.6.1版本，exe文件也就只有8.24MB，而假如用XTP的话，当是它的dll就有5.5MB，还要加上MFC的dll，大概是3.6MB，这样附属的文件体积就已经超过StoneBase主程序文件大小了。还有一个想法是，希望能借此机会好好学习一下WTL的使用。 至于要做得什么样的，从特性外部行为上看，可以模仿StoneBase和MultiGo。比如首先要能支持几种国内常见的棋谱文件格式，还要支持棋谱库，MultiGo没有，StoneBase 用了一个叫Absolute Database的嵌入式数据库，我猜大概因为StoneBase是用Delphi开发的缘故吧。我可以用SQLite来替代的，不过StoneBase有一个很庞大的棋谱库，所以也需要能以某种方式读取它的数据库。需要有良好的打印支持功能，肯定很多情况下，需要把棋谱打印出来，对着纸自己敲棋子，那种感观享受不是电脑程序能比的。要有方便的棋谱输入编辑功能，要有格式转换功能等等。 具体实现上，我想尝试一下纯插件框架，也即用C++实现一组核心的功能，其他高层的业务逻辑全都使用外部脚本扩展实现。这种框架有点像Eclipse，又有点像Mozilla的XUL方案，要扩展的地方包括主菜单、工具栏、弹出式右键菜单、棋谱格式读写等。
有些问题是看不出来的。 今天因为有人提了单，我才下决心去看了一下代码，经过比较仔细的排查，最后结论是，果然是被我改坏了，原来的那种实现方式确实是不会出这种问题的，不过那种实现方式是一定不能留的，一定要被改掉的，只能在现在的基础上进行修改，最后好像勉强可以了，哈哈。 还有一个问题，好久好久了，是以前离职的一个人留下来的东西，交给其他部门人用的工具，现在发现有问题了，原来我看了一下，似乎问题不在工具本身，而在工具调用的底层通信模块上。今天又被人一说，仔细读了一下工具的源代码，再加上和那底层通信模块作者的讨论，最后结果是，确实好像是工具实现得不对。有几行代码一眼看就觉得写得有问题，且不说是否真有问题，首先代码就不应该是那样写的。 另外是这大半年来我陷入其中的工程，今天写用户手册，当然需要演示截图，结果发现了好几个比较严重的问题。唉，我这大半年的投入产出比还真是低，心里有点难过。争取在剩下的3个星期里，把这些严重问题修正了，完善一下用户手册，就彻底交付了，唉，从开始计划的2个月，到现在都大半年了，真是没完没了，还拖累了绩效，不过似乎就算不搞这个，绩效也不会好到哪里去吧，郁闷！ 最后提件还算好的事吧，小思宇回深圳了，今天还给我打电话，挺高兴地跟我说“我回来了”，大概是因为彭彭回来了吧。不过她那高兴的劲也短暂地感染了我，让我如沐春风啊，哈哈。
