代理的英文叫做*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的一个帖子，这个站点专门制作代码明信片。什么是代码明信片呢？如下图。

最近在使用过程中发现图床on微博出了点问题，响应体的JSON解析错误，不用想都知道肯定是微博修改了响应体的数据结构（微博图片上传接口响应体是html tag和json混在一起，十分专业）。简单修复了一下，测试的时候却发现，微博的图片上传接口变得不再稳定了，经常404。看来微博图床是不能用了，正好我早就觉得微博不是个好图床。缺点如下：

1. 经常性的要重新登陆，麻烦死了
2. 无法获取到完整的上传图片列表
3. 无法删除上传的图片
4. 服务状态不可控，指不定什么时候接口就不能用了

*Donald E.Knuth*说过一句非常著名的话，过早的优化是万恶之源。原文如下：

We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil.

我是十分赞同这句话的，并且在开发过程中也深有体会。什么叫做*过早的优化*呢？即不需要考虑优化的时候你在考虑优化。这绝对不意味着可以任性地写代码，随意地选择数据结构和算法。这句话是告诉我们，在程序开发的早期阶段，程序员应该专注在程序的逻辑实现上，而不是专注在程序的性能优化上。用正确的数据结构和算法，优美合理的语句实现你要的功能。而不是满脑子在想：“这个函数是不是可以优化一下？”。