已經不再是個那麼常參加 Conf 的少年

這篇不會是以往參加 Conference 的那種筆記文了，筆記的話應該參考官方的共同筆記就行了：https://hackmd.io/@mopcon/2020/https%3A%2F%2Fmopcon.org%2F2020。

會想寫下這篇文章的原因主要是上一份工作真的滿忙的，所以期間根本毫無心情參加任何 Conference。看看這個分類的上一篇文章，居然已經是 2017 年 11 月，將近 3 年前了。而這個分類在 7 年間總共有 48 篇文章，一比較之下就知道我跟幾年前相比起來有多不常參加 Conf 了。

在這個離職後無業的狀態將近滿一年的時間，思索了人生、考量了許多現實狀況以及武漢肺炎的疫情影響，再次興起了找國外的遠端工作的念頭。這次剛好收到 OCF 寄來的信，提到有 OSCVPass 的人可以用開源貢獻票參加 MOPCON 2020，點進去後看到了有遠端工作相關的議程，第一次看到的時候其實有點猶豫，主要是今年也有拿開源貢獻票去 COSCUP 2020，但其實並沒有什麼充到電的感覺。但在 MOPCON 2020 會期的前兩個禮拜，又收到了一次信，抖然想起很久以前就想參加這個濁水溪以南最大科技年會，「也許南部的年會跟北部的感覺不一樣？」，看了一下還有票，於是就報名然後訂了附近的青年旅館了。

其實 MOPCON 第 1 屆當時朋友就問過我要不要去參加了，只是當時還是個在背學貸的窮大學生，前往南部來回通勤加上住宿的費用根本吃不消，加上看到是「行動科技年會」，跟我當時想走的系統管理與網路管理的方向不太符合，就沒參加。沒想到一晃眼 MOPCON 已經第 9 屆了，而這幾年自己的變化其實也不小，從背學貸的窮大學生變成了已經還完學貸且達成當時年薪目標的工程師，卻也在進入職場工作的這 4 年喪失了許多以往的熱情。

隨著年紀的增長，參加 Conf 的方式也不一樣了。

到了這個年紀，加上從參加人生第一場 Conf 算來已經快 10 年了，現在來參加 Conf 真的都不是專門來認真聽議程做筆記的了。以前還是窮學生的時候，票價真的是一筆負擔，覺得錢花下去了一定要聽到一堆沒聽過的東西，然後努力做筆記，回去打開筆記把不懂的東西全都查一遍，全部都學起來，這樣才能值回票價。

現在反而是相反，很多議程在講的東西可能都已經聽過，主要還是來跟久久沒見到的人講講話、更新一下彼此的近況。以前也不太喜歡聽一些經驗分享或是一些和人比較相關的非技術性議程，但出社會幾年後才瞭解到，其實這些才是更為困難的，技術學得起來就有，但經驗是寶貴的，每個人的經驗都是獨一無二的，尤其很多技術採用了以後，在過程中真的會遇到很多問題，能夠聽到別人的經驗分享，就可以避開很多踩雷的狀況，因為別人已經先踩過了，這些往往都是技術推廣議程不會提到的事。

和人相關的部份也是如此，工作幾年後就會瞭解到，和人的合作才是有最多不確定性的環節，除非是完全獨立工作者，否則勢必會面對到這些問題，這也是為什麼好像大家都有在跑敏捷開發，但每個人的敏捷都長得不一樣的原因，因為所有跟人相關的規則，都會隨著團隊規模大小、團隊成員組成、團隊合作方式、...等等各種不同的因素有所改變，沒有一個能夠完全適用的通則。聽聽別人怎麼做的及其成果，再來檢視和比較一下自己的團隊狀況，往往可以獲得一些新的想法。

