專案涵蓋 Quarkus API、GCP Datastore、Pub/Sub、Apache Camel、測試、Kubernetes 佈署 相關技術，據此規劃 Lab 和 Skill Approve。 目標 : 讓學員熟悉 Quarkus API、GCP Datastore、Pub/Sub、Apache Camel、測試、Kubernetes 部署 POC 課程規劃（0 到 1） 本 POC 旨在讓越南 IT 新進人員快速上手 GCP 及 Quarkus，並能夠開發、測試、部署一個完整的雲端應用。考量到部分學員可能基礎較弱，課程將從 零開始（0 到 1），循序漸進，確保每位學員都能夠理解與應用。 目標 掌握 Quarkus 基礎：學習如何開發 REST API，理解 Java 基礎概念。

1.尋找適合的 Open Source 專案 2. Fork 到自己的 Repository 點選 GitHub/GitLab 的 Fork 按鈕，把原始倉庫 (upstream) 複製到自己的帳號，變成自己的 repo (origin)。 3. Clone 專案到本地端 複製自己 fork 的 repo 到本地環境： git clone https://github.com/your-username/project-name.git cd project-name 設定 upstream（指向原始專案）：origin 指向你的 fork。

目標 熟悉雲端環境：使用 Google Cloud，熟悉 Cloud Run、Cloud SQL、Cloud Storage、Pub/Sub 等元件。 強化後端開發能力：使用 Java Spring Boot，學習 RESTful API 設計與實作。 掌握檔案處理技術：包括 照片上傳、壓縮、格式驗證，學習如何運用雲端服務處理文件。 理解非同步處理概念：使用 Pub/Sub 進行非同步任務處理，如圖片壓縮等。 功能設計 1. 基本 CRUD 功能 員工管理新增：輸入員工的基本資料，如 員工編號、身分證號、電子郵件 等。 查詢：根據 員工名稱、編號或身分證號 來查找員工資料。

一般與高峰值比較表https://docs.google.com/spreadsheets/d/1k62M_ajCoP3yRi5F66QjnYBpN3i01fXjNLvMBfPtgx8/edit?usp=sharing Develop : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVF3TVRWbE5XWTVOeTFpTmpCakxUUm1abU10T0RkbE5TMWtOR0ZoWm1Kak0yWmxZbVVRQVE9PRAOGiRDN0U2M0VBMS1GQTRDLTQzMjEtQkJGRC0xRTBGQTQ4OEU4QzY MVP : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVF4WkRreVpHTmpNaTAwWmpBNExUUTRZekF0T1RjeFl5MHlPV1k0WmpneU1qWmpZbVVRQVE9PRAUGiQxMUI5OTk2RC00NDcyLTREODAtQkVERi03RjAyRDc4MTlFNTQ Basic : https://cloud.google.com/products/calculator?hl=zh-TW&dl=CjhDaVEzTURreE56ZzVOaTA1WlRsaExUUmtNamd0T0RjNFppMHdNbU16TnpRd1pXTXlNVFFRQVE9PRASGiQwMjVCOEJBNy0wNkY3LTRDRTAtOTg3OS01QzhGMzIxRTgxNkY Release market(再補上流量更改後，金額會暴增) :

在雲端運算技術快速演進的時代，企業面臨著如何有效運用雲端資源的重要課題。Google Cloud Platform (GCP) 作為全球主要的雲端服務供應商之一，提供了多樣化的無伺服器運算服務（Serverless Computing Services）選項。其中，Cloud Run 和 App Engine 是兩個被廣泛採用的服務，各自具有不同的特性和應用場景。 而在微服務架構（Microservices Architecture）盛行的現今，系統往往需要部署數十個甚至上百個微服務，而每個服務的啟動時間（Cold Start Time）都會直接影響整體系統的反應速度。因此服務啟動效能的優劣會影響使用者體驗（UX）及系統可用性（Availability）。 因此，針對此部分我們花時間去研究 Cloud Run 與 App Engine 喚醒時間差異。此篇文章會具體描述我們如何做這個POC實驗以及會有一個初步的結論。 實驗背景與服務簡介 當開發Web應用時，選擇 Cloud Run 或 App Engine 作為服務部署平台時，冷啟動時間是評估效能的一個關鍵指標。本實驗旨在比較 Cloud Run 與 App Engine 在冷啟動時間上的差異，提供選擇依據。 冷啟動時間指的是當新的容器實例被創建並首次處理請求所需的時間，包括以下幾個階段：

