使用 Zod 于运行时检验类型
Zod 是以 TypeScript 为首的 Schema 声明和验证库，为什么有了 TypeScript 还需要 Zod？轻易的撰写运行时数据验证就是 Zod 的目的，像是验证第三方 API 传递的数据、用户输入在 URL 中或表单中的数据使用 Zod 来验证都很方便。
Zod 是以 TypeScript 为首的 Schema 声明和验证库，为什么有了 TypeScript 还需要 Zod？轻易的撰写运行时数据验证就是 Zod 的目的，像是验证第三方 API 传递的数据、用户输入在 URL 中或表单中的数据使用 Zod 来验证都很方便。
JavaScript has try...catch syntax for capturing errors. How can we ensure the type of errors thrown in TypeScript?
Zod is a schema declaration and validation library led by TypeScript. The purpose of Zod is to easily write runtime data validation.
JavaScript 有 try...catch 語法用於捕捉程式中的錯誤情境，在需要時使用 throw 語法來拋出「任何錯誤」，通常建議會丟出 JS 預設的錯誤物件，但在 TypeScript 要怎麼做才能確保拋出的錯誤的型別？
Zod 是以 TypeScript 為首的 Schema 聲明和驗證庫，為什麼有了 TypeScript 還需要 Zod？輕易的撰寫 Runtime 資料驗證就是 Zod 的目的，像是驗證三方 API 傳遞的資料、用戶輸入在 URL 中或表單中的資料使用 Zod 來驗證都很方便。
最近阅读 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察觉这不是我日常工作拆分问题的方式吗！简直是不谋而合，正好也想写一篇文章来分享这个达成共识的方法，同时这也是一个很好向上沟通的方式，不管是对团队还是对上级沟通都有帮助。
Recently reading about Goals, Problem, Solutions in Stay SasSy made me realize this is how I break down problems at work!
最近閱讀 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察覺這不是我日常工作拆分問題的方式嗎！簡直是不謀而合，正好也想寫一篇文章來分享這個達成共識的方法，同時這也是一個很好向上溝通的方式，不管是對團隊還是對上級溝通都有幫助。
網頁原先是靜態文件，但隨著需求增加，動態的改動網頁的狀態已變得普遍，隨意使用 `disabled` 屬性就像是在用戶路上堵上一顆巨石，這樣的設計不僅無法幫助用戶解決問題，還會讓用戶感到困惑。我們應該盡全力讓用戶知道問題原因，而不是只做到「阻止用戶的錯誤行為」。
在 Astro 中使用 MDX 撰寫文章給我非常多的彈性，但絕大多數文章我還是希望使用 Markdown 現有的語法來撰寫，像是：圖片、程式碼區塊、列表……等，有沒有辦法將自定義的元件對應於 Markdown 語法呢？這樣就不用每次都要再 MDX 中特地引入元件並使用，單純的撰寫 Markdown 即可。
TDD 测试驱动开发是一种开发方法论，先写测试再实践代码，应该如何撰写测试？或许听过 TDD 但不清楚与单纯写测试差别在哪？这篇文章详细描述 TDD 的优势与实际操作范例快速了解 TDD 为什么这么赞。TDD 目的便是打造一个工作流程能够验证代码的行为，让开发者能够更有信心的重构、更动代码。
TDD Test-Driven Development is a development methodology where tests are written before the implementation code.
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑：為什麼 UI 設計與開發的流程總是如此不順暢不協調？「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品？」是本篇文章探討的核心問題。
TDD 測試驅動開發是一種開發方法論，先寫測試再實踐代碼，應該如何撰寫測試？或許聽過 TDD 但不清楚與單純寫測試差別在哪？這篇文章詳細描述 TDD 的優勢與實際操作範例快速了解 TDD 為什麼這麼讚。TDD 目的便是打造一個工作流程能夠驗證程式碼的行為，讓開發者能夠更有信心的重構、更動程式碼。
观察并厘清什么样的「品格」是一位软件工程师可以具备的，以及普遍工作环境和社群带给我的感受，总结出几点可以解决问题的模式，在日常也作为我自己参考与努力的依据。有耐心、能沟通、跳脱框架是我理想中软件工程师可以具备的美德，不知道你是不是也认同这样的想法？