#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 大体也可以有两种，严格的是就是测试在代码之前。不严格的就是代码和测试并行，既测试在写完一段代码不久后补上。

楼主说的排列组合是不是这种？C(3,2) =3 且排序是 1,2,13, 23 ?? 如果是这种，下面的有可能（10%...）是对的（纯粹无聊，抛砖引玉，坐等答案！）。。。

nth = 1000 i = 1 C(n,r) = C(n-1,r-1) + C(n-1,r) 两种情况 C(n-1,r-1) > 1000 (1) C(n-1,r-1) > 1000 (2)

情况（1） nth = nth - C(n-1,r-1) n = n - 1 r = r -1

情况（2）nth - C(n-1,r-1) nth = nth n = n-1 r = r -1 这个时候记录下 i。

nth = 0 的时候停止，把记录的所有 i 搞出来，应该就是解（1 成的把握是正确的吧。。。sorry）。

解释下公式，如果我没记错的话 C(n,r) = C(n-1,r-1) + C(n-1,r) ---- () () 的右半部分是考虑两种可能，取第 n 个 + 和不取第 n 个。 n 个可以理解为第 n 个球，而我是倒着给球编号的。

解释下思路 有两种可能，第 nth（1000），他取得 i 和不取得 i 如果 nth 小于 C(n-1,r-1)，则意味着要取 i，那么记录 i，更改 nth,n,r，做递归 如果 nth 大于 C(n-1,r-1)，以为着不取 i。nth = nth - C(n-1,r-1)（所有去 i 的可能的情况）。做递归。

#16 楼 @saiga :plus1:

#13 楼 @saiga :) 觉得能写出代码的人都很牛！比如 8 楼

#12 楼 @bluexuemei 程序的构造与解析 应该有这道题。。。你可以问问别人。 或者 http://www-inst.eecs.berkeley.edu/~cs61a/sp14/ ，也应该有类似的题，我忘了在哪了。。。都是关于找钱的，就是有几种硬币，然后一凑个整数。

觉得递归都不容易懂，反正我学递归学了好久。。。

availables = [1,3,..10....]

想要凑起来得 m 有两种情况，1，用 availables 的第一个数，2，不用 availables 的第一个数。然后递归。

对于第一种情况，m = m- availablse[0]，下一次的 availables 刨除第一个数。 对于第二种情况，m = m，下一次的 availables 刨除第一个数。

大体思路就是分两种情况，然后做递归。 #7 楼 @saiga 突然发现，我不知道 01 和动态规划。。。掩面 。。。

用递归做，比较好一些吧？

#32 楼 @blacktulip 我没说清楚。 web 方面，觉得 Javascript 和 Django 的需求都很大，也许最后去的那家公司，你用的是这两种技术。反正就是觉得有这样一种可能，学 rails 可能最后不会用 rails。

#33 楼 @ericguo 不好意思，我表述有问题。。。不好意思。。。是可能为碰到坑。