Golang on omegaatt

Golang 1.27 新特性整理：泛型補完與轉正的實驗性功能

raiven.kao@gmail.com (Raiven Kao) — Thu, 06 Aug 2026 00:00:00 +0000

半年前寫完 Go 1.26 新特性那篇，文末問了一句「準備好更新你的 go.mod 到 go 1.26 了嗎？」，沒想到一轉眼 Go 1.27 也要來了。撰文的當下 Go 1.27 即將正式發布，以下內容是根據 release candidate 整理，如果正式版有微調，還是以官方 release notes 為準。

如果說 Go 1.26 給我的感覺是數量多、廣度大，那 Go 1.27 更像是把之前欠的債還一還。generic method 從 issue 一路等到現在終於落地，goroutineleak profile 從需要 GOEXPERIMENT 才能開的實驗功能轉正成預設行為，encoding/json/v2 也從實驗畢業成為預設實作。這篇就挑幾個我覺得值得記錄的改動來聊聊。

語言層面：泛型設計的最後一塊拼圖

Generic Method 真的來了

這件事我在 Go 1.27 即將支援 Generic Method 那篇已經寫得很詳細了，這裡就不重複展開，只放結論：method 現在可以宣告自己的 type parameter，不用再繞道用 package-level function 把 receiver 當參數傳進去。

type List[T any] struct {
    items []T
}

func NewList[T any](items ...T) List[T] {
    return List[T]{items: items}
}

// MapTo 是 generic method，帶著自己的型別參數 U，
// 跟 receiver 的型別參數 T 是兩回事。
func (l List[T]) MapTo[U any](f func(T) U) List[U] {
    out := make([]U, len(l.items))
    for i, v := range l.items {
        out[i] = f(v)
    }
    return List[U]{items: out}
}

type Cat struct {
    Name string
    Age  int
}

cats := NewList(Cat{"Mittens", 3}, Cat{"Tama", 5})
names := cats.MapTo(func(c Cat) string { return c.Name })
fmt.Println(names.items) // [Mittens Tama]

老話一句：interface 目前還是無法宣告帶 type parameter 的 method，這是 dynamic dispatch 架構性的限制，不是漏掉沒做。想看完整的來龍去脈跟 workaround 的比較，去讀前面連結的那篇。

Go 1.27 即將支援 Generic Method：告別 package-level 函式的 workaround

raiven.kao@gmail.com (Raiven Kao) — Wed, 27 May 2026 00:00:00 +0000

前言

Go 1.18 帶來泛型之後，我們終於可以寫出型別安全的通用函式，不再需要到處 interface{} 加型別斷言。但一個眾所周知的限制一直存在到現在，method 沒辦法有自己的 type parameter。

換句話說，這段程式碼在目前的 Go 版本中是非法的：

func (c *Client) doRequest[T any](ctx context.Context, method, path string, body any) (*T, error) {
    // 編譯錯誤：cannot use generic method doRequest without instantiation
}

為了繞過這個限制，大家只能退而求其次，把 receiver 當作普通參數傳進去，改用 package-level 的 generic function。

最近 Go issue #77273 的進展讓這件事有了轉機，generic method 的設計已被接受，預計在 Go 1.27 正式釋出。

為什麼現在沒有 Generic Method？

這不是 Go team 沒想到，而是刻意的設計決策。

Go 的 interface 是核心功能，method 必須能夠被 dispatch 到具體的實作上。如果 method 自身帶有 type parameter，編譯器在 dispatch 時需要知道 T 是什麼，這在動態 dispatch（interface dispatch）的情境下是個難題，runtime 無法事先知道要生成哪個型別的實例化版本。

所以泛型剛推出時，generic method 被刻意排除在外，等待一個比較完整的設計方案。這個等待從 Go 1.18 一路等到了 1.27（暫定）。

Pragmatic Clean Architecture in Go

raiven.kao@gmail.com (Raiven Kao) — Thu, 23 Apr 2026 00:00:00 +0000

前言

在大型系統或需要長期維護的產品中，導入 DDD（Domain-Driven Design）或 Clean Architecture 幾乎是業界的標準答案，分層清晰、職責明確、可測試性高，這些優點毋庸置疑。

但問題是，不是每個專案都是大型系統。

當你面對的是一個內部工具、side project、或是剛起步的新產品，Clean Architecture 的大全套 Use Case、Port、Adapter、Aggregate、Repository Interface 全放 domain，往往會讓你在還沒寫第一行商業邏輯之前，就先在資料夾結構裡迷路了三個小時，或是讓不熟悉的貢獻者花費大量時間在閱讀架構。

這篇文章想討論的是：在不犧牲可測試性與可維護性的前提下，哪些抽象可以捨棄、哪些值得保留，以及我自己踩過的一些坑。

捨棄什麼

獨立的 Port/Adapter 層

Clean Architecture 中，Use Case 透過明確定義的 input/output port 與外界溝通，搭配 Adapter 負責格式轉換。這在大型系統中確實有其價值，但它帶來的代價是：為了讓每一層都能獨立替換，你需要維護大量的介面與轉換邏輯，而這些轉換邏輯往往只是把 A struct 的欄位複製到 B struct。

在小專案中，這條轉換鏈可以大幅縮短。HTTP handler 本身就可以負責 DTO 的轉換，不需要再多一層 Adapter。

DDD 的 Aggregate

Aggregate 是 DDD 中保護業務不變式（invariant）的邊界，透過 Aggregate Root 統一管理相關物件的存取。這個概念本身沒有問題，但在小專案中，如果業務規則還不夠複雜到需要嚴格的不變式保護，過早引入 Aggregate 反而會讓簡單的 CRUD 操作變得冗長。

保留什麼

捨棄了部分複雜度之後，剩下的四層架構已經足以應付絕大多數的小專案需求。

`package domain`

這裡只放 Domain Model 與 Value Object。

值得特別說明 Domain Model 的定義。它不等同於 DDD 裡的 Domain，不是什麼深奧的設計概念，Domain Model 只是在描述「這個應用程式如何跟外部世界互動、邊界在哪」，也就是你的核心資料結構與它們身上的行為。有些「賣課」的人喜歡把 Domain Model 直接等同於 DDD 的 Domain，實際上它是個更基礎、更普遍的概念，可以參考這支影片的解釋。Domain Model 中不需要也不該出現任何技術細節，例如回傳是否是 JSON 等等，這些 Domain Model 甚至要能讓 PM 與非技術人員也「聽的懂」。

放棄 Electron 與 Tauri? 我用 Wails + HTMX 打造 3MB 的跨平台桌面應用

raiven.kao@gmail.com (Raiven Kao) — Mon, 09 Mar 2026 00:00:00 +0000

Web 仔要有 Web 仔的自覺

前言

前陣子收到了 Murphy 的需求，嘗試使用 Tauri 寫了一個桌面 App。Tauri 結合 Rust 與 React 的體驗相當不錯，打包出來的體積也十分理想。

但身為一個主要撰寫 Golang 的後端工程師，內心總有一個聲音：「如果能用 Go 來寫桌面應用，那該有多好？」

眾所周知，Golang 在原生的 Desktop GUI 框架上一直沒有特別強勢的殺手級專案（過去使用 Fyne 的經驗不算太好）。在環顧了一眾基於 Chromium 的 Electron 或是基於系統 WebView 的 Tauri 後，決定走一條稍微不一樣的「老路」：使用 Wails 搭配 HTMX 與 Templ。

最終的產物就是 Dub 一個跨平台的批次檔案重新命名工具。更甚，在 Linux 上打包出來的可執行檔只有約 3MB，並且完美支援 macOS 與 Linux，且幾乎沒有複雜的前端狀態管理負擔。

