@zhaozijie @davidzhu001 @lips @kgen @nightire @Rei @cuterxy @hooooopo @ywjno @peter @blacktulip 坑已填完，多谢捧场。让评论来得更猛烈些吧。 btw，如果按照中学论文的标准，俺这个论点、论据、论证都算不错吧，既提出了问题，也解决了问题，是不是可以在讲台上当做范文来念？嘿嘿，至于精华不精华，班组你自己看着办……

#27 楼 @hooooopo 我感觉是人为干涉的，人工置顶而已

#25 楼 @hooooopo 哈哈，多谢捧场，接孩子回来了，继续填坑…… 不过我很好奇 ruby china 上首页的推荐算法，为啥俺码这么多字，都上不去，难道就因为黑了 Rails？

@zhaozijie @blacktulip @lips @kgen @nightire @Rei @cuterxy 主贴有更新，但是因为急事又没填完，sorry 啊，待会儿继续，哈哈哈……

#19 楼 @cuterxy 问题就在于需要开发者做很多额外工作才能集成，这会带来一系列的问题，比如插件版本升级，我后面会对这一点做详细说明的。

#18 楼 @Rei debug 一下，其实这段代码不符合 dom 幂等操作：

$(document).on 'page:change', ->
  $('textarea[data-behaviors="editor"]').editor() # a jquery plugin

如果这个 plugin 在设计的时候没考虑到避免多次初始化，那么，同样会遇到我说的问题（当然很多 jq 插件是没这个问题的，但情况很多，谁也无法保证别人的代码万无一失），这就是为啥要吐槽的原因，Rails 崇尚最小惊讶，在这点上却非常让人惊讶，“以前的代码完全没问题，现在怎么这样了？”呵呵。

#18 楼 @Rei 确实，操作 dom 是上一个时代的思维，这方面我比较关注 web component，以及 react.js

#16 楼 @cuterxy 请为维护老系统的程序员考虑，某些应用在 rails 3 时代就开发了，现在升级到新版，很蛋疼的。还有就是，作为开发人员，你能保证自己的代码按照 rails 的要求来，但是三方插件呢，特别是那些 ui 库，如果没有人做 assets pipeline 兼容的 gem 包，要集成进来这的好累，我后续会就这个问题讨伐 Assets Pipeline！

#11 楼 @Rei 请看主贴，我会不断的扩充这个帖子，欢迎继续热烈讨论。

#13 楼 @cuterxy 因为 rails tut 上说了，你以前的 ready 事件现在不能用了，改成 page:change。如果你不用这个事件，那么只能这样：同时监听 ready 跟 page:load，因为第一次显示页面的时候，只会触发 ready，然后接下来由于 Turbolinks 的原理，真正换页面了会触发 load，所以方案二是这样的：

$(document).on 'ready, page:load' ->
  #你的初始化代码

但是真的问题在哪里？作为前端开发者，我 tm 为什么要去管某个 attach even 或者别的什么 dom 操作是不是幂等的？以前没有 Turbolinks 的时候，可不需要闲操心……

至于 delegate 方式，不是无懈可击的，你知道的 ujs 就是通过取消冒泡来阻止 Trubolinks 瞎捣乱的。

#7 楼 @Rei 至于 ajax 请求为啥会 redirect，那是因为很多事情，json response 并不是最佳方案，详情可以看 the rails way 的 ajax 章节，你不会想前后端重复某些业务逻辑的。对我来说，响应 html 片段代码能直接用 form helper，还能利用 ujs 来处理后续的请求，为何还要响应 json，然后让客户端 js 来组织界面，还要注意 CSRF 的问题。比方说购物车，我界面上修改了数量，ajax 发给服务器，处理好之后直接把这个购物车的 html 再返回来就好，不是么？这个时候你就会遇到，修改了资源，然后需要 redirect 成 get 的情况了。万事皆有可能，只不过某些人先掉坑里，然后跑出来告诉别人小心点，仅此而已。

#7 楼 @Rei Controller 就是 service 层？？？OMG……

service 层的存在，首先是要解决逻辑归宿的问题，另一个巨大的优点就是，通过抽象出这个层面，你可以极大的提升代码可重用性！比方说，我现在的系统有 web 界面，好，我用 rails，然后抽象出了服务层。某一天，我的 boss 蛋疼说要做桌面版 GUI，在前面的基础上，我可以直接把 service copy 过来用，如果你把 controller 层当服务层，因为纠缠了 http 的东西，别做梦了……

@darkbaby123 啊哈，服务层设计，欢迎楼主来参与吐槽盖楼： https://ruby-china.org/topics/24742

#25 楼 @stephen 是的，图画错了

可以远程么，嘿嘿……

@mogod 没有看过 ecshop 的源码，貌似是 php 的？期待了解的朋友分享感受：）

@stephen 没错，我再来加一点最关键，也是最吸引我的：

3、spree 采用 rails engines 来拆分子模块，开发者可以根据需要灵活选择组合实现业务功能，这是社区目前比较流行的架构方式（Modular Architecture，也有人称之为 Component-based Application），基于这种方式，每个子模块都是独立的 gem 包，可以重用到不同的场合。还记得大明湖畔的 devise 么？它也是个 rails engine gem，用户登录基本上是每个 web 应用必备的功能，每次新开发项目都要重复一遍是很蛋疼的事儿，devise 通过将自己打包为 mountable 的 engine 提供给程序员，做到的最大的可重用性，但是 spree 则更进一步，将一个具体的业务领域（电子商务）用同样的模块化架构来实现，并开源，多么美好……

目前我在自己的项目中也在学习运用这种方式来组织功能模块，目前遇到的问题是，这样会打破很多 rails 约定俗成的惯例，也就是不符合 COC 原则，确实有点蛋疼，大概需要更高层次的架构水平，以及对整个开发过程有深入的理解，提高熟练程度才能得心应手吧。换句话说，新手请绕道，日后再说吧：）

@mogodb @zhaozijie

我们后续会增加对其他模块的源码分析，以及整个 gem 是如何组装起来，实现模块化架构的原理，敬请期待。

#15 楼 @andor_chen 图灵社区的读者一样给优惠码吧？

#13 楼 @andor_chen 很奇怪，为啥有关 Engines 的介绍没有被收录到指南中，官方就没有： http://guides.rubyonrails.org/engines.html 希望中文版能补上这篇，包括目录和翻译。

@ruohanc 暂时还木有

恩，会及时跟进。

我是这本书的中英文双版审校者，大家在阅读的过程中有什么建议或意见都可以发到我邮箱，谢谢：chen.ruijie#gmail.com

beta 版已经出来了：http://pragprog.com/book/ppmetr2/metaprogramming-ruby

@lukew 原因在那个评论里面已经写得很清楚了……

时至今日，个人觉得 prag 社的那本《agile rails》已经不合时宜了，《Ruby on Rails 3 Tutorial》才是入门首选，因为他不仅仅教你 rails 怎么用，更教会了你如何去正确使用 rails。

很多年前我就评价过了，那会儿还是第一版： http://book.douban.com/review/4654745/ 作为一名八年 rails 使用经验的 coder，个人建议的阅读顺序如下——

1. rails tuts
2. rails guide
3. rails way
4. crafting rails

翻出 Peepcode 邀请 Jim 录制的 Play by Play 视频看，真是世事难料啊……

楼主，推荐用这个来监听文件系统，轮训太蛋疼了： https://github.com/guard/listen

英文版作者写的进度是 75%……

@andor_chen 说好的优惠呢？