这两天我看到人就会推荐这个 gem

#4 楼 @lgn21st 这个说法我非常理解，虽然没有用过 mac，但是我也从侧面观察到使用 mac 对人的潜在影响——当然是指好的方面 不过我同样理解楼主，实际上我对这条贴士也感觉很别扭，可以鼓吹但最好不要排斥，这种绝对排它的说法很难不引起别人的反感

#32 楼 @hxgdzyuyi 这个还是第一次听说，长见识啊

#87 楼 @lgn21st 晕，这个教派这么长的名字，一查才知道原来是摩门教

我最常用的其实是 tab 键，虽然不起眼，但确实有很多新手不习惯，所以专门提醒一下，如果是 ubuntu，几乎所有的命令（包括很多参数）都有提示

#24 楼 @camel @quakewang 为什么不用 Ctrl+R 呢？

#18 楼 @zlx_star 我明白你的意思，所以才这么回答。 实际上，要提高自动化测试的 IOR，先要问问它是干什么用的，我的建议是换一下思路：如果不用自动化测试，你需要人工做哪些事情才能对系统的质量放心，然后考虑自动化的成本，这样你自己就会明白应该添加哪些自动化测试。

反过来，如果你平时自己并没有手工验证一下代码正确性，那么可能意味着这个地方的质量你是特别不关心，结论你懂的。

再次强调一下，具体做事的时候要多考虑一个因素，有些事情不做不是因为不重要，而是人手不足，当自动化是一个选择的时候，一些事情也许可以提上议事日程

其它具体的建议往往和项目类型相关，你可以参考，但是恐怕不适合简单照搬

这个项目挺有意思阿

我直接用磁盘分析器，主要是喜欢那个展现方式，很直观

如果是 rack 里面的实现，也请说明具体在哪里做的

其实可以反思一下这个标题——“什么时候需要增加测试？”，乍一看很奇怪，合格的工程师都要对自己的工作进行测试，所以无所谓增加测试，这个问题要问的其实是“什么时候需要增加自动化测试”

这么一想你就明白了，所有的自动化工作都可以这么归纳——“当人肉成本不足的时候就进行自动化”

所以首先严格要求团队成员通过测试确保质量，然后培训或者提醒他们——测试的手段包括自动化，其它事情由开发人员决定就可以了，当他发现回归测试是一个噩梦的时候，合格的程序员自然会添加自动化的工作

具体落实起来要多考虑一个因素，有些事情不做不是因为不重要，而是人手不足，此时考虑自动化吧

#38 楼 @siriuszhuang #39 楼 @siriuszhuang 你这两个场景恐怕是两类问题。 后一个比较简单，如果对队列的“消费”如果是排它的，那么一开始就不应该有多个线程去消费，“建造”这个活动应该只有一个独立的后台进程去负责实施，它在执行时检查建造队列是否为空，然后决定自己的行为，其它线程随便给队列丢任务。这里的要点是：判断是否能建造和实施建造过程是个顺序执行的任务，不能把判断拆出来并发。 前一个比较复杂，看来你们确实是 web game 之类，这个地方的问题其实是“实时更新”，如前所述，所谓“并发”（你这里是并行）本身并不是问题，完全彻底的异步化就可以了，但是计算“战斗结果”这个是不能并行的，只能有独立进程去频繁更新，并第一时间广播给客户端，难点在于这个独立进程的性能，通知是否及时。

BTW：看来还是 @quakewang 经验丰富，我没想到是 web game，所以要纠正一下我之前的建议，如果确实是 web game，任务队列用数据库实现绝对不合理，这时候应该用专业的消息引擎了。

#68 楼 @lgn21st 过滤一下吧，贪多嚼不烂，别让喜剧变悲剧。 也许有的主题可以放在 ruby tuesday 来做，话说杭州这边也很久没搞了

#4 楼 @luikore 你写一个吧

#64 楼 @lgn21st 照这么增加下去这次会议要爆棚啊

#6 楼 @ayumi043 1.9 应该可以跨多核的，爬虫对并发的要求不是很高，多线程应该足够了

找到了比较一个优雅的方法：

git fetch origin
git reset --hard origin/master

参考来源：fast_git_deploy

#14 楼 @luikore 恩，这个好

我结合 pry 进行调试的时候会遇到 crash

#18 楼 @bhuztez 要看怎么做，添加一个锁字段比较容易犯错，用单独的队列表配合独立进程就会很简单，用数据库的一个好处是可以直接借助事务和锁强制并发请求顺序进入队列，缺点是性能太差

#15 楼 @siriuszhuang 你做的事情可以看作一个状态无关的函数，所以消息队列其实就是存储执行函数所需要的参数值的，这是逻辑队列，实现可以是多样的，最简单的做法可以在数据库创建一个 records 表，每次请求直接 insert，然后外部启动一个 ruby 进程周期性的从数据库按照 id 一条一条读出来慢慢执行。 当然，更好的方式是使用专门的消息引擎，比如 @bhuztez 提到的 rabbitmq 等等，不过我猜你的场景还没到这个地步

#10 楼 @siriuszhuang @bhuztez 的建议是正确的，不过可能楼主没看懂，我换种说法，并发本身并不是问题，问题出在并发的同时对某些地方又要求顺序执行（比如同时做就会“建立两个建筑”），所以关键是把顺序执行和并发分开，简单的解决方式是使用消息队列——无论前面怎么并发，进队列的时候永远是顺序执行。 这样做的话，一般意义上的“创建升级事件或者其他复杂的逻辑”都可以在处理消息的阶段顺序进行，虽然未必快，但是可以保证正确

补：看来不是没看懂，是被吓住了，嘿嘿

#9 楼 @ery 其实 mixed 你可能一直在用

文章很不错，不过 @yuan 的发言也不是完全没有用，我也担心会有人盲目照搬不看前提，有争论可以帮助他们。 提个小问题，下面这句话

如果符合條件的資料是 10 萬筆，全拉出來有高達 10G 的大小

难道一条数据是 100K 么？这个数据库的表设计也太可怕了吧？

#10 楼 @knwang 用 java 开发类似功能的时候我确实会把 tag 变成一个 class，不过如果是 ruby 则不一定，一开始的逻辑其实很简单，就是把 tag 里面的一些特殊的东西剔除出去，因为没把握写好正则，所以写了这样的代码。 至于判断 code smell 也是要看场景的，当然如果要添加日志，还可以用 tap，我在 blog 里补充了例子（链接见 #9 楼）。 总的说来，是否需要建立对象其实是看复杂度的，只是 ruby 本身会把事情简化，所以其它语言需要建立很多对象，而用 ruby 的时候我会把精力放在更必要的场合