#18 楼 @huacnlee 外部只有一个请求~ 本地数据库查询倒是没什么问题~~

#15 楼 @lithium4010 就是我们做的项目依赖外部接口请求返回的数据..然后外部请求有几个就得得 400ms 左右~~然后再拿回来处理...

有几个 api 外部请求就得 400-500ms...怎么活~~

#7 楼 @wskongdesheng 我想知道怎么廋脸？

难招人~~

赞~~桌球桌帅帅的

比较看好 顶一个

lk6763688 at gmail.com 谢谢 -_-

https://www.gitbook.com/book/yeasy/docker_practice/details 不知道你要的是那一本 人邮好像出了书

差不多情况 拆不动 后面写的时候再抽逻辑吧 重构还要保证正常更新和线上的没问题 工作量会很大的

貌似有中文书~~

https://github.com/rails/strong_parameters#nested-parameters 没理解错得话是这个

最大的坑就是别在坑里望着的别人画在上面的饼

办公环境不能再好了

超人性化管理~~~自由 feel

Growing Rails Applications in Practice 这本书不错，对更好的组织项目代码提了很多有用的建议

看了其中一些，收获很多，但是听力太水了 好多都是在意淫 + 脑补

#4 楼 @mango 忽略我吧～～～

芒果竟然到大 ruby 论坛来了～～～

昨晚刚好看了，挺有意思的，就是没发现竟然是 rails tutorial 的作者

看到周末的啦 哈哈

#1 楼 @sanivbyfish
#2 楼 @cisolarix http://www.mikeperham.com/2011/05/04/background-processing-vs-message-queueing/

在重构的时候，不论是瘦 controller，胖 model，还是抽取 model 中的共同业务逻辑到 concern 中还是楼主这篇利用 Service 优化 Fat Model，疑惑把一些功能直接封装成 engine 或者 gem，项目的代码量很难说骤减到一个让人轻易就能掌控的的程度。而且想 concern engine 这种实际运行时代码并没有减少。

然而这么做的目的是为了让程序员能够更好的维护代码，特别是当项目不断拓展业务逻辑，代码里的业务越来越多的时候。我上周看了下 2012 金数据的团队负责人在 rubyconf 分享的东西，说道当项目超过 3000 行的时候就要警觉，考虑将新的业务放到单独的子项目中（其他的忘了）。有点时候到我们手里的代码有诸多限制，譬如表结构等等不能随便动的，或者变动表结构或者做对应的数据迁移工作量太多。那么先让代码更加可控，可维护应该是我们首先关注的了（个人愚见）。

在这过程中利用 Service 优化 Fat Model，其实还可以让 controller 更好的符合 restful 的原则，使 action 的命名可以尽量只用 CRUD 就满足需求，最好的例子就是用户注册了。另外使用 active_type 这个 gem（绝世利器，应该能消除 5 楼的顾虑），可以让 service 逻辑可以使用 activerecord 的验证，避免自己在 model 写回调去验证可能出现的问题（objectsonrails 那本书好像说了，我以前看了一遍没太看懂，第二遍还没看~~，自己可以去研究下）。楼主的转的英文帖子说的太抽象了，一些细节都没说，有兴趣的可以去买《Growing Rails Applications in Practice》这本书详细看看，可以借鉴下。

另外你要有一个巨 NB 的懂架构的头，还有一个巨有远见的产品或者甲方，，感觉这些东西都是细枝末节~~~~（需求天天大变，还重构个毛）

#7 楼 @est 怎么摆弄~~~求科普

简历很好看

#6 楼 @suffering 20 ~ 30 还能接受~~~

40 美刀~~~多厚？

#22 楼 @lidashuang 好 谢了