Toomore Blog: 2022

CONCOM 2022 x OCF 參加後感想

CONCOM 是 Conference for open communities，簡單來說就是研討會的研討會，主要參與者大部分來自近年各大研討會的工作人員，每兩年舉辦一次，來分享近況與一起解決問題。

這次是我第一次參加 CONCOM，也在小講座大平台階段分享志工服務平台起源與未來的目標。

志工服務平台在 2022 年 COSCUP 辦完之後有特別針對程式部分作強化，目前全部都有標上 typing hint、另外也使用 fastAPI 加入第一版的 API。之後行政組也希望持續協助其他組別在行政流程上的優化與志工在平台上參與的深度。

在休息時間交流時，大部分其他研討會或是社群在志工管理的部分都面臨到類似的問題，但也有表達出希望可以使用 COSCUP 志工服務平台的可能。但目前平台還是主要以 COSCUP 的情境在使用，未來是否可以規劃一個通用的版本這可能要再想一下該如何著手。

另外一個滿感興趣的分享是請到 g0v 的 Isabel 來分享揪松團如何聘人與社群分工，或是說職工與志工如何協調執行？我覺得比較有印象是說怎樣吸引志工來參與，因為其實我們大部分都面臨到如何留住志工人才的問題，她有提到一個想法，就是讓活動「好玩」就夠了，滿足「好玩」這件事情就幾乎可以解決很多問題了。

而志工主要是將事情捏出社群的樣貌後交給職工去執行這樣子的運作方式。當然還是有一個比較赤裸的問題是職工要找社群背景比較好還是不見得呢？答案是找非社群的夥伴會比較好，主要是志工與職工的界線或是會模糊分不清楚所造成的問題。

總之 Isabel 的分享帶給我滿多的想法，有些觀點有讓我思考到志工服務平台之後的方式該往哪去發展會比較好。

已經很久沒有聽議程參加研討會的感覺了，好像真的花滿多時間在舉辦研討會而沒時間學習些什麼了，但覺得 CONCOM 應該要每年都舉辦才對，兩年辦一次太久了 XD

COSCUP 2023 行政組招募

今年行政組比較早起動，我們現在已經開始招募 2023 年的志工夥伴，這次行政組組內依舊有三個任務組別：庶務組、開發組、招募組。

大約在 11 月的時候，COSCUP 2022 的團隊有聚集到花蓮兩日一夜的 Team Building(?)，主要是討論或是集思廣益目前我們有哪些待解決的問題。

那時候有稍微意識到一個問題是 COSCUP 每一屆團隊的組長都滿會把事情處理完，但這就會發生一個問題，對於新加入的夥伴會沒有依循或是參考的東西可以上手。換句話說，我們可能越來越無法讓新夥伴知道我們在做什麼了！

這其實是滿嚴重的問題，簡單來說就是要勤勞一點的寫文件或是成果報告之類的，讓大家可以尋覓或是順藤摸瓜的方式去瞭解一個活動的籌劃過程。

所以這次我大算慢慢建立關於行政組的籌備過程，慢慢的記錄到本來是「志工平台」開發用的文件裡。

大會是使用 HackMD 來紀錄，但我比較喜歡好看一點的版面，另外 HackMD 有點破碎，如果沒有一個有系統的整理或是索引，其實也不太好對於新夥伴的引導閱讀。

總之，這一屆先從「行政組」來編寫，之後再看看怎樣用一個大會版本的 COSCUP/docs 之類的！

vscode surround select by using snippet

選取、標記

最近將專案進行多國語系的製作，需要將字串挖出來在需要翻譯的字串前後標記 _('')、{{_('')}} 或 {{_("")}}。

在 vim 底下要這樣操作有點辛苦，最後還是開啟 vscode 來看看有沒有相關的解決辦法。找到一篇提到可以自訂 snippet 並對應快捷鍵組的方式使用。

Command + Shift + P 找到 "> Preferences: Open Keyboard Shortcuts (JSON)"

