All Stories

证明自己在这个世界存在过

  昨天上午跟大领导谈了后,基本确定下来辞职的事实。这2周多来,几次同领导们沟通,都被问及到底是什么原因要离职,我都一直以身体抱病需要休息,家人意见要我返回老家以及失恋之后精神不济,工作状态极差等等这些事情做为理由。嗯,其实我说的都是事实,当然也许还有一些没说出口的原因,毕竟作出一个决定,尤其是对自己来说是个关系比较重大,影响比较重大的事情,肯定是有很多原因掺杂在一起,只不过有的比重大些,有的小些而已。  昨天中午跟王同学在食堂吃饭,我兴高采烈地跟她讲我怎么和领导沟通,我要怎么处理剩下的事情,以后我有什么理想等等,荣荣就说我好兴奋啊,还真是脱离苦海了。兴奋只是暂时的,之后便是接踵而来的麻烦事情需要处理。  星期天在江江家打牌时,看到一个电视剧,里面一个坐在轮椅上的青年男人歇斯底里地大喊“我受够了,我什么都没有,我没有钱,没有健康,没有爱情……”,沉重地拨动了我的心弦。那不正是现在的我的真实写照吗?记得前些日子跟王同学在QQ上聊天,她还说“可怜的胖胖,出来几年,带着一身病回去了”,我当时可真是郁闷坏了,我可不希望这样被人同情,被人怜悯!但那却是事实。当在电视上听到那几句嚎叫时,我的心情很压抑,不过好在我马上想清楚了,我跟电视上的人是有区别的,最大的区别就是我没有绝望。我仍然对自己的未来充满了希望,尽量到目前为止,情况并不乐观,但我的选择是挣扎,而不是放弃。我不过分乐观,保持着一点应有的悲观和警惕,却不失强大的自信。我有的是远大的而自认为还算高尚的理想,并且坚信自己一定能通过努力在这条路上走下去,直到收获成果。  这些日子的所见所闻,加上和人讨论得到的启发和自己的思考。我略有点惊讶地发现,原来自己还是有点儿事业心的,只不过跟旁边的大多数人都没取得过一致意见而已。就说那天去江江家打牌,事后回想起来,真觉得有点后怕,人多了还可以一些打个牌,聊个天,要是两个人这么静悄悄的下午呆在家里,可以做些什么?还有上次,小思宇来深圳,把我叫去一起去小妞家里,那第二天下午,4个人打牌打累了,就一个一个倒在客厅的沙发上睡过去了,我也觉得后怕。那不是我想要的生活,至少不是现在的我想要的生活,那太缺少激情和活力,懒洋洋而无所事事是我很害怕面对的状态。我希望在自己有精力有能力的时候,做些事。难得活一次,做一回人,总得做点事情,留下点痕迹,证明自己在这个世界存在过……

今天面了几个人

  也算是体验了一把面试官的感觉,好好玩哦,看着有些人紧张的样子,想想当年自己在学校时那紧张的情形,只能感叹时间的匆匆流逝!

