2006年11月18日

老师让每个人记录每天帮家里干了些什么事情

小明想了半天 然后在作业本上写到:每天帮家里吃饭~~~~~

 

–看到着条短信之后我就彻底笑翻了,这么可爱的孩子,那天去吃饭的时候,一个人看幽默大全就笑疯了,旁边一个同事就说:看幽默大全都会笑的人都还很天真。。。。。。

2006年04月17日

[转贴]http://www.blogcn.com/user82/unmi/blog/27639599.html

维也纳在等着你—-世上没有加班这回事

维也纳在等着你

几年前,我与南加州一个大项目的项目经理交流各自的艰辛历程。他开始叙述将项目和疯狂的时间表压到他下属的身上产生的影响。一是发生的两宗离婚案,其中原因可以直接追溯到与他的人经常加班有关;再者就是一个员工的孩子吸毒,其中原因可能是由于在过去的一年里,孩子的父亲太忙,未能尽到做父亲的责任,最后,测试团队的负责人又神经崩溃。
在他继续叙述这些可怕的事情的时候,我开始意识到,此人一直在炫耀他这种奇怪的工作方式。你也许怀疑,如果再有另个一两个人离婚和一个人自杀,这个项目原本会取得圆满的成功,至少在他的眼里是这样的。
――TDM

每当谈起“聪明地工作”这一话题时,一个很普遍的感觉就是,现实世界中的管理就是在更大程度上以员工的生活为代价,让他们更努力、更长时间地工作。经理们总是不停地吹嘘他们的员工的加班时数和能从这些人身上榨取更多时间的小把戏。

使用西班牙人理论的管理
很久以前,历史学家们从各种不同的价值理论中形成了一个抽象的结论:西班牙人的理论坚持认为地球上只有一个固定数量的价值,因此通向积累财富的道路就是学会从土地或者从人身上更有效地榨取财富。而英国人的理论认为价值可以通过天才和技术创造出来。因此英国就产生了工业革命,而西班牙人就转动起了车轮,开始开拓疆土和剥削在新大陆的印第安人。他们从海上运回大量的黄金,他们的所有努力带来的却是通货膨胀(太多的金钱追逐太少的有用货物)。
西班牙人的价值理论依然生机勃勃地活在各处的经理们的心中,每当他们谈到生产力的时候,你就看到这一点。生产力应该意味着用一小时的工钱榨取更多利润,两者之间有很大的不同。持西班牙人的理论的经理梦想通过不付钱要求员工加班加点的简单手段达到新的生产力水平,他们将一周所要做的任何工作除以40小时,而不是员工实际投入的80或90小时。
确切地说那不是生产力――那更像是欺骗――但对美国的经理来说这是一种艺术境界。他们威逼或哄骗他们的下属延长工作时间,他们给下属的印象是交货日期是多么重要(即使这个日期可能是很武断的;地球不会因为你的项目迟了一个月完成而停止转动)。他们欺骗手下人接受毫无希望实现的时间紧迫的进度表,让他们带着愧疚的心理,牺牲一切以满足这个进度表的要求,并且竭尽所能地使手下人更长时间、更努力地干活。

来自后方的一句话
虽然你的员工在办公室也许被“更长时间、更努力地工作”这句话所影响,但从他们家里听到的是完全不同话语。在家里听到的是“生活已离你而去,你要洗的衣服堆满了壁橱,你的小宝宝没人抱了,你的配偶开始朝其他地方张望。旋转木马的人生只剩下一圈了,只有最后一次中奖机会了,如果你把你的生活用到COBOL上……”

但是你知道,当实情被告知之时,
你或许能得到你想要的或者你只能变老,
在你还未走到半道之时,你就要被淘汰出局,
你何时意识到――维也纳在等着你?
      ――《陌生人》(The Stranger)比利•乔尔

维也纳在等着你,在比利的歌词里,就是你人生之路的最后一站。当你到达那里时,一切都完了。如果你认为你的项目组成员对如此沉重的话题一点也不担心,请你再想想,你的下属很清楚上帝赐予每个人的生命都是短暂的,他们也非常清楚有比他们正在从事的这种愚蠢的工作更为重要的事情。

世上没有加班这回事
对于领薪水的员工而言,加班是天真的经理想像出来的虚构之物。噢,为了在星期一的最后期限完成工作而在星期六加班几个小时可能会有点好处,但是那总是伴随着一个相等时段的补偿性“减班”,弥补上他们生活中因加班失去的部分。对应于1个小时的加班,或多或少会有一个小时的减班。从短期而言,这种抵消的方法可能对你有好处,但是从长远角度看,这些好处会被抵消掉。

疯狂的孩子你慢一点,
把电话摘下然后消失一会儿,
对了,你可以放松一两天,
你何时意识到……维也纳在等着你?

正因为持西班牙理论的经理们很大程度上对不付工资的加班视而不见(这些人总是计算1周40小时工时,而不考虑人们实际投入了多少时间),因此对减班也视而不见。你从未在任何人的时间表上看到这一点,那是花在打电话、闲谈或干脆是休息上的时间,没有人能真正工作超过40小时,至少不是连续地和以创造性工作所需要的强度水平进行工作。
加班就像冲刺:在马拉松赛跑中,对那些还有剩余能量的人来说,最后几百码是非常重要的,但是如果你在第一个1英里开始冲刺,你只是在浪费时间。对经理而言,如果试图让人冲刺得太多,结果只会失去人的尊重。最好的员工已经经历过这种事情了:当经理哆嗦说工作必须在4月份完成时,他们知道保持沉默并且转动着眼睛就足够了。然后当他们能够补休时他们就补休,并且以每周实际工作40小时而告终。优秀员工以那种方式做出反应;而其他所有员工则是工作狂。

工作狂
工作狂将加班加点,不需要补休。虽然或许他们的工作效率在降低,但是他们会工作过多的时间。如果给他们施加足够的压力,他们会在损害个人生活的道路上走很长一段路,但是这只是一时的。这样的信息迟早会传到甚至最专心的工作狂的耳朵里:

慢一点,你做得很好了,
在你死前你不可能完成一切心愿,
虽然今晚在边缘线上非常浪漫,
但是何时你意识到……维也纳在等着你?

一旦体会到这一点,在完成了这个项目后,你就完全失去了这个员工。意识到一个人为了不重要的价值(工作)牺牲了更重要的价值(家人、爱情、家庭、青春),这种意识是破坏性的,它会使得一个曾经不知情地做出了牺牲的人寻求报复。他不会去找老板平静而理智地解释在将来事情必须改变――他只是辞职了,这是另外一种耗尽热情和精力的情况。无论如何,他已经离开了。
工作狂是一种疾病,但不是像酗酒那样,只影响几个不幸的人。工作狂更像感冒:每个人都不时地碰到一回。我们在此写这些内容的目的不是为了过多地讨论它的根源和根治方法,而是为了讨论这个更简单的问题:你,作为经理,应该如何与你的工作狂打交道。如果你用典型的西班牙理论的方法最大限度地剥削他们,你最终将失去他们。无论你是多么拼命地需要他们把所有的时间都投入到项目中,你不能让他们以个人生活为代价来这样做。失去一个好人是不值得的,这一点已超过了狭隘的工作狂范畴,进入到更加复杂的主题:有意义的生产Α?

