Hello 讀者好，
你有發現最近出現了想多白板軟體嗎？與 Miro、FigJam 等主打設計協作的白板軟體不同。Eraser 這款白板則是強調專為工程師團隊而生，例如支援 markdown 語法的便條貼、可以靠鍵盤百分百控制，寫程式與畫圖表融為一體。網站上也提供許多範例模板，大家可以體驗看看。
lily
[Podcast] 星箭廣播 EP171 | 當你的往來銀行也是新創公司：聊聊在美國創業用的 SaaS（ft. 林宜儒）
延續 170 集〈創業不去矽谷了？台灣創業者前進德州奧斯汀〉，連續創業者、 Teachify 開課快手 共同創辦人 Lawrence 要聊聊他們公司在美國營運所使用的 SaaS 產品，並且回顧一下過去在台灣創業時的相關經驗，包括與銀行往來的「難忘」回憶。
Lawrence 以一個對於在美國開公司還不太熟悉的創業者角度，深入分享他們用於管理、支付員工薪酬和保險的 Gusto，以及同為新創公司的銀行服務 Mercury，這些厲害的產品讓他對於「API 正在吃掉價值鏈」以及 No-Code、Low-Code 等趨勢有更深一層的體會。除了深入分享使用體驗，Lawrence 也會談到如何評估是否採納某個 SaaS 產品。
本文作者是一位 UX 寫作者，她在文中說明「命名」之於設計系統有三個重要性，包括：為團隊建立共通語言、將抽象的想法轉化成有形有體的文字才能順利施作，並為前端程式碼與設計文件搭起溝通橋樑。文中最實用的部分莫過於為設計系統命名的技巧，掌握邏輯、可擴充性、簡練並制定標準原則，命名不再是苦差事。
本文作者 Ernest 是 AWS Community Hero，長期參與台灣 AWS 社群。這是他寫給 AWS 新手（包含不會寫程式的人）的學習路線與策略，全文以結構化方式提供資訊，著重於 PDCA 循環的「P」（plan），並且附有一張以筆記軟體 Heptabase 製作的學習地圖。
除了附上相關資源連結之外，Ernest 更重視「學習的架構」。就像我們看一般地圖，他建議讀者先找出自己在哪裡，先從距離自己位置最近的開始學。對於沒有相關基礎的讀者，他也說「先不要管這些甜點是怎麼做出來的，先試著品嚐看看味道」，可以先從應用層面、S3 或 serverless 著手。最後再次提醒感興趣的讀者記得到文章最下方查看 Ernest 提供的「地圖」。
你做過「業餘專案」嗎？在正職工作之餘，本文作者 Ben Stokes 探訪了業餘專案愛好者在閒暇之餘做的小工具、迷你服務或課程內容，像是對待專案如栽植一座花園的法國開發者 Ben Issen，以及為 Tinder 打造 VS Code 外掛的 Ben Awad，讓大家靠著程式風格決定左滑還是右滑。有的純粹為了好玩，有的則是為了在履歷上增添經歷，來看看他們在「創作者經濟」扮演了什麼樣的角色吧，又，如果業餘專案失敗了會怎樣嗎？如果你還不知道業餘專案是什麼、或者需要有人推一把啟動專案，這篇文章會是很好的起點 😎
產品經理該怎麼思考自己的職涯呢，有沒有如軟體工程師一樣的「職涯階梯」可以參照？本文前半段詳細說明何謂產品經理的職涯階梯，包含獨立貢獻者跟管理者兩種角色，他們分別該有什麼樣的技能？會經歷什麼樣的階段？
文章後半段則是解說在組織中如何導入產品經理職涯階梯，包含制定、導入、落實與調整四個部分，主管、產品經理與人資都應參與其中，例如對主管來說，為了避免倚賴年資，並讓真正傑出的產品經理晉升，最關鍵的任務是制定職級標準、找出楷模（role model）；而對產品經理來說，清楚的期待跟成長路徑則是他們最在乎的事。
你在開發軟體時都會寫「測試」嗎？假如你對測試還沒什麼概念，可以參考這篇文章。本文主題是軟體開發過程中的測試環節，對測試的意義與相關基礎概念做了一番簡介。作者 PJCHENder 是一名專注於前端技術的開發者。文中提到，假如把軟體開發的過程比喻成寫考卷，那麼「測試」就像是在對答案，所謂的「寫測試」則是將原本手動的測試工作自動化，以程式來進行。
作者在提供測試範例時指出，寫測試都需要有一個預期的正確結果，再拿實際執行後的結果與之比對，讀者也可以拿這個概念對照文末介紹的「測試驅動開發」（TDD）。本文也有討論到「一定要寫測試嗎？」這樣的問題，作者認為答案會隨著專案的時空背景不同而改變，例如產品開發的階段或商業模式都有影響，甚至也不是簡單的是非題。
（文章代表圖：Photo by Kevin Jarrett on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出