概述

上週末，PyGotham邀請我在他們於曼哈頓舉辦的年會上演講。為了最大化參與這場活動的收穫，我整理了一份筆記，記錄我在會中的所學。分享出來，希望對其他人也能帶來一些趣味或幫助。

評分與評價

演講品質

今年整體的演講品質讓我有點失望。我喜歡其中的幾場（見下文），但有不少場次並未達到我的期待。

部分原因在於我並非目標聽眾。許多時段都是 Machine learning(機器學習) 相關的演講，我覺得 Machine learning 很有趣，但工作上用不到，所以對入門的 ML 演講已經感到有點飽和。

活動流暢度

要向 PyGotham 的主辦團隊致敬，整場活動運作得如同一部運轉順暢的機器。身為講者，我在需要的時間點都能取得所有資訊。我看的每一場演講，音響與視訊設備都運作良好。所有議程都準時進行。餐點美味且份量充足，只不過碳水化合物稍多了一點。

場地

賓州飯店（The Pennsylvania Hotel）是很棒的研討會場地。現場有三個舞台，座位充足，我從未感到擁擠或被擋在想看的演講之外。所有會議室距離很近，方便在不同場次間移動，也有足夠的空間讓與會者在走廊交流。

我對自己演講的感受

請見下方的「自我演講講評」。

最喜歡的演講

在網路徹底腐壞之前將其封存

講者：Nick Sweeting（尼克·史威廷） 來自 Monadical

我從未意識到圍繞著網頁封存竟有如此龐大的社群，以及他們的工具竟已如此成熟。尼克·史威廷指出，我們失去集中式資料典藏的情況有多麼常見。這對像亞歷山大圖書館這樣的古代典藏是如此，對 Geocities 和 Tumblr 這類數位資訊亦然。唯有當一般人擁有能夠自行封存與保存副本的工具時，這些典藏才得以存續。

尼克·史威廷介紹了可用於封存網頁的不同工具，並帶領大家瀏覽各種致力於網路封存的組織與線上社群。工具的成熟度超出我的預期，甚至有好幾款工具能夠封存 single-page apps(單頁應用程式)（SPAs），也就是透過大量 JavaScript 與 RPCs 動態產生 HTML 的應用程式。甚至在常見的工具程式中，也內建了強大的封存功能。

尼克·史威廷展示了以下 wget 指令，它能完整下載單一網頁，包含所有的 JavaScript、CSS 與圖片：

wget \
  --no-verbose \
  --adjust-extension \
  --convert-links \
  --force-directories \
  --backup-converted \
  --span-hosts \
  --no-parent \
  -e robots=off \
  --restrict-file-names=windows \
  --timeout=60 \
  --warc-file=archive.warc \
  --page-requisites \
  --user-agent="Lalala this is chrome I promise..." \
  --load-cookies="mycookies.txt" \
  --compression=auto \
  --no-check-certificate \
  --no-hsts \
  "https://2019.pygotham.org"

其他我喜歡的部分：

• 尼克·史威廷分享了kiwix，這是我之前不知道的專案。他們提供像 Wikipedia 與 StackOverflow 這類大型內容網站的離線副本，讓你可以在本機執行。
• 尼克·史威廷維護了一份封存資源與社群目錄。

當維護 Python 專案不是你的正職時

講者：Hynek Schlawack（海尼克·許拉瓦克）

• 演講大綱
• 投影片

海尼克·許拉瓦克維護著幾個熱門的開源專案（attrs、structlog），而他能用來審查外部 pull request 的時間有限。他利用自動化工具來縮短審查時間，並讓第三方貢獻者能夠自行找出錯誤。這正好呼應了我對程式碼審查的第一守則：讓電腦做枯燥的部分。

海尼克·許拉瓦克是一位風趣且充滿活力的講者。他以一句玩笑道開場：「嗨，我是海尼克·許拉瓦克，你那位還不認識的歐洲朋友。」這為整場演講定調，內容會是有趣且有時帶點詼諧的。

其他我喜歡的部分：

