#3 楼 @blacktulip 觉得敏捷还有一点，就是不做没有价值的事情。比如 DHH 在产品的演示阶段，不会去修 bug，因为这个流程的目的就是尽可能的确定需求，既我要做的，到底是不是客户想要的。有没有 bug 一点不影响这个目的，所以完全没必要浪费这个时间。

觉得试错也要让代价尽可能小，比如 lo-fi ui。画出来了，流程就有了。比做 design，线框图实在多了。

做事可以有两种，一种靠试错。一种靠推断。 试错，其实一定程度上，假定了，不可知。就是我不知道用户需要什么，我也不知道市场需要什么。很多公司用 20% 的时间让员工做自己想做的事情，除了为了调节心情，也是基于此考虑。

预测。考已有的知识，预测结果。比如 100+100 我不要用计算机，就知道结果。

假定了不可知，其实也是有套路可言。比如，没有公司拿 50% 的时间做尝试。再比如经济理论上是不可测的。在比如有人靠极小概率的负面时间获利（《黑天鹅》的作者）。一定程度上是，承受小程度的损失，获得巨大的潜在李毅。

预测。 人的行为，有的时候又很大程度可以被预测的。人除了食、色这些本能的需求外。需求其实无外乎是地位（面子），确定性（稳定），关系，自主性，公平。（引自《Your Brain At Work》）

比如今年的 ruby Conf 上。有个做 A/B 测试的例子。大体是一个中级的收费，被给成 limitation 后，就有更多的人购买了 pro（30% 几吧？具体忘了。。。）。

人其实会花一些钱，购买自主性。所以 limitation 会不受待见。这个就是一个推断。

如果相信“推断”是有道理的，那么大可不必做这个 A/B 测试。也就可以省些成本。

觉得什么都可能是有意义的，也可能是么意义的。

比如口渴了，喝水就很有意义。但不渴了，要他水喝，就是没意义的。

再比如，有的程序员，就是想要做高大上的东西。那么用高大上的架构，高大上的语言，做些高大上的东西。对于这些人就是有意义的。说白了就是，带我装逼，带我飞。能装逼，能飞，就是有意义的。

再比如，有的程序员是要做事，要解决问题。比如我这种，去重构代码，考虑的只是是否更可维护，至于美不美观（其实 beautifu code 的标准就是是否可维护，而不是看起来爽不爽），跟我没关系。最终的产品，能解决问题，对我来说就是有意义的。至于产品是否高大上，是否好看，对我来说，没有什么意义。

扯远点。王守仁说，无善无恶心之体，有善有恶意之动。 如果人心连善恶都没有，何来的意义？当然也是我个人的理解，很可能是误解:)。

说句闲话，我倒是很喜欢王守仁的处事态度，方式不重要，目的才重要。不在乎如何达到目标（高大上的语言框架不重要，能解决问题的话，有没有技术都不重要），而只在乎是否能达到目的和目的是什么。其实这和 BDD 是契合的，这也是我当初选择当程序员的原因。

集体来讲，共同目的很重要。比如我上学的时候，每年要站着回家，20 个小时左右。我每年都要坐！不是因为多么喜欢身边的乘客，而是，火车能送我回家。如果不能送我回家的车，我一分钟都不想上。

(以上纯属个人观点，不见得是对的，倒是很有可能是愚蠢的 :) )

1. user story + 5 why
2. lofi ui

其实敏捷也有求分析，只不过很轻量，并且需要客户参与。而且是最！困！难！的一步。

理论上，程序员拿到手里的东西都是确定的东西（比如提供搜索功能，至少要精确到按照名字搜索的程度。再比如优化，要确定为，响应速度在三秒以内），之后可以开撸了。

有人说，tdd 有的时候意义不大。确实这样的，因为完整的流程，tdd 前面是 BDD，BDD 前面是需求分析。

当然这个都是书上说的。。。

CS169。

做缓存？

觉得在 ruby conf 分享者中，最牛的就是那个做视频的。据说是辍学的。简单来说就是 目标明确 + 不扯淡。再就是比较搞笑。

觉得能不能解决问题跟学历什么的关系不大。

#1 楼 @happypeter 动手很重要。但大方向必须要对。

更喜欢有人能给出 big picture（别扯细节，但多数人做不到这点），然后有实际操作，再去理解其中的“道理”。

#2 楼 @jcd

觉得键点是，他把水填起来来了。把 bar 想象成可以增加的。

然后就是逻辑的严密了。我猜的，不知道对不对。

说一句，这种算法，code 都是很 cheap 的，方法更重要。

