潮流特區

焦點文章

CyberCom3合1充電數據線 — 一條線搞掂晒，充電超方便！

科技新知
Lifemagtechie・2025-06-12

而家大家手上嘅電子產品多到數唔清，手機、平板、藍牙耳機、遊戲機……每部機都有自己嘅充電線，仲有啲好舊款用USB，iPhone用Lightning，最新又係Type-C，搞到充電時成日手忙腳亂，尤其去旅行，帶幾多條線都唔夠！ 呢條 CyberCom3合1充電數據線，就係為咗解決呢個煩惱而生。佢集合多種接口於一身，無論你係用緊iPhone定Android，甚至其他電子裝置，都可以用一條線搞掂晒，方便又慳位，真係你嘅生活充電好幫手！ 一條線，多種接口，無懼設備多 CyberCom3合1充電數據線支援 Micro USB、USB A、Type C 同 Lightning 四大接口，無論你係iPhone、Samsung定係其他品牌，甚至係藍牙耳機、遊戲機，都可以用呢條線充電同傳輸數據。旅行唔使再帶一大堆線，行李又有位可以擺多啲戰利品啦！ 快充快傳，效率up up！ • 支援QC快充技術，最高60W輸出，手機、平板、智能手錶都可以超快充滿，唔使等成日。 • 傳輸速度高達480Mbps，無論係工作文件定係娛樂影片，一link就傳，節省你寶貴時間。
 耐用又防纏繞，攜帶超方便 • 採用彈性TPE物料，線身唔易打結，收納方便，唔怕亂晒。 • 線材耐用又有彈性，日常用或者出街旅行都好啱用。
 產品小百科 • 1米長度，無論係屋企、公司定旅行都啱用。 • 建議零售價 $99，依家優惠價$79就可以帶走。
 由此開始，充電更快更簡單！ 設計貼心，性能強勁，係你工作同生活嘅好拍擋。無論係手機、平板、遊戲機定藍牙耳機，呢條線都幫你搞掂晒充電同數據傳輸，令你嘅數碼生活更輕鬆自在。了解CyberCom3合1充電數據線嘅詳情同優惠，幫你打造更智能、更方便嘅充電新體驗！購買網站: www.cyberportcom.com查詢電郵: info@cyberportcom.com

最新文章

雲系統的持續更新，大家的選擇是什麼？

科技新知
MacauYeah・2026-01-30

在開始之前，筆者先解釋一下自己對Linux發佈策略的理解。筆者之前以為自己都尚算了解，但到了兩難問題時，才開始反思。所以都不禁懷疑自己的基本觀念有沒有問題，如果大家覺得筆者多少有些理解上的錯誤，請留言糾正。 普通軟件的發佈 主要分為穩定（Stable / GA)， 測試（Edge / Alpha / Beta），特定版本。穩定、測試版本也可能有多個不同的分支，但它們主要是指不同環境下的選擇。通常安裝時，都會安裝最後的穩定、測試，除非最後版本有明顯Bug，我們需要回覆到再去的一個穩定版本。 當我們每次都更新到最後的穩定版本，我們稱之為rolling release. 以docker 官方建議的方式，我們在ubuntu底下，可以看到它的有很多結果回傳。 apt list --all-versions docker-ce Listing... Done docker-ce/noble,now 5:29.1.4-1~ubuntu.24.04~noble amd64 [installed] docker-ce/noble 5:29.1.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.4-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.4.0-1~ubuntu.24.04~noble amd64 ... 我們可以選擇過去某個版本，但通常無腦update，就會去到最後一個版本。 Ubuntu的發佈策略 我們換個package看看，如果只看重要軟件的話，例如kernel，我們沒有什麼可以選擇 apt list --all-versions linux-image-generic Listing... Done linux-image-generic/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed] linux-image-generic/noble 6.8.0-31.31 amd64 apt list --all-versions linux-image-virtual Listing... Done linux-image-virtual/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed,automatic] linux-image-virtual/noble 6.8.0-31.31 amd64 除了可選擇數量外，另一個最大的不同是，kernel的自身版本其實固定在 6.8.0，就算更新，都是同一個版本的ubuntu補丁版，並不是官方kernel的bug fix版。筆者認為，這應該就是所謂的point release的策略。 （如果大家安裝物理機的話，kernel可能會是6.14，筆者大部份都是VM，還是比較舊的版本。筆者保證，6.8.0-90.91與 6.8.0-31.31之間，曾經是有多個不同版本的。但現在沒法下載回來，除非之前大家有安裝過。） 但相同情況，我們找另一個package看看，由 ubuntu 自己打包的docker 版本，雖然可以選擇的數量是有限的，但它們的版本是不斷更新的，而且不是hotfix版，還有大版本更新。 apt list --all-versions docker.io Listing... Done docker.io/noble-updates,now 28.2.2-0ubuntu1~24.04.1 amd64 [installed] docker.io/noble-security 27.5.1-0ubuntu3~24.04.2 amd64 docker.io/noble 24.0.7-0ubuntu4 amd64 雖然版本是跟著官方docker最新版本，但也有持續跳級更新。如果真的要分類，筆者應該會把它歸類為 rolling release。 Rolling release vs Point release 花了一些時間看例子之後，終於開始討論我們自己的更新策略了。rolling release，最主要的原因是，舊版本無人再免費維護了，有什麼bug，都在最新版本中修復，但也因此有機會出現不相容的情況。point release，最主要的原因是為了維持極強的穩定和兼容版本，這亦代表，除官方專家出手，否則很難有舊版本的bug fix。 那麼我們有什麼選擇？ 有point release，當然跟point release，因為程式不可能天天做調整。除非大家想要新功能再升級版本。 沒有point release，就手動自己選擇hotfix版或小版本升級。在升級大版本前，一定要做整合測試。若追求極致的穩定，升級大版本時就不要原機升級，要另起爐灶，似兩個相對獨立的環境並行過渡。如果有container版本，就用container隔離，一般java等都可以這樣建獨立環境。 沒有point release，也沒有可隔離的並行環境：其實 docker 接近這類。對它應的OS層的存取，雖然可以用VM隔離，但通常都不實際。因為重新安裝OS， 設定外部環境，成本很高。docker 在中 lab 並行升級是可以，但投産環境並行真的不實際。沒有辦法之下，筆者還是原機升級。頂多是lab中實現更多的整合測試。

