🔍 搜尋結果:技術

🔍 搜尋結果:技術

JavaScript 系列八:結語

恭喜你完成了一系列的專案開發挑戰 放眼市面上的新手教材,應該沒人會把作業設定到這麼困難! 但我認為時機差不多了,所以要求一些有挑戰性、有趣的專案來讓你做,應該難不倒你 而且這種只用基本功能,就完成複雜專案的經驗,有助於掌握框架的本質、熟練框架基礎 既然你通通順利完成了,代表你的學習狀況「相當不錯」...... 再次跟你說聲恭喜! --- 這些專案內容,已經相當接近實務上、職場上會遇到的開發需求 也就是說,你的開發經驗已經「大大提升」了不少 事實上,光是目前的技能與經驗,已經可以應付職場上絕大多數的功能要求 你已經離「進入職場工作」,又大大靠近了一步! 但是呢,要能夠與團隊共同開發中大型專案,還是需要學習框架進階觀念、生態系、以及 JavaScript 生態系各種工具 坊間補習班,通常會在課程很早期開始教上述這些內容。我認為這會令學習者非常眼花撩亂 所以我讓你僅僅學完 `Essentials` 的內容,就立刻動手開發複雜、好玩的應用程式 我認為這樣才能清楚認識框架的強大,以及知道「工具不是導入越多、搞得越複雜就越好」 而是要視情況,只導入必要的、大小適宜的技術工具,這樣才能收放自如 那麼更大型的專案,又該引入哪些進階觀念、生態系工具呢? 這些會在後續的課程提到! --- 消化、研究完本課程之後,關於 JavaScript 更多必學的基本觀念 請接著前往「自學網頁の嬰兒教材:JavaScript(九)」開始學習吧! https://codelove.tw/@howtomakeaturn/course/QxMYx5

前 Netflix 資深工程師:爲什麼我會辭掉年薪 $450,000 美元的工作

Michael Lin 是前網飛資深工程師,年薪高達 45 萬美元,約合新台幣 1300 萬元 但是他在工作四年後離職了,並且在網路上分享了心得 - 原文出處:https://dev.to/_michaellin/why-i-quit-a-450000-engineering-job-at-netflix-1f0g --- ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ucmypesj5zywleeojx92.png) > 金手銬 —— 你留在一份你寧願辭職、只是為了錢而待著的工作。 我以為我會永遠留在 Netflix。市場上薪酬最高。講求自由與責任。無限帶薪假期。你還能要求什麼呢? 所以當我在 2021 年 5 月離開 Netflix 時,每個人都認為我瘋了。我父母首先反對。他們來自文化大革命時期的中國,當時幾乎沒有足夠的食物吃,他們認為我正在拋棄他們來到美國所經歷辛苦的一切。 “低下頭去幹活就對了!”他們說。 “不要對你所擁有的不知感恩!”他們說。 我的朋友們也不相信。 “有一堆免費食物欸!” “FAANG 巨頭欸!” “帶著慢慢領股票呀!” 我聽到的唯一讓我略微停頓的反對論點,來自我在 Netflix 的導師。他說我不應該在沒有找到另一份工作的情況下辭職,因為“我會放棄我在 Netflix 的高薪所擁有的影響力。” ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lb8qyf1sxngv1xeateei.png) > 一邊休息一邊慢慢領股票 這讓我停頓了整整 3 天,但我還是放棄了。8 個月後的現在,我 100% 確定這是正確的決定。 在這篇文章中,我想談談幫助我了解金手銬真正成本的 3 個因素,以及為什麼每年 50 萬美元的薪水也無法讓我繼續從事我不再喜歡的工作。 ## 一個失敗的角色轉換 隨著辦公室於 2020 年 3 月關閉,工作中所有最好的部分 ——社交、同事、津貼,都消失了。 而你剩下的就是工作本身。因此,如果您不喜歡這份工作,而這就是您的全部,那麼 COVID 會將這一事實放大 10 倍以上。 而且我不喜歡這份工作。但原本不是這樣的。 我在 Netflix 工作了將近 4 年,擔任用戶增長方面的資深軟體工程師。一開始,我覺得自己得到了豐厚的報酬來學習。工作了 1.5 年左右,我都喜歡它。 Netflix 的文化與我之前在亞馬遜經歷過的更為隱秘的文化截然不同。每個產品決策的備忘錄都可供所有員工閱讀。這就像拿錢去讀 MBA。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2amgontvgl7nkhlkecsf.png) > Netflix 對其所有產品決策的透明度是在那裡工作的最佳福利之一。這與蘋果和亞馬遜更為隱秘的文化形成鮮明對比。 但是在我的後半段時間裡,工程工作開始感覺像是複制粘貼。 需要啟動一個新的微服務? 複製粘貼一個舊的,更改業務邏輯,你就完成了。 新的 A/B 測試? 複製粘貼舊的,更改一些測試變體,就完成了。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8g1j19x9dvj8lvbga9wk.png) > Netflix 非常喜歡 A/B 測試。這是他們從主頁(來自 Netflix 技術部落格)測試的 CTA 的 4 個變體 我覺得毫無疑問工程可以為 Netflix 所用,但我覺得更好的問題是,某個特定專案是否充分利用了工程資源。所以我想過渡到產品管理,在那裡我可以領導這些工作。我花了 2 年的時間在公司轉了一圈,不停地建立聯繫,與每個組織交談,併申請我能找到的每一個職位。 當我向每個組織申請時,我提交了關於我作為 PM 的優先事項的建議:客戶服務、開發人員生產力、工作室、合作夥伴關係和通知。我建議在我自己的團隊中建立一個角色來幫助管理不斷增長的基礎設施。我還建議其他 PM 可以將更多工作委託給我,這樣他們就可以騰出時間來發展他們的組織。所有這些提議最終都沒有成功。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rchwbz4agbjhitt38tiq.png) > 我花了 2 年的時間兜圈子試圖在 Netflix 找到一份 PM 的工作,但最終落得一場空。 回過頭來看,我意識到自己的錯誤。我想如果我再努力一點,我最終會得到這份工作。但現在我意識到,有時由於結構性問題,事情超出了你的控制。 Netflix 沒有適當的流程來支持這樣的橫向角色變更;我從未見過工程師在這裡成功過渡到產品管理。 他們為我提供了更多與產品管理合作的機會,以培養產品技能,對此我深表感謝。但合作與擁有角色本身不同。歸根結底,你不能只讀一本關於游泳的書就指望學會游泳。你必須跳入水中。 ## 動力減弱,表現減弱 在我失敗的 PM 求職接近尾聲時,我覺得高薪是一個越來越糟糕的優點。原本是在賺錢和學習。現在我只是在賺錢。 我團隊的目標和我的興趣也開始出現分歧。我的團隊正在朝著涉及平台遷移的更注重工程的方向發展。但我的興趣更多地轉向創業和產品管理。我分配的工程工作永遠不會適用於我以後所做的任何其他工作。 我開始覺得我又犯了以前的職業錯誤 - 在一份不適合我的工作上待的時間比我應該做的要長。這個錯誤的代價比人們想像的要高。如果你在一份你想離開的工作上多呆了兩年,並且在你的一生中做了 5 份以上的工作,那麼你只是在你不想做的工作上浪費了你生命中的 10 年。我覺得我在浪費時間。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mz85i3mpvnky6zos5qye.png) > 沒有什麼比錯過工作訊息更讓人焦慮的了。 我的動力減弱了,我的表現也隨之減弱。我越來越少參加會議,盡量減少做任何與開發產品管理技能不直接相關的工作,並在溝通方面拖拖拉拉。最後唯一的動機就是不想被解僱。感覺我已經達到了我的目標是這麼低的標準,甚至努力跨越它,這讓我有點難過。 不幸的是,我的經理開始注意到了。在持續 2 個多小時的激烈績效評估中,他告訴我,我需要 1) 更多地參與這次遷移,以及 2) 更加溝通。用他的話說,“如果我想留在團隊中”,我必須在這些方面有所改進。 ## 重新評估 COVID-19 期間的生活優先事項 疫情大流行是一記警鐘。 看著數以百萬計的人死於 COVID 讓我意識到明天是無法保證的。在您的任何夢想實現之前,您可能會死於 COVID。你推遲夢想的時間越長,它永遠不會實現的風險就越大。所以如果有什麼你想要的,你必須現在就去做。 不想再說晚點才是時候了。現在就是時候。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5oawd1k9a5lnzses4is3.png) > 被推遲的夢想就是被拒絕的夢想。我一直以來最喜歡的名言。 我意識到金手銬的真正代價是什麼。代價是你的青春,你的時間,你的生命。人們不會準確判斷這些成本,因為薪水是一個硬數字,而你的青春價值更無形。但僅僅因為某些東西難以衡量,並不意味著它的價值就低於金錢等可數的東西。很難衡量品牌、心理健康或愛情的價值,但我們知道這很重要。 看到所有這些人死於 COVID,我害怕有一天我的墓碑上會寫著: > “這裡躺著 Michael。他一生都在做他不想做的工作。然後他感染了 COVID 接著就死掉了。祝安息。” 我在一份我不喜歡的工作上待的時間越長,這成為我墓碑的可能性就越大。我知道我現在必須採取行動 - 我不能一直把棘手的職業問題推到一邊。我不得不辭職。 ## 最後的日子 我把糟糕的績效評估和被解僱的威脅當成是一種解脫。但我想在不被解僱的情況下先拿到遣散費。 因此,幾週後,我在一對一面談中,向我的經理提案,我們討論了“先發制人的遣散費方案”。 我這樣說:“我的表現在下降,因為我的動力在下降。我沒看到我的積極性有可能提高,因為團隊的目標與我的職業目標背道而馳。如果我們現在討論 Netflix 的先發制人遣散費而不是拖延下去會怎麼樣?這樣 Netflix 就可以省錢,你可以更快地找到更適合團隊的人選,我也可以去做我想做的事。對每個人來說都是雙贏的局面。” ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jpr7oownjm47eomrnyne.png) > 掙脫束縛。 在他與 HR 討論後,我與他和 HR 進行了最後一次會面,他們同意先發制人地解僱我,然後我拿到了最後的遣散費。金手銬 —— 再見了。 ## Netflix 之後的生活 我以為離開公司我的生活就結束了,但事實恰恰相反。我擔心我會沒有社交生活,但實際上我在退出後遇到了更多的人 —— 其他的創業者、企業家和建設者。 我看到我的心理健康得到改善,因為如果我錯過了另一封電子郵件或 slack 訊息,我因擔心而產生的焦慮消失了。 我現在感到內心深處的平靜,一種堅定的信念,即一切都會好起來的,即使現在不能保證未來的成功。當我在周日晚上打字時,如果工作對我有利,我對周末工作沒有任何問題。沒有比知道我掌握了自己工作的所有價值更好的動力了。 ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gvzbuxd6dx1klb8a6mdz.png) 通過只做讓我充滿活力的事情,它可能會諷刺地釋放比我以前賺的更多的潛在收入。 我從 2021 年 5 月辭職已經 8 個月了。我在 2021 年剩下的時間裡休息了一段時間。我在紐約住了幾個月,在猶他州和亞利桑那州進行了一次公路旅行,總體上很享受生活。 我決定全身心地為自己工作。雖然我才剛剛起步,沒有任何真正可靠的收入來源,但我會相信這個過程,如果我致力於讓我充滿活力的事情,好事就會發生。 --- 我現在真的相信,安全行事是最冒險的選擇。當你謹慎行事時,你同樣會暴露在所有的危險之中,而且沒有向上的機會。正如海倫凱勒曾經說過的: ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/srvmeb69o4owf6mhgu66.png) > 謹慎行事是最冒險的選擇。

JavaScript 系列七:結語

