GoTime#34期 Pachyderm, Provenance, Data Lakes

本篇内容是根据2017年2月份#34 Pachyderm, Provenance, Data Lakes音频录制内容的整理与翻译

Joe Doliner 加入了节目，谈论使用 Pachyderm 管理数据湖、数据容器、溯源(provenance) 以及其他有趣的 Go 项目和新闻。

Erik St. Martin: 大家好，欢迎收听新一期的 GoTime 播客。今天是第34集，本期节目由 Toptal 和 Backtrace 赞助。今天的主持人有我，Erik St. Martin，还有 Carlisia Pinto...

Carlisia Thompson: 大家好。

Erik St. Martin: 还有 Brian Ketelsen...

Brian Ketelsen: 嘿，大家好！

Erik St. Martin: 今天还有一位特别嘉宾，他是一个叫 Pachyderm 项目的联合创始人兼 CEO。我不想透露太多细节，因为我更希望他能亲自向我们介绍这个项目。让我们欢迎 Joe Doliner。

Joe Doliner: 谢谢大家，很高兴来到这里。

Erik St. Martin: 那么，Pachyderm... 在我们深入探讨之前，你愿意先为大家简要介绍一下 Pachyderm 是什么吗？

Joe Doliner: 当然可以。Pachyderm 是一种所谓的数据湖（Data Lake），另一个你可能熟悉的数据湖的例子是 Hadoop 工具生态系统。Pachyderm 的目标是构建一个比现有 Hadoop 更现代化的版本。我们对它的设计有非常明确的看法。首先，我们完全接受了基于容器化的世界观。

使用 Hadoop 时，如果你想处理某些数据，你可能需要编写一个 Pig 脚本，或者写一个包含 Map 和 Reduce 方法的 Java 类…… 它有很多不同的前端工具。而在 Pachyderm 中，处理数据的前端只有一个，那就是容器。你只需要把你的代码放到一个容器中，通过本地文件系统读取数据，就像你在笔记本电脑上操作一样。这样做的好处是，开源生态系统中所有的工具都可以直接被用在 Pachyderm 上的数据科学项目中。

我们喜欢说，如果你能把代码放到容器里，那么 Pachyderm 就能帮助你把它扩展到处理 PB 级别的数据。我们会协调这些容器，复制你的代码，并将数据组织到这些容器中，从而让数据流动起来。

Pachyderm 还有一个非常创新的功能，是 Hadoop 不具备的，那就是版本控制。我相信听这个节目的大家应该对 Git 非常熟悉。Pachyderm 基本上就是为超大规模的数据集实现了类似 Git 的功能。当你的服务器日志流入 Pachyderm，或者你的数据库转储数据到 Pachyderm 时，我们会以非常细粒度的方式对数据进行快照记录，这样你就可以清楚地看到数据是如何变化的。而且，由于当新数据进入时分析会自动进行，你还可以看到数据分析是如何随着数据变化而变化的。这样你就可以清晰地追踪到“这块数据生成了这个分析结果”，并回溯到任何计算中所使用的原始数据。

Brian Ketelsen: 那这是不是完整的数据溯源（Data Provenance）？

Joe Doliner: 完全正确，没错。

Brian Ketelsen: 哇！

Joe Doliner: 数据溯源是 Pachyderm 的一项核心功能。我们可以实现非常细粒度的溯源，甚至可以细化到系统内的单个文件级别。

Brian Ketelsen: 这太厉害了，真是个大突破。

Erik St. Martin: 是的，这对我和 Brian 来说特别有意义，因为我们曾在两个不同的工作岗位上处理过大数据，主要是做欺诈预测和信用评分。在这些工作中，特别是处理法律相关的问题时，数据溯源至关重要。因为你可能需要缓存某些计数或数值，这些数值最终会被用到回归模型中进行评分计算。但如果有人起诉你，你需要能够轻松地追踪到当时使用了哪些数据。这点太重要了。

Brian Ketelsen: 是的，这真的很关键。我记得 Pachyderm 刚发布的时候---应该是大约两年前吧---我们当时就在上一家公司试用了它。即使是它最早期的版本也已经让我印象深刻了。

Joe Doliner: 谢谢夸奖。不过我敢说，当时的版本可能也有很多不够令人满意的地方。

Brian Ketelsen: 确实，当时功能还不多。最早的版本主要是把 Docker 容器流连接在一起，但即使如此，我对这个想法已经非常惊艳了。我很高兴听到你们现在进展得这么顺利。

Joe Doliner: 是的，没错。这个项目之所以能够不断完善，主要是因为我们有更多的人参与其中，我们也对许多概念进行了优化…… 开源的核心就是快速迭代，所以我们现在的成果是过去两年里我们和社区一起快速迭代的结果。

Brian Ketelsen: 你们的开源用户主要是什么类型？平均来说，Pachyderm 的用户是怎样的？

Joe Doliner: 这个问题我经常被问到。让人感到有趣的是，很难定义一个“平均用户”，因为这些工具可以适用于非常广泛的使用场景。我们的一位最著名的用户---他们实际上也是我们的客户，所以我可以用这个词---是一家叫 General Fusion 的公司。他们正在构建全球首个商用核聚变反应堆，这本身就已经非常酷了。但为了做到这一点，他们需要不断对核聚变实验中产生的等离子体进行测试，而这些测试会产生大量数据，这些数据由他们的各种设备记录下来。他们需要一个地方来存储这些数据。所以，他们把所有数据存储在 Pachyderm 中，Pachyderm 会对这些数据进行快照记录，这样他们就可以分发数据给外部的物理学家，让他们用各种工具分析这些数据，找出其中的规律。

另一个我们看到很多用户或客户的领域是机器学习。你们之前谈到过这个领域的一些问题。最近两个月对我们来说特别有利，因为欧盟刚刚通过了一项法律，规定消费者有权获得任何算法决策的解释。比如说，银行现在开始用机器学习来决定是否给某人贷款。

如果你在欧盟，银行拒绝了你的贷款申请，你可以要求他们解释原因：是什么数据导致了这个决定？可以想象，有一个能够自动追踪所有数据溯源的系统会让这件事变得非常简单。你只需查看机器学习模型的溯源，就可以直接告诉消费者“这些数据是被用来做出这个决定的”。所以，我们在这个领域也看到了很多需求。

Brian Ketelsen: 是的，这真是个很大的需求。

Erik St. Martin: 如果大家能想象一下这个问题，就会发现其复杂性：这些数据每天都在变化。有时候数据会出错，需要从系统中删除。而作为评分模型一部分的数据集也在不断变化。所以，能够回溯到某个具体时间点，找到用于计算某个结果的具体数据集是非常重要的。因为消费者可能会在一段时间后提出异议，而在一两个月内，数据集可能会发生巨大变化。能够轻松地回溯“这是当时用于计算这个结果的具体数据集”是一个巨大优势。

Joe Doliner: 是的，没错。而且我们非常喜欢数据溯源的另一点是，它真正实现了科学方法。比如，如果公司内部有一个数据湖系统，而你作为数据科学家加入后，看到某个结果是通过公司过去一年定义的一系列复杂步骤计算出来的。但如果你觉得这个结果看起来有些异常，并想进一步探究它的来源，如果没有办法轻松地追溯这些步骤，找到输入数据和处理过程，那你可能会浪费大量时间去问别人这些问题，只为了能进行进一步实验…… 但在 Pachyderm 中，这一切都是记录好的，也是可复现的。你可以直接查询所有信息，然后开始自己的实验，用以进一步验证结果。

