[Linux] 跨平台 SSH Client 工具 - Termius

前言
身為一個 Windos 重度用戶來說，近期要切換到 Linux 環境開發無疑是個重大挑戰，建置 CentOS 環境的第一步必須先連到遠端的 Linux Server，同事大力推薦  Terminus ，此工具支援 mac 以及 windows 且適用於 desktop 以及 mobile 版本，重點還免費，對 Linux 新手當然是一大福音，這篇簡單紀錄 Terminus 工具的安裝與使用方式，分享給跟我對於 Linux 還在摸索的新手朋友們。

安裝 Termius

安裝傳送門 : 請點我 
Step 1 : 公司筆電是 Windows 因此下載 Termius for Windows 版本
另外也同時支援 Mobile、Mac、Linux，如果在 Windows 使用系統會同步至 mobile 版本

Step 2 : 點選取得，會開始進行下載

如果是第一次使用，會建議要求註冊帳號的動作

Step 3 : 安裝完畢之後，第一次使用會跳出介紹說明

使用 Termius

主要視窗畫面如上，畫面我覺得是相當不賴
如果不喜歡深色系的話，可以點選左上角 > Terminal，選擇自己喜歡的顏色或是字形大小

新增連線
在主視窗右下角，點選  +NEW HOST 

輸入遠端資訊資訊，名稱、IP 相關設定，輸入完畢後按下右上角 Save

新增完畢後，點擊後會跳出輸入帳號密碼

即可順利進去 Linux server

結語
好的，以上是 Termius 最簡單的操作方式，使用上相當容易上手沒太多難度，已列入我個人私藏工具之一，工具有提供更多好用的功能與說明，如果想了解更多資訊可以了解 Termius 官網介紹

Read More

[conference] MOPCON 2022 - 無密碼時代來臨 ? 初探 FIDO 驗證標準

分享心得
這幾年無密碼議題越來越夯，去年在 Apple 開發者大會也有 Presskey 讓相關議題更火紅，在去年初就有聽主管聽到 FIDO 相關技術議題，一直希望有時間研究相關議題在公司產品整合既有服務，於是自己就花自己時間研究很多這好玩的議題，整理完後並在 Mobile Open Platform Conference 分享最近研究的驗證議題 《FIDO》，現場分享時隨著人數暴增緊張程度跟說話速度也加快，自己並未想到會有這麼多人會來聽，也因為緊急過頭原本提早結束，提早進入 QA 階段，希望有在場聽得受眾聽完有幫助，對於 QA 的回覆也有幫助到各位，如果對投影片內有任何 feedback 歡迎留言或私訊給我

議程介紹
主題 : 無密碼時代來臨 ? 初探 FIDO 驗證標準

