对于网络编程学习而言，尝试实现一个 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 提供的特性。