Pan in the Nutshell

前言 要怎麼在不重新下載東西的情況下，把一整包 code 包含依賴本身，移到新的地方呢？ 舉個之前遇到的例子：我想在學校部署一個用 Python Streamlit 框架寫的程式碼評測工具，但是在測試部署時發現一個非常頭痛的問題：學校的連外網路特別慢，導致 pip 幾乎無法正常完成安裝。在嘗試了 pip download 以及一些打包方案後，發現 Streamlit 的執行最終都會缺幾個元件導致啟動失敗，最終都還是需要用 pip install 補全依賴。最後我想到一個 workaround：拿其他同學的 Windows 筆電先把程式準備好，再把準備好的程式複製到新的地方。 不過要怎麼「準備好程式」然後「複製到新的地方」呢？ Python 不像 Go 和 Rust 可以編譯成靜態的執行檔，也不像 Node.js 和 PHP 有著各個專案獨立的 node_modules 或 vendor 資料夾，可以搬到其他地方而保持程式的依賴正常運作。不過 Python 有個很類似 node_modules 的東西——Virtualenv，搞不好我們真的能像 node_modules 一樣直接把整組專案複製到其他電腦上，專案就能跑了。 但是 Stack Overflow 的文章又提到「venv 通常不能直接複製到其他電腦上」。 In general you can’t copy virtual environments anywhere, Docker or otherwise. They tend to be tied to a very specific filesystem path and a pretty specific Python installation. If you knew you had the exact same Python binary, and you copied it to the exact same filesystem path, you could probably COPY it in as-is, but the build system would be extremely fragile. 1 ...

tl;dr 使用 Zeabur 部署 Blog 使用 Cloudflare R2 當圖床，Cloudreve 管理 使用 Umami 進行網站資料統計 選擇性部署 CodiMD / Hedgedoc 方便行動裝置編輯 常見的方案有什麼問題 純粹的 GitHub Pages 架設靜態 Blog，搭配 Google Analytics（或 Cloudflare Web Analytics）雖然是最便宜的選擇，但對於媒體管理上和草稿編輯還是不太方便。 統計工具方面，除了 Google Analytics 之外，幾乎沒有什麼功能特別強大，可以看單一使用者流向的統計工具。 圖床方面，媒體放在 GitHub repository 上會造成 repo 迅速膨脹，但又擔心其他免費圖床如 Imgur 會倒閉。而且 Imgur 不能上傳圖片以外的資源！🥺 草稿編輯方面，GitHub 沒有提供一個比較好的 Markdown 書寫工具，要獲得好的書寫體驗，就需要在電腦上用 VS Code 等等的 Markdown editor 書寫，局限了在手機上完成草稿或者編輯文章的能力。 怎麼解決？ 作為一個 self-hosted 跟偏好 Cloud Native 方案的使用者，我會這麼規劃我的 blog： 這次我使用的 Blog SSG 是 Hugo，速度確實快，而且 template 比 Hexo 簡潔和清晰一點。 ...

把 pan.blog 重新翻新了一下，主要是： 換成 Hugo，提升編譯速度 圖床放到 CDN 上，不跟 GitHub 放在一起了 其實 pan.blog 我前一陣子就想重新整理了，只是一直沒有動力來做。 不過 ChatGPT 開始支援 Web Search，讓我覺得「把文章寫在 Google 可以索引的地方，之後也能幫到自己」， 再加上 X 的走向讓人不太樂觀，所以我打算把一些有價值的東西用 Blog 的方式留存。 這個新 Blog 有把一些我覺得值得留存的東西從老的 Hexo 站移過來，之後也會寫一些技術短篇～

