I am PC

Postman 幫助開發人員在開發時期能夠快速測試 Web API 的功能是否正確運作，而很多時候我們的 API 設計，會因為安全性的關係，在呼叫時必須夾帶 Token 資訊，以驗證呼叫端是否有權限使用該 API，所以會先呼叫一隻驗證身份並回傳 Token 的 API，再將該 Token 放到其他呼叫 API 的 HTTP Request 中去使用，這篇將介紹兩種在此情境下，加速測試時期使用 Token 的作法。

Azure 認知服務平台提供了 AI as a Platform 的一站式服務，其中提供了多種認知服務，例如電腦視覺、語音服務、文字分析、異常偵測等等，官方也提供了多種程式語言的 SDK，讓開發者可以更容易地使用 SDK 來呼叫認知服務的 REST API，輕鬆應用 AI 讓應用程式變得更智能。這篇來玩玩將語音即時轉譯為文字的 Speech Cognitive Service。

Azure 提供了豐富的雲端資源，而為了讓全球的使用者能更享受更低的網路延遲，Azure 截至目前為止，在全球提供 54 個資料中心（或稱地區），我們可以把應用程式放在離使用者相對靠近的地方，提供更高效率的服務，所以在設定 Azure 上的資源時，要放在哪個地區就要好好想想了，那麼要如何得知這 54 個地區的清單及地理資訊呢？

當我們使用 Visual Studio 開發 ASP.NET Core 網站的時候，執行偵錯時，Visual Studio 會去讀取 launchSettings.json 設定檔，並根據所提供的設定值來啟動網站，但裡面有個屬性 commandName 其實很關鍵，關係到 Visual Studio 是”如何”啟動網站的。

相信還有很多企業內部的網頁應用程式還是只能用 IE 來開啟使用，針對這點 Microsoft Edge (Chromium) 有提供 IE Mode，讓你可以在 Microsoft Edge 中使用 IE 開啟 IE Only 的網頁，而不脫離整個瀏覽器介面，對於不想要在多個應用程式切換來切換去的使用者來說，相當便利。

之前寫過一篇在 .NET Core 主控台應用程式中全域捕捉未處理的例外，主要是透過 .NET 應用程式的 AppDomain 類別下的 UnhandledException 來添加客製的例外處理，然而在 ASP.NET Core 專案中，內部會是個小型 Kestrel 網頁伺服器在運作，因此大多數的 Exception 是不會往上傳遞並被 AppDomain.UnhandledException 接收到，所以這個方式是行不通的。但我們可以透過 ASP.NET Core 專案架構中的中介程序，捕捉發生在 HTTP Context 下的例外錯誤，這篇來做看看如何在中介程序（Middleware）中全域處理例外。

在開發 Web API 的時候你可能會遇到這種情境，想要收集所有對我們網站所發起的 HTTP 要求，從呼叫 API 的網址、HTTP 方法、甚至 HTTP 要求的內容（Request Body）等，要把這些資訊儲存下來，供之後分析使用，以前你可能會透過 IIS Log 來做，現在在 ASP.NET Core 的程式架構中，我們可以在專案架構的中介程序中，攔截 HTTP 資訊，來做任何我們想要做的事。

一直以來，當要處理 JSON 的時候 Json.NET 是最佳的幫手，有非常順手的 API 和功能，讓開發者輕鬆處理 JSON 的大小事，甚至在 .NET 的各種函示庫、框架中都有用到，但當許多專案相依於此函示庫時，只要版本一更新，很容易造成許多專案要更著變動，造成相依的函示庫版本很難掌握，因此 .NET Team 發展了 System.Text.Json 來在 .NET 專案中取代 Json.NET 的依賴。

最近在玩 Windows Terminal 搭配 WLS 的時候，遇到一件和換行字元有關的小狀況，讓我無法順利使用 .bash_aliases，簡單說就是 Windows 和 Linux 的換行字元是不一樣的。

開發 .NET 應用程式時，我們可以在程式碼中使用 try...catch 語法來捕捉例外，並對異常進行處理，但有時候總會有漏網之魚，最常見的作法是在程式碼的最外層來加上 try...catch 語法來捕捉例外，但這樣程式碼有點不夠優雅，如果能在應用程式定義域中來處理，程式碼會變得更漂亮。