All Stories

真是烦死了

真是烦死了

  接了无数个电话,当然人家也是打了无数个电话。也许换位思考一下,或许人家更烦一点,那种完全寄希望于别人,自己毫无掌控之力的无力感、恐慌,也许比我的心烦意乱更不爽吧,哈哈。  现在的问题大部分是由于程序运行环境变化,考虑不周引起的。开发环境毕竟是最不容易出现问题的了,呵呵。  下午去参加一个测试行业TMG的会,看到一人介绍了一个叫iTEST的工具。据说这是一美国公司,有80个人开发的,还是基于Eclipse的RCP,看功能似乎比较有趣,说起来没有什么核心技术,但是能解决一类问题,每个license要20000USD,还真是贵呀。其实是一基于录制、重放技术的自动化工具。它的不同点在于,它本身支持多种终端协议,通过它来进行输入,对远端操作,它自动记录下所有的操作,并自动将操作转换成TCL脚本,之后就能重用这些操作序列,进行自动测试。跟平常的Robot之类的自动化体系工具理念不同的一点是,它一开始没有定义为一个自动化工具,只是作为一个操作终端,所以不需要进行测试设计,自动化设计,脚本编写等传统的自动化流程阶段,它的定位在于保存历史操作记录,并在需要时重用这些操作。想了想,似乎有些地方,跟TDL有点点像,因为TDL宣扬的是脚本就是用例,用例就是脚本,有脚本就可以直接手工测试,也可以直接通过Impeller来自动化测试,从人工介入的行为上看,似乎很相似。回来跟同事一说,他们似乎觉得很不屑。再想想也没什么的,他们就那脾气,觉得自己多牛x似的,会点MFC和COM外,也再不会其他什么了吧。  另外,负责那Impeller工具开发的同事还在担心,到时候一季度这套体系推广不了,这个项目就要解散了。我倒是觉得没什么的哈。只是我还想做着玩玩,除了那查找替换部分要重构之外,剩下的网元模拟器、图形化配置环境以及脚本扩展编辑器,都是比较感兴趣的,呵呵。

好多问题,好烦

好多问题,好烦

  那36字节的内存泄漏似乎是在Boost里的,昨天从CodeProject上下了一个跟踪内存分配情况的代码,放在工程里用了一下,看到走到Boost.system里去了。这让我觉得有点泄气,对Boost对崇敬的心情啊!不过想想,这36字节一直存在于整个进程的始末,也许它像个普通的singleton一样是不需要释放的呢,而且说不定release就没问题了呢。  MS SQL Server居然不支持双引号,晕,Access就好好的。气死人了。  问题太多了,改来改去整出一堆一堆的问题。下午的时候都烦死了,于是在那里抱怨,当初决定用Excel来作为流程文件格式,根本就是一个错误的决策。因为用户在用Excel编辑的时候,我的程序是跟踪不到各种变化的,最大限度的只能了解到变化前后的状态。今天又偶然发现另一个让人头疼的问题。本来那图形通过Excel的自动化接口直接Copy到系统剪贴板中,然后再从剪贴板中取出存成一个图片文件。但在Copy时有一问题是,它并不从Sheet左上角(0,0)位置开始,而是从所有Shape的最大边界值开始,而我关心的只是Rectangle、Ellipse等几个图形,对于Line等都是直接丢弃掉的。另一方面,Copy图形时,是会把所有Shape都选进去的,这样当有line是在rectangle之类的最大边界以外时,就不能再计算出定义精确的位置偏移了。为了这个问题,跟同事讨论了好一会儿,也没有人根本性的从技术上解决的方案,最后我灵机一动,说不如我们定个模板,该模板固定在左上角(0,0)处开始有个Shape,放个logo上去,用户的流程文件只能从该文件修改而来,这样就保证能获取不用计算偏移的图片了。说改就改,我都为我的灵机一动感到犹如神来之笔啊,哈哈!  还有很多易用性的问题,确实,最早的时候自己也觉得易用性太差,后来根据同事意见,作了一定的修改,易用性有了一定的提高,今天得到一些意见,果然易用性还是太差,嗯,写程序的人确实很难去理解最终用户的使用习惯,这是一大弊端啊,要改要改!  这样弄得心好烦啊!两年计划真的能好好实施下去吗?我不知道,我太懒了,所以我不敢拍胸脯。