Coding中的AI輔能3 | AI 探索新領域

科技新知
MacauYeah・2026-01-26

繼之前筆者介紹使用AI Chat問一些技術固有問題後，筆者亦試著繼續用AI做一些其他功能探索。 也是先講結論 目前筆者針對自己不熟悉的技術，而且認為已存在，不太可能不存在的技術，叫AI幫忙做事。跟過去一期最大的差別，就是筆者無法快速判斷AI的答案是對還是錯，只能跟著AI一句一句的地執行Code再去找問題。但即使是這樣的情況下，AI還是能提供到有參考價值的答案。 Jasper report studio 參數引用 在預設的情況下，Jasper report studio 的某些參數只可以反映在 SQL Data Source中，其他Data Source並不適合。但即使這樣，筆者還是希望AI找尋一下過去的人有什麼解決辦法。原本的問題，筆者在Google上，並不能找到合適的參考案例，但在問Claude Sonnet 後，反而有案例。實測下，也是有效的。 與搜尋引擎關鍵字不同，在Claude Sonnet中，筆者花了較長的字句去描述問題。也有可能是因為「生成式」的關係，Claude Sonnet 可以生成更多我沒有見過的關鍵字，從而得到答案。而這個答案，非常大機會並不是出自官方的使用說明中。這種就像坊間的用法，可能升級後會突然無法使用。但至少目前可以解決問題。 QEMU 的教學 筆者一直被逼著試用一些新的cloud image，並非筆者認知的傳統VM使用方法。qemu筆者之前有看過官方教學，但實在太長、太複雜，故筆者就把自己的問題拋給DeepSeek-V3，看看它能不能提供一個可行的指令。 結果是可行的。不過要重提的是，筆者雖然對QEMU不太懂，但至少對Cloud image有些認識，知道Cloud image是如何運作，某些image又可能缺了些什麼。針對性地問DeepSeek-V3一些具體問題，結果還可以接受。也幫忙解決了筆者誤會抄下來的指令。 總結 總括來講，這種方法係加大了筆者可以搜索的範圍，AI亦可以做一些自己的嘗試。省卻了自己閱讀大量文章之後再組合的過程。對於一些自己太熟悉，但是穩定的技術，應該會有可行解。 但如果針對一些很肯定資料來源的問題，筆者還是會選擇使用傳統搜索的方式或以AI找出官方來源，自行到官網查證。Fact Check 資料可信性，原本就是這麼做，也會繼續這樣做。AI會有幻覺，傳統的搜尋答案有部份也是來Stack Overflow等討論區，也是需要進一步自行了解。

Steam Deck 運行qcow2 image

科技新知
MacauYeah・2026-01-23

