潮流特區

焦點文章

「心寒影滙2」大人細路齊齊玩盡Halloween!
創意生活
Cheers!・2025-10-08

2025嘅萬聖節,澳門新濠影滙為您準備好「驚嚇」同「歡樂」雙重體驗~膽大王必挑戰嘅「心寒片場」可以一站式體驗以七大電影為主題的解謎鬼屋,沉浸式感受被鬼嚇住動腦!一家大細都啱玩嘅「玩『懼』萬聖節」Toy Story 主題攤位遊戲、面部彩繪、免費爆谷同「Trick or Treat」等緊您! 9月19日至11月2日,無論您係膽大王定係家庭樂,總有一樣啱您玩! 門票現已發售,立即預訂:httpss.ctm.netjpvOc 心寒片場 Creepy Studio |解謎鬼屋等您體驗 平時睇鬼片就多,親身被鬼追您又試過未?今個萬聖節,新濠影滙「心寒片場」解謎鬼屋強勢回歸!七大恐怖電影主題輪住嚇您 mdash;《娃鬼回魂》、《鬼新娘迎親》、《邪靈娃娃》hellip;hellip; 一邊解謎一邊逃出,包您嚇到尖叫唔停口! 日期:2025年9月19日至11月2日(逢星期五至日)時段: 下午 1500 1900(最後入場 1830) 晚上 1900 2300(最後入場 2230) 地點:澳門新濠影滙一樓(巨星酒廊對面) 膽大王想獨闖「心寒片場」?標準門票MOP $144即刻出發,新濠會員更可享9折優惠!如果自問「膽細細又驚又要玩」,不如拉埋班FD一齊挑戰四人行套票,MOP 444(原價MOP $576)平均每人只需MOP $111,抵玩又刺激~ 專程從香港過來玩?咁就一定要訂「港澳船票套票」啦!MOP $404即包「心寒片場」門票1張同香港澳門來回船票1套(「香港澳門」船票僅限於門票當天或提前一日使用;「澳門香港」需於門票當日計算七日內來使用。),原價成MOP $584,而家慳咗成百幾蚊真係超值! 玩完驚到餓?我哋幫您諗埋~「心寒片場」星滙自助午餐套票 MOP $404(原價MOP $538),包「心寒片場」門票同自助午餐1位 僅限門票當日或翌日使用 ;或者選擇「嘉宴」餐飲禮券套票 MOP 404(原價MOP $544),包「心寒片場」門票同MOP $400餐飲禮券,等您可以盡情補充能量!僅限活動期間使用 無論獨闖、組隊、定係遠道而來,總有一套啱您玩!立即預訂:httpss.ctm.netjpvOc 玩「懼」萬聖節|一家大細放心玩~遊戲攤位面部彩繪免費爆谷! 萬聖節小朋友Cos得咁得意,點可以唔帶佢哋出嚟威?今個萬聖節就去「澳門新濠影滙一樓時代廣場」!場內設有多個《反斗奇兵》主題攤位遊戲,MOP$20換一個遊戲代幣,挑戰成功即有機會贏得Toy Story獨家禮品,大人細路都玩得開心! 新濠會員尊享優惠: MOP $200 換10個遊戲代幣,免費送「反斗奇兵三眼仔糖果桶」,小朋友可以拎住去Trick or Treat啦! 面部彩繪體驗:用2個遊戲代幣,即可為小朋友畫超應節嘅萬聖節彩繪,可愛定恐怖任您揀! 免費爆谷派發:喺時代廣場(DFS 附近)仲有免費派發爆谷,首200名客人更可獲《反斗奇兵》主題爆谷,送完即止! 遊戲攤位開放時間:2025年9月19日至11月2日(逢星期五至日) 時間:1300 2100 面部彩繪體驗 amp; 爆谷派發時間:1300 ndash; 1800 地點:澳門新濠影滙1樓時代廣場 Trick or Treat?|糖果大放送! 小朋友最愛環節嚟啦!9月19日至11月2日期間(每日都有!),只要喺新濠影滙精選商戶門口大叫「Trick or Treat」,即可免費拎糖!實現糖果大豐收~ 萬聖節點止有得玩?新濠影滙「搞怪美食」驚喜登場! 玩到肚餓?唔使驚!新濠影滙四間餐廳齊推萬聖節主題限定套餐,搞怪得黎又好味,絕對係視覺與味覺嘅雙重享受~ 載運美式餐室嘅木乃伊開心套餐 骷髏骨頭開心套餐 惡魔魅影開心套餐,隨餐仲送萬聖節公仔掛飾,即時補充您係鬼屋尖叫流失嘅能量! 甜品控必衝羅浮餅廊及輕食嘅造型蛋糕, 小編最期待嘅就係「骷髏朱古力紅桑子蛋糕」同「紅桑子十字架丹麥 」,造型驚悚但味道驚喜,保證您相機食先! 想同朋友Chill 住打卡? 巨星酒廊萬聖節Tea Set絕對唔輸蝕 mdash; 「怪獸之眼」、「吸血南瓜」、「木乃伊手指」、「女巫紅寶石」hellip; hellip;hellip;款款精緻得嚟帶點詭異,包您一邊驚一邊笑! 最後當然唔少得星滙餐廳自助餐,多款萬聖主題美食任您放題,仲有一系列可愛到「嚇死人」嘅甜品,等您視覺同味覺同時被攻擊! 驚聲睇好戲|萬聖節電影優惠 喺鬼屋尖叫完,點可以唔睇返場戲壓壓驚?活動期間憑當日「心寒片場」門票,或者著住萬聖節服飾,去「影滙戲院」買飛即享: 第二張戲飛只要 MOP 60元! (即場出示當日「心寒片場」門票或穿著萬聖節主題服飾即享優惠) 一邊食爆谷一邊睇戲,萬聖節之旅完美收官~ 活動日期:2025年9月19日至11月2日地點:澳門新濠影滙戲院票務處 今個萬聖節唔使諗去邊,新濠影滙包大人同細路盡興而歸!記得約實朋友、帶埋一家大細嚟玩啦!

最新文章

為何Python這麼熱門?
科技新知
MacauYeah・2024-08-27

