摘要

當初玩 Mac 從一開始很痛苦的 bash ，到了換了好像超好用的 fish (friendly interactive shell) 可以參考一下 [TIL] Note: about change your shell from bash to fish ．

當然，之後也有想要換到 zsh 參考這篇 [TIL] Change fish shell theme with nerd font 但是又遲遲不敢換．

不過今天總算發生了重要的問題． 公司一堆 Operation 相關的 Makefile 竟然完全死在 fish 上面． GG

只好認真來換… zsh

基本的 zsh 配備

當然要先看看這篇我認為超適合當 zsh (還有 oh-my-zsh) 的推坑文超簡單！十分鐘打造漂亮又好用的 zsh command line 環境 基本流程就依照這篇就好，補充一些:

• iterm2 換字型到 Sauce Code Pro Nerd Font Complete 如果你字體大小是在 12 很容易卡死(hang) ． 就得要清除所有 iterm2 的設定 · 建議要先切換字體大小到 14 再換字型．

defaults delete com.googlecode.iterm2

• iTerm2 本身對於各個 Shell 都有 integration ，可以讓你使用起來更方便．

curl -L https://iterm2.com/shell_integration/zsh \
  -o ~/.iterm2_shell_integration.zsh

source ~/.iterm2_shell_integration.zsh

• POWERLEVEL9K 雖然很棒，但是不是太多功能需要．這裡列出我使用的功能

export TERM="xterm-256color"


POWERLEVEL9K_MODE='nerdfont-complete'
ZSH_THEME="powerlevel9k/powerlevel9k"
# command line 左邊想顯示的內容
POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir vcs) 
# command line 右邊想顯示的內容
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(kubecontext) 

POWERLEVEL9K_SHORTEN_DIR_LENGTH=1
POWERLEVEL9K_SHORTEN_DELIMITER=""
POWERLEVEL9K_SHORTEN_STRATEGY="truncate_from_right"

進階設定

這裡介紹幾個好用 plugin ，可以幫助大家快速（無痛?）切換到 zsh

plugins=(
#git 可以有一些快捷鍵 ggl ...
  git
# 自動補全   
  zsh-completions
  gitfast
# 解壓縮用
  extract
# z: 可以快速並且支援模糊切換目錄 ex: z docume <tab>
  z
# 讓你喚回 fish 漂亮的顏色
  zsh-syntax-highlighting
# 就像 fish 一樣，打到一半自動建議你
  zsh-autosuggestions
)

相關習慣變更

• Quick Search History:
  • 先按下 “Ctrl + R” 再打你需要的…
• Auto-Completed:
  • 先打出你需要的 ex: gcloud 然後再按下 (up) 鍵
• 相關路徑與設定
  • GOBIN, GOPATH
  • Heroku path
  • Gcloud path (reinstall again)
  • cocoa pods PATH
  • LIBRARY_PATH

其他就還好，大概就是之前被 fish 強制修改的習慣．

• ; —> &&
• $(VAR) —> (VAR)
• env ABC=edc —> ABC=edc

VSCode integrated terminal 也要改

其實剛換過去，還沒有感覺到有太多的不同．不過 VSCode 一打開就發現有個嚴重的問題， ` vscode 還在使用 fish shell`

趕緊打開 user.setting (cmd+,) ，然後加入以下的修改

    "terminal.integrated.shell.osx": "zsh",
    "terminal.integrated.cursorBlinking": true,
    "terminal.integrated.fontSize": 12,

Reference

• 超簡單！十分鐘打造漂亮又好用的 zsh command line 環境
• [TIL] Note: about change your shell from bash to fish
• [TIL] Change fish shell theme with nerd font
• zsh oh-my-zsh 插件推荐
• oh-my-zsh: plugin git

摘要

花了一點時間玩了一下 makefile ，有一些字串對應方式與使用方式在不使用 sed 的前提下其實也很方便． 順手整理一下一些常用的案例．

並且也列出一些使用 makefile 在編譯 Dockerfile 的時候經常會用到的範例．

基礎常見語法:

wildcard

