刚发现 ruby-china 可以直接上传图片…

#12 楼 @Saito :D

#9 楼 @doitian 没有吧？给个链接看看，红轴的。

@huacnlee 不知道寿命是不是真的有传说中的那么久，如果有的话，寿命 + 手感，应该还算值吧。

@hooopo 买了吧买了吧 :D

@hooopo 上线一下呗

o.o

#48 楼 @xiaolai 我觉得是越看重钱的人，越容易受到诱惑，越喜欢走“捷径”，越容易往歪路上走，越容易短视。

#8 楼 @_kaichen 首先回复你

“用起来很慢”跟“根本不可用”不是一回事吧？实际上软件不可用的问题倒更有可能是因为代码不清晰引起的，常见的一个场景就是用户的一个很合理的需求，程序员由于各种原因推迟甚至不给支持，根本上的原因是代码改动困难，一个小需求在代码上需要动大刀，成本太大。这才叫做软件“不可用”。

老温那句话怎么说来着，“如果不是为了使程序能用，我可以写出每张卡片的处理时间只需要 1 毫秒钟的程序来”。

编程的本质是抽象，从 0 和 1 层层抽象到用户需求。烂代码对程序员不可用，最终迟早会积累（抽象）成软件对用户不可用，这是一个熵增的过程。所以，到底是注重代码质量的程序员本末倒置，还是急于完成功能的程序员短视呢？有的时候快即是慢。

以上，与主题无关。接着再回复关于主帖的部分

我并不是逐个的反对 lz 的建议，有一些甚至是赞同的。但是从文章整体当中嗅到一些味道，首先我做个猜测，赞同 lz 所有建议的，是不是习惯在 rake task 里写大量代码呢？我在 rake task 里的代码往往只有几句，例如Model.backup，多数逻辑分散在 Model 的各个方法里。所以这时候，第 1 个建议我是反对的，放弃重用已有逻辑直接写 SQL 或者用另一套 ORM 违反了 DRY 原则，多出许多维护的工作。

2 和 3 我没有反对。

第 4 个建议，我用 Rails 几乎没有关心过 transaction。事务本是用来保障数据完整性的，但是文章中使用它居然是为了提高性能，是不是过分追求性能了点？有时候，高层的一些方案能够解决性能问题，就尽量使用高层的解决方法，实际上在越高层解决性能问题，效果越明显。实在顶不住了，才再往底层挖掘，这样可以尽量的减少脏代码，同时又不损失性能。而且就算挖到底层，我也不会用这样的歪路子，为了性能到处声明事务，让人莫名其妙。

第 5 个建议，该 save 时还是要 save，一些时候的保存操作就是应该触发 callback 和 validator。不过如果习惯在 rake task 里写许多代码，而不是把多数逻辑分散到模型当中去，有这样的建议好像也不奇怪。

建议 6 中 lz 提到的问题，在批量操作数据的时候，实际上是用建议 3 解决，而非建议 7。在另一些情况下，可以用缓存搞定，也不是用建议 7。而建议 7 的做法实际上不是用来解决性能相关问题，而是代码质量的问题，详见设计模式的“代理模式”，或者重构名录“隐藏委托”。

建议 8 无争议。

建议 9，同建议 5，我反而是多用 destroy 少用 delete，生怕忘了清除什么，留下脏数据，或者是需要手动来维护一些本来可以自动维护的关联关系。

建议 10 无争议。

我的观点是无论 功能开发 还是 性能优化，自底向上的都不是什么好方法。

我会首先考虑代码简洁。一个问题是：简洁的代码和高性能二者真的只能取其一吗？如果答案是肯定的，那么你真的曾经把代码写简洁过吗？

这篇博客的问题在于，业务代码当中考虑了本该由底层的支持（Rails）该做的事情。里面提到的问题也许难免遇到，问题是解决的方法：是该在业务代码里考虑这些，还是应该去改进 Rails？这是对象职责分配的问题。

程序员圈某“名人”的做法是，“link_to 有性能问题，那我们就不用 link_to，全都给我改用 html 的 a 标签。”封装哪里去了？散弹式修改这么强烈的 bad smell，居然没嗅到。

