文章列表

雲系統的持續更新,大家的選擇是什麼?

科技新知
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等討論區,也是需要進一步自行了解。

想試國産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也能找到一些幫助。

2025 個人年度模型總結(下)|唔上唔落,特別有愛再入手系列

手機‧電玩
MacauYeah・2025-12-25

SDEX 巴巴托斯天狼座 / SDEX 命運 不過這一兩個模的問題,而是整個SDEX都需要大量補色。雖然外型不錯,強行把玩還是可以的。但因為工作量問題,沒有時間或者耐性,就盡量不要碰。想要練手嘅朋友反而可以多買。 EG Nu 主體套件是沒有問題的,問題就是官方一直沒有推出配件包。筆者試過買Fake Nu 背包,能安裝,但會有重量不平問題。正式配件包,據說下年是會推出的。有愛可以考慮先團主體,然後等配件包,避免事後加價。不想等的話,可以買副廠配件包也可以。那為何筆者會買它呢?主要是初期練手刻線為主。EG的特點是造型可以,但板件數不多,可以快速到實驗你想試的事。 HG EXIA 舊模,純情懷向,需要補色。第三方水貼亦唔見有,真係要靠自己。可動唔算好好,但得益於輕裝甲的設計,裝甲干涉唔多。能做完還是很有吸引力的,但真的要花功夫。 RG Wing Zero EW 天使翼有一個很特別嘅吸引力,上支架可以做出好多華麗嘅造型。因為呢款係舊款RG模型,所以有軟骨問題,好在佢唔係走Seed 系路線,靠一雙翼都可以有好多變化。硬要走手持巨炮的路線,就要考慮使用多支架。 HG Mighty freedom 去年劇場版模型,雖然係新設計,拼裝體驗是很好的。但外型對比MR魂,榮耀防衛者有一些決定性的缺陷,翼的張開角度沒能完好配合身體。除非大家識自行改造,如果唔係背包會有少少奇怪。平時亦需要支架支撐。 原本還有兩隻想介紹的模型,不過因為真係純粹吐槽,就不介紹了。今年嘅分享就到呢一度,新嘅一年,祝大家心想事成,事事順利。

2025 個人年度模型總結(中)

手機‧電玩
MacauYeah・2025-12-24

續上編分享,繼續曬一下筆者推薦的模型 HG 炮型脈衝 呢一款係筆者第一款買嘅PB 模型。因為算係新生系列中比較舊嘅款,所以若要效果好,就要大量補色。而且因為係PB,所以說明書說上沒有官方作例,筆者只可以參考RG模型作補色。 另外,筆者都做咗一個嘗試,就係加入花紋貼紙(RG 借來的),整體即刻提升咗一個層次。所以若果唔想做太多功夫嘅朋友,都可以搵搵有冇第三方水貼。 HG 命運 呢款係模型圈裏面唔少人推介嘅模型,有些玩家都話可以直接平噴,唔需要做複雜嘅遮蓋上色。筆者就理解為,對於素組玩家嚟講應該更友善,唔需要自己補色。筆者製作之後,覺得翅膀還是有點素,如果唔買水貼嘅話,要喺翅膀補色落返啲功夫。 整體可動性唔錯,但唔可以同MR魂比,翅膀比較受限,大刀同大炮亦冇MR嗰種局部放大的設計,如果你按照MR官圖去拍攝,你可能會覺得HG 少咗一份氣勢。除此之外都算正常發揮。 HG 維爾達 便宜好物,只要你識補色就可以。呢款模型有一啲白色或者奶白色嘅補色貼紙,真係要落筆補色要考慮遮蓋力問題。想偷懶嘅話,用返貼紙亦都OK。其他部份都係深灰色補色,遮蓋力,一般都冇問題。因為肩甲上邊有花紋,前裙甲亦係特殊造型,唔需要特別買水貼去提升線條感。 HG GQuuuuuux 今年嘅新作品,結構真係好特別,冇進行補色,亦冇滲線,整體顏色已經好鮮艷。 唯一比較難接受嘅,就係佢嘅頭部造型。如果你接受到造型嘅話,只要唔係價錢出現溢價,都可以買。最近(年底)亦見到有價格回落嘅情況,所以係一個好好嘅出手時機。 和模線 塔斯提爾 上年發售嘅國模產品,筆者今年先正式完成。和模線唔算係一個內卷廠商,無合金骨架,但係佢嘅設計嘅産品都仿人形,比例做得唔錯,構造有心思,體驗好過魔動核好多。唔洗補色,亦唔使靠水貼去提升細節。部份地方有蝕刻貼,只限於眼睛部份。 值得推薦的部份已經講得差不多了,下一期就介紹一下筆者踩過的坑。