透過 wildcard 可以擴展找出所有匹配的項目．

找出所有具有 Dockerfile 的目錄(並且依序排列)

DOCKERFILE_PATHS := $(sort $(wildcard */Dockerfile))

patsubst 替換字串

常用再換掉路徑，去除路徑．以下紀錄幾個常用的．

取得 Parent Path (ex: a/b/c/d –> a/b/c)

PARENT_PATHS := $(patsubst %/,%,$(dir $(CURRENT_PATHS)))

nodir 去除所有目錄

這個可以幫你去除所有目錄，剩下檔名． ex: a/b/c/d –> d

取得上一層目錄列表

PARENT_PATH_LIST := $(notdir $(dir $(CURRENT_PATHS)))

這裡也要解釋一下， dir 會取得目錄而已．跟 nodir 剛好相反．

另外， basename 跟 dir 也不同．

$(basename a/b/c/d.a) —> d

進階用法 *, % 與$* 跟 $<

這邊講解起來會有點難懂，就用一個案例來講解．

• $* 會找出所有結果
• % 會將前方變數帶給之後用
• $< 列出前面的結果

以下用個例子

範例(1) : 找出 Dockerfile 並且編譯

build-image-%: %/Dockerfile $(shell find $* -type f)
	time docker build  \
		--tag docker.io/$(YOUR_PROJECT)/%:master \
		--file $< \
		$(dir $<)

這個會去編譯某個你輸入底下的 Dockerfile ．

舉例而言: 你有個目錄 tensorflow/Dockerfile 你就要輸入 make build-image-tensorflow ，他就會自動找出這個 Dockerfile 並且編譯名稱為 $(YOUR_PROJECT)/tensorflow:master 以下透過這個案例解釋每個用法:

• % 會將前面輸入的，帶到後面．在這裡也就是 tensorflow 帶到第二個與第三個出現%的地方
• $< 會列出 shell find $* -type f 結果，也就是列出所有檔案，並且符合 %/Dockerfile 也就是如果你有其他檔案舉例為 tensorflow/README.md 也不會列出．

似乎這樣好像很麻煩? 其實透過前面介紹的基礎常見語法，可以更方便編譯．

範例(2) : 找出所有符合目錄直接帶到以上編譯

#find all docker files
DOCKERFILES := $(sort $(wildcard */Dockerfile))

#extract dir name
DIRS := $(patsubst %/Dockerfile,%,$(basename $(DOCKERFILES)))

#remain only dir name list
NAMES := $(notdir $(DIRS))

#add prefix combine to function strings
TARGETS := $(addprefix build-image-,$(NAMES))

#get all functions and run it.
all: $(TARGETS)

舉例而言，你有以下目錄結構

• a/README.md
• b/Dockerfile
• b/README.md
• c/Dockerfile
• d/test.c

你現在只要輸入 make all 就會自動把 b/Dockerfile 與 c/Dockerfile 找出來，並且組成字串 build-image-b build-image-c 然後呼叫到範例(1)來呼叫兩個 docker build

Reference

• 8.2 Functions for String Substitution and Analysis
• Makefile的一些用法
• 寫 Web 也可以用 Makefile：好好管理你的環境流程

目錄:

• 對於 Version and Go 相關詳解(part1)

• 開始實戰 vgo (part2)

摘要

vgo 是 Golang 將在 1.11 提出的新功能．提供著套件的管理與版本的控制．

本篇文章會解釋 vgo (versioning go) 與 dep 在 sub-package的挑選上有什麼不同． 並且解釋出 vgo 如何解決掉大家的問題． 並且在 Go versioning 的準則 (principles) 上， Russ Cox 有列出以下的準則:

• Compatibility
• Repeatability
• Cooperation

接下來，我會整理一下近期學習的經驗．試著讓各位能在這篇文章中了解．

Compatibility

這邊講的是套件在開發上的”兼容性”，他也很強調所謂的 “Semantic Import Versioning” ． 也就是如同上圖所顯示的部分一樣，任何的產品與套件都應該遵循以上的版本法則．

