🔍 搜尋結果:ci

🔍 搜尋結果:ci

專屬雲端的程式語言

> 面向雲程式設計的宣言。 別誤會我的意思,我喜歡雲!它使我能夠建立令人驚嘆的東西,並徹底改變了我使用軟體創新和解決問題的方式。 它是「*新電腦*」、終極電腦、「*無電腦電腦*」。它可以彈性擴展,永遠在線,無處不在,可以做任何事情。這是無邊無際的。它肯定會留在這裡。 但天哪,這絕對不是我們在未來十年內建立雲端應用程式的方式。隨著雲端從“我不想讓伺服器放在我的辦公桌下”發展到“我的應用程式需要30 個不同的託管服務來執行其任務”,我們有點忘記了優秀的開發人員體驗是什麼樣子的。 為雲端建立應用程式有時感覺就像把我孩子的袋子裡未使用的樂高積木灑滿了客廳地板並試圖建造一座城堡。在經歷了撕碎的撲克牌、可怕的芭比娃娃頭和漏電的電池之後,你讀了第一百萬次說明書,卻發現你最終建造的東西與上次建造的東西基本上相同。 分類樂高積木很有趣!和孩子們一起打發時間。它甚至滿足了我的強迫症……但見鬼,這不是我想要建立專業軟體的方式! *讓我試著描述一下我和我的開發人員朋友正在努力解決的問題。* ### 我想專注於為我的用戶創造價值 當我建立專業軟體時,我希望將大部分時間花在應用程式的*功能*領域,而不是我使用的平台的*非功能*機制。 每次我想要在 AWS Lambda 函數內執行程式碼時,我都必須了解它需要與 tree-shaken 依賴項捆綁在一起,作為 zip 檔案上傳到 S3 並透過 Terraform 部署,這是沒有意義的。或者,為了能夠向 SNS 發布訊息,我的 IAM 策略必須有一個允許對主題的 ARN 執行`sns:Publish`操作的語句。*每個開發人員都需要了解 ARN 是什麼嗎?* 所有這些東西與我試圖為用戶創造的價值沒有任何關係。這是純粹的力學。**我們能擺脫它嗎?** ### 我想獨立 作為一名開發人員,最令人沮喪和最扼殺流程的情況之一是我必須停下來等待某人或某事才能繼續前進。 就像快樂地在空中滑翔,欣賞風景,欣賞優美的背景音樂,突然,*砰!*混凝土牆。 當您為雲端建立應用程式時,這堵混凝土牆有多種形狀和尺寸。是 DevOps 人員排隊;需要更新的是 IAM 策略;是只有外部兼職顧問才知道如何除錯的部署失敗;我們希望內部平台中不斷積壓的缺失旋鈕和 API 能夠改變一切。 這些障礙令人沮喪,因為它們迫使我切換環境,應用「臨時」安全策略,並發明我不想談論的醜陋駭客。這是一個破碎的世界。 我想獨立。我希望能夠把事情做好,保持順其自然。我想一次一點地改善世界,並在完成*後*繼續下一件事。我想要完成任務時的多巴胺激增,而不是另一個未完成的線程的羞恥感。 ### 我想要即時回饋 我說過我想要獨立,但不要誤以為我會寫完美的程式碼。這就是為什麼我想用鉛筆而不是鋼筆寫程式碼。 有些開發人員可以花一整天的時間進行編碼,甚至無需呼叫編譯器,最終,他們進行編譯和部署,然後就可以正常工作了。 我很欽佩他們,但我不是那種類型的開發人員。不,先生。對我來說,這就是迭代、迭代、迭代。我從小處開始,用輕鉛筆畫草圖,看一看,擦掉一堆東西,畫一條更粗的線,後退一步,瞇著眼睛,畫更多,擦掉更多,再看一眼,*沖洗並重複*。 這就是為什麼對我來說,最重要的是迭代速度。我越早執行並測試我的應用程式,我就能越快地返回並迭代。這就是我的流量所在。 當我開始程式設計時,我使用 Borland C++。過去,在 IBM PC AT 機器(TURBO ON)上編譯和執行一個程式大約需要 100ms。**雲端中的平均迭代周期需要幾分鐘。分鐘!有時要幾十分鐘!** 這是當今雲端中迭代的樣子:我對程式碼進行了更改;然後我需要編譯它;將其部署到我的測試帳戶;找到管理控制台的方式來實際觸發它;等待它執行並去搜尋 登入另一個服務。然後我意識到有一個錯誤回應告訴我我很愚蠢,因為我怎麼不知道我必須傳入 Accept-Content: application/json,否則我會得到一些名為「XML」的奇怪結果我不知道該怎麼辦(開個玩笑,XML 很棒,不是真的)。現在一切又重新來過… 因此,您說“編寫單元測試”,以居高臨下的方式試圖證明當前的現實是合理的。 「偉大的開發人員編寫單元測試」。好的!因此,現在我需要獲取我的程式碼,該程式碼進行了大約20 個外部API 呼叫,並透過從過時的文件中複製並貼上它們來以某種方式模擬API 回應,結果卻發現我的請求被拒絕了,因為我缺少了一些隱式操作我的 IAM 安全聲明。我們都去過那裡。 **說實話,給我90年代的開發者經驗**。我想要進行更改,並且希望能夠以互動方式或透過在幾毫秒內的單元測試來測試此更改,並且我想坐在沒有 WiFi 的飛機上執行此操作,好嗎? (我們在 90 年代沒有 WiFi)。 ### 所以這只是一句吐槽? 一定不行!我是電腦程式編制員。有時我覺得我從出生起就一直在寫軟體。我一直在社會危險的時期這樣做,當時成為電腦極客並不酷。 我一直喜歡成為開發人員,因為如果我對自己的工具不滿意,我可以製作自己的工具。畢竟,製造工具已經融入了我們的 DNA——人類製造工具的歷史已經超過一百萬年。 我對我的工具不滿意。 2022 年 4 月,我與好朋友、前微軟同事 \[Shai Ber\] 聯手,創立了 \[Wing\],其使命是***為開發者解鎖雲端***。我們聚集了一群令人難以置信的美麗極客,他們與我們一樣對開發人員體驗和開源充滿熱情,並開始了我們的旅程,使開發人員(即我們自己)能夠解決這些基本問題。 ### 編譯器來救援 那麼我們該如何一次解決所有這些問題呢? **我們正在為雲端建立一種程式語言。** 「*一種程式語言!?* 」你問。 “*世界上沒有足夠的程式語言嗎?* ”,“*編寫一個編譯器真的很難嗎?* ”, *“開發人員想要學習一門全新語言的機會有多大?* ”,“*為什麼不能你侵入了現有的語言工具鏈,瞇起眼睛,然後就到此為止了嗎?* ” 我不是一個心血來潮就建立程式語言的人。事實上,我花了過去五年的時間建立 \[AWS CDK\],這是一個*多語言庫*,它允許開發人員使用他們最喜歡的程式語言定義雲端基礎設施,從而解決了我正在談論的一些挑戰。 「滿足開發人員所在的位置」是 AWS 和 CDK 的美好宗旨,它激勵我們建立 \[JSII\] 和 \[constructs\] 等出色的技術。 ***但有時,「他們在哪裡」並不是一個足夠好的模型來創造所需的體驗。*** 用程式碼定義基礎設施確實使我們能夠建立更高層級的抽象,但只要我的應用程式程式碼需要與此基礎設施交互,抽象就變得太\[洩漏\]。我被迫要了解比我需要的更多的知識,而且我必須成為 IAM、VPC、ALB、EBS 等領域的專家,基本上還有比我想記住的更多的 TLA。 我們今天使用的語言都是圍繞著*電腦是一台機器*的想法而設計的。他們已經達到了能夠為我們提供對這些機器的可靠抽象的程度。它們抽象化了 CPU、記憶體、檔案系統、行程管理和網路。作為開發人員,我不必關心文件在磁碟上的佈局方式,甚至不必關心哈希映射需要多少記憶體。我只需寫`readFile()`或`new Dictionary()`即可開始我的一天。是的,對我來說,了解幕後發生的事情並不是一個壞主意,但我並不是被迫這樣做。 大多數這些語言還為我提供類型安全。當我使用錯誤數量的參數呼叫函數時,我的編譯器會對我大喊大叫。我不必等到我的應用程式執行時才意識到我忘記了參數,或者傳遞了錯誤的類型。 **在雲端,我獨自一人**。每當我的程式碼需要與雲端資源或服務互動時(隨著產業的發展,這種情況越來越多)我必須放棄程式語言的舒適性和安全性。我必須跳出機器的邊界,進入網路的狂野西部,而我的編譯器卻一無所知。 突然之間,所有痛苦的來源幾乎變得非常明顯。如今的雲端應用程式只是由互不相連的部分拼湊而成。我有一個用於我的基礎設施的編譯器,另一個用於我的函數,另一個用於我的容器,另一個用於我的 \[CI/CD 管道\]。每個機器都非常認真地對待自己的工作,並讓我在每台機器中保持安全和快樂,但我的應用程式不再在單台機器上執行,我的應用程式在雲端上執行。 ***雲就是計算機。*** ### Wing,一種面向雲端的程式語言 當新的程式設計範式出現時,語言需要時間來迎頭趕上。我曾經喜歡用 C 語言建立物件導向的程式碼,但它是一個有漏洞的抽象。我必須了解物件在記憶體中的佈局方式、\[V 表\] 的工作原理,並記住將物件作為每個函數的第一個參數傳遞。當程式語言開始像一等公民一樣支援物件導向的概念時,這種範式就民主化了,今天大多數開發人員甚至不知道 V 表是什麼,世界一直在旋轉。 **Wing** ,或者***winglang,***如果你想可愛一點的話,它擁有你所期望的現代、面向物件、強類型和通用語言的所有好東西,但它還包括一些額外的原語,旨在支持分佈式雲作為一等公民的基於服務的性質。 ### 一探究竟 我們在 Wing 上的工作已經快一年了,我很高興邀請您查看並告訴我您的想法。雖然仍處於 Alpha 階段,尚未準備好投入生產使用,但已經可以用它來建立一些[實際的應用程式](https://github.com/winglang/research/tree/main/dogfooding)。 https://github.com/winglang/wing --- 原文出處:https://dev.to/winglang/cloud-why-so-difficult-3j33

資料庫 101:如何為 100 萬玩家的遊戲建立排行榜模型。