為什麼是 Wails + HTMX？

在選擇桌面應用程式的技術方案時，我們通常有幾個考量

Electron: 開發體驗極佳，生態系最豐富，但代價是動輒上百 MB 的體積與高昂的記憶體佔用。對於一個小工具來說，太過沉重。（這也是我優先選擇 Zed.dev 作為主要編輯器的原因）
Tauri: 效能極佳，體積小，但後端需要寫 Rust。雖然 Rust 很香，但有時候只想用最熟悉的 Go 快速把邏輯刻出來。
Wails: 與 Tauri 類似，採用前端網頁技術結合系統原生 WebView，但後端語言是 Golang。

既然選了 Wails，前端該用什麼？現代前端框架（React, Vue, Svelte）通常需要建置複雜的 SPA（Single Page Application），並透過 JSON API 與後端溝通。但對於一個狀態並不複雜的工具軟體，不想在前端再維護一份狀態。

Clean Craftsmanship：在 LLM 時代重拾軟體工匠精神

raiven.kao@gmail.com (Raiven Kao) — Thu, 19 Feb 2026 00:00:00 +0000

為什麼在這個時間點讀這本書

最近對於如何在 LLM 時代帶領團隊一起提昇生產力感到困惑。當 AI 能在幾秒鐘內生成幾百行程式碼，「寫程式」這件事的門檻似乎降到了前所未有的低點。但門檻低了，品質呢？

當「每個人」都在養龍蝦，有了生產力焦慮，TypeScript 寫的 OpenClaw 才剛出現，Python 的 NanoBot 馬上跟上，接著是 Golang 的 picoclaw，然後 Rust 的 ZeroClaw 也來了。

根據 ZeroClaw 做的 benchmark，這些 Agent 已經降到小於 5MB 的記憶體佔用與 10ms 的啟動時間，「種族」為人類的我們對於產出軟體來說還剩什麼？

帶著這個問題，我決定先從自身出發，找出在 LLM 時代還能保持軟體工程「工匠精神」的誘因。於是翻開了 Robert C. Martin 的 Clean Craftsmanship。

這本書分為三個部份：紀律、標準、道德。一半以上的篇幅在講述 TDD 這個老生常談的開發方式，但透過 TDD，我們更能知道何謂軟體的「品質」。以下是我特別書籤的幾個段落。

紀律

童子軍規則

離開營地時，要比你來時更乾淨。

這也是在 Clean Code 一書就提到的概念。每次微小的重構，都能小程度的減少技術債的產生。不需要一次大刀闊斧，只要每次經過一段程式碼時，順手讓它變得更好一點。

讓我想到 Claude is not a senior engineer (yet) 這篇文章中提到的 Sweeks——一位被稱為「園丁」的 distinguished engineer，他不斷地重寫、收緊抽象，讓經過他手的程式碼都變得更乾淨。我們都想成為 Sweeks，對吧？

在 LLM 時代，AI 擅長的是「組裝」現有解決方案，但它缺乏 Sweeks 那種「看到可以更好的地方就會忍不住動手」的靈魂。童子軍規則提醒我們：這份靈魂不能丟。

Test Doubles 的正名

書中透過實戰的例子講述了所有 test double：Dummy、Stub、Spy、Mock、Fake。

坦白說，我曾經在諸多 repo 中看到這些名詞卻沒有實際使用它們。頂多在 DI 時製作了一個「用於模擬 database repository 的 implement」，或是使用了 gomock 這種套件來產生 mock，然後把所有替身都統稱為 mock。

Golang 1.25 testing/synctest 初體驗：告別在測試中寫 time.Sleep 的日子

raiven.kao@gmail.com (Raiven Kao) — Sun, 18 Jan 2026 00:00:00 +0000

前言

在我們目前的應用程式架構中，由於高度與 Kubernetes 耦合，服務啟動與運作期間需要頻繁地去讀取 K8s 中的 ConfigMap。為了達成配置熱更新（Hot Reload），我們引入了 Kubernetes client-go 中的 informers 機制來監聽 ConfigMap 的 CRUD 事件。

雖然 K8s 官方提供了 fake client 讓我們能測試 informers 的邏輯，但在 Service Code 的層級，我們往往需要封裝一層更適合業務邏輯的 ConfigWatcher。Golang 引以為傲的輕量級 Goroutine 與 Channel 搭配非常適合用來處理這種非同步的事件傳遞。

然而，一旦涉及到 Goroutine 的非同步測試，「時間」往往就成了最大的敵人。

遇到的問題：不穩定的測試與魔法數字

為了模擬 ConfigMap 的變更通知，我們定義了一個 ConfigMapWatcher 介面與對應的 Event 結構：

const (
	ConfigMapUpdateEventTypeAdded ConfigMapUpdateEventType = iota
	ConfigMapUpdateEventTypeModified
	ConfigMapUpdateEventTypeDeleted
)

type ConfigMapUpdateEvent struct {
	Name  string
	Type  ConfigMapUpdateEventType
	Value map[string]string
}

type ConfigMapWatcher interface {
	Watch(ctx context.Context, eventCh chan<- ConfigMapUpdateEvent) error
}

接著，我們很自然地在 testing 中實作了一個 fake 物件來模擬事件發送：

type fakeConfigMapWatcher struct {
	injectCh  chan ConfigMapUpdateEvent
	watchErr  error
	watchOnce sync.Once
}

func newFakeConfigMapWatcher() *fakeConfigMapWatcher {
	return &fakeConfigMapWatcher{
		injectCh: make(chan ConfigMapUpdateEvent),
	}
}

func (f *fakeConfigMapWatcher) sendEvent(event ConfigMapUpdateEvent) {
	f.injectCh <- event
}

func (f *fakeConfigMapWatcher) Watch(ctx context.Context, eventCh chan<- ConfigMapUpdateEvent) error {
	if f.watchErr != nil {
		return f.watchErr
	}

	f.watchOnce.Do(func() {
		go func() {
			for {
				select {
				case <-ctx.Done():
					return
				case e := <-f.injectCh:
					eventCh <- e
				}
			}
		}()
	})
	return nil
}

問題來了，當我們在寫單元測試時，呼叫 sendEvent 將事件送入 channel 後，消費者端（也就是我們的業務邏輯 Goroutine）並不會「立刻」收到並處理完成。為了確保 assert 斷言執行時，業務邏輯已經跑完了，我們被迫在測試中加入 time.Sleep：

Golang 1.26 新特性在數量上史無前例的多

raiven.kao@gmail.com (Raiven Kao) — Tue, 13 Jan 2026 00:00:00 +0000

隨著時間來到 2026 年初，Go 語言迎來了 1.26 版本的更新。如果說 Go 1.18 的泛型是語言層面的重大變革，那麼 Go 1.26 則是在「數量」與「廣度」上讓人感到驚艷的一次釋出。從語言特性的語法糖、標準庫的實用擴充，到 Runtime 效能的顯著提升（Green Tea GC），甚至是實驗性的 SIMD 支援，這次的更新內容豐富到讓人目不暇給。

本文將挑選其中幾個我認為對日常開發最重要、或最有趣的改動來進行介紹。

語言層面的改動

`new(expr)`：終於不用再寫輔助函數了

在 Go 1.26 之前，如果我們想要取得一個基本型別（如 int, bool, string）的 pointer，通常需要宣告一個變數或者寫一個輔助函數。這在定義 struct 的 literal 時特別煩人，尤其是當 struct 欄位是 *bool 或 *int 用來區分「零值」與「未設定」的時候。

回顧過去，我們為了這個小需求付出了不少努力：

