通常開源專案需要面對長期維護的問題，而長期維護需要人力（開發者）物力（伺服器與基礎建設），個人開發者來說是個負擔。有些專案會有企業贊助，有些專案則是替用戶提供顧問與服務來收費維持。 這期選了 Bear 修改授權的新聞，也因為這則新聞，順道看了 Sentry 的授權模式。我們都希望擁有健康的開發生態，而授權條款很大程度左右了這點。 🗞️ 熱門新聞 Bear changes license to Elastic License Blog 平台工具 Bear 修改授權，原本是 MIT，現在改用 Elastic License。 看開發者的說法，原因是有人搭便車，fork 完直接部署成服務賣錢。開源不是免費勞工，這樣確實有點過分。Elastic License 的差別是不准以託管方式提供服務，算是補上這個洞。 相對 AGPL 來講，有時這種個人開發的小型專案，也不追求產業影響力，直接用 EL
Preplexity 跟 Anthropic 等公司開始讓瀏覽器 AI 代理化，資安領域專家 Simon Willison 指出這可能會導致眾多資安漏洞出現。我建議兩邊的意見都可以看看，Anthropic 為了防堵問題，也下過不少功夫，看完後你會比較知道該如何使用 AI 代理。 另外這期特別喜歡 Mike Sun 談台灣的產品經理遇到的挑戰，我現在不太建議新人直接在台灣當產品經理，舞台太小，成長空間有限，會影響日後發展。如果真的對產品很有興趣，可以先到其他地方建立起正確的產品觀後，再回到台灣發展。 🗞️ 熱門新聞 Piloting Claude for Chrome Anthropic 最近推出 Chrome 用的 Claude 插件，但是依照說明文件：「當我們在自主模式中加入安全防護機制後，成功將 23.6%的攻擊成功率降低至 11.2%。」 儘管 Anthropic 特地專文說明它們的防護措施，
隨著 LLM 變成日常的一部分，它們也在改變原有的網路生態。Fastly 的報告顯示，AI 機器人每分鐘可對網站發起高達 39K 次請求，日後造訪網站的，可能大多是機器人，而不是真人。 🗞️ 熱門新聞 Fastly warns AI bots can hit sites 39K times per minute 繼上次 Codeberg 的新聞後，Fastly 出報告指出 AI 機器人正造成網站營運負擔。 大多觀點延續幾個月來的趨勢：「網站負載增長主要並非來自人類訪客，而是代表聊天機器人公司運作的自動爬蟲與抓取程式。 」值得注意的是，AI Fetcher 的數量也在增加中，我猜這多少暗示了用戶搜尋資料的行為正在變化。 Meta 占了所有 AI 流量的 52% 🙄 ，相對下 Anthropic 只佔 3.76%
Ghost Release 新版了！距離上次大版號更新，已經過了 3 年多，這幾年來，創作者經濟變化得很快，Ghost 也嘗試讓創作者更容易經營自己的內容。 我會等 6.0 發布一陣子，穩定下來後才會更新。很期待他們下一步會是什麼。 🗞️ 熱門新聞 Ghost 6.0 Ghost Release 6.0。 兩個重量級更新：支援 ActivityPub，讓 Ghost 可以 Leverage 社群媒體分發渠道；以及內建 Analytics，支援流量分析。這剛好就是兩個我最想要的功能，Great Work。 常說經營內容的痛點在，不知道如何發佈內容，不知道訪客從哪來。當然這都可以用工具協助，例如設定 GA、或者使用 Postiz 等來經營社群，可是我覺得一個好的平台應該要替創作者處理掉這些事，Ghost
以前在開發內容平台產品時，常常想，如果有天我們的使用者要離開平台，他們擁有自由嗎？在現代，數位創作者有點像是佃農，替平台生產內容，可是因為數位落差，他們沒有移動的能力。 隨著時代進步，法規應該要與時俱進，這期選了數位部的公告草案，告訴我們科技與制度可以如何相輔相成。 另外，從本期開始，加入了目錄大綱，希望讓讀者閱讀時能更容易在不同議題間切換。 🗞️ 熱門新聞 社交資料可攜權與互通性 在唐鳳那看到這則消息，最近衛城出版編輯的帳號被無預警停權，引發討論，我自己也常常焦慮，當使用這些便利的平台服務時，我們是不是交出一些沒意識到的權利？ 身為個人，可行的策略是，在發布內容到平台前，先保留一份在自己手中，但這其中的不平等顯而易見。《數位選擇法案》讓我理解到，創作者有機會在一個更好更平等的環境下創作。 我希望台灣也能有這樣的一天。 I gave the AI arms and legs – then it rejected me 在 HN 上看到的新聞，有名開發者發現自己的函式庫被用在 Claude
近期開始有人建議用 Context Engineering 來取代 Prompt Engineering，的確相較於 Prompt，Context 是更精確的用詞。前一期也提到，當 Duolingo 的 CEO 被問到 AI 是否只是模型套皮時，他也說模型一定有影響，但更多是關乎你的 Context。 那麼，業界現在是如何看待 Prompt 的呢？Github Spark 跟 V0 的例子或許能提供一些參考。 🗞️ 熱門新聞 Using GitHub Spark to reverse engineer GitHub Spark GitHub Spark 最近推出公開預覽，讓你可以用 prompt 直接開發應用。 作者用逆向工程，找出 Spark 的 system
現在是 AI 時代，大家都在想怎麼讓自己的產品跟 AI 掛勾，但具體要怎麼做呢？背後的思考有哪些？Duolingo 給出他們自己的觀點。 例如，現在的產品是否只是 AI 套皮，你接收使用者的問題，套上自己的提詞後，拿去給 OpenAI，要它回答你？在現在百家爭鳴的情況下，選擇哪個模型會有差嗎？AI 能帶來新用戶與新營收嗎？等等。 另外本週也選了一篇少數派的文章，談 AI 對 RSS 的影響，對 RSS 未來方向有興趣的人不妨看看。 🗞️ 熱門新聞 Duolingo CEO Luis von Ahn wants you addicted to learning Duolingo CEO 專訪，相當紮實，推薦閱讀。 「對我們來說，
我一直都喜歡看科技公司的願景與文化，原因是，我想知道別人是如何看待自己的使命，又是用什麼方式打造它。願景通常在官網都會有，但想要知道文化，只能聽內部人講講了。 Palantir 前陣子因為它不同於矽谷的文化，而引起很多討論。受此影響，前 OpenAI 的員工在離職創辦公司後，也發文談論他所見到的 OpenAI。最讓我震撼的是，他們幾乎沒有資金困擾，想的都是如何打造出色的 AI 模型。 🗞️ 熱門新聞 Reflections on OpenAI 前員工談 OpenAI 的內部文化。 讀起來最大的感觸是，有些價值觀、觀點、實踐，只有在世界級的公司跟資源下，才有可能建立起來。讓每個團隊各自為政，看誰能端出最好的成果，這對新創（特別是沒拿創投）實在太奢侈了。 我相信這種經歷會變成是「可以帶著走的饗宴」，那種衝擊也是最寶貴的。 AI Open Source Productivity METR 前陣子發了一篇研究，說使用 AI
這星期看了比較多職涯相關的內容，最讓我驚訝的是 Canonical 的面試流程，當我分享這則新聞後，有更多朋友紛紛補充他們的面試經驗：需要經歷三個 Tier，每個 Tier 都有三關，而內容甚至還包括問人選「高中成績」與「大學生活」。 我很難想像一家做 Linux 發行版的公司，會如此草率對待人選，這讓我對他們家的產品有了很大的問號。 🗞️ 熱門新聞 My experience with Canonical's interview process 這是一篇 Canonical 的面試經歷（如果你不知道什麼是 Canonical，就是開發 Ubuntu 的公司）。 整個過程讓人非常驚訝，甚至還需要人選回答「高中成績」，而在面試中做筆記居然是扣分項。我看完後有股移除 Ubuntu 的衝動。真的太扯啦。 What happens when engineers work
最近用了很多 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 創辦人
2023 年 6 月 28 號，rsc 提交 github.com/golang/mock 最後的 commit，他修改 README，加入 Update, June 2023: This repo and tool are no longer maintained. Please see go.uber.org/mock for a maintained fork instead. 更新，2023 年 6 月：此倉庫及工具已不再維護。請改用 go.uber.org/mock
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
Business
某個下雪天，我拖著病體，組裝一套供使用者簡報之用的破爛系統，莎朗進來發現我在操控台前勉強支撐，她便離開了，幾分鐘後，她端著一鍋湯回來，為我倒了一杯，我的精神為之一振。我問她要做的管理工作那麼多，怎麼會有空做這種事，她向我展露她的招牌微笑，說：「湯姆，這就是管理。」 －《Peopleware: Productive Projects and Teams》 有次跟一名職涯顧問聊天。我提到：「我希望透過打造產品來替別人創造價值，如果有很棒的團隊，我相信自己能辦到。」她問：「團隊是必須的嗎？」我愣住了，隨口說：「因為打造產品需要很多不同的職能……還需要可持續性的運作，對，我想團隊是必要的。」事後回想，她的問題很有趣，現代社會好像把「團隊」和「領導」當成是成功的標配，人力市場也一堆團隊主管的職缺，這是一則現代神話嗎？還是某種工業革命時代的遺產？ 身為個人貢獻者的管理者 不是說團隊不重要，只是在現代，你會用不同的角度審視完成目標需要的條件。你想想，如果你是個開發者，自己架網站、
Web
Phil Karlton 有句名言：「計算機科學中只有兩件難事：快取失效和命名。」 想像你在管理網站，因為傳輸速度與伺服器效能問題，網站讀取速度很差，特別是當你的使用者來自地球另外一端，常常需要等待幾秒才能看到畫面，這讓他們的使用體驗大打折扣。身為一名重視使用體驗的開發者，你肯定知道該如何解決這問題，沒錯，答案就是 CDN（內容傳遞網路）。 CDN 可以看成是服務商在全球各地建置伺服器，當你的網站內容（例如圖片、CSS、JavaScript、影片等）流經這些伺服器時，它會保留一份複本（稱為快取），等到下次有人讀取同樣的內容，CDN 會拿出複本給使用者。因為全球各地都有 CDN 節點，美國的使用者可以由美國節點提供，日本的使用者可以由日本節點提供。這樣既加速網路傳遞效率，也降低來源伺服器的效能壓力，可謂一舉兩得。 當然這是有條件的。CDN 會使用網址來判斷快取是否是相同檔案，假設你的內容以圖片為主，通常來說，當你更換圖片，新舊兩張圖片會有不同網址，被當成兩個不同的檔案，新圖使用新快取，舊快取留著也沒差；但如果你的內容是文字，新舊版文字很可能有相同網址，
Business
想搬家想很久，連身邊的朋友都搬完了，我還沒動工。 原因是我懶，我討厭麻煩，每次有人問我吃什麼，我都回答麥當勞。搬家是一件麻煩事，我已經有一份很讚的工作了，全副精神都放在工作上，偶爾才會想起來，反正家什麼時候都能搬，一點也不急，有什麼好急的呢對吧。這樣一拖，就拖到現在。 繼續用 Medium 不好嗎？ 跟男女朋友分手一樣，通常被問到：「對方不好嗎？」得到回答是：「也沒有不好啦，只是……（以下開放填空）。」 從優點開始講吧！Medium 的編輯器很棒，它是 WYSIWYG（所見即所得）類型的編輯器，能讓創作者快速發佈內容，也因為它讓內容發佈更容易了，它開始吸引一批優秀的創作者，這批創作者持續創作內容，又吸引來更多讀者，更多讀者激勵創作者產出內容，內容又再吸引讀者……這形成一個增強迴圈。Medium 還能支援多人協作，拜它時尚簡約的風格所賜，科技公司會使用 Medium 來打造品牌形象，例如我前公司的 Tech Blog
Observability
點進 OpenTelemetry 的官方文件，它最先映入眼中的句子是「什麼是 OpenTelemetry」。例如，它是套可觀察性框架，用於檢測、蒐集與導出遙測數據；它是開源且供應商中立，能搭配其他的開源工具，像 Jaeger 或 Prometheus；它能將應用程式與系統儀表化，無關是用 Go 還是 .NET 開發，也無關部署在 AWS 還是 GCP 上。 但是身為一名開發者，當下我們想的是：「公司常開發一些沒人要用的功能，聽說 OpenTelemetry 可以提高可觀察性，也許我們應該放棄開發功能，轉頭建立更好的開發環境。」「AWS 常常要不到需要的數據，也許我們應該改用另一套工具，像是 OpenTelemetry，來解決這件事。」我們想像 OpenTelemetry 「應該」要能解決目前面臨到的一些問題，就像在技術的鏡像中尋找願望一樣。 如果已經有在用 Sentry，還需要導入 OpenTelemetry
Go
Ian Lance Taylor 在 "Range Over Function Types" 這篇文章聊到 iterator 誕生的原因。如果我們有兩個容器，稱為集合(Set)，想要取得這兩個集合中的不重複元素，加到新的集合中形成聯集，我們可以寫個 Union 函式來執行 // Set holds a set of elements. type Set[E comparable] struct { m map[E]struct{} } // Union returns the union of two sets. func Union[E comparable](s1, s2 *Set[
Web
OAuth 2 讓網路服務可以存取第三方的受保護資源，因此，有些開發者會進一步利用 OAuth 2 來進行使用者認證。但這中間存在著一些語義落差，因為 OAuth 2 當初設計目的是「授權」而不是「認證」，兩者關注的焦點會有些不同。OpenID Connect 是基於 OAuth 2 的一套身份認證協定，讓開發者可以在 OAuth 2 授權的基礎上，再加入標準的認證流程。在這篇文章中，我會說明授權跟認證的場景有何差異，並講解 OpenID Connect 如何滿足認證需求。 因為 OpenID Connect 是建構在 OAuth 2 的基礎上，我會假設這篇文章的讀者已經知道 OAuth 2 的組件與流程，如果你不熟悉，可以先閱讀另外兩篇文章 * OAuth 2.0：
Security
因為 HTTP 是無狀態協定，為了保持使用者狀態，需要後端實作 Session 管理機制。在早期方式中，使用者狀態會跟 HTTP 的 Cookie 綁定，等到有需要的時候，例如驗證身份，就能使用 Cookie 內的資訊搭配後端 Session 來進行。但自從 JWT 出現後，使用者資訊可以編碼在 JWT 內，也開始有人用它來管理使用者身份。前些日子跟公司的資安團隊討論，發現 JWT 用來管理身份認證會有些風險。在這篇文章中，我會比較原本的 Session 管理跟 JWT 的差異，並說明可能的風險所在。 Session 管理 Session 是什麼意思？為什麼需要管理？我們可以從 HTTP 無狀態的特性聊起。所謂的無狀態，翻譯成白話，就是後面請求不會受前面請求的影響。想像現在有個朋友跟你借錢，
Go
從併發的角度來看，Goroutine 跟 Thread 的概念很類似，都是將任務交給一個執行單元來處理。然而不同的是，Goroutine 將調度放在用戶態，因此更加輕量，也能避免多餘的 Context Switch。我們可以說，Go 的併發處理是由語言原生支援，有著更好的開發者體驗，但也因此更容易忘記底層仍存在著輕量成本，當這些成本積沙成塔，就會造成 Out of Memory。這篇文章會從 Goroutine 的生命週期切入，試著說明在併發的情境中，應該如何保持 Goroutine 的正常運作。 因為這篇講的內容會比較底層，如果對應用情境不熟的人，建議先看過同系列 * Goroutine 的併發治理：由錯誤處理談起 * Goroutine 的併發治理：值是怎麼傳遞？ * Goroutine 的併發治理：管理 Worker Pool 再回來看這篇，應該會更容易理解。 Goroutine 的資源使用量 讓我們看個最簡單的例子，假設現在同時開
Go
併發會需要多個 Goroutine 來同時執行任務，Goroutine 雖然輕量，也還是有配置成本，如果每次新的任務進來，都需要重新建立並配置 Goroutine，一方面不容易管理 Goroutine 的記憶體，一方面也會消耗 CPU 的運算效能。這時 Worker Pool 就登場了，我們可以在執行前，先將 Goroutine 配置好放到資源池中，要用時再調用閒置資源來處理，藉此資源回收重複利用。這篇文章會從 0 開始建立 Work Pool，試著丟進不同的場景需求，看看如何實現。 基本的 Worker Pool Worker Pool 的概念可以用這張圖來解釋 Job 會放在 Queue 中送給 Pool 內配置好的 Worker，Worker 處理完後再將結果送到另一個 Queue 內。因為這是很常見的併發模式，
Go
當併發時，每個 Goroutine 可以看成是一個個單獨的個體，他們維護著自己的 Call Stack，彼此互不干涉。如果希望這些默默運行的 Goroutine 攜手完成任務，就要在他們之間建立一種通訊方式。在 Go 中，資訊應該如何被傳遞？其中的權衡又有哪些？這篇文章會介紹 Goroutine 常用的三種值的傳遞方式，以及相關衍生議題。 使用閉包取得值 第一種方式是使用閉包。先來想想輸出應該要長怎樣，假設建立 100 個 Goroutine，每個 Goroutine 會收到一個值並印出來，傳給 Goroutine 的值應該都要不同，最後印出來的結果會是 0 到 99。這裡用 time.Sleep 模擬長時間的處理，用 println 印出值來觀察操作結果。程式碼是 func main() { var wg