在 Spring Boot 應用程式中，Log 通常會先輸出到 Console 或檔案，方便開發與單機排查問題。不過當服務數量變多、部署環境變複雜後，單靠各主機上的 Log 檔案會讓查詢與追蹤變得不方便。這時可以透過 Logstash 接收 Spring Boot 輸出的結構化 Log，再寫入 Elasticsearch，讓後續查詢、分析與視覺化更加集中。
本文會記錄如何在 Linux 環境安裝 Logstash，設定 Logstash 將 TCP 收到的 JSON Log 寫入 Elasticsearch，最後再於 Spring Boot 的 logback 設定中加入 Logstash Appender，讓應用程式 Log 可以送進 Elasticsearch。
Jaeger 是一套開源的分散式追蹤系統，常用於觀察微服務架構中請求在不同服務之間的流向、耗時與錯誤位置。透過 Jaeger，可以把分散在多個服務中的 trace 資料集中起來，協助開發者分析效能瓶頸與服務之間的呼叫關係。
本文會示範如何在 Ubuntu 環境中安裝 Jaeger Tracing，並透過 systemd 將 Jaeger 設定成系統服務。這裡使用 Jaeger 的 OpenTelemetry Native Backend 設定，讓服務可以接收 OTLP gRPC 與 HTTP 格式的 trace 資料，並透過 Jaeger Query UI 查詢追蹤結果。
相較於只依賴應用程式日誌，Jaeger 可以用更直觀的方式呈現跨服務請求的完整脈絡：
這篇文章記錄如何在 Ubuntu 26.04 環境中安裝 Elasticsearch 與 Kibana，並完成基本的服務啟動、記憶體限制、設定檔調整，以及後續登入 Kibana 所需的密碼與 enrollment token 取得流程。
本文使用 Elastic 官方 APT 儲存庫安裝套件，版本來源為 packages/9.x/apt。安裝完成後，Elasticsearch 會啟用內建安全功能，因此後續需要透過重設密碼與建立 enrollment token 來完成 Kibana 的連線設定。
Chrome Extension 最迷人的地方，是它可以在不改動網站原始碼的情況下，替既有網頁補上一層新的操作體驗。這篇文章會以 coolpc-plus 這個專案為範例，拆解一個 Chrome Extension 如何在原價屋估價頁注入側邊欄、讀取頁面零件清單、呼叫 AI Provider，最後把推薦零件反映回原本的頁面。
這個專案不需要打包流程，也沒有複雜的前端框架。整體使用 Chrome Extension Manifest V3、原生 JavaScript、HTML 與 CSS 完成，因此很適合拿來理解 Chrome 插件的基本架構。
Docker 是容器化技術的核心工具，掌握其常用指令對於日常開發和運維工作至關重要。本指南將介紹最實用的 Docker 指令，並提供詳細的使用說明和範例。
平常在測試新的開發工具、VS Code 版本、JDK 或終端機設定時，最麻煩的地方通常不是安裝本身，而是安裝後會不會改到主機環境。像是 PATH、右鍵選單、登錄檔、使用者設定與工具版本，只要多試幾次，就可能讓原本穩定的開發機變得難以追蹤。
而這篇文章的起因，則是近期各種套件竊取資訊、惡意更新與供應鏈攻擊事件越來越頻繁。當我們只是想快速驗證某個工具、套件或 extension 是否可用時，其實不一定適合直接在主要開發機上執行。即使來源看起來可信，也可能因為相依套件、安裝腳本或更新流程帶來額外風險。
Windows Sandbox 很適合用來處理這類需求。它可以建立一個一次性的 Windows 環境，關閉後所有變更都會被丟棄；只要把啟動設定與安裝腳本整理好，每次都能快速還原出乾淨且一致的 VS Code 開發驗證環境。
這篇文章會以 C:\Sandbox 底下的設定為例，說明如何透過 Windows Sandbox 自動掛載資料夾、套用基本系統設定，並離線安裝 VS Code、PowerShell 7、Windows Terminal、7-Zip 與 Zulu JDK，讓 Sandbox 啟動後就能直接進行開發驗證。完整範例可參考 java-sandbox 專案。
最近把一個放在腦中一陣子的小想法做出來了：幫自己的 blog 做一個可以聊天的 agent。
這個念頭其實是從很日常的困擾開始的。文章寫久了之後，自己有時候也會忘記以前到底寫過哪些東西。要找內容時，通常就是翻分類、看標籤、搜關鍵字；這些方式當然都能用，但總覺得少了一點「直接問它」的感覺。既然現在 AI 工具都已經這麼容易接了，那乾脆試試看，能不能讓自己的 blog 也變成一個可以對話的入口。
所以這次就用 LangChain4j 快速做了一個 Blog Agent。沒有一開始就想把它做成什麼很完整的產品，比較像是先把腦中的畫面做出來：後端有一個 server side 可以處理 agent 的互動，服務直接丟到 Cloud Run 上跑，然後再寫一個給 Hexo 用的聊天室窗插件，把它接回原本的 blog 頁面。
做的時候其實滿有那種「先讓它跑起來再說」的感覺。LangChain4j 這邊先把後端流程接起來，Cloud Run 負責讓服務可以被呼叫，Hexo 插件則處理畫面上的聊天入口。每一塊都不算特別巨大，但全部接在一起之後，看到自己的部落格右下角真的出現一個可以互動的聊天室，感覺還是滿微妙的。原本只是靜靜放文章的地方，突然多了一個可以被詢問的介面。
這一輪 Pixel Battle 的開發，主要集中在任務引導與前期體驗的整理。相較於前幾次紀錄裡還在搭建系統骨架，現在遊戲已經做出兩個章節的任務流程，也加入了對話系統。整體來看，玩家進入遊戲後應該會比以前更容易理解自己正在做什麼，也比較能感受到遊戲希望帶出的體驗方向。
最近 Pixel Battle 的基礎系統已經完成到一個可以繼續往內容層推進的程度。地圖探索、角色成長、戰鬥切換、怪物素材、技能與 build 的骨架都逐步搭起來之後，開發上遇到的問題也開始改變：以前比較常卡在「系統要怎麼做」，現在則更常卡在「玩家進來之後，到底要經歷什麼」。
所以這一輪我把重點放在世界觀設定，以及遊戲前 30 分鐘的體驗內容。也就是先讓遊戲從一個功能逐漸堆起來的原型，慢慢變成一個有背景、有起點、有任務節奏，也能讓玩家理解自己正在扮演什麼角色的作品。
