307
Node.js Collaboration Summit 与 JSConf EU 纪行
受集团赞助，参加了今年五月在柏林举行的 JSConf EU。另外 Node.js 社区趁着欧洲参会的人多以及考虑到柏林靠近 V8 团队大本营慕尼黑，在 JSConf 前两天在附近举办了一次Node Collaboration Summit和一些别的活动，作为 Node Core 的 collaborator 我也一并参加了，以下是个人的一些总结。
整体感受：阿里与中国开发者在国际社区与标准制定过程的缺席
平行世界
在柏林的几天我和许多认识不认识的人交谈下来，最大的感受就是阿里，或者说中国的开发者在国际社区几乎没有什么存在感。几乎每个和我第一次见面的人在得知我在阿里工作，住在中国的时候，都表示好奇为什么中国的程序员好像活在另一个宇宙里。这里说的中国程序员，特指“土生土长，在中国公司工作的程序员”。从很多人的说法里听下来，我们就像一股神秘的东方力量，虽然人多势众，但是很少出来和国际社区的人交流。比如说，虽然每个人都听说过阿里，但是只在新闻里听说过，见过我们大 boss 的各种采访，只有极少数人见过阿里的程序员，有些人虽然听说过阿里的开源项目，但是点进去一看都在用中文讨论 issue 和写 commit，注释里可能还有很多中文，于是就默默点叉了。大家见过和交谈过的中国程序员绝大部分都是外籍或者在外工作的，所以对在中国公司工作的土生土长中国程序员感到十分好奇。一部分人知道墙的存在还能多少理解一些，其他人都感到十分困惑，对于很多人来说我就是第一个活生生出现在他们面前跟他们说话的“real Chinese” = =。这其中还有不少人是经常到世界各地开会，见多识广的，于是就更加奇怪了。
按照个人的经验，其实在 GitHub 上活跃的中国程序员还是很多的，但是实际参与到大型开源项目的日常维护，经常开 PR 和帮助维护 issue tracker，参加线上下会议的就很少了，只是偶尔出现的话这些项目里的人一般不会在意对方本人是怎样的人，没有交谈过一般也不知道真实姓名和来自什么地方，所以自然也就不知道对方其实是中国程序员了。国内对“自己创建的开源项目”一般更上心，但是据我观察好像这样的自己创建开源项目很少会有国际社区的人参与进来，一个主要的原因是这些项目大部分第一工作语言都是中文，让大部分不会中文的人望而却步，所以最后依然是两个平行世界。作为对比，像 JS 社区里比较知名的 Vue.js 虽然作者是华人，但是不在国内工作，第一工作语言也是英文，最开始也是在国际社区推广成功的，后来也在中文社区做了很多努力，所以算是比较罕见的在两个世界都有存在感的项目。
然而开源社区里，“维护者”总是比“创建者”要多得多，拿我比较熟悉的 Node.js 社区来说，Node.js Core 的大多数维护者都是最近几年才参与到项目里来的，npm 上很多热门模块的维护者也不是作者本人，这些有影响力的项目日常的 issue triage，code review，代码维护，新功能实现，版本发布，技术决策，很多都已经和原作者没什么关系了，社区活动大部分也都是承担日常工作的维护者们在互相沟通，而这样的维护者中确实很少有活跃的中国程序员，也难怪他们会有这样的疑问了。我曾经考虑过语言障碍是不是造成这个现象的一个原因，但实际上我接触过的很多维护者母语都不是英语，即使拿亚洲国家来说，隔壁日本的程序员在国际社区活跃的也不少，而日本程序员的平均英文水平似乎也并没有比中国高特别多，只要不影响理解大家都是可以沟通的。另外还有好几个人跟我提过的一点是，似乎只有中国人会在默认用英语的 issue tracker 上直接用中文开 issue，其他非英语国家的人都不会这样，他们都很好奇为什么，然而其实我也不知道原因……
回来和其他同事讨论这个现象的时候，还想到了一点，就是我们喜欢看自己的某些项目具备了基本的英文文档，或者我们有某几个在国际社区比较活跃的开发者，就以为其他国家的人应该会注意到中国项目和中国开发者的存在，所以会觉得他们说看不到中国人有些奇怪。然而我们的项目仅仅是无数个来自不同国家的项目里的几个项目，我们的开发者也不过是无数个来自不同国家国家开发者里的几个人，每个人的关注范围都是有限的，注意不到这几千几万分之一的来自中国的活动，其实也不是很难理解。换句话说，就是数量虽然不是没有，但是太少了，而且缺乏现象级的活动，因此还不到能让大多数人察觉到的地步。
尬聊
另外据我观察，似乎国内的程序员在被公司派出去参会的时候都不怎么和非华裔的人搭讪，比较喜欢找同样是来自中国的人搭话（我遇到过一些其他中国公司的人，他们似乎都倾向于找亚裔说话，而且发现对方是华人会很快切换到中文），所以造成了即使我们有人出国参会，结果非中国程序员依然不认识中国的程序员的状况……不过根据我在国外留学的朋友的说法，似乎这个情况在留学生里也是很常见的……
P.S. 我第一次出国开会的时候也不会主动找人聊天，不过被几个认识的人带着尬聊和被几个人尬聊之后，就学会套路了，基本就是看到落单的人自己刚好又很闲的话，就凑上去说 Hi I am xxx，对方这个时候会回 Hi I am yyy, 然后两边握手说一下 nice to meet you，接下来就是 where do you come from, where do you work, what do you work on 三件套就可以开始瞎聊了。如果是因为某些因素见过好几次面或者一起参与过几次讨论，但还没有直接说过话的，开头加句 Have I introduced myself to you?或者 I don't think I have introduced myself to you就可以。其实和国内开会搭讪也没什么区别，另外因为我是女的所以和女程序员搭讪有 buff，所以我比较喜欢找女程序员搭讪，开会中途吃饭拼桌的时候也是和旁边的人边吃边聊的好机会。除了这个尬聊的方式以外，在有第三方共同认识的人在场的情况下也可以很快认识人，如果第三个人不主动介绍你们认识，在交谈的间隙说一句I don't think we have met然后报上名字伸手即可，当然最快的就是以前在 github 一起 code review 过的人直接报 github id 就一见如故了……
午餐时间，尬聊的机会
Community Area，尬聊机会x2
JavaScript 标准过程中的缺席
除了在社区活动和开源项目中的缺席以外，还有一些人好奇的一点是，中国公司在标准制定组织里似乎没有什么存在感。有个德国人告诉我，他曾经问 Branden Eich（JavaScript 之父）为什么 TC39 （制定 JavaScript 标准的组织）里没有中国公司，Branden Eich 的回答是他感觉中国人似乎对标准不感兴趣。这让那个人感到相当诧异，他问我为什么像阿里这样广泛使用 JavaScript 的公司，会对 JavaScript 标准的制定和决策不感兴趣呢？然而这个问题，我也给不出一个看上去比较合理的答案……
因为我是 Node.js CTC（Core Technical Comittee）的提名成员，所以也参加了 Node.js Collaboration Summit 后 Google 撮合的一次 Node.js CTC + TC39 + V8 团队 + npm 的人 + IBM 的人 etc. 的聚餐，刚好有跟 TC39 的 Daniel Ehrenberg 聊了一下，在我简单介绍了一下我的工作之后，他想知道阿里人对 JavaScript 标准的现状和进行中的 proposal 的看法。在钉钉和一些同事讨论过后，后来 JSConf EU 有一个 TC39 的 Panel，结束后 TC39 的几个人在 Google 的展台继续交流，刚好上台的 TC39 成员里 James Snell 也是我平时交流比较多的 Node.js 社区的核心成员，于是我就过去聊天，把我总结的一些反馈和思考告诉了他们。
TC39 在台上的 Panel，左一的 James 和左四的 Myles 都是 Node.js CTC 的成员。左二是 Domenic Denicola 也经常和 Node.js Core 有合作，左三是 Daniel Ehrenberg，左五是一个在微软工作参与维护 moment.js 和 Date API 的成员。
在和 Daniel 和 James 交谈的时候我们聊到了最近 Node Core 里几个关于 Promise 的 PR，James 的感觉是虽然 async/await 已经落地了，但是在 Node 的用户里教育和推广离开 callback style 还需要时间，于是我向他们介绍了一下 generator 在 async/await 出现前已经在阿里的生产环境使用了很多年，内部的后端代码基本没有什么人用 callback 了，基础库的 API 上基本不是 promise 就是 generator，内部的定制框架基本都不基于 express 而是 koa。他们对国内几乎完全不同的风向很惊讶，根据 Daniel 介绍，V8的generator 当初是 Bloomberg 赞助他现在的公司的 Igalia 的 Caitlin Potter 实现和帮助推进标准的，就是因为 Bloomberg 和我们一样内部很依赖这种 generator 的用法（P.S. 我在会场居然碰到了以前在中大认识的师兄，他就在伦敦为 Bloomberg 工作，据他介绍Bloomberg 内部有一个 V8 的 fork，里面有很多私有的扩展，这点有一点类似 alinode 的前身的情况）。Daniel 现在正在负责推进的一个标准是任意精度的整数，这让我想起 alinode 其实内部也曾经有一个为蚂蚁的业务需求添加了 BigNumber 的 fork，而且阿里内部的前后端 JavaScript 代码确实遇到过类似用 Number 做 ID 的类型结果遇到精度问题，需要抓紧升级的情况。但我们基本都是自己去寻找曲线救国的解决方案，并没有想到去 TC39 推进标准，从长远角度解决问题，也没能 Igalia 一样作为第三方协助推进 JavaScript 引擎上游做实现，阿里作为 JavaScript 的使用大户，虽然在很多方面受到 JavaScript 标准的影响，但在 JavaScript 标准和实现上的参与还是太少，也难怪别人会觉得奇怪了。在我跟他们介绍阿里 JavaScript 和 Node.js 技术应用的一些情况（包括 YunOS，enclose 这些比较罕见的应用）的时候，他们表示，为什么你现在才出现，我们根本不知道还有一个大公司在这样用 JavaScript = =！我只能回答其实我去年才毕业，在阿里正式工作不到一年，阿里和国内业界的很多情况我也是才了解没多久……= =|||
或许我们在标准制定和实现上的缺席有一点是因为，我们内部推广一个新东西一般比在社区推广高效的多，TC39的标准制定过程十分漫长，中间有很多无比枯燥的文案细节要讨论，无数画风不太友好的会议要开，虽然 JavaScript 引擎实现新特性也是相对效率比较高的（除了要经常跟进proposal 的变动，但毕竟基本都是写代码，不怎么需要动嘴皮子），但是许多需要 runtime 配合实现或者推广的特性还是会很长时间都无法落地。比如 Promise 在 Node.js API 上的整合，纠缠了好几年都没有落地，中间出现过许多个 PR，最后都会被无休无止的论战淹没，以前成立过的 Promise Working Group 现在也不活跃了，最近几个为 Node 添加的 PR 也是争议不断。这样有争议性的月经话题纯粹由社区的志愿维护者去推进，很容易最后大家都觉得口水战太久浪费彼此的时间，结果一次又一次不了了之（P.S. 从柏林回来之后为 Node.js Core API 添加 Promise 抽象的 util.promisify() 终于合并了，感谢耐心惊人的 Anna，她大概是我见过的脾气最好的人之一 = =）。虽然我们内部对 Promise 和 async/await 存在实际需求，但是毕竟在 Node.js Core 没有直接支持的情况下，我们用 npm 模块加上 co + generator 也能达到类似的开发体验，自己也有其他需求在身，对于推动社区和标准落地这种容易吃力不讨好还特别耗费时间的事情，自然就没有十分的动力了。
我们组因为工作内容的原因，偶尔会向 V8 交一些 patch，而向 Google 的开源项目提交 patch 需要签署 CCLA，中间的过程十分漫长，需要联系法务做一些不在程序员认知领域的手续。到我提交 patch 的时候我们组已经把坑给踩过了，虽然时隔略久法务也忘了怎么为新成员授权，不过通过四处查阅文档一两天后也解决了手续问题。然而看当初第一次签署协议的邮件记录了解流程的时候，还是对整个过程的曲折程度感到惊讶，幸好我授权的时候原来接口的法务还在，如果当初的法务离职了，没有交接好这个十分低频的工作，估计就远远没这么顺利了。相比之下，仅仅是内部 fork，不提交 patch 回去的话想怎么改就怎么改，或许这也是我们倾向于内部造车而不是提交反馈回上游开源社区的一个原因。当然这种东西法务也是一回生两回熟，Intel 和 IBM 这样四处参与开源项目的公司对这种手续就已经驾轻就熟了，以后的情况还是比较乐观的。
另外一点与国外大公司不同的是，在对待标准化进行中的 JavaScript 新特性的时候，我们大多数人还处在只看 proposal 表面而不去关心细节，注意不到其中可能和自己的实际需求完全脱节的坑的阶段。相比之下 Google 这样技术布局更广的公司对 proposal 的细节关注更高，不会只对一个 proposal 看似美好的表面欢呼雀跃，而是会去认真挑刺，对于他们关心的 proposal，如果发现和实际需求不符合的情况他们会直接进行阻拦，宁可什么都没有也好过让一个有缺陷的特性进入 JavaScript 的标准覆水难收，就连自家同事做 champion 的 proposal 可能也照怼不误，比如 Object.observe，可取消的 Promise 都是这样夭折的。一个论点是，只要实际需求足够强烈，proposal 们都是会以更好的形态卷土重来的，所以阻拦一个特性的实现并不会造成世界末日。包括当年的 ES4，最近几年被不少人在 TypeScript 的风潮下发现当成遗珠，觉得微软和雅虎当年的阻拦似乎显得有些无理取闹，但事实上参与 ES4 制定的很多人其实是庆幸 ES4 最终没有落地的，因为 ES4 的很多想法表面上看似美好，事后具体去深究他们写出来的草案细节，会发现其实还有很多严重缺陷，这是许多普通的应用开发者光看各种 proposal 的概述，不去直接翻阅 ecma-262 的情况下不会注意到的，只有整天关心茴字有几种写法，不断咬文嚼字的标准制定者们才会感到后怕。当然，某些阻拦新特性的理由可能显得有些杞人忧天，为了一点小事伤了大计，然而一个未落地的新特性到底会不会因为一点细节上的 bug 在开发者社区造成严重的负面影响，是没有人能给出确切答案的，毕竟没有人能够预测未来，只能说塞翁失马，焉知祸福了。
Node.js Collaboration Summit
比较沉重的思考写完，下面是比较轻松的部分了……按照时间顺序，先记录一下 Node.js Collaboration Summit 的见闻。
Node.js Collaboration Summit 在 JSConf 会场附近的 co up 举办，主要以各个 working group 分组讨论以及集体讨论一些重要 issue 的形式进行。因为航班的缘故错过了第一天早上的 introduction 所以没有认全人，不过还是认识了很多一起 code review 过的 GitHub ID 的本尊，参与了部分讨论。
HTTP/2
目前 nodejs/http2 的 master 还在继续和上游的 master 同步，基本实现已经完成，主要缺测试和进一步检查有没有内存泄漏等问题。经过和 npm 上 http2 的维护者沟通后确定这个模块最终的名字是 http2，通过 npm 的安装机制来保证未来跑在老版本 Node 使用 npm 包的代码依然能够正常运行，但是升级到新版本的 Node 如果 require('http2') 就需要迁移到 Node Core 自己的这个实现了。
Diagnostics
目前大多数 APM 厂商都是通过 monkey-patch Node.js 里的模块获取必要的监控信息的，但是这样很容易造成兼容问题并且互相冲突。计划对各家 APM 插入代码（instrumentation）的方式总结一下 best practices，编写一个不断更新的文档来为 core 模块和用户模块提供指导，方便多方代码和谐共处。另外或许可以统一一下 APM 厂商输出监控信息的格式，一个想法是使用 V8 的 trace events API，但问题是目前大多数 APM agent 都是在 JS 层插入代码的，而 trace events API 是 C++ 层的，如果产生跨 JS 和 C++ 层的调用会增加性能损失。另一个方案是各家联手设计一个 JS 的 API，不过这个 API 可能需要放在 core 里否则没法在生态系统里落地。API 的设计可以借鉴 mongodb 的 APM API，他们自己维护这个 API，目前为止效果还挺不错的。
TSC 的组织结构
现在 Node.js 的组织结构是 CTC（Core Technical Comittee）属于 TSC（Technical Steering Comittee）的下属，各个 working group 也在 TSC 下面，CTC 和各个 WG 负责 Node.js 项目与生态系统日常的实际工作，TSC 的职能更偏行政一些，比如审批旅行经费的申请，这就导致了很多人对 TSC 的日常工作不感兴趣，对参加 TSC 的工作会议也不是很积极。鉴于这个情况，一些人参考 TC39 的组织，希望能够重新调整 Node.js TSC 的组织结构，改 CTC 为一个针对 Node.js Core 的 WG，和其他 WG 并列，并且提升一些非正式的 GitHub 团队（如负责版本发布与维护 git 分支的 release 团队）作为正式的 WG，不跨 WG 的争议在 WG 内自行投票解决（类似现在 CTC 投票解决 Node.js Core 里的一些决策争议），跨 WG 的争议提到 TSC 投票解决，每个 WG 只有一票。日常偏行政的工作还是由 TSC 决定，但是不要求所有人都参加，只要关心的人出来投票即可，这样没有强烈争议的问题可以更快通过。同时，TSC 的职能也更偏重为各个技术团队和 Node.js 基金会董事沟通的桥梁。
Myles Borins 和 James Snell 向大家介绍他们对新架构的设想
与几个日本 collaborator 的交流
这次到柏林见到了 Node.js Core 两个比较活跃的日本开发者，Daijiro Wachi（和智大二郎）和 Yosuke Furukawa（忘记问汉字怎么写了……），他们也是 NodeFest（东京Node学园祭）的组织者，作为同是亚洲国家的 Node.js 开发者,他们对国内的 Node.js 社区也很感兴趣，希望我们能够多交流一下。此外还得知韩国也是有 Node.js 的会议的，叫做 playnode，他们问我中国有没有 Node.js 相关的活动，想了一下好像只有比较小的 Node Party 和 Node 地下铁了，虽然 JSConf China 也有一部分 Node.js 相关的话题……
我和 Daijiro 因为之前一直在 GitHub 上一起参与 WHATWG URL 标准的实现所以比较熟，聊到了最近在日本很火的中国人不需要用现金的新闻（凄い势いで进む中国のキャッシュレス社会、既に想像の遥か上に到达），顺便介绍了一下阿里的一些业务，另外在和几个德国人聊天的时候他们也表示中国在这方面比其他国家领先了不少，很多人对国内这方面的生活方式都感到很好奇。
JSConf EU
JSConf EU的组织与整体观感
这次 JSConf EU 很多人都注意到了女性讲师的比率特别高，在和其中一位女性讲师 Chen Shay （来自 Google AMP 团队）交谈的时候，得知这次的演讲稿评选是盲选的，也就是评委看不到讲师的个人信息，只能凭 proposal 的标题和概述来评分。另一方面，JSConf EU 的气质比较 hipster，相比起一些会议西装革履，热衷企业级话题的的氛围，JSConf EU 会更偏好有趣、发人深省的话题，和关于开源社区建设、开源项目维护的话题，可能也是造成女性讲师比例高的一个因素。但是几个很有技术深度的 talk，比如 V8 团队成员分别就 JavaScript 引擎优化与 parser 实现做的分享，讲师也都是女性。
受 Node.js 基金会的邀请，我也在担任今年 Node.js Interactive North America 的演讲稿评委，刚好在 JSConf 的第一天就是 NINA 第一轮评审的截止日期，所以也免不了比较一下两个会议的差异（去年到 NINA 做分享的纪行可以看这里）。今年的 NINA 和 JSConf EU 一样，也采用了盲选的方式进行评审。按个人经验，NINA 其实是企业气氛比较浓的会议，所以有大量的企业级议题。有趣的是，NINA 的绝大部分议题都和 JSConf 仿佛处在两个世界。NINA 收到了大量关于 IoT、Serverless、Micro services、Container/Orchestration的议题（多到已经视觉疲劳了必须要看几个 proposal 休息一下再评分才能保持客观……），基本上和 QCon、Goto这类综合性会议的热点差不多，大部分都在谈论这些热点话题在 Node.js 领域的应用。而 JSConf EU 绝大部分话题要么是前端开发相关，要么是关于社区或者 JavaScript 本身，只有一个关于压缩算法和一个关于 IoT 道德问题的分享算是和 Node.js 或者后端开发相关。这点还是让我感到比较意外的，在会场门口的 nearform 的展台聊天的时候，也有人提到了这点（nearform 是做 Node.js 服务的公司，有不少 Node.js Core 的成员，所以技术倾向也离前端比较远）。
因为 JSConf 都会把视频上传到 YouTube，加上几个感兴趣的 talk 我已经在其他地方看过，所以 talk 本身不是重点，主要是趁这个难得的机会，在会场与来自世界各地的开发者进行交流。大部分思考总结在前面了，这里就不赘述了。除了 V8 的两个 talk 以外（其实这两个 talk 以前也见到过），印象比较深的还有 Ashley Williams 的 A Brief History of Modularity，谈及了 twitter 上热议的 leftpad 事件以及 “删除 jQuery 结果反而加多了一大堆代码” 事件，引经据典非常发人深省。另外由于 Facebook 刚好在 JSConf EU 前几天发布了 prepack，好几个讲师都提到了抓紧在 JSConf EU 前临时改 slides 把 prepack 谈进去的事……
一些其他讨论
在看 talk 的间隙我在会场旁边的展区和别人聊天，刚好会场门口就是 nearform 的展台，nearform 的蛮多人以前都在 GitHub 上一起合作过，比较熟就聊的比较多（连过来照看他们 HR 姐姐都能一起聊 >__<）。Node.js 社区的核心成员，同时也是前 IBM 的 Node.js Technical Lead 的 James Snell 最近跳槽到了 nearform，他对阿里内部的 Node.js 应用状况挺感兴趣的，希望有机会能够在一起开个 chat 交流一下。另外他们也很好奇我们中国的开发者对 Node.js 里的错误信息本地化有什么意见，不过个人来说习惯看英文的错误信息，中文的错误信息感觉如果翻译的不好还不如直接看原文，而且英文的错误信息一般 Google 能搜到更多结果……刚好最近我们也在合作推动给 Node.js 里的错误信息添加统一的永久编号，以编号作为标示，专门在文档里详细解释每个编号的意义和解决方案的工作，个人的意见是这套系统完成之后，把有详细解释的文档翻译成中文会对中国的开发者更有用，而输出到 stderr 里的那一行错误信息其实不翻译问题也不大。
另外由于这几天在讨论前面提到的 TSC 重组的事，加上最近经常收到关于 Node.js API 文档中文翻译的请求，发现 Node.js 的国际化 WG（i18n WG）下属的很多小组，包括简体中文小组的工作都处于停滞状态，这是 TSC 重组需要考虑的一个问题，毕竟 i18n WG 是一个比较特殊的存在（由大量不同语言的小组组成，其中部分活跃，部分停止），关于这个 WG 的投票权怎么解决我们也还没有想出特别好的方案。考虑到我们正在准备在今年的 JSConf China 举办一次 Code and Learn 活动，或许可以借此机会吸引更多的人参与到中文翻译的活动来。
到德国旅行的一些经验
到德国开会需要申请申根签证，本来想申请商务签证的，结果发现德国的商务签证需要德国方出具的邀请信原件（也就是必须快递过来 = =），而且还要雇主的三个月银行对账单（这种东西在大公司怎么拿得到 = =!!），好在只是参会不是去讲，所以换成了旅游签证。相比之下，去年申请的商务美签虽然要面签但简直是水过，面试只看了一眼电子打印的邀请信……我一般习惯自己 DIY 签证申请，所以材料都是自己准备的。申根签证基本上都被领事馆外包给了中智的签证中心处理，因为需要按指纹所以第一次申请申根签证的不能纯远程邮寄材料了事，好在杭州也开了一个签证中心所以不需要去上海递签。签证需要的机票预订单是在飞猪上询价之后下单，出票后拿着预订号到汉莎官网查询打印的（因为飞猪给我的预订单排版有点惨不忍睹……），酒店预订单是在 booking 上打印的，保险是在淘宝上买的（第一次购买居然给了一个50块的红包，于是我55块就买到了符合签证要求的保险……），JSConf EU 的票是通过官方渠道在 tito 购买的，付款后会发送 receipt 到邮箱。
柏林的公交系统报站很多是只有德文的，而且非中枢的地铁站、火车站和公交站之类地方标示很多也只有德文，所以如果不学一点简单的旅游用德文以及德语发音的话，可能会在地铁站看着只有 Ausgang 没有 Exit 的标示一脸懵逼，或者在车上听不懂站名坐过站……不过好在大多数人是可以说英语的，连机场卖公交票的老奶奶都木有问题。柏林的公交系统，包括地下铁（U-Bahn），地上铁（S-Bahn），有轨电车（Tram），普通巴士和机场大巴，全都是一个售票系统，如果要呆比较多天而且要到处跑的话，买多日票会比较划算，我直接到了机场就买了一张七日票，接下来的几天所有公交都可以随便坐。另外柏林的公交系统都是不验票的，巴士上没有刷票的地方，地铁站也没有闸口，但是车上会有便衣的人随机抽查，抽到了没有票或者票没有盖章是要罚款的，我在柏林只遇到过一次查票的人。买到票之后需要盖章（validate），上面会印上盖章时期和起始地点，查票的时候以这个信息为依据来检验票有没有过期或者有没有超过能去的范围。当然如果人多的话的话也可以直接打车，印象里有点小贵，地铁坐三四站就能到的地方打车要十几欧，而一张七天票才三十欧，而且柏林的公交系统效率非常高，也很准点，从时间角度来讲打车也未必快多少。柏林的出租车貌似都是静静地在某个上车点排队等人主动来敲他们的窗子的，而且给的收据都是在现成的票据上手写的金额。
德国很多地方是不能刷信用卡的，所以最好带上足够的欧元现金。欧元纸币最小面额是 5 欧，再往下就是硬币了，但是 20 分和 50 分的硬币比 1 欧和 2 欧的硬币大，而且花样和颜色差的不是很远，有点难辨认……虽然估计欧元区的人习惯了掂量一下重量就知道了……另外去欧洲旅行一定要有欧标的转换插头，我只带了一个，感觉不够用 =__=。此外出行前还买了一个 vodafone 的流量卡，不过拿来开 wifi 热点另一台手机消耗的比较肆无忌惮很快就把流量给消耗掉了，虽然联通的漫游也还算够用，26 包一天的流量，也是漫游到了 vodafone，网速还算可以吧……
在柏林到达和离开的机场都是 Tegel（TXL），这是一个很神奇的机场，登机口均匀散布在圆形的结构里，每个登机口都有自己的值机柜台和安检，从抵达机场公交站到完成值机安检抵达登机口只要十来分钟，效率惊人。相比之下转机入境的慕尼黑机场（MUC）和出境的法兰克福机场（FRA)就大得多了，在慕尼黑机场的时候我还不小心走错到了直接离开机场入境的 passport control，被取消了 stamp 到转机的 passport control 重新入境 OTZ。另外，法兰克福机场感觉到处都是中国人和中文广告，慕尼黑机场中国人就少得多……
聊天的时候一个纯正德国人告诉我 JSConf EU 举办的区域在柏林乃至德国都是一个很特别的存在，无论是政治还是文化上……街头有很多涂鸦，是本地文化的一部分，所以看上去会有些脏乱。这边天黑的很晚，晚上八九点天还是亮着的，加上人也不少，所以晚上一个人走路的时候感觉并不害怕。和其他一起参会的同事在街上走的时候好几次遇到跟我们打招呼说话的，不过也都没有恶意，有的用中文说你好，有的用英文说 Welcome to Berlin!，感觉都挺友好的。在 JSConf 和一个德国女程序员聊天的时候她说他们本来要派中国分公司的人过来，结果那人在国内听说了太多德国的恐怖新闻坚决不肯过来，她觉得很奇怪因为德国并没有那么不安全呀……我想估计社会新闻听多了哪里都会显得很危险吧，如果一直关注国内的这类新闻也会觉得中国很危险的，虽然社交平台上经常传各种德国的这类消息，然而仔细注意一下国内发生的各种事件其实也很多，但我平时也并没有感觉生活在水深火热之中……
广告：Code and Learn in Shanghai!
最后打一个广告：Node.js 基金会打算今年到中国举办一次 Code and Learn，也就是由 Node.js Core 的 collaborator 做导师，给来参加的人分配一个简单的任务，一对一指导参加的人向 Node.js Core 提交 PR 的活动，任务本身一般比较简单，主要是带领大家熟悉向 Node.js 这种大型开源项目提交 PR 和 code review、合并、发布的流程。目前暂时决定作为 JSConf China 的一部分举行，地点在上海，时间大概是 7 月 16 日，坐标在国内的几个 collaborator 都有参加做导师的意向，国外也有几个 collaborator 正在申请经费过来。对向 Node.js Core 做贡献感兴趣又打算参加 JSConf China 的同学可以关注一下，相关讨论和计划可以参见 nodejs/code-and-learn#68。
最后更新：2017-05-13 08:44:30