稍微研究了一下BepInEx這個很常見的模型修改外掛在macOS下要怎麼使用，我用Chill with You – Lo-Fi Story來舉例。首先，你當然要有且下載這個遊戲：
Leave a comment
BepInEx在macOS/Steam下怎麼使用 (Chill with you – Lo-Fi Story)
iPhone Air Review: Lightweight and Elegant
從 iPhone 13 Pro 用到現在，已經快三年半了。原本沒特別想換，但最近看著螢幕邊框越來越舊、電池健康掉到 82%，加上身邊朋友陸續換新機，還是忍不住開始研究今年的 iPhone 17 系列。
一開始的目標其實是 iPhone 17，Pro 系列向來是「全都要」的選擇。但仔細比規格後發現，今年 Apple 的取捨策略跟以往不太一樣。iPhone 17 Pro 雖然有三鏡頭、更好的散熱、更大電池，但很多功能對我這種不打遊戲、不拍專業影片、不需要極致多工的人來說，真的用不到 :
- 性能：現在iPhone老實講性能還滿過剩的，我還真想不到我日常什麼場合會需要很好的散熱跟更強的CPU，尤其我又不打遊戲。
- 記憶體：17 是 8GB，17 Pro 是 12GB，殺後台的差別對我這種不愛開一堆分頁的人來說，幾乎感覺不到，也許開了沒啥路用的Apple Intelligence「或許」會感受到一點差異？但是應該也不值一萬大洋的差價。
- USB：17 Pro 有 USB 3 傳輸，比較起17的USB2，我不禁思考我拿這台iPhone 13 Pro到底用USB傳過幾次東西啊？好像一次都沒有吧？這規格應該可以當作完全沒差吧！？
- 電池：感覺那顆衰老殘缺的13 Pro都夠用了，應該哪隻都夠滿足我需求吧我猜？
- 拍照：多了一顆光學望遠，老實講光學望遠在13 Pro上不能說沒用過，但是真的很少很少…
一直到這個時候其實我都完全沒有考慮過iPhone Air。17 Pro 系列價格比 17 高出一大截，CP 值瞬間讓我動搖。去年 iPhone 16e 被砍到連 MagSafe 都沒有，今年 17無印反而回歸「該有的都有」，螢幕有 ProMotion 120Hz、支援 Always-On，MagSafe 也完整保留，感覺 Apple 終於把「平而不貧」的平衡點找回來了。
Read more “iPhone Air Review: Lightweight and Elegant” Leave a comment
聊聊電動車電池校正
大多數電車車主應該都知道電池分為LFP跟三元鋰(我們取主流的NMC)，也都知道LFP建議充到100%來做「電池校正」，而通常對NMC則是沒有類似的建議。
什麼是電池校正？為什麼需要電池校正？
任何有BMS(電池管理系統)的電池都有個百分率，告訴你用掉了多少電。這個百分率有時會不準確，通常這些百分率會在下幾個週期BMS的電池校正中貼近正常。那為什麼唯獨磷酸鐵鋰(LFP)需要特別關心電池校正，而三元鋰(NMC)不太需要？
我們先從單一cell(單一電池)的情況說起
直覺上，我們判斷一個電池剩下多少電，通常是看他的電壓，再去參照放電曲線。在大多數的情況下的確是如此:
Leave a comment
回顧一下這一年的電車生活
Model Y在一年前有迎來一波滿大的降價（約20萬），很多剛買的車主自覺變成韭菜。不過他人的韭菜就是我的快樂啦，趁著這波降價就把家裡的小白升級成大白。
賞車
當時是改款後Model S/X進台灣，我本來一開始的目標是Model S，在網路上填表單也是要試乘S。後來台特打電話來說明目前S並沒有開放試乘，不過歡迎來台特內湖靜態賞車，也能先安排一下Y的試乘。
Read more “回顧一下這一年的電車生活” 2 Comments
如何在CLion上用Rust玩LeetCode
之前花了不少時間在goland上跑起leetcode plugin，需要一些設定才可以讓整個goland跑起來。現在多了一個Rust可以玩解題，那我們首先還是要先把整個環境搭起來啦！
需要條件
- CLion。官方Rust套件是比較prefer CLion，我不太確定其他的JetBrains系列IDE能不能跑，反正我是用CLion跑起來就是了。
- Cargo/rustc 這在裝官方的rust套件應該就已經裝上去了。如果你不知道這是啥的話，先把rust學熟在想著用rust解題吧….
- IntelliJ Rust Plugin，雖然官方建議用CLion跑，不過看這名字….應該可以在IntelliJ跑起來？
- LeetCode Editor or LeetCode Editor Pro ，兩者其實差異不大，只差在後者login比較方便，前者要去找session ID。我是覺得他對我幫助很大，我就付費支持啦。
Leave a comment
Go 1.18:Generic and Fuzz
錯誤的種類
在講這個之前，先提一下主流語言通常「錯誤檢出」方面通常分為三個階段：
- 編譯前階段 (pre-compile time)
- 指的是這個錯誤不需要被編譯即可被檢出
- 很多語言沒有這東西，他需要language server protocol(LSP)支援，如
gopls - 很多IDE各語言的賣點就是自己獨到的LSP，但是剛好拿來做利子的
C++擁有非常混亂的LSP實作，常常pre-compile time報錯，但是compile下去沒問題，以及反之….主要也是因為C++實在是過於複雜。
- 編譯階段 (compile time)
- 指的是這個錯誤在編譯的時候就可以找出來
- 前兩者也可以並稱為compile time，如果沒有要特別指名LSP提供的功能的話。
- 執行階段 (runtime)
- 指的是這個錯誤需要在執行期才會發作
而go是一個滿特殊的語言，他能夠把一些runtime才能檢出的東西藉由gopls以及go vet 做結構性語法檢查下，將錯誤把runtime提前到pre-compile time。
Leave a comment
用tag實作Password Mask
我其實滿驚訝目前好像沒有任何library有實作這個，或者有但是我找不到，所以我就實作了一個。別看這功能看起來很小巧簡單，這個需要對reflect有相當的認識，所以把製作心得記錄下來。
成品網址
需求
通常我們server boot up的時候需要印出很多log，有時候無可避免的要把整個config給印到log上，這樣會產生一個問題：要是config內含敏感資訊，如帳號跟密碼，這就會產生一些資安問題：
log.Infof("bootup with config : %+v", config)
印出來就會像這樣（標準的%+v會印出來的格式）
{Host:192.168.1.1 User:username Password:mypassword123}
顯然，這是不太恰當的，所以我們總歸來講有幾種作法
- 把他轉json再印，把敏感的地方用
json:"-"讓他不被印出來 - 實作
func String() string，把敏感資料手動by key抹除掉
Leave a comment
將服務遷移到Google Cloud Functions
最近開始把腦筋動到每個月要吃掉我20鎂的linode，看看能不能用Google Compute Platform來取代掉單純的VM。GCP本身有提供Free Tier, 所以只要小心地控制用量，搬遷應該是可以省下一筆，而且也可以玩玩GCP的一些新功能。
需求分析
我這次先搬遷之前寫的一個爬蟲服務，這個爬蟲服務應該是我現有服務裡面最簡單的一個，首先先分析一下他有什麼特性：
- 需要定時被喚醒（設計上大概10分鐘一次就夠了）
- 需要一個地方存放爬下來的分析資料
- 不需要實體上的Database
- 程式本體相當小
Leave a comment
沒原生Thread Pool，那我們自製Worker Group
可以先看看上一篇沒Thread Pool，Limiter也好？真的嗎？ 來個前情提要。
Worker Group其實基本概念跟Thread Pool很像，就是:
- 一堆Worker在跑，等著接收參數並且輸出結果
- 單一Worker擁有一個用來輸入參數的channel，以及一個用以輸出結果的channel
- Worker可被context的Done()終結，或者：
- 可被WaitGroup終結
不過由於go沒有generic(目前版本是1.16，在1.17/1.18會支援)，所以這兩個channel都沒辦法寫得很漂亮，這也是大多數Worker Pool要不就是得用chan interface{}來寫，不然就是寫不出來。不過Worker Group這種東西其實夠輕量，輕量到其實自己打造都是可以的，這邊就介紹一下怎麼自己打造一個Worker Pool，以及揭秘為什麼很多CLI/UI都需要有一個自己的UI Thread(go沒thread，所以稱為UI routine吧）。
One Comment
沒Thread Pool，Limiter也好？真的嗎？
眾所皆知Go是沒有原生的Thread Pool這種東西，這在寫Crawler的時候會造成一些小小的不便。比方說你想要crawl PTT，這樣打一打大概2秒內DDoS protection就把你擋起來了：
docUrlList, _ := GetDocUrlList() //拿到某個版的文章列表
for _, docUrl := range docUrlList {
go func() {
docUrl := docUrl
p, _ := ParseSingleRawDocument(docUrl)
parseChannel <- p
}()
} 2 Comments