恭喜你完成這份奇怪的 Vue 入門課程 如同我在這門課程中不斷強調的 任何的技術工具,其實都充滿了大量的過時觀念、多餘觀念、錯誤觀念 也就是很多小功能、小語法,要嘛是已經很少人在用了,要嘛是重複設計了,要嘛是根本設計失敗了。這些學了也用不到 偏偏你在補習班或者上網自學的時候,沒有人敢跟你這樣講。因為講的人自己也不太確定、沒有真正深入了解 所以我在這門課程只引導你使用最基本的語法、用最基本的功能 你已經完成了所有作業,代表這些基本功你都順利掌握了 不要小看這種只專注在基本功的學習方法 把基本功摸熟的人,在有必要學習任何進階觀念的時候,會比別人更快融會貫通 --- 偷偷跟你說一句,即便是業界工程師、業界講師,大多數人對於程式設計、大型工具的許多觀念,也都是一知半解的 這沒有什麼問題,我也總是跟你說:能解決問題就好 比較有問題的是:不確定的東西,要知道自己不懂、承認自己也不確定。在有必要的時候,要知道往哪個方向去深究 除此之外,既然自己也不太確定,就不要跟別人說 XXX 寫法一定比 YYY 寫法好,諸如此類的話 在程式開發這個圈子,絕大多數意見,都只是主觀意見,卻被講得好像是科學證明過的公認客觀意見、有對錯之分。這絕非事實 請積極學習,但也請保持懷疑&批判的態度。面對新工具、新觀念,不需要感到太困擾或者焦慮 --- 翻閱 Vue 官方文件,你會發現 `Essentials` 這個段落,你幾乎通通讀完了 這些就是 Vue 的基礎觀念,已足夠你開發出各種易於維護、架構彈性的中型應用程式了 那麼該如何開發大型應用程式呢?那就需要更進一步學習模組化、元件等等的觀念 這些會在後續的課程提到! --- 消化、研究完本課程之後,關於 JavaScript 更多必學的基本觀念 請接著前往「自學網頁の嬰兒教材:JavaScript(八)」開始學習吧! https://codelove.tw/@howtomakeaturn/course/jqe6xX

JavaScript 系列七:第1課 ── 認識 Vue 基本環境與 render state

## 課程目標 - 能夠運行 Vue 基本環境 - 能夠 render state ## 課程內容 身為工程師,要習慣到處翻閱各種技術文件 這次的課程,我不會手把手帶領,細談所有觀念 我會一次提供一個官網連結。請你一邊閱讀,一邊把其中的範例貼到 jsfiddle 跑跑看 我會額外提供簡單介紹&關鍵字,然後補充一些注意事項 官網文件內容是英文,如果對英文沒把握,就去翻中文官網 https://cn.vuejs.org/guide/introduction.html 但是,長遠來說,還是要逐漸提升自己的英語閱讀能力才行 --- 先學基本的安裝&運行 - https://vuejs.org/guide/quick-start.html 這系列課程,我們用最簡單的 CDN 環境來跑就好了,先只學 CDN 那一段就好 --- 接著來學 Vue 最基本觀念 - https://vuejs.org/guide/essentials/application.html - https://vuejs.org/guide/essentials/template-syntax.html 內容很多,大部份看不懂沒關係,稍微有個印象就好 如同我在前言所說,同一件事有很多種花俏寫法,你根本不用全部學會 這一課我們只要學會如何 render state 就好了 ``` <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script> <div id="app"> {{ user.name }} 喜歡吃 {{ fruits[0].name }} 以及 {{ fruits[1].name }} </div> <script> const { createApp } = Vue createApp({ data() { return { user: { name: "John Doe" }, fruits: [ { name: "Apple", }, { name: "Banana", }, ] } } }).mount('#app') </script> ``` 上面這段範例,在 `data()` 函式將 application state 準備好 然後只要將一段作為 UI 的 html 寫好,我們稱之為模板(template) 接著 Vue 就會把 state 放進 template 裡面,把結果給 render 出來 貼到 jsfiddle 跑跑看吧,你會發現非常簡單、好理解 ## 課後作業 這系列課程,我們要模仿 Google Keep 製作一個應用程式 請先把玩一下 Google Keep https://keep.google.com/ 作業使用 jsfiddle 來寫 --- 這一課先簡單呈現 UI 就好 請使用以下這段 code 作為 application state ``` data() { return { notes: [ { title: "春節行程安排", content: "吃飽睡,睡飽吃", color: "red", }, { title: "工作待辦事項", content: "詢問各家廠商報價", color: "green", }, { title: "運動健身計畫", content: "每天早上六點去健身", color: "blue", }, ] } } ``` 使用以下這段 code 作為 template ``` <div id="app"> <div class="note"> <h3 class="title"> <!-- 請顯示第一個項目的標題 --> </h3> <p class="content"> <!-- 請顯示第一個項目的內容 --> </p> </div> <div class="note"> <h3 class="title"> <!-- 請顯示第二個項目的標題 --> </h3> <p class="content"> <!-- 請顯示第二個項目的內容 --> </p> </div> <div class="note"> <h3 class="title"> <!-- 請顯示第三個項目的標題 --> </h3> <p class="content"> <!-- 請顯示第三個項目的內容 --> </p> </div> </div> ``` - 陣列內容就只有三筆資料,就只要顯示這三筆資料就好 - 在 application state 裡面的陣列,直接用 `索引` 來取出值就好,這一課先不用寫 for 迴圈 - color 這一課還不會用到,可以先忽略沒關係 - 請在 `<style>` 加上一些樣式,讓整個頁面漂亮一點 - 每則記事可以單純的放進網頁就好,不用像 Google Keep 那樣花式的排版(那種叫瀑布流排版,很難寫) 做出以上功能,你就完成這次的課程目標了!

JavaScript 系列五:第4課 ── 學會 AJAX 基本原理

## 課程目標 認識基本的 AJAX 原理 ## 課程內容 這一課來認識大名鼎鼎的 AJAX 觀念 AJAX 全名 Asynchronous JavaScript and XML 簡單來說,就是「非同步從主機取得資料來更新網頁內容」的技術 舊式的網頁,都是瀏覽器向主機發送 HTTP 請求 -> 主機回應一大坨 html 內容 -> 瀏覽器顯示漂亮網頁給用戶看 因為是一次拿到一大坨 html 內容,我們說「網頁上全部內容都是同步取得」 現代的網頁,也是有很多頁面是這樣直接取得,但有更多功能,是依靠非同步取得資料之後來更新的 - 滑動到網頁下方,動態載入了更多貼文 - 對內容按讚,按讚成功網頁出現了小變化 - 聊天室與別人聊天,網頁也是一段一段文字更新 這些都是使用 AJAX 技術的例子 也就是先載入基本網頁內容,再接著根據需求,於不同時間點發送 HTTP 請求取得部份內容,所以叫做非同步 實務上,我們會說「這邊要發一個 AJAX 跟主機要資料」 --- 讓我們拿一個「模擬線上購物網站 API」來當作例子 https://fakestoreapi.com/ 發一個 AJAX 取得 ID 為 1 的用戶資料 ``` fetch('https://fakestoreapi.com/users/1') .then(res=>res.json()) .then(json=>console.log(json)) ``` 請在 jsfiddle 試試,看看結果 會看到一個包含信箱、ID、姓名、電話等等欄位的用戶個資,以物件的形式呈現 這邊使用了內建的 fetch 函式,參數放入要呼叫的 API 網址 接著使用 `.then()` 函式,由於是直接寫在後面,這相當於把 `fetch()` 回傳的東西,直接當成物件再接著呼叫 `.then()` 函式,然後再把結果當成物件再呼叫 `.then()` 一次 也就是跟這段一模一樣 ``` var result1 = fetch('https://fakestoreapi.com/users/1'); var result2 = result1.then(res=>res.json()); var result3 = result2.then(json=>console.log(json)); alert(result1) alert(result2) alert(result3) ``` 請在 jsfiddle 試試,會發現 console 顯示的個資一樣,這邊用三個 alert 觀察過程中的東西 會發現顯示三次 `[object Promise]`,這個 Promise 是一個進階觀念,這邊不細談,簡單講就是處理非同步請求的一種資料格式 `.then()` 參數傳進一個箭頭函式,這是省略大括號 `{}` 的箭頭函式寫法,其實就只是會自動回傳結果的函式寫法而已 但參數放了個函式,看起來有點怪,為何要這樣寫? --- 記得我們之前寫過的動態綁定 onclick 事件嗎? ``` <button id="my-btn">Click me</button> ``` ``` // 第一種寫法 function myFunction() { alert('你點擊了按鈕!'); } var btn = document.getElementById('my-btn'); btn.onclick = myFunction; ``` 網頁元素的事件處理,也是一種「非同步」程式設計 也就是我不確定「點擊」事件何時會發生,但我先「綁定」好事件發生時要做的任務,綁完就讓網頁正常呈現就好 上面的程式碼,可以改寫成這樣 ``` // 第二種寫法 var btn = document.getElementById('my-btn'); btn.onclick = () => { alert('你點擊了按鈕!'); } ``` 如果使用 jQuery,那還可以這樣改寫 ``` // 第三種寫法 $('#my-btn').click(() => { alert('你點擊了按鈕!'); }) ``` 第一種寫法,看起來像是:我先定義好函式,接著把函式名稱當作變數,綁定到 onclick 屬性 第二種寫法,看起來像是:onclick 這邊現場寫一個箭頭函式,把要執行的任務,當場交待清楚 第三種寫法,看起來像是:jQuery 提供的 `.click()` 函式,會負責把事件綁好,參數傳任務進去就對了 以上三種寫法,效果是完全一模一樣的! 所以你早就接觸過「非同步」程式設計了 也就是「有些任務現在還不會立刻執行,但我先把要執行的任務交待清楚,時間點到的時候,就執行」 以 UI 動作來說,時間點就是 `onclick` 之時、`onchange` 之時 以 AJAX 動作來說,時間點就是 `拿到主機回應` 之時 像這種不是馬上執行的動作,在 JavaScript 領域,我們習慣用「寫一段函式定義當作參數傳進去」來表達! --- 回頭看一下我們的範例 ``` fetch('https://fakestoreapi.com/users/1') .then(res=>res.json()) .then(json=>console.log(json)) ``` 因為 fetch 第一個回傳的結果,代表的是一個 `HTTP 回應物件`,這個回應物件的 HTTP body 是實際的 JSON 內容,可以用 `.json()` 函式取得內容 所以第二個 `.then()` 的參數,才是我們真正想做的事情 看不懂沒關係,我們多看幾個例子吧 取得全部用戶個資的 AJAX。觀察 console 結果,會看到一個陣列,內含大量個資物件 ``` fetch('https://fakestoreapi.com/users') .then(res=>res.json()) .then(json=>console.log(json)) ``` 取得五筆用戶個資,也是拿到陣列 ``` fetch('https://fakestoreapi.com/users?limit=5') .then(res=>res.json()) .then(json=>console.log(json)) ``` 以上內容,全部通通看不懂沒關係,畢竟,需要多了解一些 HTTP 協定與術語,比較好理解 你就先照做就好:要發 AJAX,就用 `fetch()` 函式,接著第一個 `then()` 要執行 `.json()` 函式,然後第二個函式才是你真正要執行的任務! ## 課後作業 請使用 https://jsfiddle.net/ 請使用「模擬線上購物網站 API」 https://fakestoreapi.com/ 假設正在開發一個讀取全部商品資料的頁面 用以下 html 為基礎 ``` <button>Load Products</button> <hr> <ul></ul> ``` 點擊按鈕,發送 AJAX 到 https://fakestoreapi.com/products 請求全部商品資料 拿到資料之後,將每筆資料用以下格式呈現,塞進 `<ul>` 元素裡面 ``` <li> <span>xxx</span> <button>Details</button> </li> ``` xxx 是商品名稱。點擊 Details 按鈕,連續跳出三個 alert,分別顯示 `id` `category` `description` --- 請注意,在 for 迴圈裡面綁定 onclick 事件的時候,for 迴圈的參數請加上 `const` 舉例來說,請這樣寫 ``` for (const product of json) { ``` 請「不要」這樣寫 ``` for (product of json) { ``` 否則,在迴圈裡面的 onclick 事件,執行起來會有 bug 原因跟上一課提到的 Hoisting 現象有關 我認為這是 JavaScript 的設計失敗,所以詳細原因我不想說明 這是屬於上個世代 JS 工程師的痛苦回憶,這一代的 JS 工程師不需要經歷 現在就用 ES6 語法,宣告變數一律記得加上 `const` 或 `let` 就對了 --- 做出以上功能,你就完成這次的課程目標了!

JavaScript 系列五:第3課 ── 變數作用域、箭頭函式、ES6 語法

