周刊第5期：拖延症

本期周刊延迟了两天，今晚抽空补上，内容会相对比较少。

反思一下，一个原因是这周比较忙，但主要还是因为自己的拖延症，希望以后能够克服这个问题。

一个排查页面网络请求错误的方法

我们在平时开发页面时，可能会遇到一些奇奇怪怪的跨域报错，但是通过 Network 面板却看不出是什么问题。

可以使用 chrome://net-export/ 记录网络请求，然后导入到 这里 进行分析。

这里分享两个笔者真实遇到的案例，其中一个去年发过一篇文章：《记一次因 HSTS 导致跨域问题的经历》。

今天遇到另一个问题，同样是跨域报错，有了上面的经历，这次我轻车熟路地记录、分析，得到以下：

通过上图分析问题的原因：因为 预检请求 需要发送 OPTIONS，而接口的响应头里的 access-control-allow-methods 没有包含 OPTIONS，所以导致跨域。

所以下次如果遇到页面的请求报错，也可以通过这个方法来分析原因。

一些本周阅读过的好文章、以及我的一些总结和个人思考；非常建议你直接阅读原文，毕竟一千个读者就有一千个哈姆雷特，而且我的理解可能是错的。

Exhausting Exhaustive Testing

原文地址：《Exhausting Exhaustive Testing》 | openmymind

非常短的一篇文章，但作者的观点让我醒醐灌顶：编写有效的测试具有挑战性，每个测试用例都需要考虑最大化其价值。

举一个例子，比如我们有这么一个软删除用户的函数：

func deleteUser(id) (bool, error) {
  tag, err := conn.Exec(`
    update users
    set status = 'deleted'
    where id = $1
  `, id)

return tag.RowsAffected() == 1, err
}

通常我们会如何测试这个函数？是不是这样：

1. 插入一个新的用户
2. 调用这个函数
3. 判断这个新用户是否被删除

这样测试没有错，但是我们忽略了一点：如果这个函数把所有用户都删除了呢？是不是也能通过测试？

所以正确的测试方式是：插入两个用户，删除第一个用户，确保第二个用户没有被删除。

还有另外一个例子，假如我们要获取用户列表，SQL 是这样的：

select id, name
from users
where status = 'normal'
  and customer_id = $1
order by name

通常我们可能是这样测试的：

1. 插入一个新用户，设置 customer_id
2. 判断是否返回这个新用户

但作者认为至少需要插入四个新用户才能进行这个测试：

1. 四个用户，其中一个被删除的 A、一个 customer_id 不符合的 B，剩余两个才符合条件
2. 确保没有返回 A 和 B

诚然我们都认同测试的重要性，但是如何编写测试是一门非常高深的学问，只是编写测试用例的时候只是流于表面的，那么其价值是非常低的，甚至是浪费时间的。

百度腾讯阿里真的是高科技企业吗？

原文地址：《百度腾讯阿里真的是高科技企业吗？》 | 马工

那么，这些潜力人才去了BAT，在干什么呢？腾讯的公众号文章《搞了运维开发这么多年，原来 Ping 还能这么玩儿！》揭示了部分真相：一个北大本科毕业生在腾讯研究一个1981年的协议ICMP，而这个协议因为不安全已经被大多数美国同行比如AWS给默认禁掉了。说句不客气的话，ICMP协议就是IT行业的回字的四种写法，让北大毕业生去研究ICMP协议，就是把他们变成孔乙己。

有趣的链接

• AES加密/解密：一个在线 AES 加密/解密的工具。

• PlantUML Editor：一个在线画 PlantUML 的工具。

• OssArt：一个非常有意思的开源项目，它可以帮你打印出最早从 2010 年开始的 GitHub Activity 贡献图，让你的成就感满满。