Brian Ketelsen: 这真的了不起。你能谈谈 Go 在其中的作用吗？我知道你们用了很多容器化技术，但你们的守护进程（daemon）是用 Go 写的吗？是什么把这一切粘合在一起？

Joe Doliner: 当然可以。整个系统都是用 Go 写的。这是因为我们所使用的所有技术本身都是用 Go 开发的，所以它们最好的客户端库也会是 Go 的。比如 Docker、Kubernetes 和 Etcd…… 我们部署的整个技术栈基本都是 Go 的。我们基于 Kubernetes 部署，利用 Etcd；当然，Docker 容器是用户提供给我们用于处理数据的一切。

此外，Go 是开发这种系统级软件非常棒的语言。我们部署的主要组件是 Pachyderm 的守护进程，也叫 Pachd。这是一个用 Go 编写的服务器，使用 gRPC。gRPC 让我们可以非常轻松地搭建结构化的 API，然后专注于编写实际的核心代码。这也是 Go 的一大优点---它不会妨碍你，你可以专注于编写真正重要的代码。

我们还有一个前端命令行工具叫 Pach Control，也是用 Go 写的。它使用了 Cobra，这是 Steve Francis 开发的命令行工具库，非常好用。这大概就是我们的架构，实际上很简单。

Erik St. Martin: 那么，选择 Go 的主要动机是因为你们需要使用的其他组件已经是用 Go 开发的吗？

Joe Doliner: 是的，绝对是这样。而且我们知道，Go 团队最关注的用例正是我们的用例。Google 内部使用 Go 的主要目的是写服务和命令行工具。所以我们知道…… 使用开发者认为工具最适合的场景总是最好的选择，因为你会得到最好的支持。

Erik St. Martin: 太棒了。那么在容器内部的数据层面呢？Pachyderm 是否为用户提供了任何工具来帮助他们构建自己的数据处理组件，还是完全让用户在容器中自行处理，而你们只负责工作负载的分配？

Joe Doliner: 我们负责所有可以被称为“数据编排”的工作---哪些数据需要被处理，在哪些容器中处理。但具体如何处理数据完全由用户决定。比如，在 Pachyderm 中，我们以“仓库”（repo）的形式管理数据，模仿了 Git 的语言。你可能有一个存储服务器日志消息的仓库，而你想要处理这些日志，比如查找特定的事件。

你需要做的就是编写一个二进制程序，把它放到一个容器中，然后交给 Pachyderm，告诉它“这是我的容器，这是我要在容器中运行的命令”。当这个命令在容器中运行时，它会在文件系统中看到一小部分日志消息供你处理。你只需要从磁盘读取这些数据，进行你想要的处理，然后把结果写回文件系统的另一个位置。

当代码运行完后，Pachyderm 会自动收集这些数据，把它放回文件系统，并触发下游的处理流程。我们负责所有的流水线编排和数据分发，而你只需要负责具体的分析逻辑。

这种方式也能处理非常复杂的数据集联结。你可以对多个数据集进行大规模联结，我们会分发并编排所有这些工作，以便你的代码可以运行…… 但你只需要写“当数据在磁盘上时，我该如何处理它”的逻辑。

Brian Ketelsen: 天哪，我现在只想停下手头的工作去试试这个工具。

Joe Doliner: 我们非常欢迎你去试试，但不要现在就停下，因为我们还要继续完成这期节目。[笑声]

Brian Ketelsen: 我们之前已经证明了，即使没有我，节目也能继续下去。所以我要暂时离开，去下载一些 Docker 容器，稍后回来。[笑声]

Joe Doliner: 好的。

Erik St. Martin: 我们会在节目结束时把他叫回来，让他告诉我们他的使用体验。

Joe Doliner: 希望他会有好的体验。我现在正为此祈祷。如果你遇到任何问题，可以加入我们的用户交流群。

Brian Ketelsen: 这听起来真是太棒了。

Erik St. Martin: 这可能会是个有趣的节目形式---给节目中的某个人布置一个任务，然后在结尾再来看他的完成情况。

Joe Doliner: 我觉得这可能是一个很棒的广播版开源体验。你可以看到我们现场为一个开源项目提供支持。不过不幸的是，这可能会让听众觉得非常无聊，因为我会问一些问题，比如“权限设置对了吗？用户路径对了吗？”之类的。但确实可能会很有趣。

Brian Ketelsen: 是啊，我的 Docker 卷（volumes）又出问题了。

Joe Doliner: 哦不……又是 Docker 卷的问题。

Brian Ketelsen: 我几天前也遇到了这个问题…… 我刚安装了一个新的 Linux 发行版，因为我每个月都换一次发行版。这次我又换回了 Arch，但最新的 Arch Linux Docker 包只有在使用 Overlay 文件系统时才能正常工作，而 Arch 的包里并没有捆绑所需的 Overlay 库，也没有明确提示。我花了大约一个小时到处查找，试图弄明白为什么 Docker 没法正常工作。最后，我终于在某个不起眼的地方找到了一条小提示，说“你需要安装这个 Arch 包来让 Overlay 正常工作”。

Joe Doliner: 这听起来就是经典的 Linux 使用体验。某个地方有一条小提示，如果你能用 Google 搜到它，它会告诉你该怎么做。但在你找到之前，你完全无从下手。

Brian Ketelsen: 是的，完全正确。这就是我们日常的操作，所以这种任务不适合一个时间受限的节目。[笑声] 你永远不知道它会是一个十分钟的任务还是一个十天的任务。

Joe Doliner: 最糟糕的是，当你在 Linux 的论坛上找到一个有类似问题的帖子，提问者详细描述了问题，但没有人回答。然后十天后，提问者更新帖子说“找到答案了，谢谢大家”，却不写出解决方案。所以你仍然一头雾水，但知道某人确实解决了这个问题。

Erik St. Martin: 我知道 Go 社区里的人可能会发这个链接，但有一个 xkcd 的漫画就讲了类似的事情，漫画里问“你是谁，某某人？你发现了什么？”因为多年后你会再次回到这个问题。

Brian Ketelsen: 完全正确。而且，比有人解决了但不告诉你答案更糟糕的是，当你在网上搜索解决方案时，发现了自己以前发的帖子，并且帖子里写了答案。我不知道我有多少次遇到过这样的情况。

Joe Doliner: 是的，我也遇到过。

Brian Ketelsen: 为什么我第一次解决的时候就没能记住呢？

Erik St. Martin: 我要说一下社区有多棒，因为我刚才开玩笑说会有人发链接。不到30秒，就有人发了。

Brian Ketelsen: 太棒了！

Erik St. Martin: 所以，听众们注意了，这是 xkcd 的第979集。

Brian Ketelsen: DenverCoder9，你是谁？ [笑声] 真是太有趣了。

Erik St. Martin: 我通常不会发帖提问。我更倾向于私下问人或者在频道里讨论，所以我很少遇到自己提问的帖子。

