前情提要

最近想再面試，發現大家都很流行刷題，好像沒有刷個 100、200 題，就不能夠面試了。
我剛開始從事軟體工作之初，刷題並不是一個很主流的面試條件，不過也是會準備一些考古題，
關於這樣的面試方式，是不是真的能找到公司要的人才，或許有機會未來，再寫一篇來聊聊。

總之，我很喜歡 TDD 的開發方式，試著在刷題的過程之中，順便練手一下 TDD

二元搜尋樹(Binary Search)

演算法題庫的第一題，就是二元搜尋樹(Binary Search)，
概念上很簡單，就是將數列排列後，由中位數去比較大小，
如果目標比中位數大，那麼就往右側的樹，再作一次搜尋
如果目標比中位數小，那麼就往左側的樹，再作一次搜尋
直到找目標，或是抵達樹葉，而仍未找到目標便回傳 -1

這樣的作法，不考慮極端狀況下，會比遍歷整個樹快一倍

測試案例

目標 5，空陣列，回傳-1

這個案例用來建立方法簽章，
用最簡單的方法實作

1
2
3

public int Search(int[] nums, int target) {
  return -1;
}

目標 5，[5]，回傳 0

這個案例用來實作判斷 target 是否在 nums 之中，
先 hard code 通過測試

1
2
3
4
5

public int Search(int[] nums, int target) {
  if (nums.Length > 0)
    return 0;
  return -1;
}

接著我們要修改 hard code 的部份，首先實作中位數的比較，
同時代出左右 index 的概念

1
2
3
4
5
6
7
8
9
10

if (nums.Length > 0)
{
    int left = 0;
    int right = nums.Length - 1;
    int mid = (right - left) / 2;
    if (nums[mid] == target)
    {
        return mid;
    }
}

重構，利用左右 index 的觀念，改寫進入搜尋的條件式

1
2
3
4
5
6
7
8
9
10

int left = 0;
int right = nums.Length - 1;
if (right - left >= 0)
{
    int mid = (right - left) / 2;
    if (nums[mid] == target)
    {
        returN mid;
    }
}

目標 5，[5,6]，回傳 0

我們的樹開始長出葉子，僅管通過測試，
我們也需要透過這個案例，產生一個 while 迴圈，

1
2
3
4
5
6
7
8
9
10

int left = 0;
int right = nums.Length - 1;
while (right >= left)
{
    int mid = (right - left) / 2;
    if (nums[mid] == target)
    {
        returN mid;
    }
}

目標 5，[5,6,7]，回傳 0

目標 5，[3,4,5]，回傳 2

有了 mid 的概念，我們可以以 mid 的左右 假想為不同的子樹，
用這兩個案例逼出左、右樹邊界重設條件，
注意 mid 同時也是邊界重要條件之一，
為此，我們需要調整 mid 的邏輯，
完整的程式如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

int left = 0;
int right = nums.Length - 1;
while (right >= left)
{
    int mid = (right - left) / 2 + left;
    if (nums[mid] == target)
    {
        returN mid;
    }
    if (nums[mid] < target)
    {
        left = mid + 1;
    }

    if (nums[mid] > target)
    {
        right = mid - 1;
    }
}

小結

二元搜尋樹是屬於簡單的題型，
也是資工學習演算法的初級題目，
轉為 TDD 的過程也不困難，掌握幾個原則，
一、先設計再實作
二、用測試案例趨動實作
三、果斷拋棄無法趨動實作的測試案例(案例設計不當的壞味道)
四、適當的重構，以符合當初的設計

(fin)

前情提要

約耳測試是我早期在評量一間公司的軟體團隊成熟程度的指標，
非常簡單好用，像極了軟體業的艾卜佳評分表,
可以參考我之前的文章

最近要換工作了，再看看約耳測試的評量表，有了一些想法，特別記錄下來

我的看法

比較表

你有使用原始碼控制系統嗎? 你有使用 Git 嗎 ?

這題我覺得比較沒有爭議，分散式版控與集中式版控之爭已經是十年前的討論，
Git 可以說是唯一選擇，雖然曾有一些說法試著說明 Mercurial 比 Git 更好，
但是市場証明了一切。

初學者學習起來資源多、門檻低、工具鏈完整，進階者不能不會 Git。
不論是開發流程、測試、需求管理 Git 的應用應該被包入日常作業之中。
有用 Git 是基本的基本，困難的是如何整合在你整個日常作業之中。
但原本的題目是「你有使用原始碼控制系統嗎?」 所以我想只你有在用 Git 就當作合格吧。

你能用一個步驟建出所有結果嗎? 新人需要多少步驟才能建立好開發環境 ?

這題有點難，我本來想用「你怎麼實作 CI/CD ?」，
但即使到了今天，這也是個大哉問，一鑑還原可以當作一個目標，
在實務上，通常可以作到 3 大步驟就完成開發環境建置我覺得是最理想的。

• 取得源碼(git clone)
• 取得/設定授權(internal auth/password/credential)
• Build & Run

你有沒有每天都重新編譯建立(daily builds)嗎? 你有高品質的自動化整合/迴歸測試嗎?

這題有兩個面向，一個是測試的頻率，一個是測試的品質，
在工具發達的今日，高頻測試不是難事，你可以每天建置一次，也可以每次部署都建置一次。

重點反而在於，你的整合與測試是不是符合品質的，在實務上看到太多為測試而測試的案例。
或是追求特定指標(每日建置次數/測試覆蓋率等…)而無法真正達到為品質把關。

不過回到這題，你有高品質的自動化整合/迴歸測試嗎 ?
有沒有很好量化，高不高品質就難說了，也許問題可以改成
「你有自動化整合/迴歸測試嗎?如果有的話，請舉例說明曾被測試救了一次的經驗(欄截到的錯誤版本)?」
舉不出例子就是種壞味道，很有可能他的自動化整合/迴歸測試是自我滿足或是吹牛用的工具，
而不是真正對產品有用保護。

你有沒有問題追蹤資料庫(bug database)? 你有 Issue Tracking System 嗎?

這題我覺得也是基本題，如果有的話可以追問

