搜尋

搜尋結果

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的結果。 對於筆者已知的問題，若筆者過去的專案已有答案，筆者還是寧願自行複制貼上，去做一些手動修改，去適配新的場景，因為這需要的驗證工作量還更少，風險更低。

重入膠坑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

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

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 界面，就未能夠做到那些複雜的跨機轉譯。

比 Java Mail 更簡單的 Spring boot email
科技新知
MacauYeah・2025-10-24

使用 Spring boot 對接 SMTP gateway 發 email ，相對是容易的。 基本上，它就是會使用自建的 org.springframework.mail.javamail.* , 對接 javax.mail.* / jakarta.mail.* 以前的所有設定值 ，都可以經 spring.mail.properties.* 傳入 例如 spring.mail.properties.mail.smtp.auth=true spring.mail.properties.mail.smtp.ssl.enable=true spring.mail.properties.mail.smtp.socketFactory.port=465 就等於過去 java.util.Properties props = new java.util.Properties(); props.put("mail.smtp.auth", "true"); props.put("mail.smtp.ssl.enable", "true"); props.put("mail.smtp.socketFactory.port", "465"); 一個最簡單可以連去 google smtp 的簡易 code 如下 ### application.properties spring.mail.host=smtp.gmail.com spring.mail.port=587 spring.mail.username= spring.mail.password= spring.mail.properties.mail.smtp.auth=true spring.mail.properties.mail.smtp.starttls.enable=true // SpringBootEmailApplicationTests.java @SpringBootTest class SpringBootEmailApplicationTests { @Autowired private JavaMailSender javaMailSender; @Value("${spring.mail.username}") private String fromAddress; private static final Logger LOG = LoggerFactory.getLogger(SpringBootEmailApplicationTests.class); @Test void contextLoads() { try { SimpleMailMessage mailMessage = new SimpleMailMessage(); mailMessage.setFrom(fromAddress); mailMessage.setTo("XXXXXXXX"); mailMessage.setText("this is backend email trigger for spring boot"); mailMessage.setSubject("spring boot test mail"); javaMailSender.send(mailMessage); } catch (Exception e) { LOG.error("Error while Sending Mail"); throw new RuntimeException(e); } } } github 原始碼 https://github.com/macauyeah/spring-boot-demo/tree/main/spring-boot-tutorial/spring-boot-email

高達模型，不噴塗還有什麼選擇？
手機‧電玩
MacauYeah・2025-10-09

之前筆者就高達模型中，籠統地比較不同的1/144比例產品。現在筆者也正式入手更多不同的系列，看看有沒有哪些適合不同需求的玩家。 SD系列：Mobile Join Gundam 明盒盒蛋，拼裝模型，但不需要剪鉗也可以隨手取件。要補色、滲線或進行一步加工制作。優點是可動性高，官方有提供補色貼紙，但距離足夠分色，還是有一段距離。 筆者並不在意它的分色不完美，以這個不足百元的商品來講，可動性足夠讓筆者快樂一個下午。 SD系列：FW Gundam Converge 明盒盒蛋，有少量件需要拼裝，大部份都已經有預塗裝。因為制作比較精緻，人氣商品比MJG會再貴一點。但可動度就很低，幾乎只有手臂、手碗、頭的平轉，腿腰不可動。筆者購入這個系列的原因，主要是當時已經無力再自行塗裝，把它當完成品直接買回來當擺設，也是一番享受。 兩者二選一的話，筆者更偏好MJG，因為有可動性，強行把玩也勉強可玩，一起擺場景也更耐玩。而FW的話，它的優勢反而是選擇多，方便整個系列收藏。因為有塗裝，而且有少部份可動，想拍照也不是不可以，耐玩度不高就是了。 FW就筆者跟朋友交流，在另一個系列MSE的出現下，FW似乎不太受樂。不過筆者未入手過MSE，難以作比較。但外觀上，似是MJG的另一個版本，但沒有骨架。

Spring Boot Web App 更新期間的維護模式：從唯讀到全鎖的解決方案
科技新知
MacauYeah・2025-08-25