For 高老師Git課程簡易項目紀錄，此篇比較適合對Git有概念且會操作的人。另外高見龍講課真的專業級，可以講得很輕鬆詼諧，然後切入中心觀念。針對講課項目內容去展開細項。 init / config 跳過git config --list 經驗說在某些專案中，當有多層發包需求時，承包商可能會希望隱藏實際的開發情況，讓業主無法看出這些多層發包的細節。使用 git config --local 可以針對特定專案進行配置，這樣即使專案中有不同的開發者進行 commit例如，你可以為某個專案設置統一的提交者名稱和郵件地址：git config --local user.name "統一承包商" git config --local user.email "contractor@example.com" git add . (all file attatch) 很危險又不負責任的指令，有可能把沒做完的檔案Attach 什麼時候做Commit ? 完成feature，或是做一個段落....想commit就commit..? 未做完會下wip(Work In Progress)註解。 commit message 是什麼? . here 當下資料夾路徑所有檔案做Attach

For近期須分享TDD，想到之前上BDD課程筆記，課程只教BDD概念，雖然有實作，但C#實作上沒使用到SpecFlow去編輯DSL（Domain-Specific Language，特定領域語言）語法去對應產出程式碼，所以自行嘗試了一下。網路蠻多用法文章，但都是最簡單的Context，所以剛好課程有提供稍微接近實作一點的例子來嘗試看看。過程中有遇到一些問題，所以稍微紀錄一下。 BDD簡易概念 簡易概念 BDD 則是將開發過程聚焦在軟體的行為和需求上。強調用自然語言(接近人看得懂的語言)描述軟體應該具有的行為，從而讓開發人員、測試人員和非技術人員（如產品經理、業務分析師等）都能清楚地理解需求。 與TDD差異 舉個例子，如果一個計算機程式要做加法功能 TDD撰寫一個測試Case，檢查模擬加法功能（例如，測試 2 + 3 = 5）。

簡述 近期在跟高雄軟體King討論Log紀錄的機制方式，得知了AOP的機制，於是認真稍微研究了AOP的使用與實現方式。雖然King提供的AspCore真的快速實現了AOP，不過還是想花點時間去認真看若不使用Framework該如何實現這件事情~ AOP使用橫切入方法在原Class中插入新方法的且不會破壞原Class Method的一種技巧。 將橫切關注點（Cross-cutting concerns）與業務主體進行進一步分離，以提高程式碼的模組化程度！ 我們直接來帶例子來瞭解比較快~ 如果今天你拿到的他人已寫好Service程式碼如下

一、關於Module 在闡述Module前，讓我們先來比對非物件化設計與物件化設計的差異性。看到下圖左，在非物件化的傳統設計，資料與方法操作上是整個拆開設計，在資料流複雜外我們可以看相依性高，偶合的狀況也較高。 接著討論物件化設計部分，先不論封裝等物件操作技巧，單純根據資料與方法關係設計出物件(物件特性:資料(Data) 物件行為:方法(Function))，我們可以看到原本互相依賴的Fun關係可各自獨立使用，在資料流上也較為單純。 物件化後，雖然在資料操作面上簡化許多，但隨著專案功能性逐漸增加，物件與功能處理流程上會趨近越複雜，如下圖為一個簡易的系統，此系統根據外部Sensor系統獲取、過濾與計算資料，在沒模組化的設計前提，可以看到Control與Data Flow呈現一個較零散的關係狀態 此時我們根據Sensor功能額外設計一個Sensor模組如下，此時我們就可以針對Sensor相對應的資料模組將之封裝在模組內，此模組對外則就單純開放運算(calculation)與過濾(filtering)的功能。 模組化後可以明顯看出控制與資料流的彼此相依性值，因此降低了修改與擴充狀況的互相影響性值。

