最近在写 golang-notes 的时候，看到 hexo 的 blog 支持直接展示 plantuml 和 mermaid 图表，折腾了一晚上发现并不是很好用。。。这些功能都是以插件形式支持，但在每个 blog 主题下又都需要自己配置，主题显然也没有什么统一的规范，自己用的话还是会碰到蛋疼的问题。此外 hexo 也不支持直接把图片上传到自己的 blog (别跟我说传什么七牛 cdn 之类的，几年后要是人挂了，你这就蛋疼了)。 虽然 ghost 已经商业化，且官网直接把 download

软件工程发展了这么多年，直到现如今，业界还是比较喜欢讨论 TDD [https://www.zhihu.com/question/37623307]，BDD [https://en.wikipedia.org/wiki/Behavior-driven_development]，DDD [https://www.zhihu.com/question/25089273/answer/69859648]。 虽然最后那个和前两个不太像是同一个维度的东西，不过因为都是 xDD，我们就先放在一起了嗯。每一种理论都有不少拥趸和践行者，都希望在各自的不归路上一路走到黑。

在 runtime2.go(go 1.10) 中定义了 goroutine 生命周期中所有可能的状态，虽然状态不多，不过其状态切换的可能性还是蛮多的，整理了一张图： 带上 GC 以后，图会比较乱，去掉 GC 相关的状态切换以后，会清爽许多。这里所有的 goroutine 状态切换都是由 runtime 的函数触发的，我们把 runtime 字样也从图上删除： 抽时间写写状态切换的文章。 再来一张 p 状态切换的：

在《Designing Data-Intensive Application》一书中为当今大多数的互联网系统下了个定义，即数据密集型系统。在数据密集型系统中我们要应对的是数据的爆炸性增长问题。 为了应对问题我们采用了一些手段，比如 partition、replication，但这些手段，在一些场景或语言受限的情况下会带来一些麻烦的问题。本文主要讲一讲复制方面的问题。 说到复制 replication，可能大多数人第一印象都是存储系统中的复制，比如 MySQL 中基于 binlog 的复制，redis 中基于操作日志的复制，zk/etcd/kafka 中基于特定算法的复制(实质上也是基于 log 的复制)，等等。但复制的概念本身实际上是很广的，

plan9 assembly 完全解析 众所周知，Go 使用了 Unix 老古董(误 们发明的 plan9 汇编。就算你对 x86 汇编有所了解，在 plan9 里还是有些许区别。说不定你在看代码的时候，偶然发现代码里的 SP 看起来是 SP，但它实际上不是 SP 的时候就抓狂了哈哈哈。 本文将对 plan9 汇编进行全面的介绍，同时解答你在接触 plan9 汇编时可能遇到的大部分问题。 本文所使用的平台是