生产力:赢得战役和输掉战争
下次当你听某人谈到生产力时,仔细听一听说话的人是否用了“人员流动”一词,很大的可能性是他(或她)没有提到这个词。多年来,从听到的关于“生产力”的讨论或看到的数以百计的关于这方面的文章中,我们从没有遇见一个专家谈到有关“人员调整”这个主题的任何事情。然而只谈论一个而不谈论另外一个有什么意义呢?下面评价一下公司在改进生产力方面通常要做的一些事情:
•强迫人们加班加点
•产品开发过程的机械化
•在产品质量上的妥协
•生产过程的标准化
这些措施中的任何一个都会潜在地降低工作的趣味性和满意度。因此,改进生产力的过程是在冒险使人员流动辐度加剧。这不是说不付出人员流动的代价,就不能改进生产力。这只是说,无论何时开始达到更高的生产力都需要把人员流动考虑进去。否则,完成的“改进”会与关键人才的损失相抵消。
大多数的公司甚至不保留有关人员流动的流计数字。实际上没有人能告诉你代替一个有经验的工作作人员的成本是什么。并且无论何时考虑到生产力时,似乎人员流动是不存在的或是免费的。数据通用公司(Data General)的“鹰”项目就是一个例子。这个项目是个西班牙人理论的胜利:项目组成员是一群工作狂,他们无止境地、无偿地加班加点,为了把生产力推到一个从未听说过的水平。在项目结束的时候,实际上所有的开发人员都辞职了,那样做的成本是什么?恐怕没有人能够用方程式计算出来。
生产力必须定义为利润除以成本。利润是可观测到的美元存款和工作中的收入,成本是总成本,包括替换那些由于工作而疲惫不堪的人员的成本。

反复
在过去的一年中,我为一个项目做了一些咨询工作。该项目进展得很顺利,项目经理知道她能够按项目进度表按时提交产品。她被管理委员会叫来做项目进度汇报,她说可以保证产品在最后期限3月1日准备好,完全根据最初估计的时间按时完成。高层经理认真考虑了这一意料之外的好消息,然后第二天又把她叫来,既然她可以按时在3月1日完成,他们解释说,那么最后期限就改到1月15日。
――TRL

对那些信奉西班牙人理论的经理们来说,一张能够真正按时完成的进度表是没有价值的,因为它没有对工作人员带压力。更好的做法是有一张毫无希望、不可能按时完成的时间表,它可以榨取员工们更多的劳动。
在你的职业生涯中,很可能你已经见识过一个或多个信奉西班牙人理论的经理。对他们的目光短浅付之一笑是很好的,但是别以为自己就不会犯这样的错误。我们每个人都在不同场合,不同时期屈从于这种短期策略,给下属施加压力,让他们更努力地工作;为了做到这一点,我们不得不忽视他们效率的降低和由此而产生的人员流动现象,忽视坏的副作用是容易做的。但不那么容易做到的是牢记这样一个麻烦的真理:

人们在受到时间重压的时候不是工作得更好,只是工作得更快。

为了工作得更快,他们不得不牺牲产品的质量和他们对自己工作的满意度。

[Unmi后注] 此篇为《人件》中的一章--维也纳在等待,因在网上找不到现成的原文文字,所以我只能不辞辛劳的一字一字的录入过来,也只因看了这一章有些感触:作为一位IT工作者,真的不愿意加班,莫拿什么“干我们这一行,哪有不加班的”道理来说明加班是应该的,前面那句话本身就是有问题的。IT可以是挨踢,也可以是 I’m tired.

Eventful或Upcoming保存社交日历

Gootodo安排日程表

Box.net存储有价值的文档 http://www.box.net/

Newsvine阅读或撰写新闻

YouTube或JumpCut查找视频 http://www3.youtube.com/index 

Diigo创建和共享网络书签

Odeo创建播客和音频备忘录

Wordpress或Xanga发布博客

Flickr或Buzznet共享照片  http://www.flickr.com

2006年04月06日

    虽然在商业方面存在竞争,GNOME与KDE两大阵营的开发者关系并没有变得更糟,相反他们都意识到支持对方的重要性—如果KDE和GNOME无法实现应用程序的共享,那不仅是巨大的资源浪费,而且将导致Linux出现根本上的分裂。 

    KDE与GNOME是目前Linux/UNIX系统最流行的图形操作环境。从上个世纪九十年代中期至今,KDE和GNOME都经历了将近十年的漫漫历程,两者也都从最初的设计粗糙、功能简陋发展到相对完善的阶段,可用性逼近Windows系统。图形环境的成熟也为Linux的推广起到至关重要的作用,尽管Linux以内核健壮、节省资源和高质量代码著称,但缺乏出色的图形环境让它一直难以在桌面领域有所作为,导致Linux桌面应用一直处于低潮。如果大家还有印象,一定会记得1999-2001年间Linux发展如火如荼,当时国内涌现出大量的Linux发行版厂商,但当用户发现Linux距离实用化还有十万八千里的时候,Linux热潮迅速冷却。业界也对此一度灰心失望,其中一部分厂商因无法盈利迅速销声匿迹,另一部分厂商则不约而同将重点放在服务器市场—与桌面市场形成鲜明对比的是,Linux以稳定可靠和低成本的优势在服务器领域获得了巨大的成功。
在一些Linux厂商放弃桌面化努力的同时,国际开源社群却不断发展壮大,自由的理念吸引越来越多一流的程序员参与。与商业模式不同,自由软件程序员在开始时都只是利用业余时间开发自己感兴趣的东西,并将其自由公开,这是一种不折不扣的贡献行为。尽管开发进度缓慢,但认同自由软件理念的开发者越来越多,一个个开源项目逐渐发展壮大。 

    在此期间一个被人忽视的重大事件就是商业巨头也积极参与进来,IBM、RedHat、SuSE、Ximian、Novell、SUN、HP等商业公司都直接介入各个开源项目,这些企业或者是将自身的成果免费提供给开源社群,或者直接派遣程序员参与项目的实际开发工作,例如SuSE(现已为Novell收购)在KDE项目上做了大量的工作,RedHat、Ximian(现已为Novell收购)则全程参与Gnome项目,IBM为Linux提供了大量的基础性代码,是推进Linux进入服务器领域的主要贡献者,SUN公司则将StarOffice赠送给开源社群,并资助成立著名的OpenOffice.org项目。这样,大量的自由软件程序员都可以从各个项目的基金会中领到薪水。在这一阶段,开源项目摆脱了程序员业余开发的模式,而由高水平的专职程序员主导,这也成为各个自由软件项目的标准协作模式。与商业软件公司不同,自由软件项目的参与者都是首先为个人兴趣而工作,他们的共同目标都是拿出品质最好的软件,在协作模式稳定成形之后,各个软件就进入到发展的快行道。进入2005年后,这些项目基本上都获得了丰硕的成果,其中最突出的代表就是Firefox浏览器的成功,而作为两大图形环境,KDE和GNOME分别发展到3.5和2.12版本,两者的可用性完全可以媲美Windows。更重要的是,开源社群的发展壮大为这些项目的未来发展奠定了坚实的基础:KDE项目将超越Windows作为自己的目标,力量更强大的GNOME项目更是将开发目标定在超越Mac OS X的Aqua图形环境;Firefox则计划运用GPU的硬件资源来渲染图像,达到大幅度提高速度的目的;OpenOffice.org在努力提升品质的同时奠定了开放文档格式标准。除了上述主要项目之外,我们也看到如Mplayer播放器、Xine播放器、Thunderbird邮件客户端、SCIM输入平台等其他开源项目也在快速发展成熟之中,且几乎每一天都有新的项目在诞生。有意思的是,除了涉及到软件开发外,还出现了为Linux设计视觉界面的开放协作项目,全球各地有着共同目标的艺术家通过互联网组织到一起,共同为Linux系统设计一流的视觉界面、系统图标,而所有的自由软件程序员都有一个共同的目标,那就是开发出一流水准的软件提供给大众使用。这种基于挑战自我、带有浓烈精神色彩的软件开发模式成为商业软件之外的另外一极。现在,微软面对的并不是那些只在业余时间鼓捣代码的程序员,而是分布在全球各地、数量庞大、且拥有一流技术水平的开发者,这些开发者被有效地组织起来,形成一个个有序的协作团队,大量实力雄厚的商业公司在背后提供支持。虽然今天的Linux系统还无法在桌面领域被广为接纳,但只需要两、三年时间,高速进化的Linux平台将可达到全面进军桌面的水准,也正是看到其中的机会,Novell、RedHat等重量级Linux企业都不断在技术和市场推广方面加大投入,Linux桌面化近在咫尺。 

    在介绍完必要的背景之后,我们将进入关于KDE与GNOME的技术专题。如果你是刚刚接触Linux的新手,一定会对KDE和GNOME感到困惑不已—为何会有两个功能重复、操作习惯迥异的图形环境?这不仅麻烦也耗费开发者精力。通过本文,你将获得清晰的答案。而更重要的是,我们将在本文中向大家介绍KDE与GNOME的实际水平、各自的优点和未来发展趋势。如果你对Linux桌面应用有些兴趣,那么未来的KDE/GNOME一定会让你感到震惊不已。