在 Go 1.18 泛型出現之前：我們經常需要定義一堆如 Int64Ptr(v int64) *int64 或 Float64Ptr(v float64) *float64 的輔助函數（AWS SDK 的使用者應該對此非常熟悉）。
匿名函數大法：如果不想要定義全域的輔助函數，有時甚至會看到像 enabled := func(b bool) *bool { return &b }(true) 這種冗長且難讀的寫法。
泛型時代：雖然可以用一個通用的 ptr[T] 解決，但還是需要額外的程式碼。

以前我們可能需要這樣做：

func ptr[T any](v T) *T {
    return &v
}

type Config struct {
    Enabled *bool
}

conf := Config{
    Enabled: ptr(true),
}

在 Go 1.26 中，內建的 new 函數得到了增強，現在它不僅接受型別，還可以直接接受表達式（Expression）。

Interface 不是有開就好：從一個 PR 來看抽象化的重要性

raiven.kao@gmail.com (Raiven Kao) — Sat, 04 Oct 2025 00:00:00 +0000

前言

最近團隊正在開發一個新產品，其中一個核心功能需要 client 與 server 之間進行即時、雙向的溝通。經過一番技術評估，我們決定採用 WebSocket 來實現這個需求。

身為一個良好習慣的開發團隊，我們在開發初期就導入了依賴注入（Dependency Injection），希望透過界面（Interface）來解耦商業邏輯與具體的實作，這樣不僅能提高程式碼的可測試性，未來在更換底層實作時也能更加輕鬆。

一切聽起來都很美好，直到我在一次 Code Review 中，看到了一段熟悉的程式碼。

一個 PR 的故事

在我們的 Domain Layer，也就是處理核心商業邏輯的地方，我看到同事定義了下面這個 interface：

// package/to/domain/service.go

// WebSocketService defines the interface for websocket communication.
type WebSocketService interface {
    // StartAndLinsten starts the service and listens for incoming messages.
    StartAndLinsten(ctx context.Context) error

    // Send sends a message to the client.
    Send(ctx context.Context, message any) error

    // ... other methods
}

第一眼看過去，好像沒什麼大問題。有名稱、有方法、也確實是個 interface。然而，當我細看 WebSocketService 這個命名時，總覺得哪裡怪怪的。

於是我在 PR 上留下了這樣的 comment：

這個界面主要是抽象化 client 與 server 間的互動，不應該侷限於 WebSocket 這個 Protocol。假如我們未來要換成使用 socket.io 或是 gRPC stream，是不是連 domain 層的 interface 也要跟著改動？

監控你的執行檔：初探 watchexec

raiven.kao@gmail.com (Raiven Kao) — Sat, 06 Sep 2025 00:00:00 +0000

前端開發有 liveserver，後端開發有 air，那 TUI 開發呢？本文記錄了我在開發 Bubbletea 應用時，從 air 轉向 watchexec 的心路歷程，以及如何使用這個通用工具來優雅地實現終端機應用的熱重載。

用 Golang Bubbletea 打造終端機應用：從 Hello World 到多頁面架構

raiven.kao@gmail.com (Raiven Kao) — Fri, 05 Sep 2025 00:00:00 +0000

探索如何使用 Golang 的 Bubbletea 函式庫，基於 Elm 架構，從零開始打造一個互動式終端機應用（TUI）。本文將從一個簡單的計數器範例，逐步引導你建構出一個類似 Web 應用的多頁面架構，並分享整個生命週期中的關鍵概念與注意事項。

如何利用 Golang AST 助攻 LLM 省 token 又高效

raiven.kao@gmail.com (Raiven Kao) — Mon, 16 Jun 2025 00:00:00 +0000

前言

近來大型語言模型（LLM）的發展可謂一日千里，特別是在程式碼理解、生成與輔助開發方面，展現出了驚人的潛力。許多開發者開始嘗試將 LLM 融入到日常工作中，期望能提昇開發效率，甚至實現所謂的「vibe coding」——讓 LLM 理解程式碼的整體風格與意圖，並在此基礎上進行協作。

然而，當我們試圖讓 LLM 直接「閱讀」整個大型專案的程式碼庫時，往往會碰到一些現實的挑戰。上下文長度限制、高昂的 token 消耗以及潛在的雜訊干擾，都可能讓 LLM 的表現不盡如人意。這時候，我們就需要更聰明的方法來為 LLM「提煉」程式碼的精華。

在這篇文章中，我想分享一個在 Golang 專案中可能被忽略的利器：抽象語法樹（Abstract Syntax Tree, AST）。透過 Golang AST，我們可以更精準地提取程式碼的結構資訊，為 LLM 提供一份濃縮且高效的上下文，既能節省寶貴的 token，又能幫助 LLM 更好地把握「Code Vibe」。

LLM 直接消化大型 Code Base 的「痛」

想像一下，你正在開發一個頗具規模的 Golang 後端服務，裡面包含了數十個套件、數百個檔案。現在，你想讓 LLM 幫你新增一個功能，或者重構某個模組。如果直接把所有相關的程式碼一股腦地丟給 LLM，可能會遇到以下這些令人頭痛的問題：

token 消耗「爆表」：LLM 的使用成本與輸入輸出的 token 數量直接相關。將大量原始碼作為輸入，無疑會產生巨額的 token 費用，對於個人開發者或小型團隊來說，這可能難以承受。
「腦容量」不足的上下文限制：即使是目前頂尖的 LLM，其能夠處理的上下文長度也是有限的。面對龐大的程式碼庫，LLM 可能無法一次「看」全所有必要的資訊，導致理解片面或生成結果不佳。
資訊過載與雜訊干擾：完整的程式碼中，充斥著各種細節——註解、空行、詳細的錯誤處理邏輯、暫時用不到的私有函式等等。這些資訊對於 LLM 理解程式碼的「vibe」或執行特定高層次任務（例如「模仿現有風格新增一個 API 端點」）來說，有時反而會成為雜訊，影響其判斷。
龜速的回應：通常情況下，輸入給 LLM 的資訊越多，它處理並生成回應所需的時間就越長。在追求高效開發的今天，漫長的等待顯然不是我們想要的。

面對這些挑戰，我們不禁要問：有沒有一種方法，可以只給 LLM「剛剛好」的資訊，讓它既能理解我們的意圖，又能高效地完成任務呢？Golang AST 或許就是答案的一部分。

Golang AST 如何「助攻」

在我們深入探討 AST 如何幫助 LLM 之前，先快速回顧一下什麼是 Golang AST。

一次核心模組的重構經驗

raiven.kao@gmail.com (Raiven Kao) — Sat, 14 Jun 2025 00:00:00 +0000

前言

在軟體開發的漫漫長路中，我們時常會接手一些充滿「歷史印記」的專案。這些專案的核心模組，往往因為業務的快速迭代與時間的無情沖刷，逐漸演化成難以觸碰的「史前巨獸」。近期，我便有幸（或許該說是不幸地）參與了一次這樣核心模組的重構之旅，其核心是我們產品線廣泛使用的 Golang gRPC 認證攔截器 (Interceptor)。這段經歷充滿挑戰，但也收穫良多，希望能藉此分享一些心得。

歷史的塵埃：核心模組的演進悲歌

我接手的這個核心認證模組，在專案初期或許設計簡潔明瞭，但隨著產品線的不斷擴展和需求的堆疊，其複雜度已然失控。追溯其演進的脈絡，彷彿能看到一部小型技術債的形成史。

最初的起點：單純的 gRPC Interceptor

可以想見，專案伊始，對於 gRPC 服務的認證需求相對單純。一個通用的攔截器或許就能滿足所有需求，程式碼結構清晰可見：

package main

func SimpleAuthInterceptor(...) {
    log.Println("Performing basic authentication via SimpleAuthInterceptor")
    return handler(ctx, req)
}

