原文出處：https://dev.to/kumarkalyan/top-5-github-repositories-to-achieve-system-design-mastery-27n4 ## 簡介 🔥 本文包含前 5 個 GitHub 儲存庫的列表，可協助您掌握系統設計。 這些儲存庫主要包含與系統設計相關的教學課程、部落格、影片和案例研究 請務必存取這些儲存庫，探索內容，實施所學知識，如果可以的話做出貢獻，並給他們 ⭐ 來幫助他們成長。  ## 什麼是系統設計 系統設計⚙️是為特定係統設計架構、元件、介面和資料以滿足特定要求的過程。 在建立任何應用程式或系統之前，🏗️規劃系統如何運作、需要哪些資源、在哪裡部署、系統元件將使用哪些 API 以及如何擴充系統非常重要。因此，系統設計理念對於軟體開發人員掌握建置高效且可擴展的系統非常重要。 💯 ## 1\.開發者路線圖 [https://github.com/kamranahmedse/developer-roadmap](https://github.com/kamranahmedse/developer-roadmap) * 開發者路線圖 GitHub 儲存庫由 Kamran Ahmed 建置和維護，該儲存庫可以被認為是軟體開發的最佳手冊 * 它在 Git Hub 上擁有 255k 星和 684 名貢獻者。該儲存庫僅提供英文版本，它包含所有內容的結構化路線圖以及資源、指南等。 > [給開發者路線圖打 ⭐](https://github.com/kamranahmedse/developer-roadmap) --- ## 2\.系統設計入門 [https://github.com/donnemartin/system-design-primer](https://github.com/donnemartin/system-design-primer) * Sytem Design Primer GitHub 儲存庫由 Facebook（現為 Meta）的技術主管建立。這個儲存庫可以被認為是系統設計的聖經 * 它在 GitHub 上擁有 233,000 顆星，擁有 100 多個貢獻者，並提供多種不同語言版本。 > [給系統設計入門打 ⭐](https://github.com/donnemartin/system-design-primer) --- ## 3\.系統設計101 [https://github.com/ByteByteGoHq/system-design-101](https://github.com/ByteByteGoHq/system-design-101) * System Design 101 GitHub 儲存庫由 Byte Byte Go Hq 建置和維護，這是一個在系統設計面試中脫穎而出的平台 * 它在 Github 上有 39.2k 啟動次數和 14 個貢獻者。此儲存庫僅提供英文版本，是初學者的最佳儲存庫。該儲存庫包含有關通訊協定、CI-CD、架構模式、微服務、DevOps、雲端、Linux 等主題的有效指南。 > [給 system-design-101 打 ⭐](https://github.com/ByteByteGoHq/system-design-101) --- ## 4\.系統設計資源 [https://github.com/InterviewReady/system-design-resources](https://github.com/InterviewReady/system-design-resources) * Sytem Design Resources GitHub 儲存庫由 Interview Ready 建置和維護，這是一個為大型科技巨頭提供 Sytem 設計面試的平台。 * 它在 Git Hub 上有 11,400 顆星，有 8 位貢獻者。此儲存庫僅提供英文版本。它包括有關各種系統設計主題的案例研究、指南和視訊講座，包括視訊處理、叢集和工作流程管理、服務內訊息傳遞、訊息佇列反模式、服務網格、實用系統設計、分散式檔案系統、時間序列資料庫、速率限制、記憶體資料庫 - Redis 等等 > [給系統設計資源打 ⭐](https://github.com/InterviewReady/system-design-resources) --- ## 5\.系統設計 [https://github.com/karanpratapsingh/system-design](https://github.com/karanpratapsingh/system-design) * 系統設計 GitHub 儲存庫由 Curebase 的高級軟體工程師 Karan Pratap Singh 建置和維護。 * 它在 Git Hub 上有 21,100 顆星，有 9 位貢獻者。此儲存庫僅提供英文版本。它基本上是作者真書的免費版本。它共有 5 章，最適合剛接觸開發的初學者。 > [給系統設計打 ⭐](https://github.com/karanpratapsingh/system-design) 在那之前請繼續關注我的下一篇博客 
上一篇文章談了「同時上班＆接案＆創業」的簡單策略 我發現滿多人對於接案這塊比較感興趣，提了很多問題 我簡單分享一些心得＆建議 --- > 請問原po，在準備接案有想過：我的能力已經足夠接案，這種類似的想法嗎？ 這幾年因為 freelancer 的身份，在一些活動、場合會遇到各種領域的 freelancer 每次遇到這些新朋友，我都會問：你是如何開始的呢？ 我發現有 90% 的機率，得到的故事都是以下這樣： 「我工作幾年之後，在 XX 年的時候離職，想說休息一下，看看之後要幹嘛。這時候有前同事來問：他那邊有人在問誰能接案，能否幫忙？」 「我就先接下來，想說那做完這筆，之後再看要不要找工作。結果做完之後再休息一下，這時又有朋友來問，能不能接某個案子。」 「我就又接一個，然後再休息一下，反正不急著找新工作。就這樣加減接案，做一陣、度假一陣。過了幾個月、幾年之後，有一天發現：我好像可以一直這樣下去。」 所以根據我個人經驗＆觀察：根本沒有人會下決心說，我要從此離職，轉身變成一個全職 freelancer 都是工作轉換的空檔，自然發生的。如果案子沒了，那就開始找工作上班，幾年之後離職休息，上面的故事會再重複一次。 所以重點是：為什麼這些人在轉換的空檔，會有人來問？ 其實就是 1. 在工作上的表現不錯，同事、主管、合作廠商、親朋好友都覺得你值得信賴 2. 有稍微經營個人品牌，身邊的人稍微知道你是做什麼的，然後根據互動經驗覺得你「溝通能力」不錯，會讓人想合作 3. 你稍微有一點勇氣，能夠接受這種「休息一下，想想看之後要幹嘛」的狀態長達數個月之久，很多人在這狀態會很緊張，急著找新工作 然後一些有趣的事情，可能就會自然發生。當然你需要有一點點積極、願意擁抱未知，大概是這樣 --- > 我其實不清楚到底要做到什麼程度？業界常用的必備工具有沒有掌握？發生問題解決辦法能不能處理？ 不論是工作、接案，基本上就是養成「挑戰能力範圍之外一點點」的習慣 不要超出能力太多，會被壓力擊倒、會開天窗、你誠信會出問題 不要完全做已經熟悉的事情，這樣沒有進步，久了會有點無聊 就做超出能力一點點的事情，常常這樣的話，久了自然會有把握＆經驗 這需要時間累積，沒有捷徑、沒有秘訣 --- > 哥有推薦接案的案源嗎 根據我的經驗，你在台灣註冊任何接案平台，或者去 FB 社團搶案子之類的，案件內容＆報酬都會「有點悲劇」 這沒辦法，平台化的東西，大家就是殺價競爭、紅海市場廝殺，比誰更樂意壓榨自己 你就算用英文搜尋，找國外接案平台，狀況也差不多，沒有好到哪去 所以我不推薦任何案源，我推薦你經營個人品牌。雖然有點丟臉，好像讓親朋好友看到你在老王賣瓜 但是行銷就是這樣，你多少要推銷自己一點，不然看起來一點自信都沒有，誰又能放心付個高價錢給你做案子呢？ 那怎麼經營個人品牌？參考我後面的回答 --- > 希望能分享關於案源品質管控的部分（怎麼避開爛專案）🙏 如果你很外向、具有那種油條的業務性格，那你就多多跟各種客戶談生意，多多談判，累積經驗就行 如果你很內向、不具有那種談判性格，實在很怕踩雷，那我建議你：只跟你喜歡的人合作 在 LINE 上打字、Email 往來的時候，感覺對方連話都講不清楚嗎？那你們實在溝通方式有差，建議婉轉拒絕吧 用 LINE 語音，或者視訊軟體開會，感覺對方有點城府，你有一點怕他嗎？那你們做人處事原則大概很不一樣，建議婉轉拒絕吧 實在很想避開爛專案，那就只跟你覺得「跟這個人當朋友好像也沒問題」的案主合作吧！ 當然工作機會，會減少很多，但是，你跟案主互相折磨、互相為難、互告上法院的機率也會減少很多 --- > 想問有建議其他職業的做法嗎？ 抱歉我比較熟悉寫程式領域 但其他職業的話，我覺得經營個人品牌總是不會錯 我滿建議大家 1. 部落格 2. Podcast 3. YouTube 4. 短影片 選擇一種格式來創作，分享一些東西，目標不用高，就花幾年時間，試著經營出 1,000 粉絲就好 分享什麼？結合你的興趣 or 專業，弄點「好笑的有趣的」或「有知識技術含量的」或「能幫讀者省錢或避免踩雷或有利益可圖的」內容，就這些即可，總是會有讀者，因為看到根本賺到 這過程會學到行銷、推銷、品牌、定位，很多很多商業基本知識，零收入沒關係，就是一種商業練習 千萬不要眼高手低、整天空想、整天焦慮沒完沒了，想要搞很大，過了好幾年還是 100 粉絲都沒有 慢慢來吧，但務必要有點進度、養成進步的習慣 以上，簡單幾點分享，希望對你有幫助
https://youtu.be/I7dwJxGuGYQ ## TL;DR - 在使用 useContext 時，一定要將其包裝成 custom hook - [好讀版本](https://hackmd.io/@jason60810/rklVqNUh2) - [React 官方文件新增了 TypeScript 使用專文](https://react.dev/learn/typescript?fbclid=IwAR3Pgkr8xpS48Vwa0ADo3oagaAPKX1q05jHhtbXH8ltV8MKwa8FAvePoXPU) - [英文版本](https://jason60810.hashnode.dev/always-use-a-custom-hook-for-context-api-not-usecontext-react-context-api-typescript) ## 資料夾結構 ( 使用 next app route )  ### theme-context.tsx 一定要加上 `use client`，因為 useState 只能在 client component 運作 ， **特別注意，就算這裡加了`use client`，所有的子層還是 server component (預設)**  ### layout.tsx 加上 provider 之後，下面所有的子層都可以拿到值，不用用 prop 一個一個傳下去  ### page.tsx  ### logo.tsx 1. 因為 useContext 要在 client component 運作，所以要加上 `use client`。 2. 當使用 useContext 時，一定要引入 ThemeContext，用起來很麻煩 3. 因為 ThemeContext 預設是 null，所以當不是在 provider 裡使用 `useContext` 時 ( Logo component )，會發生錯誤，因此需要先確認有 context  舉例:不是在 provider 裡使用 `useContext`  ### 創建 custom hook  ### 使用 custom hook 現在引入 ThemeContext 和處理錯誤的問題，已經抽離到 custom hook 中  ### 加上型別 1. React.ReactNode，可以接受 JavaScript primitives ，如果只想要是 jsx 可以使用 React.ReactElement ( [react 官方文件](https://react.dev/learn/typescript#typing-children) ) 2. `type Theme` 可以讓 `useState` 在 get 和 set 時，可以使用正確的型別，例如:當想要 `setTheme('blue')` 時，會報錯，因為 `type Theme` 只有 'dark' 和 'light' 3. 在給予 createContext 型別時，可以利用 ts 的 union 讓 createContext 知道可能有 null 這個型別 ( [react 官方文件](https://react.dev/learn/typescript#typing-usecontext) ) 
距離大學畢業已經三年，我大學主要修php 還留著PHP7 新觀念php7+MySQL+AJAX的教科書 但那時候還沒學精 想繼續鑽研PHP但我英文不好想先從中文書看 請教是要先買php新版本的PHP8還是繼續原來那本(PHP7)弄懂好? 雖然目前應該是前端JS趨勢但我仍然想先把PHP學精在學前端 可能我對PHP語法比較熟悉吧 雖然高中學過JS 但JS都遺忘了...
各位好，我是在google搜尋CSS討論區時碰巧逛到這裡的， 如果有違規之處請多多包涵 我在Mdn網站查找關於Block formatting context的資料 (https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Block_formatting_context) 在這邊提到創建條件： The root element of the document (). 和BFC的特性： With on the , everything inside that container participates in the block formatting context of that container, and floats will not poke out of the bottom of the element. 我在實作時發現如果要把body創建成BFC，要如下： ``` <style> html { overflow: auto; } .top { overflow: auto; border: 3px solid blue; } .bfc1 { width: 100px; height: 300px; float: left; background-color: gold; } </style> </head> <body class="top"> <div class="bfc1">bfc1</div> </body> ``` 這樣才能實現用藍色框框把浮動一同框起來 我的疑問是，既然"The root element of the document"，為什麼我還需要overflow: auto ? 並且，html和.top二者的overflow: auto只要缺一個，就無法創建BFC， 從Mdn、W3C和各個BFC教學文章我都找不出這樣結果的原因， 但我英文差，也有可能漏掉重要的資訊 另外想問BFC值得把它搞清楚嗎?我已經花太多時間在這上面了...
# !important 的正確使用時機 !important 會強制打斷正常的 css 修改邏輯權重 在我十年的工作經驗中，只有兩種情況會這樣用 第一個是寫 utility css class 的時候 例如 `.text-center` `.text-right` 這種輔助功能性的 css class 比方說參考 bootstrap 的相關文件 https://getbootstrap.com/docs/5.3/utilities/api/ 這些 css class 看命名就知道有一種「這元素就是要這樣式」的感覺 所以加上去會蓋過其他所有 css class，但是這沒問題，不會造成維護的困擾 別人一看就知道是 utility class 在作用 --- 第二個情況是，當你確認自己在對某元素進行「最終維護」的時候 也就是幾乎結束的專案，最後一次幫客戶修改，你很確定有些元素之後不會再擴充、再修改了 這時有些樣式會偷懶 !important 亂加一通 改完就不想管了 # 當同事濫用導致 code 難以維護 實務上來說，除了上述兩種情況之外，使用 !important 都是「完全不可接受的」！ 當專案內出現大量 !important 時，會讓 css 難以維護，甚至是無法維護！ 就我個人經驗來說，這情況非常慘，是一種「重大技術債」 也就是代價很高，會開始不斷支付利息，然後很沒效率 # 現階段的務實處理 這個情況的出現，代表圖隊內有人「經驗不足」或者是「缺乏責任感」 需要適當反應、溝通，避免未來再出現這情況 第一種辦法是 相關樣式通通重寫！這個成本很高，但專案若還需要長期維護很久，可能必須這樣 第二種辦法是，讓相關 PM 與資深工程師知道這個情況的存在 他們會可以理解：相關 code 修改起來的時間，難以預期、難以估計！分配安排上，要考量到這點，甚至避免相關樣式的改動 總而言之，這情況，算是相當「雷」了 工作上，千萬別當濫用 !important 的人 # 最後補充 在程式設計領域，各種套件、協定、API 在設計的時候，有些功能會提供給大家用，但希望大家盡量少用 這種時候，通常會讓函式名稱、變數名稱、或者是相關命名「長得很奇怪」 比方說突然有一個「全英文大寫的命名」、「很冗長的函式命名」、「用奇怪的底線前後包住的命名」、「使用奇怪的特殊符號的命名」 這些就是「知道你可能必要時刻會需要用，但是非常不鼓勵使用」的 API，所以故意讓你打字累一點、而且會察覺到自己在幹嘛 !important 就是屬於這類東西，打起來很怪很累，所以當然不應該濫用 --- 以上，簡單分享
身為網站工程師，對於 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 網頁後端開發，吸收得更好 嘿嘿，讓我們馬上開始吧！
## 課程目標 - 學會 git 初始化 ## 課程內容 這次的課程，主要是透過每課作業練習實務情境 關於 git 的基本安裝，網路上有非常多教學，請根據你的作業系統，自己找一套安裝方法 不論是使用「終端機」讓你輸入指令，或者是有 GUI（圖形化介面）讓你點擊 UI 執行指令，都可以 關於 git 的基本觀念，學起來可深可淺，我只會簡單說明工作上需要的觀念 覺得黑箱或者想深入研究的話，可以上網搜尋相關關鍵字，深入理解 git 底層機制 --- 在要使用 git 追蹤的資料夾內，首先要使用的指令是 ``` git init ``` 這會初始化資料夾環境，讓 git 開始追蹤資料夾內所有檔案變化的一舉一動 其實不用想得太神奇，這指令只是在資料夾內建立一個隱藏的資料夾 `.git/` 而已（你可以根據你的作業系統，想辦法找到這個隱藏的資料夾） 後續的 git 指令，背後都是去查看 `.git/` 的內容而已 --- 初次使用 git，打指令可能會被要求設定名稱信箱，這些要用來記錄在 git 歷史訊息內，辨識操作者 ``` git config --global user.name "您的名稱" git config --global user.email "您的信箱" ``` --- 接著來試用兩個指令 首先是查看目前的工作狀態 ``` git status ``` 因為還沒有任何程式碼，所以應該會顯示「沒東西」的中文或英文訊息 接著來查看歷史編輯紀錄 ``` git log ``` 一樣會顯示「沒紀錄」的中文或英文訊息 這兩個基本指令，對於學習非常有幫助 在每次打任何 git 指令之前與之後，都打打看這兩個指令，可以幫助認識當前追蹤狀況 ## 課後作業 請開一個新資料夾，用 git 初始化這個資料夾 接著分別輸入 `git status` 與 `git log` 應該會看到 git 回應「沒東西」與「沒紀錄」的訊息 完成以上任務，你就完成這次的課程目標了！ --- 交作業的方法： 可以把 `git status` 與 `git log` 顯示的文字內容複製，貼到留言區 也可以直接截圖視窗內 `git status` 與 `git log` 的內容，上傳到留言區
我是web工程師，從剛開始學MVC就深感困惑： - 怎麼每個地方說的MVC都不太一樣？ - 有些文章講的MVC，跟我正在用的MVC，怎麼像完全不同的東西？ Model、Controller、View三者到底如何互動？真是一個定義不明、含糊不清的名詞。 這讓我研究了很久。最後，發覺它是一個嚴重的誤會。 這個誤會導致了學習和溝通上的代價，請聽我娓娓道來。 # 哪些是MVC？ web領域，不論前端(client-side)、後端(server-side)、不論什麼程式語言，幾乎所有framework都自稱、或被認為是「MVC」。 有哪些呢？ 前端：Backbone.js、AngularJS、Ember.js… 後端：Ruby on Rails、CodeIgniter、Laravel、Django… 真的是這樣嗎？它們全都是MVC嗎？ # MVC是什麼？ 該怎麼定義MVC呢？ 我們先來看看維基百科怎麼說： > MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。 嗯，跟大家說的一樣。我們繼續往下看： > 模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 看起來有些陌生，整段描述跟你的web開發經驗完全不同，對嗎？ 最大的疑問來自這句： > 那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式）） 後面直接叫你去看觀察者模式(observer pattern)。 問題來了：你有在view跟model之間實作observer pattern嗎？ 也就是說，你的Model在資料改變之後，能主動通知View嗎？ 沒有的話，就根本不符合MVC的定義。 # 全都不是MVC？ 我們現在發現MVC有observer pattern這個必要條件了。 事情嚴重了起來。 client-side framework或許能夠符合這個條件。 以Backbone.js官網範例來說，我們可以這樣在Model上註冊： ``` book.on({ "change:title": titleView.update, "change:author": authorPane.update, "destroy": bookView.remove }); ``` 它的確實作了observer pattern。 但server-side framework呢？ 你的Model如何能在發生改變之後去「主動通知」View？ 你平常開發web哪有用到server push的技術？ 所有server-side framework，從Ruby的Rails；PHP的CodeIgniter、Laravel；到Python的Django，他們全都不是MVC。 它們實作的，是昇陽電腦在1998年提出的「Model 2」。 # 什麼是Model 2？ Model 2名氣不大，在維基百科連中文條目都沒有。我們看看英文條目怎麼講： > Model 2 is a complex design pattern used in the design of Java Web applications which separates the display of content from the logic used to obtain and manipulate the content. > In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. 它針對web而設計，讓controller進行必要的程序之後，將資料塞進view去呈現。 正是我們server-side框架在做的事情。 也就是說，server-side目前只能實作Model 2；client-side可以實作Model 2，也可以實作MVC。 # 巨大的代價 web工程師最常碰的就是client-side跟server-side框架。結果整個業界把MVC跟Model 2混為一談，都說成MVC。 這帶來了什麼後果呢？ MVC變成一個從初學者到業界工程師，永遠說不清楚、下不了定義的名詞。 這件事對於學習和討論，造成了非常巨大的成本。（參考下方的Q1和Q2） # 那該怎麼辦？ 下次有初學者詢問「什麼是MVC」的時候，怎麼回答才不會害他回家之後「越查資料越混亂」？ [Rails is not MVC](http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html)的作者提出了三種解決方法： > 第一個方法是聲稱MVC已經從原始意義改變了，Model 2也可以稱為MVC。如此一來，我們可以用「傳統MVC」或「真MVC」來描述原始的MVC。這是現在普遍的作法，但我不認為改變定義是一個好主意。這幾乎是越搞越亂。 > 第二個方法是到處推廣Rails其實是Model 2，MVC就留給…MVC吧。這很困難，但至少能保持定義不變。 > 第三個是直接忽略這些混亂。管它那麼多？ 我個人覺得MVC這個詞已經沒救了，不管怎麼解釋都會帶給別人混亂。 當對方同時學習client-side跟server-side時，混亂更強烈。 我選擇這樣回答： 「MVC有分很多種喔！網路上全部沒寫清楚，你一定看不懂。 沒關係，你只要知道View可以抽出來就好。 C跟M先別管，你先隨便瞎搞吧。」 --- # Q&A ## Q1: 怎麼可能各大server-side framework都搞錯？ 確實有人腦袋清醒得很，它就是Python的Django。 Django的官方文件內根本沒有「Controller」這個名詞。 看看Django官網的常見問題： > Q: Django似乎是一個MVC框架，但你們把Controller命名為「View」，把View命名為「Template」。你們幹嘛不用標準命名啊？ > A: （前略）…如果你真的很想要一個縮寫，你就說Django是一個MTV框架吧。Model、Template、View。這樣分比較有道理些。 Django不想變成搞亂MVC的幫凶，只好委屈地又發明了一個名詞「MTV」。 ## Q2: 那client-side框架有受影響嗎？ 有。client-side框架也必須為MVC巨大誤會浪費一堆時間解釋。 看看Backbone.js官網的常見問答： > Backbone跟「傳統MVC」的關聯何在？ > …我們來比較一下Backbone跟像是Rails這種server-side MVC框架的差別… Backbone實作了「傳統MVC」，卻被迫用「傳統MVC」來描述server-side的Model 2，然後花一堆篇幅解釋。 ## Q3: 知道Model 2的存在又如何？我現在依然一片混亂！ 沒錯，Model 2跟MVC都用到Model、Controller、View三個名詞，所以看起來類似。 但是，我們不應該再把時間花在思考「MVC怎麼如此難懂」。 我們討論的重點，應該是「如何分辨MVC與Model 2」、「在server-side如何實作Model 2才漂亮」、「在client-side實作MVC跟Model 2的優劣分別何在」。 ## Q4: 好，那你現在回答我，「如何分辨MVC與Model 2」？ OK，就讓我拋磚引玉一下。 分別談談Model、View、Controller吧： ### View - Model 2: 不具有行為，只是等別人塞資料進去的模板（template）。 - MVC: 具有監視Model的行為，並以此去改變呈現（presentation）。 兩種View有沒有很像？跟張飛、岳飛一樣像。 看看Backbone.js官網的View範例。你server-side的View哪是長這樣？ ``` var DocumentRow = Backbone.View.extend({ tagName: "li", className: "document-row", events: { "click .icon": "open", "click .button.edit": "openEditDialog", "click .button.delete": "destroy" }, initialize: function() { this.listenTo(this.model, "change", this.render); }, render: function() { ... } }); ``` ### Controller - Model 2: 接收請求與參數，轉交給Model處理，再把結果（最新的資料）塞進View。 - MVC: 接收請求與參數，轉交給Model處理。沒其他事了。 兩種Controller有沒有很像？跟小狗、熱狗一樣像。 MVC的View跟Model 2的Controller可能還比較像一點。（隨便說說，千萬別這樣類比。） ### Model - Model 2: 接收Controller傳來的參數，回傳結果。 - MVC: 接收Controller傳來的參數，將結果通知View。 Model倒是有些類似。 總之，Model 2跟MVC除了三個部份的名字一樣之外，沒什麼關聯了。 ## Q5: 我決定徹底鑽研MVC跟Model 2的定義了。給我一些延伸閱讀？ http://www.ithome.com.tw/node/77330 http://andrzejonsoftware.blogspot.tw/2011/09/rails-is-not-mvc.html https://docs.djangoproject.com/en/1.7/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names http://backbonejs.org/#FAQ-mvc https://r.je/views-are-not-templates.html --- ##一些社群的看法（2015-2-28） 附上幾個社群的連結，裡面有許多很棒的討論。 https://www.facebook.com/groups/javascript.tw/permalink/600136880087654/ https://www.facebook.com/groups/199493136812961/permalink/759391387489797/ https://www.facebook.com/groups/pythontw/permalink/10153760201638438/ https://www.facebook.com/mosky.liu/posts/10203964969186383 http://www.ithome.com.tw/voice/94877
初學者接觸OOP，幾乎都會有以下疑惑： 我到底為什麼要學OOP？OOP解決了什麼問題？書上這些範例就算不用OOP也寫得出來吧？ 然後覺得「繼承」、「多型」、「介面」、「抽象類別」等等的名詞很難，覺得OOP很難。 其實這些名詞雖然重要，但對新手來說，本來就很難在一開始就搞懂。 建議先搞懂「資料跟行為在一起」是什麼，以及它的好處在哪，就可以了，其它的慢慢來。 # 什麼叫做「資料跟行為在一起」？ 假設我們在開發一個「中英文互助學習網」，鼓勵中文人士與英語人士登入討論。 這個系統的貼文、留言功能會顯示「發文日期」。 發文日期要根據使用者的註冊身份（台灣人、英語人士）顯示不同格式（台灣格式、西方格式）。 下面就以這個日期格式的功能舉例說明「資料跟行為在一起」是什麼意思。 ## 作法一：直接硬寫（不OOP、資料跟行為混在一起） 初學者通常會用最簡單、也最直覺的作法，直接硬寫出來，像這樣： ``` <?php $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否顯示台灣格式 */) { # 轉換成這樣 2016.6.2 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$year.$month.$day"; } else { // 西方格式 # 轉換成這樣 6/2/2016 $arr = explode('-', $postDate); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; echo "$month/$day/$year"; } ``` 這種寫法的資料（日期）跟行為（轉換成各種格式）混在一起。 它的優點是寫起來很簡單，缺點則有兩個： * 日期格式的邏輯會重複出現在很多地方，整段code會到處重複出現 * 整段code大概會塞在 `div` 或是 `span` 的裡面，導致它跟HTML混在一起，很亂 ## 作法二：自訂函數（不OOP、資料跟行為沒混在一起） 為了解決作法一遇到的問題，聰明的初學者很快就想到可以用「自訂函數」！就像這樣： ``` <?php function localFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$year.$month.$day"; } function englishFormat($date) { $arr = explode('-', $date); $year = $arr[0]; $month = $arr[1]; $day = $arr[2]; return "$month/$day/$year"; } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 if (/* 判斷是否為台灣人身份 */) { echo localFormat($postDate); } else { // 英語人士身份 echo englishFormat($postDate); } ``` 這種寫法將行為（轉換成各種格式）用自訂函數給獨立出來，也大幅改善了作法一遇到的問題。 對小型的網頁程式來說，這招非常好用，不但開發快速、簡單，還漂亮地將資料跟行為拆開。 但是程式規模變大之後，為了將各種行為拆出來，會寫出很多自訂函數，類似這樣： ``` ?php function localFormat($param) { // blah blah ... } function englishFormat($param) { // blah blah ... } function someTask($param) { // blah blah ... } function anotherTask($param) { // blah blah ... } function otherTask($param) { // blah blah ... } //... ``` 於是又衍生出三個問題： 1. 像localFormat、englishFormat這樣的函數名稱意義模糊，看不出是處理日期、人名，還是什麼東西的格式 2. 這些自訂函數各有不同的行為，全部放在一起顯得很亂，應該要想辦法分類、整理這些函數 3. 像localFormat、englishFormat這樣的函數，只吃特定格式的參數，最好能跟某種資料的形式綁在一起，以後要改程式時，能讓相關的資料跟行為一起被看到 問題1很好解決，只要替函數名稱加前綴字變成dateLocalFormat、dateEnglishFormat就行了。 問題2也很好解決，只要多開幾個檔案，把相關的函數放進同一個檔案就行了。 問題3就很棘手，資料跟行為拆開之後，如何在概念上又找方法整理在一起？ ## 作法三：使用class（OOP、資料跟行為在一起） 正是這些處理資料、整理行為的問題，導致了OOP的誕生： ``` <?php class Date { public $year; public $month; public $day; public function __construct($date) { $arr = explode('-', $date); $this->year = $arr[0]; $this->month = $arr[1]; $this->day = $arr[2]; } public function localFormat() { return $this->year . '.' .$this->month . '.' . $this->day; } public function englishFormat() { return $this->month . '/' .$this->day . '/' . $this->year; } } $postDate = '2016-06-02'; # 假設資料庫取出來的發文日期長這樣 $date = new Date($postDate); if (/* 判斷是否為台灣人身份 */) { echo $date->localFormat(); } else { // 英語人士身份 echo $date->englishFormat(); } ``` OOP的寫法，一次解決了前述三個問題： 問題1 => 現在從類別名稱就可以知道底下方法的意義了 問題2 => 現在相關的函數都整理進同一個類別底下成為方法了 問題3 => 現在資料的形式都統一在constructor處理一次，之後不管新增多少方法都不用處理資料了 這就是所謂的「資料跟行為在一起」，也正是OOP的核心概念。 利用這種方式整理程式碼、寫出一個又一個的類別，可以大幅提昇程式碼的品質。 # 結論 上述的作法一跟作法二並沒那麼糟糕，但確實會帶來一些問題。 對於小型的網頁程式來說，可能還算夠用。 但是隨著程式規模變大，如果將概念上相關的資料跟行為整理在一起，會很有幫助。 實務上也可以先從作法二開始寫起，直到發現某些資料跟行為關係密切，再拉出來整理成類別即可。 至於很多OOP教學會提到的「繼承」、「多型」、「介面」、「抽象類別」等等名詞，一時搞不懂沒有關係，你可能實務上也暫時用不到。之後找時間慢慢搞懂它們的用途就好。 光是知道「將資料跟行為放在一起」的技巧，就能夠開始寫OOP程式碼了。 （註：本篇文章的程式碼純屬教學用途。實務上PHP已經有DateTime類別可以使用，或是用更漂亮的Carbon類別。） ## Q&A Q1：我常常設計一些類別，只有資料沒有行為，聽起來OK嗎? 不OK，這很不OOP，而且沒意義。 乾脆直接用關聯式陣列去表示那些資料就好。 Q2：我常常設計一些類別，只有行為沒有資料，聽起來OK嗎? 這個要看情況，不一定。 但唯一可以確定的是，這種作法很不OOP。 因為OOP的核心是「資料跟行為在一起」。 這也是為什麼你會看到有人明明寫了類別、用了物件，別人卻說「這不夠OOP」。 然後你又會看到像JavaScript這樣連「類別」關鍵字都沒有（ES5以前），卻能夠寫出很OOP程式碼的關係。 判定的標準都是一樣的，而且也就只有這麼一個標準：資料跟行為有沒有在一起。 Q3：一個類別包含的概念是越大越好，還是越小越好？ 不一定。不過我們從作法一到作法三的過程，有一個明確目的：希望讓程式碼更好懂。 如果聲稱一個類別包含的概念很大（例：設計LanguageHelpWebsite類別，用來代表「中英文互助學習網」需要的所有功能），那會把幾乎整個網站的所有行為跟資料都放進去，成為所謂的God object。它可沒有讓程式碼更好懂。 相反地，如果聲稱一個類別包含的概念很小（例：分別設計LocalDate、EnglishDate類別），雖然意義可能更精準了，但用一整個Date類別的概念去思考，程式碼會更容易理解，也就是所謂的內聚性（Cohesion）更高。 所以要替OOP就是「資料跟行為在一起」加個但書： 要以方便理解程式為前提，將資料和行為放在一起。
## code spell checker  不管是自己的英文程度太差，還是粗心大意，把英文字拼錯是家常便飯， 這款擴充套件就是來幫助你的救星！ 使用code spell checker馬上會幫你標出奇奇怪怪的單字， 讓你確定沒有不小心把1跟l搞錯，就debug一整天的那種尷尬事件！ ## live server  寫前端最需要的就是看到畫面٩(｡・ω・｡)，و 每次如果都要自己在網址列找到檔案的位置才打開html， 那實在是太沒有工程師的效率了，簡直荒唐！！ 當然要使用這款live server來架，馬上就可以看到自己的前端畫面， 而且儲存之後自動更新，根本神器。 ## material icon theme  沒有什麼其他的，純粹就是好看！ 裝了這款之後可以讓icon變得比較不一樣，整天都跟程式為伍， 當然就是要追求好看的圖圖。 ## prettier - code formatter  超級讚的排版好物，懶得自己縮排了啦！就靠這款prettier， 讓你的程式從原本醜醜的排版， 最後，變成人類也能看懂的正常程式，必裝神器之一！ ## 補充有人整理的 ### github  [專案點這邊](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 前端開發必備安裝推薦 ## 心得 以上都是寫程式過程中會發現的需求，自然會想要找擴充來安裝，提升效率、美觀， 利用這些擴充功能，寫程式的體驗真的變得很舒服呢(๑•́ ₃ •̀๑)。 未來如果有什麼新的，也會持續補充，也歡迎大家分享討論唷～～
## 課程目標 - 能夠運行 Vue 元件 ## 課程內容 我們一樣讀官網文件就好 先來讀元件基本觀念 https://vuejs.org/guide/essentials/component-basics.html 再來讀註冊元件的方法 https://vuejs.org/guide/components/registration.html 再來讀元件的檔案格式 https://vuejs.org/guide/scaling-up/sfc.html 我鼓勵你習慣去讀英文，但實在不行就讀中文沒關係 https://cn.vuejs.org/guide/essentials/component-basics.html --- 在我的課程中反覆說過很多次 官網文件中各種內容很多，大部份看不懂沒關係，稍微有個印象就好 很多內容學了，其實根本實際上也很少用到 留個印象，遇到問題大概知道去哪翻閱就可以 整個程式設計師生涯，就用這種態度即可，沒問題的 --- 很多時候，甚至一知半解，也沒關係，根本不重要 舉個例，官網有時候會這樣寫 ``` <ButtonCounter /> ``` 有時候會這樣寫 ``` <button-counter></button-counter> ``` 官網有說明，分別在什麼時候，建議哪種寫法比較好 老實說，那些說明，連我都看不太懂，我也不認同官網的建議 我建議你就隨便寫，能跑就可以了 上過我前面課程的話就知道，我對 Vue 的許多設計細節，充滿意見、不認同 但是這個行業就是這樣，大家都充滿主觀看法，工具本身也充滿主觀看法 這些很正常，並不妨礙你成為一個專業的程式設計師 反正，框架的背後，就是會轉換成你在系列一～六學過的那些：DOM 操作、事件處理、狀態管理，就這樣而已 ## 課後作業 請使用官方的元件試玩工具：Vue SFC Playground https://sfc.vuejs.org/ 這一課我們來試著匯入元件就好 - 請建立 `Header.vue` `Main.vue` `Footer.vue` 三個元件 - 元件內容分別顯示 `I am header!` `I am main!` `I am footer!` 就好 - 在 `App.vue` 之中匯入以上元件 做出以上功能，你就完成這次的課程目標了！
## 課程目標 - 能夠運行 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 那樣花式的排版（那種叫瀑布流排版，很難寫） 做出以上功能，你就完成這次的課程目標了！
## 課程目標 認識變數作用域 認識函式的不同寫法與特性 ## 課程內容 來認識一些程式語言觀念與名詞 ``` <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 - 你會宣告兩個區域變數，分別記錄兩個輸入的值，接著用來進行四種計算，才能完成此功能 --- 做出以上功能，你就完成這次的課程目標了！
第1課 ── autosize 套件 https://jsfiddle.net/birdie2019/j69s8vdc/38/ 第2課 ── vanilla-lazyload 套件 https://jsfiddle.net/birdie2019/401xa29h/104/ 第3課 ── Chart.js 套件 https://jsfiddle.net/birdie2019/upLn7j1b/6/ 第4課 ── jQuery 套件 原生JS: https://jsfiddle.net/birdie2019/ebax340f/2/ jQuery: https://jsfiddle.net/birdie2019/eabr2jh3/7/ 第5課 ── xdan/datetimepicker 套件 https://jsfiddle.net/birdie2019/y7mzws6r/18/ 第6課 ── kenwheeler/slick 套件 https://jsfiddle.net/birdie2019/k6vgcod0/52/ 第7課 ── TinyMCE 套件 https://jsfiddle.net/birdie2019/m8dforLn/23/ --- 心得分享： 以上套件都蠻有趣的，尤其是Chart.js，在學習過程中一直讚嘆這套件好厲害！ jQuery我覺得不錯，程式碼可以少打很多，但還是覺得學好JS很重要。 另外讀第三方套件文件內容都是英文，一開始讀有點措手不及，有些東西看不懂和不了解其意思，但動手試試看觀察變化，試個幾次就明白了，請勇於嘗試會發現很好玩。
我英文很OK 所以資源滿豐富的 這點我很幸運也很感激 只是我點子也比較多 常常想要實作超出我能力的東西 例如串後端 資料庫 弄出會員系統 發送email驗證 一些實作python的爬蟲 因為我也常常搜尋人家前輩的作品 心有所向 就很嚮往也做出那些東西 (例如這種論壇 就是我的目標之一 之前一直很期待有這種程式的討論社團.....版主實現我的願望 ) 可是後端我完全不懂 還不會 目前還在專注練習html+css+js的小作品 心中的焦慮感太強了...導致往往都沒法動手 畢竟我未來要搞的作品就是專案 有時候小作品太小 都沒什麼動力練 可是自己實力又還不到.... 挫折˙真的滿滿啊... 感謝版主開這個論壇 讓我抒發... 學習規劃真的不容易...
## 課程目標 認識並且能實做 modal 元件 ## 課程內容 modal 中文叫「互動視窗」元件，也有人叫「燈箱」或者「視窗」 這是幾乎所有網站都會用到的元件 台灣各大媒體網站常見的「蓋板廣告」，就算是一種「視窗」 各大社群網站，逛一逛就跳出「視窗」強迫你登入 點擊照片或者貼文，以前常常會開啟新網頁，現在常常設計成打開「視窗」直接就可以看內容 modal 跳出時，通常會將整個背景變成半透明黑色或白色，來讓視窗內容更顯眼 並且 modal 會有按鈕可以關閉 請上網搜尋 `popup modal ui` `lightbox ui`，四處觀摩一下業界常見的設計 --- 要寫出這種視窗的效果，其實 css 的部份還比 js 的部份難一些 請上網搜尋 `燈箱 css` `popup modal css` `popup modal css` 了解各種不同的寫法與技巧 半透明背景遮罩的英文術語叫 `black overlay` 請上網搜尋 `css 黑色半透明遮罩` `full page black overlay css` 了解各種如何做到此效果。不過，若是做不出來，這個效果也是可以省略不做 ## 課後作業 請使用 https://jsfiddle.net 用以下 html 為基礎（你可以稍微修改），接著寫出 css 與 js 的部份 ``` <button onclick="loginModal()">點我登入帳號</button> <hr> <button onclick="postModal()">點我新增貼文</button> <div class="modal" id="login-modal"> <div>帳號：<input type="text"></div> <div>密碼：<input type="password"></div> <hr> <button class="btn-close">關閉</button> </div> <div class="modal" id="post-modal"> <div>標題：<input type="text"></div> <div>內文：<textarea>
## 課程目標 學會基本的陣列取值 能從 html 元素中，得到用戶選取的內容 ## 課程內容 這課先來學一點陣列觀念 ``` var colors = ['red', 'orange', 'yellow', 'green']; ``` 中括號 `[]` 包起來就是宣告一個陣列，並記錄到 `colors` 變數中。此陣列內容是四個字串。 陣列索引從 0~3，因為在程式設計中，索引通常是從 0 開始而不是從 1 開始。 在陣列後方，使用中括號加上索引，就可取得陣列內容的值 ``` alert(colors[0]); alert(colors[1]); ``` 這兩個 alert 會顯示出陣列中第一個元素、第二個元素，馬上到 jsfiddle 試試看就會清楚了！ --- 在前幾課，我們學會了取得 `<input type="text" />` 這種元素內容的方法 文字輸入框是最常用到的網頁功能，除此之外，下拉式選單也很常用 ``` <select id="my-colors"> <option value="red">鮮豔的紅色</option> <option value="orange">美麗的橘色</option> <option value="yellow">亮眼的黃色</option> </select> <button onclick="showColor()">Click me</button> ``` 像這樣的選單，如何取得用戶選取的值呢？ ``` function showColor() { var menu = document.getElementById("my-colors"); var index = menu.selectedIndex; alert(index); var value = menu.options[index].value; var text = menu.options[index].text; alert(value); alert(text); } ``` 首先一樣用 `document.getElementById` 找到我們的選單元素 選單元素這種物件，會有 `.selectedIndex` 屬性來代表目前選中的索引 我們用 alert 先把索引跳出來看一下 同時，選單元素這種物件，會有 `.options` 屬性來代表其中的 `<option>` 元素，並且會是一個陣列 這個陣列裡面，通通都是物件，一個物件代表一個 `<option>` 元素 每個 `option` 物件，又有 `.value` 屬性可供存取，以及 `.text` 屬性可供存取 工程師可以根據需要選擇 `.value` 或 `.text` 來使用 我們在寫 html select 元素時，通常會在 value 放英文單字，然後 text 放清楚的中文說明 請在 jsfiddle 試試看上面的範例，實驗一下、玩玩看，就會清楚了！ ## 課後作業 接續前一課的作業，你的「線上下單」頁面，目前會顯示訂單資訊，方便顧客確認 除了顧客名稱之外，這課的作業要加強下單功能、顯示更多訂單資訊 --- 除了輸入客戶名字的欄位之外，請用 `select` 元素加上一個選單，讓用戶可以選擇服裝的分類：男裝、女裝 接著再用 `select` 元素多做一個選單，讓用戶可以選擇服裝的類型：外套、上衣、下身 這樣顧客就知道這間「成衣批發工廠」，有提供哪些商品批發了！ 接著要將顧客選擇的內容，顯示在訂單資訊裡面 類似這樣： ``` －－－－－－－－－－ ｜您的訂單 ｜ ｜顧客姓名：ＸＸＸ｜ ｜服裝分類：ＸＸＸ｜ ｜服裝類型：ＸＸＸ｜ －－－－－－－－－－ ``` ＸＸＸ的地方預設是空白，在點擊訂購按鈕之後，跳出招呼訊息之後，就把ＸＸＸ改為顧客輸入、選擇的內容 請替這個訂單資訊區塊加一些 css 屬性，弄得漂亮一點 做出以上功能，你就完成這次的課程目標了！
身邊很多朋友工作幾年之後，從非本科轉職寫程式 主要方法大概三種：報名實體課程、報名線上課程、買線上課程自學 ## 報名實體課程 資策會、程式補習班，都屬於此類 需要本人實際到教室，由老師上課 這種課程通常需要耗時數個月，費用會在新台幣十萬上下 好處是有同學一起、有同儕壓力、有問題可以當面問老師、厲害的老師可以現場掌握全班學習狀況 壞處是每個人學習速度不同，有人跟不上、有人覺得教太慢 這種學習法，需要碰運氣，如果遇到優秀的老師，學習氛圍、效果，都會非常好 但是，就我觀察課表，以「全端工程」為主打的課程，進度通常非常倉促，能真正消化的學生非常少數 多數人只是糊裡糊塗把功課、專案做完，畢業後其實還是很沒信心、一頭霧水 （只專注在特定領域開發的課程，狀況比較好一點） 主因是基礎知識還不夠熟，就開始大量學習工具用法 我建議這種狀況，不要對自己起太多懷疑，保持耐心，養成做紀錄的習慣 覺得一知半解的地方就把問題記錄一下，每天都整理出一些問題 整理出一張問題清單，找時間請教別人、或是上網慢慢研究 多數回答，聽完之後應該還是聽不懂，沒關係，先放著 有搞懂的問題就劃掉，一段時間之後，會更清楚程式設計整體觀念，也會更有信心 重點是要知道自己具體是哪些細節不了解、一知半解，才有補充＆複習＆研究的方向 ## 報名線上課程 坊間許多業者提供這類服務，會有大量教學影片，個人自己找時間看完即可 並且會幫大家分組、需要一起做專案、會有助教指導 好處是每個人可以自行抓節奏，並且費用便宜許多，通常不到實體課程四分之一 如果是組合式的課程商品，就更好了，可以先購買一些基礎課程，滿意才買更多 壞處是需要紀律，督促自己去學習，需要積極、主動一點 通常我是推薦朋友，去買這種課程，因為財務、時間風險，比實體課程小很多 真的找不到相關業者提供課程、有找到政府補助、有找到特別優秀的實體課程名師，才去找實體課程 ## 買線上課程自學 不分學期、沒有分組專案、沒有助教 基本上就是找一些影片自己來看 這種課程國外比較多，需要英文能力好 好處是費用非常便宜，通常幾百元～幾千元就有很不錯的內容 甚至有 freeCodeCamp 這種完全免費的課程 壞處是需要英文能力，並且很多只是小課程，不是完整的一套多課程規劃，會不確定自己的進度到哪了 如果有親戚朋友是業界軟體工程師，比較好，因為可以跟他請教、確認自身進度、以及確認自己求職條件如何 ## 結論 半路出家不容易，我鼓勵大家把學習想成是一個「逐漸清晰」的過程 看過電腦讀取大張高清圖片的樣子嗎？先是模模糊糊的馬賽克，接著一塊一塊慢慢變清晰，最後才是變成完整的美麗圖片 學習會有點類似這樣，一開始到處模模糊糊的沒關係，保持耐心，逐步提高各處的解析度即可 只要先有一整張模糊的圖片即可。不需要執著在圖片一個角落，覺得這塊不清楚，就不能往下走 更千萬不要因為圖片模糊，就覺得「我果然不適合寫程式，放棄好了」，這絕對是搞錯重點 以上，簡單建議分享，希望對你有幫助！ --- 您在坊間補習班的學習經驗如何呢？歡迎在留言處跟大家分享您的個人學習經驗！
# 第6課 課程目標 正式在自己電腦上寫網頁 不再需要依靠jsfiddle來寫網頁 # 第6課 課程內容 前五課都是用jsfiddle來學習，先跳過了環境設定的問題。 這次的課程要練習正式在自己電腦上寫網頁。 其實，用記事本就可以寫網頁。只要把副檔名存成 .html 就可以了。 請閱讀這份教材： [HTML Editors](http://www.w3schools.com/html/html_editors.asp) 不習慣看英文，可以改看這裡： [HTML 编辑器](http://www.w3school.com.cn/html/html_editors.asp) 接著要回頭學一些基本知識，這些知識在前幾課我們先跳過了： [HTML Introduction](http://www.w3schools.com/html/html_intro.asp) [HTML Head](http://www.w3schools.com/html/html_head.asp) 不習慣看英文，可以改看這裡： [HTML 简介](http://www.w3school.com.cn/html/html_jianjie.asp) [HTML 头部元素](http://www.w3school.com.cn/html/html_head.asp) 全部唸完之後，請試著用計事本在自己電腦上做出一個網頁檔，然後用瀏覽器去打開它 # 第6課 作業 這次的作業要做所謂的 landing page landing page 是網站的門面，給客戶的第一印象 請參考下列網址，了解更多 landing page 的概念 [實例網站解說什麼是 Landing Page ？](https://cola.workxplay.net/what-is-an-landing-page/) 本次的作業內容如下： 假設你打算在近期內創業，請替你的公司建立一個漂亮、有效的 landing page 如果想不到的話，就請替你目前任職的公司，建立landing page 作業條件如下： 請尋找並下載一張大圖片，當作網頁的背景圖片 參考圖庫：https://unsplash.com/ 請建立一個獨立的 css 檔，不要在 html 檔內寫任何一行 css 試著用計事本在自己電腦上做出這個 landing page，然後用瀏覽器去打開它 完成這些，你就完成這次的課程目標了！
你的轉職路上，還缺少一份自學作業包！寫完這幾包，直接拿作品去面試上班！
本學院另有附設一個 LINE 新手發問＆交流群組！歡迎加入討論！
