这样需要配别的什么东西一起用吧，否则谁来处理前端资源优化、压缩的任务呢？

我实在不想折腾前端，能省则省。

Turbolinks 的事件处理

不能好好的写$(document).on('ready', function() {})，要写成page: change，后来又改成page: load，最近升级到 Rails5，还要改写成turbolinks: load。

然而前端是我的弱项，从一个坑跳到另一个坑里，天知道我经历了什么……

当然，告诉了。

我一路自学 Rails，看到这个东西的时候就知道不能用。。

感谢！

我之前写的确实不对，这次受教了。

我先去参考一下 Homeland 的 Dockerfile。

嗯那就是我道行还不够深，先把 Dockerfile 写对了，再考虑用进去。

容器部署的调度工具我也是昨天才想到这个问题，脑子里转了一圈发现周围没什么好用的。至于提升运维能力，这得看公司发展，我自己心很大，但这不是我一厢情愿就能做成的事情。

没有，只是用 Puma 起了多线程。

是我没讲清楚。 我目前不用 Docker 是有原因的：

1. 微服务的拆分与持续维护的成本，在我看来是不可估量的。
2. 每次 Build image，会在 image 内部重新 bundle install，就有可能引起依赖软件的版本变化，就有可能引入未知的新的 bug，且排查成本较高。而这种 bug 在常规开发/部署的方式中几乎不存在，即使有也能很快定位到问题。
3. 在企业中不能脱离人员架构讲技术。我可以自己用起来 Docker，但总有人不是那么熟练；不论是培训、技术转型还是后期维护都会有成本，这种成本现阶段是完全不必要的。

docker 也有 docker 的成本，业务没那么复杂的时候，Docker 有点大材小用。

上面那段 nginx 的配置在 development 环境中如何体现？

难免扣除了印象分，今后共事会带有先入为主的看法。

公司缺人呗，想着有 x 年经验即使没什么出彩的也不会太差，没想到坑了。

Rails Guide 里有很清楚地讲到这两个用法的区别和使用场景。

然而提示了。

这个不方便讲，不过不算少。

本身多对多关系就是需要中间表，不论是否承载独立业务，不论是在哪个语言、哪个框架中。has_many_and_belongs_to只是框架上的封装，RDB 里该怎么样还要怎么样。我觉得这些也是 Web 后端开发者的常识吧，与框架无关。

同没用过。感觉这个函数是给新手用的，太过简单，不符合业务场景。

嗯，以后也得这么搞。

嗯是的。

我敢保证那天下午一定不是“人多的聚会”的场景，聚会的氛围和忙碌的 Office 的氛围完全不同。

另外，遇见这样的开发者也算是小概率事件吧。

这得是多脆弱。。。

就是因为有这么一个下午的时间，还有 error log 的提示，我才觉得无法理解/接受。

我也不敢保证自己能什么都不忘，但很基本的东西，又加上充足的时间和提示，再怎么忘也都该想起来了。

不排除，但小公司考证不来。

怎么讲？

兄弟我多问一句，这个价值观是怎么看出来的？

既然你能理解has_many_and_belongs_to，那么如果实体 A、B 之间存在多个“多对多”的关系，你这一个has_many_and_belongs_to就完全不够用了，这时候就该用has_many through了。

最简单的理解，就这样。

我上面所说的，是我对 PM 和研发的职责划分。我能在一定程度上做好自己职责之内的事，但 PM 那边做不到、又管不了，这是我这边的问题。

这套思路是我最近理清楚的，还没来得及推行。要让整个团队都认同这个观点，大概会比较难。

受教了。