現在參加 Conf 都不太開筆電了，以前總覺得聽每個議程都要認真做筆記，共筆總是寫得很勤，往往都寫到筆電沒電。現在則是專注看著投影幕與講者的動作、聆聽其話語，一邊思索如果是自己的話會怎麼做，在心裡不停的對話與詢問自己，將觀念與想法與自己的經驗互相比較，然後再度內化成自己的，像是一種再度淬煉過程。聽不懂的東西比以前少了很多，也更能夠在聽到講者的描述後，想到其他類似的狀況或更快能夠想出這類作法的優缺點。

當面更新朋友們的近況

和好幾年沒見的月湖學長見了面，更新了一下彼此的近況，但其實大部分的時間都是我在講，而且講了很久，還有點耽誤到了吃午餐的時間，覺得對他有點不好意思。主要就聊到去年很期待地去了矽谷一個月，分享一下自己在那邊看到的狀況以及自己覺得的優缺點，也聊到了彼此共同認識在矽谷工作的工程師朋友們，再聊到後來發現自己把矽谷想的太美好了，去完反而沒有那麼想去矽谷工作了。月湖也稍微跟我說了他在公司擔任 Scrum Master 的狀況，聽起來是為了敏捷相關議程來的。

和幾年沒見的寬寬學長見了面，大學做專題的時候真的很感謝他的帶領與幫忙，當時我因為缺錢兼了兩份程式相關的校內工作忙得焦頭爛額，常常在專題開會的時候沒跟上預計的進度，最後做出來的結果我也覺得不甚滿意，到現在覺得有點對不起學長，但還是在過程中學到了很多跟資安相關的知識。尤其學長因為平時涉獵的書籍與論文很多，遇到不懂的地方往往可以得到他指點方向。從那時算起來也過了 6 年了，也恭喜寬寬學長終於從博班畢業，現在也繼續在他熟悉資安領域努力著，上上一份工作離職後也很熱心地推薦我去他現在就職的公司，但老實說我畢業後就自覺到能力不足（資安方面真的遇過太多比我有天份、比我強又比我努力的人了。）再加上相較之下我還是比較喜歡處理網路系統架構，就沒有往資安領域前進了。但也沒有不碰資安，SRE 的系統管理和網路管理依舊會碰到，只是就沒有那麼專精了，純粹就是興趣而已。

因為上一份工作有第一次當了主管的經驗，和現在也是管理職的學長聊了許多擔任管理職會遇到的問題，真的是有很多心有戚戚焉的部份。也聊到了大學時和我一起做專題的小樂，向學長更新了一下小樂的近況，小樂後來跑去中國從事電腦視覺相關工作，後來也當上了小主管，近期離職後也有和他通過一次電話聊到了當小主管的很多狀況與經驗，彼此交流了許多不同的處理方式。管理職真的是個很可憐的職位，不時要面臨上頭突如其來的壓力，得做好向上管理，另一方面又要對帶的人認真負責，一沒處理好問題往往就讓你帶領的人對你的信心產生動搖，在合作上就會產生一些阻力。上班總是要忙著處理公司和組員的事務，還要怕自己的技術能力退步，得用下班的時間自己找時間精進能力。

「這麼多人都在努力著，以前的自己好像也是這樣，只是不知道從什麼時候消失了，該找回那種感覺了吧。」

這次參加完是有感覺人生被充電的。老實說離職無業的這一年滿迷惘的，主要是發現自己幾年前列的中短期目標基本上全部達成了，一瞬間失去了許多實現目標的動力。再加上前一份工作 Burnout 實在太嚴重，所以就給自己一年的 mini-retirement，一邊慢慢回血，一邊思考人生的下一步該怎麼走。

紀錄一下這次我比較有印象的議程：

