潮流特區

焦點文章

CyberCom3合1充電數據線 — 一條線搞掂晒,充電超方便!
科技新知
Lifemagtechie・2025-06-12

而家大家手上嘅電子產品多到數唔清,手機、平板、藍牙耳機、遊戲機hellip;hellip;每部機都有自己嘅充電線,仲有啲好舊款用USB,iPhone用Lightning,最新又係TypeC,搞到充電時成日手忙腳亂,尤其去旅行,帶幾多條線都唔夠! 呢條 CyberCom3合1充電數據線,就係為咗解決呢個煩惱而生。佢集合多種接口於一身,無論你係用緊iPhone定Android,甚至其他電子裝置,都可以用一條線搞掂晒,方便又慳位,真係你嘅生活充電好幫手! 一條線,多種接口,無懼設備多 CyberCom3合1充電數據線支援 Micro USB、USB A、Type C 同 Lightning 四大接口,無論你係iPhone、Samsung定係其他品牌,甚至係藍牙耳機、遊戲機,都可以用呢條線充電同傳輸數據。旅行唔使再帶一大堆線,行李又有位可以擺多啲戰利品啦! 快充快傳,效率up up! bull; 支援QC快充技術,最高60W輸出,手機、平板、智能手錶都可以超快充滿,唔使等成日。 bull; 傳輸速度高達480Mbps,無論係工作文件定係娛樂影片,一link就傳,節省你寶貴時間。
 耐用又防纏繞,攜帶超方便 bull; 採用彈性TPE物料,線身唔易打結,收納方便,唔怕亂晒。 bull; 線材耐用又有彈性,日常用或者出街旅行都好啱用。
 產品小百科 bull; 1米長度,無論係屋企、公司定旅行都啱用。 bull; 建議零售價 $99,依家優惠價$79就可以帶走。
 由此開始,充電更快更簡單! 設計貼心,性能強勁,係你工作同生活嘅好拍擋。無論係手機、平板、遊戲機定藍牙耳機,呢條線都幫你搞掂晒充電同數據傳輸,令你嘅數碼生活更輕鬆自在。了解CyberCom3合1充電數據線嘅詳情同優惠,幫你打造更智能、更方便嘅充電新體驗!購買網站 www.cyberportcom.com查詢電郵 info@cyberportcom.com

最新文章

何謂 Infrastructure as code - IaC
科技新知
MacauYeah・2024-06-07

在雲端服務出現後,好多新的名字,或許大家都聽過,筆者也稍為再簡介一下。 Software as a Service Saas。就像我們的Web App,不用下載體件,可以直接經雲進行業務操作。 Platform as a service Paas。這個概念可能最含糊,筆者理解就是,雲端供應商提供一些底層的軟件,供IT人使用。像是資料庫,Web Engine。 Infrastructure as a Service Iaas。這個更底層,雲端供應商給出CPU, IP, Memory, Storage等,頂多就再多個預安裝OS的選項。IT人自己去配搭使用。 多得這些彈性服務,雲端應用才真的跟過去租用實體伺服器有所差異。 但對於IT人來講,要使用這麼多不同的服務,實在也不簡單。對於IT消費方,用錢換來實體硬件的靈活性,但因為硬件沒有邊界之後,軟件的量就暴增。管理也不能說是很方便。 在Docker, Kubernetes等Container容器出現後,又為這些管理問題帶來另一種希望,就是Infrastructure as code IaC。它的目標是,管理基礎設施,要像管理原始碼一樣,checkout 就可以回覆到指定狀態。 初聽之下,大家可能覺得好玄,但其實這個概念,在之前筆者的Docker 教學中,已經有出現過。Docker compose 、Docker stack 指令,它們都是基於yaml檔的IaC。 當筆者更新了yaml 檔,執行一次stack deploy ,docker 就會對比之前狀態,如果replica分身不夠多,就自動增加所欠數量,如果image 也更新了,就排隊輪流重起換image 。最重要的是,當我們checkout 舊的yaml 檔,回到過去某個狀況,只要還是執行同一句stack deploy ,系統就自然減少所需的replica數量,下戴過去的image。這就代表,我們對於container 構建而成的環境,都可以放入Git等版本控制中,整個管理模式,就像管理程式碼一樣GitOps。 對於更進階的Kubernetes更是如些,除了container外,多種不同的network,storage配置,都通過yaml檔進行控制。這樣,架構即使複雜,但只少可以測試、重現和管理。還有一個,它比Docker stack要強的是,它某程度上支緩刪除的概念。雖然不完全,但總比完全沒有方便。 這個IoC的概念,可能還未達到一定廣泛地應用的階段,但它的核心在於,基建項目有檢測試差異的功能,自動去因為這個差異去加或減資源。用Programmer的講法,就是系統有Diff的功能,自動多除少補。

