All Stories

玩了一天

  昨天又早早地醒来,然后开电脑,写了一会儿代码,估计了一下时间,洗澡,出门,坐391到图书馆,错误地估计了路程,到得太早了,于是进去里面的阅览室看了些杂志,大概过了半个小时多吧,才等到人。还好我已经很习惯等别人了,在以前多次的等人过程中磨练出来了,哈哈。  从图书馆出来,在旁边的餐厅里吃了个咖喱鸡饭,味道不错哦,鸡肉比较嫩,只是量太少了,想起上一次吃咖喱鸡好像是我生日的时候请xcc和afei,在万象城后面的泰国餐馆芭蕉叶里吃的,记得那次的量比较大,呵呵。  吃完饭后,两个人想不好去哪里玩一下,最后说起去看电影吧,于是绕了点弯路去坐地铁,又一个路盲mm,呼呼。到了购物公园Coco Park,里面有个百老汇电影城。我在深圳2年,还没去过电影院呢。mm说没看过变形金刚,看了一下时间,10分钟后就有一场,只是没有好的座位了,只有前三排的了。买了一大桶爆米花,一人一杯可乐加冰。电影院的效果果然就是好啊,连脸上的根根胡茬子都能清楚地看到。  看完电影,她有个师兄打电话约她去K歌,于是于是,俺就也厚着脸皮去蹭了,哈哈。打的到华强北巴蜀风旁边的星期8,好多人在等,看到一个精瘦的小男人,好像比较内向的样子,过了一会儿,又来了一个mm,4个人坐着无聊,斗了一会儿地主,终于有房了。还好几个人都不是很拘束,我也觉得奇怪,以前跟小思宇她们一起玩的时候要是遇到这种场景,我肯定是很自闭的,现在却几乎已经克服了那种心理问题了。  7点半,从卡厅出来,去找吃的,本来说的是去吃小肥羊,后来被我带到小肥羊旁边的华神火锅去了,哈哈!点菜的时候我正给妈妈打电话,打完电话人家已经点完了,mm说,不知道我喜欢吃什么,只记得我很喜欢吃田鸡,于是帮我点了份田鸡,呵呵。  开心!~其实人是很容易改变的,嗯嗯!

终于把大部分的问题解决了

  终过连续几周的奋战,到今天下班前,基本把编辑模块相关的问题解决完了,新的需求能加的也都加上了,不过真的从开始设计就遗留下来的通用性问题,实在是一个很烦人的事情,从程序结构上就限制了它的灵活性和可扩展性。今天还是很高兴的,因为把注释块折叠的问题搞得差不多了,昨天的解决方案今天被彻底废弃,因为它会引起一些很奇怪的问题而不容易解决。今天从Scintilla内部着手,修改了一小点代码适应自己的需求。下周就要开始把GT3000升级了,把相关的部分也跟着修改一下。那个模块经过几次几乎是推翻重来的过程,真是气死我了,一方面也确实是自己当时没有考虑到后续的维护和扩展,另一方面不停地修改原有的需求,导致我刚刚开发完一部分特性就被告知需求的变更,就需要重新来过。这回我索性就把这模块的问题先挂在那里,先从相对稳定的不容易频繁变更的做起。

老大一个怪想法

  老大又提出一个怪想法:为了测试,让原本不支持COM的程序支持COM。在我看来,这是一种非常古怪的想法。而且他一来就说要注入,而我一开始并没有觉得注入能带来多少好处,或者说对于我们现有水平,现在掌握的技术程序来说,注入可能没有多少优势提升。后来经过稍微的讨论,我也认识到,注入可以让有些事情变得更简单一点,比如可以把窗口的消息处理过程都替换掉。但老大只是为了自动化测试,有了COM后通过脚本语言就可以直接调用相关的功能,而这个COM组件其实是个中间代理的角色,它接收脚本的测试操作请求,然后对实际的程序做相应的处理,处理后的结果再由它返回给脚本。而现在的问题是,它怎么对实际的程序做相应的处理,比如点击某个菜单项,比如点击某个工具栏按钮,这个如果是用标准Windows控件的话,或许还好办一点,但也就没有注入的必要了,可如果用的是其它非标准的组件的话,即使注入了,能做更多事情了,也还是很难达到灵活控制外部程序的目的啊!