X Window打造桌面环境 

    在介绍KDE和Gnome之前,我们有必要先来介绍UNIX/Linux图形环境的概念。对一个习惯Windows的用户来说,要正确理解UNIX/Linux的图形环境可能颇为困难,因为它与纯图形化Windows并没有多少共同点。Linux实际上是以UNIX为模板的,它继承了UNIX内核设计精简、高度健壮的特点,无论系统结构还是操作方式也都与UNIX无异。简单点说,你可以将Linux看成是UNIX类系统中的一个特殊版本。我们知道,微软Windows在早期只是一个基于DOS的应用程序,用户必须首先进入DOS后再启动Windows进程,而从Windows 95开始,微软将图形界面作为默认,命令行界面只有在需要的情况下才开启,后来的Windows 98/Me实际上也都隶属于该体系。但在Windows 2000之后,DOS被彻底清除,Windows成为一个完全图形化的操作系统。但UNIX/Linux与之不同,强大的命令行界面始终是它们的基础,在上个世纪八十年代中期,图形界面风潮席卷操作系统业界,麻省理工学院(MIT)也在1984年与当时的DEC公司合作,致力于在UNIX系统上开发一个分散式的视窗环境,这便是大名鼎鼎的“X Window System”项目。不过,X Window(请注意不是X Windows)并不是一个直接的图形操作环境,而是作为图形环境与UNIX系统内核沟通的中间桥梁,任何厂商都可以在X Window基础上开发出不同的GUI图形环境。MIT和DEC的目的只在于为UNIX系统设计一套简单的图形框架,以使UNIX工作站的屏幕上可显示更多的命令,对于GUI的精美程度和易用程度并不讲究,毕竟那时候能够熟练操作UNIX的都是些习惯命令行的高手,根本不在乎GUI存在与否。1986年,MIT正式发行X Window,此后它便成为UNIX的标准视窗环境。紧接着,全力负责发展该项目的X协会成立,X Window进入了新阶段。与此同步,许多UNIX厂商也在X Window原型上开发适合自己的UNIX GUI视窗环境,其中比较著名的有SUN与AT&T联手开发的“Open Look”、IBM主导下的OSF(Open Software Foundation,开放软件基金会)开发出的“Motif”。而一些爱好者则成立了非营利的XFree86组织,致力于在X86系统上开发X Window,这套免费且功能完整的X Window很快就进入了商用UNIX系统中,且被移植到多种硬件平台上,后来的Linux也直接从该项目中获益。当然,这些早期的X Window环境都设计得很简单,许多GUI元素模仿于微软的Windows,但X Window拥有一个小小的创新:当鼠标指针移动到某个窗口时,该窗口会被自动激活,用户无需点击便能够直接输入,简化了用户操作—这个特性在后来的KDE和Gnome中也都得到完整的继承。

    由于必须以UNIX系统作为基础,X Window注定只能成为UNIX上的一个应用,而不可能与操作系统内核高度整合,这就使得基于X Window的图形环境不可能有很高的运行效率,但它的优点在于拥有很强的设计灵活性和可移植性。X Window从逻辑上分为三层:最底层的X Server(X服务器)主要处理输入/输出信息并维护相关资源,它接受来自键盘、鼠标的操作并将它交给X Client(X客户端)作出反馈,而由X Client传来的输出信息也由它来负责输出;最外层的X Client则提供一个完整的GUI界面,负责与用户的直接交互(KDE、Gnome都是一个X Client),而衔接X Server与X Client的就是“X Protocol(X通讯协议)”、它的任务是充当这两者的沟通管道。尽管UNIX厂商采用相同的X Window,但由于终端的X Client并不相同,这就导致不同UNIX产品搭配的GUI界面看起来非常不一样。

KDE项目的发起 

    MIT的X Window推出之后就成为UNIX图形界面的标准,但在商业应用上分为两大流派:一派是以Sun公司领导的Open Look阵营,一派是IBM/HP领导的OSF(Open Software Foundation)的Motif,双方经过多年竞争之后,Motif最终获得领先地位。不过,Motif只是一个带有窗口管理器(Window-Manager)的图形界面库(Widget-Library),而非一个真正意义上的GUI界面。经过协商之后IBM/HP与SUN决定将Motif与Open Look整合,并在此基础上开发出一个名为“CDE(Common Desktop Environment) ”的GUI作为UNIX的标准图形界面。遗憾的是,Motif/CDE和UNIX系统的价格都非常昂贵,而当时微软的Windows发展速度惊人并率先在桌面市场占据垄断地位,CDE则一直停留在UNIX领域提供给root系统管理员使用,直到今天情况依然如此。 

    在上个世纪九十年代中期,以开源模式推进的Linux在开发者中已经拥有广泛的影响力。尽管X Window已经非常成熟,也有不少基于X Window的图形界面程序,但它们不是未具备完整的图形操作功能就是价格高昂(如CDE),根本无法用于Linux系统中。如果Linux要获得真正意义上的突破,一套完全免费、功能完善的GUI就非常必要。1996年10月,图形排版工具Lyx的开发者、一位名为Matthias Ettrich的德国人发起了KDE(Kool Desktop Environment)项目,与之前各种基于X Window的图形程序不同的是,KDE并非针对系统管理员,它的用户群被锁定为普通的终端用户,Matthias Ettrich希望KDE能够包含用户日常应用所需要的所有应用程序组件,例如Web浏览器、电子邮件客户端、办公套件、图形图像处理软件等等,将UNIX/Linux彻底带到桌面。当然,KDE符合GPL规范,以免费和开放源代码的方式运行。

    KDE项目发起后,迅速吸引了一大批高水平的自由软件开发者,这些开发者都希望KDE能够将Linux系统的强大能力与舒适直观的图形界面联结起来,创建最优秀的桌面操作系统。经过艰苦卓绝的共同努力,KDE 1.0终于在1998年的7月12日正式推出。以当时的水平来说,KDE 1.0在技术上可圈可点,它较好的实现了预期的目标,各项功能初步具备,开发人员已经可以很好地使用它了。当然,对用户来说,KDE 1.0远远比不上同时期的Windows 98来得平易近人,KDE 1.0中大量的Bug更是让人头疼。但对开发人员来说,KDE 1.0的推出鼓舞人心,它证明了KDE项目开源协作的开发方式完全可行,开发者对未来充满信心。有必要提到的是,在KDE 1.0版的开发过程中,SuSE、Caldera等Linux商业公司对该项目提供资金上的支持,在1999年,IBM、Corel、RedHat、富士通-西门子等公司也纷纷对KDE项目提供资金和技术支持,自此KDE项目走上了快速发展阶段并长期保持着领先地位。但在2004年之后,GNOME不仅开始在技术上超越前者,也获得更多商业公司的广泛支持,KDE丧失主导地位,其原因就在于KDE选择在Qt平台的基础上开发,而Qt在版权方面的限制让许多商业公司望而却步。 

    Qt是一个跨平台的C++图形用户界面库,它是挪威TrollTech公司的产品。基本上,Qt同X Window上的 Motif、Open Look、GTK等图形界面库和Windows平台上的 MFC、OWL、VCL、ATL是同类型的东西,但Qt具有优良的跨平台特性(支持Windows、Linux、各种UNIX、OS390和QNX等)、面向对象机制以及丰富的API,同时也可支持2D/3D渲染和OpenGL API。在当时的同类图形用户界面库产品中,Qt的功能最为强大,Matthias Ettrich在发起KDE项目时很自然选择了Qt作为开发基础,也正是得益于Qt的完善性,KDE的开发进展颇为顺利,例如Netscape5.0在从Motif移植到Qt平台上仅仅花费了5天时间。这样,当KDE 1.0正式发布时,外界看到的便是一个各项功能基本具备的GUI操作环境,且在后来的发展中,Qt/KDE一直都保持领先优势。有必要提到的是,TrollTech公司实质性参与了KDE项目,如前面提到Netscape 5.0 的移植工作就是由TrollTech的程序员完成,而KDE工程的发起者、Matthias Ettrich本人也在1998年离开学术界加入TrollTech,并一直担任该公司的软件开发部主管,因此TrollTech公司对于KDE项目拥有非常强的影响力(当然不能说绝对掌握,毕竟KDE开发工作仍然是由自由程序员协作完成的)。我们前面提到,KDE采用GPL规范进行发行,但底层的基础Qt却是一个不遵循GPL的商业软件,这就给KDE上了一道无形的枷锁并带来可能的法律风险。一大批自由程序员对KDE项目的决定深为不满,它们认为利用非自由软件开发违背了GPL的精神,于是这些GNU的狂热信徒兵分两路:其中一部分人去制作Harmonny,试图重写出一套兼容Qt的替代品,这个项目虽然技术上相对简单,但却没有获得KDE项目的支持;另一路人马则决定重新开发一套名为“GNOME(GNU Network Object Environment)”的图形环境来替代KDE,一场因为思想分歧引发的GUI之战开始了。

