DevOps 是一種重視「開發」和「維運」之間溝通合作的文化、運動或慣例。透過自動化「軟體交付」和「架構變更」的流程，使得建置、測試、發布軟體能夠更加快速、頻繁且可靠。
我有時會上課程網站買課，特別是國外的網站，有些課程內容品質高，而且還能無價體驗，我常常在想這在商業上怎麼行得通。Coursera 最近推出預覽功能，某方面來說，也是在宣告長期要往付費走。 網路最大的特點是開放，因為開放，我們看到不可思議的成長，也因為開放，我們有時會很惋惜理想的落幕。 🗞️ 熱門新聞 The Day MOOCs Truly Died: Coursera's Preview Mode Kills Free Learning 很有趣的一篇新聞：Coursera 的預覽模式給了 MOOC 最後一擊。 我對 Coursera 的商業模式不熟，看起來它之前是靠證書與服務營利。很難想像線上課程能用免費支撐這麼久，這幾乎是公益了，將內容鎖在付費牆後比較像可理解的商業行為。 讓我困惑的是，這些年 Coursera 是如何獲利？以及，當時投資人對它的想像是什麼？ The PSF has withdrawn
最近安排旅遊計畫，會到 Brisbane 居住三個月，突然跟熟悉的環境分開，用陌生眼光看待周圍一切，真是個特別的體驗。 世界依然在轉動，只是用了不同速度，反映在每週週報上，是項目變少了，可是內容變長了。 🗞️ 熱門新聞 Flight Recorder in Go 1.25 Go 1.25 開始支援 Flight Recorder。 以前要抓 trace，都是要等到事發後才能抓，有沒有可能事發前抓呢？有，原理很簡單，配置一塊記憶體存放臨時的 trace，如果符合條件，輸出持久化，否則丟棄，這就是 Flight Recorder。 官方給的範例很讚，像 slow request 這類例子，常常是處理 request 時遇到問題，在沒有 Flight Recorder
近期台灣技術圈新聞應該要算 Vibe Coding，無獨有偶的是，HN 上也談到類似的議題：行銷跟技術的界線在哪？哪些東西可以包裝成商品販售，哪些則是應該要有基本的自我審核？ 🗞️ 熱門新聞 Product Hunt is Dead 有位產品創辦人寫了篇 Blog，標題比較聳動：Product Hunt 已死。 我沒特別 Follow Product Hunt，只有偶爾看看，但看完還是五味雜陳。依照文中所說，當你在 Product Hunt 發布產品後，會有一堆人來跟你說需不需要買讚，這讓我想到以前書市買榜的例子。 有人可能會覺得這是行銷，只是對我來說，行銷跟欺騙還是兩回事。我比較不確定的是，假設今天換個場景，改為無傷大雅的善意謊言，我會同意嗎？ ✨ 科技觀點 How to Lead in a Room Full of Experts
Chrome 的判決出來了，Google 不用分拆，只需要保障競爭者能跟它公平競爭。 這個判決有指標意義，所有人都知道 Google 長期利用 Chrome 數據改善它的搜尋引擎，讓其他廠商處於競爭劣勢。要解決這問題，最簡單方式是要求 Google 出售 Chrome，而法官在仔細評估後，給出相當審慎的判決。 我喜歡這種法律見解，具有實務與原則的平衡，法律條文不應該是照本宣科。 🗞️ 熱門新聞 Google Can Continue Paying for Firefox Search Deal, Judge Rules 以前很少注意 Chrome 的新聞，剛好最近判決出來了，看了一些。 最驚訝的是，Mozilla 有 85% 的年度收入是由 Google 給的，如果判決禁止 Google 出錢成為瀏覽器預設的搜尋引擎，將直接影響到 Mozilla
近期開始有人建議用 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
有些產品看到會覺得行不通，有些產品則相反，只要聽到就覺得是個好主意。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 創辦人
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
Observability
點進 OpenTelemetry 的官方文件，它最先映入眼中的句子是「什麼是 OpenTelemetry」。例如，它是套可觀察性框架，用於檢測、蒐集與導出遙測數據；它是開源且供應商中立，能搭配其他的開源工具，像 Jaeger 或 Prometheus；它能將應用程式與系統儀表化，無關是用 Go 還是 .NET 開發，也無關部署在 AWS 還是 GCP 上。 但是身為一名開發者，當下我們想的是：「公司常開發一些沒人要用的功能，聽說 OpenTelemetry 可以提高可觀察性，也許我們應該放棄開發功能，轉頭建立更好的開發環境。」「AWS 常常要不到需要的數據，也許我們應該改用另一套工具，像是 OpenTelemetry，來解決這件事。」我們想像 OpenTelemetry 「應該」要能解決目前面臨到的一些問題，就像在技術的鏡像中尋找願望一樣。 如果已經有在用 Sentry，還需要導入 OpenTelemetry
Go
在雲原生的環境中，程式通常採用容器部署，而不同環境間所需要的配置也會不同，像是開發環境的資料需要與生產環境分離；金絲雀部署要分流生產環境的流量，但不會寫資料到生產環境中；開發環境為了除錯，要印出 level 低的 log；開發環境跟生產環境要拿取的 key vault 的 key 跟 version 不同；等等。在雲原生的時代前，開發人員或維運人員通常會各自維護一份執行的程式，開發在開發環境中驗證後，交付維運部署上線，一次性處理好配置；但在雲原生時代，部署變得越來越頻繁，幾乎不太可能手動管理。這時要把問題倒過來想，不是因應開發出來的程式來設定配置，而是有沒有可能，因應部署會遇到的問題來設計開發？ Store config in the environment Heroku 基於 SaaS(Software-as-a-Service) 實踐，歸納出 12 條雲原生應用的設計原則，稱為 The Twelve-Factor App，其中關於配置，
Go
錯誤處理是 Golang 最常被討論的一個點。這有幾個因素，首先，這跟它「錯誤是值」的設計理念有關，開發者需要在業務流程中穿插錯誤處理，違反關注點分離的原則，當然會引發爭議。另外，在 1.13 前，Golang 標準 errors 庫的表現力有限，當需求較為複雜時，需要開發者自行發明錯誤處理輔助函式。這讓人不禁好奇，Golang 的錯誤處理設計原則是什麼？有沒有比較好的實踐？或者說，我們能不能找到一種方式，優雅地處理錯誤？ 錯誤與異常 先來看看不同人的觀點，Robert Martin 在討論到錯誤處理時，是如此建議的 使用異常替代返回錯誤碼，錯誤處理代碼就能從主路徑代碼中分離出來，得到簡化 他給出的例子是 try { deletePage(page); registry.deleteReference(page.name); configKeys.deleteKey(page.name.
Go
對現代開發者來講，單元測試已經不是可選，而是必備了。單元測試能保護程式碼，讓錯誤提早現形，也能讓重構時更安心。通常我們在評估單元測試的執行狀況時，會用 coverage 當成其中一項指標。當然，coverage 還是會有一些使用的場合跟侷限，當談到專案落地，可能大家會想知道的是，coverage 該怎麼使用，才能幫助到專案？ 開發、審查、回顧 我們先來看看什麼時候會需要知道 coverage？通常依照團隊的工作流程，將它分為三個階段：開發、審查、回顧。每個階段關注的場景會略有不同。 一個一個講。對開發中情形，開發者想知道的是剛寫完的邏輯是否能正常運行，有沒有對應的測試，覆蓋範圍是否已經足夠，如果還有條件分支沒覆蓋到的話，是哪裡？是不是每個錯誤都有處理了。這時最需要的是，codebase 要能 highlight 剛剛講的資訊，幫助開發者一眼掌握。 當開發完成，feature branch 被提交到原始碼管理系統，例如 GitLab，會需要一名
C/C++
以前我們討論過如何在 C/C++ 的專案中，使用 Conan 管理第三方套件。當開發應用程式時，只要用 Conan 就能引入現成的函式庫；但如果角色轉換，開發的不是應用程式，而是函式庫，為方便他人引用，就需要將函式庫打包成 Conan Package，並上傳到 Server。在常見的開發情境中，開發者既需要引用別人的函式庫，也期待自己的函式庫能讓別人引用。 本文會講解如何編寫 Conan 的 Recipe，打包 C/C++ 的函式庫，並在實際的應用程式中引用。 需要 Clone 程式碼的，可以到這裡。 Create Conan Project 既然要打包程式，就需要先建立起專案 mkdir conan-recipe && cd conan-recipe 依照官方說明，可以用 conan