socks4a 协议代理
对于网络编程学习而言，尝试实现一个 proxy 是一个很好的途径。因为一个 proxy 对于 clients 来说是 server，对 remote servers 来说又是 client，一下就覆盖到了网络编程的两个大块。
同时，需要管理/协调两侧的连接对如何正确的处理网络连接的关闭也是一个挑战。
对于网络编程学习而言，尝试实现一个 proxy 是一个很好的途径。因为一个 proxy 对于 clients 来说是 server，对 remote servers 来说又是 client，一下就覆盖到了网络编程的两个大块。
同时，需要管理/协调两侧的连接对如何正确的处理网络连接的关闭也是一个挑战。
Designing Headers for HTTP Compression
看起来是 HTTP/2 的 header compression 使用建议
How to Think About HTTP Status Codes
HTTP status codes 使用建议。
适合结合 Rest API design 相关文章一起食用。
golang 这破 timer 坑真多
C++ 17 Guaranteed copy elision explained.
因为公司使用 Windows 和 MacOS 的人最多，因此导致两个后果：
求一下交集可以发现，在贵司使用 Linux 作为开发平台的同学应该很难过。很不幸的是，我刚好属于那种在 Linux (虚拟机里跑 Mint) 上写后端服务的人。
公司买的深信服的 VPN 服务，那个客户端虽然官方宣称支持 ubuntu，但是事实是压根不能用，连接成功后一旦有数据包就自动断开。
官方论坛有人反映过类似的问题，得到的回答千篇一律都是推荐使用 Windows 和 MacOS。
然而让我使用屎一样的 MacOS 是不可能的；让我在自己的主力台式机的 Windows 上装深信服的客户端也是不可能的。
本文内容中提及的 CMake 均指提倡 target-based properties 的 modern cmake，而非史前版本的 legacy cmake。
对于 C++ 工程而言，只要 ABI 的问题还存在，源码依赖就是最稳妥最普适最可靠的依赖引入方式；即使这些引入的源码在构建中会单独编译成（动/静态）库。
同时，GitHub 成为开源文化社区的标杆后，获取实现了某一功能的第三方库的源代码的难度大大降低。
因此个人倾向上：只要允许，都应该以特定版本的源码引入的方式去依赖一个第三方库。
事实上，Google Facebook 这些大厂内部实行的 monorepo 也是源码依赖的一种实现方式，因为某个工程需要的依赖源码都可以一并获取到。
在使用 CMake 作为构建系统的工程体系下，要以源码依赖的方式添加一个子工程只需要使用 add_subdirectory() 添加目标工程的顶层目录（根 CMakeLists.txt 所在的目录）。
我的个人项目 KBase 和 ezio，在此之前都是通过 git submodule 的方式引入自己需要的依赖源代码，然后通过
add_subdirectory() 建联（*nix 平台）依赖的版本管理直接复用 submodule 提供的特性。
上上周的时候给 ezio 做了一个调整，稍微修改了一下 TCPConnection 对外暴露的几个状态变化的事件。
起因是在写 example/chat-client 的时候，因为主线程单独跑了一个事件循环从 stdin 中读取用户输入，所以 ChatClient 以及内部的 TCPClient 是跑在另外的工作线程上。
因为那个时候 TCPClient 之对外暴露了 connection 和 disconnection 的事件回调（这两个事件还统一成了一个 on_connection()），所以自然选择在 disconnection 的时候进行退出主循环的操作。
但是这个时候会出现：
ChatClient，连同内部的 TCPClient 一起销毁。因为这部分代码跑在主线程上，所以不会和工作线程有任何 coordination。TCPClient 会在触发 on_connection() 来表明连接断开后会继续做一些内部清理工作；然而因为前面已经将 TCPClient 析构了，导致 UAF而当时为了解决这个问题，采用的 workaround 时，ChatClient::OnConnection() 在发现连接断开后，通过 RunTaskAfter() 的方式延后执行 EventLoop::Quit()。
这个做法非常丑陋而且不可靠。