• The Best Setup, in A Nutshell
• Why Use Both System Python and Pyenv Python?
• pipx
• PDM
• Caveats
• Summary

This blogpost describes the Python development setup that makes the most sense to me (and probably you as well) in 2022 and beyond. By "Development Setup", I mean the local development environment, and not about deploying apps on a server.

The Best Setup, in A Nutshell

• For executables/utility tools (e.g. mypy, black), install with system Python + pipx
• For project development, install different Python versions via pyenv
• For dependency management, use PDM (PDM is installed via pipx)

I'll explain each choice in more details below.

Why Use Both System Python and Pyenv Python?

One unusual thing you probably have noticed is that the setup consists of two ways to install Python: the system Python and Python installed by pyenv. Here, by "system Python", I mean the Python carried with your system, or the Python installed with a system package manager (e.g. apt, brew). Many articles suggested that we should never using system Python, so why still use it? Because we need two independent systems for two different purposes:

• For utility tools, reliability matters the most. You want them to always work when you need them. The less things they depend on, the better. System Python is the best choice, because they have the least dependencies. Also, for utility tools, It doesn't really matter which Python it is running on. Therefore even if system Python is behind the latest version, it is usually fine.
• For Python interpreters used by projects, flexibility is more important. You may need to upgrade them when a patch version fixed a bug, or using a specific Python version because that's what you have on the server. pyenv fits this purpose well.

pipx

pipx needs no introduction, it has become the de-facto way to install Python executables. But imagine if you install pipx with pyenv-installed Python. This creates a dependency like this:

mypy --> pipx --> 3.9.7 (pyenv) --> pyenv --> system Python

As you can see, the 3.9.7 (pyenv) --> pyenv part is unnecessary. It also creates trouble when upgrading Python: you either have to reinstall pipx, or keep Python 3.9.7 forever since pipx and all the tools above relies on it.

PDM

Now comes to the controversial part: PDM. Disclaimer: PDM is my personal choice, and it's totally ok if you chose Poetry, Pipenv, or any other tools. Here are the reasons why I use PDM:

⚠️⚠️ UPDATE 2023.5: I should clarify that, PEP 582 is good for developing libraries; for applications, PDM's virtualenv mode should still be preferred.

• PDM helped me get away from virtual environments
  I used to have 10+ virtual environments, and I get a headache every time I saw the long list. It essentially makes it impossible to ever upgrade my project Python, because I really don't want to setup virtual environments again for every project.

  With PDM, I have no virtual environments. Each project directly depends on the pyenv-installed Python. I'm also free to upgrade patch versions (e.g. from 3.9.7 to 3.9.9), which allow me to always use the latest Python release.

  See also You don't really need a virtualenv.

• PDM is well maintained
  PDM is created and maintained by PyPA member Frost Ming. If you don't know what PyPA members do, let's just say they know the best about Python packaging. Frost Ming also maintains Pipenv.

  I used to use Poetry, which is also a nice tool. But sometimes Poetry is buggy, especially when upgrading project Python. What's worse is that no one seems to be dealing with those bugs (example). PDM is the opposite. Issues are usually responded within a day or two, including feature requests.

  Benefit from being maintained by a PyPA member, PDM is usually the fastest in adopting new proposals in the Python packaging world, which lets its users stay on high productivity.

Overall, I find PDM better than other tools I've used, and it's constantly getting better (5~6 releases per month). I tweeted about my transition from Poetry to PDM, might be interesting to read.

Caveats

You may still need to install a new system Python when the old version gets deprecated. You can use pipx reinstall-all to reinstall existing tools, which is not so bad.

The setup may or may not work on Windows. If you can confirm which case it is, and/or if there's any issues, let me know, I'm happy to put them in the article.

Summary

In the past few years, Python gained a lot of great improvements in the development/packaging ecosystem, but this also created a mess that even the most experienced developers had a hard time picking tools. Luckily, I've found the silver bullet that works for me, and I hope it would also work for you.

• 项目的坑
  • 当需求不是直接来源于用户时一定要谨慎
  • 内部 2c 项目（大概率）好于 2b 项目
  • 警惕那些依赖其它组的项目
  • 了解组里其它人在做什么
  • 不要对项目产生感情
• 老板的坑
  • 不要盲目相信老板
  • 警惕只想把你当工具人的老板