• 需求的分級
• 一般需求與緊急需求怎麼處理 ?
• BUG 與 Defect 怎麼處理 ?

如果沒有 Issue Tracking System 的公司一定雷，自已好自為之。

你會先把問題都修好之後才寫新的程式嗎? 你有管理你的技術債嗎?

這題與上一題有所關連，但是上一與之相關的人員比較像是 PM/PO/管理者的角色，
而這題更多是 RD 需要負起的責任。
實務上為了快速滿足需求，欠技術債是難免的，與其不欠債，不如好好管理債務，
那 Issue Tracking System 就會是一個很好用的工具。

而實際台灣的業界，我蠻常看到 RD 是欠債不理的，用一些神乎其技完成了某功能，
然後離職無人能接手(或是難以接手)，再去各大社群或是大會演講，
雖然技術很領先，但這樣的人實在讓人難以尊敬(不過看起來他們是過蠻爽的啦)

你有一份最新的時程表嗎? Scrum: 你知道 Sprint 的目標嗎? Other:你最重要的事是什麼?

這裡特別提到了 Scrum(請參照 Scrum Guide，其它捉文解字的、守破離的、殞石開發的不算 Scrum )
因為在 Scrum 的 Sprint 設計是有目標導向的，
而不是 Scrum 的話，你知道你最重要的事情是什麼嗎 ?
至少要說出前 3 項，與短中長程的目標，人無遠慮必有近憂，
這個問題適用於開發主管與產品主管，可以了解這兩個面向公司的發展與未來性。

你有規格嗎? 你有規格/POC/mockup 嗎 ?

這題其實不用改，即使敏捷宣言說Individuals and interactions over processes and tools，
但是這些文件實務上是能帶來很多好處的，在各行各業都有類似的手冊、文件來幫助溝通，
很多時候你也可以錄影/錄音來加速增加溝通的效率，不要太過極端就好，
如果是 010 來評分的話，我建議至少要有 68 成規格應被置成文件(不論影音文字)

程式人員有沒有安靜的工作環境? 你一天會有多少會議?常常被打斷嗎?

例行性會議有多少 ? 非例行性會議(頻率)有多少 ?
多久會 1-1 ? 這些問題很看管理者的風格，但是又很打擾開發者，
另外如果面試爽約、逾時、讓你乾等等…可以視作一種壞味道，不仿可以切入追問。

你有沒有用市面上最好的工具? Cloud/IDE/所有開發人員的開發體驗是一致的嗎?

現在的工具實在太多，還有各種外掛，所以要讓開發人員的開發體驗一致是相當困難的，
建議在建立開發人員(可以依團隊劃分)的環境文件之中，應該要有一份共用且最新的相關設定的檔。

~~你有沒有測試人員?~~~ 你有 QA 團隊嗎?

測試已經是一門水很深的領域了，如果沒有一個團隊在負責測試，或是沒有自動化測試，
要小心這是個壞味道，或許你可以把問題變成「測試團隊怎麼驗收功能?」

有沒有在面試時要求面試對象寫程式 ?

不得不說我也很不喜歡面試時寫程式，最主要是常常面試的題目難如登月，
進到公司後，卻在作九九乘法表般的開發。
網路上甚至都有「面試造火箭，入職擰螺絲」一說了。
樂觀的說，如果你不懂得造火箭，那你的螺絲很難擰得正確，
悲觀的說，這些資訊主管，正缺乏一種正確評量人的方法，所以只能用這種方法進行篩選，
而且這方法還算行得通。

反之，我反而很想在面試的時候，有機會可以跟面試管或是未來的同事 pair programming。

有沒有做走廊使用性(hallway usability)測試? 你有 UI/UX 團隊嗎?

走廊使用性測試我並不熟，我的理解是盲測使用者怎麼使用你的產品?
目前的業界通常有專門的 UI/UX 團隊在處理，不過要怎麼預測使用者行為仍然是很難的
最後看看這篇經點的笑話

一個測試工程師走進一家酒吧，要了一杯啤酒
一個測試工程師走進一家酒吧，要了一杯咖啡
一個測試工程師走進一家酒吧，要了 999999999 杯啤酒
一個測試工程師走進一家酒吧，要了 0 杯啤酒
一個測試工程師走進一家酒吧，要了-1 杯啤酒，
一個測試工程師走進一家酒吧，要了 0.7 杯啤酒
一個測試工程師走進一家酒吧，要了-10000 杯啤酒
一個測試工程師走進一家酒吧，要了一杯蜥蜴
一個測試工程師走進一家酒吧，要了一份 Qer@24dg!&*(@
一個測試工程師走進一家酒吧，什麽也沒要
一個測試工程師走進一家酒吧，又走出去又從窗戶進來又從後門出去再從下水道鑽進來
一個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓
一個測試工程師走進一家酒吧，要了一杯燙燙燙的錕斤拷
一個測試工程師走進一家酒吧，要了 NaN 杯 Null
一個測試工程師沖進一家酒吧，要了 500 杯啤酒咖啡洗腳水野貓狼牙棒奶茶
一個測試工程師把酒吧拆了
一個測試工程師化妝成老闆走進一家酒吧，要了 500 杯啤酒並且不付錢
一萬個測試工程師在酒吧門外呼嘯而過

酒保從容應對

測試工程師很滿意

測試工程師們滿意地離開了酒吧

一名顧客點了一份炒飯

酒吧陷入火海

murmur 一下這些充滿美學卻不能被叫美工的人，說得自已好像賈伯斯，
大多是我覺得或是我的經驗，很少在依賴數據判斷，或是與工程團隊互動，
去建立回饋機制或 A/B Testing。

參考

• 約耳測試中文

(fin)

前情提要

參考前篇，
我針對了我 Blog 文章的發佈流程作了改善，
當中我提到其中並沒有用到多麼了不起的技術或新知，
而是整合現有的技術，讓流程更加的自動化。

這次我又想到一個自動化的流程，
之前提到的 npm-check-updates 工具，
雖然可以很輕鬆的更新 npm 套件，但是什麼時候執行就是一個問題了，
可以的話，我希望讓 CI/CD 代勞。

實作

立刻來捲起袖子吧，
首先回顧一下手動作業的流程。

前置條件

全域安裝 npm-check-updates

流程

1. 拉取專案 git pull
2. 執行 ncu -u
3. 如果有異動的話 git commit -m "some message here"
4. 推上遠端 repo git push

自動化

看看上面的流程，我們知道其實我們只需要一個安裝好 node、git 與 ncu 的環境，

接著就依照流程執行命令即可，這裡我覺得正可以展現 Github Workflow 與 Actions 的強大之處，
你的問題，就是大眾會遇到的問題，而且大部份的情況都有對應的 Actions，
我們所需要作的，就是組合這些步驟，並且放入自已的邏輯。
直接看 workflow 範例

1
2
3
4
5
6
7
8
9
10
11

steps:
  - name: Checkout
    uses: actions/[email protected]
  - name: ncu-upgrade
    run: |
      npm i -g npm-check-updates
      ncu -u
  - name: Commit & Push changes
    uses: actions-js/[email protected]
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}