密碼一直是讓人又愛又恨的東西，隨著網路的世界越來越複雜，對於密碼複雜度與安全性的要求也越來越高，不時資安大廠都會發表關於密碼外洩的新聞，使用者為了方便使用相同帳密遭到破解造成的經濟損失不計其數，有沒有一個更好更安全的方式可以解決困擾已久問題呢 ?
無密碼認證（Passwordless Authentication）技術在這幾年越來越多人開始討論，在今年全球密碼日當天，Google、微軟、蘋果共同發出聲明將支持 ( FIDO Fast Identity Online）身分認證方式，為何科技大廠會選擇 FIDO 網路身分驗證呢 ? 其背後的原理到底是如何做到無密碼登入的呢 ? 手機裝置要如何支援呢 ? 在這 Session 預計與大家分享
1. 甚麼是 FIDO
2. 原理與特性
3. FIDO 的下一步

主辦單位 : MOPCON
議程表 : 連結
投影片 : 連結

Read More

[conference] DevopsDays 2022 - 可觀測性(Observability)的實踐

分享心得
這兩年因緣際會接觸可觀測性(Observability)這議題，研究後覺得挺有趣於是不要臉的報名 DevopsDays Taipei 研討會分享，也很幸運地獲得評審青睞有機會在今年 DevopsDays 2022 分享，這次分享有兩個大的挑戰分別是議程內容與時間
1. 議程內容 : 指的是在過去雖然有在 .NET Conf 2021 分享過一小段，但要在這麼大的場合要把 Observability 說明清楚是個不容易的事情，尤其是這議題在國內比較少看到有人提到，因此很多時間在看國外研討會影片或是文章來釐清自己的觀念與想法。
2. 時間 : 由於議題只有 25 分鐘，可觀測性到底是甚麼 ? 想要解決甚麼問題 ? 它與監控差異到底在哪裡呢 ? 觀念說明完再提到實踐工具有哪些，要在短時間把資訊整理清楚並說讓第一次的會眾了解是個很大的挑戰，也有試著把整理的內容給幾位強者同事分享看是否哪裡不清楚的地方，強者同事也聽完給很多實用的建議，整個投影片內容修改不下 20 次才完成初版 (頭髮都白了 XDDD
由於之前都太緊張所以都沒注意到場地，當天實際閒晃到場地才傻眼過去分享都是比較小場地這次被安排到 ABC 會議室，心裡只能默默祈禱今天準備內容不要太掉漆就好，幸好過程中還算順利準備的議題都有分享到，會後也有很多朋友詢問相關議題與實作細節，護國神山也有 HR 與主管來找我聊聊(但太緊張完全忘記說啥 XDD)，結束緊張又刺激的一天。

一個月後傍晚收到 DevOpsDays Taipei 活動的議程問卷調查，過去參加 DevOpsDays 都是站在台下當聽眾，沒想到會有一天站在 #DevOpsDays 台上分享感到很開心，感謝當天議程與會者的建議跟留言，也期許自己未來還有機會分享自己研究的心得 :)

議程介紹
主題 : 可觀測性(Observability)的實踐

隨著科技不斷的進步與雲端的普及，企業軟體在架構的演進與應用程式開發的速度與越來越快，隨之而來的挑戰是開發人員如何針對這些服務進行更好的監控（Monitor），以提供高可用性的服務。
可觀測性（Observability）在這幾年越來越多人在討論，甚至在 CNCF 還有專區介紹 Observability 相關的工具，可觀測性與監控到底有何不同？為何國外大型研討會與雲端廠商都開始提到可觀測性？
這主題將會分享以下內容
➊ 什麼是 Observability ?
➋ 可觀測性 vs 監控 
➌ 實踐工具

主辦單位 : DevOpsDays Taipei
議程表 : 連結
共筆 : https://hackmd.io/@DevOpsDay/2022/%2F%40DevOpsDay%2FBkLestagj
投影片 : 連結

Read More

[Testing] Playwright : 現代化的跨瀏覽器自動化測試框架

前言
在前一篇 [Tool] END-TO-END Test 測試工具 - Playwright 介紹好用的 open source 工具 Playwright，過了一年 Playwright 功能越來越強大自己也花了點時間研究，這篇文章就來針對這套好用的開源工具繼續推坑，若有問題歡迎提出來一起討論。

E2E Testing
在提到 Playwright 之前，想要先提一下什麼是 end to end testing，查詢 wiki 可以得到下列解釋

End-to-End Testing (E2E testing) refers to a software testing method that involves testing an application’s workflow from beginning to end. This method basically aims to replicate real user scenarios so that the system can be validated for integration and Data Integrity.

它是軟體開發生命週期(SDLC)中使用的一種方法，目標是模擬真實用戶場景從頭到尾的樣子，目的是為了確保子系統案預期工具與行為。上述聽起來可能會覺得很抽象，或者是可能在過去工作上聽過很多不同的名詞，聽完上述描述可能更容易讓人混淆，像是單元測試、E2E 測試、整合測試與 UI 測試，那麼這幾個有什麼不同呢 ? 我們可以透過這張圖來讓大家更容易了解這之間的差異

圖片來源 : Microservices Testing Strategies, Types & Tools: A Complete Guide

這是一張經典的測試金三角圖，裡面說明了單元測試、整合測試、E2E 測試、與 UI 測試之間的差異

• 單元測試 : 紅色框部分，開發人員在撰寫程式時針對模組進行驗證的測試
• 整合測試 : 藍色框部分，不同模組之間呼叫行為是否符合預期，上圖例子是前端與後端開發完後進行測試動作
• E2E 測試 : 橘色框部分，上圖例子是前端與後端開發完後，再與其他服務(Service) 及資料庫多個服務進行測試
• UI 測試 : 灰色框部分，上圖例子是使用 Client App 來呼叫後面服務(Service)，驗證功能是否如預期

核心概念都是透過「預期結果（expect）」和「真實結果」去做比對，驗證兩者是否相同，不同測試就會驗證失敗再請工程師去察看哪邊出了問題要進行修正的動作。了解這些測試可能的差異之後，在實際執行上還要考慮的點是測試範圍、時間、成本等三個重要因素，因為各自所測試的守備範圍與顆粒度不同，勢必也會影響到測試人員或是開發人員所花費的時間，進而也會有執行成本的議題產生，因此在執行上也須要多考量這些因素。

E2E Testing 挑戰
在執行上可能會遇到很多大大小小的挑戰，我這裡列出我覺得在執行上可能比較重要的兩點 : 瀏覽器支援與螢幕解析度

瀏覽器支援

由於使用者習慣的不同，所在國家政策與安全考量不同，因此在瀏覽器的分布上是相對沒那麼集中，如果要在測試時支援多個瀏覽器可能遇到的挑戰是在測試時就要在不同的瀏覽器上進行測試，來看其功能與 UI畫面是否與預期長的相同，功能不會有異常與意外，要花費的時間勢必要多少時間。

螢幕解析度

談完瀏覽器，下一個要關心的議題是螢幕解析度的部分。越來越多人使用手機與平板來瀏覽網頁，大家在使用的 Device 的螢幕尺寸與解析度都不相同，因此開發出來的網頁要如何在不同的螢幕正常呈現也是很重要的。
圖片來源 : Infographic: Fragmentation in OS, browsers, and devices

簡單總結一下 E2E 測試會遇到的挑戰

• 瀏覽器 : 瀏覽器的種類型態不同，開如何支援與決定不支援那些 ?
• 學習曲線 : 簡單來說就是 E2E 測試工具好不好學，是不是容易上手對團隊來說是個重要的議題
• 穩定性 : E2E 測試可能是一直需要持續修改的，要在每次執行的過程可以重複執行不出錯，資料的準備也是重要的關鍵
• 維護成本 : 隨著產品功能不斷的迭代，程式碼會一直不斷的修改，要如何確保測試案例可以一直正常執行，或是當心功能上線時可以快速進行相關調整也很重要

Playwright
Playwright 是一套現代化可靠的 e2e 測試工具，他是由微軟開源的，第一個版本是由微軟在 2019 年底 release，經過兩年的時間越來越火紅。根據熱門 Best of JS 網站的資料顯示，在 Testing tools 中 Playwright 佔據第一名，可以說是相當地受到開發者的歡迎與喜愛。

Why Playwright ?
Playwright 有很多強大的功能與特性，我這邊有整理自己覺得對開發者來說重要的六大特性，分別是

• Cross Browser
• Cross Language
• Auto Retry/wait
• Browser Contexts
• Tracing
• Powerful Tooling

接下來依據這六個特性來做簡單的說明

Cross Browser

Playwright 支援了所有現代化的 render 引擎，包括 Chromium, WebKit 和 Firefox，因此幾個主流的瀏覽器像是 Chrome、Edge、Firefox、Opera 都支援。如果要對網頁做相容信測試 Playwright 是一个很好的選擇。也解決了前面提到 E2E 挑戰的第一點。

Cross Language
支援多程式語言，提供多種程式語言的 API，包括 TypeScript、JavaScript、Python、.NET 和 Java。跨程式語言帶來甚麼好處呢 ? 可以選擇自己熟悉的程式語言開發測試的腳本。這邊官方有更詳細的說明，詳細可以到 playwright.dev 看更詳細的資料。

Auto Retry/wait

舉個實際案例，假設我們有個登入頁面，登入 page 有帳號密碼欄位要輸入其中帳號欄位要輸入時會自動檢查格式內容是否正確，檢查邏輯是在檢查格式過程中登入按鈕是沒辦法輸入的。
一般來說，我們所撰寫的測試腳本會按照你的程式碼逐行往下執行(肉眼跟不上的速度)，因此在沒有 autowait 功能的情況底下，這種測試案例在執行上是很容易執行失敗的(因為無法按下登入按鈕)，失敗原因是前面提到的預期結果與實際測試結果不同。在過去可能會在測試腳本遇到時等待一段時間再繼續 (thread.sleep n 秒)，等待一段時間之後再按下按鈕，但這個 N 秒在每個環境可能會有所不同需要團隊討論，太長會影響測試腳本的執行總時間，太短則很容易遇到測試腳本執行失敗的狀況，playwright 內建 auto wait 功能讓大家可以忽略這件事情，可以更專注的撰寫重要邏輯上。

Browser Contexts

它能夠在單個瀏覽器中提供互相隔離的執行環境，特別是在測試多個頁面時這個特性是相當重要的，可以透過腳本很方便的實現網頁頻繁的切換。每個頁面可以在各自的 context 中執行不會互相干擾，包括 cookies 等資訊都是隔離開的。
上述內容或許有點抽象，舉個實際的例子可能會比較好理解，假設公司產品是開發類似通訊軟體類(IM)，要測試 Web 版的聊天功能，在這情境下就需要開啟兩個聊天畫面來測試聊天功能是否正常。腳本上可能是開啟兩個瀏覽器做登入，登入之後透過 A 傳給 B 看訊息內容是否有正確的送達。在過去沒有此功能可能要先登出 A 在重新登入 B 進行驗證。現在有這功能就可以省下登入登出時間快速驗證效果與功能正確性。

Tracing
跑測試時可能會遇到當你的測試案例執行失敗，要如何快速的定位問題，並提供給開發團隊的 RD 同仁呢 ?
反過來說，如果可以知道在哪個步驟或是地方知道執行之敗，這樣對於盤查問題跟問題定位上會有更大的幫助，開發團隊可以更快地找到哪邊有問題，並針對有問題的地方盤查傳遞的 http request 內容或是 request body 參數是甚麼，可以更快速的找到問題並進行修正，對於修復問題的時間可以大大的提升。playwright 有提供 Trace Viewer 強大的 GUI Tools，提供截圖、action、source code 及 screenshots 等資訊讓開發人員可以定位問題，詳細可以參考 trace-viewer。

Powerful Tooling
Test Generator : 測試團隊可能相較於開發人員，有些是比較沒有程式開發相關背景的。playwright 提供 Codegen 功能，可以透過瀏覽器錄製測試步驟，產生程式碼。程式碼可以在工具平台上重複的進行測試的動作，對於測試人員的 Loading 也相對較輕鬆。
另外也提供測試報告，團隊可以透過測試報告來了解一些潛在的問題，舉例說當你發現測試時間過長，就可以透過測試報告觀看每一段所花費多久，找到可能可以改善的地方或是優化的點。


Demo : Test Generator
來透過 codegen 功能來試試看它是如何產生代馬的，在此步驟可以先開啟命令提示字元輸入安裝 playwright 指令

npx playwright install

接著輸入內建的 codegen 指令，來錄製操作步驟與產生其相關的語法

npx playwright codegen demo.playwright.dev/todomvc

會跳出瀏覽器視窗，接著可以在是窗框中輸入 keyword，在這案例中我輸入 test、this is a book，可以發現在右方框中會同步產生相關語法，如下圖所示

你也可以錄製在 google 輸入關鍵字，接著再去點選特定的查詢結果，下面代碼是透過錄製開啟 google 首頁，接著查詢 COSCUP MEETUP 研討會連結，進入到連結後找到 "" 分享 SESSION 內容頁面，並將其結果儲存下來

public static async Task Main()
{
	await GoogleCOSCUP();
}

private static async Task GoogleCOSCUP()
{
	using var playwright = await Playwright.CreateAsync();
	await using var browser = await playwright.Chromium.LaunchAsync(new BrowserTypeLaunchOptions
	{
		Headless = false,
	});
	var context = await browser.NewContextAsync();
	// Open new page
	var page = await context.NewPageAsync();
	// Go to https://www.google.com/?gws_rd=ssl
	await page.GotoAsync("https://www.google.com/?gws_rd=ssl");
	// Click [aria-label="搜尋"]
	await page.Locator("[aria-label=\"搜尋\"]").ClickAsync();
	// Fill [aria-label="搜尋"]
	await page.Locator("[aria-label=\"搜尋\"]").FillAsync("coscup");
	// Press Enter
	await page.Locator("[aria-label=\"搜尋\"]").PressAsync("Enter");
	//await page.WaitForURLAsync("https://www.google.com/search?q=coscup&source=hp&ei=yvHlYsjhDbmRr7wPt4OysAI&iflsig=AJiK0e8AAAAAYuX_2qYZgkQ_Hm0nRenoqQN3m5Lu5HiY&ved=0ahUKEwjI7q_lkqL5AhW5yIsBHbeBDCYQ4dUDCAo&uact=5&oq=coscup&gs_lcp=Cgdnd3Mtd2l6EAMyCwgAEIAEELEDEIMBMgQIABADMgUIABCABDIECAAQAzIECAAQAzIECAAQAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQ6CAgAEIAEELEDOhEILhCABBCxAxCDARDHARDRAzoOCC4QgAQQsQMQxwEQ0QM6CwguEIAEELEDEIMBOhQILhCABBCxAxCDARDHARDRAxDUAjoICAAQsQMQgwE6CwguEIAEEMcBEK8BUL4EWJcTYNIaaAJwAHgAgAGZAYgB0QWSAQM0LjOYAQCgAQGwAQA&sclient=gws-wiz");
	// Click text=COSCUP 2022 | Conference for Open Source Coders, Users ...
	await page.Locator("text=COSCUP 2022 | Conference for Open Source Coders, Users ...").ClickAsync();
	await page.WaitForURLAsync("https://coscup.org/2022/zh-TW/");
	// Click a:has-text("議程表") >> nth=1
	await page.Locator("a:has-text(\"議程表\")").Nth(1).ClickAsync();
	await page.WaitForURLAsync("https://coscup.org/2022/zh-TW/session");
	// Click text=2022 / 7 / 31
	await page.Locator("text=2022 / 7 / 31").ClickAsync();
	// Click text=現代化 End to End 測試工具 : Playwright
	await page.Locator("text=現代化 End to End 測試工具 : Playwright").ClickAsync();
	await page.WaitForURLAsync("https://coscup.org/2022/zh-TW/session/3QNTQT");

	await context.Tracing.StopAsync(new()
	{
		Path = "trace.zip"
	});

}

程式說明

• Line 9 : Headless，透過步調用瀏覽器的渲染引擎，可以提高其腳本執行速度與測試效率
• Line 17 : 開啟 Google 首頁
• Line 21 : 輸入 COSCUP 並按下搜尋
• Line 26 : 點擊 COSCUP 2022 連結
• Line 29 & 32 : 點擊議程表 & 選擇 7/31 日期
• Line 37 : 將其結果儲存下來，檔名為 Trace.zip

以上簡單介紹到這邊，有興趣的朋友歡迎可以試試看 :)

感想
如果想了解更多，可以參考 #30DaysOfPlaywright 日後有機會可以做進一步的研究跟分享，以上如果有不清楚的地方歡迎一起討論，hope it helps !

參考
playwright.dev

Read More

[conference] COSCUP 2022 | 現代化 End to End 測試工具 : Playwright

分享心得
去年有幸在 COSCUP 分享研究的權限套件 Casbin，今年也很幸運的投稿 end to end 測試工具 playwright 有徵選上，跟去年不一樣的是去年是因為疫情關係所以都是透過線上方式進行，今年是直接改為線下進行，雖然說時間是 30 分鐘，但要在這麼多人面前分享對自己來說也是一個很大的挑戰，也很 lucky 的最後完整的分享完也沒大問題，對自己來說也是逐步的挑戰自己的過程，也希望參加此議程的朋友們可以在有所收穫，也非常感謝 COSCUP 主辦當為給我這機會可以在台灣最大的 Open Source 年會上進行分享，以下是分享的內容與影片連結，若有任何問題歡迎提出來一起討論。

議程介紹
主題 : 現代化 End to End 測試工具 : Playwright

質量對於產品交付是重要的指標，如何節省手動測試的時間是個重要的議題之一，可以藉助自動化工具可以幫助達到其目標。
在 Web 測試中如何面對瀏覽器的多樣化是個很大的挑戰，這次要介紹的開源框架是 Playwright，支援跨平台測試，支援 Firefox、Webkit、Chromium 等 Web 三大瀏覽器核心。降低開發者在自動化測試的難度與跨程式語言的挑戰。
在本議程會與大家分享下面幾個議題
➊ Playwright 是甚麼 ?
➋ Playwright 特性與解決什麼問題 ?
➌ Demo

主辦單位 : COSCUP 開源人年會
COSCUP 是由台灣開放原始碼社群聯合推動的年度研討會，起源於 2006年，是台灣自由軟體運動 (FOSSM) 重要的推動者之一。活動包括有講座、攤位、社團同樂會等，除了邀請國際的重量級演講者之外，台灣本土的自由軟體推動者也經常在此發表演說，會議的發起人、工作人員與講者都是志願參與的志工，所有議程都是免費參加。 此外，今年 COSCUP 很榮幸的邀請到 RubyConf Taiwan 合作舉辦聯合研討會，並且如往常一樣，徵求各式各樣不同的 Open Source 相關稿件，歡迎有興趣的你/妳共襄盛舉。 開發者 (Coders)、使用者 (Users) 和推廣者 (Promoters) 是讓自由及開放原始碼軟體發光發熱的三大支柱，這個研討會就是專為這三種人舉辦的：你可以是 A 軟體的開發者、B 軟體的推廣者、C 軟體的使用者，不論你是已經踏入自由及開放原始碼軟體領域，還是一直站在門口不知如何入門，歡迎你來參加 COSCUP — Conference for Open Source Coders, Users and Promoters!

議程表 : 連結
共筆 : https://hackmd.io/@coscup/ByiRHCyTc/%2F%40coscup%2FBkbaSCJac
投影片 : 連結

Read More

[AzureDevops] 初探 Wiki 文件管理

前言
隨著團隊成員越來越多，在人員越來越多發現有些基本知識像是 Code Review 規範或是新人報到流程沒有系統化整理起來，因此需要一個知識管理平台存放相關 Domain 與流程相關文件，於是開始 suvery 知識管理平台發現在 Azure Devops Wiki 符合好管理、版控紀錄、可以使用 markdown 方式撰寫十分方便，可以做為團隊上 KM (knowledge management) 文件中心，這篇文章就來簡單介紹小小的使用心得。

建立 Wiki Project
首先在 Azure Devops 建立完 Demo Team Knowledge Management 專案，接著建立 wiki 專案，到左邊點擊 create project wiki

接著會請你建立第一個 wiki page，在這編輯視窗是可以透過 Markdown 格式輸入你整理好的資訊文件內容，接著就完成了第一頁 wiki page。

關閉 Azure Devops Service
建立完專案後，如果專案目的是專門給 Knowkedge Management 文件管理使用的話，可以考慮關閉專案中其他 Azure Devops Service 像是 Board、Pipeline、Test Plans 等服務，選單就會比較乾淨些。關閉方式可以透過到 Project setting > Azure Devops Service > Off service

關閉之後，在 Project 左方選單就僅會呈現必需的資訊 (非必要，視主管與團隊需求而定)

設定 Access level
建立完專案後，必須在設定用戶權限才可以具有訪問專案的權限，如果沒有特別設定的情況下預計權限會是 Stakeholder，可以訪問到的功能是 Azure Boards 和 Azure Pipelines 部分功能；要讓團隊成員可以編輯則要將訪問權限設定為 Basic，就可以讀取大部分的 Azure Devops 服務，詳細訪問級別權限與讀取服務可以參考 About access levels

Clone Wiki
在編輯上有兩種方式，你可以選擇直接在 Azure Devops 上直接透過畫面編輯，或是把專案直接 Clone 下來 (背後也是 Git Repo)，Clone 功能可以透過專案點擊右邊會跳出 more action，接著選擇 Clone wiki 複製 Git repo 位置，再透過你熟悉的工具進行編輯的動作

Wiki Page
新增 page
可以透過下方的 new page 進行新增 wiki page 的動作，如果新增完頁面後想要新增子頁面也可以透過 add sub-page 動作新增，在 page title 部分是有限制的，wiki page 名字是不能重複(唯一性)，不能與其他已存在的 wiki page name 重複；另外在 page title 上如果輸入空白的話系統預設會用 - 來取代。

如果要進行頁面的排序調整，可以透過滑鼠拖拉的方式在 Azure Devops 介面直接調整；若是使用 Git repo 則可以開啟 .order 檔案透過手動修改排序方式達到你要調整的排序。

Page 編輯

在編輯文字內容上是使用 Markdown 風格，關於 markdown 基本語法詳細說明可以參考微軟官方文件 Syntax guidance for basic Markdown usage，這裡就不在多加說明，這裡我就列出個人覺得實用的幾個功能
Table of content (TOC)
當你的內容需要標題時可以在指定位置插入 TOC，讓在閱讀時可以透過導引快速定位你要找的資訊內容，對於文件內容過長時很好用

Insert Mermaid diagram
如果文件中需要說明模組之間的互動關係，或是畫流程圖時，可能在過去都是透過軟體繪製，像是之前在部落格介紹過的 PlantUML - 在 Visual Studio Code 繪製 UML 圖，再將畫完的結果截圖貼在文件內容中。使用 Mermaid 則可以替你省下這些工作

舉例來說上述內容簡單描述 User 發送請求，透過應用程式讀取資料庫的流程，在 Mermaid 使用下列語法描述

::: mermaid
 graph LR;
 A[User] --> B[Application] --> C[Database]
:::

可以在編輯視窗中劃出所需要的流程圖，可以說是相當的方便。目前內建支援三種圖形分別是循序圖、流程圖與甘特圖，如果想了解更多細節內容可以參考官方文件 add-mermaid-diagrams-to-a-wiki-page 說明。

感想
工欲善其事，必先利其器。在過去開發或是接觸到不同的專案時，最讓人害怕的就是沒有文件說明要重新摸索，可能會花費較長的時間來整理前人留下來的祖產內容，但部分開發人員對於撰寫文件也是不熟悉的，如果可以讓撰寫文件這件事變得容易上手，就有機會達到這兩者之間的平衡。若是你的團隊也有類似的困擾時不妨可以參考 Azure Devops Wiki 的服務，讓知識文件化對團隊夥伴帶來幫助，hope it help :D

參考
Add and edit wiki pages
Syntax guidance for Markdown usage in Wiki

Read More

[sharing] 開發經驗分享 - Web API 從 0 到 1

分享
最近在整理筆電資料，不小心發現過去在某公司開發經驗的投影片，從一開始的建立 API Team 的緣由到後續遇到諸多線上 Production 問題的寶貴經驗，從無到有在到上線後的效能問題，再來思考如何建立監控機制來確保 API 的穩定性與問題追蹤，或許這些解決方案在現在可能都是 common sense 但在當時年少無知時是加班熬夜很多個夜晚所解決的，現在回想起來都是挺有趣的但是在問題發生當下是辛苦的，在整理完後當時在前公司 T 社也有分享給全公司的夥伴交流，希望有些踩過的雷年輕的夥伴們不要再重複遇到，提供給有興趣的朋友也希望可以幫助到各位 :)