• 组的坑
  • 业务/技术/个人兴趣，至少要占一项
  • Fake infra 和 True infra
  • 不要去 scope 太小和前景莫测的组
• 换组心得
  • 关注具体的工作内容和大方向
  • Impact 是否好兑现
  • 和工程师聊天
  • 什么时候该考虑转组？
• 总结

正如大家所知，我最近换了一个组。回顾过去几年，被坑的时候实在不少。从中我意识到了一些事情，故用这篇文章记录一下，也算再给自己的想法做个 snapshot。文章的三部分别讲项目、老板以及组的坑。最后再聊聊换组。

这里的“坑”不单指外界的坑，也包括自己犯过的错误。本文的适用范围还请读者自行判断，毕竟大到公司，小到组和部门，它们的差别都极大。你觉得和你遇到的情况不符，请不要杠，这没意义。虽然这么说，我觉得大部分内容还是通用的。另，有些英文说法没有翻译，但都不难理解。

项目的坑

当需求不是直接来源于用户时一定要谨慎

我转组的原因之一是 2020 年做的大项目失败了。项目实现了规划的功能，架构也清晰合理，但没有达到预期的 impact，而我原本是指望用它来到 L5 的。为什么会这样呢？归根到底，这个项目并非来源于客户的直接需求，而是老板拍脑袋想出来的。我的（前）老板某一次和其它几个老板聊天，发现其它组都有一个工具。他觉得这玩意我们大部门也挺需要的，那就找人做吧。不是说它完全没用，毕竟我们最终还是找到了两个客户，但我们很想推的组没推动，并且未来大概也不会有更多用户。后来我才知道老板先问了我的 TL (Tech Lead)，TL 没有接，然后才找的我。TL 依靠丰富的经验避开了这个坑，但我就没那么好运气了。结论：需求不是直接来源于用户是一个巨大的危险信号。

内部 2c 项目（大概率）好于 2b 项目

这里仅讨论内部工具项目，不适用于面向外部用户的产品。几年下来我有一个很直接的观察，成功的内部工具基本都是 2c，很少有 2b 的。可能有人会好奇，内部工具也有 2b2c 之说吗？有个很简单判断方法：一个工具或系统，如果工程师能自己用起来，那就是 2c；如果需要部门里 >1 人讨论并决定，那就是 2b。举两个例子：一个开箱即用的任务监控面板是 2c 的，而一个需要修改 release 流程才能使用的工具就是 2b 的。当然，我观察到的样本很少，所以结论未必对。但我真心感觉 2b 的东西想推动，要花费几倍于 2c 工具的时间，效果还未必好。总之如果你有的选，请尽量把时间花在 2c 项目上。

警惕那些依赖其它组的项目

OKOK 我明白，世界上就没几个不需要跨部门合作的项目。但合作方式也是多种多样的。假如对方是你的客户，你需要和他们沟通来实现一个需求，又或者大家同属一个大组做同一个产品，这种就没问题。而当对方在你的关键路径上——比如你想做的东西没有对方配合就完不成，且你们又是跨部门，这种就有很大风险。如果你正在参与此类项目，请一定确保：

• 双方（或多方）要 aligned（阿里话的“对齐”），尤其是老板之间。包括对项目的预期、优先级、工期、资源投入，都必须互相知晓并认可，而且要落实到 OKR 层面。不要相信工程师的口头承诺，我被坑过，而且很惨。
• 要有定期例会。
• Escalate（上升）的渠道一定要通畅。当对方没有按期交付或出现各种问题时，你要能通过自己老板向对方施压。这也是为什么双方老板的支持是必需的。

了解组里其它人在做什么

除了上面提到的那个项目，其实我曾有更好的机会升 5。我们组有个项目，本来由两个人分别负责前后端，结果后端哥们儿写一半离职了。后端是用 C++ 实现的，而我当时是组里唯一有 C++ readability 的人，如果申请接手，老板 100% 会同意。然而我当时埋头于自己的任务，完全不关注组里其它人在做什么（即使我一直帮他们 review 代码）。因为不了解，也没有意识到这个项目的潜力。后来这个项目交由前端哥们儿负责，并且成了组里的重点项目。我就这么错失了好机会。说白了这又是“选择大于努力”的例证。

于是我决定，进新组之后至少和每个人 1:1 一次，即使他们的工作看起来和你毫无关联。同时关注各种新提案和设计文档，了解其它人在做什么。除了寻找可能的机会，这也有助于站在更高视角全面理解当前的工作。

