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

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

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

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

愿意认真给你答案的人，肯定也愿意认真阅读你的问题。加粗所传达出的信息是“我知道你们都不会认真阅读，所以只读我加粗的重点就好了”。相关吐槽：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 算了。

没有完美的最佳，只有满足限制条件下的最合适。

如果换我来做这个需求，就会直接把生成的结果写入到新文件了事。上传的旧文件扔在那不管，直到硬盘空间吃紧了再考虑清理。

“生成临时文件”这件事目前有什么问题么？性能？还是硬盘空间？

简单来说，不建议这么做。

展开来说，把新生成的文件改名覆盖旧文件，这个操作按照 man 3 rename 里的描述是可以做到原子化的。这很可能比你自己实现的原子化方案要靠谱。

具体来说，因为我不知道你要这么做的目的是什么，这个帖子很可能是个 XY Problem：https://ruby-china.org/topics/7154

简单来说，不建议这么做。

详细来说，因为我不知道 LZ 原本面对的问题具体是怎样的，所以不便直接给出答案。这很有可能是个 XY Problem：https://ruby-china.org/topics/7154

Here is what I think:

• This is practically a job ad posted in a wrong category with a nonsensical title.
• It's not even a proper job ad. You probably haven't read the rules at all: https://ruby-china.org/topics/25579
• The English... well actually it smells more like Chinglish to me. You probably need to put some work into it if you really want to keep your job as an international recruiter (assuming you are, that is). 或者如果你懂中文，就直接说中文好了。Ruby China 上的人应该都懂中文的。

这种标题太容易给人造成一种“只有大神才有资格回答问题”的错觉。然而实际上问出来的问题水平实在太低，根本不需要大神来回答。

关于 : 语法的问题，论坛第一页就有入门级的资料可以看：https://ruby-china.org/topics/34066 form_for 的用法在 Rails API 文档里查：http://api.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-form_for

这么说吧，由业务需求带来的软件复杂度没法消除，只能尝试管理起来。不同的功能向不同的客户可见，这件事肯定是要在某个层面上解决。要么在代码库层面上做拆分，要么在运行时判断。如果你不想在代码里留十几个开关，而是选择用分支 / 分仓库方案，那么就意味着会有十几个分支 / 仓库需要提交代码。而且每个分支至少要有一个部署实例，每个部署实例都可能需要运维方面的开销。如果你的团队能 handle 得了这些问题，当然也可以。

如果你想找更新颖的，更趋近完美的解决方案，那我实在是帮不上忙了。我自身的经验是在功能开关的应用上尝到过甜头，所以会有这方面的偏好。

不过话又说回来，如果你的业务真的是每个客户都有定制的且不能相容的功能需求，那么你的业务会从 SaaS 方向逐渐向外包方向倾斜。这个事我只能说：但愿你从客户手里拿到的钱能满足得了为了应对这样的业务扩展所带来的复杂度而被迫增加的人力成本（这句话好长）。

Python 标准库里的 sqlite3 底层实现是直接动态加载 libsqlite3.so 的，所以底层逻辑是由 sqlite 决定的。

那么这样直接去读 sqlite 的文档，应该就有答案： https://sqlite.org/search?s=d&q=hot+journal

因为在 Ruby 中数组是可变对象，而且赋值 / 作为参数传递时，传递的都是引用。 关于 Ruby 的引用： https://en.wikibooks.org/wiki/Ruby_Programming/Introduction_to_objects

再就是 Array.new 方法的不同用法的语义，官方文档也是有介绍的： http://ruby-doc.org/core-2.4.1/Array.html#method-c-new

如果是我来解决这个问题的话：

• 把两个分支合并成一个，避免新写的代码要在人力管理下合并到两个分支上去。也避免两套代码所带来的额外 CI 等开销。
• 有业务冲突的地方，通过功能开关来解决问题：https://blog.travis-ci.com/2014-03-04-use-feature-flags-to-ship-changes-with-confidence/

当然因为我不清楚具体的业务，这个方案也不一定非常合适。

建议搭个异常监控，把异常事件都发送到监控服务上去。比如用这个 https://sentry.io/ 然后再慢慢调查。

如果你把这个页面里所有的方法名 ( http://ruby-doc.org/core-2.4.1/Method.html#method-list-section ) 都看一遍，你会发现有个方法叫做 #owner。也许方法所属的 class / module 处会有更多的关于可见性的信息，值得你继续调查下去。

文档里的信息够用么： http://ruby-doc.org/core-2.4.1/Method.html

作为一个 web 开发程序员，我对在桌面浏览器上还要故意模拟成手机界面，要用点击而不是滚动才能翻到下一页但内容又不是很多的 web 界面，而且默认还要放背景音乐的 web 界面非常不感兴趣。

只有吐槽能力，没有设计经历，悲剧了 = =

• 考虑用 StandardJS 把代码格式规范化：https://standardjs.com/
• 对 config 的处理：如果用户没有自定义的 config.json 文件，可以考虑在解析过文件之后就直接用一个对象字面量来提供配置的默认值。这样后面的代码就不需要操心 config 可能为空的问题了。
• 可以考虑用一些很短小的函数来为某些操作明确表意：比如从页面里提取结果的部分，可以分别抽取成 parseCnResult($), parseEnResult($)
• Don't Repeat Yourself: console.log(color_output( ... ));这部分结构重复出现了，可以考虑抽取成一个函数。
• Program into the Language: JS 支持将函数作为对象来传递，当你做完了前两项重构之后，可以再简化代码：

const parser = isCn ? parseCnResult : parseEnResult
printWithColor(parser($))

暂时就这么多。

呃，虽然我看过搞笑漫画日和，但这里并不清楚你所说的“好像日和吐槽”具体是什么意思。而且我也没有学过日语。

如果你是在评价行文风格，那么我想应该是因为原文文风就是如此。当然也有可能是我在翻译中意外地加工成了现在的样子。

我自己也试了一下，目测 require() 和 load() 的查找逻辑是不一样的。

• require "./foo" 使用句点开头的参数：这只会找 $PWD。考虑到进程的工作目录可能被任意处代码修改，而且我们不能确定进程启动时的工作目录是啥（或者需要自己花时间去确定），我的建议是没有特殊情况不要用。
  • 或者我感觉这应该是 ruby 的未定义行为 / bug / 隐藏 feature，不用太当回事，更不能依赖它。
• load "foo.rb"具体的路径查找逻辑我也不是太清楚。目前观察到的是：load "kramdown" 和 load "kramdown.rb" 都只会抛出找不到模块的 LoadError，即使 require "kramdown" 是能正常加载的；以及$PWD 是会被查找的。
  • 反正常规的 require 用法加上 require_relative 已经够用了。实在有特殊需求的时候再调查 load 的行为不迟。但看来 load 并不是“可以重复加载的 require”。

当然源码才是 source of truth，直接去读源码最靠谱。

让持续集成环境尽可能地接近生产环境（通常是 Linux，使用大小写敏感的文件系统），如果测试覆盖较完整的话，应该可以在测试阶段就发现问题。 如果某些文件实在懒得去写测试覆盖，可以尝试自己写个脚本去测：https://gist.github.com/5long/1abc1b7d8c1adf71044ae5a596a2dff5

至于在开发环境下检查，我的意见是干脆不要在 Mac 环境下过多考虑这种问题。直接用 Vagrant 跑个虚拟机，再运行上面的脚本好了。

可以，但原文的许可协议（CC-BY-NC-SA 3.0）不仅要求注明出处，还有别的要求。官方的中文简单诠释可以看这里：https://creativecommons.org/licenses/by-nc-sa/3.0/deed.zh