• 兩個與遠端工作有關的議程
  • 聽下來覺得跟平常有在追蹤的遠端工作相關消息講的差不多，沒有什麼覺得特別需要紀錄的。
  • 我個人的想法是，遠端工作現階段還是比較適合軟體工程師還有文字工作者，因為這兩者本質上都已經很習慣使用文字工作，所以對於使用文字將細節紀錄下來的非同步方式，相較於其他職位來說會比較習慣許多，以軟體公司來說大概就是工程師與網路行銷這兩個職位吧。
  • 以我自己在上一份工作中部份遠端工作的經驗來說，光是軟體公司團隊裡頭的設計師或專案經理在討論事情時，用遠端方式討論的效果還是有差，視訊會議討論的時候在即時互動上的回應還是會有一段惱人的延遲。更別說像是業務這種需要透過觀察對方的表情上的細節來工作的人了。
  • 只就軟體業來說我個人是樂見其成就是，像我這種很需要個人專注空間與時間且不喜歡被打斷的軟體工程師來說，遠端工作真的滿適合我的，在上一份工作有嘗試過的感覺也是如此，但非工程師的職位我就不敢說了。
    • 當然如果之後找到了全職的遠端工作的話，實際工作模式勢必得再進行細部調整，畢竟很多人最不適應的就是上班與下班的界線變得非常模糊，反而沒有因此覺得工作比較輕鬆。
  • 至於遠端工作會不會成為主流？我個人覺得不會。除非疫情影響一直持續下去，一旦影響消失了，我覺得大多數公司還是會回到原本習慣的模式，畢竟人類的習慣實在太難改變了，也不是所有矽谷的員工都想遠端工作。除非遠端工作這件事對公司來說可以顯著降低成本，或是突然出現像廣告那樣改變人類的行為模式的突發事件，畢竟也是有公司擔心遠端工作會降低團隊間的凝聚力而導致一些負面影響。
    • 但這裡有一點我覺得可能有希望的是 AR 跟 VR 的相關應用，如果持續發展到可以像實體見面互動那樣順暢的話且裝置成本降低到一定程度的話，可能有機會，但有很多需要接觸到實際材質的設計工作還是很難變成遠端工作的形式。
  • 而關於有些公司給遠端工作的薪水會因為地區而降低這件事，感覺就回到如何談薪水的部份了，只是是遠端工作版本的。
  • 我個人是覺得這部份還是會暫時是可以接受遠端工作的資方和勞方，只是數量可能會因為疫情變多。至於受迫於疫情影響而開放遠端工作的公司，在疫情影響結束後會不會因為各方面的考量，裁掉無法配合本地工作的員工，我覺得也不無可能。
• 《優雅的 API 設計 - 後端工程師必修的設計模式》
  • 主要就講 HTTP 跟 REST，HTTP 的部份有講到許多人在設計 API 會忽略或不夠清楚其用意或細節的 Status Code
    • 200 OK, 201 Created, 202 Accepted, 204 No Content 的使用時機
    • 401 Unauthorized, 403 Frobidden 的差異
      • 401 是沒登入的狀態
      • 403 則是已登入但被禁止
    • 設計的時候多參考一下 MDN 應該就可以避免掉這種問題，如果一開始設計沒有注意到的話，等到 API 已經跟人對接的時候才改就會有點麻煩，如果是自家的團隊倒還好處理，如果是提供 API 給使用者或是外包公司的話，就會比較麻煩了。
  • HATEOAS
    • Hypermedia as the Engine of Application State
    • 你的 REST 不是 REST？ | iThome

      • Level 3 更進一步地在 Level 2 的約束基礎，加上 Hypermedia，資源除了 URI 作為識別之外，還必須能表示出本身接受的操作，以及與其他資源間的關係──後者有點類似 HTML 頁面超鏈結的概念，你可以從目前 HTML 頁面得知有哪些頁面能夠前往，但 Level 3 不是只有超鏈結，除了知道如何前往其他資源，還要能夠知道它是什麼、如何對它操作等。

      • Roy Fielding 是在其論文第五章 REST 中，提到 hypermedia as the engine of application state，簡稱 HATEOAS，而 Leonard Richardson 的模型中，達到 Level 3 成熟模型的應用程式，必須支援 HATEOAS。

      • 按照 Roy Fielding 的觀點，沒有 HATEOAS 約束，就不是REST，然而，Leonard Richardson 也說過，一開始就要討論 HATEOAS 的概念是困難的，因此他才從 HTML 與 URI 開始，開展了他對成熟模型的區分。

      • HATEOAS 是個概念，實際上，如何從一個資源得知其他的資源？該採用哪個格式？格式中該採用哪些識別名稱？這需要有實作規範，而 HAL (Hypertext Application Language) 是實作規範之一，採用特定的 JSON 格式、ATOM (RFC 4287) 鏈結語法概念，來描述某些協議等（JSON API 雖然也可包含資源關係，然而畢竟不像 HAL 就是為了支援 HATEOAS ）。

      • 某些程度上，雖然從回應中，可以大致得知資源的使用方式，然而，並不是採用 HATEOAS 概念，就不用寫文件了，HATEOAS 當中，雖然可以呈現的資源間的關係及操作描述，並不包含商務邏輯上的語意，因為，它考量的是，客戶端可以依這些描述，自動因應資源的變化，而不是客戶端可以在沒有文件的狀況下，理解資源能達成哪些商務邏輯。

