楼主说的排列组合是不是这种？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 不好意思，我表述有问题。。。不好意思。。。是可能为碰到坑。

学 4 的问题 会有不支持的情况（比如某个 gem），资料要少很多。rails4 本身可能就有 bug。 据说 rails4 相对难度大。觉得 rails 本身就很大，很难学。

当然也有好处，比如，一步到位。但问题是，你有多打的可能用的是 rails？又有多大可能你用的是 4？？？更可能的情况是，你大部分时间在写 JavaScript 或者是 Django。

#1 楼 @liprais :thumbsup:

#2 楼 @wangping #3 楼 @lex 我就是胡扯下。。。

#4 楼 @sufish 有理！！！:thumbsup:

#5 楼 @zhouchongzxc :thumbsup:

#33 楼 @Martin91 没做啊。。。我太懒了。。。

没有 Julia 不好玩！

#1 楼 @chenge :thumbsup:

#2 楼 @lihuazhang 觉得有些基本的东西需要了解，比如 stub，mock，比如单元测试的原则什么的。

#3 楼 @chankaward 又换头像了。。。

#12 楼 @sufish https://github.com/cloudwu/ejoy2d 这个似乎没有测试。。。

#9 楼 @ruby_sky 重点是大神好吗！！！sorry... 误会了 :)

我其实，就是找个机会，说下自己对测试的看法。。。楼主忽略我吧！

如果你写一段代码，会想着试一试你的代码（应该每个人都这么写代码吧？）。把这个代码写下来，觉得就是最简单的测试。好处显而易见，DRY。

有些没必要写，有的用不好 stub。这些情况，都会拖慢开发。但，代码个人觉得，代码质量的问题，才是最大的问题。

个人而言，半年来，写测试的时候，比我不写测试的时候要快，当然这也有可能是因为项目的特性以及记忆的不准确产生的偏差。但，我测试其实是覆盖不足那种。。。

TDD 其实前面还有 BDD，没 BDD 确定你做的是正确的事，既，你没有用葫萝卜钓鱼。那么有些代码会被直接丢掉。。。你写不写代码，都意义不大。

再者 TDD 不是说你写了测试，你就是 TDD，TDD 的流程，是 Red,Green,Refactor。你不重构，tdd 也没什么意思。

TDD，1 是分析问题的方法，明确目的，具体化问题。就好比接数学题的时候，如果你能问自己问题是什么，和举一些具体的例子，有助于你解题，见《怎样解题》。 2，分解问题。问题被分解为，有什么样的结果，和怎样去实现，是比较合理的。但同时也增加了相当大的复杂度。和学习成本，看如何取舍了。 3，代码的正确性，由代码自身保证。人脑不喜欢做重复的事情，所以，将重复的事情，交给电脑，也应该是合理的。大脑也不擅长逻辑思维，和抽象的事物（见《Your Brain At Work》），而测试刚好代替了大脑的这部分工作。 4, debug 时间和写测试时间，哪个多哪个少，也是看个人了。我 debug 能力跟屎一样，我也懒得学，所以用测试弥补。

释迦摩尼说过，不要相信任何人只凭听说的一切，当真正实践过，并且和自己的“原则”相符的时候，才去相信。

如果真的在乎这个，去读读相关的书，《Test-Driven JavaScript Development》，比如《重构》。了解不同人的不同看法，反对的，支持的。 亲身实践。写测试也分人。写测试也需要经验积累。

不写测试的，一样有牛人，比如云风似乎就不写，一样很牛，再比如 @ruby_sky 。写的，当然也有很烂的。

测试是手段，不是目的。

one more 如果，你写测试，不开心，不写测试，可能会更好。如果你 debug 不开心，不妨试试写测试。

见过 python 的 doctest，感觉不算是单元测试，没 stub 什么的。但又是测试一个 function 的。。。也可能是写测试的人出于某种考虑，没有用到 stub 什么的吧？ 没研究过 python 的 doctest，不知道第三方依赖是否是个问题？比如 respec 是不是每个文件都要引入？再比如 factory，觉得需要有单独的文件。

从 emacs 换成 sublime 又换回了 emacs。。。

