首页
归档
分类
标签
软件
关于
链接
订阅
代码
类库大魔王的挖井日记
挖一口属于自己的井
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的小程序,很容易用,有这样的工具,就可以先调试其中的服务器端或客户端,等这样单独的调得差不多了,就可以进行联调。不然同时联调的话,出了错还不知道到底是哪边的问题。
« Prev
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
Next »
发现
→
imported from CSDN (124)
Film & ACG (15)
Water (170)
Shareware (151)
Software (140)
Plugin Framework (28)
lookfor (36)
CPPOOPGPXP (87)
Lua,Script (51)
Be Old (15)
Job (185)
mm (48)
Emulator (3)
Execise Outdoor (13)
gfw (10)
Reading (20)
Driving (16)
Mobile (15)
wxWidgets (29)
WIND (14)
PSP NDS (2)
CodingStudio (44)
Cryptography (2)
Editor,IDE (5)
TeX (1)
Life (82)
Technic (6)
Qt (28)
SNS (35)
Ninayan (35)
GUI Framework (1)
KarenMeu (1)
Kindle (3)
Coding (14)
Startup (6)
network (14)
Go (10)
idea (1)
os (1)
iOS (1)
Cloud (1)
device (2)
embed (6)
gochess (1)
Router (3)
blog (4)
Blog (2)