且看我的对比：

婴儿出生 <==> 肉鸭被宰，一生谓一死；

襁褓吸奶 <==> 挂上吊钩，将将第一步；

蹒跚学步 <==> 过水除毛，坎坷初遭遇；

幼儿求学 <==> 开膛剖肚，艰辛的起步；

毕业工作 <==> 高温烘焙，辛苦中历练；

结婚生子 <==> 上料填充，色香味俱全；

挂在墙上 <==> 装入包装，痛苦的终结。

最为关键的是，在特定的阶段，都有特定的步骤在前方等着，终究是跳不出那个圈圈。

所以，你我都是鸭子。

Hibernate POJO Generator
http://hibernatepojoge.sourceforge.net/
POJO+DAO+JUnit+Spring Config (No Eclipse Plugin)

Salto-db Generator
http://salto-db.sourceforge.net/salto-db-generator/index.html
POJO+DAO+Eclipse Plugin

修身、齐家、治国、平天下

[sleep]
ping 127.0.0.1 -n 需要的秒数+1 -w 1000 > nul

[kill]
taskkill /f /im “进程名(如notepad.exe)”
taskkill /f /fi “WINDOWTITLE eq notepad*”

其中/f表示强制，/im表示image镜像名(可执行文件名)，/fi表示filter，后面跟表达式，比如这里的”窗体标题等于notepad*”，支持wildcast通配符。

via Read Sean

另外一个不错的站点：
http://www.cn-dos.net/forum/forumdisplay.php?fid=23

我不上网，是对自身生命的一种把持方式。因为生命是由“时间”和“注意力”组成的，而最有可能夺去我的“时间”和“注意力”的，就是信息的洪水。信息看似重要，其实未必，百分之九十九是消耗性的。它会造成一种假象，似乎你占有了它，其实，恰恰是它占有了你。

——余秋雨

就这样吧。

适逢岁末，上来涂写几笔，当做年终盘点吧。

国家大事记
===============

迷信在国人之中是占有相当大比例的，以至于这个承载了太多美好期望的数字8不堪重负，给我们展现了太多意料之外的画面。

08年，是出名的一年。这些名字，想来大伙儿都不会太陌生：陈良宇 黄松有 臧天朔 黄光裕 陈冠希 范跑跑 周正龙 林嘉祥 杨佳，最后，连饭岛爱也自杀了。

08年，是创造的一年。什锦八宝，俯卧撑，打酱油，囧，雷，槑…… 中国人民充分运用其源远流长的文化底蕴，让中国文化大放异彩。

08年，是天灾的一年。雪灾，地震，泥石流，触目惊心。08年，也是人祸的一年。藏独，蚁力神，家乐福，胶济铁路，刺五加，三鹿，公交爆炸，股市暴跌，金融危机，地铁塌方，历历在目。

08年，是貌似繁荣的一年。法定节假日，奥运，神七上天，改革开放三十年，听着神气。08年，也是动荡的一年。从年初的“跑不赢刘翔，一定要跑得过CPI”，到目前的“百元周”，在期盼中迎来了两岸直航。

08年，还有许多值得我们去怀念的事情。相信过段时间会有很多文章出来，写的也定然比我详尽而出色。于我，仅止于此吧。

个人小事记
===============

磕磕绊绊的从07年走来，心情时好时坏，遭遇跌宕起伏。

试着去规划。设定目标，按部就班，断断续续坚持了小半年，又没了下文。

试着去学习。比起往年来，今年看的书已经算是不错的进步了。自我表扬一下。

试着去思考。或许还不够精彩，却也是一点一滴的凝聚。上帝若发笑，那就随他吧。

试着去怀念。体验人生的悲观离合，感悟生命的潮起潮落。

试着去经历。年初的时候兴致勃勃做跳槽准备，后来仍流于书面，归根到底是执行力不够。再后面经历了裁员，各类面试，冷脸热茶，摸爬滚打，倒也不失为一番境遇。

试着去抉择。有些事情很难说就是对或者错，不同的时间不同的心情导致不同的选择，造就了将来完全不同的道路。或许会遗憾，或许会感慨，人生却没有ctrl+z。对不起，我又文思泉涌了。

试着去总结。

试着去记录。

08年，大抵也就如此吧。

其实在回答这个问题时，脑中冒出来的第一个答案是：人最难了解的莫过于自己。在大脑作出判断之前，它已经把潜意识中认为正确的答案给了出来。换句话说，那是你自己大脑的主观判断。说的有点绕，不过就是这个理儿。

但是面试的时候总不能这样忽悠考官，所以还是具体来谈谈。

总体来说，我不能算是很聪明的那一类人，但也绝不能算笨。从很小时候上学开始，就发现有些问题一想就明白，有些要想上老半天，还是似懂非懂的样子。大学里头刚开始念的是数学系，也就是在那时发现，人跟人的差异确实很大。同学中天资聪慧者有之，亦不乏资质愚钝之人。自己介乎两者之间，好在很多时候勤以补拙，一路走来尚属顺利。

最大的特点应该是耐心。加上一点点勤奋，可以对某个问题进行持之以恒的研究。往往也正是这样的执著，驱动着自己不断对新事物加以尝试。带来的一个副作用就是偶尔会有点不计代价，所以不会是块经商的好料子。

最大的缺点当属分心。在研究某个问题的同时必然会牵扯到一些新问题新知识，不知不觉会沉醉其中而忘了主题。相应的，兴趣太多也不是什么好事，从技术上来说往往是广度有余，深度不足（顺便提一点，现在很多公司都提倡专业化，所以一般而言是深度要求高于广度）。

学的是理科（后转工科），却又处处可以见到夹杂在其中的文科影子，所以是一个复杂的混合体。于文于理都不算很冒尖，各自掌握的倒也不错。性格中多少还有些完美主义的影子，总希望以最优雅的方式来解决问题。这些是优是劣就见仁见智了。

凑合着写的很乱，本身这些就是不太容易整理的东西。

朋友们见了，也可以补充补充。相信你们的眼光，一定有比我独到之处。