在資料處理、資料科學領域,什麼是最近的AI模型,Python都是做這些事的熱門選擇。對於以前從未用過Python來處理業務的筆者來講,實在不懂為何Python會那麼大熱。不過最近,筆者實戰過後,真心覺得它是提高生產力的重要工具,而且並不限於資料科學上面,一些簡單的腳本操作也是很有優勢的。 筆者前述有討論過 型別對程式語言的重要性,到現時這一刻,筆者都會覺得【型別】是有助於長期的程式開發。而Python這個語言,大部份人都會介紹它是動態語言,可以使用弱型別,然後,就沒有其他講法了。動態弱型別,筆者一直都不認為它的根本上的原因。就像Javascript一樣,它亦發展出類靜態強型別的Typescript版本,而且它亦不因此而被人棄用。所以Python的強大,動態語言並不一最重要的原因,它也可以模疑寫出有規有距的type hinting。 或者用另一個方向問,大家覺得 Excel SpreadSheet 好用嗎?它們可以很簡易地做出資料計算、篩選。而且可以一邊做,一邊調整公式。例如要大家做一個陣列的總和,大家會想打開一個Javascript,初始化陣列的每個數字,然後寫個For迴圈去計算總和嗎?還是打開 Excel SpreadSheet,打下一欄或一列的數字,然後叫出Sum函數?筆者一定會選擇後者,不單止因為寫函數比較方便,那怕之後要調整數字,也比較方便。 大家有感受到差異嗎?筆者想表達的是,在操作 Excel SpreadSheet 我們並不是整個程式重新執行一次,我們是修改完一部份,那上看到結果。但傳統的語言,例如C、Java、那怕是Javascript,我們都難以局部地更新或執行特定某一個區塊。那怕是現在我們有hot reload,但其實我們編寫的思維,都是讓我們完整執行起一個頁面,再人手輸入,看結果。如果我們只想運行某個單一Function函數,我們只能寫test case測試,但寫test case又是一個很大的入門門檻。 但大家如果看看Python,在古早的年代,Python已經有Python shell,那就像是Linux Shell或Window CMD一樣,可以一邊寫腳本,一邊看結果。寫了10行的程式,發現在第10行引用第5行的部份有問題,修正並執行第5行後,就可以回來馬上重跑第10行的語句,就馬上有結果了。第6至9行,因為沒有關聯性,就不需要逐一重新執行,那是多麼的方便阿。道理上,我們若沒有完整執行整個程式,可能還是有一些盲點,開發重要的,需要長期維護的程式,還是要像傳統一樣,有test case,有程式進入點,整個運行。但對於臨時性的操作,看看效果,我們實在無必要寫一個原整程式。 舉個例子,假如我們臨時有需要,要取得某個政府網站的即時數據,例如澳門的停車場資訊,空位的上下限是多少,我們絕對可以用python寫幾行就取得結果,然後順便做個資料運算。我們沒有必要很嚴僅地為考慮不同數據的出現情況,我們什至可以hard code 硬編碼地計算某個Array的元素。直到突然有一天,這個操作變得恆常化,我們還是有條件把之前的python程式碼,改寫成一個規規矩矩的完整腳本,包括異常處理,函數複用。其實Javascript在改用 NodeJs 作為引擎後,我們還是可以經過 Node.js REPL,來做互動操作,只是Python Shell出現得更早,也是官方支援的功能。 Python這個臨時操作的便利,對於資訊爆炸的年代來講,實在很幫得上忙。再加上現在除了Python Shell以前,還有Jupter Notebook,讓大家可以在Web頁面上,執行像Python Shell的互動操作,對於修過特定區域的程式碼,就更加方便。這些便利,都是不是因為動態語言來創造的優勢,而是實實在在的Coding Anywhere。

Github flow 沒有提及的發佈 - 佈署 | Release - Deployment
科技新知
MacauYeah・2024-08-23

不知道之前為大家介紹的github flow,大家覺得怎樣?好用嗎?今天,筆者又來講講筆者心中認為它沒有好好給出指引的地方。 我們的信心指數,其實沒有那麼高 在前文中,經過 pull request 、 code review 、 auto test ,道理上,開發者可以做的都已經做過了,然後就是等待發佈 Release。 對於單純的庫類型的程式碼,筆者認為,的確沒有事可以再做,實務上就是直接找人其他程多員試用最新版本,看看有沒有問題。只要 main master 上,明確的表示版本號的變更,就差不多等於直接發佈。有需要提供binary版本的,就還需要觸發上載binary的流程,但這個跟 pull request 觸發 auto test 差不多, auto test 成功後就上載。 對於服務類型的程式碼,例如 Web App 等,直接發佈到正式環境還是有些不妥吧?始終會即時影響到業務,我們至少有個測試場,經用戶做實際的業務操作去驗收。但這個時機,應該是在Github flow的什麼時候做? 在原始的git flow中,有一個叫做 develop 的相對穩定分支,僅次於 main 。它是功能開發完成後第一次pull request 的地方,我們可以用這個概念來做自動發佈到測試場。但若在github flow 中加入了這個 develop uat staging 分支,其實就等於複雜地回到過去傳統的 git flow中,對好多新手來講難以接受。Github flow 的成功簡化,其實很大依賴著自動化測試。現在的測試用例,並不再限於單元測試。就連整合測試,也可以經Docker等容器化技術去做,只要我們的自動化測試有足夠信心,就可以發佈。但反觀我們的 Web App 例子,我們認為自動化測試難似涵蓋所有情境,也難以開發。所以我們還在有個時間發佈到測試場,進行人工測試。 pull request 快速迭代 筆者結合自己的經驗,配上國外討論區 Stack overflow 的內容,筆者認為Github flow上進行 pull request 後,就是最好的發佈測試場時機。所以我們需要盡快進行驗收測試,完成後在Git commit上加上Tag,以示通過驗收測試,可以發佈正式環境的版本。 不過這個模式是有一個很重要的前題假設:快速迭代。當我們驗收完成後,盡可能快地發佈到正式環境,不然會阻礙下一個功能的pull request驗收,或是覆蓋了上一個pull request的驗收環境。 用反面的例子來說明,如果我們有很多功能需要驗收,或變化很多,或存在多輪的里程碑開發,我們就不適宜那上述模式。最保險的做法,還是回到傳統的 git flow ,引入 develop uat staging 分支。但如果大家還是那麼討厭傳統 git flow,筆者還是有另一個提議。 既不想回到傳統 git flow ,但又需要慬㥀的考慮驗收發佈流程 如果開發的功能變化比較大,需要多方面協調、測試、驗收,經歷多次里程碑後,才有一個對外發佈的版本,大家可以考慮分開 Repository 做開發。例如 v1,v2的 Repository 完全獨立。 v1 是已發佈的版本,有獨立的測試場,任何即時候需要修正,就在v1的 Repository 做 pull request。 v2 則是未發佈版本,亦有獨立的測試場。加入任何新功能後,就在v2的 Repository 做 pull request,用自己專用的測試場做驗收。到 v2 正式發佈後, v1 就封存處理,再開一個 v3 作為下一個大版本的開發。這個模式,那怕在庫類型的程式碼也用得上。 這樣做的好處是 git Repository 和歷史記錄都會獨立,自動發佈的腳本程也會簡單明確一些。壞處則是 v1 v2 難以做功能對比,我們只能靠人腦記著 v1 有沒有什麼後期加入的修正和功能,需要同步移植到 v2 中 相對的,著是同一個Repository,可以利用merge 功能確保 v1 有的,v2 都己處理,只是必需要很懂處理版本衝突問題。

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

