🌗 管理創新專案的藝術
➤ 如何在大型科技公司成功推進創新專案
✤ https://maheshba.bitbucket.io/blog/2025/02/09/2025-skunks.html
本文作者分享了在 Meta 與 Confluent 兩家公司，從小型實驗性專案（skunkworks）到大型工程專案的經驗。作者歸納了成功管理這類專案的九個關鍵原則，強調了團隊合作、避免官僚主義、專注影響力以及清晰溝通的重要性。這些原則旨在幫助工程師和經理在創新專案中建立有效的合作模式，並提升專案成功的機率。
+ 這篇文章很有洞見，提醒我們在追求創新的同時，也要注意團隊管理和溝通的重要性。
+ 作者提出的原則很實用，特別是在大型組織中，可以幫助我們避免不必要的官僚主義和內耗。
#專案管理 #軟體工程 #創新

🌖 效能優化為何是艱鉅任務
➤ 優化工程的四大本質困境
✤ https://purplesyringa.moe/blog/why-performance-optimization-is-hard-work/
本文探討程式碼效能優化的本質困境，從組合性衝突、參數連續性調整到硬體架構限制，揭露優化過程需反覆實測的必然性，並批判編譯器自動優化的神話。
+ 「讀到編譯器把高階語法直接轉成低效指令時，突然理解為何有些程式碼手動展開反而更快」
+ 「混合排序閾值那段完全寫出我的惡夢，每次改演算法都得重跑整套基準測試，根本永劫回歸」
#軟體工程 #效能調校 #程式開發

🌘 需求變化直到停止之時
➤ 穩定需求下的形式化方法價值
✤ https://buttondown.com/hillelwayne/archive/requirements-change-until-they-dont/
本文探討了在軟體開發過程中，需求不斷變化的問題，以及何時應該開始投入形式化方法以確保系統的穩定性和可靠性。作者指出，當需求變化頻繁時，過早進行嚴謹的測試或形式化建模可能是不划算的，因為這些工作可能因需求變更而作廢。然而，一旦需求趨於穩定，形式化方法便能發揮其價值，驗證新系統是否滿足既有需求，並避免引入新的錯誤。文章也以物理學中的相變為例，說明瞭軟體系統在規模和複雜度達到一定程度時，需要進行架構上的變革，而這種變革也可能帶來意料之外的副作用。
+ 這篇文章點出了許多軟體開發者都會遇到的困境，需求總是變來變去，何時該停下來做點穩定的事情？
+ 作者用相變的比喻非常貼切，讓人更容易理解軟體系統發展的階段性和可能遇到的問題。
#軟體工程 #需求管理 #形式化方法

🌗 組態語言的五個層級
➤ 從簡單到複雜：理解組態語言的演進與選擇
✤ https://beza1e1.tuxen.de/config_levels.html
本文探討了組態語言的五個層級，從最簡單的字串儲存於檔案，到複雜的完整程式語言。作者指出，在設計新的組態方案時，瞭解這些層級至關重要，並建議儘可能使用最低層級的語言以保持簡潔，同時警惕在更高層級可能出現的複雜性和循環依賴問題。文章也分享了各層級的範例，例如 Linux 的 `procfs`、INI 檔案、JSON/YAML/XML 等，以及更進階的 XSLT、Jsonnet 和完整程式語言如 Python。
+ 「這篇文章讓我更清楚地瞭解不同組態語言的權衡考量。我一直覺得 YAML 很方便，但作者提到 XML 的工具支援更好，讓我開始重新思考。」
+ 「作者對於避免在組態中使用完整程式語言的警告很有道理。循環依賴確實會讓系統變得難以維護。」
#軟體工程 #組態管理 #程式語言