在營運 Web App 的時候，雖然我們有 Docker / K8s 可以滾動更新，但難保用戶在更新的過程中，有一半訪問去到了舊版，另一半去了新版。如果可以，Web App 本身自帶維護模式，可以自我判斷什麼時候應該忽略新的訪問，當然最好。但要做到這一點，前期需要很多規劃。狠心一點，可以直接關掉對外的服務，讓用戶無法訪問。 但在另一些情況下，例如升級/搬遷的情況，下線時間比較長，完全關掉服務並不是一個很好的方向，我們至少還可以提供唯讀的選擇。而且這個可以從資料庫出發，讓 Web App 少處理一點邏輯。 如果 Web App 背後的資料庫是 MSSQL 或 MySQL，唯讀這件事應該是簡單的，只要你把 service account 的權限改變就好。但如果你用Oracle，就要想想辦法。 筆者想到的方法，暫時有兩個。第一個就需要大家寫寫 Script ，一口氣把所有 Table 給鎖起來。例如: 第二個，就是生成一個新的唯讀 User schema，給他所有Select的權限。然後更新 Web App 使用那個唯讀 User schema存取資料。 兩個方法有什麼差異呢？ 前者就全部鎖起來，沒有任何一個資料庫用戶可以改寫資料。如果你的業務沒有差異性，全部一起封起來就完事。但如果你只想 Web App 轉成唯讀，但其他背景程式還可以執行更新。那你就只能用後者了。但後著也不是百分百的完全無痛，至少你 Web App 要支援登入與操作的 Schema分離。 例如用Spring boot JPA的話，可以在 application.properties 可以讓登入及操作的Schema不一樣。 spring.datasource.username=READ_ONLY_USER spring.jpa.properties.hibernate.default_schema=ORIGINAL_SCHEMA 又或者在 java 層面指定。 @Table(schema = "ORIGINAL_SCHEMA") 這看上去，是很有彈性的。但其實也是有些局限。如果你本來的JPA有寫特制的 JPQL 或 Raw Query，又或者你在Java層面加了 @Subselect，由於這些都是程式原作者所 hard code 的，JPA沒法幫你改寫。改來改去，可能還是前述寫Script的方法，一口氣把所有 Table 給鎖起來實際一些。 Reference 更多筆者的程式開發分享，見請 github

Swarm mode 上線 7 - load balancer | 反向代理 (2)
科技新知
MacauYeah・2025-07-18

前幾天，我們就使用traefik做了個最簡單的http反向代理。 做完上述的使用驗證後，我們可以正式開始看官方的例子，該例子加入了SSL，這就更充份地體現反向代理的用途。 官方教學連結 官方的yaml也很長，筆者實測了一個簡化版本。 services: traefik: image: traefik:v3.4 ports: - target: 443 published: 443 protocol: tcp networks: - traefik_proxy volumes: - /var/run/docker.sock:/var/run/docker.sock:ro configs: - source: dynamic-tls.yaml target: /dynamic/tls.yaml secrets: - source: certs-local.key target: /certs/local.key - source: certs-local.crt target: /certs/local.crt command: - --api.dashboard=true - --log.level=INFO - --accesslog=true - "--providers.file.filename=/dynamic/tls.yaml" - --providers.swarm.exposedByDefault=false - --providers.swarm.network=traefik_proxy - --entrypoints.websecure.address=:443 - --entrypoints.websecure.http.tls=true deploy: replicas: 1 placement: constraints: - node.role==manager whoami: image: traefik/whoami networks: - traefik_proxy deploy: labels: - "traefik.enable=true" - "traefik.http.routers.whoami.rule=Host(`whoami.swarm.localhost`)" - "traefik.http.routers.whoami.tls=true" - traefik.http.services.whoami.loadbalancer.server.port=80 networks: traefik_proxy: name: traefik_proxy driver: overlay attachable: true configs: dynamic-tls.yaml: file: ./dynamic/tls.yaml secrets: certs-local.key: file: ./certs/local.key certs-local.crt: file: ./certs/local.crt 餘下的就照跟官方設定 生成cert file。（或大家有正式的證書，就可以免去這一步。） mkdir -p certs openssl req -x509 -nodes -days 365 -newkey rsa:2048 \\ -keyout certs/local.key -out certs/local.crt \\ -subj "/CN=*.swarm.localhost" 指向cert的動態設定檔。 tls: certificates: - certFile: /certs/local.crt keyFile: /certs/local.key 然後我們就可以這樣測試 curl -v -k -H 'host:whoami.swarm.localhost' 筆者在一開始時，始終無法設定 dyanmic/tls.yaml ，其實是筆者誤會了 traefik 的讀取方式。本個例子中，traefik 其實會動態讀取 swarm 及 file provider 的設置，而dyanmic/tls.yaml是經過file provider的方式生效。也就是 traefik-ssl.yaml 中的"--providers.file.filename=/dynamic/tls.yaml"。 本個例子與官方例子最大的不同，是官方的cert, tls, 是直接使用bind mount的方式存取，如果你有多過一個manager，這個方式不太有效。本文就用了swarm config及swarm secret，方便多個manager自動配置。不過swarm config及swarm secret都有個缺點，若要更新它們的內容，就必需要重命名（例如dynamic-tls.yaml=> dynamic-tls.yaml2） ，否則swarm不允許發佈。 完整 yaml 請見 github