在預設Docker和K8s的容器主導世界裏面,其實一直都缺少了直觀的儲存空間。當你的程序需要讀寫故定的來源資料,該來源就必需是外部的穩定儲存空間,例如是資料庫、NFS。但資料庫、NFS等,要做到真的正穩定,其實就要走Cluster叢集模式,確保它們自己本身不是做成single point of failure 單點故障的元兇。 坊間,只要付得起錢,其實找個穩定的資料庫或NFS,也是有的。但如果你像筆者一樣,只有一塊或多塊【鐵】,就要試試開源的儲存引擎Ceph Storage。 Ceph Storage,有自己特有的CephFS格式,但也支援NFS httpsdocs.ceph.comenquincycephadminstall。也就是,只要我們有足夠多人力,道理上可以自己用實體機去模擬一個穩定的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】httpsdocs.ceph.comenreefcephadminstall#addinghosts 節章可能有些誤導,大家應該要看 【Host Management】中的【Adding Hosts】 httpsdocs.ceph.comenreefcephadmhostmanagement#cephadmaddinghosts 在每個節點內,可以直觀地連接地Ceph Dashboard,但若大家需要Port Forword,要注意你的Network Interface,筆者就只能經過預設的IPv4的public ip 進行ssh port forward,不能經過0.0.0.0。 Script 位置 httpsgithub.commacauyeahubuntuPackerImageblobmaininitCephCluster.sh

Spring Data 關聯型態 02
科技新知
MacauYeah・2024-08-09

Presist and Casecade 前次的文章,講了一些Spring Data最基本的關聯概念,但當要正式儲存或刪除,就有些考慮完整性問題。平常我們在處理資料庫的關聯表格時,也需要面Foreign Key的正確性問題。同樣地,Spring Data也有這方面的考量,但它有提份一個很方便的CascadeType選項,可以簡化一些流程。 假設你只能存取Parent Repo,那你需要在Parent中,加入CascadeType.All。當repo.saveparent時,它就會順多把所有child的也一併進行Save,你也不需要有Child Repo的存在。 @OneToManymappedBy=quot;parentquot;, cascade = CascadeType.All List children = new ArrayList; 但在複雜的狀況下,例如你不想在更新parent的情況下,不小心弄到child,特別是經過public web下的API操作,你對web client的資料正確性有存疑,就不要使用CascadeType了。這也是筆者認為在大多數情況下,我們都會把Parent和Child的CRUD分開操作,然後根據需要使用各自的repo save。 如果你一定要用CascadeType.ALL CascadeType.REMOVE,就要再留意刪除的問題。為什麼?因為刪除 parent,其實指的是某個parent不再存在,但不代表child也要一起刪除,child的parent連結可以變為null,也有重新連結其他parent的可能。 如果大家確定需要共同刪除,就可以用CascadeType.ALL 或 CascadeType.REMOVE。 還有一個新的選擇,orphanRemoval = true,也有類似效果。 @OneToManymappedBy=quot;parentquot;, cascade = CascadeType.REMOVE List children = new ArrayList; or @OneToManymappedBy=quot;parentquot;, orphanRemoval = true List children = new ArrayList; or @OneToManymappedBy=quot;parentquot;, cascade = CascadeType.REMOVE, orphanRemoval = true List children = new ArrayList; 筆者測試過,混著用也是可以的。若大家看過其他教程,可能會覺得orphanRemoval = true 和 CascadeType 總是一起出現,但它們其實是分別操作的。單獨使用orphanRemoval = true,有時候則是為了不會出現無主的child,但這不代表parent和child的想要同步更新。 JPA Entity 的生命週期 Spring Data跟傳統的資料庫Selete,Create,Update,Delete SQL 語句有所不同。也就是這個不同,它的CascadeType比資料庫的Cascade Update和Cascade Delete更強大。 Spring Data 預設其實是使用 jakarta.persistence.EntityManager,每個Entity主要分為四個狀態 Transient New 不在EntityManager的掌控中 Managed 在EntityManager的掌控中,將會在下次flush時,變成sql create或update statement Detached 脫離EntityManager的掌控,不受flush影響 Removed 在EntityManager的掌控中,將會在下次flush時,變成sql delete statement 在Spring Data Jpa 以前,我們若要直接操作Hibernate,經常見到persist, remove的寫法 entityManager.persistentity; entityManager.removeentity; entityManager.detachentity; entityManager.mergeentity; 其實persist就是把處於Transient、Removed的entity,改為Managed。而remove就是把Managed改為Removed。detach,merge也類似,就是Managed,Detached之間互換。 EntityManager最強大的是,它可以讓程序員不需要再為Managed狀態下的entity操心,它會自動判別下次flush,應該create還是update,如果完全沒有改動的,連update也不會執行。 註,flush和commit也有不同,flush就是從java寫到資料庫中,在資料庫commit前,還可以使用rollback放棄。 而Spring Data,則是進一步簡化,它把persist改為save,remove改為delete,然後自動選擇flush的時機。 CascadeType 在解釋完Entity 的生命週期後,終於可以回到CascadeType了。這裏的CascadeType不是資料庫的Cascade操作,其實它是指EntityManager的狀態操作是否有傳遞關係。亦即是,persistparent時,要不要連同child也一起操作 我們查看 CasecadeType 的原始碼,就可以發現可以被傳遞的操作共有以下這些 PERSIST MERGE REMOVE REFRESH DETACH ALL 以上全部 這裏的 CasecadeType.PERSIST ,跟資料庫的 Cascade Update 是不一樣的。資料庫裏的 Cascade Update,是指當 Parent 的 Primary Key 有變,對應child的 Foreign Key也一起變。但因為 JPA Entity 的機制, Parent 的 Primary Key 不可以改變,理論上不會發生類似資料庫的 Cascade Update,頂多有 Cascade Delete。 CasecadeType.PERSIST 就像之前述的生命週期解說一樣, 把 parent和 child 一起拉到受管理的狀態。 註 CascadeType.REMOVE有點尷尬,似乎有更特別的使用規範。筆者測試過,在某些情況下,CascadeType.REMOVE無法處理ForeignKey問題,又或者是,刪除的順序不對。詳見 spring boot data deletion Reference entitylifecyclemodel spring boot data deletion