解决了一些问题

解决了一些问题

  今天专心把几个比较严重的问题整了一下。  首先是程序在退出的时候,全弹出出错消息框,我都不清楚这个问题是什么时候开始有的,无奈之下,把那些遗留在那里的,暂时没用上的,准备以后有机会用的代码绝大部分都删掉了,最后发现是由于文件系统实时监控引起的。  我估计是因为一个驱动器一个线程来监视,最后程序退出时没有让线程自己返回,而是强制结束,可能就会有问题。于是我就在OnClose时向每个驱动器都创建个临时文件,这样ReadDirectoryChangeW就会返回,线程就有机会主动退出了。试了一下,有时候还是不正常,通过打印消息看到并不是每个线程都能正常退出。后来通过在线程中打断点试了试,发现好像其它线程还挂在EnterCriticalSection上了,就是说还没主动退出就被强制结束了。于是我通过减少临界区的执行时间,暂时解决了这个问题。我猜,也许在OnClose中每创建个临时文件后加入一点延时,也可以达到目的吧,不过仅仅是猜测罢了,呵呵。  解决了这个崩溃的问题后,转向内存泄漏问题。本来一开始是只有一处36字节的泄漏,一直没找到原因。后来不知道加入了什么代码,有七八处不同大小的泄漏,这让人看了觉得很不爽。通过在程序开始处加入_CrtSetBreakAlloc语句,可以让程序在启动时如果分配了指定序号的内存块时自动断下。马上发现有一处是因为一个singleton没有在退出时主动delete,加上就行。后来,又发现其他几处是因为UDP服务器端的问题,该模块基于asio写成,调试器自动在io_service相关的代码处断下了,看了看代码,我估计是退出时服务器没有释放必要的资源引起的,确实,当时因为不熟悉asio,也不熟悉socket,所以都是胡乱拼凑的代码。再看了一下asio自带的那些例子代码,在退出时主动关闭socket,内存泄漏果然都消失了。  只是最后还是剩下那一直以来的36字节泄漏,调到晚上还是没找到原因。尝试用Windbg,还是没解决,不过我确实也不会用Windbg,郁闷!

两年计划

两年计划

  昨天晚上,跟小思宇在电话里,又跟孙同学在QQ语音上聊了很久,最后她们竟不约而同地叫我好好工作,多赚点钱,之后就好了。都说现在的人现实得很,我也没有其他办法了。  早上醒来,突然想到一个两年计划,就是之后两年里,要实现的几个大目标,当然这些要在这里实现,才更有意义。首先,过完农历年回来,开始去学车,一边学车,一边攒钱,等车学完,买个十来万的车来用用。然后,再攒钱,看在两年之期内能攒下多少钱,对于买房这个目标,能有多少完成度。两年,就到2009年12月31日为止。反正我还小,到那时也才26,接近27而已。我还有时间。

再一次失败

再一次失败

  实在觉得奇怪,为什么,我到底哪里错了?很是怀疑背后有一只手在操控这一切,可是这只手在哪里,谁的手,为什么什么要这样?

明天,希望一切顺利

明天,希望一切顺利

  我都厌倦那一直失败的感觉了,说磨难也算是经历够了吧。明天,希望一切都顺利啊!给我一个寄托,给我一个精神依靠和支撑!

见到马姐姐了

见到马姐姐了

  这个称呼我觉得肉麻了一点儿,呵呵,不过就是有几个同事喜欢这样叫。中午在食堂见到她时,还是被吓到了,怎么变成这样儿了,这个脸是怎么了,跟毁容一样了,变成一麻脸了,本来多好一姑娘啊。排队打饭的时候,她站在旁边一排,我就在那儿喊她名字,然后她说我瘦了,呵呵。宣宣就在那里说,以后千万不要走女强人类型。吃过饭后,她走的时候还叫我们注意身体,我心想,你才是最应该注意身体的人呢。真是变化太大了,才大半年时间啊,怎么就变成这样了呢!  这女人啊,还是得保养啊,曾经有光网第一美女已经不在了,只存在于一些人的记忆中了!

