只有累積,沒有奇蹟

顯示具有 Open Source 標籤的文章。 顯示所有文章
顯示具有 Open Source 標籤的文章。 顯示所有文章

2024年2月9日 星期五

[Free] 電子書 : Observability 101

前言
在國外,可觀測性 (Observability) 這個詞已經成為熱門話題引起熱烈討論,在 CNCF (Cloud Native Computing Foundation) landscape 中有一個區域專門介紹可觀測性 (Observability) 相關工具與技術。 在國外研討會中,發現越來越多人探討如何透過可觀測性來實現 DevOps 更高效率。 近幾年台灣也開始看到越來越多相關文章與研討會分享,分享有關可觀測性的觀念與實踐經驗。在吸收這些知識與寶貴知識後,對這主題有更深入的了解與認識。因此希望自己可以藉由 ITHome 鐵人賽的機會,整理並分享自己關於可觀測性的理解與小小心得。希望藉由透過這次不要臉分享,可以讓對這主題也有興趣的朋友們能夠更快了解可觀測性的重要觀念,一起入坑。

參加鐵人賽完賽後將此參加過程的技術文章整理後放置在 github 上,並統整成 pdf 電子檔方便提供給有需要的人下載。

此書章節如下
  • 第 01 天 : 起心動念
  • 第 02 天 : Observability in DevOps
  • 第 03 天 : Business Continuity
  • 第 04 天 : Service Level Agreement
  • 第 05 天 : Disaster Recovery
  • 第 06 天 : 災難復原計畫 Disaster Recovery Plan
  • 第 07 天 : 高可用性與可靠性 High Availability & Reliability
  • 第 08 天 : 監控與指標分析 Monitor
  • 第 09 天 : DevOps x Observability 小結
  • 第 10 天 : 可觀測性 Observability
  • 第 11 天 : 解析監控和可觀測性:從哨塔到全景地圖
  • 第 12 天 : 可觀察性的演進史:從控制理論到重新定義
  • 第 13 天 : 可觀測性信號(Signals)的進化之旅
  • 第 14 天 : 可觀測性管道:解析現代數據收集與分析
  • 第 15 天 : 開賽至今的回顧與反思
  • 第 16 天 : 可觀測性與它的工具小夥伴們
  • 第 17 天 : OpenTelemetry : 在收集遙測數據中加上一點新標準
  • 第 18 天 : OpenTelemetry : 核心元件大解密 (1/2)
  • 第 19 天 : OpenTelemetry : 核心元件大解密 (2/2)
  • 第 20 天 : OpenTelemetry : Demo 專案快速入門 (1/2)
  • 第 21 天 : OpenTelemetry : Demo 專案快速入門 (2/2)
  • 第 22 天 : 可觀測性摘要 cheetsheet 及小結
  • 第 23 天 : 可觀測性工具的整合與挑戰
  • 第 24 天 : Grafana Cloud : 雲端監控的未來
  • 第 25 天 : Grafana Cloud : 蒐集應用程式遙測數據
  • 第 26 天 : Grafana Cloud : 蒐集應用程式遙測數據 (2/2)
  • 第 27 天 : Grafana Cloud : 使用 Grafana Pyroscope 優化應用程式性能
  • 第 28 天 : Grafana 事件管理 : 從告警到修復的問題排除流程 (1/2)
  • 第 29 天 : Grafana 事件管理 : 從告警到修復的問題排除流程 (2/2)
  • 第 30 天 : 從傳統開發到可觀測性驅動開發 (ODD)
  • 第 31 天 : 30 天之後 ?

如何取得電子書
基於「取之網路,用之網路」的精神,此電子書是免費的,如果您喜歡這本電子書或者它對您有幫助,請您高抬貴手在 GitHub 電子書項目專案給我一些鼓勵 ⭐️⭐️⭐️ : 傳送門

2023年3月2日 星期四

[Free] 電子書 : OpenTelemetry 可觀測性的未來

前言
在 2021 年因為接觸可觀測性工具 Signoz 意外發現 OpenTelemetry 收集遙測數據的標準,開始覺得議題很好玩這框架十分有趣,在找電子書的過程中意外發現由 O'Reilly 出品的 The Future of Observablity with OpeTelemetry,內容十分不錯,作者也是對於分散式系統頗有研究的大師,由於此新議題市面上的電子書不多,因此花了點時間參考大陸開源有名的前輩 Jimmy Song 翻譯的簡中版,整理一份繁體中文版給有需要的夥伴們。
此書章節如下
  • 前⾔
  • 第 1 章:可觀測性的歷史
  • 第 2 章:結構化數據的價值
  • 第 3 章:⾃動分析的局限性
  • 第 4 章:⽀持開源和原⽣監測
  • 第 5 章:OpenTelemetry 架構概述
  • 第 6 章:穩定和⻑期⽀持
  • 第 7 章:建議的設置和遙測管道
  • 第 8 章:如何在組織中推廣 OpenTelemetry
  • 附錄 A:OpenTelemetry 項⽬組織

