只要 5 分鐘!讓你的 Mac 擁有美觀的 Terminal!2024 最新最簡單快速的 Zsh + iTerm2 + Powerlevel10k 設定教學

前言

最近在重新設定 Mac 的 Terminal 時,發現現在關於 Zsh 和 iTerm2 的網路文章都太舊、很多指令已經不適用、安裝順序也很混亂,對於新手來說我覺得會很挫折,所以決定用最簡潔的方式把自己最近設定的流程記錄下來,目的是希望新手們也能輕鬆快速擁有一個美觀好用的 Terminal (幾年前我還是新手的時候,真的是設定到很崩潰…)

環境需求

  1. MacOS
  2. 已安裝 Homebrew
  3. 已安裝 git

安裝順序

請按照 1~5 步驟的順序,在 Terminal 中執行指令

1. 安裝 zsh

brew install zsh

2. 安裝 oh-my-zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

3. 安裝 iTerm2

brew install iterm2

4. 安裝主題 Powerlevel10k

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

5. 設定主題

開啟 iTerm 並執行:

vi ~/.zshrc
  1. 按下 i 切換成 insert 模式,往下拉會看到 ZSH_THEME,將它設定為 ZSH_THEME="powerlevel10k/powerlevel10k",輸入 :wq 儲存並離開
  2. 執行指令:exec $SHELL
  3. 照著互動式的選擇題,依自己需求和喜好去輸入對應字母數字,最後就會自動套用到設定檔(若沒有跳出互動式設定或是想要再次調整,隨時可執行指令 p10k configure 去做設定)

完成!

恭喜!你的 Terminal 已成功美化!

(內建的 Tango Dark 主題就已經很好看)

如果想要讓使用體驗更升級的話, 請往下繼續閱讀~


進階推薦:安裝 zsh 的 Plugins

可以選擇安裝自己需要的!

1. 安裝

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
  • zsh-z:快速前往常用或最近使用的資料夾
git clone https://github.com/agkozak/zsh-z $ZSH_CUSTOM/plugins/zsh-z

2. 設定 Plugins 並啟用

  • 開啟設定檔 .zshrc
vi ~/.zshrc
  • 按下 i 切換成 insert 模式,往下拉看到 plugins 後在括號內加上 plugins 的名稱
    我的範例如下(bindkey 那行是讓我可以用 tab 鍵自動補完指令)
# In ~/.zshrc 

plugins=(git zsh-autosuggestions zsh-syntax-highlighting zsh-z) 
 
bindkey '^I' autosuggest-accept 

  • 按下 :wq 儲存檔案,並執行以下指令啟用設定 exec $SHELL

如果 VS Code 的 Terminal 無法正常顯示圖示的話

⬆️ 沒有正常顯示圖示 😭

1.進入 VS Code > 點擊左下方的齒輪 > Settings

2. 點擊右上角的圖示,進入 JSON 檔

3. 新增下方設定到 settings.json ,並且記得儲存!

"terminal.integrated.fontFamily": "MesloLGS NF"
加上去後終於正常了!

有任何問題都歡迎留言討論~


參考資料

【轉職】非本科從零開始轉職工程師的心路歷程(包含給轉職者的建議)

先自我介紹一下,作者 Jumping 我本人 2019 年以前從來沒碰過程式,透過自學資料科學相關課程,目前是有三年資料領域工作經驗的資料工程師 Data engineer,這篇文章記錄了我從自學到轉職過程的心路歷程,以及給同樣想要轉職的朋友的建議。

先聊聊我的背景

或許我跟大多數人一樣,在上大學前也完全不知道自己要念什麼科系,當時只想說「總之就是三類組,然後分數到哪就去哪」, 後來大學念了食品科學系,雖然後來也是有找到一點熱情,但畢業後仍然不知道自己要什麼,看到身邊不少朋友選擇繼續念碩士,我也憑著那一點熱情考了食品科學相關的研究所,所以在我的六年學生時期是完全沒有碰過程式,大部分都是生物和化學相關的課程和實驗。