• Major version: 具有向後不相容的變動，就要變更．
• Minor version: 當有新的功能加入，就要變更．
• Patch version: 只是問題的修復．

在這裡，只要是 Major version 是一樣的話，就不應該產生有任何向後不相容的變動．也建議不要有 API 的版本變動．

Repeatability

為了讓每個使用軟體（或是套件）上能夠讓每個人在任何時間都能夠透過相同的程式碼與相同的套件版本來使用．

在 Opening keynote: Go with Versions - GopherConSG 2018 演講的時候 ， Russ Cox 曾經提到一個很重要的概念．

What is software engineering?

Software engineering is what happens to programming when you add time and other programmers.

也就是說 Software Engineering 是經過一段時間的開發，並且是跟其他人一起開發． 所以來說”版本的可重複性”(Repeatability) 就格外的重要．

• 你必須要在半年後接手開發的人，能夠拿到跟你目前一樣狀態的品質與原始碼．
• 你也必須要讓其他人不論本地端是否有預裝哪些套件，也要能夠拿到相同的代碼

在提到其他的部分之前，我們得提一下跟 Repeatability 相反的部分． Low-Fidelity Builds

Low-Fidelity Builds

這裡解釋一下，何謂 “Low-Fidelity Builds” ．並且解釋為何 vgo 能夠達成 High-Fidlity Build.

Low-Fidelity Builds (低忠誠度的版本)，也就是表示你的版本控管並不嚴謹．使得你的套件在版本變更的時候，會讓你的產品穩定度低下．

假設我們開發套件 A ，裡面使用到 B 與 C 套件．假設 A 必須要使用到 B1.2 與 C1.2 才能正常運作．

範例 1: 使用 go get

當你使用 go get 他會檢查目前 GOPATH 資料夾內是否有相關套件， 條件如下:

• 當套件存在的時候，他會直接使用該套件（不論版本是否新舊）
• 當套件不存在的時候，會抓下最新的套件．

問題:

當你 GOPATH 裡面有 B1.1 這時候跑 go get 就不會更新套件，而造成你在跑的時候可能會造就 build fail 的狀態．

範例 2: 使用 go get -u

使用 go get -u 會無條件將所有使用的套件更新到最新版本，這並不是代表沒有問題的．

問題:

如同以上的圖示，如果執行到 go get -u 就會抓下最新的套件 B 與 套件 C ．也就是說會抓下 B1.2 與 C1.3 ．由於套件 A 在開發的時候，並沒有測試過 C1.3 這個版本的套件，這時候可能會造成錯誤的產生．

結論

所以可以看得出來，不論是原生的 go get -d 或是更新套件 go get -u 的方式．透過這些方式所產生的套件管理都是具有低忠誠度的版本控管．

接下來會來解釋，透過 vgo 能夠如何來管理套件的版本並且解決原始 go get 所帶來的問題．

接下來會帶到 vgo 如何透過 Minimal Version Selection 來解決這樣的問題．

下次文章會開始解釋 MVS (Minimal Version Selection)

Reference

• Opening keynote: Go with Versions - GopherConSG 2018
• A Proposal for Package Versioning in Go
• Go & Versioning

Problem

If you have big repo, you want to separate it into several small repos.

There are two approach you might google it, here is different

Subtree

git subtree split -P feature_a -b "branchA"

It will separate your code, but it will include whole git history. It will slow-down your CI/CD flow if your original repo history is very huge.

Filter-Branch

which rewrites the repo history picking up only those commits that actually affect the content of a specific subdirectory. (refer to refer 2)

git filter-branch --prune-empty --subdirectory-filter SUBDIR -- --all

Reference

• Splitting a subfolder out into a new repository
• Difference between git filter branch and git subtree?
• Using Git subtrees for repository separation

這幾天閱讀 Damian Gryski 的 blog post “Consistent Hashing: Algorithmic Tradeoffs” 整理出來的投影片 (第一版)

應該會找時間寫寫中文 blog

放上這次再 GTG (Golang Taipei Gathering 30)聚會的投影片，主要是介紹可能會放入 go 1.11 的新功能 vgo