GNOME与KDE交替发展 

    GNOME项目于1997年8月发起,创始人是当时年仅26岁的墨西哥程序员Miguel De Icaza。关于GNOME的名称有一个非常有趣的典故:Miguel到微软公司应聘时对它的ActiveX/COM model颇有兴趣,GNOME(Network Object Model )的名称便从此而来。GNOME选择完全遵循GPL的GTK图形界面库为基础,因此我们也一般将GNOME和KDE两大阵营称为GNOME/GTK和KDE/Qt。与Qt基于C++语言不同,GTK采用较传统的C语言,虽然C语言不支持面向对象设计,看起来比较落后,但当时熟悉C语言的开发者远远多于熟悉C++的开发者。加之GNOME/GTK完全遵循GPL版权公约,吸引了更多的自由程序员参与,但由于KDE先行一步,且基础占优势,一直都保持领先地位。1999年3月,GNOME 1.0在匆忙中推出,稳定性奇差无比,以至于许多人笑称GNOME 1.0还没有KDE 1.0 Alpha稳定,而同期的KDE 1.1.2无论在稳定性还是功能上都远胜于GNOME,直到10月份推出的GNOME 1.0.55版才较好解决了稳定性问题,给GNOME重新赢回声誉。由于思想分歧,当时GNOME的开发者与KDE的开发者在网络上吵得天翻地覆,几乎达到相互仇视的地步。但不管怎么说,GNOME都跌跌撞撞迈出了第一步,尽管那时KDE几乎是所有Linux发行版默认的桌面环境。 

    GNOME的转机来自于商业公司的支持。当时Linux业界的老大RedHat很不喜欢KDE/Qt的版权,在GNOME项目发起后RedHat立刻对其提供支持。为了促进GNOME的成熟,RedHat甚至专门派出几位全职程序员参与GNOME的开发工作,并在1998年1月与GNOME项目成员携手成立了RedHat高级开发实验室。1999年4月,Miguel与另一名GNOME项目的核心成员共同成立Helix Code公司为GNOME提供商业支持,这家公司后来更名为Ximian,它事实上就成为GNOME项目的母公司,GNOME平台上的Evolution邮件套件便出自该公司之手。进入2000年之后,一系列重大事件接连发生,首先,一批从苹果公司出来的工程师成立Eazel公司,为GNOME设计用户界面和Nautilus(鹦鹉螺)文件管理器。同年8月,GNOME基金会在Sun 、RedHat、Eazel、Helix Code(Ximian)的共同努力下正式成立,该基金会负责GNOME项目的开发管理以及提供资金,Miguel本人则担任基金会的总裁。此时,GNOME获得许多重量级商业公司的支持,如惠普公司采用GNOME作为HP-UX系统的用户环境,SUN则宣布将StarOffice套件与GNOME环境相整合,而GNOME也将选择OpenOffice.org作为办公套件,IBM公司则为GNOME共享了SashXB极速开发环境。同时,GNOME基金会也决定采用Mozilla作为网页浏览器。KDE阵营也毫不示弱,在当年10月份推出万众瞩目的KDE 2.0。KDE 2.0堪称当时最庞大的自由软件,除了KDE平台自身外,还包括Koffice办公套件、Kdevelop集成开发环境以及Konqueror网页浏览器。尽管这些软件都还比较粗糙,但KDE 2.0已经很好实现了Matthias Ettrich成立KDE项目的目标。也是在这个月,TrollTech公司决定采用GPL公约来发行Qt的免费版本,希望能够以此赢得开发者的支持。这样,Qt实际上就拥有双重授权:如果对应的Linux发行版采用免费非商业性的方式进行发放,那么使用KDE无须向TrollTech交纳授权费用;但如果Linux发行版为盈利性的商业软件,那么使用KDE时必须获得授权。由于TrollTech是商业公司且一直主导着KDE的方向,双许可方式不失为解决开源与盈利矛盾的好办法。TrollTech宣称,双许可制度彻底解决了KDE在GPL公约方面的问题,但RedHat并不喜欢,RedHat不断对GNOME项目提供支持,希望它能够尽快走向成熟,除RedHat之外的其他Linux厂商暂时都站在KDE这一边,但他们同时也在发行版中捆绑了GNOME桌面。

     在2001-2002年,火热一时的Linux运动开始陷入低潮期,几乎所有的厂商都发现桌面Linux版本不可能盈利,而易用性的不足也让业界不看好Linux进入桌面的前途。但在服务器市场,Linux发展势头非常迅猛,直接对UNIX和Windows Server造成威胁。不过,秉承自由软件理念的开发者们并不理会外界的论调,他们一直将Linux桌面化作为目标,GNOME项目和KDE项目都在这期间获得完善发展。2001年4月,GNOME 1.4发布,它修正了之前版本的Bug,功能也较为完善,但在各方面与KDE依然存在差距;同年8月,KDE发展到2.2版本。2002年4月,KDE跳跃到3.0版本,它以Qt 3.0为基础,各项功能都颇为完备,具备卓越的使用价值;两个月后,GNOME阵营也推出2.0版本,它基于更完善的GTK 2.0图形库。进入到2003年后,KDE与GNOME进入真正意义上的技术较量。1月份,KDE 3.1推出,而GNOME 2.4则在随后的2月份推出,两大平台都努力进行自我完善。也是在这一年,Linux商业界出现一系列重大的并购案:1月份,Novell公司宣布收购德国的SuSE Linux,而SuSE Linux是地位仅次于RedHat的全球第二大Linux商业企业;8月,Novell接着将GNOME的母公司Ximian收归旗下。这两起并购案让Novell成为实力与RedHat不相上下的强大Linux企业,而Novell和RedHat就成为能够影响Linux未来的两家企业。在图形环境上,SuSE一向选择KDE,并在KDE身上投入相当多的精力,在被Novell并购后,SuSE的桌面发行版尽管还侧重于KDE,但同样不喜欢Qt授权的Novell已经开始向GNOME迁移。 

    进入2004年后,KDE与GNOME依然保持快速发展,KDE阵营分别在2月份和8月份推出3.2、3.3版本,GNOME则在3月和9月推出2.6和2.8,两者的版本升级步幅旗鼓相当。到3.3版本的KDE已经非常成熟,它拥有包括KOffice、Konqueror浏览器、Kmail套件、KDE即时消息在内的一大堆应用软件,且多数都达到可用标准,功能上完全不亚于Windows 2000。而GNOME更是在此期间高速发展,GNOME 2.8版本的水准完全不逊于KDE 3.3,而且此时两者的技术特点非常鲜明:GNOME讲究简单、高效,运行速度比KDE更快;KDE则拥有华丽的界面和丰富的功能,使用习惯也与微软Windows较类似。商业支持方面,RedHat还是GNOME的铁杆支持者,IBM、SUN、Novell、HP等重量级企业也都选择GNOME,而KDE的主要支持者暂时为SuSE、Mandrake以及中科红旗、共创开源在内的国内发行商。2005年,厚积薄发的GNOME开始全面反超,3月份的2.10、9月份的2.12让GNOME获得近乎脱胎换骨的变化,加之OpenOffice.org 2.0、Firefox 1.5等重磅软件的出台让GNOME如虎添翼;KDE方面则分别在3月和11月推出3.4和3.5,其中KDE 3.5也逼近完美境地,我们认为它的水平与GNOME 2.12不相伯仲。但KDE在商业支持方面每况愈下,Novell在11月宣布旗下所有的商业性发行版将使用GNOME作为默认桌面(仍会对KDE Libraries提供支持),SuSE Linux桌面版则会对KDE与GNOME提供同等支持,而社区支持的OpenSuSE仍将使用KDE体系—但谁都明白GNOME将成为Novell的重心,KDE只是活跃在免费的自由发行版中。 

    到这里,我们发现一个颇富戏剧性的结局:致力于商业化的KDE反而失去了重量级商业企业的支持,尽管一些中小规模的Linux企业因技术能力问题将继续支持KDE,但它的商业前途有限。而遵循GPL、完全不以商业化为目的的GNOME反而在该领域大获成功。许多Linux发烧友都不明白为什么优秀的KDE会受到如此待遇,其实道理非常简单—没有哪一家重量级企业喜欢受制于人,也许KDE的Qt不需要很多授权费,但谁知道TrollTech公司以后会不会漫天要价?既然有免费的GNOME可以选择,那为什么不呢?基于此种理由,RedHat、Novell两家最大的Linux企业和SUN都采用GNOME,而它们对GNOME的鼎力支持也让该项目可拥有足够多的技术保证,为今后的高速发展奠定坚实的基础。需要纠正一个可能的误解,虽然Novell收购了Ximian,但RedHat并没有受到太大影响,双方对GNOME的贡献都是相互共享的,因为GNOME以GPL自由版权公约发行,合作即共赢。至于KDE项目,虽然它失去这些商业巨头的支持,但没有能力转换桌面的中小Linux厂商将继续追随KDE,而且在非商业的社区Linux发行版中,KDE依然有强大的生命力。 

    虽然在商业方面存在竞争,GNOME与KDE两大阵营的开发者关系并没有变得更糟,相反他们都意识到支持对方的重要性。如果KDE和GNOME无法实现应用程序的共享,那不仅是巨大的资源浪费,而且将导致Linux出现根本上的分裂。事实上,无论是GNOME的开发者还是KDE的开发者,他们都有着共同的目标,就是为Linux开发最好的图形环境,只是因为理念之差而分属不同的阵营。KDE与GNOME的商业竞争对开发者们其实没有任何利益影响(只有TrollTech会受影响),基于共同的目的,KDE与GNOME阵营大约从2003年开始逐渐相互支持对方的程序—只要你在KDE环境中安装GTK库,便可以运行GNOME的程序,反之亦然。经过两年多的努力,KDE和GNOME都已经实现高度的互操作性,两大平台的程序都是完全共享的,例如你可以在GNOME中运行Konqueror浏览器、Koffice套件,也可以在KDE中运行Evolution和OpenOffice.org,只不过执行本地程序的速度和视觉效果会好一些。在未来一两年内,KDE和GNOME将进行更高等级的融合,但两者大概永远都不会合为一体—GNOME还是GNOME,KDE也还是KDE。或许你觉得这是浪费开发资源而且很可能让用户无从选择,但我们告诉你这就是Linux,它与Windows和Mac OS X有着绝然不同的文化。更何况全球有越来越多自由软件开发者(所以不必担心浪费开发资源),Linux用户的使用偏好也不可能总是相同,保持两个并行发展的图形环境项目没有什么不妥。至于GNOME项目和KDE项目的开发者们,曾经因为理念不同而吵得天翻地覆,但他们现在尽释前嫌,因为所有人都意识到,他们其实彼此需要,团结在一起可以让他们在硬件厂商面前有更大的发言权,从而促使厂商在推出Windows驱动的同时也提供相应的Linux版本,而且彼此可以相互借鉴优秀的设计,确保Linux拥有一个最出色的图形桌面环境。

