这个就是老子的，一生二，二生三，三生万物。。。好吧我承认我在扯淡。

推荐这个 http://hi.baidu.com/xiangxuehai000/item/30b7583024bd02c91a9696c6 觉得可以考虑下重命名试试。 比如把 zero 改成 zero-time-operation?

倒是觉得这句话很牛逼“算法可计算函数都是递归函数“ http://zhidao.baidu.com/link?url=hQqthbqY96AAqUkUJWevU8k7Qr6At1cnDHavhiioUdyvCQyYurfRK3DW1D6yhdofx9VtzniqFDPh_R-8KogAJK

觉得递归，就是定义了 0，然后定义了 1，再然后再在上面构建加法，乘法什么的。这个是不是就是丘奇数的意义？我不知道。。。

亲自试了下，觉得除了有人上千推一下，几乎没有危险。穷人，没相机，不知道那个相机是不是重的离谱。

收腹抬腿是个过程，当感觉重心快没了的时候，你自然会停下来。当然也不排除直接用力过猛的可能性。

by the way。这个动作练腹肌非常好！

玩过 tricking（比较安全的极限运动）的飘过。

一般在做危险动作的时候，要么是有很大的把握，要么是防护措施做的很好。

如果说极限运动危险，那么至少要拿到数据，比如极限运动者的死亡率和普通人的死亡率的比例。或者同开车比较。

再者，如果我有朋友干预我的喜好，我只能说呵呵。

#8 楼 @appell 我算是在用吧，但还没上线。 有些东西没有，但目前没怎么遇到过坑。

#1 楼 @yanguango thanks #2 楼 @Alexander 。。。我觉得我还是不碰这个东西的好。 #6 楼 @rasefon 好吧。。。

#46 楼 @crazyphage 我小白一个。。。什么都不懂。还比较笨。 觉得语言是用来解决问题的工具，需要用什么语言，就用什么语言。

#44 楼 @saiga 用了一段时间 clojure，感觉只有一个，我的智商不够。

#5 楼 @6233843 :) 我给出证明或者代码好了。。。不好意思。我实在是太懒了。。。

觉得这个算法可以补救下。。。但不确定是不是你想要的。。。 假设一共有 6 个人，分为两组。 前面是一样的。现在假设“树”已经生成完了，放在一个数组里。

觉得可以这样分组。 [1,2] [3,4],[5,6]

对于 [1,2],用随机方法，决定是把 1 放在第一组，还是第二组，以此类推。这样就有了随机性。

简单来说 k-means 就是定义了“距离”，距离近的就放在一组里面。k-means 需要组数作为参数。还可以定义权重。

assert_select ? 楼主找找吧，我就知道一个这个。。。

#2 楼 @imlcl 觉得是不是 random 一次就可以了？

觉得首先要准确定义“随机”这个概念。

如果“随机”的意思是说，每组内，有属性 A 的一样多，有属性 B 的一样多。

先按地区，分成三个数组 A1,A2,A3 对于 A1，按照 M,N,O 分组。

这样就能展成一个多叉树。叶子节点是数组，数组内的元素含有相同元素。

把所有叶子节点连在一起，变成一个数组 A_final

假设分为 n 组。

对 A_final 的 index，做摸运算就 ok 了。

似乎能行。。。我再想想。

发现我光顾着扯淡了，没正面回答楼主的问题。现在回答下。 我一般都会写测试，覆盖率应该有 60% 以上。除了状态极好的情况下，才会 tdd。但我会补测试。

哪有那么多人愿意 TDD 的。。。

有个图灵奖的获得者，说，写测试的难度是写代码的两倍。

不严格的 tdd 只要测试和代码可以交叉进行。

测试学习成本也不低，要学习一些概念，怎么写测试用例，怎么 stub（没 stub，根本没办法 TDD），在什么时候 stub。很多东西要学。

而且 TDD 乎还要配合下 BDD。BDD 尽可能的确定下需求，然后再 TDD。

先分组，1-9 做组 1 10 - 19 组 2 ...... 100 - 199 组 3

满租的情况 对于没一组，1 开头的有一个公式，非 1 开头的又有一个公式。。。

不满租的情况 组内所有数除以 10，记 1 知道可以填满某个租，用公式计算。 余下的重复这个过程，知道为个位数。

应该是可以。。。

嘿嘿！

#14 楼 @chenge 当然是真的拉，我们真的是站着开会的！！！哈哈。

由有经验的人估计难度，似乎要更靠谱一些！

不希望啊。 不过我们还好了，进度真的完成不了的话，可以延期，可以商量。

压力，难度，还是需要的，但太大，太多了，就不好了！

#12 楼 @chenge 觉得敏捷中很重要的一个部分是站立会议，而站立会议中的一项，就是以投票的方式确定项目的难度。难度过高，或者存在分歧过大，就要拆分或者讨论。

还有一些补救的办法，比如远远超过预期，就要重新讨论。

人应该更擅长做小计划，而非大计划。

觉得就是效率问题。这些方法不仅在软件行业存在，在别的行业也存在。

比如第二条。有人发现美国的工人没有日本的工人效率高，然后就研究为什么，最后得到的结论是，日本人允许员工换工作（想不起来是在哪读的了）。 人其实很讨厌做“重复”的事情，人每“重复”一次，就要付出更大的努力。

环境安静 一般来讲，人在安静的环境下更容易集中注意力，当然也只是一般情况。而注意力是否集中，是影响效率最重要的因素。

求解答，敏捷和甘特图的关系？

顶！

更喜欢 underscore，觉得 each_with_index 比较麻烦。也更喜欢函数式的方式。

觉得用 ruby 完全没有优势啊。。。

#8 楼 @zhangyuan 忘了改了。。。

#5 楼 @saiga 确实。。。多谢指正！ 可以具体说一下嘛？thanks。

NaN == NaN; false ...

#21 楼 @zealinux 可能是这本书吧？一万小时天才理论 http://book.douban.com/subject/4726323/

想说几点

1. 很多牛人都经历了一万小时的努力，变得很牛。但不见得努力一万个小时，就会很牛。
2. 一万小时，指的是精深训练。精深训练首先是是那种不很舒服的训练，有难度，但难度有不能过高。一流的运动员，觉得一天能有 4 个小时这样的时间就谢天谢地了。既，并非所有时间都能算在这个一万小时里面。
3. 这本书的例子，多数和运动，音乐有关。而且基于髓鞘质，简单来说，就是一件事情重复多了，就可以做的更好。和运动有关的，很多都需要反复的重复。但和思维有关的，似乎更注重方法（当然这些基于我的了解，很可能是错误的）。

支持 do 和 end，还可以像 python 一样把函数当参数传。

方程定义很变态，比如f(x) = x + 1

@ruby_sky 哈哈 确实。

#9 楼 @shangrenzhidao 耦合度高了不好写测试，方法复杂了不好写测试，参数多了也不好写测试。 应该是吧？

先写测试。 如果你先写代码，再写测试，会非常蛋疼。所以有人提出了 TDD。 TDD 大体也可以有两种，严格的是就是测试在代码之前。不严格的就是代码和测试并行，既测试在写完一段代码不久后补上。