開發者朋友您好！ 我知道不斷學習和進步是多麼困難。跳過一些被低估的知識是多麼容易，但成為偉大的開發人員所必需的。 在我的旅程中，我發現了一些非常寶貴的資源，我真的不敢相信它們是免費的。以下是其中兩個： ### 1.[重構大師](https://refactoring.guru)  這個網站有大量的知識，充滿了美麗的插圖和清晰的解釋，我還沒有找到更好的。 它詳細涵蓋了兩個主要主題：重構的藝術和設計模式。 您將了解如何準確確定程式碼髒的原因以及清理程式碼並使程式碼可讀且更易於維護的正確方法。 此外，您還可以閱讀所有 22 種經典設計模式。 哦，它有多種語言的程式碼範例！ ### 2.[鍛煉](https://exercism.org/)  如果您正在學習或正在考慮學習新的程式語言，那麼這裡就是正確的地方。 Exercism 是一個透過實踐學習的平台，透過練習從簡單的世界到高級和困難的挑戰。 有 70 多種語言可供學習，其中一些語言有特殊的學習路線圖。所有練習都按主題分組，您需要學習一個主題才能解鎖在此基礎上建立的其他主題。這對於快速學習非常有用，而且不會浪費時間從一篇文章跳到另一篇文章，來回。 有些語言和技術有很棒的文件並且教得很好，而其他語言和技術則不然。因此，運動總是可以增加你的學習經驗。 ### 結論 這就是本文的全部內容。感謝您的閱讀，並且不要忘記在評論中貢獻並失望您不相信的資源是免費的或如此便宜的資源。 💻👋🏻 再見... --- 原文出處：https://dev.to/kochiyama/2-sites-to-become-a-better-developer-2f9j
> 最初發佈在[我的部落格](https://devinduct.com/blogpost/16/styling-html-checkboxes-is-super-easy)上 老故事 --- 過去，像`checkbox`這樣的 HTML 元件很難按照我們想要的方式設定樣式。通常這些元件會突顯整個頁面設計，這對使用者體驗不太好。 更不用說每個瀏覽器都有（並且仍然有）自己的控制外觀，從而導致不同瀏覽器之間的外觀和感覺有所不同。 為了克服這些情況，開發人員過去常常進行大量駭客攻擊，例如隱藏輸入、為複選標記建立圖像和圖標以及加入一堆 JavaScript 程式碼來處理檢查/取消檢查。如果你問我，這並不那麼漂亮，而且似乎需要做很多工作才能實現一些簡單的事情。 新故事 --- 上述時代早已過去，我們比以往任何時候都更接近在所有瀏覽器上看起來和感覺都相同的複選框樣式的通用方式，特別是有訊息稱 Microsoft 正在建置基於 chromium 的瀏覽器。你可以[在這裡](https://www.windowscentral.com/microsoft-building-chromium-powered-web-browser-windows-10)讀到它 。 從我的角度來看，新的故事是我們可以設定複選框的樣式而不隱藏它，也無需加入 SVG 圖像和 JavaScript 程式碼。這可以透過使用以下方法來完成： 1. CSS `appearance`屬性 2. HTML `check mark`符號 (✓) ### 外觀性能 > 外觀屬性用於使用基於使用者作業系統主題的平臺本機樣式來顯示元素。 這個屬性支援許多值，但我們感興趣的是值`none` 。基本上，我們想要刪除所有本機樣式並套用自訂樣式。最後，我們的複選框將具有漂亮的顏色和過渡，最重要的是，它在所有主要瀏覽器中的外觀和感覺都相同。 用法範例： ``` .my-class { -webkit-appearance: value; -moz-appearance: value; /* -o-appearance: value; - Not required since the new version of Opera uses - webkit prefix for this property, but we've added it nevertheless just to be aware of it */ appearance: value; } ``` 好的，讓我們深入研究程式碼。 超文本標記語言 ------- 我們的 HTML 標記非常簡單。我們有一個`label`包裹我們的`input`和一個`span`來保存文字。它看起來像這樣： ``` <label class="checkbox"> <input type="checkbox" /> <span>Check Me</span> </label> ``` 這裡沒有什麼太花俏的。我們使用包裝元素來更輕鬆地垂直對齊內部專案。這是透過我們將在 CSS 部分看到的 Flexbox 佈局來完成的。 CSS --- CSS 樣式如下所示： ``` .checkbox { display: inline-flex; cursor: pointer; position: relative; } .checkbox > span { color: #34495E; padding: 0.5rem 0.25rem; } .checkbox > input { height: 25px; width: 25px; -webkit-appearance: none; -moz-appearance: none; -o-appearance: none; appearance: none; border: 1px solid #34495E; border-radius: 4px; outline: none; transition-duration: 0.3s; background-color: #41B883; cursor: pointer; } .checkbox > input:checked { border: 1px solid #41B883; background-color: #34495E; } .checkbox > input:checked + span::before { content: '\2713'; display: block; text-align: center; color: #41B883; position: absolute; left: 0.7rem; top: 0.2rem; } .checkbox > input:active { border: 2px solid #34495E; } ``` 如果您認為這仍然是大量 CSS，請讓我提醒您，我們不需要 Flexbox 佈局或過渡來實現此樣式。加入此內容是為了使其更加優雅。如果我們刪除額外的 CSS，我們需要做的就是透過將`appearance`設為`none`來刪除預設樣式，新增邊框和顏色並設定 HTML 符號。 讓我們分解一下重要的部分來支持上面的陳述。第一步是使用`appearance`屬性並刪除預設樣式： ``` ... -webkit-appearance: none; -moz-appearance: none; -o-appearance: none; appearance: none; ... ``` 希望這個屬性很快就會成為標準，我們將能夠在沒有瀏覽器特定前綴的情況下使用它。 接下來，我們需要提供自訂邊框和背景： ``` ... border: 1px solid #34495E; border-radius: 4px; outline: none; background-color: #41B883; cursor: pointer; ... ``` 最後，我們將使用`::before`偽類別來設定 HTML 符號的樣式。在我們檢查輸入欄位後，下面的 CSS 將顯示 HTML 符號，顏色和位置都很好。 ``` ... content: '\2713'; display: block; text-align: center; color: #41B883; position: absolute; left: 0.7rem; top: 0.2rem; ... ``` 就是這樣！真的就是這麼簡單。為了將複選框設計與頁面的其餘部分相匹配，無需再使用 JavaScript 來實現這些樣式。我們可以使用這裡提供的 CSS 安全地實現它。 這是一個可以使用程式碼的現場小提琴： https://jsfiddle.net/proticm/2wzatymr 進一步閱讀 ----- 如果您對 CSS 變數感興趣，請查看[這篇文章](https://devinduct.com/blogpost/10/css-variables-cheat-sheet)或我的部落格上發布的[這篇](https://devinduct.com/blogpost/11/ui-theming-with-css-variables)文章。 [外觀屬性](https://developer.mozilla.org/en-US/docs/Web/CSS/appearance)請參閱官方文件 --- 原文出處：https://dev.to/proticm/styling-html-checkboxes-is-super-easy-302o
Visual Studio Code 是目前市場上非常受歡迎且使用者友好的程式碼編輯器。如果您專注於使用 JavaScript 框架進行前端開發，這些擴充功能可以大大提高工作效率並節省您的時間。 在眾多類似的文章中，這篇文章有何不同？嗯，這是基於我個人的開發經驗。同事經常詢問我使用的擴充程序，本文分享了他們的見解。如果您正在尋找久經考驗的擴充功能來增強您的編碼體驗，那麼您可以在這裡找到它們。 文字格式和可讀性 -------- ### [Prettier — 程式碼格式化程序](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) 此擴充功能會自動格式化您的程式碼，使其看起來整潔且一致。這就像有一個私人助理來整理你的程式碼，可以節省你大量的時間和精力。可以根據我們專案的需求進行配置。 ### [色彩高光](https://marketplace.visualstudio.com/items?itemName=naumovs.color-highlight) 這個擴充功能是一個被低估且有用的工具，專門用於 UI 開發。它在程式碼編輯器中突出顯示顏色，使您可以輕鬆地使用顏色程式碼並確保精美的視覺呈現。在下面的螢幕截圖中，顏色`#43feee`被突出顯示，減少了出錯的機會。  ### [凹入彩虹](https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow) 它透過使用縮排顏色視覺化縮排等級來提高程式碼的可讀性。此擴展為每個縮排層級加入了微妙的顏色變化，使嵌套程式碼結構更易於一目了然地解析。  ### [改變大小寫](https://marketplace.visualstudio.com/items?itemName=wmaurer.change-case) 它提供了在camelCase、CONSTANT\_CASE或snake\_case之間進行轉換的直覺快捷方式，使大小寫轉換無縫且輕鬆。  ### [程式碼拼字檢查器](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker) 它有助於發現程式碼中的拼字錯誤和拼字錯誤，確保程式碼更清晰、更具可讀性。它是維護程式碼品質和避免意外錯誤的有用工具。  --- 程式碼品質和改進 -------- ### [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint) ESLint 是確保 JavaScript 程式碼品質的寶貴工具。它會掃描您的程式碼中的錯誤、樣式不一致和常見錯誤，這有助於您維護更乾淨、更可靠的程式碼。您可以透過在設定檔中建立一組自訂[規則](https://eslint.org/docs/latest/rules/)來為您的專案配置 ESLint。 例如，如果您的專案禁止嵌套三元表達式，ESLint 將在您的編輯器中標記它們。同樣，如果沒有定義像 DDMMYYYY 這樣的變數，ESLint 會突出顯示它。您甚至可以指定每種類型問題的嚴重性級別，從而確定優先順序並相應地解決它們。這種積極主動的程式碼品質方法有助於防止錯誤並保持整個專案的一致性。  ### [誤差鏡頭](https://marketplace.visualstudio.com/items?itemName=usernamehw.errorlens) 它是一個 VS Code 擴展，可增強程式碼編輯器中的錯誤突出顯示。它提供常見錯誤和警告的即時回饋，使開發人員能夠在編寫程式碼時快速解決問題。  ### [JS重構助手](https://marketplace.visualstudio.com/items?itemName=p42ai.refactor) 對於使用 JavaScript、TypeScript、React 和 Vue.js 的開發人員來說，這是一個不可或缺的工具。它提供了超過 120 個程式碼操作，可以有效地編輯、現代化和重構程式碼，使程式碼維護和最佳化變得更加容易。  ### [聲納林特](https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarlint-vscode) 它提供了比簡單的 linting 更全面的程式碼分析。 SonarLint 不僅可以偵測編碼問題，還可以更深入地了解程式碼品質、安全漏洞和潛在的效能瓶頸。 它利用基於行業最佳實踐的規則集，並可以與 SonarQube 或 SonarCloud 整合以進行集中程式碼品質管理。對於較大的專案，強烈建議這樣做。  --- 開發工具和實用程式 --------- ### [控制台忍者](https://marketplace.visualstudio.com/items?itemName=WallabyJs.console-ninja) 它透過直接在程式碼旁邊顯示 console.log 輸出和執行時錯誤來改進 JS 開發工作流程。此擴充功能提供了對偵錯資訊的便捷存取，增強了程式碼理解和問題解決。  ### [Turbo 控制台日誌](https://marketplace.visualstudio.com/items?itemName=ChakrounAnas.turbo-console-log) 它加速了寫入有意義的日誌訊息的過程。此擴充功能可自動插入 console.log 語句，從而在偵錯和故障排除任務期間節省時間和精力。這是我的清單中最常用的擴充功能之一，經常被問到。 1. 選擇或懸停作為除錯主題的變數（手動選擇將始終接管懸停選擇） 2. 按`ctrl + alt + L` (Windows) 或`ctrl + option + L` (Mac) 日誌訊息將插入到與所選變數相關的下一行。  ### [吉特透鏡](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens) 對於依賴 Git 進行版本控制的開發人員來說，它是必備的擴充。透過 GitLens，您可以輕鬆地視覺化程式碼作者身份、瀏覽 Git 儲存庫，並獲得有關專案歷史和演變的寶貴見解。  GitLens 的主要功能之一是它能夠直接與程式碼內聯顯示詳細註釋或「指責」訊息。這使您可以查看誰最後修改了每行程式碼以及進行更改的時間。透過提供這種程度的程式碼作者可見性，GitLens 可以幫助您了解每行程式碼背後的上下文，並與您的團隊更有效地協作。  ### [Mintlify 文件編寫器](https://marketplace.visualstudio.com/items?itemName=mintlify.document) 它是一款基於 AI 的 VS Code 文件工具。它為使用各種程式語言編寫文件提供智慧建議和自動完成功能。 透過支援 Markdown 格式並與 VS Code 無縫集成，它可以幫助開發人員輕鬆建立專業文件。  ### [進口成本](https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost) 此擴充功能將在編輯器中內嵌顯示導入包的大小。此擴充功能利用 webpack 來偵測導入的大小。 它透過辨識專案中使用的重型庫來幫助提高性能。  --- 特定語言的工具 ------- ### [自動關閉標籤](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-close-tag) 當您在開始標記的右括號中鍵入內容時，它會自動新增 HTML/XML 結束標記。這種節省時間的功能減少了手動工作量並簡化了編碼，從而實現更快、更有效率的開發。  ### [自動重命名標籤](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag) 當我們重新命名一個標籤時，它會自動重新命名已配對的 HTML/XML 標籤。這個小但有用的功能可以節省時間，使編碼更有效率和愉快。  ### [CSS轉換器](https://marketplace.visualstudio.com/items?itemName=Lakkannawalikar.css-converter) 它將 HTML CSS 轉換為 JS CSS 以用於樣式化元件，反之亦然。 1. 選擇要轉換的 CSS 文本 2. 輸入`Shift + Command + V` (mac)、 `Shift + Ctrl + V` (windows/linux)  --- 測試和測試覆蓋率 -------- ### [是](https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest) 它可以幫助開發人員直接在編輯器中執行和除錯 Jest 測試。憑藉內嵌測試結果和直覺的導航，它簡化了 JavaScript 專案的測試工作流程。  ### [覆蓋範圍](https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters) 它有助於直接在程式碼編輯器中顯示 lcov 或 xml 報告產生的測試覆蓋率資料，並提供對程式碼覆蓋率的深入了解，幫助您評估測試套件的有效性。無需切換到另一個窗口，從而節省了時間。  --- 獎金 -- ### [瓦卡時間](https://marketplace.visualstudio.com/items?itemName=WakaTime.vscode-wakatime) 它會自動追蹤您跨不同程式語言的編碼時間，提供寶貴的見解來優化您的生產力。  ### 自動儲存 VS 程式碼設定 我發現一個有用的省時技巧是將“自動儲存 VS 程式碼”設定配置為 onFocusChange。這意味著每當我切換到不同的檔案或應用程式時，我的更改都會自動儲存。這樣就無需手動儲存檔案並避免遺失任何修改的風險。此外，對於行動或網頁應用程式，此設定允許我在切換到瀏覽器或模擬器時立即看到更新的更改，從而加快開發過程。  --- 最後的話 ---- 上述這些工具透過自動化任務和簡化工作流程顯著改善了開發體驗。它們透過在程式碼編輯器中提供程式碼格式化、錯誤偵測和版本控制整合等功能，為開發人員節省了大量的時間和精力。 --- 原文出處：https://dev.to/saloniagrawal/boost-productivity-quality-essential-vs-code-extensions-18oj
Supabase Storage 現已正式成為 S3 相容儲存提供者。這是最受歡迎的功能之一，現已在公共 alpha 版本中提供。可斷點續傳上傳也從測試版過渡到普遍可用。 https://supabase.com/ga-week ⚡️ 了解有關 GA 週的更多資訊 [Supabase 儲存引擎](https://github.com/supabase/storage)是完全開源的，是為數不多的提供 3 種可互通協定來管理檔案的儲存解決方案之一： - [標準上傳](https://supabase.com/docs/guides/storage/uploads/standard-uploads)：上手簡單 - [斷點續傳](https://supabase.com/docs/guides/storage/uploads/resumable-uploads)：適用於大容量斷點續傳 - [S3 上傳](https://supabase.com/docs/guides/storage/s3/compatibility)：相容於多種工具 https://youtu.be/WvvGhcNeSPk S3相容性 ----- 我們始終努力在 Supabase 採用業界標準。支援標準使工作負載可移植，這是一個[關鍵的產品原則](https://supabase.com/docs/guides/getting-started/architecture#everything-is-portable)。 S3 API 無疑是一種儲存標準，我們正在讓各種經驗水平的開發人員都可以使用它。 S3 協定向後相容我們的其他 API。如果您已經透過我們的 REST 或 TUS API 使用存儲，現在您可以使用任何 S3 用戶端與您的儲存桶和檔案進行互動：使用 TUS 上傳、使用 REST 提供服務以及使用 S3 協定管理它們。 該協議適用於雲端、本地開發和自託管。[在我們的文件中](https://supabase.com/docs/guides/storage/s3/compatibility)查看 API 相容性 使用 Supabase S3 進行身份驗證 --------------------- 要使用 Supabase S3 進行身份驗證，您有 2 個選項： 1-**標準**`access_key`**和**`secret_key`憑證。您可以從[儲存設定頁面](https://supabase.com/dashboard/project/_/settings/storage)產生這些。這種身份驗證方法與支援S3協定的工具廣泛相容。它也只能*在伺服器端*使用，因為它提供對儲存資源的完全存取。 我們將在不久的將來加入可以存取特定儲存桶的範圍存取金鑰憑證。 2-**使用 RLS 的使用者範圍憑證**。這利用了所有 Supabase 服務中廣泛採用的概念：[行級安全性](https://supabase.com/docs/guides/auth/auth-deep-dive/auth-row-level-security)。它允許您透過將儲存操作範圍限定到特定的經過身份驗證的使用者或角色來與 S3 協定進行交互，同時尊重您現有的 RLS 策略。此方法是透過使用 S3 協定支援的會話令牌標頭來實現的。您可以在[文件](https://supabase.com/docs/guides/storage/s3/authentication#session-token)中找到有關如何使用會話令牌機制的更多資訊。 S3 相容集成 ------- 在 S3 協定的支援下，您現在可以透過提供一對可以隨時撤銷的憑證將 Supabase Storage 連接到許多第三方工具和服務。 您可以使用流行的工具進行備份和遷移，例如： - [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/s3/) ：官方 AWS CLI - [rclone](https://rclone.org/) ：用於管理雲端儲存上的檔案的命令列程式。 - [Cyberduck](https://cyberduck.io/) ：適用於 Mac 和 Windows 的雲端儲存瀏覽器。 - 以及任何其他 s3 相容工具。  請[在此處](https://supabase.com/partners/integrations/cyberduck)查看我們的 Cyberduck 指南。 資料工程師的 S3 --------- S3 相容性為資料工程師提供了一個很好的原語。您可以將它與許多流行的工具一起使用： - ClickHouse 等資料倉儲 - 查詢引擎，如 DuckDB、Spark、Trino 和 Snowflake 外部表 - 資料載入器，例如 Fivetran 和 Airbyte 在此範例中，我們出色的資料分析師 Tyler 示範如何將 Parquet 檔案儲存在 Supabase Storage 中並使用 DuckDB 直接查詢它們： https://youtu.be/diL00ZZ-q50 S3 中的分段上傳 --------- 除了標準上傳和斷點續傳之外，我們現在還支援透過 S3 協定進行分段上傳。這使您可以透過並行上傳區塊來最大化上傳吞吐量，然後將區塊連接到最後。 斷點續傳已普遍可用 --------- 隨著[平台 GA 的發布](https://supabase.com/ga)，我們也很高興地宣布可斷點上傳也普遍可用。 可斷點上傳由[TUS 協定](https://tus.io/)提供支援。與啟迪團隊的密切合作，到達這裡的旅程非常有意義。大力讚揚 TUS 協議的維護者[@murderlon](https://github.com/Murderlon)和[@acconut](https://github.com/Acconut) ，感謝他們在開源方面的協作方式。 Supabase 貢獻了 TUS Spec 的 Node 實現的[一些高級功能，](https://github.com/tus/tus-node-server/pulls?q=is%3Apr+sort%3Aupdated-desc+author%3Afenos)包括[分散式鎖定](https://github.com/tus/tus-node-server/pull/514)、[最大檔案大小](https://github.com/tus/tus-node-server/pull/517)、[過期擴展](https://github.com/tus/tus-node-server/pull/513)和大量錯誤修復：  這些功能對於 Supabase 至關重要，並且由於[TUS 節點伺服器](https://github.com/tus/tus-node-server)是開源的，因此它們也可供您使用。這是另一個核心原則：只要有可能，[我們就會使用和支援現有工具，](https://supabase.com/docs/guides/getting-started/architecture#support-existing-tools)而不是從頭開始開發。 - **跨儲存桶傳輸**：我們新增了跨儲存桶複製和移動物件的功能，而以前您只能在同一個 Supabase 儲存桶中執行這些操作。 - **標準化錯誤程式碼**：錯誤程式碼現已在整個儲存伺服器上標準化，現在可以更輕鬆地針對特定錯誤進行邏輯分支。您可以[在此處](https://supabase.com/docs/guides/storage/debugging/error-codes)找到錯誤程式碼清單。 - **多租戶遷移**：我們對所有租戶中執行的遷移進行了重大改進。這減少了整個佇列的遷移錯誤，並使我們能夠以非同步方式執行長時間執行的遷移。請繼續關注包含更多詳細資訊的單獨部落格文章。 - **解耦依賴**：儲存與其他 Supabase 產品完全解耦，這意味著您可以將儲存作為獨立服務執行。開始使用這個[docker-compose 檔案](https://github.com/supabase/storage/blob/master/docker-compose.yml)。 入門 -- - [在我們的文件中](https://supabase.com/docs/guides/storage/s3/compatibility)查看 S3 API 相容性 - 了解[S3 身份驗證](https://supabase.com/docs/guides/storage/s3/authentication) - 嘗試使用 Cyberduck 進行 S3：遵循我們的[整合指南](https://supabase.com/partners/integrations/cyberduck) - 嘗試使用 DuckDB 進行 S3：按照[YouTube 上的](https://www.youtube.com/watch?v=diL00ZZ-q50)指南進行操作 **更多關於 GA 週的訊息** - [斯帕巴斯威夫特](https://supabase.com/blog/supabase-swift) - [AWS Marketplace 上的 Supabase](https://supabase.com/blog/supabase-aws-marketplace) - [Supabase 開源黑客馬拉松 2024](https://supabase.com/blog/supabase-oss-hackathon) - [Supabase引導程式](https://supabase.com/blog/supabase-bootstrap) - [分支現已公開](https://supabase.com/blog/branching-publicly-available) --- 原文出處：https://dev.to/supabase/supabase-storage-now-supports-the-s3-protocol-3479
我正式擁有三年經驗和中級職稱。自從兩年前我寫下了[我作為專業開發人員第一年學到的 12 件事](https://dev.to/abbeyperini/12-things-i-learned-during-my-first-year-as-a-professional-developer-i0f)以來，我的最佳建議已經發生了很大的變化。 1. 水平不重要，結果才重要 -------------- 如果你正在解決他們的問題，沒有人會問你已經開發了多久。不要僅僅因為某個主題被稱為高級而推遲學習您感興趣的主題。你永遠不知道你會被要求建造什麼，所以它可能會比你想像的更快派上用場。 2.不要死記硬背 --------  了解如何找到您需要的資訊。我不是說 StackOverflow 和 GenAI。對於您使用的工具和語言，請了解規範或文件所在的位置。找出誰寫了最好的指南。 如果您不記得了，也沒關係`?`當您要使用 JavaScript 條件運算子時，or `:`首先出現。重要的是您知道何時使用條件運算符以及在哪裡可以找到確切的語法。 工具不斷更新。請務必檢查您正在閱讀的文件的版本。找到一種方式來了解最新情況，無論是新聞通訊還是真正喜歡 CSS 的朋友。 3. 深入基礎知識 --------- 聽聽在 3 年內使用過 3 個 JavaScript 框架的人的話——如果你很好地了解基礎知識，那麼在生態系統中學習新工具就會容易得多。您最終可能會編寫出更簡單、更強大的軟體。您不會嘗試編寫已經存在的功能，因為您不知道它們存在。您將更了解所遇到的錯誤，並在導致錯誤之前預見錯誤。 4.系統思考會讓你走得更遠 ------------- 解決任何錯誤都需要係統思考。如果您不考慮牆上的插頭，當烤麵包機無法打開時您就不會想到檢查它。能夠將系統作為一個整體來思考，可以更輕鬆地預測邊緣情況並設計新功能。在[新程式碼庫入門中](https://dev.to/abbeyperini/getting-started-in-a-new-codebase-e7b#6-mental-models)閱讀有關如何為程式碼庫建立心理模型的更多訊息 5.先嘗試再問，確保問題永遠不會是個愚蠢的問題 ----------------------- 開發人員通常以解決問題為導向。如果你能證明你嘗試了一些方法但沒有奏效，那麼他們可能會想深入挖掘自己，找出為什麼明顯的解決方案不起作用。 6.每一行程式碼都是一種責任 --------------  編寫程式碼就像其他人必須修復它一樣。 （即使 6 個月後那個人就是你。）安裝軟體包，就像你必須經常更新它們一樣。記錄原因，這樣以後就不會意外破壞某些東西。在將某個固執己見的工具整合到您的系統之前，先了解它的意見，並找出它的意見與您所需的功能相衝突。 7.練習閱讀別人的程式碼 ------------ 通常教授軟體開發的方式可能會讓您相信您經常會建立新鮮的、全新的應用程式。您更有可能修復現有程式碼庫並為其加入功能。您甚至可能花更多的時間閱讀程式碼而不是編寫程式碼。練習閱讀程式碼和重構程式碼而不引入新的錯誤。 8. 測試、測試、再測試 ------------ 正如[Chocho](https://www.linkedin.com/in/enriquezamudiolopez)在 DevNexus 2024 演講中所說，“程式碼就是理論。軟體就是實踐。”在請求審查之前，請始終執行您的程式碼並對其進行測試。盡可能多練習編寫測驗。您會發現，預測使用者如何破壞您的程式碼並考慮更多的事情，而不只是快樂的道路，將使您成為更好的開發人員。 9. 練習將需求轉化為軟體 ------------- 票#387 - 在頁面上新增一個按鈕，用於開啟模式並允許使用者編輯此資料。 預計您可以將這樣的需求轉換為步驟清單或偽程式碼。如果票證太模糊，您就有責任獲得所需的答案。 解決這些步驟後，您將需要將它們轉換為程式碼並（希望）對該程式碼進行測試。然後，您將負責透過公司的版本控制、（希望）審查、（希望）品質保證和部署流程來取得該程式碼。 開源是實踐這一點的好地方。 10. 社區極為重要 ---------- 你不會在社群媒體貼文中獲得最細緻、最公正的觀點。當您需要這種觀點時，您需要一個支持網絡來打電話。 指導是其中的一部分。參加當地的聚會和會議是建立人際網絡和擴展發展世界觀的好方法。加入網路小組將使您能夠了解資深開發人員的觀點。 不要試圖獨自完成這項工作。那裡有很多訊息，很容易讓人不知所措或視野狹隘。 11.找到你喜歡程式設計的地方 ---------------  我並不是說熱愛你的工作或成為難以捉摸的熱情程式設計師。然而，不斷的學習會讓你自己陷入反覆的不適。如果你不知道為什麼要繼續醒來並對自己做這些事，你就會精疲力盡。這完全可能是個自私的原因，但你必須知道為什麼。 12.每個人都在自己的旅程上 -------------- 您不會與他人的職業和內容競爭。別人的成功之路可能根本不適合你。專注於您獨特的視角和優勢。尋找並分享您的聲音。外面有人想聽聽看。 結論 -- 查看我（或其他任何人）的個人資料可能會讓您相信我通往中級開發人員的道路是筆直而順利的。事實恰恰相反。我跌倒過，哭過，刺破過，精疲力竭過，還被困過很多兔子洞。 因此，我必須衷心感謝我的丈夫、家人、朋友和科技社群幫助我站穩腳步。我還必須感謝許多同事給予我發揮潛能的機會。沒有你們，我不可能走到這一步。我很感激我有這樣的經驗。 --- 原文出處：https://dev.to/abbeyperini/12-tips-from-a-mid-level-developer-29bk
**現在是 2024 年，您又建立了另一個 JavaScript 框架。說真的，夥計！** 當您談論另一個 Javascript 框架時，您可能會笑並認為有大量經過驗證的選項，為什麼還要建立另一個框架？ 🤷♂️ 讓我與您分享我的個人故事，它導致了新的 Javascript 框架的發展。但如果你不關心我的可悲的故事，這裡是 TLDR： > **TiniJS**是一個元框架，由基於 Google [Lit](https://lit.dev/)庫的**Web 元件**技術提供支援。 > 您可以先下載[入門範本](https://github.com/tinijs/bare-starter)或使用 CLI 初始化應用程式，執行`npx @tinijs/cli@latest new my-app`並按照說明進行操作。 > 有關更多詳細訊息，請參閱下面的**“入門”**部分或存取<https://tinijs.dev/> 。 故事 --  開個玩笑吧，我不是 Javascript 的專家，但我想稍微介紹一下我的背景，這樣您可能就會知道我關於前端 Web 開發的煩惱故事。我曾經是 Angular 1 版本的開發人員，目前主要使用 Vue，偶爾使用 jQuery。我有這**3 個 PITA** （Pain In The \*beep\*）經歷，這促使我嘗試使用 TiniJS 框架。 > **PITA #1 - 建立良好的 UI/UX 很困難，既乏味又耗時！** 早在 2010 年左右，就有兩種不同類型的網站：一種有大量文本、連結，幾乎沒有一些圖片；另一種有大量文本、連結，幾乎沒有一些圖片。其他的則包含大量的圖形元素，例如 GIF 圖像、Flash 背景、彩虹遊標… 人們往往有**後端難前端容易的**刻板印象。這有點正確，但不完全正確，我的意思是，我該怪誰，對吧？因為只要有一點 HTML 和 CSS 知識，您就可以非常輕鬆地建立靜態網站。但是，為了建立良好的 UI/UX，還有很多事情需要考慮。你必須成為更多事情的大師，而它們一點也不容易！  > **PITA #2 - CSS 框架缺乏功能並且自訂它們不是很有效！** 人們意識到前端開發的困難，開始建立CSS框架來幫助解決這個問題。 Bootstrap是這一趨勢的先驅之一，其他流行的有：Foundation、Semantic UI、Bulma、Skeleton、Pure CSS…這些CSS框架很棒，毫無疑問，它們幫助我們建立一個好的UI/使用者體驗更快，但它們也有自己的限制。 首先，儘管所有框架都提供了一定的方式來定制樣式，但總的來說，我覺得這對我來說不是很容易和可重用。  二是功能缺失。我的意思是，它們主要是 CSS，它們提供一些功能，通常是作為 JQuery 的插件。大多數情況下，您必須編寫自己的 Javascript 才能使功能正常運作。 > **PITA #3 - JavaScript 框架勢不可擋，而且有點多餘！** 進入現代 Web 開發時代，Javascript 框架已成為新趨勢。但問題是我們有太多的選擇，這既是福也是禍。它們提供了很棒的功能，但互通性不太好，您不能只從一個框架中取出一段程式碼並在另一個框架中使用它。特別是，為特定框架建立一個具有單獨套件的 UI 系統是一項非常艱鉅的任務。  每次我開始一個專案或做某種前端工作時，前端web的碎片化對我來說都有些痛苦。這似乎就是生活方式，無可避免，不是嗎？請不要誤會我的意思，我並不反對任何框架，我傾向於選擇解決方案而不是技術，所以如果它適合你，就用它吧。但我想知道有什麼辦法可以以某種方式統一或縮小前端開發經驗的差距嗎？ 🤔 介紹 TiniJS --------- 這就是我嘗試**TiniJS 框架**一段時間的原因。它是基於[Lit](https://lit.dev/)庫、使用本機**Web 元件**技術開發 Web/桌面/行動應用程式的工具集合。感謝[Lit](https://lit.dev/)團隊建立了一個出色的工具，幫助我們更輕鬆地使用標準 Web 元件。 它的目標是盡可能**標準化、小型化和多功能化**。與其他框架和元框架沒有真正的可比性，但總體而言，它具有相似的功能，但另一方面也有關鍵的區別。它既是替代選擇，也是對其他框架的補充。您可以使用 TiniJS 建立各種類型的應用程式：**登陸頁面、SPA、PWA、桌面應用程式、行動應用程式**…就功能而言，任何在 Javascript 中工作的內容都應該在 TiniJS 應用程式中正常運作。 整個系統由幾個部分組成，這是一個快速介紹。 > 請注意，**並非所有部件現在都可用**，該專案還處於早期階段，有些是**之前的實驗**，我盡力盡快將它們投入使用。但我的時間和資源有限，所以請耐心等待，如果可能的話請幫助我。 🙇♂️ > V1 的計畫及其路線圖可在<https://github.com/tinijs/tinijs>找到 ### 核 **TiniJS 的**核心提供了傳統的專案結構和簡化的開發流程。有**用於組織內容的資料夾**，**用於開發的本機伺服器**，在分發時，您可以選擇 Vite 或 Parcel 或 Webpack 來**建立產品**。 核心還包括：用於在頁面之間導航的**路由器**、用於全域狀態管理的簡單**儲存**、支援**PWA** ，... 您可以嘗試[Try TiniJS 中的範例專案（範例照片庫應用程式）](https://stackblitz.com/edit/try-tinijs?file=app%2Fapp.ts) ### 使用者介面系統 TiniJS 有一個專用的**UI 庫，我的目標是提供每個常用的元件和區塊甚至整個頁面**。元件以特殊的方式建置，它們是自訂元素，不僅可以與 TiniJS 一起使用，還可以與其他框架或不使用框架一起使用。  使用可重複使用元件很容易，通常是以將 props 傳遞給自訂元素標籤的形式。自訂可以透過 props 或 CSS `::part()`或自訂主題系列或完全克隆元件來源來完成，... 元件還能夠以盡可能小的努力適應幾乎所有設計系統。這是透過主題系統實現的，概念是這樣的： - 元件**只寫一次**，它們是**無頭的**（沒有特定的樣式） - 主題被組織成**系列**（又稱設計系統），系列定義自己的基本特徵，例如：Bootstrap、Material、Fluent、Spectrum，... - 根據基本特徵，一個系列有風格變體，稱為**“皮膚”** ，例如，Bootstrap 系列可能有：淺色皮膚、深色皮膚… 考慮到主題概念，任何應用程式都可以具有以下主題功能： - **一個**主題系列 - 可能是當今存在的所有網路應用程式中的 80% 到 90%，只有 1 種特定風格相當於 TiniJS 1 主題系列。 - **一個**主題系列 + 多個皮膚 - 常見的用例是亮/暗模式，相當於 TiniJS 1 主題系列，具有來自同一系列的多個皮膚。 - **多個**主題系列 - 高度個人化的應用程式可能有多個主題系列，每個系列都有一個或多個皮膚，將根據使用者參考應用某個主題。 UI 使用詳細資訊將在[主頁](https://tinijs.dev/ui)上提供，現在您也可以在<https://ui.tinijs.dev/>查看實驗概念，以查看該概念的實際應用。 ### 網頁、PWA、混合桌面/行動設備 預設的 TiniJS 應用程式是**單頁應用程式**，它小而快速，可以直接部署為 Web 應用程式。但是，您也可以將 TiniJS 轉換為以下一種或所有類型的應用程式： - **漸進式 Web 應用程式**(PWA) - 使用單一 CLI 命令實作（即將推出） - 混合**桌面/行動**應用程式 - 使用 Tauri 2.0 或類似工具（todo：編寫指令） ### 靜態和伺服器 TiniJS 應用程式可以作為靜態網路啟動，無論大小，無需伺服器或資料庫。您始終可以使用 SaaS 服務來滿足幾乎任何後端需求。我還在開發`@tinijs/content` - 一個基於文件的內容管理系統，用於輕鬆管理多種類型的內容。靜態站點產生（SSG）或預渲染也在計劃中。 如果您需要處理後端任務並參考從 Node 伺服器而不是靜態主機為 Web 應用程式提供服務，則可選的 Nitro 伺服器用於**伺服器/API 路由**和其他**伺服器內容**。我的開發能力有限，因此第一個版本可能不支援伺服器端渲染（SSR），相反，我計劃使用半SSR，其中伺服器將為用戶提供單頁服務，並向機器人提供最少的伺服器端渲染內容。 ### 功能和模組 在功能方面，由於 TiniJS 應用程式**基於標準 Web 技術**，因此在瀏覽器中工作的任何程式庫和功能都可能在 TiniJS 應用程式中運作。因此，與其他框架相比，您可能**不必擔心功能**。您甚至可以在 TiniJS 應用程式中使用其他框架，例如初始化 Vue 應用程式並將其安裝到 TiniJS 頁面內的元素。 還有一個模組架構師，以便某些模組可以進入 TiniJS 應用程式的工作流程，建立更簡化的開發管道。 ### 工具 官方 CLI 工具提供了一些使用 TiniJS 應用程式的便利命令。 - `dev` - 啟動本機開發伺服器 - `build` - 建構生產分配 - `preview` - 在部署之前預覽生產版本 - `generate` - 生成元件、頁面、實用程式... 此外，CLI**足夠通用，可以在 TiniJS 應用程式以外的任何類型的專案中使用**。它具有可擴展的架構，您可以在其中擴展更多命令以用於其他自動化任務。一些官方擴展，例如`ui`命令（來自`@tinijs/ui` ）用於處理 UI 任務或`content`命令（來自`@tinijs/content` ）用於處理內容相關任務，...您可以根據自己的目的建立 CLI 擴展包私人或共享。 好了，說得夠多了，讓我看看一些行動吧！ 👌 開始使用 ---- **Tini** （越南語中的“ [Tí nị](https://translate.google.com/?sl=vi&tl=en&text=t%C3%AD%20n%E1%BB%8B&op=translate) ”，意思是非常小、可愛的東西）。 為了快速建立**TiniJS**專案，您可以使用[CLI](https://tinijs.dev/cli)來初始化模板。 ``` npx @tinijs/cli@latest new my-app ``` 上面的命令透過下載**Bare**模板來建立一個應用程式。將來，我想提供幾個入門範本。您還可以建立自己的模板並與社區共享或供您自己私人使用。目前，這些模板可用： - [Bare](https://github.com/tinijs/bare-starter) （預設）- TiniJS 應用程式的最小結構。 - [空白](https://github.com/tinijs/blank-starter)（標誌`-t blank` ）- 包含路由器、狀態管理、元標記管理和[Bootstrap 主題系列](https://tinijs.dev/ui)。 現在，在專案內部，您可以執行`npm run dev`來啟動開發伺服器。您可以透過編輯檔案`./app/app.ts`來開始開發，該檔案是應用程式的根元件。有關如何使用 Lit 處理自訂元素，請存取[Lit 元件](https://lit.dev/docs/components/overview/)， `LitElement`和`TiniComponent`之間存在一些差異，但現在您可以像平常一樣修改`static styles`和`render()` 。 若要建立發行版，請執行`npm run build`並可選擇執行`npm run preview`以預覽生產版本。現在您可以將`.output`資料夾部署到任何靜態主機。 您可能需要查看這些範例以了解 TiniJS 應用程式如何運作的更多細節。 - 首頁 - <https://github.com/tinijs/tinijs/tree/main/apps/tinijs.dev> - 待辦事項應用程式 - <https://github.com/tinijs/tinijs/tree/main/examples/todo> 這就是**TiniJS 框架**的基本介紹。下次我們將探索**TiniJS 應用程式的結構並使用元件**。 欲了解更多訊息，請存取： <https://tinijs.dev> 謝謝您，編碼愉快！ 💖 --- 原文出處：https://dev.to/lamnhan/ive-created-yet-another-javascript-framework-5c5o
上週我發現了一些很棒的圖書館！ 檢查它們、使用它們、幫助它們加星⭐️ > 「我永遠不會停止學習。 我不會只做分配給我的事情。 我知道不存在所謂的現狀。 我將透過充滿熱情和忠誠的客戶來永續地發展我們的業務。 我永遠不會放棄幫助同事的機會，我會記得我知道一切之前的日子。 影響力比金錢更能激勵我，而且我知道**開源是我們這一代最強大的想法之一**。 我會盡可能多溝通，因為這是分散式公司的氧氣。我參加的是一場馬拉松，而不是短跑，無論目標有多遠，到達目標的唯一方法就是每天把一隻腳放在另一隻腳前面。只要有時間，沒有什麼問題是解決不了的。 馬特·穆倫韋格 Automattic 首席執行官   --- Coolify -- 隆重介紹 Coolify，它是[Heroku](https://www.heroku.com/) 、 [Netlify](https://www.netlify.com/)和[Vercel](https://vercel.com/)的開源和自架替代品 這個創新平台由[Andras Bacsai](https://twitter.com/heyandras)開發，使用戶能夠輕鬆部署和管理其 Web 應用程式，同時保持對其基礎設施的完全控制。  ### 主要特徵： - **自託管**：借助 Coolify，您可以自由地將 Web 應用程式託管在自己的伺服器上，從而完全控制您的部署環境。 - **輕鬆部署**：該平台簡化了部署過程，讓您只需單擊幾下或命令即可部署應用程式。 - **可擴展性**：Coolify 旨在輕鬆擴展，在不影響效能的情況下滿足不斷增長的流量和工作負載需求。 - **客製化**：您可以自訂和配置部署環境以滿足您的特定要求，確保最佳效能和安全性。 - **整合**：Coolify 與流行的開發工具和工作流程無縫集成，使其可以輕鬆合併到您現有的專案中。 - **社區支持**：受益於充滿活力的開發者和貢獻者社區，他們提供支援、共享資源並協作改進平台。  在 GitHub 上查看 Coolify 並給它一顆星： [Coolify Repository](https://github.com/coollabsio/coolify) --- Glasskube ----- [Glasskube](https://glasskube.dev/)是一個開源 Kubernetes 套件管理器，可簡化 Kubernetes 部署的套件管理。它提供了一個用戶友好的介面，降低了管理您最喜歡的 Kubernetes 套件的複雜性並提高了透明度。  ### 主要特徵： - **使用者友善的 UI** ：Glasskube 提供直覺的使用者介面，使 Kubernetes 套件管理對於使用者來說更容易存取和理解。 - **Brew-Inspired CLI** ：對於熟悉命令列介面的高級用戶，Glasskube 提供了 Brew-inspired CLI，允許高效的套件管理操作。 - **依賴感知**：Glasskube 套件具有依賴關係感知能力，確保 Kubernetes 套件的順利管理和安裝並考慮依賴關係。 - **雲端原生應用程式**：Glasskube 設計為雲端原生應用程式，符合 GitOps 原則，有助於無縫整合到 Kubernetes 環境和工作流程中。 Glasskube 作為簡化 Kubernetes 套件管理的寶貴工具而脫穎而出。無論您是 Kubernetes 新手還是經驗豐富的 DevOps 工程師，Glasskube 都能提供使用者友善的解決方案，幫助您輕鬆有效地管理 Kubernetes 套件。 [看看 GitHub 上的 Glasskube 並給它一顆星](https://github.com/glasskube/glasskube) --- AgentCloud --- [AgentCloud](https://www.agentcloud.dev)是您建立自己的 AI 應用程式遊樂場的首選平台！想像一下，它就像擁有您自己的個人 GPT（生成式預訓練變壓器）建構器平台，但具有一些很棒的額外功能。  借助 Agent Cloud，公司可以靈活地為其員工建立和部署兩種不同類型的應用程式： 1. **對話式聊天應用程式**：這些應用程式的運作方式與 OpenAI 的 GPT 類似，允許使用者開發單代理聊天應用程式。然而，它們還具有利用任何大型語言模型 (LLM)、存取豐富的工具庫以及利用來自眾多資料來源的龐大知識庫的額外優勢。 2. **流程應用程式**：向自動化天堂問好！這些應用程式透過為代理設定要處理的目標和任務來幫助您簡化流程。這一切都是為了讓工作變得更輕鬆、更快捷、更有協作性。 因此，無論您是希望透過漂亮的聊天機器人來提高工作效率，還是像專業人士一樣自動執行任務，Agent Cloud 都能滿足您的需求。這一切都是為了為您的團隊提供他們需要的工具，讓他們更聰明地工作，而不是更辛苦地工作！ 最好的部分是什麼？它是開源的！如果您喜歡使用 Agent Cloud，為什麼不在 GitHub 上表達一些喜愛並給它一顆星呢？您的支持對開源社群來說意味著世界。 🌟 看看 GitHub 上的 Agent Cloud 並給它一顆星： [Agent Cloud Repository](https://github.com/rnadigital/agentcloud)  我還發現了一個很酷的演示，可以讓您先睹為快了解 Agent Cloud 的全部內容。請觀看此處的介紹影片，以及創始人本人在 YouTube 上對[RAG Google Bigquery](https://youtu.be/POLdnrjsy9c?si=y5MFXNSs-o5TJMMH)的一些精彩見解。  --- CrewAI ------ [CrewAI](https://www.crewai.com/)是一個突破性的框架，旨在協調角色扮演和自主人工智慧代理。這個開源專案由 João Moura 開發，使代理商能夠智慧協作，使他們能夠無縫地協作完成複雜的任務。  ### 主要特徵： - **協作智能**：CrewAI 促進人工智慧代理之間的協作智能，使他們能夠匯集資源和專業知識，更有效地完成任務。 - **自主代理**：此框架支援自主人工智慧代理的開發，能夠根據其環境和目標做出獨立決策並採取行動。 - **任務編排**：CrewAI 提供用於編排任務和協調多個代理程式的操作的工具，確保順暢的協作和同步。 - **可擴展性**：借助 CrewAI，開發人員可以擴展其 AI 系統以容納大量代理，使其適用於從小規模模擬到大規模環境的應用程式。 - **靈活性**：該框架在設計代理行為和互動方面提供了靈活性，允許開發人員自訂系統以適應特定的用例和場景。 - **社群支援**：CrewAI 受益於充滿活力的開發人員和研究人員社區，促進自主代理和人工智慧領域的協作和創新。 在 GitHub 上查看 CrewAI 並給它一顆星： [CrewAI Repository](https://github.com/joaomdmoura/crewAI) > 了解[Agent Cloud 和 CrewAI](https://www.agentcloud.dev/blog/agent-cloud-vs-crewai-a-comparison)之間的差異。 --- SuperAGI ----- [SuperAGI](https://superagi.com/)是一個尖端平台，旨在突破對話式 AI 的界限，整合通用人工智慧 (AGI) 原理，建立高度智慧且適應性強的聊天機器人。  ### 主要特徵： - **通用人工智慧（AGI）** ：SuperAGI 利用 AGI 原理開發具有類人理解和推理能力的聊天機器人。 - **深度學習模型**：該平台利用最先進的深度學習模型（例如變壓器和神經網路）來處理和產生自然語言響應。 - **知識圖**：SuperAGI 結合知識圖來表示和組織訊息，使聊天機器人能夠存取龐大的結構化知識儲存庫。 - **元學習**：SuperAGI 採用元學習技術，使聊天機器人能夠根據過去的互動和回饋不斷改進和調整其行為。 - **多輪對話**：SuperAGI 支援多輪對話，允許聊天機器人維護上下文並與用戶進行更自然、更流暢的互動。 - **可擴展性**：該平台具有高度可擴展性，使開發人員能夠整合自訂模組並根據需要擴展聊天機器人功能。 在 GitHub 上探索 SuperAGI： [SuperAGI 儲存庫](https://github.com/TransformerOptimus/SuperAGI) --- Gitroom ---- [Gitroom](https://gitroom.com/)提供工具並協助您擴展開源儲存庫。獲得更多知名度、明星、貢獻和客戶。  ### 主要特徵： - **統一協作**：Gitroom 將團隊協作直接引入到您的 Git 儲存庫中，從而實現無縫溝通和協調。 - **即時更新**：隨時了解儲存庫活動的即時更新，讓團隊能夠輕鬆追蹤變更和進度。 - **互動式討論**：直接在 Git 儲存庫中參與互動式討論，從而輕鬆分享想法並提供回饋。 - **任務管理**：使用內建任務管理功能追蹤任務和問題，簡化專案工作流程並提高生產力。 - **整合**：Gitroom 與 GitHub 順利集成，為已經習慣該平台的使用者提供熟悉且直覺的介面。 - **客製化**：透過可自訂的設定和首選項自訂 Gitroom，以滿足您團隊的特定需求。 在 GitHub 上探索 Gitroom：[Gitroom 儲存庫](https://github.com/gitroomhq/gitroom) 總之，這些儲存庫 - AgentCloud、Gitroom、Glasskube CrewAI、Coolify 和 SuperAGI - 都包含用於建立更聰明應用程式的令人驚嘆的工具。無論您喜歡聊天機器人、人工智慧代理還是 Web 部署，每個人都能找到適合自己的東西。 如果您喜歡所看到的內容，請在 GitHub 上給他們一顆星 ⭐️，為什麼不使用他們的工具來創造一些很棒的東西呢？ 很快會在另一篇部落格文章中見到您。  感謝您閱讀，如果您喜歡這個部落格並且想更深入地了解開發人員工具、React 等，請查看我[網站](https://theankurtyagi.com/)上的其他文章。 - [如何使用 React 和 Appwrite 建立安全的任務管理應用程式](https://theankurtyagi.com/appwrite/) - [如何使用 Hygraph 和 React 建立評論應用程式](https://theankurtyagi.com/build-review-app-hygraph-react/) - [如何使用 React 和 Supabase 建立全端 Notes 應用程式](https://theankurtyagi.com/notes-app-react-supabase/) --- 原文出處：https://dev.to/tyaga001/6-open-source-libraries-you-must-know-in-2024-5dgb
Supabase `bootstrap`是從現有入門範本啟動新託管 Supabase 專案最快的方式： `npx supabase bootstrap` 這為 Supabase 帶來了類似「shadcn」的體驗，在本地建立專案並啟動準備部署的遠端資料庫。 https://supabase.com/ga-week ⚡️ 了解有關 GA 週的更多資訊 入門 -- 從任何本機目錄執行`supabase bootstrap` ，系統將提示您選擇啟動範本。最棒的是，您甚至不需要安裝 CLI 即可開始！只要安裝了`npm`或`bun` ，就可以開始了！ - CLI： `supabase bootstrap` - NPM： `npx supabase@latest bootstrap` - 髮髻： `bunx supabase@latest bootstrap`  模板如何運作 ------ 入門範本清單在 GitHub 上發佈為[Samples.json](https://github.com/supabase-community/supabase-samples/blob/main/samples.json) 。每當我們（以及未來的社區）加入新的啟動器時，它將自動對所有 Supabase 用戶可用。 範本儲存庫通常包含完整的前端程式碼，檔案結構如下： - 包含`config.toml`和`migrations`檔案（如果有）的`supabase`目錄。 - `.env.example file` ，定義 CLI 的環境變數清單以填入專案憑證。我們目前支援與[Vercel 整合](https://vercel.com/integrations/supabase)相同的憑證清單。如果`.env`檔案不存在，CLI 將為您建立它。 當地發展 ---- 選擇啟動器後，Supabase CLI 會將所有檔案從範本儲存庫下載到您選擇的本機目錄。 > **GitHub 速率限制** 從範本儲存庫下載過於頻繁時，您可能會遇到 GitHub 速率限制。可以透過在本地將 GITHUB\_TOKEN 環境變數設定為 GitHub 個人存取權杖來避免這種情況。 該模型與流行的[shadcn](https://ui.shadcn.com/)工作流程非常相似。在本機儲存庫中建立檔案後，您可以修改它們並將它們簽入原始碼管理。 部署到生產環境 ------- 在`supabase bootstrap`過程中，將在 Supabase 平台上建立一個新專案並連結到您的本機環境。如果您還沒有帳戶建立流程，此命令將引導您完成帳戶建立流程。  > **需要一些耐心** 連結到新的託管專案可能需要一段時間，因為它需要在雲端啟動新的資料庫。 連結完成後，系統將提示您將所有範本遷移檔案推送到新託管的專案。這些遷移檔案將使用必要的模式設定您的遠端資料庫以支援入門應用程式。  推送遷移後，您的專案憑證將匯出到`.env`文件，以便您從任何前端或後端程式碼進行連線。預設環境變數包括： - `POSTGRES_URL` - `SUPABASE_URL` - `SUPABASE_ANON_KEY` - `SUPABASE_SERVICE_ROLE_KEY` 由您選擇的範本定義的`.env.example`檔案中的其他自訂變數也將合併到您的本機`.env`檔案中。 > **安全地儲存憑證** 安全地儲存這些憑證非常重要，因為任何人都可以使用`POSTGRES_URL`連接到您的遠端資料庫。 開始開發 ---- 最後，CLI 將建議一個`start`命令來在本地啟動您的應用程式。啟動本機應用程式將使用`.env`檔案中定義的憑證連接到新的託管專案。  範本庫 --- 就是這樣，只需一個命令，您就可以啟動一個新專案並端到端執行。 Supabase Bootstrap 讓您更輕鬆地開始使用 Supabase、行動應用程式工具和 Web 開發框架（例如 Next.js、Expo React Native、Flutter、Swift iOS）。 我們即將推出更多模板，並將開放給社區貢獻。敬請關注！ 開始使用 ---- 請造訪[Supabase CLI 文件](https://supabase.com/docs/guides/cli/getting-started)以開始使用`supabase bootstrap` 。 **更多關於 GA 週的訊息** - [斯帕巴斯威夫特](https://supabase.com/blog/supabase-swift) - [AWS Marketplace 上的 Supabase](https://supabase.com/blog/supabase-aws-marketplace) - [Supabase 開源黑客馬拉松 2024](https://supabase.com/blog/supabase-oss-hackathon) - [Oriole 加入 Supabase](https://supabase.com/blog/supabase-aquires-oriole) - [分支現已公開](https://supabase.com/blog/branching-publicly-available) --- 原文出處：https://dev.to/supabase/supabase-bootstrap-the-fastest-way-to-launch-a-new-project-56hf
CSS 知道幾種測量單位。最著名的單位是像素，但還有其他單位雖然不那麼流行，但在某些用例中非常方便。 本文涵蓋相對單位、絕對單位和視口單位。 |媒體|建議|偶爾使用|不經常使用|不建議| |-----|------------|--------------|--------------- -|- --------------| |畫面|em、rem、%|px|ch、ex、vw、vh、vmin、vmax|cm、mm、in、pt、pc| |印出|em、rem、%|cm、mm、in、pt、pc|ch、ex|px、vw、vh、vmin、vmax| 相對單位 ---- 與像素、點或公分等絕對單位相反，您也可以使用百分比、em 或 rem 等相對單位來定義尺寸。 相關單位也[符合無障礙標準](https://www.w3.org/WAI/WCAG21/Techniques/css/C28.html)。 在大多數瀏覽器中，預設字體大小為`16px` ，您可以使用該值作為計算的基礎（例如 16px 等於 1em、1rem 或 100%）。 |單位|描述| |----|------------| |%|百分比| |em|元素的字體大小（例如2.5em表示字體比普通字體大2.5倍）| |rem|文件根元素的字型大小| |ch|「0」字元的寬度，在等寬字體中，所有字元具有相同的寬度，1ch 等於 1 個字元| |ex|x-目前字體的高度，以小寫x|的高度測量 https://codepen.io/fullstack-to/pen/PrXNGW ### em 和 rem 有什麼差別？ 差別就在於傳承。 `rem`值基於根元素 ( `html` )。每個子元素都使用`html`字體大小作為計算基礎。 另一方面， `em`是基於父元素的字體大小。 `rem`讓字體大小的計算變得更容易。對於嵌套元素甚至多個嵌套元素（例如列表），不再需要根據父元素的字體大小來計算字體大小。 `rem`總是計算與`html`標籤相關的字體大小。 ### 不同的字體系列  所有字體都具有相同的大小 (18pt)，但紅色條表示字體的 x 高度 ( `ex` ) 不同。  字體再次具有相同的大小（18pt）。在此圖中，比較了字元寬度 ( `ch` )。 Mono space 字體的每個字元具有相同的寬度，而 serif 或 sans-serif 字體的每個字元可能具有不同的寬度（ `i`比`o`窄）。 絕對單位 ---- 絕對單位的大小是固定的，你不能討論公分有多長。如果需要精確長度，則應使用絕對單位（例如不應調整大小的元件）。如果您想要定義限制以避免區域變得太寬或太窄，它們也很有用。絕對單位不會根據螢幕尺寸、方向或其他變化而改變。 |單位|描述|| |----|------------|----| |公分|公分|1 公分 = 1 公分| |毫米|毫米|10 毫米 = 1 公分| |英吋|英吋|1 英吋 = 96 像素 = 2.54 公分| |px|像素|1 px = 1 英吋的 1/96| |pt|點|1 pt = 1 in| 的 1/72 |pc|異食癖|1pc = 12 分| https://codepen.io/fullstack\_to/pen/mZaVBZ 視窗單位 ---- 視口單位表示目前瀏覽器視窗的百分比。 與百分比單位的差異在於，視口單位始終以瀏覽器視窗大小的百分比計算。而百分比單位繼承其父元素的大小。 |單位|描述| |----|------------| |vw|視窗寬度的 1%（50% 表示視窗寬度的一半）| |vh|視窗高度的 1%（50% 表示視口高度的一半）| |vmin|視窗較小（vw 或 vh）尺寸的 1%| |vmax|視窗較大（vw 或 vh）尺寸的 1%| https://codepen.io/fullstack-to/pen/gNZryX 當瀏覽器視窗大小調整或手機方向改變時， `vmin`和`vmax`可能會改變。 `vmin`是視口高度或寬度之間的最小值（以百分比表示），取決於哪個較小。 `vmax`是視口高度或寬度之間的最大值（以百分比表示），取決於哪一個較大。 --- 如果您喜歡我的內容，您可能想在 Twitter 上關注我？ [@fullstack\_to](https://twitter.com/fullstack_to) 封面圖片由[William Warby](https://unsplash.com/@wwarby?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)在[Unsplash](https://unsplash.com/search/photos/measurement?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)上提供 --- 原文出處：https://dev.to/matthias/units-in-css-em-rem-pt-px-vw-vh-vmin-vmax-ex-ch-53l0
是的，我要寫一下我們目錄中可能最被忽略的檔案**package-lock.json** ！ package-lock.json 是一個極其重要的文件，它可以幫助您避免在儲存庫中出現大量的**「boom pop bam bam 🔥」** 。 因此，在討論 package-lock.json 之前，我們先討論語意版本控制和 package.json。 **1.** 語意版本控制 ============ 語意版本控製或 SemVer 是對套件進行版本控制的理想方式。它們通常寫成`1.4.5` (major.minor.patch)  *1a.*錯誤修復/補丁版本 -------------- 包括錯誤修復/文件拼字錯誤等。 *1b.*次要版本 --------- 包括新增的功能或 API，不會破壞舊版本的任何內容，因此在 v1.1.0 上執行的任何內容也應該在 v1.9.0 上執行。 *1c.*主要版本 --------- 包括破壞東西的版本。它可以包括刪除 API 或更改函數名稱，因此適用於 v1.0.0 的任何內容可能不一定適用於 v2.0.0 **2.** package.json ============ package.json 是一個文件，其中包含有關您的專案的資訊（名稱、版本等），並列出了您的專案所依賴的套件。  正如您在上圖中看到的，在 package.json 下列出的每個依賴項之後都有一個類似`^2.20.0`的數字，它是該包的版本，但在版本之前有`^` 。所以^這個小傢伙可以成為你專案的徹底破壞者。 版本之前的 ^ 符號告訴 npm，如果有人克隆該專案並在目錄中執行 npm install，則在他的 node\_modules 中安裝該套件的最新次要版本。 假設我在 package.json 中使用了`^2.20.0`的 Express，然後 Express 團隊發布了版本 2.24.0，現在當有人克隆我的存儲庫並在該目錄中執行`npm install`時，他們將獲得版本2.24. 0（您可以也把`~`代替`^`它將更新到最新的補丁版本） 但是，如果套件開發人員破壞了次要版本上的任何功能，這可能是一個大問題，因為它可能會使您的應用程式崩潰。 所以npm後來發布了一個名為package-lock.json的新檔案來避免這種情況 **3.** package-lock.json =============  package-lock.json 將簡單地避免安裝更新的次要版本的這種一般行為，因此當有人克隆您的儲存庫並在其電腦中執行 npm install 時。 NPM 將查看 package-lock.json 並安裝與所有者安裝的套件完全相同的版本，因此它將忽略 package.json 中的`^`和`~` 。 此外，它還包含一些其他元訊息，可以節省您在安裝 npm 時從 npm 獲取資料的時間。 您可以參考[npm 部落格](https://docs.npmjs.com/files/package-lock.json)以獲取有關 package-lock.json 的更多資訊。 謝謝您閱讀此篇！ 我希望這有用 🎉 :) --- 原文出處：https://dev.to/saurabhdaware/but-what-the-hell-is-package-lock-json-b04
https://www.youtube.com/watch?v=qrl0h-gbafA 介紹 -- 在網路開發領域，響應式設計的概念通常會為初學者帶來陡峭的學習曲線。即使在轉向更高級的主題之後，許多人仍然難以完全掌握響應式設計的本質，而這一缺陷在他們的專案中變得明顯。 對許多工程師來說，響應式設計是一個難以實現的目標，主要是因為截止日期的緊迫感常常會將他們的注意力轉移到功能以及專案在個人裝置上的外觀上。這種狹隘的關注可能會導致對網站或應用程式在不同裝置上的執行情況的監督。 即使是成熟的網站也會在響應能力方面出現問題。就我個人而言，當我縮小筆記型電腦上的瀏覽器時，我發現眾所周知的 amazon.com 失去了美感。  也就是說，我認為現在要達到相當熟練的響應式設計水平並不是太難。我只是認為教育界缺乏對這個主題的關注，也缺乏以清晰、全面的方式呈現它。這就是我打算在這篇文章/影片中做的事情。 我已經確定了為了實現幾乎所有響應式設計而必須了解的 7 個 CSS 屬性/概念。雖然可能還有其他技術可以增強反應能力，但這七種技術足夠全面，可以解決大多數情況。除非您的應用程式非常複雜，否則您應該能夠在合理的時間內理解並應用這些概念。 當然，要真正理解這些概念，實踐是不可或缺的。這就是為什麼我製作了一個影片教學來補充本指南，提供所討論原則的實際演示。請記住，隨著每次練習，這些概念都會變得更加直觀。 以下是我認為至關重要的主要主題： - 尺寸單位 - 相對於螢幕 - `vw` , `vh` - 相對於其他元素 - `%` - `max-width`和`min-width`屬性 - 彈性盒 - CSS 網格 - 媒體查詢 - 響應式影像屬性 - JavaScript 用於更複雜的回應行為 尺寸單位 ---- 大多數初學者專注於建立一個適合他們螢幕的設計。因此，他們沒有意識到以精確的方式（通常使用像素（px））指定元素的大小、填充、邊距等的缺點。問題是這些元素永遠不會隨著螢幕尺寸的變化而改變尺寸。過渡到使用較少的絕對單位，如百分比和視口單位 (vw/vh) 是靈活設計的關鍵。 ### 百分比 初學者必須小心百分比。理解父子關係的概念需要時間，當給子物件一個百分比時，它是其父/容器（可互換術語）大小的百分比，而不是整個螢幕的大小的百分比。 這裡的另一點是，所有看似「沒有父級」的外部元素實際上都有 - `<body>`元素。身體尺寸如下： - 寬度 - 螢幕的寬度 - Height - 其內部內容的高度（如果正文中沒有任何內容，則為 0） ### 視口寬度/高度 ( `vw` / `vh` ) 當您想要相對於*螢幕*調整元素的大小，從而與其*直接容器*的大小無關時，您需要使用`vw`和`vh` 。 下面是一個例子。假設您的網站應該有一個`<header>`然後是一個`<main>`部分，並且您想要專門調整標題的高度，並讓主要部分佔據螢幕的其餘高度。 實現此目的的一種方法如下： ``` header { height: 300px; } main { height: calc(100vh - 300px); } ``` 一個`vh`單位基本上是視口高度（螢幕高度）的 1%。因此， `100vh`表示螢幕高度的 100%，因此`calc(100vh - 300px)`表示「螢幕高度的 100% 減去 300px」。 這確保了主要部分將佔據標題之後螢幕的剩餘高度。 您也可以使用 flex 來實現此結果，但我稍後會討論這一點。在這種具體情況下，我認為兩者都可以。隨著專案複雜性的增加，也許一種方法會更好。 ### 何時使用 px 擁有這些其他選項以及我將在下面詳細介紹的選項絕對並不意味著 px 單位如今在 CSS 中沒有一席之地。在很多情況下，您希望某些東西具有不隨螢幕變化的特定尺寸。 UI 設計中的許多元素可能更喜歡永遠不會改變的特定尺寸。例如，按鈕的大小通常是這樣的。 `max-width`和`min-width`屬性 ------------------------- 當您希望元素的大小增大或縮小但僅限於某個點時，這些屬性會變得非常有用。 常見的情況是使用者介面頂部的搜尋欄。搜尋欄可能會佔據行動裝置上的大部分螢幕寬度。儘管筆記型電腦的搜尋欄比手機更大，但一旦裝置變大，您就不會希望搜尋欄幾乎保持全螢幕寬度。 看看 Airbnb 的輸入列如何隨著螢幕的增加而變化（我的意思是它的寬度）。 移動的：  藥片：  大平板電腦/小筆記型電腦：  筆記型電腦:  這些影像有點難以判斷，但在行動裝置上，搜尋欄佔據了螢幕的大部分寬度，但就像素而言仍然很小。然後它擴展到平板電腦和小型筆記型電腦。但在某個時刻，隨著螢幕尺寸的進一步增大，它會停止增長。 彈性盒 --- 我覺得自己很幸運，在 Flexbox 發明之前不必學習 CSS。簡而言之，「Flex」是一種在位置和大小方面將元素相互關聯的驚人方法。 使用flex，你可以寫`display: flex;`在父元素上，那麼它就成為“彈性容器”，並且其所有直接子元素都成為“彈性專案”。您可以在 Flex 容器上設定幾個直覺的 Flex 相關屬性來描述 Flex 專案的行為。您也可以在 Flex 專案本身上設定一些屬性，以將其樣式與 Flex 專案的其餘部分區分開來。 初學者通常不理解彈性關係是嚴格在父子之間的。不是父母和孫子，等等。您可以擁有本身也是 Flex 容器的 Flex 專案。這意味著一個元素具有`display: flex;`它的子元素之一也有`display: flex;` 。 以下是 flex 可以派上用場的兩個最常見的場景： - Flex 可讓您在彼此相鄰或彼此之上的元素之間建立位置/空間關係。因此，例如，如果您在一行中有幾個專案，則只需使用一兩個簡單的 CSS 屬性即可在該行中將它們均勻地間隔開。 - 使用 flex，您可以輕鬆更改同級元素的定位方向。就方向而言，我的意思是從水平（行）到垂直（列），反之亦然。例如，考慮螢幕頂部導航中的連結，這些連結在移動設備的漢堡菜單下垂直組織。 CSS 網格 ------ Flex 有一個缺點，那就是當您嘗試同時控制兩個方向（x 軸和 y 軸）上的元素時。 Flex 的核心是為沿著同一個軸（x 軸或 y 軸）對齊的元素定義屬性。想要執行此操作的最常見場景是製作專案網格時。 當試圖確保它們的尺寸相同時，您可能會遇到麻煩。有關此範例，請參見下圖。  使用網格，您只需應用一兩個簡單的 CSS 屬性即可，然後問題就解決了。見下文。 ``` #card-container { padding: 20px; display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); gap: 20px; justify-content: center; } ``` 注意 - 有些人實際上選擇在其網站的整個佈局中使用網格。說實話，我從來沒有花足夠的時間來探索這個選項，因為我先學了flex（網格後來出來了），而flex可以滿足我95%以上的需求。我確實只需要用於實際網格佈局的網格，如果我需要的話，它們通常是我網站的一部分。 在 UI 的不同部分使用 flex 和 grid 並沒有什麼問題！ 媒體查詢 ---- 幾乎在任何設計中，當螢幕達到一定尺寸時，您都需要做出更大的改變。小螢幕更喜歡垂直滾動。使用更大的電腦螢幕，您可以水平放置更多元素。 透過媒體查詢，您可以定義所謂的“斷點”，即某些樣式將被覆蓋的點，以適應其他裝置的調整設計。 您可以選擇先建立行動用戶介面還是桌面使用者介面，然後建立一個斷點，在該斷點處定義新樣式以覆蓋最初並非針對的平台的現有樣式。 讓我們使用以下範例：對於行動設備，某些元素應組織在列中，但在較大的設備上，它們應組織在行中。 假設我們選擇了“行動優先設計”，這意味著首先設計行動用戶介面，然後確定實現更大設備設計的響應能力。這種選擇，而不是首先為筆記型電腦/桌上型電腦設計，在今天被認為更好，因為人們在手機上花費的時間比在大型電腦上花費的時間更多，而且公司更願意讓更多的用戶滿意。 好吧，告訴你的應用程式在平板電腦寬度和更大的情況下更改其外觀的方法基本上是- 使用媒體查詢斷點- 說，“在這個像素寬度和更高的像素寬度下，現在將這些專案的組織更改為一行。 此變更可能表示僅將 Flex 容器的 flex-direction 屬性從列變更為行，如下所示： ``` #flex-container { display: flex; flex-direction: column; } screen and (min-width: 768px) { #flex-container { flex-direction: row; } } ``` 此程式碼片段意味著 ID 為「flex-container」的元素將具有`flex-direction: column` ；對於寬度小於 768px 的螢幕，但對於寬度為 768px 及以上的螢幕，該元素將具有`flex-direction: row;` 。 附註 - 每個裝置都有相對標準的像素寬度，因此您可以尋找設定斷點的像素寬度，以指示從行動裝置到平板電腦、平板電腦到筆記型電腦等的轉換。 響應式圖像屬性 ------- 通常，上述屬性的組合將用於指定網站中圖像的大小，並且不需要進一步的 CSS。 然而，有時圖像不隨螢幕縮放。我想提供一些在這種情況發生時您可以探索的屬性。 其中一項屬性是`aspect-ratio` 。此屬性可讓您定義影像的首選縱橫比，以便它在不同的螢幕尺寸上始終保持相同的高寬比。 另一個屬性是`object-fit` ，它可以採用`fill` 、 `contain` 、 `cover` 、 `none`和`scale-down`等值，允許靈活控制圖像如何適應不同的螢幕尺寸。 JavaScript 用於更複雜的回應行為 --------------------- 最後，JS 在響應式設計中發揮著至關重要的作用，可以實現 CSS 單獨無法處理的更動態和複雜的調整，從而允許基於使用者互動或裝置規範的自訂行為。 使用 JS，您可以對更多事件類型做出反應，而不僅僅是螢幕尺寸更改，例如按鈕點擊、捲動、拖放等。 使用 JS，您可以編寫邏輯來根據您想要的任何條件動態調整元素的大小。例如，您可以根據使用者的裝置、行為、偏好和/或位置來調整內容。 JS 將佔 UI 程式碼的大部分，因此如果使用 HTML 和 CSS 無法輕鬆實現某些功能，則解決方案通常需要 JS。 結論 -- 實現響應式設計是一種平衡行為，需要將 CSS 技巧和策略性 JavaScript 結合起來。透過理解和應用上述七個關鍵概念，開發人員可以建立不僅具有視覺吸引力而且可適應所有必要設備的網站。 掌握響應式設計的旅程是不斷學習與實踐的過程。要了解這些概念的實際應用，請不要忘記查看隨附的影片教學。 請記住，響應式設計是觸手可及的，並且隨著每個專案的進行，該過程變得更加直觀。 希望我能夠透過這篇文章和影片使響應式設計成為一個不那麼模糊和令人畏懼的概念。 祝您未來的專案一切順利，感謝您的閱讀。 直到下一次， 賈里德 --- 原文出處：https://dev.to/jaredcodes/finally-understand-responsive-design-3con
什麼是 body-parser？ ========= 通常，當我看到描述[Express.js](https://expressjs.com/)伺服器的部落格文章或文章時，它通常以類似於以下內容的內容開頭： ``` npm init -y npm i express body-parser ``` 接下來就是經典 ``` const express = require('express'); const bodyParser = require('body-parser'); const app = express(); app.use(bodyParser.json()); // more express stuff ``` 我曾經在幾乎我製作的*每個*Express 應用程式中都有這四行程式碼！ 然而，幾週前，我仔細研究了[Express 文件](https://expressjs.com/en/api.html)，注意到從 4.16.0 版本[（三年前發布！）](https://www.npmjs.com/package/express/v/4.16.0)開始， [Express 基本上附帶了開箱即用的 body-parser！](https://expressjs.com/en/api.html#express.json) 如何使用 Express 版本？ ================ 好吧，你幾乎可以只搜尋`bodyParser` ，並將其替換為`express` ！ 這意味著我們上面的四行程式碼可以重構為以下三行程式碼： ``` const express = require('express'); const app = express(); app.use(express.json()); ``` 如果您使用[Babel](https://babeljs.io/) （我強烈推薦！），您甚至可以使用命名導入來使程式碼更加簡潔： ``` import express, { json } from 'express'; const app = express(); app.use(json()); ``` --- 原文出處：https://dev.to/taylorbeeston/you-probably-don-t-need-body-parser-in-your-express-apps-3nio
我在論壇上看到有人發問：免費提供網頁 對方賺得網站 我賺得經驗 這套流程可行嗎？ https://codelove.tw/@JsLover0018/post/n3VdEq 我認為很多年輕的工程師可能都曾有過類似念頭 今天分享幾點個人看法 --- 先講結論，我認為這是一個餿主意，基本上是在浪費時間 只有在很少的情況下可以考慮。大多數情況下，絕不應該免費提供你的專業 ## 免費背後釋放的訊息 從原文的案例來看，網站會是這些店家的重要門面、品牌的一部份、甚至影響銷售流程 所以這件事影響很大，並且後續可能需要定期更新、維護 我舉個比較生活化的例子 你今天對自己的牙齒排列不滿意，想找人矯正 有位無牌照的素人來跟你推銷：牙齒矯正這塊我有在自學，技術我大概都了解，我免費幫你矯正，你讓我賺得經驗，好嗎？ 我認為 99% 的人都會拒絕，寧可花10-30萬找人矯正。但明明是免費，為什麼拒絕？ 因為這會對個人外表有巨大影響，而且需要後續維護，誰敢這樣把案子給你？ 免費，背後同時也釋放一個訊息：我沒把握、我沒自信、我缺經驗、我缺案子、並且後續要不要維護全看我心情、並且你永遠不能說我有誠信問題、也不能告我，因為我沒收錢，而且我一開始就講清楚了 釋放這樣的訊息，導致大多數接觸的客戶都興趣缺缺，並不意外。 你可能想說，我不一樣，我真的願意不收錢、並且把事情做好 那麼你願意簽合約嗎？「甲方支付費用0元。如果乙方後續產出，不符合下列規格要求，乙方賠20萬元。之後每年維護費用也是0元，如果不符合下列條件要求的更新頻率，每年乙方再賠3萬元」 這樣的合約太欺負人，不可能有人簽。老實講，在民法上能不能這樣簽我都很懷疑 ## 消費心理學 vs 經濟學 再講一個，普通人比較難想像的東西 絕大多數人現在思考買賣，會依靠他們在公民課、或者經濟學課上學到的東西 供需關係決定價格、價格越低銷量越好、價格越高銷量越差 然而，一個實際做過銷售、做過生意的人會發現，根本不是這樣 完全一模一樣的產品或服務，在其餘條件都不變的情況下，你把價格從原本的 $299 改成 $99 你用經濟學思考會以為：價格變低、銷量變好，相乘之後，總體銷售額可能更大或更小 但實際上很可能銷量反而更差，總體銷售額就是變差而已 同理，你把價格從原本的 $299 改成 $499 你用經濟學思考會以為：價格變高、銷量變差，相乘之後，總體銷售額可能更大或更小 但實際上很可能銷量完全沒減少，甚至提高，總體銷售額就是更賺錢而已 為什麼？這就是消費心理學、消費行為 對於任何業務、銷售的從業人員，可能都不會意外 但是大多數普通人可能比較難想像、遇到了會深感訝異 定價的設定、如果再加上相關服務內容項目、用字遣詞的調整，影響程度會更大 ## 結論 如果是有親戚朋友、或者熟悉的同事介紹，真的有人沒預算、但又有網站需求 我認為是可以免費幫人做一些簡單的網站，累積一些經驗、作品集這樣 但如果要用免費為主打，去主動業務開發 我認為不太可行 那到底如何銷售？如何經營個人品牌？如何進步到有自信去標準收費、標準服務？ 這些都需要慢慢研究，這也是做生意有趣、有挑戰性的地方 請記住，做生意就是，慢慢去弄清楚市場需要什麼、顧客在想什麼的過程 你自己以為怎樣，或者以為什麼對客戶有價值，那都是你以為而已，你的想法並不重要 這是一個需要放下自尊，視野要清晰、需要時間的過程 像原 po 這樣花時間跟多組客戶嘗試，然後失敗的經驗很好，就是學習的一個過程 持續改善銷售能力就對了，做 sales 跟做 coding 說起來也是一樣，trial and error 以上，簡單分享，祝你很快開始接到幾個案子！
* [第1課 ── 認識 callback hell](https://jsfiddle.net/birdie2019/6dm07yo8/20/) * [第2課 ── 認識 promise chain 鏈接](https://jsfiddle.net/birdie2019/p8uL3r1e/28/) * [第3課 ── 認識 async/await 語法](https://jsfiddle.net/birdie2019/ydzsu43c/24/) 終於有比較清楚了！
轉職快一年了，輪流跟幾個後端合作，目前我觀察到的如下(因為是在接案公司，常常在趕進度或同時進行多個專案) 有的後端很好心，且可以快速切割工作內容(前後端沒有分離)，直接留言告訴你做什麼改什麼，他負責做什麼改什麼，甚至幫你程式碼第幾行都標示出來。 有的是後端api開發完不會通知，要一直去追問進度才知道對方是否開發完成 有的是後端給的api缺東缺西或是沒有說要傳遞什麼資料給後端，要特別去問，回應的態度要看對方心情，但有的雖然缺東缺西但至少標示清楚，可以馬上知道缺少什麼欄位資料，請後端補齊 比較誇張的一次是多個後端一起開發專案，我前端串接完api測試沒問題，交測後發現網頁報錯，看起來是api沒回應資料，查了才知道後端們整合api後沒通知前端api路徑有更改... 想問問，前端前輩們是如何與後端溝通的？ 或是分享工作上合作經驗，感激不盡 >_<
自學網頁の嬰兒教材：第2課 ── CSS 輕入門: https://jsfiddle.net/applelily/4kuo01L6/ --- 自學網頁の嬰兒教材：第3課 ── 網頁排版: https://jsfiddle.net/applelily/xcr3jzfe/3/ --- 自學網頁の嬰兒教材：第4課 ── 好用的表格: https://jsfiddle.net/applelily/m10zqh76/8/ --- 自學網頁の嬰兒教材：第5課 ── 用力送出表單: https://jsfiddle.net/applelily/v3ju1Lbr/73/ --- 自學網頁の嬰兒教材：第6課 ── 在自己電腦上寫網頁: https://jsfiddle.net/applelily/23gu1qzb/2/ --- 自學網頁の嬰兒教材：第7課 ── 大感動！我也有個人網頁了！: https://jsfiddle.net/applelily/7r4s0gLo/1/ ---
不好意思打擾各位前輩 我是剛剛入職的新手前端，我想詢問一下前端的工作內容 --- **第一天**上班主管就丟給我一個他們之前開發寫到一半的專案， 要我修客服聊天室連線的問題，demo給我看一下問題出在哪， 之後我把專案打開整個人都麻了，裡面一大堆的文件，我都不知道是做什麼的， 哪個檔案是哪個頁面我都不知道，最後通靈才知道應該是使用SignalR這個套件， 不過我也沒有使用過，只知道他是用來實現ws連線技術的， 最後是下班前兩三個小時，主管自己過來操作讓他可以使用，我在旁邊看的一楞一楞的。 --- **第二天**主管讓我做不同語系，用i18next套件，把網頁上的文字設定到裡面， 這個其實沒問題，有問題的是我不知道哪個頁面對應到哪個檔案，檔案底下的組件又在哪裡， 有時候明明是member資料夾底下的頁面，同一資料夾裡面也有components的資料夾， 但頁面上有時候不只使用到member資料夾底下的組件，還用到了上層資料夾的組件， 我真的不是很明白，所以中午我就問說有沒有開發的流程圖之類的東西， 他只笑著跟我說:[沒有]，我最後就一個一個點開，找不到的只能先記事本記錄下來之後在一起問。 --- **第三天**還是再做第二天的事情，但下午主管又丟另一個專案給我，是要修改串API的問題， 說現在有資料但不是他想要的，讓我去跟後端說明他想要什麼資料， 之後就開文件讓我看API是怎麼串的，他好像是把axios封裝起來做了很多處理，講解一下之後， 讓我去翻其他文件是怎麼串的。 --- 想請教一下各位前輩面對前端的工作內容， 我是不是應該在學得更深一點再開始找工作
我曾經做過大概三次到四次的接案嘗試 這是有訊息回應的 其他發訊息無回應的就不計算 都是先把網頁寫好 然後聯絡對方 跟對方簡單介紹說 我可以提供這個網頁做為協助 並且不需要收費當作練習 一個是有經營YT的英文家教 有訊息回應 不過後續沒有討論細節 當我丟完示範的頁面(自己找他的一些圖片文章做成的網頁) 後 沒有積極的回應 另一個是某地方的健身房 小工作室 發訊息後對方有回應 老闆的老婆說要跟老闆討論看看 後續無下文 一個是某地方的按摩 新開的 也是已經做完網頁 資訊圖片都是我自己抓完做上去 也弄了swiper去顯示google評論 有到場跟老闆娘說明這個網頁 以及簡單介紹網頁好處 後續也是說要跟老公討論 無下文 再來是某個認識的健身自由教練 是我的一個教練 他有經營自己IG 並沒有在連鎖健身房上班 也有下IG廣告招生 其實非常需要網頁做為個人品牌推廣 我也是已經把他的一些教學圖文或資料丟上去 寫好了網頁 訊息問 也表明無須收費 就是一個經驗 可以給他放在任何頁面當他的官網 但也是被婉拒 說暫時沒有想發展(可是時至今日 他仍然在投放IG廣告 經營IG貼文找學生等等 經歷過這些 我開始在想 似乎這問題不是免費不免費的問題 一方面是他們有種莫名的執著 或者是 我缺少了某個關鍵點去說服他們接收這個網頁 又或者他們真的不需要 這真的是令人感到挺沮喪的 感覺一定是某個過程缺少了什麼 也許我說服力不夠強 但我感到最矛盾的是 明明跟對方溝通過程 了解他們需要拓展 卻很果斷的拒絕了網頁這個東西 也許他們是認為沒幫助...但以我的角度來看 做關鍵字 或是放在他們google商家的"網站"欄位 都是很好的幫助 這真的讓我迷惘很久.......... 我認為這種 找到一個"客人" 幫她完成"需求" 免費提供網頁 對方賺得網站 我賺得經驗 這套流程好像似乎被我驗證不太可行....總之 這是個我還需要理解的領域 是否水很深? 還請各位前輩發表一些經驗談 感恩
例如有個 component 如下： ``` vue <template> <iframe :src="url.src"></iframe> </template> <script> export default { data() { return { url: { src: 'https://example.com', }, }; }, }; </script> ``` 這時如果 src 網址變動，iframe 內會顯示新的網頁，同時也會造成 browser history 被修改，也就是點擊瀏覽器的上一頁時，會發現整個網頁沒有跳回上一頁，而是 iframe 回復到舊的網址，但如果這不是你想要的效果呢？ vue.js 官方文件介紹 key 的時候提到： > It can also be used to force replacement of an element/component instead of reusing it. 所以答案就是在 iframe 加上動態的 key，key 和 src 同時變動時，vue.js 就會強制替換成新的 iframe，跳過 browser history 被修改的問題，點擊瀏覽器的上一頁就能正常回到前一頁了，範例如下： ``` vue <template> <iframe :key="url.key" :src="url.src"></iframe> </template> <script> export default { data() { return { url: { key: 1, src: 'https://example.com', }, }; }, }; </script> ``` P.S. 參考資料中，文章作者提到 react 也是一樣的處理方式。 參考資料： https://vuejs.org/api/built-in-special-attributes.html https://www.aleksandrhovhannisyan.com/blog/react-iframes-back-navigation-bug/ https://stackoverflow.com/questions/821359/reload-an-iframe-without-adding-to-the-history#answer-77278956
這篇作者強烈偏好 promise 並排斥寫 async/await https://uniqname.medium.com/why-i-avoid-async-await-7be98014b73e 留言區有清楚的相反論點 不用對這議題有特定立場，但就是要知道注意事項： **即使語法看起來像同步 code，也要知道背後是非同步 code，不然遲早會出問題**
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