開發者在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不是針對自動化或企業管理所做的,只有一些基本操作。 官方連結 httpsapps.gnome.orgBoxes 官方原始碼 httpsgitlab.gnome.orgGNOMEgnomeboxes Flathub載點 httpsflathub.orgappsorg.gnome.Boxes 對於筆者來說,能裝到VM,代表就有更多的操作空間。如果大家不介意多了一些虛擬層,會太影響效能,其實很多操作可以在VM內使用。例如不需要再用podman,可以直接在VM中使用docker、安裝k8s等。對於效能問題,我們必需要在Steamdeck操作時,至少我們可以在VM中先安裝Arch linux,找回必要的依賴包,編譯我們想要的link lib,再抄回Steamdeck下執行。過程的確比較轉折,但若然Steamdeck這台機器只適合打機的話,就真的很可惜。

BEYOND EXPO | Dr. Easy好醫師智慧醫療平台 打造澳門智慧城市
科技新知
Cheers!・2024-05-24

為推動本澳智慧醫療發展,澳門電訊打造了結合人工智能技術Dr. Easy好醫師醫療平台,澳門電訊Dr. Easy好醫師醫療平台啟動儀式在23日下午,於BEYOND國際科技創新博覽澳門電訊展館舉行! 平台啟動儀式 郵電局局長劉惠明、衛生局局長羅奕龍、澳門中聯辦經濟部助理陸上城、議員陳澤武、胡祖傑、梁孫旭、梁鴻細、鄭安庭、羅彩燕、馬耀鋒及澳門電訊行政總裁潘福禧共同參與平台啟動儀式。 澳門電訊商務副總裁湛寶儀發表 「Dr.Easy好醫師平台是澳門電訊面向醫療機構和服務使用者打造的一站式智慧醫療解決方案,提供多元化的數字管理功能、問診預約、檢查預約、遠程視像諮詢及報告查詢等功能,並內置了AI生命體徵檢測功能*,應用人工智能技術,透過面部掃描可分析身體健康數據,隨時掌握大致的身體狀況。亦期望透過該智慧醫療平台,為醫療機構及服務使用者解決現時存在的痛點、難點,打造一站式便捷高效的診療體驗。」 澳門電訊商業服務及拓展高級經理邵慶祥詳細介紹Dr. Easy好醫師平台亮點 為醫療機構提打造管理系統 實現資料雲管理 服務使用者端一鍵預約、覆診、報告查詢等功能 首批進駐澳門電訊Dr.Easy醫療平台嘅醫療機構代表 澳門明愛 歐亞口腔醫療中心 健滙醫療中心 尚越醫療中心 諾安醫療服務 工人醫療所 便民醫療中心 百利康醫療中心 九澳護養院 澳門電訊亦會繼續透過引進及自研各項智慧轉型解決方案,為醫療服務使用者打造更優質的智慧醫療服務體驗,助力澳門各界加速數字化轉型步伐,為市民打造一個智慧城市! *AI生命體徵檢測功能之所有數據不能代替醫療專業人員的臨床判斷,結果只供參考,如有需要請聯絡專業的醫療人員諮詢

BEYOND EXPO | 澳門電訊 X 澳門大學 延續項目合作 推動智慧旅遊業
科技新知
Cheers!・2024-05-24