觀注在 steps 的部份，
透過 actions/checkout 取得最新的 remote repository

1
2

- name: Checkout
  uses: actions/[email protected]

接下來，執行一些語法，
安裝 npm i -g npm-check-updates
再執行 ncu -u

最後，透過 action-js/push 將異動推回 remote repository

1
2

- name: Commit & Push changes
  uses: action-js/[email protected]

下一個問題是，要怎麼取得 git repo 的權限 ?
登登!! 我們可以使用 GITHUB_TOKEN 就輕易取得權限,
有關 GITHUB_TOKEN 的介紹可以參考下方的連結。

參考

• https://blog.marsen.me/2022/09/26/2022/Hexo_CICD/
• https://blog.marsen.me/2022/09/08/2022/how_to_npm_update_more_smoothly/
• GitHub Actions: GITHUB_TOKEN Explained
• GitHub Action for GitHub Commit & Push
• Checkout V3

(fin)

前情提要

我的 blog 一直以來都是用 markdown 加上 hexo 與 github page 建置的靜態網站。
為此，我也寫了一系列的文章;但是我卻沒想過優化 blog 撰寫的流程。

我目前寫作的的流程是這樣的:

首先我會用任何工具補捉自已的想法，手機、筆記本、便利貼、Notion etc…
然後我會用 hackmd.io 來寫草稿。
草稿完成後，我會在自已電腦的 Marsen.Node.Hexo Repo 上完成文章。
接著我會先執行 git push 上版，再接著手動進行 blog 的建置(hexo g) 與部署(hexo d)。

這次要優化的部份是 **手動進行 blog 的建置(hexo g) 與部署(hexo d)**。
我希望寫完 blog 後推上 main 就是發佈了。

進一步的話，可以考慮用分支作草稿流程管理，但先不過早優化。

實作

首先，來了解我們的架構

如圖，可以被畫分為兩個部份，第一個部份是紅框處，
在取得 Hexo Source 後，執行 hexo g 會產生靜態檔案放在 public 資料夾，
藍框處是第二部份，將 public 資料夾部署到 Github Page 的 repository 當中。

就這麼簡單，整個流程只會用到兩個工具 git 與 hexo，
我們只要透過 docker 準備好安裝這兩個工具的 image 在 CI/CD 上執行即可
我找到了一個 Github Action 的 repository – HEXO-ACTION
依照以下的 SOP 就可以完成 CI/CD 設定

1. 準備 Deploy Keys 與 Secrets
   執行以下指令

   $ ssh-keygen -t rsa -C “username@example.com“

   這時我們會取得一組私鑰與公鑰，
   請在 Github Page repository 的 Settings > Deploy keys 中，加入公鑰(記得要勾選 Allow write access)

   https://github.com/{your_account}/{your_account}.github.io/settings/keys

   然後依照 hexo-action 的說明，你必需在 Hexo Source 的 repository 的 Settings > Secrets > actions 中加入私鑰
   有關 ssh-keygen 與不對稱加密的相關知識這裡就不多說明了,
   簡單的去理解，這組鑰匙是用來對 Github Page Repository 作讀寫，所以公鑰會放在 Github Page Repository 中。
   想嚐試存取 Github Page Repository 的人都會拿到公鑰，但是真得要存取，你得有私鑰才行。
   這個時候，Hexo Source Repository 會將私鑰以 Secrets 的形式存下來，
   在 Actions 執行時，會透過 {secrets.DEPLOY_KEY} 去取得私鑰，小心別弄丟了，不然你要從頭來過。
   DEPLOY_KEY 是 HEXO-ACTION 所規範的 Key Name。

   如果你真的很想修改這個 Key Name，可以把 hexo-action fork 回去自已改

2. 配置 Github Workflow
   這步驟就相當簡單了，可以直接參考 HEXO-ACTION 的配置，或是看看我的 workflow 配置

後續

一些小錯誤要注意一下

第一點，Hexo Source repository 的 package-lock.json 應該要進版控，
這個檔案本來就應該進版控，不知道為什麼之前被設成 ignore 了，
剛好 hexo-action 有用到 npm ci 語法才發現這個錯誤，相關文章請參考

在 Hexo Source 的設定檔 _config.yml 中的 deploy 區段有兩點要注意，
第一，type 一定要是 git，第二，repository 的路徑請設定為 ssh (不要用 https)，
參考以下範例

1
2
3
4

deploy:
  type: git
  repository: [email protected]:marsen/marsen.github.io.git
  branche: master

如此一來，未來我寫好文章，只要 push 上 Hexo Source，就可以打完收工了，
再也不用額外的手動作業囉，這篇文章剛好就是第一篇，馬上來試試看。

心得

相關的技術與知識我都有兩年以上了，
但是一直沒有發現應該將其結合起來，可以省下許多時間，
讓我想到 91 大說的綜效，我應該要讓想像力再開放一些，儘可能的把知識與資訊變成真正的價值。

參考

• Hexo 系列文章
• ssh-keygen
• hexo-action
• npm ci

