CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章  👉 上自學課程  👉 討論區交流
最新出爐作業包
⭐ 邁向資深之路：非同步 JS 訓練（二）—— 各種寫法的錯誤處理、收尾處理
⭐ 邁向資深之路：非同步 JS 訓練（一）—— 從 Callback Hell 到 Promise 介面
⭐ Github Desktop 新手入門教學 —— 用漂亮的 GUI 介面來學習 Git 基本觀念
⭐ 邁向資深之路：後端 JS 訓練（二）—— 玩玩看 Express，用純後端做做看部落格
⭐ 邁向資深之路：後端 JS 訓練（一）—— 玩玩看 Node，做做看老派 CLI 應用程式

🔍 搜尋結果：for

🔍 搜尋結果：for

反應性的推導

當您第一次了解反應式系統時，範例總是看起來像這樣，這是有原因的： ``` let name = state("John"); effect(() => { console.log("Hi" + name); }) ``` > *我們將使用偽程式碼，而不是為了迎合特定庫或框架的語法。* 不需要太多就能理解，當我更新此狀態時，會發生一個呼叫我的副作用的事件。自己實現這種行為也不是太困難。但這還遠遠不是故事的全部。 無論您是想忘記 React、使用 Svelte 探索符文還是想嘗試 Angular；無論您是建立 Solid 應用程式、在 Vue 中建立視圖還是生活在 QwikCity 中，這個主題都相關。它超越了虛擬 DOM 或訊號。在您認為「useEffect」被建立為每個人存在的禍根之前，讓我們先來看看反應性最重要的部分：派生。 ----------------- ## 派生與同步 您可能已經在您選擇的 JS 框架/反應系統中看到了派生值。它可能看起來像“useMemo”，或者可能是“compulated”，或者可能就在分配了值的“$”後面。但所有這些的不變之處是你被告知它們是為了產生一種反應性關係。即使 B 或 C 發生變化，A 也是 B + C 總和： ``` let a = state(1); let b = state(1); const c = memo(() => a + b); effect(() => console.log(c)); ``` 他們可能告訴您派生值應該是純粹的——也就是說它不應該寫入任何其他狀態——但該規則也適用於它的內部。 您可以先將其應用為派生狀態的心理模型： ``` function memo(fn) { let internal = state(); effect(() => internal = fn()); return internal; } ``` 但這永遠無法正常工作。 大多數 UI 框架都關心提供互動性。即取得使用者操作的輸入，將其套用到某種狀態，然後更新 UI。我們看到它形式化為“ui = fn(state)”，但這是一個重複的循環。 就反應性而言，它看起來像： > 更新狀態-> > 執行純計算 -> > 執行副作用（例如更新 DOM） 原因是最終用戶與 UI 互動需要一致性。他們看到的（和看不到的）應該全部同步。您無法與過時的頁面部分進行交互，因為它設定了錯誤的期望。 UI 庫安排其副作用同步執行，以確保最終用戶可以信任體驗。 這意味著程式碼執行有明確的階段。庫需要確保在渲染之前解決所有相關計算。 這導致了以下之間的確切區別： ``` let name = state("John"); const upperName = memo(() => name.toUpperCase()); updateUI(name, upperName); ``` ``` let name = state("John"); let upperName = state(); effect(() => upperName = name.toUpperCase()); updateUI(name, upperName); ``` 第一個例子是推導，其中推導的狀態是它所依賴的狀態的函數。第二個範例是同步，其中狀態的變更會導致其他狀態更新。這是一個重要的區別。 在第二個範例中，根據您的反應模型，可能會發生不同的事情，而不是簡單地按預期立即顯示所有內容。根據效果安排時間與 UI 渲染時間的不同，當您更新「name」時，您可能會短暫看到更新後的「name」和「upperName」的先前值。在像 React 這樣的粗粒度渲染框架中，您的元件可能會執行兩次。因為更新效果中的狀態會再次開始循環。 ---------------- ## 無故障一致性 即使您始終可以在渲染之前進行同步，您仍然有可能使用不同中間狀態（可能是意外狀態）的值多次執行表達式，直到圖形穩定下來。推導可以提供可預測性。 現在，許多反應式系統保證對於任何狀態更新，每個節點最多只執行一次，並且執行時不會出現故障。透過無故障，開發人員向庫提供的程式碼永遠不會觀察到中間或過時狀態。 考慮： ``` let a = state(1); const b = memo(() => a + 1); const c = memo(() => a + 1); const d = memo(() => c + 1); const e = memo(() => b + d); effect(() => console.log(e)); ``` 或作為圖表 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kg9w4yehyeqhgry1wkvk.png) 不同的系統運作方式不同，但在所有情況下，我們期望初始執行產生值為 5 的「e」。 同樣清楚的是，某些狀態依賴其他狀態。當我們更新“a = 2”時，無論機制如何，如果我們只想執行每個節點一次，“c”必須在“d”之前解析，“d”必須在“e”之前解析。 ---------------- ## 推與拉 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1004yrongpx1usdsxe0x.jpg) 那我們要如何處理這個問題呢？它通常從以下兩個想法之一開始。調度（拉）和事件（推）。讓我們使用上一節中的範例來分別了解。 ### 拉動（調度） 這個想法是從副作用（目標）開始，然後詢問遇到的值。 React 通常被認為具有基於「拉」的反應性。在此系統中，當狀態更新時，它會安排檢查以查看是否需要執行任何工作。 但它檢查什麼？天真地，也許一切都改變了，因為它不知道發生了什麼變化。然而，許多 UI 庫都處理元件。如果狀態由元件擁有，那麼這可以作為起點。當元件狀態更新時，安排此元件運作。 基於拉動的系統是粗粒度的。也就是說，他們依賴自上而下地重播所有內容，因為他們不知道發生了什麼變化。如果我們想像一個更細粒度的「拉動」系統，它就無法知道任何變化，直到它追溯到變化的源頭，而變化的源頭可能存在於其依賴項中，也可能不存在。當最終需要向下執行時，額外的遍歷只是額外的工作。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kg9w4yehyeqhgry1wkvk.png) 在我們的範例中，圖片中我們首先執行要求“e”的效果。如果不在之前執行“b”或“d”，我們不知道“e”是否已更改。明確依賴項（如 React 的依賴項陣列）可以在不執行節點的情況下給出向上的路徑。所以我們可以回溯`e`、`b`、`a`，然後執行`b`，然後回溯`d`、`c`、`a`，然後執行`c`、`d`、 ` e` 在最終執行我們的效果之前。但考慮到我們無論如何都在執行整個範圍（元件），即使其中一部分沒有改變，這都是不必要的。 記憶（通常以推導的形式）允許提前退出，有助於優化這種情況，但這種方法雖然一致，但從根本上來說效率很低。 ### 推送（事件） 這個想法是更新從已更改的來源狀態向外傳播。 RxJS 是基於「推送」的反應性的常見範例。它將讓每個節點訂閱其依賴項中的更改事件，然後在收到通知時執行並在其值發生更改時通知其觀察者。 考慮深度優先傳播，因為它反映了最初建立時執行的方式。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kg9w4yehyeqhgry1wkvk.png) `a` 更新，通知 `b` 和 `c`。然後“b”執行並通知“e”。然後“e”執行並看到“b”的更新值，但隨後它遇到了“d”，它尚未執行並且具有舊值... 廣度優先也有類似的問題，因為「d」和「e」與來源「a」的距離相同，再次導致過時的值。它會嘗試執行“b”、“c”，然後執行“e”、“d”，結果發現“d”在“e”之前沒有被計算。 基於「推送」的系統很難確保我們有效地尋求保證。進行排序插入可以工作。但即使最後沒有任何效果器在監聽，它仍然可以工作。它確切地知道傳播時發生了什麼變化，但不知道該變化會產生什麼影響。 ### 推拉 第三種選擇是結合這兩種技術。訊號是事實上的「推拉」反應系統。訂閱和通知的製作方式類似於“推”，但工作的安排類似於基於“拉”的系統。透過這種方式，只安排會改變的事情，並且保持一致。 在我們更新“a”的範例中，“b”和“c”被通知它們可能會發生更改，進而通知“e”和“d”。最後，監聽「e」的效果被排隊。然後，我們的效果首先執行，在觸及值時拉低值，類似於我們上面描述的假設的細粒度「拉」系統。只不過這次只有可能受影響的效果才會排隊。 它知道發生了什麼變化以及這些變化的影響，確保我們只做所需的工作。 如果您對推拉演算法如何在各種訊號庫中工作的更多細節感興趣，請查看： {% 連結 https://dev.to/modderme123/super-charging-fine-grained-reactive-performance-47ph %} ---------------- ## 可以推導的應該推導 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kxmqpzohmk1az3k92anp.png) 我不是 100% 確定這句話最初來自哪裡，但我第一次聽到這句話來自 MobX 的建立者 Michel Westrate。這些都是我們賴以生存的話語。 不言而喻，我們所期望的函式庫和框架的一致性僅靠狀態和效果是不可能實現的。當效果寫入狀態時，您不再可以遍歷依賴關係圖來了解需要計算的內容。依賴性消失了。這不僅僅是低效。這是很容易出錯的。 這是一個很深奧的話題。就這麼多，我只觸及了表面。 「推」與「拉」還有其他含義，即使在查看屬於同一類別的系統時也有很多細節。下一次，我們將研究惰性派生與急切派生以及處理非同步的潛力。 -------------- 特別感謝 Atila Fassina、Fabio Spampinato 和 Daniel Afonso 的審閱。 --- 原文出處：https://dev.to/this-is-learning/derivations-in-reactivity-4fo1

0個讚   0留言 55瀏覽

📈 RAG 檢索增強生成：5 個適合初學者的開源程式庫 🚀

#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 ![LLMWARE](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dy22hfga9az7uol150ar.png) --- # 2. [MongoDB](https://github.com/mongodb/mongo) MongoDB 是一種廣泛使用的開源 NoSQL 資料庫程式。它屬於以文件為導向的資料庫類別，這意味著它以類似於 JSON 文件的格式儲存和組織資料。 MongoDB 的設計具有靈活性和可擴展性，使其適合各種應用程式和行業。 資料庫（如 MongoDB）是 RAG 中非常重要的一步，因為它們在嵌入之前儲存從文件或知識庫中提取的訊息，包括重要的元資料。 https://github.com/mongodb/mongo ![MongodbVector](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ii6vl3tu41gfo6v3zt5g.png) --- # 3. [Milvus 向量資料庫](https://github.com/milvus-io/milvus) Milvus 是一個開源向量資料庫，旨在為嵌入相似性搜尋和人工智慧應用程式提供支援。 Milvus 讓非結構化資料搜尋更容易存取，無論部署環境如何，都可以提供一致的使用者體驗。 Milvus DB，或類似的向量 DB，是 RAG 中至關重要的一步。它是存儲向量嵌入以進行相似性搜尋的地方。該資料庫允許人們用自然語言提出問題並檢索相關結果。如果沒有良好的嵌入和向量資料庫，LLM 模型將無法接收正確的文字區塊來讀取。 https://github.com/milvus-io/milvus ![Milvus DB](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5t6jyfaidyfvxwd8nb7.png) --- # 4. [擁抱臉](https://github.com/huggingface) 如果你還沒去過 Hugging Face，你真的應該去看看。這是所有開源模型的去處，並且可以單槍匹馬地將世界從人工智慧壟斷中拯救出來。就像 Github 用於開源專案一樣，Hugging Face 用於開源模型。有超過 450,000 個模型，所有模型都免費供任何想要使用它們的人使用。 Hugging Face 的 Transformers 庫是首選庫 提供數千個預訓練模型來執行不同模式（例如文字、視覺和音訊）的任務。 這些模型可應用於： - 文本，用於文本分類、資訊提取、問答、摘要、翻譯和文本生成等任務，支援 100 多種語言。 - 影像，用於影像分類、物件偵測和分割等任務。 - 音頻，用於語音辨識和音頻分類等任務。 Transformer 模型還可以組合執行多種模式的任務，例如表格問答、光學字元辨識、從掃描文件中提取資訊、視訊分類和視覺問答。 https://github.com/huggingface ![擁抱臉](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pn47bs3bd97eu4gulkzb.png) --- #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 ![Llama.cpp](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vev1gzen7oolvnug4vfl.png) --- 這是幫助您開始使用 RAG 的非常基本的概述。如果您想要一個讓所有這些庫無縫協作的一站式整合解決方案，請造訪 LLMWare 的 GitHub 庫，找到 50 多個優秀範例來幫助您入門。 [在不和諧中找到我們](https://discord.gg/fCztJQeV7J) - 我們很樂意聽到您的來信！ --- 原文出處：https://dev.to/llmware/top-5-beginner-friendly-open-source-libraries-for-rag-1mhb

0個讚   0留言 533瀏覽

SQL 查詢優化 23 倍！！！

所以我現在已經進入 Web 開發大約 3 年了，專業也有一年多了，這是我處理一個與資料庫查詢最佳化相關的問題的時候，我不是 SQL 專家，我可以得到這份工作完成。沒有花哨的查詢、觸發器、預存程序等。無論如何，我不得不穀歌搜尋最後一個。 長話短說..我們的 ORM (TypeORM) 把我們搞砸了.. ## 免責聲明： 這並不是要誹謗 TypeORM 或任何 ORM。它們是為其建置目的而設計的特殊工具。我在最後附加了一些參考連結，這些連結是人們面臨類似問題的公開討論。無論如何，讓我們繼續這篇文章。 ## 問題！ 我們的提交表有超過 70 萬筆記錄，表現非常糟糕。從表中取得資料的最長時間超過 6 秒。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5dqlrbtn491upu8lwxs.png) 查詢相當簡單。我們所擁有的只是 4 個連接、幾個 where 子句（大約 4 個）、排序（在created_at time 字段上的 DESC）、限制和跳過。 ## 根本原因分析.. 導致我們的提交表大幅放緩的幾個因素如下：- - **索引** - 對用於連接表的欄位進行不正確的索引或未進行索引。 - **不必要的連接** - 我們的查詢中有一些不必要的連接，可以將其刪除以獲得更多效能。 - **空字串錯誤** - 我們程式碼中的一個錯誤，如果沒有為這些列提供使用者輸入，我們將與作為查詢的 where 條件一部分的所有列的空字串 (“”) 進行比較。 - **ORM** - ORM 正在執行一個超級愚蠢的查詢來獲取資料。 這些是我在檢查程式碼和資料庫模式以及分析正在執行以獲取所需資料的查詢時發現的精確點。 ## 對提到的每個問題進行分析和測試。 ###<u>原因 1：索引</u> 在進行了一些谷歌搜尋並閱讀了人們的類似問題後，我發現我們的問題並不是那麼大。人們正在為數百萬行而苦苦掙扎，而我們的只是其中的一小部分，所以一定是我們做錯了什麼。 早期解決這些問題的社區提出了許多建議。我發現進行適當的索引會有很大幫助。 因此，為了進行測試，我從 beta 資料庫中獲取了提交內容，該資料庫擁有大約超過 **100k 記錄**。 在沒有任何最佳化的情況下，執行整個過程平均需要 **2.3 秒**。 （當然，這個時間不僅包括在資料庫上執行查詢的時間，還包括透過網路傳播資料的時間） ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2mgewrjv4khpzrst86nb.png) 在向列加入索引後，我確實發現它縮短了幾毫秒的時間，但這還不夠。它仍然在 **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

0個讚   0留言 238瀏覽

部署網站之前需要檢查的 14 件事👨‍💻🔥

### 讓我們開始吧！ 🚀 將網站丟入野外網路是一件大事，因此確保首先加強每個細節是關鍵。 我的意思是，您想確保您的網站在手機和平板電腦上看起來很流暢，而不僅僅是桌上型電腦（響應能力）。並且您希望真實的人也能夠找到並使用您的網站（SEO）。 我列出的這份清單列出了 14 項必須做的事情 - 涵蓋可用性、可存取性、SEO 優化、出現問題時的備份計劃、確保事物安全的 SSL 以及使用 CDN 加快加載時間等內容。 所有需要檢查的關鍵框，以便您的網站在發佈到世界各地之前被鎖定和加載。 🌐 ![圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/addvh49t2nim1ne6efn1.png) *** ### 簡介⏱️ - 反應能力📱 - 輔助使用♿ - 可用性👍 - 加載時間短⏱️ - SSL 憑證🔒 - 優化圖片🌅 - 使用後備🔄 - 仔細檢查連結和表格✔️ - 404 頁面與圖示 🚫🤔 - 縮小檔案📦 - 專業領域🌐 - 這個🔍 - 使用 CMS 🖥️ - 額外提示🎁 *** ### 1. 回應能力📱💻 如今，使您的網站響應式是網頁開發的重要組成部分。確保您的網站在筆記型電腦、桌上型電腦、手機和平板電腦上看起來不錯。 使用每種流行的瀏覽器測試您的網站。它需要與所有瀏覽器的最新版本相容。 您永遠無法知道某些使用者將使用什麼裝置和瀏覽器來造訪您的網站。 至少會有人嘗試在裝有過時版本三星瀏覽器的舊 Galaxy S3 上執行它。 📲 *** ### 2. 輔助功能 ♿ 網路可存取性是指設計和開發殘疾人可以使用的網站和技術。 簡而言之，網站應該可供所有人存取，這意味著即使是殘疾人也應該理解、導航並與之互動。 開發網站時應考慮許多因素。 其中一些是：加入鍵盤導航、使用 ARIA 角色、在文字和背景之間使用足夠的顏色對比度、向所有圖像加入替代文字以及為連結使用描述性名稱。 🌐 *** ### 3.可用性👍 可用性衡量特定使用者如何有效地使用網站來實現既定目標。 確保您的網站易於使用。使用者應該能夠快速、輕鬆地找到他需要的東西。 您需要像訪客一樣查看網站上的每個元素。文字應該易於在行動裝置和其他標準設備上閱讀，並且您應該使導航清晰且易於理解。 您網站的兩個版本上的內容應該相同。 🕵️‍♂️ *** ### 4.載入時間短⏱️ 網站頁面載入速度是您應該考慮的最重要的事情之一。 你不應該讓你的用戶等待很長時間；您網站的使用者體驗變得很糟糕。 您的網站應該盡快加載，而且網站速度已成為當今 SEO 的首要任務之一。 🚀 *** ### 5.SSL憑證🔒 SSL 代表安全通訊端層。 SSL 憑證可讓您使用 HTTPS 進行安全資料傳輸，並將確保您的網站經過加密，以便駭客無法攔截您的任何資料。 這不僅會讓您的訪客放心，而且還會提高您網站的搜尋引擎優化 (SEO)，因為 SSL 現在是 Google 搜尋演算法的一部分。 🔐 *** ### 6.優化圖片🌅 無論您的網站如何優化，圖像始終是頁面上加載最慢的元素之一。 因此，優化網站上的圖像至關重要。 最好避免使用 TIFF 或 BMP 影像，而堅持使用 JPEG 和 PNG。 另外，您應該避免空圖像 src 程式碼行。在部署您的網站之前，跨網頁優化您的圖片；否則，將會影響您的頁面載入時間。 📸 *** ### 7. 使用後備。確保使用後備 🔄 「後備」只不過是在瀏覽器無法呈現特定 HTML 標記、CSS 屬性或腳本時向瀏覽器提供的附加選項。 回退最常與 HTML5 標籤和 CSS3 屬性一起使用，這兩個屬性都是新的，並且在某些瀏覽器中可能不完全支援。 🛡️ *** ### 8. 仔細檢查所有連結和表格 ✔️ 在部署網站之前，請務必檢查所有連結、按鈕、表單等。它們是否正常運作？ 經常發生這樣的情況：開發時有效的連結在生產中部署後可能無效。 按鈕和表單也是如此。始終檢查是否有損壞的連結和文件。 🚫🔗 *** ### 9. 404，網站圖示。 🚫🤔 404 頁面很重要，因為訪客可能會輸錯或點擊錯誤的連結，因此您不希望存取者看到難看的錯誤警告。 確保您已在網站上設定自訂 404 頁面以防止這種情況發生。 🚧 *** ### 10.縮小檔案📦 縮小是最小化網頁和腳本檔案中的程式碼和標記的過程。 這是減少網站載入時間和頻寬使用的主要方法之一。 主要目標是刪除冗餘或不必要的資料，例如間距和註釋。 🧹 *** ### 11.專業領域🌐 如果您希望您的網站看起來專業，請購買專業網域。 不要使用「.netlify.app」、「.vercel.app」等網域。 許多初學者買不起專業域名，但專業域名總是看起來比子域名更好。 💼 *** ### 12.這個🔍 SEO 是您應該關心的最重要的主題之一。 SEO 可以提高您網站在搜尋結果中的排名。 而且，獲得高排名的主要目的是吸引更多流量並將流量轉化為客戶。 📈 *** ### 13. 使用 CMS 🖥️ CMS 代表內容管理系統。 如果您使用CMS，您可以輕鬆更改CMS中的任何內容，而無需重複編輯程式碼。 使用 CMS 的另一個好處是，如果您的網站內容是由非技術人員建立和編輯的，他們需要有一個良好的 GUI 介面。 🤖 *** ### 14.額外提示🎁 - 確保您的網站沒有任何重大漏洞。 🛡️ - 將腳本放在底部。將樣式表放在頂部。 📜 - 使用 CDN（內容傳遞網路）。 🌐 - 避免重定向。 🔄 - 使用快取。 🔄 *** ### 總結🌟 準備好將您的網站推向世界了嗎？我感覺到你了。很嚇人但很刺激！當您為發布日做準備時，請牢記這 14 件事，它們將幫助您建立一個由內而外令人驚嘆的網站。 有很多事情需要考慮，但為了創造出令你自豪的東西是值得的。只要不斷改進即可。 你的網站從未真正完成， 將其視為一個有生命、不斷進化的事物！ 🌱 與我聯絡：[Linktree](https://linktr.ee/arjuncodess/) 我希望這篇文章對您有所幫助❤️ 快樂編碼！ 🚀 感謝11671！ 🤗 --- 原文出處：https://dev.to/arjuncodess/14-things-to-check-before-deploying-a-website-49ee

0個讚   0留言 178瀏覽

GitHub README 文件：響應式？ 🤔 動畫？ 🤯 淺色和深色模式？ 😱

