Wolf 的小小部落格

換個筆電有什麼好開心的？

Thu, 19 Feb 2026 00:40:00 GMT

簡單來說：啊就很薄很輕

為什麼要換筆電？

簡單來說，舊的筆電續航真的太糟糕了

我上一臺筆電是在疫情的時候的線上上課時買的，還記得當時筆電的價格漲漲漲，漲到內顯筆電也要 1 萬多快兩萬，~~雖然現在記憶體的漲幅好像也差不多~~。那是一臺 Lenovo 的 IdeaPad Gaming 3 的樣子，一顆 AMD 的 Ryzen 5 5600H，8G DDR4 記憶體（後來自己擴到 16G），NVIDIA 的 GTX 1650 顯示卡，實打實的電競本。

在線上上課的時候其實問題都不大，因為都在家裡接著電用，GPU 還可以撐著大部分的遊戲跟一般的日常使用，變向的把一臺筆電當桌機在用

但後來疫情結束了，開始有機會出門了，筆電的續航就變得很重要了。這臺筆電的續航大概只能撐 2-3 小時，對於我這種偶爾會帶筆電出門的人，就變得非常麻煩

那臺筆電有一顆差不多 45Wh 的電池，乘上後來的電池容量約 83%，得到了 37.35Wh，除上一般功率約 15W 的話，大概只能撐 2.5 小時，這還是在不開 GPU 的情況下，如果開了 GPU 的話，功率可能會飆到 30W，那續航就更慘了

加上後來特殊選才上了，想想以後上大學似乎也是要一臺新筆電，所以就決定換一臺了

問題來了，該選什麼筆電？

跟以前需要玩遊戲的需求不一樣，我目前的需求差不是這樣：

可以讓我用上差不多 4 小時不充電
可以不用 Windows
有好音響跟漂漂的機身

如果你拿這個條件去問別人，差不多有 95% 的人會推薦 MacBook Air，畢竟現在好像拿 3 萬左右就可以買到，加上 Apple M 系列晶片的超低功耗，續航也非常好，外觀也不錯，還有 macOS 這個系統可以用... 嗎？

