如何設計簽署的XML檔案 (XML Signature)

如何設計簽署的XML檔案 (XML Signature)

from gelis 技術隨筆- 點部落 http://ift.tt/1JdaQwf

留言

張貼留言

這個網誌中的熱門文章

SA (System Analysis) 系統分析師 與 軟體架構師的差別？

圖片
SA (System Analysis) 與軟體架構師的差別？ 前言 這其實是先前在臉書回復其他社團的貼文，為避免當時的內容與想法被臉書淹沒，於是將其整理成文章，表示我沒有將臉書當成文章在寫。 雖然現在流行 AI 撰寫文章，但我可以證明本文章絕對不是 ChatGTP 撰寫的，內容與想法 + 圖片都是出自我的想法 與 工作相關經驗。 版篇文章以台灣軟體產業為基準，不適用於歐美國家。 SA 與 BA 角色 也有朋友提到 BA 這個角色，其實我當時所處年代 (約西元 2000 年左右)還不盛行 BA (Business Analysis) 這個角色，尤其在台灣。其實在灣大部分一人分飾多角，像我現在同時是架構師、顧問、Traniner、有時是 Developer，有時也協助制定或定義開發（流程 / 規範）等等。 我認為 BA 的角色若相較於 SA 更為狹隘點（就軟體開發來說 / 或者說目的不同），怎麼說呢？一般軟體開發還是重在最後產出『成品/Product』、但 BA 並不是，他更著重在商業、滿足的所謂的『業務成果』，這又讓我想起 POPIT 模型，有興趣可參考附件連結。 SA 系統分析師 vs. 軟體架構師 的差別？ 回歸到主題，究竟 SA 與 架構師 的差別是什麼？ 我覺得差別蠻大的，是職能與本質上的差別。 架構師的職能更廣、而 SA 通常較為狹隘（了解商業需求／有的 SA 要為使用者需求負責） 12年前我是某家 SI 公司的 SA & 2010~2014 擔任軟體架構師的感想。 我畫張簡圖，即上方的 Logo 圖，簡要說明這兩者職能上的差別，越往（左邊是更懂技術 / 右邊更趨近商業流程）：  (1). 我認為架構師更全能、甚至含括 SA 的範圍。  (2). 許多軟體公司的 SA 是不碰技術的，頂多繪製 ER-Model  (3). 甚至許多軟體公司 SA 不是技術出身 結論： 因為軟體架構師在分析系統架構時，同時得要考量商業需求，並在軟體架構中落實， 套用先前敏捷的軟體架構， 除了不做（過多 / 過度）的設計之外，還要讓系統保持高度彈性 、 要因應需求、也要因應客戶端的環境、考量 Cost 成本問題、又同時得要考量團隊的 Skill，不是一窩蜂的導入新技術，在專案中， 任何技術的使用都需要 成本 的 ，軟體...
閱讀完整內容

AI 時代的軟體架構設計的進化之路（二）

圖片
AI 時代的軟體架構設計的進化之路（二） 文章目錄 前言 AI 對軟體架構設計的影響 如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則 把 Scenario 轉換為 prompt (精華篇) 結語 前言 在前一篇文章 【 AI 時代的軟體架構設計的進化之路（一） 】中，我們探討了 AI 對軟體架構設計的影響，當時，我解釋了軟體在時做過程中，系統分析與設計的過程是幫助我們工程師思考的一個重要過程，因為這個過程才能夠幫助我們客戶的需求合理或不合理之處、理解最佳的系統設計的 boundary 那個界線在哪裡？如何將目前的『需求』實作到最佳恰到好處？ AI 對軟體架構設計的影響 現階段的 AI 或 GAI 工具嚴格來說，都還僅限於副駕駛 Copilot 的角色，但是軟體在設計的過程中得執行許多決策，且軟體開發的過程中並不是只有撰寫程式，更多的是『溝通』、『協作』、『解決問題』，單純的撰寫程式可能只占整體軟體開發生命週期所有大小事情中不到 20% 的工作量，當然也還包刮了測試、部署、維運等工作。然而，大部分的工作均需要開發人員進行『思考』與規劃，但是規劃這件事情需要考量的不單就只是如何實作，可能也包括了『團隊成員Skills』、『客戶端執行環境』、『成本的限制與考量』、甚至是『如何與其他進行跨系統整合』、等...，而這些都是還是需要人來進行決策，與如何進行下一步的。 如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則 大約在 2025-08-15 左右，我開了一堂【AI 時代下的系統分析與設計】線上直播課程，課程大致上其實先前我的決戰 OOAD 系列課程 與 最新的 API Framework 框架開發V2 課程的延伸，雖然我會在課程中使用 AI 工具 GitHub Copiplot，但重點仍就放在軟體建構過程中的各個環節點，比如從需求訪談到需求的擷取、也就是系統分析/設計）的過程，只不過，我讓 AI 來介入系統分析與設計的過程的環節點，而不只是與 AI 來 Pair-Programming 而已，我這樣做的目的是希望幫助軟體開發者不要停止思考，我記得，最近有看見 Continuous Delivery 一書的作者 David Farley 似乎也提到說 Vibe Coding 是本年...
閱讀完整內容

軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程

圖片
軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程 圖片來源：https://coolshell.cn/articles/18024.html 前言 本篇文章是上一篇『 軟體架構設計：API 設計準則（一）、API 的設計開發與挑戰 』的接續。前一篇文章中，我們探討了 API 的開發與挑戰，這還沒結束，這篇我們來聊聊什麼是 API Design-First 優先設計？這與傳統的軟體開發有些不同，這與我們已經熟悉的 RESTful API 的以 Resource-Based 為設計的設計概念也有些不同，下面，我們就來探討吧！ 為什麼需要 API 設計原則？ 在說明為什麼需要 API 設計原則時，我得先回到一開始的主題 API Design-First 優先設計，為什麼需要 API Design-First 呢？因為 API 設計有別於傳統軟體開發，差異等等下方解釋，在設計 API 時講求有效的產出，首先是別企業體的或企業組織為維持市場競爭力與獲利所擁有的能力與模型稱為：【商業能力】，而在開發 API 時將將用戶與開發者視為第一考量，講求的是盡可能讓用戶在不牽涉過多技術細節便可調用這個 API。 在早期，許多企業未遵循 API Design-First 流程開發方法，而使用傳統方式設計 API，會後得到的結果可能就是『多次的砍掉重練及更冗長的開發週期』或最終 API 不為其他客戶所使用，甚至退出市場。 從 RESTful 到 API Design-First 優先設計   圖（一）、傳統 Resource-Based 的 RESTful API 原本我們熟知的 RESTful API 是將數位世界中的圖像、物件、後端的人員，都可稱為資源，這又稱作 Resource-Based API 的設計，因為 RESTful 將網路上的一切都視為資源。 但是在API Design-First 的概念裡面： 1. 資源 ≠ 資料模型 好的 API 設計提供的是該企業的數位能力，而不是後端的資料結構，因為 API 涉及的是跨企業之間的資料交換，這裡的 API 設計並不是傳統 SPA 應用程式裡面的 Front-end Framework 去呼叫的那個後端 API，這是兩個完全不同的開發情境，這必須先說明清楚。 另...
閱讀完整內容