然後填入以下內容：

    {
        "key": "shift+cmd+a",
        "command": "editor.action.insertSnippet",
        "when": "editorTextFocus",
        "args": {
            "snippet": "{{_('${TM_SELECTED_TEXT}')}}"
        }
    },

key 的部分就是對應到鍵盤快捷建，建議可以搭配 "Preferences: Open Keyboard Shortcuts (JSON)" 看看有沒有重複使用的部分。

args.snippet 裡面使用到 TM_SELECTED_TEXT 的變數可以參考這裡。

透過這樣的方式，除非遇到較複雜的句子（可能參雜一些語法或樣式）需要調整外，就可以加快把字框出來！

DevFest Taichung 2022 - GDG Taichung

週六去參加 GDG Taichung 舉辦的 DevFest Taichung 2022 活動，地點辦在東海大學推廣部。每次去台中大部分都去東海大學附近，所以漸漸也滿熟悉那一帶的環境。

這次去幫忙活動攝影，活動早上八點半開始，很早起床從台北出門，前一天還太晚睡覺，早上睡過頭。

活動是一整天的議程與工作坊，一整天下來我記得有一場特別留下來聽完，是關於 UIUX 的議題，最主要是講者^[1] 所介紹的案例剛好都是有在使用的服務，所以特別有興趣瞭解講者是如何處理專案的過程。

之前在做志工平台的時候，UIUX 只能用 bulma 這種風格型的套件來處理，但就只能算堪用，實際要將這些元件結合起有意義的引導或行為又是一大課題要面對，只能感嘆缺乏這項技能很惋惜！

之後來找找看看有沒有相關的入門書籍可以惡補一下。

UIUX knowhow - 實務工作中的應用、黃翎(Lynn) / AJA 大予創意 / UI

Github actions cache - Python, Poetry

Github 在 2022/10/20 發布一項更新，可以在 web 介面下管理 Actions Workflows 的 caches。

不過在此之前，還沒將 actions cache 加到目前使用的專案中，趁這次調整使用看看。手邊有一個以 Python 為主要語言開發、Poetry 為套件管理的專案，預期可以將「相對穩定」的套件 cache 起來。

基本的會使用到的 actions：

actions/checkout@v3

另外有兩種方式可以支援 cache 的使用

actions/setup-python

在 actions/setup-python 有兩個參數可以開啟使用，cache、cache-dependency-path。cache 可以為 pipenv、pip、poetry。cache-dependency-path 則是指定套件安裝檔的位置：

pipenv: Pipfile.lock
pip: requirements.txt
poetry: poetry.lock

詳細的設定檔範例可以參考文件，雖然 actions/setup-python 提供一個非常簡易的設定，但如果想要更多自訂的快取設定，可以試試原生的 actions/cache

actions/cache

actions/cache 是最原生的功能，可以透過 path、key 來指定快取的位置。以 Poetry 為例，在 Poetry 相關的預設路徑下，可以針對 ~/.local, ~/.cache 來建立快取。

如果你習慣將環境資料夾裝在專案底下（virtualenvs.in-project=true）也可以將 ./.venv 也建立快取位置。

而 key 的命名可以使用 hashFiles 來比對 poetry.lock 檔案差異值來建立。

所以依這樣這樣的規則，我們可以有三個快取建立：

poetry-venv-${{ hashFiles('\*\*/poetry.lock') }}
poetry-local-${{ hashFiles('\*\*/poetry.lock') }}
poetry-cache-${{ hashFiles('\*\*/poetry.lock') }}

接下來只要 poetry.lock 沒有變動，都會使用快取來加快流程。

COSCUP Volunteer 開發近況

在 2022/09/30 上線部署的版本中，包含了平台上使用 API 的可能。

API 的功能是之前大家敲碗很久的項目，但因為抽不出時間來處理、規劃，在 2022 活動結束後先列為重點開發項目之一。

