All Stories

迁户口,迁档案之二

  今天去关内给小丫头迁档案和户口,早上睡到8点多,很不情愿地起床,不过也比平时上班时晚了一个多小时了,昨晚睡得也不晚啊,怎么会那么困呢。洗漱完毕出门,已经过了8点半了,等328路,结果一直等到9点才勉强挤上一辆。  到了那公司,还不到10点,这出乎我原来的预料,心里顿时放松了一点。那么一个小公司,里面有个女人招呼我过去,我拿出迁户申请和商调函。被告知那些个人资料是要填好的,于是又打电话问小丫头那些东西怎么填。接着又被告知要交档案保管费,每月20元,从2007年2月交到2008年9月,还好不是很多,但我还是忘了拿钱上去,跑到楼下的招行ATM机上取了钱上去,结果那儿的财务部说他们不收现金的,但是大概看在我已经拿了几张红纸片的份上,乱糟糟地不知道从哪里找出一本开收据的本。最先招呼我的女人把档案都装入一个档案袋,贴上纸,盖了十几下章,然后找出小丫头的户口卡交给我,第一站的任务就基本完成了。  随后是要去高新派出所办迁入户口,因为不知道坐什么车,所以一下楼就打了个的。也不知道是不是绕路了,比我想像的要久。而且想不到那派出所在那么一个偏僻的地方,不过好在一进门就看到办理的地方,取号排队,开始还取错号了,大概一直排了半个小时的样子吧,才轮到我,那办理的大姐一看就说出我们公司的名字,看来我们公司在那儿的业务很多啊。没几分钟就办完了,时间都耗在坐车和排队上了。  出了派出所,看到路对面就是一个公交车始发站,看来只有转车了。这车也是绕路的,绕了好久,到了市民中心,本来想坐个391回公司的,结果等了10几分钟也没等到,失去了耐心,决定再次转车,先坐到梅林关,再爬上一个小巴,1点半差3分的时候终于赶回公司刷卡,这样就只需要报上午半天的假了。  坐下吃了块巧克力,因为早饭和中饭都没吃,饿啊!然后给小妞打电话,问她有没有吃的,她说有小面包。于是我先跑到人事服务中心,把户口卡和档案交回去,结果那管档案的mm说还缺转正定级表,我郁闷,这党员还真麻烦啊!指不准还得跑一趟关内,累啊,要是自己有车就好了!

终于借到《Lex与Yacc》了

  几个月前,就想从公司图书馆去借本《Lex与Yacc》了,可是从在线服务中可以查到确实有一本没有借出去,但到了图书馆就是找不到那本书放在什么地方了,图书馆的人说他们也没有办法找到,因为书要么就是照着编号放在书架上的,如果在指定的书架上没有,那就没办法了。我还为此去了几次图书馆,希望碰碰运气万一某一天他们整理的时候能发现那本没有找到的书,但是一次一次都失望而归。也想过自己买一本,但逛过深圳的几处大型书城,都没有找到过,从网上倒是能看到介绍,可是都是断货了,太郁闷了!  昨天觉得该去还那本《Windows技术内幕》了,虽然借了三个月,但没看几页。到图书馆一看,惊喜地发现有一本《Lex与Yacc》静静地躺在柜台面上,看来是刚刚有人还回来的,连忙抢到手中。  实在觉得这词法分析和语法分析在处理模式化文本时太有用了。说起来虽然现在在做那个劳什子一体化平台,可是我心里却一直想回去完善编辑器,简直有种生不逢时,壮志未酬的感觉。本来同事是有一种语法解析组件的,大概浏览过那代码,其实是从ruby源代码里抠出来,在某一阶段直接把语法分析树dump出来。不过不知道为什么在源代码超过8000行时,分析出来的行号总是过绕接,从头开始。我也没仔细定位过这个问题到底是哪里出了错,主要是那代码全是别人写的,而且用了一些我个人极不喜欢的处理方式,我就懒得再去查错和修正了。我宁可自己再写一个解析器,因为我知道用lex和yacc可以做到。当时简单地看过ruby的源代码,发现它的词法分析器并不是用lex生成的,并且里里有一段代码是用gperf生成的,于是以为gperf也是一种词法分析器生成器,后来自己用了gperf才明白过来,原来ruby的词法分析器是手写的,其中gperf生成的那段代码只是为了识别出其中的保留字而已。而语法分析器确实像是用yacc生成的,不过由于ruby的语法太过于魔幻,所以语法分析器似乎复杂得超出我的想像。如果我回头再去做编辑器,这个语法解析器势在必行,不关是为了解析出语法树显示出来,另外还有些用途。其中之一是,其中有一个另外的需求是将表格化的描述与脚本来回转换,如果没有可靠的语法解析器支持,这个需求要实现就实在太过困难了点。另外还有个需求,是前两天才提出来的,说是要能跳转到方法定义处,于是当然要知道方法定义的位置,而这位置当然需要事先准备好。本来还以为rdoc从源代码中提取文件时可以顺便提取出来,后来同事一说,yaml中并没有保留文件名和行号,所以还得想办法提出来。我一想这个就太不可靠了点,万一某些方法就是没有注释文档呢。所以一定要另外有个模块来提取方法定义,我当时想到了ctags。今天试了试,发现用ctags还是有些缺憾,它只能提取出方法名称,以及匹配该名称的正则表达式,而并没有行号。另外,看了看ctags的源代码,发现另外更严重的问题,ruby并没有说定义方法时def关键字和方法名一定要在同一行中,如果是不同行中,ctags就不行了,所以还是得实实在在的语法解析器出马啊!  当然,像ruby这种比较复杂的语法解析,我不需求全部自己从头开始写起,可以抄袭一部分它的代码,至少词法分析器大部分可以直接使用,而那语法解析里把BNF留下,把动作换掉, 这样虽然还是要读懂那部分代码,但总比全部自己来轻松多了,而且也可靠得多。  得稍微系统点地学习一下lex与yacc了。