上期我們介紹了如何使用qemu快速跑起三個不同的qcow2，如果你像筆者一樣，相用Steam Deck使測試，它沒有自帶的qemu，那又該如何呢？ Distrobox 幫到你 因為qemu是一個CPU的程序，理論上只要有container，就可以跑起來。因為Steam Deck自帶Distrobox和podman，用它來起個ubuntu的container，就可以下載qemu。 就可行性上，是可以的，只是速度有點慢，筆者想應該是kvm加速沒有生效。 Boxes 幫到你 除了Distrobox，Steam Deck上還有一個神器Boxes，不過它要經flatpak（Discovery）安裝。 Boxes 可以直接運行 qcow2 格式的VM。OpenEuler ，AnolisOS 都順利運行。而阿里aliyun 3，道理上只要經過第一次cloud-init改寫的qcow2檔，搬來Boxes就可以用。不過筆者在實測時，似乎aliyun 3 boot機極之慢，比在qemu要慢而者沒有明顯錯誤代碼。aliyun OS還需要再研究一下是格式問題還是硬件模擬有差異。 為何Distrobox+Qemu可以運行的話，還會用Boxes? 因為Qemu還是有一些學習成本，而Boxes就有齊snapshot等功能，也可以隨時加大hdd，學習成本較低 正所謂，有GUI，還在GUI下探索是王道

想試國産Linux Cloud Image ? 無問題Qemu快速幫到你

科技新知
MacauYeah・2026-01-21

不知道大家最近有沒有在考慮使用國産OS，如果有，大家又是怎樣做初步測試的呢? 筆者之前一直都笨笨的從ISO開始安裝，所以每試不同的版本，都要從零開始。不但重複，OS安裝階段的複制過程也是很耗時的。但其實國産OS，大部份都有qcow2的格式，我們若只是本地測試的話，其實可以利用qcow2來做快速VM生成。 阿里aliyun 之前筆者有介紹過ubuntu的multipass，若你想試用的國産OS就是阿里aliyun，只要你有ubuntu，就可以快速跑起來。 但如果沒有ubuntu，只要有qemu（多平台），也是可以的。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -snapshot \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=aliyun_3_x64_20G_nocloud_alibase_20251215.qcow2 \\ -drive if=virtio,format=raw,file=seed.img 上述指令中的qcow2和seed.img，階為官方網站可以下載的。預設帳號 alinux 密碼 aliyun。 seed.img是用於cloud-init的，就是初始化VM所用。第二次開機時，就不需要再使用seed.img qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -snapshot \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=aliyun_3_x64_20G_nocloud_alibase_20251215.qcow2 華為OpenEuler 同樣地，我們也是用qemu可以跑起OpenEuler，只是它沒有seed.img（不支持cloud init），所以直接跑起就好。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=openEuler-24.03-LTS-SP3-x86_64.qcow2 預設帳號 root 密碼 openEuler12#$ 第二次開機，指令也是一樣。 龙蜥AnolisOS 方式也一樣。 qemu-system-x86_64 \\ -cpu host -machine type=q35,accel=kvm -m 2048 \\ -nographic \\ -netdev id=net00,type=user,hostfwd=tcp::2222-:22 \\ -device virtio-net-pci,netdev=net00 \\ -drive if=virtio,format=qcow2,file=AnolisOS-8.10-x86_64-ANCK.qcow2 預設帳號 anuser 密碼 anolisos 總結 如果只是要體驗一下國産OS，Qemu快速起VM就足夠。但Qemu本身只有NAT網絡，想要做VM之間的通訊，需要大量的學習成本。

Coding中的AI輔能2 | Ai 寫測試用例

科技新知
MacauYeah・2026-01-21

繼之前筆者介紹使用AI Chat問一些技術問題後，筆者亦試著用AI直接參考code的改動。 先講結論 目前筆者只針對自己熟悉的技術，叫AI幫忙做事。那怕它做錯，我也有條件驗證及修正。而結果是，。 優點：它的確有幫上忙，省了我一些時間。省時不多，但有省得不多。總比全人力Google來得舒服。 缺點：很慢，有點鈍。它的答案也可能很直觀，需要手動再調整。 寫測試 為免一下子挑戰太大，筆者先從寫測試開始。使用一個現有的專案，去掉secret等敏感資訊，然後針對新做的function，叫GitHub Copilot 幫忙寫Test Case。Copilot Agent就會開始檢驗你現有的測試，學著你之前的風格，為新的function寫測試。Copilot會結合你現有的程式，也了解一些框架的知識，例如Hibernate Entity, Repository之間的關係，試著寫一個符合你剛才文字表述的邏輯。就是因為這也是一個整體掃瞄和學習的過程，筆者覺得不論付費還是免費的AI額度，可能都會一樣慢。 為什麼要在這個地方上使用AI幫忙呢? 因為Test Case中，通常因應不同的情況，有不同的預設值。很多時，Test Case相似，又無法直接覆用預設值。所以找AI幫忙起草，後期自己再修正一些，總比全力自己設計要省心一點。 Maven pom依賴升級 筆者亦都有試過找GitHub Copilot 解決一些因版本升級帶來的依賴不相容的問題。同樣地，筆者對於這些問題，有一定的了解，只是不想每個版本逐個比較。筆者想靠 Agent 找到相近或相容的版本，結果算做得不錯。這些問題本身沒有難到需要大量Google去做資料搜集，但至少Troubleshoot時，要回憶幾個不同的maven指令。平常pom 版本分析的指令很少機會會用，一時三刻要重新好好理解一下，也是費神。這個場境，似乎AI也勝任，自己最後驗證也簡單。就像解一元多次方程式一樣，找解很費神，但驗證就很簡單。那怕驗證時真要追蹤 pom file，也有IDE幫忙。 總括來講，筆者沒有叫AI大量創作，在控制問題範圍的情況下，免費額度的GitHub Copilot也能找到一些幫助。

