搜尋

搜尋結果

重入膠坑 9 |加深刻線
手機‧電玩
MacauYeah・2025-06-20

之前就為大家介紹過,想有效率地消除Gunpla山積,事前計劃好一個概定的流程,絕對是件很重要的事。筆者亦有分享一過自己使用取件表的效果,對素組黨是有一定的好處。有時筆者亦會使用極簡版的素組流程,完全制作局部的部件,再進行下一部份,就只需兩個零件盒就夠。 最近,筆者就想再次升級,進行刻線加深再滲線,然後補色,那麼之前極簡版的步驟就不完全適用了。主要因為滲線部份,依據刻線的熟練度及不同顏料的特性,某些步驟要提前,關於顏料的部份可能一次性地使用會更佳。 簡單回顧之前素組流程:剪件→修件→打磨→組合→滲粗線→補色→保護漆。 現在,我們想利用刻線的方式為更多高低面滲線,至少要在完全組合之前就去刻。又因為刻線容錯率問題,刻線出界時,很多時需要利用打磨的方式修正。而且打磨之後,因為表面不夠光滑,水性滲線液比較難以擦乾淨,所以就在打磨之前滲線,可以避免一些奇怪的情況。 現在可以改成:剪件→修件→刻線→滲線→打磨→組合→補色→保護漆。 如果你的是琺瑯漆滲線液,只要刻線夠深,比較沒有擦不乾淨的問題,所以你可以考慮以下組合。 琺瑯漆滲線流程:剪件→修件→刻線→打磨→組合→滲線/補色→保護漆。 到底是先滲線還是先補色,就視乎補色顏料的附著力和互相溶解的問題。道理上補色marker附著力不強,怕在抹滲線漬時同時抺走marker,可能先滲線後補色會好一點。 最後,就再補充一下極簡步驟中,想完整完成一個局部區域再去下一步,這個想法理論上可行,只要大家不計較滲線液、水性漆的消耗率(利用率),是可行的。 全件修件後,之後再全件滲線,這樣滲線性就一次性地使用。這樣可以減少滲線性濃度不一致的問題,也差少在攪拌時出現的浪費(司特力的原裝瓶實在很易出意外,不如田宮的穩定)。補色方面也是,即使是經過調色,如果可以一次性地使用,就可以減少色差和消耗。如果大家不在意這些問題,也就不需要全件完成才進入下一步。即使在全件規劃的情況下,有時還是會因為失誤,而需要反工。

第三十五屆澳門藝術節。澳門炫目劇團舞台劇<今夜無人能睡>
文化創意
蘇蘇・2025-05-17

本應是最溫暖的避風港,卻成為了最沉重的牢籠;本應是相依相扶的家人,卻造成了最致命的傷害。在病態的關係中,有沒有哪種愛能帶來救贖? 澳門舞台劇《今夜無人能睡》以病態陰鬱的黑色幽默,直擊社會貧困家庭的困境,揭開長期照顧者與被照顧者無處傾訴的悲歌。 *照片來源: 澳門藝術節FB 演出陣容包括香港舞台劇獎最佳女主角楊螢映和最佳男配角蔡澤民,以及多位澳門演員,以寫實細膩的演繹探究人性的脆弱,是否能釜底抽薪尋找救贖的可能。 觀眾入座時,姐姐及婆婆已在演區內活動。姐姐因為交通意外,雙腿失去了活動能力,她戴着耳機看書,沉醉在自我世界中;失智婆婆則用助行器在台上走來走去,一會兒去洗手間,一會兒去倒水,一會兒在床上輾轉反側,妹妹在自己的房間沉迷著自己的事情,這就是她們的生活日常,活在同一空間但又沉溺在各自的世界中,互不干涉卻又相互依賴。觀眾一邊入場就座,一邊步進她們的日常之中。 剛開始時,觀眾會對她們正在做甚麼大感興趣,但當時間久了,就會慢慢的自僱看著自己的電話。這有如當下社會令人唏噓的困境,除非身在其中,又或者被報上新聞或社交平台,才會引起人們的關注。這不正是我們面對各類社會問題的狀態嗎? *照片來源: 澳門藝術節FB 總體而言,導演沒有以悲天憫人的形式呈現三婆孫的不幸,反而以略帶自嘲的荒誕引發思考。最後姐姐道出被照顧者與照顧者的永恆矛盾:既唏噓又依賴。 《今夜無人能睡》作為這屆藝術節的澳門代表,不僅是澳門藝術成就的展示,更是澳門文化主體性的宣言,透過戲劇讓世界看見這座小城的創造力與文化的深度,促進戲劇生態的可持續成長。

