一种可能性而已... 心理素质不佳也算减分项呀

噗 楼上有位去人多的聚会就会😂

环境不同，紧张，临场发挥失常

和求职者心理素质也有关系

不知道要怎么说了。。。 @kgen 对这种事怎么交涉有啥经验么...

这答复也是无懈可击，没法反驳...

我在家（北京联通）测试东京 1 机房比 2 快了快十倍... 但是 1 不让迁进去了

你更新到原文上嘛...

继续抛砖引玉哇

必须啊... github flavored markdown

来啊

是的，从另一方面来讲，role.permissions = {read: false} 这样做改变了 permissions 的类型是很合乎逻辑的行为，Ruby 鸭子类型嘛！

但是，write_attributes 等行为也会改变 permissions 的数据类型，这就涉及到 ActiveModel 的相关的原理了，他底层是用 public_send "#{attribute}=", val 来实现更新数据的行为，所以这里有抽象泄露。

总之是个比较高级的特性了，用好很强大，提另一种用法，来自 Redmine： https://github.com/edavis10/redmine/blob/master/app/models/role.rb#L77

但是需要注意的问题也很多，这里有抽象泄露，得对 ActiveModel 有一些了解才能正确实现，提一种坑

class Role < ApplicationRecord
  def permissions
    @_permissions ||= Permissions.new read_attribute(:permissions)
  end
end

role = Role.new
role.permissions.class #=> Permissions 这是我们期望的
role.permissions = {read: false} # 或者 role.update_attributes permissions: {} 前端表单提交可能会这么写
role.permissions.class #=> Hash 注意！

默认是 YAML，你发的文档有提的。

他不是不推荐，这里确实有坑，举个例子，你可以持久化成 JSON，但是 JSON 和 Ruby 的数据类型没法一一对应，没有考虑到这点（主要是说 Coder 要处理好类型转换，包括字段为 nil 之类种种边界情况），就会出问题，所以在使用的时候要小心。

这个不冲突的呀，serialize 只决定把某个字段映射成什么类，最后持久化成什么样是 Coder 来控制的，存成 hstore 没有任何问题

况且，serialize 可以把字段映射成一个具体的类，可以有效的封装状态行为验证等等

想它的价值得把存储数据和应用数据分成两件事来看待

效率可能低，但是功能非常强大，serialize 只是一种标准实践，封装了形如

class Role < ApplicationRecord
  def permissions
    @_permissions ||= Permissions.new read_attribute(:permissions)
  end
end

这种将某字段作为虚拟模型的模式，那能做到多强大就看需要和想象力了

Rails 只是为一些简单场景（比如数组、哈希）做了开箱即用的实现，Rails 推崇 PG，还有 PG 支持 Array 这些数据类型比 Rails 提供这方面支持可晚了一些，这里有点历史原因在的

store 和利用 hstore 之类的数据库特性不冲突的，序列化和反序列化是由 coder 完成，可以自己定制

没错的，他说 == 等价于（Equivalent） <=> 所以后边就全用 <=> 来举例用法了，Ruby 为了让你用着爽，为很多方法提供了常见的别名 （通过 alias_method），典型的还有 count、size、length，Rails 里也有不少，在文档上，就取其中一种来做示例了

serialize 现在也有，其实你看看 store 的源码就知道怎么回事了

def store(store_attribute, options = {})
  serialize store_attribute, IndifferentCoder.new(options[:coder])
  store_accessor(store_attribute, options[:accessors]) if options.has_key? :accessors
end

简单场景下的 serialize 的封装

不能...我各个地方都表态用电脑是件非常神圣的事情...要先洗手...手打油了重新洗手，用电脑时不吃零食...

转载过来吧！

那个键盘质量不高的，就工作敲代码用...然后几个键就失灵了

勤奋！

好键盘啊，就是做工质量太次，我从 13 年到去年中用废两把了...去年又买了一把做工改进不少

肯定算大型项目了 Gitlab 还拆了好多到子项目里去，包括 Redmine 模型的代码都不多的，模型只能算核心数据结构吧，这几个项目的 lib 目录都是大头...

Gitlab 更工整一些，Discourse 那个太乱了。。

那俩实际比模型数复杂的多吧... 最近刚好在看

凶残了...

我的 mac mini 要半个小时多吧

KO 也肯定超过 50 了... 知人这边是因为企业系统，模型围绕业务做的，业务多了模型数量就上去了... 不过可能那统计有水分，不少都是虚拟模型应该

+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Controllers          |  14970 |  12206 |     321 |    2080 |   6 |     3 |
| Helpers              |   3017 |   2631 |       0 |     270 |   0 |     7 |
| Jobs                 |   1534 |   1256 |      63 |     122 |   1 |     8 |
| Models               |  42755 |  30393 |     495 |    3063 |   6 |     7 |
| Mailers              |    199 |    166 |      10 |      16 |   1 |     8 |
| Javascripts          |   7686 |   5926 |     182 |    1165 |   6 |     3 |
| Libraries            |  16079 |  13358 |     145 |    1151 |   7 |     9 |
| Tasks                |   3899 |   3405 |       4 |      73 |  18 |    44 |
| Controller tests     |   8885 |   7331 |     207 |     948 |   4 |     5 |
| Helper tests         |    329 |    255 |      15 |      27 |   1 |     7 |
| Model tests          |  25440 |  20199 |     317 |    1751 |   5 |     9 |
| Mailer tests         |    136 |    112 |       9 |      18 |   2 |     4 |
| Job tests            |    798 |    645 |      25 |      78 |   3 |     6 |
| Integration tests    |    205 |    155 |       2 |      17 |   8 |     7 |
+----------------------+--------+--------+---------+---------+-----+-------+
| Total                | 125932 |  98038 |    1795 |   10779 |   6 |     7 |
+----------------------+--------+--------+---------+---------+-----+-------+
  Code LOC: 69341     Test LOC: 28697     Code to Test Ratio: 1:0.4

知人的，其实 KnewOne 项目全部代码量比这个还多... 没存代码就是