这两天我看到人就会推荐这个 gem
#32 楼 @hxgdzyuyi 这个还是第一次听说,长见识啊
我最常用的其实是 tab 键,虽然不起眼,但确实有很多新手不习惯,所以专门提醒一下,如果是 ubuntu,几乎所有的命令(包括很多参数)都有提示
#24 楼 @camel @quakewang 为什么不用 Ctrl+R 呢?
这个项目挺有意思阿
我直接用磁盘分析器,主要是喜欢那个展现方式,很直观
如果是 rack 里面的实现,也请说明具体在哪里做的
其实可以反思一下这个标题——“什么时候需要增加测试?”,乍一看很奇怪,合格的工程师都要对自己的工作进行测试,所以无所谓增加测试,这个问题要问的其实是“什么时候需要增加自动化
测试”
这么一想你就明白了,所有的自动化工作都可以这么归纳——“当人肉成本不足的时候就进行自动化”
所以首先严格要求团队成员通过测试确保质量,然后培训或者提醒他们——测试的手段包括自动化
,其它事情由开发人员决定就可以了,当他发现回归测试是一个噩梦的时候,合格的程序员自然会添加自动化的工作
具体落实起来要多考虑一个因素,有些事情不做不是因为不重要,而是人手不足,此时考虑自动化吧
#38 楼 @siriuszhuang #39 楼 @siriuszhuang 你这两个场景恐怕是两类问题。 后一个比较简单,如果对队列的“消费”如果是排它的,那么一开始就不应该有多个线程去消费,“建造”这个活动应该只有一个独立的后台进程去负责实施,它在执行时检查建造队列是否为空,然后决定自己的行为,其它线程随便给队列丢任务。这里的要点是:判断是否能建造和实施建造过程是个顺序执行的任务,不能把判断拆出来并发。 前一个比较复杂,看来你们确实是 web game 之类,这个地方的问题其实是“实时更新”,如前所述,所谓“并发”(你这里是并行)本身并不是问题,完全彻底的异步化就可以了,但是计算“战斗结果”这个是不能并行的,只能有独立进程去频繁更新,并第一时间广播给客户端,难点在于这个独立进程的性能,通知是否及时。
BTW:看来还是 @quakewang 经验丰富,我没想到是 web game,所以要纠正一下我之前的建议,如果确实是 web game,任务队列用数据库实现绝对不合理,这时候应该用专业的消息引擎了。
找到了比较一个优雅的方法:
git fetch origin
git reset --hard origin/master
参考来源:fast_git_deploy
我结合 pry 进行调试的时候会遇到 crash
#15 楼 @siriuszhuang 你做的事情可以看作一个状态无关的函数,所以消息队列其实就是存储执行函数所需要的参数值的,这是逻辑队列,实现可以是多样的,最简单的做法可以在数据库创建一个 records 表,每次请求直接 insert,然后外部启动一个 ruby 进程周期性的从数据库按照 id 一条一条读出来慢慢执行。 当然,更好的方式是使用专门的消息引擎,比如 @bhuztez 提到的 rabbitmq 等等,不过我猜你的场景还没到这个地步
#10 楼 @siriuszhuang @bhuztez 的建议是正确的,不过可能楼主没看懂,我换种说法,并发本身并不是问题,问题出在并发的同时对某些地方又要求顺序执行(比如同时做就会“建立两个建筑”),所以关键是把顺序执行和并发分开,简单的解决方式是使用消息队列——无论前面怎么并发,进队列的时候永远是顺序执行。 这样做的话,一般意义上的“创建升级事件或者其他复杂的逻辑”都可以在处理消息的阶段顺序进行,虽然未必快,但是可以保证正确
补:看来不是没看懂,是被吓住了,嘿嘿
文章很不错,不过 @yuan 的发言也不是完全没有用,我也担心会有人盲目照搬不看前提,有争论可以帮助他们。 提个小问题,下面这句话
如果符合條件的資料是 10 萬筆,全拉出來有高達 10G 的大小
难道一条数据是 100K 么?这个数据库的表设计也太可怕了吧?