• 《Bug Bounty 打雜經驗談 - Bug Hunter 如何協助軟體安全性》
  • Bell–LaPadula model

    • The Bell-LaPadula security model is directed toward access control and is characterized by the phrase "write up, read down" (WURD). Compare the Biba model, the Clark-Wilson model, and the Chinese Wall model.

    • 簡單來說就是安全層級低的不可以修改安全層級高的
  • 看到 BambooFox 這幾年愈來愈厲害然後也開始打 Bug Bounty 覺得滿好的，作為極早期參與的一員，也有和寬寬學長聊到這件事，但後來是真的沒花那麼多時間在資安方面了。
• 《從遺留架構動身前往 Kubernetes 的世界》

  • 「以前的我不相信 10x 工程師，直到我遇到了 1/10 工程師。」

  • 「為什麼要改用 K8S？」

    • 雖然提到了是因為要開啟歐洲區服務，為了 GDPR 不能使用原本在美國的伺服器，但其實還是因為身為 10x 工程師的技術顧問一句話（一顆隕石？）才開始用。如果單純只是為了要 Infrastructure as Code，用 Ansible 應該也是可以辦到。
    • 我自己的經驗是如果伺服器不需要特別編譯特殊的套件以及是使用 GCP 的話，用 Kubernetes 會方便很多，尤其 GCP 跟 Kubernetes 畢竟都是 Google 自家的產品，整合來說比在 AWS 上好很多。

  • 「K8S 預設的 liveness probe 和 readiness probe 很完整」

    • 踩過雷以後就不這麼覺得了，基本上都要特別設定過，不然 rolling update 的時候服務會有 downtime。
  • Legacy code 之所以被稱為 Legacy，不是因為其存在時間長久，而是後人（包含自己）能不能簡單看懂，如果不能，那就跟歷史遺跡一樣，被稱為 Legacy。
• 《在這個不大不小的醫院，DevOps 欲怎樣落地》
  • 居然有醫院在 RPi 4 上用 Docker 跑 MQTT, InfluxDB 耶，第一次聽到，好潮。

  • 「為中小型醫院開源一個通用性的專案」

    • 這個夢想有點偉大，滿敬佩的。
  • 這個議程應該是我在 MOPCON 2020 裡頭最佩服的一個，對我來說，在薪水不高的南部務實地一步步改進醫院裡頭相對落後的資訊系統，真的是需要很強烈的情感才有辦法達到。而且每個環節都闡述得滿清楚的，最後更是用那張最常見的 DevOps Infinity Graphic 把各個環節用到的工具都清楚地列出來，真的有一股莫名的感動油然而生且令人肅然起敬。
  • 看到標題的時候想說在南部該不會是用台語講全場吧！但後來不是，不過講者自己也有說他希望自己之後可以挑戰用台語講。