Ubuntu 的簡易日常更新

科技新知
MacauYeah・2025-12-17

早陣子跟新認識的朋友聊天，聽到他們因為要轉伺服器平台，煩惱如何做作業系統層面的定期更新。筆者亦都分享一下自己是如何做 Ubuntu OS 層面的定期維護。 沒錢，就用最原始的方式解決 因為Ubuntu也算是常見的linux品牌，所以基本有有商用軟件可以偵測OS的狀態，並針對它推送更新。不過如果你像筆者一樣，是個貧窮的革命家，那就只有土炮一點自己做鏡像點及做測試。 建立一個 ubuntu 的 deb 包 mirror。手動單次地用步 mirror，確保自己其他 server 同一個時間段都只會取得同一個更新。 停了 ubuntu 的 kernal 自動更新。不然的話，mirror 有更新，ubuntu 亦會偷偷地自動安裝了新的kernal，只是等待你的重啟。 使用一個測試機，先經 mirror 更新到最新的狀態。運行一段日子後，其他機再陸續更新。如果你投産環境有多於一種配置，就考慮要多個不同的測試機。更新指令直接做成 script，方便在其他機器中重複。 輪流 ssh 登入各台機，執行相同的更新指令。更新指令經 git 同步到其他機器。為確保不受 ssh 斷線的風除，必要時還需加入 tmux 。 多機器的煩惱 上述的做法雖然可行，不過當你有十台以上的機器，重複做 ssh, tmux, git checkout, script 互動，也是很累人。考慮一次性地全自動化執行，還是有必要的。筆者對上述的第四步驟，作出一些取捨，以確保更新速度足夠快，可以順暢地執行。 什麼是必需要更新的？ 筆者觀察到，在 container 技術出現後，其實很多時安裝應用都不會直接在 OS 層安裝 deb / rpm 包，都是直接經 docker image 去做。所以OS層面，或者很多服務都不會被啟動。筆者亦發現，至少在ubuntu下，只更新kernel，對比無腦全更新所有 deb 包，會快很多很多。 如果可以，我們只更新kernel，再加對應的 container runtime，是不是更新對令相對地穩定，而且可以經外部統一管理。也就是不用在每一台機中進行 tmux + git checkout ，全數在外部推送 ssh 指令？ 筆者就用 multipass VM + ssh key，表達一下執行概念。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get autoremove -y ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get update ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- apt-get install -y linux-generic linux-headers-generic linux-image-generic ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 -- reboot 上述最大的假設，是第一、三步，更新 kernel 時不會因為網絡問題導致 ssh 斷線，因為它們都是系統級別的改寫，中斷後並不能確保可以重來。第二步就很安全，隨時重來也沒有問題。 這樣，我們就可以在任一台管理機，經過一個 shell script for loop，更新所有其他機器。 如果我們對於網絡還是有些疑慮，我們也可以試用一次性排程式的方式去做。 ssh -i /var/snap/multipass/common/data/multipassd/ssh-keys/id_rsa ubuntu@10.115.189.200 echo '/your/script/location' | at 08:00 PM 17.12.2025 這樣的好處是，我們可以連 tmux 的開啟也省略，git checkout 也可以經固定的 script 執行（只是很煩鎖）。但這也會有壞處，就是看不到執行的情況，只能事後檢查系統狀態，是否已更新過。 當然前述 ssh key 的方法也可以加入 git checkout 更加深化不同的更新 script，但這又會增大斷線可能。ssh key 還是以快速完成指令更實際。 註：因為網安原因，筆者把上述 script 中的 S U D O 關鍵字去掉，這樣 blog 才能發出。

你開始寫 Spring Boot 測試案例了嗎？

科技新知
MacauYeah・2025-11-29

