本文是首发于个人微信公众号的文章“TB一周萃选[第8期]”的归档。

再看看那个光点，它就在这里。那是我们的家园，我们的一切。你所爱的每一个人，你认识的每一个人，你听说过的每一个人，曾经有过的每一个人，都在它上面度过他们的一生。我们的欢乐与痛苦聚集在一起，数以千计的自以为是的宗教、意识形态和经济学说，所有的猎人与强盗、英雄与懦夫、文明的缔造者与毁灭者、国王与农夫、年轻的情侣、母亲与父亲、满怀希望的孩子、发明家和探险家、德高望重的教师、腐败的政客、超级明星、最高领袖、人类历史上的每一个圣人与罪犯，都住在这里——一粒悬浮在阳光中的微尘。

但在浩瀚的宇宙剧场里，地球只是一个极小的舞台。

——卡尔·萨根 《暗淡蓝点》

笔者注：那个光点所指的是1990年旅行者1号于距地球64亿公里处最后一次回望母星的照片中的地球，它只是一个占用2-3个像素的光点。

这一周，我们被“超级月亮”、“红月亮”、“月全食”等关键字刷屏了。月全食并不是稀罕物，据说一般2年就会有一次，而且由于是体格巨大的地球遮住月球，因此可观赏的地域也是很广阔的，与稀罕的日全食有大不同。这次月全食的特殊之处在于月亮恰位于公转的近地点，看起来大一些罢了。即便大，也有很多人不屑去看，但更多的人选择关注这个事件，并抽空儿抬头瞄上两眼，还有一部分更为执着的天文爱好者们冒着严寒，移步到远离市区的户外，就为了能最大程度降低城市光污染对观赏的影响。

对地外星体或天文现象的关注，古人早已有之。只是古代人不明其理，以神秘或神灵释之。究其深层原因？人类为何从古自今保持对地外事物的关注，仅仅是看客？仅仅是好奇么？从每个个体的角度来看也许是这样，但从人类文明整体的角度来说，这是根植于我们人类古老的基因所决定的：人类社会终极目标就是要不断的生存和繁衍下去，世世代代，子子孙孙无穷尽也。古时人类即是如此，但苦于能力不足，无法将手臂伸到地球之外。但随着人类文明演化和发展，尤其是当人类科技发展突飞猛进之后，人类逐渐意识到：“地球也许是我们的第一个家，但可能不是我们唯一的家”。“人类生存和繁衍”的使命促使着人们不断地走出地球，其第一要务就是找到合适人类生存的第二家园或更多家园，附带的任务可能是为人类在茫茫的宇宙星海中找到其他“邻居”。

只是和科幻片中的宇宙探索进展相比，现实中的我们的进展还是太缓慢了。

一、一周文章精粹

1. 写Go代码时遇到的那些问题[第2期]

年前开启写的一个Go coding系列，这里广告一下。第2期内容关注了dep的日常工作流、“超时等待退出”框架的一种实现以及Go testing中的fixture的setUp和tearDown，欢迎交流。

文章链接：“写Go代码时遇到的那些问题[第2期]“

2. 使用不到200行Go代码实现你的区块链

2017年以来，随着比特币价格的爆发，区块链技术热度也逐渐走强。对于技术人来说，区块链是什么不能仅停留在口头上，Show your code更重要。这篇文章旨在以Go代码从头开始实现一个简易区块链的demo，目的是帮助你理解区块链背后的原理。

文章链接：“Code your own blockchain in less than 200 lines of Go!”

3. “The Good Way to REST”系列

自从Roy Thomas Fielding在他2000年的博士论文中提出了REST(REpresentational State Transfer)设计原则后，RESTful架构一度在Web Service的领域占据了大片领地，直到近几年RPC的兴起，RESTful才有了一副“过气网红”的样子。总体来说，RESTful已是一门成熟的设计技术原则。REFINERI咨询师Berat Daglar撰写了三篇文章，对REST的概念、原理机制以及发展过程进行了介绍和总结：

