Hello 讀者好～
經典科幻電影《駭客任務》要出第四集了（英文正式片名為 The Matrix Resurrections）！提前上線的互動式官方網站很有意思，由你自己來選擇藍色藥丸或紅色藥丸，每次重新點擊都會產出不同的電影剪輯片段，據說共有 18 萬種版本 💊
編輯已經準備好中秋連假複習小時候看得似懂非懂的三集《駭客任務》，12 月上映時無縫接軌。
liz
| [Podcast] 星箭廣播 EP123 | 一部電影要播一年！電子紙「慢電影播放器」｜Titan 幫自己的智慧音響做了一個螢幕 越來越多生活環境裡的廣告看板、公車站牌、速食店菜單都漸漸被螢幕取代，有些甚至換上了電子紙螢幕。本集《星箭廣播》想跟大家聊聊各種跟顯示器相關的有趣專案。前陣子 Julie 發現一個專案「慢電影播放器」，作者將電影《2001 太空漫遊》特殊處理後，以原本三千分之一的速度在自製電子紙螢幕播放，原本兩個多小時的電影變成超過八千小時，要一年才播得完。作者的靈感來源是什麼？除了用上電子紙螢幕，他還用了什麼特殊的技術去處理影像？ Titan 會分享一個他最近按照網路教學完成的小專案：用 Raspberry Pi 搭配一片四吋 LCD 螢幕，為家裡的 Sonos 音響系統做一個顯示器。兩位主持人還會聊到幾個有趣的螢幕相關專案和產品，例如電子紙手寫平板電腦和柔性 AMOLED 螢幕 DIY 套件等等。當然，也歡迎你跟我們分享更多好玩的專案或應用。 |
| [英] 按人頭還是使用量收費？你的 SaaS 新創產品該如何訂價？ 你的 SaaS 新創產品該按照人頭（per seat）還是使用量（per use）來收費？前者對客戶來說費用的可預期性較高，常見的是 Salesforce 或 Adobe，後者提供的彈性高，代表則是 Twilio。簡單的做法是可以先用一個 2X2 的矩陣，將客戶的價值（value）與使用量（usage）各自區分為間歇、週期性（Intermittent）和穩定（steady）兩種，如果客戶價值與使用量都是間歇、週期性，那可以採用按照使用量收費。文章會進一步談到選擇訂價策略的多種情境（例如你的成本結構、進入市場策略），甚至混搭的使用方式，有些 SaaS 公司會先收取一定的費用，然後再按使用量計費。 作者提醒，許多人將訂價策略當成「變現」（monetization）在思考，但把它當客戶獲取策略（acquisition strategy）來想也很重要。善用訂價策略還有綁住客戶的效果，例如按人頭計算並以年費計價，其實就是客戶的轉換成本。作者還舉了一個很有意思的案例：米其林有一款輪胎很耐用，若按舊有模式來賣勢必會侵蝕銷售，因此他們改採里程數（使用量）來計價，這讓卡車/貨運公司可以將費用轉嫁到客戶身上。 |
| [英] 設計師必須要很努力，才能讓使用者毫不費力——「預設值」的五個設計原則 你能想像一個沒有「預設值」的世界嗎？操作任何產品都必須自行定義，這肯定會增加許多認知負荷。對多數使用者來說，「預設值」能不動則不動，因此預設值是展現設計是否周到的重要關鍵。 曾在 Air Asia、思科擔任設計師的 Rohith M S，分享了五個預設值的設計原則：以訂機票的流程為例，需要自己手動調整的選項能少則少，另外，盡量使用大家熟悉的設計元素，別讓使用者 在需要自定義時感到困惑。最後一個建議則是，切記保留「恢復預設值」的選項（編輯就有使用新產品時改預設值改到亂掉，想歸零重新來過卻遍尋不著，只好刪掉重新下載的經驗 🥲）。 |
| [英] 四封電子郵件揭露 YouTube 被 Google 收購的 起源 2006 年 Google 以 16.5 億美金收購了 YouTube，創下科技史的經典收購案例。Google 當時是怎麼看待這間剛展露頭腳的公司的？Internal Tech Email 揭露了四封由 Google 高層 Jeff Huber、Peter Chane 針對 YouTube 交換意見的信件，YouTube 創辦人來自 PayPal 幫的背景，以及近在咫尺的創業地點，商業化的潛力、方式也與 Google 的長處不謀而合，這些都讓 Huber 興致高昂，Chane 的態度則較為保守 🧐 最後，他們把整串信件呈交給 Google 共同創辦人 Larry Page，他的態度是什麼呢？（此外，寄件副本欄也有玄機——後來成為 YouTube CEO 的 Susan Wojcicki 也在寄件對象裡面。） |
| [英] 反向面試問題集 「你有沒有什麼問題？」面試時主動提問，是了解公司、團隊，降低期望落差的機會。GitHub 上一份集結眾人心力的「反向面試」（Reverse interview）問題集，列出了許多在面試時可以反問面試者的問題，從職責範圍、技術層面、團隊文化、辦公環境、福利到遠端政策，還包含了公司對公共議題的態度與立場。你可以從這份清單中找到自己最好奇的問題，先做做功課後如果無法找到答案，就可以在面試中提問了。 本文也有中文版本（簡體），有需要的讀者可以參考～ |
| [英] Notion 用 Next.js 重構了官網，自家工程師現身說法 隨著 Notion 使用者快速成長，團隊也頻繁發表部落格文章和使用指南，並新增各種登入頁面，但同時網站的效能也成了未爆彈。（你可能也聽過的抱怨是速度越來越慢了）於是他們出動三位工程師、花了兩個月重構官網搬到 Next.js——結果網站 Lighthouse 分數從原本的 50 分變成 97，SEO 成效也提升了，而且開發時不用再擔心弄壞官網和 app。 因為初期團隊規模小，Notion 官網和 app 共用一套程式碼是利大於弊，但兩年過去，開發者和使用者體驗都開始受影響，而在優化現有用戶端 codebase 和搬到靜態網站產生器從頭開始之間，他們最終採用了後者。至於過程中的決策和執行細節，包括為什麼選擇 Next.js；在版本控制、託管、部署等方面要特別注意的事，也很值得參考。 |
| [中] Phil Huang／雲端原生人才看得到，找不到？ 雲端原生（Cloud Native）領域中，為什麼會出現「人找事」或「事找人」的種種問題？作者黃秉鈞以地端 IT 基礎架構師角度拋出討論，首先點出他觀察到台灣甲乙方的現況，像是多數政府單位及金融、製造業仍重視地端＋離線的基礎平台建設； app 開發只想用服務而不想管服務等等；而老闆對 DevOps、SRE 和雲端工程師這類員工又有著變身超級賽亞人的期待。 人才端的部分，除了釐清考取證照與否的意義，作者也點出幾個常見誤解和相對應的組織文化挑戰，包括會容器使用 VS. 會容器平台管理、CI/CD 持續交付整合、IT 自動化。最後還有關於 DevOps 和 SRE 的差異，以及他分享給人才和企業方的一些建議。雖然這是線上討論的簡報檔，不過仍能對此議題有更進一步的了解。 |
| [中] Huli／來談談工程師的知識焦慮 前端工程師 Huli 常看到有人問自己下一步該往哪去，是要學 A 還是 B 或回去學重要的基礎 C？他曾經也是這樣，發現時不時有新的框架或函式庫出現，也每天汲取新的知識，但還是有這種「學不完」的知識焦慮。而他的解方是選擇放棄——他反思自己真的需要這些知識嗎？少看了真的有影響嗎？ 他剖析知識焦慮產生的最大原因之一是沒有方向，所以他分享給已經在工作、還在找工作的人不同建議，包括他對學習順序的看法（先學習工具跟框架，抑或是原理跟基礎？），幫助擺脫這種知識焦慮，專注眼前目標，並忽略其他雜訊。 |
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出
（文章代表圖：Photo by Liam Truong on Unsplash）