Read More

[Azure] App Service Diagnostics - Collect Memory Dump

前言
前兩篇分別介紹了 App Service Diagnostics 中的 Collect .Net Profiler Trace 與 Auto heal，分別都可以透過工具來蒐集雲端伺服器的緩慢問題分析與蒐集記憶體資訊，這一篇則是介紹如何 dump 目前伺服器 memory 的資料，以及有多個伺服器的時候該如何抓取特定的 Server memory data。若對於上述內容有問題或是不清楚的地方，歡迎提出來一起討論。

Collect Memory Dump
在 Azure 上提供非常多的分析工具可以協助開發人員找到應用程式的問題，應用程式出問題不管在地端的機房或是雲端上都是有可能會發生的，在過去服務還沒上到雲端時是透過一些工具，像之前黑暗大就寫過 ASP.NET CPU 飆高問題之傻瓜分析工具－DebugDiag Tools 找到應用程式 Crash 或是緩慢原因，今天要分享的是 Memory Dump 把應用程式當下的記憶體 clone 一份下來，再進行問題的盤查或是分析，另外在 Memory Dump 之前提醒事項如下

• While collecting the memory dump, a clone of your app's process is created so the impact on the site availability is negligible.
• Dumps are collected for the worker process (w3wp.exe) and child processes of the worker process.
• Size of the memory dump is directly proportional to the process size, so processes consuming more memory will take longer to be dumped.
• Your App will not be restarted as a result of collecting the memory dump.

