karloku

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

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

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