• 介紹了幾個我原本不知道的工具：
  • isort：整理你的 Python import 敘述。
    • 我已加入到我的Python3 範本專案。
    • 這個工具的缺陷是它只提供兩種模式：「自動修正」（不是我在建置檢查中想要的）或「給出無幫助的失敗訊息」。
  • Black：格式化 Python 程式碼的空白。
    • 很有趣，但相較於我偏好的格式化工具 yapf，似乎沒有帶來什麼有意義的改進。
  • tox：可在不同的虛擬環境中執行 Python 測試腳本。
    • 我想我大約五年前用過 tox，但當時我是把它當作在單元測試中模擬行為的工具。現在這個專案已經完全不同，所以我搞不清楚是他們在 mock 被納入標準函式庫後改變了方向，還是我自己搞混了。
    • 無論如何，它看起來很不錯。我還沒有建立過需要在多個 Python 環境中執行的專案，但先記起來備用也不錯。
• 我喜歡海尼克·許拉瓦克的pull request 檢查清單範例與貢獻者文件。
• 我以前從未見過有人為自己的演講建立公開的文字大綱，但海尼克·許拉瓦克的很有幫助。

讓你成為 Async，成就大善！

講者：Mark Smith（馬克·史密斯） 來自 Nexmo

馬克·史密斯介紹了 Python 的 asyncio 模組，這是用來撰寫並行程式的 Python 函式庫。他解釋自己是透過打造一個名為 mysyncio 的簡化版本來搞懂這個函式庫的運作方式。

我很驚訝馬克·史密斯竟能用如此精簡的程式碼重現 asyncio 的諸多功能。他的實作省略了真正 asyncio 模組中的關鍵功能，最明顯的是 thread-safety(執行緒安全性)與 exception handling(例外處理)，但仍實現了 asyncio 的核心功能。並行程式設計往往難以推理，因此看到馬克·史密斯去除魔法後的版本，讓 asyncio 變得更直觀易懂。

自我演講講評

講者：Michael Lynch（麥可·林奇）（我本人）

• 投影片

我對自己的演講感覺不錯。我對準備程度感到滿意（演練了 5 到 7 次），不過我希望自己能更早開始排練，而不是拖到研討會當週才匆忙準備。

在 PyTexas 的演講後，我給自己的改進筆記是放慢語速，並避免太常低頭看筆電。我想在 PyGotham 時，我太專注於維持緩慢的語速，以至於語調聽起來很平淡，好像我對自己的內容感到厭倦。在前 5 到 10 分鐘後有改善，但未來演講時我想提醒自己，要記得在表達中注入情感。

我最大的失誤是使用 Google Slides 的「簡報者檢視」來投影，而不是鏡像輸出螢幕。我以為螢幕上的計時器能幫我掌握節奏，卻忘了那會讓我看不到自己的投影片。我對內容已相當熟悉，光看簡報者檢視中的小縮圖就能講完大部分內容，但在好幾個時刻，我仍不得不轉身背對觀眾去看螢幕上的文字。

• 表現良好的部分

  • 我對所報告的內容感到得心應手。
  • 我成功放慢了語速，並將注意力集中在觀眾身上。

• 需要改進的部分

  • 記得要鏡像輸出筆電畫面，而不是使用「簡報者檢視」來呈現。
  • 說得慢不代表要用平淡的語調。我很興奮能參加這些研討會，所以可以在演講中更好地展現這份熱情。
  • 內容本身聽起來有點生硬——可以多加一點輕鬆感和笑點。
  • 提早開始排練，讓準備過程不會感到倉促。

花費

跟我參加 PyTexas 花費的約 1,200 美元相比！如果所有研討會主辦單位都把會場辦在開車或搭火車就能到的距離，而且確保我附近剛好有朋友有空房可以借住，那就太方便了。

時間方面，我花了 5 到 10 小時準備。由於已經有了 PyTexas 的投影片，這次準備起來輕鬆許多，不過我仍根據上次研討會的反思對簡報做了一些修改。

其他想法

「我還能怎麼改進？」

在以往的研討會上，當有人走過來說喜歡我的演講時，我總是只會道謝。今年，我嘗試回應：「謝謝！你覺得有哪些部分我可以改進？」人們對這個問題有點意外，但通常會思考一下並給出建議。