雖然筆者過往做 spring boot framework 教學中，都有滲入一些測試用例。筆者也曾經困惑了很長一段時間，所以就獨立開一個主題，聊一下筆者在實務上對spring boot test 的理解。 測試案例究竟測試什麼？ 測試用例 (test case) 是確保你的程式碼正確性與穩定性的重要步驟，但在 framework 下，並不是所有功能都很容易寫成測試。所以在討論 framework 測試之前，釐清測試的本質。 function input - business logic - function output 這意味著我們輸入某些資料（input），然後經過業務邏輯（business logic）的處理，最後產生結果輸出（output）。 我們的測試目標，其實就是確保業務邏輯正確。而我們的手段就是經檢查概定的輸入資料，核對輸出結果。 那麼只要我們可以生成輸入資料，就一定可以檢查輸出結果了吧？其實不是的，因為實務上的輸入和輸出沒有這麼簡單。筆者常接觸到的輸入輸出如下 輸入 function 輸入參數 系統狀態資料，例如：資料庫狀態、外部API結果。 輸出 function 輸出參數 寫入系統（影響到）的資料，例如：資料庫狀態、使用外部API時的輸入參數。 總之就是考慮了狀態機 (state machine) 的問題，每個狀態+外部輸入都是一個測試用例，然後核對狀態機去了下一個什麼狀態。 言下之意，我們就是暴力地生成輸入參數和模擬狀態資料，道理上就是可以進行測試。 Spring boot web framework 中，我們又會測試什麼？ function input - business logic - function output在Spring boot web就變成如下 controller request - business logic - controller response在 Spring Boot test 中，我們可以用模擬的 MVC (MockMvc) 測試來驗證 controller 的行為。不過，其實進入 controller 前經過很多系統轉換，而這些道理上跟Framework的技術大相關，與業務邏輯小相關。所以為免折磨自己，可以將業務邏輯單獨封裝成服務（service）。之後直接測試服務 ，易寫也易讀。 controller request - service input - business logic - service output - controller response道理上 controller 能做的業務邏輯，服務 (service) 都可以無腦重現。這樣還可以重用服務，減少測試的數量。 如何實現輸入？ 直接 new Object。大部份的情況下，因為業務是自己編寫的，應該都可以直接 new 出來。 經 json 檔讀入。如果輸入的參數量太多，逐個經 java new 是很耗時的，我們可以經 json 反序列化變成 Object。但這亦只限於自己可以操作/改寫的類。 Mockito 模擬那些無法簡易經 new 或 json 反序列化的 Object。例如：spring security authentication object 我們在使用時，其實只看到 interface。我們難似自己實現一個可以反序列化的類，那麼我們可以使用 Mockito 來模擬這些資料。一些外部API的結果，我們也可以用使 Mockito 來模擬。 什麼情況下不進行測試？ 有些情況下，我們可能選擇不對某些功能進行測試，原因可能包括對功能的了解不足或是單純的懶惰。以下是一些例子： 僅進行配置的Function：如果你的 Function 只是在 Framework 中填寫配置，而且你並不太了解它的運作原理，可能就不需要進行測試了。例如，Spring boot web 中，需要大家配置一個SecurityFilterChain Object，它要求大家將 HttpSecurity 轉換為 SecurityFilterChain 。因為輸入的 HttpSecurity 是系統固定的參數，我們亦沒有檢查它的狀態。這種情況下，它的輸入及輸出，其實我們都沒有真正理解。我們硬測試的話，測試功能可能只流於表面。若我們真的要做測試，也是經過MockMvc進行端到端測試（end-to-end testing），測試它在事後的影響範圍。 單純的框架功能：例如資料庫的儲存庫介面（repository interface），雖然是在框架下生成的，對於自己手動調整的部份功能，筆者通常亦不會進行單獨測試，通常都會搭配業務邏輯一起進行。它可以使用 Mockito 進行模擬測試，或用測試環境的真實資料庫進行測試。 面對的挑戰 總括來講，筆者盡可能地把測試用例限定在業務邏輯中，就可以大大地降低寫測試的技術難度。但筆者還是有些問題並未完美解決。 測試用例的數量可能很多，因此共用與維護變得相當困難。逐個用例獨立編寫輸入也是很累的。對於 Mockito 的使用，筆者還是可免則免。因為要逐個功能模擬，編寫量就指數提高，這亦難似配合外部變化。一般來說，能優先使用測試環境或者 Docker 來模擬環境的，就盡量用。 離線開發、離線測試。系統依懶的外部功能越多，想做單機開發的難度就越高。即使前述有 Docker 測試，對於持續整合（CI）來講也是有一定難度。那麼這時，Mockito 就是一個可取的選擇。但這又回到編寫量及難以偵測外部變化問題。 希望這篇文章能幫助你更好地理解測試案例的編寫方向，並在Spring boot web開發中加入你自己的測試！

docker swarm 回到最基礎的群集組建

科技新知
MacauYeah・2025-11-21

