几年前在 oreilly 看到一本叫 《living documentation》的书，可惜当时烂尾了。 最近图灵出版了该书的中文翻译版，才想起来有这么回事。。。正好最近有时间，把这个坑了几年的东西给填上了。 简单来说，这本书基本可以叫 living java doc(误。我们可以先看看日常开发中会涉及到哪些文档： * 需求文档 * 接口文档 * 业务词汇表文档 * 模块业务流程文档 * 系统间交互文档 * 系统架构文档 * 系统依赖文档 * 发布文档 * 示例文档(tutorial) * 项目进度文档 * 案例文档 * 汇报文档 要写的类型文档还是不少的，无论哪种文档，

在给某个项目做长时间极限压测的时候，经常会出现压几小时不出问题，突然就崩了的情况。 查看监控发现崩的时候 goroutine 突然涨起来了，那么可以用我之前开发的问题诊断工具了，配置下面的策略：若 goroutine 突然开始暴涨，则将 goroutine 文本 dump 下来。对这个诊断工具不了解的，可以看看我之前写的 无人值守的自动 dump-2 [http://xargin.com/autodumper-for-go-ii/] 和 无人值守的自动 dump [http://xargin.com/autodumper-for-go/]。 代码集成好之后再压，发现崩溃时，

为什么要做优化 这是一个速度决定一切的年代，只要我们的生活还在继续数字化，线下的流程与系统就在持续向线上转移，在这个转移过程中，我们会碰到持续的性能问题。 互联网公司本质是将用户共通的行为流程进行了集中化管理，通过中心化的信息交换达到效率提升的目的，同时用规模效应降低了数据交换的成本。 用人话来讲，公司希望的是用尽量少的机器成本来赚取尽量多的利润。利润的提升与业务逻辑本身相关，与技术关系不大。而降低成本则是与业务无关，纯粹的技术话题。这里面最重要的主题就是“性能优化”。 如果业务的后端服务规模足够大，那么一个程序员通过优化帮公司节省的成本，或许就可以负担他十年的工资了。 优化的前置知识 从资源视角出发来对一台服务器进行审视的话，CPU、内存、磁盘与网络是后端服务最需要关注的四种资源类型。 对于计算密集型的程序来说，优化的主要精力会放在 CPU 上，要知道 CPU 基本的流水线概念，知道怎么样在使用少的

从进入互联网公司开始工作起，每个人都在问自己，CRUD 到底有什么技术含量？ 别觉得 CRUD 只是业务工程师的问题，无论你在写什么程序，基本上都是在和数据打交道，除了读就是写。只不过读写的时候还会附带一些领域相关的行为。比如： 编译器：读文本，做 parse 网络程序：读连接，decode，encode，写连接 数据库：从磁盘上读，从内存里读，向磁盘里写，向内存里写 工程上，谁也没有权力鄙视谁，你觉得领域的技术含量高，只不过是领域内的工作做的人少罢了。不管门槛多么高的工程领域，只要工程师红利们蜂拥而至，总有一款内卷适合你。

工程师是一个需要大量阅读的岗位，读书、读文档、读论文、读技术新闻，现在大部分电子设备都是 LCD 或 OLED 屏幕，对眼睛的伤害非常大。 因为行业的特殊原因，有时我们会一天花 13-15 小时使用各种电子设备，工作时间长的人很容易眼睛疲劳，严重的可能还会患上干眼症。 能够缓解这个问题的是市面上用户比较少的 eink 设备，比如 kindle： 目前 kindle 最新的设备是 oasis 3，7 寸屏幕 300 PPI，如果只做纯文字阅读，kindle