KDE与GNOME走向融合 

    2006年,GNOME与KDE都站在一个全新的起点,获得商业公司和更多自由程序员支持的GNOME踌躇满志,将超越的目光放在Mac OS X系统。也许你认为Windows Vista的半透明和三维界面将Linux远远抛在后面,那么我们告诉你这是绝对的误解,GNOME目前已经可以实现类似的效果,Novell在前几个月就向外界作过详细的演示。当前的KDE也可支持相当不错的半透明和阴影特效,技术上毫不落后于GNOME。现在,GNOME项目朝向革命性的3.0版本迈进,KDE则致力于开发同样有重大技术变革的4.0,这两个成果大概在2007年可进入现实,届时Linux系统将具备更卓越的可用性。也就是说,Linux桌面应用的全面铺开指日可待,而除了开发者和厂商的努力外,如何向企业和个人用户推广以及提供培训将是厂商要考虑的主要问题,我们今天恰好站在这样的一道门槛上。

2006年04月04日

创建型

    类 Factory Method。

    对象 Abstract Factory,Builder,Prototype,Singleton。

结构型

    类 Adapter。

    对象 Adapter,Bridge,Composite,Decorator,Facade,Flyweight,Proxy。

行为型

    类 Interpreter,Template Method。

    对象 Chain of Responsibility,Command,Iterator,Mediator,Memento,Observer,State,Strategy,Visitor。

2006年04月01日

Chapter 3 Measure Twice, Cut Once: Upstream Prerequisites

3.1 Importmance of Prerequisites

使用高质量的实践方法是那些能创造高质量软件的程序员的共性.这些高质量的实践方法在项目的初期[计划设计],中期[构建实践],末期[测试]都强调质量.前期准备就是定义问题,定下解决方案的规格,以及设计解决房案的时候做出这种计划.

Prerequisites的中心目标就是降低风险:一个好的项目规划者能够尽早地将主要的风险清除掉,以示项目的大部分工作能够尽可能地平稳地进行.准备工作倾向于集中改进需求分析和项目规划.

