写得很好 学习到了

https://ruby-china.org/topics/1020

是不是这样用更好一些呢？

User.includes(topic_users: :topic)

嗯 一直在做的内容 特别是前后端分离的时候 非常的不想要 prefix attribute name. 如果是自定义验证方法 通过errors.add() 方法添加错误信息 其实是可以包装错误 采用 I18n 的方式输出我们想要的错误信息的

# 例如
erros.details  #=> {:customer=>[{:error=>:blank}], :identification_type=>[{:error=>:blank}]}

errors.add(:identification_type, :custom_error, message: "Custom Error")   # => ["can't be blank", "Custom Error"] 

# 再次输出
errors.details #=> {:customer=>[{:error=>:blank}], :identification_type=>[{:error=>:blank}, {:error=>:custom_error}]} 
errors.messages # => {:customer=>["must exist"], :identification_type=>["can't be blank", "Custom Error"]}

我的想法是采用 I18n 的方式包装输出 需要的错误信息

update_attributes 只算是实例方法 我觉得让别人来调用你的实例方法是不安全的 这个方法还可以写 并不是只读方法 只读方法 随便调无所谓 单一涉及到写操作 就会出现一些问题 两个系统之间 相互更新的用实例方法就不可控了

代码风格统一 是不希望了 就是一些东西还是遵从一个标准好阅读一点 为什么我特别支持选用接口和消息的方式去更新呢 很大一部分取决于系统架构 采用微服务的架构 通过消息解耦模块 各个模块之间可以单独更新而不影响其他模块 但是实施起来要求技术成本有点高

在硬件越来越好的情况下 能更快的写出代码 我选择 ES6

高冷的 vim 党

感谢回复 现在大部分时间都在 windows 平台上撸代码 通过 sftp 传代码到服务器 所以没遇到你们说的 linux 不支持中文的情况
在 Windows 上编码主要还是有很多文件要写 工作环境限制只能用 windows 系统 以后在 inux 上开发可能会换 vscode 吧

简历已发 大数据方向挺不错的

其实我说的不可预测是指的 线程调度不可预测 线程调度不可预测 所以我觉得不能用共享变量来参与计算 顶多是起到一个计数作用 例如：

@a = 1
10.times do |e|
Thread.new {
   @c = 1
   @c += @a
}
p "#{e}  #{@c}"
end

这段代码的输出就依赖 线程调度 不同的线程调度会出现不同的输出

这个跟 redis 的原子操作没有关系

redis 现在正在看 redis 的原子操作只能保证 写是唯一的 最终的值是我们预期的 但是中间过程还是不可预测的吧

共享变量的问题 多个线程共用一个变量 这个过程是不可预测的 要想不出错貌似只能读不能写 除非能做到线程之间同步和互斥 要不以后可能就会出现一堆 bug

由潜入深 首先是暴力算法 之后通过空间换时间的思想加快了速度 最后更是通过线性同余算法再次优化了内存空间 减少了空间分配 分配更均匀 其实这和我们软件开发是一样的 先是简单实现 然后逐步迭代