搜尋

搜尋結果

Bandai小比列高達模型的危機
手機‧電玩
MacauYeah・2026-02-27

筆者去年就分享了一系列自己機械人模型的制作經驗，大部份都被Bandai的小比例高達所主導。其中一個原因，是因為動畫的加持，令到每台高達在筆者心中，都有一個神聖的地位。 而其有一兩款國模原創系列，品質是好的，就只是少了一份共鳴。這令筆者覺得，其實中國的開模技術及制作誠意，是不是已經超越了Bandai？所以筆者買一台外型是高達模型的高仿拼裝產品回來做個對比，在拼完之後，實在令筆者覺得Bandai是有意放任做好小比例模型的市場。 結論講在前頭 筆者反對盜版，盜版是需要付上版權責任的。如果Bandai肯借出舊的高達IP，讓有實力的第三方開模，那怕賣貴一點，Bandai單純抽成，都是可以接受的。這樣Bandai不需要考慮開模成本，就可以把舊模持續更新，那就Bandai 、玩家、第三方都可以win win win。 Bandai小比列高達模型的現況 雖然1/144的分支裏面，Bandai已經有EG/HG/RG三種選擇，但對於玩家來講，都不太有誠意。EG可動差，易斷，HG其實水口外露很嚴重，在不打磨的情況下，很多地方都有白刺刺的水口，RG就是件太細，一有不慎就發生悲劇。RG的外型最修長，但有時比人的感覺會是細節密集得過火了。 在筆者最近購入的那一台國產高仿中，讓筆者看到了不一樣的設計。它雖然沒有RG的細節，但分件做得比HG好。分色也比HG多，而且更多的分件，亦可以通過嵌套的方式去相互遮蓋水口。 隱水口現在基本是國模的標準配置，不論原創還是高仿。就那麼一點小事，其實HG也可以有，Bandai就偏偏不用在HG上。國模也不是全部隱水口，只在有需要的部份使用。筆者過去一年的Seed Freedom劇場版HG模型，就是總在手、大腿當眼處來個大大水口，看著有夠難受。 看著看著，筆者就會想，有些開模技術的事，不是Bandai不能做，而是不想升級舊模。新模雖有很大發揮空間，但它都選擇去挑戰新動畫設定（例如Gquuuuuux），為求衝一波人氣，就生產一堆新模出來。HG就是比例失衝的產物，夠快就好，反觀晚個半年推出的MR魂系列，比例都有所調整，基本都會好看些。 老實說，Bandai MR魂都能設計出來，其實也可以下放技術給HG用。那我們就不用受那些水口的拆磨了（筆者亦有想過，其實那些品質特別好的高仿，是不是就是把MR逆向工程，改為拼裝的？） 還是那個總結 筆者明白在商業上，需要衡量風險，Bandai延期的話，可能會錯失熱度，做得多好，也只會少賺了。但正如之前所說，把舊IP借給第三方廠，由它們是再重塑外觀、批裝結構、生產模具，Bandai只在抽成，應該大家都開心。現在即使沒有IP授權，高仿依然存在，如果只是因為IP問題，令到一些更優質的產品消失，實在是玩家的遺憾。 因為IP問題，封面圖是筆者今年制作的Bandai HG 新生命運，而非高仿。如果大家想知道是哪一台超越了它，可以再自行搜一搜相關關鍵事。

想試國産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之間的通訊，需要大量的學習成本。

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

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

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

小比例高達的選擇： HG vs RG vs R魂 （MR 魂）
手機‧電玩
MacauYeah・2025-09-29

