文章列表

Git - 持續整合策略 02 | Git - Continuous integration strategy 02

科技新知
MacauYeah・2024-03-14

Night Build 實務操作上的注意點 Night build第一個要注意的問題,就是要確保同一個commit,真的可以重複建設。一般來說,大家的目標只在運行測試,而自動測試不具破壞性,就基本可以重複的。而如果測試當中包含發佈測試版本,那就還要考慮重複發佈有沒有生效或造成附作用。 以Java maven為例,重複發佈測試版本需要遵守特定的規則,版本號需要以SNAPSHOT結尾,這是為讓maven每天都會重新下載它們的包。而沒有SNAPSHOT結尾的,就只會做一次性下載,減少重複下載造成的資源浪費。若真遇著不支援重複發佈的情況,就需要以日期時間做版本號,就像vscode的某些插件,就是以時間截結尾以作為區分。 Night build另一個要注意的問題,就是開發圖隊何時進行下一輪開發,這會決定何時有新的版本號。扣除上述因為工具不支援的而引發的副作用,還要考慮沒有更新而發生的問題。 有個尷尬情況是,團隊在發佈現行版本時,release commit與main有機會是同一個commit(也就是未有進行下一輪開發)。若不斷重複發佈,有沒有變相發佈了一些沒有預期的功能?例如Docker image,官方大力建議每日自動發佈。當底層的image更新後,頂層引用它們的image,也可以重新發佈,保持安全性。但這樣做的問題,就是頂層的同一個版本號,昨日與今日的運行結果也可能不一樣。這對追蹤問題,並不友好。 所以大家做分支整合時,要預先對版本號作好規劃。然後還要留意Night build不應與release commit重疊。版本號大家做好語意管理,再加上alpha / beta / SNAPSHOT等區分Night build版本,應該就足夠了。而commit重疊問題,就要留意開發週期,Night build要麼就比release早一個commit(即在release時,不推進Night build),要麼晚一個commit(即馬上規劃下一個版本號進行Night build)。

星穹鐡道:抽角色、組隊簡介

手機‧電玩
MacauYeah・2024-03-13

因為抽卡機率問題,坊間很多建議都基於課金的前題,不是所以有人都可以重複。但這亦不是筆者體驗這遊戲的主要方向,所以筆者集中分享一些主線必定會取得的角色,或盡量以4星的方式組隊。但在說明組隊之前,先講一講基本系統。讓大家知道那些地方有課金機率成份。 基本出戰 本遊戲是團隊戰,最多同時4名角色上場,同一角色不會出現兩次。影響出戰強度的,除了角色本身屬性、技能,還有裝備要求。同一角色可以裝備一款【光錐】,六款【遺器】,達到不同的Buff。 每個角色獨有自己的【命途】技能養成,光錐及遺器則可以交換使用。 在攻略副本時,可以借好友的角色,但依然會限制同一角色不能重疊。而好友的光錐及遺器不能交換。 卡池 在遊戲中有角色【躍遷】,就是抽角色的地方。除主角外,其餘角色都可以經【躍遷】以機率的方式抽取。若抽到重複角色,會轉化為【星魂】,用作提升角色的特殊技能。主角的星魂以遊戲進度獎勵發佈,其他角色暫時都以抽取為主要來源。特殊角色,如【黑塔】有特別支線任務可以取得。 光錐同時在【躍遷】中取得。 遺器則是副本敵人隨機掉落,沒法經抽選擇。而角色命途技能、光錐、遺器養成部份,所需資源都可在遊戲主線或副本取得。所以有限抽取的,就是角色和光錐。 希有度 角色稀有度最低為4星,最高為5星,道具則為有3-5星。 卡池沒有4星角色保底,只有4星結果保底,每十連抽可以得到4星角色或道具。 組隊目標 - 4星非洲隊 主線故事中,一定可以獲得 主角(物理,攻)或(第一章最後獲得,火,盾) 三月七(冰,盾) 艾絲妲(火,輔助Buff) 丹恆(風,單體攻擊) 娜塔莎(第一章中後期獲得,物理,奶) 黑塔(支線模擬宇宙獲得,冰,群體攻擊) 艾絲妲原本筆者也以為是抽角隨機獲得的,但以BiliBili Wiki引證,其實是抽角教學中必定獲得的角色,所以道理上各位也一定會有。但有些版本有活動送角色,但似乎地區不一樣有不一致情況,故筆者沒有列出。 三月七 雖然在取得奶之前,主角(物理)、三月七、丹恒、艾絲妲,就是沒有選擇之下的選擇。但其實三月七的盾有隱藏技能,會增加受擊機率,這是變相指定角色吸仇恨換賺能量的做法。她也是在缺奶時最重要假回血手段,所以是一個有長期培養的角色,用來湊雙冰、雙盾或一奶一盾也不錯。 艾絲妲 筆者一直忽略了的一位重要角色,因為她施放攻擊就有機會蓄能,蓄能全體加攻。終結技有全體加速效能,普偏的裝備方向是為她加速加能量,讓她可以再為其他人加速加攻。也因為第一章後,與主角可以組成雙火隊,主角可以全隊加盾,艾絲妲加速,打火弱點敵人的話,一定不虧。 娜塔莎 奶,就不用說明了。另外,她也作雙物理的組成。也是筆者作為平常無腦開荒的組成,主角(火,盾) 加 三月七 加 娜塔莎 加 弱點輸出。效率可能不高,但勝在無腦。 無腦隊最大的問題是弱點擊破率很低,因為盾和奶都需要經常回復,少了輸出的機會成本。