2025 個人年度高達模型總結(上)

手機‧電玩
MacauYeah・2025-12-23

筆者呢一年都不斷分享製作模擬經驗,但就好少分享自己嘅作品。其實筆者今年都砌咗相當數量嘅中小比例模型,主要都係集中喺 1/144嘅比例。 因為大部份都係過去嘅商品,所以筆者就唔做年度最佳的評比。就係針對筆者個人嘅收藏目標,推薦一啲筆者認為有質素嘅商品。筆者同大眾嘅審美不太一樣,最主要因為筆者考量自主站立嘅關係,例如好多大背包機體,對澳門土地資源短缺環境,長期保存嚟講都係唔合適,所以呢類都唔係筆者收藏的首選。最後入圍筆者嘅名單,通常係一啲輕型機、人型機。 HG 新生紅渣古 UC 元祖呢個系列,代表住最原始嘅設計,對於玩慣後期系列嘅朋友嚟講,紅渣古真係好樸素,就係因為呢種樸素令佢身上面嘅線條設計比較獨特,再加上佢係圓面裝甲比較多,佢所需要嘅製作加工工序唔多,簡單加深刻線,唔需要補色都已經有好高完成度。 HG 不朽正義 上一年嘅劇場版機體,如果你依家買嘅話價錢應該係回落到一個好合適嘅價錢,佢同其他主角機唔太一樣,因為佢背包係得兩片細細嘅翼,想要站立係好容易。加上佢係匕首格鬥機,玩法比較特別。而且係新嘅設計,補色亦無rising freedom 咁多,好適合爽砌爽玩。 HG 無限正義二式 如果背包嘅規則嚟講,呢台機應該係唔符合筆者嘅標準。但因為呢部機嘅背包,係一台小飛機,可以單獨拆出作為展示。就展示+可玩性,一齊考量,整體都算唔錯。(除咗價錢比較硬之外。) 原本mighty strike freedom 都想列入其中,但最尾還係除名。考慮榮耀防衛者,對於整台機體的展示方式,收納時候好臃腫,分開展示,主體機又顯得好肥,而且背翼展開,對於MR魂,的確差咗一個等級,所以呢台機就冇推薦。 EG Build Strike Exceed Galaxy 簡單粗暴特別。 因為筆者喺素組嘅途中整壞咗頭部,所以用咗其他棄件代替。亦因為咁,意外地創造咗一種新感覺。因為呢個系列係鼓勵自由組合,整出嚟效果唔會太差。不過就係EG嘅關節容易損壞,所以把玩要很小心 EG Perfect strike 不過不失。背包雖然重,但係因為有大件同埋大炮可以作為支撐,收納情況下,可以自主站立(當然上支架可以更挺),對比筆者過去舊有嘅RG, EG呢一款雖然細節比較少,但比較硬淨。RG 多年之後好多件都要落膠水黐死,EG 相對冇咁容易鬆脫。站屍一流。 本年度筆者還有其他推薦的模型,不過需要時間慢慢找出來拍一拍。有興趣的朋友記得留意筆者的更新。

Coding中的AI輔能

手機‧電玩
MacauYeah・2025-12-20