如何取得電子書
基於「取之網路,用之網路」的精神,此電子書是免費的,如果您喜歡這本電子書或者它對您有幫助,請您高抬貴手在 GitHub 電子書項目專案給我一些鼓勵 ⭐️⭐️⭐️ : 傳送門

2022年9月3日 星期六

[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

2022年8月9日 星期二

[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
投影片 : 連結



2022年2月6日 星期日

[Free] 更新 ASP.NET Core 的兩三事 電子書

前言
star-wars-font
之前有整理 ASP.NET Core 相關文章變成一本電子書 Something about ASP.NET Core 並放在 Github 上供人自行取用 (詳細可以參考 這篇 文章),去年也有撰寫一些相關的議題因此在過年期間也針對電子書做更新,新增的內容及章節如下
  • 建立 Azure Container Registry 並整合 Microsoft Team 通知
  • 如何在 ASP.NET Core Middleware 加上單元測試 UnitTest
  • ASP.NET Core 使用強型別取代 IOption 注入配置
  • ASP.NET Core 中的例外處理方式
  • 建立排程服務 - Generic Host 搭配 Quartz.Net
  • 現代化監控使用 OpenTelemetry 實現

如何取得電子書
第一次分享電子書格式有些混亂尚在調整中,各位朋友如果對於外觀與格式部分可以先忽略暫時忍耐一下,我還在找方法讓格式更美觀一些,如果有建議的電子書製作方式也可以留言給我 XD。如果對於電子書內容有疑問或是有疑慮的地方歡迎在 GitHub 發 Issue 或是寄 EMAIL 至 marcustung116@gmail.com 信箱給我,我會定期更新並修復問題發布至新版的電子書中。

下載位置 : GitHub : 傳送門


Feedback
基於「取之網路,用之網路」的精神,ASP.NET Core 的二三事 電子書是免費的,如果您喜歡這本電子書或者它對您有幫助,請您高抬貴手在 GitHub 電子書項目專案給我一些鼓勵 ⭐️⭐️⭐️ : 傳送門
如果覺得這本電子書真的很不錯,也可以請我喝杯咖啡讓我有動力繼續更新下去,謝謝 :)

2021年12月20日 星期一

[conference] .NET Conf 2021 - 初探 OpenTelemetry - 蒐集遙測數據的新標準

分享心得
參加好幾屆 .NET Conf 每次都是收穫滿滿,今年被主辦單位也是技術管理者論壇志工 Kyle 推坑在 .NET 年度盛會邀請分享,原本十分不好意思但想到之前已經有在 COSCUP 與 MOPCON 分享過兩場,於是決定分享最近有興趣的議題 OpenTelemetry 開源框架, 依舊保持緊張就斷片的正常發揮,在一開始主持人介紹完開場就立刻忘詞 (掉漆again),很高興可以參予 Study4.TW 10年盛會,可以有機會在講師休息室認識大神們,可以在自己熟悉的 meetup 分享技術是件很幸福的事情,非常非常難得的線下分享,特此紀錄一下


議程介紹
主題 : 初探 OpenTelemetry - 蒐集遙測數據的新標準
隨著商業的變化越來越快與技術不斷的推進,系統架構的演進可能從單體式(monolithic)到 SOA 在到分散式架構,迎接的挑戰是如何在服務越切越細的情況下,能夠更即時的瞭解線上應用程式(Application)的狀況。
開始越來越多人討論分佈式追踪(Distributed Tracing)議題,在過去有 Dapper 或是 opencensus 可以幫助達到目的,有沒有一個更高效且統一的方式蒐集應用程式的遙測數據呢?
OpenTelemetry 是雲原生可觀察性的框架,它提供了標準化的 API、SDK 與協議,支援 W3C 定義的 Http trace-context 規範,同時提供在開發者可以在 Pipleline 上進行擴展,降低開發者在蒐集遙測數據上的困難度。在本議程會與大家分享下面幾個議題
➊ OpenTelemetry 特性
➋ OpenTelemetry 解決什麼問題呢?
➌ OpenTelemetry 是如何做到服務之間的數據追蹤、蒐集與分析的呢?

主辦單位 : .NET Conf
.NET CONF 這一年一次的世界級盛會台灣不會缺席!由台灣 MICROSOFT 和 STUDY4 共同組織的台灣 .NET CONF 開發人員活動,快來慶祝並了解新版本帶來的優秀開發體驗吧!

議程表 : 連結
共筆 : https://hackmd.io/@Study4/dotnetconf-2021/%2Fp57xhYRBTnm1QgpaRiOL0A
投影片 : 連結

2021年10月23日 星期六

[conference] MOPCON 2021 - 探討開源平台 SigNoz,實施大規模分佈系統遙測的挑戰

分享心得
網站上線後往往才是挑戰的開始,在大神 Ant 推坑下報名了 MOPCON,跟與會的朋友分享 #Signoz 這套開源的工具,其中也帶到 #可觀察性 與 #監控平台應具備特性 等自己有興趣的議題。也趁空檔跟一些講者聊聊各自研究的議題,在活動結束後回想,都覺得收穫最多的不是別人而是自己,也很感謝在準備過程中協助 review 的朋友跟夥伴,希望這次在濁水溪以南最強大行動科技年會的分享聽眾都有收穫,等待 MOPCON 官方把影片上架構在分享給大家,若有任何問題歡迎提出來一起討論。

議程介紹
主題 : 探討開源平台 SigNoz,實施大規模分佈系統遙測的挑戰
在服務切割越來越微細的世代,系統上線後的監控也變得越來越複雜
為了監控雲端應用服務上線後的可用性,可能會使用不同的工具像是 Prometheus、Grafana 或是 Jaeger 來達到其目的
,或是使用一些整合性高須付費的 SaaS 服務像是 DataDog、NewRelic 等。
有沒有一個框架可以在監控上整合各服務間的問題且免費的呢?
SigNoz 是一個開源且功能強大的監控平台,透過此框架內建常見的 RPS, 50th/90th/99th 等監控指標,當請求進來後在各個服務的跟蹤指標資訊都可以查看到,發生問題時可以快速找到根本問題與排除。
透過 OpenTelemetry 函式庫建立與管理各服務的監控數據,支援跨程式語言能夠整合常見的服務與工具。
在本議程會與大家分享下面幾個議題
➊ SigNoz 要解決什麼問題呢 ?
➋ OpenTelemetry 是甚麼 ? OpenTelemetry 是如何做到服務之間的數據追蹤、蒐集與分析的呢
➌ SigNoz 的優點與缺點是什麼呢 ?

主辦單位 : MOPCON 堅持濁水溪以南,最大行動科技年會
議程表 : 連結
共筆 : https://hackmd.io/@mopcon/2021/%2FDRb25K2eS5KD96WcAgHBzQ



影片連結

2021年8月1日 星期日

[conference] COSCUP 2021 | 初試 Casbin - 快速搭建符合 99% 產品都需要的高彈性可維護之授權控制系統

分享心得
在過去都是在技術研討會擔任觀眾的我,某天在跟技術大神 Ant 大聊天時不小心被推坑參加 COSCUP 開源人年會上分享 Casbin 這套 OpenSource 的授權框架,自己抱著試試看的心情沒想到投稿的議程有上,研討會進行方式今年也因為疫情的關係從線下活動改為線上的方式,但對於第一次參加公開分享擔任講者的我來說是沒有區別的(一樣緊張),花了不少時間準備這議題也請 Ant 與 Justin review 議題內容,其中也使用 Casbin.NET 來 Demo 讓大家更容易理解,另外還花了很多時間在研究影片字幕要如何加上,做完覺得線上課程的講師也是非常厲害的阿 !
希望參加此議程的朋友們可以在有所收穫,也非常感謝 COSCUP 主辦當為給我這機會可以在台灣 最大的 Open Source 年會上進行分享,以下是分享的內容與影片連結,若有任何問題歡迎提出來一起討論。


議程介紹
主題 : 初試 Casbin - 快速搭建符合 99% 產品都需要的高彈性可維護之授權控制系統
相信開發人員都設計過權限功能,在不同程式語言也都有不同的框架與設定權限方法
在服務切割越來越微細的世代,是不是有一種方式可以在設定權限策略(Policy)上更簡單呢 ?
Casbin 是一個開源且功能強大的權限控制庫,做到一種跨程式語言的標準 (各程式語言通用統一資源),支援 PHP、JAVA、GO等 Node.js 等常見的程式語言。也將複雜的 Authentication 與 Authorization 做簡化,將常用的授權方式 ACL, RBAC, ABAC 進行模組化。
在本議程會與大家分享下面幾個議題
• Casbin 是如何做到跨程式語言的標準呢 ?
• 一些常見的授權方式在 Casbin 是怎麼做到 & 設定的呢 ?
• Casbin 的優點與缺點是甚麼呢 ?

主辦單位 : 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/rymNETD0O/%2F%40coscup%2Fry-7ETDAO


影片連結


2019年8月13日 星期二

[Free] ASP.NET Core eBook - ASP.NET Core 的兩三事

前言
去年正式踏入 ASP.NET Core 的世界,在學習 .NET Core 的過程中自己也持續地將所學到相關知識記錄在這裡,除了希望可以加深對於 ASP.NET Core 的了解之外也希望能幫助自己健忘的金魚腦,另外也有個想法是累積到一定文章數量之後,可以將所學到的文章有系統與結構性整理出來成電子書,來幫助對 .NET Core 有興趣或是正在學習的的開發者朋友,經過一個月的努力之後於是誕生了  ASP.NET Core 的二三事  電子書 alpha 版 ( 英文名字是 Something about ASP.NET Core )
star-wars-font
特地製作 STAR WAR 字體版本封面以示慶祝 (灑花!!!)

此電子書主要內容是由此部落格中 ASP.NET Core 相關文章整理而成,也是自己經歷近一年學習 ASP.NET Core 累積的學習筆記,還有開發時所遇到的問題及解法 (踩到的雷),目前 alpha 版本章節暫定如下

目錄


暫定的目錄章節如上,相信對 ASP.NET Core 有一定程度了解的朋友都知道還有很多重要的部分沒提到,自己比較有興趣的內容像是 Middleware、Dependency-Injection、httpclientfactory、GC 和 Docker 議題等章節都還擺放在 blog 的草稿中,再加上 .NET Core 3.0 也接近 release 時間,相信有更多好玩的議題可以研究,上面提到的部分日後有時間整理完後會先發布在此部落格,再定時將整理好的與 ASP.NET Core 相關的 session 更新至電子書中。

如何取得電子書 
第一次分享電子書格式有些混亂尚在調整中,各位朋友如果對於外觀與格式部分可以先忽略暫時忍耐一下,我還在找方法讓格式更美觀一些,如果有建議的電子書製作方式也可以留言給我 XD。如果對於電子書內容有疑問或是有疑慮的地方歡迎在 GitHub 發 Issue 或是寄 EMAIL 至 marcustung116@gmail.com 信箱給我,我會定期更新並修復問題發布至新版的電子書中。

下載位置
GitHub : 傳送門
Feedback 
基於「取之網路,用之網路的精神,ASP.NET Core 的二三事 電子書是免費的,如果您喜歡這本電子書或者它對有幫助,您可以考慮做下列幾件事情
  • 請您高抬貴手在 GitHub 電子書項目專案給我一些鼓勵 ⭐️⭐️⭐️ : 傳送門
  • 請大家不吝嗇去推廣給有需要的朋友,讓這本書內容變更好
如果覺得這本電子書真的很不錯,也可以請我喝杯咖啡讓我有動力繼續更新下去,謝謝 :)

