在 LeanCloud 被心动收购快三年的时候，我离开了心动和 TapTap。

一段时间前我看到 Will Larson 写的 Deciding to leave your job，其中讲到决定是否离开时应该问自己的四个问题：

• Has your rate of learning significantly decreased?
• Are you consistently de-energized by your work?
• Can you authentically close candidates to join your team?
• Would it be more damaging to leave in six months than today?

这几个问题可以说贴切地描述了我当时的状态。我对于公司的管理风格和文化有比较强的看法，过去创业最重要的原因也是要实现自己的这些想法。所以如果在这些方面对所在的公司失去认同，就很难专注地把工作做好，很容易把注意力转移到个人自身的提高上。这或许可以算是我的缺点。所以应该说离开的决定在内心早就做了，只是一直没考虑确定具体时间，也一直没好意思提出。在国庆前正好我创业时的合伙人俊文也说准备离开，所以国庆后我就一起提出了。毕竟他离开就意味着很多工作要交接，组织结构也要调整，以其过几个月再调整第二次，不如一次到位。过去三年内外部环境都变了很多，我所负责的业务对现在的 TapTap 来说确实价值很有限，我们离开也好给公司需要做的一些改变让路。

之后我很快加入了 EMQ。这是一家做跨境支付的公司，国内还有一家做 IoT 的同名公司，所以很容易混淆。我在 10 多年前还在负责 AVOS 中国的时候就通过 Steve Chen 介绍认识了 EMQ 的创始人 Max，当时他还没创业。EMQ 和 LeanCloud 是同一年开始的，后来 Max 多次邀请过我加入，虽然时机都不太合适，但我一直关注着这家公司的发展。这次时机对双方来说都很合适，所以我就决定加入了。过去很多人都说我离钱比较远，那么这对我是个离钱近一些学习 financial services 的机会。

EMQ 是一家比较西式的创业公司，有 80 多人，开发团队有十多人，在台湾、香港、新加坡、印度、欧洲和东南亚都有同事。让我比较意外的是产品和运营团队的不少同事也都有很不错的技术背景。我们的技术栈包括 Erlang、Python、TypeScript、Clojure、Postgres 和 AWS，目前前后端都有职位在招聘，如果你有兴趣可以把简历发到 engineering-hiring@emq.com 和我们联系。春节之后在上海应该会有办公室，此外我们也会考虑很优秀的远程候选人。

「如何反转一个链表？」是一个在面试中被问滥的问题。我参与的面试中偶尔也有我们自己的面试官问。 如果你去别的公司面试被问到这个问题，要是给出的答案是（以 Python 为例）：

def reverse(l):
 l.reverse()
 return l

或者是：

def reverse(l):
 return l[::-1]

肯定会被拒掉。面试官所预期的是你自己定义节点，再定义链表：

class Node:
 def __init__(self, data):
 self.data = data
 self.next = None

class LinkedList:
 def __init__(self):
 self.head = None
 # 以下略，问 ChatGPT 就可以了。

不过既然是个被问滥的问题，如果遇到不妨尽量给出一个面试官没见过的答案。 比如，构造链表：

def cons(h, t):
 return lambda f: f(h, t)

取头：

def car(l):
 return l(lambda h, _: h)

取尾：

def cdr(l):
 return l(lambda _, t: t)

反转：

def reverse(l):
 rev = lambda l, r: rev(cdr(l), cons(car(l), r)) if l else r
 return rev(l, None)

以上就是完整答案。为了展示方便写个打印链表的函数：

def printl(l):
 toStr = lambda l: str(car(l)) + ' ' + toStr(cdr(l)) if l else ''
 print('(', toStr(l),')')

写个例子试一下：

l = cons(1, cons(2, cons(3, cons(4, None))))
printl(l)
printl(reverse(l))

输出是：

( 1 2 3 4 )
( 4 3 2 1 )

这应该是自己构造链表的最短答案了，但是有一定风险被面试官以奇怪的理由据掉。如果你是面试官，又想问这道题，就得了解各种实现方式，避免把不该拒的人拒了。🙃

这是我一年前发在 TapTap 内部 Confluence 的一篇文章，经过一些修改后公开出来，希望对更多人有价值。

Google 的很多软件工程实践都在对外发布的各种 Tech Talk、CppCon 的演讲以及多本已出版的书里提到过（比如 Software Engineering at Google、Site Reliability Engineering 等），所以这篇文章的内容并不算新鲜事，只是贡献一些个人视角。另外我在 Google 工作已经是 10 多年前的事，现在可能已经变化很大，但我认为 2000~2010 年的时候是 Google 最有创造力、最高效、对人才的吸引力也最强的时候。

一点背景

有时言必谈前公司的人会有点让人讨厌，不过无论是之前创业，还是现在，讨论起工程方面的事情都很难避免提起 Google 是怎么做。Google 和所有公司一样，并不是所有方面都做得很好，比如产品能力以及饱受诟病的客户服务。但就是因为在 engineering 方面领先大部分公司很多，所以削弱了其他方面的弱点带来的影响。Google 取得成功的大部分产品基本都是在技术实现上大幅领先同时代的产品，从而实现用户体验上的领先，早期产品中最有代表性的是 Search、Maps 和 GMail。Google 的 engineering culture 也对包括 Facebook 等在内的大量硅谷公司以及国内包括字节这样的公司产生了深远影响。

我在 Google 的三年是在一个叫 Google Web Server（简称 GWS）的团队。这个项目可以说是 Google 历史最悠久的项目，从 Google 存在开始就有 GWS，到现在 20 多年，Google 的 HTTP header 里 server 还是 GWS，应该还是同一个项目、同一个 code base 和 binary。

一开始的时候 Google Search 就是 GWS。后来从它里面拆出了一部分放到前面承担类似 SLB 的角色，叫 GFE（Google FrontendEnd）；又把实现单纯搜索的部分拆了出来叫做 Superroot。GWS 更多地成为了一个实现搜索相关的整体业务逻辑的服务，它后面有 15~20 个后端服务，除了 Superroot 外，还有广告、拼写检查、搜索词修正、query rewrite、用户偏好等等。经过多年的演变，GWS 的开发语言也从 Python 变成了 C，再变成 C++，后来又为了方便快速做试验内嵌了 Python 解释器。在整个过程中，GWS 从来没被真正意义上重写过，因为 Google 一直都有大量的业务需求等着实现，不可能有停下来重写或者重构的机会。所有大的改变都必须以渐进的方式来实现，包括换语言。尽管只有 Google 一家公司在用，但是 2010 年的时候 GWS 就支撑了全球 13% 的活跃网站，是排在 Apache、Nginx、IIS 之后的第四大 web server，因为 Google host 的网站很多都是 GWS 来 serve 的，包括自定义域名的 custom search 以及 enterprise search。