【日本。大阪】├住宿┤ 阪急大阪龍仕柏酒店 Hotel Hankyu RESPIRE OSAKA ~ 鄰近JR大阪站
走遍世界
80後愛旅行✈️・2025-01-19

「阪急大阪龍仕柏酒店 (ホテル阪急レスパイア大阪)」是一間位於大阪梅田的酒店, 地理位置非常便利,距離 JR 大阪站約 3 分鐘步行路程, 距離阪急電車大阪梅田站和大阪地鐵御堂筋線梅田站約 5 分鐘步行路程。 由關西機場到酒店,只要乘搭機場巴士就可以直達酒店樓下!!真的超級方便 https://www.kate.co.jp/tcn/timetable/detail/UM 「阪急大阪龍仕柏酒店」本館於2019年開幕,酒店樓下就是 Yodobashi Umeda 友都八喜梅田商場 由地下到八樓都是商店和餐廳,住在這裡根本不用"落地"都已經能逛一整天!! 「阪急大阪龍仕柏酒店 Hotel Hankyu Respire Osaka」 酒店Lobby在9樓,光是看Lobby就知道「阪急大阪龍仕柏酒店」超有規模。 Lobby很大,有很多休息的地方,剛下飛機還沒到 Check in 時間也可以在這裡休息一下再出門血拼! 酒店以主助Check in 為主,有很多部機器可供同時使用,而且都有多種語言的介面,非常方便。 Lobby 有提供免費咖啡、熱茶等供飲用 還有一次性的用品,可按自己需要領取。 這次預訂的是「30階以上高層 禁煙」的雙人房,最後竟然被安排在35樓頂樓的房間,超棒的!!! 一開門進來我真的尖叫出來!!房間超大超美的!! 有在日本大城市住過酒店的人都知道,東京、大阪這些鑽石級地段的酒店,房間都小到連行李箱都打不開! 但這裡居然大到可以是"多層"的平面設計!! 一進房門,旁邊是獨立的廁所,外面有一塊全身鏡。出門前都可以整理一下,很方便! 而另一邊是開放式衣櫃,我個人是很喜歡這種沒有門的設計,感覺比較乾淨。 再來下一"層"是梳洗的地方,有洗臉盤和浴室。 洗臉盤的位置很大,放東西後還有很多空間,作為化妝枱用很不錯 浴室有跟日本傳統,有浴缸,也有淋浴的地方。 而另一邊是放了雪櫃,和免費的飲用水。 來到最後一"層",就是睡床的位置。 其實單是這裡已經比很多大阪酒店大了!! 是兩張單人床的設計,每邊各有一個床頭櫃,還有小桌子和椅子。 對面還有工作枱和電視,真的有超多空間可以放買回來的戰利品!! 而位處35樓的房間看出去的風景也很美!!超開揚的!! 我在房間內欣賞了日、夜景,還有黃昏的景致,真的有點不太想出門 「阪急大阪龍仕柏酒店 (ホテル阪急レスパイア大阪)」的電梯除了可以直達地面外,還可以到達空中走廊, 不用日曬雨淋,就可以走到 JR 大阪站、阪急電車大阪梅田站、大阪地鐵御堂筋線梅田站、周邊的各大商場等, 都可以經過空中走廊直接連通!! 四通八達的空中走廊 而在酒店9樓Lobby還有一條扶手電梯可以到達商場8樓的美食廣場 / 餐廳 有天逛完街回來就直接在8樓的餐廳吃飯,再用這條專屬的扶手電梯回酒店,真的超方便! 2024年6月連續入住了4晚,一共是 98,640 円,當中每晚的房價都不同,平均大概每晚 24,660 円 這個價錢能夠住在 JR 大阪站旁邊,酒店樓下又已經有商場和餐廳, 不論是交通還是購物都非常方便的地點!! 真的很推薦這間「阪急大阪龍仕柏酒店 (ホテル阪急レスパイア大阪)」 ホテル阪急レスパイア大阪

為程所困-是什麼讓你不想寫自動化測試?
科技新知
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 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做太細緻的權限管理。

Swarm Mode 上線番外篇:Ceph
科技新知
MacauYeah・2024-08-20