API 文件可以參考這裡，目前主要完成 API Token 取得的方式，或是透過 OpenAPI 介面簡單使用。

API 建構是使用 fastAPI 框架來實作，而 fastAPI 使用 Pydantic 作 dataclass 的結構化，所以也趁這一次，把一些原本寫的不太好的底層架構也一併改為 Pydantic 的表示方式。

目前用了 fastAPI 後，我覺得 flask 真的好像沒有跟上一些 Python3.8 之後的特性，有點可惜。

目前的開發節奏會調整成每兩個禮拜釋出一版做迭代衝刺，另外看能不能在 10/15 的 MOPCON 招募一下 App 的開發者！

COSCUP x KCD 2022 結束後紀錄

📝

COSCUP x KCD 2022 終於在 7/31 順利舉辦完了。想說趁現在還有點記憶，就來記錄一下活動的過程。

籌備期間

這次大會第一次開會的時間是在 2022/02/23，之後就每兩週開會一次，記得好像只有第一次開會在摩茲工寮，之後大家都很習慣的在線上開。

這次有被邀請擔任總召組成員之一，COSCUP 因為人數越來越多，所要注意到的事務也越來越廣，總召組成員多一點比較好。這次的組成會是現任的三位（球魚、Denny、我）加上前任兩位（Singing、nfs）當顧問，但其實都有跳下來一起幫忙完成事務。

至於行政組，在今年的目標是可以找到組長人選交接，我比較想要專心作「志工服務平台」上的開發。所以今年算是行政和總召兩邊，但比較多在行政這裡處理事務。

開會方式

大會在七月前是每兩週在週三晚上線上開會，會議內容會使用 HackMD 紀錄。而行政組也是每兩週、一樣在週三晚上線上開會，但兩會交替著開會。

行政組這裡是用 Trello 追蹤事件，這個版好像在 2019 年有嘗試使用，那時候大會各組有想要試試在 Trello 上管理各組的工作任務，但老實說，反而我們因為有很固定的大會開會模式，也就不用太管到各組怎麼處理，大會的會議比較像是工作匯報與尋求他組協助的地方。

我是覺得 COSCUP 開會都（從以前到現在）還滿有效率的，大家也都知道要講哪裡重點。

不過大會的會議記錄是用流水帳的方式紀錄，越到活動開始前的資訊量會越來越大，有時候其實會忘記有些服務其他組別已經建立好了，或是在漫長的會議記錄中找曾經提過的事情。我想可能要有人去整理關於組的事項列表或服務清單之類的，在針對某項事務可以快速連結的路徑。

2022 的行政組

今年的行政組三位是固定班底（鯉魚、刺蝟、Choupi）、一位跨組機動（Julia）、一位最後退出（退出的這位後面再提發生什麼事情）。

如果以結果論，活動當天的人力配置稍嫌不足，還好三位組員都是很熟練的志工，很多突發狀況都能夠提出很棒的解決辦法，然後再來詢問我的建議後去處理。

這裡我想要提出一個簡易的流程，關於組員如何處理事情的流程。組員發現問題 → 可以如何解決的方案 → 詢問組長討論 → 執行。

這個流程讓我今年覺得比較放心，因為我有設定一個目標是希望組員的「參與感」可以提升。之前在行政組的時候我會不小心把事情都處理完，但會讓組員不知道要做什麼，所以特別在這次希望能改善這問題。

中途退出的組員

結論是「溝通」問題，在滿多情況下沒有與我討論而做對的事情，這比較麻煩一點在於要再花很多時間去告知「如何修正」。

這其實不太正確的做法，我是覺得應該要在動手做之前就確定好方向（包含需求面），而不是做出一個需求涵蓋不夠或是方向不對的事情再「要求」對方給予「如何修正」的建議！

如果今天已經是成為「組員」的情況下，「組長」會是你必須與他保持「溝通」暢通的途徑。（而且是「至少」、相對於組員與組員之間）