就在刚才，专心享用那仅剩的几个小核桃的时候，无意间发现个个都是满口留香，跟之前动不动吃到坏的情况完全不同。之后洗澡时忽然脑袋灵光闪耀，发现这个事情跟个人做事习惯隐隐相合。

一直以来，我吃核桃的时候会把半个的、裂纹大的、容易剥开的先挑来吃了，然后再慢慢对付剩下的。这样做比较省事，不过有个副作用就是吃到坏的概率也很高。而那些比较密封的，裂纹少的，往往是被留到最后。今天却无意间发现它们反而是最香、最好的。

这是不是也印证了容易得到的往往不是最好的道理？还是想证明要获得比较好的回报（最好的核桃），就需要付出更大的代价（对付那坚硬的外壳）？又或者，以后得改变习惯，一开始就攻坚，争取在最短时间内得到最大的收获（会不会又掉入太功利的陷阱）？

也许，核桃们也在想这个问题。

摘录下来，作为自己将来需要抉择时的辅助参考。

有兴趣的，可以点此前往：痛苦的选择：不再只专注于技术

评论同样精彩。

—————————–

以下为全文引用（防止将来某天源地址不能访问）：

我很长一段时间都在煎熬中度过，已经快到而立之年，对自己的发展方向、前途却还很迷茫。这么多年来，我一直受兴趣指引，走了很长的路，或曲或直，但我从来没有后悔过。可决定未来的方向却让我痛苦不已。

1987年，我开始在CONMAX（记得不是很清楚了）机器上学习BASIC，从此和程序语言结下了不解之缘。当时学校仅有两台苹果II型电脑，我们连碰的机会都没有。CONMAX机器开机就是BASIC，没有操作系统，没有磁盘（使用录音机记录程序），在这样的机器上，我和我的同学们用SHAPE 命令编程序在屏幕上写自己的名字，写赛车游戏、碰碰球游戏。编程给我带来了无穷的乐趣。

93年考入大学，因为当时外贸非常热门，我放弃了感兴趣的自动化专业、机械专业，开始学习工业外贸。由于是工业外贸，所以在课程设置上包含了机械、电子、经济、英语、外贸等方向的多门课程。凭着自己的兴趣，在机械相关的课程上，我的平均成绩不在97分之下（画法几何还考了100分）。这也奠定了后来学习Auto CAD、3DS MAX的基础。电子类课程成绩也不错，基本上都是班中第一。我对外语和外贸并不是很感兴趣，但在周围同学的强大压力下，还是以73.5分的成绩通过了六级考试，并在全院第一个拿到了BEC2的证书，更没想到的是5年后我竟然成为了BEC的口语考官。

大学的生活非常紧张，除了在学生会任职之外，我还把学校中所有的计算机培训班课程学了一个遍，在这期间我接触了PASCAL、C语言、 FoxBASE、FoxPro，也为我参加数学建模竞赛奠定了计算机基础。1995年，学校组队参加全国大学生数学建模竞赛，我没有被选中。在强烈要求下，我作为旁听生参加了近一年半的数学建模的培训。虽经过艰苦的准备，但最终由于一个小失误导致我们组在全国大学生数学建模竞赛上只拿到了河北省二等奖。为了挽回失去的荣誉，我放弃了考研，毅然决定与队友参加美国大学生数学建模竞赛，并最终取得了一等奖的好成绩。可笑的是，在参赛获奖的两组六个人中，竟然有三个人是当时的“旁听生”。

虽然外贸专业课没有学好，但大学的学习为我的英语、数学、计算机打下了很好的基础，这也是我的兴趣带我到这一步的。毕业后留校，并转行管理信息系统。比起管理信息系统专业的学生来，我欠缺了太多的知识。我把“计算机技术”作为我的专攻方向，不断追赶。VFP、VB、DELPHI、.NET、SQL Server……甚至成为了MCT，在计算机技术上走了很远。

现在，我忽然发现“累”了。我发现我对编程、对计算机技术不象以前那么专注了。我更加感兴趣技术后面的东西：设计模式、分析模式、财务管理、营销策略、企业信息化……想起当时我的老师说管理信息系统是“数学”、“管理”、“计算机”的交叉地带，我现在花了7年的时间才明白“技术”不能代表一切。

很多象我一样对计算机技术“狂热”的人，其中一个原因恐怕是“编程”容易上手，花上个把月的时间就可以学到一些“高深”东西，并且可以编程炫耀一番了。另外，编程是创造的过程，看着自己的想法付诸实现，总会有成就之感，即使程序编写的很糟糕。编程也能处处体现征服困难的喜悦，每当一个问题被解决，心里面总有一种成就感，即使这个问题早就有人解决过了。这也是为什么有人花上大量时间，用尽各种技巧用JavaScript编写一个Web控件，而根本不去琢磨是否有一种智能客户端的技术，可以使用功能丰富的Windows控件。

编程中的这种体会引导着我的兴趣，让我走了很远，也失去了很多。“专注于计算机技术”让很多人放弃了外语、放弃了数学、放弃了管理。很多人说这种放弃是心甘情愿的，你可能花了两年的时间学习英语，然而收获很少，为什么不去学计算机呢，至少能够“速成”，而且喜悦伴随着整个的学习过程。可是，这错了。编程创造的价值是什么呢？当你开发一套系统的时候，这套系统的管理内涵决定了应用信息系统的价值，而不是编程技巧的高低。编程技巧的高低可以决定开发效率，但不能决定企业应用信息系统究竟能带来多大的收益。编程是一种机械性的工作，它里面的创新并不能象优化管理流程一样对企业带来的巨大的利润。Web Service技术也不是凭空出现的，而是应企业应用集成的需求而出现的。

现在的编程技术也降低了编程的门槛（很多人的虚荣心可以更容易的实现了），寒枫天伤有一次推荐自动代码生成的一系列网站，我看了一些，其中 “Constructor”软件让程序编写.net系统变的如此容易。应用MDA后恐怕更容易。也许有一天人们不用再写那么多的代码。程序开发员的价值是否也意味着会不断贬值呢？