雖然筆者都知道，全世界在講 k8s ，全世界都叫筆者放棄 docker swarm，但無獨有偶，docker swarm 還是有使用的價值。 你只有單個服務在運行，只想要做冗餘或分流。快速地用 docker swarm 做最小可行性産品，推出市場。 傳統的HA功能做到了，但你沒有中央匯整日誌的功能。而你也不想把事情攪得太複雜，使用docker swarm 可以讓你在任何一個管理節點上查看不同 container 的日誌。 你的客戶只提供VM，他可能有自己的k8s平台，但不讓你使用。自建一套docker swarm ，先入場，事後擴展再要求客戶提供k8s，對於客戶來講，先證明系統是有價值的，在金錢成本上或能力上，一定是件比較可以接受的事。 筆者之前介紹過一系列的 docker swarm 教學，但生成群集的部份一直沒有做介紹。因為實在太簡單，所以一直都沒有收納在教學內容當中。但現在考慮其完整性，以及為了讓大家感受一下它有多簡單，所以重新寫了組建群集的步驟。 組成群集 以前各家不同的軟件，想要起一個群集，要左攪右攪，又要重啟。而docker swarm真的很簡單，只要各機中有 docker ，再在各機中順序打指令就好。 node 1 使用docker swarm init docker swarm join-token manager # node 1 > docker swarm init > docker swarm join-token manager To add a manager to this swarm, run the following command: docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx:2377 其餘的管理員節點就根據上述的提示，使用 docker swarm join --token SWMTKN-1-xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx:2377 就好。只要總數的管理員節點有奇數個就可以了（包括當初的node 1）。即是1、3、5等都可以。這是因為在容錯的情況下，必需由管理節點作出多數決，才能容易地知道判斷是哪些節點出現問題。 如果不為容錯，只想增加可工作的機器，那麼我們只需要增加工作節點。我們可以在任何管理員節點生成docker swarm join-token worker > docker swarm join-token worker To add a worker to this swarm, run the following command: docker swarm join --token SWMTKN-1-yyyyyyyyyyyyyyyyyyyyyyy yyy.yyy.yyy.yyy:2377 若想要檢查各個節點的工作狀態，在管理員節點上執行 docker node ls 看到了。 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION xxxxxxxxxxxxxxxxxxxxxxxxx * node1hostname Ready Active Leader 28.5.1 yyyyyyyyyyyyyyyyyyyyyyyyy * node2hostname Ready Active Reachable 28.5.1 全部教學請見 https://macauyeah.github.io/AProgrammerPrepares/VMDockerNotes/SwarmModeCommandCN.html

codeserver 在團隊間開箱即用就是最大的好處

科技新知
MacauYeah・2025-11-20

之前我們就有探討過 vs code 與 codeserver 的差別，初步結論就是 vs code 的 debug 功能比較完善。如果大家懂得 devcontainer 的使用形式，使用 vs code 應該可以得到最大的效益。就在筆者想跳過 codeserver 的時候，又有新朋友對 codeserver 有興趣。最主要的原因還是它可以一體化預安裝所有事，若大家使用筆者的image，有 docker 、有瀏覽器就已經可以開箱即用。 所以這裏，筆者也重新翻新了筆者版本的使用說明。有興趣使用的朋友可以直接跟 github readme 試用。 https://github.com/wingzero0/codeserverUbuntu 本次翻新，主要加入了常見問題。這些問題部份與 docker 的基本限制有關、部份則是筆者的 env 所限。 常見問題 FAQ 運行 node 應用時很慢 在 windows / mac 下，它們的 docker 是經過 VM 建出來的。若使用 bind mount ，其實是經過 VM 層面抄資料夾。普通 java 開發沒有大問題，但如果遇上 node_module ，就會出現極大效能問題。 node_module 最好還是放在 container 內的 mounted volume 中。本 project 預設的 docker-compose.yaml 就已經有 /home/ubuntu/sourcecode mounted volume ，有需要可以放在其內直接使用。 linux 則沒有這個問題，因為 docker 只是 linux 的一個 process ，可以直接連到資料夾。 mounted volume 權限問題 如果大家自定義 mounted volume ，注意 docker 預設會是 root 權限，本系統使用 local user ubuntu，有需要改為它。 chown -R 'ubuntu:ubuntu' YOUR_TARGE_FOLDER 若然code-server異常，需要重啟。在 host 可以使用 docker command，在 container 中，可能殺掉所有 process # at host, outside of code-server docker compose -f docker-compose.local.yaml stop docker compose -f docker-compose.local.yaml start # at container, inside of code-server killall5 -9 上/下載 上載檔案：可以經過拖拉的方式，把桌面的檔案拖進 code-server 的 Explorer 區域。 下載檔案：可以點選 code-server Explorer區域內的檔案，按滑鼠右鍵，選 Download 。

為何 VueJS 除錯如此麻煩？

科技新知
MacauYeah・2025-11-04