Spring Boot 06 - Spring Boot Web 調試工具
科技新知
MacauYeah・2024-08-02

之前兩節,都一直在講怎樣寫code,也介紹了Test Case的好。若為初次接觸,Spring有很多設定需要摸索,若開始時就設定錯誤,對不少人來講都會有很大打擊。在這裏,筆者就介紹一些vscode和spring的工具,可以讓IDE多幫忙一下,減少走歪路的機會。 vscode插件 以下兩個插件,都在於提示用戶設定。 Spring Boot Dashboard vscjava.vscodespringbootdashboard 可以那它來運作spring boot app,省去找尋main 位置的麻煩 綜覽整個程式中的所有Bean Bean是一個很重要的元素,日後會再提及 若程式為Spring boot web,可以顯示所 http endpoint。 Spring Boot Tools vmware.vscodespringboot 檢查設定檔的設定值有沒有寫錯 (application.properties, application.yml) 綜覽檔案中的有以@為首的與spring相關的元素(檔案很大時就會有用) 可以在IDE運行spring時,查看@元素的bean資訊 not works , 加了actuator也是沒有看見 Spring Initializr(vscjava.vscodespringinitializr) 經網絡初始化spring 專案的依賴引用設定 Maven for Java vscjava.vscodemaven 若大家在使用Spring Initializr時,選取了maven作管理工具,那麼這插件就可以在後續幫忙更新引用。 若專案的Spring 及㡳層引用有變,vscode也需要它來引用更新。 這是java 開發工具包vscjava的其中一員,它的其他插件也可以順帶安裝。 調試工具 open api swaggerui 如果我們在開發Web http API ,其實都是為了該某個客戶端使用。但如果該客端明白我們的API該怎樣使用,大家總不會逐個連結,自行編寫使用手冊及範例吧。所以就有了open api 和 swaggerui 的旦生 。 open api,就是一個公認的使用手冊標準,我們只要在springweb中加入 springdocopenapistarterwebmvcui 的程式庫,就可以自動為我們的controller 生成 open api 的說明檔。 更強大的是,這個程式庫可以利用剛生成的open api,配上 swaggerui ,自動測生一個可供測試的頁面。這個頁面可以供碼農們直接操作,也會產生對應的 curl 指令,讓碼農們可以在任何的主機上重複。這樣,那麼是沒有太多解釋的說明文檔也可以使用。 做法很簡單,在pom.xml中加入依賴。 org.springdoc springdocopenapistarterwebmvcui 2.5.0 由於安全性問題,上述程式碼未能完整顯示,請參見文末完成Source Code 然後我們就可以加入Controller,運行 spring 後,我們可以在 httplocalhost8080swaggeruiindex.html 找到 swagger 的頁面,然後就可以在 ui 上測試API了。 躲在Proxy背後的 swagger 如果你跟筆者一樣,使用 codeserver 或 github codespaces ,你就不能很隨意地連接到 8080 端口。你只能經過Http Proxy去訪問。這樣 open api的原有的設定就不合用了。 這時我們需要自行修改 open api 的 bean,加入我們真正的根路徑。然後筆者使用 codeserver,而IDE只會在port 9000上執行,它對外的前置路徑會是 httplocalhost9000proxy8080。 @Bean public OpenAPI springShopOpenAPI Server server = new Server; server.setUrlquot;httplocalhost9000proxy8080quot;; return new OpenAPI.serversList.ofserver; 由於安全性問題,上述程式碼未能完整顯示,請參見文末完成Source Code 然後訪問 httplocalhost9000proxy8080swaggeruiindex.html,還會發現 quot;Failed to load remote configuration.quot; 。但你可以在 quot;explorequot; 搜尋欄位內貼上 httplocalhost9000proxy8080v3apidocs,再一次搜尋檔案,就回復正常了。 註:如果你熟習Nginx這類Reverse Proxy ,你的環境有條件直接修改 Request Header,加入XForwarded,就不用煩惱寫Bean了,也不用手動在explore裏重新修正apidocs的位置。詳見 httpsspringdoc.orgindex.html#howcanideployspringdocopenapistarterwebmvcuibehindareverseproxy Controller的繼承 Spring Controller的 @ 標記 Annotation ,其實支援繼承的。經Spring 生成的 api docs,也有如何效果。例如以下程式碼 public class ParentController @GetMappingquot;postfixquot; public String postfix return quot;this is postfixquot;; @RestController @RequestMappingquot;apiquot; public class ChildController extends ParentController @GetMappingquot;directquot; public String directCall return quot;direct resultquot;; 由於安全性問題,上述程式碼未能完整顯示,請參見文末完成Source Code 在ChildController的實例中,它會有兩個API,分別是 apidirect apiprefix 它支援Java Function Overwrite(覆寫),但不能改 @ 標記,以下就是一個錯的例子 @RestController @RequestMappingquot;apiquot; public class ChildController extends ParentController @GetMappingquot;Overwritequot; 把這個 @ 行刪了才能正常執行 public String postfix return quot;this is Overwritequot;; 由於安全性問題,上述程式碼未能完整顯示,請參見文末完成Source Code Source Code spring boot web api doc

Swarm mode 上線 4 | IP 設定
科技新知
MacauYeah・2024-07-23

