All Stories

一天Workshop

  开了一天workshop,上下午各3.5个小时,谈及了部门目前存在的问题,以后的发展方向,规划等等在我看来似乎离得不近的东西。不过通过今天一天的workshop,总算让我的心态又调整了一点,本来是很不爽现在做的事的,结果我又被说服了,我觉得现在做的事还是比较有趣的,有价值的,至少可以让自己的技术得到提升。话说昨天小妞的老公还叫我不要太沉迷技术,可是我发现我其他的什么谋生能力都没有,实在是不得已而为之啊!  昨天晚上居然兴奋得睡不着,试用过dot的能力后,越来越觉得格式化显示流程图的功能可以用dot来做,可以让它导出成png(或jpeg或gif)之类常见的图片格式,再导出成svg这种文本格式,通过解析svg来获取到各个图形节点的坐标位置,通过png来进行实际的显示。只不过昨晚简单看了看dot生成的svg,里面用的尺度单位又是那该死的“磅(即pt)”,大概我们目前最常用的分辨率下是1磅≈0.75像素,这样就又多了一次浮点乘法运算。还是得去图书馆找一本讲svg格式的书来看看,主要了解一下它怎么描述坐标系统。  自从基本用ACE搞定了文件传输功能后,我又开始在心里有点蠢蠢欲动了,在这个工具里面加入Kademlia会怎么样呢,当然现在这个工具的用户还太少太少,看Kademlia的那些参数定义和设置应该是依赖于一定量的用户数的基础上吧,可能是几十万,也可能是几百万,那样才能发挥出分布式hash的效用。看我做的这个工具,只有几个人用,最多也就是几十个人吧,也许通过一些政治手段,可能达到几百人,但还是太少了,根本不能体现这Kad的作用,不过我就是想把这工具做为一个试验田,既然干得不开心,就努力为自己争取些其他方面的收获嘛。

今天进展不错

  今天终于把文件传输部分改得几乎能正常传输完整个文件了,试了2KB、84KB、2MB三个文件,都没问题,其中2MB的是个Rar文件,能正常解压缩,说明应该是没有一个字节是错的了,而且速度在局域网内也基本在一个可接受的范围内。  昨天传文件的时候,还一直会丢失些数据,反正发送端是应该没什么错的,老老实实把整个文件的内容都读出来,然后一次1KB左右发出来,可是接收端总是收到不在期望内的数据,或者就是收到几个数据包后,就再收不到什么数据了。当时我还怀疑是不是因为发送得太快,但又觉得加个延时进去明显不太合理;又怀疑是不是收到数据包的顺序可能跟发送的顺序不一致,所以还试了试给数据包加入序号,但这个举措明显解决不了前面提到的两个问题。昨天可谓是毫无头绪,连猜带蒙地整了一天,结果就是证明了那些想法都是不可行的。  今天也算是灵机一动,想到了曾经看到过http下载文件,多线程下载时,就是可以指定下载文件的偏移量,于是我想,我也这样做,而且每次只发送一小点,接收端收到后再请求下载另外一部分,这样就直到把整个文件下载完,于是,果然可以完整地传输完整个文件了,虽然代码写得很dirty。现在想起来,在这样的策略下,要让这个操作支持断点续传和多线程下载也不是很麻烦的事了。  搞定了文件传输问题后,感觉心情一下舒畅了很多,换了另外一个工具的维护工作,要增加一个新功能,当时我估摸着可能要花些时间,于是跟那同事说要2天工作量。也不知道是不是心情好的缘故,不到3个小时就几乎搞定了,同样代码写得很dirty,而且这个工具最初代码是另外一个已经离职的人写的,他的代码风格跟我的路数不一样,我在这样的基础上进行维护,代码看着要多别扭就有多别扭。不过这只是个小工具,功能很弱很少,所以这些都不用太关注,要求实现的功能做了就行了。  之后又看了一会儿dot的user guide,开始还以为用它来画流程图很符合格式化后流程图的显示的形式,只要用一组比较清晰简洁的语法,直接可以生成一张图片,但是后来发现我这工具中对流程图的可控性要求比较高,不但要求显示,而且要求一定程度的编辑的能力,即需要能随时方便地知道某个坐标下是哪个节点,或者某个指定的节点在哪个位置,但是今天看了dot的只是直接输出成某种图片的格式,可能比较复杂。现在想想还是有可能知道是,比如SVG、PS之类的格式dot也是直接支持输出的,这类格式的文件其实是文本内容,应该保存有这类节点标识和位置信息的映射关系的,只不过再要解析它们,复杂性如何就不得而知了。

