CodeLove 論壇 - 免費自學作業包＆新手友善討論區，幫你轉職工程師！

👉 讀技術文章  👉 上自學課程  👉 討論區交流
最新出爐作業包
⭐ 邁向資深之路：非同步 JS 訓練（二）—— 各種寫法的錯誤處理、收尾處理
⭐ 邁向資深之路：非同步 JS 訓練（一）—— 從 Callback Hell 到 Promise 介面
⭐ Github Desktop 新手入門教學 —— 用漂亮的 GUI 介面來學習 Git 基本觀念
⭐ 邁向資深之路：後端 JS 訓練（二）—— 玩玩看 Express，用純後端做做看部落格
⭐ 邁向資深之路：後端 JS 訓練（一）—— 玩玩看 Node，做做看老派 CLI 應用程式

🔍 搜尋結果：工程師

🔍 搜尋結果：工程師

後端 JS 訓練一：前言

身為網站工程師，對於 JavaScript 在 `瀏覽器還境` vs `Node.js 環境` 的關係，通常有點困惑 我認為單獨教一下 Node.js 開發，對於前端工程師的能力會有很大幫助！ 坊間要教 Node.js 通常會教「網頁後端程式設計」，這種教法當然沒問題 不過，我找到了一個更好吸收的教學法，就是從「命令列程式設計」開始教起！嘿嘿！ 命令列英文是 Command Line Interface，我們通常簡短稱呼為 CLI CLI 程式就是那種打開一個全黑的視窗，用戶需要手動打字，然後視窗又會跳出一堆字的程式 聽起來像是 40 年前人們使用電腦的方式，感覺是老派過氣的東西，對嗎？ 其實大錯特錯！ 工程師在 ssh 遠端處理主機的設定時，幾乎都還是操作透過 CLI 操作 使用 Linux 系列電腦的朋友（例如 Ubuntu 作業系統），日常中也會大量使用 CLI 即便是前端工程師，在開發過程，還是有大量的情況要使用 CLI，例如 NPM 相關指令通通會用到 --- 其實，CLI 是電腦程式最原始的 UI 介面！ Windows 電腦是一種 UI、網頁是一種 UI、手機是一種 UI 工程師在開發工具給別的工程師使用時，很常會懶得設計 UI 比如我寫了一個很強的檔案壓縮程式、或是硬碟清理程式，核心演算法寫完，我就想發佈給大家用了 我幹嘛還要花時間去寫一個漂亮、五顏六色、有按鈕的 UI？程式就用 CLI 操作就可以了，反正用戶都是工程師 --- 因為 CLI 是最原始的 UI，我認為教你寫一些 CLI 應用程式，對於 Node.js 會有極大的幫助 別擔心，這門課非常簡單，也非常好玩，也會讓你知道 Node.js 拿來寫 CLI 是什麼感覺 雖然這年頭市面上沒有人會去教 CLI 程式開發了，不過我保證你會獲益良多，還能讓之後學 Node.js 網頁後端開發，吸收得更好 嘿嘿，讓我們馬上開始吧！

2個讚   1留言 393瀏覽

常常懷疑自己該不該繼續走程式設計？簡單分享幾個觀點

不論是在學生、正在轉職、或是剛開始上班 不少人常常有這念頭：我好像不太適合走這條路，怎麼辦？ 讓我簡單分享幾個觀點 # 關於天份與熱情 很多人對於社會上各種工作抱有「資格論」的傾象 我抱持相反觀點，我認為你在各行各業，沒有天份、沒有熱情也沒有關係 詳細理由我不贅述，請參考我之前的文章：寫程式不需要天份，也不需要熱情 https://codelove.tw/@howtomakeaturn/post/2anXlx # 我在工作上總是做得很慢 這點跟生產力＆考績有直接關係，所以是比較重要沒錯 但是，所謂做得很慢，也可能是公司的要求不合理，或者身處團隊實在太強，同事實在太猛 所以，在職場經常有落後同事的感覺，這比較像一個人與團隊的節奏感的問題 如果你雖不優秀，但主管對你的表現其實尚可接受，你的程式碼 bug 很少、品質也還行，甚至你在各間公司其實也沒真的被開除過，那做得慢一點也還好吧 如果幸運遇到「知道怎麼分配適合任務給你」的專業主管，也許這問題，會更顯得微不足道 # 我還是很經常會懷疑自己 ... 很擔心 ... 有沒有可以參考的大原則、大方向？ 有，我建議你留意一件事就好了：「我有沒有在進步」 第一個原因是，寫程式這個行業，日新月異，發展實在太快，開發者需要不斷進步，才能維持競爭力 這種進步可快可慢，有自己的節奏沒關係，但每過幾個月回頭看，要有「我確實有變強一些」的感覺才行 有個很簡單的檢測方法，就是維護自己半年前寫的程式碼時，要有「好垃圾的程式碼，我寫得還真爛」的感覺。這代表你進步很多，否則不就是原地踏步？ 第二個原因是，我認識很多所謂學得快、做得也快的工程師，在職業生涯的前幾年，進步非常快 但是，大概在三十歲左右，大家難免速度會慢下來，更希望把重心關注在其他事情，比如生活品味上，這之後的技術能力就進步沒那麼快了 我想說的是，這很像是經典的「龜兔賽跑」的故事，你雖是烏龜，但能走多遠其實也不一定，長久下來未必是落後的，所以關注在自身的進步、成長、學習，準沒錯 # 結論 如果寫程式令你痛苦不堪、同事主管讓你壓力很大、待遇根本遠低預期、一直以來你也根本不覺得自己有在成長進步，那麼是有點慘，或許是該考慮轉行 但如果狀況沒那麼糟，我建議你關注在自己的成長狀態即可 定期寫筆記，記錄自己近期到底學了什麼，通常會發現進步得比想像中得還多 關於程式設計，慢慢研究、慢慢學，或許也能有不錯的發展 --- 以上，簡單看法分享

4個讚   0留言 414瀏覽

寫程式不需要天份，也不需要熱情

這是我 2015 年寫的文章，當時在學界、業界評價兩極，也引起很多人痛罵 多年後回頭看，我的觀點不變。文章滿適合這個論壇的，我順手轉發一下 --- 從來沒有一個技能，曾經被神化到這個程度： 「你不但要有天份，還要有熱情，才適合寫程式。」 那些寫程式的人，好像「從小就立定志向，決定未來要寫程式了」。 缺乏其一的話，你要嘛是個假貨，要嘛走不遠，總之就是不適合。 這種深植人心的刻板印象不但大錯特錯，同時還是有害的。 隨便找幾個工程師都能證明這點。 # Jacob Kaplan-Moss（Django創造者） Jacob Kaplan-Moss的這份簡報提到： [一個平庸工程師的自白](http://www.inside.com.tw/2015/06/12/i-am-a-mediocre-programmer) > 這種關於「程式天才」的神話非常有害，一方面它把行業門檻設置得特別高，令很多人望而卻步，另一方面它也在折磨產業內的人，因為你如果不能 rocks ，就會變成 sucks ，所以不得不用一切時間來努力學習和工作，導致影響生活。…（略）…我們應該改變這種態度，寫程式只是一些技能，並不需要太多天分，它是可以學習的，而且做一個平庸的工程師不丟人， 他本人在[Twitter的自介](https://twitter.com/jacobian)直接寫「不是真的程式設計師（not a real programmer）」， 透漏著他對這種迷思的不耐煩。 # Jacob Thornton（Bootstrap作者） 在Github擁有八萬顆星的Bootstrap作者， 前Twitter、現任Medium工程師Jacob Thornton的一篇採訪也是這種迷思的反例： [Jacob Thornton痛恨電腦（Jacob Thornton Hates Computers）](https://medium.com/@verbagetruck/jacob-thornton-hates-computers-5c64f164ee07) > 當他說「我痛恨電腦」的時候，並不完全在開玩笑。…（略）…他說「我本來要去唸社會學的」 接著描述了他第一份工作的情況： > 我拿到了一個遠超我能力的工作。每一天都可能被開除。所以我非常努力工作，想搞懂JavaScript，因為我不懂它到底在幹嘛。 > 我一生中最現實的一刻到了。整間公司的人圍在我身邊，要我做一個XHR request。我根本沒做過，我只稍微聽過而已。於是我開始打字、重新整理瀏覽器，然後什麼都沒出來。我反覆做了幾次，知道自己完蛋了，他們發現我是假貨了。接著我突然發現自己忘記加「.send()」。我加了之後再次重新整理瀏覽器，畫面成功顯示。整個團隊感覺像在說「喔，酷。」然後就各自回辦公桌了。 > 我在那裡坐了15分鐘。心想，就這樣。我搞定了。我不會被開除了。 這段描述一點也不像「程式天才」在職場的表現。 至於支持他一路走來的動機是什麼呢？他說： > 我是一個高度在乎同儕的人，我做前端的朋友總是會告訴我哪個地方做很醜或是在哪個瀏覽器上壞掉。感覺真的很棒。我真的只想跟朋友一起寫程式，一起工作。 [他本人的Twitter](https://twitter.com/fat)自介寫「computer loser」， 置頂推文是「公司裡第一爛的工程師，但是第三酷」。 這種態度跟刻板印象完全相反。 # Rasmus Lerdorf（PHP之父） Rasmus Lerdorf的[言論](https://en.wikiquote.org/wiki/Rasmus_Lerdorf)常常引起廣泛爭議： - 我其實很討厭寫程式，不過我喜歡解決問題。 - 有些人熱愛寫程式。我不懂他們為何會這樣。 - 我不是一個真的工程師。我把東西弄一弄，弄到能跑之後就不管了。真的工程師會說「這段程式能跑，但記憶體沒管理好，我們來修好它」。我只會說，一直重新開機不就好了。 從他的言論，很難看出他對電腦本身有多少熱情。 他也跟Jacob Kaplan-Moss以及Jacob Thornton一樣，懶得對寫程式的迷思多做解釋， 乾脆直接說自己是loser、假工程師了。 # David Heinemeier Hansson（Rails之父） DHH在接受[Big Think訪問](http://bigthink.com/videos/big-think-interview-with-david-heinemeier-hansson)時提到： > 說來有點好笑。我以前寫PHP跟Java的時候，常常花時間去摸其他程式語言。到處摸看看其他程式語言…隨便什麼都好。寫PHP跟Java實在太悶了，我需要用這種方式讓自己暫時抽離。 > 我以前寫PHP跟Java的時候，完全不覺得自己之後會當程式設計師。 整段看起來都不像是一個「電腦天才」的自我介紹。 最後讓他愛上的不是電腦本身，而是Ruby程式語言的優雅性。 如果Ruby沒有被發明，DHH現在也許會做完全不同的事情。 --- 這一類可以說明刻板印象大錯特錯的文章實在太多了， 看看工程師們最愛的幾個玩笑：[關於工程師 59 條搞笑但卻真實無比的語錄](http://www.inside.com.tw/2013/12/20/59-hilarious-but-true-programming-quotes-for-software-developers) - 一個人寫的爛軟體將會給另一個人帶來一份全職工作。 - 傻瓜都能寫出電腦能理解的程式，優秀的工程師寫出的是人類能讀懂的程式。 - 開發軟體和建造教堂非常相似——完工之後我們就開始祈禱。 如果工程師都很有天份跟熱情，這些笑話又怎會受歡迎呢。 再看看Medium上很受歡迎的學習系列文章：[資深開發者給後輩的七個 Coding 學習心得](http://buzzorange.com/techorange/2013/11/29/wish-someone-had-told-me-when-learn-coding/) 其中的幾個建議 - 也許常常有人說你是錯的 - 也許常常會有人跟你說「你並不是個 Coder」 - 不要在意外表，能力才是一切 無非就是想打破這類寫程式的迷思、無意義的資格論神話。 下次又有人學到一半，開始反省自己適不適合、夠不夠資格的時候， 我只想跟他說：你就多找幾種方式學學看吧，不要抱持那種奇怪的資格論。 很多時候其實只是[搞錯方法](http://blog.turn.tw/?p=1283)、[搞錯心態](http://blog.turn.tw/?p=2568)而已。 真的完全學不懂再放棄吧。 寫程式不需要天份，也不需要熱情。 (Photo via Sano Rin, CC licensed.)

