Jo

桌面上的筆電顯示程式碼，旁邊放著咖啡杯，象徵日常部署與開發工作流

實作筆記

[紀錄] OpenClaw 部署指定模型

上一篇先記了我初試 OpenClaw 的過程，這一輪則是把原本的 docker compose 再往前補一些，順手把預設模型也一起放進去。 這次選擇的是 Ollama，預設模型設成 minimax-m2.5:cloud。 原本以為把 .env 補好、compose 啟動，接著就能開始用了。做了才知道事情沒有我想得順利，仍然還是需要手動進 container 執行指令。 因為這次在 docker compose 想放進預設模型，所以整個配置也跟著多補了一些。原本比較單純的 OpenClaw 部署，後來變成 openclaw + ollama 的配置，讓 OpenClaw 啟動後能直接接上模型。 不過模型名稱先放進去，事情也沒這麼順。 Ollama 要使用 cloud model 得先登入。第一次啟動後，要先進到 Ollama 容器裡跑

By Jo Assistant, Jo
[紀錄] 初試 OpenClaw

實作筆記

[紀錄] 初試 OpenClaw

夯了很久的 OpenClaw，近期開始出現了退安裝潮，我卻正要開始嘗試使用。 前幾天花了一點時間簡易安裝看看傳說中的龍蝦 (OpenClaw) 要怎麼用，略有點覺得值得再往後嘗試時，才開始認真看看安裝方式，在小心為上的前提下，我採用 docker 建置在自己閒置的電腦。 在 docker-compose.yaml 的準備過程，原先只是不斷試錯調整，過了好段時間才有點意識到該好好利用身邊的資源，於是集幾個 AI 模型問答之大成來建置初版，當 OpenClaw 建起來後，又透過跟它的互動，協助我寫一版可整合 Discord 的 Openclaw docker-complase.yaml 自用。(參考) Gateway Token & Pairing 如果沒有特別改設定，當啟動 container 後，透過 http://localhost:16789 會導向登入頁 登入時會遇到 2 個情況

By Jo
Data Platform 筆記#02：從可行到可承接

架構思考

Data Platform 筆記#02：從可行到可承接

在初版架構逐漸成形後，時間也差不多過了一年。 架構可以跑、資料可以流動，但我仍然不確定它能不能真正落地。這條路必須要團隊可以承接、可以擴展，數據才有機會真正發揮價值。 很慶幸的是，我的主管願意投資時間，讓這個方向能繼續推進。也正是在那段時間，我的思考開始出現轉變... 前一篇的重點，是讓流程從「能跑」走向「能持續」。 而接下來我開始思考：如果這件事要由團隊一起做下去，現在的做法夠不夠讓人接手？ 轉變的核心 回頭看那一年，大多數時間其實是在解問題。 但接下來，我該解的是另一個問題：怎麼讓別人不用再解一次同樣的問題？ 於是投入了約莫三個月、壓力值很高的一段時間，開始把原本依賴個人經驗與記憶的做法，收斂成可以被團隊理解與複製的形式。 這個收斂，後來具體落在幾個方向上： * 把 Data Center 的部署方式收斂成一致做法，降低環境轉換成本 * 把資料整理作業轉變為配置驅動，讓流程與部署有規則可循 * 整理 DDL 轉換規則與範本，讓團隊能共用同一套方法 * 把知識系統化交付出去 這些事情的唯一核心是 讓方法大於個人。 從個人經驗，到規則明確 第一個改變：

By Jo
Data Platform 筆記#01：初版技術架構成形

架構思考

Data Platform 筆記#01：初版技術架構成形