白話來說，Memory Dump 會 Clone 當下應用程式 (w3wp.exe) Process 的資訊，花費時間多寡取決於 Process 用量多寡決定，應用程式不會被重啟。了解以上資訊後，就來看看如何在 Azure 設定 Memory Dump
Step 1 : 開啟 App Service
Step 2 : 點選左邊清單的 Diagnose and solve problems 功能
Step 3 : 在右邊框輸入 "點選 Memory Dump"

Step 4 : 選擇 Dump 下來的檔案放置的位置，如果之前沒執行過需要設定 Dump file 要存放的位置

Step 5 : 接著下一步，Mode 部分是選擇要蒐集 Dump Data 或者是除了 Dump 之外還希望進行 Memory 的分析，如果 Server 是多台機器的話，下面會列出目前的機器有哪些提供使用者選擇所要蒐集的 Instance

另外，如果之前有執行過蒐集過 Dump 的動作，下方也會列出之前手動或是自動蒐集的 Dump 檔案清單

Step 6 : 按下 Collect MemoryDump 按鈕之後，會開始蒐集應用程式的 Memory 資訊 (需等待一段時間，時間長短跟你應用程式 Memory 成正比)

Step 7 : 完成後可以看到 dump file 存放到指定的 storate account 位置，如果有勾選 Analyze Data 則會產生分機報告。

