但是如果你没有创意该怎么办？别担心，并非只有你这样。事实上，你所遇到的大部分程序员都缺乏创意。原因在于，跟编程中客观的逻辑性思维相比，创意需要一种不同的思维方式。

幸运的是，创新思维是可以学习的。我列出了一个可以激发创意的书籍清单。(注：排名不分先后，有两本书没有相应中文名，应该是没有中文版)


《Pragmatic Thinking and Learning: Refactor Your Wetware》 - Andy Hunt 安迪·亨特

这是一本为程序员量身定制的激发创意的书，作者安迪自己也是一名程序员。（他也是《程序员修炼之道》的作者之一）。

Thinkertoys: A Handbook of Creative-Thinking Techniques - Michael Michalko
《米哈尔科商业创意全攻略》 - 迈克尔·米哈尔科

迈克尔·米哈尔科通过带领你解决一些拼图游戏来迫使你改变思维方式。对于那些缺乏创意的人来说这可能往往是一项艰巨的任务。

Thinkpak: A Brainstorming Card Deck - Michael Michalko迈克尔·米哈尔科

　　这并不是一本真正的书。基于从《米哈尔科商业创意全攻略》中学到的技术，迈克尔·米哈尔科做了一副卡片，你可以用这副卡片来激发自己的创意，并将你的创意运用于实际应用中。

Cracking Creativity: The Secrets of Creative Genius - Michael Michalko
《创意的技术：100位天才的9种思考习惯》- 迈克尔·米哈尔科

迈克尔·米哈尔科的三本书（资料）中的最后一本。在这本书中，迈克尔着重讲了如何像历史上包括莱昂纳多·达·芬奇和华特·迪士尼在内的创意天才一样进行思考。

How to Get Ideas - Jack Foster, Larry Corby
《更多好主意》- 杰克·福斯特 & 拉里·科比

　　拥有原创性的想法是有创意的一个表现，但这些想法从何而来呢？这本书会告诉你如何激发产生新的想法，并让你达到更高的水平。

The Innovator’s Toolkit: 50+ Techniques for Predictable and Sustainable Organic Growth - David Silverstein, Philip Samuel, Neil DeCarlo
《创新者工具箱: 50+可预见与可持续创新技术》- 大卫·西尔弗斯坦，菲利普·塞缪尔，尼尔·戴卡洛

程序注释本来是一些比较好的习惯，当程序员老手带新手的时候，总是会告诉新手，一定要写程序注释。于是，新手们当然会听从老手的吩咐。只不过，他们可能对程序注释有些误解，于是，我们经常在程序中看到一些如下的注释：

r = n/2;  //r是n的一半

//循环，仅当r- n/r不大于t
while ((r-n/r) <=t){
        … …
        r = 0.5 * (r-n/r); // 设置r变量
}

每当看到这样的注释——只注释是什么，而不注释为什么，相信你一定会被惹火，这是谁写的程序注释啊？不找来骂一顿看来是不会解气了。程序注释应该是 告诉别人你的意图和想法，而不是告诉别人程序的语法，这是为了程序的易读性和可维护性，这样的为了注释而注释的注释，分明不是在注释，而是在挑衅，惹毛别 人当然毋庸置疑。

第九位 打断

正当程序沉浸于编程算法的思考，或是灵感突现正在书写程序的时候，但却遭到别人的打断，那是一件非常痛苦的事情，如果被持续打断，那可能会让人一下 子就烦躁起来。打断别人的人在这种情况下是非常不礼貌的。被打断的人就像函数调用一下，当其返回时，需要重新恢复断点时的现场，当然，人不是电脑，恢复现 场通常是一个很痛苦的过程，极端的情况下可能需要从头开始寻找思绪，然后一点一点地回到断点。

因此，我看到一些程序员在需要安静不被打扰的时候，要么会选择去一个没人找得到的地方，要么会在自己的桌子上方高挂一个条幅以示众人——“本人正执 行内核程序，无法中断，请勿骚扰，谢谢！”，可能正在沉浸于工作的程序被打断是多么大的开销。自然，被打断所惹毛了的人也不在少数了。

第八位  需求变化

这个事情估计不用多说了。只要是是程序员，面对需求变化的时候可能总是很无奈的。一次两次可能还要吧接受，但也顶不住经常变啊。据说敏捷开发中有一 套方法论可以让程序员们享受需求的变化，不知道是真是假。不过，今天让你做一个书桌，没有让你把书桌改成餐桌，后天让你把餐桌改成双人床，大后天让你把床 改成小木屋，然后把小木屋再改成高楼大厦。哎，是人都会被惹毛了的。那些人只用30分钟的会议就可以作出任何决定，但后面那几十个程序员需要搭上几百个小 时的辛苦工作。如果是我，可能我也需要神兽草泥马帮助解解气了。

不过，这也正说明了，程序员并不懂得怎么和用户沟通，而用户也不懂得和程序员沟通，如果一个项目没有一个中间人（如：PM）在其中协调的话，那么整 个项目可能就是“鸡同鸭讲”，用户和程序员都会被对方所惹毛了。如果要例举几个用户被惹毛的事情，估计程序员的那种一根筋的只从技术实现上思考问题的方法 应该也能排进前5名。

第七位  经理不懂技术

外行领导内行的事例还少吗？领导一句话，无论对不对，都是对的，我们必需照做，那怕是多么愚蠢多么错误的决定，我们也得照做。程序员其实并不怕经理 不懂技术，最怕的就是不懂技术的经理装着很懂技术。最可气的是，当你据理力争的挑站领导权威的时候，领导还把你视为异类。哎，想起这样的领导别说是骂人 了，打人的冲动都有了。

其实，经理只不过是一个团队的支持者，他应该帮助团队，为团队排忧解难。而不是对团队发号施令。其实管理真的很简单，如果懂的话，就帮着做，如果不懂的话，就相信下属，放手让下属做。最怕的就是又不懂技术，还不信任下属的经理了。哎，这真是程序员的痛啊。

第六位 用户文档

用户文档本来不应该那么的令人害怕。这些文档记录了一切和我们所开发的软件有关的一些话题。因为我们并不知道我们所面对的用户的电脑操作基础是什么 样的，所以，在写下这样的文档的时候，我们必需假设这个用户什么也不懂。于是，需要用最清楚，最漂亮的语言写下一个最丰富的文档。那怕一个拷贝粘贴的操 作，可能我们都要分成五、六步来完成，那怕是一个配置IP地址的操作，我们也要从开始菜单开始一步一步的描述。对于程序员来说，他们在开发过程中几乎天天 都在使用自己开发的软件，到最后，可能都有得有点吐了，但还得从最简单的部份写这些文档，当然容易令他们烦燥，让程序员来完成这样的文档可能效果会非常不 好。所以，对于这样的用户文档，应该由专门的人来完成和维护。

第五位  没有文档

正如上一条所说的，程序员本来就不喜欢写文档，而因为技术人员的表达能力和写作能力一般都不是太好，所以，文档写的也很烂。看看开源社会的文档可能 就知道了。但是，我们可爱的程序员另一方面最生气的却是因为没有文档。当然，让面说是的用户的文档，这里我们说的是开发方面的文档，比如设计文档，功能规 格，维护文档等等。不过，基本上都是一样的。反正，一方面，我们的程序员不喜欢写文档，另一方面，我们的程序又会被抱怨没有文档，文档太少，或者文档看不 懂。呵呵。原来在抱怨方面也有递归啊。据说，敏捷开发可以降低程序开发中的文档，据说他们可以把代码写得跟文档和示图似的，不知道是真是假。不过，我听过 太多太多的程序员抱怨没文档太少，文档太差了，这个方面要怪还是怪程序员自己。

第四位 部署环境

虽然，程序员们开发的是软件，但是我们并不知道我们的程序会被部署或安装在什么样的环境下，比如，网络上的不同，RAID上的不同，BIOS上的不 同，操作系统的不同（WinXP和Win2003），有没有杀毒软件，和其它程序是否兼容，系统中有流氓软件或病毒等等。当然，只要你的软件出现错误，无 论是你的程序的问题，还是环境的问题，反正都是你的问题，你都得全部解决。所以，程序员们并不是简单地在编程，很多时候，还要当好一个不错系统管理员。每 当最后确认问题的原因是环境问题的时候，可能程序员都是会心生怨气。

第三位 问题报告

“我的软件不工作了”，“程序出错了”，每当我们听到这样的问题报告的时候，程序员总是感到很痛苦，因为这样的问题报告等于什么也没有说，但还要程 序员去处理这种错误。没有明确的问题描述，没有说明如果重现问题，在感觉上，当然会显得有点被人质问的感觉，甚至，在某些时候还掺杂着看不起，训斥的语 气，当然，程序员基本上都是很有个性的，都是软硬不吃的主儿，所以，每当有这样的语气报告问题的时候，他们一般也会把话给顶回去，当然，后面自己然发生一 些不愉快的事情。所以，咱们还是需要一个客服部门来帮助我们的程序员和用户做好沟通。

第二位 程序员自己

惹毛程序员的可能还是程序员自己，程序员是“相轻”的，他们基本上都是持才傲物的，总是觉得自己才是最牛的，在程序员间，他们几乎每天都要吵架，而且一吵就吵得脸红脖子粗。在他们之间，他们总是被自己惹毛。

• 技术上的不同见解。比如Linux和Win，VC++和VB，Vi和Emacus，Java和C++，PHP和Ruby等等，等等。什么都要吵。
• 老手对新手的轻视。总是有一些程序员看不起另一些程序员，说话间都带着一种傲慢和训斥。当新手去问问题的时候，老手们总是爱搭不理。
• 在技术上不给对方留面子。不知道为什么，程序员总是不给对方留面子，每当听到有人错误理解某个技术的时候，他们总是喜欢当众大声指证，用别人的“错误”来表明自己的“博学”，并证明他人的“无知”。
• 喜好鄙视。他们喜好鄙视，其实，这个世界上没有一件事是完美的，有好就有不好，要挑毛病太容易了。程序员们特别喜欢鄙视别人，无论是什么的东西，他们总是喜欢看人短而不看人长。经常挂在他们嘴上的口头禅是“太差”、“不行”等等。

程序员，长期和电脑打交道，编写出的代码电脑总是认真的运行，长期养成了程序员们目空一切的性格，却不知，这个世界上很多东西并不是能像电脑一样，只要我们输入正确的指令它就正确地运行这么简单。程序员，什么时候才能变成成熟起来……

第一位 程序员的代码

