工作二字似乎就足够概括我这一整年的经历，2018 对于我来说，nothing happens to me。

Since the middle of last month, I started to read the source code of programming language Go for better understanding its runtime and more. The entire series are based on Go 1.11 at the moment, and it will continuously getting support for at least three major release version. Now, the entire article is open source at GitHub: https://github.com/changkun/go-under-the-hood. You can submit an issue or pull request to contribute if you were interested in this study.

Go 源码研究：unsafe 范式

unsafe 包该包会绕过所有的 Go 类型安全检查，几乎是 Cgo 的灵魂，也是支撑 Go 运行时、reflect、系统调用等机制的核心。

Go 源码研究：sync.Pool

sync.Pool 是一个临时对象池。一句话来概括，sync.Pool 管理了一组临时对象，当需要时从池中获取，使用完毕后从再放回池中，以供他人使用。

Go 运行时编程

本文可能会过时。 它旨在阐明不同于常规 Go 编程的 Go 运行时编程，并侧重于一般概念而非特定接口的详细信息。

本文介绍了如何使用 Go 语言开发高负载的 WebSocket 服务。如果你对 WebSocket 非常熟悉，但并不了解 Go 语言，我希望你仍然能对此文所介绍的一些优化技术感兴趣。

RESTful API 已经不是什么新奇玩意儿了。HTTP 的无状态性让我们在处理交互式 CS 应用中不得不使用诸如 Session、Cookie 等技术。那么我们的问题产生于：如果客户端发出的请求的在服务端需要较长的时间处理，我们应该如何设计我们的 RESTful API？这次就来聊一聊异步 RESTful API 的设计。

最近在实践分布式和微服务系统，总算是能够把课本上学到的知识学以致用了。于是打算开一个系列来随机聊一聊分布式系统的一些知识。

Here lists some issues when I was exploring Human-bot interaction.

本文译自：http://www.offconvex.org/2018/02/17/generalization2/ 译者：欧长坤

本文是关于我最新的论文并提供了一些之于我之前一篇文章新的关于「泛化谜题」的观点。

这篇新论文引入了一个基于压缩的基本框架来证明泛化界。并表明深度网络的是高度噪音稳定并可进行压缩。这个框架同时还未去年的一些论文提供了简单的证据（下面会讨论）。

回忆关于泛化理论的基本定理：具有 $m$ 个样本的训练集则泛化误差（定义为训练数据和测试数据之差）是 $\sqrt{\frac{N}{m}}$ 的高阶项，其中 $N$ 是网络的有效参数（或复杂度度量）；它最多可能是实际参数数，但实际上可能会少得多（为了便于说明，这篇文章将忽略 $\log N$等这些在计算中产生的干扰因素）。泛化之谜在于：当网络参数量高达百万级时即便当 $m=50K$，网络同样具有相当低的泛化误差（比如 CIFAR10）。反过来想，从某种意义上来说这似乎在告诉我们，网络的实际的参数量是远低于 $50K$ 的。

这里N是网络的有效参数（或复杂性度量）的数量; 它至多是可训练参数的实际数量，但可能会少得多。 （为了便于说明，这篇文章将忽略\ logN等这些也出现在这些计算中的讨厌因素）。神秘的是，即使当m = 50K时，具有数百万参数的网络也具有低泛化误差（如在CIFAR10数据集中） ，这表明真实参数的数量实际上远低于50K。

Bartlett et al. NIPS'17 与 Neyshabur et al. ICLR'18 尝试类似于 PAC-Bayes 和 Margin 的有趣想法对复杂度度量进行量化（同时也影响了我们的论文）。但终究这种量化是不切实际的——量级比实际参数量还要多。相比之下，我们的新估计值要好几个数量级，并且更加有意义。下面的条形统计图进行了说明（所有的 bound 都忽略了干扰因素，可训练参数的数量仅用于表示比例）：