看更多文章： 1. [使用 gRPC 和微服務建立可擴展的通知系統](https://dev.to/suprsend/building-a-scalable-notification-service-with-grpc-and-microservices-l6d) 2. [在 React 網站中新增通知來源](https://dev.to/suprsend/adding-a-notification-feed-in-react-websites-4oa0) 4. [2023 年現代應用通知基礎設施完整指南](https://dev.to/suprsend/a-complete-guide-on-notification-infrastruct-for-modern-applications-in-2023-13b9) --- 應用程式通常可以分為兩種類型的效能瓶頸： 1. **I/O 限制：** 這些應用程式將大部分時間花在處理輸入和輸出上。 2. **CPU 限制：** 這些應用程式將大部分時間花在運算任務上。 現在，這些分類如何轉化為前端應用程式的上下文，特別是 React 應用程式？ **React 中的 I/O 效能挑戰** 當涉及到 React 應用程式時，經常會出現 I/O 效能方面的問題，主要與非同步 HTTP 呼叫相關。無效地管理這些網路請求可能會導致應用程式速度減慢。雖然這篇文章主要關注 CPU 效能，但有必要簡要介紹一下可以找到 I/O 限制問題解決方案的關鍵領域： - 盡可能實施延遲載入。 - 在初始載入資產和後端請求時請務必小心。 - 減少載入高度靜態元素的頻率（例如，選擇選項、配置）。 - 去抖特定請求的次數。 - 使用 Promise.all 等技術盡可能並行化請求。 - 透過優化資料庫存取等措施來提高關鍵後端端點的效率。 **React 中的 CPU 效能挑戰** 這篇文章的主旨是解決 React 中的 CPU 效能挑戰。在深入研究細節之前，讓我們先對效能建立一個具體的定義： - 瀏覽器應用程式主要作為單執行緒程式執行。 - 腳本任務，例如 JavaScript 執行、DOM 渲染和事件處理，都發生在同一個執行緒。 - 緩慢的 JavaScript 模組可能會阻塞主執行緒。 - 如果主執行緒被阻塞，使用者介面將變得無回應，導致每秒幀數 (fps) 下降。 - 響應式 UI 的目標是至少 30 fps，理想情況下達到 60 fps，這意味著每幀的計算時間應在 30 毫秒或更短的時間內。 在 React 的背景下，這個問題變得至關重要。當觸發 React 元件更新時，整個子樹必須在 30 毫秒內渲染完畢。對於複雜而冗長的元件結構（例如表、樹和列表），這變得尤其具有挑戰性，可能需要大規模重新渲染。 **反應渲染和提交階段** 從高層次來看，React 分為兩個不同的階段： **渲染階段：** - 當元件更新時啟動，由 props 或 hooks 的變更觸發。 - React 遍歷元件子樹，渲染每個子樹並計算虛擬 DOM (VDOM) 子樹。 - 只有受更新影響的「髒」子樹需要重新計算；更新元件的父元件可能不需要重新渲染。 - 此階段的效率與每個子元件的大小和計算成本成正比。 - React.memo 可用於提供更有效率渲染流程的提示。 **提交階段：** - 渲染階段產生整個 UI 的新虛擬 DOM。 - 在提交階段，React 將新樹與前一棵樹進行比較（VDOM 比較）。 - React 計算反映新 VDOM 樹所需的最小 DOM 突變。 - 套用 DOM 突變，更新 UI。 - 預設情況下，此階段本質上是高效的。 - 整個過程必須在 30 或 16 毫秒內完成（分別針對 30 fps 和 60 fps），UI 才會被視為回應。工作負載與應用程式的大小成正比。 後續探索將聚焦在提升Render階段的效率。在深入研究優化技術之前，了解如何測量和辨識應用程式中的緩慢元件至關重要。 **測量** 我經常依賴的工具包括： 1. **Chrome 開發工具的效能標籤** 2. **React Dev Tool 的效能標籤** **Chrome 開發工具的效能標籤** 該工具作為適用於任何瀏覽器應用程式的綜合資源而脫穎而出。它提供對每秒幀數的洞察、捕獲堆疊追蹤、辨識程式碼的慢速或熱點部分等等。主要使用者介面由火焰圖表示。 若要深入了解套用於 React 的 Chrome 效能選項卡，請參閱此[文件](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance)。 **React 開發工具的效能標籤** 若要利用此工具，您需要在瀏覽器中安裝 React Dev Tool 擴充功能。它專門針對 React 客製化了 Chrome 開發工具效能標籤中的資訊。透過火焰圖，您可以觀察不同的提交階段以及在對應渲染階段執行的 JavaScript 程式碼。 該工具有助於輕鬆確定： - 當元件進行重新渲染時。 - 哪些道具改變了。 - 哪些鉤子發生了變化，包括狀態、上下文等等。有關更多詳細訊息，請參閱[介紹性帖子](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html)。 **測量方法** 這是我在評估前端應用程式時更喜歡的方法： 1. **確定問題：** - 找出導致 UI 回應問題的頁面互動。 2. **建立一個假設：** - （可選）產生有關問題的潛在位置的想法。 3. **測量：** - 透過測量每秒幀數 (fps) 等基本指標來驗證問題。 4. **測量（第二部分）：** - 辨識有問題的程式碼部分； （可選）驗證您的假設。 5. **建立解決方案：** - 根據收集到的見解實施解決方案。 6. **測量解決方案：** - 透過檢查關鍵指標來驗證實施的解決方案是否解決或緩解了問題。 在沒有適當衡量的情況下進行最佳化會使努力實際上變得無效。雖然有些問題可能很明顯，但大多數問題都需要徹底的測量，從而構成性能增強過程的基石。 此外，測量可讓您向上傳達成果，向使用者、利害關係人和您的領導層通報應用程式特定領域內實現的效能改進（以百分比增益表示）。 **React 應用程式中 CPU 限制問題的通用解決方案** 現在有了測量結果並了解了問題領域，讓我們深入研究潛在的解決方案。優化 React 效能圍繞著改進渲染的元件和渲染的元件。 許多效能問題也源自於反模式。消除這些反模式（例如避免渲染方法中的內聯函數定義）有助於提高渲染時間。事實上，解決不良模式可以降低複雜性並同時提高效能。 **🤔 改進元件渲染** 辨識 React 應用程式中的緩慢元件通常指的是難以渲染或單一頁面上實例數量過多的特定元件。多種原因可能導致他們行動遲緩： - 元件內的阻塞計算。 - 渲染大型元件樹。 - 使用昂貴或低效率的函式庫。 大多數這些問題都歸結為提高元件渲染的速度。有時，關鍵元件不能依賴過於複雜的函式庫，需要回歸基本原則並實施更簡單的替代方案。 例如，我在複雜表格中每行的多個單元格中過度使用 Formik 時遇到了此類挑戰。雖然提高單一元件的效率還有很長的路要走，但注意力最終必須轉移到正在渲染的元件上。 **🧙 改進哪些元件渲染** 這方面提供了兩大類改進： 1. **虛擬化：** - 僅渲染視窗中可見的元件。例如，僅呈現使用者可以看到的表格行或清單專案。事實證明，這種方法對於複雜的 UI 是有益的，雖然可以在不解決「內容」步驟的情況下應用它，但建議這樣做。現代函式庫通常為虛擬化表和清單提供強大的支持，例如“react-virtualized”。虛擬化減少了 React 需要在給定幀中渲染的元件數量。 2. **道具優化：** - React 的目標是使元件類似於純函數，但可能會嘗試渲染不必要的次數。 **反應.備忘錄：** - React 中的大多陣列件都可以被記憶，確保使用相同的 props，元件返回相同的樹（儘管鉤子、狀態和上下文仍然受到尊重）。如果它們的 props 保持不變，則利用 `React.memo` 通知 React 跳過重新渲染這些已記憶的元件。 ``` import React from 'react'; const MyComponent = React.memo((props) => { // Component logic here }); export default MyComponent; ``` **假道具更改：useCallback：** - 解決虛假道具更改問題涉及道具內容保持不變但引用發生變化的情況。一個典型的例子是事件處理程序。 ``` import React, { useCallback } from 'react'; const MyComponent = () => { const onChange = useCallback((e) => console.log(e), []); return <input onChange={onChange} />; }; export default MyComponent; ``` **假道具更改：useMemo：** - 在將複雜資料結構作為 props 傳遞之前，在沒有適當記憶的情況下建立複雜的資料結構時，也會出現類似的挑戰。利用「useMemo」可確保僅在依賴項發生變更時才重新計算行，從而提高效率。 ``` import React, { useMemo } from 'react'; const MyComponent = ({ data, deps }) => { const rows = useMemo(() => data.filter(bySearchCriteria).sort(bySortOrder), [deps]); return <Table data={rows} />; }; export default MyComponent; ``` 雖然您可以靈活地自訂「React.memo」如何比較目前與先前的道具，但保持快速運算至關重要，因為它是渲染階段不可或缺的一部分。避免在每次渲染期間過於複雜的深度比較。 ## 現在看起來怎麼樣？ ### 道具已更改 它在 React 開發工具中的樣子：  他們真的嗎？它們是假的道具更改嗎？使用`useCallback`和`useMemo`。 ### 父渲染 它在 React 開發工具中的樣子：  使用“React.memo”來記住您的純元件。 ### 掛鉤已更改（狀態、上下文） 它在 React 開發工具中的樣子：  這裡沒有什麼太明顯的事情要做。嘗試驗證更改的鉤子是否有意義。也許一個糟糕的上下文提供者正在以與假道具更改可能出現的方式相同的方式偽造更改。 --- > 與此類似，我個人在 Slack 上經營著一個由開發人員主導的社群。我們在其中討論這些類型的實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議以及一切有助於開發人員保持理智的事情；）畢竟，太多的知識也可能是危險的。 > 我邀請您加入我們的免費社區，參與討論，並分享您的驚人經驗和專業知識。您可以填寫此表格，Slack 邀請將在幾天後收到您的電子郵件。我們擁有來自一些偉大公司（Atlassian、Scaler、Cisco、IBM 等）的出色人員，您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9) --- 您可能想要查看整合通知基礎架構的無縫方式。 https://github.com/suprsend/suprsend-go --- 原文出處：https://dev.to/nikl/react-is-slow-what-to-do-now-369g
## 介紹 在 Javascript 中，函數就是值（一等公民）。這意味著它們可以分配給變數和/或作為值傳遞。 ``` let random = function(){ return Math.random() } let giveMeRandom = random // assigning random to a variable ``` 這項知識使我們能夠用這種語言編寫函數式程式設計。在函數式程式設計中，我們大量使用高階函數。 ## 高階函數？ 高階函數是將其他函數作為參數*或*返回函數作為結果的函數。 以其他函數作為參數通常稱為“回調函數”，因為它是由高階函數回調的。這是 Javascript 常用的概念。 例如，陣列上的 *map* 函數是一個高階函數。 *map* 函數接受一個函數作為參數。 ``` const double = n => n * 2 [1, 2, 3, 4].map(double) // [ 2, 4, 6, 8 ] ``` 或者，使用匿名函數： ``` [1, 2, 3, 4].map(function(n){ return n * 2 }) // [ 2, 4, 6, 8 ] ``` *map* 函數是該語言內建的眾多高階函數之一。 *sort*、*reduce*、*filter*、*forEach* 是該語言內建的高階函數的其他範例。 高階函數可讓您編寫更簡單、更優雅的程式碼。讓我們看看如果沒有這樣的抽象，上面的程式碼會是什麼樣子。讓我們用循環取代 *map* 函數： ``` let array = [1, 2, 3, 4] let newArray = [] for(let i = 0; n < array.length; i++) { newArray[i] = array[i] * 2 } newArray // [ 2, 4, 6, 8 ] ``` ## 組合的力量 盡可能使用高階函數的一大優點是組合。 我們可以建立更小的函數，只處理一個邏輯。然後，我們透過使用不同的較小函數來組合更複雜的函數。 這種技術減少了錯誤並使我們的程式碼更易於閱讀和理解。 透過學習使用高階函數，您可以開始編寫更好的程式碼。 ## 例子 讓我們試著舉個例子。假設我們有一個教室的成績清單。我們的教室有 5 個女孩，5 個男孩，每個人的成績都在 0 到 20 之間。 ``` var grades = [ {name: 'John', grade: 8, sex: 'M'}, {name: 'Sarah', grade: 12, sex: 'F'}, {name: 'Bob', grade: 16, sex: 'M'}, {name: 'Johnny', grade: 2, sex: 'M'}, {name: 'Ethan', grade: 4, sex: 'M'}, {name: 'Paula', grade: 18, sex: 'F'}, {name: 'Donald', grade: 5, sex: 'M'}, {name: 'Jennifer', grade: 13, sex: 'F'}, {name: 'Courtney', grade: 15, sex: 'F'}, {name: 'Jane', grade: 9, sex: 'F'} ] ``` 我想了解一些關於此事的事情： - 該班的平均成績 - 男生的平均成績 - 女孩的平均成績 - 男孩中音調較高的 - 女孩中的最高調 我們將嘗試使用高階函數來獲得簡單易讀的程式。讓我們從編寫可以協同工作的簡單函數開始： ``` let isBoy = student => student.sex === 'M' let isGirl = student => student.sex === 'F' let getBoys = grades => ( grades.filter(isBoy) ) let getGirls = grades => ( grades.filter(isGirl) ) let average = grades => ( grades.reduce((acc, curr) => ( acc + curr.grade ), 0) / grades.length ) let maxGrade = grades => ( Math.max(...grades.map(student => student.grade)) ) let minGrade = grades => ( Math.min(...grades.map(student => student.grade)) ) ``` 我寫了7個函數，每個函數都有一份工作，而且只有一份工作。 *isBoy* 和 *isGirl* 負責檢查一名學生是男孩還是女孩。 *getBoys* 和 *getGirls* 負責將所有男孩或女孩帶出教室。 *maxGrade* 和 *minGrade* 負責取得某些資料中的最高和最低等級。 最後，*average*負責計算一些資料的平均等級。 請注意，*average* 函數還不知道它要處理的資料類型。這就是構圖之美。我們可以在不同的地方重複使用我們的程式碼。我可以將此功能與其他功能一起使用。 現在，我們已經有了編寫高階函數所需的東西： ``` let classroomAverage = average(grades) // 10.2 let boysAverage = average(getBoys(grades)) // 7 let girlsAverage = average(getGirls(grades)) // 13.4 let highestGrade = maxGrade(grades) // 18 let lowestGrade = minGrade(grades) // 2 let highestBoysGrade = maxGrade(getBoys(grades)) // 16 let lowestBoysGrade = minGrade(getBoys(grades)) // 2 let highestGirlsGrade = maxGrade(getGirls(grades)) // 18 let lowestGirlsGrade = minGrade(getGirls(grades)) // 9 ``` 請注意，外部函數（例如*average*）始終將內部函數的輸出作為輸入。因此，組合的唯一條件是確保輸出和輸入匹配。 而且因為每個函數只負責一件事，所以它使我們的程式碼更容易除錯和測試。 --- 原文出處：https://dev.to/damcosset/higher-order-functions-in-javascript-4j8b
Docker 是一個工具，允許開發人員將他們的應用程式及其所有依賴項打包到一個容器中。然後，這個容器就可以輕鬆地在任何安裝了 Docker 的機器上傳輸和執行，而不必擔心環境的差異。這就像是打包和執行軟體的標準化方式。 **容器是什麼？**  容器就像一個小包，其中包含程式執行所需的一切，可以輕鬆地在不同電腦上移動和執行，而不會造成任何麻煩。 最酷的部分是這個迷你電腦（容器）就像一個披著斗篷的超級英雄。它可以在任何電腦上執行，無論它們有多麼不同，因為它自帶特殊的環境。這是一種保持軟體井然有序的方式，並確保它無論在哪裡都能以相同的方式運作。  **為什麼我們需要 Docker？** 1. **一致性：** Docker 確保軟體在您的電腦、您朋友的電腦或任何電腦上以相同的方式運作。它使事情保持一致。 2. **可移植性：** 您可以將您的軟體及其朋友打包到 Docker 容器中，並且它可以移動到任何地方。這就像將您的遊戲及其所有規則放在手提箱中並在朋友家中玩。 3. **隔離：** Docker 容器就像小氣泡。氣泡內發生的事只會留在氣泡內。這意味著容器中的一個程式不會幹擾容器外的另一個程式。 4. **效率：** Docker有助於節省電腦資源。您可以讓許多容器在同一台電腦上執行，而不會相互妨礙，而不是讓一整台電腦只用於一個程式。 5. **速度：** Docker 讓啟動、停止和共享軟體變得快速、輕鬆。這就像打開和關閉遊戲機一樣 - 快速而簡單。 **什麼是 Docker 映像？**  Docker 映像像是程式及其運作所需的所有內容的快照。它是一個打包版本，包括程式碼、工具和設置，就像包含所有成分的餅乾食譜的快照一樣。 **圖像是配方，容器是當您按照該配方實際製作和執行程序時所得到的。** **一些基本的 Docker 命令。**  1. **`docker執行nginx`** - 此命令告訴 Docker 使用「nginx」映像執行容器。這就像告訴 Docker 啟動一個預製程式的新實例（nginx，它是一個 Web 伺服器）。 2. **`docker ps`** - 顯示正在執行的容器的清單。這就像檢查當前正在執行哪些程式。 3. **`docker ps -a`** - 顯示所有容器的列表，包括已停止的容器。這就像檢查您執行過的所有程式的歷史記錄。 4. **`docker stopsilly_sammet'** - 停止名為「silly_sammet」的正在運作的容器。這就像關閉當前正在執行的程式。 5. **`docker rmsilly_sammet'** - 刪除名為「silly_sammet」的已停止容器。這就像丟掉你不再需要的程式的指令一樣。 6. **`docker 映像`** - 列出您擁有的所有 Docker 映像。這就像查看您可以執行的所有不同程式的選單一樣。 7. **`docker rmi nginx`** - 刪除“nginx”圖像。這就像刪除您不想再使用的程式的配方。 8. **`docker拉nginx`** - 從網路下載「nginx」映像。這就像從食譜中獲取新食譜一樣。 9. **`docker 執行 ubuntu sleep 5`** - 使用「ubuntu」映像檔執行容器並使其休眠 5 秒。這就像啟動一個程序，只是等待一小會兒，然後就停止了。 10. **`docker exectracted_mcclintock cat /etc/hosts`** - 在名為「distracted_mcclintock」的正在執行的容器內執行命令。這就像在食譜書中偷看特定頁面一樣。 11. **`docker run -d kodekloud/simple-webapp`** - 從「kodekloud/simple-webapp」鏡像以分離模式執行容器。這就像啟動一個程式並讓它在背景執行。 12. **`docker Attach a043d`** - 將您的終端附加到 ID 為「a043d」的正在執行的容器。這就像跳入正在執行的程式來查看發生了什麼。 **一些 Docker 概念：** 1. **使用標籤執行：** - 標籤就像程式的版本。它指定您要執行哪個版本。 - 範例程式碼：`docker run nginx:latest` - 這將執行最新版本的 Nginx 程式。 2. **使用標準輸入執行：** - STDIN 就像在鍵盤上打字一樣。有些程式需要您的輸入。 - 範例程式碼：`docker run -i -t ubuntu` - 這會在 Ubuntu 容器內執行互動終端，讓您可以鍵入命令。 3. **使用連接埠映射執行：** - 連接埠就像門。程式使用它們與外界進行通訊。 - 範例程式碼：`docker run -p 8080:80 nginx` - 這將執行 Nginx，並打開電腦連接埠 8080 上的門，將其連接到容器的連接埠 80。 4. **使用磁碟區映射執行：** - 磁碟區就像共用資料夾。它們讓您可以將東西存放在容器之外。 - 範例程式碼：`docker run -v /your/local/folder:/container/folder nginx` - 這將執行 Nginx 並將電腦上的資料夾連接到容器內的資料夾。 5. **檢查容器：** - 檢查就像仔細檢查正在執行的程式。 - 範例程式碼：`docker檢查container_name` - 這為您提供有關正在執行或已停止的容器的詳細資訊。 6. **容器日誌：** - 日誌就像日記。他們記錄程式正在做什麼。 - 範例程式碼：“docker 日誌容器名稱” - 這會向您顯示特定容器的日誌或活動。 ##環境變數 環境變數就像程式用來尋找重要資訊的便利筆記，有點像是程式可以理解和更好工作的秘密訊息！ 1. **Python腳本（app.py）中的環境變數：** - 假設您有一個用 Python 寫的程式 (app.py)。您可能想要在不更改程式碼的情況下自訂它。您可以使用環境變數。 - 範例程式碼（app.py）： ``` import os app_color = os.getenv("APP_COLOR", "default_color") print(f"The app color is {app_color}") ``` - 正常運作腳本：`python app.py` - 以特定顏色執行：`export APP_COLOR=blue; python 應用程式.py` 2. **在 Docker 中使用 ENV 變數：** - Docker 容器也可以使用環境變數。這就像是向容器內的程式發出指令。 - 範例程式碼： - `docker run -e APP_COLOR=green simple-webapp-color` - 這會執行 Docker 容器（`simple-webapp-color`）並將環境變數 `APP_COLOR` 設為「綠色」。 3. **檢查環境變數：** - 有時，您會想要檢查正在執行的容器正在使用哪些環境變數。 - 範例程式碼：`docker檢查blissful_hopper` - 此命令提供有關名為“blissful_hopper”的容器的詳細訊息，包括其環境變數。 簡單來說，環境變數就像程式（或 Docker 容器）可以讀取以了解如何行為的小註釋。您可以在執行程式之前設定這些註釋，程式將使用它們來自訂自身。第二個範例中的「export」指令就像在執行程式之前寫一條註釋，告訴它如何運作。 “docker Inspect”指令就像是在容器內部查看它有什麼註解。 ## Docker 映像 **Docker 檔案：** Dockerfile 就像是 Docker 建立映像的一組指令。這就像是烤蛋糕的食譜。 ``` # Use the Ubuntu base image FROM Ubuntu # Update apt repository RUN apt-get update # Install dependencies using apt RUN apt-get install -y python # Install Python dependencies using pip RUN pip install flask RUN pip install flask-mysql # Copy source code to /opt folder COPY . /opt/source-code # Set the working directory WORKDIR /opt/source-code # Specify entry point to run the web server ENTRYPOINT ["flask", "run"] ``` **建立自己的圖像的步驟：** 1. 使用上述內容建立一個名為「Dockerfile」的檔案。 2. 將其保存在與原始碼相同的目錄中。 **建置 Docker 映像：** 在終端機中執行以下命令： ``` docker build -t your-image-name . ``` 此命令告訴 Docker 使用目前目錄中的 Dockerfile (`.`) 建置映像，並使用您選擇的名稱對其進行標記 (`-t your-image-name`)。 **分層架構：**  - 將 Docker 映像視為一個分層蛋糕。 Dockerfile 中的每個指令都會在映像上新增一層。 - 圖層可重複使用。如果您變更程式碼中的某些內容，Docker 只會重建受影響的層，從而提高效率。 **Docker 建置輸出：** - 當您建置映像檔時，Docker 會顯示流程中的每個步驟。如果發生故障，它會給您錯誤訊息。 **你可以容器化什麼？** - 幾乎所有東西！應用程式、服務、資料庫、網站，基本上任何軟體都可以容器化。 - 這就像將您的軟體放入一個盒子中，以便它可以在任何地方執行而不會造成麻煩。 ## 什麼是 Docker CMD 與 ENTRYPOINT **Docker 中的`CMD`：** - 將 CMD 視為啟動容器時程式執行的預設操作。 - 這就像說，“嘿，當你執行這個容器時，默認執行此操作。” - 範例：`CMD ["flask", "run"]` 表示當容器啟動時，它會自動執行 Flask Web 伺服器。 **CMD 範例：** ``` FROM alpine CMD ["sleep", "5"] ``` 在此範例中，當您使用此映像執行容器時，它會自動休眠 5 秒。 **Docker 中的`ENTRYPOINT`：** - 將 ENTRYPOINT 視為容器所做的主要事情。就好像boss的命令一樣。 - 它設定一個預設應用程式在容器啟動時執行，但您仍然可以根據需要覆蓋它。 - 範例：`ENTRYPOINT ["flask", "run"]` 表示容器主要用於執行 Flask Web 伺服器，但如果需要，您仍可新增更多指令。 **入口點範例：** ``` FROM alpine ENTRYPOINT ["sleep"] CMD ["5"] ``` 在這裡，主要目的是睡眠，如果您願意，您仍然可以覆蓋睡眠持續時間。 在這兩種情況下，容器在啟動時只會休眠幾秒鐘。主要區別在於如何提供參數以及它們是否可以輕鬆覆蓋。 CMD 就像在說，“這是默認要做的事情”，而 ENTRYPOINT 就像在說，“這是主要要做的事情，但如果你願意，你可以稍微調整一下。”它們都有助於定義容器啟動時執行的操作。 ## Docker 中的網路： Docker 網路幫助容器（程式）相互通信，確保它們可以順利地協同工作。 **預設網路：** - Docker 建立預設網路供容器通訊。 - 範例程式碼：`docker run ubuntu --network=host` - 這使用主機網路執行 Ubuntu 容器，這意味著它與主機共享網路命名空間。 **使用者定義的網路：** - 您可以建立自己的網路以更好地組織和控制。 - 範例程式碼： ``` docker network create --driver=bridge --subnet=182.18.0.0/16 custom-isolated-network ``` - 這將建立一個名為「custom-isolated-network」的使用者定義的橋接網絡，具有特定的子網。 **上市網路：** - 您可以查看您擁有的所有網路。 - 範例程式碼：`docker network ls` **檢查網路：** - 您可以檢查特定網路的詳細資訊。 - 範例程式碼：`docker網路檢查blissful_hopper` - 這顯示有關名為「blissful_hopper」的網路的詳細資訊。 **嵌入式 DNS：** - Docker 有一個內建的 DNS 系統，供容器透過名稱相互查找。 - 範例程式碼：`mysql.connect(mysql)` - 這可能是程式碼中的一行，其中名為「mysql」的服務使用 Docker 的 DNS 連接到另一個名為「mysql」的服務。 ## Docker 儲存：  Docker 儲存就像使用容器時決定將資料保存在哪裡一樣。您可以將它們保留在容器內，使用磁碟區在容器之間共用它們，或將它們儲存在容器外部以妥善保管。 **Docker中的檔案系統：** - Docker 使用分層架構來建立映像。 Dockerfile 中的每個指令都會在檔案系統中新增一個新圖層。 ``` # Dockerfile FROM Ubuntu RUN apt-get update && apt-get install -y python RUN pip install flask flask-mysql COPY . /opt/source-code WORKDIR /opt/source-code ENTRYPOINT ["flask", "run"] ``` - Dockerfile 中的層： - 第 1 層：Ubuntu 基礎層 - 第 2 層：apt 軟體包的更改 - 第 3 層：pip 套件的變化 - 第 4 層：原始碼 - 第 5 層：使用「flask」指令更新入口點 - 第 6 層：容器層 **影像圖層：** - 當您建立 Docker 映像時，它由唯讀層組成。每一層代表影像的變化或加入。 - 第 1 層：Ubuntu 基礎層 - 第 2 層：apt 軟體包的更改 - 第 3 層：pip 套件的變化 - 第 4 層：原始碼 - 第 5 層：使用「flask」指令更新入口點 ``` # Build the Docker image docker build -t mmumshad/my-custom-app . ``` **容器層：** - 當您執行 Docker 容器時，會在唯讀映像層上方新增一個讀寫層。該層特定於正在執行的容器。 - 第 6 層. 容器層 ``` # Run the Docker container docker run mmumshad/my-custom-app ``` **數量：** - 卷是一種在容器外部保存資料的方法。它們就像外部記憶體。 ``` # Create a Docker volume docker volume create data_volume # Use the volume in a container docker run -v data_volume:/var/mysql mysql ``` - 您也可以使用「-v」將特定目錄從主機掛載到容器： ``` # Mount a host directory to a container directory docker run -v /path/on/host:/var/mysql/mysql -d mysql ``` - docker run --mount 指令用於將主機上的特定目錄或檔案掛載到正在執行的 Docker 容器中。 ``` docker run --mount type=bind,source=/mysql,target=/var/mysql mysql ``` **儲存驅動程式：** - Docker 使用儲存驅動程式來管理資料的儲存和存取方式。一些常見的儲存驅動程式包括 AUFS、ZFS、BTRFS、Device Mapper、Overlay 和 Overlay2。 [在 Docker 管理資料](https://docs.docker.com/storage/) [關於儲存驅動程式](https://docs.docker.com/storage/storagedriver/) [卷](https://docs.docker.com/storage/volumes/) ## Docker 組合  Docker Compose 是一個方便的工具，可幫助您輕鬆執行和連接不同的軟體服務，就好像它們都是同一事件的一部分一樣。 **Docker Compose 基礎：** 1. **執行單一容器：** - 通常，您可以像這樣執行單獨的 Docker 容器： ``` docker run mmumshad/simple-webapp docker run mongodb docker run redis:alpine docker run ansible ``` 2. **Docker 撰寫文件（`docker-compose.yml`）：** - Docker Compose 允許您在一個簡單的檔案中定義所有這些服務： ``` # docker-compose.yml version: '3' services: web: image: 'mmumshad/simple-webapp' database: image: 'mongodb' messaging: image: 'redis:alpine' orchestration: image: 'ansible' ``` - 此檔案描述您要執行的服務（「web」、「database」、「messaging」、「orchestration」）、它們各自的映像以及任何其他配置。 3. **使用 Docker Compose 執行：** - 要一起啟動所有這些服務： ``` docker-compose up ``` - Docker Compose 負責啟動「docker-compose.yml」檔案中定義的所有容器。 4. **使用 Docker Compose 建置：** - 您也可以使用 Docker Compose 建置映像： ``` docker-compose build ``` - 此指令建置「docker-compose.yml」檔案中指定的映像。 **執行連結容器：** - 如果您要透過連結執行單一容器： ``` docker run -d --name redis redis docker run --name voting-app -p 5000:80 --link redis:redis voting-app docker run --name result-app -p 5001:80 --link db:db result-app docker run -d --name worker --link db:db --link redis:redis worker ``` - 在 Docker 中撰寫： ``` # docker-compose.yml version: '3' services: vote: image: 'voting-app' ports: - '5000:80' links: - 'redis:redis' result: image: 'result-app' ports: - '5001:80' links: - 'db:db' worker: image: 'worker' links: - 'db:db' - 'redis:redis' db: image: 'db' redis: image: 'redis' ``` Docker Compose 可讓您在單一檔案中描述整個應用程式堆疊，從而輕鬆管理、執行和連接不同的服務。這就像在一份計劃中寫下活動的所有任務，然後 Docker Compose 為您處理設定。 [Docker Compose 概述](https://docs.docker.com/compose/) [Docker 撰寫文件](https://docs.docker.com/engine/reference/commandline/compose/) ## Docker 註冊表  Docker 註冊表是人們儲存和分享 Docker 映像的地方，使其他人可以輕鬆使用和執行他們的軟體。它就像一個大型線上程式庫，可以輕鬆下載並在不同電腦上使用。 **Docker 註冊表基礎知識：** 1. **公共登記處：** - Docker 映像可以在 Docker Hub 等公共註冊表中儲存和共用。 - 例： ``` docker pull nginx ``` 2. **私人登記處：** - 有時，您可能希望將圖像保存在您自己的私人註冊表中。 - 例： - 登入私人註冊表： ``` bash docker login private-registry.io ``` - 從私有註冊表中的映像執行容器： ``` docker run private-registry.io/apps/internal-app ``` 3. **部署您自己的私有註冊表：** - 您可以為您的團隊或公司部署自己的私人註冊表。 - 例： - 在您的電腦上執行私有註冊表： ``` docker run -d -p 5000:5000 --name registry registry:2 ``` - 為私人註冊表標記您的圖像： ``` bash docker image tag my-image localhost:5000/my-image ``` - 將映像推送到您的私人註冊表： ``` bash docker push localhost:5000/my-image ``` - 從您的私人註冊表中提取映像： ``` bash docker pull localhost:5000/my-image ``` 4. **從遠端私有註冊表中提取：** - 您也可以使用 IP 位址或網域從遠端私有註冊表中提取映像。 - 例： ``` docker pull 192.168.56.100:5000/my-image ``` Docker 註冊表就像一個儲存空間，人們在其中保存和共享 Docker 映像。您可以將公用註冊表用於廣泛使用的映像，也可以根據您的特定需求設定自己的私人註冊表。它就像一個用於共享和儲存軟體藍圖（圖像）的特殊庫。 ## Docker 引擎  想像一下，你有一個魔盒（Docker Engine），可以為你執行和管理各種程式（容器）。 Docker Engine 就像是這個魔盒的大腦。 1. **Docker 守護程式：** - 守護程式就像魔法盒的看門人。它始終在那裡，隨時準備接受指示並確保一切順利進行。 2. **REST API：** - 將 REST API 視為一組允許您與魔盒對話的規則。它就像你和守護程式用來溝通的語言。你告訴守護程式要做什麼，它會理解，因為你們說的是同一種語言。 3. **Docker CLI（命令列介面）：** - Docker CLI 就像是用來命令守護程式的魔杖。您輸入指令，守護程式就會按照您的指示進行操作。這就像說「Abracadabra」就能讓事情發生。 **連線到遠端 Docker 引擎：** 連接到遠端 Docker 引擎可讓您控制另一台機器上的容器，且設定約束可確保容器僅使用指定的資源。 1. **Docker主機IP：** - 您可以使用 IP 位址和連接埠連接到不同電腦上的 Docker 引擎。 - 例： ``` docker -H=remote-docker-engine:2375 run nginx ``` - 這告訴您的本機 Docker CLI 與遠端 Docker 引擎進行通訊。 2. **有約束地執行容器：** - Docker 允許您設定容器的資源限制，例如 CPU 和記憶體限制。 - 例： ``` docker run --cpus=0.5 ubuntu docker run --memory=100m ubuntu ``` - 這些指令限制容器僅使用半個 CPU 核心和 100 MB 記憶體。 當然，讓我們簡化一下PID命名空間的概念： **命名空間PID：** PID 命名空間可讓您為容器中的進程（如程式或任務）建立單獨的區域，因此它們有自己的一組「票號」（進程 ID），不會與容器外的進程發生衝突。 **範例程式碼：** 1. **使用主機 PID 命名空間執行容器：** - 這表示容器與主機共用相同的「票號」。 ``` docker run --pid=host ubuntu ``` 2. **執行具有隔離 PID 命名空間的容器：** - 這表示容器有自己的一組獨立於主機的「票號」。 ``` docker run --pid=container ubuntu ``` 在第一個範例中，容器與進程交互，就好像它與主機位於同一空間中一樣。在第二個範例中，容器有自己的進程隔離空間。這就像在大型活動中擁有一個私人區域，您的團隊有自己的一套票號，讓您可以獨立於活動的其餘部分進行操作。 **容器化概念：** 1. **進程 ID 命名空間：** - 容器有自己獨立的流程 ID (PID) 空間，因此容器內的流程與容器外的流程是分開的。 - 例： ``` docker run --pid=host ubuntu ``` - 此指令使用主機的 PID 命名空間來執行容器，因此它共用相同的程序。 2. **網路命名空間：** - 容器也有自己獨立的網路命名空間，這意味著它們可以有自己的網路配置。 - 例： ``` docker run --net=host nginx ``` - 此指令使用主機的網路命名空間來執行容器。 3. **Unix分時命名空間：** - 此命名空間允許容器擁有自己的時間視圖，與主機和其他容器分開。 - 例： ``` docker run --uts=host ubuntu ``` - 此指令使用主機的 Unix 時間共用命名空間來執行容器。 4. **進程間掛載命名空間：** - Mount命名空間隔離檔案系統，讓容器擁有自己的檔案系統視圖。 - 例： ``` docker run --mount=type=bind,source=/host/folder,target=/container/folder ubuntu ``` - 此指令將主機中的資料夾安裝到容器中。 當然！我們來簡化一下cgroup的概念： **C組：** cgroup（控制組的縮寫）可協助在不同進程或容器之間管理和分配系統資源，例如 CPU 和記憶體。它們確保沒有任何一個進程或容器耗盡所有可用資源，從而保持一切平衡。 **範例程式碼：** 1. **使用 Cgroup 設定 CPU 限制：** - 這就像說聚會上的每位客人只能吃一定數量的食物。 ``` docker run --cpus=0.5 ubuntu ``` - 這限制容器僅使用一半的 CPU 核心。 2. **使用 Cgroup 設定記憶體限制：** - 這就像說每位客人只能在舞池上佔據一定的空間。 ``` docker run --memory=100m ubuntu ``` - 這限制容器僅使用 100 MB 記憶體。 [Docker 引擎概述](https://docs.docker.com/engine/) [使用 Docker Engine API 進行開發](https://docs.docker.com/engine/api/) [執行時指標](https://docs.docker.com/config/containers/runmetrics/#control-groups) ## Linux容器與Windows容器的概念： **Linux 容器（預設）：** Linux 容器是一種打包和執行軟體及其所需一切的方法，它們最適合執行 Linux 的電腦。 **Windows 容器：** Windows 容器是一種打包和執行軟體的方式，就像 Linux 容器一樣，但它們設計用於執行 Windows 的電腦。 **Windows 容器基礎：** 1. **集裝箱類型：** - Windows 容器有兩種主要類型：Windows Server Core 和 Nano Server。 - **Windows Server Core：** 將其視為功能更齊全的容器，適合各種應用程式。 - **Nano Server：** 將其視為一個輕量級容器，專為特定的、簡約的用例而設計。 2. **基礎鏡像：** - 基礎映像就像是建立容器時開始使用的空白畫布。 - 例： ``` docker pull mcr.microsoft.com/windows/servercore:ltsc2019 ``` - 此指令擷取 Windows Server Core 基礎映像。 - 例： ``` docker pull mcr.microsoft.com/windows/nanoserver:ltsc2019 ``` - 此命令提取 Nano Server 基礎映像。 3. **支援的環境：** - Windows 容器可以在特定版本的 Windows 作業系統上運作。 - 例： - 您可以在 Windows Server 2016 上執行 Windows 容器。 - 例： - 您可以在 Windows 10 專業版和企業版上執行 Windows 容器，並使用 Hyper-V 隔離容器進行額外隔離。 ## 容器編排  容器編排是一種管理和協調多個容器的方法，確保它們無縫協作來執行應用程式，就像一個超級智能的管理器確保所有機器人一起工作來建置完美的塔一樣。 **為什麼要編曲？** 1. **多項任務，一名經理：** - 想像一下您有許多機器人（容器）執行不同的工作。編排就像有一位超級聰明的經理（編排者），他告訴每個機器人該做什麼，並確保一切順利進行。 2. **一致性：** - 編排確保所有任務每次都以相同的方式完成。這就像為您的機器人提供了一套要遵循的指令，以確保其行為的一致性。 3. **效率：** - 編排有助於優化任務，確保資源（如時間和材料）有效利用。這就像經理確保所有機器人一起工作而不浪費能源。 4. **縮放比例：** - 當您需要完成更多工作時，編排可以輕鬆建立額外的機器人（容器）。這就像當有很多事情需要完成時神奇地召喚更多機器人來提供幫助。 5. **可靠性：** - 編排確保任務可靠地完成，即使機器人（容器）出現故障。這就像製定備份計劃來確保無論如何都能完成工作。 6. **協調：** - 編排協調任務，確保機器人無縫協作。這就像經理確保每個機器人都知道自己的角色並協作以實現總體目標。 **容器編排程式碼：** ``` # Create a Docker service with 100 replicas (instances) of a Node.js application docker service create --replicas 100 --name my-nodejs-app nodejs ``` 在這個例子中： - `docker service create`：該指令告訴 Docker 建立一個服務，該服務是一組正在執行的容器。 - `--replicas 100`：此標誌指定您需要 100 個服務實例（副本）。 - `--name my-nodejs-app`：此標誌為您的服務提供名稱，在本例中為「my-nodejs-app」。 - `nodejs`：這是 Node.js 應用程式的圖片或配方。這就像是烘焙紙杯蛋糕的藍圖。 因此，這段簡單的程式碼就像告訴您神奇的廚師助手 (Docker Swarm) 建立 Node.js 應用程式的 100 個副本，確保您有大量容器正在執行並準備好提供服務。 ## Docker 群  Docker Swarm 是一個工具，可以幫助協調和管理一組電腦（節點）作為一個機器人團隊一起工作，使它們能夠以協調的方式部署和執行多個容器。這就像有一個首席機器人經理，確保所有單一機器人一起建造出偉大而令人驚嘆的東西。 **設定 Docker Swarm：** 1. **群組管理器：** - 想像你有一個首席機器人（Swarm Manager）來領導團隊。主機器人決定需要做什麼，並指導其他機器人（節點）如何協同工作。 ``` # Initiate Docker Swarm on the Swarm Manager docker swarm init ``` 2. **節點工作人員：** - 現在，您的工作機器人（節點工作人員）已準備好加入團隊。 Swarm Manager 共享一個特殊的程式碼（令牌）來邀請他們一起工作。 ``` # Join a Node Worker to the Docker Swarm docker swarm join --token <token> <Swarm Manager IP> ``` **Docker Swarm 服務：** 現在您已經有了一個協調的團隊，您想要建立一項服務，例如與您的機器人團隊一起建造塔： ``` # Create a Docker service (a group of containers) with 3 replicas (instances) docker service create --replicas 3 --network frontend --name my-web-server my-web-image ``` - `--replicas 3`：此標誌告訴 Docker 建立服務的三個實例（副本）。 - `--network frontend`：此標誌指定您的服務屬於名為「frontend」的網路。 - `--name my-web-server`：這會為您的服務命名，在本例中為「my-web-server」。 - `my-web-image`：這是您的網頁伺服器的圖片或藍圖。這就像建造塔樓的配方。 您建立了一個由隊長（Swarm Manager）和工作機器人（Node Workers）組成的機器人團隊。然後，您指示他們建立一個執行您的 Web 伺服器應用程式的服務（容器群組）。主機器人確保建立 Web 伺服器的三個副本並將其連接到「前端」網路。這就像有一個首席機器人經理在工作機器人的幫助下監督多個塔（貨櫃）的建造。  **好的，這就是本文的內容。** 另外，如果您對此或其他任何問題有任何疑問，請隨時在下面的評論中或在 [Instagram](https://www.instagram.com/_abhixsh/) 、[Facebook](https://www.facebook.com/abhi.haththakage/) 或[Twitter](https://twitter.com/abhixsh)。 感謝您閱讀這篇文章，我們下一篇再見！ ❤️ --- 原文出處：https://dev.to/abhixsh/docker-for-the-absolute-beginner-3h1p
最近，社群網路上流行一張 gif 動圖，展示了一件 [Bjorn Staal 製作的令人驚嘆的藝術品](https://twitter.com/_nonfigurativ_/status/1727322594570027343)。  我想重新建立它，但缺乏球體、粒子和物理的 3D 技能，我的目標是了解如何讓一個視窗對另一個視窗的位置做出反應。 本質上，在多個視窗之間共享狀態，我發現這是 Bjorn 專案中最酷的方面之一！ 由於無法找到有關該主題的好文章或教程，我決定與您分享我的發現。 > 讓我們嘗試根據 Bjorn 的工作建立一個簡化的概念驗證 (POC)！  我做的第一件事就是列出我所知道的在多個客戶端之間共享資訊的所有方法： ## 呃：伺服器 顯然，擁有伺服器（帶有輪詢或 Websocket）可以簡化問題。然而，由於 Bjorn 在沒有使用伺服器的情況下實現了他的結果，所以這是不可能的。 ## 本機存儲 本地存儲本質上是瀏覽器鍵值存儲，通常用於在瀏覽器會話之間保存資訊。雖然通常用於儲存身份驗證令牌或重定向 URL，但它可以儲存任何可序列化的內容。 [您可以在這裡了解更多](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage)。 我最近發現了一些有趣的本地儲存 API，包括 *`storage`* 事件，每當同一網站的另一個會話更改本地儲存時就會觸發該事件。  我們可以透過將每個視窗的狀態儲存在本地儲存中來利用這一點。每當一個視窗改變其狀態時，其他視窗將透過儲存事件進行更新。 這是我最初的想法，這似乎是Bjorn 選擇的解決方案，因為他分享了他的LocalStorage 管理器程式碼以及與ThreeJs 一起使用的範例[此處](https://github.com/bgstaal/multipleWindow3dScene) 。 但是當我發現有程式碼可以解決這個問題時，我想看看是否有其他方法…劇透警告：是的，有！ ## 共享工作者 這個華而不實的術語背後是一個令人著迷的概念——WebWorkers 的概念。 簡單來說，工作執行緒本質上是在另一個執行緒上執行的第二個腳本。雖然它們無法存取 DOM（因為它們存在於 HTML 文件之外），但它們仍然可以與您的主腳本進行通訊。 它們主要用於透過處理背景作業來卸載主腳本，例如預取資訊或處理不太關鍵的任務（例如流日誌和輪詢）。  共享工作線程是一種特殊類型的 WebWorkers，它可以與同一腳本的多個實例進行通信，這使得它們對我們的用例很有趣！好吧，讓我們直接進入程式碼！  ### 設定工人 如前所述，工作人員是具有自己的入口點的「第二腳本」。根據您的設定（TypeScript、捆綁程式、開發伺服器），您可能需要調整 tsconfig、新增指令或使用特定的匯入語法。 我無法涵蓋所有使用 Web Worker 的可能方法，但您可以在 MDN 或網路上找到資訊。 如果需要，我很樂意為本文撰寫前傳，詳細介紹設定它們的所有方法！ 就我而言，我使用的是 Vite 和 TypeScript，因此我需要一個「worker.ts」檔案並將「@types/sharedworker」安裝為開發依賴項。我們可以使用以下語法在主腳本中建立連結： ``` new SharedWorker(new URL("worker.ts", import.meta.url)); ``` 基本上，我們需要： * 辨識每個視窗 * 追蹤所有視窗狀態 * 一旦視窗改變狀態，提醒其他視窗重繪 我們的狀態將非常簡單： ``` type WindowState = { screenX: number; // window.screenX screenY: number; // window.screenY width: number; // window.innerWidth height: number; // window.innerHeight }; ``` 當然，最重要的訊息是“window.screenX”和“window.screenY”，因為它們告訴我們視窗相對於顯示器左上角的位置。 我們將有兩種類型的訊息： * 每個窗口，無論何時改變其狀態，都會發布一個帶有新狀態的“windowStateChangedmessage”。 * 工作人員將向所有其他視窗發送更新，以提醒他們其中一個視窗已更改。工作人員將發送包含所有視窗狀態的「syncmessage」。 我們可以從一個看起來有點像這樣的普通工人開始： ``` // worker.ts let windows: { windowState: WindowState; id: number; port: MessagePort }[] = []; onconnect = ({ ports }) => { const port = ports[0]; port.onmessage = function (event: MessageEvent<WorkerMessage>) { console.log("We'll do something"); }; }; ``` 我們與 SharedWorker 的基本連結如下所示。我有一些基本函數可以產生 id，並計算當前視窗狀態，我還對我們可以使用的稱為 WorkerMessage 的訊息類型進行了一些輸入： ``` // main.ts import { WorkerMessage } from "./types"; import { generateId, getCurrentWindowState, } from "./windowState"; const sharedWorker = new SharedWorker(new URL("worker.ts", import.meta.url)); let currentWindow = getCurrentWindowState(); let id = generateId(); ``` 一旦我們啟動應用程式，我們應該提醒工作人員有一個新窗口，因此我們立即發送一條訊息： ``` // main.ts sharedWorker.port.postMessage({ action: "windowStateChanged", payload: { id, newWindow: currentWindow, }, } satisfies WorkerMessage); ``` 我們可以在工作端監聽此訊息並相應地更改 onmessage。基本上，一旦工作人員收到 windowStateChanged 訊息，要么它是一個新窗口，我們將其附加到狀態，要么它是一個已更改的舊窗口。然後我們應該提醒大家狀態已經改變： ``` // worker.ts port.onmessage = function (event: MessageEvent<WorkerMessage>) { const msg = event.data; switch (msg.action) { case "windowStateChanged": { const { id, newWindow } = msg.payload; const oldWindowIndex = windows.findIndex((w) => w.id === id); if (oldWindowIndex !== -1) { // old one changed windows[oldWindowIndex].windowState = newWindow; } else { // new window windows.push({ id, windowState: newWindow, port }); } windows.forEach((w) => // send sync here ); break; } } }; ``` 為了發送同步，我實際上需要一些技巧，因為“port”屬性無法序列化，所以我將其字串化並解析回來。因為我很懶，所以我不只是將視窗映射到更可序列化的陣列： ``` w.port.postMessage({ action: "sync", payload: { allWindows: JSON.parse(JSON.stringify(windows)) }, } satisfies WorkerMessage); ``` 現在是時候畫東西了！ ## 有趣的部分：繪畫！ 當然，我們不會做複雜的 3D 球體：我們只會在每個視窗的中心畫一個圓，並在球體之間畫一條線！ 我將使用 HTML Canvas 的基本 2D 上下文進行繪製，但您可以使用任何您想要的內容。畫一個圓，非常簡單： ``` const drawCenterCircle = (ctx: CanvasRenderingContext2D, center: Coordinates) => { const { x, y } = center; ctx.strokeStyle = "#eeeeee"; ctx.lineWidth = 10; ctx.beginPath(); ctx.arc(x, y, 100, 0, Math.PI * 2, false); ctx.stroke(); ctx.closePath(); }; ``` 為了繪製線條，我們需要做一些數學運算（我保證，這不是很多🤓），並將另一個視窗中心的相對位置轉換為目前視窗上的座標。 基本上，我們正在改變基地。我用一點數學來做到這一點。首先，我們將更改底座以在顯示器上具有座標，並透過目前視窗 screenX/screenY 進行偏移  ``` const baseChange = ({ currentWindowOffset, targetWindowOffset, targetPosition, }: { currentWindowOffset: Coordinates; targetWindowOffset: Coordinates; targetPosition: Coordinates; }) => { const monitorCoordinate = { x: targetPosition.x + targetWindowOffset.x, y: targetPosition.y + targetWindowOffset.y, }; const currentWindowCoordinate = { x: monitorCoordinate.x - currentWindowOffset.x, y: monitorCoordinate.y - currentWindowOffset.y, }; return currentWindowCoordinate; }; ``` 如您所知，現在我們在同一相對座標系上有兩個點，我們現在可以畫線了！ ``` const drawConnectingLine = ({ ctx, hostWindow, targetWindow, }: { ctx: CanvasRenderingContext2D; hostWindow: WindowState; targetWindow: WindowState; }) => { ctx.strokeStyle = "#ff0000"; ctx.lineCap = "round"; const currentWindowOffset: Coordinates = { x: hostWindow.screenX, y: hostWindow.screenY, }; const targetWindowOffset: Coordinates = { x: targetWindow.screenX, y: targetWindow.screenY, }; const origin = getWindowCenter(hostWindow); const target = getWindowCenter(targetWindow); const targetWithBaseChange = baseChange({ currentWindowOffset, targetWindowOffset, targetPosition: target, }); ctx.strokeStyle = "#ff0000"; ctx.lineCap = "round"; ctx.beginPath(); ctx.moveTo(origin.x, origin.y); ctx.lineTo(targetWithBaseChange.x, targetWithBaseChange.y); ctx.stroke(); ctx.closePath(); }; ``` 現在，我們只需要對狀態變化做出反應。 ``` // main.ts sharedWorker.port.onmessage = (event: MessageEvent<WorkerMessage>) => { const msg = event.data; switch (msg.action) { case "sync": { const windows = msg.payload.allWindows; ctx.reset(); drawMainCircle(ctx, center); windows .forEach(({ windowState: targetWindow }) => { drawConnectingLine({ ctx, hostWindow: currentWindow, targetWindow, }); }); } } }; ``` 最後一步，我們只需要定期檢查視窗是否發生變化，如果發生變化則發送訊息 ``` setInterval(() => { const newWindow = getCurrentWindowState(); if ( didWindowChange({ newWindow, oldWindow: currentWindow, }) ) { sharedWorker.port.postMessage({ action: "windowStateChanged", payload: { id, newWindow, }, } satisfies WorkerMessage); currentWindow = newWindow; } }, 100); ``` [您可以在此儲存庫中找到完整的程式碼](https://github.com/achrafl0/multi-window-article)。實際上，我用它做了很多實驗，使它變得更加抽象，但其要點是相同的。 如果您在多個視窗上執行它，希望您能得到與此相同的結果！  謝謝閱讀 ！ 如果您發現這篇文章有幫助、有趣或只是有趣，您可以將其分享給您的朋友/同事/社區 [您也可以訂閱我的電子報](https://notachraf.substack.com/)它是免費的！ --- 原文出處：https://dev.to/notachraf/sharing-a-state-between-windows-without-a-serve-23an
你好👋 今天，讓我們來看看**前 1% 的開發人員使用**的 8 個 React 儲存庫（以及那些您可能從未聽說過的儲存庫）。 準備好？  --- # 我們如何找到前 1% 的開發人員使用的儲存庫？ 🔦 我們如何找到最好的開發人員使用的東西背後的故事植根於大量的資料探勘和一些重要的建模。 現在，在 Quine，我們根據開發人員的**[DevRank](https://docs.quine.sh/for-developers/devrank)** 對開發人員進行排名。 簡單來說，DevRank 使用 [Google 的 PageRank 演算法](https://en.wikipedia.org/wiki/PageRank) 根據開發人員對開源儲存庫的貢獻來衡量開發人員在開源領域的重要性。 為了建立此列表，我們查看了前 1% 已加星號的儲存庫。 🌟 然後，我們計算了前 1% 的開發者會為回購加註星標的可能性，與後 50% 的開發者不支持的可能性進行比較。  最後，經過一番挑選，我們找到了以下 8 個儲存庫。 ：向下點： 當您想要建立很酷的網頁應用程式時，這些儲存庫將特別有用。** 如果您有興趣建立小型應用程式，並且喜歡應用人工智慧方面，我們建議您查看 Creator Quests，這是一項**開源挑戰，獎勵開發人員使用 ChatGPT、Claude、Gemini 建立酷炫的 GenerativeAI 應用程式**和更多。 :upside_down_face: 💰 最新的 Creator Quest 挑戰您使用生成式 AI 建立開發人員工具。要參與，只需註冊 [Quine](https://quine.sh/?utm_source=devto&utm_campaign=best_react_repos) 並前往 _Quests_。 **目前獎金池為$2028**，並且隨著更多參與者的加入，獎金池將會增加！點擊下面的圖片並嘗試！ ⬇️ [](https://quine.sh/?utm_source=devto&utm_campaign=best_react_repos) --- # jsxstyle/jsxstyle **不再有 JS 到 CSS 的跳躍** [](https://github.com/jsxstyle/jsxstyle) **為什麼要關心？** 在 Web 開發中，使用 React 或 Preact，您必須設定元件的樣式（如按鈕、選單等）。傳統上，這是使用單獨的 CSS 檔案或複雜的樣式系統來完成的，這可能非常耗時且管理起來很麻煩。 jsxstyle 可讓您直接在 JavaScript 程式碼中以及元件中定義樣式，從而簡化了此過程。換句話說，這意味著您不再需要在 JS 和 CSS 檔案之間跳躍。 **設定**：`npm install jsxstyle` **範例用例**：您的程式碼可以如下所示。 👇 ``` <Row padding={15}> <Block backgroundColor="#EEE" boxShadow="inset 0 0 0 1px rgba(0,0,0,0.15)" borderRadius={5} height={64} width={64} marginRight={15} backgroundSize="contain" backgroundImage="url(http://graph.facebook.com/justinbieber/picture?type=large)" /> <Col fontFamily="sans-serif" fontSize={16} lineHeight="24px"> <Block fontWeight={600}>Justin Bieber</Block> <Block fontStyle="italic">Canadian</Block> </Col> </Row> ``` [https://github.com/jsxstyle/jsxstyle](https://github.com/jsxstyle/jsxstyle) --- # 💨 alangpierce/蔗糖酶 **Babel 的超快替代品** [](https://github.com/alangpierce/sucrase) **為什麼你應該關心？** Babel 是 Web 開發中廣泛使用的工具，可將現代 JavaScript 程式碼轉換為舊瀏覽器可以理解的格式。 Sucrase 是 Babel 更快的替代品。 **設定**: ``` yarn add --dev sucrase # Or npm install --save-dev sucrase node -r sucrase/register main.ts ``` **用例範例**：Sucrase 可以直接從 JS 呼叫： ``` import {transform} from "sucrase"; const compiledCode = transform(code, {transforms: ["typescript", "imports"]}).code; ``` [https://github.com/alangpierce/sucrase](https://github.com/alangpierce/sucrase) --- # 🎨 woorm/折射鏡 **我為您的網頁程式碼著色，讓您的生活更輕鬆** [](https://github.com/wooorm/refractor) **為什麼你應該關心？** Refractor 很重要，因為它允許您加入突出顯示，從而增強專案的可讀性；尤其是當您將程式碼片段新增至 Web 應用程式時。它允許您用 270 多種程式語言表達程式碼，並且在傳統的基於 HTML 的突出顯示不理想的領域（例如 CLI 表單）特別有用。 **設定**：`npm install refractor` **用例範例**： ``` import {refractor} from 'refractor' const tree = refractor.highlight('"use strict";', 'js') console.log(tree) ``` **產量**： ``` { type: 'root', children: [ { type: 'element', tagName: 'span', properties: {className: ['token', 'string']}, children: [{type: 'text', value: '"use strict"'}] }, { type: 'element', tagName: 'span', properties: {className: ['token', 'punctuation']}, children: [{type: 'text', value: ';'}] } ] } ``` [https://github.com/wooorm/refractor](https://github.com/wooorm/refractor) --- # 🐦 react-static-tweets **您在網站上加入推文的最佳選擇。** [](https://github.com/transitive-bullshit/react-static-tweets) **為什麼你應該關心？** 將推文加入到您的網站是您在許多登陸頁面上看到的一項很酷的功能。 React Static Tweets 很重要，因為它提供了一種在 Web 專案中嵌入推文的高效方法，與 Twitter 的標準嵌入方法相比，提供更快的載入時間和更好的效能。 **設定**: ``` npm install react-static-tweets static-tweets date-fns # or yarn add react-static-tweets static-tweets date-fns ``` **用例範例：** ``` import React from 'react' import { fetchTweetAst } from 'static-tweets' import { Tweet } from 'react-static-tweets' const tweetId = '1358199505280262150' export const getStaticProps = async () => { try { const tweetAst = await fetchTweetAst(tweetId) return { props: { tweetAst }, revalidate: 10 } } catch (err) { console.error('error fetching tweet', err) throw err } } export default function Example({ tweetAst }) { return <Tweet ast={tweetAst} /> } ``` [https://github.com/transitive-bullshit/react-static-tweets](https://github.com/transitive-bullshit/react-static-tweets) --- # 🖨️ preactjs/preact-render-to-string **以 HTML 形式呈現您的元件** [](https://github.com/preactjs/preact-render-to-string) **為什麼要關心？** 「preact-render-to-string」是一個工具，可以幫助網站更快地載入並在搜尋引擎中更好地顯示。使用 Preact 等 JS 框架建立的網站需要一段時間才能顯示內容，因為瀏覽器必須先執行 JavaScript。此儲存庫透過將元件轉換為現成的 HTML 來完成伺服器端的繁重工作。因此，當有人造訪該網站時，即使網路速度很慢，他們也會立即看到內容。 **設定**：`npm install preact-render-to-string` **用例範例：** ``` import { render } from 'preact-render-to-string'; import { h, Component } from 'preact'; /** @jsx h */ // Classical components work class Fox extends Component { render({ name }) { return <span class="fox">{name}</span>; } } // ... and so do pure functional components: const Box = ({ type, children }) => ( <div class={`box box-${type}`}>{children}</div> ); let html = render( <Box type="open"> <Fox name="Finn" /> </Box> ); console.log(html); // <div class="box box-open"><span class="fox">Finn</span></div> ``` [https://github.com/preactjs/preact-render-to-string](https://github.com/preactjs/preact-render-to-string) --- # 🏆 自行車刮鬍/曲柄 **唯一的 JavaScript 框架** [](https://github.com/bikeshaving/crank) **為什麼要關心？** 在像 React 這樣的傳統 Web 框架中，Web 元件配置一次，僅在明確指定時才更改。它們看起來像是需要手動更新的靜態影像。 Crank.js 透過允許小部件更新自身以回應新資料來改變這一點，類似於用新新聞刷新的新聞收報機。這對於管理即時資料（例如即時體育賽事比分或產品更新）的 Web 應用程式尤其有用。 這個倉庫需要更多的人遷移到這裡才能獲得關注，但它仍然是一個非常酷的倉庫，值得關注。 👀 **設定**：`$ npm i @b9g/crank` **用例範例**： ``` import {renderer} from "@b9g/crank/dom"; function Greeting({name = "World"}) { return ( <div>Hello {name}</div> ); } renderer.render(<Greeting />, document.body); ``` [https://github.com/bikeshaving/crank](https://github.com/bikeshaving/crank) --- # 🎯 evoluhq/evolu **我是一個本地第一的人** [](https://github.com/evoluhq/evolu) **為什麼要關心？** Web 應用程式通常依賴在伺服器上儲存使用者資料，這需要持續的網路連接，並引起對隱私和資料安全的擔憂。這種基於伺服器的方法也意味著如果伺服器發生故障或公司停止運營，效能會降低，並且可能會遺失資料。 Evolu 引入了「本地優先」方法，其中資料直接儲存在使用者的裝置上。這意味著您的應用程式可以離線工作，更快地存取資料，並提供增強的隱私和安全性。如果您正在建立離線 Chrome/瀏覽器應用程式，這將非常有用。 **設定**：` npm install @evolu/react` 要開始使用它，您可以在[此處](https://www.evolu.dev/docs/quickstart)找到這個很棒的指南。 [https://github.com/evoluhq/evolu](https://github.com/evoluhq/evolu) --- # 📸 笑話社群/快照差異 **我比較你們的元件並突出顯示差異** [](https://github.com/jest-community/snapshot-diff) **為什麼要關心？** 在測試 React 元件或其他 JavaScript 值時，開發人員通常會比較整個狀態或輸出。這意味著處理大量資料，查找特定變更就像大海撈針一樣。 Snapshot-diff 是重點比較工具，可讓您取得元件的兩種不同狀態（或任兩個 JavaScript 值）並直接比較它們，僅將差異突出顯示。 這對於測試 React 元件特別有幫助，因為它可以準確指出兩種狀態之間發生的變化，從而更容易辨識和理解程式碼變更的影響。 **設定**：`yarn add --dev snapshot-diff` **範例用例：** 預設笑話匹配器 ``` const snapshotDiff = require('snapshot-diff'); test('snapshot difference between 2 strings', () => { expect(snapshotDiff(a, b)).toMatchSnapshot(); }); const React = require('react'); const Component = require('./Component'); test('snapshot difference between 2 React components state', () => { expect( snapshotDiff(<Component test="say" />, <Component test="my name" />) ).toMatchSnapshot(); }); ``` [https://github.com/jest-community/snapshot-diff](https://github.com/jest-community/snapshot-diff) --- **我希望這些發現對您有價值，並將有助於建立更強大的 React 工具包！⚒️** 如果您今天想利用這些工具來獲得獎勵，我們剛剛發起了一項使用生成式人工智慧建立開發人員工具的挑戰。 如果對此有興趣，請登入 [Quine](https://quine.sh/?utm_source=devto&utm_campaign=best_react_repos) 並發現任務！ 💰  最後，請**考慮透過加星號來支持這些專案。 ⭐️** PS：我們與他們沒有任何關係。我們只是認為偉大的專案值得高度認可。 下週見， 您的開發夥伴💚 巴普 --- 原文出處：https://dev.to/quine/8-repos-used-by-the-top-1-of-react-devs-2758
## 為什麼是書籍？ 在發展我的技能時，我喜歡結合使用會議演講、視訊教學、書籍、論文、部落格文章、邊做邊學和教學/部落格。書籍是從別人所犯的錯誤中學習、從他們的成功中受到啟發以及間接體驗他們的成就的好方法。 在這篇文章中，我想分享我最喜歡的書籍，這些書籍在我從高級軟體工程師到成為技術主管的過程中對我幫助最大。他們幫助我拓寬並加深了對軟體工程、軟體架構以及建構和經營軟體業務的理解。他們教我挑戰和塑造我的行為和習慣。其中一些深深影響了我的個人和職業生活。 不用說，閱讀這些書不會自動讓你升職或讓你擔任新的技術主管職位。當然，你還是需要自己的經驗，自己的錯誤，還需要一點運氣。根據您所從事的特定領域不斷提高您的技術知識和技能也很重要。此清單中的書籍並不關注特定技術，而是適用於任何技術堆疊和業務的一般原則和概念。 對於清單中的每本書，我都會附上一個簡短的摘要，可以幫助您判斷這本書是否與您相關。為了賦予它個人風格，我還將包括我從這本書中學到的最有價值的教訓。這不一定是這本書的主要訊息，也不是唯一重要的訊息，而是最能引起我共鳴的訊息。 ## 列表 ### 設計它！ [*Design It!: From Programmer to Software Architect*]((https://www.oreilly.com/library/view/design-it/9781680502923/)) Michael Keeling 是一本針對有志向的軟體開發人員的綜合指南轉變為軟體架構師的角色。本書提供了一種實用且易於理解的軟體架構方法，強調了設計在建立有效的軟體系統中的重要性。 Keeling 涵蓋了廣泛的主題，從軟體架構的基本原理到設計可擴展和可維護系統的實用技術。 在整本書中，基林提倡採用實踐、迭代的軟體設計方法，鼓勵讀者批判性地思考他們所做的架構選擇。他介紹了各種架構風格和模式，並討論如何評估權衡並做出符合專案目標和限制的決策。本書充滿了現實世界的範例、練習和實用技巧，對於那些希望發展軟體架構和設計技能的人來說是一個寶貴的資源。 **我從書中學到的最有價值的教訓：** 不存在「沒有設計」這樣的事情。 「無設計」通常意味著在工程師的腦海中存在多種、隱含的設計，這些設計彼此不一致。明確、協作、迭代地設計，並以書面記錄設計！ ### 釋放它！ Michael Nygard 的[*Release It!: Design and Deploy Production-Ready Software*](https://www.oreilly.com/library/view/release-it/9781680500264/) 是軟體開發人員和架構師的重要指南討論建立在生產環境中可靠運作的軟體所面臨的挑戰。本書深入探討了設計、部署和維護能夠承受現實世界操作嚴苛的軟體的複雜性。 Nygard 強調從設計過程一開始就考慮生產現實的重要性，並提倡從僅僅編寫程式碼到提供彈性、可擴展和可維護的系統的思維方式轉變。 Nygard 提供了對軟體系統在生產中遇到的各種陷阱的見解，例如網路問題、不可預測的負載模式和硬體故障。他介紹了穩定性模式和反模式等概念，說明如何建立能夠優雅地處理故障並在壓力下保持穩健的系統。這本書充滿了現實生活中的故事和案例研究，展示了生產環境中不良系統設計所造成的災難性後果。 “放開它！”對於軟體專業人士來說，這是一個寶貴的資源，他們希望確保他們的系統不僅能正常執行，而且在面對現實世界的挑戰時具有彈性和可靠性。 **我從書中學到的最有價值的教訓：** 每個軟體工程師都應該在建立他們的軟體時考慮到生產。生產中的軟體負責營運您的業務、影響您的客戶並決定成功或失敗。 ### 站點可靠度工程 [*站點可靠性工程：Google 如何執行生產系統*](https://www.oreilly.com/library/view/site-reliability-engineering/9781491929117/) 作者：Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall理查德·墨菲(Richard Murphy) 對Google 用於管理其大規模、高度可靠系統的實踐和原則進行了富有洞察力的探索。本書介紹了站點可靠性工程 (SRE) 的概念，這是一門將軟體工程與 IT 營運相結合的學科，重點是建立可擴展且可靠的軟體系統。 作者都是 Google 的 SRE 領域經驗豐富的從業者，他們分享瞭如何建置、部署、監控和維護強大且有彈性的系統的專業知識。他們深入研究了 Google 使用的具體策略和技術，例如設定服務等級目標 (SLO)、有效管理變更以及平衡發布速度與服務可靠性的需求。這本書涵蓋了一系列主題，從 SRE 團隊的組織方面到事件管理和事後分析文化等技術實踐。這本書提供了對世界上最熟練的工程組織之一的內部運作的罕見了解，對於參與大型系統的操作、維護和擴展的任何人來說都是寶貴的資源。 **我從書中學到的最有價值的教訓：** 不存在完美的系統。透過明確定義和衡量 SLO 和錯誤預算，您可以就可靠性和速度之間的權衡做出明智的決策。 ### 改變你的問題，改變你的生活 [*改變你的問題，改變你的生活：領導力、指導和生活的 12 種強大工具*](https://www.goodreads.com/en/book/show/6665149)，作者 Marilee Adams 探討了我們提出的問題可能會對我們的生活和職業生涯產生影響。亞當斯引入了「問題思維」的概念，這是一種透過深思熟慮和用心提問來轉變思維、行動和結果的方法。這本書強調了我們問自己的問題類型，從限制性的、判斷性的「判斷者」問題到更開放的、建設性的「學習者」問題，如何能顯著影響我們的觀點和結果。 亞當斯透過引人入勝的敘述闡述了她的想法，講述了一個人與生活挑戰作鬥爭並學習應用問題思維原則的故事。這種方法為個人提供了實用的工具和技術，以提高他們的溝通、決策和解決問題的能力。透過培養學習者心態並提出更好、更有說服力的問題，讀者可以被引導建立更積極、更有生產力的個人和專業關係。這本書對於領導者、教練以及任何希望增強與他人聯繫並更有效地駕馭複雜情況的能力的人來說特別有價值。 **我從書中學到的最有價值的教訓：**我意識到我經常處於「評判者」心態中。更加留意這一點，並有意識地選擇轉變為「學習者」心態，對我來說幾乎就像一種超能力，可以解決我面臨的任何挑戰。 ### 思考，快與慢 Daniel Kahneman 的 [*思考，快與慢*](https://www.amazon.de/-/en/Designing-Data-Intective-Applications-Reliable-Maintainable/dp/1449373321) 是對心理學與經濟學，深入研究我們如何思考和做出決策。卡尼曼介紹了兩種主導我們心理過程的不同思維模式：「系統1」（快速、直覺和情緒）和「系統2」（較慢、更深思熟慮和更邏輯）。卡尼曼在整本書中探討了這兩個系統對我們的判斷、決策以及我們感知周圍世界的方式的影響。 這本書全面探討了影響我們日常思維的各種認知偏見和啟發法。卡尼曼展示了我們的直覺系統 1（通常對我們很有幫助）也可能導致嚴重的錯誤和偏見。他也探討了系統 2 的功能和局限性，強調系統 1 的快速判斷如何影響和推翻它。這本書綜合了數十年的研究，提供了對人類思想和行為的複雜性的深入見解。對於任何有興趣了解我們在個人和職業環境中的選擇和行為背後的心理過程的人來說，這是一本必讀的書。 **我從書中學到的最有價值的教訓：**我了解到這兩種模式都很有價值，但也有其缺點。我學會了更了解影響我思考的偏見和啟發法，並有意識地選擇何時依賴系統 1，何時使用系統 2。 ### 原子習慣 James Clear 的[*原子習慣：一種簡單且行之有效的建立好習慣和改掉壞習慣的方法*](https://jamesclear.com/atomic-habits) 是一本變革性的指南，深入研究了習慣的科學以及習慣的小習慣改變可以帶來顯著的結果。作者提出了一個理解習慣如何形成的全面框架，並提供了培養好習慣和改掉壞習慣的實用策略。這本書的核心理念是，隨著時間的推移，微小的改進或「原子習慣」可以累積成重大的、改變生活的結果。 克利爾強調系統比目標更重要，他認為專注於實現目標的流程和系統比專注於目標本身更有效。他介紹了行為改變四定律──一套簡單、可操作的原則來引導習慣的形成。其中包括使線索明顯、渴望有吸引力、反應簡單以及獎勵令人滿意。透過結合科學研究、個人故事和現實世界的例子，克利爾闡述如何將這些原則應用於生活的各個方面，從健身和財務管理到生產力和個人成長。 《原子習慣》為培養持久的習慣提供了一個易於理解且引人注目的藍圖，對於任何想要在生活中做出積極、持久改變的人來說都是有價值的。 **我從這本書中學到的最有價值的教訓：** 透過對我的日常生活進行許多小改變，這些改變單獨地只會對我的生產力產生很小的影響，所有這些習慣結合起來會產生巨大的影響。 ### 有意識的商業 Fred Kofman 的 [*Conscious Business: How to Build Value Through Values*](https://www.amazon.de/-/en/Fred-Kofman/dp/1622032020) 是一本發人深省的書，探討了個人誠信和職業成功。作者提出了這樣的觀點：建立成功且可持續發展的企業的關鍵在於有意識的管理實踐，其中個人價值觀和道德原則處於決策過程的最前沿。該書認為，商業上的成功不僅在於經濟收益，還在於實現個人和職業成就。 科夫曼討論了有意識的商業的各個方面，包括問責制、責任、情緒智商、溝通技巧以及建設性解決衝突的能力。他強調領導者能夠激發信任、培養開放和誠實的文化並以同理心領導的重要性。透過現實世界的例子、實用的建議和練習，科夫曼指導讀者如何發展這些技能並將其應用到他們的職業生活中。 **我從書中學到的最有價值的教訓：**無條件回應能力的概念。我現在不斷提醒自己，無論情況如何，我都有權力和責任選擇對任何情況的反應。 「響應能力」是「響應」和「能力」的雙關語，強調自覺、主動回應的能力。 ### 首先，打破所有規則 [*首先，打破所有規則：世界上最偉大的管理者的不同做法*](https://store.gallup.com/p/en-us/10286/first-break-all-the-rules) 作者：Marcus Buckingham柯特·科夫曼（Curt Coffman）根據蓋洛普組織的研究提出了一種激進的管理方法。本書挑戰了有關領導力和管理的傳統智慧，提出最有效的管理者往往會違反標準做法。 本書的核心訊息是，偉大的管理者不會遵循單一模式或嚴格遵守傳統的管理原則。相反，他們透過專注於員工的個人優勢而不是試圖糾正他們的弱點來打破規則。作者認為，這種方法可以提高敬業度、生產力和整體工作滿意度。 白金漢和科夫曼確定了使世界上最好的管理者脫穎而出的關鍵見解和策略。其中包括選擇人才而不是簡單地填補職位的重要性，定義正確的結果而不是規定正確的步驟，關注優勢而不是沉迷於劣勢，以及為員工找到合適的人選而不是簡單地將他們晉升到下一個梯級。梯子。 **我從書中學到的最有價值的教訓：** 專注於優勢而不是劣勢的重要性。我學會了接受自己的弱點，並使用工具和策略來彌補它們，而不是試圖「修復」它們。相反，我投入時間和精力來發展自己的優勢，並嘗試為我所領導的人做同樣的事情。 ## 榮譽獎 在我從高級軟體工程師到技術主管的旅程中，我發現還有很多有價值的書籍。它們更專注於特定技術，這就是為什麼我沒有將它們包含在主列表中。儘管如此，我想在這裡提及它們，因為它們可能與您相關，具體取決於您所從事的領域/行業。 - [*資料庫內部架構*](https://www.databass.dev/)，作者：Alex Petrov。我讀過的「最好的」資料庫書籍。它以一種非常容易理解的方式涵蓋了資料庫的所有基礎知識。對於任何使用資料庫的人來說，這是一本必讀的書。 - [*設計資料密集型應用程式*](https://www.amazon.de/-/en/Designing-Data-Intential-Applications-Reliable-Maintainable/dp/1449373321) 作者：Martin Kleppmann。建立資料密集型應用程式的綜合指南。它涵蓋了廣泛的主題，從資料庫和資料處理到分散式系統和串流處理。 - [*Oracle JRockit：權威指南*](https://www.packtpub.com/product/oracle-jrockit-the-definitive-guide/9781847198068)，作者：Marcus Hirt 和 Marcus Lagergren。對於任何對 JVM 內部結構感興趣的人來說，這是一個很好的資源。 - [*Linux 程式介面*](https://man7.org/tlpi/) 作者：Michael Kerrisk。這是一本關於 Linux 的非常詳細的書，涵蓋了廣泛的主題，從基本的系統呼叫到進程組、訊號和套接字等高級主題。 ## 最後的想法 雖然書籍是個很好的學習工具，但它們並不能取代第一手經驗。你仍然需要犯自己的錯誤並從中學習。與他人討論你讀過的書，了解他們的觀點並挑戰你自己的觀點也很有幫助。也許您可以加入讀書俱樂部，或與同事或朋友一起閱讀。 我希望這份清單對您的職業生涯有所幫助。如果有一本書啟發了您並且您認為應該在此列表中，請在下面的評論中告訴我。 --- 原文出處：https://dev.to/frosnerd/books-that-helped-me-become-a-tech-lead-3831
這是開源的季節☃️ 假期編碼可以是一種幸福的經歷，沒有什麼比在休息時間建立一個很棒的專案更好的了。 我瀏覽了無數的儲存庫，找到了 24 個最適合聖誕節編碼的庫。  不要忘記 STAR 🌟 這些儲存庫並保存本文以供日後使用。 --- #Web-Dev🌐： ### 1. [CopilotTextarea ](https://github.com/CopilotKit/CopilotKit) - React 應用程式中的 AI 驅動寫作  具有 Github CopilotX 功能的任何 React `<textarea>` 的直接替代品。 自動完成、插入、編輯。 可以即時或由開發人員提前提供任何上下文。 ###2.[React Joyride](https://github.com/gilbarbara/react-joyride) - 建立產品演練 ###3.[NextAuthJS](https://github.com/nextauthjs/next-auth) - 輕鬆設定驗證 ###4.[Trigger.dev](https://github.com/triggerdotdev/trigger.dev) - 可靠地執行長時間作業而不會逾時 --- #UI/UX🦋： ### 5. [Flowbite](https://github.com/themesberg/flowbite) - 頂級 CSS 元件庫  最好、最受尊敬的 UI 元件庫之一。 基於實用優先的 CSS 框架。 易於使用，充滿重要的支援和模板。 ###6.[MaterialUI](https://github.com/mui/material-ui) - 使用 Google 的 Material Design 實現的基礎 React 元件 ###7。 [SwiperUI](https://github.com/nolimits4web/swiper) - 用於實現行動滑動 UI 的受人尊敬的庫 ###8.[ReactSpring](https://github.com/pmndrs/react-spring) - 在 React 中實現具有真實物理效果的動畫 --- #GenAI🤖： ## 9. [CopilotPortal](https://github.com/RecursivelyAI/CopilotKit)：在您的應用程式中嵌入可操作的 LLM 聊天機器人。  應用程式中的上下文感知 LLM 聊天機器人可以回答問題並採取行動。 只需幾行程式碼即可獲得一個可用的聊天機器人，然後根據需要進行自訂和嵌入。 ###10.[llamafile](https://github.com/Mozilla-Ocho/llamafile) - 將使用 LLM 的複雜性壓縮到單一檔案 ###11。 [Pezzo.ai](https://github.com/pezzolabs/pezzo) - 開發人員最喜歡的 LLM 操作和可觀察性 ###12.[Tavily](https://github.com/assafelovic/gpt-researcher) - 開發人員友善的自治 GPT 代理，可搜尋資料並撰寫報告 --- #安全/隱私🔐： ### 13. [Wazuh](https://github.com/wazuh/wazuh) - 統一開源安全平台  適用於端點和雲端工作負載的統一開源安全平台。 威脅偵測、預防和回應。 保護本地、容器化和雲端環境。 ###14.[Zeek](https://github.com/zeek/zeek) - 深入分析網路流量 ###15。 [SuperTokens](https://github.com/supertokens/supertokens-core) - 開源身分驗證提供者 ###16.[Sniffnet](https://github.com/GyulyVGC/sniffnet) - 本地監控您的網路流量 --- #移動📱： ### 17. [Tamagui ](https://github.com/tamagui/tamagui) - 受人尊敬的 React Native UI 與最佳化函式庫  Tamagui 旨在快速設計 React 應用程式。 它包含一個可選的 UI 套件和一個用於增強效能的最佳化編譯器。 允許在 Web 和本機平台之間實現無縫程式碼共享，為每個環境最佳化樣式元件。 ###18.[EarlGrey](https://github.com/google/EarlGrey) - Google 進行的 iOS UI 測試 ###19。 [ReactNativeMaps](https://github.com/react-native-maps/react-native-maps) - 高度可自訂的應用程式地圖元件 ###20.[ReactNativePaper](https://github.com/callstack/react-native-paper) - 適用於 iOS 和 Android 的設計庫 --- #其他🎅： ### 21. [LangChain ](https://github.com/CopilotKit/CopilotKit) - 使用 LLM 建立自訂操作鏈  一個著名的庫，但仍然包含在內，因為它是我最喜歡的庫之一，並且建置起來很有趣。 模組化元件可協助您將 LLM 整合到與許多應用程式和 API 整合的操作中。 用於建立 LLM 代理的強大框架。 ###22.[ReactAgent](https://github.com/eylonmiz/react-agent) - 實驗專案。將提示轉變為有效的反應元件 ###23.[Awesome for Beginners](https://github.com/MunGell/awesome-for-beginners) - Github 初學者友好專案列表 ###24.[Appwrite](https://github.com/appwrite/appwrite) - 適用於網路和行動應用程式的強大後端平台 --- 而且……就是這樣，夥計們！ 希望您喜歡這些庫，並且它們可以幫助/激勵您在假期期間建立一些很酷的東西。 ##如果您喜歡本文，請不要忘記對儲存庫加 STAR🌟 並透過回饋來支持本文。 #聖誕節快樂！ 🎅🏽☃️ --- [PS：本文附有我用 [Suno.ai](https://www.suno.ai) 產生的伴奏歌曲。他們很搞笑，很棒，也很令人毛骨悚然。告訴我你最喜歡哪一個： 1. [開源聖誕老人](https://app.suno.ai/song/e5d415a5-2914-4fc4-b3e5-136ea0a8ef5a/) 2.【聖誕老人的程式設計師聖誕魔法】(https://app.suno.ai/song/5794dcf0-e9cc-4e0d-a80f-f70ef4b73150/)] --- 原文出處：https://dev.to/copilotkit/24-must-try-open-source-projects-for-your-christmas-coding-3603
## 介紹 幾天前，我在我曾經就讀的大學舉辦了一場關於 Kubernetes 及其元件的演講。我媽媽說她喜歡這個演講，所以我把它變成了一篇部落格文章。 許多軟體工程師傾向於忽視與 Kubernetes 相關的任何東西，儘管他們可能每天都會使用它。乍一看，它似乎很複雜，就像一個需要潛入的全新世界。是的，確實如此，但在這篇文章中，我將介紹 Kubernetes 叢集的所有主要元件，並在範例中解釋它們的作用。 在這篇文章結束時，您不會成為 Kubernetes 專家，但您可能會很好地了解要尋找什麼以及如何建立 Kubernetes 最初看起來的混亂狀態。 *代表 Kubernetes 架構的圖片取自 [Kubernetes 網站](https://kubernetes.io/docs/concepts/overview/components/)* ### **向我們展示您的支持🙏🏻**  在我們開始之前，如果您為我們的儲存庫加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興。我們的 GitHub 儲存庫位於：https://github.com/cyclops-ui/cyclops ⭐ ## 成分 首先，我們可以將 Kubernetes 叢集分為兩部分：**控制平面**和**工作節點**。控制平面負責整個操作並控制集群的狀態。我們很快就會了解這意味著什麼。另一方面，我們的工作節點本質上只是監聽控制平面告訴它們要做什麼的電腦。它們是我們集群的運算能力。我們在叢集中執行的任何應用程式都將在這些節點上執行。 讓我們進一步分解。 ### 控制平面  正如我們所說，控制平面確保我們的叢集能如預期運作。它透過與叢集用戶通訊、調度工作負載、管理叢集狀態等來實現這一點。 控制平面由四個關鍵元件組成。它們本身很簡單，但一起建立了一個複雜的系統。這些元件是： - **API** - **ETCD** - **調度程序** - **控制器經理** 控制平面元件可以在叢集中的任何機器上執行，但通常在一組單獨的機器上執行，通常稱為**主節點**。這些機器不用於執行任何其他容器或應用程式，而是為 Kubernetes 控制平面保留。 #### API Kubernetes API 充當叢集的前端接口，允許使用者與叢集互動、定義所需狀態以及執行建立、更新和刪除資源等操作。 這是我們與集群的**唯一聯繫點**。此外，沒有其他元件直接相互通信，但所有通信都是透過 API 進行的。 #### ETCD ETCD 是 API 的**資料庫**；就這麼簡單。當您告訴 Kubernetes 建立部署時，它會與所有其他建立的資源一起儲存在 ETCD 中。 ETCD 的一個特點是它的鍵值儲存被組織為檔案系統。 ETCD 的另一個出色功能是用戶可以**訂閱**事件並獲得有關更改的通知。例如，*建立新 Pod 時讓我知道*。 #### 調度程序 顧名思義，調度程式**決定 pod 將在哪個節點上執行**。它透過一組規則來實現這一點，您可以在 [Kubernetes 文件](https://kubernetes.io/docs/home/) 中閱讀。 *這就是我說你不會成為專家時的意思，但你會知道要谷歌什麼:)* 調度程序**訂閱**保存在 ETCD 中的所有新建立的 pod，但它**只能**與 API 通訊來取得此更新。 當它發現 Pod 已建立時，它會計算在哪個工作節點上執行它。一旦決定，**調度程序不會在任何機器上執行任何東西**；它只是告訴 API 在特定節點上執行 pod。 #### 控制器管理器 控制平面的最後一個元件是控制器管理器。我們可以把它當作我們集群的恆溫器。它的工作是將集群的當前狀態轉變為所需的狀態。 這意味著它將**在幕後建立所有需要的資源**來滿足我們的需求並使我們的應用程式啟動並執行。 它執行多個控制器進程，這些進程訂閱了 ETCD 上的更改，並編譯成相同的二進位檔案以便於部署。控制器管理員的角色以及這些控制器的作用將在部落格後面進行更詳細的定義。 ### 工作節點  現在我們已經了解了整個叢集的管理方式，接下來讓我們深入了解容器在哪裡運作以及如何實現這一點。 Kubernetes 叢集中的每個節點上執行 3 個元件。當然，您可以在叢集中擁有多個節點，但每個節點都需要這三個元件來託管您的應用程式。 那些是： - **容器運作時** - **kubelet** - **成為代理** #### 容器執行時 允許 Kubernetes 執行容器並管理節點上容器的生命週期的元件是容器執行時。 支援多個容器執行時，例如[conatinerd](https://containerd.io/)、[cri-o](https://cri-o.io/) 或其他[CRI 相容執行時](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)。 #### 庫貝萊特 另一個訂閱 pod 事件的元件是 Kubelet。每次在節點上調度 pod 時，該節點上執行的 Kubelet 都會聽到該訊息並啟動所有定義的容器。最重要的是，Kubelet 還執行健康檢查，以確保一切能如預期運作。 #### 成為代理 Kubernetes 中的 KubeProxy 管理叢集中 pod 之間的網路連接，處理負載平衡和網路路由等任務。它透過維護網路規則並將服務抽象轉換為可操作的網路策略來確保 Pod 之間的無縫通訊。 ## 從部署到正在執行的容器 現在我們已經列出了 Kubernetes 叢集中的所有元件及其角色，接下來讓我們講述一個有關 Kubernetes 部署如何成為在叢集中的各種電腦上執行的一組容器的故事。 ### Pod、副本集和部署 快速提醒這三者的關係：Pod、Replicaset 和 Deployment。  我們可以在 Kubernetes 叢集中部署的最小單元是 **pod**。有了它，我們將定義我們的容器。 最有可能的是，我們需要同一應用程式的幾個實例，並且我們可以定義如何使用 **Replicaset** 複製我們的 pod。它將透過啟動和終止來確保我們有所需數量的 Pod 執行。 太棒了，現在我們已經複製了我們的應用程式，但我們想推出新版本的應用程式。我們必須拆除現有的 Pod/Replicaset 並建立新的。部署將自動執行此流程，使我們能夠安全地推出我們的功能。 ## 威望  現在我們已經了解了所有術語並觸及了所有 Kubernetes 元件及其角色，讓我們看看當我們將 Deployment「套用」到 Kubernetes 叢集時會發生什麼。 假設我們已經建立了一個定義應用程式的「deployment.yaml」檔案（您可以在[此處](https://imgur.com/7qKp189)了解如何執行此操作）並執行「kubectl apply -f deployment. yaml” 。 `kubectl` 現在將把我們的部署定義提交到叢集的**唯一的聯絡點** - Kubernetes API。 我們的簡單 API 將把我們的部署儲存在 ETCD 資料庫中。每次將 Deployment 物件儲存到 ETCD 時，它都會讓 API 知道 Deployments 發生了更改，並且它應該讓**每個訂閱此類事件的人**知道這一點。 控制平面中有一個元件想要知道何時產生新的部署，這就是**控制器管理器**。當它聽到新的 Deployment 時，它將根據 Deployment 配置建立一個新的 Replicaset。為了建立此 Replicaset，它將透過建立請求來呼叫 API。 建立 Replicaset 與建立 Deployment 非常相似。 API 將接收一個 Replicaset 來建立並儲存到 ETCD 中。這將使 ETCD 告訴 API 有人建立了一個 Replicaset 並將該資訊傳遞給所有訂閱的元件，這又是控制器管理器。 當 Controller Manager 聽到新的 Replicaset 時，它會透過呼叫 API 來建立使用該 Replicaset 定義的所有 Pod，您猜對了，該 API 會將所有這些 Pod 儲存到 ETCD 中。  *正如我們所說，發生了很多事情，因此我們決定建立一個 GIF 來幫助您了解整個過程。* 在這裡，我們包括了 Scheduler，它訂閱了 Pod 建立事件。每次聽到新的 Pod 時，它都會決定應該在哪個節點上執行。 Scheduler 並沒有執行 Pod，只是告訴 API** 它為其選擇了哪個節點。然後 API 將保存該資訊。 另一個監聽 Pod 事件的元件是 Kubelet，它是執行在 Kubernetes 叢集中每個工作節點上的元件。每次 API 告訴 Kubelet Scheduler 決定在其節點上執行 Pod 時，Kubelet **將啟動 Pod 定義的所有容器**。 最後，我們將配置變成了在機器上執行的應用程式！這是一個漫長的過程，有很多移動部分，但這可能是我最喜歡的部分。 每個元件只承擔部署應用程式的一小部分責任，但它們一起解決了一個相當複雜的問題。 ## 最後的想法 希望本文能幫助您掌握 Kubernetes 元件，並幫助您揭開最受歡迎的編排器的神秘面紗。我們鼓勵您自行挖掘，因為我們很高興了解這一點。 我們推薦學習 Kubernetes 的一本書是 Marko Lukša 的《Kubernetes in action》。它非常受歡迎，並且很好地概述了 Kubernetes 背後發生的事情以及如何使用它。 --- 原文出處：https://dev.to/cyclops-ui/complexity-by-simplicity-a-deep-dive-into-kubernetes-components-4l59
開始一個新專案就像一次冒險起航——對開發人員來說充滿了興奮和挑戰。當您集思廣益並為您的下一件大事規劃功能時，有一個遊戲規則改變者可以讓您的旅程更加順利：API。  為了在不減少預算的情況下為您的專案提供所需的推動力，這裡精選了一系列最佳免費 API。它們就像您值得信賴的伙伴，可以無縫地融入您的工作中，讓您的編碼之旅更加愉快和高效。 ------------------- ### 開源API測試平台 [Firecamp](https://firecamp.dev) 是開源 API 測試工具，可協助您比以往更快地測試 API。 如果您能花 5 秒給我們一顆星，我將非常感激💜  ----- 讓我們深入探討一下： 1.[JSONPlaceholder API](https://jsonplaceholder.typicode.com/) - 幫助開發人員在使用真正的程式之前測試他們的程式。它允許您使用 HTTP 請求建立、變更和刪除虛假資料。 - 可以根據您的需求使用它可以是 JSON、CSV 和 YAML  -------- 2.[OpenWeatherMap API](https://openweathermap.org/api) - 全球任何地點的即時天氣資料。 - 存取目前天氣狀況、預報和歷史資料。 - 非常適合涉及天氣預報、氣候分析或旅行計劃的應用。 -------- 3.[新聞API](https://newsapi.org/) - 總結來自世界各地各種來源的新聞文章。 - 提供即時和歷史資料，包括標題、來源和文章摘要。 - 非常適合需要即時新聞更新、內容聚合或情緒分析的應用程式。 -------- 4.[Unsplash API](https://unsplash.com/developers) - 用於應用程式和網站的高品質、免版稅圖像。 - 存取大量專業照片。 - 非常適合涉及視覺內容、設計或使用者參與的專案。 ------------ 5.[REST國家API](https://restcountries.com/) - 檢索有關國家的訊息，包括人口、面積等。 - 對於涉及地理、教育或文化探索的應用程式很有用。  ------------ 6.[Randomuser.me API](https://randomuser.me/) - 產生隨機用戶資料，包括姓名、地址和個人資料圖片。 - 非常適合在不使用真實用戶資料的情況下測試和原型應用程式。 ------------ 7.[JokeAPI](https://jokeapi.dev/) - 透過大量笑話將幽默融入您的專案中。 - 非常適合娛樂應用程式或為您的網站加入輕鬆的感覺。 ------------ 8.[匯率-API](https://www.exchangerate-api.com/) - 存取各種貨幣的即時和歷史匯率。 - 對於涉及電子商務、金融或旅遊的專案至關重要。 ------------ 9.【NASA開放API】(https://api.nasa.gov/) - 從 NASA 的大量收藏中檢索資料，包括圖像、影片和天文學資料。 - 非常適合教育計畫、太空愛好者或任何對宇宙探索感興趣的人。 ------------ 10.[COVID-19資料API](https://covid19api.com/) - 隨時了解全球 COVID-19 即時統計資料。 - 對於專注於健康、資料視覺化或流行病監測的應用程式很有用。 ------------ 11.[圖書API](https://openlibrary.org/developers/api) - 開放式庫提供了一套 API 來幫助開發人員啟動並執行我們的資料。其中包括 RESTful API，它使 Open Library 資料可以採用 JSON、YAML 和 RDF/XML 格式。 ------------ 這些 API 涵蓋了廣泛的功能，可讓您為專案加入不同的功能，而不會產生額外的成本。 請務必瀏覽他們的文件，以便無縫整合到您的開發工作流程中。 您還記得您為有趣的專案嘗試的第一個 API 嗎？在下面評論並與社區分享。 下週見！！ 🙏 --- 原文出處：https://dev.to/firecampdev/11-free-and-fun-apis-you-must-use-in-your-side-project-219m
如今，軟體開發的最大變化是部署頻率。產品團隊更早（並且更頻繁）地將版本部署到生產中。長達數月或數年的發布週期變得越來越罕見，尤其是對於建立純軟體產品的人來說。 如今，使用服務導向的架構和微服務方法，開發人員可以將程式碼庫設計為模組化。這使他們能夠同時編寫程式碼庫的不同部分並將其部署到程式碼庫的不同部分。 縮短部署週期的商業優勢是顯而易見的： * 縮短上市時間 * 客戶在更短的時間內獲得產品價值 * 客戶回饋也更快回流到產品團隊，這意味著團隊可以更快地迭代功能並解決問題 * 開發人員整體士氣上升 然而，這種轉變也為營運或 DevOps 團隊帶來了新的挑戰。隨著部署更加頻繁，部署的程式碼更有可能對網站可靠性或客戶體驗產生負面影響。這就是為什麼制定程式碼部署策略以最大限度地降低產品和客戶的風險非常重要。 在本文中，我們將討論一些不同的部署策略、最佳實踐和工具，它們將使您的團隊更快*且*更可靠地工作。 --- ## 現代應用的挑戰 現代應用程式通常是分散式且基於雲端的。它們可以彈性擴展以滿足需求，並且由於高可用的架構，對故障的恢復能力更強。他們可以利用完全託管的服務，例如[AWS Lambda](https://aws.amazon.com/lambda/) 或[Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) ，其中平台承擔一些營運責任。 這些應用程式幾乎總是有頻繁的部署。例如，行動應用程式或消費者 Web 應用程式可能在一個月內經歷多次變更。有些甚至每天多次部署到生產中。 他們經常使用微服務架構，其中多個元件協同工作以提供完整的功能。不同的元件可以有不同的發布週期，但它們都必須無縫地協同工作。 活動部件數量的增加意味著出現問題的可能性更大。由於多個開發團隊對整個程式碼庫進行更改，當問題不可避免地發生時，可能很難確定問題的根本原因。 另一個挑戰：基礎設施層的抽象，現在被視為程式碼。新應用程式的部署可能還需要部署新的基礎架構程式碼。 ## 流行的部署策略 為了應對這些挑戰，應用程式和基礎架構團隊應該設計並採用適合其用例的部署策略。 我們將回顧幾種不同的部署策略並討論幾種不同部署策略的優缺點，以便您可以選擇適合您的組織的策略。 ## “大爆炸”部署 顧名思義，「大爆炸」部署會一次更新應用程式的全部或大部分。這種策略可以追溯到軟體在實體媒體上發布並由客戶安裝的時代。 大爆炸部署要求企業在發布之前進行廣泛的開發和測試，通常與大型順序發布的[「瀑布模型」](https://en.wikipedia.org/wiki/Waterfall_model)相關。 現代應用程式的優點是可以在客戶端或伺服器端定期自動更新。對於現代團隊來說，這使得大爆炸方法變得更慢、更不靈活。 大爆炸部署的特點包括： * 所有主要部分都打包在一個部署中； * 用新版本很大程度上或完全取代現有軟體版本； * 部署通常會導致較長的開發和測試週期； * 假設失敗的可能性很小，因為回滾可能是不可能或不切實際的； * 完成時間通常很長，需要多個團隊的努力； * 要求客戶端採取行動更新客戶端安裝。 大爆炸部署不適合現代應用程式，因為對於面向公眾或關鍵業務應用程式來說，風險是不可接受的，因為中斷意味著巨大的財務損失。回滾通常成本高、耗時，甚至不可能。 大爆炸方法適用於非生產系統（例如，重新建立開發環境）或供應商打包的解決方案（例如桌面應用程式）。 ## 滾動部署 滾動、分階段或分步部署比大爆炸部署更好，因為它們最大限度地減少了許多相關風險，包括無法輕鬆回滾的用戶面臨的停機時間。 在滾動部署中，應用程式的新版本逐漸取代舊版本。實際部署需要一段時間。在此期間，新舊版本將共存，不會影響功能或使用者體驗。此過程可以更輕鬆地回滾與舊元件不相容的任何新元件。 下圖顯示了部署模式：叢集中每台伺服器的舊版本顯示為藍色，新版本顯示為綠色。  應用程式套件升級是滾動部署的一個範例。如果原始應用程式部署在容器中，則升級一次可以處理一個容器。每個容器都經過修改，可以從應用程式供應商的網站下載最新的映像。如果其中一個應用程式有相容性問題，舊映像可以重新建立容器。在這種情況下，套件應用程式的新舊版本會共存，直到每個應用程式都升級為止。 ## 藍綠、紅黑或 A/B 部署 這是另一個自動防故障過程。在這種方法中，兩個相同的生產環境並行工作。 一種是目前正在執行的生產環境，接收所有使用者流量（顯示為藍色）。另一個是它的克隆，但閒置（綠色）。兩者都使用相同的資料庫後端和應用程式配置：  新版本的應用程式部署在綠色環境中，並進行功能和效能測試。一旦測試結果成功，應用程式流量就會從藍色路由到綠色。綠色則成為新的產品。  如果綠色生效後出現問題，流量可以路由回藍色。 在藍綠部署中，兩個系統都使用相同的持久性層或資料庫後端。保持應用程式資料同步至關重要，但鏡像資料庫可以幫助實現這一目標。 您可以使用藍色的主資料庫進行寫入操作，並使用綠色的輔助資料庫進行讀取操作。從藍色切換到綠色期間，資料庫會從主資料庫故障轉移到輔助資料庫。如果測試時green也需要寫入資料，資料庫可以採用雙向複製。 一旦綠色變為可用，您可以關閉或回收舊的藍色實例。您可以在這些實例上部署較新的版本，並使它們成為下一個版本的新版本。 藍綠部署依賴流量路由。這可以透過更新主機的 DNS CNAMES 來完成。但是，長 TTL 值可能會延遲這些變更。或者，您可以變更負載平衡器設置，以便變更立即生效。 ELB 中的連線耗盡等功能可用於服務動態連線。 ## 金絲雀部署 金絲雀部署就像藍綠部署，但它更規避風險。您可以使用分階段的方法，而不是一步從藍色切換到綠色。 透過金絲雀部署，您可以在生產基礎架構的一小部分中部署新的應用程式程式碼。一旦應用程式被批准發布，只有少數用戶會被路由到它。這可以最大限度地減少任何影響。 如果沒有報告錯誤，新版本可以逐步推廣到基礎設施的其餘部分。下圖示範了金絲雀部署：  金絲雀部署的主要挑戰是設計一種方法將某些使用者路由到新應用程式。此外，某些應用程式可能始終需要同一組使用者進行測試，而其他應用程式可能每次都需要不同的群組。 考慮透過探索多種技術來路由新用戶： * 在允許外部使用者存取之前，將內部使用者暴露給金絲雀部署； * 基於來源IP範圍的路由； * 在特定地理區域發布應用程式； * 使用應用程式邏輯為特定使用者和群組解鎖新功能。當應用程式對其他使用者上線時，此邏輯將被刪除。 ## 部署最佳實踐 現代應用程式團隊可以遵循許多最佳實踐，將部署風險降至最低： * **使用部署清單。** 例如，清單上的一項可能是「僅在應用程式服務停止後備份所有資料庫」以防止資料損壞。 * **採用持續整合 (CI)。** CI 確保簽入程式碼儲存庫功能分支的程式碼僅在*經過一系列相依性檢查、單元和整合測試以及成功建置。如果路徑中出現錯誤，建置將失敗並通知應用程式團隊。因此，使用 CI 意味著應用程式的每項變更都需要在部署之前進行測試。 CI 工具的範例包括：CircleCI、Jenkins。 * **採用持續交付 (CD)。** 透過 CD，CI 建置的程式碼工件被打包並隨時準備在一個或多個環境中部署。請閱讀我們的[低風險持續交付電子書](https://try.rollbar.com/low-risk-continuous-delivery-guide/) 以了解更多資訊。 * **使用標準作業環境 (SOE)** 以確保環境一致性。您可以使用 Vagrant 和 Packer 等工具來開發工作站和伺服器。 * **使用建置自動化工具來自動化環境建置。** 使用這些工具，通常只需單擊一個按鈕即可輕鬆拆除整個基礎架構堆疊並從頭開始重建。 CloudFormation 就是此類工具的一個範例。 * **在目標伺服器中使用 Puppet、Chef 或 Ansible 等組態管理工具**來自動套用作業系統設定、套用修補程式或安裝軟體 * **使用 Slack 等通訊管道**來自動通知不成功的建置和應用程式故障 * **建立一個流程，用於就部署失敗向負責團隊發出警報。** 理想情況下，您將在 CI 環境中捕獲這些情況，但如果部署了更改，您將需要一種方法來通知負責團隊 * **為執行狀況檢查失敗的部署啟用自動回滾**，無論是由於可用性還是錯誤率問題。 ## 部署後監控 即使您採用了所有這些最佳實踐，事情仍然可能失敗。因此，監控部署後立即發生的問題與規劃和執行完美部署同樣重要。 應用程式效能監控 (APM) 工具可以幫助您的團隊監控關鍵效能指標，包括部署後的伺服器回應時間。應用程式或系統架構的變化會極大地影響應用程式的效能。 像 [Rollbar](http://rollbar.com/) 這樣的錯誤監控解決方案同樣重要。它將快速通知您的團隊部署中的新錯誤或重新啟動的錯誤，這些錯誤可能會發現需要立即關注的重要錯誤。 如果沒有錯誤監控工具，這些錯誤可能永遠不會被發現。雖然少數遇到錯誤的用戶會花時間報告它們，但大多數其他用戶不會。隨著時間的推移，負面的客戶體驗可能會導致滿意度問題，或更糟的是，可能會導致業務交易無法進行。 錯誤監控工具還可以在營運/DevOps 團隊和開發人員之間建立所有部署後問題的共享可見性。這種共同的理解使團隊能夠更加協作和回應。 _原文發佈於 [rollbar.com](https://rollbar.com/blog/deployment-strategies/)_ --- 原文出處：https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
Kubernetes 已成為管理容器化應用程式的首選平台，提供可擴展性、靈活性和穩健性。然而，Kubernetes 的複雜性可能令人望而生畏，需要開發人員和 DevOps 團隊瀏覽複雜的設定檔和命令列互動。 一些強大的開發工具已經出現，以簡化 Kubernetes 叢集的管理並簡化部署流程。在本文中，我們將探討五種 Kubernetes 開發工具： - [**普羅米修斯**](https://prometheus.io/) - [**獨眼巨人**](https://cyclops-ui.com/) - [**科達**](https://keda.sh/) - [**卡本特**](https://karpenter.sh/) - [**帆船**](https://velero.io/) 這些工具提供直覺的使用者介面、自動擴展功能、災難復原解決方案並提高管理 Kubernetes 叢集的效率。 ### 向我們展示您的支持🙏🏻 在我們開始之前，如果您為我們的儲存庫加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興。我們的 GitHub 儲存庫在這裡：https://github.com/cyclops-ui/cyclops ⭐ ## 1. Prometheus：Kubernetes 監控與警報  **Prometheus** 是一款專為微服務和容器設計的開源監控和警報工具包。它提供靈活的查詢、即時通知以及對容器化工作負載、API 和分散式服務的可見性。 Prometheus 的功能之一是它能夠透過偵測可能升級為攻擊的不規則流量或活動來協助雲端原生安全。 它使用基於拉取的系統，發送稱為“scrapes”的 HTTP 請求，從應用程式和服務收集指標。這些指標儲存在記憶體和本機磁碟中，可以輕鬆檢索和分析。 Prometheus 可以直接從客戶端庫或透過匯出器（位於應用程式附近的軟體）存取資料。匯出器接受來自 Prometheus 的 HTTP 請求，確保資料格式相容性，並將請求的資料提供給 Prometheus 伺服器。 Prometheus 提供了四種主要類型的指標：計數器、儀表、直方圖和摘要。這些指標可以靈活地測量應用程式和服務的各個方面，例如事件啟動計數、記憶體使用情況、資料聚合和分位數範圍。 為了發現監控目標，Prometheus 利用 Kubernetes 叢集中的服務發現。它可以獨立於應用程式資訊存取機器級指標，從而實現全面監控。 資料收集完成後，Prometheus 提供了一種名為 PromQL 的查詢語言，使用戶能夠存取監控資料並將其匯出到 Grafana 等圖形介面，或使用 Alertmanager 發送警報。 ## 2. Cyclops：只需點擊幾下即可部署應用程式  **Cyclops** 是一個簡化 Kubernetes 叢集中執行的應用程式管理的工具。它將複雜的設定檔抽象化為基於表單的 UI，從而無需手動配置和命令列互動。這使得具有不同技術專業知識水平的個人更容易存取部署過程。 有了 Cyclops，您就不再局限於一刀切的方法。您可以自訂模組以滿足您的獨特需求，讓您可以自由建立具有輸入驗證的模板，以便與您的團隊無縫協作。 這不僅加快了您的工作速度，還使每個團隊成員能夠獨立工作，從而促進更順暢、更有效率的工作流程。 在 Cyclops 中，每個模組都列出了它使用的資源的詳細清單——部署、服務、pod 等，所有這些都在簡單的視圖中。您可以輕鬆追蹤它們的狀態，幫助您快速發現並修復應用程式中的任何問題。這就像有一個清晰的路線圖來導航和解決出現的任何問題。 在 Cyclops 的架構中，核心元件是 [Helm](https://helm.sh/) 引擎，它允許動態產生配置。該引擎是有效管理 Cyclops 框架中的設定和參數的關鍵機制。 由於基於 Kubernetes 的系統通常使用 Helm 作為套件管理器，因此無縫整合 Cyclops 是一個簡單的流程。 Cyclops 促進部署實踐的一致性和標準化。透過提供預先定義的範本或設定預設，Cyclops 可確保部署遵循既定的最佳實務和指南。這種一致性不僅提高了部署的可靠性和穩定性，而且還促進了協作。 ## 3. Keda：Kubernetes 工作負載的事件驅動自動縮放  Kubernetes Horizontal Pod Autoscaling (HPA) 和 Vertical Pod Autoscaling (VPA) 廣泛用於根據 CPU 和記憶體使用量自動縮放 Kubernetes 叢集。 然而，它們也有局限性，例如無法將 Pod 擴展到零或基於資源利用率以外的指標進行擴展。這就是 **Keda**（Kubernetes 事件驅動的自動縮放）發揮作用的地方。 Keda 是一個開源容器自動縮放器，它透過根據外部事件或觸發器縮放 Pod 來擴展本機 Kubernetes 自動縮放解決方案的功能。 Keda 監控 AWS SQS、Kafka 和 RabbitMQ 等事件來源，根據預定義規則有效觸發或停止部署。這種適應性強的解決方案還允許自訂指標，促進為訊息驅動的微服務量身定制的有效自動擴展，確保最佳效能和資源利用率。 Keda 的元件包括事件來源、縮放器、指標適配器和控制器。事件來源提供觸發擴展的外部事件，而擴展器則監視這些事件並取得指標。指標適配器轉換控制器的指標，然後相應地擴展部署。 透過利用 Keda，DevOps 團隊可以在沒有事件需要處理時縮小規模，從而釋放資源並降低雲端成本。 Keda 還提供與各種 DevOps 工具鏈的互通性，支援內建和外部縮放器。 借助 Keda，自動擴展變得更加靈活和高效，使團隊能夠優化資源利用率並適應不斷變化的工作負載需求。 ## 4. Karpenter：Kubernetes 的自動化節點配置  Kubernetes 叢集經常面臨在可用節點上調度 Pod 的挑戰。 **Karpenter** 是一個開源叢集自動縮放器，可自動配置新節點以回應不可調度的 Pod。它評估待處理 Pod 的聚合資源需求，並選擇最佳實例類型來滿足它們。 Karpenter 還支援整合功能，主動移動 Pod 並以更便宜的版本取代節點，以降低叢集成本。 一個突出的功能是引入“節點池”，允許用戶根據各種標準對節點進行分類。這種客製化確保了客製化的資源分配方法，卡彭特動態地將節點配置到最合適的池中。 Karpenter 的核心旨在無縫地自動擴展 Kubernetes 叢集。 Karpenter 利用 Kubernetes 中的自訂資源定義 (CRD)，與現有工具和 API 無縫集成，為使用者提供熟悉的體驗。 Karpenter 的靈活性超出了 AWS 的範圍，使其成為適用於雲端和本地環境的多功能解決方案。 Karpenter 的適應性體現在它透過 Kubernetes 資源支援使用者定義的策略和策略。這種靈活性使組織能夠使 Karpenter 與其獨特的應用程式和工作負載需求保持一致，從而實現更好的自動化和最佳化的 Kubernetes 可擴展性。 ## 5. Velero：Kubernetes 的災難復原與備份  **Velero** 是一款功能強大的工具，可為 Kubernetes 叢集提供災難復原和備份解決方案。它使用戶能夠輕鬆備份、還原和遷移應用程式及其持久性磁碟區。 Velero 拍攝叢集資源和資料的快照，並將它們儲存在 AWS S3、Google Cloud Storage 或 Azure Blob Storage 等物件儲存提供者中。 借助 Velero，使用者可以建立備份計劃，確保關鍵叢集資源的定期快照。這樣可以在資料遺失或叢集故障時實現高效的災難復原。 Velero 也支援叢集遷移，簡化了在 Kubernetes 叢集之間行動應用程式和資料的過程。 該工具提供資源過濾功能，允許使用者選擇性地備份和還原特定資源。 這種靈活性可確保備份中僅包含相關資料，從而節省儲存空間並減少備份和還原時間。 Velero 與 CSI（容器儲存介面）集成，提供備份磁碟區並將其恢復到原始狀態的支援。 除了災難復原和備份之外，Velero 還提供在任何命名空間中執行、使用掛鉤擴充功能以及支援自訂外掛程式以增強自訂等功能。它提供了診斷和解決常見問題的故障排除指南，確保管理 Kubernetes 叢集的流暢體驗。 ## 結論 這五種 Kubernetes 開發工具 - Prometheus、Cyclops、Keda、Karpenter 和 Velero - 在簡化 Kubernetes 叢集管理的複雜性方面發揮關鍵作用。 從使用Prometheus 進行監控和警報，到使用Keda 進行事件驅動的自動縮放，再到透過Karpenter 進行自動化節點配置，每個工具都可以解決特定的挑戰，從而有助於打造更有效率、更有彈性的Kubernetes環境。 Cyclops 因其用戶友好的方法而脫穎而出，將複雜的配置抽象化為直覺的 UI，而 Velero 則提供重要的災難復原和備份解決方案來保護關鍵資料和應用程式。 由於 Kubernetes 仍然是現代應用程式部署的基石，這些工具使開發人員和 DevOps 團隊能夠更輕鬆地駕馭複雜的容器化環境。 透過將這些工具整合到 Kubernetes 工作流程中，您可以增強可擴展性、簡化部署流程，並確保應用程式在當今動態且要求嚴苛的運算環境中的穩健性。 --- 原文出處：https://dev.to/cyclops-ui/five-tools-to-add-to-your-k8s-cluster-2j89
在上一個發布週期間，我們在 Supabase Studio 的 SQL 編輯器中引入了文字到 SQL。這是我們邁向完整人工智慧助理的第一步。 今天，我們將介紹 Supabase Assistant，這是儀表板內的人工智慧助手，以及一些新功能，可幫助您更快地從創意到生產。 https://youtu.be/hu2SQjvCXIw 這是鳥瞰圖： - **行級安全策略：** 透過 AI 輕鬆實現 - **Postgres 角色：** 更改工作室的 Postgres 角色 - **使用者模擬：**視覺化您的安全策略 - **即時檢查器：**檢查和除錯即時請求 - **功能預覽：** 查看 Studio 中的熱門新聞 ## 介紹 Supabase 助手 我們很高興能夠透過新的 **Supabase Assistant 擴展 Studio 的 AI 功能。** 開發人員告訴我們，SQL 編輯器中的文字到 SQL 功能大大提高了他們的速度（以及他們的 SQL 能力）。當人工智慧與基於模式的資料庫（如 Postgres）結合使用時，它的功能非常強大，因為它可以從模式中推斷出大量上下文，並且資料庫為生成的程式碼提供了更嚴格的保證。我們先前的版本堅定了我們的信念，即人工智慧將成為未來資料庫開發的關鍵部分。 今天，我們在行級安全編輯器中推出了 Assistant 支持，並且很快就會擴展到 Studio 中的其他位置：表編輯器、Postgres 函數、無伺服器函數等。 讓我們先進入行級安全性。  ## 透過 AI 實現簡單的 RLS 策略 在我們收到的所有功能請求中（而且我們收到了很多！），編寫[行級安全性](https://supabase.com/docs/guides/auth/row-level-security)策略的更簡單方法是其中之一最頻繁的。 行級安全性 (RLS) 是 Postgres 的一項功能，可提供對資料庫的細粒度存取。雖然 RLS 很強大，但編寫策略可能是一件苦差事。今天，我們發布了一款基於 AI 的 RLS 編輯器，讓編寫安全策略變得簡單。 新的 RLS 編輯器將 SQL 置於中心位置。我們希望讓開發人員能夠充分發揮 Postgres 的潛力，而不是將其抽象化。這個編輯器其實是兩個工具： 1. SQL 編輯器：如果您非常了解 SQL，那麼有一個新的編輯器可以讓您快速編寫策略。 2. 助手：如果您是 RLS 新手並需要幫助，您可以使用助手並透過它進行聊天。  此助手經過調整，可產生用於行級安全性的 SQL，以便快速、輕鬆地按照您需要的方式設定策略。 我們探索了 RLS 編輯器的各種方法和設計。這種 SQL 優先的方法在人工智慧的幫助下，感覺就像我們一直在尋找的解決方案。現在可以透過功能預覽啟用新的 RLS 編輯器（更多資訊請見下文）。我們很樂意[聽到您的回饋。](https://github.com/orgs/supabase/discussions/19594) ## Postgres 角色 您可能從未想過這一點，但 Studio 就像任何其他 Postgres 用戶端一樣連接到您的資料庫。 它使用預設的[Postgres角色](https://supabase.com/docs/guides/database/postgres/roles)，`postgres`。 「postgres」角色的功能類似於「服務角色」金鑰，授予它對資料庫的管理權限。它具有管理員讀寫權限，並繞過行級安全性。 如果您使用我們的客戶端程式庫，您將熟悉「anon」和「service_role」 API 金鑰。這些鍵實際上解析為 Postgres 角色，也稱為“anon”和“service_role”。這些密鑰實際上是包含 Postgres 角色的 JWT 令牌： ``` { "role": "service_role", // the Postgres role "iss": "supabase" // the issuer of the JWT "exp": 1445385600, // the time the JWT will expire } ``` 如果您可以使用在應用程式中使用的相同 Postgres 角色在 Studio 中執行查詢會怎麼樣？如果您可以讓 Studio 假裝使用與預設「postgres」角色不同的角色怎麼辦？今天，您可以：  您可以使用新的角色下拉清單為 Studio 中的查詢選擇不同的 Postgres 角色。這是一個強大的工具，用於測試行級安全策略並確定每個角色可以存取哪些資料。 讓我們建立一個 Twitter/X 克隆來進行說明。在 Twitter 克隆中，您： - 有一個包含「user_id」和「content」等欄位的推文表。 - 可以設定行級安全性，以便只有推文的作者才能存取和修改自己的推文。 - 只能查看和編輯您撰寫的推文。 當我們使用“postgres”角色進行查詢時，我們可以看到所有資料。當我們使用“anon”查詢時，不會傳回任何資料。這是有道理的，因為我們尚未建立允許「匿名」存取此表的策略。 角色下拉清單解鎖了另一個方便的功能：與 Supabase Auth 結合使用時，它甚至可以假裝是不同的使用者。 ## 使用者模擬 還記得上面的 API 金鑰嗎？它們可以包含一個附加字段：“sub”。這是用戶的 ID。當您使用「authenticated」角色時，「sub」欄位是登入您的應用程式的使用者的ID： ``` { "sub": "348b-some-user-uuid", // the ID of the user "role": "authenticated", // the Postgres role "iss": "supabase" // the issuer of the JWT "exp": 1445385600, // the time the JWT will expires } ``` 我們可以透過使用使用者 ID「建立」JWT，然後使用該 JWT 執行查詢來模擬 Studio 中的使用者。 在我們編寫 RLS 策略以允許用戶查看自己的推文後，讓我們看看它的實際效果。在這裡，我們可以選擇「已驗證」角色，並選擇特定用戶以僅查看他們的推文。以下是我們所有用戶的推文：  表編輯器現在正在模擬我們的用戶。 您可以模擬專案中的任何用戶，並按照他們的方式查看事物。您的 RLS 政策中的任何條件都會自動反映在表中。 ✨ 魔法 ✨ 您可以直接從 Studio 建立 RLS 策略並測試它們是否完全按照您的預期運作。 表格編輯器的樂趣不止於此。我們還為 SQL 編輯器和 GraphiQL 新增了角色支援。讓我們透過嘗試在 SQL 編輯器中選擇我們自己的推文清單來重複上面所做的事情：  在 GraphiQL 中：  將此功能與新的 RLS 編輯器結合，您可以在幾分鐘內使用真實資料編寫和測試 RLS 策略。這使得編寫 RLS 策略的過程變得更快、更容易。如果您有回饋，[我們很樂意聽到。](https://github.com/orgs/supabase/discussions/19595) ## 即時檢查器 Supabase [Realtime](https://supabase.com/realtime) 非常適合建立協作應用程式。您可以透過 Websocket 接收資料庫更改，儲存和同步有關使用者狀態的資料，以及透過「通道」向客戶端廣播任何資料。 今天，我們發布了 Realtime Inspector：一種直接在 Studio 中進行 Realtime 原型設計、檢查和除錯的簡單方法。您可以使用即時檢查器查看通道中發送和接收的訊息。您可以按類型篩選訊息：狀態、廣播和資料庫變更。  當然，我們也在這裡新增了「角色」下拉清單。您可以按角色查看事件並模擬用戶，就像表和 SQL 編輯器一樣。 如果您使用 Realtime，您會發現新的檢查器非常方便。 ## 功能預覽 今天，我們發布了**功能預覽**，這是我們用於推出新功能的工具。在普遍可用之前，我們會以預覽版的形式發布 Beta 功能。您可以看到可用於預覽的功能清單以及螢幕截圖和簡要說明。每個功能都包含一個指向 Github 討論以獲取反饋的連結。 我們對功能預覽有幾個目標。我們想： - 更快地向您提供功能 - 讓您更輕鬆地向我們提供回饋 - 縮短迭代循環 我們越快地迭代您的回饋，我們就能越快將功能發佈到普遍使用中。 雖然我們認為這些功能是測試版，但請注意，我們非常重視您的安全、隱私和資料完整性。我們發佈到預覽版的任何內容都會考慮到這一點進行測試，並且處於我們正在尋找 UX/UI 回饋的階段。 您可以在左下角的使用者頭像選單下找到我們的功能預覽：  目前我們有兩個預覽功能： 1. 我們之前看到的新 RLS 助手：  2. 以及修改後的 API 側面板：  我們將積極關注 Github 討論並回覆您的回饋。 ## 總結 在此更新中，我們在增強您的 Supabase 體驗方面取得了巨大進展。 1. **行級安全策略：** 在新助理的幫助下，我們比以往任何時候都更容易建立行級安全策略。此功能極大地簡化了定義對資料的細粒度存取的過程。 2. **Postgres 角色和使用者模擬：** 我們的新角色選擇器可讓您直接在 Studio 中視覺化安全策略的影響。這使您可以了解不同角色如何與資料交互，從而為測試存取控制提供強大的工具。 3. **即時檢查器：** 使用即時檢查器，您可以原型設計、檢查和偵錯即時訊息。這個工具對於使用 Supabase Realtime 的人來說非常有用。 4. **功能預覽：** 我們推出了功能預覽，為您帶來測試階段的新工具和功能，讓您更輕鬆地提供回饋並塑造開發流程。 這些更新反映了我們對 SQL 優先方法和以使用者為中心的開發的承諾。我們期待您的回饋，我們將繼續努力讓 Supabase 更快、更輕鬆地讓您的想法付諸實現。 ## 更多發布第 X 週 - [Postgres語言伺服器：實作解析器](https://supabase.com/blog/postgres-language-server-implementing-parser) - [Supabase 設計如何運作](https://supabase.com/blog/how-design-works-at-supabase) - [Supabase 專輯](https://www.youtube.com/watch?v=r1POD-IdG-I) - [Supabase 啟動週 X 黑客松](https://supabase.com/blog/supabase-hackathon-lwx) - [啟動週 X 社群聚會](https://supabase.com/blog/community-meetups-lwx) --- 原文出處：https://dev.to/supabase/supabase-studio-ai-assistant-and-user-impersonation-22mn
## **簡介** 在本教程中，您將學習如何使用**現代工具**和**最佳實踐**來監控您的Javascript應用程式。 探索分散式追蹤的力量，並了解如何無縫整合和利用 Odigos 和 Jaeger 等工具來增強您的監控能力。 **您將學到什麼：✨** - 如何在 Javascript 中建立微服務🐜。 - 為微服務設定 Docker 容器📦。 - 配置 Kubernetes ☸️ 以管理微服務。 - 整合追蹤後端以可視化追蹤🔍。 您準備好成為監控 JS 應用程式的**專家**了嗎？ 😍 說**是的，先生！**。 我聽不到你說話。大聲點說。 🙉  *** ## **讓我們設定一下 🦄** > 🚨 在部落格的這一部分中，我們將建立一個虛擬的 JavaScript 微服務應用程式並將其部署在本地 Kubernetes 上。如果您已經有一個並且正在跟進，請隨意跳過這一部分。 為您的應用程式建立初始資料夾結構，如下所示。 👇🏻 ``` mkdir microservices-demo cd microservices-demo mkdir src cd src ``` ### **設定伺服器** 🖥️ > 👀 出於演示目的，我將建立兩個相互通信的微服務，最終我們可以使用它來視覺化分散式追蹤。 - **建置與 Dockerize 微服務 1** 在「/src」資料夾中，建立一個新資料夾「/microservice-1」。在資料夾內初始化 **NodeJS** 專案並安裝所需的依賴項。 ``` mkdir microservice-1 cd microservice-1 npm init -y npm install --save express node-fetch ``` 建立一個新檔案“index.js”並新增以下程式碼： ``` // 👇🏻/src/microservice-1/index.js const express = require("express"); const fetch = require("node-fetch") const app = express(); const PORT = 3001; app.use(express.json()); app.get("/", async (req, res) => { try { const response = await fetch("http://microservice2:8081/api/data"); const data = await response.json(); res.json({ data: "Microservice 2 data received in Microservice 1", microservice2Data: data, }); } catch (error) { console.error(error.message); res.status(500).json({ error: "Internal Server Error" }); } }); app.listen(PORT, () => { console.log(`Microservice 1 listening on port ${PORT}`); }); ``` 伺服器正在偵聽連接埠“3001”，並且在對“/”發出請求時，我們從“microservice2”請求資料並將回應作為 JSON 物件返回。 📦 現在，是時候對這個微服務進行 docker 化了。在“/microservice-1”資料夾中建立一個新的“Dockerfile”並新增以下程式碼： ``` // 👇🏻/src/microservice-1/Dockerfile FROM node:18 # Use /usr/src/app as the working directory WORKDIR /usr/src/app # Copy package files and install production dependencies COPY --chown=node:node package*.json /usr/src/app RUN npm install --production # Copy the rest of the files COPY --chown=node:node . /usr/src/app/ # Switch to the user node with limited permissions USER node # Expose the application port EXPOSE 3001 # Set the default command to run the application CMD ["node", "index.js"] ``` 將我們不想推送到容器的文件加入到“.dockerignore”總是很好。使用我們不想推送的檔案的名稱來建立一個“.dockerignore”檔案。 ``` // 👇🏻/src/microservice-1/.dockerignore node_modules Dockerfile ``` 最後，透過執行以下命令來建構 🏗️ docker 映像： ``` docker build -t microservice1-image:latest . ``` 現在，這就是我們第一個微服務的完整設定。 ✨ - **建置與 Dockerize 微服務 2** 我們將有一個類似於“microservice1”的設置，只是在這裡和那裡進行了一些更改。 在「/src」資料夾中，建立一個新資料夾「/microservice-2」。在該資料夾內，初始化 **NodeJS** 專案並安裝所需的依賴項。 ``` mkdir microservice-2 cd microservice-2 npm init -y npm install --save express node-fetch ``` 建立一個新檔案“index.js”並新增以下程式碼： ``` // 👇🏻/src/microservice-2/index.js const express = require("express"); const fetch = require("node-fetch") const app = express(); const PORT = 3002; app.use(express.json()); app.get("/api/data", async (req, res) => { const url = "https://jsonplaceholder.typicode.com/users"; try { const response = await fetch(url); const data = await response.json(); res.json(data); } catch (error) { console.error(error.message); res.status(500).json({ error: "Internal Server Error" }); } }); app.listen(PORT, () => { console.log(`Microservice 2 listening on port ${PORT}`); }); ``` 伺服器正在偵聽連接埠 3002，根據對“/api/data”的“GET 請求”，我們從“jsonplaceholder”獲取資料並將回應作為 JSON 物件傳回。 📦 現在，是時候對這個微服務進行 docker 化了。複製並貼上「microservice1」的整個「Dockerfile」內容，然後將連接埠從 3001 變更為 3002。 另外，新增一個「.dockerignore」檔案並包含我們在建立「microservice1」時新增的相同檔案。 最後，透過執行以下命令來建構 🏗️ Docker 映像： ``` docker build -t microservice2-image:latest . ``` 現在，這也是我們第二個微服務的完整設定。 ✨ - **設定 Kubernetes** > 確保已安裝 **[Minikube](https://github.com/kubernetes/minikube)** 透過執行以下命令建立新的本機 Kubernetes 叢集。我們在設定 Odigos 和 Jaeger 時將需要它。 **啟動 Minikube：🚀** ``` minikube start ``` 現在我們已經準備好並 Docker 化了兩個微服務，是時候設定 Kubernetes 來管理這些服務了。 在專案的根目錄下，建立一個新資料夾「/k8s/manifests」。在此資料夾中，我們將為兩個微服務新增部署和服務配置。 - **部署設定📜**：用於在 Kubernetes 叢集上實際部署容器。 - **服務配置📄**：將 Pod 暴露給叢集內部和叢集外部。 首先，我們為「microservice1」建立清單。建立一個新檔案「microservice1-deployment-service.yaml」並新增以下內容： ``` // 👇🏻/k8s/manifests/microservice1-deployment-service.yaml apiVersion: apps/v1 kind: Deployment metadata: name: microservice1 spec: selector: matchLabels: app: microservice1 template: metadata: labels: app: microservice1 spec: containers: - name: microservice1 image: microservice1-image # Make sure to set it to Never, or else it will pull from the docker hub and fail. imagePullPolicy: Never resources: limits: memory: "200Mi" cpu: "500m" ports: - containerPort: 3001 --- apiVersion: v1 kind: Service metadata: name: microservice1 labels: app: microservice1 spec: type: NodePort selector: app: microservice1 ports: - port: 8080 targetPort: 3001 nodePort: 30001 ``` 此配置部署了一個名為「microservice1」的微服務，其資源限制為 **200MB 記憶體** 🗃️ 和 **0.5 個 CPU 核心**。它透過部署在連接埠 3001 上公開微服務，並透過服務在 **NodePort** 30001 上公開微服務。 > 🤔 還記得我們用名稱「microservice1-image」建構的「Dockerfile」嗎？我們使用相同的映像來建立容器。 可透過集群內的連接埠 8080 存取它。我們假設「microservice1-image」透過「imagePullPolicy: Never」在本地可用。如果沒有到位，它將嘗試從 Docker Hub 🐋 中提取映像並失敗。 現在，讓我們為「microservice2」建立清單。建立一個名為「microservice2-deployment-service.yaml」的新檔案並新增以下內容： ``` // 👇🏻/k8s/manifests/microservice1-deployment-service.yaml apiVersion: apps/v1 kind: Deployment metadata: name: microservice2 spec: selector: matchLabels: app: microservice2 template: metadata: labels: app: microservice2 spec: containers: - name: microservice2 image: microservice2-image # Make sure to set it to Never, or else it will pull from the docker hub and fail. imagePullPolicy: Never resources: limits: memory: "200Mi" cpu: "500m" ports: - containerPort: 3002 --- apiVersion: v1 kind: Service metadata: name: microservice2 labels: app: microservice2 spec: type: NodePort selector: app: microservice2 ports: - port: 8081 targetPort: 3002 nodePort: 30002 ``` 它與“microservice1”的清單類似，只有一些更改。 👀 此配置部署一個名為「microservice2」的微服務，並透過部署在連接埠 3002 上將其內部公開，並透過服務在 **NodePort** 30002 上將其外部公開。 可透過叢集內的連接埠 8081 進行存取，假設「microservice2-image」可透過「imagePullPolicy: Never」在本地使用。 全部完成後，請確保套用這些設定並使用這些服務啟動 Kubernetes 叢集。將目錄更改為`/manifests`並執行以下命令：👇🏻 ``` kubectl apply -f microservice1-deployment-service.yaml kubectl apply -f microservice2-deployment-service.yaml ``` 執行以下命令檢查我們的兩個部署是否正在**執行**：👇🏻 ``` kubectl get pods ```  最後，我們的應用程式已準備就緒，並使用必要的部署配置部署在 Kubernetes 上。 🎉 *** ## **安裝 Odigos 😍** > 💡 [**Odigos**](https://odigos.io/) 是一個開源可觀察性控制平面，使組織能夠建立和維護其可觀察性管道。  > ℹ️ 如果您在 Mac 上執行，請執行以下命令在本地安裝 Odigos。 ``` brew install keyval-dev/homebrew-odigos-cli/odigos ``` > ℹ️ 如果您使用的是 Linux 計算機，請考慮透過執行以下命令從 GitHub 版本安裝它。確保根據您的 Linux 發行版更改該檔案。 > ℹ️ 如果 Odigos 二進位檔案不可執行，請在執行安裝指令之前執行此指令 `chmod +x odigos` 使其可執行。 ``` curl -LJO https://github.com/keyval-dev/odigos/releases/download/v1.0.9/cli_1.0.9_linux_amd64.tar.gz tar -xvzf cli_1.0.9_linux_amd64.tar.gz ./odigos install ```  > 如果您需要有關其安裝的更多簡短說明，請按照此[**連結**](https://docs.odigos.io/installation)操作。 現在，Odigos 已準備好執行 🎉。我們可以執行它的 UI，配置追蹤後端，並相應地發送追蹤。 *** ## **將 Odigos 連接到追蹤後端 💫** > 💡 [**Jaeger**](https://github.com/jaegertracing/jaeger) 是一個開源的端對端分散式追蹤系統。  ### **設定 Jaeger！** ✨ 在本教程中，我們將使用 **Jaeger** 🕵️♂️，這是一個流行的開源平台，用於查看微服務應用程式中的分散式追蹤。我們將用它來查看 Odigos 生成的痕跡。 > 有關 Jaeger 安裝說明，請點選此 [**link**](https://www.jaegertracing.io/download/)。 👀 若要在 Kubernetes 叢集上部署 Jaeger，請執行下列命令：👇🏻 ``` kubectl create ns tracing kubectl apply -f https://raw.githubusercontent.com/keyval-dev/opentelemetry-go-instrumentation/master/docs/getting-started/jaeger.yaml -n tracing ``` 在這裡，我們建立一個「tracing」命名空間，並在該命名空間中為 Jaeger 應用部署配置📃。 此命令設定自託管 Jaeger 實例及其服務。 👀 執行以下命令來取得正在執行的 pod 的狀態：👇🏻 ``` kubectl get pods -A -w ``` 等待所有三個 Pod 都 **正在執行**，然後再繼續。  現在，要在本地查看 Jaeger Interface 💻，我們需要進行連接埠轉送。將流量從本機電腦上的連接埠 16686 轉送至 Kubernetes 叢集中選定 pod 上的連接埠 16686。 ``` kubectl port-forward -n tracing svc/jaeger 16686:16686 ``` 此命令在本機電腦和 Jaeger pod 之間建立一條隧道，公開 Jaeger UI，以便您可以與其互動。 最後，在瀏覽器上開啟「 http://localhost:16686 」並查看 Jaeger 實例正在執行。  ### **設定 Odigos 與 Jaeger 一起工作！** 🌟 > ℹ️ 對於 Linux 用戶，請前往從 GitHub 版本下載 Odigos 二進位檔案的資料夾，然後執行以下命令來啟動 Odigos UI。 ``` ./odigos ui ``` > ℹ️ 對於 Mac 用戶，只需執行： ``` odigos ui ``` 造訪“ http://localhost:3000 ”，您將看到 Odigos 介面，您將在“default”命名空間中看到您的部署。  選擇這兩個選項並點擊“下一步”。在下一頁上，選擇 Jaeger 作為後端，並在出現提示時加入以下詳細資訊： - **目的地名稱🛣️**：提供您想要的任何名稱，例如說**快速追蹤**。 - **端點🎯**：為端點加上`jaeger.tracing:4317`。 就是這樣 - Odigos 已準備好向我們的 Jaeger 後端發送痕跡。就是這麼簡單。 🤯  *** ## **查看分散式追蹤 🧐** 設定 Odigos 後，在 Jaeger 主頁「 http://localhost:16686 」上，您將已經看到列出的兩個微服務。  Odigos 已經開始向 Jaeger 發送我們的應用程式痕跡。 😉 請記住，這是我們的微服務應用程式。由於以「microservice1」為起點，因此再向「microservice1」發出一些請求，隨後它將向「microservice2」請求資料並傳回。最終，Jaeger 將開始填滿這些痕跡。  點擊任一請求，您應該能夠觀察請求如何流經您的應用程式以及完成每個請求所需的時間。 這一切都是在沒有更改一行程式碼的情況下完成的。 🤯 一切都感謝 **Odigos**！ 🤩  想像一下，這只是一個很小的虛擬應用程式，但對於一個執行著大量微服務並相互交互的更大的應用程式來說，分散式追蹤將非常強大！ 💪 透過分散式跟踪，您可以輕鬆辨識應用程式中的瓶頸，並確定哪個服務導致問題或花費更長的時間。 🕒 *** ## **讓我們總結一下！ 🥱** 到目前為止，您已經學習如何使用 **Odigos** 作為應用程式和追蹤後端 **Jaeger** 之間的 **中間件**，透過分散式追蹤來密切監控 👀 Javascript 應用程式。 👏 如果您已經做到了這一步，請拍拍自己的背。 🥳你值得擁有！ 😉 本教學的源程式碼可在此處取得： https://github.com/keyval-dev/blog/tree/main/odigos-monitor-JS-like-a-pro > 如果您對本文有任何疑問或建議，請在下面的評論部分分享。 👇🏻 那麼，這就是本文的內容。感謝您的閱讀！ 🎉🫡 --- 原文出處：https://dev.to/odigos/monitor-your-javascript-application-like-a-pro-581p
在任何領域，無論是藝術、體育還是軟體開發，達到頂峰的最快方法就是研究那些已經處於頂峰的人……並做他們正在做而你沒有做的事情。 如果您以編寫程式碼為生，這意味著要考慮一下高級開發人員。這意味著確定他們擁有哪些你不具備的技能、習慣和特質。 在過去 3 年裡與全球頂尖軟體工程師一起工作了數千個小時之後，我發現您現在就可以實施 12 種高級開發人員特質，以快速將您的成長提升到一個新的水平。 讓我們從第一開始… ## 1. 專注 專注意味著對某些事情說不，這樣我們就可以做其他事情。 理想情況下，對不重要的事情說不。並對那些能帶來改變的事情說「是」。使船移動得更快的東西。 這對許多開發人員來說確實很難，因為它違背了我們的本能。這意味著接受你無法完成所有事情。並不是每個機會都是平等的。 你不可能學習所有新的框架。您無法閱讀所有時事通訊。您不可能參加所有會議。而你不必這樣做。 你的時間有限。你的能量也是如此。 成為高級開發人員意味著選擇你的戰鬥。  > 「人們認為專注意味著對你必須關注的事情說『是』。但這根本不是這個意思。這意味著對其他一百個好主意說不。” ——史蒂夫‧賈伯斯 有趣的是，你選擇的越好，你進步的速度就越快。高級開發人員每天都有 24 小時的時間。但他們做得更多。 如何？ 透過少做事。 當新事物出現時，問問自己“這真的很重要嗎？”或者這只是另一個趨勢？很可能這只是另一個偽裝成機會的干擾。  高級開發人員說的「不」多於「是」。他們完成的專案比開始的專案還要多。他們在學習新框架之前先掌握已經使用的框架。如果你想更快進入高級，你需要培養的第一個特質就是專注。 ## 2. 二階思維 讓「初級開發者」尖叫的一件事是「讓我們建造它，我們會找到結果」的態度。年輕人傾向於先編碼，後思考。 如果您剛開始，這可能是一個很好的態度，但是當您開發可用於生產的軟體時，您將無法更改一些技術決策。或者很容易改變。 例如，您選擇Vue作為前端框架。 然後，需求會改變。你開始認為 React 會是更好的選擇。當然，你可以切換到 React。但這既不容易，也不便宜。 資深開發人員知道，靠自己的供應很容易獲得快感。但是，如果您愛上了您最了解的框架和函式庫，您將開始做出糟糕的技術決策。  他們會三思而後行，考慮自己選擇的後果。這可能意味著在嘗試理解問題時詢問「五個為什麼」。 或考慮他們的解決方案可能存在的缺點。 例如，現在我們新增了 Redux，全域狀態可能更容易管理。但我們必須在 Redux 上招募新的開發人員。學習曲線很高。 而且，你猜怎麼著，我們的 JavaScript 套件會變得更大，這對效能不利。 考慮二階環境將使您成為更好的開發人員。它還將在技術面試中為您提供幫助。 🚨 PS您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3GJuOjr) 🚨 ## 3.實用主義 當初級開發人員閱讀一本關於最佳實踐的書時，他們會跳起來並嘗試將它們應用到任何版本中的每一行程式碼。他們虔誠地追隨他們。 如果您無法自己做出技術決策，那麼遵守預先定義的規則會容易得多。但軟體開發不是一種宗教。 一個很好的例子是測試。 當初級開發人員閱讀 TDD（測試驅動開發）時，他們將開始嘗試測試所有內容。旨在實現完整的程式碼覆蓋率。事實上，完整的程式碼覆蓋率會帶來遞減的結果，並且最終會浪費時間。  高級開發人員知道如何平衡最佳實踐和上市時間。何時走捷徑，何時不走捷徑。 快速破解會產生錯誤和技術債。當程式碼上下文發生變化時，始終遵守規則會導致錯誤的決策。 你需要一個平衡。 根據情況重新考慮您的技術選擇。 ## 4. 沒有什麼好證明的 由於缺乏自信，初級開發人員發現自己不斷地試圖向他人證明自己。與對自己的價值和技能缺乏安全感的高級開發人員一樣。 他們的信心是建立在他人的認可之上。 這是一場失敗的遊戲。 他們會嘗試在某個技術討論、與他人交談或在深夜或週末推送程式碼時展示自己了解多少。 事實上，所有這些行為都會造成有毒的團隊環境並適得其反。在最好的情況下，他們會讓你看起來比實際情況更高級。  獵豹不需要在比賽中證明自己，它只是為了狩獵而奔跑。 有兩種方法可以解決這個問題。 第一個是停止在外部驗證上花費太多。因為事實是你不需要向任何人證明自己。只對你自己。 第二是與頭腦中的負面聲音和平相處。 你可以成為你最嚴厲的批評者。完美主義、對失敗的恐懼以及對「真正的」開發人員的錯誤認知正在摧毀你的自尊。這就是為什麼無論你多努力，你總是感覺功虧一簣。 是時候擺脫你的頭腦了。 專注於掌握你的手藝，剩下的就會水到渠成。您將立即對自己和自己的技能更加自信。你將不再試圖向陌生人證明自己。 ## 5. 掌握基礎知識 每當我在 LinkedIn 上看到開發人員的個人資料，並且他們將自己描述為「React」開發人員或「Angular」開發人員時，我就知道他們不是高級開發人員。他們可能是該框架中的高級人員，但總體而言不是高級人員。 框架開發人員永遠不會成為高級開發人員。 框架不會讓你成為高級，因為框架只是錦上添花。不是蛋糕本身。冰山一角與其底部。  我甚至推測，目前軟體開發人員中冒充者症候群盛行的背後，甚至是高階開發人員的背後，並不是缺乏天賦，也不是缺乏努力。 這是基本面薄弱。 這也是為什麼除錯或效能優化等主題對於大多數開發人員來說是一個猜謎遊戲。他們不習慣深入挖掘他們正在使用的庫和工具的表面。 要成為高級開發人員，您不僅必須了解事物背後的“什麼”，還必須了解事物背後的“原因”。 例如，高級開發人員不僅能夠建立 React 應用程式。但他們也會理解為什麼 React 是以某種方式建構的。以及它如何與編寫的語言（JavaScript/TypeScript）和執行的平台（Web 瀏覽器）融合。 好訊息是，一旦你掌握了基本原理，一切的水平都會上升。 🚨 PS您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3GJuOjr) 🚨 ## 6. 端對端交付 公司避開初級開發人員的第一大原因是他們需要大量外部協助才能完成工作。外部幫助意味著您將打擾高級開發人員來完成您的工作。 初級開發人員被認為“昂貴”，因為他們無法獨立交付。 相反，高級開發人員可以提供端到端的服務。給他們一堆要求，他們會解決剩下的問題。這並不意味著他們是獨狼，而且他們通常非常擅長團隊合作。 這並不意味著高級開發人員快速破解事物只是為了推動它們前進。 那不是「真正的」前輩。 這並不意味著他們深入了解軟體開發生命週期的每個部分。 但是，高級開發人員了解整個軟體開發生命週期的所有主要部分。並且可以為其中的每一個（前端、後端、部署）做出貢獻。 如果您是想要升級的初級/中級開發人員，那麼端對端交付是您需要關注的特徵。 ## 7. 心智模型 高級開發人員與初級開發人員的主要區別之一是他們可以處理的複雜性。 老年人可以理解更複雜的程式碼庫和需求。 他們可以理解二階環境。程式碼庫的變化將如何影響效能、成本甚至團隊。 他們這樣做並不是因為他們記住了每個實作細節。這是不可能的，因為人類的記憶非常有限。 他們這樣做是因為他們將程式碼的複雜度抽象化為心理模型。這些都是表示現實的簡單方法。 開發人員如何建構高品質的心理模型？ 透過查看框架和庫的背後並學習它們背後的設計模式。根據您的技術堆棧，存在著許多噪音。諸如 SOLID 原則或 MVC 之類的東西... 但我認為最好的開始方法是選擇您正在使用的任何框架並嘗試超越程式碼。  開始問自己，為什麼框架的建立者要這樣建構它？它是建立在新概念的基礎上還是只是古老原則的實現（通常是這種情況）？ 透過回答這些問題，您將建立軟體開發的思維模型，並能夠處理更多的複雜性。這是快速成長為高級開發人員的最有效方法之一。 🚨 PS您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3GJuOjr) 🚨 ## 8. 資深開發人員控制故事 高階開發人員可以做得非常好的一件事是領導技術討論並影響周圍的其他人。無論是業務利害關係人、產品經理或其他開發人員，資深開發人員都知道如何引導他們朝著正確的方向發展。 他們結合自信、技術專長和溝通技巧來做到這一點。 高級開發人員也能夠設定嚴格的界限。 他們可以不同意而不會情緒激動。他們可以在會議期間為自己（和他人）挺身而出。他們積極協商薪資。 他們講述自己的故事。  高級開發人員知道如何以及何時在沙子上劃線並說“夠了”。 如果另一個開發人員在程式碼審查期間開始指責其他人，老年人知道如何阻止他們。如果高階主管試圖介入開發人員的工作並進行微觀管理，高階管理層知道如何在不破壞關係的情況下阻止他們。 沒有關於如何變得更加自信的開發人員的分步指南。 這需要重複和練習。第一步是停止一直說「是」。並開始嘗試在薪資談判中取得進展。 ## 9. 長期思考 初級開發人員考慮“現在”。他們的想法是短期的。當他們走捷徑時，他們的程式碼也是如此。初級開發人員會擴展一段程式碼，而不考慮正確重構它，或乾脆忽略測試和效能。 但青年人也會對自己的職業生涯進行短期思考。 這可能意味著跳槽過多或自毀前程。這可能意味著忽視。 就像不提高你的技能或推銷自己的方式一樣，因為現在你的工作很穩定。只是被解僱六個月後才後悔。 成為更高級的開發人員的一部分是開始進行長期思考。 第一個方法是改變你的心態。大多數初級開發人員的短期思維不是由懶惰引起的，而是由自我懷疑引起的。 他們內心深處仍在思考成為開發人員是否適合他們。或者他們是否選擇了正確的職業。 這些疑慮阻止他們做出長期承諾。  好事需要時間，資深開發人員知道這一點並相應地調整他們的想法。 現在，隨著人工智慧威脅到軟體開發的終結，這種短期思維比以往任何時候都更加頻繁。如果某件事很快就會消失，為什麼還要承諾呢？ 相信我，只有當我完全致力於我作為開發人員的職業生涯時，事情才開始起飛。 我說：「就是這樣」。 我不再向外張望。我告訴自己：這是我現在的工作，也是我未來十年的工作，所以讓我把它做好吧。 我開始投資我的技能，因為現在我知道它們會得到回報。 即使你未來 20 年不打算寫程式碼，擁有長遠的心態也會為你帶來巨大的好處。高級開發人員之所以能夠達到高級水平，是因為他們致力於自己的技術。如果您渴望實現這一目標，您也應該這樣做。 🚨 PS您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3GJuOjr) 🚨 ## 10.卓越是一種習慣 我想正是 Kent Beck 說過那句名言：「我不是一個偉大的程式設計師，只是一個有著好習慣的好程式設計師」。習慣很重要，因為它們經得起時間的考驗。 因為您擁有的任何關於 JavaScript 框架的知識遲早都會過時。技術變革。但你的習慣將永遠伴隨你。 好訊息是人類是習慣的動物。 在我們的大腦中設定新的慣例並不容易。 但一旦我們將它們內化為習慣，我們就很容易堅持下去。利用這一點的最佳方法是實現您的任何目標並將其分解為日常行動。然後透過重複將這些行為變成習慣。 例如，如果您想更好地進行測試，請每天編寫一個單元測試。 如果您想在日常會議中做好更多準備並清晰思考，請寫日記。如果你想找到一份新的開發人員工作，並且你必須發送 100 份申請，那麼每天發送 10 份申請。 養成新的習慣，你向高級水準的進步將持續且穩定。 ## 11. 保護您最重要的資產 身為高階開發人員意味著不僅要長遠考慮您的程式碼和技術決策，還要考慮您的健康。 因為健康就是財富。 我在影片中一次又一次地談論這一點。 開發人員的工作需要久坐。您一天的大部分時間都坐在電腦前的椅子上。這對你的健康非常不利。 然後，辦公室裡到處都是垃圾食品，像是薯條、汽水和糖果。這意味著除非您有意識地努力，否則您將很難保持健康和體形。 但如果你想擁有一個長期而富有成效的軟體編寫職業，並且不想最終出現背部問題、糖尿病，甚至更糟糕的情況，那麼你需要開始照顧自己的健康。  欲得金蛋，勿殺鵝。如果你想提高工作效率，首先要照顧好自己。 這並不意味著您必須開始每週去健身房 5 次。 或進行一些瘋狂的節食。但每周至少2至3次運動。您可以去健身房、跑步或參加團隊運動。現在我正在做 在飲食方面，減少糖和精緻碳水化合物的攝取。肉也不要過量。 也要考慮您的心理健康。 忽略諸如「吃飯、睡覺、編碼、重複」之類的建議，在工作之外建立自己的生活。 開始一個新的嗜好。聯繫朋友。休息一下。 從短期來看，你的進步可能會慢一些。但從長遠來看，你將能夠在遊戲中停留更長時間。 🚨 PS您是否希望快速晉升為擁有優質資源、回饋和責任的高階開發人員？ [點擊此處加入我們的免費社區 - 高級開發學院。](https://bit.ly/3GJuOjr) 🚨 ## 12. 閉合圓圈 最後，資深開發人員了解業力是如何運作的。他們知道，無論他們多麼努力，或者多麼聰明，在他們走向頂峰的道路上，都有數十個人的幫助。 這並沒有剝奪他們的優點，但也承認其他人。 所以他們關閉了這個圈子。 他們幫助其他開發人員。他們這樣做是沒有期望的。 不是因為它可能會讓你升職。或是地位，或是仰慕。他們這樣做是因為這是正確的事。  甚至科比·布萊恩也抽出時間來指導年幼的孩子並讓他們進入籃球領域。您也可以抽出時間來幫助新開發人員。 幫助剛起步的人會帶給你部分火花。初學者第一次看到事物時所感受到的熱情和好奇心是如此具有感染力。 另一件你可以變成日常習慣的事情！ 好的，就是這樣。具備這 12 個特徵，您將快速成長到高級甚至更高級別。 --- 原文出處：https://dev.to/dragosnedelcu/12-senior-developer-traits-junior-developers-need-to-master-285m
毫無疑問，掌握 Web 開發最有效的方法之一就是透過實作。雖然學習理論概念很重要，但將您的知識應用到現實世界的專案中才能真正鞏固您的技能。無論您是想要打下堅實基礎的初學者，還是尋求新挑戰的經驗豐富的開發人員，這裡有 25 個 Web 開發專案可以提高您的能力。 ### 學生成績管理系統 學生成績管理系統旨在為學生和大學提供一種快速且用戶友好的方式來存取和管理考試成績。學生可以登入查看他們的成績，新生可以選擇註冊。該系統旨在以易於理解的方式呈現結果。 **如何做：** 掌握前端、後端和資料庫程式設計的基礎知識後，從建立全端應用程式開始。利用HTML、CSS、JavaScript、PHP和MySQL實現使用者認證、結果顯示和註冊功能。  ### 線上程式碼編輯器（React） 該專案涉及使用 React 建立線上程式碼編輯器，允許使用者用各種程式語言編寫和執行程式碼。目標是建立一個用戶可以無縫編輯和測試原始程式碼的平台。 **如何做：** 先使用 HTML、CSS 和 React 進行前端工作。實現程式碼輸入、執行和結果顯示功能。專注於建立用戶友好的介面，以獲得流暢的程式碼編輯體驗。  ### 使用 React 進行 Amazon 克隆 Amazon Clone 專案圍繞著使用 React 建立 Amazon 線上商店的工作副本。該專案將幫助您了解有效的電子商務網站所需的元件並將它們應用到您的應用程式中。 **如何做：** 從 HTML、CSS 和 JavaScript 開始。使用 React 建立電子商務網站的不同部分，例如產品清單、購物車和結帳流程。整合動態資料並增強使用者介面。  ### 客戶關係經理 客戶關係管理器專案涉及建立一個後端 Web 應用程式，該應用程式允許建立、讀取、更新和刪除 (CRUD) 客戶資料。這是了解後端 Web 開發的基礎專案。 **如何做：** 利用 Node.js、Express.js 和 MongoDB 等技術來建立後端基礎架構。實施 CRUD 操作來管理客戶資料。開發一個用戶友好的介面，用於與客戶資料庫互動。  ### 排序展示台 排序可視化器專案旨在提供各種排序演算法的可視化表示。使用者可以觀察不同的演算法如何執行，並更深入地了解 JavaScript 的基本概念。 **具體操作方法：** 使用 HTML、CSS、Bootstrap 和 JavaScript 建立 Web 應用程式。實現冒泡排序、合併排序和快速排序等排序演算法的視覺化。允許用戶與視覺化進行交互，以增強他們的學習體驗。  ### 多人遊戲 – Connect4 多人遊戲 – Connect4 專案專注於建立具有多人遊戲功能的著名 Connect4 遊戲。它提供了學習一些重要的網路和遊戲設計基礎知識的機會。 **如何做：** 如果您想知道多人遊戲是如何開發的，或者您曾經想為週末製作一款遊戲，那麼這個專案適合您。使用 PyGame、Sockets 和遊戲編程為您和您的朋友建立多人 Connect4 遊戲。  ### YouTube 腳本摘要器 投入時間觀看可能比預期更長的電影變得相當具有挑戰性。有時，如果我們不能從他們那裡收集有用的訊息，我們的努力可能會徒勞無功。透過自動總結影片的文字記錄，我們可以輕鬆地發現這些影片中的關鍵主題，這節省了我們再次觀看整個影片的時間和精力。 **如何做到這一點：** 人們每天都會觀看 YouTube 影片，這些影片可以是指導性的、紀錄片的或任何其他持續時間較長的類型；考慮透過提供摘要資訊可以節省多少時間。該專案將是一個 chrome 擴展，它將向後端的 Rest API 發送請求，該 API 將向您發送 YouTube 腳本的摘要。  ### OurApp – NodeJS 中的社交媒體 Web 應用程式 現實應用程式 OurApp 的用戶可以進行交流、相互關注以及發布簡短的推文。掌握 HTML、CSS 和 JS 後，專案最適合想要使用 Nodejs 和 MongoDB 深入研究完整堆疊的人。 **怎麼做：** 你想成為能夠超越 HTML、CSS 和 JS 的全端開發人員嗎？建立這個完整的堆疊應用程式，以了解如何使用 NodeJS、MongoDB 和其他技術來建立現代、快速且可擴展的伺服器端 Web 應用程式。如果您想在磨練 NodeJS 技能的同時開發一些有趣的東西，那麼這個專案就是適合您的。您還可以免費註冊全端 Web 開發課程，這將幫助您成為您所在領域的傑出開發人員。  ### Codechef 通知 CodeChef 經常遇到伺服器過載問題，導致評審難以快速提供提交結果。留給編碼人員的唯一選擇是在一段時間後不斷檢查站點，看看結果是否存在。透過這個專案，我們希望消除審查提交頁面以確定提交結果的額外步驟。我們將自動執行檢索結果的過程並在準備好後立即通知使用者。 **如何操作：** Codechef 是一個流行的編碼實踐平台，但伺服器過載可能會導致結果延遲。此附加元件旨在透過自動化獲取結果並及時通知用戶的流程來節省時間。使用網路抓取或 API 來收集結果資訊並實作通知系統。  ### 使用 Dash 來視覺化和預測股票 該專案涉及使用 Dash（一種用於建立分析 Web 應用程式的 Python 框架）來視覺化和預測股票資料。它提供了將資料視覺化和機器學習概念應用於金融資料的機會。 **如何操作：** 如果您對股票市場感興趣，該專案將簡化股票資料的可視化。利用Python、Dash和相關函式庫進行資料視覺化。實施基於歷史資料預測股票趨勢的功能。  ### 線上程式碼編輯器 (JQuery) 線上程式碼編輯器可透過瀏覽器存取，並位於遠端伺服器上。儘管一些線上程式碼編輯器更像是完整的 IDE，但其他編輯器更像是具有語法突出顯示或程式碼完成等基本功能的文字編輯器。 **如何操作：** 使用 HTML、CSS、JavaScript 和 JQuery 建立線上程式碼編輯器。專注於透過語法突出顯示和程式碼完成等功能來增強使用者體驗。確保程式碼輸入和執行順利。  ### 模糊URL FuzzyURLs 涉及使用 Django（Python 的高級 Web 框架）建立 URL 縮短服務。它提供了建立 Web 應用程式的實務經驗，特別關注 URL 操作。 **如何做：** 從頭開始開發一個基於 Django 的 URL 縮短器。了解 URL 縮短服務的工作流程並實現建立、管理和重新導向短 URL 的功能。  ### 使用 React 進行 Slack 克隆 該專案旨在使用 React 建立 Slack 克隆，提供即時訊息和協作的平台。這是一個中高階專案，強調React-Redux和Firebase。 **如何做：** 應用 React-Redux 原理來建立一個類似 Slack 的 Web 訊息服務。利用 Firebase 實現即時資料庫功能。專注於建立響應靈敏且功能豐富的訊息傳遞應用程式。  ### Web 應用程式的 Node.js 驗證 了解使用 Node.js 為 Web 應用程式建立驗證系統。探索各種身份驗證技術，評估其優點和缺點，並實施改進。 **如何做：** 對於那些想要深入研究 Node.js 並了解建立安全身份驗證系統的複雜性的人來說，這個專案非常適合。實施使用者身份驗證、會話管理並探索增強安全性的方法。  ### TinyMCE 同義詞插件 為 TinyMCE 富文本編輯器建立一個插件，用於搜尋單字的同義詞並允許使用者將它們插入編輯器中。 **如何做到這一點：** 為 TinyMCE 開發一個自訂插件，整合一項功能，使用戶能夠搜尋同義詞並輕鬆地將它們插入到富文本編輯器中。了解 TinyMCE API 以實現無縫整合。  ### 迷宮裡的老鼠 建立一個基本的 React Web 應用程式，顯示老鼠從帶有預設障礙的方形迷宮的左上角到右下角可以採取的所有可能路徑。 **具體操作方法：** 建立一個簡單的 React Web 應用程式來直觀地呈現經典的 Rat in the Maze 謎題。實施功能來展示老鼠穿過迷宮的所有潛在路徑。  ### 簡歷產生器 Web 應用程式 使用 ReactJS 和 NodeJS 建立一個用於建立履歷的 Web 應用程式。該專案將指導您完成建立簡歷產生器的步驟，並提供一種實用的方法來支援個人製作簡歷。 **如何做：** 深入研究 ReactJS 和 NodeJS 來開發一個用戶友好的簡歷產生器。實施加入個人詳細資訊、教育背景、工作經驗和技能的功能。專注於建立動態且可自訂的履歷模板。  ### Markdown 編輯器 建立一個 Markdown 編輯器，讓使用者編寫 Markdown 並預覽渲染的 HTML。 Markdown 是一種基於網路的文字格式化系統，廣泛用於部落格文章、文件等。 **如何做：** 使用 HTML、CSS 和 JavaScript 開發 Markdown 編輯器。使用戶能夠編寫 Markdown 程式碼並查看渲染的 HTML 的即時預覽。使用粗體文字、圖像和清單等功能增強編輯器。  ### 450 DSA 追蹤器 450 DSA Tracker 旨在協助使用者追蹤解決 450 道資料結構和演算法問題的進度。它利用 TypeScript、React.js 的 reducer 和 context API 以及即時瀏覽器 IndexedDB 來快取資訊。 **具體操作方法：** 使用 TypeScript 和 React.js 實作 Web 應用程式，以追蹤解決資料結構和演算法問題的進度。利用reducer 和context API 進行狀態管理，並利用IndexedDB 進行即時瀏覽器快取。  ### 待辦事項網頁應用程式 使用 Node.js 框架 Adonis.js 建立待辦事項 Web 應用程式。了解 HTTP、REST API 和 CRUD 操作，同時建立用於管理待辦事項清單的後端 API。 **如何操作：** 使用 Adonis.js 為待辦事項 Web 應用程式建立 CRUD API。使用 Postman 測試 API 並建立用於新增、更新和刪除任務的後端功能。獲得使用後端框架的經驗。  ### 兩個真相和一個謊言遊戲 Slack 機器人 開發一個 Slack 機器人，用於在 Slack 工作區中玩「兩個真相和一個謊言」遊戲。該專案利用 JavaScript 和 Node.js 為工作區成員建立一個有趣的互動式遊戲。 **如何做：** 建立一個 Slack 機器人，以促進「兩個真相和一個謊言」遊戲。使用 JavaScript 和 Node.js 處理 Slack 工作區中的互動。實現用戶共享陳述並猜測哪一個是錯誤的功能。  ### 使用 Chromakey（綠幕）效果進行即時視訊處理 探索視訊處理中使用的色度（綠幕）效果。使用 HTML、CSS 和 JavaScript 建立 Web 應用程式，以背景影片或圖像取代綠幕。 **具體操作方法：** 開發一個處理即時視訊並應用色鍵效果的 Web 應用程式。使用 HTML、CSS 和 JavaScript 操作影片幀並用背景影片或圖像替換綠幕。  ### WhatsApp 網頁克隆 使用 React 和 Firebase 開發具有即時訊息功能的 WhatsApp Web 克隆。 **如何操作：** 使用 React 建立使用者介面並使用 Firebase 實現即時資料庫功能，打造流暢的訊息體驗。  ### WhatsApp 上的電子郵件提醒 設定新電子郵件的 WhatsApp 提醒以簡化電子郵件管理和通知。 **如何操作：** 使用自動化平台 Twilio 建立一個工具，從收件匣中獲取詳細資訊並在 WhatsApp 上發送警報。  ### 天氣預報應用程式 使用 Streamlit 函式庫和 OpenWeatherMap API 為天氣預報應用程式建立響應式前端。 **如何操作：** 利用 Python 和 Streamlit 可視化天氣資料並與 OpenWeatherMap API 互動以獲取即時天氣資訊。  ### 總結 這個 Web 開發專案的彙編提供了各種各樣的挑戰，使您能夠提高跨不同技術和概念的技能。無論您對全端開發、資料視覺化、遊戲設計還是自動化感興趣，這些專案都可以提供有價值的幫助 --- 原文出處：https://dev.to/mukeshkuiry/25-web-development-projects-you-must-work-on-2024-4onl
*乾淨的架構*在許多方面都未能滿足我的期望。儘管 Martin 先生對這個主題表現出明顯的熱情，但「清潔架構」組織得很差，缺乏範例，並且對使用現有系統保持沉默。作者錯過了一個重要的機會來教導我們何時以及如何將這些經驗教訓應用到我們自己的系統中。讓我解釋。 ### *乾淨的架構*是一本組織得很差的書 這本書需要很長時間才能開始。關於設計範式（結構化、物件導向和函數式）的章節似乎特別不合時宜且不必要。 關於 SOLID 原則的章節很好。我很高興看到這些原則被分解並得到很好的解釋。我發現思考它們對系統架構的適用性很有趣。但鮑伯叔叔提出了諸如硬性規則之類的堅實原則，這讓我感到不舒服。事實上，我非常確定一個***從未***違反 SOLID 原則的系統將是一個巨大的混亂。 然而，第 137 頁的這一段很重要： >架構的主要目的是支援系統的生命週期。良好的架構使得系統易於理解、易於開發、易於維護、易於部署。最終目標是最小化系統的生命週期成本並最大化程式設計師的生產力。 這是一個很好的觀察。叔叔鮑伯為什麼不把它放在第一章呢？ ### 例子不夠多 本書中幾乎沒有任何例子。第 33 章包含一個討論影片銷售電子商務應用程式的範例。沒關係。但我並沒有明確地知道如何將這些概念應用到我自己的系統中。 附錄講述了 Bob 叔叔如何提出 SOLID 原則和乾淨架構規則的故事。它載有過去專案的範例。我認為這是本書**最有趣的部分**。 ### 這本書沒有提到改進現有系統的架構 大多數開發人員將大部分時間花在現有系統上。因此，我期望 *[Clean Architecture](https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164/)* 充滿有關改進現有系統的建議。但這本書在這個問題上顯然隻字不提。 ### 如何建立一個乾淨的架構？ 在本書的前半部分中，您將了解如何透過遵循 SOLID 原則將系統沿系統邊界分解為元件來建立一個乾淨的架構（我是這樣解釋的）。如果你停止閱讀那裡，你可能會有這樣的印象：叔叔鮑伯不會批准你為建築所做的一切，這是可以理解的。如果你認為他提出的幾個選項是「正確」的做事方式，這也是情有可原的。然而，在本書的最後，您將在第 228 頁讀到： >這個例子旨在顯示架構邊界無所不在。作為建築師，我們必須小心地辨識何時需要它們。我們也必須意識到，如果完全實施這些邊界，其成本是昂貴的。 >同時，我們必須認識到，當這些邊界被忽略時，即使存在全面的測試套件和重構規則，以後加入它們的成本也會非常昂貴。 >那我們建築師該怎麼辦？答案令人不滿意。一方面，多年來，一些非常聰明的人告訴我們，我們不應該預見抽象的需要。這就是 YAGNI 的哲學：“你不會需要它。”這句話充滿智慧，因為過度設計往往比設計不足更糟。另一方面，當您發現確實需要一個不存在的架構邊界時，加入這樣一個邊界的成本和風險可能會非常高。 >所以你已經得到它了。軟體架構師啊，你必須看見未來。你必須聰明地猜測。您必須權衡成本並確定架構邊界在哪裡，哪些應該完全實現，哪些應該部分實現，哪些應該被忽略。 因此，在本書的一半以上，他說應該由我們來決定我們的系統的邊界在哪裡。這種界限可能無所不在。令人困惑，對吧？ ### 這本書缺少什麼 因此，如果軟體架構的最終目標是最小化系統的生命週期成本，那麼一本關於架構的書不應該幫助架構師做出這些決策嗎？ #### 未解答的問題 這本書給我留下了很多未解答的問題。各種選擇的經濟學討論在哪裡？如何找到最適合我的系統的架構？研究在哪裡？  我該如何決定水平分層、垂直切片或其他方式是否可以最大限度地降低系統的生命週期成本？或者，如果我沒有明確定義的層，我該如何決定哪種分層策略（如果有）可以最大限度地降低我的生命週期成本？ 我還有更多問題。如果您改進現有系統架構的時間有限，您應該把精力放在哪裡？將資料庫與業務邏輯分開總是一個好主意嗎？您應該始終遵循哪些建議？哪些建議取決於系統？ #### 讓*乾淨的架構*更有價值的細節 在*[Code Complete](https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/)*中，Steve McConnell 討論了不同非功能性需求（例如可靠性、可靠性）之間的權衡、正確性、可維護性、可讀性等。他解釋了一些需求如何協調一致而另一些需求如何衝突。我很樂意看到類似的東西用於本書中討論的架構決策。 在*清潔架構*中，專案規模、團隊規模、專案失敗的後果、預期程式碼生命週期和其他重要因素作為架構的驅動因素沒有得到足夠的重視。例如，Healthcare.gov 需要比您正在開發的個人待辦事項清單更多的架構，即使它們都是由資料庫支援的 Web 應用程式。 ### 這本書的真正內容是什麼 本書的大部分內容我都感到有些困惑。我有點明白叔叔鮑伯想說什麼。但直到讀了附錄才完全明白。那麼，讓我為您節省一些時間。 #### 一個例子 想像一下您正在為消費市場建立一台桌上型電腦（例如辦公室電腦）。您可以選擇硬件，然後為整個系統編寫軟體（韌體、作業系統、驅動程式、應用程式等）。 #### 你會寫一個整體嗎？ 你會怎樣做呢？您會編寫一個巨大的程式（一個整體），其中電子表格的程式碼知道您為電腦選擇的磁碟類型嗎？您能否想像更新電子表格程式碼並在各處新增「if」語句，以便在您有 SATA 磁碟機時執行一件事，而在有 SCSI 磁碟機時執行另一件事？然後對 VGA、DVI 和 HDMI 視訊做同樣的事情？ PS/2 與 USB 滑鼠輸入的不同路徑怎麼樣？然後對文字處理器和您打算與電腦捆綁的所有其他應用程式重複該過程？ 維護這將是一場惡夢，對嗎？那麼解決方法是什麼呢？建築學！您的電子表格不應該知道您使用的是哪種滑鼠。也不知道你有什麼樣的顯示器。它應該完全忘記這些細節。 #### 計算機中的邊界 如果您查看計算機，您會發現這一點。您的滑鼠中有嵌入式軟體，可以與作業系統進行通訊。然而，詳細資訊對您的應用程式是隱藏的。您的電子表格接受標準化輸入，而無需知道或關心您使用的滑鼠類型。然後，當有人發明了新的輸入裝置（例如觸控板）時，它會自動與您的電子表格配合使用。 這只是計算機的邊界之一。您可能會想出數百個。您可以指派不同的團隊來處理系統的不同部分。您可以為不同元件互動的各種方式建立或採用不同的規格。 此時你可能會說「呃」。顯然，您不希望每次硬體發生變化時都更改並重新編譯電子表格。維護將是一場惡夢。並且我同意。 #### 邊界是你的朋友（如果你正確使用它們） 很容易看出硬體邊界。但使硬體邊界變得有價值的相同邏輯也適用於軟體邊界。軟體邊界更難看到。 因此，您可以從在螢幕上顯示電子表格的能力開始。但您可能還想將其儲存到磁碟、儲存為 PDF、儲存為 CSV 或列印。因此，電子表格程式的邊界之一可能是擁有代表每個電子表格的內部資料結構。然後將該結構傳遞給不同的程式碼，以所需的格式顯示、儲存或列印它。 如果您讓資料結構完全不知道它是如何顯示、保存或列印的，那麼您可以在以後加入「儲存到 XML」功能，而無需深入研究與電子表格資料結構相關的所有程式碼。如果電子表格資料結構有幾百萬行程式碼，您可以想像這會容易得多。 這就是鮑伯叔叔在本書中試圖告訴我們的全部。 **您可以使用 SOLID 原則在系統中建立邊界，隱藏實作細節、降低複雜度並幫助您降低系統的總生命週期成本**。 ### 一本更好的軟體架構書 在許多方面，Martin Fowler 的*[企業應用程式架構模式](https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/)* 遠遠優於*清潔架構* 。 Fowler 描述了他在企業應用程式中反覆觀察到的模式。他給出了每個模式的簡單範例，描述了它的工作原理以及在何處使用它。我發現“企業應用程式架構模式”非常可讀並且適用於我的系統。 ### 要點 *乾淨的架構*中有有價值的訊息，但你必須努力找到它。 我發現有關嵌入式軟體的章節是最容易理解的章節之一。直觀上，避免在整個程式碼庫中分散低階呼叫是有意義的。在沒有硬體的情況下使邏輯可測試也是有意義的（特別是因為嵌入式軟體通常是在硬體可用之前開發的）。如果您只能閱讀本書的兩章，我建議您閱讀這一章和附錄，無論您以編寫哪種軟體為生。 總的來說，《乾淨的架構》是一本很難讀的書，鮑伯叔叔留給我的問題比答案還多。我絕對不會推薦這本書作為您關於軟體架構的第一本書（請查看*[企業應用程式架構模式](https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ )* 由馬丁·福勒取代）。 *同意還是不同意。我很想聽聽你的想法。* *喜歡這篇文章嗎？請在下面“喜歡”它。* --- 原文出處：https://dev.to/bosepchuk/why-i-cant-recommend-clean-architecture-by-robert-c-martin-ofd
多年來圍繞著評論存在著許多爭論。許多人堅持認為“好的程式碼會自我註釋”，而其他人則贊成在程式碼中包含好的註釋，並認為應該需要它們。當我閱讀和聽到這些爭論時，我注意到他們經常關注程式碼的*什麼*和*如何*......即。程式碼*做什麼*，以及*如何*做到這一點。但「為什麼」的概念很少進入討論…即。 *為什麼*需要這段程式碼，或是*為什麼*要這樣寫。儘管雙方都有有效的論據，但很難知道該往哪個方向走。這促使我建立了 3 條規則，我相信這不僅有助於彌合兩者，而且還能鼓勵編寫更好的程式碼。我想與您分享我的 3 條規則，希望它們能像我一樣對您有所幫助。 ## 規則 1：名稱要解釋*什麼*  程式碼中的變數、參數、介面、函數、類別、方法或其他「事物」的名稱應提供足夠的訊息，以清楚地描述該事物的「什麼」功能或它所具有的「什麼」值。另一個開發人員應該能夠在幾週或幾個月後讀取該事物的名稱，並準確地知道它的功能或它所擁有的內容，而無需詢問、查看額外的程式碼或閱讀額外的文件。如果這樣做，則應更改名稱以使其更清晰。 為了在這裡澄清一點，重要的是要注意名稱不負責描述某些東西的“用途”。名稱僅負責描述該事物的“做什麼”，或該事物所具有的“什麼”價值。 讓我們來看一些我個人遇到的例子來幫助澄清這一點： ``` const derivatives = []; ``` 只知道這個名字，你就能知道這個陣列裡會保存什麼樣的資料嗎？顯然它包含了從其他東西複製或改編的東西......但是這些資訊足夠嗎？試著退一步思考，如果您在正在編寫的某些程式碼中遇到此問題，您會問自己或其他人甚麼樣的問題。 ``` function name(user) { // ... } ``` 這裡我們有一個函數正在執行與用戶名相關的操作...現在，無需閱讀其他程式碼或向某人詢問更多上下文，您能說出這個函數的作用嗎？ 當我遇到這個問題時，我必須查看更多程式碼才能弄清楚它做了什麼......在我問“這是否返回名稱？”，“這是否會更新名稱？”或“這是否構造來自其他資料的名字？” 希望您能看到上面的範例不是好名稱，需要更改，因為它們不符合此規則的要求。您將不得不查看更多程式碼或詢問其他人來弄清楚他們做什麼或持有*什麼*。那什麼是更好的名字呢？顯然，我們可以使用很多不同的名稱，但這裡有幾個例子： ``` const derivativeUsers = []; ``` 透過這個更新後的名稱，我們現在可以知道該陣列將容納一定數量的從其他陣列複製或改編的用戶。無需閱讀額外的程式碼或詢問其他人。哈札！ ``` function getFullName(user) { // ... } ``` 在這裡，我們更改了函數的名稱，以更清楚地說明該函數的*什麼*功能。透過這個簡單的更新，我們現在知道該函數傳回傳遞給它的使用者的全名。 因此，總結第一條規則，您在程式碼中命名的任何內容都應該清楚地描述該事物的*什麼*，或*什麼*值（如果成立）。這可能會讓你的名字變得更冗長一些，但在我個人看來，如果更冗長一點意味著程式碼對你和團隊來說更具可讀性和可維護性，那麼這是值得付出的代價。 ## 規則 2：程式碼應解釋*如何*  雖然事物的名稱告訴了它“做什麼”，但它內部的程式碼應該描述它“如何”做到這一點。現在，這可能聽起來有點明顯，但它帶來了一些您必須考慮的事情。 為了讓其他人理解程式碼「如何」執行某些操作，它必須具有可讀性和可理解性。如果沒有人能夠理解執行*操作*的程式碼，那麼它的好處就會少很多。其中一部分來自於組成程式碼的各個部分的命名。但有助於程式碼可讀和理解的其他因素包括簡單性、組織和結構、格式和樣式，僅舉幾例。 這是一個很大的話題，有很多關於它的文章、書籍和課程，所以我不會在這裡討論太多細節。只需要知道，編寫乾淨的程式碼是編寫可讀且可理解的程式碼的一個非常重要的部分，它可以讓團隊的其他成員知道「如何」某件事是如何做到的。 另一個難題是模組化。如果某個東西很小並且只做一件事，那麼理解它是如何做的就容易多了。您可能在您的職業生涯中以某種形式聽說過這個概念。也許您熟悉單一職責原則，即 [SOLID 原則] 中的「S」(https://www.goodreads.com/book/show/25936819-design-principles-and-design-patterns) 。如果您還不熟悉，我強烈建議您研究一下，因為它是軟體開發領域的重要概念。但回到正題。如果一個函數、類別、方法、元件或其他任何東西執行不只一件事，則程式碼的複雜性會急劇增加，並且不僅辨識*如何*它是如何做到的，而且隨著時間的推移，維護它也會變得更加困難。 因此，為了使您的程式碼符合第二條規則，您或團隊的其他成員必須在幾個月後能夠理解它。他們應該能夠查看某些“事物”的程式碼，並能夠輕鬆辨識它“如何”執行其功能。為了實現這一點，我們必須編寫乾淨、可讀、可理解的程式碼。 ## 規則 3：評論應該解釋*為什麼* 最後，當需要更多資訊時，當我們需要了解「什麼」和「如何*」之外的內容時，我們需要「為什麼」…這就是評論來拯救世界的地方。當我們編寫程式碼時，有時我們需要傳遞更多訊息，例如「為什麼」做出決定、「為什麼」需要一段程式碼或與之相關的一些其他上下文。這些都是應該評論的事情。 在編輯不是立即顯而易見的特定程式碼區塊時，可能需要考慮一些晦澀的用例。這應該被清楚地註釋，這樣當下一個開發人員下週、下個月甚至明年返回這段程式碼時，他們也會考慮到這些訊息，而不是重新引入一些錯誤，或破壞其他一些部分的功能。 也許由於某些第三方依賴項的工作方式，必須在程式碼的特定區域執行一些不「正常」的操作。與其期望團隊的其他成員遇到同樣的問題並必須自己解決，不如對情況進行評論，以節省他們以後的時間（可能是幾個小時甚至幾天）。 理解「為什麼」某件事以這種方式完成可以提供巨大的洞察力，特別是當有多種路徑可供選擇時，或者如果存在影響決策的間接背景。在我個人看來，評論“為什麼”不僅僅是程式碼中的“很好”，而且至關重要。它對於可維護性、知識共享至關重要，最重要的是對於幫助團隊其他成員成功至關重要。 知道何時應包含“為什麼”有時可能很困難。大多數人，包括我自己，都忘記了我們擁有別人所沒有的知識和理解。我們在生活中假設或期望其他人要么知道這些東西，要么很容易弄清楚……即使我們花了幾個月的時間收集不同的資訊來獲得這些知識。因此，當您編寫下一段程式碼時，請真正退一步思考一下，您認為下一個開發人員將擁有哪些資訊來理解它？然後，在評論中寫下這些內容。 ## 結論 嗯，就是這樣…保存程式碼的 3 個簡單規則。因此，下次當您在流程中編寫下一個重要功能時，請嘗試記住... 1. 命名應該解釋您的程式碼的*什麼*功能。 2. 程式碼本身應該是可讀且易於理解，以便您和其他人可以輕鬆辨識它*如何*執行它正在執行的操作。 3. 使用註解提供所有額外訊息，以便每個人都知道*為什麼*程式碼是這樣編寫的。 希望這3條規則對你的職涯有幫助！下次見，駭客快樂！ --- 原文出處：https://dev.to/wraith/my-3-rules-for-documenting-code-2f54
碰巧有些 Linux 終端機命令很難記住，將它們作為備忘單保存在電腦或紙上是一個很好的做法。此列表並不詳盡，但包含最常用的命令。請隨意在下面的評論中加入您最常用的命令並分享此列表✌️。 ## 用戶 - **Id** – 有關使用者的詳細資訊（uid、gid 和群組）。 - **last** – 列出有關最近登入的訊息，包括時間、使用者名稱、IP 位址和會話持續時間。 - **who** – 顯示授權使用者。 - **groupadd "testgroup"** – 建立一個名為「testgroup」的群組。 - **adduser NewUser** – 新增名為「NewUser」的使用者。 - **userdel NewUser** – 刪除名為「NewUser」的使用者。 - **usermod NewUser** – 修改使用者「NewUser」的資訊。 ## 目錄導航 - **cd /**- 導覽至根目錄。 - **cd** - 導航到主目錄（使用 $HOME 變數）。 - **cd /root** - 導覽至 /root 目錄。 - **cd ..** - 向上移動一級。 - **cd /root/.ssh** - 導航到隱藏資料夾 .ssh。 ## 使用文件 - **ls -al** – 顯示目前資料夾中的檔案和目錄。 - **pwd** – 顯示目前工作目錄。 - **mkdir NewFolder** – 建立一個名為「NewFolder」的新目錄。 - **rm NewFile** – 刪除名為「NewFile」的檔案。 - **rm -f NewFile** – 強制刪除名為「NewFile」的檔案。 - **rm -r NewFolder** – 遞歸刪除名為「NewFolder」的目錄。 - **rm -rf NewFolder** – 強制遞歸刪除名為「NewFolder」的目錄。 - **cp oldfile1 newfile2** – 將「oldfile1」的內容複製到「newfile2」。 - **cp -r olddir1 newdir2** – 遞歸地將目錄「olddir1」複製到「newdir2」。如果 Dir2 不存在，則會建立它。 - **mv oldfile1 newfile2** – 將「oldfile1」重新命名為「newfile2」。 - **ln -s /etc/log/file logfile** – 建立到檔案的符號連結。 - **touch newfile** – 建立一個名為「newfile」的空白檔案。 - **cat > newfile** – 取得 STDIN 並將其放入「newfile」中。 - **head newfile** – 輸出檔案「newfile」的前 10 行。 - **tail newfile** – 輸出「newfile」的最後 10 行。 - **gpg -c newfile** – 使用密碼以 gpg 格式加密「newfile」並將其儲存在同一目錄中。 - **gpg newfile.gpg** – 解密 gpg 檔案。 - **wc newfile** – 顯示新檔案中的位元組數、字數和行數。 ## 檔案/目錄權限 - **chmod 777 /root/ssh** – 為有權存取伺服器的每個人（擁有者、群組、其他人）設定讀取、寫入和執行權限。 - **chmod 755 /root/ssh** – 將擁有者的權限配置為 rwx，將群組和其他人的權限配置為 r_x。 - **chmod 766 /root/ssh** – 設定擁有者的 rwx 以及群組和其他人的 rw。 - **chown newuser newfile** – 將 newfile 的擁有者改為 newuser。 - **chown newuser:newgroup newfile** – 將 newfile 的擁有者和群組擁有者變更為 newuser 和 newgroup。 - **chown newuser:newgroup newfolder** – 將目錄 newfolder 的擁有者和群組擁有者變更為 newuser 和 newgroup。 - **stat -c “%U %G” newfile** – 顯示 newfile 的使用者和群組擁有者。 ## 搜尋 - **grep searchargument newfile** – 在 newfile 中搜尋 searchargument。 - **grep -r searchargument newfolder** – 遞歸搜尋 newfolder 中所有檔案中的 searchargument。 - **定位新檔案** – 顯示新檔案的所有位置。 - **find /etc/ -name "searchargument"** – 在 /etc 目錄中尋找名稱以 searchargument 開頭的檔案。 - **find /etc/ -size +50000k** – 在 /etc 目錄中尋找大小大於 50000k 的檔案。 ## 檔案 - **tar -cf archive.tar newfile** – 從檔案「newfile」建立檔案「archive.tar」。 - **tar -xf archive.tar** – 提取檔案「archive.tar」的內容。 - **tar -zcvf archive.tar.gz /var/log/** – 從 /var/log/ 目錄建立檔案並使用 gzip 對其進行壓縮。 - **gzip newfile** – 壓縮新檔案（副檔名為 .gz）。 ## 從套件中安裝程式 - **rpm -i pkg_program.rpm** – 在 CentOS、RHEL 等上安裝 RPM 軟體包。 - **rpm -e pkg_name** – 刪除 CentOS、RHEL 等上的 RPM 軟體包。 - **dnf install pkg_name** – 在 CentOS、RHEL 等上使用 DNF 從儲存庫安裝軟體包。以前使用 YUM，但最近已被 DNF 取代。 - **dpkg -i pkg_name** – 從 Debian、Ubuntu、Mint 等上的 DEB 軟體包安裝。 - **dpkg -r pkg_name** – 刪除 Debian、Ubuntu、Mint 等上的 DEB 軟體包。 - **apt install pkg_name** – 在 Debian、Ubuntu、Mint 等上從儲存庫安裝軟體套件。 - **apt remove pkg_name** – 移除 Debian、Ubuntu、Mint 等上的軟體套件。 - **apt update && apt update** – 更新系統中的軟體包（Debian、Ubuntu、Mint 等）並更新儲存庫。 ## 流程 - **ps** – 顯示目前正在執行的進程。 - **ps aux | grep 'bash'** – 尋找 'bash' 的程序 ID (PID)。 - **pmap -x 11** – 在進程記憶體中映射 PID 11 的進程。 - **top** – 顯示所有正在執行的進程。 - **kill pid** – 透過 PID 終止進程。 - **killall process** – 終止名為「process」的所有程序。 - **pkill process-name** – 按名稱向程序發送訊號。 - **bg** – 將掛起的程序傳送到背景。 - **fg** – 將正在執行的進程帶到前台。 - **fg process** – 將名為「process」的進程帶到前台。 - **lsof** – 列出進程開啟的檔案。 - **renice 19 PID** – 設定進程的最低優先權。 - **pgrep bash** – 尋找「bash」的進程 ID。 - **pstree** – 顯示進程的樹狀表示。 ## 系統 - **uname** – 顯示系統資訊。 - **uname -r** – 顯示有關 Linux 核心的資訊。 - **hostname** – 顯示主機名稱。 - **hostname -i** – 顯示主機的 IP 位址。 - **date** – 顯示日期和時間。 - **timedatectl** – 輸出和修改日期和時間設定。 - **cal** – 顯示日曆。 - **w** – 顯示目前登入的使用者。 - **whoami** – 顯示您的使用者名稱。 - **finger root** – 顯示有關 root 使用者（需要使用「apt-get install Finger」的資訊進行安裝）。 ## 硬體指令 - **dmesg** – 在啟動期間顯示系統訊息。 - **cat /proc/cpuinfo** – 顯示有關處理器的資訊。 - **cat /proc/meminfo** – 顯示有關記憶體的資訊。 - **lshw** – 顯示有關裝置的詳細資訊。 - **lsblk** – 顯示有關區塊裝置的資訊。 - **free -m** – 釋放記憶體：RAM 和交換（切換 -m 表示 MB）。 - **lspci -tv** – 在樹狀圖視圖中顯示 PCI 裝置資訊。 - **lsusb -tv** – 在樹狀圖視圖中顯示 USB 裝置。 - **dmidecode** – 顯示有關 BIOS 設備的資訊。 - **hdparm -i /dev/xda** – 顯示有關磁碟的資訊。 - **hdparm -tT /dev/xda** – 顯示 xda 的讀寫速度。 - **badblocks -s /dev/xda** – 執行壞扇區測試。 ## 光碟管理指令 - **df -h** – 顯示已安裝分割區上的可用空間（以位元組為單位）。 - **df -i** – 顯示檔案系統中的空閒 inode。 - **fdisk -l** – 提供有關磁碟、分割區和檔案系統的資訊。 - **du -sh** – 顯示已安裝分割區上的未分配空間（以 MB、GB、TB 為單位）。 - **findmnt** – 顯示所有安裝點。 - **mount /dev/sdb1 /mnt** – 將 sdb 磁碟的分割區 1 掛載到 /mnt 目錄。 ## 網絡 - **ip addr show** – 顯示所有可用網路介面的 IP 位址。 - **ip address add 192.168.0.1/24 dev eth0** – 將位址 192.168.0.1 指派給 eth0 介面。 - **ifconfig** – 顯示所有可用網路介面的 IP 位址。 - **ping 192.168.0.1** – 發送 ICMP 協定請求以連接到 192.168.0.1 處的節點。 - **whois 網域** – 顯示有關網域的資訊。 - **dig 網域 **– 檢索有關網域的 DNS 資訊。 - **dig -x 192.168.0.1 ** – 執行反向 DNS 解析。 - **host serverspace.us** – 解析主機位址。 - **hostname -I ** – 顯示本機位址。 - **wget file_name（連結到檔案）** – 下載檔案。 - **netstat -pnltu ** – 顯示主機上正在偵聽的所有連接埠（需要「apt-get install net-tools」）。 ## 遠端連線 - **ssh root@host** – 以 root 使用者身分透過 ssh 連線到遠端主機。 - **ssh -p port_number user@host** – 使用非預設 ssh 連接埠連接到遠端主機，指定使用者。 - **ssh host** – 使用目前使用者的預設連線。 - **telnet host** – 使用 telnet 連線（連接埠 23）。 --- 原文出處：https://dev.to/serverspace/linux-commands-cheat-sheet-aif
想要 **在 2024 年掌握前端 Web 開發？** 無論您是渴望開始前端開發之旅還是希望提升您的技能，我們都能滿足您的需求。 這裡有 9 個令人興奮的專案，它們將使您能夠在 2024 年掌握前端開發。為了加速您的學習過程，每個專案都配有專用資源。 讓我們深入研究並將您的編碼願望變成現實！ 🚀 ### 1. 說故事作品集網站 建立一個引人入勝的說故事作品集網站來展示您的技能和專案。使用動畫和過渡來吸引訪客。 **您將學到什麼：** 該專案將提高您建立個人作品集、將動畫與 CSS 和 JavaScript 結合的能力。您還將透過網頁設計深入了解如何有效地講述故事。 **技術堆疊：** HTML、CSS、JavaScript、GSAP（GreenSock 動畫平台）。 **資源：** [說故事作品集教學](https://youtu.be/0fYi8SGA20k?si=lgzXlqL7m2aK3nzg)  ### 2. 電影搜尋應用程式 使用 React Hooks 建立電影搜尋應用程式。用戶可以搜尋電影、查看詳細資訊並發現新上映的電影。 **您將學到什麼：** 透過這個專案，您將掌握使用 React Hooks 進行狀態管理、非同步資料擷取和響應式設計。此外，您還將深入了解如何處理使用者輸入和管理複雜的資料結構。 **技術堆疊：** React Hooks、Axios、CSS（flexbox/grid）和電影資料庫（IMDB）API。 **資源：** [電影搜尋應用程式教學](https://www.freecodecamp.org/news/how-to-build-a-movie-search-app-using-react-hooks-24eb72ddfaf7/)  ### 3. 任務管理應用程式 開發具有任務建立、完成追蹤和類別組織等功能的任務管理應用程式。 **您將學到什麼：** 該專案將加深您對 React 中的狀態管理、CRUD 操作以及用於任務管理的使用者友好介面的實現的理解。 **技術堆疊：** React、useState、useEffect、localStorage、CSS。 **資源：** [任務管理應用教學](https://youtu.be/m4MDt7UUu1w?si=EcCbIMtkmHZIsWPS)  ### 4. 互動式履歷表產生器 建立一個互動式履歷產生器來展示您的職業歷程。包括教育、工作經驗和技能部分。 **您將學到什麼：** 透過這個專案，您將掌握表單處理、動態內容呈現和建立互動式使用者介面的藝術。這是提高你的 React 技能的絕佳機會。 **技術堆疊：** React、表單處理、CSS（樣式元件）。 **資源：** [互動式履歷產生器播放清單](https://youtube.com/playlist?list=PLrL9i_Ka3T0caA37TXSlicITQl1pp_3Ry&si=UhftAkbYr_eYaxJZ)  ### 5.產品落地專案 開發一個產品登陸頁面，重點宣傳特定產品或服務。針對各種螢幕尺寸實施響應式設計。 **您將學到什麼：** 本專案將加深您對響應式網頁設計的理解，包括媒體查詢、Flexbox 和網格佈局。您還將提高建立具有視覺吸引力的登陸頁面的技能。 **技術堆疊：** HTML、CSS（Flexbox/Grid）、響應式設計。 **資源：** [產品登陸頁面教學](https://youtube.com/playlist?list=PL07efmqYWHZ8jroJAkkFB2s4ZKpVNCOQa&si=ZI375j0QMaN7rpdn)  ### 6. 使用 GitHub API 的個人資料頁面 建立一個個人資料頁面，從 GitHub API 取得資料，顯示使用者資訊、儲存庫和貢獻熱圖。 **您將學到什麼：** 該專案將增強您使用 API、處理非同步資料以及建立具有視覺吸引力的使用者設定檔的技能。您還將獲得將第三方 API 整合到應用程式中的經驗。 **技術堆疊：** React、GitHub API、CSS。 **資源：** [GitHub API 設定檔教學](https://dev.to/falanatolu/using-github-api-to-fetch-and-display-a-github-user-profile-26g6)  ### 7.響應式部落格網站 開發一個響應式部落格網站，其中包含針對各種裝置優化的文章清單、單一文章頁面和導航選單等功能。 **您將學到什麼：** 該專案將提高您建立複雜佈局的技能，並專注於回應能力。您將獲得建立導航結構和優化不同螢幕尺寸的使用者體驗的經驗。 **技術堆疊：** HTML、CSS (Flexbox/Grid)、JavaScript。 **資源：** [響應式部落格網站教學](https://youtu.be/NNQuhOeM0mI?si=RjNPOIm-otDhMTsE)  ### 8. 使用 Lottie 檔案的動畫天氣應用程式 使用 Lottie 檔案建立帶有動畫天氣圖示的天氣應用程式。提供與當前天氣狀況對應的即時天氣資訊和動畫。 **您將學到什麼：** 該專案將擴展您將外部庫 (Lottie) 整合到專案中的技能。您還將獲得使用即時資料 API 和實現動態動畫的經驗。 **技術堆疊：** React、Lottie、OpenWeatherMap API、CSS。 **資源：** [動畫天氣應用教學](https://youtu.be/pFvWwFua6mw?si=Xut6cKy10rV1DpFd)  ### 9.SaaS 登陸頁面 設計並建置軟體即服務 (SaaS) 產品的登陸頁面。強調簡潔的設計、有效的文案和引人注目的號召性用語元素。 **您將學到什麼：** 該專案將提高您建立以行銷為導向的登陸頁面的技能，並專注於用戶轉換。您還將深入了解有說服力的設計和有效使用配色方案的原則。 **技術堆疊：** React、Tailwind CSS、文案。 **資源：** [SaaS 登陸頁面教學](https://youtube.com/playlist?list=PLz_5rPRIvGEBDvyf-HIIDHjsPppnuXtFG&si=JIpCCIbz4QW8v9o4)  踏上這些令人興奮的專案，在 2024 年掌握前端 Web 開發。每個專案都提供一系列獨特的挑戰和學習機會，讓您具備在動態 Web 開發領域脫穎而出所需的技能。快樂編碼！ 🚀 --- 原文出處：https://dev.to/mukeshkuiry/9-projects-to-master-frontend-web-development-in-2024-with-resource-d0k
嘿嘿👋 在您作為開發人員的旅程中，賺錢的常見方法是**獲得全職工作**。 然而，您可能還沒有找到工作（_又名您仍在學習_），或者您已經開始工作，但您正在尋找賺取額外現金的方法。 現在，您可以嘗試透過多種方式賺取副收入。 “有些比其他更現實。” 在本文中，我們將了解您今天就可以開始的**_可實現的_副業收入工作**。 深吸一口氣，讓我們用這些新知識洗滌我們的靈魂。 🧎  **_免責聲明：_** 我沒有嘗試清單中的每個選項。如果您認為應該在清單中加入一些內容或您想分享個人經歷，請在下面發表評論（我很樂意聽取您的意見！）。 🙇♂️ --- ## ⚔️ 創作者任務 在 Quine，我們目前正在為開發人員提供一種將其技能貨幣化的方法。 _Creator Quests_ 是每兩週發生一次的開源挑戰。 **這就像一場 24/7 的黑客馬拉松，獎勵開發者建立酷炫的應用程式**以及使用未來的開發者工具。 🚀 社區透過對他們喜歡的專案給予榮譽來決定獲勝者。獲得最多榮譽的專案將獲得最多的收益。 🤑 **下一次挑戰將於 12 月 19 日星期二開始。** 要參加，請註冊 [Quine](https://quine.sh/?utm_source=devto&utm_campaign=monetising_dev_skills) 並前往 _Quests_。 PS：測試期間，100%有效參賽者均獲得獎勵💸 目前的獎金池為 1024 美元，隨著更多參與者的加入，獎金池將會增加！點擊下面的並試試看！ ⬇️ [](https://quine.sh/?utm_source=devto&utm_campaign=monetising_dev_skills --- # 💃 MaaS - 我即服務 **自由工作者很難開始。** 然而，每個人都可以**實現並獲得**。 我在資料分析方面有一些自由職業經驗。如果我必須重做一次，我會採取以下方法： **1️⃣ 選擇平台：** 了解[Fiverr](https://www. Fiverr.com/)、[Upwork](https://www.upwork.com/en-gb/nx/job)之間的區別-post/instant/welcome) 和 [自由工作者](https://www.freelancer.co.uk/)。選擇一個您喜歡的平台並專注於此。我發現 [Malt](https://www.malt.com/) 是一個有趣的平台，但如果你認為自己非常優秀，你可以隨時關注 [TopTal](https://www.toptal.com) / ）。 **2️⃣ 不要成為萬事通先生/女士：** 圍繞非常具體的服務建置配置文件，例如_我專門從事Python 抓取工具的編碼並使用MongoDB 建置資料庫，最終通過Plotly 顯示儀表板_（不完全是這樣）但你明白了🙃）。 **3️⃣ 為您的第一個客戶不收取任何費用：** 獲得您的第一個客戶非常困難，因此請聯繫招聘訊息並說明您很樂意**免費這樣做。** 如果他們對這份工作感到滿意，請詢問他們提供良好的評級。 **4️⃣ 獲得您的第一筆薪水：** 開始為您的工作收費 - 仍然以較低的費率 - 並建立您的聲譽。 **5️⃣ 提高定價：** 一旦您在平台上擁有更強大的地位，您就可以決定提高定價。 我的最後評論是，雖然我相信每個人都可以透過自由工作開始賺錢，但**我不認為每個人都應該這樣做。** 有很多缺點不符合你喜歡的工作方式（難纏的客戶、截止日期） 、平台依賴性等）。 **💁 特別提示：** 在倫敦，我發現了一個吸引一些客戶的小技巧。您可以聯繫一些相關的諮詢/招聘機構，他們可以幫助您找到客戶。如果您在起步時遇到困難，請考慮這樣的機構。 --- ## 🧪 測試一下。獲得報酬。 作為開發人員，您了解網頁或應用程式背後的技術細節。 這意味著您有能力執行出色的品質檢查。 根據您關注的平台，您可以花 10 到 60 分鐘以上嘗試應用程式或網站。 市面上有各種平台，但您可以查看的 3 個已知網站是： - [Trymata](https://trymata.com/) - [使用者測試](https://www.usertesting.com/) - [UserLytics](https://www.userlytics.com/user-experience-research/paid-ux-testing/) PS：還有一個完整的調查選項，在我看來，花費很少。如果您仍然好奇，可以查看[Wynter](https://wynter.com/participants/join)或[SwagBucks](https://www.swagbucks.com/g/paid-surveys)。 --- # 🐛 蟲子獵人 如果您對細節有敏銳的洞察力並且喜歡網路安全，那麼您可以透過這項技能獲利。 如果你有好奇心並且有良好的程式設計技能，你就可以在那裡賺錢。 🥂 一開始你可能會得到 20 美元的報酬，但獎勵可能會增加到天文數字，例如 10 萬英鎊以上。 我要強調的是，這不是你成為百萬富翁的方式。有一些不錯的競爭，你可能不會賺到很高的錢。 您仍然應該嘗試一下，看看它是否適合您。 最知名的平台是： - [HackerOne](https://www.hackerone.com/) - [BugCrowd](https://www.bugcrowd.com/) 如果你在這方面變得擅長，你可以考慮大公司，因為這往往是大公司的地方。 您可以從 [Microsoft](https://www.microsoft.com/en-us/msrc/bounty)、[Apple](https://security.apple.com/bounty/) 和 [Google](https: //bughunters.google.com/about/rules/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules)。 **最後提示：** 如果您發現自己喜歡使用的網站有漏洞，向他們索取賠償總沒有壞處。 🙃 --- ## 🧑🏫 你學到了什麼嗎？教它回來 輔導是我個人最喜歡的「副業」。 對於某些人來說，這可能看起來“乏味”，但它是非常可以實現的，並且它**增強您圍繞特定主題的知識，同時賺大錢**。 此外，您不一定需要成為專家。 這是正確的！ 只要您在特定領域更有知識，您就可以收取教授該知識的服務費用。 您可以透過 3 種方法來解決此問題： ### 📜 老學校方式 1️⃣ **確定合適的學校**：在學校/學院周圍張貼實體廣告，並附上您的課程和聯絡方式。 2️⃣ **辨識社群：** 尋找並參與相關的 Discord、Facebook 和 Linkedin 群組。以尊重的方式讓相關社區了解您的服務。 3️⃣ **不要太貪心：** 以較低的價格開始您的第一堂課，讓一切順利進行。經過一些經驗後，考慮提高價格。 ### 👶 新學校方式 查看以下平台： - [Codementor](https://www.codementor.io/freelance) - [Superprof](https://www.superprof.co.uk/lessons/computer-programming/united-kingdom/) - [導師](https://tutorhouse.co.uk/a/coding) 註冊成為導師並以低於市場價格的價格開始招募您的第一批學生。 ### 📦 數位內容 您可以考慮建立一些視訊課程。 我個人最喜歡的是一個名為 [Stan Store](https://www.stan.store/?ref=bap&utm_source=stan-store-link&utm_medium=redirect&utm_campaign=storefront) 的新工具。 這是數位創作者的全能工具包，不僅僅是建立影片內容。 > 我個人使用這個平台賺了幾百美元。 或者，您可以查看更傳統的平台，例如 [SkillShare](https://www.skillshare.com/en/search?query=Coding) 或 [Udemy](https://www.udemy.com/)。 --- ## 較不容易實現的路徑（但值得一提）👇 <br> <br> - **🚧 黑客馬拉松**：一些黑客馬拉松提供豐厚的現金獎勵。缺點是通常存在相當多的競爭。要尋找合適的黑客馬拉松，迄今為止最好的網站是 [DevPost](https://devpost.com/)。 <br> - **🏷️ 銷售鍋爐模板：** 您可以根據自己的知識建立鍋爐模板。在這種情況下，「稍微少一點」的是你能賺多少錢（至少在最初）。這是因為它需要大量的追隨者（或大量的行銷）。如果你想嘗試一下，可以看看 [Gum Road](https://gumroad.com/) 和 [AppSumo](https://appsumo.com/)。 --- 我希望您喜歡這篇文章，它可以幫助您了解如何利用您的開發技能來從事副業。 上述演出並不是試圖描繪出你將一夜致富的景象。然而，它們是副業，獲得報酬的機會很高。只要保持一定的一致性，隨著時間的推移，您可以期望獲得更多的收入。 🚀 這篇文章的靈感來自 @lissy93 寫的一篇很棒的文章。 如果您有興趣了解將您的開發技能貨幣化的其他方法（特別是如果您更有經驗），請查看他們的[文章](https://dev.to/lissy93/50-ways-to-bring -in- extra-cash-as-a-developer-19b6) 並給它一些愛。 下週見， 您的開發夥伴💚 巴普 --- 如果您想加入開源中自稱「最酷」的伺服器😝，您應該加入我們的[discord伺服器](https://discord.com/invite/ChAuP3SC5H/?utm_source=devto&utm_campaign=9_deep_learning)。我們隨時為您的開源之旅提供協助。 🫶 {% 嵌入 [https://dev.to/quine](https://dev.to/quine) %} --- 原文出處：https://dev.to/quine/5-achievable-side-hustles-for-developers-4bcg
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