首先程序员应该意识到前期准备的重要性,其次必须具备完成项目规划创作的专业技能,再次排除一切干扰进行前期准备.WISCA[why isn't sam coding anything],WIMP[why is't mary programming]

项目计划,对于管理者意味着项目所需时间人数以及计算机台数.从技术角度意味着弄清楚你想要建造的是什么,以防止浪费钱去建造一个错误的东西.在开始之前先思考打算如何去做,这也很重要.

程序员是软件食物链的最后一环,架构师吃掉需求,设计师吃掉架构,而程序员则消化设计.
发现错误的时间要尽可能接近引入该错误的时间,缺陷在食物链中呆的时间越长,他对食物链后继造成的损害就越严重.

3.2 Determine the kind of software you’re working on

序列式开发法[sequential]

需求相当稳定
设计直截了当 而且理解透彻
开发团队对于这一应用领域非常熟悉
项目风险很小
长期可预测性很重要
后期改变需求设计编码的代价很可能较昂贵

迭代式开发法[interative]

需求并没有被理解透彻或者出于其他理由你认为他是不稳定的
设计很复杂或者有挑战性或者两者兼具
开发团队对于这一应用领域不熟悉
项目包含许多风险
长期可预测性不重要
后期改百年需求设计代码的代价可能较低

3.3 Problem Definition Prerequisite

[产品设想/product vision][产品定义/vision statement][任务陈述/mission statement][产品定义/product definition][问题定义/problem definition]
只定义了问题是什么,不涉及任何可能的解决方案,问题定义在具体的需求分析工作之前,而需求分析是对所定义的问题的深入调查,用客户语言来写,从客户角度来写.

3.4 Requirements Prerequisite

[需求开发/requirements development][需求分析/requirements analysis][分析/analysis][需求开发/requirements definition][软件需求/software requirements][规格书/specification][功能规格书/functional spec]

明确的需求确保用户可以驾驭系统的功能 用户可以自行评审

需求不是稳定的

构建期间的需求变更[需求核对表--功能,非功能,质量,完备性]

3.5 Architecture Prerequisite

[系统架构/system architecture][高层设计/high-level design][顶层设计/top-level design][架构规格说明书/architecture specification]

构架的组成部分

program organization 定义程序的主要构造块,每个列在需求中的功能特性都至少应该有一个构造块覆盖它,明确每个构造块的通信规则.
Major Classes
Data Design 数据应该只由一个子系统或一个类直接访问.
Business Rules
User Interface design
Resource Management 架构应该描述一份管理稀缺资源[数据库连接,线程,句柄]的计划.
Security
Performance
Scalability
Interoperability
Internationalization/Localization
Input/Output
Error Processing
Fault Tolerance
Architectural Feasibility
Overengineering
Reuse Decisions
Change Strategy
General Architectural Quality

3,6 Amount of time to spend on upstream prerequisites

      我今天很荣幸在这个世界上最好的大学之一的毕业典礼上和你们在一起.我从来没有从大学中毕业.说实话,今天也许是我在我的生命中离大学毕业最近的一天了. 今天我想向你们讲我生活中的三个故事. 不是什么大不了的事情,只是三个故事而已.

      第一个故事是关于把生命中的点联系起来的.(connecting the dots)

      我在Reed大学读了六个月之后就退学了,但是在十八个月以后我真正的作出决定退学之前,我还经常去学校.我为什么要退学呢?

      故事要从我出生的时候开始讲起.我的生物学意义上的母亲,那是一个年轻的, 没有结婚的大学毕业生. 她决定让别人收养我, 她十分想让我被大学毕业生收养.所以在我出生的时候她已经为了我被一个律师和他的妻子收养做好了一切的准备工作.但是她没有料到,当我被生出来的时候,律师夫妇突然决定他们想要一个女孩. 所以我的父母,他们当时还在我的生物学意义上父母的候选名单上,突然在半夜接到了一个电话:"我们现在这儿有一个不小心生出来的男婴,你们想要他吗"他们回答道:"当然"但是我的生物学意义上的母亲随后发现我的母亲从来没有从大学毕业,而我的父亲从来没有从高中毕业. 她拒绝签这个收养合同.只是在几个月以后,我的父母答应她一定要让我上大学,那个时候她才同意.

      在十七岁那年,我真的上了大学.但是我很愚蠢的选了一个几乎和你们斯坦福大学一样贵的学校, 我的蓝领父母的所有积蓄都花在了我的学费上面. 在六个月后, 我已经看不到其中的价值. 我不知道我想要在我的生命中作甚么,我也不知道大学能怎么样帮助我找到这个问题的答案. 但是在这里我几乎花光了我父母这一辈子所有的积蓄.所以我决定要退学,我觉对这是个正确的决定. 不能否认,我当时确实非常的害怕, 但是现在回头看看,那的确是我这一生中最棒的一个决定.在我做出退学决定的那一刻, 我终于可以不必去上那些令我提不起丝毫兴趣的课程了. 然后我还可以去上上那些看起来有点意思的课程.

      但是这并不是那么罗曼蒂克. 我失去了我的宿舍,所以我只能在朋友的房间的地板上面睡觉,我去捡5??的可乐瓶子,仅仅为了吃饭,在星期天的晚上,我可以走七英里穿过这个城市到Hare Krishna temple,只是为了在能吃上这个星期唯一一顿好一点的饭. 但是我喜欢. 我跟着我的直觉和好奇心走, 遇到的很多东西,在后来被证明是无价之宝. 让我给你们一个例子吧.

      Reed大学在那时提供也许是全美最好的美术字课程. 在这个大学里面的每个海报, 每个抽屉的标签上面全都是漂亮的美术字. 因为我退学了,没有受到正规的训练, 所以我决定去参加这个课程去学学怎么写出漂亮的美术字. 我学到了san serif serif字体,我学会了怎么样在不同的字母组合之中改变空格的长度, 还有怎么样才能作出最棒的印刷式样 .那是一种科学永远不能捕捉的美丽的,真实的,艺术的精妙, 我发现那实在是太美妙了.

      当时看起来这些东西在我的生命中都好像没有什么实际应用的可能. 但是十年之后,当我们在设计第一台Macintosh电脑的时候,就不是那么回事了.我把当时我学的那些家伙全都设计进了Mac. 那是第一台有着漂亮的印刷样式的电脑. 如果我当时没有退学,就不会有机会去参加这个我感兴趣的美术字课程, Mac就不会有这么多的字体和字体中间适合的空间.那么现在个人电脑就不会有现在这么美妙的印刷样式. 当然在我还在大学的时候是不可能向前看将这些点联系起来的,但是当我十年后回头看的时候, 真是非常,非常的清楚.

      再次要说的是,你在向前看的时候不可能将这些点联系起来;你只能在向后看的时候将这些点联系起来.       所以你必须相信这些点会在你的未来的某一天联系起来.你必须要相信某些东西, 你的勇气, 目的, 生命, 因缘.       这个过程永远不会让我倒下,只是让我的生命更加的与众不同而已.

      我的第二个故事是关于爱和损失的.

      我非常幸运, 因为我在很早的时候就找到了我爱的东西. Woz和我在我二十岁的时候就在父母的车库里面开始了我们的苹果公司. 我们工作得很努力,十年之后, 这个公司从只有在车库中的两个穷光蛋发展成了有超过四千雇员,价值超过二十亿的大公司. 在那时的前一年, 我们刚刚发布了我们最好的产品, 那就是Macintosh. 我也就要三十岁了. 在那个时候, 我被炒了鱿鱼.       你怎么可能会从你自己创立的公司被炒鱿鱼呢? , 在苹果发展的时候我们雇了一个很有天分的家伙和我一起管理这个公司,在最初的几年,公司运转的很好. 但是后来我们对未来的看法发生了分歧, 最终我们吵了起来. 当争吵发生的时候, 董事会站在了他那边. 所以在三十岁的时候, 我被炒了.在这么多人的眼皮下我被炒了.我整个成年之后生活的焦点离我而去, 这真是毁灭性的打击.

      在最初的几个月里我真是不知道该做些什么. 我把之前创业者交给我的指挥棒给丢了, 我觉得我让那一代的创业者都很沮丧. 我和David PackBob Boyce见面并试图向他们道歉. 我把事情弄得如此的糟糕. 但是我渐渐发现了曙光, 我仍然喜爱我作的这些东西.       苹果公司发生的这些事情丝毫的没有改变这些, 一个bit也没有. 我被驱逐了,但是我仍然在爱中. 所以我决定从头再来.

      我当时没有看到, 但是事后证明, 从苹果公司被炒是我这辈子发生的最棒的事情. 作为一个成功者的极乐感觉被重新作为一个创业者的轻盈感觉所代替: 对任何事情都不那么肯定. 这让我觉得如此自由, 进入了我生命中最有创造力的一个阶段.

      在接下来的五年里, 我创立了一个名叫NeXT的公司, 还有一个叫Pixar的公司, 然后和一个将要成为我妻子的美妙的女人相识了. Pixar 制作了世界上第一个用电脑制作的动画电影 , "玩具总动员", 现在是世界上最成功的工作室. 在后来的一系列转变中, Apple收购了NeXT,然后我又回到了Apple. 我们在NeXT发展的技术在Apple的复兴之中发挥了关键的作用. 我还和 Laurence 一起拥有了一个美妙的家庭.

      我可以非常肯定,如果我不从Apple被开除的话, 这些事情是一件也不会发生的. 这个药的味道实在是太苦了, 但是我想病人需要这个药.有些时候, 生活会拿起一块转头向你的脑袋上猛拍一下. 不要失去信心. 我很清楚唯一使我一直走下去的就是我爱我所做的.
     
