如果问题仅仅在于“我如何定义我的错误并准确地告知用户”，我认真介绍一下 RFC7807 所定义的一种媒体格式:application/problem+json
https://tools.ietf.org/html/rfc7807

{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
'status": 403,
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}

其中 type, title, detail, status 和 instance 都是这个规范定义的成员字段，但也都是可选的，此外别的字段都是可以随意拓展的。

其中 status 的存在就可以有效避免楼里说的 HTTP status 被篡改的问题。

type 要求是一个指向人类可读的错误文档的 URI，如果可以确保这个 URI 不变，调用方可以对这个 URI 进行判断来确定错误。title 和 detail 则是提供了人类可读的说明。

这个格式已经有很多语言的实现，Github 上一搜都能出来很多。而且这个格式是 RESTful 的，因为用到了超媒体。

如果传输过程中 HTTP Body 也不幸被修改了，可能会出现的情况是 HTTP Header 的 Content-Type 也被修改，不是 application/problem+json，那么可以确定问题发生在传输过程中。如果 Content-Type 是 application/problem+json 而 body 无法按照这个格式解析，也很容易确定问题发生在传输过程中。

不懂超媒体的就不要再黑 RESTful 了。

archlinux-java?

校招面了三十次才找到现在这个工作…

有意思。不过我以为是 Firefox send 有 API，原来是先下到 CI 再放页面上

Introduction to Algorithm 。不过这个的前置课程（ prerequisites ）是数据结构，线性代数（有涉及矩阵乘法）和高等数学（有涉及到无穷级数）

@psx2019 推荐这里面的崔毅东老师！因为是我本科老师

@jzmws 没有不安全的 HTTP 请求，只有不安全的 HTTP server 实现

有

@muzuiget 我也是 restful 信徒，但我几乎从来没在真实的系统上见过真正的 restful 接口（ GitHub 勉强算）。这就像是我信仰共产主义但是从来没见过共产社会

常见问题：
讲状态码就是在讲 restful 吗？
我觉得不是，restful 的核心是超媒体。HTTP 状态码只是语义上的辅助。全部 200 也可以是 restful 。
HTTP 状态码够用了吗？
我觉得够用，而且你可以在 body 里加上具体业务的状态码。
如果 HTTP 状态码被中间的网络服务改了怎么办？
如果 body 不被改的话，像 RFC7807 那样把 HTTP 状态码写一份到 body 里也是可以的。
全用 200 有什么好处？
增加就业。

RFC7807 了解一下

开源项目用得多了你就会发现有一些 bug 或者功能缺失，然后你就可以提 issue，如果维护者很忙，说 PR welcome 。你就可以 fork 然后改了提 PR 。提 issue 其实就是已经参与了，提 PR 如果被 merge 就算是有代码贡献

合法…所以尽可能地不要在上班时间写开源，除非公司支持

看过有研究说，虽然国人觉得国内网站页面信息量过大，但是去看了信息量少的国外网站反而会觉得信息量不够。国人已经习惯了这样信息量大的网站。
另外从人类认知学的角度来说，人的认知是受人过去的经验和周围的环境所影响的。所以当第一个受欢迎的（先不论怎么成功的）网购网站定下来这样的布局设计，后来的网站也会跟着模仿以确保用户在访问时可以按照原来习惯的逻辑进行交互
虽然我也觉得丑，但我觉得这是中国用户的审美和使用习惯的真实反映

电声乐器容易带到公司练，优先考虑

@collery 没时间不要学乐器，没钱也不要

WordPress 和 Heroku 在 Most Dreaded 里很是令我惊讶

JS 是真的火，连《设计模式》的 Erich Gamma 和《重构》的 Martin Fowler 都在写