是的，你沒聽錯，我的 GitHub 自述文件有淺色和深色模式，甚至是響應式的。在這篇文章中，我將簡要介紹我用來實現這一目標的技巧（以及使它變得困難的事情！） 但首先，讓我們看看我的個人資料在不同的螢幕尺寸和顏色偏好下是什麼樣子（或者親自嘗試一下 [GrahamTheDevRel 在 GitHub 上的個人資料](https://github.com/GrahamTheDevRel)！ ## 深色模式 ![GrahamTheDevRel GitHub 設定檔在桌面上處於深色模式。頂部有 5 個按鈕，就像一個選單，格雷厄姆在一個對話氣泡旁邊豎起大拇指，上面寫著「很好，我看到使用黑暗模式，就像一個真正的開發人員！呵呵！」。以下有 4 個部分討論他所做的專案和工作。![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oo5kj6fueo591w13a4tq.png) ## 移動的 請注意以下部分的不同按鈕設計和佈局。 建立這些按鈕比您想像的要困難得多！ ![GrahamTheDevRel GitHub 個人資料在行動裝置上處於深色模式。頂部有5 個按鈕，就像一個顯示社交圖標的選單，格雷厄姆在對話氣泡下方豎起大拇指，上面寫著「很好，我看到使用黑暗模式，就像一個真正的開發人員！呵呵！」。以下有4 個部分討論他所做的專案和工作，這些專案和工作的佈局與桌面不同，以適應較小的螢幕尺寸。![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3zo2c9hay32tcvmoc3ek.png) ## 燈光模式 我忍不住在英雄部分錶達了不同的訊息，當然我只是在開玩笑！ 🤣💗 ![GrahamTheDevRel GitHub 設定檔在桌面上處於輕型模式。頂部有5 個按鈕，就像黑底白字的選單，格雷厄姆拇指朝下，旁邊有一個對話氣泡，上面寫著「哦不，不是淺色模式，你不知道開發人員只使用深色模式嗎？」。以下有 4 個部分討論他在淺色方案中所做的專案和工作。](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cgipfop82t8499i5fukw.png) ## 喔...我有沒有提到它是動畫的？ 請記住，前 5 個按鈕都是單獨的圖像！花了一點功夫才把它弄好！ ## 使用了一些技巧！ 好吧，所以你來這裡不僅僅是為了看我的個人資料！ （如果你這樣做了，也愛你！🤣💗） 不，你是來學一些技巧的，這樣你就可以自己做對吧？ 嗯，有一個“技巧”，然後只需一個 HTML 功能，您就可以自己完成此操作。 讓我們從最有趣的開始： ## 製作響應式按鈕和圖像的技巧！ 網站上的按鈕和英雄圖像是有趣的部分。 為了讓它們發揮作用，我們使用了許多人沒有聽說過的 SVG 功能「<foreignObject>」。 ## `<foreignObject>` 和 SVG 獲勝！ 這是使事物響應的最大技巧。 你看，在 markdown 文件中我們能做的事情非常有限（這就是為什麼我們看到人們使用 `<table>` 等進行佈局......ewww）。 但 SVG 有一個獨特的功能，[`<foreignObject>`](https://developer.mozilla.org/en-US/docs/Web/SVG/Element/foreignObject)。 這允許您在 SVG 中包含許多內容，**包括 HTML 和 CSS。** 有了它，我們就有了更多的力量！ 您可以在 CodePen 的演示中看到（單擊按鈕可以更改外部容器的大小，它代表頁面上圖像的可用空間）： ### SVG 中 CSS 的 CodePen 演示 **一定要查看 html 面板**，所有技巧都在那裡！ https://codepen.io/GrahamTheDev/pen/mdomxyy 關鍵部分在這裡： ``` <svg xmlns="http://www.w3.org/2000/svg" fill="none"> <foreignObject width="100%" height="100%"> <div xmlns="http://www.w3.org/1999/xhtml"> <!--we can include <style> elements, html elements etc. here now, with a few restrictions! Note it must be in xHTML style (so <img src="" /> not <img src="" > to be valid --> </div> </foreignObject> </svg> ``` 從那裡我們可以使用內聯 `<style>` 元素和標準 HTML 元素來建立響應式映像。 但您可能會注意到該演示中使用的標記的另一件事。 ## 圖片很吸引人！ 我將圖像（SVG 氣泡和我的圖像）作為 [`data` URL](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs ）。 這是因為所謂的[內容安全策略 (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) 及其在 GitHub 上的實作方式。 現在我不會解釋 CSP，但本質上它們有一條規則：「嘿，除了當前上下文之外，不能從任何地方加載圖像」。 對於普通圖像來說這不是問題，但這是圖像中的圖像，並且該圖像的“上下文”就是其本身。 因此，如果我們嘗試在 SVG 中包含另一個圖像，它將來自不同的位置並破壞我們的 SVG。 幸運的是，「資料」 URI 被視為相同的上下文/來源。 這就是為什麼它們在我們的範例中使用的原因，如果您想自己實現的話，還需要考慮另一件事！ ## 最後一個技巧，「<picture>」元素且沒有空格。 我的意思是，這甚至不是一個技巧！ 我的自述文件中的最後 4 個框是響應式的（並尊重顏色偏好），但它們使用標準媒體查詢來工作。 這裡唯一的考慮是嘗試找到一個有效的斷點，恰好是 GitHub 上的 768px。 然後我建立了 4 組圖像： - 深色模式和桌面 - 黑暗模式和移動設備 - 燈光模式和桌面 - 燈光模式和移動。 ### 大或小圖像 為了獲得正確的圖像，我們在每個來源上對桌面（大）圖像使用“media =”（min-width：769px）`，對於移動（小）圖像使用“media =“max-width：768px）”放入我們的“<picture>”元素。 ### 淺色和深色模式 若要取得淺色或深色模式，我們使用[`prefers-color-scheme`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme)媒體查詢。 ### 結合我們的查詢和來源 然後我們只需設定「<picture>」元素來使用「(**寬度查詢**)和(顏色首選項)」的組合來選擇我們想要的來源： ``` <picture> <source media="(min-width: 769px) and (prefers-color-scheme: light)" srcset="readme/[email protected]"> <source media="(max-width: 768px) and (prefers-color-scheme: light)" srcset="readme/[email protected]"> <source media="(max-width: 768px) and (prefers-color-scheme: dark)" srcset="readme/[email protected]"> <img src="readme/[email protected]" alt="You will find me writing about tech, web dev, accessibility, breaking the internet and more over on DEV! Purple and neon pink design with Graham pointing at the next section" width="50%" title="My writing on DEV"> </picture> ``` 本身並不困難，但建立 4 種圖像變體非常耗時。 ### 沒有空格 我遇到了最後一個問題。 底部實際上由 4 個不同的圖像組成（是的，我必須為其建立 16 個不同的圖像...）。 這樣做的原因是每個部分都是一個可點擊的連結。 並不複雜，但有一個小問題要注意。 如果您想要讓兩個影像直接並排接觸（因此兩個影像的寬度均為 50%），則必須刪除錨點、圖片元素甚至這些圖片元素內的來源之間的所有空白。 否則 GitHub 會為你的元素加入一些邊距，並且它們將不會在同一行。 另外，儘管我刪除了所有空白，但我遇到了另一個限制，但第一行和第二行之間仍然有 8px 的間隙，您無法遺憾地刪除它（因此之間的線！）。 ## 包起來！ 我可能會在未來對內容安全策略、「<picture>」元素技巧，當然還有「<foreignObject>」做一些更深入的解釋。 這更多的是對概念的介紹，以便您可以自己使用它們，而不是教程。 但現在你已經了解我使用的技巧，我希望看到你建立一個比我的更漂亮的 GitHub 自述文件了！ 如果您這樣做，請在評論中分享！ 💪🏼🙏🏼💗 大家編碼愉快！ 💗 --- 原文出處：https://dev.to/grahamthedev/take-your-github-readme-to-the-next-level-responsive-and-light-and-dark-modes--3kpc

0個讚   0留言 176瀏覽

🐍 Python Playground：16 種入門方法📚

## 簡介 本文是一份指南，旨在透過易於使用且引人入勝的資源來幫助 Python 程式設計新手。從適合初學者的庫到互動式編碼平台，您應該找到最適合您的！ ![介紹 GIF](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t9my6x9r0e94l27b92o5.gif) --- # 圖書館 以下 Python 函式庫易於使用，非常適合 Python 入門。 ![Python 函式庫](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h692caetdehj9360jceg.png) ## 1- [Taipy](https://github.com/Avaiga/taipy) Taipy 是 Python 領域的一個新程式庫，非常適合用最少的程式碼建立強大的 Web 應用程式。使用 Taipy 開始使用 Web 應用程式。 🔑特點： - 豐富的互動性 - 為您的佈局、樣式等提供更多自訂功能（無需 CSS） - 多頁和多用戶應用程式 --- ![QueenB GIF](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0un08vhstrk6zpst5yti.gif) 您的支持意義重大🌱，並且在許多方面為我們帶來了很大的幫助，例如寫文章！ 🙏 --- ## 2- [海龜圖形](https://docs.python.org/3/library/turtle.html) 絕對初學者的起點。這個預先安裝的 Python 程式庫以有趣且直覺的方式教您 Python 程式設計的基礎知識。 --- ## 3- [EasyGUI](https://easygui.sourceforge.net/) 開始使用此庫的圖形使用者介面 (GUI)。 它的簡單性使其成為初學者建立基本 GUI 的首選。 --- ## 4- [Matplotlib](https://github.com/matplotlib/matplotlib) 這個小部件庫成為 Python 領域的首選是有充分理由的。憑藉廣泛的圖表類型，您可以繪製任何 2D 圖表。 該庫允許透過細粒度的圖形元素進行顯著的客製化。 --- ## 5- [Pandas](https://github.com/pandas-dev/pandas) 即使所有 Pythonista 都使用 Pandas，這個函式庫也很容易理解，並且允許您做很多事情。 您可以了解資料框和系列以及如何有效地處理資料。 🔑特點： - 從各種來源載入資料 - 重塑資料框 - 透過基本統計進行基本資料分析 --- ## 6-[桑尼](https://thonny.org/) Thonny 對於初學者來說是一個很棒的 IDE。 它具有幫助理解程式設計過程以及直接編寫和除錯 Python 程式碼的出色功能。您可以在這個輕鬆的環境中嘗試以前的庫。 --- # 編碼平台 程式設計平台提供類似學術的環境，非常適合快速、結構化的學習。 ![編碼平台](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oqkaqb15vava1iuwg42l.png) ## 7- [Datacamp](https://www.datacamp.com/) 這是我開始使用Python的平台，怎麼能不包括它呢？ Datacamp 是一個互動式學習平台，專注於圍繞資料科學和分析進行程式設計。他們有不同程度的課程，使其成為開始學習 Python 和資料分析概念的好地方。 --- ## 8-【程式碼實戰】(https://codecombat.com/) Code Combat 讓學習變得有趣，就像您在玩遊戲的同時學習 Python 一樣。 這個平台有一個世界，您可以在遊戲中提升角色，同時學習如何編碼。 這個網站適合年輕一代，但我建議任何年齡的初學者嘗試！ --- ## 9- [Sololearn](https://www.sololearn.com/) 這個平台透過他們的社區旋轉和發展。 Sololearn 專注於簡短的 Python 課程，是隨時隨地學習 Python 的絕佳工具。 --- # 教學與挑戰 教學和挑戰是透過小型且可管理的專案來增強和測試 Python 技能的絕佳方法。 ![教學](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v195zko860x4d3bffznm.png) ## 10- [Codechef](https://www.codechef.com/) 該網站以程式設計競賽為特色。 對於那些透過競賽學得更好的人來說，Codechef 適合您。它們提供各種挑戰來滿足所有程式設計等級的需求。 --- ## 11- [Codewars](https://www.codewars.com/) 該社區網站還提供程式設計挑戰。 這是使用 Python 學習和挑戰自己的好方法。 --- ## 12- [精通機器學習](https://machinelearningmastery.com/) Machine Learning Mastery 提供機器學習和 Python 的教學和書籍。 這些教程對我的一些機器學習專案很有幫助，我仍然不時回顧它們！ --- # 完整專案 使用 Python 建立整個專案是在現實場景中測試您的技能的好方法。一般來說，這些專案是對你的投資組合的一個很好的補充。 ![完整專案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/la3zqq1e7kr7gmncblxa.png) ## 13- [Kaggle](https://www.kaggle.com/) 這個平台是我測試 Python 和機器學習技能的首選平台。該平台展示資料科學專案。 Kaggle 也是加入到您的履歷中的一個很好的資源。 --- ## 14- [freeCodeCamp](https://www.freecodecamp.org/) 儘管 freeCodeCamp 專注於 Web 開發，但該平台也使用 Python 專案。邊做邊學的好方法。 --- # 黑客松 黑客馬拉松是在動態和協作的環境中學習的好方法。參加黑客馬拉鬆在學術和專業上都很有價值。 ![黑客松](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w9xcuqaoj7tsw7a7ri0b.png) ## 15- [駭客大聯盟](https://mlh.io/) MLH 為來自世界各地的學生舉辦黑客馬拉松。他們的黑客馬拉松可以在現場進行，也可以在網路上進行。 黑客馬拉松非常適合將 Python 技能應用到實際專案中。 此外，這是在面試或履歷中展示專案的好方法。 --- ## 16- [Devpost](https://devpost.com/) Devpost 是一個線上黑客馬拉松網站。他們提供的活動<在主題和獎品方面有很多選擇！ --- ## 結論 這些資源提供了多種方式來透過這些易於使用的函式庫、互動式學習平台和實際挑戰來啟動您的 Python 程式設計之旅。 --- ![GIF 結束](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rvimkpxsq91d6m1jfei1.gif) 如果您有任何問題或回饋，請隨時與我們聯繫！ --- 原文出處：https://dev.to/taipy/python-playground-16-ways-to-get-started-4fgg

0個讚   0留言 167瀏覽

使用 Next.js、Resend 和 Trigger.dev 建立後台電子郵件通知

## 您會在本文中找到什麼？ 電子郵件通知是讓使用者了解應用程式所執行操作的最常用方法。典型的通知包括：有人追蹤您、有人喜歡您的貼文、有人查看了您的內容。在這篇文章中，我們將探索如何使用 Next.js、Resend 和 Trigger.dev 建立一個簡單的非同步電子郵件通知系統。 我們將使用 Next.js 作為框架來建立我們的應用程式。我們將使用 Resend 發送電子郵件，並使用 Trigger.dev 非同步卸載和發送電子郵件。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jwlb0t41kg2s3djcb072.gif) ## Papermark - 開源 DocSend 替代品。 在我們開始之前，讓我與您分享 Papermark。它是 DocSend 的開源替代方案，可幫助您安全地共享文件並從查看者那裡獲取即時的逐頁分析。全部都是開源的！ 如果您能給我們一顆星星，我會非常高興！別忘了在留言區分享你的想法❤️ [https://github.com/mfts/papermark](https://github.com/mfts/papermark) [![Papermark 應用程式](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/igzk8cdssbmla9uf1544.png)](https://github.com/mfts/papermark) ## 設定專案 讓我們繼續為我們的電子郵件後台通知系統設定專案環境。我們將建立一個 Next.js 應用程式，並設定為重新發送，最重要的是，設定觸發器來處理非同步電子郵件通知。 ### 使用 TypeScript 和 Tailwindcss 設定 Next.js 我們將使用「create-next-app」產生一個新的 Next.js 專案。我們還將使用 TypeScript 和 Tailwind CSS，因此請確保在出現提示時選擇這些選項。 ``` npx create-next-app # --- # you'll be asked the following prompts What is your project named? my-app Would you like to add TypeScript with this project? Y/N # select `Y` for typescript Would you like to use ESLint with this project? Y/N # select `Y` for ESLint Would you like to use Tailwind CSS with this project? Y/N # select `Y` for Tailwind CSS Would you like to use the `src/ directory` with this project? Y/N # select `N` for `src/` directory What import alias would you like configured? `@/*` # enter `@/*` for import alias ``` ### 安裝重新傳送和 React-Email Resend 是開發人員優先的事務性電子郵件服務。我們將使用它向我們的用戶發送電子郵件。 `react-email` 是一個 React 元件庫，可以輕鬆建立漂亮的電子郵件。 ``` npm install resend react-email ``` ### 安裝觸發器 Trigger 是 TypeScript 的後台作業框架。它允許您從主應用程式中卸載長時間執行的任務並非同步執行它們。我們將使用它非同步發送電子郵件。 觸發器 CLI 是在新的或現有的 Next.js 專案中設定觸發器的最簡單方法。有關更多訊息，請查看[他們的文件](https://trigger.dev/docs/documentation/quickstarts/nextjs)。 ``` npx @trigger.dev/cli@latest init ``` ## 建立應用程式 現在我們已經完成了設置，我們準備開始建立我們的應用程式。我們將介紹的主要功能是： - 設定重新發送電子郵件 - 編寫API路由來發送電子郵件 - 新增觸發器作業以使電子郵件發送非同步 ### #1 設定重新傳送電子郵件 首先，我們需要設定重新發送來發送電子郵件。我們將在專案中建立一個新檔案「resend-notification.ts」並新增以下程式碼。 ``` // lib/emails/resend-notification.ts import { Resend } from "resend"; import { NotificationEmail } from "@/components/emails/notification"; const resend = new Resend(process.env.RESEND_API_KEY!); export async function sendNotificationEmail({ name, email, }: { name: string | null | undefined; email: string | null | undefined; }) { const emailTemplate = NotificationEmail({ name }); try { // Send the email using the Resend API await resend.emails.send({ from: "Marc from Papermark <[email protected]>", to: email as string, subject: "You have a new view on your document!", react: emailTemplate, }); } catch (error) { // Log any errors and re-throw the error console.log({ error }); throw error; } } ``` 使用「react-email」的通知電子郵件範本將如下所示： ``` // components/emails/notification.tsx import React from "react"; import { Body, Button, Container, Head, Heading, Html, Preview, Section, Text, Tailwind, } from "@react-email/components"; export default function ViewedDocument({ name, }: { name: string | null | undefined; }) { return ( <Html> <Head /> <Preview>See who visited your document</Preview> <Tailwind> <Body className="bg-white my-auto mx-auto font-sans"> <Container className="my-10 mx-auto p-5 w-[465px]"> <Heading className="text-2xl font-normal text-center p-0 mt-4 mb-8 mx-0"> <span className="font-bold tracking-tighter">Papermark</span> </Heading> <Heading className="mx-0 my-7 p-0 text-center text-xl font-semibold text-black"> New Document Visitor </Heading> <Text className="text-sm leading-6 text-black"> Your document was just viewed by someone. </Text> <Text className="text-sm leading-6 text-black"> You can get the detailed engagement insights like time-spent per page and total duration for this document on Papermark. </Text> <Section className="my-8 text-center"> <Button className="bg-black rounded text-white text-xs font-semibold no-underline text-center" href={`${process.env.NEXT_PUBLIC_BASE_URL}/documents`} style={{ padding: "12px 20px" }}> See my document insights </Button> </Section> <Text className="text-sm"> Cheers, <br /> The Papermark Team </Text> </Container> </Body> </Tailwind> </Html> ); } ``` ### #2 撰寫API路由發送電子郵件 現在，我們已經準備好了電子郵件範本。我們可以使用它向我們的用戶發送電子郵件。我們將建立一個無伺服器函數，該函數會取得使用者的“姓名”和“電子郵件”，並使用我們之前建立的“sendNotificationEmail”函數向他們發送電子郵件。 ``` // pages/api/send-notification.ts import { NextApiRequest, NextApiResponse } from "next"; import prisma from "@/lib/prisma"; import { sendViewedDocumentEmail } from "@/lib/emails/resend-notification"; export const config = { maxDuration: 60, }; export default async function handle( req: NextApiRequest, res: NextApiResponse ) { // We only allow POST requests if (req.method !== "POST") { res.status(405).json({ message: "Method Not Allowed" }); return; } // POST /api/send-notification try { const { viewId } = req.body as { viewId: string; }; // Fetch the link to verify the settings const view = await prisma.view.findUnique({ where: { id: viewId, }, select: { document: { select: { owner: { select: { email: true, name: true, }, }, }, }, }, }); if (!view) { res.status(404).json({ message: "View / Document not found." }); return; } // send email to document owner that document await sendViewedDocumentEmail({ email: view.document.owner.email as string, name: view.document.owner.name as string, }); res.status(200).json({ message: "Successfully sent notification", viewId }); return; } catch (error) { console.log("Error:", error); return res.status(500).json({ message: (error as Error).message }); } } ``` ### #3 新增觸發器作業，使電子郵件傳送非同步 我們的電子郵件發送功能已準備就緒，但我們不想同步發送電子郵件，因此要等到電子郵件發送後應用程式才會回應使用者。我們希望將電子郵件傳送任務轉移到後台作業。我們將使用觸發器來做到這一點。 在設定中，Trigger CLI 在我們的專案中建立了一個「jobs」目錄。我們將在該目錄中建立一個新檔案“notification-job.ts”並新增以下程式碼。 ``` // jobs/notification-job.ts import { client } from "@/trigger"; import { eventTrigger, retry } from "@trigger.dev/sdk"; import { z } from "zod"; client.defineJob({ id: "send-notification", name: "Send Notification", version: "0.0.1", trigger: eventTrigger({ name: "link.viewed", schema: z.object({ viewId: z.string(), }), }), run: async (payload, io, ctx) => { const { viewId } = payload; // get file url from document version const notification = await io.runTask( "send-notification", async () => { const response = await fetch( `${process.env.NEXT_PUBLIC_BASE_URL}/api/send-notification`, { method: "POST", body: JSON.stringify({ viewId }), headers: { "Content-Type": "application/json", }, } ); if (!response.ok) { await io.logger.error("Failed to send notification", { payload }); return; } const { message } = (await response.json()) as { message: string; }; await io.logger.info("Notification sent", { message, payload }); return { message }; }, { retry: retry.standardBackoff } ); return { success: true, message: "Successfully sent notification", }; }, }); ``` 將匯出新增至作業索引文件，否則觸發器將不知道該作業。雖然是小細節，但連我都忘記了這一點，並花了一個小時尋找錯誤。 ``` // jobs/index.ts export * from "./notification-job"; ``` ### 獎勵：防止惡意存取 API 路由 我們已準備好 API 路由，但我們不想允許任何人存取它。我們希望確保只有我們的應用程式可以存取它。我們將使用一個簡單的標頭身份驗證金鑰來做到這一點。 在觸發器作業中，我們將標頭加入到請求中： ``` // jobs/notification-job.ts .. ... const response = await fetch( `${process.env.NEXT_PUBLIC_BASE_URL}/api/jobs/send-notification`, { method: "POST", body: JSON.stringify({ viewId }), headers: { "Content-Type": "application/json", Authorization: `Bearer ${process.env.INTERNAL_API_KEY}`, // <- add the authenication header with a local env variable }, }, ); ... .. ``` 在 API 路由中，我們將在「try {} catch {}」區塊之前檢查 API 金鑰是否符合： ``` // pages/api/send-notification.ts .. ... // Extract the API Key from the Authorization header const authHeader = req.headers.authorization; const token = authHeader?.split(" ")[1]; // Assuming the format is "Bearer [token]" // Check if the API Key matches if (token !== process.env.INTERNAL_API_KEY) { res.status(401).json({ message: "Unauthorized" }); return; } ... .. ``` 確保將“INTERNAL_API_KEY”新增至“.env”檔案中。 ``` # .env INTERNAL_API_KEY="YOUR_API_KEY" ``` ## 結論 瞧！我們已經準備好非同步電子郵件通知系統。我們現在可以非同步向用戶發送電子郵件，而不會影響用戶等待時間。我們還可以使用觸發器從主應用程式中卸載許多我們不希望用戶等待的其他任務。 感謝您的閱讀。我是 Marc，開源倡導者。我正在建立 [papermark.io](https://www.papermark.io) - DocSend 的開源替代品。 繼續編碼！ ## 幫幫我！ 如果您覺得這篇文章有幫助，並且對觸發器和後台任務有了更好的理解，如果您能給我們一顆星，我將非常高興！別忘了在評論中分享你的想法❤️ [https://github.com/mfts/papermark](https://github.com/mfts/papermark) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nk9c8ktyv1tf3n6jgbxh.gif) --- 原文出處：https://dev.to/mfts/building-background-email-notifications-with-nextjs-resend-and-triggerdev-4cem

0個讚   0留言 152瀏覽

從 Next.js 到 Rails 再到 Elixir：我的 React.js 倦怠之旅

我自 2019 年以來一直是 Web 開發人員。我使用 React.js 和基於 React 的框架，如 Gatsby、Next、Remix、Astro 和 Hydrogen。我從來沒有對這些工具感到完全滿意，但是，作為一個深入 JS 生態系統的初學者，我從同行那裡聽到的都是這樣的話：「這就是方式，任何其他程式語言要么慢，要么老」。 ![就是這樣](https://media.giphy.com/media/stnjSj2vpLcM4rwmEH/giphy.gif) 結果，我習慣了巨大的複雜性：多個獨立的儲存庫、數千個函式庫和框架來實現簡單的事情、GraphQL、微服務、無伺服器、靜態網站產生、增量靜態再生、部分水化、 redux 、redux-thunk、babel、webpack、react 伺服器元件、伺服器操作等。這個清單還可以再持續 10 分鐘。 直到有一天我說**受夠了！** 讓我們來看看我慢慢發瘋的完整時間線。這需要一段時間，在閱讀長篇文章之前，請隨意煮點咖啡！ --- ## 倦怠的時間表 ### [Gatsby.js](https://www.gatsbyjs.com/) 我記得完成我的訓練營並想：“我終於能夠建立我的作品集了！”，所以我做到了。只有一個小問題，我想在 Google 上建立索引，但是使用舊的「create-react-app」使這項任務幾乎不可能完成。很快我了解了 SEO 和 React 的水合循環，這讓我找到了這個問題的「解決方案」：Gatsby.js。靜態網站產生的想法對當時的我來說簡直是革命性的，畢竟沒有什麼比預先渲染 HTML 檔案更快了，對吧？ 我決定透過閱讀文件來學習這個新框架，讓我告訴你，這**不是**一次有趣的體驗。我以前從未聽說過 GraphQL，顯然，您需要它來產生所有靜態檔案（到底是什麼？？？）。我問我的一些網友，很難學習這些過度設計的廢話是否正常，他們回答說「技能問題，再努力一點！」。於是我更加努力，終於學會了之後，我把我的個人網站移植到了Gatsby上。 ![再努力一點](https://media.giphy.com/media/gzRiZROEyDCznPofKj/giphy.gif) 我的大部分頁面都成功在 Google 上建立了索引，幾個月來，我對結果非常滿意。然後另一個問題出現了：我的**很多**開發者朋友開始說“Gatsby 死了！建立 Next 是為了簡化靜態站點生成並提供伺服器端渲染”。 ### [Next.js](https://nextjs.org/) 我快速瀏覽了 Next 文件並**立即**愛上了它。我能夠在沒有 GraphQL 的情況下用三分之一的程式碼做與 Gatsby 相同的事情！我再次將我的作品集移植到另一個框架：Next。 這次我確實有一次美好的經驗。部署到 Vercel 輕而易舉，「getStaticProps」和「getServerSideProps」功能很簡單，但功能非常強大，我可以選擇每個頁面的渲染樣式，整體來說非常靈活。 不幸的是，我透過慘痛的教訓學到了一些東西：在 JavaScript 生態系統中，所有美好的事情都會結束。 ### [混音](https://remix.run/) 我清楚記得 Remix 發佈時的情景。多名科技影響者開始發布有關它的內容（一如既往）。然而，當時我在主頁上看到它不支援靜態網站生成，只支援伺服器端渲染，所以我想「等一下，這些年來投資於 [JAMstack](https://jamstack.org/) 都被扔在這裡了嗎？不可能，這個框架不會長久」。然而，令我驚訝的是，Remix 不僅生存了下來，而且還被 Shopify 收購 https://shopify.engineering/remix-joins-shopify ，並成為 Next 的重要競爭對手。 幾個月過去了，我決定嘗試看看。我再一次感到驚訝，Remix 的主要座右銘是使用 Web 基礎知識，而不是像 Next 這樣過於複雜的快取系統。因此，在Remix 中編碼時，我腦中需要的思維模型要簡單10 倍：沒有全域狀態管理器，只需使用URL，更少的客戶端狀態，將所有邏輯移至伺服器，並使用cookie，無需使用完整堆疊中間的 REST API 非常簡單，只需將資料庫查詢移至「loader」函數即可。 ### 離開矩陣 ![離開矩陣](https://media.giphy.com/media/11e0gEWxYoSYTK/giphy.gif) 然後，突然間，真相呈現在我面前，我服下了紅色藥丸。我的腦海中開始浮現出多個問題：Remix 不就像所有其他「古老而無聊」的框架（如 Rails、Laravel 和 Django）一樣嗎？幾十年來，我們一直在使用伺服器端渲染進行全端 Web 開發，但 JavaScript 黑手黨集體認為這種方法是垃圾，將所有內容移至客戶端才是未來。難道同一個黑手黨認為 Rails 一直都是對的嗎？用 JS 框架做所有那些過度設計的怪物不是正確的舉動嗎？我開始質疑一切。這種「新」的 Web 開發方式更加簡單、快速。 ### 我已經完成了 Next 和 Vercel 我透過 [Next.js 應用程式路由器](https://nextjs.org/docs/app) 達到了臨界點。以下是 Vercel 向 Next 推送的所有錯誤的完整清單： - 曾經簡單的：「getStaticProps」和「getServerSideProps」函數現在變得複雜而麻煩。目前，沒有特定的位置來新增 API 呼叫或資料庫查詢，您可以將它們寫入任何您想要的位置！在多年前使用 PHP 犯了同樣的錯誤之後，我們開始再次將業務邏輯與 UI 混合。難道前端開發者不吸取過去的教訓嗎？如果我刪除按鈕會發生什麼事？這是否會破壞我的使用者身份驗證流程，因為資料庫呼叫位於其中？您的前端應該 100% 可廢棄且可更換。你相對於競爭對手的競爭優勢在於業務邏輯，它應該與 UI 層完全隔離。 ![可怕的 Next.js 程式碼](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kp41ds14loo21xgimcza.png) - 接下來是伺服器優先。這聽起來沒那麼糟吧？畢竟，這解決了 SEO 問題並立即向用戶展示新鮮內容。問題在於，大多數現有的 Next 程式碼庫都依賴客戶端程式庫，例如樣式元件和一些全域狀態管理器。這是什麼意思？隨著此類重大變化的不斷發生，您的應用程式將在幾週而不是幾年內變成遺留軟體。更多的時間花在保持所有依賴項最新上，而不是做重要的事情：發布功能。 - Vercel 從 Meta 聘請了多名 React 核心團隊成員。這帶來了嚴重的利益衝突，因為這些工程師現在（據稱）正在發布有利於 Next 的功能，而不是優先考慮那些可以幫助所有基於 React 的框架（如 Remix）的功能。 ![Vercel 正在破壞 React](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9ye40ykjgrd3z10t5nx7.png) 我再也受不了了。我對自己說：你知道嗎？我厭倦了一遍又一遍地重新學習相同的框架，我完全不同意這種新的範式。 毫不奇怪，其他內容創作者也經歷了類似的情況： https://youtu.be/zkCBSz353fc?si=z3-FDVgcB3xfp06h https://youtu.be/Zt8mO_Aqzw8?si=10fy1d-ZoB7t3Uc_ --- ## 啟蒙之路 我非常累。在厭倦了所有的 React 工具後，我開始了尋找更簡單的 Web 框架的旅程。以下是我一直在尋找的先決條件： - 含電池 - 約定優於配置 - 良好的開發體驗 - 現代化且高性能的前端 我的第一個反應是查看 [Stack Overflow Survey 2023](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies) 中的頂級框架。我立即從清單中刪除了所有與 JS、C# 和 Java 相關的內容。我從來沒有興趣學習後兩個，它們看起來醜陋且冗長。所以剩下的選項是：Laravel (PHP)、Django (Python)、Rails (Ruby) 和 Phoenix (Elixir)。 Python 是我在網路工程學位期間使用的語言，我獲得了非常愉快的體驗。 Django 似乎遵循約定優於配置的理念，但最終讓我放棄它的是沒有一個好的內建工具來在前端工作。論壇上的大多數人都說他們使用[HTMX](https://htmx.org/) 和[Alpine](https://alpinejs.dev/)，但是，兩者都是您需要安裝的外部依賴項。 放棄Laravel 是非常困難的，因為它具有驚人的成本效益，有數百個官方軟體包可以處理新創公司可能需要的幾乎所有內容，例如託管、身份驗證、條紋支付等。對於前端，他們創造了[慣性。Node.js](https://inertiajs.com/)，這是一種非常簡單而優雅的方式，可以在前端使用 React 的同時保持 Laravel 的高生產力和強大功能。百分之百誠實地說，我沒有選擇 Laravel 的唯一原因是 PHP 的語法，它看起來很難看，到處都是一堆 `$` 和 `->`。 ### Ruby on Rails Ruby on Rails 無需介紹。它是 Web 開發框架的元年，其革命性的「15 分鐘建立部落格」至今仍令人印象深刻。在我開始抱怨我發現的所有問題之前，讓我們先從好的方面開始。 與 Python 類似，Ruby 是一種可以向非技術人員展示的語言，他們會理解該軟體想要做什麼。它是**迄今為止**我見過的最容易閱讀和最美麗的語言。我很快就意識到，[編寫視覺上令人愉悅的程式碼](https://world.hey.com/dhh/a-writer-s-ruby-2050b634) 是Rails 團隊的首要任務，這對我來說來說是新的。 更不用說 Rails 幾乎發明了「包含電池」和「約定優於配置」的哲學，所以這不會是一個問題。在一份文件中，我提供了任何類型的 Web 應用程式所需的一切。 在前端，有 [Hotwire](https://hotwired.dev/)，這是一種非常簡單且輕量級的方法，可以實現 SPA 框架提供的所有 UX 改進。我一直很好奇測試這個庫的極限，它看起來非常有前途。 好吧，Rails 在紙面上滿足了我想要的框架的所有先決條件。我們來試試吧！我在本地測試的第一件事是“railsscaffold”命令。我立即感到震驚。一個指令就能產生 CRUD 所需的一切？決不！ ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/58lbioexmot9412kojr5.png) 在 Node + React 領域，要實現相同的目標，我需要手動編寫所有程式碼（這裡沒有生成器）並安裝一堆程式庫，例如：Vite、prisma、express、react router、redux、redux-thunk 、 vitest、cypress 、react 測試庫、zod、typescript、eslint、prettier、1000 個不同的插件，甚至可能還有GraphQL 或tRPC。基本上就是一個已經有 900 個依賴項的 package.json。 在“railsscaffold”最初的震驚之後，當我從控制器打開程式碼時，我再次震驚了： ``` class ArticlesController < ApplicationController def index @articles = Article.all end def show @article = Article.find(params[:id]) end def new @article = Article.new end def create @article = Article.new(article_params) if @article.save redirect_to @article else render :new, status: :unprocessable_entity end end def edit @article = Article.find(params[:id]) end def update @article = Article.find(params[:id]) if @article.update(article_params) redirect_to @article else render :edit, status: :unprocessable_entity end end def destroy @article = Article.find(params[:id]) @article.destroy redirect_to root_path, status: :see_other end private def article_params params.require(:article).permit(:title, :body) end end ``` 這是所有後端程式碼嗎？只需幾行？這不可能！這非常簡單，看起來就像一個「低程式碼」工具。它簡單、優雅、可讀性極強，這是我們在 JS 領域很少見的。 好吧，好吧，你現在一定在想：「這個來自網路的瘋狂 React 開發者說他最終使用了 Elixir，所以 ruby 一定有問題！」。你是對的，我的匿名朋友，有些事情讓我很惱火，讓我們談談。 首先，我們需要解決房間裡的大象：從 React + Typescript 轉向動態類型語言並不容易。從我開始編寫程式碼的那一刻起，我的 VScode 上就沒有出現智慧感知或充滿程式碼建議的下拉式選單，我感到盲目和迷失。這是一種可怕的感覺，我可能會在函數名稱上輸入錯誤，直到網站投入使用時才意識到！我知道我們可以編寫測試，但這是我希望在 IDE 上立即辨識的錯誤類型，而不是在測試或部署期間辨識。 另一件我以為我會喜歡但最終討厭它的事情是：太多的魔法。在 Typescript 程式碼庫中，我可以點擊任何類別或函數的頂部，前往原始程式碼並查看其實作方式。在 Rails 上，我到底在哪裡進行驗證（例如）？我是否在控制器內建立私有函數？有專門的資料夾嗎？不，正確的位置是在模型內部。為什麼？因為這就是它的工作原理，所以您要么採用該約定，要么很難編寫 Ruby 程式碼。我根本無法對一切在幕後如何運作產生“直覺”，我必須盲目地相信維護者在組織一切方面做得很好。 為了解決我的挫折感，我開始寫前端程式碼。如何建立元件？ [部分](https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials)。如何定義該元件的 prop 類型？沒有辦法做到這一點，您需要打開它並直觀地查找其中的所有變數。做一些互動怎麼樣？建立國家？嗯，有帶有 [Stimulus](https://stimulus.hotwired.dev/) 的 Hotwire，但是正如您所看到的，您需要手動建立“重新渲染”功能，它沒有找到一種方法像React 這樣改變狀態後自動重新渲染頁面。 ``` // src/controllers/slideshow_controller.js import { Controller } from "@hotwired/stimulus" export default class extends Controller { static targets = [ "slide" ] initialize() { this.index = 0 this.showCurrentSlide() } next() { this.index++ this.showCurrentSlide() } previous() { this.index-- this.showCurrentSlide() } showCurrentSlide() { this.slideTargets.forEach((element, index) => { element.hidden = index !== this.index }) } } ``` 我再一次感到沮喪。我非常接近找到完美的框架！如果 Rails 失敗，我想嘗試的下一個框架是什麼？靈丹妙藥。 ### 長生不老藥和鳳凰 我必須說實話，我已經沒有耐心了。我嘗試了多種不同的生態系統，我幾乎確信要堅持使用 Ruby on Rails，並放棄對完美的追求。直到我的 YouTube 推薦部分出現了一個影片： https://www.youtube.com/live/bfrzGXM-Z88?si=Xsa7yCKeVSY5R3sT 堅持，稍等！在這裡我們可以看到一位 React 開發人員說了很多關於函數式程式設計、Elixir 和 Phoenix Live View 的好話。也許我應該嘗試一下！ 我做的第一件事就是打開Elixir 和Phoenix 的文件，我真的很喜歡這樣一個事實：所有包都使用[Hex Docs](https://hexdocs.pm/) 以相同的方式進行記錄，您只需要取得習慣於單一介面以學習新事物。 另一個好處是，您只需閱讀文件即可真正學習 Elixir，無需昂貴的課程！在其他所有生態系統中，我必須透過付費課程學習語言，然後透過閱讀文件來學習框架。 然後是時候開始編寫程式碼了。很快我就明白函數式程式設計與 OOP 有很大不同。我們來做一個小小的比較： ``` // JS const obj = {name: "daniel"} obj.age = 25 // result: obj = {name: "daniel", age: 25} ``` ``` # Elixir obj = %{name: "daniel"} obj = Map.put(obj, :age, 25) # result: obj = %{name: "daniel", age: 25} ``` 或者您可以使用管道運算子透過更簡單的語法實現相同的效果： ``` # Elixir with pipe operator obj = %{name: "daniel"} |> Map.put(:age, 25) # result: obj = %{name: "daniel", age: 25} ``` 最初，您可能會發現它的可讀性較差且更複雜，但我保證隨著時間的推移它會變得有意義！嗯，至少對我來說是這樣。身為 React 開發人員，我已經習慣了到處都可以看到多個函數，甚至前端元件也是函數！更不用說建立類別有時被 JavaScript 黑手黨視為一種程式碼味道。我的大腦已經針對這種新範式進行了“塑造”，這對我來說很自然。自從我在大學獲得網路工程學位以來，我上過幾門關於物件導向程式設計的課程，但它從來沒有「受歡迎」。我無法將複雜的問題建模為類別和物件。隨著時間的推移，使用多個函數來「改變」一個變數是我在腦海中建模的方式。 主要框架怎麼樣？包含鳳凰電池嗎？約定優於配置？ **是的！** 老實說，生態系統與 Rails 不在同一水平，但已經達到了 95%。除非您需要非常具體的功能，Phoenix 都能滿足您的需求。 我幾乎被 Elixir 迷住了，我的清單中缺少兩件事：良好的開發人員體驗和現代/高效能的前端程式碼。 José Valim 宣布他正在嘗試為該語言加入類型，但 Elixir 目前還沒有這些類型，所以我很擔心。如何在沒有類型的情況下獲得智能感知和自動完成？很快我發現這些功能不一定相關。在 VScode 上安裝 [ElixirLS 擴充功能](https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls) 後，我感到很驚訝。可以在隨機資料夾的隨機模組內定義函數，將其導入其他位置，並取得它的智慧感知和文件！我從靜態類型語言中獲得了這些好處，而無需編寫類型的麻煩，簡直太棒了！ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ 我對前端的最後一個擔憂是由 Phoenix [Live View](https://hexdocs.pm/phoenix_live_view/welcome.html) 解決的。在程式碼方面，這正是文件主頁中讓我信服的部分： ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5sjzj90khytebnk523fm.png) 您可以為每個元件定義“props”，如果類型不匹配，您的 IDE 中會出現錯誤，就像 React 一樣！感人的！ 使用者體驗怎麼樣？每當使用者點擊連結時是否會載入整個頁面？一定不行！即時視圖與客戶端建立 WebSocket 連接，然後每次頁面轉換只是透過 Websocket 進行內容交換，不會發出新的 HTTP 請求。此外，所有狀態都在伺服器端進行管理，這意味著 Trello 等豐富的用戶體驗過去由於加載過多的 JavaScript 而在客戶端非常卡頓，現在變得非常快！ Elixir 處理所有複雜的狀態邏輯並將頁面的更新部分傳送到前端。看看這裡的完整解釋： https://youtu.be/wrmVk2czqMg?si=ZoWAlPjQC-svmV3Y 由於我們使用 WebSocket 來建立 UI，因此建立像 Twitter 這樣的「即時」應用程式只需要幾行程式碼！ https://youtu.be/MZvmYaFkNJI?si=gAow6oIjgf8_OTkg ## 結論 可以肯定地說，「完美的技術堆疊」並不存在。解決所有問題的靈丹妙藥是我們在腦中創造的幻覺，以不斷尋找和建構最優化的工具。 然而，在個人層面上，完美的堆疊確實存在。因為每個開發人員都有偏好，您可以輕鬆找到適合您標準的工具。如果你有和我類似的旅程，完美的可能就是長生不老藥和鳳凰！所以試試看吧，也許你會像我現在一樣喜歡它。 如果您讀到了這篇文章的結尾，那您就太棒了！非常感謝您抽出寶貴的時間，希望我能為您的職業生涯帶來一些價值。 ![結束](https://media.giphy.com/media/lD76yTC5zxZPG/giphy.gif) --- 原文出處：https://dev.to/danielbergholz/from-nextjs-to-rails-then-elixir-my-journey-through-reactjs-burnout-h8d

0個讚   0留言 292瀏覽

極為簡單的 Python 專案結構與導入

喜歡這些文章嗎？買書吧！ [***Jason C. McDonald 的《Dead Simple Python》可從 No Starch Press 取得。](https://nostarch.com/dead-simple-python) --- 教程最糟糕的部分始終是它們的簡單性，不是嗎？您很少會發現一個包含多個文件的文件，更罕見的是包含多個目錄的文件。 我發現**建立 Python 專案**是語言教學中最常被忽略的部分之一。更糟的是，許多開發人員都會犯錯，在一堆常見錯誤中跌跌撞撞，直到他們得到至少「有效」的東西。 好訊息是：您不必成為他們中的一員！ 在《Dead Simple Python》系列的本期中，我們將探索「import」語句、模組、包，以及如何將所有內容組合在一起而不費力氣。我們甚至會涉及 VCS、PEP 和 Python 之禪。係好安全帶！ # 設定儲存庫 在我們深入研究實際的專案結構之前，讓我們先討論一下它如何適合我們的版本控制系統 [VCS]…從您*需要* VCS 的事實開始！有幾個原因是... * 追蹤您所做的每一個更改， * 弄清楚你什麼時候弄壞了東西， * 能夠查看舊版的程式碼， * 備份您的程式碼，以及 * 與他人合作。 您有很多選擇。 **Git** 是最明顯的，尤其是當您不知道還可以使用什麼時。您可以在 GitHub、GitLab、Bitbucket 或 Gitote 等上免費託管 Git 儲存庫。如果您想要 Git 以外的東西，還有許多其他選擇，包括 Mercurial、Bazaar、Subversion（儘管如果您使用最後一個，您可能會被同行視為恐龍。） 我將悄悄假設您在本指南的其餘部分中使用 Git，因為這是我專門使用的。 建立儲存庫並將「本機副本」複製到電腦後，您就可以開始設定專案了。您至少需要建立以下內容： - `README.md`：您的專案及其目標的描述。 - `LICENSE.md`：您的專案的許可證（如果它是開源的）。 （有關選擇一個的更多訊息，請參閱 [opensource.org](https://opensource.org/)。） - `.gitignore`：一個特殊文件，告訴 Git 要忽略哪些文件和目錄。 （如果您使用其他 VCS，則該檔案具有不同的名稱。請尋找。） - 包含您的專案名稱的目錄。 沒錯...**我們的Python 程式碼檔案實際上屬於一個單獨的子目錄！** 這非常重要，因為我們的儲存庫的根目錄將變得非常混亂，其中包含建置檔案、打包腳本、虛擬環境以及各種方式其他實際上不屬於原始碼的內容。 僅為了舉例，我們將虛構的專案稱為「awesomething」。 # PEP 8 和命名 Python 風格主要由一組稱為 **Python 增強提案**（縮寫為 **PEP**）的文件管轄。當然，並非所有 PEP 都被實際採納——這就是它們被稱為「提案」的原因——但有些是被採納的。您可以在Python官方網站上瀏覽主PEP索引。此索引的正式名稱為 [PEP 0](https://www.python.org/dev/peps/)。 現在，我們主要關注 [**PEP 8**](https://www.python.org/dev/peps/pep-0008/)，它最初由 Python 語言建立者 Guido van Rossum 於2001 年。該文件正式概述了所有Python 開發人員應普遍遵循的程式設計風格。把它放在枕頭下！學習它，遵循它，鼓勵其他人也這樣做。 （附註：PEP 8 指出樣式規則總是有例外。它是*指南*，而不是*命令*。） 現在，我們主要關注標題為 [“包和模組名稱”](https://www.python.org/dev/peps/pep-0008/#package-and-module-names)的部分。。 > 模組應該有簡短的、全小寫的名稱。如果可以提高可讀性，可以在模組名稱中使用下劃線。 Python 套件也應該有短的、全小寫的名稱，儘管不鼓勵使用底線。 我們稍後會了解*模組*和*包*到底是什麼，但現在，請了解**模組由檔案名稱命名**，而**套件由其目錄名稱命名**。 換句話說，**檔案名稱應全部小寫，如果可以提高可讀性，則使用下劃線。**同樣，**目錄名稱應全部小寫，如果可以避免，則不使用下劃線**。換句話說... + 執行此動作：`awesomething/data/load_settings.py` + 不是這個：`awesomething/Data/LoadSettings.py` 我知道，我知道，這是一種冗長的表達方式，但至少我在你的步驟中加入了一點 PEP。 （*你好？這個東西開著嗎？*） # 套件和模組 這會讓人感覺虎頭蛇尾，但這裡是那些承諾的定義： **任何Python（`.py`）檔案都是一個*模組*，目錄中的一堆模組是一個*套件*。** 嗯……差不多了。要讓目錄成為包，您還必須做另一件事，那就是將名為「__init__.py」的檔案貼到其中。實際上，您不必將任何內容*放入*該文件中。它必須在那裡。 您也可以使用`__init__.py` 做其他很酷的事情，但這超出了本指南的範圍，因此[請閱讀文件以了解更多資訊](https://docs.python.org/3/tutorial/modules.html#packages)。 如果你*確實*忘記了套件中的`__init__.py`，它會做一些比失敗更奇怪的事情，因為這使它成為一個**隱式命名空間包**。您可以使用這種特殊類型的套件做一些有趣的事情，但我不會在這裡討論。像往常一樣，您可以透過閱讀文件來了解更多：[PEP 420：隱式命名空間包](https://www.python.org/dev/peps/pep-0420/)。 所以，如果我們看看我們的專案結構，`awesomething` 實際上是一個包，它可以包含其他包。因此，我們可以將「awesomething」稱為我們的*頂級包*，以及其*子包*下的所有包。一旦我們開始進口東西，這將非常重要。 讓我們看一下我的現實專案“遺漏”的快照，以了解我們如何建置東西... ``` omission-git ├── LICENSE.md ├── omission │ ├── app.py │   ├── common │   │   ├── classproperty.py │   │   ├── constants.py │   │   ├── game_enums.py │   │   └── __init__.py │   ├── data │   │   ├── data_loader.py │   │   ├── game_round_settings.py │   │   ├── __init__.py │   │   ├── scoreboard.py │   │   └── settings.py │   ├── game │   │   ├── content_loader.py │   │   ├── game_item.py │   │   ├── game_round.py │   │   ├── __init__.py │   │   └── timer.py │   ├── __init__.py │   ├── __main__.py │   ├── resources │   └── tests │   ├── __init__.py │   ├── test_game_item.py │   ├── test_game_round_settings.py │   ├── test_scoreboard.py │   ├── test_settings.py │   ├── test_test.py │   └── test_timer.py ├── pylintrc ├── README.md └── .gitignore ``` （如果您想知道的話，我使用 UNIX 程式“tree”來製作上面的小圖。） 您會看到我有一個名為“omission”的頂級包，它有四個子包：“common”、“data”、“game”和“tests”。我還有“resources”目錄，但只包含遊戲音訊、圖像等（為簡潔起見，此處省略）。 `resources` 不是一個包，因為它不包含 `__init__.py`。 我的頂層包中還有另一個特殊檔案：`__main__.py`。這是當我們直接透過「python -m omission」執行頂級套件時執行的檔案。我們稍後會討論「__main__.py」中的內容。 # 導入如何進行 如果您以前編寫過任何有意義的 Python 程式碼，那麼您幾乎肯定熟悉「import」語句。例如... ``` import re ``` 知道當我們導入模組時，我們實際上是在執行它是有幫助的。這意味著模組中的任何“import”語句也正在執行。 例如，[`re.py`](https://github.com/python/cpython/blob/3.7/Lib/re.py#L122) 有幾個自己的 import 語句，當我們說 `導入重新`。這並不意味著它們可用於我們從*導入“re”的文件，但這確實意味著這些文件必須存在。如果（由於某種不太可能的原因）“enum.py”在您的環境中被刪除，並且您執行了“import re”，它將失敗並出現錯誤... > 回溯（最近一次呼叫最後一次）： > 檔案“weird.py”，第 1 行，位於 <module> 中 > 進口再 > 檔案“re.py”，第 122 行，位於 <module> 中 > 導入枚舉 > ModuleNotFoundError：沒有名為「enum」的模組 當然，讀到這裡，你可能會有點困惑。有人問我為什麼找不到外部模組（在本例中為“re”）。其他人想知道為什麼要導入內部模組（此處為“enum”），因為他們沒有直接在程式碼中請求它。答案很簡單：我們導入了 `re`，然後導入了 `enum`。 當然，上面的場景是虛構的：「import enum」和「import re」在正常情況下永遠不會失敗，因為這兩個模組都是Python核心庫的一部分。這只是一個愚蠢的例子。 ;) # 匯入註意事項 實際上有多種導入方式，但其中大多數應該很少使用（如果有的話）。 對於下面的所有範例，我們假設有一個名為「smart_door.py」的檔案： ``` # smart_door.py def close(): print("Ahhhhhhhhhhhh.") def open(): print("Thank you for making a simple door very happy.") ``` 例如，我們將在 Python 互動式 shell 中執行本節中的其餘程式碼，執行位置與「smart_door.py」相同。 如果我們想執行`open()`函數，我們必須先導入模組`smart_door`。最簡單的方法是...... ``` import smart_door smart_door.open() smart_door.close() ``` 我們實際上會說“smart_door”是“open()”和“close()”的**命名空間**。 Python 開發人員非常喜歡命名空間，因為它們讓函數和其他內容的來源一目了然。 （順便說一句，不要將 *命名空間* 與 *隱式命名空間包* 混淆。它們是兩個不同的東西。） **Python 之禪**，也稱為 [PEP 20](https://www.python.org/dev/peps/pep-0020/)，定義了 Python 語言背後的哲學。最後一行有一個聲明解決了這個問題： > 命名空間是一個非常棒的想法——讓我們做更多這樣的事情！ 然而，在某種程度上，命名空間可能會變得很痛苦，尤其是對於嵌套包來說。 `foo.bar.baz.whatever.doThing()` 太醜了。值得慶幸的是，我們確實有辦法避免*每次*呼叫函數時都必須使用命名空間。 如果我們希望能夠使用 `open()` 函數，而不必總是在其前面加上模組名稱，我們可以這樣做... ``` from smart_door import open open() ``` 但請注意，「close()」和「smart_door.close()」在最後一個場景中都不起作用，因為我們沒有直接匯入該函數。要使用它，我們必須將程式碼更改為這樣... ``` from smart_door import open, close open() close() ``` 在之前可怕的嵌套包噩夢中，我們現在可以說“from foo.bar.baz.whatever import doThing”，然後直接使用“doThing()”。或者，如果我們想要一點命名空間，我們可以說“from foo.bar.baz importwhatever”，然後說“whatever.doThing()”。 “導入”系統非常靈活。 但不久之後，您可能會發現自己說“但是我的模組中有數百個函數，我想全部使用它們！”這是許多開發人員偏離軌道的地方，這樣做... ``` from smart_door import * ``` **這非常非常糟糕！** 簡而言之，它直接導入模組中的所有內容，這是一個問題。想像一下下面的程式碼... ``` from smart_door import * from gzip import * open() ``` 你認為會發生什麼事？答案是，「gzip.open()」將是被呼叫的函數，因為這是在我們的程式碼中導入並定義的「open()」的最後一個版本。 `smart_door.open()` 已被 **shadowed** - 我們不能稱之為 `open()`，這意味著我們實際上根本無法呼叫它。 當然，由於我們通常不知道，或者至少不記得每個導入的模組中的*每個*函數、類別和變數，所以我們很容易陷入一堆混亂。 *Python 之禪* 也解決了這個情況... > 顯式優於隱式。 您永遠不必“猜測”函數或變數來自何處。文件中的某個位置應該有程式碼“明確”告訴我們它來自哪裡。前兩個場景證明了這一點。 我還應該提到，早期的 `foo.bar.baz.whatever.doThing()` 場景是 Python 開發人員不喜歡看到的。也來自 *Python 之禪*... > 扁平比嵌套更好。 一些包的嵌套是可以的，但是當你的專案開始看起來像一套精緻的俄羅斯娃娃時，你就做錯了。將模組組織到包中，但保持相當簡單。 # 在您的專案中匯入 我們之前建立的專案文件結構即將「非常方便」。回想一下我的「遺漏」專案... ``` omission-git ├── LICENSE.md ├── omission │ ├── app.py │ ├── common │ │ ├── classproperty.py │ │ ├── constants.py │ │ ├── game_enums.py │ │ └── __init__.py │ ├── data │ │ ├── data_loader.py │ │ ├── game_round_settings.py │ │ ├── __init__.py │ │ ├── scoreboard.py │ │ └── settings.py │ ├── game │ │ ├── content_loader.py │ │ ├── game_item.py │ │ ├── game_round.py │ │ ├── __init__.py │ │ └── timer.py │ ├── __init__.py │ ├── __main__.py │ ├── resources │ └── tests │ ├── __init__.py │ ├── test_game_item.py │ ├── test_game_round_settings.py │ ├── test_scoreboard.py │ ├── test_settings.py │ ├── test_test.py │ └── test_timer.py ├── pylintrc ├── README.md └── .gitignore ``` 在我的“game_round_settings”模組中，由“omission/data/game_round_settings.py”定義，我想使用“GameMode”類別。類別在「omission/common/game_enums.py」中定義。我怎樣才能到達它？ 因為我將“omission”定義為包，並將模組組織到子包中，所以實際上非常簡單。在“game_round_settings.py”中，我說...... ``` from omission.common.game_enums import GameMode ``` 這稱為**絕對導入**。它從頂級包“omission”開始，然後進入“common”包，在其中查找“game_enums.py”。 一些開發人員向我提供更像「from common.game_enums import GameMode」的導入語句，並想知道為什麼它不起作用。簡而言之，「data」套件（「game_round_settings.py」所在的位置）不知道其兄弟包。 然而，它確實知道它的父母。正因為如此，Python 有一種叫做「相對導入」的東西，它可以讓我們做同樣的事情，就像這樣... ``` from ..common.game_enums import GameMode ``` `..` 表示“此套件的直接父包”，在本例中為“omission”。因此，導入後退一級，進入“common”，並找到“game_enums.py”。 關於是否使用絕對導入或相對導入有許多爭論。就我個人而言，我更喜歡盡可能使用絕對導入，因為它使程式碼更具可讀性。不過，您可以自己做決定。唯一重要的部分是結果是「顯而易見的」——任何東西的來源都不應該是神秘的。 (繼續閱讀：[Real Python - Python 中的絕對導入與相對導入](https://realpython.com/absolute-vs-relative-python-imports/) 這裡還隱藏著另一個陷阱！在 `omission/data/settings.py` 中，我有這一行： ``` from omission.data.game_round_settings import GameRoundSettings ``` 當然，由於這兩個模組都在同一個包中，我們應該可以直接說“from game_round_settings import GameRoundSettings”，對嗎？ *錯誤！* 它實際上無法找到“game_round_settings.py”。這是因為我們正在執行頂級包“omission”，這意味著**搜尋路徑**（Python 查找模組的位置以及順序）的工作方式不同。 但是，我們可以使用相對導入來代替： ``` from .game_round_settings import GameRoundSettings ``` 在這種情況下，單一“.”表示“這個包”。 如果您熟悉典型的 UNIX 檔案系統，這應該開始有意義。 `..` 表示“後一級”，“.` 表示“目前位置”。當然，Python 更進一步：`...` 表示“後兩級”，`....` 表示“後三級”，依此類推。 但是，請記住，這些「等級」不僅僅是簡單的目錄。他們是包裹。如果在一個不是包的普通目錄中有兩個不同的包，則不能使用相對導入從一個包跳到另一個包。為此，您必須使用 Python 搜尋路徑，但這超出了本指南的範圍。 （請參閱本文末尾的文件。） # `__main__.py` 還記得我提到在我們的頂級包中建立一個 `__main__.py` 嗎？這是一個特殊的文件，當我們直接使用 Python 執行套件時會執行該文件。我的“omission”包可以使用“python -m omission”從我的存儲庫的根目錄執行。 這是該文件的內容： ``` from omission import app if __name__ == '__main__': app.run() ``` 是的，實際上就是這樣！我正在從頂級包“omission”導入我的模組“app”。 請記住，我也可以說「來自…」。改為導入應用程式。或者，如果我只想說“run()”而不是“app.run()”，我可以執行“from omission.app import run”或“from .app import run”。最後，只要程式碼可讀，我如何進行導入並沒有太大的技術差異。 （附註：我們可以爭論為我的主要`run()` 函數設定一個單獨的`app.py` 對我來說是否合乎邏輯，但我有我的理由......而且它們超出了本指南的範圍。 ） 首先讓大多數人感到困惑的部分是整個「if __name__ == '__main__'」語句。 Python 沒有太多**樣板** - 必須非常普遍地使用且幾乎不需要修改的程式碼 - 但這是那些罕見的位元之一。 `__name__` 是每個 Python 模組的特殊字串屬性。如果我將“print(__name__)”行貼在“omission/data/settings.py”的頂部，當該模組被導入（並因此執行）時，我們會看到“omission.data.settings”被打印出去。 當模組直接透過「python -m some_module」運作時，模組會被指派一個特殊值「__name__」：「__main__」。 因此，「if __name__ == '__main__':」實際上是在檢查該模組是否以 *main* 模組執行。如果是，它將在條件下執行程式碼。 您可以透過另一種方式看到這一點。如果我將以下內容加入到“app.py”的底部... ``` if __name__ == '__main__': run() ``` ……然後我可以直接透過 `python -m omission.app` 執行該模組，結果與 `python -m omission` 相同。現在`__main__.py`被完全忽略，`omission/app.py`的`__name__`是`"__main__.py"`。 同時，如果我只是執行“python -m omission”，“app.py”中的特殊程式碼將被忽略，因為它的“__name__”現在又是“omission.app”。 看看效果如何？ # 總結 我們來複習。 * 每個專案都應該使用 VCS，例如 Git。有很多選項可供選擇。 * 每個 Python 程式碼檔案 (`.py`) 都是一個 **模組**。 * 將您的模組組織到**包**中。每個包必須包含一個特殊的「__init__.py」檔案。 * 您的專案通常應由一個頂級包組成，通常包含子包。該頂級包通常共享您的專案的名稱，並作為專案存儲庫根目錄中的目錄存在。 * **永遠不要**在導入語句中使用「*」。在考慮可能的例外之前，Python 之禪指出「特殊情況並沒有特殊到足以違反規則」。 * 使用絕對或相對導入來引用專案中的其他模組。 * 可執行專案的頂層套件中應該有一個`__main__.py`。然後，您可以使用「python -m myproject」直接執行該套件。 當然，我們可以在建立 Python 專案時使用許多更高級的概念和技巧，但我們不會在這裡討論。我強烈建議閱讀文件： + [Python 參考：導入系統](https://docs.python.org/3/reference/import.html) + [Python 教學：模組](https://docs.python.org/3/tutorial/modules.html) + [PEP 8：Python 風格指南](https://www.python.org/dev/peps/pep-0008/) + [PEP 20：Python 之禪](https://www.python.org/dev/peps/pep-0020/) + [PEP 240：隱式命名空間套件](https://www.python.org/dev/peps/pep-0420/) --- *感謝 `grym`、`deniska` (Freenode IRC `#python`)、@cbrintnall 和 @rhymes (Dev) 提出的修改建議。* --- 原文出處：https://dev.to/codemouse92/dead-simple-python-project-structure-and-imports-38c6

0個讚   0留言 427瀏覽

✨ 5 個被低估的開源專案 🫵🤐

## 簡介 本文列出了五個不太受歡迎的優秀專案，您應該嘗試一下。 🔥 這些工具旨在改進**資料處理**、**API 開發**、**後端測試**、**身份驗證**和**安全隧道**。 諸如此類的開源專案依賴社群支持🙏，因此請考慮探索並為這些儲存庫加註星標，以促進它們的發展。 ![擁抱 GIF](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rxhja1odmmx414wrts5a.gif) *** ## 1. [集算器](http://scudata.com) **- 資料處理** > 💡 集算器是一種用於資料處理的腳本語言，具有豐富的函式庫函數和強大的語法。 ![集算器資料處理腳本語言](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z9dts1lgr1zy96k6zveu.jpg) 集算器是一個針對結構化和半結構化資料的計算和處理引擎。集算器既不是SQL系統，也不是NoSQL技術（如MongoDB），而是採用自創的SPL（結構化處理語言）語法，編碼更簡單，可以利用現有的資料處理技術建立高效的程式。 集算器是**純Java**編寫的，可以輕鬆為您的Java🍵應用程式加入強大的資料處理功能，但非Java應用程式可以透過RESTful API呼叫集算器。 ### 熱門常見問題解答🤔 > **⬇️集算器可以執行在哪些平台上？** 由於它純粹是用 Java 建置，因此可以在任何配備 JVM（Java 虛擬機）、雲端伺服器甚至容器的作業系統中流暢執行。 😎 > **⬇️集算器可以基於現有資料庫運作嗎？** 是的當然！集算器支援數十種資料來源，包括資料庫、文字、excel、json/xml、web服務等。 > **⬇️ 為什麼要放棄 SQL 而選擇集算器？** 簡化的逐步程式碼，易於編寫和除錯。相較於SQL降低N倍的開發、硬體、維運成本。 > 🟢我最近寫了一篇關於這個工具的文章，重點介紹了它的強大功能。看看吧👇。 https://dev.to/shricodev/one-must-have-tool-for-anyone-in-data-field-2jek > 如果你想更深入地了解這個工具的潛力，**[jbx1279](https://dev.to/jbx1279)**分享了一些關於集算器和SPL本身的富有洞察力的文章。請務必也檢查一下它們。 https://github.com/SPLWare/esProc *** ## 2. [Firecamp](https://firecamp.dev/) **- 郵差替代方案** > 💡 API 開發平台，幫助開發人員輕鬆設計、開發、測試和記錄他們的 API。 ![Firecamp 工具 Postman 替代品](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uigr65jz5z6yh731x9gm.jpg) Firecamp 是開放原始碼 Postman 的替代方案，具有 VScode DX，這是一個優先考慮開發人員體驗的 API 開發平台，並為設計、測試和記錄 API 提供無縫環境。 🎯 借助 Firecamp，跨工作區和團隊就 API 集合進行協作，並更快地建立 API，而無需在工具和應用程式之間切換。文件、CLI、CI/CD 一站式提供。 > **⬇️ 從 Postman 切換到 Firecamp 對我來說有挑戰性嗎？** 您可以將 Postman 腳本和資料（例如 **API Collection** 和 **環境變數**）無縫傳輸到 Firecamp，沒有任何問題。 ![Firecamp Postman 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q74wl17yc9b7clse6m3h.png) https://github.com/firecamp-dev/firecamp *** ## 3. [Keploy](https://keploy.io/) **- 後端測試** > 💡 為您的應用程式產生實際有效的測試和存根！ ![Keploy 產生後端測試](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ry5awt5wtk5qyiqccbwp.jpg) Keploy 是您的開源、以開發人員為中心的後端測試工具。它使工程團隊的後端測試變得簡單且有效率。使用 Keploy，我們不必編寫手動測試用例。 它記錄 API 互動和預期回應，並產生測試案例和資料模擬，使我們的工作變得輕鬆高效，顯著加快發布速度並增強可靠性。 📈 > **⬇️ 它是一個單元測試框架嗎？還是它完全取代了單元測試？** Keploy 與「go-test」、「Pytest」或「Jest」等單元測試框架配合得很好，可簡化測試流程並節省高達 80% 的工作。雖然它涵蓋了大多數情況，但您仍然可以選擇為非 API 可呼叫方法編寫測試。 > **⬇️ 我需要更改程式碼才能將 Keploy 整合到我的應用程式中嗎？** 不需要。Keploy 可以很好地與您現有的程式碼庫配合，無需更改程式碼。 ![Keploy 後端測試示範](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kdsnkmq2efgxltzplfq9.gif) https://github.com/keploy/keploy *** ## 4. [Hanko](https://hanko.io) **- 金鑰驗證** > 💡 支援 FIDO2 和 WebAuthn 標準的無密碼身份驗證伺服器。 ![Hanko 金鑰驗證](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aqifvf1i536y0afh7nhe.jpg) Hanko 是一款輕量級開源用戶身份驗證解決方案，可帶您踏上超越密碼的旅程。它支援 FIDO2 和 WebAuthn 標準，提供安全、無縫的使用者身份驗證體驗。 > **⬇️ Hanko 如何運作？** Hanko 的工作原理是使用使用者自己的裝置（例如智慧型手機、筆記型電腦或安全金鑰）註冊和驗證使用者。這些裝置可作為加密令牌，無需密碼或其他憑證即可證明使用者的身分。 Hanko 還支援各種身份驗證方法，例如行動應用程式中的生物辨識或 OAuth 登入。 > **⬇️ 我該如何開始使用 Hanko？** 您可以透過註冊免費帳戶並按照文件和教學課程開始使用 Hanko。對於生產用途，請選擇 Hanko Cloud。 > 🟢 我最近使用 Hanko Passkeys 身份驗證建立了一個專案。查看**[此處](https://github.com/shricodev/pdfwhisper-openai)**。 ![Hanko 登陸頁](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/emte4gfglhdft8g8dlhh.png) https://github.com/teamhanko/hanko *** ## 5. [Zrok](https://zrok.io/) **- Ngrok 類固醇** > 💡 Ngrok 的替代品，提供增強的功能和免費的 SaaS 型號。 ![Zrok ngrok 替代方案](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x4n31emowwxoamfqzawm.jpg) Zrok 是一個建立在 **OpenZiti** 之上的工具，有助於共享正在執行的服務，例如 Web 伺服器或網路套接字，或安全地將靜態檔案目錄共享到網際網路。它是 Ngrok 的替代品，但具有一些增強功能和**免費 SaaS** 型號。 借助 Zrok，您可以為應用程式建立安全隧道，從而更輕鬆地共享和協作專案。 > **⬇️ 使用 Zrok 相對於 Ngrok 有什麼好處？** Zrok 擁有內建的身份驗證系統、用於管理隧道的 Web 儀表板以及免費的 SaaS 模型。它也是完全**可自我託管**。 > **⬇️ 我該如何開始使用 Zrok？** 若要開始使用 Zrok，請下載適合您平台的 Zrok 用戶端或使用 Web 介面建立隧道。您也可以使用 Zrok CLI 從命令列建立和管理隧道。 ![Zrok 安全隧道](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bp8bguor0wj3i8h6ail1.png) https://github.com/openziti/zrok *** > 如果您認為您使用的任何其他方便的專案沒有應有的受歡迎，請在下面的評論部分分享。 👇 非常感謝您的閱讀！ 🎉🫡 --- 原文出處：https://dev.to/shricodev/top-5-underrated-open-source-projects-that-no-one-talks-about-2gki

0個讚   0留言 308瀏覽

我們用於建立人工智慧/資料全端應用程式的開源專案獲得了資助！ 🎉🎉

𝗛𝗶𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆， 我們很高興與您分享這個好訊息：我們上個月完成了 500 萬美元的種子輪融資，以幫助開發人員建立 AI/資料全端應用程式。 𝗧𝗵𝗲 𝗧𝗮𝗶𝗽𝘆 𝗦𝘁𝗼𝗿𝘆 幾年前，Albert 和我在為大型組織領導人工智慧專案多年後，決定是時候過渡到完整的 Python 開發並停止使用傳統的 Java、JS、.Net 堆疊等。 我們非常清楚我們正在尋找哪些功能，但令我們驚訝的是，我們在許多現有的 Python 套件中找不到它們。 我們的使命既簡單又雄心勃勃：提供缺少的磚塊，阻止如此多的人工智慧/資料試點成功部署專案。 特別是，我們希望將最終用戶帶回「人工智慧/資料」畫面。今天我仍然驚訝地發現，關於最終用戶的提及如此之少：從資料科學家到資料工程師，都是關於資料流、公開演算法等？沒有提及人類將如何與人工智慧/資料模型互動......我們想改變這一切！ 所以我們決定建造 Taipy… 𝗧𝗮𝗶𝗽𝘆𝗰𝗼𝗺𝗯𝗶𝗻𝗲𝘀： - 功能強大的互動式前端應用程式產生器，但學習/使用非常簡單。 - 「場景」是最終用戶（以及資料科學家）輕鬆與資料和演算法互動的可能性。 2022 年，我們首次推出了 Taipy 作為開源專案（請查看我們的 [GitHub 頁面](https://github.com/Avaiga/taipy)），隨後於當年稍後推出了企業版本。 感謝這個令人驚嘆的社區的大力支持和興趣，我們的 GitHub 計畫不僅流行，而且受歡迎程度也顯著上升，在幾週內從 100 顆星增加到 3,000 多顆星！我們非常感謝您的支持和熱情。 [隨意 ⭐ Taipy 儲存庫](https://github.com/Avaiga/taipy) 我還要感謝我們早期的企業採用者，他們在驗證和測試新技術方面非常重要。感謝麥當勞、KnowledgeTouch、Groupe Les Mousquetaires、Total Energies、Textil Apparel Limited、IFP-EN 等提供的特價。 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗦𝘁𝗮𝘁𝘂𝘀 我們最近發布了： - [Taipy Cloud](https://www.taipy.io/posts/introducing-taipy-cloud-the-easiest-way-to-deploy-your-taipy-applications)允許社群使用者部署、託管和與世界其他地方分享他們的應用程式 - 重要的後端功能：Taipy Studio、應用程式版本控制、任務排程、Python API、用於場景管理的視覺化元件、新的 CLI 等等... - 在前端方面：一個新的樣式套件、一組用於即時應用程式建立的預設樣式表範本、新圖表... - [TalkToTaipy](https://talk-to-taipy.tapy.cloud/)，基於 LLM 的應用程式，僅使用自然語言探索資料集 𝗧𝗮𝗶𝗽𝘆’𝘀𝗳𝘂𝘁𝘂𝗿𝗲 這項重大投資使我們能夠繼續全職致力於改進 Taipy。這筆資金也是實現我們願景的關鍵一步，將 Taipy 定位為 Python 人工智慧/資料專案的領先平台。 𝗧𝗵𝗲 𝗻𝗲𝘅𝘁 𝗿𝗲𝗹𝗲𝗮𝘀𝗲 (𝗽𝗹𝗮𝗻 𝟰） 即將（本季）推出的精彩版本包含主要新功能： - 全新的**無程式碼 GUI 設計器**：您無需編碼即可建立 GUI 頁面！抱歉劇透，但這位新設計師是個殺手！ - **分散式計算：** 在遠端叢集上執行以並行場景/任務執行。 - **與主要平台整合**：如 Databricks、Dataiku 等。 所有這一切，同時忠於我們的開源根源！ 𝗢𝗻 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝘀𝗙 - 我們現在出現在多個社群平台：[Discord](https://discord.com/invite/SJyz2VJGxV)、[LinkedIn](https://www.linkedin.com/company/taipy-io)、[ X](https://twitter.com/Taipy_io) 和[YouTube](https://www.youtube.com/@taipy_io)。 - 我們贊助了多項活動：會議（PyData、Pycon、ODSC...）、黑客馬拉松、派對、網路研討會... - 我們也計劃很快開始定期舉辦 Taipy 技術講座。 。 是的，所有這些都是開源的！ 我們總是渴望收到您的來信，因此，如果您認為 Taipy 需要改進或加入哪些內容，請告訴我們。您的意見對於制定我們的路線圖非常寶貴。 謝謝大家的支持。沒有您，我們不可能達到這個里程碑！ 文森特·戈塞林和阿爾伯特·安托萬 太皮聯合創辦人 還沒看過 Taipy 嗎？歡迎造訪我們的[GitHub頁面](https://github.com/Avaiga/taipy ）。 --- 原文出處：https://dev.to/taipy/our-open-source-project-for-building-ai-data-full-stack-apps-got-funded-4e68

0個讚   0留言 86瀏覽

网页文件加载失败如何重试

> 本文主要讲解脚本文件加载失败时的处理，对于其他类型的文件加载错误时，解决方向大致一样 ## 背景 在我们开发网站应用时，我们可能会遇到脚本加载失败的情况，导致脚本加载失败的原因有很多，比如用户的网络问题、终端设备问题、用户浏览器版本等诸多因素。 ## 解决方案 在 JavaScript 中，我们可以创建一个监听来监听脚本加载失败的情况，然后针对加载失败的脚本进行重新加载。 重新加载的方案，一般是通过更换域名来解决。我们给每个脚本添加一个映射关系表，用来在加载失败时匹配新的域名进行重试。 具体的解决方案，下面我一步一步讲解，另外希望大家可以仔细阅读注释中的内容 ```html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>脚本加载失败如何重试</title> <script> window.addEventListener( "error", // 监听全局错误 function (e) { console.log(e); }, true // 由于脚本加载失败不会冒泡，所以我们要在捕获阶段进行监听 ); </script> </head> <body> <script src="https://www.zowlsat.com/api/1.js"></script> <script src="https://www.qqqqqqq.com/api/2.js"></script> <script src="https://www.zowlsat.com/api/3.js"></script> </body> </html> ``` 此时我们可以在浏览器控制台看到以下效果 ![脚本加载失败如何重试](https://www.zowlsat.com/images/article/1.png) 但是这个监听方法会监听到很多其他的错误，我们只需要监听脚本加载失败的错误，所以我们要通过这个监听事件的参数 e 来判断了 ![脚本加载失败如何重试](https://www.zowlsat.com/images/article/2.png) 根据上图我们可以发现，普通错误的类型是 ErrorEvent，而脚本加载失败的类型是 Event，并且他的 target 会指向 script 标签，所以我们根据这个区别过滤掉其他的错误，这样剩下的情况才是我们需要处理的。 ```js window.addEventListener( "error", function (e) { if (e.target.tagName !== "SCRIPT" || e instanceof ErrorEvent) return; console.log(e); }, true ); ``` 接下来就是如何来实现重新加载，我们先给需要重新加载的域名建立一个映射关系，用于替换映射关系表中的域名。然后就是挨个匹配，当还是加载失败时继续匹配下一个，直到成功为止。 ```js const domainList = ["www.aaaaa.com", "www.bbbbb.com", "www.zowlsat.com"]; const retry = {}; window.addEventListener( "error", function (e) { if (e.target.tagName !== "SCRIPT" || e instanceof ErrorEvent) return; // 创建一个URL对象 const url = new URL(e.target.src); // 获取文件路径 const key = url.pathname; // 假如映射表中没有这个文件路径，那么就初始化一个映射键 if (!(key in retry)) { retry[key] = 0; } // 假如匹配完整个映射表都没重新加载成功，则放弃 const index = retry[key]; if (index >= domainList.length) { return; } // 获取新的完整路径 const domain = domainList[index]; // 替换域名 url.host = domain; // 创建新的script标签 const script = document.createElement("script"); script.src = url.toString(); // 将新的script标签追加到加载失败的script标签之前 document.body.insertBefore(script, e.target); retry[key]++; }, true // 由于脚本加载失败不会冒泡，所以我们要在捕获阶段进行监听 ); ``` 到此为止，我们功能已经基本实现，效果如下图 ![脚本加载失败如何重试](https://www.zowlsat.com/images/article/3.png) 但是有一个很关键的问题，就是假如我 2.js 这个文件中的内容，在 3.js 中要使用，那这样的话，2.js 就必须加载到 3.js 之前，否则就会报错。此时，我们就需要在 2.js 加载失败时，阻塞浏览器的解析，知道重新加载完成或者放弃重新加载时，再继续渲染之后的内容。 那这样的话我们该怎么做呢？🤔 其实很简单，在我们入门 js 时就学到过一个知识点，就是使用`document.write` `document.write`这个方法在解析期间使用的话，会阻塞浏览器的解析，而我们现在就是需要阻塞浏览器解析，那此时我们只需要将创建 script 标签的方法更换为`document.write`方法即可。 修改之后的代码如下： ```js const domainList = ["www.aaaaa.com", "www.bbbbb.com", "www.zowlsat.com"]; const retry = {}; window.addEventListener( "error", function (e) { if (e.target.tagName !== "SCRIPT" || e instanceof ErrorEvent) return; const url = new URL(e.target.src); const key = url.pathname; if (!(key in retry)) { retry[key] = 0; } const index = retry[key]; if (index >= domainList.length) { return; } const domain = domainList[index]; url.host = domain; // 此处加上转译是因为防止编译器识别script标签为结束标签报错 document.write(`\<script src="${url.toString()}">\<\/script>`); // const script = document.createElement("script"); // script.src = url.toString(); // document.body.insertBefore(script, e.target); retry[key]++; }, true ); ``` 现在我们再打开控制台查看，现在js文件按它原来的顺序执行了，这样既不会改变原有的代码逻辑，又可以在可控范围内进行重新加载。 效果如下图： ![脚本加载失败如何重试](https://www.zowlsat.com/images/article/4.png) 以上是简单实现了一个js文件重新加载错误的方案，其实这个方案也可以运用到其他很多类型的文件，不限于js文件。 然后我们还需要更加细化这个方法的话，我们可能还需要考虑到这个script标签是否带有`async`、`defer`等属性，还有诸多需要考虑的点，但是沿着这个方向解决的话，大体是没有问题的。

1個讚   0留言 113瀏覽

2024 年 7 個學習 Python 的最佳場所 [網站 + 平台]

--- 標題：2024 年學習 Python 的 7 個最佳地點 [網站 + 平台] 發表：真實 描述：如果您想知道 2024 年在哪裡學習 Python，那麼請查看這 8 個排名前列的網站和免費教程，以在 2024 年免費在線學習 Python 編程。 標籤: python, 程式設計, 編碼, 開發 封面圖片：https://thepracticaldev.s3.amazonaws.com/i/60y4jb5e98udezhppwt8.png --- *披露：這篇文章包含附屬連結；如果您透過本文提供的不同連結購買產品或服務，我可能會收到補償。* 不管你相信與否，Python 已經激勵了許多人學習編碼，而且它還在不斷激勵他們。我認識一些人因為不同的原因學習 Python，從 [web 開發](https://javarevisited.blogspot.com/2019/04/top-5-python-web-development-frameworks.html) 到[機器學習](https://javarevisited.blogspot.com/2019/08/top-5-python-books-for-data-science-and-machine-learning.html)。 我看過新人學習 Python，使用 Django 編寫 Web 應用程式，使用 Python 建立機器學習模型，然後編寫一些方便的腳本來自動執行無聊的工作。 Python 目前是世界上**#1 的程式語言**，並且由於資料科學和機器學習以及出色的 [Python 庫](https://javarevisited.blogspot.com/2018/10/ top-8-python- libraries-for-data-science-machine-learning.html）如Pandas、NumPy 和[TensorFlow](https://hackernoon.com/top-5-tensorflow-and-ml-courses-對於程式設計師-8b30111cad2c）。 因此，如果您也考慮在 2024 年學習 Python，或者已經開始使用 Python 進行編碼，但仍在尋找一些免費資源，那麼您來對地方了。 過去，我分享了許多有用的免費Python資源，例如[書籍](https://javarevisited.blogspot.com/2019/07/top-5-books-to-learn-python-in-2019.html ）和[免費課程](https://javarevisited.blogspot.com/2018/12/10-free-python-courses-for-programmers.html)。今天，我將分享一些可以免費學習 Python 的網站、免費教學和入口網站。 從免費資源中學習真是太棒了，因為您不需要信用卡，也不需要支付課程費用。您所需要的只是時間和學習的渴望。 然而，這並不容易，因為有很多[免費的Python資源](https://medium.com/swlh/5-free-python-courses-for-beginners-to-learn-online-e1ca90687caf)可用，選擇正確的一個是一項艱鉅的任務。這就像大海撈針一樣，這就是本文將為您提供幫助的地方。 順便說一句，如果你不介意花幾塊錢來學習像Python 這樣有價值和有用的東西，那麼我還建議你看看Josh Portilla 的**[完整的Python 3 Bootcamp](http://bit. ly/complete Udemy 上的 -python3-bootcamp)**。您將以更結構化的方式快速學習 Python，並且您可以在 Udemy 的促銷活動中僅花費 10 美元購買本課程。 ##2024 年 8 個初學者的熱門平台和免費 Python 教程 在這裡，您將找到一些免費學習 Python 的最佳地點，我與幾位 Python 專家一起精心挑選了這些資源。我有目的地選擇盡可能少的資源，但我仍然有一些選擇。如果您有任何其他免費教授 Python 開發的有用 Python 網站，請隨時推薦它們。 ###**1\. [Coursera](https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org%2F)** 如果您想在不支付一分錢的情況下向世界一流大學學習，那麼 Coursera 就是您的最佳選擇。它提供史丹佛大學、歐洲工商管理學院、新加坡國立大學（新加坡國立大學）等知名大學教授的線上課程。 最重要的是，它還有最受歡迎的免費課程之一來學習*Python - 適合所有人的程式設計*（Python 入門）。 本課程將從零開始教您 Python 3。您不需要任何程式設計經驗，因為您將在課程中學習。超過 1250,000 名學生已經註冊了這門課程並學習如何編程，現在是您從中受益的機會。 課程也是 [**Python forEverybody 專業化**](https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org% Coursera 上的2Fspecializations %2Fpython)，其中包含另外4 個深入學習Python 的課程，例如： 1.【Python資料結構】( https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org%2Flearn%2Fpython-data%3Fspecialization%3Dpython） 2.【使用Python存取Web資料】( https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org%2Flearn%2Fpython-network-data%3Fspecialization%3Dpython） 3. [透過Python使用資料庫]( https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org%2Flearn%2Fpython-databases%3Fspecialization%3Dpython） 4. [Capstone 專案：使用 Python 檢索、處理和視覺化資料]( https://coursera.pxf.io/c/3294490/1164545/14726?u=https%3A%2F%2Fwww.coursera.org%2Flearn%2Fpython-data-visualization） 所有課程都可以免費旁聽，這意味著您可以免費加入並學習。但是，您無法參加作業和測驗，並且在付款之前不會獲得任何認證。 [![Python 適合所有人Coursera 免費課程](https://1.bp.blogspot.com/-9iz43SzwsfY/XX4691bTMjI/AAAAAAAAaYE/Xk960951xbALk2Y7eCIqfIgL94pOq5vDQCA51xbALk207eCIqfIgL94pOq5vDQA2057%/57%/A5%/B5%/B55%/B5/M5%/B5%/M5%/AM5%/B5%/Mr. 2Bfree。 .jpg) ]( https://dev.to/javinpaul/7-python-online-courses-for-beginners-and-intermediate-programmers-1h4k) 如果您想要所有這些和認證，那麼您需要註冊不是免費的專業化課程。如果您負擔得起並欣賞該課程，無論如何，您應該訂閱，它完全值得您的時間和金錢。 我建議加入 [Coursera Plus]，這是 Coursera 的訂閱計劃，可以無限制地存取許多課程、認證和專案。如果您想參加 Coursera 中的多個課程或認證，這可能是最好的學習方式，不僅包括 Python，還包括資料科學和雲端。 ------ ###**2\. [Udemy](https://click.linksynergy.com/deeplink?id=JVFxdTr9V80&mid=39197&murl=https%3A%2F%2Fwww.udemy.com%2F)** 這是另一個流行的線上課程平台，它可能擁有地球上最大的線上課程集合。我喜歡 Udemy，因為你幾乎可以找到任何你想學的課程，而且還是免費的。 與 [Codecademy](https://bit.ly/codecademypro) 不同，您不需要任何訂閱，只需建立免費帳戶，然後您就可以註冊免費的 Python 課程。大多數講師在首次推出課程時都會免費提供課程，以便獲得一些關注、評論和社會認同。 但是，也有一些完全免費的優質 Python 課程。您可以加入他們來學習 Python 3。以下是我最喜歡的一些免費課程，可幫助您深入學習 Python。 Udemy 的優點是您可以向專家學習，但它的互動性不如 CodeCademy。不過，如果您喜歡透過影片學習，那麼沒有比 Udemy 更好的地方了。 如果你能負擔得起一些錢，你還可以以10 美元左右的一次性價格獲得很棒的訓練營風格的課程，例如**[The Complete Python 3 Bootcamp](http://bit.ly/complete -python3-bootcamp)**關於他們的閃購。 [![5 個免費學習 Python 的網站](https://1.bp.blogspot.com/-D0BNTzFrdGo/XX44gcl_gII/AAAAAAAAaXk/yIXkYvrcO60EB9lgyHTQiCDp8nUoaAzSQCLcBGAsYvrcO60EB9lgyHTQiCDp8nUoaAzSQCLcBGAsY7/s400/The% ://bit.ly/complete-python3-bootcamp） -------- ###**3 [透過 Educative 從頭開始學習 Python](https://www.educative.io/courses/learn-python-from-scratch?affiliate_id=5073518643380224)** 如果您不知道 Educative.io 是一個基於文字的互動式平台，可讓您透過瀏覽器進行學習和編碼。您可以學習概念並只需在下一行中編寫程式碼，而無需擔心下載必要的軟體和設定開發環境。對於任何學習任何程式語言的初學者來說，這是最大的優勢，因為他們中的大多數人都陷入了這個設定部分。 如果你想[在2024 年學習Python](https://www.java67.com/2020/05/top-5-courses-to-learn-python-in-depth.html) 那麼這門課是完美的地方開始。本課程首先探索基本建置塊，然後再討論函數和循環等更高層次的概念。有趣的測驗和程式設計挑戰將伴隨您一路前行，幫助您強化課程中涵蓋的所有概念。 在課程結束時，您將熟悉[資料結構](https://becoming human.ai/6-courses-python-programmers-can-join-to-learn-data-structs-and -algorithms-c1a37284938e) 和Python中的函數式程式設計。這是一門免費課程，因此您無需支付任何費用即可加入，您只需建立 Educative.io 帳戶即可存取課程。 [![深入 Python 的免費教學](https://thepracticaldev.s3.amazonaws.com/i/2bwr9gfk1yxgn89j3kjy.png)](https://www.educative.io/courses/learn-python-from-從頭開始？affiliate_id=5073518643380224) ---- ### 4\. [DataCamp 的免費 Python 入門課程](https://datacamp.pxf.io/c/1193463/1012793/13294?u=https%3A%2F%2Fwww.datacamp.com%2Fcourses%2Fintro-to-python-for -資料科學） DataCamp 的「Python 程式設計簡介」課程對於想要踏上 Python 世界之旅的初學者來說是一個極好的資源。此免費課程具有用戶友好的介面和全面的內容，適合剛接觸程式設計或希望鞏固基礎 Python 技能的學習者。 它涵蓋了變數、資料類型、控制結構、函數等關鍵概念，確保學生充分掌握 Python 基礎知識。透過實踐方法，參與者參與實際練習和編碼挑戰，以增強他們的理解。 無論您是想進入資料科學、Web 開發或任何 Python 相關領域，本課程都會對該語言的語法和功能進行紮實的介紹，為更高級的學習奠定基礎。 說到社會認同，超過 500 萬人參加了這門課程，這是任何線上 Python 課程的記錄，它的平均評分為 4.7，簡直令人驚嘆。 順便說一下，如果您喜歡Datacamp的線上學習平台及其課程，可以考慮付費訂閱。他們有不同的計劃，如標準、專業和高級，允許存取所有專案。我推薦 **[標準計劃](https://datacamp.pxf.io/c/1193463/1012793/13294?u=https%3A%2F%2Fwww.datacamp.com%2Fpricing)** 因為它是正確的-價格合理，您可以獲得提高資料技能的所有必需品。 [![適合初學者的最佳免費Python課程](https://blogger.googleusercontent.com/img/a/AVvXsEhZ1TxSJhyjGvc8q5E6AE4d8YXovCdy4RuU75uZWx2ISudjW64QLyZgNCiERoA0Ee3HYjmW64QLyZgNCiERoA0Ee3HYjmW64QLDgNCiERo YAx yjX5tcmFxfSsiOOFfnIG6ta66ZtpgGFbs-m2KQpxFHdNxvlFyLbwk0hBfD-MhIWXo0fDjmbXsyli9EzQ=w395-h250)](https://datacampc. /c/1193463 /1012793/13294?u=https%3A%2F%2Fwww.datacamp.com%2Fcourses%2Fintro-to-python-for-data-science) -------- ###**5\. [CodeCademy](https://bit.ly/codecademypro)** 如果您喜歡互動式學習，那麼沒有比 CodeCademy 更好的地方了。他們首先用盡可能少的單字教你理論，然後要求你使用該概念在線上編寫程式碼。最好的事情是您不需要進行任何設置，例如在電腦上安裝 Python。 您可以直接從瀏覽器執行 Python 程式碼。另一個好處是，在準備好之前，您不需要編寫完整的程式。您需要進行一些小的更改並執行它們。這是學習 Python 程式設計的一種很棒且有趣的方式。 我使用他們的互動式平台學習了 JavaScript、Java、Python 和 Linux。早些時候，他們是完全免費的，但現在他們有免費增值模式，其中一些課程或課程僅對付費會員開放。 目前，他們的[**學習Python 2**](https://bit.ly/learnpython2withcodecademy)課程是免費的，而[**Python 3課程**](https://bit.ly/learnpython3codecademy)只是免費的可供付費會員使用。如果您負擔得起並欣賞 CodeCademy，請務必訂閱，但如果您無法從他們的 Python 2 課程開始，那麼它非常適合沒有編碼經驗的初學者。 [![線上學習Python的免費互動課程](https://1.bp.blogspot.com/-lSHI8IMKqGA/XX46dg1vjwI/AAAAAAAAaX8/4O1-n9jcl5YT47zh02TOYIdGA87j3AOxQCLcBGAsYhon/T47zh02TOYIdGA87j3AOxQCLcBGAsYhon/s4007% PG )](https://bit.ly/codecademypro) ----- ###**6\. [Google 的 Python 課程](https://developers.google.com/edu/python/)** 如果你不知道，Google 也為初學者提供了一套優秀的 Python 教程，稱為 Google 的 Python 課程。這是一個免費課程，適合有一點程式設計經驗並且想要學習 Python 的人。課程包括書面教程、講座影片和大量練習 Python 編碼的程式碼練習。 第一個練習涉及字串和清單等基本 Python 概念，為下一個練習奠定基礎，下一個練習是處理文字檔案、進程和 http 連接的完整程序。 Google 本身的許多專案都使用 [Python](https://javarevisited.blogspot.com/2018/05/10-reasons-to-learn-python-programming.html)。而且，這些材料通常在 Google 內部用於向剛開始編碼或幾乎沒有程式設計經驗的人教授 Python。 本材料最好的部分是 YouTube 上提供講座影片。因此您不需要任何其他帳戶。它還教您設定自己的[Python開發環境](https://medium.com/better-programming/top-5-courses-to-learn-python-in-2018-best-of-lot-26644a99e7ec ），這確實帶來了最初的挑戰，但從長遠來看是很好的。 ------ ###**7\. [微軟的免費Python課程](https://www.awin1.com/cread.php?awinmid=6798&awinaffid=631878&clickref=&p=%5B%5Bhttps%3A%2F%2Fwww.edx.org%2Fcourse%2Fintroduction-to - python-absolute-beginner-4%5D%5D)** 如果谷歌也有Python課程，微軟怎麼會落後呢？嗯，它還在 Edx（另一個流行的免費教育線上入口網站）上提供免費的 Python 課程。本課程名為“Python 簡介：絕對初學者”，是一門學習 Python 的免費課程，由高級內容開發人員 Eric Camplin 教授。 本課程將在Jupyter Notebooks 中教您Python，這是一個基於瀏覽器的線上[Python] 編碼編輯器(https://hackernoon.com/top-5-courses-to-learn-python-in-2018- best-of- lot-26644a99e7ec)，這表示你不需要安裝Python。這是一個為期 5 週的課程，每週學習 3 到 4 個小時。 本課程也是 Microsoft 入門級軟體開發專業計劃的一部分，該課程也是免費的。您只需在需要認證時付費。您可以將其新增至您的履歷或 LinkedIn 個人資料中，如下所示： [![免費最佳Python認證課程](https://1.bp.blogspot.com/-1U2amxNH280/XX47hDYf-3I/AAAAAAAAaYk/Xa8Se2JHrmca1AbXy81ILDQofQW4KyAzwCLcBGAsAsYHQ/s400/IntrodBPY free % 2B課程.png)](https://javarevisited.blogspot.com/2018/03/top-5-courses-to-learn-python-in-2018.html) ------ ###8。 [學習 Python - FreeCodeCamp 的初學者完整課程 [教程]](https://www.youtube.com/watch?v=rfscVS0vtbw) 本課程將向您全面介紹 Python 中的所有核心概念。跟著影片一起學習，您很快就會成為 Python 程式設計師！您可以在 YouTube 上免費觀看，這是目錄 ⭐️內容⭐ ⌨️ (0:00) 簡介 ⌨️ (1:45) 安裝 Python 和 PyCharm ⌨️ (6:40) 設定和 Hello World ⌨️ (10:23) 繪製形狀 ⌨️ (15:06) 變數和資料類型 ⌨️ (27:03) 使用字串 ⌨️ (38:18) 處理數字 ⌨️ (48:26) 取得使用者的意見 ⌨️ (52:37) 建構一個基本計算器 ⌨️ (58:27) 瘋狂自由遊戲 ⌨️ (1:03:10) 列表 ⌨️ (1:10:44) 列表函數 ⌨️ (1:18:57) 元組 ⌨️ (1:24:15) 功能 ⌨️ (1:34:11) 退貨聲明 ⌨️ (1:40:06) If 語句 ⌨️ (1:54:07) If 語句與比較 ⌨️ (2:00:37) 建構一個更好的計算器 ⌨️ (2:07:17) 字典 ⌨️ (2:14:13) While 循環 ⌨️ (2:20:21) 建構一個猜謎遊戲 ⌨️ (2:32:44) For 循環 ⌨️ (2:41:20) 指數函數 ⌨️ (2:47:13) 2D 清單和嵌套循環 ⌨️ (2:52:41) 建構翻譯器 ⌨️ (3:00:18) 評論 ⌨️ (3:04:17) 嘗試/例外 ⌨️ (3:12:41) 讀取文件 ⌨️ (3:21:26) 寫入文件 ⌨️ (3:28:13) 模組和 Pip ⌨️ (3:43:56) 類別與物件 ⌨️ (3:57:37) 建構多項選擇測驗 ⌨️ (4:08:28) 物件函數 ⌨️ (4:12:37) 繼承 ⌨️ (4:20:43) Python 解譯器 ![免費 Python 教學與平台](https://thepracticaldev.s3.amazonaws.com/i/zu01vymg8iberknzdeb8.png) ---- 這就是一些 **您可以免費學習 Python 的網站**。所有這些都是很棒的資源，您可以選擇您喜歡的資源。您不需要註冊所有這些，這將是荒謬且耗時的。相反，選擇最適合您的學習風格的一種。 例如，如果您喜歡互動式學習，請選擇[CodeCademy](https://javarevisited.blogspot.com/2019/09/codecademy-vs-udemy-vs-onemonth-which-is-better-for-learning-code . html），如果您喜歡非正規影片課程，那麼選擇 Udemy；如果您喜歡大學和學校等結構化教育，那麼選擇 Coursera。 而且，如果您喜歡基於文字的學習，請記住閱讀比觀看影片更快，那麼 Google 的 Python 課程是最好的。 除此之外，Scrimba 是另一個免費學習 Python 程式設計的好地方。 您可能喜歡的其他 **Python 文章和資源** - [2024年學習Python的10個原因](https://javarevisited.blogspot.com/2018/05/10-reasons-to-learn-python-programming.html) - [Python初學者學習Python的5大課程](https://javarevisited.blogspot.com/2018/03/top-5-courses-to-learn-python-in-2018.html) - [Python 開發者最喜歡的 5 個 Web 開發框架](https://javarevisited.blogspot.com/2019/04/top-5-python-web-development-frameworks.html) - [Python 與 JavaScript - 哪個更好開始？](https://javarevisited.blogspot.com/2019/05/python-vs-javascript-which-programming-language-beginners-should-learn.html) - [10門免費線上課程深入學習Python](https://javarevisited.blogspot.com/2018/12/10-free-python-courses-for-programmers.html) - [資料科學與機器學習的 8 個最佳 Python 函式庫](https://javarevisited.blogspot.com/2018/10/top-8-python-libraries-for-data-science-machine-learning.html) - [Python vs Java - 初學者應該學習哪種程式語言？](https://javarevisited.blogspot.com/2018/06/java-vs-python-which-programming-language-to-learn-first.html ) - [5 Python 資料科學與機器學習課程](https://javarevisited.blogspot.com/2018/03/top-5-data-science-and-machine-learning-online-courses-to-learn-online . html) - [完整的 Web 開發者路線圖](https://hackernoon.com/the-2019-web-developer-roadmap-ab89ac3c380e) - [10本針對程式設計師的免費Python程式設計書籍](http://www.java67.com/2017/05/top-7-free-python-programming-books-pdf-online-download.html) - [資料科學的 5 本 Python 書籍](https://javarevisited.blogspot.com/2019/08/top-5-python-books-for-data-science-and-machine-learning.html) 感謝您到目前為止閱讀這篇文章。如果您喜歡這些網站，請與您的朋友和同事分享。如果您有任何問題或回饋，請留言。 一切順利。 **P。 S. -** 如果你此刻只想做一件事來開啟你的 Python 程式設計之旅，那就加入 **[完整的 Python 3 Bootcamp](http://bit.ly/complete-python3-bootcamp ) ** Jose Portilla 在Udemy 上的課程。您將快速學習 Python 並且永遠不會後悔您的決定。 --- 原文出處：https://dev.to/javinpaul/top-5-places-to-learn-python-programming-for-free-m4c

0個讚   0留言 102瀏覽

SOLID 是你最需要的程式設計原則！

剛開始**物件導向程式設計**，不知道**SOLID**？別擔心，在本文中我將向您解釋它並舉例說明如何在開發程式碼時使用它。 - [什麼是 SOLID？](#什麼是 SOLID) - [S - 單一責任原則](#s-single-responsibility-principle) - [開閉原則](#the-開閉原則) - [L - 里氏替換原理](#l-里氏替換原理) - [I - 介面隔離原則](#i-interface-segregation-principle) - [D - 依賴倒置原則](#d-dependency-inversion-principle) - [結論](#conclusion) ##什麼是實體？ 在物件導向程式設計中，術語 SOLID 是五個設計假設的縮寫，旨在促進理解、開發和維護軟體。 當使用這套原則時，可以顯著減少錯誤的產生，提高程式碼質量，產生更有組織的程式碼，減少耦合，改進重構並鼓勵程式碼重複使用。 ## S - 單一職責原則 ![單一責任原則範例](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oebel9z9m0pupvh0bg02.png) >*SRP - 單一職責原則* 這原則說**一個類別必須有一個且只有一個改變的理由** 就是這樣，不要建立具有多種功能和職責的類別。您可能已經完成或遇到一個可以做所有事情的類，例如“God Class”。在那一刻看起來一切都很好，但是當需要對這個類別的邏輯進行任何更改時，問題肯定會開始出現。 >**God Class - God Class：** 在物件導向程式設計中，它是一個知道太多或做太多事情的類別。 ``` class Task { createTask(){/*...*/} updateTask(){/*...*/} deleteTask(){/*...*/} showAllTasks(){/*...*/} existsTask(){/*...*/} TaskCompleter(){/*...*/} } ``` 這個 **Task** 類別透過執行 **四個** 不同的任務來打破 **SRP** 原則。它正在處理**任務**的資料、顯示、驗證和驗證。 ### 這可能導致的問題： - 「缺乏連結」－一個類別不應該承擔不屬於它自己的責任； - 「太多的資訊在一起」 - 你的類別將有很多依賴項並且很難進行更改； - 「實現自動化測試的困難」 - 很難[“mock”](https://pt.wikipedia.org/wiki/Objeto_Mock)這種類型的類別； 現在將 **SRP** 應用於 *Task* 類，讓我們看看這個原則可以帶來的改進： ``` class TaskHandler{ createTask() {/*...*/} updateTask() {/*...*/} deleteTask() {/*...*/} } class TaskViewer{ showAllTasks() {/*...*/} } class TaskChecker { existsTask() {/*...*/} } class TaskCompleter { completeTask() {/*...*/} } ``` >您可以將建立、更新和刪除放在單獨的類別中，但根據專案的上下文和大小，最好避免不必要的複雜性。 也許您問過自己「我只能將其應用於類別嗎？」不，相反，您也可以將其應用於方法和函數。 ``` //❌ function emailClients(clients: IClient[]) { clients.forEach((client)=>{ const clientRecord = db.find(client); if(clientRecord){ sendEmail(client); } }) } //✅ function isClientActive(client: IClient):boolean { const clientRecord = db.find(client); return !!clientRecord; } function getActiveClients(clients: IClient[]):<IClient | undefined> { return clients.filter(isClientActive); } function emailClients(clients: IClient[]):void { const activeClients = getActiveClients(clients); activeClients?.forEach(sandEmail); } ``` 更美觀、優雅、更有組織的程式碼。這個原則是其他原則的基礎，透過應用它，您將建立優質、易於閱讀和易於維護的程式碼。 ## O - 開閉原則 ![開閉原則範例](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qk0e24cnjefd5e8r0h6c.png) >*OCP - 開閉原則* 這個原則說的是**物件或實體必須對擴充功能開放，但對修改關閉**，如果需要加入功能，最好對其進行擴展而不是更改其原始程式碼。 想像一個學校辦公室的小型系統，其中有兩個班級代表學生的課程表：小學和高中。另外還有一個班級，定義了學生的班級。 ``` class EnsinoFundamental { gradeCurricularFundamental(){} } class EnsinoMedio {     gradeCurricularMedio(){} } class SecretariaEscola { aulasDoAluno: string; cadastrarAula(aulasAluno){ if(aulasAluno instanceof EnsinoFundamental){ this.aulasDoAluno = aulasAluno.gradeCurricularFundamental(); } else if(aulasAluno.ensino instanceof EnsinoMedio){ this.aulasDoAluno = aulasAluno.gradeCurricularMedio(); } } } ``` `SecretariaEscola` 類別負責檢查學生的教育程度，以便在註冊課程時應用正確的業務規則。現在想像一下，這所學校在系統中加入了技術教育和課程表，那麼就需要修改這個課程，對吧？但是，這樣你就會遇到一個問題，那就是違反了*SOLID 的「開閉原則” *。 我想到了什麼解決方案？可能在類別中加入一個“else if”，就這樣，問題解決了。不是小學徒😐，這就是問題所在！ **透過更改現有類別以加入新行為，我們面臨著將錯誤引入到已經執行的內容中的嚴重風險。** >**記住：** **OCP** 認為課程必須針對更改關閉並針對擴充功能開放。 看看重構程式碼所帶來的美妙之處： ``` interface gradeCurricular {     gradeDeAulas(); } class EnsinoFundamental implements gradeCurricular {     gradeDeAulas(){} } class EnsinoMedio implements gradeCurricular {     gradeDeAulas(){} } class EnsinoTecnico implements gradeCurricular {     gradeDeAulas(){} } class SecretariaEscola {     aulasDoAluno: string;     cadastrarAula(aulasAluno: gradeCurricular) {         this.aulasDoAluno = aulasAluno.gradeDeAulas();     } } ``` 看到 `SecretariaEscola` 類，它不再需要知道要呼叫哪些方法來註冊該類別。它將能夠為建立的任何新型教學模式正確註冊課程表，請注意，我加入了“EnsinoTecnico”，無需更改原始程式碼。 >*自從我實作了 `gradeCurrarily` 介面以來。* >介面背後的獨立可擴展行為和反向依賴關係。 >鮑伯叔叔 - `開放擴充`：您可以為類別加入一些新功能或行為，而無需更改其原始程式碼。 -「修改關閉」：如果您的類別已經具有不存在任何問題的功能或行為，請勿變更其原始程式碼以新增內容。 ## L - 里氏替換原則 ![里氏替換原理範例](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eyrl3p96aqzowf72ipcb.png) >*LSP - 里氏替換原理* 里氏替換原則 — **A** **衍生類別必須可以被其基底類別取代**。 *兄弟* Liskov 在 1987 年的一次會議上介紹的這個原理在閱讀他的解釋時有點難以理解，但是不用擔心，我將向您展示另一個解釋和一個示例來幫助您理解。 > 如果對於 S 類型的每個物件 o1 都有一個 T 類型的物件 o2，這樣，對於用 T 定義的所有程式 P，當 o1 被 o2 取代時 P 的行為不變，那麼 S 是 T 的子類型 你明白了嗎？不，我第一次讀它時（或其他十次）也不明白它，但等等，還有另一種解釋： > 如果 S 是 T 的子類型，則程式中類型 T 的物件可以用類型 S 的物件替換，而不必變更該程式的屬性。 - [維基百科](https://pt.wikipedia.org/wiki/Princ%C3%ADpio_da_substitui%C3%A7%C3%A3o_de_Liskov)。 如果您更直觀，我有一個程式碼範例： ``` class Fulano { falarNome() { return "sou fulano!"; } } class Sicrano extends Fulano { falarNome() { return "sou sicrano!"; } } const a = new Fulano(); const b = new Sicrano(); function imprimirNome(msg: string) { console.log(msg); } imprimirNome(a.falarNome()); // sou fulano! imprimirNome(b.falarNome()); // sou sicrano! ``` 父類別和衍生類別作為參數傳遞，並且程式碼繼續按預期工作，神奇嗎？沒什麼，這就是我們利斯科夫兄弟的原則。 ### 違規範例： - 覆蓋/實作一個不執行任何操作的方法； - 拋出意外的異常； - 從基底類別傳回不同類型的值； ## I - 介面隔離原則 ![範例介面隔離原則](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p88do8ivd00s9aofo5yq.png) >*ISP - 介面隔離原則* 介面隔離原則 — **不應強迫類別實作它不會使用的介面和方法。** 該原則表明，建立更具體的介面比建立通用介面更好。 在下面的範例中，建立了一個「Animal」接口來抽象化動物行為，然後類別實作該接口，請參閱： ``` interface Animal { comer(); dormir(); voar(); } class Pato implements Animal{ comer(){/*faz algo*/}; dormir(){/*faz algo*/}; voar(){/*faz algo*/}; } class Peixe implements Animal{ comer(){/*faz algo*/}; dormir(){/*faz algo*/}; voar(){/*faz algo*/}; // Esta implementação não faz sentido para um peixe // ela viola o Princípio da Segregação da Interface } ``` 通用介面「Animal」強制「Peixe」類別具有有意義的行為，最終違反了 **ISP** 原則和 **LSP** 原則。 使用 **ISP** 解決此問題： ``` interface Animal { comer(); dormir(); } interface AnimalQueVoa extends Animal { voar(); } class Peixe implements Animal{ comer(){/*faz algo*/}; dormir(){/*faz algo*/}; } class Pato implements AnimalQueVoa { comer(){/*faz algo*/}; dormir(){/*faz algo*/}; voar(){/*faz algo*/}; } ``` 現在更好了，“voar()”方法已從“Animal”介面中刪除，我們將其加入到派生介面“AnimalQueVoa”中。這樣，行為就在我們的上下文中被正確隔離，並且我們仍然尊重介面隔離的原則。 ## D - 依賴倒置原則 ![依賴倒置原則範例](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9s5ywa9xijb41c1z2l1a.png) > *DIP — 依賴倒置原理* 依賴倒置原則 — **依賴抽象，而不是實現。** > 1. 高層模組不應該依賴低層模組。兩者都必須依賴抽象。 > > 2. 抽像不應該依賴細節。細節必須依賴抽象。 > > - *叔叔鮑伯* 在下面的範例中，我將展示一個簡單的程式碼來說明**DIP**。在此範例中，我們有一個透過不同方式（例如電子郵件和簡訊）發送訊息的通知系統。首先讓我們為這些通知方式建立具體的類別： ``` class EmailNotification { send(message) { console.log(`Enviando e-mail: ${message}`); } } class SMSNotification { send(message) { console.log(`Enviando SMS: ${message}`); } } ``` 現在，讓我們建立一個依賴這些具體實作的服務類別： ``` class NotificationService { constructor() { this.emailNotification = new EmailNotification(); this.smsNotification = new SMSNotification(); } sendNotifications(message) { this.emailNotification.send(message); this.smsNotification.send(message); } } ``` 在上面的例子中，`NotificationService`直接依賴`EmailNotification`和`SMSNotification`的具體實作。這違反了 DIP，因為高級 `NotificationService` 類別直接依賴低階類別。 讓我們使用 **DIP** 修復此程式碼。高級“NotificationService”類別不應依賴具體實現，而應依賴抽象。讓我們建立一個「Notification」介面作為抽象： ``` // Abstração para o envio de notificações interface Notification { send(message) {} } ``` 現在，具體的「EmailNotification」和「SMSNotification」實作必須實作此介面： ``` class EmailNotification implements Notification { send(message) { console.log(`Enviando e-mail: ${message}`); } } class SMSNotification implements Notification { send(message) { console.log(`Enviando SMS: ${message}`); } } ``` 最後，通知服務類別可以依賴「Notification」抽象： ``` class NotificationService { constructor(notificationMethod: Notification) { this.notificationMethod = notificationMethod; } sendNotification(message) { this.notificationMethod.send(message); } } ``` 這樣，「NotificationService」服務類別依賴「Notification」抽象，而不是具體實現，從而滿足**依賴倒置原則**。 ## 結論 透過採用這些原則，開發人員可以建立更能適應變化的系統，使維護變得更容易，並隨著時間的推移提高程式碼品質。 所有這些內容都是基於我學習 OOP 期間在網上找到的筆記、其他文章和影片，其中的解釋接近原理的作者，而示例中使用的程式碼是我根據自己對 OOP 的理解建立的。原則。讀者，我希望我對您的學習進程有所幫助。 --- 原文出處：https://dev.to/clintonrocha98/era-solid-o-que-me-faltava-bhp

0個讚   0留言 213瀏覽

如何製作精彩的 GitHub 個人資料

如果您是 GitHub 新手或主要使用私人 GitHub 儲存庫，那麼您可能還沒有 GitHub 個人資料。 GitHub 個人資料有助於為存取您個人資料的人提供基本資訊。擁有良好的個人資料甚至可以幫助您脫穎而出，尤其是當您開始為開源專案做出貢獻並且人們開始注意到您時。 在本文中，我將展示如何建立您自己的 GitHub 設定檔。我還將分享從哪裡獲得個人資料的靈感。最後，我將分享資源和技巧，幫助您建立出色的 GitHub 個人資料！ ## 建立您的 GitHub 個人資料 在開始自訂 GitHub 個人資料之前，您首先需要建立一個。 這是一個[簡短指南](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme)來自 GitHub，了解如何設定您的個人資料。 但您需要做的就是： - 建立一個新的儲存庫，**與您的 GitHub 使用者名稱**相同。 - 將 `README.md` 檔案新增至您的新儲存庫。 例如，我的 GitHub 使用者名稱是 [kshyun28](https://github.com/kshyun28)。要建立我的個人資料，我需要建立一個也名為 [kshyun28](https://github.com/kshyun28/kshyun28) 的儲存庫，然後新增一個「README.md」檔案。 ![範例 GitHub 設定檔儲存庫](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616186/GitHub%20Profile/github-profile-repository-example_veplgh.png) 設定「儲存庫」和「README.md」檔案後，透過前往您的 GitHub 個人資料(網址為 https://github.com/YOUR-USERNAME )來驗證您的個人資料是否可見。 就我而言，它將是 https://github.com/kshyun28。 ## 自訂您的 GitHub 個人資料 現在您已經有了 GitHub 個人資料，是時候發揮創意了！ 這裡的關鍵是**讓你的個性在你的個人資料上展現**。你的 GitHub 個人資料不必像 LinkedIn 那樣太正式。 我還建議**從簡單開始**。這有助於您的 GitHub 設定檔啟動並執行。當您有新想法時，您可以隨時改進您的個人資料。 ### GitHub 風格的 Markdown、格式和 HTML 為了自訂 GitHub 設定檔的“README.md”，您將使用 **GitHub Flavored Markdown**。如果您以前寫過 Markdown 內容，那麼格式化對您來說應該很容易。 如果你是第一次用Markdown 寫作，你可以去[GitHub 的文件](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) 來熟悉可用的格式化選項。 您也可以使用 **HTML** 作為您的個人資料的其他格式選項。 我發現以下 HTML 標記很有用： - 不間斷空格：`nbsp;` - div 居中對齊：`<divalign="center"></div>` 您可以使用大多數 HTML 標籤，但 GitHub Flavored Markdown 會過濾掉以下 HTML 標籤： - `<標題>` - `<文字區域>` - `<樣式>` - `<xmp>` - `<iframe>` - `<無嵌入>` - `<無框架>` - `<腳本>` - `<明文>` > 💡：要了解更多訊息，請參閱與 HTML 區塊相關的 [GitHub Flavored Markdown Spec](https://github.github.com/gfm/#html-blocks)。 ### 尋找靈感 為了幫助您入門，我建議您查看其他很棒的 GitHub 設定檔以獲取想法。你可以造訪 [awesome-github-profile-readme](https://github.com/abhisheknaiidu/awesome-github-profile-readme)，我在製作個人資料時找到了靈感。 由於設定檔是開源的，您可以將一些好主意用於您的精彩設定檔！ 您也可以查看[我的個人資料](https://github.com/kshyun28)以獲取一些想法。 😉 ### 新增徽章 要為您的個人資料加入徽章，您可以查看 [markdown-badges](https://github.com/Ileriayo/markdown-badges)。該存儲庫有多種徽章可供選擇，從程式語言到 Netflix 等串流平台。 如果您找不到所需的內容或想要建立自訂徽章，可以前往 [shields.io](https://shields.io/)，這就是 [markdown-badges](https://github.com/Ileriayo/markdown-badges) 使用。 這是我在個人資料中使用 [markdown-badges](https://github.com/Ileriayo/markdown-badges) 的範例。 ![Markdown 徽章範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616185/GitHub%20Profile/badges-example_t6jyr6.png) ### 新增圖標 要在您的個人資料中加入“技能”或“技術堆疊”部分，我建議使用 [skill-icons](https://github.com/tandpfun/skill-icons)，它提供漂亮的圖標。 如果您的圖示不受支持，您可以造訪 [simpleicons](https://simpleicons.org/)，其中包含超過 2900 個流行品牌的 SVG 圖示。 這是一個範例，我在個人資料的技術堆疊部分使用了 [skill-icons](https://github.com/tandpfun/skill-icons)。 ![圖示範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616185/GitHub%20Profile/icons-example_nyo1sn.png) ### 使用表情符號 在 GitHub Flavored Markdown 中，您可以使用表情符號。要查看支援的表情符號的完整列表，您可以存取此 [emoji-cheat-sheet](https://github.com/ikatyang/emoji-cheat-sheet)。 如果您想自己取得支援的表情符號列表，可以使用 [GitHub 的 Emoji API](https://docs.github.com/en/rest/emojis/emojis#get-emojis)。 在瀏覽器上造訪 https://api.github.com/emojis 應該會顯示所有支援的表情符號的 JSON 回應。 ``` { "+1": "https://github.githubassets.com/images/icons/emoji/unicode/1f44d.png?v8", "-1": "https://github.githubassets.com/images/icons/emoji/unicode/1f44e.png?v8", "100": "https://github.githubassets.com/images/icons/emoji/unicode/1f4af.png?v8", "1234": "https://github.githubassets.com/images/icons/emoji/unicode/1f522.png?v8", "1st_place_medal": "https://github.githubassets.com/images/icons/emoji/unicode/1f947.png?v8", "2nd_place_medal": "https://github.githubassets.com/images/icons/emoji/unicode/1f948.png?v8", "3rd_place_medal": "https://github.githubassets.com/images/icons/emoji/unicode/1f949.png?v8", "8ball": "https://github.githubassets.com/images/icons/emoji/unicode/1f3b1.png?v8", ... ``` 這是我在個人資料中使用表情符號的範例。 ![表情符號範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616185/GitHub%20Profile/emojis-example_yfzhef.png) ### 新增 GitHub 統計訊息 要為 GitHub 活動加入卡片和統計訊息，我建議使用 [github-readme-stats](https://github.com/anuraghazra/github-readme-stats)。您可以使用不同的版面配置和主題自訂統計卡。 以下是我將 GitHub 統計資料新增至我的個人資料的範例。 ![GitHub 統計資訊範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616186/GitHub%20Profile/github-stats-example_ndhxk3.png) ### 新增引號 在您的個人資料中加入隨機引用可以為訪客增添一抹亮色。我發現 [github-readme-quotes](https://github.com/PiyushSuthar/github-readme-quotes) 對於這樣做很有用。 這是我的個人資料上的樣子。我個人喜歡加入引號，為我的個人資料訪客提供一些價值。 ![報價範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704616185/GitHub%20Profile/quote-example_dfvjrh.png) ### 提高可存取性 自訂您的個人資料時，請確保它**可供盡可能多的人查看**。並非每個人都可以查看或載入圖像。有些人有殘疾，而有些人的網路連線速度很慢。 提高個人資料的[輔助功能](https://developer.mozilla.org/en-US/docs/Learn/Accessibility/What_is_accessibility)的一種方法是向圖像加入描述性「替代文字」。 ``` <!-- Markdown Image --> ![Image Alt Text](image-source) <!-- HTML Image Tag --> <img alt="Image Alt Text" src="image-source" /> ``` 然後，要測試您的個人資料的可存取性，您可以嘗試停用網頁瀏覽器上的圖像載入。這是有關如何停用 Google Chrome 映像載入的[指南](https://www.wikihow.com/Disable-Images-in-Google-Chrome)。 這是我的個人資料在 Google Chrome 上停用圖片載入後的樣子。 ![GitHub 設定檔可存取性範例](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704717170/GitHub%20Profile/github-profile-accessibility_vixcg8.png) ### 更多想法 要為您的個人資料加入更多資訊圖表，我建議查看 [metrics](https://github.com/lowlighter/metrics)。這是 GitHub 上最受好評的存儲庫之一，其中包含“github-profile”主題，因此我不能忽略它。 然後我發現了這個漂亮的資源 [beautify-github-profile](https://github.com/rzashakeri/beautify-github-profile)，在這裡您可以找到更多自訂個人資料的方法。 如果您也喜歡冒險，可以在[此處](https://github.com/topics/github-profile)探索「github-profile」主題。預設情況下，儲存庫會按星數排序。 請隨意探索有「github-profile」主題的儲存庫。您甚至可能會發現那些使用頻率不高但正是您所需要的。 ### GitHub 簡介 成就 雖然這與自訂 GitHub 設定檔的「README.md」無關，但我覺得有必要包含它。 如果您前往 GitHub 個人資料，您會注意到左側邊欄上有一個「成就」部分。 ![GitHub 個人資料成就](https://res.cloudinary.com/dlieqpdfd/image/upload/v1704632356/GitHub%20Profile/github-profile-achievements_tlqp3p.png) 收集這些成就很有趣，並且可以改善您的整體 GitHub 檔案。 要了解有關可用成就以及如何獲得這些成就的更多訊息，請查看 [GitHub 個人資料成就列表](https://github.com/Schweinepriester/github-profile-achievements)。 ## 結論 回顧一下，我們演練如何建立 GitHub 個人資料。然後我展示瞭如何使用 GitHub Flavored Markdown 和 HTML 格式化您的個人資料。之後，我分享了您可以從哪裡獲得個人資料的靈感。最後，我提供了有關如何自訂個人資料的提示和資源。 我希望這可以幫助您製作精彩的 GitHub 個人資料。我很想看看你能想出什麼辦法！ 感謝您的閱讀，請隨時發表評論或與我聯繫[此處](https://linktr.ee/kshyun28)。 --- 原文出處：https://dev.to/kshyun28/how-to-make-your-awesome-github-profile-hog

0個讚   0留言 236瀏覽

Kubernetes 變簡單 - Cyclops 簡介

如果您是開發人員，您很可能聽說過 Kubernetes。您聽說它是一個了不起的工具，可以幫助您擴展應用程式和管理微服務。但是，您可能也聽說過它**非常**複雜。它太複雜了，你可能會被嚇跑。我不怪你；這也是我的第一個反應。 如果您在此網站上搜尋帶有 Kubernetes 標籤的熱門帖子，您會發現大量教學和解釋 Kubernetes 的人員。 這些貼文是最熱門的，因為人們**想要**了解 Kubernetes，因為我們覺得，在當今的軟體開發世界中，Kubernetes 是不可避免的。某種程度上，這是真的… 軟體開發人員通常需要了解並使用 Kubernetes；如果您曾經在這個領域尋找過工作，您就會知道這一點。 但是，如果有一個工具可以最大限度地減少您與 Kubernetes 的接觸點呢？此工具可簡化流程並在您嘗試將應用程式部署到 Kubernetes 叢集時為您提供指導。一個高度可自訂的工具，可以讓組織中的某人（了解 Kubernetes，通常稱為 DevOps）為您建立使用者介面！ 是的，你沒看錯，就是獨眼巨人！ 😄 需要澄清的是，Cyclops 並不用於建立和管理 Kubernetes 叢集和其他基礎設施；而是用於建立和管理 Kubernetes 叢集和其他基礎設施。相反，Cyclops 用於在叢集內部署和管理應用程式。 ## 向我們展示您的支持🙏🏻 ![Github 明星](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zby3mjhcgvmvlpm9jtaa.gif) 我們正在將 Cyclops 打造為**開源**，您的支援對我們來說意味著一切。考慮在[GitHub](https://github.com/cyclops-ui/cyclops) 上給我們一顆星，並在我們預定的[ProductHunt](https://www.producthunt.com/products/cyclops)上關注我們我們的第一個版本！ ## 在我們開始之前 為了測試 Cyclops，您需要一些東西。如果這不是您第一次使用 Kubernetes，那麼您很可能已經準備好了一切，但我們仍然會為 Kubernetes 領域的新手描述每個元件。這些工具不僅用於 Cyclops，您還可以將它們用於任何與 Kubernetes 相關的事情。 測試 Cyclops 需要的主要內容是 Kubernetes 叢集。如果你有一個可以用來玩的東西，那就太好了；如果沒有，我們將向您展示如何在您自己的電腦上啟動叢集。因此，做到這一點的三個先決條件是： - [**Docker**](https://www.docker.com/products/docker-desktop/) - [**Minikube**](https://minikube.sigs.k8s.io/docs/) - [**kubectl**](https://kubernetes.io/docs/tasks/tools/) Docker 是最受歡迎的容器化工具，我們將使用它來下載並啟動 Minikube 映像。下載 Docker 非常簡單：造訪他們的網頁並下載 Docker 桌面應用程式。 Minikube 在本機電腦上扮演 Kubernetes 叢集的角色。它是開發和測試 Kubernetes 應用程式的絕佳工具，非常適合這種場景。您可以在[此處](https://minikube.sigs.k8s.io/docs/start/)找到有關如何安裝它的指南。 最後缺少的是與 Kubernetes 叢集通訊的方式，這是透過名為「kubectl」的 Kubernetes 命令列工具完成的。它可用於部署應用程式、檢查和管理叢集資源以及檢視日誌。在本教程中，我們將使用它將 Cyclops 安裝到 Minikube 上的叢集中，並在叢集外部公開其功能。 ## 安裝獨眼巨人 一旦您準備好 Kubernetes 叢集（請查看*開始之前*部分），安裝 Cyclops 就是一個簡單的過程。使用“kubectl”，在終端機中執行以下命令： ``` kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.0.1-alpha.5/install/cyclops-install.yaml ``` 它將建立一個名為「cyclops」的新命名空間，並部署 Cyclops 實例執行所需的一切。 現在，剩下的就是將 Cyclops 伺服器暴露在叢集之外。您需要使用以下命令公開後端和前端。 透過以下方式公開前端： ``` kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops ``` 並透過後端： ``` kubectl port-forward svc/cyclops-ctrl 8080:8080 -n cyclops ``` 就是這樣！現在您可以在瀏覽器中透過 [http://localhost:3000](http://localhost:3000/) 存取 Cyclops。 如果您在使用「port-forward」命令時遇到問題，您可能只需要在將 Cyclops 安裝到叢集中後等待幾秒鐘，可能需要一段時間才能啟動其所有資源。 ## 現在是示範時間💥 現在您已經啟動並執行了 Cyclops 實例，是時候看看它的功能了。 您應該會看到一個幾乎空白的螢幕，沒有顯示任何已部署的模組。 *模組* 是 Cyclops 的應用程式😎 的俚語。那麼，讓我們從建立我們的第一個模組開始吧！ 點擊右上角的“新增模組”按鈕，您應該會進入一個新畫面。在這裡，Cyclops 詢問我們要部署哪個 Helm 圖。 不要太深入，但 [Helm](https://helm.sh/) 是一個非常流行的 Kubernetes 開源套件管理器。它可以幫助您建立在 Kubernetes 中執行的應用程式所需的設定檔。這些圖表讓 Kubernetes 知道如何處理叢集中的應用程式。 不用擔心;為了展示 Cyclops 的基礎知識，我們建立了一個簡單的 Helm 圖表，以便任何人都可以遵循。您可以在我們的 [GitHub 儲存庫](https://github.com/cyclops-ui/templates/tree/main/demo) 中找到它的樣子，以及您可以使用的更多 Helm 圖表範例！ ![已載入圖表](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mpcmtuvaasmmr30er318.png) 正如您所看到的，一旦您進入圖表存儲庫，Cyclops 將呈現一個使用者介面。 *如果您想了解渲染背後的魔力，請查看我們之前的[博客](https://dev.to/cyclops-ui/how-cyclops-utilizes-json-schema-to-deliver-dynamical-ui-49e ).* 您可以根據需要填寫字段，但請注意 [Kubernetes 命名約定](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/)！ 如果您想繼續，我的輸入如下： - 名稱：`演示` - 副本：`1` - 圖片：`nginx` - 版本：`1.14.2` - 服務：“真實” 我們還將模組名稱設定為“demo”。點擊“儲存”，Cyclops 將向您顯示新模組的詳細資訊。 ![單一 Pod 部署](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lzdg5f5vhq5qmptq62zh.png) 此畫面顯示您的應用程式目前正在使用的所有資源。它將列出所有部署、服務、pod 或任何其他資源。在這裡，我們可以看到 Cyclops 將一個 Pod 部署到您的叢集中，正如我們在副本欄位中指定的那樣。如果您想確保它確實在叢集中執行，可以使用以下“kubectl”命令進行檢查： ``` kubectl get pods ``` 但是，如果突然需要擴展您的應用程式或任何其他資源怎麼辦？好吧，別擔心；有了 Cyclops，這真的很容易！ 透過點擊*編輯*按鈕，您可以變更應用程式資源的值。讓我們嘗試將應用程式擴展到 3 個副本，看看會發生什麼。 ![Tree Pod部署](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d3tx8a4bovw7evgx3iut.png) 您現在應該在 *Deployment* 選項卡中看到另外兩個 Pod；歡呼！ 🎉 當然，這適用於您可能想要對應用程式進行的任何其他更改。也許是服務？如果我們意識到我們不再需要它呢？嗯，有了 Cyclops，如果需要的話，很容易將其關閉。 再次點擊“編輯”按鈕，這一次，關閉服務切換。 ![服務關閉](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8f9wzg7bvzx4ta2fx6pg.png) Cyclops 不會自動刪除它，但會警告您（透過警告三角形標誌）您將其關閉，並且它不再起作用。這意味著您可以安全地刪除它！ 如果您厭倦了您的應用程式，您也可以刪除整個應用程式🗑️ 點擊刪除按鈕並填寫模組名稱以安全刪除它。您可以再次使用“kubectl”檢查它是否真的被刪除： ``` kubectl get pods ``` ## 結束 這就是它的全部內容！ Cyclops 讓對 Kubernetes 有不同了解的人可以利用它的力量。如果您遵循本教程，您應該已經使用 Cyclops 部署了您的第一個應用程式；恭喜！ 🎉 在我們的[網頁](https://cyclops-ui.com/)上，您可以找到另一篇教程，展示更多功能和更複雜的用例，以及我們的聯絡資訊和社群資訊。 如果您對如何讓 Cyclops 變得更好有任何回饋或想法，您可以填寫我們的簡短 [Google 表單](https://forms.gle/jrwcBHRtpwmK91v47)！ --- 原文出處：https://dev.to/cyclops-ui/kubernetes-made-simple-introducing-cyclops-44g0

0個讚   0留言 138瀏覽

每個開發人員必須了解的 10 個 Git 指令

了解 Git 和 GitHub 對於任何開發人員都至關重要，因為它們可以提供有效的版本控制和程式碼管理。熟練這些工具可以讓您脫穎而出並提高您的工作效率。在這篇文章中，我們將探索一組 Git 指令來啟動您的軟體開發之旅。 ## Git 詞彙 在深入研究這些命令之前，讓我們先熟悉一些 Git 術語。這種理解不僅可以幫助你更好地掌握 Git，還可以為你的整體理解打下基礎。 ### 儲存庫 儲存庫或儲存庫充當儲存空間，用於儲存專案的原始程式碼及其版本歷史記錄。 ### 工作目錄 工作目錄是您目前對專案進行更改的位置，其中存放您正在處理的文件。 ### staging 暫存充當儲存庫和工作目錄之間的中間區域。您可以在其中新增更改，然後將其提交到主儲存庫。 ### commit 提交是對階段提出的更改的快照，由唯一辨識碼（SHA-1 雜湊）標識並附有提交訊息。 ### 分支 分支代表儲存庫的並行版本，有助於獨立地處理不同的功能或錯誤修復。 ### 合併 合併涉及將建議的變更合併到主儲存庫中，通常用於將新功能整合到主專案中。 ### 拉 拉取是指從任何遠端儲存庫取得程式碼並將其合併到本機儲存庫（即工作目錄）。 ### 推 推送涉及將本機變更傳送到任何儲存庫的任何遠端分支。 ### 複製 克隆是建立主儲存庫的本機副本、建立有效拉取和推送連線的過程。 ### pull 取得會將變更從任何遠端儲存庫下載到本機儲存庫，而不直接將它們合併到本機儲存庫中。它對於在合併之前檢查更改很有用。 ### fork Forking 在您的 GitHub 帳戶上建立其他人儲存庫的個人副本，從而可以在不影響原始儲存庫的情況下進行變更。 ### 衝突 當兩個或多個分支在程式碼的同一部分發生變更時，就會出現衝突，而 Git 無法直接合併它們。 ### head 在 Git 中，HEAD 是指標/引用，始終指向目前分支中的最新提交。當您進行新的提交時，HEAD 會移動到提交的頂部。   現在，讓我們一一探討 10 個 Git 指令。 ![開始迷因](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s5zias7tsgsdjokp5g9p.gif) ## 1 - 一起新增和提交文件 傳統上，在 Git 中，我們使用「git add *」指令來暫存所有已修改的檔案以供後續提交。隨後，我們使用 git commit -m "commitMessage" 指令來提交這些變更。然而，存在一個更簡化的命令，只需一步即可完成這兩項任務： ``` git commit -am "commitMessage" ``` 「-am」標誌允許我們暫存這些變更並在一次有效的操作中提交它們。 ## 2 - 建立並切換到 Git 分支 與前面的場景類似，另一個命令組合了兩個命令的功能。不要使用單獨的命令，而是使用 `gitbranchbranchName` 建立分支並使用 `gitcheckoutbranchName` 切換到它。使用以下命令一步即可完成這兩項任務： ``` git checkout -b branchName ``` 帶有“git checkout”命令的“-b”標誌允許我們建立一個新分支並立即切換到它。 ## 3 - 刪除 Git 分支 若要刪除 Git 中的分支，請使用 `gitbranch-d` 或 `gitbranch-D` 指令。 “-d”選項用於安全刪除，僅刪除完全合併到目前分支的分支。 “-D”選項用於強制刪除，無論是否完全合併。以下是命令： 安全刪除（檢查合併）： ``` git branch -d branchName ``` 強制刪除（不檢查合併）： ``` git branch -D branchName ``` ## 4 - 重新命名 Git 分支 若要重新命名分支，請使用「gitbranch-m」指令，後面跟著目前分支名稱和新的所需分支名稱。例如，要將名為“oldBranch”的分支重新命名為“newBranch”，請執行： ``` git branch -m oldBranch newBranch ``` 如果您想要重新命名您正在工作的目前分支，而不指定舊名稱，請使用下列命令： ``` git branch -m newBranchName ``` 在這裡，您不需要指定舊的分支名稱，因為 Git 會假設您要將目前分支重新命名為新名稱。 ## 5 - 取消暫存特定文件 有時，您可能希望從暫存區域中刪除特定文件，以便在提交之前進行其他修改。使用： ``` git reset filename ``` 這將取消暫存該文件，同時保持變更不變。 ## 6 - 放棄對特定檔案的更改 若要完全放棄對特定文件所做的變更並將其恢復到上次提交的狀態，請使用： ``` git checkout -- filename ``` 此指令可確保檔案回到先前的狀態，撤銷最近的修改。這是一種在不影響其餘更改的情況下重新開始處理特定文件的有用方法。 ## 7 - 更新您的最後一次 Git 提交 想像一下，您剛剛在 Git 儲存庫中進行了一次提交，但隨後您意識到您忘記了在該提交中包含更改，或者您可能想修復提交訊息本身。您不想為這個小更改建立一個全新的提交。相反，您想將其加入到先前的提交中。您可以在此處使用命令： ``` git commit --amend -m 'message' ``` 此命令修改您最近所做的提交，將任何分階段的變更與您的新評論結合以建立更新的提交。 要記住的一件事是，如果您已經將提交推送到遠端儲存庫，則需要使用「git push --force」強制推送變更來更新遠端分支。標準的「git push」操作會將新的提交附加到遠端儲存庫，而不是修改最後的提交。 ## 8 - 隱藏更改 假設您正在處理兩個不同的分支A 和B。在分支A 中進行更改時，您的團隊要求您修復分支B 中的錯誤。當您嘗試使用「git checkout B」切換到分支B 時，Git 會阻止它，顯示錯誤： ![無法更改分支](https://miro.medium.com/v2/resize:fit:809/1*SAEI_fhVWNDX-3FKtQG3SQ.png) 我們可以按照錯誤訊息的建議提交更改。但承諾是 更像是固定的時間點，而不是正在進行的工作。這是我們可以應用錯誤訊息的第二個建議並使用隱藏功能的地方。使用此命令來儲存您的變更： ``` git stash ``` `git stash` 暫時儲存您尚未準備好提交的更改，讓您可以切換分支或處理其他任務，而無需提交不完整的工作。 若要重新套用分支中隱藏的更改，請使用“git stash apply”或“git stash pop”。這兩個命令都會恢復最新隱藏的變更。儲存應用程式只是恢復更改，而彈出則恢復更改並將其從儲存中刪除。您可以[在這裡](https://opensource.com/article/21/4/git-stash)閱讀有關隱藏的更多資訊。 ## 9 - 恢復 Git 提交 想像一下，您正在開發一個 Git 專案，並且發現某個特定的提交引入了一些不必要的更改。您需要撤銷這些變更而不從歷史記錄中刪除提交。使用以下命令撤銷該特定提交： ``` git revert commitHash ``` 這是糾正專案中的錯誤或不需要的更改的安全且非破壞性的方法。 例如，假設您有一系列提交： - 提交A - 提交 B（此處引入了不需要的更改） - 提交C - 提交 D 若要逆轉提交 B 的影響，請執行： ``` git revert commitHashOfB ``` Git 將建立一個新的提交，我們將其稱為提交 E，它將否定提交 B 引入的更改。提交 E 成為分支中的最新提交，並且該專案現在反映瞭如果提交 B 從未發生過時的狀態。 如果您想知道如何檢索提交哈希，使用“git reflog”很簡單。在下面的螢幕截圖中，突出顯示的部分代表您可以輕鬆複製的提交哈希： ## 10 - 重置 Git 提交 假設您已經承諾了您的專案。然而，經過檢查，您意識到您需要調整或完全撤銷上次提交。對於這樣的場景，Git 提供了這些強大的指令： ### 軟重置 ``` git reset --soft HEAD^ ``` 當您使用“git reset --soft HEAD^”時，您正在執行軟重置。此命令允許您回溯上次提交，同時保留暫存區域中的所有變更。簡而言之，您可以使用此命令輕鬆取消提交，同時保留程式碼變更。當您需要修改上次提交（也許需要在再次提交之前加入更多更改）時，它會很方便。 ### 混合重置 ``` git reset --mixed HEAD^ ``` 這是當您使用“git reset HEAD^”而不指定“--soft”或“--hard”時的預設行為。它取消最後一次提交並從暫存區域中刪除其變更。但是，它將這些變更保留在您的工作目錄中。當您想要取消提交最後一次提交並從頭開始進行更改，同時在重新提交之前將更改保留在工作目錄中時，這會很有幫助。 ### 硬重置 ``` git reset --hard HEAD^ ``` 現在，我們來談談「git reset --hard HEAD^」。它會完全刪除 Git 歷史記錄中的最後一次提交以及所有相關變更。當您使用“--hard”標誌時，就沒有回頭路了。因此，當您想永久放棄最後一次提交及其所有變更時，請務必謹慎使用此選項。 感謝您的閱讀。我希望這篇文章對您有所幫助，並且您學到了一些新命令。如果您還有任何疑問，請隨時與我們聯繫。請隨意分享您在日常生活中經常使用的任何 Git 命令，您會發現它非常方便。 :) 與我聯繫 [LinkedIn](https://www.linkedin.com/in/mukeshkuiry) [X（以前的 Twitter）](https://twitter.com/mukeshkuiry7) --- 原文出處：https://dev.to/mukeshkuiry/10-must-know-git-commands-for-software-engineers-3733

0個讚   0留言 150瀏覽

創作 RawJS 之後，我再也沒有碰過 React。

早在 2012 年 10 月，TypeScript 0.8 就發布了。當時我正在開發一個中型 JavaScript 專案。它發布的那天，我閱讀了最初的規範，在玩了大約 10 分鐘後，我確信這將是未來，因此我開始用 TypeScript 重寫我的整個應用程式。相對於標準無型別 JavaScript 的好處是巨大的。 我對 [RawJS](https://www.squaresapp.org/rawjs/) 也有同樣的感覺。 [RawJS 是一個小型函式庫](https://github.com/squaresapp/rawjs)，它使普通 JavaScript 應用程式開發更符合人體工學。它不僅僅是當今最新的 Web 框架，可以與 React、Vue、Svelte 或其他框架競爭。 RawJS 是不同的。 RawJS 直觀地說明了為什麼框架本身的整個前提可能有點誤導。它表明大多數應用程式最好使用普通 JS 並採用某些程式模式。 我知道這是一個非常大膽的聲明。但我懇請您研究一下 RawJS 誕生背後的心態和想法。 ## React 往往會破壞專案的複雜性 我不認為我說 React 太複雜是太過分了。畢竟，Svelte 正是因此而專門建立的。 React 會導致應用程式臃腫。舉個例子——我最近接到了一項任務，負責監督一個 React 應用程式的開發，該應用程式的複雜性已經失控。我最終扔掉了整個應用程式，並使用 RawJS 重建了整個應用程式，使用了一個從未接觸過 RawJS 的團隊，甚至根本沒有做過很多直接的 DOM 操作。幾週之內，團隊就加快了速度，現在該應用程式比以前的 React 應用程式小了約 90%。不，這不是一個錯字。 我們現在已經到了這樣一個階段：React 是「沒有人會因為購買 IBM 而被解僱」的選擇。問題是——人們「應該」因為購買 IBM 而被解僱。這是一個隱喻，指的是那些懶得做充分的需求分析、默認從眾心態、出於恐懼和懶惰而盲目跟隨大多數其他人正在使用的東西的人。 一旦您有幸使用 RawJS 加速的普通 JavaScript 開發應用程式，React 的過度複雜程度就會變得更加清晰。 RawJS 對 props、state、hooks、JSX、從特定基礎強制繼承（React.Component）、虛擬 DOM、自動資料綁定以及 React 所做的一切的必要性提出了質疑。 React 的膨脹及其施加的限制（例如禁止您直接編輯 DOM）都集中在試圖維護其虛擬 DOM 系統的完整性，我認為這是針對特定領域問題的解決方案對於facebook.com，那些精心建置的應用程式根本不具備。 所謂的直接 DOM 操作的效能劣勢被嚴重誇大了。事實上，如果做得正確，直接 DOM 操作通常會提高效能。這是因為您能夠精確控制 DOM 的更新方式。它允許您根據需要使用手術刀更新 DOM 的微小區域。虛擬 DOM 與此相反。它是一個生硬的工具，在大量 DOM 子樹上執行複雜的比較演算法，以便自動計算需要更新的內容。 自動資料綁定和反應性的有用性也被誇大了。假設您的程式碼組織良好，那麼建立您的應用程式以便 DOM 由於資料變更而更新似乎不會比僅建置應用程式以在必要時明確更新 DOM 所需的程式碼少。但與前者的區別在於，它給你強加了一個巨大的難以除錯的黑盒子，並迫使你遵守他們的官僚機構層。除非您組裝了一個精心建置的普通 JS 應用程式（例如使用 RawJS！），否則很難體會到擺脫這種情況的好處。 ## 為什麼沒有人談論匿名控制器類別？ 匿名控制器類別（ACC）是一種需要引起更多關注的模式。它們是將普通 JavaScript 應用程式從雜亂無章轉變為連貫且美觀的關鍵想法之一。 ACC 的基本前提是建立一個與 DOM 中單一元素鬆散連接的物件，並且其垃圾收集生命週期等於所連接元素的生命週期。這是對繼承 HTMLElement 的一個進步，HTMLElement 是另一種選擇（但我不喜歡這種選擇，原因我將在另一篇文章中討論）。 考慮以下程式碼： ``` class SomeComponent { readonly head; constructor() { this.head = document.createElement("div"); this.head.addEventListener("click', () => this.click()); // Probably do some other stuff to this.head } private handleClick() { alert("Clicked!") } } ``` ACC 是建立單一 .head 元素（可能還有其他巢狀元素）、連接事件偵聽器、分配樣式等的類別。它們具有通常是事件處理程序或其他輔助方法的方法。然後實例化該元件，並將元件的 .head 元素加入 DOM： ``` const component = new SomeComponent(); document.body.append(component.head); ``` 該類別被視為“匿名”，因為一旦元件實例附加到 DOM，您就可以丟棄該實例。一旦元素從 DOM 中刪除並被垃圾回收，該類別的實例就會被垃圾回收，因為 DOM 是唯一擁有對它的引用的東西。例如： ``` class SomeComponent { readonly head; constructor() { this.head = document.createElement("div"); this.head.addEventListener("click', () => this.remove()); // Probably do some other stuff to this.head } private remove() { // Remove the component's .head element from the DOM, // which will by extension garbage collect this instance of // SomeComponent. this.head.remove(); } } ``` ACC 的優點在於它們基本上不會施加任何限制。他們可以繼承任何東西（或什麼都不繼承）。它們只是一個想法——您可以將它們塑造成您喜歡的樣子。 當然，在許多情況下您可能想要取得與特定元素關聯的 ACC。例如，想像一下迭代 this.head 元素的祖先元素，並取得與其關聯的 ACC 以呼叫某些公共方法。有一個名為 [HatJS](https://github.com/squaresapp/hatjs) 的輕量級程式庫，旨在改善使用 ACC 的人體工學。 **編輯：我是 HatJS 的作者。 「匿名控制器類別」是我發明的一個術語。這是在實驗過程中出現的模式，儘管我懷疑我是第一個發現它的人，因為這個概念非常明顯。就像 JSON 之前有名字一樣。您不需要將 HatJS 與 RawJS 一起使用。許多人正在建立普通的JavaScript 應用程式（或者對於迂腐的人來說是「普通的TypeScript 應用程式」），並且僅僅透過建立繼承自HTMLElement 的自訂元素，有效地將元素和控制器合併到同一個實體中，就取得了巨大的成功。我已經用這種方法建置了一些應用程式，並認為 ACC 更好，原因我會在以後的文章中介紹。** ## 改進 document.createElement() 具有令人驚訝的強大影響 儘管本文試圖為直接使用 DOM API 提供最有力的案例，但這些 API 絕對失敗的一個領域是使用屬性、樣式和事件附件來建立複雜的 DOM 層次結構。 DOM API 的這一部分非常冗長，如果沒有一些外部幫助，您的程式碼將比所需的長度長約 10 倍。這就是 RawJS 的用武之地。 RawJS 的設計正是為了一個目的。它使 document.createElement() 的人體工學性能提高了 10 倍。呼叫函數並取得 HTMLElement 實例的層次結構。它沒有任何其他作用。沒有奇怪的背景魔法。您可能不認為這聽起來很有影響力。但你的評估是錯的。 事實證明，在過去 15 年圍繞框架模式的構思中，我們不需要虛擬 DOM、反應性、資料綁定預編譯器或任何其他野生科學專案。我們需要匿名控制器類別模式和更好的方法來建立 HTMLElement 實例。 使用這兩種技術，我可以肯定地說，我永遠不會再故意使用 React 或任何其他競爭框架。這類框架根本無法提供超出 JavaScript 已經可以完成的功能，無法保證它們所施加的巨大權重和官僚作風。 那麼 RawJS 程式碼是什麼樣的呢？對 RawJS 建立者函數的呼叫遵循以下形式： ``` const htmlElement = raw.div(...parameters); ``` 強大的人體工學來自於可接受的參數的廣度（在 RawJS 中輸入為“Raw.Param”）。 參數可以是字串、數字、布林值、陣列、函數、DOM 節點實例、對 `raw.on("event", ...)` 的呼叫（建立可移植事件附件）以及幾乎任何其他內容。 RawJS 總是做你所期望的。 我不會重申使用 RawJS 來建立層次結構可以做的很棒的事情。快速入門對此進行了詳細介紹。 主要想法是，因為幾乎任何東西都可以是 Raw.Param，所以您可以建立迷你函數庫來產生 Raw.Params 列表並返回它們。由此可實現的程式碼重用水準是前所未有的。再說一次，除非你真正使用過它，否則很難欣賞它。我討厭與 LISP / 閉包進行比較，但還是有相似之處。 ## 我見過的最好的 CSS-in-JS 解決方案 如果不建構對應的 CSS，HTML 元素層次結建置構器有什麼用呢？ RawJS 還擁有一流的 CSS-in-JS 解決方案，它可以完成我在任何其他解決方案中未見過的功能。例如，RawJS 完全支援僅限於特定元素的 CSS。 ``` const anchor = raw.a( // This constructs CSS within a global style sheet, // and the rules below will be scoped to the containing // anchor element. raw.css( ":focus", { outline: 0 }, ":visited": { color: "red" } ), raw.text("Hyperlink!") ); ``` 使用 RawJS 的 CSS-in-JS 解決方案還可以做很多其他事情。本文並不是 RawJS 教程，但如果您正在尋找此類內容，這裡有一個快速入門和一個演示應用程式。 ## 使用 DOM 作為狀態管理器實際上很好。 我們收到的一個常見的反對意見是，您將應用程式狀態儲存在哪裡？答案是使用 DOM 作為狀態管理器。 在你對此感到不寒而慄之前，請記住tailwind 如何率先提出在HTML 元素上刪除數百萬個類名的想法，有效地重新建立內聯CSS 的等價物，多年來，內聯CSS 一直被認為是一種反模式，但開發人員堅持它其實是很好，現在大家都在做嗎？同樣的想法也適用於使用 DOM 作為狀態管理器。 如今，每個人決定建立應用程式的方式都是從某種被視為「真相來源」的資料結構開始，然後您需要以某種方式將其笨拙地投影到 UI 中。以另一種方式做這件事被認為是“天真的”，甚至是反模式。但是，我想建議擁有兩個需要保持同步的獨立表示本身就是一種反模式。 嘗試使用某種框架以宣告方式將資料對應到 DOM 會導致複雜度大幅增加。這種技術的問題在於，對同一件事物有兩種不同的表示自然會比假設的只有一種這種表示的替代技術更加臃腫。 事實證明，如果您讓 ACC 接受輸入資料以便自行渲染，效果實際上會好得多。然後，您可以使用某種保存函數來檢查 DOM 的狀態以產生可保存的資料塊。這樣，您的事實來源不必與 DOM 同步，因為您的事實來源就是 DOM。 檢查以下程式碼範例： ``` class FormComponent { readonly head; private readonly firstNameInput; private readonly lastNameInput; constructor(firstName: string, lastName: string) { this.head = raw.form( this.firstNameInput = raw.input({ type: "text", value: firstName }), this.lastNameInput = raw.input({ type: "text", value: lastName }), raw.button( raw.text("Save"), raw.on("submit", () => this.save()) ) ); } private save() { const firstName = this.firstNameInput.value; const lastName = this.lastNameInput.value; SomeDatabaseSomewhere.save({ firstName, lastName }); alert("Saved!"); } } ``` 看？您只需將值儲存在 DOM 中即可。在本例中，我們使用文字輸入的值，但您也可以將資料儲存為 HTML 屬性、類別名稱或任何有意義的內容。 當然，在某些情況下，您需要儲存無法分解為字串、數字和布林值的狀態。我還看到一些狀態儲存在 ACC 內的屬性中的情況。做任何對你有用的事。 ## 元件之間的通信 在某些情況下，您可能需要更新多個元件以回應一項操作，或更簡單地在 ACC 之間發送訊息。 HatJS 可以幫助解決這個問題。 請記住，ACC 建立了一種隱藏的控制器層次結構。您擁有典型的 DOM 元素層次結構，但只有某些元素是 ACC 的頭元素。因此，這將建立自己的 ACC 層次結構，它是整個 DOM 元素層次結構的嚴格子集。 [HatJS](https://github.com/squaresapp/hatjs) 具有遍歷 ACC 層次結構的功能，並快速擷取可能位於或不位於元素後面的 ACC 實例。 ``` class ParentComponent { readonly head; constructor() { this.head = raw.div( new ChildComponent().head ); // Call Hat.wear() to define the object as a "hat" // and make it discoverable by HatJS Hat.wear(this); } callAlert() { alert("Hello!"); } } class ChildComponent { readonly head; constructor() { this.head = raw.div( raw.on("click", () => { // Hat.over finds the "Hat" (or the ACC) that exists // above the specified element in the hierarchy. // And passing ParentComponent gives you type-safe // tells HatJS what kind of component you're looking // for, and also gives you type-safe access to it. Hat.over(this, ParentComponent).callAlert() }) ); } } ``` 除了「Hat.over()」之外，還有「Hat.under()」、「Hat.nearest()」等方法來尋找 DOM 相對中可能存在或不存在的特定類型的其他 ACC到指定的元素。 ## 興奮起來！ 那麼，我是否說服您啟動您的 React 應用程式並使用 RawJS 來重建您一生的工作？如果您想開始使用，請造訪 [這裡是 RawJS 網站](https://www.squaresapp.org/rawjs/)。 RawJS 的儲存庫是[此處](https://github.com/squaresapp/rawjs)，HatJS 的儲存庫是[此處](https://github.com/squaresapp/hatjs) --- 原文出處：https://dev.to/paulgordon/after-using-rawjs-im-never-touching-react-again-or-any-framework-vanilla-javascript-is-the-future-3ac1

0個讚   0留言 153瀏覽

2024 年開源 Discord 計劃

大家好！ **祝大家新年快樂** 🥳 我的將會充滿壓力和樂趣。希望你的也是！ ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/8f714431-4254-4287-8634-c27c6308c1c2/ezgif.com-resize__43_.gif?t=1703587844) [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 中看到大量活動。 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/c84b9613-4209-49c4-a02e-345d1377aefa/image.png?t=1703588707) --- 2\.製造“非產品”Discord -------------------------------- 當您的 Discord 伺服器類似於「Novu」時，Discord 的訪客會有「這是 Novu 產品。讓我們來談談這個吧，」雖然大多數產品都是這樣做的，但你不必這樣做。 我們的 Discord 伺服器可以是「通知基礎架構」。現在，我們擴大了受眾範圍，為他們提供了一個了解有關通知的所有資訊的地方。 HackSquad 非常活躍，因為它是一個基於開發人員的伺服器，人們可以在其中談論任何事情。 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/00ff23cd-c6d1-4f34-b773-3fb6c2fb2aa1/image.png?t=1703588739) --- 3\.有意圖地加入 -------------------- 最近，我發現在我的通話期間透過我們的 Discord 伺服器進行推廣的人比自己加入的人要活躍得多。 我認為這是建立一個活躍社區的主要秘密 - 雖然你不能與每個人交談，但只有少數人已經相當不錯了，因為他們會很活躍並讓其他人參與其中。 **您可以執行的其他選項是：** * 在 Discord **「入門」** 嚮導中提供更多訊息，以便人們可以了解透過活躍可以得到什麼。 * 在 Discord 連結旁邊顯示一些內容或 YouTube 影片，以便人們可以了解伺服器的價值。 * 標記參加不同活動的人並徵求他們的意見。 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/74fbf3ff-2c78-4257-8af0-d02e6b2208e2/image.png?t=1703588859) 到目前為止，您喜歡這篇文章嗎？ 請務必註冊新聞通訊以閱讀下一篇新聞通訊 訂閱 \* 加入您的郵箱，獲得前1000星的影片將發送至您的郵箱 或邀請你的朋友學習【如何取得 GitHub stars】(https://howtogetgithubstars.com) --- 4\.保持 ---------- 讓人們加入您的 Discord 是「**獲取**」過程的一部分，但讓他們留下來是「**保留**」過程的一部分。 在 HackSquad 中，讓人們回到 Discord 會讓他們更加活躍。 **例如：** * 我不會製作網路研討會的 YouTube 直播或 Zoom 直播，而是製作 Discord 直播，然後透過電子報將人們帶回 Discord。 * 我舉辦的可重複活動超出了「如何使用 Novu」的範圍。我實際上會做更多通用的東西來吸引更多的人。 * 我舉辦 Discord 贈品活動，讓開發者回歸。 * 我經常在社群媒體上寫關於成為 Discord 的一部分的好處。 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/e23e84a2-b0a0-473d-af8e-b41a0c820e16/image.png?t=1703588895) --- 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)，他們幫助我發展社區並將其整合在一起。 當您給予模組**“力量”**時，它們會自動變得更加活躍 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/056b4451-19ac-4304-9bfa-59a82fa8e1f4/image.png?t=1703588936) --- 6\.建立入職管道 ------------------------------------------- 當有人加入你的 Discord 時，那將是他們最活躍、最積極的時候。 **你應該利用這個時間！** 在 Discord 上問他們一些問題，並讓他們參與一些對話並給予一些意見。 另外，**DM 他們**。雖然這與活躍在 Discord 上無關，但這是了解社群成員並從他們那裡提取一些資訊的絕佳時機： * 為什麼加入？ * 你在建造什麼？ * 誰告訴你我們的事了？ * 為什麼想從這個社區獲得？ 如果可以的話，甚至嘗試打一個 10 分鐘的電話。 事情是這樣的：你不是活躍的 **24/7**，但如果你有來自世界各地的模組 - 他們可以幫助你！ 只要確保不是所有的模組同時向同一個人發送私訊即可 - 這不太好 🙂 ![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/cc0d1401-d2ba-4943-bfda-39bac4f1be5f/image.png?t=1703588982) 最後一件事🤣 製造很多錯誤 - 這會讓人們陷入**（當然，我在開玩笑。）** --- ## 我邀請您註冊我的電子報。 若符合以下條件，本通訊對您有好處： - 您正在考慮開源您的產品（或建立新產品）。 - 您正在考慮開啟一個副產品並將其開源（以反映您的主要產品）。 - 您從事科技業，希望在沒有明星/沒有 GitHub 趨勢的情況下實現成長。 這是一份 100% 免費的時事通訊（並且永遠如此）。請隨時註冊： [https://gitroom.com](https://gitroom.com/) ![技術](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86ywkzncq6erg44d6xy9.gif) --- 原文出處：https://dev.to/github20k/the-discord-plan-for-open-source-in-2024-2596

0個讚   0留言 171瀏覽

React 終極閱讀清單：2024 年 15 篇必讀文章

React 是一個用於建立使用者介面的流行 JavaScript 函式庫，其生態系統不斷發展。為了幫助您隨時了解 React 及其生態系統的最新發展，我整理了 2024 年一些必讀文章的清單。這些文章涵蓋了廣泛的主題，從 React 最佳實踐到性能對 React 生態系統的優化等等。無論您是初學者還是經驗豐富的 React 開發人員，這些資源都可以幫助您更深入地了解 React 及其生態系統。名單如下：✨ --- ### 🚀 React 渲染互動指南 [🔗 連結](https://ui.dev/why-react-renders) 🔖 難度等級 - 中級 ![React 渲染互動指南](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8s1ij3v0nafviz529u51.png) 本文深入探討了 React 中渲染的概念，解釋了 React 何時以及如何更新視圖。它提供了一個簡單的心理模型來理解 React 的工作原理，並旨在澄清有關 React 渲染的常見誤解。 --- ### 🚀 新文件中的 React JS 最佳實踐 [🔗連結](https://sebastiancarlos.com/react-js-best-practices-from-the-new-docs-1c65570e785d) 🔖 難度等級 - 中級、專家 ![新文件中的 React JS 最佳實踐](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2rhkaq0wyzivzcttknn5.png) 本文介紹了基於新 React 文件的 React 開發最佳實務。它旨在按順序閱讀，涵蓋了 React 的各個方面，適合有經驗和中級的 React 開發人員。 --- ### 🚀 索引作為鍵是一種反模式 [🔗 連結](https://robinpokorny.medium.com/index-as-a-key-is-an-anti-pattern-e0349aece318) 🔖 難度等級 - 初級 本文討論了在 React 中使用索引作為鍵以及為什麼它是一種反模式。它解釋了使用索引作為鍵在更新或刪除清單中的專案時如何導致問題，並提供了為清單專案分配鍵的替代解決方案。 --- ### 🚀 治癒 React useState Hell 的方法？ [🔗連結](https://www.builder.io/blog/use-reducer) 🔖 難度等級 - 中級 ![React useState Hell 的治癒方法？](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2n42610mw5vqi2v9h27d.png) 本文討論了 React 中使用 useState 鉤子管理狀態的挑戰，並建議使用 useReducer 鉤子作為解決方案。它強調了 useState 在管理複雜狀態方面的局限性，並提供了使用 useReducer 來解決這些限制的範例。 --- ### 🚀 使用 React 設定 ESLint [🔗 連結](https://z1.digital/blog/eslint-guide-how-to-use-it-with-confidence) 🔖 難度等級 - 中級 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gng3ylrfo3avggbyum7i.png) 本文提供了有關在 React 中使用 ESLint 的全面指南，深入了解如何在 React 專案中有效地設定和使用 ESLint。它涵蓋了 React 開發中 ESLint 的最佳實踐和常見配置。 --- ### 🚀 React 18 中的自動批次：你應該知道什麼 [🔗連結](https://blog.bitsrc.io/automatic-batching-in-react-18-what-you-should-know-d50141dc096e) 🔖 難度等級 - 中級 本文介紹了 React 18 中自動批次的新功能，該功能預設批次從任何位置呼叫的狀態更新。它提供了一個簡單的範例來了解自動批次的工作原理以及它如何提高 React 應用程式的效能。本文的難度為中等。 --- ### 🚀 進階 React 元件組合指南 [🔗連結](https://frontendmastery.com/posts/advanced-react-component-composition-guide/) 🔖 難度等級 - 中級 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s60c8h3umt0ferz4a4e5.png) 本文是高階 React 元件組合的綜合指南，涵蓋了複雜 React 應用程式中組合元件和管理狀態的各種技術。它提供了建立可重複使用和可維護的 React 元件的實際範例和最佳實踐。本文的難度等級為中級到專家級。 --- ### 🚀 奇妙的閉包 [🔗 連結](https://www.developerway.com/posts/fantastic-closures) 🔖 難度等級 - 中級、專家 ![神奇的閉包](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rbc289miygudkmem99sa.png) 本文解釋了 JavaScript 中閉包的概念，以及如何在 React 中使用閉包來管理狀態和處理事件。它提供了使用閉包建立可重複使用元件的範例，並討論了在 React 中使用閉包的優點和缺點。 --- ### 🚀 帶有 tRPC 和 React 的全端 TypeScript [🔗連結](https://www.robinwieruch.de/react-trpc/) 🔖 難度等級 - 中級 ![使用 tRPC 和 React 的 TypeScript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/afg8iuxzz2forqkqv1xs.png) 本文提供了在 React/TypeScript 應用程式中實作 tRPC（用於建立 API 的 TypeScript 框架）的指南。它涵蓋了 tRPC 客戶端和伺服器相依性的安裝，並解釋了前端專案的具體實作。 --- ### 🚀 重新思考 React 最佳實踐 [🔗連結](https://frontendmastery.com/posts/rethinking-react-best-practices/) 🔖 難度等級 - 中級、專家 ![重新思考 React 最佳實踐](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dhfs0g00mffloojru15s.png) 本文討論了 React 最佳實踐的演變，特別是在 React 18 和 React Server Components (RSC) 的背景下。它探討了 React 的核心約束、過去的管理方法以及 Remix 和 Next.js 等 React 框架中不斷變化的思維模型。 --- ### 🚀 反應性能 [🔗連結](https://www.causal.app/blog/react-perf) 🔖 難度等級 - 中級、專家 ![反應表現](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w3n4c4enue5jkne7u5mc.png) 本文討論了提高 React 應用程式效能的各種技術，包括優化渲染、減小套件大小以及使用 React.memo 和 useMemo 掛鉤。它提供了提高 React 應用程式效能的實際範例和最佳實踐。 --- ### 🚀 下一張圖片的事實 [🔗 連結](https://dev.to/alex_barashkov/things-you-might-not-know-about-next-image-5go8) 🔖 難度等級 - 中級 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/56363g9jfn1pc1az0f77.png) 本文介紹了有關 Next.js Image 元件的各種見解和詳細訊息，涵蓋了開發人員可能不知道的方面。它提供了有關使用 Next.js Image 及其功能的實用訊息，對於使用 Next.js 的開發人員非常有用。 --- ### 🚀 建立聊天：使用 React、WebSockets 和 Web Push 的瀏覽器通知 [🔗連結](https://dev.to/novu/building-a-chat-browser-notifications-with-react-websockets-and-web-push-1h1j) 🔖 難度等級 - 中級 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a2tgb2z4agzxya64sw2q.png) 本文提供了使用 React、WebSockets 和 Web Push 建立帶有瀏覽器通知的聊天應用程式的綜合指南。它提供了對這些技術整合的深入見解，並提供了在 Web 應用程式中實現聊天和通知的實用方法。 --- ### 🚀 如何使用 React 和 OpenAI API 建置和部署 ChatGPT 克隆應用程式 [🔗連結](https://kinsta.com/blog/chatgpt-clone/) 🔖 難度等級 - 中級 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4ekfcw5i06qn5g3wls85.png) 本文提供了使用 React 和 OpenAI API 建置和部署 ChatGPT 克隆應用程式的逐步指南。它涵蓋了依賴項的安裝、建置前端以及將應用程式部署到 Kinsta 的應用程式託管平台。 --- ### 🚀 React 批評的歷史參考 [🔗連結](https://www.zachleat.com/web/react-criticism/) 🔖 難度等級 - 中級、專家 本文提供了對 React 的批評的歷史參考，涵蓋了開發人員和專家多年來提出的各種擔憂和批評。它探討了 React 的局限性和缺點，並提供了有關 React 作為框架的演變的見解。 --- 總而言之，精選的「2024 年關於 React 的 15 篇最佳文章」可以為渴望了解不斷變化的 React 開發格局的開發人員提供全面的指南。這些文章根據其相關性、深度和見解而精心挑選，提供了今年掌握 React 的路線圖。透過深入研究這些資源，開發人員可以保持在 React 生態系統的最前沿，利用建立尖端 Web 應用程式所需的知識和技能來增強自己的能力。 --- ## 關於我 嘿，我是 Dhruv Kothari 👋 一位全端 Web 開發人員和 UI/UX 愛好者，目前在 Upraised 擔任軟體工程師。我也是一名有競爭力的程式設計師、50 歲以下的立方愛好者、集郵家和錢幣學家。您可以透過 [GitHub](https://github.com/kothariji) 和 [Twitter](https://twitter.com/_kothariji) 與我聯繫 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/slfb7me1gnr43epsib99.png) --- 原文出處：https://dev.to/kothariji/the-ultimate-react-reading-list-top-15-must-read-articles-in-2024-2c3

0個讚   0留言 201瀏覽
歡迎發文
💡 記錄日常工作的實踐、心得
💡 發表對生活和職場的感悟
💡 針對感興趣的事件發表隨筆或者雜談
💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣
💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）
熱門文章
🔥 GitHub README 文件：響應式？ 🤔 動畫？ 🤯 淺色和深色模式？ 😱
🔥 网页文件加载失败如何重试
🔥 53 個專案創意（從初級到高級）
🔥 用於建立 AI/ML 應用程式的最佳開發工具！
🔥 為開源做出貢獻將使您獲得新工作的機會增加 10 倍 🚀
  近期留言
熱門搜尋： email COM 學習 工作 1 使用 c C 研 題 node.js . with 房 2 開發 前 ＣＳＳ 4 作為 第一 專案 10 JS ci % vs go 20 github id 前端 網站 作業 ui Ai git 技術 分享 50 html AI 測試 api 研究 語言 java 結構 資料庫 ` 工程師 app jav COMPO 系列 vue javascript 搜尋 後端 Java react 架構 HTML user React Line 非同步 cn CSS Can 練習 this 謝謝 聊天 CD 遊戲 rest prisma 作業分享 新創 for create 網頁 PHP .NET js Github 分離 promise Node 資料結構 GIT 主題 PYTHON ruby part ") console JAVA 套件
🛡️ 隱私及網站安全：本站註冊過程「不須提供任何個資」，只要 E-Mail 與帳密即可註冊，請安心註冊！線上付款過程使用「綠界科技 ECPay 」第三方專業金流廠商，全程在「綠界科技 ECPay 」網站進行付款程序，本站「不會紀錄任何信用卡資訊」，請放心付款、解鎖課程！您隨時可以透過 FB 粉專或者 Email 聯絡站長，請求刪除網站上的個人資料。