工程师是一条艰辛的修炼之路，管理者同样，只有不断思索，才能领悟到团队、领导、和自己想要什么，不想要什么。
管理可以细分出很多领域，也有很多方法论，我党长期坚持使用的双头领导制是其中经典，司令和政委、厂长和书记……都是管理者，但要求的技能和心智是不一样的。一些大公司也会照着这个模式建设所谓的“矩阵式”管理架构：称之为“项目线领导”和“职能线领导”，或者平常口头上简单的称之为“管事”的领导和“管人”的领导，虽然不完全合适，但更好理解一些。小公司则可能一个领导即主战、又主建。
对于通常意义上的管理者（管事+管人），我总结了 9 项职责，再分之成三重境界。我认为一位管理者把自己的时间和精力主动地、特意地放在哪些职责上，可以体现出他在管理上修炼达到的 Level。
作者是阿里的中间件架构师，北联业务，南接数据库，所以在数据库上着笔最多。但为了不写成太技术流，把阿里的共享服务和中台战略在书中四处撒播。还好书名比较贴切的表达了全书主旨：阿里 IT 架构的演进史。
读完此书，可以对淘宝、天猫、聚划算……背后的很多系统有个概要的了解：HSF、TDDL、Tair、鹰眼、Sentinel（哨兵）……，对一些阿里使用的技术也能够略知一二：超配、限流、埋点、ACID/CAP/BASE……
通篇着笔最多的就是“共享服务中心”了，阿里专门做中台组件的部门，伴随 2015 中台战略而崛起的部门，让作者充满自豪感的部门。几乎每个章节都介绍了一到两个服务组件，读完之后对阿里 PaaS 层的技术组件和中台业务的逻辑分解都会有一定的认识 。我曾经认为 IaaS/PaaS/SaaS 是技术架构，前/中/后台是业务架构，读完之后我觉得应该这么讲：IaaS/PaaS/SaaS 即是技术架构，也是业务架构，因为全书给读者传达一个理念：技术的逻辑模块要从用户的角度按业务来分解。
另外，文中有几个观点也颇有同感，我试着理解一下：
摘要：
字幕文件通常不嵌入视频文件，独立的字幕文件利于：存储、修改、分享、多格式、多编码……
在书籍上直接标注（Annotation）或注释（commention），即 内嵌为书籍的元数据（meta data），不但破坏了原书，干扰了读者，也不利于修改、分享、尤其是合并，多人的标注能够合并、修订……这才是我们想要的。
针对不同格式 pdf（azw、epub……容我以后再研究研究）有不同的软件可以实现此目的，此处列举几个。
如果这些问题存有疑惑，可以读一下此文。
Feedly 前段时间升级，侧边栏做了修订，新增了 Dark 模式（但还是欠火候，对比度太晃眼，达不到 IDE 的水平，要有点灰度才显得高级）。
添加 Feed、Dark 模式、Support 3 个图标单独搞了个侧边栏 —— 这么占地方，不是很喜欢。
此次修订同时修改了网站获取图标的方式，以前一直能够正确的获取，效果是这样的：
摘要：
github 能够与多种持续集成（CI）和持续交付（CD）工具融合，github 的 marketplace 中有整理好的一份 CI 工具清单，里面列了 20+ CI 工具，其中 10+ 个还带有“Verified by Github”的绿色认证标签，2017 年 github 推出过一篇blog，统计出 top10，Travis、Circle、Jenkins 为前三，但 2019 年我想估计排位已经变化了，至少上面清单中已经找不到 Jenkins 了。
Travis 等工具的 CI 功能相比 Jenkins 会弱一些，可配置性、灵活性、和插件都不可比，但 travis 不需要自己搭建和维护 CI 服务器，github 上 public 项目就免费提供服务，Jenkins 则需要自己搞台电脑 or 云主机，两者一比，免费的午餐又胜利了。
摘要：
python3.X -m pip install来安装，虚拟级 source 后可直接pip install。虽然一直都用虚拟环境，但还是想把系统安装的 python 路径整理一下，今天了结这个心愿。