输入法卸载功能趋近完美了

  昨天为止,把输入法在注册表中的所有能找到的相关项都删除了,但输入法管理器中的图标还是好好的,输入法ime文件没被删除的话,也还可以切换过去正常使用。只有重启系统了才会消失,说明这样处理是不够的。  本来就知道有个小小的程序可以近乎完美地卸载输入法,不用启动就能使图标消失。今天上网把那个小东西找来,还真的挺小的,用PEiD看了一下说是用Delphi写的,没检测到压缩壳都只有20KB,应该是没用VCL了,本来还想用DeDe来反编译一把的,结果下了个DeDe来,好像不怎么会用啊,反正是反不出什么东西来。既然这么小,就用IDA试试喽,装入就分析完了。流程视图都只有一小点,从字符串表中顺藤摸瓜,找到一个叫UnloadKeyboardLayout的API调用,上Google随便一搜就看到有篇Blog写的如何用该API来卸载输入法,真是的,以前输入各种关键字都没有找到这篇Blog,还害得我大费周折地去反汇编,还好,也总算解决。  顺带还多了解一点内容,原来HKL就是输入法在Keyboard Layouts下面的子键的数值。

人是怎样变懒的

  今天拿到体检报告,说我超重了,要多做锻炼,多吃蔬菜水果,少吃肉类。其实体检出来的体重数值已经比我预期的轻了,人越来越懒了是没错。人是怎样变懒的呢?  现在每天回到家,都有点感觉累,不想动,于是就这样一天一天颓废堕落了。

T43与N73蓝牙连接

  下午正在睡觉,小妞打电话来把我吵醒了。打完电话,穷极无聊,想想怎么弄一下我的T43让它可以和我的N73通过蓝牙连接。一直都知道T43可以用蓝牙,但一直没用成功过。上网找了一下相关的资料,原来只要Fn+F5打开蓝牙功能就可以了。这样用N73就能搜索到了,但在连接的时候提示需要什么通讯码,就像识别标识一样。还以为是固定的,所以上网搜索了一下,没什么实际有用的信息。后来偶然发现,在T43上搜索蓝牙设备,可以找到N73,这里设一下PIN码,然后在N73里连接时要求通讯码输入那个自己设的PIN码就可以了,呵呵。这样就基本解决了T43与N73蓝牙通信的问题。不过试了一下,连接很不稳定,经常马上就断了,而且传输速率只有8Kbps左右。

关于程序运行效率后续

  话说同事那任务把他整得精疲力竭,昨天加班又是继续攻关这个遗留问题。老大的看法是RichEdit在显示的时候占用太多时间是主要原因,于是同事把RichEdit换成用Scintilla控件来进行显示,结果效率并不比RichEdit好,估计因为Scintilla是一个通用的文本编辑器,为了进行着色、词法分析等任务,在这种特殊场合下,并不是最优的方案。还是换回RichEdit,只好从提高字符串操作效率着手。把其中一部分操作原本使用CString的,全部改换成用C运行时库重写了一遍,尽量减少字符串复制操作,用原始的指针,同时也避免了原本非常频繁的CString对象的创建和销毁,再加上一点点从CPU优化的角度的编码技巧。最后发现似乎效果还是挺明显的,不过RichEdit内的数据如果一多,显示速度也会降下来,这个问题照我的看法,如果坚持要使用RichEdit的话,只能开个定时器,每一个固定的时间周期,把RichEdit中的数据减少一点,保证RichEdit中最多只存储一定数量,该数量应该还不至于明显影响显示速度的内容,否则就完全摒弃使用RichEdit,采用自己画的方案,因为每次只是画出显示的那一部分内容,速度应该很快,而难点是,要把所有内容缓冲到文件中,如何能在文件不断增长的情况下,快速准确地定位到需要进行显示的那部分内容。  这个事件,让我对现成库的效率都产生了怀疑的心理,MFC库的慢是为众人诟病的,但不知我更习惯使用的STL效率如果,它的string类,它的各种算法不知道应用到这种场合会是什么样的效果。必要的时候还是得靠自己手动解决,看了《软件优化技术》中的一点内容,编译器优化会帮我们做不少事情,但很多时候还得程序员帮助编译器创建更优化的条件和机会。