几乎所有在搜索结果页用户可见的改动都会需要改 GWS 的代码。这就涉及到了很多其他项目和团队，除了和搜索有紧密关系的广告外，还有地图、新闻、财经，甚至小到汇率转换、计算器。Google 的搜索框不仅是狭义的搜索，其实功能是很多的。这就导致项目非常复杂，改动也非常频繁。GWS 的二进制文件编译出来有 1G 多，在当年已经超过了 gcc 和 gdb 的上限，需要使用内部改过的版本。项目每周发布一个新版，平均有大几百个 changelist。Changelist 是 Perforce 的名词，相当于是 GitHub 的 pull request 或者 GitLab 的 merge request，是一次 code review 的单位，大小通常是多个 commit。

这样一个项目听起来似乎需要一个庞大的团队来维护，而且很容易成为瓶颈。我 2007 年加入的时候，团队有不到 20 人。2010 年我离开的时候有 40 人左右（负责的范围也变大了），分布在 Mountain View、芝加哥、匹兹堡、纽约。除了 GWS 外，这个团队还维护着一些服务端的基础组件，比如我们开发维护的一个项目是 Google 大部分 C++ 服务的基础，提供了标准的健康检查、feature flag、监控变量管理、实验框架等功能。团队成员还有时间发起一些 20% project，比如我和另外两位同事合作开发了一个 serve Google 所有静态文件的新服务，把这部分职责从 GWS 分离出来。听起来这么多的事情由那么小的团队来做是不可能的。秘诀在于 GWS 每周大几百个 changelist 中大部分并不是这个团队里的人写的代码。

GWS team 不负责实现其他产品在搜索里的需求，但是会花大量时间 review 其他产品的工程师提交到 GWS 的改动。由于每周的改动量巨大，很多人会花一半以上的工作时间在 code review 上。GWS team 自己也做开发，但是责任是不同的，日常开发大概有几类

• 为了提高 GWS 的性能和稳定性，或者为了团队本身的开发效率做的重构和改进
• 为了让其他团队能更容易地修改 GWS 而开发的模块化功能，比如 OneBox、ManyBox、Universal Search
• 为搜索和广告的整体业务需求增加的功能，比如试验框架
• 上一段所说的输出给其他项目的基础组件以及从 GWS 衍生出的新项目

因为这是我的第一份全职工作，其实在 Google 期间并没有觉得有多好，以为大公司都是这样的。但是离开之后才觉得，能有这段各团队之间能顺滑地高效协作的工作经历是很幸运的。这样的工作模式在大部分其他公司很难完全复制，因为它需要一些很强的基础设施做支持。以我们目前的工作模式，很难想象能达到同样的吞吐量，可能也很难复制同样的模式。但是分析一下别人做得好的地方还是能给我们提供一些方向上的参考，做一些努力能提高的空间还是很大的。下面我就介绍一下支撑 Google 团队间高效协作最重要的几个方面。

代码管理和安全

Google 的每个工程师都可以访问全公司 99.9% 的代码，这是决定 Google 的工作方式最根本的条件。剩下只有少数人能访问的那部分叫 HIP (High-value Intellectual Property)，主要是防 SPAM 的逻辑。这部分代码如果泄露了，很快就会被恶意网站利用使得搜索质量显著下降，并且没有可以迅速补救的办法。其他所有项目的所有代码都是对所有工程师开放的。

Google 全公司共用一个代码库，叫做 google3，用 Perforce 做版本管理，但是自己在 Perforce 的命令行客户端 p4 之外包了一个工具叫 g4（为了描述方便，以下 Git 和 Perforce 里 submit、merge 等名词区别就不纠结了，从上下文意思应该清楚）。每次一个工程师在自己本地创建一个 workspace 的时候，g4 会用 OverlayFS 从 NFS 上把最新版本的整个 google3 映射到本地。从工程师的视角，整个 Google 的代码树就是自己电脑上一个只读的大目录。当他 checkout 某个路径进行编辑的时候，g4 会把对应的子目录实际复制到本地，这样在他的视角那个目录就变成可读写的了。所以任何一个工程师都可以编译、测试、修改公司的任何一个项目。

很多人都会问，这样代码不会泄露吗？在那么大的公司可以肯定一定是会泄露的。2010 年前后有很多 Google 中国的人去百度，人民搜索（云壤）、盘古搜索也都是 Google 的人出来做的，要说没有知识产权外泄谁都不信。但是对公司而言，让自己跑得更快远比让竞争对手跑得慢一点更重要。所以大部分情况下保密措施应该是以不伤害效率为前提的。对用户数据的保密除外，但是保护用户数据的措施通常不会影响到大部分人的工作效率。

当时内部邮件列表每个人都可以建，项目管理工具的项目每个人都可以建，工程师可以看任何一个数据中心的任何机器上任何服务的日志，甚至可以动态修改它的 feature flag。理论上这些都可以被滥用或者误用，但是滥用往往缺乏动机，误用可以从设计上避免。一个大原则是风险可控或可逆的事情默认是没有流程的，只有实际发生了问题，证明必要时才会靠引入流程来解决。有了流程就需要有人审批有人执行，如果它解决的问题不常发生、有其他方案或者产生的危害不如流程带来的成本，那么设立流程就是不理性的。

共用一个开放的 repo 目的是让每个工程师都能访问、修改、运行公司的任何项目。要做到这一点，还需要每个项目都使用同样的基本工具。

构建工具

Google 使用的构建工具叫 Blaze，支持 Google 当时允许使用的四种语言：C++、Java、Python、JavaScript（Closure）。后来 Blaze 开源了，改名叫 Bazel，由社区增加了对更多语言的支持。

无论哪个项目，编译的方式都是在 google3 目录运行 blaze build [path]，而 blaze test [path] 是运行项目里的所有测试。一个工程师如果需要对某个他不熟悉的项目做一些小的修改，需要的知识是很少的，只要做完改动后确保新的代码有测试覆盖，所有老的测试能通过，就可以提交到 code review 的系统了。

每个项目会有一个 Wiki 页面介绍怎么在本地运行和调试，通常来说是描述需要传递什么命令行参数来连接本服务依赖的线上或测试环境的其他服务。对于需要实际运行、进行人工验证的复杂改动，看了 Wiki 以后就能自己在本地跑一个实例，这类改动在 code review 时也通常会要求提供一个本地 demo 的地址。所以任何一个工程师都可以把 Google 的任何一个服务从源代码编译并运行起来。