无论你当时觉得自己的设计和写的代码如何的漂亮和经典，过上一段时间后，再回头看看，你必然会觉得自己的愚蠢。当然，当你需要去维护他人的代码的时 候，你一定要在一边维护中一边臭骂别人的代码。是否你还记得当初怎么怎么牛气地和别人讨论自己的设计和自己的代码如何如何完美的？可是，用不了两年，一刚 从学校毕业的学生在维护你的代码的过程当中就可以对你的代码指指点点，你的颜面完全扫地。呵呵。当然，也有的人始终觉得自己的设计和代码就是最好的，不过 这是用一种比较静止的眼光来看问题。编程这个世界变化总是很快的的，很多事情，只有当我们做过，我们才熟悉他，熟悉了后才知道什么是更好的方法，这是循序 渐进的。所以，当你对事情越来越熟悉的时候，再回头看自己以前做的设计和代码的时候，必然会觉得自己的肤浅和愚蠢，当然看别人的设计和代码时，可能也会开 始骂人了。

下面是“Neo”和“陈皓”的翻译，我们的翻译水平有限，所以，我们提供了中英文对照，有不当之处，还请各位指正。

A good programmer is someone who looks both ways before crossing a one-way street. — Doug Linder, systems administrator

好的程序员这样一类人，这类人在横穿一条单行道前都要先看一下路两边。– Doug Linder, 系统管理员

A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits. — Edsger Dijkstra, computer scientist

关于工具，一个最重要的，也是最不易察觉的方面是，工具对使用此工具的人的习惯的潜移默化的影响。如果这个工具是一门程序语言，不管我们是否喜欢 它，它都会影响我们的思维惯式。 –Edsger Dijkstra, 计算机科学家，著名的“程序=数据结构+算法”的提出者。

Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra

抽象和模糊完全地不同，抽象的目的并不是把事情变模糊，而去创建一个新的语义层，在那里是绝对精确的描述。 — Edsger Dijkstra

Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. — Edsger Dijkstra

除了数学爱好，对于一个有能力的程序员来说，出色地掌握自己的母语是最宝贵的财富。– Edsger Dijkstra

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg. — Bjarne Stroustrup, developer of the C++ programming language

C很容易使你搬起石头砸自己的脚，而C++把这事变得更难，但是如果一定要这么做，那么你的整条腿都会被炸飞 -Bjarne Stroustrup, C++语言的发明者

Commentary: most debugging problems are fixed easily; identifying the location of the problem is hard. — unknown

修复bug很容易，但是定位bug却很困难 – 匿名

Considering the current sad state of our computer programs, software development is clearly still a black art, and cannot yet be called an engineering discipline. — Bill Clinton, former President of the United States

看看当前计算机程序糟糕的事态，软件开发明显一直是一门妖术，其仍然不能被称为一个工程学。 –比尔.克林顿 美国前总统

For a long time it puzzled me how something so expensive, so leading edge, could be so useless, and then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. — Bill Bryson, author, from Notes from a Big Country

长期以来，有个事一直困扰着我，那就是越是昂贵的，越是前沿的，就越可能是没用的。然后，困扰我的另一个事是，计算机是一个死的机器，却可以不可思 议地去完成那些巧妙的事情，而计算机程序员是那么聪明人却在做着不可思议的愚蠢的事情，简而言之，他们真是天生的一对。– Bill Bryson旅游文学作家 Big Country中的笔记

Given enough eyeballs, all bugs are shallow (e.g., given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone). — Eric S. Raymond, programmer and advocate of open source software, from The Cathedral and the Bazaar