3個讚   3留言 4,465瀏覽

未來 ChatGPT 會取代軟體工程師嗎？你完全不需要擔心這個

最近看到滿多年輕學生、考慮轉職者提問：未來 ChatGPT 會取代軟體工程師嗎？ 看來這個議題已經造成不少 IT 領域學生的焦慮，我非常驚訝，讓我簡單談論一下這件事 # 個人經驗回顧 我在畢業前全心學習 web 前端與後端開發，2012 年畢業時，正逢智慧型手機快速發展，所有公司都在思考如何開發手機 app 來創造新機會，當時媒體的主要論述是：「web 已死！web 工程師都將失業，未來是 mobile app 的世界！」 當時年輕的我，看到這些媒體這樣分析，也是有點焦慮，但同時又有點不服氣，所以依然 100% 心思在研究 web 開發，不管媒體怎麼看衰。現在，10 年過去了，請問 web 職缺消失了嗎？ # 媒體的習慣、網紅 YTer 的習慣 想像你住在一個非常小的島嶼國家上，往外走一下就看到海，國家全年365天基本沒什麼大事，每天就是太陽升起、太陽落下。如果你是島上的「新聞從業人員」，請問你每天能做什麼？你當然只能誇大你看到的每件事情。 看到海水漲潮，發新聞：「海水異常上漲！恐有釀禍危機！全國一半人口恐有水災、死亡風險！」 看到海水退潮，發新聞：「近三年最低點！海水不斷消退、國家水資源流失、重大警訊！我國恐成大型沙漠！」 世界上大多數事情本就「帶有波動性」，一下狀況好一下狀況壞，潮起又潮落，正如月有陰晴圓缺，這相當正常。 媒體、網紅，基本上需要吸引人們關注來過活，他總不能每天發新聞：「今天海水正常漲潮，沒什麼特別的。」、「今天海水退潮了，這很自然，不太重要。」 身為現代公民，你要有能力透過媒體吸收新知，但同時也要有能力保持冷靜、自行判斷，不要隨意被影響。你要能看出各種觀點背後相關的利益。 # AI 對職缺的影響 AI 當然對各行各業會有重大衝擊，但是目前也僅止於改善工作效率、優化流程而已。 AI 因為可以加強專業人員的生產力，所以會造成職缺變少一點，但要到「軟體工程師通通失業」、「就靠機器人寫完所有程式」這種程度，實在太誇大了 最後，程式設計已經是各種工作領域之中，最難被機器取代的職缺之一，如果真的被高階人工智能取代，那社會上已經沒有多少工作適合人做，大概會是「無條件基本收入」制度之類的社會 --- # 結論 太廢的技能、感覺問 google 或問 ChatGPT 就有的東西，可以不用學了，像死背課文一樣的任務再也不用做了 除此之外，該學什麼學什麼，不用想太多 上個時代，懂得善用 google 與網際網路的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 下個時代，懂得善用 AI 的專業人士 vs 不懂得善用的專業人士，生產力有巨大差別 除此之外，跟案主溝通、釐清功能規格、分析各種技術選擇、認識領域知識並設計軟體，是極度複雜的工作，你真的覺得一個機器人放在面前聊天幾分鐘，它就能通通做完給你？ --- 以上，簡單看法分享

2個讚   2留言 664瀏覽

Git 入門上手教材：第7課 ── 學會處理 git 衝突

## 課程目標 - 學會處理 git 衝突 ## 課程內容 這課來學一下 commit 彼此有衝突，而 git 沒辦法自動合併的情況吧 先挑一個資料夾，把 `my-work-1.html` 裡面隨意加上幾行內容 ``` <p>我的第一個網頁檔案</p> <p>new content a</p> <p>new content b</p> <p>new content c</p> ``` 接著 ``` git add my-work-1.html git commit -m 'new content abc' git push ``` 順利送出！ 然後去另一個資料夾，把 `my-work-1.html` 裡面隨意加上幾行內容 ``` <p>我的第一個網頁檔案</p> <p>new content x</p> <p>new content y</p> <p>new content z</p> ``` 接著 ``` git add my-work-1.html git commit -m 'new content xyz' git push ``` 結果失敗了！一如預期，被 git 喊停了 ``` To github.com:howtomakeaturn/my-first-testing-repo.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'github.com:howtomakeaturn/my-first-testing-repo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. ``` 預期之中，這時應該 pull 對吧？ ``` git pull ``` ``` remote: Enumerating objects: 14, done. remote: Counting objects: 100% (12/12), done. remote: Compressing objects: 100% (4/4), done. remote: Total 8 (delta 3), reused 8 (delta 3), pack-reused 0 Unpacking objects: 100% (8/8), 792 bytes | 79.00 KiB/s, done. From github.com:howtomakeaturn/my-first-testing-repo d999c25..2cf01f4 main -> origin/main hint: Pulling without specifying how to reconcile divergent branches is hint: discouraged. You can squelch this message by running one of the following hint: commands sometime before your next pull: hint: hint: git config pull.rebase false # merge (the default strategy) hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. Auto-merging my-work-1.html CONFLICT (content): Merge conflict in my-work-1.html Automatic merge failed; fix conflicts and then commit the result. ``` 在前一課，我們 pull 之後，會被 git 自動把雲端版本、跟本機你剛改過的版本，合併在一起，然後在終端機編輯器內，請你打一段小訊息，備註這次合併 這次，卻沒有進入終端機編輯器內，而是跳出一串訊息！ 注意看最後幾行！ ``` Auto-merging my-work-1.html CONFLICT (content): Merge conflict in my-work-1.html Automatic merge failed; fix conflicts and then commit the result. ``` 這就是 commit 衝突的情況：兩個 commit 都有改到同樣檔案，雖然先後時間不同，但是 git 不敢直接用新的蓋掉舊的！ git status 看一下 ``` Unmerged paths: (use "git add <file>..." to mark resolution) both modified: my-work-1.html ``` 清楚寫出了：both modified，兩邊都修改過！ 打開 `my-work-1.html` 看一下 ``` <p>我的第一個網頁檔案</p> <<<<<<< HEAD <p>new content x</p> <p>new content y</p> <p>new content z</p> ======= <p>new content a</p> <p>new content b</p> <p>new content c</p> >>>>>>> 2cf01f4f63f5ea9040610495688f08032761a170 ``` 看起來很嚇人，其實，只是 git 怕你看不清楚，用一種誇飾法，列出衝突的地方而已！ HEAD 段落，是你剛提交的 commit 部份 `2cf01f4f63f5ea9040610495688f08032761a170` 的部份呢？則是剛剛從 github 抓下來的 commit 代號！ 要如何處理衝突呢？其實，你就決定一下，衝突這幾行，到底要怎麼合併就可以了，然後把 git 誇飾法的地方刪掉 比方說，我決定讓行數交錯呈現吧 ``` <p>我的第一個網頁檔案</p> <p>new content a</p> <p>new content x</p> <p>new content b</p> <p>new content y</p> <p>new content c</p> <p>new content z</p> ``` 改完之後 ``` git add my-work-1.html ``` ``` git commit -m 'handle conflict' ``` 手動合併的 commit，我個人通常習慣訊息就寫 handle conflict ``` git push ``` 大功告成！這就是所謂的 git 衝突處理 ## 課後作業 接續前一課的作業 在上一次的作業，我們嘗試了兩個資料夾，同時 push 送出 commit，導致 git 比對 github 上的雲端版本時，發現有衝突，請你先 pull 再 push 的情況 上次的情況比較單純，因為雖然有衝突，但是 git 一看就知道影響不大，所以 pull 時自動處理了衝突，把事情都安排好了 這次的作業，我們要模擬「遇到衝突，而且 git 無法自動處理衝突」的情況 --- 請按照以下步驟，送出 commit **第一步** 到 `at-home` 資料夾，打開檔案 `about.html` 的內容，原本是 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發</p> ``` 請改成 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發，目標是成為厲害的前端工程師</p> ``` 然後送出 commit，接著 `git push` 出去 你會看到 github 上面就被更新了 **第二步** 到 `at-laptop` 資料夾，假設你今天出門工作，忘記先 pull 了，也忘記檔案其實你已經改好了 打開檔案 `about.html` 的內容，依然是 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發</p> ``` 請改成 ``` <h1>我是誰</h1> <p>我是XXX，目前在自學網頁開發，目標是成為厲害的軟體工程師</p> ``` 然後送出 commit，接著 `git push` 出去 這時 git 會請你先更新，於是你輸入 `git pull` 你會發現 git 表示遇到衝突，無法自動合併，請你處理！ 原來有一邊是寫「前端工程師」，另一邊是寫「軟體工程師」 git 無法自動判斷你到底是想要以哪個為準！（其實用哪個都可以吧！） 請處理這個 conflict 衝突，處理完之後 push 到 github 上面 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 可以把 github 專案連結，貼到留言區

