丢失 collection 不至于.
就算古早的 mongodb 会丢数据, 但那也是 2.0 以前的默认配置下, 写入数据不需要 ack 时期的事情了.

venv 最有安全感, 配合 dotenv 一起用也没什么不便利的地方

如果优化不了条件的话, 可以设计成能提前进行 return/continue/break 的执行方式

当然最好是想办法优化一下判断条件, 这么长的判断式可读性很差

都可以, DTO 看起来帅一点也更符合本身单词的逻辑, 但是对自动转换驼峰和蛇形的反射器不太友好. 取舍以后保持一致就行.

@Cielsky 锁包了就没事. npm i 时生成 package-lock 都是默认选项了, 用 npm ci 能保证按照 package-lock.json 里的依赖进行安装.
而且 npm i 也只会在发现写在 package.json 里的项目有新版本时更新 package-lock.json. 非库项目不要用 ^ 指定依赖版本, 应该直接指定确定的版本号. 这样只有手动升级的时候才会导致 lock 变更, 可以进行测试.

@2i2Re2PLMaDnghL 对, 我意思 MIT 就只要求写个 "Copyright Notice" (翻译: 冤有头债有主(

用 MIT License 就要做好被白嫖的准备. 这协议除了留个 Copyright 之外几乎什么都给出去了.

用开源项目不锁好版本号, 不测试版本更新, 那后果也是自负. 外部依赖本来就是系统风险的一部分.

@ThirdFlame 别说铁道了, 连地铁族都给关了...

cpu 的发热量, 吹出来的暖风可能还不如对流风导致体感温度下降来得明显
个人体感还是把机箱内部的热量都从机箱上部吹出来, 让他自然弥散的效果更好点. 最不济在低负载下也不会出现冷风直吹的情况.

扯其他的什么货币都是虚的

proof-of-work 这个信任机制需要运算参与, 挖矿是激励参与运算的手段.
当这个激励手段因为某些原因获利远大于投入的时候, 挖矿就会成为一个投入的无底洞, 直到收益和投入达到平衡.

盯着激励结果说当然可以说是虚无缥缈的东西, 但是对区块链这个无控制者的分布式数据库而言, 这些都是为了维护网络安全性的必要投入.

另外其他任何激励机制只是变相的改变了能源 /算力的投入产出, 本质上依然是投入运算资源来换分布式网络的安全.

其实就和拔火罐以后很爽一样...
拔火罐是 M 吗...

驼峰蛇形的拼写并不是刻板的按照大写转小写加下划线, 而是要看里面每个部分的单词本身.

WeChat 本身是一个词, 所以小写的时候也不会拆开. get WeChat ID -> getWeChatID -> get_wechat_id

套规则的时候还是得先看里面单独的单词是什么, 然后再拼接起来.

国内这些 postman copycat, 看了半天也没看出来有比 postman 实用在哪.

repo 不适合你们小组长, 不如推荐他配个网盘, 把项目文件放在网盘目录里自动同步吧.

爬虫和搜索引擎分开说

我是搜索引擎我也不给自营的电商网站做索引啊, 这都是卖钱的广告流量我主动送给他干什么嘛.

cpython 慢没办法回避的. 看隔壁 ruby 的 mri 从 2.0 开始到 3.0 一直在优化性能, JIT 已经是成了解释器标配.
而 cpython 从 2 升级到 3 解释器性能还是大幅倒退的... 最近 3.10 才总算是比 3.8 快了那么点

15 秒一次这个访问频率没必要引入额外的 redis, 放在 pg 里就够了.
如果已经有现成的 redis, 而且不是做缓存用途是作为数据库的, 倒是可以选择放进去

管理员被绑架引发的数据安全问题(