為推動澳門智慧城市建設發展,澳門電訊與澳門大學早於2018年已簽署了戰略合作協議,透過雙方的合作,成功完成了「旅遊大數據算法研發」及「自動化客戶體驗測試工具研發」的項目合作,5月23日,於BEYOND國際科技創新博覽會(BEYOND EXPO)澳門電訊展館舉行雙方延續戰略合作簽署協議,為助力澳門14產業多元發展注入新活力! 簽署有關戰略合作協議 澳門大學副校長(研究)葛偉教授和澳門電訊行政總裁潘福禧共同見證下,澳門大學科技學院院長須成忠教授與澳門電訊商務副總裁湛寶儀簽署了有關戰略合作協議! 澳門電訊商務副總裁湛寶儀:「澳門大學卓越的科研團隊和師生,是澳門電訊在推動智慧城市領域研究成果轉化的重要伙伴,其中『旅遊大數據算法研發』項目的成果,更成為了支持澳門智慧旅遊發展的重要部分,未來,澳門電訊繼續就5.5G、AI、大數據、智慧物聯網應用等領域,與澳門大學展開更深入的合作,期待為澳門打造更多智慧應用場景。」 澳門大學科技學院院長須成忠教授:「澳門大學與澳門電訊的強強合作,相信能對澳門的通訊發展,起到更大的推動作用,這次的續約,也是雙方對前期工作的認可和肯定,雙方的後續合作,特別是在產學研方向的合作,有望推動上更高更大的台階。」 雙方進行了產學研項目交付儀式 交付項目 「旅遊大數據算法研發」項目 將助力澳門電訊大數據服務應用,進一步精準地分析及挖掘景點與旅客之間的關係,擴展數據的可用性及支持轉化更多應用場景。 「自動化客戶體驗測試工具研發」項目 將加快澳門電訊推動實現智能化工作流程,提高工作效率及測試準確性、擴大測試覆蓋範圍等,更好地了解客戶的服務使用體驗。 澳門大學代表參觀展館 在澳門電訊介紹下,參觀了展館中圍繞助力推動文化旅遊、大健康產業、AI大數據潛力和應用、最新網絡安全技術與多網融合、新一代極速網絡等方面的「數碼澳門3.0」網絡基建及智慧應用。

Spring Boot 04 - 進入http json api 世代
科技新知
MacauYeah・2024-05-23