今天去加班了

  今天去加班了,难得哦,突然一下子变得很忙,这星期连续三天晚上加班,对我来说几乎是难以想像的啊。加班回来就先给妈妈打电话,然后给阿姨发短信。  给小丫头打电话,没人接,于是放下,看网页。过了一会儿小丫头发短信来说,9点以后她就接听免费了。于是安安份份地等到9点,再给小丫头打。这次小丫头似乎心情不错呢,还好像比以前会搞笑了,真是有点意外,倒是换过来我唉声叹气了好几次。记得刚来公司的那一年,经常心情不好的时候就会给小丫头打电话,那时她还在学校里,而且几乎每次她都是很固定的活动,也是我们学校的人最平常的活动,上BBS、看碟、打游戏,以前我在学校的时候也是这么过的,所以总是给我一种很怀念的感觉。以前每次跟小丫头打电话都会把糟糕的心情变好,真的很奇怪,现在却好像不行了,可能是跟我的心态有关系吧,现在的心态跟以前不一样了。  所以,人千万不能随便动感情啊,不然像陷入了泥潭,难以自拔啊!

关于程序运行效率

  同事为了能快速地打印输出格式化的字符串,已经被弄得精疲力竭了,呵呵。这些字符串来源于Ruby解释器的输出,包括各种复杂的信息,所以需要在显示前进行相关的处理,比如提取出放在行首的颜色信息,把字符串断行等等。目前的问题是,输出显示很慢,要么就是闪烁,要么就是脚本执行已经被中断了,它还在那里慢吞吞地输出,其实确实字符串已经送到了,但进行字符串处理的过程太慢,导致脚本执行中断时,还堆积了很多没处理的字符串。  看一下我们这个项目的代码,一般都是只求功能的实现,几乎从来不关心代码运行效率的问题。我一直也是这样的毛病,以前也没怎么想过特意去怎么优化。现在这个事情突然让我对这方面很是关注。  一般说来,以这个例子来说,要解决,首先就是要使用更高效的算法,看到同事写的那一段代码,确实是很低效的,大量的字符串重复拷贝、对象创建和销毁、字符串匹配等等都是很耗费时间的操作,又不注意稍微节省点用,照老大的说法,一个CString被复制了几次,用个引用效率也能高一些啊!然后可以考虑从CPU层面的优化,当然当前都是调试版本处理,也许效果还不是很明显。  我想了一下,如果是我来做那部分东西,我会怎么办。首先,我可能会把所有的CString都用C++标准库里的string/wstring来代替。其次,我应该尽量会避免每次收到一个字符串时就new一个结构体,里面还有个CString成员,这样的分配内存和创建对象操作在这种场合都太费时间了。然后是,开一个合适大小的内存池,这样一边可以追加,一边可以取出处理。再就是尽量提高匹配的效率,选择一些比较高效的算法以及好好改写程序逻辑和代码结构。最后是,RichEdit似乎也有一部分问题,可以考虑自己画,把所有接收到的内容先写入一个文件,或某块内存,每次自己处理滚动条消息,然后计算比例,画出相应的部分内容,如果用双缓冲画几行字,即使用GDI应该也还可以吧。不过这样纯粹是我的空想,基本没有实践支持,所以具体效果如何,以及复杂度如何,我也不得而知。