打擾了各位，想問一下如果想要透過特殊選材的話，有大量的競賽經驗/表現，還是有實作成品，哪個會比較好？ 我當年特選是以實作為重的。我踩過坑了，所以我能告訴你 不要想著你的實作可以獲得教授青睞。 通常在高中年紀做的作品——比如自己寫的內核、寫的網站服務、寫的系統，都是垃圾。教授早已閱歷無數，你引以為傲的作品，可能對他們來說就是 print("Hello, World") 而已。除非你的作品真的很知名——就比如說你造出了一個每個月使用人次高達 10 萬的東西，要不然說實話，你只是證明「你對這個領域有很淺薄的研究」——但一點都不特殊。當然，假如你能把你的作品做出相當大的特色（你造出了一個 O(1) 的旅行者問題演算法），甚至你還因此發上期刊，這就另當別論。 所以既然大家都是菜雞，那教授要怎麼選出「特殊」的？當然是量化下來的能力。不要看不起 APCS 還有一堆競賽：這個是你唯一可以拿來說嘴的了。你可以在這些競賽中大談你是如何把基礎能力用到極致，用到把其他競賽者打爆的——其實這樣也有一點「專案」的效果了，都是基礎能力應用，但至少教授可以知道「你的基礎能力確實超越同儕。」 總結來說，不要以為你的專案用了些什麼「設計模式」、「物件導向」，就可以變成教授人人都想搶的人才——說實話，你的專案除非有名到教授想要知道，否則教授只會覺得你只是寫了一堆比較進階的 Hello, World。乖乖競賽，把你的能力用來打爆其他人，這才是特選成功的法則。 當然你也可以繼續拿你的專案當作是特選的題材，但就警告你不要害到自己一所學校都沒上然後學測還爆掉。我有個開發了一堆專案、甚至還算知名，而且還經常參與各種社群活動的朋友——他的 4 間特選全部爆炸，學測失利，最後分科上了間沒有契合他興趣的科系。我自己幸好還有些比賽，所以勉強上了間普普通通的大學，但也是挺後悔自己當初叛逆沒去考 APCS。 原文寫在《中學資訊討論群 CISC》：https://discord.com/channels/755456963265036309/1078522742057480232/1096319706664804394。

背景 最近在做一個有簡歷功能的個人網站。 大學的網頁課程要上傳一個 styled 的 profile。起初兩週我想了許多種方案，比如「直接把之前超前進度的作業1 改成亮色系，然後繳出去」、「用 ChatGPT 幫我寫一份 styled 的網頁。」但我覺得都太敷衍，再加上當時有一些事情要處理，所以我就先放著——直到繳交前 3 天。 繳交前夕，我突然有個打算：「要不要試著超前上課進度2？」如果作業還繼續用 Vanilla JS 也實在太沒有新意，而且我這時突然想到一個很有意思的主意：做出一個可以分享給別人（也方便自我介紹）的簡歷。 我面試的時候常常被問到「你的作品集在哪裡」、「你的簡歷在哪」。我是有個人形象頁面，但幾乎沒有說明自己的經歷：這也就導致沒有人——包括我自己——知曉我究竟參與了哪些專案、製作了哪些 projects，以及設計了什麼東西。如果能藉由這次作業的機會打造出一個可以分享給別人（也方便自我介紹）的簡歷，那肯定會讓這個作業更有價值。 「做一個好看的簡歷網站」和「用現代前端工程標準製作專案」，便成為這個專案的兩大目的。 「滾動式開發」：逐步趨近完美 專案本身沒有用到傳統意義上的敏捷開發，但我在這個專案實踐了一些敏捷開發的「滾動式」精神。 「滾動式」的概念其實就是「慢慢達成趨近完美」：應該要先專注在核心的部分（比如這次的專案就是以個人介紹為核心），然後再慢慢地把其他的東西（比如作品集、開源貢獻）加進去。重構也是：一開始不用追求到完全的 best practice——細節可以留待日後再來改善，但如果為了細節而導致核心部分的缺失，便是本末倒置。 時間安排的重要性 雖然這麼說，但我仍然想追求完美主義：我很討厭承認一個長得超醜、超難維護的 snippet 是我寫的，我希望可以帶給閱聽者極其完美的體驗。正是因為如此，這次的作業依然是花了相當多的時間重構。可是比起細節，內容的完善明顯比較重要——更何況我因為這個 project 荒廢了太多其他的事情，排除掉學習到的經驗，投入的時間成本其實早就超出了這個專案可以帶來的價值。 **「時間安排」，在無論是在專案管理、還是日常生活的方方面面都十分重要。**安排任務的優先級、並且專注在完成最核心的事情，為專案的管理之道。我覺得我時間管理一直都做得不太好——想法太多，時間卻是有限的——是時候逼迫自己從無限的想法中切分，而不是讓一個想法佔據掉太多的時間。 勇於發問，明白自己的不足 寫網站的時候我就有和好幾位朋友共同研討「如何做出舒適的設計」，並且共同討論如何做出優秀的動效設計。這次我就和一位有著不小聲望的專業前端工程師和設計師，共同討論網頁每一處細節的設計。 另外，網站在開發後期也有遇到以及在遇到效能問題時與幾位更專業的前端工程師共同查出問題。在網頁撰寫末尾，我就有遇到一個很嚴重的效能問題：滑到卡片的時候會嚴重掉幀，但 Profile 裡面並沒有指出具體是哪個函數導致問題。後來和朋友討論之後，鎖定是 shadow 動效導致的問題，而在解決之後，效能問題也就臨刃而解。 不要過度工程化 (over-engineering) 之前看過一篇文章，說：「Best Practice 是總結出來的，不代表一開始就得導入這些東西。」工程更像是事情在遇到事情或需要擴充時的解決方法，而不是在沒必要的時候就無止境導入的玩意。 另外，不完美是難免的：像是我的 codebase 就重構了數次，即將發起的一次是發現自己違背了 Tailwind CSS 的 Atomic CSS 理念，打算全數改回 Component 的形式。重構是個學習，不要害怕不完美——不完美才能學習，學習才能成長。 目前 App 還會繼續改進的地方 除了上面提到的 bad smell 之外，我還打算加上一些更多 GitHub 的元素（比如個人的貢獻狀況、以及貢獻圖表）。不過把 bad smell 做完之後應該就是直接 promote 然後暫時放著了——有更多更重要的專案得做啊。 ...

