之所以想写这个，也是时机到了，因为上周看了一眼自己团队管理的服务器数量，不知不觉已经达到一屏幕都放不下的程度了，好还自己当初强制规范团队统一内网域名格式，不然现在真不知道怎么管理。 其实回想起来，管理内部网络还是不够规范的，因为现在还是允许团队直接连接生产环境内网登录机器的，也就是开发与生产环境没有隔离。这么做显然有点不安全，这当然会在之后有足够精力后会去...

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

上上周去旅游了，写了篇自己都觉得比较水的文章，这周补上一篇。 :P 近几个月开始将现有的 Node.js 服务重构为 Golang 服务，其实这个计划去年就开始制定，并且在很长一段时间里面都在准备基础： 设施：自动化运维，日志以及监控； 知识：Golang、框架微服务架构的设计以及业务的梳理； 接下来先从介绍开始。 Go kit 简介 Go kit 是...

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

前言 服务的稳定性，对于任何一个在线提供给用户服务的公司来说，都是非常重要的，更遑论当这个服务是与充值消费相关的时候。 于是，任何一次线上事故，都可能会给公司带来显而易见的损失：因为相比于其他部门，负责服务端的小伙伴们，发生事故的时候很容易暴露在风口浪尖之中，一次代码 Bug 或者数据库调整等变更，都可能带来直接的损失，并且这种损失是快而直接的，出问题那段...

话说，在很久以前的程序界，是没有内存垃圾回收这种说法的，大家习惯于被 C 以及 C++ 的内存问题各种花式吊打。 直到有一天，John McCarthy 大神 1959 年在 LISP 中实现了内存垃圾回收，大家才惊奇的地发现：『居然还有这种操作？』。 正如 iPhone 出来之后重新定义了手机，内存垃圾回收的出现无异于重新定义了高级语言。 好，接下来开始...

其实今天的文章算是 APM 以及 Node.js 探针原理 的续篇，在去年介绍了一些原理之后，其实还有很多地方没有说清楚。 不过，开头还是先介绍下分布式追踪。 简单介绍 分布式追踪在微服务领域非常重要，因为服务一旦多了，就涉及到性能瓶颈分析与线上问题排查、服务之间的关系梳理等等，这在单体应用的时候，非常简单，你甚至在本地就能解决，但是在一个比较大的公司内部...

之前在 谈谈如何当一名合适的面试官 说了很多，但实际操作起来，会有很多的差别，现在把这几周的想法总结下。 最近接连面试了 30 多个候选人，然后只通过了三个人，这三个人有什么特点呢？ 基础扎实 善于沟通 积极主动 现在就来说说，我为什么看重这三点： 基础能力 这个不用说，其实当年我也犯过这个错误：校招面试的时候，面对面试官各种苛刻的提问，很多都答不上来...

背景 我们线上的 k8s 集群是使用 ansible 安装的[1]，使用的是 coreos 提供的 hyperkube 镜像中的可执行文件（其实之前也提到过类似的：CentOS 7 使用 ansible 搭建 kubernetes）； 跑的应用主要是线上离线任务，属于即使挂掉一阵也不会影响到正常业务的那种，部署了 15 个 Deployment； 部署的...

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

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

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

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

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

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

译者边注

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

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