🌕 Erlang 並非關於輕量級程序與訊息傳遞…
➤ Erlang 的真正核心：行為 (Behaviours)
✤ https://stevana.github.io/erlangs_not_about_lightweight_processes_and_message_passing.html
這篇文章探討了Erlang語言的核心理念。作者原本認為Erlang的重點在於其輕量級程序和訊息傳遞機制，但經過多年的思考，他認為Erlang的真正核心在於「行為」(Behaviours)，即通用的組件。這些行為，例如 `gen_server`、`gen_event` 等，提供了建構可靠分散式系統所需的基礎架構，讓開發者只需專注於業務邏輯的實現，而將並發處理等複雜問題隱藏在行為之中。作者認為這種設計方法不僅簡化了開發流程，更提升了系統的可靠性、可測試性和可維護性。
+ 這篇文章讓我重新思考了Erlang的設計哲學，原來我之前只看到了冰山一角。
+ 我一直覺得Erlang很難學，但瞭解了行為的概念後，感覺好像找到了學習的方向。
#程式語言 #Erlang #分佈式系統 #軟體工程

🌗 如果你的網站也有營業時間呢？
➤ 重新思考網站全天候運行的必要性
✤ https://bobbiechen.com/blog/2022/7/21/what-if-your-website-had-business-hours
本文探討了軟體服務是否可以像實體店面一樣，設定有限的營業時間。作者指出，過度追求24/7全天候運行可能並非總是最佳選擇，並以B&H Photo、Low-Tech Magazine和Kingdom of Loathing等案例說明，某些網站即使有停機時間，並不會因此失去大量收入，反而能有效降低運營成本。作者更進一步思考了雲端服務的成本效益，並提出將伺服器規模縮減至零的可能性，以節省費用。
+ 這篇文章讓我開始思考，我們的網站是否真的需要24/7運行。或許我們可以考慮在某些時段下線維護，以節省成本。
+ 作者的觀點很有意思，尤其是B&H Photo的例子，讓我意識到使用者並非總是需要立即的服務，有時候等待也是可以接受的。
#軟體工程 #網站營運 #成本效益

🌘 PDEATHSIG 幾乎從來都不是你想要的
➤ 一個看似簡單的優化任務，背後隱藏的複雜系統問題。
✤ https://www.recall.ai/post/pdeathsig-is-almost-never-what-you-want
本文記錄了作者在 Recall.ai 嘗試優化 Output Media 功能時遇到的困難。原本預期的簡單任務，卻因為 Chromium 在 Bubblewrap 沙盒環境中隨機終止而陷入困境。作者深入研究 Linux 核心、Bubblewrap 沙盒機制和 Rust Tokio 的線程模型，最終發現問題源於一個名為 `PR_SET_PDEATHSIG` 的 Linux 核心功能，以及對其文件理解的偏差。這個功能設計上是為了在父線程死亡時向子程序發送信號，但實際情況卻導致 Chromium 在父程序仍然運行時被意外終止。最終，移除 Bubblewrap 命令中的 `--die-with-parent` 參數解決了問題。
+ 這篇文章寫得真好，將複雜的技術問題和除錯過程描
#軟體工程 #除錯 #Linux 核心 #Bubblewrap #Tokio

🌗 以「痛苦」為導向的程式設計 – 火星上的思考
➤ 透過實際痛點驅動軟體開發，降低風險並提升效率
✤ http://nathanmarz.com/blog/suffering-oriented-programming.html
這篇文章分享了作者在開發即時計算系統 Storm 的過程中，所採用的「以痛苦為導向的程式設計」方法。這種方法的核心在於：除非你感受到沒有某項技術的痛苦，否則不要去開發它。作者將開發過程分為三個階段：「讓它可行」、「讓它優美」，以及「讓它快速」，並詳細闡述了每個階段的策略和重要性，強調理解問題領域的深度和廣度對於成功開發大型專案至關重要。
+ 這篇文章很有啟發性，提醒我不要過早優化，而是要先專注於解決實際問題。
+ 「以痛苦為導向」這個概念很新穎，讓我重新思考了自己過去的開發方式。
#軟體工程 #程式設計 #架構設計 #Storm

