搜尋

搜尋結果

兩大年度音樂盛事 助力澳門「旅遊+娛樂」發展
生活在我城
80後愛旅行✈️・2025-08-26

澳門銀河綜合度假城旗下銀河綜藝館宣布,與TMElive騰訊音樂超現場(下稱「TMElive」)的戰略合作協議將續簽三年, 雙方協議在各自的資源及平台領先優勢下,助力澳門文化旅遊產業高質量發展, 同時為來自世界各地的音樂愛好者帶來精彩、多元的音樂娛樂體驗。 首屆TIMA國際音樂大賞及第六屆TMEA騰訊音樂娛樂盛典亦順利於銀河綜藝館完滿舉行。 三日的盛事吸引眾多海內外樂迷蒞臨銀河綜藝館,並帶動澳門的旅遊景點人流絡繹不絕,充分展現「旅遊+娛樂」的聯動成果。 在剛過去的8月22至24日,首屆TIMA國際音樂大賞及第六屆TMEA騰訊音樂娛樂盛典於銀河綜藝館圓滿舉辦。來自全球一共25組演出單位分別於22及23日先後登上TIMA的舞台。 首屆TIMA國際音樂大賞及第六屆TMEA騰訊音樂娛樂盛典舉行場地銀河綜藝館專為世界級盛事而設。逾3,000平方米的面積可容納多達16,000位觀眾,是亞洲最大最先進的室內綜藝館之一。舞台的搭設具有高度靈活性,規模可讓樂團們充分展現多元音樂、曲風,盡情揮灑音樂創意與表演,為樂迷們奉獻超乎預料的演出效果。「澳門銀河」同時亦積極助力澳門「演藝之都」的建設,尤其在與TMElive騰訊音樂超現場達成的戰略協議之下,為來自世界各地、不同類型的旅客及本地居民呈現精彩絕倫的演出,為澳門注入更多音樂能量,推廣澳門「旅遊+」及2025東亞文化之都的多元魅力。

Docker 101 - 為何要做成Docker (Container - 容器化)
科技新知
MacauYeah・2025-07-21