筆者過往一直就關注高達HG 模型的素組制作，以及把玩相關資訊。而眾所週知，HG的精緻度及可動性，其實都不怎麼，想要美觀，必需要花很多心思去制作才行，想要高可動，也要一定的改制能力。 就以不噴塗的前題下，1/144比例下，除了HG外，我們還有的選項，就是 RG , Robot 魂 和 Metal Robot 魂。而筆者這兩三年，都陸逐有入一些近期的貨，可以分享一下對比。我們就先各個系列對比 HG 作一些分享，最後再分情境做個綜合評價。 RG vs HG 只要你有薄刃剪 + 滲線 + 貼紙，你就會得到一台可以吊打HG的高細節高達模型。貼紙是套件內附送的，只要把貼紙好好貼完，什麼水口阿，都可以無視。這是最最最大的優勢。 缺點就是你的選擇不多，而且高達套件都有軟骨問題。不把玩，全部罰企，是可以接受的。高強度打把，最好選擇RG25號以後的作品，把玩時也要格外小心，因為真的易壞。 Robot 魂 vs HG 課金取得官方代工，買回來就可以即時把玩。最美好的部份是可動性一般比同期HG高（不必然）。手型、特效件也比HG 多。筆者認為開箱即玩擺POSE，是它的最大價值，所買回來一定要開箱把玩、拍照，不然發揮不出它的性價比。 雖然R魂可以視為官方代工，但這個代工的細節並不多，並不包括滲線和貼紙，所以你想拍一些近鏡的大頭相，還是太過素。有需要還是可以自行刻線或另購水貼。 Metal Robot 魂 vs HG MR魂，其實就是R魂的升級版，部份關節或內構，以合成金屬制作，強度會再早高一級。大家可以視為課金取得更高級的代工，外表雖然無淺線刻線，但塗裝+移制技術，已足夠表出現細節等。拿在手上，就有一種珍品的感覺。 MR魂好像有錢就什麼都解決了一樣，但其實不是。它的可動性，其實不太特別突出，而且會有掉件問題。筆者入手的兩款通販MR魂，都有群甲容易掉落的問題。所以錢只是花了在塗裝和用料上，把玩體驗可能不比R魂強（特效件少很多） 綜合情境 何時選擇HG: 款色限定，因為HG的款色夠多，其他魂系並一定有推出。HG可能是某些機體的唯一選擇。想爽玩，想好看，一定要有些動手能力。 何時選擇RG: 如果你覺得帥就完事，但又不想花太多錢和時間，那麼RG就是你的好朋友。只要細心對著說明書拼裝，貼上貼紙，就不用再花心思了。 何時選擇R魂: 對於把現有要求的朋友，可以選這個系列。有空就把來扭一扭，做個情境，是何其狀觀的一件事。 何時選擇MR魂: 不想動手拼裝，又想帥，但把玩時間都沒有的朋友，可以選這個。開箱上支架，選一個固定的姿勢，長放飾櫃，那是最簡單也最優美的一件事。

【沖繩。古宇利島】Ocean Blue @ 古宇利海洋塔
走遍世界
80後愛旅行✈️・2025-09-17

Ocean Blue 位於古宇利海洋塔１樓，餐廳內有大片玻璃窗，可以將壯闊的海景一覽無遺。 在這裡可以一邊用餐一邊俯瞰古宇利大橋與碧海藍天的美景！ 逛完古宇利海洋塔，在炎熱的屋頂露台和展望樓層拍完照後，到Ocean Blue喝一杯Tower Drink 吹吹冷氣 在室內隔著玻璃望向這壯闊的海景，真的非常治癒！！ ​ 古宇利海洋塔Ocean Blue 沖縄県国頭郡今帰仁村古宇利538番地 導航定位電話：0980-56-1616 停車場：可停200台 10:00～18:00（最終入園17:30） https://tabelog.com/tw/okinawa/A4702/A470202/47013631

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

重入膠坑 10｜JMS（集模社）的馬克兔作品分享
手機‧電玩
MacauYeah・2025-06-26

