TL;DR

當發現需要執行很久的 ServiceBus Trigger Function 有重複執行的情況出現時，可以嘗試到官方的 Host.json 設定指引，按照 SDK 版本找到對應的「訊息鎖定最大持續時間」設定，例如 maxAutoLockRenewalDuration（延伸模組 5.x+）或 maxAutoRenewDuration（Functions 2.x），並加入專案的 Host.json

因為 ServiceBus 在傳遞訊息之後，如果超過一段時間（MaxAutoRenewDuration）內沒有得到回應，就會解除信件的鎖並嘗試重新傳遞，這時候如果原先的 Function 仍在執行，就會一前一後重複執行 Function 並發生許多光怪陸離的事，例如寫入兩筆資訊、重複複製資料之類的。

建議如果調整了有 ServiceBus Trigger Function 的 Azure Functions Timeout 設定時，或是發現某支 ServiceBus Trigger 的 Functions 執行時間過長，就要一併注意 MaxAutoRenewDuration 的設定，避免重複執行的情況出現。

嗨各位朋朋，又双叒叕到了「同事推薦的好用工具」時間！

今天要介紹的是 Devtoys：這是一套包含了許多貼心小工具的工具箱，例如 UUID 產生器、Base64 編碼解碼、JSON Format 都可以在這邊找到，省下 Google 這些小工具的時間。

進入官網或 Store 下載之後，點開就能在畫面上看到一整堆小工具：

左邊的工具列也有工具分類和搜尋可以使用，具體有哪些工具這邊就不再贅述。可以到 Github 上看一下工具列表，或是就直接下載下來看看更清楚：

在工作上遇到在兩個 Azure 工具間建立訊息佇列（Message Queue）的需求，因此接觸到了 Azure Service Bus（中文：服務匯流排 燴牛排？），在前輩的協助下建立了一組簡單的 Demo，這就來筆記一下。

什麼是訊息佇列（Message Queue, MQ）

首先讓我們簡單認識一下訊息佇列。假設我們有生產者和消費者兩個服務，其中生產者負責產生資料，而消費者負責消費這些資料：

各位也可以這樣理解：生產者就像是壽司師傅，他會不斷的捏壽司出來；而這時候來了一位大胃王顧客，他就是消費者，會不斷地把壽司吃掉

大概對這兩個角色有點認識就行了。那麼，假設我們有兩組 API 服務：其中一個是負責寫入 Log 的服務，而另一個是產品服務。

產品服務會將 Log 內容丟給 Log 服務去紀錄 Log，這時候產生了這些日誌資料的產品服務就是生產者，而消費這些日誌資料去寫 Log 的服務就是消費者。

也就是：產品服務（生產者） —— 資料 —> Log 服務（消費者） 這樣的狀況。

然而像這樣直接相依的兩個服務，可能就會遇到一些問題：像是消費者突然掛掉，導致生產者也跟著掛掉；又或是消費者的變動和擴展會連帶影響到生產者必須跟著變動等等。

嗨各位朋朋，又到了「同事推薦的好用工具」時間！

今天要推薦的是 Snipaste 這套香香的截圖工具。

在遠古時代的時候，我寫部落格或是測ＡＰＩ要貼圖附結果時，都是使用 Windows 內建的剪取工具（Shift + Win + S）來螢幕截圖，之後貼到小畫家上再進行標記（例如畫底線、紅色框框等等）

但有了 Snispate，這個動作就可以一氣呵成！

介紹一下同事推薦的 Windows 好用工具：方便的快速啟動工具 Wox 以及能快速搜尋檔案的 Everything。

如果你曾經有看著檔案總管轉圈圈、等到火都上來了的經驗；或是懶得伸伸手用滑鼠點資料夾，那也許你能試試 Wox + Everything 的組合來稍稍拯救你的心理健康。

前一次用到 AngleSharp 已經是去年抓網路小說的時候，想不到最近又用上了，乾脆就來筆記一下。

AngleSharp 是一款簡單方便的 C# 爬蟲套件，撈網頁時支援 QuerySelector 的語法來篩選網頁元素，並且撈回來的資料集合也都能用 Linq 操作，讓我們能對爬取的網頁內容快速進行篩選和處理，只需要短短的語法就可以開心抓想要的內容。

說到要示範爬蟲，果然還是要用爬蟲界默認的經典範例 PTT 表特版 來操作（？），接著就讓我們來寫一個簡單的腳本來抓取文章吧！

這是一篇遲來的白金炫耀廢文。

這次的成就對蒐集東西的要求比較少，沒有像黑魂一樣需要在同個場景來回打怪刷道具。通常只需要經歷幾個主要的劇情，然後到各地探險、打倒一些Ｂｏｓｓ，白金獎盃就幾乎到手了。

對我這種一半時間都在到處逛街、動不動迷路然後就被王打死的人來說，實在是福音。畢竟我真的很討厭重複打同隻怪刷東西，去年的黑魂也卡在刷誓約物品很久很久。讚美法環，法環拯救了我的靈魂。

