管理社區是一項艱鉅的工作，但經過幾年的努力，它就變得容易了。這是我們社區的第一個月，我想向您展示我們迄今為止所取得的成就。 如果您打算經營一個社區甚至加入一個社區，本系列將以[地下室開發人員](https://discord.gg/basementdevs)為例向您展示如何衡量社區的健康狀況。 目錄 -- - [一、整體成就](#1-general-achievements) - [2. 人口統計](#1-demographics) ``` * [2.1 New Members](#21-new-members) ``` ``` * [2.2 Members Activation](#22-members-activation) ``` ``` * [2.3 Member Visits & Comunicators](#23-member-visits-amp-comunicators) ``` - [3. 活動](#3-events) - [4. 合作夥伴](#4-partnerships) - [5. 發佈內容](#5-published-content) - [6. 現在怎麼辦？](#6-what-now) 一、整體成就 ------ 首先，我要感謝加入社群的幾位讀者。現在我們有幾個波蘭人每天在那裡參與活動。 > 僅供參考：社群正在尋找像您這樣的成員，所以請盡快加入我們！ ：D  我們最新的每週例會人數達到了 71 人的高峰。 自從我們建立社群以來，我們的每週會議一直是討論新機會、專案和其他機會，並聽取成員意見的地方。 < 視訊控制樣式=“高度：100％；”> 您的瀏覽器不支援影片標籤。 說到社群回饋，我們的大多數成員都是想要習慣英語的巴西人，因此社群中製作的第一個專案是一個覆蓋層，用於將我們在每週會議中所說的所有內容從英語翻譯成巴西葡萄牙語！為[Pantotone](https://github.com/Pantotone)乾杯，這個神奇工具的創造者！  此外，由於我們開始建立專案，因此建立了一個新的 GitHub 組織來託管與我們社區相關的所有專案。不要忘記[關注我們的社區](https://github.com/basementdevs)以獲取最新的專案更新！ 2. 人口統計 ------- 當我們談論成長時，我們談論的是數字！以下是**1 月 14 日至 2 月 12 日**的回顧。 ### 2.1 新成員 自 1 月 15 日起，我們的會員人數增加了一倍！目前我們的伺服器上有 2197 名活躍會員，其中許多人每天都在不同風格的語音頻道（小組或一對一）和文字頻道中練習英語。  ### 2.2 會員激活 我們本月將研究的指標之一是新成員的“激活”，即他們了解社區的含義以及為什麼它非常適合他們。  我們在第一個月做得很好，你可以看到圖表直接到底部，但這只是因為上週我們在巴西舉辦了**狂歡**節，所以這是預料之中的，我們的巴西開發商值得參加這個令人驚嘆的活動和一個愉快的假期。 ### 2.3 會員來訪及溝通  我們的平均溝通者數量或參與度是 8%。我們的目標是到 3 月底達到 15%。我們要怎麼做呢？我還不知道，但有了這份每週活動列表，這應該是個不錯的選擇。 3. 活動 ----- 活動是我們社區的核心，上個月舉辦了 16 場預先安排的活動，分為 5 個模式： - **地下室會議：**我們的每週會議於每週二晚上 07:00 BRT 舉行。其目的是分享我們社區的計劃、宣布新的合作夥伴關係、向成員通報最新訊息，當然還有練習英語。 - **和雷納託一起練習：**每週三，我們的社區都會聚在一起和雷納託一起練習英語。在這次練習中，我們的成員會得到一個主題，每個人都與雷納托就這個主題進行對話，總是引入新單字來擴大社群的詞彙量。 - **與JP一起旅行：**在本次會議中，我們的會員將與JP一起計劃他們的夢想旅行，討論費用、參觀地點、當地美食等等！快來和我們一起規劃您的旅程。 - **與李奧納多一起練習：**每週四早上，我們的社區都會與李奧納多一起參加英語練習課程。參與者被分配一個主題並與李奧納多對話，融入新單字建立詞彙量。 - **Coding Dojo：**二月初，我們推出了 Basement Coding Dojo，這是一項社群成員在模擬衝刺期間在開發團隊中扮演角色的活動。我們的第一個 Dojo 開發團隊由[Gabriel](https://github.com/gvieiragoulart) 、 [Lorena](https://github.com/Lorenalgm) 、 [Lucas](https://github.com/lucas-pace) 、 [Pedro](https://github.com/pedrovian4) 、 [Renato](https://github.com/reenatoteixeira)和[Yuri](https://github.com/yurastico)組成。在一個月的時間裡，團隊的目標是建立一個簡單但完整的應用程式，從事設計、後端和前端工作，參加每週會議並與開源專案互動。您可以在[此存儲庫](https://github.com/basementdevs/english-coding-dojo)中找到有關此事件的更多資訊。 4. 合作夥伴 ------- 現在我們最大的目標是找到HR公司甚至是正在積極招募開發人員的公司。 這個月，我們的目標是建立一個人口統計資料，提供更多有關有趣事物的訊息，為我們的會員帶來這些機會，例如：資歷、堆疊等。到目前為止，我們已經取得了一些成果，但還沒有什麼意義，因為這對我們來說是一種新方法。  如果您的公司有空缺職位，請發送電子郵件至 [email protected]，我會將其轉發給我們最好的會員進行申請！ 5. 發佈內容 ------- 上個月，我們社群的成員在這個平台上發表的文章獲得了多項認可。我們想重點介紹以下文章，這些文章是其發布週中最相關的文章（前 7 名）。 {% 嵌入 https://dev.to/danielhe4rt/database-101-how-to-model-leaderboards-for-1m-players-game-2pfa %} 「在他的『Database 101』系列的最新一期中，@danielhe4rt 探索了為擁有100 萬玩家的遊戲排行榜建模的複雜藝術。本文借鑒開源節奏遊戲YARG 的個人經驗並利用ScyllaDB 的效率，深入研究了查詢驅動的資料建模和寬列資料庫概念，為製作高性能排行榜提供了全面的指南。” {% 嵌入 https://dev.to/reenatoteixeira/everything-that-you-need-to-know-about-git-2440 %} 「透過這份全面的初學者指南，探索GIT 的程式碼版本控制世界！這篇突破性文章由首次DEV 貢獻者@reenatoteixeira 撰寫，精心解開了GIT 的所有要點，確保學習之旅順利進行。具有清晰的解釋和詳細的步驟-通過逐步指導，您將掌握 GIT 的藝術，為您提供無縫的版本控制功能。” {% 嵌入 https://dev.to/kecbm/staircase-detail-112g %} 透過我們的貢獻者@kebcm 建立的這個精彩的分步教程，了解如何為初學者在編程中建立樓梯！樓梯是由一系列台階形成的視覺表示，每個台階都由 # 字元表示。探索如何建立列印自訂尺寸樓梯的函數。 {% 嵌入 https://dev.to/anthonyvii/be-a-better-developer-with-these-git-good-practices-2dim %} 如果您是開發人員，您可能會經常使用 Git。無論是單獨還是團隊開發，這對於應用程式開發都至關重要。但許多人都在與混亂的儲存庫和不清楚的提交訊息/分支名稱作鬥爭。學好 Git 並堅持最佳實踐是職業發展的關鍵之一。 6. 現在怎麼辦？ --------- 到目前為止，我們的社區正在以一種我們意想不到的方式發展，但仍然以健康的方式發展。許多以前從未嘗試過**技術英語**的人已經邁出了練習的第一步，並開始**看到新的可能性**，這就是我們需要的燃料。 如果您想成為這一變革之旅的一部分，請加入我們的[Discord 伺服器](https://discord.gg/basementdevs)，並且不要忘記喜歡和評論本文！ 歡迎任何讓我們的社區變得更好的建議，好嗎？保持水分，下個月見！ > 順便說一句，**雷納托**和**安東尼**在這份報告中幫助我乾杯：D --- 原文出處：https://dev.to/danielhe4rt/what-weve-achieved-with-1-month-of-basement-devs-3pec
DevOps 是 IT 產業中一個快速發展的領域。作為一名 DevOps 工程師，跟上開發空間以避免落後至關重要。 GitOPs 是該領域已經發展成熟的流行範例。 **GitOps**是一種 DevOps 框架或實踐，透過它，我們使 Git 儲存庫成為單一事實來源，同時將 CI/CD 和版本控制應用於基礎設施自動化。 [紅帽](https://www.redhat.com/en/topics/devops/what-is-gitops)將其定義為「使用 Git 儲存庫作為單一事實來源來交付基礎設施即程式碼」。 另一方面， **[DevSecOps](https://aws.amazon.com/what-is/devsecops/#:~:text=DevSecOps%20is%20the%20practice%20of,is%20both%20efficient%20and%20secure.)**是 DevOps 的新改進版本，它在 SDLC（軟體開發生命週期）中灌輸安全工具和控制措施。 devsecops 方法的主要目標是“將安全性左移”，即安全性應該從一開始就成為開發生命週期的一部分，而不是事後才想到。 在本專案指南中，我們將應用 GitOps 實踐，同時實作包含許多工具的高階端對端 DevSecOps 管道。 專案概況 ==== 這是一個由兩部分組成的專案。在第一部分中，我們將設定執行 CI 管道的 EC2 執行個體。 **若要了解如何使用 jenkins 建立標準的持續整合管道，請按[此處](https://dev.to/kelvinskell/a-practical-guide-to-building-a-standard-continuous-integration-pipeline-with-jenkins-2kp9)。** 在第二部分中，我們將設定 EKS 叢集、ArgoCD 用於持續交付，並配置 Prometheus 和 Grafana 用於應用程式監控。 在這個專案中，我們將涵蓋以下內容： **- 基礎架構即程式碼：**我們將使用 terraform 來設定我們的 EC2 執行個體以及 EKS 叢集。 **- Jenkins 伺服器設定：**在 Jenkins 伺服器上安裝和設定基本工具，包括 Jenkins 本身、Docker、OWASP 相依性檢查、Sonarqube 和 Trivy。 **- EKS 叢集部署：**利用 Terraform 建立 Amazon EKS 叢集，這是 AWS 上的託管 Kubernetes 服務。 **- 負載平衡器配置：**為 EKS 叢集配置 AWS 應用程式負載平衡器 (ALB)。 **- ArgoCD 安裝：**安裝並設定 ArgoCD 以實現持續交付和 GitOps。 **- Sonarqube 整合：**整合 Sonarqube 以在 DevSecOps 管道中進行程式碼品質分析。 **- 監控設定：**使用 Helm、Prometheus 和 Grafana 實現對 EKS 叢集的監控。 **- ArgoCD應用程式部署：**使用ArgoCD部署微服務應用程式，包括資料庫和入口元件。 第一部分：設定 CI 管道 ============= **- 第 1 步：設定 EC2 執行個體** 克隆[Git 儲存庫](https://github.com/Kelvinskell/microservices-devops-1)。 `cd`進入 terraform 目錄。 執行`terraform init` ，然後執行`terraform plan`以查看建議的基礎架構變更。 執行`terraform apply`來實作這些變更並配置實例。 此實例使用使用者資料進行引導，一旦配置完畢，將自動安裝 jenkins、sonarqube、trivy 和 docker。  **- 步驟2：修改應用程式程式碼** 這是一個簡單但關鍵的步驟。在您剛剛複製的儲存庫中包含的**Jenkinsfile**中，您必須將所有出現的「 **kelvinskell** 」變更為您的 DockerHub 使用者名稱。如果您想自己實施這個專案，這是非常有必要的。 **- 第 3 步：設定 Jenkins 伺服器** - 在瀏覽器上登入jenkins伺服器。  - 安裝建議的插件並完成註冊。 - 前往“管理Jenkins”、“插件”，然後安裝以下插件：Docker、Docker Commons、Docker pipeline、SonarQube Scanner、Sonar 品質門、SSH2 Easy、OWASP 依賴項檢查、OWASP Markup Formatter 插件、GitHub API pluin 和GitHub pipeline插件。  - 設定工具：前往 Dashborad > 管理 jenkins > 工具 **git安裝**  **聲納掃描器安裝**  **依賴性檢查**  **Docker安裝**  **- 第 4 步：配置 SonarQube** - 在瀏覽器上，連接到連接埠 9000 上的 Jenkins 伺服器 IP 位址並登入伺服器。 預設使用者名稱和密碼是“admin”。  登入後，按一下“手動”。  請按照上圖中的說明操作，然後按一下「設定」。 **注意：**您的專案金鑰必須完全是**newsread-microservices-application** 。這樣，您就不必編輯 Jenkinsfile。 - 選擇**“With Jenkins”**並選擇 GitHub 作為 DevOps 平台。  - 點擊**“配置分析”** ，在步驟3中，複製“sonar.projectKey”，稍後您將需要它。  - 點選「帳戶」>「我的帳戶」>「產生令牌」。 為其命名並點擊“生成”。  - 前往“管理 Jenkins”>“憑證” - 選擇 Secret tex 並貼上您剛剛複製的令牌。  - 現在前往 Jenkins 儀表板 > 設定 Jenkins > 系統 > Sonarqube 伺服器 > 新增 Sonarqube - 將其命名為“SonarQube Server”，輸入秘密令牌的伺服器 URL 和憑證 ID。 請注意，我們的伺服器 url 是 localhost，因為 SonarQube 與 jenkins 託管在同一台伺服器上。  - 點選“儲存”。 **- 第 5 步：整合您的 DockerHub 憑證** 此階段對於 Jenkins 存取您的 DockerHub 帳戶至關重要。 - 前往“管理 Jenkins”>“憑證”>“新增憑證”  **- 第 6 步：設定 Jenkins 管道** - 從 Jenkins 的儀表板中，按一下「新專案」並建立管道作業。  - 在“建置觸發器”下，選擇“觸發遠端建置”。  在「身份驗證令牌」方塊下設定秘密令牌。我們將在建立 GitHub Webhook 時使用它。 - 在管道下，確保參數設定如下： - 定義：來自 SCM 的管道腳本 - SCM：設定您的 SCM。確保只建立您的主分支。例如，如果您的主分支名為“main”，請將“\*/main”放在要建置的分支下。 - 腳本路徑：Jenkinsfile  **注意：**您必須將我的[儲存庫](https://github.com/Kelvinskell/microservices-devops-1)分叉到您自己的 GitHub 帳戶。這是您存取儲存庫並能夠對其進行配置所必需的。 完成此操作後，建立 GitHub 個人存取權杖。 我們將使用 GitHub PAT 從 Jenkins 向我們的儲存庫進行身份驗證。 - 連接到 EC2 實例，切換到 jenkins 用戶，建立 SSH 金鑰對。公鑰將作為您的 PAT 上傳到 GitHub，而私鑰將加入到我們的 Jenkins 配置中。  - 返回 Jenkins 伺服器，點擊“新增憑證”  錯誤訊息現已消失。  - 點選“儲存”。 **- 第 7 步：建立 GitHub WebHook** 這對於遠端觸發我們的詹金斯建置是必要的。 - 前往儲存庫的 GitHub Webhook 建立頁面並輸入以下資訊： URL：輸入以下 URL，根據需要替換 \*\*\* 之間的值： ``` ***JENKINS_SERVER_URL***/job/***JENKINS_JOB_NAME***/build?token=***JENKINS_BUILD_TRIGGER_TOKEN*** ```  **- 第 8 步：執行管道** 現在，我們已經完成了該管道的配置。是時候檢驗我們的工作了。 您可以透過進行變更並推送到 GitHub 儲存庫來觸發管道。如果正確配置了 Web hook 觸發器，這將自動啟動管道。 或者，您只需點擊“立即建置”即可執行管道。 如果一切都按預期配置，您將得到以下輸出：  結論 -- 我們現在已經結束了這個專案的第一部分。在第一部分中，我們配置並設定了持續整合管道。第二部分將涉及使用 ArgoCD 實施 GitOps。 我們將使用 terraform 配置 EKS 集群，然後使用 ArgoCD 持續部署到 EKS 集群。 這裡的想法是，您可以讓單獨的團隊管理流程的兩個部分 - 持續整合和持續部署。從而進一步解耦和簡化整個過程，同時使用 Git 作為我們的單一事實來源。 **PS：**我願意接受遠距 DevOps、雲端和科技寫作機會。 在[LinkedIn](https://linkedin.com/in/kelvin-onuchukwu-3460871a1)上與我聯絡。 --- 原文出處：https://dev.to/kelvinskell/advanced-end-to-end-devops-project-deploying-a-microservices-app-to-aws-eks-using-terraform-helm-jenkins-and-argocd-part-i-3a53
如果您是開發人員，您可能每天都會使用名為 Git 的版本控制系統。無論是團隊工作還是個人工作，該工具的使用對於應用程式的開發過程都至關重要。然而，通常會遇到混亂的儲存庫、提交的訊息不明確、無法傳達有用資訊以及濫用分支等問題。對於想要在就業市場中脫穎而出的人來說，了解如何正確使用 Git 並遵循良好實踐至關重要。 --- 目錄 -- 1. [Git 分支的命名約定](#naming-conventions) 2. [分支名稱約定前綴](#branch-names) 3. [提交訊息](#commit-message) 4. [常規提交](#conventional-commits) --- Git 分支的命名約定<a id="naming-conventions"></a> ------------------------------------------ 當我們使用程式碼版本控制時，我們應該遵循的主要良好實踐之一是為分支、提交、拉取請求等使用清晰且描述性的名稱。確保所有團隊成員的簡潔工作流程至關重要。除了提高生產力之外，記錄專案的開發過程還可以簡化團隊合作。透過遵循這些做法，您很快就會看到好處。 基於此，社群建立了一個您可以在專案中遵循的分支命名約定。以下專案的使用是可選的，但它們可以幫助提高您的開發技能。 **1.小寫：**分支名稱不要使用大寫字母，堅持小寫； **2. 連字符分隔：**如果您的分支名稱由多個單字組成，請用連字符分隔它們。遵循烤肉串慣例。避免 PascalCase、camelCase 或 Snake\_case； **3. (az, 0-9)：**分支名稱中僅使用字母數字字元和連字符。避免使用任何非字母數字字元； **4. 請不要使用連續的連字號（--）。**這種做法可能會令人困惑。例如，如果您有分支類型（例如功能、錯誤修復、修補程式等），請改用斜線 (/)； **5. 避免以連字符結尾分支名稱**。這是沒有意義的，因為連字符分隔單詞，並且末尾沒有單詞可以分隔； **6. 這個做法最重要：**使用描述性的、簡潔的、清晰的名稱來解釋分支上做了什麼； **分支名稱錯誤** - `fixSidebar` - `feature-new-sidebar-` - `FeatureNewSidebar` - `feat_add_sidebar` **好聽的支行名字** - 功能/新側邊欄 - 新增側邊欄 - 修補程式/取得歷史資料上的間隔查詢參數 --- 分支名稱約定前綴<a id="branch-names"></a> --------------------------------- 有時分支的目的並不明確。它可以是新功能、錯誤修復、文件更新或其他任何內容。為了解決這個問題，通常的做法是在分支名稱上使用前綴來快速解釋分支的用途。 - **feature：**它傳達了將要開發的新功能。例如， `feature/add-filters` ； - **發布：**用於準備新版本。前綴`release/`通常用於在合併來自分支主伺服器的新更新以建立版本之前執行諸如上次觸及和修訂之類的任務。例如， `release/v3.3.1-beta` ； - **bugfix：**它表示您正在解決程式碼中的錯誤，並且它通常與問題相關。例如， `bugfix/sign-in-flow` ； - **hotfix：**與bugfix類似，但它與修復生產環境中存在的嚴重錯誤有關。例如， `hotfix/cors-error` ； - **docs：**寫一些文件。例如， `docs/quick-start` ； 如果您正在使用任務管理工作流程，例如 Jira、Trello、ClickUp 或任何可以建立使用者故事的類似工具，則每張卡片都有一個關聯的編號。因此，通常在分行名稱的前綴上使用這些卡號。例如： - `feature/T-531-add-sidebar` - `docs/T-789-update-readme` - `hotfix/T-142-security-path` --- 提交訊息<a id="commit-message"></a> ------------------------------- 讓我們來談談提交訊息。不幸的是，很容易找到帶有“加入了很多東西”或“皮卡丘，我選擇你”之類的提交訊息的專案......是的，我曾經發現一個專案，其中提交訊息與神奇寶貝戰鬥有關。 提交訊息在開發過程中非常重要。創造一段美好的歷史將在你的旅程中給你很多幫助。與分支一樣，提交也有社區建立的約定，您可以在下面了解： - 提交訊息包含三個重要部分：主題、說明和頁腳。提交的主題是必要的，它定義了提交的目的。描述（正文）用於為提交的目的提供額外的上下文和解釋。最後是頁腳，通常用於元資料，例如分配提交。雖然同時使用描述和頁腳被認為是一種很好的做法，但這不是必需的。 - **在主題行中使用祈使語氣。**例如： > `Add README.md` ✅; > `Added README.md` ❌； > `Adding README.md` ❌； - **主題行的第一個字母大寫。**例如： > `Add user authentication` ✅； > `add user authentication` ❌； - **不要以句號結束主題行。**例如： > `Update unit tests` ✅； > `Update unit tests.` ❌; - 主題行限制在**50個字元**以內，即清晰、簡潔； - 將正文包裹在**72 個字元**處，並將主題與**空白行**分隔開； - 如果您的提交正文有多個段落，請**使用空白行將它們分開**； - 如有必要，使用**要點**而不是僅使用段落； --- 常規提交<a id="conventional-commits"></a> ------------------------------------- > “常規提交規範是基於提交訊息的輕量級約定。它提供了一組簡單的規則來建立明確提交歷史記錄。” 以下引用來自Conventional Commit 的官方網站。該規範是社區中提交訊息最常使用的約定。 ### 結構 ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ### 提交類型 我們要研究的第一個結構是提交類型。它提供了有關此提交中所做操作的清晰上下文。您可以在下面看到提交類型清單以及何時使用它們： - **feat：**引進新功能； - **fix：**修復軟體錯誤； - **refactor：**用於程式碼更改，保留其整體功能； - **chore：**不影響生產程式碼的更新，涉及工具、配置或程式庫調整； - **docs：**文件文件的新增或修改； - **perf：**程式碼更改提高效能； - **style：**與程式碼呈現相關的調整，例如格式和空白； - **test：**測試的包含或修正； - **build：**影響建置系統或外部依賴項的修改； - **ci：** CI 設定檔和腳本的更改； - **env：**描述 CI 流程中設定檔的調整或加入，例如容器配置參數。 ### 範圍 範圍是一種結構，可以在提交類型之後加入以提供額外的上下文資訊： - `fix(ui): resolve issue with button alignment` - `feat(auth): implement user authentication` ### 身體 提交訊息的正文提供了提交引入的更改的詳細說明。它通常會加入在主題行後面的空白行之後。 **例子：** ``` Add new functionality to handle user authentication. This commit introduces a new module to manage user authentication. It includes functions for user login, registration, and password recovery. ``` ### 頁尾 提交訊息的頁腳用於提供與提交相關的附加資訊。這可以包括諸如誰審查或批准了變更之類的詳細資訊。 **例子：** ``` Signed-off-by: John <[email protected]> Reviewed-by: Anthony <[email protected]> ``` ### 突破性變革 指示提交包含可能導致相容性問題或需要修改相關程式碼的重大變更。您可以在頁腳中新增`BREAKING CHANGE`或包含`!`在類型/範圍之後。 ### 使用常規提交的提交範例 ``` chore: add commitlint and husky chore(eslint): enforce the use of double quotes in JSX refactor: type refactoring feat: add axios and data handling feat(page/home): create next routing chore!: drop support for Node 18 ``` **包含主題、正文和頁尾：** ``` feat: add function to convert colors in hexadecimal to rgba Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s. Reviewed-by: 2 Refs: #345 ``` --- 參考 -- - <https://www.conventionalcommits.org> - <https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534> - <https://se-education.org/guides/conventions/git.html> - <https://cbea.ms/git-commit/> https://blog.geekhunter.com.br/o-que-e-commit-e-como-usar-commits-semanticos/ --- 原文出處：https://dev.to/anthonyvii/be-a-better-developer-with-these-git-good-practices-2dim
介紹 -- 過去一年，生成式人工智慧一直是科技領域的熱門話題。每個人都在使用它來建造很酷的專案。谷歌有自己的生成人工智慧，稱為 Gemini。 最近，Google 為 Gemini 開發者推出了 API。它附帶了幾個庫和框架，開發人員可以使用它們將其合併到他們的應用程式中。 在本文中，我們將建立一個簡單的 Node.js 應用程式並將 Google Gemini 整合到其中。我們將使用[**Google Gemini SDK**](https://www.npmjs.com/package/@google/generative-ai) 。 那麼，事不宜遲，讓我們開始吧！ 什麼是雙子座？ -------  Google Gemini 是由 Google AI 開發的強大且多方面的 AI 模型。 Gemini 不僅處理文字；也處理文字。它可以理解和操作各種格式，如程式碼、音訊、圖像和視訊。這為您的 Node.js 專案帶來了令人興奮的可能性。 專案設定： ----- ### **1.建立Node.js專案：** 要啟動我們的專案，我們需要設定 Node.js 環境。那麼，讓我們建立一個節點專案。在終端機中執行以下命令。 ``` npm init ``` 這將初始化一個新的 Node.js 專案。 ### 2.安裝依賴項： 現在，我們將安裝專案所需的依賴項。 ``` npm install express body-parser @google/generative-ai dotenv ``` 這將安裝以下軟體包： - express：流行的 Node.js Web 框架 - body-parser：用來解析請求體的中介軟體 - @google/generative-ai：用於存取 Gemini 模型的套件 - dotenv：從 .env 檔案載入環境變數 ### 3.**設定環境變數：** 接下來，我們將建立一個`.env`資料夾來安全地儲存 API 憑證等敏感資訊。 ``` //.env API_KEY=YOUR_API_KEY PORT=3000 ``` ### 4.**取得API金鑰：** 在使用 Gemini 之前，我們需要從 Google Developers Console 設定 API 憑證。為此，我們需要註冊 Google 帳戶並建立 API 金鑰。 登入後，前往<https://makersuite.google.com/app/apikey> 。我們會得到這樣的結果：  然後我們將點擊“建立 API 金鑰”按鈕。這將產生一個唯一的 API 金鑰，我們將使用它來驗證對 Google Generative AI API 的請求。 > 要測試您的 API，您可以執行以下 Curl 命令： > > ```javascript > 捲曲\\ > -H '內容類型：application/json' \\ > -d '{"contents":\[{"parts":\[{"text":"寫一個關於魔法背包的故事"}\]}\]}' \\ > -X POST https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent?key=YOUR\_API\_KEY > ```` > > 將`YOUR_API_KEY`替換為我們先前獲得的實際 API 金鑰。 取得 API 金鑰後，我們將使用 API 金鑰更新`.env`檔。 ### 5. 建立 Express 伺服器： 現在，我們將在根目錄中建立一個`index.js`檔案並設定一個基本的express 伺服器。請看下面的程式碼： ``` const express = require("express"); const dotenv = require("dotenv"); dotenv.config(); const app = express(); const port = process.env.PORT; app.get("/", (req, res) => { res.send("Hello World"); }); app.listen(port, () => { console.log(`Server running on port ${port}`); }); ``` 在這裡，我們使用“dotenv”套件從`.env`檔案存取連接埠號碼。 在專案的頂部，我們使用`dotenv.config()`載入環境變數，使其可以在整個檔案中存取。 ### 6. 執行專案： 在此步驟中，我們將向`package.json`檔案新增一個啟動腳本，以輕鬆執行我們的專案。 因此，將以下腳本新增至 package.json 檔案中。 ``` "scripts": { "start": "node index.js" } ``` package.json 檔案應如下所示：  要檢查一切是否正常，讓我們使用以下命令執行該專案： ``` npm run start ``` 這將啟動 Express 伺服器。現在如果我們造訪這個 URL <http://localhost:3000/>我們會得到：  驚人的！專案設定已完成並且執行完美。接下來，我們將在下一節中將 Gemini 加入我們的專案中 新增Google雙子座： ------------ ### 1. 設定路由和中介軟體： 要將 Gemini 新增至我們的專案中，我們將建立一個`/generate`路由，以便與 Gemini AI 進行通訊。 為此，將以下程式碼新增至`index.js`檔案。 ``` const bodyParser = require("body-parser"); const { generateResponse } = require("./controllers/index.js"); //middleware to parse the body content to JSON app.use(bodyParser.json()); app.post("/generate", generateResponse); ``` 在這裡，我們使用`body-parser`中間件將內容解析為 JSON 格式。 ### 2.設定Google Generative AI： 現在，我們將建立一個控制器資料夾，並在其中建立一個`index.js`檔案。在這裡，我們將建立一個新的控制器函數來處理上面程式碼中聲明的生成路由。 ``` const { GoogleGenerativeAI } = require("@google/generative-ai"); const dotenv = require("dotenv"); dotenv.config(); // GoogleGenerativeAI required config const configuration = new GoogleGenerativeAI(process.env.API_KEY); // Model initialization const modelId = "gemini-pro"; const model = configuration.getGenerativeModel({ model: modelId }); ``` 在這裡，我們透過傳遞環境變數中的 API 金鑰來為 Google Generative AI API 建立一個配置物件。 然後，我們透過向配置物件的`getGenerativeModel`方法提供模型 ID（“gemini-pro”）來初始化模型。 > #### **型號配置：** > > 我們也可以依照自己的方便配置模型參數 > > 這些參數值控制模型如何產生回應。 > > 例子： > > ```javascript > 常量產生配置 = { > 停止序列：\[“紅色”\]， > 最大輸出令牌：200， > 溫度：0.9， > 頂部P：0.1， > 頂級K：16， > }; > > const model = configuration.getGenerativeModel({ model: modelId, GenerationConfig }); > ```` > #### **安全設定：** > > 我們可以使用安全設定來防止有害的反應。預設情況下，安全性設定配置為阻止在各個維度上具有中等到高可能性不安全的內容。 > > 這是一個例子： > > ```javascript > const { HarmBlockThreshold, HarmCategory } = require("@google/generative-ai"); > > 常量安全設定 = \[ > { > ``` > category: HarmCategory.HARM_CATEGORY_HARASSMENT, > > ``` > ``` > threshold: HarmBlockThreshold.BLOCK_ONLY_HIGH, > > ``` > }, > { > ``` > category: HarmCategory.HARM_CATEGORY_HATE_SPEECH, > > ``` > ``` > threshold: HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE, > > ``` > }, > \]; > > const model = genAI.getGenerativeModel({ model: "MODEL\_NAME", safetySettings }); > ```` > > 透過這些安全設置，我們可以透過最大限度地減少有害內容生成的可能性來增強安全性。 ### 3. 管理對話歷史記錄： 為了追蹤對話歷史記錄，我們建立了一個陣列`history`並將其從控制器檔案中匯出： ``` export const history = []; ``` ### 4.**實現控制器功能：** 現在，我們將編寫一個控制器函數`generateResponse`來處理產生路由（/generate）並產生對使用者請求的回應。 ``` /** * Generates a response based on the given prompt. * @param {Object} req - The request object. * @param {Object} res - The response object. * @returns {Promise} - A promise that resolves when the response is sent. */ export const generateResponse = async (req, res) => { try { const { prompt } = req.body; const result = await model.generateContent(prompt); const response = await result.response; const text = response.text(); console.log(text); history.push(text); console.log(history); res.send({ response: text }); } catch (err) { console.error(err); res.status(500).json({ message: "Internal server error" }); } }; ``` 在這裡，我們從請求正文中獲取提示，並使用`model.generateContent`方法根據提示產生回應。 為了追蹤響應，我們將響應推送到歷史陣列。 ### 5. 查看回覆紀錄： 現在，我們將建立一條路線來檢查我們的回應歷史記錄。該端點傳回`history`陣列。 將簡單程式碼加入`./index.js`資料夾中。 ``` app.get("/generate", (req, res) => { res.send(history); }); ``` 我們就完成了！ ### 6.執行專案： 現在，我們必須檢查我們的應用程式是否正常運作！ 讓我們使用以下命令來執行我們的專案： ``` npm run start ```  沒有錯誤！感謝上帝！ :) 它運作正常。 ### 7. 檢查功能 接下來，我們將使用 Postman 發出 Post 請求來驗證我們的控制器功能。 我們將使用以下 JSON 負載向<http://localhost:3000/generate>發送 POST 請求： ``` { "prompt": "Write 3 Javascript Tips for Beginners" } ```  我們得到了回應： ``` { "response": "1. **Use console.log() for Debugging:**\n - console.log() is a useful tool for debugging your JavaScript code. It allows you to inspect the values of variables and expressions, and to see how your code is executing. This can be especially helpful when you encounter errors or unexpected behavior in your program.\n\n2. **Learn the Basics of Data Types:**\n - JavaScript has several built-in data types, including strings, numbers, booleans, and objects. Understanding the properties and behaviors of each data type is crucial for writing effective code. For instance, strings can be manipulated using string methods, while numbers can be used in mathematical operations.\n\n3. **Use Strict Mode:**\n - Strict mode is a way to opt-in to a restricted and secure subset of JavaScript. It helps you to write more secure and reliable code, as it throws errors for common mistakes that would otherwise go unnoticed in regular JavaScript mode. To enable strict mode, simply add \"use strict;\" at the beginning of your JavaScript file or module." } ```  偉大的！我們的 Gemini AI 整合正在按預期工作！ 此外，我們可以造訪[http://localhost:3000/generate 的](http://localhost:3000/generate)歷史記錄端點來查看對話歷史記錄。 這樣，我們就將 Gemini AI 整合到了 Node.js 應用程式中。在接下來的文章中，我們將探索 Gemini AI 的更多用例。 到那時，請繼續關注！ 結論 -- 如果您發現這篇部落格文章有幫助，請考慮與可能受益的其他人分享。您也可以關注我，以了解更多有關 Javascript、React 和其他 Web 開發主題的內容。 要贊助我的工作，請存取： [Arindam 的贊助頁面](https://arindam1729.hashnode.dev/sponsor)並探索各種贊助選項。 在[Twitter](https://twitter.com/intent/follow?screen_name=Arindam_1729) 、 [LinkedIn](https://www.linkedin.com/in/arindam2004/) 、 [Youtube](https://www.youtube.com/channel/@Arindam_1729)和[GitHub](https://github.com/Arindam200)上與我聯絡。 感謝您的閱讀:)  --- 原文出處：https://dev.to/arindam_1729/how-to-use-google-gemini-with-nodejs-2d39
你能在 4 小時內完成你的作品集嗎？ 聽起來很瘋狂，對吧？ > 您的作品集是一個展示您最好的作品、個性和才能的網站。您可以被雇用，人們可以更多地了解您。 建立一個好的投資組合需要遵循各種規則，而條件取決於您的職業。例如，使用者體驗設計師與軟體開發人員的情況可能完全不同。 ### 我認為一個好的作品集應該是什麼樣的。 對我來說，這三件事對於一個好的作品集是必不可少的。 應該很**簡單**。**在職的**。**專業的**。 - 存取作品集的人的體驗應該很好。 - 此人應該能夠與您聯繫（通常是聯絡表單）。 - 作品集應該有一個故事和一點個人風格。 - 它應該放在網域上以提高可信度。 - 它不應該有太多會破壞這一刻的花俏動畫。 ### 為什麼你應該製作一個投資組合？ 擁有作品集是一種常見的做法，尤其是當您有多個東西要展示時。 > 並非每個人都有時間或資源來製作完全適合自己需求的獨特投資組合。 嗯，你不應該。 在這個不斷發展的世界中沒有必要。 沒有非常容易使用的程式碼工具。 但是你能在一天甚至一小時內製作出作品集嗎？ 我們無法製作最好的作品集，但我們可以製作一個效果良好的體面作品集。 如果您不喜歡這個也沒關係，因為我知道製作具有自己獨特風格的作品集需要花費很多時間。 每個人都有自己的經歷，每個人都試圖根據我們多年來所學到的知識互相幫助。 一點注意 ---- 我是使用者體驗法則的忠實粉絲，知道如何才能做到優秀。 我不會介紹像 Bubble、Framer、Wix 和 Squarespace 這樣的無程式碼工具，因為它們已經很流行了。 --- 我管理多個社群檔案，因此我總是糾結於將觀眾引導至哪些社群媒體。 大多數人都在努力擁有多個配置文件，您一定聽說過`linkfree`或`bento` 。 您不僅僅是一系列關於您的連結。 你必須講述你的故事。這個故事很重要。 作品集是實現這一目標的最佳方式，因此這裡有一些工具，對於想要快速獲得具有良好使用者體驗的作品集的人來說將很有幫助。 您可以使用每個選項連接到您的網域。 我敢打賭這篇文章會讓你大吃一驚。 那我們就開始吧。 --- 1.[聚合工作](https://www.polywork.com/invite/anmol_baranwal-voltorb) ---------------------------------------------------------------- Polywork 是 2022 年最好的產品之一。 它可以在幾秒鐘內將您的 LinkedIn 個人資料轉換為個人網站。 我是 Polywork 的忠實粉絲，因為製作獨特風格的作品集是多麼容易。它有一個圖形編輯器，可以讓你建立部分，你也可以在後台使用人工智慧。 相信我，這就是您所需要的一切。  最棒的是它是免費的，您可以以大約 96 美元購買一年。考慮到您將透過高級版本解鎖所有新`fonts` 、 `layouts`和`colors` ，這是一個相當不錯的交易。 這是來自其中一個模板。酷吧 :D  在免費版本中，您將獲得一個按鈕來隨機化您的作品集（不同的主題和佈局）。一定要嘗試！ 您可以加入這樣的個人化連結。  您可以建立亮點以及「關於我」、「社交連結」和個人化「標題」等部分。此外，還有超過 1,000 種針對不同個人資料量身定制的徽章供您選擇。  開箱即用的是，您可以控制您的`social card` 、 `metadata` ，甚至頁面`title` 。這使您可以完全控制，使您的投資組合看起來真實。  有很多話要說，但最方便的功能是有人可以多快與您聯繫。 就好像在短短幾秒鐘內，讓我們面對現實吧，這正是每個投資組合所需要的。  您可以查看我的[Polywork 個人資料](https://www.polywork.com/anmolbaranwal)作為樣本。  關於 Polywork 的最佳簡介之一來自 Craftwork 的共同創辦人[Mike Bifulco](https://www.polywork.com/irreverentmike) 。一探究竟！ > 在 Polywork 上創造一個好的作品集甚至不需要超過 4 小時。 2.[來自珍珠](https://peerlist.io/anmolbaranwal/signup) -------------------------------------------------- 我加入 Peerlist 已經幾個月了。我也是他們的測試版行動用戶之一。 除了可以使用同行清單做的其他事情之外，您還可以在網域上製作良好的投資組合。 讓我們討論其中的一些。   您可以在一個設定檔中包含所有內容。 - GitHub 個人資料、貢獻和固定儲存庫 - DEV + Hashnode + Medium 部落格文章 - YouTube影片 - 子堆疊 + RSS 來源 - Codeforces 和其他編碼設定文件 - 您甚至可以從 Product Hunt 加入您的狩獵或製造商產品 基本上一切:D   對等列表上還有一個集合的概念。我在其他地方見過這些，但是將這些放在您的個人資料中確實很棒。 您可以在一個地方新增社交資料卡。 以及您推薦的影片、書籍、播客或自訂內容。  您甚至可以找到工作並通過您的簡歷和經驗進行驗證。  您還可以做的另一件事是為某人提供擔保，這可以提高可信度並讓您在個人資料中具有明顯的優勢。它與LinkedIn上的推薦類似，但他們在卡片上做了一些創意。  您可以免費將您的個人資料連接到您的自訂網域。所以，這就是你的投資組合的樣子。  順便說一句，如果您想知道 -> 您的社交連結將位於底部。 您甚至可以讓您的專案在同行清單中受到關注：D 牽涉的事情很多，我無法一一列舉。 我將在後面的文章中介紹 Peerlist 中令人興奮的內容。 請注意！ 3.[展示](https://www.showwcase.com/) ---------------------------------- Showwcase 的主要目標是建立一個強大的開發者社群。 Showwcase 是我幾個月前使用的第一個。  一種簡單而強大的方式來展示您的故事。 最獨特的功能之一是您可以與 Stripe 連接，並且可以從付費追蹤者那裡賺錢。多麼酷啊？ 這些是您可以在自訂部分之外製作的一些部分。  您可以輕鬆加入社交連結並查看一些很棒的社區，例如`Open Source` 、 `Hackathons` 、 `Internships` 、 `Portfolios`等等。  您可以獲得推薦，甚至可以加入合作者，這是一件很划算的事情。我從一開始就對此感到驚訝。  您可以使用您的個人連結產生並製作適合 ATS 的簡歷。 例如，您可以[在這裡](https://www.showwcase.com/anmol-baranwal/resume/ats)找到我的。它使用網站資訊。順便說一下，我的個人資料沒有更新：D 這個社群非常龐大，我已經加入 Showwcase 幾個月了。  您可以在[anmol-baranwal.showwcase.com](https://anmol-baranwal.showwcase.com/)查看我的展示個人資料 請參閱 Showwcase 執行長[Rong](https://www.showwcase.com/tianrongliew)的簡介。 您可以在 Showwcase 進行招募和受聘。 我不喜歡簡歷功能，該功能只是從個人資料中收集資料。有履歷會更有利。 但 Showwcase 已經提供了超出您所需的功能。 4.[閱讀](https://read.cv/) ------------------------ 這是製作作品集的另一種方式。我喜歡 Read 的使用者介面。 最好的事情是有人可以隨時隨地與您聯繫，並且很容易找到帶有甜蜜表情符號的聯繫按鈕。它實際上鼓勵人們使用該聯繫部分。  您可以在 ReadCV 上查看[Edmundo Santos](https://read.cv/edmundo)的個人資料。非常棒。  有各種各樣的部分，如社交聯繫、經驗、副專案、演講、寫作等等。  您可以加入的部分數量令人難以置信。它為您在各個部分提供了很大的靈活性。  當然，還有職位列表和自訂網域，您可以將您的個人資料連結到其中。 佈局是固定的，但足以讓您入門。 我見過很多偉大的人使用“閱讀”作為他們的首選個人資料！ --- 這些是您可以使用的一些很棒的資源。 - [超過 25 個帶有程式碼的令人驚嘆的作品集](https://dev.to/anmolbaranwal/stunning-portfolios-that-will-blow-your-mind-fuel-your-creativity-226o) - [無需編碼即可建立令人驚嘆的網站的 20 個工具](https://dev.to/anmolbaranwal/20-game-changing-website-builders-to-build-classy-websites-without-coding-4ll7) - [開發人員的最小組合模板](https://github.com/cobiwave/simplefolio)- GitHub 上有 13k Stars --- 當您將個人資料連接到網域時，沒有人有時間查看您是否自己製作了作品集。只要它對你有用，那就太棒了。 你覺得有用嗎？ 除了 ReadCV（新手）之外，我已經嘗試了這些方法好幾個月了，直到那時我才讓你知道。 順便說一句，這些都沒有贊助。我希望如此。哈哈！ 如果你堅持使用那些簡單、無聊的工具，你就錯過了。在這個科技世界中，您可以毫無麻煩地建立您的投資組合。 程式設計師會否認建立這樣的作品集行不通，但這不是真的，如果它對你有用那就太好了。 我已經完成了 5000 多個小時的編程，我可以這麼說。 任何好的東西都比糟糕的投資組合好。 正如我在一開始所說的，如果您不想透過程式設計來建立原始作品集也沒關係，因為只有開發人員才應該使用程式碼來完成它。 您還需要什麼？ 匆忙！建立您的作品集並向世界展示:D 你認為哪個最好？我喜歡 Polywork & Read。兩者都是我在列表中使用最少的：D 我很高興我終於寫了這篇文章。 我透過深入研究並分享我的經驗來撰寫內容。您可以透過[在 GitHub 上贊助](https://github.com/sponsors/Anmol-Baranwal)我來支持我。 請在[GitHub](https://github.com/Anmol-Baranwal)和[Twitter](https://twitter.com/Anmol_Codes)上關注我:) > 如果您熱衷於贊助這篇文章，請給我發訊息 [email protected] 或在 Twitter 上聯繫我！ 🚀 {% 嵌入 https://github.com/Anmol-Baranwal %} 多寫，多啟發。  --- 原文出處：https://dev.to/anmolbaranwal/make-your-portfolio-in-just-4-hours-its-possible-2p3
利用 Rust 支援的後端框架與 React 前端相結合，提供出色的無瀏覽器體驗 ----------------------------------------  許多開發人員都可以告訴您他們對 JavaScript GUI 框架又愛又恨的關係，該框架幫助徹底改變了許多桌面應用程式的製作方式。事實上，我們今天使用的許多應用程式，無論是與開發、社交媒體、通信……凡是有關的應用程式，都是使用 Electron 框架建置的。 如果您好奇，請從其[網站](https://www.electronjs.org/apps)查看使用 Electron 的應用程式的精選清單。 --- 關鍵是，Electron 為具有 Web 開發經驗的開發人員提供了為多個平台建立獨立桌面應用程式的機會…所有這些都無需學習任何新的程式語言！它提供了使用我們許多人一直使用的相同 JavaScript、CSS 和 HTML 的能力，這當然是非常棒的！ 簡單總結一下 Electron 是如何做到這一點的： > Electron 是一個使用 JavaScript、HTML 和 CSS 建立桌面應用程式的框架。透過將 Chromium 和 Node.js 嵌入到其二進位檔案中，Electron 允許您維護一個 JavaScript 程式碼庫並建立可在 Windows、macOS 和 Linux 上執行的跨平台應用程式 - 無需本地開發經驗。 ---  --- 使用 Electron 建立桌面應用程式的最大缺點之一，正如你們中的一些人可能在 Stack Overflow 和其他論壇中看到的那樣…生成的二進位檔案往往非常大！如此之大，即使只是一個中等大小的程式碼庫也可能產生約 60MB 的最終二進位。 在親身經歷了這種挫敗感之後，我開始想知道是否有一個神奇的解決方案可以解決這個問題……事實證明， **Rust 恰好提供了一個！** ---  --- > Tauri 是一個工具包，可協助開發人員使用幾乎任何現有的前端框架為主要桌面平台開發應用程式。核心是用 Rust 建構的，CLI 利用 Node.js，使 Tauri 成為一種真正的多語言方法來建立和維護出色的應用程式。 ### 潛入 令我興奮的是，他們的命令列鷹架工具建立了使用熟悉的前端框架啟動和執行所需的所有 Rust 檔案。不僅如此，一旦我準備好開始將自己的功能加入到後端以供 UI 使用，Tauri 就可以讓一切工作變得相當無縫！ ---  --- 我決定嘗試讓 Tauri 為我計劃參與的一個社區專案建立一個新的桌面儀表板應用程式，劇透一下……**它並沒有讓人失望！** 正如我之前提到的，入門相當簡單： - 確保您的系統已安裝 Rust - 如果在 Windows 或 Linux 上，請確保安裝相關相依性 - 執行一個簡單的命令來設定您的專案 之後，問題是將前端原始檔全部放在一起，同時當我需要一些有關 UI 和後端之間的進程間通訊的指導時，偶爾會參考 Tauri 的文件。 --- {% 嵌入 https://gist.github.com/dedSyn4ps3/5703367578339fc8c3440ea8a09fa449 %} --- 使用 Tauri 建立儀表板的美妙之處在於，我不再需要為了能夠正確利用進程間通訊而建立單獨的`preload.js`檔案。 所需要的只是在我想要從 UI 呼叫的函數上方的`main.rs`中進行正確的註釋，以及在我的 React `jsx`檔案中加入一個簡單的導入行： `import { invoke } from '@tauri-apps/api/tauri'` 最終，Tauri 建置的應用程式的強大之處在於其後端使用 Rust。這使得像我這樣的開發人員能夠將他們的最終產品建置成本地執行的二進位文件，其大小只是許多 Electron 建置的應用程式的一小部分。 ### 結論 至少對我來說，很明顯，Tauri 肯定有潛力繼續發展，直至推翻 Electron 作為主導的「前端」GUI 框架。儘管由於是基於 Rust 建置的，可能會存在一些令人生畏的因素，但了解其內部結構所需的少量時間是非常值得的！ ---  --- 我鼓勵任何想要開始前端 GUI 開發之旅的人檢查 Tauri 框架，並抵制立即將 Electron 作為直接解決方案的衝動……我向你保證，你會感到驚訝！ 為了完整起見，您可以在我的 Gitlab 上找到我的社群專案的完整程式碼庫。如果您正在為自己的專案尋找任何想法，請檢查一下！ {% 嵌入 https://gitlab.com/dedSyn4ps3/enviroplus-desktop %} {% 嵌入 https://dev.to/dedsyn4ps3 %} {% cta https://github.com/dedsyn4ps3 %} 💻 也查看我的 Github！{% endcta %} --- 原文出處：https://dev.to/dedsyn4ps3/goodbye-electron-hello-tauri-26d5
介紹 -- 2024 年即將到來，我們努力為新的一年做計劃，思考來年我們可以做或學到的事情。現在是在新的一年中尋找要學習的框架、了解它們的功能並找出它們的特別之處的最佳時機。我們查看了 2023 年[JS 新星](https://risingstars.js.org/2023/en)名單以獲取指導，並試圖盡可能客觀。**對於每個特色框架，我們重點介紹了它們最大的優點，以便您可以了解它們的優點以及哪些可以讓您親自嘗試！** HTMX - 回到基礎🚲 ------------  這是給誰的： - 你想少寫 JavaScript - 您想要更簡單、以超媒體為中心的程式碼 如果不從那些自詡為和平前端庫的東西入手，那將是一種罪。 HTMX 在 2023 年人氣飆升，在過去一年中獲得了大部分 GitHub 明星。 HTMX 不是普通的 JS 框架。如果您在[HTMX](https://htmx.org/)工作，您將把大部分時間花在超媒體世界中，與我們通常以 JS 為重的現代 Web 開發觀點相比，您會以完全不同的眼光來看待 Web 開發。 **HTMX 利用 HATEOAS（超媒體作為應用程式狀態引擎）概念的力量，使開發人員能夠直接從 HTML 存取瀏覽器功能，而不是使用 Javascript** 。 這也證明您可以透過發布精彩的迷因並將口碑作為主要行銷來源來獲得知名度和認可。不僅如此，你還可以成為HTMX的[CEO](https://htmx.ceo/) ！它吸引了許多開發人員嘗試這種建立網站的方法並重新思考他們當前的做法。所有這些都讓 2024 年該圖書館的未來變得令人興奮。 Wasp - 全棧，開箱即用🚀 ---------------  這是給誰的： - 您想快速發布全端應用程式 - 您希望在一個出色的一體化解決方案中繼續使用 React 和 Node.js，而不需要手動選擇堆疊的每個部分 - 您想要一個用於 React 和 Node.js 的免費 saas 模板，其中所有內容都已預先配置 - [Open SaaS](https://github.com/wasp-lang/open-saas) 對於那些希望該工具簡單輕鬆地完全控制其堆疊的人來說，別再猶豫了！ [Wasp](https://github.com/wasp-lang/wasp)是一個固執己見的全端框架，它利用其編譯器以快速、簡單的方式為您的應用程式建立資料庫、後端和前端。**它使用 React、Node.js 和 Prisma，這些都是全端 Web 開發人員正在使用的最著名的工具。** Wasp 的核心是 main.wasp 文件，它可以滿足您的大多數需求。在那裡，您可以定義： - 全端認證 - 資料庫結構定義 - 非同步作業，無需額外的基礎設施 - 部署簡單且靈活 - 全端類型安全 - 電子郵件發送（Sendgrid、MailGun、SMTP 伺服器...） - 和更多… 最酷的事？在您的 Wasp 應用程式完成編譯步驟後，輸出是標準的 React + Vite 前端、Node.js 後端和 PostgreSQL 資料庫。從那裡，您可以使用單一命令輕鬆地將所有內容部署到[Fly.io](http://Fly.io)等。 儘管有些人可能認為 Wasp 固執己見的立場是一件消極的事情，但它是 Wasp 眾多全端功能背後的驅動力。借助 Wasp，為單一開發人員或小型團隊啟動全端專案變得更加容易，特別是如果您使用預製模板或[OpenSaaS](https://github.com/wasp-lang/open-saas)之一作為 SaaS 啟動器。由於專案的核心定義明確，因此很容易開始專案，並有可能在幾天內建立您自己的全端 SaaS！ **同樣很酷的是，大多數 Web 開發人員的大部分現有知識仍然適用於此，因為 Wasp 所使用的技術已經建立**。 Solid.js - 一流的反應性 ↔️ --------------------  這是給誰的： - 如果你想要高反應性程式碼 - 現有的 React 開發人員想要嘗試一些低學習曲線的高效能東西 [Solid.js](https://www.solidjs.com/)是一個非常高效能的 Web 框架，與 React 有一些相似之處。例如，兩者都使用 JSX，利用基於函數的元件方法，**但它不使用 Virtual DOM，而是將程式碼轉換為 vanilla JS** 。儘管如此，它更出名的是利用信號、備忘錄和效果來實現細粒度反應的方法。儘管如此，訊號仍然是 Solid 中最簡單和最著名的原語。它們包含值及其 getter 和 setter 函數，允許框架根據需要在 DOM 中的確切位置觀察和更新更改，這與 React 不同，React 會重新渲染整個元件。 Solid.js 不僅使用 JSX，還對其進行了增強。它提供了一些很酷的新功能，例如 Show 元件，它可以啟用 JSX 元素的條件渲染，而 For 元件則允許更輕鬆地迭代 JSX 中的集合。另一個重要的事情是，它還有一個名為Solid Start（目前處於測試階段）的元框架，使用戶能夠根據自己的偏好，使用基於文件的路由、操作、API 路由和中間件等，以不同的方式呈現應用程式特徵。 Astro - 靜態網站之王👑 ---------------  這是給誰的： - 如果您想要一款適用於部落格、CMS 網站的優秀工具 - 一個可以整合其他函式庫和框架的框架 如果您在 2023 年建立了一個內容驅動的網站，那麼您很有可能使用[Astro](https://astro.build/)作為您選擇的框架來實現它！ Astro 是另一個使用不同架構概念來脫穎而出的框架。對 Astro 來說，它是島嶼建築。在 Astro 的上下文中，島嶼是頁面上的任何互動式 UI 元件，從靜態內容的海洋中脫穎而出。一個頁面可以有任意數量的島嶼，因為它們彼此隔離執行，但它們也可以共享狀態並相互通信，這非常有用。 Astro 的另一個有趣的事情是，他們的方法使用戶能夠使用[不同的前端框架，](https://docs.astro.build/en/guides/integrations-guide/)例如 React、Vue、Solid 來製作他們的網站。因此，開發人員可以輕鬆地根據他們目前的知識建立網站，並利用可以整合到 Astro 網站中的現有元件。 Svelte - 簡單而有效🎯 ---------------  這是給誰的： - 你想要一個容易學習的框架 - 編寫簡單且程式碼執行速度快 **[Svelte](https://www.notion.so/Web-frameworks-we-are-most-excited-for-in-2024-35cfadc282ab4d28904b0fe4adf231d4?pvs=21)是另一個框架，它試圖透過盡可能簡單和對初學者友好來簡化和加速 Web 開發**。這是一個非常簡單的學習框架，因為要擁有響應式屬性，您必須聲明它並在 HTML 模板中使用它。每當 Javascript 中的值以程式設計方式更新時（例如，透過觸發 onClick 事件按鈕），它將反映在 UI 上，反之亦然。 Svelte 的下一步將是引入符文。 Runes 將成為 Svelte 處理反應性的方式，以便更輕鬆地處理大型應用程式。類似於 Solid.js 的訊號，符文提供了一種透過使用類似函數的語句來利用應用程式的反應狀態的直接方法。與 Svelte 目前的工作方式相比，它們將允許使用者精確定義整個腳本的哪些部分是反應性的，以便元件具有更高的效能。與 Solid 和 Solid Start 類似，Svelte 也有自己的框架，稱為 SvelteKit。 SvelteKit 為使用者提供了一種快速啟動由 Vite 支援的 Svelte 應用程式的方法。它提供路由器、建置優化、不同的渲染和預渲染方式、影像優化等。 Qwik - 很快🚤 ----------  這是給誰的： - 如果您想要一個高效能的網頁應用程式 - 現有的 React 開發人員想要嘗試一些低學習曲線的高效能東西 此列表中最後但並非最不重要的框架是[Qwik](https://qwik.builder.io/) 。 Qwik 是另一個利用 JSX 和功能元件的框架，類似於 Solid.js 的做法，為基於 React 的開發人員提供熟悉的環境，以便盡快上手。顧名思義， **Qwik 的主要重點是實現應用程式的最高效能和執行速度**。 Qwik 透過利用可恢復性的概念來實現其速度。簡而言之，可恢復性是基於暫停伺服器上的執行並在客戶端上恢復執行的思想，而無需重播和下載所有應用程式邏輯。這種行為是透過延遲 JavaScript 程式碼的執行和下載來實現的，除非有必要處理用戶交互，這是一件很棒的事情。它既可以提高整體速度，又可以將頻寬量降低到絕對最小值，從而實現近乎即時的載入。 結論 -- 我們提到的所有這些框架和庫之間最大的共同點是熟悉度。**每個人都尋求以一種基於他們當前知識的方式來接觸潛在的新開發人員，而不是做一些全新的事情，這是一個非常酷的概念**。 當然，這裡可能還有更多未在全文中提及的函式庫和框架，但至少值得一提。例如，我們有 Angular，除了新的徽標和文件之外，它還包括訊號和新的控制流。還有 Remix 新增了對 Vite、React Server Components 和新的 Remix SPA 模式的支援。最後，我們不能忘記 Next.js，它在過去幾年中成為了 React 開發人員的預設選項，為新的 React 功能鋪平了道路。 --- 原文出處：https://dev.to/wasp/web-frameworks-we-are-most-excited-for-in-2024-4d15
介紹 -- 在 SPA 出現之前，Web 應用程式通常是多頁面的。這意味著每次用戶與應用程式互動時，伺服器都會發送完整的新頁面，然後瀏覽器會再次載入它。每次用戶在頁面之間導航時，都會發生完整的頁面重新加載，這可能會減慢速度並造成不太流暢的用戶體驗。類似的應用程式通常是使用伺服器端技術建立的，例如 PHP、Ruby on Rails、ASP.NET 等，這些技術在伺服器端產生 HTML 程式碼並將其發送到瀏覽器。  Web開發人員是通用專家，他們同時負責前端和後端部分。隨著網路技術的發展和用戶的需求，需要新的解決方案，使他們能夠在沒有任何問題或等待的情況下使用互動式介面。 這就是第一個使用 BackboneJs 或 AngularJs 的 SPA 解決方案的出現。它們使我們能夠減少伺服器的負載（當時伺服器的資源有限），並在透過 JS 處理網頁時提供互動性，因為無需等待伺服器更新的新頁面。 這就是前端和後端部分的劃分。純粹前端開發人員的角色變得更加需求和多樣化。他們開始專注於建立使用者介面、使用 HTML、CSS 和 JavaScript，以及與 API 和伺服器互動。另一方面，後端開發人員變得更加關注資料處理、應用程式業務邏輯、使用資料庫和建立伺服器 API。 這就是我們進入 React、Angular2、Vue 和其他 Web 應用程式開發工具時代的方式。現在我們不再建立簡單的表單和列表，而是有 js 路由、狀態管理、瀏覽器 API、將授權令牌綁定到請求、資料映射等。 > ### 我們開始把簡單的事情複雜化。 透過這種方法，出現了以下問題： - **溝通協調困難**。 Api 合約與通訊方法 — HTTP 1.1、Websocket、GraphQL。 JSON 解析和驗證。 - **理解和認識上的分歧**。例如，您可以開發一個建立許多查詢的前端應用程式，並將其視為正常且最佳化的 SPA。但對於後端來說，這是一個非常危險的情況，因為它現在需要大量的資料庫存取以及對這些資料的適當聚合，這會影響它的效能和維護。 - **重複工作**。後端的大多數 CRUD 操作在前端都有類似的行為。我們不只是從伺服器獲取列表，現在我們將其放入 store() 中，每個用戶操作都透過dispatch() 處理並等待請求執行，之後我們透過reducer() 更新store根據結果——**後端對資料庫所做的一切，我們都會在前端重複**。 （頁面重新加載和從伺服器將 SPA 恢復到當前狀態也值得一提 - 目前是一個單獨的痛苦） - **除錯和測試困難**。現在您需要考慮可能的整合問題並在應用程式雙方的上下文中測試它們。是的，您可以為前端應用程式建立隔離的 e2e 測試，但它們不能保證生產中的可靠性。是的，有 ZoD 用於驗證伺服器回應，但它的使用百分比是多少？ - **增加了開發時間和成本**。對 API 合約的任何更改都需要兩個人同時進行。您不能像以前那樣直接將模板變更為伺服器。你需要集會、分成單獨的任務、商業分析專家等等來讓改變順利進行。 - **搜尋引擎優化**。由於我們的應用程式完全是透過 JS 建構的，搜尋引擎無法取得應用程式內容及其導航來正確索引它，因此需要 SSR 和 SSG 解決方案。 - **安全**。在頁面上輸入的任何關鍵資料在傳遞到伺服器之前都需要隱藏。此外，應用程式需要向伺服器請求大量個人訊息，從而洩露存取權杖。 那麼，通常的前端為什麼會消亡呢？ ---------------- 只需存取任何資源，您就會看到有多少職位空缺： - Python + Django - PHP + Laravel - NextJs + React - Nuxt + Vue 這些都是用於基於伺服器的 Web 應用程式開發的捆綁包。由於採用 Hydration 和 Resumability 方法，伺服器只能渲染介面的修改部分，而無需重新載入頁面。 他們提供什麼： - 伺服器應用程式現在不需要複雜的 HTTP 或 WS 合約並且雙方都支援它們，它可以使用更好的方法與 gRPC 等其他服務交換資訊。 - 由於缺乏中間批准，更改過程更快，對於 1 人，用戶看到的結果會立即更改。 - 測試可以全面檢查應用程式，消除整合測試並減少錯誤。 - 您僅交換 HTML 標記，所有「請求-回應」邏輯對使用者來說都是隱藏的 - 當您可以傳遞現成的範本時，為什麼還要傳遞大量 JSON 資料來將 SPA 還原到正確的狀態呢？ - 你不需要擔心瀏覽器相容性，也不需要使用babel等工具，因為頁面上的JS程式碼很少。 隨著No-Code解決方案的出現、透過AI生成模板、龐大的伺服器資源和SEO需求——目前數量的前端開發人員和工具不再需要只開發前端部分。 企業主有一個合理的問題——“*為什麼我需要雇用一個純粹的前端開發人員和一個純粹的後端開發人員來做一個簡單的應用程式？”* 全端開發人員並不是一種管理時尚，就節省人員配備而言，現在它已成為中流砥柱。你不需要一個純粹的前端開發人員，你需要一個能夠製作整個應用程式、直接對資料庫或其他服務執行簡單操作並顯示結果的開發人員。 是的，毫無疑問仍然會存在需要前端和後端分離的複雜或“無頭”應用程式，但大多數應用程式將脫離 SPA 並沿著已經存在的方式發展，但現在我們有一個解決方案那些問題。隨著 HTMX 的出現，任何具有基礎知識的後端開發人員都可以建立 Web 應用程式。現在你甚至不需要了解 JS 就可以建立一個幾乎沒有邏輯的單頁應用程式。 你可能會問，「*前端開發人員不僅負責 JS 邏輯，還負責 CSS 和適當的選擇器、HTML 及其語義，後端開發人員現在必須知道嗎？* 」 — 不，現在人工智慧或「HTML 佈局設計師」可以根據 Figma 的佈局產生模板。 HTML 範本的邏輯和互動性現在在伺服器上定義。 結論 -- 現在是思考您是否真的需要所有這些複雜的前端開發工具以及您是否應該保持純粹的前端開發人員的好時機。 我預計目前的前端開發人員將採用 60% 前端和 40% 後端的比例轉向全端資格，以保持相關專家的地位。 HTMX 只是開始，NextJs 或 Nuxt 工具的向量將會成長，Angular 類型的框架如果不能適應新的實作就會消亡，儘管 Angular 生態系統已經在 AnalogJs 上有了原型 資源 -- - [**htmx - 強大的 html 工具**](https://htmx.org/) - [**模擬**](https://analogjs.org/) - [按「前端開發人員」角色搜尋職位](https://www.indeed.com/jobs?q=front+end+developer&l=Remote) - [按「全端開發人員」角色搜尋職位](https://www.indeed.com/jobs?q=full+stack+developer&l=Remote) - [**Vercel 的 Next.js - React 框架**](https://nextjs.org/) - [**Nuxt：直覺的 Vue 框架**](https://nuxt.com/) --- 原文出處：https://dev.to/misterion96/the-front-end-development-were-used-to-is-dying-4e19
讓我給你一個簡單的🚦路線圖，讓你知道你現在在哪裡以及下一步應該去哪裡。  🔑關鍵概念 ----- 每個網站都有兩個部分。一個**前端**，一個**後端**。 前端是您在瀏覽器中看到它並與之互動的部分。**所有視覺方面**。 後端是為前端提供動力的部分。它*在幕後*，**主要是儲存資料和資料庫**並提供給前端。 🌐工作 --- 因此，網路開發工作分為`three categories` 。 - 👨💻前端開發 - 🛟後端開發 - 🚢以及全端開發（涉及前端和後端開發） 👷♂️後端開發人員到底是做什麼的？ ------------------ 後端開發人員負責建立驅動用戶所使用的應用程式*功能*的**基礎系統**。 這包括設計架構、實施和維護這些關鍵系統等各種任務。 他們的職責通常涉及與： - 💾 資料庫，例如MySQL， - ✂️ 框架，例如 Laravel 或 Ruby on Rails，以及 - 🧨 API（應用程式介面）。 他們的專業知識確保後端基礎設施無縫執行，從而實現使用者介面與底層資料和流程之間的順暢互動。 如果您不知道的話，這是後端開發人員的`core`職責： |任務|描述| |---|---| |了解績效需求與目標 |了解網站的效能要求和目標 | | API的開發與管理|為網站建立和管理 API | |開發資料儲存與處理系統|建置系統以安全地儲存和處理支付處理等流程所需的資料| |編寫、測試和維護程式碼 |編寫程式碼、測試和開發編碼問題的解決方案，包括維護任務 | |設計網站架構|使用敏捷 Scrum 和框架等既定方法設計網站架構 | |組織系統邏輯|有效建構系統邏輯| |提供系統問題的解決方案|提供解決方案來解決與系統相關的問題和挑戰 | --- 🥷 六個月內成為後端開發人員的技能 ----------------- 成為熟練的後端開發人員需要在相對較短的時間內掌握各種技能和技術。 下面，我概述了一個**全面的路線圖**，以幫助您在六個月內實現這一目標： **第 1 個月：🦴後端開發基礎** - **第一週：**了解後端開發人員的角色和職責。熟悉資料庫、框架和 API。 - **第 2-3 週：**參加資料庫綜合課程。了解 SQL 和 MySQL 等關聯式資料庫。練習建立和管理資料庫。 - **第 4 週：**了解伺服器端程式語言。從 PHP 或 Python 開始。學習基本語法、控制結構和資料類型。 **第 2 個月：🍖高階後端概念** - **第 1-2 週：**加深對資料庫的理解。探索 MongoDB 等 NoSQL 資料庫。了解*資料建模和優化*。 - **第 3-4 週：**掌握伺服器端程式語言。深入研究 PHP 或 Python。了解函數、類別和物件導向程式設計。 - **最後 2 天：**使用框架進行實踐專案。選擇流行的框架，例如*適用於 PHP 的 Laravel 或適用於 Python 的 Django* 。建立簡單的應用程式以理解模型-視圖-控制器 (MVC) 架構。 **第 3 個月：🌦️API 開發和集成** - **第 1-2 週：**了解 API 及其在後端開發中的重要性。探索 RESTful API 設計原則。 - **第 3 週：**開始建立您自己的 API。使用`Postman`等工具來測試和偵錯 API 端點。了解身份驗證和安全性。 - **第 4 週：**關注*API 整合*。了解如何在 Web 和行動應用程式中使用 API。練習將第三方 API 整合到您的專案中。 **第 4 個月：🛸故障排除與最佳化** - **第 1-2 週：**掌握故障排除技術。了解如何有效診斷和除錯後端應用程式。 - **第 3 週：**進入效能優化階段。了解快取、負載平衡和資料庫索引。 - **第 4 週：**學習監控和分析工具。使用 New *Relic 或 Datadog*等工具來監控應用程式效能。了解如何產生和**分析**績效指標。 **第 5 個月：🌥️雲端基礎設施和部署** - **第 1 週：**了解雲端運算概念。了解 AWS 或 Azure 等流行的雲端供應商。 - **第 2-4 週：**學習後端開發雲端服務課程。了解無伺服器運算、容器化和微服務。 - **休息日：**練習將應用程式部署到雲端。了解 CI/CD 管道和自動化部署策略。 **第 6 個月：🏗️高級主題和專案** - **第 1-2 週：**在上個月，學習更多高階後端主題。選擇訊息佇列、事件驅動架構和即時通訊等主題。 - **第 3 週：**開展*頂點計畫*。選擇一個具有挑戰性的專案，整合各種後端技術和概念。 - **第 4 週：**最後，反思您的學習歷程。審查您的專案並確定需要改進的領域。透過練習**程式設計挑戰**來準備工作面試。 ⛏️後端開發：工具與軟體 ------------ 以下是後端開發中常用的工具和軟體的細分： **1. 📇資料庫框架：** - **MySQL：**用於儲存和檢索資料的關聯式資料庫管理系統。它廣泛用於 Web 應用程式，並提供可擴展性和可靠性。 - **MongoDB：**一種 NoSQL 資料庫程序，使用具有模式彈性的類似 JSON 的文件。它適用於資料模型快速變化或非結構化資料的應用程式。 **2. 🛝網路伺服器：** - **Apache HTTP Server 2：**一種開源 Web 伺服器軟體，可透過網際網路提供 Web 內容。它以其穩定性、安全性和靈活性而聞名，使其成為託管網站和 Web 應用程式的熱門選擇。 **3. 🔐安全協定：** - **SSL/TLS 憑證：**這些是透過電腦網路提供安全通訊的加密協定。 SSL（安全通訊端層）及其後繼者 TLS（傳輸層安全性）對伺服器和用戶端之間的資料進行加密，確保線上連線的機密性和完整性。 **4. 💫版本控制系統：** - 接下來，請熟悉版本控制系統。這些系統有助於追蹤專案歷史並實現與其他人的協作工作。 - 🔌 吉特： - Git 是使用最廣泛的版本控制系統，超過 70% 的軟體開發團隊都在使用。這是一個必須知道的工具，建議分配大約兩週的時間來學習 Git。 後端開發人員通常利用這些工具和軟體來建立強大、可擴展且安全的 Web 應用程式，用於處理資料儲存、伺服器託管和線上通訊加密。 如果您尋求有關後端開發的更多知識，請考慮查看此[深入的後端開發路線圖](https://roadmap.sh/backend)。 --- 👏結論 --- 透過遵循此時間表並持續努力學習，您可以在 6 個月內獲得寶貴的後端開發技能，並為找到後端開發工作做好充分準備。 如果您想在六個月內成為前端開發人員，您也可以閱讀這篇文章。 👇 [6 個月內成為前端開發人員的路線圖](https://dev.to/codewithshahan/must-have-frontend-development-skills-roadmap-2024-28jc) 最後，如果你想知道[前端開發的未來](https://dev.to/codewithshahan/the-future-of-frontend-development-1amd)，你也可以看看這篇文章。 請關注更多有價值的內容，如果您覺得有幫助，您可能也會喜歡我的[YouTube 頻道](https://www.youtube.com/programmingwithshahan)。 感謝您花時間閱讀這篇文章。 🤳我的社交： [X](https://twitter.com/shahancd) --- 原文出處：https://dev.to/codewithshahan/skills-to-become-a-backend-developer-in-6-months-roadmap-4li3
什麼是 readme 文件？ -------- 自述文件是用戶在查看儲存庫時首先看到的內容。它讓用戶了解專案的內容、使用的語言、條款和條件、您的專案可以做什麼、顯示正在執行的應用程式的螢幕截圖等。 為什麼它如此重要？ --------- 該用戶可能是招募人員、您未來的老闆或客戶。因此，需要注意的是，專案的自述文件應該回答專案的內容、原因和方式。 因此，重要的是要包含最重要的訊息，對專案和所使用的技術堆疊進行清晰的描述，並提供可能不適合 README 文件的連結和進一步說明，以避免不必要地搜尋所有其他文件。可能會導致用戶失去興趣並轉向下一個潛在員工。 編寫有關該專案的良好文件是多麼重要，我怎麼強調都不為過。使用者不僅在尋找有關專案本身的訊息，而且還看到您的文件技能和對細節的關注，這可以讓您更接近找到工作。 如果您讀過我的其他文章，您可能已經注意到，除了程式設計之外，學習其他技能對我的職業生涯有多麼重要，這些技能最終幫助我找到了工作。良好的文件就是其中之一。 自述文件中應包含哪些內容？ ------------- 以下是一些可以幫助您的指導性問題： - 該專案是關於什麼的？ - 為什麼開發它，你的動機是什麼？ - 它解決什麼問題？ - 你學到了什麼？ - 是什麼讓您的專案脫穎而出？ 我將向您展示如何將這些問題轉換為文字。 ### 可能的結構 **描述** 專案的目的和描述，以便閱讀您的作品集的人可以在閱讀專案資訊的前幾秒鐘內了解該專案。 **技術堆疊** 技術堆疊，包括您的專案使用的程式語言、程式庫和框架（例如：Python、React 等）。如果您有使用外部公共 API 的前端應用程式，請提及這一點。 **設計** 與專案相關的使用者介面範例。如果專案有使用者介面，您可以插入使用者介面的 GIF、影片或圖像。 如果它是在終端上執行的應用程式，您可以建立一個 GIF 來展示如何使用它。這有助於了解如何與應用程式互動以及人們在執行專案時會看到什麼。 **特徵** 如果您的專案有很多功能，您應該加入**“功能”**部分並在此處列出它們。 **如何執行專案** 有關如何設定、執行和使用該專案的說明。如果有人想從頭開始該專案，這很好，他們應該在專案的自述文件中找到他們需要了解的所有內容，而不需要您的任何幫助。 如果很簡單，您可以將其包含在自述文件中。如果說明較長，您也可以參考專案中的另一個文件。 您還應該使用 Netlify 來託管您的專案，以便使用者可以打開已部署的應用程式並立即使用它來查看它是如何運作的。 （請記住，並非每個查看您 GitHub 個人資料的招募人員都充分了解如何在本地建立專案。） 如何設計自述文件的樣式？ ------------ `README.md`中的`.md`副檔名代表 Markdown，這是一種輕量級標記語言，具有簡單的文字格式化語法。它是一種非常簡單的語言，用於為 GitHub 建立美觀且美觀的自述文件。 因此，您可以使用典型的 Markdown 語言，例如 ``` # Heading 1 ## Heading 2 ### Heading 3 Emphasis, aka italics, with *asterisks* or _underscores_. Strong emphasis, aka bold, with **asterisks** or __underscores__. Combined emphasis with **asterisks and _underscores_**. 1. First ordered list item 2. Another item ⋅⋅* Unordered sub-list. 1. Actual numbers don't matter, just that it's a number ⋅⋅1. Ordered sub-list 4. And another item. [I'm an inline-style link](https://www.google.com) [I'm an inline-style link with title](https://www.google.com "Google's Homepage")  ``` --- 原文出處：https://dev.to/yuridevat/how-to-create-a-good-readmemd-file-4pa2
> 最初發佈在我的[部落格](https://inspiredwebdev.com/article/5-best-note-taking-apps-for-programmers)上。 > 請查看我的[部落格](https://inspiredwebdev.com)以獲取更多文章，或[在 Github](https://github.com/AlbertoMontalesi/The-complete-guide-to-modern-JavaScript)上查看我的免費閱讀 JavaScript 電子書，其中涵蓋了從 ES6 到 2019 年的所有新功能 做筆記是學習的重要組成部分，作為程式設計師，我們有 Docs 或 Word 等軟體無法滿足的特定需求。這就是為什麼我列出了我最喜歡的 5 個筆記應用程式。 在過去的幾年裡，我已經使用了所有這些，其中一些我仍在使用，有些我已經停止使用，但這 5 個中的任何一個都會對您有所幫助。 您會看到它們都使用 Markdown（標準語法或自訂語法），這是因為我發現它是記筆記的最快方式，因為它允許快速建立具有簡單格式的文件，還允許您加入程式碼區塊語法高亮。 注意：這些應用程式都是免費的或有免費套餐，因此您無需花費一分錢即可開始使用它們。 1）[Notion](https://www.notion.so) ----------------------------- 適用於：Windows、MacOS、Android、iOS、Web。 這是我用來撰寫這篇文章的應用程式。 它很棒，因為它不僅僅是一個 Markdown 文字編輯器，您還可以做更多事情，包括在頁面中加入表格、看板、日曆。 你可以在你的裝置之間同步你的筆記，而且它有一個網頁版本，這意味著即使你像我一樣使用 Linux，你仍然可以使用它。 它對程式碼區塊有非常堅實的支持，具有突出顯示和包裝程式碼的能力。 免費版本包含足夠的空間，您應該可以使用一段時間。 2)[Stackedit](https://stackedit.io/app#) ----------------------------------- 適用於：網路 Stackedit 沒有行動應用程式，但您仍然可以透過瀏覽器輕鬆使用它。 它比 Notion 簡單得多，是一個與 Google Drive 同步的簡單的 Markdown 編輯器。 每當我需要寫下我的想法時，我每天都會用它來記錄我的工作筆記，並且我想確保我可以從我的辦公室和我自己的筆記型電腦存取它們。 它是完全免費的，並且 Markdown 文件存儲在您的 Google 雲端硬碟中，因此如果您想將它們遷移到其他地方，這將非常簡單。 對程式碼區塊的支援非常好，可以為您需要的任何語言提供語法突出顯示。 3）[Typora](https://www.typora.io/) ------------------------------- 適用於：Windows、MacOS、Linux Typora 簡單乾淨，是一款功能強大的 Markdown 編輯器。不幸的是，它沒有行動版本或網路用戶端，但桌面用戶端非常穩定且功能強大。 我用它編寫了我的第一本[JavaScript 電子書](https://github.com/AlbertoMontalesi/The-complete-guide-to-modern-JavaScript)，我非常喜歡與 Pandoc 的集成，將我的 Markdown 電子書直接匯出為 epub、pdf 和 doc 文件。 它對程式碼區塊有很好的支持，使用 prism 進行語法突出顯示，並且還允許您建立 css 檔案來設定匯出的 PDF 檔案的樣式。 4）[Quip]([https://quip.com](https://quip.com/)) ---------------------------------------------- 適用於：Windows、MacO、Web、Android、iOS Quip 是我使用的第一個編輯器，雖然我不再使用它，但它仍然是一個很好的解決方案。 行動應用程式不是最好的，但網路用戶端堅固且功能強大，可讓您輕鬆加入表格等。 有些功能是付費的，但總的來說免費版本已經夠好了。 對突出顯示的程式碼區塊的支援是基本的，與其他程式碼區塊不在同一水平上 獎勵： [VSCode](https://code.visualstudio.com/) -------------------------------------------- 適用於：Windows、MacOS、Linux 儘管 VS Code 並非為此而生，但它是一個很棒的筆記應用程式。 在編寫[電子書](http://a-fwd.to/5gUojI8)的第二版時，我使用 VS Code 建立單獨的 Markdown 檔案和一個簡單的節點腳本將它們合併為一個檔案。 您還可以利用 GitBooks 連接您的儲存庫並在線上發布您的筆記，以私下或公開方式提供。 動態編輯並不是最簡單的，因為您無法在手機上使用 VS Code，但您仍然可以從 FastHub 或類似的第 3 方用戶端等應用程式直接編輯 Github 儲存庫中託管的檔案。 什麼是你最喜歡的？ --------- 你呢？您已經使用過這些應用程式嗎？您最喜歡的筆記應用程式是什麼？在評論中讓我知道 --- 非常感謝您的閱讀。在[DevTo](https://dev.to/albertomontalesi)上關注我，或在我的 blog [inishedwebdev](https://inspiredwebdev.com/)上關注我，以了解更多資訊。 [](http://a-fwd.to/5gUojI8)  在[Amazon](http://a-fwd.to/5gUojI8)和[Leanpub](https://leanpub.com/thecompleteguidetomodernjavascript2019)上取得我的電子書 --- 原文出處：https://dev.to/albertomontalesi/5-best-free-note-taking-apps-for-programmers-2n81
最近，我改用[Sublime Text](https://www.sublimetext.com/)作為我的主要程式碼編輯器。一年多來，我一直使用[Visual Studio Code](https://code.visualstudio.com/)來編寫程式碼。這兩個編輯器非常相似，但也有足夠的差異，我想分享一下是什麼讓我全職使用 Sublime。 *注意：這篇文章並不是要為了一項技術而抨擊另一項技術。我嘗試根據我的個人經驗進行誠實的比較，但選擇程式碼編輯器是一個主觀過程，因此每個人都會對自己的最愛有不同的看法。* 是什麼讓我跳槽 ------- ### 偉大的符號分析 當您在 Sublime Text 中開啟一個專案時，它會自動啟動一個稱為「符號分析」的過程，這是在程式碼中尋找關鍵字的一個奇特術語。符號分析的好處在於，我可以輸入 Cmd + Shift + R 來調出符號搜尋選單，並在整個程式碼中快速找到類別名稱和方法。我主要使用 PHP，因此如果我已經知道我正在處理的類別名稱是`PostController` ，我可以在符號搜尋中搜尋它並立即在編輯器中開啟我的 PHP 類別檔案。 VS Code 也支援符號搜尋，但是，它只支援幾種開箱即用的語言。有一個與 VS Code 一起使用的第三方 PHP 符號分析器，但是，我發現它在處理大型程式碼庫時遇到困難，而 Sublime 則沒有問題。 ### 超快 Sublime Text 是可用於編寫程式碼的最快的文字編輯器。它幾乎立即打開並執行非常快速的搜尋。 Microsoft 在保持 VS Code 效能方面做得很好，但是 VS Code 是基於[Electron](https://electronjs.org/)的。 Electron 是一個用於捆綁 Chromium 實例和用 JavaScript/Node.js 編寫的程式碼的框架。它使編輯器具有很強的可擴展性，但使用 Chromium 的整個實例作為文字編輯器會使應用程式啟動緩慢並使用更多記憶體。 Sublime Text 是一個用 C++ 編寫的本機應用程式，因此其佔用空間要少得多。 ### 更好的 Vim 綁定 我非常喜歡在編寫程式碼時使用 Vim 鍵綁定。儘管我喜歡 Vim 鍵盤快捷鍵，但我仍然喜歡使用標準文字編輯器來利用側邊欄文件清單和文件標籤等現代功能。我發現 Sublime 的 Vim 支援比 VS Code 更準確，這有助於我更快地編寫程式碼。 Sublime 支援開箱即用的 Vim 綁定，但如果您使用[Vintageous](https://github.com/guillermooo/Vintageous)插件，您可以獲得更多功能。 我在 Visual Studio Code 中懷念的事情 ---------------------------- ### 功能豐富的側邊欄 VS Code 有一個非常好的側邊欄，可以更靈活地建立和移動檔案。 Sublime 有一個更好的側邊欄插件，還有其他鍵盤快捷鍵插件（例如[AdvancedNewFile）](https://github.com/skuroda/Sublime-AdvancedNewFile)可以使轉換更容易，但有時我會懷念 VS Code 側邊欄的開箱即用功能。 ### 內建偵錯工具 VS Code 有一個內建的偵錯器，適用於多種程式語言。它使得使用 PHP 的 xdebug 變得非常簡單。儘管 Sublime 有除錯插件，但它們並不像 VS Code 提供的開箱即用的那樣可靠。在這種情況下，如果我正在除錯一些棘手的東西，我仍然會打開 VS Code。 結論 -- 最後，文字編輯器完全取決於個人喜好和工作要求。對於我的用例來說，Sublime 是一次非常愉快的體驗，它幫助我更快地編寫程式碼。如果您想了解有關 Sublime Text 的更多訊息，Jeffrey Way 在 Laracasts 上開設了相關[課程](https://laracasts.com/series/sublime-text-mastery)，Wes Bos 也寫了一本相關[書籍](http://wesbos.com/sublime-text-book/)。 請在評論中告訴我您最喜歡的編輯器是什麼！ --- 原文出處：https://dev.to/restoreddev/why-i-switched-from-visual-studio-code-to-sublime-text-28k0
所謂年後離職潮，應該很多人年後會換工作吧 祝各位跳槽順利 😁 然後很多新人應該工作不到一年，這次是以工程師身份第一次放年假 歡迎分享菜鳥工程師工作心得 😁 祝各位新年快樂 😁😁
每個開發人員都需要一個工具包來簡化他們的工作流程、提高生產力並有效地處理一些最複雜的任務。 這可能是開發、測試或專案管理，擁有合適的工具可以決定您的開發過程的成敗。 讓我們來看看我最喜歡的一些，我希望它們也成為您的最愛！  --- **讓我們開始吧！** 👇 1.[翼](https://github.com/winglang/wing) ---------------------------------------  > - 🔥 雲端程式語言 > - 🔥 將基礎架構和執行時間程式碼合併為一種語言的統一程式設計模型 {% cta https://github.com/winglang/wing %} 請star ⭐ Wing {% endcta %} --- 2.[收件匣清零](https://github.com/elie222/inbox-zero) ------------------------------------------------  > - 👉 幾分鐘內清理你的收件匣 > - 👉 時事通訊清理、人工智慧自動化、冷電子郵件攔截器和分析 {% cta https://github.com/elie222/inbox-zero %} 請加註星標 ⭐ 收件匣零 {% endcta %} --- 3.[紙標](https://github.com/mfts/papermark) -----------------------------------------  > - 🚨 開源 DocSend 替代方案 > - 🚨 透過即時分析和白標選項安全地共享推廣資料、銷售提案和其他文件 {% cta https://github.com/mfts/papermarkr %} 請加註星標 ⭐ Papermark {% endcta %} --- 4.[適體資料庫](https://github.com/aptabase/aptabase) -----------------------------------------------  > - 📣 應用程式分析 > - 📣 適用於您選擇的框架！ （JS | NextJS 等） {% cta https://github.com/aptabase/aptabase %} 請加註星標 ⭐ SoapUI {% endcta %} --- 5.[文件](https://github.com/documenso/documenso) ----------------------------------------------  > - 🚀 開源文件簽名 > - 🚀 與所有您喜愛的工具整合 - 發送、連接、接收和嵌入到任何地方 {% cta https://github.com/documenso/documenso %} 請加註星標 ⭐ Documenso {% endcta %} --- 6.[翻轉](https://github.com/flipt-io/flipt) -----------------------------------------  > - ⚡ 現代工程團隊的支援 GitOps 的功能管理平台。 > - ⚡ 遵循現代 DevOps 最佳實踐，例如基於主幹的開發、持續交付和軟體終止開關，而無需重新啟動應用程式。 {% cta https://github.com/flipt-io/flipt %} 請加註星標 ⭐ Flipt {% endcta %} --- 7.[開啟狀態](https://github.com/openstatusHQ/openstatus) ----------------------------------------------------  > **建立信任：** > - ✨ 向使用者展示您的可靠性，並減少客戶服務單的數量。 > **自訂域** > - ✨ 帶上您自己的域名，並為狀態頁面賦予個性化風格。 {% cta https://github.com/openstatusHQ/openstatus %} 請加註星標 ⭐ OpenStatus {% endcta %} --- --- 原文出處：https://dev.to/winglang/developers-toolkit-your-essential-open-source-devtools-hgc
CSS 屬性`line-height`定義兩個內嵌元素之間的間距。典型用途是分隔文字。您可以看到人們將其與“前導”進行比較，“前導”是印刷術中使用的術語，指兩行文本的基線之間的空間。 `line-height`工作方式不同。它在文字上方和下方加入了空間。  左：行距，右：行高 用法 -- 您可以使用具有不同值的`line-height`如下所示： ``` body { line-height: normal; /* default */ line-height: 2; line-height: 1em; line-height: 1rem; line-height: 200%; line-height: 20px; } ``` 噢，孩子😧！好多啊。讓我們一一分析一下👍。 ### 預設值和無單位值 如果您不將其設定為不同的值，則「正常」是預設值。通常，這意味著它設定為`1.2` ，這取決於瀏覽器供應商。那麼只有一個數字值而沒有任何單位是什麼意思呢？它實際上是一個乘數。它採用`font-size`值並將其乘以`1.2` 。讓我們用下面的例子來計算一條線的高度。 ``` body { font-size: 16px; line-height: 1.5; } ``` 我們只需要做以下計算：16 \* 1.5 = 24px。現在我們知道文字的最小高度為 24 像素。因此它將在文字下方和上方加入 4 個像素。酷就這麼簡單😎！ ### em 和 rem 下一個是`em`和`rem` 。 `rem`相對於根元素的`font-size` ， `em`相對於目前元素的 font-size。這是一個例子 ``` html { font-size: 12px; } .remExample { font-size: 16px; line-height: 1.5rem; /* line-height will be 12 * 1.5 = 18px */ } .emExample { font-size: 16px; line-height: 1.5em; /* line-height will be 16 * 1.5 = 24px */ } ``` ### 百分比 `%`值有點難以閱讀。 100%意味著乘以1。再次舉例來說明這一點。 ``` body { font-size: 12px; } .percentage { font-size: 16px; line-height: 150%; /* line-height will be 16 * 1.5 = 24px */ } ``` ### 像素（px） 對我來說最簡單也是最令人困惑的是`px`值。將其設為任何像素值都會將其精確地設定為該值。因此，如果您的`font-size`為 16px，並且您將`line-height`設為 12px，您的字體將比它所包裝的容器更大。一般來說，您應該盡量避免在行高中使用`px`值！ ``` body { font-size: 16px; } .pixel { line-height: 12px; } ``` ### 一些最佳實踐 一般來說，我先將`body`元素中的`font-size`和`line-height`設定為以下值。 ``` body { font-size: 16px; line-height: 1.5; } ``` 由此，您可以建立所有其他樣式。我會盡量避免使用無單位數字以外的任何東西。另外，嘗試使用易於分割的`font-size`值，例如 16 或 12。這將有助於您在設計中保持平衡。您也可以在`margin`和`padding`中使用它。在腦中計算 16 \* 1.5 比 13 \* 1.5 更容易。然後您將永遠知道實際價值是多少。 ``` body { font-size: 16px; line-height: 1.5; } h1, h2, h3, h4, ul, ol { margin-bottom: 15rem; } button { display: inline-block; padding: 0.75rem 1.5rem; } ``` 當然，你可以嘗試一下，這些規則也會有例外，但我總是這樣開始。 資源 -- - http://www.indesignskills.com/tutorials/leading-typography/ - https://developer.mozilla.org/en-US/docs/Web/CSS/line-height - https://www.w3schools.com/cssref/pr\_dim\_line-height.asp - https://css-tricks.com/almanac/properties/l/line-height/ - https://ux.stackexchange.com/questions/35270/is-there-an-optimal-font-size-line-height-ratio **謝謝閱讀！** --- 原文出處：https://dev.to/lampewebdev/css-line-height-jjp
我相信您可以想像版本控製程式碼的重要性，以便我們可以**恢復變更**並**恢復遺失的資料以及其他可能性**。 我打賭你知道有人*（不是我呵呵）*通過使用越來越有創意的名稱建立文件副本來對其文件進行版本控制...  在 1972 年之前，隨著**SCCS *（原始碼控制系統）***的發布，這是有史以來第一個**集中式**版本控制軟體之一，這可能是任何人對其程式碼進行版本控制的方式。 但我們在這裡不是在談論 SCCS，我們現在真正感興趣的是**GIT** ，這是一款**分散式**開源版本控制軟體，明年*(07/04/2005)*將慶祝其誕生 20 週年。 目錄 -- - [1.GIT是什麼？](#chapter-1) - [2.GIT如何運作？](#chapter-2) - [3.安裝GIT](#chapter-3) - [4.配置GIT](#chapter-4) - [5. 啟動本機儲存庫](#chapter-5) - [6. 使用 GIT](#chapter-6) - [7. 認識分支](#chapter-7) - [8. 與遠端倉庫同步](#chapter-8) - [9. 結論](#chapter-9) - [10. 參考文獻](#chapter-10) 1.GIT是什麼？<a name="chapter-1"></a> --------------------------------- GIT 是一個開源**分散式**版本控制系統，於 2005 年推出，由 Linus Torvald *（Linux 核心建立者）*開發。 使用GIT，我們可以在本地**控制專案的版本***（在工作資料夾中）*並將所有變更同步到遠端儲存庫*（例如在GitHub上）* 。 2.GIT如何運作？<a name="chapter-2"></a> ---------------------------------- 想像一個**實體**文件櫃，其中有一個包含所有專案文件的資料夾。每當有人需要操作文件時，他們都必須將其拾取，**將其從資料夾中刪除，並在完成後將其返回到資料夾中**。因此，兩個人**不可能**處理同一個文件，完全避免了任何可能的衝突。 **但這不是 Git 的工作原理！** *（感謝上帝）* 這就是**集中式**版本控制系統的工作方式，其中使用者需要**「簽出」**和**「簽入」**文件，即每當有人需要處理特定文件時，他們需要簽出該文件，**刪除從儲存庫中獲取**文件，然後在工作完成後簽入該文件，**並將其返回儲存庫**。  在像**GIT**這樣的**分散式**系統中，多個人可以存取同一個遠端儲存庫中的檔案。每當有人需要操作文件時，他們只需將其**克隆***（或克隆整個存儲庫）*到本地計算機，然後將修改發送回遠端存儲庫。這使得**多人可以處理同一個專案**，甚至操作**相同的文件**。  這就是允許大型**開源**專案的分佈，來自世界不同地區的人們在同一個專案上工作，管理修改和可能的衝突*（是的，這裡可能會發生合併衝突）* 。 3.安裝GIT<a name="chapter-3"></a> ------------------------------- **GIT**適用於主要作業系統*（Windows、Linux、MacOs...），*安裝過程非常簡單，可以透過**命令列**或透過[git-scm.com](https://git-scm.com/)的**官方安裝程式**完成。 ### 3.1 在 Windows 上 要在 Windows 上安裝 GIT，只需存取官方網站並[下載安裝程式即可](https://git-scm.com/download/win)。然後只需**按照說明進行操作**，一切都會好起來，然後我們就可以在終端機中使用 GIT 命令了。 ### 3.2 在Linux上 對於Linux，我們可以使用以下**命令**安裝**GIT** ： ``` sudo apt install git-all ``` 透過這樣做， **GIT**必須準備好在我們的終端中運作。 ### 3.3 在 MacOS 上 對於 Mac，安裝**GIT**最簡單的方法是安裝[Homebrew](https://brew.sh/) ，然後在終端機中執行以下**命令**： ``` brew install git ``` 然後**GIT**必須準備好在我們的終端中運作。 4.配置GIT<a name="chapter-4"></a> ------------------------------- 安裝後，使用以下**命令設定 GIT**很重要： ``` git config --global user.name "[username]" # e.g. John Doe ``` ``` git config --global user. email "[[email protected]]" # e.g. [email protected] ``` > 此外，也可以透過刪除`--global`標籤來為某些本機儲存庫配置特定使用者。 5. 啟動本機儲存庫<a name="chapter-5"></a> ---------------------------------- 配置**GIT**後，我們就可以**啟動本地儲存庫了**。為此，我們可以**從頭開始一個新的儲存庫**或**複製現有的遠端儲存庫**。 ### 5.1 從頭開始（git init） 要啟動新儲存庫，只需導航到所需的儲存庫**根資料夾**並執行以下命令： ``` git init ```  透過這樣做，將在專案資料夾內建立一個`.git`目錄，該目錄將**負責此本機儲存庫的工作資料夾中的版本控制**。 ### 5.2 克隆現有儲存庫（git clone） 克隆現有遠端儲存庫就像從頭開始建立新儲存庫一樣簡單。為此，只需使用`git clone`命令，將要複製**的儲存庫的 URL**作為參數傳遞到要複製儲存庫的資料夾中： 複製現有的遠端儲存庫就像從頭開始建立新的儲存庫一樣簡單。為此，只需使用`git clone`命令，將**遠端儲存庫 URL**克隆到我們要下載儲存庫的資料夾中： ``` git clone [repository-url] ```  然後整個存儲庫必須**克隆**到我們的本地機器並**自動連結到相關的遠端存儲庫**。 > 有了複製的儲存庫，我們以後就不再需要使用`git remote`指令了。 6. 使用 GIT<a name="chapter-6"></a> --------------------------------- 在我們的**本機儲存庫**中，我們可以建立專案所需的文件，但它們**不會由 GIT 自動同步**，當有任何變更需要版本控制時，我們需要報告它。 因此，我們可以根據需要**操作**文件，並**在完成所需的變更後**，**將更新的文件傳送到 GIT** 。 為此，重要的是要了解版本控制中有**3 個階段的無限流***（是的，無限）* ： ``` MODIFY -> STAGE -> COMMIT ``` - **修改：**版本控制的第一階段，我們在這裡找到與上一個可用版本相比**已更改的檔案**。 - **STAGE：**版本控制的第二階段，這是我們放置**要新增到下次提交的修改檔案**的地方。 - **COMMIT：**版本控制的最後階段，當我們**確認變更**時，將階段中修改的檔案傳送到本機儲存庫。 提交修改後的文件後，我們在本地存儲庫中有一個可用的**新版本**，它可以再次接收更新，再次*“修改”* ，然後放入*“階段”* ，並再次*“提交”* ，確認較新的版本版本等等*（因此，「無限」哈哈）* 。 > 值得注意的是，提交不會覆蓋已修改文件的舊版本，而是包含新版本以及指向最後版本的指針，從而追蹤 GIT 追蹤的每個文件的版本。 ### 6.1 新增和提交（git add 和 git commit） 儘管聽起來很複雜，但執行版本控制流程**非常簡單**。由於所需的修改已完成，我們使用以下命令**新增要在舞台上提交的修改後的檔案**： ``` git add [filename] ``` > `git add -A` -> 將所有修改的檔案立即加入階段。 > > `git add *.[extensão-do-arquivo]` -> 將所有具有指定檔案副檔名的已修改檔案一次新增至暫存區（例如`git add *.html` ） 我們可以隨時使用`git status`指令檢查目前本機儲存庫**狀態**：  請注意，當我們**在建立新檔案後**在儲存庫中執行`git status`時，新檔案將顯示為*「Untracked」* 。這意味著該文件是**全新的**，仍然需要加入到任何提交中才能被**GIT追蹤**。 > 可以讓 GIT 忽略儲存庫中的特定檔案或資料夾。為此，我們只需將一個名為`.gitignore`的檔案新增到根資料夾中，並在其中寫入應忽略的檔案或資料夾的名稱。 > > 注意：被忽略的檔案和資料夾將不再出現在 GIT 軌道上，甚至不會顯示為「未追蹤」。要重置跟踪，只需從`.gitignore`文件中刪除所需的名稱即可。 要包含文件，我們可以使用要新增的文件的名稱來執行`git add`命令*（在本例中為「index.html」）* ：  這樣，透過重新執行`git status`我們可以看到新檔案已新增至*「stage」* ，並**最終準備好在下一次提交中發送**，這可以使用以下命令完成： ``` git commit -m "[descriptive-message]" ``` > 提交具有唯一的 ID（雜湊碼）並且是**IMMUTABLE 的**，即一旦確認就無法修改。 > > `git commit -a` -> 執行直接提交，將所有修改的檔案新增至暫存區並提交它們。 **成功提交檔案後**，執行`git status`時，我們注意到**沒有更多修改的檔案需要上傳**，因為所有修改都已在上次**提交**時有效保存在我們的本機儲存庫中。  此外，還可以使用`git log`指令查看儲存庫的提交日誌來**驗證所做的更改**，該指令顯示所有提交的一些元資料，例如雜湊碼、分支、作者、日期等。  可以重複整個過程來加入我們專案所需的新文件，修改它們並透過進行新的提交將它們發送到本地儲存庫。  > `git log -N` -> 顯示最近 N 次提交的日誌。 > > `git log [branch-A] [branch-B]` -> 顯示「branch-B」中但不在「branch-A」中的提交日誌。 > > `git log --follow [filename]` -> 顯示更改指定檔案的提交日誌，即使它已更改名稱。 > > `git diff` -> 列出與儲存庫中最新可用版本相比所做的變更。 > > `git diff [nome-do-arquivo]` -> 列出對指定檔案相對於儲存庫中最後一個可用版本所做的變更。 ### 6.2 撤銷提交前後的更改 **在提交之前**，對本地存儲庫所做的任何更改都可以撤消或更改，但**一旦提交，就無法更改**。這是因為提交是**不可變的物件**，這意味著不可能編輯或更改提交中的資料。 但是，**可以進行新的提交**來撤銷更改，或更正先前提交中的不正確資訊。無論哪種方式，我們都可以使用以下命令之一： ``` git checkout -- [filename] # Discards changes made to the local file before the commit (irreversible action) ``` ``` git reset --hard HEAD # Discards changes made to a file that is in stage (before the commit) ``` ``` git reset --hard HEAD~1 # Discards the last commit made in the local repository (only the last commit) ``` ``` git commit --amend # Creates a new commit, replacing the last commit made in the local repository ``` ``` git revert [commit-hash] # Creates a new commit, reverting the changes of the specified commit ``` 7. 認識分支<a name="chapter-7"></a> ------------------------------- **分支**只不過是儲存庫的一個**分支**，到目前為止，所有操作都已在分支`master/main'`上執行。 > 預設情況下，儲存庫中建立的第一個分支是`master/main` ，它是儲存庫的主分支。 ### 7.1 為什麼要使用分支？ 乍看之下似乎沒什麼，但**分店卻為專案的發展賦予了巨大的力量**。 想像一下，我們正在開發一個 Web 平台，並且想要**測試一項新功能**，但我們的儲存庫已經**託管或與其他人共享**，任何有問題的更改都可能會給他們帶來糟糕的體驗。我們可以做什麼？ 如果您一直在考慮**複製並貼上**專案資料夾，建立一個新的**「測試版本」** ，那麼您是對的！嗯，差不多… 透過 GIT，我們可以對分支做類似的事情。由於它們是**分支**，我們可以簡單地**建立一個名為「test」的新分支**，從而在完全**隔離的分支**中擁有我們專案的一個版本，準備好進行翻轉，**而不會危及主分支**。  ### 7.2 建立分支（git分支） 建立**分支**意味著建立可以獨立工作的儲存庫的並行副本，而不會影響`master/main`分支。為此，我們只需執行以下命令： ``` git branch [branch-name] ``` > 在沒有特定分支名稱的情況下執行`git branch`指令必須顯示儲存庫中可用分支的列表，並用「\*」標記目前正在使用的分支。 在執行`git branch test`指令之前， `git branch`指令只會傳回`master`分支。  建立新分支後，我們可以執行以下命令在可用分支之間切換： ``` git checkout [branch-name] ``` 執行`git checkout test`指令後，我們可以看到**活動分支已切換**。從那一刻起，**所有提交的資訊都會傳送到儲存庫的`test`分支**，而不會影響分支`master/main` 。  > 可以根據需要建立任意數量的分支，並且我們可以使用以下命令與現有分支進行互動： > > `git checkout -b [branch-name]` -> 使用給定名稱建立一個新分支並直接切換到它。 > > `git branch -d [branch-name]` -> 刪除指定分支。 > > `git branch -m [new-name]` -> 將目前分支的名稱變更為給定名稱。 ### 7.3 合併分支（git merge） **當完成不同分支**上的工作，並且我們確定所做的更改不會在專案中引起任何問題時，我們可以將當前分支**合併**到`master/main`分支中，**應用當前分支中的所有更改分支到儲存庫的主分支**。 要**合併**分支，我們需要**切換到將接收更改的分支**並執行以下命令： ``` git merge [branch-name] # Merge the given branch into the active branch ``` 在這裡，由於我們位於分支`test`上，因此我們應該使用`git checkout`命令**切換到分支`master`** ，然後使用我們要合併的分支的名稱*（在本例中為“test”）*執行`git merge`命令。  透過這樣做，在分支`test`上完成的所有工作*（在本例中為`style.css`檔案的建立）*將合併到分支`master`中。  ### 7.4 合併衝突 如果**在同一行上更改了一個或多個檔案**並且合併無法**自動**完成，則使用`git merge`合併不同分支可能會導致一些**衝突**。  出現這種情況時，我們可以執行`git status`指令來檢查**哪些檔案**有衝突。  在繼續合併之前，我們需要**解決衝突**，方法是定義應該進行哪些更改，或檢查更改以使它們相互相容。為此， **GIT 將在衝突文件中插入標記**以協助解決問題。  解決衝突後，我們只需要將修改過的檔案放回舞台，提交新的無衝突版本，然後再次執行`git merge`指令，這一定會成功合併，沒有任何問題。 8. 與遠端倉庫同步<a name="chapter-8"></a> ---------------------------------- 我們已經知道可以**將本地存儲庫連接到遠端存儲庫**並遠端同步我們的所有工作，使其**保持最新**。 為此，我們需要執行`git push`命令，該**命令將所有提交從本地存儲庫發送到遠端存儲庫**，但首先我們需要\*\*配置遠端存儲庫。 ### 8.1 配置遠端倉庫 啟動*遠端儲存庫*非常簡單。這裡我們將使用**GitHub**來完成它。 首先，我們需要在 GitHub 帳戶中**啟動一個新的空白儲存庫***（只需選擇一個名稱並點擊「建立儲存庫」）* ：  接下來，我們需要透過在本機儲存庫中執行以下命令**來配置遠端儲存庫和本機儲存庫之間的關係**： ``` git remote add origin [remote-repository-url] ```  > `git remote -v` -> 顯示實際連接到本機儲存庫的遠端儲存庫的 URL。 正確**連接**遠端儲存庫後，我們需要使用指令`git branch -m main`**將本機分支`master/main`的名稱變更**為「main」 *（如果您的本機分支已稱為`main` ，請忽略此步驟）* ：  > 保持本機儲存庫的主分支與我們要推送到的遠端儲存庫的主分支同名非常重要。 最後，完成上述步驟後，我們可以使用以下命令首次將本機儲存庫與遠端儲存庫**同步**： ``` git push -u origin main ```  當我們執行`git push -u origin main`指令時，我們可能需要輸入**GitHub 憑證***（使用者和存取權杖）* 。 > 如果您不知道**GitHub 存取令牌**是什麼，或者您沒有設定存取令牌， [請按一下此處](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)。 > > 我們也可以透過**使用 GitHub CLI 設定身份驗證**來解決此問題。 [按此處](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git)了解具體方法。 經過**身份驗證**後， `git push`應該會成功執行，將本地儲存庫中的所有提交與遠端儲存庫同步。   ### 8.2 第一次後的Git推送（git推送） 完成上述所有步驟後，可以單獨使用`git push`指令完成**新同步**，無需任何其他參數，如下所示。   > 在這種情況下，使用**GitHub CLI**繞過了執行命令`git push`所需的身份驗證。您可以[點擊此處](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git)了解具體方法。 ### 8.3 更新本地倉庫（git pull） 使用**分散式**遠端儲存庫，可以**遠端**進行更改*（直接在遠端儲存庫中）* ，從而導致我們的本機儲存庫**變得過時**。 考慮到這一點，**更新本機儲存庫**並同步我們在遠端儲存庫中獲得的任何變更非常重要，**以確保本機專案始終具有遠端儲存庫中可用的最新版本**。為此，我們可以執行以下命令： ``` git pull ``` 想像一下，一個**新檔案**`README.md`已**直接在我們的遠端儲存庫中**建立，因此我們的本機儲存庫現已過時。  在本機儲存庫中，我們可以使用上面提到的`git pull`**同步**遠端儲存庫中的變更。  > 當我們執行`git pull`指令時回傳的前 7 行是`git fetch`指令的回傳。換句話說，如果我們執行`git pull`命令而不先執行`git fetch`命令，GIT 將同時執行這兩個命令以從遠端存儲庫檢索更新並將其同步到本地存儲庫。 > > `git fetch` -> 從遠端儲存庫取得更新，但不同步本機儲存庫（需要`git pull` ）。 9. 結論<a name="chapter-9"></a> ----------------------------- 這一切讓我們確信GIT是程式設計師日常生活中必備的版本控制系統，了解它的主要指令和用途可以成為我們技術資歷的轉捩點。最後，隨著本地和遠端儲存庫的同步和更新，以及我們迄今為止所學到的一切，我們已經準備好繼續推進這個令人敬畏的版本控制系統的實用性。 10. 參考文獻<a name="chapter-10"></a> --------------------------------- - [GIT 的官方文件。](https://git-scm.com/docs/git#_git_commands) - [\[PT-BR\] GIT：入門迷你課程（45 分鐘內學會） - Codigo Fonte TV](https://youtu.be/ts-H3W1uLMM?si=-hKGkUmwgT2lZJwy) --- 原文出處：https://dev.to/reenatoteixeira/everything-that-you-need-to-know-about-git-2440
開發者們大家好，我將分享一些更有效地使用 Git 的最佳實踐。**Git？**是的，就是你已經熟悉的 git。程式碼夥伴是您的守護天使，可確保您的程式設計冒險順利進行，讓開發人員能夠輕鬆地進行專案協作。 你是那個建立分支然後忘記它們存在的原因的人嗎？總是需要尋找*文件變更*才能理解提交？這裡有一些建議供您參考。 我為什麼要遵循標準？ ---------- - **清晰和理解** - **協作與團隊合作** - **易於導航和維護** - **文件和知識轉移** - **工程品質** - **自動化變更日誌** - **優化 CI/CD** 在你讀之前 ----- - **分支命名約定**和**提交訊息**約定下的每個 seb 部分分別按**基本**、**中階**和**進階規則**排序。 - 您可以根據用例和相關性遵循任何層級的規則，無論如何，建議遵循**中間規則**層級的約定。 - 以下內容根據參考部分提供的資源進行改編和組織。 --- 分支命名約定 ------ ### 基本 1. **描述性名稱**：一個命名良好的分支可以為其目的提供直接的上下文。選擇清晰的名稱，而不是通用名稱。 例如： `feature/login` 、 `bugfix/navbar-overflow` 2. **使用連字號**：使用連字號分隔分支名稱中的單字（或短橫線），這確保了可讀性。 例如， `bugfix/fix-login-issue`比`bugfix/fixLoginIssue`或`bugfix/fix_login_issue`更具可讀性。 3. **小寫字母數字字元**：僅使用小寫字母數字字元（az、0–9）和連字號。盡可能避免標點符號、空格、底線或任何特殊字元。 4. **避免不必要的連字符**：避免不必要的連字符，例如後續或尾隨的連字符。 例如， `feat/new--login-`是一種不好的做法。 5. **簡短有效**：保持分支名稱簡單。在描述性的同時，它們也應該足夠簡潔，以便一目了然地傳達目標。 ### 前綴或類型 - 為分支加入前綴有助於根據其用途來組織它們。這不僅提高了清晰度，還有助於自動化工作流程。 - 一些常見的分支類型前綴及其用例包括： - `feature/` ：用於開發新功能， - `bugfix/` ：修復程式碼中的錯誤。通常是與某個問題相關的。 - `hotfix/` ：修復生產中的關鍵錯誤。 - `release/` ：準備新版本，通常用於執行最後修改和修訂等任務。 - `docs/` ：用於撰寫、修改或修正文件。 - 例如， `feature/new-feature`或`release/version-1.0.0` 。 ### 包括票號 如果您的專案使用 Jira 等問題追蹤系統，或者它根據 github 問題或其他類似工具進行修改。在分支名稱中包含問題的令牌將使追蹤變得簡單。範例： `feature/PROJ-123-footer-links` --- 提交訊息約定 ------ - 提交訊息的最終格式： ``` <type>([optional scope]): <description> # subject [optional body] [optional footer(s)] ``` ### 資訊主題 - **命令式**：以命令式建立提交訊息。以動詞開頭來指示提交的作用。 例如：使用`fix: Fix bug #67`比`fix: Fixed bug #67` - **簡短總結**：嘗試將主題行控制在 50 個字元以內，以確保訊息在各種 Git 工具中可讀，例如使用`git log --oneline`時。避免尾隨句點和不必要的單字/符號。 - **將描述大寫**：這聽起來很簡單。主題行以大寫字母開頭。 ### 類型和訊息正文 - 主題行中的`type`前綴可用於表示提交中包含的變更的類型。一些常用的類型是： - `feat:` ：總結程式碼庫中的新功能。 - `fix:` ：修復程式碼庫。 - `build:` 、 `chore:` 、 `ci:` 、 `style:` 、 `refactor:`是其他一些例子。 - 可以將`scope`加入到提交的類型中以提供額外的上下文訊息，並將其括在括號中，例如`feat(parser): Add the ability to parse arrays` - 可以將`body`新增至訊息中，以在提交中包含詳細說明。 - 在主題行後面留空行來加入正文。 - 將正文包裹在 72 個字元處，即。使用多行正文，每行不超過 72 個字元。 頁腳和擴充訊息正文 --------- - `footer`用於傳達有關提交的附加訊息，例如審查者、批准者等。例如： - `Signed-off-by: Alice <[email protected]>` - **重大變更**： `BREAKING CHANGE`是指程式碼庫中相當重要的重大變更。可以透過加`!`來表示。在類型/範圍之後和/或透過將其加入到`body`或作為`footer` ``` chore!: drop support for Node 6 BREAKING CHANGE: use JavaScript features not available in Node 6. ``` - **多段落正文**：在某些情況下，多個段落有助於更詳細地解釋提交的目標。範例：描述提交更改的內容、原因以及方式。 #### 例子 可以[在此處](https://www.conventionalcommits.org/en/v1.0.0/#examples)找到提交訊息的各種用例範例。 結論 -- 遵守 Git 約定類似於說通用語言。然而，很明顯，這些標準或約定並沒有被任何系統強制執行；因此，這些標準的調整和擴展使用完全取決於我們。 養成這些習慣肯定會改善您的 Git 體驗並鼓勵協作編碼環境。儘管我們不能一下子就遵循這些，但逐漸適應它們無疑會有所不同。 我計劃寫一篇關於**使用 Husky 實現 Git 約定的文章**，透過反應和評論來表達您的支持。快樂編碼！ 參考 -- - [Git 分支的命名約定 — 備忘單，作者：Abhay Amin](https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534) - [常規提交](https://www.conventionalcommits.org/en/v1.0.0) - [Git 約定](https://se-education.org/guides/conventions/git.html) - [如何透過 CBEAMS 撰寫 Git 提交訊息](https://cbea.ms/git-commit) - [Git 預告片](https://git-scm.com/docs/git-interpret-trailers) --- 原文出處：https://dev.to/shinjithdev/git-good-best-practices-for-branch-naming-and-commit-messages-oj4
我們中的許多人已經在 Product Hunt 上推出了一段時間，**越來越多的人開始質疑那裡的受眾是否真誠，以及是否仍然值得在他們自己的平台上推出**。 一周前剛剛推出了我們的最新產品，我想在這裡分享我們的第一手經驗並涵蓋三個主要內容： - 今天就推出 Product Hunt 的外觀和感覺如何 - 我們從發布中得到了什麼 - 如何（最好）利用 Product Hunt 來開發您的產品 關於我們 - 推出 6 次，超過 2,000 票贊成 -------------------------- 在過去 3 年裡，我們在 Product Hunt 上推出了 6 次，贏得了「最佳產品」獎（當天排名第 1 和第 5 名），並總共收集了超過 2,000 個讚。一週前，我們剛完成了[Open SaaS 的第六次發布，這是 300 美元以上 SaaS 入門產品的開源替代品](https://github.com/wasp-lang/open-saas/)。  您會發現許多文章為在 PH 上推出提供建議，並從那些獲得推薦的人那裡贏得故事，但幾乎沒有人分享幕後知識以及實現這一目標的真正需求。這就是這篇文章的目的。 我將引導您完成啟動步驟並發表評論並分享我們在每個步驟中的經驗。讓我們開始吧： 安排您的發布並建立“即將推出”預告片 - “讓我們交換贊成票” -------------------------------  一旦您安排了Product Hunt 的發布，您就可以建立一個橫幅，顯示在他們的「即將推出」頁面(https://www.producthunt.com/coming-soon) 上，這就是您的旅程開始的地方。這使 PH 訪客有機會了解接下來會發生什麼，並訂閱以在發布後收到通知，這也是您可以用來行銷您的發布的第一個東西。 **這也是 PH 經濟開始的時候 - 一旦您發布發布預告片，您將開始收到與其他即將推出其產品的人交換贊成票的報價**：  這實際上是一種合法的策略（從共享激勵而不是購買選票的意義上來說），可以透過自動化非常有效地利用。它不會帶來任何合格的潛在客戶（也就是真正對您的產品感興趣的人），但它可能有助於獲得投票，從而提高您的產品發布的知名度和影響力。 我們根本沒有使用過這個策略（所以我無法證明它的效率），因為我們很晚才發布“即將推出”頁面，就在發布前一兩天，而且我們也沒有工作流程沒有地方也沒有人力來完成它。 Linkedin、WhatsApp 和其他平台上也有專門的小組，讓 PH 參與者可以互相支持。如果您加入這些活動，您將會收到更多此類訊息和請求。 發布日 - 主動發送的電子郵件和「購買投票」優惠 ------------------------ 發布當天，類似上述的要求愈加強烈。我甚至收到了其他人在同一天推出產品的幾封電子郵件，要求我投票，因為他們刪除了我的電子郵件並將我加入到他們的時事通訊中。 ### 當天的前 4 小時 - 隱藏點讚 Product Hunt 最近推出了在一天的前 4 小時內以隨機順序顯示產品的功能，並隱藏點讚數。背後的想法是保證所有產品一開始就有平等的知名度，並有公平的機會吸引觀眾的注意。 隨著我們最新推出的 Open SaaS，我們取得了有史以來最好的開局 - 4 小時內獲得 100 票贊成！  當然，我們參與了我們的網絡，但也注意到來自我們不認識的人的大量投票和評論。有瞭如此強勁的開局，我非常有信心我們能躋身排行榜前 5 名產品之列。 > 進入前 5 名產品是 Product Hunt 主頁上的「首屏」位置，因此儘早到達那裡是最終進入該位置的最佳方式。 > 但當排行榜最終揭曉時，Open SaaS 勉強躋身當天發布的前 10 名！  前五名與其他產品之間存在著相當明顯的差距，第一名的產品的支持率幾乎是第二名的兩倍。**這對我們來說相當沮喪，因為感覺我們追趕的機會幾乎是零。** ### “嘿，想買點讚嗎？” 排行榜揭曉後，我們開始收到另一種類型的訊息——直接購買點讚的報價。仍然相對接近前 5 名的產品可能使我們成為一個非常合格的領導者：  與此略有不同的是，讓不同的社群媒體影響者和社群所有者伸出援手，向他們的追隨者推銷您的產品，並承諾獲得 X 票：   甚至我們的一些直接聯絡人也知道“一個人”可以讓你到達 Product Hunt 的頂端，並主動提出介紹我們，所以這有點像一個“公共秘密”，而我們是少數不知道的人關於它。 我們從發布中得到了什麼 - #7、HN 頭版、GitHub 上的趨勢… -----------------------------------  **我們 PH 發布的主要好處不是發布本身，而是我們可以將其與其他東西結合起來，例如**[在 HackerNews 上發布 Open SaaS](https://news.ycombinator.com/item?id=39192304) **，**它最終在其中展示了大約半天（在 Show 上展示的時間更長） HN 選項卡）。  最後，所有這些參與度加起來讓我們能夠在 GitHub 上獲得全球趨勢，這反過來又為 Open SaaS 帶來了更多流量（今天，在發布一周後，它已經擁有[超過 2500 顆星](https://github.com/wasp-lang/open-saas/)）。  ### 由此產生的流量 看看過去兩週 Open SaaS 儲存庫帶來的流量，我們可以觀察到以下內容：   HackerNews 的推出吸引的人數是 Product Hunt 的三倍多。 GitHub 吸引了更少的人存取實際的儲存庫，但我的直覺是，更多的人在沒有離開「趨勢」頁面的情況下加註了星標。 在 PH 的每日時事通訊中獲得專題報告 - 有幫助嗎？ ---------------------------  Open SaaS 在發布結束時成為當天排名第七的產品，獲得約 400 票贊成。根據 Product Hunt 的資料，當日排名前 10 名的產品最終會出現在擁有超過 50 萬訂閱者的每日新聞通訊中。 該時事通訊以 3 個大型促銷區塊開始，因此您必須滾動相當長的時間才能到達前一天的熱門產品。  對我們來說，它並沒有產生太大的影響，我認為它為我們贏得了大約 20 票。也許是因為我們不是第一，或者只是因為它是一個相當深的漏斗（打開電子郵件 → 一直向下滾動 → 檢查所有產品 → 喜歡 Open SaaS → 決定投票）。  在沒有任何提升策略的情況下是否有可能贏得當天的第一名？ --------------------------- **是的，這絕對是可能的。我已經得到了幾個我信任的聯絡人的證實，他們用他們的產品贏得了第一名，沒有任何機器人或支付贊成票。**但它也肯定變得不那麼常見和難以預測。 大多數時候，我們推出的產品首先會表現出一些不尋常的行為。有一次，是該公司在前一周推出，但他們只是稍微重新命名了產品和網站，然後重新推出。還有一次，一款產品在發布結束前幾個小時突然獲得了很高的支援率。 那麼，這意味著什麼？它還值得在 Product Hunt 上推出嗎？ ---------------------------------- 顯然，今天雙方都有不同的力量和動機驅動 Product Hunt 用戶的行為。最初，有一個社區想要了解最新產品並表達他們的興趣，並且有一些創始人想要連接到該社區。 **現在，也有一些創作者最希望自己的產品獲勝，無論實際的受眾參與度如何，因為他們相信這將有助於他們實現最終目標，例如影響範圍、籌款或對其他用戶的社會認可。顯然，有一方願意滿足這項需求，但對產品並沒有任何真正的興趣。** 為什麼這可能？ Product Hunt 正在採取許多措施來偵測和防止此類行為，但如果不嚴格限制 Product Hunt 所追求的網路效應（即能夠分享您的啟動連結），就很難做到這一點。 **除此之外，對我們來說，定期在 Product Hunt 上發布仍然是值得的。原因如下。** 產品搜尋是一個很棒的藉口 ------------ Product Hunt 為您提供了一個獨特的機會來宣布您的產品「正式」發布。您可以決定在哪一天執行此操作並安排時間，並且 100% 所有人都能看到它，您也可以分享並邀請人們查看。**你有 24 小時的時間，在此期間，你完全有理由聯繫你認識的每個人（以及其他人）並繼續按喇叭。**  **Reddit 和 HackerNews 等其他高影響力平台無法做到這一點。**當然，您可以隨時分享有關您產品的新聞，但不能保證任何人都會看到它（實際上恰恰相反），除非社區的集體思想決定如此，這幾乎是確定性的。您可以輕鬆地花費一周的時間來準備您的發布帖子，但它會在幾分鐘內被演算法淹沒。 **這就是為什麼我們不將 Product Hunt 視為最終目標（贏得第一名），而只是將其視為我們整個發布過程的一部分。這是一個很棒的講台，也是一個談論你的產品的好藉口，而上面的任何其他東西都只是一個額外的好處。** 我們保持簡單 ------ 您會發現很多來自「PH 專家」的文章（和付費課程），解釋您應該如何提前幾個月準備發布、預熱您的受眾、準備他們將分享的評論等。**我們不做任何這些事情。我們只需準備內容（影片+一些螢幕截圖和介紹性評論），然後在發布當天邀請我們認識的所有人支持我們。然後，白天我們也會在 Reddit、Hackernews 和 dev.to 上發文。**  有時我們最終會進入前 5 名，有時則不然，**但每次，我們的用戶參與度都會穩步提升，並且通常會在接下來的幾天/幾週內出現更好的結果**。例如， [MAGE，我們基於 GPT 的全端應用程式啟動器](https://usemage.ai/)，在 PH 發布後就出現了爆炸性增長，並[在幾個月內被用來建立了 30,000 多個專案](https://dev.to/wasp/how-we-built-a-gpt-web-app-generator-for-react-nodejs-from-idea-to-25000-apps-in-4-months-1aol)。 我們經常這樣做 ------- 我們的目標是每 3 個月發布一次 Product Hunt，作為發布週的一部分，這就是我們迄今為止所做的。除非 6 個月過去了或有重大更新，否則您無法真正推出完全相同的產品，但您可以自由地推出與主產品相關的其他（子）產品和功能。 > **💡 提示**：當您提交發佈時，您可以要求 PH 團隊將其「連接」到您的產品，以便它將出現在該產品的發布清單中。通常，他們自己做。它看起來像這樣：  雖然我們的主要產品是[Wasp，一個基於 React 和 Node.js 的全端框架](https://github.com/wasp-lang/wasp)，但到目前為止我們推出的產品如下： - **Wasp Alpha** - 純產品，v0 差不多 - **Wasp Beta** - 差不多兩年過去了，我們還沒有採用「經常發布」的方法 - **免費 SaaS 模板**- [Open SaaS](https://github.com/wasp-lang/open-saas)的前身，4 個月後 - [\*\*MAGE，GPT Web 應用程式產生器](https://usemage.ai/)\*\* - 由 Wasp 提供支援的全端 Web 應用程式產生器 - [**React/Node 的全端身份驗證，無第三方服務**](https://wasp-lang.dev/docs/auth/overview)- Wasp 的身份驗證功能 - 最後， **[Open SaaS - 300 美元以上 React 和 Node.js SaaS 初學者的免費開源替代品](https://github.com/wasp-lang/open-saas/)** 它已成為我們發布工作流程的常規部分，對於我們在該季度推出的任何新功能，我們都會尋找一個好的候選人在即將推出的發布中展示。這使我們能夠繼續談論我們所做的事情，並且我們還獲得了很多可以嵌入到我們的文件、部落格文章等中的好內容（例如影片、橫幅）。 例如，這個影片展示了 Wasp 中的身份驗證如何運作 - 首先我們將它用於我們的[Product Hunt 發布](https://www.producthunt.com/products/wasp-lang-alpha#full-stack-auth-for-react-node-by-wasp)，現在它[位於我們的身份驗證文件的頂部](https://wasp-lang.dev/docs/auth/overview)。 {% 嵌入 https://www.youtube.com/watch?v=Qiro77q-ulI&ab\_channel=Wasp %} 謝謝閱讀！ ----- 感謝您閱讀本文！這篇文章比我最初預期的要長得多，但我不斷獲得更多關於要寫什麼的想法。我希望您會發現它對計劃下一次發布有所幫助，並且您也會更好地了解在此過程中會發生什麼。 我也很想得到您的回饋，並了解您在 Product Hunt 上推出的經驗和策略。 快樂發射！ --- 原文出處：https://dev.to/wasp/product-hunt-has-become-pay-to-win-but-you-should-still-use-it-to-launch-your-product-508d
大家好，最近以工作上不太有機會用到的技術來練習專案： https://goods.carrier.express 使用 Astro + Solid.js，搭配 Sanity.io 當作內容管理 除了想要獲得操作的流暢度回饋以外， 還想要知道「**夠不夠安全**」？ 其實也只是 secret key 放在 environment variable。 之前曾經以相同的方法取用 secret，在面試時，對方一下子就從瀏覽器挖出使用的 secret， 感覺很像當場被扣到 0 分， 事後在社群問怎麼解決，得到回饋大多是「前端沒有秘密」。 想知道怎麼做，才可以在安全問題達到基本要求呢？謝謝！
身為開發人員，我總是在尋找那些小細節，因為細節很重要。 我們都是 DEV 上一個大社群的一部分，在這篇文章中，我很高興分享一些您可能不知道的這個平台上意想不到的功能和技巧。 讓我帶您了解在 DEV 上可以做的 12 件令人驚訝的事情，從建立自訂按鈕到建立評論範本！ 請評論並讓我知道哪一點最讓你驚訝。 --- 1.使用標籤過濾貼文。 ----------- 隨著我們的提要中不斷出現帖子，擁有一些控制和過濾器至關重要。一種方法是使用標籤過濾貼文。 例如，要查看帶有`#discuss`標籤的帖子，只需導航到[dev.to/t/discuss](https://dev.to/t/discuss) 。 同樣，如果您想要帶有標籤`#softwaredevelopment`的帖子，請前往[dev.to/t/softwaredevelopment](https://dev.to/t/softwaredevelopment) 。 作為一般規則，您可以使用它。 ``` https://dev.to/t/paste_your_tag_without_spaces ``` 您可以將上述 URL 與您的標籤貼在一起，以查看相關類別中的熱門貼文。  您可以找到負責處理該特定標籤的標籤管理員。 如果您想知道，標籤管理員負責維護標籤與貼文的相關性。 您可以在[dev.to/dashboard/following\_tags](https://dev.to/dashboard/following_tags)檢查您關注的標籤。 所有標籤的完整清單可在[dev.to/tags](https://dev.to/tags)上找到。 --- 2.基於官方標籤的便利資源。 -------------- 它可能與第一個相關，但並非每個標籤都如此。 某些標籤提供了方便的官方資源，例如`tailwindcss`的文件或`nextjs`的有用指南。這些資源可能很有價值，尤其是當您不熟悉某個特定標籤時。  例如， `nextjs`標籤有不錯的資源:)  這些「小細節」讓DEV平台更加人性化、資訊豐富。 --- 3.RSS 源。 -------- 向 5 歲的孩子解釋 RSS feed： > 想像一下，您有一個最喜歡的卡通節目，每次有新劇集時，您的神奇電視就會向您展示它。 RSS 提要就像網站的神奇信使。當您最喜歡的網站上有新內容時，它會告訴您的計算機，這樣您就可以看到它，而無需一直檢查。這就像一個友好的通知，說：「嘿，您喜歡的網站上發生了一些有趣的事情！」。 這就像擁有來自多個來源的內容的個人化新聞源。 - 使用以下命令檢查您的 DEV RSS 提要： `dev.to/feed/your_username` - 檢查我用來尋找 RSS 來源 URL 的[Chrome 擴充功能](https://chromewebstore.google.com/detail/get-rss-feed-url/kfghpdldaipanmkhfpdcjglncmilendn)。 在本[指南](https://dev.to/p/publishing_from_rss_guide)中詳細了解如何從 DEV 的 Feed 建立草稿。 前往[dev.to/settings/extensions](https://dev.to/settings/extensions)貼上您的 RSS Feed URL 並將其與您的 DEV 設定檔整合。 假設您有自己的博客，每當您將博客發佈到您的網站時，開發人員都會將該博客作為草稿帖子獲取，您可以從儀表板發布該博客。  ### 什麼是規範 URL？ 想像一下您有一個網頁，並且有它的一些副本或變體。 （您的個人部落格+DEV部落格） 規範 URL 就像將主要 URL 標記為老闆一樣——原始來源。 它可以幫助搜尋引擎了解哪個版本是最重要或首選的，從而防止混淆並提高網頁的搜尋引擎排名。 重新發佈內容以保持搜尋引擎的清晰度時，了解規範 URL 至關重要。 --- 4.許多創新事物的瘋狂徽章。 -------------- DEV 每週根據文章中介紹的技術授予多個徽章。從技術堆疊徽章到「喜愛的評論」徽章等古怪徽章，每個徽章都有自己的魅力。 例如，如果您使用 React 撰寫文章並被視為本週最佳作者，您將獲得 React 徽章。  我忍不住分享我對我看到的一些可愛徽章的興奮之情。  我認識幾個擁有這枚心愛徽章的人。 如果你知道，請評論！    誰有這個？哈哈！值得聚會。  我有這個，但沒有贏得任何遊戲🤣  前 7 位作者徽章通常被認為是最負盛名的，是我個人最喜歡的。獲得此徽章本身就是一種榮譽。  我無法一一列舉；否則，人們會生氣。哈哈！ 在[dev.to/badges](https://dev.to/badges)上探索徽章的完整清單。 --- 5.軟體比較。 ------- 比較軟體並不是一個新趨勢。我們一直這樣做。 因此，開發團隊列出了社群建立的熱門貼文清單。人們通常會一遍又一遍地瀏覽這些帖子。 名單包含約 350 多家軟體公司。必須檢查！ - [dev.to/software-comparisons](https://dev.to/software-comparisons) - 軟體比較  --- 6. 為圖像新增標題。 ----------- 在 DEV 貼文中，您可以為圖像加入標題，以提供上下文或附加資訊來補充所顯示的圖像。 這是在圖像中導航的一種有趣的方式。 以下是您可以如何做到這一點。 您必須在圖像後面使用`<figcaption>`標記。 例如，請參見下圖及其文法。  Anmol Baranwal 的 GitHub 簡介 ```  <figcaption> GitHub Profile of Anmol-Baranwal </figcaption> ``` --- 7.訂閱評論。 ------- 通常，作為帖子的作者，您會自動訂閱所有評論。 這意味著您將收到該帖子的每條評論的通知。 然而，有趣的是，您還可以訂閱其他貼文的評論。我建議這樣做，特別是對於帶有`#discuss`標籤的帖子，因為它可以讓您接觸到各種觀點，最終獲得寶貴的學習經驗。 - `top-level comments`的通知是一個方便的功能。  --- 8. 嵌入和換行。 --------- 大多數人都已經知道這一點了。 但對於那些不這樣做的人，您可以嵌入任何影片，以便可以播放影片而不是粘貼連結。 它允許觀眾直接觀看影片，而無需存取其他網站。 ``` {% embed paste_url_here %} ``` 例如，嵌入我的 DEV 設定檔將如下所示。 {% 嵌入 https://dev.to/anmolbaranwal %} 有些人可能不知道使用` `建立換行符。 這種簡單的技術可以提高貼文的可讀性。 例如，可以使用` `將第一個句子與下一個內容分開。 。 第二句話由換行符號分隔。 --- 9. 號召性用語按鈕。 ----------- 這是最酷的！ 您知道您可以製作帶有描述的個人化按鈕嗎？如此令人興奮！ 這是吸引註意力和增強參與度的便捷方式，而且非常容易實施。 例如，讓我們為我的 GitHub 個人資料建立一個 CTA： {% cta https://github.com/Anmol-Baranwal %} 🚀 造訪我的 GitHub 個人資料 {% endcta %} 您可以使用以下語法來建立該按鈕： ``` {% cta https://github.com/Anmol-Baranwal %} 🚀 Visit My GitHub Profile {% endcta %} ``` 這種個人化的風格可以為您的貼文增添全新的維度。 該語法使用 Shopify 建立的[Liquid 標籤](https://github.com/Shopify/liquid)。 --- 10. 完整的編輯指南。 ------------ 這是即使是頂級作者也可能不知道的隱藏寶石。 DEV 團隊製作了一份全面的編輯器指南，幾乎涵蓋了使用編輯器的各個方面。它是回答以下問題的一站式資源： - 如何為圖像加入標題 - 支援的 URL 嵌入 - 如何新增不會顯示在內容中的評論（作者註） - Markdown 基礎+推薦封面圖片尺寸（1000 \* 420） - 他們甚至涵蓋了可存取性等等。 請在[dev.to/p/editor\_guide](https://dev.to/p/editor_guide)閱讀完整指南。 非常感謝開發團隊建立瞭如此方便的指南！請關注官方開發團隊並加入其中：） {% 嵌入 https://dev.to/devteam %} --- 11.評論範本。 -------- DEV 提供的另一個很棒的功能是保存評論範本的能力。無論是自我介紹還是分享社群媒體 URL，這些範本都可以節省您的時間並提高互動的一致性。 它可能很小，但它的威力很大！ 它與 GitHub 上常見的功能非常相似。  讓我們看看它是如何工作的。 若要設定評論模板，請造訪[dev.to/settings/response-templates](https://dev.to/settings/response-templates)  您可以輕鬆新增帶有短標題的新範本以供快速參考。  當您位於帖子的評論部分時，請點擊右下角的三個點 -> 然後點擊書籤符號。您將找到可以直接使用的模板清單。  值得信賴的用戶甚至可以獲得預先定義的模板列表，以更加方便。  --- 12. 播客？影片?以及隱藏標籤的力量。 -------------------- 您知道您可以在 DEV 上傳貼文影片嗎？  您可以在[dev.to/dashboard](https://dev.to/dashboard)的左下角找到上傳影片的選項  這是改進您的帖子的絕佳方法。在[dev.to/videos](https://dev.to/videos)上發現這些影片貼文。 DEV 還設有專門討論播客的部分。您甚至可以在[dev.to/pod](https://dev.to/pod)上提交自己的播客以供審查並探索其他各種播客。 > 個人化提要的隱藏標籤 隱藏標籤是一種讓您能夠更好地控制所看到的內容的方法，也是一種從 Feed 中隱藏您不想看到的內容的方法。  您可以在標籤頁面上隱藏標籤 - 使用搜尋來尋找您想要隱藏的特定標籤  您也可以在儀表板的「以下標籤」部分隱藏標籤 - 按三個點即可存取隱藏選項 - 您可以在[dev.to/dashboard/hidden\_tags](https://dev.to/dashboard/hidden_tags)找到隱藏標籤。  您可以查看儀表板上隱藏的標籤並取消隱藏它們 此功能可確保在 DEV 上提供更個人化和愉快的瀏覽體驗。 我不會討論 API，因為這會讓帖子變得很長。 不過，如果您有興趣，可以探索有關[Forem API 的](https://developers.forem.com/api/v1)更多資訊。 --- 獎金 -- 我知道我知道！ 我承諾了 12 件事，但這裡還有一些關於「只要有人讀你的博客，你就可以賺錢！」的額外內容。 在這篇富有洞察力的[部落格文章](https://dev.to/hacksultan/web-monetization-like-i-m-5-1418)中探討網路貨幣化的概念。這是一本很棒的指南，解釋了您需要了解的一切。 您還可以閱讀有關如何成為[DEV Mod](https://dev.to/community-moderation)並與其他社區成員合作的更多資訊。 --- 我不知道你怎麼想，但我特別興奮， `DEV`團隊可能還隱藏著更多寶藏。哈哈！ 我希望你今天學到了一些新東西。 我喜歡 DEV 社區，因為它是接觸各種精彩內容的絕佳場所：生動的討論帖子、深入的教程、庫更新、職業建議等等。 > 如果您熱衷於贊助這篇文章，請給我發訊息 [email protected] 或在 Twitter 上聯繫我！ 🚀 如果您喜歡我的內容，請透過在我的 GitHub 和 Twitter 上關注我來支持我。 - [GitHub](https://github.com/Anmol-Baranwal) - 繼續建造！ - [推特](https://twitter.com/Anmol_Codes) - [領英](https://www.linkedin.com/in/Anmol-Baranwal/) {% 嵌入 https://dev.to/anmolbaranwal %} 多寫，多啟發。  --- 原文出處：https://dev.to/anmolbaranwal/12-things-you-didnt-know-you-could-do-with-dev-2041
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