Brian Ketelsen: 我的问题通常是发在博客上的。我写了一篇关于如何做某件事的博客，然后两年后我再次需要做这件事，结果发现自己的博客回答了我的问题。这让我很无语。

Erik St. Martin: 你自己的博客...

Brian Ketelsen: 是的，这真的很尴尬。那么，Pachyderm 作为一个用 Go 编写的编排系统，Go 的哪些特性让你们的开发更加顺利？同时，在这么大规模的编排系统中，与 Go 开发者社区的协作又是怎样的？

Joe Doliner: Go 的一些特性确实让开发进展顺利。首先是它自带的库非常全面。比如，它有一个内置的 HTTP 库，而且很好用。在此之前，我在 RethinkDB 上用 C++ 编程，那时我记得我们不得不自己写 HTTP 库和 HTTP 服务器，因为很难集成现有的工具。

我认为 Go 最棒的特性就是它的“开箱即用”（batteries included）。标准库中有许多非常好用的东西。除此之外，goroutine 对我来说是最好的并发方式。

在我们做 RethinkDB 时，我们首先为 C++ 写了一个协程库，这样我们就可以使用类似 goroutine 的并发风格。但这个库远没有 Go 的 goroutine 那么简洁优雅，因为 Go 只需要几个基本原语（primitives），你几乎就能实现任何事情。除此之外，我们还用了一些标准功能，比如接口（interfaces）、函数等…… 但我觉得，用 Go 的人很难避免使用这些东西。

Brian Ketelsen: 是的，至少想成功的话就很难避免。

Joe Doliner: 是的，否则很难用好 Go。我无法想象如果你只能使用结构体和简单函数的话，Go 会是什么样子。

Brian Ketelsen: 就像 Pascal。

Joe Doliner: 对，没错，就像 Pascal。

Erik St. Martin: 哇。

Brian Ketelsen: 那么，目前为止，你看到的 Pachyderm 最大的使用场景是什么？客户的数据规模一般有多大？

Joe Doliner: 我们目前看到的数据规模大概在几百 GB，这是目前最大的情况。这比我们最终想达到的“大数据”规模要小得多。

但我们发现一个很有趣的现象：有很多用户的数据规模处于 1TB 以下的中间地带。他们不想仅仅依靠一堆脚本在 AWS 机器上运行，也不想用一台放在自家机房的大服务器，因为那样太难管理了。所以他们需要一个编排层来帮他们管理这些数据，但这并不完全是为了处理超大规模数据。

我们现在正在进行一项大规模的优化工作，基本上是用户在推动我们这样做，因为他们的使用案例越来越大，系统开始暴露出一些问题。我们正在努力突破系统目前的瓶颈，我预计可能在接下来的三到四个月内，我们会进入多 TB 的数据范围。

Brian Ketelsen: 很棒！那现在对数据规模的限制主要是什么？

Joe Doliner: 有很多限制。我们遇到的一个主要问题是，如何确定数据在 Docker 容器内部的存放位置，以防止系统崩溃。目前，Kubernetes 并没有提供磁盘空间配额的功能。你可以在调度 Pods 时请求内存和 CPU 配额，但无法请求磁盘空间。起初，我们直接把数据写入 Docker 容器内部，这种方式可以用，但后来发现 Docker 文件系统中有一个 10GB 的写入限制…… 这完全可以理解，因为这是一个 Overlay 文件系统，不应该写入太多数据。我们解决了这个问题：可以将数据直接写入主机路径，但这会让编排变得更加复杂。

另一个问题是我们有两种有趣的扩展方向。一种是超大型文件，比如 100GB 的文件，用户会把它们放到 Pachyderm 中处理。另一种是小文件，但数量可能有上百万个。在处理百万级文件时，我们在某些地方打开了过多的连接来下载这些文件，导致文件描述符耗尽等问题。

这些问题都是系统在高负载下暴露出的典型边界问题。我们需要不断打磨这些棱角，让系统能够真正胜任这些工作负载。

Brian Ketelsen: 你认为未来还会有分布式文件系统的使用场景吗？我知道最近在这方面有很多活动，有一些非常有趣的分布式文件系统，很多都是用 Go 写的。

Joe Doliner: 是的，Pachyderm 的核心组件之一是 Pachyderm File System，也就是一个分布式文件系统。这是它与其他分布式文件系统的主要区别，因为它内部集成了所有的版本控制逻辑。我确实认为会有许多不同分布式文件系统的用例。我们现在感到非常兴奋的一个项目是 Minio，虽然严格来说 Minio 不是分布式文件系统，它是一个对象存储，但你知道，差别并不大……它们在很多方面可以被用作相似的用途。

Minio 的团队实际上已经让 Pachyderm 能够在 Minio 上运行，这非常令人兴奋。之前，你需要将 Pachyderm 部署在某种对象存储之上，这对于云平台来说非常方便，因为你可以用 S3、Google Cloud Storage 或者 Azure Blob Storage。但如果你想要一种平台无关的方式，或者你想在本地运行，我们之前的最佳答案是 RADOS，也就是 Ceph 的底层存储……它是 S3 兼容的，但设置起来有点复杂。

而 Minio 的设置非常顺畅。它完全用 Go 写成，我们现在已经在 Pachyderm 中对它提供了直接支持，因此它是我们目前首选的本地部署解决方案。

Brian Ketelsen: 太棒了！说到 Minio，我们非常喜欢 Minio 的团队。他们是开源项目中最支持社区的团队之一。他们几乎支持了我能想到的所有 Meetup，比如 Women Who Go、GoTime FM 和 GopherTime……他们真的是非常棒的社区成员，我很喜欢他们。

Joe Doliner: 是的，他们也在支持我们，而我们也是另一个开源项目。通常情况下，你很少看到开源项目之间有这样的支持，但他们主动联系了我们，并为我们做了这些。所以，是的，那些家伙真的很棒。

Brian Ketelsen: 这真是太酷了。

Erik St. Martin: 我觉得是时候进入我们的第一个赞助商环节了。广告之后，我很想和你聊聊---你在节目前的邮件中提到了一些关于开源项目的有趣话题，比如如何运营一个大型开源项目并围绕它建立一家公司。我很想深入探讨这个问题。不过，先来介绍一下今天的第一个赞助商 Toptal。

广告时间

Erik St. Martin: 我们回来了。我们正在和来自 Pachyderm 的 Joe Doliner 聊天。在广告之前，你提到维护一个开源项目的人性化问题，以及如何保持开源的同时围绕它建立一家公司。我很想听听你的想法，因为这个问题很有趣---如何免费分享你的技术核心，同时又能围绕它建立一个成功的公司？

Joe Doliner: 这是一个非常有趣的问题，短答案是：我认为这是一个非常难的问题。有些人在我告诉他们我们的软件是开源时会说：“哇，那是不是意味着你永远无法从中赚钱？” 这并不完全正确，但这是一个非常贴切的直觉，因为这看起来确实像是你在免费送出核心技术，而如果你无法限制用户的访问，那就很难收费。