這次的狀況歸納為「無法溝通」、「無法預期行為」為由、請對方先行退出。

2022 的總召組

關於今年協助總召組的部分，我個人認為能協助的事情不多，可能沒有很清楚總召的職權範圍到哪個部分。

不過我自己是比較信奉 COSCUP 已經成為各社群辦理年度活動的大平台原則，希望我們能激勵各社群來 COSCUP 「一起」舉辦研討會。

而且各組人力有限，也不太可能我們直接起一軌主辦該社群議程。所以在這個原則下，縱使是我們感興趣的議題對應到的社群、也應該激勵、激發他們能成長到來 COSCUP 申請議程軌與舉辦！

我覺得關於 COSCUP 議程最後演變成「由各社群」負責一天的議程軌的這個概念，目前還是滿多人不太清楚。

簡單來說，COSCUP 就像一個大型的 outlet 商場，我們提供空間、好的活動場地、把會眾聚集的能力，剩下的就由各社群去提供「專業」、「特色」的議程與會眾互動！

2023？

明年、或是說從此刻開始，還是會多花一點時間在「志工服務平台」。目前平台還有很多需要改進的空間，尤其是這次回到實體活動的部分。

另外在電子報系統也需要與志工服務平台整合，還有全服務平台的 API 建立，希望在 2023 年能看到比較「明顯的」改善。

COSCUP Volunteer 志工平台歡迎來貢獻！

在參與 2022/06/18 g0v hackath50n 之後，目前 COSCUP 志工平台是呈現可以被貢獻的狀態了！

大概在五月份開始，把專案盡可能的調整看起來像是 Open Source 的專案狀態。在找資料的時候好奇如何才可以算是一個 Open Source 專案，發現原來 Github 有特別為這個主題建立一系列的指引手冊「Open Source Guides」

這個指引手冊寫的很棒，覺得應該要有人來帶個讀書會之類的一起導讀或是分享！

那這兩個月一直到 g0v 活動前，有哪些完成的事項呢？

首先第一個是改用 Poetry 取代 pip，雖然這個取代法有另外一個副作用（等等後面補述），但整體來說為了讓其他貢獻者能夠不要在為套件管理搞得很麻煩，尤其是近幾年大家對 pipenv 的失望！

接下來是使用 Github Actions 來跑 pytest, pylint, mypy 或是試 build images。

Coding Style

Coding style 的部分是用 pylint, autopep8 來處理，這裡有另外一套 black 常常會拿來比較，而且 vscode 也預設使用 black，這樣就有點尷尬了，之後可能要來評估一下轉移使用 black 的差異，雖然我是比較喜歡 ' 大於 "

mypy 是用來輔助作型別檢查的工具。目前在 ./models, ./module 底下的文件都補上 typing hints，Python 也特別註明 typing hints 的註記不會影響 runtime，也就是你亂標也沒差，雖然有些人可能會覺得標成這樣就不像是 python 這個語言的特點，但 Open Source 的專案是希望越多人貢獻越好，程式碼的可讀行性越清楚越好。

Development Docs

最後是文件的產生，選擇使用 MkDocs，並套用熱門的 Material for MkDocs 樣式。mkdocs-material 這樣式真的好用到沒話說，樣式內建的套件也都相當實用。之前用過很老牌的 sphinx，但 reStructuredText 這語法每次都寫的好不順手。

在文件的部分有一章節是引導如何在本地端建立開發環境，在本地端的開發會使用 docker compose 的方式建立環境，在本地端建立開發帳號。

Poetry 的副作用

在 production 的環境中會先包一個 base image，這裡會把必要的套件先安裝好，提供給 application 或是 celery 使用。但改用 Poetry 的時候會多出約 200 MBs 的容量，必須手動刪除一些放置在 _vendor 底下用不到其他版本的 python。在 Github 上面也有類似的處理方式。

目前還是與 pip 比較還是增長約 100MBs 的差異，這個之後再來研究 poetry 內部運作的方式。