自动化测试

GWS 作为一个 C++ 的项目，测试覆盖率保持在 90% 以上，这是非常不容易的。用静态语言的项目测试难度比动态语言大很多，因为对象的属性和方法无法动态替换，想要能在测试中 mock 掉 side effects 需要在设计上做更多的努力。自动化测试的好处相关的书上有很多，就不赘述了。我只说两点：第一，对自动化测试的要求确实可以产生更好的设计，比如鼓励面向接口的设计；第二，对于 Google 那样的协作模式来说，自动化测试不是一件锦上添花的事，而是必须。因为无论是去修改其他项目的信心，还是让其他人来修改自己的项目的信心，都来自于很高的测试覆盖率。

确保自己项目的稳定性和质量的方式不是不让别人改，而是把自己关心的东西加到测试里去。比如当时我们有一个用来表示用户请求的类叫 GWSRequest，一个 GWSRequest 对象的生命周期就是整个请求处理的过程，所以这个类自然就成了存这个过程中产生和消费的各种信息的地方。时间一久它的属性就越来越多，还出现了多个属性重复存了同样的信息的情况。后来我们加了一个测试 STATIC_ASSERT_LE(sizeof(GWSRequest), MAX_GWSREQUEST)，试图往 GWSRequest 加新属性的改动在编译时就会失败。如果有人想改 MAX_GWSREQUEST 的值，就需要说明为什么是必须的。有的比较卷的团队为了控制代码的复杂度，还把自己 code base 的行数上限放到了测试里。如果有人增加了 10 行代码，就需要重构其他地方的代码来省出 10 行，或者提供一个好的理由来提高上限。

Code Review

Code review 是每个 Google 的工程师日常工作中很核心的部分。每一个改动都需要经过除作者外至少另一个人的 review 才会 merge。无论是对发明 Python 的 Guido van Rossum 还是发明 C 的 Ken Thompson， 都是如此。google3 代码树中每个项目的目录有一个 OWNERS 文件，里面是一些工程师的 ID。当有人提交一个 changelist 后，系统会自动把这个 changelist 分配给涉及到的每个目录的一个 owner 来 review，每个 owner review 通过，并且涉及到的各目录的测试都成功之后才能 merge。Guido van Rossum 加入 Google 后前几年的成果就是开发了内部的 code review 工具 Mondrian，可见这件事对 Google 的重要程度。

做 Review 的人主要关心几件事：

• 改动的业务逻辑是否正确，具体实现在性能和可读性方面是否合理；
• 是否符合 Google 的代码规范以及本项目附加的一些条件；
• 新的代码是否有足够的自动化测试覆盖；
• 用户可见的改动是否被产品经理批准（会要求提供 Buganizer 的链接，Buganizer 是 Google 自己开发的类似 Jira 的系统）。

除了日常的 code review 外，每个新员工会需要学习公司的代码规范，并通过工作中会用到的每个语言的可读性 review。方式是准备一个百行以上的 changelist，提交给一个有资格做 readability review 的工程师，通过之后才有权限提交用在生产环境的代码。有权做这类 review 的是在一个叫 readability committee 里的资深工程师，他们也负责制定公司的代码规范。比如当时给我做 C++ readability review 的是Generic Programming and the STL 的作者 Matt Austern。我刚入职时同组的同事告诉我 Guido van Rossum 到 Google 后第一次 Python readability review 没有通过，不知真假。

Code review 除了让项目的 owner 保证代码质量，让其他项目可以快速推进需要的改动外，还起到传播知识的作用。很多时候一些在公司多年的工程师的 reviewer 是入职不久的新人，做 review 的人往往也能从别人的代码里学到很多东西。

版本管理和发布流程

Google 在内部做版本管理的方式就是不做版本管理，所有项目都 live at head。当然，每个项目都有对公司外的版本发布流程，live at head 是对内依赖的策略。一般不会出现一个项目依赖一个组件的 1.1，而另一个项目依赖这个组件的 1.2 这样的情况。每个项目在每次编译的时候，都会把所有依赖从最新的代码编译，使用到的依赖的版本是由编译的时间点决定的。这自然就意味着每一次提交后的代码状态都应该作为稳定版本对待。

一般外部的开源项目，会分不同的版本号，由用户决定什么时候升级，并且由用户做升级所需要的改动。按照 2015 年的数据，Google 有 20 亿行代码，其中的依赖关系错综复杂。而 C++ 对于一个项目用到的两个组件依赖同一个组件的不同版本的场景（菱形依赖）支持是很脆弱的。所以不太可能使用 SemVer 之类的版本方案，除了纯技术上的问题外，每个组件要为内部用户维护多个版本也是成本巨大的。所以 Google 把版本管理完全倒了过来，每个项目/组件都只要维护一个最新版，所有的改动最重要的原则是不能破坏任何测试。所以如果有人在一个共享组件里做了向前不兼容的改动，就会需要在同一个 changelist 里把整个代码库里所有调用到这个接口的地方改过来。有的改动会动到十多个项目，需要十几个 owner 来 review，这并不少见。当然 Google 有强大的代码搜索工具来辅助这样的事。据几年后 Google 工程师在 CppCon 上的分享，他们还用 MapReduce 做了大规模重构工具，不过是在我离开之后了。

没有内部版本管理就意味着要保证每个版本的稳定。Code review 的工具会保证每次 merge 前都运行了所有涉及的测试，但是有时还是会发生代码 merge 之后导致测试失败的情况。比如可能有 race condition，也就是两个人几乎同时 merge 了会相互影响的代码；也可能失败的测试和改动的文件不在一个目录，导致 merge 前没有运行。GWS team 有个工程师轮值的角色叫警长（sheriff），一旦 GWS 的任何测试变红，本周的警长就会找出来是谁干的，并把对应的改动撤销。后来有人做了工具把这个流程半自动化了，一旦有测试失败，就会自动生成一个 changelist 把对应改动撤销并发 code review 给警长，他只要确认、跑测试、点 merge 就行。再后来有的团队把这个过程完全自动化了，不用人工干预。

GWS 每周会做一次 binary push，也就是二进制文件的发布。流程是每周一早上负责发布的工程师从当前的代码做一个发布分支编译出一个二进制文件，交给 QA 开始测试，发现 bug 就把修复 cherry pick 到发布分支。由于大部分逻辑错误都会在开发过程中的自动化测试发现，QA 阶段发现的大部分是通过截图比对工具找到的某条线移了一个像素之类的问题。QA 流程通过后，就从单数据中心单台机器开始灰度，逐步发布到全球。如果到周四下班还没完成发布，本周的发布就会被放弃，下周再重复同样的流程。发生发布失败的情况很少，如果发生会作为事故来开会复盘。