足够多的眼睛，就可让所有问题浮现(比如：只要给于足够多的beta测试者和开发人员一起工作，那么，几所所有的问题都会很快的出现，而修正也会是显而易见的）

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer. — Steve McConnell, software engineer and author, from Code Complete

好的代码自己本身就是最好的文档。当你打算加注释的时候，问问自己‘我如何才能把我的代码改善到不需增加注释？’重构自己的代码，然后使文档让其更清楚。 — Steve McConnell《代码大全》的作者

Hey! It compiles! Ship it! — unknown

嘿，编译通过了！出货！–匿名

Inside every well-written large program is a well-written small program. — Charles Antony Richard Hoare, computer scientist

在每个编写精良的大程序里面都是一个编写精良的小程序。 –Charles Antony Richard Hoare,计算机科学家

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. — Nathaniel S. Borenstein, computer scientist

需要注意的是，没有哪个经过规范培训的工程师会赞成写一个DestoryBaghdad（摧毁巴克达）的函数。最基本的职业规范会告诉他们应该去写 一个叫DestoryCity的函数，然后把“Baghdad”（巴克达）当成这个函数的参数。——　Nathaniel S. Borenstein,　计算机科学家

Managing programmers is like herding cats. — unknown

管理程序员就如同养一群猫一样 –匿名

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. — Bill Gates, co-founder of Microsoft Corporation

用代码行数来衡量编程的进度，就如同用航空器零件的重量来衡量航空飞机的制造进度一样。——Bill Gates，微软创始人

More good code has been written in languages denounced as bad than in languages proclaimed wonderful — much more. — Bjarne Stroustrup, from The Design and Evolution of C++

好的代码都都在的批评声中写成的，而差的则是在表杨声中写成的。——Bjarne Stroustrup, 摘自《The Design and Evolution of C++》

Programs must be written for people to read, and only incidentally for machines to execute. — Harold Abelson and Gerald Jay Sussman, computer scientists and authors, from The Structure and Interpretation of Computer Programs

代码应该是写给其他人来读的，而能让机器运行的仅仅是附带着的。——　Harold Abelson 与 Gerald Jay Sussman, 计算机科学家和作家，摘自《The Structure and Interpretation of Computer Programs》

Real programmers don’t comment their code. If it was hard to write, it should be hard to understand. — unknown

真正程序员从来不写代码的注释，如果代码非常难写，那么同样代码的注释也会非常难懂 –匿名

Simplicity is prerequisite for reliability. — Edsger Dijkstra

简单是可靠的前提条件 — 迪杰斯特拉

The C programming language — a language which combines the flexibility of assembly language with the power of assembly language. — unknown

C语言—— 一门同时具有了汇编语言灵活性和汇编语言强大能力的语言。– 匿名

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. — Tom Cargill, object-oriented programming expert at Bell Labs

开始的90%的代码用了90%的开发时间，而剩下的最后的10%的代码会需要另外90%的开发时间。– Tom Cargill,面向对象编程专家,贝尔实验室

The important point is that the cost of adding a feature isn’t just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web. The trick is to pick the features that don’t fight each other. — John Carmack, computer game programmer

增加一个功能特性的成本并不单单是为这些功能编码所花费时间的成本，还这个成本应该包括特性扩展的障碍成本。当然，任何的功能清单都可以被实现，只 需要有足够的时间。但是除些之外，你应该对你的代码库的脆弱性感到紧张，而那些新的想法应该足够的简单，而不是去花费更多更多的时间去纠缠于现有的蜘蛛 网。这里的决窃是挑选那些不会和别人冲突的的功能。

The key to performance is elegance, not battalions of special cases. The terrible temptation to tweak should be resisted unless the payoff is really noticeable. — Jon Bently and M. Douglas McIlroy, both computer scientists at Bell Labs

表现的关键是精美和典雅的，并不是使用大量的特殊案例。对于任何调整的冲动都应该是被限制的，除非其回报真的是值得注意的。– Jon Bently and M. Douglas McIlroy, 二者都是贝尔试验实的计算机科学家

The last good thing written in C was Franz Schubert’s Symphony Number 9. — Erwin Dieterich, programmer
最后一件用C做的好作品就是弗朗茨.舒伯特的C大调第9交响曲 — Erwin Dieterich, programmer程序员

The problem with using C++ … is that there’s already a strong tendency in the language to require you to know everything before you can do anything. — Larry Wall, developer of the Perl language

使用C++最大的问题是..在C++语言里，存在这一种很强的趋势，就是如果你不明白C++语言的细节，你就无法做好任何事情。– Larry Wall, developer of the Perl language

The sooner you start to code, the longer the program will take. — Roy Carlson, University of Wisconsin

你越早开始都手编码，你所花费来编程的时间就越长 — Roy Carlson, University of Wisconsin

The value of a prototype is in the education it gives you, not in the code itself. — Alan Cooper, software author, from The Inmates are Running the Asylum

原型的价值在于他给你的教训，而不是代码自身 — Alan Cooper, software author, from The Inmates are Running the Asylum

There are only two kinds of programming languages: those people always bitch about and those nobody uses. — Bjarne Stroustrup

世界上只有两类编程语言：人们都抱怨的语言和从来没有人使用的语言 — Bjarne Stroustrup

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. — Charles Antony Richard Hoare

世界上有两个设计软件的方法，一种方法是设计的尽量简单，以至于明显的没有什么缺陷，另外一种方式是使他尽量的复杂，以至于其缺陷不那么明显。

Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code. — Eric S. Raymond

丑陋的程序就像一座丑陋的吊桥：他们相比漂亮的良好的吊桥起来，更有可能会坍塌，这是因为人类（尤其是工程师）感知漂亮的东西是和我们处理和理解复杂问题的能力相关的。所以，一个程序语言如果很难以优雅地方式编程，那么其就很难写出好的代码。

Weeks of programming can save you hours of planning. — unknown

多做几周的编程可以节省你做计划的时间 —— 匿名 （意思为，只有实践过了，你才更容易做计划，没有实践过，做起计划来将会很头痛）

When a programming language is created that allows programmers to program in simple English, it will be discovered that programmers cannot speak English. — unknown

当程序语言被设计成允许程序以很简单的英语来编程的时候，人们将会发现编写程序的程序员都来自不会说英语的地方。 –匿名

过早的优化是万恶之源。Premature optimization is the root of all evil!
- Donald Knuth

在水里行走和以一个需求规格进行软件开发，有一点是相同的，那就是如果水或需求都被冻住不 了，那么行走和软件开发都会变得容易。Walking on water and developing software from a specification are easy if both are frozen
- Edward V Berard

Hofstadter 定理：“一件事情总是会花费比你预期更多的时间，就算是你已经考虑过本条Hofstadter 定理”。It always takes longer than you expect, even when you take into account Hofstadter’s Law.
- Hofstadter’s Law

有些遇到问题的人总是会说“我知道，我会使用正则表达式”，那么，你现在有两个问题了。（意思是：你本想用正则表达式来解决你已有问题，但实际上你 又引入了“正则表达式”的一个新问题）Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems
- Jamie Zawinski

调试程序的难度是写代码的两倍。因此，只要你的代码写的尽可能的清楚，那么你在调试代码时就不需要那么地有技巧。Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
- Brian Kernighan

用代码行来衡量开发进度，无异于用重量来衡量制造飞机的进度。Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
- Bill Gates

PHP被一些不合格的业余人员造就成了一个小恶魔；而Perl则是被一些熟练的但不正当的专业人员造就成了一个超级大恶魔。PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals.
- Jon Ribbens

在两个场合我被问到：“请你告诉我，如果你给机器输入了错误的数字，那么，是否还能得到正确的答案？”我并不能正确领会这类想法。（注意，本引言的 作者姓Babbage，这个名字和神父同名，意思是，作者在反问提问的人，你是问我还是向神父祈祷？）On two occasions I have been asked, ‘Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?’ I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”
- Charles Babbage

在编程的时候，我们一定要想像一下，以后维护我们自己的代码的那个人会成为一个有暴力倾向的疯子，并且，他还知道我们住在哪里？Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
- Rick Osborne

现代的编程是“程序员努力建一个更大更傻的程序”和“世界正在尝试创造更多更傻的人”之间的一种竞赛，目前为止，后者是赢家。 Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
- Rich Cook

我才不关于我的代码是否能在你的机器上工作！我们不会给你提供机器。I don’t care if it works on your machine! We are not shipping your machine!
- Ovidiu Platon

我总是希望我的电脑能够像电话一样容易使用；我的这个希望正在变成现实，因为我现在已经不知道怎么去使用我的电话了。I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.
- Bjarne Stroustrup

计算机是一种在人类历史上所有发明中，可以让你比以前更快地犯更多的错误的发明，同样，其也包括了“手枪”和“龙舌兰酒”这两种发明的缺陷。A computer lets you make more mistakes faster than any other invention in human history, with the possible exceptions of handguns and tequila.
- Mitch Ratcliffe

如果调试程序是一种标准的可以铲除BUG的流程，那么，编程就是把他们放进来的流程。If debugging is the process of removing software bugs, then programming must be the process of putting them in.
- E. W. Dijkstra

教一群被BASIC先入为主的学生，什么是好的编程风格简直是一件不可能的事。对于一些有潜力的程序员，他们所受到的智力上的伤害远远超过了重建他 们的信心。It is practically impossible to teach good programming style to students that have had prior exposure to BASIC. As potential programmers, they are mentally mutilated beyond hope of regeneration.
- E. W. Dijkstra

理论上来说，理论和实际是一样的。但实际上来说，他们则不是。In theory, theory and practice are the same. In practice, they’re not.
- Unknown

只有两个事情是无穷尽的：宇宙和人类的愚蠢。当然，我现在还不能确定宇宙是无穷尽的。Two things are infinite: the universe and human stupidity; and I’m not sure about the universe.
- Albert Einstein

Perl这种语言就好像是被RSA加密算法加密过的一样。Perl – The only language that looks the same before and after RSA encryption.
- Keith Bostic

我爱“最终期限”，我喜欢“嗖嗖嗖”的声音就像他们在飞一样。I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams

说Java好的是因为它跨平台就像好像说肛交好是因为其可以适用于一切性别。Saying that Java is good because it works on all platforms is like saying anal sex is good because it works on all genders
- Unknown

XML就像是一种强暴——如果它不能解决你的问题，那只能说明你没有用好它。XML is like violence – if it doesn’t solve your problems, you are not using enough of it.
- Unknown

爱因期坦说，自然界中的一切一定会有一个简单的解释，因为上帝并不是反复无常和独裁的。当然，不会有什么信仰能程序员像爱因期坦那样感到舒服。 Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
- Fred Brooks

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” – Tom Cargill 
 “最开始的90%的代码使用了程序员90%的时间，剩下的10%的代码也需要90%的开发时间”——Tom Cargill（这不就是中国谚语——“行百步半九十”）

“In order to understand recursion, one must first understand recursion.” – Author Unknown 
 “要知道什么是‘递归’，你首先需要知道‘递归’”——无名氏

“I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.” – Bjarne Stroustrup 
“我总是希望电脑能和电话一样好用，现在我的这个愿望成真了，因为我已经不知道怎么使用我的电话了”– Bjarne Stroustrup

 “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” -C.A.R. Hoare
“我们有两个方法来进行软件设计：一个是让其足够的简单以至于让BUG无法藏身；另一个就是让其足够的复杂，让人找不到BUG。前者更难一些” — C.A.R. Hoare

  “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.” – Gerald Weinberg
“如果建筑工人盖房子就像程序员写程序一样，那么只需要一只啄木鸟就可以摧毁人类文明”– Gerald Weinberg

“Nine people can’t make a baby in a month.” – Fred Brooks 
“九个人不能只用一个月就能生出孩子来”– Fred Brooks （这是对人月计算法的一个讽刺）

“Before software can be reusable it first has to be usable.” – Ralph Johnson
“在软件可被重用前，它必需要可以被用”– Ralph Johnson

程序员之歌
99 little bugs in the code,
99 bugs in the code,
fix one bug, compile it again,
101 little bugs in the code.
101 little bugs in the code….
(Repeat until BUGS = 0)

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. –Martin Fowler
任何一个傻子都能写出让电脑能懂的代码，而只有好的程序员可以写出让人能看懂的代码 — Martin Fowler

Wirth’s law: Software gets slower faster than hardware gets faster. –Niklaus Wirth
Wirth定律，软件把性能变慢的速度要快于硬件把性期变快的速度。– Niklaus Wirth

 Better train people and risk they leave – than do nothing and risk they stay.
–Anonymous
就算是培训的员工会离开，这也好过他们什么也不做却不会离开。——无名氏

Good judgment comes from experience, and experience comes from bad judgment. –Frederick P. Brooks
“好的判断来自于经验，而经验则来自于坏的判断”

UNIX is simple. It just takes a genius to understand its simplicity –Dennis Ritchie
UNIX 简单的，但只有天才才能知道他的简单 — Dennis Rithie

Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. 　–Doug Gwyn
Unix 并不是设计成——阻止人们做那些愚蠢的事，因为那同样会阻止人们做聪明的事。——Doug Gwyn

如果你想看更多这样的引言，你可以浏览下面这个网页：
http://www.comp.nus.edu.sg/~damithch/pages/SE-quotes.htm

1） The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式，框架，那些著名的方法、模式、框架只代码赞同他们的人多，并不代表他们适合你， 你应该更多的去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“best practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2）Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的娱乐方式去生活，无论是编程，还是运动，还是去旅游，那么你只不过是在应付你的工作， 无时无刻不扎在程序堆中，这样下来，就算是你是一个非常聪明，非常有才华的人，你也不会成为一个优秀的编程员，要么只会平平凡凡，要么只会整天扎在技术中 成为书呆子。当然，这个观点是有争议，热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3）Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。

4）XML is highly overrated

XML可能被高估了。XML对于Web上的应用是不错的，但是我们把其用到了各种地方，好像没有XML，我们都不会编程了。

5）Not all programmers are created equal

这是那些junior经理或是流程爱犯的错，他们总是认为，DeveloperA == DeveloperB，只要他们的title一样，他们以为他们的能力、工作速度、解决问题的方法，掌握的技能等等都是一样的。呵呵。更扯的是，在某些时 候，就算是最差的程序员，他们也会认为其比别人强十倍，这就是现代的SB管理。

6）”Googling it” is okay!

Google只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度的使用Google，只会让你越来越离不开他，你越来越去要去立马 告诉你答案，而你越来越不会自己去思考，自己去探索，去专研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们 的智力发展大大的没有好处。

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言， 了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是 Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.

你的工作不是保守，那种教会徒弟，饿死师父的想法，不但是相当短浅的，而且还是相当脑残的。因为，在计算机世界里，你掌握的老技术越多，你就越没 用，因为技术更新的太快。你对工作越保守，这个工作就越来越离不开你，你就越不越不能抽身去学新的东西，你也就越来越OUT了。记住：If you can’t be replaced then you can’t be promoted!

9）Design patterns are hurting good design more than they’re helping it.

很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱动编程”，正如第一点所说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

10）Unit Testing won’t help you write good code

准确地说，我们可以认为这是Test-Driven开发，其实，这种开发就是先写unit test case，这样的开发方式的主要目的是，为了防止你不会因为一个改动而引入Bug，但这并不会让你能写出更好的代码。这只会让你写出不会出错的代码。同第 一点，这样的方法，只不过是防止糟糕的程序员，而并不是让程序员或代码质量更有长进。反而，通过Unit Test会为程序员的为自己代码做辩解的一种托辞。

最后，顺便说一下，以前去那个敏捷的公司面试，发现那个公司的某些技术人员中毒不浅，具体表现在上述的1）9）10）观点上。

 只要拂去阴霾，就能亮出朗朗晴空。如 果你在工作上有些不如意，要相信自己不会一直处于人生的低谷期，总有一天能冲破重重云层。告诉自己：我并没有失败，只是暂时没有成功！只要在内心点亮一盏 希望之灯，一定能驱散黑暗中的阴霾，迎来光明。
       的确，论资历，他们是不折不扣的职场菜鸟，业务涉及不深，人脉一穷二白，在工作中经常碰壁。他们的压力并不一定都像千钧大石，而是像大雨来临 前的天色，灰色低沉，明明有空间，却被灰色填满每个缝隙，只能等待大雨倾盆之后的晴空。
"起得比鸡早，睡得比狗晚，干得比驴多，吃得比猪差。"这是很多刚刚毕业的人喜欢用来调侃自己生活状态的话。虽然有点儿夸张，但是，他们中的很多人的 确一直都被灰色心情所笼罩--心里永远是多云转阴。记得有位哲人曾说："我们的痛苦不是问题本身带来的，而是我们对这些问题的看法产生的。"换个角度看人 生，是一种突破、一种解脱、一种超越、一种高层次的淡泊与宁静，从而获得自由自在的快乐。
       一位哲人说："人生就是一连串的抉择，每个人的前途与命运，完全把握在自己手中，只要努力，终会有成。"就业也好，择业也罢，创业亦如此，只要奋发努力， 都会成功。你是不是准备把生命的承诺全部都交给别人？
毕业后这5年，是改变自己命运的黄金时期。在最能决定自己命运时，如果还不把握，那你还要等到什么时候呢？我的人生我做主，命运由己不由人。
不要活在别人的嘴里，不要活在别人的眼里，而是把命运握在自己手里。
别说你没有背景，自己就是最大的背景。美国作家杰克·凯鲁亚克说过一句话："我还年轻，我渴望上路。"在人生的旅途中，我们永远都是年轻人，每天都应 该满怀渴望。每个人的潜能都是无限的，关键是要发现自己的潜能和正确认识自己的才能，并找到一个能充分发挥潜能的舞台，而不能只为舞台的不合适感到不快。 要客观公正地看待自己的能力，结合自己的实际情况和爱好冷静选择，尽可能到最需要自己、最适合自己的地方。
    在人力资源管理界，特别流行一个说法，即"骑马，牵牛，赶猪，打狗"理论：人品很好，能力又很强的，是千里马，我们要骑着他；人品很好但能力普通的，是老 黄牛，我们要牵着他；人品、能力皆普通的，就是"猪"，我们要赶走他；人品很差能力很强的，那是"狗"，我们要打击他。
       我想，刚刚毕业几年的你，一样胸怀大志，一样想成为一匹被人赏识、驰骋沙场的千里马吧？那么，就好好沉淀下来。低就一层不等于低人一等，今日的俯低是为了 明天的高就。所谓生命的价值，就是我们的存在对别人有价值。能被人利用是一件好事，无人问津才是真正的悲哀！
       能干工作、干好工作是职场生存的基本保障。
       任何人做工作的前提条件都是他的能力能够胜任这项工作。能干是合格员工最基本的标准，肯干则是一种态度。一个职位有很多人都能胜任，都有干好这份工作的基 本能力，然而，能否把工作做得更好一些，就要看是否具有踏实肯干、苦于钻研的工作态度了。
       在能干的基础上踏实肯干。
       工作中，活干得比别人多，你觉得吃亏；钱拿得比别人少，你觉得吃亏；经常加班加点，你觉得吃亏……其实，没必要这样计较，吃亏不是灾难，不是 失败，吃亏也是一种生活哲学。现在吃点儿小亏，为成功铺就道路，也许在未来的某个时刻，你的大福突然就来了。
       能吃亏是做人的一种境界，是处世的一种睿智。
       在工作中并不是多做事或多帮别人干点儿活就是吃亏。如果领导让你加加班、赶赶任务，别以为自己吃了大亏，反而应该感到庆幸，因为领导只叫了你，而没叫其他 人，说明他信任你、赏识你。吃亏是一种贡献，你贡献得越多，得到的回报也就越多。乐于加班，就是这样的一种吃亏。
       舍得舍得，有舍才有得；学会在适当时吃些亏的人绝对不是弱智，而是大智。
给别人留余地就是给自己留余地，予人方便就是予己方便，善待别人就是善待自己。
傻人有傻福，因为傻人没有心计。和这样的人在一起，身心放松，没有太多警惕，就能相互靠近。傻在很多时候意味着执着和忠贞，也意味着宽厚和诚实，让人 不知不觉站到他一边。傻人无意中得到的，比聪明人费尽心机得到的还多。毕业这几年，你的天空中只飘着几片雪花，这样你就满足了吗？成功需要坚持与积累，与 其专注于搜集雪花，不如省下力气去滚雪球。巴菲特说："人生就像滚雪球，最重要的是发现很湿的雪和很长的坡。"让自己沉淀下来，学着发现"很湿的雪"，努 力寻找"很长的坡"。记住：散落的雪花会很快融化，化为乌有，只有雪球才更实在，才能长久。
在毕业这几年里，你要是能做到比别人多付出一分努力，就意味着比别人多积累一分资本，就比别人多一次成功的机会。
       什么是职业化呢？职业化就是工作状态的标准化、规范化、制度化，即在合适的时间、合适的地点用合适的方式说合适的话、做合适的事，使知识、技能、观念、思 维、态度、心理等符合职业规范和标准。"在每个行业里，都有很多出色的人才，他们之所以能存在，是因为比别人更努力、更智慧、更成熟。但是，最重要的是， 他们比一般人更加职业化！这就是为什么我现在能当你老板的原因。一个人仅仅专业化是不够的，只有职业化的人才能飞在别人前面，让人难以超越！"不要以为我 们现在已经生存得很安稳了。对于毕业5年的人来讲，一定要认清即将面临的五大挑战。 

1.强烈建议联系手机通话服务提供商取消长途电话服务
如果直接拨打国际长途的话，在美国可能高至4美元/分钟，为了防止因使用电话卡失误造成高额话费，建议大家都联系服务商关闭国际长途服务。这也是我在多数 买电话卡的网上看到的建议。

2.本地接入号与toll-free的区别
（1）大多数在美加办过手机或者即将办手机的童鞋相信都听说过family plan，family plan是几个人一起分享一定分钟数的协议。family plan在9:00pm–6:00am之间、周末打美国国内电话是免费的。
（2）本地接入号是电话卡服务商提供的一种利用这种family plan免费时段的服务。在免费时段内可以拨打本地接入号接入服务，通常会便宜一些。但是如果不是在免费时段内拨打本地接入号的话会占family plan的时间的，family plan的时间用完后即使是打美国国内电话也很贵的噢。而打toll-free号码在任何时段都不会占用family plan的时间的。此外，toll-free号码可以在公用电话上拨打。
（3）有些prepaid plan如果不确定自己是否有免费时段，可以拨打toll-free号码拨打，这样选择卡的时候就要首先选择toll-free便宜的卡。
（4）有些手机服务商（AT&T, T-Mobile, Verizon等）提供亲情号服务（亲情号之间打电话不要钱），可以将本地接入号设为亲情号，这样就可以随时给国内打电话了。

3.选择卡需要注意的事项
（1）有免费时段的童鞋注意选择有本地接入号的卡，不是所有电话卡都有覆盖美国或加拿大全境的本地接入号。万一买了没有本地接入号的卡，你就只能使用稍微 贵点的toll-free的号码拨打了。
（2）接入费：某些卡打电话很便宜，只要0.6cents，但是却需要维护费和接通费。这种卡比较适合电话很多的童鞋使用，反正很快用完，也交不了多少维 护费和接通费。
（3）卡的有效期：对那些只给父母报平安的童鞋来说，打电话其实不多，这样选个有效时间长的卡比较好。

4.购卡安全与推荐
现在在网上买卡多数都比较安全，在国外用信用卡在网上购买是很安全的，网上消费也一般有一个月的安全期，也就是说一个月内你发现自己的卡消费有问题，都可 以取消交易。 （debit card也可以在网上如同credit card消费，只是debit card没有信用额度，只能自己存多少就花多少，当然一般有credit card后都愿意用credit card购买，这样可以逐渐提高信用记录）。

下面列出了很多电话卡，从美国打到中国，现在选择Pingo很划算，现在注册Pingo，每买10$的话费送5$。Pingo原本从美国打往中国只要1.2美分，toll-free也仅需2.2美分，算上优 惠的话Pingo从美工打往中国仅需0.80美分，toll-free也才1.46美分。而且Pingo也不需要接入费的。wednesday（星期三 ）拨打更实惠，只需要半价。

中国打往美国

美国打往中国

1、电话预约

预约赴美签证时间，电话是4008－872－333及86-21-3881-4611

话务中心的工作时间是：

周一至周五：早7：00 — 晚7：00

周六：早8：00 — 晚5：00

1)、缴预约电话费