Nah no macOS :(

雖然我也很想用 macOS，但我對 Apple 的生態系統真的沒有什麼興趣，尤其是他們的軟體跟服務，對我來說完全沒有吸引力，甚至有點反感，所以我不太想買 MacBook Air，雖然他在其他方面的表現都很符合我的需求

我想要一臺筆電，用的是 MacBook 的硬體，跑的是 Linux 系統

macOS 系統包括但不限於：

開發者不知道為什麼都好喜歡推出付費功能
自訂的範圍有限
Liquid Glass 好醜

找什麼 Windows 筆電呢？

綜合剛剛的 MacBook No No 跟之前的需求，我就開始找 Windows 筆電了，主要是看一些輕薄商務本，因為他們通常有比較好的續航跟好看的外殼，反正不要不小心買到 Arm 處理器的都應該可以裝 Linux

找了一找之後，看到了這臺 Zenbook S14，他的最高配幾乎完美的符合了我的需求

Intel Ultra 7 258V
14 吋 16:10 的 OLED 120Hz 螢幕
32G 記憶體
1T PCIe 4 的 SSD
鋁合金的機體

重點是他有 72Wh 的超大電池！拿朋友的 S16 的時候也感覺他的音響不錯，雖然說 S14 的音響可能沒有 S16 那麼好，但應該也不會差到哪裡去

缺點是這個：

這個是 2026 漲價後的價格，原本是 49900 的樣子，反正是 4 萬 9 附近

這個價格已經可以去買一臺很好的 MacBook Air，呃對

水水水水貨耶

後來在朋友的推薦下，找到了這家大陸筆電代購商，價格差不多是這樣：

雖然說這個價格比官方的便宜了不少，但還是有點小貴，但想著「反正這臺筆電我想買很久了，現在有機會買到就買了」，就不小心下單了

至於為什麼不去京東自己買是因為筆電出問題還有人可以找，跟那時還沒用過京東

下單之後等了又等，差不多兩週之後賣家說處理好了，後來安排面交後拿到機器之後就迫不及待的開箱了，外觀真的很漂亮，機身也很薄，拿在手上感覺很輕，螢幕也很亮，音響也不錯，總之第一印象非常好

只是後來用一用之後發現這臺的耳機孔有撞到的樣子跟上蓋的部分有一些些塗層剝落，雖然說不太明顯，但還是有點小失望，只不過後來賣家有退錢跟後來去華碩維修光感器的時候他們也有幫我把這些小問題處理掉了

Btw 華碩的保固真是神奇，水貨還是可以走全球保固

Windows to Linux

這臺拿到時還是 Windows 11，我用了差不多 3 小時之後就開始灌了 Linux，比較特別的是這次不用 Arch 從頭來，用了 CachyOS 這個 Arch 的衍生版，安裝過程非常簡單，幾乎沒有什麼問題，安裝完之後也幾乎沒有什麼問題，唯一的問題就是一些 ASUS 的驅動有點麻煩，底下列出幾個問題：

光感器沒偵測到

這臺的螢幕上面有一個光感器，原本應該是可以自動的根據目前的環境亮度更改螢幕亮度跟色彩的，但在 Linux 上面這個功能完全沒辦法用。原本以為是驅動的問題，開了 Windows 轉了又轉，找了 SensorsExplorer 還是讀不到

後來拿去了 ASUS 維修，維修回來說好了，變成 Windows 正常但 Linux 還是讀不到，才發現這臺的感測器得另外裝 Intel SensorHub 的驅動，網路上有大佬已經把 .bin 檔案拖出來，把它丟進去 /usr/lib/firmware/intel/ish/ 重開就偵測得到光感器的 IIO 裝置ㄌ

音響變得超爛

這臺的音響在 Windows 底下聽起來還不錯，但到了 Linux 上之後，少了 ASUS 跟 Dolby 調的 EQ 跟 DSP 之後，整個聲音變得超級平，聽起來扁扁的，低音也玩了個捉迷藏消失

後來的解法是裝 Easy Effects，經過一番 EQ 博鬥之後把低音弄回去了，雖然說聲音還是沒有 Windows 上面好聽，但至少不會爛到哪裡去

吐槽一下，Easy Effects 的作者不知道是撞到還是啥的，說了個他討厭 GTK 之後版本 8.x.x 後面的全部都用 Qt，整個介面變得醜到天邊

這臺目前在舊一點的 Kernel 可能還沒有 module 支援，但有聽說過裝 sof-firmware 可以解決掉沒聲音的問題

TLP 降功耗跟頻率

我自己原本從舊電腦就習慣在不接電的時候降平臺功耗跟改 CPU 的 scaling governor 來延長續航，以前用 Ryzen 5 5600H 的時候，極限降頻會感覺到非常明顯的卡頓，但在這臺 Zenbook S14 上面，降頻之後的效能還是非常不錯的，幾乎沒有什麼卡頓的感覺，甚至在一些比較吃 CPU 的工作上面，降頻之後的效能還是比之前的筆電好很多

個人認為可能是 258V 的效能本來就不錯，降了之後沒啥差別，溫度差不多則是落在 45 度左右

用了一陣子之後

用了一陣子之後明顯感覺到的是續航真的不錯，雖然比不上 MacBook 現在的機型，它還是贏過市面上差不多 80% 的 Windows 筆電。電池充到 100% 之後差不多可以撐 5 ~ 7 個小時（看 YouTube 與 coding 混合用），如果純 coding + Spotify + Discord + 瀏覽器差不多應該可以用到 5 個小時

Intel 這顆畢竟還是 amd64 的處理器，發熱量四捨五入也是蠻猛的，不接電用還好，一接電之後 scaling governor 就會直接變成 performance，CPU 沒事找事做，溫度有時候會跑到 50 幾

跑個遊戲

至於跑遊戲的話，這裡測試用神奇的方法在 Linux 上跑絕區零的效果還行，用這顆 Arc 140V 的內顯可以跑到中畫質差不多 40 ~ 50 禎，是可以玩的範圍。這個月蠻夯的終末地就爆了，用 Windows 下只能跑到 10 來禎，而這是在最低畫質下跑

總歸來說這臺不是遊戲本

Local LLM!

雖說沒獨顯也不是遊戲本，這臺的內顯倒好像蠻適合跑 local LLM 的。這裡用了 intelanalytics/ipex-llm-inference-cpp-xpu 這個 Docker image 來跑 Ollama

呃為什麼不直接跑 Ollama 是因為 Intel 做的支援有點爛，死活沒法調用 GPU 甚至是 NPU 來跑模型，後來發現這個 image 還是最方便跟穩定的作法

不想用這個 Docker image 也可以用 LM Studio，它可以用 Vulkan 來調用 GPU 作計算，但效能沒上面 Docker image 用的 SYCL 好

然後抓一個 Ollama 的 client oterm 來用，跑起來差不多是這樣

這裡沒測出一個 token 需要多久，一開始跑的速度體感跟 ChatGPT 差不多，後面會越來越慢就是

至於這臺 CPU 說有內建的 NPU 到現在還不知道得怎麼用，而且不知道哪裡說好像現在只有 Windows 有支援？

總結

沒啥好說的，就輕薄商務本，續航不錯，外觀也不錯，Linux 也能裝，缺點就是價格有點小貴，不過如果你想要一臺輕薄商務本的話，這臺 Zenbook S14 還是蠻值得考慮的

Astro: 過了兩年

Tue, 17 Feb 2026 22:20:00 GMT

前幾週看到了 Cloudflare 丟了一大筆錢給 Astro 的消息，突然想到了我網站也用了好久好久的 Astro，想來點回顧

回去翻以前的 package.json，最早的一個 commit 說我當時用的是 Astro 2.9.6，找了找 2.9.6 的 release date，好像是 2023/7/29 發的版本，算一下也過了兩三年ㄌ

Astro 改了什麼

其實 Astro 我個人覺得他現在的更新速度已經有些些的變慢了，但他還是我看過 major version 翻最快的網頁框架，從當時的 2.x 版本一路跳到現在的 5.x 版本，這中間經歷了不少改變，從新功能到舊有的改進，Astro 在這塊還是做的很好

View Transitions API

我最印象深刻的還是當時 Astro 加進了當時只有 Chrome 有的 API View Transitions API，這個 API 可以讓網頁在切換頁面的時候有更平滑的過渡動畫

當時 Astro 直接把這個功能內建進去，我只記得我看到 Demo 的時候覺得超級酷，後來就敲了敲程式碼讓我的網頁也能用上這個功能

哦 View Transitions API 目前已經被更多瀏覽器支援了，像是 Firefox 的使用者現在也可以看到這個炫泡的動畫

View Transiton 現在在 Astro 裡面叫做 <ClientRouter />

i18n routing

在 Astro 3.5 版本的時候，他們加入了一個心的功能，i18n routing，這讓要寫多語言網站的開發者可以更輕鬆的寫出多語言的網頁

Astro 這個新東西基本上把正常多語言需要的 routing 的工作轉到框架層面去做，開發者只需要專注在網頁的撰寫與設計即可

在 Astro 4 中，他們把 i18n 的 routing 邏輯更加完善了一次，讓開發者可以定義預設語言跟加入了一些好用的變數幫助頁面知道現在的語言

做半套的 i18n

雖說 Astro 的確有加入 i18n，但我個人覺得他 i18n 只做了一半，也就是 routing 的部分

如果要寫更多更複雜的網頁，可能還是需要像是 astro-i18n-aut 這種神奇的套件來處理 template，不然你會像這個網站一樣有這種有點奇怪的檔案結構

src/pages/
├── 404.astro
├── blog
│   ├── index.astro
│   └── [slug].astro
├── index.astro
├── rss
│   ├── blog-en.xml.js
│   └── blog-zh.xml.js
└── zh-tw
    ├── 404.astro
    ├── blog
    │   ├── index.astro
    │   └── [slug].astro
    └── index.astro

如果你找不出問題，這個問題出在如果我要更新檔案的內容，我得開 /src/pages/index.astro 跟 /src/pages/zh-tw/index.astro 這兩個檔案一起改，這在要大改網頁樣式的時候會變得很難搞

超棒的 template generation

哦這個不是新功能，但他真的很棒，我要講第二次

反正如果你用過 React 那類的前端框架，你一定有用過這種語法：

() => {
  const mySuperTitle = "Hello World";
  
  return (
    <h1>{mySuperTitle}</h1>
  )
}

神奇的是 Astro 其實也支援這個語法，你可以把它想成 React 但是沒有 JS：

---
const mySuperTitle = "Hello World";
---

<h1>{mySuperTitle}</h1>

Quick note: 那兩個 --- 的 JS 會在伺服器端跑，底下的是會送到使用者端跑的東西，所以如果你在底下寫 <script>，那串程式碼就會跑到使用者端那邊，這在要寫動態網頁的時候蠻好用的

不小心推一堆人進坑

感覺是因為現在用 Astro 的人也變多了，我身邊越來越多人用 Astro，像是毛哥現在感覺超喜歡用 Astro，甚至開了一個叫做 fastro 的 template

還有其他人也開始用了 Astro，大多數都在部落格網站上：

甚至是一些大公司也開始用了：

Astro 的確帶給了許多開發者快速建站的能力，加上他的入門門檻其實不高，讓很多人都能夠輕鬆的上手。也希望 Astro 未來可以繼續完善他的功能！

特殊的特殊選才

Wed, 14 Jan 2026 23:40:00 GMT

理論上就是一個遲到的特殊選才心得

先講結果

反正在亞洲社會結果好像比較重要，先在這裡曬結果。

學校	科系	結果
國立成功大學	資訊工程	正取 1
國立中央大學	資訊管理	正取 1
私立中原大學	資訊工程	正取 2
國立清華大學	資訊工程	一階沒過 😭
國立陽明交通大學	資訊工程	一階沒過 😭
國立中山大學	資訊工程	一階沒過 😭
國立台南大學	資訊工程	過一階放棄
國立高雄大學	資訊工程	過一階放棄
國立海洋大學	資訊工程	過一階放棄
國立高雄師範大學	軟體工程與管理	過一階放棄

而我最後是選擇去成大，至於為什麼那麼多學校過一階但是放棄，我底下會講

我有什麼經驗

簡單來說，就是一個專案仔

我不喜歡競程，APCS 只有基本的觀念 4 級分實作 3 級分，圖靈計畫什麼的都沒上過。倒是專案做蠻多的，除了這個網站之外還有一些其他專案，目前著重於網頁開發跟一些小工具的開發

現在比較不一樣的是有理解一些硬體的東西，像是電路板之類的，做過了兩三塊自己設計的電路板

另外有參加過幾次黑客松，只是沒有得過什麼獎，要說辦過跟參與籌備的黑客松還比較多

黑客松延伸閱讀：HackIt HackIt 可能有一些問題

備審公開版下載：點這裡

備審檔案較大會比較卡

中央大學面試

中央大學是所有學校裡面跑的算前面的，他是最早停止報名、面試跟放榜的學校。沒記錯的話應該是 10 月就開始報名，寫邀請函

順帶一提，我個人覺得邀請函除非可以找到很特別的人，不然就找學校比較了解你的老師寫就好了

但在中央大學公布簡章之後，我發現了我的資格不符合中央資工的條件：

喔不 APCS 卡到了，那...那去資管吧。資管的條件相對就比較親民 (?)，APCS 剛剛好到我的成績，差不多是這樣：

我個人覺得資管跟資工是都可以，畢竟都是資訊相關的

但根據上不知道幾屆學長的線報，中央資管很偏管理，如果要投下一屆資管特選又喜歡資訊的學弟妹要了解一下實際狀況

中央其實蠻快就公布一階通過的名單，沒意外的進了複試。中央的複試其實跟個人申請很像，也是大多數學校採用的方式，也就是面試

面試詳細內容我忘了，但我記得教授有四五個，但提問的好像只有兩三個教授。我這次面試有做三折頁進去，教授也都有拿走我的三摺頁，可能是覺得蠻特別的，不知道

順帶一提三摺頁是什麼，基本上就是把你自己做成傳單，然後給教授看。篇幅通常一頁，就簡單的帶過一下你是誰做過什麼，特別在哪裡。

面試問題差不多都著重於我的這些專案到底是跟資訊管理裡面的管理有什麼關係，畢竟我做的看起來都像是資訊工程的東西。其中不免俗的問一下你有投什麼其他學校跟為什麼不去資工系

中央的面試是我第一個去面試的，但也是唯一一個沒有請你自我介紹的，蠻神奇

成功大學上機

成功大學以時程來看應該是我第二個去二階的學校，但他比較特別是二階是使用上機考的方式來檢定

~~專案仔狂喜~~

成大的上機考是帶我們去電腦教室，每個人一臺有 Ubuntu 的桌機，給你一個 ESP32 大禮包（不能帶走，傷心）還有一整天的時間，有免費午餐

ESP32 大禮包裡面有三片 NodeMCU-32S，一個 USB 3.0 Hub（他們的桌機好像是 NUC，很少 USB 孔得擴充）跟三條 MicroUSB 的線

考試規章裡面有一條很重要的是電腦不能安裝任何其他軟體，只能用預裝的 Visual Studio Code 跟 Firefox 瀏覽器（忘了 Chrome 有沒有反正我不用），其中 VS Code 也不能裝其他的擴充元件，不然就是違規

哦但 Visual Studio Code 有 Copilot，討厭爛微軟但又喜歡他現在的貼心（

考試內容蠻直覺的，有三個小題，差不多如下：

用 ROS2 跑 eBNN 推論
用 ROS2 跑上面那個東西，但是要用兩片 ESP32 跑，有點像是平行計算
用 ROS2 用三片 ESP32 跑一堆演算法，我記得各是排序、SHA-0 演算法、CRC32這樣，三個要在三片不同 ESP32 跑

至於怎麼評分呢，我個人覺得蠻特別的，成大他們架了一個 GitLab 自架版，給每個人發了一個帳號。帳號裡面有一個 repository，基本上把全部你需要的東西喇在裡面

要提交評分的時候就打你要評哪題，在 commit message 前面放那題的題號，GitLab CI 就會下去跑對應題目的程式碼

我覺得這裡的瓶頸是很多人其實不太會用 GitLab，餘光有看到有人直接在 GitLab Web IDE 複製貼上

其實 GitLab 就在登入之後，先在 Linux 機器上面生一個 SSH Key，然後把 public key 塞進去你的帳號，接下來的 git 操作透過 SSH 即可，不一定要用到 API Key 或是用其他的方式讓 git 記得密碼

因為這屆的 VS Code 裡面有 Copilot，我剛好也有 GitHub Student Pack 的關係，所以就用了一些神奇魔法

eBNN 推論

有點忘記了，但我記得這個 eBNN 演算法他已經有給在 repository 裡面，模型也有，整體來說你的動作就是完成把資料發過去 ESP32 跟在上面跑運算的部分

這題算簡單，但記得要把資料轉成 binary 之類的東西加速傳輸速度，可以拿到滿分

平行 eBNN 推論

這題差不多就是把第一題的程式改成分配給兩個 ESP32 跑，然後把結果收回來，也是可以拿到理論滿分

三塊板子三個演算法

這題個人就覺得比較難了，他繼承了前一題要多塊板子的操作加上額外的演算法需要實作。沒記錯的話他也沒有給排序、SHA-0 跟 CRC32 的演算法

小知識，GitLab 裡面的 README.md 原本好像是寫 SHA-256 還是什麼 512，但 PDF 裡面寫 SHA-0，然後大家都看 README 然後做不出來。改 SHA-0 就正常了

詳細怎麼解我有點忘了，但後來這題得用到 ESP32 上的兩顆核心才跑的比較快，不然其中一種演算法會比較慢。就把核心切成一個接訊息，一個跑演算法本身

這題我就沒有拿到滿分，只有拿到滿分的 95% 還是 90%

成大上機總結

整體來說就是一個想收專案仔的走向，後來放榜總成績是 94.41 這樣，然後拿了一個正取 1

聽說跟正取 2 差 0.02 分，酷斃了

中原大學面試

中原是我眾多學校裡面唯一一個私校，就想如果其他沒上還是可以就近讀，而且中原的資工聽說還不錯

面試前他們給了一個麻布袋，裡面裝了一瓶水，是我見過最豐盛的面試前的禮物包。面試過程其實蠻簡單的，有三位教授，中間那位不提問但旁邊兩位都有提問。

這是我唯二面試的學校之中有問到專業問題的學校，像是問到為什麼用 Docker 而不是用 VM，還有我做過這麼多專案怎麼判定這個專案已經是完成品這樣

Btw, 為什麼不用 VM 是因為 Docker 的 footprint 相較 VM 來說小很多，部署跟維護上會比較簡單

其他學校呢？

說起來蠻糟糕的，但我在中央放榜之後，已經確定保底有中央，~~中字輩以下的學校我都不去了~~。像是台南、高雄、海大這些學校我都沒有去面試

特殊選才好玩嗎？

我個人覺得對於一個在某一個領域來說十分專精的學生來說，特殊選才是一個很好的選擇。特別是在校成績不太好，或是感覺讀書真的不是你的強項的學生

特殊選才強調的是跨越學科的能力，學校看的是你這個人在課業以外闖出了什麼明堂，而不是你在課業上有多優秀。特殊選才好玩的是那個從完全不懂要怎麼做備審，一步一步的到簡章閱讀、投備審、準備面試準備三摺頁再到最後錄取到一間喜歡的學校的這個過程

個人覺得是不用去找標榜「特殊選才衝刺」或是啥鬼的補習班，自己摸索就好。畢竟高中只有一次特殊選才的機會，補習班也不見得能幫你什麼忙

HackIt 可能有一些問題

Tue, 21 Oct 2025 00:35:00 GMT

閱讀前先看

事後 HackIt 有與我取得聯繫，他們目前主張許多在此文章提到的點已經被修好了。在此聲明，以下文章僅供留存與參考用。

這篇文章的源頭

這篇文章其實在今年八月就已經寫完了，只是當時感覺沒有必要發出來，也感覺發出來了可能會引發更大的問題

但後來想想，這個組織的問題我認為我還是需要講出來，況且，當時的情況好像又重演了

以下是八月撰寫的的原文：

Who is HackIt?

在開始吃瓜之前，我先簡單介紹一下 HackIt 是誰

HackIt，是一個想要在台灣推廣青少年自主籌備活動，推動自主開發文化的組織，曾經辦過 Hack Club 的 Scrapyard TW 和第五屆中學生黑客松子賽事

而我，曾是這團隊的一員

你問 Hack Club 是誰？簡單說，他們是一個提供青少年自主學習任何與科技相關知識的美國非營利組織，詳情可看 Hack Club 官網

我為什麼會加入 HackIt？

事情得回溯到今年（2025）一月

當時 Hack Club 正準備舉辦全球黑客松 Scrapyard，幾乎包辦所有資金與資源。我看到消息想說也來試試，畢竟台灣之前沒人辦過 Hack Club 的黑客松，而且資金問題似乎不會是阻礙

於是我填了 Hack Club organizer 表單，到送出表單之前，我突然發現 Slack 上已經有個 #scrapyard-taiwan 頻道

既然有人了，表示台灣有人想辦 Scrapyard。於是我立刻聯絡了建立頻道的那個人

那人叫小波，當時覺得很新奇，台灣竟有人活躍在 Hack Club Slack，我當然加入他的組織——HackIt，成了籌備團隊一員

Scrapyard TW

時間飛快，活動逐漸成形，比賽前一週，小波突然丟出一個大問題：

黑客松沒有能決定最終優勝者的投票系統。

當時處理資訊類問題的只有我和另一人，於是兩個人在 7 天內要硬生生搞出一套前後端完整、能跑能跳的投票系統。時間表看起來絕對不夠

比賽當天在三民高中舉行，大約 100 人參加。活動一開始還算順利，資金來自 Hack Club，參賽者吃得開心，coding 也沒什麼問題

參賽者黑客松進行時，我和夥伴在搞一個小黑客松，目標是趕出那個系統。我們熬到凌晨兩三點，硬是弄出能用的版本

系統設計要讓參賽者多面向評分，採互評機制，我們覺得還不錯，後來滿心歡喜地睡覺

隔天，小波卻因為某個理由，決定不用我們系統。事情發生在評分當天上午或中午，時間根本趕不及。最後評分變成很草率的方式，直接用 Google Forms，我們辛苦蓋出的系統淪為參賽者的紀錄工具

簡言之，我們做的系統根本沒派上用場，雖然在製作過程中，我們也不太了解到底要做什麼東西

確切是不是一週我忘了，但我可以確定當時時間很趕

補充：評分其實應該用 Hack Club 官方集中評分系統 Podium，但小波自己也不太清楚。簡單說，我們白做了一套系統

真的是組織出問題嗎？

聽完故事，你可能會想：

「都怪小波？一個人怎麼可能拖垮整個組織？」

但 HackIt 的架構本身就容易牽一髮動全身

如前所述，HackIt 是小波成立的組織，他想要沒有組長、組員之分，大家都是平等的成員

我看這種組織，要不然向心力強到爆炸，要不然就是少數幾個人拖著整個團隊前進。遺憾的是，HackIt 屬於後者

簡單說，HackIt 繞著小波轉，其他組員基本上都是執行者。你稍後會理解我為什麼這樣說

中學生黑客松子賽事

Scrapyard TW 結束後，HackIt 開始籌備由台灣微課程發展協會主辦的中學生黑客松子賽事第一屆

初期籌備時，小波列出任務，大家照著做，過程還算順利

但後來小波因私事幾次往返大陸，這段期間組織明顯停擺。訊息發出沒人回，需和主辦方確認的事情也拖延。事情做完沒人接手，組員們反倒無所事事

更麻煩的是，小波長時間沒消息，原本他要做的防作弊系統完全沒完成，現場也沒人頂上

雖然活動最後還是辦完了，但這種狀況真的很不負責任，只能靠剩下的組員硬撐

我當時其實已經退出 HackIt，本以為跟我沒關係，結果活動當天因為技術支援沒人，還被叫去幫忙現場解決問題。只能說當時心情超複雜，該幫的還是得幫，但也更確定我當初決定離開是對的

HackIt 一直強調扁平組織，沒有領導階層，人人平等

但實際遇到需要快速決策或整合時，常常卡在「不知道誰決定」的狀況。事情做到一半卻沒明確方向，最後不了了之

資訊流也越來越亂。活動主題、形式、地點、補助等關鍵訊息，很多一開始沒講清楚。籌備過程中，我也搞不清楚部分細節，甚至連架構都只能自己猜

從 Scrapyard TW 到中學生黑客松，這段參與讓我看到，HackIt 雖然出發點好，想推動青少年主導專案文化，但缺乏明確分工和溝通，理想反而成了混亂和疲乏的來源

最後我在這狀況下退出，也決定在問題沒解決前不會再回去了

HackIt，內部真的需要改變

我知道這篇文章可能讓一些人不舒服，尤其是曾參與或還在 HackIt 的朋友

但我寫這些，不是要批評誰，而是想記錄當時觀察。HackIt 理念真的很好，也吸引不少年輕人願意投入，只是實際上，真的多少人有熱情走下去都是未知數

我相信只要組織願意重新思考結構──無論是權責分工、決策流程，或成員流動機制，未來還是能辦出更多有趣的活動

但這件事，必須有人真心想改

歷史重演

這裡是文章發佈之前新增的，不是八月草稿內的

老實說，我一直都在觀察著 HackIt Discord 伺服器的狀況。我也可以看到出來，當時許多人因為 HackIt 發出的消息與福利而參與 Hack Club Daydream

但比賽後，從一兩個詢問報銷的事情，到連續數天的抱怨與投訴

如同某個群友所說的，並不是活動是高中生為高中生辦理，就可以草草了事，更不能拖欠當時承諾的事項

請 HackIt，先處理好目前 Daydream 的問題，再來想下一步怎麼做

身為曾經的組員，我知道你的夢想很大，但夢想背後需要做出的努力，還是得到位

倘若你要聊聊，請不要私訊，請寄信至 me@wolf-yuan.dev

當個免費仔蹭免費雲端服務吧

Fri, 08 Aug 2025 00:50:00 GMT

不論你在寫什麼類型的程式，總有一天會遇到需要雲端服務的時候。無論是網站、API、資料庫還是其他應用程式，總有一些雲端程式可以讓程式更方便地執行

但雲端服務時常需要付費，對於個人開發者或小型專案來說，這可能會是一筆不小（有可能根本不想付）的開銷。幸運的是，現在有許多雲端服務提供免費方案，讓我們可以在開心 coding 的同時也一起用到一些額外的雲端服務

反正你都會過來這裡看這篇文章了，我認為你應該會寫些程式，或是有興趣學習寫程式，我這裡就不會著墨太多在程式與設定方面，主要是介紹一些免費的雲端服務，讓你可以在不花錢的情況下，享受雲端服務帶來的便利。這篇文章會採分類的方式來介紹各個服務，你也可以到頁首找目錄點點看

伺服器、私人伺服器

這裡會舉幾個雲端可以託管的服務，不論是 VPS 的服務，或是一些可以直接部署網站的服務。

適合用用來跑 Docker 容器、自架服務或是其他需要伺服器架構的服務

部分平臺可以對網路、儲存空間、CPU、記憶體客製化，可以根據需求調整資源。

GCP VM Instance：推 👍

❤️ 永久免費，前 90 天可用 $300 美金的信用額度。結束後可在額度內繼續免費使用

GCP (Google Cloud Platform) 如名稱所示，是 Google 的雲端運算平臺，平臺上幾乎把所有的雲端服務都包了起來，從虛擬機器、容器、資料庫、儲存空間、機器學習等等都有。Google 也有提供一些其他服務的免費方案，不只 VM Instance

在前 90 天用 300 美元的額度時，你可以隨便開機器、隨便開 Bucket、隨便用 IPv4 地址直到 90 天或是額度用完後。要注意的點是額度用完之後，Google 會直接把你的服務關掉，除非改到 Pay As You Go（按量付費）方案，否則無法繼續使用

但在 Pay As You Go 的方案中，Google 還是有提供免費的服務額度。在永久免費方案中提供的 Compute Engine 的規格是：

2 vCPU (0.25 ~ 2 vCPU) 是共享核心
1 GB 記憶體
30 GB 磁碟空間
不知道多少的網路流量
只能開在 us-west1（奧勒岡）、us-central1（愛荷華）、us-east1（南卡羅萊納）區域，不能建立在台灣！

網路流量待確認，如果用標準層級的網路，流量理論上可以到 200 GB 不需額外付費

以免費的規格來看，這個方案對於需要自架服務，不想自己組伺服器的人來說十分適合。唯獨要留意的是網路流量不能過多，太多會被收錢 QQ

AWS EC2

🕑️ 有限期免費，前 6 個月可獲得最高 $200 美金的信用額度。結束後無 VM 永久免費方案

AWS（Amazon Web Services）又如名稱所示是 Amazon（對就是那個網購平臺）的雲端運算平臺，提供的服務非常多樣化，從虛擬機器、容器、資料庫、儲存空間、機器學習等等都有。AWS 也有提供一些其他服務的免費方案，像是 Lambda (類似 serverless functions)、DynamoDB 之類的

AWS 在前 6 個月內，你可以隨意使用你有的額度。同樣跟 Google 一樣，在額度用完或是 6 個月後，AWS 會直接把你的服務關掉

Azure VM

🕑️ 有限期免費，前 12 個月可獲得最高 $200 美金的信用額度。結束後無 VM 永久免費方案

Azure（Microsoft Azure）是微軟的雲端運算平臺，提供的服務跟其他平臺一樣也非常多樣化，從虛擬機器、容器、資料庫、儲存空間、機器學習等等都有。Azure 也有提供一些其他服務的免費方案，有興趣的可以去看看

在前 12 個月內，你可以總共在一個月內跑 750 小時的虛擬機器，其中包含幾個方案，全部都是 1 GB 記憶體 的方案：

B1s：Intel Xeon E5-2673 v3，1 vCPU，1 GB 記憶體
B2pts v2：Arm CPU，2 vCUP，1 GB 記憶體
B2ats v2：AMD CPU，1 vCPU，1 GB 記憶體

但我沒用過這幾個方案，目前不確定網路的限制是多少。網路上找到的資料寫的是 outbound 流量 100 GB、inbound 流量無限制

Oracle Cloud：推 👍

❤️ 永久免費，前 30 天可用 $300 美金的信用額度。結束後可在額度內繼續免費使用

Oracle Cloud 是 Oracle（那個做 Java Runtime 很有名的）的雲端運算平臺，提供的服務跟其他平臺一樣也非常多樣化，有興趣的再自己去查查吧

跟其他平臺一樣，Oracle Cloud 在前 30 天內提供 $300 美元的額度，讓你可以隨意使用。額度用完後，你可以繼續使用免費的服務，其他服務則會被關掉

Oracle Cloud 的免費方案提供了 2 個 VM Instance，規格如下：

其中一個是用 AMD CPU 的執行個體，提供了：

0.25 vCPU
1 GB 記憶體
最多 200 GB 的磁碟空間（！）

另外一個是用 Arm CPU 的執行個體，提供了誇張多的：

3000 vCPU/hour
24 GB 記憶體（！）
最多 200 GB 的磁碟空間（！）

永久免費方案給的額度很多，我不確定目前還有沒有註冊名額，但如果有的話，這個方案是非常適合用來自架服務的。~~可惜我搶不到~~

網站託管

這裡會舉幾個可以直接部署網站的服務，適合用來部署靜態網站、前端應用程式或是包含 serverless functions 的後端程式

Vercel：極推 😍

❤️ 永久免費，免費額度很多

Vercel 是一個專門用來部署前端應用程式的服務，提供了非常慷慨的免費額度。Vercel 支援多種前端框架，如 Next.js、Nuxt.js、Astro 等等

跟 GitHub Pages、GitLab Pages 不同的是，Vercel 支援部署包含 serverless functions 的後端程式，可以把前端應用程式跟後端程式一起部署在 Vercel 上

Vercel 的免費方案的優點跟缺點是：

每月 100 GB 的流量
每月 100 萬次 functions 呼叫
每月 4 小時的 CPU 時間
每月 360 GB/hours 的 functions 執行記憶體
免費的 analytics、speed insights、image optimization 等等功能

至於 functions 執行的容器規格如下：

1 vCPU
2 GB 記憶體

我用 Vercel 用下來仍感覺他是目前最適合部署全端程式的平臺，如果你有前端應用程式或是包含 serverless functions 的後端程式要部署，Vercel 是非常適合的選擇

Cloudflare Workers 極推 😍

❤️ 永久免費，網路使用無限制！

Cloudflare Workers 是 Cloudflare 提供的 serverless functions 平臺，可以讓你在 Cloudflare 的邊緣網路上執行程式碼。Cloudflare Workers 會把你的程式放到多個 edge node 上執行，這樣可以讓你的程式在全球各地都可以快速執行

以前會推 Cloudflare Pages，但 Cloudflare Workers 在最近支援了 ASSETS binding，意思是你可以把 workers 當靜態網站來用，限制與 Pages 一樣

Cloudflare Workers 主要的優點跟限制是：

每天 100000 次請求（超多）
每次可使用 10 ms 的 CPU 時間
執行記憶體 128 MB
Functions 總大小 1 MB
不支援任何像是 sharp 的圖片最佳化套件

我認為 Cloudflare Workers (Pages) 是目前最適合部署靜態網站的平臺，因為他可以直接把靜態網站部署在 Cloudflare 的 edge network 上，並且提供了非常慷慨的免費額度

Render

🤔 永久免費，但有更好的替代方案

Render 是一個提供多種雲端服務的平臺，像是網站託管、API、資料庫等等。Render 的免費方案提供了不錯的免費額度，讓你可以輕鬆地部署網站或是 API

Render 的免費方案的優點跟限制是：

每月 100 GB 的流量
512 MB 的記憶體
每月不限制請求次數
每月 750 小時的執行時間
一段時間沒人上線會自己睡著，啟動要花差不多一分鐘

Render 的免費方案適合用來部署一些小型的網站或是 API，但相比之下，在 Vercel 支援 Fluid Compute 的情況下，Render 的免費方案就顯得有點弱了，特別是在需要啟動時間的部分

Netlify

🤔 永久免費，但有更好的替代方案

Netlify 是一個專門用來部署前端應用程式的服務，提供了還不錯的免費額度。Netlify 同樣支援多種前端框架，如 Next.js、Nuxt.js、Astro 等等

Netlify 的主要優點跟限制是：

每月 100 GB 的流量
每月 100 萬次 functions 呼叫

我個人認為 Netlify 跟 Vercel 提供的服務很像，像是流量限制跟 functions 呼叫次數都差不多，但我覺得 Vercel 的免費額度更慷慨一些，並且 Vercel 在我用過後感覺體驗更好一些

GitHub Pages：推 👍

❤️ 永久免費，設定完可以直接忘記，GitHub CDN 加持

GitHub Pages 想必超多人都有聽過，很多人的網站都架在他有名的 *.github.io 網域底下。GitHub Pages 會把你的網站部署在 GitHub 的伺服器上，並且可以直接幫你撈一個 SSL 憑證

唯一的問題是 GitHub Pages 只能部署靜態網站，不能部署動態網站或是包含 serverless functions 的後端程式。如果你只是要部署一個靜態網站，GitHub Pages 是非常適合的選擇

GitLab Pages：推 👍

❤️ 永久免費，設定完可以直接忘記

老實說跟 GitHub Pages 差不多，GitLab Pages 也是可以直接部署靜態網站的服務。GitLab Pages 的部署方式跟 GitHub Pages 有點不一樣，但基本上也是可以直接部署靜態網站

AWS Lambda

❤️ 永久免費，免費額度還不錯

AWS Lambda 是 AWS 提供的 serverless functions 平臺，可以讓你在 AWS 的伺服器上執行程式碼。雖然這聽起來有點斜咖，但你其實是可以把 Next.js 的 SSR（Server side rendering）的網頁丟上 AWS Lambda 的，像這個專案做的 adapter

AWS Lambda 的免費方案的優點跟限制是：

每月 100 萬次請求

雖然我沒試過把網站丟到這種平臺上，但 AWS Lambda 的免費額度還不錯，適合用來部署一些小型的全端網頁

資料庫

這部份會講一下一些可以免費用的代管資料庫服務，但因為我對這部份比較不熟，可能會有些疏漏

Supabase：極推 😍

❤️ 永久免費，平臺直接開一個 AWS VM 跑你的資料庫，個人超愛

Supabase 是一個開源的後端即服務（BaaS）平臺，提供了類似 Firebase 的功能，但使用 PostgreSQL 作為資料庫。Supabase 提供了非常慷慨的免費額度，讓你可以輕鬆地使用資料庫

Supabase 的免費方案的優點跟限制是：

500 MB 的資料庫儲存空間
1 GB 的檔案儲存空間
無限次的資料庫請求
每月 5 GB 的資料庫流量

Supabase 還提供身分驗證的功能，可以串接框架與第三方 OAuth 平臺，可以對資料庫權限進行細緻的控制。還有他們的 TypeScript SDK 超級好用，typing 會自動產生，也很適合跟著後端一起包在 serverless functions 裡面使用

AWS DynamoDB

❤️ 永久免費

AWS DynamoDB 是 AWS 提供的 NoSQL 資料庫服務，AWS 會幫你管好理資料庫的執行，讓你可以直接把精力放在 coding 上

DynamoDB 的免費方案的優點跟限制是：

每月 25 GB 的儲存空間（！）
每月 200 萬次讀取請求
每月 200 萬次寫入請求

雖然我沒用過 DynamoDB，但他其實跟等等要講的 MongoDB 類似，適合用來存一些非結構化的資料。如果你需要一個 NoSQL 資料庫，DynamoDB 是一個不錯的選擇，AWS 給的免費額度看上去也不錯，特別是儲存空間的部分

MongoDB Atlas：推 👍

❤️ 永久免費，平臺直接開一個 AWS/GCP/Azure 的 VM 跑你的資料庫

MongoDB Atlas 是 MongoDB 提供的雲端資料庫服務，提供了很棒的免費額度，讓你可以直接把 MongoDB 資料庫丟在雲端上

MongoDB Atlas 的免費方案的優點跟限制是：

每月 512 MB 的儲存空間
每秒最多 100 次讀取 / 寫入請求

跟 Supabase 一樣，MongoDB Atlas 也同樣沒有限制制資料庫請求次數，這對於需要大量讀取 / 寫入資料的應用程式來說根本是福音。還有 MongoDB 可以選擇多個雲端平臺來部署資料庫，像是 AWS、GCP、Azure 等等，也可以自訂你要放在哪個地區

所以我說，我的 YouBike 呢？

Sat, 02 Aug 2025 17:30:00 GMT

直接帶我去查 Bike 網頁 專案與 YouBike 完全無關

最近真的一直被 YouBike 氣到。

理論上來說，YouBike 應該要確保任何一個站點沒有車可借，更不應該讓有任何一站沒有位子可以還車。但好像 YouBike 官方基本上沒有很常在管這件事情

經過幾次從高中出來沒有車可借，或是騎到目的地之後沒有位可還，客服電話已經打到感覺行動電話的市話有點貴後，我想寫一個小程式看看 YouBike 到底有沒有在沒車的時候即時補車，或是在一天某個時段都會沒車的時候，YouBike 有沒有預防性的先補車

查 Bike

經過大約 25 小時的瘋狂 coding 跟抓 bug，還有幾天的資料收集後，我搞出了這個網站：

你現在也可以上 https://youbike.wolf-yuan.dev 來看看這個網站

超簡單的首頁

首頁上可以看到系統總共追蹤的站點有幾個，而整體來看，累積多少時間沒有車可以借、沒有位可以還

另外，最頂部的表情跟底下的文字會依照全部已追蹤站點的狀態顯示

在首頁上面，這幾個表情符號分別代表：

綠色笑臉：全部的站點都有車可以借，有位可以還
黃色哭臉：有站點沒有位子可以還了
紅色生氣：有站點沒有車可以借

而每個站點也都可以展開顯示近幾個小時的歷史紀錄，還有該站點有多少百分比的時間沒有車可以借或是位可以還

算詳細的站點報告

在首頁點下去「查看更多歷史資料」的按鈕後，會跑出這個頁面：

這個頁面可以查詢最多 5 天內的各小時站點狀態快照還有即時的站點狀態，旁邊有一個小小的狀態條會顯示那個時候的站點狀態

哦對了，每小時快照狀態條的顏色跟首頁的狀態顏色意義一樣，也是黃色是沒位可還，紅色是沒車可借

但是頁面最上面的表情符號顏色意義跟就跟首頁稍稍不一樣了。為了讓別人看這個頁面可以直接知道現在的狀態，各個顏色代表：

紅色：已經全部沒車可借或是沒車可還
黃色：<5 臺車可借或是 <3 個還車柱可還
綠色：就完全正常，可借可還

可能會改，但目前我認為這樣比較可以一下子就知道有沒有車可以借

怎麼加站點？

啊當然現在寫了一長串好用的功能，你可能會想問你要怎麼把站點加進追蹤清單內

因為目前這個網頁還不太穩定，站點現在採申請制。如果你想要把你家附近的站點或是學校附近的站點加到這個網頁裡面，你可以發一個郵件到 me@wolf-yuan.dev

郵件內容必須包含以下幾個東西：

要加站點的完整站點名稱

不知道可以看停車柱上面的站點名字，或是上 YouBike 官網查詢。得是完整的站點名稱。站點名稱得讓我知道的你指的站點到底是哪個，如果還是真的不確定到底叫做什麼，你可以丟地址給我。記得檢查有沒有其他站點撞名哦
一張或是多張 站點沒車 或是 站點滿車然後你沒位子可以還的照片

如果沒有照片，你可以寫一小段為什麼要加的理由

伺服器與資料庫資源有限（目前是很有限），目前還沒辦法全台的站點都加進去，所以目前得先這樣處理

Well, technically 🤓☝️

講完功能之後，該來講講這個網頁背後用的技術。這個網站目前整個活在雲端，也不花我一毛錢

應該是說以目前的規模來說不用花我一毛錢，請各位爬蟲們高抬貴手，我未來可能會加 API

拉資料的後端（應該算後端

後端採 TypeScript 撰寫，跑在 Cloudflare Workers 上面會從 YouBike 的網頁 API 抓完資料後，放進 Supabase 資料庫

資料類型分成兩種，兩個都用 cron trigger 跑：

每分鐘即時資料 * * * * *：抓即時資料，看站點狀態來增加沒車 / 滿車的時數
每小時資料快照 0 * * * *：抓資料放站點快照，就這樣

每個小時的快照僅會保存 5 天，但每分鐘的沒車 / 滿車狀態則是累加，無天數限制

顯示資料的前端（網頁

前端用 Astro + TypeScript + TailwindCSS 撰寫，跑在 Cloudflare Workers 上

每個頁面都是用 SSR (Server side rendering)，也就是每個頁面都不需要 client 額外去叫 Supabase 的 API，理論上會讓效能變好很多，特別是在效能超級糟糕的中低階手機上。網頁設計採用跟我個人網站一樣的設計語言

頁面跟頁面之間都用 Astro 的 <ClientRouter /> 串起來，用瀏覽器的 View Transition API 做出頁面跟頁面之間超級流暢的動畫

我很抱歉 Firefox 使用者，Firefox 現在沒有 View Transition API 所以只會看到淡入淡出

YouBike 的伺服器是馬鈴薯做的

另外，吐槽一下 YouBike

後端在抓資料的時候，時不時就會抓到 YouBike 伺服器噴出來的 503，不知道是刻意的還是伺服器後端程式寫太爛，但每次都是在深夜出現

目前推測是 YouBike 為了省錢，在夜晚的時候 scale-down 伺服器或是 DB 的 replica 變少，讓錯誤率提高

資料得出的結論

所以我看了這些資料得出來的結論是什麼？

我只能說，YouBike 是可以解決這些沒車、沒位還的問題，我也認為他們有想要解決，只是要再多加把勁

根據臺北市提供的見車率資料顯示，臺北差不多有 700 多個站點見車率大於 90%，500 多個站點見車率介於 60% ~ 90% 之間

經過比對，在臺北的站點跟系統蒐集到的資料大略相同，但因為那些小站或是流動率較低的站點，卻可以讓見車率的統計數據提高。我不曉得見車率 93% 怎麼算來的，但對於尖峰時段會沒車的站點來說，見車率絕非 93%

而聯絡客服後，補車人員差不多要 15 分鐘左右才會到場補車，如果現場沒車預備則會需要更多的時間，客服會先叫你去鄰近站點借車還車。臺北新北人可能還有捷運可以使用，對於其他縣市來說，下個站點可能距離超級遠，要走過去倒不如直接用其他交通方式

然後現在 YouBike 直接把客服專線裡面的無車可借的選項拿掉，真有你的 YouBike

來玩玩 Docker 多階段建置與 distroless 吧

Tue, 01 Apr 2025 20:30:00 GMT

想像你剛剛寫完了你的專案，並且想要將它打包成一個漂亮的 Docker 映像檔。

你大費周章的寫了一個 Dockerfile，執行了 docker build 指令，過了 1 分鐘。當映像檔建置完成後，你發現這個映像檔超級大。就僅僅是一個簡單的 Node.js 程式，完整的容器映像檔竟然來到了快 1GB。

你可能會想問：「有沒有辦法減少映像檔的大小呢？」

古老的方法：單階段建置

在 Docker 首次推出時，建立一個 Docker 映像檔的唯一方式是用單一階段的建置。這是一個簡單且直接的方法。你只需寫一個簡單的 Dockerfile，然後跑跑指令把它 build 起來。

以下是一個打包 C++ 應用程式的單階段 Dockerfile 範例：

FROM debian:12

COPY . /app
RUN apt-get update && apt-get install -y build-essential && \
  gcc -o /app/donut /app/donut.c

ENTRYPOINT ["/app/donut"]

而 donut.c 是什麼呢？就是那個用 C 寫的，會轉圈圈的甜甜圈程式：

             i,j,k,x,y,o,N;
         main(){float z[1760],a
      #define R(t,x,y) f=x;x-=t*y\
   ;y+=t*f;f=(3-x*x-y*y)/2;x*=f;y*=f;
   =0,e=1,c=1,d=0,f,g,h,G,H,A,t,D;char
 b[1760];for(;;){memset(b,32,1760);g=0,
h=1;memset(z,0,7040);for(j=0;j<90;j++){
G=0,H=1;for(i=0;i<314;i++){A=h+2,D=1/(G*
A*a+g*e+5);t=G*A        *e-g*a;x=40+30*D
*(H*A*d-t*c);y=          12+15*D*(H*A*c+
t*d);o=x+80*y;N          =8*((g*a-G*h*e)
*d-G*h*a-g*e-H*h        *c);if(22>y&&y>
 0&&x>0&&80>x&&D>z[o]){z[o]=D;b[o]=(N>0
  ?N:0)[".,-~:;=!*#$@"];}R(.02,H,G);}R(
  .07,h,g);}for(k=0;1761>k;k++)putchar
   (k%80?b[k]:10);R(.04,e,a);R(.02,d,
     c);usleep(15000);printf('\n'+(
        " donut.c! \x1b[23A"));}}
           //3D-spinning-donut

參考 donut.c：limiteci/donut.c

那個 Dockerfile 看起來很簡單，對吧？在打包過程中，我們安裝了 build-essential 套件，這個套件包含了你在編譯 C 應用程式時所需要的幾乎所有編譯器與工具。然後複製原始碼到容器裡面，編譯它，並且執行了編譯後的二進位檔。

不過這裡好像出了點問題：/app/donut 這個已編譯的程式不需要任何來自 build-essential 的工具，這些工具只在編譯程式時需要。所以，我們在最終映像檔中包含了不必要的工具。

移除不必要的小工具

為了解決這個問題，我們需要在編譯過程後移除不必要的工具。底下是一個簡單的範例：

FROM debian:12

COPY . /app
RUN apt-get update && apt-get install -y build-essential && \
  gcc -o /app/donut /app/donut.c && \
# [!code ++]
apt remove -y build-essential && apt autoremove -y && apt-get clean

ENTRYPOINT ["/app/donut"]

在上面的範例中，我們在編譯過程後移除了 build-essential 套件，並且清理了 apt 快取，來減少映像檔的大小。

用 Alpine Linux 作為基底映像檔

這裡有另一個選擇，就是使用 Alpine Linux 作為基底映像檔。Alpine Linux 當初就是設計成極度輕量與安全。它只有 5MB 的大小（加上 busybox），比 Debian 小很多。

你可以用下面使用 Alpine Linux 的 Dockerfile 來取代上面的 Debian Dockerfile：

FROM alpine:3

COPY . /app
RUN apk add --no-cache build-base && \
  gcc -o /app/donut /app/donut.c && \
  apk del build-base

ENTRYPOINT ["/app/donut"]

這裡的結果映像檔應該比 Debian 映像檔小很多，差不多是 5 倍的差距。

但是，這裡有個問題：Alpine Linux 使用 musl 作為標準 C 函式庫，這與大多數 Linux 發行版使用的 glibc 不同。這可能會導致一些 (通常不只一些) C/C++ 應用程式的相容性問題。

特別是如果你有一個來自不知道哪裡的的二進位檔，而且它又需要 glibc 才能執行，那麼祝你好運。嘻嘻

一個更好的方法：多階段建置

Docker 在 17.05 版本中引入了多階段建置。它允許你在多個階段中建置你的應用程式，並且將前面做出來的程式從一個階段丟到另一個階段。

我們可以這麼想：我們可以有一個大廚房，裡面擺滿了烹飪所需的工具和食材，而送給客戶的只是一個小盒子來盛裝食物。

以下是一個使用多階段建置的 Dockerfile 範例：

FROM debian:12 AS builder

RUN apt-get update && apt-get install -y build-essential

COPY . /app
RUN gcc -o /app/donut /app/donut.c

FROM debian:12

COPY --from=builder /app/donut /app/donut

ENTRYPOINT ["/app/donut"]

這個 Dockerfile 的作用是在第一階段建置應用程式，然後將編譯後的二進位檔複製到第二階段。第二階段是使用從乾淨的 debian:12 映想檔。這個 Dockerfile 建置出來的映像檔應該比不使用多階段的小，因為它不包含 build-essential 套件。

使用 distroless 映像檔

如果你有嘗試上面的範例，你可能會發現最終跑出來的映像檔還是很大。因為我們只移除了額外安裝的 build-essential，基底映像檔 (Debian 的那個) 的大小還是很大。

2017 年，Google 推出了 distroless 映像檔，這些映像檔只包含執行應用程式所需必要的工具。也因為只包含最少的工具，它沒有多餘的東西。比純淨還要純淨。

也因為 distroless 映像檔沒有套件管理器，你基本上不能在映像檔中安裝額外的套件。你只能從前一階段複製檔案到這個階段。這也是為什麼多階段建置對於 distroless 映像檔來說很重要。

要烹飪一個 distroless 映像檔，我們需要使用 debian:12 當作第一階段，先建置二進位檔，然後將二進位檔複製到 gcr.io/distroless/static-debian12 映像檔：

FROM debian:12 AS builder

RUN apt-get update && apt-get install -y build-essential

COPY . /app
RUN gcc -static -o /app/donut /app/donut.c

FROM gcr.io/distroless/static-debian12

COPY --from=builder /app/donut /app/donut

ENTRYPOINT ["/app/donut"]

注意一下，這裡我們在 gcc 後面加上了 -static，如果你不加上這個參數，二進位檔會是動態連結的，這樣就需要 glibc 才能執行。 (簡單來說，最終的映像檔會變大)

或是你可以使用有 glibc 的 gcr.io/distroless/base-debian12 映像檔

這個最終的映像檔應該比之前的 Debian 或 Alpine 映像檔小很多，因為它基本上只有一個 "donut" 的二進位檔而已。

最極致的解決方案

其實還有一個基底映像檔叫做 scratch。

哦，不是，我不是在講那隻叫做 Scratch 的橘色福瑞貓

scratch 其實是一個很特別的映像檔，老實說他其實只是一個特殊的名字，Docker 會把它視為一個 "建立一個新的空白檔案系統" 的指令。

畢竟是一個空白的檔案系統，它當然也沒有任何系統的函式庫等等的工具，這個讓它變得超級小及安全。

我們可以用這個簡單的範例來看看怎麼用 scratch 映像檔：

FROM debian:12 AS builder

RUN apt-get update && apt-get install -y build-essential

COPY . /app
RUN gcc -static -o /app/donut /app/donut.c

FROM scratch

COPY --from=builder /app/donut /app/donut

ENTRYPOINT ["/app/donut"]

使用 scratch 的映像檔必須為靜態連結的二進位檔案，你不能用動態連結的二進位檔，因為 scratch 裡面根本沒有東西可以動態連結到。

這個 Dockerfile 應該會跑出最小的 docker 映像檔，因為它裡面只有一個 donut 執行檔而已。

最終比較

基底映像檔	整體大小
Scratch	767kB
Distroless + 多階段建置	2.76MB
Alpine	7.4MB
Debian，使用多階段建置	117MB
Debian，單階段，移除 `build-essential`	140MB
Debian，單階段，不移除 `build-essential`	534MB

以上大小僅供參考，實際大小可能會有所不同。這些映像檔是在我的筆電上使用 Docker 28.0.1 建置的。

以上數據顯示，scratch 得到了最小的映像檔大小。distroless 排在第二，而 Alpine 則是第三。

雖然在這個比較中，Alpine 和 distroless 沒有跑出最小的映像檔，但考慮到它只有幾 MB 的大小，它仍然是一個不錯的選擇。

結論

所以你應該選擇什麼呢？Scratch 還是 distroless 還是 Alpine 還是 Debian？

我的建議是，如果你的程式不需要任何一般 Linux 系統會有的函式庫，請考慮使用 scratch。

而如果 Google 已經很好心的幫你做了一個包含你要使用的執行環境的 distroless base image，那麼請使用 distroless。目前，distroless 有 python3、java-{17, 21} 和 nodejs-{18, 20, 22}。這些映像檔包含了這些執行環境，而且應該是經過特別優化的。

在 distroless 的 GitHub 上面看看有什麼可以用的環境

至於 Alpine，如果你的應用程式用了一些特別的執行環境，而且恰恰好做那個環境的人有提供已經建立好的 Alpine 映像檔，那麼請使用它。

至於 Debian 呢？除非你有一個非常特殊的使用情況，否則我建議不要使用它作為基底映像檔。

Astro: 新生代的高效網頁框架

Sat, 01 Mar 2025 15:00:00 GMT

事情發生在某天我想開始建立個人網站的時候，我當時正在思考有什麼方法可以讓我快速的建立一個網站

使用現有的模版當然可以，但我不希望我的網站跟別人的看起來很像。只用 HTML 開搞當然也是可以，但我可不希望處理網頁的效能，想到未來的可維護性更是頭痛。

框架？

考慮以上幾點，我似乎需要一個網頁框架來幫助我處理這些問題。經過我生鏽的大腦考慮後，我整理出了以下幾個框架：

Next.js

第一個參賽者是 Next.js，一個建立全端網頁時最好的選擇

憑藉著 React 的生態系，Next.js 在我心中有了近乎完美的分數。這就是為什麼這個框架是我建立網站第一個考慮的框架。

但是好的東西總是有著缺點。例如在不用 SSR (server-side rendering) 的情況下，網頁是不能在 JavaScript 停用的狀況下瀏覽的、Next.js 與 React 的在網頁裡包含的函式庫跟純 HTML 比起來大多了，會稍稍拖慢網站的效能。

Vue.js

既然都叫 Vue".js" 了，怎麼可能不用 JavaScript？而且 Vue 的語法對我來說有點不合胃口，<script setup>，看起來好奇怪...

Angular... 等等這個真的有人用嗎？

哎呀 Angular，好久不見。Angular 以前似乎在前端設計頗有名聲，但我不太確定現在的評價如何。

於是我決定到 Angular 的網站看看，但這個看起來有些奇怪的程式碼讓我卻步了：

import {Component} from '@angular/core';
import {FormsModule} from '@angular/forms';
import {bootstrapApplication} from '@angular/platform-browser';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <label for="name">Name:</label>
    <input type="text" id="name" [(ngModel)]="name" placeholder="Enter a name here" />
    <hr />
    <h1>Hello {{ name }}!</h1>
  `,
  imports: [FormsModule],
})
export class DemoComponent {
  name = '';
}

bootstrapApplication(DemoComponent);

不知道你們怎麼想，但我個人覺得它比 Vue 還要難看

Astro

後來，我找到了 Astro。一些 Reddit 的使用者都蠻推薦這個新的網頁框架。於是我開了 Astro 的網站來看看，這裡是一個範例程式碼中的首頁範例：

---
import '../styles/global.css';
// Component Imports
import Button from '../components/Button.astro';

// Full Astro Component Syntax:
// https://docs.astro.build/basics/astro-components/
---

<html lang="en">
	<head>
		<meta charset="utf-8" />
		<meta name="viewport" content="width=device-width" />
		<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
		<meta name="generator" content={Astro.generator} />
		<title>Astro + TailwindCSS</title>
	</head>

	<body>
		<div class="grid place-items-center h-screen content-center">
			<Button>Tailwind Button in Astro!</Button>
			<a href="/markdown-page" class="p-4 underline">Markdown is also supported...</a>
		</div>
	</body>
</html>

嘿等等，我是在看 HTML 還是一個網頁框架的語法？這個看起來極其簡單的語法讓我馬上想試試看這個酷酷的框架。

稍稍停一下，為什麼我覺得沒有開 JavaScript 的使用者很重要？

首先，通常以 JavaScript 來渲染的網頁都使用較多的資源，也可能拖慢網站速度。還有，有著更高安全性的瀏覽器（例如 Tor 瀏覽器）時常預設將 JavaScript 封鎖。

我希望我的網站是大家都可以輕易的瀏覽，包含那些沒有穩定的網路或是使用舊手機的人

我也希望可以使我的網站對盲人"聽起來更好聽"，我還在持續加強這塊

開搞 Astro 網頁

在決定成為一個太空人（用 Astro 的人叫 Astronaut，個人覺得這個名字很酷 :D）之後，我使用了這個指令來開一個新的專案：

pnpm create astro@latest

接著把 TailwindCSS 新增到 Astro 內：

pnpm astro add tailwind

嘿，TailwindCSS 版本 4 有更改使用方式，我目前不確定現在這個指令會產生什麼樣的結果。你可能需要看一下 Astro 跟 TailwindCSS 的說明文件

然後我就開始寫網站了。Astro 直覺的語法十分好理解，特別是如果你以前有學習過 HTML。Astro 的 Island 也讓框架混搭變得簡單許多，如果你現在有使用其他框架撰寫的程式碼也可直接用上。

太空人的煩惱

傳說中的 JavaScript

Astro 預設不放任何 JavaScript 到你的網頁中，這使 Astro 在撰寫互動式網頁時比較不那麼理想。以狀態管理來說，Astro 就沒有像 React 一樣的小工具可以使用。我們以此網站的狀態列為例：

這是如果我使用 React 的話看起來的樣子：

const [scroll, setScroll] = useState(false);

window.addEventListener("scroll", (event) => {
  // 一些判斷條件
  setScroll(true);
});

return (
  <nav class={twMerge("some-default-style", scroll && "some-special-style")}>
    {/* ...其他程式... */}
  </nav>
);

那如果我使用 Astro，一個幾乎不對 JavaScript 做任何更改的網頁框架呢？

<nav class="some-default-style" id="nav">
  {/* ...其他程式... */}
</nav>

<script>
  window.addEventListener("scroll", (event) => {
    // 一些判斷條件
    document.getElementById("nav").classList.add("special-style");
    // else
    document.getElementById("nav").classList.remove("special-style");
  }
</script>

剛開始，你可能會覺得框架不使用過多 JavaScript 感到開心，因為它不像 React 會限制你只能使用特殊語法或是只能使用特定的實作方式，但隨著你的網站需要的動畫增加後，你會需要自己寫更複雜的程式碼來製作這些動畫。這使 Astro 在撰寫互動式網站時不那麼的方便。

圖片優化

Astro 內建的 astro:assets 模組提供了一些圖片優化，像是圖片壓縮跟可以使其更無障礙的標籤等等。

但是 Astro 的圖片優化沒有提供一個我希望有的功能：對於不同的螢幕尺寸來給予不同的 src，也就是 srcset。需要額外撰寫一個酷酷的 OptimizePicture 元件來為圖片產生多個 widths 屬性，一個 astro:assets 內 Image 所支援的屬性，你可以看看 Astro 對於這個屬性的說明文件

底下是我的 OptimizePicture 元件的程式碼，供你參考一下

---
import { Picture, inferRemoteSize } from "astro:assets";

const props = Astro.props;

let width;
if (typeof props.src === "object") {
  width = parseInt(props.src.width);
} else if (typeof props.src === "string") {
  const size = await inferRemoteSize(props.src);
  width = size.width;
}

const widths = [];
const ratioMultiplier = props.maxWidth / props.maxViewport;
let currentViewport = props.maxViewport;

while (currentViewport >= 240) {
  widths.push({
    viewport: currentViewport,
    width: Math.round(currentViewport * ratioMultiplier),
  });
  currentViewport -= 320;
}
---

<Picture
  formats={["avif"]}
  widths={widths.map(({ width }) => width)}
  sizes={widths
    .reverse()
    .map(
      ({ viewport, width }) =>
        `(max-width: ${viewport}px) ${width}px`,
    )
    .concat(`${width}px`)
    .join(", ")
    .trim()}
  quality={100}
  {...props}
>
  <slot />
</Picture>

在我撰寫這個元件時，我發現 Astro 似乎沒有一個標準載入圖片的方式。props.src 回傳的內容有時是 string（字串），而有時是 object （物件）。這個元件只能支援 props.src 為物件的時候，也就是在 Markdown 檔案裡載入圖片的時候。

嗨，如果你覺得你有更好的解法，請發一個 email 讓我知道！

結論

在閱讀完這個文章後，你可能會想，你真的需要使用 Astro 嗎？

我的想法是，如果你要建立一個靜態網站、個人的部落格或是不會使用到那麼多很 fancy 的 JavaScript 技術，我建議你使用 Astro。畢竟，這個分數很高對吧：

2025/06/22 更新：PageSpeed Insights 好像不會保留網站測試的歷史紀錄，你可以自己去 PageSpeed Insights 的網頁把我的網站丟進去測測看

但是若你的網站需要更多需要 JavaScript 來達成的效果，不論是動畫還是功能，我還是建議你使用其他框架。

hyprland 是我用過最好用的視窗管理器

Sat, 30 Nov 2024 16:00:00 GMT

Hello there, are you a English reader? Well congrats, this post has an English version, you can click the translation icon at the bottom of the page or go here.

某天，當時我正無聊得滑著手機，突然發現了一些有關於我以前看到使用 Wayland 的視窗管理器 —— hyprland。這讓我想起了以前在 Reddit 上面看到的一些有關於它的新聞，這讓我突然想要試試看這個 DIY 的小玩具。

在看過一些文章及影片後，我決定嘗試看看這個酷東西。以下我將分享我如何在我的電腦上安裝及設定 hyprland 。

噢對了，它現在看起來像這樣：

安裝

安裝 hyprland 其實非常簡單且快速。使用 hyprland 的首要條件應該是在你的電腦上安裝 Arch Linux，然後執行以下指令：

sudo pacman -S hyprland

同時你需要 hyprland 預設的終端機模擬器 kitty 你可以用這個指令安裝。

sudo pacman -S kitty

很簡單對吧。雖然使用 Arch 分支的其他 Linux 發行版如 Manjory 或 EndeavourOS 能然能執行 hyprland ，但我個人偏好使用 Arch Linux 。

這份教學假設您使用 Arch Linux。我不推薦使用 Debian 或是 Fedora ，他們的更新速度不像 Arch Linux 那麼頻繁和及時。並且官方的儲存庫裡面可能沒有 hyprland 必須或額外可安裝的元件，您可能得自行編譯它們。

這時 hyprland 已經安裝成功了，但如果您不想要每次開機都得自己在 tty 中輸入 hyprland 來進入桌面的話，我會推薦你安裝 ssdm 登入管理員，它兼具簡單及高度客製化的優點，您可以執行以下指令安裝 ssdm :

sudo pacman -S sddm

接著只要重新啟動電腦，您就會發現 hyprland 與 SDDM 都已經成功的安裝了。

客製化

當然，目前的 hyprland 與美麗二字相差甚遠，這是因為 hyprland 預設的自動生成設置檔僅有最基礎，最簡單的設置，進階的功能必須由您敲敲打打來更改。以免你不知道，這幾個是未經更改的 hyprland 不具備的功能：

亮度調節
音量調節
螢幕截圖或錄影
螢幕鎖定

沒錯，hyprland 就是這麼的高度客製化，多數的設置都得由您親手完成，聽起來有沒有覺得熱血沸騰呢？

我們先從移除上方橫欄中討人厭的自動生成警告開始，請使用你的文字編輯器打開 ~/.config/hypr/hyprland.conf，將以 autogenerated 開頭的行數註解掉，像是這樣：

# #######################################################################################
# AUTOGENERATED HYPR CONFIG.
# PLEASE USE THE CONFIG PROVIDED IN THE GIT REPO /examples/hypr.conf AND EDIT IT,
# OR EDIT THIS ONE ACCORDING TO THE WIKI INSTRUCTIONS.
# #######################################################################################

autogenerated = 1 # remove this line to remove the warning // [!code focus] [!code --]
# autogenerated = 1 # remove this line to remove the warning // [!code focus]

更改完畢後別忘了儲存檔案，你會發現上方的警告訊息自動消失了。這是因為 hyprland 在偵測到設定檔案變更後會自動重新載入設置檔。當然你也可以使用 hyprctl reload 來重新載入 hyprland 的設定。

hyprland 有一套自己的設定檔格式，您可以在它的官方文檔裡面找到所有可供設定的選項。

為 hyprland 加上酷酷的模組

沒有經過「調味」的 hyprland 並未具有許多其他視窗或是桌面管理器擁有的特色，但透過強大的社群製作的擴充，您可以為 hyprland 加上更多的功能。

以下我將會介紹幾種我自己有在使用的小零件，他們可以讓 hyprland 更加方便實用 (同時也更美麗)：

waybar

waybar 是給使用 Wayland 的桌面/視窗管理器使用的狀態欄。它支援許多自訂選項，可以透過 waybar 的設定檔及 GTK CSS 把它打造成您想要的樣子。

以下指令可以在你的電腦上安裝 waybar :

sudo pacman -S waybar

安裝後您可以手動在終端機執行 waybar 來開啟狀態列，也可以直接修改位於 ~/.config/hypr/hyprland.conf 的 hyprland 設置檔，在任意位置加入這行設定：

# 其他設定 ...
+ exec-once = waybar

這會讓 hyprland 在啟動時自動幫您執行 waybar。

waybar 可以使用位在 ~/.config/waybar/config 以及 ~/.config/waybar/style.css 的設定檔更改它的樣子，你可以在 waybar 的官方文檔找到更多的資訊。

wlogout

wlogout 是一個使用 Wayland 的登入登出選單，可以用它來將電腦登出、重啟、關機或是執行其他指令。

你可以使用下列指令安裝 wlogout :

paru -S wlogout

wlogout 被儲存於 AUR 中，您可以把 paru 換成 yay 或是任何您喜歡的 AUR 助手。

wlogout 擁有一些客製化的選項，你可以編輯位於 ~/.config/wlogout/layout 及 ~./config/wlogout/style.css 的設置檔來自訂它。你可以用 man 5 wlogout 指令來看它支援的設定選項。

不像 waybar 必須於 hyprland 啟動時就開始執行，wlogout 是一次性的指令，你可以使用 hyprland 的設定檔將它綁定到任何一個快速鍵來開啟，像是這樣：

+ bind = SUPER, P, exec, wlogout

這串設定會使你按下 SUPER (通常是 Windows 鍵) + P 的組合鍵時執行 wlogout 指令。

wofi

嘿，在我撰寫這篇文章時，wofi 似乎沒有被原開發者積極的維護，但我執行起來沒有任何的問題。如果您會介意，可以試試看 fuzzel 或 rofi 等類似的程式進行替代

wofi 是一個使用 wayland 的應用程式起動器及選單，它同樣支援 GTK CSS 用以客製化。

使用以下指令安裝 wofi :

sudo pacman -S wofi

你可以在終端機輸入 wofi 以啟動。當然您也可以在 ~/.config/hypr/hyprland.conf 中給 wofi --show drun 一個方便的快捷鍵：

+ bind = SUPER, D, exec, wofi --show drun

你可以把 --allow-images 加入命令列選項中來顯示應用程式圖示。

SwayOSD

SwayOSD 是一個酷酷的小工具，可以在你調整亮度及音量時顯示目前的亮度或是音量大小，也可以顯示大小寫鎖定或是數字鍵鎖定的狀態。

使用以下指令安裝 SwayOSD:

paru -S swayosd-git

讓 swayosd-server 在你開啟 hyprland 時自動啟動：

+ exec-once = swayosd-server

並並將音量按鈕和亮度按鈕綁定到 SwayOSD，打開 ~/.config/hypr/hyprland.conf 並加入這幾串文字：

+ bindl = ,XF86AudioMute, exec, swayosd-client --output-volume mute-toggle
+ bindle =, XF86AudioRaiseVolume, exec, swayosd-client --output-volume raise
+ bindle =, XF86AudioLowerVolume, exec, swayosd-client --output-volume lower
+ bindle =, XF86MonBrightnessUp, exec, swayosd-client --brightness +3
+ bindle =, XF86MonBrightnessDown, exec, swayosd-client --brightness -3

這會讓 SwayOSD 在你按下音量或亮度按鈕時顯示酷酷的 OSD，就像 Gnome 一樣

swayosd-git 被儲存於 AUR 中，因此您可以將 paru 換成 yay 或是任何您熟悉的 AUR 助手。

我撰寫這篇文章時，SwayOSD 並沒有有版本標記的 AUR 套件，只有 -git 版本。

為什麼在選擇 Hyprland 小工具時 Wayland 很重要？

Hyprland 是基於 Wayland 協議的，這是一個比 X11 更安全和現代的顯示協議。因此，舊有的 X11 應用程式無法在 Wayland 上原生運行。

雖然可以通過 XWayland 在 Wayland 上運行 X11 應用程式，但我極度不推薦這樣做，因為大多數情況下程式會變得較慢，而且會出現許多視覺上的問題 (像是 HiDPI 縮放、奇怪的視窗大小)。

當你為 Hyprland 選擇小工具時，請確保它們是基於 Wayland 協議的（比如為 wlroots 開發的工具），這樣它們就能在 Hyprland 上原生運行，不會出現任何問題。

我的 dot files

我有一個 GitLab 儲存庫包含了我對上述套件的設定，以及我的 hyprland 設定檔。你可以點擊這裡來查看。

結語

這就是我對 hyprland 的看法，我希望這篇文章能幫助到您了解 hyprland 並且給了你一些怎麼使用 hyprland 的點子。如果您有任何問題或是建議，歡迎寄一封電子郵件到我的信箱，這個文章底下應該會顯示我的電子郵件。