每個開發人員都需要一個工具包來簡化他們的工作流程、提高生產力並有效地處理一些最複雜的任務。 這可能是開發、測試或專案管理，擁有合適的工具可以決定您的開發過程的成敗。 讓我們來看看我最喜歡的一些，我希望它們也成為您的最愛！  --- **讓我們開始吧！** 👇 1.[翼](https://github.com/winglang/wing) ---------------------------------------  > - 🔥 雲端程式語言 > - 🔥 將基礎架構和執行時間程式碼合併為一種語言的統一程式設計模型 {% cta https://github.com/winglang/wing %} 請star ⭐ Wing {% endcta %} --- 2.[收件匣清零](https://github.com/elie222/inbox-zero) ------------------------------------------------  > - 👉 幾分鐘內清理你的收件匣 > - 👉 時事通訊清理、人工智慧自動化、冷電子郵件攔截器和分析 {% cta https://github.com/elie222/inbox-zero %} 請加註星標 ⭐ 收件匣零 {% endcta %} --- 3.[紙標](https://github.com/mfts/papermark) -----------------------------------------  > - 🚨 開源 DocSend 替代方案 > - 🚨 透過即時分析和白標選項安全地共享推廣資料、銷售提案和其他文件 {% cta https://github.com/mfts/papermarkr %} 請加註星標 ⭐ Papermark {% endcta %} --- 4.[適體資料庫](https://github.com/aptabase/aptabase) -----------------------------------------------  > - 📣 應用程式分析 > - 📣 適用於您選擇的框架！ （JS | NextJS 等） {% cta https://github.com/aptabase/aptabase %} 請加註星標 ⭐ SoapUI {% endcta %} --- 5.[文件](https://github.com/documenso/documenso) ----------------------------------------------  > - 🚀 開源文件簽名 > - 🚀 與所有您喜愛的工具整合 - 發送、連接、接收和嵌入到任何地方 {% cta https://github.com/documenso/documenso %} 請加註星標 ⭐ Documenso {% endcta %} --- 6.[翻轉](https://github.com/flipt-io/flipt) -----------------------------------------  > - ⚡ 現代工程團隊的支援 GitOps 的功能管理平台。 > - ⚡ 遵循現代 DevOps 最佳實踐，例如基於主幹的開發、持續交付和軟體終止開關，而無需重新啟動應用程式。 {% cta https://github.com/flipt-io/flipt %} 請加註星標 ⭐ Flipt {% endcta %} --- 7.[開啟狀態](https://github.com/openstatusHQ/openstatus) ----------------------------------------------------  > **建立信任：** > - ✨ 向使用者展示您的可靠性，並減少客戶服務單的數量。 > **自訂域** > - ✨ 帶上您自己的域名，並為狀態頁面賦予個性化風格。 {% cta https://github.com/openstatusHQ/openstatus %} 請加註星標 ⭐ OpenStatus {% endcta %} --- --- 原文出處：https://dev.to/winglang/developers-toolkit-your-essential-open-source-devtools-hgc
有了正確的函式庫，任何開發人員都可以在他們的應用程式中建立強大的人工智慧功能（如 Ninja 🥷）。 在此列表中，我編譯了 7 個很棒的 AI 庫，您現在可以使用它們（相對）輕鬆地發布功能。 不要忘記為這些圖書館加註星標以表達您的支持。  https://github.com/CopilotKit/CopilotKit --- 1. [CopilotPortal](https://github.com/CopilotKit/CopilotKit) ：建構應用程式原生人工智慧聊天機器人 -------------------------------------------------------------------------------  應用程式內人工智慧聊天機器人助理可以「查看」您目前的應用程式狀態並在前端和後端採取操作。 一組完全可自訂的反應元件和掛鉤以及用於建立 LLM 和您的應用程式之間互動的架構。 定義*useMakeCopilotReadable* 、 *useMakeCopilotActionable*和*CopilotSidebarUIProvider*使其運作。 ``` import "@copilotkit/react-ui/styles.css"; import { CopilotProvider } from "@copilotkit/react-core"; import { CopilotSidebarUIProvider } from "@copilotkit/react-ui"; export default function App(): JSX.Element { return ( <CopilotProvider chatApiEndpoint="/api/copilotkit/chat"> <CopilotSidebarUIProvider> <YourContent /> </CopilotSidebarUIProvider> </CopilotProvider> ); } ``` https://github.com/CopilotKit/CopilotKit --- 2. [RAGxplorer](https://github.com/gabrielchua/RAGxplorer) - 視覺化並探索您的 RAG 文件 ----------------------------------------------------------------------------  RAGxplorer 是一個 Python 工具，用於視覺化機器學習和自然語言處理中的 RAG（檢索增強生成）文件。 以互動方式探索 RAG 流程中使用的文件中的聯繫和內容。 若要設定 RAGxplorer，請在程式碼中定義 RAG 檢查點路徑並安裝指定的依賴項。 ``` import streamlit as st from utils.rag import build_vector_database st.set_page_config(page_title="RAGxplorer", page_icon="🔍") uploaded_file = st.file_uploader("Upload your PDF", type='pdf') query = st.text_input("Enter your query") search = st.button("Search") top_k = st.number_input("Number of Chunks", value=5, min_value=1) st.session_state["chroma"] = build_vector_database(uploaded_file, ...) st.session_state['retrieved_id'] = query_chroma(...) plot_embeddings(...) ``` https://github.com/gabrielchua/RAGxplorer --- 3. [Tavily GPT 研究員](https://github.com/assafelovic/gpt-researcher)- 獲得法學碩士以搜尋網路和資料庫 -----------------------------------------------------------------------------------  Tavilly 可讓您將 GPT 支援的研究和內容產生工具新增至您的 React 應用程式中，從而增強其資料處理和內容建立功能。 ``` # Create an assistant assistant = client.beta.assistants.create( instructions=assistant_prompt_instruction, model="gpt-4-1106-preview", tools=[{ "type": "function", "function": { "name": "tavily_search", "description": "Get information on recent events from the web.", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "The search query to use. For example: 'Latest news on Nvidia stock performance'"}, }, "required": ["query"] } } }] ) ``` https://github.com/assafelovic/gpt-researcher --- 4. [Pezzo.ai](https://github.com/pezzolabs/pezzo) - 開發者優先的 LLMOps 平台 --------------------------------------------------------------------  用於管理 OpenAI 通話的集中平台。 優化您的提示和令牌使用。追蹤您的人工智慧使用情況。 免費且易於整合。 ``` const prompt = await pezzo.getPrompt("AnalyzeSentiment"); const response = await openai.chat.completions.create(prompt); ``` https://github.com/pezzolabs/pezzo --- 5. [DeepEval](https://github.com/confident-ai/deepeval) - 評估 LLM、RAG 和微調性能 --------------------------------------------------------------------------  DeepEval 是一個開源框架，透過將評估視為單元測試來簡化法學碩士的評估。 它提供了評估 LLM 輸出的各種指標，其模組化設計允許開發人員定制他們的評估流程 要使用它，您需要安裝該程式庫、編寫測試案例並執行這些用例來評估您的 LLM 的效能。 ``` Pytest Integration: from deepeval import assert_test from deepeval.metrics import HallucinationMetric from deepeval.test_case import LLMTestCase test_case = LLMTestCase( input="How many evaluation metrics does DeepEval offers?", actual_output="14+ evaluation metrics", context=["DeepEval offers 14+ evaluation metrics"] ) metric = HallucinationMetric(minimum_score=0.7) def test_hallucination(): assert_test(test_case, [metric]) ``` https://github.com/confident-ai/deepeval --- 6. [CopilotTextarea](https://github.com/RecursivelyAI/CopilotKit) - React 應用程式中的 AI 驅動寫作 ----------------------------------------------------------------------------------------  具有 Github CopilotX 功能的任何 React `<textarea>`的直接替代品。 自動完成、插入、編輯。 可以即時或由開發人員提前提供任何上下文。 ``` import { CopilotTextarea } from "@copilotkit/react-textarea"; import { CopilotProvider } from "@copilotkit/react-core"; // Provide context... useMakeCopilotReadable(...) // in your component... <CopilotProvider> <CopilotTextarea/> </CopilotProvider>` ``` https://github.com/RecursivelyAI/CopilotKit --- 7. [SwirlSearch](https://github.com/swirlai/swirl-search) - 人工智慧驅動的搜尋。 ----------------------------------------------------------------------  Swirl Search 是一個開源平台，它使用人工智慧同時搜尋多個資料來源並提供有關這些資料的起草報告。 它可以跨各種來源進行搜尋，包括搜尋引擎、資料庫和雲端服務，並且可以按照儲存庫中提供的安裝說明輕鬆設定。 Swirl Search 建置在 Python/Django 堆疊上，在 Apache 2.0 授權下發布，並作為 Docker 映像提供，使其可供使用者存取和自訂。 https://github.com/swirlai/swirl-search --- 謝謝閱讀！不要忘記為文章加入書籤，給出您的反應，並支持和查看提到的很棒的庫。 乾杯! --- 原文出處：https://dev.to/copilotkit/im-building-an-ai-project-here-are-the-libraries-im-going-to-use-pd0
您經常聽到工程師將 Web Components 與 React 進行比較。這是我的看法。 ### Web 元件是規格。你的網路框架不是。 事實上，我們不需要 JavaScript 框架來使用 Web 元件，這是一個巨大的差異。 Web 元件規格自訂元素 v1、範本、插槽和 ShadowDOM 的部分都可以在瀏覽器中運作。這意味著開始編寫 Web 元件時無需依賴關係！  您不需要大量的 JavaScript 來渲染 UI。 Web 元件對於載入嚴重依賴項阻礙使用者互動的情況（例如行動裝置的情況）非常有用。但還不止於此。事實證明，[Web 元件的靜態網站產生需要最少的工具](https://github.com/readymade-ui/readymade/blob/master/build-gh-pages.js)。 HTML 模組將使處理模板部分的人體工學變得更好。今年，Chrome 團隊宣布 [HTML 模組規格](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ) 即將推出！雖然您可能需要 JavaScript 框架來建立複雜的 Web 應用程式，但靜態網站最好僅使用規範來建置。考慮到網路中有多少內容是靜態內容，這是一個很大的問題。抱歉，React 和蓋茲比。 ### Web 元件是包容性的。 JavaScript 生態系統是如此分散。 Web 元件為每個人提供了使用同一種語言的機會。 React 的支持者很快指出“沒有單一的‘Web 元件社區’，但事實是社區是我們所有人。JavaScript 框架是排他性的。你必須成為俱樂部的一部分。自定義元素則不然。v1. 初學者可以開始編寫它們，而無需學習JavaScript 庫的艱苦戰鬥。 ### Web 元件解決了一個不同的問題。 React 解決了 UI 開發中狀態缺失的問題。自訂元素是無狀態的。您需要將狀態機引入自訂元素。 JavaScript 框架永遠都有空間。 Web 元件提供了一個機會來簡化過去幾年一直在這裡流行的元件範例，以便每個人都可以使用相同的 UI 元件。 Web 元件本質上是在擴展我們日常使用的基本元素時解決人體工學問題。 [甚至在 React 文件中也這麼說。](https://reactjs.org/docs/web-components.html)React 和 Web Components 解決了不同的問題。 ### Web 元件是可互通的。您的 Javascript 框架很可能不是。 在框架中使用自訂元素不僅是可能的，而且應該被視為進入 2020 年的最佳實踐。Javascript 框架應該能夠處理自訂元素，就像處理 DOM 一樣。讓 Web 元件與 JavaScript 框架配合使用有許多怪癖。 React 有一些問題，但 React 團隊表示[他們將考慮與規範緊密整合](https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3/)。 Angular 不支援自訂內建元素的部分規格。 Angular 提供了對自主自訂元素的支持，甚至可以使用 Angular Elements 編譯它們。 Vue 與自訂元素具有相當的互通性，但是如果您遇到問題，使用 Vue 編碼的人請在這裡留言。有一些解決方法可以解決整合 Web 元件所產生的問題，但 JavaScript 框架還需要做一些工作來確保完整的自訂元素 v1 規範正常運作。 ### Web 元件是 a11y。 客製化的內建元素可讓您擴展按鈕、輸入等原生元素，並選擇和實現您自己的功能。透過擴充具有可存取性特徵的元素，您可以免費獲得這些功能。通常，在使用 JavaScript 框架建立 UI 元件時，您必須複製輔助功能。 ### 教育和網路工程存在問題。 在過去十年流行的程式碼學院中，我們忘記了詳細說明規格並直接跳入 JavaScript 框架。即使是入門級課程也可以包括接觸 React。這對於只想讓我們「使用平台」的 JavaScript 框架來說是有利的，但它留下了一個空白，即初級工程師缺乏我們所使用的平台的知識：HTML、CSS 和 JavaScript。 Web Components 透過提供每個人都可以學習和使用的規範來解決這個問題。 ## 我們就不能好好相處嗎？ 即使對於初學者來說，學習 HTML 規範也很容易。讓每個瀏覽器和函式庫都同意並支援規範是很困難的。 HTML 是一個動態文件，並且隨著時間的推移而不斷變化。 [Apple 拒絕](https://github.com/w3c/webcomponents/issues/509#issuecomment-230700060) 在 Safari 中實作自訂的內建元素規格。自從 Microsoft 在 Edge 中遷移到 Chromium 以來，所有最受歡迎的常青瀏覽器都實作了自訂元素 v1。我們只需要更好地合作，Web 元件可以為 2020 年代實現 UI 元件提供可持續的範例。  這並不意味著您現在無法開始使用 Web 元件。對於不支援此規格的瀏覽器，存在 [Polyfills](https://www.webcomponents.org/polyfills/)。 我們應該共同努力，確保 Web 元件進入開發工作流程。從前端 Web 開發教育的一開始到最複雜的 Web 應用程式 Web 元件都有可能簡化 UI 元件開發、提供開箱即用的輔助功能，甚至減少建立 UI 所需的程式碼量。是時候我們釋放這種潛力了，而不是爭論哪個 JS 框架更適合提供元件範例。 JavaScript 框架將繼續擅長其最擅長的領域：狀態管理、提供架構模式和方便的工具。 Web 元件將繼續存在。我們可以共同努力，讓網路變得更美好。 --- 原文出處：https://dev.to/steveblue/it-s-not-about-web-components-vs-react-5137
#RAG簡介 作為開發人員，您今天可以學到的最有價值的技能之一是學習如何使用大型語言模型 (LLM) 建立檢索增強生成 (RAG) 應用程式。 ## 為什麼？ 因為世界上有超過 64 ZB 的資料，這甚至不包括書籍或實體文件等實體資料。 （供您參考，1澤字節是一兆千兆位元組。） 不僅如此，全球90%的資料都是在過去兩年建立的，而且資料量每兩年就會翻倍。基本上，公司都在海量的資料中游泳，而且這些資料每天都在變得越來越大。 公司將如何存取和使用所有這些資料？ 現在每個人都聽說過使用檢索增強生成（RAG）來透過人工智慧尋找資訊。能夠存取和使用不斷增長的資料量是每個公司都需要的關鍵技能。 即使您知道 RAG 基本上是描述將文件或知識連結到 LLM 的工作流程的簡寫方式，許多開發人員自己（還）還沒有嘗試或試驗過這一點。 網路上充滿了圖書館列表，但如何開始呢？ 以下是幫助您開始使用 RAG 的最佳庫的簡短清單。 --- # 1. [LLMWare](https://github.com/llmware-ai/llmware) 在LLMWare中，您可以上傳文件，並透過幾行程式碼開始檢索資訊。它處理 RAG 所需的整個過程：文件攝取、解析、分塊、索引、嵌入、儲存到向量資料庫以及連結到 LLM 以檢索答案。 LLMWare 被設計為整合和端到端，因此所有這些步驟都可以開箱即用。它組裝了所有部件，因此您無需這樣做。 LLMWare 使其非常簡單且易於上手： - 只需幾行程式碼即可透過端到端範例實現 RAG 工作流程 - 建立庫並無縫載入文件 - 輕鬆產生嵌入 - 輕鬆進行語意搜尋 - 利用任何 Hugging Face 模型或 GPT-4 等封閉源模型來回答資料中的問題 - 範例包括無需 GPU 的 RAG 模型 https://github.com/llmware-ai/llmware  --- # 2. [MongoDB](https://github.com/mongodb/mongo) MongoDB 是一種廣泛使用的開源 NoSQL 資料庫程式。它屬於以文件為導向的資料庫類別，這意味著它以類似於 JSON 文件的格式儲存和組織資料。 MongoDB 的設計具有靈活性和可擴展性，使其適合各種應用程式和行業。 資料庫（如 MongoDB）是 RAG 中非常重要的一步，因為它們在嵌入之前儲存從文件或知識庫中提取的訊息，包括重要的元資料。 https://github.com/mongodb/mongo  --- # 3. [Milvus 向量資料庫](https://github.com/milvus-io/milvus) Milvus 是一個開源向量資料庫，旨在為嵌入相似性搜尋和人工智慧應用程式提供支援。 Milvus 讓非結構化資料搜尋更容易存取，無論部署環境如何，都可以提供一致的使用者體驗。 Milvus DB，或類似的向量 DB，是 RAG 中至關重要的一步。它是存儲向量嵌入以進行相似性搜尋的地方。該資料庫允許人們用自然語言提出問題並檢索相關結果。如果沒有良好的嵌入和向量資料庫，LLM 模型將無法接收正確的文字區塊來讀取。 https://github.com/milvus-io/milvus  --- # 4. [擁抱臉](https://github.com/huggingface) 如果你還沒去過 Hugging Face，你真的應該去看看。這是所有開源模型的去處，並且可以單槍匹馬地將世界從人工智慧壟斷中拯救出來。就像 Github 用於開源專案一樣，Hugging Face 用於開源模型。有超過 450,000 個模型，所有模型都免費供任何想要使用它們的人使用。 Hugging Face 的 Transformers 庫是首選庫 提供數千個預訓練模型來執行不同模式（例如文字、視覺和音訊）的任務。 這些模型可應用於： - 文本，用於文本分類、資訊提取、問答、摘要、翻譯和文本生成等任務，支援 100 多種語言。 - 影像，用於影像分類、物件偵測和分割等任務。 - 音頻，用於語音辨識和音頻分類等任務。 Transformer 模型還可以組合執行多種模式的任務，例如表格問答、光學字元辨識、從掃描文件中提取資訊、視訊分類和視覺問答。 https://github.com/huggingface  --- #5. [Llama.cpp](https://github.com/ggerganov/llama.cpp) 沒有GPU？沒問題！ Llama.cpp 來救援！ llama.cpp 的主要目標是在 MacBook 上使用 4 位元整數化來執行 LLaMA 模型。 * 無依賴的純 C/C++ 實現 * Apple Silicon 一等公民 - 透過 ARM NEON、Accelerate 和 Metal 框架進行最佳化 * 對 x86 架構的 AVX、AVX2 和 AVX512 支持 * 混合F16/F32精度 * 支援2位、3位、4位、5位、6位和8位整數化 * CUDA、Metal 和 OpenCL GPU 後端支持 一旦量化，更大的模型就可以在 CPU 上執行，而效能損失很小。尋找 GGUF 版本的模型來嘗試使用 LLMWare 或其他 RAG 工作流程。 https://github.com/ggerganov/llama.cpp  --- 這是幫助您開始使用 RAG 的非常基本的概述。如果您想要一個讓所有這些庫無縫協作的一站式整合解決方案，請造訪 LLMWare 的 GitHub 庫，找到 50 多個優秀範例來幫助您入門。 [在不和諧中找到我們](https://discord.gg/fCztJQeV7J) - 我們很樂意聽到您的來信！ --- 原文出處：https://dev.to/llmware/top-5-beginner-friendly-open-source-libraries-for-rag-1mhb
所以我現在已經進入 Web 開發大約 3 年了，專業也有一年多了，這是我處理一個與資料庫查詢最佳化相關的問題的時候，我不是 SQL 專家，我可以得到這份工作完成。沒有花哨的查詢、觸發器、預存程序等。無論如何，我不得不穀歌搜尋最後一個。 長話短說..我們的 ORM (TypeORM) 把我們搞砸了.. ## 免責聲明： 這並不是要誹謗 TypeORM 或任何 ORM。它們是為其建置目的而設計的特殊工具。我在最後附加了一些參考連結，這些連結是人們面臨類似問題的公開討論。無論如何，讓我們繼續這篇文章。 ## 問題！ 我們的提交表有超過 70 萬筆記錄，表現非常糟糕。從表中取得資料的最長時間超過 6 秒。  查詢相當簡單。我們所擁有的只是 4 個連接、幾個 where 子句（大約 4 個）、排序（在created_at time 字段上的 DESC）、限制和跳過。 ## 根本原因分析.. 導致我們的提交表大幅放緩的幾個因素如下：- - **索引** - 對用於連接表的欄位進行不正確的索引或未進行索引。 - **不必要的連接** - 我們的查詢中有一些不必要的連接，可以將其刪除以獲得更多效能。 - **空字串錯誤** - 我們程式碼中的一個錯誤，如果沒有為這些列提供使用者輸入，我們將與作為查詢的 where 條件一部分的所有列的空字串 (“”) 進行比較。 - **ORM** - ORM 正在執行一個超級愚蠢的查詢來獲取資料。 這些是我在檢查程式碼和資料庫模式以及分析正在執行以獲取所需資料的查詢時發現的精確點。 ## 對提到的每個問題進行分析和測試。 ###<u>原因 1：索引</u> 在進行了一些谷歌搜尋並閱讀了人們的類似問題後，我發現我們的問題並不是那麼大。人們正在為數百萬行而苦苦掙扎，而我們的只是其中的一小部分，所以一定是我們做錯了什麼。 早期解決這些問題的社區提出了許多建議。我發現進行適當的索引會有很大幫助。 因此，為了進行測試，我從 beta 資料庫中獲取了提交內容，該資料庫擁有大約超過 **100k 記錄**。 在沒有任何最佳化的情況下，執行整個過程平均需要 **2.3 秒**。 （當然，這個時間不僅包括在資料庫上執行查詢的時間，還包括透過網路傳播資料的時間）  在向列加入索引後，我確實發現它縮短了幾毫秒的時間，但這還不夠。它仍然在 **2 秒** 左右，而且往往不止於此。 所以有點令人失望！無論如何，繼續下一個目標。 ### <u>原因 2：空字串錯誤</u> 因此，我們的時間從 **2.3** 秒縮短到了大約 2 秒，這對於索引來說並不算多。但後來我在我們的程式碼中發現了一個小錯誤，假設有四個輸入欄位供使用者根據四個不同的列鍵入和過濾結果。如果使用者沒有在任何輸入上鍵入任何內容（主要是在頁面首次載入時），且 API 呼叫會直接取得最新資料，而不進行任何過濾，僅進行連接和排序。 因此，在那一刻，我們為資料庫中的所有列傳遞了“”字串，這似乎無害，但實際上發生的情況是，資料庫正在對所有四列進行查找，您猜對了“”字串。所以進行了大量的查找，實際上什麼都沒有。 因此，當我將其更改為空（如empty/null）時（相當於從查詢中刪除where子句），查詢時間從**2.3秒變為1.3秒**。 如果您想知道使用使用者提供的實際輸入進行過濾需要多長時間。大約**500ms**（這是可以接受的）。 結論 - 即使您的資料庫使用所有可搜尋列進行索引，“”字串也不能很好地發揮作用。 好的，我們正朝著正確的方向前進。我們整整縮短了 1 秒，但我們仍然必須將其控制在 **200/150ms** 以下，所以還有很長的路要走。 ### <u>原因 3：不必要的連接</u> 在查詢提交時，我們正在與不需要的比賽和課程表進行連接。因此，當所有內容都加入到程式碼中時，我們只是刪除了它，但這表明審閱者並沒有給予太多關注（我是其中之一）。 ### <u>原因 4：ORM</u> 這是造成最多的問題.. 好.. 問題!!. 所以有一種叫做 **主動記錄模式** 的東西，TypeORM 為我們提供了使用類似 JSON 的物件產生 SQL 查詢的東西，一個例子就是。 ``` model.find({ select: { userName : true, firstName : true }, where: { userName : “SomeUsername” }, relations: { user : true, contest: true, problem: true }, order: { created_at : “ASC/DESC” , skip: 0, take: 10, }) ``` 因此，這使得開發變得快速、簡單，對於不擅長編寫原始 SQL 查詢的開發人員來說，感覺非常直觀，因為這是最抽象的版本，您實際上是在建立 JSON 物件來產生 SQL 查詢。 這種方法看起來不錯，而且大多數時候都有效，但在我們的例子中，它做了一些非常愚蠢的事情，我不會輸入它在做什麼，這樣你就可以自己看到查詢。 簡而言之，它正在執行兩個查詢，首先對於這種情況根本不需要，它可以通過我稍後編寫並測試的一個簡單的單個查詢輕鬆完成。 它不僅執行兩個單獨的查詢（原因尚不清楚，因為這是一個已知問題，有時在使用typeorm 的活動記錄模式時發生），它還將四個表連接兩次，每個查詢一次，然後還排序兩次各一次。 （這實際上沒有任何意義） 這也是表演受到最大打擊的地方。自己看看下面的查詢。 ``` SELECT DISTINCT `distinctAlias`.`Submission_id` AS `ids_Submission_id`, `distinctAlias`.`Submission_created_at` FROM (SELECT `Submission`.`id` AS `Submission_id`, ... more selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId`) `distinctAlias` ORDER BY `distinctAlias`.`Submission_created_at` DESC, `Submission_id` ASC LIMIT 10 ``` ``` SELECT `Submission`.`id` AS `Submission_id`, `Submission`.`language` AS `Submission_language`, `Submission`.`verdictCode` AS `Submission_verdictCode`, `Submission`.`tokens` ... shit ton of selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId` LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId` WHERE `Submission`.`id` IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ORDER BY `Submission`.`created_at` DESC ``` 所以這兩個查詢是問題的主要原因，也是主要原因之一。 因此，我編寫了一個簡單的原始 SQL 查詢來執行與它嘗試使用 2 個單獨的查詢執行的完全相同的操作，查詢如下：- ``` SELECT Submission.id, Submission.language, Submission.verdictCode, ... FROM submission AS Submission LEFT JOIN problem ... LEFT JOIN user ... ORDER BY Submission.created_at DESC LIMIT 10 ``` 當我們執行這個查詢時，它的執行時間僅為 **100ms!!!** 因此，我們現在從 **1.3** 秒移至 **100ms**，總體從 **2.3** 秒移至 **100ms** 效能提升超過 **23 倍。** 之後我就去睡覺了。仍然需要做更多的測試，並嘗試找出邊緣情況（如果有），並提出為此編寫查詢的最佳方法。目前，我正在考慮使用 TypeORM 提供的儲存庫模式或查詢建構器模式。 第二天： 又來了.. ### <u>全文索引</u> **全文索引**可以提高從這些索引列中搜尋單字和短語的效率，我們也可以嘗試一下。 （這是我的同事 Jay 提出的一個非常好的觀點，它進一步提高了表現）。 ###<u>發現了一些更重要的點。</u> 在 MySQL 中最佳化具有唯一索引的資料列上的「LIKE」查詢時，可以採用一些策略來提高效能。以下是一些建議： 1. **索引優化：** - **使用全文索引：** 如果您的「LIKE」查詢涉及在列中搜尋單字或片語，請考慮使用全文索引而不是常規唯一索引。全文索引是專門為基於文字的搜尋而設計的，可以提供更快、更準確的結果。 - **使用排序規則：** 確保列的排序規則不區分大小寫和重音。這可以透過使用「utf8_general_ci」或「utf8mb4_general_ci」等排序規則來實現。它允許更有效地利用索引，因為搜尋變得不區分大小寫和重音。 2. **查詢最佳化：** - **前綴搜尋：**如果您的`LIKE`查詢在末尾使用通配符（例如，`column LIKE 'prefix%'`），索引仍然可以有效地使用。但是，如果通配符位於開頭（例如“column LIKE '%suffix'”），則不會使用索引。在這種情況下，請考慮使用替代技術，例如全文搜尋或儲存列的反向值以實現高效的後綴搜尋。 - **最小化通配符：** 模式開頭的通配符（`'%suffix'`）會使查詢速度明顯變慢。如果可能，請嘗試建立查詢，使通配符僅出現在模式的末尾（「前綴%」）。 - **參數綁定：** 如果您從應用程式內執行「LIKE」查詢，請使用參數綁定或準備好的語句，而不是直接連接查詢字串。這有助於防止SQL注入並允許資料庫更有效地快取執行計劃。 3. **快取和查詢結果：** - **快取查詢結果：** 如果`LIKE`查詢結果相對靜態或不需要即時，可以考慮實作像memcached或Redis這樣的快取機制。快取可以透過直接從記憶體提供結果來顯著縮短反應時間。 - **物化視圖：** 如果經常執行「LIKE」查詢且資料列的資料相對靜態，請考慮建立物化視圖來預先計算並儲存「LIKE」查詢的結果。如果查詢物化視圖所帶來的效能提升超過了額外的儲存和維護需求，則此方法可能會很有用。 值得注意的是，這些優化策略的有效性可能會根據您的特定用例而有所不同。 ### 經過所有測試後建議的改進點。 1. 修正將空字串傳遞到 where/過濾條件的問題。 2. 在效能至關重要的讀取操作中，轉而使用查詢建構器而不是活動記錄模式。 3. 在用於搜尋和過濾的欄位中新增索引。另外，在不唯一且用於搜尋的列上新增全文索引。 4. 刪除/避免不必要的連線。如果可能的話，重組架構以在必要時複製資料。 5. 使用 LIKE 運算子搜尋時，使用「prefix%」模式，而不是我們使用的預設模式「%suff+pref%」。使用前綴模式有助於資料庫使用索引並提供更好的結果。 儘管如此，我們成功地將查詢時間從 **7 秒** 降低到 **<=150 毫秒**，這樣做後感覺很好，因為這是我第一次涉足性能和優化並尋找從我們已有的資源中榨取更多資源的方法。 特別感謝[Mitesh Sir](https://www.linkedin.com/in/miteshskj/) 在這次調查期間指出了潛在的原因並引導我走向正確的方向，並一遍又一遍地重新啟動測試伺服器😂因為由於記憶體限制，在多次執行測試後，資料庫會變得非常慢。 如果您想更多地談論與這一切相關的內容，請在 X 上關注我，https://twitter.com/RishiNavneet ### 參考 1. https://github.com/typeorm/typeorm/issues/3857#issuecomment-714758799 2. https://github.com/typeorm/typeorm/issues/3857 3. https://stackoverflow.com/questions/714950/mysql-performance-optimization-order-by-datetime-field 4. https://stackoverflow.com/questions/22411979/mysql-select-millions-of-rows 5. https://dba.stackexchange.com/questions/20335/can-mysql-reasonously-perform-queries-on-billions-of-rows 6. https://stackoverflow.com/questions/38346613/mysql-and-a-table-with-100-millions-of-rows 7. https://github.com/typeorm/typeorm/issues/3191 PS - 這些改進很久以前就完成了，我只是懶得發布它😬。 --- 原文出處：https://dev.to/navneet7716/optimizing-sql-queries-h9j
如標題所示，在這篇文章中，我們將介紹您可以學習並用作下一個專案起點的開源 Web 應用程式。堅持到最後，因為那裡有超酷的獎勵等著你！ 在我們開始討論之前，先說幾句智慧之言（希望如此）： ## （開源）榜樣的重要性  **從頭開始一個新專案時，您可以做的最有幫助的事情之一就是選擇一個或多個角色模型。**例如，如果您正在建立一個新的生產力應用程式，您可能會關注Trello 等產品或體式。當然，您的應用程式不會相同，並且您可能會想到一些使您的應用程式獨一無二的核心差異，但仍然會有很多您不想重新發明的共享概念和機制。 即使您的角色模型是一個閉源應用程式，您仍然可以透過在野外觀察它來獲得很多價值 - 設計元素、UI、用戶旅程和使用的術語，... **但是現在想像一下，如果您決定學習的應用程式是開源的，並且您可以輕鬆地在 GitHub 上存取其完整原始程式碼 - 這將打開一個全新的可能性世界！** 接下來只需從“外面」並猜測幕後發生了什麼，現在您可以看到每一個細節並了解所做的每一個決定。架構、部署、API 設計、庫和使用的演算法 - 一切都在那裡供您查看！ ## 注意規模（也就是不要過度設計） 另一件需要記住的事情是您的專案目前所處的階段。下面，我們將看到開源 SaaS 應用程式的不同範例，從獨立駭客、「週末建置」副專案到企業級 Web 平台。 **儘管您可能會發現擁有數百萬用戶的專案是一個令人驚嘆的學習資源，但請記住，並非他們所做的一切都是您必須嚴格遵循的。由於他們每天遇到的用戶規模和數量龐大**，他們的架構和設計決策通常會更加複雜。如果您剛開始，最好堅持使用最簡單（但仍然合理）的方法，直到您希望需要更高級的方法。 > 從現在開始，對於我們提到的每個應用程式，我們將使用“T 卹尺寸”方法（S、M、L...），讓您大致了解其尺寸和複雜性（無論是在功能還是功能方面）。使用者。 現在，前言結束了，讓我們一起來看看一些令人驚嘆的開源應用程式，您可以立即開始學習：  ## [CoverLetterGPT](https://coverlettergpt.xyz/) - 人工智慧驅動的 SaaS 的完美起點 💾 **原始碼**：https://github.com/vincanger/coverlettergpt 👕 **尺寸**：S **🛠️ Stack**：Chakra UI、React、Node.js 和 Prisma，由 [Wasp](https://github.com/wasp-lang/wasp) 提供支持 [CoverLetterGPT.xyz](http://CoverLetterGPT.xyz) 是每個獨立駭客的夢想- **它是一個由GPT 支援的SaaS，完全開源，最重要的是，它是人們每天使用並付費的真實產品為了**！根據您的履歷和職位描述，該工具將產生一封專業撰寫的求職信。然後，您可以進一步調整每個段落的語氣或手動編輯。 它非常適合學習，因為它不太大，架構也很簡單，但它具有應用程式中可能需要的所有功能 - 社交身份驗證 (Google)、cron 作業、文件上傳、GPT 集成、透過 Stripe 進行支付集成，甚至可以透過比特幣付款！ CoverLetterGPT 由 React、Node.js 和 Prisma 製成，由 [Wasp 框架](https://github.com/wasp-lang/wasp) 提供支持，它負責所有管道並刪除大量樣板檔案。 **最好的部分是，當您準備好時，可以透過執行單一 CLI 命令來免費部署應用程式**：「wasp deploy」。 <center><h3>🚨注意🚨</h3></center> > 提示：Wasp 團隊最近發布了 [OpenSaaS](https://kdta.io/github-wasp-lang-open_3)，**一個完全免費且開源的 React 和 Node.js 樣板啟動器**。它包含提到的所有內容 + Tailwind、管理儀表板、登陸頁面、部落格等。 [在此處查看](https://kdta.io/github-wasp-lang-open_4) 以更快地開始使用。 ## Supabase Studio - 儀表板傑作🖼️  💾 **原始碼**：https://github.com/supabase/supabase/tree/master/apps/studio **👕 尺寸**：M/L **🛠️ 堆疊：** Next.js (React)、Tailwind [Supabase](https://supabase.com/) 是一個著名的開源專案，其核心是用 Elixir 編寫的。但是，由於我們在本文中專注於 Web 應用程式，因此我們將看一下 **Supabase Studio - 一個儀表板，您可以在其中查看和管理所有專案。它本身就是一部傑作，而且完全開源！** 該設計是使用 Tailwind 定制的，您可能希望在自己的專案中重複使用許多元素 - 用戶管理、表格、列表等。它還有自己的 AI 集成，用於編寫 SQL 查詢，效果出奇的好。 ## Papermark - 開源 DocSend 替代方案 ✉️  💾 **原始碼**：https://github.com/mfts/papermark 👕 **尺寸**：M **🛠️ 堆疊**：Next.js (React)、Tailwind、Prisma [Papermark](https://github.com/mfts/papermark) 最近受到社群的廣泛喜愛，尤其是其簡潔的設計和直覺的介面。雖然從外觀上看起來很簡單，但該應用程式包含許多功能，使一切順利執行：文件上傳、電子郵件發送、內建分析和自訂網域... **如果您正在建立涉及大量文件管理和使用者協作的專案**，這絕對是您應該考慮的專案。 ## [Crowd.dev](http://Crowd.dev) - 開發社群資料平台，使用 Vue 製作 📊👩💻  💾 **原始碼**：https://github.com/CrowdDotDev/crowd.dev **👕 尺寸**：M **🛠️ 堆疊：** Vue、Node.js [Crowd.dev](http://Crowd.dev) 是 GitHub 最新的後起之秀之一 - 它是一個用於監控社區活動的平台，無論是在 Slack 還是 Discord 上。如果您正在經營自己的開發者社區，那麼這樣的工具是必須具備的，以便了解正在發生的事情以及最活躍的成員是誰。 它在儀表板方面提供了很多功能，但它的另一個強項是**集成 - 如果您正在建置一個從外部源獲取和處理大量資料的應用程式，那麼這是您的首選角色模型**。如果你是 Vue 愛好者，那就加分了，因為這個專案就是用它製作的！ ## Habitica - 作為角色扮演遊戲的習慣追蹤器🐲⚔️  💾 **原始碼**：https://github.com/HabitRPG/habitica **👕 尺寸**：L **🛠️ 堆疊：** Vue、Bootstrap、SAAS、Node.js、MongoDB [Habitica](https://habitica.com/) 是我見過的最酷的網頁應用程式之一（他們也有 iOS 和 Android 應用程式） - 它可以幫助您透過角色扮演遊戲！想像 Trello 這樣的看板，但對於您完成的每項任務，您都可以獲得 XP 和金幣，甚至可以與朋友組隊接受任務。 Habitica 已經存在 10 年了，它通過 Vue、Node.js/Express 和 MongoDB 的經典堆疊完美地經受住了時間的考驗。 **如果您想了解建立了多麼豐富的互動式 UI，以及執行這種規模的專案需要什麼樣的架構，那麼這個應用程式絕對值得一試。**誰知道，您甚至可能最終成為居住自己！ ## 🏆 **獎勵** 🏆 Appflowy - Rust 和 Flutter 中的概念替代品 🤯  💾 **原始碼**：https://github.com/AppFlowy-IO/AppFlowy **👕 尺寸**：M **🛠️ 堆疊：** Flutter、Rust 如果您走到這一步，您應該得到特別的待遇！這不是一個網絡應用程式，但它太酷了，我無法控制自己 - 它是**一個用 Rust 和 Flutter 建置的 Notion 替代品（因此可以做筆記）**！由於其本地優先的性質，用戶體驗非常流暢，並且它還將所有內容同步到雲端（如果您願意，您可以自行託管）。 **如果您一直在使用 Rust，但也在尋找一個可以每天使用的專案，Appflowy 可能是完美的選擇。** 它擁有從資料儲存到業務邏輯和 UI 的所有內容，全部都包含在其中一個包供您學習並查看您認為最有趣的內容。 ## 就是這樣！我很想聽聽你的訊息🫵  這就是我們今天的全部內容（*放下麥克風*），非常感謝您的閱讀！我希望您發現它有用和/或有趣。 我在撰寫本文時遇到了很多開源 Web 應用程式，很難只選擇其中 5 個。 **現在，我很想聽聽您的來信 - 您最喜歡的開源應用程式是什麼，以及您如何使用它們？寫在下面的評論👇** 謝謝您，下次再見！ 👋 --- 原文出處：https://dev.to/matijasos/5-beautiful-open-source-web-apps-to-learn-from-and-get-inspired-280f
對外行人來說，**K8s 代表Kubernetes**，數字8 代表**K** 和**s 之間的八個字母。** Kubernetes 在當前的技術環境中幾乎不可避免，但仍然不受歡迎，因為它的複雜性和陡峭的學習曲線。 基於終端的交互在這個故事中發揮著重要作用。如果您曾經有幸觀看一位經驗豐富的 DevOps 使用 Kubernetes 集群工作的方式，您可能會像看一位經驗豐富的武術家展示他的戰鬥技巧一樣看待他。這是因為透過終端完成的所有事情總是看起來更可怕，似乎需要多年的培訓。 🥋 現在的問題是：我們怎麼能讓這樣一個複雜的問題（甚至它的名字還被美化了）變得更有趣呢？好吧，以同樣的方式，我們讓一切變得更愉快 → 讓它變得更容易，讓它更漂亮！ 🎀 你可能會問，你會怎麼做呢？具有**圖形使用者介面**或簡稱 GUI！讓我們來看看在處理 Kubernetes 時為您提供使用者介面的**五個工具**。 ### 向我們展示您的支持🙏🏻  在開始之前，我們想提一下，我們已經安排了 [Product Hunt 的首次發布](https://www.producthunt.com/products/cyclops)！點擊“通知我”按鈕，以便在我們外出並準備好接收您的回饋時收到提醒 🔔 如果您為我們的[儲存庫](https://github.com/cyclops-ui/cyclops)加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興 ⭐ ## Kubernetes 儀表板 讓我們深入了解 **Kubernetes 管理的精髓工具** – [**Kubernetes 儀表板**](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)。它會自動與您的叢集捆綁在一起，提供 Kubernetes 環境的圖形概覽。您可以使用它來概覽叢集上執行的應用程式、將容器化應用程式部署到 Kubernetes 叢集以及管理叢集資源。 Kubernetes 儀表板不僅提供概述，還有助於排除故障。它提供對 Kubernetes 資源運作狀況的洞察，突出任何操作錯誤。 透過它，您還可以部署應用程式。您可以使用您編寫的清單或透過您剛剛填寫的表單來完成此操作。但是，值得注意的是，該表單雖然用戶友好，但缺乏基本範例之外的自訂靈活性。 雖然 K8s 儀表板是**萬能**，但許多人發現它是一個多面手，缺乏深入的功能。這種限制鼓勵我們探索更多工具，每種工具都是為特定目的而設計的，因此我們透過我們探索過的工具清單開始我們的旅程。  ##K9s 透過終端探索集群時，[**K9s**](https://k9scli.io/) 是你最好的朋友（明白了嗎？🐶）。它與 Vim 的互動風格有共同點，即使用快捷鍵和以 `:` 開頭的命令，但不要因此而洩氣。 K9s 密切關注 Kubernetes 活動，為資源互動提供**即時**資訊和直覺的命令。 它幾乎可以取代標準的“kubectl”，並且在與 Kubernetes 互動時不需要您身邊有“備忘單”。您只需選擇資源並深入到最低級別即可遍歷資源。這樣可以輕鬆提取日誌並存取其外殼。 K9s 可讓您查看每個資源的清單，並能夠編輯和套用變更。正如我所提到的，它**幾乎**取代了“kubectl”。區別之一是您**無法**透過 K9 部署新資源。 K9s 具有過濾資源並使用「/」指令進行搜尋的功能，可以更輕鬆地在資源海洋中找到您要尋找的資源或透過特定 pod 的日誌進行過濾。 螢幕頂部隨時可以使用的命令和快捷方式清單是一個不錯的設計，它的皮膚和插件自訂為您提供了額外實用程式的空間。  ## 獨眼巨人 如果您在處理清單檔案時遇到困難，[**Cyclops**](https://cyclops-ui.com/) 就是適合您的工具！ Cyclops 透過將清單轉換為基於 Web 的結構化形式，消除了處理清單時的混亂和複雜性，從而消除了手動配置和命令列互動的需要。 這使得具有不同技術專業知識水平的個人**更容易理解**部署過程。 在 Cyclops 的架構中，核心元件是 [Helm](https://helm.sh/) 引擎。 Helm 在 Kubernetes 社群中非常受歡迎；很可能你已經遇到過它。 Helm 的流行因其簡單的整合而發揮了 Cyclops 的優勢。  有了 Cyclops，您就不再局限於一刀切的方法。 **您可以自訂表單以滿足您的獨特需求。** 例如，團隊成員可以產生 Helm 圖表，讓其他人可以使用 Cyclops 定義必要的值，以實現輕鬆的應用程式部署。 一旦您聲明了應用程式的所需狀態，部署它就像單擊按鈕一樣簡單。此外，一旦部署應用程式，也可以透過 Cyclops 輕鬆更改所需狀態。 在 Cyclops 中，每個應用程式都列出了它使用的資源的詳細清單 - 部署、服務、pod 等，所有這些都在簡單的視圖中。您可以輕鬆追蹤它們的狀態，幫助您快速發現並修復應用程式中的任何問題。這就像有一個清晰的路線圖來導航和解決出現的任何問題。  ## 開發空間 考慮每次儲存程式碼時自動刷新本機伺服器的便利性和節省時間，從而提供程式碼變更的即時視覺化。 想像一下將這種流暢的體驗進一步應用到 Kubernetes 叢集中； [**DevSpace**](https://www.devspace.sh/) 讓這一切成為可能。借助 DevSpace，您可以在編碼過程中**即時部署應用程式**，從而促進快速迭代。 DevSpace 透過自動將變更套用到 K8s 叢集來簡化流程，而無需整個映像建置和部署管道。它在本地建立映像，而不將其推送到註冊表，儘管在開發過程中需要它的人可以使用自動推送映像的選項。 此外，DevSpace 具有一個使用者介面，雖然有些限制，但可以快速概述叢集中的所有 Pod。它允許您**輕鬆存取 Pod 日誌，甚至直接在其中執行命令**，從而增強您的開發工作流程。 儘管我專注於本地開發，但 DevSpace 也用於建立工作流程。您的所有工作流程都保存在一個檔案中，從而可以使用單一「devspace deploy」命令輕鬆在任何電腦上重現環境。  ## 庫貝前一個 與本文中提到的其他工具不同，[**Kubevious**](https://kubevious.io/) 無法更改叢集狀態。它僅用作可觀察性工具，重點關注集群中的潛在問題。它突出顯示了您可能執行的每種資源的潛在威脅和風險。 圖形視圖提供對容器、網路、暴露、RBAC 和 Helm 圖表的深入了解，以進行直觀的故障排除。 Kubevious 有一個**規則引擎**，有助於偵測並防止錯誤配置。它附帶了開箱即用的規則，但它也允許您建立自訂規則（例如，「不允許圖像位於*最新*標籤上」）。 它還配備了很酷的**時間機器**功能，允許用戶回到過去、審核應用程式、根本原因中斷和恢復清單，確保完全了解叢集歷史記錄。 我不得不提一下它提供的**全文**搜尋！您可以搜尋任何資源，而無需知道其特定名稱。一個很好的例子是，只需輸入「*port 3000*」即可搜尋使用特定連接埠的任何資源，Kubevious 就會找到您的資源。  ## 最後的想法 為了增強 Kubernetes 體驗，我們推出了五個令人愉悅的工具，每個工具都有其獨特的魅力，讓您的旅程更加順暢和愉快。 這些並不是為 Kubernetes 提供 UI 的唯一工具，但我們希望專注於一些可能不太知名的工具。 所有這些工具都是開源的，所以請嘗試一下；他們是免費的！ 我想用一個針對讀者的問題來結束這篇文章：您對 Kubernetes 的圖形表示有何看法？是否需要，或者「kubectl」是否佔據主導地位？ --- 原文出處：https://dev.to/cyclops-ui/five-tools-to-make-your-k8s-experience-more-enjoyable-5d85
如果我告訴你，你覺得自己在開發者職涯中陷入困境的原因與你的技術技能無關，你會怎麼想？ 它與資料結構、系統設計或軟體架構無關。 但這與你如何看待整個程式設計有關。 你看，自從你開始編碼以來，你就已經習慣於相信某些關於成為開發人員的神話，這些神話正在毀掉你的職業生涯。這就是為什麼你會患上冒名頂替症候群並懷疑自己的技能。讓你停留在同一水平，感到沮喪和工資過低。 更糟的是，這些信念深深植根於我們作為開發人員的日常生活中，以至於我們將它們視為理所當然。我們甚至不質疑他們。因為我們認為它們是現實。 事實上，它們只是社區流傳的神話。 尚未被揭穿的神話。部分原因是它們在紙上聽起來不錯。事實上，它們是危險的偏見，阻礙你走出去，建立你應得的未來。 在這篇文章中，我們將一一揭穿這些神話。 因此，您可以擺脫限制性信念，為最重要的目標採取行動，並釋放您作為開發人員的全部潛力。 讓我們從第一個讓你陷入困境的程式設計神話開始... # 1. 激情的神話 激情神話說，偉大的開發人員都非常熱情。他們在晚上編碼，在週末編碼。晚上，他們用程式碼做夢。 如此充滿熱情的程式設計師可以無休無止地編寫無數小時的程式碼。他們甚至沒有註意到這一點。當然，因為他們是如此熱情。 如果你沒有足夠的熱情去吃飯、睡覺、編碼和重複，那麼你應該收拾行李，找點別的事情做。我的朋友，開發人員不適合你。 去找點別的事做吧。聽說麥當勞要招募了 這是一個多麼糟糕的訊息，特別是對於剛開始的新開發人員。 開發人員和軟體公司都延續著激情的神話。 首先是那些試圖推銷自己並取得成功的開發商。部分是透過展示他們有多麼熱情。我不怪他們。我們都以某種方式這樣做。我所指出的只是這種行為的負面後果。 其次，激情的神話是由公司宣揚的。 充滿熱情的人對生意很有好處。因為他們願意廉價地出賣自己的時間。他們在辦公室度過數百個小時，讓別人變得富有。因為他們對自己所做的事情充滿熱情。 他們用這些無薪時間換取了什麼？ 我想這與他們的工作有情感連結。一種歸屬感。欣賞和目的。這些都是非常強大的藥物。 但是，你猜怎麼著……你不需要把你的時間免費交給一些自稱是家庭的公司來獲得這些感覺。  把你的時間留給你真正的家人。當你沒有攪拌足夠多的程式碼行時，它不會把你踢出去。 擁有平衡的生活，編碼不會佔用您大部分時間。 交朋友並在工作之餘擁有自己的嗜好。你也會得到同樣的滿足。除了讓你的時間回來！ 激情的神話是危險的，因為它以另一種方式告訴你，首先，你還不夠（在這種情況下不夠熱情）。 > “程式設計不是一種“激情”或“天賦”，而是後天技能的集合。” - Jacob Kaplan-Moss（Django、Python 框架的共同建立者） 激情神話之所以如此危險，是因為它會觸動你作為開發人員最大的恐懼，特別是如果你是自學成才的話。 害怕「你還不夠」。 激情神話的第二個基本訊息是你工作不夠努力。 這會讓你越來越努力，忽視你的健康和家庭，導致倦怠。這就是為什麼有些公司是有毒的工作場所。 事實上，最好的軟體開發人員都非常懶惰。這就是為什麼他們嘗試設計事物並提高效率，而不是用蠻力解決問題。 根據我的經驗，開發人員成為高級開發人員的標誌之一就是不必在周末編碼。 **高級開發人員選擇一致性而不是熱情。** 生產力突飛猛進，穩定進步。他們知道「激情」來來去去。太多的熱情會導致倦怠。 當時間流逝時，經驗豐富的開發人員就會停止熱情。他們合上筆記型電腦並離開了辦公室。 有趣的部分？ 透過暫時遠離編碼，他們第二天回來時會更加新鮮，並渴望親自動手。 如果您想充分發揮開發人員的潛力，請忘記激情的神話。 相反，要注重平衡和一致性。作為一個已經編碼十多年的人，我可以告訴你開發人員的職業生涯是一場馬拉松。 現在來談談阻礙程式設計師前進的第二個誤解… 🚨附言您是否希望透過優質資源、回饋和問責制快速晉升為高階職位？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3So6BWF)🚨 # 2. 經驗的神話 如何晉升資深開發人員？如何獲得技術主管？您如何獲得更多責任或加薪？ 傳統的建議會告訴你沒有靈丹妙藥。你只是需要更多的經驗。所以堅持住。當你的眼睛有皺紋、背部疼痛時，你可能會到達那裡。或者你可能不會。我們不確定。  _閱讀 LinkedIn 上的開發人員職位發布後的感受如何。圖片來源：Reedit._ 儘管經驗確實很重要，但這個神話被過度使用了。 首先，並非所有經驗都是平等的。 人們可以在快節奏的新創公司待一年，然後看到它成長。學習如何從幾百個用戶擴展到數百萬個。 或花一年時間維護公司中的一些遺留企業軟體。除了發送格式良好的電子郵件和辦公室政治之外，學到的東西很少。 **注意**：相反的情況也可能發生。你在新創公司中什麼也學不到，因為產品永遠不會受到關注，而你在企業中學到很多東西，因為他們已經擁有了規模。 以編寫程式碼年數表示的經驗並不能很好地顯示開發人員的資歷。單獨的時間並不能轉化為學習。重要的是你在這段時間裡做什麼。 雖然晉升高級可能沒有靈丹妙藥，但有一定的模式。 如果開發人員模仿這些模式，他們可以大大加速他們的成長。這就是為什麼你會發現擁有 3 年經驗的開發人員拿著 6 位數的薪水，而一些高級開發人員在月底仍然難以支付賬單。 這種經驗神話阻礙了你，因為傳達的訊息是相同的：你還不夠（以你沒有足夠的形式）。 我是說沒有經驗就能出人頭地嗎？沒有任何這些你就可以成為高級開發人員嗎？ 不。 但不要高估時間的價值。相反，你應該看重的是執行力。當你划船時，船的移動速度比你只是等待水流時要快。 經驗神話長期存在有兩個主要原因。 ### 第一，缺乏知識。 當你問高級開發人員需要什麼才能達到下一個級別，而他們不知道所需的確切技術和軟技能時，他們只會遵循多年的經驗，而不會顯得愚蠢。 ### 第二，不安全感。 如果高級開發人員看到您試圖比他們更快地行動，那麼人類精神中醜陋的部分就會發揮作用。在一個聲稱如此開放和友好的行業中，嫉妒是很常見的。像軟體開發人員這樣非常聰明的人通常也非常雄心勃勃。 軟體開發是一個競爭非常激烈的行業。 我們同時合作和競爭。只要我們確保競爭公平並且不欺騙自己就可以了。 經驗神話是一種不公平的競爭方式。我們不關注人們的才能和技能，而是更關注他們履歷中的任意數字。 _雞生蛋蛋生雞的問題。圖片來源：theSeniorDev_ 為了擺脫體驗神話，轉移你的注意力。更關心你的技能而不是你在某項工作上花費的時間。 如果當你提出要求時，有人以沒有足夠的「多年經驗」為由，不要讓他們阻止你。完善你的履歷和技能，開始進行技術面試，然後讓市場來決定。 🚨附言您是否希望透過優質資源、回饋和問責制快速晉升為高階職位？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3So6BWF)🚨 # 3.人工智慧的神話 現在是 2024 年，你學習如何編碼是沒有意義的。或如何成為更好的開發人員。很快，人工智慧將取代我們所有人！編碼工作即將結束，為什麼還要費心？ 人工智慧的神話已經存在了幾十年。但直到 ChatGPT 和 Github Copilot 發布之前，它從未如此存在。 那麼，為什麼要費心去成為更好的開發人員呢？  軟體開發本來就很困難，現在你有一個完美的藉口放棄它。 甚至不會被認為是失敗。你可以將其歸咎於開放人工智慧。 沒那麼快。 我會給你兩個理由說明為什麼你還是應該費心。 繼續程式設計的第一大原因是你正在學習的「元」技能。這些都是技能背後的技能。 當你學習如何編碼時，你就是在學習如何思考。以結構化的方式思考。您正在學習如何將業務需求建模為逐步說明。您正在學習如何集中註意力、如何過濾資訊以及如何在團隊中工作。 即使機器本身很快就會完成實施和編碼，這些「元技能」也非常有價值。 繼續敲擊鍵盤的第二個原因是，從我們迄今為止所看到的情況來看，人工智慧工具會犯下許多錯誤。它們是預測機器。他們無法思考。人類推理仍有需求。 這些人工智慧工具會變得更聰明嗎？ 大概。 它們會在不久的將來取代人類嗎？可能不會。 你猜怎麼著，如果你不再閱讀那些關於人工智慧將如何取代你的偏執文章，而是真正在軟體開發方面做得更好，你很可能永遠不會被取代。 或者，當這種情況發生時，您已經在某個充滿異國情調的海灘上退休了。 ####老年的比喻。 想像一下你已經 50 歲了。機器贏了。他們將一切自動化。但是，你不斷學習、適應和學習新技能。賺大錢，投資養老。你現在很聰明，而且已經退休了。 假設你陷入了目前正在發生的人工智慧偏執狂。你放棄了編碼。你做了一些被標記為人工智慧免疫的事情（不知道是否存在，但建築工作是最重要的）。 你賺了一些錢，但沒學到多少東西，同時也毀了你的身體。你現在老了，想要一份辦公室工作。理想的情況是遙遠的事。 你對如何實現這一點的了解為零。您繼續編碼的開發人員夥伴在打高爾夫球方面表現得很好。 屈服於恐懼毀了你的生活。 不要因恐懼而屈服。永遠不要停止學習和進步。 _圖片來源：theSeniorDev_ 繼續變得更好。提升整個堆疊的技能。熟悉人工智慧。幾個月後，你就會迎頭趕上，並慶幸自己沒有放棄。 **為什麼這些程式設計神話如此有效？** 因為它們觸及了身為開發人員最大的恐懼之一。 害怕你還不夠。還不足以得到那份工作。不足以讓拉取請求獲得批准。還不足以成為「真正的開發人員」。 希望讀完本文後，您能夠認清這些神話的真相。純粹的誤解阻礙了你。 不要屈服於恐懼，不斷提升你的技能。 直到下一篇， 德拉戈斯 🚨附言您是否希望透過優質資源、回饋和問責制快速晉升為高階職位？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3So6BWF)🚨 --- 原文出處：https://dev.to/dragosnedelcu/3-programming-myths-that-keep-you-stuck-frustrated-and-underpaid-27bg
大家好！ **祝大家新年快樂** 🥳 我的將會充滿壓力和樂趣。希望你的也是！  [Discord](https://discord.com?utm_source=nevo.github20k.com&utm_medium=referral&utm_campaign=the-discord-plan-for-open-source-in-2024) 是一個聊天訊息平台，您可以執行它與開發人員進行互動為您的產品。它可用於行銷、支援或為您的產品建立強大的社群。 在 Novu 期間，我們總是嘗試讓 Discord 伺服器 **「活躍」。** 這是我和很多創辦人都經歷過的事情。 他們希望他們的 Discord 不僅僅是一個 **「支援」** 頻道。 大多數創辦人的目標是讓 Discord 頻道活躍起來，只是透過人們之間的互動，**但是你如何做到這一點？** 以下是您可以在 Gitroom 和 HackSquad Discord 伺服器中嘗試的對我來說效果很好的操作清單。 --- 1\.讓人們回頭購買更多 ---------------------------------- 我想從最簡單的例子開始 - [**Midjourney**](https://www.midjourney.com/?utm_source=nevo.github20k.com&utm_medium=referral&utm_campaign=the-discord-plan-for-open-source-2024)。 他們的主要產品位於 Discord 上；如果你想產生影像，你必須使用 Discord 機器人來完成。每當人們開始創作圖片時，他們就會接觸到其他人並與他們互動。這是一個天才之舉。 在[Gitroom](https://discord.gitroom.com?utm_source=nevo.github20k.com&utm_medium=referral&utm_campaign=the-discord-plan-for-open-source-in-2024) 中，我實現了一個機制，供人們啟動他們的內容。由於大多數人每週都會發佈內容 - 他們必須**每週**回來，同時與其他人互動。 這就是為什麼您通常每週一都會在 Gitroom 中看到大量活動。  --- 2\.製造“非產品”Discord -------------------------------- 當您的 Discord 伺服器類似於「Novu」時，Discord 的訪客會有「這是 Novu 產品。讓我們來談談這個吧，」雖然大多數產品都是這樣做的，但你不必這樣做。 我們的 Discord 伺服器可以是「通知基礎架構」。現在，我們擴大了受眾範圍，為他們提供了一個了解有關通知的所有資訊的地方。 HackSquad 非常活躍，因為它是一個基於開發人員的伺服器，人們可以在其中談論任何事情。  --- 3\.有意圖地加入 -------------------- 最近，我發現在我的通話期間透過我們的 Discord 伺服器進行推廣的人比自己加入的人要活躍得多。 我認為這是建立一個活躍社區的主要秘密 - 雖然你不能與每個人交談，但只有少數人已經相當不錯了，因為他們會很活躍並讓其他人參與其中。 **您可以執行的其他選項是：** * 在 Discord **「入門」** 嚮導中提供更多訊息，以便人們可以了解透過活躍可以得到什麼。 * 在 Discord 連結旁邊顯示一些內容或 YouTube 影片，以便人們可以了解伺服器的價值。 * 標記參加不同活動的人並徵求他們的意見。  到目前為止，您喜歡這篇文章嗎？ 請務必註冊新聞通訊以閱讀下一篇新聞通訊 訂閱 \* 加入您的郵箱，獲得前1000星的影片將發送至您的郵箱 或邀請你的朋友學習【如何取得 GitHub stars】(https://howtogetgithubstars.com) --- 4\.保持 ---------- 讓人們加入您的 Discord 是「**獲取**」過程的一部分，但讓他們留下來是「**保留**」過程的一部分。 在 HackSquad 中，讓人們回到 Discord 會讓他們更加活躍。 **例如：** * 我不會製作網路研討會的 YouTube 直播或 Zoom 直播，而是製作 Discord 直播，然後透過電子報將人們帶回 Discord。 * 我舉辦的可重複活動超出了「如何使用 Novu」的範圍。我實際上會做更多通用的東西來吸引更多的人。 * 我舉辦 Discord 贈品活動，讓開發者回歸。 * 我經常在社群媒體上寫關於成為 Discord 的一部分的好處。  --- 5\.指定主持人 ---------------------- 我用 Gitroom 做的第一件事就是在 Discord 上找到第一批活躍且有才華的人，並讓他們成為 mod。這是我讓社區活力提升十倍的最佳措施之一。 一旦社區發展一點，我打算帶來更多的模組。 在 HackSquad 中，我在 1 個月內任命了 10 位版主 - **史上最佳決策。** 我很高興有像[Nathan這樣有才華的人](https://www.linkedin.com/in/nathan-tarbert/?utm_source=nevo.github20k.com&utm_medium=referral&utm_campaign=the-discord-plan-for-open-source-in-2024) 和[Saurabh](https://www.linkedin.com/in/srbhr/?utm_source=nevo.github20k.com&utm_medium=referral&utm_campaign=the-discord-plan-for-open-source-in-2024)，他們幫助我發展社區並將其整合在一起。 當您給予模組**“力量”**時，它們會自動變得更加活躍  --- 6\.建立入職管道 ------------------------------------------- 當有人加入你的 Discord 時，那將是他們最活躍、最積極的時候。 **你應該利用這個時間！** 在 Discord 上問他們一些問題，並讓他們參與一些對話並給予一些意見。 另外，**DM 他們**。雖然這與活躍在 Discord 上無關，但這是了解社群成員並從他們那裡提取一些資訊的絕佳時機： * 為什麼加入？ * 你在建造什麼？ * 誰告訴你我們的事了？ * 為什麼想從這個社區獲得？ 如果可以的話，甚至嘗試打一個 10 分鐘的電話。 事情是這樣的：你不是活躍的 **24/7**，但如果你有來自世界各地的模組 - 他們可以幫助你！ 只要確保不是所有的模組同時向同一個人發送私訊即可 - 這不太好 🙂  最後一件事🤣 製造很多錯誤 - 這會讓人們陷入**（當然，我在開玩笑。）** --- ## 我邀請您註冊我的電子報。 若符合以下條件，本通訊對您有好處： - 您正在考慮開源您的產品（或建立新產品）。 - 您正在考慮開啟一個副產品並將其開源（以反映您的主要產品）。 - 您從事科技業，希望在沒有明星/沒有 GitHub 趨勢的情況下實現成長。 這是一份 100% 免費的時事通訊（並且永遠如此）。請隨時註冊： [https://gitroom.com](https://gitroom.com/)  --- 原文出處：https://dev.to/github20k/the-discord-plan-for-open-source-in-2024-2596
## 簡介 以下是專注於全端開發不同面向的 Python 函式庫；有些專注於 Web 應用程式開發，有些專注於後端，有些則兩者兼而有之。  --- ## 1. [Taipy](https://github.com/Avaiga/taipy) Taipy 是一個開源 Python 庫，用於建立生產就緒的應用程式前端和後端。 它旨在加快應用程式開發，從最初的原型到生產就緒的應用程式。 🔑特點： - 豐富的互動性 - 為您的佈局、樣式等提供更多自訂功能（無需 CSS） - 多頁和多用戶應用程式 - 圖形管道編輯器 - 與 Taipy 前端功能整合以實現端到端部署 - 日程安排 - 筆記型電腦相容  ---  https://github.com/Avaiga/taipy 您的支持意義重大🌱，並且在許多方面為我們帶來了很大的幫助，例如寫文章！ 🙏 --- ## 2.[Prefect](https://github.com/PrefectHQ/prefect) Prefect 是一個提供資料管道開發的框架。 它透過注重簡單性和用戶友好性而與 Airflow 等競爭對手區分開來。 如果您想要一個具有各種功能但比 Airflow 更容易學習的成熟產品，Prefect 是一個很好的中間產品。 🔑特點： - 直覺且使用者友好的控制面板 - 快取等智慧功能 - 以流程為基礎的架構，可輕鬆融入工作流程組織 - 動態參數化與依賴管理 - 混合執行（本地/雲端）  --- ## 3. [Streamlit](https://github.com/streamlit/streamlit) Streamlit 是一個遊戲規則改變者，可以快速、簡單地建立 Web 應用程式。 此資料應用程式框架將其從更完整、更複雜的解決方案轉變為快速、用戶友好的解決方案。 🔑特點： - Pythonic框架 - 互動式小部件 - 使用者友善性  --- ## 4.[氣流](https://github.com/apache/airflow) Apache Airflow 是一個開源平台，專為調度和監控工作流程而設計。 它是編排複雜資料管道和 ETL 流程的絕佳選擇，因為它在過去十年中一直是管道領域的重要參與者。 該庫的完整性與陡峭的學習曲線有關。 🔑特點： - 基於DAG的工作流程定義 - 包括 DAG 視覺化的完整介面，可追蹤故障並管理重試。 - 各種集成 - 動態任務執行和調度 - 以Python為中心的設計 - 社區支持  --- ## 5. [Brython](https://github.com/brython-dev/brython) Brython 將 Python 帶到了前端，因為這個名字重新組合了「瀏覽器」和「Python」。 它引入了直接在 Web 應用程式中執行 Python 程式碼的獨特概念。 這種創新方法可讓您使用 Python 建立互動式 Web 體驗。 🔑特點： - 易於集成，因為它將 Python 邏輯直接整合到瀏覽器中 - 相容於不同的網頁瀏覽器  --- ## 6. [達世幣](https://github.com/plotly/dash) Dash 由 Plotly 建立，是一個利用 Plotlys 元件完整性的 Web 應用程式框架。 眾所周知，它是一個完整的解決方案，因此需要更長的時間來掌握。 🔑特點： - 基於元件的架構 - 強大的互動式儀表板 - 即時資料更新  --- ## 7. [Dagster](https://github.com/dagster-io/dagster) Dagster 是本次編譯中較新的函式庫之一，它是一個雲端原生資料管道編排，旨在統一資料整合、工作流程編排和監控。 與其他工具相比，Dagster 強調工作流程建立和管理的 DataOps 面向。 🔑特點： - 聲明式管道設置 - 固執己見的結構 - 版本控制 - 與 Hadoop 集成 - 全面的元資料跟踪  --- ## 8. [SQLAlchemy](https://github.com/sqlalchemy/sqlalchemy) SQLAlchemy 是一個用於處理資料庫互動的 Python 函式庫。 它是一個連接Python程式設計和關係資料庫的多功能工具包。 掌握這個庫的時間較長，但好處是實實在在的。 🔑特點： - SQL 表達式語言 - 物件關係映射（ORM） - 對資料庫的廣泛支持 - 複雜查詢支持  --- ## 9. [芹菜](https://github.com/celery/celery) Celery 是一個 Python 函式庫，用作建立後端應用程式的框架。 它處理分散式任務處理、作業執行和工作流程。 它是一個完整的解決方案和廣泛的功能集，具有更陡峭的學習曲線。 🔑特點： - 平行處理 - 可擴展性 - 任務調度 - 非同步處理  --- ## 10. [Peewee](https://github.com/coleifer/peewee) 與 SQAlchemy 一樣，Peewee 是一個簡化資料庫互動的 Python 函式庫。 它與競爭對手的不同之處在於用戶友好且簡單的設定。 該庫是中小型專案的最佳選擇。 🔑特點： - 輕量級框架 - 資料庫支持 - Python式文法  --- ## 11. [Kedro](https://github.com/kedro-org/kedro) Kedro 是一個開源 Python 框架。 它為生產就緒的資料科學管道提供了一個工具箱。 事實上，Kedro 可以輕鬆地與成熟的 Python ML 庫集成，並提供統一的方法來實現端到端框架。 🔑特點： - 資料目錄 - 筆記本集成 - 專案模板 - 有自己的觀點，因為它強制執行特定的約定  --- ## 結論 Python 被認為是人工智慧和機器學習應用程式的首選語言。 為了簡化和自動化這些應用程式，Python 見證了框架庫的出現。 這些程式庫有助於 Web 應用程式開發、後端服務以及開源全端應用程式的建立。 ---  我剛開始我的內容創作之旅；如果您有任何問題或回饋，請隨時與我們聯繫！ --- 原文出處：https://dev.to/taipy/full-stack-toolbox-python-edition-20h2
看更多文章： 1. [使用 gRPC 和微服務建立可擴展的通知系統](https://dev.to/suprsend/building-a-scalable-notification-service-with-grpc-and-microservices-l6d) 2. [在 React 網站中新增通知來源](https://dev.to/suprsend/adding-a-notification-feed-in-react-websites-4oa0) 4. [2023 年現代應用通知基礎設施完整指南](https://dev.to/suprsend/a-complete-guide-on-notification-infrastruct-for-modern-applications-in-2023-13b9) --- 應用程式通常可以分為兩種類型的效能瓶頸： 1. **I/O 限制：** 這些應用程式將大部分時間花在處理輸入和輸出上。 2. **CPU 限制：** 這些應用程式將大部分時間花在運算任務上。 現在，這些分類如何轉化為前端應用程式的上下文，特別是 React 應用程式？ **React 中的 I/O 效能挑戰** 當涉及到 React 應用程式時，經常會出現 I/O 效能方面的問題，主要與非同步 HTTP 呼叫相關。無效地管理這些網路請求可能會導致應用程式速度減慢。雖然這篇文章主要關注 CPU 效能，但有必要簡要介紹一下可以找到 I/O 限制問題解決方案的關鍵領域： - 盡可能實施延遲載入。 - 在初始載入資產和後端請求時請務必小心。 - 減少載入高度靜態元素的頻率（例如，選擇選項、配置）。 - 去抖特定請求的次數。 - 使用 Promise.all 等技術盡可能並行化請求。 - 透過優化資料庫存取等措施來提高關鍵後端端點的效率。 **React 中的 CPU 效能挑戰** 這篇文章的主旨是解決 React 中的 CPU 效能挑戰。在深入研究細節之前，讓我們先對效能建立一個具體的定義： - 瀏覽器應用程式主要作為單執行緒程式執行。 - 腳本任務，例如 JavaScript 執行、DOM 渲染和事件處理，都發生在同一個執行緒。 - 緩慢的 JavaScript 模組可能會阻塞主執行緒。 - 如果主執行緒被阻塞，使用者介面將變得無回應，導致每秒幀數 (fps) 下降。 - 響應式 UI 的目標是至少 30 fps，理想情況下達到 60 fps，這意味著每幀的計算時間應在 30 毫秒或更短的時間內。 在 React 的背景下，這個問題變得至關重要。當觸發 React 元件更新時，整個子樹必須在 30 毫秒內渲染完畢。對於複雜而冗長的元件結構（例如表、樹和列表），這變得尤其具有挑戰性，可能需要大規模重新渲染。 **反應渲染和提交階段** 從高層次來看，React 分為兩個不同的階段： **渲染階段：** - 當元件更新時啟動，由 props 或 hooks 的變更觸發。 - React 遍歷元件子樹，渲染每個子樹並計算虛擬 DOM (VDOM) 子樹。 - 只有受更新影響的「髒」子樹需要重新計算；更新元件的父元件可能不需要重新渲染。 - 此階段的效率與每個子元件的大小和計算成本成正比。 - React.memo 可用於提供更有效率渲染流程的提示。 **提交階段：** - 渲染階段產生整個 UI 的新虛擬 DOM。 - 在提交階段，React 將新樹與前一棵樹進行比較（VDOM 比較）。 - React 計算反映新 VDOM 樹所需的最小 DOM 突變。 - 套用 DOM 突變，更新 UI。 - 預設情況下，此階段本質上是高效的。 - 整個過程必須在 30 或 16 毫秒內完成（分別針對 30 fps 和 60 fps），UI 才會被視為回應。工作負載與應用程式的大小成正比。 後續探索將聚焦在提升Render階段的效率。在深入研究優化技術之前，了解如何測量和辨識應用程式中的緩慢元件至關重要。 **測量** 我經常依賴的工具包括： 1. **Chrome 開發工具的效能標籤** 2. **React Dev Tool 的效能標籤** **Chrome 開發工具的效能標籤** 該工具作為適用於任何瀏覽器應用程式的綜合資源而脫穎而出。它提供對每秒幀數的洞察、捕獲堆疊追蹤、辨識程式碼的慢速或熱點部分等等。主要使用者介面由火焰圖表示。 若要深入了解套用於 React 的 Chrome 效能選項卡，請參閱此[文件](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance)。 **React 開發工具的效能標籤** 若要利用此工具，您需要在瀏覽器中安裝 React Dev Tool 擴充功能。它專門針對 React 客製化了 Chrome 開發工具效能標籤中的資訊。透過火焰圖，您可以觀察不同的提交階段以及在對應渲染階段執行的 JavaScript 程式碼。 該工具有助於輕鬆確定： - 當元件進行重新渲染時。 - 哪些道具改變了。 - 哪些鉤子發生了變化，包括狀態、上下文等等。有關更多詳細訊息，請參閱[介紹性帖子](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)。 **測量方法** 這是我在評估前端應用程式時更喜歡的方法： 1. **確定問題：** - 找出導致 UI 回應問題的頁面互動。 2. **建立一個假設：** - （可選）產生有關問題的潛在位置的想法。 3. **測量：** - 透過測量每秒幀數 (fps) 等基本指標來驗證問題。 4. **測量（第二部分）：** - 辨識有問題的程式碼部分； （可選）驗證您的假設。 5. **建立解決方案：** - 根據收集到的見解實施解決方案。 6. **測量解決方案：** - 透過檢查關鍵指標來驗證實施的解決方案是否解決或緩解了問題。 在沒有適當衡量的情況下進行最佳化會使努力實際上變得無效。雖然有些問題可能很明顯，但大多數問題都需要徹底的測量，從而構成性能增強過程的基石。 此外，測量可讓您向上傳達成果，向使用者、利害關係人和您的領導層通報應用程式特定領域內實現的效能改進（以百分比增益表示）。 **React 應用程式中 CPU 限制問題的通用解決方案** 現在有了測量結果並了解了問題領域，讓我們深入研究潛在的解決方案。優化 React 效能圍繞著改進渲染的元件和渲染的元件。 許多效能問題也源自於反模式。消除這些反模式（例如避免渲染方法中的內聯函數定義）有助於提高渲染時間。事實上，解決不良模式可以降低複雜性並同時提高效能。 **🤔 改進元件渲染** 辨識 React 應用程式中的緩慢元件通常指的是難以渲染或單一頁面上實例數量過多的特定元件。多種原因可能導致他們行動遲緩： - 元件內的阻塞計算。 - 渲染大型元件樹。 - 使用昂貴或低效率的函式庫。 大多數這些問題都歸結為提高元件渲染的速度。有時，關鍵元件不能依賴過於複雜的函式庫，需要回歸基本原則並實施更簡單的替代方案。 例如，我在複雜表格中每行的多個單元格中過度使用 Formik 時遇到了此類挑戰。雖然提高單一元件的效率還有很長的路要走，但注意力最終必須轉移到正在渲染的元件上。 **🧙 改進哪些元件渲染** 這方面提供了兩大類改進： 1. **虛擬化：** - 僅渲染視窗中可見的元件。例如，僅呈現使用者可以看到的表格行或清單專案。事實證明，這種方法對於複雜的 UI 是有益的，雖然可以在不解決「內容」步驟的情況下應用它，但建議這樣做。現代函式庫通常為虛擬化表和清單提供強大的支持，例如“react-virtualized”。虛擬化減少了 React 需要在給定幀中渲染的元件數量。 2. **道具優化：** - React 的目標是使元件類似於純函數，但可能會嘗試渲染不必要的次數。 **反應.備忘錄：** - React 中的大多陣列件都可以被記憶，確保使用相同的 props，元件返回相同的樹（儘管鉤子、狀態和上下文仍然受到尊重）。如果它們的 props 保持不變，則利用 `React.memo` 通知 React 跳過重新渲染這些已記憶的元件。 ``` import React from 'react'; const MyComponent = React.memo((props) => { // Component logic here }); export default MyComponent; ``` **假道具更改：useCallback：** - 解決虛假道具更改問題涉及道具內容保持不變但引用發生變化的情況。一個典型的例子是事件處理程序。 ``` import React, { useCallback } from 'react'; const MyComponent = () => { const onChange = useCallback((e) => console.log(e), []); return <input onChange={onChange} />; }; export default MyComponent; ``` **假道具更改：useMemo：** - 在將複雜資料結構作為 props 傳遞之前，在沒有適當記憶的情況下建立複雜的資料結構時，也會出現類似的挑戰。利用「useMemo」可確保僅在依賴項發生變更時才重新計算行，從而提高效率。 ``` import React, { useMemo } from 'react'; const MyComponent = ({ data, deps }) => { const rows = useMemo(() => data.filter(bySearchCriteria).sort(bySortOrder), [deps]); return <Table data={rows} />; }; export default MyComponent; ``` 雖然您可以靈活地自訂「React.memo」如何比較目前與先前的道具，但保持快速運算至關重要，因為它是渲染階段不可或缺的一部分。避免在每次渲染期間過於複雜的深度比較。 ## 現在看起來怎麼樣？ ### 道具已更改 它在 React 開發工具中的樣子：  他們真的嗎？它們是假的道具更改嗎？使用`useCallback`和`useMemo`。 ### 父渲染 它在 React 開發工具中的樣子：  使用“React.memo”來記住您的純元件。 ### 掛鉤已更改（狀態、上下文） 它在 React 開發工具中的樣子：  這裡沒有什麼太明顯的事情要做。嘗試驗證更改的鉤子是否有意義。也許一個糟糕的上下文提供者正在以與假道具更改可能出現的方式相同的方式偽造更改。 --- > 與此類似，我個人在 Slack 上經營著一個由開發人員主導的社群。我們在其中討論這些類型的實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。 > 我邀請您加入我們的免費社區，參與討論，並分享您的驚人經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們擁有來自一些偉大公司（Atlassian、Scaler、Cisco、IBM 等）的出色人員，您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9) --- 您可能想要查看整合通知基礎架構的無縫方式。 https://github.com/suprsend/suprsend-go --- 原文出處：https://dev.to/nikl/react-is-slow-what-to-do-now-369g
Docker 是一個工具，允許開發人員將他們的應用程式及其所有依賴項打包到一個容器中。然後，這個容器就可以輕鬆地在任何安裝了 Docker 的機器上傳輸和執行，而不必擔心環境的差異。這就像是打包和執行軟體的標準化方式。 **容器是什麼？**  容器就像一個小包，其中包含程式執行所需的一切，可以輕鬆地在不同電腦上移動和執行，而不會造成任何麻煩。 最酷的部分是這個迷你電腦（容器）就像一個披著斗篷的超級英雄。它可以在任何電腦上執行，無論它們有多麼不同，因為它自帶特殊的環境。這是一種保持軟體井然有序的方式，並確保它無論在哪裡都能以相同的方式運作。  **為什麼我們需要 Docker？** 1. **一致性：** Docker 確保軟體在您的電腦、您朋友的電腦或任何電腦上以相同的方式運作。它使事情保持一致。 2. **可移植性：** 您可以將您的軟體及其朋友打包到 Docker 容器中，並且它可以移動到任何地方。這就像將您的遊戲及其所有規則放在手提箱中並在朋友家中玩。 3. **隔離：** Docker 容器就像小氣泡。氣泡內發生的事只會留在氣泡內。這意味著容器中的一個程式不會幹擾容器外的另一個程式。 4. **效率：** Docker有助於節省電腦資源。您可以讓許多容器在同一台電腦上執行，而不會相互妨礙，而不是讓一整台電腦只用於一個程式。 5. **速度：** Docker 讓啟動、停止和共享軟體變得快速、輕鬆。這就像打開和關閉遊戲機一樣 - 快速而簡單。 **什麼是 Docker 映像？**  Docker 映像像是程式及其運作所需的所有內容的快照。它是一個打包版本，包括程式碼、工具和設置，就像包含所有成分的餅乾食譜的快照一樣。 **圖像是配方，容器是當您按照該配方實際製作和執行程序時所得到的。** **一些基本的 Docker 命令。**  1. **`docker執行nginx`** - 此命令告訴 Docker 使用「nginx」映像執行容器。這就像告訴 Docker 啟動一個預製程式的新實例（nginx，它是一個 Web 伺服器）。 2. **`docker ps`** - 顯示正在執行的容器的清單。這就像檢查當前正在執行哪些程式。 3. **`docker ps -a`** - 顯示所有容器的列表，包括已停止的容器。這就像檢查您執行過的所有程式的歷史記錄。 4. **`docker stopsilly_sammet'** - 停止名為「silly_sammet」的正在運作的容器。這就像關閉當前正在執行的程式。 5. **`docker rmsilly_sammet'** - 刪除名為「silly_sammet」的已停止容器。這就像丟掉你不再需要的程式的指令一樣。 6. **`docker 映像`** - 列出您擁有的所有 Docker 映像。這就像查看您可以執行的所有不同程式的選單一樣。 7. **`docker rmi nginx`** - 刪除“nginx”圖像。這就像刪除您不想再使用的程式的配方。 8. **`docker拉nginx`** - 從網路下載「nginx」映像。這就像從食譜中獲取新食譜一樣。 9. **`docker 執行 ubuntu sleep 5`** - 使用「ubuntu」映像檔執行容器並使其休眠 5 秒。這就像啟動一個程序，只是等待一小會兒，然後就停止了。 10. **`docker exectracted_mcclintock cat /etc/hosts`** - 在名為「distracted_mcclintock」的正在執行的容器內執行命令。這就像在食譜書中偷看特定頁面一樣。 11. **`docker run -d kodekloud/simple-webapp`** - 從「kodekloud/simple-webapp」鏡像以分離模式執行容器。這就像啟動一個程式並讓它在背景執行。 12. **`docker Attach a043d`** - 將您的終端附加到 ID 為「a043d」的正在執行的容器。這就像跳入正在執行的程式來查看發生了什麼。 **一些 Docker 概念：** 1. **使用標籤執行：** - 標籤就像程式的版本。它指定您要執行哪個版本。 - 範例程式碼：`docker run nginx:latest` - 這將執行最新版本的 Nginx 程式。 2. **使用標準輸入執行：** - STDIN 就像在鍵盤上打字一樣。有些程式需要您的輸入。 - 範例程式碼：`docker run -i -t ubuntu` - 這會在 Ubuntu 容器內執行互動終端，讓您可以鍵入命令。 3. **使用連接埠映射執行：** - 連接埠就像門。程式使用它們與外界進行通訊。 - 範例程式碼：`docker run -p 8080:80 nginx` - 這將執行 Nginx，並打開電腦連接埠 8080 上的門，將其連接到容器的連接埠 80。 4. **使用磁碟區映射執行：** - 磁碟區就像共用資料夾。它們讓您可以將東西存放在容器之外。 - 範例程式碼：`docker run -v /your/local/folder:/container/folder nginx` - 這將執行 Nginx 並將電腦上的資料夾連接到容器內的資料夾。 5. **檢查容器：** - 檢查就像仔細檢查正在執行的程式。 - 範例程式碼：`docker檢查container_name` - 這為您提供有關正在執行或已停止的容器的詳細資訊。 6. **容器日誌：** - 日誌就像日記。他們記錄程式正在做什麼。 - 範例程式碼：“docker 日誌容器名稱” - 這會向您顯示特定容器的日誌或活動。 ##環境變數 環境變數就像程式用來尋找重要資訊的便利筆記，有點像是程式可以理解和更好工作的秘密訊息！ 1. **Python腳本（app.py）中的環境變數：** - 假設您有一個用 Python 寫的程式 (app.py)。您可能想要在不更改程式碼的情況下自訂它。您可以使用環境變數。 - 範例程式碼（app.py）： ``` import os app_color = os.getenv("APP_COLOR", "default_color") print(f"The app color is {app_color}") ``` - 正常運作腳本：`python app.py` - 以特定顏色執行：`export APP_COLOR=blue; python 應用程式.py` 2. **在 Docker 中使用 ENV 變數：** - Docker 容器也可以使用環境變數。這就像是向容器內的程式發出指令。 - 範例程式碼： - `docker run -e APP_COLOR=green simple-webapp-color` - 這會執行 Docker 容器（`simple-webapp-color`）並將環境變數 `APP_COLOR` 設為「綠色」。 3. **檢查環境變數：** - 有時，您會想要檢查正在執行的容器正在使用哪些環境變數。 - 範例程式碼：`docker檢查blissful_hopper` - 此命令提供有關名為“blissful_hopper”的容器的詳細訊息，包括其環境變數。 簡單來說，環境變數就像程式（或 Docker 容器）可以讀取以了解如何行為的小註釋。您可以在執行程式之前設定這些註釋，程式將使用它們來自訂自身。第二個範例中的「export」指令就像在執行程式之前寫一條註釋，告訴它如何運作。 “docker Inspect”指令就像是在容器內部查看它有什麼註解。 ## Docker 映像 **Docker 檔案：** Dockerfile 就像是 Docker 建立映像的一組指令。這就像是烤蛋糕的食譜。 ``` # Use the Ubuntu base image FROM Ubuntu # Update apt repository RUN apt-get update # Install dependencies using apt RUN apt-get install -y python # Install Python dependencies using pip RUN pip install flask RUN pip install flask-mysql # Copy source code to /opt folder COPY . /opt/source-code # Set the working directory WORKDIR /opt/source-code # Specify entry point to run the web server ENTRYPOINT ["flask", "run"] ``` **建立自己的圖像的步驟：** 1. 使用上述內容建立一個名為「Dockerfile」的檔案。 2. 將其保存在與原始碼相同的目錄中。 **建置 Docker 映像：** 在終端機中執行以下命令： ``` docker build -t your-image-name . ``` 此命令告訴 Docker 使用目前目錄中的 Dockerfile (`.`) 建置映像，並使用您選擇的名稱對其進行標記 (`-t your-image-name`)。 **分層架構：**  - 將 Docker 映像視為一個分層蛋糕。 Dockerfile 中的每個指令都會在映像上新增一層。 - 圖層可重複使用。如果您變更程式碼中的某些內容，Docker 只會重建受影響的層，從而提高效率。 **Docker 建置輸出：** - 當您建置映像檔時，Docker 會顯示流程中的每個步驟。如果發生故障，它會給您錯誤訊息。 **你可以容器化什麼？** - 幾乎所有東西！應用程式、服務、資料庫、網站，基本上任何軟體都可以容器化。 - 這就像將您的軟體放入一個盒子中，以便它可以在任何地方執行而不會造成麻煩。 ## 什麼是 Docker CMD 與 ENTRYPOINT **Docker 中的`CMD`：** - 將 CMD 視為啟動容器時程式執行的預設操作。 - 這就像說，“嘿，當你執行這個容器時，默認執行此操作。” - 範例：`CMD ["flask", "run"]` 表示當容器啟動時，它會自動執行 Flask Web 伺服器。 **CMD 範例：** ``` FROM alpine CMD ["sleep", "5"] ``` 在此範例中，當您使用此映像執行容器時，它會自動休眠 5 秒。 **Docker 中的`ENTRYPOINT`：** - 將 ENTRYPOINT 視為容器所做的主要事情。就好像boss的命令一樣。 - 它設定一個預設應用程式在容器啟動時執行，但您仍然可以根據需要覆蓋它。 - 範例：`ENTRYPOINT ["flask", "run"]` 表示容器主要用於執行 Flask Web 伺服器，但如果需要，您仍可新增更多指令。 **入口點範例：** ``` FROM alpine ENTRYPOINT ["sleep"] CMD ["5"] ``` 在這裡，主要目的是睡眠，如果您願意，您仍然可以覆蓋睡眠持續時間。 在這兩種情況下，容器在啟動時只會休眠幾秒鐘。主要區別在於如何提供參數以及它們是否可以輕鬆覆蓋。 CMD 就像在說，“這是默認要做的事情”，而 ENTRYPOINT 就像在說，“這是主要要做的事情，但如果你願意，你可以稍微調整一下。”它們都有助於定義容器啟動時執行的操作。 ## Docker 中的網路： Docker 網路幫助容器（程式）相互通信，確保它們可以順利地協同工作。 **預設網路：** - Docker 建立預設網路供容器通訊。 - 範例程式碼：`docker run ubuntu --network=host` - 這使用主機網路執行 Ubuntu 容器，這意味著它與主機共享網路命名空間。 **使用者定義的網路：** - 您可以建立自己的網路以更好地組織和控制。 - 範例程式碼： ``` docker network create --driver=bridge --subnet=182.18.0.0/16 custom-isolated-network ``` - 這將建立一個名為「custom-isolated-network」的使用者定義的橋接網絡，具有特定的子網。 **上市網路：** - 您可以查看您擁有的所有網路。 - 範例程式碼：`docker network ls` **檢查網路：** - 您可以檢查特定網路的詳細資訊。 - 範例程式碼：`docker網路檢查blissful_hopper` - 這顯示有關名為「blissful_hopper」的網路的詳細資訊。 **嵌入式 DNS：** - Docker 有一個內建的 DNS 系統，供容器透過名稱相互查找。 - 範例程式碼：`mysql.connect(mysql)` - 這可能是程式碼中的一行，其中名為「mysql」的服務使用 Docker 的 DNS 連接到另一個名為「mysql」的服務。 ## Docker 儲存：  Docker 儲存就像使用容器時決定將資料保存在哪裡一樣。您可以將它們保留在容器內，使用磁碟區在容器之間共用它們，或將它們儲存在容器外部以妥善保管。 **Docker中的檔案系統：** - Docker 使用分層架構來建立映像。 Dockerfile 中的每個指令都會在檔案系統中新增一個新圖層。 ``` # Dockerfile FROM Ubuntu RUN apt-get update && apt-get install -y python RUN pip install flask flask-mysql COPY . /opt/source-code WORKDIR /opt/source-code ENTRYPOINT ["flask", "run"] ``` - Dockerfile 中的層： - 第 1 層：Ubuntu 基礎層 - 第 2 層：apt 軟體包的更改 - 第 3 層：pip 套件的變化 - 第 4 層：原始碼 - 第 5 層：使用「flask」指令更新入口點 - 第 6 層：容器層 **影像圖層：** - 當您建立 Docker 映像時，它由唯讀層組成。每一層代表影像的變化或加入。 - 第 1 層：Ubuntu 基礎層 - 第 2 層：apt 軟體包的更改 - 第 3 層：pip 套件的變化 - 第 4 層：原始碼 - 第 5 層：使用「flask」指令更新入口點 ``` # Build the Docker image docker build -t mmumshad/my-custom-app . ``` **容器層：** - 當您執行 Docker 容器時，會在唯讀映像層上方新增一個讀寫層。該層特定於正在執行的容器。 - 第 6 層. 容器層 ``` # Run the Docker container docker run mmumshad/my-custom-app ``` **數量：** - 卷是一種在容器外部保存資料的方法。它們就像外部記憶體。 ``` # Create a Docker volume docker volume create data_volume # Use the volume in a container docker run -v data_volume:/var/mysql mysql ``` - 您也可以使用「-v」將特定目錄從主機掛載到容器： ``` # Mount a host directory to a container directory docker run -v /path/on/host:/var/mysql/mysql -d mysql ``` - docker run --mount 指令用於將主機上的特定目錄或檔案掛載到正在執行的 Docker 容器中。 ``` docker run --mount type=bind,source=/mysql,target=/var/mysql mysql ``` **儲存驅動程式：** - Docker 使用儲存驅動程式來管理資料的儲存和存取方式。一些常見的儲存驅動程式包括 AUFS、ZFS、BTRFS、Device Mapper、Overlay 和 Overlay2。 [在 Docker 管理資料](https://docs.docker.com/storage/) [關於儲存驅動程式](https://docs.docker.com/storage/storagedriver/) [卷](https://docs.docker.com/storage/volumes/) ## Docker 組合  Docker Compose 是一個方便的工具，可幫助您輕鬆執行和連接不同的軟體服務，就好像它們都是同一事件的一部分一樣。 **Docker Compose 基礎：** 1. **執行單一容器：** - 通常，您可以像這樣執行單獨的 Docker 容器： ``` docker run mmumshad/simple-webapp docker run mongodb docker run redis:alpine docker run ansible ``` 2. **Docker 撰寫文件（`docker-compose.yml`）：** - Docker Compose 允許您在一個簡單的檔案中定義所有這些服務： ``` # docker-compose.yml version: '3' services: web: image: 'mmumshad/simple-webapp' database: image: 'mongodb' messaging: image: 'redis:alpine' orchestration: image: 'ansible' ``` - 此檔案描述您要執行的服務（「web」、「database」、「messaging」、「orchestration」）、它們各自的映像以及任何其他配置。 3. **使用 Docker Compose 執行：** - 要一起啟動所有這些服務： ``` docker-compose up ``` - Docker Compose 負責啟動「docker-compose.yml」檔案中定義的所有容器。 4. **使用 Docker Compose 建置：** - 您也可以使用 Docker Compose 建置映像： ``` docker-compose build ``` - 此指令建置「docker-compose.yml」檔案中指定的映像。 **執行連結容器：** - 如果您要透過連結執行單一容器： ``` docker run -d --name redis redis docker run --name voting-app -p 5000:80 --link redis:redis voting-app docker run --name result-app -p 5001:80 --link db:db result-app docker run -d --name worker --link db:db --link redis:redis worker ``` - 在 Docker 中撰寫： ``` # docker-compose.yml version: '3' services: vote: image: 'voting-app' ports: - '5000:80' links: - 'redis:redis' result: image: 'result-app' ports: - '5001:80' links: - 'db:db' worker: image: 'worker' links: - 'db:db' - 'redis:redis' db: image: 'db' redis: image: 'redis' ``` Docker Compose 可讓您在單一檔案中描述整個應用程式堆疊，從而輕鬆管理、執行和連接不同的服務。這就像在一份計劃中寫下活動的所有任務，然後 Docker Compose 為您處理設定。 [Docker Compose 概述](https://docs.docker.com/compose/) [Docker 撰寫文件](https://docs.docker.com/engine/reference/commandline/compose/) ## Docker 註冊表  Docker 註冊表是人們儲存和分享 Docker 映像的地方，使其他人可以輕鬆使用和執行他們的軟體。它就像一個大型線上程式庫，可以輕鬆下載並在不同電腦上使用。 **Docker 註冊表基礎知識：** 1. **公共登記處：** - Docker 映像可以在 Docker Hub 等公共註冊表中儲存和共用。 - 例： ``` docker pull nginx ``` 2. **私人登記處：** - 有時，您可能希望將圖像保存在您自己的私人註冊表中。 - 例： - 登入私人註冊表： ``` bash docker login private-registry.io ``` - 從私有註冊表中的映像執行容器： ``` docker run private-registry.io/apps/internal-app ``` 3. **部署您自己的私有註冊表：** - 您可以為您的團隊或公司部署自己的私人註冊表。 - 例： - 在您的電腦上執行私有註冊表： ``` docker run -d -p 5000:5000 --name registry registry:2 ``` - 為私人註冊表標記您的圖像： ``` bash docker image tag my-image localhost:5000/my-image ``` - 將映像推送到您的私人註冊表： ``` bash docker push localhost:5000/my-image ``` - 從您的私人註冊表中提取映像： ``` bash docker pull localhost:5000/my-image ``` 4. **從遠端私有註冊表中提取：** - 您也可以使用 IP 位址或網域從遠端私有註冊表中提取映像。 - 例： ``` docker pull 192.168.56.100:5000/my-image ``` Docker 註冊表就像一個儲存空間，人們在其中保存和共享 Docker 映像。您可以將公用註冊表用於廣泛使用的映像，也可以根據您的特定需求設定自己的私人註冊表。它就像一個用於共享和儲存軟體藍圖（圖像）的特殊庫。 ## Docker 引擎  想像一下，你有一個魔盒（Docker Engine），可以為你執行和管理各種程式（容器）。 Docker Engine 就像是這個魔盒的大腦。 1. **Docker 守護程式：** - 守護程式就像魔法盒的看門人。它始終在那裡，隨時準備接受指示並確保一切順利進行。 2. **REST API：** - 將 REST API 視為一組允許您與魔盒對話的規則。它就像你和守護程式用來溝通的語言。你告訴守護程式要做什麼，它會理解，因為你們說的是同一種語言。 3. **Docker CLI（命令列介面）：** - Docker CLI 就像是用來命令守護程式的魔杖。您輸入指令，守護程式就會按照您的指示進行操作。這就像說「Abracadabra」就能讓事情發生。 **連線到遠端 Docker 引擎：** 連接到遠端 Docker 引擎可讓您控制另一台機器上的容器，且設定約束可確保容器僅使用指定的資源。 1. **Docker主機IP：** - 您可以使用 IP 位址和連接埠連接到不同電腦上的 Docker 引擎。 - 例： ``` docker -H=remote-docker-engine:2375 run nginx ``` - 這告訴您的本機 Docker CLI 與遠端 Docker 引擎進行通訊。 2. **有約束地執行容器：** - Docker 允許您設定容器的資源限制，例如 CPU 和記憶體限制。 - 例： ``` docker run --cpus=0.5 ubuntu docker run --memory=100m ubuntu ``` - 這些指令限制容器僅使用半個 CPU 核心和 100 MB 記憶體。 當然，讓我們簡化一下PID命名空間的概念： **命名空間PID：** PID 命名空間可讓您為容器中的進程（如程式或任務）建立單獨的區域，因此它們有自己的一組「票號」（進程 ID），不會與容器外的進程發生衝突。 **範例程式碼：** 1. **使用主機 PID 命名空間執行容器：** - 這表示容器與主機共用相同的「票號」。 ``` docker run --pid=host ubuntu ``` 2. **執行具有隔離 PID 命名空間的容器：** - 這表示容器有自己的一組獨立於主機的「票號」。 ``` docker run --pid=container ubuntu ``` 在第一個範例中，容器與進程交互，就好像它與主機位於同一空間中一樣。在第二個範例中，容器有自己的進程隔離空間。這就像在大型活動中擁有一個私人區域，您的團隊有自己的一套票號，讓您可以獨立於活動的其餘部分進行操作。 **容器化概念：** 1. **進程 ID 命名空間：** - 容器有自己獨立的流程 ID (PID) 空間，因此容器內的流程與容器外的流程是分開的。 - 例： ``` docker run --pid=host ubuntu ``` - 此指令使用主機的 PID 命名空間來執行容器，因此它共用相同的程序。 2. **網路命名空間：** - 容器也有自己獨立的網路命名空間，這意味著它們可以有自己的網路配置。 - 例： ``` docker run --net=host nginx ``` - 此指令使用主機的網路命名空間來執行容器。 3. **Unix分時命名空間：** - 此命名空間允許容器擁有自己的時間視圖，與主機和其他容器分開。 - 例： ``` docker run --uts=host ubuntu ``` - 此指令使用主機的 Unix 時間共用命名空間來執行容器。 4. **進程間掛載命名空間：** - Mount命名空間隔離檔案系統，讓容器擁有自己的檔案系統視圖。 - 例： ``` docker run --mount=type=bind,source=/host/folder,target=/container/folder ubuntu ``` - 此指令將主機中的資料夾安裝到容器中。 當然！我們來簡化一下cgroup的概念： **C組：** cgroup（控制組的縮寫）可協助在不同進程或容器之間管理和分配系統資源，例如 CPU 和記憶體。它們確保沒有任何一個進程或容器耗盡所有可用資源，從而保持一切平衡。 **範例程式碼：** 1. **使用 Cgroup 設定 CPU 限制：** - 這就像說聚會上的每位客人只能吃一定數量的食物。 ``` docker run --cpus=0.5 ubuntu ``` - 這限制容器僅使用一半的 CPU 核心。 2. **使用 Cgroup 設定記憶體限制：** - 這就像說每位客人只能在舞池上佔據一定的空間。 ``` docker run --memory=100m ubuntu ``` - 這限制容器僅使用 100 MB 記憶體。 [Docker 引擎概述](https://docs.docker.com/engine/) [使用 Docker Engine API 進行開發](https://docs.docker.com/engine/api/) [執行時指標](https://docs.docker.com/config/containers/runmetrics/#control-groups) ## Linux容器與Windows容器的概念： **Linux 容器（預設）：** Linux 容器是一種打包和執行軟體及其所需一切的方法，它們最適合執行 Linux 的電腦。 **Windows 容器：** Windows 容器是一種打包和執行軟體的方式，就像 Linux 容器一樣，但它們設計用於執行 Windows 的電腦。 **Windows 容器基礎：** 1. **集裝箱類型：** - Windows 容器有兩種主要類型：Windows Server Core 和 Nano Server。 - **Windows Server Core：** 將其視為功能更齊全的容器，適合各種應用程式。 - **Nano Server：** 將其視為一個輕量級容器，專為特定的、簡約的用例而設計。 2. **基礎鏡像：** - 基礎映像就像是建立容器時開始使用的空白畫布。 - 例： ``` docker pull mcr.microsoft.com/windows/servercore:ltsc2019 ``` - 此指令擷取 Windows Server Core 基礎映像。 - 例： ``` docker pull mcr.microsoft.com/windows/nanoserver:ltsc2019 ``` - 此命令提取 Nano Server 基礎映像。 3. **支援的環境：** - Windows 容器可以在特定版本的 Windows 作業系統上運作。 - 例： - 您可以在 Windows Server 2016 上執行 Windows 容器。 - 例： - 您可以在 Windows 10 專業版和企業版上執行 Windows 容器，並使用 Hyper-V 隔離容器進行額外隔離。 ## 容器編排  容器編排是一種管理和協調多個容器的方法，確保它們無縫協作來執行應用程式，就像一個超級智能的管理器確保所有機器人一起工作來建置完美的塔一樣。 **為什麼要編曲？** 1. **多項任務，一名經理：** - 想像一下您有許多機器人（容器）執行不同的工作。編排就像有一位超級聰明的經理（編排者），他告訴每個機器人該做什麼，並確保一切順利進行。 2. **一致性：** - 編排確保所有任務每次都以相同的方式完成。這就像為您的機器人提供了一套要遵循的指令，以確保其行為的一致性。 3. **效率：** - 編排有助於優化任務，確保資源（如時間和材料）有效利用。這就像經理確保所有機器人一起工作而不浪費能源。 4. **縮放比例：** - 當您需要完成更多工作時，編排可以輕鬆建立額外的機器人（容器）。這就像當有很多事情需要完成時神奇地召喚更多機器人來提供幫助。 5. **可靠性：** - 編排確保任務可靠地完成，即使機器人（容器）出現故障。這就像製定備份計劃來確保無論如何都能完成工作。 6. **協調：** - 編排協調任務，確保機器人無縫協作。這就像經理確保每個機器人都知道自己的角色並協作以實現總體目標。 **容器編排程式碼：** ``` # Create a Docker service with 100 replicas (instances) of a Node.js application docker service create --replicas 100 --name my-nodejs-app nodejs ``` 在這個例子中： - `docker service create`：該指令告訴 Docker 建立一個服務，該服務是一組正在執行的容器。 - `--replicas 100`：此標誌指定您需要 100 個服務實例（副本）。 - `--name my-nodejs-app`：此標誌為您的服務提供名稱，在本例中為「my-nodejs-app」。 - `nodejs`：這是 Node.js 應用程式的圖片或配方。這就像是烘焙紙杯蛋糕的藍圖。 因此，這段簡單的程式碼就像告訴您神奇的廚師助手 (Docker Swarm) 建立 Node.js 應用程式的 100 個副本，確保您有大量容器正在執行並準備好提供服務。 ## Docker 群  Docker Swarm 是一個工具，可以幫助協調和管理一組電腦（節點）作為一個機器人團隊一起工作，使它們能夠以協調的方式部署和執行多個容器。這就像有一個首席機器人經理，確保所有單一機器人一起建造出偉大而令人驚嘆的東西。 **設定 Docker Swarm：** 1. **群組管理器：** - 想像你有一個首席機器人（Swarm Manager）來領導團隊。主機器人決定需要做什麼，並指導其他機器人（節點）如何協同工作。 ``` # Initiate Docker Swarm on the Swarm Manager docker swarm init ``` 2. **節點工作人員：** - 現在，您的工作機器人（節點工作人員）已準備好加入團隊。 Swarm Manager 共享一個特殊的程式碼（令牌）來邀請他們一起工作。 ``` # Join a Node Worker to the Docker Swarm docker swarm join --token <token> <Swarm Manager IP> ``` **Docker Swarm 服務：** 現在您已經有了一個協調的團隊，您想要建立一項服務，例如與您的機器人團隊一起建造塔： ``` # Create a Docker service (a group of containers) with 3 replicas (instances) docker service create --replicas 3 --network frontend --name my-web-server my-web-image ``` - `--replicas 3`：此標誌告訴 Docker 建立服務的三個實例（副本）。 - `--network frontend`：此標誌指定您的服務屬於名為「frontend」的網路。 - `--name my-web-server`：這會為您的服務命名，在本例中為「my-web-server」。 - `my-web-image`：這是您的網頁伺服器的圖片或藍圖。這就像建造塔樓的配方。 您建立了一個由隊長（Swarm Manager）和工作機器人（Node Workers）組成的機器人團隊。然後，您指示他們建立一個執行您的 Web 伺服器應用程式的服務（容器群組）。主機器人確保建立 Web 伺服器的三個副本並將其連接到「前端」網路。這就像有一個首席機器人經理在工作機器人的幫助下監督多個塔（貨櫃）的建造。  **好的，這就是本文的內容。** 另外，如果您對此或其他任何問題有任何疑問，請隨時在下面的評論中或在 [Instagram](https://www.instagram.com/_abhixsh/) 、[Facebook](https://www.facebook.com/abhi.haththakage/) 或[Twitter](https://twitter.com/abhixsh)。 感謝您閱讀這篇文章，我們下一篇再見！ ❤️ --- 原文出處：https://dev.to/abhixsh/docker-for-the-absolute-beginner-3h1p
## 為什麼是書籍？ 在發展我的技能時，我喜歡結合使用會議演講、視訊教學、書籍、論文、部落格文章、邊做邊學和教學/部落格。書籍是從別人所犯的錯誤中學習、從他們的成功中受到啟發以及間接體驗他們的成就的好方法。 在這篇文章中，我想分享我最喜歡的書籍，這些書籍在我從高級軟體工程師到成為技術主管的過程中對我幫助最大。他們幫助我拓寬並加深了對軟體工程、軟體架構以及建構和經營軟體業務的理解。他們教我挑戰和塑造我的行為和習慣。其中一些深深影響了我的個人和職業生活。 不用說，閱讀這些書不會自動讓你升職或讓你擔任新的技術主管職位。當然，你還是需要自己的經驗，自己的錯誤，還需要一點運氣。根據您所從事的特定領域不斷提高您的技術知識和技能也很重要。此清單中的書籍並不關注特定技術，而是適用於任何技術堆疊和業務的一般原則和概念。 對於清單中的每本書，我都會附上一個簡短的摘要，可以幫助您判斷這本書是否與您相關。為了賦予它個人風格，我還將包括我從這本書中學到的最有價值的教訓。這不一定是這本書的主要訊息，也不是唯一重要的訊息，而是最能引起我共鳴的訊息。 ## 列表 ### 設計它！ [*Design It!: From Programmer to Software Architect*]((https://www.oreilly.com/library/view/design-it/9781680502923/)) Michael Keeling 是一本針對有志向的軟體開發人員的綜合指南轉變為軟體架構師的角色。本書提供了一種實用且易於理解的軟體架構方法，強調了設計在建立有效的軟體系統中的重要性。 Keeling 涵蓋了廣泛的主題，從軟體架構的基本原理到設計可擴展和可維護系統的實用技術。 在整本書中，基林提倡採用實踐、迭代的軟體設計方法，鼓勵讀者批判性地思考他們所做的架構選擇。他介紹了各種架構風格和模式，並討論如何評估權衡並做出符合專案目標和限制的決策。本書充滿了現實世界的範例、練習和實用技巧，對於那些希望發展軟體架構和設計技能的人來說是一個寶貴的資源。 **我從書中學到的最有價值的教訓：** 不存在「沒有設計」這樣的事情。 「無設計」通常意味著在工程師的腦海中存在多種、隱含的設計，這些設計彼此不一致。明確、協作、迭代地設計，並以書面記錄設計！ ### 釋放它！ Michael Nygard 的[*Release It!: Design and Deploy Production-Ready Software*](https://www.oreilly.com/library/view/release-it/9781680500264/) 是軟體開發人員和架構師的重要指南討論建立在生產環境中可靠運作的軟體所面臨的挑戰。本書深入探討了設計、部署和維護能夠承受現實世界操作嚴苛的軟體的複雜性。 Nygard 強調從設計過程一開始就考慮生產現實的重要性，並提倡從僅僅編寫程式碼到提供彈性、可擴展和可維護的系統的思維方式轉變。 Nygard 提供了對軟體系統在生產中遇到的各種陷阱的見解，例如網路問題、不可預測的負載模式和硬體故障。他介紹了穩定性模式和反模式等概念，說明如何建立能夠優雅地處理故障並在壓力下保持穩健的系統。這本書充滿了現實生活中的故事和案例研究，展示了生產環境中不良系統設計所造成的災難性後果。 “放開它！”對於軟體專業人士來說，這是一個寶貴的資源，他們希望確保他們的系統不僅能正常執行，而且在面對現實世界的挑戰時具有彈性和可靠性。 **我從書中學到的最有價值的教訓：** 每個軟體工程師都應該在建立他們的軟體時考慮到生產。生產中的軟體負責營運您的業務、影響您的客戶並決定成功或失敗。 ### 站點可靠度工程 [*站點可靠性工程：Google 如何執行生產系統*](https://www.oreilly.com/library/view/site-reliability-engineering/9781491929117/) 作者：Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall理查德·墨菲(Richard Murphy) 對Google 用於管理其大規模、高度可靠系統的實踐和原則進行了富有洞察力的探索。本書介紹了站點可靠性工程 (SRE) 的概念，這是一門將軟體工程與 IT 營運相結合的學科，重點是建立可擴展且可靠的軟體系統。 作者都是 Google 的 SRE 領域經驗豐富的從業者，他們分享瞭如何建置、部署、監控和維護強大且有彈性的系統的專業知識。他們深入研究了 Google 使用的具體策略和技術，例如設定服務等級目標 (SLO)、有效管理變更以及平衡發布速度與服務可靠性的需求。這本書涵蓋了一系列主題，從 SRE 團隊的組織方面到事件管理和事後分析文化等技術實踐。這本書提供了對世界上最熟練的工程組織之一的內部運作的罕見了解，對於參與大型系統的操作、維護和擴展的任何人來說都是寶貴的資源。 **我從書中學到的最有價值的教訓：** 不存在完美的系統。透過明確定義和衡量 SLO 和錯誤預算，您可以就可靠性和速度之間的權衡做出明智的決策。 ### 改變你的問題，改變你的生活 [*改變你的問題，改變你的生活：領導力、指導和生活的 12 種強大工具*](https://www.goodreads.com/en/book/show/6665149)，作者 Marilee Adams 探討了我們提出的問題可能會對我們的生活和職業生涯產生影響。亞當斯引入了「問題思維」的概念，這是一種透過深思熟慮和用心提問來轉變思維、行動和結果的方法。這本書強調了我們問自己的問題類型，從限制性的、判斷性的「判斷者」問題到更開放的、建設性的「學習者」問題，如何能顯著影響我們的觀點和結果。 亞當斯透過引人入勝的敘述闡述了她的想法，講述了一個人與生活挑戰作鬥爭並學習應用問題思維原則的故事。這種方法為個人提供了實用的工具和技術，以提高他們的溝通、決策和解決問題的能力。透過培養學習者心態並提出更好、更有說服力的問題，讀者可以被引導建立更積極、更有生產力的個人和專業關係。這本書對於領導者、教練以及任何希望增強與他人聯繫並更有效地駕馭複雜情況的能力的人來說特別有價值。 **我從書中學到的最有價值的教訓：**我意識到我經常處於「評判者」心態中。更加留意這一點，並有意識地選擇轉變為「學習者」心態，對我來說幾乎就像一種超能力，可以解決我面臨的任何挑戰。 ### 思考，快與慢 Daniel Kahneman 的 [*思考，快與慢*](https://www.amazon.de/-/en/Designing-Data-Intective-Applications-Reliable-Maintainable/dp/1449373321) 是對心理學與經濟學，深入研究我們如何思考和做出決策。卡尼曼介紹了兩種主導我們心理過程的不同思維模式：「系統1」（快速、直覺和情緒）和「系統2」（較慢、更深思熟慮和更邏輯）。卡尼曼在整本書中探討了這兩個系統對我們的判斷、決策以及我們感知周圍世界的方式的影響。 這本書全面探討了影響我們日常思維的各種認知偏見和啟發法。卡尼曼展示了我們的直覺系統 1（通常對我們很有幫助）也可能導致嚴重的錯誤和偏見。他也探討了系統 2 的功能和局限性，強調系統 1 的快速判斷如何影響和推翻它。這本書綜合了數十年的研究，提供了對人類思想和行為的複雜性的深入見解。對於任何有興趣了解我們在個人和職業環境中的選擇和行為背後的心理過程的人來說，這是一本必讀的書。 **我從書中學到的最有價值的教訓：**我了解到這兩種模式都很有價值，但也有其缺點。我學會了更了解影響我思考的偏見和啟發法，並有意識地選擇何時依賴系統 1，何時使用系統 2。 ### 原子習慣 James Clear 的[*原子習慣：一種簡單且行之有效的建立好習慣和改掉壞習慣的方法*](https://jamesclear.com/atomic-habits) 是一本變革性的指南，深入研究了習慣的科學以及習慣的小習慣改變可以帶來顯著的結果。作者提出了一個理解習慣如何形成的全面框架，並提供了培養好習慣和改掉壞習慣的實用策略。這本書的核心理念是，隨著時間的推移，微小的改進或「原子習慣」可以累積成重大的、改變生活的結果。 克利爾強調系統比目標更重要，他認為專注於實現目標的流程和系統比專注於目標本身更有效。他介紹了行為改變四定律──一套簡單、可操作的原則來引導習慣的形成。其中包括使線索明顯、渴望有吸引力、反應簡單以及獎勵令人滿意。透過結合科學研究、個人故事和現實世界的例子，克利爾闡述如何將這些原則應用於生活的各個方面，從健身和財務管理到生產力和個人成長。 《原子習慣》為培養持久的習慣提供了一個易於理解且引人注目的藍圖，對於任何想要在生活中做出積極、持久改變的人來說都是有價值的。 **我從這本書中學到的最有價值的教訓：** 透過對我的日常生活進行許多小改變，這些改變單獨地只會對我的生產力產生很小的影響，所有這些習慣結合起來會產生巨大的影響。 ### 有意識的商業 Fred Kofman 的 [*Conscious Business: How to Build Value Through Values*](https://www.amazon.de/-/en/Fred-Kofman/dp/1622032020) 是一本發人深省的書，探討了個人誠信和職業成功。作者提出了這樣的觀點：建立成功且可持續發展的企業的關鍵在於有意識的管理實踐，其中個人價值觀和道德原則處於決策過程的最前沿。該書認為，商業上的成功不僅在於經濟收益，還在於實現個人和職業成就。 科夫曼討論了有意識的商業的各個方面，包括問責制、責任、情緒智商、溝通技巧以及建設性解決衝突的能力。他強調領導者能夠激發信任、培養開放和誠實的文化並以同理心領導的重要性。透過現實世界的例子、實用的建議和練習，科夫曼指導讀者如何發展這些技能並將其應用到他們的職業生活中。 **我從書中學到的最有價值的教訓：**無條件回應能力的概念。我現在不斷提醒自己，無論情況如何，我都有權力和責任選擇對任何情況的反應。 「響應能力」是「響應」和「能力」的雙關語，強調自覺、主動回應的能力。 ### 首先，打破所有規則 [*首先，打破所有規則：世界上最偉大的管理者的不同做法*](https://store.gallup.com/p/en-us/10286/first-break-all-the-rules) 作者：Marcus Buckingham柯特·科夫曼（Curt Coffman）根據蓋洛普組織的研究提出了一種激進的管理方法。本書挑戰了有關領導力和管理的傳統智慧，提出最有效的管理者往往會違反標準做法。 本書的核心訊息是，偉大的管理者不會遵循單一模式或嚴格遵守傳統的管理原則。相反，他們透過專注於員工的個人優勢而不是試圖糾正他們的弱點來打破規則。作者認為，這種方法可以提高敬業度、生產力和整體工作滿意度。 白金漢和科夫曼確定了使世界上最好的管理者脫穎而出的關鍵見解和策略。其中包括選擇人才而不是簡單地填補職位的重要性，定義正確的結果而不是規定正確的步驟，關注優勢而不是沉迷於劣勢，以及為員工找到合適的人選而不是簡單地將他們晉升到下一個梯級。梯子。 **我從書中學到的最有價值的教訓：** 專注於優勢而不是劣勢的重要性。我學會了接受自己的弱點，並使用工具和策略來彌補它們，而不是試圖「修復」它們。相反，我投入時間和精力來發展自己的優勢，並嘗試為我所領導的人做同樣的事情。 ## 榮譽獎 在我從高級軟體工程師到技術主管的旅程中，我發現還有很多有價值的書籍。它們更專注於特定技術，這就是為什麼我沒有將它們包含在主列表中。儘管如此，我想在這裡提及它們，因為它們可能與您相關，具體取決於您所從事的領域/行業。 - [*資料庫內部架構*](https://www.databass.dev/)，作者：Alex Petrov。我讀過的「最好的」資料庫書籍。它以一種非常容易理解的方式涵蓋了資料庫的所有基礎知識。對於任何使用資料庫的人來說，這是一本必讀的書。 - [*設計資料密集型應用程式*](https://www.amazon.de/-/en/Designing-Data-Intential-Applications-Reliable-Maintainable/dp/1449373321) 作者：Martin Kleppmann。建立資料密集型應用程式的綜合指南。它涵蓋了廣泛的主題，從資料庫和資料處理到分散式系統和串流處理。 - [*Oracle JRockit：權威指南*](https://www.packtpub.com/product/oracle-jrockit-the-definitive-guide/9781847198068)，作者：Marcus Hirt 和 Marcus Lagergren。對於任何對 JVM 內部結構感興趣的人來說，這是一個很好的資源。 - [*Linux 程式介面*](https://man7.org/tlpi/) 作者：Michael Kerrisk。這是一本關於 Linux 的非常詳細的書，涵蓋了廣泛的主題，從基本的系統呼叫到進程組、訊號和套接字等高級主題。 ## 最後的想法 雖然書籍是個很好的學習工具，但它們並不能取代第一手經驗。你仍然需要犯自己的錯誤並從中學習。與他人討論你讀過的書，了解他們的觀點並挑戰你自己的觀點也很有幫助。也許您可以加入讀書俱樂部，或與同事或朋友一起閱讀。 我希望這份清單對您的職業生涯有所幫助。如果有一本書啟發了您並且您認為應該在此列表中，請在下面的評論中告訴我。 --- 原文出處：https://dev.to/frosnerd/books-that-helped-me-become-a-tech-lead-3831
## 你好呀！  首先，讓我給你一些背景資訊。 [直到最近](https://help.heroku.com/RSBRUH58/removal-of-heroku-free-product-plans-faq)，**Heroku** 有一個很好的免費層，可以讓您部署和測試東西與他們的馬力機。使用起來很輕鬆。但隨著這一免費層的取消，開發人員不得不尋找新的平台來部署他們的專案。 幸運的是，有許多新的託管提供者不斷湧現。但**實際上選擇部署位置**可能與為專案編碼一樣具有挑戰性。  這就是為什麼在本文中，**我將展示其中一些** **選項**，用於免費在線託管您的應用程式。我們將快速了解每個提供者最擅長的領域，以便您可以做出明智的決定，並讓您的應用程式上線。 --- ### 快速提醒 在開始部署我們的應用程式之前，請務必閱讀您選擇的框架提供的部署指南。 [React](https://create-react-app.dev/docs/deployment/)、[NextJS](https://nextjs.org/docs/pages/building-your-application/deploying)、[Wasp](https://wasp-lang.dev/docs/advanced/deployment/overview)，而且大多數目前框架都有非常好的部署指南（甚至是讓這些部署更容易的平台）。 因此，您的框架選擇可能會對您的託管提供者產生很大影響！  ## 支持我們！ 🙏⭐️ 順便說一句，我是 Wasp 團隊的一員，如果您能檢查我們的全端 React/NodeJS/Prisma 框架並[給我們一顆星](https://kdta.io/github-黃蜂-lang-wasp_14 )。 我們正在努力幫助開發人員盡可能快速、輕鬆地從想法到部署（例如，單一命令、全端部署），感謝所有幫助！ 好的。現在，讓我們探索一些在免費託管應用程式時提供絕佳選擇的雲端平台。 ### 韋爾塞爾  如果您正在部署前端應用程式，那麼這裡的體驗是難以比擬的。免費套餐**真的**很好。我有大約 20 個小型網站在 Hobby 計劃上執行，但無法減少使用量。 除此之外，部署的簡單性也令人驚訝。  您所要做的就是選擇一個 github 儲存庫，如果他們檢測到您正在使用主要框架之一，您可能甚至不需要配置任何內容！他們會處理好這一切，您的應用程式將在幾秒鐘內執行。  不幸的是，對於後端和資料庫 [Vercel](https://vercel.com/) 仍然不是一個很好的選擇。如果你有一個非常小的後端（並且專注於NodeJS），你可以嘗試使用[Vercel 的函數](https://vercel.com/docs/functions/serverless-functions) 基礎設施在這裡部署，儘管它們在以下方面受到限制：執行時間和複雜性。 對於更複雜的後端，我們將不得不看看下面的一些提供者。 ### 鐵路  [Railway](https://railway.app/) 是一個可讓您輕鬆部署 Web 應用程式和 API 的平台。當您註冊時，它提供每月**價值 5 美元的免費使用**的免費套餐。 只需幾個命令，您就可以部署應用程式並立即啟動並執行。它有一個非常漂亮的 UI，整體部署體驗也很好！ 順便說一句，我真的很喜歡他們決定展示物品和容器的方式。這是一種非常聰明的方式來概覽事物，而不是數百個小應用程式。有時，[簡單地將事物分組](https://lawsofux.com/law-of-common-region/) 會對使用者體驗產生重大影響，如下所示：  它還支援 React、Next.js 和 Node.js 等流行框架。此外，它還提供一鍵式資料庫設定和[社區建立的模板](https://railway.app/templates)，可以顯著簡化為專案設定 Dockerfile 的過程。  以下是它的基本當前價格，每月 5 美元（他們每月給你使用）實際上足以讓你擁有一些專案（如 2 - 3 個小型網站、後端和資料庫）和如果您知道如何正確設置它們（例如，將它們設定為在不使用時自動睡眠），請執行。  他們在應用程式設定頁面中有此選項。在那裡，您還可以找到其他可以更改的有趣的配置選項，例如網域、執行狀況檢查端點等。 ### 使成為  Render 是另一個用戶友好的雲端平台，提供**良好的免費套餐**並支援廣泛的應用程式。它簡化了部署和擴展應用程式的過程，並支援多種程式語言和框架。 Render 的免費套餐包括（每月）： - 500 管道建設分鐘 - 100GB 頻寬 唯一的例外是他們的 **Cron Jobs 服務（您的情況可能不需要，特別是如果您正在利用 [Wasp 的內建作業](https://wasp-lang.dev/docs/advanced) /jobs），每月最低費用為1 美元。**   它的功能真的很強大！我能夠部署資料庫、NestJS 應用程式和 NextJS 前端，所有這些都可以與遷移、Prisma ORM 等一起使用！它有一些很好的事件追蹤（儘管它可以呈現得更好——有時，螢幕上有太多元素）。  而且它還具有一些可觀察性功能！您可能認為這些不會在非常小的應用程式上使用，但是，當您在生產環境中偵錯事物時，您擁有的每個工具都可以產生有關問題的新見解。   ### 飛  [Fly](https://fly.io/)是專注於全球邊緣運算的雲端平台。 Fly 專注於高效能託管，並提供全球邊緣站點網路。 Fly 以其可擴展性和性能優化而聞名。  它支援各種程式語言和框架，讓您可以建立和部署功能強大的應用程式，並且在部署過程中，您只需下載[flyctl](https://fly.io/docs/hands-on/install-flyctl/)現在您就可以出發了！  順便說一句，Wasp 框架支援使用 Fly! 的單一命令部署！您可以在[此處](https://wasp-lang.dev/docs/advanced/deployment/manually#flyio)查看有關它的更多資訊！  它還可以容納一些小物品，但當我們查看實際價值時，成本會變得有點陡峭：  對於服務質量，它有一些不錯的監控儀表板和 Sentry 集成，這似乎非常有用。您也可以使用 SSH 輕鬆檢查應用程式日誌！  ### 網路化  Netlify 以其出色的免費套餐而聞名，並提供各種功能來建立和部署網站。話雖如此，它更像是 Vercel 的直接競爭對手，因為它專注於前端和靜態內容。 與 Vercel 一樣，它並不適用於強大的後端，但它也可以選擇託管無伺服器功能，您只需將資料庫託管在其他地方即可。 它使用為每個框架量身定制的特定建置器，為主要框架提供出色的支援。他們的[部署文件](https://docs.netlify.com/configure-builds/overview/?_gl=1%2a10z7npm%2a_gcl_au%2aMTcyNzA3MDU2My4xNzAyNjUxODAx#basic-build-settings)非常全面且有幫助。  透過 Netlify，您可以利用其內容交付網路 (CDN) 為使用者提供快速的靜態內容交付。它們提供了一系列功能來幫助您建立和優化您的網站。 Netlify 的免費方案包括： - 每月 300 分鐘建置時間 - 每月 100GB 頻寬 Netlify 因其易用性和強大的功能而受到開發人員的歡迎。它是託管靜態網站或 [Jamstack](https://jamstack.org/) 應用程式的絕佳選擇。  他們還有一些主要的框架建置執行時，可以簡化您的流程！ ### 結論 如果您還沒有為 [Wasp 的儲存庫](https://www.github.com/wasp-lang/wasp) 加註星標，我建議您這樣做！它可以幫助我們每週為您帶來這樣的免費內容。另外，它是最好的、沒有廢話的全端框架，可以減少開發時間並完成專案。 在免費託管您的應用程式時，重要的是要考慮每個平台的特定功能和限制。每個平台都有自己的優勢，選擇最適合您的需求和要求的平台非常重要。 以下是您的視覺回顧：  嘿！您想查看有關所有這些平台的更深入的文章嗎？留在評論區！ --- 原文出處：https://dev.to/wasp/top-5-ways-to-host-your-full-stack-app-for-free-c2j
## 介紹 幾天前，我在我曾經就讀的大學舉辦了一場關於 Kubernetes 及其元件的演講。我媽媽說她喜歡這個演講，所以我把它變成了一篇部落格文章。 許多軟體工程師傾向於忽視與 Kubernetes 相關的任何東西，儘管他們可能每天都會使用它。乍一看，它似乎很複雜，就像一個需要潛入的全新世界。是的，確實如此，但在這篇文章中，我將介紹 Kubernetes 叢集的所有主要元件，並在範例中解釋它們的作用。 在這篇文章結束時，您不會成為 Kubernetes 專家，但您可能會很好地了解要尋找什麼以及如何建立 Kubernetes 最初看起來的混亂狀態。 *代表 Kubernetes 架構的圖片取自 [Kubernetes 網站](https://kubernetes.io/docs/concepts/overview/components/)* ### **向我們展示您的支持🙏🏻**  在我們開始之前，如果您為我們的儲存庫加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興。我們的 GitHub 儲存庫位於：https://github.com/cyclops-ui/cyclops ⭐ ## 成分 首先，我們可以將 Kubernetes 叢集分為兩部分：**控制平面**和**工作節點**。控制平面負責整個操作並控制集群的狀態。我們很快就會了解這意味著什麼。另一方面，我們的工作節點本質上只是監聽控制平面告訴它們要做什麼的電腦。它們是我們集群的運算能力。我們在叢集中執行的任何應用程式都將在這些節點上執行。 讓我們進一步分解。 ### 控制平面  正如我們所說，控制平面確保我們的叢集能如預期運作。它透過與叢集用戶通訊、調度工作負載、管理叢集狀態等來實現這一點。 控制平面由四個關鍵元件組成。它們本身很簡單，但一起建立了一個複雜的系統。這些元件是： - **API** - **ETCD** - **調度程序** - **控制器經理** 控制平面元件可以在叢集中的任何機器上執行，但通常在一組單獨的機器上執行，通常稱為**主節點**。這些機器不用於執行任何其他容器或應用程式，而是為 Kubernetes 控制平面保留。 #### API Kubernetes API 充當叢集的前端接口，允許使用者與叢集互動、定義所需狀態以及執行建立、更新和刪除資源等操作。 這是我們與集群的**唯一聯繫點**。此外，沒有其他元件直接相互通信，但所有通信都是透過 API 進行的。 #### ETCD ETCD 是 API 的**資料庫**；就這麼簡單。當您告訴 Kubernetes 建立部署時，它會與所有其他建立的資源一起儲存在 ETCD 中。 ETCD 的一個特點是它的鍵值儲存被組織為檔案系統。 ETCD 的另一個出色功能是用戶可以**訂閱**事件並獲得有關更改的通知。例如，*建立新 Pod 時讓我知道*。 #### 調度程序 顧名思義，調度程式**決定 pod 將在哪個節點上執行**。它透過一組規則來實現這一點，您可以在 [Kubernetes 文件](https://kubernetes.io/docs/home/) 中閱讀。 *這就是我說你不會成為專家時的意思，但你會知道要谷歌什麼:)* 調度程序**訂閱**保存在 ETCD 中的所有新建立的 pod，但它**只能**與 API 通訊來取得此更新。 當它發現 Pod 已建立時，它會計算在哪個工作節點上執行它。一旦決定，**調度程序不會在任何機器上執行任何東西**；它只是告訴 API 在特定節點上執行 pod。 #### 控制器管理器 控制平面的最後一個元件是控制器管理器。我們可以把它當作我們集群的恆溫器。它的工作是將集群的當前狀態轉變為所需的狀態。 這意味著它將**在幕後建立所有需要的資源**來滿足我們的需求並使我們的應用程式啟動並執行。 它執行多個控制器進程，這些進程訂閱了 ETCD 上的更改，並編譯成相同的二進位檔案以便於部署。控制器管理員的角色以及這些控制器的作用將在部落格後面進行更詳細的定義。 ### 工作節點  現在我們已經了解了整個叢集的管理方式，接下來讓我們深入了解容器在哪裡運作以及如何實現這一點。 Kubernetes 叢集中的每個節點上執行 3 個元件。當然，您可以在叢集中擁有多個節點，但每個節點都需要這三個元件來託管您的應用程式。 那些是： - **容器運作時** - **kubelet** - **成為代理** #### 容器執行時 允許 Kubernetes 執行容器並管理節點上容器的生命週期的元件是容器執行時。 支援多個容器執行時，例如[conatinerd](https://containerd.io/)、[cri-o](https://cri-o.io/) 或其他[CRI 相容執行時](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。 #### 庫貝萊特 另一個訂閱 pod 事件的元件是 Kubelet。每次在節點上調度 pod 時，該節點上執行的 Kubelet 都會聽到該訊息並啟動所有定義的容器。最重要的是，Kubelet 還執行健康檢查，以確保一切能如預期運作。 #### 成為代理 Kubernetes 中的 KubeProxy 管理叢集中 pod 之間的網路連接，處理負載平衡和網路路由等任務。它透過維護網路規則並將服務抽象轉換為可操作的網路策略來確保 Pod 之間的無縫通訊。 ## 從部署到正在執行的容器 現在我們已經列出了 Kubernetes 叢集中的所有元件及其角色，接下來讓我們講述一個有關 Kubernetes 部署如何成為在叢集中的各種電腦上執行的一組容器的故事。 ### Pod、副本集和部署 快速提醒這三者的關係：Pod、Replicaset 和 Deployment。  我們可以在 Kubernetes 叢集中部署的最小單元是 **pod**。有了它，我們將定義我們的容器。 最有可能的是，我們需要同一應用程式的幾個實例，並且我們可以定義如何使用 **Replicaset** 複製我們的 pod。它將透過啟動和終止來確保我們有所需數量的 Pod 執行。 太棒了，現在我們已經複製了我們的應用程式，但我們想推出新版本的應用程式。我們必須拆除現有的 Pod/Replicaset 並建立新的。部署將自動執行此流程，使我們能夠安全地推出我們的功能。 ## 威望  現在我們已經了解了所有術語並觸及了所有 Kubernetes 元件及其角色，讓我們看看當我們將 Deployment「套用」到 Kubernetes 叢集時會發生什麼。 假設我們已經建立了一個定義應用程式的「deployment.yaml」檔案（您可以在[此處](https://imgur.com/7qKp189)了解如何執行此操作）並執行「kubectl apply -f deployment. yaml” 。 `kubectl` 現在將把我們的部署定義提交到叢集的**唯一的聯絡點** - Kubernetes API。 我們的簡單 API 將把我們的部署儲存在 ETCD 資料庫中。每次將 Deployment 物件儲存到 ETCD 時，它都會讓 API 知道 Deployments 發生了更改，並且它應該讓**每個訂閱此類事件的人**知道這一點。 控制平面中有一個元件想要知道何時產生新的部署，這就是**控制器管理器**。當它聽到新的 Deployment 時，它將根據 Deployment 配置建立一個新的 Replicaset。為了建立此 Replicaset，它將透過建立請求來呼叫 API。 建立 Replicaset 與建立 Deployment 非常相似。 API 將接收一個 Replicaset 來建立並儲存到 ETCD 中。這將使 ETCD 告訴 API 有人建立了一個 Replicaset 並將該資訊傳遞給所有訂閱的元件，這又是控制器管理器。 當 Controller Manager 聽到新的 Replicaset 時，它會透過呼叫 API 來建立使用該 Replicaset 定義的所有 Pod，您猜對了，該 API 會將所有這些 Pod 儲存到 ETCD 中。  *正如我們所說，發生了很多事情，因此我們決定建立一個 GIF 來幫助您了解整個過程。* 在這裡，我們包括了 Scheduler，它訂閱了 Pod 建立事件。每次聽到新的 Pod 時，它都會決定應該在哪個節點上執行。 Scheduler 並沒有執行 Pod，只是告訴 API** 它為其選擇了哪個節點。然後 API 將保存該資訊。 另一個監聽 Pod 事件的元件是 Kubelet，它是執行在 Kubernetes 叢集中每個工作節點上的元件。每次 API 告訴 Kubelet Scheduler 決定在其節點上執行 Pod 時，Kubelet **將啟動 Pod 定義的所有容器**。 最後，我們將配置變成了在機器上執行的應用程式！這是一個漫長的過程，有很多移動部分，但這可能是我最喜歡的部分。 每個元件只承擔部署應用程式的一小部分責任，但它們一起解決了一個相當複雜的問題。 ## 最後的想法 希望本文能幫助您掌握 Kubernetes 元件，並幫助您揭開最受歡迎的編排器的神秘面紗。我們鼓勵您自行挖掘，因為我們很高興了解這一點。 我們推薦學習 Kubernetes 的一本書是 Marko Lukša 的《Kubernetes in action》。它非常受歡迎，並且很好地概述了 Kubernetes 背後發生的事情以及如何使用它。 --- 原文出處：https://dev.to/cyclops-ui/complexity-by-simplicity-a-deep-dive-into-kubernetes-components-4l59
如今，軟體開發的最大變化是部署頻率。產品團隊更早（並且更頻繁）地將版本部署到生產中。長達數月或數年的發布週期變得越來越罕見，尤其是對於建立純軟體產品的人來說。 如今，使用服務導向的架構和微服務方法，開發人員可以將程式碼庫設計為模組化。這使他們能夠同時編寫程式碼庫的不同部分並將其部署到程式碼庫的不同部分。 縮短部署週期的商業優勢是顯而易見的： * 縮短上市時間 * 客戶在更短的時間內獲得產品價值 * 客戶回饋也更快回流到產品團隊，這意味著團隊可以更快地迭代功能並解決問題 * 開發人員整體士氣上升 然而，這種轉變也為營運或 DevOps 團隊帶來了新的挑戰。隨著部署更加頻繁，部署的程式碼更有可能對網站可靠性或客戶體驗產生負面影響。這就是為什麼制定程式碼部署策略以最大限度地降低產品和客戶的風險非常重要。 在本文中，我們將討論一些不同的部署策略、最佳實踐和工具，它們將使您的團隊更快*且*更可靠地工作。 --- ## 現代應用的挑戰 現代應用程式通常是分散式且基於雲端的。它們可以彈性擴展以滿足需求，並且由於高可用的架構，對故障的恢復能力更強。他們可以利用完全託管的服務，例如[AWS Lambda](https://aws.amazon.com/lambda/) 或[Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) ，其中平台承擔一些營運責任。 這些應用程式幾乎總是有頻繁的部署。例如，行動應用程式或消費者 Web 應用程式可能在一個月內經歷多次變更。有些甚至每天多次部署到生產中。 他們經常使用微服務架構，其中多個元件協同工作以提供完整的功能。不同的元件可以有不同的發布週期，但它們都必須無縫地協同工作。 活動部件數量的增加意味著出現問題的可能性更大。由於多個開發團隊對整個程式碼庫進行更改，當問題不可避免地發生時，可能很難確定問題的根本原因。 另一個挑戰：基礎設施層的抽象，現在被視為程式碼。新應用程式的部署可能還需要部署新的基礎架構程式碼。 ## 流行的部署策略 為了應對這些挑戰，應用程式和基礎架構團隊應該設計並採用適合其用例的部署策略。 我們將回顧幾種不同的部署策略並討論幾種不同部署策略的優缺點，以便您可以選擇適合您的組織的策略。 ## “大爆炸”部署 顧名思義，「大爆炸」部署會一次更新應用程式的全部或大部分。這種策略可以追溯到軟體在實體媒體上發布並由客戶安裝的時代。 大爆炸部署要求企業在發布之前進行廣泛的開發和測試，通常與大型順序發布的[「瀑布模型」](https://en.wikipedia.org/wiki/Waterfall_model)相關。 現代應用程式的優點是可以在客戶端或伺服器端定期自動更新。對於現代團隊來說，這使得大爆炸方法變得更慢、更不靈活。 大爆炸部署的特點包括： * 所有主要部分都打包在一個部署中； * 用新版本很大程度上或完全取代現有軟體版本； * 部署通常會導致較長的開發和測試週期； * 假設失敗的可能性很小，因為回滾可能是不可能或不切實際的； * 完成時間通常很長，需要多個團隊的努力； * 要求客戶端採取行動更新客戶端安裝。 大爆炸部署不適合現代應用程式，因為對於面向公眾或關鍵業務應用程式來說，風險是不可接受的，因為中斷意味著巨大的財務損失。回滾通常成本高、耗時，甚至不可能。 大爆炸方法適用於非生產系統（例如，重新建立開發環境）或供應商打包的解決方案（例如桌面應用程式）。 ## 滾動部署 滾動、分階段或分步部署比大爆炸部署更好，因為它們最大限度地減少了許多相關風險，包括無法輕鬆回滾的用戶面臨的停機時間。 在滾動部署中，應用程式的新版本逐漸取代舊版本。實際部署需要一段時間。在此期間，新舊版本將共存，不會影響功能或使用者體驗。此過程可以更輕鬆地回滾與舊元件不相容的任何新元件。 下圖顯示了部署模式：叢集中每台伺服器的舊版本顯示為藍色，新版本顯示為綠色。  應用程式套件升級是滾動部署的一個範例。如果原始應用程式部署在容器中，則升級一次可以處理一個容器。每個容器都經過修改，可以從應用程式供應商的網站下載最新的映像。如果其中一個應用程式有相容性問題，舊映像可以重新建立容器。在這種情況下，套件應用程式的新舊版本會共存，直到每個應用程式都升級為止。 ## 藍綠、紅黑或 A/B 部署 這是另一個自動防故障過程。在這種方法中，兩個相同的生產環境並行工作。 一種是目前正在執行的生產環境，接收所有使用者流量（顯示為藍色）。另一個是它的克隆，但閒置（綠色）。兩者都使用相同的資料庫後端和應用程式配置：  新版本的應用程式部署在綠色環境中，並進行功能和效能測試。一旦測試結果成功，應用程式流量就會從藍色路由到綠色。綠色則成為新的產品。  如果綠色生效後出現問題，流量可以路由回藍色。 在藍綠部署中，兩個系統都使用相同的持久性層或資料庫後端。保持應用程式資料同步至關重要，但鏡像資料庫可以幫助實現這一目標。 您可以使用藍色的主資料庫進行寫入操作，並使用綠色的輔助資料庫進行讀取操作。從藍色切換到綠色期間，資料庫會從主資料庫故障轉移到輔助資料庫。如果測試時green也需要寫入資料，資料庫可以採用雙向複製。 一旦綠色變為可用，您可以關閉或回收舊的藍色實例。您可以在這些實例上部署較新的版本，並使它們成為下一個版本的新版本。 藍綠部署依賴流量路由。這可以透過更新主機的 DNS CNAMES 來完成。但是，長 TTL 值可能會延遲這些變更。或者，您可以變更負載平衡器設置，以便變更立即生效。 ELB 中的連線耗盡等功能可用於服務動態連線。 ## 金絲雀部署 金絲雀部署就像藍綠部署，但它更規避風險。您可以使用分階段的方法，而不是一步從藍色切換到綠色。 透過金絲雀部署，您可以在生產基礎架構的一小部分中部署新的應用程式程式碼。一旦應用程式被批准發布，只有少數用戶會被路由到它。這可以最大限度地減少任何影響。 如果沒有報告錯誤，新版本可以逐步推廣到基礎設施的其餘部分。下圖示範了金絲雀部署：  金絲雀部署的主要挑戰是設計一種方法將某些使用者路由到新應用程式。此外，某些應用程式可能始終需要同一組使用者進行測試，而其他應用程式可能每次都需要不同的群組。 考慮透過探索多種技術來路由新用戶： * 在允許外部使用者存取之前，將內部使用者暴露給金絲雀部署； * 基於來源IP範圍的路由； * 在特定地理區域發布應用程式； * 使用應用程式邏輯為特定使用者和群組解鎖新功能。當應用程式對其他使用者上線時，此邏輯將被刪除。 ## 部署最佳實踐 現代應用程式團隊可以遵循許多最佳實踐，將部署風險降至最低： * **使用部署清單。** 例如，清單上的一項可能是「僅在應用程式服務停止後備份所有資料庫」以防止資料損壞。 * **採用持續整合 (CI)。** CI 確保簽入程式碼儲存庫功能分支的程式碼僅在*經過一系列相依性檢查、單元和整合測試以及成功建置。如果路徑中出現錯誤，建置將失敗並通知應用程式團隊。因此，使用 CI 意味著應用程式的每項變更都需要在部署之前進行測試。 CI 工具的範例包括：CircleCI、Jenkins。 * **採用持續交付 (CD)。** 透過 CD，CI 建置的程式碼工件被打包並隨時準備在一個或多個環境中部署。請閱讀我們的[低風險持續交付電子書](https://try.rollbar.com/low-risk-continuous-delivery-guide/) 以了解更多資訊。 * **使用標準作業環境 (SOE)** 以確保環境一致性。您可以使用 Vagrant 和 Packer 等工具來開發工作站和伺服器。 * **使用建置自動化工具來自動化環境建置。** 使用這些工具，通常只需單擊一個按鈕即可輕鬆拆除整個基礎架構堆疊並從頭開始重建。 CloudFormation 就是此類工具的一個範例。 * **在目標伺服器中使用 Puppet、Chef 或 Ansible 等組態管理工具**來自動套用作業系統設定、套用修補程式或安裝軟體 * **使用 Slack 等通訊管道**來自動通知不成功的建置和應用程式故障 * **建立一個流程，用於就部署失敗向負責團隊發出警報。** 理想情況下，您將在 CI 環境中捕獲這些情況，但如果部署了更改，您將需要一種方法來通知負責團隊 * **為執行狀況檢查失敗的部署啟用自動回滾**，無論是由於可用性還是錯誤率問題。 ## 部署後監控 即使您採用了所有這些最佳實踐，事情仍然可能失敗。因此，監控部署後立即發生的問題與規劃和執行完美部署同樣重要。 應用程式效能監控 (APM) 工具可以幫助您的團隊監控關鍵效能指標，包括部署後的伺服器回應時間。應用程式或系統架構的變化會極大地影響應用程式的效能。 像 [Rollbar](http://rollbar.com/) 這樣的錯誤監控解決方案同樣重要。它將快速通知您的團隊部署中的新錯誤或重新啟動的錯誤，這些錯誤可能會發現需要立即關注的重要錯誤。 如果沒有錯誤監控工具，這些錯誤可能永遠不會被發現。雖然少數遇到錯誤的用戶會花時間報告它們，但大多數其他用戶不會。隨著時間的推移，負面的客戶體驗可能會導致滿意度問題，或更糟的是，可能會導致業務交易無法進行。 錯誤監控工具還可以在營運/DevOps 團隊和開發人員之間建立所有部署後問題的共享可見性。這種共同的理解使團隊能夠更加協作和回應。 _原文發佈於 [rollbar.com](https://rollbar.com/blog/deployment-strategies/)_ --- 原文出處：https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Kubernetes 已成為管理容器化應用程式的首選平台，提供可擴展性、靈活性和穩健性。然而，Kubernetes 的複雜性可能令人望而生畏，需要開發人員和 DevOps 團隊瀏覽複雜的設定檔和命令列互動。 一些強大的開發工具已經出現，以簡化 Kubernetes 叢集的管理並簡化部署流程。在本文中，我們將探討五種 Kubernetes 開發工具： - [**普羅米修斯**](https://prometheus.io/) - [**獨眼巨人**](https://cyclops-ui.com/) - [**科達**](https://keda.sh/) - [**卡本特**](https://karpenter.sh/) - [**帆船**](https://velero.io/) 這些工具提供直覺的使用者介面、自動擴展功能、災難復原解決方案並提高管理 Kubernetes 叢集的效率。 ### 向我們展示您的支持🙏🏻 在我們開始之前，如果您為我們的儲存庫加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興。我們的 GitHub 儲存庫在這裡：https://github.com/cyclops-ui/cyclops ⭐ ## 1. Prometheus：Kubernetes 監控與警報  **Prometheus** 是一款專為微服務和容器設計的開源監控和警報工具包。它提供靈活的查詢、即時通知以及對容器化工作負載、API 和分散式服務的可見性。 Prometheus 的功能之一是它能夠透過偵測可能升級為攻擊的不規則流量或活動來協助雲端原生安全。 它使用基於拉取的系統，發送稱為“scrapes”的 HTTP 請求，從應用程式和服務收集指標。這些指標儲存在記憶體和本機磁碟中，可以輕鬆檢索和分析。 Prometheus 可以直接從客戶端庫或透過匯出器（位於應用程式附近的軟體）存取資料。匯出器接受來自 Prometheus 的 HTTP 請求，確保資料格式相容性，並將請求的資料提供給 Prometheus 伺服器。 Prometheus 提供了四種主要類型的指標：計數器、儀表、直方圖和摘要。這些指標可以靈活地測量應用程式和服務的各個方面，例如事件啟動計數、記憶體使用情況、資料聚合和分位數範圍。 為了發現監控目標，Prometheus 利用 Kubernetes 叢集中的服務發現。它可以獨立於應用程式資訊存取機器級指標，從而實現全面監控。 資料收集完成後，Prometheus 提供了一種名為 PromQL 的查詢語言，使用戶能夠存取監控資料並將其匯出到 Grafana 等圖形介面，或使用 Alertmanager 發送警報。 ## 2. Cyclops：只需點擊幾下即可部署應用程式  **Cyclops** 是一個簡化 Kubernetes 叢集中執行的應用程式管理的工具。它將複雜的設定檔抽象化為基於表單的 UI，從而無需手動配置和命令列互動。這使得具有不同技術專業知識水平的個人更容易存取部署過程。 有了 Cyclops，您就不再局限於一刀切的方法。您可以自訂模組以滿足您的獨特需求，讓您可以自由建立具有輸入驗證的模板，以便與您的團隊無縫協作。 這不僅加快了您的工作速度，還使每個團隊成員能夠獨立工作，從而促進更順暢、更有效率的工作流程。 在 Cyclops 中，每個模組都列出了它使用的資源的詳細清單——部署、服務、pod 等，所有這些都在簡單的視圖中。您可以輕鬆追蹤它們的狀態，幫助您快速發現並修復應用程式中的任何問題。這就像有一個清晰的路線圖來導航和解決出現的任何問題。 在 Cyclops 的架構中，核心元件是 [Helm](https://helm.sh/) 引擎，它允許動態產生配置。該引擎是有效管理 Cyclops 框架中的設定和參數的關鍵機制。 由於基於 Kubernetes 的系統通常使用 Helm 作為套件管理器，因此無縫整合 Cyclops 是一個簡單的流程。 Cyclops 促進部署實踐的一致性和標準化。透過提供預先定義的範本或設定預設，Cyclops 可確保部署遵循既定的最佳實務和指南。這種一致性不僅提高了部署的可靠性和穩定性，而且還促進了協作。 ## 3. Keda：Kubernetes 工作負載的事件驅動自動縮放  Kubernetes Horizontal Pod Autoscaling (HPA) 和 Vertical Pod Autoscaling (VPA) 廣泛用於根據 CPU 和記憶體使用量自動縮放 Kubernetes 叢集。 然而，它們也有局限性，例如無法將 Pod 擴展到零或基於資源利用率以外的指標進行擴展。這就是 **Keda**（Kubernetes 事件驅動的自動縮放）發揮作用的地方。 Keda 是一個開源容器自動縮放器，它透過根據外部事件或觸發器縮放 Pod 來擴展本機 Kubernetes 自動縮放解決方案的功能。 Keda 監控 AWS SQS、Kafka 和 RabbitMQ 等事件來源，根據預定義規則有效觸發或停止部署。這種適應性強的解決方案還允許自訂指標，促進為訊息驅動的微服務量身定制的有效自動擴展，確保最佳效能和資源利用率。 Keda 的元件包括事件來源、縮放器、指標適配器和控制器。事件來源提供觸發擴展的外部事件，而擴展器則監視這些事件並取得指標。指標適配器轉換控制器的指標，然後相應地擴展部署。 透過利用 Keda，DevOps 團隊可以在沒有事件需要處理時縮小規模，從而釋放資源並降低雲端成本。 Keda 還提供與各種 DevOps 工具鏈的互通性，支援內建和外部縮放器。 借助 Keda，自動擴展變得更加靈活和高效，使團隊能夠優化資源利用率並適應不斷變化的工作負載需求。 ## 4. Karpenter：Kubernetes 的自動化節點配置  Kubernetes 叢集經常面臨在可用節點上調度 Pod 的挑戰。 **Karpenter** 是一個開源叢集自動縮放器，可自動配置新節點以回應不可調度的 Pod。它評估待處理 Pod 的聚合資源需求，並選擇最佳實例類型來滿足它們。 Karpenter 還支援整合功能，主動移動 Pod 並以更便宜的版本取代節點，以降低叢集成本。 一個突出的功能是引入“節點池”，允許用戶根據各種標準對節點進行分類。這種客製化確保了客製化的資源分配方法，卡彭特動態地將節點配置到最合適的池中。 Karpenter 的核心旨在無縫地自動擴展 Kubernetes 叢集。 Karpenter 利用 Kubernetes 中的自訂資源定義 (CRD)，與現有工具和 API 無縫集成，為使用者提供熟悉的體驗。 Karpenter 的靈活性超出了 AWS 的範圍，使其成為適用於雲端和本地環境的多功能解決方案。 Karpenter 的適應性體現在它透過 Kubernetes 資源支援使用者定義的策略和策略。這種靈活性使組織能夠使 Karpenter 與其獨特的應用程式和工作負載需求保持一致，從而實現更好的自動化和最佳化的 Kubernetes 可擴展性。 ## 5. Velero：Kubernetes 的災難復原與備份  **Velero** 是一款功能強大的工具，可為 Kubernetes 叢集提供災難復原和備份解決方案。它使用戶能夠輕鬆備份、還原和遷移應用程式及其持久性磁碟區。 Velero 拍攝叢集資源和資料的快照，並將它們儲存在 AWS S3、Google Cloud Storage 或 Azure Blob Storage 等物件儲存提供者中。 借助 Velero，使用者可以建立備份計劃，確保關鍵叢集資源的定期快照。這樣可以在資料遺失或叢集故障時實現高效的災難復原。 Velero 也支援叢集遷移，簡化了在 Kubernetes 叢集之間行動應用程式和資料的過程。 該工具提供資源過濾功能，允許使用者選擇性地備份和還原特定資源。 這種靈活性可確保備份中僅包含相關資料，從而節省儲存空間並減少備份和還原時間。 Velero 與 CSI（容器儲存介面）集成，提供備份磁碟區並將其恢復到原始狀態的支援。 除了災難復原和備份之外，Velero 還提供在任何命名空間中執行、使用掛鉤擴充功能以及支援自訂外掛程式以增強自訂等功能。它提供了診斷和解決常見問題的故障排除指南，確保管理 Kubernetes 叢集的流暢體驗。 ## 結論 這五種 Kubernetes 開發工具 - Prometheus、Cyclops、Keda、Karpenter 和 Velero - 在簡化 Kubernetes 叢集管理的複雜性方面發揮關鍵作用。 從使用Prometheus 進行監控和警報，到使用Keda 進行事件驅動的自動縮放，再到透過Karpenter 進行自動化節點配置，每個工具都可以解決特定的挑戰，從而有助於打造更有效率、更有彈性的Kubernetes環境。 Cyclops 因其用戶友好的方法而脫穎而出，將複雜的配置抽象化為直覺的 UI，而 Velero 則提供重要的災難復原和備份解決方案來保護關鍵資料和應用程式。 由於 Kubernetes 仍然是現代應用程式部署的基石，這些工具使開發人員和 DevOps 團隊能夠更輕鬆地駕馭複雜的容器化環境。 透過將這些工具整合到 Kubernetes 工作流程中，您可以增強可擴展性、簡化部署流程，並確保應用程式在當今動態且要求嚴苛的運算環境中的穩健性。 --- 原文出處：https://dev.to/cyclops-ui/five-tools-to-add-to-your-k8s-cluster-2j89
毫無疑問，掌握 Web 開發最有效的方法之一就是透過實作。雖然學習理論概念很重要，但將您的知識應用到現實世界的專案中才能真正鞏固您的技能。無論您是想要打下堅實基礎的初學者，還是尋求新挑戰的經驗豐富的開發人員，這裡有 25 個 Web 開發專案可以提高您的能力。 ### 學生成績管理系統 學生成績管理系統旨在為學生和大學提供一種快速且用戶友好的方式來存取和管理考試成績。學生可以登入查看他們的成績，新生可以選擇註冊。該系統旨在以易於理解的方式呈現結果。 **如何做：** 掌握前端、後端和資料庫程式設計的基礎知識後，從建立全端應用程式開始。利用HTML、CSS、JavaScript、PHP和MySQL實現使用者認證、結果顯示和註冊功能。  ### 線上程式碼編輯器（React） 該專案涉及使用 React 建立線上程式碼編輯器，允許使用者用各種程式語言編寫和執行程式碼。目標是建立一個用戶可以無縫編輯和測試原始程式碼的平台。 **如何做：** 先使用 HTML、CSS 和 React 進行前端工作。實現程式碼輸入、執行和結果顯示功能。專注於建立用戶友好的介面，以獲得流暢的程式碼編輯體驗。  ### 使用 React 進行 Amazon 克隆 Amazon Clone 專案圍繞著使用 React 建立 Amazon 線上商店的工作副本。該專案將幫助您了解有效的電子商務網站所需的元件並將它們應用到您的應用程式中。 **如何做：** 從 HTML、CSS 和 JavaScript 開始。使用 React 建立電子商務網站的不同部分，例如產品清單、購物車和結帳流程。整合動態資料並增強使用者介面。  ### 客戶關係經理 客戶關係管理器專案涉及建立一個後端 Web 應用程式，該應用程式允許建立、讀取、更新和刪除 (CRUD) 客戶資料。這是了解後端 Web 開發的基礎專案。 **如何做：** 利用 Node.js、Express.js 和 MongoDB 等技術來建立後端基礎架構。實施 CRUD 操作來管理客戶資料。開發一個用戶友好的介面，用於與客戶資料庫互動。  ### 排序展示台 排序可視化器專案旨在提供各種排序演算法的可視化表示。使用者可以觀察不同的演算法如何執行，並更深入地了解 JavaScript 的基本概念。 **具體操作方法：** 使用 HTML、CSS、Bootstrap 和 JavaScript 建立 Web 應用程式。實現冒泡排序、合併排序和快速排序等排序演算法的視覺化。允許用戶與視覺化進行交互，以增強他們的學習體驗。  ### 多人遊戲 – Connect4 多人遊戲 – Connect4 專案專注於建立具有多人遊戲功能的著名 Connect4 遊戲。它提供了學習一些重要的網路和遊戲設計基礎知識的機會。 **如何做：** 如果您想知道多人遊戲是如何開發的，或者您曾經想為週末製作一款遊戲，那麼這個專案適合您。使用 PyGame、Sockets 和遊戲編程為您和您的朋友建立多人 Connect4 遊戲。  ### YouTube 腳本摘要器 投入時間觀看可能比預期更長的電影變得相當具有挑戰性。有時，如果我們不能從他們那裡收集有用的訊息，我們的努力可能會徒勞無功。透過自動總結影片的文字記錄，我們可以輕鬆地發現這些影片中的關鍵主題，這節省了我們再次觀看整個影片的時間和精力。 **如何做到這一點：** 人們每天都會觀看 YouTube 影片，這些影片可以是指導性的、紀錄片的或任何其他持續時間較長的類型；考慮透過提供摘要資訊可以節省多少時間。該專案將是一個 chrome 擴展，它將向後端的 Rest API 發送請求，該 API 將向您發送 YouTube 腳本的摘要。  ### OurApp – NodeJS 中的社交媒體 Web 應用程式 現實應用程式 OurApp 的用戶可以進行交流、相互關注以及發布簡短的推文。掌握 HTML、CSS 和 JS 後，專案最適合想要使用 Nodejs 和 MongoDB 深入研究完整堆疊的人。 **怎麼做：** 你想成為能夠超越 HTML、CSS 和 JS 的全端開發人員嗎？建立這個完整的堆疊應用程式，以了解如何使用 NodeJS、MongoDB 和其他技術來建立現代、快速且可擴展的伺服器端 Web 應用程式。如果您想在磨練 NodeJS 技能的同時開發一些有趣的東西，那麼這個專案就是適合您的。您還可以免費註冊全端 Web 開發課程，這將幫助您成為您所在領域的傑出開發人員。  ### Codechef 通知 CodeChef 經常遇到伺服器過載問題，導致評審難以快速提供提交結果。留給編碼人員的唯一選擇是在一段時間後不斷檢查站點，看看結果是否存在。透過這個專案，我們希望消除審查提交頁面以確定提交結果的額外步驟。我們將自動執行檢索結果的過程並在準備好後立即通知使用者。 **如何操作：** Codechef 是一個流行的編碼實踐平台，但伺服器過載可能會導致結果延遲。此附加元件旨在透過自動化獲取結果並及時通知用戶的流程來節省時間。使用網路抓取或 API 來收集結果資訊並實作通知系統。  ### 使用 Dash 來視覺化和預測股票 該專案涉及使用 Dash（一種用於建立分析 Web 應用程式的 Python 框架）來視覺化和預測股票資料。它提供了將資料視覺化和機器學習概念應用於金融資料的機會。 **如何操作：** 如果您對股票市場感興趣，該專案將簡化股票資料的可視化。利用Python、Dash和相關函式庫進行資料視覺化。實施基於歷史資料預測股票趨勢的功能。  ### 線上程式碼編輯器 (JQuery) 線上程式碼編輯器可透過瀏覽器存取，並位於遠端伺服器上。儘管一些線上程式碼編輯器更像是完整的 IDE，但其他編輯器更像是具有語法突出顯示或程式碼完成等基本功能的文字編輯器。 **如何操作：** 使用 HTML、CSS、JavaScript 和 JQuery 建立線上程式碼編輯器。專注於透過語法突出顯示和程式碼完成等功能來增強使用者體驗。確保程式碼輸入和執行順利。  ### 模糊URL FuzzyURLs 涉及使用 Django（Python 的高級 Web 框架）建立 URL 縮短服務。它提供了建立 Web 應用程式的實務經驗，特別關注 URL 操作。 **如何做：** 從頭開始開發一個基於 Django 的 URL 縮短器。了解 URL 縮短服務的工作流程並實現建立、管理和重新導向短 URL 的功能。  ### 使用 React 進行 Slack 克隆 該專案旨在使用 React 建立 Slack 克隆，提供即時訊息和協作的平台。這是一個中高階專案，強調React-Redux和Firebase。 **如何做：** 應用 React-Redux 原理來建立一個類似 Slack 的 Web 訊息服務。利用 Firebase 實現即時資料庫功能。專注於建立響應靈敏且功能豐富的訊息傳遞應用程式。  ### Web 應用程式的 Node.js 驗證 了解使用 Node.js 為 Web 應用程式建立驗證系統。探索各種身份驗證技術，評估其優點和缺點，並實施改進。 **如何做：** 對於那些想要深入研究 Node.js 並了解建立安全身份驗證系統的複雜性的人來說，這個專案非常適合。實施使用者身份驗證、會話管理並探索增強安全性的方法。  ### TinyMCE 同義詞插件 為 TinyMCE 富文本編輯器建立一個插件，用於搜尋單字的同義詞並允許使用者將它們插入編輯器中。 **如何做到這一點：** 為 TinyMCE 開發一個自訂插件，整合一項功能，使用戶能夠搜尋同義詞並輕鬆地將它們插入到富文本編輯器中。了解 TinyMCE API 以實現無縫整合。  ### 迷宮裡的老鼠 建立一個基本的 React Web 應用程式，顯示老鼠從帶有預設障礙的方形迷宮的左上角到右下角可以採取的所有可能路徑。 **具體操作方法：** 建立一個簡單的 React Web 應用程式來直觀地呈現經典的 Rat in the Maze 謎題。實施功能來展示老鼠穿過迷宮的所有潛在路徑。  ### 簡歷產生器 Web 應用程式 使用 ReactJS 和 NodeJS 建立一個用於建立履歷的 Web 應用程式。該專案將指導您完成建立簡歷產生器的步驟，並提供一種實用的方法來支援個人製作簡歷。 **如何做：** 深入研究 ReactJS 和 NodeJS 來開發一個用戶友好的簡歷產生器。實施加入個人詳細資訊、教育背景、工作經驗和技能的功能。專注於建立動態且可自訂的履歷模板。  ### Markdown 編輯器 建立一個 Markdown 編輯器，讓使用者編寫 Markdown 並預覽渲染的 HTML。 Markdown 是一種基於網路的文字格式化系統，廣泛用於部落格文章、文件等。 **如何做：** 使用 HTML、CSS 和 JavaScript 開發 Markdown 編輯器。使用戶能夠編寫 Markdown 程式碼並查看渲染的 HTML 的即時預覽。使用粗體文字、圖像和清單等功能增強編輯器。  ### 450 DSA 追蹤器 450 DSA Tracker 旨在協助使用者追蹤解決 450 道資料結構和演算法問題的進度。它利用 TypeScript、React.js 的 reducer 和 context API 以及即時瀏覽器 IndexedDB 來快取資訊。 **具體操作方法：** 使用 TypeScript 和 React.js 實作 Web 應用程式，以追蹤解決資料結構和演算法問題的進度。利用reducer 和context API 進行狀態管理，並利用IndexedDB 進行即時瀏覽器快取。  ### 待辦事項網頁應用程式 使用 Node.js 框架 Adonis.js 建立待辦事項 Web 應用程式。了解 HTTP、REST API 和 CRUD 操作，同時建立用於管理待辦事項清單的後端 API。 **如何操作：** 使用 Adonis.js 為待辦事項 Web 應用程式建立 CRUD API。使用 Postman 測試 API 並建立用於新增、更新和刪除任務的後端功能。獲得使用後端框架的經驗。  ### 兩個真相和一個謊言遊戲 Slack 機器人 開發一個 Slack 機器人，用於在 Slack 工作區中玩「兩個真相和一個謊言」遊戲。該專案利用 JavaScript 和 Node.js 為工作區成員建立一個有趣的互動式遊戲。 **如何做：** 建立一個 Slack 機器人，以促進「兩個真相和一個謊言」遊戲。使用 JavaScript 和 Node.js 處理 Slack 工作區中的互動。實現用戶共享陳述並猜測哪一個是錯誤的功能。  ### 使用 Chromakey（綠幕）效果進行即時視訊處理 探索視訊處理中使用的色度（綠幕）效果。使用 HTML、CSS 和 JavaScript 建立 Web 應用程式，以背景影片或圖像取代綠幕。 **具體操作方法：** 開發一個處理即時視訊並應用色鍵效果的 Web 應用程式。使用 HTML、CSS 和 JavaScript 操作影片幀並用背景影片或圖像替換綠幕。  ### WhatsApp 網頁克隆 使用 React 和 Firebase 開發具有即時訊息功能的 WhatsApp Web 克隆。 **如何操作：** 使用 React 建立使用者介面並使用 Firebase 實現即時資料庫功能，打造流暢的訊息體驗。  ### WhatsApp 上的電子郵件提醒 設定新電子郵件的 WhatsApp 提醒以簡化電子郵件管理和通知。 **如何操作：** 使用自動化平台 Twilio 建立一個工具，從收件匣中獲取詳細資訊並在 WhatsApp 上發送警報。  ### 天氣預報應用程式 使用 Streamlit 函式庫和 OpenWeatherMap API 為天氣預報應用程式建立響應式前端。 **如何操作：** 利用 Python 和 Streamlit 可視化天氣資料並與 OpenWeatherMap API 互動以獲取即時天氣資訊。  ### 總結 這個 Web 開發專案的彙編提供了各種各樣的挑戰，使您能夠提高跨不同技術和概念的技能。無論您對全端開發、資料視覺化、遊戲設計還是自動化感興趣，這些專案都可以提供有價值的幫助 --- 原文出處：https://dev.to/mukeshkuiry/25-web-development-projects-you-must-work-on-2024-4onl
*乾淨的架構*在許多方面都未能滿足我的期望。儘管 Martin 先生對這個主題表現出明顯的熱情，但「清潔架構」組織得很差，缺乏範例，並且對使用現有系統保持沉默。作者錯過了一個重要的機會來教導我們何時以及如何將這些經驗教訓應用到我們自己的系統中。讓我解釋。 ### *乾淨的架構*是一本組織得很差的書 這本書需要很長時間才能開始。關於設計範式（結構化、物件導向和函數式）的章節似乎特別不合時宜且不必要。 關於 SOLID 原則的章節很好。我很高興看到這些原則被分解並得到很好的解釋。我發現思考它們對系統架構的適用性很有趣。但鮑伯叔叔提出了諸如硬性規則之類的堅實原則，這讓我感到不舒服。事實上，我非常確定一個***從未***違反 SOLID 原則的系統將是一個巨大的混亂。 然而，第 137 頁的這一段很重要： >架構的主要目的是支援系統的生命週期。良好的架構使得系統易於理解、易於開發、易於維護、易於部署。最終目標是最小化系統的生命週期成本並最大化程式設計師的生產力。 這是一個很好的觀察。叔叔鮑伯為什麼不把它放在第一章呢？ ### 例子不夠多 本書中幾乎沒有任何例子。第 33 章包含一個討論影片銷售電子商務應用程式的範例。沒關係。但我並沒有明確地知道如何將這些概念應用到我自己的系統中。 附錄講述了 Bob 叔叔如何提出 SOLID 原則和乾淨架構規則的故事。它載有過去專案的範例。我認為這是本書**最有趣的部分**。 ### 這本書沒有提到改進現有系統的架構 大多數開發人員將大部分時間花在現有系統上。因此，我期望 *[Clean Architecture](https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164/)* 充滿有關改進現有系統的建議。但這本書在這個問題上顯然隻字不提。 ### 如何建立一個乾淨的架構？ 在本書的前半部分中，您將了解如何透過遵循 SOLID 原則將系統沿系統邊界分解為元件來建立一個乾淨的架構（我是這樣解釋的）。如果你停止閱讀那裡，你可能會有這樣的印象：叔叔鮑伯不會批准你為建築所做的一切，這是可以理解的。如果你認為他提出的幾個選項是「正確」的做事方式，這也是情有可原的。然而，在本書的最後，您將在第 228 頁讀到： >這個例子旨在顯示架構邊界無所不在。作為建築師，我們必須小心地辨識何時需要它們。我們也必須意識到，如果完全實施這些邊界，其成本是昂貴的。 >同時，我們必須認識到，當這些邊界被忽略時，即使存在全面的測試套件和重構規則，以後加入它們的成本也會非常昂貴。 >那我們建築師該怎麼辦？答案令人不滿意。一方面，多年來，一些非常聰明的人告訴我們，我們不應該預見抽象的需要。這就是 YAGNI 的哲學：“你不會需要它。”這句話充滿智慧，因為過度設計往往比設計不足更糟。另一方面，當您發現確實需要一個不存在的架構邊界時，加入這樣一個邊界的成本和風險可能會非常高。 >所以你已經得到它了。軟體架構師啊，你必須看見未來。你必須聰明地猜測。您必須權衡成本並確定架構邊界在哪裡，哪些應該完全實現，哪些應該部分實現，哪些應該被忽略。 因此，在本書的一半以上，他說應該由我們來決定我們的系統的邊界在哪裡。這種界限可能無所不在。令人困惑，對吧？ ### 這本書缺少什麼 因此，如果軟體架構的最終目標是最小化系統的生命週期成本，那麼一本關於架構的書不應該幫助架構師做出這些決策嗎？ #### 未解答的問題 這本書給我留下了很多未解答的問題。各種選擇的經濟學討論在哪裡？如何找到最適合我的系統的架構？研究在哪裡？  我該如何決定水平分層、垂直切片或其他方式是否可以最大限度地降低系統的生命週期成本？或者，如果我沒有明確定義的層，我該如何決定哪種分層策略（如果有）可以最大限度地降低我的生命週期成本？ 我還有更多問題。如果您改進現有系統架構的時間有限，您應該把精力放在哪裡？將資料庫與業務邏輯分開總是一個好主意嗎？您應該始終遵循哪些建議？哪些建議取決於系統？ #### 讓*乾淨的架構*更有價值的細節 在*[Code Complete](https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/)*中，Steve McConnell 討論了不同非功能性需求（例如可靠性、可靠性）之間的權衡、正確性、可維護性、可讀性等。他解釋了一些需求如何協調一致而另一些需求如何衝突。我很樂意看到類似的東西用於本書中討論的架構決策。 在*清潔架構*中，專案規模、團隊規模、專案失敗的後果、預期程式碼生命週期和其他重要因素作為架構的驅動因素沒有得到足夠的重視。例如，Healthcare.gov 需要比您正在開發的個人待辦事項清單更多的架構，即使它們都是由資料庫支援的 Web 應用程式。 ### 這本書的真正內容是什麼 本書的大部分內容我都感到有些困惑。我有點明白叔叔鮑伯想說什麼。但直到讀了附錄才完全明白。那麼，讓我為您節省一些時間。 #### 一個例子 想像一下您正在為消費市場建立一台桌上型電腦（例如辦公室電腦）。您可以選擇硬件，然後為整個系統編寫軟體（韌體、作業系統、驅動程式、應用程式等）。 #### 你會寫一個整體嗎？ 你會怎樣做呢？您會編寫一個巨大的程式（一個整體），其中電子表格的程式碼知道您為電腦選擇的磁碟類型嗎？您能否想像更新電子表格程式碼並在各處新增「if」語句，以便在您有 SATA 磁碟機時執行一件事，而在有 SCSI 磁碟機時執行另一件事？然後對 VGA、DVI 和 HDMI 視訊做同樣的事情？ PS/2 與 USB 滑鼠輸入的不同路徑怎麼樣？然後對文字處理器和您打算與電腦捆綁的所有其他應用程式重複該過程？ 維護這將是一場惡夢，對嗎？那麼解決方法是什麼呢？建築學！您的電子表格不應該知道您使用的是哪種滑鼠。也不知道你有什麼樣的顯示器。它應該完全忘記這些細節。 #### 計算機中的邊界 如果您查看計算機，您會發現這一點。您的滑鼠中有嵌入式軟體，可以與作業系統進行通訊。然而，詳細資訊對您的應用程式是隱藏的。您的電子表格接受標準化輸入，而無需知道或關心您使用的滑鼠類型。然後，當有人發明了新的輸入裝置（例如觸控板）時，它會自動與您的電子表格配合使用。 這只是計算機的邊界之一。您可能會想出數百個。您可以指派不同的團隊來處理系統的不同部分。您可以為不同元件互動的各種方式建立或採用不同的規格。 此時你可能會說「呃」。顯然，您不希望每次硬體發生變化時都更改並重新編譯電子表格。維護將是一場惡夢。並且我同意。 #### 邊界是你的朋友（如果你正確使用它們） 很容易看出硬體邊界。但使硬體邊界變得有價值的相同邏輯也適用於軟體邊界。軟體邊界更難看到。 因此，您可以從在螢幕上顯示電子表格的能力開始。但您可能還想將其儲存到磁碟、儲存為 PDF、儲存為 CSV 或列印。因此，電子表格程式的邊界之一可能是擁有代表每個電子表格的內部資料結構。然後將該結構傳遞給不同的程式碼，以所需的格式顯示、儲存或列印它。 如果您讓資料結構完全不知道它是如何顯示、保存或列印的，那麼您可以在以後加入「儲存到 XML」功能，而無需深入研究與電子表格資料結構相關的所有程式碼。如果電子表格資料結構有幾百萬行程式碼，您可以想像這會容易得多。 這就是鮑伯叔叔在本書中試圖告訴我們的全部。 **您可以使用 SOLID 原則在系統中建立邊界，隱藏實作細節、降低複雜度並幫助您降低系統的總生命週期成本**。 ### 一本更好的軟體架構書 在許多方面，Martin Fowler 的*[企業應用程式架構模式](https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/)* 遠遠優於*清潔架構* 。 Fowler 描述了他在企業應用程式中反覆觀察到的模式。他給出了每個模式的簡單範例，描述了它的工作原理以及在何處使用它。我發現“企業應用程式架構模式”非常可讀並且適用於我的系統。 ### 要點 *乾淨的架構*中有有價值的訊息，但你必須努力找到它。 我發現有關嵌入式軟體的章節是最容易理解的章節之一。直觀上，避免在整個程式碼庫中分散低階呼叫是有意義的。在沒有硬體的情況下使邏輯可測試也是有意義的（特別是因為嵌入式軟體通常是在硬體可用之前開發的）。如果您只能閱讀本書的兩章，我建議您閱讀這一章和附錄，無論您以編寫哪種軟體為生。 總的來說，《乾淨的架構》是一本很難讀的書，鮑伯叔叔留給我的問題比答案還多。我絕對不會推薦這本書作為您關於軟體架構的第一本書（請查看*[企業應用程式架構模式](https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ )* 由馬丁·福勒取代）。 *同意還是不同意。我很想聽聽你的想法。* *喜歡這篇文章嗎？請在下面“喜歡”它。* --- 原文出處：https://dev.to/bosepchuk/why-i-cant-recommend-clean-architecture-by-robert-c-martin-ofd
## 第 1 部分：將 MongoDB 與 Flask 結合使用 你好！在本系列的最後一個[部分](https://dev.to/paurakhsharma/flask-rest-api-part-0-setup-basic-crud-api-4650)中，我們學習瞭如何建立基本的“ CRUD” ` 使用 python `list` 的 REST API 功能。但這不是現實世界應用程式的建構方式，因為如果您的伺服器重新啟動或上帝禁止崩潰，那麼您將丟失伺服器中儲存的所有資訊。為了解決這些問題（以及許多其他問題），使用了資料庫。所以，這就是我們要做的。我們將使用 [MongoDB](https://docs.mongodb.com/manual/) 作為我們的資料庫。 如果您剛從這部分開始，您可以在[此處]找到我們迄今為止編寫的所有程式碼（https://github.com/paurakhsharma/flask-rest-api-blog-series/tree/master/Part% 20 -%200）。 在開始之前，請確保您已在系統中安裝了 MongoDB。如果您還沒有安裝，可以安裝 [Linux](https://docs.mongodb.com/manual/administration/install-on-linux/)、[Windown](https://docs.mongodb.com/手冊/教學/install-mongodb-on-windows/）和[macOS]（https://docs.mongodb.com/manual/tutorial/install-mongodb-on-os-x/）。 主要有一些流行的函式庫可以讓 MongoDB 的使用變得更容易： 1) [Pymongo](https://api.mongodb.com/python/current/) 是 MongoDB 的低階 Python 包裝器，使用 `Pymongo` 類似於直接編寫 MongoDB 查詢。 以下是使用“Pymongo”更新“id”與給定“id”相符的電影名稱的簡單範例。 ``` db['movies'].update({'_id': id}, {'$set': {'name': 'My new title'}}) ``` `Pymongo` 不使用任何預先定義的模式，因此它可以充分利用 MongoDB 的無模式特性。 2) [MongoEngine](http://docs.mongoengine.org/) 是物件文件映射器，它使用文件模式，使 MongoDB 的使用變得清晰、更容易。 這是使用“mongoengine”的相同範例。 ``` Movies.objects(id=id).update(name='My new title') ``` 「Mongoengine」對資料庫中的欄位使用預先定義架構，這限制了它使用 MongoDB 的無架構性質。 正如我們所看到的，雙方都有各自的優點和缺點。因此，請選擇最適合您的專案的一種。在本系列中，我們將學習“Mongoengine”，如果您希望我也介紹“Pymongo”，請在下面的評論部分告訴我。 為了在我們的`Flask` 應用程式中更好地使用`Mongoengine`，有一個很棒的`Flask` 擴展，名為[Flask-Mongengine](http://docs.mongoengine.org/projects/flask- mongoengine/en/latest/)。 那麼，讓我們開始安裝「flask-mongoengine」。 ``` pipenv install flask-mongoengine ``` *注意：由於`flask-mongoengine` 是在`mongoengine` 之上建造的，所以在安裝Flask-mongoengine 時會自動安裝，而且`mongoengine` 是在`pymongo` 之上建造的，所以它也會被安裝* 現在，讓我們在「movie-bag」中建立一個新資料夾。我將其稱為“資料庫”。在「database」資料夾中建立一個名為「db.py」的檔案。另外，建立另一個檔案並將其命名為“models.py” 讓我們看看文件/資料夾現在是什麼樣子。 ``` movie-bag │ app.py | Pipfile | Pipfile.lock └───database │ db.py └───models.py ``` 現在，讓我們深入探討有趣的部分。 首先，讓我們透過將以下程式碼新增至「db.py」來初始化我們的資料庫 ``` #~movie-bag/database/db.py from flask_mongoengine import MongoEngine db = MongoEngine() def initialize_db(app): db.init_app(app) ``` 在這裡，我們導入了“MongoEngine”並建立了“db”物件，並定義了一個函數“initialize_db()”，我們將從“app.py”中呼叫該函數來初始化資料庫。 讓我們在“models”目錄中的“movie.py”中編寫以下程式碼 ``` #~movie-bag/database/models.py from .db import db class Movie(db.Document): name = db.StringField(required=True, unique=True) casts = db.ListField(db.StringField(), required=True) genres = db.ListField(db.StringField(), required=True) ``` 我們剛剛建立的是資料庫的文件。因此，使用者無法新增此處定義的其他欄位。 這裡我們可以看到「Movie」文件有三個欄位： 1）`name`：是一個`String`類型的字段，我們在這個字段上也有兩個約束。 - “必需”，這意味著用戶在不提供標題的情況下無法建立新電影。 - “唯一”，這意味著電影名稱必須是唯一的，不能重複。 2) `casts`：是一個`list`類型的字段，其中包含`String`類型的值 3) `genres`: 與`casts`相同 最後，我們可以在「app.py」中初始化資料庫，並更改「view」函數（處理 API 請求的函數）以使用我們先前定義的「Movie」文件。 ``` #~movie-bag/app.py -from flask import Flask, jsonify, request +from flask import Flask, request, Response +from database.db import initialize_db +from database.models import Movie app = Flask(__name__) -movies = [ - { - "name": "The Shawshank Redemption", - "casts": ["Tim Robbins", "Morgan Freeman", "Bob Gunton", "William Sadler"], - "genres": ["Drama"] - }, - { - "name": "The Godfather ", - "casts": ["Marlon Brando", "Al Pacino", "James Caan", "Diane Keaton"], - "genres": ["Crime", "Drama"] - } -] +app.config['MONGODB_SETTINGS'] = { + 'host': 'mongodb://localhost/movie-bag' +} + +initialize_db(app) [email protected]('/movies') -def hello(): - return jsonify(movies) [email protected]('/movies') +def get_movies(): + movies = Movie.objects().to_json() + return Response(movies, mimetype="application/json", status=200) [email protected]('/movies', methods=['POST']) -def add_movie(): - movie = request.get_json() - movies.append(movie) - return {'id': len(movies)}, 200 [email protected]('/movies', methods=['POST']) + body = request.get_json() + movie = Movie(**body).save() + id = movie.id + return {'id': str(id)}, 200 [email protected]('/movies/<int:index>', methods=['PUT']) -def update_movie(index): - movie = request.get_json() - movies[index] = movie - return jsonify(movies[index]), 200 [email protected]('/movies/<id>', methods=['PUT']) +def update_movie(id): + body = request.get_json() + Movie.objects.get(id=id).update(**body) + return '', 200 [email protected]('/movies/<int:index>', methods=['DELETE']) -def delete_movie(index): - movies.pop(index) - return 'None', 200 [email protected]('/movies/<id>', methods=['DELETE']) +def delete_movie(id): + Movie.objects.get(id=id).delete() + return '', 200 app.run() ``` 哇！變化很多，讓我們一步一步地進行變化。 ``` -from flask import Flask, jsonify, request +from flask import Flask, request, Response +from database.db import initialize_db +from database.models.movie import Movie ``` 這裡我們刪除了“jsonify”，因為我們不再需要，並加入了“Response”，我們用它來設定回應的類型。然後我們從之前定義的「db.py」導入「initialize_db」來初始化資料庫。最後，我們從“movie.py”導入“Movie”文件 ``` +app.config['MONGODB_SETTINGS'] = { + 'host': 'mongodb://localhost/movie-bag' +} + +db = initialize_db(app) ``` 這裡我們設定 mongodb 資料庫的配置。這裡主機的格式為「<host-url>/<database-name>」。由於我們已經在本地安裝了 mongodb，因此我們可以從“mongodb://localhost/”存取它，並且我們將資料庫命名為“movie-bag”。 最後，我們初始化資料庫。 ``` [email protected]('/movies') +def get_movies(): + movies = Movie.objects().to_json() + return Response(movies, mimetype="application/json", status=200) + ``` 在這裡，我們使用“Movies.objects()”從“Movie”文件中獲取所有物件，並使用“to_json()”將它們轉換為“JSON”。最後，我們傳回一個「Response」物件，其中我們將回應類型定義為「application/json」。 ``` [email protected]('/movies', methods=['POST']) + body = request.get_json() + movie = Movie(**body).save() + id = movie.id + return {'id': str(id)}, 200 ``` 在「POST」請求中，我們首先取得發送的「JSON」和一個請求。然後我們使用“Movie(**body)”請求中的欄位來載入“Movie”文件。這裡的「**」稱為擴充運算符，在 JavaScript 中寫為「...」（如果您熟悉的話）。顧名思義，它的作用是傳播「dict」物件。 <br/> 所以，`Movie(**body)` 變成了 ``` Movie(name="Name of the movie", casts=["a caste"], genres=["a genre"]) ``` 最後，我們保存文件並獲取其“id”，我們將其作為回應返回。 ``` [email protected]('/movies/<id>', methods=['PUT']) +def update_movie(id): + body = request.get_json() + Movie.objects.get(id=id).update(**body) + return '', 200 ``` 這裡我們先找到與請求中發送的「id」相符的Movie文件，然後更新它。這裡我們也應用了擴充運算子將值傳遞給「update()」函數。 ``` [email protected]('/movies/<id>', methods=['DELETE']) +def delete_movie(id): + Movie.objects.get(id=id).delete() + return '', 200 ``` 與此處的“update_movie()”類似，我們獲取與給定“id”匹配的電影文件並將其從資料庫中刪除。 哦，**我剛剛想起來**，我們還沒有將 API 端點加入到“GET”，僅從我們的伺服器獲取一個文件。 讓我們加入它： 在 `app.run()` 上方加入以下程式碼 ``` @app.route('/movies/<id>') def get_movie(id): movies = Movie.objects.get(id=id).to_json() return Response(movies, mimetype="application/json", status=200) ``` 現在您可以從 API 端點「/movies/<valid_id>」取得單一影片。 要執行伺服器，請確保您位於“movie-bag”目錄。 然後執行 ``` pipenv shell python app.py ``` 在終端機中啟動虛擬環境並啟動伺服器。 哇！恭喜您已經走到這一步了。要測試API，請使用我們在[上一篇]((https://dev.to/paurakhsharma/flask-rest-api-part-0-setup-basic-crud-api-4650)) 中使用的“ Postman」本系列的一部分。 您可能已經注意到，如果我們向端點發送無效資料，例如：沒有名稱或其他字段，我們會收到“HTML”形式的不友善錯誤。如果我們嘗試取得資料庫中不存在的「id」影片文件，那麼我們也會收到「HTML」回應形式的不友善錯誤。這並不是一個精心建構的 API 的例外行為。我們將在本系列的後面部分中了解如何處理此類錯誤。 ### 我們從本系列的這一部分學到了什麼？ - `Pymongo` 和 `Mongoengine` 之間的差異。 - 如何使用「Mongoengine」建立文件架構。 - 如何使用「Mongoengine」執行「CRUD」操作。 - Python 擴充運算子。 您可以在[此處]找到這部分的完整程式碼(https://github.com/paurakhsharma/flask-rest-api-blog-series/tree/master/Part%20-%201) 在下一部分中，我們將學習如何使用「Blueprint」來更好地建立 Flask 應用程式。以及如何使用“flask-restful”以最少的設定遵循最佳實踐，更快地建立 REST API 直到那時快樂編碼😊 --- 原文出處：https://dev.to/paurakhsharma/flask-rest-api-part-1-using-mongodb-with-flask-3g7d
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