有沒有想過像**《英雄聯盟》** 、 **《要塞英雄**》甚至**《Rockband》**這樣的遊戲是如何建立排行榜模型的?在本文中,我們將了解如何正確建模模式以以極其高效的方式處理它們! 如果您剛開始使用一般資料庫或資料庫,您可能需要閱讀我的第一篇文章[《資料庫 101:初學者的資料一致性](https://dev.to/danielhe4rt/database-101-why-so-interesting-1344)》。那篇文章記錄了我自己對有多少資料庫範例的探索,因為我的眼光遠遠超出了我以前僅使用 SQL 和 MySQL 的經驗。我正在**資料庫 101**系列中追蹤我的研究。 > 距離我發表本系列的第一篇文章已經快一年了!感謝您在我學習主題時與我在一起。您的評論和想法總是非常有幫助! 1. 序言 ----- ![YARG 遊戲玩法截圖](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dvensca2v67ma66vssnh.png) 從我還是個孩子的時候起,就像大多數普通開發者一樣,我就對遊戲及其製作方式著迷。說到這裡,我要跟大家介紹一下我兒時最喜歡的遊戲:《吉他英雄3:搖滾傳奇》。 十多年後,我決定嘗試在開源環境中為一些遊戲做出貢獻,例如[rust-ro(Rust Ragnarok Emulator)](https://github.com/nmeylan/rust-ro)以及本文的主角: [YARG(Yet Another Rhythm Game)](https://github.com/YARC-Official/YARG) 。 YARG 實際上是另一個節奏遊戲,但這個專案的不同之處在於它是完全**開源的**,他們聯合了遊戲開發和設計方面的傳奇貢獻者來讓這個專案能夠運作。 突然之間,這款遊戲被 Twitch 上的 Guitar Hero/Rockband 主播們所採用並玩,我想:好吧,這是一個開源專案,所以也許我可以利用我的資料庫技能來建立一個**速度極快的排行榜**或儲存過去的比賽。 一開始只是在他們的 Discord 上進行了一次簡單的聊天,後來變成了關於如何讓這個專案更快發展的長時間討論。 然後我決定和我的老闆談談,問他我是否可以和 YARG 的人一起工作,條件是建立一些足夠酷的東西來實現[ScyllaDB(NoSQL 寬列資料庫)](https://scylladb.com/) ,因為我在那裡擔任開發倡導者。您不會相信ScyllaDB帶來的簡單性和可擴展性如何完美契合YARG.in的需求! 無論如何,談話是廉價的。讓我向您展示一些程式碼和概念! 2.QDD-查詢驅動的資料建模 --------------- ![NoSQL 與關係型資料庫](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ivkj9j8ni2fakkctx53n.png) 當我們談論使用**NoSQL**進行開發時,大多數情況下我們應該理解,根據範例(文件、圖形、寬列等),您應該先了解**要執行哪個查詢**。 在 MySQL 中,主要目標是了解一致性,而在 Scylla 中,您應該專注於查詢並基於該查詢建立模式。 在這個專案中,我們將處理兩種類型的範例,它們是: - 核心價值 - 寬列(聚類) 現在讓我們來談談我們建模的查詢/功能。 ### 2.1 功能:儲存匹配 ![提交詳情 YARG](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jaw4q7349upgrsa5p5g3.png) 每次完成 YARG 遊戲時,最有趣的事情就是提交您的分數以及許多其他遊戲內指標。 基本上它將是基於主索引的單一查詢,僅此而已。 ``` SELECT score, stars, missed_notes, instrument, ... FROM leaderboard.submisisons WHERE submission_id = 'some-uuid-here-omg' ``` ### 2.2 功能:排行榜 ![排行榜 Figma 文件](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/69jp0vgxef71titt9ks0.png) 現在我們的主要目標是:一個超酷的**排行榜**,在良好的資料建模之後你不需要關心它。排行榜是按歌曲計算的,因此每次您播放特定歌曲時,您的最佳成績都會被保存並排名。 然而,這個介面有一個重要的點,那就是有過濾器來準確地知道要帶來「哪個」排行榜: - 歌曲 ID:必填 - 儀器:必填 - 修飾符:必需 - 難度:必填 - 玩家 ID:可選 - 分數:可選 想像一下我們的查詢如下所示,它會傳回按分數降序排列的結果: ``` SELECT player_id, score, ... FROM leaderboard.song_leaderboard WHERE instrument = 'guitar' AND difficulty = 'expert' AND modifiers = {'none'} AND track_id = 'dani-california' LIMIT 100; -- player_id | score ----------------+------- -- tzach | 12000 -- danielhe4rt | 10000 -- kadoodle | 9999 ----------------+------- ``` 現在我們知道了將在這裡使用的功能,但是您能想像最終的模式將如何嗎? 不?好的,讓我來幫助你! 3. 資料建模時間! ---------- 是時候深入研究 ScyllaDB 的資料建模並更好地了解如何擴展它了。 ### 3.1 - 匹配建模 ![遊戲結束畫面](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b6kedk7iu67zg7myj9mp.png) 首先,讓我們先來了解遊戲本身: - 這是一個節奏遊戲; - 您一次播放一首特定的歌曲; - 您可以在遊戲前啟動“修改器”,讓您的生活變得更輕鬆或更困難; - 您必須選擇一種樂器(例如吉他、鼓、貝斯和麥克風)。 - 遊戲玩法的各個方面都會被跟踪,例如: - Score; - Missed notes; - Overdrive count; - Play speed (1.5x ~ 1.0x); - Date/time of gameplay; - And other cool stuff. 考慮到這一點,我們可以輕鬆地開始我們的資料建模,這將變成這樣: ``` CREATE TABLE IF NOT EXISTS leaderboard.submissions ( submission_id uuid, track_id text, player_id text, modifiers frozen<set<text>>, score int, difficulty text, instrument text, stars int, accuracy_percentage float, missed_count int, ghost_notes_count int, max_combo_count int, overdrive_count int, speed int, played_at timestamp, PRIMARY KEY (submission_id, played_at) ); ``` 讓我們跳過所有`int/text`值並跳到`set<text>` 。 **集合**類型可讓您儲存特定類型的專案清單。我決定使用這個清單來儲存修飾符,因為它非常適合。看看查詢是如何執行的: ``` INSERT INTO leaderboard.submissions ( submission_id, track_id, modifiers, played_at ) VALUES ( some-cool-uuid-here, 'starlight-muse' {'all-taps', 'hell-mode', 'no-hopos'}, '2024-01-01 00:00:00' ); ``` 使用這種類型,您可以輕鬆儲存專案清單以供以後檢索。 另一個很酷的資訊是這個查詢是一個鍵值對!這意味著什麼? 由於您始終僅透過`submission_id`來查詢它,因此它可以歸類為鍵值。 ### 3.2 排行榜建模 ![排行榜濾鏡 Figma](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lpmzngra3jk5ipf3os3i.png) 在本文的這一部分中,您將學習一些很酷的寬列資料庫概念。 在我們的排行榜查詢中,如前所述,我們總是需要在 WHERE 子句中使用一些動態值,這意味著這些值將屬於**分區鍵**,而**聚類鍵**將具有可以是「可選」的值。 **分區鍵**是基於您新增的用於標識值**的欄位組合的**雜湊。你明白了嗎?不?好吧,我也花了一段時間才明白這一點,但讓我向你展示一些東西: 假設您玩了`Starlight - Muse` 100 次。如果您要查詢此訊息,將透過`score`或`player_id`等聚類鍵區分出100倍不同的結果。 ``` SELECT player_id, score --- FROM leaderboard.song_leaderboard WHERE track_id = 'starlight-muse' LIMIT 100; ``` 如果有 1.000.000 個玩家播放這首歌,你的查詢會變得很慢,並且將來會成為一個問題,因為你的分區鍵只包含一個字段,即`track_id` 。 但是,如果您向**Partition Key**加入更多字段,例如玩遊戲之前的強制性內容,也許我們可以縮小這些可能性以實現更快的查詢。現在你看到大局了嗎?加入諸如**“樂器”** 、 **“難度**”和**“修改器”等**欄位將為您提供一種均勻分割有關特定曲目的資訊的方法。 讓我們想像一些簡單的數字: ``` -- Query Partition ID: '1' SELECT player_id, score, ... FROM leaderboard.song_leaderboard WHERE instrument = 'guitar' AND difficulty = 'expert' AND modifiers = {'none'} AND -- Modifiers Changed track_id = 'starlight-muse' LIMIT 100; -- Query Partition ID: '2' SELECT player_id, score, ... FROM leaderboard.song_leaderboard WHERE instrument = 'guitar' AND difficulty = 'expert' AND modifiers = {'all-hopos'} AND -- Modifiers Changed track_id = 'starlight-muse' LIMIT 100; ``` 因此,如果您以特定形狀建立查詢,它將始終查找特定令牌並根據這些特定分區鍵檢索資料。 我們來看看最終的建模,談談聚類鍵和應用層: ``` CREATE TABLE IF NOT EXISTS leaderboard.song_leaderboard ( submission_id uuid, track_id text, player_id text, modifiers frozen<set<text>>, score int, difficulty text, instrument text, stars int, accuracy_percentage float, missed_count int, ghost_notes_count int, max_combo_count int, overdrive_count int, speed int, played_at timestamp, PRIMARY KEY ((track_id, modifiers, difficulty, instrument), score, player_id) ) WITH CLUSTERING ORDER BY (score DESC, player_id ASC); ``` 分區鍵的定義如上所述,由我們**所需的參數**組成,例如:track\_id、修飾符、難度和樂器。在**聚類鍵**上,我們新增了**Score**和**player\_id** 。 > 請注意,預設情況下,聚類欄位按`score DESC`排序,以防萬一玩家得分相同,選擇獲勝者的標準將按`alphabetical` ¯\\\_(ツ)\_/¯。 首先很容易理解的是,我們**每個玩家只有一個分數**,但透過這種建模,如果玩家以不同的分數兩次經歷同一條賽道,它將產生兩個不同的條目。 ``` INSERT INTO leaderboard.song_leaderboard ( track_id, player_id, modifiers, score, difficulty, instrument, stars, played_at ) VALUES ( 'starlight-muse', 'daniel-reis', {'none'}, 133700, 'expert', 'guitar', '2023-11-23 00:00:00' ); INSERT INTO leaderboard.song_leaderboard ( track_id, player_id, modifiers, score, difficulty, instrument, stars, played_at ) VALUES ( 'starlight-muse', 'daniel-reis', {'none'}, 123700, 'expert', 'guitar', '2023-11-23 00:00:00' ); SELECT player_id, score FROM leaderboard.song_leaderboard WHERE instrument = 'guitar' AND difficulty = 'expert' AND modifiers = {'none'} AND track_id = 'starlight-muse' LIMIT 2; -- player_id | score ----------------+------- -- daniel-reis | 133700 -- daniel-reis | 123700 ----------------+------- ``` 那我們要如何解決這個問題呢?嗯,這本身不是問題。這是一個特點!哈哈 身為開發人員,您必須根據專案需求建立自己的業務規則,這也不例外。我這麼說是什麼意思? 您可以在插入新條目之前執行簡單的**DELETE**查詢,並確保在該特定**分區鍵**組內, **player\_id**中的特定資料不會低於新**分數**。 ``` -- Before Insert the new Gampleplay DELETE FROM leaderboard.song_leaderboard WHERE instrument = 'guitar' AND difficulty = 'expert' AND modifiers = {'none'} AND track_id = 'starlight-muse' AND player_id = 'daniel-reis' AND score <= 'your-new-score-here'; -- Now you can insert the new payload... ``` 這樣我們就完成了簡單的排行榜系統,該系統與 YARG 中執行的系統相同,也可以在每秒數百萬個條目的遊戲中使用:D 4. 如何為 YARG 做出貢獻 ---------------- 這是我邀請您為這個精彩的開源專案做出貢獻的文字部分! 今天,我們正在為所有玩家建立一個全新的平台,使用: - 遊戲:Unity3d [(儲存庫)](https://github.com/YARC-Official/YARG) - 前端:NextJS [(儲存庫)](https://github.com/YARC-Official/yarg.in) - 後端:Laravel 10.x [(儲存庫)](https://github.com/YARC-Official/yarg-api) 我們將需要盡可能多的開發人員和測試人員與主要貢獻者一起討論遊戲的未來實現! ![YARG 不和諧](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y5b2pdxvrth2o6jfmada.png) 首先,請確保加入他們的[Discord 社群](https://discord.gg/sqpu4R552r)。在進入開發板之前,所有技術討論都會在社群後台進行。 此外,在 Discord 之外,YARG 社群主要關注[EliteAsian](https://twitter.com/EliteAsian123) (核心貢獻者和專案所有者)Twitter 帳戶的開發展示。一定要跟著他去那裡。 https://twitter.com/EliteAsian123/status/1736149319382671766 僅供參考,遊戲的**首席美術師**(又稱[Kadu)](https://twitter.com/kaduyarg)也是**Elgato**的**廣播專家**和**產品創新**開發人員,曾與以下串流媒體合作: - 忍者 - 納德肖特 - 石山64 - 以及傳奇 DJ Marshmello。 Kadu 也使用他的 Twitter 分享一些見解以及 YARG 新功能和實驗的早期預覽。所以,別忘了在 Twitter 上關注他! https://twitter.com/kaduyarg/status/1689489132060397568 以下是一些有用的連結,可以幫助您了解有關該專案的更多訊息: - [官方網站](https://yarg.in/) - [Github 儲存庫](https://github.com/YARC-Official/YARG) - [任務板](https://yarg.youtrack.cloud/agiles/147-7/current) > 有趣的事實:YARG 受到了 Guitar Hero 專案負責人[Brian Bright](https://twitter.com/BrianBright/status/1744533504531317194)的關注,他喜歡該專案的開源特性。太棒了,對吧? 5. 結論 ----- 資料建模有時具有挑戰性,這項研究花了 3 個月的時間研究了許多新的 ScyllaDB 概念,並與我在 Twitch 的社群一起進行了大量測試。 我還發布了[遊戲排行榜演示](https://github.com/scylladb/gaming-leaderboard-demo),您可以在其中獲得有關如何使用**NextJS**和**ScyllaDB**實現同一專案的一些見解! 另外,如果您喜歡 ScyllaDB 並想了解更多訊息,我強烈建議您觀看我們的免費[大師班課程](https://lp.scylladb.com/masterclass-ondemand-main?siteplacement=navigation)或存取[ScyllaDB 大學](https://university.scylladb.com/)! 不要忘記喜歡這篇文章,在社交上關注我並填滿你的水瓶 xD 下一篇文章見! [在推特上關注我](https://twitter.com/danielhe4rt) [在 Github 上關注我](https://twitter.com/danielhe4rt) [在 Github 上關注我](https://twitter.com/danielhe4rt) [關注並訂閱我的 Twitch 頻道](https://twitch.tv/danielhe4rt) --- 原文出處:https://dev.to/danielhe4rt/database-101-how-to-model-leaderboards-for-1m-players-game-2pfa

關於 Web Components 與 React 的比較,我的看法

您經常聽到工程師將 Web Components 與 React 進行比較。這是我的看法。 ### Web 元件是規格。你的網路框架不是。 事實上,我們不需要 JavaScript 框架來使用 Web 元件,這是一個巨大的差異。 Web 元件規格自訂元素 v1、範本、插槽和 ShadowDOM 的部分都可以在瀏覽器中運作。這意味著開始編寫 Web 元件時無需依賴關係! ![](https://thepracticaldev.s3.amazonaws.com/i/cdmrq1jzjxci8ce1vpv7.png) 您不需要大量的 JavaScript 來渲染 UI。 Web 元件對於載入嚴重依賴項阻礙使用者互動的情況(例如行動裝置的情況)非常有用。但還不止於此。事實證明,[Web 元件的靜態網站產生需要最少的工具](https://github.com/readymade-ui/readymade/blob/master/build-gh-pages.js)。 HTML 模組將使處理模板部分的人體工學變得更好。今年,Chrome 團隊宣布 [HTML 模組規格](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ) 即將推出!雖然您可能需要 JavaScript 框架來建立複雜的 Web 應用程式,但靜態網站最好僅使用規範來建置。考慮到網路中有多少內容是靜態內容,這是一個很大的問題。抱歉,React 和蓋茲比。 ### Web 元件是包容性的。 JavaScript 生態系統是如此分散。 Web 元件為每個人提供了使用同一種語言的機會。 React 的支持者很快指出“沒有單一的‘Web 元件社區’,但事實是社區是我們所有人。JavaScript 框架是排他性的。你必須成為俱樂部的一部分。自定義元素則不然。v1. 初學者可以開始編寫它們,而無需學習JavaScript 庫的艱苦戰鬥。 ### Web 元件解決了一個不同的問題。 React 解決了 UI 開發中狀態缺失的問題。自訂元素是無狀態的。您需要將狀態機引入自訂元素。 JavaScript 框架永遠都有空間。 Web 元件提供了一個機會來簡化過去幾年一直在這裡流行的元件範例,以便每個人都可以使用相同的 UI 元件。 Web 元件本質上是在擴展我們日常使用的基本元素時解決人體工學問題。 [甚至在 React 文件中也這麼說。](https://reactjs.org/docs/web-components.html)React 和 Web Components 解決了不同的問題。 ### Web 元件是可互通的。您的 Javascript 框架很可能不是。 在框架中使用自訂元素不僅是可能的,而且應該被視為進入 2020 年的最佳實踐。Javascript 框架應該能夠處理自訂元素,就像處理 DOM 一樣。讓 Web 元件與 JavaScript 框架配合使用有許多怪癖。 React 有一些問題,但 React 團隊表示[他們將考慮與規範緊密整合](https://dev.to/ben/why-the-react-community-is-missing-the-point-about-web-components-1ic3/)。 Angular 不支援自訂內建元素的部分規格。 Angular 提供了對自主自訂元素的支持,甚至可以使用 Angular Elements 編譯它們。 Vue 與自訂元素具有相當的互通性,但是如果您遇到問題,使用 Vue 編碼的人請在這裡留言。有一些解決方法可以解決整合 Web 元件所產生的問題,但 JavaScript 框架還需要做一些工作來確保完整的自訂元素 v1 規範正常運作。 ### Web 元件是 a11y。 客製化的內建元素可讓您擴展按鈕、輸入等原生元素,並選擇和實現您自己的功能。透過擴充具有可存取性特徵的元素,您可以免費獲得這些功能。通常,在使用 JavaScript 框架建立 UI 元件時,您必須複製輔助功能。 ### 教育和網路工程存在問題。 在過去十年流行的程式碼學院中,我們忘記了詳細說明規格並直接跳入 JavaScript 框架。即使是入門級課程也可以包括接觸 React。這對於只想讓我們「使用平台」的 JavaScript 框架來說是有利的,但它留下了一個空白,即初級工程師缺乏我們所使用的平台的知識:HTML、CSS 和 JavaScript。 Web Components 透過提供每個人都可以學習和使用的規範來解決這個問題。 ## 我們就不能好好相處嗎? 即使對於初學者來說,學習 HTML 規範也很容易。讓每個瀏覽器和函式庫都同意並支援規範是很困難的。 HTML 是一個動態文件,並且隨著時間的推移而不斷變化。 [Apple 拒絕](https://github.com/w3c/webcomponents/issues/509#issuecomment-230700060) 在 Safari 中實作自訂的內建元素規格。自從 Microsoft 在 Edge 中遷移到 Chromium 以來,所有最受歡迎的常青瀏覽器都實作了自訂元素 v1。我們只需要更好地合作,Web 元件可以為 2020 年代實現 UI 元件提供可持續的範例。 ![](https://media.giphy.com/media/3o7qE1EaTWLQGDSabK/giphy.gif) 這並不意味著您現在無法開始使用 Web 元件。對於不支援此規格的瀏覽器,存在 [Polyfills](https://www.webcomponents.org/polyfills/)。 我們應該共同努力,確保 Web 元件進入開發工作流程。從前端 Web 開發教育的一開始到最複雜的 Web 應用程式 Web 元件都有可能簡化 UI 元件開發、提供開箱即用的輔助功能,甚至減少建立 UI 所需的程式碼量。是時候我們釋放這種潛力了,而不是爭論哪個 JS 框架更適合提供元件範例。 JavaScript 框架將繼續擅長其最擅長的領域:狀態管理、提供架構模式和方便的工具。 Web 元件將繼續存在。我們可以共同努力,讓網路變得更美好。 --- 原文出處:https://dev.to/steveblue/it-s-not-about-web-components-vs-react-5137

React 和 NextJS 2024 最佳免費開源 SaaS 初學者

## 長篇大論;博士 SaaS 樣板啟動器隨處可見,但它們非常昂貴(約 200-800 美元)。 我想為 React 和 NextJS 找到最好的免費開源 SaaS Starters,這些 Starters 將在 2024 年積極維護。 在下面的文章中,我將介紹每個初學者的功能及其優缺點,所以如果您有興趣,請繼續閱讀。但我還在下面整理了這個漂亮的圖表,可以一目了然地對它們進行比較(順便說一句,文章底部有同一圖表的文本版本,帶有可點擊的連結)。 享受! ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wr6z6jqmypnl5hzrgyr1.png) ## 介紹 軟體即服務 (SaaS) 應用程式是獨立駭客和個人企業家賺錢的最佳方式之一。這就是為什麼 SaaS 樣板啟動器正在崛起!但其中一些售價高達 2,000 美元以上,平均價格約為 200 美元。 這就是為什麼我開始尋找是否有免費的開源 SaaS 啟動器以及它們的表現如何。在找到了很多但注意到大多數不再積極維護後,我將範圍縮小到這四個免費的開源 SaaS Starter:BoxyHQ 的 SaaS Starter、Open SaaS、SaaS Starter Kit 和 Next SaaS Stripe Starter。 ## BOXYHQ SaaS 入門套件 “**您的終極企業級 Next.js 樣板”** ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/51svaqq6lu6s3ldoy5i0.png) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xd6cftpnl9robmmtw36b.png) - GitHub:https://github.com/boxyhq/saas-starter-kit - 影片演練:[https://www.youtube.com/watch?v=oF8QIwQIhyo](https://www.youtube.com/watch?v=oF8QIwQIhyo) BoxyHQ 是一家專注於安全的公司,專注於單一登入 (SSO) 和企業安全解決方案。因此,這個 SaaS 入門套件雖然免費且開源,但更專注於企業需求也就不足為奇了。 因此,如果您正在尋找一個外觀簡潔、具有安全 SAML SSO、使用者帳戶建立、團隊建立和管理以及 Webhooks 和事件整合功能的樣板,那麼這就是您的範本。 優點: - SAML 單一登入 - 全面的角色和權限 - 專注於企業SaaS應用程式開發 缺點: - 更適合企業級應用程式,這對於較小的專案來說可能有點過分 - 一些即將推出的功能(例如計費和訂閱)尚未實現 ## 開放 SaaS 「***免費*具有超能力的 SaaS 範本」** ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/awz3renuql3k5awlvkms.png) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5ptji6f1viufkonb3bzw.png) - 網站與示範:https://OpenSaaS.sh - Github:https://github.com/wasp-lang/open-saas Open SaaS 專注於建立一個功能齊全的開源 SaaS 樣板,它擁有您期望從付費模板中獲得的一切,包括整合的人工智慧。範例、為您的網站流量和收入統計配置的分析儀表板以及完整的文件和支援。 它由 Wasp 團隊為您帶來,這是一個全端 React / NodeJS / Prisma 框架,可透過設定檔為您管理功能。例如,這意味著您只需幾行程式碼即可“推出您自己的身份驗證”,因為 Wasp 會為您管理樣板檔案。 優點: - 利用Wasp進行全端開發,減少開發時間 - 擁有完整的文件和多元化且支持性的社區 - 與 OpenAI API 集成,並包含人工智慧驅動的應用程式範例 - 開箱即用的端到端類型安全 缺點: - 可能缺少一些更廣泛的 SaaS 應用程式功能,例如測試 - 依賴 Wasp,一個鮮為人知但高效能的全端框架 ## SaaS 入門套件 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rdy7kkxnwvddia1qcxii.png) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vqikv8rshdqq0yj1sas6.png) - 網站與示範:[https://www.saasstarterkit.com/](https://www.saasstarterkit.com/) - GitHub:[https://github.com/Saas-Starter-Kit](https://github.com/Saas-Starter-Kit) SaaS 入門套件是一個現代 SaaS 樣板,旨在建立具有免費/開源和專業/付費選項的全面 SaaS 解決方案。 這是一個簡單、乾淨的 UI,包含許多漂亮的 UI 元件,包括 Shadcn UI 分析儀表板元件。但不幸的是,您必須將它們與您自己的資料來源集成,因為大多數樣板都沒有管道。 目前它缺少很多配置,但看起來它在未來可能是一個有前途的模板 優點: - 提供免費版和專業版,使其能夠滿足多種需求 - 精心設計的 UI 元件,專門用於管理儀表板 缺點: - 具有增強功能的專業版不是免費的,這可能會讓一些用戶望而卻步 - 主要是內建Auth的UI元件集合,所以開發者還需要做很多工作 ## 下一個 SaaS Stripe 入門者 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ui7rg0yqafp9mf5nki0d.png) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pd9uqi903h358oqu37w9.png) - 網站與示範:[https://next-saas-stripe-starter.vercel.app/](https://next-saas-stripe-starter.vercel.app/) - GitHub:https://github.com/mickasmt/next-saas-stripe-starter Next SaaS Stripe Starter 是一個簡單、乾淨的 SaaS 樣板,可利用現代、流行的工具。儘管它不像其他一些軟體那麼功能齊全,但由於使用了 Shadcn UI 和 Contentlayer,它看起來很漂亮,並且有一個時尚的部落格。一般來說,它處於良好的狀態,可以用作 SaaS 的基礎。 如果您正在尋找一個最小的 NextJS 模板並且可以進行大量自訂和功能開發,那麼這就是適合您的模板。 優點: - 看起來不錯並且利用了各種流行的工具。 - 它包括未來的更新,涵蓋成功訂閱和切換訂閱計劃的重新發送功能。 缺點: - 很少甚至沒有文件 - 不像其他模板那樣功能豐富。 ##六。結論與建議 雖然所有 SaaS Starter 都為您的專案提供了良好的基礎,但如果您正在開發企業級應用程式,請考慮 BOXYHQ。如果您正在尋找可立即投入生產的模板並希望快速交付,那麼 Open SaaS 將是理想的整體模板,而如果您正在建置簡單/微型 SaaS 並且想要現代設計美感,則 Next SaaS Stripe Starter 則適合您。 | | [BoxyHQ SaaS 入門套件](https://github.com/boxyhq/saas-starter-kit) | [開放SaaS](https://opensaas.sh) | [SaaS 入門套件](https://www.saasstarterkit.com/) | [下一個 SaaS Stripe 入門](https://next-saas-stripe-starter.vercel.app/) | | --- | --- | --- | --- | --- | | **適合** | 🏢 📈<br/>企業。對於需要 Teams 功能的應用程式 | 🧑‍💻🤖 <br/>獨立駭客和新創公司快速建立現代 (AI) 應用程式 | 🧑‍💻🔧 <br/>獨立駭客正在尋找優秀的 UI 元件集合 | 🧑‍💻🎨 <br/>獨立駭客正在尋找簡約、時尚的 SaaS 樣板。 | | **易於使用** | 6/10 <br/>複雜,以企業為中心。 | 8/10 <br/>精簡且快速。有據可查。 | 5/10 <br/>需要大量額外設定。 | 7/10 <br/>良好的基礎,但缺乏一些功能 | | **授權** |透過 Auth.js 驗證電子郵件、SAML SSO、Google、Github |電子郵件已驗證,Google,Github 透過 Wasp w/ Lucia |電子郵件、Google 透過 Auth.js |谷歌透過 Auth.js | | **管理儀表板** |限團隊管理 |內建和預先配置的網站和收入分析 |用於收入分析的 UI 元件(未配置) |無 | | **付款** |否(即將推出)|條紋| Stripe(+ Lemonsqueezy 付費版)|條紋| | **分析** |透過 Mixpanel 進行第 3 方(付費)|合理(免費、開源)或 Google | Vercel 分析(付費)| Vercel 分析(付費)| | **人工智慧.準備好了** |沒有 |內建 AI 支援 https://opensaas.sh (OpenAI API) |沒有 |沒有 | | **端對端類型安全性** |沒有 |是的 |沒有 |沒有 | | **電子郵件發送器** |郵件發送 | SendGrid、EmailGun 或 SMTP |重新發送 |重新發送 | | **內建部落格** |沒有 |是(透過 https://astro.build/)|否(付費版本,是)|是(透過 https://contentlayer.dev/)| | **造型** |順風|順風| Tailwind,Shadcn ui | Tailwind,Shadcn ui | | **使用者介面與設計** |基本 |款式好看|帶有漂亮 UI 元件的基本 |現代、時尚的造型| | **社區支持** | https://discord.gg/uyb7pYt4Pa | https://discord.gg/aCamt5wCpS | https://www.reddit.com/r/saas_kit/(發佈時沒有討論)|無 | | **文件** |基本 |非常詳細|基本 |可憐| | **演示應用程式** |無 | https://opensaas.sh | https://www.saasstarterkit.com/ | https://next-saas-stripe-starter.vercel.app/ | https://next-saas-stripe-starter.vercel.app/ --- 原文出處:https://dev.to/vincanger/best-free-open-source-saas-starters-for-react-nextjs-2024-4nbn

😎 2024 年值得關注的 9 個熱門開源專案

身為一名熱衷於開源的開發人員,我不斷關注新興的專案、函式庫和服務。 你知道那些,似乎有那種特殊的醬汁。 ![燈泡時刻](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aj2mtk0t0oa7doj1midk.gif) 我整理了一份小清單,列出了我在新的一年中看到的趨勢或預期的趨勢。 讓我們來看看我最近遇到的一些最令人驚訝和印象深刻的專案。 ## 1. [Wing](https://github.com/winglang/wing) ![翼](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kj3n6z4negxh2rvthj3a.gif) Wing 開發了一種名為 **[Winglang](https://www.winglang.io/)** 的面向雲端的程式語言,專門用於解決雲端開發人員面臨的需求和挑戰。 將基礎設施和執行時程式碼組合成一種語言,並具有內建的本機模擬器以及可觀察性和偵錯控制台。 Wing 減少了認知負荷和上下文切換,使開發人員能夠保持創作流程。 Wing 如何促進您的發展: - 更快的迭代周期 - 透過機翼模擬器進行在地化測試 - 透過編寫更少的程式碼部署到雲端 {% cta https://dub.sh/wing-cloud %} 請star ⭐ Winglang {% endcta %} <小時/> ## 2. [也許](https://dub.sh/wing-cloud) ![也許](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8sdivkavkiuht8tgtsuq.gif) Maybe 最近開源了他們的個人理財 + 財富管理應用程式 一些功能包括: - 投資標桿 - 投資組合分配 - 債務洞察 {% cta https://github.com/maybe-finance/maybe %} 請加註星標 ⭐ 也許 {% endcta %} <小時/> ## 3. [Wstunnel](https://github.com/erebe/wstunnel?tab=readme-ov-file) ![Wstunnel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/24jmmutuudqssociwxg9.gif) Wstunnel使用與http相容的WebSocket協定來繞過防火牆和代理程式。 這允許您傳輸您想要的任何流量並存取您需要的任何資源/網站。 {% cta https://github.com/erebe/wstunnel?tab=readme-ov-file %} 請加註星標 ⭐ wstunnel {% endcta %} <小時/> ## 4. [Spotube](https://github.com/KRTirtho/spotube) ![wstunnel](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nhcqt9wvdd0lchc3tsut.gif) 開源、跨平台的 Spotify 用戶端,利用 Spotify 的資料 API 和 YouTube(或 Piped.video 或 JioSaavn)作為音訊來源,跨多個平台相容, 不再需要 Spotify Premium。 順便說一句,這不是另一個 Electron 應用程式😉 {% cta https://github.com/KRTirtho/spotube %} 請加註星標 ⭐ Spotube {% endcta %} <小時/> ## 5. [柔術](https://github.com/martinvonz/jj) ![Jujutzu](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vcy49y6dpnwav2t4i8mw.gif) Jujutsu 是一個軟體專案的版本控制系統,以 Rust 編寫。 您用它來: - 取得/複製您的程式碼 - 追蹤程式碼的更改 - 發布這些變更以供其他人查看和使用。 {% cta https://github.com/martinvonz/jj %} 請star ⭐ Jujutsu {% endcta %} <小時/> ## 6. [黃蜂](https://github.com/wasp-lang/wasp) ![黃蜂](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1f3vyg7g6gn0wke26g9h.gif) Wasp(Web 應用程式規格)是一個類似 Rails 的 React、Node.js 和 Prisma 框架。 在一天之內建立您的應用程式並使用單一 CLI 命令進行部署! - 快速開始 - 無樣板 - 沒有鎖定 {% cta https://github.com/wasp-lang/wasp %} 請加註星 ⭐ 黃蜂 {% endcta %} <小時/> ## 7. [最佳化](https://github.com/refinedev/refine) ![精煉](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/atf3c2rldmw5zsk181cb.gif) 用於建立內部工具、管理面板、儀表板和 B2B 應用程式的 React 框架,具有無與倫比的靈活性。 Refine 不限於一組預先設計樣式的元件,而是提供以下集合: - 輔助掛鉤 - 成分 - 供應商 {% cta https://github.com/refinedev/refine %} 請加註星 ⭐ Refine {% endcta %} <小時/> ## 8. [DbGate](https://github.com/dbgate/dbgate) ![DbGate](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3uwv1e66powp9mtli147.gif) DbGate 是一個跨平台資料庫管理器,其設計目的是在同時處理更多資料庫時使用簡單且有效率。 **支援的資料庫:** - MySQL - PostgreSQL - SQL伺服器 - 甲骨文(實驗性) - MongoDB - 雷迪斯 - SQLite - 亞馬遜紅移 - CockroachDB - 瑪麗亞資料庫 {% cta https://github.com/dbgate/dbgate %} 請star ⭐ DBGate {% endcta %} <小時/> ## 9. [ivy](https://github.com/unifyai/ivy) ![常春藤](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6z2k5064eyhfpdf3y71k.gif) Ivy是一個開源機器學習框架: - 自動調整您的模型 - 將程式碼轉換為任何框架 - 編寫與框架無關的程式碼 {% cta https://github.com/unifyai/ivy %} 請star ⭐ Ive {% endcta %} <小時/> --- 原文出處:https://dev.to/winglang/9-top-trending-open-source-projects-to-watch-for-in-2024-emb

反應性的推導

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

SQL 查詢優化 23 倍!!!

所以我現在已經進入 Web 開發大約 3 年了,專業也有一年多了,這是我處理一個與資料庫查詢最佳化相關的問題的時候,我不是 SQL 專家,我可以得到這份工作完成。沒有花哨的查詢、觸發器、預存程序等。無論如何,我不得不穀歌搜尋最後一個。 長話短說..我們的 ORM (TypeORM) 把我們搞砸了.. ## 免責聲明: 這並不是要誹謗 TypeORM 或任何 ORM。它們是為其建置目的而設計的特殊工具。我在最後附加了一些參考連結,這些連結是人們面臨類似問題的公開討論。無論如何,讓我們繼續這篇文章。 ## 問題! 我們的提交表有超過 70 萬筆記錄,表現非常糟糕。從表中取得資料的最長時間超過 6 秒。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5dqlrbtn491upu8lwxs.png) 查詢相當簡單。我們所擁有的只是 4 個連接、幾個 where 子句(大約 4 個)、排序(在created_at time 字段上的 DESC)、限制和跳過。 ## 根本原因分析.. 導致我們的提交表大幅放緩的幾個因素如下:- - **索引** - 對用於連接表的欄位進行不正確的索引或未進行索引。 - **不必要的連接** - 我們的查詢中有一些不必要的連接,可以將其刪除以獲得更多效能。 - **空字串錯誤** - 我們程式碼中的一個錯誤,如果沒有為這些列提供使用者輸入,我們將與作為查詢的 where 條件一部分的所有列的空字串 (“”) 進行比較。 - **ORM** - ORM 正在執行一個超級愚蠢的查詢來獲取資料。 這些是我在檢查程式碼和資料庫模式以及分析正在執行以獲取所需資料的查詢時發現的精確點。 ## 對提到的每個問題進行分析和測試。 ###<u>原因 1:索引</u> 在進行了一些谷歌搜尋並閱讀了人們的類似問題後,我發現我們的問題並不是那麼大。人們正在為數百萬行而苦苦掙扎,而我們的只是其中的一小部分,所以一定是我們做錯了什麼。 早期解決這些問題的社區提出了許多建議。我發現進行適當的索引會有很大幫助。 因此,為了進行測試,我從 beta 資料庫中獲取了提交內容,該資料庫擁有大約超過 **100k 記錄**。 在沒有任何最佳化的情況下,執行整個過程平均需要 **2.3 秒**。 (當然,這個時間不僅包括在資料庫上執行查詢的時間,還包括透過網路傳播資料的時間) ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2mgewrjv4khpzrst86nb.png) 在向列加入索引後,我確實發現它縮短了幾毫秒的時間,但這還不夠。它仍然在 **2 秒** 左右,而且往往不止於此。 所以有點令人失望!無論如何,繼續下一個目標。 ### <u>原因 2:空字串錯誤</u> 因此,我們的時間從 **2.3** 秒縮短到了大約 2 秒,這對於索引來說並不算多。但後來我在我們的程式碼中發現了一個小錯誤,假設有四個輸入欄位供使用者根據四個不同的列鍵入和過濾結果。如果使用者沒有在任何輸入上鍵入任何內容(主要是在頁面首次載入時),且 API 呼叫會直接取得最新資料,而不進行任何過濾,僅進行連接和排序。 因此,在那一刻,我們為資料庫中的所有列傳遞了“”字串,這似乎無害,但實際上發生的情況是,資料庫正在對所有四列進行查找,您猜對了“”字串。所以進行了大量的查找,實際上什麼都沒有。 因此,當我將其更改為空(如empty/null)時(相當於從查詢中刪除where子句),查詢時間從**2.3秒變為1.3秒**。 如果您想知道使用使用者提供的實際輸入進行過濾需要多長時間。大約**500ms**(這是可以接受的)。 結論 - 即使您的資料庫使用所有可搜尋列進行索引,“”字串也不能很好地發揮作用。 好的,我們正朝著正確的方向前進。我們整整縮短了 1 秒,但我們仍然必須將其控制在 **200/150ms** 以下,所以還有很長的路要走。 ### <u>原因 3:不必要的連接</u> 在查詢提交時,我們正在與不需要的比賽和課程表進行連接。因此,當所有內容都加入到程式碼中時,我們只是刪除了它,但這表明審閱者並沒有給予太多關注(我是其中之一)。 ### <u>原因 4:ORM</u> 這是造成最多的問題.. 好.. 問題!!. 所以有一種叫做 **主動記錄模式** 的東西,TypeORM 為我們提供了使用類似 JSON 的物件產生 SQL 查詢的東西,一個例子就是。 ``` model.find({ select: { userName : true, firstName : true }, where: { userName : “SomeUsername” }, relations: { user : true, contest: true, problem: true }, order: { created_at : “ASC/DESC” , skip: 0, take: 10, }) ``` 因此,這使得開發變得快速、簡單,對於不擅長編寫原始 SQL 查詢的開發人員來說,感覺非常直觀,因為這是最抽象的版本,您實際上是在建立 JSON 物件來產生 SQL 查詢。 這種方法看起來不錯,而且大多數時候都有效,但在我們的例子中,它做了一些非常愚蠢的事情,我不會輸入它在做什麼,這樣你就可以自己看到查詢。 簡而言之,它正在執行兩個查詢,首先對於這種情況根本不需要,它可以通過我稍後編寫並測試的一個簡單的單個查詢輕鬆完成。 它不僅執行兩個單獨的查詢(原因尚不清楚,因為這是一個已知問題,有時在使用typeorm 的活動記錄模式時發生),它還將四個表連接兩次,每個查詢一次,然後還排序兩次各一次。 (這實際上沒有任何意義) 這也是表演受到最大打擊的地方。自己看看下面的查詢。 ``` SELECT DISTINCT `distinctAlias`.`Submission_id` AS `ids_Submission_id`, `distinctAlias`.`Submission_created_at` FROM (SELECT `Submission`.`id` AS `Submission_id`, ... more selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId`  LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId`) `distinctAlias` ORDER BY `distinctAlias`.`Submission_created_at` DESC, `Submission_id` ASC LIMIT 10 ``` ``` SELECT `Submission`.`id` AS `Submission_id`, `Submission`.`language` AS `Submission_language`, `Submission`.`verdictCode` AS `Submission_verdictCode`, `Submission`.`tokens` ... shit ton of selects FROM `submission` `Submission` LEFT JOIN `problem` `SubmissionSubmission_problem` ON `SubmissionSubmission_problem`.`id`=`Submission`.`problemId`  LEFT JOIN `user` `SubmissionSubmission_user` ON `Submission_Submission_user`.`id`=`Submission`.`userId` WHERE `Submission`.`id` IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) ORDER BY `Submission`.`created_at` DESC ``` 所以這兩個查詢是問題的主要原因,也是主要原因之一。 因此,我編寫了一個簡單的原始 SQL 查詢來執行與它嘗試使用 2 個單獨的查詢執行的完全相同的操作,查詢如下:- ``` SELECT   Submission.id,   Submission.language,   Submission.verdictCode, ... FROM   submission AS Submission   LEFT JOIN problem ...   LEFT JOIN user ... ORDER BY   Submission.created_at DESC LIMIT 10 ``` 當我們執行這個查詢時,它的執行時間僅為 **100ms!!!** 因此,我們現在從 **1.3** 秒移至 **100ms**,總體從 **2.3** 秒移至 **100ms** 效能提升超過 **23 倍。** 之後我就去睡覺了。仍然需要做更多的測試,並嘗試找出邊緣情況(如果有),並提出為此編寫查詢的最佳方法。目前,我正在考慮使用 TypeORM 提供的儲存庫模式或查詢建構器模式。 第二天: 又來了.. ### <u>全文索引</u> **全文索引**可以提高從這些索引列中搜尋單字和短語的效率,我們也可以嘗試一下。 (這是我的同事 Jay 提出的一個非常好的觀點,它進一步提高了表現)。 ###<u>發現了一些更重要的點。</u> 在 MySQL 中最佳化具有唯一索引的資料列上的「LIKE」查詢時,可以採用一些策略來提高效能。以下是一些建議: 1. **索引優化:** - **使用全文索引:** 如果您的「LIKE」查詢涉及在列中搜尋單字或片語,請考慮使用全文索引而不是常規唯一索引。全文索引是專門為基於文字的搜尋而設計的,可以提供更快、更準確的結果。 - **使用排序規則:** 確保列的排序規則不區分大小寫和重音。這可以透過使用「utf8_general_ci」或「utf8mb4_general_ci」等排序規則來實現。它允許更有效地利用索引,因為搜尋變得不區分大小寫和重音。 2. **查詢最佳化:** - **前綴搜尋:**如果您的`LIKE`查詢在末尾使用通配符(例如,`column LIKE 'prefix%'`),索引仍然可以有效地使用。但是,如果通配符位於開頭(例如“column LIKE '%suffix'”),則不會使用索引。在這種情況下,請考慮使用替代技術,例如全文搜尋或儲存列的反向值以實現高效的後綴搜尋。 - **最小化通配符:** 模式開頭的通配符(`'%suffix'`)會使查詢速度明顯變慢。如果可能,請嘗試建立查詢,使通配符僅出現在模式的末尾(「前綴%」)。 - **參數綁定:** 如果您從應用程式內執行「LIKE」查詢,請使用參數綁定或準備好的語句,而不是直接連接查詢字串。這有助於防止SQL注入並允許資料庫更有效地快取執行計劃。 3. **快取和查詢結果:** - **快取查詢結果:** 如果`LIKE`查詢結果相對靜態或不需要即時,可以考慮實作像memcached或Redis這樣的快取機制。快取可以透過直接從記憶體提供結果來顯著縮短反應時間。 - **物化視圖:** 如果經常執行「LIKE」查詢且資料列的資料相對靜態,請考慮建立物化視圖來預先計算並儲存「LIKE」查詢的結果。如果查詢物化視圖所帶來的效能提升超過了額外的儲存和維護需求,則此方法可能會很有用。 值得注意的是,這些優化策略的有效性可能會根據您的特定用例而有所不同。 ### 經過所有測試後建議的改進點。 1. 修正將空字串傳遞到 where/過濾條件的問題。 2. 在效能至關重要的讀取操作中,轉而使用查詢建構器而不是活動記錄模式。 3. 在用於搜尋和過濾的欄位中新增索引。另外,在不唯一且用於搜尋的列上新增全文索引。 4. 刪除/避免不必要的連線。如果可能的話,重組架構以在必要時複製資料。 5. 使用 LIKE 運算子搜尋時,使用「prefix%」模式,而不是我們使用的預設模式「%suff+pref%」。使用前綴模式有助於資料庫使用索引並提供更好的結果。 儘管如此,我們成功地將查詢時間從 **7 秒** 降低到 **<=150 毫秒**,這樣做後感覺很好,因為這是我第一次涉足性能和優化並尋找從我們已有的資源中榨取更多資源的方法。 特別感謝[Mitesh Sir](https://www.linkedin.com/in/miteshskj/) 在這次調查期間指出了潛在的原因並引導我走向正確的方向,並一遍又一遍地重新啟動測試伺服器😂因為由於記憶體限制,在多次執行測試後,資料庫會變得非常慢。 如果您想更多地談論與這一切相關的內容,請在 X 上關注我,https://twitter.com/RishiNavneet ### 參考 1. https://github.com/typeorm/typeorm/issues/3857#issuecomment-714758799 2. https://github.com/typeorm/typeorm/issues/3857 3. https://stackoverflow.com/questions/714950/mysql-performance-optimization-order-by-datetime-field 4. https://stackoverflow.com/questions/22411979/mysql-select-millions-of-rows 5. https://dba.stackexchange.com/questions/20335/can-mysql-reasonously-perform-queries-on-billions-of-rows 6. https://stackoverflow.com/questions/38346613/mysql-and-a-table-with-100-millions-of-rows 7. https://github.com/typeorm/typeorm/issues/3191 PS - 這些改進很久以前就完成了,我只是懶得發布它😬。 --- 原文出處:https://dev.to/navneet7716/optimizing-sql-queries-h9j

為什麼番茄鐘不起作用?試試這個替代方案🍅

## 什麼是番茄鐘 番茄工作法由弗朗西斯科·西里洛 (Francesco Cirillo) 開發,是一種時間管理方法,使用計時器將工作分成多個時間間隔,傳統上為 25 分鐘,中間間隔 5 分鐘的短暫休息。 這些時間間隔被稱為“番茄鐘”,以西里洛大學時使用的番茄形狀的廚房計時器命名。 ## 為什麼番茄工作法可能不適用於開發人員 雖然番茄工作法很流行,但它可能不適合每個人,尤其是開發人員。原因如下: 1. **心流狀態的中斷**:嚴格的時序可能會破壞對編碼至關重要的深層「心流狀態」。當你全神貫注於一個複雜的問題時,因為計時器響而停下來可能會打斷你的思路。 2. **可變的任務長度**:編碼任務的複雜程度各不相同,通常無法完全適合 25 分鐘的間隔。有些任務可能需要長時間不間斷的專注,而有些任務則更短、更直接。 3. **上下文切換**:番茄工作法要求的頻繁休息可能會導致過度的上下文切換。對於需要持續集中註意力並深入了解手頭問題的任務來說,這會適得其反。 ## 更好的選擇 - Flowmodoro Flowtime 技術又名 Flowmodoro 是由 [Zoë Read-Bivens](https://medium.com/@UrgentPigeon/the-flowtime-technique-7685101bd191) 建立的,作為 Pomodoro 主要問題的解決方案。 與番茄工作法不同,Flowmodoro 是遞增計數而不是遞減計數。它可以讓您集中註意力,直到您自然地感到需要休息。然後,當您決定休息時,只需停止計時器,將專注時間除以 5,並為休息設置倒數計時器。 此方法尊重您的流程狀態並適應編碼任務的可變性質。 ## 如何實作 Flowmodoro 實作 Flowmodoro 很簡單,可以從碼錶和計時器應用程式等基本工具開始。這是一個基本指南: 1. **選擇一項任務**:先選擇要專注的一項任務。這可以確保您的注意力不會分散在多個任務上。 2. **開始工作**:選擇任務後,啟動秒錶。這標誌著你專注工作時期的開始。不受任何干擾地專注於您的任務。 3. **停止工作**:繼續工作,直到您自然地感到需要休息一下。這可能是當您感覺注意力不集中或您已經達到任務的邏輯停止點時。然後,停止秒錶。記錄的這個時間就是你專注工作的持續時間。 4. **休息一下**:將休息時間計算為專注工作時間的五分之一。例如,如果您工作了 50 分鐘,請休息 10 分鐘。為這個休息時間設定一個倒數計時器。這個比例可以確保您得到充分的休息,同時又不會失去工作的動力。 您可以一次又一次地重複這個循環。 ## 自動化流程 我一直在使用 Flowmodoro,它確實幫助我提高了編碼時的工作效率。然而,我注意到一個小缺點:每次都要手動設定計時器的重複過程。 為了解決這個問題,我目前正在開發與此工作流程無縫整合的解決方案。這就是 [Flowmodor](https://flowmodor.com) 的用武之地——我正在建立一個網頁應用程式,用於自動化和完善 Flowmodoro 流程。 Flowmodor 目前正在開發中,您可以透過加入候補名單來成為 Beta 測試員。該工具準備就緒後,您將有機會試用它。 https://flowmodor.com/#getWaitlistContainer 作為開發人員,我們的工作需要靈活性和適應性。 Flowmodoro 的設計就考慮到了這一點。讓我們用 Flowmodoro 擁抱我們的峰值流量狀態! --- 原文出處:https://dev.to/flowmodor/why-pomodoro-doesnt-work-try-this-alternative-2no9

每個開發者都必須知道的 12 個網站 🤩

**開發者們大家好!** 歡迎來到我的另一篇博文。 在這篇文章中,我想分享一些每個開發人員都必須了解的基本網站或工具。 所以讓我們**開始**👇並且不要**忘記**“💖🦄🔥”。 --- ## 1. [omatsuri.app](https://omatsuri.app) 🍡 ![omatsuri](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ic3rw7rpncvtsbas0an9.jpeg) Omatsuri 是一個提供網頁開發人員資源的日本網站。 “Omatsuri”,一個漸進式 Web 應用程式 (PWA),提供 **12 個開源前端工具的集合**。 這些資源**免費使用**和自訂,這在您設計新網站或應用程式時非常有幫助。 --- ## 2. [htmlrev.com](https://htmlrev.com/) 📄 ![htmlrev](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qa8wq2cfu7bn12h34l85.jpeg) HTMLrev 是一個**尋找 HTML 範本**和設計資源的絕佳網站。 他們為網站、登陸頁面、部落格、作品集等提供免費的 html 模板。 這些模板隨時可用且易於自訂。這是滿足您所有範本需求的一站式場所。 --- ## 3. [Unicornicons.com](https://unicornicons.com/) 🦄 ![unicorcicons](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zb4alzy6dmxa67p4prfk.jpeg) Unicornicons 擁有**漂亮的動畫圖示**,您可以在專案中使用它們。 他們有高級圖標包,但也提供許多**免費圖標**。這些圖標有助於使介面更具吸引力和樂趣。 您還可以輕鬆自訂顏色。 --- ## 4. [UiVerse.io](https://uiverse.io/)✨ ![uiverse](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iko1dy9qzowtp0m2pxs4.jpeg) UiVerse 是一個使用 CSS 和 Tailwind 建立的 UI 元素社群。 他們擁有超過 **3000 個元素,可以在 MIT 許可下免費**使用。 這對於建立 UI 元件並節省開發時間非常有用。您可以搜尋、篩選元素並直接取得要複製的程式碼。 --- ## 5. [undraw.co](https://undraw.co/illustrations) 🖌 ![取消繪製](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ejqgeh89p0m4bxhqres4.jpeg) Undraw 是一個開源插圖函式庫。他們提供**美麗的 SVG 插圖**,您可以免費使用。 這些插圖很現代,可以輕鬆自訂。這對於登陸頁面、有關部分和產品行銷的內容非常有幫助。 他們也不斷加入新的插圖。 --- ## 6. [patternpad.com](https://patternpad.com/) 🎨 ![patternpad](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/o1dmudn1m4qkn5kb4ukl.jpeg) PatternPad 讓您設計來自無限顏色和形狀變化的圖案。您可以在這裡非常輕鬆地**建立獨特的品牌模式**、簡報、社交貼文等。 圖案匯出為 SVG 以供靈活使用。這是一個很好的工具,可以為您的設計增添視覺吸引力。 --- ## 7. [shapeivider.app](https://www.shapeivider.app/) 🗺 ![shapeivider](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e2rofzquhdbh1rh0zd4z.jpeg) ShapeDivider 可協助您非常輕鬆地**在**標題、段落或部分之間新增曲線形狀。它是設計中經常使用的技術。 該網站允許您透過選擇形狀和顏色類型來產生程式碼。您可以**直接複製並貼上程式碼**。非常有用的工具! --- ## 8. [photopea.com](https://www.photopea.com/) 📸 ![photopea](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/811c325yaic55z5dyxnm.jpeg) Photopea 是一款線上照片編輯器,支援 PSD、XCF、Sketch、XD 和 CDR 格式。 **您可以免費開啟、編輯和儲存照片**,無需安裝任何軟體。 它具有類似於 Photoshop 的工具,但對初學者非常友好。這非常適合開發人員的基本影像編輯需求。 --- ## 9. [quickref.me](https://quickref.me/) 🧑‍💻 ![quickref](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/we3ozwf4mz5emjduqs9g.jpeg) QuickRef 是各種**開發人員工具、框架和技術**的備忘單集合。它們涵蓋了從程式語言、資料庫、設計工具到終端命令的所有內容。 這些備忘單可以幫助您更快學習,並且在開發過程中也非常方便。 **將此加入書籤!**。 --- ## 10. [devdocs.io](https://devdocs.io/) 📚 ![devdocs](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dfm13a7p6avflurnp7kc.jpeg) DevDocs 為許多程式庫和框架提供 API 文件。 **它從各種來源收集文件**並以有組織的方式呈現它們。 在開發過程中,經常需要參考文件。該網站使您可以輕鬆快速地找到所需的內容。 --- ## 11. [devhints.io](https://devhints.io/) 📝 ![devhints](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/233ziqtf3v6e0w9lkgyn.jpeg) Devhints 包含各種技術和工具的簡明備忘單。這些就像**開發人員的袖珍參考卡**。該資訊清晰呈現,沒有額外的細節。 他們專注於最重要的功能。這是一個很棒的網站,可以找到快速提醒。 --- ## 12. [開發工具](https://developer.chrome.com/docs/devtools/) 🛠 Chrome 開發者工具或 DevTools 是一套強大但有時令人難以抗拒的 Web 開發者工具。 developer.chrome 上的文件可協助您掌握這些工具。它涵蓋了每個面板的使用、鍵盤快捷鍵以及提示和技巧。任何開發人員都不應忽略 Chrome DevTools 文件。 --- ## 就是這樣😁 感謝您閱讀這篇部落格🙏,我希望這能為您帶來一些新的去處! 如果您發現任何其他有用的網站,請發表評論📩。 並且不要忘記加上“💖🦄🔥” **快樂編碼👋** --- 原文出處:https://dev.to/random_ti/top-12-websites-that-every-developer-must-know-2a67

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

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

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

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

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

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

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

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

✨ 十大工具,可以幫助你了解應用程式的運行狀況 🚀

假設您有一個或多個應用程式 - 它們都發送日誌 - 您如何知道它們內部發生了什麼? 通常有兩種方法: - **日誌記錄**:保存來自多個應用程式的日誌並提供見解和搜尋。這是老方法並且總是有幫助的。 - **追蹤**:專注於提供對應用程式效能的洞察;您可以針對它們建立準確的指標以進行監控和警報。 有些工具用於記錄,有些工具用於跟踪,有些工具兩者兼而有之! 以下是您必須了解的用於日誌和追蹤的開源工具: ![日誌](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/esar1pngxpw8z18zap74.gif) --- # 1. [Quickwit](https://github.com/quickwit-oss/quickwit)(日誌與追蹤)👑 Quickwit 是一個開源分散式搜尋引擎,專為大規模日誌管理和分析而設計。 Quickwit 是 Elasticsearch 的直接替代方案,具有更高的效能,尤其是在雲端原生和大規模分散式環境中,並且專注於優化儲存和搜尋效率。 通常,您會使用 OpenTelemetry、Fluentbit、Odigos(自動偵測追蹤工具)等工具來收集日誌和追蹤,將它們傳送到 Quickwit,然後使用 Jaeger(追蹤)或 Grafana(日誌和追蹤)將其視覺化。 **有趣的事實:** Elasticsearch 和 Kibana 都放棄了社區許可證,轉而採用更具限制性的許可證(從 Apache 2 到 Elastic 許可證,並遭到社區的強烈反對)。 Quickwit 是 AGPL 3。它對 FOSS(免費開源社群)更加開放。   ![Quickwit](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5azmt0hnhkj9oks3a93o.gif) --- # 2. [Grafana](https://github.com/grafana/grafana)(日誌和追蹤) Grafana 是 ELK 堆疊的開源替代品。對於日誌和跟踪,您必須設定兩個查詢引擎:Loki 和 Tempo,都由 Grafana 維護。 一旦您在 Loki 和 Tempo 中索引了所有日誌或跟踪,您將需要一個可視化工具來搜尋您的資料:Grafana 來了! Grafana 可讓您查詢、視覺化、警報和理解您的指標,無論它們儲存在何處。與您的團隊建立、探索和分享儀表板,並培養資料驅動的文化。   ![Grafana](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z0nsm0wfiqbnwcudksxr.gif) --- # 3. [Odigos](https://github.com/keyval-dev/odigos)(追蹤) Odigos 是一項獨特的技術,無需更改程式碼即可為 k8s 中的任何應用程式產生追蹤:然後可以將所有追蹤轉發到 Quickwit 或 Elasticsearch 等資料庫(它們有更多整合)。 如果您不知道,OpenTelemetry 是一個接收日誌和追蹤的協定。 Odigos 正在使用該標準,因此您可以在任何支援 OpenTelemetry 的資料庫中發送您的追蹤!   ![Odigos](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zo1qsgpt4glrro31n6fv.gif) --- # 5. [Jaeger](https://github.com/jaegertracing/jaeger)(追蹤) 與 Prometheus 不同,Jaeger 專注於追蹤。 Jaeger 支援跨分散式系統傳播上下文訊息,確保追蹤資料在服務網路中正確關聯。 它並不是為處理大量資料而設計的,您必須將其與強大的儲存引擎(如 Quickwit 或 Elasticsearch)一起使用。在這樣的設定中,Jaeger 可以根據您的服務進行擴展,使其適用於小型和大型系統。   ![Jaeger](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qzyo7fh4ete01pml8ea6.gif) --- # 6. [SigNoz](https://github.com/SigNoz/signoz)(日誌與追蹤) Signoz 提供日誌和追蹤管理功能。 您可以在單一管理平台中視覺化追蹤和日誌。 您可以透過尋找導致問題的確切追蹤並查看各個請求追蹤的詳細火焰圖來找到問題的根本原因。 ![Signoz](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wo47pgko3cluu9ufdxb3.gif)   --- # 7. [Keep](https://github.com/keephq/keep)(提醒) 保持與目前所有可觀察工具、資料庫和通訊管道的連接,並將所有內容聚合到一個平台中,在出現問題時提供頂級警報 😈   ![保留](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ofi0usc5qz9o8n0dc1d6.gif) --- # 8. [Uptrace](https://github.com/uptrace/uptrace)(日誌與追蹤) Uptrace 是一個基於 OpenTelemetry 的可觀察性平台,用於攝取日誌和追蹤。您可以監控您的應用程式並蒐索您的日誌。 由於其 OpenTelemetry 支援和眾多集成,可以輕鬆收集和發送資料 😈。請注意,您需要設定 Postgresql 和 Clickhouse 資料庫。   ![Uptrace](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ozdcpgz3a9anbqke5bo9.gif) --- # 9. [HyperDX](https://github.com/hyperdxio/hyperdx)(日誌與追蹤) HyperDX 是一個開源可觀察性平台,可讓您搜尋日誌並分析您的痕跡。您可以在一個平台上偵錯複雜的錯誤和使用者問題,而無需在多個工具之間跳轉。   ![HyperDX](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g3d0l1rkccv85gmqlqfn.gif) --- # 10. [普羅米修斯](https://github.com/prometheus/prometheus)(指標) 有趣的是,這個庫是以電影[普羅米修斯](https://www.imdb.com/title/tt1446714/)命名的(當然我是在開玩笑),但這是我的第一個假設(無論如何,這是一部好電影) 雖然 Prometheus 和 Elasticsearch 看起來很相似,但實際上它們非常不同。 Prometheus 只關注基礎設施的指標(例如 CPU、記憶體使用情況、磁碟使用情況…),但不太適合高基數指標。 Quickwit比較專注於Logs和Trace; Elasticsearch 可以做日誌、追蹤和指標! 他們傾向於攜手合作。 Prometheus 提供了一個原始的 UI,這很好,但它與 Grafana 儀表板最搭配。 有趣的是,Prometheus 提供了名為 PromQL(Prometheus Query Language)的查詢語言   ![普羅米修斯](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gougnoofwi5x2w2cz180.gif) --- 我們在 X 上連接嗎? :) [我在這裡](https://twitter.com/nevodavid) 您是否使用其他一些優秀的工具來記錄和追蹤? 請在評論中讓我了解它們:) --- 原文出處:https://dev.to/nevodavid/top-10-tools-to-learn-whats-going-on-in-your-app-20em

Kubernetes 變簡單 - Cyclops 簡介

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

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

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

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

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

網頁反應慢,怎麼辦?

看更多文章: 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 開發工具中的樣子: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k0wsxe16icfytqfamg3p.png) 他們真的嗎?它們是假的道具更改嗎?使用`useCallback`和`useMemo`。 ### 父渲染 它在 React 開發工具中的樣子: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ilqb2astlchzto603anc.png) 使用“React.memo”來記住您的純元件。 ### 掛鉤已更改(狀態、上下文) 它在 React 開發工具中的樣子: ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k8beosx4hh1n90ejts3h.png) 這裡沒有什麼太明顯的事情要做。嘗試驗證更改的鉤子是否有意義。也許一個糟糕的上下文提供者正在以與假道具更改可能出現的方式相同的方式偽造更改。 --- > 與此類似,我個人在 Slack 上經營著一個由開發人員主導的社群。我們在其中討論這些類型的實現、整合、一些真相炸彈、奇怪的聊天、虛擬會議以及一切有助於開發人員保持理智的事情;)畢竟,太多的知識也可能是危險的。 > 我邀請您加入我們的免費社區,參與討論,並分享您的驚人經驗和專業知識。您可以填寫此表格,Slack 邀請將在幾天後收到您的電子郵件。我們擁有來自一些偉大公司(Atlassian、Scaler、Cisco、IBM 等)的出色人員,您一定不想錯過與他們的互動。 [邀請表](https://forms.gle/VzA3ST8tCFrxt39U9) --- 您可能想要查看整合通知基礎架構的無縫方式。 https://github.com/suprsend/suprsend-go --- 原文出處:https://dev.to/nikl/react-is-slow-what-to-do-now-369g

