2024-11-25 13:14:26
要怎麼在不重新下載東西的情況下，把一整包 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
2024-11-24 00:56:03
純粹的 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 簡潔和清晰一點。
2024-11-22 22:27:38
把 pan.blog 重新翻新了一下，主要是：
其實 pan.blog 我前一陣子就想重新整理了，只是一直沒有動力來做。
不過 ChatGPT 開始支援 Web Search，讓我覺得「把文章寫在 Google 可以索引的地方，之後也能幫到自己」，
再加上 X 的走向讓人不太樂觀，所以我打算把一些有價值的東西用 Blog 的方式留存。
這個新 Blog 有把一些我覺得值得留存的東西從老的 Hexo 站移過來，之後也會寫一些技術短篇～
2023-04-14 02:23:00
打擾了各位，想問一下如果想要透過特殊選材的話，有大量的競賽經驗/表現，還是有實作成品，哪個會比較好？
我當年特選是以實作為重的。我踩過坑了，所以我能告訴你 不要想著你的實作可以獲得教授青睞。
通常在高中年紀做的作品——比如自己寫的內核、寫的網站服務、寫的系統，都是垃圾。教授早已閱歷無數，你引以為傲的作品，可能對他們來說就是 print("Hello, World") 而已。除非你的作品真的很知名——就比如說你造出了一個每個月使用人次高達 10 萬的東西，要不然說實話，你只是證明「你對這個領域有很淺薄的研究」——但一點都不特殊。當然，假如你能把你的作品做出相當大的特色（你造出了一個 O(1) 的旅行者問題演算法），甚至你還因此發上期刊，這就另當別論。
所以既然大家都是菜雞，那教授要怎麼選出「特殊」的？當然是量化下來的能力。不要看不起 APCS 還有一堆競賽：這個是你唯一可以拿來說嘴的了。你可以在這些競賽中大談你是如何把基礎能力用到極致，用到把其他競賽者打爆的——其實這樣也有一點「專案」的效果了，都是基礎能力應用，但至少教授可以知道「你的基礎能力確實超越同儕。」
總結來說，不要以為你的專案用了些什麼「設計模式」、「物件導向」，就可以變成教授人人都想搶的人才——說實話，你的專案除非有名到教授想要知道，否則教授只會覺得你只是寫了一堆比較進階的 Hello, World。乖乖競賽，把你的能力用來打爆其他人，這才是特選成功的法則。
當然你也可以繼續拿你的專案當作是特選的題材，但就警告你不要害到自己一所學校都沒上然後學測還爆掉。我有個開發了一堆專案、甚至還算知名，而且還經常參與各種社群活動的朋友——他的 4 間特選全部爆炸，學測失利，最後分科上了間沒有契合他興趣的科系。我自己幸好還有些比賽，所以勉強上了間普普通通的大學，但也是挺後悔自己當初叛逆沒去考 APCS。
原文寫在《中學資訊討論群 CISC》：https://discord.com/channels/755456963265036309/1078522742057480232/1096319706664804394。
2022-12-16 08:02:06
最近在做一個有簡歷功能的個人網站。
大學的網頁課程要上傳一個 styled 的 profile。起初兩週我想了許多種方案，比如「直接把之前超前進度的作業1 改成亮色系，然後繳出去」、「用 ChatGPT 幫我寫一份 styled 的網頁。」但我覺得都太敷衍，再加上當時有一些事情要處理，所以我就先放著——直到繳交前 3 天。
繳交前夕，我突然有個打算：「要不要試著超前上課進度2？」如果作業還繼續用 Vanilla JS 也實在太沒有新意，而且我這時突然想到一個很有意思的主意：做出一個可以分享給別人（也方便自我介紹）的簡歷。
我面試的時候常常被問到「你的作品集在哪裡」、「你的簡歷在哪」。我是有個人形象頁面，但幾乎沒有說明自己的經歷：這也就導致沒有人——包括我自己——知曉我究竟參與了哪些專案、製作了哪些 projects，以及設計了什麼東西。如果能藉由這次作業的機會打造出一個可以分享給別人（也方便自我介紹）的簡歷，那肯定會讓這個作業更有價值。
「做一個好看的簡歷網站」和「用現代前端工程標準製作專案」，便成為這個專案的兩大目的。
專案本身沒有用到傳統意義上的敏捷開發，但我在這個專案實踐了一些敏捷開發的「滾動式」精神。
「滾動式」的概念其實就是「慢慢達成趨近完美」：應該要先專注在核心的部分（比如這次的專案就是以個人介紹為核心），然後再慢慢地把其他的東西（比如作品集、開源貢獻）加進去。重構也是：一開始不用追求到完全的 best practice——細節可以留待日後再來改善，但如果為了細節而導致核心部分的缺失，便是本末倒置。
雖然這麼說，但我仍然想追求完美主義：我很討厭承認一個長得超醜、超難維護的 snippet 是我寫的，我希望可以帶給閱聽者極其完美的體驗。正是因為如此，這次的作業依然是花了相當多的時間重構。可是比起細節，內容的完善明顯比較重要——更何況我因為這個 project 荒廢了太多其他的事情，排除掉學習到的經驗，投入的時間成本其實早就超出了這個專案可以帶來的價值。
**「時間安排」，在無論是在專案管理、還是日常生活的方方面面都十分重要。**安排任務的優先級、並且專注在完成最核心的事情，為專案的管理之道。我覺得我時間管理一直都做得不太好——想法太多，時間卻是有限的——是時候逼迫自己從無限的想法中切分，而不是讓一個想法佔據掉太多的時間。
寫網站的時候我就有和好幾位朋友共同研討「如何做出舒適的設計」，並且共同討論如何做出優秀的動效設計。這次我就和一位有著不小聲望的專業前端工程師和設計師，共同討論網頁每一處細節的設計。
另外，網站在開發後期也有遇到以及在遇到效能問題時與幾位更專業的前端工程師共同查出問題。在網頁撰寫末尾，我就有遇到一個很嚴重的效能問題：滑到卡片的時候會嚴重掉幀，但 Profile 裡面並沒有指出具體是哪個函數導致問題。後來和朋友討論之後，鎖定是 shadow 動效導致的問題，而在解決之後，效能問題也就臨刃而解。
之前看過一篇文章，說：「Best Practice 是總結出來的，不代表一開始就得導入這些東西。」工程更像是事情在遇到事情或需要擴充時的解決方法，而不是在沒必要的時候就無止境導入的玩意。
另外，不完美是難免的：像是我的 codebase 就重構了數次，即將發起的一次是發現自己違背了 Tailwind CSS 的 Atomic CSS 理念，打算全數改回 Component 的形式。重構是個學習，不要害怕不完美——不完美才能學習，學習才能成長。
除了上面提到的 bad smell 之外，我還打算加上一些更多 GitHub 的元素（比如個人的貢獻狀況、以及貢獻圖表）。不過把 bad smell 做完之後應該就是直接 promote 然後暫時放著了——有更多更重要的專案得做啊。
2022-10-18 13:37:00
第一次看到沒有 commit package-lock.json 的 repo
事實上這樣在 library 上沒有什麼問題。Lockfile 的追蹤有個小原則：
假如函式庫有用到諸如 ESLint 的工具，追蹤一下可以避免之後設定開發依賴的麻煩， 所以像 NPM 官方就是推薦 無論如何都追蹤 lockfile。
不過也有預設不推薦在 library 情境下追蹤 lock 的例子，比如 Rust 的 Cargo 套件管理器2。不過 Cargo 的開發工具主要都是作為 submodule 安裝在系統中，通常不會跟著 repo 一起追蹤，所以不太適合放在一起比較。
不過要注意：這時候的 lockfile 就不是追給下游應用程式看的，主要是為了自己開發方便。
package.json 通常不是描述固定的版本，而是一個版本區間：舉個例子：你可能在 package.json 裡面描述 vue: "^2.4.0"，但實際上 NPM 幫你選了 2.7.13。這個行為是可以預測的，可以參考 NPM 官方的 Semver 計算機：https://semver.npmjs.com。
