最近用了很多 Cloudflare 的產品，像是 Zero Trust、WARP，還有 Cloudflare Tunnel。每次的體驗都讓我嘖嘖稱奇，好像它們預判了我的需求一樣。這家公司始終追求著「更好的網路」這個目標，內容付費又是另一個例子。 🗞️ 熱門新聞 Content Independence Day: no AI crawl without compensation! 賽博佛陀 Cloudflare 又來普渡眾生了。這次是針對 AI 爬蟲收費。 「網路正在改變。它的商業模式也將改變。在這個過程中，我們有機會從過去 30 年網路的優點中學習，並為未來的網路創造更好的環境。 」 Cloudflare 真的很有意思，連思考的角度都很有趣。 內容當然是有價的，只是價格會怎麼支付呢？在現代的內容創作，這題變得非常複雜。 Folklore.org: Joining Apple Computer
有些產品看到會覺得行不通，有些產品則相反，只要聽到就覺得是個好主意。Sentry 的產品通常都是後者。我猜有部分，也是因為它們的產品都指向同一個使命：可除錯性。 🗞️ 熱門新聞 Linux Foundation Announces the FAIR Package Manager Project for Open Source Content Management System Stability Linux 基金會啟動 FAIR 專案，為 WordPress 外掛程式提供替代方案。 底下的 Supporting Quotes 可以看看，講話都很客氣，左一句「去中心化」右一句「透明的治理架構」，在講什麼大家都很清楚 😜 。 Uber 與 Airbnb 重塑 VC 玩法，一文看懂 a16z 創辦人
來自阮一峰老師的靈感與嘗試，我會在 Weekly Issue 中記錄每周值得分享的科技內容，周一發刊。多數內容都有刊在我的 X、Threads 或 Facebook 中，你可以追蹤上述社群媒體得到最新消息。這裡的性質更接近單周回顧與歷史歸檔。 🗞️ 熱門新聞 The Pulse #134: Stack overflow is almost dead StackOverflow 的情況比我想的還糟，退化到剛成立三個月的狀況？太要命了。 我自己好奇的是 2020 年的衰退如何引起？平台治理的問題嗎？ Cloudflare service outage June 12, 2025 Cloudflare 近幾次中斷事故都有出報告，內容包括背景跟時間軸，還有改善方式，這是很正確也很重要的實踐。 我也曾經遇過幾次重要的服務停機事件，當時都會盡可能擠出時間即時更新 + 出報告。後來服務也的確越來越穩。這種問題很多都是文化層面的問題。 Ask HN: How
Web
自訂網域（Custom Domain）是 SaaS 常見的服務，只是我通常都沒花錢買。某次跟朋友聊天，她想聽聽我對內容平台的觀點，嘰哩呱啦分析完一堆後，我最後建議她，最好還是買個網域： 「你想想看，妳現在投入這麼多心力在經營內容，建立自己的品牌形象。如果妳的網址永遠都掛在別人的平台底下，就像在別人家租房子，雖然方便，但終究不是自己的。」 「有了自訂網域，妳的品牌就是自己的，無論未來平台怎麼變，妳的讀者都能透過固定的網址找到妳，這對品牌來說很重要。就算未來妳想換平台，也不會流失妳辛苦建立起來的流量。」 後來我在 Ghost 官方頁面看到類似說法 If you would like to make your site memorable and easy to find with a branded custom domain, then you can
Web
Phil Karlton 有句名言：「計算機科學中只有兩件難事：快取失效和命名。」 想像你在管理網站，因為傳輸速度與伺服器效能問題，網站讀取速度很差，特別是當你的使用者來自地球另外一端，常常需要等待幾秒才能看到畫面，這讓他們的使用體驗大打折扣。身為一名重視使用體驗的開發者，你肯定知道該如何解決這問題，沒錯，答案就是 CDN（內容傳遞網路）。 CDN 可以看成是服務商在全球各地建置伺服器，當你的網站內容（例如圖片、CSS、JavaScript、影片等）流經這些伺服器時，它會保留一份複本（稱為快取），等到下次有人讀取同樣的內容，CDN 會拿出複本給使用者。因為全球各地都有 CDN 節點，美國的使用者可以由美國節點提供，日本的使用者可以由日本節點提供。這樣既加速網路傳遞效率，也降低來源伺服器的效能壓力，可謂一舉兩得。 當然這是有條件的。CDN 會使用網址來判斷快取是否是相同檔案，假設你的內容以圖片為主，通常來說，當你更換圖片，新舊兩張圖片會有不同網址，被當成兩個不同的檔案，新圖使用新快取，舊快取留著也沒差；但如果你的內容是文字，新舊版文字很可能有相同網址，
Web
OAuth 2 讓網路服務可以存取第三方的受保護資源，因此，有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差，因為 OAuth 2 當初設計目的是「授權」而不是「認證」，兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定，讓開發者可以在 OAuth 2 授權的基礎上，再加入標準的認證流程。在這篇文章中，我會說明授權跟認證的場景有何差異，並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上，我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程，如果你不熟悉，可以先閱讀另外兩篇文章 * OAuth 2.0：
Web
在上一篇的結論中，我們講到開發者通常最想知道，開發 OAuth 2.0 客戶端需要什麼知識。後端工程師要實現 OAuth 2.0，最常見的情境是開發一個客戶端應用，用來存取資源擁有者的受保護資源。因此在這篇中，我們將用 Go 來牛刀小試一番，開發一個網路應用，它會取得使用者同意後，跟 Google 拿取使用者姓名並顯示出來。 註冊客戶端 不是隨便哪個應用都能跟 Google 授權伺服器申請授權，要跟授權伺服器互動，首先要人家願意信任你。因此，在開始寫程式前，要先到 GCP 的 APIs & Services 中註冊客戶端，連結是這個 點選 CREATE CREDENTIALS 並選擇 OAuth client ID，創造一個新的客戶端憑證 我們要開發的是個網路應用，Application type 選
Web
使用者體驗是 B2C 重要的產品面向。通常一個網路服務，會要求使用者註冊帳戶後才能開始使用——以台灣金融保險法規為例，使用者需要建立帳戶後，才能得到報價。站在行銷觀點，註冊會降低用戶的轉換率，因為它需要填寫姓名、暱稱、生日、信箱等資料，步驟相當繁瑣，對行動場景，這百分百是個負面體驗。這讓人不禁想問，這個環節是可以優化的嗎？ 事實上，我們可以合理假設使用者資訊已經存在社群媒體中，例如 Google、Facebook、Twitter、GitHub，而我們需要的只是請求使用者同意，讓我們可以代表使用者，存取社群媒體中受限制的資源。也就是，我們關注的是有沒有一個授權框架，可以讓第三方應用取得對資源的訪問權限。 OAuth 2.0 這就帶到 OAuth 2.0 想要解決的問題。在傳統的 Client-Server 認證架構中，當客戶端要存取伺服端資源時，需要提供使用者的帳號密碼。如果發起請求的是第三方應用，則資源擁有者要將帳號密碼提供給第三方應用。可以想像，你需要請人幫你收信，就需要把家裡鑰匙交給對方。
Web
Protocol buffers，簡稱 Protobuf，是由 Google 設計的結構化序列化資料技術。對網路應用來講，常常需要在不同的伺服端、客戶端之間交換資料，這些資料格式有 XML、JSON 等等之類。XML 特點是完整，便於記載更多的 meta data，但格式複雜，需要更強的效能來解析，傳輸時也需要更多頻寬；而 JSON 是 JavaScript 用於表示物件的語法，相對 XML 來得簡潔，隨著 JavaScript 普及，也變成現在常用的輕量級資料交換格式。 儘管 XML 跟 JSON 在當前網路應用中已經相當常見，但用不同語言開發的伺服端程式，都需要分別實現自己語言的 XML 或 JSON 解析，同時，這些格式定義也是團隊協作的痛點。假設 A 團隊開發某支應用，