2019年8月9日 星期五

[OpenSource] Moda-Time 時間套件

前言
過去開發時常常都會需要處理關於時間顯示問題,C# 日期輸出格式可以透過 DateTime.ToString() 方式來自訂顯示輸出內容舉例來說取得時間後對於輸出內容格式化、指定日期是一周中的星期幾等資訊,都會在 ToString() 時候加上 format 來定義,這些格式化的內容讓代碼在閱讀上會有些小混亂,且不容易記住需要查文件才知道,因此我利用一點時間整理過去在 C# 處理時間時常用到的方法,於是乎  Moda-Time  Library 就誕生了,希望可以讓開發者在處理時間上更方便,此篇就簡單介紹此套件所提供的 API 使用及簡單範例,若有問題或是錯誤的地方歡迎各位前輩一起討論指導

使用方式
Moda-Time 所提供的 API 是使用 C# 3.0 開始有的擴充方法 (Extension Method) 為基礎,並參考 Java 著名的時間套件 joda-Time 提供的 API,在原有的 C# DateTime 中加入新的方法簽章,以下根據此套件的方簽章做簡單的介紹與範例

日期時間信息
取得有關指定日期的顯示資訊,代碼如下
var now = DateTime.Now;

Console.WriteLine($"現在時間是:{now.ToString()}...");
Console.WriteLine($" - DayNameOfWeek: {now.DayNameOfWeek()}");
Console.WriteLine($" - ShortDayNameOfWeek: {now.ShortDayNameOfWeek()}");
Console.WriteLine($" - ShortDayNameOfWeek (指定 Culture): {now.ShortDayNameOfWeek(new CultureInfo("en-us"))}");
Console.WriteLine($" - MonthNameOfYear: {now.MonthNameOfYear()}");
Console.WriteLine($" - MonthNameOfYear (指定 Culture): {now.MonthNameOfYear(new CultureInfo("en-us"))}");
Console.WriteLine($" - ShortMonthNameOfYear: {now.ShortMonthNameOfYear()}");
Console.WriteLine($" - ShortMonthNameOfYear (指定 Culture): {now.ShortMonthNameOfYear(new CultureInfo("en-us"))}");
Console.WriteLine($" - GetWeekOfYear: {now.GetWeekOfYear()}");
Console.WriteLine($" - GetWeekOfMonth: {now.GetWeekOfMonth()}");
Console.WriteLine($" - GetEndDayOfMonth: {now.GetEndDayOfMonth()}");