0個讚   12留言 757瀏覽

Git 入門上手教材：第5課 ── 學會連線 github

## 課程目標 - 學會連線 github ## 課程內容 git 工具，光是一個人離線使用，就已經很好用了 再加上雲端功能，變成雲端專案，那就會更強大 上傳專案可分為兩種類型 第一種是公開專案 public repository 也就是所謂的開源專案 open source 在實務上，軟體工程師，會大量使用彼此開源分享出來的專案 學習跟開源社群互動，是工程師一個極度重要的技能 當然不可能所有程式碼都免費熱心給人用，所以會有第二種，稱為私人專案 private repository 也就是自己、或者團隊的私人專案 --- 業界最常用的 git 雲端服務有三家 github、gitlab、bitbucket 當然公司要自己架一套自己的 git server 也可以 不過以 open source 來說，主要會在 github 上面 --- 請自行註冊 github 帳號，之後建立一個 github 專案 Create a new repository -> 幫專案簡單命名 `my-first-testing-repo` -> 類型選 Public -> 初始化時別加任何檔案（通通選 None） 舉例來說，我剛建立的專案，網址在這： https://github.com/howtomakeaturn/my-first-testing-repo 回到本機的專案底下，依序輸入下列指令 ``` git remote add origin [email protected]:howtomakeaturn/my-first-testing-repo.git ``` 設定雲端 git 對應網址 ``` git branch -M main ``` 建立一個命名為 main 的分支 （本機上的分支命名是預設的 master，近年因為這有奴隸時代主人/奴僕的影子，在轉型正義之下，很多廠商把預設分支名稱改為 main） ``` git push -u origin main ``` 把本機的程式碼，推到 github 上去 --- 在網路上找文章的時候，有時候會看到主分支叫 master，有時會看到叫 main 這是因為轉型正義、政治正確的關係，新舊慣例有點衝突，自己習慣、轉換一下即可 --- 另外，在設定雲端 git 位置的時候，有文章會寫 `https://` 開頭，有文章會寫 `git@` 開頭 ``` git remote add origin https://github.com/howtomakeaturn/my-first-testing-repo.git ``` ``` git remote add origin [email protected]:howtomakeaturn/my-first-testing-repo.git ``` 其實功能一樣，前者是每次跟雲端 git 互動，都要驗證輸入帳密 後者是比較方便，每次都自動檢查電腦上的 ssh key 驗證，但一開始設定 key 會花些時間 通常來說，任意挑一種方式，都可以。但是 github 在 2021 年開始，不再允許 git push 時使用帳密驗證 所以，就去學一下 ssh key 的設定方式吧！需要在本機建立 ssh key，然後到 github 更新 key 資訊 請根據你的作業系統，自己上網找一下建立 ssh key 的方式，然後再找一下 github 設定 ssh key 的地方 --- 完成之後，這個開源專案，不但可以線上看到程式碼 https://github.com/howtomakeaturn/my-first-testing-repo 還可以線上看到 commit 提交紀錄 https://github.com/howtomakeaturn/my-first-testing-repo/commits/main ## 課後作業 接續前一課的作業，現在你打算把專案上傳到 github，當做雲端備份，也方便跟別人分享原始碼 請註冊一個 github 帳號，建立一個新的 repository，並且把之前做的個人品牌網站，上傳到 github 上傳之後，你應該會在 github 專案的頁面，看到專案的程式碼，也能看到多筆 commit 歷史紀錄 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 可以把 github 專案連結，貼到留言區

0個讚   8留言 955瀏覽

Git 入門上手教材：前言

有聽過 git 嗎？ git 是現代工程師 100% 會使用到的工具 在以前的年代，團隊內有多位工程師，同時在修改多個檔案時，你知道要怎麼互相更新檔案嗎？ 答案是使用「USB 隨身碟」！（更早以前是用3.5磁碟片！） 也就是我改完一部份之後，放進 USB 拿給同事更新。他們改完一部份之後，也拿給我更新 在那個網路不發達、工具不發達的年代，你可以想像這滿沒效率的！ --- 除此之外，就算你完全是自己一個人工作，git 還是非常好用的 首先，專案會一直修改更新，而 git 的版本管理功能，可以讓你不用擔心手上舊版的程式碼被新版蓋掉：你隨時可以切回去看舊版程式碼 另外，當你有桌電、筆電，等等多個裝置時 也許你平常都在家裡用電腦，偶爾帶筆電出門工作 這種情況，多個裝置的專案程式碼同步，也可以使用 git 最後，其實這年頭沒有誰是一個人寫程式的。你多少會需要跟 open source 社群互動，屆時當然還是使用 git 在同步程式碼！ --- git 這個工具的用法，可深可淺 這門課會教你足夠在工作上使用的最基本 git 指令，非常有趣、好玩 不用想得太困難，git 就只是個工具而已，學習怎麼使用而已 話不多說，讓我們馬上開始來學習 git 的使用吧！

4個讚   0留言 1,713瀏覽

MVC是一個巨大誤會