除了 binary push 外，还有 data push，也就是数据发布。数据包括 GWS 的配置文件、各种黑名单白名单、模版文件等。Data push 比较轻量，每天有多次，都是采用灰度发布到全球的方式。

以上这样 live at head 的方式意味着不太可能有长期存在的功能分支。如果一个工程师在独立功能分支上开发了几周，那基本上是不太可能合并回主线的。无论是多大的新功能，都会需要拆成很多小的 changelist，高频地提交到主线。只是未完成的功能会用一个 flag 屏蔽掉，在生产环境不会运行。所有用户可感知的改动都是用与试验一致的方式发布，从单个数据中心千分之一的流量开始灰度到全量。如果发现问题，只要做 data push 把 flag 的值改回来就行，因为老的 code path 已经在线上运行了很久，所以改回来一定没问题。这让发布很安全，大家也有信心做大胆的尝试。

关于项目管理和排期

排期这个词在 Google 其实很少出现，离开 Google 之后都在小创业公司就更不会出现。如果大部分事情都需要项管排期，一件很小的事情也可能被排到一两个月后，而这件小事可能 block 了很多其他工作。把一个工程师的时间按开发任务线性地排列，完全做完一件事再开始做另一件事，也并不是高效的方式。工程师确实是需要专注的、避免多任务切换的时间，但这样的时间应该是以小时计，而不是以天或周计的。一个工程师应该把任务分割成尽可能小的单元，写完代码和测试后及时提交给别人 review，并且也需要 review 其他人的 merge request。从天和周的维度看，本来就是需要在多件事情之间切换的。

在 Google 的三年多里，我们团队的 project manager 对于工程师来说存在感一直比较低，项管不会过多干预个人的工作计划。每个工程师都相当于自己的项管，工程师之间会互相就优先级进行沟通达成共识和妥协。这样的好处是工作量小但 block 了其他人的事情会被快速完成；实际做事情的人用专业的语言沟通，不需第三者传话，也不容易造成误解；一些重要但不紧急的事情，比如重构、还技术债，也可以由工程师在日常工作中穿插地推进。我无法想象在 Google 当时的团队能按集中排期来安排工作。过去十多年里，硅谷比较成功的互联网公司都是用与 Google 相似的方式来工作的，这不是偶然现象。网状的沟通协作与传统的树状比，表面可能感觉混乱，但是因为不容易形成瓶颈、沟通中信息损耗少，效率是很高的。

我们能先从哪些事做起

Google 的人喜欢说 Google 的工程实践是为连续运行十年以上的软件设计的。10 年不是很长时间，已经基本站稳脚跟的公司需要探索在开发协作上更 scalable 的方式。我们不太可能去复制 Google 的所有东西，Google 的方式也未必放在所有公司都是适用的，但是有一些方向性的结论在整个业界是得到了共识的，我们也应该朝那个方向去努力。以下是我们可以在公司推动改进的一些方向。

在工程师团队里培养测试文化

在这个年代写完代码就交给 QA 去测试，靠人工来保证质量，是很落后的方式，因为它不能 scale。人工的测试做十次就是十倍的成本，哪怕每次内容都一样。自动化测试是所有人都知道好，很少人实际做，更少人能做好的事。Google 也不是从一开始就把测试做得很好，而是由一小群人努力地在全公司推动起来。最可见的一件事是 Testing on the Toilet，内部简称 TotT。他们在全球办公室的几百个马桶前都装上了这样的海报，这样大家在上厕所的同时还能学习如何写测试。久而久之，重视的人越来越多，开始在 code review 中执行测试覆盖率的要求，大部分的项目都逐步建立起高质量的测试。

让自己的项目更容易被别人改动

要改代码首先要看得到。我一直认为代码应该默认是对内公开的，虽然可能会增加泄露风险，但和效率的提高比是微不足道的。如果市值几千亿美元的公司都能对每个工程师开放代码，对大部分公司而言部门之间还互相捂得很严就太小气了。Git 本身不是为 Monorepo 设计的（虽然最近有一些支持，以及微软有全球最大的 Git repo），可能短期我们也难以大范围转为 monorepo，但是 GitLab 把 repo 组织成树状的设计一定程度上是为了在权限管理上模拟 monorepo 按目录管理的方式，是很容易做到默认 owner 可读写，其他人可读，让任何人都可以通过 merge request 改任何代码的。

让别人更容易改动还包括提供内部文档，让别人知道如何修改、运行、调试（别人包括团队新人、其他团队、未来的自己）；提高可读性和模块化，让别人容易理解；提高测试覆盖率，让别人不容易改坏。

尽量提交代码而不是需求

现在经常会遇到有一件事需要涉及多个项目的改动，把需求提到其他项目，发现要排到很久以后了。解决优先级上的冲突，让对自己重要的任务早点完成的最好办法就是把一件事的开发收缩到同一个团队，不管要改的代码在哪里，都尽可能由同一个团队完成开发，由 owner review。从经济上来说，由需求方投入资源也是更合理的方式。这样的工作方式偏爱能力全面的团队和工程师，在 Google 一个人经常性地提交 2~3 种语言的代码是很常见的。

当然，也不是所有的事情都能收敛到同一个团队进行。有的任务是需要对多个项目进行根本性的改动的，就会需要来自多个团队的工程师形成一个临时的小团队了。

建立代码规范

很多公司通常是从很小的时候就会建立公司范围的代码规范，因为有了一致的规范，才好使用同样的工具，阅读和修改其他团队的代码时才能比较容易。如果在规模较大时再从零开始做这件事会非常困难。可行的路径可能是自下而上的，各个团队先建立自己的规范，协作得多的团队可以取长补短，从能建立共识的部分形成共同的规范，逐步扩大适用的范围。

其实这是知乎上的回答。公司并购之后由于团队变大了很多，特别忙，所以博客和播客都断更了好久。

其实我们官网的公告已经把主要的前因后果介绍得比较清楚了，没有太多其它的新内容可说。

其它答案里说的大公司同类竞争之类倒不是主要原因。从我们创业开始，阿里、腾讯就陆续有过多次形态类似的产品尝试，后来字节也有相似的产品，但是都并没有很成功。选择不用 LeanCloud 的用户大部分是会用云主机等形态更底层的云服务的。所以本质上我们主要是和更传统的云服务竞争，而不是和形态相似的产品竞争。

