@hobochen c 语言是个人设计的而非组织设计的，这句话（大意），我是从《深入理解计算机原理》里面看来的。

c 语言是设计的很简练的语言，它是个人设计的，并非组织设计的。c 语言很多地方按照约定来设计的，可能在主力语言是 java 或者 c#的人看来比较不美，但是实际上这是简洁的美。
例如：字符串以'\0'结尾。与字符串操作相关的库函数也都是基于这个假设。
再例如，库函数、变量命名都有大量缩写，例如 getchar, fopen，而不是 OpenFile()这种风格。
而数组的约定，就是将数组与指针等同起来理解。如果需要记录长度，请单独拿一个变量。

（接上文）
站在系统负责人的角度，要防御到各方面的因素，那么就请使用 [事件溯源] 模式。

根据业务代码的行为，根据逻辑推演，可以证明：运行到某处，某条件一定成立。（这也是“约定”的数学基础）
如果某个条件没有被满足，那么就说明它的数学基础不满足：一定是代码有 bug，或者 DBMS 有 bug，或者是有其他未遵守约定的程序（或者人）随意的修改了数据库的记录。

假设某记录不存在，那么你在访问模型类（假设用 orm ）的成员的时候（也可以主动检查）就会抛出空引用异常，然后就可以查看 log，排查以上三条中的哪一条出了问题。
站在普通成员的角度，通常只有第一条是你的锅，那么就在业务代码中做足测试，并且在业务代码中加上（适量的）判断约定条件是否成立的语句。

站在

@hronro 我测试过 750ti 的 nvenc 编码，发现占用非常少，但是画质不怎么好，但基本够手机用户观看。刚刚看了视频，不禁感叹又一个痛点被新的 nvenc 单元解决了解决了。

官方文档，例如微软的 docs

查一下脑瘤

对资本家绝对不能手软，但是也要注意不能被安上敲诈勒索的帽子。

在你的项目里面用 nuget 安装客户的版本。然后打包成 nupkg，别打包成 dll。

@libasten 可能微软推出.Net Core 会给人不成熟、没案例的感觉。其实.Net Core 的积淀应该理解为十几年 .Net Framework + Mono c#的成熟度，而不应该理解为才发布几年的东西。

@stnaw 《反脆弱》我读了 3 遍以上

表演窗帘擦嘴

理论上（数学）是可以的。设字母表Σ大小为 S，哈希字符串长度为 L，改变图片的其他部分，组成 S^L + 1 种组合，总会遇到相同的。

详细的说，在服务划分上，《大型网站系统与 Java 中间件实践》的方法与微服务的理解不太一样。
微服务是 1 个团队=1 个 Bounded Context=1 个数据存储（不与其他服务共享）；服务间通过消息来通信。看了几页《大型网站技术架构-核心原理与案例分析》，发现同样也有这个问题（代码有公用部分、数据储存共用，都是与微服务不符的部分）。

只能说写书的时间点、运气不是很好。

还有一个运气不好的地方就是：MongoDB 在 2018 年夏的时候开始支持跨文档 ACID 事务（分布式事务）。而这本书是 14 年的。

@wujichao
关于服务的知识没有成体系化。也不怪作者，毕竟微服务的概念、普遍标准那时候还在探索阶段。
保证消息一致性的有种做法是错的，他说能保证一致性，但仔细分析可以发现不能保证消息一致性；并且没有提及 Outbox Pattern 这种极其简单的标准做法。
整本书的知识也没成体系化，像是大杂烩，有凑字数的嫌疑。

@wysnylc 李智慧的这本借了还没看。《大型网站系统与 Java 中间件实践》实在太离谱了，我都无力吐槽了。

@terrywater 因为你是废物 因为你脑容量不足 所以你读不了物理书

@terrywater 你在这个贴子里面干了什么？我给你总结一下：

从物理学专业人员来看，v 站的程序员大多都只懂皮毛，就像一群小学生。
而你，走进一所小学，拿着一道数学分析的题目问小学生：“你看，这里不对啊！如果微积分理论是正确的，那么这个结果不是和理论矛盾了吗？”
小学生答不上来，或者凭借有限的知识乱答一通。然后你就反驳小学生的论证，随后附上一句：果然，微积分的理论有问题！

建议去看一些科普类的物理书（例如环球科学），而不是和非专业人员讨论问题。