## 課程目標 認識變數作用域 認識函式的不同寫法與特性 ## 課程內容 來認識一些程式語言觀念與名詞 ``` <button onclick="action1()"> global scope </button> <button onclick="action2()"> local scope </button> ``` ``` var counterA = 0; function action1() { counterA = counterA + 1; alert(counterA); } function action2() { var counterB = 0; counterB = counterB + 1; alert(counterB); } ``` 到 jsfiddle 跑跑看,會發現第一個計數器會不斷 +1 疊加上去;第二個計數器卻永遠顯示 1 這就是變數作用域的區別:變數宣告在很外面的,會在很大的範圍內都可使用這變數;變數宣告在很裡面的,只在裡面的範圍內才可使用這變數 宣告在最外面的稱為全域變數(global),反之則稱為區域變數(local) 目前為止的作業,其實你已經到處在寫 global 與 local 變數了,這觀念還算簡單、直觀 --- 用精確的技術名詞來說明的話 在 ES6 (2015) 之前,JavaScript 中的變數作用域只有 Global Scope 跟 Function Scope 兩種 並且,在使用 `var` 關鍵字時,要留意一種名為 Hoisting 的現象,這是一種會讓人搞錯變數作用域的現象 在 ES6 之後,有了 `const` 與 `let` 兩種新關鍵字,宣告的變數為 Block Scope 使用這兩種關鍵字,就不會出現 Hoisting 的現象 --- 我個人認為,Hoisting 是一個設計失敗的程式語言特性 應該要讓 JavaScript 引擎直接報錯、程式直接壞掉比較好 一般程式語言沒有 Hoisting 這種現象,此為 JavaScript 獨有特性 這是當年 Netscape 瀏覽器公司,為了衝市占率、歡迎大家亂寫 JS 程式碼的產物 我不想細談 Hoisting,反正改天你真的遇到問題,大概知道要往這方向研究就是了 --- 實務上,現在大家都寫 `const` 與 `let`,比較不寫 `var` 了 所以 Function Scope 跟 Block Scope 的差別在哪? 簡單來說,這樣的程式碼,x 正常顯示,y 會報錯 ``` if (true) { var x = 1; const y = 2; } alert(x); alert(y); ``` `var` 會覺得變數作用域,只有 `function 函式` 內、外的差別,內就是同樣 local,外就是 global `const` `let` 會覺得變數作用域,每次遇到 `大括號 {}` 都算一次內、外的差別,大括號裡面就是 local,裡面的裡面就是 local 中的 local 看不太懂沒關係,總之,變數宣告時,遇到 bug,就往前面找大括號,把變數搬來搬去,試試看,會慢慢搞懂的 本課先教你區分 global 與 local 兩種概念就好,這在大多數程式語言都是通用概念 在本系列教材內容以及作業中,`const` `let` `var` 隨便混著用,都可以 大概知道當前變數是 global 還是 local 就好 反正改天你真的遇到問題,大概知道要往這方向研究就是了 --- 接下來談一談 JavaScript 中的函式 之前的課程中,有過這樣的範例 ``` <button id="my-btn">Click me</button> ``` ``` function myFunction() { alert('你點擊了按鈕!'); } var btn = document.getElementById('my-btn'); btn.onclick = myFunction; ``` `myFunction` 被當成變數一樣,被指派給一個物件的屬性了 在很多程式語言中,函式是不能這樣使用的!函式永遠只能單獨加上小括號去執行 `myFunction()` 這個差別有點像是,其他程式語言認為變數是「名詞」,函式是「動詞」。那些語言認為這樣才能溝通、描述世界 而 JavaScript 認為變數是「名詞」,函式是「動詞」也是「動名詞」,也就是認為函式也是一種「名詞」。JavaScript 認為這樣才能溝通、描述世界 中文說「我開車」跟「開車很好玩」,沒有在管「開車」是動詞還是名詞,中文使用者就是習慣這樣溝通 英文說「I drive」跟「Driving is fun」,句子裡面主詞的部份一定要是名詞,如果想放動詞,就先改寫成 +ing 動名詞,英文使用者就是習慣這樣溝通 上面通通看不懂沒關係,反正知道各種程式語言,都是設計者與社群的主觀偏好,然後都能完成任務、各有不同長處短處就好 --- 最後,跟大家談一下函式的不同寫法 ``` function func1() { alert(1); } var func2 = () => { alert(2); } func1(); func2(); ``` ES6 之後有所謂的箭頭函式 他跟傳統寫法的主要差別,在於對於 `this` 關鍵字的認定 在工程師主流推崇 OOP(物件導向程式設計)的年代,`this` 的使用很巧妙、也很讓人困惑 實務上現在寫前端,比較少用 OOP 寫法,稍微偏向 FP(函數式程式設計)多一點,所以 `this` 問題變比較小 我不想細談 `this` 以及兩種函式寫法的差別,在本系列教材內容以及作業中,隨便混著用,都可以 反正改天你真的遇到問題,大概知道要往這方向研究就是了 ## 課後作業 請使用 https://jsfiddle.net 用以下 html 為基礎(你可以稍微修改),id 跟 class 之類的你可以自由決定 ``` simple counter: <button>-</button> <button>+</button> <hr> simple calculator: <input type="text" /> <input type="text" /> <button>加/減/乘/除</button> ``` 這邊有兩個小型應用程式 第一個應用程式,是簡單的計數器 - 第一次點擊 + 號按鈕,會用 alert 跳出 1 - 第二次點擊 + 號按鈕,會用 alert 跳出 2 - 依此類推,每次點 + 都會遞增,每次點 - 都會遞減 - 你會宣告一個全域變數,記錄這個累積的值,才能完成此功能 第二個應用程式,是簡單的計算機 - 有兩個欄位可以輸入數字 - 點擊按鈕,連續跳出四個 alert,分別顯示「加/減/乘/除」的計算結果 - 例如:輸入 6 與 2 -> alert 顯示 8 -> alert 顯示 4 -> alert 顯示 12 -> alert 顯示 3 - 你會宣告兩個區域變數,分別記錄兩個輸入的值,接著用來進行四種計算,才能完成此功能 --- 做出以上功能,你就完成這次的課程目標了!

JavaScript 系列五:第1課 ── 學會 Cookie 相關功能

## 課程目標 認識並且能使用 Cookie 相關功能 ## 課程內容 大名鼎鼎的 cookie,很多人在科技新聞上都聽過 某某公司利用網頁 cookie 追蹤個資、某某公司偷偷用 cookie 分享個資 這類新聞提到的 cookie,就是本課在說的 cookie 目前為止的作業,你會發現只要重新整理網頁,畫面上的所有東西就都歸零回預設值了 因為我們說網頁 HTTP 協議是「無狀態」的,也就是每次打開網頁的「狀態」不會被保留 這樣的設計當然有好處以及方便的地方,因為每次打開網頁都是獨立事件、彼此不會互相影響,開發起來單純很多 但是在實務上,經常需要「有狀態」才能完成某些功能,例如「已登入帳號」的狀態,否則網站會變很難用 Cookie 技術就是為了這個原因而誕生 --- Cookie 主要有兩個特性 - cookie 的內容,主機端也能存取 - cookie 的內容,網頁重新整理之後還會保留 Cookie 會出現在 HTTP Request 內,一起送到主機 會員登入功能、各種廣告追蹤功能,就是這樣做到的 HTTP 協議不熟沒關係,反正就是前端工程師設定過 cookie 值之後,後端工程師也能在主機端拿到那些值就對了 --- 注意,由於 cookie 會包含一些網站上的敏感資訊,jsfiddle 等等線上程式碼實驗工具、以及各種免費架站工具,幾乎通通都關閉了 cookie 功能 我目前找到一個可以用 cookie 的架站工具 https://replit.com/ 本課請使用 replit 來跑範例程式碼、寫作業 註冊登入之後,點 Create -> Templates -> 選 HTML, CSS, JS 那個 -> Create Repl 就可以開始寫了,但是右邊的預覽視窗,因為是 iframe,一樣不能用 cookie 請點擊右上方的 Open in a new tab,就可以正常跑 cookie 功能了 --- 來看一些範例程式碼吧 ``` Your Age: <input type="text"> Your Name: <input type="text"> <button onclick="save()">Save</button> <script> if (document.cookie) { alert(document.cookie); var arr = document.cookie.split(';'); var myage = arr[0].split('=')[1]; var myname = arr[1].split('=')[1]; document.querySelectorAll('input')[0].value = myage; document.querySelectorAll('input')[1].value = myname; } function save() { var myage = document.querySelectorAll('input')[0].value; var myname = document.querySelectorAll('input')[1].value; document.cookie = 'myage=' + myage; document.cookie = 'myname=' + myname; alert('saved!'); } </script> ``` 這個範例中,輸入年齡、名字一次,接著重新整理網頁,會發現資料一樣存在欄位裡面,不用重新輸入! 存取值,都是透過 `document.cookie` 這個物件屬性,值的格式是 `name=value` 雖然 `document.cookie=` 寫了兩次,但第二次並不會蓋掉第一次的值,而是兩個都存進 cookie 了 (這個設計,很糟糕,沒錯,讓人看得很混亂。應該是瀏覽器的設計者,有他們的苦衷,我們先不細究原因,先知道怎麼用就好) 然後,讀取的時候,多個值會用分號 `;` 隔開,所以讀取時我用了 `.split()` 這個字串函式 除此之外,cookie 還可以設定「使用期限」以及「限定網域」,但我這邊就先不示範 總之,cookie 的效果大概就是這樣,稍微理解就好。然後這些值,後端工程師在伺服器端,也會收到,就這樣! --- 如上所示,cookie 寫起來,有點麻煩 實務上,每次都這樣手寫,太囉唆,通常會直接找套件來用,我是用這款 https://github.com/js-cookie/js-cookie 用來操作 cookie 的 API,漂亮多了! --- 關於 cookie 的 debug 除錯,也要知道一下 打開瀏覽器開發者工具 -> Application -> Cookies 可以看到網站上有哪些 cookie,也可以直接在這邊修改、刪除 cookie --- cookie 還有一些特性,以及大小限制、使用限制 這邊不細談,稍微知道怎麼用 cookie 就好 有興趣的話,請上網搜尋一下,多研究一些 cookie 的細節 ## 課後作業 請使用 https://replit.com/ 來寫作業 假設你正在幫客戶寫一個「成人限制級網站」 頁面第一次打開會顯示蓋板警告,下方有兩個按鈕 ``` 警告︰您即將進入之網頁內容需滿十八歲方可瀏覽。 根據「兒童及少年福利與權益保障法」規定,本網站已於非闔家皆宜之網頁加以標示。若您尚未年滿十八歲,請點選離開。若您已滿十八歲,亦不可將本站之內容派發、傳閱、出售、出租、交給或借予年齡未滿18歲的人士瀏覽,或將本網站內容向該人士出示、播放或放映。 您年滿十八歲嗎? [離開] [是,我已年滿十八歲] ``` - 點擊離開,把用戶跳轉到 google 首頁 - 點擊確認,就關閉蓋板警告,在網頁上顯示一張美女 or 帥哥圖片:參考圖庫 https://unsplash.com/ - 只要按過確認,重新整理之後,蓋板警告就不會再跳出來 做出以上功能,你就完成這次的課程目標了!

現代前端框架的背後觀念:新手必讀基本功