文章链接：
* “The Good Way to REST: Introduction”
* “The Good Way to REST: Core Values And Mechanics”
* “The Good Way To REST: Road to Maturity”

4. Apollo 2.0框架和源码分析(一)

Baidu的Apollo自动驾驶平台一经发布就受到了广泛的关注。其最新Apollo 2.0更是具备了实现简单城市道路自动驾驶的能力。

知乎专栏上的这篇“”文章为大家详细介绍了Apollo 2.0软硬件框架结构。但源码分析还要等后续部分出炉。

文章链接： Apollo 2.0框架和源码分析(一)

5. Go package import全面总结

Go基础知识范畴，该文对Go中各种形式的import用法进行了梳理，初学者可以看看。

文章链接：“Go tips and tricks: almost everything about imports”

二、一周资料分享

1.远程工作指南

在这个网络时代，远程工作的方式越来越多的被很多个人和公司所青睐，其尤其适合程序猿、撰稿人等以计算机为工具进行“创作”的键盘族，一台电脑+一根网线（一个无线路由）足矣。remote working形式还尤其适合“松耦合”、初期无固定办公场所的初创公司。

但对于一个公司或组织而言，采用远程工作的方式还是有一定挑战的：比如：如何招聘到正确的人、高效沟通、有效管理、远程工作文化的建立等。这些都可以从下面这份远程工作指南的资料中找到。

资料链接：“远程工作指南”

2. Hacker 101指南

“安全”永远是影响广泛但从业人员又相对小众的领域。对于一般开发者而言，“安全”永远是被最后考虑的topic，而所谓的安全问题又都是开发者“一手造就”的，这似乎是一个死结。

hacker101.com网站推出了free的web安全视频课程，从名字中的“101”我们也可以知道这是一个入门课程，课程包括会话安全和漏洞两大主题，值得一看。

资料链接：“Hacker 101 Guide”

三、一周工具推荐

1. vscode+vscode-go+vscodevim组合

再吹一波vscode!

之前曾写过一篇文章《使用Visual Studio Code辅助Go源码编写》，那个时候我依然以Vim为主，vscode为辅。不过当时在文章中我就提到过vim结合vim-go在我的机器上存在的一些问题：比如save文件时非常慢、光标移动后光标下的字符显示异常等。这些问题我个人猜测与vim-go使用的相关插件的性能有关，也许也和我的单一GOPATH目录下go packages过多有关。不过，无论怎样，vim下写Go代码的体验日益糟糕。

因此在这两个月编码较多、task较为急迫的情况，我切换到了“vscode+vscode-go+vscodevim”组合，这以后除了因gocode偶尔崩溃导致的自动补齐失效(可以重启gocode解决：gocode close;gocode)之外，基本没有遇到什么较大问题。

可以说vscode为多种编程语言的程序员之间提供了一种通用的“工具”语言。可惜在android mobile或pad上无法使用vscode。

工具链接：vscode

四、一周图书推荐

1.《Designing Distributed Systems – Patterns and Paradigms for Scalable, Reliable Services》

Brendan Burns目前是微软azure的技术工程总监，但其更响亮的title是之前在Google Cloud Platform工作时和Joe Beda、Craig McLuckie一起发起了Kubernetes开源项目，开启了分布式计算的新时代。

近期Brendan Burns刚刚发布了自己的新书《Designing Distributed Systems – Patterns and Paradigms for Scalable, Reliable Services》。在书中，Brendan Burns借用软件设计模式的概念阐述和总结了构建一个可靠、可扩展的分布式系统时可能使用到的一些“模式”：

• 单机模式(Single-Node Patterns)
  • 边车模式 (Sidecar Pattern)
  • 大使模式 (Ambassador Pattern)
  • 适配器模式(Adapter Pattern)
• 服务模式(Serving Patterns)
  • 带负载均衡的多副本无状态服务(Replicated Load-Balanced Services)
  • 分片服务(Sharded Services)
  • 分散/聚集(Scatter/Gather)
  • 函数即服务和事件驱动处理(Functions and Event-Driven Processing)
  • 分布式选主(Ownership Election)