Google终于也出浏览器了

  今天在公司就发现有人传了个chrome的完整安装包上来,都没有安装过程,直接双击,过n秒钟的后,窗口就弹出来了,很简洁,简洁得让人感觉像是个玩具。只玩了两下,就没了新鲜感,就凭它现在的状态,它是吸引不了我的,我还是继续用回Firefox,那些使用习惯设置,插件,都已经成为我暂时离不开Firefox的理由。  回家打开Google Reader一看,n多blog和discussion在描述chrome,顺便让我有那么一点点惊喜地发现这还能直接从svn里下到源代码!不过就像其他的各种开源源代码一样,不到真的要用时,我是决计不会去看这些源代码的,尽管我确实已经下了不少源代码了,包括Code::Blocks、CodeLite、notepad++等等,都是因为在某些时刻突然觉得这些源代码有一定的参考价值,而且update这些源代码也成为我每次打开电脑后几乎必做的一件事。但实际上,我却还是没有真正能从这些源代码中获取过多少有用有价值的东西,这不怪这些源代码,而要怪我自己。公司里有个牛人,看部门似乎是个做硬件的,却好像看过n多开源项目的源代码,包括那些BSD系统、Linux系统的,实在佩服这种人的毅力和恒心。  Google出浏览器了,对最终用户来说,也许是件好事,这样激烈的市场竞争,能促进产品进步。当然可能就苦了Web开发者,不同的浏览器之间必定有些不兼容的情况存在,而Web开发者则必然需要为了兼容几大主流浏览器而煞费苦心。  对于我来说,暂时影响不大,继续留守Firefox 3观望中。

唯心主义的领导

  此乃人生之大不幸,竟然让我遇到了。什么事情到了他嘴上都是很简单的,任何问题他都可以说得睁着眼睛理直气壮地说没有难度,还会装着问你一下有没有困难,如果你说有困难,他就会很不屑地说,这有什么难的,不是很简单吗!有着这样唯心主义的领导,事情做好了,是理所当然的,事情做不好,简直是罪大恶极。  也许这就是所谓的驭人之术,可以被手下看不惯,甚至觉得愤怒,想法可以荒唐不切实际,但最终在一定程度上某些方面确实有所输出。  工作以来,从来没有这么气愤过,最多是有过深深的失望和无奈,但这次真的是愤慨。  我已经没有心情再跟他争辩了,反正无论怎么争辩都是做无用功。有句很流行的话,把生活比作被强奸,我想这句话套用在工作上也是恰如其分的。无论做什么,我同样是拿着这点微薄的工资,没了我,地球依然会转。  最近倒是隐隐有种感觉,似乎自己写的代码,结构组织方面比以前要做得好一些了。但在那种大框架,或小技巧方面,还是没有长进。一方面,半路出家,没有经过系统的学习培训;另一方面,缺少大型软件架构设计的经验;还有,编写代码行数确实还不多。  在技术方面的追求,未来的三到五年还是不能放下的,毕竟我年纪也并不大。只是除此之外,也要多关注学习一下其他诸如管理、营销之类的知识,这些方面跟技术才能相辅相成吧。

被人pk了

  无限佩服cracker们,25日发布的Tiburon,今天偶然发现网上已经有对应的xx出来了,对于这种叫好不叫座的产品,实在是致命的打击。  今天又被叫去汇报,气死我了,我的脾气现在也实在不是很好,可是又不能把人家怎么着。啥也不懂,却要装做啥都懂,偏偏又能以权压人。这样的社会真是太可恨了,这样的世界实在太没趣了。于是下午几乎就没什么心情干活了,随便整了一下,反正代码check in后CruiseControl会自动编译打包的,所以就出去闲逛,跟人聊天吹牛。一直到快下班的时候,才发了个邮件说可以下载最新的安装包了。  倒是看到同事在用一个叫EA的东西,全称是Enterprise Architect,简单说来是个像Rational Rose一样的东东,用于画画类图、序列图,然后可以通过简单的配置直接生成代码框架。我问了下同事,跟Rose比,有什么区别,同事说EA功能多,支持全流程,而且体积小,才几十MB。然后我就顺便跟他扯起来,说我们也可以做个这样的东西,他就说这是需要一个公司来做的。于是我就举出StarUML的例子来说明,三五个人也是可能做出来这种东东的。  想起来,做为一个开发工具供应商,比如原来的Borland,除了提供IDE,即开发阶段的支持,另外对设计阶段的支持也是很重要的,特别是现在各种软件工程方法论的越来越盛行,所有开发者,对建模的重视程度也是越来越高,现在好用的,功能强劲的,确实基本都是价格昂贵的企业开发,像StarUML这样的已经是免费软件中最好的一类了,其他廉价或免费的质量能达到这种程度的,确实也很难找到了。这类软件的利润应该很高,但估计对售后培训等的需求也比较高。

一天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的小程序,很容易用,有这样的工具,就可以先调试其中的服务器端或客户端,等这样单独的调得差不多了,就可以进行联调。不然同时联调的话,出了错还不知道到底是哪边的问题。