原文撰於 Twitter。 撰文初衷 第一次看到沒有 commit package-lock.json 的 repo TL;DR 事實上這樣在 library 上沒有什麼問題。Lockfile 的追蹤有個小原則： 應用程式建議追蹤 lockfile：不追蹤，下次 npm install 就無法確定具體的依賴版本是什麼。 函式庫可以不用追蹤，因為使用者安裝套件時，套件管理器會根據依賴自動選取最適合的版本，而你自己的 lockfile 會被忽略1。不過建議追蹤，見下文。 函式庫「該不該」追蹤 lockfile？ 假如函式庫有用到諸如 ESLint 的工具，追蹤一下可以避免之後設定開發依賴的麻煩， 所以像 NPM 官方就是推薦 無論如何都追蹤 lockfile。 不過也有預設不推薦在 library 情境下追蹤 lock 的例子，比如 Rust 的 Cargo 套件管理器2。不過 Cargo 的開發工具主要都是作為 submodule 安裝在系統中，通常不會跟著 repo 一起追蹤，所以不太適合放在一起比較。 不過要注意：這時候的 lockfile 就不是追給下游應用程式看的，主要是為了自己開發方便。 為什麼「應用程式」就該追蹤 lockfile？ package.json 通常不是描述固定的版本，而是一個版本區間：舉個例子：你可能在 package.json 裡面描述 vue: "^2.4.0"，但實際上 NPM 幫你選了 2.7.13。這個行為是可以預測的，可以參考 NPM 官方的 Semver 計算機：https://semver.npmjs.com。 ...

原文撰於 Dcard。 Abstract 「威注音」是一款主打智慧 🤖、美觀 🎨、高自訂性 🔧，且追求完美  的注音輸入法。正在為錯字百出的選字、操作習慣、簡體輸入，甚至是原廠注音遲遲不修正的 bug 所苦嗎？威注音或許可以讓你對注音打字改觀 🥳。 威注音自己覺得有八個值得你使用的理由（建議搭配宣傳海報閱讀）： 最佳化打字體驗 ⌨️ 還再打出錯字擺出的句子，成為朋友對話之間的笑柄、公司討論之間的尷尬嗎 😅？或許你可以試試看威注音輸入法。 威注音輸入法的詞庫收錄了三千餘條（且持續增加中的）常用詞組，因此輸入常用詞彙時可以減少選字的次數 🙌🏼。 目前威注音的詞庫仍在持續更新、拓展，因此威注音將會變得愈來愈智慧。如果你有任何想納入官方詞庫的常用字彙，也可以在這篇底下（或到 GitHub 下）留言提議加入～ 可以自訂語彙 💬 覺得每次輸入自己或朋友的名字，或者是科系名稱都得選字很煩嗎？威注音提供了一套非常簡單的自訂詞彙新增方式，簡而言之就是「選字後選取，按 Return 存檔。」可以看看下方影片的操作： 原生繁簡輸入、零轉換 蘋果內建的輸入法「不支援簡體輸出模式」——想像每次跟對岸朋友洽談事情，每一句都得使用特色選單裡面的簡體轉換功能轉換 😱……就算你不煩，觸控板應該也挺累的 😰。 威注音除了提供原生的簡體輸出模式，輸出簡體只要切換輸入法即可一步到位之外，威注音的詞庫也是簡體中文與繁體中文各自一份的：方便簡體中文母語者「在不熟悉台澎金馬的審音與習慣讀音的前提下」也可以順利使用威注音敲字。 P.S.: 威注音的繁體中文輸入模式可以使用「轉換至康熙繁體」「轉換至 JIS 繁體」功能。 精緻選字窗（框） 我覺得這是威注音和其他競品比較下的最直觀第一感受了。當其他競品的選字窗還停留在 Windows XP 的土裡土氣、甚至沒有暗色模式的時候；威注音的選字窗已經和蘋果原生相當相似，甚至可以啟用「IMK 選字窗」來得到和原生注音同款的介面效果 🧑‍🎨。 IMK 選字窗可以在威注音的「開發道場」開啟。不過威注音自己做的田所矩陣選字框，我覺得已經很接近蘋果的 UI 效果了。 極高自訂、可玩性 你想用 Shift 切換中英文嗎？預設開啟 🎉；你只想用「中/英」切換鍵切換語言嗎？也可以關閉 Shift 的切換。 你想要輸入罕見到原廠注音打不出來的字嗎？威注音可以讓你啟用「CNS11643 全字庫」，在安裝正確字體後即可直接打出符合政府編碼標準的罕見字 🎉。 覺得選字窗的候選字太小，看不清楚嗎？威注音支援把選字窗文字放到原先 6 倍大 (96px) 的大小 🎉。 ...