讀取速度 選抽一個資料庫 下BACKUP DATABASE指令，備分資料庫不做寫入，只做讀取，可得到讀取速度值。 BACKUP DATABASE [FUXIN_CPL] TO DISK ='NULL' WITH COPY_ONLY 下圖可看到結果每秒讀取速度為180MB/sec 寫入速度 BACKUP DATABASE [FUXIN_CPL] TO DISK ='C:\TEST.BAK' WITH COPY_ONLY 此時會得到讀寫時間為每秒153MB

在前面的章節中，我們詳細探討了Keycloak的基礎知識，這一Part稍微講一下如何實際運用Keycloak，結合角色權限設置，來實作不同User具有不同角色權限來使用API的功能。 至Keycloak服務設置Client、User與Role設置 (版本17.0.1 ) 工具測試 撰寫AP Code 另外有點需要事先提醒注意一下，文章提供的Url格式! 例如文章提到 Url設定 : http://{your-keycloak-server}/realms/{your-realm-name}/protocol/openid-connect/token

Java實作，lib keycloak spring starter 被新版的spring boot棄用了，整合至spring oauth2。參考點我，但依舊有在維護。 測試時，平台顯示authorization_request_not_found，找半天問題，最後清Cookie才解決。

五、Keycloak串接Google Auth設置與Demo Code 在前面的章節中，我們詳細探討了Keycloak的基礎知識，這一Part稍微講一下如何實際運用Keycloak，結合OAuth 2.0協議，來實現Google認證登入，達成單點登入(SSO)的功能。我們的Demo會如下圖Flow，實作一個簡易的Web API，當使用Web API時，第一時間會打到Keycloak，再由Keycloak導到Google認證頁面，認證過後瀏覽器才會收到正確的API資料。基本上會有三個步驟需要設置 至Google Cloud API設置憑證 至Keycloak服務設置Client以及Identify Providers (版本17.0.1 ) 撰寫AP Code Mermaid Code sequenceDiagram participant User as [瀏覽器]

四、Keycloak介紹 我們剛才談到實現SSO（單一登入）的功能，那麼現在問題來了：有沒有一個工具或平台能讓我們更方便地實現這一切呢？答案是有的，那就是Keycloak。Keycloak是一個集成了多種身份驗證和授權機制（包括OIDC和SAML）的開源身份和訪問管理解決方案。 Keycloak的特點如下 多協議支持: Keycloak支持OIDC和SAML，所以你不必為了不同的應用而選擇不同的解決方案。 易於管理: Keycloak有一個使用者友善的管理界面，你可以輕鬆設定用戶、角色和權限。 靈活性: 它是開源的，意味著你可以根據自己的需要對它進行定制。 詳細提供以下功能

三、SSO 簡述 OIDC和SAML討論完後，我們來聊聊單一登入（SSO）。SSO是一個身份驗證方案，它讓使用者能透過一次登入就可訪問多個應用程式和網站。簡而言之： 透過單一的登入窗口，進行單一的身分驗證，就可以讓許多的服務共同來使用這個驗證結果 OIDC和SAML都可以實現這樣的SSO功能。舉例來說，假設你在工作中要使用三個不同的平台： 郵件系統（Email System） 公司內部網站（Intranet） 報表和數據分析平台（Analytics Platform）

在這部分，我們將探討OIDC和SAML。正如前一章節所提，身分驗證和授權是整個安全流程中非常關鍵的環節。一般來說，會有專門的解決方案來處理這些問題。OIDC和SAML都是為這個目的而設計的標準協議，它們提供一個集中式的方法來驗證使用者身份，並界定他們可以訪問哪些資源或執行哪些操作。 1. Open ID Connect (OIDC)： OIDC是一個建立在OAuth 2.0之上的身分認證層。OAuth 2.0本身是一個專注於授權的框架，而OIDC則在這個基礎上增加了身分驗證功能。這樣，應用程式不僅能知道使用者有哪些權限，還能瞭解使用者是誰，並獲取他們的基本資訊，比如名稱和電子郵件地址。 a. OAuth 2.0 OAuth 2.0 是一個授權框架，允許第三方應用程式在使用者同意的情況下存取使用者在某個服務上的資訊，而不需要分享使用者的密碼。通常在OAuth 2.0，會有幾個角色，我們這邊舉一個簡單情境，你希望使用「快速日記」App，而這個App提供使用Google帳戶登入的功能來使用Google雲端硬碟服務。 Resource Owner(資源擁有者) : 通常就是User(你)， 能授予應用程式取得受保護資料的人，通常就是終端使用者（end-user）。例如你希望使用「快速日記」App，而這個App提供使用Google帳戶登入的功能。在OAuth的流程中，當App請求許可存取你的資料時，你會給予（或拒絕）這個請求。 Resource Server(Resource Server) : 存放使用者受保護資料的伺服器，以這個例子來說就是Google雲端硬碟，當「快速日記」App希望保存或讀取日記時，它會向此伺服器提出請求。

