薛惟仁 筆記本

分享後端工程師協助前端 Code Review 三年的心路歷程，探討其原因、對前後端與團隊的好處、挑戰，以及最終放手的決定。適合對 Code Review 與前後端協作感興趣的開發者閱讀。

日本這個充滿歷史文化的國度，一直是心中嚮往已久的旅行目的地。這次的六天五夜行程，我們選擇了京都、大阪和奈良，期望能在短暫的時間內深入體驗傳統的神社文化並且享受地道的日本美食。

程式碼審查 (Code Review) 旨在通過其他開發人員 (被稱為 Reviewer) 對程式碼進行檢查和審核 (Review)，以確保程式碼的質量和一致性。這個過程通常在程式碼合併到主分支之前進行，目的是發現潛在的錯誤、改善程式碼的可讀性，同時確保程式碼符合團隊的編碼標準和最佳實踐。

這裡記錄形容詞與形容動詞的各種形態變化規則與重音規則。

除了理解「[日語] 動詞活用規則與重音規則」一文中詳細列出的動詞變化規則與重音規則外，還需要搭配大量的練習才能將這些規則內化到心裡，使動詞變化成為反射動作，避免在使用到的時候才從頭開始推導。這裡記錄常見的動詞與變化形式並且標上重音，目的是讓自己與有需要的讀者可以隨時透過「唸」來強化動詞活用這門課題。因此，這篇文章推薦的服用方式為將動詞變化「唸到變成反射動作而記起來」而非「背到記起來」。

這裡記錄了 N5 與 N4 會遇到的動詞變化規則與重音規則。

在本文中，我們將使用 Golang WebAssembly 創建一個簡單的 TODO 應用，完全使用 Golang 來操作 DOM，整個代碼的複雜度不高，但足以用來學習 Golang 撰寫 WebAssembly 的基本技巧。

貝祖曾說：對任意兩整數 $a,b \in \mathbb{Z}$ 一定可以找到 $x,y \in \mathbb{Z}$ 滿足 $gcd(a,b)=ax+by$。此即為貝祖等式 (Bézout's identity)。雖然網路上許多相關證明，但個人認為這些證明都有一個通病，也就是過程中省略許多步驟與解釋，讓人看得不明所以，無法輕易得知該步驟是根據什麼道理得來的。這篇文章主要為這些證明補上個人的想法，使證明過程容易理解。

HTTP 搭配 TCP/IP 來運作是常見的案例，但實際上 HTTP 本身只假定下層協定會提供可靠的傳輸，所以只要任何滿足可靠傳輸的協定都能成為 HTTP 的下層。在行程間通訊 (IPC, Inter-Process Communication) 應用情境中，較常使用 Unix Domain Socket (UDS) 來取代 TCP/IP，例如：docker 指令透過 Docker Server 建立的 UDS 發送 HTTP Request 給 Docker Server。因此，對開發者來說，知道如何對使用 UDS 作為下層傳輸協定的 HTTP Client 進行測試是重要的。

HTTP 是廣受使用的傳輸協定之一，其為客戶端 (Client) 與伺服器 (Server) 通訊訂定一個 Request/Response 標準，可以輕易地使用瀏覽器、爬蟲工具等遵守 HTTP 協定的 Client 來對 Server 發出請求以取得資料。在程式開發中，透過 HTTP 呼叫第三方 Server 的 API 是常見的一個行為，例如：LINE Notify、Firebase 等服務，背後皆是使用 HTTP 與其 Server 交換資料。為了確保邏輯正確性且提高代碼品質，正確撰寫 HTTP Client 的測試就變得格外重要。