我是web工程師，從剛開始學MVC就深感困惑： - 怎麼每個地方說的MVC都不太一樣？ - 有些文章講的MVC，跟我正在用的MVC，怎麼像完全不同的東西？ Model、Controller、View三者到底如何互動？真是一個定義不明、含糊不清的名詞。 這讓我研究了很久。最後，發覺它是一個嚴重的誤會。 這個誤會導致了學習和溝通上的代價，請聽我娓娓道來。 # 哪些是MVC？ web領域，不論前端(client-side)、後端(server-side)、不論什麼程式語言，幾乎所有framework都自稱、或被認為是「MVC」。 有哪些呢？ 前端：Backbone.js、AngularJS、Ember.js… 後端：Ruby on Rails、CodeIgniter、Laravel、Django… 真的是這樣嗎？它們全都是MVC嗎？ # MVC是什麼？ 該怎麼定義MVC呢？ 我們先來看看維基百科怎麼說： > MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。 嗯，跟大家說的一樣。我們繼續往下看： > 模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 看起來有些陌生，整段描述跟你的web開發經驗完全不同，對嗎？ 最大的疑問來自這句： > 那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 後面直接叫你去看觀察者模式(observer pattern)。 問題來了：你有在view跟model之間實作observer pattern嗎？ 也就是說，你的Model在資料改變之後，能主動通知View嗎？ 沒有的話，就根本不符合MVC的定義。 # 全都不是MVC？ 我們現在發現MVC有observer pattern這個必要條件了。 事情嚴重了起來。 client-side framework或許能夠符合這個條件。 以Backbone.js官網範例來說，我們可以這樣在Model上註冊： ``` book.on({ "change:title": titleView.update, "change:author": authorPane.update, "destroy": bookView.remove }); ``` 它的確實作了observer pattern。 但server-side framework呢？ 你的Model如何能在發生改變之後去「主動通知」View？ 你平常開發web哪有用到server push的技術？ 所有server-side framework，從Ruby的Rails；PHP的CodeIgniter、Laravel；到Python的Django，他們全都不是MVC。 它們實作的，是昇陽電腦在1998年提出的「Model 2」。 # 什麼是Model 2？ Model 2名氣不大，在維基百科連中文條目都沒有。我們看看英文條目怎麼講： > Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. > In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. 它針對web而設計，讓controller進行必要的程序之後，將資料塞進view去呈現。 正是我們server-side框架在做的事情。 也就是說，server-side目前只能實作Model 2；client-side可以實作Model 2，也可以實作MVC。 # 巨大的代價 web工程師最常碰的就是client-side跟server-side框架。結果整個業界把MVC跟Model 2混為一談，都說成MVC。 這帶來了什麼後果呢？ MVC變成一個從初學者到業界工程師，永遠說不清楚、下不了定義的名詞。 這件事對於學習和討論，造成了非常巨大的成本。（參考下方的Q1和Q2） # 那該怎麼辦？ 下次有初學者詢問「什麼是MVC」的時候，怎麼回答才不會害他回家之後「越查資料越混亂」？ [Rails is not MVC](http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html)的作者提出了三種解決方法： > 第一個方法是聲稱MVC已經從原始意義改變了，Model 2也可以稱為MVC。如此一來，我們可以用「傳統MVC」或「真MVC」來描述原始的MVC。這是現在普遍的作法，但我不認為改變定義是一個好主意。這幾乎是越搞越亂。 > 第二個方法是到處推廣Rails其實是Model 2，MVC就留給…MVC吧。這很困難，但至少能保持定義不變。 > 第三個是直接忽略這些混亂。管它那麼多？ 我個人覺得MVC這個詞已經沒救了，不管怎麼解釋都會帶給別人混亂。 當對方同時學習client-side跟server-side時，混亂更強烈。 我選擇這樣回答： 「MVC有分很多種喔！網路上全部沒寫清楚，你一定看不懂。 沒關係，你只要知道View可以抽出來就好。 C跟M先別管，你先隨便瞎搞吧。」 --- # Q&A ## Q1: 怎麼可能各大server-side framework都搞錯？ 確實有人腦袋清醒得很，它就是Python的Django。 Django的官方文件內根本沒有「Controller」這個名詞。 看看Django官網的常見問題： > Q: Django似乎是一個MVC框架，但你們把Controller命名為「View」，把View命名為「Template」。你們幹嘛不用標準命名啊？ > A: （前略）…如果你真的很想要一個縮寫，你就說Django是一個MTV框架吧。Model、Template、View。這樣分比較有道理些。 Django不想變成搞亂MVC的幫凶，只好委屈地又發明了一個名詞「MTV」。 ## Q2: 那client-side框架有受影響嗎？ 有。client-side框架也必須為MVC巨大誤會浪費一堆時間解釋。 看看Backbone.js官網的常見問答： > Backbone跟「傳統MVC」的關聯何在？ > …我們來比較一下Backbone跟像是Rails這種server-side MVC框架的差別… Backbone實作了「傳統MVC」，卻被迫用「傳統MVC」來描述server-side的Model 2，然後花一堆篇幅解釋。 ## Q3: 知道Model 2的存在又如何？我現在依然一片混亂！ 沒錯，Model 2跟MVC都用到Model、Controller、View三個名詞，所以看起來類似。 但是，我們不應該再把時間花在思考「MVC怎麼如此難懂」。 我們討論的重點，應該是「如何分辨MVC與Model 2」、「在server-side如何實作Model 2才漂亮」、「在client-side實作MVC跟Model 2的優劣分別何在」。 ## Q4: 好，那你現在回答我，「如何分辨MVC與Model 2」？ OK，就讓我拋磚引玉一下。 分別談談Model、View、Controller吧： ### View - Model 2: 不具有行為，只是等別人塞資料進去的模板（template）。 - MVC: 具有監視Model的行為，並以此去改變呈現（presentation）。 兩種View有沒有很像？跟張飛、岳飛一樣像。 看看Backbone.js官網的View範例。你server-side的View哪是長這樣？ ``` var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, initialize: function() { this.listenTo(this.model, "change", this.render); }, render: function() { ... } }); ``` ### Controller - Model 2: 接收請求與參數，轉交給Model處理，再把結果（最新的資料）塞進View。 - MVC: 接收請求與參數，轉交給Model處理。沒其他事了。 兩種Controller有沒有很像？跟小狗、熱狗一樣像。 MVC的View跟Model 2的Controller可能還比較像一點。（隨便說說，千萬別這樣類比。） ### Model - Model 2: 接收Controller傳來的參數，回傳結果。 - MVC: 接收Controller傳來的參數，將結果通知View。 Model倒是有些類似。 總之，Model 2跟MVC除了三個部份的名字一樣之外，沒什麼關聯了。 ## Q5: 我決定徹底鑽研MVC跟Model 2的定義了。給我一些延伸閱讀？ http://www.ithome.com.tw/node/77330 http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html https://docs.djangoproject.com/en/1.7/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names http://backbonejs.org/#FAQ-mvc https://r.je/views-are-not-templates.html --- ##一些社群的看法（2015-2-28） 附上幾個社群的連結，裡面有許多很棒的討論。 https://www.facebook.com/groups/javascript.tw/permalink/600136880087654/ https://www.facebook.com/groups/199493136812961/permalink/759391387489797/ https://www.facebook.com/groups/pythontw/permalink/10153760201638438/ https://www.facebook.com/mosky.liu/posts/10203964969186383 http://www.ithome.com.tw/voice/94877

0個讚   1留言 523瀏覽

[資源分享] 裝爆的VScode擴充套件，人生沒有擴充套件就是黑白的！

## code spell checker ![](https://i.imgur.com/dEaysXp.png) 不管是自己的英文程度太差，還是粗心大意，把英文字拼錯是家常便飯， 這款擴充套件就是來幫助你的救星！ 使用code spell checker馬上會幫你標出奇奇怪怪的單字， 讓你確定沒有不小心把1跟l搞錯，就debug一整天的那種尷尬事件！ ## live server ![](https://i.imgur.com/BdyRNga.png) 寫前端最需要的就是看到畫面٩(｡・ω・｡)，و 每次如果都要自己在網址列找到檔案的位置才打開html， 那實在是太沒有工程師的效率了，簡直荒唐！！ 當然要使用這款live server來架，馬上就可以看到自己的前端畫面， 而且儲存之後自動更新，根本神器。 ## material icon theme ![](https://i.imgur.com/cLgrQLt.png) 沒有什麼其他的，純粹就是好看！ 裝了這款之後可以讓icon變得比較不一樣，整天都跟程式為伍， 當然就是要追求好看的圖圖。 ## prettier - code formatter ![](https://i.imgur.com/DDkFzb4.png) 超級讚的排版好物，懶得自己縮排了啦！就靠這款prettier， 讓你的程式從原本醜醜的排版， 最後，變成人類也能看懂的正常程式，必裝神器之一！ ## 補充有人整理的 ### github ![](https://i.imgur.com/7X9O5Dz.png) [專案點這邊](https://github.com/Lin-jun-xiang/vscode-extensions-best/blob/main/README_%E4%B8%AD%E6%96%87.md) ### 影片分享 https://www.youtube.com/watch?v=xGE_M3R69YA [ Alex 宅抬槓 ] Visual Studio Code 外掛生存戰｜從 2019 到 2020 前端開發必備安裝推薦 ## 心得 以上都是寫程式過程中會發現的需求，自然會想要找擴充來安裝，提升效率、美觀， 利用這些擴充功能，寫程式的體驗真的變得很舒服呢(๑•́ ₃ •̀๑)。 未來如果有什麼新的，也會持續補充，也歡迎大家分享討論唷～～

4個讚   4留言 1,082瀏覽

新手推薦：最基本的 10 個 Git 指令與原理