專炒比特幣期貨｜線性回歸指標｜勝率逾七成｜6月份回報45%｜麥振威
創富坊
程式交易 www.quants.hk (導師: 財經書藉作家: 麥振威)・2025-07-17

專炒比特幣期貨｜線性回歸指標｜勝率逾七成｜6月份回報45%｜麥振威 早前我們已推出了合共9個策略(Strategy)給Patreon 會員選擇使用。今次推出的則是一個指標(Indicator)，影片中為這個指標加上了一些簡單的平倉準則做backtest效果已經不俗。 6月份交易BTC USDT Perpetual，勝率逾七成，回報有45%。用5萬港元本金，獲利約23000港元(已扣除交易費用及資金費用) 可在以下連結參考指標資料: https://www.tradingview.com/script/1D11hGCm-%E7%B7%9A%E6%80%A7%E5%9B%9E%E6%AD%B8%E6%8C%87%E6%A8%991-0/

學用AI模型分析Reddit內容｜比大部份技術指標更準｜新手快速上手｜麥振威
創富坊
程式交易 www.quants.hk (導師: 財經書藉作家: 麥振威)・2025-05-26

不少人都會運用技術指標去判斷市場走勢，但其實趨勢最受整體的氣氛影響，例如當股市有壞消息出現，若市場對後市信心充足，下跌的幅度也不會太大。Reddit 的wallstreetbets每天也有大量散戶貼文，這些貼文其實反映了市場大部份人的情緒。 影片教大家如何申請Reddit的API，再用程式將wallstreetbets的內容大量下載，然後再用AI模型為這些內容進行「情感分析」，讓AI模型計算出最新的情緒分析分數。這個結果除了可用作分析市場氣氛，更可直接當作一個技術指標運用，預測結果比市場上大部份的技術指標更加準確，而且可以配合其他的指標組成交易策略再做backtest或autotrade。 要學懂用AI模型分析Reddit內容其實也只需要幾個步驟，即使是新手也能學得懂。

Galera 4 (Mariadb cluster) on ubuntu 24
科技新知
MacauYeah・2025-04-28

前述我們一直在介紹docker cluster，但docker也不是萬能的。某些依賴HDD的程式，而且檔案權限相對有要求的程式，例如：資料庫，用docker去接入共享的HDD (mout share storage)，反而更麻煩。一來需要程式本身支援，二來要修改官方docker的初始化程序，過程相關折騰。所以有這方法需求的，都可以先考慮原本的VM做成Cluster。 本文就介紹一下傳統的Mariadb 做成Cluster的方式。老實講，Mariadb 官方手冊可能因為要適配各個不同的OS品牌，並沒有提供一個平台完整的安裝流程。最後筆者也是轉向一些非官方的網絡教學，才成功設定。 Galera 4 (Mariadb cluster) on ubuntu 24 https://www.linode.com/docs/guides/how-to-set-up-mariadb-galera-clusters-on-ubuntu-2204/ 筆者參考上述文章，配合自己測試的結果，以下簡介一下在Ubuntu 24.04的安裝過程 準備3台VM，假設它們的IP為 192.168.0.2, 192.168.0.3, 192.168.0.4 ，確保它們之間的網路可以互通，每一台機都執行以下的安裝script NODE1 192.168.0.2 修改/etc/mysql/mariadb.conf.d/60-galera.cnf, 留意 wsrep_node_address, wsrep_node_name 部份，要與本機相同。 設定好後，我們可以關掉mariadb，經galera 新起cluster的方式叫起它，然後經sql 在內部查看現時成功有加到cluster的機器數量。 應該要看到數量為1 NODE2 192.168.0.3 在node2，跟進述一樣，修改 /etc/mysql/mariadb.conf.d/60-galera.cnf，記得wsrep_node_address, wsrep_node_name要換成新機的值。 設定好後，就重啟mariadb，順便看看現時成功有加到cluster的機器數量。應該要看到數量為2 NODE3 192.168.0.4 在node3，跟進述一樣，設定值筆者就省略了。我們可以在測試一次真實的改動，是否可以同步到其他node。 我們先試在node3加入新的資料庫test1，然後在node2查看是否存在。 node2應該是可以找到test1的，不然就要經過查wsrep_cluster_size看看node3是否成功接入。 然後我們再在node2試試修改root的密碼，看看會不會同步到其他node。 最後node1, node3都需要使用新的password才能登入。 當一切都如預期，你的Mariadb Galera cluster就成功了。