當完兵出了社會,第一份工作理所當然的選擇進了食品業做研發,當時還常常被面試官問「為什麼你要做食品研發?」,老實講,我還真的回答不出來。

這種茫然困惑、不知道自己想要做什麼的狀態,一直持續到我出社會幾個月後,接觸程式語言時才開始產生變化。

接觸程式的過程

拿到工作的薪水後,我開始想該如何做投資上的運用,這時候我開始研究公司的財報、技術分析線圖等散戶會做的一些事,在查資料時發現很多人會使用 Python 自己寫爬蟲和畫線圖,於是我開始一點一點地學習怎麼樣寫 Python 語法,後來遇到有些股票網站資訊和圖表是需要付費訂閱才能觀看時,也試著自己按照那些付費圖表的邏輯去編寫程式,並嘗試視覺化出我心中所想的圖表。

(至於我自學的方式和課程,後續的文章會再做說明)

為何轉職?以及轉職時遇到的困難?

在這樣反覆學習和實作的過程中,漸漸發現自己對於寫程式收集及處理資料很感興趣,也很享受把想法和創意透過程式作品實踐出來的過程和成就感,於是就開始思考自己是否有機會轉職做一位工程師,而當時會想轉職很大的原因是:

  • 覺得大數據是未來趨勢,所有公司將來都會需要數據來輔助決策,因此打算往數據方面的工程師發展
  • 當然薪資待遇也很重要,我待的食品業算是傳產,薪資天花板比較低,如果轉職的話比較有發展空間

但同時也要思考許多實際上的困難

  • 因為領域跨很多,所以要補的技術和知識實在太多
  • 自己當時因為研究所 + 當兵 + 工作兩年已經滿 28 歲,要怎麼跟更年輕的肝競爭,還來得及轉嗎?
  • 要離職專心自學嗎?我自己經濟狀況是否允許?

調適心態、面對挑戰

面對這些困難,我自己仍然做了轉職的決定,是因為有了心態上的調適,像是技術不足的部分我可以靠上課學習來補足,也選擇了在繼續工作的狀態下持續自學,讓我不用擔心經濟上的問題。

另外一個我覺得很重要的心態突破,就是評估了利弊之後,好好想一下「對自己來說,最糟的狀況是什麼?」,我自己的答案是「大不了我就是轉職失敗,然後回食品業工作」,所以其實現在轉職並不會有多糟的後果,也是因為這樣想,我才毅然決然繼續往轉職資料工作者的路前進。

你也想要轉職嗎?

當我過了兩三年,回顧我的轉職過程時,我覺得有幾點人生體悟,可以給想要轉職的朋友一些參考:

– 確立目標

凡事都需要一個清楚明確的目標,才能讓我們走在正確的路上!

– 動手實作

不論是在什麼領域,學習都不能只有輸入,最重要的還是輸出,學了之後一定要自己動手做,像是當時我自己的 Side Project 就幫助我找到工作。

– 放下「沉沒成本」

其實不會有所謂「真正準備好」的時候,何時開始都不嫌晚,最適合開始進行的時機就是「現在」,不要因為「沉沒成本」而委屈求全。我到現在還是很感謝當時的我所做的選擇,因為沒有當初的「捨」,就沒有現在的「得」

– 列出恐懼與困難

把自己目前想得到的恐懼和困難都寫下來,如果自己還在為了轉職而卻步,想想這些困難是「知識技術」上的挑戰?還是其實是「勇氣」的挑戰呢?列出了所有的恐懼並面對它們,說不定會發現其實自己離目標沒有想像中的遠喔!

如果你正在為了要不要轉職而猶豫不決,希望我的這些經驗能幫助到你! 也歡迎把文章分享給正在轉職的朋友們!

[Streamlit] 解決部署錯誤:Failed to create the application reverse proxy

