目錄
- 專業編程 - 關於此列表
- 原則
- 為此列表做出貢獻
- 必須閱讀的書
- 必讀文章
- 其他一般材料和資源清單
- 主題
- 算法和數據結構
- API設計與開發
- 態度，習慣，心態
- 身份驗證/授權
- 自動化
- 最佳實踐
- 超越軟件工程和隨機
- 偏見
- 商業
- 快取
- 職業發展
- 字符集
- 棋
- 雲
- 代碼評論
- 編碼和代碼質量
- 溝通
- 編譯器
- 配置
- 連續集成（CI）
- 資料庫
- 數據格式
- 數據科學/數據工程
- 偵錯
- 設計（Visual，UX，UI，版式）
- 設計（OO建模，建築，模式，反故事等）
- 開發環境和工具
- Docker
- 文件
- 網際網路
- 編輯和IDE
- 電子郵件
- 工程管理
- 練習
- 實驗
- 功能編程（FP）
- 遊戲開發
- 圖形
- 硬體
- http
- 幽默
- 事件響應（ONCALL，警報，中斷，消防，驗屍）
- 網際網路
- 採訪
- Kubernetes
- 大語言模型（LLM）
- 學習與記憶
- 許可證（法律）
- Linux（系統管理）
- 低代碼/無代碼
- 低級，組裝
- 機器學習/AI
- 數學
- 行銷
- 網絡
- 可觀察性（監視，記錄，例外處理）
- 開源
- 操作系統（OS）
- 過度工程
- 表現
- 個人知識管理（PKM）
- 個人生產力
- 看法
- 隱私
- 解決問題
- 軟件工程師的產品管理
- 項目管理
- 程式設計語言
- 編程範式
- 公開演講（介紹）
- 閱讀
- 重構
- 正則
- 釋放和部署
- 可靠性
- 搜尋
- 安全
- 殼（命令行）
- SQL
- 系統管理
- 系統體系結構
- 可伸縮性
- 站點可靠性工程（SRE）
- 技術債務
- 測試
- 工具
- 類型系統
- 排版
- 版本控制（GIT）
- 職業道德，生產力與工作/生活平衡
- 網絡開發
- 寫作（溝通，博客）
- 演講的資源和靈感
- 保持最新
- 概念
- 我的其他列表
專業編程 - 關於此列表
給我六個小時砍樹，我將花在前四個銳化斧頭。 （亞伯拉罕·林肯）
為程序員提供的全棧資源集合。
此頁面的目的是使您成為更熟練的開發人員。您只會發現我發現真正鼓舞人心或已成為永恆經典的資源。
原則
- 此頁面並不意味著全面。我試圖保持輕便，而不是太壓倒了。
- 文章的選擇是有用的。
- 我不一定同意或認可其中每一個資源中每一條行。他們的作者也是如此：我不認可每個作者所說的一切，並且會說的。
專案:
- ？ ：資源清單
- ： 書
- ？ ：視頻/電影提取/電影/談話
- ？ ：幻燈片/演示
- 祖：必須閱讀
- ？ ： 紙
為此列表做出貢獻
隨時開放公關供款！
我不會添加所有內容：如上所述，我試圖使列表保持簡潔。
必須閱讀的書
我發現這些書令人難以置信：
- 務實的程序員：從《旅行者到掌握：動手實踐》是我讀過的有關編程的最具啟發性和有用的書。
- 代碼完成：一本實用的軟件構建手冊：務實程序員的不錯的補充，為您提供了談論代碼的必要框架。
- 發布它！：這本書超越了代碼，並為您提供了構建可準備生產的軟件的最佳實踐。它將為您提供大約3年的現實經驗。
- 可伸縮性規則：縮放網站的50個原則
- Linux編程接口：Linux和Unix系統編程手冊：在教您幾乎需要了解的有關Linux的所有信息之外，這本書將為您提供有關軟件如何發展的見解，以及具有簡單而優雅的接口的價值。
- 計算機程序的結構和解釋（免費）：SICP是計算機科學中最有影響力的教科書之一（在麻省理工學院撰寫和使用），在CS教育中具有影響力。 Byte建議SICP“對於對自己的職業真正感興趣的專業程序員”。
有一些免費書籍，包括：
- 專業軟件開發：非常完整，是此頁面的好伴侶。免費章節主要集中在軟件開發過程上：設計，測試，代碼編寫等 - 而不是技術本身。
- ？ VHF/自由編程書
- ？電子書發現/自由編程書
必讀文章
- 新軟件工程師的實用建議
- 作為高級工程師
- 在軟件開發中汲取的經驗教訓：其中一篇文章為您提供了多年的來之不易的課程，全部在一篇簡短的文章中。必須閱讀。
- 我學到的東西很難
- 首先規格，然後代碼
- 測試可以使API更好
- 未來的思維是未來的垃圾
- 文件是給您未來自我的情書
- 有時，讓應用程序崩潰比什麼都不做要好
- 了解並遠離貨物邪教
- “工作正確的工具”只是為了推動議程
- 學習基礎功能編程
- 始終在您的日期使用時區
- 始終使用UTF-8
- 創建庫
- 學習監視
- 明確勝於隱式
- 公司尋找專家，但要使通才更長
- 處理用戶數據的最佳安全方法不是捕獲它
- 是時候停下來了，該停止了
- 您負責使用代碼
- 當不是時不要說“完成了”
- 注意人們對您的反應
- 當心微侵略
- 保留“我不知道的事情”列表
- 跡象表明您是一個好程序員（並非這裡的所有內容都很棒 - 其中一些要適得其反）
- 首先實驗的本能
- 與代碼和設計的情感分離
- 渴望修復沒有破裂的東西
- 被難以理解的
- 被迫教
- 廉潔的耐心
- 對完美的破壞性追求
- 平台的百科全書
- 思考代碼
- 在羅馬時，像羅馬人一樣
- 創建自己的工具
- 對層次結構無動於衷
- 因失敗而興奮
- 對情況無動於衷
- 替代脈動做出承諾
- 由經驗驅動
- 7個絕對真理
- 在您職業生涯的早期，您可以在1年內在支持團隊中學習10倍，而不是自己編碼
- 每個公司都有問題，每個公司都有技術債務。
- 在您缺乏現實世界經驗的主題上過分自以為是，這是非常自大的。
- 許多會議會議涵蓋了概念證明，而不是現實世界中的情況。
- 處理遺產是完全正常的。
- 架構比挑剔更重要。
- 在適當的情況下專注於自動化文檔。
- 擁有一些技術債務是健康的。
- 高級工程師除了編程外還必鬚髮展許多技能。
- 我們在某些地區仍然很少。
- 如何構建好軟件
- 基本工程實踐的良好高級摘要。
- 不良軟件的根本原因與特定的工程選擇無關，而與開發項目的管理方式有關。
- 沒有柏拉圖上良好的工程等事情：這取決於您的需求和遇到的實際問題。
- 軟件不應被視為靜態產品，而應作為開發團隊集體理解的生活體現。
- 軟件項目很少失敗，因為它們太小；他們之所以失敗，是因為他們太大了。
- 當心官僚目標將偽裝成問題陳述。如果我們的最終目標是使公民的生活變得更好，我們需要明確承認使他們的生活變得更糟的事情。
- 構建軟件不是避免失敗；這是關於在戰略上盡快失敗，以獲取構建好東西所需的信息。
- 如何成為-10x工程師
- 無效10名工程師的輸出。
- 在技術討論中持有10名工程師人質。
- 浪費10週的云成本工資。
- 浪費400小時在不良建築上的工程。
- 產生400小時的蟲子分診。
其他一般材料和資源清單
其他列表
- Liuchong/Awesome-Road圖：路線圖的精選清單。
圖書
- 冒名頂替者的手冊-30美元。從作者那裡：“沒有CS學位？我也沒有 - 這就是為什麼我寫這本書的原因。”
- 計算機科學書
文章
- MR-MIG/每個程序員都知道：每個軟件開發人員都應該知道的（主要是）技術的東西集合
- 著名軟件開發法律
- 亞馬遜建築商庫
- kdeldycke/Awesome-Falseoody：虛假程序員相信
- hellerve/編程談話
- Techyaks：談話清單
- 談話改變了我對編程的看法
- 每個計算機科學專業都應該知道的
- Kamranahmedse/開發人員-Road圖
- MTDVIO/每個程序員都知道：每個軟件開發人員都應該知道的（主要是）技術知識的集合
- 邁克·阿克頓（Mike Acton）對專業軟件工程師的期望
- 他們沒有教您有關軟件工程的事情
- 領域知識比您的編碼技能更重要
- 代碼是次要的。業務價值是首先。
- 您大多數時候都在不確定性
- 我們高估了我們的短期能力，但低估了我們的長期能力。
- 想要在您的技術職業中有不公平的優勢嗎？消費內容用於其他角色
- 跨職能的理解對於現代科技公司至關重要
- 有助於避免低估其他角色的重要性和困難
- 幫助您在與該角色的人互動中戰略性
- 在十年內教自己編程
公理
- 戒律 - urbit
- 數據比代碼更好。
- 正確性比性能更重要。
- 確定性的節奏啟發式。
- 一百條簡單性比二十條複雜性更好。
- 如果您的抽象正在洩漏，那不是由於宇宙的某些法律。您只是吸取抽象。通常，您沒有足夠狹窄地指定抽象。
- 如果您避免更改一部分代碼，因為他們擔心喚醒其中的惡魔，那麼您將生活在恐懼中。如果您呆在您編寫或熟悉的代碼小部分的舒適範圍內，您將永遠不會編寫傳奇代碼。所有代碼都是由人類撰寫的，可以由人類掌握。
- 如果顯然有正確的方法做某事和錯誤的方法，請以正確的方式進行操作。編碼需要令人難以置信的紀律。
- 獲得正確答案的最佳方法是以錯誤的方式嘗試。
- 練習告訴你，事情是好是壞。理論告訴你為什麼。
- 沒有資格解決問題的原因沒有理由不解決問題。
- 如果您不了解正在使用的系統，則無法控制它。如果沒有人理解系統，則係統正在控制。
- 嵌入式經驗規則
- 改變了我生活的50個想法
- 對10,000小時編程的思考
- 我20年以來作為軟件工程師學到的20件事
課程
- Google Tech Dev指南
- 麻省理工學院的CS教育學期缺失。包括有關外殼，編輯，數據爭吵，git，調試和分析，元編程，安全性和加密的講座。
- 冒險的自學習者尼爾·塞恩斯伯里（Neil Sainsbury）的數學
- JWASHAM/CODING-INTERVIEW-UNIVERSITY：一個完整的計算機科學研究計劃，成為一名軟件工程師。
- 教自己計算機科學：一組最佳的CS資源。
- OSSU/計算機科學：計算機科學的免費自學教育！
主題
算法和數據結構
- 閱讀CLR。您可以在OCW上觀看和下載課程 - 還有更新的課程。
- 或算法設計手冊
- 在Project Euler上嘗試一些算法
- CS 61B 2023春季
其他資源：
- 算法，傑夫·埃里克森（Jeff Erickson）
老實說：算法可能是一個非常乾燥的話題。這個Quora問題列出了一些更有趣的學習替代方案，包括：
- Grokking算法
- 基本算法
- 數據結構可視化
- ？ 15個分類算法在6分鐘內
- 哈希
- 可視化算法
- B-Trees和數據庫索引
示例實現：
- trekhleb/javascript-algorithms：JavaScript中實現的算法和數據結構
- 演算法
分佈式系統中的算法：
API設計與開發
一般休息內容：
- 建築風格和基於網絡的軟件體系結構的設計Roy Fielding（REST的發明者）
- 用於構建Restful HTTP+JSON API的有用資源集合。
- REST API設計的最佳實踐，堆棧溢出博客
- 不受干擾的休息：設計完美API的指南：關於Restful API設計的非常完整的書。
示例指南：
- 微軟的REST API指南
- Zalando Restful API和活動計劃指南
- Google的API設計指南：設計網絡API的一般指南。
- AIP-1：AIP目的和準則
- AIP代表API改進建議，該建議是一項設計文檔，為API開發提供了高級，簡潔的文檔。
更具體的主題：
- 為什麼您應該使用鏈接而非鍵來代表API中的關係，Martin Nally，Google
- “使用鏈接代替外國鍵來表達API中的關係，可以減少客戶使用API所需的信息的數量，並減少客戶和服務器相互耦合的方式。”
- 給我 /事件，而不是webhooks
- 事件可以解鎖急需的Webhook功能，例如允許您的Webhook消費者重播或重置其Webhook訂閱的位置。
- 解鎖Json Patch的力量
態度，習慣，心態
- 掌握編程，肯特·貝克（Kent Beck）。
- 熟練的程序員的特徵
- 編程的道：一組關於編程的寓言。
- 擁有所有權是獲得想要的最有效方法
- 找時間成為更好的開發人員
- 每天十分鐘：亞歷克斯·艾倫（Alex Allain）如何在不到200個小時的時間裡寫一本書，每天寫10分鐘。
- 軟件工程師的護理和餵養（或為什麼工程師脾氣暴躁）
- 在軟件，產品經理，設計師和軟件工程師的thriument派中，只有工程師有望關閉其創意思維並只是生產。
- 工程師和產品經理都傾向於錯誤地思考產品規格或要求等效於宜家的家具手冊。
- 這是使工程師脾氣暴躁的最重要的事情之一：不斷變化的優先事項。
- 即使許多工程師會抱怨產品經理改變主意，但在他們的時間估計中，幾乎沒有人會考慮到這一點。
- 計算機科學計劃並不是要為您在行業中所面臨的任務做好準備。
- 當工程師比所使用的工程師更多時，工程時間最終會遠離發展，並進行計劃，同步和協調。
- 讓工程師參與創作過程
- 為工程師提供創造力的機會。
- 鼓勵時間休息。
- 讓我們代碼
- 明確的感謝
- 產品意識的軟件工程師Gergely Orosz
- 偉大的產品工程師知道，最少可愛的產品需要正確的深度
- 產品有意識的工程師迅速繪製出邊緣案例，並考慮減少對其進行工作的方法：通常帶來不需要工程工作的解決方案
- 參與用戶研究和客戶支持
- 將良好的產品建議帶到桌子上
- 提供產品/工程權衡
- 40年的40堂課，史蒂夫·施拉夫曼（Steve Schlafman）
- 如果您想在最重要的事情上取得進步，則需要決定要讓誰失望。這是不可避免的。
- 您可以進行的最好的投資是自己的教育。永遠不要停止學習。您可以進行的第二好投資是通過真實且有意義的互動來建立網絡。這是您所知道的，您認識的人。
- 您將永遠不會得到您不要求或積極尋求的東西。大膽試試吧！
- 這與隧道盡頭的光無關。這是隧道。每天出現並享受這個過程。
- 一個偉大的隊友總是將組織及其目標置於自己的自身利益之外。
- 選擇您的位置。我們的時間有限，大腦只能處理太多。焦點是關鍵。明智地選擇。
- 每個人都可能在掙扎。善良。有幫助。
- 關於編碼，自我和注意力
- 初學者的思想接受了絕對知識是無限的事實，因此保持得分是浪費時間。
- 掌握只是動量的積累，而不是知識的積累。
- 處理自我分心已經教會我喜歡解決問題的過程。它教會了我愛和尊重學習過程。結果，我更有生產力。我不太焦慮。我是一個更好的隊友。我是一個更好的朋友，也是一個更好的思想家。
- 固定與成長：塑造我們生活的兩種基本思維方式
- 一位出色的軟件工程師是什麼樣的？
- 良好的睡眠，良好的學習，美好的生活
- ？史蒂夫·喬布斯（Steve Jobs）：如果您不尋求幫助，您將不會走很遠
- 編程行情
- 善良
- 從根本上講，善良是要對您對周圍人的影響負責。
- 它要求您注意他們的感受和體貼，以了解您的存在對他們的影響。
- 沃倫·巴菲特（Warren Buffett）說，這個1個簡單的習慣將成功的人與其他所有人分開
- 成功的人和真正成功的人之間的區別在於，真正成功的人幾乎對一切都拒絕。
- 如何幸運？
- 程序員應停止慶祝無能，DHH
- 編程的魔力在很大程度上只是您還不知道的事情。
- 如果您打算使自己的職業編程，那麼認為您不應該走上一些掌握的道路是不好的。
- 沒有速度限制
- 不要等待動力，動力
- 最重要的編碼習慣
- 最重要的編碼習慣
- 每日伸展
- 定期休息
- 不要在深夜代碼
- 改善您的編碼環境
- 有關閱讀所有其他建議論文的新軟件開發人員的建議
- 微服務不是問題。無能的人是
冒名頂替綜合徵被低估了：克服冒名頂替綜合症的許多談話。我說擁抱自我懷疑，每天懷疑自己。在一個快速發展的行業中，您的許多知識每年都會到期，即使您周圍的大多數初級人員都在不斷地烹飪您所沒有的技能；您通過申請新手的決心（甚至恐懼）來保持競爭力。這個跑步機的好處是，每個工程師都在上面：僅僅因為您是冒名頂替者，並不意味著別人比您更應得的，因為他們也冒犯了。您應該為自己提倡，冒險，在事情進展順利時拍打背部，並在您開始建立解決問題的記錄時，相信您的技能和適應性。只要毫無疑問：您只與您解決的最後一個問題一樣好。
丹·海勒（Dan Heller），在軟件中建立職業
我已經學會了永遠不會清空寫作的井，但是總是要在井中仍然有東西時停下來，然後在晚上從餵養牠的泉水中加入。 - 歐內斯特·海明威（Ernest Hemingway）
- Grug brained開發人員：自我意識程序員的習慣。像編程的道，不同的風格。
良好的判斷來自經驗。經驗來自不良判斷。
拖延
- 新聞對您有害 - 放棄閱讀會讓您更快樂，監護人
- 新聞誤導
- 新聞無關緊要
- 新聞沒有解釋力
- 新聞對您的身體有毒
- 新聞增加了認知錯誤
- 新聞抑制思維
- 新聞就像毒品一樣
- 新聞浪費時間
- 新聞使我們被動
- 新聞殺死了創造力
身份驗證/授權
- 在微服務世界中的授權
- 授權邏輯：規則很難，因為它們會隨著時間的流逝而發展
- 哥本哈根書提供了有關在Web應用程序中實施AUTH的一般指南
自動化
最佳實踐
超越軟件工程和隨機
偏見
偏見不僅適用於招聘。例如，在完全不同的背景下，批評某人的代碼寫作時，基本歸因偏差也適用。
商業
- 開發人員的付款101
- 自製計費系統的4個最大問題
- ？建立自己的計費系統的14次痛苦
快取
職業發展
- 高級發展的連接三角形研究瞭如何定義高級工程師。
- 工程師丹·海勒（Dan Heller）成長的十個原則。
- 不要稱自己為程序員帕特里克·麥肯齊（Patrick McKenzie）。
- 擔任工程經理
- 我希望我25歲的職業建議
- 職業是馬拉松，而不是衝刺
- 大多數成功來自重複，而不是新事物
- 如果工作真的很棒，那麼所有有錢人都會有工作
- 管理是關於人的，而不是事物
- 真正聽別人
- 認識到員工是具有有限情感能力的人
- 不要只是與自己年齡的人建立聯繫
- 永遠不要犧牲自己的道德原因
- 認識到失敗是在學習
- 我希望我小時候會得到職業建議
- 不要過多地專注於長期計劃。
- 找到好的思想家，並冷笑您最欣賞的人。
- 在整個壽命中為生產率分配高價值。
- 不要過度優化的事情，而不是您的重中之重。
- 閱讀很多，閱讀周圍人沒有閱讀的東西。
- 認真思考要確定解決問題的問題。
- 閱讀更多歷史。
- 為什麼優秀的開發人員被提升為不幸，Rob Walling。或者為什麼管理層可能不適合您。
- 利用您的職業來幫助解決世界上最緊迫的問題的指南
- 什麼是高級工程師的工作？您不僅要成為個人貢獻者。
- 從編碼訓練營畢業到構建分佈式數據庫
- 閱讀書籍（和論文），而不是博客文章
- 對您的職業軌跡負責
- ？圓潤的工程師包括許多很棒的書籍建議。
- Paradigm Polyglot（學習不同的語言和範式）
- 數據庫polyglot
- 協議Polyglot（最好是TCP/IP和HTTP）
- 熟練構建工具，包裝和分配
- 調試，可觀察性
- 部署，下文和Devops
- 軟件體系結構和擴展
- 能夠編寫玩具編譯器，口譯員和解析器的能力
- 寫玩具遊戲的能力
- 了解算法分析的能力
- 一些職業建議，威爾·拉爾森。
- 您得到的建議是某人試圖綜合他們的經歷，而不是關於世界如何運作的準確陳述。
- 建立聲望的水庫。
- 有些人擅長某些事情，以至於他們目前的角色最終無法替代，這會使他們陷入困境，即使他們是更有趣的人的好候選人。
- 良好的關係將隨時隨地跟隨您。也很糟糕。
- 在您的職業生涯的早期，請盡可能地在盡可能多的不同類型的公司工作。
- 邪惡提示：避免“簡單”的事情
- 終極代碼kata
- 高級軟件工程師的特徵：影響，感知，可見性，影響力，指導
- 軟件工程 - 軟件
- 批判性思考並提出良好的論點
- 掌握基本面
- 專注於用戶，其他所有內容都將遵循
- 學習如何學習
- 如何擁有軟件工程師的成長
- 四十年的程序員
- 您得到的越好，您看起來像其他人越少
- 您可以通過做基礎知識來學習深刻的原則
- 查看其他領域，從其他領域學習
- 小心生產力提示
- 高級工程師將來生活
- 您的職業地圖會是什麼樣？
- 如何在亞馬遜（或其他任何大型公司）取得成功
關於高級工程師：
選擇您的下一個/第一個機會
- 職業決定 - 埃拉德·吉爾（Elad Gil） - 埃拉德（Elad）博客
進入員工工程
- 我在5年內成為了Faang的員工工程師。這些是我一路上學到的14堂課。
- 軟件工程不僅僅是編碼。實際上，編碼是其中的一小部分。
- 管道你的工作
- 向反饋開放並聽。就像，認真地聽著。
- 很難找到很好的反饋；珍惜它。
- 密切關注地平線（但不是兩者）。
- 弄清楚什麼重要，然後讓剩下的一切。
- 比較確實是喜悅的小偷。
- 指導是一件美麗的事情。
- 總的來說，美好的日子不僅要“發生”。
- 建議和指導就是這樣；他們不是規則。
- 指南接觸員工加工程角色，威爾·拉爾森（Will Larson）
字符集
- 絕對最小的每個軟件開發人員絕對，積極地必須了解Unicode和角色集（沒有藉口！）
- 每個軟件開發人員必須了解2023年Unicode的絕對最低限度（仍然沒有藉口！）
棋
（是的 - 國際象棋有自己的部分:)
雲
代碼評論
- 如何進行代碼審查，Google的工程實踐文檔。
- 宣傳後評論：提高開發人員速度的一個有趣的想法（雖然有一些警告）。
- 如何使您的代碼審閱者愛上您
- 首先查看您自己的代碼
- 寫一個清晰的改變主義描述
- 自動化簡單的東西
- 用代碼本身回答問題
- 範圍狹窄的變化
- 單獨的功能和非功能變化
- 對批評的慷慨回應
- 巧妙地徵求丟失的信息
- 將所有關係授予您的評論者
- 最小化審查之間的滯後
- 如何像人類一樣進行代碼評論
- 問HN：您如何審查代碼？：關於黑客的精彩討論，充滿了有趣的想法。
- 馬斯洛的代碼評論金字塔
- 遠程團隊中的代碼審查：非常完整的規則集。
- 默認沒有代碼評論
編碼和代碼質量
- 編寫易於刪除的代碼，不容易擴展
- Egoless編程的十誡
- 清潔代碼：敏捷軟件手工藝手冊，羅伯特·C·馬丁（Robert C. Martin）。描述了許多有用的最佳實踐。有點長。還有一個乾淨的代碼備忘錄。
- 哪種軟件工藝是關於
- 我們厭倦了寫廢話。
- 以後，我們不會接受愚蠢的謊言。
- 我們不會相信快速意味著骯髒的說法。
- 我們將不允許任何人迫使我們表現非專業。
- 命名布爾變量的提示
- 有一個約定，將布爾變量和函數名稱前綴為“ is”或“ has”。
- 嘗試始終使用的是，即使對於復數（
isEachUserLoggedIn也比areUsersLoggedIn或isUsersLoggedIn更好） - 避免自定義前綴（
isPaidFor比wasPaidFor更好） - 避免負面因素（
isEnabled比isDisabled更好）
- 如何編寫無與倫比的代碼
- Kettanaito/naming-cheatsheet ：：綜合語言 - 不合穩定指南命名。 A/HC/LC模式的故鄉。
- ？優質的工程指南
溝通
另請參見寫作部分
- 如何有效地作為開發人員進行交流
- 您在編程時可視化什麼？
編譯器
- 編譯器作者資源頁面
- Kanaka/Mal：MAL-製作LISP
配置
- JSON的配置文件的缺點，Martin Tournoij。
- 無法添加評論
- 引號過多和語法噪音
- 使用DC（聲明配置）來控制邏輯通常不是一個好主意。
- 您的配置很爛？嘗試一種真實的編程語言
連續集成（CI）
資料庫
另請參見SQL部分。
- 簡單的英文介紹CAP定理
- PACELC定理：“如果在分佈式計算機系統中進行網絡分區（P），則必須在可用性（a）和一致性（C）（根據CAP定理）之間進行選擇，但是即使系統，也必須在系統之間進行選擇在沒有分區的情況下正常運行，必須在延遲（L）和一致性（C）之間進行選擇。”
- 零停機時間數據庫遷移（代碼示例正在使用導軌，但這對任何編程語言都非常有用）
- 現代存儲系統背後的算法，ACM隊列
- 讓我們構建一個簡單的數據庫
- 數據庫系統中的讀數，第五版
- 比較數據庫類型：數據庫類型如何發展以滿足不同的需求
- 關係數據庫如何工作
- 使用索引，盧克
- 課程簡介 - 用於開發人員，行星級的MySQL
- 查詢引擎如何工作
- 為什麼您可能應該使用sqlite | Epic Web開發
nosql
- NOSQL模式
- NOSQL數據庫：調查和決策指導
- DynamoDB文檔有一些很棒的頁面：
- 閱讀一致性
- 從SQL到NOSQL
- NOSQL設計DynamoDB
- Redis解釋說
Postgres
- 大量PostgreSQL的安全操作（這適用於PostgreSQL，但也適用於其他DBS）。
- 解釋說，Postgres的交易隔離
- PostgreSQL練習
- Postgres操作備忘單
- 只需使用Postgres即可
- Postgres就足夠了
- Postgres：不要這樣做
- PostgreSQL和UUID作為主要密鑰
數據格式
- 虛假的程序員相信電話號碼，Google的
libphonenumber 。 - 自動完成規則：自動完成字段的粗略規格
- 虛假的程序員相信地址
- 虛假的程序員相信名字
- kdeldycke/Awesome-Falseoody：虛假程序員相信
- 了解UUID，ULID和字符串表示
- 虛假的程序員相信虛假列表
- 澳大利亞/lord_howe是最奇怪的時區
數據科學/數據工程
- 骯髒的十二：在線受控實驗中的十二個常見的度量解釋陷阱
- DataStAckTV/Data-Gradeer-road圖：成為數據工程師的路線圖
- 很棒的數據工程學習路徑
- 現代數據基礎架構的新興體系結構
- 如何超越整體數據湖到分佈式數據網格
- 基於數據湖體系結構的數據平台具有常見的故障模式，從而導致規模未實現的承諾。
- 我們需要將域作為一流的關注，應用平台思維來創建自助數據基礎架構，並將數據視為產品。
- mlops
- Uber的大數據平台：100多個pb具有微小潛伏期
- SQL應該是數據轉換邏輯的默認選擇
偵錯
另請參閱此文檔中的事件響應部分
- 橡皮鴨問題解決
- 橡皮鴨
- 五個
- 五個謊言分析
- 當技術成為模板的一部分時，真正的問題會揭示自己。
- 動作項目可能與根本原因非常遙遠。
- 無限的如何批評五種方法，並提倡一組不同的問題，可以從事件中學習最多。
- 另請參閱：人類錯誤：模型和管理
- “這五個方面的問題是，它被隧道視為對工作方式的線性和簡單的解釋，事件的發展。”
- “人為錯誤成為起點，而不是結論。” （Dekker，2009年）
- “當我們問'如何？'時，我們要敘事。”
- “在決策和行動方面，我們想知道某人做自己所做的事情是有意義的。”
- 在每個“為什麼”步驟中，將只選擇一個答案以進行進一步調查。詢問“如何”鼓勵更廣泛的探索。
- “在大多數其他人類努力中，在事故調查中，我們屬於您對您的視野或wylfiwyf原則的犧牲品。這是一個簡單的認識，即對我們所做的假設的事實的一個簡單認識將在很大程度上看待（您看起來像是什麼樣的），將決定我們實際發現的東西（您找到什麼）。” （Hollnagel，2009年，第85頁）（請參閱Wylfiwyf的圖）
- “可以選擇'根本原因'的最終原因是，它在政治上是可以接受的，因為已確定的原因。在政治上是不可接受的。” （南希·萊維森（Nancy Leveson），工程更安全的世界，第20頁）
- 有限的理性：理性個人將選擇一個令人滿意而不是最佳的決定
- 本文提供了具體的方法和問題，以徵求人們的故事，這將產生更好的見解。
- 您期望發生什麼？
- 如果您當時必須向同事描述情況，您會告訴您什麼？
- 這種情況適合標準方案嗎？
- 您想實現什麼目標？是否同時有多個目標？是否有時間壓力或您能做什麼？
- 請參閱此處的模板
- Linux性能分析60,000毫秒
- HubSpot的驗屍：我從250個中學到了什麼
- 調試雜誌，朱利安·埃文斯（Julian Evans）
- 如果您了解一個錯誤，則可以修復它
- 三十分鐘的規則：如果有人陷入了30分鐘以上的時間，他們應該尋求幫助
- 如何創建最小，可重複的示例，堆棧溢出
- Some ways to get better at debugging, Julia Evans
- Learn the codebase
- Learn the system (eg, HTTP stack, database transactions)
- Learn your tools (eg,
strace , tcpdump ) - Learn strategies (eg, writing code to reproduce, adding logging, taking a break)
- Get experience: according to a study, "experts simply formed more correct hypotheses and were more efficient at finding the fault."
- What exactly is the 'Saff Squeeze' method of finding a bug?
- A systematic technique for deleting both test code and non-test code from a failing test until the test and code are small enough to understand.
- tcpdump is amazing, Julia Evans
- What we talk about when we talk about 'root cause'
Design (visual, UX, UI, typography)
I highly recommend reading The Non-Designer's Design Book. This is a pretty short book that will give you some very actionable design advices.
- If you're working on data, Edward Tufte's The Visual Display of Quantitative Information is considered a classic.
- The Universal Principles of Design will give you enough vocabulary and concepts to describe design challenges into words.
- Book recommendations from HackerNews
- ?Design for Non-Designers
文章：
- 10 Usability Heuristics Every Designer Should Know
- Visibility of System Status
- The Match Between The System And The Real World
- Every system should have a clear emergency exit
- Don't forget that people spend 90% of their time interacting with other apps
- Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, eg a familiar person, recall = deeper retrieval)
- ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
- Help Users Recognize, Diagnose, And Recover From Errors
- How to pick more beautiful colors for your data visualizations
- Visual design rules you can safely follow every time
Typograhy: see "Typography" section
資源：
- ？ bradtraversy/design-resources-for-developers: design and UI resources from stock photos, web templates, CSS frameworks, UI libraries, tools...
Design (OO modeling, architecture, patterns, anti-patterns, etc.)
Here's a list of good books:
- Design Patterns: Elements of Reusable Object-Oriented Software: dubbed "the gang of four", this is almost a required reading for any developer. A lot of those are a bit overkill for Python (because everything is an object, and dynamic typing), but the main idea (composition is better than inheritance) definitely is a good philosophy.
- And their nefarious nemesis Resign Patterns
- Patterns of Enterprise Application Architecture: learn about how database are used in real world applications. Mike Bayer's SQLAlchemy has been heavily influenced by this book.
- Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
- Clean Architecture, Robert C. Martin. Uncle Bob proposes an architecture that leverages the Single Responsibility Principle to its fullest. A great way to start a new codebase. Also checkout the clean architecture cheatsheet and this article.
- Game Programming Patterns: a book about design, sequencing, behavioral patterns and much more by Robert Nystrom explained through the medium of game programming. The book is also free to read online here.
One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.
文章：
- O'Reilly's How to make mistakes in Python
- Education of a Programmer: a developer's thoughts after 35 years in the industry. There's a particularly good section about design & complexity (see "the end to end argument", "layering and componentization").
- Domain-driven design, Wikipedia.
- On the Spectrum of Abstraction ?, Cheng Lou
- The “Bug-O” Notation, Dan Abramov
- Antipatterns
- Inheritance vs. composition: a concrete example in Python. Another slightly longer one here. One last one, in Python 3.
- Composition Instead Of Inheritance
- Complexity and Strategy: interesting perspective on complexity and flexibility with really good examples (eg Google Apps Suite vs. Microsoft Office).
- The Architecture of Open Source Applications
- The Robustness Principle Reconsidered
- Jon Postel: "Be conservative in what you do, be liberal in what you accept from others." (RFC 793)
- Two general problem areas are impacted by the Robustness Principle: orderly interoperability and security.
- Basics of the Unix Philosophy, Eric S Raymond
- Eight Habits of Expert Software Designers: An Illustrated Guide
You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)
資源：
Design: database schema
- A humble guide to database schema design, Mike Alche
- Use at least third normal form
- Create a last line of defense with constraints
- Never store full addresses in a single field
- Never store firstname and lastname in the same field
- Establish conventions for table and field names.
Design: patterns
- KeystoneInterface, Martin Fowler.
- Build all the back-end code, integrate, but don't build the user-interface
- 101 Design Patterns & Tips for Developers
- Python Design Patterns: For Sleek And Fashionable Code: a pretty simple introduction to common design patterns (Facade, Adapter, Decorator). A more complete list of design patterns implementation in Python on Github.
- SourceMaking's Design Patterns seems to be a good web resource too.
- Anti-If: The missing patterns
Design: simplicity
- Simple Made Easy ?, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.
Dev environment & tools
工具
- Glances: An eye on your system
- HTTPie: a CLI, cURL-like tool for humans
- jq: command-line JSON processor
- tmux: terminal multiplexer
- htop: an interactive process viewer for Linux
- htop explained
- 社會
- Visual guide to SSH tunnels
- casey/just: a command runner written in Rust (claims to be better than Makefile)
- Gazr: an opinionated way to define your
Makefile
Article about tools:
- The return of fancy tools
- Simple tools make you think a little more
- Drucker: "I'm not writing it down to remember it later, I'm writing it down to remember it now."
- Frictionless note-taking produces notes, but it doesn't produce memory.
Docker
See also the Python-specific section in charlax/python-education.
- Best Practices Around Production Ready Web Apps with Docker Compose
- Avoiding 2 Compose Files for Dev and Prod with an Override File
- Reducing Service Duplication with Aliases and Anchors
- Defining your
HEALTHCHECK in Docker Compose not your Dockerfile - Making the most of environment variables
- Using Multi-stage builds to optimize image size
- Running your container as a non-root user
- Docker Best Practices for Python Developers
- 使用多階段構建
- Pay close attention to the order of your Dockerfile commands to leverage layer caching
- Smaller Docker images are more modular and secure (watch out for Alpine though)
- Minimize the number of layers (
RUN , COPY , ADD ) - Use unprivileged containers
- Prefer
COPY over ADD - Cache python packages to the docker host
- Prefer array over string syntax
- Understand the difference between
ENTRYPOINT and CMD - Include a
HEALTHCHECK instruction - Whenever possible, avoid using the
latest tag. - Don't store secrets in images
- Use a
.dockerignore file (include **/.git , etc.) - Lint and Scan Your Dockerfiles and Images (eg with
hadolint ) - Log to stdout or stderr
- Docker Containers Security
文件
- Documentation-Driven Development
- Writing automated tests for your documentation: this should be required, IMO. Testing code samples in your documentation ensures they never get outdated.
- ？ Documentation is king, Kenneth Reitz
- 保留一個更改
- Architectural Decision Records (ADR): a way to document architecture decision.
- 記錄架構決策
- joelparkerhenderson/architecture-decision-record: examples and templates for ADR.
- And a CLI tool: npryce/adr-tools
- The documentation system
- Checklist for checklists
- Best practices for writing code comments
- Always be quitting
- Document your knowledge
- Train your replacement
- 代表
- By being disposable, you free yourself to work on high-impact projects.
- Write documentation first. Then build.
- Diátaxis: a systematic approach to technical documentation authoring
- There are four modes: tutorials, how-to guides, technical reference and explanation
- The docs goes into a lot of details about each model.
- Architecture.md
- Two open source projects with great documentation (esbuild and redis)
The palest ink is more reliable than the most powerful memory. -- Chinese proverb
網際網路
- ？ Awesome dotfiles: lots of great dotfiles.
- 我的雜物
文章
- Setting Up a Mac Dev Machine From Zero to Hero With Dotfiles
Editors & IDE
- Sublime Text essential plugins and resources
- Bram Moolenaar (Vim author), Seven habits of effective text editing (presentation). This is about Vim but it contains good lessons about why investing time in learning how to be productive with your text editors pays off.
- VScode is one of the most popular text editors as of writing.
- Visual Studio Code Can Do That?, Smashing Magazine.
- Coding with Character
vim
- ？ vim-awesome
- ？ Vimcasts
- ️ Is Vim Really Not For You? A Beginner Guide
- The first part of a series of 6 articles with lots of detailed and practical tips for using Vim efficiently.
- A Vim Guide for Advanced Users: more advanced shortcuts and commands
- Learning the vi and Vim Editors
- Practical Vim, Drew Neil
- Learn Vimscript the Hard Way
- VimGolf: nice challenges to learn Vim
- Vim anti-patterns
- Learn Vim For the Last Time: A Tutorial and Primer
- Vim Cheat Sheet & Quick Reference
- History and effective use of Vim
- Moving Blazingly Fast With The Core Vim Motions
- micahkepe/vimtutor-sequel: Vimtutor Sequel - Advanced Vim Tutor Lessons
- Vim Racer - An Online Game for VIM Navigation
Feel free to check my vim configuration and my vim cheatsheet.
Other editors:
電子郵件
- Email explained from first principles
- ？ Transactional Email Best Practices
工程管理
Checkout my list of management resources.
練習
The best way to learn is to learn by doing.
- build-your-own-x: compilation of well-written, step-by-step guides for re-creating our favorite technologies from scratch
- Richard Feynman: "what I cannot create, I do not understand"
- The elevator programming game
- Challenging projects every programmer should try, Austin Z. Henley
- Challenging projects every programmer should try: text editor, space invaders, compiler (Tiny Basic), mini OS, spreadsheet, video game console emulator.
- More challenging projects every programmer should try: ray tracer, key-value store web API, web browser, stock trading bot.
- Let's Build a Regex Engine
- Write a time-series database engine from scratch
- 7 GUIs to build to learn fundamental UI programming skills
- A list of programming playgrounds, Julia Evans
- Write more "useless" software
實踐：
實驗
- 8 annoying A/B testing mistakes every engineer should know
Functional programming (FP)
- Goodbye, Object Oriented Programming
- Functional Programming & Haskell ?: some good reasons to learn FP!
- Functional Programming Fundamentals: short introduction to FP and its advantages.
- OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
- OO is not about state. Objects are bags of functions, not bags of data.
- Functional Programs, like OO Programs, are composed of functions that operate on data.
- FP imposes discipline upon assignment.
- OO imposes discipline on function pointers.
- The principles of software design still apply, regardless of your programming style. The fact that you've decided to use a language that doesn't have an assignment operator does not mean that you can ignore the Single Responsibility Principle.
- Parse, don't validate
- Use a data structure that makes illegal states unrepresentable
- Push the burden of proof upward as far as possible, but no further
- Let your datatypes inform your code, don't let your code control your datatypes
- Don't be afraid to parse data in multiple passes
- Avoid denormalized representations of data, especially if it's mutable
- Use abstract datatypes to make validators “look like” parsers
- ？功能編程
- Monads in 15 minutes
- hemanth/functional-programming-jargon: jargon from the functional programming world in simple terms
- The definitive guide to learning functional programming, Exercism
遊戲開發
- Introduction · Joys of Small Game Development
圖形
硬體
- NandGame: build a computer from scratch.
- What Every Programmer Should Know About SSDs
- How To Make A CPU - A Simple Picture Based Explanation
http
- Choosing an HTTP Status Code — Stop Making It Hard
- HTTPWTF
- 10 Surprising Things You Didn't Know About HTTP
- The HTTP crash course nobody asked for
幽默
- The Jeff Dean Facts
- Compilers don't warn Jeff Dean. Jeff Dean warns compilers.
- Unsatisfied with constant time, Jeff Dean created the world's first
O(1/N) algorithm. - Jeff Dean mines bitcoins.在他的腦海。
- The Daily WTF: Curious Perversions in Information Technology
Incident response (oncall, alerting, outages, firefighting, postmortem)
Also see this section on my list of management resources, "Incident response".
Also see the Debugging section in this doc.
- Incident Response at Heroku
- Described the Incident Commander role, inspired by natural disaster incident response.
- Also in presentation: Incident Response Patterns: What we have learned at PagerDuty - Speaker Deck
- The Google SRE book's chapter about oncall
- Writing Runbook Documentation When You're An SRE
- Playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.”
- Using a template can be beneficial because starting from a blank document is incredibly hard.
- The Curse of Knowledge is a cognitive bias that occurs when someone is communicating with others and unknowingly assumes the level of knowledge of the people they are communicating with.
- Make your content easy to glance over.
- If a script is longer than a single line, treat it like code, and check it into a repository to be source control and potentially tested.
- Incident Review and Postmortem Best Practices, Gergely Orosz
- Computer Security Incident Handling Guide, NIST
- Incident Management Resources, Carnegie Mellon University
- Sterile flight deck rule, Wikipedia
- Shamir Secret Sharing It's 3am.
- Site Reliability Engineering and the Art of Improvisation has lots of good training ideas
- Walkthroughs of observability toolsets
- Decision requirements table building
- Team knowledge elicitation
- Asking the question, “Why do we have on-call?”
- Spin the Wheel of Expertise!
Alerting:
- My Philosophy On Alerting
- Pages should be urgent, important, actionable, and real.
- Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
- Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
- Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
- The further up your serving stack you go, the more distinct problems you catch in a single rule. But don't go so far you can't sufficiently distinguish what's going on.
- If you want a quiet oncall rotation, it's imperative to have a system for dealing with things that need timely response, but are not imminently critical.
- This classical article has now become a chapter in Google's SRE book.
- ？ The Paradox of Alerts: why deleting 90% of your paging alerts can make your systems better, and how to craft an on-call rotation that engineers are happy to join.
驗屍
- A great example of a postmortem from Gitlab (01/31/2017) for an outage during which an engineer's action caused the irremediable loss of 6 hours of data.
- Blameless PostMortems and a Just Culture
- A list of postmortems on Github
- Google's SRE book, Postmortem chapter is excellent and includes many examples.
- Human error models and management
- High reliability organisations — which have less than their fair share of accidents — recognise that human variability is a force to harness in averting errors, but they work hard to focus that variability and are constantly preoccupied with the possibility of failure
"Let's plan for a future where we're all as stupid as we are today."
– Dan Milstein
Example outline for a postmortem:
- 執行摘要
- 影響
- Number of impacted users
- Lost revenue
- 期間
- Team impact
- 時間表
- 根本原因分析
- 經驗教訓
- Things that went well
- Things that went poorly
- Action items (include direct links to task tracking tool)
- Tasks to improve prevention (including training)
- Tasks to improve detection (including monitoring and alerting)
- Tasks to improve mitigation (including emergency response)
網際網路
- 互聯網如何工作？
- 網絡如何工作
- Advice to young web developers
採訪
Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.
- System design interview for IT company
- Technical Interview Megarepo: study materials for SE/CS technical interviews
- How to Win the Coding Interview
- I spent 3 months applying to jobs after a coding bootcamp.這是我學到的。
- Top 10 algorithms in Interview Questions
- Interactive Python coding interview challenges
- Tech Interview Handbook
- 完整的計算機科學研究計劃，成為軟件工程師
- Interview advice that got me offers from Google, Microsoft, and Stripe
- A framework for grading your performance on programming interview problems
- Preparing for the Systems Design and Coding Interview, Gergely Orosz
- What I Learned from Doing 60+ Technical Interviews in 30 Days
- System Design Interview Guide for Senior Engineers, interviewing.io
Questions you should ask:
- Questions to ask your interviewer
- Questions to ask the company during your interview
- Interviewing the Interviewer: Questions to Uncover a Company's True Culture
- Twipped/InterviewThis: questions to ask prospective employers
- tBaxter/questions-for-employers: A big collection of useful questions to ask potential employers.
恢復：
- The Red Flags on Your Resume
- 我們在簡歷中尋找的東西
- We look for demonstrated expertise, not keywords
- We look for people who get things done
- We look for unique perspectives
- We care about impact, not meaningless metrics
- Why you shouldn't list certifications on LinkedIn
See also the exercises section in this document.
Kubernetes
- OWASP/www-project-kubernetes-top-ten
- Kubernetes Tutorial for Beginners: Basic Concepts
Large Language Model (LLM)
- What Is ChatGPT Doing… and Why Does It Work?, Stephen Wolfram
- Embeddings: What they are and why they matter
Learning & memorizing
Learn how to learn!
- How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition .
- One Sure-Fire Way to Improve Your Coding: reading code!
- Tips for learning programming
- You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait title, it's actually a good article.
- How to ask good questions, Julia Evans.
- Stop Learning Frameworks
- Learning How to Learn: powerful mental tools to help you master tough subjects
- Why books don't work, Andy Matuschak.
- "As a medium, books are surprisingly bad at conveying knowledge, and readers mostly don't realize it."
- "In learning sciences, we call this model “transmissionism.” It's the notion that knowledge can be directly transmitted from teacher to student, like transcribing text from one page onto another. If only!"
- "By re-testing yourself on material you've learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
- Strategies, Tips, and Tricks for Anki: those advices work for any tool actually
- 添加圖像。 Our brains are wired visually, so this helps retention.
- Don't add things you don't understand.
- Don't add cards memorizing entire lists.
- Write it out. For wrong answers, I'll write it on paper. The act of writing is meditative. I really enjoy this.
- Keep on asking yourself why? why does this work? why does it work this way? Force yourself to understand the root of a topic.
- Cornell Method: when reading a topic, write out questions on the margins to quiz yourself.
- Pretend you have to teach it
- Use mnemonics phrases like PEMDAS for lists and other hard-to-remember topics.
- Delete cards that don't make sense or you don't want to remember anymore.
- Effective learning: Twenty rules of formulating knowledge
- Build upon the basics
- Stick to the minimum information principle: the material you learn must be formulated in as simple way as it is
- Cloze deletion is easy and effective: Kaleida's mission was to create a ... It finally produced one, called Script X. But it took three years
- Graphic deletion is as good as cloze deletion
- Avoid sets
- Avoid enumerations
- Combat interference - even the simplest items can be completely intractable if they are similar to other items. Use examples, context cues, vivid illustrations, refer to emotions, and to your personal life
- Personalize and provide examples - personalization might be the most effective way of building upon other memories. Your personal life is a gold mine of facts and events to refer to. As long as you build a collection for yourself, use personalization richly to build upon well established memories
- Provide sources - sources help you manage the learning process, updating your knowledge, judging its reliability, or importance
- Prioritize - effective learning is all about prioritizing.
- How to Remember Anything You Really Want to Remember, Backed by Science
- Quiz yourself
- Summarize and share with someone else.
- Connect what you just learned to experiences you previously had.
- How To Remember Anything Forever-ish: a comic about learning
- Get better at programming by learning how things work
- How to teach yourself hard things
- Building Your Own Personal Learning Curriculum
- Always do Extra
- Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code.
- Extra must be balanced against Normal Work.
- Extra must be aligned with your Normal Work.
- Against 3X Speed
- Lectures are most effective when they're only a component of the classroom experience
- Learning is about spaced repetition, not binge-reading books
- The Problems with Deliberate Practice
- Why Tacit Knowledge is More Important Than Deliberate Practice
- In Praise of Memorization
- You can't reason accurately without knowledge
- Memorizing organized your knowledge
- It stays with you
- Celebrate tiny learning milestones, Julia Evans.
- Keep a brag document
- You can do a lot "by accident"
- Fixing a bug can be milestone
- Why writing by hand is still the best way to retain information, StackOverflow
- ？ Making Badass Developers - Kathy Sierra (Serious Pony) keynote
- How to study (with lots of cartoons from Calvin & Hobbes!)
- 管理您的時間
- Take notes in class & rewrite them at home
- Study hard subjects first & study in a quiet place
- Read actively & slowly, before & after class
- 做作業
- Study for exams
- Take Exams
- Do research & write essays
- Do I really have to do all this?
- Are there other websites that give study hints?
- 10 Things Software Developers Should Learn about Learning
- ？ Things I Learned the Hard Way, Bryan Cantrill
About flashcards:
- 增強長期記憶
- How to write good prompts: using spaced repetition to create understanding - also includes lots of insightful research papers.
- Effective learning: Twenty rules of formulating knowledge
- Rules for Designing Precise Anki Cards
- Fernando Borretti, Effective Spaced Repetition
- Anki-fy Your Life gets into why it makes sense to invest in your memory.
About Zettelkasten and PKM (personal knowledge management): see Personal knowledge management
Richard Feynman's Learning Strategy:
- Step 1: Continually ask "Why?”
- Step 2: When you learn something, learn it to where you can explain it to a child.
- Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.
Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates
Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang on到。 - 埃隆·馬斯克（Elon Musk）
"Experience is something you don't get until just after you need it." ― Steven Wright
Tell me and I forget.教我，我記得。讓我參與進來。 – Benjamin Franklin
Education is the kindling of a flame, not the filling of a vessel. - 蘇格拉底
That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. – Ralph Waldo Emerson
A wise man can learn more from a foolish question than a fool can learn from a wise answer. – Bruce Lee
A lecture has been well described as the process whereby the notes of the teacher become the notes of the student without passing through the mind of either. - Mortimer Adler
Fools learn from experience. I prefer to learn from the experience of others. — Bismark
Licenses (legal)
- Software Licenses in Plain English
Linux (system management)
- Welcome to Linux command line for you and me!
- Linux Performance, Brendan Gregg
Low-code/no-code
- How Levels.fyi scaled to millions of users with Google Sheets as a backend
Low-level, assembly
- Back to Basics, Joel Spolsky. Explains why learning low level programming is important.
- I think that some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels.
- What's in a Linux executable?
- The Elements of Computing Systems: building a modern computer from first principles (nand2tetris).
- Old pattern powering modern tech
- Demystifying bitwise operations, a gentle C tutorial
- Understanding the Power of Bitwise Operators. No math needed
- Memory Allocation (an interactive article)
- Why does 0.1 + 0.2 = 0.30000000000000004?, Julia Evans (about floating point)
- Putting the "You" in CPU
- x86-64 Assembly Language Programming with Ubuntu
Machine learning/AI
數學
行銷
- goabstract/Marketing-for-Engineers
網絡
- The Great Confusion About URIs
- A URI is a string of characters that identifies a resource. Its syntax is
<scheme>:<authority><path>?<query>#<fragment> , where only <scheme> and <path> are mandatory. URL and URN are URIs. - A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. Eg
mailto:[email protected] . - A URN is a string of characters that uniquely identifies a resource. Its syntax is
urn:<namespace identifier>:<namespace specific string> . Eg urn:isbn:9780062301239
- Everything you need to know about DNS
- Examples of Great URL Design
- Four Cool URLs - Alex Pounds' Blog
Observability (monitoring, logging, exception handling)
See also: Site Reliability Engineering (SRE)
記錄
- Do not log dwells on some logging antipatterns.
- Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
- Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
- Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
- Lies My Parents Told Me (About Logs)
- Logs are cheap
- I can run it better myself
- Leveled logging is a great way to separate information
- Logs are basically the same as events
- A standard logging format is good enough
- Logging - OWASP Cheat Sheet Series
- The Audit Log Wall of Shame: list of vendors that don't prioritize high-quality, widely-available audit logs for security and operations teams.
- Guide on Structured Logs
Error/exception handling
- Error handling antipatterns in this repo.
- Writing Helpful Error Messages, Google Developers' course on Technical Writing
- Explain the problem
- Explain the solution
- Write clearly
指標
- Meaningful availability
- A good availability metric should be meaningful, proportional, and actionable. By "meaningful" we mean that it should capture what users experience. By "proportional" we mean that a change in the metric should be proportional to the change in user-perceived availability. By "actionable" we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfy these requirements…
- ？ Meaningful Availability paper.
- This paper presents and evaluates a novel availability metric: windowed user-uptime
監視
- Google, Site Reliability Engineering, Monitoring Distributed Systems
- PagerDuty, Monitoring Business Metrics and Refining Outage Response
- ？ crazy-canux/awesome-monitoring: monitoring tools for operations.
- Monitoring in the time of Cloud Native
- How to Monitor the SRE Golden Signals
- From the Google SRE book: Latency, Traffic, Errors, and Saturation
- USE Method (from Brendan Gregg): Utilization, Saturation, and Errors
- RED Method (from Tom Wilkie): Rate, Errors, and Duration
- Simple Anomaly Detection Using Plain SQL
- How percentile approximation works (and why it's more useful than averages)
- Implementing health checks
- IETF RFC Health Check Response Format for HTTP APIs
開源
- Non-code contributions are the secret to open source success
操作系統（OS）
- The Linux Programming Interface: A Linux and UNIX System Programming Handbook: already mentioned above.
- Modern Operating Systems, Andrew Tanenbaum, Herbert Bos (not read)
- Operating Systems: Three Easy Pieces (free book, not read)
- Linux Kernel Development, Robert Love. A very complete introduction to developing within the Linux Kernel.
- The 10 Operating System Concepts Software Developers Need to Remember
- Play with xv6 on MIT 6.828
- macOS Internals
Over-engineering
- 10 modern software over-engineering mistakes
- A good example of over-engineering: the Juicero press (April 2017)
- You Are Not Google: the UNPHAT method to avoid cargo cult.
- Don't even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
- eNumerate multiple candidate solutions. Don't just start prodding at your favorite!
- 想太多
- 1st poison: education.
- 2nd poison: marketing.
- 3rd poison: ego
- Solution: Stop trying to connect all the dots ahead of time. Embrace uncertainty and start doing.
- Don't Let Architecture Astronauts Scare You, Joel
- Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
- Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it's interesting because it's peer to peer, completely missing the point that it's interesting because you can type the name of a song and listen to it right away.
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”
— John Gall, General systemantics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometime referred as "Galls' law")
"Software engineering is what happens to programming when you add time and other programmers."
— Rob Pike, Go at Google: Language Design in the Service of Software Engineering
You can't connect the dots looking forward;您只能將它們向後連接。因此，您必須相信這些點會以某種方式在您的未來聯繫。 You have to trust in something — your gut, destiny, life, karma, whatever.這種方法從未讓我失望，這使我的生活有所不同。
- 史蒂夫·喬布斯
表現
- Numbers Everyone Should Know
- 每個程序員都應該知道的延遲號
- Rob Pike's 5 Rules of Programming
- You can't tell where a program is going to spend its time.
- 措施
- Fancy algorithms are slow when n is small, and n is usually small.
- Fancy algorithms are buggier than simple ones
- Data dominates.
- Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust: a great way to learn about measuring performance.
- The Mathematical Hacker
- Four Kinds of Optimisation
Personal knowledge management (PKM)
- Zettelkasten Method
- How to build a second brain as a software developer
- Notes Against Note-Taking Systems
- An interesting contrarian take!
- I am waiting for any evidence that our most provocative thinkers and writers are those who rely on elaborate, systematic note-taking systems.
- I am seeing evidence that people taught knowledge management for its own sake produce unexciting work.
- MaggieAppleton/digital-gardeners
- Notes apps are where ideas go to die.那很好。
個人生產力
Check out this section on my list of management resources, "Personal productivity".
看法
- At 31, I have just weeks to live. Here's what I want to pass on
- First, the importance of gratitude.
- Second, a life, if lived well, is long enough.
- Third, it's important to let yourself be vulnerable and connect to others.
- Fourth, do something for others.
- Fifth, protect the planet.
- Life Is Not Short
- "The most surprising thing is that you wouldn't let anyone steal your property, but you consistently let people steal your time, which is infinitely more valuable." - 塞內卡
隱私
- Privacy Enhancing Technologies: An Introduction for Technologists, Katharine Jarmul, MartinFowler.com
解決問題
- Dealing with Hard Problems
- Invert, always, invert
- Define the problem - what is it that you're trying to achieve?
- Invert it - what would guarantee the failure to achieve this outcome?
- Finally, consider solutions to avoid this failure
- ？ Hammock Driven Development, Rick Hickey
- A classic talk on problem solving.
Product management for software engineers
See the Product management section on my entrepreneurship-resources list of resources.
- Checkout this newsletter produced by Posthog: Product for Engineers
項目管理
See the Project management section on my engineering-management list of resources.
程式設計語言
I would recommend learning:
- JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
- A compiled language (Java, C, C++...).
- A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir...).
- A language that has first-class support for functional programming (Haskell, Scala, Clojure...).
A bit more reading:
- A brief, incomplete, mostly wrong history of programming languages
- 類型
- Resources To Help You To Create Programming Languages
- Effective Programs - 10 Years of Clojure ?, Rich Hickey. The author of Clojure reflects on his programming experience and explains the rationale behind some of Clojure's key design decisions.
- Learn more programming languages, even if you won't use them, Thorsten Ball
- These new perspectives, these ideas and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages, because one of the best things that can happen to you when you're trying to solve a problem is a change of perspective.
- Programming Language Checklist: a fun take on "so you want to build your own language?"
- Static vs. dynamic languages: a literature review
- Polyglot Programming and the Benefits of Mastering Several Languages
- It's not what programming languages do, it's what they shepherd you to
- Ask HN: What do you code when learning a new language/framework?
- The seven programming ur-languages: ALGOL, Lisp, ML, Self, Forth, APL, Prolog
- Lua: The Little Language That Could
- The Montréal Effect: Why Programming Languages Need a Style Czar
- TodePond/DreamBerd: a perfect programming language
只有兩種語言：人們抱怨的語言，也沒有人使用的語言。
-- Bjarne Stroustrup (C++ creator)
List of resources:
- Great Works in Programming Languages
Python
For Python check out my professional Python education repository.
JavaScript
In this repository: check ./training/front-end/
JavaScript is such a pervasive language that it's almost required learning.
- mbeaudru/modern-js-cheatsheet: cheatsheet for the JavaScript knowledge you will frequently encounter in modern projects.
- javascript-tutorial: comprehensive JavaScript guide with simple but detailed explanantions. Available in several languages.
- 30 Days of JavaScript: 30 days of JavaScript programming challenge is a step-by-step guide to learn JavaScript programming language in 30 days.
- Unleash JavaScript's Potential with Functional Programming
垃圾收集
- A Guide to the Go Garbage Collector: a very insightful guide about Go's GC
編程範式
- Imperative vs Declarative Programming, Tyler McGinnis.
- I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it's untraceable while the pattern is being executed.
- ？ Imperative vs Declarative Programming
Public speaking (presenting)
閱讀
- Papers we love: papers from the computer science community to read and discuss. Can be a good source of inspiration of solving your design problems.
- The morning paper: one CS research paper explained every morning.
- The Complete Guide to Effective Reading
- The benefits of note-taking by hand
- The Art of Reading More Effectively and Efficiently
- You should be reading academic computer science papers, Stack Overflow Blog
- How to Remember What You Read
- 記筆記
- Stay focused
- Mark up the book
- Make mental links
- Quit books
- Writing summaries is more important than reading more books
- In 1-2 sentences, what is the book about as a whole?
- What are the 3-4 central questions it tries to answer?
- Summarize the answers in one paragraph each.
- What are the most important things you have learned personally?
- There was an interesting contrarian take in the Hacker News thread: "Once I relaxed and decided, 'If the stuff in this book is good enough, my brain will keep it FOR me' both my satisfaction AND utility of books increased dramatically."
- You Are What You Read, Even If You Don't Always Remember It
- "I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.", Ralp Waldo Emerson
重構
- The Rule of Three, Coding Horror
- Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
- It is three times as difficult to build reusable components as single use components.
- A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
- Refactor vs. Rewrite
- Tripping over the potholes in too many libraries
正則
- The Best Regex Trick
- regex101: build, test, and debug regex
Releasing & deploying
- How we release so frequently
- How to deploy software, Zach Holman
- BlueGreenDeployment, Martin Fowler
- Move fast and break nothing, Zach Holman
- ？ Move fast and don't break things, Google
- Shipping to Production, The Pragmatic Programmer
版本控制
- SemVer - Semantic Versioning
- CalVer - Calendar Versioning
- Semantic Versioning Will Not Save You
- Version numbers: how to use them?
清單
- Production Readiness Checklist, Gruntwork
- Checklist: what had to be done before deploying microservices to production
- Things end users care about but programmers don't: includes colors, formatting, themes, integrations, UX, compatibility, operations.
功能標誌
- Flipping out, Flickr. One of the first articles about feature flags.
- Feature Flags, Toggles, Controls, a website documenting feature flags, from Launch Darkly.
- Feature Toggles (aka Feature Flags), Pete Hodgson, martinFowler.com. Comprehensive article on the topic.
- Deliver new functionality to users rapidly but safely
- Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
- Experiment Toggles are used to perform multivariate or A/B testing.
- Ops Toggles control operational aspects of our system's behavior.
- Permissioning Toggles change the features or product experience that certain users receive.
- Static vs dynamic toggles
- Long-lived toggles vs transient toggles
- Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.
- Feature Flags Best Practices: Release Management, LaunchDarkly
- How we ship code faster and safer with feature flags, Github.
- Flipr: Making Changes Quickly and Safely at Scale, Uber
- Feature flags are ruining your codebase
Testing in production
- Why We Leverage Multi-tenancy in Uber's Microservice Architecture
- Developing in Production
- Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
- Wood's theorem: As the complexity of a system increases, the accuracy of any single agent's own model of that system decreases rapidly.
- The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
- At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
- Testing in Production: the hard parts, Cindy Sridharan
- The whole point of [actual] distributed systems engineering is you assume you're going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
- How can you cut the blast radius for a similar event in half?
- Differentiate between deployment (0 risk) and release
- Build a deploy-observe-release pipeline
- Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
- Test configuration changes just like you test code
- Default to roll back, avoid fixing forward (slow!)
- Eliminate gray failures - prefer crashing to degrading in certain cases
- Prefer loosely coupled services at the expense of latency or correctness
- Use poison tasters (isolate handling of client input)
- Implement per-request-class backpressure
- Have proper visibility from a client/end-user standpoint (client-side metrics)
- Testing in Production, the safe way
- Multi-Tenancy in a Microservice Architecture
可靠性
See also System architecture
圖書：
- 站點可靠性工程
- Written by members of Google's SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.
引號：
Quality is a snapshot at the start of life and reliability is a motion picture of the day-by-day operation. – NIST
Reliability is the one feature every customer users. -- An auth0 SRE.
文章：
- I already mentioned the book Release it!多於。 There's also a presentation from the author.
- Service Recovery: Rolling Back vs. Forward Fixing
- How Complex Systems Fail
- Catastrophe requires multiple failures – single point failures are not enough.
- Complex systems contain changing mixtures of failures latent within them.
- Post-accident attribution to a 'root cause' is fundamentally wrong.
- Hindsight biases post-accident assessments of human performance.
- Safety is a characteristic of systems and not of their components
- Failure free operations require experience with failure.
- Systems that defy detailed understanding
- Focus effort on systems-level failure, instead of the individual component failure.
- Invest in sophisticated observability tools, aiming to increase the number of questions we can ask without deploying custom code
- Operating a Large, Distributed System in a Reliable Way: Practices I Learned, Gergely Orosz.
- A good summary of processes to implement.
- Production Oriented Development
- Code in production is the only code that matters
- Engineers are the subject matter experts for the code they write and should be responsible for operating it in production.
- Buy Almost Always Beats Build
- Make Deploys Easy
- Trust the People Closest to the Knives
- QA Gates Make Quality Worse
- Boring Technology is Great.
- Non-Production Environments Have Diminishing Returns
- Things Will Always Break
- ？ High Reliability Infrastructure migrations, Julia Evans.
- Appendix F: Personal Observations on the Reliability of the Shuttle, Richard Feynman
- Lessons learned from two decades of Site Reliability Engineering
資源：
- ？ dastergon/awesome-sre
- ？ upgundecha/howtheysre: a curated collection of publicly available resources on SRE at technology and tech-savvy organizations
彈性
- ？ The Walking Dead - A Survival Guide to Resilient Applications
- ？ Defensive Programming & Resilient systems in Real World (TM)
- ？ Full Stack Fest: Architectural Patterns of Resilient Distributed Systems
- ？ The 7 quests of resilient software design
- ？ Resilience engineering papers: comprehensive list of resources on resilience engineering
- MTTR is more important than MTBF (for most types of F) (also as a presentation)
搜尋
- What every software engineer should know about search
安全
- Penetration Testing: A Hands-On Introduction to Hacking, Georgia Weidman
- Penetration Testing Tools Cheat Sheet
- A practical guide to securing macOS
- Web Application Security Guide/Checklist
- Reckon you've seen some stupid security things?: everything not to do.
- Checklist of the most important security countermeasures when designing, testing, and releasing your API
- OWASP Cheat Sheet Series: a series of cheat sheets about various security topics.
- Docker安全
- How to improve your Docker containers security
- Secure by Design, a book review by Henrik Warne.
- There is a big overlap between secure code and good software design
- Every domain value should instead be represented by a domain primitive.
- External input needs to be validated before it is used in the system, in the following order: origin, size, lexical content, syntax, semantics.
- Entities should be consistent at creation, have limited operation, shouldn't be sharing mutable objects.
- Three Rs to do every few hours: rotate secrets automatically, repave servers and applications (redeploy on clean footprint), repair vulnerable.
- Don't use exceptions for the control flow.
- OWASP Top Ten Web Application Security Risks
- How to start an AppSec program with the OWASP Top 10
- ukncsc/zero-trust-architecture: Principles to help you design and deploy a zero trust architecture
- ？ Minimum Viable Security
- The Open Software Assurance Maturity Model
- Security by Obscurity is Underrated
- Don't Wanna Pay Ransom Gangs? Test Your Backups, Krebs on Security
- The Beginner's Guide to Passwords
- 密碼遊戲
- Learnings from 5 years of tech startup code audits
- API Tokens: A Tedious Survey: don't use JWT.
- The Six Dumbest Ideas in Computer Security
Training for developers:
- hacksplaining
- Codebashing
- OWASP Security Knowledge Framework
- PagerDuty Security Training
- Gruyere: Web Application Exploits and Defenses
List of resources:
- ？ meirwah/awesome-incident-response: tools for incident response
- ？ Starting Up Security
- ？ decalage2/awesome-security-hardening: security hardening guides, tools and other resources
Shell (command line)
- The case for bash
- ？ alebcay/awesome-shell
- ？ dylanaraps/pure-bash-bible: pure bash alternatives to external processes.
- The Bash Hackers Wiki provides a gentler way to learn about bash than its manages.
- Awk in 20 Minutes
- ？ Linux Productivity Tools
- jlevy/the-art-of-command-line: master the command line, in one page must read
- Minimal safe Bash script template
- Command Line Interface Guidelines
- The Linux Commands Handbook
- How to write idempotent Bash scripts
- Learn bash by playing an adventure
- Effective Shell
- Computing from the Command Line
- What helps people get comfortable on the command line?, Julia Evans
- 6 Techniques I Use to Create a Great User Experience for Shell Scripts
SQL
- SQL styleguide
- Best practices for writing SQL queries
- Practical SQL for Data Analysis
- Reasons why SELECT * is bad for SQL performance
- Animate SQL
- Lost at SQL, an SQL learning game
- Joins 13 Ways
- spandanb/learndb-py: learn database internals by implementing it from scratch.
- SQL for the Weary
系統管理
- ？ kahun/awesome-sysadmin: a curated list of amazingly awesome open source sysadmin resources
系統體系結構
See also Reliability, Scalability
Reading lists:
- ？ donnemartin/system-design-primer: learn how to design large scale systems.準備系統設計採訪。
- ？ A Distributed Systems Reading List
- ？ Foundational distributed systems papers
- ？ Services Engineering Reading List
- ？ System Design Cheatsheet
- karanpratapsingh/system-design: learn how to design systems at scale and prepare for system design interviews
- A Distributed Systems Reading List
部落格:
- High Scalability: great blog about system architecture, its weekly review article are packed with numerous insights and interesting technology reviews. Checkout the all-times favorites.
圖書：
- Building Microservices, Sam Newman (quite complete discussion of microservices)
- 設計數據密集型應用程序
文章：
6 Rules of thumb to build blazing fast web server applications
The twelve-factor app
規模架構系統簡介
The Log: What every software engineer should know about real-time data's unifying abstraction: one of those classical articles that everyone should read.
Turning the database outside-out with Apache Samza
Fallacies of distributed computing, Wikipedia
The biggest thing Amazon got right: the platform
- All teams will henceforth expose their data and functionality through service interfaces.
- Monitoring and QA are the same thing.
Building Services at Airbnb, part 3
- Resilience is a Requirement, Not a Feature
Building Services at Airbnb, part 4
- Building Schema Based Testing Infrastructure for service development
Patterns of Distributed Systems, MartinFowler.com
ConwaysLaw, MartinFowler.com (regarding organization, check out my engineering-management list).
The C4 model for visualising software architecture
If Architects had to work like Programmers
建築模式
- BFF (backend for frontend)
- 斷路器
- Rate limiter algorithms (and their implementation)
- Load Balancing: a visual exploration of load balancing algos
- Good Retry, Bad Retry: An Incident Story: insightful, well-written story about retries, circuit breakers, deadline, etc.
Microservices/splitting a monolith
- Service oriented architecture: scaling the Uber engineering codebase as we grow
- Don't start with microservices in production – monoliths are your friend
- Deep lessons from Google And EBay on building ecosystems of microservices
- Introducing domain-oriented microservice architecture, Uber
- Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
- In small organizations, the operational benefit likely does not offset the increase in architectural complexity.
- Best Practices for Building a Microservice Architecture
- ？ Avoid Building a Distributed Monolith
- ？ Breaking down the monolith
- Monoliths are the future
- "We're gonna break it up and somehow find the engineering discipline we never had in the first place."
- 12 Ways to Prepare your Monolith Before Transitioning to Microservices
- Death by a thousand microservices
可伸縮性
See also: Reliability, System architecture
- Scalable web architecture and distributed systems
- Scalability Rules: 50 Principles for Scaling Web Sites (presentation)
- Scaling to 100k Users, Alex Pareto. The basics of getting from 1 to 100k users.
站點可靠性工程（SRE）
See: Reliability
技術債務
- TechnicalDebt, Martin Fowler.
- Fixing Technical Debt with an Engineering Allocation Framework
- You don't need to stop shipping features to fix technical debt
- Communicate the business value
- Ur-Technical Debt
- Today, any code that a developer dislikes is branded as technical debt.
- Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
- Ur-technical debt is generally not detectable by static analysis.
測試
- ️ Testing strategies in a microservices architecture (Martin Fowler) is an awesome resources explaining how to test a service properly.
- ？ Testing Distributed Systems
Why test:
- Why bother writing tests at all?, Dave Cheney. A good intro to the topic.
- Even if you don't, someone will test your software
- The majority of testing should be performed by development teams
- Manual testing should not be the majority of your testing because manual testing is O(n)
- Tests are the critical component that ensure you can always ship your master branch
- Tests lock in behaviour
- Tests give you confidence to change someone else's code
How to test:
- A quick puzzle to test your problem solving... and a great way to learn about confirmation bias and why you're mostly writing positive test cases.
- Testing is not for beginners: why learning to test is hard. This shouldn't demotivate you though!
- Arrange-act-assert: a pattern for writing good tests
- Test smarter, not harder
Test pyramid:
- The test pyramid, Martin Fowler
- Eradicating non-determinism in tests, Martin Fowler
- The practical test pyramid, MartinFowler.com
- Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test.
- Every single test in your test suite is additional baggage and doesn't come for free.
- Test code is as important as production code.
- Software testing anti-patterns, Kostis Kapelonis.
- Write tests. Not too many. Mostly integration. for a contrarian take about unit testing
- ？ Unit test 2, Integration test: 0
- Testing in the Twenties
- Google Testing Blog: Test Sizes
- Pyramid or Crab? Find a testing strategy that fits, web.dev
End-to-end tests:
- Just say no to more end-to-end tests, Google Testing Blog
- End-to-end testing considered harmful
工具
- DevDocs API Documentation: a repository for multiple API docs (see also Dash for macOS).
- DevChecklist: a collaborative space for sharing checklists that help ensure software quality
- ？ Free for developers: list of free tiers for developments tools and services
- Choose Boring Technology
- Ask HN: Best dev tool pitches of all time?
- A list of /uses pages detailing developer setups, gear, software and configs
The future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age — Lindy's Law
類型系統
- Counterexamples in Type Systems: a library of runtime issues that weren't caught by the type system
排版
- Butterick's Practical Typography
- Typography for Lawyers
- Quick guide to web typography for developers · OlegWock
- Features of your font you had no idea about
Version control (Git)
Learning Git, courses and books:
- Git Book
- Git from the inside out
- Git Tutorials and Training, Atlassian
- Git Immersion
- A Visual Git Reference (a bit more advanced)
- Think Like (a) Git
- Git's database internals I: packed object store: an insightful deep dive from Github
- Oh My Git!: a game to learn git
Cheat sheets:
- Git Cheat Sheet
- git-tips
- Oh Shit, Git!?!
More specific topics:
- 傳統提交
- Git Merge vs. Rebase: What's the Diff?
- ？ Story-telling with Git rebase
- ？ Git Rebase vs. Merge
- ？ 10 Git Anti Patterns You Should be Aware of
- Learn Git Branching: an interactive game
- Fix conflicts only once with git rerere
- Monorepo解釋了
- How to Write a Git Commit Message
- git-worktree: manage multiple working trees attached to the same repository.
Work ethics, productivity & work/life balance
Check out this section on my list of engineering-management resources, "Personal productivity".
網絡開發
In this repository: check training/web-dev/ and ./training/front-end/
Learning guide and resources:
- grab/front-end-guide: a study guide and introduction to the modern front end stack.
- Front-End Developer Handbook 2019, Cody Lindley
- A Directory of design and front-end resources
- ？ codingknite/frontend-development: a list of resources for frontend development
主題：
- 136 facts every web dev should know
- Maintainable CSS
- Things you forgot (or never knew) because of React
- Checklist - The A11Y Project for accessibility
- DevTools Tips
- 67 Weird Debugging Tricks Your Browser Doesn't Want You to Know
- Client-Side Architecture Basics
- Web Browser Engineering: this book explains how to build a basic but complete web browser, from networking to JavaScript, in a couple thousand lines of Python.
Writing (communication, blogging)
➡️ See also my engineering-management list
- Undervalued Software Engineering Skills: Writing Well
- From the HN discussion: "Writing a couple of pages of design docs or an Amazon-style 6 pager or whatever might take a few days of work, but can save weeks or more of wasted implementation time when you realise your system design was flawed or it doesn't address any real user needs."
- Sell Yourself Sell Your Work
- If you've done great work, if you've produced superb software or fixed a fault with an aeroplane or investigated a problem, without telling anyone you may as well not have bothered.
- The Writing Well Handbook
- Ideas — Identify what to write about
- First Drafts — Generate insights on your topic
- Rewriting — Rewrite for clarity, intrigue, and succinctness
- Style — Rewrite for style and flow
- Practicing — Improve as a writer
- Write Simply, Paul Graham
- Writing is Thinking: Learning to Write with Confidence
- It's time to start writing explains why Jeff Bezos banned PowerPoint at Amazon.
- The reason writing a good 4 page memo is harder than "writing" a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related.
- Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.
- Programming and Writing, Antirez
- Writing one sentence per line
- Ask HN: How to level up your technical writing?. Lots of great resources.
- Patterns in confusing explanations, Julia Evans
- Technical Writing for Developers
- Some blogging myths, Julia Evans
- George Orwell's Six Rules for Writing
- Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
- Never use a long word where a short one will do.
- If it is possible to cut a word out, always cut it out.
- Never use the passive where you can use the active.
- Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
- Break any of these rules sooner than say anything outright barbarous.
- Blog Writing for Developers
Guides & classes about technical writing:
- Documentation Guide — Write the Docs
- 原則
- Style guides
- Docs as code
- 標記語言
- 工具
- Technical Writing One introduction, Google
- 文法
- 主動的聲音
- Clear & short sentences
If you're overthinking, write. If you're underthinking, read. – @AlexAndBooks_
Resources & inspiration for presentations
- https://twitter.com/devops_borat
- https://speakerdeck.com/
- 迪爾伯特
- Calvin & Hobbes (search engine)
- https://twitter.com/_workchronicles
Keeping up-to-date
Website and RSS feeds (I use Feedly):
- Hacker News ️
- VentureBeat
- High Scalability: see above
安全：
新聞通訊：
- Bytes (JavaScript)
- PyCoders (Python)
- Posthog
部落格:
概念
詞彙表
- BDD
- 蓋定理
- DDD
- 乾燥
- EAV
- 抓牢
- 吻
- Make it run, make it right, make it fast
- OOP
- 堅硬的
- TDD
- Two Generals' Problem
- YAGNI
My other lists
- engineering-management
- entrepreneurship-resources
- professional-programming
- python-education