不要对项目产生感情

我当初之所以选择换到现在的组，主要是因为（前）老板答应我可以继续之前的工作——一个我很喜欢并认为有很大潜力的项目。时至今日，这个项目完全兑现了潜力，然而我却因此耽误了两年。如果当时抛弃对项目的感情，我完全可以找个更合适的组。转组的事之后会细聊。

老板的坑

之前和 Phil 做过一期节目聊了这个话题，不过我们遇到的情况不尽相同，感兴趣的可以去听一下。我只说我遇到的情况。

不要盲目相信老板

我的三任老板都有过很离谱的判断：

• 第一任老板认为写什么语言都不影响换组（我一开始写 Dart。。。）。然而事实就是换组非常看背景。很多组明面上说可以进去再学，实际上都希望申请者会写特定的语言（等着进去再学的人根本拿不到面试：）。
• 第二任老板极度厌恶 C++ 并热爱 Java。他要求我把一个 C++ 服务用 Java 重写。这明显是个费力不讨好的活，但又不能不干，于是我和老板说服了另一个人去写。结果如我所料，他花了时间却没拿到任何 impact（真对不起他）。
• 现任老板比较短视。他上任后大刀阔斧地砍项目（交给别的组维护），理由是我们要 focus 在几个重点项目上。很多成功或有潜力的项目都上了被砍名单。问题是 EngProd 组的活本来就少，被这么一砍，不少人拿不到足够有 impact 的项目，只能做些小 feature。去年离职了好几个，今年目测还要跑一波。

所以我认为，老板的话要听，但决策一定要自己做（或者说，做自己认可的决策）。这里面有个更本质的原因。自己做决策，即使错了，也可以复盘反思，并取得进步。而让他人做决定，自己将很难进步——对不知道对在哪，错也不知道错在哪。

警惕只想把你当工具人的老板

我换组的另一个原因是发现老板有把我当工具人的倾向。在 Google，好的老板要能平衡组与组员的利益，既保证组的发展，又确保个人能够成长（说白了就是晋升）。前两任老板虽说都给过我坑项目，但至少他们会和你聊个人发展并给出建议。这些我都看在眼里。现老板去年还是工程师，在前老板走后被提拔上来。一开始的感觉是他不太关注我的项目，即不了解也不想去了解。今年 Q1 快结束时，事情开始变糟。如之前所说，老板开始砍项目，并把我调往那个我曾经错过的项目。本以为老板打算让我从现在开始 own 它，然而并不是。老板的意思是让我 Q2 去实现一个比较重要的功能，后续安排再议。从我知道的情况看，这个项目中很有 impact 的一块已经被分给了一个即将到来的 intern——是的你没听错，intern。我问老板：明明这个 feature L3 工程师就能做（简单的 CRUD），并且对他们晋升帮助很大，为什么让我来？老板说你擅长这块，你来做比较快。话说到这份上，继续聊下去已经没太大意义了。

怎么判断老板有没有把你当工具人？我觉得有这么两点：

• 看老板给不给你做职业规划。好的老板会说：我觉得你想晋升，impact/difficulty/leadership 还不够，做XXX任务可能对你有帮助，或者我们一起想想能做什么。把你当工具人的老板不会给你规划。

• 看老板对你是否诚实。我曾对现老板说：仅仅加这个功能基本上就是 L3 的活，感觉对我晋升没有帮助。老板说不要紧，只要你做得快，拿 SEE（类比 3.75）是没问题的。在我看来这就是典型的不诚实，或者职场 PUA 话术。你再资深，该花的时间还是得花，收集需求、设计、实现、测试，这其中有的时间是你无法控制的。资深工程师无非是做出来的东西稳定一些，考虑更周全，bug 更少，并不是一定就能做得更快——因为最快的方法永远是糙快猛。

  如果是前老板，我觉得他会说：“虽然没法让你到 5，但我们有客户急需这个功能。我们可以规划一下之后的安排，比如让你顺势 own 这个项目，或者找一个更好的项目”。诚实是最重要的。不要骗我们，我们不傻。

当然，现老板也和我聊过晋升。他说如果我想晋升就得自己想一个好项目。于是我想了一个 impact 很大的，写了提案给相关组审阅，他们很满意。然后老板说我们不做这个，要 focus。我：？？？