Git 是軟體工程師最重要的工具之一，今天來學一點 Git 吧！ 原文出處：https://dev.to/swordheath/git-the-basic-commands-every-developer-should-know-2m1e **什麼是 Git？** Git 是一個追蹤文件變更的版本控制系統。使用 Git 可以讓您保留所有更改的記錄並根據需要返回到特定版本。它使用方法簡單，佔用空間小，而且非常高效。它的分支模型使它有別於幾乎所有其他可用的 SCM。您可以使用 GitHub 或其他線上主機來儲存文件的備份及其修訂歷史。 **Git 的主要元件** 對我來說，Git 是在團隊專案中使用的絕佳工具，因為它有助於避免程式碼混淆，並帶來一個簡單而有效的工作流程。 ** Repository** Git 存儲庫（或簡稱 repo）包含所有專案文件以及整個修訂歷史記錄。您使用一個普通的資料夾（例如網站的根目錄夾）並告訴 Git 將它變成一個存儲庫。這將建立一個 .git 子文件夾，其中儲存了所有用於追蹤修改的 Git 元資料。簡而言之，存儲庫是您保存程式碼的地方。 **Commit** 要向存儲庫加入新程式碼，您需要進行提交，這是存儲庫在特定時間點的快照、將特定更改或一系列更改提交到存儲庫中的文件。 Git 的歷史紀錄由連續的提交組成。 **Branch** 分支用於儲存您的更改，直到它們準備就緒。在主分支（master）保持穩定的情況下，您可以在分支上工作。完成後，您可以將其與母版合併。最大的好處是您可以在一個存儲庫中擁有多個分支，並在需要時合併它們。 **Pull requests** 這是 Git 中用於在將更改合併到您的程式碼庫之前討論更改的技術。PR 不僅僅是一個通知；它是針對所提議功能的專門討論串。這在多人處理同一份程式碼時特別方便，允許開發人員檢查彼此的工作。 現在我們已經簡要討論了 Git 的主要元件，我想列出每個開發人員在開始使用 Git 之前必須知道的**10 個基本 Git 命令**。 **1。開始一個新的存儲庫** ``` git init ``` **2。分別設定作者姓名和電子郵件地址以用於您的提交** ``` git config - - global user.name “[name]” git config - - global user.email “[email address]” ``` **3。從遠程存儲庫下載現有程式碼** ``` git clone <https://name-of-the-repository-link> ``` **4。建立一個新分支** ``` git branch <branch-name> ``` **5。在 master 中合併分支** ``` git merge <branch-name> ``` **6。從遠程存儲庫取得更新** ``` git pull <remote> ``` **7。將文件加入到 Git 的暫存區** ``` git add <file or directory name> ``` **8。存儲庫的當前狀態** ``` git status ``` **9。將在 master 分支上所做的更改發送到您的遠程存儲庫** ``` git push [variable name] master   ``` **10。更改 head（在版本歷史記錄中加入一筆更新）** ``` git commit -m " Commit Message" ``` --- 這些是每個使用 Git 的人都必須知道的主要指令。Git 非常好用，指令數量也相當多。但是記住這些指令並不是一項艱鉅的任務——您只需要開始使用 Git，大多數指令都會憑直覺記住。

0個讚   0留言 673瀏覽

給寫完 JavaScript 系列九的同學們：求職前的準備＆簡易指南

有幾位同學已經寫完系列一～九的全部作業了 整體能力已經可以準備開始面試前端工程師的職缺了 這邊寫一篇簡單說明 # 需要補充的技能 前端技能中最困難的部份已經有相當基礎了 剩下有些東西沒那麼難，但要學一下，上班會用到 這些東西我未來可能會寫教材，但我最近很忙，近期無法寫新教材 ## git 程式碼版本管理工具，找書或者上網找文章學一下，至少要會 add commit push pull 這些指令 ## npm 作業都是用線上環境，實際開發都是在本機為主，需要知道 javascript 套件管理工具 npm 怎麼用 ## create-vue https://github.com/vuejs/create-vue 要能在本機架起來 vue 開發環境，這款至少要知道一下 ## vue 3 教材安排是學 vue 2，但現在很多公司都已經轉用 vue 3 語法了 背景知識大同小異，但語法差異不少，要知道一下怎麼轉成 vue 3 寫法 --- 老樣子，學的時候有點一知半解沒關係，大概會用就好，畢竟是面試 junior developer 的職缺，公司通常會有工程師同事，技術長＆他們會協助你實務上的細節 # 投履歷的公司篩選 在找工作的時候，投那種「無經驗可」的職缺 很多公司會寫「一年以上工作經驗」，這種就是不歡迎半路出家剛學完者 因為很多人從補習班畢業之後，連 hello world 都寫不出來，公司想要避免遇到這種人 就先投「無經驗可」的職缺就好 公司類型基本上有分「接案公司」、「做自己公司產品」兩種 第一份工作沒差，去接案公司練功、去做自家產品慢慢打磨產品，都可以，待個半年，先進入業界再說，都可以學到很多 長期來講，我之後再寫文章說明差異 # 履歷表的寫法 基本上你照自己習慣寫，簡潔有力即可，這行業基本上是實力主義，唬爛幫助不大 但有幾個東西務必要寫進去 ``` 學習的過程中，為了瞭解網頁的基礎，而不只是當個框架的使用者，我有用純 html/javascript 練習多個元件 [附上第三課全部作業] 並且有找一些看起來很紅的業界套件，練習導入使用 [附上第四課全部作業] 然後我有用 vue 寫了多個應用程式練習 [附上第八課全部作業] 還有試著拿 vue 生態系的元件庫做範例，模仿做了幾個元件 [附上第九課全部作業] ``` 我認為履歷表附上這些東西，會讓99%的面試官印象深刻，覺得你幾乎是「即戰力」，對你更有信心 # 結語 以上，如果你寫完系列一～九全部內容了，那我認為你離上班已經很接近了 如果正在準備轉職，準備一下，試著投一些履歷試試看，試試水溫 不用急著辭職，因為今年全球景氣充滿不確定性，但就試試看能收到多少面試邀請，等於秤秤自己的斤兩，比較有個底 順利上班之後記得來寫文章分享心得 然後最好養成習慣寫技術部落格，直接在這邊寫即可 求職過程有疑問，一樣多多來這邊發問即可 求職卡關、面試不順、薪資待遇有疑慮、業界實務有困惑，都上來發問即可 我會視情況公開 or 私下回答 以上，有打算轉職的同學，祝大家早日上班囉～

8個讚   2留言 1,507瀏覽

我推薦 Svelte 給所有工程師的 10 個理由