(fin）

簡介 useEffect

在 RC(React Component) 當中，useEffect 是一個常用 Hook，用來處理一些副作用(side-Effect)。

用 FP(Functional Programming) 的角度來看，RC 只是依照狀態(state)或是參數(prop)來呈現不同的外觀，就像是一個單純的 Pure Function。
FP 一些常見的副作用如下:

• I/O (存取檔案、寫 Log 等)
• 與資料庫互動
• Http 請求
• DOM 操作

而 Http 與 DOM 正好是我們開發 RC 最常接觸到的副作用，
useEffect 就是要來解決這個問題。

如何運作

1. RC 在渲染的時候會通知 React
2. React 通知 Browser 渲染
3. Browser 渲染後，執行 Effect

使用範例

下面是 VSCode 外掛產生的程式片段

1
2
3
4
5
6
7

useEffect(() => {
  first;

  return () => {
    second;
  };
}, [third]);

我們可以看到 useEffect 需要提供兩個參數，一個函數與一個陣列
這裡有三處邏輯，first、second、third,
為了更好說明概念，順序會稍會有點跳躍，請再參考上面程式範例

相依(dependencies)

third 就是指與此副作用相依的參數，如果不特別加上這個參數，
每次重新渲染都會觸發 Effect 的第一個參數的函數，
如果只提供一個空陣列，就只會在第一次渲染的時候觸發，這很適合用在初始化的情況。
觸發時機:

• 不傳值，每次渲染時
• []，只有第一次渲染時
• [dep1,dep2,…]

注意的事項與 useMemo

useEffect 在判斷觸發的 dependencies 參數，
會有 Primitive 與 Non-primitive 參數的差別。

Primitive: 比如 number、boolean 與 string
Non-primitive: 比如 object、array
這兩種參數的差異在於 JavaScript 在實作時，記憶體的使用方式

Primitive 會直接將值記錄在記憶體區塊中，
Non-primitive，則會另外劃一塊記憶體位置存值，再將這塊記憶體位址存到參數的記憶體位址中。
所以當我們比較的是記憶體位址時，即使內部的值都相同也會回傳 false

參考範例

1
2
3
4
5

const [staff, setStaff] = useState({ name: "", toggle: false });
useEffect(() => {
  console.count(`staff updated:${JSON.stringify(staff)}`);
}, [staff]);
//}, [staff.name, staff.toggle]);

每次我們點擊 Change Name 按鈕的時候，都會呼叫改變命名的方法，

1

const handleName = () => setStaff((prev) => ({ ...prev, name: name }));

但是即時我們的 name 沒有改變，仍然觸發 Effect，
這是因為 staff 是一個 Non-Primitive 型別的變數。
一種簡單暴力的方法是將物件展開放入 [] 之中。

這裡我們無法使用展開運算符(Spread Operator)
因為一般的物件沒有 Symbol.iterator 方法

Only iterable objects, like Array, can be spread in array and function parameters.
Many objects are not iterable, including all plain objects that lack a Symbol.iterator method:

物件展開放入 [] 之中的明顯缺點是，當物件變的太大或複雜的時候，
你的 [] 會變得又臭又長。

解法可以使用 useMemo
useMemo 會回傳一個存在記憶體裡的值，
完整範例請參考

1
2
3
4
5
6
7
8

const memo = useMemo(
  () => ({ name: staff.name, toggle: staff.toggle }),
  [staff.name, staff.toggle]
);

useEffect(() => {
  console.count(`staff updated:${JSON.stringify(memo)}`);
}, [memo]);

函數

回到我們的程式片段
first 其實就是處理 Effect 函數，我們可以把 Effect 寫在這裡，
範例中都是寫 console.log 實務上更多會是打 API、fetch etc… 的行為

Clean up functions

useEffect 的第一個參數是一個函數，可以回傳一個 callback function 用來清除 side Effect。

舉例說明:
想像我們有兩個連結用來切換不同的使用者資料，
在切換的過程中會打 api 取得不同使用者(user1 與 user2)的資料,

我們會先點 user1 的連結取 user1 資料(因網速過慢，此時資料還沒回來)，
再點 user2 的連結取取 user2 資料(user2 的資料也還沒回來)，
這時，user1 資料回來了，畫面會渲染 user1 資料(實際上，這時候我想看 user2 的資料)，
再過一會兒，user2 資料回來了，畫面閃爍，渲染 user2 資料。

線上範例看這,使用網速網路會更明顯。

這是表示當我們點擊 user2 的連結時，其實我們已經拋棄了點擊 user1 的結果(對我們來說已經不需要了)，
這時候 Clean up function 就是用來處理這個不再需要的 side-effect。

我們可以簡單設定一個 toggle 來處理這個問題

1
2
3
4
5
6
7
8
9
10
11
12
13

useEffect(() => {
  let fetching = true;
  fetch(`https://jsonplaceholder.typicode.com/users/${id}`)
    .then((res) => res.json())
    .then((data) => {
      if (fetching) {
        setUser(data);
      }
    });
  return () => {
    fetching = false;
  };
}, [id]);

我們也可使用 AbortController,
有關 AbortController 的相關資訊可以參考隨附連結，或是留言給我再作介紹。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

useEffect(() => {
  const controller = new AbortController();
  const signal = controller.signal;
  fetch(`https://jsonplaceholder.typicode.com/users/${id}`,{ signal })
    .then((res) => res.json())
    .then((data) => {
        setUser(data);
    })
    .catch(err=>{
      if(err.name === "AbortError){
        console.log("cancelled!")
      }else{
        //todo:handle error
      }
    });
  return () => {
    controller.abort();
  };
}, [id]);

以上，我們就介紹完了 useEffect 的三個部份(函數、回呼函數與相依數列)與用法。

如果你使用常見的套件 axios 應該怎麼作 clean up，
補充範例如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

useEffect(() => {
  const cancelToken = axios.cancelToken.source();
  axios(`https://jsonplaceholder.typicode.com/users/${id}`,{ cancelToken:cancelToken.token })
    .then((res) =>
        setUser(res.data);
    })
    .catch(err=>{
      if(axios.isCancel(err)){
        console.log("cancelled!")
      }else{
        //todo:handle error
      }
    });
  return () => {
    cancelToken.cancel();
  };
}, [id]);

why render twice with React.StrictMode

請參考官方文章,
StrictMode 可以幫助開發者即早發現諸如下列的問題:

• Identifying components with unsafe life-cycles
• Warning about legacy string ref API usage
• Warning about deprecated findDOMNode usage
• Detecting unexpected side effects
• Detecting legacy context API
• Ensuring reusable state

小結

• React.StrictMode 可以幫助你檢查組件的生命周期(不僅僅 useEffect)
• React.StrictMode 很有用不應該考慮移除它
• useEffect 包含三個部份
  • 第一個參數(function)，處理 side-Effect 的商業邏輯
  • 第一個參數的回傳值(clean-up function)，處理 side-Effect 中斷時的邏輯(拋錯、釋放資源 etc…)
  • 第二個參數表示相依的參數陣列
    • 不傳值將會導致每次渲染都觸發副作用
    • 傳空陣列將會只執行一次
    • 相依的參數需注意 Primitive 與 Non-primitive
    • useMemo 可以協助處理 Primitive 與 Non-primitive

參考

• https://reactjs.org/docs/hooks-reference.html#useeffect
• https://www.youtube.com/watch?v=QQYeipc_cik
• https://morioh.com/p/a8366f4ec07a?f=603c719d1528b00f7934320a&fbclid=IwAR07igsz8cQ49y1AQYElDBxPk23vqv-9WDYTlbrCf-yBcXhapz9WzAa9lhQ
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/rest_parameters
• https://www.zhoulujun.cn/html/webfront/SGML/html5/2022_0530_8824.html
  (fin)

簡介

本文簡單介紹一下 TypeScript Omit 的用法與範例，
更多資料可以參考官方文件

說明

Omit 字義為忽略、省略，在 TypeScript 中是一種 Utility Type,
使用方法如下:

1

type NewType = Omit<OldType, "name" | "age">;

第一個參數是傳入的 Type, 第二個參數是要忽略的欄位，
並會回傳一個新的 Type, 這是 TypeScript Utility Types 的標準用法。

具體一個例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

interface LocationX {
  address: string;
  longitude: number;
  latitude: number;
}

interface SpecificLocation extends Omit<LocationX, "longitude" | "latitude"> {
  coordinate: {
    longitude: number;
    latitude: number;
  };
}

type AnotherLocation = Omit<SpecificLocation, "coordinate"> & {
  x: number;
  y: number;
};

const example1: SpecificLocation = {
  address: "example first on some where",
  coordinate: {
    latitude: 100,
    longitude: 100,
  },
};

const example2: AnotherLocation = {
  address: "example 2nd on some where",
};

console.log(example1);
console.log(example2);

說明:

1. interface 可以用 extends 加上新欄位，借此實現 override 欄位的功能
2. type 使用 & 作擴展，一樣的方式先省略(Omit)再擴展欄位
3. 相反的 Utility Type 有 Pick

完整範例

這些 Utility Types 蠻有趣的，有時間應該將它們補完。

20220913 補充

進一步探討 Omit

1. Omit 適用於 type 與 interface

2. 與 Omit 相反的就是 Pick

3. Omit 與 Exclude 的差別

   • Omit 移除指定 Type 的欄位
   • Exclude 移除 union literal Type 當中的成員
   • Exclude 可以適用於 enum

舉例說明:

下面兩個例子分別使用了 union literal 與 enum,
在這種情況下如需要忽略部份的成員, 請使用 Exclude,
你要用 Omit 也不會報錯, 但是無法達到編譯時期警告的效果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

type TrafficLight = "red" | "yellow" | "green";

type RedLight = Exclude<TrafficLight, "yellow" | "green">;
type GreenLight = Omit<TrafficLight, "red">;

const sighs: {
  Danger: RedLight;
  Warning: TrafficLight;
  Safe: GreenLight;
} = {
  Danger: "red", // if you use other words would get error
  Warning: "yellow",
  Safe: "there is no constraint any string",
};

console.log(sighs);

範例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

enum TrafficLight {
  red,
  yellow,
  green,
}

type RedLight = Exclude<TrafficLight, TrafficLight.yellow | TrafficLight.green>;
type GreenLight = Omit<TrafficLight, TrafficLight.red>;

const sighs: {
  Danger: RedLight;
  Warning: TrafficLight;
  Safe: GreenLight;
} = {
  Danger: TrafficLight.red, // if you use yellow or green would get error
  Warning: TrafficLight.yellow,
  Safe: TrafficLight.red,
};

console.log(sighs);

範例

參考

• https://bobbyhadz.com/blog/typescript-override-interface-property
• https://timmousk.com/blog/typescript-omit/
• https://www.typescriptlang.org/docs/handbook/utility-types.html#omittype-keys
• https://ithelp.ithome.com.tw/articles/10269471

(fin)

前情提要

純屬個人偏見，我討厭 Nodejs。
有幾個原因，
首先，使用 javascript 作為開發語言，用弱型別直譯式的語言來開發大型專案是痛苦的。
不論在 TDD、重構或是除錯上…我始終作不到極速開發那樣流暢的感覺，
即使改用 TypeScript，儘管看到 TypeScript 的可能性，這樣的感覺還是揮之不去。
很希望有機會可以跟這樣的高手交流。

再者，node_modules 是出了名的零碎肥大，網路上甚至為它作了迷因，如下圖

第三點，專案的 npm 更新是相當麻煩的，也是這篇文章我們要面對的問題，
通常我們的專案，隨著時間開發，會與越來越多 npm 套件，先不論它會不會變成黑洞影響時空，
我最常遇到的問題是，我不知道有哪些套件需要被更新 !??
這些更新有的無關痛養，有的是提昇效能，有的是安全性更新…
不論如何，我的目標是更新更加的流暢，而不要被一些奇怪的問題阻檔。

但實務上，更新之路是異常充滿危機與苦難…

實際案例

在這裡我用一個我的學習用專案來進行演練 Marsen.React.Practice，
這個專案是我用來練習 React 相關的開發，相比任何商務專案，相信會小得多。
但是它相依的套件依然多得驚人，有的與字型相關，有的與 TypeScript 型別相關，
有多語系、有 firebase、有 RTK(React-Tool-Kit)、有 Router、有 Form etc…
隨隨便便也有近 30 幾個相依套件需要管理、更新。

