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