func SimpleStreamAuthInterceptor(...) error {
    log.Println("Performing basic stream authentication via SimpleStreamAuthInterceptor")
    return handler(srv, ss)
}

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    s := grpc.NewServer(
        grpc.UnaryInterceptor(SimpleAuthInterceptor),
        grpc.StreamInterceptor(SimpleStreamAuthInterceptor),
    )

    log.Println("gRPC server listening on :50051")
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

在這個階段，一切看起來是那麼的美好與純粹。

Golang Iterator 簡介與 samber/lo 比較

raiven.kao@gmail.com (Raiven Kao) — Sat, 31 May 2025 00:00:00 +0000

自從 Golang 1.18 版本引入泛型（Generics）後，Go 語言的生態系統迎來了許多令人興奮的變化。其中，Golang 1.23 版本對 Iterator（迭代器）的標準化，以及 iter 套件的加入，無疑是近期改動中相當重要的一環。本文將淺談 Golang Iterator 的基本概念，深入探討 Pure Iterator 與 Impure Iterator 之間的區別與設計考量，並與社群中流行的 samber/lo 工具庫進行比較。

什麼是 Iterator？

Iterator Pattern（迭代器模式）是一種常見的設計模式，它提供了一種循序存取集合物件中各個元素的方法，而又無需暴露該物件的內部表示。簡單來說，Iterator 就像一個指針，可以依序指向集合中的下一個元素，直到遍歷完所有元素為止。

Golang 中的 Iterator

在 Golang 1.23 之前，我們通常透過 for-range 迴圈來迭代 array、slice、string、map、channel 等內建資料結構。然而，對於自訂的資料結構或複雜的序列生成邏輯，缺乏一個統一的迭代標準。

Golang 1.23 版本正式將 Iterator 標準化，並在標準庫中加入了 iter 套件。同時，slices 和 maps 套件也增加了一些回傳 Iterator 的工廠函數（Iterator Factories）。到了 Golang 1.24，更有如 strings.SplitSeq 等函數加入，進一步豐富了 Iterator 的應用場景。

// strings.SplitSeq 回傳一個迭代器，用於遍歷由 sep 分隔的 s 子字串。
// 此迭代器產生的字串與 Split(s, sep) 回傳的相同，但不會建構整個 slice。
// 它回傳一個單次使用的迭代器。
func SplitSeq(s, sep string) iter.Seq[string]

如果對 Golang 1.23+ 中 Iterator 的語法和語義還不熟悉，建議可以閱讀 Ian Lance Taylor 在 Go 官方部落格發表的介紹文章

建構多平台的 container image

raiven.kao@gmail.com (Raiven Kao) — Sun, 30 Mar 2025 00:00:00 +0000

前言

最近在搞 side project 時，常常需要在不同的 CPU 架構上跑我的應用程式。例如，開發用的 MacBook 是 ARM 架構 (Apple Silicon)，開發用的 Desktop 是 x86 架構（Ryzen 5900X），而部署的伺服器可能是 x86 (AMD64)，有時候甚至想在 Raspberry Pi (ARM) 上跑些小東西。每次都要為不同平台分別建構 image 實在有點麻煩，而且 Registry 上一堆 xxxapp-amd64, xxxapp-arm64 的 tag 看了也很礙眼。經過一番研究與嘗試，是時候接觸 Docker Buildx 了。

為什麼需要多平台映像檔

在 wintel 的商業策略下，以及大家對高性能伺服器的普遍認知，主要用 x86/amd64，但現在 ARM 架構越來越普及，從 Apple Silicon 的 Mac、AWS Graviton 處理器、各種 IoT 設備到你的 Raspberry Pi，ARM 無所不在。如果你的 container image 只支援 amd64，那它就無法在這些 ARM 設備上原生運行 (需要模擬，效能差)。為了Build Once, Run Anywhere，多平台映像檔 (Multi-platform images) 就是 meta。

OCI 多平台映像檔架構簡述

其實不複雜。傳統的單一平台 image，它的 manifest 指向一組設定檔和一堆 layer。而多平台 image 則是透過一個 manifest list (索引) 指向多個特定平台的 manifest。每個特定平台的 manifest 才各自指向該平台的設定檔和 layer。

使用 go work 在本地開發解決同時開發 module 的問題

raiven.kao@gmail.com (Raiven Kao) — Thu, 20 Feb 2025 00:00:00 +0000

在 Golang 1.18 中 go workspace 的提案釋出後，golang 的官方文件或多或少也提到應該要怎麼做 multi module 的開發。相較於過去需要不斷的替換 go.mod 內的 replace 指令，go work 大幅改善了 multi module 的開發體驗。

為什麼需要 go work

專案逐漸變大

當你在維護一個小工具 side project 時，單一的 module 就能夠滿足所有需求，但當專案逐漸變大，會需要將專案拆分成多個 module。可以透過一個例子來理解：假設我們有一個專案，拆分成以下兩個 module：

common-lib-golang: 存放所有專案都會用到的 function，例如 retry, logger, tracer 等等
backend: 實際提供 http api 的程式碼

最開始的檔案架構為：

.
├── backend
│   ├── go.mod
│   ├── go.sum
│   └── main.go
└── common-lib-golang
    ├── go.mod
    ├── go.sum
    └── util.go

隨著專案變大，我們在開發 backend 時，時常會需要修改 common-lib-golang 內的程式碼，這時候就需要 go work 來協助我們。

在習慣 go mod 後重新學習 git submodule

raiven.kao@gmail.com (Raiven Kao) — Fri, 24 Jan 2025 00:00:00 +0000

前言

使用 Golang 作為主要開發已經有五年的時間。最近因工作需要接觸到 Python 專案，並且該專案使用 git submodule 的方式來引用共同函式庫 common-lib-python。對於長久使用 Golang 的 go mod 的我來說，submodule 是一個相對陌生的概念。藉這個機會撰寫一篇文章，整理並紀錄一下 git submodule 的用法，也作為未來的參考。

這篇文章會假設已經對 git 的基本操作有一定程度的了解，並著重在 submodule 的概念、使用情境以及與 Golang 的 go mod 的差異比較。文章內容會以下列流程來呈現：

建立一個新的 Python 專案 my-python-repo
建立一個 Python 模組 my-python-module 作為 submodule
在 my-python-repo 中使用 my-python-module 作為 submodule
模擬需求變更，同時修改 my-python-repo 與 my-python-module，並分別發送 PR
與 Golang 的 go mod 進行比較

建立 Python 專案與模組

先建立兩個新的 git repo，分別是 my-python-repo 與 my-python-module。

# 建立 my-python-repo
mkdir my-python-repo
cd my-python-repo
git init
touch main.py
git add .
git commit -m "Initial commit"

# 建立 my-python-module
cd ..
mkdir my-python-module
cd my-python-module
git init
touch my_module.py
git add .
git commit -m "Initial commit"

# 將兩個專案 push 到 Github/Gitlab 上

my-python-repo 與 my-python-module 都已經是一個獨立的 git repo。

Golang Composition over Inheritance

raiven.kao@gmail.com (Raiven Kao) — Sat, 11 Jan 2025 00:00:00 +0000

Golang 是一門簡潔有力的程式語言，相較於其他程式語言，更傾向於使用組合（composition）而不是繼承（inheritance），語言設計之初更是沒有提供繼承的關鍵字，這種設計哲學讓 Golang 在現代軟體開發中脫穎而出。

繼承固然有其優點，但在建構複雜的物件關係時，容易產生過於龐大的繼承層級結構。這使得程式碼難以閱讀和維護，就像是一棵盤根錯節的大樹，牽一髮而動全身。