框架背後有什麼必學觀念的?這篇文章簡單整理如下 原文出處:https://dev.to/lexlohr/concepts-behind-modern-frameworks-4m1g --- 很多初學者會問“我應該學哪個框架?”和“學一個框架之前需要學多少JS或TS?” - 無數自以為是的文章都在宣傳作者首選框架或庫的優勢,而不是向讀者展示其背後的概念、教他們如何做出明智的決定。讓我們先解決第二個問題: ## “在學習框架之前要學多少 JS/TS?” 盡可能多地理解它們的基本概念。您將需要了解基本資料類型、函數、基本運算符和文檔對像模型 (DOM),這是 HTML 和 CSS 在 JS 中的基礎。雖然先學一點當然沒關係,但沒必要先精通框架或庫。 如果您是一個完全的初學者,[JS for cats](http://jsforcats.com/) 可能是您第一步的好資源。繼續前進,直到您感到自信為止,然後繼續前進,直到您開始感到自信不足。那就是你了解足夠的 JS/TS 並可以開始學框架的時間。其餘的你可以邊走邊學。 ## “你指的是什麼概念?” - 狀態 - 效果 - 記憶化 - 模板和渲染 所有現代框架都從這些概念中衍伸出它們的功能。 ### 狀態 狀態只是讓您的應用程式跑起來的資料。它可能在全局級別上,適用於應用程式的較大部分,或適用於單個元件。讓我們以一個簡單的計數器為例。它保留的計數是狀態。我們可以讀取狀態並寫入狀態以增加計數。 最簡單的表示通常是一個變數,其中包含我們的狀態所包含的資料: ``` let count = 0; const increment = () => { count++; }; const button = document.createElement('button'); button.textContent = count; button.addEventListener('click', increment); document.body.appendChild(button); ``` 但是這段程式碼有一個問題:對 count 的更改,就像對 increment 所做的更改一樣,不會更新按鈕的文本內容。我們可以手動更新所有內容,但這對於更複雜的用例來說並不能很好地擴展。 `count` 更新其用戶的能力稱為*反應性*。這是通過訂閱並重新執行應用程式的訂閱部分來更新的。 幾乎每個現代前端框架和庫都有一種響應式管理狀態的方法。解決方案分為三部分,至少採用其中之一或混合使用: - Observables / Signals - Reconciliation of immutable updates - Transpilation #### Observables / Signals Observables 基本上是允許藉由訂閱閱讀器的函數來進行讀取的結構。然後訂閱者在更新時重新執行: ``` const state = (initialValue) => ({ _value: initialValue, get: function() { /* subscribe */; return this._value; }, set: function(value) { this._value = value; /* re-run subscribers */; } }); ``` 這個概念的第一個用途之一是在 [knockout](https://knockoutjs.com/) 中,它使用相同的函數,帶和不帶參數進行寫/讀存取。 這種模式目前正在以「信號」的形式復興,例如在 [Solid.js](https://www.solidjs.com/docs/latest/api#createsignal) 和 [preact signals](https://preactjs.com /guide/v10/signals/),但在 [Vue](https://vuejs.org/) 和 [Svelte](https://svelte.dev/) 的底層使用了相同的模式。 [RxJS](https://rxjs.dev/) 為 [Angular](https://angular.io/) 的反應層提供動力,是這一原則的延伸,超越了簡單狀態,但有人可能會爭辯說它模擬複雜性的能力可能反而綁手綁腳。 [Solid.js](https://www.solidjs.com/) 還以儲存(可以通過 setter 操作的物件)和可變(可以像平常一樣使用的物件)的形式進一步抽象這些信號 JS 物件或 [Vue](https://vuejs.org/) 中的狀態來處理巢狀狀態物件。 #### Reconciliation of immutable states 不變性意味著如果一個物件的屬性發生變化,整個物件引用必須改變,所以簡單的引用比較可以很容易地檢測到是否有變化,這就是協調器所做的。 ``` const state1 = { todos: [{ text: 'understand immutability', complete: false }], currentText: '' }; // updating the current text: const state2 = { todos: state1.todos, currentText: 'understand reconciliation' }; // adding a to-do: const state3 = { todos: [ state.todos[0], { text: 'understand reconciliation', complete: true } ], currentText: '' }; // this breaks immutability: state3.currentText = 'I am not immutable!'; ``` 如您所見,未更改專案的引用被重新使用。如果協調器檢測到不同的物件引用,它會再次使用狀態(props, memos, effects, context)來重跑所有元件。由於讀取存取是被動的,這需要手動指定對反應值的依賴性。 顯然,您不是以這種方式定義狀態。您可以從現有屬性建置它,也可以使用所謂的 reducer。reducer 是一個函數,它接受一個狀態並返回另一個狀態。 [react](https://reactjs.org/) 和 [preact](https://preactjs.com/) 使用此模式。它適合與 vDOM 一起使用,我們將在稍後描述模板時探討它。 並非每個框架都使用其 vDOM 來使狀態完全響應。 例如 [Mithril.JS](https://mithril.js.org/components.html#state),元件會在設置的事件後變化後更新狀態;否則你必須手動觸發 `m.redraw()`。 #### Transpilation Transpilation 是一個建置步驟,它重寫我們的程式碼以使其在舊瀏覽器上執行或賦予它額外的能力;在這種情況下,該技術用於將簡單變數更改為反應系統的一部分。 [Svelte](https://svelte.dev/) 基於一個轉譯器,該轉譯器還通過看似簡單的變數宣告和存取為其反應式系統提供動力。 順便說一句,[Solid.js](https://solidjs.com) 使用轉譯,但不是針對它的狀態,只是針對模板。 ### 效果 在大多數情況下,我們需要對反應狀態做更多的事情,而不是從中衍伸並渲染到 DOM 中。我們必須管理副作用,這些都是由於視圖更新之外的狀態更改而發生的所有事情(儘管 [Solid.js](https://solidjs.com) 等一些框架也將視圖更改視為效果)。 還記得第一個例子中,訂閱處理被故意遺漏的狀態嗎?讓我們完成這個處理效果,來作為對更新的反應: ``` const context = []; const state = (initialValue) => ({ _subscribers: new Set(), _value: initialValue, get: function() { const current = context.at(-1); if (current) { this._subscribers.add(current); } return this._value; }, set: function(value) { if (this._value === value) { return; } this._value = value; this._subscribers.forEach(sub => sub()); } }); const effect = (fn) => { const execute = () => { context.push(execute); try { fn(); } finally { context.pop(); } }; execute(); }; ``` 這基本上是 [preact signals](https://preactjs.com/guide/v10/signals/) 或 [Solid.js](https://solidjs.com) 中反應狀態的簡化,沒有錯誤處理和狀態突變模式(使用接收前一個值並返回下一個值的函數),但這很容易加入。 它允許我們使前面的範例具有反應性: ``` const count = state(0); const increment = () => count.set(count.get() + 1); const button = document.createElement('button'); effect(() => { button.textContent = count.get(); }); button.addEventListener('click', increment); document.body.appendChild(button); ``` > ☝ 使用您的開發人員工具在 [空白頁面](about:blank) 中嘗試上述兩個程式碼塊。 在大多數情況下,框架允許不同的時間安排,讓效果在渲染 DOM 之前、期間或之後執行。 ### 記憶化 Memoization 意味著緩存從狀態計算的值,它會從狀態衍伸的變化更新時更新。它基本上是一種回傳衍伸狀態的效果。 在重新執行元件功能的框架中,例如 [react](https://reactjs.org/) 和 [preact](https://preactjs.com/),這讓某些複雜計算不需要每次都重複計算。 對於其他框架,情況恰恰相反:它允許您選擇部分組件進行響應式更新,同時緩存之前的計算。 對於我們簡單的反應式系統,memo 看起來像這樣: ``` const memo = (fn) => { let memoized; effect(() => { if (memoized) { memoized.set(fn()); } else { memoized = state(fn()); } }); return memoized.get; }; ``` ### 模板化和渲染 現在我們有了純的、衍伸的和緩存形式的狀態,我們想把它展示給用戶。在我們的範例中,我們直接使用 DOM 來加入按鈕並更新其文本內容。 為了對開發人員更加友好,幾乎所有現代框架都支持一些特定領域的語言來編寫類似於程式碼中所需輸出的內容。儘管有不同的風格,比如 `.jsx`、`.vue` 或 `.svelte` 文件,但它們都歸結為用類似於 HTML 的程式碼表示 DOM,因此基本上 ``` <div>Hello, World</div> // in your JS // becomes in your HTML: <div>Hello, World</div> ``` 你可能會問“我要把狀態放在哪裡?”。很好的問題。在大多數情況下,`{}` 用於表示屬性和節點周圍的動態內容。 最常用的 JS 模板語言擴展無疑是 JSX。對於 [react](https://reactjs.org),它被編譯為純 JavaScript,其方式允許它建立 DOM 的虛擬表示,一種稱為虛擬文檔對像模型或簡稱 vDOM 的內部視圖狀態。 這樣設計的原因是:建立物件比存取 DOM 快得多,所以如果你能用當前的替換後者,你可以節省時間。但是,如果您在任何情況下都有大量 DOM 更改或建立無數物件而沒有更改,則此解決方案的優點就變成必須通過「記憶化」來規避的缺點。 ``` // original code <div>Hello, {name}</div> // transpiled to js createElement("div", null, "Hello, ", name); // executed js { "$$typeof": Symbol(react.element), "type": "div", "key": null, "ref": null, "props": { "children": "Hello, World" }, "_owner": null } // rendered vdom /* HTMLDivElement */<div>Hello, World</div> ``` 不過,JSX 不僅限於 react。例如,Solid 使用其轉譯器更徹底地更改程式碼: ``` // 1. original code <div>Hello, {name()}</div> // 2. transpiled to js const _tmpl$ = /*#__PURE__*/_$template(`<div>Hello, </div>`, 2); (() => { const _el$ = _tmpl$.cloneNode(true), _el$2 = _el$.firstChild; _$insert(_el$, name, null); return _el$; })(); // 3. executed js code /* HTMLDivElement */<div>Hello, World</div> ``` 雖然轉譯後的程式碼乍看可能令人望而生畏,但解釋這裡發生的事情卻相當簡單。首先,建立包含所有靜態部分的模板,然後複製它以建立其內容的新實體,並加入動態部分並連接以根據狀態更改進行更新。 Svelte 走得更遠,不僅可以轉換模板,還可以轉換狀態。 ``` // 1. original code <script> let name = 'World'; setTimeout(() => { name = 'you'; }, 1000); </script> <div>Hello, {name}</div> // 2. transpiled to js /* generated by Svelte v3.55.0 */ import { SvelteComponent, append, detach, element, init, insert, noop, safe_not_equal, set_data, text } from "svelte/internal"; function create_fragment(ctx) { let div; let t0; let t1; return { c() { div = element("div"); t0 = text("Hello, "); t1 = text(/*name*/ ctx[0]); }, m(target, anchor) { insert(target, div, anchor); append(div, t0); append(div, t1); }, p(ctx, [dirty]) { if (dirty & /*name*/ 1) set_data(t1, /*name*/ ctx[0]); }, i: noop, o: noop, d(detaching) { if (detaching) detach(div); } }; } function instance($$self, $$props, $$invalidate) { let name = 'World'; setTimeout( () => { $$invalidate(0, name = 'you'); }, 1000 ); return [name]; } class Component extends SvelteComponent { constructor(options) { super(); init(this, options, instance, create_fragment, safe_not_equal, {}); } } export default Component; // 3. executed JS code /* HTMLDivElement */<div>Hello, World</div> ``` 也有例外。例如,在 [Mithril.js](https://mithril.js.org/) 中,雖然可以使用 JSX,但我們鼓勵您編寫 JS: ``` // 1. original JS code const Hello = { name: 'World', oninit: () => setTimeout(() => { Hello.name = 'you'; m.redraw(); }, 1000), view: () => m('div', 'Hello, ' + Hello.name + '!') }; // 2. executed JS code /* HTMLDivElement */<div>Hello, World</div> ``` 雖然大多數人會發現開發人員缺乏經驗,但其他人更喜歡完全控制他們的程式碼。根據他們主要想解決的問題,缺少轉譯步驟甚至可能是有益的。 儘管很少有人這樣推薦,許多其他框架都允許在不進行轉譯的情況下使用。 ## “我現在應該學習什麼框架或庫?” 我有一些好訊息和一些壞訊息要告訴你。 壞訊息是:沒有萬靈丹。沒有哪個框架在每個方面都比其他框架好得多。他們每個人都有自己的優勢和妥協。 [React](https://reactjs.org/) 有它的鉤子規則,[Angular](https://angular.io/) 缺乏簡單的信號,[Vue](https://vuejs.org/)缺乏向後兼容性,[Svelte](https://svelte.dev/) 不能很好地擴展,[Solid.js](https://www.solidjs.com/) 禁止解構,[Mithril.js]( https://mithril.js.org/) 並不是真正的反應式,僅舉幾例。 好訊息是:沒有錯誤的選擇——至少,除非專案的要求真的很有限,無論是在 bundle 大小還是性能方面。每個框架都會完成它的工作。有些人可能需要配合團隊的設計決策,這可能會使您的速度變慢,但無論如何您都應該能夠獲得可行的結果。 話雖這麼說,沒有框架也可能是一個可行的選擇。許多專案都被過度使用 JavaScript 破壞了。其實帶有一些互動性的靜態頁面就可以完成這項工作。 現在您已經了解了這些框架和庫應用的概念,請選擇最適合您當前任務的概念。不要害怕在下一個專案中切換框架。沒有必要學習所有這些。 如果你嘗試一個新的框架,我發現最有幫助的事情之一就是跟它的社群有所連結,無論是在社群媒體、discord、github 還是其他地方。他們可以告訴您哪些方法適合他們的框架,這將幫助您更快地獲得更好的解決方案。 ## “拜託,你*總是*有個人喜好吧!” 如果你的主要目標是就業,我建議學習 [react](https://reactjs.org/)。如果您想要輕鬆的性能和控制體驗,請嘗試 [Solid.js](https://solidjs.com);你可能會在 Solid 的 [Discord](https://discord.com/invite/solidjs) 上見到我。 但請記住,所有其他選擇都同樣有效。你不應該因為我這麼說就選擇一個框架,而應該使用最適合你的框架。

