流水不争先

IT 部门必读级别的书，以下是一些常用的 Tips

第十七章：从思维到机器 理想模型应尽可能从良好而详尽的设计范本库为基础，这些范本出发，设计师可以获得天然的一致性。但随着范本库的增长，设计师对其的熟悉程度会迅速降低。对范本库进行结构化的处理属于分类学范畴。 真正的敌人来源于范本库本身：拙劣的样本、太少的模型、狭隘的范围。 人们希望在大部分工作时间中双肘都可以支撑。 第十八章：从机器到思维 设计者需要至少两个大型的屏幕。 设计者需要同时看到目录视图和详细视图。应当提供多个视图以避免设计师的来回切换动作。 使用2D视图（抽象方式、工程习惯）进行设

第二章：理性模型 多数设计师会把所有的项线性相加，但线性方式不适合于衡量效用，因为边际效益会递减。（例如足够的电源插座是必要的，但过多的插座并不会提升总功能。但我们进行设计的时候，往往只是把数量简单相加） 在每个决策点设计师都可以有多种选择，因此设计的过程可以看作在“设计树”中寻找可行且较好的路径。（因此可以在某种程度上画出决策树来帮助思考） TODO：尝试用思维导图来描述“设计树” 设计多数时间是在寻找“最低限度满足条件”的路径而不是最优路径。 第三章：理性模型的缺陷 设计中的最大难题是决

第十九章：卓越的设计来自于卓越的设计师（而非过程） 虽然某些人视他们为疯子，但我们视他们为天才。因为那些疯狂地认为他们能改变世界的人，确实就是改变了世界的人。——Steve Jobs 为何过程抑制了卓越的设计：（非常有见解的分析） 过程的存在是为了给新产品开发的自然混乱带来秩序 因此过程天然就是保守的（不适合于高度创新工作） 过程具备可预测性 过程是“打响上一次战役”，鼓励使用从前有效的战术，不鼓励失败过的战术。因此面对新战役将无所适从。 其本质是“面向否决”的，

第八章：设计中的理性主义和经验主义 人人都会犯错，很多时候，大多数人都是在热情和兴趣的引诱下走向错误之渊。 理解力有两种形式：直觉和推演，无论哪一种都需要以知识为后盾——笛卡尔 PS: 这一章的翻译或内容让我如坠云雾，（一开始）我不清楚是书中的理性/经验主义、正式证明等用词是惯用的哲学/工程术语还是作者生造的，抑或原书确实是这个意思？我头脑中的理性主义对应着书中的经验主义：强调人天生有缺陷且一定会犯错，要通过实验和迭代来消除瑕疵。而书中的理性主义在我看来则是理想主义：认为经过正确的途径可以做出无暇的作

第六章：协作设计 多数伟大作品是由一两个人独立完成的。（二人团队往往具有神奇的效率，可能是由于彼此的激励和相互表达思想使人更快的了解到自己的错误，二人协作的错误率大大低于独立作业。以下的团队均指两人以上的。） 协作的必要性 技术复杂性和工程的规模不断增加 产品开发的时间压力越来越大 协作的成本 分割成本 学习与教授 沟通成本 变更成本：当设计师作出变更时影响到其他设计部分，则成本会高很多 多数情况下，人们暗示团队成员是对等的，从而设计必须满足每

这是一本很有趣的书！虽然我无法认同作者的很多观点，但是毫无异议的是：他的观点很有启发性。作者的视角和论点覆盖了大部分技术管理者面临的问题，让你从“人”的角度考虑如何进行技术人员的管理。（原书的英文名就是 Managing Humans）……

本書的後半部分有廢話之嫌，但依然保持了有趣的文風——畢竟是博客，湊合吧

XML 以及 Groovy 元编程基础

Groovy Recipes 是 2008 的老书了（没办法，貌似 Groovy 的基础读物之后就没有新的了），胜在够薄，拿来复习下 Groovy 的知识吧。

Definition: By connecting to a standardized network we can find information, buy and sell quickly and easily, with lower process and administration costs. Some of us will never wish to go online. Internet time is said to run seven times faster. De

Despite this programming, we do have a choice. It's easy to adopt a 'take me as you find me' attitude but this is not always appropriate. Whatever our choice, we are responsible for our behavior and accountable for the consequences. My negative behavior