學習寫程式，除了複制貼上還有什麼？
科技新知
MacauYeah・2025-02-07

不知道大家是如何學習特定程式語言/框架的建構? 也不知道大家可如何保持程式庫/框架的最新狀態? 筆者就分享一下最新的經驗，看看對大家有沒有得著。 制作自己的範本 跟著程式/框架的導覽教學(Tutorial)走一偏 從零起一個新專案 設定專案，該用的基本功能全部設定好，作為概念驗證(Proof of Concept)，也作為日後範本(Template)之用。 有需要用新專案，就複制之前的範本，再逐一修改名字或路徑的設定。 上述做法，是筆者過去比較常用的策略。面對很統一要求的專案，都有效。當程式庫有更新，我們可以選擇只局部修改，範本就可以長期用。我們也不需要經常從零走一篇。 練手的Code - 從零起一個新專案 上述的範本做法，對於現時需求多變的專案，可能不是很有效。例如有些專案使用Session Auth，有些則是Api Auth，有些則是Open Auth。同一個範本中有齊多種Auth的設定，原本難度就有夠高，之後複制完還要自行禁用不相關的部份，也是相當的煩人。當範本中多有個地方都有互相衝突的地方，複制範本就不是一個很易的做法。 面對那些複雜的配對，我們務必要真正了解技術的運作原理，然後為每個功能都從零建一個專案，做一個最簡單的Proof of Concept。重點不是在未來拿它們複制貼上，而是用來厘清概念，哪段程式對這個功能至關重要，哪段其實沒有作用。 如果可以，每次程式庫/框架升級時，都從零建一次。這樣一來可以練手，加深記憶，二來是每次版本的變動，有些程式碼可能已經變得沒有作用，原本的寫法並不再是最簡的。當然這個也可以為每個功能獨立做成範本，到有需要的時候再抄少量的程式碼就好。 其實練手的過程中，我們亦會慢慢熟習IDE的功能，有些IDE或Plugin已經很方便地自行完成一些設定。所以筆者漸漸的也習慣了不抄程式碼，改為以IDE Plugin的方式建立，某些真的很不熟練的部份才會維持範本複制的型式。 這是筆者最近學習vue3 的練習清單，還在持續新增中。讀者們有興趣也可以一起來修訂。 https://github.com/macauyeah/AProgrammerPrepares/blob/main/src/vuejs/TimeAttack.md

為程所困－是什麼讓你不想寫自動化測試？
科技新知
MacauYeah・2025-01-08