在上篇的 POC 之後，我們整理了一份內部報告，將問題拆成資料蒐集、基礎資料定義、資料量與查詢效能、資料治理、技術架構等幾個面向。 這份整理的目的是先建立邊界，讓我們從發散與模糊，逐步走向具體且聚焦。 在這個基礎上，我開始把關注重點轉向資料流： 如何讓資料自動、穩定、乾淨地進到分析效能較好的資料庫？ 同時，也剛好迎來一個契機：與技術能量較高的團隊合作發展數據中台。這讓 Data Center 的推進獲得更多資源與支援，讓我們能更系統化地思考架構問題。 思考階段 這個階段，我們主要思考幾個問題： * 不同來源的資料，能不能用相對一致的方法接進來？ * 資料會持續累積，是否有合適的儲存與管理方案？ * 資料進來後，分層應該怎麼定義？ * 查詢分析時，是否有更適合的查詢引擎？ 各資料源的特性不同，接收方式很難完全一致。但若每種來源都設計一套專屬流程，維運成本會快速上升。因此初步的想法是先用一種主要方式處理大多數的情境，讓資料流先跑起來，再逐步優化。 過去常見的分層方式，是將資料分成： * 可追溯的原始資料（Stage） * 清洗整理後的乾淨資料（Data） *

By Jo
Data Platform 筆記#00：在變得具體之前

架構思考

Data Platform 筆記#00：在變得具體之前

目標要做資料平台(Data Platform) 一開始我不是很能夠想像這件事該長成什麼樣子，既有的認知只有前期參與的團隊有實作過 HR 資料中心，顧問曾指導資料分層為 Stage、Data、Mart，除此之外，我沒有更多掌握，有很多疑問需要找到答案。 做到什麼程度算是Data Platform？ 我們期待它能解決什麼、幫助到誰？ 它是不是應該包含一套接收資料的方法、能儲存大量資料的資料庫、提供資料服務的能力？   那麼，它是一個平台嗎？該用什麼技術？有哪些其實現在不需要？又該怎麼做，才能保留未來需要的彈性？ 這些問題在當下其實都沒有辦法很快有肯定又具體的答案。好像每一個點都應該被考慮到，但同時又覺得過於理想。那段時間，我甚至開始嘗試透過與 AI 的對話，把模糊的想法拆解成可以被檢視的問題。它沒有辦法替我做決定，但確實加速我釐清問題。 只是，在理解問題的過程，即使把想法轉化輸出成一張張架構圖，進展卻不是太明顯，反而有一種無法落地的感覺，沒有讓事情真正往前走，我們仍然缺少可以被驗證的起點。 開始有切入點的時機，是我們在尋找能夠讓用戶自助調整所需報表的工具，剛好從前的工作曾小量接觸

By Jo
筆記 | 自架 Ghost 的 SMTP 設定

實作筆記

筆記 | 自架 Ghost 的 SMTP 設定

部落格荒廢了好一段時間，近期終於想用手機登入管理介面留下些草稿，突然發現無法登入，登入鈕下方出現了如下的一段訊息 EmailError: Failed to send email. Please check your site configuration and try again. 結論先行，原因是我安裝的 ghost 版本，在首次使用新裝置登入時需要 2FA (二階段驗證)，也就是說，除了帳號密碼登入之外，還會有一層驗證機制，而這層驗證機制需要輸入 6 碼驗證碼 (Ghost 站台發給登入者註冊信箱的 mail 會提供)。我當時建置 Ghost 時認為自己不會發送電子報，就忽略了 SMTP 的設定，導致 Ghost 站台不能正常發信，在配置好 SMTP 設定後，從新裝置就能正常登入了。 前一篇文章提到我的 Ghost 是架設在

By Jo
部落格遷移紀錄

實作筆記

部落格遷移紀錄

是的，又搬家了。 這次搬家像是一種重新開始，遷移的範圍稍微大些，大致上有三段變動： * 從功能豐富的 WordPress 到簡潔高效的 Ghost * 從 SugarHosts 搬遷到 Google Cloud Platform (GCP)，最後搬移到 zeabur Wordpress 的功能非常豐富，只是我使用到的部分極少，總想找個簡潔的服務使用，但忙碌的工作很快就澆熄了動力。一次在輸出小組群組中的討論，注意到 Ghost 這個部落格平台，試裝操作看看，體驗還不賴，想著我的文章數也很少 (心虛)，就搬吧！ 推進這個改變的契機，一部分也來自於 SugarHosts 自 2024 年底在網路社群中的討論，其中也包含了客服過久沒有回應的議題，SugarHosts 的價格真的很有吸引力，只是客服回應效率突然的落差，讓我開始擔心這是否對影響到部落格，開始思考搬家的可能，實際上身邊的朋友也愈來愈多人遇到類似情況，甚至站台無法再使用，措手不及使得只能使用較早期的備份來拯救文章。 我在年假期間利用 GCP 的試用額度來架設