LeanCloud 创业的几年中，各方面都有不少改进的空间，但是在资源有限的条件下，我觉得在国内环境能做的范围内，产品、团队和文化都还是有一些做得不错的地方，各方面被同行借鉴得也不少。但是我们在财务上并不成功，至少没有达到 venture-backed 的创业公司的增长期望。一方面团队创始人都是技术出身，公司一直都没有过在市场、BD、销售方面有资深经验的人才，虽然有一两次碰到比较合适的人，但都因为各种原因没有实现；另一方面也有行业发展的客观原因，做一些横向对比就能发现。Starbucks 前 CEO Howard Schultz 说过，公司文化等等很重要，但是一家公司在财务上能 deliver 是一切的基础，不然其他东西都是不可持续的。

LeanCloud 并不是第一次收到并购邀约。过去曾有 A 股上市公司，加密货币和区块链最火爆的时候也有这个领域的公司，不过都没推进到谈价格的阶段。因为两个前提要有保证：第一是产品的未来发展和对现有用户服务的连续性；第二是文化和管理上我们创始人自己和团队得愿意加入对方。

知道和使用 LeanCloud 的游戏公司数量很少，但是如我们的公告上说，这部分公司贡献了将近一半的收入。其实我们一直以来都很想拓展这个领域的客户，但是一直都没找到好办法。与 TapTap 的结合对 LeanCloud 来说是一个让我们的产品真正进入游戏行业的很好的机会。对所有现有用户来说，也意味着我们未来有充足的资源继续改进产品。

心动从做「天天打波利」开始就用 LeanCloud 的服务，一开始我和前 CTO 沈晟沟通得比较多，从去年开始聊并购后和两位创始人及其他高管都有交流。他们所期望的公司管理方式和文化和我们自己还是很一致的。创业的人大多有两方面的目标：一方面当然是财务上的；另一方面是创造一家符合自己自己理想的公司。只是很多人做着做着就忘了第二点了。我觉得心动/TapTap 是一家很难得的公司：两位创始人在坚持朝着自己的理想迈进，而同时财务上又能 deliver。其实因为财务上的空间比较大，心动和 TapTap 在管理和文化上在做一些比 LeanCloud 更加大胆的尝试，只是因为公司一直比较低调，所以在互联网圈子里大部分求职者对这家公司还缺乏了解。

LeanCloud 团队目前已经和原 TDS（TapTap Developer Services）团队合并，LeanCloud 的各项服务也已经引入 TDS，详情可以看我们两天前办的 TapTap 开发者沙龙的报道。现在 TDS 正在积极扩充团队，欢迎优秀人才加入，详情请见我们的招聘网站。

这一期我们从 IPFS 项目及 Brave 浏览器的一些新尝试展开聊了 Web 的开放性相关的话题。

特别感谢 Kai Luo 为我们制作了片头片尾音乐。

如何收听

• 播客主页 有国外各大平台的链接
• 直接订阅 RSS
• 其它平台待更新

本期主播

• Livid
• 王子亭
• 江宏

相关链接：

• IPFS
• IPNS
• ZeroNet
• Brave 浏览器

在 small talk 的第二期我们聊了一下搭载苹果 M1 芯片的 Mac。我们回顾了各自使用 M1 Mac 的感受和遇到的问题，后半部分讨论未来可能的行业影响以及购买方面的建议。

欢迎留言给我们提出反馈以及以后希望听到的话题：

• 语音留言（你的留言可能会出现在以后的节目里）
• 文字留言：请在本帖下面发评论

如何收听

• 播客主页 有各大 Podcast 平台的链接
• 喜马拉雅
• 直接订阅 RSS

本期主播

• Livid
• 王子亭
• 江宏

讨论中提到的相关链接

• 苹果正式发布 M1 芯片
• 在 M1 芯片 Mac 上使用 Homebrew
• Docker desktop for M1 Mac tech preview
• Why is Apple’s M1 chip so fast?
• 在 M1 Mac 上跑 3DMark
• 在 M1 Mac 上用 Rosetta 2 + CrossOver 玩 Resident Evil 3
• M1 对 Resetta 2 的特殊支持
• Mac 2002-2018 出货量
• Nintendo Switch 出货量
• OpenEmu：Mac 上的游戏机模拟器
• Microsoft reportedly designing its own ARM-based chips for servers and Surface PCs
• Graviton: AWS 自研的 ARM 芯片
• Ampere Computing：研制云计算 ARM 芯片的公司

最近难过地得知 Stan Eisenstat 教授在 12 月 17 日去世，我在 2017 年回学校时还去找他聊了会儿天。这也让我想起几年前去世的 Paul Hudak。这两位教授虽然不是我正式的导师，但都对我影响很大，所以就想写一写我对他们的记忆。

我在去耶鲁上学之前就在 Joel Spolsky 的 Joel on Software 里读到过 Stan Eisenstat。他教的 CS323: Systems Programming and Computer Organization 在学生中是一门传奇性的课程。选课的人往往在那个学期会需要花大量时间熬夜甚至通宵来完成他布置的几个大作业，而在课程完成后都会觉得收获很多。进入耶鲁后我抓住机会申请做了这门课的助教。当年（1998 - 2002）我在国内接受的计算机科学本科教育说实话和美国好的大学比还有很大差距，直到后来国内大学有越来越多留学回来的人加入，这个差距才缩小，所以其实读博期间还要弥补一些知识面上的裂缝。给本科生课程做助教对于提升自己也是非常有益的。他在一个学期里会让学生完成几个大作业：实现一个 UNIX shell，一个 LZW 文件压缩/解压程序，重新实现 make 等等。每个项目 Stan 都会准备好一套测试，学生提交完后他跑一遍测试就能马上得出正确性的得分。他也准备了详尽的代码风格文档，所有的作业和考试都有正确性和风格两部分分数。到期末他会让助教自己设计一个期末项目给学生作为期末考，助教也要负责给这个项目写一套自动化测试来给学生提交的代码打分。所以每一届学生遇到的期末项目都不同，而每个助教也有自己的发挥空间，参与这个过程的每个人都很有收获。我现在还记得给学生出的题目是做一个支持用 telnet 登录的多线程 BBS 服务器，我写了一个 telnet 机器人来测试他们实现的各项功能。Stan 在耶鲁计算机科学系将近 50 年，这门课和他教的 CS223: Data Structures and Programming Techniques 一直都是计科系的核心编程课，无数学生在 Zoo（系里的机房）耗费了无数夜晚来完成这两门课的作业。