過深的繼承層級會導致知名的「脆弱基類問題」(fragile base class problem)，使得程式碼難以修改和擴展。

組合則不同，它鼓勵建立小型、專注的 struct，然後像樂高積木一樣，將這些 struct 組合成更大的結構。這種方式讓程式碼模組化，更容易理解和修改。

彈性

Golang 的 type system 支援我們靈活地組合各種 struct。可以建立一個新的 struct，並在其中「嵌入」其他 struct 作為其欄位。

type Car struct {
    make  string
    model string
    year  int
}

type Driver struct {
    name string
    car  Car
}

func main() {
    myCar := Car{"Toyota", "Camry", 2020}
    driver := Driver{"John", myCar}
    fmt.Println(driver.name)         // 輸出: John
    fmt.Println(driver.car.make)    // 輸出: Toyota
}

在這個例子中，Driver 透過組合 Car 來建立更豐富的資料結構。Driver 「has-a」 Car，而不是「is-a」 Car，這提供了更高的彈性，讓 Driver 可以更專注在自身的邏輯。

程式碼複用

組合促進了程式碼的複用。可以建立許多小型、可複用的 struct，然後將它們組合成各種不同的結構。

繼承也能實現程式碼複用，但它也可能導致不必要的耦合，使得程式碼難以修改，因為對父類別的修改可能會影響到所有子類別。

type Engine struct {
    power      int
    fuelType   string
}

type Wheels struct {
    count      int
    material   string
}

type Vehicle struct {
    engine Engine
    wheels Wheels
    brand  string
}

func (v Vehicle) getBrand() string {
    return v.brand
}

func (v Vehicle) getEnginePower() int {
    return v.engine.power
}

在這個例子中，Vehicle 透過組合 Engine 和 Wheels 來複用這兩個 struct 的欄位和功能。Vehicle 「has-a」 Engine and 「has-a」 Wheels，並可以新增自己的欄位和方法，例如 brand、getBrand() 和 getEnginePower()。這種方式讓 Vehicle 可以專注於自身的邏輯，同時又能複用 Engine 和 Wheels 的功能。

Golang 1.22 中 http routing 的改進

raiven.kao@gmail.com (Raiven Kao) — Wed, 30 Oct 2024 00:00:00 +0000

Golang 作為一個偏向 server 應用的程式語言，一般的 web server 並不會直接使用原生的 package net/http，而更多的使用 gin-gonic/gin 或是 gorilla/mux，後來也有 labstack/echo 以及 go-chi/chi 等等選擇，在效能、輕量、好維護、好擴充中，都能找到對應的 third party package，其中的原因不外乎是原生的 package 提供的功能過於簡潔。

好在 1.22 中，官方改進了 net/http 中對於多工器、路由，甚至出了一篇部落格，現在更可以「大膽的」直接使用 standard library。

Path Parameter

若要將應用的 Web API 定義成 RESTful，我們會使用 /資源/{資源唯一識別符}/子資源/{子資源唯一識別符} 來定義路徑。假如要獲取一個使用者的訂單，則會使用 GET /users/1/orders 來獲取。在 1.22 以前，我們只能定義到 /users，再自行解析往後的 path：

http.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
    subPath := strings.TrimPrefix(req.URL.Path, "/users/")
    if len(subPath) == 0 {
        xxx
    } else {
        ooo
    }
    ...
})

而在 1.22 中新增了 net.http 對 path parameter 的支持，我們可以直接使用 (*http.Request).PathValue("xxx") 來獲取：

http.HandleFunc("/users/{user_id}", func(w http.ResponseWriter, r *http.Request) {
    userID := r.PathValue("user_id")
    ...
})

不過也帶來一些限制

使用 TinyGo 與 Raspberry pi pico 實現溫濕度感測器

raiven.kao@gmail.com (Raiven Kao) — Wed, 02 Oct 2024 00:00:00 +0000

前言

作為嵌入式系統學習的微小專案，我決定使用 TinyGo 來實現一個簡單的溫濕度感測器。過去我大多使用 Arduino 作為微控制器（MCU）開發平台，但這次想嘗試使用 TinyGo 來進行單片機的學習。 TinyGo 是 Go 語言的一個子集，專門針對小型設備和微控制器進行了優化，使得我們可以在資源受限的硬體上運行 Go 程式。

全部的程式碼都可以到 omegaatt36/pico-bme280 中找到。

硬體選擇

Raspberry Pi Pico

我選擇了 Raspberry Pi Pico 作為本專案的主控板。Pico 是一款基於 RP2040 晶片的微控制器開發板，具有以下特點：

雙核 ARM Cortex-M0+ 處理器，時脈可達 133 MHz
264KB 的 SRAM 和 2MB 的板載閃存
支援 USB 1.1 主機和設備功能
低功耗睡眠和休眠模式
可編程 I/O（PIO）狀態機
30 個 GPIO 引腳
便宜

價格僅需要 5 美元，後繼款的 Pico 2 仍然維持 5 美元，還額外增加了 RISC-V 架構的支援，可以一次玩到兩種處理器架構。 Pico 的這些特性使其非常適合用於各種嵌入式專案，包括我們的溫濕度感測器。

BME280 感測器

最初我購買了 BMP280 感測器，但後來發現它只能測量溫度和氣壓，無法測量濕度。因此，我轉而選擇了 BME280 感測器，它可以同時測量溫度、濕度和氣壓。

BME280 是一款精確度高、體積小、待機功耗低的環境感測器。但當連續偵測時，通過的電流會導致 sensor 功耗上升，進而導致測量到過高的溫度。

透過內建的 pprof 工具來分析 Golang 發生的 memory leak

raiven.kao@gmail.com (Raiven Kao) — Sat, 17 Aug 2024 00:00:00 +0000

前言

某天下午，公司的 cronjob daemon 無預警的被 GCP OOM Kill 了，且程式碼沒有看出明顯的原因。

根據過去的經驗，local 開發時會使用 go tool pprof 來分析 CPU profile 或是 memory 與 trace 的問題，詳細可以參考 Go 官方文件。

由於我們的程式碼是一個基於 gin 的 http service，因此可以使用 gin 提供的 pprof 來快速建立 endpoint。

gin pprof

gin 的 pprof package 提供了數個基於 net/http/pprof 的 endpoint，可以分別為：

/: 基本的 pprof 的 static page，可以分析 CPU 與 memory 的問題。
/cmdline: 分析 command line 的問題。
/profile: 分析 CPU profile 的問題，可以透過 query string 來指定 CPU profile 的 duration。
/symbol: 分析 symbol table 的問題。
/trace: 分析 trace 的問題。
/goroutine: 分析 goroutine 的問題，這也是本文中重點查看的 endpoint。
/heap: 分析 heap 的問題。

可以在 http server 中加入以下程式碼來啟用 pprof：

基於 Golang 的 Grafana Dashboard 與 JWT 認證的前後端實作

raiven.kao@gmail.com (Raiven Kao) — Mon, 10 Jun 2024 00:00:00 +0000

在工作上有一個需求是需要做一些 OLAP，原訂計畫是使用 Google Looker(ver. Google Cloud Core)，礙於量小不符合經濟效益，決定用 Grafana 這個較熟悉的開源套件來幫助我們做視覺化的處理。

這篇文章的範例可以在 omegaatt36/grafana-embed-example 中找到所有的 source code

我的 Use Case 為已經有一組 SHA512 產生的 Key，以下的內容為使用 HS512 進行簽名與認證。

流程

