Kiwi lee

程式語言就是我們跟機器溝通,同時也跟人溝通的語言。凡是語言撰寫,都無法跳脫明確的詞句,準確容易理解的段落,及順暢貼近的邏輯。好文章跟好的程式碼,都是可以被評價的。

Photo by Chris Ried on Unsplash

引言

近期重新把前面 1–9 章再看一次,並在 ccClub 內部做了一次小小的分享。在分享的過程中,不斷的思考每個章節的核心觀念要如何串連起來。

後來發現,他的核心概念,

  • 所有文字的明確性,包含命名、程式碼的描述編排到檔案之間的互動
  • 每一個概念的目的,必須區分「抽象」或「實作」。定義好區塊後,就盡量只服務那個目的!

闡述

其實這兩個概念,延伸到有用「文字」的地方,都不外乎是這樣的撰寫邏輯,像是散文、報告文章、廣告等等,都需要滿足所謂的言之有物,敘事清礎,才能好好的將你要表達的內容,給好好的傳遞出去。

雖然我們很難去定義好看的文章是什麼?畢竟在這之中有很多的個人主觀的干擾,但我們透過一些分析,可以以客觀的方式去說文章是好的。

如同上述的朱老師的影片,針對文字的描述,從解讀、評價到喜好,讓我們可以理解文章的好與壞,與所謂的喜好是差距很大的。我們每個人都會自己的喜好,但這不代表因為自己的喜好,而不去承認文章本身的評價好壞。

來到程式碼

同樣的想法,來換到程式碼,我們可以說有些 coding style 不是我們喜歡的,但我們重點是要看這個程式碼,是否有正確的表達自己,讓寫扣的人讀扣的人,都能很簡單的理解程式碼的用途,及該如何修改更新。

如果沒有好的程式碼表現

就像寫文章時,沒有妥善的詞彙去表達,像是

我回來了、我回家了、我到家了

雖然都是表達同個想法,但結合上下文會有不同的聯想。

在更講求邏輯順序的程式碼上,更是影響重大。雖然我們可以將程式碼實際的運行,來知道函式的目的,但如果每個函式都要這樣,甚至函式彼此之間的串連,多個參數的導入都如此,那可真累死人了。

因此用適當明確的命名,及將程式碼每一個區塊都寫得精確,即是 clean coe 的開始。

概念目的性

當我們嘗試用準確的詞描繪後,面對到的即是我們想表達的概念,縱使文章寫得很精確到位,但卻為了服務不同的讀者,從而讓文章過於複雜,讓人需要反覆得閱讀,努力得在這之中,找出自己想要的內容。

那我們會說這是個不好的文章。

在程式碼也是一樣,每個段落只服務一個概念,可能是抽象的介面,又或是實作介面的內容,但就只能有一個你要服務的對象。

開門的函式就專心開門,權限就交給權限。

從服務單一概念的想法上,其實就跟書中說盡量減低函式的參數想法一樣。參數的增加,只代表函式的複雜化,及其要服務的對象種類越來越多。

因此,小結這概念的想法:

  • 讓你的程式區塊以單一概念去服務外部,就是強化其內聚性。
  • 讓你的程式碼以更簡單的方式互相關聯彼此,其實就是減少耦合性。

結語

用正確的文字,去組織順暢的邏輯,並確保每個段落的概念是純粹的。

--

--

紀錄一下,在佈署時,遇到的錯誤訊息 fatal: reference is not a tree 及解法

Issue

想將已有的 argocd application 追蹤的 repo 指到另一個 repo,但在 argocd 同步新的 repo 檔案時,出現這個錯誤,導致無法正常的 refresh&sync。

Root Cause

詢問同事大大,知道這個 git 錯誤訊息,是系統想比較前個 commit,但因為某些原因,無法找到,才會噴這個錯誤。

可參考下面這篇網頁

Reproduce

  1. 想更換到另一個 repo
  2. 複製舊 repo 的佈署檔,到新 repo 的某個新資料夾
  3. 修改 argocd application 從舊的 repo,指到新 repo 的該資料夾下

ArgoCD 需要比較新 repo 的資料夾,跟舊的 commit 之間的 diff,只不過因為舊的 commit 無法找到,因此就會噴出這個錯誤。

Solve

在新的 repo 再推一個 commit,創造新舊 diff,即可解決這個問題

--

--

這篇希望先定義 kubernetes 各元件在網路上的抽象定義,從 overlay network 的角度來看, cluster-node-pod-container 的關聯性及允許

Overlay Network / Underlay Network

Overlay 是建立在另一網路之上的電腦網路,其中的節點可能是通過虛擬或邏輯連結相連,提供可靠、高效的網路設定。

定義

Tracing the path of network traffic in Kubernetes (learnk8s.io)

連結中,講述在 kubernetes 的網路如何實作,好讓我們在使用 kubernetes 不用煩惱彼此間的網路是如何橫跨實體網路。

  • 在 cluster 的每個 pod ,可以在不需要 NAT(Network Address Translation) 直接連接到其他 pod
  • 在 cluster 的每個 pod,都會有自己的 ip,可讓其他 pod 透過這個連接到
  • 在同個 node 的 pod,內部的程式可在不需要 NAT 下,互相連接
  • 在同個 pod 中的 container,彼此間可用 localhost 連接,port 共享

運作的元件

Operating a Kubernetes network (jvns.ca)

  • Your overlay network backend (like flannel/calico/weave net/romana)
  • kube-dns : 幫助在同一個 Kubernetes Cluster 中的所有 Pods ,都能透過 Service 的名稱找到彼此
  • kube-proxy : 監視在 node 上的 service/endpoint,叫 iptables 撰寫規則,完成轉遞流量目的
  • Ingress controllers / load balancers: cluster 對外的連接
  • kubelet : 控制器!

小結

紀錄下目前對於網路的初步認識,未來會繼續從內部的 pod,擴展到跨 node 的 pod — service — pod 的連接,其底層是如何實作出來的。

Reference

[Day 17] Pod 之間是如何找到彼此呢 — DNS Service Discovery — iT 邦幫忙::一起幫忙解決難題,拯救 IT 人的一天 (ithome.com.tw)

--

--