本節,我們將會建立一個http服務,提供json api讓程式訪問。 下戴模版 我們跟上節一樣,使用Spring Initializr Maven 下載模版,但細節筆者就不再講啦。Dependency主要選擇 Spring Web Spring Boot DevTools 下載後,可以直接運行測試,可以用指令 mvn test 或經IDE運行。Spring會至少測試下能不能成功取用預設的8080端口。 Controller 我們若要實作 http json api,需要在 spring 中加入一個類,附註為 @RestController ,那方便起見,類名我們也命名為 XXXController 吧。作為示範,我們弄一個 HomeController.java ,裏面有最常見的 http GET, POST功能。 srcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapibasiccontrollerHomeController.java import org.springframework.web.bind.annotation.RestController; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; ... other import @RestController @RequestMappingquot;apiquot; public class HomeController @GetMappingquot;someRecorduuidquot; public Map readSomeRecord@PathVariable String uuid return Map.ofquot;retquot;, quot;your uuidquot; uuid; @PostMappingquot;someRecordquot; public Map createSomeRecord@RequestBody Map requestBody HashMap ret = new HashMaprequestBody; ret.putquot;retquot;, quot;got your requestquot;; return ret; HomeController裏,完整的URL 其實為 GET httplocalhost8080apisomeRecorduuid POST httplocalhost8080apisomeRecord URL中的api之後的路徑,都是定義在 HomeController 中,而前半的8080及context path,是使用預設值。在正式環境下,可能隨時會被重新定義。但我們做本地測試,只需要驗證預設值就可以了。 我們真的運行起程式mvn clean compile springbootrun,再使用最簡測試工具進行測試。Windows的朋友,可以選擇Postman作為測試,它有圖形介面。而linux的朋友,請用curl,預設安裝都會有。下列為方便表示測試參數,筆者選用curl。 測試GET,其中1234會自動對應到spring裏的uuid。 curl httplocalhost8080apisomeRecord1234 # return quot;retquot;quot;your uuid1234quot; 測試 POST,其中的 d 參數,會對應 spring裏的 @RequestBody, H 參數則是設定 http header 的意思,我們就使用約定俗成的 json 作為 header 。 curl X POST httplocalhost8080apisomeRecord H quot;ContentType applicationjsonquot; d 'quot;requstquot;quot;did you get itquot;' # return quot;requstquot;quot;did you get itquot;,quot;retquot;quot;got your requestquot; 上面的兩個操作,都回傳了我們輸入的資訊,這代表了我們成功用spring架起了http json api,而且正常讀入資訊。 Test Case 雖然我們可以正常地架起 api,但每次開發都要 postman curl這種工具額外試一次,其實也有一些成本。而且 api 數量變大,或經多次修改後,就重複人手執行,就變得相當討厭。 面對這個問題,筆者會建議寫測試用例,即是Test Case,而且用Spring內置的@SpringBootTest來寫。 產生一個空的Test類,vscode中,最簡單可以Source Action =gt; Generate Test,然後加入這次要測試的參數。 srctestjavaiogithubmacauyeahspringboottutorialspringbootwebapibasiccontrollerHomeControllerTest.java import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.http.MediaType; import org.springframework.test.web.servlet.MockMvc; import org.springframework.test.web.servlet.RequestBuilder; import org.springframework.test.web.servlet.request.MockMvcRequestBuilders; import org.springframework.test.web.servlet.result.MockMvcResultHandlers; import org.springframework.test.web.servlet.result.MockMvcResultMatchers; @SpringBootTest @AutoConfigureMockMvc public class HomeControllerTest @Autowired private MockMvc mockMvc; @Test void testGetSomeRecord throws Exception RequestBuilder requestBuilder = MockMvcRequestBuilders.getquot;apisomeRecord1234quot; .contentTypeMediaType.APPLICATION_JSON; this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.jsonPathquot;$.retquot;.valuequot;your uuid1234quot; .andDoMockMvcResultHandlers.print; @Test void testPostSomeRecord throws Exception String request = quot;quot;quot; quot;requstquot;quot;did you get itquot; quot;quot;quot;; RequestBuilder requestBuilder = MockMvcRequestBuilders.postquot;apisomeRecordquot; .contentTypeMediaType.APPLICATION_JSON .contentrequest; this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.jsonPathquot;$.requstquot;.valuequot;did you get itquot; .andExpectMockMvcResultMatchers.jsonPathquot;$.retquot;.valuequot;got your requestquot; .andDoMockMvcResultHandlers.print; 最後就是執行 mvn test 或經IDE運行,應該都會得到所有測試都通過的結果。 mvn test # other test result ... INFO Tests run 2, Failures 0, Errors 0, Skipped 0, Time elapsed 0.368 s in io.github.macauyeah.springboot.tutorial.springbootwebapibasic.controller.HomeControllerTest # other test result ... 上面的程式碼很多,我們逐一來。 @SpringBootTest 寫在類的外面,代表執行這個測試類時,需要運行起整個Spring程序,當然也包括http的部份。 @AutoConfigureMockMvc 寫在類的外面,代表執行這個測試類時,可以模擬一些發向自己的 http 請求。 @Autowired private MockMvc mockMvc 寫在類的裏面,因為之前有定義了可以模擬 http 的請求,Spring在運行時為大家提供了那個所謂的模擬http client的實例。 MockMvcRequestBuilders,則是建造要測試的URL及Header參數。 MockMvcResultMatchers,則是檢查回傳的結果是否如遇期的一樣。 為何這個http client叫模擬 Mock 因為在測試用例中,可能連Controller 內部依賴組件也需要進一步模擬,這樣才能把測試目標集中在Controller裏,這也是單元測試的原意。只是本次的例子看不出模擬與否的差別。 MockMvcResultMatchers.jsonPath,這是用來檢測json的結構是否跟預期一樣。有些網路上的其他例子會簡寫成 jsonPath ,但因為vscode IDE的自動import功能比較差,筆者還是保留傳統的寫法。 如果大家覺得@SpringBootTest很難,想折衷地把其他測試方法,那麼把 postman curl好好管理起來,每次修改完程式,都完整地執行一次 postman curl ,也可以達到測試的效果。只不過大家還是要好好學會整合 postman curl,知道如何檢測json結構,什麼時候有錯,什麼時候叫測試通過,所以也要花一樣功夫來實現。 最後,大家千萬不要因為測試難寫而逃課,因為寫測試絕對地可以減輕日後重執行的工作量。除非你的程式碼即用即棄,否則都建議寫測試。測試跟寫文檔不一樣,有了測試也不能沒有文檔。好消息的是,文檔現在越來越多自動生成的工具,我們日後再找機會介紹。 Source Code spring boot web api basic

Ubuntu 24.04 試用報告-更新
科技新知
MacauYeah・2024-05-21

上期為大家介紹了一些ubuntu docker, multipass的一些改動。本期再繼續介紹一些其他的更新。 apt中的source.list 的位置更新了,格式也更新了,從etcaptsources.list在指向了etcaptsources.list.dubuntu.sources,格式變得更親民,就像如下所示 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites noble nobleupdates noblebackports Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg Types deb URIs httpsecurity.ubuntu.comubuntu Suites noblesecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg 承上更新,雖然格式好看了,noblesecurity的部份卻故意折開了。而且在livecd初次安裝時,大家若要改mirror鏡像站點,只能修改noble nobleupdates noblebackports的位置,noblesecurity還是會指定在官方的位置。筆者猜測它的用意是針對安全性更新,大家應該要直接訪問官方網站,不要等mirror慢慢更新。此一更新,不單影響ubuntu 24.04,連ubuntu 22.04也受一併折開了,只是22.04還是使用舊版。如果有需要變回統一的方向,減少日後自動化的修改,可以像以下修改 ubuntu 24.04的修改 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites noble nobleupdates noblebackports noblesecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg ubuntu 22.04.04的修改,刪除etcaptsources.list,新增etcaptsources.list.dubuntu.sources 對齊ubuntu24的位置 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites jammy jammyupdates jammy backports jammysecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg

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