“开发”阵营的人往往感慨为什么中国程序员没有超过30的，为什么中国没有人能够创造出一门语言来。不再专注于技术不意味着放弃技术。过分专注技术，就会陷入一种“技术成功”做成的陷阱中，最终变成一个“快乐的井底之蛙”。另外，只有知道技术的发展方向，才能更好的专注于技术，而技术的发展方向往往不取决于技术本身。设想有一天，一个跨国公司经营的几千万种商品一小时内完成清点，配货，及时针对竞争对手作出决策，所有这一切都是技术本身的功劳吗？我想不全是，其中一大部分取决于管理。用过ERP产品的程序员都说，其实每个界面都很简单，但ERP的价值不在于编程是否简单，其最重要的价值就是理顺的管理流程，推动了企业的运转。

我跟着兴趣走得太远了，而且这个“兴趣”实际上是“过分关注编程技术”带来的小恩小惠积累起来的，它让我走了条弯路（但我不后悔）。现在这个问题困扰了我太久了，我实在是很难割舍这些“小恩小惠”，可我还要割舍掉。我曾经放弃过自动化、机械选择了工业外贸，也曾经放弃了考研选择了参加美国大学生数学建模竞赛，还曾经放弃了我的大学专业工业外贸转行管理信息系统，现在我也要放弃“专注于技术”，将更多的精力专注在管理、财务、企业信息化上面。我不放弃技术，也会继续在博客园发表技术文章，只是不想再专注于技术这一方面了。

完。

27周岁，在我们老家那边已经是一个3、5岁小孩父亲的代名词了。晚上给家里打电话的时候，老妈又絮絮叨叨的围着我的个人问题纠缠不休，索性以最近工作调动的事情吸引她的注意力。从一直呆着懒散惯了的老东家，到中间疯了般的一天面试4家单位，再到现在基本确定去向。很多改变，似乎只在一两夜之间的事情。

许多年前，高中的时候，事后好几天才回想起来自己的生日已过。那时候，似乎时间是所拥有的最廉价的财富。

许多年后，却如同一个斤斤计较的小女孩般在意这一天。是感觉到时光飞逝，还是岁月蹉跎？自己也说不清楚。

收到了很特别的一份礼物，一位朋友在MSN上把彼此认识的一点一滴发了过来。文字容易让人产生时空的错觉，一起回顾着那些片段，恍惚间我们的过去又站在了跟前。望着里面的自己，轻轻的晃晃脑袋，如同《宰相刘罗锅》里头的皇帝垂暮之年一般轻声叹息。

如果时间可以重来，有一半的人都可以成为伟人。

不知道第二个27年，回首再看今日文字，又是如何感觉？

对自己说，生日快乐。

1.6:
http://java.sun.com/javase/6/docs/technotes/guides/language/index.html

Essential Classes:
http://java.sun.com/docs/books/tutorial/essential/index.html

Lesson: Concurrency
http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

Java Bean Tutorial:
http://java.sun.com/docs/books/tutorial/javabeans/whatis/index.html

The Java EE 5 Tutorial:
http://java.sun.com/javaee/5/docs/tutorial/doc/

The J2EETrademarked Tutorial for the Sun ONE Platform:
http://java.sun.com/j2ee/1.3/docs/tutorial/doc/

Java EE APIs & Docs:
http://java.sun.com/javaee/reference/index.jsp

面试题：
http://www.ad0.cn/netfetch/read.php/379.htm

比如说，你的生日。

记得《金婚》中有一段，佟子和出国回来的李天娇再次相遇，还是同样的人，还是同样的音乐，不同的是已从慢慢搅拌着喝咖啡换成了柠檬水，从共同讨论那位交响乐艺术家到早已忘了他的名字。事后佟志对大庄的感慨让我记忆犹新：

这人吧，难得有一些美好的回忆。就不该再去揭开那个梦，才发现其实一切早就已经不是原来的样子。

（原话记不真切了，大致是这个意思）

Anyway，生日快乐，曾经的小海豚。

This post is password protected. To view it please enter your password below:

Password:

今天要谈谈事业，或者说，工作。

大学里面开始，就比大多数同学更早接触实践，以至于在刚毕业那会儿多少有点沾沾自喜。很多知识是花了非常大的代价（成本）学来的，那时候没有意识到。

后来在理光工作了一年多，激情已消磨殆尽。技术上没有任何长进，对那里相对沉闷的气氛也是不太适应，急匆匆的开始了第一次跳槽。

现在想来，跳槽前对新东家的选择还是十分必要的，我觉得至少应该花10来个钟头（有效时间）去认真研究一下该公司的背景和发展前途，以及跟自己职位相关的一些信息。还要考虑和自己的长远规划是否吻合之类的问题。

来到了第二家公司，刚开始被那里非常宽松的氛围所吸引，精气神也不错。这可以从当时旅游的照片看出来。

但是最大的失误是没有从公司策略的频繁改动中看出自己的被动位置，并及时抽身而退。创业型的公司变化都挺大，这能理解。但是如果说基本的大方向都在三天一小改，五天一大改的话，决策者的权威性就要值得怀疑了。从Java转型到.net，于我可能是非常严重的错误。两年的时间说长不长，说短也不短，期间落后的部分要追赶已属不易，更要命的是先前掌握的部分可能也所剩无几。而基于微软本身产品有效性的时长太短，加以频繁推出的新产品，以及并不算太高的入门门槛，自己的优势郑一点点丧失殆尽。

另外，公司当时承诺了一点期权（虽然到现在还没兑现），让我想起了山里人捉猴子的方法：

在树干上挖一个大小合适的洞，使猴子能将手伸入，但是握拳之后却无法抽出。然后在洞中放入猴子爱吃的事物，就可以等它上钩了。
猴子因为贪恋美食，伸手拿到事物后却不肯再将手松开，于是乎只能乖乖束手就擒。

这点虚无缥缈的东西，最后很有可能拿来打水漂。自己却因为这个而变得犹豫不决，当断而未断，实在不是很利索。

适逢全球金融危机，这个时候如果再动，可能前景又比较暗淡。但人生好比海上的波浪，有时起有时落，趁着还年轻应该多搏一把，结局如何是掌握在自己的手中。