輸出如下:
現在時間是:2019/8/10 上午 06:53:42...
 - DayNameOfWeek: 星期六
 - ShortDayNameOfWeek: 六
 - ShortDayNameOfWeek (指定 Culture): Sat
 - MonthNameOfYear: 八月
 - MonthNameOfYear (指定 Culture): August
 - ShortMonthNameOfYear: 八月
 - ShortMonthNameOfYear (指定 Culture): Aug
 - GetWeekOfYear: 32
 - GetWeekOfMonth: 2
 - GetEndDayOfMonth: 31 

日期比較
取得有關指定日期的顯示資訊,代碼如下
var t1 = new DateTime(2019,1,2,3,4,5);
var t2 = t1.AddMinutes(-1);
var t3 = t1.AddMinutes(1);
var t4 = new DateTime(2019, 1, 2, 3, 4, 5);

Console.WriteLine($" - t1 IsAfter t2: {t1.IsAfter(t2)}");
Console.WriteLine($" - t1 IsBefore t3: {t1.IsBefore(t3)}");
Console.WriteLine($" - t1 IsEqual t4: {t1.IsEqual(t4)}");

輸出如下:
 - t1 IsAfter t2: True
 - t1 IsBefore t3: True
 - t1 IsEqual t4: True 

日期比較 
日期比較 API 是我個人比較愛的部分,過去在計算兩個日期的差異時都需要先做日期相減取得 timespan,在取得透過 timespan 去看差異的天數、或是時分秒等需要的數字,過去往往代碼都要寫 3 行以上,但透過此 Library 僅需要一行,範例如下
var t1 = new DateTime(2019, 1, 1, 1, 1, 1, 1);
var t2 = new DateTime(2019, 1, 2, 3, 4, 5, 6);

