如何正確的設計表單？必須知道的用戶輸入 UX 基礎
表單是是網站中最常見的功能性元素也是與用戶溝通的橋樑，像是購買商品、註冊會員、問卷填寫……等各項行動都離不開它，然而這麼重要的體驗卻時常被忽略，於是我決定整理一個良好的表單應該具備的體驗以及為什麼應該這樣設計，供所有人了解常見的表單設計問題。
表單是是網站中最常見的功能性元素也是與用戶溝通的橋樑，像是購買商品、註冊會員、問卷填寫……等各項行動都離不開它，然而這麼重要的體驗卻時常被忽略，於是我決定整理一個良好的表單應該具備的體驗以及為什麼應該這樣設計，供所有人了解常見的表單設計問題。
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？轻易的撰写运行时数据验证就是 Zod 的目的，像是验证第三方 API 传递的数据、用户输入在 URL 中或表单中的数据使用 Zod 来验证都很方便。
JavaScript 有 try...catch 語法用於捕捉程式中的錯誤情境，在需要時使用 throw 語法來拋出「任何錯誤」，通常建議會丟出 JS 預設的錯誤物件，但在 TypeScript 要怎麼做才能確保拋出的錯誤的型別？
Zod 是以 TypeScript 為首的 Schema 聲明和驗證庫，為什麼有了 TypeScript 還需要 Zod？輕易的撰寫 Runtime 資料驗證就是 Zod 的目的，像是驗證三方 API 傳遞的資料、用戶輸入在 URL 中或表單中的資料使用 Zod 來驗證都很方便。
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 猛然察觉这不是我日常工作拆分问题的方式吗！简直是不谋而合，正好也想写一篇文章来分享这个达成共识的方法，同时这也是一个很好向上沟通的方式，不管是对团队还是对上级沟通都有帮助。
最近閱讀 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察覺這不是我日常工作拆分問題的方式嗎！簡直是不謀而合，正好也想寫一篇文章來分享這個達成共識的方法，同時這也是一個很好向上溝通的方式，不管是對團隊還是對上級溝通都有幫助。
網頁原先是靜態文件，但隨著需求增加，動態的改動網頁的狀態已變得普遍，隨意使用 `disabled` 屬性就像是在用戶路上堵上一顆巨石，這樣的設計不僅無法幫助用戶解決問題，還會讓用戶感到困惑。我們應該盡全力讓用戶知道問題原因，而不是只做到「阻止用戶的錯誤行為」。
在 Astro 中使用 MDX 撰寫文章給我非常多的彈性，但絕大多數文章我還是希望使用 Markdown 現有的語法來撰寫，像是：圖片、程式碼區塊、列表……等，有沒有辦法將自定義的元件對應於 Markdown 語法呢？這樣就不用每次都要再 MDX 中特地引入元件並使用，單純的撰寫 Markdown 即可。
TDD Test-Driven Development is a development methodology where tests are written before the implementation code.
TDD 测试驱动开发是一种开发方法论，先写测试再实践代码，应该如何撰写测试？或许听过 TDD 但不清楚与单纯写测试差别在哪？这篇文章详细描述 TDD 的优势与实际操作范例快速了解 TDD 为什么这么赞。TDD 目的便是打造一个工作流程能够验证代码的行为，让开发者能够更有信心的重构、更动代码。
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑：為什麼 UI 設計與開發的流程總是如此不順暢不協調？「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品？」是本篇文章探討的核心問題。