原文出處：https://dev.to/kumarkalyan/top-5-github-repositories-to-achieve-system-design-mastery-27n4 ## 簡介 🔥 本文包含前 5 個 GitHub 儲存庫的列表，可協助您掌握系統設計。 這些儲存庫主要包含與系統設計相關的教學課程、部落格、影片和案例研究 請務必存取這些儲存庫，探索內容，實施所學知識，如果可以的話做出貢獻，並給他們 ⭐ 來幫助他們成長。  ## 什麼是系統設計 系統設計⚙️是為特定係統設計架構、元件、介面和資料以滿足特定要求的過程。 在建立任何應用程式或系統之前，🏗️規劃系統如何運作、需要哪些資源、在哪裡部署、系統元件將使用哪些 API 以及如何擴充系統非常重要。因此，系統設計理念對於軟體開發人員掌握建置高效且可擴展的系統非常重要。 💯 ## 1\.開發者路線圖 [https://github.com/kamranahmedse/developer-roadmap](https://github.com/kamranahmedse/developer-roadmap) * 開發者路線圖 GitHub 儲存庫由 Kamran Ahmed 建置和維護，該儲存庫可以被認為是軟體開發的最佳手冊 * 它在 Git Hub 上擁有 255k 星和 684 名貢獻者。該儲存庫僅提供英文版本，它包含所有內容的結構化路線圖以及資源、指南等。 > [給開發者路線圖打 ⭐](https://github.com/kamranahmedse/developer-roadmap) --- ## 2\.系統設計入門 [https://github.com/donnemartin/system-design-primer](https://github.com/donnemartin/system-design-primer) * Sytem Design Primer GitHub 儲存庫由 Facebook（現為 Meta）的技術主管建立。這個儲存庫可以被認為是系統設計的聖經 * 它在 GitHub 上擁有 233,000 顆星，擁有 100 多個貢獻者，並提供多種不同語言版本。 > [給系統設計入門打 ⭐](https://github.com/donnemartin/system-design-primer) --- ## 3\.系統設計101 [https://github.com/ByteByteGoHq/system-design-101](https://github.com/ByteByteGoHq/system-design-101) * System Design 101 GitHub 儲存庫由 Byte Byte Go Hq 建置和維護，這是一個在系統設計面試中脫穎而出的平台 * 它在 Github 上有 39.2k 啟動次數和 14 個貢獻者。此儲存庫僅提供英文版本，是初學者的最佳儲存庫。該儲存庫包含有關通訊協定、CI-CD、架構模式、微服務、DevOps、雲端、Linux 等主題的有效指南。 > [給 system-design-101 打 ⭐](https://github.com/ByteByteGoHq/system-design-101) --- ## 4\.系統設計資源 [https://github.com/InterviewReady/system-design-resources](https://github.com/InterviewReady/system-design-resources) * Sytem Design Resources GitHub 儲存庫由 Interview Ready 建置和維護，這是一個為大型科技巨頭提供 Sytem 設計面試的平台。 * 它在 Git Hub 上有 11,400 顆星，有 8 位貢獻者。此儲存庫僅提供英文版本。它包括有關各種系統設計主題的案例研究、指南和視訊講座，包括視訊處理、叢集和工作流程管理、服務內訊息傳遞、訊息佇列反模式、服務網格、實用系統設計、分散式檔案系統、時間序列資料庫、速率限制、記憶體資料庫 - Redis 等等 > [給系統設計資源打 ⭐](https://github.com/InterviewReady/system-design-resources) --- ## 5\.系統設計 [https://github.com/karanpratapsingh/system-design](https://github.com/karanpratapsingh/system-design) * 系統設計 GitHub 儲存庫由 Curebase 的高級軟體工程師 Karan Pratap Singh 建置和維護。 * 它在 Git Hub 上有 21,100 顆星，有 9 位貢獻者。此儲存庫僅提供英文版本。它基本上是作者真書的免費版本。它共有 5 章，最適合剛接觸開發的初學者。 > [給系統設計打 ⭐](https://github.com/karanpratapsingh/system-design) 在那之前請繼續關注我的下一篇博客 
## 簡介 Web 開發的世界可能會因資源太多而令人不知所措。為了簡化這個過程，我列出了專為 Web 開發人員量身定制的 24 個最佳資源。 本指南涵蓋 HTML、CSS 和 JavaScript 的核心技術，旨在為初學者和專家提供有價值的工具和見解，以提高他們的 Web 開發技能。請探索這些精心挑選的資源，以幫助您在 Web 開發中脫穎而出。 原文出處：https://dev.to/swirl/24-best-resources-for-web-developers-html-css-javascript--2hog --- ## [Swirl](https://github.com/swirlai/swirl-search) [](https://github.com/swirlai/swirl-search) 搜尋多個來源具有挑戰性。 Swirl 結合了您所有的資料庫、筆記、PDF、Jira、GitHub、向量資料庫、Discord、Slack、Teams Chat 等，並允許您搜尋它們。 允許您： - 產生答案的人工智慧摘要。 🤖 - 管理您的資料並建立知識庫。 📚 - 節省時間並提高工作效率。 ⏳ 請在 GitHub 上給 Swirl Search 一個 ⭐️。 💖 https://github.com/swirlai/swirl-search 在 GitHub 上給 Swirl ⭐ --- ## CSS 工具 #### 1. [CSS 漸變](https://cssgradient.io/) CSS Gradient 是一個可讓您為網站建立免費漸變背景的專案。  #### 2. [Colorhunt](https://colorhunt.co/) Colorhunt 為設計師和藝術家提供了很棒的調色板。  #### 3. [CSS 技巧](https://css-tricks.com/) CSS Tricks 提供了有關級聯樣式表的一些最佳建議、提示、技巧和程式碼片段。  #### 4. [Haikei 生成器](https://haikei.app/generators/) Haikei 是一款 Web 應用程式，可產生令人驚嘆的視覺內容 - 可與您的設計工具和工作流程一起使用。  #### 5. [FFFuel](https://fffuel.co/gggrain/) Fffuel 是一個顏色工具和免費 SVG 生成器的集合，用於漸變、圖案、紋理、形狀和背景。  #### 6. [SVG 背景](https://www.svgbackgrounds.com/) SVG 背景託管一系列可在您的網站上使用的 SVG 背景。  #### 7. [動畫背景](https://animatedbackgrounds.me/) 動畫背景託管各種動畫背景的程式碼片段，可用作網站的背景。  #### 8. [Flowbite](https://flowbite.com/blocks/publisher/blog-templates/) Flowbite 提供了一組基於流行的 Tailwind CSS 框架的強大設計令牌和元件。  #### 9. [DaisyUI](https://daisyui.com/) DaisyUI 為 Tailwind CSS 新增了一組可自訂的顏色名稱，這些新顏色使用 CSS 變數作為值。  --- ## HTML #### 10. [Quackit 的 HTML 範本](https://www.quackit.com/html/templates/) Quackit 提供了大量免費網站模板可供選擇。根據您的選擇，您可以從簡單或更高級的模板清單中進行選擇。  --- ## 圖示 #### 11. [Devicon](https://devicon.dev/) Devicon 是一組代表程式語言、設計和開發工具的圖示。您可以將其用作字體或將 SVG 程式碼複製/貼上到您的專案中。  #### 12. [Flaticon](https://www.flaticon.com/) 為您的專案下載免費圖示和貼紙 - 由設計師製作並為設計師製作的 PNG、SVG 等格式的圖像。  --- ## 低程式碼工具 #### 13. [Framer](https://www.framer.com/) Framer 是一款低程式碼、基於人工智慧的拖放式網站建立器。  #### 14. [泡泡](https://bubble.io/) Bubble 自稱是世界上唯一的全端、無程式碼平台。 Bubble 是一款讓您無需編寫任何程式碼即可建立應用程式的工具。  #### 15. [阿達洛](https://www.adalo.com/) Adalo 是一種低程式碼響應式 Web 應用程式設計工具。  --- ## 其他 #### 16. [CDN JS](https://cdnjs.com/) CDN JS 是一個免費開源的內容傳遞網路。它允許 Web 開發人員直接搜尋 npm 套件並將其載入到靜態頁面的 HTML 頭部，而無需擔心 npm 安裝。  ## 免費圖片 #### 17. [Unsplash](https://unsplash.com/) 雖然我們有圖像生成工具，但沒有什麼比Unsplash帶給我們的超現實主義更重要了。您可以在網站上使用許多圖像（請記住向攝影師捐贈並在使用他們的圖像時提及他們）。  #### 18. [DALLE-3](https://openai.com/dall-e-3) Open AI 影像生成工具的第三次迭代。您可以使用 Bing AI 圖像產生器工具免費使用此工具。  --- ## 模型 #### 19. [模型世界](https://www.mockupworld.co/) 大量免費、合法、完全分層、易於自訂的逼真 PSD 模型：可在您的專案、應用程式展示和演示中使用！ 〜在他們的網站上提到！  #### 20.【免費模型世界】(https://www.freemockupworld.com/) Free Mockup World 是高品質、最佳免費模型的合作，包括 Apple 裝置、品牌、標誌、印刷、數位藝術、時尚、服裝等。 〜在他們的網站上提到。  #### 21.【UI設計日報】(https://uidesigndaily.com/) 適合您網站的免費開源 UI 設計資源。 （包含登入頁面等的 Figma 模型）  --- ## 其他有用的開源程式庫 #### 22.【ShadCN】(https://ui.shadcn.com/) 使用 Radix UI 和 Tailwind CSS 建立的設計精美的元件。  #### 23. [點選投票](https://clickvote.dev/) Clickvote 是一個開源函式庫，可以省去圍繞內容建立反應元件的麻煩。  #### 24. [斯巴達NG](https://www.spartan.ng/) ShadCN 用於 Angular。開源、社群建構。  --- ## 用於搜尋資料 - Swirl ### [漩渦](https://github.com/swirlai/swirl-search) **Swirl 是一個開源搜尋平台，它改變了您與資料互動的方式。** [](https://github.com/swirlai/swirl-search) 將其視為專門為您的獨特資料集量身定制的 ChatGPT。無論是筆記、程式碼片段、PDF 檔案還是電子郵件，Swirl 都是您獲取即時、人工智慧驅動見解的首選平台。 Swirl 與眾不同的特質： - **一般搜尋**：無縫搜尋筆記、程式碼、文件、資料庫、電子郵件、聊天、日誌等。 🔍 - **個人人工智慧驅動的知識助理**：您可以為您的公司、新創公司或個人資料建立安全、可搜尋的知識庫。 🤖 - **一鍵檢索增強生成**：使用 Swirl，您可以立即執行人工智慧摘要和分析。您可以透過產生這些資料的資料來源來獲得答案。 🛠️ **請在 GitHub 上給 Swirl Search 一個 ⭐️。 💖** https://github.com/swirlai/swirl-search 在 GitHub 上給 Swirl ⭐ 並加入我們的【開源 Slack 社群 💕】(https://join.slack.com/t/swirlmetasearch/shared_invite/zt-1qk7q02eo-kpqFAbiZJGOdqgYVvR1sfw) --- 再次感謝您的閱讀！
許多人認為，成為電腦程式設計師不需要了解任何數學。雖然這可能部分正確，但了解一些基本的數學概念可以使程式設計變得更容易，並幫助您解開數位世界的秘密。 現在，讓我們探討每個程式設計師都應該熟悉的 10 個數學概念。 原文出處：https://dev.to/codewithshahan/10-math-concepts-for-every-programmer-31n9  ## 1. 布林代數 布林代數是程式設計中的基本概念。它處理只能有兩個值的二元變數：true 或 false。我們使用三個運算子來處理布林值：**AND**、**OR** 和 **NOT**。 將它們想像為決策工具。例如，如果你想知道某人是否既**有錢**又**帥**才能得到**女孩**，布爾變數可以幫助你做出決定。如果這兩個條件都滿足，他就會得到一個女孩。如果沒有，他可能還有其他選擇。您可以使用if 語句、[維恩圖](https://en.wikipedia.org/wiki/Venn_diagram) 或[真值表](https://en.wikipedia.org/wiki/Truth_table) 來表示此邏輯。  ## 2. 數位系統 電腦使用以 2 為基數（二進位）的數字系統，與人類使用以 10 為基數（十進位）的系統不同。在基數2 中，數字僅使用兩個符號表示：0 和1。了解二進位有助於我們使用其他數字系統，例如十六進位(基數16) 和基數64，這在程式設計中至關重要，特別是對於編碼和表示資料。  ## 3. 浮點數 浮點數是計算機表示實數的方式。它們並不總是精確的，這可能會導致計算中出現微小的錯誤。這些數字使用科學記數法來有效地處理大值和小值。了解浮點數的限制對於避免程式碼中出現這些錯誤至關重要。 ``` print(1.00000000005) # A positive float print(-85.6701) # A negative float ``` ## 4. 對數函數 對數幫助我們理解一些自然現像是如何運作的。將對數視為一種測量需要切割原木多少次才能達到特定長度的方法。在程式設計中，對數函數用於二分搜尋等演算法。這些功能在從演算法到科學研究的各種應用中發揮著至關重要的作用。 ## 5.集合論 集合論處理唯一值的集合。在程式設計中，這個概念被廣泛使用，特別是在資料庫中，其中表是唯一行的集合。連接集合、尋找交集、並集和差異是這種情況下的常見操作。理解集合論對於使用資料庫和資料操作非常重要。  ## 6. 組合學 組合學就是對事物和組合進行計數。無論您是為新聞應用程式開發演算法還是設計全球分散式資料庫，組合數學都可以幫助您有效地計算所有可能的組合或排列。這是一項寶貴的程式設計技能。  ## 7.圖論 圖論涉及由邊連接的節點（頂點）。這個概念用於對關係和連接進行建模。理解圖論對於解決網路路由等問題和優化各種場景至關重要。  ## 8. 複雜性理論（大 O 表示法） 複雜性理論可以幫助您分析演算法的效率。 Big O 表示法是表達演算法時間和記憶體複雜度的工具。它可以幫助您為您的程式設計任務選擇最有效的解決方案，這是面試和編寫高效程式碼的寶貴技能。  ## 9. 統計 統計對於各個程式設計領域都至關重要，尤其是在人工智慧和機器學習領域。了解平均值、中位數、眾數和標準差等基本統計概念可以讓您最擅長做出預測。它是在[資料驅動的應用程式](https://try.sanebox.com/kxz8nr6vzzwl)中進行預測和決策的基礎。  ## 10.線性代數 [線性代數](https://en.wikipedia.org/wiki/Linear_algebra) 在電腦圖形學、深度神經網路和許多其他程式設計領域中至關重要。它涉及標量、向量和矩陣來表示和操作資料。如果您想使用 3D 圖形、密碼學和機器學習，那麼線性代數就可以發揮作用。您需要掌握線性代數才能解決這些問題。  _**建議：使用 FigJam 進行專案設計**_ 身為程式設計師，您需要一個工具來與您的團隊或個人一起繪製藍圖、繪製心智圖、集思廣益、建立出色的專案、確定決策目標等等。 FigJam 是最好的選擇，也是市場上最受歡迎的工具。 > FigJam 讓團隊能夠共同建立更好的產品。定義想法、協調決策並推動工作——所有這些都在一個地方完成。 ~Figma 您可以在 [此處](https://psxid.figma.com/1a5bfv7xj7nc-lpaypq) 註冊 FigJam。您將來一定會發現它非常有用。 ## 結論 數學是程式設計世界中的強大工具，這 10 個概念只是一個開始。它們可以幫助您開發更有效率的程式碼、解決複雜的問題並揭開數位世界背後的魔力。這些數學概念將使您成為更好的程式設計師，並且您將有能力克服不斷發展的技術領域中的各種挑戰。
客戶最近有把舊 laravel 專案改寫為 SPA 的需求，需要前後端分離 為了方便前後端溝通、改善開發者體驗，我建議＆協助他們導入 GraphQL 技術到 laravel 專案中！ 實際導入＆開發半年之後，成效非常不錯！前端工程師、後端工程師都用得很開心！ 今天跟大家分享一些心得＆範例程式碼！ ## 破除迷思 > 很多公司聽到 GraphQL 會有點卻步，覺得太新、不成熟 其實，這技術面世八年了，在國外已經被許多公司廣泛採用，不算很新了！ > 很多公司會以為這是給大公司用的技術，小公司不適合使用 其實，我自己的使用經驗是，就算團隊只有兩個工程師，這技術也很好用，會讓開發速度更快，不會更慢！ > laravel 社群會以為這技術在 node 社群、或其他社群比較常見 其實，laravel 社群也有很好用的套件，導入也很方便！ 所以這技術非常值得學習、使用，至少了解一下！ ## 優點介紹 我認為最大的優點就是，大幅降低了前後端溝通的成本！ 傳統開發，後端寫完 API，要另外寫文件告訴前端網址是多少、回傳的資料格式 然後前端需要用 postman 之類的工具，方便測試、開發 使用 graphql 的話，後端寫完程式碼，就同時自動生成文件＆測試工具了！ 為了方便讀者「親自試玩」以上描述，我準備了一個範例專案給大家！ 這個專案模擬電商網站，API 可以撈 products 與 comments 兩種資料！ 然後可以訂閱商家的電子報，也就是新增 subscriber 這種資料！ ## 實務範例與 API 線上試玩 我先分享範例專案給大家！ https://graphql-laravel-example.tw/ 原始碼也已公開 https://github.com/howtomakeaturn/graphql-laravel-example --- 以往 RESTful 的設計，「讀取資料」這種動作，在 graphql 稱之為 query https://github.com/howtomakeaturn/graphql-laravel-example/tree/main/app/GraphQL/Queries 會去「更新資料庫」的動作，在 graphql 稱之為 mutation https://github.com/howtomakeaturn/graphql-laravel-example/tree/main/app/GraphQL/Mutations 以上兩個資料夾可以翻閱一下，每支 api 會是一個檔案，所以很好管理 接著使用 graphql 社群的強大工具：graphiql，就同時得到文件＆測試工具了！ https://graphql-laravel-example.tw/graphiql 我安裝了一份 graphiql 給大家，點進去玩玩看吧！ 把他當成是技術規格文件與 Postman 測試工具，身兼兩種用途！ 有了這個工具，大幅減少了前後端需要溝通的事項，對於前後端合作有「巨大幫助」！ （請注意，實務上 graphiql 建議在本機執行，不要這樣線上公開，會有資安疑慮） ## 套件介紹 在 graphql 社群，有兩種開發 api 的哲學 分別是 schema-first 與 code-first 兩種方法 laravel 社群最知名的 schema-first 套件是這款 https://github.com/nuwave/lighthouse laravel 社群最知名的 code-first 套件是這款 https://github.com/rebing/graphql-laravel schema-first 與 code-first 的差異與優缺點我先不細談 總之，我個人比較喜歡 code-first，我覺得比較直觀、簡單、好導入 所以我的範例是用 https://github.com/rebing/graphql-laravel 這套件 您的 laravel 版本建議至少要是 8.0 以上版本，太舊的可能會有問題 順帶一提，兩個套件背後都是使用 https://github.com/webonyx/graphql-php 所以底層元件一樣，兩者有很多通用的觀念，不用太擔心 --- graphiql 是 graphql 官方的重要工具 laravel 社群已經有人寫好懶人安裝套件了 https://github.com/mll-lab/laravel-graphiql 按照說明安裝即可得到超好用的自動文件＆測試工具面板！ ## 結論 有了以上兩個套件，按照說明分別安裝 然後參考我提供的範例程式碼 https://github.com/howtomakeaturn/graphql-laravel-example 您應該就可以在專案之中導入 graphql 基礎架構，並且開始用 graphql 寫出您的第一支 api 我在替客戶導入的時候，發現網路上 graphql 的教學、說明雖然很多 但是剛開始寫還是很困難，很少範例 所以我製作這份 open source 方便大家參考＆入門 並且直接把 graphiql 面板公開部署上線，方便大家體驗！ （此為系列文章，更多內容會在近期發佈） --- # 系列文章 - [Laravel + GraphQL 接案心得＆範例分享 Part 1：強大優點、API 線上試玩、工具介紹](https://codelove.tw/@howtomakeaturn/post/yx08mx) - [Laravel + GraphQL 接案心得＆範例分享 Part 2：前端 Query/Mutation 與 React 串接範例](https://codelove.tw/@howtomakeaturn/post/2an0Gx)
開源專案是創新、協作和創造力的遊樂場。它是來自世界各地的開發人員聚集在一起分享他們的想法、技能和熱情的中心。 在本文中，我精心挑選了 24 個涵蓋廣泛興趣和技術的開源專案。 從尖端的人工智慧框架到漂亮的生產力工具以及介於兩者之間的一切，每個開發人員都能找到適合自己的東西。 我提供了直接連結、描述和視覺效果，以便您可以立即獲得每個工具的初步印象。 原文出處：https://dev.to/madza/24-open-source-projects-for-developers-in-2023-391l --- ## 1\. [ esProc SPL](https://github.com/SPLWare/esProc)（贊助） 集算器SPL是一種基於腳本的資料操作語言，與SQL資料庫集成，支援進階分析和高效能並行處理。 它適合處理大型資料集，與各種工具集成，提供資料視覺化，並跨多個平台工作。一些主要功能包括： **💪 強大的資料處理能力：** 集算器SPL是一種腳本語言，具有豐富的函數庫和強大的語法。 **✨ 預存程序等效項：** 它允許透過 JDBC 介面執行 SPL 腳本。 **📈 多功能視覺化：** 它提供了成熟的報告工具，具有廣泛的視覺化配置，用於建立各種類型的報告。 **⚡ 自動化工作流程：** 它支援軟體工作流程的自動化，包括用於程式碼建置、測試和部署的 CI/CD 流程。 **🔥 相比SQL更具彈性：** 與SQL語法不同，集算器SPL允許將資料處理程式碼寫在多條語句中。  ⭐ 支援他們的 GitHub 倉庫：[https://github.com/SPLWare/esProc](https://github.com/SPLWare/esProc) ## 2\. [Hoppscotch](https://github.com/hoppscotch/hoppscotch) 一種多功能開源 API 開發和測試工具，提供使用者友善的介面，用於發出 HTTP 請求來測試 API 並與 API 互動。 它簡化了製作和發送請求的過程，使其成為使用 API 的開發人員和測試人員的必備工具。  ## 3\. [Supabase](https://github.com/supabase/supabase) Firebase 的開源替代方案，為開發人員提供了一組用於建立可擴展的即時應用程式的工具。 它提供了強大的後端即服務 (BaaS) 平台，具有身份驗證、資料庫管理和即時功能等功能，使其成為建立現代 Web 和行動應用程式的強大選擇。  ## 4\. [Supertokens](https://github.com/supertokens/supertokens-core) 一種開源身份驗證解決方案，提供強大的安全功能和輕鬆集成，以增強 Web 和行動應用程式中的使用者身份驗證和授權。 它為開發人員提供了一個全面的工具包，用於保護用戶資料並確保無縫登入體驗。  ## 5\. [Git](https://github.com/git/git) Git 版本控制系統的官方開源程式庫，最初由 Linus Torvalds 建立。 Git 廣泛用於追蹤原始程式碼的更改，並透過提供強大的分支和合併功能來實現協作軟體開發。 ## 6\. [VS Code](https://github.com/microsoft/vscode) 由 Microsoft 開發的免費開源程式碼編輯器。 它提供了高度可自訂且高效的程式設計環境，具有 IntelliSense、除錯支援和龐大的擴充庫等功能，可增強您的開發工作流程。  ## 7\. [OhMyZsh](https://github.com/ohmyzsh/ohmyzsh) 一個流行且高度可自訂的框架，用於在類 Unix 作業系統中管理 Zsh 配置。 它簡化了 shell 自訂，提供了大量插件和主題來增強您的命令列體驗。  ## 8\. [Bun](https://github.com/oven-sh/bun) 一個開源 JavaScript 工具包，旨在簡化和優化為 Web 應用程式捆綁 JavaScript 程式碼的過程。 它提供了一種現代且快速的方法來建立捆綁包，從而增強了使用 JavaScript 專案時的效能和開發人員體驗。  ## 9\. [SWR](https://github.com/vercel/swr) SWR（Stale-While-Revalidate）是一個用於在 React 應用程式中取得資料的 JavaScript 函式庫。 它可以在客戶端和伺服器之間實現高效、自動的資料同步，提供無縫的即時更新，同時確保資料保持新鮮和最新。  ## 10\. [Prisma](https://github.com/prisma/prisma) 用於現代應用程式開發的開源資料庫工具包，透過強大的查詢產生器和類型安全的 ORM（物件關聯映射）層簡化資料庫存取和操作。 它允許開發人員使用聲明性和直觀的方法管理資料庫並與之交互，從而使資料庫操作在各種資料庫系統中無縫且安全。  ## 11\. [ElasticSearch](https://github.com/elastic/elasticsearch) 由 Elastic 開發的強大且可擴展的開源搜尋和分析引擎。 它旨在幫助用戶快速有效地搜尋、分析和視覺化大量資料，使其成為從全文搜尋引擎到日誌分析等應用程式的熱門選擇。  ## 12\. [Hasura](https://github.com/hasura/graphql-engine) 一款功能強大的開源工具，可簡化應用程式的 GraphQL API 開發。 借助 Hasura，您可以輕鬆建立、管理和保護 GraphQL API，從而更輕鬆地與資料來源互動並建立現代的資料驅動應用程式。  ## 13\. [BioDrop](https://github.com/EddieHubCommunity/BioDrop) 透過單一連結與您的受眾建立聯繫。在一處展示您建立的內容和專案。 讓人們更容易找到、關注和訂閱。  ## 14\. [Powertoys](https://github.com/microsoft/PowerToys) 適用於 Windows 的開源實用程序，可提高工作效率和自訂功能。 它提供了一系列方便的工具和實用程序，包括快速啟動器、文件預覽和視窗管理等功能，旨在簡化您的 Windows 體驗。  ## 15\. [Strapi](https://github.com/strapi/strapi) 開源無頭內容管理系統 (CMS)，使開發人員能夠快速建立強大且可自訂的 API。 它使團隊能夠輕鬆建立和管理內容豐富的網站和應用程式，為各種專案提供靈活性和可擴展性。  ## 16\. [Plausible](https://github.com/plausible/analytics) 一種開源網路分析工具，旨在為網站所有者提供對其網站效能的簡單且注重隱私的見解。 它提供用戶友好、輕量級的跟踪，且不會損害存取者的隱私，使其成為那些重視資料分析而無需侵入性跟踪方法的人的理想選擇。  ## 17\. [Astro](https://github.com/withastro/astro) 現代靜態網站產生器，透過僅傳送頁面所需的 JavaScript 來提供閃電般的效能，從而實現近乎即時的載入時間。 它將傳統伺服器渲染框架的靈活性與靜態網站產生器的速度相結合，使其成為建立高效動態網站的絕佳選擇。  ## 18\. [Remix](https://github.com/remix-run/remix) 用於建立現代 JavaScript 應用程式的 Web 框架，注重速度和開發人員體驗。 它使開發人員能夠透過無縫組合伺服器渲染和客戶端渲染的內容來建立高效能的 Web 應用程式。  ## 19\. [Tensorflow](https://github.com/tensorflow/tensorflow) 由Google開發的開源機器學習框架。 它為建立和部署機器學習模型提供了靈活且全面的生態系統，使其成為人工智慧領域研究人員和開發人員的熱門選擇。  ## 20\. [Flutter](https://github.com/flutter/flutter) 由 Google 建立的開源 UI 軟體開發工具包，以其從單一程式碼庫建立適用於行動、Web 和桌面的本機編譯應用程式的能力而聞名。 它使開發人員能夠使用單一程式語言 Dart 跨多個平台建立美觀、快速且高度可自訂的使用者介面。  ## 21\. [Kubernetes](https://github.com/kubernetes/kubernetes) 一個開源容器編排平台，可自動執行容器化應用程式的部署、擴充和管理。 它為編排容器提供了強大而靈活的基礎架構，使在雲端原生環境中大規模管理複雜的分散式系統變得更加容易。 ## 22\. [Docker](https://www.docker.com/community/open-source/) 一個開源工具，可簡化多容器 Docker 應用程式的管理。 它允許開發人員使用簡單的 YAML 檔案定義和執行多容器應用程式，從而更輕鬆地編排和部署複雜的服務。  ## 23\. [Chromium](https://github.com/chromium/chromium) Google 的一個開源瀏覽器專案，旨在為所有使用者建立更安全、更快、更穩定的網路體驗方式。 它是開發人員在網路瀏覽技術領域做出貢獻和創新的平台。  ## 24\. [Linux 核心](https://github.com/torvalds/linux) 由 Linus Torvalds 和全球貢獻者社群開發的開源、類別 Unix 作業系統核心。 它作為各種基於 Linux 的作業系統的核心元件，提供硬體互動和系統管理的基本功能。  --- 以上，簡單分享！
一篇國外的熱門文章，關於一些開源選擇方案，翻譯出來給大家參考。 - Medusa vs. Shopify - Postman vs. Hopscotch - Slack vs. Rocket Chat - Google Chrome vs. Brave - n8n vs. Zapier - Webflow/Framer vs. Webiny - Bit.ly vs. Dub.co - Calendly vs. Cal.com - Airtable vs. NocoDB 原文出處：https://dev.to/rigdev/10-open-source-alternatives-to-proprietary-software-34lb --- ##Medusa：Shopify 的替代方案  您可能聽說過 Shopify，它是遊戲中的大玩家。但現在有一個新的競爭者：美杜莎。讓我們來分析一下這兩者的優點、缺點以及本質。 ###Medusa 與 Shopify 相比的優點： **按你的方式做**：Medusa 是開源的，這意味著您可以根據自己的喜好對其進行調整。想要一個霓虹粉紅結帳按鈕嗎？大膽試試吧！ **保留您的現金**：與 Shopify 不同的是，除非您使用他們的支付系統，否則 Shopify 會奪走您的部分銷售額，而 Medusa 不會動用您的口袋。 **選擇你的家**：透過 Medusa，你可以決定在哪裡開設你的商店。這就像在租公寓還是建造自己的房子之間做出選擇。 **權力歸於人民**：美杜莎受到社區的愛戴。這意味著定期更新、酷炫的新功能以及一群隨時準備提供幫助的人。 **沒有秘密**：開源意味著您可以看到幕後發生的一切。 ###Medusa 與 Shopify 相比的缺點： **開箱即用**：Shopify 擁有大量內建功能和龐大的應用程式商店。美杜莎在這方面仍在迎頭趕上。 **減少 DIY**：使用 Shopify，許多技術問題都會為您處理。美杜莎？您坐在駕駛座上，但這意味著您也必須應對道路上的顛簸。 **名言**：每個人都知道 Shopify。美杜莎仍然是學校裡的新生。 ###結論： 在 Medusa 和 Shopify 之間進行選擇可以歸結為您的特定需求和技術專長。如果您重視靈活性、客製化和成本控制，Medusa 是令人信服的選擇。然而，如果您正在尋找一個擁有良好記錄、廣泛內建功能和強大支援的平台，Shopify 仍然是一個強大的競爭者。 ##Hopscotch：郵差的替代方案  您可能聽過 Postman，它是 API 測試領域的大人物。但有一個開源挑戰者踏入了這個圈子：Hopscotch。 ###Hopscotch 與 Postman 相比的優點： **像鳥一樣自由**：作為開源軟體，Hopscotch 不會花費您一毛錢。對於關注預算的小型團隊或個人開發人員來說，這可能是一個巨大的勝利。 **社群氛圍**：像 Hopscotch 這樣的開源工具依靠社群的投入而蓬勃發展。這意味著您有一群充滿熱情的人不斷改進它並加入很酷的新功能。 **透明度**：對於 Hopscotch，不存在任何幕後謎團。您可以看到每一行程式碼，確保您確切知道發生了什麼。 **輕量級**：Hopscotch 往往比 Postman 更輕量級，如果您正在尋找資源密集程度較低的東西，這可能是一個優勢。 **豐富的客製化**：由於是開源的，如果缺少您需要的功能，您可以自行加入或召集社群來提供協助。 ###Hopscotch 與 Postman 相比的缺點： **功能豐富**：Postman 已經廣泛存在並擁有大量內建功能。它就像是 API 測試的瑞士軍刀。 **流暢的使用者介面**：Postman 的使用者介面精美且直觀，讓新手可以輕鬆上手。 **協作功能**：透過其團隊協作工具，Postman 讓團隊可以輕鬆地協同工作、共享集合並保持所有內容同步。 **廣泛的文件**：Postman 參與遊戲已經有一段時間了，因此他們建立了一個龐大的教程、指南和社區帖子庫來幫助您。 **整合生態系統**：Postman 提供與各種其他工具的集成，使其更容易融入現有工作流程。 如果您熱衷於開源，喜歡修補，並且正在尋找一個輕量級工具，那麼 Hopscotch 可能是您最好的新朋友。但如果您想要一個功能豐富且擁有良好記錄的環境，並且不介意花一些錢購買高級功能，那麼 Postman 仍然是一個不錯的選擇。像往常一樣，關鍵是找到適合您需求的工具。 ##Rocket Chat：Slack 替代方案  當談到團隊溝通工具時，Slack 一直是許多人的首選。但等一下，擂台上有個開源挑戰者：Rocket.Chat。讓我們透過簡單地了解 Rocket.Chat 與 Slack 相比的三個優缺點來分解這兩者的比較。 ###為什麼 Rocket.Chat 可能會震撼您的世界： **調整和調整**：Rocket.Chat 是開源的，這意味著如果有您不喜歡的東西或您認為可以更好的東西，您（或您的技術團隊）可以參與並自訂它。您的 Rocket.Chat 可以像您團隊最喜歡的內部笑話一樣獨特。 **錢包友好**：使用 Rocket.Chat，您可以避免 Slack 等高級版本專有軟體帶來的一些討厭的費用。此外，由於是自託管，您可以更好地控制未來潛在的價格上漲。 **您的資料，您的規則**：在您自己的伺服器上託管 Rocket.Chat 意味著您可以完全控制您的資料。無需擔心第三方存取或資料儲存位置。 ###Slack 仍可能佔上風的地方： **即插即用**：Slack 以其用戶友好的介面和易於設定而聞名。對於那些不懂科技的人來說，Slack 的簡單方法可能是一件幸事。 **整合**：Slack 一直處於領先地位，擁有龐大的應用程式整合庫。無論是 Trello、Google Drive，還是您的團隊離不開的小眾工具，Slack 都可能提供了整合。 **酷兒童俱樂部**：Slack 的受歡迎意味著許多人已經熟悉它。如果新團隊成員之前已經使用過 Slack，那麼新團隊成員的入職或與合作夥伴的協作可能會更順利。 ###結論： Rocket.Chat 提供了一個無與倫比的客製化、成本節約和資料控制的世界。但如果您正在尋找無憂無慮的設置、大量的整合以及廣泛的熟悉度，Slack 仍然可以滿足您的需求。一如既往，最好的選擇取決於您的團隊最重視的是什麼！ ##Brave：Google Chrome 的替代品  就網頁瀏覽器而言，Google瀏覽器在相當長一段時間內一直是衛冕冠軍。但有一個新的競爭者正在引起轟動：Brave。 Brave 建構於與 Chrome 相同的 Chromium 引擎之上，承諾提供不同類型的瀏覽體驗。 ###Brave 與 Google Chrome 相比的優點： **隱私第一**：Brave 非常重視隱私。它可以立即阻止第三方廣告和追蹤器，這意味著您不必擺弄設定或加入擴充功能來阻止公司在網路上追蹤您。 **速度惡魔**：由於其廣告攔截功能，Brave 通常加載頁面的速度比 Chrome 更快。更少的廣告和追蹤器意味著更少的下載資料，讓您的瀏覽體驗更快捷。 **衝浪獲得報酬**：Brave 有一個獨特的功能，稱為 Brave 獎勵。選擇尊重隱私的廣告，您可以獲得 BAT（基本注意力代幣），您可以將其保留或作為小費提供給您最喜歡的網站。 Chrome 不提供類似的功能。 ###Brave 與 Google Chrome 相比的缺點： **豐富的擴充功能**：Chrome 的網路應用程式商店是擴充功能和應用程式的寶庫。雖然 Brave 是基於 Chromium 引擎建置的，因此能夠安裝所有 Chrome 擴充程序，但由於某些擴充功能非常注重隱私和廣告攔截，因此可能會出現相容性問題。 **Google 生態系統**：如果您已經投資於 Google 領域（例如 Google 雲端硬碟、Google 照片、Google Meet），那麼 Chrome 可以與這些服務無縫整合。 Brave 可以存取它們，但不太順利。 **穩定可靠**：Chrome 已經存在多年，並且在穩定性和性能方面擁有良好的記錄。 Brave 比較新，雖然很強大，但還沒有足夠的時間來解決所有的問題。 ###結論： 如果您重視隱私，並且喜歡更快、更有價值的瀏覽體驗，那麼 Brave 可能會改變您的遊戲規則。但如果您是 Chrome 擴充功能的重度用戶或深入 Google 生態系統，那麼 Chrome 可能仍然是您的最佳選擇。 ##n8n 與 Zapier：自動化競技場  在工作流程自動化領域，Zapier 長期以來一直是家喻戶曉的名字，它幫助企業和個人連接他們最喜歡的應用程式並自動化任務。進入 n8n，這是一個開源替代方案，以其獨特的方法而引人注目。讓我們深入了解 n8n 如何與 Zapier 進行比較。 ###n8n 與 Zapier 相比的優點： **客製化之王**：n8n 是開源的，提供無與倫比的客製化功能。如果您需要特定的功能或集成，您可以自行建立或利用社群來取得協助。這種程度的彈性是 Zapier 等專有平台無法比擬的。 **成本效益**：n8n 可以自架，這意味著您可以節省大量成本，尤其是在執行大量工作流程時。使用 Zapier，隨著您的需求成長，訂閱成本也會隨之增加。 **資料隱私**：透過 n8n 的自架選項，您可以完全控制您的資料。它保留在您的伺服器上，確保您確切知道它在哪裡以及誰有權存取。這與 Zapier 等基於雲端的解決方案形成鮮明對比，後者的資料是在外部伺服器上處理的。 ###n8n 與 Zapier 相比的缺點： **使用者友好**：Zapier 以其直覺的介面而聞名，即使是非技術人員也可以輕鬆設定和管理工作流程。 n8n 以其更面向開發人員的方法，對某些人來說可能有更陡峭的學習曲線。 **海量整合庫**：Zapier 擁有超過 3,000 個應用程式整合。雖然 n8n 的清單正在快速增長，但它尚未達到與 Zapier 一樣廣泛的開箱即用整合數量。 **可靠性和支援**：憑藉其成熟的影響力，Zapier 提供強大的可靠性和專門的支援團隊。雖然 n8n 擁有一個充滿熱情的社區，但它可能無法提供與 Zapier 這樣的成熟平台相同程度的即時、專業支援。 ###結論： n8n 提供了一個客製化、節省成本和資料控制的世界，對於那些習慣更實際操作方法的人來說，這是很難擊敗的。然而，如果您正在尋找一個具有大量即用型整合、用戶友好介面和專門支援的平台，Zapier 仍然是一個強大的選擇。您的理想選擇將取決於您的特定需求和技術舒適度。 ##Webiny：Webflow 和 Framer 的替代方案  在網頁設計和開發領域，Webflow 和 Framer 等工具因提供直覺的介面和強大的設計功能而聞名。但鎮上出現了一個新的開源玩家：Webiny。 ###Webiny 與 Webflow 和 Framer 相比的優點： **開源彈性**：Webiny 的開源性質意味著您可以根據自己的喜好進行自訂。如果您需要某種功能或集成，您將不會受到專有約束的限制。這種程度的適應性是像 Webflow 和 Framer 這樣的專有平台無法完全匹敵的。 **成本考量**：從長遠來看，Webiny 更具成本效益，特別是對於較大的專案或企業。雖然 Webflow 和 Framer 需要付費，但 Webiny 的開源模型可以節省大量成本，特別是在考慮自架網站時。 **完全控制資料**：透過 Webiny，您可以選擇自行託管，從而完全控制資料及其安全性。這與 Webflow 和 Framer 等基於雲端的解決方案形成鮮明對比，在這些解決方案中，您的資料駐留在外部伺服器上。 ###Webiny 與 Webflow 和 Framer 相比的缺點： **直覺的設計介面**：Webflow 和 Framer 都以其用戶友好的設計介面而聞名。它們提供拖放功能和視覺設計工具，使設計人員即使沒有深厚的編碼知識，也可以輕鬆地將他們的願景變為現實。 Webiny 雖然功能強大，但對於純粹的設計師來說可能有更陡峭的學習曲線。 **豐富的範本和元件庫**：Webflow 和 Framer 附帶豐富的範本、元件和動畫庫。這可以顯著加快設計過程。 Webiny 較新，可能無法提供同樣廣泛的即用型設計元素。 **社群與支援**：Webflow 和 Framer 擁有大型、成熟的社群和專門的支援團隊。這意味著有大量的教程、論壇和資源可供使用。 Webiny 是新出現的，仍在發展其社區和支援基礎設施。 ###結論 Webiny 提供了一個引人注目的開源替代方案，具有客製化功能、潛在的成本節約和資料控制。然而，對於優先考慮直覺設計介面、大量設計元素和成熟社群支援的人來說，Webflow 和 Framer 的綜合優勢仍然難以超越。 ##Penpot：Figma 的替代品  在設計界，Figma 因其協作功能和時尚的介面而受到青睞。但有一個開源競爭者走進了聚光燈下：Penpot。 ###Penpot 與 Figma 相比的優點： **開源優勢**：Penpot 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化，而 Figma 等專有平台可能無法提供。 **無成本障礙**：Penpot 是開源的，可以免費使用。雖然 Figma 提供免費套餐，但高級功能和更大規模的團隊協作需要付費訂閱。使用 Penpot，您可以存取所有功能，而無需擔心訂閱費用。 **用於資料控制的自託管**：Penpot 使您可以選擇在自己的伺服器上託管。這意味著您可以完全控制資料、資料的安全性以及資料的儲存位置，這是 Figma 的純雲端模型所不具備的功能。 ###Penpot 與 Figma 相比的缺點： **成熟的生態系統**：Figma 存在的時間更長，並且擁有更成熟的生態系統。這包括一個龐大的插件庫、整合庫和社群貢獻的資源，可以增強設計過程。 **即時協作**：Figma 的突出功能之一是無縫即時協作。多個設計師可以同時處理一個專案並進行即時更新。雖然 Penpot 提供協作功能，但它可能不如 Figma 的那麼精緻。 **性能和可靠性**：Figma 的性能，尤其是複雜的設計和原型，是強大且可靠的。作為一種較新的工具，Penpot 仍在完善其性能並消除任何問題。 ###結論 Penpot 為設計工具領域提供了全新的開源視角，其成本效益和資料控制對許多人來說都很有吸引力。然而，對於那些看重龐大生態系統、即時協作和經過驗證的性能的人來說，Figma 仍然是一個強大的選擇。 ##Dub.co：Bit.ly 的替代方案  Bit.ly 已成為許多用戶的主要內容。然而，開源社群提出了另一種選擇：Dub.co。 ###Dub.co 與 Bit.ly 相比的優點： **開源彈性**：Dub.co 的開源性質意味著它在社群的貢獻下不斷發展。這允許一定程度的適應性和客製化，而 Bit.ly 等專有平台可能無法提供。 **成本考慮**：Dub.co 是開源的，可以免費使用。雖然 Bit.ly 提供免費套餐，但其高級功能和分析功能價格昂貴。透過 Dub.co，您可以存取所有功能，而無需擔心訂閱費用。 **資料隱私和自架**：Dub.co 為您提供在自己的伺服器上託管的選項。這意味著您可以完全控制您的資料、資料的安全性以及資料的儲存位置，這是 Bit.ly 的純雲端模型所不具備的功能。 ###Dub.co 與 Bit.ly 相比的缺點： **已建立的聲譽**：Bit.ly 已經存在很長時間了，並在可靠性和性能方面建立了聲譽。這種長期存在意味著許多用戶信任並熟悉其服務。 **廣泛的集成選項**：Bit.ly 提供與其他平台和行銷工具的廣泛集成，使企業可以更輕鬆地將連結管理納入其現有工作流程。 **用戶友好的介面**：Bit.ly 以其直覺的介面而聞名，使用戶可以輕鬆建立、管理和分析其縮短的連結。雖然 Dub.co 提供了一個強大的平台，但新手可能會發現 Bit.ly 的介面更加簡單。 ###結論： Dub.co 為連結管理提供了全新的開源視角，提供客製化、成本效益和增強的資料控制。然而，對於那些重視具有大量整合和易於使用介面的久經考驗的平台的人來說，Bit.ly 仍然是一個不錯的選擇。您理想的工具將取決於您的特定需求以及您如何優先考慮功能。 ##Cal.com：日曆的替代方案  在安排會議和約會時，Calendly 一直是許多人的首選平台。但有一個新的開源替代方案引起了人們的注意：Cal.com。 ###Cal.com 與 Calendly 相比的優點： **開源彈性**：Cal.com 是開源的，這意味著您可以對其進行自訂以滿足您的特定需求。無論是加入獨特的功能還是與其他工具集成，您都可以自由地打造自己的功能。這是 Calendly 作為專有平台無法提供的。 **成本效益**：Cal.com 對個人免費，並且是開源的，您可以自行託管它以避免訂閱費用。另一方面，Calendly 有免費套餐，但僅限於一種活動類型，並且缺乏一些高級功能，除非您升級到付費計劃。 **資料隱私**：透過自行託管選項，Cal.com 讓您可以完全控制自己的資料。您確切地知道它的儲存位置以及誰可以存取它，而 Calendly 的基於雲端的模型則不然。 ###Cal.com 與 Calendly 相比的缺點： **使用者體驗**：Calendly 已經存在了一段時間，並且擁有精美、用戶友好的介面。即使對於那些不懂技術的人來說，設定和管理約會也很容易。 Cal.com 較新，可能有更陡峭的學習曲線。 **整合選項**：Calendly 提供與 Google 日曆、Office 365 和 Zoom 等流行平台的廣泛整合。雖然 Cal.com 正在努力擴展其整合選項，但尚未達到與 Calendly 相同的水平。 **社群與支援**：Calendly 擁有龐大的用戶群，並提供強大的客戶支持，包括豐富的教學和資源。 Cal.com 作為一個較新的開源平台，更依賴社群支持，但社群支持可能不那麼直接或廣泛。 ###結論： 如果您熱衷於嘗試新事物、喜歡優質的免費贈品並重視保持資料的私密性，請嘗試 Cal.com。但如果您想要一個久經考驗、易於使用且擁有可靠支援的工具，Calendly 仍然是一個不錯的選擇。 ##NocoDB：Airtable 替代方案  您可能已經看過 Airtable，它具有豐富多彩的網格和簡單的拖放氛圍。但有一個新來者正在引起一些轟動：NocoDB。讓我們來分解一下這兩者是如何疊加的。 ###NocoDB 與 Airtable 相比的優點： **開源優點**：NocoDB 是開源的，這意味著您可以根據自己的喜好調整、扭曲和自訂它。另外，您還可以從不斷改進它的社區中受益。空中桌？這很酷，但它並沒有給你那種程度的自由。 **錢包友善**：使用 NocoDB，您可以透過自己託管來避免這些月費。 Airtable 有免費套餐，但如果您想要更多記錄、檢視或精美功能，則需要花費一些現金。 **您的資料，您的規則**：由於您可以自行託管 NocoDB，因此在資料方面您處於主導地位。您可以決定它的儲存位置以及誰可以查看它。使用 Airtable，您的資料將掛在他們的伺服器上。 ###NocoDB 與 Airtable 相比的缺點： **使用者友善的氛圍**：Airtable 超級直覺。它的介面很乾淨，設定基地感覺輕而易舉。 NocoDB 比較新，可能需要更多時間來適應。 **模板寶庫**：Airtable 有大量模板。無論您是計劃活動、追蹤庫存還是管理專案，都可能有一個模板。 NocoDB 仍在建立其集合。 **內建整合**：Airtable 與其他應用程式配合得很好，提供了一系列與流行應用程式的內建整合。雖然 NocoDB 正在擴展其整合遊戲，但尚未達到 Airtable 的水平。 如果您是開源愛好者，喜歡控制資料，並且希望節省一些錢，那麼 NocoDB 可能正合您的胃口。但是，如果您正在尋找超級用戶友好、具有豐富模板庫並且可以輕鬆與其他應用程式連接的工具，那麼 Airtable 仍然很強大。 ##大結論 在不斷發展的數位工具世界中，老牌巨頭和創新的新來者之間始終需要保持平衡。無論是設計平台、調度工具或資料庫系統，每個平台都有其獨特的優點和潛在的缺點。 Penpot、Cal.com、NocoDB 等開源替代方案帶來了無與倫比的客製化、成本節約和資料控制。另一方面，Figma、Calendly 和 Airtable 等老牌廠商提供用戶友好的介面、廣泛的整合選項以及隨著時間的推移和改進而帶來的可靠性。 ##誰說你必須選邊站隊？ 當今技術生態系統的美妙之處在於您可以混合搭配。使用開源工具完成一項任務，使用專有工具完成另一項任務。這就像擁有一把瑞士軍刀和一個專門的工具包。您將獲得兩全其美的效果。 例如，您可能喜歡根據資料庫需求自訂 NocoDB，但更喜歡使用 Calendly 進行排程的無縫整合。或者也許 Penpot 的開源靈活性吸引了您的設計方，而 Slack 的可靠性則讓您的團隊溝通順暢。 關鍵是，你並沒有被歸類。這一切都是為了找到適合工作的工具，有時，這意味著將開源精神與專有軟體的精美體驗相結合。 因此，當您冒險進入科技領域時，請記住：這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克！
阿川收到網友提問如下： > 阿川你好： > 我的背景是雲科碩畢業，算是混上去的，現在打算轉職軟工，由於有在工作，所以打算先以自學為主3-6個月，看情況後決定是否報名資策會。 > 想請問一下，目前比較希望能夠走後端（網頁開發類），查了一些相關資訊，網頁似乎比較友善，未來有機會再往其他產業前進！ > 搜尋了一下職務，網頁類的後端其實也需要html css js 前端三本柱。 > 我想問的是： > 1.是否直接開始學三本柱比較好？（反正前面的作品、入職也會需要）且 有了js基礎還能繼續學習node.js（後端）。 不過又礙於可能比較沒方向，會變成說學一學越來越往前端過去？ > 2.先以門檻較低的前端入門、入職以後再好好思考想專精哪一端之類的 or 以c#為主學習，再慢慢學三本柱，資料庫等等 > 3.前端的切版技術等等，是否真的必要？ 本人美感很差.. 兩個問題的考量的都是想說是否先以java,c#等後端去建立程式概念或許比較好。 > 文有點長，再麻煩您給我一些建議了，也想順便問一下，有看到您有提供免費html css 以及付費js課程，能在跟您要這方面的資訊嗎？ 這些問題很好，我一樣公開回答，給類似狀況的人參考。 --- 簡單回答如下： 1、不論前後端 html 跟 css 都要會，所以這兩個可以先學。js 的話後端不用學精，稍微會寫就好，除非你是寫 node 至於最後會去前端或後端的職缺，都可以，先不用擔心這個，不然你就找全端的職缺也可以 2、後端需要學資料庫、基本伺服器管理，語言的話 C# 或 java 或 php 或 python 或 node 之類的都可以 3、前端做久了，因為常常跟設計師合作，會慢慢具備一點設計素養。如果對「UI 設計」有興趣是最好，沒有的話，倒也沒關係。美感可以慢慢訓練，先不用畫地自限 --- 總結來說，我建議你就先學 html 與 css，之後再看你用 html css 把網頁寫漂亮有沒有興趣，如果喜歡把畫面弄漂亮，就多學一點前端。如果只想做工程，就專心在後端吧。這些問題學了 html css 之後會更清楚，先不用太糾結。不然你就以全端為方向也可以，前後端都寫！你就先挑一個免費 or 便宜的線上課程，先開始寫寫看再說 先開始行動，會更清楚自己在做什麼，之後需要花大錢去報名補習班時，也會比較有把握 就算你一開始只寫前 or 後端，很多人上班之後，因為工作需求，還是慢慢有具備全端的技能 其實不用太排斥全端，都寫的話，一來在公司能做的事情變多、能應徵的機會變多，二來還可以自己用業餘時間寫 side project，因為一個人就能做完全部事情，所以會很好玩，也對職業生涯很有幫助 關於我設計的免費 html css 教材，請參考：https://codelove.tw/courses/frontend-beginner 另外，轉職過程會有諸多問題，可以加我們 LINE 群多跟大家討論：https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g --- 以上，簡單分享，希望對大家有幫助！
## 課程目標 - 認識 callback hell 與錯誤處理 ## 課程內容 在非同步訓練一的課程，我們初步體驗到 callback hell 寫起來的感覺 其實，當年的工程師，面對的真正痛苦，比上次體驗到的更嚴重！ 非同步任務，常常需要處理「任務失敗」的情況 比方說「主機回應超時」、「資料庫連線失敗」、「主機斷線」等等情況 按照 javascript 的慣例，就是多寫一個 callback function 處理這種情況 比方說函式可以設計成這樣 ``` runAsyncTask(success, error) ``` 使用者只要分別傳進「成功後的處理」以及「失敗後的處理」即可 ``` runAsyncTask(() => { alert('執行成功！'); }, () => { alert('執行失敗，請等等重新嘗試！'); }); ``` 如果繼續拿 jquery 做範例，看起來會像這樣： ``` $.ajax({ url: url, data: params, success: (res) => {}, error: (res) => {}, }); ``` 註1：他不是設計成兩個參數，而是物件的兩個屬性，但意思一樣 註2：沒辦法繼續用上次的 `$.get()`，他沒有設計錯誤處理的 callback。所以改用 `$.ajax()` 光看這樣可能還好，畢竟寫 javascript 就是很常到處寫 callback 傳來傳去 可是，你能想像連續呼叫多個 ajax 時，再加上錯誤處理機制，callback hell 會有多嚴重嗎！ 來跟著作業，體驗一下，試著用當年的方式開發看看吧！ ## 課後作業 這一次的作業，我們要延續「非同步 JS 訓練一：第1課」的內容，並且加上錯誤處理 https://codelove.tw/@howtomakeaturn/post/lqOkWq 請找出你上次寫的作業，把上次的三組 API，換成以下這三組 ``` https://codelove.tw/fake-api/get-current-user-unstable ``` ``` https://codelove.tw/fake-api/get-orders-unstable ``` ``` https://codelove.tw/fake-api/get-order-details-unstable ``` 這三組 API 很不穩定，每組 API 都有 1/3 的機率會抓資料失敗！ 實務上不可能有 API 爛成這樣，通常失敗率會在 1% 以下，這次是方便測試，我故意寫的 API --- 幾點注意事項如下： - 不要使用現代的非同步寫法，請使用 callback hell 的寫法 - 使用 `$.ajax()` 來呼叫 API - 使用 `$.ajax()` 的 `success` 參數來處理成功的情況 - 使用 `$.ajax()` 的 `error` 參數來處理失敗的情況 - 第一個 API 失敗時，請 `alert('讀取用戶失敗，請稍後再試一次。');` - 第二個 API 失敗時，請 `alert('讀取訂單列表失敗，請稍後再試一次。');` - 第三個 API 失敗時，請 `alert('讀取訂單細節失敗，請稍後再試一次。');` 寫完之後，你應該會看到有三層深度的巢狀 callback 傳遞！ 而且比上次的情況還離譜！加上錯誤處理之後，整段 code 更加難以閱讀、維護！ 這就是當年前端工程師，每天工作面臨的狀況！很悲慘吧！ 做出以上功能，你就完成這次的課程目標了！
租用了新的雲端主機，有一天發現全部線上網站都掛了 經檢查發現是硬碟被吃光了，但是我應該沒有存那麼多資料＆圖片才對 使用指令慢慢檢查根目錄，在查到 var 時 ``` du -sh /var ``` 發現是 var 資料夾佔用了 125 GB，顯然問題就在這裡 接著使用 ``` du -h /var ``` 發現疑似是 mysql 資料夾，佔用大量硬碟空間 繼續使用指令確認 ``` du -sh /var/lib/mysql ``` 以及查看細節 ``` du -h /var/lib/mysql ``` 發現就是這個資料夾沒錯，cd 進去 ls 看一下，看到大量的 binlog 檔案，命名類似這樣 ``` ... binlog.000738 binlog.000739 binlog.000740 ... ``` 經研究，是 mysql 某種備份機制，暫時不深入研究，我目前不想使用這個備份功能 --- 輸入以下 SQL 緊急移除這些備份 ``` PURGE BINARY LOGS BEFORE NOW(); ``` 硬碟緊急狀況排除！ --- 接著要避免之後再出現這個問題 參考這篇做法 https://askubuntu.com/questions/1322041/how-to-solve-increasing-size-of-mysql-binlog-files-problem 建立獨立檔案，方便日後維護 ``` touch /etc/mysql/mysql.conf.d/howtomakeaturn.cnf ``` 放入以下內容 ``` # Added by howtomakeaturn at 2023-08-15 because of 100% disk usage issue. [mysqld] log_bin = # turn off binlog_expire_logs_seconds = 86400 # 1 day max_binlog_size = 104857600 # 100M ``` 完成之後重啟資料庫 ``` service mysql restart ``` 大功告成！應該大致關閉 binlog 功能了，持續觀察幾天看看！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆新手在討論： 如果前端要銜接後端的話，是不是學 node.js 比較快？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 首先，我很推薦新手前端也去學一點後端，這樣對整體概念會更清楚 這位網友提到的 node.js 很不錯，但是我更推薦去學 php，簡單幾個原因說明如下 # 無框架開發 常見的後端語言，在寫網站時，都需要套件＆框架才能開發 - python 需要 django - ruby 需要 rails - java 需要 spring - node 需要 express 我建議你直接寫 php 做好玩的小網站，不要用框架 php 雖然現在都用 laravel 框架，但古早時代大家都寫純 php 如果現在只是自己做個小專案，當然寫純 php 也是夠用的 學框架沒什麼不好，但是，在新手一開始的階段，我更推薦從單純的東西開始學起 一來上手很快，二來等於是紮穩馬步，三來之後學框架可以去思考：如何用純 php 語言寫出框架元件 如果自己想補充後端知識，就試試純 php 吧！先別學 laravel，晚點再去學就好 # 後端先避免非同步程式設計 這件事比較 tricky，javascript 語言本身支援非同步，這在前端 UI 處理很好用 也就是常用的 async/await，`.then().then().then()` 或者到處傳 callback function 那些的 但是！我認為在寫後端的時候，這個語言特色會讓後端開發時，顯得有點囉唆 以後端讀取檔案內容來說，絕大多數情況下，你就是要現在就讀取好檔案、讀取完才讓程式接著繼續跑，才有意義 幾乎不存在「非同步去讀取檔案，不等結果，先直接去處理別的任務」這種情況 於是 node 後端程式碼就需要去傳 callback function 或者 async/await 我認為這有點囉唆，這些情境實在沒必要用「非同步程式設計」處理！ node 社群自己也知道，所以除了 `fs.readFile` 之外，還有提供 `fs.readFileSync` 函式 作為一個教育者，我很不喜歡跟新手解釋，為甚麼會有這兩種函式，差異在哪 我認為新手後端，多去學非同步程式設計的觀念與技巧，是徒增挫折 用 python/php/ruby/java 寫後端，都不會遇到這個困擾 新手後端就學好 http 協定，GET 跟 POST 參數是怎麼傳遞的，怎麼使用 session，怎麼連接資料庫就好了 不要多被一個 asynchronous programming 困擾 # 多學一個程式語言 本身是前端工程師，再去學後端想用 node 繼續寫 javascript 當然很合理 不過，長遠來說，多學幾種程式語言，對職業生涯比較健康 首先，你會更有自信一點，並且，能夠開始比較各種程式語言的差異與哲學 很多在 A 語言理所當然的事情，在 B 語言是很罕見的 很多在 A 語言社群大家都說「對」的事情，在 B 語言社群大家都說「錯」 長遠職業生涯來說，你需要至少寫過多種程式語言，才會發現大多數事情都只是「不同社群」的「主觀偏好」 你會發現網路上多數講的斬釘截鐵的對錯觀念，都只是一種偏執。你的觀點會更全面 # 結論 以這位網友的狀況來說，本身是前端，其實，學 nodejs 或 php 都不錯啦 我個人是偏好 php > nodejs 一點，這樣 以上，簡單分享，希望對類似狀況的朋友有幫助！
昨天在我們新手寫程式 LINE 群組，有幾個業界工程師＆剛轉職的新手在討論： 我是新手前端，公司叫我學一點 php + laravel 串 API，該從哪邊學起呢？ https://line.me/ti/g2/nipkjq2WoZPKX5dTn9tE9266aEOt6EOICFGa1g 這主題很好，我決定單獨寫一篇文章討論這件事情 --- 我猜你面臨的情況，老闆不是真的叫你從無到有寫後端，應該是去硬改現成的後端專案 因為是公司馬上需要的，先求速成為主，背後細節就先別管了 就分幾個步驟來做吧 # Step 1 laravel 官網 `Installation` 章節讀一讀，然後看你用什麼作業系統，網路上 laravel 安裝教學找幾份試試看 先想辦法把環境跑起來，讓目前專案可以在電腦上跑 然後找一款有 GUI（圖形化介面）的資料庫管理軟體，在 UI 上點一點，準備好資料庫 # Step 2 `Routing` `Controllers` `Requests` `Responses` 這幾個章節讀一讀 至少稍微看懂，後端是哪些地方在接收參數、回應參數 # Step 3 把 `Eloquent ORM` 章節讀一讀，這個類別提供很多神奇的方法，很輕易就能做到 CRUD 至少稍微看懂，後端是哪些地方在跟資料庫互動，自己有辦法新增資料、更新資料、刪除資料這樣 --- 除此之外，上網找幾份 laravel 的簡易 CRUD 範例教學，不太懂背後原理沒關係，按照指示，做個部落格之類的 然後就去硬改公司現成的後端專案，頂著用，不然短期內也沒辦法真的學精 laravel，就先這樣吧！先能滿足公司需求就好！ 其實，以上所說，真的是很混的學習方法：ORM 背後的觀念、資料庫的 SQL 觀念，幾乎都沒學到 長遠來說，如果是真的要學 php + laravel 後端，我都是建議先從「純 php + mysql」開始學起 也就是我鼓勵新手用純 php 寫一個部落格網站，寫純 SQL 去連接資料庫，先搞懂這種最純粹的寫法 然後再開始學 laravel 以及 ORM 等等好用套件工具 不然的話，我知道很多人直接從 laravel 開始寫起，半知半解，工作很久了，卻連哪些功能是 php 提供的，哪些是 laravel 提供的都分不出來 然後在需要換框架 比如 CodeIgniter 或者 Yii 的時候，很多觀念無法融會貫通，長遠來說，根本事半功倍 --- 話說回來，如果老闆不是叫你硬改現成的後端專案，而是叫你從無到有寫後端 那這工作內容實在不太合理，除非你一開始應徵的就是「全端工程師」的職缺＆薪資 以上，簡單幾個方向分享，希望對你有點幫助！
簡單複習一下，在這次的課程中，我們學會了 - 用 express 處理 http get 請求 - 用 express 處理 http post 請求 - 用 express 提供靜態檔案 - 取得 url 參數 - 取得表單參數 是不是很有趣呢？ --- 再次說明，這次的課程主要是學習網頁協定＆基本觀念，實務上後端開發有很多東西要學 舉例來說，下面這些東西本課程都省略了： - ejs 模板的 layout 功能 - 連接資料庫軟體 - 會員系統、註冊登入、驗證功能 雖然省略了很多東西，但我認為已經能讓你對於 http 協定與後端開發，有大致的了解 因此基本功比一般的前端開發者更好！這也是本課的目的所在！ 很多前端工程師，工作了好一陣子，卻還是搞不清某些觀念、任務屬於前端還是後端！要避免這種混淆，職業發展才能順利又有效率！ 後面的課程，我會進一步教你清楚認識前端、後端的區別、以及釐清一些常見迷思！讓你在前端之路上，走得更順遂！ --- 消化、研究完本課程之後，請接著前往下一份教材，繼續邁向資深之路吧！ **教材研發中，敬請期待**
## 課程目標 - 使用 node 與 express 回應 http post request ## 課程內容 前面幾課我們學習了 http get 的寫法，這次來學 http post 的寫法 在「會更新主機資料狀態」的操作時，通常都會用 http post 例如，新增資料、更新資料、刪除資料，等等常見操作！ 通常主機資料狀態會放在「資料庫軟體」例如 mysql 裡面，我們簡單起見，放在一個 json 檔案就好！ --- 替這課建立 lesson6 資料夾，內容跟 lesson5 一樣即可 新增一個 new.ejs 檔案，放入以下內容 ``` <h1>新同學報到！</h1> <form method="post" action="/create"> name: <input type="text" name="name"> </form> ``` 然後在 index.js 加入這段程式碼 ``` const bodyParser = require('body-parser'); app.use(bodyParser.urlencoded({ extended: true })); app.get('/new', function(req, res){ res.render('new'); }); app.post('/create', (req, res) => { const fs = require('fs'); const name = req.body.name; const data = fs.readFileSync('./lesson6/users.json'); const users = JSON.parse(data); users.push({ name: name }); fs.writeFileSync('./lesson6/users.json', JSON.stringify(users)); res.send('<h1>新增成功！</h1>'); }) ``` 然後去終端機輸入 ``` node lesson6/index.js ``` 接著打開瀏覽器，在網址輸入 ``` http://localhost:3000/new ``` 你會看到新增同學的頁面與表單！ 輸入姓名之後，送出表單就可以新增同學的資料了！ --- 開頭跟 bodyParser 有關的兩行，要引入並設定好，才能使用 req.body 的參數 為什麼要加這兩行？這跟 express 的 middleware 機制設計有關，這邊不深入說明 反正就是在需要使用某些功能的時候，express 不會預設通通提供給你，要請你去設定啟用之後，才會支援 --- 之前處理 http get 的 url 參數時，我們使用 req.query 來取得參數 這次處理 http post 的表單參數時，我們使用 req.body 來取得參數 express 會這樣設計，是因為在 http 協定中，這兩種參數本來就放在不同地方喔！ 看不太懂沒關係，先照做就對了！ --- 檔案處理、新增資料放進 json 檔案的段落，跟之前的課程一樣，忘記的話就回頭翻閱一下吧！ ## 課後作業 這次要開發「新增文章」的功能 並且練習用 node 回應 http post request 請把 hw5 的內容複製到 hw6，然後增加 new.ejs 檔案 ``` /repo /hw6 /index.js /homepage.ejs /view.ejs /new.ejs /posts.json /public /style.css ``` 接著修改主程式 index.js 的內容，讓網站能夠回應 `/new` 這個網址 這網址會把 new.ejs 的內容 render 出來，內容就放一個 form 表單 表單內可輸入 `標題` 以及 `文章內容`，點擊送出按鈕會以 http post 的形式發送到 `/create` 接著修改主程式 index.js 的內容，讓網站能夠回應 `/create` 這個網址 將接收到的資料，存進 `posts.json` 裡面 完成以上任務，你就完成這次的課程目標了！ --- 在上傳到 github 時，你會注意到因為 `posts.json` 有改變，所以會帶著新資料一起上傳，好像有點怪？ 其實，實務上會把資料存在 mysql 這類專門資料庫軟體，不會這樣存在 json 檔案中 本課程為了簡化，所以直接存在 json 檔案，這不是實務正常做法～ 為了方便起見，每次新增文章 `posts.json` 都會改變，就都一起上傳，沒關係～
開源對很多事情都非常有用。其中之一是學習新技能。在本文中，我們將介紹 GitHub 上一些最好的開源 React 專案，您可以使用它們來快速提升您的 React 技能。 原文出處：https://dev.to/livecycle/top-github-repositories-to-learn-modern-react-development-5d3h ## 你可以學習的開源 React 專案  ## Cal.com  [https://github.com/calcom/cal.com](https://github.com/calcom/cal.com) Cal.com 將自己標榜為“絕對適合所有人的日程安排基礎設施”。他們是 Calendly 等預約安排服務的競爭對手。他們同時提供託管和自託管產品。它是一個全棧 Next.js 應用程式，它依賴 tRPC 進行類型安全的客戶端到伺服器通信。該存儲庫具有相當廣泛的 Monorepo 設置（使用 Turborepo），可將應用程式拆分為多個包。在樣式方面，Cal.com 使用 TailwindCSS 和無頭 Radix 元件。存儲庫非常活躍，他們積極鼓勵貢獻者。許多問題被標記為“良好的第一期”和“需要幫助”。 ## Taxonomy  [https://github.com/shadcn/taxonomy](https://github.com/shadcn/taxonomy) 這個有點不同。它由單個開發人員建置，作為探索新的 Next.js 13 App Router 功能的演示。但是不要讓那個愚弄你。它可以說是使用新 App Router 的最全面的開源應用程式之一。因此，即使對於想要學習如何在生產中使用 App Router 的經驗豐富的 React 開發人員來說，這也是一個很好的資源。 除了用於前端和後端的 Next.js 之外，Taxonomy 使用 NextAuth 進行身份驗證，使用 Prisma 作為 ORM，使用帶有 Radix 的 TailwindCSS 進行樣式設置。特別有趣的是 Stripe 訂閱集成。因此，如果您想了解如何將訂閱集成到您的應用程式中，這就是適合您的存儲庫。 ## Highstorm  [https://github.com/chronark/highstorm](https://github.com/chronark/highstorm) Highstorm 是這個街區的新玩家。它是一種監視應用程式中發生的事件的服務。您通過他們的 API 提交事件，然後將其輸入 Highstorm 儀表板。再次重申，這是一個基於 Next.js 的專案。它使用 Tinybird 作為分析資料的資料庫，並使用 Clerk 進行身份驗證。如果您想學習如何處理大量分析資料並將它們顯示在精美的圖表中，那麼這個專案很棒。 ## Dub.sh  [https://github.com/steven-tey/dub](https://github.com/steven-tey/dub) Dub.sh 大約在一年前作為開源連結縮短器推出。它是 Bitly 等服務的替代品。它也是基於 Next.js 並結合使用舊頁面和新 App 路由器。它通常是最早採用 Next.js 新功能（例如元資料 API）的專案之一。 該存儲庫是了解多租戶 Next 應用程式的好地方。這些是為不同域下的不同用戶提供服務的應用程式。在 Dub.sh 的情況下，用戶可以加入自己的域以在其下建立縮短的連結。該應用程式的設計也很精美，整個網站上都有許多令人愉悅的動畫。 Framer Motion 庫用於幫助解決此問題。 ## Bulletproof React  [https://github.com/alan2207/bulletproof-react](https://github.com/alan2207/bulletproof-react) Bulletproof React 與我們目前介紹的其他專案不同。該存儲庫確實包含一個功能齊全的演示 React 應用程式。但最大的價值來自閱讀此應用程式附帶的綜合文件。本文件列出了設計大型 React 應用程式各個方面的最佳實踐。這是一個很好的資源，可以定期參考以刷新您對最佳實踐的記憶。 ## 總結和開始 正如我們所見，上述每個存儲庫都提供了一個獨特的視角來了解大型 React 應用程式是如何建置的。每個人都可以從研究存儲庫的程式碼中獲益，無論您有多有經驗。 開始從存儲庫中學習的一個很好的實用技巧是提出一個特定的問題。例如，您可能會問“Taxonomy 如何處理 Stripe 訂閱？”之類的問題。然後挖掘程式碼層以找到問題的答案。 最後一點——探索開源存儲庫是提升 React 技能的好方法，但這不是您唯一應該做的事情。將您新獲得的知識應用到您自己的專案中也很重要。這就是您鞏固新技能和保留訊息的方式。 最主要的是享受這個過程，並認識到開源是培養新技能的友好場所，無論您目前的經驗水平如何。
相信有在用PHP的朋友近年來常聽到composer這個套件管理工具。 它到底是做什麼用的？又是為了解決什麼問題而存在呢？ 要瞭解這個，得先從歷史開始說起...。 # PHP最早讀取套件的方法 初學PHP時，最早會面對的問題之一就是require與include差別何在？ require_once與include_once又是什麼？ 弄懂這些問題之後，如果不使用framework，直接開發，便常出現類似這樣的code： ``` // whatever.php // 這檔案需要用到幾個類別 require 'xxx_class.php'; require 'yyy_class.php'; require 'zzz_class.php'; // ... ``` 然後在其他檔案會出現： ``` // another.php // 這檔案需要用到幾個類別 require 'yyy_class.php'; require 'zzz_class.php'; // ... ``` 這樣的結果，會產生至少兩個問題： 1. 許多檔案用到同樣幾個class，於是在不同地方都需要載入一次。 2. 當類別多了起來，會顯得很亂、忘記載入時還會出現error。 那麼，不如試試一種懶惰的作法？ 寫一個php，負責載入所有類別： ``` // load_everything.php require 'xxx_class.php'; require 'yyy_class.php'; require 'zzz_class.php'; require 'aaa_class.php'; require 'bbb_class.php'; require 'ccc_class.php'; ``` 然後在其他檔案都載入這支檔案即可： ``` require 'load_everything.php' ``` 結果新問題又來了：當類別很多的時候，隨便一個web page都會載入一堆code，吃爆記憶體，怎麼辦呢？ # __autoload 為了解決這個問題，PHP 5開始提供__autoload這種俗稱「magic method」的函式。 當你要使用的類別PHP找不到時，它會將類別名稱當成字串丟進這個函式，在PHP噴error投降之前，做最後的嘗試： ```// autoload.php function __autoload($classname) { if ($classname === 'xxx.php'){ $filename = "./". $classname .".php"; include_once($filename); } else if ($classname === 'yyy.php'){ $filename = "./other_library/". $classname .".php"; include_once($filename); } else if ($classname === 'zzz.php'){ $filename = "./my_library/". $classname .".php"; include_once($filename); } // blah } ``` 也因為PHP這種「投降前最後一次嘗試」的行為，有時會讓沒注意到的人困惑「奇怪我的code怎麼跑得動？我根本沒有require啊..」，所以被稱為「magic method」。 如此一來，問題似乎解決了？ 可惜還是有小缺點..，就是這個__autoload函式內容會變得很巨大。以上面的例子來說，一下會去根目錄找、一下會去other_library資料夾、一下會去my_library資料夾尋找。在整理檔案的時候，顯得有些混亂。 # spl_autoload_register 於是PHP從5.1.2開始，多提供了一個函式。 可以多寫幾個autoload函式，然後註冊起來，效果跟直接使用__autoload相同。 現在可以針對不同用途的類別，分批autoload了。 ```spl_autoload_register('my_library_loader'); spl_autoload_register('other_library_loader'); spl_autoload_register('basic_loader'); function my_library_loader($classname) { $filename = "./my_library/". $classname .".php"; include_once($filename); } function other_library_loader($classname) { $filename = "./other_library/". $classname .".php"; include_once($filename); } function basic_loader($classname) { $filename = "./". $classname .".php"; include_once($filename); } ``` 每個loader內容可以做很多變化。可以多寫判斷式讓它更智慧、可以進行字串處理...。 自動載入類別的問題終於解決了...。 *但是光上面的code也有15行，而且在每個project一定都會寫類似的東西。有沒有辦法自動產生這15行呢？ 我的願望很簡單，我告訴你，反正我有my_library資料夾跟other_library資料夾，你自己進去看到什麼類別就全部載入好不好...？* *阿不對，全部載入剛又說效能不好，那你進去看到什麼就全部想辦法用spl_autoload_register記起來好不好...？* *我懶得打15行了，我只想打這幾個字：* ``` $please_autoload = array( 'my_library', 'other_library'); ``` *可不可以發明一個工具，去吃$please_autoload這個變數，然後自己想辦法載入一切啊...？* *ㄟ等等，我連php程式碼都懶得打了，在web領域JSON格式更簡潔。允許我這樣打，好嗎？* ``` { "autoload": [ "my_library", "other_library" ] } ``` *然後誰來個工具幫我產生一大串autoload相關的php程式碼吧...，可以嗎？* **可以。** # Composer登場 首先，裝好composer(本文不介紹如何安裝。) 再來，建立一個composer.json檔，裏面輸入這些： ``` { "autoload": { "classmap": [ "my_library", "other_library" ] } } ``` 比原本希望的多打了一些字，不過差不多。 再來，在terminal輸入 ``` composer install ``` 執行成功之後，你會看到一個vendor資料夾，內含一個autoload.php。 沒錯，跟你夢想的一樣。你只要載入這個檔案： ``` require 'vendor/autoload.php'; ``` 你需要的所有類別，都會在適當的時候、以適當的方式自動載入。 php再也不會噴error說你「類別尚未定義」了！ 這vendor資料夾裏面的一切，都只是php code而已，並沒有特別神奇的地方。只要去看autoload.php的原始碼，就能知道composer到底寫了哪些php code給你。 *ㄟ等等，我寫的類別都放在my_library裏面了，other_library都是網路上copy下來的現成類別。我想要用Google API的Client類別、Doctrine資料庫管理抽象層類別、還有guzzlehttp的發送request類別。* *我連去下載這些檔案、然後丟進這個資料夾都懶得做了，我根本不想手動建立other_library這個資料夾。composer真那麼神...不如連下載都幫我自動下載？可以嗎？* **可以。** 查詢一下那幾個套件在 https://packagist.org/ 的名稱、還有你需要的版本號。 把剛剛的composer.json改成這樣： ``` { "require": { "google/apiclient": "1.0.*@beta", "guzzlehttp/guzzle": "~4.0", "doctrine/dbal": "~2.4" }, "autoload": { "classmap": [ "my_library" ] } } ``` 然後'composer install'指令除了自動載入你的類別之外、還會自動下載你需要的類別、然後自動載入它們。 一樣require 'vendor/autoload.php'就可以了。composer實在是太棒了。 其實composer解決的問題不只這樣。 類別多了起來之後，各種程式語言都提供namespace功能協助分類。 在有namespace的情況下，PHP社群與composer是如何解決自動載入的問題呢？ 這些比較進階的內容，下回分曉。
DHH，本名David Heinemeier Hansson，Basecamp合夥人、Google 2005年度駭客、業餘賽車手，他最知名的身份是網路開發框架Ruby on Rails的發明者。 DHH曾在部落格發表他學寫程式的心得： https://signalvnoise.com/posts/2582-how-do-i-learn-to-program 看過之後覺得獲益良多，特此翻譯出來和大家分享。 --- ## 我怎麼學會寫程式的？ 我花了二十幾年才真的學會怎麼寫程式。不是因為我嘗試的不夠，而是因為我一直用錯誤的方法。我以前都看著那些教材、範本照做，寫出一些我根本沒興趣繼續往下寫的東西。這是為了學習而學習。 我知道這方法對有些人管用，這些人就是很樂意學習新東西。我真羨慕你們。但這對我不管用，而且我知道很多人也沒辦法用這種方式學習。 為了解決鳥事而寫程式———對我來說這才管用。寫程式是因為非這麼做不可。寫程式是因為我他媽的在乎自己所寫的東西，而且我希望它越快完成越好。 這就是我學寫Ruby的方法。我把目標定為，用Ruby把Basecamp寫出來。當你因為一個目標而去學習，每件事的先後順序就變得非常清楚。我到底該做什麼才能讓這幾個訊息順利在Ruby執行？哦，我需要在這裡加一個迴圈。哦，我需要在哪裡抓些資料庫的資料出來。 決定目標的當下，你的點子就完成一半了、而且你還知道了該怎麼做。 簡單來說，就是從一些確實的東西開始做起，接著讓時鐘發出「滴」聲，然後讓它發出「答」聲。
我是web工程師，從剛開始學MVC就深感困惑： - 怎麼每個地方說的MVC都不太一樣？ - 有些文章講的MVC，跟我正在用的MVC，怎麼像完全不同的東西？ Model、Controller、View三者到底如何互動？真是一個定義不明、含糊不清的名詞。 這讓我研究了很久。最後，發覺它是一個嚴重的誤會。 這個誤會導致了學習和溝通上的代價，請聽我娓娓道來。 # 哪些是MVC？ web領域，不論前端(client-side)、後端(server-side)、不論什麼程式語言，幾乎所有framework都自稱、或被認為是「MVC」。 有哪些呢？ 前端：Backbone.js、AngularJS、Ember.js… 後端：Ruby on Rails、CodeIgniter、Laravel、Django… 真的是這樣嗎？它們全都是MVC嗎？ # MVC是什麼？ 該怎麼定義MVC呢？ 我們先來看看維基百科怎麼說： > MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。 嗯，跟大家說的一樣。我們繼續往下看： > 模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 看起來有些陌生，整段描述跟你的web開發經驗完全不同，對嗎？ 最大的疑問來自這句： > 那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 後面直接叫你去看觀察者模式(observer pattern)。 問題來了：你有在view跟model之間實作observer pattern嗎？ 也就是說，你的Model在資料改變之後，能主動通知View嗎？ 沒有的話，就根本不符合MVC的定義。 # 全都不是MVC？ 我們現在發現MVC有observer pattern這個必要條件了。 事情嚴重了起來。 client-side framework或許能夠符合這個條件。 以Backbone.js官網範例來說，我們可以這樣在Model上註冊： ``` book.on({ "change:title": titleView.update, "change:author": authorPane.update, "destroy": bookView.remove }); ``` 它的確實作了observer pattern。 但server-side framework呢？ 你的Model如何能在發生改變之後去「主動通知」View？ 你平常開發web哪有用到server push的技術？ 所有server-side framework，從Ruby的Rails；PHP的CodeIgniter、Laravel；到Python的Django，他們全都不是MVC。 它們實作的，是昇陽電腦在1998年提出的「Model 2」。 # 什麼是Model 2？ Model 2名氣不大，在維基百科連中文條目都沒有。我們看看英文條目怎麼講： > Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. > In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. 它針對web而設計，讓controller進行必要的程序之後，將資料塞進view去呈現。 正是我們server-side框架在做的事情。 也就是說，server-side目前只能實作Model 2；client-side可以實作Model 2，也可以實作MVC。 # 巨大的代價 web工程師最常碰的就是client-side跟server-side框架。結果整個業界把MVC跟Model 2混為一談，都說成MVC。 這帶來了什麼後果呢？ MVC變成一個從初學者到業界工程師，永遠說不清楚、下不了定義的名詞。 這件事對於學習和討論，造成了非常巨大的成本。（參考下方的Q1和Q2） # 那該怎麼辦？ 下次有初學者詢問「什麼是MVC」的時候，怎麼回答才不會害他回家之後「越查資料越混亂」？ [Rails is not MVC](http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html)的作者提出了三種解決方法： > 第一個方法是聲稱MVC已經從原始意義改變了，Model 2也可以稱為MVC。如此一來，我們可以用「傳統MVC」或「真MVC」來描述原始的MVC。這是現在普遍的作法，但我不認為改變定義是一個好主意。這幾乎是越搞越亂。 > 第二個方法是到處推廣Rails其實是Model 2，MVC就留給…MVC吧。這很困難，但至少能保持定義不變。 > 第三個是直接忽略這些混亂。管它那麼多？ 我個人覺得MVC這個詞已經沒救了，不管怎麼解釋都會帶給別人混亂。 當對方同時學習client-side跟server-side時，混亂更強烈。 我選擇這樣回答： 「MVC有分很多種喔！網路上全部沒寫清楚，你一定看不懂。 沒關係，你只要知道View可以抽出來就好。 C跟M先別管，你先隨便瞎搞吧。」 --- # Q&A ## Q1: 怎麼可能各大server-side framework都搞錯？ 確實有人腦袋清醒得很，它就是Python的Django。 Django的官方文件內根本沒有「Controller」這個名詞。 看看Django官網的常見問題： > Q: Django似乎是一個MVC框架，但你們把Controller命名為「View」，把View命名為「Template」。你們幹嘛不用標準命名啊？ > A: （前略）…如果你真的很想要一個縮寫，你就說Django是一個MTV框架吧。Model、Template、View。這樣分比較有道理些。 Django不想變成搞亂MVC的幫凶，只好委屈地又發明了一個名詞「MTV」。 ## Q2: 那client-side框架有受影響嗎？ 有。client-side框架也必須為MVC巨大誤會浪費一堆時間解釋。 看看Backbone.js官網的常見問答： > Backbone跟「傳統MVC」的關聯何在？ > …我們來比較一下Backbone跟像是Rails這種server-side MVC框架的差別… Backbone實作了「傳統MVC」，卻被迫用「傳統MVC」來描述server-side的Model 2，然後花一堆篇幅解釋。 ## Q3: 知道Model 2的存在又如何？我現在依然一片混亂！ 沒錯，Model 2跟MVC都用到Model、Controller、View三個名詞，所以看起來類似。 但是，我們不應該再把時間花在思考「MVC怎麼如此難懂」。 我們討論的重點，應該是「如何分辨MVC與Model 2」、「在server-side如何實作Model 2才漂亮」、「在client-side實作MVC跟Model 2的優劣分別何在」。 ## Q4: 好，那你現在回答我，「如何分辨MVC與Model 2」？ OK，就讓我拋磚引玉一下。 分別談談Model、View、Controller吧： ### View - Model 2: 不具有行為，只是等別人塞資料進去的模板（template）。 - MVC: 具有監視Model的行為，並以此去改變呈現（presentation）。 兩種View有沒有很像？跟張飛、岳飛一樣像。 看看Backbone.js官網的View範例。你server-side的View哪是長這樣？ ``` var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, initialize: function() { this.listenTo(this.model, "change", this.render); }, render: function() { ... } }); ``` ### Controller - Model 2: 接收請求與參數，轉交給Model處理，再把結果（最新的資料）塞進View。 - MVC: 接收請求與參數，轉交給Model處理。沒其他事了。 兩種Controller有沒有很像？跟小狗、熱狗一樣像。 MVC的View跟Model 2的Controller可能還比較像一點。（隨便說說，千萬別這樣類比。） ### Model - Model 2: 接收Controller傳來的參數，回傳結果。 - MVC: 接收Controller傳來的參數，將結果通知View。 Model倒是有些類似。 總之，Model 2跟MVC除了三個部份的名字一樣之外，沒什麼關聯了。 ## Q5: 我決定徹底鑽研MVC跟Model 2的定義了。給我一些延伸閱讀？ http://www.ithome.com.tw/node/77330 http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html https://docs.djangoproject.com/en/1.7/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names http://backbonejs.org/#FAQ-mvc https://r.je/views-are-not-templates.html --- ##一些社群的看法（2015-2-28） 附上幾個社群的連結，裡面有許多很棒的討論。 https://www.facebook.com/groups/javascript.tw/permalink/600136880087654/ https://www.facebook.com/groups/199493136812961/permalink/759391387489797/ https://www.facebook.com/groups/pythontw/permalink/10153760201638438/ https://www.facebook.com/mosky.liu/posts/10203964969186383 http://www.ithome.com.tw/voice/94877
初學者接觸OOP，幾乎都會有以下疑惑： 我到底為什麼要學OOP？OOP解決了什麼問題？書上這些範例就算不用OOP也寫得出來吧？ 然後覺得「繼承」、「多型」、「介面」、「抽象類別」等等的名詞很難，覺得OOP很難。 其實這些名詞雖然重要，但對新手來說，本來就很難在一開始就搞懂。 建議先搞懂「資料跟行為在一起」是什麼，以及它的好處在哪，就可以了，其它的慢慢來。 # 什麼叫做「資料跟行為在一起」？ 假設我們在開發一個「中英文互助學習網」，鼓勵中文人士與英語人士登入討論。 這個系統的貼文、留言功能會顯示「發文日期」。 發文日期要根據使用者的註冊身份（台灣人、英語人士）顯示不同格式（台灣格式、西方格式）。 下面就以這個日期格式的功能舉例說明「資料跟行為在一起」是什麼意思。 ## 作法一：直接硬寫（不OOP、資料跟行為混在一起） 初學者通常會用最簡單、也最直覺的作法，直接硬寫出來，像這樣： ``` <?php $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否顯示台灣格式 */) { # 轉換成這樣 2016.6.2 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$year.$month.$day"; } else { // 西方格式 # 轉換成這樣 6/2/2016 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$month/$day/$year"; } ``` 這種寫法的資料（日期）跟行為（轉換成各種格式）混在一起。 它的優點是寫起來很簡單，缺點則有兩個： * 日期格式的邏輯會重複出現在很多地方，整段code會到處重複出現 * 整段code大概會塞在 `div` 或是 `span` 的裡面，導致它跟HTML混在一起，很亂 ## 作法二：自訂函數（不OOP、資料跟行為沒混在一起） 為了解決作法一遇到的問題，聰明的初學者很快就想到可以用「自訂函數」！就像這樣： ``` <?php function localFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$year.$month.$day"; } function englishFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$month/$day/$year"; } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否為台灣人身份 */) { echo localFormat($postDate); } else { // 英語人士身份 echo englishFormat($postDate); } ``` 這種寫法將行為（轉換成各種格式）用自訂函數給獨立出來，也大幅改善了作法一遇到的問題。 對小型的網頁程式來說，這招非常好用，不但開發快速、簡單，還漂亮地將資料跟行為拆開。 但是程式規模變大之後，為了將各種行為拆出來，會寫出很多自訂函數，類似這樣： ``` ?php function localFormat($param) { // blah blah ... } function englishFormat($param) { // blah blah ... } function someTask($param) { // blah blah ... } function anotherTask($param) { // blah blah ... } function otherTask($param) { // blah blah ... } //... ``` 於是又衍生出三個問題： 1. 像localFormat、englishFormat這樣的函數名稱意義模糊，看不出是處理日期、人名，還是什麼東西的格式 2. 這些自訂函數各有不同的行為，全部放在一起顯得很亂，應該要想辦法分類、整理這些函數 3. 像localFormat、englishFormat這樣的函數，只吃特定格式的參數，最好能跟某種資料的形式綁在一起，以後要改程式時，能讓相關的資料跟行為一起被看到 問題1很好解決，只要替函數名稱加前綴字變成dateLocalFormat、dateEnglishFormat就行了。 問題2也很好解決，只要多開幾個檔案，把相關的函數放進同一個檔案就行了。 問題3就很棘手，資料跟行為拆開之後，如何在概念上又找方法整理在一起？ ## 作法三：使用class（OOP、資料跟行為在一起） 正是這些處理資料、整理行為的問題，導致了OOP的誕生： ``` <?php class Date { public $year; public $month; public $day; public function __construct($date) { $arr = explode('-', $date); $this->year = $arr[0]; $this->month = $arr[1]; $this->day = $arr[2]; } public function localFormat() { return $this->year . '.' .$this->month . '.' . $this->day; } public function englishFormat() { return $this->month . '/' .$this->day . '/' . $this->year; } } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 $date = new Date($postDate); if (/* 判斷是否為台灣人身份 */) { echo $date->localFormat(); } else { // 英語人士身份 echo $date->englishFormat(); } ``` OOP的寫法，一次解決了前述三個問題： 問題1 => 現在從類別名稱就可以知道底下方法的意義了 問題2 => 現在相關的函數都整理進同一個類別底下成為方法了 問題3 => 現在資料的形式都統一在constructor處理一次，之後不管新增多少方法都不用處理資料了 這就是所謂的「資料跟行為在一起」，也正是OOP的核心概念。 利用這種方式整理程式碼、寫出一個又一個的類別，可以大幅提昇程式碼的品質。 # 結論 上述的作法一跟作法二並沒那麼糟糕，但確實會帶來一些問題。 對於小型的網頁程式來說，可能還算夠用。 但是隨著程式規模變大，如果將概念上相關的資料跟行為整理在一起，會很有幫助。 實務上也可以先從作法二開始寫起，直到發現某些資料跟行為關係密切，再拉出來整理成類別即可。 至於很多OOP教學會提到的「繼承」、「多型」、「介面」、「抽象類別」等等名詞，一時搞不懂沒有關係，你可能實務上也暫時用不到。之後找時間慢慢搞懂它們的用途就好。 光是知道「將資料跟行為放在一起」的技巧，就能夠開始寫OOP程式碼了。 （註：本篇文章的程式碼純屬教學用途。實務上PHP已經有DateTime類別可以使用，或是用更漂亮的Carbon類別。） ## Q&A Q1：我常常設計一些類別，只有資料沒有行為，聽起來OK嗎? 不OK，這很不OOP，而且沒意義。 乾脆直接用關聯式陣列去表示那些資料就好。 Q2：我常常設計一些類別，只有行為沒有資料，聽起來OK嗎? 這個要看情況，不一定。 但唯一可以確定的是，這種作法很不OOP。 因為OOP的核心是「資料跟行為在一起」。 這也是為什麼你會看到有人明明寫了類別、用了物件，別人卻說「這不夠OOP」。 然後你又會看到像JavaScript這樣連「類別」關鍵字都沒有（ES5以前），卻能夠寫出很OOP程式碼的關係。 判定的標準都是一樣的，而且也就只有這麼一個標準：資料跟行為有沒有在一起。 Q3：一個類別包含的概念是越大越好，還是越小越好？ 不一定。不過我們從作法一到作法三的過程，有一個明確目的：希望讓程式碼更好懂。 如果聲稱一個類別包含的概念很大（例：設計LanguageHelpWebsite類別，用來代表「中英文互助學習網」需要的所有功能），那會把幾乎整個網站的所有行為跟資料都放進去，成為所謂的God object。它可沒有讓程式碼更好懂。 相反地，如果聲稱一個類別包含的概念很小（例：分別設計LocalDate、EnglishDate類別），雖然意義可能更精準了，但用一整個Date類別的概念去思考，程式碼會更容易理解，也就是所謂的內聚性（Cohesion）更高。 所以要替OOP就是「資料跟行為在一起」加個但書： 要以方便理解程式為前提，將資料和行為放在一起。
正在發想一個新功能，未來應該會開發 就是大家發表的文章，會有 API 這樣大家可以在 CodeLove 寫文章，然後自己另外架部落格，撈自己文章的 API 比方說 `https://codelove.tw/api/@howtomakeaturn/posts` 類似這樣 就拿到 JSON 格式的一串文章資料，這樣大家就能把 CodeLove 當文章資料庫、自己另外架喜歡的部落格了～ 大家覺得如何，還不錯吧～
未來想要找商家幫忙架站 接案賺點小錢 想問一下 純靜態網站我去辦一個github來架設應該也是可以的吧(? 怎麼好像沒看到有人這樣做 我自己猜是因為大多數不是靜態 有資料庫 後端 所以如果我架靜態網站 直接用github感覺滿偷吃步的 但也是可以的吧 假設說 撇除github這個比較旁門左道的方案(? 是否我這個目標就是要去學wordpress呢~ 自己希望未來可以走向 架網站 接案之路!! 或是各位有沒有接案經驗也可以一併分享 感恩各位前輩~
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