Spring Boot 02 - 快速接入Database的選擇: Spring Data JPA

科技新知
MacauYeah・2024-03-08

快速下戴模版 使用Spring initializr,可以很容易就建立一個以Spring boot starter為底的java project。大家可以使用Spring 官網又或是vscode plugin 快速地建立一個maven或gradle project。筆者較為熟悉maven,就以maven起一個範例。 在使用Spring initializr有幾件事必需要指定的: Spring boot version: 3.x.y 或以上 Language: java Group Id: 請選擇有意思的域名,如果你用github,可以選 io.github.yourusername artifactId: 這個範例的名字,例如commandline Packaging type: 本次使用jar,日後若開發web 應用,可以使用war Java version: 17或以上 Dependency: Spring Data JPA, Spring Boot DevTools 這次不像過去順利,因為這裏欠缺了Database連線資料,為了方便測試,我們先在pom.xml加入 h2與spring的整合很好。即使用什麼都不設定,直接運行mvn spring-boot:run,都可以成功執行了。但如果可以,在application.properties加入資料庫設定,會方便日後移植到其他常用的資料庫品版牌。 # src/main/resources/application.properties spring.datasource.driver-class-name=org.h2.Driver spring.datasource.url=jdbc:h2:mem:testdb; spring.datasource.usename=random spring.datasource.password=random 然後我們就可以做靠Spring Data JPA去生資料庫的表 (table)。Spring Data JPA預設使用的是Hibernate。假設,我們有一個表叫APPLE。我們就可以開一個class Apple和一個interface AppleRepo去接它。 // src/main/java/io/github/macauyeah/spring/tutorial/springbootdatabasic/Apple.java @Entity public class Apple { @Id String uuid; Double weight; // getter setter } // src/main/java/io/github/macauyeah/spring/tutorial/springbootdatabasic/AppleRepo.java public interface AppleRepo extends JpaRepository{ // no content here } 注意,因為不同需要,AppleRepo可能繼承不同的XXXRepository,它們大部份都是用來觸發寫入資料庫的指令。而這個也晚除了直接存取Hibnerate EntityManager的需要。 亦因為我們現在用的是h2Database,其實資料表並不存在。我們需要在執行Spring Boot時,同步先建立表,所以在application.properties 加入自動建表的設定。 # src/main/resources/application.properties spring.jpa.generate-ddl=true spring.jpa.hibernate.ddl-auto=update 然後在Spring Boot Context的環境下,可以隨時執行寫入的操作。 @Autowired private AppleRepo appleRepo; public void saveApple() { Apple apple = new Apple(); apple.setUuid(UUID.randomUUID().toString()); apple.setWeight(100.0); appleRepo.save(apple); } Source Code spring boot data basic 因為h2Database只是用作測試用,所以spring-boot執行完,資料庫就會被刪除。而上述原始碼當中,還附上了一些dump sql的方法,至少可以讓大家驗證己儲存的結果。

如何衡量課金制遊戲的價值

手機‧電玩
MacauYeah・2024-03-05

筆者因為作息調整,可以花時間花資源去深玩的遊戲越來越少,需要專攻一款價值高的遊戲是一個很重要的課題。隨着年紀增長,家庭環境改變,大家都可能會遇到相同的問題。所以筆者很想探討一下,一年只玩一款遊戲的話,CP值是否有所保證?也就是滿意度和支出的比例是否保持一個高水平? 好多老一派玩家會支持傳統主機遊戲,主要係因為免費課金制,品質很差。初時下載遊戲免費,但遊戲無法通關,過程也很重複無趣,所以滿意度很差。正好筆者最近重回手遊,就來分享一下時間和滿意度比例。 本文為了方便討論單一手遊的價值,先只以「不課金」,只討論時間成本支出。日後再以「課金上限」來對比不同的課金情況或是與主機遊戲對比。 定義 成本:時間 CP值 ⇒ 淨滿意時長 / 淨成本 ⇒ 即成本越高,每單位成本的滿意度越低。 CP值 = sum (分段內容時長 * 分段滿意度) / (時間 ) 註:分段滿意度可能為負,為方便倍數計算,最大為10,最少為-10。 崩壞:星穹鐵道 - 主觀評分 主線序+ 第一章:20小時 * 8 = 160 五角色養成,累積前70等的升級素材:30小時 * 2 = 60 因為很多時候都是內卦刷戰鬥,不怎開心,但還未至於要吐 第二章:15小時 * 8 = 120 筆者有幸以不課金的陣型,以完成主線第二章。主角(火)、娜塔莎(物理)、希露瓦(雷)、景元(雷,劇情指定角色)。除了主角滿級其他都很素。 角色養成,累積70-80(封頂等級)的升級素材:30 * 1 = 30 70-80等級就開始跳躍性質變,借助外援也無法快速囤積資源。 筆者只有主角的等級+存護命途可以練滿,另一角色也只有等級練滿。其他連突破70級的資源都不夠。 模擬宇宙部份挑戰:5小時 * 8 = 40 忘卻之亭部份挑戰:1小時 * 2 = 2 有難度,但沒什麼樂趣 淨滿意度·時長 :160 + 60 + 120 + 30 + 40 + 2 = 412 淨成本:20 + 30 + 15 + 30 + 5 + 1 = 101 CP值 412/101 = 4.08 以上,就是星穹首年來的內容,對應六季的更新。目前遊戲新剛推出2.0更新,筆者也會花一點時間了解一下是否有等級門檻。 不過以長期遊玩的角度,還要考慮如何提升高等級刷素材的滿意度。