前一次，筆者分享了VS code debugging frontend的好功能，也確實了coding anywhere並不是一個普通的notepad + language server就可以解決的事。我們還要考慮如何debugging (除錯）的問題。 雖然筆者知道 vscode 可以解決問題，但為何 最原始的 nodejs debugger 不能解決問題。如果node debugger 不能解決問題，那麼 vscode 又做了什麼，它可以解決問題？經過一輪的實驗，筆者懷心疑，也許，強大的並不是 vscode 本身，而瀏覽器才真正的做到 debugger 的功能。而 vscode 只是以更方便的方式，重現那些結果。 為何 backend 的 debugger 不發揮作用？ 筆者舉例，現時有一個 vue 3 專案，使用官方建議的方式生成 $ npm create vue@latest 這個專案，在開發模式下，會以 vite 架起一個端口為 5173 的伺服器，讓開發人員可以經過瀏覽器看到vue內容。筆者一直都認為，只要在 vite 的指令中插入 inspect 參數，一切就可以成功，就像 nodejs 一樣，只要在開始時加入參數就可以。結果當然是不行的。 經過對比 VueDevTools 的參考功能，筆者發現了一個出發點的問題。vite 其實是一個伺服器級的程式，也許它只是負責把所以 vue + js 動態轉成常見 js，就像 webpack 一樣。我們想要設的中斷點，都不在它的程式上，所以 debug 參數也沒有用。實質，我們要加的中斷點，其實要在客戶端上，也就是瀏覽器上。那因此，VueDevTools 也不包括那些功能。它只是好好地記錄了每個 vue component 或 js 是如何被改寫的過程（就像被 webpack改寫的過程）。 官方又是用什麼來除錯的？ 既然我們知道了問題所在，就要看看傳統的 javascript 又是如何除錯的。實際上，因為瀏覽器的配合，設立中斷點的功能，原來早就實現了。 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger 只要我們在任何 javascript 地方，插入 “debugger;” 這個神奇的字，瀏覽器就會在inspect模式下，自動產生中斷點。之後，你可以控制瀏覽器進行watch / step into / step over 功能。絕對比console.log更有意義。 在發現了這個方法之後，回去找vue3的官方文件，驚訝地發現，它就是提議用這種方式進行除錯。 https://vuejs.org/guide/extras/reactivity-in-depth.html#reactivity-debugging 未解之謎 雖然我們找到了設定中斷點的方式，但對於vscode是如何做到客戶端、伺服器端通用這件事，筆者還是沒有了解到。就以現在的知訊來看，很大機會就是vscode操控了瀏覽器的除錯模式，把所有資訊都回傳了vscode本身。這也是解譯了為何vscode在起動debugger時，必需要由vscode自己叫起瀏覽器。而codeserver這類雲IDE無法叫起本地瀏覽器，就造成它無法運用除錯功能的原因。 有與趣為codeserver一起搵解決方案的朋友，可以到筆者的 https://github.com/macauyeah/AProgrammerPrepares ，以文字教學的方提交你的解決方案。 祝願大家可以早日實現coding 自由。

Spring boot web api 異常處理

科技新知
MacauYeah・2025-10-28

我們在編寫程式時，經常會遇到一些極端的情況，不會經過 function 的方式回傳結果。例如一個 function 原本是提供讀檔功能，但用戶傳入的並不是一個有效的檔案路徑，又或是誰路徑權限不足，無法讀取。這些不正常的結果，並不是原本 function 所協定的回傳值。那麼，我們會拋出異常 Exception ，中斷所有被呼叫中的 function ，讓上層用戶去考慮怎樣處理這個問題。 在 Web API 中，這些 Exception 就更常見。要求用戶傳入的參數，用戶就是有時候少了幾個。覆寫資料的時候，原本的資料已被刪除。但我們現在是經過 Web Api，不能像過去一直向上拋出異常就能通知用戶。我們需要的，是把異常轉成對應的 Http Status Code，讓用戶端可以快速識別異常的類型。 java 異常對應 Http Response Code 其實在 spring boot web 中，要做轉譯，是很簡單的。在定義 java Exception的時候，若有@ResponseStatus，spring boot web 就會自動回應對應的 http error code。 @ResponseStatus(HttpStatus.FORBIDDEN) public class CustomAuthenticationException extends RuntimeException { public CustomAuthenticationException() { } public CustomAuthenticationException(String message) { super(message); } } 以後，任何一個地方拋出 CustomAuthenticationException （假設上層沒有人攔截）都會把該 Controller 的結果改為 http 403。Spring boot 也很聰明的，把異常中的 message 隱藏 ，免得有網安的問題。 若我們定義 Exception 時，沒有@ResponseStatus，Controller 就會變成 http 500，例如我在 controller 中拋個常見的 IOException，這次的結果就會變成 http 500。 @GetMapping("/api/ioError") public String forceIOException() throws IOException { throw new IOException("force io error"); } 如果某些時候，我們想使用 java Exception 中的 message 欄位作為報錯信息，讓 http 客戶端，可以通過固定的 message 檔位找到問題訊息，我們可以在application.properties中，加入server.error.include-message=always。(有些特殊情況，在開發模式時 mvn spring-boot:run ，已經可以見到有 Exception message，但在投産後java -jar又看不到。主要因為開發模式中， pom 有 optional spring-boot-devtools，會自動加入了server.error.include-message=always，但 mvn package 後就沒有，因為 runtime 沒有 spring-boot-devtools 的覆蓋。) 額外處理 異常處理除了想控制 http status code 外，有時還需要做一些額外處理，例如發出通知郵件等。若想做額外處理，需要另做一個 @RestControllerAdvice 的類，在接到指定的 exception 時，可以轉換不同的 http code ，而且還可以執行額外 java code ，改變 http ResponseBody 。 @RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(value = RuntimeException.class) @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public Map handleRuntimeException(Exception ex) { return Map.of("ret", false, "anyfields", ex.getMessage()); } } 但要注意，一旦使用@RestControllerAdvice 後，就要考慮有沒有改變了某些預設的行為。例如上述的@ExceptionHandler(value = RuntimeException.class)，代表所有RuntimException.class的子類，都會歸由該 function 所處理。當然，你也可以多加幾個 function 來處理不同的子類。 Reference spring-boot-web-api-validate