一、關於身份驗證與授權 身份驗證和授權是系統安全性非常重要的環節。身份驗證用於識別使用者是誰，而授權則賦予使用者某些特定權限。更具體來說，這整個過程可以分為四個部分： 身分識別 (Identification)：這是一個讓系統知道你是誰的過程。例如，當你使用用戶名或電子郵件地址登入系統時，就是進行身分識別。 身分驗證 (Authentication)：這個過程讓系統確認你確實是你聲稱的那個人。通常是通過輸入密碼、使用FaceID或OTP來完成的。 授權 (Authorization)：這涉及到角色分配。根據你的角色，系統會賦予你不同的權限。例如，一個“編輯者”角色可能有編輯內容的權限，而一個“閱讀者”角色則只能閱讀。 存取控制 (Access Control)：這涉及到具體的操作權限。比如，在一個IT管理系統中，一個普通使用者可能可以重啟伺服器和查看系統日誌，但不能部署新的程式碼。然而，一個開發者則可能有這樣的權限。 在你登入系統，輸入帳號密碼為身分識別與身分驗證，系統驗證完後，會根據身分授予角色。至於此角色權限則可以在後台系統上設置。至於這部分的詳細實做概念牽扯還是蠻多的...會再找時間針對這部分做一個細部講解。

此文章針對SSR與CSR作個解釋與比較 名詞解釋 SSR,CSR SSR(Server-Side Rendering) : 由Server端的 CPU 收到請求後，解析完整的 HTML 返回到使用者接收端，然後呈現網頁。 CSR(Client-Side Rendering) : 由Server端回傳資料，再由前端利用 Javascript 產生 HTML 。 在執行期間「動態」去跟後端Server拿資料，再動態產生看到的那些元素。 一般Web前端評估Performance TTFB(Time to First Byte) : 關係到網路速度、Server 處理時間，具體計算是從使用者發出 Request 到接收到第一個 Byte 的時間。 FP(First Paint) : 瀏覽器將像素渲染到螢幕上的開始時間，通常使用者會在此時看到白屏。

近期在接觸Keycloak，這是一個實現SSO（單一登入）的開源方案。本篇會簡單介紹Keycloak的基本概念、設定，並提供一個範例實作。 在深入了解Keycloak之前，我們需要對身份驗證、授權以及SSO有基本的了解。<font color="#dd0000">如果你對這些部分已經非常熟悉，可以直接跳到第四章開始閱讀。</font> 一、身份驗證與授權與Keycloak 二、OIDC(Open ID Connect) vs SAML((Security Assertion Markup Language) 三、SSO簡述 四、Keycloak介紹與簡易使用 五、串接Google Auth設置測試實作 六、多角色權限測試實作

時間 : 6/12至今 完善新人GCP Training專案 S : 公司新進員工對GCP常常缺乏基本知識，新進職員需做一個平台專案至GCP上。 T : 完成新人GCP培訓專案。 A : 過程中與同期新人互相討論，除了完成功能外，也完善整個目標。從資料表服務權限的細維度到GCP的CICD都有完善的過一遍與紀錄。 R : 後續新人進來能有完整的明確紀錄參考，減少新人上手的時間和縮短學習曲線。 資料: Code(已同步到行內), PPT(已同步到行內), 筆記參考(已同步到行內)