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

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，留下常用联系方式
• 删除电脑内与工作无关的一切其他数据，特别是私人数据
• 办公室私人物品整理
• 按公司章程办理离职手续
• 有条件的话，请同事们吃个饭

暂时就想到这么多了。

And here is the situation:

• All the web pages are built with smarty.
• The report page contains some logic that are already defined within the corresponding smarty template.
• I have access to PEAR install

So here is the solution I figured out:

1. Create a new excel file, insert some dummy data, typically with one header row and two data row, and also a row with special format for empty dataset.
2. Save the file as “web pages”, i.e.: FILENAME.htm
3. Open the htm file with your favorite text editor, you can see some html tags like “tr” and “td“, just like ordinary html files.
4. Edit the file as you like, put your logic inside. The dummy data may help you out of some cycle, if/else condition.
5. Build the page with smarty, following is some pseudo code:
   

   // some initial statement here, such as retrieving data ...

   ob_start();

   $smarty->assign(Smarty_Variable_In_Htm_File, $yourData);
   //...
   $smarty->display("FILENAME.htm“);

   $htmlResult = ob_get_contents();
   ob_end_clean();

   $dl = new HTT