组的坑

组的坑既是最好聊的又是最不好聊的。相对来说，组的坑比较明确，容易提前识别。但另一方面，组的坑多种多样，且和老板和项目都有关联，难以穷尽。所以这里只说说我知道的那些。

业务/技术/个人兴趣，至少要占一项

有的组业务有前途，有的组技术有挑战，有的组两边都有，有的组两边都没有。两边都没有的基本就是坑，这种组在大公司相当多，比如 Google 的 EngProd。当然，如果某个组做的东西就是你的兴趣所在，那就加入吧，这时候别的都没那么重要了。

Fake infra 和 True infra

EngProd 具体怎么坑，我以后或许会专门写篇文章讲，但最根本的一点在于他们负责的是 fake infra。EngProd 全称 Engineering Productivity（研发效能），现在的 title 虽然是 Software Engineer，但在 2019 年以前是 SETI（software engineer, tools and infrastructure）。有人一看到 "infrastructure" 这个词就被唬住了，以为做的是什么不得了的东西。然而 EngProd 虽不负责业务，做的东西却也跟 infra 不沾边，我称之为 "fake infra"。比如修改一下公司的集成测试框架给某个组用，帮某个组优化 presubmit/postsubmit time，减少 test flakiness，诸如此类的杂活是 EngProd 传统艺能。我理解公司设立这个职位的初衷就是把杂活分出去，让 SWE 们专注于开发。

True infra 和 fake infra 的区别是什么呢？我觉得 true infra 一定是有技术挑战的，且至少要服务于某个大部门（比如 Search/Ads/Cloud），而不是一个或几个组。那些大家耳熟能详的技术都是 true infra，比如 Spanner，F1，Flume，Bigtable 等。有意思的是，做 true infra 的组从来就不属于 EngProd，而 EngProd 也从来不负责 true infra。

不要去 scope 太小和前景莫测的组

记得第一任老板总是强调要了解 big picture，当时不懂，现在才发现说得真对。Scope 指一个组负责的工作或者产品有多大。比如前面说到的 true infra，他们的 scope 就是全公司，而 EngProd 组的 scope 则通常是一个部门（几十到一百人）。面向用户的产品更复杂一些。比如 Gmail 和 YouTube 虽然有几十亿人用，但某个组负责的小功能却未必。这时候你只能依靠经验去判断。很多时候我们看不清，这不要紧，但至少有一些坑是可以避开的，比如 messaging app。

我第一次换组的时候也犯过错误，为了能去搞 AR 花了很多时间学图形学，导致没怎么认真看其它组。现在想起来觉得自己真蠢：在 Google 做 AR 没前途不是明摆着的么？到今天为止都没有一款面向消费者的成功 AR 产品，更不要说在这方面投入不多的 Google 了。而且说白了我也不是真的有兴趣，只是觉得这个技术很酷而已。当时犯的错误，现在要用几倍时间来还。

换组心得

下面来聊聊换组。虽然和上一节相关，我还是决定单独拿出来说。很多公司不像 Google 有这么多换组机会，还可能面临老板不放人的情况。因此我不打算写换组的流程，而是把重点放到“选组”上，尽可能让内容通用一些。

关注具体的工作内容和大方向

只看产品选组还不够，具体的工作内容和大方向也很重要。比如一个明星产品组招人可能是为了是搞测试，而一个内容平台的年度 OKR 可能是加强审查。要了解一个组的方向，最简单的方法是去看它的年度 OKR。如果找不到，一定要和老板问清楚。

我遇到过这么一个组，他们有 hc 所以打算先招几个人，至于做什么等进去再分配。这也是一个危险信号。通常来说，一个职位的职责越明确，项目的风险和掉坑的概率就越小，也能让你做出更有根据的选择。

Impact 是否好兑现

我实在不知道 impact 怎么翻译比较好，“影响力”这个说法其实不准确，所以我就不翻了。Impact 是否好兑现，我们可以通过举例说明（注意，好兑现和“大小”是两码事）：

• 好兑现的：
  • 实现一个面向用户的新功能
  • 依赖的 API 要 deprecate 了，使用新 API 重构系统
  • 优化响应时间
  • 给覆盖率很低的项目写单元测试
• 不好兑现的：
  • 做一套测试框架
  • 重构系统，但是功能不变
  • 优化调试或监控工具