Git - 持續整合策略 | Git - Continuous integration strategy

科技新知
MacauYeah・2024-02-23

對於原始碼的管理,平常筆者也有在用gitlab的Continuous integration,針對每次提交(commit),都會有自動編譯和測試。但當一個專案中,有很多關聯庫(dependency library)的引用時,光是專案中每個commit 行auto build就不夠用了。更嚴重的是,若然大家有很多微服務micro service,它們的更新不會反映在commit中。 所以定期重跑動動編譯和測試,是筆者認為可以緩解關聯更新的問題,至少可以提高知道問題所在。 筆者先做了一些功課,參考別人怎樣思考Night build (定期重新編譯)這件事。 每次整合新功能到穩定分支(stable branch)之前,都需要做自動測試。 當專案複雜性越來越大,每次自動測試都把全部測試跑一次,就會遇到效能瓶頸。 所以考慮commit時做單元測試(unit test),然後每個固定的時間問隔做整合測試(integration test)。那個固定的時間間隔就是Night build。 而筆者的問題並不是來自於效能瓶頸,而是涉及關聯性更新問題。這些要麼就有是經code base 層面引發關聯性自動試測,要麼就是Night build重複測試。這兩個功能,gitlab都有提供,只是筆者初步構想下,Night build比較易設定。因為要考慮micro service的於沙盒環境的部署,最簡易的Night build只需要一個共用的環境就夠。但也同樣意味著,Night build需要進行多個不同的分支測試。就需要多個不同的環境。 Night build的測時時機也是一個問題,因為測試當下,並不能百份百對應關聯micro services的提交狀況,大家就更需要做好發佈的版本號語意管理。 不知道看完筆者的策略之後,大家又有何看法?歡迎大家一起加入git筆記的編輯。

星穹鐵道:模擬宇宙系統簡介

手機‧電玩
MacauYeah・2024-02-22

因為模擬宇宙是遊戲中一個很重要的資源獎勵來源,所以就來全面的講講它的運作方式。 模擬宇宙玩法 模擬宇宙分為多個世界,目前筆者已知的世界有八個,分別對應遊戲序章、一章、二意的地圖和敵人,除了Boss外的敵人種類都有一定隨機性。第三世界至第八世界需要根據主線遊戲進度而開啟。 積分獎勵 每次挑戰不同世界都有積分獎勵,即使沒有到達終點也會有積分。第三世界開始有不同的難度選擇,積分當然也會因為難度提高而變得更高。 每週積分到達上限後,可以取得重要的行跡升級素材 - 【命運的足跡】。而模擬宇宙一週積分會重置一次,也就是一週可以取得一個。這是角色養成後期的必要道具,只能經過不同的獎勵途徑取得(例如無名勳禮、餘燼兌換,但因為週期更長,所以暫不推薦)。 敵人道具掉落 平常角色行跡升級素材,需要經過刷普通敵人取得,同樣原理,刷模擬宇宙不同世界也可以取得。最大差異是,普通敵人刷新率受時間限制,而模擬宇宙重新挑戰就可以一直刷。要變新角色的話,刷模擬宇宙是一個可行的選擇。 積分和道具掉落獎勵也當然會因為難度提高而變得更豐厚。 命途、祝福 在主線中,不斷地提及這個遊戲中很有多個古神之類的存在。而這些神明,在模擬宇宙中就以【命途迴響】、及【祝福】來為玩家加Buff。 玩家在進行世界時,選擇角色時,亦要選擇命途。然後每次戰鬥後,就可以在三個隨機祝福中選一個。當目標命途底下對應的祝福齊夠六個以後,就可以取得命途迴響,一個更強大的Buff。指定祝福越多,命途迴響有更多額外功能,所以模擬宇宙中的Buff有很大的隨機性。 我們要降底隨機性,就只能通過有限度的置換來選取掉落的祝福。 解鎖一定量的命途、祝福,也可以取得一次性的收集進度獎勵,所以去到第七、八世界,你就會開始糾結,該選新的祝福但沒有命途加成,還是先加成後收集? 奇物 更隨機的道具,筆者認為大部份都是Debuff,因為它很大機會嚴重地干擾命途和祝福的配搭。因為同樣有收集進度獎勵,所以第一次遇到的話,也是要取舍。 筆者建議就先收集,後通關。因為低機率的物品真的百年難得一遇。 沉浸獎勵 一定難度開始,在挑戰過程中會出現沉浸獎勵,可以使用【開拓力】或【沉浸器】來兌換。它也是取得後期遺器的重要來源。

git 分支整合問題

科技新知
MacauYeah・2024-02-20

