Golang

在使用 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 的迭代。 ...

介紹 改變數值的三個步驟 取出 修改 保存 但這三者間的時間差在不同 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: ...

文章中的程式碼放在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 用來驗證 ...

前言 放在最前面 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。 ...

起因 在網站註冊流程中，若是用信箱驗證，網站會寄送一封驗證信到指定的電子信箱。信中可能含有 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。 ...

由於先前將 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 連線。 ...

免責聲明，此篇為個人學習筆記，非正式教學文，僅供參考感謝指教，有任何內容錯誤歡迎發 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 的優勢，可以點擊下方圖片看更多詳細。 ...

免責聲明，此篇為個人學習筆記，非正式教學文，僅供參考感謝指教，有任何內容錯誤歡迎發 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: ...

很高興有個機會製作面試前的測試作業，也就趁這個機會做個筆記以及學習紀錄。 前置作業 先點列一下項目需求： 基本需求 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 介接。 ...

想不到一眨眼半個月過去了，自從面試趨勢之後整個人彷彿被電到失去信心，在離職與等待面試消息期間，也只好振作補足不足的地方繼續向前。 而 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 進去也很快就算出來了，於是提交答案 ...