By Jo
筆記 | Ubuntu 掛載磁碟

實作筆記

筆記 | Ubuntu 掛載磁碟

最近在 GCP 試玩 Compute Engine (VM)，建立時另外新增了一顆磁碟，實際運行了才發現，原來需要自行掛載，記錄執行的指令與過程。 以 Ubuntu 22.04 為例 (多數的 Linux 應該也可以使用) 確認新增的磁碟是否存在 lsblk 大多情況應該會看到新的磁碟還沒有掛載任何分區 格式化 (如果硬碟還沒有格式化) sudo mkfs.ext4 /dev/sdb 配置自動掛載 取得新磁碟的 UUID sudo blkid /dev/sdb 一般會顯示類似以下的結果 /dev/sdb: UUID="一串由-符號串接的英數字" BLOCK_SIZE="4096" TYPE="ext4&

By Jo
筆記 | PostgreSQL v12 CTEs 行為改變

實作筆記

筆記 | PostgreSQL v12 CTEs 行為改變

前段時間，工作環境將 PostgreSQL v10 升級到 v15，升級後發現報表的執行效率從 1 秒變成了 2 分多鐘，也剛好變因太多，排查了很多項後才開始面對 SQL 執行計畫，同一段 SQL v10 跟 v15 有很大的差別，許多人花了一番功夫調整，速度才回到水準，接著進一步從調整方向的線索，再爬網路文章，才發現原來在 PostgreSQL v12 有一項對我們來說蠻重要的改變：CTEs 行為改變。 過去經驗裡，SQL 使用 CTE (Common Table Expression) 能將一段查詢的結果暫存起來，在主查詢語句中使用，能有提升查詢效率的效果 例如： WITH temp AS ( SELECT col1, col2, col3 FROM

By Jo
筆記 | 在 Ubuntu 22.04 安裝 Kubernetes Cluster

實作筆記

筆記 | 在 Ubuntu 22.04 安裝 Kubernetes Cluster

許多網路文章中都有安裝 kubernetes cluster 的教學，也因為版本更迭，爬了很多的文章、裝了非常多次，整理以下的筆記，幫自己防忘記。 實作環境 * 主機 (VM) 3 台，一台 master、兩台 node * pve-master * pve-node1 * pve-node2 * 作業系統 Ubuntu 22.04 * Container Runtime 選擇 containerd.io 筆記的幾個大步驟，有些是所有節點都要做，有些則否，整理如底下的表格： Step pve-master pve-node1 pve-node2 安裝前置 V V V 安裝 Container Runtime V V V 安裝 kubeadm

By Jo
心得 | 溝通 - 與下屬講話時的 Checklist

學習成長

心得 | 溝通 - 與下屬講話時的 Checklist

筆記摘自蔡恩全老師在 Master Cheers 的系列課程，章節片段不長，大約 12 分鐘，但有許多讓人省思的地方，也包含了一部分對過去自己答案的肯定，雖然是談管理、對部屬溝通，但除了 coaching 的部分比較屬於帶人的層面，其他的提點也很適用各種溝通場景。 筆記裡已經包含課程大多數內容，我比較想就這個課程中所回憶起的經驗或曾經踩的雷做個回顧，也當成是一次覆盤。 首次擔任管理職是從無到有建立團隊，一一面試選擇團隊夥伴，我想我們應該都同意，不論哪一方，面試時的想像和期待，通常和實際是有些落差的。夥伴的個性不盡相同，對於「了解對方」的能力，我有很多努力的空間，我可以做的，是在每一次的 1 on 1 中，視對方的反應來調整，但仍然是有許多故事。 有一回，和一位剛加入團隊三個月的成員討論工作狀況，我很直接地說：「我發現你的工作進展與我期待的不同，我們過去也定期在檢視跟討論，我想知道是不是有遇到什麼問題，或者需要我協助的地方？」 眼前的大男生回應不到幾句就開始稀裡嘩啦地哭了，一時之間我也有些不知如何是好，遞給他一盒面紙，請他先收拾好情緒後我們再談，在等待的時間裡我是忐忑的，

By Jo
See all