• 批处理计算模式(Batch Computational Patterns)
  • 工作队列系统(Work Queue Systems)
  • 事件驱动批处理(Event-Driven Batch Processing)
  • 协作批处理(Coordinated Batch Processing)

该书完全面对基于容器以及容器调度管理平台的构建的分布式系统，是云原生时代不可多得的技术参考书。该书由O’Reilly出版，目前在azure的站点上可以免费下载。

图书链接：《Designing Distributed Systems 》

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式：

微博：http://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作

昨天中午收到图灵出版的《布道之道 – 引领团队拥抱技术创新》一书，晚上就迫不及待地翻看开来。这是我读过的第一本有关推动组织内部技术变更/创新实践方面的书，感觉书作者对受众的分类很是准 确到位，很多布道技巧也十分值得借鉴。但就我个人多年来的体验来看，组织内部技术布道的结果，不仅仅与受众的类型有关，还与布道者自身的资历、所担任的角 色、组织内部的文化和环境、布道路线以及布道时机和对象的选择有一定关系。下面就是我在这方面的一些粗略心得。

一、技术布道结果的影响因素

我个人也算是组织内部的一个技术布道者，经过多年的碰壁和反思，感觉技术布道的结果好坏与下面的一些因素或多或少有些联系。

* 布道者的资历

无论国内国外(国内可能尤甚)，职场资历这个因素在任何职场活动中都会是一个影响因素，技术布道也不例外。如果你是一个职场新人，也许工作年头不超过一两 年，甚至是刚刚进入职场，你势必人微言轻，并尚未在组织内建立起信任，更重要的是你可能并未深入理解大家面对某种新技术或新实践时遇到的真正困惑以及问题 是什么，这时如果你在组织内尝试大力推动某种技术或实践，效果可能不甚良好：你会发现关心你的提议的受众会很少(除非之前就赢得了上层领导的支持)，你会 受到大家对你的资历的质疑："你才刚来，这东西你自己用过吗？你怎么就知道这东西会对组织带来价值？你讲的这些我都知道，但我们遇到的问题你并没有真正解 决"。记得2007年一位刚刚入司不到半年的新同事(我们得承认这位同事很有技术潜质，也很有技术热情)就在项目组内部大力推广设计模式，并多次在项目组 内部以技术沙龙的方式分享设计模式相关的知识，但效果并不好，以至于若干个月后，这位同事离职后，大家依旧如故的行事，设计模式也并未真正被用到产品代码 设计中。

相比之下，一些组织内资深的布道者反倒更容易推动组织内的技术变革。

* 布道者的角色

一般来说，技术布道的发起者多为组织内的纯技术人员或技术管理者，但也不能排除非技术人员(如：过程改善人员或高层管理者)发起技术或优秀实践的布道。纯 技术人员或技术管理者因其技术背景并深处其中，布道过程中其同理心更强，布道思路更符合大家的胃口，但效果因人因地而异；而过程改善人员或管理人员多半采 用是行政命令的灌输式的方法，强行推进技术或过程改革，这样做常常会遇到抵触或反对意见，短期内可能有效果，但长期结果却往往不佳(当然也有例外)。

* 组织文化的开放度

如果你所在的组织内的成员都抱有一个Open的心态，那恭喜你，你真是太幸运了。你的布道实践一定是相对顺利的。但实际情况中，大多数组织的文化可能没有 想象中的那么Open，大家对变化的第一反应就是"抵触和反感"– 好好的，为什么要变？你也可以说这是人的天性 – 习于安乐。显然在这种文化下进行布道，阻力将会较大，布道者需要做足准备，方可开始实施，即使如此也未必能取得很好的效果。

* 布道路线的选择

布道的路线无非两种：自上而下和自下而上。普通技术人员(包括一部分技术管理者)，多是自下而上，通过布道，说服项目组成员以及管理层使用新技术/新实 践。爬坡总是困难重重的，要想取得良好效果，需更多努力；技术管理者或其他管理人员可能采用自上而下的方式，告诉大家我们应该更换技术，采用新优秀实践， 多半相对顺利。如果你的技术的确解决了大家的问题，让大家平时的工作更"舒服"，自然就更受欢迎，推行起来也就水到渠成。

