有没有自己看文档啊，实在没有就自己写啊。

不用。

我很早以前曾花了些时间设置这些。设好了之后才发现自己很少用它。后来才发现，如果代码结构清晰，责任分明，根本不需要这个。

@steveLTN :plus1:

不建议楼主用 14.04，太新了，很多库和第三方脚本没有在 14.04 上测试过。你现在看着没问题，将来有问题还得自己一个个地解决。和核心业务无关，追求新版本完全没有必要。

目前 12.04 就足够好了。14.04 一年以后再考虑吧。

这个确实是生成了 persisted record 的。FactoryGirl.create直接呼叫 model 的 create，生成正常的记录。但build_stubbed就不会。在 controller 测试中用create是正确的。

let是懒方法，不叫不动的。因为你在edit_user_path(user)里面叫了它，所以记录生成了，测试通过。

用let有时要注意的。这个测试没有问题，但你如果测试index, 前面用了let(:user){FactoryGirl.create :users, 5)}, 后面就会通不过，因为你不呼叫记录就不能生成。这时就要用let!强制生成。

遇到过。重新再来就行了。

同学，你能不能学一点 Ruby 基础再来开发 Rails 项目？最基本的 Syntax error 你起码要能自己看出来吧。

兹证明楼主所言属实。

@QueXuQ 我的方法和二楼的没有本质的区别，但你如果有一些功能要依靠第三方 gem 的话，我的会比较方便一点。

比如说，我用 Pundit 做 authorization。Authorization 的逻辑既可以放在 Service 里面，也可以拿出来，我认为逻辑都是合理的。拿出来就可以利用现成的 method 和 controller context，比较方便一点，也比较省代码。但这样你就需要先有一个 product instance

def create
  product = Product.new(params[:rproduct])
  authorize post
  creator = ProductCreator.new(current_user, product)
  # ..
end

product.class 必须是 Prioduct 才能让 Pundit 正确判断。

直接用 Service 代替 instance 就会出现你所说的问题。我比较喜欢把 instance 和 Service 分离，这样@product的 class 不变，其他也不受任何影响。

def create
   product = Product.new(params)
   creator = ProductCreator.new(current_user, product)
   @product = creator.create
   repsond_with @product
end

Service#create里面返回 product, 无论成功还是失败。

@search 不太清楚，你可以看看@haoch的方案，不过这个 gem 也是依赖于 ActiveRecord。

migration 本来就是 ActiveRecord 下面的一个 module。你要说 Rails 的 migration 功能，那就是这个了。我不认为你可以脱离 ActiveRecord 单独使用它。

很多 Sinatra 项目里面也使用 ActiveRecord，没什么不好的。你要不愿意用，可以看看其他 ORM 比如 DataMapper 等等，我不太熟。

require 'activerecord'

这个看起来和 CoffeeScript 差不多，都是缩进，语法也类似。我觉得这个挺好的。

@cassiuschen 我都会些皮毛，不过是很早以前学的。我感觉把那些做好是没有止境的，需要很多的时间和精力。

为什么要用不一样的数据库。谁都可以装 sqlite3, PostgreSQL, MongoDB。

用 PostgreSQL 的话，development 和 test 数据库的用户名和密码留空，默认系统用户。谁都没问题。

Production 和 staging 数据库不靠 database.yml 管理，文件里面有没有无所谓。

如果你要做一些前端工作，严格地说你还是需要 windows 的。有一点无论是 Ubuntu 还是 Mac 都很难代替，那就是调试 IE，哈哈。虽然有一些 image 包，但很难用的。除此之外，Windows 就没用了。

@CN_Boris 放心啦，不会，那样是违法的。一并感谢你的分享经验。

你能做出受欢迎的开源项目也会有人免费赞助 vps 甚至 dedicate server 的。要是不开源的，商业项目就得靠项目自己赚钱罗。

"Photoshop、Adobe Illustrator" 楼主浪费了一些宝贵时间啊

@tumayun @allenfantasy 说是毒药是我说的:) 也有其他的开发者有类似观点的。算是一家之言。

Helper 大致两种，一种属于 ActionController 的，一种属于 ActionView 的，还有一些两者通用的。总之 Helper 是为 ActionController 和 ActionView 服务的，不是为了业务逻辑和具体展示逻辑服务的。

Helpers 用爽了很容易就倾向于，为了简化 View，把展示逻辑包裹进一个 Helper 里面。这个确实也很方便。现行的 Helper module 也是在鼓励这种做法，比如 generator 自动生成 PostHelpers, CommentHelpers 等等。

Helpers 的滥用主要在 Viwe 上面。大量自定义 helpers 造成的结果是：

1. 非 OOP。Helper 是属于 controller 和 view 的，本质上应该和你的 models, 和你的业务无关。

2. 非 OOP 的另一个后果，扩展性和可变性很差。

3. method 泛滥，难维护。不知不觉就写了大把 helpers，稍复杂一点的 helper 还需要 private methods 支持，越来越多。展示一变动，一些 helpers 就孤立了。基本上要靠 ROP(Regex oriented programming) 维护了。

4. 不直观。View 里面看到 helpers, 少一点还好，多了不翻代码还不知道到底输出什么东西。

总之我是尽量避免写 Helpers。我的做法是尽量用 Partials, Decorators, 通用一点的 helper 逻辑也会用 class 再加 helper 接口。实在不能避免也会写，但我发现这种情况很少。

@Kabie Helper 是毒药，除开全局 helper，别的最好少用。至于看 HTML, 那是审美观不同啦，哈哈。

我之前用过一段时间 slim，后来果断改回 ERB。

ERB 的一个重要好处就是，如果逻辑稍微有点多就很难看。这样就可以强迫你在 View 里面只写最少的逻辑。Slim 和 Haml 就没有这个问题，逻辑很流畅，但实际上很糟糕。个人还好一点，团队就更难。

另外，如果要复制一些 CSS 框架的代码，比如 Bootstrap 这些，ERB 很快。其余的要么工具转，要么手工转，总之多一道麻烦。

至于快速输入这些，编辑器加个 ZenCoding，神码都是浮云。

楼主解释一下啊。分享的喜悦大家都看不懂，和单机版有什么区别。