好兑现的项目简单明了，只要做完了 impact 就实打实地在那，不需要费劲给人解释。不好兑现的则各有各的问题：

• 做测试框架：做了并不代表有人用，没人用那 impact 就是 0。你得花心思推广。
• 重构系统：你觉得老代码写得太烂了难以维护，所以要重构。问题在于证据呢？这时候你就必须得收集数据，比如证明在老代码下加一个功能平均需要三天，而重构以后只需要一天——假设你能拿到这么理想的数据。实际情况往往是拿不到，或者并没有显著差异。
• 优化调试或监控工具：这里的困难还是在收集数据，你怎么证明改进后比改进前要好？并不是说证明不了，而是需要花心思。

优先选择 impact 好兑现的组。一般来说，做新东西比较好兑现。

和工程师聊天

和老板聊天往往容易浮于表面，或者大饼满天飞。找到组里的工程师，一般他们都会毫无保留地告诉你真实信息。我会问很多尖锐的问题，比如“你觉得组里有哪些缺点”，“晋升速度如何”等，还会详细了解工作的细节。有个工程师直接告诉我，如果你想晋升，就不要来我们组——老板们断然是不会这么说的。如果你觉得在职员工讲话会有顾虑，也可以找刚转出去的员工。实际聊下来我没发现有太大差别，只要是工程师都会如实说明情况。

什么时候该考虑转组？

这个问题没有标准答案。我现在倾向于认为只要满足条件（Google 的要求是待满一年），就可以开始关注新机会了。我们有个系统可以设置 filter，出现满足条件的内部转岗机会会自动给你发邮件。每周看一次邮件其实花不了几分钟，而且看机会并不意味着一定就要走。别看每天都有很多组在招人，实际上单看某一个组，招人的窗口都只占一年中的很小一段，甚至有的组几年都不招。很多机会错过就是错过了。

有种情况我会建议你立马开始看机会：人事变动。不论是老板离职还是组织架构调整，只要是人事变动，多多少少一定会影响工作。影响可能好可能坏，可能多可能少，你无法预测，所以最好未雨绸缪。尤其如果老板给你提供了很多支持，甚至本身就是项目的发起者，当他离职之后你的工作必然受到冲击。事情变坏往往就是一瞬间的事，如果没有准备可能会措手不及。当然这里还是要强调，看机会不等于一定要换组，只是给自己准备一条后路。如果一切照常甚至变好，那完全没有换组的必要。

总结

相信你现在也感受到了我这几年是怎么被坑过来的。我当然希望一切都一帆风顺，但既然事情已经发生，也必须总结一下引以为戒。祝大家职场之路顺利。

• 申请
• 会前准备
• Day 1
• Day 2
• Day 3

关于这篇文章到底用中文还是英文写，其实我犹豫了一会，但最终还是决定用中文，毕竟也没人会写一篇关于 PyCascades 的中文文章了。

首先，PyCascades 是什么？用官网的话说：

PyCascades is a regional PyCon in the Pacific Northwest, celebrating the west coast Python developer and user community. Our organizing team includes members of the Vancouver, Seattle, and Portland Python user groups.

简单来说 PyCascades 就是一个区域性的 PyCon。但由于许多 Python 大佬聚居于此，其影响力比其它区域性 PyCon 大很多。

我在 PyCascades 2021 给了一个演讲 “Let’s Rethink Debugging”：

下面就聊聊我从申请到参加 PyCascades 的经历。

申请

去年（2020）十月，PyCascades 官推宣布了 2021 年会议将在线上举办。当时 Cyberbrain 的第一个小版本已经接近完成，我正想找个地方宣传，于是就锁定了 PyCascades。彼时我只知道 PyCascades 有着不错的影响力，而对整个申请流程毫无概念。然后就发现想要演讲，得先提交一个 proposal。和 PyCon China 不同，PyCascades 有着严格的筛选机制。你得提交一个描述演讲内容的 proposal 给组委会审核，择优录取，所以并非报名了就能去讲。根据这份 slide 里提到的数据，PyCascades 2018 和 2019 年的演讲接收率（acceptance rate）都不超过 10%，可见筛选之严苛。

