總覽

上週末，PyGotham 邀請我到他們在曼哈頓舉辦的年度研討會上演講。為了讓這次參與的收穫最大化，我整理了一份筆記，記錄我在現場的所學與觀察。分享出來，希望對其他人也能有點意思或有點幫助。

評分與總評

演講品質

今年整體的演講品質讓我有點失望。還是有幾場我很喜歡（見下方），但不少場次都不太合我的期待。

問題有一部分在於我本來就不是主要的目標聽眾。很多場次都是機器學習相關的，雖然我覺得機器學習很有趣，但工作上用不到，聽過一堆入門的機器學習演講後，已經有點飽了。

活動流暢度

必須稱讚 PyGotham 主辦團隊，把活動辦得像一台運轉順暢的機器。身為講者，我在需要的時間點都拿到了所需的資訊。我看的每場演講，影音設備都運作良好。所有議程都準時進行。食物好吃又充足，只是碳水有點多。

場地

Pennsylvania Hotel 是個很適合辦研討會的場地。現場有三個舞台，座位充足，我從來沒有覺得擁擠，或是想看的演講被擋在門外。各個會議室彼此相鄰，換場很方便，也有足夠的空間讓大家在走廊上交流。

我對自己演講的滿意度

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

精選演講

趁一切還沒腐爛之前，先把網路封存起來

講者：Nick Sweeting，來自 Monadical

我以前沒意識到圍繞網頁封存的社群有多大、工具又有多成熟。Nick 指出，我們失去集中式資料庫的情況其實很常見。這對像亞歷山大圖書館這樣的古代典藏是如此，對 Geocities 和 Tumblr 這類數位資訊也一樣。當一般人擁有可以自行封存、保存副本的工具時，這些典藏才有機會留存下來。

Nick 介紹了各種可用於網頁封存的工具，也帶大家瀏覽了致力於網路封存的各種組織與線上社群。工具的成熟度超出我的預期，甚至有好幾套工具可以封存單頁式應用程式（SPA），也就是那些大量使用 JavaScript 和 RPC 動態產生 HTML 的頁面。就連常見的工具程式裡，也內建了強大的封存功能。

Nick 展示了下面這段 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"

其他我喜歡的地方：

• Nick 分享了 kiwix，這是我之前沒聽過的專案。他們提供了像維基百科和 StackOverflow 這類大型內容網站的離線版本，讓你可以在本機上執行。
• Nick 維護了一份封存資源與社群的名錄。

當這不是你的正職時，如何維護一個 Python 專案

講者：Hynek Schlawack

• 演講大綱
• 投影片

Hynek 維護了幾個熱門的開源專案（attrs、structlog），能用來審查外部 pull request 的時間有限。他利用自動化工具來減少審查時間，同時讓第三方貢獻者能自己找出錯誤。這正好呼應我對程式碼審查的第一原則：讓電腦去做無聊的部分。

Hynek 是個有趣又充滿活力的講者。他一開場就開了個玩笑：「哈囉，我是 Hynek，你那個你還不知道你有的歐洲朋友。」這句話就為整場演講定調，內容會很有趣，時不時還帶點幽默的調侃。

其他我喜歡的地方：

• 介紹了幾個我原本不知道的工具：
  • isort：幫你排序 Python 的 import 陳述式。
    • 我把它加到了我的 Python3 樣板專案裡。
    • 這個工具的缺點是只有兩種模式：「自動修正」（這不是我在建置檢查時想要的）或「給出沒什麼幫助的錯誤訊息」。
  • Black：格式化 Python 程式碼的空白。
    • 挺有意思的，但比起我慣用的格式化工具 yapf，似乎沒有帶來什麼實質上的改進。
  • tox：在不同的虛擬環境中執行 Python 測試腳本。
    • 我想我大概五年前用過 tox，但當時我是把它當作在單元測試中模擬行為的工具。現在這個專案已經完全不一樣了，所以我搞不清楚是他們在 mock 被納入標準函式庫之後轉了方向，還是只是我記錯了。
    • 總之，看起來還不錯。我還沒有做過需要在多個 Python 環境下執行的專案，但先記起來，以後或許用得到。
• 我很喜歡 Hynek 示範的 pull request 檢查清單和貢獻者文件。
• 我以前從沒看過有人為自己的演講做一份公開的文字大綱，但 Hynek 的那份很有幫助。

讓你成為 Async 高手，成就大業！

講者：Mark Smith，來自 Nexmo

Mark 介紹了 Python 的 asyncio 模組，也就是用來寫並行程式的函式庫。他說明自己是透過打造一個簡化版、名為 mysyncio 的版本，來搞懂這個函式庫的運作原理。

讓我驚艷的是，Mark 用這麼少的程式碼就重現了 asyncio 的大部分功能。他的實作省略了真正 asyncio 模組中幾個關鍵特性，最明顯的是執行緒安全和例外處理，但還是達成了 asyncio 的核心功能。並行程式通常很難直觀理解，所以看到 Mark 這個「去魔法」版本的函式庫，讓 asyncio 變得更容易理解了。

講評我的演講