軟體工程師都應該養成寫部落格的習慣

軟體工程師寫部落格,對於職業生涯很有幫助,有很多好處。這篇文章的作者簡單分享心得。 原文出處:https://dev.to/nasirovelchin/every-software-developer-should-write-a-blog-4622 --- 作為一名軟體工程師,我常常打算明天、下週甚至下個月,就要開始寫部落格。但幾年過去了,我還沒有寫過一篇文章。我沒有開始的原因是,我覺得,我不是專家、不是名人、也不擅長寫作,只是一個普通的軟體工程師。因此,為什麼我要花時間寫一篇文章,根本沒有人會讀。這總是阻止我開始寫。但最近,在我閱讀了幾篇軟體工程師的文章後,我改變了主意,決定開始寫。 有很多理由開始寫文章,而且,我認為每個軟體開發人員都應該擁有部落格。理由大致如下: **更快地學習並提高您的技術技能** 當我試圖解釋或教別人時,我自己也學得更快。我從大學的電腦科學課的小組作業專案中了解到這一點。我仍然記得我試圖向其他小組成員解釋和展示的一切。解釋會促使你更多地了解這個主題,這不僅對你的讀者有好處,對你自己也有好處。開設技術部落格與教學非常相似,因為在您的部落格中,您將向世界教授寫程式和電腦科學。 **推銷自己並開始你的職業生涯** 您的部落格將為您可能無法找到的各種網絡和商業機會打開大門。通過部落格,您可以得到很多機會成為自由工作者和接案者。舉個真實的例子,我的一個朋友,他開始學習 Java 程式語言,並在他的部落格上分享他的進度,有招聘人員向他發送了他從未申請過的工作機會,他們發現他在網上分享的文章。而且,他甚至在完成 Java 課程之前就開始了他的軟體工程師生涯。 **記錄您的回饋進度** 您每周有多少次找到完美的 StackOverflow 文章來解決您的問題並節省您數小時的頭撞牆?有多少次您花費數小時解決問題,但沒有其他人從您的解決方案中獲益? 即使你不時地、每週寫一篇文章,你也可以展示你面臨什麼樣的挑戰,你是如何解決它們的,你使用了哪些方法和技術,你避免了哪些。一年後,當您回顧時,您會發現您的文件對別人幫助很大,這些有用的見解,以及解決問題的方法,都很有幫助。 此外,與經驗豐富的軟體工程師相比,寫程式經驗很少的人可以更好地展示他們如何在某些主題上掙扎,陷阱和不明顯的部分在哪裡。因此,閱讀您貼文的人不會陷入您所寫內容的陷阱。 **學習如何交流和表達你的想法** 信不信由你,但您的軟體職業生涯在很大程度上取決於您溝通和表達想法的能力。即使你是一個優秀的軟體工程師,如果沒有良好的溝通和展示自己的能力,你的軟體生涯也不會大放異彩,而且會受到限制。此外,許多軟體工程師都說寫文章也能幫助他們寫出更好的程式碼。 **消除你的壓力** 脫離日常的寫程式生活,給自己一些自由,隨心所欲地寫一些你想分享的東西,分享你自己的觀點,寫下來並發表。這些都會讓你感到放鬆。 總的來說,作為軟體開發人員,寫部落格是提升個人風格的絕佳方式。寫部落格可以促進您所做或計劃做的任何事情。它打開了您意想不到的大門。值得一試,看看會發生什麼好事吧。

JavaScript 系列四:第2課 ── vanilla-lazyload 套件

## 課程目標 認識並且能使用 vanilla-lazyload 套件 ## 課程內容 這次的套件是 https://github.com/verlok/vanilla-lazyload 文件與 demo 在 https://www.andreaverlicchi.eu/vanilla-lazyload/ 當畫面上圖片很多的時候,頁面載入會很慢 lazy load 是所謂的延遲載入技術 也就是不會在一開始就通通載入,而是使用者在網頁上下滑動的時候,圖片元素出現在畫面中的時候,才動態去載入圖片 ``` <img alt="A lazy image" class="lazy" data-src="lazy.jpg" /> ``` 使用了 img 元素,class 設為 lazy,但不設定 src 屬性(因為設了瀏覽器就會直接去抓圖片),而是使用 data attribute 來另外給一個 data-src 屬性 這是一種常用的 API 設計,套件會自己去找出 `.lazy` 的元素,然後去找元素的 `data-src` 屬性,接著載入圖片 要啟用套件,需要以下 javascript ``` var lazyLoadInstance = new LazyLoad({ // Your custom settings go here }); ``` 這樣就完成了,很簡單吧? 這邊用到了 javascript 的 OOP 物件導向語法,new 出一個新物件。可以先不管 OOP 細節,照做就好,反正就是創造一個物件然後執行一些函式 創造的同時,會傳一個用大括號 `{}` 包起來的物件進去,當作套件的設定值。這邊因為都用預設的設定,所以傳空物件進去就好 `//` 開頭的是註解,是給開發者自己看的提醒文字,沒有實際功能 比較進階的用法會類似這樣 ``` var lazyLazy = new LazyLoad({ elements_selector: ".horizContainer", callback_enter: initOneLazyLoad, unobserve_entered: true // Stop observing .horizContainer(s) after they entered }); ``` 這個例子傳了有三個屬性的物件進去 各個設定與功能效果,可以再查文件,反正會用 `{}` 包起來的物件去進行參數設定就對了 這種「傳一個物件當參數,來進行套件的功能設定」的設計,也是 javascript 套件的常用 API 設計 關於物件這種資料型態,之後的課程會再進一步學習 ## 課後作業 請使用 https://jsfiddle.net 接著上網尋找 10 張漂亮圖片。參考圖庫:https://unsplash.com/ 假設正在開發一個包含大量高畫質、大圖片的企業形象網站,包含這 10 張圖片,上往下依序排列 一次載入,實在太慢了,尤其是手機用戶、舊電腦的用戶、或者網速很慢的用戶 請替這些圖片加上 lazy loading 功能 做出以上功能,你就完成這次的課程目標了!

初次轉職寫程式:作品集有用嗎?要做什麼作品?面試官會看嗎?

很多朋友轉職寫程式,在補習班或者線上課程,告一段落之後,開始找工作之前,會整理作品集 關於作品集,簡單給大家一些建議 ## 作品集有用嗎? 公司在徵人的時候,其實來應徵的人五花八門 滿多人看起來,根本不會寫程式,連最基本的小網頁或者小程式都寫不出來 連基本技能都沒有準備好,感覺是到處碰碰運氣、履歷亂誇大就到處丟。公司面試時,最怕遇到這種狀況 作品集,至少代表,你寫得出基本東西。很多人根本寫都不會寫,就去應徵了,作品集至少可以讓公司避免踩雷 話說回來,如果你的作品集,只是補習班的幾個分組專案,糊裡糊塗地完成了,就跟在學校敷衍交報告一樣,你對細節其實不了解,那這種作品集,當然幫助不大,對你的信心也沒有多少幫助 ## 要做什麼作品? 所以該做什麼作品呢? 最好做一些你真的需要的「應用程式」,寫起來才有動力、才好玩,內容也才扎實 簡單舉例,如果你在受訓的過程是這些: ### 前端工程師 做個待辦事項清單工具吧!按照自己的喜好設計,做完之後找地方上線 在找工作的這幾個星期,實際拿這個工具來做紀錄,投履歷時、面試時,很自然可以分享你的心得跟小熱情 對面試官來說,看到面試者有即戰力(即便是有一點點)、對自己的程式有熱情(即便只有一點點),都會加分不少 請參考 https://todomvc.com/ 這是各種前端工具寫的 todo list 應用程式,你還可以比較自己的程式碼,與社群所寫的差異 ### 後端工程師 我鼓勵後端的入行者,寫一個「個人專屬部落格」 這個部落格要有以下功能 - 首頁列出文章清單 - 能簡單單篇文章瀏覽 - 自己可以登入後台 - 在後台可以新增、編輯、刪除文章 有餘力的話,還可以加個留言功能 這種部落格,會實際做完資料的 CRUD 基本功能,還有簡易的註冊、登入、驗證 找地方把這個部落格上線,或者買網址、租主機,實際上線 在找工作的這幾個星期,實際拿這個部落格,來寫文章、技術筆記、經驗分享 面試官絕對會覺得你是積極的人、有備而來 (錄取之後就停止寫網誌的習慣也沒關係) ### 全端工程師 我鼓勵全端的入行者,寫一個「個人行事曆工具」並且是 single page application (SPA) 這個行事曆要有以下功能 - 有一個行事曆頁面 - 有個按鈕可以新增活動 - 點擊行事曆內的活動,可以編輯、刪除 - 有一個清單業面,可以用條列式顯示全部活動 - 全程使用 ajax,不能整個刷新頁面 這種行事曆,會實際做完資料的 CRUD 基本功能,還有基本的 SPA routing 在找工作的這幾個星期,實際拿這個行事曆,紀錄生活是像、活動 面試時分享,面試官絕對會覺得你是積極的人、是個即戰力 ## 結論 除此之外,做個人履歷表的網頁也不錯 可以搜尋 'Portfolio website examples' 看看各種漂亮設計 實際把履歷做成網頁,也可稍微證明自己能力 在工程師生涯,不斷地做自己的 side project 是一個有趣、進步的好習慣 甚至有一天,你做的某個 side project 大受歡迎,還可能變成一個獨立的小產品呢 有空可以逛逛 https://www.producthunt.com/ 看看大家都在做什麼 side project 或許模仿其中一些,做個簡易版本,你會學到很多的~! --- 您有沒有什麼好的點子、推薦的 side project 點子給初心者呢? 歡迎留言分享!

15 年開發經驗分享:從新手到中階工程師的心得

