在 Steam 城市營造和殖民模擬節購入了這款河狸浮生記，玩了一兩輪覺得挺不錯的，反正這款遊戲還沒有成就系統，也不用像前幾款一樣等白金再整理，決定來順手紀錄一下心得。

河狸浮生記的主軸是在人類滅亡後的世界裡率領河狸們建造都市，是款偏小品休閒的城市營造遊戲，我個人玩得還蠻開心的，除了河狸蠻可愛的以外，這遊戲的可玩性也符合我對小品城市營造的要求。

在指揮河狸們建立都市的過程中，我們主要會面臨三個課題：資源管理、災難處理、城市規劃。

資源管理和大多城市營造遊戲相同，就是在不同階段會有不同的主要資源目標，在生產既有資源的同時，逐步疊加生產新資源的需求。因此需要一步步提升城市蒐集、處理和儲藏資源的能力，同時維持所有資源的生產量和儲藏量，讓城市能夠持續運行。

而在這款遊戲，因為是河狸當主角，建築大多依賴木頭來製作，初期就需要積極開採木頭拓荒，同時規劃種植樹木來產生長期、持續的木頭收入，畢竟木頭自由就是持續擴張的本錢。

開伐一定木頭、開始有基本的建築之後，就開始面臨河狸的生存需求，尤其是食物和飲水。這時候就需要採集並種植漿果和胡蘿蔔等食物來源，並在河岸邊採水儲存，才能保證河狸們能夠長期存活。

在前期階段，擴張跟存活就是我們的主要目標了，吃飽穿暖就是我們河狸村的夢想。

我們在之前 JMeter 的筆記時，介紹過直接對服務爆打一波的作法：簡單來說就是打好幾輪看看服務撐不撐得住，然後紀錄能吃的最大數量，可以說是非常暴力的做法。

但如果我們想要模擬某個固定數值的請求量（例如每分鐘 100 次請求）、又或是需要用固定速率打出去（例如每 5 秒得敲一下），就不能像上次一樣粗暴地全力出擊了。

這時候，我們就可以用 JMeter 提供的 Constant Throughput Timer（固定吞吐量計時器）來限制呼叫頻率，馬上來筆記一篇。

以下範例會使用到 JMeter 的 HTTP Request 等功能，還不太瞭解的朋友推薦先閱讀上一篇筆記：使用 JMeter 來對 API 壓力測試吧

先確認一下環境：我們有一組腳本，內容只是簡單地戳一下 API

現在我們希望可以模擬線上使用者在尖峰時段的使用頻率，並確認我們服務挺得過去，所以需要把這組腳本調整成：「每分鐘戳 20 次，持續五分鐘」

補充：有時候我們收到的需求會是「持續五分鐘，然後總量為 100」這種，意思是差不多的，反正先確認好 「每分鐘的數量 x 持續幾分鐘 = 總量」 這幾個關鍵數字再說嚕。

首先讓我們加入一組 Constant Throughput Timer：

WakaTime 是一款紀錄 Coding 時間的好用工具，只要安裝 IDE 的擴充套件，就可以輕鬆地記錄各個語言、編輯器、專案所用的時間。我從 2020 年寫了篇 WakaTime 介紹文章 開始，也一路用到現在 2025 了，已經習慣動不動上去看兩眼的生活。

但在相對封閉的一些環境進行開發時，我們可能需要先對 WakaTime 調整一些設定才能用得安心，這篇筆記就分享一下最近遇到的三個場景，供有興趣的朋友參考參考。

在 WakaTime 隱藏敏感資訊（檔案名稱、專案名稱…）

Wakatime 除了會記錄使用的程式語言和 IDE 等工具以外，也會紀錄專案、檔案路徑等等。但有時候我們可能並不希望記錄這些資訊（像是業主委託的專案名稱有點敏感啦、路徑可能有個人姓名之類的），這時就需要調整 Wakatime 的 Config，來把相關的資訊隱藏起來。

Wakatime 的設定會放在 .wakatime.cfg
（Windows 預設會在 C:\Users\{User}\ 或 C:\Users\{User}\.wakatime）

開啟之後就會看見自己的 API Key 等設定，像這樣：

[settings]
api_key = ***

能在 .wakatime.cfg 調整的設定值可以參考官方文檔：USAGE.md

因為這次我們的目標是隱藏資訊，所以會用到的主要是 Hide 四兄弟：

• hide_file_names：隱藏檔案名稱
• hide_branch_names：隱藏分支名稱
• hide_project_names：隱藏專案名稱
• hide_project_folder：隱藏專案資料夾

全打開的話會像這樣：

[settings]
api_key = ***
hide_file_names = true
hide_branch_names = true
hide_project_names = true
hide_project_folder = true

接下來讓我們簡單認識一下它們。