sequenceDiagram
    autonumber
    participant U as User
    participant B as Browser
    participant I as iframe
    participant S as Server
    participant G as Grafana

    rect rgb(236,239,244)
    U->>B: Open Web Page
    B->>S: Request JWT Token
    S->>B: Return JWT Token
    B->>I: Load iframe
    I->>G: Request Dashboard with JWT Token
    G->>I: Return Dashboard
    I->>B: Display Dashboard in iframe
    B->>U: Show Dashboard
    end

Grafana

配置

主要是針對 grafana.ini 做修改

用 testcontainers 在本地開發 Go 應用程式

raiven.kao@gmail.com (Raiven Kao) — Sun, 19 May 2024 00:00:00 +0000

介紹

使用 testcontainers 是在本地開發 Golang 應用程式的一個高效方式。這可以讓我們在不需要依賴外部環境的情況下，模擬應用程式在實際生產環境中的運行狀況。

安裝 testcontainers

在 Go 專案中，我們可以通過以下指令來導入 testcontainers

go get github.com/testcontainers/testcontainers-go

透過 Redis 實踐一個 rate limiter

package user

type Limiter struct {
    client *redis.Client

    limit         int
    limitPeriod   time.Duration // 1 hour for limitPeriod
    counterWindow time.Duration // 1 minute for example, 1/60 of the period
}

func NewLimiter(client *redis.Client, limit int, period, expiry time.Duration) *Limiter {
    return &Limiter{
        client: client,

        limit:         limit,
        limitPeriod:   period,
        counterWindow: expiry,
    }
}

func (r *Limiter) AllowRequest(ctx context.Context, key string, incr int) error {
    now := time.Now()
    timestamp := fmt.Sprint(now.Truncate(r.counterWindow).Unix())

    val, err := r.client.HIncrBy(ctx, key, timestamp, int64(incr)).Result()
    if err != nil {
        return err
    }

    if val >= int64(r.limit) {
        return ErrRateLimitExceeded(0, r.limit, r.limitPeriod, now.Add(r.limitPeriod))
    }

    r.client.Expire(ctx, key, r.limitPeriod)

    result, err := r.client.HGetAll(ctx, key).Result()
    if err != nil {
        return err
    }

    threshold := fmt.Sprint(now.Add(-r.limitPeriod).Unix())

    total := 0
    for k, v := range result {
        if k > threshold {
            i, _ := strconv.Atoi(v)
            total += i
        } else {
            r.client.HDel(ctx, key, k)
        }
    }

    if total >= int(r.limit) {
        return ErrRateLimitExceeded(0, r.limit, r.limitPeriod, now.Add(r.limitPeriod))
    }

    return nil
}

type RateLimitExceeded struct {
    Remaining int
    Limit     int
    Period    time.Duration
    Reset     time.Time
}

func ErrRateLimitExceeded(remaining int, limit int, period time.Duration, reset time.Time) error {
    return RateLimitExceeded{
        Remaining: remaining,
        Limit:     limit,
        Period:    period,
        Reset:     reset,
    }
}

func (e RateLimitExceeded) Error() string {
    return fmt.Sprintf(
        "rate limit of %d per %v has been exceeded and resets at %v",
        e.Limit, e.Period, e.Reset)
}

創建和啟動 Redis 容器

正式的產品通常會使用 config 來管理 Redis 位置，這個 demo 中直接使用 localhost:6379 來展示。

如何利用 Open Policy Agent 配合 Golang 建構彈性的 RBAC 模組

raiven.kao@gmail.com (Raiven Kao) — Thu, 04 Apr 2024 00:00:00 +0000

RBAC 概念簡介

在我們探討如何利用 Open Policy Agent (以下簡稱 OPA) 和 Golang 建立一個彈性的 RBAC 模組之前，先讓我們來了解一下 RBAC的基本概念。

RBAC（Role-Based Access Control，基於角色的訪問控制）是一種廣泛應用的訪問控制策略，在軟體安全性領域尤為重要。其核心思想是將系統訪問權限與用戶的角色（職位、責任或職務）關聯起來，而不是直接與個別用戶關聯。這意味著訪問權限被捆綁到角色上，然後將用戶分配給這些角色。舉個例子，一個「管理員」角色可能有權訪問系統的所有資源，而「員工」角色則只能訪問特定部分的資源。

RBAC 的主要優勢在於其靈活性和簡化的權限管理。當需要變更權限時，只需修改角色的訪問權限，而不需要為每個用戶單獨設定。這不僅使權限管理更為高效，也減少了錯誤配置的可能性，提高了整體的系統安全性。

在實踐中，RBAC 允許創建精細且靈活的策略，以滿足複雜的商業和安全需求。無論是大型企業還是小型團隊，RBAC 都提供了一個可靠的框架，來確保正確的用戶擁有適當的訪問權限，從而保護關鍵資源免受未授權訪問。

可以參考 Cloudflare 的文章，簡單來說就是什麼「角色」能夠對什麼「資源」做什麼「操作」。

Open Policy Agent (OPA) 介紹

OPA 是一個「Strategy as Code」的開源專案，專門設計用於統一地管理和執行跨不同系統的策略。它不僅提供了一個高級的策略語言——Rego，還支援將策略作為代碼與應用程式的其他部分一同存儲、版本控制和部署。OPA 的這種設計使其能夠輕鬆集成到微服務、Kubernetes、CI/CD 管道、API 網關等多種環境中。顯著特點是其策略的編寫方式。Rego 是一種專門為策略和規則定制的查詢語言，它使開發者能夠以聲明式方式描述策略和規則，從而確保這些策略既容易理解又易於維護。這對於建立複雜的 RBAC 系統尤為重要，因為它允許策略的靈活性和可擴展性，同時又保持了清晰和易於審查的結構。

我們可以利用 OPA 提供的 API 來評估和執行這些策略。這意味著開發者可以在 Golang 程式碼中直接嵌入策略判斷的邏輯，從而實現動態、細粒度的訪問控制。這種方法的一個優點是，它支援在 runtime 動態更新策略，或是編譯進 binary，從而提供更大的靈活性和即時性。

整合 OPA 與 Golang

透過官方案例來了解如何使用

參考了 OPA 官方的 rbac 章節，並加以修改。使用最簡單的例子：

admin can read user
bob is admin
-------------------
bob can read user

轉化成 RBAC 模型即為：

Golang 隱式記憶體別名 Implicit Memory Aliasing 與其檢測方法

raiven.kao@gmail.com (Raiven Kao) — Sun, 12 Nov 2023 00:00:00 +0000

在使用 Golang 時，我們可能會遇到一種稱為隱式記憶體別名（Implicit Memory Aliasing）的問題。這篇文章將探討這個問題以及如何使用工具和語言特性來解決它。

隱式記憶體別名的問題

隱式記憶體別名主要發生在 range 語句中。當使用 range 對一個切片 slice 或映射 map 進行迭代時，Iterator 在每次迭代中並不是唯一的實例。這可能導致意外的行為，特別是在並發環境或當迭代變量被指針引用時。

slice with Implicit Memory Aliasing

下面示例可能是基本的 golang 面試題，會問你迭代後的 pointers 內的 Name 為何答案是 Joe Joe Joe

package main

import "fmt"

type Person struct {
	Name   string
	Gender string
}

func main() {
	persons := []Person{
		{Name: "John", Gender: "M"},
		{Name: "Jane", Gender: "F"},
		{Name: "Joe", Gender: "X"},
	}

	pointers := make([]*string, len(persons))
	for index, person := range persons {
		fmt.Printf("%p, %p, %p, %v\n", &person, &person.Name, &person.Gender, &persons[index].Name)
		pointers[index] = &person.Name
	}

	for index := range pointers {
		fmt.Println(pointers[index], *pointers[index])
	}
}

channel with Implicit Memory Aliasing

同樣的情況也會發生在 channel 的迭代。