🌗 drawDB：線上資料庫圖表編輯器與 SQL 產生器
➤ 簡化資料庫設計與管理的強大線上工具
✤ https://www.drawdb.app/
drawDB 是一個免費、開源、直觀的線上資料庫設計編輯器、資料模型工具和 SQL 產生器。它無需註冊即可使用，提供多種功能，包括繪製、複製和貼上圖表、匯出 DDL 腳本、反向工程現有模式、自訂工作區、鍵盤快捷鍵、範本以及錯誤偵測。它支援多種關聯式資料庫和物件關聯式資料庫，並提供簡報模式和待辦事項追蹤功能，深受社羣好評。
+ 「這個工具真的太方便了，以前設計資料庫總是覺得很麻煩，現在用 drawDB 簡直快了很多！」
+ 「免費又好用，而且還開源，這真的是開發者福音！」
#開源工具 #資料庫 #軟體工程

🌘 詛咒的Excel：「1/2」+1=45660
➤ Excel的歷史遺留問題與新興AI試算表軟體的解決方案
✤ https://www.quadratichq.com/blog/cursed-excel-datetime-math
這篇文章深入探討了Microsoft Excel在處理日期和時間計算時，因歷史相容性的考量而衍生的奇特行為。作者分享了在開發Quadratic（一款AI試算表軟體）時，逆向工程Excel並發現其底層邏輯中存在許多不合邏輯的“魔術數字”和錯誤。這些錯誤源於早期軟體（Lotus 1-2-3）的錯誤，以及對格里曆的歷史理解不足，導致Excel在某些情況下會產生令人困惑的計算結果。作者強調了Quadratic致力於建立一個更合理、更現代的試算表系統，避免了這些問題。
+ 真是沒想到Excel竟然藏了這麼多奇怪的設定！這篇文章讓我對它產生了全新的看法。
+ Quadratic聽起來很棒，期待能看到更可靠的試算表軟體出現。
#軟體工程 #Excel #數據分析

🌘 非同步 Rust 的確定性模擬測試
➤ 透過模擬測試強化分散式系統的可靠性
✤ https://s2.dev/blog/dst
本文探討了 Bandar Systems 在構建 S2 分散式資料系統時，如何實施確定性模擬測試 (DST) 的經驗。作者分享了將非同步 Rust 程式碼轉為可重複測試的挑戰，包括控制執行、隨機性、時間和 I/O。他們結合了 Turmoil 和 MadSim 工具，最終透過覆蓋關鍵系統呼叫，成功實現了完全的確定性測試，並在 CI 環境中驗證了其有效性。透過 DST，他們已發現並修復了 17 個潛在問題，大幅提升了系統的可靠性。
+ 這篇文章清楚地解釋了確定性測試的重要性，以及在 Rust 這樣的非同步環境中實施的複雜性，對開發分散式系統的工程師很有幫助。
+ 結合 Turmoil 和 MadSim 的方法很有創意，為其他團隊提供了一個很好的參考，可以快速建立可靠的測試流程。
#軟體工程 #測試 #Rust #分散式系統

🌗 軟體工程師的瘋狂：無止盡的技能要求
➤ 全能型工程師的困境與反思
✤ https://0x1.pt/2025/04/06/the-insanity-of-being-a-software-engineer/
本文以幽默且略帶諷刺的口吻，描述了現代軟體工程師所面臨的持續學習壓力。從程式語言、框架、前端技術、後端技術，到DevOps工具、雲端服務，再到管理職位，工程師需要不斷擴展技能樹，卻往往無法真正專精於某一領域。作者質疑這種“全能型”人才模式的可持續性，並以建築業作為對比，指出專業分工的重要性。
+ 真是太真實了！作為一個軟體工程師，我每天都在學習新的東西，感覺自己永遠都跟不上技術的發展速度。
+ 這篇文章點出了軟體工程師的痛點，也提醒我們在追求技術的同時，也要思考專業分工的重要性。
#科技 #職場 #軟體工程