• 《讓繁體中文自然語言處理落地的困難與機遇》
  • BERT
    • “BERT Explained: State of the art language model for NLP” by Rani Horev
    • 原來現在處理 NLP 有新的技術了，2018 年的論文，Google 團隊提出的。
    • 有人提到這個 Pre-trained + fine-tune 的方法推出後又開始相關論文大爆發了一陣子XD
  • Demo 的部份覺得滿有趣的，讓 AI 理解一段文字後，再提出問題讓 AI 來回答，這方法感覺在閱讀長文的時候很有用，但就像講者自己提到的，要商業化的話感覺還是找不太到著力點。
    • 我自己唯一想到的就是賣那種閱讀測驗的解題程式，直接拍照以後用 OCR 轉成文字，然後餵給 AI，之後再把答案直接回答出來，這樣一堆學生應該會超級開心，不過大概會被學校禁用。 lol
• 矽谷工程師講古（某一場 unconference）

  • 「台積電根本是美積電。」

    • 「裡面有多少專利跟技術都是美國的你們知道嗎？」

  • 「台灣的軟體業是參天巨木旁的矮樹。」

    • 「我也不知道該說好還是不好，因為我自己是非資工本科，因為厲害的都去硬體業了，所以我才有幸透過職訓局跟培訓營進入這個產業。」

    • 我剛剛才恍然大悟，這個參天巨木，不是一株而是兩株：電機、醫科。

  • 「你們現在哪懂什麼是真正的 Full-Stack 工程師，真正的上古 Full-Stack 工程師要進光華商場像進菜市場一樣，挑主機板的眼光跟挑魚一樣。要會開得利卡載主機，還要記得買包乖乖看個黃道吉日把主機上線。」

• 《那些年我參與智慧電網相關專案血淚史》
  • 這就是讓你突飛猛進的好隕石們 （X
    • 

  • 「我後來才發現 Issues 都被記錄在他們的筆記本或是嘴巴上。」

    • 真的要用 Issue Tracker 啦，不然後面接手的人真的會吐血。
  • Common Information Model (electricity)

    • a standard developed by the electric power industry that has been officially adopted by the International Electrotechnical Commission (IEC), which aims to allow application software to exchange information about an electrical network.

  • 聽這場真的很有當初第一份工作的既視感，基本上遇到一模一樣的問題，不過當時真的很享受一步一步把問題都解決完的成就感。
    • 「解決問題或者被問題解決。」- 工程師的日常
• 閃電講居然有人講 Neo4j
  • 想起兩年前也是因為上一份工作第一次碰到 Graph Database 開始用 Neo4j，因此踩了一陣子的雷。雖然後來那個專案沒多久就收掉了，但還是有學習到相關的知識。
  • 當時 BlueT 有提到 Cayley 和 Dgraph，然後說 Dgraph 易用度大勝。
• 《從開源專案的社會參與到建立第一筆產品收入》
  • 找了三位 Side Project 都算小有知名度的講者來一起聊聊有關 side project 的各種大小事，我覺得滿好的。
  • 尤其台下學生不少，即便是已經在工作的工程師我也很推薦自己找個 side project 來做。
  • 就像講者們說的，side project 完全不需要多偉大多厲害，基本上都是從生活中出發，遇到自己覺得不方便的事、想要更節省一點時間，然後開始思考可不可以用寫程式來幫忙辦到這件事，很多時候你覺得麻煩的事情別人也可能遇到一樣的問題，自己弄了一個這樣的 side project，就有可能剛好幫助到有和你相同問題的人。
  • 而且也完全先不用想這個 side project 到底要不要提供給別人用這件事。像我自己的個性就會覺得這樣很麻煩，開始有人使用後，就會有人覺得哪邊不好用但你自己覺得沒差，或是提出一些你自己可能完全不需要的功能，如果沒有做好這方面的心理準備的話，就會覺得很麻煩。我自己是都自己寫自己用，然後開源，反正有意見你就自己把程式碼拿去改來用吧，怕人拿去商用的話就用最嚴格的 GPLv3 license 就好。
  • side project 真的是一個很適合拿來實驗的場所，我自己也是很常看到一些新工具、新的 CI、新的測試套件、Python 新版的功能或新的寫法，就會拿 side project 來試。畢竟如果每次看到新東西都要從頭寫個小東西來試也很花時間，如果有一個 side project 就很方便，等於你有一個現成的且熟悉的實際案例可以拿來馬上實驗。
  • 我個人的方式是，把生活中當下遇到不方便然後覺得可以自己寫程式來幫忙處理的事情，用個人的 issue tracker 把當下的想法和覺得可行的方式紀錄下來，給自己開票。等到放假不知道要做什麼的時候，就可以從裡面找看看有沒有想寫的東西，先搜尋一下看看有沒有人已經實作，有的話就看看能不能拿來改來直接用，沒有的話，就自己開始寫一個。
  • 至於 side project 的商業化，我覺得一般來說不太會想這樣做，因為商業化實在有太多細節不是一個人可以完成的。
    • 不過我自己跟 3 個講者不同的是，我還滿在意被大公司抄襲拿去商業化的，最近就有看到一個疑似 AWS 抄了一個 GitHub 上有 1.2萬顆星星的 project 變成 AWS 其中一個產品的消息，如果這事情發生在我身上的話應該會滿不爽的。
    • 如果是要找到新的商業模式的抄襲可能相對比較難，但像這種把你的 side project 直接抄去加在舊有商業模式上拿來賺錢，相對就容易很多了。