用Beamer作幻灯片后想

  昨天在公司里说到,以后要多作培训,多作交流,这种事情我倒是有点儿兴趣的。培训、交流,那么幻灯片是必不可少的,于是回来后就开始捣鼓Beamer。  因为就我了解的用LaTeX做幻灯片就只有PDFScreen和Beamer两种方式,而看过实际效果后,更喜欢Beamer生成的那种。以前也用Beamer做过一个非常简单的,这次我想好好研究一下,可以做出一些比较好看的效果来。  经过昨晚和今天上午的折腾,基本掌握了一些常用的用法。总的说来,还是比较满意的,虽然速度上比较起PowerPoint这种工具慢了不少,但心中还是比较满足的,主要还是熟练程度上的不足,以及缺少良好的工具支持(呃,就是直接拿UltraEdit编辑的)。所以更坚定了我要做一个TeX代码编辑器的想法。  因为这半年来使用MediaWiki的粗浅经验,让我对TeX的用法有了更多的理解。这所谓的“所想即所得”实在只是为了就对Word之流“所见即所得”才勉强杜撰出来的词汇。在我看来,这个TeX的设计思想,就是典型的西方人的思维方式:懒散、直接、天马行空。对于几千年来接受着严谨、务实、勤勉思想熏陶的中国人来说,一时间还真有点转不过弯来。在TeX中用这样的描述方式:我把这些文字作为标题,把那些文字作为章节名,还有些其他的就是正文,而至于标题、章节名和正文应该用什么字体,什么大小,什么颜色,什么对齐方式则不是当前我应该关心的事;而我们往往已经习惯了这样的做法:我把这些文字设置成黑体四号,居中对齐当作标题,那些字是楷体小四,左侧对齐,当作章节名,还有剩下的就宋体五号了,首行缩进两个字符,就是正文该有的格式。  就这么对比着来看,所见即所得容易催长用户做出花哨的排版,用户放了较多的精力在如何定制排版格式上;而TeX的所想即所得则比较适合于循规蹈矩的排版任务,在排版过程中可以少费脑筋。这也就是我说西方人的懒散、直接、天马行空的原因。由此也更好理解,为什么Nokia的手机里没有树型结构的文件系统,全靠文件名来索引;为什么wiki也是这样只靠文章标题进行检索;为什么国外品牌的PC机硬盘只有一个分区了……

铁打的营盘流水的兵

  在食堂跟江江、bobo一起吃过晚饭,晃晃悠悠走向F3,没想到在楼下遇到疯丫头,最近见到她有点多啊,前不久教授来深圳,一起吃饭时就见过一次,再之前是马姐姐召集大家吃饭,也见过。她在这边刚开完会,于是就和她聊起来,我告诉她我要辞职回家了,她倒是表现出一点惊讶的样子,比较有趣的是她也跟我说一个“绝密”的事,她老大同意把她调到北京去了。  这让我越来越觉得用“铁打的营盘流水的兵”这句话来形容我司实在太合适了,真是半军事化的管理,连里面的人这方面的行为都很半军事化啊!想想我进公司这4年来,陆陆续续离开(不一定是离职)的人中,有多少是跟我比较熟的。雨烟离职去了北京,跟老公一起走的;教授是最近才离职的,不过中间也是几经波折,现在是去tsinghua读博了;骨狗是个比较有趣的家伙,离职前的告别邮件还是中英文双语版;小思宇是去巴基斯坦陪彭彭的;孙同学没离职,却想方设法调到武汉去嫁人了,瀑布汗;还有一些不是很熟的同事、同学离职的;剩下几个准备行动的,这中就包括疯丫头,猫猫也许算一个吧,一直嚷嚷着要去南京;小丫头说是年底会去上海,也算是一个吧,也是一直吵着要离职的家伙……总之,大的趋势看,都是往着离自己老家近的地方挪,嗯!

Byebye,C++Builder!

  昨天熬到快后半夜,从Embarcadero官网上把Delphi/C++Builder 2010的ISO安装镜像下载了下来,并从网上找了个一年试用的license,装好了来体验一把。  在4年的大学本科生活中,可算得上用了3年半的C++Builder,在毕业后从事测试工作的那近2年的时间里,也断断续续地用着,所以总以为自己对C++Builder的感情可能是不容易割舍的。但是经过昨天晚上和今天晚上短暂的试用后,嗯,只是把一个C++Builder2007的工程转换为C++Builder2010,编译有不少通不过的。我放弃了,我想说:Byebye,C++Builder!编译不过的地方,我看了一下,都是因为Unicode这个编译选项引起的,我粗略地找了一遍工程设置,似乎没有可以修改这个选项的。说实话,我感觉最好的版本是C++Builder6,后面跟Delphi合并使用一个IDE后的版本,差不多每个大版本都装过,但都没有让我继续用下去的念头。  出2009时,我曾自己安慰自己,彻底放弃它了,这回有了2010,还是忍不住弄来装了装,真的彻底放弃了,没有一点亮点!一款C++开发工具,我关注的是三方面:IDE、编译器、类库(框架)。曾经在BCB6.0和VC6.0的年代,这三方面BCB都是占据优势的,可是这之后的7、8年来,VC在大幅进步,而BCB却是裹足不前,VC现在都已经精进到几乎没事可做的地步了!  就让它,活在回忆中好了!