🌘 你沒有時間可以不用測試
➤ 測試：確保軟體品質的基石
✤ https://medium.com/@DougDonohoe/you-dont-have-time-not-to-test-e82bda121d64
文章探討了在軟體開發中，為何許多工程師認為「沒時間測試」的常見現象。作者認為這是一種誤解，測試並非負擔，而是能加速團隊效率、提升程式碼品質的投資。透過闡述測試的本質、重要性以及自動化測試的好處，作者強調即使在資源有限的情況下，也應優先考慮建立測試機制，避免未來更大的問題。文章也分析了工程師抗拒測試的原因，並指出對於建立測試基礎設施所需時間的估計往往過高，而長期效益則被低估。
+ 這篇文章點出了許多工程師的心聲，確實常常為了趕進度而犧牲測試，但看完後讓我意識到，其實不測試反而會付出更大的代價。
+ 作者的觀點很有道理，測試不只是為了找 Bug，更重要的是讓程式碼更可靠、更容易維護。自動化測試的效益真的很驚人！
#軟體工程 #測試 #開發流程

🌗 探究MacPaint的原始碼
➤ 一款劃時代繪圖工具的技術解構
✤ https://ztoz.blog/posts/macpaint-source-code/
本文深入探討了1984年隨蘋果麥金塔電腦一同推出的開創性繪圖程式MacPaint。透過分析其原始碼，研究者們揭示了MacPaint在緩衝區管理和填色演算法上的巧妙設計，充分展現了其與68k平臺的協同性，並有效提升了效能。文章同時評估了程式碼風格與架構的優缺點，以及其可變性，並對一些既有的觀點提出挑戰，強調了MacPaint在數位圖像系統發展史上的重要影響。文章回顧了MacPaint的開發歷程、與其他競爭軟體的比較，以及其對早期圖像繪製技術的貢獻。
+ 讀完這篇文章，讓我對早期電腦軟體的開發有了更深的認識，原來在資源有限的環境下，程式設計師也能創造出如此優秀的作品！
+ 難怪MacPaint能成為經典，它不只是個繪圖工具，更是麥金塔電腦成功的重要推手，也啟發了後來的許多圖像軟體。
#復古科技 #軟體工程 #歷史

🌘 卡夫卡佇列中的訊息卡了十年，最終被傳送，並寫成暢銷小說記錄其遭遇
➤ 科技疏失與數位生命的悲歌
✤ https://nareal.substack.com/p/message-stuck-in-kafka-queue-for
一則訊息在卡夫卡佇列中卡了十年，最終得以傳送，並由這則訊息本身「撰寫」成了一本暢銷小說。故事揭露了新創公司REALTIM在擴展時遭遇的技術問題，以及一個被遺忘的備份伺服器導致訊息堆積的荒謬情況。這本小說不僅講述了訊息本身的經歷，也表達了其他數位訊息的痛苦與掙扎，引發了數位社羣的共鳴，甚至獲得了 Internet Explorer 的好評。
+ 這篇文章太有趣了！雖然是個虛構的故事，但它卻點出了科技公司盲目追求擴展速度時可能犯下的錯誤，以及那些默默承受系統錯誤的「訊息」們。
+ 真的沒想到連 Internet Explorer 也會發表書評！這個故事充滿了黑色幽默，讓人不禁思考數位世界中訊息的意義和價值。
#科技新聞 #軟體工程 #幽默

🌘 VMS 的規模有多大？
➤ 追蹤 VMS 程式碼規模的演變
✤ https://vmssoftware.com/resources/blog/2025-03-31-how-big-is-vms/
本文探討了 VMS 作業系統的程式碼規模問題，作者追溯了過去 35 年來人們對此問題的疑問。透過統計 15 個代表性系統元件在四個不同版本 (V6.2, V7.2, V8.2, V9.2-3) 中的原始碼行數，作者試圖量化 VMS 的規模。 統計結果顯示，僅這 15 個元件的原始碼行數在 V8.2 到 V9.2-3 之間幾乎增三倍，且 C 語言程式碼的比例逐漸增加。 作者也觀察到不同元件的變更幅度不一，並鼓勵讀者分享對未來研究的建議。
+ 「這篇文章很有趣，能讓我更瞭解 VMS 這個老牌作業系統的複雜性。」
+ 「雖然數據只涵蓋了 15 個元件，但已經足以顯示 VMS 的規模和維護成本之高。」
#軟體工程 #作業系統 #VMS