从头开始说，要让一个开源项目获得任何关注并吸引人们的兴趣，你需要对外部世界的人们的激励进行对齐。首先，你需要做一些对人们有用的东西。它必须解决一个真实的问题，与现有的东西相比，它必须足够好、足够不同，以至于人们愿意忍受使用新产品的痛苦，因为在项目的早期阶段，它一定会很糟糕。这是无法避免的。软件需要经历很长一段时间的“不好用”才能变得真正好用。所以你需要提供一些非常有趣和引人注目的新东西，才能让人们走进门并开始尝试你的软件。

接下来，你需要开始获取开发者的兴趣，而这在很大程度上涉及到如何把项目定位在一些有趣的东西旁边。对我们来说，我们一直与 Docker 的关系非常密切。从我们开始时，Docker 就在爆炸式发展（现在依然如此）。

对很多人来说，我们是他们能用 Docker 做的一些有趣的新东西。他们一直想玩 Docker，一直想研究 Docker……而我们的项目吸引了另一群人---数据科学家和更多数据导向的人，所以我们成了他们用容器时感兴趣的产品。

你还需要考虑你的产品部署的难易程度。部署新产品总是有一些成本的，而对某些产品来说，这种成本是无法克服的。我觉得一个很好的例子是 Urbit---你们听说过这个项目吗？

Brian Ketelsen: 嗯哼。

Joe Doliner: Urbit 是一个非常酷的想法，他们正在构建一个加密安全的点对点服务器网络，用户可以获取一个可以运行任何东西的服务器，但问题是它的使用方式非常晦涩，特别难以使用。尽管如此，人们还是在使用它，他们也知道这是一个问题，并且正努力改进……但对我们来说，我们希望一开始就很好地解决这个问题。

我们注意到人们正在转向容器和容器编排工具，比如 Kubernetes，而 Kubernetes 看起来在容器编排工具中是最出色的……所以我们很早就决定让我们的产品完全基于 Kubernetes 部署。这意味着当我们试图让某人使用我们的产品时，如果他们已经在使用 Kubernetes，我们可以在 30 秒内为他们部署完成。这只是一个简单的 Kubernetes manifest 文件。这种能让用户快速体验到产品“魔力时刻”的方式---让他们真正用上产品的反馈循环越短，你的成功就越大。

另一个非常有趣的方面是如何围绕开源构建公司。我们需要雇用开发者来完成 Pachyderm 的大部分开发工作，而这些开发者通过工作获得报酬，这是将金钱与激励对齐的好方法。

为了做到这一点，你需要找到一种最终能通过产品赚钱的方式。我觉得对某些类型的开源项目来说，这种方法是完全行不通的。例如，如果你开发了一个开源的 BitTorrent 客户端，我不认为有人会为此付费。当然，也许我错了，我很乐意被证明是错的，但我认为很多人不会。

幸运的是，对于我们来说……当企业在数据基础设施上投资时，这是一个很大的投资。如果他们在运行 Pachyderm，他们很可能会有 10 或 20 个工程师每天将它作为工作流程中的重要部分。在这种情况下，企业通常非常愿意为支持合同付费，因为这可以提高他们开发人员的效率，节省成本……这也是我们目前赚钱的方式，我们向公司出售支持合同。这意味着他们可以打电话给我们，我们会解决他们遇到的任何问题。

另一种开源项目的商业模式是将其转变为某种托管模式。虽然这个类比并不完全准确，但 GitHub 可以看作是 Git 的一种商业化策略，对吧？GitHub 本身不是开源的，但你可以看到它是如何运作的。

我们计划最终为 Pachyderm 构建一个类似的服务，目前暂定名为 PachHub。你可以想象这将是一个类似 GitHub 的网站，但它不是代码仓库，而是数据仓库，并且有处理这些数据的管道。你可以看到整个社区如何处理这些开源数据，你也可以修改他们的工作，或者为我们希望构建的这个开放数据科学社区做出贡献。

Brian Ketelsen: 你之前在那个很长的独白里提到的一件事---非常感谢---是关于人们如何对开源项目感兴趣，以及如何让社区和开发者参与进来。这让我意识到，比起项目本身的点子，我更容易被项目的愿景以及它如何呈现这一愿景所吸引。因为每个问题都有很多种解决方法，但对我来说，愿景的传递往往是让我保持兴趣的关键。

即使在项目早期的“艰难阶段”，也就是你提到的那些事情没有按计划运行、或者还没有达到预期效果的时候，愿景的传递依然是关键。项目如何向我传达他们想去的方向，他们的愿景是什么，这些都是让我对开源项目感兴趣的主要原因。

Joe Doliner: 是的，完全同意。你确实需要向人们“推销”一个未来世界的梦想。我们花了很长时间反复修改、改进我们对愿景的描述，以便更好地引起人们的共鸣。我觉得现在我们有了一些对一大群人来说很有效的东西，但可能还没有对所有人都奏效。

Brian Ketelsen: 但是，当你回顾过去那些非常成功的开源项目时，很多都有一些富有魅力的领导者，他们会发表一些甚至有时是颇具争议的言论。在 Rails 社区的 DHH (译者注: 丹麦人, Ruby on Rails作者,37signals合伙人兼CTO)，在 Docker 社区的 Solomon Hykes ---他们经常发表一些颇具争议的声明。而在另一端，比如 Kubernetes 的 Joe Beda 和 Tim Hockin，他们的领导方式则非常安静、冷静，但规划周密，沟通也非常到位。

我觉得开源项目的采纳曲线在某种程度上也与领导者的个人魅力有关。

Joe Doliner: 是的，绝对如此。领导者的魅力和个性总是不可避免地渗透到项目本身以及社区中，并影响到整个运作方式。具有争议性是非常有价值的。当然，你不能为了争议而争议，但你应该始终愿意为你认为正确的事情发声---“这是我们希望产品所走的方向，这是我们看到的未来，我们要么惨败在实现它的路上，要么成功到达那里，迎来一个巨大的成功。”

Brian Ketelsen: 是的，这确实呼应了我之前的观点---你是在“销售”一个愿景，而推销这种愿景的方式和力度是吸引我参与一个项目的原因。我刚刚意识到这一点。

Erik St. Martin: 是啊，试图在保持盈利和持续回馈社区之间找到平衡，这确实是一个有趣的世界。

Joe Doliner: 完全同意。我还想说，当然，我觉得最初那个既有魅力又颇具争议的领导者例子应该是 Linus Torvalds。他总是毫不犹豫地为自己相信的事情发声，我认为这非常棒。

Erik St. Martin: 这很难……有时候我真希望自己天生就拥有让他如此自信的那种基因。[笑声]

Brian Ketelsen: 我不知道，这真的很难……很多那种有魅力的领导者……我无法想象自己没有他们那样的“过滤器”。

Erik St. Martin: 但有时候你会觉得，如果你能够随心所欲地说和做任何事，而不去考虑别人如何看待，那样或许会更快乐一些。你可能会少一些关于自己言行的压力。

说到邮件---我们之前聊到了一些项目，还有 Go 生态中你感兴趣的一些东西。你提到一个项目……我想它叫 Gitea，是这么发音吗？

Brian Ketelsen: 是的，Gitea。

