你新改过的逻辑的通常写法是用||=

foo ||= Brand.find_by :cn_name, value

抬头，做直，双手放在键盘上，眼睛看着屏幕。好了，现在你可以用这个正确的姿势来传递 hash 参数了。

@dddd1919 这个没什么特别的吧，和 Rails engine 差不多啊，"You can think of mountable applications as a‘full-featured’merb slice or rails engine."

这种页面单独 CSS 是一个甜蜜的坑，一开始一般都是为了快速解决某个问题，尝到甜头后就继续，然后就越写越多，应用页面越来越多，不能复用的 selectors 也越来越多，最后就。。。好一点的结果是花相当多不必要的时间在 CSS 上，坏一点的结果是需求变更，想换一些风格，然后就。。嘭

@vincent 。。。。。。。

@QueXuQ 正常理解的话，静态图片应该是全局化的，那这块就不要用 handlerbars 输出了，如果可能，直接在 layout html 里面做。

如果不是全局化的图片，那这些图片肯定是和特定页面有关的，所以。。。还是用 JSON 吧。

handlerbars 只是 template, 你用的 Javascript 方案是什么。

如果前端是用 JSON 来获取数据的话，呼叫 API，让 Rails API 给出 image_tag 就可以了。

好文。

再补充一个关于 link/denormalize/cache 的观点，来自 Sarah(Dispora 主要开发者之一) 的一篇文章： http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

Dispora 最初是基于 MongoDB 开发的，后来因 production 中的种种问题，后来被迫转到了关系型数据库。

Denormalization 是 MongoDB 的特定，但同时也是一个应用场景的很大限制。

有一段是关于 link(relationship) 的

Whether you’re duplicating critical data (ugh), or using references and doing joins in your application code (double ugh), when you have links between documents, you’ve outgrown MongoDB. .... If your data looks like that, you’ve got documents. Congratulations! It’s a good use case for Mongo. But if there’s value in the links between documents, then you don’t actually have documents. MongoDB is not the right solution for you

她认为 MongoDB 的 denormalize 在本质上就是 cache, 而把 cache 和实质数据存储混在一个层面有很大的问题。如果用关系型数据库，大不了使用核武器 -- 摧毁所有 cache 然后重建。但混在一起的话连这个核武器都没有了。

You can always delete the entire activity stream record out of your cache and regenerate it from your consistent backing store. It may be slow, but at least it’s possible.

What if there is no backing store? What if you skip step 1? What if the cache is all you have?

When MongoDB is all you have, it’s a cache with no backing store behind it. It will become inconsistent. Not eventually consistent — just plain, flat-out inconsistent, for all time. At that point, you have no options. Not even a nuclear one. You have no way to regenerate the data in a consistent state.

When Diaspora decided to store social data in MongoDB, we were conflating a database with a cache. Databases and caches are very different things. They have very different ideas about permanence, transience, duplication, references, data integrity, and speed.

不相关人士路过。略为提醒一下楼主，展示在公司内部做的项目可能不太合适。

@flowerwrong 用 Fireworks 就可以做，一幅幅画好，然后设好顺序和帧数就可以了。

@5swords 你多虑了:) 真没必要想得这么复杂。

关于耦合，我举个例子吧，测试用户发帖功能。这个测试肯定要求用户是已经登录的，通常做法就是一个快速的 session helper 模拟登录，不会去跑过登录界面。那样一个是费时，二个就是耦合。登录部分出错并不意味着发帖也有问题。但是过 GUI 的话两个测试都会出错。另外，要过 GUI 就意味着你必须先写写好完登录的代码，而不能团队里一人写登录，一人写发帖，或者先写发帖。

卷起袖子先写吧，具体问题具体分析。总是会越写经验越丰富的。

http://www.google.com

看看那个 gem 的 model 是如何实现的。然后去掉 gem，自己写 model, 自己写前端。

@5swords 不客气。集成测试其实成本比较高，一个方面是慢，另一个方面是维护很耗时。我觉得除非实在必要，否则尽量少写。

数据方面，只有本测试有直接关系的才需要用户生成。比如要求是填一个表单，提交后在界面上看到相应效果。这个表单的数据就需要模拟用户行为。其他数据只能在后台生成，没法都过 GUI, 否则一个个过 GUI 那个时间你是会吐血的，而且测试之间耦合太高。