不知道大家的開發團隊、專案規模有多大,但只要系統或程式已發佈,同時又要做維護更新,git 庫都至少會有兩條分枝: 新功能 - main / feature 最新的穩定發佈版本 - Release / v1.x.x 最好的情況下,在開發完新功能之前,穩定版本都沒有需要緊急修正的地方,開發者可以專心開發新功能(main / feature)。然而這個情況並不能經常維持。 情況1:有Bug要馬上修正 最常見到的情況,就是穩定發佈版本有瑕疵,可以經過小修小改來止血,由v1.x.x ⇒ v1.x.y,這些可能對用戶來說,是沒有太大感覺的改動。不過對於開發流程,就免不了由v1.x.y整合(merge)回main時,出現修改衝突的問題。 建議 若屬於日後不再需要的改動,不需於整合到main中, 當然什麼都不用做。但若屬於必要的更新,就需要早早整合到main中。整合雖然痛苦,但延後整合沒有好處。以筆者的經驗,每次整合時有衝突,而越早整合越有條件知道該取用自動混合的那個版本。以整合工具的語言來說,就是更容易的作出use mine / use theirs / edit。 情況2: 不同功能之間有衝突 上述情況1,已經算是可控的。主要因為穩定發佈版本都只會接受小修小改,大改都會直接在main中開當為新功能開發。當你有多個很重要的功能在不同時期被提出,而有些功能你沒有信心在下個發佈中提出,你就會選擇以獨立分支來實現不同的功能,最後選擇信心度高、權重也比較高的功能來發佈。這樣的好處是你可以有限時間先完成最必要的功能,但問題是多個功能分支之間,更容易地有衝突,後期也需要很廢心力地整合。 建議 少做資料夾層面的改動,因為git rename的功能並不是萬能的,會令很多git自動選擇版變得不可讀。筆者的經驗,就是錯把後端和前端的資料夾混在一起,令後端的一些重命名影響到前端。前端也因為有重寫的需要,對資料夾結構大改。最後結果就是很多看不懂的git自動選擇版。有一些有選對,但有一些就選錯。 可以做一些事前處理,來減經痛苦。在筆者的資料夾問題情境,在把後端將要整合的多個commit中,挑選最早前沒有命名問題的commit先整合一次。然後前端先手動模擬後端的人工命名,自行commit一次,最後再把後端剩餘的commit再做整合。這個做法不是完全解決問題,但至少可以讓use mine / use theirs / edit更新易理解。 而另一個建議是,縮短發佈週期,逼使其他開發中的功能越早做整合,也逼使每個功能不要做太大規模的改動。如果真的做大規模改動,就要有心理準備要多次重要的整合。 情況3: 多個穩定發佈版本需要同時維護 若然大家面對的工作規模真的很大,同時有多個版運行版本,就如gitlab,每一個月都有一個新功能版本(16.0.x, 16.1.x, 16.2.x,… 16.9.x),但它不會強逼大家更新,對於過去一段時間的功能版本,也會推出安全性更新(前述的x會不斷修正問題)。 這是一個很負責任的發佈模式,不過對於開發者來講就一定很地獄。因為16.0.x的安全更新並不能無痛地整合到16.9.x中,可能每個版本重新人工修改還要來得穩健。 建議 各個分支人工修改可能更適合。最後就是取決於商業政策的考量,到底公司願意為已發佈的功能版本提供多久的支援。就以gitlab為例,其實它也只承諾維持兩三個月前的功能版本。是否會backport到多個月之前的版本,就看問題的嚴重性和backport難易度。 也分享一些筆者朋友的經驗,他們開發的是軟件跟硬件整理的軟件庫。但因為硬件有限制,例如庫的大小、算力的差異,所以最後分支多到爆炸。這也是軟硬整合的痛,問題暫時無解。除非老闆肯放棄市場。

星穹鐵道:中後期無課心得

手機‧電玩
MacauYeah・2024-02-08

分享前先講講為何會回鍋。因為筆者平常支持的RPG品牌Square Enix 實在不濟,每次更新完手機,它家的買斷型遊戲都攔淺。實在玩不下去,還是要回到米哈遊,星穹有中文、持續更新、自動存檔,從內容到技術上都比買斷型遊戲更適合手機遊玩。所以筆者就繼續來養成看看吧。 角色取得策略 之前筆者在其他文章內有提及過,免費課金制最大的痛點就是可取得的資源有上限,所以到了中後期,資源投資在什麼角色上是一個很重要的考量。但由於本文的主題是無課心得,所以筆者亦限定自己只使用免費卷或免費石抽4星角色。筆者的抽角色策略也很保守,各位應該可以很輕易地重複到。最簡單地講,只有弱點擊破效率不足時、打不過的主線時,才會考慮抽角色。 青雀 - 量子屬性 - 智識命途 主線第二章,豐饒玄鹿,弱點屬性為火、冰、量子。主線預設只有一火(主角)一冰(三月七)的組合,筆者實在打不過豐饒玄鹿。此時有兩個選擇,要麼就多抽一個量子角色,豐富一下隊中角色;要麼去打支線模擬宇宙,取得另一隻冰免費角色-黑塔。 為長遠發展,筆者先抽角色,不過運氣不怎樣,只抽到青雀。智識命途主打群體傷害,但她沒有持續傷害加成,而且戰技有運氣成份,所以強度不高。但對於主線玄鹿至少可以一戰,有抽到朋友可以隨便升一升等級就可以。 希露瓦 - 雷屬性 - 智識命途 在中期開始,除了經普通遇敵獲取【行跡素材】之外,攻略支線【模擬宇宙】也是取得【行跡素材】的重要方法。此時希露瓦配搭虛無命途的【懷疑】debuff效果可以在【模擬宇宙】達到多重疊加傷害。有條件疊加傷害的另一個四星角色應該是素裳。筆者有抽到,但因為物理屬性重疊,所以沒有練。 另外,在正常情況下,在攻略完第一章後,預設會有一火(主角)一冰(三月七)一奶(娜塔莎),再加上希露瓦,【均衡試練伍】可以穩過。通過後,可以特破角色等級上限至80,是1.6版本的封頂等級。(2.0版本才剛更新,但應該沒有調整封頂等級)