Step 10 : 點選 Report 可以看到分析 memory 的結果，打完收工 !

另外，如果是在線上環境發生緊急問題時，蒐集應用程式的 Memory dump 可以有助於我們找到問題，但其 dump 處理時間是很漫長會花費比較長的時間，勢必也會影響到處理線上問題的時間，與微軟技術支援討論建議如果遇到這狀況，可以透過 Metric Apply Splitting 找到特定的 instance，接著在 dump 時選擇該 instance 加速其 collect dump file 的時間 (又多學到一招，Azure 初學者覺得開心)。

結論
以上是簡單介紹 Azure Memory Dump 的方式，另外在微軟官方 youtube 也有影片說明如何在 App service 進行 debugging memory 的說明，有需要的朋友可以自己觀看，Hope it helps :D

Read More

[NETCore] ASP.NET Core 限流框架 AspNetCoreRateLimit 整合 Redis

前言
在上一篇介紹了 ASP.NET Core 中的限流框架 AspNetCoreRateLimit，紀錄使用者 Request 的 IP 作為限定流量的判斷來源，並將計數器的值存放在 Server 的 Memory 中，存放在 Memory 中如果 Server 數量單台的話會沒有問題，如果 Server 數量不只一台就需要共用的 Cache Server 來存放 Request 資訊，此時可以搭配 Redis 作為 Cache server 使用，讓所有 Server 在判斷限流時都具備相同的限制條件，這篇就紀錄 AspNetCoreRateLimit 整合 Redis 的操作與設定，若有問題或是錯誤的地方歡迎網路的高手大大給予指導。

