为什么不能有这些内容呢？
git 的本质是一个版本管理工具。
除了代码以外，合同、文章等文字内容也可以使用 git 进行版本管理。
github 不是 codehub 。

@mikeven 都是无线的。

那真是太好了。
现在的 iCloud 部分请求需要连到国外去，各种卡顿。

什么病啊，小病没必要挤大医院啊

批量更新在并发度不高的情况下就很容易造成死锁。
特别是隔离级别在 RR 的情况下。
跟 mysql 锁机制有关。

本质上就是树结构的遍历算法。
BFS 请用队列
DFS 请用递归 or 栈

关闭 facetime 和 imessage 、共享相册，然后专门注册一个邮箱只给 icloud 用。

看标题的意思得出 lz 的目的主要是想拉一票人一起来 diss 这种写法的程序员。
在实际应用里碰到数据库 select 、json 等反序列化情况可能会出现 null 值使用 primitive data type 导致的 NPE 问题。
另外楼上也谈到了 null 值在许多场合的确是有实际语义的，用特殊值取代 NULL 的定义有时候反而是弄巧成拙。

lz 这种就是经验不够但是又觉得自己很牛逼的那种。殊不知小丑竟是我自己系列。

浮点数做运算会出误差的。
0.3+0.3+0.3 算出来的结果是 0.89999999999.
强行四舍五入精度不够的话，容易产生误差，假设一笔误差 0.00001 ，一天上百万笔交易金额产生的误差就会以千万为单位。。一年下来就是好几百万了。

@dingwen07
话说现在这个 winget 我有两个比较不满意的地方
一个是需要开代理
另一个有时候 windows 的安装过程是有一些选项的，winget 安装时候直接用的默认选项一步到底，事后配置麻烦。

单个用户频繁更新算不上并发。直接加行锁完事了。
就算一秒钟更新 20 下，行锁都是绰绰有余。
你觉得不合适大概率只是你自己觉得，跑一下压测就知道了，大多数情况只是杞人忧天。。

一般来说都是结合 http status 和业务状态码一起用的。
40x 系列表示这些请求已经进入到了应用内部处理，但是由于请求参数不对、权限不对、url 路径不对等原因应用内部返回了这些错误状态码。
50x 系列表示 http 请求中间经过的某个网关发生了异常、超时，或者请求已经进入到了应用内部但是应用内部出现异常等原因。

200 表示请求已经已经进入到了应用内部处理。至于业务里出现的一个错误码，比如余额不足、账号未实名认证啦这些，当然需要添加一个 code 表示异常错误来方便前端进行处理。

其实业务 code 和 http status 也有重叠的地方。比如查找 id=1000 的 book ，https://xx.xx/detail?id=1000 ，你就会去纠结到底是 404 还是弄一个业务 code 。我自己的偏好是 404 只用于 url 在后端是否有对应的 RequestMapping ，对于根据某某参数、条件查不到某数据的这种情况我喜欢放到业务 code 里。这样的话 40x 、50x 系列的 http status 的功能就更偏向于运维监控层面而非业务相关。而且这样还有个好处就是内容传输协议不再局限于 http ，我可以随时调整协议格式，比如采用 grpc ，我不需要再去考虑迁移协议后怎么兼容原来 http 404 的问题，因为我的数据返回的业务 code 里已经涵盖了 http 404 的这种情况。

前端这边肯定是先进行 http status 判断，然后再进行业务 code 判断。

说到底还是因为 http status 这东西已经出现了几十年了，跟不上现在的互联网应用变化，所以国内的设计都是以实用角度出发，存粹把 http 协议当成是一个传输的载体。现在很多公司做的接口甚至都把 url 部分废弃掉了，需要访问哪个接口把服务名称写进 http 参数里交给后端做分发。

github 早期的 url 是很 restful 的，后边规模大了，也开始不 restful 了。也就 V2EX 上一群没见过世面的小学生喜欢把 restful 挂嘴上。

我 2018 macbook pro ，插着电源用了一年，循环不到 30 次，结果电池容量就已经只剩 85%。
长期插着电源并不是什么好事。

最好的方法就是扩展 spring ，
同时 accept 接受 application/json 和 application/x-www-form-urlencoded 两种 request ，
这样你们爱传啥传啥。

nodejs 前边几年吹的很厉害，前后端一把梭。
经过几年时间的检验，nodejs 在后端届并没有展现出杀手级的应用，反而还被异军突起的 go 和 k8s 杀了一道。
现在 nodejs 基本已经沦落为用来 js 打包、本地 webpack 调试一类的支持工具了。。。

其实 AQS 的本质其实就是双向链表+LockSupport.park()和 LockSupport.unpark()实现的同步器。单看 enq 并没有什么卵用，你还得结合 shouldParkAfterFailedAcquire 、unparkSuccessor 、setHeadAndPropagate 、cancelAcquire 几个方法一起看。

任意时候 node 状态都会发生变化，所以针对链表的操作用了大量的 forloop+cas 操作来保证并发安全。jdk8 版本的这个 AQS 应该是经过了 N 个版本的修订才会搞得这么零零散散一堆方法。。

我记得 8 版本以后的某个版本好像 aqs 有大篇幅的重写。。

优秀的程序员：
出现需求->寻求市面上成熟的解决方案->出现疑虑困惑->通过各种途径解决使用困惑->问题属于硬伤无法解决->有能力则自己造轮子，没能力退而求其次选择其他方案

抠脚程序员：
出现需求->寻求市面上成熟的解决方案->选择 ES->ES 出现问题->换 SOLR->SOLR 出现问题->自己研究 LUENCE->能力有限研究不出来->？好像 pg 也有 full text search ？-> 感觉不好用->再次换回 ES