静下心来，好好学英语，好好复习技术，这是目前的计划，执行中。

前阵子曾向她提过，晚上睡觉容易失眠。这就惦记上了，让我有些小小的惊喜。

生活正以它特有的幽默作着平衡，有时候觉得这个秋天也不算寒意太浓。

厌倦了纷繁复杂的琐事，
厌倦了毫无激情的工作，
厌倦了寂寞独品的清乏，
就如同厌倦了各种程序永无休止的升级。

我只是，厌倦了。

能不能出一个生活的最终版，
把必要的功能和易用性永远的定格在那一刻？

不是，这不是我想要的生活。

本文为《我的读书笔记之人月神话》系列的第四篇，欢迎指正。

=============================================================

交流：

作者先以“巴比伦塔的启示”为引子，提出了他所认为的项目成功的先决条件：

• 清晰的目标
• 人力
• 材料
• 足够的时间
• 足够的技术

本身这些条目都没有问题，但我觉得最后两点有待商榷。不可能等什么都准备到了“足够”的地步才去动手，特别是技术方面，在项目的进程当中去学习也是常有的事儿。

而巴比伦塔的失败，也证明了“交流”和“组织”（交流的结果）的重要性。

交流的可能途径：非正式途径；会议；工作手册

—————————————–

工作量：

以大型项目的数据为依据而研究所得的结论：

工作量=常数 * 指令的数量^1.5

由于我估计作者所从事的项目大都是操作系统级别的，所以书中很多指标都用类似“指令”这些指标来衡量。简单的讲，可以把这里的指令理解为系统的原子特征。指数型增长的趋势，倒也符合正常的逻辑推理。

复杂程度的指导原则：

编译器的复杂度是批处理程序的3倍，操作系统复杂度是编译器的3倍。

批处理和编译器我都写过，只不过那编译器是用高级语言Java写的而已，对于这个复杂度没有太深的体会。如果将来有机会接触到操作系统级别的复杂项目，那倒可以回过头来细细比较一下。

—————————————–

规模：

软件的规模是视其是否使整个应用系统更加有效而言的，并不在于它的绝对成本

• 仅对核心程序设定设定规模目标是不够的，必须把所有方面的规模都编入预算
• 在指明模块有多大的同时，确切定义模块的功能
• 培养开发人员从系统整体出发、面向用户的态度

时间与空间（占用的资源）

1. 项目的粗细程度决定所需的空间大小
2. 对于给定的功能，空间越多，速度越快

如何取得 空间<->时间 的折衷？

1. 从团队成员的编程技能上培训
2. 需要技术积累，开发公用单元构件

技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高

最后，以篇末最经典的一句话总结本文：

数据的表现形式才是编程的根本

亲戚或余悲，
他人亦已歌。
死去何所道，
托体同山阿。

有些事情，终究不能避免。

一路走好，我最亲爱的外婆。

刚进大学的那个中秋，一群年轻人围坐在数学系前面的草坪上闲聊嬉戏，踌躇满志，依稀就在眼前。转眼物是人非，很多时光早已一去不复返。

脑海里忽然冒出一句话，似乎是某个老头临终所言：如果人生可以重来，那么有一半的人可以成为伟人。不想让自己太过伟大，后面的时光也足够让我好好生活，宁静而知足，就是这样了。

又记起理光的中秋传统，不知管理科今年是否还是照旧小月饼一劈为四，分而飨之？

有些日子没出声了，今儿个冒个泡，希望看到的和没看到的朋友们都过的顺心。

Exception: System.Configuration.ConfigurationErrorsException

Message: 引发类型为“System.Configuration.ConfigurationErrorsException”的异常。

StackTrace: 在 System.Web.Configuration.ErrorRuntimeConfig.ErrorConfigRecord.System.Configuration.Internal.IInternalConfigRecord.GetLkgSection(String configKey)
在 System.Web.Configuration.RuntimeConfigLKG.GetSectionObject(String sectionName)
在 System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)
在 System.Web.Configuration.RuntimeConfig.get_HostingEnvironment()
在 System.Web.Hosting.HostingEnvironment.StartMonitoringForIdleTimeout()
在 System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)
在 System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters)
在 System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
在 System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

Failed to execute request because the App-Domain could not be created. Error: 0×80131902

很有可能是IIS的asp.net插件在安装.net（特别是高版本）中造成了损坏，用以下方法修复：

1. With a command window, get to the latest version of .net under “C:\Windows\Microsoft.Net\Framework\”
2. Now run the following command: “net stop w3svc” to stop web services.
3. Then use “aspnet_regiis.exe -ua” to uninstall all instances of ASP.NET from IIS.
4. Follow with “aspnet_regiis.exe -i” to install ASP.NET into IIS.
5. Now restart web services with “net start w3svc”.

在我的机器上修复成功。

免大部分人翻墙之苦，征得作者同意后，全文引用如下：

Apathetic, Ignorant, or Just Stupid?

The comments on the NYT article “Before Guests Arrive, Beijing Hides Some Messes” really shock me. Most of them make me kinda sick and sad.

The NYT article is a good one uncovering a corner of the true situation in Beijing before the Olympics opening, though many deemed the story is “China bashing”, and “not newsworthy”, the city beautifying is right or at least understandable, because they thought that kind of things happened a lot, and everyone knew that.

Guys, you were totally misunderstanding the point. Beautification of the city was not the problem. The problem was how the city treat its people.

Yes, beautifying before a big event coming is not news at all, but systematically abusing its citizens by the government is. I believe every case of human abusing and human suffering would make news. It’s a forever theme of journalism.

And people in that city (and yes, in all over China) was suffering from the authorities for the sake of image. That’s the all what the NYT story want to tell you.

Those believed the story “not new” presented some examples, like things happened in Chicago in 1968, Montreal in 1976, Los Angles in 1984, without any concrete and appealing evidences.