回鍋模型制作已經好一段時間，亦做了不少的嘗試。但如果大家覺得新嘗試有點怕怕，可以試一試以國産KO（高仿）作為實驗對像。 筆者並不支持KO，因為質量真的有差，但以練手的角度出發，要做很多白老鼠實驗，那麼KO的價錢絕對是一個合適的選擇。可能有朋友會問，做實驗為何不使用廢件？廢件做一些基本實驗是可以的，例如切削、顔料，使用單件就可以做到。但如果要做流程實驗，廢件很難折開重來。比例實在的，還是從零剪件容易一點。實驗的流程可能是板噴、局部取件、打磨＋刻線＋滲線等。 筆者最近就開了一盒 JMS（集模社）的馬克兔 21世紀配色，主要試一下加深刻線＋打磨＋滲線配色＋水貼的流程。 先上作品圖 外貎很可以 工具 刻線：0.15刻線刀 打磨：400 600 800砂紙、陶瓷推刀 滲線液：田宮滲線液 水貼：KO自帶的水貼 流程 因為水貼原因，原本有打算用司特力的水性滲線液，但在個別區域試過後，就知道會被水貼的水引流的問題，所以馬上改回田宮的琺瑯滲線液。 加深刻線部份，想少錯，就用刻線膠帶，不然出界就要用打磨的方式修正。筆者就懶得貼，所以不少地方都有打磨的痕跡。修正時，感覺上先用推刀刮，再使用600、800號砂紙打磨，後期再消光漆，就已經足夠。有些地方，什至只用推刀，感覺上差異也不大。 滲線液的部份，本次試用黑色，作為大反差配色。個人覺得在馬克兔 21世紀下，效果配色不差，可以跟軀幹部份相對應。 至於JMS品質，真的是練手的好選擇，組合度OK。但我們不能要求關強度，對把玩有要求的朋友請勿嘗試。

【芬蘭。赫爾辛基】赫爾辛基集市廣場（Kauppatori）
走遍世界
80後愛旅行✈️・2025-04-29