Spring Boot 03 - 做好Database的模組化及測試用例
科技新知
MacauYeah・2024-04-12

這節,我們將會使用springdatajpa,寫一個業務上的資料庫模組,提供資料表的存取,讓你的好同僚可以直接使用。這樣可以在多模組的環境中,減少同一個資料表在不同地方重複又重複地重定義。將來要更新,也可以使用jar檔的方式發佈。 下戴模版 我們跟上節一樣,使用Spring Initializr Maven 下載模版,但細節筆者就不再講啦。Dependency主要選擇 H2 Database Spring Data JPA 對pom.xml作一些微調,並把springbootstartdatajpa,h2改為只在測試中生效。 並把Java檔案搬一搬位置 # old location srcmainjavaiogithubmacauyeahspringboottutorialspringbootdatatestSpringBootDataTestApplication.java srcmainresourcesapplication.properties # new location srctestjavaiogithubmacauyeahspringboottutorialspringbootdatatestSpringBootDataTestApplication.java srctestresourcesapplication.properties 以上的操作,主要是因為我們的目標是提供Schema,或者叫資料表規格。其他用於做連線的操作,我們不需要打包在jar內。所以把那些次要的東西都放在test資料夾中。我們這時可以先用mvn test指令,確保一切功能還是正常。 Entity folder 然後我們入正題,在pom.xml中加入hibernatecore,springdatajpa, 然後在main資料夾下加入 Entity、Repository,例如前述用過的Apple和AppleRepo,最後資料夾就像是這樣。 . pom.xml src main ` java ` io ` github ` macauyeah ` springboot ` tutorial ` springbootdatatest Apple.java ` AppleRepo.java ` test java ` io ` github ` macauyeah ` springboot ` tutorial ` springbootdatatest SpringBootDataTestApplication.java ` SpringBootDataTestApplicationTests.java ` resources ` application.properties 然後我們在Test Case中使用AppleRepo @SpringBootTest class SpringBootDataTestApplicationTests @Autowired AppleRepo appleRepo; @Test void contextLoads Apple apple = new Apple; apple.setUuidUUID.randomUUID.toString; apple.setWeight100.0; apple.setGravity1000.0; appleRepo.saveapple; 這個跟前述02springdatajpa最大的差別,就是我們的main中只有Entity相關的Class,我們發佈jar,別人引用我們的class,別人不會解發其他不相干的商業邏輯。假如發佈02的例子,因為Spring有自動初始化Component的原因,很可能會誤觸發02中的BasicApplicationRunner.java Source Code spring boot data test

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

Git: 何謂MONO Repository
科技新知
MacauYeah・2024-04-02

之前看了一位git大神的演講,提及一個叫MONO Repository的使用情況。後期找資料之後,才發現到這是一個公司成長後的一個重大的挑戰。 何謂MONO Repository git的傳統,就是為每一個獨立的專案,建立一個新的Repository 中譯:倉庫。這個很直觀,獨立專案,獨立管理。從零開始有很多好處,Repo體積通常會小一點,因為其內的東西都是緊密相關。做更新處理時,維護人員也更清楚自己的影響程度。這種架構方式,就叫Multi Repository。基本上,大家預設也是會走這個模式。 但當公司規模一直變大,多個專案可能不再獨立,各個專案或多或少都有一些關聯性。當任一專案更新,都有機會影響到其他人。如果公司使用Micro Service (微服務),就更有機會提早遇到。每次更新時,要跨專案地找出影響範圍原本就已經不容易,現在每個專案獨立地存放在不同的倉庫中,每個倉庫的更新速度不一樣,想要找到合適的地方、合適的時間點推出更新,更是困難。 所以,就有公司就提出,將所有專案都放在同一個Mono Repository中,方便用工具去檢查更新影響。相比Multi Repository,這樣做還可以保證同一個改動可以發生中同一個Commit中,可以讓跨專案的團隊可以即時合作(強逼修改別人的專案)。但這樣使一定會有很技術問題出現。跨專案團隊不可能每個專案都熟悉,因為不熟悉而引起的副作用一定會有,所以Main Master分支出現有缺陷的機會提高了。亦有人提出,使用Mono架構,還必要使用trunk base分支模式。也就是那些新功能,雖然要創建分支開發,但亦要盡早整合到Main Master中。這才能讓不同的團隊盡早知道問題,並解決問題。 除了開發模式更具挑戰外,Mono架構對git的效能也有很大影響。因為多專案混合,Repository的大小基本都會很大。每個git指令都會變慢,所以必需做一些週期性的cache,讓git graph, git status這樣日常操作變得暢順。同樣地,持續整合發佈需要作出調整。不過這些筆者就不在這邊詳述了,有興趣朋友可以到git 大神的Youtube觀看。 So You Think You Know Git FOSDEM 2024 註:據筆者的資料搜集,很多大公司(Software龍頭)都有使用Mono Repository去做集中管理。只不過筆者不知道如何Fact check,就不在這裏提了。