比較好的或是有名的套件，或許會官宣一些更新的原因與細節，
但是實際上，更多套件的更新你是不會知道的。

你可以這樣作

1

> npm update

然後 BOOM !! 就爆炸了

你可以看 log、可以解讀這些錯誤訊息、可以梳理其背後的原因，然後用你寶貴的生命去修復它，
過了幾周或是幾天，新版本的更新又釋出… 那樣的苦痛又要再經歷一次又一次…
或許你會想那就不要更新好了，直到某一天一個致命的漏洞被發佈或是資安審查時強制要求你更新，
或是因為沒有更新，而用不了新的酷功能，這真是兩難，所有的語言都有類似的問題，但 Nodejs 是我覺得最難處理、最令人髮指的一個。

原來有方法

原來有不痛的方法，參考如下
首先執行 npm outdated

如上圖，我們可以發現在套件後面會有 Current/Wanted/Latest 三種版號
分別顯示:目前專案的套件版本/semver 建議的最新版本/Registry 中標注為 latest 的版本
如圖所示，有時候你 Current 版本會比 Latest 版本還新，不用太過揪結與驚訝，
更多可以參考官方文件的說明

接下來我們試著來解決這些套件相依，
我們全域安裝 ncu(npm-check-updates) 這個工具

1

> npm install -g npm-check-updates

執行更新

1

> ncu -u

魔術般完成了更新，沒有任何痛點。
再次執行 npm outdated 將不會看到任何顯示，表示你目前專案的相依套件都在最新的穩定版本
定期執行或是透過 CI/CD 周期性協助你更新並 commit，是不是就會省下了許多時間呢 ?

20220928 後記

• 透過 CI/CD 自動執行的實作記錄在此

參考

• How to Update NPM Dependencies
• npm-outdated
• 91 談極速開發
• Node.js 終結者？青出於藍的 Deno(二)

(fin)

前情提要

學習 Golang 一陣子了，最近開始使用在正式的產品上，
老實說我還不覺得有用到它的特色。

在學習程式語言上的一個現實是，我在台灣面臨的商業規模大多瓶頸並不在語言本身，
開發者的寫法(甚至稱不上演算法)、軟硬架構基本上可以解決大部份的問題。

我的背景是 C#、JavaScript(TypeScript) 為主要開發項目，
除此之外，也有寫過 C、C++、Java、Php、VB.NET、Ruby 與 Python

Go 的優勢常見如下：