在腦袋裡頭一閃即逝的閃電講題目

• 擁抱隕石！隕石成長法大揭秘！
  • 壞的隕石讓你燃燒殆盡
  • 好的隕石讓你突飛猛進
• 週五到底要不要部署？
  • 不要再吵了，先週休三日，我們就可以改成討論週四要不要部署了。（誤
  • 部署啦，哪次不部署？反正壞了就加班啊。
  • 敢不敢在週五部署啦？不敢的話你的公司就是爛、你的團隊就是不夠好、你的程式碼品質就是差、你的測試就是不夠完備、你的架構就是不夠精簡！

會後感

MOPCON 參加下來給我的感覺也是學生和新手居多，這的確是件好事。但身為一個已經踏入社會 4 年的人士，真的有點想念在 2015 年已經停辦的 OSDC.tw，議程的深度真的普遍比其他 Conf 深很多，而且沒有太濃厚的商業氣息，只可惜當年參加的我還是個學生，理解的東西還不夠多。現在參加有比較多業界人士的 Conf 總是會明顯感受到濃厚的商業氣息而讓我覺得有點不是那麼舒適。

參加南部的 Conf 很明顯認識的面孔少了許多，加上我的個性本來就不是會主動認識人的那種，和人社交反而會讓我很耗損能量，所以沒那麼多認識的人大概是件好事吧？作為一個默默參與和觀察的會眾好像也就夠了，看到這麼多講者分享自己努力的經驗和過程，就會讓我覺得有被激勵到。

和月湖也聊到了，覺得 MOPCON 不幫會眾訂便當是個不錯的作法，一方面可節省開銷降低票價，另一方面則是可以讓人流回饋給當地的店家，算是一種回饋地方的感覺。不過 COSCUP 在從中研院移出後我記得也已經這樣做了，畢竟中研院那邊能吃東西的選擇實在太少，無法負荷這麼多人。

最後的座談會議程也滿棒的，近幾年的 conference 都有加入這部份，我覺得挺好的。以前不懂的時候總是覺得不過就是在台上聊天，又沒有講什麼太多技術相關的東西，真的很浪費時間。但現在則是很珍惜不同的人回答同個問題會有不同的答案這件事，因為那些都是對方獨一無二的珍貴體驗，都是可以拿來參考的素材，出了社會的世界跟在學校是完全不同的，沒有一個標準答案，所有的事情都得靠自己去嘗試，這時候有其他人的經驗可以參考真的是件很幸福的事，反而還要感謝別人願意花時間講出來分享。

每次去完 Conference 都會覺得「影響力好重要啊」，但我還是只想寫寫給自己看的 blog，但也許哪一天會改變也說不定。