Docker環境參數化 - Arg VS Env
科技新知
MacauYeah・2024-03-26

Docker Variable control 我們在Docker Image的打包時,最簡單當然就是每個步驟都使用最新版本。例如Docker Base Image,大家可能選用latest tag,安裝linux package (Linux包),也可能就apt install yum 安裝最新的穩定版本。但如果我們想要更好地做測試,就要使用指定版本,方便追蹤問題。而Docker在打包和運行時,都有不同的方式讓大家定義或覆寫指定參數。 Docker build arg 我們先從打包Image開始。 例如我們需要使用一個Base image為 ubuntu,版本預設為22.04,但有需要時可以經build指令覆寫,可以這樣寫 ARG ubuntu_version=22.04 FROM ubuntu$ubuntu_version # default ubuntu_version=22.04 docker image build t test2204 . # or overwrite by buildarg docker image build t test2404 buildarg=quot;ubuntu_version=24.04quot; 雖然Dockerfile的RUN指令都是使用linux shell,但在Dockerfile中想表達條件控制(if else statment)就不太易看。在外部加入script做控制,是另一個可行的後備選擇,它更可以連image名字也進行參數化。 # in bash script, you also can if $beta == true then ubuntu_version=24.04 else ubuntu_version=22.04 fi docker image build t test$ubuntu_version buildarg ubuntu_version=$ubuntu_version Docker Container Run and Docker Compose 一般來講,Linux Container 在執行時,就等於進入Linux Shell。也就是,我們可以使用Shell中的環境變數。 我們在打包Image前,已經可以在Dockerfile中定義自己的ENV數參(也就是環境變數)。與前面的Build Arg有所不同的是,ENV是定義在Dockerfile中,在Container運行時以環境變數的形式存在,它也可以在運行中被改變。而Arg,則只在打包Image時存在,運行期間就不存在了。(當然,你在打包時,用Arg傳入Env,以運到這個目的。) 另一個更特別的性質是,那怕ENV沒有定義在Dockerfile中,我們運行時也可以加入更多的環境變數,大家就當成是一般Linux操作,隨時在自己的shell中加入變數。 # e, env for inline variable # envfile for file docker container run e MYVAR1 env MYVAR2=foo envfile .env.list ubuntu bash 同樣地Docker compose,也支援環境變數。筆者建議environment可以使用Array格式,日後可以更方便地直接改為env_file。 # dockercompose.yaml services ubuntu image ubuntu22.04 environment RACK_ENV=development SHOW=true USER_INPUT 上述的寫法沒有任何問題,不過如果你的dockercompose.yaml是放在git等版本控制中,你更新環境變數就有可能會影響到其他人,這時你就會想轉成env_file。 dockercompose.yaml預設就會讀當前資料夾的.env,就算不存在,也可以正常運行。(當然,大家的ImageContainer應該要有預設值) # dockercompose.yaml services ubuntu image ubuntu22.04 # if env_file is not defined, it will load .env. # or you can load the specific file. # env_file # .a.env env_file內,每一行就是一個變數 # .env or a.env RACK_ENV=development SHOW=true USER_INPUT 使用預設的.env還有一個好處,就是我們可以把dockercompose.yaml也變成受環境變數控制。 # dockercompose.yaml with variable control, only works in default .env services ubuntu image ubuntu$ubuntu_version # .env ubuntu_version=22.04