今年難得有機會出國逛逛（雖然是蹭女友公司的員工旅遊，謝謝隔壁老闆！），想說 2024 也要結束了，決定趁著放長假的時候來整理一下。

因為是第一次嘗試發旅遊文，打算順著路上景點丟丟照片、簡單寫一下心得就好。如果之後有繼續發同系列的文章再來慢慢微調吧。說不定就趁勢轉型成旅遊美食部落格了呢

這篇主要會分成三個部份：行前準備、景點紀錄、個人心得。那麼就開始囉！

▲ 海東龍宮寺的燈，放這張當封面只是因為我喜歡。

行前準備

這趟除了出門必須的整頓行李和旅平險以外，還另外買了有交通卡和換匯功能的 WOWPass、提供手機網路的 SKT eSIM，這兩個在 KKday 購買的話可以選擇直接在機場取貨。

但我們交通卡跟 eSIM 取貨的航廈選錯，導致我們要在桃園機場兩個航廈之間來回跑囧，如果有一樣蠢的朋友，提醒一下桃園機場有接駁電車可以往來第一航廈跟第二航廈…

此外要特別注意的應該是地圖 APP 了。

由於韓國的法規限制（主要是因為跟北韓的尷尬狀況），較精密的地理資訊只能放在國內的伺服器。這也導致 Google Map 在韓國……不是那麼好用。

因此要前往韓國之前，通常會在 Naver Map 和 Kakao Map 裡面選一個用

我們這趟用的是 Naver Map，主要是因為 APP 裡至少還有簡中能選。
我們這些英文不好的孩子是這樣的

延伸閱讀：為什麼 Google Maps 在韓國不行用？有什麼替代方案？ - ExitTaiwan

在 VSCode 躺了一段時間的 LiveShare 終於派上了用場，這邊就簡單記錄一篇，方便以後推坑的時候用。

當時的情況是這樣的：在風和日麗的某個下午，我和女友去客美多（Komeda）喝超讚的蜂蜜冰咖啡，順便 看著她加班 悠閒地 Coding。

但麻煩的是，我們倆的座位是面對面的兩人座。所以當我們要邊看程式碼邊溝通時，得先把筆電轉 180 度，或是起身走到另一側，非常不方便

就在來回走了幾趟 漸漸不耐煩 之後，突然想起了香香的 LiveShare

LiveShare 可以讓我們在 VSCode 裡即時線上協作，一起編輯同一份程式碼。
並且也能看見對方游標的動作、在文件上留言互動等等

當我們正在 WFH，或是像這種懶得走過去(?)，但又想要和朋朋們來場 Pair 的時候，LiveShare 就可以派上用場了！

備註：Visual Studio 應該已經內建 LiveShare，
可以從「檔案 > 開始 Live Share 工作階段」來開啟

而 Jetbrains 的朋朋，
請左轉使用 Code with me，同樣也能線上開嚕

這週忙著打黑悟空，簡單記一下前陣子同事遇到的一個場景：

由於曆法的關係，SQL Server 的 datetime 範圍只能從 1753-01-01 開始。
如果我們要寫入 0001-01-01 進去的話就會報錯

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

補充：關於曆法的部份，有興趣的朋友可以參考這篇：
淺談：消失的日期，以關聯式資料庫的日期資料類型為例 - 德瑞克：SQL Server 學習筆記

這時候通常去把資料表欄位改成香香的 datetime2 就可以搞定，爽爽寫入 0001-01-01。

但如果我們正在使用 Dapper，預設會把 C# 的 DateTime 映射到 SQL Server 的 datetime，所以還是會寫入失敗。

這時候我們就需要明確地請 Dapper 幫我們使用 datetime2 來進行處理。

如果傳遞的只是某個參數，使用 DbType 就行了：

var parameters = new DynamicParameters();
parameters.Add("@Birthday", birthday, DbType.DateTime2);

但如果傳遞的是某個 Model 裡的特定欄位呢？例如：

public class HistoricalEvent
{
    public Guid EventId { get; set; }       // 歷史事件的唯一識別碼
    public string Description { get; set; } // 歷史事件的描述
    public DateTime EventDate { get; set; } // 歷史事件發生的日期, 可能早於 1753 年！
}

這種時候就可以使用 AddTypeMap 來調整一下 Dapper 的映射型別。

在做上一篇 IOptions 的筆記時，剛好看到 FeatureManagement 這香東西。
馬上來收錄一篇。順便也簡單整理一下 Feature Flag (≒Feature Toggle) 的介紹。

認識一下 Feature Flag

本部落格秉持著「簡單、友善、我好菜」的精神，按照慣例先簡單介紹一下
已經知道的朋友就可以跳過這個小節，直接前往 #環境準備 囉。