原文出處：https://dev.to/mhatvan/10-reasons-why-i-recommend-svelte-to-every-new-web-developer-nh3 儘管 [Svelte](https://svelte.dev/) 的初始版本早在 2016 年 11 月就發布了，但它在 JavaScript 前端框架中仍然處於劣勢，並且最近才開始受到社區應有的關注。 在使用了多年的各種 JavaScript 框架（包括 Angular、React 和 Vue.js）之後，我認為我對編寫程式碼如何愉快以及如何令人沮喪有了良好的總體印象。 幾年前，使用 [jQuery](https://jquery.com/) 編寫程式碼感覺就像來自純 JavaScript 的啟示。然後在我的第一份工作中，我開始使用 Angular 2，突然間 jQuery 感覺像是一個拖累。現在，React 是最酷的孩子，相比之下，Angular 感覺太複雜了。您可能會看到這是怎麼回事！ 對我來說，Svelte 是快速變化的 JavaScript 框架生態系統中的下一個進化步驟。用 Svelte 的方式編寫感覺很容易，你可以看出它的建立者 [Rich Harris](https://twitter.com/Rich_Harris)厭倦了現有框架要求您學習的所有煩人的抽象和必要的樣板程式碼。 現在你可能會問自己這個問題： ## 是什麼讓 Svelte 與眾不同？ 您可能聽說過 Svelte 出現在諸如 [前端框架的真實世界比較](https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1) 和 [State of JS Survey](https://2019.stateofjs.com/front-end-frameworks/) 等開發人員調查將其列為在捆綁包大小、性能、程式碼行數方面排名最好的框架之一以及最重要的開發者滿意度。 與流行的 [React](https://reactjs.org/) 和 [Vue.js](https://vuejs.org/) 庫相比，它們在執行時執行大量工作並使用一種稱為“虛擬”的技術DOM diffing”用於檢測變化，Svelte 作為建置步驟被編譯成無框架的 vanilla JavaScript，因此可以從大量程式碼優化中受益。 出於本能的猶豫，我起初將 Svelte 視為“只是另一個 JavaScript 框架”而不予考慮，也沒有費心去研究它。第二次聽說後，我想知道：Svelte 是炒作還是真的那麼好？我決定對它進行實戰測試並將其用於我的個人專案。 現在幾個月後，我可以給你一個明確的答案： ## Svelte 簡單、強大且優雅，您會愛上它！ 事不宜遲，以下是我向每位開始學習編程的新 Web 開發人員推薦 Svelte 的十大理由： ## 1. Svelte 元件易於理解 如果您以前從未見過 Svelte 語法，這就是一個簡單示例的樣子： https://gist.github.com/mhatvan/3630989d364e4020f26ebb96d2d7c332 與其他引入大量抽象概念、需要花時間學習和理解的前端框架相比，看到 Svelte 只是並排使用普通的舊 HTML、CSS 和 JavaScript，真是令人耳目一新。您可以通過其對初學者友好的語法查看並輕鬆辨識此處發生的情況。 ## 2.簡單寫簡潔的程式碼 正如您在上面的程式碼示例中看到的，您編寫的業務邏輯既簡單又易於閱讀。畢竟，您編寫的程式碼越少，錯誤就越少，對吧？ Svelte 的天才創造者 Rich Harris 在他的文章 [少寫程式碼](https://svelte.dev/blog/write-less-code) 中對 React 和 Vue.js 進行了一些很好的比較。根據他對編寫簡單的兩個數字相加邏輯所需的字符的檢查，React 元件通常比其 Svelte 元件大 40% 左右！ ## 3. 與標記語句的反應性 每當您希望根據其他變數更新和重新計算變數值時，您可以使用反應式聲明。只需在您想要響應的變數前面放一個美元符號，您就可以開始了！ https://gist.github.com/mhatvan/7e2f0fea362c79d64a34cb7e0c088453 每次單擊按鈕時，`count` 將增加 1，而 `doubled` 將知道 `count` 的值發生變化並相應地更新。從反應性的角度思考真的很有趣，而且寫起來感覺很好。 ## 4.開箱即用的簡單全局狀態管理 無需任何復雜的第三方狀態管理工具，如 [Redux](https://redux.js.org/) 或 [Vuex](https://vuex.vuejs.org/)。 您只需將一個變數定義為可寫/可讀存儲，並在任何以 `$` 符號為前綴的 `.svelte` 文件中使用它。 https://gist.github.com/mhatvan/710b6bb6df4ece7e9a5f53886eb2dd0d 在此示例中，我們檢查當前環境，它作為值存在於我們的商店中，並使用它來決定是否應顯示 cookie 通知。很簡單，不是嗎？ 使用 Svelte 存儲，您也永遠不必擔心內存洩漏，因為以 `$` 符號為前綴的存儲變數充當自動訂閱和自動取消訂閱。 ## 5. 內置可存取性和未使用的 CSS 檢查 Svelte 希望讓網路變得更美好，並通過程式碼中的有用提示幫助您。 每當您忘記將 alt 屬性放在 `<img>` 標籤上時，Svelte 都會為您顯示 `A11y: <img> 元素應該有一個 alt 屬性` 提醒。在 Svelte 中實現了一長串可存取性檢查，它們會提示您而不會成為麻煩。 為了使程式碼盡可能簡潔並避免遺留程式碼片段，只要在元件中找不到相應的標記，Svelte 還會為您標記未使用的 CSS 選擇器。 ## 6.元件自動導出 每當你想在元件 B 中使用元件 A 時，你通常需要先編寫程式碼導出元件 A，這樣它才能被元件 B 導入。使用 Svelte，你永遠不必擔心忘記導出， `.svelte` 元件始終默認自動為您導出，並準備好由任何其他元件導入。 ## 7. 默認情況下樣式是有範圍的 類似於 [CSS-in-JS](https://webdesign.tutsplus.com/articles/an-introduction-to-css-in-js-examples-pros-and-cons--cms-33574) 庫，Svelte默認情況下，樣式是有範圍的，這意味著 `svelte-<unique-hash>` 類名將附加到您的樣式，因此它們不會洩漏和影響任何其他元件樣式。當然，您可以選擇全局應用樣式，只需在它們前面加上 `:global()` 修飾符，或者如果您願意，也可以只使用 `.css` 文件。 ## 8. #await 塊 對於大多數 Web 應用程式，您將需要處理異步資料以向用戶顯示有用的統計訊息。 https://gist.github.com/mhatvan/2e44dc1ec402f477830f90bd77614f34 `{#await}` 塊的優點是您不必為已解決/拒絕的承諾定義額外的狀態，您只需在模板中定義內聯變數即可。 ## 9.傳遞道具的速記屬性 如果存在與變數名稱相同的 prop 名稱，我們可以將其作為簡寫屬性傳遞給元件，如下面的“{message}”。與使用 `message="{message}"` 相比沒有任何優勢，但更簡潔。 https://gist.github.com/mhatvan/9085f5330eeccdc2238e4f4e609b4f88 在上方，您可以看到根據 round 是真還是假將 class:round 屬性應用於按鈕。這很容易成為一個可重用的元件，您可以從外部傳遞 `round` 的值來有條件地決定元件的樣式。 ## 10.內置效果和動畫 Svelte 預裝了強大的效果模塊： - `svelte/motion` 效果，如補間和彈簧 - `svelte/transition` 效果，如淡入淡出、模糊、飛行、滑動、縮放、繪製 - `svelte/animate` 效果如翻轉 - `svelte/easing` 效果，如彈跳、立方體、彈性等等 Svelte 官方教程中有幾個示例，但我最喜歡[這個進度條示例](https://svelte.dev/tutorial/tweened)，因為它很簡單。 動畫是 web 開發的一個領域，您通常會在其中尋找外部依賴項來為您處理它，因此您可以開箱即用地使用它們真是太好了。 ## 不採用 Svelte 的合理理由 為了避免讓這篇文章聽起來像一篇冗長的狂熱帖子，以下是我迄今為止使用 Svelte 時遇到的缺點： ### `.svelte` 文件不能導出多個元件 一方面，我們受益於默認自動導出的 .svelte 文件，但這也意味著我們無法從單個文件導出多個元件。我不認為這有什麼大不了的，因為它會迫使您遵循最佳實踐來使用許多小的獨立元件編寫您的應用程式，這使它們易於理解和單元測試。 ### 一般模板語法 為了顯示條件邏輯，Svelte 使用類似於眾所周知的 [Handlebars](https://handlebarsjs.com/guide/builtin-helpers.html#if) 模板語法的語法。 https://gist.github.com/mhatvan/95cc1837441a272cb8422fcae24d91e0 這種編寫邏輯的方式我沒有遇到任何問題，但我更喜歡更簡潔的語法。 ### 使用 export let 在子元件中接收 props 當您想要將值從父元件傳遞到子元件時，您需要將一個值作為屬性傳遞，並使用帶有匹配變數名稱的 export let 來接收它。 https://gist.github.com/mhatvan/b67ceafb05d21c15b5782c068690d632 在現代 JavaScript 中，`export` 通常用作導出模塊的關鍵字和 `let` 聲明塊範圍變數，所以我覺得語法濫用現有關鍵字，但我習慣了它並且效果很好. ###開發速度 這與 Svelte 的開發體驗沒有直接關係，但您絕對應該知道，在財務支持方面，Svelte 無法（目前）與更大的和讚助的開源專案競爭，如 React、Angular、Vue.js 和其他專案，截至目前的貢獻者數量和受歡迎程度。 儘管如此，社區正在迅速發展，社區為 Svelte 建置的第三方專案列表也在不斷增加，這些專案可在 [Made with Svelte](https://madewithsvelte.com/) 上找到。開發 Svelte 相關工具的開發人員都是天才，您可以隨時在 [Discord](https://discord.com/invite/qa4pnmw) 頻道、[Twitter](https://twitter.com/sveltejs) 上尋求幫助) 或 [Reddit](https://reddit.com/r/sveltejs)。 Svelte 最近還加入了 TypeScript 支持，而且效果很好！ 我喜歡 Svelte 的易用性、較小的包大小和開發人員體驗等因素，因此我可以接受較慢的開發速度作為權衡。如果您總是需要盡可能快地合併最新功能，那麼您可能需要查看其他可用的 JavaScript 框架。 ### 缺少可用的工作 大多數公司仍在尋找對三大前端框架有經驗的開發人員，但也有各種知名的 Svelte 早期採用者，如 IBM、Apple、Philips、GoDaddy、1Password 或紐約時報，僅舉幾例.您可以在 [Svelte 網站](https://svelte.dev/) 底部找到大量使用 Svelte 的公司。通常，採用新框架需要一段時間才能出現在公司的工作機會中。儘管如此，Svelte 學習起來很有趣，許多開發人員喜歡使用 Svelte，尤其是在他們自己的個人專案或小規模應用程式中。 ## 結論 如果對初學者友好的語法、較小的包大小輸出和 Svelte 的瘋狂性能對您來說是一個不錯的選擇，我建議您開始使用 [Svelte 教程](https://svelte.dev/tutorial/basics)。該教程非常詳細，您可以快速了解該框架的強大功能。 在 JavaScript 框架的世界裡，事情肯定會快速變化，我希望你和我一樣相信 Svelte 擁有所有的優勢和潛力，可以讓它成為新的 #1 JavaScript 前端框架！ 您之前使用過 Svelte 嗎？你的經驗是什麼？ 在評論中告訴我，我很想知道。 感謝閱讀，希望您喜歡！ ## 有用的資源 - [Svelte 教程](https://svelte.dev/tutorial/basics) - [Svelte REPL](https://svelte.dev/repl) - [Rich Harris - 重新思考反應性](https://www.youtube.com/watch?v=AdNJ3fydeao) - [為什麼要苗條](https://github.com/feltcoop/why-svelte) - [為什麼 SvelteJS 可能是新 Web 開發人員的最佳框架](https://dev.to/bholmesdev/why-sveltejs-may-be-the-best-framework-for-new-web-devs-205i) - [為什麼我們從 React 轉向 Svelte](https://medium.com/better-programming/why-we-moved-from-react-to-svelte-f20afb1dc5d5) - [我喜歡 Svelte 的寫作風格](https://css-tricks.com/what-i-like-about-writing-styles-with-svelte/) - [我在 React 和 Svelte 中建立了完全相同的應用程式。這是差異。](https://medium.com/javascript-in-plain-english/i-created-the-exact-same-app-in-react-and-svelte-here-are-the-differences-c0bd2cc9b3f8) ## 正在尋找 Svelte 支持的伺服器端渲染解決方案？ 在使用 [Sapper](https://sapper.svelte.dev/) 接觸框架後，我是一個忠實的粉絲，一有機會就嘗試推廣 Svelte 之道。 如果您要建立一個網站並正在尋找合適的工具，我發表了一篇關於我迄今為止使用 Sapper 的經驗的文章，供您在此處閱讀：[“為什麼我為我的網站選擇 SapperJS，以及我做了什麼”到目前為止，我已經了解了該框架”](https://markushatvan.com/blog/why-i-chose-sapperjs-for-my-website-and-what-ive-learned-about-the-framework-so-遠的)。

0個讚   0留言 555瀏覽