Visual Studio Code 才是 coding anywhere的基礎?

科技新知
MacauYeah・2025-10-25

筆者過去就有發表過使用 VM / docker + code server 作為 coding anywhere的基礎， 現時也有一直使用。code server 有效，但對於Web App 開發，仍有所不足。 那個藏在瀏覽器的IDE - Code Server 使用 code server 的好處，就是筆者只需要一個有瀏覽器的客戶端，就可以連線到雲上的VM中使用 code server 。不論多重的功夫，交給外部的雲去做，自己的客戶端就可以盡可能輕便。不想自己攪一套code server開發環境？github codespaces in browser 也是一個很類似的替代器。它也是隨時經雲建立一台專用的 VM，之後就可以經瀏覽器進行開發。 一切看來都很好，所有東西都可以在 VM / docker 中進行。如果你的 VM / docker，可以有齊所有除錯工具，應該就真萬能了。現實就是不太美好，因為雲上的 VM ，docker 中的容器，主要都是沒圖形介面的。如果你想要利用的除錯工具，例如 chrome，你就未必可以順利在 headless VM / docker conatiner 中安裝了。很多除錯工具，要麼就需要圖形介面，要麼就要有條件連到本地硬碟，所以筆者就 code server 本身，真的沒有太多解法。 Web App 開發，回到原始的基本步 - Visual Studio Code 回到原始的基本步，本地Visual Studio Code + VM / docker ，就好好地可以利用本地的 chrome 等進行 NodeJs 的除錯。它就跟本地Visual Studio Code + 本地開發類似，本地能用的 chrome，可以經過 vscode 連到 VM / docker 內，只要Remote Development 插件就可以了。筆者測試過，真的很簡單，vscode連線後，會在你的VM / docker 內，安裝一個很細的 client。然後其他事就像本地開發一樣了。Remote Development 除了用自己的VM外，官方還稱它可以連上github codespaces。筆者就未有詳細測試，有興趣的朋友可以建立一個codespaces看看。 雖然 Visual Studio Code 並沒有保證完整地解決所有問題，但至少它提供了一個橋樑可以作為接口開發。coding anywhere 還是有條件實現，只是我們的客戶端並不如一開始的單純，只少要有一個完整的桌面電腦環境OS ，可以做到 port forward，做一些簡單的對接。只是單純的移動端 Web 界面，就未能夠做到那些複雜的跨機轉譯。

熱門文章

  1. 陽光．海風．老街．咖啡香：今夏澳門最有feel新玩法
  2. 【專業造型工具登陸澳門｜Beauty World系列助你輕鬆打理完美髮型】
  3. 【開箱】真實測評：快充+多設備兼容！一條搞掂嘅 CyberCom 3合1 充電數據線
  4. 澳門2026年1月20場表演終極攻略
  5. CTM Home Media x hmvod 帶您重溫《侏羅紀》經典系列

熱門關鍵字

湾湾我来了 灣灣我來了 全球華人最具影響力的台灣自由行媒體
文創遊樂場 // 米米 Esther Lim 愛小城美食,特色 建築物和休閒生活。
PP爸爸的日常
海闊天空 // Sio 一個女生，遊歷半個地球，獨自走過澳亞歐非南北美，進過撒哈拉、闖過亞馬遜、踏過天空之城、越過天空之鏡；路上學會法文西文，戀上一個拉丁情人......
綠星人 // 離子 皓愛結合環保與創意，融合生活與大自然，凝造綠色生活，同時反省自己多年來破壞地球的罪行。