假設我們原本有 Old 邏輯：

Old();

天庭傳來諭令，要我們改成 New 邏輯。這簡單，我們就把 Old 砍掉，換成 New。非常自然，改完就佈版

New();

隔天，天庭又傳來諭令，New 需要調整一下，先不要了
現在我們又需要把 New 邏輯砍掉，讓 Old 邏輯回來。
簡單，但看來我們得再上一版

Old();
// New();

再隔天，大家可能猜到天庭又要幹嘛了，總之又上了一版

// Old();
New();

如此往復三萬八千次，工程師終於受不了了：「俺老孫每天在這切換 Old 跟 New，改完還得佈版，每天搞這些就飽了，我滴媽呀，不幹了」

就在老孫關燈走人的那一瞬間，突然靈光一現：等等，俺加個開關還不行嗎？

因為手邊的 .Net Core API 專案越來越多，蠻常會需要讀 appsetting.json 的 Config，每次都要重找文章有點麻煩，這邊就來筆記一篇。

認識 Appsettings.json

首先簡單介紹一下 appsettings.json 是在幹嘛的：

我們開發的時候，常常會需要先設定好一些服務參數、組態設定之類的設定值，再用這些設定值用來控制我們程式的某些行為。例如：

• 「某功能的上限值是 10」
• 「某項開關在測試環境是 false」
• 「某服務信件的發送者要用 noreply9527」

另外常見的還有連線字串、寫 Log 時的 logging level 等等。

這些設定值會和程式碼拆開，放在設定檔集中管理，再讓程式碼從設定檔讀取相關的設定值來用就好，藉此來把設定值的管理和使用做個關注點分離。

有了設定檔，要調整修改也比較方便：要增加或是修改設定值，都只要先往設定檔衝就行。並且因為兩邊拆開了，我們也就可以簡單地替換這些設定值來應對不同狀況（例如正式環境和測試環境套用兩組不同的設定檔，或是在自己電腦測試的時候快速改個值之類的），彈性可說是 UPUP！

更重要的是，這樣我們就不需要把一大堆東西寫死在程式碼的各個地方，也就不會要改個值還要先搜尋整個專案再一個一個挖出來改了。我按 Shift Ctrl F 已經按到哭

把設定值抽出去丟到設定檔之後，我們就得到了：集中管理設定值、方便修改和替換、減少程式碼中又重複又寫死的臭東西等等好處。

在 .Net Core 的世界裡，這個設定檔就是 appsettings.json。
前面提到的像是日誌等級、功能旗標之類的這些設定值，就會放在 appsettings.json 裡面。

而當我們想要從 appsettings.json 把這些設定值給讀出來的時候，
就可以使用我們的 IOptions 啦！

使用 IOptions 來註冊 & 注入

提醒：這篇的示範會用到一些些 .Net 依賴注入（DI）相關的操作。沒接觸過的朋友可以考慮先閱讀菜雞新訓記：依賴注入

假設我們有個專案，叫做大漢防禦管理系統。專案內的 appsettings.json 有以下內容：

{
  "StrongholdInfo": {
    "Index": 49,
    "Name": "劍閣",
    "Enabled": true, 
    "General": [
      "姜維",
      "廖化",
      "張翼",
      "董厥"
    ]
  }
}

我們正好在開發一個新功能，需要抓到這段設定值。現在就來示範一下：

終於過了！九日沒有慣例的「完成所有成就」的盃，但是放結局獎盃又怕結局名字雷到路過的朋友，就截普通模式通關的盃吧。

按照慣例，留一篇筆記來聊聊心得和體驗，以下有雷。

補充：這篇是我個人遊玩《九日》的心得。
如果你是在找《九日》的白金獎盃攻略，推薦你這篇：【九日】才不是什麼全成就指南呢，哼！

要開玩 DLC 的時候跳了盃，按照慣例來發一下白金心得文～

補充：這篇是我個人遊玩《Fate/Samurai Remnant》的心得。
如果你是在找《Fate/Samurai Remnant》的白金獎盃攻略，推薦你這幾篇

• 【FSR】全成就攻略及部分收集地圖
• 智周萬物（雜記本條目100%全收集）

以下簡單列一下個人覺得的優點（當然有雷）

伊織和 Saber 這對主從很有特色。尤其是主角伊織的成長很有感，也有反應在遊戲性上，後期拿到空之架式的時候割草很爽快。在師徒決戰、伊織使出祕劍的時候，身為 Fate 玩家和動畫宅真的看得非常開心。

除此之外，二週目增加劇情、開始能漸漸窺見到主角內心異常的部份很棒。劍鬼意外地很有魅力，最後的對戰和收尾方式也相當舒服，應該是歷代精神狀況最令人「蛤？」的主角了吧。真不錯。