2026年9月11日 星期五
Spring Boot:建置與執行
2026年8月24日 星期一
Python修仙之路:VS Code + GitHub Copilot──從AI輔助學習到專案開發,全方位提升你的「程式閱讀力」
2026年7月28日 星期二
Claude Code Vibe Coding 開發手冊 第 2 版
2026年7月16日 星期四
LangChain 奇幻旅程:OpenAI x Gemini x 多模態應用開發指南
2026年7月12日 星期日
Java程式設計師應該知道的97件事:來自專家的集體智慧
2026年7月6日 星期一
Claude Code Vibe Coding 開發手冊
2026年1月28日 星期三
第一次學Excel VBA就上手:從菜鳥成長為高手的技巧與鐵則
2025年10月10日 星期五
AI應用程式開發 第二版|活用ChatGPT與LLM技術開發實作
2025年9月4日 星期四
Next.js實戰
2025年7月26日 星期六
文科生也能輕鬆實現!自建自用大語言模型(LLM):無痛操作Ollama本機端模型管理器
2025年6月22日 星期日
Metadata後設資料:精準搜尋、一找就中,數據就是資產!教你活用「描述資料的資料」,加強資訊的連結和透通
2025年6月13日 星期五
你的第一本Linux入門書:使用WSL建立Linux軟體開發與部署環境,一次學會Docker、版本控制、建立AI預訓練模型
2025年1月27日 星期一
React 思維進化:一次打破常見的觀念誤解,躍升專業前端開發者
在估評、挑選網頁應用程式的技術範疇時,無庸置疑的容器化和前後端分離兩項技術已經是軟體開發業界默認的 De facto standard ,而前後端程式分離的概念與實踐更是一舉改變軟體工程師的職務劃分。以 JavaScript 為核心語言的網頁工程師,逐步變成掌握網站與行動應用開發話語權的前端工程師。隨著 Node.js 以其高效能成為網頁後端技術新竉兒,各種超越 JQuery 這個前端 JavaScript 函式庫的挑戰者們,也因為其青出於藍而大放異彩。其中 React 便是獨領風騷的一方之霸。
對於一個從事後端開發的工程師來說,學習 React 技術,目標純粹只是想減少自己對前端技術的知溝,方便未來能與前端工程師同事更容易討論、合作有前後端分離的網站專案。不過事與願違,在完全沒基礎的情況下,嘗試去搞清楚所謂的前端技術是怎麼一回事,很容易用自己瞭解的技術去推論,而有所侷限,反而看不清真相。像我一開始也鬧了個笑話,把 React 誤以為是 Java 語言裡的 Reactive 技術,還因此去研究了 Spring WebFlux。或是後來分不清 React 和 Node.js 的角色與關係,把 React 誤當成是某種 Node.js 上的框架。後面這點倒是不能笑我,畢竟 React 的開發環境太依賴 Node.js 了,幾乎所有的資料都是指導 React 開發者先安裝 Node.js。
正在苦惱如何事半功倍地學習必要的前端基礎時,React思維進化一書如天降甘霖般紓解我的煩憂。全書的目標便是替讀者們建立最正確、基礎的 React 技術觀念。也順道解答了為何 React 這樣的前端技術能將 JQuery 取而代之,而且形同水火,兩者不能並存。實際上就是 React 為了要減輕操作瀏覽器 DOM 的負擔,導入了 Virutal DOM 的設計,壓縮程式運行中所有的元件異動,只在最後階段才同步反映到瀏覽器的 DOM 上。JSX 是方便撰寫 React element 的語法蜜糖,而 React element 卻要經過 Babel 這種語法轉譯器的幫助,才能變成真正可運作的 JavaScript 程式碼。這一切的一切都有太多前情提要的背景知識,也難怪 React 不是非常好上手的程式語言。
不過 React 不好學習有另一個關鍵的原因,如果你在網路上查找 React element 的範例程式碼,肯定會找到兩種風格截然不同的東西,class component 和後來的 function component 。 書裡提出許多論證,讓讀者知道 function component 改進、消除了過去 class component 設計上的缺失。這樣的技術改版是不得不然,但這肯定是個容易讓初學者踩雷的誤區,甚至可能白費時間學到過時的 class component 開發技術。單向資料流的 prop 以及 state ,是確保 Virutal DOM 運作能正確無誤的機制,這也連帶著影響了程式碼的開發範型。從鳥瞰的角度來評論,可以說許多 React 特殊的程式碼設計風格與規範,以及搭配運作的 hooks 函式庫,都是為了達成更有效率的 DOM 更新,React 原始設計團隊,將此負擔轉嫁到工程師上,而不是開發出能簡化程式碼的一體適用執行環境。
不論是線上的 React 前端工程師,或是像我這種想對 React 多點瞭解的後端工程師。React思維進化都是值得成為第一本或是唯一一本的 React 技術指南。在擁有書中講解、介紹的背景知識後,讀者們才能更有自信,具備足夠的底氣去學習更進階的,如 Next.js 等 React 框架。而在全書的薰陶之後,即便看到前端工程師同事丟來的程式碼,相信也能略懂略懂的端詊。
2024年11月6日 星期三
科技巨頭的演算法大揭祕:資料科學家必讀的資料科學與機器學習實戰筆記
2024年7月27日 星期六
乾脆一次搞清楚:最完整詳細網路協定全書
2024年5月12日 星期日
敏捷與Scrum軟體開發速成
對於軟體專案管理方法,始終沒這麼引起我的興趣。畢竟第一線研發工程師的日常,忙著找解法和實作程式碼才是工作重心,至於專案範圍、時程主要還是讓專案經理煩心。然而最近怡好參與一個採用Scrum管理方法的新專案,一開始難免一頭霧水進退失據,想來只好反求諸己,拿這本敏捷與Scrum軟體開發速成來補補知識量,以便更快調整好步調完成任務。
愛書人總會被書所關照,隨意挑選的一本Scrum著作,出乎意料地是言簡意賅的精典作品。有別於瀑布流程將軟體開發劃分成需求收集、設計、編寫程式和測試,採用一切都得事前設計的思維(BDUF-Big Design Up Front)。敏捷開發則是主張漸進的累積,以一點點的需求收集、一點點的設計、一點點的編寫程式和交付一點點的價值貫穿整個專案。敏捷價值觀如下:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計畫
不過理想很豐滿,現實很骨感,這種顛覆傳統的專案管理手法,前提必定要出資者理解與採用,不然若是瀑布思維的客戶遇到敏捷思維的開發團隊,雙方對做完了的定義完全不同,肯定會導致衝突與齟齬。
在Scrum團隊成員分成三類角色,代表客戶提出需求與排定優先順序的產品負責人,主導Scrum流程與會議的Scrum教練,以及實際從事開發任務的團體成員。三個角色各司其職卻又要充分的協同作業以獲得團隊共識。由於敏捷開發與瀑布法的差異甚多,如果團隊成員沒被明確告知各個角色之間的責任,將會出現不可預測的管理風險。最明顯的例子就是在瀑布法位於最末端的測試,在改敏捷開發時必須融入在每個小週期內完成,甚至是連系統開發文件也被包含在一點點的設計工作裡。也因此採用敏捷開發的團隊多半也樂於懷抱測試驅動開發的程式撰寫流程。
敏捷與Scrum軟體開發速成是本值得一看的佳作,特別是想瞭解Scrum管理的獨特之處。然而這些理論與觀念,如何真正促成專案的成功,最終的變數還是執行的Scrum團隊成員。這也是Scrum管理沒有明確聲明的前提,團隊成員必須擁有相當程度的實務經驗與技術能力,因為產品負責人只負責提出客戶需求,要怎麼如質如實地打造出堅若磐石的軟體,反而是由團隊成員主動反饋、規劃和實作。軟體開發的道路上,不論是管理手法或是技術架構,本來就沒有可以一勞永逸地適應各種場合的解決方案。如果以為敏捷開發是可以確保專案開發神功護體的銀色子彈,那可誤會大了。
2023年12月22日 星期五
和艦長一起 30 天玩轉 GitLab【第二版】(iT邦幫忙鐵人賽系列書)
自先前看過和艦長一起30天玩轉GitLab後沒多久,這本書居然也出了第二版。但當時手上忙著研究與開發其它專案,就把翻閱第二版的事先擱下。過了大半年,近來要開始評估Jenkins和GitLab CI兩者的差異與優劣,恰好回過頭來看這本2022年翻新的第二版,感覺學到的知識又更加深刻許多。
說真的,把GitLab和Jenkins拉在一起討論,實在是小看了GitLab。有別於Jenkins是專注在CI/CD領域,如書中所述,GitLab從原本的版本控制軟體起家,在不斷發展擴充功能下,已定位自己是DevOps管理平台,參與涵蓋軟體開發過程中的各個階段。它提出了DevOps Lifecycle,定義了下面各Stage並提供相關的功能讓PM/開發人員協同作業。
Plan: 提案階段。有Issue Tracker、Issue Board和Issue Kanban等專案管理工具。
Create: 開發階段。有To-Do List和Issue List,還有Merge Request的機制,可以限制合併分支時,必須有專人核可。
Verify: 持續整合階段。藉由GitLab CI腳本實踐自動化測試/整合測試。
Package: 套件管理階段。內建的Artifact management機制,達成程式產出物管理。
Secure: 資安掃描階段。整合資安掃描軟體,進行SAST(靜態程式安全測試)、重要機敏資訊清查、程式碼品質掃描。
Release: 持續交付階段。一樣透過GitLab CI來完成自動佈署作業。
Configure: 運作環境管理階段。
Monitor: 監控階段。
Govern: 治理階段。
Manage: 管理階段。提供專案進度、工時控管等基礎的數據分析功能、圖表。
第二版的重點在於用更多的篇幅來介紹如何按步就班地利用GitLab CI撰寫出Pipeline,完成自動化編譯到佈署的一連串作業。兩相比較下,Jenkins Pipeline能做到的,基本上GitLab CI也能可以達成。巧的是兩工具都建議利用Ansible來簡化自動化佈署的難度(責任外包...XD)。而GitLab CI顯而易見的特色在於,GitLab CI是以分支的Commit來觸動Pipeline、擁有Artifact產出物管理功能、Pipeline和專案一同被版控管理等等。加上提供Mesasge Bot和API觸動Pipeline的機制、與Docker環境的高度整合,以功能完整性來看,GitLab CI確實遠優於Jenkins。當然Jenkins也有數不清的Plugins可以擴充功能,所以很難斷定那個工具是第一。
GitLab中涵蓋的軟體工程觀念實在博大精深,即便是這本和艦長一起30天玩轉GitLab第二版也僅能點到為止。對於有心的管理/開發人員,想導入更多、更完整的軟體工程來說,這本書可以是個起點,藉由GitLab這個強大的平台,漸進式的導入適合的流程與機制,以更有效率的作法產生更優質的軟體產品。
2023年8月7日 星期一
Web開發者一定要懂的駭客攻防術
在工作上一直都是擔任後端應用的職務,即便是目前負責的大數據與推薦引擎,依舊是歸屬在後端運算的範疇。然而在Web/HTTP影響力與日俱增的大環境下,單單開發一個API也擺脫不掉SOAP/REST這樣依附在HTTP協定的軟體架構風格。因此針對Web的安全性議題,是不分前、後端工程師都得認真學習、思考的核心知識。Web開發者一定要懂的駭客攻防術是一本堪稱完美的Web資安入門書,流暢又精確的文字內容,在資訊類型的書中相當罕見(IT類型的書多半文字用詞繞口,也會有一兩個勘誤)。全書分成必要的基礎知識和常見威脅兩部份,很完整又詳細地解說,Web應用程式是什麼?有哪些常見的漏洞?(更重要的是)如何防止哪些漏洞?
雖然駭客攻擊聽起來總是神秘莫測,令人聯想到諜報電影裡相當高上大的設備與工具。但比較落地的實情是,多數讓駭客入侵成功的程式漏洞,總數加起來不會超過手指數量(小提醒,是十)。這些可以一一細數的程式瑕疵,造成這麼多企業、個人的財務損失,起因常常是開發團隊沒有能力處理(知識不足)或低估資安漏洞的嚴重性。藉由研讀Web開發者一定要懂的駭客攻防術,足於讓從業人員認識、理解Web開發時應留意的重點,進而打造出有高防禦力的Web應用。想若所有開發者都被要求要通過此書提及的漏洞攻防國家測驗,才能從事Web程式開發職務(類似駕照考試),網路世界在這群有著資安DNA的工程師們推動之下,相信未來駭客產業將會大受打擊。
下列心得就針對第二部份常見威脅的內容,進行概略的重點整理,也方便未來回過頭來查閱。
1.注入攻擊
起因:
程式中使用SQL語法查詢資料庫;程式中執行作業系統指令。
手法:
利用外部可以輸入的介面或檔案上傳功能,將攻擊用的字串與檔案(WebShell)傳送到程式主機,並觸發予以攻擊
防止:
SQL注入:唯一作法是採用參數化語句或是ORM技術。如果無法修改程式,至少要做到最小權限原則,讓程式只擁有最少的必要權限,將傷害減到最低。
避免傳回暴露過多資訊的傳回值,例如此帳號不存在,而是採用模糊的回應,例如找不到此帳號和密碼。
命令注入:如果無法避免支援執行作業系統指令的功能,一定要將控制字元轉義,並採用白名單限制可以被執行的命令。
遠端程式碼執行:不要直接使用未經檢查的序列化/反序列化的資料來當輸入值,並留意伺服器軟體的漏洞,以即時修補。
檔案上傳漏洞:最好直接將檔案放在CDN雲端服務中,將風險轉移到雲端業者。不然就確保上傳的檔案無法被執行(無執行權),並進行強制的檔案轉製(圖檔/文字檔)。
2.跨腳本攻擊(XSS)
起因:
程式中有接受外部輸入的進入點,卻沒有將HTML控制字元轉義。
手法:
儲存型XSS:將惡意JavaScript藉由輸入功能(例如FB、留言板),儲存到系統資料庫中。
反射型XSS:將惡意JavaScript藉由輸入參數加在電子郵件/網頁的超連結中,誘使受害者點擊。
DOM型XSS:將惡意JavaScript加在URL中的URI片段中,讓沒有防護JavaScript前端程式(網站本身的程式碼)誤讀並執行惡意功能。
防止:
一律將外部輸入值進行HTML字元轉義,特別是"&'<>等控制符號。
使用內容安全原則(CSP)HTTP回應標頭功能,可指定只允許同站台與apis.google.com的JavaScript來源(<script src="..."/>),不允許內聯(inline)的JavaScript,設定方法如下:
Content-Security-Policy: script-src 'self' https://apis.google.com
也可以用HTTP <meta>標題來設定,方法如下:
<meta http-content="Content-Security-Policy" content="script-src" 'self' https://apis.google.com">
DOM型XSS:在使用URL字串時,都要進行控制字元轉義。
3.跨站請求偽造攻擊(CSRF)
起因:
HTTP的Cookie預設行為,是在任何請求中都會帶回指定URL同一Domain的Cookie值。
手法:
藉由惡意超連結,讓受害者對未防護的網站執行本人未同意的操作。
防止:
開發網站程式時要遵守REST原則,HTTP GET只用來讀取資料,不能用來新增、修改和刪除資料。
啟動網站伺服器或軟體框架裡的防CSRF Cookie功能。
設定Cookie為SameSite=Strict,確保同Domain的請求才能一併附帶Cookie資料
Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Strict;
較寬鬆的設定是SameSite=Lax,允許GET請求可以不限定來源Domain,都會附帶Cookie資料(適用於「分享」功能),其它請求一樣限定同Domain。
Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Lax;
對於敏感操作要求重複登入以驗證身份
4.攻擊身份驗證機制
起因:
駭客直接以假身份操作網站系統
手法:
暴力破解或暗網名單
防止:
使用多因子身份驗證機制(MFA)
實作安全的登出功能,將session Cookie清除
5.連線狀態劫持
起因:
利用Cookie來保持連線狀態(session),卻沒有完善保護Cookie。
手法:
駭客取得使用者的session id或session狀態,藉以偽裝成使用者的身份進行操作。
防止:
竊取Cookie:將Cookie設定如下。HttpOnly能讓JavaScript無法讀取Cookie,Secure確保只能在HTTPS時傳送Cookie,SameSite=Lax能避免CSRF攻擊。
Set-Cookie: session_id=278283910977381992837; HttpOnly; Secure; SameSite=Lax
Session定置:一律不使用「URL改寫」來傳遞session id。
脆弱Session ID:避免使用流水號式的Session ID設計,並留意Web伺服器在Session ID實作的漏洞公告。
6.規避權限管制
起因:
系統在權限設計或目錄規劃上有缺失。
手法:
駭客利用系統的缺失得以執行未經授權的操作或是取得未經授權的檔案。
防止:
實作嚴謹的以角色為基礎的存取控制,避免任何垂直提權(執行高一級的操作)和水平提權(以他人身份執行操作)的攻擊。
增加稽核軌跡。
避免使用任何過於直覺的URL路徑與參數設計。例如/reports/<公司名稱>/<月份-年度>,讓駭客能猜測到合法路徑。
確切設定Web伺服器,不允許顯示目錄內容、不允許利用相對路徑指定父目錄中的檔案。
不要直接引用檔案,要自行維護一組暗碼代號用以連結到主機上的實體檔案。
對任何有關指定檔案位置的外部參數,都要進行最嚴格的安全檢查。
7.資訊洩漏
起因:
因疏失造成系統將機敏資訊呈現給外部使用者。
手法:
針對系統進行探索式操作,以收集可用來進行後續攻擊的機敏資訊。
防止:
不使用系統預設的回應標題(像預設的4xx、5xx頁面)。
使用未帶程式副檔名(.php、jsp、aspx)的簡潔URL。
Cookie的健值不要用預設值(JESSIONID)。
不要在正式環境中顯示詳細的錯誤描述。
壓縮或模糊化JavaScript程式。
清理前端程式中不必要的註解和程式碼。
8.加解密機制
起因:
未使用加密通訊協定。
手法:
竊聽網路封包。
防止:
一律使用HTTPS。
9.第三方元件
起因:
使用到不安全的第三方元件。
手法:
針對已知的元件漏洞攻擊。
防止:
留意第三方元件安全公告,及時更新。
保護好第三方服務的系統金鑰。
10.XML攻擊
起因:
DTD的設計漏洞。
手法:
藉由內聯的DTD宣告,讓系統主機資源耗盡。
在DTD宣告外聯以下載惡意檔案。
利用XML解析失敗時會顯示檔案內容的特性,指定主機上的機敏檔案。
防止:
關閉DTD內聯功能。
設定防火牆限制外聯對象。
盡量不使用XML,非得使用時要再三確保XML解析器的安全設定已就位。
2023年3月25日 星期六
下世代超前佈署:用Zabbix全面監管巨量伺服器
在台灣中小企業為主的職場環境下,程式人員提供「一條龍」式的IT技能服務,是普遍常見的工作樣態。從設計構思、開發實作到後續的營運維護,如果不善用工具減輕自身的負擔,想憑著一腔熱血硬撐到底,結果不是爆肝就是離職單吧。IT系統看似五花八門,追根究底來說不外乎由網路設備、伺服器、中介軟體以及應用程式所組成。藉由監控系統適時地在每一層設定監管項目,營運人員將鉅細靡遺觀察IT服務運作的狀態。開碼的監控系統產品很多,而本書介紹的「Zabbix」是相當強大、易用的選擇。
從「設定主機」的步驟開始,使用者就體會到Zabbix包羅萬象的監控能力,主機(Host)指的是任何有連網的可被監控設備,除了一般的電腦/伺服器外,也包含各式網路設備。監控使用的通訊協定,從網路常見的SNMP(Simple Network Management Protocol)、硬體週邊的IPMI(Intelligent Platform Management Interface),到真正發揮出Zabbix驚人威力的Zabbix Agent/Agent2,選項一應俱全。面對最常見的伺服器硬體監控需求,藉由範本(Template)檔的協助,使用者將可快速地將CPU、記憶體、磁碟、網路卡等重點項目設定完成。尤其是自Zabbix 3.4版開始支援的LLD(Low-Level Discovery),自動搜尋伺服器裡的磁碟、網卡名稱帶入監控項目,讓管理者免於一台台手動調整監控項目裡的參數值,讓我這個一直在用Zabbix 2.x版的老用戶,感到這次升級值回票價。
因為範本檔和LLD兩者結合後的強大威力,一般常見的監控標的都可以既有的範本檔中獲得滿足,就連較新穎的HAProxy、Redis等中間層軟體,也都有可以參照的案例可以依循。書中也特別安排一個專章,介紹包含TCP、Nginx、PHP-FPM、MySQL、IPMI、磁碟陣列卡、路由器、VMware、RabbitMQ、Elasticsearch、Kafka、Redis、Oracle、WebLogic、SQL Server、HTTPS。監控項(Item)的實践Zabbix支援18種方法!加上透過Zabbix Agent的自訂使用者參數(UserParameter)功能,應該沒有任何無法監控的項目,唯一的限制就是使用者的想像力。針對非常客製化的應用服務層(自製系統的營運狀態),一樣是拿出傳家寶刀UserParameter就可以迎刃而解。API層的監控則是利用HTTP方法,如此一來同時擁有簡化設定、減少客製化的優點。雖然Zabbix也擁有對伺服器記錄檔的文字資料收集/監控能力,不過功能非常陽春,因此對於這種需求還是用Splunk或ELK這種專門工具比較理想。
和Cacti使用集中式主機輪詢的被動式監控不同,藉由Zabbix Agent的協助下,Zabbix可以採用主動式監控,來達成監控巨量標的的任務。按書中所言,在配置有適當主機規格的前提下,單一台Zabbix Server即可監控上千台伺服器。更別說如果再加上Zabbix Proxy的分散式監控架構,讓異地機房的監控負擔由Proxy先處理後傳回Zabbix Server整合。Zabbix的監控能力,足以滿足九成以上台灣企業的IT規模。簡單一句話:好東西,不學嗎?
2023年2月18日 星期六
玩真的!Git ? GitHub 實戰手冊 - coding 實境、協同開發、雲端同步,用最具臨場感的開發實例紮實學會!
Git工具在軟體版本管理領域中的地位我想已經不用多言,基本上除非是上古時期的恐龍工程師,絕大多數的碼農都至少熟悉一種版控工具,而Git是其中的佼佼者。它被廣泛地整合到各種IDE(整合開發環境)中,也有數種方便好用的GUI(圖形使用者介面)工具,一但有協同開發的需要,Git對軟體工程師而言是非常友善的選項。
話說回來,也因為工具整合的太好,常見的操作根本用不著親自下指令,所以許多人連基本的Git指令都沒打過。更別說一些合併失敗的異常情況,是需要瞭解Git的設計與觀念才能迅速、正確的排除。如果沒打好基礎,偏偏又在專案Deadline前遇到,那可真的會讓人冷汗直冒。而這本「玩真的!Git ? GitHub 實戰手冊」正是以實例帶領讀者利用最符合職場開發情境的範例,完成一項又一項具體的Git任務,讓你從初學邁到進階的一本佳作。
不論是全域參數檔設定、修改/壓縮commit註解和運用stash暫存區等,這些被一般書籍視為「進階」的Git功能,書中都用簡明扼要的描述並配合直接的例子讓讀者心領神會,對比其它以Git為主題的書,這本的CP值是遙遙領先。最終章更是將使用Git時常困擾開發者的一些疑難雜症條例出來,一一提出具體解法。這本書放在案頭,可以讓你有如服下定心丸般,盡情使用Git來滿足協同開發與版本控制的需求。




