求職疑問

請問各位，要拿到前端工程師、網頁工程師的offer，最低要具備那些能力呢？ 作品至少要有什麼，才能面試？

0個讚   6留言 682瀏覽

JavaScript 系列九：結語

恭喜你完成了一系列酷炫的元件 Quasar 是業界最頂尖、好用的 UI 元件包之一 你在這系列作業中，也順便學習了此元件包的用法，這在實務上非常有幫助 你甚至親手製作了其中一些基本的元件，讓你大致了解元件包背後的製作原理 像這些最基礎的 UI 元件，因為通用性很高、很常被重複用到、在多個地方到處使用，所以很適合製作成元件 --- 但是，在實務上，通常開發一個頁面，就製作一個 vue 檔案即可。除了基礎 UI 元件之外，並不會額外製作多少元件 因為頁面上很多看起來像元件的東西，其實就算拆出來，別的頁面也用不到、或根本無法使用 這種情況，其實也不用刻意要拆成元件，因為意義不大，說不定還會變更亂。切記：不需要為了元件化而元件化 當你發現頁面真的有點太複雜、你明顯感受到拆成多個元件會比較好維護的時候，再拆成元件就可以了 --- 翻閱 Vue 官方文件，你會發現 `Components In-Depth` 這個段落，你幾乎通通讀完了 有些我認為非必要、沒那麼常用的段落，就沒有指定讓你閱讀。你如果好奇的話，就自行把官網剩下的頁面翻一翻吧 必要的元件觀念，你都已經知道了，這些已足夠讓你參與團隊合作、與團隊一起開發應用程式了 但是在真正大型的專案，還需要引入一些進階觀念、生態系工具 這些會在後續的課程提到！ --- 消化、研究完本課程之後，我認為你已經具備入行前端工程師的基礎能力了！ 急著上班、找工作的同學，請參考我寫的文章： **給寫完 JavaScript 系列九的同學們：求職前的準備＆簡易指南** https://codelove.tw/@howtomakeaturn/post/k31dYx 再次恭喜你順利完成本系列轉職前端課程，祝你求職順利！ 有問題可以多多上來發問！

2個讚   1留言 571瀏覽

給開發者的 15 份好用 Cheatsheets 分享

隨著程式設計技術的快速發展，我們必須學習很多新東西。有些語言和框架非常複雜，您可能記不住所有的語法或方法。備忘單就是您易於存取的筆記了。 每當有人發現任何有幫助或有價值的事情時，我們都會做筆記。但是，您不需要對在書籍、研討會或文章中看到的每個細節都做筆記。 為了幫助您學習，我編寫了這份頂級備忘單列表。 - 原文出處：https://dev.to/ishratumar/15-must-have-cheatsheets-for-developers-1n92 --- ## HTML, CSS, and JavaScript Cheatsheet 您可以在此處找到 HTML、CSS 和 JavaScript 程式碼範例。每個例子都有一個解釋。像這樣的備忘單是我的最愛之一。 連結：https://htmlcheatsheet.com/js/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/msaqyef5m5nkk3op6oq8.jpg) ## JavaScript Cheatsheet 這是對初學者的 JavaScript 的完整、快速的介紹。值得看一下。 連結：https://quickref.me/javascript ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bbhfqsoinyj3142ix5z7.jpg) ## React.js Cheatsheet React 是最流行的 JavaScript 函式庫。對於 React 愛好者來說，這是一個簡單但有用的備忘單。一定要將它加入書籤，以便快速參考。 連結：https://devhints.io/react/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1i30duid59mry623p8ee.jpg) ## Cheatography 沒有比這更好的資源了。它有超過 5,000 個備忘單、修訂輔助工具和快速參考！每個人都可以在這裡得到他們需要的一切，而不僅僅是軟體工程師。在這裡，您可以找到有關 Web 開發、商業、遊戲、健康、數位行銷等的備忘單。 連結：https://cheatography.com/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9oqaebo7kjce31dc3klp.jpg) ## Java Cheat Sheets 此處簡要列出了教科書中使用最多的 Java 語言特性和 API。這是一個很好的快速參考。 連結：https://introcs.cs.princeton.edu/java/11cheatsheet/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0hfa25tmgbd263f0biwk.jpg) ## OverAPI Over API 是一個了不起的資源。對於大多數編程語言，您可以在此處找到備忘單。 連結：https://overapi.com/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dv049973s0b5jgk5jroy.jpg) ## Devhints 這裡有一些範例、連結、片段等，可讓您簡要了解該語言的基礎知識。在一頁上，您會找到詳細的說明。值得研究。 連結：https://devhints.io/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u3l5nr66wiwvruv1iyga.jpg) ## Gitsheet Git 是開發人員應具備的最重要的技能。這是一個非常簡單的 git 命令備忘單。如果您可以存取此 Gitsheet，則無需記住所有命令。 連結：https://gitsheet.wtf/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gcf2ah61erkjkzov13nw.jpg) ## Vue.js cheatsheet 此備忘單包含 Vue.js 的詳細程式碼片段和解釋。它包括與屬性、DOM、資料、事件、生命週期、API 等相關的片段。如果您正在尋找 Vue.js 的快速參考，請檢查一下。 連結：https://marozed.com/vue-cheatsheet/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c9uq2dcd2i3wxfhjef8b.jpg) ## HTML5 Canvas Cheat Sheet 可在此處找到 HTML5 Canvas 的程式碼示例，包括其元素、2D 上下文、線條樣式、顏色、陰影等。在此處了解有關 HTML 畫布的所有訊息。 連結：https://simon.html5.org/dump/html5-canvas-cheat-sheet.html ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2a8tz7vnxr0ec5huaylb.jpg) ## Web 開發人員的 SEO 備忘單 這個網站是關於 SEO（搜尋引擎優化）的。在最有效的搜尋引擎優化技巧中，這是最有用的快速參考之一。 Web 開發人員和軟體工程師也受益於輕鬆存取 SEO 技術標準。 連結：https://moz.com/learn/seo ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/izmc3x46eyc1rdvy90tf.jpg) ## Easing functions 通過使用緩動函數，您可以調整動畫的速度以建立各種效果，例如彈跳、減速、放大等。有關詳細訊息，請參閱此 Microsoft 文件。 此外，參數隨時間變化的速率由緩動函數指定。現實世界中的物體幾乎從不以一致的速度移動，也很少突然開始和結束。使用此頁面，您可以選擇理想的緩動函數。 連結：https://easings.net/en# ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/58cd8pj9bj0m44qd1cth.jpg) ## CSS3 動畫 這個網站有一些驚人的動畫效果，你可以在你的下一個專案中使用。 連結：http://www.justinaguilar.com/animations/# ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/75v2qv333wzgw8qo5019.jpg) ## CSS 網格 CSS 網格可能有點挑戰性。因此，很難記住它的所有屬性。您可以將此備忘單加入到您的書籤中以供快速參考。 連結：https://grid.malven.co/ ![圖片說明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m2zj6k2wrtb0pszd1u7n.jpg) --- 以上，簡單分享，希望對您有幫助！

5個讚   0留言 1,783瀏覽

JavaScript 系列八：前言

在 Vue 的學習旅程中 目前只學了官網 `Essentials` 的內容 坊間補習班，通常會接著教 Vue 元件、模組化開發方法、Vue 進階工具、Vue 生態系工具、以及 JavaScript 生態系各種工具 但是我認為，僅僅只是 `Essentials` 的內容，已經足以開發許多功能強大、好用的網頁應用程式、web 工具 在這次的課程，我們將開發一系列「非常有趣、實用」的應用程式 藉由這些練習，打好對於 Vue 理解的基礎，等於是紮穩馬步、練好內功 --- 我曾多次提過，身為工程師，常常要做一些沒做過的功能 需要自學能力、需要願意面對未知的信心與勇氣 這次的課程，我只會提供簡單介紹＆關鍵字 接著就直接提出作業規格，你需要自行研究如何完成作業 --- 這堂課要做的各種專案，內容有趣到「你在找工作的時候，能夠直接當作品集放上去」 請以這個目標為標準，把樣式做漂亮、UX 做完整！ --- 話不多說，讓我們馬上開始來寫 Vue 吧！

1個讚   0留言 514瀏覽

前 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) > 謹慎行事是最冒險的選擇。

0個讚   0留言 1,030瀏覽

JavaScript 系列七：結語

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

3個讚   2留言 467瀏覽

JavaScript 系列七：第5課 ── 學習 Vue 事件處理的寫法