预约的通话过程是需要钱的，标准是54元/12分钟或者36元/8分钟。可以通过如下两种方式购买通话时间

• 去中信银行购买加密电话卡，所有网点都有卖
• 银行卡缴费，在电话里会提示，也可以采用网上购买的密码

2)、打电话前需要准备

个人信息，中文姓名、姓名拼音、生日、身份证号码、护照号码、联系电话、签证类型、传真和电子邮件

纸和笔，用于记录缴费密码和预约号码

3)、拨打电话

1、拨通后，先是中英文轮流播放“欢迎拨打美国驻华大使馆及总领馆签证信息服务中心 ……”中英文各播一遍以后，中英文提示你：”下面选择语言种类。”。然后用相对应的各种语言。播报：英语请按1，普通话请按2，广东话请按3，福州话请按4，佛山话请按5。

2、然后“寻求美国公民服务请按1,进行下一步选择请稍等” 。不按键，等5秒钟。（如 果选择1的话，会讲大约好几分钟使馆和领事馆提供给美国公民的服务）

3、接下来“查询有关美国移民的信息请按1,查询有关赴美旅行的信息请按2” ——按2。

4、按2以后，系统会提示“这项服务是用户付款服务，费用是12分钟收取人民币54元” ，有五个选项：“如果你已通过汇票支付了费用，现在希望服务生效请按1，如果你购买了中信实业银行的密码预付卡请按2，如果你已在网上购买了密码请按3， 如果你已经使用了此项服务，现在想用完剩余的分钟请按4，欲知付款的方法请按5” .如果按5，那么系统会提示三个选项：用信用卡支付按1，得到密码以后，就是支付成功了！这个密码一定要记住（可以听不止一次），预约、咨询都要用到，你 可以打多次电话，只要合计不超过12分钟。

5、接下来就是就是输入密码进入排队系统了，“想听录音资料请按1,将资料传真给您请按2, 联络客服代表请按0”，如果你想直接预约签证，就按0接通客服代表。你按了0以后，就会进入排队系统，等候空闲的客服代表。计费是从接通客服代表开始的。 经过多次验证，如果这个时候你没有耐心将电话挂掉，你的时间是会扣掉一分钟的。(我预约的时候等待了12分钟)

6、接通电话后，服务小姐会问你中文姓名、姓名拼音、签证地点、以前是否被拒过、哪一类签证、护照号码、身份证号码、联系方式、生日。预约时，会告 诉你签证的时间，几月几号几点，最后还会给你给你个“预约编号”，这个编号是12位，后面还有一个校验位，编号和校验位之间有一个横杠。要记住这个编号 （当然了，实际面谈的时候这个号也没有什么用）。

7、如果已经预约了，但是临时有事不能去签证，提前3天打电话取消预约。不打招呼、当天就不去也是可行的。但是为了稳妥起见，还是打电话取消预约吧。

2、缴纳签证申请费

在领事馆面谈前，需要去指定的中信银行缴费943人民币的签证申请费，缴费的时候需要携带申请人护照。

点击这里查看中信银行代收美国签证费的网点。俺选择淮海中路支行(在上图那儿)

3、填写签证申请表–DS-156申请表

需用英文填写电子版的DS-156表，该电子版申请表的网址是：https://evisaforms.state.gov/ds156.asp

在填完表后，需要按照提示打印申请表，在完成的申请表上会出现条形码。表格分成3页，必须正反面打印，还需要在申请表的第6、7、8、9、15、20、21栏用中文手写相应内容。

填写以后，点击最后的提交，记住只能提交一次。然后系统会生成一个PDF文档，同时在文档里出现条形码。如果你在填写的时候发生问题，可以重新填写并提交，系统生成新的条形码后，在签证的时候携带新的156即可。

4、填写补充申请表–DS-157

申请表的地址是：http://www.state.gov/documents/organization/79964.pdf

这张只要打印出来手写即可。

5、拍摄签证照片

6、准备护照

7、准备其他申请材料

其他申请材料主要是用来证明没有移民倾向的。所以需要提供户口簿、工作证明、工资单、财产证明、房产证、照片等来说明申请人和中国有着不可分离的约束力

8、在约定的日子，前往领事馆签证

需要携带如下材料

• 有效护照，指护照有效期比申请预期赴美停留日期多6个月以上
• 填写完整的DS-156表(必须有条形码，正反面打印，且贴好照片)
• 填写完整的DS-157表
• 中信银行的签证费收据，需要带上所有联的收据
• 邀请函
• 行程表
• 学员通讯录和项目介绍
• 第七点提及的其他申请材料

有关面谈时的注意事项，是请尽量如实回答

9、获得赴美签证

上海地区的签证获得，是通过邮局寄回护照的。不再是当场发放了。

PS：今天只是做了签证预约和填写DS156表，更多的信息等具体每个步骤进行了会做更多的更新。

1. Pragmatic Programmer - An attitude, a style, a philosophy of approaching problems and their solutions. They think beyond the immediate problem, always trying to place it in its larger context, always trying to be aware of the bigger picture.
   
