Go Struct Tag 是什麼？如何透過 reflect 動態處理欄位？
最近在與 MongoDB 互動時發現 Struct 欄位結尾有一段語法不是很熟悉，這篇文章探討 Struct Tag 存在的原因以及解決什麼問題。與其命令式的操縱資料，透過宣告式的方式來描述資料格式是 Struct Tag 的主要用途。
最近在與 MongoDB 互動時發現 Struct 欄位結尾有一段語法不是很熟悉，這篇文章探討 Struct Tag 存在的原因以及解決什麼問題。與其命令式的操縱資料，透過宣告式的方式來描述資料格式是 Struct Tag 的主要用途。
Goroutine 是由 Go 語言本身管理的輕量級執行緒（User-space Thread），而不是由作業系統管理的執行緒（OS Thread）。背後使用 M:N 排程模型。這意味著，M 個 Goroutine 會被分配到 N 個作業系統執行緒（OS Threads）上執行。
「對稱加密」就是通訊雙方進行加密與解密使用相同的金耀，但除了雙方都要保守金鑰外，怎麼讓雙方都持有相同的金鑰本身就是個問題，存在被劫持的風險（中間人攻擊）。「非對稱加密」透過一對金鑰（Key Pair），也就是公鑰與私鑰來解決對稱加密會遇到的問題。
在 Go 語言中，有兩種常見的資料結構可用於表示「序列資料」：Array 與 Slice。這兩者在語法上相似，但背後行為與使用情境差異非常關鍵。簡單來說，Array 是固定長度（Static Array），而 Slice 是動態長度（Dynamic Array）。
近期工作上計劃將 GitLab 遷移到 GitHub，但光是騰出時間進行專案遷移就感覺很麻煩，也因此很多計畫被耽擱著，像是建構 CI 自動化測試環境、導入 AI 代碼審核。幸好 GitLab 很早就有一項功能叫做 Mirroring。
對於 TypeScript 的泛型我一直有種恐懼，什麼滿滿的 `<T>`、`<U>`、`extends`、多層嵌套，看起來就很可怕。畢竟在日常開發裡，好像也不太需要……對吧？的確解決小問題如此，但在特定問題下泛型將會非常必要。
程式是可被執行的代碼或指令，而作業系統透過統整不同概念達成有效率的執行程式，理解以下概念可以幫助更好理解多工程式的運作原理與運行效率最佳化：CPU Core（處理器核心）、Process（進程 / 程序）、Thread（線程 / 執行緒）。
前端 UI 一直是多變且複雜的題材，經歷各種工具迭代與起伏，有很長一段時間其實並沒有什麼特別統一良好的方式進行測試。在經歷過太多次的跌宕變化過後，紀錄我認為現階段怎麼打造可被驗證的前端與未來趨勢與過程中實際遇到的各種困難。
先前提到 JavaScript 的 Iterator Protocol：什麼讓 JavaScript 資料結構能夠被迭代？ 了解 Iterator Protocol 與 Generator，而陣列正是基於 iterator 實做，自然受惠於近期推出的 iterator helper 來進行惰性求值。
你有想過為什麼陣列可以被迭代處理（for...of）但物件不行嗎？Iterables 背後仰賴 Iterator Protocol 來實踐可被迭代的資料結構。基於 Iterator Protocol 的概念更是伸展到 Generator Function 相關的知識點，可以創造更多特殊的資料結構。
Functor 的好處是：它讓我們能用同樣的方式操作不同的「容器型別」，想像成一個「裝值的盒子」，它允許我們對盒子裡的值進行運算，但同時又保留了盒子的結構。Functor 「提供了方式在容器裡操作值」，遵循同一性（Identity）與合成性（Composition）。
從先前 Functor 的概念出發，Functor 的 `map` 只能作用在數值上，而不能是「存在於容器中的數值」上，所以才需要 Applicative Functor，一種比 Functor 更多功能的結構，除了滿足 Functor 的功能外還能「讓盒子裡的函數作用（apply）到另一盒子的值」。
一種代碼風格，著重於函式的組合關係而非具體資料，定義函式時不顯式提其參數（points），而是透過函式組合與高階函式來表達資料流動。可以減少不必要的命名保持代碼簡潔與達成更好的通用組合性，但是額外的抽象須被理解與熟悉。透過兩個實際案例熟悉 Pointfree 開發風格。
我不是數學家也對於範疇論沒有太大興趣，但它深刻的與 Functional Programming 進階理念掛勾，透過實戰了解開發層面這些理論可以如何撰寫更好維護的程式。Functor 是一種具有 map 方法的結構，允許對其中的值進行轉換同時保持結構不變、讓函數可以基於容器進行組合，意味著可以被用於封裝副作用或情境。
最美好的使用體驗是即刻的，因此追求更短暫的等待時間越快越早的回饋很重要，然而倉促的將任何當下的資訊拋給用戶未必是最佳體驗，舉例來說：1.進入網頁 2.反饋「載入資料中……」3.顯示載入完成的資料，以上流程簡潔實在，會有什麼問題呢？問題出在時機和時間。