我对 Paul Hudak 也是在去耶鲁前就有很多了解。我本科的毕业设计是函数式语言的课题，所以找了一些 Haskell 的资料看。Paul 是 Haskell 的主要设计者，当时他正好出了一本新书。那时市面上还几乎没有正式出版的 Haskell 的书，国内更是完全没有。我给他发邮件问问题时提了一句很遗憾在中国买不到他的书。过了两周多就收到了他给我寄过来的书。后来进了耶鲁我选了另一位教授开的 functional programming 课，因为这方面基础薄弱学得比较差。后来 Paul 教这门课时我又去报名做助教，相当于自己也又学了一遍。虽然后来我没有选择在程序语言方面深入下去，但因为他的原因一直保持着对这个领域的兴趣和关注，所以当 Clojure 这样更具实用性的函数式语言出现时我很早接触并应用到实践中，后来创业时也选择它作为主要开发语言，使团队能在早期很高效地开发出产品。

耶鲁的计科系格外地重视教育。这句话听起来似乎有点奇怪，所有的大学都应该是重视教育的，但其实各个学校在研究和教学上的投入还是很不一样的。很多地方的教授更愿意把时间投入到研究上，多发几篇论文，而教学更多地是必须完成的义务和负担。耶鲁的很多教授，包括 Paul、 Stan、Stan 的妻子 Dana Angluin（也是同系教授）、我导师 Mike Fischer 都对教学有一种很纯粹的热爱，他们年复一年地打磨同一门课程，不吝惜花大量的时间做到尽善尽美，把培养出的学生看作最重要的遗产。我在 Yale Daily News 上看到，Stan 对学生的爱持续到了生命最后一刻，他要求等期末考结束再宣布他去世的消息，所以他离世后系里还不知道，第二天在 Zoom 上的虚拟节日聚会里大家还录制了一些祝他早日康复的消息。

我们一直都想做一个中文播客节目，但是因为最初提出想法的人都比较腼腆，一直没有启动。最近我来推动开始了这件事。

播客名称叫 small talk，除了闲聊的意思外，也有个编程语言叫 Smalltalk，算是有些双关。这个播客的目的不在于宣传产品或公司，只是聊一些有趣的技术话题。会长期参与的除了我自己外还有 V2EX 的 Livid 以及我在 LeanCloud 的同事王子亭。我们也会邀请其它嘉宾来临时参与，欢迎在评论里留言建议以后的话题。

第一期的话题是聊聊每个人家里的私有云。为了快速发布，片头片尾音乐等细节就省略了，以后再慢慢迭代。目前发布在以下平台：

• 有人说没有 RSS，所以我把 RSS 挪到了第一个
• Anchor（源）
• SoundCloud
• Spotify
• Apple Podcasts
• Pocket Casts
• Google Podcasts
• 喜马拉雅

或者可以直接播放：

其中提到的软件和网站有：

• 王子亭的 NAS 选项和配置
• 群晖
• NextCloud（一套开源的同步盘解决方案）
• UniFi Cloud Key
• NUC（英特尔的迷你电脑）
• Visual Studio Live Share
• Grafana 和 SmokePing（监控图表工具）
• 树莓派（最好不要跑存储服务）
• ZFS
• RAID5 的数据重建真的很糟糕么？
• restic（支持加密、快照，备份到对象存储的备份工具）
• B2 Cloud Storage（低成本对象存储）
• Resilio Sync（端到端的文件同步工具）
• frp（内网穿透代理）
• ZeroTier（一个支持 P2P 模式的虚拟组网服务）
• Tailscale（一个好用的虚拟组网服务，基于 WireGuard）
• Nebula（Slack 的虚拟组网工具）
• Cryptomator（给网盘加上端对端加密）
• Announcing Amazon EC2 Mac instances for macOS
• 关于用 OS X 做 V2EX 的网站服务器

很长时间之前我在公司内挖了个坑说要做个 Emacs 和 org-mode 的内部分享¹。后来一直因为拖延症没有做。上周我和其他同事讨论准备做播客的事，就又想起这件事，周末花了点时间录成一个视频放在 YouTube：

这也是我做的第一个视频教程，看完别忘了点击订阅 😁。很快我们也会发布第一期播客，请关注。

几年前一位 LeanCloud 的用户做了一个基于 LeanCloud 的评论系统叫 Valine。后来在中文独立博客，特别是用 Hexo、Jekyll 这样的静态博客框架的用户中很流行。但是最近一两年因为监管变严，无法自己备案域名的国内用户不得不迁移到国际节点。另外免费的开发版服务本意是用于开发测试，而不是需要持续运行的正式项目，所以用户们想了一些比较 hack 的办法来绕过开发版限制。大多数人都会直接 copy 网上搜到的教程，不做任何修改，这样也给 LeanCloud 带来了一些奇怪的问题。比如我们花了不少时间来分析为什么每天总是在同一时刻有大量用户的应用会开始运行定时任务。

我用业余时间断断续续做了一个叫 Remark Ninja 的评论系统，目前到了可以开放给其他人用的状态。我自己的博客、LeanCloud 的博客，以及一些自己发现 Remark Ninja 的第三方网站已经用了一段时间。由于我自己在前端基本只用 React，所以目前只提供了 React 组件。Gatsby 是一个基于 React 的功能强大灵活的静态网站框架，我个人很推荐。非 React 的网站可以在局部用 React，或者直接用 RESTful API。

除了博客以外，以 thread 方式组织评论的网站都可以使用这个服务。目前提供了以下功能：

• 基本的评论和管理功能
• 给站长的新评论提醒
• 给原评论者的新回复提醒
• Markdown 支持
• 没有用 Google Analytics 之类收集用户数据的服务

计划中的功能：

• 垃圾评论过滤

由于前端水平有限，React 组件做得比较简陋，欢迎提 pull request。

前段时间 Trump 的这个采访成为社交媒体焦点的时候，我正好在复习一些 neural network 的材料，于是想到可以用一些新的开源工具做一个识别 woman、man、cemara、TV 的完整应用试试。这个例子足够小，可以在很短时间完成，很适合用来说明如何做一个完整的深度学习应用。完成的应用部署在 https://trump-sim.jishuq.com （LeanCloud的一个云引擎实例上）。

做这个应用分为三步：先用一些图片完成模型的训练，然后把模型导出，做一个后端的 API 用来识别图片，再做一个前端用来上传图片和显示结果。

准备训练数据