## 課程目標 - 學習事件處理的寫法 ## 課程內容 來學一下事件處理的寫法 - https://vuejs.org/guide/essentials/event-handling.html 眼花撩亂沒關係，我已經多次告訴過你應該用什麼心態去面對 不用把這些東西看得太神奇，這些東西的背後，就只是你已經寫過的 html `onclick` 那些東西而已，只是多加一層「抽象化」，由 Vue 中介在中間管理 DOM 我們在寫 Vue 的時候，就是「完全不親自操作 DOM」了，通通交由 Vue 處理 我們負責專心管理 application state 就好，不用費心思去管理 DOM 用了框架，就不要再去直接操作 DOM，否則會跟框架起衝突、讓程式充滿 bug --- 有件事我必須說一下，就是 `@click` 後面可以放函式名稱，也可以直接執行函式 這個設計，實在很糟糕！我非常不喜歡！ ``` <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script> <div id="app"> <button @click="hello1"> hello 1 </button> <button @click="hello2('John')"> hello 2 </button> </div> <script> const { createApp } = Vue createApp({ methods: { hello1() { alert('hi'); }, hello2(name) { alert('hello ' + name) } } }).mount('#app') </script> ``` 以上範例，在 `@click` 裡面的內容，到底要不要加上小括號 `()`？ 乍看之下，根本無法理解。要翻閱文件，才發現原來兩種寫法都可以 我認為這違反了程式碼風格應該要 `保持一致性（consistency）` 的原則 Vue 這種彈性設計，讓程式碼變得令人困惑、難以理解 --- 再提一件事，Vue 的 template 中，雙引號的內容，到底是 `變數` 還是 `字串`？ ``` <button @click="greet">Greet</button> ``` 這個 greet 是函式名稱，是變數 ``` <div :class="{ active: isActive }"></div> ``` 這裡在雙引號內容，宣告 JSON 物件，所以是變數 ``` <template v-if="ok"> ``` 這裡是變數，變數型態大概是布林 ``` <div class="active text-danger"></div> ``` 這裡是字串 ``` <input :value="text" @input="event => text = event.target.value"> ``` 這邊的 `text` 到底是字串還是變數？ ``` <input ref="input"> ``` 這邊的 `input` 到底是字串還是變數？ 透過觀察可以發現，冒號開頭 `:`，或者小老鼠開頭 `@` 或者縮寫法 `v-` 開頭的，雙引號裡面是變數 不然的話，就跟普通 html attribute 一樣，雙引號裡面就只是字串而已 對於 Vue 這種彈性設計，我一樣「非常不喜歡」！ 當然，這些都是我個人主觀看法，一定很多人覺得又好寫、又彈性 這對於只想快速開發、懶得追根究底的新手，可能很方便 但在深入思考、試著搞懂資料型別、試著像資深工程師一樣思考的時候，會造成很多額外的困惑 --- 我想說的是，遇到這類問題，你就多試一下、多翻官網文件 然後不要覺得自己很笨、被框架嚇傻了 要知道複雜的工具，本身背後就代表多種不同的主觀偏好，然後那些主流觀點，可能真的不怎麼樣，所以不是你的問題 隨著更有經驗之後，你會能夠做出各種主觀的判斷、能夠比較各種設計的優劣之處 目前階段，你就先想辦法讓程式能跑、能完成任務就好了！ --- 再來學一下表單欄位內容的處理 - https://vuejs.org/guide/essentials/forms.html 在上個系列課程中，我們學過 data model + render function 的寫法 使用框架之後，則變成，就連表單欄位內容，也是 data model 的一部份 乍聽之下有點怪，其實，實際寫過之後，會發現還滿方便的！ ``` <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script> <div id="app"> <input v-model="username"> <button @click="greet"> Greet </button> <h1> {{ username }} </h1> </div> <script> const { createApp } = Vue createApp({ data() { return { username: "John Doe" } }, methods: { greet() { alert('Hello, ' + this.username); } } }).mount('#app') </script> ``` 正因為把 `欄位中目前輸入的值` 視為 `當前應用程式的狀態` 的一部份 所以可以隨時取得表單欄位內容，而不用像以前那樣，要透過 DOM selector 之類的，去找到元素、才拿到內容！ 一樣，表單欄位內容的取得，寫法多種，就挑順眼、簡單的來用即可 ## 課後作業 承接上一課的作業 這次要來開發「新增」與「刪除」功能囉！ 請在記事列表的上方： - 新增一個 `input` 來輸入「記事標題」 - 新增一個 `textarea` 來輸入「記事內容」 - 新增一個 `select` 來選擇顏色 - 新增一個「新增」按鈕，點擊之後，會新增記事 - 請將這些欄位的內容，放在 application state 裡面管理 然後，請在每則記事的裡面，新增一個「刪除」按鈕。點擊之後，會刪除記事 做出以上功能，你就完成這次的課程目標了！

0個讚   14留言 822瀏覽

JavaScript 系列七：第2課 ── 體驗一下 Reactivity 的效果與便利

## 課程目標 - 體驗一下 Reactivity 的效果與便利 ## 課程內容 來學 Vue 之中 Reactivity 的基本觀念 - https://vuejs.org/guide/essentials/reactivity-fundamentals.html 老樣子，大部份看不懂沒關係，稍微有個印象就好 記得之前的課程，每次更新完 state，你都要接著去執行 `render()` 函式嗎？ 所謂 Reactivity 就只是說：當你更新完 application state 之後，Vue 會自動幫你更新 UI 上的內容 就只是這樣，不要把它想得太複雜 ``` <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script> <div id="app"> 嗨，我是 {{ user.name }} <button @click="changeNewName"> 改名字 </button> </div> <script> const { createApp } = Vue createApp({ data() { return { user: { name: "John Doe" } } }, mounted() { this.user.name = "Frank" }, methods: { changeNewName() { this.user.name = "Kevin" } } }).mount('#app') </script> ``` 到 jsfiddle 跑跑看，看看畫面上出現什麼 `mounted` 是 vue 將畫面第一次載入之後，可以安排任務的地方，通常會放一些「系統初始化任務」 `@click` 跟 `methods` 那些，就只是操作事件的寫法而已，先照做就好 以上兩點，後面課程會詳談 --- 在 Vue 文件中，你會到處看到 `this` 這個關鍵字 要存取 application state，有時前面要加 `this.` 有時又不用 關於 `this` 關鍵字，它是一個 JavaScript 程式語言裡面過時又晦澀難懂的觀念 我不想細談，你也先不用研究。就先照做、程式能跑就好了 反正改天你真的遇到問題，大概知道要往這方向研究就是了 --- 接著來學 Vue 之中 Computed 屬性的觀念 - https://vuejs.org/guide/essentials/computed.html 老話一句，看不懂沒關係 雖然大家都說用這寫法，效能會比較好、程式碼會比較優雅 但實際上，我自己在好幾個專案，就完全不使用任何 `computed` 功能 一律通通只用 `methods` 來寫程式，根本也不會怎麼樣 --- 在整門系列課程，會常常像這樣，我叫你讀官網文件的很多內容 但我接著又會說，看不懂沒差，其中 XXX 根本沒用，其中 YYY 也沒必要用，只學 ZZZ 就好 這些都是我個人的主觀意見。如果你在網路上找資料，會看到許多工程師，有跟我完全相反的建議 這是軟體工程師圈子的常態，充滿各種主觀喜好、偏見，你要習慣一下 （如果你很好奇我是怎麼做出這些判斷的，請重新閱讀此系列課程，第一篇文章：前言，裡面的最後一段） 你不需要完全同意我的觀點，在研究過程中，如果你有發現比較喜歡的寫法，就直接用沒關係 如同我多次提醒過：只要能解決問題就好，你就隨便寫沒關係 各種做法細微的差異，將來有一天你會慢慢理解 ## 課後作業 承接上一課的作業 這一課來簡單體驗一下 reactivity 的效果就好 也就是簡單更新一下 application state 就好 請加入 `mounted` 函式，在裡面把「第一個記事」的內容更新為「多出門、到處走走、也要多運動」 完成之後，你會發現，你的春節行程安排，看起來積極多了～ 做出以上功能，你就完成這次的課程目標了！

0個讚   17留言 1,012瀏覽
歡迎發文
💡 記錄日常工作的實踐、心得
💡 發表對生活和職場的感悟
💡 針對感興趣的事件發表隨筆或者雜談
💡 詳細介紹你掌握的一門語言、一個技術，或者一個興趣
💡 或者，就直接把你的部落格搬到這裡（支援 API 可以撈）
熱門文章
🔥 53 個專案創意（從初級到高級）
🔥 用於建立 AI/ML 應用程式的最佳開發工具！
🔥 為開源做出貢獻將使您獲得新工作的機會增加 10 倍 🚀
🔥 我們在使用 Rust 建構 SaaS 時學到了什麼
🔥 精通程式碼審查：審閱者和 PR 創作者指南
  近期留言
熱門搜尋： email COM 學習 工作 1 使用 c C 題 研 . 2 with node.js 房 開發 前 ＣＳＳ ruby 4 專案 作為 ci JS 第一 % github 10 go vs 作業 20 id 前端 網站 git 50 分享 技術 Ai ui html 測試 api java 研究 AI 語言 資料庫 結構 工程師 ` app jav 系列 javascript Java 搜尋 COMPO vue 後端 react 架構 user for HTML Line 非同步 CSS Can 練習 React cn this 謝謝 作業分享 rest 聊天 遊戲 網頁 CD prisma create 新創 PHP .NET js Node GIT bi Github 分離 資料結構 promise 主題 AWS part console PYTHON ")
🛡️ 隱私及網站安全：本站註冊過程「不須提供任何個資」，只要 E-Mail 與帳密即可註冊，請安心註冊！線上付款過程使用「綠界科技 ECPay 」第三方專業金流廠商，全程在「綠界科技 ECPay 」網站進行付款程序，本站「不會紀錄任何信用卡資訊」，請放心付款、解鎖課程！您隨時可以透過 FB 粉專或者 Email 聯絡站長，請求刪除網站上的個人資料。