2. Take responsibility for everything they do. Don't sit idly by and watch their projects fall apart through neglect.
   One of the cornerstones of the pragmatic philosophy is the idea of taking responsibility for yourself and your actions. Don't be afraid to admit ignorance or error. Be honest about our shortcomings-our ignorance as well as our mistakes. Don't blame someone else or make up an excuse. Have a contingency plan. Provide Options, Don't Make Lame Excuses.
   
3. Learning is a continuous and ongoing process.
4. Don't Live with Broken Windows。
   Don't leave bad designs,wrong decisions, or poor code unrepaired. It's easy to slip into the mindset of "All the rest of this code is crap, I'll just follow suit." But if you find yourself on a team and a project where the code is pristinely beautiful-clean written, well designed, and elegant, you will likely take extra special care not to mess it up. Everyone dont't want to be the first one to make a mess.
   

Writing a technical document is hard. Reading a poorly written technical document is harder, and probably more painful than writing one. It takes a lot of work to create a clear, accurate, engaging piece of technical writing. Thus, in order to make life a little easier for all parties involved, I am going to share with you the 7 Rules that I follow when creating a piece of technical documentation. I did not think these rules up on my own. Rather, I formulated them from having had the benefit of working with many gifted technical and copy editors for more than a decade. Anything that I understand is because others have shown me the way. I cannot be more grateful.

Hopefully after reading this article, you will have some new tools in your technical writing toolbox that will help you create technical documents that are clearer, more engaging, less confusing and a lot more fun to read. Also, I've added at no extra charge to you, the consumer, a bonus section at the end that describes the process I use to create a piece of technical writing.

Okay, so here are the 7 Rules:

1. Dry sucks
2. Before you start, be clear about what you want your reader to do after you end
3. Write to a well formed outline, always
4. Avoid ambiguous pronouns
5. clarity = illustrations + words
6. When dealing with concepts... logical illustration and example
7. Embrace revision

1. Dry sucks

This is probably the hardest rule to formalize and the most important rule to follow. In the modern world of the Internet there are many forces at work vying for the attention of your reader. Boring, business as usual writing will not work. For better or worse, your reader wants to be entertained as well as informed. Therefore, if you create writing that is unclear and not fun, the reader will simply click the proverbial "next"; button and move on to another web page, another TV show or his or her Facebook page.

The easiest way that I've found to keep the reader entertained is to keep myself entertained. I make a significant effort always to write an article that I will want to read. I strive to have fun when I am writing. If I'm bored, the reader will be bored. If I'm confused, the reader will be confused. If I don't really care about the topic at hand, the reader will never care. It's that simple.

I like humor, so I try to make my writing humorous without compromising clarity. I try to talk to the reader, not at the reader. I write about topics that really matter to me. I use illustrations extensively in order to avoid confusing the reader.

Again, I try always to make the reading experience fun. I am aware always that I am writing in a competitive environment. There's a lot of content out there that wants a piece of the reader's attention. Thus, my advice for Rule #1 is, if you make your writing fun for you, it will be fun for the reader.

2. Before you start, be clear about what you want your reader to do after you end

Technical writing is all about the subsequent behavior of the reader. The reader is investing time reading your work because he or she wants to be able to do something after the reading experience is over. That something may be learning how to make chocolate chip cookies, power down a nuclear reactor or set up a Hadoop cluster. The important thing to remember is that the reader is using your writing as a means to another end. Your piece is a vehicle to another well defined behavior.

Thus, it will do you well to be very clear about what you want your reader to do after the reading experience is over. State your intention at the beginning. Don't leave the reader guessing. Your declaration can be something as simple and obvious as, "after reading this article you will be able to [fill in the blank here]." If you are clear about what you want your reader to do after you end, the easier it will be for you to write your piece at the beginning.

3. Write to a well formed outline, always

A well formed outline is the skeleton around which your document grows. Writing a technical document without using an outline is like trying to navigate the New York City Subway System without a map. You can end up anywhere and that anywhere may not be where you intended to go.

Writing to an outline is not about creating more work. It's about doing less work. When you write to an outline, you know where you've come from and where you are going to.

There are two rules of outlining that I always use.

1. A sublevel topic requires at least one peer.
2. Any outline level requires at least two sentences.

Allow me to elaborate. Listing 1 below is an example of an outline that violates the first rule: A sublevel topic requires at least one peer.

Listing 1: A poorly formed outline

1. Making an Orange Cranberry Tangerine Fizzle

1.1. The steps required for the Fizzle

1.1.1. Preparing the ingredients

1.1.2. Mixing the Fizzle

1.1.3. Serving the Fizzle

Notice please that in Listing 1, Level 1, has a single sublevel, 1.1 - The steps required for the Fizzle. This structure is a violation of the first rule. In order for a sublevel to be well formed, there must be at least one other peer for a topic. In other words, this means that there must be at least two sublevels for any given level.

Please look at Listing 2 below. Notice that there are now three sublevels to Level 1, of which the topic, Mixing the fizzle, now has peers. The single level, The steps required for the Fizzle, has been eliminated.

You may ask, "Where is the topic, The steps required for the fizzle?" The answer is that the topic is no longer an outline item but content within the parent topic as shown in Listing 2 below.

Listing 2: A well formed outline that violates the two sentence rule

1. Making an Orange Cranberry Tangerine Fizzle

The section below describes the process that you need follow to make an orange cranberry tangerine fizzle.

1.1. Preparing the ingredients

1.2. Mixing the Fizzle

1.3. Serving the fizzle

Please notice that although Listing 2 presents an outline with a properly structured sublevel, there is only a single sentence as content for the Level 1 topic. Having a single sentence only as content to an outline topic violates the second rule of outlining, Any outline level requires at least two sentences.

Listing 3 below shows the Orange Cranberry Tangerine Fizzle piece adjusted to support the Two Sentence rule.

Listing 3: A well formed outline that supports the Two Sentence Rule

1.Making an Orange Cranberry Tangerine Fizzle

An Orange Cranberry Tangerine Fizzle can be a welcome treat on a hot summer day. The beverage is made from natural ingredients with no artificial flavors. An Orange Cranberry Tangerine Fizzle not only tastes good, but it’s good for you too!

The sections below describe the process that you need follow to make an Orange Cranberry Tangerine fizzle.

1.1. Preparing the ingredients

1.2. Mixing the Fizzle

1.3. Serving the fizzle

Why all the hubbub about proper outline structure and at least two sentences to a level? First, following the Sublevel rule forces me to be very clear about the logical segmentation of my piece. Also the Sublevel rule ensures that my writing communicates my ideas with a flow that makes sense and is easy to follow.

Second, The Two Sentence rule forces me to create copy that is engaging, detailed and makes sense. "One sentence" writing often lacks detail. And, with the exception of one- liner comedy, writing of the "one sentence" variety is not the most interesting copy to read.

4. Avoid ambiguous pronouns

Ambiguous pronoun references are probably the most typical cause of confusion in the practice of technical writing.

Consider the paragraph in Listing 4.

This paragraph may seem a bit comical, but it illustrates some important points. First, the paragraph attempts to put you in a place that the reader occupies. The reader wants to understand what's going on but is unfamiliar with the language in play. And because the language is unfamiliar, the reader is ignorant and thus, vulnerable. The reader wants new information; he or she wants to get smarter. But the reader is also a bit anxious. Admitting ignorance, even to one's self, even at a subconscious level, can be disconcerting. The reader is cognitively fragile. Concepts and words that you, the writer, take for granted, might be completely foreign to the reader. One ill explained concept or one word used without proper clarification can turn the reader off.

In the case of the paragraph above, I would not be surprised were you to be asking, "What is a Trafalgabor? What is a Weebietata? What is the paragraph talking about? How to use Trafalgabors? How to use Weebietatas? How to use both of them? This is confusing. I am going back to my Facebook page."

If a reader has to take time out from your writing to figure out what you are trying to communicate, not only is expository flow compromised, the reader most probably will become confused. Once you confuse the reader, you've lost. All the other stuff in the world demanding the reader's attention becomes more attractive than your work. So, the "next" button is clicked and your work goes unread.

In the case of Listing 4 shown above, the confusion is caused by the ambiguous use of the pronoun, they in the second sentence. Does they refer to the Trafalgabors, the Weebietatas or both? Remember please that the reader knows nothing of Trafalgabors or Weebietatas. (Please see Figure 1 below.)

Click here for larger image
Figure 1: The use of ambiguous pronouns makes technical writing confusing

The solution to the problem is simple. Please take a look at Listing 5 below. The ambiguous pronoun is removed. Clarity is restored.

Beware! The ambiguous use of pronouns is a sign post on the road to confusing technical writing.

5. clarity = illustrations + words

Please take a look at the photo below. Tell me if you can, what is the graphic about?

I am not surprised should you find yourself a bit perplexed. It's a perplexing photo. You know what the items are, but you have no idea what they mean. Such is the nature of an illustration. A picture without words lacks context.

When it comes to illustrations, readers require context in order to avoid confusion. The reader should not need to waste time or thought trying to figure out what an illustration is about. The easiest way to avoid confusing illustrations is to provide a caption.

Please take a look at the Figure 2 below. It is the same photo. There is little question as to what the photo is about.

Click here for larger image
Figure 2: The tools and ingredients required to make an Orange Cranberry Tangerine Fizzle

When it comes to technical writing, I have found it to be a good practice to provide numbered, descriptive captions with all illustrations.

Please, don't create captions that are figure numerals only. Use both a figure numerals and a descriptive comment in the caption. Also, you'll do well to avoid orphaning illustrations. An orphan illustration is a figure that exists within the piece of technical writing yet has no reference from within the copy.

If you insert an illustration into your writing, make sure to refer to it in your copy by figure number and location using words such as, above and below. You don't want to reader taking time out from reading your work to try to associate an illustration to copy or to locate an illustration within your article. If you add have a "Figure 4" in your piece, make sure that you have language in the text that says something like, please refer to Figure 4 below.

6. When dealing with concepts... logical illustration and example, logical illustration and example

Concepts are hard to understand....that's why they're called, concepts. So, when it comes time for me to write about a concept, whether it is, the Second Law of Thermodynamics, a piece of coding technique or a full fledged software framework, I use the following pattern in my writing: concept - logical illustration - example. I try to never introduce a concept without substantiating the concept with a logical illustration and then an example.

Let's apply this rule to describe an elementary algebraic concept.

The Transitive Property of Equality is as follows:

If A = B, and B = C, then A = C

Now let's provide a logical illustration that describes the concept. (Please see Figure 3.)

Click here for larger image
Figure 3: Thee Transitive Property of Equality is a fundamental principle of elementary algebra

Listing 6 below shows a few concrete examples to solidify the understanding of the concept at hand.

Listing 6: Some concrete examples of the Transitive Property of Equality

• If 7 = 3 + 4, and 3 + 4 = 5 + 2, then 7 = 5 + 2
• If 12 + 5 = 7 + 10, and 7 + 10 = 6 + 11, then 12 + 5 = 6 + 11
• If x + y = z, and z = 2a, then x + y = 2a

