当然 既然知道术语 scheduler 了，那也可以利用这个关键词去寻找适合的 gem

定时器英文就是 scheduler 了，一般异步任务队列可以解决，通过 ActiveJob perform_later 来解决，后端接 sidekiq，你的触发器的逻辑要自己去处理

增加了资源选择字段的演示~

麻烦杭州那边安排大会前一天和第一天晚上的活动啦，找个地方可以聊聊天啥的

还没结婚哈，她还在美国读书的说~

重点错了

确实高了不少，前两年的场地我都控制在 4w 以内了，今年贵了一倍多的样子

老样子...

CC @huacnlee

我没实际写过 Ecto，但看你的代码，感觉跟我在 dummy 里的道理是一样的，总之原则就是：显式定义 schema；避免脏数据；结构化设计；数据的可读性。

@hooopo 觉得这种配置字段完全是可以分别单独建表的，可读性最佳，并且可以在数据库层面保证约束完整性

前端苦手...

其实好奇你们怎么做的问题间跳转的，看巧思 cform 的问卷设计器，很像我们的工作流的各道审批流转，我下一步计划是规则引擎、工作流引擎，还没什么头绪但是，知人这块味做的味道不是很好。

我和 @hooopo 讨论过这个问题，我俩的结论是，像我在 dummy 演示的做法（为额外属性建模但最终序列化入某列）可以，但是是反模式，用 jsonb 道理也是一样的，反模式在于这样做没办法定义一个很强的 schema，项目长久下来的维护会成为问题。

有可能的话，最好的做法还是为这些扩展属性建立实体模型。

https://github.com/jhollinger/otr-activerecord

最好一步到位 utf8mb4 否则遇到 emoji 还是会吃瘪

直接来就可以

不是，是 拷贝过来，自主研发 的缩写~

你有没有什么样的场景也可以讲下，Demo 是我对照金数据的功能来做的，想象不到的需求估计做出来也没有参考价值，所以就没去做

脚手架的生成器的源码在 https://github.com/rails/rails/tree/master/railties/lib/rails/generators/rails/scaffold 复制过来魔改一通就好了

我们现在是把整体序列化，老系统是这样做的，而且也没有更复杂的查询上的需求了。

我以后有机会的话，会在 demo 里实现持久化吧，最近的工作确实写了套 EAV 相关的东西...

这楼主首先聪明，其次是真的有热忱投入在编程这件事上，再其次他结实了一群比他还聪明（或者有成就）的志同道合的朋友

他的成长路线还是没法复制的，但是，保持好奇心，多实践，提高知识面，对于提高编程能力的作用是显而易见的

我都行，当替补嘛

可以呀

我一会拉个讲师群吧，我都认识的

地点还没选好啊~ 看来得在群里吼一下了

ApplicationRecord 长这样

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

这个是把最佳实践放进新项目的模板里，跟用 Rails 几无关

Rails 5 开始，会在 app/models 目录下额外创建一个模型基类 class ApplicationRecord < ActiveRecord::Base，你直接效仿，然后把你的公共逻辑放在里面即可，然后让你所有模型继承这个 ApplicationRecord

params 理论上跟一个 Hash 差不多，如果你想删除某个 key，params.delete :flag 就可以了，返回值是 :flag 的值。

这里如果你的查询很复杂，建议你实现一个简单的 QueryModel 类来实现，类似于

class QueryModel
  attr_accessor :flag, :keyword

  def initialize(params = {})
    params.each do |k, v|
       send :"#{k}=", v
    end
  end

  def to_query
    query = Model.all
    if flag
      query = query.where()
    end
    query
  end
end

不用写太好看，但是结构就干净好多了

另外，真假值转换用 ActiveModel::Type.lookup(:boolean).cast(value)，包括数字之类的类型，都有对应的转换类