你需要去找到你所爱的东西. 对于工作是如此, 对于你的爱人也是如此. 你的工作将会在你的生活中占据很大的一部分
.
     
你只有相信你所做的是伟大的工作, 你才能满足. 如果你现在还没有找到, 那么继续找. 不要停下来. 全心全意的去找,当你找到的时候你会知道的. 就像任何伟大的关系一样, 随着岁月的流逝只会越来越好. 所以继续找直到你找到它. 不要停下来
.

      我的第三个故事是相当于死亡的.

      当我十七岁的时候, 我读到了一句像这样的话:"如果你把每天当作是你的最后一天去活的话,那么有一天你会发现你是正确的 ."
     
这句话给我留下了很深的印象. 从那是开始, 过了33, 我在每天早晨都会在镜子中间看自己并且问自己:"如果今天是我生命中的最后一天,你会不会完成你今天想做的事情呢 ". 当答案连续很多次是"不是"的时候, 我知道我需要改变某些事情了
.

      记住我不久就将要死去是我遇到的最重要的工具. 他帮我组出生命中的重要的选择. 因为几乎所有的事情, 包括外部的期望, 所有的骄傲, 所有对难堪和失败的恐惧, 这些东西在死亡面前都会消失. 留下真正重要的东西让我看到.

      你有时候会思考你将会失去某些东西,记住你就要死去是我知道的避免这些想法的最好办法. 你已经赤身裸体了, 你没有理由不去跟随你自己的心.

      大概一年以前, 我被诊断有癌症. 我在早晨七点半做了一个检查, 检查清楚的显示在我的胰腺有一个肿瘤. 我当时都不知道胰腺是什么东西.
     
医生告诉我那很可能是一种无法治愈的癌症, 我还有三到六个月的时间活在这个世界上. 我的医生叫我回家, 然后整理好我的一切,那就是医生准备死亡的程序. 那意味着你将要把未来十年对你小孩说的话在几个月里面说完. 那意味着把每件事情都搞定,让你的家人会尽可能轻松的生活, 那意味着你要说
byebye.

      我整天和那个诊断书一起生活. 后来有一天早上我作了一个活切片检查. 医生将一个内窥镜从我的喉咙,通过我的胃, 然后进入我的肠子,用一根针在我的胰腺上的肿瘤上取了几个细胞. 我当时很镇静,因为我被服了镇定剂 但是我的妻子在那里,后来告诉我当医生在显微镜地下观察这些细胞的时候他们开始尖叫, 因为这些细胞最后竟然是一种非常罕见的可以用手术治愈的胰腺癌症. 我做了这个手术,现在我好了.

      那是我最接近死亡的时候, 我还希望这也是以后的几十年最接近的一次. 从中又活了过来, 我可以更肯定一点地的对你们说, 比死亡对我只是一个有用但是纯粹是知识上的概念地时候更加肯定一点地对你们说:

      没有人愿意死, 即使人们想上天堂, 人们也不会为了去那里而死. 但是死亡是我们每个人都公有的终点. 从来没有人逃脱它. 也应该是这样. 因为死亡就是生命中最好的一个发明. 他将旧的清除以给新的让路. 你们现在是新的, 但是从现在开始之后不久, 你们将会逐渐的变成旧的然后被清除. 我很抱歉这很戏剧性, 但是这十分的真实.

      你们的时间很有限, 所以不要将他们浪费在过其他人的生活上. 不要被教条束缚,那意味着你和其他人思考的结果一起生活.       不要被其他人的观点的噪声掩盖你真正的内心的声音. 还有最重要的是, 你要有勇气去听从你直觉和心的指示. 他们在某种程度上知道你想要成为什么样子. 所有其他的事情都是其次的.

      当我年轻的时候, 有一本惊人的出版物叫"整个地球的目录", 是我们那一代人的圣经之一. 它是一个叫 Stewart Brand 的家伙在离这里不远的Menlo Park弄的, 他诗一般地将这本书带到这个世界.那是在六十年代地后期, 在个人电脑出现之前,所以这本书全是用打字机, 剪刀还有偏光镜制造地. 有点像用软皮包装地google, google出现三十五年之前: 这是理想主义地,其中有许多灵巧地工具和伟大的想法.

      Stewart和他的伙伴出版了几期的"整个地球的目录", 当它完成了自己的使命的时候, 他们作出了最后一期的目录. 那是在七十年代的中期,你们的时代. 在最后一期的封底上清晨乡村公路的照片, 如果你有冒险精神的话你可以自己找到这种路的. 在照片之下有这样一段话:"保持饥饿,保持愚蠢".这是他们停止发行的告别语. 保持饥饿,保持愚蠢. 我总是希望自己能够那样,现在, 在你们将要毕业开始新的旅程的时候, 我也希望你们能这样.

      保持饥饿,保持愚蠢.(Stay Hungry. Stay Foolish. )

2006年03月31日

Chapter 2  Metaphors[隐喻] for a Richer Understanding of Software Development

2.1 The Importmance of Metaphors

    重要研发的成果常常产自类比[analogy],通过把你不太理解的东西和一些你较为理解,且十分类似的东西作比较,你可以对这些不太理解的东西产生更深刻的理解.这种使用隐语的方法叫做“建模”[modeling];

    模型的威力在于其生动性,让你能够把握整个概念.它能隐隐地暗示各种属性[properties],关系[relationships],以及需要补充查证的部分[additional areas of inquiry].一个好的隐喻应该是简单的,它与另一些相关的隐喻联系密切,且能够解释大部分实验证据以及其他已观测到的现象.

    隐喻的价值决不应该低估.隐喻的优点在于其可预期的效果,能被所有的人理解.不必要的沟通和误解也大为减低,学习与教授更为快速.实际上,隐喻是对概念进行内在化[internalizing]和抽象化[abstracting]的一种途径,它让人们在更高的层面上思考问题,从而避免底层次的错误

    对于其他学科而言软件开发还是一门很年轻的学科,它还没有成熟到拥有一套标准隐喻的程度.因此必然存在许多或相互补充,或相互抵触的隐喻.某些隐喻相对好一些,而另一些则比较糟糕.你对隐喻有多理解,也就决定了你对软件开发有多理解.