Joe Doliner: 嗯，我猜它的名字是结合了“git”和“tea”（像饮料茶一样）。是的，我之前在浏览一些 Go 项目时看到了它。我觉得它真的很酷，因为它就像一个开源版的 GitHub。我觉得在当前的开源世界里，一个长期无法维持的现象就是 GitHub 已经成为开源的中心，但它本身却不是开源的。这种情况看起来不可能无限持续下去。我不知道，也许 GitHub 最终会被迫开源一些东西。

还有 GitLab，我其实和 GitLab 的创始人是朋友。我希望有一天他们能在开源领域引发一些革命性的变化。但尽管我认为 GitLab 很棒，我现在还是不得不把 Pachyderm 放在 GitHub 上，因为那里是人们寻找开源项目的地方。某种程度上来说，如果你不在 GitHub 上，你就“不存在”。我总是对那些挑战这种现状的开源项目感兴趣。

我在 Google 文档里看到 Gitea 是 Gogs 的一个分支，这点我之前没意识到。

Brian Ketelsen: 是的，那是一个“政治性分叉”。Gogs 的维护者只有一两个人，他们对变更的接受度不高，所以社区中有一部分人对此感到沮丧，最终分叉出了 Gitea。

Joe Doliner: 有意思。

Brian Ketelsen: 那是去年的事了，是的。

Joe Doliner: 嗯，这确实很能代表开源领域的现状。这也是 GitHub 的优势所在---GitHub 的员工不会因为不满而分叉（fork）出一个 GitHub，因为我觉得他们做不到这点。开源有利有弊，但我最终认为我们需要一个开源版本的 GitHub。

Brian Ketelsen: 我也这么觉得。我昨天为 Gopher Academy 做了一场直播课程，主题是“如何在一个 Go 项目中提交你的第一个 pull 请求”。这是一堂很有趣的课，因为我知道很多人，尤其是在企业环境中工作的人，会对开源感到畏惧。他们在公司里很少接触开源。我们有很多大型企业客户仍在使用 Subversion，甚至是其他版本控制系统，所以 Git 对他们来说是新鲜的，而 pull 请求的概念对他们也是全新的。

这是一堂很有趣的课程，但让我感到几乎是讽刺的一件事是，Git 是一个巨大的、去中心化的版本控制系统，但现在 99% 都集中在 GitHub 上了。这种讽刺感让我觉得很有趣。

Joe Doliner: 是啊……Linus 给我们提供了一个很棒的去中心化版本控制系统，而 GitHub 则贴心地把它中心化了，这样才有人可以从中盈利。这种讽刺实在是太深刻了。

Erik St. Martin: 但这背后也有一个有趣的视角，无论是对技术的新理解，还是其他的。Linus 创建它是为了让分布式团队更好地协作，对吧？但我觉得 GitHub 确实给它带来了自己的创新。他们改变了开发者分享代码的方式。

我猜在 GitHub 之前也有 SourceForge 和类似的平台，但它们并没有像 GitHub 一样让人感到互动性那么强。

Brian Ketelsen: 一点也不。GitHub 把它变得“社交化”了，我觉得这是最大的不同。这非常重要。这是一个重要的愿景---一群有共同愿景的人定义了事物应该如何运作，人们认同了这个愿景，这让 Git 真正流行了起来。老实说，在 GitHub 出现之前，Git 并没有那么火。

Joe Doliner: 没错，我感觉刚才对 GitHub 有点批评太多了，因为它是闭源的。但不得不说，他们为开源社区做了非常棒的事情。我大学时用 SourceForge 做过一个项目，那真是太糟糕了。我甚至连最简单的事情都搞不明白。即便有人帮我，我也搞不懂。而在 GitHub 上，一切真的---它就是“有效的”。它有你想要的功能，而且它是社交化的……这种感觉很难确切说出所有让它成功的不同之处，但它确实做到了其他系统失败的地方。

这有点像 iPhone 之于智能手机的意义，用一个很老套的比喻来说。它把所有的小细节都做对了，最终融合成了一个非常吸引人的产品。

Brian Ketelsen: 是啊，我很好奇你们的 PachHub 会是什么样子。因为在大数据处理领域，无论是分享数据还是分享数据管道，甚至是小型函数让人们可以加入数据管道，这似乎是一个尚未开发的市场，非常适合吸引大量用户。这是一个巨大的市场，到处都是数据，很多人用 Perl 脚本、Python 和 Go 做着疯狂的事情。如果有一个中心化的地方可以处理这些事情，或许这就是让数据领域成为下一个 Git 的东西。

Joe Doliner: 是的，没错。这确实是我们长期愿景的一部分。正如你所说的，这是一个很大的问题，而且我觉得很多人都知道这是一个问题。如果你去硅谷转一圈，你会发现很多初创公司都试图成为“大数据领域的 GitHub”。但我看到的所有尝试都没能达到这个愿景的期望。这是因为他们基本上只是试图在现有工具上构建一个 UI，而实际上你不能这样做。要构建“大数据领域的 GitHub”，你首先需要“大数据领域的 Git”。这就是 Pachyderm 的意义。

所以，一旦我们有了“大数据领域的 Git”，并且找到了让人们享受这种体验的方式，我觉得我们就为“大数据领域的 GitHub”奠定了很多基础。但这也是一整套全新的挑战，我们作为一个项目和公司，将需要不断成长，去理解如何应对这些挑战。

Brian Ketelsen: 太棒了。我可能有点夸张，但你的愿景让我成为了你的新粉丝。

Joe Doliner: 听起来不错。如果这听起来像“兄弟情”，那我也会把它当好事接受（笑声）。

Erik St. Martin: 我觉得是时候进行今天的第二个赞助商插播了，然后我们会继续讨论更多的项目和新闻。今天的第二位赞助商是 Backtrace。

插播广告：

Erik St. Martin: 好的，我们回到节目中，继续和 Joe Doliner 聊天。刚才我们在讨论 Gitea---我们似乎一致认为它是这么发音的。

Brian Ketelsen: 希望是这样……

Erik St. Martin: 估计有人会纠正我们。接下来是项目和新闻环节。最近有没有什么有趣的事情？

Brian Ketelsen: 天啊！

Erik St. Martin: 或许我们能提一些 Joe 没见过的东西。

Brian Ketelsen: 最近有很多有趣的东西上线了。我最喜欢的一个是 Wuzz。它在 github.com/asciimoo/wuzz。

Erik St. Martin: 我就知道你会提这个……

Brian Ketelsen: 你怎么知道？

Erik St. Martin: 因为你之前还特地用 Google Hangout 给我演示过。

Brian Ketelsen: 对，我当时太兴奋了。这就像 Postman，如果你用过 Chrome 的 Postman 扩展来做 curl 请求什么的。它是一个漂亮的 ASCII 界面，你可以直接在终端中使用。你可以修改头信息，添加请求体，发出请求，查看响应---所有这些都在终端中完成。这让我少了一个离开命令行的理由。做得非常棒，而且它发布几天后就在 GitHub 上收获了两三千颗星。

Joe Doliner: 看起来现在已经有四千了。

Brian Ketelsen: 哇哦。它几乎每天都会出现在我订阅的 Changelog Nightly 邮件中，那封邮件会列出当天最热门的仓库。这是一个大消息。这是一个很棒的工具。我从几天前看到它的第一个版本开始就一直在用，而且以后也不会停下来了。