Console.WriteLine($"t1 : {t1.ToString()}");
Console.WriteLine($"t2 : {t2.ToString()}");
Console.WriteLine($" - compare two date - timespan: {t1.Compare(t2)}");
Console.WriteLine($" - compare two date - totalDay: {t1.GetCompareTotalDays(t2)}");
Console.WriteLine($" - compare two date - TotalHours: {t1.GetCompareTotalHours(t2)}");
Console.WriteLine($" - compare two date - TotalMinute: {t1.GetCompareTotalMinute(t2)}");
Console.WriteLine($" - compare two date - TotalSecond: {t1.GetCompareTotalSecond(t2)}");
Console.WriteLine($" - compare two date - TotalMilliseconds: {t1.GetCompareTotalMilliseconds(t2)}"); 

輸出如下:
t1 : 2019/1/1 上午 01:01:01
t2 : 2019/1/2 上午 03:04:05
 - compare two date - Timespan: -1.02:03:04.0050000
 - compare two date - TotalDay: -1.0854630208333333
 - compare two date - TotalHours: -26.0511125
 - compare two date - TotalMinute: -1563.06675
 - compare two date - TotalSecond: -93784.00499999999
 - compare two date - TotalMilliseconds: -93784005
另外 API 中還有提供 plus 日期相關方法,但用法和 DateTime.Add 差異不大,這裡就不在特別另外說明與附上範例程式碼,需要可自行使用。


感想
最後附上 Github 連結,歡迎提供建議、或直接修改程式碼(修改完成後請發 pull request),覺得不錯也請給我顆星星鼓勵,希望這篇介紹可以有幫助到有需要的朋友,Happy Coding :)
Github : https://github.com/marcustung/Moda-Time

參考
DateTime.ToString

Copyright © m@rcus 學習筆記 | Powered by Blogger

Design by Anders Noren | Blogger Theme by NewBloggerThemes.com