Bug多多

Bug多多

  其实静下心来想想,这也是正常的,这样匆匆忙忙赶出来的东西,质量能好到哪里去,而且事实上不但稳定性差,易用性也是极差。照我自己的估计,再给两个月,才能基本到可用的程度,即稳定性和易用性都为大多数普通用户接受的程度。  心里好烦啊!  中午在菠菜里吃出一条虫子,我都怀疑我有没有吃下去更多条,晕!拿去换了10块钱和1盘西瓜,然后去买卡士喝了。疯丫头也吃出一个小蚊蚊,这是以前某人常用的叫法,然后也是换了10块钱和1盘西瓜。  唉,我终究是很普通一人,有时候确实太高估自己了。  asio用了这么些天,还是没掌握具体用法,用来用去还是问题一堆。  COM也是很烦人一东西,无奈的是有些时候不得不用COM啊,再加上组里最有话语权决策权的几人,都是COM的忠实粉丝拥趸,郁闷。也不知道是不是我自己太高傲了,总是要跟别人唱反调。但总是觉得人家确实也没多少让我佩服的地方,唉。  对于一牛x的编辑器,以UltraEdit为榜样来说,要直接支持脚本扩展,可以通过方便地激活一外部脚本,来操作编辑器,比如移动光标,输入字符,查找替换,复制粘贴,删除撤消等等,这是一类最基本最通用的扩展方式,可以有任意数量的脚本。另外一类方式是,可以配置宿主程序的界面,比如增加菜单项,增加工具栏按钮,而且这些菜单项和按钮的位置、文字、图标等内容是可以定制的,当然点击后,就会触发一个脚本的运行,这种脚本也可以有任意数量,任意配置。还有一类方式,是事件处理脚本,当宿主程序遇到某一事件时,就会执行相应的脚本,比如打开一个文件时,文件关闭时等等,理论这类脚本也可以有任意多个,但实际上不能太多,因为如果某事件触发时,结果要分别运行一堆脚本,这种性能问题应该会比较明显,并可能让用户受不了。暂时想到的是这3类脚本扩展支持,最近又因为对多种脚本语言的简单接触,又没有哪种让我觉得特别喜欢,所以我反而想要能同时支持多种脚本语言的扩展。这时,SWIG出场的机会来了,至少Python、Ruby、Lua、TCL都是被它支持的。  除了可以用脚本扩展外,是否还要提供2进制扩展接口,这点我还不太确定,2进制扩展可以有普通DLL和COM两种方式,差别不大,只是怀疑其必要性,它有多少价值,多少能力,有多少情况下需要它出场解决问题。  最后一点是,正则引擎需要能挂接,随时任意替换吗,UltraEdit是这样做的。

日产代码500行

日产代码500行

  今天看到什么代码圈复杂度度量的理论和工具等等内容,找个Source Monitor对我这两个月来写的一体化平台的代码嚼了一遍,发现我基本上写了约20000行代码,当然,包括注释和空行。无心算了一下,以一个月20天计算,两个月来我平均日产代码500行呀!有种说不出的感觉,没想到我写代码是这样的。光是看数量20000行似乎并不多,前不久数的时候才14000。但从日产量看,这个数字太高了,我自己对自己的要求是有200就不错了。然后从Source Monitor的分析数据看,有不少地方写的复杂度高了点,最高的是21,从公司的宣传ppt上看,大概4、5之类的比较合适吧。不过我顺便让它分析了一把Impeller的代码,那编辑器模块一初始化函数,复杂度是137,哇哈哈,真吓人,还有好些八九十的。不过这也不能说明多少其它的含义,最多只能说,也许我这点代码的可维护性比Impeller中的要好一点点。那也是归功于doxygen的推动和促进,如果不是因为一直想着要留一份可以生成良好文档的代码,我也不会写那么多注释了。当然另外一部分原因是,对Boost库的逐渐了解和熟悉,在Boost的帮助下,有不少代码可以简化。  明后天就要把这两个月来的东西拿出去见人了,希望一切顺利啊!