我从来没写过 proposal，完全不知道要怎么下手。好在官方提供了一些参考资料，我就把它们看了一遍。其中值得一提的是这个 repo，里面收集了过往被接受和拒绝的一些 PyCon proposals，很有参考价值。由于 19 年在 PyCon China 讲过，演讲的前半部分我基本直接照搬，力气主要花在写后半部分 Cyberbrain 的原理介绍和展望。10 月下旬，我花四个晚上完成了 proposal 的初稿，接着就开始找人审阅。

找谁呢？我想起之前看过的那些资料。既然作者有心教人写 proposal，那么应该也会愿意帮忙审阅吧。于是我就给两位作者同时也是圈内大佬 Allison Kaptur 和 Brandon Rhodes 发了邮件。说来也巧，我在调研 Cyberbrain 时仔细阅读了 Allison 写的那篇 A Python Interpreter Written in Python，实现过程中也一直在参考文中提到的 byterun 项目，可以说渊源颇深。邮件发出后好多天也不见回信。我不想傻等，于是就推特私信了 PyCascades 的组织者 Nina。Nina 在一直是 Python 圈的活跃分子，以前也做过关于 debugging 的演讲，我觉得找她还挺合适的。很快有了回信：

This year I'm co-organized for PyCascades, so I currently have my hands full. Fortunately we have a team of volunteers that are providing speaker mentorship for the conference.

Would it be OK if I introduced you to one of our speaker mentors? If yes, just let me know which e-mail address is best for you.

我惊了，原来还有志愿者吗？那还用说，当然是赶快给我安排一个。于是，同为 Googler 的 Chris Wilcox 就成了我的 mentor。几乎是同时，Allison 和 Brandon 也回信了。于是接下来直到提交截止日期我几乎一直在改 proposal，成品就是上一篇文章中的那样。以后有空我可以专门聊聊怎么写 proposal，今天先略过了。

会前准备

Proposal 幸运地被接收了。感情上，我终于放下心来，然而理智上我从来就不觉得会被据——要是这都被拒了，被接收的那些不得上天？毕竟我也不是没看往届演讲。

于是就开始写 slide。我报名的是 recorded talk，也就是要提前录好。二月份提交才截止，理论上不用着急，但我想先试讲一次。我迅速搞定 slide，并联系了本地 Python meetup 的组织者，在 1 月 5 号晚上做了一次远程演讲。虽说只有二十多人参加，但反响还不错，这让我基本确信了这会是一个好的演讲。

到这步还不能直接录制，组委会要审核 slide 是否符合 Code of Conduct，并做一个 tech check。Tech check 委托了 Next Day Video（一个专业做会议视频的公司）进行，目的是为了确保讲师能够录制出效果足够好的视频。我先通过他们的系统预约，然后顺利进行并通过了 tech check。过程中，Next Day Video 的人还教了我怎么正确使用麦克风——原来我之前一直都摆错了方向导致无法获得最佳音效。果然这就是专业人士吗🤯。然后就是一些邮件+notion文档(1, 2, 3)，里面说明了参会和录制的各种要求，详细到视频的 bit rate 和 frame rate 都有规定。里面还推荐了一些录制用的软件。我最后采用的是 Apowersoft Free Online Screen Recorder。CoC review 通过之后，终于可以录制了。

算上 PyCon China 2020 的闪电演讲，这还只是我第二次录视频。我发现，录视频比现场演讲累太多了。可能有人会觉得，现场演讲多紧张啊要面对那么多观众，提前录的话讲坏了大不了重录或者剪辑嘛。但这也正是录视频累人的地方

• 没有现场观众，你无法得到肾上腺素或者其它什么激素的刺激，而这些刺激能极大缓解疲劳。
• 你不太会在意现场演讲中的口误、结巴等不完美的地方，因为你在面对别人讲话，而讲话时自然不会在意这些。
• 提前录制则不同，首先你是自说自话，会对各种错误非常敏感。其次你有重录的机会，导致容易吹毛求疵。

反正我第一次试着完整录，25 分钟，讲完就不行了。那天剩下的时间我几乎没办法干任何事，感觉整个人都被榨干了。自然效果也非常差，后半段可以明显感觉到讲师很疲惫。于是接下来的几天继续录，不算中途就抛弃掉的，大概第三遍的时候我觉得差不多了。我把视频传给了 Next Day Video，几天之后被告知没有问题。接下来就一身轻松等待会议开幕了。

Day 1