Motivation src: https://twitter.com/bystartw/status/1568217424658583553?s=61&t=UVzhpuQaGcgZkGpySz_yVQ Noticing some developers are confused with “Linter” and “Formatter,” I made a simple figure showing what messages Linter and Formatter prefer to print. Thanks to @nonoesp for his incisive introduction to Linter and Formatter!

src: https://twitter.com/bystartw/status/1567200310430662656?s=61&t=UVzhpuQaGcgZkGpySz_yVQ vChewing 出了 2.4.0 SP2 了！🎉 自己覺得 vChewing 是除了官方注音之外，長得最好看（因為有 IMK 加持），而且功能跟選字功能也很棒的輸入法，真的很推薦想嘗試第三方輸入法的朋友試試看！（連結見引文） Figure 1: vChewing 提交很活躍！ 資安疑慮 另外關於 vChewing (下稱 vC) 的資安或隱私疑慮： vC 在 2.3.0 之後引入 Apple 官方的沙盒機制，因此只要你沒有授予授權，輸入法本身是看不到你的資料夾的。 雖然我沒有完全閱讀 vC 的 src，但至少它的 Shift 是靠旁敲的方式偵測的，不是記錄所有鍵盤輸入 vC 只有更新和網站相關有連到個人站台 稽核方式 如果有興趣稽核 vChewing 外連的情況，可以自己 clone 回來用 regex 查，或者是直接用這個第三方網站看： sourcegraph ** 如果還是信不過（認為作者會混淆連結）的話，也可以自己掛一個抓包軟體偵測 vC 的所有請求啦…… 雖然我是找不到除了更新以外的請求 code：sourcegraph

撰文原由 在 威注音 2.1.0 SP1 的更新日誌 下看到了這麼一段話： Interface Builder 給每個標籤的命名都是隨機的，手動改起來又低效又容易改壞，對多語言本地化而言簡直是天災。 事實上在 WWDC21 中，Apple 就為 Xcode 推出了一項可以解決這項痛點的新功能：「使用編譯器擷取字串」。與早期透過從 Swift 原始碼拉取可翻譯字串，經常漏掉一些字串的方式不同——這個功能會先編譯原始碼，然後從編譯出的檔案中判斷可以翻譯的字串。 啟用功能 這項功能在新專案是預設啟用的，但舊專案可以 opt-in：點開專案設定，進入 “Build Settings”，展開所有功能（All），尋找 “Swift” 然後找到 Localization 的 “Use Compiler to Extract Swift Strings”，將其設定為 Yes 即可。 匯出字串 開啟之後的國際化與本地化方式，跟先前會不太一樣。以往需要手動改 strings 檔案，現在可以先到 “Product” > “Export Localization…” 匯出編譯器擷取出的所有字串： 接下來指定匯出的路徑，然後等待 Swift 完成編譯並擷取字串。若是從舊專案 opt-in，擷取字串的過程中可能會拋出一些錯誤，這個時候就得修正（如果只是警告的話也可以忽略）： 翻譯流程 接下來就可以進入選擇好的資料夾，使用 Xcode 點開對應語系的 xcloc 檔案： ...