#1 楼 @karmue 觉得覆盖要分哪种覆盖。如果是语句覆盖，90 是应该还是合理的。边界之类的，不在语句覆盖之内的，过早的考虑就是累赘。而且感觉这也不在 TDD 考虑范围内，TDD 有的观点只有，就是问题没有出现的时候，就不去考虑。

#4 楼 @chairy11 Master Boot Record 如果我记得没错的话（很可能是有错的。。但这个不是重点，真不是重点），想要加载系统先要“找到”系统所在的地方，所谓找，其实就是按照“门牌”找，而所有的门牌号都存在了 MBR 里，而 bios 启动的时候，会先找这个 MBR，然后通过 MBR 找到别的。。。

而 bios 是，在此省略若干字。。。

其实，我想说，我不知道如何解决你的问题。。。要是我的话就去找装电脑的了（羞。。。）。。。

好像 fitter 和 goto 有点关系。。。

推荐Engineering Long-Lasting Software 的第八章。 简单来说，就是先把项目跑起来，使用一下，有 user stroy 的看下 user story，没有的话看看 git commit 什么的也不错，最好能使用者交流下什么的，问问开发者什么的。之后注意下 models 的结构，有个 railroady 可以生成 ulm 图片。然后分离出具体问题，既你想要改或者要理解的部分。

当然这个过程比较复杂繁琐，楼主不喜欢，就可以无视他。多试试，找到自己方法。

先熟悉项目，了解需求，了解框架，找到相关部分，然后就是尝试着更改了。

个人经验是，不其实我没啥经验（我看的源码少的可怜，不是必须的就不看。。。） 1，带着问题看，或者有很明确的目的。 2，越晚接触细节越好。 3，分解问题，解决问题。

觉得我看代码的时候，一般都会看不懂。。。被逼着一定要看（一般是项目需要），才有可能看懂。。。

#15 楼 @ruby_sky ???

#10 楼 @ruby_sky #11 楼 @allenfantasy 我觉得叫涛哥也不错！霸气！

我觉得我很大程度上是在远程。因为和我做东西有关的，就一个人，在美国，但我我的工作地点是在公司。 个人感觉。 交流 交流是最大问题。 你做的事情可能是没必要的。。。或者一些细节搞错。 1，是多问问题吧？有的时候把对方的话重新组织下，问问对不对（本人英文比较渣）。 2，大局优先，先画大框，而且怎么 simple 怎么来（有出现过，把问题搞复杂的情况，比如我昨天还做了一小部分不必要的事情。。。）。 3，如果必要资源没给出或者事情没确定，建议先协商好，可以直接 pending 住。我始终相信，在任何软件开中，时间最大的浪费是在做的不是别人想要的这块。而且，真心觉得做不需要的事情是浪费时间，浪费生命。 4，测试可以非常好的降低交流成本！ 1），明确目的或者需求。 说的话不明确，语言比来就比较模糊。写成测试，就具体化了。觉得具体的东西都是好东西，哈哈。 大家应该都有感觉，写东西比说话难多了。书写，可以很好的帮助人思考。 2），动态文档（文档往往没办法跟着代码走）。 测试写的 ok 的话，大家也习惯测试的话，直接看测试，可以不需要跟你交流（当然这是理想的情况）。 3），代码最少化。 5，团队 DRY 如果有些坑，你踩过了，别人就没必要再踩一遍了。比如某个插件，我用的时候比较二逼，直接掉坑里了，如果别人也用这个插件，几句话就可以避免再踩这个坑。这个在远程比较不好搞。。。 如果遇到坑，第一时间在群里吼一声，没准就有人遇到过。如果团队有时差。。。自己解决吧。。。 一些配置。比如 emacs。。。如果公司别人也有用的，你配置起来会舒服很多。

（未完）

#12 楼 @chairy11 如果达成预期的话，人脑会释放多巴胺，而多巴胺促进大脑细胞之间每秒链接的数量，会看要到更多的可能性。 而没有达到预期的话，多巴胺会下降，而这会产生和疼痛很像的感觉，并且想要以逃跑来回应这种感觉（不想做了），影响你的逻辑思维和创造性思维。

帮你顶下吧。

话说至少半年前就看到楼主招在人了。。。