單機模式 IP設定 平常我們自己做測試,網絡功能通常用預設的就好。但當我們的Docker Container需要存取在區域網內的其他資源,避晚IP網段相衝是必需要的事。 大部份情況下,單機Docker使用的預設IP段會是 172.17.0.016 172.18.0.016 ... 若然現在區域網中,有一段172.18.0.024,大家不想Docker踩到其中,可以修改設定檔,加入預設的defaultaddresspools,以後它就只會從指定的區段使用。 # vim etcdockerdaemon.json quot;defaultaddresspoolsquot; quot;basequot; quot;172.17.0.016quot;, quot;sizequot; 24 , quot;basequot; quot;172.19.0.016quot;, quot;sizequot; 24 , quot;basequot; quot;172.20.0.016quot;, quot;sizequot; 24 其中base,是docker可以操作的總區域,size指的是Docker要自行分段的話,每段的大小是多少,上述的例子,就代表未來可能有以下Docker 網段。 172.17.0.024 172.17.1.024 ... 172.17.255.024 172.19.0.024 172.19.1.024 ... 172.19.255.024 172.20.0.024 172.20.1.024 ... 172.20.255.024 修改完設定後,重啟Docker就會生效。當然,重啟前,先刪除所有不在預設範圍的所有Container。 Swarm模式 IP設定 Swarm模式,與單機差不多,它需要在初始化Swarm就要定義,而且它不能與單機的網段有重疊。單機會預設使用Private IPv4 Class B,Swarm則是預設使用Private IPv4 Class A段,所以我們若就更改,就使用10.x.x.x吧。 docker swarm init defaultaddrpool 10.1.0.016 defaultaddrpoolmasklength 24 經上述例子初始化的 ingress 網段,將會是 10.1.0.024,隨後每個stack 則會是 10.1.1.024 10.1.2.024 10.1.3.024 重置Swarm 跟單機的情況類似,如果已建立Swarm後才修改網段,還是要整個刪掉重來。 每個節點都要執行以下指令。 docker swarm leave force 實測swarm leave這個指令也會把所有運行中的stack刪掉。 各節點重新建立swarm # in node 1, init new swarm with new ip docker swarm init defaultaddrpool 10.1.0.016 defaultaddrpoolmasklength 24 # in node 1, get new manager token docker swarm jointoken manager # in node 2 and node 3, join node 1 with new token docker swarm join token XXXXX YOUR_NEW_NODE1_IP2377 雙管齊下 如果大家同想要修定單機及Swarm的網段,還要留意有一個特別的網段docker_gwbridge。它雖然是Swarm的附帶產物,但它則是受單機的網段控制。也就是,如果大家有需要同時修改單機及Swarm的網段,則需要手動刪除Swarm及docker_gwbridge 在每個節點先刪掉舊有的Swarm及docker_gwbridge,並關掉docker docker swarm leave force docker network rm docker_gwbridge 在每個節點為docker_gwbridge修改設定,然後重起docker # vim etcdockerdaemon.json quot;defaultaddresspoolsquot; quot;basequot; quot;172.17.0.016quot;, quot;sizequot; 24 然後像前述一樣,重起Swarm。

Spring Data 關聯型態 01
科技新知
MacauYeah・2024-07-16

筆者身邊的朋友,首次接觸 ORM 的關聯型態時都會覺得很難,筆者自己也是。但在好好地理順它的設計時,就會覺得其實很簡單。 因為篇輻很長,我們先以Code First的角度,先體驗一下ORM程式讀取的便捷性,以及解決一個常見的序列化問題。 雙向存取 例如一個Parent,有好幾個Child @Entity public class Parent ... Parent Primay Key @OneToManymappedBy=quot;parentquot; List children = new ArrayList; TODO add remove @Entity public class Child ... Child Primay Key @ManyToOne Parent parent; 上述的寫法很簡潔,ORM會為你自動加入join column,處理關聯的載入。在讀取Parent時,它的所有Children就可以直接在Java層面讀取,在讀取Child時,它的Parent也隨時取得。也就是,開發人員只要經SQL準備其中一方的資料,另一方並不需要手動準備,它就可以自動按需載入。 RESTFul API 坑雙向存取 Spring Data在Java層面的雙向存取,已經做到很方便。但經常坑到我們的是Spring Data與RESTFul API的混合應用。當我們嘗試經API回傳我們的Parent Json時,API會很聰明地把關聯的Children也變成Json回傳。但他也會把child中的parent不斷重複變成json,變成無限輪迴。 坊間有兩種不同的解決方案,可以防止無限輪迴。 讓Json可以認得已經序列化的元素。@JsonIdentityInfo 讓Json只可以單向序列化serialization。@JsonManagedReference, @JsonBackReference, @JsonIgnore 筆者兩個方向都試過,但首個方法並不通用,至少它不能算是一般常見的無腦Json結構。它需要伺服器、客戶端都懂這如何經IdentityInfo認得重複出現的元素。 而單向序列化,是筆者現時的通用解。在設計RESTFul READ API時,筆者就會決定到底是Parent自動回傳Child,還是Child自動回傳Parent。決策的考慮因素,主要在於是否可以簡化Client的API調用次數。通常從Parent出發,自動回傳Child,可以節省API調用。但如果是選項性的結果List of Value,就倒過來。有時候,遇著API需要雙向設計,就只好自己設計DTO資料傳輸對象 Data transfer object, DTO。 例如Parent API,就原封不動回傳原本的元素 @Entity public class Parent ... Parent Primay Key @OneToManymappedBy=quot;parentquot; List children = new ArrayList; @Entity public class Child ... Child Primay Key @ManyToOne @JsonIgnore Parent parent; Child API,就反過來引用。 public class ParentDTO ... Parent Other fields except children public class ChildDTO ParentDTO parent; ... Child Other fields 這種DTO,看起來很麻煩。但其實Spring有提供一個簡便的複制DTO功能,它可以把自動複制兩個class中有同一名稱、同一型別的欄位到另一個class上,不需要逐個欄位明文寫出來。 BeanUtils.copychild, childDTO; BeanUtils.copyparent, parentDTO; childDTO.setParentparentDTO 因為child、childDTO中的parent欄位型別不同,BeanUtils.copy會自動忽略,其他欄位就會自動複制。 註 其實古早的網頁系統設計,DTO的概念一直存取。只是現在RESTFul API的流行,很多框架已經提向便捷的Json轉換。若然平時只需Json單向存取,筆者還是省略DTO的建立。

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