Carlisia Thompson: 是的，我也很喜欢它。用 curl 很棒，但每次我们需要重新发起一个调用时，都要在命令行里导航来回修改。而用这个工具，你只需要切换到不同的面板，输入或删除内容……真的很棒。

Erik St. Martin: 我可能没这个问题，因为我用的是 Vim bash 设置，所以我直接用 Vim 命令跳转和修改。

Brian Ketelsen: 确实挺不错的。

Joe Doliner: 我非常喜欢这种工具……我一直是它的粉丝。我真的很喜欢这种命令行界面和图形界面结合的工具。它们介于需要打开的实际应用程序和命令行之间，是一个很不错的中间地带。我还喜欢它的原因是，我真的花了很多时间盯着 curl 的手册，试图搞清楚到底发生了什么。而现在有了这样一个漂亮的可视化工具，它可以告诉我最终需要的 curl 命令并验证请求，真的太棒了。

Brian Ketelsen: 是的。昨天有一段时间，我开了五个这样的窗口，每个窗口都在发送不同的请求或者接收不同的响应，同时查看这些内容真的很美妙。这让我很开心。我热爱那些解决简单问题的开源项目，尤其是做得非常好的项目，它们总能让我感到愉快。

Carlisia Thompson: 我还有一个项目，它叫 Ozzo Validation 。它是一个用于 Go 的验证包，类似于 GoValidate，我以前用过 GoValidate。不过这个项目有些不同，因为它的验证规则和结构体（struct）是分离的。在 GoValidate 中，你需要通过结构体标签（struct tags）来定义验证规则。而 Ozzo Validation 则将规则完全分开支持嵌套验证，还有很多其他功能。真的很酷。

Brian Ketelsen: 是的，我昨晚玩了一下这个工具。我非常喜欢它。结构体标签很容易被滥用，而且通常很难维护。但 Ozzo 允许你使用简单的函数，避免了结构体标签的混乱。我很喜欢这个工具，还特意记下来，可能下次我就会用它。

Joe Doliner: 它看起来似乎可以和结构体标签很好地配合使用，因为结构体标签在编译时是静态的，如果我没记错的话。当然，它们也可能在运行时产生一些影响，但它们主要是编译器可以处理的内容。而 Ozzo 是运行时的代码，这样你就有了两种很好的工具，用来在你需要验证数据的不同阶段进行验证。

Brian Ketelsen: [笑] 我可以花一整个 40 小时的工作周来讲解如何疯狂地滥用结构体标签。我几乎都试过了。结构体标签绝对不仅仅是编译时的东西。

Erik St. Martin: 是的，因为很多结构体标签的实际使用案例最终都是动态评估的。

Brian Ketelsen: 是的，而且还是那些有趣的用法。

Erik St. Martin: 对。不过你也可以将这些和代码生成器结合使用，这样你可以通过反射更好地生成代码，而不是手动做后续改动。

Joe Doliner: 是的，这确实如此。事实上，如果你愿意的话，还可以通过这种方式进一步滥用结构体标签。

Erik St. Martin: 这似乎是人们大量使用反射的原因之一，就是因为他们想查看结构体标签……不过我也可能错了。我尽量避免使用反射。

Joe Doliner: 是啊。反射在人的世界里是很棒的，但在编程世界中却是很糟糕的。

Erik St. Martin: [笑] 在验证领域，我还希望有人能挑战 Melissa Data 的地位。拜托了。

Brian Ketelsen: 天啊……Melissa Data。

Erik St. Martin: 是的，用来验证名字，还能……

Brian Ketelsen: 地址。

Erik St. Martin: 对，地址、邮政编码、通过邮政编码映射电话号码、从名字推测性别，类似的验证。它们还大量使用 C 语言。

Brian Ketelsen: 说到“亵渎”，我记得它是一个 2 GB 的 Docker 容器。

Erik St. Martin: 是 10 GB。

Brian Ketelsen: 10 GB？哦……我记得光推送这个容器就花了整个下午。

Erik St. Martin: 我们曾经在数据管道中必须做的一件事，就是将所有数据通过 Melissa 处理，以便标准化……

Brian Ketelsen: 是的，标准化、验证、清理……呃。

Erik St. Martin: 对。

Brian Ketelsen: 如果有人能开发出一个现代化的 API，用于数据清理和验证，并且和 Melissa 一样快，那肯定能赚大钱。

Erik St. Martin: 有一个叫 SmartyStreets 的，但它不能在本地运行。

Brian Ketelsen: 是的，不过 SmartyStreets 还是很快的。作为一个托管解决方案，它的速度非常快。他们的幕后技术很厉害，我记得我们曾和他们开过一个电话会议，他们告诉我们为什么速度这么快，确实很令人印象深刻。但它是托管的，这让我们很难使用。数据不能离开数据中心。

Erik St. Martin: 我看到一篇文章，关于新推出的 dep 工具，据说它可能会成为 Go 的一部分。这篇文章是 Edward Muller 写的，他和 Peter Bourgon 在一个团队里……还有谁来着？

Brian Ketelsen: Sam Boyer……

Carlisia Thompson: Jess Frazelle……

Brian Ketelsen: Jess 和 Andrew Gerrand……

Erik St. Martin: 他们是一个团队，一起试图解决 Go 的依赖管理问题。他发布了一篇文章，我们会在 Twitter 上分享并附在节目的说明中，名字叫《Dep 101》，介绍了如何使用这个工具。我们实际上已经安排了 Sam Boyer 本月底来参加节目，所以大概三月初那集会发布。他会来聊这个工具。他写了所有那些复杂的算法来解决依赖问题。这些算法已经被打包成一个库，所以如果你在开发自己的工具，也可以使用这个库，它就是 dep 工具的核心。

Brian Ketelsen: 是的，你知道这背后有很多数学……想想依赖链和背后的图形结构，肯定比我感兴趣的数学复杂得多。

Joe Doliner: 这确实是一个非常难的问题，因为如果你不小心，很可能会误入 NP 完全问题的领域，导致工具完全停滞。所以你必须找到非常高效的解决方法。

Brian Ketelsen: 是的。

Erik St. Martin: 那个工具叫 GPS。

Brian Ketelsen: GPS，没错。

Erik St. Martin: 它是一个打包求解器。

Joe Doliner: 这可能是我对 Go 未来最兴奋的事情之一。我认为 Go 目前最大的未解决问题就是依赖管理，这对我们 Pachyderm 来说是一种持续的挑战---让我们的依赖与外部世界保持同步，接收更新，然后解决更新带来的问题。

Brian Ketelsen: 我觉得这是每个地方的问题。

Joe Doliner: 是的，不同的编程语言在解决这些问题上有不同程度的进展，但很多时候，人们会告诉你某种语言的生态看起来比实际情况要好一些。我听说 Rust 的生态环境非常不错---他们有 Cargo 或类似的工具……但依然存在很多依赖管理的固有问题，不可能用魔法完全解决，所以你需要在某种程度上选择一个“毒药”，而不管怎样，总会有一些奇怪的边缘情况。