我的自學開發之旅始於大約 15 年前,當時我還是個小孩。它慢慢從熱情變成了我的工作。 我成為了一名普通的開發人員、自由職業者。有時我因為興奮每天在電腦前瘋狂地呆上 20 個小時,有時我因為過度勞累和壓力而筋疲力盡。 這些經驗,讓我想分享幾點心得。 原文出處:https://dev.to/entrptaher/reflections-on-my-15-year-journey-from-novice-to-intermediate-developer-pje --- ## 您如何定義初級軟體工程師? 有幾個跡象表明軟體工程師是初學者。其中包括: - 不熟悉核心編程概念和最佳實踐。 - 很難編寫乾淨、結構良好且高效的程式碼。 - 在沒有完全理解其工作原理的情況下,依賴從線上資源複製和貼上程式碼。 - 難以排除和除錯程式碼中的錯誤和問題。 - 對編程語言和工具的了解有限。 - 缺乏在實際專案或團隊環境中工作的經驗。 這些是軟體工程師可能是初學者的一些潛在跡象。重點是,初學者不一定是壞事——每個人都必須從某個地方開始,每個人都有不同程度的經驗和專業知識。 但是,如果你在軟體工程師身上發現這些跡象,則可能表示他們仍處於學習的早期階段,可能需要更多的指導和支持。 ##初學者應該知道的事情 以下是我想給剛開始學習如何編碼的人的一些提示: 1. **首先確保每個專案或任務都有可以實現的明確目標。** 這可以幫助您集中精力工作,避免被不重要的程式碼分心。 使用 Notion、ClickUp、Github Issue 等工具。 2. **找出最重要的任務和功能**並首先處理它們。 這可以幫助您在專案上取得進展並按時完成任務,同時仍然給您時間來嘗試新想法。 3. **向更有經驗的軟體工程師尋求回饋和幫助**。 這可以幫助您找出可能在不必要或無用的程式碼上花費太多時間的地方,並教您如何更有效地工作。 檢查 Github 問題、Stackoverflow、Dev.to、Facebook 群組。 4. 使用工具和方法更好地**追蹤您的時間和任務。** 這可以通過使用專案管理軟體、使用敏捷開發方法或遵循其他高效編程的最佳實踐來完成。 使用 DeskTime、TimeDoctor 等工具。 5. **經常休息**,不要不停地長時間工作。 這可以幫助您避免在工作中精疲力盡,並讓您的注意力集中在手頭的任務上。 番茄鐘是一個很好的方法。 6. **除非需要,否則不要重構**。 重寫或重構程式碼是提高程式碼易讀性、修復難易度或執行速度的好方法。但這可能會花費很多時間,而且並不是永遠必要的。 在開始一個大的重構專案之前,你應該仔細考慮它是否會帶來真正的好處。你不應該為了改變而改變。 7. **與其他軟體工程師一起工作**並與他們交談。 作為初學者,您可以從比您了解更多或經驗更多的其他軟體工程師那裡學到很多東西。 通過一起處理專案、共享想法和程式碼以及互相提供回饋和幫助,您可以更快地學習和成長為一名軟體工程師。 8. **使用版本控制**來管理你的程式碼。 版本控制軟件,如 Git,可讓您跟踪程式碼的更改,與其他人一起工作,並在需要時恢復到舊版本。 這可以幫助您組織、加快並確保您的工作安全。它還可以幫助您避免丟失重要程式碼或犯錯誤。 9. **將你的工作組合成一個作品集**,以展示給可能的雇主看。 當您剛開始作為一名軟體工程師時,可能很難找到您的第一份工作或專案。 建立您的作品集是脫穎而出並向潛在雇主或客戶炫耀您的技能的一種方式。 這可以包括已完成的專案、您的程式碼範例或展示您的技能和潛力的其他工作示例。 10. **不斷學習**關於編程的新事物並跟上最新的變化(與你的目標相關)。 編程是一個總是在變化的領域,所以總是有新的語言、框架、工具和方法需要學習。作為一名軟體工程師,您可以不斷進步,並通過保持好奇心和與時俱進,在競爭越來越激烈的領域保持領先地位。 11. **編寫乾淨易讀的程式碼。** 作為初學者軟體工程師,您可能只想專注於讓您的程式碼正常工作,而沒有考慮閱讀或修復程式碼的難易程度。但是編寫乾淨且易於閱讀的程式碼很重要,原因不止一個。 它可以使您的程式碼更易於理解和更改,從長遠來看可以節省您的時間和精力。它還可以使您的程式碼更易於查找和使用,這在與其他軟體工程師合作或將您的程式碼放入更大的系統時會很有幫助。 12. **寫很多測試。** 測試是開發過程的重要組成部分,它可以幫助您發現錯誤並修復它們。 通過編寫和執行測試,您可以確保您的程式碼按您希望的方式工作,並且您可以在問題變得更糟之前找到並修復任何問題。 這可以節省您的時間、精力和挫折感,並幫助您為用戶或客戶提供品質更高的程式碼。 13. 照顧好**您的身心。** 編程對您的思想和身體來說都很難。可能需要長時間集中註意力、解決問題以及與他人合作,這對您的身體和思想來說都是艱難的。 如果您想避免倦怠並保持良好的工作狀態,照顧好自己很重要。充足的睡眠、規律的鍛煉、良好的飲食和工作中的休息都是做到這一點的方法。 照顧好你的健康會讓你保持專注、充滿活力和積極性,讓你成為一個更好的軟體工程師。 14. **了解如何除錯**您的程式碼。 除錯是開發的一個重要部分,每個軟體工程師都需要知道如何去做。 通過學習查找和修復程式碼中的錯誤和錯誤,您可以使其更可靠、更快速,並且您不會將時間浪費在無法按您希望的方式工作的程式碼上。 您可以使用許多工具和方法來修復程式碼中的錯誤。如果你想成為更好的軟體工程師,你應該學習和練習這些技能。 15. **遵守編碼規則和最佳實踐**。 如果您剛開始成為一名軟體工程師,您可能不知道在您的語言或領域中編寫程式碼的規則和最佳實踐。 學習並遵循這些標準和最佳實踐非常重要,因為它們可以幫助您編寫更易於閱讀、維護和使用的程式碼。 它們還可以幫助您避免常見的錯誤和陷阱,並且可以使其他軟體工程師更容易理解和使用您的程式碼。 通過遵循編碼標準和最佳實踐,您可以提高程式碼質量並使其對您和其他人更有用。 16. **承擔困難的專案和問題**。 如果您剛開始成為一名軟體工程師,您可能會傾向於只從事小型或簡單的專案,這樣您就不會太忙或太沮喪。 但重要的是要推動自己並承擔更大、更艱鉅的專案,因為這是你作為一名軟體工程師學到最多和成長的方式。 通過解決難題和克服障礙,您可以提高自己的技能、獲得信心並建立一個您可以引以為豪的工作體系。 17. **積極主動,主動出擊。** 不要只是等待別人告訴你該怎麼做。尋找學習和成長的機會,迎接新的挑戰。 18. **Google 一切。** 了解如何使用 google、觀看視頻和教程、存取 stackoverflow 和 reddit。但切勿在不了解其工作原理的情況下複製程式碼塊。 另外,在詢問其他高級開發人員之前,給自己設定一個谷歌搜尋的時間限制。 ##初學者應該避免的事情 以下是新軟體工程師不應該做的一些事情: 1. **忽略編程領域的最新趨勢**或時尚。 編程世界瞬息萬變,總有新的語言、框架、工具和技術需要學習。 然而,並非所有這些發展都具有同等價值或相關性,追逐每一個新趨勢或時尚可能會浪費時間和精力。 相反,專注於編程的基本概念和原則,並學習與您的目標和專案最相關和最有用的工具和技術。 2. **忽略成為完美**軟體工程師的壓力。 作為初學者,很自然地會感到要做到完美、避免犯錯或達到更有經驗的軟體工程師的標準的壓力。 然而,完美是可望不可及的,更重要的是專注於學習和提高。 樂於犯錯,從中吸取教訓,並作為一名軟體工程師繼續成長和發展。 3. **忽略將自己與他人比較**的誘惑。 作為初學者,很容易將自己與其他可能比您有更多經驗、更多技能或更成功的軟體工程師進行比較。 然而,比較很少有用,而且可能會損害您的信心和動力。 相反,專注於你自己的目標和進步,並慶祝你自己的成就,無論它們看起來多麼微不足道。 4. **忽略那些告訴你你不夠好或者你做不到的聲音**。 作為一名初級軟體工程師,你可能會遇到很多聲音告訴你你不夠好,你沒有合適的技能或知識,或者你應該放棄。 這些聲音可以來自很多方面,包括你自己的疑惑,別人的期望,或者領域的挑戰。忽略這些聲音並相信自己和自己的能力很重要。 你有潛力成為一名成功的熟練軟體工程師,如果你願意付出努力和奉獻,你就可以實現你的目標。 5. **忽略讓你的解決方案過於復雜化的誘惑**。 作為初學者,您可能會試圖使您的解決方案過於復雜,加入不必要的功能或增強功能,或者試圖用您的程式碼打動別人。 然而,簡單直接的解決方案往往是最好的,而且它們比複雜精密的解決方案更有效、更易於維護和有效。 通過關注核心需求並避免不必要的複雜化,您可以編寫對自己和他人更有價值和有用的程式碼。 6. **忽略對失敗的恐懼。** 作為初學者,您可能害怕失敗、犯錯誤或達不到他人的期望。 這種恐懼會讓你退縮,阻止你冒險、探索新想法或挑戰自己。重要的是要忽略這種恐懼,並將失敗視為學習和成長的機會。 通過從錯誤和失敗中吸取教訓,您可以成為更好的軟體工程師,並且可以培養在該領域取得成功所必需的韌性和毅力。 --- 作為初學者,很難採納建議,即使建議的人是出於善意。但如果你能堅持下去,按照有經驗的人告訴你的去做,你就會變得比你想像的更快。所以不要害怕邁出這一步並嘗試新事物。

給軟體工程師的各類好用工具清單

向您介紹這個開發人員工具列表。它是一個開源專案,由社群整理。 讓我們開始吧! 🚀 原文出處:https://dev.to/dostonnabotov/ultimate-tools-for-developers-2aj2 --- ## 程式碼編輯器和 IDE 💻 - [Visual Studio Code](https://code.visualstudio.com/) 作為免費的開源程式碼編輯器,Visual Studio Code 是開發人員的絕佳工具。它帶有許多功能和外掛,使其成為開發人員的絕佳選擇。 - [CodeSandbox](https://codesandbox.io/) 簡單來說,CodeSandbox 就是 Visual Studio Code 的在線版本。 - [Dev - Visual Studio Code](https://github.dev/) github.dev 基於網絡的編輯器是一種輕量級的編輯體驗,完全在您的瀏覽器中執行。 有兩種方法可以打開基於 Web 的編輯器 1. 在任何存儲庫或拉取請求上按 `.` 鍵 2. 將 URL 中的 .com 替換為 .dev。例如。 `https://github.dev/username/repo` - [CodePen](http://codepen.io/) CodePen 是網絡前端的遊樂場。這是一個試驗、測試和展示您的前端工作的地方。此外,您還可以從其他開發人員那裡找到許多靈感。 - [Replit](https://repl.it/) Replit 是一個簡單、強大且協作的在線 IDE。這是編碼、協作和託管專案的好地方。 - [StackBlitz](https://stackblitz.com/) 面向前端和全棧開發人員的 Web IDE。 - [TypeScript Playground](https://www.typescriptlang.org/play/) 想玩玩看 TypeScript 嗎? TypeScript Playground 是一個適合你的地方。 ## 圖片 🖼 - [Unsplash](https://unsplash.com/) 為您的下一個專案輕鬆找到精美、高質量的照片。所有照片均可免費用於商業和個人用途。 - [Pexels](https://www.pexels.com/) Pexels 是免費庫存照片的重要來源。所有照片均可免費用於商業和個人用途。 - [Carbon](https://carbon.now.sh/) Carbon 是一個很棒的平台,可以建立和共享程式碼的精美圖像,允許您使用語法突出顯示、主題、字體等自定義圖像。 ## 顏色 🎨 - [Color Space](https://mycolor.space/) 再也不會浪費時間尋找完美的調色板!只需輸入顏色!並生成漂亮的調色板 - [Coolors](https://coolors.co/) 建立完美的調色板或從數千種美麗的配色方案中汲取靈感。 - [Color Wheel](https://www.canva.com/colors/color-wheel/) 想知道什麼顏色搭配起來好看嗎? Canva 的色輪讓色彩組合變得簡單。 ## 排版 📝 - [Google Fonts](https://fonts.google.com/) Google Fonts 是一個包含免費授權字體系列的庫。只需選擇您想要的字體,將它們下載到您的計算機或使用提供的 CSS 或 HTML 鏈接將它們嵌入您的網頁。 - [Fontsource](https://fontsource.org/) 如果您不想從 CDN 獲取字體,則可以使用整齊打包的 NPM 包中的自託管開源字體。 - [Nerd Fonts](https://www.nerdfonts.com/) Nerd Fonts 使用大量字形(圖標)修補針對開發人員的字體。 ## 設計 🎨 - [Figma](https://www.figma.com/) 一個免費的線上協作界面設計工具和原型製作工具。 - [Pinterest](https://www.pinterest.com/) Pinterest 是一種視覺發現工具,可用於為您的所有專案和興趣尋找創意。 ## 文檔 📚 - [MDN 網絡文檔](https://developer.mozilla.org/en-US/) 學習Web開發的最佳平台。每當您對 HTML、CSS、JavaScript 或任何其他網絡技術有疑問時,請務必先查看 MDN。 - [W3Schools](https://www.w3schools.com/) 幾乎所有您能想到的程式語言的參考。 - [CSS 技巧](https://css-tricks.com/) 提供使用 CSS(層疊樣式表)的提示、技巧和技術的最佳平台之一。 ## 工具 🛠 等一會兒!工具中的工具?是的,你沒有聽錯。這裡有一些工具可以幫助您找到更多工具。 😃 - [Stack Overflow](https://stackoverflow.com/) Stack Overflow 是一個面向專業和狂熱工程師的問答網站。這是提出問題和獲得答案的好地方。 - [Micro Digital Tools](https://mdigi.tools/) 一組對開發人員有用的工具。 - [Small Dev Tools](https://smalldev.tools/) 一組對開發人員有用的工具。 - [Can I Use](https://caniuse.com/) Can I Use 提供了最新的瀏覽器支持表,以支持桌面和移動 Web 瀏覽器上的前端 Web 技術。 - [網站圖標生成器](https://favicon.io/) 您是否曾經為了替自己的網站建立網站圖標而苦惱?不同的尺寸,不同的格式,不同的平台。 從文本、圖像或從數百個表情符號中選擇快速生成您的網站圖標。 - [Font Awesome](https://fontawesome.com/) 免費和高級圖標庫。 - [OverAPI.com](https://overapi.com/) 以有組織的格式查找大量不同技術的備忘單。 - [Transform](https://transform.tools/) 多語言網絡轉換器。輕鬆將 HTML 轉換為 Pug、將 TypeScript 轉換為 JavaScript、將 Markdown 轉換為 HTML 等等... - [Frontend Tools](https://murtazajoo.github.io/tools/) 一個網站,您可以在其中找到具有更好用戶體驗的所有工具。 - [GitProtect](https://gitprotect.io/) 適用於所有 GitHub、GitLab、Bitbucket 和 Jira 資料的 DevOps 備份和災難恢復軟體。 - [Linear](https://linear.app/) 在團隊中組織問題和拉取請求的好工具。 ## 結論 🎉 希望您覺得這個列表有用。