自省

  中午睡过午觉走下楼,在拐角的地方看到一个男的,直觉得好眼熟,想了一会儿终于想起来,不就是这些天在食堂吃早饭时经常看到的那个男的吗,当时还心想这男的长相也实在不咋的了点。可是这次匆匆路过的一瞥,却让我自惭形秽了起来,我缺少成熟的气质,而且缺乏自信。所以我一直都有意无意地走着邋遢路线,装着吊儿郎当的样子,抱守着那残存的点点自尊心,却是没来由的自负。  为什么没有自信,说到底还不是跟自身拥有的客观条件有关系。真正拥有强大自信的人,实际上要么确实是自身拥有超乎常人的才能,或者是有其他强势的物质依靠,而这些也正是我缺少的。

调了一天ACE

  上周没调完,今天接着调,调了一天,勉强可以实现点对点文件传输了,但还剩下不少问题,比如我会在服务器端先读入整个文件,如果该文件很大很大,岂不是很占内存,如果超过了物理内存的容量,要动用虚拟内存,岂不是效率又会降低不少!这只是众多问题中的一个,还有其他各种问题,只能走一步算一步了,关键是先把容错性做好,不要动不动就崩溃。  现在的情况是一个程序里,又当服务器端,又当客户端,两边我都是用reactor实现的,其实我对其中的工作原理一窍不通,只不过抓来几个例子,照着书上写的拼凑起来,好在调试工具还算好用,加上一点点的抽丝剥茧,总算理出点头绪,也得到些经验教训。  首先,不要为了图省事而使用那个全局单件reactor对象,我开始的时候服务器和客户端共用这个对象,后来觉得不妥,把客户端的改成一个客户端连接临时生成一个reactor,使用调试工具发现勉强可以用了,服务器端却不会自动调用handle_output,后来把服务器端的那个reactor也换成自己生成的,竟然也可以了,也许是我没用对,但反正现在它几乎能运行起来了。  其次,无论reactor是用在服务器端还是客户端,都要run_reactor_event_loop一把,这个调用一直不返回,大概直到end_event_loop之后才返回吧,所以要另开一个线程来调用,除非是不想干其他事情了。这样,还可以看到一点,就是在适当的时机,要调用这个结束的方法。这和boost.asio的做法很相像。  再次,发现ACE_Message_Queue里居然只能存入16个最初压入的记录,后面再压入的全都被丢掉了,也不知道是不是有方法可以扩充到更多个数的,或者我觉得STL里的deque也不错,可以在头尾任意一端进行存取,不过ACE_Message_Queue似乎可以通过模板参数指定线程同步等选项,deque大概就完全要靠程序员自己把握了。  最后,要调socket程序,拥有和掌握好用的调试工具实在很重要,Wireshark这个开源的东东实在不错,只不过公司里居然装WinPCap是受限的,不过那个检查工具是防君子不防小人,好在可以通过改注册表中的卸载项来骗过它。另外从公司网上找到几个可以模拟TCP/UDP的Server/Client的小程序,很容易用,有这样的工具,就可以先调试其中的服务器端或客户端,等这样单独的调得差不多了,就可以进行联调。不然同时联调的话,出了错还不知道到底是哪边的问题。