Thus, the rule as has been satisfied. We presented the concept, The Transitive Property of Equality, provided a descriptive illustration and followed up with concrete examples that substantiate the concept.

Let's move on to a concept that is more relevant to software development and a bit more difficult to understand. The concept is Maven POM Inheritance. In Exhibit 1 below you are presented with the concept at hand and then a logical illustration that describes the concept. Finally, you are presented with another illustration that shows the concrete use of a POM files in an inheritance situation.

Exhibit 1: An excerpt of technical writing that describes Maven POM Inheritance

The example above relies heavily upon figures to provide logical illustration and a concrete example of the concept at hand. Creating interesting, engaging and accurate illustrations and examples are a difficult undertaking, but well worth the effort. Many times creating the illustrations for a piece of technical writing and providing example code will take as much, if not more time than writing the actual copy. Thus, I plan accordingly when allocating my time to meet a deadline.

When it comes to making a concept crystal clear, illustrate and then provide an example.

7. Embrace revision

It's rare to produce a good piece of technical writing right off the bat. Understanding your topic, organizing your ideas and then finding the language to present the ideas clearly and accurately takes time as well as a lot of effort. Therefore, don't constrain yourself by expecting to get everything right the first time. Rather, plan to write at least three versions of your piece. The first version just gets some words in print so that you can understand your intentions. The second version brings clarity and accuracy to your work. Then, once you have your facts right, your illustrations clear and your organization logical, create a third version that makes your work engaging and special.

To hijack the Thomas Edison quote, "Technical writing is 10% composition and 90% revision!"

Bonus section

Now that you learned about the 7 Rules for Creating World Class Technical Documentation, I am going to share with you the process that I use to create a piece of technical writing. It's short, but to the point. I call the process, The 7 Steps for Making a Technical Document. Here goes:

1. I create outline, at least to the second level, hopefully to the third.
2. I add to the outline my illustration for each concept.
3. I caption my illustrations.
4. I fill in the copy to the outline, following the Two Sentence Rule, adjusting my outline to adapt to the copy at hand.
5. I revise.
6. I send the piece to a subject matter expert for review. (A subject matter expert is a person that can identify inaccuracies and unclear writing.)
7. I revise again based on the response of the reviewer(s).

There you have it. 7 Rules, 7 Steps. Who could ask for more? So, now that you've learned all of my tricks, feel free to go forth and make the world a more accurate, engaging, illustrative and interesting place in which to live. It's worth the effort.

社区

Architecture,

Java

主题

开放源代码,

应用服务器,

平台,

企业架构

标签

OSGi,

图书

OSGi 在Java业界正是风生水起。几乎所有的JEE Server，比如IBM Websphere、Oracle Weblogic和Sun glassfish，都采用了OSGi作为基础平台，甚至推崇实用主义的SpringSource也挟Spring DM之势，推出了基于OSGi的应用服务器——Spring DM Server。山雨欲来风满楼，乘着这股东风，在BlueDavy发布了《OSGi实战》以及《OSGi进阶》之后，国内第一本OSGi的专业书—— 《OSGi原理与最佳实践》刚刚面世。InfoQ中文站精选了其中的两章，特做成迷你书，供各位读者免费下载。

免费下载迷你书

如果你喜欢本书，请通过购买原版《OSGi原理与最佳实践》支持出版商和InfoQ中文站。

点击这里： 免费下载这本书（PDF） 免费下载这本书（PDF） 。

迷你书目录

《OSGi原理与最佳实践》原书详细信息

前言
目录

第1章 OSGi框架简介

1.1 Equinox

1.1.1 简介
1.1.2 环境搭建
1.1.3 HelloWorld
1.1.4 开发传统类型的应用
1.1.5 从外部启动Equinox

1.2 Felix

1.2.1 简介
1.2.2 环境搭建
1.2.3 应用部署
1.2.4 在Eclipse中调试Felix

1.3 SpringDM

1.3.1 简介
1.3.2 环境搭建
1.3.3 HelloWorld
1.3.4 Web版HelloWorld

第2章 基于SpringDM实现Petstore

2.1 即插即用的Petstore

2.2 新一代Petstore的实现

2.2.1 环境准备
2.2.2 Utils模块
2.2.3 Bootstrap模块
2.2.4 ProductDal模块
2.2.5 ShoppingCartDal模块
2.2.6 ProductList模块
2.2.7 ShoppingCast模块
2.2.8 ProductManagement模块

2.3 部署

2.4 Petstore的扩展

BlueDavy《OSGi原理与最佳实践》采访

InfoQ中文站就这次出版邀请BlueDavy对OSGi的近况、在具体项目上应用OSGi应该注意的问题和解决方法，以及如何在OSGi开发过程中结合使用敏捷实践的问题进行了一番访谈。

InfoQ：自从你上一次发布<OSGi进阶>后，OSGi联盟最近有什么新进展？OSGi社区发展如何？

BlueDavy：OSGi联盟目前正在制定4.2的规范，并已发布公开草稿版本。在草稿版本中，我很欣慰的看到了OSGi联盟对 OSGi所做出的众多改进，包括了OSGi使用者们期待已久的对于Declarative Services的细节改进，并将其版本定为1.1，目前Equinox也已推出1.1版本Declarative Service的实现；除了对DS的改进外，在Core部分也可以看到提出了Framework Lunch这样的新规范部分，这对于按照标准使用OSGi和嵌入OSGi至其他容器提供了很大的帮助。除了以上这些外，还有其他很多的改进，在《OSGi 原理与最佳实践》一书中对OSGi R4.2的公众草稿版做了更多详细的分析。

但由于公布的公众草稿版本并不涉及企业应用领域，也就是EEG小组的工作，因此尽管大家期待的RFC 119: Distributed OSGi以及RFC 66: OSGi web container出现在了Early Draft中，但并没有出现在公众草稿版中，这两个最受大家关注的规范内容应该会被列入EEG出版的规范中。

对于社区这一块，OSGi尽管已经发展这么多年了，到目前为止确实仍然没有非常成熟的社区，但其相关的maillist，例如equinox maillist、OSGi-Dev maillist以及Spring-DM maillist都相当的活跃，业界的OSGi的使用者们根据自己的经验提出了不少OSGi的最佳实践，其中Bea的最佳实践总结以及Peter和BJ Hargrave在2007 JavaOne做的OSGi最佳实践总结给大家提供了很大的帮助。

InfoQ：相信很多人都想在真实项目中使用OSGi。请问如果要基于OSGi开发新系统时需要注意什么问题？如何设计系统的架构才能充分利用OSGi的好处？

BlueDavy：基于OSGi开发新系统时最值得注意的问题就是如何合理地划分模块的粒度，以及遵循OSGi框架的实现方式来构建真正的模块化、动态化的系统。

由于OSGi的强项在于模块化以及动态化，如果想在系统中充分发挥这两个优势，一方面是要让系统真正的模块化，把握好每个模块需要对外提供的功能，充分合理地使用OSGi提供的模块化交互的方式，例如import-package以及OSGi。

Service另一方面则是要让系统真正的动态化，这包括了基于OSGi框架支持的Bundle生命周期管理以及服务组件生命周期管理合理构建动态 化的模块，同时也需要合理处理动态化时所带来的影响，例如引用的服务的注销、对象状态的保留与恢复等。在《OSGi原理与最佳实践》一书中提供了一些构建 模块化和动态化系统的实践建议以及为什么要如此做的分析。

InfoQ：我们也看到在现实中存在着大量的遗留项目。那么，对于把传统的遗留系统改造成基于OSGi的架构，一般需要注意什么问题？

BlueDavy：突出的问题一般是模块ClassLoader隔离后带来的问题，对于OSGi的入门者来 说，ClassNotFoundException或者ClassCastException这类异常会成为常见的现象，这就要求使用者能够对 ClassLoader以及OSGi模块隔离和交互这两方面的知识有充分的掌握，就如BEA的microServices的开发者们总结的一样：当你不使 用OSGi来构建模块化系统时，你根本就不知道什么是真正的模块化系统，他们在移植原有的BEA的产品到OSGi上时花了一年多的时间，这也意味着要将传 统系统改造为OSGi架构确实有不小的难度，无论是OSGi知识方面的学习还是设计思想方面的转变。

InfoQ：Oracle收购了Sun，这两家公司势必要在很多方面整合，比如双方对OSGi的态度。我们知道，虽然有很多JEE Server都选择架构在OSGi之上，但是Oracle Fushion 11G里面却没有采用OSGi，请问你认为Oracle收购Sun对OSGi会产生什么影响？

BlueDavy：从我2005年接触OSGi而言，对OSGi的前景一直非常的看好，也许在2005、2006年时OSGi的前景 看似一片迷茫，但进入2008、2009后，无论从Java主流应用服务器都基于OSGi来看，还是从Java将从语言级提供对模块化的支持来 看，OSGi已经逐步的得到认可并成为事实性标准。

Oracle在很久之前就开始关注OSGi，并且Oracle也是OSGi联盟的成员之一，尽管Oracle Fushion 11G没有采用OSGi，但我认为这并不表示Oracle否定OSGi，或者不愿意采用OSGi，也许Oracle只是认为目前采用OSGi会对其原有积 累的技术产生不小的冲击，毕竟BEA为了移植到OSGi花了一年多的时间，从另外的角度来看，提供模块化的支持已经成为Java语言发展的必然，OSGi 是目前仅有的已投入实际商业产品使用的模块化规范，另一方面从OSGi对JSR277产生的影响来看，可见OSGi在Java模块化规范方面的领先地位， 因此也许不久后我们就能看到Oracle对OSGi的态度，相信很大概会是好消息。

InfoQ：应用系统开发引入OSGi之后，又如何应用TDD、自动构建等敏捷实践？

BlueDavy：OSGi Service为POJO方式，再加上OSGi和Spring一样支持方法方式的依赖注入，因此对于依赖关系不复杂的OSGi Service的TDD和自动构建没有问题。

对于依赖状况复杂的而言，在Spring中多数仍然会采用配置文件编写依赖注入关系，启动Spring容器，获取相应的bean进行测试的方式。在 这种情况下，目前OSGi容器的支持则不是很好，较Spring容器的单元测试而言复杂很多。一方面是由于OSGi采用的为Bundle部署机制，这就要 求在测试时将所有需要依赖的Bundle部署至OSGi容器中，在目前的情况下这需要通过编写程序来安装。这个状况等到OBR进入使用阶段后会好很多，原 因在于通 过OBR可以很容易的自动安装所需依赖的Bundle；另外一方面则是由于OSGi并不直接提供在外部获取OSGi Service的方法，就像Spring可以通过ApplicationContext来获取Bean。但是，也不是没有办法，如何在外部获取OSGi Service的方法在《OSGi原理与最佳实践》一书中有进行讲解。除了书中讲解的方法外，在OSGi R4.2中新提供的Framework launch也将有助于在OSGi容器外部获取OSGi Service。