Jupyter notebook 是个很流行的用来做数据分析和机器学习的交互式环境，它可以把 Markdown 文档和 Python 代码放在一个笔记本里，也可以以图表、图片等友好的方式显示代码的运行结果。这里也会用到 FastAI，它是一个基于 PyTorch，提供了很多网络和文件批量操作便捷接口的开源库。这篇文章就是在 Jupyter notebook 里写的，所以你可以直接 clone 这个 repo、安装依赖、启动 Jupyter notebook。

git clone https://github.com/hjiang/trump-sim-notebook
pip install -r requirements.txt
jupyter notebook

我们还会用到 Bing image search API 来获取做训练的图片，你需要自己注册并申请一个免费的 API KEY。当然，因为搜索到的图片是在很多第三方网站上的，所以你需要能无障碍地访问中国之外的网站。🤷‍♂️

把你的 Bing image search API key 放在项目目录下的 .env 里，以免在代码里泄露出去：

BING_SEARCH_API_KEY=XXXXXXXX....

然后在 Python 里读进来

import os
from dotenv import load_dotenv
load_dotenv()
key = os.getenv('BING_SEARCH_API_KEY')

写一个函数用来搜索图片：

from azure.cognitiveservices.search.imagesearch import ImageSearchClient
from msrest.authentication import CognitiveServicesCredentials
from fastcore.foundation import L

def search_images_bing(key, term, min_sz=128):
 client = ImageSearchClient('https://api.cognitive.microsoft.com', CognitiveServicesCredentials(key))
 return L(client.images.search(query=term, count=150, min_height=min_sz, min_width=min_sz).value)

实际验证一下, 搜一张 Artemis 的图片：

from torchvision.datasets.utils import download_url
from PIL import Image
import fastai2.vision.widgets

results = search_images_bing(key, 'Artemis')
urls = results.attrgot('content_url')
download_url(urls[0], '', 'artemis.jpg')
image = Image.open('artemis.jpg')
image.to_thumb(128, 128)

确认图片下载没问题后，我们把关心的四类图片下载到 /objects 下面的四个目录里。

from fastai2.vision.utils import download_images
from pathlib import Path

object_types = 'woman','man','camera', 'TV'
path = Path('objects')

if not path.exists():
 path.mkdir()
 for o in object_types:
 dest = (path/o)
 dest.mkdir(exist_ok=True)
 results = search_images_bing(key, o)
 download_images(dest, urls=results.attrgot('content_url'))

你可能会看到一些图片下载失败的信息，只要不是太多都可以忽略。网络上有的图片是损坏的，或者是 Python image library 不支持的格式，需要把它们删除。

from fastai2.vision.utils import get_image_files
from fastai2.vision.utils import verify_images

fns = get_image_files(path)
failed = verify_images(fns)
failed.map(Path.unlink);

预处理

在开始训练前，需要告诉 FastAI 如何标注图片，并加载到它的数据结构中。下面的代码完成以下几件事：

• 使用父目录名（parent_label）来标注每个图片。
• 保留 20% 的图片作为验证集（validation set），其它的作为训练集（training set）。训练集就是用来训练神经网络的数据，验证集用于衡量训练好的模型在遇到新数据时的准确度。这两个集合不能有重叠。
• 把图片缩小以提高效率

最后一行代码会显示验证集的前三个图片。

from fastai2.data.block import DataBlock, CategoryBlock
from fastai2.vision.data import ImageBlock
from fastai2.data.transforms import RandomSplitter, parent_label
from fastai2.vision.augment import Resize

objects = DataBlock(
 blocks=(ImageBlock, CategoryBlock),
 get_items=get_image_files,
 splitter=RandomSplitter(valid_pct=0.2, seed=42),
 get_y=parent_label,
 item_tfms=Resize(128))

dls = objects.dataloaders(path)
dls.valid.show_batch(max_n=3, nrows=1)

在做图像识别的时候往往还会对图片做一些随机的缩放、裁剪等变换，以便产生足够多的数据来提高训练效果。可以从下面代码的结果看到对同一个图片做不同变换的结果。

from fastai2.vision.augment import aug_transforms, RandomResizedCrop

objects = objects.new(
 item_tfms=RandomResizedCrop(224, min_scale=0.5),
 batch_tfms=aug_transforms())
dls = objects.dataloaders(path)
dls.train.show_batch(max_n=6, nrows=2, unique=True)

训练数据

接下来终于可以开始训练了。对于图像识别这样的应用场景来说，往往不会从零开始训练一个新的模型，因为有大量的特征是几乎所有应用都需要识别的，比如物体的边缘、阴影、不同颜色形成的模式等。通常的做法是以一个预先训练好的模型为基础（比如这里的 resnet18），用自己的新数据对最后几层进行训练（术语为 fine tune）。在一个多层的神经网络里，越靠前（靠近输入）的层负责识别的特征越具体，而越靠后的层识别的特征越抽象、越接近目的。下面的最后一行代码指训练 4 轮（epoch)。

如果你有 Nvidia 的显卡，在 Linux 下，并且安装了合适的驱动程序的话，下面的代码只需要几秒到十几秒，否则的话就要等待几分钟了。

from fastai2.vision.learner import cnn_learner
from torchvision.models.resnet import resnet18
from fastai2.metrics import error_rate
import fastai2.vision.all as fa_vision

learner = cnn_learner(dls, resnet18, metrics=error_rate)
learner.fine_tune(4)

最后输出的表格里是每一轮里训练集的 loss，验证集的 loss，以及错误率（error rate）。错误率是我们关心的指标，而 loss 是控制训练过程的指标（训练的目标就是让 loss 越来越接近于 0)。需要这两个不同的指标是因为 loss 要满足一些错误率不一定满足的条件，比如对所有参数可导，而错误率不是一个连续函数。loss 越低错误率也越低，但他们之间没有线性关系。这里错误率有差不多 10%，也就是准确率是 90% 左右。

接下来我们要看看验证集里到底有哪些图片识别错了，下面的代码会打印出 confusion matrix。在这个矩阵里，对角线的数字是正确识别的图片数，其它地方的是识别错误的图片数。

from fastai2.interpret import ClassificationInterpretation

interp = ClassificationInterpretation.from_learner(learner)
interp.plot_confusion_matrix()

从输出的矩阵可以看到一共有 11 个错误，其中男女性别错误有 4 个，此外电视和其它几类的混淆也很多。🤔

下面我们把 loss 最高的图片显示出来看看具体有什么问题。

interp.plot_top_losses(12, nrows=4)

输出的结果反映出了从互联网上抓来的数据存在的典型问题：噪声太多。比如电视的搜索结果里有电视遥控器、电视盒子、电视剧海报，还有一些是完全无关的结果。