从今天开始重新魔王

  记得曾经有一段时间,我把自己的昵称或ID说明栏上改成“从今天开始魔王”,这是一部日本动画片的名字,当时觉得这个标题很适合自己的处境或心境或志向的,也不是说魔王要干坏事,而是要像入魔一样地写程序。当时确实有那么一小段时间,读书的时候也好,工作了以后也好,有点空闲的时间就去写代码,或者上网看编程相关的内容,或者买书看,或者就泡那些编程论坛BBS。结果后来还是不了了之,尘世的诱惑实在太大,哈哈!  今天心血来潮打开久违的VS2008,打开最近创建的一个工程,看了一下SVN里的提交记录,最近一次是22天前,而想想22天前的那次提交,其实也不是自己写的代码,只不过是把别的地方的一些代码复制过来而已。  这些代码在那样的需求下,工作得很好,可是我需要它能再更进一步。昨天重装了VS2003、VS2005和VS2008,但发现2008那个RC1107错误依然存在,于是外事不决问google,发现一篇文章,果然不止我一个人有这问题,很快解决了,看了看我的配置项,最后一个include的目录尾部的字符赫然是个反斜杠,换个末尾字符不是反斜杠的放在最后,试了试OK了,哈哈,仰天长啸!  另外又看了看CppNPv2,里面关于ACE_Message_Queue的说明,原来这个消息队列有一种功能,可以限制存放在里面的最大的数据量,默认为16K,回想白天在公司里,因为我给每条记录是1024个字节,每次16条记录不就刚好是16K嘛,我汗颜!  用VS2008写代码特别安逸啊,本身就已经做得挺不错的了,而且加上VAX的辅助,现在我已经真的再也离不开它的自动完成和重构功能了!也不知道是VC2008的编译器确实改进了,还是我的机器的内存足够大(1.5GB,用XP一般情况下根本用不完),反正觉得它编译速度好快啊!想想在公司里那个P4 2.6G,因为搭配了512MB的内存,用VC2003编译个东西,那个老牛拖破车啊,不过我已经申请加1GB内存了。  还有,就是前段时间买的那个键盘打字果然很舒服啊,仿笔记本的超薄型,现在天气热,再放在本本上要烫死了,打着打着就会不自觉地加重手势,感觉超爽,哈哈!  从今天开始重新魔王!

VS出问题了

  发现机器上装的几个VS出问题了。6.0不说,因为压根没想过要用它。2003出问题似乎是最早的,大概是因为最早用得最多,就出问题也早,发现问题也早,现象是时不时弹出个消息框说什么GDIPLUS怎么出错了,而且一弹就会连续地弹好几次,让人受不了。2005本来还没怎么发现问题的,因为不常用,要用也是2003或2008,当时只是发现它的菜单怎么变中英文夹杂了,也没怎么在意,反正看得懂,最近一段时间想用它来创建个工程,发现这个wizard不能用了,估计也是因为这本地化引起的,老是去不存在的目录下查找那些html文件!最后说2008,2008是今年开始用的,春节回家的时候用它来写WallpaperHelper,当时安装的时候也费了些力气,新建个MFC工程来编译,发现还缺几个.exe文件,抱着侥幸心理从2005那里照着文件名拷贝过来,发现勉强也能用,结果今年上半年堕落颓废了,看小说去了,几乎写过代码,现在发现2008里的资源编辑器不能用了,资源视图里都打不开资源,只是报个RC多少号的错,我也懒得再去查这是什么错了,反正这个资源文件是肯定没错的,郁闷死!  没耐心继续跟它们耗了,直接卸载,重装!

奥运会闭幕了

  时间过得真快,我们国家为了承办奥运会,准备了那么多年,从第一次申办失败,到后来申办成功,再到各项准备承办,两三年前就开始倒计时,还有几百天开幕。而8月8日开幕式,感觉就是昨天一样,当时还忿忿不平地说开幕式不好看。今天就是闭幕式了,还是老样子,除了排场足够大以外,其他的我确实找不出好的来了,从色彩,到音效,或者意境,反正没有一项是我喜欢的,也不知道花费了多少人力物力,当年各种专家预测的,奥运会期间给中国经济带来的巨大好处,不知道是否都应验了?  作为东道主,中国确实历史性得获得了金牌榜第一的骄人战绩,但又一想,金牌多带来的又是多少好处呢?看到一些报道说,有些国家,比如美国、加拿大,那里的很多运动员都是业余的,平时都是有各自的工作,政府并不给运动员们发放多少金钱上的补助,相比之下我们国家的运动员呢?出了成绩,还说得过去一点,但成绩很差的那些呢,比如男足,那些钱都是从哪里来的,最后又花到哪里去了,是不是浪费了?我们国家作为发展中国家,却在这些方面作为远不如那些发达国家英明和有远见。  算了,也是一家之抱怨,没意思啊!