Brian Ketelsen: 是的，我同意。Cargo 确实做得很好，但我在 Rust 世界里看到的问题并不是 Cargo 本身，而是 Rust 本身快速变化且经常破坏兼容的 API。即使是今天……我记得两年前我玩 Rust 的时候，你根本无法编译网上找到的 Rust 代码，因为 API 变化太大，依赖包也随之改变。而且这种问题在 Rust 里至今依然很严重。但相较之下，我非常欣赏 Go 的 1.0 稳定性保证。用 Go 1.0 写的代码可以在下周发布的 Go 1.8 中继续编译。

Erik St. Martin: 更早的时候，在 Go 1.0 之前还有一个叫 Gofix 的工具，我当时对它真是感激不尽。

Brian Ketelsen: 真是个好工具。

Joe Doliner: 是的。

Erik St. Martin: 我只记得有一次发布让我需要修改代码，那次是他们引入了……

Brian Ketelsen: 是 HTTP 相关的改动吗？

Erik St. Martin: 不，是把字符从 int 类型改成了……

Brian Ketelsen: Oh，改成了 rune？

Erik St. Martin: 对，就是那次。因为编译器无法判断某个值究竟应该是整数还是字符，所以他们就留给开发者自己处理了。

Brian Ketelsen: 说到 Go 和“老派”技术，Erik 和我从 R56 版本起就把 Go 用在生产环境了。

Joe Doliner: 哇！

Brian Ketelsen: 这可是远远早于 Go 1.0 的版本啊（笑）。

Joe Doliner: 我还没用 Go 用到那么早的版本。

Erik St. Martin: 我不知道该为此感到骄傲……

Joe Doliner: 你应该感到骄傲！

Brian Ketelsen: 那确实很棒。

Erik St. Martin: ……还是该为冒这样的风险感到羞愧。

Brian Ketelsen: 不管怎样，它解决了我们的业务问题。说到另一个有趣的项目，它其实并不算新，但我越想越觉得兴奋，那就是 JetBrains 的 Gogland IDE。我平常不是个 IDE 用户，但从 Gopher Academy 的角度来看，一个高质量、商业支持的 IDE 的出现，对 Go 在企业中的普及绝对是好事。

我非常期待它的正式发布。我已经稍微玩过一点，发现它确实非常高质量。他们拥有的功能和代码分析工具是开源世界中，比如 Vim 和 Emacs，所不具备的。所以我很期待 Gogland 的发布，以及它作为一个受支持的高质量产品的到来。我觉得这对 Go 的长期发展来说是件好事。

Joe Doliner: 是的，我同意。我觉得最好的例子就是 Java。Java 在企业界如此成功，很大程度上得益于他们有非常好的 IDE，比如 Eclipse 和 JetBrains，这让更多人能够使用这门语言。

Brian Ketelsen: 还有什么令人兴奋的新闻、产品或项目是我们这周遇到的吗？我想不到别的了。我知道有很多东西，但就是想不起来有什么特别大或令人兴奋的。

Carlisia Thompson: 是的，很多（笑）。我这周停下来读了几篇通讯，发现有那么多东西让我惊讶。

Brian Ketelsen: 我看到 Vim-go Debug 发布了。我不记得是谁做的；我敢肯定在 GoTime 的 Slack 频道里，有人在我说完这句话之前就已经贴了链接……我还看了一个很棒的视频……

Erik St. Martin: 是 Jodosha……

Brian Ketelsen: Joe 谁？

Erik St. Martin: Dosha？Jodosha。我其实有个标签页开着。

Brian Ketelsen: 哦，很棒。

Erik St. Martin: 但我还没仔细看。

Brian Ketelsen: 看起来是个不错的 Vim 和 Delve 的集成工具。很有意思，因为今天早上我们在 Go 的 Slack 频道里讨论了这个……不对，是昨晚在 Twitter 上。我经常搞混这些社交平台，不过确实是昨晚在 Twitter 上。有人在问……他们对调试器的使用感到非常沮丧，我就说：“为什么？你不需要调试器也可以成为一名程序员。”这对那个人来说简直是颠覆性的。“我不需要调试器？我可以不用调试器就成为一个成功的程序员？”

我记得 Ruby 把我从调试器的依赖中解放出来了。在 .NET 和 Visual Basic 的世界里，我被 Visual Studio 宠坏了。转到 Ruby 的时候，我确实感受到了没有调试器的痛苦，但到 Go 的时候，我已经习惯了。我的意志已经被磨平，精神也已经麻木了，我不再需要调试器了（笑）。

Joe Doliner: 是的，我写 Go 的时候完全不用调试器。以前写 C++ 时倒是经常用，但 Go 让我摆脱了这个习惯。

Erik St. Martin: 是啊……现在我除了硬件项目外，基本不写 C 或 C++ 了---在硬件项目里，我还是会用调试器，主要是因为那种项目很难测试。它跑在你旁边的微控制器上，没法直接用 printf 来调试（笑）。所以你只能用调试器一步步排查。

Brian Ketelsen: 如果值是 2，就闪烁三次。

Erik St. Martin: 这其实就是一种 print 的等价物，用 LED 灯，把它们点亮、闪烁，就像串行连接一样。

Brian Ketelsen: 每个人都需要一个串行输出，对吧。

Erik St. Martin: 然后那些开发者没有关掉它们，你就赢了（笑）。

Brian Ketelsen: 很棒。我们应该转向 \#FreeSoftwareFriday 环节了，因为我们已经偏离有趣的 Go 新闻和项目，开始聊些稀奇古怪的话题了。

Erik St. Martin: 如果你还没看过，Francesc 做了一个关于 Go 现状的视频，讲的是 1.8 的一些内容。我们会把链接放到频道和节目的附注里。如果你感兴趣的话，值得一看。接下来可以转到 \#FreeSoftwareFriday 了，怎么样？

Brian Ketelsen: 太棒了。如果你还没听说过 \#FreeSoftwareFriday，这是我们节目中最喜欢的部分。我们会向那些让我们感到快乐、让我们的生活更轻松的开源项目致敬，不管是用 Go 写的还是其他语言写的。因为写开源项目和维护项目通常是一份吃力不讨好的工作，而我们想通过这个环节让那些开源维护者记住我们有多么感激他们的项目，他们为我们构建的工具是多么令人热爱，我们有多么欣赏他们的付出。

今天我想从 NATS 说起，它是 APCERA 和 Derek Collison 的作品。我今天早上用 NATS 解决了一个非常复杂的问题，解决之前我还以为根本搞不定。结果不到一个小时就解决了，而之前我花了好几个小时试图找到别的解决方案。能发现 NATS 这么好的工具真是太高兴了。它的解决方案非常优雅，他们也是我们社区的重要成员，我对此非常感激。

Erik St. Martin: 你呢，Carlisia？

Carlisia Thompson: 我想向 HashiCorp 致敬，特别是 Vault。我最近在用 Vault，四处查阅资料，看到大家对它的评价，真是令人惊叹。这些产品做得太棒了。开源世界里有很多优秀的产品，但这次，我要特别向 HashiCorp 致敬。

Brian Ketelsen: 很棒。我喜欢 Vault。

Erik St. Martin: 是的，Vault 在管理密钥、机密信息以及密钥轮换方面非常出色。HashiCorp 的开源项目不仅功能强大，而且文档质量非常高，是我见过最好的之一。

Brian Ketelsen: Erik，你之前写过的那个项目叫什么来着，是叫 SuperDog 吗？