FastAI 提供了一个 cleaner 可以帮助我们对比较小的数据集做手动清洗。它可以把整个数据集中 loss 最高的图片列出来让用户可以手动修改标签或者删除。

from fastai2.vision.widgets import ImageClassifierCleaner

cleaner = ImageClassifierCleaner(learner)
cleaner

注意 cleaner 只是做标记，你需要用 Python 代码来做实际处理。我通常就直接把有问题的图片标记为 delete 然后删除。

for idx in cleaner.delete(): cleaner.fns[idx].unlink()

清理完之后重复训练的过程。

objects = DataBlock(
 blocks=(ImageBlock, CategoryBlock),
 get_items=get_image_files,
 splitter=RandomSplitter(valid_pct=0.2, seed=42),
 get_y=parent_label,
 item_tfms=Resize(128))

objects = objects.new(
 item_tfms=RandomResizedCrop(224, min_scale=0.5),
 batch_tfms=aug_transforms())
dls = objects.dataloaders(path)
learner = cnn_learner(dls, resnet18, metrics=error_rate)
learner.fine_tune(3)

如果你注意到 error_rate 在后面的 epoch 有上升的话，可以降低 fine_tune 的参数以达到最好的效果。因为如果训练轮数过多，模型会对训练集 over fit，在遇到新数据时错误率会变高。从上面的输出可以看到准确率提高到了 96% 以上。

达到满意的准确率后就可以把模型导出用到线上了。下面这行代码会把模型保存到 export.pkl。

learner.export()

后端 API

后端 API 是这个项目最简单的一部分，只有一个 endpoint。加载前面导出的模型，收到新图片时用模型来预测分类就可以。

trump = load_learner('model.pkl')

@app.route('/api/1.0/classify-image', methods=['POST'])
def classify():
 image = request.files['image']
 res = trump.predict(image.read())
 response = jsonify({'result': res[0]})
 response.status_code = 200
 return response

完整的代码在 GitHub 上。按照文档部署到 LeanCloud 云引擎就行。

前端网站

前端也比较简单，只需要一个页面让用户上传照片，在浏览器里把照片缩小然后发送给后端 API 就可以。完整的 React 项目在 GitHub，主要的代码在 App.js。限于篇幅就不详细说明了，只附上一张运行的截图：

给读者的作业

你可能已经注意到上面的后端 API 服务是无状态的，没有存储任何数据，所以其实识别的过程可以在前端完成。如果你有兴趣的话，可以调研一下如何把 PyTorch 模型转化为 JavaScript 可用的模型，尝试在浏览器里直接识别照片。在真实的应用中，这样的方式由于不需要向服务端传输任何数据，可以完美地保护用户隐私，这也是 Apple 在推动的 on-device machine learning 的方向。

图片识别是机器学习可以解决的最简单的一类问题，因为有很多现成的结果可以重用，新的应用即使只有少量训练数据也能达到比较好的效果。还有很多其它类型的问题没有那么容易得到让人满意的结果。LeanCloud 目前正在开发机器学习方面的新产品，以帮助开发者更容易地发掘数据的价值。你如果对此感兴趣，可以关注我们的微博、微信公众号、Twitter，或者注册成为 LeanCloud 用户。不久后我们会公布更多信息，并邀请一些用户试用新产品。

最近看完了 Out of the Gobi: My Story of China and America，要是翻译成中文应该叫「走出戈壁：我的中国和美国故事」。作者单伟建上完小学后就因为文革下放到内蒙古生产建设兵团。文革后，没拿到小学毕业证的他进入了北京外经贸大学，之后在旧金山大学获得了 MBA，在 UC Berkeley 取得博士学位，后来在 University of Pennsylvania 任教。现在他是亚洲最大的私募基金之一 PAG Group 的主席和 CEO。这本书提到了很多在中国大陆比较敏感的话题，所以很可惜在目前回归个人崇拜和个人权威的环境下，应该短期内在中国见不到不经大量删减的中文版了，所以只能看 Kindle 版或者听 Audible 的有声书。

这本书讲述了作者前半生的历程：出生在北京一个大院，经历大跃进、大饥荒和文革初期，亲眼见到一些人被残酷地批斗致死，后来被下放到了内蒙古戈壁滩做了六年多徒劳无功的苦活。文革结束后他进入了外经贸大学并争取到了做访问学者的机会，后来在美国一流大学取得多个学位。

这本书里有很多动人的小故事，其中两处大概因为和我自己经历有些共鸣，最打动我。

第一是作者在戈壁滩的六年多里从没放弃学习，没有放弃对更好未来的追求，除了阅读能找到的一切书籍外，还让同被流放的前民航飞行员教他英语。他在去年 UC Berkeley 的一个演讲中说，他看到很多比他更有才华的人因为文革毁掉了一生，周围充满了悲观，但是他不断告诉自己：如果大环境一直很糟糕，自己要在戈壁待一辈子而没有出头之日，他没有谁可怨；但是如果将来发生变化，因为自己没有准备好而失去了改变命运的机会，他只能怪自己。所以他在逆境中也一直在为将来准备。

第二件事是他得到了亚洲基金会赞助到旧金山大学访问，他希望能参与该校的 MBA 课程并争取拿到学位但苦于没有学费。在想尽各种办法无果将要放弃时，他的导师给他带来了好消息：一个匿名捐助人愿意赞助他的学费。于是他成功地注册并开始了 MBA 课程。过了一段时间待他学业有小成之时，他导师告诉他那位匿名赞助人希望约他在旧金山的某个高档餐厅共进晚餐见一面。当导师夫妇身着正装出现在餐厅时，他才猛然意识到原来他们就是捐赠人。多年以后他以导师的名字命名捐赠的奖学金，以帮助更多人追求梦想。

我与作者很有共鸣，因为虽然时代不同，但是我 2002 年以当时所在的学校和背景到美国留学原本也是一件可能性很低的事（更不用说进入一所好学校），这个过程也得到了很多人的帮助，而在美国的 8 年也改变了我很多。我看完这本书后给远在 New Haven 正因为 COVID-19 疫情在家隔离的导师寄了一本作为生日礼物。

这本书在当下的环境有特别的意义。仇恨与冲突都是政客制造出来用来操纵民意、博取支持和所谓合法性的工具。普通人的生活本来离这些东西很远，却往往被煽动起来的狂热毁掉。只有国家走向开放，不同国家的人之间能自由交流，美好的事情才会发生。只愿我们的下一代还能有一个开放、和平的世界。