1. 都可以。空数据库就用 FactoryGirl 或类似，基础数据的就是 Rails 传统的 fixture。
2. 生成。fixture 是在 yml 里面事先定义好所有的。FactoryGirl 有专门的 DSL 生成，看文档就知道了。
3. 复原。我是用 database cleander 和 FactoryGirl 搭配，在 spec_helper 或者 test_helper 里面定义。用 truncation 策略。
4. 不可以。Example 之间必须清空。CRUD 不算严格的集成测试，只能算功能测试，是必须清空的。但在做模拟用户的集成测试时，为保证连续性，可以在一个 example 里面执行多个步骤。

@Yujing_Z 帐不是这么算的，谁都不会天生各个方面都会做。累在积累经验和学习技术。比方说 1000 小时集中在某个专题上你可能可以成为专家，但如果时间分散开来，各个方面都只会是泛泛。更不要说之后的技术跟进了。

这些 filter 原理其实都很简单，用一个 instance variable 或 class variable，设为空 array, 定义一个 DSL 以 symbol 格式推入 method name，用的时候遍历 array, 一个个 send。稍难一点的地方在于判断是否需要线程安全。因为 class variable 最简单，但不是线程安全的。

@iamzhangdabei 开发环境和测试环境其实都无所谓，开发环境有 seed，测试环境是空的，删就删了，一点问题都没有。生产环境我个人的建议是最好不要用 console 管理数据，而是以 GUI 和 rake 为主，以保持数据一致性。

不怎么样。monkey patching 库代码是很丑的。另外，在某些情况下你可能确实需要 delete_all。与其改写库代码，不如加一个 module 定义软删除，然后需要的 model 可以应用这个行为。

@kgen 可能台湾人才会觉得蓝绿对战比较自然吧，正常来说好像很少这两种颜色作对的。

产品设计很有可能是台湾人

@badboy 这个正方形方案好聪明。

用户表包括用户的登录信息，密码、用户名、邮箱等等。如需改动，需要比较严格的认证，比如输入密码、邮件认证等等。

用户详细信息可以让用户自由改动，无需认证。

这就是分成两个表和两个 model 的好处。

这些都是基本的东西，学 Rails 也包括学 gems。既然你自认是新手，就应该把知识的杯子放空，先接受，再来取舍。基本都没有掌握，“实现”多数情况下也是一团乱麻。

@wuwx 你说得对，我忘了 CanCan 可以用 block。

@Peter @lzyfn123 这些 gems 都可以做动态，不过我还是喜欢 Pundit, 胜在简单明确灵活。

@Peter 谢谢讨论。我刚看了你引用的 ruby-china 的帖子，我觉得那个情景的“动态”还不能称之为真正的动态，因为规则很少也方便全部加载。真正的动态是像你说的这个场景。有 GUI，有数据库表，而且数据可能会非常多。还有类似的例子就是在 github 给一个用户授予 repo 的权限，数据是海量的。

我没有实际做过这个动态。但这种用 CanCan 来做实际上可能会比较麻烦。我不知道 CanCanCan 是怎么做的，但在 CanCan 里面，所有的 ability 其实会被执行并放入一个 instance 里面。如果有大量动态数据，这个 instance 的大小可以想见肯定无法接受。

Pundit 一样可以做动态，而且可以很灵活。

就拿你说的例子吧，比如 current_user 要创建一个联系人，那么此时就要查看他是否有权限做这个。权限是动态储存在数据库里面的。

# ContactsController
def create
  @contact = Contact.new(contact_params)
  authorize! @contact
  # ...
end

Pundit 这个authorize!很漂亮，不管静态动态，反正所有的判断逻辑都会封装到 policy 里面。

然后定义一个 Authority model，这个可以从你设定的 GUI 里面 CRUD

class Authority < ActiveRecord::Base
  # :user_id
  # :action
  # :subject
end

然后 Policy

class ContactPolicy
  attr_reader :user, :obj

  def initialize(user, obj)
    @user = user
    @obj = obj
  end

  def create?
    return true if Authority.find_by user_id: @user.id, action: 'create', subject: 'Contact'
    false
  end
end

这样就可以了，如果是 false 的话 Pundit 会扔出一个错误，然后在 controller 里面设定 rescue 就行了。

有，用 Pundit，很灵活的。CanCan 的假设太多了。

@nightire 用合适的技术做合适的事情就行了。

楼主要加空格干什么，这个是百分之百是 CSS 的职责。Markup 里面要避免这些无意义的东西。

这些 tag 明显和前面的链接是不同的类别，你给它们另加一个 class 比如 label-tag, 然后.label-tag: {margin-right: 10px}就可以了。