何以见得？

假如还不能开始使用容器化方案（如 Docker）的话，至少也考虑用配置管理（如 Ansible）。而且还能搜到现成的方案：https://github.com/j-mcnally/ansible-rails

与问题是否简单无关。因为，呃，如果你读过了我给出的链接所指向的那一段你就知道原因了。我这边就不再复制粘贴。

既然你 @ 的人里不包括我，那么看来我也没有资格回答这个问题了。

再者，这个问题看上去就像是家庭作业。

一个建议：不要使用粗体。

愿意认真给你答案的人，肯定也愿意认真阅读你的问题。加粗所传达出的信息是“我知道你们都不会认真阅读，所以只读我加粗的重点就好了”。相关吐槽：https://programnt.github.io/design/2017/10/24/bold-bold-bold.html

回到主题，遇到这种问题我的解决方法是：

• 如果在构建过程能生成配置文件（比如 configs 目录下的文件），或者配置文件都是提交进仓库的，无视它。反正也就是项目根目录里多一个文件而已。
• 自己 fork 过来重写。反正 libs 文件夹里一共俩文件，加一块儿也就 50 来行。自己维护也没什么大不了的。
• 因为这个库检测/加载 qq_secrets.yml 秘密文件用的是 File.exist? 和 YAML.load_file，而 f 变量的值是个相对路径。也就是说这个库寻找秘密文件的逻辑是依赖于当前工作目录的（这个行为本身就不靠谱），而不是项目根目录。那么你可以在加载这个库时临时切换当前工作目录。虽然算不上是利用了高级语言特性的元编程，不过至少做到了不改动第三方代码就能让它的行为满足你的期望。

多年 Vim 用户，现在在用 Neovim。

曾经有一次想切换到 Emacs + Evil 玩玩，结果发现太多的功能 / 插件都需要找到对应的实现，并且从头学习快捷键，旧习惯太难改，果断放弃了。现在还依然模糊地记得 Emacs 的很多快捷键的助记性（Mnemonic）太差，实在记不住。不过年头太久了，这个模糊的记忆也许不太可靠。

现在又过了这么些年，估计转换难度已经低了些，也许有时间会试试 Spacemacs 吧。

帖子的分类是新手问题，那么问题在哪里呢？还是说只是意外地选错了分类？

要买技术书籍的话，很多出版商都是自己开网店直接卖电子版的：Apress，No Starch Press，PACKT，Manning。你提到的图灵和 The Pragmatic Bookshelf 都属于这一类。

OReilly 虽然是一家挺大的出版商，但他们好像在主推按月付费的 Safari Books 服务，不再单独售卖 DRM-free 的电子版了。正在无耻地读盗版。

再就是 Humble Bundle 上总是有打包便宜卖的电子书，但不一定是技术书。

这个行为能在 5.1 版（严格来说是 5.0 就希望引入，但由于 bug 被推迟到 5.1）被引入，就给我感觉 NPM 的开发团队有点不太靠谱。

应用的依赖管理这件事，有 Bundler 先行推广的 Gemfile{,.lock} 模式，其他包管理器如 Pipenv、Cargo 等也都跟着效仿，而且几乎见不到有人对这个设计提出有效的反对，那么看上去这个设计就足够好，NPM 这边只要效仿着做就可以了。毕竟不是去挑战什么未知领域的高端问题。

结果嘞，#16866 里面这么一吵，也不见 NPM 项目维护者拿出自己的观点来讨论讨论，也不考虑回应一下评论里提到的 npm update 行为不符合预期的问题，就直接在 #17058 给“fix”了，甚至在 code review 过程里也没人质疑，估计是私下讨论达成一致意见了吧。

反正我是先去用 Yarn 算了。

不要觉得“改个名字就可以避免被当作是泄题的纠纷”了。泄题就是泄题。

假如我为了避免自己设计的面试题被泄漏，在面试开始时就签保密协议，这会向面试人传达出一种“这家公司默认不怎么信任我”的潜台词，使面试人心理紧张，容易造成发挥失常。所以在：

• 默认面试人会泄题于是要签协议施压
• 默认面试人会在道义上坚持不泄题，不签协议可以使面试过程不那么紧张

两者间取舍，我是会选后者的。但话又说回来，假如面试一次就泄一次题，时间久了我也会觉得“既然面试过的都不值得信任那么还是签保密协议吧”。

类似的话题还包括上班要不要打卡，绩效考核要不要做（以及该如何做），代码上线是要由开发者自己灵活掌控还是搞层层验收签字制度（或者怎样找到折中的灵活又安全的制度）。如果合作中的双方能默认互相信任，解决问题的效率能高很多。