之前筆者有分享過兩個不同的Docker Image打包方式 App直接打包成Image 只把底層程式打包在Image中例如Tomcat,再用Docker Volume的方式讓Container可以起動App。 筆者就兩種方式做了一個條列式的對比。詳見連結 httpsmacauyeah.github.ioAProgrammerPreparesVMDockerNotesDeployDockerClusterCN.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去提供。可以按自己步調去慢慢適應。

型別對程式語言的重要性
科技新知
MacauYeah・2024-07-08

JavaScript等程式語言的流行,好大一個原因是因為它很簡潔。而筆者認為,動態語言的特性,即是可以省略型別,是讓它簡潔的一個很大原因。動態、靜態與強型別、弱型別並一定對等,詳見Ref 動態語言的特性,就是同一個變數,在不同時候可能代表不同的數據類型,有時候是String,有時候是Integer。所以編寫時,乾脆就不寫數據類型,因為寫了也可能是白寫。 因此初學者並不需要處理大多導入import問題,也不用考慮很多compile error問題,至少程式可以運行一半,到了最後出錯的地方才停下,也就是不會因為型別問題而整個程式開不了。 不過筆者在接觸了JavaScript後,始終沒有大量使用。一來因為筆者慣用的Java,有著更大的基礎套件,改用JavaScript未必有優勢。而且動態語言還有一個長久的管理問題,我們該如何知道更新的影響有多大? 測試用例不是萬能藥 有一部份的人認為,動態語言管理難,是因為大家不愛寫測試用例。的確,若然大家寫的測試覆蓋率足夠多,一定可以預先發現問題。但筆者在Java上實踐了寫測試的習慣一段時間,依賴測試報錯,其實也是後知後覺。 IDE的界入 筆者認為,若想好好地管理程式碼,光寫測試是不夠的,我們還需要好好地讓IDE了解我們的程式碼,認它可以很有效地重構我們的程式碼。更強的IDE,還有機會可以提醒我們有一些設計上問題。 老實講,寫Java多的朋友,都可能都知道Intellij Ultimate的名字。筆者試用後,的確很有幫助。相較之下,vscode對於Java的支援,並不十分智能。但這裏筆者還覺得vscode對於java的編寫、重構、測試,在免費的情況下,都已經足夠是足夠佛心。對於網頁應用來講,vscode差的是對javascript的支援。 vscode對javascript的支援有限,其實不能怪它不夠努力。你想多一個免費的IDE怎樣去了解你的javascript程式? 我們連型別都沒有寫出來,它能怎樣推敲? 實時去模擬各種輸入?CPU又會不會耗乾?那麼寫到一半的程式碼又怎樣輸入? 直到最近筆者採用TypeScript之後,筆者看到曙光了 TypeScript 一個變相的JavaScript的靜態型別 原本的JavaScript其實也有型別的,只是不強制。若想IDE支援,需要以特定型式寫註解。但這樣寫註解,工作量並不比引用靜態型别來得輕鬆。所以最後,筆者還是覺得直接套用TypeScript,讓自己在每一次引用參數,都要好好地先了解函數的輸入輸出型別寫法。 說實在,從JavaScript到TypeScript並不輕鬆。一些原本很無腦的Axios, Promise, Vue語句,TypeScript寫起上來,都變得很複雜。但這個套用,對於IDE來講,真的很大幫忙。它就像突然讀懂了我們的程式一樣,可以跳入跳出,可以知道在多少處被引用。重構也變得更有信心,而不是等待事後測試報錯。 有一點要補充,TypeScript並不像Java那般需要完全預先宣告型別。例如函數的回傳結果,TypeScript就不會強制要求寫出型別,因為它可以有限度地猜得出來。當然,如果大家願意宣告,就更好。 總結 總括來講,型別就像厠所的衛生情況一樣。初期當然什麼都不處理也可以,但越用越久也沒有人理會,大家也不想用下去。若然大家都願意努力維持它的品質,大家會更有意願重複使用。 參考資訊 「靜態型別 vs. 動態型別」與「強型別 vs. 弱型別」 httpsblog.tarswork.compostprogramminglanguagetypesystem Typed JavaScript httpsdepthfirst.comarticles20211103typedjavascript

Spring Boot 05 - 為 http json api 加入登入要求
科技新知
MacauYeah・2024-07-02