最近在使用 Streamlit 並且使用 Streamlit cloud 進行部署的時候,在 App 跑完部署的背景流程之後,遇到一個黑畫面顯示:

{"Code":2,"RawMessage":"Failed to create the application reverse proxy"}

上網查也找不到解法,後來發現是因為我裡面有用到 Database 的 credentials(我是用 MongoDB),但忘記把他新增到 Settings 裡面的 Secrets 裡面,如下圖的地方

新增上去之後重新整理頁面,App 就可以正常執行了。

[SQL] 為何應該要使用 “IS NULL" 而不是 “= NULL"?

當我們想要找出某些欄位是 NULL 的資料…

做為資料工作者,在處理資料的時候經常會遇到所謂的空值「NULL」,也常看到這樣的值被存在資料庫的欄位中,當我們使用 SQL 想要找出某些欄位中是空值的資料,就會使用像下方這樣的 WHERE 去做篩選,但這樣其實無法得到我們想要的結果。

SELECT 
    column_1,
    column_2
FROM `my_table`
WHERE column_1 = NULL
閱讀更多»

【MongoDB 最佳實踐規範】❶ Data Modeling 篇: 資料的儲存該如何設計

  1. MongoDB 和一般關聯式資料庫 (RDBMS) 的差異
  2. MongoDB Best Practices 最佳實踐規範
  3. Data Modeling
    1. 1. 會一起被使用的數據就放在一起
    2. 2. 避免儲存較大的陣列
    3. 3. 某些情況下,建議將數據放在不同文件
    4. 4. 跨文件存放相同的數據可以提高效能
  4. 參考資料

MongoDB 和一般關聯式資料庫 (RDBMS) 的差異

MongoDB 屬於一種非關聯式資料庫,與關聯式資料庫的差異其實網路上已經有非常多的資料,個人覺得主要是 Schema 的彈性不同:MongoDB 可以不用事先定義資料欄位和型態,但像是 MySQL 就得先 Create Table 並定義固定的 schema,若後續有想要更改或是新增欄位就會比較麻煩。

所以如果你的資料隨時間變動的可能性較大、具有較高不確定性的話,MongoDB 就會是很好的選擇!

關於差異也可以參考 AWS 所做的表格

MongoDBMySQL
資料模型將資料儲存在 JSON 文件中
然後將其組織到集合中
將資料儲存在資料欄和資料列中
資料儲存採用表格式和關聯式方式
可擴展性使用複寫和碎片化來水平擴展使用垂直擴展和僅供讀取複本來大規模提升效能
查詢語言使用 MongoDB 查詢語言使用 SQL
效能擅長 INSERT 或 UPDATE 大量記錄SELECT 大量記錄時,MySQL 的速度更快
靈活性沒有結構描述,這點提供更多靈活性
使其能處理非結構化、半結構化和結構化資料
具有剛性結構描述,能有效處理結構化資料
安全性使用 Kerberos、X.509 和 LDAP 憑證來驗證使用者使用內建身分驗證方法
MongoDB vs. MySQL

MongoDB Best Practices 最佳實踐規範

基於以上所述的一些差異,在使用 MongoDB 時的操作就會有很多要注意的地方,這次藉由官方最新發布的 MongoDB Best Practices Guide 來整理一些建議的 Tips。

預計會分成四個主題,包含

  1. Data Modeling
  2. Working With Data
  3. Optimizing Data Access Patterns
  4. Availability and Scaling

Data Modeling

數據建模要考慮的,就是最後將會如何使用這些數據、如何訪問這些數據,來決定怎麼設計資料儲存的形式。

1. 會一起被使用的數據就放在一起

把可能會一起使用的數據放在同一個 document 中,可以大幅提升查詢效能,因為等於直接省去了很多類似關聯式資料庫的 Join。

如下方的 document,user 的 alerts 是直接寫在每個 user 的資料底下,而不是像 MySQL 那樣另外寫一張叫做 alerts 的資料表,這樣在查詢的時候只要查詢 users 這個 collection 就可以直接取得各自的 alerts,完全不需要再另外 Join。