cucumber 用的就是类似这种方式导入数据。但 cucumber 做的是集成测试。

Factorygirls 似乎用在单元测试多一些。单元测试，是尽可能不依赖外部。所以应该有单独的数据。

为了保持可测还可以重构代码。 拿是否好测作为代码标准，远比所谓的经验要好用。

:plus1:

1.label。用一两个形容词形容自己的情绪。比如紧张、沮丧。技巧是，尽可能早的发现情绪，早的形容情绪。尽量的形容得准确。不要用过分形容。 2.转移注意力。比如讲注意力集中到声音上，将注意力集中在触觉上。 3.reappraise。比如从别人的角度思考问题。reordering，对事物的价值进行重新排序。

以上出自《your brain at work》 0 找到原因。暂时换个环境试试。break 一下不见得是个坏事（比如 gap 这个东西完全看你如何操作，但 gap 前建议做好足够久的准备）。

哎，努力着只看一两本书的人飘过。

#20 楼 @ruby_sky ........

想不出来如何用“搞”字回复了。我发现我越来越喜欢这个字了，哈哈。

#2 楼 @ruby_sky 孩子多大了，什么时候教他搞 ruby 或者搞编程啊？

#4 楼 @special 其实，我们老板选办公室的第一原则是离地铁近！

不建议“动”拼盘 里面的东西，动的话，会带来很高的复杂度。直接 copy 一份其实也没什么

这个问题也没用多少空间，而且随着拼盘被填满，做的尝试会越来越少，而且才 10 几秒就停了。所以就没考虑优化的问题。

希望我没理解错这个题目的意思。

觉得可以换个思路，就是把 bricks(积木) 往上面填。 代码在这， https://gist.github.com/yfractal/9fd567789ec0ef1534d0

结果看起来还不错，但我只检查第一个解。。。

有很多可重构的点，但觉得都是些小的改动。没时间，你先凑合着看吧。。。（Bricks 换个存储结构比较好些）

关键点有两个，一个是，尝试着创建积木，一个是递归。

选择创建积木的原因是，你在可能的积木中挑的话，然后在看是否合适，复杂度太高了，而且应该和创建的方法是等价的。但这是我猜的，没试着证明，也没看过你的代码。。。

不看新闻好久了。

clojure 太难写了（本人比较笨），速度也不够快。 推荐 Julia。R 的语法，C 的速度。

有人说 ios 开发复杂度在 API 那，不在语言。

电脑多数时间用来写代码、看网页、看视频。 觉得如果我有时间，宁愿给编辑器换个配色。

觉得你这个是读源码，依照不多的个人（很可能是错误的）经验，问题不应该在文档。

这个？ http://baike.baidu.com/view/5909535.htm?fr=aladdin https://github.com/id774/recommendation

其实觉得随机就可以了

http://book.douban.com/subject/24316596/

推荐理由：

1. 作者为了写这本书，做了大量的 research，读了大量的书。 作者调查了很多知名的公司，比如微软什么的（其中的一个作者 David 说，去那些公司，那里的人很多的还认识他。呵呵，你那门组成原理，人家没准还挂过科呢。David 和斯坦福的计算机主任合作写了两本书）。 作者说他读了 50000 页书还是多少的。 很少有人写书会下这么大的功夫。
2. 全面 rails 的书绝大多数都是讲一方面。就算 DHH 那本 agile development，似乎也没讲敏捷开发的流程。像 rspec 这种，单单只讲了一些特性。我甚至没觉得他把 tdd 讲的多么明白，也许是我当时看的太匆忙（tdd 推荐这本 http://book.douban.com/subject/10483528/ ）。
3. 精炼 20% 在实际中占据了 80%。而剩下的 80% 的知识不过只占 20%。比如那本 Programming Ruby，太多了。。。详细而没重点。 这本书的特点是，只给你讲了重点，你想多学点，呵呵，自己 google 去，但单单这点却十分重要，如果我要学 tdd，我会选择读几遍这本书关于 tdd 的部分，而不是看那本废话连篇的 rspec（很多写书的，其实就是对自己知识的总结，然后再给自己的产品吹个牛逼）。
4. 反馈 本书是 Berkerly 的教材。拿来讲课。讲课的过程中会收集学生的反馈。然后迅速出下一个版本。而开发人员写完书，就去写代码了。写书是开发人员的副业。而这本书的作者把写书当成自己的主业。

#1 楼 @n00b1 我不知道为什么，最近喜欢看吸血鬼相关的。。。

同意二楼的说法。 ZNation 感官刺激不错，但故事情节什么的就一般般了。

为注重效率顶一个。