我如何選擇自己鍵盤的故事
我是一個物慾非常低的人,日常東西就是用到壞才換新,直到某天常用的薄膜鍵盤壞了才開始尋找新的鍵盤。在挑選新鍵盤的過程中讓我想到選擇鍵盤的一些故事促使寫下這篇文章。作為軟體工程師不外乎每天接觸到的硬體生產力工具大概就是:鍵盤、滑鼠、電腦、螢幕、椅子、筆電、大水杯(喝水非常重要),其中鍵盤絕對是情感最深厚的一個。
我是一個物慾非常低的人,日常東西就是用到壞才換新,直到某天常用的薄膜鍵盤壞了才開始尋找新的鍵盤。在挑選新鍵盤的過程中讓我想到選擇鍵盤的一些故事促使寫下這篇文章。作為軟體工程師不外乎每天接觸到的硬體生產力工具大概就是:鍵盤、滑鼠、電腦、螢幕、椅子、筆電、大水杯(喝水非常重要),其中鍵盤絕對是情感最深厚的一個。
近期重寫的專案中有許多狀態需要管理,會需要統一管理資料於專案中,為了避免寫死代碼(Hard Coded)並且讓接手的人都能輕易地瞭解資料型態,這裡記錄一些過程中的發現。結論是應該使用 as const 來達成列舉資料管理,因為它更加直覺沒有什麼認知負擔,並且更加靈活。
為什麼如今網站大多數都長得差不多,就連體驗也差不多?我們時常會聯想設計網頁是一門富含創意創新的工作,但對使用者來說創新並不全然是一件好事。本篇文章希望引導讀者了解網頁發展的經歷並推導出為什麼「無聊的使用者介面是好的使用者體驗」這個結論。
身為前端工程近期工作的感悟是很多時候開發問題還是陷於介面的外觀、行為或互動層面上,並不是說花時間製作這些層面的事情就很遜,它們實際需要依靠經驗豐富的開發者透過多方面的研究與考量才能打造合理的架構,例如有許多要留意的事:效能、適用性、可維護性、可測試性、搜尋引擎最佳化、跨平台相容性、多語系……
AI 並不會離開我們的生活,並且只會越來越普及,這也意味著我們的生活將受到影響。什麼事情是人類能 AI 不能的?未來的工作會是怎麼樣?人們能做什麼來保證未來?什麼事情是人類能 AI 不能的?未來的工作會是怎麼樣?人們能做什麼來保證未來?思考以上問題。
Lighthouse 是一款開源的自動化網頁效能檢測工具,通常都是遇上網頁效能問題才一個一個開網頁開來測試效能,手動測試總是會有:單次的測驗結果不穩、耗時費力、不利於團隊開發的問題,今天來嘗試使用 Lighthouse CI 自動化的在每次代碼更動時檢測網頁的效能問題吧!
不到 3 步驟讓你的網站擁有以 WebAssembly 高效驅動的客製化搜尋功能。靜態網站像是部落格、文件、個人網站、公司網站……等這類閱讀體驗為主的網站通常都有搜尋內容的需求,恰逢 Pagefind 1.0 的推出我把原先自製的 fuse.js 搜尋功能換成 Pagefind,分享如何在任何靜態網站上加入搜尋功能。
近期工作接觸使用 Shadcn for Vue 來打造網頁 UI,這是一款基於 Tailwind 可彈性客製化的元件組合,讓我們可以快速建立出符合需求的網頁介面。這篇文章將會介紹現有樣式庫的問題以及 Shadcn UI 的特色,以及為什麼在前端圈這麼火爆。
表單是是網站中最常見的功能性元素也是與用戶溝通的橋樑,像是購買商品、註冊會員、問卷填寫……等各項行動都離不開它,然而這麼重要的體驗卻時常被忽略,於是我決定整理一個良好的表單應該具備的體驗以及為什麼應該這樣設計,供所有人了解常見的表單設計問題。
JavaScript 有 try...catch 語法用於捕捉程式中的錯誤情境,在需要時使用 throw 語法來拋出「任何錯誤」,通常建議會丟出 JS 預設的錯誤物件,但在 TypeScript 要怎麼做才能確保拋出的錯誤的型別?
Zod 是以 TypeScript 為首的 Schema 聲明和驗證庫,為什麼有了 TypeScript 還需要 Zod?輕易的撰寫 Runtime 資料驗證就是 Zod 的目的,像是驗證三方 API 傳遞的資料、用戶輸入在 URL 中或表單中的資料使用 Zod 來驗證都很方便。
最近閱讀 Stay SasSy 提到的 Goals, Problem, Solutions 猛然察覺這不是我日常工作拆分問題的方式嗎!簡直是不謀而合,正好也想寫一篇文章來分享這個達成共識的方法,同時這也是一個很好向上溝通的方式,不管是對團隊還是對上級溝通都有幫助。
網頁原先是靜態文件,但隨著需求增加,動態的改動網頁的狀態已變得普遍,隨意使用 `disabled` 屬性就像是在用戶路上堵上一顆巨石,這樣的設計不僅無法幫助用戶解決問題,還會讓用戶感到困惑。我們應該盡全力讓用戶知道問題原因,而不是只做到「阻止用戶的錯誤行為」。
在 Astro 中使用 MDX 撰寫文章給我非常多的彈性,但絕大多數文章我還是希望使用 Markdown 現有的語法來撰寫,像是:圖片、程式碼區塊、列表……等,有沒有辦法將自定義的元件對應於 Markdown 語法呢?這樣就不用每次都要再 MDX 中特地引入元件並使用,單純的撰寫 Markdown 即可。
Continuous Delivery 在 The Biggest Problem With UI 影片中點出了我多年來對於產品 UI 開發流程最大的疑惑:為什麼 UI 設計與開發的流程總是如此不順暢不協調?「有沒有辦法讓團隊穩定高效的產出真實滿足用戶需求的產品?」是本篇文章探討的核心問題。