All Stories
无限佩服cracker们，25日发布的Tiburon，今天偶然发现网上已经有对应的xx出来了，对于这种叫好不叫座的产品，实在是致命的打击。 今天又被叫去汇报，气死我了，我的脾气现在也实在不是很好，可是又不能把人家怎么着。啥也不懂，却要装做啥都懂，偏偏又能以权压人。这样的社会真是太可恨了，这样的世界实在太没趣了。于是下午几乎就没什么心情干活了，随便整了一下，反正代码check in后CruiseControl会自动编译打包的，所以就出去闲逛，跟人聊天吹牛。一直到快下班的时候，才发了个邮件说可以下载最新的安装包了。 倒是看到同事在用一个叫EA的东西，全称是Enterprise Architect，简单说来是个像Rational Rose一样的东东，用于画画类图、序列图，然后可以通过简单的配置直接生成代码框架。我问了下同事，跟Rose比，有什么区别，同事说EA功能多，支持全流程，而且体积小，才几十MB。然后我就顺便跟他扯起来，说我们也可以做个这样的东西，他就说这是需要一个公司来做的。于是我就举出StarUML的例子来说明，三五个人也是可能做出来这种东东的。 想起来，做为一个开发工具供应商，比如原来的Borland，除了提供IDE，即开发阶段的支持，另外对设计阶段的支持也是很重要的，特别是现在各种软件工程方法论的越来越盛行，所有开发者，对建模的重视程度也是越来越高，现在好用的，功能强劲的，确实基本都是价格昂贵的企业开发，像StarUML这样的已经是免费软件中最好的一类了，其他廉价或免费的质量能达到这种程度的，确实也很难找到了。这类软件的利润应该很高，但估计对售后培训等的需求也比较高。
开了一天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也是直接支持输出的，这类格式的文件其实是文本内容，应该保存有这类节点标识和位置信息的映射关系的，只不过再要解析它们，复杂性如何就不得而知了。
中午睡过午觉走下楼，在拐角的地方看到一个男的，直觉得好眼熟，想了一会儿终于想起来，不就是这些天在食堂吃早饭时经常看到的那个男的吗，当时还心想这男的长相也实在不咋的了点。可是这次匆匆路过的一瞥，却让我自惭形秽了起来，我缺少成熟的气质，而且缺乏自信。所以我一直都有意无意地走着邋遢路线，装着吊儿郎当的样子，抱守着那残存的点点自尊心，却是没来由的自负。 为什么没有自信，说到底还不是跟自身拥有的客观条件有关系。真正拥有强大自信的人，实际上要么确实是自身拥有超乎常人的才能，或者是有其他强势的物质依靠，而这些也正是我缺少的。
上周没调完，今天接着调，调了一天，勉强可以实现点对点文件传输了，但还剩下不少问题，比如我会在服务器端先读入整个文件，如果该文件很大很大，岂不是很占内存，如果超过了物理内存的容量，要动用虚拟内存，岂不是效率又会降低不少！这只是众多问题中的一个，还有其他各种问题，只能走一步算一步了，关键是先把容错性做好，不要动不动就崩溃。 现在的情况是一个程序里，又当服务器端，又当客户端，两边我都是用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出问题了。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！