鉴于上面的两个原因，在目前的情况下只能自行实现一个单元测试框架，OSGi China User Group最近会公布一个OSGi单元测试框架以方便大家对OSGi程序进行TDD和自动构建。

社区

Java

主题

RIA,

Silverlight,

富客户端/桌面

标签

Flex,

Flash,

JavaFX脚本,

JavaPolis,

GWT

Parleys.com是 下一代的RIA电子学习平台，在这个平台上，人们能在浏览器里或是在桌面上观看视频讲座。现在，Parleys.com的默认频道提供来自 JavaPolis、SpringOne、BeJUG、JavaBin、Jazoon、EclipseCon的一些优秀技术演讲视频。顶级品质的Java 内容总共将近有200个小时。

Parleys.com 观众也能把这些讲座下载到本地磁盘离线观看，这是一个使用得越来越多的优秀特性。浏览器和桌面应用程序都能让你用全屏模式观看演讲，甚至能在观看时动态调 整播放模板。播放时间轴可以让我们的观众添加注释、标签，并在需要的地方跳过幻灯片。你能在菜单栏选择自己喜欢的幻灯片演示设置（我自己喜欢3D Cube），或在自己的收藏列表中添加某个演讲、查看其它相关的演讲。

浏 览器和桌面应用程序之间无缝集成是一个很好的特性。比如说，你能从浏览器中启动桌面应用程序。桌面应用程序启动之后，如果你在浏览器下载某个演讲，它会被 添加到桌面应用程序的下载队列中。这样当你从浏览器中观看演讲的时候，如果该演讲已经下载过，流数据就会由桌面程序负责从本地磁盘中取得。这会节省你的 （还有我们的）一些带宽。

另一个顶好的特性是后退按钮能正常工作，你还能对演讲中的某个特定的幻灯片进行深度链接。

浏 览器版本我选的是Adobe Flex3，桌面客户端选用AIR。但由于服务器端设计为使用REST的服务层，所以我们可以很容易地添加其它技术类型的客户端。目前，我们正在并行地开 展JavaFX客户端（它看起来非常有发展前景）、GWT、Silverlight的工作。对比较不同技术来说，这是一种有趣而有根据的检验。

目 前公布的Parleys.com版本（我们的第一个版本）是一个使用轻量级AJAX的Web应用，其中Flash和JavaScript在一起无缝协作。 我们超过十万的用户很快提出了更多的RIA特性需求，像在全屏模式下观看演讲、观看过程中更换播放器模板、甚至下载演讲并离线观看。用DHTML和 Ajax满足不了更进一步的需求，对此类客户端来说，考虑像Flex/AIR、JavaFX这类RIA技术会更有意义一些。在我必须决定选择哪种RIA技 术的时候（2007年6月），JavaFX语言才刚刚发布。于是，合理而实际的选择就是从Adobe工具开始。

作为一个Java开发人员，学习面向对象的ActionScript和UI标记语言实在是像公园散步般简单。但问题是（Java）开发人员不是设计人员，而设计人员需要这两项技能来使用RIA技术。这就是我对Adobe的Thermo项目感到非常兴奋的原因。它能在Photoshop设计人员和开发人员之间的鸿沟上架设一个桥梁（很令人兴奋的东西）。

Flex和AIR的另一个优点是，你能选择不同的通讯策略——比如XML、JSON、AMF（二进制格式）——容易地与Java后端协同工作。Adobe甚至（在07年的JavaPolis大会上）开源了他们名叫BlazeDS的远程产品（用Java开发），BlazeDS允许你从ActionScript访问服务器端Java服务。

与Java比起来，Flex和AIR的不足之处是质量保证方面的工具不足。例如，ActionScript代码的静态分析（像FindBugs、PMD、Simian等）还不可用。Jetbrains最近在IDEA 7.0.3中添加了对Flex的支持，我觉得是个惊喜。它让你使用代码分析器分析ActionScript代码，这是一个好的开始。不过，现在我还不确定是否要用Flex去开发一个超过500个屏幕显示的ERP应用。JavaFX对企业世界有很大影响也在于此。

对 嵌入式RIA应用来说，另一个机遇是要便于搜索引擎搜索。RIA内容能被搜索引擎索引是非常重要的，这样人们才能通过Google、Yahoo等搜索引擎 查找到你的站点。你可以用一个并行的静态站点来方便搜索引擎，不过这样工作量太大了。我更喜欢用RSS Feeds或Atom Publisher协议的优势来达成一样的效果……等我们试验成功之后我再告诉你。

Flex 和Java之间的“交叉授粉作用”说起来也很有意思。Annotation在Java中是主流。你能观察到Flex阵营也露出了类似的端倪。比如 说，Flex的元数据标签就用于与Annotation类似的行为。因此可以想象注解过的Java EE 5实体通过类似技术被重用为ActionScript实体，并在客户端映射进SQLlite。

我对Flex/AIR较高的期望有：

• 就个人而言，我希望在AIR未来的版本中能出现Socket监听器，因为如果不这样，AIR应用中要实现完全的P2P功能也许只能使用Hack。
• 通过AIR文件部署Java应用也许会非常棒。这可以让我利用在Java中的投入。在我们头脑风暴的时后，还想过用Java语言开发Flex和AIR应用呢。
• 让签名的Flex应用摆脱Flash沙箱的束缚。

Parleys.com的Flex/AIR版本已在去年12月的JavaPolis 2007大会上发布。在那个主题演讲中，我说明了技术难题，但也解释了我们的观众要求的功能。

2007 年6月我们决定开发Parleys.com的一个RIA版本。我本来可以继续DHTML/AJAX路线，但我对版本1已经觉得非常痛苦了，我对Ajax的 求知欲消失殆尽。2007年6月，选择JavaFX做为技术路线为时太早，而且由于我在Mac上开发，Silverlight也不可用。所以，合理的选择 就是考虑Adobe Flex/AIR。服务器端仍然使用WebWork/Velocity、Spring和Hibernate来保持100%的Java。

这一选择带来的好事儿就是我的一些Java同僚震惊于Flex版的发布，于是他们决定重用相同的后端开发一个JavaFX和GWT客户端。我必须要说这看起来非常有发展前景。我会在一场非正式的JavaOne技术讨论会中介绍这些不同的Parleys.com策略。

你可以观看Parleys.com的主题演讲。

JavaFX 的工具支持仍需要加强，但更重要的是，我希望Sun Microsystems也能着手处理Photoshop和JavaFX之间的鸿沟，以便开发人员和设计人员能够协作（就像Adobe正在计划做的那 样）。支持主流的音频、视频编解码器是JavaFX获取成功的另一个重要特性。JavaFX要是想在RIA领域分一杯羹，把JavaFX应用作为 Applets部署（运行在JRE update N）、具有与Flash一样的（冷/热）启动体验也是至关重要的。希望下一届JavaOne大会上能提供相关信息。

JavaFX的优势当然是成熟的Java平台和快速的运行时环境，尤其是JavaFX代码编译之后。我发现重新设计现有的（企业）Swing应用有巨大的商机，MVC中的视图部分可以使用更好看的JavaFX皮肤来替换。

如果JavaFX Mobile允诺的那些都能实现，JavaFX也能得到巨大的推进。Java（FX）、AIR、Silverlight，谁第一个应用于iPhone，让我们拭目以待。

体验了DHTML/Ajax处理多浏览器/多操作系统的痛苦之后，我越来越欣赏GWT的策略。

我们已经有了Parleys.com客户端的第一个GWT原型。它看起来很不错，而且在不同的浏览器和操作系统上不需要调整。Google的确实现了他们的承诺，以Google中汇集的脑力是理所当然的。

开发新的组件有点儿挑战，我希望活跃的GWT社区能继续成长并发布更多的UI组件。发布GWT版本之后我们会关注观众们更喜欢哪一个客户端。我会让你保持消息灵通的。

我安装过Silverlight的版本1和版本2早期的一个Beta版。Demo确实能在Mac上的Firefox中运转，除此之外就没什么值得提的了。看看Dolmen公司中负责Microsoft技术的同事能给我带来什么惊喜吧……我可没给你们压力啊 ;)

看 DHTML/Ajax阵营是否能像RIA那样进取。GWT将会在这场较量中扮演重要的角色。一年半之后，我们也许就有了Flex4和AIR2。到那个时 候，Photoshop设计人员先绘制出原型，Flex开发人员在上面添加一些逻辑就可以收官了。由于未来因特网和电视之间的趋同，我们将能制造类似 iTunes的应用，在各种操作系统（包括Linux）上在线或离线播放HD交互式视频。

一年半之后，我应该已经知道Adobe AIR和/或Java（FX）是否运行在iPhone上，还有JavaFX Mobile的承诺能不能落实……美妙的时刻！

网上购物店的数据模型，它主要模式有产品：product ，帐户：Account，定单：Order。和产品相关的表有category ，product,item, inventory, supplier；和用户相关表有的account ，signon ，profile；和定单相关的表有orders,orderstatus,lineitem ，他们之间的整体关系如下.

ERD图

FK:Foreign Key

二、帐户模型

帐户模型，记录者用户的登录名称，密码。以及个人信息如地址，性名，电话等，还有它在系统中的profile信息。表有Account 主键是userID,它记录用户的基本信息，如email,name等。Signon 表记录者userID和password，Profile表记录者用户的登录系统的系统设置。可以根据用户的类型，显示不同的登录信息。

（1）account表

create table account (

userid varchar(80) not null,

email varchar(80) not null,

name varchar(80) not null,

status char(2) null,

addr1 varchar(80) not null,

addr2 varchar(40) null,

city varchar(80) not null,

state varchar(80) not null,

zip varchar(20) not null,

country varchar(20) not null,

phone varchar(80) not null,

constraint pk_account primary key (userid)

)

说明：primary key是userID,它记录帐户的基本信息。

（2）Signon 表

create table signon (

username varchar(25) not null,

password varchar(25) not null,

constraint pk_signon primary key (username)

)

说明：记录登录名和密码。

（3）Profile表

create table profile (

userid varchar(80) not null,

langpref varchar(80) not null,

favcategory varchar(30),

mylistopt int,

banneropt int,

constraint pk_profile primary key (userid)

)

说明：用户的登录信息，方便个性化定制。

（4）Bannerdata 表

create table bannerdata (

favcategory varchar(80) not null,

bannername varchar(255) null,

constraint pk_bannerdata primary key (favcategory)

)

说明：记录不同的登录信息。

三、产品模型

产品的模型主要有分类，它是产品的大类。表category 就是记录分类名称，描述信息。Product

记录每个产品的基本信息，包括产品名称，和产品的描述。它是一对多的关系。Supplier 表

记录产品的提供者信息，包括提供者的名称，地址，状态等。Item 记录产品的提供者，产

品ID,价格，状态。Inventory 表记录产品的数量。关系如下：

（1） category表

create table category (

catid char(10) not null,

name varchar(80) null,

descn varchar(255) null,

constraint pk_category primary key (catid)

)