个人观点，任何人都可以不同意。我也相信多数人不支持我的观点，无所谓，只希望不会影响到我周围的环境。好的环境很难找，也许就不存在，至少别让它变得更坏。

#21 楼 @kewin 要是真的就好啦 :D 只是关注 twer 们比较久罢了

#18 楼 @maddemon 不是这么说的。一来在那里技能能够提升很多，二来那里的环境没有那么多让你吐血和折寿的事，周围都是对自己有要求的人，我需要做的只是对自己有足够的要求，至少不被别人要求。从我这边来说，愿意用钱来换几年寿命。 从另一方面考虑，我相信 tw 会根据应聘者的实力给出合适的待遇，就这样。

#4 楼 @n5ken 上海办公室 2012 年春节后刚成立，不知道最近咋样了。

感觉要是能进 tw，真没必要考虑待遇。

#4 楼 @fsword 我觉得至少愿意花时间对自己的作品精雕细琢的才能算得上上“匠人”吧。

#2 楼 @hooopo 一个例子 https://github.com/mdirolf/nginx-gridfs/

数量跟质量好像必然要有冲突，不遗余力的推广社区，同时又担心质量下降我觉得挺矛盾的。人少一定是坏事嘛？数量增长得慢一点不好嘛？我觉得曾经的 JavaEye 可以作为参考吧。

我想知道，社区大了到底有啥好处？到底谁有好处？

好吧，我帮周哥顶一下。对 CSTO 所在的特别项目组不了解，没法多说啥。

我感觉 rails way 不是 oo way，rails 本身的一些东西会误导开发者，比如它的表单，特别是嵌套表单，写习惯很容易让开发者觉得暴露对象内部结构是再正常不过的事情。再比如它的 try 方法，也同样让开发者养成不封装的习惯。还有关联对象的一些方法例如：user.books.build/create、user.books << book 等等。所以第 2 点挺正常的。

可能有些未必是 orders controller 的逻辑，也许属于 payments controller，另外 model 和 controller 未必得是一一对应的。电子商务订单流程处理参考一下 spree 我觉得挺好。

iphone only 啊？话说去年 3 月，借了辆车没处还，先在楼下停着，结果中午发现被人推走了，搞得我一直没办法还车。今年 4 月份回来一查，还好，我以为欠了上千块，结果显示为 300 多块。再打电话一问，车子已经被归还，只要交 120 块钱就好。

#9 楼 @hooopo 我记得的最后一次导测试数据时间在 ns 不写 iteye 博客之后。

各种 ns

#64 楼 @yedingding 嘿嘿，就是觉得挺有勇气的。

#11 楼 @zhaowenchina 对，是这个 Moleskine。

我记得《程序员的思维修炼》里推荐过一种笔记本，忘了叫啥了，一时 google 不到，有人记得不？

严格执行 GTD 感觉比较难，是去年的目标，没完成……或者说根本没开始。之前一直在找工具，不过现在觉得工具不是问题，反而成了我的借口。

蕃茄工作法相对容易执行些，不过这两者关注的东西不一样，GTD 在宏观上把握方向，蕃茄工作法在具体的事情上保证工作效率。两者结合使用好像倒是不错。

至于习惯，GTD 本身就是一种（觉得 GTD 有用的人）需要养成的习惯吧？整个过程：收集、整理、执行、回顾等等……

#60 楼 @ruchee 我觉得更不可思议的是“我们 3 个对技术都只是了解的程度、编码能力几乎为 0”的人要做“给小团队协作的工具”。

我只是说出我的疑惑。

#39 楼 @FrozenDoggy :)

提醒一点，把脑力劳动者当体力劳动者来用一开始就错了。

区别在于： 体力劳动，人越多，工作时间越长，老板的收益就越高； 脑力劳动，脑越多，沟通成本越高。持续工作时间越长，大脑得不到充分的休息，产品质量越低。

只针对这一句：过硬的身体，可以适应强度较大的编码工作

@hooopo 实际上我比较好奇把一个常量赋值给一个变量背后的目的是什么。如果不是非这样写不可，那还好；如果代码非得这么写不可，问题的根源应该不在 lz 给出的代码当中。