Docker 絕對初學者

Docker 是一個工具,允許開發人員將他們的應用程式及其所有依賴項打包到一個容器中。然後,這個容器就可以輕鬆地在任何安裝了 Docker 的機器上傳輸和執行,而不必擔心環境的差異。這就像是打包和執行軟體的標準化方式。 **容器是什麼?** ![Docker 容器](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/imsgbstga86vnxjwgebr.png) 容器就像一個小包,其中包含程式執行所需的一切,可以輕鬆地在不同電腦上移動和執行,而不會造成任何麻煩。 最酷的部分是這個迷你電腦(容器)就像一個披著斗篷的超級英雄。它可以在任何電腦上執行,無論它們有多麼不同,因為它自帶特殊的環境。這是一種保持軟體井然有序的方式,並確保它無論在哪裡都能以相同的方式運作。 ![容器](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1z5zcued8ya2onerpzwt.png) **為什麼我們需要 Docker?** 1. **一致性:** Docker 確保軟體在您的電腦、您朋友的電腦或任何電腦上以相同的方式運作。它使事情保持一致。 2. **可移植性:** 您可以將您的軟體及其朋友打包到 Docker 容器中,並且它可以移動到任何地方。這就像將您的遊戲及其所有規則放在手提箱中並在朋友家中玩。 3. **隔離:** Docker 容器就像小氣泡。氣泡內發生的事只會留在氣泡內。這意味著容器中的一個程式不會幹擾容器外的另一個程式。 4. **效率:** Docker有助於節省電腦資源。您可以讓許多容器在同一台電腦上執行,而不會相互妨礙,而不是讓一整台電腦只用於一個程式。 5. **速度:** Docker 讓啟動、停止和共享軟體變得快速、輕鬆。這就像打開和關閉遊戲機一樣 - 快速而簡單。 **什麼是 Docker 映像?** ![Docker 映像](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/817t1rsad728snnighkj.png) Docker 映像像是程式及其運作所需的所有內容的快照。它是一個打包版本,包括程式碼、工具和設置,就像包含所有成分的餅乾食譜的快照一樣。 **圖像是配方,容器是當您按照該配方實際製作和執行程序時所得到的。** **一些基本的 Docker 命令。** ![基本 Docker 指令](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xq1pwt8896lvster3ppl.png) 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`)。 **分層架構:** ![分層架構](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9i91e79dg61wnbbfp62m.png) - 將 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 儲存](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7i54a6m0o1tb0812xbjk.jpg) 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yjyro6o2844s2or1b83c.jpeg) 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 註冊表](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bzflp82qyg36y8fcf8k8.png) 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 引擎](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hc6r4dvo9kg9xqgwsrbb.jpg) 想像一下,你有一個魔盒(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 隔離容器進行額外隔離。 ## 容器編排 ![容器編排](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3lyleybojw3xmr2dgfep.png) 容器編排是一種管理和協調多個容器的方法,確保它們無縫協作來執行應用程式,就像一個超級智能的管理器確保所有機器人一起工作來建置完美的塔一樣。 **為什麼要編曲?** 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z5noonjo2ikyrp90kc38.png) 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 伺服器的三個副本並將其連接到「前端」網路。這就像有一個首席機器人經理在工作機器人的幫助下監督多個塔(貨櫃)的建造。 ![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ytitz2wt4jsufejox9yx.gif) **好的,這就是本文的內容。** 另外,如果您對此或其他任何問題有任何疑問,請隨時在下面的評論中或在 [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

JS 設計模式:綜合指南

![圖片描述](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vukjahraekzzsj9e6h3x.png) JavaScript 以其廣泛的採用和多功能性,已成為現代 Web 開發的基石。隨著您深入研究 JavaScript 開發,理解和利用模式變得至關重要。在本文中,我們將踏上揭開 JavaScript 模式神秘面紗的旅程,並探索它們如何增強您的程式設計實踐。 ## 先決條件 要理解本文中討論的概念和技術,您需要了解 JavaScript 的基礎知識。熟悉變數、函數、資料類型、物件導向程式設計等概念至關重要。 在繼續之前,讓我們花點時間了解 JavaScript 作為程式語言的重要性。 ### JavaScript 作為程式語言 JavaScript 通常被稱為“網路語言”,是一種動態的高階程式語言。它主要用於 Web 瀏覽器中的客戶端腳本編寫,但隨著 Node.js 的出現,它也在伺服器端獲得了關注。 JavaScript 的主要功能包括操作 DOM、處理事件、為網頁提供互動性等的能力。 話雖這麼說,讓我們簡單討論一下 JavaScript 中模式的重要性和用途。 ### JavaScript 開發中模式的重要性 JavaScript 中的模式可以作為軟體開發過程中遇到的重複問題的經過驗證的解決方案。它們提供結構、改進程式碼組織、增強可維護性並促進可重複使用性。透過理解和應用模式,開發人員可以編寫更清晰、更有效率的程式碼並有效應對複雜的挑戰。 ### 理解 JavaScript 模式的目的 理解 JavaScript 模式不僅僅是記住文法或遵循最佳實踐。它使開發人員能夠批判性地思考軟體設計、選擇適當的解決方案並建立可擴展的應用程式。透過掌握 JavaScript 模式,您可以深入了解該語言及其生態系統,從而能夠編寫健全且可維護的程式碼。 現在我們知道了 JavaScript 模式的重要性和用途,讓我們深入研究 JS 設計模式的基礎知識。 ## 設計模式的基礎知識 在本節中,我們為理解 JavaScript 開發背景下的設計模式奠定了基礎。 ###設計模式的定義與特點 設計模式是可重複使用的模板,封裝了解決重複出現的軟體設計問題的最佳實踐。它們提供了一種結構化的方法來設計軟體系統,並促進模組化、靈活和可維護的程式碼。設計模式的共同特徵包括其目的、結構、參與者和協作。 ###設計模式的類型 設計模式可分為三種主要類型: - 創意 - 結構性 - 行為的 了解這些類別有助於確定給定問題的適當模式。 - **創作模式** 建立模式專注於物件建立機制,提供以靈活且受控的方式實例化物件的方法。 JavaScript 中一些常用的建立模式包括: - 辛格頓 - 工廠 - 建構函數 - 原型 - 建造者 - 模組 **單例模式** 單例模式確保一個類別只有一個實例,並提供對其的全域存取點。當您想要限制類別的實例數量並確保在整個應用程式中可以存取單一共用實例時,此模式非常有用。 ``` // Implementation example of the Singleton Pattern class Singleton { constructor() { if (!Singleton.instance) { // Initialize the instance Singleton.instance = this; } return Singleton.instance; } } const instance1 = new Singleton(); const instance2 = new Singleton(); console.log(instance1 === instance2); // Output: true ``` 在此範例中,Singleton 類別有一個建構函數,用於檢查該類別的實例是否已存在。如果實例不存在(“!Singleton.instance”條件),它將透過將其指派給「Singleton.instance」來初始化該實例。這確保了對建構函數的後續呼叫將傳回相同的實例。 當使用新的 Singleton() 語法建立實例 1 和實例 2 時,這兩個變數都會引用 Singleton 類別的同一個實例。因此,當使用嚴格相等運算子比較實例 1 === 實例 2 時,其計算結果為 true。 **工廠模式** 工廠模式提供了一種建立物件而無需指定其特定類別的方法。它將物件建立邏輯封裝在一個單獨的工廠方法中,允許建立者和建立的物件之間的靈活性和解耦。 ``` // Implementation example of the Factory Pattern class Car { constructor(make, model) { this.make = make; this.model = model; } } class CarFactory { createCar(make, model) { return new Car(make, model); } } const factory = new CarFactory(); const myCar = factory.createCar("Tope", "Model 1"); ``` 在此範例中,使用 new CarFactory() 建立了一個 CarFactory 實例,然後使用參數「Tope」和「Model 1」在工廠上呼叫「createCar」方法。這將建立一個新的 Car 物件,其品牌為“Tope”,型號為“Model 1”,並分配給 `myCar` 變數。 **建構函式模式** 建構函式模式使用“new”關鍵字從建構函式建立物件。它允許您在建構函數中定義和初始化物件屬性。 ``` // Implementation example of the Constructor Pattern function Person(name, age) { this.name = name; this.age = age; } const tope = new Person("Tope", 24); ``` 上面的程式碼定義了一個名為 Person 的建構函數,它帶有兩個參數:姓名和年齡。在函數內部,使用 this 關鍵字將名稱和年齡值指派給新建立的物件的對應屬性。 稍後,透過使用參數“Tope”和 24 呼叫 Person 函數來建立 Person 物件的新實例。這將建立一個新物件,其 name 屬性設為“Tope”,age 屬性設為 24,然後指派給變數top。這段程式碼的輸出是 Tope 持有一個物件,代表一個名為「Tope」、年齡為 24 歲的人。 **原型模式** JavaScript 中的原型模式專注於透過複製或擴展現有物件作為原型來建立物件。它允許我們建立新實例而無需明確定義它們的類別。在此模式中,物件充當建立新物件的原型,從而實現繼承以及在多個物件之間共享屬性和方法。 ``` // Prototype object const carPrototype = { wheels: 4, startEngine() { console.log("Engine started."); }, stopEngine() { console.log("Engine stopped."); } }; // Create new car instance using the prototype const car1 = Object.create(carPrototype); car1.make = "Toyota"; car1.model = "Camry"; // Create another car instance using the same prototype const car2 = Object.create(carPrototype); car2.make = "Honda"; car2.model = "Accord"; car1.startEngine(); // Output: "Engine started." car2.stopEngine(); // Output: "Engine stopped." ``` 在此範例中,汽車實例 car1 和 car2 是使用原型物件 carPrototype 建立的。 car1 的品牌為“Toyota”,型號為“Camry”,而 car2 的品牌為“Honda”,型號為“Accord”。當呼叫 `car1.startEngine()` 時,輸出“Engine started.”,當呼叫 `car2.stopEngine()` 時,輸出“Engine waiting.”。這示範如何利用原型物件在多個實例之間共用屬性和方法。 **建造者模式** 在建構器模式中,建構器類別或物件負責建構最終物件。它提供了一組方法來配置和設定正在建置的物件的屬性。建置過程通常涉及按特定順序呼叫這些方法來逐步建立物件。 ``` class CarBuilder { constructor() { this.car = new Car(); } setMake(make) { this.car.make = make; return this; } setModel(model) { this.car.model = model; return this; } setEngine(engine) { this.car.engine = engine; return this; } setWheels(wheels) { this.car.wheels = wheels; return this; } build() { return this.car; } } class Car { constructor() { this.make = ""; this.model = ""; this.engine = ""; this.wheels = 0; } displayInfo() { console.log(`Make: ${this.make}, Model: ${this.model}, Engine: ${this.engine}, Wheels: ${this.wheels}`); } } // Usage const carBuilder = new CarBuilder(); const car = carBuilder.setMake("Toyota").setModel("Camry").setEngine("V6").setWheels(4).build(); car.displayInfo(); // Output: Make: Toyota, Model: Camry, Engine: V6, Wheels: 4 ``` 在此範例中,「CarBuilder」類別允許建構具有不同屬性的 Car 物件。透過呼叫`setMake`、`setModel`、`setEngine`、`setWheels`方法,設定Car物件的屬性。 build 方法完成建置並傳回完全建置的 Car 物件。 Car 類別代表一輛汽車,並包含一個「displayInfo」方法來記錄其詳細資訊。透過建立「carBuilder」實例並連結屬性設定方法,可以使用特定的品牌、型號、引擎和車輪值來建構汽車物件。呼叫“car.displayInfo()”顯示汽車的資訊。 **模組模式** 模組模式將相關的方法和屬性封裝到單一模組中,提供了一種乾淨的方式來組織和保護程式碼。它允許私有和公共成員,從而實現資訊隱藏並防止全域名稱空間污染。 ``` const MyModule = (function() { // Private members let privateVariable = "I am private"; function privateMethod() { console.log("This is a private method"); } // Public members return { publicVariable: "I am public", publicMethod() { console.log("This is a public method"); // Accessing private members within the module console.log(privateVariable); privateMethod(); } }; })(); // Usage console.log(MyModule.publicVariable); // Output: "I am public" MyModule.publicMethod(); // Output: "This is a public method" "I am private" "This is a private method" ``` 在此範例中,程式碼使用立即呼叫的函數表達式來封裝私人和公共成員。該模組具有私有變數和方法,以及公共變數和方法。存取時,公共成員提供預期的輸出。此模式允許對封裝的私有成員進行受控存取,同時公開選定的公共成員。 - **結構模式** 結構模式著重於組織和組合物件以形成更大的結構。它們促進物件的組合,定義物件之間的關係並提供靈活的方法來操縱其結構。 JavaScript 中一些常用的結構模式包括: - 裝飾模式 - 立面圖案 - 適配器 - 橋 - 合成的 **裝飾器模式** 裝飾器模式可讓您動態新增行為或修改物件的現有行為。它透過用一個或多個裝飾器包裝物件來增強物件的功能,而無需修改其結構。 ``` // Implementation example of the Decorator Pattern class Coffee { getCost() { return 1; } } class CoffeeDecorator { constructor(coffee) { this.coffee = coffee; } getCost() { return this.coffee.getCost() + 0.5; } } const myCoffee = new Coffee(); const coffeeWithMilk = new CoffeeDecorator(myCoffee); console.log(coffeeWithMilk.getCost()); // Output: 1.5 ``` 在此範例中,「CoffeeDecorator」類別包裝了基本「Coffee」物件並新增了附加功能。它有一個「getCost」方法,透過將基礎咖啡的成本與 0.5 的附加成本相結合來計算總成本。 在使用部分,建立了「Coffee」類別的「myCoffee」實例。然後,實例化「CoffeeDecorator」類別的「coffeeWithMilk」實例,並將「myCoffee」作為參數傳遞。當呼叫“coffeeWithMilk.getCost()”時,它會返回咖啡的總成本以及裝飾器加入的成本,從而得到 1.5 的輸出。此範例說明了裝飾器模式如何透過動態新增或修改物件的屬性或方法來擴展物件的功能。 **立面圖案** 外觀模式為複雜子系統提供了一個簡化的接口,充當隱藏底層實現細節的前端接口。它透過提供高級接口,提供了一種與複雜系統互動的便捷方式。 ``` // Implementation example of the Facade Pattern class SubsystemA { operationA() { console.log("Subsystem A operation."); } } class SubsystemB { operationB() { console.log("Subsystem B operation."); } } class Facade { constructor() { this.subsystemA = new SubsystemA(); this.subsystemB = new SubsystemB(); } operation() { this.subsystemA.operationA(); this.subsystemB.operationB(); } } const facade = new Facade(); facade.operation(); // Output: "Subsystem A operation." "Subsystem B operation." ``` 在此範例中,程式碼由三個類別組成:「SubsystemA」、「SubsystemB」和「Facade」。 `SubsystemA` 和 `SubsystemB` 類別代表獨立的子系統,並具有各自的 `operationA` 和 `operationB` 方法。 「Facade」類別作為一個簡化的接口,聚合了子系統的功能。 在使用部分,建立了“Facade”類別的“facade”實例。呼叫「facade.operation()」會觸發「SubsystemA」中的「operationA」和「SubsystemB」中的「operationB」的執行。結果,輸出顯示“子系統 A 操作”。接下來是「子系統 B 操作」。這展示了外觀模式如何提供統一且簡化的介面來與複雜的子系統交互,抽像出它們的複雜性並使它們更易於使用。 **適配器模式** 適配器模式是一種結構設計模式,它允許具有不相容介面的物件透過充當它們之間的橋樑來進行協作。它提供了一種將一個物件的介面轉換為客戶期望的另一個介面的方法。 ``` // Implementation class LegacyPrinter { printLegacy(text) { console.log(`Legacy Printing: ${text}`); } } // Target interface class Printer { print(text) {} } // Adapter class PrinterAdapter extends Printer { constructor() { super(); this.legacyPrinter = new LegacyPrinter(); } print(text) { this.legacyPrinter.printLegacy(text); } } // Usage const printer = new PrinterAdapter(); printer.print("Hello, World!"); // Output: "Legacy Printing: Hello, World!" ``` 在此程式碼中,適配器模式用於彌合「LegacyPrinter」類別和所需的「Printer」介面之間的差距。 `PrinterAdapter` 擴展了 `Printer` 類,並在內部利用 `LegacyPrinter` 來適配 `print` 方法。當呼叫 printer.print("Hello, World!")` 時,它會有效地觸發舊版列印功能,並輸出「Legacy Printing: Hello, World!」。這展示了適配器模式如何透過提供標準化介面來整合不相容的元件。 **橋樑圖案** 橋接模式是一種結構設計模式,它將系統的抽象和實現分開,允許系統獨立發展。它透過使用介面或抽象類別在兩者之間引入了橋樑。下面是一個範例程式碼片段來說明橋接模式: ``` // Example class Shape { constructor(color) { this.color = color; } draw() {} } // Concrete Abstractions class Circle extends Shape { draw() { console.log(`Drawing a ${this.color} circle`); } } class Square extends Shape { draw() { console.log(`Drawing a ${this.color} square`); } } // Implementor class Color { getColor() {} } // Concrete Implementors class RedColor extends Color { getColor() { return "red"; } } class BlueColor extends Color { getColor() { return "blue"; } } // Usage const redCircle = new Circle(new RedColor()); redCircle.draw(); // Output: "Drawing a red circle" const blueSquare = new Square(new BlueColor()); blueSquare.draw(); // Output: "Drawing a blue square" ``` 在此範例中,我們有由 Shape 類別表示的抽象,它具有顏色屬性和繪製方法。具體抽象(圓形和方形)繼承自 Shape 類別並實現其特定的繪製行為。 「Implementor」由 Color 類別表示,該類別聲明了「getColor」方法。具體的「Implementors」、「RedColor」和「BlueColor」繼承自 Color 類別並提供各自的顏色實作。 在使用部分,我們建立具體抽象的實例,傳遞適當的具體實現者物件。這允許抽象化將與顏色相關的功能委託給實現者。當我們呼叫draw方法時,它會從Implementor存取顏色並相應地執行繪圖操作。 **複合模式** 組合模式是一種結構設計模式,可讓您統一處理單一物件和物件組合。它使您能夠建立層次結構,其中每個元素都可以被視為單個物件或物件集合。此模式使用通用介面來表示單一物件(葉節點)和組合(複合節點),允許客戶端與它們統一互動。 ``` // Implementation class Employee { constructor(name) { this.name = name; } print() { console.log(`Employee: ${this.name}`); } } // Composite class Manager extends Employee { constructor(name) { super(name); this.employees = []; } add(employee) { this.employees.push(employee); } remove(employee) { const index = this.employees.indexOf(employee); if (index !== -1) { this.employees.splice(index, 1); } } print() { console.log(`Manager: ${this.name}`); for (const employee of this.employees) { employee.print(); } } } // Usage const john = new Employee("John Doe"); const jane = new Employee("Jane Smith"); const mary = new Manager("Mary Johnson"); mary.add(john); mary.add(jane); const peter = new Employee("Peter Brown"); const bob = new Manager("Bob Williams"); bob.add(peter); bob.add(mary); bob.print(); ``` 在此範例中,我們有 Component 類別 Employee,它代表個別員工。 Composite 類 Manager 擴展了 Employee 類,並且可以包含員工的集合。它提供了在集合中新增和刪除員工的方法,並重寫 print 方法以顯示經理的姓名及其下的員工。 在使用部分,我們建立一個複合層次結構,其中 Manager 物件可以包含單一員工 (Employee) 和其他經理 (Manager)。我們將員工加入經理中,建構了一個層次結構。最後,我們呼叫頂級經理的 print 方法,該方法遞歸地列印層次結構,顯示經理及其各自的員工。 - **行為模式** 行為模式關注物件之間的互動和職責分配。它們為物件之間的通訊、協調和協作提供解決方案。以下是行為模式的類型。 - 觀察者模式 - 策略模式 - 命令模式 - 迭代器模式 - 調解者模式 **觀察者模式** 觀察者模式在物件之間建立一對多關係,其中多個觀察者會收到主體狀態變化的通知。它支援物件之間的鬆散耦合並促進事件驅動的通訊。 ``` // Implementation example of the Observer Pattern class Subject { constructor() { this.observers = []; } addObserver(observer) { this.observers.push(observer); } removeObserver(observer) { const index = this.observers.indexOf(observer); if (index !== -1) { this.observers.splice(index, 1); } } notifyObservers() { this.observers.forEach((observer) => observer.update()); } } class Observer { update() { console.log("Observer is notified of changes."); } } const subject = new Subject(); const observer1 = new Observer(); const observer2 = new Observer(); subject.addObserver(observer1); subject.addObserver(observer2); subject.notifyObservers(); // Output: "Observer is notified of changes." "Observer is notified of changes." ``` 在此範例中,「Subject」類別表示一個主題,它維護觀察者清單並提供新增、刪除和通知觀察者的方法。 「Observer」類別透過其「update」方法定義觀察者的行為。在使用部分,建立了「Subject」類別的「subject」實例。也使用“addObserver”方法建立兩個“observer”實例並將其新增至主題。 當呼叫“subject.notifyObservers()”時,它會觸發每個觀察者的“update”方法。結果,輸出「觀察者收到更改通知」。被記錄兩次,顯示觀察者已被告知主題的變化。 **策略模式** 策略模式可讓您將可互換的演算法封裝在單獨的策略物件中。它支援在執行時動態選擇演算法,從而提高靈活性和可擴展性。 ``` // Implementation example of the Strategy Pattern class Context { constructor(strategy) { this.strategy = strategy; } executeStrategy() { this.strategy.execute(); } } class ConcreteStrategyA { execute() { console.log("Strategy A is executed."); } } class ConcreteStrategyB { execute() { console.log("Strategy B is executed."); } } const contextA = new Context(new ConcreteStrategyA()); contextA.executeStrategy(); // Output: "Strategy A is executed." const contextB = new Context(new ConcreteStrategyB()); contextB.executeStrategy(); // Output: "Strategy B is executed." ``` 在此範例中,「Context」類別表示封裝不同策略的上下文,具有「strategy」屬性和「executeStrategy」方法。有兩個特定策略類,“ConcreteStrategyA”和“ConcreteStrategyB”,每個類別都有自己的“execute”方法來輸出特定訊息。 在使用部分,使用“ConcreteStrategyA”作為策略來建立“Context”類別的“contextA”實例。呼叫 `contextA.executeStrategy()` 會呼叫 `ConcreteStrategyA` 的 `execute` 方法,導致輸出「策略 A 已執行」。類似地,以「ConcreteStrategyB」為策略建立「contextB」實例,呼叫「contextB.executeStrategy()」會觸發「ConcreteStrategyB」的「execute」方法,從而輸出「策略 B 已執行」。這演示了策略模式如何透過將行為封裝在不同的策略物件中來允許在執行時動態選擇行為。 **命令模式** 命令模式將請求封裝為物件,允許您使用不同的請求對客戶端進行參數化、對請求進行排隊或記錄請求,並支援撤銷操作。它將請求的發送者與接收者解耦,從而促進鬆散耦合和靈活性。 ``` // Implementation class Receiver { execute() { console.log("Receiver executes the command."); } } class Command { constructor(receiver) { this.receiver = receiver; } execute() { this.receiver.execute(); } } class Invoker { setCommand(command) { this.command = command; } executeCommand() { this.command.execute(); } } const receiver = new Receiver(); const command = new Command(receiver); const invoker = new Invoker(); invoker.setCommand(command); invoker.executeCommand(); // Output: "Receiver executes the command." ``` 在此範例中,「Receiver」類別在呼叫時執行命令,「Command」類別封裝命令並將執行委託給接收者。 `Invoker` 類別設定並執行命令。在使用部分,建立了接收者、命令和呼叫者。此指令是為呼叫者設定的,呼叫「invoker.executeCommand()」會執行該指令,從而產生輸出「接收者執行該指令」。 **迭代器模式** 迭代器模式是一種行為設計模式,它提供了一種順序存取聚合物件的元素而不暴露其底層表示的方法。它允許您以統一的方式遍歷物件集合,而不管集合的具體實現如何。該模式將遍歷邏輯與集合分開,從而促進了一種乾淨而靈活的方法來迭代元素。 ``` // Implementation class Collection { constructor() { this.items = []; } addItem(item) { this.items.push(item); } createIterator() {} } // Concrete Aggregate class ConcreteCollection extends Collection { createIterator() { return new ConcreteIterator(this); } } // Iterator class Iterator { constructor(collection) { this.collection = collection; this.index = 0; } hasNext() {} next() {} } // Concrete Iterator class ConcreteIterator extends Iterator { hasNext() { return this.index < this.collection.items.length; } next() { return this.collection.items[this.index++]; } } // Usage const collection = new ConcreteCollection(); collection.addItem("Item 1"); collection.addItem("Item 2"); collection.addItem("Item 3"); const iterator = collection.createIterator(); while (iterator.hasNext()) { console.log(iterator.next()); } ``` 在此程式碼中,我們有由 Collection 類別表示的 Aggregate,它定義了用於建立迭代器物件的介面。具體聚合「ConcreteCollection」擴展了 Collection 類別並提供了迭代器建立的具體實作。 Iterator 由 Iterator 類別表示,它定義了存取和遍歷元素的介面。具體迭代器“ConcreteIterator”擴展了迭代器類別並提供了迭代邏輯的具體實作。在使用部分,我們建立一個 Concrete Aggregate 的實例“ConcreteCollection”,並向其中新增專案。然後我們使用 createIterator 方法建立一個迭代器。透過使用迭代器的“hasNext”和 next 方法,我們迭代集合併列印每個專案。 **調解者模式** 中介者模式透過引入充當協調物件之間互動的中心樞紐的中介者物件來簡化物件溝通。它封裝了通訊邏輯,並為物件提供了註冊、發送和接收訊息的方法。 ``` // Implementation class Mediator { constructor() { this.colleague1 = null; this.colleague2 = null; } setColleague1(colleague) { this.colleague1 = colleague; } setColleague2(colleague) { this.colleague2 = colleague; } notifyColleague1(message) { this.colleague1.receive(message); } notifyColleague2(message) { this.colleague2.receive(message); } } class Colleague { constructor(mediator) { this.mediator = mediator; } send(message) { // Send a message to the mediator this.mediator.notifyColleague2(message); } receive(message) { console.log(`Received message: ${message}`); } } // Usage const mediator = new Mediator(); const colleague1 = new Colleague(mediator); const colleague2 = new Colleague(mediator); mediator.setColleague1(colleague1); mediator.setColleague2(colleague2); colleague1.send("Hello Colleague 2!"); // Output: "Received message: Hello Colleague 2!" ``` 在此範例中,我們有一個 Mediator 類,它充當兩個 Colleague 物件之間的中介。中介者保存對同事的引用並提供在他們之間發送訊息的方法。 每個Colleague物件都有一個對中介者的引用,並且可以透過通知中介者來發送訊息。調解員又將訊息轉發給適當的同事。在這種情況下,同事 1 會向同事 2 發送訊息,後者接收並記錄該訊息。 ### 結論 我們探索了 JavaScript 中的一系列基本設計模式,包括建立模式、結構模式和行為模式。建立模式使我們能夠以靈活且高效的方式建立物件。結構模式有助於器官的靈活性和可擴展性。行為模式支援 JavaScript 物件之間的有效溝通和互動。透過利用這些設計模式,JavaScript 開發人員可以提高程式碼的可重複使用性、可維護性和整體系統效能。有了這些知識,我們就可以建立健壯且高效的 JavaScript 應用程式,以滿足現代軟體開發的需求。 --- 原文出處:https://dev.to/topefasasi/js-design-patterns-a-comprehensive-guide-h3m