在預設Docker和K8s的容器主導世界裏面,其實一直都缺少了直觀的儲存空間。當你的程序需要讀寫故定的來源資料,該來源就必需是外部的穩定儲存空間,例如是資料庫、NFS。但資料庫、NFS等,要做到真的正穩定,其實就要走Cluster(叢集)模式,確保它們自己本身不是做成single point of failure (單點故障)的元兇。 坊間,只要付得起錢,其實找個穩定的資料庫或NFS,也是有的。但如果你像筆者一樣,只有一塊或多塊【鐵】,就要試試開源的儲存引擎Ceph Storage。 Ceph Storage,有自己特有的CephFS格式,但也支援NFS https://docs.ceph.com/en/quincy/cephadm/install/。也就是,只要我們有足夠多人力,道理上可以自己用實體機去模擬一個穩定的NFS。 因為只是試裝,筆者暫時只用VM來測試,完整的安裝script,可以在這裏找到。script使用Multipass VM,大家有條件的話,可以使用其他VM引擎來看重複。以下是一些官網上沒有提的重點: Ubuntu 24.04 還未能正式使用。在筆者做POC的當是,Ceph v18 在 Ubuntu 24.04上需要先解決,即使大家使用Curl base下載 binary,也未必能成功。 筆者成功測的版本是 Ubuntu 22.04 + Ceph v17,全使用Ubuntu 發佈的內置版本。但大家也要留意自己的Ubuntu apt 有沒有更新到最新版,過去的 cephadm,引用的container image url也變更。記得更新到v17 的最新版,cephadm 指令才能成功取得image。 在官方說明文件的【Deploying a new Ceph cluster】中的【Adding Hosts】https://docs.ceph.com/en/reef/cephadm/install/#adding-hosts 節章可能有些誤導,大家應該要看 【Host Management】中的【Adding Hosts】 https://docs.ceph.com/en/reef/cephadm/host-management/#cephadm-adding-hosts 在每個節點內,可以直觀地連接地Ceph Dashboard,但若大家需要Port Forword,要注意你的Network Interface,筆者就只能經過預設的IPv4的public ip 進行ssh port forward,不能經過0.0.0.0。 Script 位置 https://github.com/macauyeah/ubuntuPackerImage/blob/main/initCephCluster.sh

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 中。(前文連結)

Beame 積極開拓國際市場 香港商人范榮彰博士太平紳士引領高質素箍牙服務 冀讓世界各地更多人受惠
CTM企業動向
范榮彰博士太平紳士・2024-05-30

由前東華三院總理香港商人范榮彰博士太平紳士創辦的 Beame 是一家香港牙科公司,致力於為客人實現健康美麗的笑容,提供更多人性化的箍牙解決方案,同時推動牙科行業的發展,並在國際舞台上擴展其業務。 Beame 擴展海外業務 提供全球高質素箍牙服務 Beame 團隊由一群資深香港醫療界人士組成,憑藉他們對牙科服務及牙齒矯正的專業知識和先進技術,Beame 在中環、K11、Times Squares、觀塘、南昌及沙田等地設有六家諮詢點,提供箍牙和其他服務諮詢及保養等服務。此外,Beame 的專業團隊擁有豐富的經驗和專業知識,他們會根據每位客戶的需求和期望,利用最新的技術和先進設備,提供個性化的治療方案,確保獲得最佳的箍牙效果。 國際級醫療設備保證品質 Beame 在深圳開設的自有光店,成為該公司在香港以外的首家分店。深圳自有光店提供全科牙科服務,包括全瓷牙齒貼面、藍光美白、植牙、洗牙等。所有療程由香港醫療團隊管理和設計,並使用國際級醫療設備,確保顧客獲得最佳的治療效果。顧客可以在香港和深圳各分店享受服務,同時獲得保養和諮詢服務,讓他們擁有健康美麗的笑容。 范榮彰致力推動牙科產業的發展 除了在香港和深圳,Beame 正在積極擴展海外業務,計劃在澳洲、澳門、台灣、新加坡、馬來西亞和泰國等地開設分店,以滿足不同地區對高質素箍牙服務的需求。這一擴張將使更多人能夠享受到方便快捷的牙齒矯型服務,同時推動牙科產業的發展,為當地經濟帶來增長。 范榮彰博士:希望能夠改善大家的口腔健康 Beame 創辦人范榮彰博士太平紳士表示:「隨著全球人口老化,牙科需求會越來越大,我們致力於提供優質的齒科服務,讓更多人了解並正視牙齒問題的重要性。我們希望能夠改善大家的口腔健康,同時亦為世界各地創造更多機會。」 Beame 的願景是成為世界領先的牙齒護理品牌,並為更多人提供優質的口腔護理服務。他們致力於改善人們的口腔健康,提升他們的自信心和生活質素。通過拓展海外業務,Beame 將為更多人帶來燦爛的笑容,同時為社會經濟發展做出積極貢獻。

測試驅動開發 | 系統邊界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、檢查某些重要業務值會不會是空、確保後續部份可以正常使用,這是因為我們不能被外部系統的失誤而導致自身系統癱瘓。 其實測試驅動,本質上就是強逼大家想多一點,好好定義預期的行為,不論內部條件怎樣變化,都有一自動的檢收標準。