安裝 Redis 
首先，起手式先來安裝 Redis，想使用 Redis 可以參考之前的介紹文章

Window : 在 Windows 下載與安裝 Redis、使用 Docker 安裝 Redis

Linux : 在 CentOS7 上安裝 Redis

這裡直接使用 Docker 指令來起 Redis 服務，在 powershell 輸入下列指令

> docker run --name redis-throttle -p 6379:6379 -d redis

啟動成功會顯示 docker 的 container ID 資訊在畫面上，接著在輸入 docker ps -a 確認

> docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS                    NAMES
23e010857e85        redis               "docker-entrypoint.s…"   4 seconds ago         Up 2 seconds   0.0.0.0:6379->6379/tcp   redis-throttle

Redis 啟動成功，對應的 Port 號為 6379

設定 AspNetCoreRateLimit  
在前一篇完整的介紹 AspNetCoreRateLimit 設定方式與代碼，這裡僅說明差異的地方，要使用 Redis Cache 可以使用  IDistributedCache ，IDistributedCache 在 ASP.NET Core 中命名空間為 Microsoft.Extensions.Caching.Redis，因此下一步是進行安裝的動作，在 Nuget Console 輸入下列指令

Install-Package Microsoft.Extensions.Caching.Redis -Version 2.2.0