寫文件基本技巧:如何替專案寫一份優質 README 文件

為您的開源專案提供良好的文檔是一項重要(且經常被忽視)的功能,可以促進採用並展示您的軟體的全部潛力。 不幸的是,文檔的增長速度通常比程式碼慢得多,主要是因為一些看起來相當簡單的實現,會產生大量可能的用例和變化。不可能涵蓋所有可能的場景,這就是為什麼技術作家的首要工作是確定範圍和確定優先級。關注基本知識非常重要,必須首先記錄以支持最常見的用例。 在這篇文章,我將分享一些技巧,為您的專案打造一個好的 README 文件。 原文出處:https://dev.to/erikaheidi/documentation-101-creating-a-good-readme-for-your-software-project-cf8 ## README 檔案 專案的 README 文件通常是用戶與您的專案的第一次接觸,因為這是他們在訪問您的專案時首先看到的內容。這就是為什麼優先考慮將好的 README 作為專案文檔的起點很重要。 自然地,不同的專案在 README 中有不同的東西要展示,但這些技巧應該作為大多數軟體專案的良好起點。 ## 1. 少即是多 你可能想把所有東西都放在你的 README 中,比如如何安裝和使用項目,如何部署,如何調試......更詳細地涵蓋這些主題的更完整文檔的鏈接。 當您開始時,只有一個 README 就可以了。很長的 README 沒有吸引力,因為沒有目錄或菜單可供導航,因此更難找到訊息,這最終不利於良好的用戶體驗。鏈接到相關資源的較短的自述文件使專案看起來更有條理且不那麼複雜。 如果我不想為這個專案創建一個專門的文檔網站怎麼辦?那麼,在這種情況下,您可以考慮在根目錄中創建一個 `docs` 文件夾,您可以在其中保存額外的 markdown 文檔,這些文檔可以直接從您的代碼託管平台(假設是 GitHub)瀏覽。 ## 2. 將 README 拆分為其他文檔 對於存儲庫中的文檔,您可以在應用程式的根目錄中創建一個“/docs”目錄,並使用“/docs/README.md”文件作為文檔的入口點或索引。 此文件夾的內容大概就像: - installation.md - 詳細顯示如何安裝項目的文檔。 - usage.md - 項目使用情況和主要命令的更詳細視圖。 - advanced.md - 包含一些進階使用選項和用例的文檔。 這些只是一些可以作為起點的想法。如果您覺得需要創建一個包含子文件夾的更複雜的結構,您應該認真考慮為您的項目創建一個專門的文檔網站(我們將在本系列的後續文章中介紹)。 ## 3. README 文件要點 以下是您的 README 文件中絕對應該包含的一些內容: - 項目的大致概述,包括編寫它的語言、它的作用、它為什麼有用; - 安裝要求; - 安裝文檔的鏈接; - 使用概述,讓用戶簡要了解如何執行它; - 故障排除或測試提示(可以是指向單獨文檔的鏈接); - 連接到其他資源以了解更多訊息。 理想情況下,這些應該是簡短的說明,可在必要時鏈接到更全面的文檔。 根據項目的規模和目標,您應該考慮將其他內容放在那裡: - 指向 CONTRIBUTING.md 文檔的鏈接,其中包含有關用戶如何為您的專案做出貢獻的詳細訊息 - 指向包含項目行為準則的 CODE_OF_CONDUCT.md 文檔的鏈接。 如果您的項目託管在 GitHub 上,這些將顯著顯示在右側欄的項目頁面中,就在“關於”部分的正下方。 ### 示例結構 以下是 markdown 的一般結構,您可以將其用作構建專案自述文件的基礎: ``` # Project Name A paragraph containing a high-level description of the project, main features and remarks. ## Requirements Here you should give a general idea of what a user will need in order to use your library or application. List requirements and then link to another resource with detailed installation or setup instructions. - Requirement one - Another requirement Check the [installation notes]() for more details on how to install the project. ## Usage Include here a few examples of commands you can run and what they do. Finally link out to a resource to learn more (next paragraph). For more details, check the [getting started guide](). ## Useful Resources Include here any other links that are relevant for the project, such as more docs, tutorials, and demos. ``` ## 4. 使用徽章 您可以使用徽章通過自動從專案中提取的快速訊息來豐富您的 README,例如最新構建的狀態、最新的穩定版本、專案許可證等。 有不同的服務可以為開源專案提供徽章。正如@mohsin 在這篇文章的評論部分所指出的,您可以直接從 GitHub Actions 中提取徽章,方法是轉到您的工作流程頁面,單擊右上角顯示的三個點,然後從中選擇“創建狀態徽章”菜單: ![屏幕截圖顯示在哪裡可以找到菜單以從 github 操作創建狀態徽章](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bpb6g6xofhwm8vctwcem.png) 這將向您顯示一個帶有降價代碼的對話框,您可以將其複製並貼上到您的 README 文件中。 另一個不錯的選擇是使用網站 [Shields.io](https://shields.io/),它提供了幾種不同的徽章,您可以在您的開源項目中免費使用。 例如,這是顯示最新版本 [yamldocs](https://github.com/erikaheidi/yamldocs) 的圖像 URL: ``` https://img.shields.io/github/v/release/erikaheidi/yamldocs?sort=semver&style=for-the-badge ``` 這會生成以下徽章,顯示最新版本: ![yamldocs 的最新穩定版本](https://img.shields.io/github/v/release/erikaheidi/yamldocs?sort=semver&style=for-the-badge) 這是帶有多個徽章的 README 示例: ![顯示來自 yamldocs 項目自述文件的徽章](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5frlxoex4fyke8ra1avf.png) ## 結論 文檔是任何軟體專案的重要組成部分,應該從一開始就認真對待。最好的開始方式是創建一個好的自述文件,向用戶顯示基本信息,而不是用他們可能不需要的內容來淹沒他們,以便開始使用您的專案。

2023 前端框架比較:Svelte vs React,該學哪一個呢?