1. 讓人容易了解的語意：作為漢語母語者我感受不強烈，我的英文不夠好可以感受到這點(同樣我對 Python 的感受也不深)
2. 容易上手的多緒：這個有感，相比 C# 的確易懂好寫
3. 靜態語言: 原本寫 Python 的開發人員可能比較有感，對我來說這是基本(C# 開發者角度)
4. 高效，快:目前的專案複雜性還未可以感到其差異，或許需要壓測用實際數據比較。
   經驗上是，錯誤的架構或寫法往往才是瓶頸之所在。
5. 編譯快:在 C# 的不好體驗，巨大單體專案，不包測試編譯就要 2~5 分鐘，不曉得 Go 在這樣情況的表現如何? 不過目前主流開發方式為雲原生，微服務，或許有生之年不會再看巨型單體專案了
6. 原生測試:這點我覺得真是棒，我的學習之路就是由 Learn Go with tests 開始的
7. IOP:介面導向程式設計，目前還無法體會其哲學，不過因為其語言的特性會促使人思考，這點我還在慢慢嚐試

一個新的語言我會從測試開始學，
這表示你通常會需要這些工具:測試框架、相依注入、Mocking、語意化 Assert，
本文會專注在使用相依注入的套件 WIRE

WIRE

一些 Q&A

為什麼選用 WIRE ?

google 官方推薦 Wire

還有哪些選擇 ?

• [dig] Uber DI Framework
• [inject] Facebook DI Framework
• [di]sarulabs DI Container，同事在用的 DI

有什麼不同

官方推薦，本質上更像代碼生成器(Code Generator)

Clear is better than clever ，Reflection is never clear.
— Rob Pike

示範

參考本篇文章

高耦合版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

package main

import (
  "bytes"
  "fmt"
)

type Logger struct{}

func (logger *Logger) Log(message string) {
  fmt.Println(message)
}

type HttpClient struct {
  logger *Logger
}

func (client *HttpClient) Get(url string) string {
  client.logger.Log("Getting " + url)

  // make an HTTP request
  return "my response from " + url
}

func NewHttpClient() *HttpClient {
  logger := &Logger{}
  return &HttpClient{logger}
}

type ConcatService struct {
  logger *Logger
  client *HttpClient
}

func (service *ConcatService) GetAll(urls ...string) string {
  service.logger.Log("Running GetAll")

  var result bytes.Buffer

  for _, url := range urls {
    result.WriteString(service.client.Get(url))
  }

  return result.String()
}

func NewConcatService() *ConcatService {
  logger := &Logger{}
  client := NewHttpClient()

  return &ConcatService{logger, client}
}

func main() {
  service := NewConcatService()

  result := service.GetAll(
    "http://example.com",
    "https://drewolson.org",
  )

  fmt.Println(result)
}

在上面的程式中，可以明顯看到 ConcatService 相依於 HttpClient 與 Logger，
而 HttpClient 本身又與 Logger 耦合。
這是一種高耦合，在這個例子裡 Logger 還會產生兩份實體，但實際上我們只需要一份。

Golang 實際上不像 C# 有建構子(Constructor)的設計，不過常見的實踐會用大寫 New 開頭的方法作為一種類似建構子的應用，
比如說上面例子的 NewConcatService 與 NewHttpClient。
我們可以透過這個方法來注入我們相依的服務。

相依注入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

package main

import (
  "bytes"
  "fmt"
)

type Logger struct{}

func (logger *Logger) Log(message string) {
  fmt.Println(message)
}

type HttpClient struct {
  logger *Logger
}

func (client *HttpClient) Get(url string) string {
  client.logger.Log("Getting " + url)

  // make an HTTP request
  return "my response from " + url
}

func NewHttpClient(logger *Logger) *HttpClient {
  return &HttpClient{logger}
}

type ConcatService struct {
  logger *Logger
  client *HttpClient
}

func (service *ConcatService) GetAll(urls ...string) string {
  service.logger.Log("Running GetAll")

  var result bytes.Buffer

  for _, url := range urls {
    result.WriteString(service.client.Get(url))
  }

  return result.String()
}

func NewConcatService(logger *Logger, client *HttpClient) *ConcatService {
  return &ConcatService{logger, client}
}

func main() {
  logger := &Logger{}
  client := NewHttpClient(logger)
  service := NewConcatService(logger, client)

  result := service.GetAll(
    "http://example.com",
    "https://drewolson.org",
  )

  fmt.Println(result)
}

我們把焦點放在 main 函數中，實作實體與注入會在這裡發生，當你的程式變得複雜時，這裡也變得更複雜。
一個簡單的思路是我們可以把重構這些邏輯，
到另一個檔案 container.go 的 CreateConcatService 方法中。

1
2
3
4
5
6
7
8

// container.go
package main

func CreateConcatService() *ConcatService {
  logger := &Logger{}
  client := NewHttpClient(logger)
  return NewConcatService(logger, client)
}

1
2
3
4
5
6
7
8
9
10

func main() {
  service := CreateConcatService()

  result := service.GetAll(
    "http://example.com",
    "https://drewolson.org",
  )

  fmt.Println(result)
}

接下來我們看看怎麼透過 wire 實作

使用 Wire

安裝 wire

1

go get github.com/google/wire/cmd/wire

接下來改寫 container.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//go:build wireinject

package main

import "github.com/google/wire"

func CreateConcatService() *ConcatService {
  panic(wire.Build(
    wire.Struct(new(Logger), "*"),
    NewHttpClient,
    NewConcatService,
  ))
}

在專案中執行

1

wire

wire 將會產生 wire_gen.go 檔，裡面幫你實作 CreateConcatService 函數

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//wire_gen.go
// Code generated by Wire. DO NOT EDIT.

//go:generate go run github.com/google/wire/cmd/wire
//go:build !wireinject
// +build !wireinject

package main

// Injectors from container.go:

func CreateConcatService() *ConcatService {
  logger := &Logger{}
  httpClient := NewHttpClient(logger)
  concatService := NewConcatService(logger, httpClient)
  return concatService
}

簡單回顧一下：

1. 我們需要針對特定的 Service 寫出一個方法的殼

   1 2 3

   func CreateConcatService() *ConcatService { ////skip }

2. 在方法中透過 wire.Build 加入相依的類別，實際上我們不需要 return 實體，所以用 panic 包起來

   1 2 3 4 5 6 7

   func CreateConcatService() *ConcatService { panic(wire.Build( wire.Struct(new(Logger), "*"), NewHttpClient, NewConcatService, )) }

3. 執行 wire 建立檔案

4. 實務上需要這個 Service 時，直接呼叫 Create 方法

   1	service := CreateConcatService()

GoLand 設定

如果你跟我一樣使用 GoLand 作為主要編輯器，
應該會收到 customer tags 的警告

解決方法：
GoLand > Preferences > Build Tags & Vendoring > Editor Constraints > Custom Tags
設定為 wireinject 即可

參考

• go 语言 web 框架比较：gin vs iris vs echo
• The Pros And Cons Of Programming In Go
• Learn Go with tests
• Wire Tutorial
• [Golang] Struct
• Wire:Best Practices
• Defer, Panic, and Recover
• [wire] Google 官方推薦 DI Framework
• Go Dependency Injection with Wire
• Golang 簡潔架構實戰
• 理解一下依赖注入，以及如何用 wire
• Golang 依赖注入框架 wire 使用详解
• Go 依赖注入(DI)工具-wire 使用
• 一文讀懂 wire

(fin)

前情提要

最近我設計了一個 Dialog Button ，過程十分有趣，稍微記錄一下

需求

首先 Dialog Button 的設計上是一個按鈕，被點擊後會開啟一個 Dialog，
它可以是表單、一個頁面、另一個組件或是一群組件的集合。
簡單的說 Dialog 可以是任何的 Component。

用圖說明的話，如下

藍色表示父層組件，我們會把 Dialog Button 放在這裡
綠色就是 Dialog Button 本身，它會有兩種狀態，Dialog 的隱藏或顯示
紅色則是任意被放入 Dialog Button 的 Component。
也就是說我們會用 attribute 傳遞 Component 給 Dialog Button

注意黃線的部份，我們會幾種互動的行為

1. Component 自身的行為，比如說計數器 Component 的計數功能
2. Component 與 Dialog Button 的互動，比如說關閉 Dialog Button
3. Component 與 Dialog Button 的 Parents Component 互動，比如說重新 Fetch 一次資料

具體的 Use Case 如下，
我在一個表格(Parents Component)中找到一筆資料，
點下編輯(Dialog Button)時會跳出一個編輯器(Component)，
編輯器在我錯誤輸入時會提示¹ 警告訊息，
在修改完畢儲存成功時，會關閉編輯器²並且同時刷新表格資料³
參考下圖

實作

首先先作一個陽春的計數器，這個是未來要放入我們 Dialog 之中的 Component,
這裡對有 React 經驗的人應該不難理解，我們透過 useState 的方法來與計數器互動

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

export default function Counter() {
  const handleClick = () => {
    setCount(count + 1);
  };
  const [count, setCount] = useState(0);
  return (
    <>
      Count :{count}
      <Stack spacing={2} direction="row">
        <Button onClick={handleClick} variant="contained">
          Add
        </Button>
      </Stack>
    </>
  );
}

接下來我們來實作 Dialog Button，大部份的實作細節我們先跳過
我們來看看如何使用傳入的 Component 並將其與 Dialog 內部的函數銜接起來

1
2
3

<DialogContent>
  {cloneElement(props.content, { closeDialog: closeDialog })}
</DialogContent>

這個神奇方法就是 cloneElement，
從官方文件可知，我們可以透過 config 參數提供 prop、key 與 ref 給 clone 出來的元素，

1

React.cloneElement(element, [config], [...children]);

所以我們將 closeDialog 方法作為一個 props 傳遞給 dialog 內開啟的子組件，比如說 : Counter

完整程式如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

export function DialogButton(props: DialogButtonProps) {
  const [open, setOpen] = useState(false);
  const openDialog = () => {
    setOpen(true);
  };

  const closeDialog = () => {
    setOpen(false);
  };

  return (
    <>
      <Button {...props} onClick={openDialog}>
        {props.children}
      </Button>
      <Dialog
        open={open}
        onClose={closeDialog}
        maxWidth={props.max_width}
        fullWidth
      >
        <DialogTitle>
          {props.title}
          <IconButton
            aria-label="close"
            onClick={closeDialog}
            sx={{
              position: "absolute",
              right: 6,
              top: 6,
            }}
          >
            <CloseIcon />
          </IconButton>
        </DialogTitle>
        <DialogContent>
          {cloneElement(props.content, { closeDialog: closeDialog })}
        </DialogContent>
      </Dialog>
    </>
  );
}

最後我們父層元素，也可以將自身的方法傳遞給 content Component
以達到 Component 與父層元素互動的功能，不需要再經過 Dialog Button 了

參考

• 完整範例
• cloneElement

(fin)

Docker 相關

在建立映像檔的時候

--build-arg 可以提供參數給 Dockerfile

e.g

1
2
3

docker build \
--build-arg PackageServerUrl="{Url}" \
-t deposit -f ./Dockerfile .

在 container 裡 一些 Linux 常用指令

有時候使用太輕量的 image 會缺少一些工具，
我們可以直接換成有工具的 image。
如果真的需要即時的在 container 裡面操作，
可以參考以下語法
更新 apt-get

apt-get update

透過 apt-get 安裝 curl (其它套件也適用)

apt install curl

印出環境變數
方法一、 後面可以加上指定的變數名

printenv {environment value}

方法二、 效果跟 printenv 一樣

env | grep {environment value}

GKE(k8s)相關指令

準備好 manifests.yml,

GCP 授權

gcloud container clusters get-credentials {kubernetes cluster name} –region {region} –project {project name}

e.g

• gcloud container clusters get-credentials gke-cluster-qa –region asia-east1 –project my-first-project

取得專案列表

kubectl config get-contexts

切換專案(prod/qa)

kubectl config use-context {namespace}

e.g

kubectl config use-context {prod_namespace}
kubectl config use-context {qa_namespace}

套用 manifests(記得切換環境)

kubectl apply (-f FILENAME | -k DIRECTORY)

e.g

kubectl apply -f ./manifests.yml
kubectl apply -f ./k8s/manifests.yml –namespace=prod

查詢 configMap

• kubectl -n=qa get configmap {config_name} -o yaml

查詢 secret

• kubectl -n prod get secret {secret_name} -o json
• kubectl -n qa get secret {secret_name} -o json

pods port 轉入開發者環境

kubectl -n={namespace} port-forward {service} 80:80

e.g

kubectl -n=qa port-forward service/deposit 80:80

取得資訊

• kubectl -n=qa get po
• kubectl -n=qa get deploy
• kubectl -n=qa get svc

進入 pods terminal 環境

kubectl -n=qa exec -it {pods_name} – /bin/bash

e.g

kubectl -n=qa exec –stdin –tty my-service-5b777f56b8-q7lf7 – /bin/sh

重啟服務

kubectl rollout restart {service_name} -n qa

e.g

kubectl rollout restart my-service-n qa

其它 CI 中用到的指令

• envsubst
  • https://medium.com/@SiegeSailor/%E4%BD%BF%E7%94%A8-envsubst-%E6%9B%BF%E6%8F%9B%E7%92%B0%E5%A2%83%E8%AE%8A%E6%95%B8-8c2826996fd5
• cut
• export

綜合應用

設定環境變數，並且置換 yml 檔中的參數，最後 apply 到線上環境

e.g

export K8S_NAMESPACE=qa && envsubst < k8s/manifests.yml | kubectl -n=$K8S_NAMESPACE apply -f -

export K8S_NAMESPACE=qa && envsubst < k8s/configmap.qa.yml | kubectl -n=$K8S_NAMESPACE apply -f -

manifests.yml 的範例

Deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

apiVersion: apps/v1
kind: Deployment
metadata:
  name: $SERVICE_NAME
  namespace: $K8S_NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: $SERVICE_NAME
  template:
    metadata:
      labels:
        app: $SERVICE_NAME
    spec:
      containers:
        - name: $SERVICE_NAME
          image: "asia-east1-docker.pkg.dev/$PROJECT_NAME/docker/$SERVICE_NAME:latest"
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: my-service-config
            - secretRef:
                name: my-service-secret

Service

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: Service
metadata:
  name: $SERVICE_NAME
  namespace: $K8S_NAMESPACE
spec:
  type: ClusterIP
  selector:
    app: $SERVICE_NAME
  ports:
    - port: 8080
      targetPort: 8080

ConfigMap

1
2
3
4
5
6
7
8
9

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-service-config
  namespace: $K8S_NAMESPACE
data:
  THIRD_PARTY_URL: "https://third_party_url/"
  THIRD_PARTY_TOKEN: TBD
  THIRD_PARTY_ID: TBD

Secret

!!要記得作 base64 Encode

1
2
3
4
5
6

apiVersion: v1
kind: Secret
metadata:
  name: my-service-secret
  namespace: $K8S_NAMESPACE
data: secret.Key:<<must encoded base64>>

manifest 實作上的 tip

更多參考官方文件與範例，設定太多了，不懂就去查
可以用 ---- 串連多份文件，但我實務上不會串 Secret
e.g

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

apiVersion: apps/v1
kind: Deployment
metadata:
  name: $SERVICE_NAME
  namespace: $K8S_NAMESPACE
spec:
  replicas: 1
  selector:
    matchLabels:
      app: $SERVICE_NAME
  template:
  ## 中間省略
----
apiVersion: v1
kind: Service
metadata:
  name: $SERVICE_NAME
  ## 中間省略
----
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-service-config
  ## 以下省略

參考

• 使用-envsubst-替換環境變數
• kubernetes

(fin)