四月慢慢找回了节奏，至少这期没有再拖到月中才做。整理的时候发现，从朋友圈中收藏文章的数量快赶上传统从RSS订阅里收藏的文章数了。看来技术还是在慢慢地在分分秒秒中无形的进化着，看似缓慢却又无限迅疾。想了半天也没给4月刊想出一个满意的副标题，正如第一篇文章《DevOps》中评论的那样，命名永远都是困难的，认怂了，就叫无名吧。

DevOps中文名称: 开发自运维

“语言的边界就是思想的边界. 一个精确表达概念的词汇将阻止误解的产生.”。确实“开发自运维”这个名字是我到目前为止觉得对于DevOps最合适的中文翻译，一个好的名字会让人有一拍大腿的冲动，消除了歧义和误解。又一次证明了作为TwoHardThings中的“naming things”的重要和困难。歪楼一句，希望“客户自开发”的日子晚点到来。

帅爆了的 RSpec 测试结果显示方法：Philips Hue

帅爆了，从最早的熔岩灯到后来见到过的自动瞄准火箭炮，无聊的程序员们一直没有失去对于酷炫的测试或是构建失败提醒机制的探索。如今到了智能硬件和智能穿戴的时代，什么电击手环、自动关空调，或是谁弄挂了Build始终有个光柱跟随之类的，估计很快就出来了，只有想不到的没有做不到。

架构之重构的12条军规（上）

和前一阵的工作内容相关。对于架构级别的重构，其实本质上和代码级别的重构是一样的，无论是定义还是原则甚至手法。首先要搞清楚解决的问题，避免陷入为了重构而重构或是为了升级而重构的陷阱；开始之前要保证有充分的测试保障；保持重构的节奏，从识别一个问题或是Smell（例如组件依赖混乱）开始到消除这个Smell结束；过程中要力争保持系统的随时可用（随时都可以通过所有的测试，可随时提交）。记住重构的手法（心法）对于架构级的重构依然有效，还是那16字真言：旧的不变，新的创建，一步切换，旧的再见。

TW洞见｜基于微服务架构，改造企业核心系统之实践
专访ThoughtWorks王磊：微服务是互联网时代的必然

微服务虽然概念已经不是很新了，从最新的技术雷达来看现在是越来越成熟，无论是理论基础还是工具支持，包括成功案例。王磊在第一篇文章中总结了微服务的各种好处。不过真正尝试过的人肯定会有更深的感受，就是在这些好处背后微服务也会带来各种新问题：包括如何确定服务的粒度和拆分问题，以及对于构建部署运维测试的更高要求，包括与性能之前的平衡。对于这些问题，在第二篇的专访中，王磊有给出了自己的想法。话说回来，任何新的技术在解决一些老的问题的同时往往都会引入一些新的问题，我们有时候需要勇敢一点，技术和社会不就是在解决一个接一个新的问题的过程中不断进步的么。

哪些镜头是演员失误或出现意外成就的经典之作？

关于《纽约灾星》的回答太曲折离奇了，居然还是个纪录片，也就是说所有的都是真实的，“主角”就是事件的本人。果断去网上看了一下第六集的结尾部分，德斯特和采访人的对话以及之后在洗手间的喃喃自语，这是只有真实才能带给人的那种触动和冲击，不得不感叹，生活才是最好的导演！

其他好的资源汇总
AngularJS的启动引导过程
现代JavaScript开发者的工具箱

本文转载自健荐公众号。

原文链接：
https://mp.weixin.qq.com/s/c8xXkJDGJkrh1ueeTnkcCw

创作场景

DevOps 中文名称: 开发自运维