All those events held in overseas a few decades ago seam so far away that I can’t have a clue and make comment. I don’t know if there existed any human rights issue in those events. If something bad to their people really happened, I feel sorry and sympathetic to those as I feel the same to my compatriots today. But those were all old days and I believe in western civilized world, as one commenter put it: “In today’s world is quite hard to imagine one day waking up with a wall covering the front of people’s homes, or a veil covering their businesses just because they do not comply with the standards of beauty.”

Others took the happening for granted because they thought they treat their stuffs like laundry the same way when they invited guests to their houses. These statements were totally wrong, because human beings is absolutely not stuffs. Even as unfortunate as those poor Chinese people, they own human rights and civil rights and human dignity as well as westerners. They are not doomed to be victimized, even for the sake of public good! Nobody should be treated in that way. Everybody is not like the “stuffs” you can casually throw, hide or destroy at will.

Should they been sacrificed for the beauty of the city, for the incoming glorious event, for the pleasant sightseeing of foreign athletes, leaders and tourists? No. If someone must pay for the beauty of the city, it must be those who most benefit from the beautification of the city.

China is not just another exotic tourist resort. Chinese people have suffered from ruthless and corrupt despots and bureaucrats for thousands of years. We don’t deserve more suffering because of foreigners. Chinese are open and warmhearted to all kindly friends come from abroad, but those apathetic tourists regarding Chinese pains like the way they treat monkeys in zoos would not deserve it.

If those indifferent comments not came from apathetic heart, it probably came from ignorant mind. Beautification of cities in China are not as the same way most western countries run. There is always an “Chinese characteristic” way done by the authorities to average Chinese. When a governmental campaign comes, citizens are brutally dealt with, houses are arbitrarily teared down, hundreds of thousands of low-income immigrants are mercilessly driven out, dissidents are illegally tracked and harassed, protesters are beaten, tortured and even arrested. It’s out of luck for you when your property or livelihood was in the way. No equitable negotiation. No modest compromising. No fair compensation.

I believe most westerners have no idea what befall average Chinese everyday by the authorities. Most of you seem so friendly to China while critical to your own countries. Unfortunately these kind of friendliness are actually Chinese-government-friendly, not Chinese-people-friendly. These kind of comments sound so familiar to Chinese people just like the tones of the CCP Propaganda Dept hyping everyday. More and more Chinese people know what crap they are today.

“One World, One Dream” is the theme of Beijing Olympics. It’s true that Chinese share the same planet with people in the rest of the world, so as we share the same dream of prosperity, democracy, freedom and happiness with people in the rest of the world. We deserve respect and a better life. Don’t make stupid comments until you really understand what’s happening in China. Help us if you really like China. Keeping concern for the truth and pressure on human rights issues will do the trick.

Thanks to Wozy, via Link

网上找了半天，寻到了一个所谓的Team System，总以为是最高级的了。装了之后才发现是个Architecture Edition，在升级VS2005的那些项目文件时候提示有转换失败，细查之下发现是一个Test项目。后来才想到可能是版本搞错了，去微软的网站查了一下，果不其然，Visual Studio 2008的版本那叫一个复杂，除了Standard Edition和Professional Edition外，还有个Team System，居然可以细分成这么多：

• Architecture Edition
• Database Edition
• Development Edition
• Test Edition
• Team Suite

前几个各自的侧重点不同，功能也是各有差异。如果安装两个以上，那就是两者功能的一个合集。
最后一个相当于前面几个的合集，什么功能都有了。

真搞不懂微软花那么大力气推出和维护这么多版本，是否真的有客户愿意买账。

如果想比较专业版和标准版的区别，可以看：这里
如果需要细致比较Team System中各个版本的区别，可以看：这里

另外，有神秘大奖赠送：猛击这里

不许Google，不许Baidu，猜对了有奖。

update:

答案揭晓：￥300/瓶

本文为《我的读书笔记之人月神话》系列的第三篇，欢迎指正。

=============================================================

这次谈得是贯彻执行的问题。换句话说，也就是如何确保一个拥有诸多结构师和编程人员的项目团队，对整个系统保持概念上的完整性？

最好的办法就是文档化的规格说明——手册！
这里的手册应该包括各种说明文档，设计文档，甚至备忘录，只要是对理解系统的设计有帮助的，应该都可以归入在内。

谈到手册，可能刚开始工作或者比较偏好编程的朋友会觉得比较头大，不太喜欢。刚开始的时候我也是如此，可随着时间的推移和工作经历的增多，却越来越发现手册的重要性。大到设计思想，小到会议记录，手册就像幻灯片一样将整个系统显示在你的面前。

那么，应该怎样书写文档（手册？manual？document？whatever），怎么样的文档才能算是好文档？

先来回答后面那个问题：

清晰、完整和准确：精确比生动更重要

好在搞技术的大多数都是理性思维，不会为了华丽辞藻在那边苦思冥想半天。

写到这里的时候忽又想起在之前那家日企得到的经验：尽量用简短的英文来描述，不用长句式。一来小日本不太擅长也不喜欢英语，二来长句式在理解上确实不如短句来的一目了然。

再回过头来说说第一个问题，人月神话的作者给出了两种用来书写文档的定义：形式化定义和记叙性定义。

但是作者并未就这两种定义给出具体的解释和说明，这里就简单谈谈我的理解：

所谓的形式化定义就是用一种有规则的、有限制或有约定的语言（自然语言、计算机语言、伪代码，均可），来描述系统的一些关键特征，或者表达文档所关注的重点目标对象。而记叙性定义，就是简单的用大篇幅的文字来描述上述特征或目标。

两者各有优缺点：

• 形式化定义比较精确，倾向完整，但不易理解（总不能保证每个阅读手册的人都是搞编程的吧），对于有些场景很难描述清楚；
• 记叙性定义能够表达结构性原则，描述阶段或层次上的结构，表达异常和强调对比的关系，并解释原因，却也因此而显得有些累赘，索引和定位都比较差。

再补充一点，形式化定义是一种设计实现，仅仅用于外部功能（描述系统必须做什么）。潜在的问题是：实现可能过度地规定了外部功能（声明了自己到底做了些什么），当实现充当标准时，必须防止对实现的任何修改（这话听着很拗口，其实仔细想想确实如此）。