接著到 startup.cs 將原本儲存在 memory 的地方，改成存到 Redis 並且定義 Redis 的連線字串內容

    public void ConfigureServices(IServiceCollection services)
    {
        // 省略

        // 注入 counter and IP Rules 
        //services.AddSingleton<IIpPolicyStore, MemoryCacheIpPolicyStore>();
        //services.AddSingleton<IRateLimitCounterStore, MemoryCacheRateLimitCounterStore>();
        services.AddSingleton<IIpPolicyStore, DistributedCacheIpPolicyStore>();
        services.AddSingleton<IRateLimitCounterStore, DistributedCacheRateLimitCounterStore>();
        services.AddDistributedRedisCache(option =>
        {
            option.Configuration = Configuration["Redis:ConnectionString"];
            option.InstanceName = Configuration["Redis:InstanceName"];
        });
    }

代碼中定義了 Redis Server 的連線字串與名稱，Throttle 的 Rule 設定為 10m 僅能訪問 1次，因此我們需要到 appsettuing.json 加上 Redis 的設定資料

"Redis": {
    "ConnectionString": "127.0.0.1:6379",
    "InstanceName": "Redis Throttle"
},

確認 Redis 資料 
此時，在重新執行應用程式可以發現當達到設定的次數上限時，就會跳出我們熟悉阻擋的訊息

API calls quota exceeded! maximum admitted 1 per 10m.

再來使用 Redis Desktop Manager 連線到 Docker 內的 Redis，可以發現當達到上限次數時 Redis 有存放相關的 Request 資料，如下圖所示

AspNetCoreRateLimit 將資料儲存在 Redis 成功，大功告成 !!!

參考
AspNetCoreRateLimit

Read More