动态表单最麻烦的在于字段特殊处理，例如对字段有特殊的编辑或者显示需求，就需要添加例外情况来处理。不知道关于这点，作者有什么好办法？

哈哈，我理解收到不合适的简历会浪费时间，不过没必要置顶告知。这个论坛的人还是比较讲究规范的，纯属建议，不喜勿喷。

看来本论坛还是喜欢比较俗一些的描述（直接写明薪资范围）😊。

居然这么早的问题都被翻出来。

我倒是认为研究前端是不得已的选择。

Ruby 作为一名后端语言，拼性能拼不过 java，C ++，做客户端比不上 Object-C，C #, 。虽然拥有开发速度快，代码优雅等高级技能，但是由于语言小众，让很多大企业又望而却步，所以这几年的发展一直不能有很大突破。

但是依托于 Rails 这一强大框架，我们有了另外一个标签：全栈。所以为了进一步扩大影响力，我们可以在前端上多多扩展，甚至于达到后端包围前端，甚至达到全端 Ruby 的曲线战略。Rails 近几年的发展变化也体现了这一趋势。

另外，如果你没有主动接触前端，等到前端成熟了，Rails 只能作为一个 API 服务又还有什么优势。等到那时候来追悔莫及，不如趁早渗漏进去，在前端界占据一席之地。

看上去，可能是没有 jquery-rails，但是 application.js 里面又使用了 jquery。

《战狼 2》也有大疆的身影：https://zhihu.com/question/50171698/answer/205752592 果然是消费级无人机的扛把子。

错误提示很明显啊。不行的话就在出错的地方调试：https://github.com/redis/redis-rb/blob/v3.3.1/lib/redis/client.rb#L121

CDN 应该是缓存了资源，而不是缓存了请求吧。

看得出来，你挺喜欢“智障”。😄

最可怕的不是 WALL，而是 WALL 后面逐渐妥协和习惯的心。

--- 读帖有感

让人印象深刻的头像，不久前看到过发招聘。

active model serializers 的性能其实并不怎么样，而且一不小心就会混入额外的查询。建议看序列化时生成的日志。

仔细看了一遍代码，说实话，没有发现这样做有很大的好处？功能比较微妙，大多数应用里面可能都不需要这么做，或者不需要这么复杂。

按照 Ruby 的查找逻辑，如果做同名检测的话，性能估计会很差吧，难以想象每个方法都需要遍历一遍继承树。

居然离我住的地方如此之近，可惜了。

不要伤心，站起来😄

效率好给力

可以自己加入。PS: 回复某楼的功能坏了？

悄悄地，你来杭州了。

我可以认为你只是找个借口写 Golang.

所以你们其实是用 int 记录了日期，作为日期快速查询，更精确的时间并没有用 int 表示？

看上去，用 int 来代替 datetime，性能有了很大的提升？

你们是在什么规模的情况下改用 int 存储的？有没有这方面经验可以分享？

正好没事，去转转。

在不同的目录下，分别创建项目，使用不同的 Gemfile。

理论上可行。不过 Object#define_singleton_method 是 C 的实现，所以你可能需要 ffi。

但，为什么不直接升级到 2.0

好赞，一个好的工位对于自由办公的人有莫大吸引力。

碰到某些特殊情况就是坑了。

比如说 IP 地址判断地区，由于目前不存在覆盖率 100% 的 IP 库，所以必然会出现某个 IP 关联的地址为空，这时候如果使用了 belongs_to，坑你没商量。

好东西，不过我当时看的是《当幸福来敲门》，大男人都忍不住掉眼泪。

说说自己的故事。

我大学计算机学了三年，去找实习工作，没提任何薪资要求的情况下，依然被拒绝了十一次，最后只能靠励志电影鼓励自己。