如何取舍，关键还是看系统本身的特性更适合哪种方式，以及文档编写人员的习惯。注意：两者只能以其中之一为标准，另一个为辅助。
另外，为保持一致性，须由少数人对大家的想法进行整理和汇总，对看似琐碎或不重要的问题进行判断并得出结论，使之体现在文档中。

文档的话题就说到这里，回到前面“贯彻执行”的主题。有多种很好的方式方法可以利用：

周例会：
建议以书面形式在会议之前分发，要求事先Review原先的设计并作出思考，提出少数解决方案，传递给结构师。
当需要对变更作出决策时 ==> 强调首席结构师的最终决策权，避免妥协和拖延（这个很重要，我已经有所切身体会了）

年例会：
由于各种原因，在周例会中可能未予以考虑的某些问题会堆积起来。有时候程序员都是很固执的性格，这些问题的一直存在，会让系统的执行变得困难。年例会就是针对这个来考虑的。大家在会上把那些问题列举出来，进行表决或者讨论，时间可能会持续几周，每日更新手册说明，记录前一日的各项决定（可能需要一定的额外工作量）。

目前为止我没有参加过此类的年例会，可能超大型的项目才会有这种可能性。不过听上去还是很不错的主意。

对规格说明有疑问时：

• 不要自己猜测

很多新手常会犯这个错误

• 打电话询问相关结构师

有些人就是怕麻烦，或者怕开口交流，需要努力克服

• 结构师记录并定期整理、分发给相关人员

啊哦，又多了点工作量

• 不需很正式

似乎是好消息

以测试作为驱动动力：
开发和测试不是两个冤家，测试能够推动系统更加贯彻的执行。

就先到这里吧。

别说这会儿油价那么高，有钱买车还没钱加油呐。再说咱买车不就图个方便，说出去以车代步，多威风！捎带还能载个人啥的，您说是不是？

啥牌子？甭管国产还是进口，只要跑起来轻快，式样美观大方，那就行了。

所以，当我今晚路过那家商店，看到它第一眼的时候，我就知道，这车，我是离不了了。

是的，那是一辆崭新的捷安特，静静的停在那里，等待着下一个慧眼识珠的主人。我的目光追随着她俊美的身形，久久挪不开视线。

胯下，是那头伴随了我3年多的小毛驴，已是迟暮之年。不忍让其累倒在工作岗位上，忍痛将其转让。

饶舌完毕，回到正题，算算经济账。

05年2月26号将其购入，到今天正好是3年零4个月。按每月平均工作21天，每天乘车花费2*2=4元计算，这些年来应该替我省了至少 4*21*40=￥3360，当初买车费用为￥1688，远远够本了。

今天去问了一下，这车还能卖400块，也就是说一共是 3360+400=￥3760。

现在有两个方案：

A、换新电池然后继续用，电池更换费用为350元

B、把电瓶车卖了，然后买那辆捷安特，估计也在4-500左右

闲来无事，分析分析两者的差别。

• 电瓶车卖掉的价钱正好换来一辆自行车，从这点上来说成本没有变化。
• 但是如果电瓶车要继续使用，需要更换电池，也就是新增的成本。
• 新电瓶能够继续使用一年半左右，但是自行车保养得好可以使用3年以上。
• 自行车每月停车费比电瓶车少3块。
• 最重要的是，骑自行车可以让我这把久未运动的老骨头再次活动起来。

综上，我只好另觅新欢了。亲爱的毛驴，再见了。谢谢你带给我的这些回忆。

本文为《我的读书笔记之人月神话》系列的第二篇，欢迎指正。

=============================================================

效率一直是困扰每个团队，特别是项目经理的一个大问题。作者从他数十年的项目经验（大部分是硬件或硬软件结合，但也适用于纯软件）中总结了若干模式，用于有效提升大型项目的开发效率。让我们一起略窥究竟。

对于大型的团队，作者提出了一个“外科医生”的模型，即：

将整个系统（项目）划分为若干子系统，每一部分由一个独立的团队承担，每个团队采取类似外科手术的操作方式进行开发：一个外科医生（首席程序员，有决定权），护士（副手，熟悉系统，和别的团队沟通交流），管理员（控制财务、人员、工作地点等的机构管理），编辑（文档维护），程序员，测试员，专家，其他人员（……）

通常对10人左右的编程团队而言，上述角色分工就足够了，其中管理员和专家可以同时为多个团队服务。团队间的协调，也因人数（外科医生）的减少而提高了效率。

这样就提出了一些新的问题：如何保证整个系统设计概念的完整性？

简单的来回答就是：需要系统架构师对整个系统系统的完整性进行比较好的设计和拆分。

一步一步来看：

我们的终极目标是：易用性（simplicity）。而衡量系统设计的最终测试标准是：功能与理解上复杂程度的比值。

这就要求我们用最简洁和直接的方式来处理业务，同时易用性需要设计的一致性和概念的完整性。

关于系统概念的完整性有若干点值得注意：

• 要求必须由少数结构师来决定，其余人员则可以在有限制的范围内更加有效的发挥创造力（没有规矩，不成方圆）

结构师是需求的确定者和系统特征的确定者，拥有决定权。

• 要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想

这个很好理解，这个世界总是由少数人领导大部分人的。

对于中间可能出现的一些问题，作者也做了详尽解释：

• 当估算过高时，需要削减设计或建议用成本更低的实现方式

削减设计对于架构师而言是件很痛苦的事情，但有时候我们不得不如此。换低成本的实现方式只是建议，因为架构师不应该牵扯到具体的内部实现当中去。

• 过度设计

这个和上面的有一点区别，前者更多的是出于经济和预算方面的考虑，这里是指年轻的（指经验不丰富，尤其是在开发第二个系统时）架构师会对系统有一些过多的修饰功能和想法。这时应根据系统的基本理念和目的变更，舍弃一些功能。

特别对于项目经理的建议：

坚持至少拥有两个以上系统开发经验的结构师的决定；保持对特殊诱惑的警觉，确保原则上的概念和目标再详细设计中得到完整的体现。