* 布道时机和对象的把握

变化是需要用成本买单的，既有人力成本，时间成本，甚至包括机会成本。如果你非要向一个下周就要发布的项目组推广JUnit，非要向一个工期仅有三个月且 交付后无需维护的产品线推广持续集成/交付，那你肯定是自找苦吃。这些例子都说明了一点：把握好布道的时机和对象。人家都忙得脚打后脑壳了，你还给人加添 乱，显然时机掌握错了；你推广的东西除了增加成本并未带来任何好处，显然对象选择错了。正如《布道之道》一书中提到的那样：你推广的成果(技术或工具)应 该可以让受众至少感觉到如下价值之一才行：提高了效率；降低了风险；增进了理解。否则你就找错了推广对象。

二、技术布道的有效实践

弄清楚上面的影响因素后，我们就可以谈谈一些利于收获良好结果的技术布道的有效实践了。

* 从问题出发，选择要布道的技术/工具

前面说过，你布道的成果(技术/工具/优秀实践)是需要给大家带来价值的，这其中主要的方面就是为了解决大家目前所面临的问题，比如开发效率不高、系统部 署繁琐、人工回归测试工作量巨大等等。因此只有当你觉察到这些问题，并对这些问题深入理解后，再去选择你要布道的技术/工具/最佳实践；否则如果只是为了 引入新技术而引入新技术的话，那么引入的技术和工具就好比无源之水、无本之木，没有长久的生命力。

* 选择合适的受众与时机

布道所推广的技术和工具多不具有普适性，它在一定受众范围内是有生命力的。因此在谋划布道之前就要考虑好对象。甚至可以在布道之前先深入到选定的受众当 中，对受众以及他们所遇到的问题进行相关的调查和分析，这样做才能事半功倍，布道的结果才可能更佳；另外在确定受众后，就是选择布道时机的问题了，时机的 选择因情况而异。但无论如何也不能犯上面提到的那些错误，否则你的努力将付之东流。

* 以点及面，划分阶段

受众面越大，布道的结果可能越不易理想。因此，最好先在小范围内布道并给予持续支持，直到该技术/工具/实践在小范围内变得不可取代并看到了成果，再向更 大的受众范围推广，此时之前那些已经尝到甜头的受众将会成为你下一阶段布道的强力助手。另外阶段性的布道还有助于你进行自我挑整，修正之前的不足，找到更 为合理的策略和方法。

* 利用局部布道成功结果的影响力说服更广范围的受众

人们都信奉"眼见为实"，因此将前期小范围布道的成功结果会让更广范围的受众相信你推广的技术/工具/实践将会给自己带来价值。这要比你口若悬河般的说教好上百倍。特别是在说服管理者时，这尤为有用，甚至决定成败的那个最重要的因素。

* 建立信心和耐心，潜移默化中布道，甚至先斩后奏

对于一些之前布道失败(无论是否是你推广的，包括那些被管理者否定的)的技术/工具/实践，只要你认定(在对问题的深入理解的前提下作出的判断)它会带来 价值，那就不要放弃，要有些耐心。并运用上面那条实践，先在局部尝试，影响小范围受众；收到显著成果后，再扩大受众面，用现有的成果说服他人，或甚至直到 当管理者问及你是如何取得这个成果时，你再告诉他：是因为我用了XX技术/工具/实践。

* 降低目标预期

最后这点算不上什么有效实践。对于布道者而言，如果要想保持一个持续向前的心态，保持持续关注前沿技术的动力，降低布道结果对你的负面打击，那就在布道之前降低你的目标预期吧。

最后切忌犯一个错误，那就是：只懂皮毛，就去布道推广(多数都并非出于解决问题之目的)。这样做的结果只能是失败，并很可能让大家失去对你的信任。这个错误自己犯过，见过职场新人犯过，也见过牛人犯过。