本節,我們將為之前的http服務,加入認證機制,只有在資料庫現存的用戶可以登入及訪問我們的json api。 下戴模版 慣例,我們用Spring Initializr Maven 下載模版,Dependency主要選擇 Spring Web Spring Boot DevTools Spring Security Controller 跟上節一樣,我們起一個Controller,為簡化測試,我們只做http GET api。 由於本blog對於Source Code的顯示不太友好,有需要看source code的,請到Github查看 srcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapidatacontrollerHomeController.java import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMappingquot;apiquot; public class HomeController @GetMappingquot;someRecorduuidquot; public Map readSomeRecord@PathVariable String uuid return Map.ofquot;retquot;, quot;your uuidquot; uuid; 準備我們的test case,但這次我們預期它應該要出現登入失敗的結果。 srctestjavaiogithubmacauyeahspringboottutorialspringbootwebapidatacontrollerHomeControllerTest.java @SpringBootTest @AutoConfigureMockMvc public class HomeControllerTest @Autowired private MockMvc mockMvc; @Test void testNoLogin throws Exception RequestBuilder requestBuilder = MockMvcRequestBuilders.getquot;apisomeRecord1234quot; .contentTypeMediaType.APPLICATION_JSON; this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.status.is4xxClientError .andExpectMockMvcResultMatchers.jsonPathquot;$.retquot;.doesNotExist .andDoMockMvcResultHandlers.print; 在我們執行上述的測試,test case 成功過了。我們的基本設定跟上一節其實沒有多大改動,為何現在http api會回傳狀態 401? 那是因為我們在依賴中加了,Spring Security,它配合了Spring Web,就會自動為所有api加入權限檢測。我們的測試中,沒有任何用戶登入,當然會出現 http 401。為了讓我們可以好好管理誰可以使用api,我們就來設定一定Security。 我們加一個WebSecurityConfig.java,暫時指定所有的訪問路徑都必需有USER權限,並且用 http basic的方式登入。 srcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapidataconfigWebSecurityConfig.java import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.security.config.Customizer; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.web.SecurityFilterChain; @Configuration @EnableWebSecurity public class WebSecurityConfig @Bean SecurityFilterChain securityFilterChainHttpSecurity http throws Exception http.authorizeHttpRequestsauthorizeHttpRequests gt; authorizeHttpRequests.requestMatchersquot;quot;.hasRolequot;USERquot;; 所有的訪問路徑都必需有USER權限 ; http.httpBasicCustomizer.withDefaults; 使用http basic作為登入認證的方式 return http.build; 上述例子,只是擋了沒有權限的人,我們還需要讓有登入身份的用戶可以成得取限User權限。 我們繼續修改,WebSecurityConfig,加入只在記憶體有效的InMemoryUser import org.springframework.security.core.userdetails.User; import org.springframework.security.core.userdetails.UserDetails; import org.springframework.security.core.userdetails.UserDetailsService; import org.springframework.security.provisioning.InMemoryUserDetailsManager; public class WebSecurityConfig .. @Bean public PasswordEncoder passwordEncoder return new BCryptPasswordEncoder; 我們的密碼不應該明文儲,比較保險,我們使用BCrypt演算法,為密碼做單向加密。 @Bean public UserDetailsService userDetailsService UserDetails user = User.withUsernamequot;adminquot; .passwordpasswordEncoder.encodequot;passquot; .rolesquot;USERquot;.build; 我們在記憶中體,加入一個測試用的User,它的名字為admin,密碼為pass,權限為User return new InMemoryUserDetailsManageruser; 然後加入新的測試,直接模擬Role。結果是通過的。 srctestjavaiogithubmacauyeahspringboottutorialspringbootwebapidatacontrollerHomeControllerTest.java @Test void testLoginWithRoles throws Exception RequestBuilder requestBuilder = MockMvcRequestBuilders.getquot;apisomeRecord1234quot; .contentTypeMediaType.APPLICATION_JSON.with SecurityMockMvcRequestPostProcessors.userquot;someonequot; .rolesquot;USERquot;, quot;ADMINquot;; 沒有使用密碼,只使用Role this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.status.is2xxSuccessful .andExpectMockMvcResultMatchers.jsonPathquot;$.retquot;.valuequot;your uuid1234quot; .andDoMockMvcResultHandlers.print; 再來一個測試,改用密碼登入,分別輸入錯的和正確的密碼。 @Test void testLoginWithWrongPasswordAndNoRole throws Exception RequestBuilder requestBuilder = MockMvcRequestBuilders.getquot;apisomeRecord1234quot; .headerquot;Authorizationquot;, quot;Basic randompassquot; 輸入錯的密碼,應該回傳http 401 Unauthorized .contentTypeMediaType.APPLICATION_JSON; this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.status.is4xxClientError .andDoMockMvcResultHandlers.print; @Test void testLoginWithPassword throws Exception RequestBuilder requestBuilder = MockMvcRequestBuilders.getquot;apisomeRecord1234quot; .headerquot;Authorizationquot;, quot;Basic YWRtaW46cGFzcw==quot; http basic 就是把 adminpass 轉成base64 .contentTypeMediaType.APPLICATION_JSON; this.mockMvc.performrequestBuilder .andExpectMockMvcResultMatchers.status.is2xxSuccessful .andExpectMockMvcResultMatchers.jsonPathquot;$.retquot;.valuequot;your uuid1234quot; .andDoMockMvcResultHandlers.print; 最後,當然是正確的密碼才能通過。若果大家還是半信半疑,我們可以跑起真的正服務(IDE RUN或mvn springbootrun),然後用curl去試。 curl httplocalhost8080apisomeRecord1234 failed with 401 curl u quot;adminpassquot; httplocalhost8080apisomeRecord1234 successed 使用SQL Database讀取用戶登入資訊 一般而言,我們不可能把所有用戶登資訊打在InMemoryUser中,通常背後有一個資料庫儲存所有的用戶資訊,我們在登入時,讀取它來做對比檢證。 為此,我們在maven中,加入 Spring Data JPA h2 database (或任何你的資料庫,如mysql 、 sql server) 最後一步,我們把InMemoryUser去掉,改為從資料庫讀取。因為原始碼太多,就不全部貼上。最主要的是WebSecurityConfig.java要關掉之前的UserDetailsService,改為提供一個UserServiceImpl類,它會實現UserDetailsService的功能。 @Configuration @EnableWebSecurity public class WebSecurityConfig 把原來的Bean先變成註解,其他不變 @Bean public UserDetailsService userDetailsService UserDetails user = User.withUsernamequot;adminquot; .passwordpasswordEncoder.encodequot;passquot; .rolesquot;USERquot;.build; return new InMemoryUserDetailsManageruser; springboottutorialspringbootwebapidatasrcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapidataconfigUserServiceImpl.java other import import org.springframework.security.core.authority.SimpleGrantedAuthority; import org.springframework.security.core.userdetails.User; import org.springframework.security.core.userdetails.UserDetails; import org.springframework.security.core.userdetails.UserDetailsService; import org.springframework.security.core.userdetails.UsernameNotFoundException; import org.springframework.security.crypto.password.PasswordEncoder; @Service public class UserServiceImpl implements UserDetailsService @Autowired PasswordEncoder passwordEncoder; @Autowired UserRepo userRepo; @Override public UserDetails loadUserByUsernameString username throws UsernameNotFoundException 因為我們資料庫沒有資料,為了方便測試密碼的加密,我們在java code上直接插入一筆資料。 UserEntity defaultUser = new UserEntity; defaultUser.setUsernamequot;adminquot;; defaultUser.setPasswordpasswordEncoder.encodequot;passquot;; defaultUser.setRolequot;USERquot;; defaultUser.setUuidUUID.randomUUID.toString; userRepo.savedefaultUser; 上述為測試用插入資料,不應該出現在正式使用環境中。 UserEntity user = userRepo.findOneByUsernameusername .orElseThrow gt; new UsernameNotFoundExceptionusername quot; not foundquot;; 找找資料庫有沒有正在登入的該名使用者username List authorities = List.ofnew SimpleGrantedAuthorityquot;ROLE_quot; user.getRole; LOG.debugquot;got user uuid, username, role from databasequot;, user.getUuid, username, user.getRole; 如果前面的 findOneByUsername 有結果回傳,我們就給它一個ROLE_XXX的權限。 return new Userusername, user.getPassword, authorities; 這裏從沒有檢查過密碼是否有匹配,全部交給Spring Security去做 springboottutorialspringbootwebapidatasrcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapidataentityUserEntity.java springboottutorialspringbootwebapidatasrcmainjavaiogithubmacauyeahspringboottutorialspringbootwebapidatarepoUserRepo.java 上述段落中,筆者省略了UserEntity和UserRepo,它們只是一般的springdatajpa概念,有需要可以經文末的連結查看完全原始碼。最需要注意的,是UserEntity的password欄位,在資料庫中是以加密的方式儲存。我們在配匹登入者與資料庫記錄時,也沒有自行檢驗密碼的需要。我們只是在加密過的密碼回傳給Spring Security,Spring框架會自行把登入者輸入的密碼與加密了的密碼作比較。

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