暂告一段落。

这次运气没有那么好，打电话给房东不在家，只好晚上再说了。

大热天的挤了一个钟头的公交车，真是受罪不小。看来这个健忘症该治治了，俺还那么年轻的说。

有谁知道什么食物有助于提高记忆力的，吱个声吧。

本文为《我的读书笔记之人月神话》系列的第一篇，欢迎指正。

=============================================================

文章的开头是很美的一段：

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.
美食的烹调需要时间；片刻的等待，更多美味，更多享受。

—- Menu on restaurant Antoine, New Orleans.

相信所有的饕客都会对此感同身受，频频点头。作者可能是想藉此说明，软件开发就如同美食烹调，都是循序渐进，有章可循的。贸然跃进，可能只会适得其反。

接下来，开篇就提出了全书最重要的观点：人月(Man Month)不能互换。

长期以来有一种观点认为，一个软件项目，如果需要3个人做4月的话，那么4个人做3个月也可以完成。通俗的来讲，就是效率（或者说进度）会随着人数的增派而相应提升，从而缩短了整体的时间。事实上，在阅读此书之前，排除一些细小因素（比如人员个体差异等），我大体上也是这么想的。

不成立的原因有很多，作者给出了如下几点（每项后面的是我的注解，下同）：

1. 项目时间依赖于顺序上的限制

确实如此，但如果每个环节上都增派了人手，似乎对进度提升还是有帮助的。

2. 人员培训和交流的时间更多

这个就是我所说的个体差异了。但是交流成本的增加确实是我事先没有想到的。

3. 有些任务是不能拆解的，添加人手对进度没有帮助

碰到过类似情况，有一个任务在身，Leader分配了另外一人来帮忙，结果给他解释的功夫自己做完都足够了。

4. 人员的增加会引起模块的重新划分，从而导致测试的延长

没有想到过，但是觉得很有道理。

当然，对于何时成立的情况作者也给出了说明（如图所示）：

也就是当 y = N/x （N为常数，即总的工作量）的时候才成立，换句话说就是两者（人力，时间）乘积恒定为常数。当然这是我的分析，作者并未明确指出这一点。

另外，他还列举了缺乏合理进度安排的若干原因：

1. 对估算技术缺乏有效的研究

这个尚待研究，确实需要补充学习。

2. 错误的隐含假设人、日可以互换，将进度与工作量混淆
3. 由于缺乏信心，软件经理不会有耐心持续估算
4. 对进度缺少跟踪和监督

有经验的项目经理可能会在这方面做一些努力和尝试，但是目前为止我还没有见到过实际应用中特别成功的例子。

5. 意识到进度有偏移时，下意识的反应是增加人力

wrong decision!

最后作者给出了他认为的进度安排的经验法则：

• 1/3计划
• 1/6编码
• 1/4构件测试和早期系统测试
• 1/4系统测试，所有的构件已完成

放在目前中国的大部分项目上来看，可能很少有团队能够按照这个比例来做事。这个也有可能是跟他所从事的一直是大型项目（比如IBM的OS/360）有关，到那个Level的感觉就不是我现在所能体会的了，但有了良好的设计做前提保障，编码确实是可以花最少时间的部分。

作者中间还放了一个煎蛋的启示：

如果煎一个鸡蛋需要2分钟，而客户想在1分钟内得到，那么只能坚持让他等待，或者生吃。否则蛋会因为火太旺而变得一半焦，一半却是生的。

即：

不要为了满足客户的期望，而设定不合理的进度安排（坚持自己的估计——基于充分的经验和直觉）

从我有限的项目经验来看，中国的客户更倾向于做上帝。他们可能希望你在指定时间内把产品交付出来，至于说后期的bug之类，可以慢慢补（菜里面忘记放盐了，不好意思，我再回一下锅 :P）。而国外的客户则更青睐于使用相对比较成熟和稳定的产品，而不是依靠后期的不断修正（微软，我不是故意说你的 ^_^）。

最后，以Brooks法则来结束此文：

向已经进度落后的项目中增加人手，只会使进度更加落后。
Adding man power to a late software project makes it later.

顺便提一下Solution：重新安排进度；削减任务。

先到这里吧。

作者：
Frederick P.Brooks.Jr.

简介：

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的简介，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范……

//以下列表会持续更新直到阅读完毕

1. 《人月神话》读书笔记之一：进度
2. 《人月神话》读书笔记之二：效率
3. 《人月神话》读书笔记之三：执行
4. 《人月神话》读书笔记之四：规模

到底系统时钟（定时器）可以作为Actor来画吗？

下面的文件可能正好解答了你的疑惑：点击查看

如果你只想简单的知道答案，Here it is：不推荐。

处理方法：

1. 将Time作为Secondary Actor
2. Use case中不加入Time，详情放在Architect文档中说明

详情可参阅上述附件。

新浪的广告正迫不及待的告诉我们：

绿色是生命！
绿色是希望！

在那下面，是我同样葱翠碧绿的股票交易记录，还有将近-20%的盈亏率

真他妈讽刺！

thanks a lot for your concern.

涉及违反法律的内容，已经删除。

Stay clear and keep that in mind.

现在，还不是去计较，去追究，去感慨的时候。汶川，这个将被亿万中国人永远铭记的地方，那里的人们，需要你我的帮助。除了默默为他们祈福外，我们还可以尽自己的一点努力，去尽量挽救一些幸存者。众志成城，相信灾区的人们一定可以见到风雨之后的彩虹。

需要捐款的，可以参见下面的信息：

想要在自己的blog上挂此banner的，请参阅：

http://plod.popoever.com/archives/001372.html

事情发生在把Eclipse的各个插件合并起来，准备做一个All-in-one的package的时候。Total Commander 一直报拷贝出错，还以为是以前经常碰到的Linux下大小写文件在windows下重名冲突的问题，仔细看了之后并非如此。一层层目录定位下去，出错的文件并无特殊之处。想了想可能是路径太长的原因，把它移到上层目录果然问题消失。