golang 樂觀鎖、悲觀鎖學習筆記與實驗

raiven.kao@gmail.com (Raiven Kao) — Sun, 14 May 2023 00:00:00 +0000

介紹

改變數值的三個步驟

取出
修改
保存

但這三者間的時間差在不同 process、不同 thread、不同 corutine/goroutine 中會造成競爭危害(race condition)。

可以使用多種發法確保並行(concurrency)處理時保持資料的一致性，這裡介紹的是最常使用的悲觀鎖與樂觀鎖。

悲觀鎖: 總可能發生問題

lock
(1) 取值
(2) 修改
(3) 保存
unlock

樂觀鎖: 不會總是發生問題

(1) 取值
if *addr == old {
    (2) 修改
    (3) 保存
    return true
}
return false

悲觀鎖

golang 中主要使用 sync.Mutex 作為悲觀鎖，看似會阻塞住其他 goroutines，但其實 sync.Mutex 中也使用到了 CAS。

sync.Mutex 中有一個 int32 的 state 與 uint32 的 sema(semaphore)

type Mutex struct {
	state int32
	sema  uint32
}

const (
	mutexLocked = 1 << iota // mutex is locked
	mutexWoken
	mutexStarving
	mutexWaiterShift = iota
    starvationThresholdNs = 1e6
)

func (m *Mutex) Lock() {
	if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
		if race.Enabled {
			race.Acquire(unsafe.Pointer(m))
		}
		return
	}
	m.lockSlow()
}

state:

golang 中使用 Line LIFF 實作 Single Sign-On

raiven.kao@gmail.com (Raiven Kao) — Sat, 22 Apr 2023 00:00:00 +0000

文章中的程式碼放在https://github.com/omegaatt36/line-verify-id-token中。

Requirements

Line Login Channel
- channel id
- channel secret
Line LIFF APP
- 用 liff.getIDToken() 獲取 ID Token

在現代網站中，單一登錄 (Single Sign-On, SSO) 已經成為了一個普遍存在的功能，它能夠讓使用者在不同的應用程式和服務之間自動地登錄，而不需要再輸入帳號和密碼。這樣可以方便使用者的使用，並且也能夠增加安全性，減少帳號密碼被盜用的風險。

我們將使用 Golang 語言來實作單一登錄功能，並且使用 Line LIFF 來進行身份驗證。在此之前，我們需要先了解幾個概念。

Line LIFF (Line Front-end Framework) 是一個由 Line 提供的 Web 應用程式框架，開發者可以使用它來建立 Line 的客戶端應用程式。使用 Line LIFF 開發的應用程式可以在 Line 客戶端中被直接執行，而不需要額外安裝或下載。此外，Line LIFF 還提供了一些功能，例如使用者的身份驗證、分享資料等等。

JWT (JSON Web Token) 則是一種開放標準，用於在不同系統之間安全地傳輸訊息。它通常用於認證和授權，因為它可以確保傳輸的訊息是可信的，而且在傳輸過程中不會被竄改。

我們可以使用 Line 的 Verify API，同時也可以選擇後端自己驗證，解出 jwt 中的資訊。

我們的目的是拿到每個使用者在 Line 的 UserID，做為身分識別。於是根據 Line 提供的 JWT 欄位對應，定義一個結構用來存放驗證後的資訊。

// DecodedIDToken defines decoded payload by id token.
type DecodedIDToken struct {
	Amr       []string
	ChannelID string
	Email     string
	ExpiredAt int64
	IssuedAt  int64
	Issuer    string
	Name      string
	Picture   string
	UserID    string
}

接著撰寫一個驗證 ID Token 的 function 用來驗證

跟風寫了個使用 OpenAI API 的 Telegram Chat Bot

raiven.kao@gmail.com (Raiven Kao) — Fri, 17 Mar 2023 00:00:00 +0000

前言

放在最前面 Github repo

原本打算使用別人寫好的 bot，免費的版本均是透過儲存 cookies 的方式，直接透過 ChatGPT 網頁建立新的「Chat」。好景不常，OpenAI 馬上把登入頁面到聊天頁面中間安插了類似 reCaptcha，來驗證是否為真人。看到有好心人提供了 go 版本的 OpenAi API，就打算自己寫一寫，順便當作《Clean Architecture》的讀後作業。

依賴注入

~~架構圖待補~~

我需要對 OpenAI 詢問，並用 stream(逐字)的方式回給我，也需要對 Telegram 逐字回答。

在這個 8931bf 版本中，很明確定義對於 OpenAI 與 Telegram 的 usecase

chatgpt_usecase.go

// ChatGPTUseCase defines ChatGPT send question use case.
type ChatGPTUseCase interface {
	Stream(ctx context.Context, question string) (<-chan string, <-chan error)
}

telegram_usecase.go

// TelegramUseCase defines telegram send message use case.
type TelegramUseCase interface {
	SendAsLiveOutput(chatID int64, feed <-chan string) error
}

在 *_repository.go 進行實作。並在 main.go 中依賴反轉，將實作注入近 bot service。

gin 搭配 html/template 包實現動態生成 HTML 文件

raiven.kao@gmail.com (Raiven Kao) — Thu, 26 Jan 2023 00:00:00 +0000

起因

在網站註冊流程中，若是用信箱驗證，網站會寄送一封驗證信到指定的電子信箱。信中可能含有 verify token 或是直接是寫好的 verify URL。至於實作方面我們可以透過 Go 1.16 推出的 Embedding Files 搭配 html/template，實現動態生成 HTML 信件，用以寄送至指定信箱。

本篇內容的詳細程式碼可以到 github 頁面查看。

實作

資料夾結構:

project/
├─ templates/
│  ├─ template.go
│  ├─ success.tmpl
│  ├─ verify.tmpl
├─ main.go

templates

project/templates/template.go

在包內宣告私有變數，透過 Embedding Files 讀出目錄內的所有檔案。
```
package template

//go:embed *
var f embed.FS
```

宣告需要被轉換成 HTML 模板的檔案名 TemplateName，可以用 go-enum 來自動生成變數。並將其註冊進陣列 _TemplateNameNames 內。

package template

// ENUM(
// success.tmpl
// verify.tmpl
// )
type TemplateName string

func (x TemplateName) String() string {
	return string(x)
}

var _TemplateNameNames = []string{
	string(TemplateNameVerifyTmpl),
	string(TemplateNameSuccessTmpl),
}

// TemplateNameNames returns a list of possible string values of TemplateName.
func TemplateNameNames() []string {
	tmp := make([]string, len(_TemplateNameNames))
	copy(tmp, _TemplateNameNames)
	return tmp
}

const (
	TemplateNameVerifyTmpl  TemplateName = "verify.tmpl"
	TemplateNameSuccessTmpl TemplateName = "success.tmpl"
)

最終將 embed files 與檔案名丟給 html/template 包請他們我們轉換成 template。

後端工程師用 Golang 在 WSL 中寫 GUI 是不是搞錯了甚麼 - 安裝篇

raiven.kao@gmail.com (Raiven Kao) — Thu, 26 Jan 2023 00:00:00 +0000

由於先前將 raspberry pi 4b 給賣掉了，bmx280 中基於 bme280 而產生的 exporter 因此失去戰鬥能力，藉此玩玩 tinygo，透過 serial port 透過 raspberry pi pico 對 bme280 讀取溫溼度。在開發過程中發現，WSL 中，command line 輸入:

GOOS=windows go run main.go

這樣會吃 windows 的環境，比如讀 serial port 需要 COM port，這樣就不是去讀 /dev/ttyS4 而是讀 COM4，這 cross compile 也太方便了吧…。

