原文出處：https://dev.to/chaoocharles/how-creating-content-as-a-developer-changed-my-life-270e 大家好，我想鼓勵一些想要開始編碼職業但發現很難找到第一份工作或實習的人。還有那些因為開始懷疑自己的能力而難以開始/完成專案的人（冒名頂替症候群）。我將透過告訴你我自己的旅程以及我一路上學到的東西來做到這一點，希望你能有動力繼續你的旅程。 我叫查爾斯，來自非洲肯亞。我早在 2016 年就開始了我的編碼之旅，當時我進入大學，在 BTECH I.T 尋求職業生涯。在此之前，我對電腦了解不多，我只知道它們很酷，我想研究它們。在高中時，我是一名表現最好的學生，我的英語老師（也是副手，哈哈）認為我想做一些像計算機這樣簡單的事情而不是像工程、醫學、飛行員等更專業、更有前途的職業，這是愚蠢的，你說出它們的名字。好消息是我沒有聽，而是去做了我想要的事情，而且我不會為此感到後悔。事實是，IT 領域的任何職業都是當今世界上最好的職業之一，世界頂級公司之所以能處於領先地位，是因為程式碼。看看 Netflix、亞馬遜、微軟、Facebook、Airbnb 或 Uber。所有這些公司都透過程式碼賺了數十億美元，因此不要讓任何人欺騙您，讓您認為您走在錯誤的道路上。我來這裡是為了告訴你，你正走在最好的道路上。 回想2016年剛入職第一年的時候，由於出身卑微，擁有一台筆記型電腦對我來說是非常困難的，即使是一台簡單的筆記型電腦，甚至是二手的筆記型電腦。如果我要做 I.T，那麼擁有一個對我來說也是強制性的。擁有一部像樣的智慧型手機也是一個問題，但幸運的是，我有一個三星口袋（那些小三星手機，如果你還記得的話），並在說服朋友用它與我交換一些錢和一部按鍵手機後。這款手機在這個故事中很重要，因為它是我用來開始學習程式設計的手機。在學校裡，我們被教導如何編碼，是的，但這還不夠，它主要是理論。關於編碼的事情是你必須_練習_、_練習_、再_練習_。於是，我從同學那裡了解到了一個名為sololearn的應用程式。我在那裡開始學習 Web 開發，包括 html、css、javascript、php、sql，我想還有一點 jquery。這個應用程式教會了我有關這些主題的所有基礎知識，並且在完成每節課後它都有有趣的挑戰和徽章。唯一的問題是我不會透過手機進行完整的項目編碼。但重點是，當您等待購買筆記型電腦時，您絕對可以開始透過智慧型手機學習程式設計。因此，不要因為沒有筆記型電腦而高枕無憂。你越早意識到沒有人來拯救你越好。 我繼續從我的三星口袋裡學習了一個月，後來在內羅畢街頭（有很多扒手）它被神秘地偷走了。學校的朋友送了我一部HTC手機，螢幕碎了，有些地方根本碰不著，我得旋轉螢幕多次才能碰到地方😂，不過乞丐不挑食，我就繼續用了以便在本學期剩下的時間裡學習更多有關編碼的知識。 第二學期，現在是2017年，我收到了學生貸款。我的一些朋友/同學用他們的貸款去聚會、喝酒以及在俱樂部與女孩們玩耍。嗯，就我而言，我知道自己從哪裡來，也知道自己要去哪裡。於是，我拿了一些錢，立刻買了一台筆記型電腦。剩下的錢用來付學費和一點生活費。這對我的案例來說是一個巨大的進步，因為我現在可以了解更多資訊並開始從筆記型電腦上處理專案。因此，如果您有錢，請停止考慮參加聚會和購買昂貴的東西，而是考慮如何用這筆錢讓您的生活變得更好。 2017年至2019年期間，沒有太大變化。我只是在學習和做學校作業等。我想我還用 HTML 和 CSS 製作了兩個網站，我為這些工作獲得了一些報酬。我探索了更多關於編碼的知識，包括學習Java 中的OOP（物件導向程式設計），也用Java 進行了一些Android 應用程式開發，我的筆記型電腦無法處理android studio 😂，所以我又回到了Web 開發。我探索了 WordPress 以及如何用它製作博客等，並建立了一個 WordPress 博客，並以幾美分的價格出售。 2019年底，我正在讀三年級第三學期（這在我們大學被稱為內部工業實習），大約在這個時候，我被敲響了警鐘。我意識到我一直在學習編碼，但除了簡單的 html、css 和 WordPress 網站之外，我仍然無法建立一個完整的專案。我對任何一種程式語言都沒有足夠的信心。另外，畢業的要求是在第四年完成一個編碼專案。我也開始對未知產生恐懼，例如放學後要做的事情，因為只剩下一年了。我開始做很多研究如何創建一個完整的網絡應用程序，因為我已經了解了 javascript 的基礎知識，並且出現了一件我不知道的事情，即 javascript 框架，目前最流行的是 Angular、Vue並做出反應。當時我就知道我必須學習這些框架之一，而且很難決定選擇哪一個，但我最終選擇了 React，因為它是所有框架中最受歡迎、最有前途的工作，而且我仍然使用 React 進行編碼這點。 我嘗試從sololearn學習React，但進展並不順利。我嘗試了 youtube 並發現了 @thenetninja 頻道：https://www.youtube.com/@NetNinja，它非常有益健康，這就是我對 React 的很好的介紹。後來我從 Udemy 學習了兩門完整的 React 課程，一門由 _Stephen Grider_ 教授，另一門由 _Maximilian Schwarzmüller_ 教授。順便問一下，我沒有完成它們，誰完成了 udemy 課程？ 😂 但這兩門課程教會了我更多關於 React 的高級知識。 在學習 React 的過程中，我也很好奇如何在放學後或還在學校的時候透過程式碼賺錢，我發現了幾個選擇，找工作、自由工作、創建內容（這可以是寫部落格或 YouTube 頻道） ）、開始播客、寫書、創建像udemy 這樣的課程等等。由於我還在上學，我知道找工作很難處理，所以我決定嘗試自由工作和內容創作。還是在 2019 年，我開設了 YouTube 頻道：https://www.youtube.com/c/chaoocharles 來教授編碼，也開設了一個 upwork 帳號來從事自由專案的編碼。 我知道我不是一個好的作家，正如你從這篇文章中絕對可以看出的那樣，所以我嘗試了視頻而不是博客。這是另一個挑戰，因為我必須學習如何製作影片、學習錄製和編輯軟體等等。但我還是堅持了下來，並從同學那裡得到了我的前 100 個訂閱。我的影片一開始就很糟糕，而且我做了很多工作，甚至沒有得到一分錢。但從正面的角度來看，製作影片讓我更理解編碼概念。就像，對我來說，要解釋我必須先理解的東西。我主要用 html、css 和 React 創建了很多視頻，做得越多，我對創建視頻和編碼就越有信心。 2020 年，我有很多時間來做這一切，因為我們因新冠疫情關閉了學校近一年，經過一年的努力，我終於獲得了 1000 名替補，這對我來說是一個巨大的勝利。 2020 年中期，我取得了兩場重大勝利，在 YouTube 上達到了 1k，並且在 Upwork 上找到了我的第一個客戶。我需要 1000 訂閱者和 4000 小時的觀看時間，YouTube 才會開始向我付費。我距離 4k 觀看時間還很遠，但至少我已經達到了其中一項要求。 Upwork 也很難找到第一個客戶，我申請工作卻無濟於事，但這第一個客戶改變了遊戲規則。我讓他相信我知道如何編碼，並用我的 YouTube 教程證明了這一點。你看，在製作 YouTube 教學的同時，我也在為自己建立一個作品集，我也在我的 github 上發布了多個專案。這麼說吧，我的投資組合目前看起來非常好，這位客戶毫不猶豫地給了我一份合約。如果你碰巧教了一些東西，人們就會開始將你視為專家（即使你正在努力教那件事😂）這可以通過視頻或博客，我認為你應該嘗試一下。我在 upwork 專案上做得很好，這個客戶在那一年和接下來的一年裡繼續給我更多的專案。我做了他的大約 8 個項目，在 upwork 上獲得了上升人才徽章，後來又獲得了頂級徽章，這讓我贏得了更多客戶。  是的，我知道我現在的工作成功分數很差，但你明白了，哈哈😂 在製作YouTube 影片和Upwork 專案時，我也在做我的最後一年項目，因為我現在已經是第四年了，但這些是我自從2020 年因新冠疫情在家以來所做的唯一事情。雖然在2020 年底，我們回去上學期，做了考試並展示了專案。 快轉到 2021 年，我現在正在做附件。這是我畢業的必要條件。我透過在 Facebook 和網路上尋找肯亞的網路開發公司，輕鬆獲得了這一點。評論他們的帖子並解釋我的 IT 背景。我從某家新創公司的 CEO 那裡得到了 DM，並且以前端開發人員的身份加入了那裡。我試圖就報酬進行談判，但最好的結果只是維持交通和午餐，每週去辦公室三天，並承諾在實習後獲得一份長期工作。作為一名學生，這已經足夠好了，所以我就這麼做了。 在這家公司，我的 CSS 和 React 技能給他們留下了深刻的印象。我改造了他們公司的網站，並在我在那裡的5個月期間又做了2個網站。學校對我進行了評估，後來公司給了我工作機會。我覺得每個月的收入對我的技能來說不夠好，因為我可以在一兩週內輕鬆地做同樣的自由職業，而且我在那裡的時候我的 YouTube 也得到了貨幣化。我只是拒絕了這個提議，並決定專注於我的自由職業和內容創作之旅。如果他們允許我在處理其他事情的同時遠端處理他們的項目，也許我會接受這個提議，但這不在他們的公司政策中。我不想滿足於更少。你看，過去幾年我所做的一切都給了我選擇，也讓我不再急於找到工作，並擁有競爭優勢。 2021 年年中，我以二等高年級畢業，我保證如果不是我用 YouTube 和 upwork 分散自己的注意力，我會獲得一等，第四年我表現最差。但我後悔嗎？不。問題是，我從來沒有用過那個學位，它仍然鎖在家裡的某個地方，沾滿了灰塵。好處是，技能和經驗是這個編碼和程式設計領域最重要的。只有少數公司可能會要求學位，但大多數公司不會。他們會詢問您過去的經驗、您從事過的項目，並希望您通過程式設計面試。因此，如果你正在尋找一份程式設計工作，並因為沒有獲得學位而指責自己沒有學位，那麼你應該停下來。我們大多數擁有學位的人甚至沒有使用它們。也許我們唯一的優勢是我們在學校建立的聯繫或從那裡獲得的技能。但說實話，我所知道的大部分內容都是我自學的，我相信每個程式設計師都是自學的程式設計師，無論他們是否上過學。你必須親自動手。光靠論文並沒有太大幫助。 畢業後，我開始從 YouTube 獲得專案邀請，以及報酬豐厚的專案。我也開始利用 YouTube 和 GitHub 來在 Upwork 上獲得更好的付費項目，透過分享我的個人資料連結來告訴客戶我所取得的成就。所以，所有這些加起來就很不錯了。現在，我僅透過內容創作來支付所有帳單，並透過在工作和外部工作項目上工作來獲得更多收入。我的時間也很靈活，在家工作，這很棒。 2022 年我只做了一份全職工作。雖然位置偏遠，但完全值得。 我的觀點是，如果你正在努力尋找一份工作或一個項目，你可以透過為自己建立一些東西來改變一切。建立部落格、建立播客、創建頻道、創建公司、創建課程、寫書、公開構建（啟動一個大型專案並在此處和 Twitter 上分享您的進度），只需在這裡展示您的技能即可您能做什麼，遲早你會開始從事高薪專案。停止追逐工作，而只是吸引他們。 正如你從我的旅程中可以看出的，這不是一天的成就，直到一年多我才得到一分錢的內容創作報酬，直到一年多我才得到一個客戶的工作。我不是一天就能學會程式設計的，我是從一部手機開始的，後來又是用學校貸款買的一台低階筆記型電腦（我甚至還沒付）。所有這些成功的人士和公司都是從某個地方開始的，您今天就可以開始改變您的生活。開始親自動手，兩三年後你甚至不會相信自己來自哪裡。 這是我的故事，我希望你學到了一兩件事✌️ 訂閱我的 YouTube 頻道：https://www.youtube.com/c/chaoocharles 在 Twitter 上關注我：https://twitter.com/ChaooCharles
原文出處：https://dev.to/turculaurentiu91/why-you-should-choose-htmx-for-your-next-project-o7j 在本文中，我們將旨在了解為什麼您下次為 Web 應用程式選擇技術堆疊時應該考慮 HTMX 作為 React 的替代品。我們將研究傳統 HTTP JSON API + React 帶來的複雜性和挑戰，以及如何透過使用 HTMX 輕鬆避免它們。 **注意**：在本文中，我將討論 React，但它可以替換為任何其他前端框架，如 Angular、Vue、Svelte 或 Solid，但我談論 React 是因為它是大多數 Web 的預設技術開發人員預設為。 ### HTMX 到底是什麼 如果您還不知道，[HTMX](https://htmx.org/) 是一個小型瀏覽器 (JS) 庫，它使用一些屬性擴展了 HTML，允許您使用來自伺服器。它還使 HTML 能夠對所有動詞發出 HTTP 請求，而不僅僅是 GET 和 POST。 ## React 解決了什麼問題 React 是一個 JavaScript 程式庫，可協助您透過保持使用者介面與狀態同步來編寫高度互動的應用程式。您告訴它如何渲染給定的狀態，每次更新狀態時，它都會重新渲染（盡可能有效率）UI 以反映狀態變更。 每次狀態發生變化時，您都會通知庫它發生了變化，並提供新的狀態，它將處理 UI 更新。 需要本地記憶體狀態的高互動應用程式的範例可以是您可以在網路上找到的各種文字編輯器（VSCode）之一、拖放看板（如 Trello 或 JIRA）、視訊播放器或聊天室。 什麼不是此類應用程式的範例？您正在建立的待辦事項清單、您正在閱讀的新聞網站、您發布的部落格以及周圍的大多數網站。如果我們看一下 [80/20 規則](https://en.wikipedia.org/wiki/Pareto_principle) >80% 的結果來自 20% 的原因，80% 的結果來自 20% 的努力。 你可以說 80% 使用 React 的 Web 應用程式不需要本地狀態。對於那 20% 需要它的人來說，你可以說它只是應用程式的一小部分（大約 20%），其餘部分只能用 HTML 來表達。 **這些數字是編造的，我沒有任何研究來支持這一點** ## React 也解決了哪些問題，使其被現代網站廣泛採用 HTML 已經過時了。使用 HTML 製作應用程式的舊方法涉及頁面、連結和表單的集合，這些頁面、連結和表單向使用者描述給定資源的當前狀態以及他們可以執行哪些操作來更改它。 每次使用者與資源互動時，應用程式只能重新載入整個頁面以顯示資源的新狀態。 幾年後，FaceBook 推出了 React，這是一個 JS 程式庫，可讓開發人員建立單頁應用程式 (SPA)。導航時不再需要重新加載整個頁面，狀態更新的酷過渡、對用戶的有趣反饋以及其他使 Web 開發人員在其網站中採用 SPA 框架的細節。 ## 複雜性問題  如果你不理解上面的架構，不用擔心，沒有什麼好理解的。我要求 ChantGPT 為我生成它，由於它過於複雜且沒有任何意義，它完美地反映了現代 Web 應用程式目前的預設基礎架構。 一個很酷的程式設計原則是**KISS**，它代表“保持簡單，愚蠢”，或者有些人可能喜歡開玩笑，“保持簡單，愚蠢！” 現代開發人員預設建立 Web 應用程式的當前基礎設施和技術堆疊極其複雜，做了很多不必要的事情，只是因為它很酷！ 當您自己建立第一個 POC 時，效果很好，但下一刻您加入了更多團隊成員，並且使用多次迭代和「擁抱」更改的敏捷方式，它有點崩潰，原因是我們將往下看一下。 ## 傳統 HTTP JSON API + React 的狀態管理問題 在 Web 應用程式中，您經常要做的就是從資料庫中獲取資源的狀態並將其呈現給使用者。讓我們以任務管理應用程式為例。使用者有一個任務列表，每個任務都有一個狀態： - 任務的標題 - 說明 - 任務完成時的標誌 - 截止日期（可選） 我們通常將此狀態儲存在資料庫中，並將此資訊呈現給用戶，您必須： - 從使用者有權存取的資料庫中取得所有任務。 - 可以選擇轉換資料（也許您儲存完成的日期並從中計算「is_completed」標誌）。 - 將資料序列化為 JSON。 - 透過 HTTP 請求取得資料。 - （可選但通常）根據模式驗證資料，可能使用 YUP 或 ZOD。 - 使用 Redux、Zustand、react-query 或其他狀態管理庫將 JSON 轉換為狀態並將其儲存在快取中。 - 轉換 HTML 中的狀態，通常會決定使用者可以使用資料做什麼。 簡而言之，我們正在描述如何在 JavaScript 中渲染所有資源的所有可能狀態，在瀏覽器中下載所述 JavaScript，然後 JavaScript 下載一堆 JSON 格式的資料並將其渲染（如果它知道如何）瀏覽器顯示為HTML！ 向使用者顯示任務清單需要做大量工作，特別是當任務僅在使用者變更時才更改時，應用程式必須將應用程式置於載入狀態，發出另一個 HTTP 請求（以PUT 或PATCH 或DELETE）使快取值（狀態）無效並重新獲取它以顯示更改的任務。 或者更糟的是，當用戶更改某些任務時，樂觀地更新本地狀態並立即顯示更改，並在幕後執行更新請求，僅在他們成功更新後通知用戶更新失敗。 這是非常容易出錯的。對於這個待辦事項應用程式來說，它可能會很有效，因為您是唯一的開發人員，並且該應用程式足夠大，您可以在腦海中保留正在發生的所有事情的地圖。但是當你的團隊規模更大時，尤其是當你將團隊分成前端和後端時，溝通不良可能會導致很多問題。 後端可能使用“is_completed”標誌，而前端可能需要“is_active”標誌。後端可能會將經過 Markdown 處理的「描述」傳送到 HTML，而前端可能希望它不被處理。後端可能會將“描述”設為可選，以允許使用者在前端不同步時保存草稿，並且您會看到許多“未捕獲的類型錯誤：無法讀取未定義的屬性（讀取“toLowerCase” ）” 另一方面，在 HTMX 上，您可以直接在範本上呈現 HTML，只要後端語言允許，就可以確保類型安全。您僅向瀏覽器發送相關訊息，向使用者提供對資源的適當控制，並指示瀏覽器或 HTMX 如何解釋使用者操作以及後端對這些操作的回應。所有應用程式狀態都是 HTML，這個概念稱為 [HATEOAS](https://htmx.org/essays/hateoas/) ## 傳統 HTTP JSON API + React 對文件的需求 為了讓兩個團隊（後端和前端）獨立工作並透過 HTTP JSON API 進行通信，您需要擁有適當的 API 文件。您還需要記錄如何計算使用者可以對給定資源執行哪些操作以顯示控制項。 大多數此類文件寫起來都很痛苦，特別是因為通常需要在實作之前編寫，而開發人員尚未完全理解問題的範圍，因此前端可以並行開發。這通常會在開發過程中進行許多更新，以適應開發過程中出現的問題，並可能導致團隊之間的版本不一致。 您還需要對 API 進行版本控制，並注意不要在非主要版本變更中引入重大變更。您無法再在不變更主要版本的情況下變更欄位名稱。您還需要保持 API 的多個版本運作或強制前端團隊進行調整。 大多數時候，文件已經過時了。有些必須緊急修復，有些新要求是在發布前一天提出的，現在您的文件已經過時，即使在很短的時間內。而且您必須記住更新它，或者更糟的是，您建立了一張票來記住它，而其他人拿起它，但沒有完整的圖片並記錄了錯誤！ ## 重複的邏輯問題 對於每個資源，您必須實施授權策略。您必須確定目前使用者是否可以將任務 **46234** 標記為已完成。您必須在後端程式碼的某個位置編寫此檢查。否則，您的應用程式將開放給_不安全的直接物件參考_，或任何使用 Postman 的人都可以將您的任務標記為已完成。 您還必須在前端實現相同的邏輯，僅當用戶有權標記已完成時才顯示標記按鈕（讓我們假設您可以與其他用戶共享您的任務，但只有您可以更改它們）。 現在每次這個邏輯改變時，你都必須在兩個應用程式中實作它，並同時發布它或擁有多個版本的API。 ## 效能問題 為了使用 React 在瀏覽器中呈現網站，您需要將佔用大量內存和解析/處理影響的 React 程式碼、狀態管理庫程式碼、腳趾 UI 庫程式碼、CSS-IN- 捆綁在一起。JS 庫程式碼、應用程式程式碼以及我們透過NPM 安裝和使用的任何js 程式庫（我們並不羞於安裝新套件，請參閱[leftpad 問題](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/))。這通常會導致透過網路傳送大塊的 JavaScript 資源。當然，您可以在瀏覽器中緩存，但在現代敏捷開發中，每個衝刺至少部署一次，因此這無法解決任何問題。這會消耗網路流量和電池，這對行動裝置來說是一個經常被忽視的問題。 上述JavaScript需要由瀏覽器來解釋，消耗處理能力和電池。 JavaScript，尤其是 ReactDOM，需要追蹤 DOM 的鏡像。在其之上加入普通 DOM 和本地狀態緩存，以及所有渲染函數，以及所有“useMemo”、“useCallback”和“useState”。也要加入需要在記憶體中保存所有上下文變數的所有閉包。 JavaScript 引擎並不以其記憶體效率而聞名！您會聽到人們抱怨瀏覽器消耗了多少內存，但他們低估了他們存取的網站所消耗的內存量。 所有這些加起來，最終會耗盡用戶的電池和記憶體。當然，您可以付出努力並優化所有這些，或使用其他程式庫（如 Svelte），但所有這些努力都可以用於為您的用戶提供更有意義的功能。 ## 服務端渲染的需要 近年來，我們播種了伺服器端渲染專用框架（如「Next.js」）的興起。它們的流行凸顯了對以 HTML 格式交付內容的需求，特別是出於可存取性優化、效能和搜尋引擎優化的原因。 你不想等待瀏覽器下載 JavaScript 來渲染頁面，然後等待 JavaScript 發出 HTTP 請求來獲取內容然後渲染它，你希望它立即渲染，特別是對於上面的情況折疊內容。 這又增加了一層複雜性，包括： - 基礎設施，現在您還需要另一台伺服器用於前端應用程式 - 程式碼更複雜，包括什麼程式碼在伺服器上執行以及什麼在瀏覽器上執行的思維導圖 - 部署管道現在更加複雜 - 測試基礎設施現在更加複雜 - 現在解決問題變得更加困難，您需要了解問題是在瀏覽器上、在客戶端應用程式伺服器上還是在 API 伺服器上 ## 解決這些問題 Web 開發社群各自使用自己的語言或開發技術，以不同的方式解決這些問題： - Next.js（以及 Nuxt 等） - 反應伺服器元件 - 拉維爾 - 慣性.JS - 活線 - 點網 - Blazor 頁面 - 靈藥 - 鳳凰即時查看 - 鐵鏽 - 樂浦伺服器功能 還有許多我忘記或從未聽說過的其他解決方案！ 無論如何，此類解決方案的存在和流行證明了這些問題是有效的並且在 Web 開發人員的日常生活中遇到過。否則他們不會不遺餘力地解決這些問題，尤其是以開源的方式！ 還有 [Turbo](https://turbo.hotwired.dev/) 以及採用它們的框架、Ruby on Rails、PHP Symphony 以及其他可能以與 HTMX 相同的方式解決相同問題的框架。選擇 HTMX 只是個人喜好，但你絕對應該了解這一點，這和 HTMX 一樣酷！ 在所有這些中，HTMX 脫穎而出，不僅因為它不會將您鎖定到特定技術，您可以透過對模板進行微小更改來從 PHP 切換到 Rust，而且還因為它完全消除了對有狀態元件的需求，或者需要追蹤與資源無關的應用程式的某種狀態。 例如，讓我們採用確認對話方塊模式。您通常最終要做的是，您有一個本地記憶體狀態（如果它是開啟的），並根據該狀態將其顯示給使用者。在 HTMX 中，狀態 **IS THE HTML** 意味著當您按一下開啟模式時，您 **GET** `tasks/{taskId}/confirm-delete` 並將回應 HTML 嵌入到 DOM 中。當它被刪除時，您就完全刪除了模式和任務！這以一種獨特且極其簡單的方式解決了上述所有問題，您不需要： - 追蹤狀態 - 知道如何渲染對話框 - 記錄API - 檢查使用者是否可以刪除任務（在前端） - 您的後端應用程式始終負責 - 您可以獲得更好的安全性，因為您不會向瀏覽器發送不相關的資料並竊取敏感資訊 - 你會得到更好的表現 __*最重要的是，您可以讓您的應用程式保持簡單，只有在解決使用者問題時才允許複雜性！*__ 您只需指示 HTMX 從何處獲取對話框以及將其放置在何處，一切就完成了！ ``` <!-- the delete button --> @if ($chirp->user->is(auth()->user())) <form> @csrf @method('delete') <x-dropdown-link :component="'button'" type="submit" hx-get="{{ route('chirps.confirm-destroy', $chirp) }}" hx-swap="beforeend" hx-target="closest .chirp" > {{ __('Delete') }} </x-dropdown-link> </form> @endif <!-- the dialog template --> <div class="modal fixed z-10 inset-0 overflow-y-auto flex justify-center items-center bg-black bg-opacity-50" style="backdrop-filter: blur(14px);"> <div class="bg-white rounded p-6"> <h2 class="text-xl border-b pb-2 mb-2">Confirm Action</h2> <p>Are you sure you want to delete this chirp?</p> <div class="flex justify-end mt-4 gap-4"> <x-secondary-button _="on click remove closest .modal" > Cancel </x-secondary-button> <form> @csrf <x-danger-button hx-delete="{{route('chirps.destroy', $chirp)}}" hx-target="closest .chirp" hx-swap="delete"> Delete </x-danger-button> </form> </div> </div> </div> ``` _這個範例來自我的 [HTMX with Laravel] 教學（https://dev.to/turculaurentiu91/laravel-htmx--g0n) ，請看！_ 就像這樣，當我們單擊刪除按鈕時，我們指示 HTMX 對 `chirps/{chirp}/confirm-destroy` 執行 **GET** 請求，並將結果 HTML 放在最接近的父級 `< 之前div class="chirp">` 結束（在底部）。在刪除對話方塊中，當使用者確認時，我們指示 HTMX 對 `chirps/{chirp}` 端點執行 **DELETE** 請求，成功後，我們刪除具有 `chirp` 類別的最接近的父級。 ## 結論 在不斷發展的 Web 開發領域，看到 HTMX 等倡導簡單性和回歸基礎的工具令人耳目一新。透過利用 HTML 和 HTTP 的強大功能，HTMX 允許開發人員建立動態 Web 應用程式，而無需傳統 JavaScript 框架的複雜性和開銷。 因此，下次您開始新專案或考慮重構現有專案時，請嘗試 HTMX。您可能會驚訝於用這麼少的錢就能取得如此大的成就。
原文出處：https://dev.to/rjwignar/are-you-stealing-from-other-projects-4f0n ### 優秀的程式設計師抄襲；更優秀的程式設計師會偷竊嗎？ > 優秀的藝術家臨摹；偉大的藝術家偷竊 > \- 巴勃羅·畢卡索 巴勃羅·畢卡索經常因說出上述引言而受到讚譽。我不會提供我自己對這句話的解釋，因為有興趣的人可以在網路上找到大量的解釋。然而，我經常想知道這句話如何應用於程式設計和開源開發。 ### 我們的程式設計知識真的是我們自己的嗎？ 網路上有很多資源可以教您幾乎所有與程式設計相關的知識。我自己和我的許多同學幾乎所有的程式設計知識都是從教科書、線上資源/文件和 YouTube 教學中學到的。這些資源教會了我們今天擁有並應用的程式設計知識，但是所有這些知識都被盜了嗎？如果您從數千人觀看的 YouTube 教程中學會了編寫第一個“Hello World”程序，您是否在竊取程式碼？影片上傳者也學會使用外部資源編寫「Hello World」程式的可能性有多大？上傳者的知識被偷了嗎？ 我不能說這些知識是否被盜，但我相信這種知識對於我們建立和擴展我們的技能是必要的。沒有人能夠知道每一個完美的實現，或是為每個專案編寫每一行程式碼。 ### 開源軟體是為使用而生的！ 開源軟體的存在不應該被忽視，開源軟體是用來使用的！如果開源專案提供了您需要的功能，那麼當其他人為您精心完成這些功能時，為什麼還要自己實現這些功能呢？只要該庫得到積極維護並滿足您的需要，您就應該使用和研究開源庫。如果您發現任何錯誤、問題或缺少的功能，請嘗試建立自己的解決方案並為該專案做出貢獻，使其對每個人都更好！同樣，如果開源程式庫提供了您需要的功能，但您無法整合該程式庫，請以開源專案為靈感，在您自己的專案中實現該功能。 ### 從其他專案中獲取靈感 在我之前的[關於程式碼閱讀的部落格文章](https://dev.to/rjwignar/code-reading-i7h)中，我閱讀了Docusaurus 的程式碼庫來研究該專案如何為受保護的程式碼區塊實現語法突出顯示。我的研究告訴我，Docusaurus 實際上使用第三方函式庫 [Prism-React-Renderer](https://github.com/FormidableLabs/prism-react-renderer) 來提供語法突出顯示。這些知識很有用，因為我想在我的 Markdown 到 HTML 轉換器 [ctil](https://github.com/rjwignar/ctil) 新增語法突出顯示，但不想從頭開始實現該功能。雖然我無法在自己的專案中使用 Prism React Renderer，但研究 Docusaurus 給了我找到一個我可以使用的開源程式庫的想法。 ### 使用highlight.js 進行語法高亮顯示 在搜尋第三方語法螢光筆時，我找到了 [highlight.js](https://highlightjs.org/)。 ctil 將文字（`.txt`）和 Markdown （`.md`）轉換為生成的 HTML（`.html`）文件，因此我希望生成的 HTML 文件支援語法突出顯示。透過使用內容分發網路（CDN），highlight.js 可以用作 HTML 標籤，因此我可以透過將以下行新增至產生的 HTML 檔案來新增highlight.js： ``` <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/styles/default.min.css"> <script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/highlight.min.js"></script> <script>hljs.highlightAll();</script> ``` 透過這些行，我能夠[加入語法突出顯示](https://github.com/rjwignar/ctil/commit/c597f05724b60731e129aead33f1c3017a99ec17)：  ### 與 Docusaurus 方法的比較 在我的[上一篇部落格文章](https://dev.to/rjwignar/code-reading-i7h)中，我描述了 Docusaurus 如何使用 Prism React Renderer 新增語法突出顯示。與 Docusaurus 一樣，我使用了第三方函式庫highlight.js 來加入語法突出顯示。然而，在 Docusaurus 中新增和修改了設定檔以設定 Prism React Renderer，並透過使用「<Highlight />」元件加入了語法突出顯示。 Prism React Renderer 還提供了使用者可以在其專案中配置的突出顯示主題。對於我的專案，只需將highlight.js 加入到生成的 HTML 文件中，作為要透過 CDN 傳送的 HTML 標籤。現在我對基本的語法突出顯示感到滿意，所以我不關心有一個特定的突出顯示主題。透過 CDN 使用highlight.js 的一個缺點是，如果使用者在線，語法突出顯示可能無法運作。將來我可能會將highlight.js加入到專案本身中，這樣語法突出顯示就可以離線工作。 ### 下一步。 此功能仍在開發中。在目前迭代中，html 用作 `<code>...</code>` 區塊的預設語言類別。目前這是可以接受的，但此解決方案將忽略原始 Markdown 文件中的任何語言類設定。我希望 ctil 解析 Markdown 文件中的語言標籤，以確定使用哪種語言進行突出顯示。這將是未來需要解決的問題。有興趣的人可以在[此處](https://github.com/rjwignar/ctil/issues/11)找到問題。 ### 那麼從開源專案複製程式碼算不算偷竊？ 只要專案許可證允許複製，並且您遵循專案許可證的要求，您就不會竊取。同樣，我認為從開源專案中尋找靈感並不是偷竊。
原文出處：https://dev.to/m_midas/44-react-frontend-interview-questions-2o63 ## 介紹 在面試 React 前端開發人員職位時，為技術問題做好充分準備至關重要。 React 已經成為建立使用者介面最受歡迎的 JavaScript 程式庫之一，雇主通常專注於評估候選人對 React 核心概念、最佳實踐和相關技術的理解。在本文中，我們將探討 React 前端開發人員面試期間常見問題的完整清單。透過熟悉這些問題及其答案，您可以增加成功的機會並展示您在 React 開發方面的熟練程度。因此，讓我們深入探討您應該準備好在 React 前端開發人員面試中解決的關鍵主題。  ### 1.你知道哪些React hooks？ - `useState`：用於管理功能元件中的狀態。 - `useEffect`：用於在功能元件中執行副作用，例如取得資料或訂閱事件。 - `useContext`：用於存取功能元件內的 React 上下文的值。 - `useRef`：用於建立對跨渲染持續存在的元素或值的可變引用。 - `useCallback`：用於記憶函數以防止不必要的重新渲染。 - `useMemo`：用於記憶值，透過快取昂貴的計算來提高效能。 - `useReducer`：用於使用reducer函數管理狀態，類似於Redux的工作方式。 - `useLayoutEffect`：與 useEffect 類似，但效果在所有 DOM 變更後同步運作。 這些鉤子提供了強大的工具來管理狀態、處理副作用以及重複使用 React 功能元件中的邏輯。 [了解更多](https://react.dev/reference/react) ### 2.什麼是虛擬 DOM？ 虛擬 DOM 是 React 中的一個概念，其中建立實際 DOM（文件物件模型）的輕量級虛擬表示並將其儲存在記憶體中。它是一種用於優化 Web 應用程式效能的程式設計技術。 當 React 元件的資料或狀態發生變更時，虛擬 DOM 會被更新，而不是直接操作真實 DOM。然後，虛擬 DOM 計算元件的先前狀態和更新狀態之間的差異，稱為「比較」過程。 一旦辨識出差異，React 就會有效地僅更新真實 DOM 的必要部分以反映變更。這種方法最大限度地減少了實際 DOM 操作的數量，並提高了應用程式的整體效能。 透過使用虛擬 DOM，React 提供了一種建立動態和互動式使用者介面的方法，同時確保最佳效率和渲染速度。 ### 3. 如何渲染元素陣列？ 要渲染元素陣列，可以使用“map()”方法迭代該陣列並傳回一個新的 React 元素陣列。 ``` const languages = [ "JavaScript", "TypeScript", "Python", ]; function App() { return ( <div> <ul>{languages.map((language) => <li>{language}</li>)}</ul> </div> ); } ``` [了解更多](https://react.dev/learn/rendering-lists) ### 4. 受控元件和非受控元件有什麼不同？ 受控元件和非受控元件之間的區別在於**它們如何管理和更新其狀態**。 受控元件是狀態由 React 控制的元件。元件接收其當前值並透過 props 更新它。當值改變時它也會觸發回調函數。這意味著該元件不儲存其自己的內部狀態。相反，父元件管理該值並將其傳遞給受控元件。 ``` import { useState } from 'react'; function App() { const [value, setValue] = useState(''); return ( <div> <h3>Controlled Component</h3> <input name="name" value={name} onChange={(e) => setValue(e.target.value)} /> <button onClick={() => console.log(value)}>Get Value</button> </div> ); } ``` 另一方面，不受控制的元件使用 refs 或其他方法在內部管理自己的狀態。它們獨立儲存和更新狀態，不依賴 props 或回呼。父元件對不受控元件的狀態控制較少。 ``` import { useRef } from 'react'; function App() { const inputRef = useRef(null); return ( <div className="App"> <h3>Uncontrolled Component</h3> <input type="text" name="name" ref={inputRef} /> <button onClick={() => console.log(inputRef.current.value)}>Get Value</button> </div> ); } ``` [了解更多](https://react.dev/learn/sharing-state- Between-components#driven-and-uncontrol-components) ### 5. 基於類別的 React 元件和函數式 React 元件有什麼不同？ 基於類別的元件和函數式元件之間的主要區別在於**它們的定義方式以及它們使用的語法。** 基於類別的元件被定義為 ES6 類別並擴展了 `React.Component` 類別。他們使用「render」方法傳回定義元件輸出的 JSX (JavaScript XML)。類別元件可以透過「this.state」和「this.setState()」存取元件生命週期方法和狀態管理。 ``` class App extends React.Component { state = { value: 0, }; handleAgeChange = () => { this.setState({ value: this.state.value + 1 }); }; render() { return ( <> <p>Value is {this.state.value}</p> <button onClick={this.handleAgeChange}> Increment value </button> </> ); } } ``` 另一方面，函數元件被定義為簡單的 JavaScript 函數。他們接受 props 作為參數並直接返回 JSX。功能元件無權存取生命週期方法或狀態。然而，隨著 React 16.8 中 React Hooks 的引入，功能元件現在可以管理狀態並使用其他功能，例如上下文和效果。 ``` import { useState } from 'react'; const App = () => { const [value, setValue] = useState(0); const handleAgeChange = () => { setValue(value + 1); }; return ( <> <p>Value is {value}</p> <button onClick={handleAgeChange}> Increment value </button> </> ); } ``` 一般來說，功能元件被認為更簡單、更容易閱讀和測試。建議盡可能使用函數式元件，除非有特定需要基於類別的元件。 ### 6. 元件的生命週期方法有哪些？ 生命週期方法是一種掛鉤元件生命週期不同階段的方法，可讓您在特定時間執行特定程式碼。 以下是主要生命週期方法的清單： 1. `constructor`：這是建立元件時呼叫的第一個方法。它用於初始化狀態和綁定事件處理程序。在功能元件中，您可以使用“useState”鉤子來實現類似的目的。 2. `render`：此方法負責渲染 JSX 標記並傳回螢幕上要顯示的內容。 3. `componentDidMount`：元件在 DOM 中渲染後立即呼叫該方法。它通常用於初始化任務，例如 API 呼叫或設定事件偵聽器。 4. `componentDidUpdate`：當元件的 props 或 state 改變時呼叫該方法。它允許您執行副作用、根據更改更新元件或觸發其他 API 呼叫。 5. `componentWillUnmount`：在元件從 DOM 刪除之前呼叫此方法。它用於清理在`componentDidMount`中設定的任何資源，例如刪除事件偵聽器或取消計時器。 一些生命週期方法，例如“componentWillMount”、“componentWillReceiveProps”和“componentWillUpdate”，已被棄用或替換為替代方法或掛鉤。 至於“this”，它指的是類別元件的當前實例。它允許您存取元件內的屬性和方法。在函數式元件中，不使用“this”，因為函數未綁定到特定實例。 ### 7. 使用 useState 有什麼特色？ `useState` 傳回一個狀態值和一個更新它的函數。 ``` const [value, setValue] = useState('Some state'); ``` 在初始渲染期間，傳回的狀態與作為第一個參數傳遞的值相符。 `setState` 函數用於更新狀態。它採用新的狀態值作為參數，並**對元件的重新渲染進行排隊**。 `setState` 函數也可以接受回呼函數作為參數，該函數將先前的狀態值作為參數。 [了解更多](https://react.dev/reference/react/useState) ### 8. 使用 useEffect 有什麼特別之處？ `useEffect` 鉤子可讓您在功能元件中執行副作用。 稱為 React 渲染階段的功能元件的主體內部不允許突變、訂閱、計時器、日誌記錄和其他副作用。這可能會導致用戶介面中出現令人困惑的錯誤和不一致。 相反，建議使用 useEffect。傳遞給 useEffect 的函數將在渲染提交到螢幕後執行，或者如果您傳遞一組依賴項作為第二個參數，則每次依賴項之一發生變更時都會呼叫該函數。 ``` useEffect(() => { console.log('Logging something'); }, []) ``` [了解更多](https://react.dev/reference/react/useEffect) ### 9. 如何追蹤功能元件的卸載？ 通常，「useEffect」會建立在元件離開畫面之前需要清理或重設的資源，例如訂閱或計時器辨識碼。 為了做到這一點，傳遞給`useEffect`的函數可以傳回一個**清理函數**。清理函數在元件從使用者介面刪除之前執行，以防止記憶體洩漏。此外，如果元件渲染多次（通常是這種情況），則在執行下一個效果之前會清除上一個效果。 ``` useEffect(() => { function handleChange(value) { setValue(value); } SomeAPI.doFunction(id, handleChange); return function cleanup() { SomeAPI.undoFunction(id, handleChange); }; }) ``` ### 10. React 中的 props 是什麼？ Props 是從父元件傳遞給元件的資料。道具 是唯讀的，無法更改。 ``` // Parent component const Parent = () => { const data = "Hello, World!"; return ( <div> <Child data={data} /> </div> ); }; // Child component const Child = ({ data }) => { return <div>{data}</div>; }; ``` [了解更多](https://react.dev/learn/passing-props-to-a-component) ### 11. 什麼是狀態管理器？您曾與哪些狀態管理器合作過或認識哪些狀態管理器？ 狀態管理器是幫助管理應用程式狀態的工具或程式庫。它提供了一個集中式儲存或容器來儲存和管理可由應用程式中的不同元件存取和更新的資料。 狀態管理器可以解決幾個問題。首先，將資料和與其相關的邏輯與元件分開是一個很好的做法。其次，當使用本機狀態並在元件之間傳遞它時，由於元件可能存在深層嵌套，程式碼可能會變得複雜。透過擁有全域存儲，我們可以存取和修改來自任何元件的資料。 除了 React Context，Redux 或 MobX 通常用作狀態管理庫。 [了解更多](https://mobx.js.org/README.html) [了解更多](https://redux-toolkit.js.org/) ### 12. 在什麼情況下可以使用本地狀態，什麼時候應該使用全域狀態？ 如果本機狀態僅在一個元件中使用且不打算將其傳遞給其他元件，則建議使用本機狀態。本地狀態也用在表示清單中單一專案的元件中。但是，如果元件分解涉及嵌套元件且資料沿層次結構傳遞，則最好使用全域狀態。 ### 13. Redux中的reducer是什麼，它需要哪些參數？ 減速器是一個純函數，它將狀態和操作作為參數。在減速器內部，我們追蹤接收到的操作的類型，並根據它修改狀態並傳回一個新的狀態物件。 ``` export default function appReducer(state = initialState, action) { // The reducer normally looks at the action type field to decide what happens switch (action.type) { // Do something here based on the different types of actions default: // If this reducer doesn't recognize the action type, or doesn't // care about this specific action, return the existing state unchanged return state } } ``` [了解更多](https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers) ### 14. 什麼是操作以及如何更改 Redux 中的狀態？ Action 是一個簡單的 JavaScript 物件，必須有一個字段 一種。 ``` { type: "SOME_TYPE" } ``` 您也可以選擇新增一些資料作為**有效負載**。為了 改變狀態，需要呼叫我們傳遞給它的調度函數 行動 ``` { type: "SOME_TYPE", payload: "Any payload", } ``` [了解更多](https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers) ### 15. Redux 實作了哪一種模式？ Redux 實作了 **Flux 模式**，這是應用程式可預測的狀態管理模式。它透過引入單向資料流和應用程式狀態的集中儲存來幫助管理應用程式的狀態。 [了解更多](https://www.newline.co/fullstack-react/30-days-of-react/day-18/#:~:text=Flux%20is%20a%20pattern%20for,default% 20method %20用於%20處理%20資料。） ### 16. Mobx 實作哪一種模式？ Mobx 實作了**觀察者模式**，也稱為發布-訂閱模式。 [了解更多](https://www.patterns.dev/posts/observer-pattern) ### 17. 使用 Mobx 的特徵是什麼？ Mobx 提供了「observable」和「compulated」等裝飾器來定義可觀察狀態和反應函數。以action修飾的動作用於修改狀態，確保追蹤所有變更。 Mobx 還提供自動依賴追蹤、不同類型的反應、對反應性的細粒度控制，以及透過 mobx-react 套件與 React 無縫整合。總體而言，Mobx 透過根據可觀察狀態的變化自動執行更新過程來簡化狀態管理。 ### 18.如何存取Mobx狀態下的變數？ 您可以透過使用「observable」裝飾器將變數定義為可觀察來存取狀態中的變數。這是一個例子： ``` import { observable, computed } from 'mobx'; class MyStore { @observable myVariable = 'Hello Mobx'; @computed get capitalizedVariable() { return this.myVariable.toUpperCase(); } } const store = new MyStore(); console.log(store.capitalizedVariable); // Output: HELLO MOBX store.myVariable = 'Hi Mobx'; console.log(store.capitalizedVariable); // Output: HI MOBX ``` 在此範例中，使用“observable”裝飾器將“myVariable”定義為可觀察物件。然後，您可以使用“store.myVariable”存取該變數。對「myVariable」所做的任何變更都會自動觸發相關元件或反應的更新。 [了解更多](https://mobx.js.org/actions.html) ### 19.Redux 和 Mobx 有什麼差別？ Redux 是一個更簡單、更固執己見的狀態管理庫，遵循嚴格的單向資料流並促進不變性。它需要更多的樣板程式碼和顯式更新，但與 React 具有出色的整合。 另一方面，Mobx 提供了更靈活、更直觀的 API，且樣板程式碼更少。它允許您直接修改狀態並自動追蹤更改以獲得更好的性能。 Redux 和 Mobx 之間的選擇取決於您的特定需求和偏好。 ### 20.什麼是 JSX？ 預設情況下，以下語法用於在 React 中建立元素。 ``` const someElement = React.createElement( 'h3', {className: 'title__value'}, 'Some Title Value' ); ``` 但我們已經習慣這樣看 ``` const someElement = ( <h3 className='title__value'>Some Title Value</h3> ); ``` 這正是標記所謂的 jsx。這是一種語言的擴展 簡化對程式碼和開發的認知 [了解更多](https://react.dev/learn/writing-markup-with-jsx#jsx-putting-markup-into-javascript) ### 21.什麼是道具鑽探？ Props 鑽取是指透過多層嵌套元件傳遞 props 的過程，即使某些中間元件不直接使用這些 props。這可能會導致程式碼結構複雜且繁瑣。 ``` // Parent component const Parent = () => { const data = "Hello, World!"; return ( <div> <ChildA data={data} /> </div> ); }; // Intermediate ChildA component const ChildA = ({ data }) => { return ( <div> <ChildB data={data} /> </div> ); }; // Leaf ChildB component const ChildB = ({ data }) => { return <div>{data}</div>; }; ``` 在此範例中，「data」屬性從 Parent 元件傳遞到 ChildA，然後從 ChildA 傳遞到 ChildB，即使 ChildA 不會直接使用該屬性。當存在許多層級的嵌套或當元件樹中更靠下的元件需要存取資料時，這可能會成為問題。它會使程式碼更難維護和理解。 可以透過使用其他模式（如上下文或狀態管理庫（如 Redux 或 MobX））來緩解 Props 鑽探。這些方法允許元件存取資料，而不需要透過每個中間元件傳遞 props。 ### 22. 如何有條件地渲染元素？ 您可以使用任何條件運算符，包括三元。 ``` return ( <div> {isVisible && <span>I'm visible!</span>} </div> ); ``` ``` return ( <div> {isOnline ? <span>I'm online!</span> : <span>I'm offline</span>} </div> ); ``` ``` if (isOnline) { element = <span>I'm online!</span>; } else { element = <span>I'm offline</span>; } return ( <div> {element} </div> ); ``` [了解更多](https://react.dev/learn/conditional-rendering) ### 23. useMemo 的用途是什麼？它是如何運作的？ `useMemo` 用於緩存和記憶 計算結果。 傳遞建立函數和依賴項陣列。只有當任何依賴項的值發生變更時，`useMemo` 才會重新計算記憶值。此優化有助於避免 每次渲染都需要昂貴的計算。 使用第一個參數，函數接受執行計算的回調，使用第二個依賴項陣列，僅當至少一個依賴項發生變更時，該函數才會重新執行計算。 ``` const memoValue = useMemo(() => computeFunc(paramA, paramB), [paramA, paramB]); ``` [了解更多](https://react.dev/reference/react/useMemo) ### 24. useCallback 的用途是什麼？它是如何運作的？ `useCallback` 掛鉤將傳回回呼的記憶版本，僅當依賴項之一的值發生變更時，該版本才會變更。 當將回調傳遞給依賴連結相等性來防止不必要的渲染的最佳化子元件時，這非常有用。 ``` const callbackValue = useCallback(() => computeFunc(paramA, paramB), [paramA, paramB]); ``` [了解更多](https://react.dev/reference/react/useCallback) ### 25. useMemo 和 useCallback 有什麼不同？ 1. `useMemo` 用於儲存計算結果，而 `useCallback` 用於儲存函數本身。 2. `useMemo` 快取計算值，如果依賴項沒有改變，則在後續渲染時傳回它。 3. `useCallback` 快取函數本身並傳回相同的實例，除非相依性發生變更。 ### 26.什麼是 React Context？ React Context 是一項功能，它提供了一種透過元件樹傳遞資料的方法，而無需在每個層級手動傳遞 props。它允許您建立一個全域狀態，樹中的任何元件都可以存取該狀態，無論其位置如何。當您需要在未透過 props 直接連接的多個元件之間共用資料時，上下文就非常有用。 React Context API 由三個主要部分組成： 1. `createContext`：此函數用於建立一個新的上下文物件。 2. `Context.Provider`：該元件用於向上下文提供值。它包裝了需要存取該值的元件。 3. `Context.Consumer` 或 `useContext` 鉤子：此元件或鉤子用於使用上下文中的值。它可以在上下文提供者內的任何元件中使用。 透過使用 React Context，您可以避免道具鑽探（透過多個層級的元件傳遞道具）並輕鬆管理更高層級的狀態，使您的程式碼更有組織性和效率。 [了解更多](https://react.dev/learn/passing-data-deeply-with-context) ### 27. useContext 的用途是什麼？它是如何運作的？ 在典型的 React 應用程式中，資料使用 props 從上到下（從父元件到子元件）傳遞。但這樣的使用方法對於某些類型的道具來說可能過於繁瑣 （例如，所選語言、UI 主題），必須傳遞給應用程式中的許多元件。上下文提供了一種在元件之間共享此類資料的方法，而無需明確傳遞 props 樹的每一層。 呼叫 useContext 的元件將始終在以下情況下重新渲染： 上下文值發生變化。如果重新渲染元件的成本很高，您可以使用記憶來優化它。 ``` const App = () => { const theme = useContext(ThemeContext); return ( <div style={{ color: theme.palette.primary.main }}> Some div </div> ); } ``` [了解更多](https://react.dev/reference/react/useContext) ### 28. useRef 的用途是什麼？它是如何運作的？ `useRef` 傳回一個可修改的 ref 物件，一個屬性。其中的當前值由傳遞的參數初始化。傳回的物件將在元件的整個生命週期內持續存在，並且不會因渲染而改變。 通常的用例是以命令式存取後代 風格。 IE。使用 ref，我們可以明確引用 DOM 元素。 ``` const App = () => { const inputRef = useRef(null); const buttonClick = () => { inputRef.current.focus(); } return ( <> <input ref={inputRef} type="text" /> <button onClick={buttonClick}>Focus on input tag</button> </> ) } ``` [了解更多](https://react.dev/reference/react/useRef) ### 29. 什麼是 React.memo()？ `React.memo()` 是一個高階元件。如果您的元件始終使用不變的 props 渲染相同的內容，您可以將其包裝在「React.memo()」呼叫中，以在某些情況下提高效能，從而記住結果。這意味著 React 將使用上次渲染的結果，避免重新渲染。 `React.memo()` 只影響 props 的變更。如果一個功能元件被包裝在 React.memo 中並使用 useState、useReducer 或 useContext，那麼當狀態或上下文發生變化時，它將重新渲染。 ``` import { memo } from 'react'; const MemoComponent = memo(MemoComponent = (props) => { // ... }); ``` [了解更多](https://react.dev/reference/react/memo) ### 30.React Fragment是什麼？ 從元件傳回多個元素是 React 中的常見做法。片段可讓您形成子元素列表，而無需在 DOM 中建立不必要的節點。 ``` <> <OneChild /> <AnotherChild /> </> // or <React.Fragment> <OneChild /> <AnotherChild /> </React.Fragment> ``` [了解更多](https://react.dev/reference/react/Fragment) ### 31.什麼是 React Reconciliation？ 協調是一種 React 演算法，用於區分一棵元素樹與另一棵元素樹，以確定需要替換的部分。 協調是我們過去所說的虛擬 DOM 背後的演算法。這個定義聽起來是這樣的：當你渲染一個 React 應用程式時，描述該應用程式的元素樹是在保留的記憶體中產生的。然後這棵樹被包含在渲染環境中——例如，瀏覽器應用程式，它被翻譯成一組 DOM 操作。當應用程式狀態更新時，會產生一棵新樹。將新樹與前一棵樹進行比較，以便準確計算並啟用重繪更新的應用程式所需的操作。 [了解更多](https://react.dev/learn/preserving-and-resetting-state) ### 32.為什麼使用map()時需要列表中的鍵？ 這些鍵可幫助 React 確定哪些元素已更改， 新增或刪除。必須指定它們以便 React 可以匹配 隨著時間的推移陣列元素。選擇鍵的最佳方法是使用能夠清楚區分清單專案與其鄰居的字串。大多數情況下，您將使用資料中的 ID 作為金鑰。 ``` const languages = [ { id: 1, lang: "JavaScript", }, { id: 2, lang: "TypeScript", }, { id: 3, lang: "Python", }, ]; const App = () => { return ( <div> <ul>{languages.map((language) => ( <li key={`${language.id}_${language.lang}`}>{language.lang}</li> ))} </ul> </div> ); } ``` [了解更多](https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key) ### 33. 如何在 Redux Thunk 中處理非同步操作？ 要使用 Redux Thunk，您需要將其作為中間件導入。動作建立者不僅應該傳回一個物件，還應該傳回以調度為參數的函數。 ``` export const addUser = ({ firstName, lastName }) => { return dispatch => { dispatch(addUserStart()); } axios.post('https://jsonplaceholder.typicode.com/users', { firstName, lastName, completed: false }) .then(res => { dispatch(addUserSuccess(res.data)); }) .catch(error => { dispatch(addUserError(error.message)); }) } ``` [了解更多](https://redux.js.org/usage/writing-logic-thunks) ### 34.如何追蹤功能元件中物件欄位的變化？ 為此，您需要使用“useEffect”掛鉤並將物件的欄位作為依賴項陣列傳遞。 ``` useEffect(() => { console.log('Changed!') }, [obj.someField]) ``` ### 35.如何存取DOM元素？ 引用是使用 React.createRef() 或 useRef() 鉤子建立的，並透過 ref 屬性附加到 React 元素。透過存取已建立的引用，我們可以使用「ref.current」來存取 DOM 元素。 ``` const App = () => { const myRef = useRef(null); const handleClick = () => { console.log(myRef.current); // Accessing the DOM element }; return ( <div> <input type="text" ref={myRef} /> <button onClick={handleClick}>Click Me</button> </div> ); } export default App; ``` ### 36.什麼是自訂鉤子？ 自訂鉤子是一個允許您在不同元件之間重複使用邏輯的功能。它是一種封裝可重複使用邏輯的方法，以便可以在多個元件之間輕鬆共用和重複使用。自訂掛鉤是通常以 **use ** 開頭的函數，並且可以根據需要呼叫其他掛鉤。 [了解更多](https://react.dev/learn/reusing-logic-with-custom-hooks) ### 37.什麼是公共API？ 在索引檔案的上下文中，公共 API 通常是指向外部模組或元件公開並可存取的介面或函數。 以下是表示公共 API 的索引檔案的程式碼範例： ``` // index.js export function greet(name) { return `Hello, ${name}!`; } export function calculateSum(a, b) { return a + b; } ``` 在此範例中，index.js 檔案充當公共 API，其中導出函數“greet()”和“calculateSum()”，並且可以透過匯入它們從其他模組存取它們。其他模組可以導入並使用這些函數作為其實現的一部分： ``` // main.js import { greet, calculateSum } from './index.js'; console.log(greet('John')); // Hello, John! console.log(calculateSum(5, 3)); // 8 ``` 透過從索引檔案匯出特定函數，我們定義了模組的公共 API，允許其他模組使用這些函數。 ### 38. 建立自訂鉤子的規則是什麼？ 1. 鉤子名稱以「use」開頭。 2. 如果需要，使用現有的鉤子。 3. 不要有條件地呼叫鉤子。 4. 將可重複使用邏輯提取到自訂掛鉤中。 5. 自訂hook必須是純函數。 6. 自訂鉤子可以傳回值或其他鉤子。 7. 描述性地命名自訂掛鉤。 [了解更多](https://react.dev/learn/reusing-logic-with-custom-hooks) ### 39.什麼是SSR（伺服器端渲染）？ 伺服器端渲染（SSR）是一種用於在伺服器上渲染頁面並將完整渲染的頁面傳送到客戶端進行顯示的技術。它允許伺服器產生網頁的完整 HTML 標記（包括其動態內容），並將其作為對請求的回應傳送到客戶端。 在傳統的用戶端渲染方法中，用戶端接收最小的 HTML 頁面，然後向伺服器發出額外的資料和資源請求，這些資料和資源用於在客戶端渲染頁面。這可能會導致初始頁面載入時間變慢，並對搜尋引擎優化 (SEO) 產生負面影響，因為搜尋引擎爬蟲很難對 JavaScript 驅動的內容建立索引。 透過 SSR，伺服器透過執行必要的 JavaScript 程式碼來產生最終的 HTML 來負責渲染網頁。這意味著客戶端從伺服器接收完全呈現的頁面，從而減少了額外資源請求的需要。 SSR 縮短了初始頁面載入時間，並允許搜尋引擎輕鬆索引內容，從而實現更好的 SEO。 SSR 通常用於框架和函式庫中，例如用於 React 的 Next.js 和用於 Vue.js 的 Nuxt.js，以啟用伺服器端渲染功能。這些框架為您處理伺服器端渲染邏輯，讓實作 SSR 變得更加容易。 ### 40.使用SSR有什麼好處？ 1. **改進初始載入時間**：SSR 允許伺服器將完全渲染的 HTML 頁面傳送到客戶端，從而減少客戶端所需的處理量。這可以縮短初始載入時間，因為使用者可以更快地看到完整的頁面。 2. **SEO友善**：搜尋引擎可以有效地抓取和索引SSR頁面的內容，因為完全渲染的HTML在初始回應中可用。這提高了搜尋引擎的可見度並有助於更好的搜尋排名。 3. **可存取性**：SSR 確保禁用 JavaScript 或使用輔助技術的使用者可以存取內容。透過在伺服器上產生 HTML，SSR 為所有使用者提供可靠且易於存取的使用者體驗。 4. **低頻寬環境下的效能**：SSR減少了客戶端需要下載的資料量，有利於低頻寬或高延遲環境下的使用者。這對於行動用戶或網路連線速度較慢的用戶尤其重要。 雖然 SSR 提供了這些優勢，但值得注意的是，與客戶端渲染方法相比，它可能會帶來更多的伺服器負載和維護複雜性。應仔細考慮快取、可擴展性和伺服器端渲染效能最佳化等因素。 ### 41.你知道Next.js的主要功能有哪些？ 1. `getStaticProps`：此方法用於在建置時取得資料並將頁面預先渲染為靜態 HTML。它確保資料在建置時可用，並且不會因後續請求而更改。 ``` export async function getStaticProps() { const res = await fetch('https://api.example.com/data'); const data = await res.json(); return { props: { data } }; } ``` 2. `getServerSideProps`：此方法用於在每個請求上取得資料並在伺服器上預先渲染頁面。當您需要取得可能經常變更或特定於使用者的資料時，可以使用它。 ``` export async function getServerSideProps() { const res = await fetch('https://api.example.com/data'); const data = await res.json(); return { props: { data } }; } ``` 3. `getStaticPaths`：此方法在動態路由中使用，用於指定建置時應預先渲染的路徑清單。它通常用於獲取帶有參數的動態路由的資料。 ``` export async function getStaticPaths() { const res = await fetch('https://api.example.com/posts'); const posts = await res.json(); const paths = posts.map((post) => ({ params: { id: post.id } })); return { paths, fallback: false }; } ``` [了解更多](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating) ### 42.什麼是 Linters？ Linters 是用來檢查原始程式碼是否有潛在錯誤、錯誤、風格不一致和可維護性問題的工具。它們可幫助執行編碼標準並確保整個程式碼庫的程式碼品質和一致性。 Linters 的工作原理是掃描原始程式碼並將其與一組預先定義的規則或指南進行比較。這些規則可以包括語法和格式約定、最佳實踐、潛在錯誤和程式碼異味。當 linter 發現違反規則時，它會產生警告或錯誤，突出顯示需要注意的特定行或多行程式碼。 使用 linter 可以帶來幾個好處： 1. **程式碼品質**：Linter 有助於辨識和防止潛在的錯誤、程式碼異味和反模式，從而提高程式碼品質。 2. **一致性**：Linter 強制執行編碼約定和風格指南，確保整個程式碼庫的格式和程式碼結構一致，即使多個開發人員正在處理同一個專案時也是如此。 3. **可維護性**：透過儘早發現問題並促進良好的編碼實踐，linter 有助於程式碼的可維護性，使程式碼庫更容易理解、修改和擴展。 4. **效率**：Linter 可以透過自動化程式碼審查流程並在常見錯誤在開發或生產過程中引起問題之前捕獲它們來節省開發人員的時間。 一些流行的 linter 包括用於 JavaScript 的 ESLint 以及用於 CSS 和 Sass 的 Stylelint。 [了解更多](https://eslint.org/docs/latest/use/getting-started) ### 43.你知道哪些 React 架構解決方案？ 有多種用於建立 React 專案的架構解決方案和模式。一些受歡迎的包括： 1. **MVC（模型-視圖-控制器）**：MVC 是一種傳統的架構模式，它將應用程式分為三個主要元件 - 模型、視圖和控制器。 React 可以在 View 層中使用來渲染 UI，而其他程式庫或框架可以用於 Model 和 Controller 層。 2. **Flux**：Flux是Facebook專門針對React應用程式所推出的應用架構。它遵循單向資料流，其中資料沿著單一方向流動，從而更容易理解和除錯應用程式的狀態變更。 3. **原子設計**：原子設計並不是React特有的，而是將UI分割成更小、可重複使用元件的設計方法。它鼓勵建立小型、獨立且可以組合以建立更複雜的 UI 的元件。 4. **容器和元件模式**：此模式將表示（元件）與邏輯和狀態管理（容器）分開。元件負責渲染 UI，而容器則處理業務邏輯和狀態管理。 5. **功能切片設計**：它是一種用於組織和建構 React 應用程式的現代架構方法。它旨在透過根據功能或模組劃分應用程式程式碼庫來解決可擴展性、可維護性和可重用性的挑戰。 ### 44.什麼是特徵切片設計？ 它是一種用於組織和建立 React 應用程式的現代架構方法。它旨在透過根據功能或模組劃分應用程式程式碼庫來解決可擴展性、可維護性和可重用性的挑戰。 在功能切片設計中，應用程式的每個功能或模組都組織到一個單獨的目錄中，其中包含所有必要的元件、操作、reducers 和其他相關檔案。這有助於保持程式碼庫的模組化和隔離性，使其更易於開發、測試和維護。 功能切片設計促進了關注點的清晰分離，並將功能封裝在各個功能中。這允許不同的團隊或開發人員獨立地處理不同的功能，而不必擔心衝突或依賴性。  **我強烈建議點擊“了解更多”按鈕以了解功能切片設計** [了解更多](https://dev.to/m_midas/feature-sliced-design-the-best-frontend-architecture-4noj) ## 了解更多 如果您還沒有閱讀過，我強烈建議您閱讀我關於前端面試問題的其餘文章。 https://dev.to/m_midas/52-frontend-interview-questions-javascript-59h6 https://dev.to/m_midas/41-frontend-interview-questions-css-4imc https://dev.to/m_midas/15-most-common-frontend-interview-questions-4njp ## 結論 總之，面試 React 前端開發人員職位需要對框架的核心概念、原理和相關技術有深入的了解。透過準備本文中討論的問題，您可以展示您的 React 知識並展示您建立高效且可維護的使用者介面的能力。請記住，不僅要專注於記住答案，還要理解基本概念並能夠清楚地解釋它們。 此外，請記住，面試不僅涉及技術方面，還旨在展示您解決問題的能力、溝通能力以及團隊合作能力。透過將技術專業知識與強大的整體技能相結合，您將具備在 React 前端開發人員面試中脫穎而出的能力，並在這個令人興奮且快速發展的領域找到您夢想的工作。 祝你好運！
大家好，我想鼓勵一些想要開始當工程師，但很難找到第一份工作的人。還有那些因為懷疑自己的能力而難以開始/完成專案的人（冒牌者症候群）。我將告訴你我自己的旅程，以及我一路上學到的東西來，希望你能有動力繼續你的旅程。 原文出處：https://dev.to/chaoocharles/how-creating-content-as-a-developer-changed-my-life-270e 我叫查爾斯，來自非洲肯亞。我早在 2016 年就開始了我的編碼之旅，當時我進入大學，在 BTECH I.T 尋求職業生涯。在此之前，我對電腦了解不多，我只知道它們很酷，我想研究它們。在高中時，我是一名表現最好的學生，我的英語老師（也是副手，哈哈）認為我想做一些像計算機這樣簡單的事情而不是像工程、醫學、飛行員等更專業、更有前途的職業，這是愚蠢的，你說出它們的名字。好訊息是我沒有聽，而是去做了我想要的事情，而且我不會為此感到後悔。事實是，IT 領域的任何職業都是當今世界上最好的職業之一，世界頂級公司之所以能處於領先地位，是因為程式碼。看看 Netflix、亞馬遜、微軟、Facebook、Airbnb 或 Uber。所有這些公司都透過程式碼賺了數十億美元，因此不要讓任何人欺騙您，讓您認為您走在錯誤的道路上。我來這裡是為了告訴你，你正走在最好的道路上。 回想2016年剛入職第一年的時候，由於出身卑微，擁有一台筆記型電腦對我來說是非常困難的，即使是一台簡單的筆記型電腦，甚至是二手的筆記型電腦。如果我要做 I.T，那麼擁有一個對我來說也是強制性的。擁有一部像樣的智慧型手機也是一個問題，但幸運的是，我有一個三星口袋（那些小三星手機，如果你還記得的話），並在說服朋友用它與我交換一些錢和一部按鍵手機後。這款手機在這個故事中很重要，因為它是我用來開始學習程式設計的手機。在學校裡，我們被教導如何編碼，是的，但這還不夠，它主要是理論。關於編碼的事情是你必須_練習_、_練習_、再_練習_。於是，我從同學那裡了解到了一個名為sololearn的應用程式。我在那裡開始學習 Web 開發，包括 html、css、javascript、php、sql，我想還有一點 jquery。這個應用程式教會了我有關這些主題的所有基礎知識，並且在完成每節課後它都有有趣的挑戰和徽章。唯一的問題是我不會透過手機進行完整的專案編碼。但重點是，當您等待購買筆記型電腦時，您絕對可以開始透過智慧型手機學習程式設計。因此，不要因為沒有筆記型電腦而高枕無憂。你越早意識到沒有人來拯救你越好。 我繼續從我的三星口袋裡學習了一個月，後來在內羅畢街頭（有很多扒手）它被神秘地偷走了。學校的朋友送了我一部HTC手機，螢幕碎了，有些地方根本碰不著，我得旋轉螢幕多次才能碰到地方😂，不過乞丐不挑食，我就繼續用了以便在本學期剩下的時間裡學習更多有關編碼的知識。 第二學期，現在是2017年，我收到了學生貸款。我的一些朋友/同學用他們的貸款去聚會、喝酒以及在俱樂部與女孩們玩耍。嗯，就我而言，我知道自己從哪裡來，也知道自己要去哪裡。於是，我拿了一些錢，立刻買了一台筆記型電腦。剩下的錢用來付學費和一點生活費。這對我的案例來說是一個巨大的進步，因為我現在可以了解更多資訊並開始從筆記型電腦上處理專案。因此，如果您有錢，請停止考慮參加聚會和購買昂貴的東西，而是考慮如何用這筆錢讓您的生活變得更好。 2017年至2019年期間，沒有太大變化。我只是在學習和做學校作業等。我想我還用 HTML 和 CSS 製作了兩個網站，我為這些工作獲得了一些報酬。我探索了更多關於編碼的知識，包括學習Java 中的OOP（物件導向程式設計），也用Java 進行了一些Android 應用程式開發，我的筆記型電腦無法處理android studio 😂，所以我又回到了Web 開發。我探索了 WordPress 以及如何用它製作博客等，並建立了一個 WordPress 博客，並以幾美分的價格出售。 2019年底，我正在讀三年級第三學期（這在我們大學被稱為內部工業實習），大約在這個時候，我被敲響了警鐘。我意識到我一直在學習編碼，但除了簡單的 html、css 和 WordPress 網站之外，我仍然無法建立一個完整的專案。我對任何一種程式語言都沒有足夠的信心。另外，畢業的要求是在第四年完成一個編碼專案。我也開始對未知產生恐懼，例如放學後要做的事情，因為只剩下一年了。我開始做很多研究如何建立一個完整的網絡應用程式，因為我已經了解了 javascript 的基礎知識，並且出現了一件我不知道的事情，即 javascript 框架，目前最流行的是 Angular、Vue並做出反應。當時我就知道我必須學習這些框架之一，而且很難決定選擇哪一個，但我最終選擇了 React，因為它是所有框架中最受歡迎、最有前途的工作，而且我仍然使用 React 進行編碼這點。 我嘗試從sololearn學習React，但進展並不順利。我嘗試了 youtube 並發現了 @thenetninja 頻道：https://www.youtube.com/@NetNinja 它非常有益健康，這就是我對 React 的很好的介紹。後來我從 Udemy 學習了兩門完整的 React 課程，一門由 _Stephen Grider_ 教授，另一門由 _Maximilian Schwarzmüller_ 教授。順便問一下，我沒有完成它們，誰完成了 udemy 課程？ 😂 但這兩門課程教會了我更多關於 React 的高級知識。 在學習 React 的過程中，我也很好奇如何在放學後或還在學校的時候透過程式碼賺錢，我發現了幾個選擇，找工作、自由工作、建立內容（這可以是寫部落格或 YouTube 頻道） ）、開始播客、寫書、建立像udemy 這樣的課程等等。由於我還在上學，我知道找工作很難處理，所以我決定嘗試自由工作和內容創作。還是在 2019 年，我開設了 YouTube 頻道：https://www.youtube.com/c/chaoocharles 來教授編碼，也開設了一個 upwork 帳號來從事自由專案的編碼。 我知道我不是一個好的作家，正如你從這篇文章中絕對可以看出的那樣，所以我嘗試了影片而不是博客。這是另一個挑戰，因為我必須學習如何製作影片、學習錄製和編輯軟體等等。但我還是堅持了下來，並從同學那裡得到了我的前 100 個訂閱。我的影片一開始就很糟糕，而且我做了很多工作，甚至沒有得到一分錢。但從正面的角度來看，製作影片讓我更理解編碼概念。就像，對我來說，要解釋我必須先理解的東西。我主要用 html、css 和 React 建立了很多影片，做得越多，我對建立影片和編碼就越有信心。 2020 年，我有很多時間來做這一切，因為我們因新冠疫情關閉了學校近一年，經過一年的努力，我終於獲得了 1000 名替補，這對我來說是一個巨大的勝利。 2020 年中期，我取得了兩場重大勝利，在 YouTube 上達到了 1k，並且在 Upwork 上找到了我的第一個客戶。我需要 1000 訂閱者和 4000 小時的觀看時間，YouTube 才會開始向我付費。我距離 4k 觀看時間還很遠，但至少我已經達到了其中一項要求。 Upwork 也很難找到第一個客戶，我申請工作卻無濟於事，但這第一個客戶改變了遊戲規則。我讓他相信我知道如何編碼，並用我的 YouTube 教程證明了這一點。你看，在製作 YouTube 教學的同時，我也在為自己建立一個作品集，我也在我的 github 上發布了多個專案。這麼說吧，我的投資組合目前看起來非常好，這位客戶毫不猶豫地給了我一份合約。如果你碰巧教了一些東西，人們就會開始將你視為專家（即使你正在努力教那件事😂）這可以通過影片或博客，我認為你應該嘗試一下。我在 upwork 專案上做得很好，這個客戶在那一年和接下來的一年裡繼續給我更多的專案。我做了他的大約 8 個專案，在 upwork 上獲得了上升人才徽章，後來又獲得了頂級徽章，這讓我贏得了更多客戶。  是的，我知道我現在的工作成功分數很差，但你明白了，哈哈😂 在製作YouTube 影片和Upwork 專案時，我也在做我的最後一年專案，因為我現在已經是第四年了，但這些是我自從2020 年因新冠疫情在家以來所做的唯一事情。雖然在2020 年底，我們回去上學期，做了考試並展示了專案。 快轉到 2021 年，我現在正在做附件。這是我畢業的必要條件。我透過在 Facebook 和網路上尋找肯亞的網路開發公司，輕鬆獲得了這一點。評論他們的帖子並解釋我的 IT 背景。我從某家新創公司的 CEO 那裡得到了 DM，並且以前端開發人員的身份加入了那裡。我試圖就報酬進行談判，但最好的結果只是維持交通和午餐，每週去辦公室三天，並承諾在實習後獲得一份長期工作。作為一名學生，這已經足夠好了，所以我就這麼做了。 在這家公司，我的 CSS 和 React 技能給他們留下了深刻的印象。我改造了他們公司的網站，並在我在那裡的5個月期間又做了2個網站。學校對我進行了評估，後來公司給了我工作機會。我覺得每個月的收入對我的技能來說不夠好，因為我可以在一兩週內輕鬆地做同樣的自由職業，而且我在那裡的時候我的 YouTube 也得到了貨幣化。我只是拒絕了這個提議，並決定專注於我的自由職業和內容創作之旅。如果他們允許我在處理其他事情的同時遠端處理他們的專案，也許我會接受這個提議，但這不在他們的公司政策中。我不想滿足於更少。你看，過去幾年我所做的一切都給了我選擇，也讓我不再急於找到工作，並擁有競爭優勢。 2021 年年中，我以二等高年級畢業，我保證如果不是我用 YouTube 和 upwork 分散自己的注意力，我會獲得一等，第四年我表現最差。但我後悔嗎？不。問題是，我從來沒有用過那個學位，它仍然鎖在家裡的某個地方，沾滿了灰塵。好處是，技能和經驗是這個編碼和程式設計領域最重要的。只有少數公司可能會要求學位，但大多數公司不會。他們會詢問您過去的經驗、您從事過的專案，並希望您通過程式設計面試。因此，如果你正在尋找一份程式設計工作，並因為沒有獲得學位而指責自己沒有學位，那麼你應該停下來。我們大多數擁有學位的人甚至沒有使用它們。也許我們唯一的優勢是我們在學校建立的聯繫或從那裡獲得的技能。但說實話，我所知道的大部分內容都是我自學的，我相信每個程式設計師都是自學的程式設計師，無論他們是否上過學。你必須親自動手。光靠論文並沒有太大幫助。 畢業後，我開始從 YouTube 獲得專案邀請，以及報酬豐厚的專案。我也開始利用 YouTube 和 GitHub 來在 Upwork 上獲得更好的付費專案，透過分享我的個人資料連結來告訴客戶我所取得的成就。所以，所有這些加起來就很不錯了。現在，我僅透過內容創作來支付所有帳單，並透過在工作和外部工作專案上工作來獲得更多收入。我的時間也很靈活，在家工作，這很棒。 2022 年我只做了一份全職工作。雖然位置偏遠，但完全值得。 我的觀點是，如果你正在努力尋找一份工作或一個專案，你可以透過為自己建立一些東西來改變一切。建立部落格、建立播客、建立頻道、建立公司、建立課程、寫書、公開建置（啟動一個大型專案並在此處和 Twitter 上分享您的進度），只需在這裡展示您的技能即可您能做什麼，遲早你會開始從事高薪專案。停止追逐工作，而只是吸引他們。 正如你從我的旅程中可以看出的，這不是一天的成就，直到一年多我才得到一分錢的內容創作報酬，直到一年多我才得到一個客戶的工作。我不是一天就能學會程式設計的，我是從一部手機開始的，後來又是用學校貸款買的一台低階筆記型電腦（我甚至還沒付）。所有這些成功的人士和公司都是從某個地方開始的，您今天就可以開始改變您的生活。開始親自動手，兩三年後你甚至不會相信自己來自哪裡。 這是我的故事，我希望你學到了一兩件事✌️
客戶最近有把舊 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)
國外一名資深開發者分享工作心得與技巧，與大家分享原文！ 原文出處：https://dev.to/wraith/my-8-tips-for-a-better-life-as-a-developer-1hfg --- 我擔任軟體開發人員已經有 8 年多了，從我自己的經驗以及從一些非常有才華的人那裡學到了很多東西。在這篇文章中，我想分享一些真正讓我的體驗變得更好、更愉快的事情。 ## 1. 找一個您喜歡工作的地方  您的環境對您的生活貢獻很大。它可以增加或減輕壓力，幫助您集中注意力或分散注意力，讓您感到安全或不安全等等。因為它在我們每個人的生活中都扮演著不可或缺的角色，所以我認為從這裡開始是合適的。 無論您是在辦公室還是遠端工作，您很可能可以採取一些措施來找到一個讓您感覺「合適」的地方。我說「對」是因為這裡每個人都會有所不同。有些人想要感到舒適和「賓至如歸」。其他人想要一個不太舒適的區域，而是真正讓他們「進入狀態」並集中註意力的區域。 多年來，我嘗試了很多不同的地點，只是為了看看什麼對我有用。我坐在陽台上，享受早晨涼爽的空氣，喝著一杯熱咖啡。我確實坐在桌子底下，身上蓋著毯子。我坐在壁櫥、角落、咖啡店、餐廳、酒吧、汽車、公園、餐桌和樓梯井裡。透過所有這些實驗，我已經能夠找到在我需要時為我提供所需的地方。如果我需要集中註意力，我就需要獨處。某處有一扇可以關閉的門，但沒有窗戶讓我注意到有人走過。當我太舒適時，就像依偎在柔軟的沙發上的毯子裡時，我的工作效果就不太好。如果我需要改變節奏，或者只是需要和人們在一起，我發現我真的很喜歡坐在不太擁擠的小酒吧或餐廳裡。我可以在某個地方點一杯飲料和一份開胃菜然後工作，但周圍仍然有幾個人。 所以我鼓勵你嘗試幾個地方。找出什麼對你有用，同樣重要的是，找出什麼對你沒用。如果你找不到地方，你總是可以花一點力氣去打造你想要的地方！ 「正確」對你來說意味著什麼？ ## 2. 投資硬體  作為軟體開發人員，我們使用的硬體數量非常多。可以說，我們使用鍵盤和辦公椅之類的東西比生活中任何其他物品都多。當然，我們可以使用任何舊鍵盤來完成工作，我們可以坐在任何椅子上。但我發現，對「更好」的硬體進行一點投資會對我的工作體驗產生很大的影響。 ### 椅子 如果您在工作時坐著，並且您只想投資一件東西，那麼它絕對應該是您的椅子。一張既提供舒適又提供支撐的椅子確實可以大有幫助。從您可以坐多久並集中註意力而不會感到不舒服，到日常生活中背部、頸部和肩膀的感覺，您的椅子對您的整體健康和福祉有很大影響。因此，一定要找到一款好的產品，而不要只滿足於會導致不良姿勢的產品。 我個人使用 [Secretlab Titan Evo（蝙蝠俠主題）](https://secretlabchairs.ca/products/titan-evo-2022-series?sku=R22PU-Batman)，幾年來我對它非常滿意。與許多高端桌椅相比，價格還不錯。 ### 鍵盤 僅次於椅子（但相差不多）的是鍵盤。輕鬆地成為我們每天工作中互動最多的工具。那裡也有很多選擇，因此無論您的個人喜好如何，很可能有一些東西可以滿足您的需求。 每個人選擇合適的鍵盤都有很大不同。有些人喜歡低調的鑰匙而不是機械鑰匙。有些人需要整合 USB 連接埠。成本、人體工學、有線或無線、可自訂的按鍵和開關、背光、可配置的 LED、支援配置按鍵佈局、高度和大小、按鍵數量，這樣的例子不勝枚舉。尋找適合您的鍵盤無疑是一段旅程，但我強烈建議您繼續下去。當然，我們可以使用任何鍵盤來完成我們的工作......但我保證，如果您嘗試一下，找到「正確的」鍵盤將使您作為開發人員的一天和體驗更加愉快。 我使用 [Moonlander Mark 1](https://www.zsa.io/moonlander/)，絕對💙它！分離式設計確實幫助我不再那麼無精打采，也幫助消除了我長期以來的肩膀和手腕疼痛。再加上那些櫻桃棕色的開關聽起來很漂亮😍！ ### 滑鼠 談論鍵盤就不能不談論它們的助手——滑鼠。就像鍵盤一樣，市面上有許多不同類型的鍵盤，每個人都會有自己的偏好。幸運的是，即使是半像樣的滑鼠也有相當低的價格，因此嘗試一些滑鼠來找到適合您的滑鼠相對容易。但與此處的所有其他專案一樣，投入一點時間和金錢即可對您的體驗產生積極影響。 我的老鼠是 [ZLOT 垂直遊戲滑鼠](https://www.amazon.com/gp/product/B07T3PFWCB?th=1)。它是一款較輕（重量）的滑鼠，但具有良好的人體工學感覺和響應能力，我已經喜歡了很長一段時間了。 ### 螢幕 這絕對是一個可選專案，但我發現它讓我的工作更加愉快。並非每個人都需要外接顯示器。有些人實際上更喜歡直接使用筆記型電腦工作。但如果您確實喜歡使用外部顯示器，這是一項可以產生巨大影響的投資。 遺憾的是，由於多台 4k 顯示器在 Mac 上工作出現問題，我放棄了多顯示器設置，現在使用 [Sceptre 35" 曲面顯示器](https://www.sceptre.com/Monitors/2K-4K-Series/C355W-3440UN-35-Curved-Monitor-product1176category12category98.html)。它有很多空間，所以我仍然可以在一個螢幕上打開大量視窗。 ### 耳機 耳機也是可選的（有些人可能會反對這一點😝），但它們的好處怎麼強調都不為過。從減少干擾到幫助您集中註意力，一副好的耳機可以大有幫助。就像我列出的大多數專案一樣，每個人的偏好都會有所不同。但是，投入一點時間和金錢來尋找一雙適合您的好鞋，確實可以將您的遊戲提升到一個新的水平。我認識的許多人都尋求良好的降噪效果，而且它們必須輕盈舒適，這樣才能一次佩戴幾個小時。 我個人喜歡使用 Beats。我曾經使用[Studio3](https://www.bestbuy.ca/en-ca/product/beats-by-dr-dre-studio3-over-ear-noise-cancelling-bluetooth-headphones-black/11534527 )但是當我必須開始戴眼鏡時，我不喜歡這些耳機給我的鏡框帶來的壓力，所以我改用了[Beats Fit Pro](https://www.beatsbydre.com/earbuds/beats-fit-pro?sku=MK2F3) 並且對它們非常滿意。我已經連續戴了 8 個小時，效果非常好。它們輕巧、舒適、音質好，並且在我慢跑和運動時表現良好且穩定。 您使用什麼硬體？您夢想的硬體是什麼？ ## 3. 找到您*喜歡*使用的工具  除了硬體之外，作為開發人員，我們還使用許多軟體工具來完成我們的工作。有些我們別無選擇，但也有很多我們可以選擇，找到您真正喜歡使用的工具確實可以讓您的日常體驗變得更好。即使只是擁有一個可以配置為您喜歡的外觀的工具也可以產生積極的影響。 我在這裡想強調的不是找到每個人都使用的工具，因為他們可以做各種各樣的事情。更多的是尋找您真正「喜歡」和「期待」使用的工具來完成工作。即使它們不能完成其他工具可以完成的所有奇特的事情，如果您確實希望使用其他工具，那就使用它！擁有我們積極喜歡的工具確實會為我們的生活增添很多積極性。 多年來，類似的工具有很多，但這裡有一些工具為我的日常生活帶來了很多樂趣： - Giphy Desktop app - 用 gif 回覆取代無聊的文字，讓 Slack 訊息變得生動起來。 - Raycast - 這已經取代了我 Mac 上的 Spotlight。透過專業版，我可以存取 ChatGPT 4...因此，只需一個快速鍵盤快捷鍵，我就能輕鬆掌握 AI。對我來說遊戲規則改變者！ - Obsidian - 雖然這已經是一個流行的筆記應用程式，但我花了一些時間編寫了一些腳本來為我自動化工作，它完全改變了我記下所有筆記並跟踪我需要做的所有事情的方式。 - Arc browser - Arc 花了整整 1 天的時間才成為我的主要瀏覽器。現在，當我測試瀏覽器對我正在建立的某些功能的支援時，我只使用其他瀏覽器（在我的桌面上）。 - Habitical - 獲得徽章、成就和一般遊戲化讓我非常有動力，所以這個待辦事項應用程式讓我管理和執行任務變得更加有趣！ 有哪些工具可以為您的日常開發生活帶來樂趣？ ## 4. 設定目標  我知道這聽起來很明顯，而且我相信我們都從無數其他來源聽到這一點。但您可能會驚訝地發現有多少人沒有為自己設定目標。不相信我？向你的任意 2 到 3 個鄰居詢問他們目前正在努力實現什麼目標。當我問這個問題時，經常得到的只是聳聳肩，然後回答「沒什麼」。 僅僅設定目標也是不夠的。你也必須定期考慮它們。有些方法建議將它們寫下來並放在鏡子上或您經常看到它們的地方。這個方法對我個人來說沒有效果，但也許對你有用？對我來說有效的方法是每天早上開始工作前坐下來15 分鐘，並重點思考我的目標、我所有的待辦事項以及日曆上的所有事情（是的，我實際上在日曆上留出15分鐘的時間）這個，並強迫自己堅持這個時間）。在這段時間裡，我思考我的目標，並找出我今天可以做的一件小事，讓我離實現每個目標更近一步。 例如，如果我的目標是在家人來過感恩節之前清理車庫，我會想，「我今天可以做哪一件小事來實現這個目標？」。有時答案特別小…「掃到工作台下面」。其他時候我可能會更有動力，或者我有更多的可用時間，這可能是更大的事情。無論如何，請花一些時間考慮您今天可以採取的一項行動來實現該目標。 當我這樣做時，我的大腦中會發生一些事情。我發現自己感覺更有成就感和更樂觀。當然，完成目標可能是一條漫長的道路（如果它是一個大目標），但是知道我離我想要完成的事情更近了，這對我的日常生活產生了積極的影響，並讓我能夠完成的事情比我想像的還要多。 無論大小，給自己設定目標。然後定期思考它們，並採取許多微小的行動，以朝著前進邁出一步。我保證這會為您的生活帶來美好的事物！ 現在您正在努力實現哪些目標？ ## 5. 保持好奇心並了解*為什麼*  很多人對編碼專案中的完成方式感到沮喪或評判。我肯定去過那裡！ - “為什麼有人選擇這項技術？！對於這個用例來說，其他技術要好得多...” - “為什麼有人會寫這樣的程式碼？！” - “如果我們不做 X 而只是做…，事情會好得多” 這些聽起來很熟悉嗎？ 儘管事情有時會令人沮喪，但在軟體開發中，做出的每個決定背後幾乎總是有一個「原因」。這是最好的選擇嗎？也許不是……但做出這樣的選擇還是有原因的。 我曾經對事情的現狀感到沮喪，然後在嘗試解決問題時感到沮喪，然後在遇到障礙時感到沮喪。但最終，事情突然發生了，我沒有感到沮喪，而是開始尋找這些事情發生的原因。背後的*原因*是什麼。當我養成「尋找原因」而不是「想知道為什麼不」的習慣時，我的好奇心變得更強。我發現我正在尋找更多的訊息，更徹底地學習和理解事物，更多地同情與我一起工作的人，最終，沮喪的感覺減少了很多。 現在，我的經歷更加積極了。無論我是重構一段複雜的程式碼，試圖找到解決惱人問題的方法，還是為新工作學習全新的程式碼庫，我實際上更喜歡這個過程，因為我只是好奇並想知道「為什麼」。 最近一次讓您真正感到沮喪的編碼*事情*是什麼？您知道*為什麼*會是這樣嗎？ ## 6. 為重點工作劃出日曆  這說起來容易做起來難，具體取決於您的工作地點，但它會對您的開發人員生活產生驚人的影響！ 您是否曾經在該區域中，只是編寫程式碼來建立該新功能，然後「*叮！*」有人向您發送了一條緊急的 Slack 訊息？或是有人拍拍你的肩膀問你問題？您解決了乾擾問題，然後返回螢幕，然後您就失去了所有註意力？如果沒有……我願意賭很多錢，你會在職業生涯的某個時刻這麼做。 「在區域中」或進入「心流」的概念是一個已經被研究和寫了很多的主題。我強烈建議您查看一些有關該主題的文章和書籍，因為這是一個非常有趣的主題（至少對我來說是😃）！其中許多研究都表明，處於心流狀態是多麼有益，而且在中斷後可能需要 20 分鐘以上才能恢復到那種精神狀態！因此，找到讓自己進入這種心態並保持這種狀態的方法非常重要！ 我發現讓自己進入這種狀態的最佳方法之一就是在日曆上劃出大量時間專門用於「專注工作」。一開始這可能是一個挑戰，讓人們在嘗試聯繫之前檢查您的日曆或 Slack 狀態，並幫助每個人了解您將在焦點時間結束後立即回覆他們。但最終人們會明白過來，並且回報是巨大的！別忘了在這段時間關閉通知！ 不過這裡有一些提示...... - 接受有時會出現緊急事務並需要更高優先順序的事實。這就是生活，我們只能隨波逐流……但這不該成為「常態」。 - 拍攝 2-3 小時的片段。少於這個數量會讓人覺得不夠，但超過這個數量，人們就會被迫更頻繁地打斷你。請記住，其他人也有重要、緊急的事務，在當今的工作環境下，讓他們等待半天以上才能獲得地址確實不公平或不合理。 - 在你最有生產力的時間安排這些時間段。對我來說，早上 6 點到 10:30 左右我的工作效率最高。所以我通常會嘗試將我的專注時間安排在這些時間裡。 您發現一天中的什麼時段您的工作效率最高？ ## 7. 讓 PR 小一點  我喜歡這個，並且在過去一年左右的時間裡它已經成為我的首要任務。 事實證明，保持 Pull 請求（或 GitLab 人員的合併請求）較小有很多積極的好處。發布的錯誤更少，我們審查程式碼的時間更少，功能的推出速度更快，僅舉幾例。所有這些不僅使我們的產品變得更好，而且我發現它也極大地改善了我作為開發人員的體驗！ 透過專注於較小的變化，我發現我可以更徹底地思考問題，考慮到在較大變化的混亂中可能被忽視的用例。我能夠更快地將變更納入審查，我的團隊成員能夠更快地審查我的程式碼，因為我只佔用了他們5 分鐘而不是2 小時的時間，並且在審查期間，我收到的程式碼要少得多變更請求。因此，更好的程式碼將會出現，我可以繼續花更多的時間來建立新的東西，而不是必須解決一堆被遺漏的錯誤。 另一方面，審查小型 PR|MR 比大型 PR|MR 更令人愉悅。您是否曾經需要審查某人的 PR|MR，其中包含數千個更改、跨越 20 多個檔案以及應用程式的多個區域？當你這樣做時，你的第一個反應是什麼？您是否對參與並開始審核感到過於興奮？或者，也許您感到“呃”，於是推遲了會議，因為距離下一次會議只有 30 分鐘，而您可以在這段時間內完成其他事情？ 當審查大型 PR|MR 時，通常會失去很多細節（或至少受到較少的關注），最終，大多數人會達到「審查盲目性」或「審查疲勞」的地步，事情開始被忽視，或者審稿人必須離開一段時間，稍後再回來。這一切都會導致審核過程花費更長的時間、效率更低，並導致提交更多的變更請求。更不用說所有團隊成員都有的不滿情緒了。 自從我開始將此作為自己的優先事項，並與團隊成員一起努力讓他們也這樣做時，我注意到我在 PR|MR 方面的經驗明顯改善了。我更願意在會議之間跳出一些評論，我不得不要求更少的改變，而且我不會在需要離開並重新振作起來之後感到精疲力盡。就連我的計劃也變得更準確了！ 總而言之，我強烈向大家推薦這個。如果您想了解更多關於這樣做的好處，我建議您查看 [LinearB 部落格](https://linearb.io/blog) 以及 [Dev Interrupted 播客](https://linearb.io/dev-interrupted/podcast).他們談到了一些很棒的觀點，我發現這些觀點確實對工程領導者和團隊有幫助！ 你曾經審查過的最糟糕的公關是什麼？ ## 8. 寫下一切！  我的最後一個建議是我在去年開始做的事情，在閱讀了[如何做智慧筆記](https://www.amazon.ca/How-Take-Smart-Notes-Technique/dp/3982438802)和[把事情做好](https://www.amazon.ca/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280)它對我的生活產生了驚人的影響。 當我學到新東西時，我會把它寫下來。即使只是一小段描述我學到的東西。當出現新任務時，無論大小，我都會把它寫下來。在會議期間，如果分享想法、給予回饋、提出問題，所有這些都會被記錄下來。如果我對某事有一個隨意的想法，或者一個頭腦發熱的想法……你猜對了……它會被寫下來。然後，每當我有幾分鐘空閒時間時，我都會先看筆記，而不是瀏覽社群媒體。我盡可能回顧它們，這強化了我腦海中的訊息，但也幫助我將不同的想法聯繫在一起，這往往會產生一個全新的想法。 透過這樣做，我發現我對事情的記憶更加徹底。如果我不能，我有記錄並且可以將其調出！它使我能夠完成更多的工作文件，而且我甚至在任何給定時間都有 4 或 5 篇部落格文章正在編寫中！遺漏的事情少了很多，而且我能夠完成更多的事情。 我最近開始了一份新工作，透過使用這種方法，人們已經來找我詢問我是如何做到這麼多的！秘密醬汁？全部寫下來並將其加入到系統中。 這對我來說改變了遊戲規則，我只需要鼓勵其他人也這樣做，因為我真的相信這可以使他們的生活受益匪淺！ 你用什麼方法來記住和分享你學到的東西？ ## 結論 在過去 8 年多的軟體開發人員和工程師工作中，我學到了很多。我經歷過好時光和壞時光，並一路走來學到了一些非常有用的人生課程。透過找到我喜歡工作的地方，在我的硬體上投入更多的時間和金錢，找到我「喜歡」使用的工具，設定目標，保持好奇心並專注於“為什麼”，定義專注工作的時間，專注於保持PR 較小，並寫下我能寫下的一切，我可以誠實地說，我的開發者體驗得到了極大的改善。 我非常希望這些技巧中至少一兩個能改善您的體驗。
本文轉載自:https://ithelp.ithome.com.tw/articles/10338469 ## 前情提要 有時候，夜深人靜，總是會想要沉思人生的意義。 於是打開某個網站， 開始看一些只有長大了才能看的大人動作愛情學，必須好好鑽研， 此刻電影裡的聲響徹雲霄，你感覺無比尷尬..... 這時候就需要靜音神隊友。 可以自己加入網頁名單，讓小電影們先保持靜音，自己再手動開啟。 如此一來非常保險，絕對不讓你不小心爆音。 非常的有禮貌，人生的哲理更奧妙了。 ## 腳本下載  https://greasyfork.org/zh-TW/scripts/477196-%E9%9D%9C%E9%9F%B3%E5%B0%8F%E5%8A%A9%E6%89%8B ## JS程式碼 ``` // ==UserScript== // @name 靜音小助手 // @namespace http://tampermonkey.net/ // @version 0.1 // @description try to take over the world! // @author You // @match https://*/* // @icon https://www.google.com/s2/favicons?sz=64&domain=xvideos.com // @grant none // ==/UserScript== // 定義 JSON 資料，包含網址開頭 var jsonUrls = [ "https://www.xvideos.com/", "https://example.com/json2", // 添加更多的網址開頭 ]; // 取得當前網址 var currentUrl = window.location.href; // 檢查當前網址是否以 JSON 中的某些開頭開始 var isJsonUrl = jsonUrls.some(function(jsonUrl) { return currentUrl.startsWith(jsonUrl); }); // 如果當前網址符合 JSON 的某些開頭，執行程式碼 if (isJsonUrl) { // 在這裡放置你想要執行的程式碼 console.log("當前網址符合 JSON 開頭"); Mute(); } else { console.log("當前網址不符合 JSON 開頭"); } function Mute(){ // 取得網頁上所有的 <video> 元素 var videoElements = document.getElementsByTagName('video'); // 迭代所有的 <video> 元素並將其靜音 for (var i = 0; i < videoElements.length; i++) { videoElements[i].muted = true; } } ``` ## 觀念筆記 只能說，前端的東西往往越簡單，越強。 這次只是使用三個小觀念，都是超級基本的小小觀念，幼稚園等級。 ### 第一部分：使用陣列儲存網址 ``` // 定義 JSON 資料，包含網址開頭 var jsonUrls = [ "https://www.xvideos.com/", "https://example.com/json2", // 添加更多的網址開頭 ]; ``` 這部分就是把我們的資料儲存起來，可以自己新增訂義哪些網址要被匹配。 ### 第二部分：location的API 使用網址要確認網址，就是用location，這已經屢見不鮮。 另外字串的搜查，startsWith非常老舊卻也很無敵。 ### 第三部分：影片靜音API 很簡單，針對video元素muted就可以了，非常輕鬆！ 簡直就像早餐吃鬆餅一樣，鬆。 ## 心得 很多人常常說前端，好難，JS好基八 我是覺得，關你屁事？/ᐠ｡ꞈ｡ᐟ\ 你會罵蛋餅為什麼要這麼蛋餅嗎，蛋餅之所以好吃就是因為它是蛋餅，不好吃也因為它是蛋餅。 JS的奇怪或是難懂，只是它的本質，在那邊靠北靠母的風氣真的很無聊。 要玩梗也可以多一點新的梗，而不是表面嘴皮耍耍。 它很機八，但也很強，這就是JS的厲害之處。 因此這個簡單實用的小腳本，又再次被我們秒殺了！ 喜歡可以關注，未來還會有更多JS的小試身手、前端動手玩創意也還有一堆素材呢⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾
## 轉載自 https://ithelp.ithome.com.tw/articles/10338052 ## 前情提要 有時候我們需要使用一些圖片，勢必需要圖片的網址，這時候， 也許你可以本機上傳，然後去把網址抓好， 又或者你可以找到網路上別人的圖片，右鍵開啟新分頁，再複製網址； 又或者直接打開檢查(F12)找到src的網址去複製。 光聽這個流程我就覺得，心累。 這時候前端大師，就會寫一套簡單的小腳本來完成這個白爛的工作。 ## 腳本下載  https://greasyfork.org/zh-TW/scripts/477141-img%E8%A4%87%E8%A3%BD%E5%A4%A7%E5%B8%AB ## JS程式碼 ``` // ==UserScript== // @name IMG複製大師 // @namespace http://tampermonkey.net/ // @version 0.1 // @description 針對網頁上圖片，點擊就複製其網址 // @author You // @match *://*/* // @icon https://www.highcharts.com/demo/highcharts/spline-plot-bands // @grant none // ==/UserScript== let isEventActive = false; // 用於跟蹤事件的狀態 // 創建一個鏈接元素並設置其屬性 const toastrCssLink = document.createElement('link'); toastrCssLink.rel = 'stylesheet'; toastrCssLink.href = 'https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/css/toastr.min.css'; // 創建一個腳本元素並設置其屬性 const toastrScript = document.createElement('script'); toastrScript.src = 'https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js'; // 創建另一個腳本元素並設置其屬性 const toastrScript2 = document.createElement('script'); toastrScript2.src = 'https://cdnjs.cloudflare.com/ajax/libs/toastr.js/latest/js/toastr.min.js'; // 將鏈接元素和腳本元素添加到文檔頭部 document.head.appendChild(toastrCssLink); document.head.appendChild(toastrScript); document.head.appendChild(toastrScript2); // 獲取頁面上的所有img元素 const images = document.querySelectorAll('img'); function removeClickHandler(image) { image.removeEventListener('click', clickHandler); } function toggleEvent() { if (isEventActive) { // 如果事件已經激活，則關閉事件 console.log('IMG複製大師關閉ꐦ°᷄д°᷅'); // 解除事件監聽 images.forEach(removeClickHandler); isEventActive = false; } else { // 如果事件尚未激活，則打開事件 console.log('IMG複製大師啟動ฅ^•ﻌ•^ฅ'); // 遍歷所有img元素 images.forEach((image) => { // 檢查圖像是否已加載 if (image.complete) { // 圖像已加載，直接添加點擊事件處理程序 addClickHandler(image); } else { // 圖像尚未加載，等待加載完成後再添加點擊事件處理程序 image.addEventListener('load', () => { addClickHandler(image); }); } }); isEventActive = true; } } document.addEventListener('keydown', (event) => { if ((event.key === 'q' && event.ctrlKey) || event.key === 'F8') { toggleEvent(); // 切換事件的狀態 } }); function transformImageUrl(url) { // 使用正則表達式匹配URL中的目標部分 const regex = /https:\/\/cache.ptt.cc\/c\/https\/i.imgur.com\/([^?]+)/; const match = url.match(regex); if (match) { // 如果匹配成功，構建新的URL const imgurId = match[1]; return `https://i.imgur.com/${imgurId}`; } else { // 如果沒有匹配到目標部分，返回原始URL return url; } } // 創建一個函數，用於添加點擊事件處理程序並處理圖像的src function addClickHandler(image) { image.addEventListener('click', clickHandler); } // 創建一個函數，用於處理點擊事件 function clickHandler() { let src = this.src; src = transformImageUrl(src); const textArea = document.createElement('textarea'); textArea.value = src; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); document.body.removeChild(textArea); // 使用 toastr 進行通知 toastr.success('網址複製完成: ' + src); } ``` ## 觀念筆記 這個小腳本總共使用了大概三種觀念， 第一種就是toast的套件使用， 第二個是監聽鍵盤做開關， 第三個則是程式本身對於img的監聽，把src複製到剪貼簿。 ### 第一部分:套件 使用套件在於腳本，必須利用appendChild，先使用create的API製作出放置CDN的link元素， 再把它append到網頁上，則可以使用其套件。 ### 第二部分:監聽鍵盤 這腳本啟動與關閉是透過監聽鍵盤的，ctrl+q或F8這部分就是純粹監聽。 ``` document.addEventListener('keydown', (event) => { if ((event.key === 'q' && event.ctrlKey) || event.key === 'F8') { toggleEvent(); // 切換事件的狀態 } }); ``` 裡面寫了一個toggleEvent是因為想要設定可以開開關關。 ### 第三部分:程式本身 這邊有一點小技巧是複製到剪貼簿，其實以前文章也有寫過教學，是個常見實用的招數： ``` const textArea = document.createElement('textarea'); textArea.value = src; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); ``` 再來就是針對網頁上全部的img元素，去監聽點擊事件、移除事件這兩個。 ``` const images = document.querySelectorAll('img'); function addClickHandler(image) { image.addEventListener('click', clickHandler); } function removeClickHandler(image) { image.removeEventListener('click', clickHandler); } ``` 之後這兩個事件要寫在toggle裡面，當開啟的條件就執行新增事件；關閉就執行解除綁定 開啟也就是： ``` images.forEach((image) => { // 檢查圖像是否已加載 if (image.complete) { // 圖像已加載，直接添加點擊事件處理程序 addClickHandler(image); } else { // 圖像尚未加載，等待加載完成後再添加點擊事件處理程序 image.addEventListener('load', () => { addClickHandler(image); }); ``` 關閉則是： `images.forEach(removeClickHandler);` ## 心得 這次的小腳本功能非常簡單，寫起來邏輯也是很清晰透明，沒有什麼彎曲。 雖然簡單，但是寫起來功能非常實用！ 這就是針對懶人專用的！ 其實沒有人規定前端這種東西要寫得多大，多了不起/ᐠ｡ꞈ｡ᐟ\ 好像你很屌、很懂前端、框架，那個是一回事，能夠完成自己的需求也很美好。 很久沒更新了，這次的酷酷小腳本應該很爽⁽⁽٩(๑˃̶͈̀ ᗨ ˂̶͈́)۶⁾⁾ 好好的來玩前端吧，未來還有更大的宇宙！
成品連結：https://codingdark.github.io/program/2023/09/18/API-Test.html ##第一步 架部落格 最初看到站長的貼文，提供了本站的API 並且鼓勵大家自架部落格，來嘗試串API 看到文章的當下，覺得有點難度(沒用過github page，API也不熟) 不過看到站長提供的關鍵字`setup a personal blog with github pages` 最終還是決定先google看看 查了之後，發現近年的gitbub簡化了很多 都可以自動部署，根本就是一鍵架站 外加原始碼開源，很多東西都能自己改 所以光是部落格就玩了一天XD 因為本站為CodeLove 愛寫扣 我就創了一個CodingDark 闇寫扣 表示致敬本站 & 本人的中二風格 ##第二步 串API 因為不熟的關係，所以決定先隨便串 呼叫API之後，把data印在console.log 大致上看了一下資料格式 使用上其實就類似陣列，非常方便 沒有想像中的難 確認API可以正常呼叫後 陸續加入一些功能 比方說，用Table把文章列表排整齊、加上[Read more]按鈕 先讓json資料，轉換成網頁能呈現出來的[資訊] ##第三步 程式碼優化 到這邊為止，網頁的畫面已經差不多定型了 剩下的就是回頭檢視程式碼 考量到後續維護 盡可能把重複的程式碼，包裝成function 或是把一群散亂的變數，包裝成object 最後，為了方便擴充文章列表 將原本是寫死的HTML Dom 改成動態產生 目前的部落格頁面 點進去會撈出站長、Tony，以及我的文章列表 後續若想要列出其他使用者的文章 只需新增`setTable(userAccount)`即可 ##結尾 感謝站長提供有趣的API 讓大家可以有練習的機會 雖然目前我在工作上，沒接觸過API 但經過這次的練習，以後若是真的有需要用到 可以更快上手
一篇國外的熱門文章，關於一些開源選擇方案，翻譯出來給大家參考。 - 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 的可靠性則讓您的團隊溝通順暢。 關鍵是，你並沒有被歸類。這一切都是為了找到適合工作的工具，有時，這意味著將開源精神與專有軟體的精美體驗相結合。 因此，當您冒險進入科技領域時，請記住：這不是選擇立場的問題。它是為了找到讓您的數位生活更輕鬆、高效和愉快的完美工具。潛入、實驗並製作你獨特的科技馬賽克！
您是否想過當您**執行 Rust 程式**時**RAM**會發生什麼情況**？您編寫程式碼的**方式會如何干擾系統中的許多其他事物？ 這篇文章將幫助您了解更多關於 *管理記憶體* 和 **RUST 如何運作** 的資訊。 原文出處：https://dev.to/canhassi/how-rust-memory-management-work-to-beginners-622 ## 1. Stack and Heap 在了解 rust 的作用之前，您必須先了解一些概念。一般來說，我們有兩種類型的內存，稱為：**堆疊和堆**。現在我們來介紹一下他們。 ### 1.1 記憶體：Stack 堆疊，顧名思義，**工作原理就像堆疊**，遵循**“後進先出”（LIFO）的原則。**也許分步驟解釋會更容易： *想像一下**一堆盤子**； *您放入的**第一道菜**是**最後取出的**； * 當**函數被呼叫**時，一塊記憶體被**「堆疊」在棧頂； * 當**函數結束**時，該區塊**“unstacked”**，釋放該記憶體。 通常，**編譯器**（在編譯時）知道將儲存在堆疊上的**值**，因為它知道需要儲存多少記憶體。此過程**自動**發生，所有值都會從記憶體中刪除。 下面是一個例子： ``` fn main() { let number = 12; // at this moment the variable has created println!("{}", number); // 12 } // When the owner (main function) goes out of scope, the value will be dropped ``` 在 Rust 中，我們只需使用「{}」即可建立一些作用域，這會在堆疊中加入具有有限生命週期的層。當您離開該特定*範圍*後，記憶體將被清除，您將遺失相關資訊。一個很好且簡單的例子是： ``` fn main() { { let number = 12; println!("{}", number); // 12 } println!("{}", number); // Cannot find value `number` in this scope } ``` ### 1.2 記憶體：Heap 簡而言之：**堆**記憶體是一個空閒記憶體空間，用於分配可能更改的資料。 想像一下，您需要在啟動程式後**儲存一些變數**，該變數在編譯時沒有已知的固定大小，因為它可能有大小變化或是記憶體中的直接分配。 如果上述可能性之一匹配，我們就知道我們有 **堆** 內存，而不是 **堆疊**。堆擁有更**靈活的記憶體**和更大的空間。看一看： ``` let number = Box::new(12); // alocate a integer in heap let name = String::from("Canhassi"); // alocate a String in heap ``` 在 Rust 中，我們有兩種字串「類型」：「&str」和「String」。 * **&str**：根據所寫的文字有固定的大小； * **字串**：具有可以增加、減少和刪除的大小。 ……這就是為什麼 `String` 儲存在堆上，而 `&str` 儲存在堆疊上。 釋放堆記憶體的一種方法是：當儲存堆上某些內容的**變數離開函數的作用域（到達函數末端）時，它將以相同的方式釋放作為堆疊。 好了，現在我們對這兩種記憶體類型有了一個清晰的認識，但是堆疊和堆在管理記憶體方面有什麼區別呢？讓我們看看這些差異吧！ ## 2. 借用檢查器 借用檢查器是 Rust 編譯器的**部分**，它**檢查並確保**所有權、借用和生命週期**規則得到尊重**。 老實說：一開始我在理解它是如何運作的方面遇到了一些問題，我發現這在新的 Rustaceans 中很常見。但別擔心，我的朋友。我會用最好的方式教你。但首先，讓我們先來看看下面的程式碼： ``` fn main() { let name = String::from("Canhassi"); // Creating a string variable print_name(name); // calling the print_name function passing the variable println!("{}", name); // Error: name borrowed to print_name() } fn print_name(name: String) { println!("{}", name); // print "Canhassi" } ``` 如果您使用該程式碼執行編譯器，您將看到以下錯誤： ``` borrow of moved value: name ``` 當我們呼叫“print_name”函數時，“name”變數將被**移動到另一個作用域**，並且該作用域將成為它的**新所有者**。並且所有者的規則超出範圍將再次應用。借用檢查器確保**一旦所有權轉移**，原始變數**不能再用於**來存取該值。這發生在上面的程式碼中。 使用原始變數的另一種方法是使用類似的引用。 ``` fn main() { let name = String::from("Canhassi"); // Creating a string variable print_name(&name); // calling the print_name function passing the variable println!("{}", name); // print "Canhassi" } fn print_name(name: &String) { println!("{}", name); // print "Canhassi" } ``` PS：這些**借用檢查器的規則僅適用於**堆中指派的物件**。 ## 3. 錯誤預防 借用檢查器對於確保 Rust 記憶體安全而無需[垃圾收集器](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) 至關重要。 在 C 和 C++ 等其他語言中，我們（作為開發人員）必須使用某些函數手動釋放記憶體。 C++ 以允許記憶體管理錯誤而聞名，包括[記憶體洩漏](https://en.wikipedia.org/wiki/Memory_leak)。 C++本身不會導致記憶體洩漏。相反，**C++ 為程式設計師提供了大量的靈活性**和控制力，如果使用不當，這種**自由可能會導致錯誤**。 一個著名的錯誤是**未定義的行為**，例如，想像一個函數傳回這樣的變數的引用 ``` fn main() { let number = foo(); // calling foo function } fn foo() -> &i32 { let number = 12; // creating a var number &number // try return a reference of var number } ``` 程式碼不起作用，因為 Rust 編譯器對記憶體管理有限制規則。我們不能回傳 var `number` 的引用，因為這個函數的作用域將會消失，而 var `number` 將會消失，所以 Rust 不會讓這種情況發生。在 C++ 中我們可以做到這一點，並且它允許臭名昭著的記憶體洩漏。 我認為知道 Rust 編譯器避免了這種類型的錯誤真是太酷了...如果這個主題對您來說是新的，我可以說內存洩漏可能會花費很多錢並且確實很難修復它，因為絕不只有一次內存洩漏。 其他範例是，**雙重釋放**，當您嘗試釋放相同物件兩次（例如在 C 程式碼中）時，就會發生這種情況。 ``` char* ptr = malloc(sizeof(char)); *ptr = 'a'; free(ptr); free(ptr); ``` 這個主題非常廣泛，當您使用其他語言時，很可能會產生類似的錯誤。但是，我會讓您自己進行研究，並確保在這篇文章的評論中告訴我更多！ ## 4。結論 我寫這篇文章的目的是以更一般的方式展示記憶體管理如何與 Rust 配合使用。但我建議您閱讀《Rust 程式語言》一書的第 4 章（ https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html ）來獲得更完整的知識。在那裡您將獲得更多示例和更多關於此內容的解釋。 希望這篇文章有幫助！ 🦀🦀
阿川收到網友提問如下： ``` 站長阿川您好 我是一名App工程師 從2013年第一份工作到現在近10年 這十年我從工程師到資深工程師到管理職位都有相關經驗 一共經歷四份工作 離開公司原因大多是與人理念不合 今年邁入40歲 目前在一間外商工作 年薪約200左右 最近又再找尋新機會 但是相關職位看到我的經歷常常被拒絕 因為該職位不想要這麼資深的 不然就是年薪必須砍半 最近有一個機會可以加入幾個創業家所組成的公司 缺點是薪資可能只剩下現有的1/3 優點是可以接觸相關人士學到創業可能所需的技能 也可以藉由這樣機會建立屬於自己的產品一步步養活自己 在網路上看到您的文章彷彿醍醐灌頂 也對於長年職涯生命握在別人手上感到非常不適應 但是我明白產品可能不是自身想像那麼容易打造 不過我仍想試試看 不知道您這邊是否有什麼想法可以對我未來要走的路提供一些建議 非常感謝您撥空看完 ``` 這主題很好，我決定單獨寫一篇文章討論這件事情，跟大家分享一下 --- 首先，這位朋友目前的工作狀況，外商、200萬年薪，如果工作壓力不大、下班時間正常，辦公室氣氛融洽 這麼好的條件，如果放棄這份工作，實在相當可惜！ 有沒有考慮利用下班＆週末的時間，寫一些自己的作品、app，試試看？ 一人獨立開發，或者找朋友一起經營，都可以，做完之後，到相關的 FB 社團、批踢踢看板，宣傳一下 會學到很多商業、經營、行銷的技能，會很好玩 也或許，你會發現要做的事情太多、太雜、太難，你會滿不適應的，那樣的話，你會重新看見現職公司的美好 --- 再來，如果目前的公司實在很煩，除了高薪之外，工時、工作內容、環境壓力，你根本通通都不喜歡、鐵了心想要離職 那麼眼前的選項就是 - 找類似工作，薪水變二分之一 - 前往新創嘗試，薪水變三分之一 這樣的話，我有一個小原則跟你分享 # 職涯判斷技巧：Ctrl+Z 不心痛原則 這是我發明給自己，在面臨重大決定會用的一個原則 Ctrl+Z 是工程師每天會用到的快捷鍵：「恢復上一動」 在面臨選項的時候，可以去想想：「恢復上一動」的成本會很高嗎？ ### 「我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？」 舉例來說，社會新鮮人有點想考公務員 vs 想去業界上班看看 如果先考公務員，工作之後迷惘，想辭職去業界，這時「Ctrl+Z」的成本就非常高，因為當初花了數個月準備國考 如果先去業界上班，工作之後迷惘，想去考公務員，這時「Ctrl+Z」的成本就低很多，因為當初就是花一些時間面試而已 所以迷惘的社會新鮮人，我都是建議先去業界面試看看，再去考公務員 --- 再舉一個例子，年輕工程師想去大公司面試 vs 想去新創面試 大公司面試流程很多、面試成本很高，去新創通常聊一個下午就錄取了 所以迷惘的年輕工程師，我都是建議先去新創工作看看，如果之後再去大公司上班，心態就會很穩，因為你知道新創時髦的外表底下，其實愚蠢的地方也不少，你會比別人更看見大公司的美好 如果到了大公司才嚮往新創，到時再次反悔、重新面試大公司的成本就高很多、這樣很浪費時間 --- 我認為現代人，不管做什麼選擇，一定都會覺得迷惘、好奇當初沒做的那個選擇、常常會有遺憾 所以重點不是「如何第一次就做出正確決定」，因為做不到 重點是「**我該先做哪一個決定，到時反悔的話，可以 Ctrl+Z 不心痛呢？**」 這種路徑，比較不留遺憾，因為各種路都走過了，並且算是一種逐漸認識自己的過程 這樣做決定，會容易許多吧！我自己都是這樣做的～ --- 以這位網友面臨的狀況： - 降薪50%去類似環境的大公司上班，然後繼續迷惘新創公司是什麼樣子 - 降薪66%去新創公司看看，然後可能很喜歡、也可能發現是在浪費時間 如果選後者，去工作半年一年，真的不喜歡，頂多就是回去找大公司面試，這樣「Ctrl+Z」的成本也不高吧？ 我會覺得就去新創看看也沒關係，因為之後反悔的成本也沒多高，而且這種事就是體驗過才知道 # 結論 其實創新、創業，極度困難、要做的事情也很雜亂 在我跟各種新創公司合作的經驗來說，很多時候其實也是浪費時間、有點像在幫老闆圓個人夢想，產品本身很爛。當然我也跟很多優秀新創合作過、學到很多寶貴技能 總之去新創不一定好玩，也不一定學得到東西 但我認為有策略性地、管理好各種職涯選擇的成本、在過程中認識自己、增廣見聞、降低迷惘，是很重要的 這位網友如果本身有房貸、車貸、家庭孩子要養，那麼這個抉擇確實非常困難 另一方面，職業生涯不是只有充實金錢＆地位，能夠充實人生經驗＆體驗，也是很有意義的，不是嗎？ 建議靜下心，好好的幫自己分析一下、聽聽看內心的聲音，新選項真的讓你有「義無反顧」的感覺嗎？ --- 我另外還有一些幫助工程師觀察「眼前這位迷人的創業者，有沒有可能是個地雷」的技巧，有機會再跟大家分享吧～！ 以上，簡單幾點分享，希望對大家有幫助，祝各位都有滿意、幸福的職業生涯！
## 課程目標 - 認識 callback hell 與收尾處理 ## 課程內容 研究完 callback hell、promise chain、async/await 的錯誤處理 接著來用三課的時間，分別研究收尾處理吧！ 讓我們先從 callback hell 的寫法開始！ --- 什麼是收尾處理？ 其實就是，有些事情，不論任務執行成功 or 失敗，都固定要執行 這種事情，可以在 success callback 跟 error callback 最後都寫，但這樣就重複寫了，很煩！ 所以就有所謂的收尾處理，讓你寫一次就好了 如果繼續拿 jquery 做範例，看起來會像這樣： ``` $.ajax({ url: url, data: params, success: (res) => {}, error: (res) => {}, complete: () => {}, }); ``` 其實，就是再多一個 callback function 而已！很單純吧！ 在連續多個 ajax call 的時候，錯誤處理機制，再加上收尾處理機制，想想看 callback hell 會有多嚴重！ --- 看到這邊，你可能會想，到底什麼事情需要在收尾機制處理呀？ 其實，以我個人經驗來說，需要放進收尾處理的東西，其實很少 最常見的就是處理畫面上的「載入中，請稍等...」的文字，或者是畫面上「用來代表忙碌中的一個旋轉的圖示」 不論任務執行結果，都需要把這些文字、圖示隱藏 老實說，很多人根本連「忙碌中」這個狀態也沒做，導致 UX 不太好 所以實務上，如果你發現專案中不太會寫收尾處理，那也算正常，你就知道有這功能可以用即可 ## 課後作業 在第一課的作業，你已經體驗到了 callback hell 與錯誤處理的悲劇 忍耐一下，這一課要再體驗一下當年工程師的痛苦：加上收尾處理吧！ 請拿出第一課的作業，我們來改善這個頁面的 UX（使用者體驗），明確提示「忙碌中」這個狀態 --- - 請用 html 元素，在頁面中加入一段 `讀取中，請稍等...` 的訊息，這個元素預設不顯示 - 在開始呼叫 API 的地方，用 js 操作來讓那個 html 元素顯示 - 在結束呼叫 API 的地方，使用 `$.ajax()` 的 `complete` 參數，用 js 操作來讓那個 html 元素隱藏 寫完之後，你應該會發現，有點難寫，而且顯示/隱藏的時機，有點奇怪！ 如果想要讓顯示/隱藏的時機，完全正確，那就會重複很多一樣的 code！ 別懷疑，就是這麼難寫、這麼奇怪！這就是當年前端開發的為難之處！ 做出以上功能，你就完成這次的課程目標了！
## 課程目標 - 認識 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 更加難以閱讀、維護！ 這就是當年前端工程師，每天工作面臨的狀況！很悲慘吧！ 做出以上功能，你就完成這次的課程目標了！
本課程為 JavaScript 非同步訓練的第二部份 第一部份的專案練習，已經學習到非同步的基本觀念 第二部份，將繼續學習非同步與「錯誤處理」、「收尾處理」的關係 本系列教材，一樣會按照時光推進，讓您知道為何會有這麼多寫法、為何演化到今天這樣子！ 準備好的話，讓我們馬上開始吧！
## 課程目標 - 認識 callback hell ## 課程內容 在一般「同步程式設計語言」中，程式碼執行的順序，就是一行一行跑下來，很容易理解 但 JavaScript 是「非同步程式設計語言」，很多時候，執行順序不是一行一行跑下來 為了讓用戶能持續流暢操作瀏覽器介面，工程師需要在會用到「非同步」的地方使用特殊寫法 最原始、也最單純的做法是使用 callback function，也就是把要在非同步任務結束後才跑的任務，寫在 callback function 傳進去 以 jquery 最原始的 ajax 處理為例 ``` $.get(url, params, (data) => { // do something with data }) ``` 第三個參數，也就是箭頭函式的部份，就是所謂的 callback function --- 當年的前端工程師，在一開始覺得這樣寫沒問題，但是當網頁應用程式越來越複雜之後 發現在需要連續執行多個非同步任務時，會需要不斷傳 callback function 進去更深層 最後導致的結果，就是所謂的「callback hell」！這讓程式碼很難讀、很難維護！ ``` $.get(url, params, (data) => { // do something with data to get params2 $.get(url2, params2, (data) => { // do something with data to get params3 $.get(url3, params3, (data) => { // do the final task with data }); }); }); ``` 這樣描述比較抽象，來跟著作業，試著用當年的方式開發看看吧！ ## 課後作業 讓我們時光倒轉，回到 2000 年代，體驗一下當時的開發方式 請使用 https://jsfiddle.net/ 寫作業 請載入 jquery 套件，並且用 `jQuery.get()` 來處理 ajax ``` <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous"></script> ``` --- 假設你身為前端工程師，正在開發電商網站 今天，產品經理跟你說，為了提升 UX（用戶體驗） 希望能在網頁上顯示「最近一次的訂單內容」，就像這樣： ``` 尊貴的客戶您好，您上次的消費內容是： 訂單編號：XXX 訂單內容：XXX 訂單金額：XXX 希望這次也能有機會服務您！ ``` --- 目前後端工程師提供了三組 API 給你使用 使用當年的 jquery 寫法會像是下面這樣： ### 取得當前登入用戶的資料 為了簡化起見，你不用實作「登入、驗證」等等功能 就當作用戶已經登入了，請直接呼叫這個 API 即可 ``` $.get("https://codelove.tw/fake-api/get-current-user", {}, (res) => { console.log('the current user id is:' + res.data.user.id) }); ``` ### 取得指定用戶的全部訂單 ``` $.get("https://codelove.tw/fake-api/get-orders", { user_id: 1 }, (res) => { console.log('get ' + res.data.orders.length + ' orders'); }); ``` ### 取得指定訂單的內容細節 ``` $.get("https://codelove.tw/fake-api/get-order-details", { order_id: 1 }, (res) => { console.log('the order id is #' + res.data.order.id); console.log('the order content is ' + res.data.order.content); console.log('the order amount is $' + res.data.order.amount); }); ``` - 請依序呼叫這三個 API，來完成這次需要的功能 - 把第一個 API 拿到的 user id 放進第二個 API 呼叫 - 把第二個 API 拿到的最後一個 order id 放進第三個 API 呼叫 - 把第三個 API 拿到的資料，顯示在網頁上 請注意，不要使用現代的非同步寫法，請使用 callback hell 的寫法，也就是： - 在第一個 API 的 callback function 裡面呼叫第二個 API - 在第二個 API 的 callback function 裡面呼叫第三個 API - 在第三個 API 的 callback function 裡面完成最終需要的功能 寫完之後，你應該會看到有三層深度的巢狀 callback 傳遞！ 這就有一點悲慘了，有點 callback hell 的感覺！ 做出以上功能，你就完成這次的課程目標了！
阿川收到網友提問如下： > 您可以分享您的軟體工程師職崖規劃嗎?再次感謝 我個人的職涯規劃其實比較偏激，是同時做「上班＆接案＆創業」這三件事 我簡單說明一下爲什麼我會這樣做，給大家參考 --- 我是 79 年次，2013 年退伍的，大學資管系畢業 出社會第一個月我就發現，我滿不喜歡上班的，但是我沒有能力、也沒有錢創業 於是我設計了一個我稱之為「三把梯子」的方法論，作為長期生涯指引 # 三把梯子理論 第一把梯子是上班：成為資深工程師、跳槽更大公司、賺更多薪水，這樣不斷往上爬 第二把梯子是接案：接親戚朋友介紹的案子、累積個人品牌、得到更多的客源，開公司接案，這樣不斷往上爬 第三把梯子是創業：研發軟體產品，從 side project 開始，從 open source 開始，學習行銷，學賺錢、寫更多產品、開公司創業，這樣不斷往上爬 基本上就是上班族、自由工作者、創業者三種職業生涯 --- 我給自己的三把梯子指引是：先從第一把梯子開始往上爬，稍微爬一段，就往旁邊的第二把梯子踩過去，接著爬 接著在第二把梯子慢慢往上爬，稍微爬一段，準備好了就往第三把梯子爬過去，慢慢往上爬 在這個過程中，只要覺得腳步沒踩穩、會摔死，就往回踩過去，爬前一把梯子 你可能覺得很離譜：想要同時兼顧三件事，不就會變成通通都搞砸嗎？ 其實，你只要... # 做同時對兩三把梯子有幫助的事情 職涯的大方向有了，接著就是付諸行動，要做一些能「同時對兩三把梯子有幫助」的事情 ## 部落格 我在 2013 年想到的事情是「寫部落格」，我非常勤奮地寫了兩三年，很多文章都還找得到 - https://blog.turn.tw/ - https://startup.turn.tw/ - https://dev.turn.tw/ 寫部落格、並且試著得到流量，會同時學到寫作、銷售、溝通能力，對三把梯子都會有幫助 我在寫到多篇文章都有數十萬瀏覽量之後，我就大致知道自己掌握這項技能了 ## 研討會 接著我想到的事情是「參與 conference 分享」 其實這沒有大家以為的那麼難，算是寫作的延伸加強版而已，拿原創的文章去一些小聚、研討會發表 我在成為 PHPConf Taiwan 2015 以及 LaravelConf Taiwan 2018 的講者之後，我就大致知道自己掌握這項技能了了 ## 做專案 再來是「寫 side project」以及做「open source」 一開始可以先做好玩為主，但之後要稍微從一些商業野心出發，才能學習 `monetization` （賺錢）這件事 我做了一些專案，在國內外論壇到處分享，成績馬馬虎虎，但我也學到很多 --- 上面這三件事情，會同時對「前兩把梯子」有巨大幫助，在找工作、或者接案的時候，很多人會更信賴你，對第三把梯子也會有點幫助 當然，像這樣同時爬三把梯子，沒辦法跟「專心爬一把梯子」的人比，這是一定的，而且要付出的時間相當龐大 但是，這讓我獲得足夠的安全感，避免一次做太高風險的事情，而且也有後路可退 # 我目前的三把梯子的進度 第一把：我現在去投履歷、找工作，在各種大小的公司都還是有面試機會，也有很多業界的朋友可以幫忙介紹，要上班沒問題 第二把：在完全不主動去找案子的情況下，很多朋友會幫忙轉介紹案子給我 我也是美國接案平台的簽約工程師 https://www.toptal.com/resume/chuan-hao-you 有時會接一些歐美的案子，所以要接案沒問題 第三把：我大概做了70個左右的 side project 目前正在經營的有這幾個 梗圖工具 https://memes.tw/ 每月60萬不重複使用者 咖啡廳資料 https://cafenomad.tw/ 每月3萬不重複使用者 活動平台 https://yii.tw/ 每月2萬不重複使用者 工程師交流 https://codelove.tw/ 您目前正在看的網站 另外還有 房地產 https://landchart.tw/ 書評網 https://wenwen.life/ 美女圖 https://beautyhunt.tw/ 批踢踢閒逛 https://www.ptt.best/ 這些網站，其中有幾個，是有一些收入的，所以第三把創業的梯子也還可以 目前這三把梯子，其實我都還正在爬，並沒有最後一定會待在哪一把梯子上面 # 結論 這邊簡單分享我替自己設計的職業生涯，「三把梯子」算是一種很偏激的職業生涯 業界像這樣做的工程師應該非常少數，最大缺點就是要花費的時間非常多，優點就是，其實樂趣不少 其實，學無止盡，這就只是同時在「技術」跟「商業」兩方面花時間學習而已 能分享的事情還有很多，大家有興趣就多多按讚吧，也許我再多寫一些這方面的文章！ 也歡迎大家多多發表文章，這個 CodeLove 就是我做來給工程師們互相交流的地方！ 以上簡單分享，希望對你有幫助～！
某種角度來說，我認為當工程師是很幸運的，能有兩種角度去經營個人品牌：菁英路線 vs 社群路線 --- # 菁英路線 菁英路線就是想辦法得到頂尖軟體公司的認可，比如說 Google Facebook Microsoft IBM 或者台灣本土一些知名軟體公司 或者矽谷一些設點在台灣的軟體公司 這種通常要刷 LeetCode、做大量面試準備、可能大學學歷也要很好看 這種履歷表一但有了一間，後面一間一間換，整個履歷表看起來就很漂亮 薪水好 社會地位高 大家都覺得你超猛 但這路線只適合少數人 # 社群路線 社群路線我覺得簡單、好玩很多 就是每當你的實力有所成長，就找機會大方分享 不論是寫網誌、報名 conference 分享、報名小聚分享 或者參與 open source 討論、發 PR、在 stackoverflow 問答 都是很好的貢獻方式！重要的是，這些貢獻最好能量化、有相關網址連結，在投履歷的時候可以附上 也可以在個人檔案頁面附上，這樣才能越累積越多、讓人一目瞭然 如果是在聊天室參與討論、在 FB 社團參與討論，就很可惜，相關貢獻沒辦法變成單獨網址、附上履歷表 這種路線經營一陣子後，在業界的工作機會、接案機會、合作機會，也會多很多 --- 第一條路線是面對少數人，爭取他們的認同，也就是其他精英、以及公司面試官的認同 第二條路線是面對社群，爭取他們的認同，也就是面對社群五花八門的意見、各類不同族群 就我個人來說，我是走第二條路線，這跟個性有關 --- 身為軟體工程師，我認為至少要在其中一種路線，稍微有所經營 職業生涯上，才會有點安全感，不然會常常有被淘汰的擔憂、面臨社會新鮮人競爭的擔憂
## 課程目標 - 能夠從 Github 抓專案下來 ## 課程內容 我們在上一課發佈專案到 Github 了 這次來學習把專案從 Github 抓下來吧！ 首先來把電腦上的專案刪掉，模擬我們今天拿到一台新電腦的情境 在主視窗點選 `Current Repository` 會秀出專案列表 對著我們的專案 `my-first-repo` 按右鍵，然後選 `Remove` 刪除，確認視窗繼續按 `Remove` 會發現 Github Desktop 變回初始畫面了！ --- 但目前只是 Github Desktop 停止追蹤專案而已，那個資料夾其實還在電腦上喔 請在電腦上，直接前往那個資料夾，會發現檔案都還在 請把 `my-first-repo` 整個資料夾刪掉，這樣才是真的模擬拿到新電腦 --- 現在來試著把專案從 github 抓下來吧！ 點擊 `Clone a Repository from the Internet` 因為已經登入 github 了，應該會顯示專案列表 找到上次發佈的 `my-first-repo` 專案 （如果專案沒出現，畫面上有一個重新整理的按鈕，按一下） 然後 `Clone` 按鈕按下去 成功囉！專案回來囉！ `History` 分頁按下去，看看是不是跟之前都一模一樣？ 軟體工程師在跨裝置工作（使用多台電腦）、或是多位工程師合作時，就是這樣同步專案內容的！ ## 課後作業 接續前一課的作業，專案已經傳到 github 了 現在來模擬你拿到新電腦，第一次從 github 抓專案的情境 請把原本電腦上的那個專案資料夾，整個刪掉 這時去看 Github Desktop，應該會顯示「Can't find」開頭的提示 請將 Github Desktop 視窗截圖，這是本次作業的第一張截圖 截圖完畢之後，點擊畫面上的 `Remove` 將這個專案刪掉 --- 現在電腦上已經沒有專案了，就當作你今天拿到一台新電腦，準備開始工作，要把 github 上的專案抓下來 請點擊 `Add` 然後選 `Clone Repository...` 接著找到你在 github 上的專案 把剛剛那個專案整個抓下來之後，你應該會發現，剛剛整個刪掉的專案資料夾，現在內容又通通出現囉！ 請將 Github Desktop 視窗截圖，這是本次作業的第二張截圖 --- 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 請把第一張、第二張截圖，分別貼到留言區
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本論壇另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