這是俺整理公司新訓內容的第七篇文章，目標是紀錄 Fluent Validation 這個好用套件。

FluentValidation 可以幫我們將 Api 傳入的參數的檢查用更口語、更乾淨的方式去處理，除了可以將檢查邏輯拆分成單獨的 Validator 類別，更提供了許多內建的檢查規則和自訂的彈性，相當方便。

並且因為將參數的檢查邏輯整理出去，就可以和 Controller 本身的工作做簡單的拆分，達到關注點分離的目標。

現在就讓我們來認識一下這個好用工具吧！首先要從很久很久以前開始說起…

前言

西元前的某一天，憂心的皇帝在朝堂內繞著柱子走，突然大臣奪門而入。

大臣：「陛下！敵軍已經攻到國境內啦！」

皇帝大驚：『邊境的那些檢查站和關口難道都陷落了嗎？不可能！』

大臣：「陛下，有內奸和敵國勾結，檢查站完全沒檢查！髒資料已經闖進來了！」

皇帝喊了一聲：『怎麼可能！讓朕看看！』就打開 Controller 和前一個版本的 Git Log，這一看差點就昏了過去。

原來 Controller 的舊程式碼就已經很亂了，檢查參數的條件 if/else 和其他呼叫的方法、組裝資料都雜在一起。結果這次專案改動時，某一行就被內奸改壞了，關鍵的參數竟然沒檢查到！

『可，可惡！來人啊，把工程師推出午門斬首！』

「皇上！他已經離職啦！」

皇帝跌坐在地，懊悔地說：『如果當初有好好把檢查參數跟實際組資料的部份都拆開的話，也許就不會這樣了…』

「是啊，如果我們有用 Fluent Validation…！」

專案現況

大臣提到的 FluentValidation 是一套能幫我們把傳入參數的分離出去、用更口語化的方式去撰寫的工具。

……如果當時他們有使用 Fluent Validation 來把驗證的邏輯和規則跟原本很亂的 Controller 切分的話，說不定就能及時發現問題吧，大概。

為了不要步上他們的後塵，就讓我們直接回到本系列的卡牌管理 API 服務來加上這個好用工具吧！

Omni 是一款 Chrome 的擴充功能。它能夠讓你用快捷鍵叫出搜尋框，並直接搜尋當前開啟的分頁、書籤、歷史紀錄等等。

這個工具適合：

• 習慣分頁開很多的人，尤其是像我這種能分頁分組摺疊之後就開更多
• 懶得用滑鼠去找分頁、也懶得 Ctrl Tab 逐個分頁切換的人
• 書籤存了一大堆但每次都忘記放在哪裡，最後還是重新搜尋一次的人
• 想在瀏覽器有方便的搜尋框（就像 Mac 的 Alfred 或 Windows 的 Powertoy 那樣）
• 即使只有三個分頁，還是要在朋友面前打字裝潮的人

從朋友那兒聽到了用 AutoMapper 把串列成員物件攤平成一組串列的問題，發現了 ConvertUsing 的好用，這邊就紀錄一下。

事情是這樣的，首先有一個 Parent 類別，其中包含著兩個成員：Id 和串列的 Child 類別，而 Child 類別則只有一個成員 Val，如下：

public class Parent
{
    public int Id { get; set; }
    public IEnumerable<Child> Children { get; set; }
}

public class Child
{
    public double Val { get; set; }
}

另外還有一個 Target 類別，包含 Id 和 Val 兩個成員：

public class Target
{
    public int Id { get; set; }
    public double Val { get; set; }
}

現在的目標是：將一個有著 Child 串列的 Parent 映射成 Target 串列。

也就是說，假設我們的來源是這樣子：

var boo = new Parent
{
    Id = 1,
    Children = new List<Child>
    {
        new Child { Val = 1 },
        new Child { Val = 2 },
    }
};

希望可以變成這樣子：

var expect = new List<Target>
{
    new Target { Id = 1, Val = 1 },
    new Target { Id = 1, Val = 2 },
};

我之前遇到的時候，會直覺地將 Child 直接 Map 到 Target，再對 Target 做個 Foreach 來補上 Parent 的 Id。

這次和朋友討論時，提到了另一個角度：雖然這樣的做法相當直覺快速，但其實並不能保證後續維護的人使用這組 Mappings 時，都知道這裡要補資料；況且此處的對應關係的確是 Parent 到 List<Target>，並非 Child 到 Target 而已，直覺上就怪怪的。若要解決這個問題，可能就要再包裝一層，把 Mapper 隔離出去做個轉換器之類的。

但想想又覺得 AutoMapper 不可能沒提供這個場景能使用的方法才對，最後餵狗發現 AutoMapper 確實有提供 ConvertUsing 來讓我們客製化轉換過程，這邊就紀錄一下。