关于『设计一个微服务治理的工具』这个想法，我已经酝酿很久了。但是，你懂的，又是因为种种原因，我搁置了蛮久了。最近，刚好因为在研究『架构适应度函数』，所以，我有了一个新的想法。微服务架构治理，看似和架构适应度函数并没有啥关系。但是，我设想的是一个用于『微服务治理的架构适应度函数』。
IDEA 是我日常使用最多的开发工具之一，大概仅次于 Firefox （Google 和 StackOverflow 是生产力）和 iTerm 2。因为研究编辑器和 IDE 的关系，我研究了一段时间的 IDEA 插件的相关机制。其中作为研究的主要对象是 Android Studio 对于 Android APK 的构建部分。
日常的搬砖过程中，我们总会因为代码上的一些设计问题，进行争论。而最后结果呢，可能就是『show me you code』，又或者是『你行你来』。
最近，我又挖了几个开源项目的坑，Ledge、Ledge Framwork、Igso 等等。每次挖新坑的时候，经常性地都要花很多的时间，想着怎么编写 README、完善 README。而就是这么一个简单的 README 的编写，它都要花费我相当长的时间，或是几个小时，或是几天。
很早以前，我便想着写一篇文章吐槽一下数字化时代。如果你熟知我在开源世界的贡献（代码 + 内容），就知道我一直是开源软件、自由软件的拥趸：RMS 一直是对的 [🐶🐶🐶] 。
12 月初，ThoughtWorks 开始了 Annual Review 的 Kick Off，我开始总结这一年的工作，与此同时，我也开始总结我的 2019 节点。今年仍然是『平淡无奇』也过完了重要的一年。
最近，经历了一系列代码吐槽事件之后，结合公司大佬的观点之后，大体上对于程序员的编码 level 有一个更好的认识。所以，我决定写一篇文章，以此来划分不同的程序员。我知道为别人打标签是不对的，政治上是不正确的，但是我不会明着对你说的。每个人在自己心里都有的一杆秤。
再三犹豫，终于在 rebase 到上海之后，还是决定写下这篇文章。三年多以前，我 rebase 到了深圳，开始了国内交付项目的旅途，我也几乎成为了待在该 account 下最长的 developer 没有之一。在那之前，我在 offshore 项目，混吃混喝混 session。
在科技公司，诸如于 ThoughtWorks，当你在等待项目 / 两个项目之间 / 没有项目的时候，这段时间称为 bench （冷板凳，笑） 又或者是称为 beach。
最近，我困扰于『知识管理』——其实一开始，我并不知道我需要的是它。在我打算买几本 Kindle 电子书，以消磨一下时间的时候，我发现了『知识管理』相关话题的电子书。我这才意识到，我迫切需要一些新的工具来管理知识。