龐大的Docker Logs該如何處理? | 傳統的syslog幫到你

科技新知
MacauYeah・2024-02-02

平常大家在做單機app時,寫log有很多選擇,最簡單就是寫在檔案中。但在docker container裏面,寫檔案時要注意怎樣保留log檔,避免因為重建container時不見了。 docker 大部份官方預設image,都把log導向至stdout和stderr。這是方便docker做管理,也方便大家使用統一的docker logs指令來查看,即使到了Swarm mode底下,docker service logs也是同樣原理,使用差異不大,頂多就是不保證log的實時性。 如果網路延遲不計較的話,最大問題也是logs怎樣保存的做法。預設就是container刪走的時候,logs也會一借走。單機模式下,沿用最普遍的方法寫log的做法不是不可行,只是考慮到在極端情況下,同一個node(節點)中,有可能同時運作同一個service(服務)的多個分身(replica),這裏它們寫檔案時就有機會互相搶佔。 筆者認為,比較合理的是外部提供的服務,例如syslog,把寫檔的操作交給節點的Host OS處理。然後就保證好每筆log都會是一條完整的記錄。 以下就以linux Host裏面的syslog,為大家簡介一下設定的步驟。 設定docker 導向 syslog 把該主機的docker daemon (/etc/docker/daemon.json),設定使用syslog driver,並以特定的方式編寫syslog tag。 { "log-driver": "syslog", "log-opts": { "tag": "dockercontainer/{{.ImageName}}/{{.Name}}/{{.ID}}" } } 無腦設定已完成,重啟docker就可以了。 但為了日後管理方便,能把docker log放進獨立的一個檔案中,會更易找問題。所以我們可以進一步設定syslog。我們以Ubuntu 22.04為例,可以在/etc/rsyslog.d/下增加一個設定檔(/etc/rsyslog.d/*.conf),指定看到syslog tag以dockercontainer為首的記錄,都要獨立抽出來。 # file: /etc/rsyslog.d/51-docker.conf :syslogtag,startswith,"dockercontainer" -/var/log/dockercontainer.log 為免有檔案權限問題,手動指定檔案的所有權後,才正式重啟syslog。然後所有相關記錄都會寫在/var/log/dockercontainer.log 滾滾滾滾滾動的log檔 檔案一天一天地長大,如果可以,還是自動清掉太舊的記錄為妙。Linux Syslog,通常也會配著logrotate使用。 筆者亦以Ubuntu 22.04為例子,做了個最簡單的自動滾Log功能。目標就是當log檔案大於1M後,就要重開log檔。舊的log檔最多保留7份,多了就刪掉最舊的。 # file: /etc/logrotate.d/rsyslog-dockercontainer /var/log/dockercontainer.log { rotate 7 size 1M missingok notifempty compress delaycompress sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript } 加了設定後,什麼都不用重啟,因為它是Ubuntu 的排程動作,到執行時就會以最新的設定檔執行,詳見/etc/cron.daily/logrotate. 有需要手動測試的話,需要手動呼叫/usr/sbin/logrotate。加入-d參數後,會被視為debug mode,這是官方的說法,但因為debug mode沒有執行效果,更加像是linux中常見的dry run mode。

Steam Deck 也可以作為文字創作

科技新知
MacauYeah・2024-01-23

之前筆者就介紹了,如何使用Steam Deck作為程式開發機使用。這可能對於一般讀者來講不太常用,更常用的是做一些文書處理。筆者最近也拿著Steam Deck,也一步步地補充文書處理所缺少的軟件,正式踏入Steam Deck日常之路。 如果你沒有對系統做過任何更改,在桌面模式中,只要打開「Discover」,輸入後逐的軟件的唯一package name,就可以找到相關軟件。 但如果你像筆者之前一樣,加了homebrew等第三方系統,可能所有軟件都需要在terminal中,經過指令sudo flatpak install PACKAGE_NAME。 Chrome 唯一碼: com.google.Chrome 系統預設瀏覽器只有Firefox,不習慣的話可以另外下載Chrome。有了Chrome,至少所有的雲端文書軟件都可以用,想用Google Doc也沒有問題。 中文輸入法:Fcitx5 + Rime 唯一碼:org.fcitx.Fcitx5 唯一碼:org.fcitx.Fcitx5.Addon.Rime Steam Deck原本有自帶的輸入法,但只適用於螢幕虛擬鍵盤使用(即使用Steam key + X,打開虛擬鍵盤),而實體鍵盤就無法轉輸入法了。這時就需要Linux上的Fcitx5和Rime了。安裝很簡單,之後還要設定一下。 首次安裝後,在啟動器(桌面左下角)搜㝷及啟動 fcitx5,然後在右下角就會見到有個新的鍵盤圖示出現。 按鍵盤圖示,滑鼠右鍵,點選configure,把Rime 加入Fcitx裏面,然後Apply → Close 然後按鍵盤圖示,滑鼠左鍵,應該就會切會成中文輸入法了。這時原本的鍵盤圖示會變成中文輸入法的圖示(或者你經Ctrl-Space也可以) 最後對著中文輸入法圖示,再滑鼠右鍵,可以選擇不同的中文輸入法,例如拼音、注意、倉頡等。 有了輸入法,有了瀏覽器,世界已經都是你的了。 下載器 JDownloader 唯一碼:org.jdownloader.JDownloader 它可以用來下載大部份隱藏文件,例如YouTube video / audio 。但需要注要,首次下載JDownloader 後,還要經過軟件內部更新,否則不能使用。(就像很多手遊,下了主程式後還要下更新檔) 其他 如果你不是長期有網絡,還需要真離線版文書處理器,還可以看看LibreOffice,WPS Office。但這些都不能保證跟windows office 百分百轉換,可能還是使用雲版的Microsoft office 365還要實際。

街霸六-如何不要被【贏】成為競技遊戲的唯一目標?

手機‧電玩
MacauYeah・2024-01-19

眾所週知,玩遊戲普遍都是圖開心。很多朋友玩遊玩競技遊戲時,【贏】都是一個很重要的樂趣指標,但競技總不可能每個人都贏,輸的人反而是大多數。所以競技遊戲若沒有其他樂趣,玩著玩著,就會越來越少參與者。 問題是,競技遊戲真的有其他方面的樂趣嗎? 筆者認為是有的,但至少參與者的心態要放開。 就像求學不是求分數一樣,探索一門新知識比分高低要來得重要,玩遊戲也更是如此。以筆者玩街霸六的情況來講,可以探索的地方實在很多:- 目押、取消連技- 對空- 對策動力衝擊- 對策突進- 狗昇、防狗昇- 打亂動、搶制(Abare)- 壓起身 (Meaty)- 安全跳 (Safe Jump)- 立回 (Neutral)- 確反 (Punish)- 差合 (Whiff Punish)- 打拆 (Shimmy) 最後才引伸不同的角色對策。 而大部份人都一定會陷入的低潮就是:當等級越高,對手的熟練度就越高,對機制的理解就越深,然後就會對戰得越沮喪。筆者因為一些原由,看到別人都爬分時都有非常沮喪的練歷,也看到退遊戲的心路歷程分享。 筆者屬低分區,無條件指導別人如何進步,但筆者可以提的意見是,要逆向思維:自己會輸,是因為對方是強者,跟強者對戰,其實是在學習、在感受。有時候,筆者也會因些微差距而輸了對局。有時候,筆者也會想,是不是對方運氣好。 但感謝街霸六的對戰大堂,只要對方願意,可以很方便的跟同一位對手重複對戰。經過重複對戰,你就會知道是不是真的只是對方運氣好。更重要的是,重複對戰可以有助於大家熟知對手的策略,只要有對策,對局就不一樣。就算當下無解,也可以在訓練室再進一步研究。 街霸六的對戰機制和訓練室的各項細微功能,是眾多手遊、什至是主機遊戲,都無法提供的。可以隨時與陌生對手匹配友誼賽,可以自定義對戰,可以重播比賽,觀看對手的輸入按鍵,訓練室還可以查幀表,錄動作,混合抽樣播放動作,讓你可以有目的性地實驗、練習反應對策。 在分數線機制上也有一些保障,不同角色分數獨立,打上特別段位後有一次跌級保障。讓大家在排名賽上,輸掉也不至於十分心痛。若果心理上實在受不住排名賽的壓力,友誼賽絕對低分爬上高分區的一個試招的好選擇。在對戰大堂的友誼賽中,很易會遇到比自己排名高的對手,多找對方實戰看看,輸了沒有成本,但贏得了經驗。

Spring Boot 01 - 萬物始於Spring boot context

科技新知
MacauYeah・2024-01-16

Spring Boot 01 - 萬物始於Spring boot context 筆者早些時候向一位朋友討論,為何Java那麼不受歡迎。朋友一句就回答,Java煩爆,沒有人會喜歡。 老實講,Java在句法上,實在囉唆。但以筆者的經驗,即使使用其他語言和開發框架,在實戰到一定複雜程度下,其實也一樣煩爆。 而現在的Java框架中,就以Spring boot的入門門檻低。筆者從Spring boot 1.x用到現在的3.x,也真的感受到更多的簡化,所以筆者也加入一起推廣Spring boot的行列。筆者將會通過一系列最小的可執行程式,為大家講解Spring在Web和資料庫上的應用。 所以現在就不廢話,馬上開壇作法 快速下戴模版 使用Spring initializr,可以很容易就建立一個以Spring boot starter為底的java project。大家可以使用Spring 官網又或是vscode plugin 快速地建立一個maven或gradle project。筆者較為熟悉maven,就以maven起一個範例。 在使用Spring initializr有幾件事必需要指定的: Spring boot version: 3.x.y 或以上 Language: java Group Id: 請選擇有意思的域名,如果你用github,可以選 io.github.yourusername artifactId: 這個範例的名字,例如commandline Packaging type: 本次使用jar,日後若開發web 應用,可以使用war Java version: 17或以上 之後就不用選了。若你經官網起範例,你會得到一個zip檔,下載後解壓縮。若你使用vscode插件,最後插件會叫有一個位置儲存。它們都是最後也是會得到同一樣範例Java project。 你使用Vscode,Intellij打開,IDE都會自動辨識到它是java maven project,同時會顯示java和maven結構。道理上你用Intellij 應該可以無腦開始編譯(Community 或Ultimate版都可以), Vscode有安裝Extension Pack for Java也會開始自動編譯。不想麻煩,也可以試用Github Codespaces - java。Github Codespaces其實就是一個雲上的vscode,經網頁可以連到Github VM內的vscode,所以它也會有齊Extension Pack for Java等插件。 筆者最後也會上載已完成的範例,它也可以在Github Codespaces上以Java執行或繼續開發。 打開project中的pom.xml,它為我們添加了兩個很重要的lib org.springframework.boot spring-boot-starter ... ... org.springframework.boot spring-boot-maven-plugin spring-boot-starter是重中之重,它定義了怎樣動態地設定日後的其他lib,它是讓我們可以無腦設定的一個關鍵。(但若大家有很多客制化的設定,就要返撲歸真地逐個lib叫起)。 maven在預設情況下,只會負責編譯和打包目前的project原始碼。所有相關依賴(就是xml中的dependency),並不會自動包起。而spring-boot-maven-plugin,就是幫我們把相關依據都包在一起,讓你的jar可以獨立行起來。 註: 若大家在開發lib jar,並不是一個獨立執行的jar,也就是原始碼上沒有main函數,大家就不應該引用spring-boot-starter和spring-boot-maven-plugin。 我們繼續看其他原始碼,整個資料夾就像以下那樣。 . |-- HELP.md |-- pom.xml `-- src |-- main | |-- java | | `-- io | | `-- github | | `-- macauyeah | | `-- springboot | | `-- tutorial | | `-- commandline | | `-- CommandlineApplication.java | `-- resources | `-- application.properties `-- test `-- java `-- io `-- github `-- macauyeah `-- springboot `-- tutorial `-- commandline `-- CommandlineApplicationTests.java CommandlineApplication是我們有main函數的java class。我像可以經過IDE運行main又或者下指令mvn spring-boot:run來執行。 正式開始我們的Commandline開發 我們在CommandlineApplication.class中,加入新的程式碼,實現ApplicationRunner和它的函數run。 package io.github.macauyeah.springboot.tutorial.commandline; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.boot.ApplicationArguments; import org.springframework.boot.ApplicationRunner; // other import @SpringBootApplication public class CommandlineApplication implements ApplicationRunner { static Logger LOG = LoggerFactory.getLogger(CommandlineApplication.class); public static void main(String[] args) { SpringApplication.run(CommandlineApplication.class, args); } @Override public void run(ApplicationArguments args) throws Exception { args.getOptionNames().stream().forEach(optionName -> { LOG.debug("option name:" + optionName); args.getOptionValues(optionName).forEach(optionValue -> { LOG.debug("option values:" + optionValue); }); }); LOG.debug("program end."); } // ... 這個run函數很直白,就是更好地演譯main中的String[] args。 但大家還要看清楚,這個main並沒有直接執行run。其實它是靠SpringApplication.run及@SpringBootApplication,跑一堆自動設定,最後因為傳入CommandlineApplication.class是一個Spring 可以處理的ApplicationRunner,所以才呼叫它的CommandlineApplication.run。 換個講法,如果今天做的是web應用,傳入去的就會是SpringBootServletInitializer,這個SpringBootServletInitializer也不一定跟main是同一個class。 如果大家有興趣,可以經過反編譯器,點入@SpringBootApplication看它的原始碼,你就可以看到它其實代表了很多自動化的東西。如果我們只做一些在同一個模組下生效的事情,《自動化》極大地降低了大家入門門檻。一般來講,如果大家不在意程式碼的複用度,比較少機會自行設定,自動化已經很有用。而隨著系統規模增加,多模組就慢慢地顯得重要,在大家了解完基本的Spring後,著者再從測試用途test case入手,為大家介紹如何手動設定。 Source Code Commandline Application

Spring Boot - Maven Cheat sheet

科技新知
MacauYeah・2024-01-12

基礎 刪除所有結果,全部重新編譯 mvn clean compile 跑起用Spring boot寫的main class,運行Spring boot context。 mvn spring-boot:run # or mvn clean compile spring-boot:run 執行測試用例,預設只會測試test資料夾下以某些命名規則的class(例如class名以Tests或Test結尾的class,其他命名規則筆者未有能力一一驗證) mvn test # or mvn clean compile test 多Profile、多組件、多測試 使用-P指定編譯時的選用pom.xml中的project.profiles.profile參數。也可以用此來傳遞到spring profile,使得編譯後的spring war預設選擇特定profile。 mvn clean compile -PmvnProfile # or mvn clean compile spring-boot:run -PmvnProfile 使用-pl限定mvn指令只對某個子組件生效,但有時候子組件之間也有引用關係,所以需要再額外加上-am參數(--also-make) mvn clean compile spring-boot:run -pl SUBMODULE_NAME -am 使用-Dtest=限定只執行某個class的測試用例,或單個測試函數。(可以無視class名的命名規則) mvn test -Dtest=TEST_CLASS_NAME # or mvn test -Dtest=TEST_CLASS_NAME#TES_METHOD_NAME 若屬於多組件情況下,其他子模組找不到同樣名稱的測試,會測試失敗。需要再加上-Dsurefire.failIfNoSpecifiedTests=false mvn test -pl SUBMODULE_NAME -am -Dtest=TEST_CLASS_NAME -Dsurefire.failIfNoSpecifiedTests=false # or mvn test -pl SUBMODULE_NAME -am -Dtest=TEST_CLASS_NAME#TES_METHOD_NAME -Dsurefire.failIfNoSpecifiedTests=false 打包 在本機電腦中,把java變成jar或者war。通常用於自行發佈的環境中。 mvn package 有時特定Profile沒法成功執行測試用例,或者你認為有些測試問題不影響使用,需要跳過package中的test。 mvn package -Dmaven.test.skip=true # won't compile test folder mvn package -DskipTests=true # compile, but won't run 例外情況 強行把一個第三方jar,種到本機電腦中的.m2/repository # copy from https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html mvn install:install-file -Dfile= -DgroupId= -DartifactId= -Dversio

街霸六的元宇宙大笪地對戰大廳

手機‧電玩
MacauYeah・2023-12-26

上期就為大家介紹了Modern Mode的新系統。今期就再繼續為大家介紹新的對戰系統。(上期連結: https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/13954 ) 找個陪練很重要 現在街霸五中,網上對戰不外乎是隨機的排名賽、隨機的友誼賽、邀請特定網友在對戰大廳輪流對賽。看下去沒有什麼大問題對不對? 實質上就是一切都很隨機,而對戰大廳很少人懂得運用。 街霸六中一個很重要的改動,就是在隨機的排名賽和友誼賽,加入賽後自訂賽制的玩法。排名賽上遇到五五波的對手,想跟它再打幾場? 可以,馬上進入自訂友誼賽,打個夠。這個改動很必要,在過去的日子裏,特發跟不同人隨便打兩三場,根本不知道應對手段;跟同一個對手來回對策,才會慢慢知道輸在哪裏,有沒有什麼地方是博奕的盲點。猜包剪揼連輸三場,你覺得是對手運氣上壓制你,但連猜十場你也輸,就代表你真的被對方看透。若在排名賽上沒有碰到想賽後重複對戰的對手,遊戲商亦很佛心地重現了一個類似大笪地的對戰大廳,讓你可以在元宇宙坐在一個虛疑街機框下,等待那些跟你一樣不太介意分數,等級差不多、但只想連續思考對策的朋友。 在過去街霸五中,隨機的友誼賽和對戰大廳,對筆者這些低端玩家來說實在沒有什麼用途。友誼賽實力差距很大,基本上就是老手開發新帳號來碾壓新手的地方。對戰大廳則是連線品質參差問題,見到高分的不敢進去,低分的基本上網路卡到不能玩。當時最能遇到熟練度差不多的對手,就只有排名戰,但同一名對手的排名戰機會不多,然後大家又非常在意分數的上上落落,所以當時的對戰實在稱不上快樂。 對比這個情況,街霸六就變得放鬆很多,大家更容易地在大笪地中找到差不多的對手陪練,不用計較分數。大笪地的成功,並不是單純地因為可以自定義對戰,它的連線品質提高,也是穩定在線玩家數量的一大原因。 其他重要改進 單從字文上,或許你覺得整個街霸六都是換湯不換藥。但筆者很負責任的說,它是在硬技術和設計上,都做到很大的改進。雖然不能稱為劃時代的改進,但有了它們,遊戲更友善: 對戰系統可以全平台跨平台對戰,PS、XBox、PC可以大混戰。你能匹配到的有效在線玩家變多了。 提高連線品質,現在那怕是Steam Deck連上Wifi也能網上進行對戰,大家也不那麼懼怕延遲的問題。 大笪地加入社交元素,你還可以通過故事模式,解鎖自定義格鬥技,在非正式的對戰中跟別人惡攪對戰。 練習模式加入極重要的幀數顯示,大家更有條件地自定義練習情境。 玩家們已經極少再需要上網查幀數資料,除了無敵幀需要上網查以外,其他的自行試就好。 官方在練習模式中預錄制了一些情境練習,例如對空、破防、解投等,讓大家可以直接練。但在解投的情境中,更讓筆者明白這遊戲有多麼的爾虞我詐。 這兩期講的東西,都是Capcom針對核心遊戲元素的多項精進。吸收了街霸五的技術和策略上的失敗,街霸六就從軟硬兩方向大改進。Modern Mode在直正意義上可以讓新手入門,但又不致於無腦遊戲。對戰機制,可以讓大家不只關注排名賽,更大地去提供實戰環境讓大家實驗自己的PvP策略。