WEB(RoR)_C(性能)_Elrang(并发)｜周期迭代+持续集成+及时沟通

软件的不直观是难学、难用、难开发、难理解的根本；唯一直观的线索是结构，尤其是数据的结构；代码结构也是线索之一；知识往往蕴含在结构之中，理出结构也就触到本质。

《The Elements of Programming Style 》是一本很古老的书。30 年的岁月依旧无法掩盖其中的真知灼见。把代码写清楚，别耍小聪明。想干什么，讲的简单点、直接点。只要有可能，使用库函数。避免使用太多的临时变量。”效率“不是牺牲清晰性的理由。让机器去干那些脏活。重复的表达式应该换成函数调用。加上括号、避免歧义。不要使用含糊不清的变量名。把不必要的分支去掉。使用语言的

来源于：http://book.csdn.net/bookfiles/34/100341059.shtmlUnix哲学起源于Ken Thompson早期关于如何设计一个服务接口简洁、小巧精干的操作系统的思考，随着Unix文化在学习如何尽可能发掘Thompson设计思想的过程中不断成长，同时一路上还从其它许多地方博采众长。Unix哲学说来不算是一种正规设计方法。它并不打算从计算机科学的理

第1章  构造过程抽象1.1 程序设计的基本元素1.1.1 表达式1.1.2  命名和环境1.1.3  组合式的求值1.1.4  复合过程1.1.5  过程应用的代换模型1.1.6  条件表达式和谓词1.1.7  实例：采用牛顿法求平方根1.1

数据==函数－是核心 结构、结构、结构业务率＝业务代码/(业务代码+技术代码)  1最好>UI测试的投入产出－>自动测试UI－C－M一起动起来，面和体快速UI－>M小而快UI－领域迭代M逻辑－UI形象Just do it，fire on act

正则表达式小贴士如果不用复杂的正则式就能解决问题，一定不要用。 如果必须写比较复杂的正则式，请参考以下原则。 从大处着眼，先理解待解析的文本的整体结构是什么样子，划分为小部件； 从细处着手，试图实现每一个小部件，力求每一部分都是完整、坚固的，且放在全局也不会冲突。 合理组装这些部件。 分而治之的好处：只有某个模块出错，其它部分没错时，可以迅速定位错误，消除BUG。 谨慎使用捕获括号，除非你知道自己在做什么，知道它会有什么副作用，以及是否有可行的解决措施。对于短小的正则式来说，一两个多余的括号是无伤大雅的；但

多年开始关注软件发展的转变，虽然很多在国外已然成熟，但在国内还有许多在探索之中。
软件发展的新方向：
１.　软件向ＤＳＬ方向发展，目标是向问题域接近
２.　软件开发向动态、多核、函数方向发展
３.　软件开发向敏捷方面发展
４.　快速、灵活的市场需求是发展和转变的动力
５.　互联网是软件发展的主战场，尤其是移动互联网
所以要加强以下方面能力：
１.　动态语言能力
２.　ＤＳＬ能力
３.　多语言能力<

Chapter FirstThe New Reality: 如今，人人都能开创事业。Chapter Takedowns Ignore the real world: “在现实中行不通”只是在为不去尝试找借口，与你，想开创事业的你，无关。Learning from mistake is overrated: 失败不是成功她妈，让其他人失败去吧。要知道自己应该做什么，从成功走向成功。Planning is guessing: 计划等于是让过去驱动未来，要学会即兴演出——知道当下最应该做什么，而不是盲目遵循计划。

本文是 Paul Graham 写的一篇关于黑客与画家共同之处的文章，深入探讨了黑客工作的艺术性与创造性。虽然大部分的程序员都觉得艺术是一件很遥远的事情，但对于那些愿意仔细打磨代码追求精益求精的优秀黑客来说，在创造的过程中总是能感受到艺术的真实存在（尽管可能只是隐约感受到，而且羞于把自己和艺术联系起来）。艺术之所以会让人觉得高高在上远离生活，是因为大部分人都是在衣着光鲜地谈论着艺术，而不知道什么是创造。要成为一个创造者，你所要做的不是夸夸其谈，而是投入全部热情去不断实践。Dirty Yo

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

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

    抽象和模糊完全地不同，抽象的目的并不是把事情变模糊，而去

原作：Joseph Ottinger
 
这篇文章实际表述了编程时应引起注意的很重要的6个思想：

快速失败；
写更少的代码（不要让自己重复）；
程序是写给人看的；
做正确的事情；
消减状态；
了解你的“创造”