主办方在周五安排了一个线上的 social 活动，使用的平台是 SptialChat。这个产品还挺有意思的。进去之后有一个类似剧场的空间，你可以在空间中拖动自己的头像，模拟在物理空间中走动的感觉。当你把头像移到一群人旁边就可以听到他们讲话，并且距离越近听得越清晰。一开始我只是听，后来 Anthony Shaw 过来和我打招呼，我也就顺势混入那一群人瞎聊起来。我说我感觉录视频好累，Anthony 和另一个讲师说他们也发现录视频会让自己要求变高，到最后受不了只能把讲稿完全写下来。

主办方还找了个 DJ 在台上打碟。打碟的大叔全程也不和人交流，感觉很沉醉其中。

Day 2

周六是正式会议，九点半开场。然而我七点就起床看了场球，还输了。郁闷了一阵想起来还要开会，点进去发现 Guido、Brett 等几位大佬已经开始聊天了。随后一直听，并反复在 recorded talk 和 live talk 之间切换，因为 PyCascades 的两个 track 是同时进行的。值得一看的演讲是 Your Name Is Invalid!，大概就是讲处理各种语言文本时各种可能出的问题，比如有的语言中大小写字母不是一一对应的。最后的结论是 "Don't assume anything"。这让我想起以前看过的讲时区处理的视频，想用代码囊括复杂多样的世界，何其难也。

会议之前若干周，主办方在 Slack 上开了几个私密频道给讲师，当作后台使用。会议当天，Next Day Video 的人会在后台联系讲师做 tech check——是的，为了确保万无一失，当天还有 tech check。我的演讲在下午 1:55，大概 1 点做 tech check。工作人员说声音没问题，但让我把后面的百叶窗拉上一点不让太亮了，并且还问能不能把摄像头放低一点。这里要解释一下，我用的是一个台式机连接大显示器，摄像头是放在显示器上面的，这样就造成了一种俯视的感觉。为了解决视角问题，我只能找两个纸巾盒子摞起来，把摄像头放在上面，这样勉强和我的头平齐。我还挺好奇其它人都是怎么做的。

临近演讲时间，我登入 Next Day Video 的讲师专用后台。和主持人对了一次词，包括要怎么称呼和介绍我。这次会议我统一跟人说叫我"laike"了，毕竟称呼不重要。我之前以为开场介绍过后就可以退出，没想到还得一直待在后台。我只能找了一台笔记本打开听自己的演讲。他们强调说视频的播放有一段时间的延迟，但是我听着听着就忘了。临近结尾，我看到 slack 上有消息，是主持人让我马上过来说结束语。也就是说，我需要在视频没结束的时候就去讲，因为有延迟，观众看到的就是视频一结束，我和主持人马上出镜。我手忙脚乱地坐回屏幕前，调整摄像头，讲了一句话才发现自己处于 mute 状态，又赶紧 unmute。这状况频出的直播大概会成为未来的美好回忆吧。

后台状况不提，演讲效果还是不错的。听众不出意外地被 Cyberbrain demo 震住，当然这也在意料之中。我边听边打字回答听众问题，十分愉快。

有一些听众希望在 console 和 notebook 里使用。我只能说，希望未来可以实现吧。最令我高兴的还是看到 Łukasz 说他被 sold 了，虽然他后来也没有去 star 😢

之后就是在 Q & A 房间继续回答问题。有人问这个项目和 Google 有没有关系，我就非常想笑，怎么可能有关系啊。还有人问能否用 Cyberbrain profile 慢代码，我也只能承认不行。不管问题如何，能有机会和听众聊 Cyberbrain 就足够让我开心了。

Day 3

Day 3 是 sprints，我没参加只是去看了一眼，感觉线上做 sprints 还是有点奇怪。以后线下一定要参加一回。

大概就是这样。全程下来要问我哪一点印象最深，不是具体的 talk，也不是自己的第一次英文演讲，而是主办方那惊人的专业性。会前会中已经讲过，但这种专业性甚至延续到了会后。当他们把演讲视频上传到了 YouTube，我发现我在视频里有露脸。别不在意这个，但我并不想。正当我烦恼要怎么联系主办方解释自己的苦衷，甚至已经开始在脑中构思措辞时，我接到了一封邮件。这是一封确认视频有没有问题的邮件。我喜出望外，便在回复里说明了需求。于是他们迅速撤下视频，两天后剪辑完成又重新发布。这种受尊重的感觉实在太好了。我愿称 PyCascades 是我参与过的最专业的技术大会。