想写个文档收集管理工具

  昨晚在整理硬盘上的电子书,顺便想到我零星收集的n多资料,一般就是一张网页,或者一个txt文件,里面可能是一篇文章,或者一小段代码,却很可能讲述了一个技术原理或一个小小的编程技巧,我没有计算过总共有多少个这样的文件,估摸着应该有几万个吧,这些只是平时上网,看到觉得有用才收藏下来的,不像那些电子书,很大一部分是去年从一个同事那里直接拿硬盘对拷过来,有些根本不是我关心的领域的,比如无线通信之类的。  这些文档散落在硬盘上,虽然我也大体上划分了一些分类,比如algorithme、crack等等,但当真要找某个比较细节的内容时,很可能要花很多时间,还不一定能找到。于是我就想,要是有一个适用于编程资料收集管理的工具就好了。我是懒得再去网上找了,先不说能不能找到真的完全符合我的要求的软件,即使有(这个可能性很小很小啊),也不一定是免费的。以前看过几个文档收集管理工具,要么是纯粹的通用工具,缺少对编程资料的倾向性适配,要么就是纯粹收集源代码的,又缺少对文字内容的支持。所以又回到原来我说过的一句话上来,最好用的软件是自己写的。  以前用BCB写过一个电子书管理的工具,花了些时间,但实际上并不好用,界面也其丑无比,太业余了,这是促使我后来义无反顾地投入VC阵营的重要原因之一,在像XTP、BCG之类的界面库帮助下,用MFC做界面其实并不比VCL麻烦,而且以我个人的经验看来,在同等工作量投入的情况下,反而更容易做出比较专业的界面来。又跑题了,那个电子书管理程序的功能太弱,虽然当时也想过不光要能管理电子书,还要能管理普通的文本资料,但后来由于对界面的极度不满意,直到完全失去了兴趣和信心,就放弃了。  现在想用MFC+XTP写一个,数据库就用SQLite好了,不光能管理文本资料,也能管理电子书,这是我比较希望的一种方式。管理文本资料时,需要特别关注,可能有两种不同类型的内容,一类是文字描述,一类是源代码,所以要同时有两个视图来表达一份资料的内容。资料的分类管理是必须的,而且更需要的是一种比较方便的搜索功能,不但要能搜索标题,还要能搜索内容。再有就是文本资料和电子书的管理要融合在一起,看起来没有特别明显的分界,但又留有余地可以完全分离开来。  这个工具不是通用目的的,是为程序员专用的,所以用户范围可能少了点,但这也算是围绕着我的整体规划目标了,developing for developers!

相比之下SVN比VSS更好用

  最近这段时间,SVN和VSS混用,有些工程是放在SVN里的,有些是放在VSS里的,但总的说来,感觉SVN更好用些,也许VSS 2005已经提供了各种现代化的特性,但直到现在,我还只是以VSS 6.0的眼光看待。  SVN在编辑前不需要check out,这点我就很喜欢,在VS 2005中,可以设置得让IDE自动check out出来,但离开了IDE,还是得自己去做这点操作。现在我用的VS 2003,就会自行弹出个check out确认对话框,这让用过SVN的人觉得很不耐烦。尤其是在某些情况下一个操作会要求先后对多个文件进行编辑,这时VS 2003就会不厌其烦地一次又一次地提醒要check out每一个文件,比如要编辑资源,就会要改.rc文件和resource .h文件,如果是添加一个新的类,就会要求编辑.h和.cpp文件等等。  但是SVN也有很让人头痛的问题,比如它完全依靠文件夹下的.svn文件夹工作,而且似乎很容易出错,出错了还不容易修复,VSS就很少这类问题。还有就是似乎代码仓库也有类似的毛病,容易出错,出错也也不容易修复。  今天得到一个经验,如果一次性要添加很多文件夹和文件到仓库中,最好不要用add和commit操作,而是用import。前者需要2步人为的操作,所以感觉要花费更多的时间。今天我就是需要添加4个文件,总共有130MB左右的数据量吧,n多个文件,用add还正常,commit时还会执行adding操作,然后是send content,到中途不知为何就阻塞在那里了,等了一会儿耐不住性子就x了窗口,到仓库里delete掉看到的几个文件夹,却有一个文件夹之后总是add不了了。后来改用import,就全加上去了,汗!  但是如果是一点一点来的话,我更愿意接受SVN这种工作方式。