图形程序设计续之零碎问题

  图形编辑功能已经做了两周了,到现在为止,也只能画出矩形框,在矩形框之间用白线、样本曲线,或贝塞尔曲线进行连接。又一次发现,只有在编码实现的时候,才会遇到很多之前没有想到的各种问题,而且有些问题要解决,也是要花费不少功夫的。  要考虑图层的问题,如何定义每个图形所在的图层,在绘制时,才得比较方便快速,而且需要可以随时修改图形所在的图层。图层的影响是多方面的,例如在绘制整张画布及图形对象时,要从底层开始绘制,而对于在某个点上点击选中一个图形对象时,却要从上到下进行遍历查找。  还考虑随时可以修改画布的大小,因为在添加图形,或修改图形位置时,是随时都可能把图形放在一个走出当前画布大小的位置上的,这时程序应该可以自动检测出需要扩大多少。对于向右、向下方向的扩大处理很方便,直接将画布大小重新定义即可。而对于向左、向上方向的扩展,则除了重新定义画布大小外,还得把超出部分归整到(0,0)这个坐标上,也就是说,要把所有已存在的图形对象的位置都调整一遍。  再要考虑子图的问题。也就是说,一张完整的图片,在某一时刻,只是显示了其中一部分图形对象,这部分当前被显示的可以作为一个子图来对象,而没有被显示,则是属于其他的子图。每个子图之间应该没有多少强相关的关系,最多是一个图形,与一个子图可以有包含(从属)关系,一个子图用来解释一个图形。常见的一种应用场景就是,双击了某个图形,就展示另外一张图片。这就同样要求设计一种灵活高效的数据结构来保存这些信息。  从当前的实现情况看,每个图形对象中,都有不少成员变量,保存了一些中间数据,这些中间数据不属于图形对象的本质属性,却对于图形在特定时刻进行动作起着重要作用,从代码美观角度讲,感觉很冗余,所以要考虑如何优化,减少这种成员变量。例如对于一些状态变量,或许可以用位域的标识。

把最幸福的事都回忆一遍

  昨天晚上,近12点,锁好门,准备熄灯上床,却听到手机的短信铃声响起。当时我就猜,在这么个时间,说不定是那小丫头发的,不,应该是我很肯定,一定是那小丫头发的。拿起一看,果然是小丫头,那个我曾经叫她宝宝,后来一直称呼为小乖的女人。短信的内容倒比较意外,说自己头好痛,眼睛也好痛,要爆了,却又睡不着。于是我便拨回去。  两个人断断续续,说着从我毕业工作以来的两个人之间的几乎每一件事情。睡在同一个屋子里,一起逛街,一起去欢乐谷玩,给她买眼霜和书,帮她买数码相机和笔记本,她大队培训期间出去玩让我在家里着急,买了里芯已经烂了的苹果给她……她问我她要结婚了我祝不祝福她。我短暂地沉默后,回答当然祝福了。然后她就在电话那头哭起来,我问她为什么哭,是不是他对她不好。她说没什么,他对她很好很好。还说她最对不起的人就是我,我说我没有怪你,是我自己给你这个机会让你对不起我的。而且就算真的很喜欢很喜欢一个人,也不是一定要生活在一起的。以前听小思宇说起过,陈奕讯在一个访谈节目中说的,他都已经有小孩的人了,到现在心中还是一直放不下一个人,惦记着一个人。我也可以。  我给她说起我妈妈,那是一个眼光很挑剔的中年妇女,我把众多女同事,女同学的照片拿回家给她看,基本上都是挑缺点的。小丫头就说,是不是她的脸那么圆,我妈妈也是不喜欢的。我解释说,你那种圆脸,我妈妈是很喜欢的,还说了脸圆圆的,屁股也圆圆的,这样的女孩子才好。小丫头说,那她最终也没能成为我妈妈的儿媳妇。我说,那是我妈的儿子没本事,没福气。说到很少见小丫头哭,其中的一次,是那年雪灾,到了机场没车回家,给我发短信,在机场一个人哭,我正在家里吃饭,我妈问我在跟谁发短信,我说了后,我妈还叫我回短信让小丫头不要哭了,不然不漂亮了,而我却说小丫头脸圆圆的,哭起来的样子很可爱的。  还说到,我曾经在她的照片袋里看到她和一个男生的大头贴,我心好酸好痛,当时怎么那么老实,没有趁上街的机会拉她一起去拍大头贴。她说,那个男生是yaya以前的男朋友,居然让人误会了,哈哈,印象中好像也只有这么一个男生一起拍过大头贴。后来她又说到,当时我千方百计把她介绍进公司,本来是希望能离得近一点的,想不到一下就被派到成都去了,是不是当时后悔得要死。我说,后悔倒没有,就是很痛恨这个命运,想不到在命运的面前真的一点能力都没有。真的,我不但痛恨这个命运,还痛恨着这个公司,就是它把小丫头弄到离我那么远的地方去了,便宜了以后可能成为她老公的那个小子。我问小丫头,如果她还是一直呆在深圳的话,我应该还是有机会的吧。小丫头轻轻笑笑。  小丫头说,很怀念以前在深圳的日子。呃,她只在深圳呆了不到半年。我说我也是,我很怀念她在深圳的日子。  几乎把我觉得最幸福的事情都回忆了一遍,最后我说,以后不要哭了,你哭我也会难过的,你已经不和我一起生活了,那就要在其他方面有所补偿,你担负着让我们两个人都快乐的责任。

