代理的英文叫做 *Proxy*，是计算机中的常用软件。
简单来说，代理的功能犹如它的名字所示：代替某人来处理某事。
常见的代理分两种，正向代理和反向代理。不管哪种代理，它们都位于客户端和服务器之间，将我们传统的 客户端 <-> 服务器 通信变成了 客户端 <-> 代理 <-> 服务器 通信。
字符串是任何一个编程语言中的重要概念，同时也是一个非常复杂的问题。
日常编码中可能并不一定能见到它的复杂性，下面是几个字符串操作，使用你最熟悉的编程语言，看看结果如何。
- 逆转字符串
"noël"，正确结果应该是"lëon" - 获取字符串
"noël"前三个字符，正确结果应该是"noë" - 获取字符串
"😸😾"的长度，正确答案应该是 2 - 字符串
"noël"和字符串"noël"规整化以后应该相等（他们看起来一样，但是内部表示不一样，一个 6 字节，一个 5 字节，这里涉及到 Unicode 的规整化）
对于大部分编程语言，包括 Ruby，Python，JS，C#，Java 等，上面的问题都无法全部返回正确结果（但是，拥有超强 Unicode 支持的 Elixir 可以）。
DNS 全称 Domain Name System，是我们每天都在使用的基础互联网设施。
它被发明出来的原因很简单，计算机之间的通信用的是 IP 地址，是一串数字，人类记忆起来十分不方便，因此，我们给地址起个名字，然后将名字和 IP 之间的关系记录起来，这样，我们只用记住名字就行了。
从上面可以看出，DNS 系统类似我们日常使用的电话本，只不过里面存储的是域名和 IP 之间的关系。和人与电话之间的关系一样，一个域名可以有多个 IP，一个 IP 也可以有多个域名。
HTTP Basic Auth 是 HTTP 提供的一种验证方式，因为明文传输用户名和密码，非 HTTPS 环境下很不安全，一般用的非常少。但是在某些情况下用一用还是非常方便的，比如，一些静态站点例如文档系统可以使用 HTTP Basic Auth 进行简单地权限验证。
最近这段时间一直在忙着迁移博客，把原本基于 Jekyll 的博客迁移到了 Hugo 上。
之所以从 Jekyll 迁移的原因并不复杂，就是一个字：慢。Jekyll 的速度实在是太慢了，我只有几十篇文章，在 Watch 模式下，每次改动，重新生成都要花费 3 秒钟，实在是太慢了。
Regenerating: 1 file(s) changed at 2017-05-14 10:37:16 ...done in 3.085089 seconds.
Regenerating: 1 file(s) changed at 2017-05-14 10:37:20 ...done in 3.121783 seconds.
diff 是我们每天都要使用的一个功能，每次提交时，我都习惯先用 git diff --cached 看看这次提交更改了些什么，确定没问题，然后再 git commit。git 生成的 diff 非常直观，直观到我从来都没有去思考过 diff 是怎么生成的，觉得这应该是很简单的一件事，两个文件做个对比，不就行了。
最近一直在思考如何对线上服务做深度监控。基础的服务可用性监控很简单，定期 Ping 即可。但是怎样才能监控服务器的一些更加关键的数据呢？比如，每一个 API Point 的请求次数（QPS），最大响应时间，平均响应时间等。最终我希望实现的效果是有一个 Dashboard，我可以清楚地看到各种参数曲线，对服务器的运行情况了然于胸。
绘制 Dashboard 不难，目前提供数据可视化的工具很多，随便选一个都能满足需要。关键问题是，怎样将整个流程打通？
- 服务器该以怎样的形式暴露出数据？
- 数据怎样被收集和存储起来？
- 存储起来的数据怎样提供给数据可视化工具？
- 怎样做到足够灵活，可以可视化自己感兴趣的任意数据？
很早之前就看过到关于 commits.io 的一个帖子，这个站点专门制作代码明信片。什么是代码明信片呢？如下图。
注：因为七牛 API 修改，编辑于 2019-03-25T16:20:00。
最近在使用过程中发现 图床on微博 出了点问题，响应体的 JSON 解析错误，不用想都知道肯定是微博修改了响应体的数据结构（微博图片上传接口响应体是 html 和 json 混在一起，十分专业）。简单修复了一下，测试的时候却发现，微博的图片上传接口变得不再稳定了，经常 404。看来微博图床是不能用了，正好我早就觉得微博不是个好图床，缺点如下：
- 经常性的要重新登陆，麻烦死了
- 无法获取到完整的上传图片列表
- 无法删除上传的图片
- 服务状态不可控，指不定什么时候接口就不能用了
Donald E.Knuth 说过一句非常著名的话，过早的优化是万恶之源，原文如下：
We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil.
我是十分赞同这句话的，并且在开发过程中也深有体会。什么叫做 过早的优化 呢？即不需要考虑优化的时候你在考虑优化。这绝对不意味着可以任性地写代码，随意地选择数据结构和算法。这句话是告诉我们，在程序开发的早期阶段，程序员应该专注在程序的 逻辑实现 上，而不是专注在程序的 性能优化 上。用正确的数据结构和算法，优美合理的语句实现你要的功能。而不是满脑子在想：“这个函数是不是可以优化一下？”。