之所以想写这个，也是时机到了，因为上周看了一眼自己团队管理的服务器数量，不知不觉已经达到一屏幕都放不下的程度了，好还自己当初强制规范团队统一内网域名格式，不然现在真不知道怎么管理。

其实回想起来，管理内部网络还是不够规范的，因为现在还是允许团队直接连接生产环境内网登录机器的，也就是开发与生产环境没有隔离。这么做显然有点不安全，这当然会在之后有足够精力后会去改正（是的，当初如果一开始做好就不会有这事了），现在团队的日常开发真是到了分分钟都离不开内网的程度，贸然实行严格安全制度必然会引起太多不必要的麻烦。

记得小时候，有次自己用手拿了两根铁丝插进插座（别问为什么，我在探索真理……），于是至今仍然记得那种全身酥麻以及恶心的感觉，但是幸好时间不长，两秒之后就停了，然后我家就停电了——对的：空气开关起作用了，我的小命就这么留下来了。

上上周去旅游了，写了篇自己都觉得比较水的文章，这周补上一篇。 :P

近几个月开始将现有的 Node.js 服务重构为 Golang 服务，其实这个计划去年就开始制定，并且在很长一段时间里面都在准备基础：

用了 GitHub Pages 作为博客已经几年了，而 HTML 博客的域名一直用的是默认的 xizhibei.github.io，之所以没有用自定义域名，也就是考虑到 GitHub 自定义域名不支持 HTTPS。而如果一定要使用，则必须在其它进行一些设置，比如配置 CDN，来将 GitHub Pages 当成源站。

前言

服务的稳定性，对于任何一个在线提供给用户服务的公司来说，都是非常重要的，更遑论当这个服务是与充值消费相关的时候。

话说，在很久以前的程序界，是没有内存垃圾回收这种说法的，大家习惯于被 C 以及 C++ 的内存问题各种花式吊打。

直到有一天，John McCarthy 大神 1959 年在 LISP 中实现了内存垃圾回收，大家才惊奇的地发现：『居然还有这种操作？』。
正如 iPhone 出来之后重新定义了手机，内存垃圾回收的出现无异于重新定义了高级语言。

其实今天的文章算是 APM 以及 Node.js 探针原理 的续篇，在去年介绍了一些原理之后，其实还有很多地方没有说清楚。

之前在 谈谈如何当一名合适的面试官 说了很多，但实际操作起来，会有很多的差别，现在把这几周的想法总结下。

背景

1. 我们线上的 k8s 集群是使用 ansible 安装的[1]，使用的是 coreos 提供的 hyperkube 镜像中的可执行文件（其实之前也提到过类似的：CentOS 7 使用 ansible 搭建 kubernetes）；

春节过完，我等外来务工人员又开始向一线城市聚集了，回到了熟悉的工位上，而接下来是三四月份，俗称金三银四，是我们蠢蠢欲动的时候，你今年可要跳槽？

最近这些天，算是刷新我对于黑产的认知。

最近对 TypeScript 很是着迷，或者说是在使用的过程中找回之前使用强类型语言写后端程序的感觉，在介绍 TypeScript 之前，先简单说说 JavaScript 的历史。

从前年开始，我开始用 GitHub issues 写博客，写到去年的时候，逐渐意识到，GitHub issues 还是有一定不足的，比如一个很关键的点：无法查看有多少人看了你的博客文章之类的运营数据，所以那得使用 Google analysis 之类的分析工具。

又是一年过去了，在这一年里，似乎很多事情还处于未完成状态，但是，时间不等人，掐指一算（打开了 Excel），我的人生也已经过去了 10000 多天，至少三分之一已经入土 (是的，扎心了）。

• 原文：https://www.targetprocess.com/articles/speed-in-software-development/
• 作者：MICHAEL DUBAKOV
• 译者：xizhibei

译者边注

这篇文章是几月前看到的，现在打算翻译一下来回顾以及加深里面的内容，作者以系统思考的方式论证什么因素对于软件开发速度是重要以及不重要的，以及它们之间的复杂关系，文风诙谐幽默，可读性非常高，最后相信你会从线性思维方式的方式转变过来，能够认识到软件开发速度不是单单靠某个因素就能提高的。

每一个 IT 公司的 CEO 都希望开发软件的速度能再快些，而时间又是最昂贵也是最有价值的资源，因此你不能把它浪费在返工、重构、开会甚至体育活动上面。是吗？看情况。