研討會中可惜的是缺乏回饋。每個人都能在公開演說與投影片的清晰度上進步，但講者往往缺乏關於哪些有效、哪些無效的資訊。當我在看演講時，經常看到一些講者犯下可以輕易修正的錯誤，很想告訴他們。但主動給予未經請求的建議是很失禮的，尤其對方很可能本來就對此感到焦慮。

未來當有人在演講後來找我時，我會道謝，同時記得詢問我還能怎麼做得更好。如果你看過我的演講，歡迎告訴我你覺得我可以改進的地方。

研討會是激發靈感的好地方

研討會能激發創造性思考。我總是要到坐在會場時才想起來，但每場我參加的研討會都會發生這種事。我在研討會上產生的想法，是在其他地方絕不會想到的。

我不確定是因為有時在聽演講時思緒會飄走，還是因為講者帶領我走過他的思考過程，進而觸發了我平時不會有的想法。但每參加一場研討會，我都會帶著關於事業或未來想承接專案的好點子離開。

我應該來場關於竊取加密貨幣的演講

舉一個我在其他地方絕不會想到的點子為例，我在 PyGotham 意識到應該把《我是如何竊取你的 Siacoin》變成一場研討會演講。這是一個有趣的故事，用到了 Python，還涵蓋了像Levenshtein distance(萊文斯坦距離)與public-key cryptography(公開金鑰密碼學)等主題，我可以用有趣的方式來介紹。以前從沒想過要把它做成演講題目，但一想到就覺得再明顯不過。

也許我不該有所求

今年稍早的 PyTexas 之後，我意識到自己正在尋找新專案，而現場有一整間會議室的科技工作者，所以我當時就該請大家來跟我聊聊他們工作上的痛點。每個人肯定都有希望能直接委外給代管服務的工作面向。我（希望）已經展現出自己是個能幹的開發者，所以他們本可以請我幫他們打造些什麼。

在 PyGotham，我在演講結尾邀請大家來找我聊聊他們覺得工作中缺少的代管服務。結果，什麼也沒發生。

我本以為最差的情況，至少也會得到一些糟糕的點子，像是：「我們想要 MailChimp，只是希望它是免費且無限量的。」但沒有，什麼都沒有。所以也許這個策略沒什麼價值。未來，我可能會嘗試利用這個舞台來為 What Got Done 吸引一些新使用者。

審查 CFP 讓人大開眼界

當講者申請研討會時，他們會填寫「CFP」，也就是 calls for proposals(徵求演講稿)。內容是幾段文字，說明你為何應該在研討會上演講，以及活動議程中的簡介該怎麼寫才能吸引觀眾來聽你的演講。

PyGotham 是我經歷過的第一個讓與會者能看到並對每一份 CFP 投票的研討會。我寫過幾份 CFP，但從未讀過別人的，所以以一個（或多或少）擁有投票權來決定哪場演講會被選上的身分去體驗，令我大開眼界。

一些心得：

• 審查 CFP 真的很耗神。
  • 我想大約有 300 份投稿。我分了 3 到 4 個時段來審，但我確定自己對某些投稿更有耐心、更寬容，僅僅是因為精神狀況不同。
• 要在個人興趣與大眾喜好之間取得平衡很困難。
  • 例如，我對 Machine learning 演講不是那麼感興趣，但我知道其他人有興趣。那我該投贊成還是反對呢？
• 在 CFP 中擺出自命不凡的態度沒有好處。
  • 有些投稿者表現得好像填寫 CFP 有辱身分。有一題是：「你的演講主題是什麼？」接著下一題大致是：「與會者應該從你的演講中帶走什麼？」我看到好幾個人對後面那題給出敷衍的答案，像是「見上文」或「這跟第一題沒有實質差異」。
  • 當你已經審了 100 份 CFP 且必須淘汰 90% 的內容時，那些態度傲慢的投稿最容易被刷掉。

一年三場研討會是個好目標

年初時，我設下目標要在 2019 年於三場研討會上演講。PyGotham 讓這個目標達成：

1. NERD Summit 2019
2. PyTexas 2019（我的筆記）
3. PyGotham 2019

回顧起來，我覺得一年三場仍是個好目標。每場研討會都會讓我累上一、兩週，但它們也能激發好點子，並讓我接觸到原本可能不會發現的工具與技術。