2018年3月过去了，我收获到什么？
最大的收获自然是我和 Joe 老爷子访谈，它是无价的。我前些日子已经放了篇文章：Joe Armstrong 面对面。没看过的同学可以点进去看看。我希望我六十岁时，也能像老爷子一样，睿智，洞悉世事，和我聊天的人都有这样的感觉 —— 就跟 Frodo 憧憬未来时夸赞 Sam 那样：Tyr the thinker。
Code Beam 演讲
这次 Code Beam，我做了一个三十多分钟的演讲：Release, Deploy, Upgrade, Monitor Elixir Services in Real World。题目长到没朋友。Slides 可以去我的 github：tyrchen/unchained 捞。视频地址：
https://www.youtube.com/watch?v=kwHtlmyxE6c
稿子我改了五版，直到上台前十分钟，我还在做最后的修改。这个稿子完全用 notability 手绘而成，算是我这三个月使用 notability 的集大成者。我给 Joe 老爷子看我的初稿，还成功说服他也买了一份 copy 呢。对 notability 的使用，我即便说不上是超神入化，也对得起出类拔萃 —— 我能够更好地控制版面，我对颜色的使用日渐稳定（形成自己的体系），我对构图越来越精进，能够更好地表达我的意图，我还制作各种不同的 template，在不同的场合使用。最重要的一点 —— 现在全手绘已然不是瓶颈，大多数时候，我用 notability 手绘的效率，比用 grafio，gliffy 的效率还高不少。如果大家感兴趣，我改天写篇关于如何使用 notability + iPencil 提高效率的文章。
rehearsal 我做了两遍。一次 BBL，讲给 US Eng team 听；一次 elixir knowledge share，讲给 China elixir team 听。两遍 rehearsal 下来，让我对所讲的内容，关键点，以及时间有不错的把握。rehearsal 和我最后的 talk 出入不小，这得益于 Joe 对我的提点。我虽然对 Great leaders start with why 这句话倒背如流，可在自己的如此重要的 talk 上，还是对 why 重视不够，如果不是 Joe 吐槽，我可能会做一场非常平庸的演讲。“what problem have you solved? Why it matters to me?” 是每个演讲者都应该重视，并且首先讲明白的问题。
我的演讲本身还是有不少毛病 —— 手势太碎，目光太多聚焦于讲稿而非观众，从头到尾拘囿于一方讲台，没有太多移动，着装可以再精干些，语言可以再简练些，铿锵有力些，少点嗯嗯啊啊，多些着重句子之后的停顿。不过对于第一次对外的英文 talk，我觉得已经不错了 —— 我给自己打 80 分。不积跬步无以至千里，慢慢来。
Erlang VM 培训
这次 Code Beam，我还参加了当周周六的 Erlang VM 的培训。讲师 Erik Stenman，Beam Book 的作者（我就是因为看了他的书才关注他的）。Erik 博士看着憨憨的一个工程师，其实 NB 得不得了：他 PhD 参与了 erlang 的 HiPE 项目（Erlang Native Compiler），让 Erlang 的执行效率提升 10-50 倍；Post Doc 参与 Scala 第一版 compiler 的开发，为 Scala 完成第一个可用的 compiler。这样一个牛人一天的培训才 300 刀，到哪里找这样的好事去？我去年写过一篇文章：当我参加培训的时候，我在学什么？不知道有多少人看过，又有多少人真正将其策略性地应用于自己的工作生活。
对于这种档次的大会的培训，学什么主题其实并不重要。重要的是你选择什么样的讲师，你想从讲师那里得到什么？不要把培训看成培训，把培训看成是廉价的，对等的咨询的机会。 300 刀一天你找 Erik Stenman 咨询，这跳楼价可以笑到尿裤子吧。我的朋友小山同学显然从我那篇文章里得到了启发，这次花三天时间参加 Joe 老爷子的培训，一千多刀，从老爷子里那里学到很多人生经验（我看他的笔记本上小抄抄下不少），还和老爷子混的谙熟，我这次能跟老爷子约上两个小时单聊，也源自他的大力举荐。
所以，善用培训。善用讲师的时间。花点时间了解讲师，做些功课，看看你想从中得到些什么，或者你能从中得到些什么。说服你的老板把培训费用给报销（连这种费用都不给报的老板，可以把他炒掉），然后把你所有想问的问题都整理出来，利用培训的间歇（一天的培训，茶歇 + 午餐 + QA，怎么着也能匀出来两三个小时），好好「咨询」。:)
我这次本来打算培训前把 erlang emulator 的源码走一遍，攒一堆问题问 Erik，无奈最近在参会和公司的大项目两相夹击下，身心俱疲，没有功夫读代码，只得把 Beam Book 草草过一遍，问了些问题，然后又追着 Erik 聊了不少关于 aeternity 的问题。
去年我参加 OTP training，结识了erlang solution 的老大 Francesco，我们建立了深厚的联系，我去北京出差前我还邀请他来 Tubi HQ 参观，顺便探讨 Hive 和我做的 Overseer；等忙完这一阵，我也会和 Erik reconnect，好好向他取经 aebytecode（ae 里面处理 smart contract 的 compiler）。
Data Center 迁移
在 Tubi，过去的几个月我们一直在忙活一个大项目：data center 的迁移。把所有的服务和数据从一个 data center 迁移到另一个 data center 这样的事情，比我们大的公司要么不需要去做，要么有专门的团队处理；比我们小的公司要么还没遇到这种烦恼，要么一开始的设计就很好，避免这样的问题。我们不大不小，又背着数年的技术债，所以工程师才有机会接受这样空前的挑战和考验 —— 可能一辈子也不会遭遇第二回，实在是天赐的机会。data center 的迁移，不算是个脑力活，更多考究的是体力，韧性，和统筹能力。好几种形态各异的数据库服务，几十个 service，几百台机器，以及长长的 action list，由约莫十个后端工程师在流量低峰期的几个小时内迁移完毕，并且要尽可能降低对用户的影响和广告收入的影响，不啻于在一架正在飞行的飞机上更换引擎。几个月的努力，毕其功于一役，每个人所经受的压力非同寻常。
两周前的周四凌晨，也就是我出差前两天，我们的后端团队破釜沉舟，成功完成了这个壮举。详细的过程，有机会我会另行撰文总结。这里说两点收获。
《礼记 中庸》里曰：凡事豫则立，不豫则废。言前定，则不跲；事前定，则不困；行前定，则不疚；道前定，则不穷。我们做事前如果先有详尽的计划和准备，发生让自己追悔莫及，走投无路的事情的概率就大大降低。Data Center 的迁移，是个苦活累活，考究的是事无巨细均考虑周全。我们都有哪些 service 和 database，哪些对外，哪些对内，哪些第三方，哪些自研，谁来负责，目前状态是什么，ETA 是哪天，这样的 responsibility matrix 要构建好。迁移时分几个阶段，迁移前几个小时干什么，迁移时 DNS 切换的先后顺序，迁移后都要验证些什么，如果出现问题，预案是什么。就跟下棋一样，一步步要先尽可能考虑清楚了，省得到时候焦头烂额，急中生错。这是其一。
其二是测试的重要性。即便新的 data center 测试无误，还是需要导入一些 production 的流量验证 —— 我一直有个担心：新的 Data Center 使用新域名 abc.com，所有的 client 使用 tubitv.com，即便 abc.com 一切服务无误，我们却很难保证当 tubitv.com 指向 abc.com 对应的服务上去时不出错。Tubi TV 整个 business 的麻烦之处是，client 太多太多，有些 legacy 的 client 对于我们自己来说都是黑盒。因而，我们不得已想出了一个非常 hack 的方式来测试 —— 把公司 HQ 的 DNS 服务器切换到了自己用 bind9 搭的 DNS 服务器上。这个 DNS 服务器会 hajack tubitv.com 的所有子域名，指向新的 data center，同时 forward 其它 DNS 请求。这个方法让我们在公司内部 eat our own dogshit，帮助我们测试出了一些严重的，我们完全没有预料到的 bug。
Blockchain 分享会
我每次出差都尽可能举办个活动，做点分享。这次出差一周，本想简单点，做一个知乎 live，讲讲 bitcoin —— 自从我写文章介绍我在 Tubi 内部的分享后，很多读者都希望我能公开讲一次。无奈知乎 live 的小编一根筋，非要让我证明我是这个领域的牛人，否则不予通过。我觉得我肯定不算牛人 —— 从我真正开始看 blockchain 相关的技术到现在，都不到三个月，和那些动辄三五年前就入行的，从经历上是没法比的。然而以我这段时间在中文社区的观察来看，真正扎在 blockchain 技术领域深耕，且愿意分享的屈指可数。这并不奇怪：1) blockchain 领域的浮躁让江湖地位以金钱，或者说，捞钱的能力来衡量，真正扎在技术里的人的声音被淹没；2) 好的技术专家未必是一个好的分享者 —— 就像写代码能力比我强的人海了去了，但像我这样写了四年技术公众号还有的写的，太少太少。所以即便我不是牛人，我觉得我所讲的内容也能对大多数人有所启发。
可惜事与愿违，我不得不证明我是牛人，而最终我没法证明我是知乎小编眼中的牛人 —— 我把我的 github 上有关 blockchain 的 code 和 talk 的 repo 提交上去，也不晓得对方是否懂得如何用 github，反正我更新两次，被拒绝两次 —— 我一气之下删了 live，这样的猫鼠游戏我没工夫玩。线上做不了，那干脆线下，于是在朋友的推荐下，和云享客牵上了线，线下分享。
且容我再引用一下我引用过无数次的箴言：The brick walls are not there to keep us out; the brick walls are there to give us a chance to show how badly we want something.
在知乎碰壁，我的傲娇被激发出来 —— 一个小时的分享我不够资格，那么，我干脆做一下午的分享如何？我跟云享客的 Helen 敲定了细节：不要嘉宾，就我自己干讲。时间从 1:00 到 5:00，讲四个小时，中间休息两次 —— 四个小时的单口相声，这是我从未尝试过的事情。
虽然我肚子里有那么一点点货，但做过讲座的人都了解，自己理解和讲出来让别人理解，难度不是一个数量级，台上一倍的时间，台下保底翻番。Data Center 迁移完成，新系统稳定下来后，我便开始写 slides，火车上写，睡前写，飞机上写，还几乎把出差期间的业余时间（除了和人吃饭）都搭进去。周五晚上在极客时间做完小分享回到酒店后，老婆问我明天的分享准备得如何？我苦笑到：才准备好三分之一的内容。于是周五又干到半夜。周六早五点半起来，看着剩下的内容，我估计五个小时能完成，写了一个小时后，酒店网络 + V** 实在是个瓶颈，我便在早餐后大概7点多去公司继续忙活，这一写又是五小时，中午12点10分，我才赶完 120 页的 slides，然后在朋友的车上，简单把稿子过了一遍。
最终，我的分享在周六下午 1:15 开始。由于准备得还算充分，我最担心的事情没有发生：我的内容不足以撑起四个小时的讲座。最终，我讲了近五小时，还因为时间不够，跳过了原计划讲半小时的内容。
slides 可以在我的 github repo tyrchen/unchained 下载。我还会继续更新这个 slides，使其装载更多的内容，真正达到我心目中理想的：一份 slides 在手，入门 blockchain 无忧。
讲座的视频，随后会先发给参与讲座的同学，之后看情况公布出来。
在这次讲座的 slides 的末尾，我放了 Roger Banister 的故事来佐证 believe is self-fulfilling prophecy（是的，我偷师于 Tal Ben Shahar 的 Positive psychology 课程）。这也是在这次讲座的整个过程中，我体会最深的地方。很多事情，别人怎么看并不重要，重要的是自己怎么看。信心从来都不是来自外界，而是自己笃定自己能成，就像庄子在逍遥游里说的那样：「举世而誉之而不加劝，举世而非之而不加沮」。只有这样，才能够守着目标，勇往直前，逢山开路遇水搭桥。
当然，最重要的还是，当一件事情做成，「举世誉之」之时，不要沉湎其中，静静走开，追逐下一个目标。就像费德勒那样，第十九个大满贯奖杯到手，觥筹交错之后，就成了他孩子们的玩具。