跳到主要內容

發表文章

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@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') }}

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)、一位最後 退出 (退出的這位後面再提發生什麼事情)。 如果以結果論,活動當天的人力配置稍嫌不足,還好三位組員都是很熟練的志工,很多突發狀況都能夠提出很棒的解決辦法,然後再來詢問我的建議後去處理。 這裡我想要提出一個簡易的流程,關於組員如何處理事情的流程。組員發現問題 → 可以如何解決的方案 → 詢問組長討論 → 執行。 這個流程讓我今年覺得比較放心,因為我有設定一個目標是希望組員的「參與感」可以

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 這語法每次都寫的好不順手。 在文件的部分有一章節是引導如

離開了六年!

最後一篇的文章停在 2016/01/17,看起來 Google 真的把 Blogger 給放棄了,雖然我也差不多6年沒有寫東西了,但這裡一點新功能都沒有,好慘! 本來想用看看 wordpress ,但目前看起來整個走 收費模式 (如果自己不架設),然後這裡真的也保留很多文章,要搬不搬頭也有點大,決定還是繼續在這裡寫下去。 剛好最近離職後比較有空閒的時間,還是重捨寫 Blog 習慣比較好! 恩,這篇就這樣當作一個新階段的開始!

show