在 Web 開發世界中,有時感覺就像每天都有新的前端框架問世!大多數來去匆匆,但有一件事是肯定的:Svelte 將繼續存在。 不過,這並不意味著您應該放下一切並在今天學習!追逐最新潮流會讓您分心和不知所措。 這篇文章將一勞永逸地回答:**我應該學習 React 還是 Svelte?**。 您將看到一些程式碼範例,這些範例解釋了為什麼 React 開發人員會為 Svelte 瘋狂,但我們也必須實際一點。 React 已經存在了很長時間。有更多的套件、支援、職缺。 Svelte 還能取代 React 嗎?讓我們找出答案! - 原文出處:https://dev.to/mikehtmlallthethings/svelte-vs-react-which-framework-to-learn-in-2023-50gf --- * 📍 什麼是 React? * 📍 什麼是 Svelte? * 📍 React 和 Svelte 的 5 個區別 * Svelte 的捆綁包尺寸更小 * Svelte 更容易學習 * Svelte 使用純 HTML、CSS 和 JavaScript 進行編譯 * React 有更多的套件 * React 有 React Native * 📍 React 是庫還是框架? * 📍逐行比較 React 和 Svelte 專案 * 📍 Svelte 比 React 快嗎? * 📍 何時從 React 切換到 Svelte * 📍 結論 ### **What is React?** 讓我們從 React 開始。 React 是一個漸進式 JavaScript 前端框架(或函式庫,具體取決於您詢問的對象),可幫助您構建複雜的 Web UI。 它由 Facebook(現為 Meta)於 2013 年創建,能夠很快在前端 Web 開發領域站穩腳跟。 React 的核心是狀態和渲染狀態,這意味著要使用它,您必須添加其他庫來處理客戶端功能和路由。 ### **What is Svelte?** Svelte 也是一個前端 JavaScript 框架,但採用了更加一體化的方法。 Svelte 具有內建的狀態管理、路由和客戶端 (DOM) 功能。 ![](https://scrimba.com/articles/content/images/size/w1600/2022/12/React-vs-Svelte-functionalities.png) React 需要第三方庫和工具,如 Redux、React Router、JSX,而 Svelte 內建了很多這樣的功能。它不太靈活,但更方便和一致。 它採用更幕後(魔術)風格的方法,它直譯非常基本的 JavaScript 程式碼並為您處理 UI 和狀態管理: ``` <script> let count = 0; function handleClick() { count += 1; } </script> <button on:click={handleClick}> Clicked {count} {count === 1 ? 'time' : 'times'} </button> ``` Svelte 由紐約時報的開發人員 Rich Harris 於 2016 年創建,用於以高效的方式處理複雜的圖表和圖形。它從那裡成長為 React 和 Vue 之類的備受喜愛的競爭對手。 ### **React 和 Svelte 之間的 5 個區別** ### **1。 Svelte 的構建包大小要小得多** 我們在下面構建的相同(功能)應用程序。部署包大小在 React 是 41.2 kB,在 Svelte 是 2.1 kB。這幾乎減少了 **20x** 🤯 為了獲得這些數字,我構建了一個在 Svelte 和 React 中具有相同功能的應用程序。我們將在 React 與 Svelte 代碼分解部分深入研究這些應用程序。 ![](https://scrimba.com/articles/content/images/size/w1600/2022/12/React-vs-Svelte-bundle-size-2.png) 我用 React 和 Svelte 構建了一個相同的應用程序。看看 Svelte 包小了多少! ### **2。 Svelte 更容易學習,因為它的語法簡單** Svelte 採用更幕後的魔術方法,允許您編寫非常少量的樣板或語法糖來完成複雜的綁定。模板語法只是帶有一些額外內容的 HTML,這與 JSX(React 等價物)有很大不同並且更容易學習。 React 變數宣告: ![](https://scrimba.com/articles/content/images/size/w1600/2022/12/React-_-React-vs-svelte_-reactive-variable-declaration.png) Svelte 變數宣告: ![](https://scrimba.com/articles/content/images/size/w1600/2022/12/Svelte-_-React-vs-svelte_-reactive-variable-declaration.png) Svelte 看起來像純 JavaScript,但它具有與 React 完全相同的功能。更新 Svelte 變數將自動更新它所在的 UI 元素。 ### **3。 Svelte 符合純 HTML、CSS 和 JavaScript** Svelte 將您編寫的程式碼編譯成基本的 HTML、CSS 和 JavaScript。它不需要像 React 那樣與你的代碼捆綁在一起! React.js 需要存在於一個 bundle 中以完成所有正確的虛擬 DOM 比較和創建,Svelte 不使用虛擬 DOM 來處理 UI。相反,它選擇了基本的 JavaScript 元素創建函數,例如 document.createElement。 ### **4。 React 擁有更多為它構建的庫和包** React 已經存在了 3 年多,也是目前 JavaScript 框架事實上的王者👑。正因為如此,它擁有大量用戶和公司創建的軟件包。 用戶創建的包通常只是為了使路由和狀態管理更容易,或者添加滑塊、燈箱等。這些並不重要,因為 Svelte 具有可靠的選項,並且兼容/適應大多數 JavaScript 套件。 有點困難的是,要跟任何其他框架之前創建的 React 套件整合時不容易。我在 Solana 和以太坊上從事 Web3 專案時經常遇到這個問題。 ### **5。 React 有 React Native** React Native 是使用率最高和受支持最多的跨平台框架之一。它提供了使用 React 創建 iOS 和 Android 應用程式的能力。全部來自同一個代碼庫。由於其成熟度,它擁有大量的庫、支援和學習資源。 儘管有 Svelte 的替代方案,例如稱為 Svelte-native 的 NativeScript 改編版,但它們不具有與 React-native 相同的可靠性和功能。 ### **React 是函示庫還是框架?** 儘管 React 通常被稱為框架,但可以說,由於其範圍,它更像是一個函式庫。它專門負責管理 UI 的狀態並使其與應用程式中的資料狀態保持同步。 因此,它需要第 3 方函式庫來處理應用程式路由 (React Router)、UI 創建 (JSX) 和元件之間的狀態管理 (Redux)。 另一方面,Svelte 內建了上述所有功能,因此更像是一個完整的 UI 管理解決方案。 你可以看到大多數人都同意這是一個函式庫,但仍有一些爭論👇 https://twitter.com/htmleverything/status/1597574223148765185 ### **逐行比較 React 和 Svelte 專案** 比較兩種 Web 技術的最佳方法是深入研究並使用它們進行構建。構建完全相同的應用程序有助於了解每個庫/框架如何處理不同的功能。 讓我們看看: * 條件渲染 * 模板循環 * 更新狀態 * 事件掛鉤 ### **我們在建造什麼?** 編碼是一項口渴的工作,因此我們將構建一個簡單的網絡應用程序,允許用戶跟踪他們全天喝了多少杯水(或🍺)。 額外的好處是顯示每杯喝醉的歷史和時間。 我們將保持 UI 簡單,以更多地關注底層框架。 (見下面的用戶界面) https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark ### **React** 為了分解代碼,首先讓我們深入了解一些 React 概念和術語👇 React 有幾種類型的語法你需要學習。鉤子、狀態和模板 (JSX) 是主要的。 鉤子 - 允許您進入應用程序的生命週期 State - 允許您根據數據的變化更新 UI 元素。它將“狀態”(或更簡單的變量)更改與 UI 更新聯繫起來 模板 - 允許您直接在 HTML 中使用變量和 JavaScript React 組件的樣式通常由單獨的 .css(或 .scss)文件處理。 ### **React 代碼分解** https://codesandbox.io/embed/react-water-example-scrimba-ny5q0m?fontsize=14&hidenavigation=1&theme=dark&view=editor 變數是使用 useState 掛鉤設置的,它允許更新變量並讓 UI 動態呈現這些更新。 `useEffect` 用於在加載應用程序時設置今天的日期。 JSX 模板使用基本的“{}”符號以及 HTML 中的標準 JavaScript 函數,允許顯示變量和循環數組(使用“.map”)。 ### **Svelte** Svelte 採用不同的方法,採用更“幕後魔術”的風格。邏輯看起來很像純 JavaScript。在後台,代碼做的事情幾乎與 React 代碼做的一樣。 Svelte 仍然有像 `onMount` 和 `onDestroy` 這樣的鉤子,但是簡單地分配一個變量並讓它完全響應並在模板 (HTML) 中可訪問不需要任何特殊的語法糖。 另一個很大的區別是您可以直接在 Svelte 組件中編寫 CSS/SCSS。這只是一個選項,因為您仍然可以像在 React 中一樣導入樣式,但我注意到大多數 Svelte 項目都使用樣式內組件。 ### **Svelte 代碼分解** https://codesandbox.io/embed/svelte-water-example-scrimba-2vsoid?fontsize=14&hidenavigation=1&module=%2FApp.svelte&theme=dark&view=editor 上面的代碼實例化了一個 cupsOfWater 數組,將新的日期變量設置為當前日期。 聲明一個函數來創建一個新日期並將其存儲在一個名為 cup 的變量中,然後將其添加到 cupsOfWater 數組中。 模板部分更接近 HTML 並增加了一些功能。再次使用“{}”表示法,您可以從“<script>”部分引用任何聲明的變量。您還可以使用事件偵聽器(如 `on:click`)、條件(如 `{#if}`)和使用 `{#each}` 循環。 ### **Svelte 比 React 快嗎?** 是的,從快速的 HTML 生成到更快的構建和開發環境,Svelte 的性能都大大優於 React。 * 生成 HTML * 根據狀態更新 UI * 第一次內容豐富的渲染 * 互動時間 * 速度指數 所有這些都看到了可衡量的差異,而 Svelte 具有優勢。您的應用程序越大越複雜,差異就越明顯。 在 Zeitspace 的一篇文章中可以看到性能比較 https://www.zeitspace.com/blog/we-built-an-app-with-svelte.-heres-what-we-learned ### **Svelte 比 React 好嗎?** 當開始一個新專案時,Svelte 有足夠的優勢,它應該始終是一個考慮因素。 話雖如此,React 在使用率方面仍然絕對勝過 Svelte。這可能會導致專案的第 3 方插件支持、僱用和壽命問題。 不過,為了應對這一點,Svelte 語法的易用性使其非常容易上手,尤其是對於 React 開發人員而言。這是公司在招聘 Svelte 項目時可以藉鑑的東西(不要將自己局限於 Svelte 開發人員)。 ### **何時從 React 切換到 Svelte** Svelte 是構建複雜網站或 Web 應用程序的絕佳選擇。許多老牌公司已經開始將 Svelte 用於內部和外部應用程序: * 1Password * Avast * Chess.com * Alaska Airlines * Fusion Charts * Rakuten * GoDaddy * IBM * Square * 紐約時報 * 飛利浦 但這並不意味著您必須將當前的 React 應用程序放入垃圾桶! 那麼什麼時候是接觸 Svelte 的合適時機? 如果您的應用/網站: * 由於頻寬限制,需要較小的包大小 * 需要盡可能快 * 需要快速建造 When is not the right time to reach for Svelte? 什麼時候不適合使用 Svelte? 如果您的應用/網站: * 嚴重依賴第 3 方集成/工具 * 需要轉換為移動應用程序 這些很快就不會成為問題,但在投入之前確實需要進行一些研究和盡職調查。 ### **結論** 建議投入其中並嘗試在 Svelte 中構建一些東西。如果你來自 React,我幾乎可以向你保證你會喜歡它的簡單性和速度。

德國資深架構師:給新手工程師的幾點建議

一名資深的德國軟體架構師 Jeroen De Dauw,寫了一篇很好的文章,給新手工程師一些寫程式的建議。 - 原文出處:https://dev.to/jeroendedauw/advice-for-junior-developers-30am --- ## 給新手工程師的一般建議 ### 1. 程式碼不是重點 作為開發者,我們喜歡寫程式。大多數工程師希望收到的任務明確,可以不用管技術之外的事情,專心解決有趣的技術挑戰。 請花足夠的心力去確認,您正在解決正確的問題。引用管理學大師 Peter Drucker 的話:高效率地去做一件根本沒必要的事情,結果依然是完全沒意義。儘早、經常去搜集回饋,透過「持續交付」來向真正的用戶互動,成為敏捷(Agile)的工程師。 軟體開發成本高昂,現實世界專案的絕大部份工作都是在維護而已。再加上目標應該是對用戶、對生意有幫助,所以結論就是:寫程式最好的方法,經常是完全不寫。引用比爾蓋茲的話:用程式碼有幾行來衡量工程進度,就像用重量來衡量飛機的製造進度。 另請參閱:YAGNI 原則、KISS 原則、The Last Responsible Moment 文章。 ### 2. 軟體設計很重要 在我開發生涯的前五年,我以為軟體設計是架構師或其他特殊職位的人在做的事。我以為開發者專注在完成任務即可,以為軟體設計、最佳實踐、寫測試這些,都不關我的事。我的程式能跑,我的生產力很高,我以為這樣就對了。 直到我閱讀了 Robert C. Martin 的 Clean Code,這書刺激了我對軟體設計的關注,並包含許多範例與啟發。其中最啟發我的是:走得快的唯一方法,就是走得好。也就是說,如果你把事情搞得一團糟,結果只會讓你速度更慢。 學習寫出設計良好的乾淨程式碼,需要時間和精力。而且剛開始的時候,會寫比較慢,並且會犯錯誤。 ### 3. 使用最佳實踐 寫測試通常會有幫助。雖有例外,但大多數時候,寫自動化測試會大有幫助。寫測試就是一種最佳實踐。 如果你不太會寫測試,請遵循最佳實踐並為所有內容寫測試。**開始時,盲目遵循最佳實踐比遵循自己弱弱的判斷要好**。一段時間之後,您將知道怎麼寫測試比較有效,並能夠區分您搞砸了和不值得編寫測試的情況。因為 bug 變少了、重構起來更輕鬆了,您將開始理解測試帶來的深入的價值。**到有了自己的判斷力後,您將能夠超越最佳實踐**。 此建議適用於您在學習任何最佳實踐的新手時期。自動化測試只是一個例子。 有個陷阱要注意,明智的最佳實踐,與荒謬、適得其反的做法之間,只有一線之隔。因為大多數程式碼都很亂,而且大多數開發者(包括資深人員)不了解軟體設計的基礎知識,因此事情就更複雜了。有一個好的指導者很重要。除此之外,根據我自己的經驗,要小心只存在您的語言、框架社群的最佳實踐。尋找那些已經存在了幾十年的長青建議比較好。 --- ## 給新手工程師的技術建議 ### 4. 寫測試 寫自動化測試。也許在寫程式之前先寫測試,例如運用測試驅動開發(TDD)。這讓您可以輕鬆反覆驗證幾段程式是否正確,而不用一直手動跑測試、除錯。 > 你覺得先寫測試很煩嗎?但之後再忙著抓 bug 有比較好? 更重要的是,測試為您重構時提供了額外保障。你需要持續重構來保持程式乾淨。沒有可靠的測試保障,程式碼就可能越變越亂。 如果您的程式碼設計不佳,例如使用繼承進行重用,或使用靜態函數,則編寫測試會很困難。另一方面,如果您有遵循 SOLID 原則、沒有全局依賴項,那麼寫出好的測試並不困難。 設計好測試也很重要,因為糟糕的測試只會拖慢開發速度。避免將測試綁定到被測程式碼的實作細節或系統結構。 ### 5. 不要用繼承來做到程式碼重用 這是讓人以為是最佳實踐的其中一個反例。我的建議是:剛開始時,根本就不要用繼承來做到程式碼重用。這通常都幫助有限,而且帶來一大堆麻煩。請多用組合、少用繼承(關鍵字:composition over inheritance)。 ### 6. 寫出 OOP 程式碼 學習 SOLID 原則,避免寫出 STUPID 原則的程式碼 ( https://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ )。理解這些原則和反模式非常有價值。 創造一些真正的物件。只有靜態方法的類別,根本不算是物件導向。盡量避免完全使用靜態寫法。 ### 7. 寫出函數式程式碼 不要把函數式程式設計,跟指令式程式設計搞混了。 重點不是完全切換到函數式語言。而是學習使用函數式風格的優點。例如減少狀態、讓函數專心一件事。另請參閱:https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell ### 8. 程式碼稍微重複沒關係 將一大塊程式碼到處複製貼上當然很不好。有尊嚴的開發者很快就發現這一點,並開始遵循某種形式的:不重複自己原則 Don't Repeat Yourself (DRY)。不幸的是,對 DRY 的追求往往會導致過度工程和額外的複雜性。所以會有一條新原則:寫兩次原則 Write Everything Twice(WET)。也就是僅在第三次出現重複時,才動手改善重複段落。 ### 9. 型別、命名、註解 試著寫一些能夠表達自我的程式碼,避免寫註解。 > 每次寫註解時,都應該要皺一下眉頭,感受到自己的表達能力有點失敗。 —— Robert C. Martin 註解很危險,因為有可能說謊。程式碼可以不更新註解就修改,那一開始的註解就變錯誤了。這種情況下,註解不但沒幫助,還會誤導到別人。 要寫出能夠表達自我的程式碼: - **一個函數只做一件事** 因為只做一件事,就能給一個清楚的命名。 - **減少狀態** - **使用型別** 定義清楚的型別,加上跑測試,能讓系統更穩定。 - **減少混合型別** 避免可以同時是整數、布林值或字串的參數或回傳值。如果讓每個函數專心一件事,這自然會做到。 - **寫測試** 良好的全面測試,也同時會是程式碼的使用說明範例。 Robert C. Martin 的書 Clean Code 在命名和寫註解方面有提供一些很好的經驗法則。 --- 以上,希望對大家有幫助!