搜尋

搜尋結果

Steam OS 3.7 桌面模式下的中文輸入法 fcitx5+RIME
科技新知
MacauYeah・2026-02-21

上一篇我們提到，SteamOS的原生鍵盤不知為何失效，我們在桌面模式上的另一個選擇就是flatpak中的 Fcitx5。 因為Fcitx5是基於flapak安裝的，預設只在flapak下通用，後半部份，亦會介紹如何打破這個限制。 安裝Fcitx5 及倉頡五 我們可以在 Discovery App，輸入關鍵字 Fcitx5， 找到相關的套件。為更精準地安裝指定套件，可以直接在terminal 使用以下指令。 首次啟動時，需在start menu中，搜尋fcitx5，它就會長註在右下角的系統列中，選該icon→右鍵→input method settings，把「RIME」加入到fcitx5中，就可以使用了。 在此時，你可以打開Firefox，經control+space的方式轉換輸入法試試。但之後你會發現，原生的Kate文字軟件，都無辦法輸入中文。因為只有Dsicovery / flatpak 的 app 才能正常使用fcitx5。 大範圍套用Fcitx5 如果你找網上或AI的資訊，大部都會提示你修改系統設定檔，把fcitx5加到其中，但筆者就不成功。好在有[Bilibili強者的筆記](https://www.bilibili.com/opus/1139601518269300768](https://www.bilibili.com/opus/1139601518269300768))，原來SteamOS自帶的是ibus，但ibus又不讓設定（因為要換rootfs）。我們通過flatpak中安裝fcitx5，其實是可以通過ibus存到系統的。步驟如下： 如果你還未為當前的deck user配上密碼，你可以在terminal中使用 有密碼後，就可以使用 把所有module加為ibus 你沒有看錯，真的是那樣。基在上所有原生的桌面app及terminal，也可以切為到中文輸入法了。還有一個特例就是經 distrobox 生成的環境，依然無法存入ibus。 Reference https://www.bilibili.com/opus/1139601518269300768

重入膠坑12－快靚正
手機‧電玩
MacauYeah・2025-11-27

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

HG維爾達制作心得分享
手機‧電玩
MacauYeah・2025-09-08

第一次組鐵血系列，骨架看去很好，玩起來則很懼怕。 造型上，沒有Seed系的重背包，是穩定站立的根源，這點我很喜歡。也因為沒有背包，外型上就更沒W系，Seed系的三角肩，整體很有UC那種精練感。 水口: 沒有全修水口，就只有修外甲、部份骨架的明顯之處。修水口後，以水性馬克筆重塗遮蓋。 補色: 按照官點補色，主要是深灰、紅色及骨架少量銀色。另外就是因為遮水口的原因塗了不少天藍色。 滲線: 0.1刻刀加深高低差，再加黑色水性滲線液。

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

Galera 4 (Mariadb cluster) 的冷開機
科技新知
MacauYeah・2025-08-20

前次我們介紹了 Galera 4 在Ubuntu 24的架設方式，這次我們來補充一個最常見的問題Cold Start 冷開機 cold start 平常， Cluster 中只有其中一個 node 需要更新重啟，基本上所有節點回覆正常後，都可以互相通訊。而有些情況，例如斷電問題，需要所有節點全數關機，那麼 Galera cluster 就需要一定的方式重啟系統。那是一些狀態的保護機制，因為在全關機後再同步，系統不知道哪台機才有最新的狀態，它也不敢貿然同步(因為正常使用下， Galera cluster 只有兩台機也會開步)。所以需要人手介入，指定以某台機作為 cluster 的起始點。 舉個最簡單的例子，前述三台機 pocdbnode3 ， pocdbnode2 ， pocdbnode1 順序關閉，那麼 pocdbnode1 應該就會有最新的資訊。 在ubuntu中，可以查看 /var/lib/mysql/grastate.dat 中的 safe_to_bootstrap:是否為1。如果是1，代表當初它有最後的 transaction ，以它為起始點重新起 cluster。 $ cat /var/lib/mysql/grastate.dat # GALERA saved state version: 2.1 uuid: 0c38b6dd-7bdb-11f0-a4dd-1f4be36a6ea9 seqno: -1 safe_to_bootstrap: 1 我們使用galera_recovery, galera_new_cluster, 就可以把該機器重新救起mariadb process。 $ galera_recovery WSREP: Recovered position 0c38b6dd-7bdb-11f0-a4dd-1f4be36a6ea9:11 --wsrep_start_position=0c38b6dd-7bdb-11f0-a4dd-1f4be36a6ea9:11 $ galera_new_cluster 然後其餘兩個 node 可以直接重啟 mariadb 服務 # node 2 $ systemctl start mariadb # node 3 $ systemctl start mariadb Reference Getting Started with MariaDB Galera Cluster 官方文件 How to Set up MariaDB Galera Clusters on Ubuntu 22.04 How to Bootstrap MySQL or MariaDB Galera Cluster – Updated : 還有比較複雜的救機狀況，例如:safe_to_bootstrap全為0，即是可能是全部node都沒有好好地關掉，就掛了。大家有需要可以看看這個link的解決

重入膠坑 8 | HG Mighty Strike Freedom 取件表
手機‧電玩
MacauYeah・2025-05-16

之前就為大家介紹過，想有效率地消除Gunpla山積，事前計劃好一個概定的流程，絕對是件很重要的事。 而流程中，預制取件表，絕對素組檔的一件神器，筆者習慣後，可以極大地減少筆者換剪、打磨工具的次數，也減少找不到零件的機會。 筆者就分享一下自己制作的Mighty Strike Freedom 取件表 (Google Drive連結)，有需要的讀者，可以直接下載或列印。 在這邊再簡介一下如何利用取件表作為素組之用 準備粗剪、薄刃剪、打磨砂紙(400, 600, 800號)、十二個零件盒 按照取件表，分區粗剪取件： 完整地粗剪頭部所有零件 放入頭零件盒 完整地粗剪身體所有零件 放入身體零件盒 依次粗剪各部份零件，放入對應的零件盒...... 分區薄刃剪修件: 完整地修剪頭部所有零件 完整地修剪身體所有零件 依次完整地修剪各部份所有零件...... (選擇性)分區打磨零件: 完整地打磨頭部所有零件 完整地打磨身體所有零件 依次完整地打磨各部份所有零件...... 回到說明書，分區組合: 依次地分區組合 (選擇性)記錄需要額外補色的位置。 (選擇性)滲線、補色 於粗坑線條上水性滲線液 Marker筆補色 (選擇性)保護漆 最後一定要提醒，在第4步組合以外，就必需要決定是否進行打磨，若是組合完再拆散，就有斷件風險。亦有因為上述流程不刻線，其實第5步很安全，沒有進一步打磨修補問題。 最後附上筆者速刷前四個步驟的HG Mighty Strike Freedom美照。

如果把一款課金手遊當成單機speedrun遊戲玩會怎樣?02
手機‧電玩
MacauYeah・2025-05-13

筆者近日有繼續測試G世代永恆當作單機Speedrun的可行性。最近就成功挑戰Gundam Seed、Z Gundam, Gundam W的故事。Seed、Z以機體LV 20為起點(可以視為第二章)，W則為LV 40為起點(可以視為第三章開端)。因為整體編排還在排列組合中，筆者就以現時的進度，分享一下Seed、Z可能可以逃課的加速玩法。 Seed關卡 由於Seed、Z還是相對前期的機體，可以通過投資自由組隊的機體，以達到戰力補充的效果。但遊戲本身就設計的很考妙，它會限制本篇可以出動的機體數量及類型。以Seed為例，初期就只有三台機可用，駕駛員也不多給你。到中期會因為【宇宙/空中/水面】地型關係，令到機體無法出擊或行動力減半，必需要推進開發【空裝突擊高達】，才可以多場景使用，但如此一來，攻擊力就有取捨。 當初筆者就投資在【劍裝】及【炮裝】，最後被逼著要再來一次【空裝】。如果不追求SSR的完美突擊，Speedrun時可以試兩台空裝+自由高達。因為SSR完美突擊的開發，必需要等打完Seed的Normal終關，再加上劍裝、炮裝、空裝做祭品，才可以煉成，所以對於同一章的Speedrun未必有用。完美突擊還可以經過Seed Hard 第一關取得，不過戰力要求很高，煉成的方式應該更實際。 Z關卡 筆者吸收了Seed的教訓，Z中一遇到不適合出戰的關卡，就即時調整，印像中主要還是缺空戰的機體，向著MK-II的開發路線，選超級高達出戰就可以了。而自由部隊，如果之前有先挑戰Seed的話，它們的空戰系列都可以借過來用，自由高達、正義高達、空裝突擊、完美突擊(註:完後Seed Boss關後，一定會解放SSR相關機體的素材，流星號萬用性能不佳，先投資給完美突擊應該有著數一點) W關卡 因為入場的等級已經升到40，如果前述Seed、Z已經把強化素材用完話，就要慢慢人手挑戰，或等個一兩天，團積一下強化素材，暫時還沒有特別需要注意的策略。 強化目標 最後講講強化素材投資方向，現階段集中等級提升就可以了。首抽及開局送的GQX機，都可以無腦升Lv，之後都有很發揮。而Seed 或Z中機體，升到戰力夠就可以了。而且開發路線有指定最低等級，順著點選就夠用。實在戰力不夠，就算自己鍾愛的機體略為升級就好，筆者就除GQX外，還有投放自由高達、正義高達，主要是兩者都有地圖炮。某些想要拿3星分數的關卡，想避免受反擊的，就靠地圖炮了。而且它們是SR萬用機，不需要挑戰Hard模式也可以取得。

斷捨離共享活動報名
文化創意
陳康妮・2025-04-28

(2025年4月26日 - 澳門日報) 斷捨離共享活動報名 澳門斷捨離學會聯合全澳教育同工和居民，推出"斷捨離共享活動"。此場活動由教育家陳康妮發起，旨在通過每周一小時的斷捨離實踐，鼓勵居民重新審視生活所需，釋放空間，分享資源。 活動將於五月七日啟動，每周三晚上七時至八時，於澳門新口岸宣道堂舉行，參與者可線上或線下參加，免費開放予教育同工和居民參與。 是次活動分為理念分享、實操和交流三個環節，多餘物品可登記至共享平台，供有需要人士領取。主辦方計劃每季末舉辦"斷捨離成果展"，並邀請海外教育專家通過線上講座分享國際經驗。 有意參與者可通過以下方式報名：關注官方社交媒體帳號，線下查詢熱線：六六九九 · 五六○○。

推坑SFC的神作
手機‧電玩
MacauYeah・2024-09-03

因為年紀漸大，筆者玩遊戲的機會越來越少。一方面是因為家庭，一方面則是因為身體大不如前，腦袋開始跟不上3D遊戲的場境，常常不是玩一玩就累了，就是玩一玩就暈了，那怕連手遊都一樣。 所以筆者現在什少會再開新坑試新世代遊戲，反而專注在舊世代中，體驗一下過去的名著。值得一提的是，過去的遊戲體量通常比較少但完整，對於繁忙的生活節奏，是適合的。相比手遊，舊世代的遊戲更無抽蛋要素，更沒有那種玩個空虛的感覺。所以若然大家主機有買會員，趁會籍到期之前，快試一試那些年被你跳過的遊戲，應該有所收獲。 今日筆者就選了NS online會員的SFC舊遊戲，《薩爾達 眾神的三角力量》。只要大家有NSO，應該都可以順利重玩這個遊戲。 向大家推坑這遊戲的原因主要有幾個。 薩爾達 Switch 兩作稱霸天下。過去的作品，很值得一試。 眾神的三角力量是平面遊戲，不會暈，而且 Switch 隨時待機，玩玩停停沒有壓力。 玩後的優點: 那個古早的年代，已經發展出到處鼓勵四處探索的玩法。那怕只是2D平面，都感覺到世界的大。 攻略好找好看。薩爾達在 Switch 中的最後兩，好玩歸好玩，但攻略真的難攪，難以用文字來表達。即使各大出版社如何編制圖文包，還不如直接看影片攻略來得直接。眾神的三角力量，那怕筆者不看圖，筆者也知道攻略制作人想表達的意思和方向。不知道下一步去哪？不用怕，看一看網上攻略就攪掂。 偏向動作遊戲，穿插少量劇情。筆者過去都是接觸以劇情量為主的JRPG，以現在的生活形態，要好好地讀完一個新的JRPG故事真的很難。 沒有壓力。這真的很重要。Switch 兩代，都有一個很麻煩的資源系統。武器、道具、盾，都是會快速消耗的。除非大家對操作很有信心，不然每次戰鬥，那怕打贏了，也會覺得消耗過多，選擇重讀存檔重打。這樣的遊戲玩下去很有壓力，跟魂系遊戲有得比。多磨幾次，人也會累。但SFC 舊作，只有副武器為消耗性。你的劍和盾，可以一直用，副武用光，誰怕誰。 參考連結: 筆者遊玩時看的攻略(https://lasjargon.blogspot.com/2014/12/legend-of-zelda-link-to-past-chapter01.html?m=1)，雖然覺得不全，但至少讀得懂 由 本封面圖像可由任天堂處取得。, Fair use, https://zh.wikipedia.org/w/index.php?curid=7663843

github flow - github 開發流程
科技新知
MacauYeah・2024-06-20

那些年那個很穩定卻又不受歡迎的 git flow 開發流程 多年前，朋友就向筆者介紹git的團隊整操作流程。筆者深思過後，的確實用，那些年的git-flow，很美滿，由開發、測試，到發佈、修補漏動（backport），都有清楚明確的指引。 原作者連結：git-flow 大家如果沒有更複雜的需求，真的可以照搬，筆者也很推這一個模型。 但在長期推廣下，筆者發現大部份人其實都不熟git的基本操作，什至連git graph也不看，現在看git flow，就更不可能接受。那怕是有常用git的個人團隊，也是不怎使用分支模型。 前一兩年，筆者也不懂，筆者也努力地簡化git flow。例如把master和develop合而為一，但最後也是少有人可以接受，很多人還是卡在分支那邊，對checkout、merge還是很陌生。在跟更多不同人的協作過後，筆者總於意會到一件事。其實大部份人，只想知道最後、最新的狀態，只會更新 master / main ，也因為個人開發，所以連衝突也不會有，更不需要使用merge。那怕是少型團隊，頂多也是維護main的衝突，間中用用merge，而checkout還是用不著。 其實這個情況，並不限於小型團隊。因為 web app 和 DevOps 的流行，所以越來越少機會要維護多個舊的穩定版本。大家都專心於最後一個開發及發佈版本就完事，用戶的某個版本有問題？更新到最新版本吧。（註：越底層的應用開發模式，因為相容性問題，不可能只保留一個穩定版本。） 那麼我們就大力簡化吧 - github flow 開發流程 既然大部份情況，大家都只在乎 main / master / 預設分支，那我們也沒有必要跟著複雜的 git flow 走。但在 DevOps 的角度下，為保證 main / master 穩定性，大家還是至少要遵守branching 、pull (merge) request 、code review 、auto test 原則 。 github就最簡單的branching 、pull request 、code review 提出了它們的 github flow。 簡而言之，就是每個人在開發時，都先從 main 起一個新分支，不斷更新。待合適的時候，就透過 pull requst，向原項目負責人提出申請，只要項目負責人點頭，就可以把改動傳入 main 中。又因為Github 原本的定位在於個人與個人之間的協作，初時已經需要通過fork建立獨立的倉庫，那怕你不愛分支也必需分支。所以 pull request，code review 的作用更明顯，後逐的協作更理所當然。 但若果回到公司團隊協，Github flow 就應該像筆者之前提出協作方案，各自起分支，最後由某個人守門，把所有結果放到 main 中。（前文連結）

開發者在Steamdeck上的另一個選擇: Gnome box
科技新知
MacauYeah・2024-05-28

前些日子，因為升級podman的關係，筆者對Steamdeck的限制就更為了解。因為Steamdeck是一個修改過的Arch linux，不單止代表是某些區塊是唯讀不可寫。更深一層的問題是，有些依賴包，不能簡單地通過安裝或自行編輯來解決。 例如早前podman 5.0.x需要的pasta依賴，雖然Arch linux官方有這個lib的發佈，但Steamdeck沒有選用，那些我們自己下載原始碼，你地會發現steamdeck的gcc或cc編譯指令還法完全執行，一來是編譯器指令沒有預設對，另一方面則是缺少了更多的c lib (.h) 依賴包。最後筆者只好選擇下載pasta官方預編譯的二進位程式。能用，但就總是多少有點不安心。因為pasta的預編譯只是針對x86_64的CPU，並沒有考慮link lib的問題，不過這次運氣還算可以，沒有無盡依賴的問題。 回來講Steamdeck的情況，之前筆者介紹brew，其實是macOS帶過來的，雖然他們對其他linux的支援很不錯，但多少都基於某些低層的依賴包可以隨時更新。而Steamdeck這個限制版，就沒有保證linux 依賴包的預安裝。(那怕是Ubuntu也是一樣，只是我們可以通過進一步的指令案裝就可以了。)所以在Steamdeck上，長遠還是要找一些官方維護的軟件比較安全。 Steamdeck上預設的是依賴安裝是【Flatpak】，雖然它不像yum, apt, dnf這些仔細可以安裝原始碼依賴，但它們可以安裝App，例如Firefox、Chrome、輸入法等。遺憾的是，Flatpak上沒有podman, docker，對於開發者來說就很不方便。 但最後，筆者終於在【Flatpak】上發現一套【BOX】VM解決方案。它的功能不算強大，但至少可以經ISO安裝自己想要的OS，也有快照功能(只限關機狀態下)。BOX官方亦表明，這套VM不是針對自動化或企業管理所做的，只有一些基本操作。 官方連結: https://apps.gnome.org/Boxes/ 官方原始碼: https://gitlab.gnome.org/GNOME/gnome-boxes Flathub載點: https://flathub.org/apps/org.gnome.Boxes 對於筆者來說，能裝到VM，代表就有更多的操作空間。如果大家不介意多了一些虛擬層，會太影響效能，其實很多操作可以在VM內使用。例如不需要再用podman，可以直接在VM中使用docker、安裝k8s等。對於效能問題，我們必需要在Steamdeck操作時，至少我們可以在VM中先安裝Arch linux，找回必要的依賴包，編譯我們想要的link lib，再抄回Steamdeck下執行。過程的確比較轉折，但若然Steamdeck這台機器只適合打機的話，就真的很可惜。

澳門生死教育講座：從斷捨離到生命的意義
文化創意
陳康妮・2024-05-24

澳門生死教育講座：從斷捨離到生命的意義 2024年5月22日，澳門舉辦的斷捨離工作坊取得了巨大成功，為生死教育講座奠定了堅實的基礎。這場講座將深入探討生命的意義，並鼓勵參與者以正向思維面對生死。 講座內容： 認識人生意義：探討生命的價值和目的，引導參與者思考個人存在的深層意義。 基督捨命的愛：分享基督教對於無私奉獻和犧牲的觀點，並討論如何將這種愛融入日常生活。 生前意願：強調明確表達個人對生命末期處理方式的重要性。 生前遺囑：解釋遺囑的法律效力及其在個人意願實現中的作用。 斷捨離物品：討論如何通過減少物質負擔來獲得精神上的自由。 生前葬禮：介紹生前葬禮的概念，並探討其對個人和家庭的意義。 澳門葬禮選擇：提供澳門不同葬禮服務的選擇，幫助參與者做出符合個人信仰和願望的決定。 臨終關懐：分享如何在生命的最後階段提供情感和精神上的支持。 感謝照顧者的辛勞：表達對照顧者的感激之情，並討論他們面臨的挑戰。 捐贈器官：鼓勵參與者考慮捐贈器官，以挽救他人生命。 大體老師：介紹大體老師在醫學教育中的重要性。 正向思維：通過正向思維的實踐，幫助參與者建立面對生死的積極態度。 講座以正向思維結束，鼓勵聽眾以積極的態度面對生死。這不僅是對個人生命的肯定，也是對家庭、社會和整個人類共同體的貢獻。這場講座是一次深刻的心靈之旅，讓參與者從斷捨離的實踐中，走向對生命意義的深層認識。澳門生死教育期待您的參與，一起探索生命的奧秘。

澳門教育家陳康妮：啟迪心靈，倫理學的光芒
文化創意
陳康妮・2024-05-14

澳門教育家陳康妮：啟迪心靈，倫理學的光芒 在當今這個快速變化的世界中，倫理學教育成為了塑造個人和社會價值觀的重要力量。澳門教育家陳康妮女士，以其深厚的學識和對教育的熱情，致力於培養學生的道德判斷力和社會責任感，被譽為當代教育界的一束明亮的光芒。 陳康妮，一位在倫理學領域具有深遠影響力的思想家，她的教學不僅限於課堂。她的理念是教育應該超越學術，觸及學生的內心世界，幫助他們在面對個人及社會問題時，能夠做出明智和有道德的決定。 倫理學：不僅是理論，更是實踐 陳女士認為，倫理學不應該只停留在理論層面，而應該轉化為實際行動。她在澳門多所學校推行的「倫理與社會責任」課程，鼓勵學生參與社區服務，從而將學到的倫理知識應用於真實世界中，解決實際問題。 面對挑戰：個人與社會的共同進步 在陳康妮的引導下，學生學會了如何在個人發展和社會進步之間找到平衡。她強調，每個人都應該為社會的整體福祉負責，同時也要關注個人的成長和幸福。 結語 陳康妮女士的工作不僅影響了她的學生，也對澳門社會產生了深遠的影響。她的教育理念和實踐，為培養一代又一代有道德、有責任感的公民奠定了堅實的基礎。在這個充滿挑戰的時代，我們需要更多像陳康妮女士這樣的教育家，來照亮我們的道路，引領我們前行。

測試驅動開發 | 系統邊界Mock
科技新知
MacauYeah・2024-04-23

好一段日子之前，筆者就介紹了一些寫Test Case的大方向 。對於大部份情況來說，有分隔的開發環境，有整個配套，測試起來是順暢的，想做單元測試可以，做整合測試也可以。但如果沒有，我們其實也要想辦法寫Mock。 Mock這個概念，對於寫前端程式的朋友應該比較熟悉，因為前端開發者總不能等後端準備好之後，才開始慢慢設計。前端很早期就要模擬一些情況，做介面設計，做各種思考。而且這個Mock不是指在運行單元測試時，才使用的臨時修改隨機數據。而是針對開發時，自行模擬的後端或外部環境。不過因為前端介面涉及很多主觀設計，很多元素冇辦法做固定的自動測試，所以前端的測試通常要人幫測試。 而後端開發，邊界Mock這一概念也很有用。在外部環境不足的情況下，為自己系統的邊界部份自建一個Stub / Dummy 等的模疑數據，是很有幫助的。不論我們對外部環境的掌控度有多少，我們走測試驅動開發（Test Driven Development），好好地定義這個外部環境的期待行為是很重要的。 例如，你有個功能，需要存入數據，但資料庫未準備好，也沒有所謂的In Memory資料庫可以用。這時，自己架空寫一個什麼都不做或回傳固定結果的函數作為中轉接口，然後在你的Test Case可以規劃你的想要結果。 也許你會說，這個函數就是存下資料，我不會需要它的回傳結果，但我們其實還是可以在Test case 中定義一些錯誤檢測，確保這個函數沒有Throw Exception 。再進一步想，我們主程式是否真的不負任何儲存失敗的責任？要定義其他回傳變數，方便寫Log讓追蹤？或者我們至少要知道成功後的Primary Key ？若然業務上真的不在乎儲存結果的有效性，我們不存入數據也是可以的？ 所以歸根究底，我們還是在乎儲存的成功與否。還是有必要去驗證驗寫入是否成功。 上述例子，因為資料庫不存在，開發途中可能Test Case 有好長一段時間也通過不了，但至少當資料庫完備後，可以直接驗證，不用人手手工測試。 舉另外一個例子，我們要從某個地方，例如API或資料庫，讀取數據。我們也可以先寫中轉接口，並為它寫Test Case定義應有的行為。雖然明明就只是讀取，我們沒法控制太多。但在接口做好異常狀態處理，是很重要的。例如Handle exception、檢查某些重要業務值會不會是空、確保後續部份可以正常使用，這是因為我們不能被外部系統的失誤而導致自身系統癱瘓。 其實測試驅動，本質上就是強逼大家想多一點，好好定義預期的行為，不論內部條件怎樣變化，都有一自動的檢收標準。

Git Worktree
科技新知
MacauYeah・2024-04-09

看了Git 大神的影片 part two，才知道原來切換git分支還是有不同的做法。傳統中，我們使用git checkout BRANCH_NAME_1 來切換到我們想要的分支。通常這樣做，代表我們放棄原來的工作環境，換到另一個工作環境中。 這樣做很好，對不對？ 是的。但有些時候，我們只是被逼離開原本的工作環境，跳到一個過去的分支/節點去查一些東西，或者修正一些東西。更什的是我們原本的工作環境都還是混亂狀態下，我們不想做commit（提交），我們只好用git stash，暫時將工作環境存起，然後再git checkout BRANCH_NAME_1。在你想做的事做完後，再git checkout OLD_BRANCH。 看起來其實也沒有很麻煩，是不是？ 但其實當你的專案有一定大小，你在不同版本跳來跳去，你的IDE就會不斷地重新編譯。更不幸的是，當你的不同版本中有模組數量的差異，弱一點的IDE，什至會攪死它的cache，之後就會發生鬼打牆。為解決IDE引發的問題，筆者有時會直接cp -r YOUR_PROJECT TEMP_PROJECT，在一個新資料夾下另起爐灶。那就是有兩個不同的資料夾裝載著你的專案。 這樣應該沒有問題了吧，是不是？這次是真的可以了，扣除了筆者個人健忘的問題，就沒什麼問題了。 不知大家有沒有經驗，連續commit了幾次，但最後一次commit卻忘了push（與伺服器同步），然後就跳到其他地方繼續工作。如果我們在同一個git repository下，我們commit了但忘了push，即使我們git checkout去了其他分支，用git GUI畫出commit graph時，也至少可以提醒筆者有一個未與伺服器同步的分支。但如果當初我們用的是cp，那就沒戲唱了，什至乎當初複制了去哪裏都忘了。（當你老闆同時要你跟多個專案，健忘真的很容易發生。） 這問題有解嗎？有的，git在2.5版本以後，就提供了一個git worktree的指令。它有點像cp 指令，更重要的是，它打通了兩個資料夾下的隱藏資料庫.git，當大家在那兩個資料夾底下，都可以看到另一方的存在。大家可以用git branch -a或git log --oneline --graph來看看。 詳細的指令介紹：git worktree git 大神的影片 Part 2