算了一下，连带路径分隔符“\”及文件名本身，最大支持259个字符（系统为XP,SP2）。

特此记录一下。

梦中自己身处日本，奈何早先学校记的一点日语，除了“斯密马赛”在某个角落尚有备份还能张口就来之外，其他早已被做了格式化。似乎想去某个地方，和路旁小店里头老头老太（脸太糊了，记不真切）打听路线，指手画脚做了半天只有自己看得懂的手势，无济于事，只能仰天长叹做困兽状。

不知此梦何解，望达人指教一二。

今天白天在公司上了会MSN。很久没有在这个时间段上线，忽然飘过来一句话：来得正好，找你。原来是在日本的一个同学，询问我是否有前去发展的意图。聊了半天，最后伊来了一句：就算不来工作，来日本看看樱花，赏赏风景也是不错啊。

甚为诡异。

后面又收得邮件若干，有网上盛传之戏弄日本人笑话数则，时评一篇，杂文不等，均与此国有关。

甚为不解。

还是不解。

莫非真有传说中的记忆往复，可在特定时刻，将以往依稀淡忘之事跑马灯一般调出来？如同小时家门口屋檐下那口用来接雨水的缸，平时瞧着里头之水很是澄清，调皮的用棍子搅拌几下，便看到那沉积之物晃悠悠的浮上了水面。

继续胡思乱想中，却不再胡言乱语。

中央五套在重播奥沙利文对阵亨得利的半决赛，看了两局，关了电视。倒不是对比赛本身失去了兴致，而是这场对决，对于亨得利而言无异于谢幕表演，不忍再看。

王者之气仍在，坚毅冷峻的眼神也是丝毫不亚当年，缺失的怕是那股遇妖除妖、遇魔伏魔的霸气。可能生活琐事和对家庭的眷恋让这位昔日的王者分心太多，又或者岁月不饶人，体力精力都已经无法跟巅峰时代相提并论。曾经的台球皇帝，已经沦为自嘲支持者不过一二。这次的世锦赛，要不是小将马克·艾伦缺少经验在赛点上连丢数局，亨得利怕是早已止步于八强之外了。

诚然，你可以很乐观的说，他已经没有什么遗憾了。那么多的荣誉背负在身，那么多的超级记录让后人难以望其项背。在斯诺克的史书上，必然会有Stephen Hendry的名字深深镌刻其上。不过，看着自己身上的光环一点点的消逝，从云端跌落回凡间，还有比这更最凄凉的事情么？有些运动员在自己的职业巅峰状态忽然宣布退役，多少是想将那最亮最美好的尖峰时刻尘封起来，让人们记住他最潇洒的时刻。

英雄迟暮，恐怕就是这个样子吧？

一直顶着忙的名义，给自己强加各式的活动。这个下午，当它悠然的空出来与我相伴的时候，那种似曾相识的感觉又回到了从前。

在音乐论坛上闲逛着，顺着推荐的曲目，感触着那些或沉重或轻缓的音符，任由各个角落发出的异国声音，载着自己穿梭于世纪前后。手边，微香的龙井；耳畔，悠扬的苏格兰风笛；面前，鲜绿的植物，生机勃勃的准备迎接又一个盛夏。一抬眼，浮云也在冲我微笑。

这一刻，没有电脑，没有搜索引擎，没有生存的烦恼，没有一切切的纷繁复杂。唯一需要的，就是倚着躺椅，在阳光下缓缓的睡过去。

世界并没有改变太多，改变的是我们。匆匆行路的时候，偶尔停下来看看路边的风景，真好。

Let’s take a break.

BBS 图片分享 旅行故事分享

http://www.tripntale.com/

悄然毅然，有些事情还是默默的走到我们面前。老人家素来身体健康，胃口尚佳，但是时间还是以它的方式，无情的缓步向前推移。生老病死，本是无法避免之事，当发生或即将发生在自己亲近之人身上的时候，却总归会有那种挥之不去的哀愁涌上心头。

外婆以九十一之高龄，坚强的越过了二十一世纪，见证着诸多变迁，如今也算是安享天年，儿孙满堂（最大的重孙早已结婚，怕是重重孙也要呼之欲出）。倒是我这个最小的外孙，却还总让老人家惦记着。半梦半醒之间，病榻之上，仍不忘嘱咐我妈让我早点成家立业。如此关切，除了最疼爱自己的外婆，恐难再有出其右者。

人总要在生离死别的时刻，才忽然体会到逝去时光的珍贵。有些东西，真的离我们好近好近。

愿吉人自有天相。

This post is password protected. To view it please enter your password below:

Password:

Recently I have made a long term plan for my job career, in another post (password protected), and some guidlines for my personal life as well, which is also private and confidential

Anyway, I will still try my best and put some energy on the daily stuff intermittently, as which is the foundation of the above.

Good luck to me, and to you all concerned.

人各有志，抛开离职原因不谈，今天想说说离职前的最后那段时间的行为表现。

通常可以见到的情况会有：

• 轻者：工作效率低，做事拖沓，延迟情况严重
• 重者：不作为，不将责任范围内的任务完成
• 请假较多，经常不在公司

有一些情况是某些公司可能不会把剩余的年假换算为薪资退给员工，所以第三条多少可以算是有点情有可原。
但是前两条可能就不太好了，越是到最后，越是体现出个人职业素养的时候。
如果把员工在公司的表现作为一条坐标系里头的曲线的话，最后的那部分斜率为负恐怕不是很好看，也有点得不偿失。

想了一想，列出了自己认为比较合适的做法，也欢迎各位看客补充：

• 完成手头的模块或任务；如果比较大不可能全部完成，应与上级确认，到某个可衡量的状态为止
• 确定工作交接内容，交接对象和最后交接时限
• 整理电脑内的文档、资料，将平时积累的无关公司机密的材料备份到自己的信箱或移动硬盘
• 发送farewell letter，留下常用联系方式
• 删除电脑内与工作无关的一切其他数据，特别是私人数据
• 办公室私人物品整理
• 按公司章程办理离职手续
• 有条件的话，请同事们吃个饭

暂时就想到这么多了。