图形程序设计续之困扰

  开始做那个图形编辑程序1周多了,现在遇到了瓶颈,因为原来的设计考虑得太不全面,很多很明显的问题都没有有顾及到,结果到实际编码实现到一定程度时,发现原来的程序结构有点不行了,不够用了。  主要的矛盾在于,原本我的设计上是,每种图形,都各自响应用户操作,互相不知道其他同类的存在。而实际上这是不对的,或者说不合适的,比如连接线,在端点确定前就是要知道那个位置是否贴到某个图形上了。另一方面,当某个图形上的连接点移动时,同样得通知所有跟这连接点连着的连接线,或者是某个图形被删除时,得同时删除连接在它上面的所有连接线。  本来所有图形对象都在一个管理器进行任务分派,现在看来,至少有得有一个类,可能还是这个图形对象管理器,做更多的事情,可以查询它所管理的图形对象一些特殊的状态,还要维护图形对象间的关系,可以是一个邻接矩阵,或一个邻接链表,反正就是一个图的表示法。这些不是我现在的主要困扰,我的困扰在于,图形对象怎么来调用这些查询状态的操作。本来图形对象被那个管理器对象包含了,另一方面那些查询状态的操作得知道所有这些对象,这样的循环依赖,让我感觉不爽!

有点必要学习SQL

  话说,我并不是计算机科班出身,因此很多基础的知识都是不知道的。这不,发现SQL真是有必要要好好学习一下了。最近在很多地方用到了数据库来存储东西,于是不可避免地需要写些SQL,最最基本的SELECT、INSERT、UPDATE还是会点的,不过也仅限于在单表中进行操作。  前两天发现一个可以显著提高在Sqlite3中SELECT性能的方法,那就是建索引。因为IDE需要AutoCompletion和Calltip功能,而用于这两个功能的数据都是存在一个sqlite3数据库中,该数据库目前已经有不少数据了,光是一张记录了方法的表,就有1万多条记录,从中SELECT是经常要做的操作,所以能提高点性能是很有意义的事。自从给该表建了索引后,至少感觉上非常明显,AutoCompletion几乎没有任何停顿就提示出来了,而以前的话,有个明显的停顿,虽然这个停顿的时间并不长,但已经能让人感觉出来了。这只是一点,让我觉得学习一下SQL有好处的地方,就让我尝到了莫大的甜头。还有一点就是,有不少地方的SELECT的条件,是从这次其他的SELECT中取得的数据,而我全部都是分成一条SELECT一次操作来进行的,我想,如果能把这些SELECT合并成一条语句,应该还是能再提高点运行速度吧。