講者：Michael Lynch（我本人）

• 投影片

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

在 PyTexas 演講後，我給自己的改進筆記是放慢語速、少一直低頭看筆電。我覺得在 PyGotham 時，我太專注於維持慢速語調，結果語氣聽起來很平淡，好像連我自己都對內容感到無聊。過了前 5 到 10 分鐘後有好一點，但未來演講時，我想提醒自己要記得在講話時注入情感。

我犯的最大錯誤是用 Google Slides 的「簡報者檢視畫面」來投影，而不是鏡像我的螢幕。我以為畫面上的計時器能幫我掌握節奏，卻忘了這樣我就看不到自己的投影片。我對內容算熟，大部分投影片光看簡報者檢視畫面裡的小縮圖就能講下去，但還是有好幾次我得轉身背對觀眾、看著大螢幕來讀文字。

• 表現不錯的地方

  • 我對要講的內容感到自在。
  • 我成功放慢了語速，並把注意力放在觀眾身上。

• 需要改進的地方

  • 記得要鏡像筆電畫面，而不是用「簡報者檢視畫面」來報告。
  • 放慢語速不代表要用平淡的語氣。我能參加這些研討會其實很興奮，演講時應該更能表現出這份熱情。
  • 內容本身聽起來有點太過一本正經——可以多加一點輕鬆感和笑點。
  • 提早開始排練，這樣準備起來才不會那麼趕。

花費

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

時間上，我花了 5 到 10 小時準備。因為已經有 PyTexas 時的投影片，這次準備起來輕鬆多了，不過我還是有根據上一次的反思稍微修改了內容。

其他心得

「我還能怎麼改進？」

在之前的研討會上，當有人走過來跟我說喜歡我的演講時，我總是只回一句謝謝。今年，我試著改口說：「謝謝！你覺得有什麼地方我可以改進的嗎？」大家對這個問題有點意外，但通常會想一下，然後給出建議。

研討會上很可惜地缺乏回饋。每個人在公開演說和投影片的清晰度上都能再改進，但講者卻很少能拿到哪些有效、哪些無效的資訊。我在看演講時，常常看到一些講者犯了其實很容易修正的錯誤，很想告訴他們。但主動跑去給人未經請求的建議是很失禮的，尤其是對方本來可能就已經很緊張了。

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

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

研討會能激發創意思考。我每次都忘了這件事，直到坐在會場裡才又想起來，但這在我參加的每一場研討會都會發生。我在研討會上想到的點子，是平常根本不會想到的。

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

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

舉一個如果不是在研討會就不會想到的點子為例，我在 PyGotham 意識到，我應該把「我是怎麼偷走你的 Siacoin」變成一場研討會演講。這是個有趣的故事，用到了 Python，還涵蓋了幾個像 Levenshtein 距離和公開金鑰加密這樣可以用有趣方式講解的主題。我以前從沒想過可以把它做成演講題目，但一想到就覺得這主意再明顯不過了。

或許我不該要求什麼

今年稍早參加完 PyTexas 後，我意識到自己正在尋找新專案，而現場滿滿都是科技從業人員，所以我本來應該請大家來跟我聊聊他們工作上的痛點。每個人肯定都有一些希望能直接外包給代管服務的工作。我（希望）已經展現出自己是個能幹的開發者，所以他們本可以請我幫他們打造些什麼。

在 PyGotham，我在演講結尾邀請大家，如果覺得工作中缺少了什麼代管服務，歡迎來找我聊聊。結果呢，什麼都沒發生。

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

審稿 CFP 讓人大開眼界

講者要申請研討會演講時，需要填寫「CFP」，也就是徵稿啟事。這是幾段文字，用來說明你為什麼應該在研討會上演講，以及議程表上的簡介該怎麼寫才能吸引聽眾來聽你的場次。

PyGotham 是我參加過的第一個讓與會者能看到並投票決定每一份 CFP 的研討會。我自己寫過幾份 CFP，但從沒看過別人的，所以以一個對哪場演講會被選上有投票權（雖然份量不明）的人的角度來體驗，真是大開眼界。

一些心得：

• 審稿 CFP 真的很累人。
  • 我想大概有 ~300 份投稿。我分了 3 到 4 次來看，但我確定光是因為精神狀態不同，我對某些投稿就比其他投稿更有耐心、更大方。
• 要在個人興趣和大眾需求之間取得平衡很難。
  • 例如，我對機器學習的演講沒什麼興趣，但我知道很多人有興趣。那我到底該投贊成還是反對？
• 在 CFP 裡擺出高傲的態度很吃虧。
  • 有些投稿者表現得好像填寫 CFP 有辱身分。裡面有一題是「你的演講主題是什麼？」接著下一題大概是「聽眾應該從你的演講中帶走什麼？」我看到好幾個人對後一題給了很敷衍的答案，像是「見上題」或「這跟前一題沒有實質上的差別」。
  • 當你已經審了 100 份 CFP、必須淘汰掉其中 90% 時，那些態度高傲的投稿就是最容易被刷掉的。

一年三場研討會是個不錯的目標

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

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

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