（fail fast, write less code (and don't repeat yourself), computer programs are for p

在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》，翻译成中文就是“你认为最有争议的编程观点是什么？”，不过，在400多个主回贴，以及千把个子回贴中，好像并不是很有争议，而是令人相当的茅塞顿开，下面罗列一些，并通过我自己的经历和理解发挥了一些，希望对你有帮助。1） The only “best practice” you should be using all the time is “Us

软件思想家Gerald Weinberg专访　　 Gerald Weinberg给自己的评价是”thinker”。的确，与形形色色汗牛充栋的实用技术手册类书籍相比，Weinberg先生的著作（《程序开发心理学》、《系统化思维导论》、《你的灯亮着吗？》……）无不闪耀出睿智的光芒，并因此显得卓尔不群。　　　　在Weinberg先生的著作中译本即将问世之时，笔者有幸采访了Weinberg先生，与这位软件业内最著名的”thinker”有了一次近距离的交流……　　 《程序员》（下文简称”《程》

标题: 《程序开发心理学》读书笔记（一）上次就说要好好看温伯格的书，今天开始看《程序开发心理学》，在这里做一点点摘录和写一点点感想（蓝色部分），权当是读书笔记吧。读完序，给我留下最深印象的是译者的序中这么一句：“本人曾经因为侥幸发现其中（指此书）一处小纰漏，得到了温伯格先生寄来的一美元奖励，他对科学的这种严谨而坦率的态度，令人钦佩。”----张亚勤院士曾经这样评价温伯格先生：他是从个体心理、组织行为和企业文化角度研究软件管理和软件工程的权威和代表人物，他有着程序员、系统事、咨询师、专业作家的多重

系统化思维导论读后感　　1. 有个朋友推荐这本书给我，并且介绍的时候说，这本书也喜欢用数学或者类似数学的方式来描述问题，然后用解数学问题的方式来解决问题。我顿时很有兴趣，于是在当当网上购买了一本，由于当时我在重庆出差，我让当当把书送到了公司。　　2. 今天出差回来，拿到了书，吃完晚饭就开始看。对我来说，序言 等 仅仅是 有点风趣。　　3. 开始进入正题，他通过力学，分子动力学，引入了事物复杂性的那张图，可以说对于我这个读者，非常成功。力学是高中学的，我认为我高中的物理还是学得非常好的，分子动

在风起云涌的互联网浪潮中，产品迭代的速度越来越快。随着用户需求的激增，也不断带来了对设计师能力要求的提高。初入交互设计领域几年来，明显发现可视化的内容远比文档的更易于被用户(以至我们的客户)所接受，就像用户研究项目中常说的一句话：“用户怎么说的，并不代表他们怎么想。”今天以“原型设计”为基点，与大家展开几点做简要的分析。一、什么是原型设计？首先，让我们看看在体验设计的过程中的“原型设计”。以下结合个人对UCD理解和项目经验，梳理和简化的传统体验设计的流程。(流程是每个群体的工作方式，好像我们

hennry注：原型与产品真的是分得清吗？为什么要分清呢？最好是不分清，不浪费，迭代发展这里说的原型仅针对基于B/S架构开发的项目。目前有很多专业制作原型的工具例如axure、mockflow、InfoMaker和一些“非专业”软件：photoshop、Dreamweaver等等，如果你有足够的耐心使用word也可以做原型，当然还有笔、纸、橡皮擦。我接触过很多原型制作工具，也做了很多所谓的原型，项目不同，公司不同，使用的工具也不一样。个人认为用哪种工具制作原型，第1取决于用哪种工具最适合项目人员

一般的客户在刚开始往往不了解自己到底想要什么样的软件，随着项目的一步步进行，他们会根据实际完成的部分逐渐理清头绪，提出进一步的要求。有一种说法就是，“真正的需求是在第一个版本完成的时候产生的。”用户在看到完整的成品后，才首次理顺了自己的思路，然后在成品的基础上对功能进行删减。为了让客户更早明确自己的需求，还是应该根据最初的模糊需求制作出一个demo来，为客户提供一个实体做参考，来进一步细化需求，避免前期的返工。这个最初的demo是交付静态html页面还是由grail那种脚手架生成的crud程

hennry注:需求界面（html/css)　  开发不过最好用“快速后台数据”填充界面画出全部（几乎）界面图好似不敏捷？疑问？在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式。总是有人抱怨在需求和软件设计之间仍然有很大的鸿沟需要填补，这是至今仍然未能有效解决的软件工程难题。多年以来，有很多人一直在寻找从需求到设计的直接的形式化映射方法，但是收获很少。实际上软件工程对于软件生命周期前面的那些阶段并没有多大的帮助。为了响应 o6z说的努力在在现有技术基础上杀死人狼的号召

敏捷理解在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。真的是这样吗？敏捷过程到底是如何做需求分析？用户故事和用例有什么区别？敏捷过程如何去管理需求的？这些是一些想要实践敏捷的人一直在困惑的事