🌗 推出用於安全資料存取的受保護查詢模式
➤ 提升全端應用程式資料安全性的新方法
✤ https://kilpi.vercel.app/blog/2025-03-27-introducing-the-protected-query-pattern/
本文介紹了「受保護查詢模式」（Protected Query Pattern），一種用於簡化和提高全端應用程式中資料存取安全性的方法。傳統上，權限驗證邏輯散落在程式碼各處，容易造成維護困難和潛在的資料外洩風險。受保護查詢模式透過將純查詢函式與授權層分開，提供更明確、可維護且可重複使用的解決方案，並有效解決資料篩選和隱藏等問題。透過使用Kilpi等工具，可以輕鬆實作此模式，提升應用程式的安全性與可讀性。
+ 這篇文章清楚地解釋了在現代應用程式中管理資料權限的挑戰，並提供了一個非常實用的解決方案。
+ 我一直苦苦思索如何更好地處理資料授權，受保護查詢模式看起來是一個非常優雅且有潛力的方案。
#軟體工程 #安全 #資料庫 #權限管理

🌗 所有估算都錯了，但沒有一個是毫無用處的
➤ 軟體估算的本質與應對之道
✤ https://newsletter.techworld-with-milan.com/p/all-estimations-are-wrong-but-none
軟體開發中的估算本質上是不準確的，因為它們是針對未知未來的預測。諸如霍夫斯塔德定律、布魯克斯定律、規劃謬誤等眾多因素都會導致估算失敗。然而，估算依然重要，因為它們能促成計畫並提供價值。文章詳述了影響估算的各種法則與認知偏差，並提出了改善估算準確性的方法，例如追蹤進度、預留緩衝、分解任務、定期更新估算，以及採用如COCOMO模型等工具。此外，文章也介紹了瓦斯科·杜瓦特的「NoEstimates」方法，提倡以產出量和週期時間等實證數據取代傳統的估算方式。
+ 這篇文章提醒我我們團隊經常犯的錯誤，特別是在樂觀評估任務所需時間方面。
+ 我對「NoEstimates」方法很感興趣，也許值得在我們下個專案中嘗試。
#軟體工程 #專案管理 #估算

🌘 AWS 的系統正確性實踐
➤ 從形式化方法到輕量級技術，AWS 如何確保雲端服務的可靠性
✤ https://queue.acm.org/detail.cfm?id=3712057
Amazon Web Services (AWS) 一直致力於提供客戶可完全信任的可靠服務。為此，AWS 採用形式化和半形式化的方法來確保系統的正確性，並不斷演進其測試實踐。透過使用如 TLA+ 和 P 程式語言等工具，AWS 能在開發初期發現並排除潛在的錯誤，並在實施效能優化時保持系統的正確性。同時，AWS 也積極採用輕量級的形式化方法，例如屬性驅動測試、確定性模擬和持續模糊測試，以加速開發並提升服務品質。
+ 這篇文章詳細展示了 AWS 如何一步步提升系統的可靠性，證明瞭形式化方法在大型系統開發中的價值。
+ 令人印象深刻的是 AWS 不只採用傳統的形式化方法，還積極探索輕量級的技術，讓更多工程師可以參與到系統正確性的保障中。
#雲端運算 #軟體工程 #形式化方法

🌕 GitHub - supabase-community/postgres-language-server: 一個針對 Postgres 的語言伺服器
➤ 開發者專案，為 Postgres 提供全面的語言伺服器功能
✤ https://github.com/supabase-community/postgres-language-server
這是一個針對 Postgres 的語言伺服器，著重於開發者體驗和可靠的 SQL 工具，提供自動完成、語法錯誤高亮、類型檢查、程式碼檢查等功能，並致力於擴充和增強核心功能，建立強大且易於訪問的基礎設施。
+ 這個專案對於需要開發與管理 Postgres 資料庫的工程師來說應該很有幫助。
+ 真棒！有人終於開發了這樣一個方便的工具，對開發工作來說應該相當寶貴。
#軟體工程