Art的辦公桌

先前已經有直接在 pipeline 專案內執行批次指令來分析專案，但這樣做的話其實並沒有辦法在專案分析的時候，判斷分析結果，只能依照原先做好的流程一直走下去，因此這一篇文章主要在解決這一點，透過 Jenkins 套件來處理這件事情

採用 Selenium + ChromeDriver 實作網頁快照功能，雖然 FirefoxDriver 好像有一個可以截完整頁面的方法可以用，但平常沒用 FireFox 也不想安裝，直接使用 Chrome 的 CDP Command 來處理截圖

先前已經有研究過熔斷機制屬於應用程式呼叫其他服務的時候，對方無法正常回應所採取的手段。限流則是針對自己的應用程式，去限制外部傳過來的請求數量，要做到這一點則必須要能夠知道自己的負載峰值大概在哪一個程度，在接近上限的時候才能夠啟動限流的干預機制，像是服務降級、或是直接拒絕請求

前陣子因為工作需要，研究了一下如何取得 youtube 聊天室訊息，今天就稍微分享一下過程跟心得吧

先前在 2020 的時候為了練習程式碼分析工具，找到了 sonarQube 也因此撰寫了幾篇練習文章，但 2022 的今天在使用當初文章內的方法已經不適用了。可能是因為軟體更新的關係，所以這次特別紀錄一下重新練習的經過做個紀錄。先前的文章也就不再更新，將相關文章整理在左側選單，有興趣再去看。

前陣子重灌電腦，發現 oh-my-posh 已經不再直接支援 powershell，因此需要依照官網的方法調整一下原先的作法

今天寫的是一個很簡單的 tip，因為使用 rider 但是團隊其他人並沒有使用，這樣子 IDE 產生出來的一些檔案如果也寫到專案的 .gitignore 好像也不太好，以往都是很熟悉的團隊成員，所以偷懶直接加上去也沒關係，但如果是剛到新團隊這樣幹就不太好了

熔斷機制這個名詞我自己的理解是核心觀念就是類似電路過載保護的概念。家裡面的繼電器負責的就是提供一個保護機制，當同一電流迴路的用電負載超出安全電流，則繼電器就會跳脫，使得電路斷路，達到隔離的作用。原因是連續通過的電流會讓電線過熱(這個有興趣的話好像可以去看看電磁學，我都還給老師了沒有記得很詳細)，容易使電線的絕緣體老化(也就是電線外面那層塑膠皮)，甚至是燃燒的情況，從而有電線走火的危機

上面那個說法我不確定離開學校那麼久之後有沒有講錯，但大致上的觀念就是這樣：當系統發生問題，透過保護機制將發生問題的系統斷開，不讓問題繼續擴大

REF: 過載保護 - 中文百科

分散式追蹤系統

系統架構從單體轉變成微服務之後，使用者發出的單次請求往往會涉及到多個服務之間的呼叫，以往採用的日誌服務也較難以窺見全貌，當我們需要追蹤某一次請求中間發生了那些事情，我們期望能獲取的資訊不外乎是這次的請求，總共經過哪些服務，每個服務花費了多久的時間，呼叫的順序等等，這就是分散式追蹤系統能夠幫我們做到的事情。只不過每一家系統的 API 都不太一樣，所以 W3C 也有提供一份Trace Context - W3C，讓大家都用同一個標準來實現分散式追蹤。

在這之前看到一堆像是 RequestId, TraceId, SpanId, ParentId, ActionId，可能還有很多我沒有列出來的名詞，真的是有看沒有懂，現在至少可以從 W3C 的建議中明確知道一些名詞與他們的用途，其他的應該就是各家廠商自己的定義了，那就有用到再說囉

以往使用 ELK 來記錄資訊，是一件非常複雜繁瑣的事情，與 ELK 還有一堆 beat 打交道，首先要面對的是不熟悉的 linux 系統，接著是聽都沒聽過的一堆設定方式跟眉眉角角，太久沒用我連 SSL 都忘記怎麼用，更別提複雜的設定語法。而使用 Serilog + Seq 就相對簡單很多，查詢語法也比 Kibana 友善。