早排跟一位外國的朋友聊天,發現對方公司大力地推動開發工作與AI結合,而且實務上亦幫到忙,可以解放生産力。 既然大家在AI上有得益,筆者亦試用一下。就礙於安全性問題,目前筆者暫時都經過chatbot的發散問題的方式,問AI取得方向性的建議。以下,筆者就分享一下自己的使用心得。 Github Copilot Chat 道理上可以直接安裝VSCode上,但不知道是否不版本更新問題。筆者的Ubuntu 24.04 VSCode 無法運行。反而匯出vsix 後,筆者的codeserver (open source VSCode) 可以運行。 有相同問題的朋友,可以留言找codeserver的詳細安裝方式。 初次使用下,GPT-5 mini 的性能不錯。作為發散問題,可以幫筆者快速地梳理筆者想要了解的技術。(前題是這個技術很成熟,只是筆者不太了解) 例如:筆者會問它關於一些 builder pattern 的必要性。與原本的做法有什麼差異。通過一輪來回對答,筆者對於使用情境也有一個更全面的了解。相對於傳統,筆者要多輪Google,之後再在腦海中梳理再追問,的確快好多。 GitHub Copilot Chat 唯一的問題是,免費的額度需要每個月才會補充。長期用需要付上月費,而且它內置的Model並不包括 DeepSeeks 和 Claude。 我們可以經API KEY隨時加的外部的Model,不過這就等於我們需要多頭付費,GitHub 充一份錢,外部算力也是。 Poe.com 因為筆者暫時也只是使用開放式問題,做一些思維上的整理。筆者還試過 Poe 的第三方Claude Bot。除了策略問題外,範例寫Code效果也行。(當然是限制在筆者未了解,但其實已面世很久的技術。如果好像現在問它一個spring boot 4的問題,就不太推薦) 由於不是直接由Bot改Code,所以算力消耗不高,Poe也每日補充免費額度,可以更方便用來試水看看。 還想用AI嗎? 筆者直接給答案,想,很想。不過這並不代表我們就輕鬆很多。 對於傳統開發框架,我們還是要先理解、學習。就算未來筆者試用Bot生成Code,筆者還是要負責驗證的部份。驗證的能力,其實就是基於過去的理解和學習。面對一些新問題,筆者還是需要去官方網站找實際的資料、範例,以判斷AI生成的結論是否合理。也依靠這些資訊去修正AI的結果。 對於筆者已知的問題,若筆者過去的專案已有答案,筆者還是寧願自行複制貼上,去做一些手動修改,去適配新的場景,因為這需要的驗證工作量還更少,風險更低。

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開發中加入你自己的測試!

重入膠坑12-快靚正

手機‧電玩
MacauYeah・2025-11-27

筆者今年度,在高達模型制作上,一直針對在分享非噴塗的制作技巧之中。這主要是因為筆塗或素組所需的工具比較單純,而且筆塗使用水性顔料之下,更不會有異味出現,可以在家中安心操作。之前亦提過素組打磨對於對於水口覆蓋的極限問題,亦一度讓筆者認為[純素組打磨]是貼錢買難受,因為時間花出去,但效果不盡人意,還不算直剪不打磨。 經過一段時間的快速組合後(其實是筆者山積太多,所以快速清山積),筆者盡可能跳過那些效果不佳的步驟,保留一些更差異性明顯的工敍,嘗試做出人工花費少,但自己還能接受的作品。 不做取件表-但留意分部制作 雖然做取件表可以讓自己未來可以更專心剪件、規劃。但除非取件表是他人預制好的,或是自己要重複做同一款高達,不然自己弄,是很耗時間的。如果各位制作的只是HG的量,其實分部位直接剪,也很容易做到減少換版的次數,所以取件表可以不做。 不全部刻線-滲線後再執漏 不刻線,直接滲線,效果一定不完美的。但全部刻線,成本高,容錯也低。筆者經過三隻模的測試,似乎不刻線情況下,可以通過拭擦方式,取得7成的水性顔料滲線成功率。剩下的,就乖乖重新刻線再滲線。整體省了時間,不過就是要接受某些線修可以粗幼不等。這樣做的還有另一個大好處,就是減少刻線的出錯。 點綴式的膠貼或水貼 如果大家制作的作品,原本就有送貼紙(例如RG),一定要記得貼。如果沒有,也可參考市場上有沒有第三方貼紙。如果你買的是HG,雖然第三方水貼只是給RG用,但其實你也可以借來用於HG上。肩位,裙夾位,盾位,腳位,也是點綴的好地方。 薄刃剪二刀流 如果想不打磨,二刀流手法是必不可少的。只使用足夠鋒利的剪鉗,直接使用二刀流也可以大大地減少水口發白的情況。第一刀要保留足夠多的流通,避免拉扯。第二刀貼著水口再剪時,就要足夠慢,減少形變而産生的發白。二刀流可以變為多刀流,看大家需要。神之手也就很推薦的,但始終也是消耗品,如果有價錢上的考慮,可以投資低價位的薄刃剪。水口大一點,小一點,差異不太大,只要不發白,薄刃剪的效果就發揮得好了。 UC系列和最新的HGCE系列 不想補色的話,最好考慮元組的系列,因為結構簡單,所以原本分色做得還不錯。而最近的HGCE,分件也越做越多,想偷懶也是可以的。不過就2018之前推出的非元祖HG,大家就真的慎入,補色工作跑不掉。

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 自由。