（2）product表

create table product (

productid char(10) not null,

category char(10) not null,

name varchar(80) null,

descn varchar(255) null,

constraint pk_product primary key (productid),

constraint fk_product_1 foreign key (category)

references category (catid)

)

（3） item表

create table item (

itemid char(10) not null,

productid char(10) not null,

listprice decimal(10,2) null,.unitcost decimal(10,2) null,

supplier int null,

status char(2) null,

attr1 varchar(80) null,

attr2 varchar(80) null,

attr3 varchar(80) null,

attr4 varchar(80) null,

attr5 varchar(80) null,

constraint pk_item primary key (itemid),

constraint fk_item_1 foreign key (productid)

references product (productid),

constraint fk_item_2 foreign key (supplier)

references supplier (suppid)

)

（4） inventory 表

create table inventory (

itemid char(10) not null,

qty int not null

)

（5）supplier表

create table inventory (

suppid int not null

name varchar(80)

status  char(2)

attr1   varchar(80)

attr2   varchar(80)

city    varchar(80)

state   varchar(80)

zip    char(6)

phone   varchar(80)

constraint pk_supplier primary key (suppid),

)

四、定单模型

定单记录用户的选择产品信息，数量，表主要有Orders,记录用户的地址，帐户信息，总金

额。Orderstatus 记录定单状态。Lineitem 记录定单中的产品数量，单位价格，产品ID。

（1）orders表

create table orders (

orderid int not null,

userid varchar(80) not null,

orderdate date not null,

shipaddr1 varchar(80) not null,

shipaddr2 varchar(80) null,

shipcity varchar(80) not null,

shipstate varchar(80) not null,

shipzip varchar(20) not null,

shipcountry varchar(20) not null,

billaddr1 varchar(80) not null,

billaddr2 varchar(80) null,

billcity varchar(80) not null,

billstate varchar(80) not null,

billzip varchar(20) not null,

billcountry varchar(20) not null,

courier varchar(80) not null,

totalprice number(10,2) not null,

billtoname varchar(80) not null,

shiptoname varchar(80) not null,

creditcard varchar(80) not null,

exprdate char(7) not null,

cardtype varchar(80) not null,

locale varchar(20) not null,

constraint pk_orders primary key (orderid),

constraint fk_orders_1 foreign key (userid)

references account (userid)

)

定单的信息。

（2）Orderstatus表

create table orderstatus (

orderid int not null,

linenum int not null,

timestamp date not null,

status char(2) not null,

constraint pk_orderstatus primary key (orderid, linenum),

constraint fk_orderstatus_1 foreign key (orderid)

references orders (orderid)

)

定单中的产品状态

（3）lineitem表

create table lineitem (

orderid int not null,

linenum int not null,

itemid char(10) not null,

quantity int not null,

unitprice number(10,2) not null,

constraint pk_lineitem primary key (orderid, linenum),

constraint fk_lineitem_1 foreign key (orderid)

references orders (orderid)

今天我的windows 7遇到了小问题，资源管理器的“收藏夹”无法展开，但“库”和“计算机”都可以。但点击“收藏夹”能进入到“收藏夹”的文件夹，里面的快捷方式没有丢失。我尝试右击“收藏夹”，选择“还原收藏夹”链接也没有效果。也就是说，某些原因导致了windows 7资源管理器的“收藏夹”失灵了。

搜索了很久都没有找到答案，于是我使用了英文作为关键词去搜索，经过了几次的链接转跳后，终于找到了答案。

解决方法：

在“vistax64”论坛里，有网友贴出了Vista下收藏夹被清空和资源管理器的“收藏夹”无法展开的问题的解决方案，其中一个修改注册表的方法经测试有效，分享如下：

1、运行regedit

2、展开到HKEY_CLASSES_ROOT"lnkfile

3、添加一个字符串值：IsShortcut ，不需要填写串值，回车即可

4、重新登入

如果你嫌麻烦，可以直接下载这个reg文件，双击导入即可。

社区

Architecture

主题

互联网,

性能和可伸缩性

标签

Google,

社区

在几周前将网页加速工具开源后，Google又发布了一个网站，意在探寻更多的方法，并推动全互联网的加速进程。这次Google分享了研究数据、网站加速优化指南、有关性能的录制视屏、大量性能优化工具的介绍，以及一个讨论组，期望所有人都能在此分享如何使网页更快的创意。

Google研究部门针对网页装载速度如何影响用户的搜索结果做了一个研究，在数据响应阶段他们引入了几个可控的延迟：

在引入这些可控延迟，并对用户监视了4-6周之后，他们在搜索结果数字中发现了如下问题：

虽然0.5%的损失对一般人并不意味着什么，但是Google确信这样的损失对他们来说意味深远，因为在用户执行搜索的数字、广告点击显示的数字以 及收入之间有着直接的关联。除了加速自己的Web服务器，考虑到这样做对其他人也有着积极的作用，Google还想加速全部互联网。

Google认为，除了带宽限制，还有其他多方面的因素导致了互联网的慢速：

• 在Web开发中，网站没有遵循最佳实践，导致不必要的慢速；
• Web服务器经常没有专为速度而优化；
• 几个互联网协议是在10年或者15年之前设计的，那时候的网站和Web应用和现在大不相同；
• 浏览器也是最近才开始关注速度，很多互联网用户还在使用慢速的浏览器。

那么对Google来说，互联网速度应该快到什么程度？从一页导航到另一页的速度应该和翻一页杂志的速度相当；允许视频和图像内容尽可能快；用户之 间的实时协作不能因链接而延迟，包括移动用户等。等等这些，Google想看到HTML得到优化，这一点在HTML 5里也已经得到体现，但是他们还希望优化甚至用一些更好的东西改变HTTP和TCP。然而，考虑到要在目前的基础设施中做这样巨大的投资，这个改变还相当 难以实现。

为了指导其他人如何加速他们的网站，Google提供了如下一些指南：

• CSS：每个声明只使用一次
• gzip压缩如何工作
• HTTP缓存
• 使用网页加速工具优化网站性能
• 将浏览器回流降至最小程度
• 优化JavaScript代码
• 优化Web图片
• PHP性能技巧
• 预读取资源文件
• 正确包含样式表和脚本文件
• 降低HTML文档的文件大小
• 用户体验和网站优化

他们还从各种信息源收集到以下一些工具：

• Page Speed（网页加速工具）：这是一个开源的Firefox/Firebug插件。网站管理人员和Web开发人员可以使用网页加速工具估算自己网页的性能，并得到如何优化这些网页的建议。
• AOL Page Test（AOL网页测试）：这是一个用来测量和分析使用IE时网页性能的开源工具。
• Cuzillion：该工具能够快速构建网页，并发现组件如何交互。每天，浏览器都会有各种无法预料的行为，有时因为浏览器不同，行为也各异。Cuzillion能够让你发现这些行为，并和其他人分享示例网页。
• Fiddler 2：这是一个Web调试代理工具，能够记录计算机和互联网之间的所有HTTP流量。Fiddler让你能够监测到所有HTTP流量，设置断点，虚拟流入和流出数据。Fiddler有一个强大的基于事件的脚本子系统，能够使用任何.NET语言进行扩展。
• Firebug：Firebug和Firefox相集成，让你在浏览网页时就能使用多个开发工具。你可以编辑、调试、监视任何Web页面的CSS、HTML和JavaScript代码。
• Hammerhead：Hammerhead给Firebug增加了一个Tab，用来测量网页的装载时间。
• httperf：这个工具能够用来测量Web服务性能。它提供了一个用来创建不同HTTP工作量和测量服务器性能的功能。Httperf的重点不是实现一个特定的标准，而是提供一个自动的、高性能的工具，以帮助构建微观和宏观层面的标准。
• HttpWatch：这是一个HTTP浏览器和调试器，和IE以及Firefox相集成，在浏览器窗口的配合下，对HTTP和HTTPS进行无缝监视。
• IBM Page Detailer（IBM网页设计器）：一个图形工具，让Web站点开发人员和编辑快速而准确地从客户角度估算网页性能。IBM网页设计器提供了网页从何处被传递到Web浏览器的行为细节。这些细节包括时间、大小，以及一个网页中每个条目的身份。
• JSLint：一个JavaScript项目，用来查找JavaScript程序中的错误，是一个代码质量工具。
• JSMin：一个过滤器，可以从JavaScript文件中清除评论和不必要的空白。
• Microsoft VRTA（Visual Round Trip Analyzer）：VRTA工具帮助Web开发人员和测试人员可视化网页下载、寻找最佳实践和改变，以优化Web性能。VRTA检查通讯协议、定位往返过多的原因，以及推荐的解决方案等。
• mon.itor.us：提供个性化的Ajax仪表盘界面，检查服务器性能和有效性，创建运行时间报告，跟踪访问者，检查CPU、内存和其他系统资源，并在监测到异常时给用户报警。
• OOCSS：允许开发者撰写快速、可维护、基于标准的前台后台代码。
• Pylot：一个用来测试Web服务性能和可扩展性的开源工具。它运行HTTP载入测试，这在容量规划、标准、分析和系统调整时都很有作用。Pylot生成并发载入（HTTP请求）、验证服务器响应和产生数据报告。
• Smush It：使用图像格式特定无损图像优化工具，挤出你图像中的所有冗余字节——还不改变他们的外观和可视质量。通过优化图像，你可以得到一个所节省字节多少的报告，所有修改的图片也可以作为一个单一zip包下载。
• Wbox： 该工具意在当你测试HTTP相关文件时，能够多些乐趣。用它可以执行很多任务，包括：为Web应用、Web服务生成内容所用的时间，Web应用负载，无需 改变本地解析器测试虚拟主机配置，在发出正确的HTTP代码的情况下检查重定向是否工作正常，测试HTTP压缩是否正常工作以及是否让服务器页面更快，将 其作为一个配置少的HTTP服务器来分享文件。
• Yahoo! YSlow：用来分析网页，并基于一套高性能Web页的规则，给出提高性能的方法。YSlow是一个Firefox插件，和Firebug Web开发工具相集成。
• YUI Compressor：一个JavaScript压缩器，用来生产比其他大多数工具更高压缩比的文件。

最后，Google加速网站包含了一个讨论组，任何人都可以在此分享他们的技术和创意，以用来加快网页的访问速度。

InfoQ网站上相关内容链接：Google开源网页加速工具Page Speed

查看英文原文：Google Calls for a Joint Effort to Speed Up the Internet

• www.k585.com
• www.vodtt.com
• www.mm023.com
• www.13hp.com
• v.92na.com
• tv.huayushequ.com
• www.145la.cn
• www.gggvod.cn
• www.dv165.com
• ymx18.cn
• www.qvodc.com
• whklg.5944vip.net
• www.lvyoulvyou.com
• zjd240.w18.dns2008.cn
• movie.in0574.com
• www.cctv-tv.net
• zjd.9yz.cc
• www.hcge.net
• 19623.800y.net
• www.sdxyyy.com