赫爾辛基集市廣場（Kauppatori）是芬蘭赫爾辛基最著名的廣場之一，也是遊客必到的熱門地點。 而且廣場濱臨波羅的海，從集市廣場可以欣賞到迷人的海港風光，還能搭乘渡輪前往著名的芬蘭堡或群島進行遊覽。 廣場上有販賣著各種當地的特色食品，和手工藝品和紀念品的攤位。 赫爾辛基集市廣場（Kauppatori） Eteläsatama 00170 Helsinki 星期一至五 06:30 ~ 18:00 星期六 06:30 ~ 16:00 星期日 (僅限5月至9月開放）

重入膠坑6-補色地獄
手機‧電玩
MacauYeah・2025-03-23

之前筆者就有介紹過水性馬克筆補色、滲線，對於有一直砌開最新HG、MG的朋友來講，只需要考慮滲線就夠。但對於一些便宜價位的入門級的HG或SDEX模型，補色就更重要，因為它們的成型色大都只有兩至三種，即使套件中有提供補色貼紙，亦無法函蓋所有部位。筆者最近做的一款舊HG能天使及SDEX巴巴托期天狼座就是如些。 你所需要的是一套足夠便宜的平替 之前筆者亦介紹過【迪斯派】的模型專用的水性馬克筆，但對於這麼大量的補色，迪斯派的單價也是相當讓人心痛。最近筆者就發現到另一款更便宜的平替品，【多樂繪直液式丙烯馬克筆】。筆者寫稿當天，非金屬色中，也是45.8RMB 24色，72.8RMB 48色。相對於6.9一支的迪斯派非金屬色，多樂繪很便宜，顏色選擇也很多。 多樂繪亦提供散裝購買，7.9RMB 自選三支非金屬色，即是2.64一支。如果大家不想一次過全部購買24色，可以參考筆者以下型號 配合區部重塗: 600(白色), 603(黃色), 608(藍色), 622(淺灰), 680(深灰), 664(紅色)。上述與萬代的成型色還是會有色差，但相對不太明顯。其中600(白色), 603(黃色)，遮蓋力較差，需要多次重塗以便發色。 還有一些筆者用到但不是通用色，628(天藍色？)，642(海軍藍？) 使用效果: 筆者在塗裝部份只是處於基本補色要求，沒有試過混色、疊色、過渡等高階用法。對比迪斯派，多樂繪的感覺真的差不多。 操作 使用前先搖一搖筆身，拔蓋就用。 上色前需要打磨嗎? 對於白色、黃色等，先打磨模型表面，有助加強附著力。但白色始終難發色，也要多次重塗。深色的不用打磨表現也很好。 易刮漆嗎? 易刮，所以要留意邊角位。完成補色後記得上保護漆，上保護漆之前也記得再檢查一遍。 遇到的最大問題 多樂繪的黑色出墨過快，難以控制影響範圍，因為顏色太深，事後也很難清潔。但其他顏色未有出墨過快的問題，未知是否個別事件。另外筆者亦未試過傳統的水性消色筆，都一律以酒精或牙籤清理錯處，暫時無需使用專用消色筆(多樂繪可能也沒有消色筆)。 迪斯派比多樂繪做得更好的可能是出墨的部份，它不需要搖筆身，也有正常的顏色表現。但迪斯派的顏色選擇很少，灰色、藍色與萬代的成型色很不協調，小部份補色也很顯眼。筆者認為它最大的問題是缺少深灰色，這是萬代很多內構的常用色，再加上多樂繪價錢便宜一大截，一口氣買幾次回來粗用回本。 如果大家有發現一些更細微的分別，歡迎隨時留言交留。

重入膠坑5 | 堆積變山積，山積有辦法解決嗎？
手機‧電玩
MacauYeah・2025-02-20

針對大標題的問題，先講結論，堆積是沒法完全避免的，但我們應該有條件防止堆積變成山積(大量堆積)。 堆積不可避免的原因 以前筆者一直是玩遊戲多，面對特價節日買多了的現像，直到PS4後期，都還會有這個問題出現。但在過渡到PS5早期，就不再有這個問題。因為數位遊戲必定是越賣越便宜，除了機器壞、停產的問題，基本上不會有所謂的錯過好遊戲的問題。不同平台，每年都有節日特價，急玩頂多也就原價買入，能等就一定會有好價錢。 但模型可不一樣，實體商品都有限量的問題，首發一定貴，再販之後會回落到正常價，但再過一期就不一定有現貨。所以大家的策略一般是先買入自己認為不錯的新貨/特價品，以免後來買不到，即使山積也會照買。不過問題就是當年紀越來越大，又或是對制作越來越有要求，作業的速度就會越來越慢，然後山積就會越來越嚴重。 改變一下心態 首先這裏不討論成品玩具的山積問題，因為成品玩具至少可以折價出讓，只要夠捨得，想清貨一般都有市場。這裏講的山積問題主要是針對拼裝模型部份，針對那些要自己出手，慢慢一件件加工的玩具。 最初，我們可能很想完美地砌完一台模型，打磨、上色、擺拍。但因為一些技術問題，例如因為損毀要另行修復、制作難度、天氣問題、家庭問題，令大家的進度一直無法向前。久而久之，就會更無心情去完成作品，食之無味，棄之可惜。 面對這個問題，我們可以考慮放過自己，其實不一定要完美制作才能體現樂趣。素組，AA膠強行修復，遮醜，拍攝區部特寫，也可以一定程度的避重就輕地跳過有問題的部份。 貴精不貴多 由少量堆積變成山積主要的原因源自於【不想錯過】，但對於長遠目標來講，山積可能意義不大。 如果我們的目標是收藏，我們會想精制，而面對可能損毀的風險，雙入更具意義。所以不同時期山積多款模型，就變得沒有對沖意義。 如果我們的目標是重複把玩，我們可能更在意空間收納的方便性。若山積的話對於怎樣找模型，絕對是一個阻礙。舊模可能需要搬去一個更隱閉的地方，但這樣亦代表不再把玩，所以堆積也沒有價值。 重新定義如何斷捨離 回到本文最初的結論，堆積，或者叫作團貨，是沒法完全避免的。主要因為商品可取得性問題，再加上對珍品的不捨，一定量的堆積是必定會出現的。但我們可知道，物品始終都會老化或損壞，亦即是有保質期的問題，堆積不代表可以永久擁有。有些我們無法完成、修復的作品，就只好換個形式儲存，例如變成改件作為下一個作品的配件使用，又或是送出給下一位有緣人。新品購入時，亦要評估保質時間，自己是否可以在指定時間內開封體驗，免得錯過最佳觀賞時間。

Github copliot vs Intellij IDEA ultimate
科技新知
MacauYeah・2025-02-18

github copliot 最近正式開放每月限量免費使用，只要有github 帳號，就可以經過vscode copliot plugin，向 github copliot 交互式生成程式碼，又或是經 copliot 提供 code completion。大家會不會想過，加了github copliot的vscode，是不是效率暴升，可以跟傳統的付費IDE 例如intellij 的IDEA ultimate版本平起平坐？ 流暢度明顯提高 是的，在生成程式碼方面，特別是code completion，在開啟copilot之後，實在好太多了。筆者長期寫java，vscode 原生的 java code completion，實在太陽春。java class name都很長，而且是強型別，很多時候都要完整打出class name。但大部份時候，筆者都要打很多個字之後，vscode才猜到你想打什麼，再給你可能的code completion，但這樣一來你也快打完了，幫助不大。要麼就是自己複制貼上，要麼就自己全拼出來。 在開了github copilot之後，在空行開始時，它就會開始猜你的意途，在打幾個字母以後，它雖然會頓一頓，但總在筆者跳去其他部份複制class name之前，就給出更新結果，實在省心太多。但猜測始終是猜測，大部份時候還是邊打邊修正。不過code completion方面，已經是追得上intellij，有些時候更是超越了intellij。例如我們有時寫 javascript 時，需要做多語言顯示，我們需要為每個語言設定一份i18n的翻譯。copilot 在這方面也能幫到忙，它會自動推薦可能的翻譯，你連問都不用問，這些功能，都不是 intellij 的本地運算會有的支援。 另一個要提提的是 copilot chat，它跟大家平時使用 chatgpt 程式碼生成的方面類似，只是它可以直接在vscode的某個檔裏直接交換生成程式碼。不過生成的品質都很一般，很初階的事可以做，深一點的就不懂。例如你很常寫java，但突然要寫javascript，有些javascript的array操作你懶得查，這時你可以叫copilot chat幫你生成。但若果你今日使用 javascript 框架，有一些 vuejs 或 reactjs 的結構參數傳遞你不太了解，你想找copilot chat，那就幫助不太。它依然可以生成一些程式碼，但對你碰釘的地方沒有修正意義。你還是需要自行從官方文件較對、研究Stack overflow中相似問題的解決方案。就跟chatgpt差不多。當然這些不是傳統IDE可以給你的。但如果現今對比的是收費的copilot chat和本地免費的ollama qwen2.5-coder，copilot chat就沒有太大性價比。 可以作為付費IDE的平替嗎? 如果我們拿vscode + github copilot 跟 intellij IDEA ultimate來比較，前者入門價錢是120美元一年，後者入門則是169美元(次年續期有優惠，但到了第三年才會比 github copilot便宜)。單看價錢的話，github copilot的確比較便宜。想省點錢，github copliot絕對是一個可以考慮的選擇。但除了錢以外，或者我們還要考慮一些其他因素。 公司立場上，介不介意你的IDE上傳資料到cloud service上面？ 付費IDE的除錯功能、多環境整合、程式碼品質分析，這些關係到長期維護，非程式碼生成部份，是不是可以忽略不計。 筆者在開發開源的程式，長期都使用vscdoe，在配上 github copilot 後，明顯覺得它提升了 vscode 的流暢度。但相對實際工作上，筆者還是會集中使用 intellij IDEA ultimate 。因為即使vscode 有明顯改善，但日常碰到的問題更多不是在生成部份，而是解決那些似是而非的程式碼結構陷阱，這方面還是intellij 更幫到忙。(當然stack overflow和其他網路資源才是真正的救命靈藥。)

steam deck 辦公用途工具資訊 2024/12更新
科技新知
MacauYeah・2024-12-17

購入steam deck 已經有一年多的時間，之前亦發過一些安裝教學。適逢筆者系統重裝，又有機會重新檢視工具的可用性。 Podman / Distrobox 一項很重要的更新，Steam OS已經有預安裝podman，不需要經home brew安裝。但預裝的podman 沒有內置DNS，可能會對K8S等進階應用有影響，不過筆者只作為單機測試用，普通的podman compose沒有問題。 另一項很重要的更新，就是 distrobox，它可以經 podman 讓大家方便地執行不同的 linux 版本，想在Steam OS上使用Ubuntu？沒問題，開箱即用；想用VScode官方維護版本，沒問題，安裝指定Linux再按裝VScode就好。 詳見上一期的介紹。Steam OS 3.5更新，內建 podman, distrobox 中文輸入法 我們不需要再安裝Fcitx5 + Rime，如果大家在遊戲模式下，已經設定好中文輸入法，那麼在輸到桌面模式下，照樣以Steam Button + X Button的方式，打開內鍵輸入法。你會見到有虛擬鍵盤彈出，它會覆寫桌面模式的。此時，即使你關掉虛擬鍵盤，並用實體鍵盤，中文輸入法都會保留。不過大家要確認，彈出當下必需要是【中文】。 若然你彈出的虛擬鍵盤是英文，請按【地球】轉換到【中文】後，關掉虛擬鍵盤，再重來一次(重按Steam Button + X Button)，確保彈出的時候是經【中文】覆寫。 Discovery Discovery 是 Steam OS 預設用來安裝第三方程式的地方，它經 flathub / flatpak 存取程式。但筆者一定要先強調，它提供的第三方程式，並不一定會得到原開發者的支援，它屬於打包移植之類。 例如 flathub 中可以找到 Google Chrome (https://flathub.org/apps/com.google.Chrome) ，但它實際是經過一個github 專案移植過去的 (https://github.com/flathub/com.google.Chrome)。它有提供持續更新，但筆者不保證當中有沒有任何被植入過任何不正當軟件。 相反，flathub中有一些程式是經過原開發者支援的，例如 Firefox (https://support.mozilla.org/en-US/kb/install-firefox-linux), Gnome Boxes (https://gitlab.gnome.org/GNOME/gnome-boxes), Gimp (https://www.gimp.org/downloads/) ，這類可以比較放心使用。 筆者過去使用 Discovery ，的確有遇到一些權限問題，但最後估計應該是筆者安裝 Homebrew 所影響。筆者在重裝 Steam OS 後，直接使用 Discovery，就沒有問題。過去需要經 Homebrew 安裝的東西，現在經 podman , distrobox 或 Gnome boxes 就可以了，不再需要經Homebrew去折騰一輪。而且Homebrew也不是萬能的，因為Steam OS有限制一些套件的事用，即使安裝Homebrew也解決不了。若想要完全開放套件限制或解決依賴問題，還不如直接開啟Steam OS覆寫權限，轉用Arch Linux的安裝包。

Git 歴史修正
科技新知
MacauYeah・2024-10-29

有時候，我們修正一系統檔案，例如某個commit中，多了一個不該放的檔案，又或者想修改該commit的作者，我們就要追搜到某個commit，然後用rebase隨個改。 例如本次repo，有一個githubAction.md，因為錯誤原因，被加到了main中，也藏了很久。如果我們想連根拔起，我們需要加出它第一次出現的commit。 $ git log githubAction.md commit 60ccd70f6b768138cbe23c93ffcfa32574ce895c 那我們就以它前一個commit作為rebase的根據，進行逐個commit修正。 $ git rebase -i 60ccd70f6b768138cbe23c93ffcfa32574ce895c^ pick 60ccd70 draft some content pick e2ee9a3 add some senario. pick b91afc1 refine submodule; pick 98cd366 add notes about submodule specific checkout; pick 064b06f test directly commit in submodule main pick 7b648d2 update git submodules notes pick 556f25e add notes about merge timing pick 5244804 Create git-continuous-integration-strategy.md pick 107e486 add more pratical nodes about ci; pick d93cbee add mono repo challenge pick 1c471b6 add worktree notes pick 9063ccb notes about different of git flow and github flow; pick b72e89e Update github-flow.md, add ref more link pick 0b8f2a9 draft github flow release problem pick 8b333fc finalize github flow release strategy 在rabase選項中，把需要改的commit由pick改為edit。(rebase會以舊到新顯示)。然後儲存。例如 edit 60ccd70 draft some content edit e2ee9a3 add some senario. edit b91afc1 refine submodule; pick 98cd366 add notes about submodule specific checkout; pick 064b06f test directly commit in submodule main pick 7b648d2 update git submodules notes pick 556f25e add notes about merge timing pick 5244804 Create git-continuous-integration-strategy.md pick 107e486 add more pratical nodes about ci; pick d93cbee add mono repo challenge pick 1c471b6 add worktree notes pick 9063ccb notes about different of git flow and github flow; pick b72e89e Update github-flow.md, add ref more link pick 0b8f2a9 draft github flow release problem pick 8b333fc finalize github flow release strategy 我們第一次會在60ccd70，我們作出想要的改動，然後經amend去改掉60ccd70 $ rm githubAction.md $ git add -u $ git commit --amend --author="newuser " 確定無誤的話，就可以去下一步，即是到了e2ee9a3 $ git rebase --continue 因為已經rebase過，你此時看到的不會再是hash不再是e2ee9a3，而是自動rebase完的e2ee9a3。若大家有東西要改，就使用commit --amend。如果沒有東西要改，也沒有conflict，可以繼續rebase --continue下去。

Docker Tag 命名
科技新知
MacauYeah・2024-10-24

一般來講，同一個docker image會提供多個不同的版本，每個版本會附予不同的tag，以作標識。但以docker image的維護者來講，它的tag通常代表的是自己程式的版本號。不過這個版本號卻存在很多變數，就讓筆者好好地逐一說明。 程式的版本號 在沒有Docker的年代，其實所有軟件在發佈時，都會標示版本號，方便使用方明確追蹤問題，自行選擇升級、降級以解決相容性問題。大家要重現問題，也能清清楚地重現。所以docker image的tag，在某程度，都是代表發佈自己的程式版本號。但以前的年代，軟件底層的依賴，例如OS層面的共享程式庫，則不在發佈的管控中，所以過去的程式，在跨電腦安裝時，都會出現缺少某些共享庫的問題。而使用了Docker後，image以內的共享庫的都會在打包的那一刻固定和發佈，就不會有漏的問題。 庫更新，怎麼辦 上面說到image可以打包共享庫，但問題是共享庫也會有安全性更新問題，那麼對docker image的維護者來講，它自己的tag又該如何命名？ 因為庫的量可大可少，所以一般來說，都不可能完全把各個庫的版本號寫在自己的tag上。退而求其次，就是用"版本號+日期"，庫的細版本號，就存在原始碼當中。Ubuntu 就是這樣的例子。 不過"版本號+日期"的命名方式真的方便嗎？每次下遊用戶想更新去最近版本，都要自己找一次最近的日期。這樣對很多用戶來講都不夠方便。所以docker又提供了一個重tag的功能。例如ubuntu:noble，在早些時候指著noble-20240904.1，然後過幾天，又指向更新的noble-20241009。更常見的是latest，每次image都預設會存在，docker也希望大家會定期更新這個tag，讓大家可以更易地找到最新版本。 註: 這跟git tag有所不同，git tag並不預期會變的。當協作者收到tag後，那怕上遊刻意更新tag指針，協作者沒有刪除原tag之前，都不會知道tag更新去了哪裏。 我們該如何選 在發佈方和引用方來講，引用時可以明確使用唯一的"版本號+日期"，對穩定性來講是有意義的。不過多多少少，會產生額外的時間成本。發佈方來說，就是多用了一些儲存空間，方便引用方可以隨時找到舊(庫)版本。而引用方，就要手動修改引用號，作為驗收依據，自動更新的難度比較大。 但對於自動更新要求比較大的情況下，可能就是使用latest或者會隨時更新的share tag(共用tag)比較實際。但我們也依然要定一些方式去版本更新記錄，例如：同時使用 beta latest archive 每日自動更新beta，只有所有測試都通過時，才把archive指向現在的latest，再把latest指向現在的beta。這樣做的好處是，核心的docker stack檔案改變的機會較少，也可以免除docker swarm做太細緻的權限管理。