那些年那個很穩定卻又不受歡迎的 git flow 開發流程 多年前,朋友就向筆者介紹git的團隊整操作流程。筆者深思過後,的確實用,那些年的gitflow,很美滿,由開發、測試,到發佈、修補漏動(backport),都有清楚明確的指引。 原作者連結:gitflow 大家如果沒有更複雜的需求,真的可以照搬,筆者也很推這一個模型。 但在長期推廣下,筆者發現大部份人其實都不熟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 中。(前文連結)

Coding Anywhere 工作方案
科技新知
MacauYeah・2024-06-13

最近筆者一直在準備軟件開發的教材,因為各種原因,例如:新舊硬件交替,沒有固定的電腦等等,讓寫稿和設計教程的進行得很慢。但其實這種情況並不旱見,即便是真正的開發團隊,也會時時刻刻面對各種新舊設備的更換。在不久的未來,這種更替速度可能更頻繁,工作模式也很可能趨向這樣,為了打造更靈活的工作方案,適筆者一直為自己的coding anywhere情境物色合適的工具。 基本假設 在分享之前,有些前題條件必需要滿足,coding anywhere的基本條件是我們可以把一些厚重的資源變成cloud或遠端工作,如果你是開發主機遊戲,你的測試必需要在PS5上跑,那就沒有條件帶著裝備走。即使你可以設定遠端連線,但你人在外,其實沒法在PS5上做互動。真正有條件實行的工作,必需要可以在外由開發至測試都行得動。 在這個前題下,筆者就開始分享一些自己嘗試過不同組合。 不可或缺的東西 滑鼠、網絡 這件事,看似不重要,但筆者一直沒法找到完美的解決方案。 無線滑鼠是標準配置,筆者曾經想去掉滑鼠,但不太可行。這個大家還是選一個不太大,而且可以穩定在不同機器切換的滑鼠吧。至於鍵盤,視乎你的主機有沒有實體鍵盤,如果最後選擇平板或掌機的話,還是需要帶鍵盤外出,亦即是不論你選擇何種方案,鍵盤的重量也是不會消失的。 另一個就是網絡流量問題。我們處身的環境,並不一定有免費網絡。有時為了安全性,我們不想配對公用Wifi。那怕不考慮安全問題,公用Wifi都很常出現因為人流太多而被踢的情況,所以一般都考慮直接使用手機的4G5G網絡。而為了節省流量,一般控制好大檔案大更新的下載時機,都是可以達到的。 不同的工作模式,不同的選擇 上述第一個問題在筆者看來,都屬於沒有選擇,但下面的選擇,可以基於價錢、功能、需要而搭配。另外,我們還要假設我們有足夠的Remote資源可以用。但如果大家的開發,必需要帶著硬件資源,就不太可能實現coding anywhere。 一台入門級的Notebook 如果我們大部份工作,都可以經Cloud Service解決的話,其實我們不必投資太多在主機之上。Notebook帶著四處跑,壞的可能性也多,入門級的Notebook就算壞了也沒有那麼心痛。 全Cloud Service還有另外一個好處是不需要擔心備份問題,壞了Notebook就狠心換機。而且Cloud Service的好處是需要更新client software的網絡流量消費不高,不過想真省錢的話,就需要好好控制cloud service。 例子1,如果大家熟識或願意使用github codespace或gitpod等全cloud IDE,Notebook只需要安全Browser就夠。所有IDE, VM都由github或gitpod提供,它們各自有各自的免費用量,也就是說,當大家真的不夠用又不想付費,可以兩著切換用。真的不夠用,就時租codespace 2G 每小時$0.18USD,約為每小時1.44MOP。 例子2,如果大家有自己Cloud VM,可以用VS Code SSH,除SSH的extension外,其他安裝及運行在VM中,對Notebook client的要求不高。Cloud VM品牌可以使用Digital Ocean、Linode等,2G機器價錢更低,每小時0.018USD左右,不過就要自己初始化各種工具。 一台高階的Notebook 這個方案可能就不需要再多解釋了,那就是你把家裏的核心電腦帶著到處走,一切都自給自足。在外的不可控因素可能就只有電量控制。另外一方面,長期的備份和維修成本也是需要考慮的。 輕便裝:一台中階大平板 跟上面的遊戲用PC掌機類似,不過螢幕更大,但缺點是配上鍵盤後,價錢比得上一台中階電腦,出門的重量也比得上電腦。在軟件上,你還必需要選擇Cloud VM,Local IDE也不一定有。所以在成本上來講,沒有很太優勢。大平板可能只對那些有專門APP需求的用戶有意義。 究極輕便裝,一台710寸入門平板 大平板最大的問題是價錢,但如果換成小平板,一切就不錯了,壞了也沒有那麼心痛。源用所有純Cloud解決方案。出門的負重最低,電量也最有保證。這是筆者最推薦的方案。 低成本高階機:遊戲用PC掌機 對,你沒有看錯,筆者指的是主打遊戲的PC掌機,也是筆者現時自己的最佳方案。假如你在工作室、家、公眾環境來回切換,很擔心傷到Notebook的話,那麼買台低成本的PC掌機絕對是可以接受。有些很重要的底層功能,需要多台Cloud VM,可能花費很高,所以還是需要經Local實現比較有性價比。 它最重主要的問題是螢幕小和沒有鍵盤,但這個程度,對比入門平板來講,其實都差不多。但它比平板有更強的CPU、RAM,作為移動核心電腦一定沒有錯。你還可以自由選擇Local VM、Cloud起VM。