2.2 How to use software metaphors

    与其说软件隐喻象是一张路线图,还不如说它是一盏探照灯.它不会告诉你到哪里去寻找答案,而近视告诉你该如何去寻找答案.隐喻的作用更像是启示[heuristic],而不是算法[algorithm].

    算法是一套定义明确的指令,使你能完成某个特定的任务.算法是可预测的[predicable],确定性的[determistic],不易变化的[not subject to chance].

    而启发式方法是一种帮你寻求答案的技术,但它给出的答案是具有偶然性的[subject to chance],因为启发式方法仅仅告诉你该如何去找,而没有告诉你要找什么. 

     如果有一些能明确知道你该如何解决编程问题的信息,编成当然会更容易,结果也更易预见.但编程这门学科还没有那么先进,或许永远都不会那么先进.对于编程来说,最大的挑战还是将问题概念化[conceptualizing],编成中的很多错误都是概念性错误.正因为每一个问题在概念上都是独特的,所以要找到一套能解决所有问题的一通百通的指导规则是很难的甚至是不可能的.如此看来,能一般性知道大致该如何解决问题,至少也和知道如何解决特定问题一样有价值了. 

    善于运用隐喻来照亮自己的软件开发过程的人,他对于编成的理解会更好,并且能够更快的写出更好的代码.

2.3 Common software Metaphors

    Software Penmanship:Writing Code

    写作代码往往是个人的事,而一个项目多半会涉及和承担许多不同职责的人.

    软件的开发注重于代码的重用[reuse]以往一些项目的设计思想,代码和测试用例[test case].

    写作这一引用意暗示着软件开发过程是一种代价昂贵的试错[trail and error]过程,而非仔细的规划和设计.

    Software Farming:Growing a System

    一次设计系统的以小部分,写一段代码,作一点测试,并将成果一点点添加到整个系统中.通过这种小步前进,你可以把每次遇到的麻烦减小到最小.

     但是糟糕的隐语描述这种好的技术往往是可笑的,对系统设计"施肥",对细节设计"疏果",并通过有效的管理土地来增加代码的"产量",最终获得大丰收,还会说轮种"C++和大麦",或者让土地闲置一年增加硬盘里的"氨肥"的供应量.

    同时它暗示了人们将无法对开发软件的过程和方式进行任何直接的控制.

    Software Oyster Farming:System Accretion

    学会给系统增加一个小部分.根生长密切相关的另一些词语有增量的[incremental],迭代的[iterative],自适应的[adaptive],演进的[evolutionary].以增量的方式惊醒设计编译和测试都是目前已知的最强有力的软件开发概念.增量开发的优势在于未做过过渡的承诺.

    如现在的,演进式交付[Evolutionary Delivery],敏捷编程[agile programming][Tom.Gilb《The Principles of software Engineering Management》]

    Software Construction:Building Software

    建造软件暗示了软件开发中存在着诸多阶段,如计划,准备,及执行等.根据所建造的软件不同,这些阶段的种类和程度可能会发生变化.建造于软件中对应的隐喻,

    构建什么类型的房子–问题定义[problem definition]
    建筑师的总体设计–架构设计[architectural design]
    建房人员完成–软件构建[software construction]
    装修美化–软件优化[software oprimization]
    以及贯穿于整个过程的检查人员的检查–软件复查/评审[reciews]和审查[inspections]

    能买得到的现成的东西,洗衣机,烘干机–使用高级语言提供的现成的东西,容器,科学计算函数,用户界面组件,数据库访问组件,因为自己编写能买得到的现成的代码通常是没有意义的.

    一流的高档住宅,特别订制的橱柜,与之搭配的洗碗机,冰箱,冷藏柜–建构一流的软件编写自己的科学计算函数以获得更快的速度和更高的精度.编写自己的容器,容器类,用户界面,数据库访问组件,可以让各部分无缝拼接,拥有一流的外观和体验.

    建筑不同的房子规划设计质保方面所学达到的成都是不一样的,在软件开发中可以使用灵活的轻量级的方法,但是为了安全性或者其他目标就得使用严格的,重量级的开发方法.

    Applying Software Techniques:The Intellectual Toolbox

    技术并不是规矩[rule],它只是分析工具[analytical tools],好的工匠知道完成某项工作要用哪些工具,也知道该怎样正确的使用.程序员也应这样,编程方面的知识你学得越多,泥淖中的工具箱就会有更多的分析工具,也会知道在何时用这些工具以及怎么正确使用它们.

    Combining Metaphors

    隐语是一种启发式方法而不是算法,因此它们并不排斥.你可以同时用多个隐喻.

Chapter 1   Wlecome to software construction

1.1  What is software construction

       Software Development

            probleme definition[定义问题]

            requirements development[需求分析]

            construction planning[规划构建]

            software architecture   /    high-level design    [软件架构]/[高层设计]

            detailed design[详细设计]

            coding and debugging[编码与测试]

            unit testing[单元测试]

            intergration test[集成测试]

            intergration[集成]

            system testing[系统测试]

            corrective maintenance[保障维护]

构建的主要活动是编码[coding]与调试[debugging],但也涉及详细设计[detailed design],规划构建[constructiong planning],单元测试[unit testing],集成[intergration],集成测试[intergration test]等其他活动单元.

软件设计中的非构建活动有:管理[management],需求分析[requirements development],软件构架设计[software architecture],用户界面设计[user interface],系统测试[system test],维护[maintenace].

编码[coding]是机械的把设计翻译成机器语言的过程,而构建[construction]需要客观的创造力和判断力,可以用编程[programming]来替代构建.

构建活动中的具体任务:
        验证有关的基础工作已经完成 因此构建活动可以顺利地进行下去;
        确定如何测试所写的代码;
        设计并编写类[class]和子程序[routine];
        设计并编写变量[variable]和具名常量[named constant];
        选择控制结构[control structure],组织语句块;
        对你的代码进行单元测试和集成测试,并排除其中的错误;
        评审开发团队其他成员的底层设计和代码,并让他们评审你的工作;
        润饰代码仔细进行代码的格式化和注释;
        将单独开发的多个软件组建集成为一体;
        调整代码[tuning code],让他更快,更省资源.

1.2  Why is software construction important?
        构建过程是软件开发的主要过程,占据软件开发的30%~80%时间;
        构建是软件开发的核心活动;需求分析和架构设计都是在构建开始前完成的基础工作,它让你进行更有效的构建,系统测试是构建的活动的后续工作,用来验证构建的正确性;
        把主要尽力集中于构建活动,大大提高程序员的生产率.;
        构建活动的产物-源代码,往往是对软件的唯一精确描述;
        构建活动是唯一项确保能完成的任务,对构建活动的改进是改进软件开发过程的一种有效途径;

2005年12月24日

Sun Microsystems 近日宣布向JCP执行委员会提交JSR 270 – Java SE 6 ("Mustang") 的最初草案。

报道中指出,该技术规范定义了Java 2 Standard Edition platform 下一代 — 命名为’Mustang’的版本主要功能,计划2006年推出。Mustang 作为J2SE 计划发布的其中之一,整个计划目标是预计将在未来的18-24个月的周期内,定期发布提升质量和增加功能的新产品。

详细内容:http://jcp.org/aboutJava/communityprocess/edr/jsr270/index.html