測試場 VS 自動化測試 筆者一直地更新自己過去所編寫的程式，很恐怖的是，那時的自己很少思考過怎樣寫測試Test Case。致使每次做更新時，都膽戰心驚，要手動建立測試場，人肉去測試每個可能有受影響的地方。在那些年的時候，有能力自己搭建測試場，已經是萬幸。但當面對一些要長期維護的程式，測試場的人肉測試並不是一個有效的方法，一來費時間，二來人腦記憶並不可靠。單靠自己去想想那些地方受影響，再測試，某程度是在挑戰人腦的記憶上限。如果是團隊合作，就更麻煩，你以為修改不會影響到其他人，結果卻是翻天覆地。 所以為求長治久安，編寫自動化測試，是有必要的。這些自動化測試，都算是回歸測試，每次程式有任何地方改動，都確保所有自動化測試被通過。理想始終是理想，但實際操作又會遇到怎麼的問題？ 以筆者剛更新的程式為例，難以測試主要是當初沒有想過要測試這件事，所以程式結構通常是【連續順序】地執行。想分段測試？除非先重構。 Function中太多自己創建的Object 回顧自己的程式，初期編寫時，總會我手寫我心，每想要創建任何資源，在java中就會使用 new 字眼，或是自行呼叫某些 builder 類來取得資源，這是其中一個令自己無法寫測試的原因。 我們要想想，這些資源，是不是自己Function中所關心的核心。如果這個資源是被直接回傳的，我們要保留，如果它是HttpClient，只是要來獲取其他資源的媒介，我們或許可以利用依賴注入來取得它，即是把 HttpClient 改為經呼叫方傳入。注入的好處時，我們可以在Test中，修改那些資源的行為和結果。更進一步的是，把那些資源改為 interface 的方式存取，那麼在 Test 中就能更任意地控制該資源的行為。 首次重構某些資源成為依賴注入，大部份都會影響呼叫方，很多地方都要重寫。不論使用constructor injection, setter injection, annotation injection 等，上傳呼叫方，或多或少都會要加減改變參數。極致地，我們把構建都交給Program 框架去做，例如Spring Boot中，各種資源，都交給框架去自動配致。當然，這種做法的學習成本高，除錯成本也高。 【注入】其實是想在控作那些資源，在測試中運行得到固定的行為。使用前述的HttpClient例子，當我們業務邏輯是先訪問外部Web API，再根據結果做處理，那麼我們測試時，就會想模擬Web Api的結果。如果要做到自動化測試，最強硬的手段，就修改自己的HttpClient，模疑給出固定結果。 想要做到這種，在傳統的Java中，我們需要透過進一步抽離Interface去做。但這樣做很累，所以筆者通常會用如Mockito的程式庫，去修改HttpClient的行為。有興趣直接看程式碼的讀者，可以去看 github 。 當然，上述的 HttpClient 例子，使用測試場也有可做測試，自己再去模擬那些Web Api的回傳，有些情況下，這樣會更真實，但大家就必需好好定義測試場的行為。因為測試場可能與團隊的其他成員所共用，有機會其他人可能想要更多互動的測試方式，而非固定的結果。但並上非固定結果的測試場，自動化要測試的可控度就減少。

Docker 來源掃瞄 - Docker Image Scan
科技新知
MacauYeah・2024-12-19

當網安要求越來越高時，我們也要留心 docker image 的來源是不是有漏洞問題。 docker hub 本身就已經有一些安全掃瞄報告，以 nginx 的 1.27.3 版本為例， docker hub nginx 1.27.3 ， docker hub 已經列出相當多的CVE漏洞。 不過對於不公開的 docker image ，安全描瞄可是要收費的。作為小團隊，可能想先尋求一些簡單的免費方案。如果你想同樣的需求，可能Trivy會幫到你。 Trivy Trivy 是一個用於描瞄軟件版本依賴或設定檔是否引用到一些有漏洞問題的軟件，它也能檢測 docker image 是否有漏洞或錯誤設定的問題。而且更好的是， Trivy 本身亦有 Docker Image 版本，我們就不用煩惱怎樣弄一個 Trivy 的執行環境，只要可以運行 docker ，有網路就可以了。但使用 Docker Image 版的 Trivy 有一個額外要求，就是它要有主機上的 docker.sock 權限。 描瞄的指令如下，其中 docker.sock 就是為了讓 containers 內部的程式可以存取主機的 docker daemon , .cache 則是為了方便暫在下載資源。 上面故意用 nginx 的兩個同版本號不同平台的 docker image，其實就是為了引出一些潛在問題。nginx 預設是使用的debain OS的，在筆者寫文章的當下，已經更新到最近的 image ，但始終有一大部份可能的漏洞。反觀 alpine OS 版本，就找不到這麼多問題。 這是因為 alpine 預設安裝的依賴較少，所以找到的漏洞也少。正所謂，做多錯多，唔做唔錯（大誤）。這其實有好有不好，因為在發生問題時，在 alpine 下可能連基本的除錯工具都沒有。除非大家有完整測試，或者對 alpine 有相當的認識，你才會選擇一個非官方預設的版本。但就以事論事，引用較少的依賴，長久之下的確是不會有那麼多隱患。大家如果有條件，也可以試試 alpine 或其他版本。 前一節我們可以看到，Trivy需要經過 socket 的方式才能存取主機上的 container daemon 操作權。但 podman 作為一個不主張 daemon (daemon less)，亦主張不需要 root (rootless)，那麼它該怎樣執行？ 其實podman也有user層面上的 socket，而且 trivy 也有對應的方式去轉用第三方 socket (有點像使用遠端主機 socket，但官方並未宣佈正式支援遠端的方式。) 具體使用方式，筆者亦已在 steam deck 上測試，使用方式如下。不過因為 steam deck 預設沒有 root，筆者就省略 cache 指令，免得之後要有權限問題要手動清理。 Ref Podman socket activation Trivy: Support for rootless podman