像這樣的 embedded data (subdocuments) 在 MongoDB 是比較建議的做法,因為也可以讓 UPDATE 資料能在單一一個操作中完成。

// db.users
{
     _id: "abc",
     email: "xyz@example.com",
     preferences: {
     alerts:[
         { name: "morning", frequency: "daily", time: { h: 6, m: 0 } }
     ],
     colors: { bg: "#cccccc" }
     }
}

2. 避免儲存較大的陣列

由於 MongoDB 每個 document 的最大儲存上限是 16 MB,所以像是餐廳商店的評論,資料的則數和字數都是未知的,用陣列儲存在同一個餐廳商店資料階層底下,有可能就會占用很大的儲存空間。

因此這類的數據就建議每個評論分成不同的 document,並帶有餐廳商店的 ID 做參照 (如下方範例)

// businesses
{
     _id: "100",
     name: "Bake and Go",
     addresses: [
         { street: "40 Elm", state: "NY" },
         { street: "101 Main St", state: "VT" }
     ]
}

 // businessReviews
{
     _id: "61e706e2450fac1271c9b27a",
     storeId: "100",
     rating: 5,
     comment: "Best bagels in town, a must try if you are in the area."
}
{
     _id: "61e706e2450fac1271c9c522",
     storeId: "100",
     rating: 5,
     comment: "Yummy desserts and a nice place to sit and eat."
}

3. 某些情況下,建議將數據放在不同文件

其實並非所有的 1:1 或 1:many 關聯都可以直接無腦放在同一個文件中,如果有以下狀況的話,就建議將數據放在不同的文件:

  • 在很常需要讀取的文件中,包含了部分幾乎不會用到的數據
  • 文件中部份數據會隨時間更新和成長,但另外一部分卻相對固定不變
  • 文件大小可能會超過 16 MB 上限 (如同前述的第2點)

下方以一個汽車製造商的資料庫為例,汽車車款 (models) 是陣列的形式,但由於車款的資料通常都是個別顯示 (比較不會有同時需要取用多個車款的情況),所以這樣儲存陣列的話,查詢數據後就會需要進行額外的資料處理。

這是錯誤示範:

// manufacturers
{
     _id: "200",
     name: "Swaab Automotive",
     type: "auto",
     models: [
         { name: "Swaab Model X", year: 2022, sku: "SWA-X-22Z"},
         { name: "Swaab Model Y", year: 2022, sku: "SWA-Y-22Z"},
         //...
     ]
}

因此這種情況下,就比較建議將汽車 models 另外獨立成一個 collection,並且帶有製造商 ID 做參照。

而且通常 models 資料的使用也會較獨立,也可能更新比較頻繁,所以把它們拉出來做為另一個 collection 會比較方便讀取和寫入。

正確示範如下:

// models
{
     _id: "1201",
     name: "Swaab Model X",
     year: 2022,
     sku: "SWA-X-22Z",
     manufacturer_id: "200"
}
{
     _id: "1202",
     name: "Swaab Model Y",
     year: 2022,
     sku: "SWA-Y-22Z",
     manufacturer_id: "200"
}

4. 跨文件存放相同的數據可以提高效能

為了提高效能,就要避免額外的資料 JOIN 操作,所以建議可以在不同的文件中存放相同的數據。

如下方範例,在 users, posts 兩個 collections 中都存放相同的使用者 Email 數據:

// users
{
     _id: "1",
     name: { first: "Jane", last: "Doe" }
     email: "jdoe@example.com"
}

// posts
{
     _id: "1055",
     title: "My First Post",
     text: "Hello World",
     userId: "1",
     userEmail: "jdoe@example.com"
}

雖然資料看起來會比較複雜,但 MongoDB 提供了 change streamstriggers,來確保跨文件的重複存放數據都能保持同步更新和一致性。

參考資料