Toomore Blog

CONCOM 是 Con ference for open com munities，簡單來說就是 研討會的研討會 ，主要參與者大部分來自近年各大研討會的工作人員，每兩年舉辦一次，來分享近況與一起解決問題。 這次是我第一次參加 CONCOM，也在 小講座大平台 階段 分享 志工服務平台起源與未來的目標。 志工服務平台在 2022 年 COSCUP 辦完之後有特別針對程式部分作強化，目前全部都有標上 typing hint、另外也使用 fastAPI 加入第一版的 API 。之後行政組也希望持續協助其他組別在行政流程上的優化與志工在平台上參與的深度。 在休息時間交流時，大部分其他研討會或是社群在志工管理的部分都面臨到類似的問題，但也有表達出希望可以使用 COSCUP 志工服務平台的可能。但目前平台還是主要以 COSCUP 的情境在使用，未來是否可以規劃一個通用的版本這可能要再想一下該如何著手。 另外一個滿感興趣的分享是請到 g0v 的 Isabel 來分享揪松團如何聘人與社群分工，或是說職工與志工如何協調執行？我覺得比較有印象是說怎樣吸引志工來參與，因為其實我們大部分都面臨到如何留住志工人才的問題，她有提到一個想法，就是讓活動「 好玩 」就夠了，滿足「 好玩 」這件事情就幾乎可以解決很多問題了。 而志工主要是將事情 捏出社群的樣貌 後交給職工去執行這樣子的運作方式。當然還是有一個比較赤裸的問題是職工要找社群背景比較好還是不見得呢？答案是找非社群的夥伴會比較好，主要是志工與職工的界線或是會模糊分不清楚所造成的問題。 總之 Isabel 的分享帶給我滿多的想法，有些觀點有讓我思考到志工服務平台之後的方式該往哪去發展會比較好。 已經很久沒有聽議程參加研討會的感覺了，好像真的花滿多時間在舉辦研討會而沒時間學習些什麼了，但覺得 CONCOM 應該要每年都舉辦才對，兩年辦一次太久了 XD

今年行政組比較早起動，我們現在已經開始招募 2023 年的志工夥伴，這次行政組組內依舊有三個任務組別：庶務組、開發組、招募組。 大約在 11 月的時候，COSCUP 2022 的團隊有聚集到花蓮兩日一夜的 Team Building(?)，主要是討論或是集思廣益目前我們有哪些待解決的問題。 那時候有稍微意識到一個問題是 COSCUP 每一屆團隊的組長都滿會把事情處理完，但這就會發生一個問題，對於新加入的夥伴會沒有依循或是參考的東西可以上手。換句話說，我們可能越來越無法讓新夥伴知道我們在做什麼了！ 這其實是滿嚴重的問題，簡單來說就是要勤勞一點的寫文件或是成果報告之類的，讓大家可以尋覓或是順藤摸瓜的方式去瞭解一個活動的籌劃過程。 所以這次我大算慢慢建立關於行政組的籌備過程，慢慢的記錄到本來是「志工平台」開發用的 文件 裡。  大會是使用 HackMD 來紀錄，但我比較喜歡好看一點的版面，另外 HackMD 有點破碎，如果沒有一個有系統的整理或是索引，其實也不太好對於新夥伴的引導閱讀。 總之，這一屆先從「 行政組 」來編寫，之後再看看怎樣用一個大會版本的 COSCUP/docs 之類的！

選取、標記 最近將專案進行多國語系的製作，需要將字串挖出來在需要翻譯的字串前後標記 _('') 、 {{_('')}} 或 {{_("")}} 。 在 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 的變數可以 參考這裡 。 透過這樣的方式，除非遇到較複雜的句子（可能參雜一些語法或樣式）需要調整外，就可以加快把字框出來！

週六去參加 GDG Taichung 舉辦的 DevFest Taichung 2022 活動，地點辦在東海大學推廣部。每次去台中大部分都去東海大學附近，所以漸漸也滿熟悉那一帶的環境。 這次去幫忙活動攝影，活動早上八點半開始，很早起床從台北出門，前一天還太晚睡覺，早上睡過頭。 活動是一整天的議程與工作坊，一整天下來我記得有一場特別留下來聽完，是關於 UIUX 的議題，最主要是 講者 [1] 所介紹的案例剛好都是有在使用的服務，所以特別有興趣瞭解講者是如何處理專案的過程。 之前在做志工平台的時候，UIUX 只能用 bulma 這種風格型的套件來處理，但就只能算堪用，實際要將這些元件結合起有意義的引導或行為又是一大課題要面對，只能感嘆缺乏這項技能很惋惜！ 之後來找找看看有沒有相關的入門書籍可以惡補一下。 UIUX knowhow - 實務工作中的應用、黃翎(Lynn) / AJA 大予創意 / UI

Github 在 2022/10/20 發布 一項更新，可以在 web 介面下管理 Actions Workflows 的 caches。 不過在此之前，還沒將 actions cache 加到目前使用的專案中，趁這次調整使用看看。手邊有一個以 Python 為主要語言開發、 Poetry 為套件管理的專案，預期可以將「相對穩定」的套件 cache 起來。 基本的會使用到的 actions： actions/checkout@v3 另外有兩種方式可以支援 cache 的使用 actions/setup-python@v4 actions/cache@v3 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') }}

在 2022/09/30 上線部署的版本中，包含了平台上使用 API 的可能。 API 的功能是之前大家敲碗很久的項目，但因為抽不出時間來處理、規劃，在 2022 活動結束後先列為重點開發項目之一。 API 文件可以 參考這裡 ，目前主要完成 API Token 取得的方式，或是透過 OpenAPI 介面 簡單使用。 API 建構是使用 fastAPI 框架來實作，而 fastAPI 使用 Pydantic 作 dataclass 的結構化，所以也趁這一次，把一些原本寫的不太好的底層架構也一併改為 Pydantic 的表示方式。 目前用了 fastAPI 後，我覺得 flask 真的好像沒有跟上一些 Python3.8 之後的特性，有點可惜。 目前的開發節奏會調整成每兩個禮拜釋出一版做迭代衝刺，另外看能不能在 10/15 的 MOPCON 招募一下 App 的開發者！