Erik St. Martin: 我不知道是谁取的这个名字，但对，我为我们曾经工作过的一家大数据公司写了这个项目，因为我们需要轮换加密密钥，所以我基于 Vault 写了个工具。

Brian Ketelsen: 如果你去访问 github.com/xordataexchange/superdog，你会发现我把它命名为 SuperDog，因为里面有加密（Crypto）的功能，而这总让我想起我儿子小时候最喜欢的卡通片《Crypto The Superdog》（超级狗 Crypto）。

Erik St. Martin: 现在听起来确实更有道理了。

Brian Ketelsen: 看吧，现在就有逻辑了。它是一个基于 Vault 的包装工具，可以让你轻松实现密钥轮换，同时在开发环境中可以不使用加密，但在生产环境中默认使用非常强的加密。Erik 为我们写的这个工具非常棒，而且它是开源的。

Erik St. Martin: 如果你听过我们之前的节目，你可能会记得我说过，我通常不会发布自己的项目，有时候 Brian 会直接把我的代码发布出去……[笑声] 这就是一个典型的例子。我当时说：“还没准备好，还没准备好！我对这个东西还不确定……”结果他直接说：“代码已经在 GitHub 上了，我正在写博客介绍它。”

Brian Ketelsen: 抱歉……[笑声]

Erik St. Martin: Joe，你有没有什么项目或者维护者想要特别致敬的？

Joe Doliner: 有的。我想向 gRPC 致敬，这是我们在 Pachyderm 中使用的工具，现在很多 Go 项目也在用它。我觉得 gRPC 是那种默默无闻的英雄，它们帮助我们管理各种 API，但终端用户几乎看不到它的存在……所以我想特别向这些开发者致敬。我也不太确定具体该向哪位维护者致敬，因为它分布在很多不同的代码库里，但总体来看，它应该是 Google 的项目。我真的很希望 Google 开放他们内部代码的这种趋势能持续下去，因为我从中受益良多，我相信其他人也一样。

Erik St. Martin: 我也不太清楚现在是谁在维护它……它确实是 Google 开发的，但我觉得现在有一些其他公司也参与其中了……我需要查一下。不过，gRPC 是 Brian 和我在很早之前就开始关注的东西，甚至可能早到我们不该在生产环境中使用它的时候。gRPC 确实很棒。

Brian Ketelsen: 确实如此，真的很棒。

Erik St. Martin: 我们之前做的一个项目中尝试自己写了一个 RPC 层，但如果当时有 gRPC，那就太好了。在跨语言的 RPC 层中遇到的一些问题，现在都可以通过 gRPC 优雅地解决。如果你只是在 Go 中做 RPC 调用，那使用标准库中的 Gob 就很容易，但在不同技术栈之间的通信中---gRPC 真是太棒了。

Brian Ketelsen: Erik 提到的 SkyNet 是我们第一个大型 Go 项目。唯一还活下来的东西就是 SkyDNS，它现在是 Kubernetes 的 DNS 系统……至少它还存活了下来，其他部分早就被淘汰了。

Erik St. Martin: 为我们辩护一下，当时并没有 Docker，也没有 Kubernetes，更没有 Mesos……这些东西当时都不存在。

我今天的 \#FreeSoftwareFriday 推荐---我既不承认也不否认我需要用到这个工具，但假设你需要破解密码或哈希值，有一个叫 Hashcat 的项目非常棒。它可以用你的 CPU，也可以用 GPU……如果你有 FPGA 或协处理器，它也支持……而且速度快得离谱，特别是对低碰撞率的哈希值，比如 MD4 和 MD5，如果你有一块好显卡，可以在几分之一秒内完成。假设如此。

Brian Ketelsen: 昨天 Erik 和我因为破解密码而进行了一场显卡大战，看看谁的显卡更快……非常有趣。不过我们可能不该承认这件事，对吧？[笑声] Adam，把这段删掉。这没发生过，什么都没看到，继续往前看……

Erik St. Martin: 所以，有没有其他项目或者维护者是大家想致敬的？没有的话我们就结束今天的节目吧？我把大家的沉默当作没有了。

非常感谢大家参与节目，尤其是感谢 Joe 来到我们的节目中，和我们聊了聊 Pachyderm。这真是一个非常棒的项目，我鼓励所有还没尝试过的听众去试着部署一些实例，因为我们都爱大数据。尤其是能说“大数据”这个词---大数据云端化。

Brian Ketelsen: [笑声] 这是一个数据湖。你得下去游泳，兄弟！

Joe Doliner: 我最近了解到一个关于“大数据”这个词的小趣事---我为一个叫 LeBigData 的法国博客做了采访……“大数据”这个词在法语中被逐字翻译了；这就是法语中的官方术语。我觉得 LeBigData 这个名字特别搞笑。

Brian Ketelsen: 这可一点也不像法国的风格……他们对自己的语言保护得那么严格，讨厌英语词汇进入法语体系……他们甚至有一个机构专门保护法语免受英语影响。他们不想让任何英语词汇进入法语。

Joe Doliner: 他们明明有“大”和“数据”的法语单词……我学过一点法语，我知道他们有这些词。他们有替代词，只是这些互联网上的年轻人不尊重语言保护协会的规则吧。

Brian Ketelsen: 真是太糟糕了……

Erik St. Martin: 非常感谢所有听众的支持，特别感谢今天的赞助商 Toptal 和 Backtrace。请多多支持他们，因为他们也在支持我们。如果你喜欢这期节目，请和你的朋友和同事分享。大家可以通过 GoTime.fm 订阅我们。在 Twitter 上我们是 @GoTimeFM，GopherSlack 里也有 GoTimeFM 频道。如果你想参与节目或者有主题建议，可以去 github.com/gotimefm/ping 提交。好了，再见，大家！

Brian Ketelsen: Erik，在节目结束前我们还有一个重要的声明……GoTime FM 及其制作人、成员和工作人员不对因使用 Pachyderm 而引发的数据湖淹没你家的情况负责，所以请谨慎使用 Pachyderm。 [笑声]

Joe Doliner: 如果你的数据湖淹了家，来我们的 Slack 用户频道，我们会帮你解决问题。这种事以前发生过。我们就是干这个的，我们是专业的。

Erik St. Martin: [听不清 01:03:07.21] 没发生过。[笑声] 我在等着……这期节目将在大约一周后发布，不过我非常期待会有相关的表情包和动图出来……比如从数据湖里被救出来的场景。

Brian Ketelsen: 我觉得你高估了我们的社交影响力。

Erik St. Martin: 不，我现在把它当作一个挑战。

Joe Doliner: 这才是衡量一集节目好坏的真正标准……Carlisia，请说。

Carlisia Thompson: 我只是想提醒一下，我们还没正式说再见呢。

Brian Ketelsen: 哦，那我们应该正式说再见了。

Erik St. Martin: 我刚才已经说过了，是你们没回应。[笑声]

Brian Ketelsen: 好吧，谢谢你来参加节目，Joe。

Joe Doliner: 谢谢邀请，我玩得很开心。再见，各位听众……这次体验真是太棒了。

Carlisia Thompson: 谢谢你，J.D.。再见，大家。

Erik St. Martin: 再见，大家！