2024-05-14

[踩雷筆記] Gitlab CI/CD 與 GCP - 靜態網站部署整合 404 與 `/`

前情提要

最近將公司的所有靜態網站轉換到 GCS 上了，遇到一些情境，特此記錄
這篇會以 Vue 與 Nuxt 的角度出發。
在前後端分離的情況下，SEO 變成一個問題，SSR 可以解決這個問題，
我們可以使用 Nuxt 建立我們的專案，並透過 generate 生成靜態檔案。

再進一步來說，我們可以整合 GCS 進行靜態網站的部署

題外話

Nuxt 的幾種建置方式

npx nuxt build
The build command creates a .output directory with all your application, server and dependencies ready for production.
這個命令會建立一個 .output 目錄，裡面包含了你的應用程式、伺服器和所有必要的依賴，準備好用於生產環境。
預設的行為，可以實作 SSR(Server Side Render)，適用有 SEO 需求，且變化快速的網站，Ex: 電商產品頁
npx nuxt build --prerender
–prerender false Pre-render every route of your application. (note: This is an experimental flag. The behavior might be changed.) .
–prerender false 會對應用程式的每個路由進行預渲染。（注意：這是一個實驗性的標誌。行為可能會更改。）；
它會先產生好 HTML，適合 SSG 網站(內容不常改動，但有 SEO 需求）。Ex: BLOG
npx nuxt generate

The generate command pre-renders every route of your application and stores the result in plain HTML files that you can deploy on any static hosting services. The command triggers the nuxi build command with the prerender argument set to true
這個命令會對你的應用程式的每個路由進行預渲染，並將結果存儲在普通的 HTML 文件中，你可以部署到任何靜態托管服務上。　　
該命令會觸發 nuxi build 命令，並將 prerender 參數設置為 true。
它適合純靜態的網頁(SPA)。Ex: Landing Page.　與前者最大的差異是，前者會建置成不同的 HTML，

問題

當我們在建置好靜態網站並部署到 GCS 上時，我遇到了一個異常的問題，
當我複製貼上網址時會發生 404 Not Found，主因是當我的網址結尾不是/時，
瀏覽器會轉導到 /index.html。
舉例說明:

https://marsen.me/sample 複製貼上，會轉導到 https://marsen.me/sample/index.html
而這頁不存在，導致產生 404 的錯誤

解法

採取升級 Nuxt 到 v3.8.0 以上，
這是實驗性的功能，雖然目前有效，仍需觀注未來更新的狀況。
若不打算升級，另外有用 middleware 處理重定向，
可參考此 issue 的討論串，
要寫比較多，而且留言者在部署到 vercel 有遇到其他問題。故採升級的方式解決此題。

參考

靜態網站部署整合 GCP - Load Balancing & Cloud Storage
[實作筆記] Gitlab CI/CD 與 GCP 相關文章

(fin)

2024-04-17

[實作筆記] 清理 CI/CD (Gitlab-runner)

寫在前面

NM;DR
沒有什麼意義，不需要讀這篇

緣由

CI/CD 執行失敗，檢查錯誤發現是 Gitlab-runner[*1] 主機空間不足。

處理歷程

連線 Gitlab-runner 主機
查詢空間使用狀況，找到佔磁區的資料

marsen@gr00:~$ sudo du -h --max-depth=1 /
24K /tmp
0 /sys
74M /boot
… skip …
24K /root
94G /var
97G /
用指令作深層的搜尋　sudo du -h --max-depth=3 /var
發現 docker 的問題最大

252K /var/lib/docker/containers
4.0K /var/lib/docker/trust
4.0K /var/lib/docker/runtimes
91G /var/lib/docker
不選擇清理磁碟，而用 docker 指令檢查 docker images
批次刪除指令　docker images -f "dangling=true" -q | xargs docker rmi
再次檢查

marsen@gr00:~$ sudo du -h --max-depth=1 /
24K /tmp
0 /sys
74M /boot
… skip …
24K /root
16G /var
20G /

後續

可能要建立一個排程定期去清理 CI/CD 無用的 image
- 可以的話想整入 CI/CD 作業中，但在 DinD[*2] 的環境不確定怎麼實作
log 與 cache 也有看到較高的資料成長曲線，未來也要納入評估

20240829 更新設置定期清理腳本

建立 cleanup.sh，並將其放置在 root 根目錄下：

1 2	sudo cp /path/to/cleanup.sh /root/ sudo chmod +x /root/cleanup.sh

cleanup.sh 的內容：

#!/bin/bash

# 清理未使用的 Docker 資源
sudo docker system prune -a --force --volumes

# 清理未使用的 Docker 卷
sudo docker volume prune --force

# 縮減系統日誌大小
sudo journalctl --vacuum-time=30d

設置排程

以 root 用戶創建定期排程以每月執行清理腳本：

打開 cron 編輯器：

1	sudo crontab -e

在 cron 編輯器中添加以下行：

1	0 0 1 * * /root/cleanup.sh > /root/cleanup.log 2>&1

0 0 1 * *：每月的第一天午夜執行。
/root/cleanup.sh：執行清理腳本。
/root/cleanup.log 2>&1：將輸出和錯誤重定向到 /root/cleanup.log。

驗證和檢查

手動運行清理腳本以驗證它是否按預期工作：

1	sudo /root/cleanup.sh

查看 cron 日誌

檢查 cron 日誌以確保定期任務已成功運行：

在 Ubuntu/Debian 系統上：

1	sudo grep CRON /var/log/syslog

使用 journalctl（如果使用 systemd）：

1	sudo journalctl -u cron

註解

Gitlab-Runner 是　Gitlab Solution 中執行工作的實體，可以是多台，此案只有單台
Dind: Docker In Docker,如同字面意思，在 Docker 中跑 Docker，是 Gitlab-runner 的實作方法之一

(fin)

2024-04-17

[實作筆記] Gitlab CI/CD 與 GCP - Cloud Run 方案選擇過程記錄

前情提介

在我的實務經驗上，很常與新創團隊合作，而架構選擇常常是第一個問題，
最常見的解法是，由技術負責人選擇最熟悉的技術…
這樣真的好嗎?
比如說，T 社早期由某群工程人員開發，
選擇了 Go、Nodejs、C# 等多語言與雲端 GKE(K8S) 作為開發架構，
事後不負責任離職後，對持續的運作與維護都造成了困難
這件事對我的警鐘是 — 作為管理者，如果不具備識別專業的能力，就只能透過信賴某人或團隊;這是非常脆弱且危險的。

執行環境的選擇

作為 Web 開發者，最常用的執行環境由簡入繁如下:

地端到雲端到

開發機就是正式機: 通常只是用來展示，開發者最常這樣作
地端的主機: 沒有技術能力公司，很有可能都是這樣的架構，直接向開發商買主機放機房或是由開發商部署
地端的虛擬機(VM): 會用較高規格的機器部署多台 VM，可以更有效使用資源
雲端的虛擬機(VM): 使用上與上面差不多，但是由大廠來維持高可用性，學習門檻低
雲端的 Server Less: 需要熟悉不同雲的相關產品，算是有點門檻，完成後可以精準控制預算、減少人力成本、透過雲維持高可用性
雲端的 K8s: 門檻較上面更高，也有相同的優點，但是會有更高的可控性，適合有一定使用規模後，需要細部彈性調整資源的公司。
再回地端: 如果規模再繼續成長，雲端的成本變得高不可攀時，或控制力下降，在有一定的技術水準情況下，有的公司會選擇回到地端。參考 37signals 的例子

GCP Cloud Run

回歸本文，我選擇了 GCP Cloud Run，這是一種雲端的 Server Less 的解決方案。
產品的規模沒有大到需要 K8s，團隊成員的具備足夠的能力，
類似的方案還有 Cloud Function，
作為一個 Web API Base 的輕量專案，我評估 Cloud Run 更適合
Cloud Function 較適合 Event Driven 的片段行為
Cloud Run 較適合有點複雜度，但是可以容器化的應用。

參考關鍵字

參考

[實作筆記] Gitlab CI/CD 與 GCP 相關文章

(fin)

2024-03-29

[實作筆記] MacBook Terminal 美化與設計

前情提要

參考前文，受同事啟發，改用 zim 取代 oh-my-zsh，
用更高效與精煉的方式設定 terminal 環境，
看看下面的小故事與 Zim 的官網，
這就我選擇更換的原因。

小故事

可以參考此文，

當前流行的 Zsh 框架有三個主要選項：Oh My Zsh、Prezto 和 Zim。
Oh My Zsh 是最受歡迎的，但因其過於龐大、混亂和性能問題而受到批評。
Prezto 是對其的重大改進，但未被合併回 Oh My Zsh。
而 Zim 是一個從頭重寫的框架，非常快速、高效，並將許多最佳想法結合在一起。
Zim 還提供了各種主題和模塊，並且易於安裝和管理。
這些框架在定製 Zsh 提示符、增加功能和優化性能方面提供了不同的選擇。

Overview

下載與設定 iTerm2
安裝 zim
安裝 powerlevel10k

第一步下載並安裝 iTerm2

設定 iTerm2 的外觀

從網站 iTerm2-Color-Schemes (https://github.com/mbadolato/iTerm2-Color-Schemes) 下載你喜歡的配色方案，
例如 “DimmedMonokai.itermcolors”。
開啟 iTerm2，點擊菜單欄的 “iTerm2”，選擇 “Preferences”。
在偏好設定視窗中，選擇 “Profiles” 選項卡，然後選擇你要更改配色方案的會話配置文件。
在 “Colors” 選項卡下，點擊 “Color Presets” 按鈕，選擇 “Import…”。
找到剛才下載的配色方案檔案，例如 “DimmedMonokai.itermcolors”，點擊 “Open”。
選擇 “DimmedMonokai” 作為你的 iTerm2 配色方案。

import .itemcolors

Profiles 裡有更多的設定, 字型、顏色
比如說, 調整啟始視窗大小與背景透明度, 可以前往 Windows 進行設定.
更多的細部設定可以自行摸索. 　
記得重新載入才能看到效果

第二步, 安裝 zim

1	curl -fsSL https://raw.githubusercontent.com/zimfw/install/master/install.zsh \| zsh

即可完成安裝，並預設定一些相當實用的模組，可以參考

設定

一般來說不需要這些額外的設定，我的情況是同時需要移除 oh-my-zsh 才會有額外的項目需要進行
進入 ~/.zshrc　修改

一、刪除 oh-my-zsh 的區塊
常用的一些工具，都被整合在 zim 之中了
例如　zsh-syntax-highlighting　原本在 zshrc 的設定如下
現在都可以全數刪除

# Install zsh-syntax-highlighting if it's not installed
if [ ! -d ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting ]; then
  git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting
fi

# Load zsh-syntax-highlighting plugin
plugins+=(zsh-syntax-highlighting)

# Set name of the theme to load --- if set to "random", it will
# load a random theme each time oh-my-zsh is loaded, in which case,
# to know which specific one was loaded, run: echo $RANDOM_THEME
# See https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
ZSH_THEME="powerlevel10k/powerlevel10k"

由於zim本身就有包含 zsh-syntax-highlighting，
所以其它相關的設定不會有問題。
例如：

ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE='fg=177'
ZSH_HIGHLIGHT_HIGHLIGHTERS=(main brackets)
typeset -A ZSH_HIGHLIGHT_STYLES
ZSH_HIGHLIGHT_STYLES[comment]='fg=242'

Prompt 設定

Prompt 主要影響 terminal 的外觀，
一般來說社群主流會推薦的 Powerlevel10k 後面會提供實作步驟，
但是 zim 已經提供足夠的 theme作選擇，
下面選用 minimal (zim 提供的輕量版主題)作範例　
我們可以修改 ~/.zimrc 即可完成設定

1 2	# A heavily reduced, ASCII-only version of the Spaceship and Starship prompts. zmodule minimal

安裝 Powerlevel10k

不過 zim 一樣可以使用 Powerlevel10k
前往 Powerlevel10k
我們使用 zim 的方式安裝

修改 ~/.zimrc

1	zmodule romkatv/powerlevel10k --use degit

後執行　zimfw install

之後重啟 iTerm2 將會有一連串設定問題, 依照喜歡的設定即可,
可以參考這個影片,
如果設定完後不喜歡, 可以執行 p10k configure 重新設定
比較一下，效果我覺得都不錯

參考

(fin)

2024-03-19

[學習筆記] TypeScript 的 Using 與 Symbol.dispose

介紹

TypeScript 在 5.2 引入了一個新關鍵字 using - 可用於在離開作用域時使用 Symbol.dispose 函數處理任何內容。

看一下官方的說明

TypeScript 5.2 introduces support for the forthcoming Explicit Resource Management feature in ECMAScript,
which aims to address the need for “cleaning up” after creating an object.
This feature allows developers to perform necessary actions such as closing network connections,
deleting temporary files, or releasing memory.

using 與 await 的目的在於釋放資源上會非常有用。

在舉例子之前先看一下新的全域 Symbol:Symbol.dispose 與 Symbol.asyncDispose,
任何將函數分配給 Symbol.dispose 的物件都將被視為「資源」（“具有特定存留期的物件”），並且可以與 using 關鍵字一起使用。

舉例來說:

{
  const getResource = () => {
    return {
      [Symbol.dispose]: () => {
        console.log('Hooray!')
      }
    }
  }

  using resource = getResource();
} // 'Hooray!' logged to console

當程式離開 resource 所在的 scope 後，就會觸發 Symbol.dispose 的 function

應用

比較常見的場景在於存取 DB、File System 等…
我們現在的作法需要用 try...finally 進行處理

export function processFile(path: string) {
    const file = fs.openSync(path, "w+");

    try {
        // use file...

        if (someCondition()) {
            // do some more work...
            return;
        }
    }
    finally {
        // Close the file and delete it.
        fs.closeSync(file);
        fs.unlinkSync(path);
    }
}

而改用 using 後可以變得如此簡單

export function processFile(path: string) {
    using file = new TempFile(path);

    // use file...

    if (someCondition()) {
        // do some more work...
        return;
    }
}

參考

(fin)

2024-03-13

[實作筆記] Gitlab CI/CD 與 GCP - Workload Identity Federation

前情提介

現況用 Service Account 會有什麼問題？
當我們希望與第三方的服務與 GCP 作整合時，
傳統的（我之前的）作法是透過建立 Service Account Key 去提供給第三方資源存取的權限。
這會產生資安隱患，主要是這把 Key 的權粒度大難以稽核，有效期長風險，
而要定期更換 Key 會變成一個麻煩的管理問題。

需求介紹

我目前透過 GCS 並掛載 Load Balancing 部署靜態網站，
而 CI/CD 是透過 Service Account 的 Key 去執行工作，
這是一種有資安隱憂的作法，所以我試著使用 Workload Identity Federation 取代

概念

TLDR;

而 Workload Identity Federation 是基於 IAM 機制，允許第三方服務整合 GCP 資源，
背後的技術原理是基於 OIDC，在這裡我們不過度展開，簡單描述如下:

Gitlab CI／CD 首先取 Gitlab OIDC Token，取得 Token 的作法可以參考官方文件，下面是個簡單的範例:


job_with_id_tokens:
  id_tokens:
    FIRST_ID_TOKEN:
      aud: https://first.service.com
    SECOND_ID_TOKEN:
      aud: https://second.service.com
  script:
    - first-service-authentication-script.sh $FIRST_ID_TOKEN
    - second-service-authentication-script.sh $SECOND_ID_TOKEN

｜OIDC 是基於 Oauth2 的標準，簡單可以想成 Oauth2 再加上身份驗証。
2. 有了 Gitlab OIDC Token，我們可以透過 GOOGLE STS(Security Token Service) API 取得　Federated Token
在這裡我們需要先建立好 Workload Identity Provider(IdP)，而可以設定 Attribute Conditions 來作限制
3. 這個時候可以用 Federated Token 與 GCP IAM API 交換來一個短周期的 Access Token
4. 本質上還是用 Service Account 在作事，但是用短周期的 Access Token 取代 Key, 從而簡化了 Key 的管理工作

實作步驟

建立 Workload Identity Pool

#Update $GCP_PROJECT_ID value
gcloud iam workload-identity-pools create gitlab-test-wip \
  --location="global" \
  --description="Gitlab demo workload Identity pool" \
  --display-name="gitlab-test-wip" \
  --project=$GCP_PROJECT_ID

設定 workload identity pool provider 並建立 Attribute conditions,
這步的關鍵是讓只符合你條件設定的 User 才能取得 Token

#Update GITLAB_NAMESPACE_PATH value
gcloud iam workload-identity-pools providers create-oidc gitlab-identity-provider --location="global" \
--workload-identity-pool="gitlab-test-wip" \
--issuer-uri="https://gitlab.com" \
--allowed-audiences=https://gitlab.com \
--attribute-mapping="google.subject=assertion.sub,attribute.aud=assertion.aud,attribute.project_path=assertion.project_path,attribute.project_id=assertion.project_id,attribute.namespace_id=assertion.namespace_id,attribute.namespace_path=assertion.namespace_path,attribute.user_email=assertion.user_email,attribute.ref=assertion.ref,attribute.ref_type=assertion.ref_type" \
#--attribute-condition="assertion.namespace_path.startsWith(\"$GITLAB_NAMESPACE_PATH\")" \
--attribute-condition="assertion.namespace_path.startsWith(\"marsen\")" \
--project=$GCP_PROJECT_ID

建立 GCP Service Account
在我的例子中

#Create a service account
gcloud iam service-accounts create gitlab-runner-sa --project=$GCP_PROJECT_ID

#Add sample permissions to the Service account
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
  --member=serviceAccount:gitlab-wif-demo@${GCP_PROJECT_ID}.iam.gserviceaccount.com \
  --role=roles/storage.admin

建立 Service Account 與 WIP 的角色關係綁定

可以先取得專案的 GCP Project Id

1	PROJECT_NUMBER=$(gcloud projects describe $(gcloud config get-value core/project) --format=value$projectNumber$ --project $GCP_PROJECT_ID)

設定 Service Account 的角色為 workloadIdentityUser，並將其設定為 workloadIdentityPools 的服務帳戶

1
2
3

gcloud iam service-accounts add-iam-policy-binding gitlab-runner-sa@${GCP_PROJECT_ID}.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="principalSet://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/gitlab-test-wip/*"

建立 Gitlab CI/CD 進行測試

image: node:20.9.0-alpine

.gcp_wif_auth: &gcp_wif_auth
  #id_tokens to create JSON web tokens (JWT) to authenticate with third party services.This replaces the CI_JOB_JWT_V2
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://gitlab.com
  before_script:
    - apt-get update && apt-get install -yq jq
    #Get temporary credentials using the ID token
    - |
      PAYLOAD=$(cat <<EOF
      {
      "audience": "//iam.googleapis.com/${GCP_WORKLOAD_IDENTITY_PROVIDER}",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:access_token",
      "scope": "https://www.googleapis.com/auth/cloud-platform",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:jwt",
      "subjectToken": "${GITLAB_OIDC_TOKEN}"
      }
      EOF
      )
    - |
      echo "Payload: ${PAYLOAD}"
    - |
      FEDERATED_TOKEN=$(curl -s -X POST "https://sts.googleapis.com/v1/token" \
      --header "Accept: application/json" \
      --header "Content-Type: application/json" \
      --data "${PAYLOAD}" \
      | jq -r '.access_token'
      )
    #- | 
    #  echo "Federated Token: ${FEDERATED_TOKEN}"
    #Use the federated token to impersonate the service account linked to workload identity pool
    #The resulting access token is stored in CLOUDSDK_AUTH_ACCESS_TOKEN environment variable and this will be passed to the gcloud CLI
    - |
      WHAT_IT_IS=$(curl -s -X POST "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${SERVICE_ACCOUNT_EMAIL}:generateAccessToken" \
      --header "Accept: application/json" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer ${FEDERATED_TOKEN}" \
      --data '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \
      | jq -r '.'
      )
    - |
      echo "WHAT_IT_IS: ${WHAT_IT_IS}"
    - |
      export CLOUDSDK_AUTH_ACCESS_TOKEN=$(curl -s -X POST "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${SERVICE_ACCOUNT_EMAIL}:generateAccessToken" \
      --header "Accept: application/json" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer ${FEDERATED_TOKEN}" \
      --data '{"scope": ["https://www.googleapis.com/auth/cloud-platform"]}' \
      | jq -r '.accessToken'
      )

stages:
  - deploy-prod

deploy-prod:
  variables:
    GCP_PROJECT_NAME: my-project-9527
    GCP_WORKLOAD_IDENTITY_PROVIDER: "projects/000009527/locations/global/workloadIdentityPools/gitlab-test-wip/providers/gitlab-identity-provider"
    SERVICE_ACCOUNT_EMAIL: "[email protected]"
  <<: *gcp_wif_auth
  stage: deploy-prod
  image: google/cloud-sdk:latest
  script:
    - echo "Deploying artifacts to PROD GCS🚀🚀🚀"
    - echo $CLOUDSDK_AUTH_ACCESS_TOKEN
    - gcloud config set project ${GCP_PROJECT_NAME}
    - gcloud storage cp -r $CI_PROJECT_DIR/dist/* gs://my-static-website/

參考

(fin)

2024-02-24

[學習筆記] 為前端框架 Component 建立 Props Typing 的幾種方式，以 React 為例

前言

在開發 React 應用程式時(其它框架其實也適用)，
使用 TypeScript 來強制定義 props 是一個常見的做法。
然而，有許多不同的方法可以實現這一目標。這篇文章討論了三種主要的方法。

比較

Inline Object Literals

在這個方法中，我們直接在函式的參數位置定義了 props 的型別，如下所示：

const Wrapper = (props: {
  children?: ReactNode;
}) => {
  return <div>{props.children}</div>;
};

優點：快速簡潔。
缺點：不太適合長期維護。

另一種解構的寫法會有更少的字數，
它會有一個 {}:{}特殊寫法，前者表示傳入的參數，後者表示要被解構的物件與型別
這樣的寫法最主要在 component 當中要使用傳入參數時可以省略 prop. 的語法，
但是理解上會不會更困難(對於不熟悉的開發者而言)就見團隊見智了…

 
const Wrapper = ({
  children,
}: {
  children?: ReactNode;
}) => {
  return <div>{children}</div>;
};

Type Aliases

在這個方法中，我們把 props 的型別定義抽取到一個類型別名中：

export type WrapperProps = {
  children?: ReactNode;
};

const Wrapper = (props: WrapperProps) => {
  return <div>{props.children}</div>;
};

優點：可以在其他文件中重用。
缺點：在大型代碼庫中可能會讓 TypeScript 變慢。

Interfaces

在這個方法中，我們使用介面來定義 props：

export interface WrapperProps {
  children?: ReactNode;
}

const Wrapper = (props: WrapperProps) => {
  return <div>{props.children}</div>;
};

優點：性能較好，在大型代碼庫中表現較好。
缺點：需要較多的代碼。

小結

儘量使用 interface 會有較好的效能，同時可以共用這些代碼並幫助理解。

參考

(fin)

2024-02-22

[學習筆記] Vim 學習資源

介紹

Vim 是一款強大高效的文本編輯器，強調效率和快速操作。
學習 Vim 能顯著提升編輯速度和效率，無需滑鼠，節省操作時間。
這裡記錄著我的學習資源，提供給未來的我複習使用。

TLDR Tips

gg：移動到檔案的第一行
G：移動到檔案的最後一行
gg=G：重新縮排整個檔案
gv：重新選取上一次的視覺選取
`` <`：跳到上一次視覺選取的開始
`` >`：跳到上一次視覺選取的結尾
^：移動到行的第一個非空白字符
g_：移動到行的最後一個非空白字符
g_lD：刪除行上的所有尾部空白
ea：在當前單字的末尾插入
gf：跳到游標下的文件名
xp：向前交換字符
Xp：向後交換字符
yyp：複製當前行
yapP：複製當前段落
dat：刪除包括標籤在內的 HTML 標籤
dit：刪除 HTML 標籤內的內容，但不包括標籤本身
w：向右移動一個單字
b：向左移動一個單字
dd：刪除當前行
zc：關閉當前摺疊
zo：打開當前摺疊
za：切換當前摺疊
zi：完全切換摺疊
<<：向左移動當前行的縮排
>>：向右移動當前行的縮排
z=：顯示拼寫更正
zg：添加到拼寫字典
zw：從拼寫字典中刪除
~：切換當前字符的大小寫
gUw：將大小寫轉換到單字的末尾（u 用於小寫，~ 用於切換）
gUiw：將整個單字轉換為大寫（u 用於小寫，~ 用於切換）
gUU：將整行轉換為大寫
gu$：將直到行尾的文本轉換為小寫
da"：刪除下一個雙引號括起來的字符串
+：移動到下一行的第一個非空白字符
S：刪除當前行並進入插入模式
I：在行的開頭插入
ci"：更改下一個雙引號括起來的字符串內容
ca{：更改大括號內的內容（也可以試試 [, ( 等）
vaw：視覺選取單字
dap：刪除整個段落
r：替換字符
``[`：跳轉到上次複製的文本的開始
``]`：跳轉到上次複製的文本的結尾
g;：跳轉到上次更改的位置
g,：向前跳轉到更改列表
&：在當前行上重複上次的替換
g&：在所有行上重複上次的替換
ZZ：儲存當前檔案並關閉

學習資源

內建學習工具

1	> vimtutor

(fin)

2024-01-25

[實作筆記] 一些關於 Azure Resource Group 的冷知識

前情提要

Resource Group 是 Azure 上比較特別的一個設計，
這裡拿來記錄一些知道就知道，不知道就不知道的小事務。

本文

NetworkWatcherRG

https://learn.microsoft.com/zh-tw/azure/network-watcher/network-watcher-create?tabs=portal#delete-a-network-watcher-in-the-portal

注意

當您使用 Azure 入口網站建立網路監看員實例時：

網路監看員實例的名稱會自動設定為NetworkWatcher_region，其中region會對應至網路監看員實例的 Azure 區域。
例如，在美國東部區域中啟用的網路監看員名為NetworkWatcher_eastus。
網路監看員實例會建立在名為NetworkWatcherRG的資源群組中。若尚無該資源群組，將會加以建立。

Azure DevOps

https://learn.microsoft.com/en-us/azure/devops/organizations/billing/set-up-billing-for-your-organization-vs?view=azure-devops

當我們將 Azure DevOps 的 Billing 綁定之時，
會建立一組 VisualStudioOnline-XXXX 的 Resource Group

(fin)

2024-01-25

[實作筆記] Macbook 壓縮檔案

前情提要

假設分享機密文件給同事或者發送文件到郵件或雲端儲存時，就必須手動處理壓縮和加密，
可以參考一些文章，大致有三個作法

購買付款壓縮軟體
使用雲端服務
手動執行 terminal 指令

手動執行就可以處理的問題，我不會特別想要付款買一個軟體，
而雲端服務會擔心資訊安全，特別是要加密的資料代表有一定程度的重要性。
Terminal 大概是網路文章的主流解。
當我需要經常這樣做時，就太麻煩了，還要記得操作指令，額外增加心智負擔。
理想上，我希望只要選擇文件或資料夾，右鍵點擊”Zip with Password”，就能創建加密的 zip 文件。

實作

打開 Automator app。
創建一個新 Automator 文件：File > New (或按 ⌘N)，選擇 “Quick Action” 類型。
將輸入類型更改為 “files or folders”。
在左側的 Actions library 中，雙擊 “Run AppleScript”，或拖放到右側工作區。刪除示例代碼，替換為第 5 步的腳本。

複製並粘貼下面的 AppleScript 代碼。


set prompt_text to "請輸入壓縮密碼"

repeat
    set zip_password to text returned of (display dialog prompt_text default answer "" with hidden answer)
    set verify_password to text returned of (display dialog "再次輸入壓縮密碼" buttons {"OK"} default button 1 default answer "" with hidden answer)
    considering case and diacriticals
        if (zip_password = verify_password) then
          exit repeat
        else
            set prompt_text to "密碼不一致，請重新設定"
        end if
    end considering
end repeat

tell application "Finder"
    set the_items to selection
    if ((class of the_items is list) and (count of the_items) > 0) then
        set items_to_zip to ""
        repeat with each_item in the_items
            set each_item_alias to each_item as alias
            set item_name to name of each_item_alias
            set item_name to quoted form of (item_name & "")
            set items_to_zip to items_to_zip & item_name & " "
        end repeat

        set first_item to (item 1 of the_items) as alias
        set containing_folder to POSIX path of (container of first_item as alias)
        set zip_name to text returned of (display dialog "輸入壓檔名" default answer "")
        set zip_file_name to quoted form of (zip_name & ".zip")

        if zip_password is not equal to "" then
            -- 如果存在密碼，執行加密壓縮
            do shell script "cd '" & containing_folder & "'; zip -x .DS_Store -r0 -P '" & zip_password & "' " & zip_file_name & " " & items_to_zip
        else
            -- 否則執行單純壓縮
            do shell script "cd '" & containing_folder & "'; zip -x .DS_Store -r0 " & zip_file_name & " " & items_to_zip
        end if
    else
        display dialog "你未選擇任何檔案。" buttons {"OK"} default button 1
    end if
end tell

儲存工作流程：File > Save (或按 ⌘S)，給它一個名字，如 “Zip with Password”

現在，選擇文件或文件夾，右擊，選擇 “Quick Actions” 中的 “Zip with Password”，
按照提示輸入密碼、驗證密碼和設置 zip 文件的名字。測試新創建的 zip 文件，確保一切運作正常。

參考

(fin)

前情提要

題外話

問題

解法

參考

寫在前面

緣由

處理歷程

後續

20240829 更新設置定期清理腳本

設置排程

驗證和檢查

查看 cron 日誌

註解

前情提介

執行環境的選擇

地端到雲端到

GCP Cloud Run

相關作業

20240427 更新

參考關鍵字

參考

前情提要

小故事

Overview

第一步 下載並安裝 iTerm2

設定 iTerm2 的外觀

第二步, 安裝 zim

設定

Prompt 設定

安裝 Powerlevel10k

參考

介紹

應用

參考

前情提介

需求介紹

概念

實作步驟

參考

前言

比較

Inline Object Literals

Type Aliases

Interfaces

小結

參考

介紹

TLDR Tips

學習資源

前情提要

本文

NetworkWatcherRG

Azure DevOps

前情提要

實作

參考

第一步下載並安裝 iTerm2