筆者更新了之前的Docker入門筆記(https://github.com/macauyeah/VMDockerNotes/blob/main/DockerConcept101CN.md),順便補充了一些內容。如果各位讀者還在糾結要不要進行容器化,可以看看這些特性有沒有讓你心動。 Container - 容器化的便利 1. 做到隔離效果 傳統上,同一機器安裝不同的 lib / dependency ,可能出現衝突。在 docker 的環境下,不同 container 之間可以隔離開,除了是網路之間出現引用關係的衝突外,動態庫的衝突就沒有見過。一般處理好 Persistent Volume 的考量,單機下是沒有什麼問題的。 2. 遷移的過程比較簡單 傳統上,要把程式從一台機器搬到另一台機器,要預先安裝好相關的 lib / dependency 。但使用 docker / container 後,只要 docker 版本相容就好。docker image 本身,就已包括所有的 lib / dependency 。另一個常見的傳統問題,就是 Linux 檔案的擁有權問題,特殊情況下,新機同一個 user 的 ID 編號也不一樣,可能要手動恢復權限。如果是 container 的 bind mount 檔案,只要使用 tar command (`tar --same-owner -xvf file.tar`)保留權限解壓就好。 3. 垂直水平擴容 因為有隔離及遷移方便的優勢,原本的機器達到上限,可以隨時換到其他機器上,修改對應的用戶入口就可以了(或更改DNS,可以更無縫連接)。一台機器不夠,亦可以多台機器一起來。即使不使用 docker swarm / k8s 方案,有傳統的 proxy gateway 再加單機的 docker ,就可以做到分流的效果。 當然使用 docker swarm / k8s 才是正解,可以更簡化 proxy gateway 的設定。而傳統的分佈式問題,例如 Share Storage 等,其實就沒有簡化到,但也沒有增加難度。所以大家若考慮擴容的問題,更適合考慮使用 Container 的方案。 筆者總結這兩三年來的使用經驗,只要大家一直有用開Linux,其實單機容器化不太難,頂多就是配置外置Persistent Volume / Share Storage會帶來不習慣。而大家也可以想,Storage 這問題,是隨時隨地佈署應用程式的不可或缺的思考方式。Docker 沒有帶來更多的麻煩,而是帶來更多標準化的應用,例如傳統的NAS / NFS,也是這個Storage問題的其中一個解法。

不用Multipass,自動化還有什麼選擇?
科技新知
MacauYeah・2025-05-28

因為multipass 升級同時轉換driver的關係,很久之前筆者介紹的multipass static ip 慢慢開始失效。如果大家只是為了做lab,雖然multipass預設的不是fix ip,但它的dhcp ip並不常更換,在multipass上起VM還是有一定優勢。 但若大家在更大的環境下,不可能有類似multipass exec 的型式去下指令,又或者,我們本地也沒有足資源做VM,必需使用公有雲,我們還有其他可以自動化的方法嗎? 有的。那就最初的ssh。 假設在公有雲,開了三台Linux VM,要作為聯機實驗用。我們只需要再一台Linux跳板機(可以是cloud VM或是local Mac / Linux,就可以順序以ssh為三台VM下指令。我們不需要開三台terminal,在不同VM之間切換,我們是直接在跳板機下指令,也就在跳板機上,實現自動化為三台機進行一系列的設定。 即是如果之前可以經multipass exec 完成的自動化,只要不涉及重置網絡操作,道理上也可以經ssh 實現。例如筆者之前的docker init可以這樣改寫 # local multipass exec -n NODE_NAME -- docker swarm init # remote ssh USERNAME@NODE_NAME -- docker swarm init 抄檔案也可以改寫 # local multipass transfer SOME_SCRIPT_FILE NODE_NAME:. # remote scp SOME_SCRIPT_FILE NODE_NAME:. 也因為公有雲或某些公司網絡,我們什少可以改變它的網絡設定,我們基本只可以使用預留的IP進行設定。不過也因為這樣,我們什少再作出重置網絡的操作。 但大家還是要留意,如果要真順暢ssh或scp,需要預先綁定ssh key。這些預先綁定ssh key的功能,一般在各大的public cloud都會有。如果沒有,我們也可以自動化開始之前,先使用ssh-copy-id為所有VM加入ssh key,這邊筆者就不再重複敍述。 參考資料 https://www.cyberciti.biz/faq/what-does-double-dash-mean-in-ssh-command/

概有雲供應商的K8S,為何要自己弄Docker Swarm / 本地K8S ?
科技新知
MacauYeah・2024-11-19

其實筆者寫了這麼多篇docker 的文章,可能有朋友會問,為何要自己從零建立Container環境,使用供應商直接提供的K8S服務不是很好嗎? 按照市場發展,各大雲供應商都越來多,競爭越嚟越激烈,作為用戶方,理應可以得到更合理的價格。不過作為使用VPS多年的筆者,真的沒有覺得雲服務的價格可以便宜到一個不用煩惱的水平,大家還是需要很㥀重地考量自己的業務是不是值得雲端化。 正常來講,在有足夠使用量的前提下,雲端化也是合適的,也真的有產到錢。但問題是大部份情況下公司內部自主開發的應用,都沒有去到這個程度。每個應用去租用一個VPS,即使使用最低配置,用起來的時候覺得不夠快,閒起來的時侯也是浪費錢。 這時,使用 Container 技術,就是讓多個不同的應用,共享同一個或多個VPS的好方法。因為 Container 可以簡易地做到應用之間的隔離,即使不同應用之間有依賴衝突,只要 Contianer 層面沒有衝突就可以共存。 Docker swarm 與 K8S 同為 container 技術,文章最前面,就提到了這個問題,為何不選現有的K8S,反而要自己弄Docker Swarm?其實關鍵亦是價錢的問題。使用K8S固然方便,但就每個節點都得使貴一級的雲端供應商服務,當我們的應用總是流量不足,就更易變得食之無味,棄之可惜。老實講,貴一級的雲端服務,有它存在的價值,很多東西可以做自動化擴展,例如概據流量自動擴容。另外,因為底層 Container 技術有供應商支援,也不用再另外購買支援服務。但這些都是業務有一定流量,才能展現出優勢。 反觀Docker Swarm,就是簡單可入手,初時一個VPS也可以。什至乎不上雲,找幾台舊電腦,實機做也可以。當然K8S也可以實機,不過就簡易程度來講,Docker Swarm 無得輸。待業務真正成長到一個有足夠流量的服務時,才進一步遷移到供應商的原生雲。在初期使用自建的Docker Swarm或小型K8S,可以先加入一些資源統計,以確定是否即裝滿負荷。

Docker Image打包建議
科技新知
MacauYeah・2024-07-10

之前筆者有分享過兩個不同的Docker Image打包方式 App直接打包成Image 只把底層程式打包在Image中(例如Tomcat),再用Docker Volume的方式讓Container可以起動App。 筆者就兩種方式做了一個條列式的對比。詳見連結 https://macauyeah.github.io/AProgrammerPrepares/VMDockerNotes/DeployDockerClusterCN.html 因為兩種方式筆者都有實作過,也算用了很段時間,所以也有一些實際經驗可以分享。 如果大家上正式的Docker課程,Docker導師通常會推薦為每個App打包成獨立Image,因為底層程式的Overhead通常不大,例如底層程式是Tomcat、Apache、Nignx這類網頁伺服器,重量級的開銷並不是因為多幾個Web Engine的分身造成,通常都是因為業務本身。但如果你講的底層程式是資料庫等的大型程式,才可能會有明顯的差異。 但實務上的建議,就是必需考慮自身的經驗,到底那個方案自己比較有把握。獨立打包App,在正式環境也需要考慮跟蹤問題的情況,多個不同App要溝通,也是了解Container網絡。如果打包底層程式,所有App都可以當成是本機下運行,更有信心追蹤問題,也是一個很好的出發點,到了有需要彈性改變不同App的需要,才轉向獨立打包的做法。 筆者最初也是走這個打包底層程式的方向,到了自己有信心試用Docker Swarm,才走向獨立打包的做法。筆者親身經驗,因為到了Docker Swarm,網段會變得暴增,這跟公司現有的內部網絡相衝的機會就會變多。在Swarm起立初時,筆者並沒有意識到這件事,所以當初排查問題,也花了一些時間才知道要向網段衝突上著手。 另一個出自Docker導師實務上的建議,就是正式環境中不要做用Docker compose,應該使用Docker Swarm。那怕Swarm只有一個節點,也應該用Swarm,導師的主要理據是Swarm有Rolling Update (滾動更新)的機制。同一個node也可以有多個分身,每個分身輪流更新,就不會出現大中斷的情況。筆者就自身經驗,Tomcat可以同時容納一個App的多個版本,Nginx也有Failover(故障轉移)等,如果你很熟這些功能,不一定要需要靠Swarm去提供。可以按自己步調去慢慢適應。

Oracle Database in Docker
科技新知
MacauYeah・2023-09-22

雖然筆者之前有提過,Docker並不是萬能,Docker在管理有狀態應用(Stateful Application)的情況下,只能走單機路線。但因為Docker實在很方便,所以連Oracle Database這類強狀態應用也有出Docker版本。當然,它在預設的情況下,只能在單機下操作。 不過即使在單機操作下,還是有一些跟其他Docker Image有差異的地方,需要特別拿出來聊聊。 假設根據官方的教學,跑起了一個oracle19c的Docker Container。再查看當中的Process,你會發現有一個內部PID為1的runOracle.sh 在Docker中這個PID為1的Process是很重要的,它是判斷整個Container有沒有運行的依據。它就是當初在Docker Image中Entrypoint或CMD指定的那個指令生起的Process。Docker daemon要進行停止指令,要停止container時,也是對著PID為1的那個process來處理。 一般的情況下,如果PID為1的那個process可以無腦地停了、重開,那一切都好辦。但在Oracle Database的情況下,就不適合。因為Database始乎都是有交易概念的(Transaction),它的停止並不是殺了process就了事,它還要考慮HDD操作中,有那些可以被考慮為完成,有那些下次要還原(undo)、重做(redo)。如果殺了process就等於Oracle 的Shutdown Abort,有機會下次開機會,就會有交易異常而且無法決定該如何操作。 大家需要先進入Docker container,經sqlplus進行必要的關閉Database指令。但此時,PID為1的那個process,其實還在進行中,在Docker 層面,它就像是Docker Container還在正常運行中,只是Database離線了。又因為sqlplus關閉Database並不是馬上有結果的,所以在整體關閉時可能需要串連command。就像

四年的等待-《戰神:諸神黃昏》上
手機‧電玩
MacauYeah・2022-12-02

一鏡到底的運鏡手法、優秀的畫面、劇場的吸引力,都是《戰神(2018)》的優點。再加上筆者是一個忠實的劇情黨,所以對它的續作《戰神:諸神黃昏》期待更加高。原本還以為會很快就DLC形式推出,結果一等就是四年。 以下部份涉及劇透,不想受影響的朋友趕緊回頭。 筆者尚沒玩到大結局,就初期三章,但感覺要麼故事伏筆很多,要麼就是有點硬來。從一開始,大家都在找尋謎之提爾,與芙蕾雅開戰停戰、到變成夥伴,這幾個部份的劇情都不錯。 但阿特柔斯處理所謂的預言,由積極找尋預言, 到突然進入巨人世界鐵森林了解預言。再由安格爾博達解說預言是由她母親所畫的,並得知父親會死亡,自己會幫助奧丁。由不相信到自己主動找奧丁,這種奇怪的舉動,實在令人費解。雖然阿特柔斯還是處於叛逆期的狀態,但就顯得有點別扭。可能之後有反轉吧。 到遊戲方面,介面處理有點「老」,感覺好像回到十年前的版面設計。而所謂的開放世界,其實還是半開放吧,與《戰神(2018)》一樣,每段劇情的路線差不多都是只有一條到達終點,其他路線只是拿物品而已,支線劇情仍然處理得不錯,可以知道每個角色的過去以及地區的面貌。而且夥伴角色不同,但不可以選擇。怪物的種類在本作就暫時只有幾款是全新的,其他還是沿用上集的。 未完,待續

MHR Sunbreak 體驗日記-3 那些過於硬核的打擊機制
手機‧電玩
MacauYeah・2022-11-18

Monster Hunter系列出了名的硬核,並不是單純的是敵人AI很強、攻擊有多猛,更重要的是對於操作細節的要求。 筆者一開始並不認同MH有很強的打擊感,因為以筆者初入門的水平來感覺,只會感到自己在打牆。在打牆的情況下,不論怎樣有打擊感,都只感覺到被反彈,一點打擊樂趣都沒有。玩著玩著,打到正篇的後期,感覺從打牆變成了打空氣,因為魔物越走越快,越走越遠。大家若想體會打擊感,online組野團可能會比較有感覺。 但這些打牆、打空氣,其實都是制作組故意為之,好讓大家感到有壓力,讓大家嘗試以不同的裝備性能對反制魔物。打牆、打空氣的成因主要是因為累積傷害和DPS的不足所致,雖然打到肉質(弱點)好的位置,但魔物總是有霸體,一手把你反彈走;魔物招式打空了,你想大招反擊,但你大招出來時,牠又剛好走了。 在不斷的熟習自己武器的性能,讓普通攻擊可以恆常地命中後,各積異常狀況就會在魔物身上累積,那怕你拿一把純物理武器,魔物被恆常攻擊後,都會出現倒地狀態。在裝備或貓飯加持的性況下,這地倒地狀態就更容易地在拼刀中出現。那些直正痛快的感覺,就是在倒地後的一波大輸出中體現。 可是萬惡的制作組,怎樣讓你這麼容易地感覺得快樂呢?這遊戲還有一個「打點」的重要設定,一下打歪了,資源就會完全浪費。這是筆者從正篇打到來DLC都還沒有掌握好的東西,欲哭無淚。 玩壞了的MHR 充能斧

你在看短篇攻略還是在收藏經典?
手機‧電玩
MacauYeah・2022-05-18

網路多媒體盛行與普及,媒體也逐漸輕量化。像Blog的出現,比起寫書寫散文要輕量得多,但慢慢地,寫Blog也嫌太長,寫Tweet(Twitter)/ Feed (Facebook)就適合大眾閱讀。影片類媒體也一樣,長篇影片創作成本高,收效也相對低,還不如短視頻有力。遊戲攻略也如是,在資訊不斷發達,大家寧願簡斷地分享一些小技巧,也鮮少有人有條件地把所有事情串合起來。 但當生活都充斥著短媒體的時候,長篇媒體就顯得更加有品味和價值。過往攻略書很受歡迎,最主要是因為資訊傳播渠道太少。但現在遊戲攻略不再局限於紙媒,一個大而全的遊戲專題攻略,就變得像神一樣的存在。筆者雖然已經無法像過往一樣長期玩遊戲,但筆者依舊有關注一些質量高的遊戲攻略網站,間中,筆者也會購買它們的實體書作為收藏。 UCG遊戲機實用技術 - 一個歷久不衰的國產雜誌 在那個中國還未開放遊戲市場的年代,UCG就已經營遊戲媒體。那些年,PS2的攻略,筆者也有收藏過一本。在如今網路資訊盛行,它也還健在,確實很有實力。近一兩年,筆者陸續入手了五本UCG的專輯,除了其中一本的內容比預期差了點,其餘四本也是滿滿的誠意,其中《黑暗之魂火之檔案 三部曲》,NPC的對話內容就不是一般網站可以找得到找得全;《鬼泣 終極檔案》各代隱藏技/里技,每關隱藏要素都列出及最高難度攻略,實在讓筆者也想不到。 vgtime遊戲時光 - 網台及網路攻略 這是一個經營了好幾個年頭的網路媒體,雖然資料量比不上台灣的巴哈姆特,但勝在有整合資訊。查找攻略的時候,可以更有系統地了解遊戲的操作和要素。筆者在攻略一些獨立遊戲,像是《Hollow Knight》的時候,靠的就是它了。即使AAA大作,大家也可以在這個平台搜搜看,雖不一定有完全攻略,但它的碎片攻略也比HK01的攻略好多了,因為它的出圖和分頁方式比HK01好很多,不會出現圖文互相干擾的問題。另外,它們也有網台節目,打機打多了,聊聊Game也是另一番風味。 如果各位讀者對遊戲媒體有其他推薦,亦不妨在本文留言,讓更多人可以知道好東西的存在。