一、今天要達成什麼今天的目的是對系統進行全面的測試，從功能到性能，從異常情況到用戶行為模擬，確保系統在發佈之前不會出現任何重大問題。會根據測試結果進行改進，特別...
一、今天要達成什麼在正式發佈之前，需要檢查所有的資料和設定，確保一切正確無誤。今天我想要確保所有的 API 檢查項目都符合標準並準備好進行上線。二、檢查項目清單...
一、今日目標用 Google 試算表把 Day 20 累積的資料，做成最小可用的儀表板。 逐小時成功率（折線） 「資料最不新鮮」Top 10（橫條） 右上角顯...
一、前言到站資訊多半看一下就」，使用者要的不是長篇說明，而是一句話就懂：現在有沒有車、資料多久前的、要不要等。以下把常見情境整理成文案庫，搭配簡單寫作規則，之後...
一、前言到站時間（ETA）本質上是「預估」，不是「保證」。路況、紅綠燈、上下車人數等因素都會讓時間飄。本篇整理最常見的 5種不準原因，並搭配「畫面怎麼說」「系統...
一、前言今天把前面累積的數字（成功率、延遲、新鮮度、429、noData、請求量）放進一頁式儀表板。重點是「讓人一眼看懂今天穩不穩、哪裡出問題」，而不是塞滿所有...
前言昨天我已經讓 n8n 每天 07:00 自動存一列資料。從今天開始，不再只看有沒有存到，而是學會看懂這些數字：成功率、延遲、被限速的次數、資料新鮮度……有了...
前言前面已經決定好要查哪三支 API，也有快取時間、錯誤說法、欄位命名。今天要做的事，就是把「每天都要查一次」這件事交給工具做，不要每天手動開 Postman。...
前言前面都在把 API 本身「做好」：欄位有沒有對、時間有沒有時區、錯誤有沒有統一、查不到有沒有說明。到今天開始可以看「實際使用起來穩不穩」，這就需要有幾個指標...
前言前幾天我們都在處理「有資料」的情況，像是固定資料先抓、即時資料要看才抓、抓完可以快取。但實際上一定會有打不到、來源回空的時候。這一篇要先把這些「有問題的狀況...
前言昨天我把「資料每天怎麼流動」分成平常版和尖峰版。今天要把這條路線再具體一點，說清楚：哪些資料可以暫存（快取）、可以存多久、超過多久要丟掉重抓、抓不到時要不要...
前言今天要把三支 API（/bus/routes、/bus/stops、/bus/eta）排成一條「每天都看得懂」的資料路線。平常怎麼查、什麼時候要存、多久要重...
今天要做什麼前面 Day 5 我們已經按按鈕試過了，確定 API 打得通。但只靠眼睛看，很容易漏掉欄位沒回或時間不是 ISO 8601等等。今天就是在 Pos...
前言現實世界的 API 很多都不是完全公開的，會要求你帶金鑰才能查。只要有金鑰，就一定要想三件事：放哪裡不會被亂看到、哪些人能看、過期或失效時要怎麼換。今天我打...
前言今天要把「一定要有、不能為空、長甚麼樣」寫成一份清單，之後不管誰都可以照這張表檢查，確保三支 API 的資料都能穩定顯示而且好看。一、三支 API 的「一定...
前言同一時間，很多人都在查到站時間。若大家一直猛刷新，資料提供端很容易被塞爆，結果誰也拿不到最新資料。速率限制（Rate Limit）的目的就是：讓大家用可持續...
前言到站資訊要「準、穩、能解釋」。測試的目的是：同樣的輸入，三支 API（/bus/routes、/bus/stops、/bus/eta）要回一樣的寫法與可預期...
目標 把 /bus/routes、/bus/stops、/bus/eta 寫成一份最小可用的 OpenAPI（YAML）。 只放一定會用到的核心欄位；先能讀懂...
前言今天先把要用到的三個查詢用一頁說明寫清楚，重點是每個查詢的「網址要長怎樣」、「一定要帶哪些欄位」、「回來會有哪些欄位」。先把這三件事定好，明天就能很順地把它...
前言到站資訊再怎麼做，現場都可能出現各種不如預期的狀況。我認為好的做法不是把數字藏起來，而是用一致、看得懂的文字把狀態說清楚，並附上資料的新鮮度。今天把會遇到的...
前言要在同一個畫面同時看到「站名」與「幾分鐘到」，關鍵在於兩份資料能不能對得上。沿用昨天的規則：欄位用小駝峰、時間用 ISO 8601（含時區）、持續時間用秒、...
為什麼先把「寫法」講好資料每天都可能變，但寫法要固定。固定的寫法能讓介面設計、測試、自動化與協作變簡單：欄位看名字就懂、錯誤一眼能判斷、時間不用猜。今天把三件事...
目標 完成一份 Postman Collection，包含「站/路線（固定）」與「到站（即時）」兩支請求。 以按鈕方式發送兩次請求並取得成功回應，保存為學習成...
目標：1.規劃「到站小看板」版面與文案。2.訂出資料新鮮度（SLO）與顯示規則，確保資訊清楚、穩定、可預期。 介面草圖如下： [ 到站小看板｜市政府站（往○○方...
前言:今天先不急著去按任何按鈕，把心力放在「看懂官方的說明頁」。理由很簡單：要畫畫面、決定多久更新一次，都要建立在「我知道去哪裡問、要帶什麼、回來長怎樣」這三件...
前言每天早上我在臺北等公車，手機上的不同 App 有時給出不同的到站時間。不是誰故意騙人，而是大家拿資料的方式不一樣、更新時間也不一致。把資料透過「同一個窗口」...
前言大家好，我每天在臺北通勤，常遇到「公車到底幾分鐘到？」或「轉乘資訊很分散」的困擾。與其抱怨，不如用 30 天把資料接起來：找得到、看得懂、用得上。這個系列的...
iThome鐵人賽
看影片追技術