後續在工作上接收了需要寫一個 websocket server/client，而 client 需要:

有圖形化最好 (TUI or GUI)
跑在 windows 桌面上

，開發過程中再次感受到 cross compile 的方便，有點慶幸是在這個一個方便的時代學習敲鍵盤(?

Requirement

Golang 1.16+ ()
Docker or Podman

在 WSL 中建立 X Window System 環境

因為我的 Golang 環境是基於 WSL，於是我需要先準備在 WSL 中能跑的 GUI 環境。在 Unix like 使用的 GUI 被稱之為 X Window System 或 X11 或 X，以所需的情形來說即是需要在 Windows 中啟動 X server，來與 WSL 中的 X client 連線。

Golang 學習筆記 Day 0 - Why Golang & 安裝篇

raiven.kao@gmail.com (Raiven Kao) — Tue, 25 Aug 2020 00:00:00 +0000

免責聲明，此篇為個人學習筆記，非正式教學文，僅供參考感謝指教，有任何內容錯誤歡迎發 issue。

Why Golang

在高中時期，除了一年級上學期是用 C 打開程式大門之外，大家都知道的，畫金字塔、 cin 、 cout 等等基本的邏輯觀念，一年級下學期開始就是 C#、HTML、PHP，也玩轉在 CPLD、Arduino、焊三角錐、兩根同軸焊接，總之就是全部吃掉就對了，雖然都是皮毛但不至於完全沒印象。

然而到了大學，敝人不才沒有考上一般大學，也沒考上工科第一二志願科大，在整個大學過程碰了最多的反而是 python、machine learning。然而也都是碰皮毛~~因為都在玩社團、學攝影~~，事實上在大學時期程式功力已荒廢大半。

所幸在實習期間，公司願意提供環境讓我邊學習邊成長後做出貢獻，而使用的後端語言是 PHP，然而就一年以來的使用 PHP 有以下優缺點：

學習曲線極低，但坑很多
解釋型腳本語言部署極方便
非靜態、非強行別、萬用 array 導致容易出現很多偷懶的 code
窮人聖經 LAMP、LNMP
歷史悠久 framework 眾多、工作好找，甚至有許多 C 底層的高校框架可以使用。
可以很 OO 也可以不 OO，寫 code 彈性極大
在 php 7.0 改用 zend 引擎後效能改頭換面，「原來 PHP 也可以寫遊戲」。搭配一些 C 底層框架，甚至可以跟 nodeJS 一較高下，而期望中 8.0 效能將再更高。

但是，再快也只是 AE86，腳本語言終究與「高效」存在矛盾，同時，與其在 PHP 中配合 IDE 使用 type hinting 自我約束，何不直接寫強行別語言呢?? 然而在看過許多主流 web service 語言後，最後決定來學學 Golang，而關於 golang 的優勢，可以點擊下方圖片看更多詳細。

Golang 學習筆記 Day 1 - Getting started

raiven.kao@gmail.com (Raiven Kao) — Tue, 25 Aug 2020 00:00:00 +0000

免責聲明，此篇為個人學習筆記，非正式教學文，僅供參考感謝指教，有任何內容錯誤歡迎發 issue。

在前一天介紹了為何要使用 golang、安裝過程以及基本的 hello world，這天將重點放在最基本的 golang 程式碼特徵。

packages

正如昨天關於 hello world 的解析中提到的，每個程式都是由一到多個 packages 組成的，也就是 .go 中必須宣告該檔案是哪個 package，且同一個資料夾中僅接受 xxx 以及 xxx_test 兩種 package名稱，也就是該 package 的名稱以及測試檔的「測試包」。

至於 package 要怎麼命名呢，首先要提到檔案該如何命名，雖然 go format 是對於程式碼風格十分嚴格的，但是對於檔案名稱似乎就沒那麼嚴謹，但整個社群中普遍會用 snake_case 或是 dash-case 作為檔案 (甚至是 package) 的命名。

aaabbbccc.go
time-machine.go
battery_charger.go

但是需要注意的是 go build 會忽略所有以 _ 或是以 . 作為結尾的後綴， underline 可能會導致在建構時被忽略。

再來提到 package 到底要如何命名呢，官方文檔中明確的提到不要用 camelCase 以及 snake_case 。

The style of names typical of another language might not be idiomatic in a Go program. Here are two examples of names that might be good style in other languages but do not fit well in Go:

RESTful server based on golang

raiven.kao@gmail.com (Raiven Kao) — Thu, 19 Mar 2020 00:00:00 +0000

很高興有個機會製作面試前的測試作業，也就趁這個機會做個筆記以及學習紀錄。

前置作業

先點列一下項目需求：

基本需求

based on golnag
The API interface you provide can be any of the following：RESTful、json rpc、gRPC
At least two sources
When a source is unavailable, the result of its last successful ask is returned
Use git to manage source code
Write readme.md and describe what features, features, and TODO which have been implemented

額外可選

Traffic limits, including the number of times your server queries the source, and the number of times the user queries you
Good testing, annotations, and git commit
An additional websocket interface is provided to automatically send the latest information whenever the market changes
Users can choose to use an automatic source determination, the latest data source, or manually specify the source of the data
Package it as a Dockerfile, docker-compose file, or kubernetes yaml
There is a simple front-end or cli program that displays the results
The API you provide has a corresponding file, such as a swagger, or simply a markdown file
Other features not listed but that you thought would be cool to implement

這邊就必須要先打預防針了，這篇僅為學習筆記，並非正式教學。且，我只是 Golang 初學者，所以這篇內也不會出現什麼高等級的解法，甚至也是第一次實作介接 API 呢 (笑)。而 DB 以及 redis 都是直接以方便使用去寫 dbi 而已並無用抽象曾去封裝，也進而導致 unit test 十分困難先擱置了，有空才會再針對性重構，而此次就先將目標專注在 API 介接。

Codewars Find X II in golang

raiven.kao@gmail.com (Raiven Kao) — Tue, 03 Mar 2020 00:00:00 +0000

想不到一眨眼半個月過去了，自從面試趨勢之後整個人彷彿被電到失去信心，在離職與等待面試消息期間，也只好振作補足不足的地方繼續向前。

而 docker 學習心得何時會產出呢？在學習過程中發現除了一般操作(day1 內容)外，底層或多 container 溝通都是大量的網路觀念與知識，需要更多知識量才能整理成筆記，不急不急。

由於學習過程發現而這段時間在 coding 能力上主要還是靠 codewars 上的題目，畢竟解完後能看別人的 code 來檢視自己的 code 能不能更好。其中不免遇到一些覺得很有趣的題目，好比這題 Find X II，他並不是什麼過分難的題目，邏輯也不是很難通，畢竟只是一個 6 kyu 的題目，但為何快一年了只有 44 個人解完呢，這就牽扯到下面要說的。

題目概要

有下一段程式碼:

func FindX(n int) int {
  if n == 0 {
    return 0
  }
  x := 0
  for i:=1; i<=n; i++ {
    x += FindX(i-1) + 3*i
  }
  return x
}

但 x 範圍為 1 <= n <= 10**6(1e6) ，請試著重構。且當 n 愈來試大時，可能會超過 int64 表達，故需要將結果對 10**9 + 7 取模

標記 FUNDAMENTALS OPTIMIZATION

解題邏輯

若沒有取模限制的話這題可以化簡為 O(1)，但很明顯不行。於是先將原題目化簡為 O(n):

func FindX(n int) int {
    mod := int(math.Pow10(9)) + 7
	m := 0
	for i := 0; i <= n; i++ {
		m = (m*2 + 3*i) % mod
	}
	return m
}

好測試過，就算是輸入 1e6 進去也很快就算出來了，於是提交答案