前言
這陣子開始了一個自己的 side project，叫做程式導師實驗計畫，希望能在四個月內把學生培養成找得到工作的工程師。
而 Git 身為工程師的必備技能之一，用 Git 來交作業也是合情合理的一件事，可以先培養學生們對 Git 的熟悉程度。
但問題來了：要怎麼用 Git 交作業？
前陣子正在重構公司的專案，試了一些東西之後發現自己對於 React 的渲染機制其實不太了解，不太知道 render 什麼時候會被觸發。而後來我發現不只我這樣，其實還有滿多人對這整個機制不太熟悉，因此決定寫這篇來分享自己的心得。
其實不知道怎麼優化倒還好，更慘的事情是你自以為在優化，其實卻在拖慢效能，而根本的原因就是對 React 的整個機制還不夠熟。被「優化」過的 component 反而還變慢了！這個就嚴重了。
因此，這篇文章會涵蓋到下面幾個主題：
為了判別你到底對以上這些理解多少，我們馬上進行幾個小測驗！有些有陷阱，請睜大眼睛看清楚啦！
關注 RxJS 已經好一段時間了，最早知道這個東西是因為 redux-observable，是一個 redux 的 middleware，Netflix 利用它來解決複雜的非同步相關問題，那時候我連redux-saga都還沒搞懂，沒想到就又有新的東西出來了。
半年前花了一些時間，找了很多網路上的資料，試圖想要搞懂這整個東西。可是對我來說，很多教學的步調都太快了，不然就是講得太仔細，反而讓初學者無所適從。
這次有機會在公司的新專案裡面嘗試導入redux-observable，身為提倡要導入的人，勢必要對這東西有一定的瞭解。秉持著這個想法，上週認真花了點時間再次把相關資源都研究了一下，漸漸整理出一套「我覺得應該可以把 RxJS 講得更好懂」的方法，在這邊跟大家分享一下。
在開始之前，要先大力稱讚去年 iT 邦幫忙鐵人賽的 Web 組冠軍：30 天精通 RxJS，這系列文章寫得很完整，感受得出來作者下了很多功夫在這上面。看完這篇之後如果對更多應用有興趣的，可以去把這系列的文章讀完。
好，那就讓我們開始吧！
之前在 Hacker News 上面看到了這一篇文章：Payment Request API — Now Being Implemented in All Major Browsers，大意就是 Payment Request API 這一個東西將會在主流瀏覽器上面被實作出來。
在這之前，我完全沒有聽過這個東西，完全不知道它在做什麼。但經過我稍微研究之後，發現這個原來是網頁支付介面的未來。
這篇的原文（你走你的陽關道，我走我的獨木橋：前後端分離）是我之前在 iT 邦幫忙鐵人賽的其中一篇文章，寫完之後有陸陸續續收到一些回饋，就想說可以重新整理一下這篇文章，讓它變得再更清楚一點。
如果你有以下疑惑的話，這篇文章非常適合你：
最近剛好上到 CS50 Week3，這一週的主題是：Algorithms，裡面介紹到了幾種經典的排序法，像是選擇排序、泡沫排序、插入排序以及合併排序。
我覺得身為一個軟體工程師，大概一輩子都脫離不了排序了，畢竟這是經典演算法之一嘛！與其每次要面試之前都凌亂的準備，不如現在就整理出一篇，紀錄一下各個排序法的心得，幫自己做個統整。
因此，這一篇將利用 JavaScript 來實作各個經典排序演算法。
這次實做的排序法都會是由小到大排序，並且為了方便起見，每一個排序法「都會直接更改原本的 array」，但如果你不想改到原本的也很簡單，在每一個的函式最開頭加上：arr = arr.slice()複製一份原本的即可。
還有，因為文章裡面比較難放動畫，所以我只能放一些圖片而已，若是想搭配視覺化演算法一起學習的話，我非常推薦 VISUALGO，這網站絕對會讓你對排序的理解度更上一層樓。
2021-05-25 補充：文中所提到的在 target phase 會依照加上 event listener 的順序觸發，在新版的 Chrome 似乎更改了這個行為，請參考：Chrome 89 更新事件触发顺序，导致99%的文章都错了（包括MDN）
（補充：感謝 othree 前輩的指點，指出這其實是在講 DOM 裡面事件傳遞的順序，因此把標題以及內文修正，原標題為：JavaScript 的事件傳遞機制：捕獲與冒泡）
今天為大家帶來的內容是 DOM 裡面的事件傳遞機制，而與這些事件相關的程式碼，相信大家應該不太陌生，就是addEventListener, preventDefault跟stopPropagation。
簡單來說，就是事件在 DOM 裡面傳遞的順序，以及你可以對這些事件做什麼。
為什麼會有「傳遞順序」這一詞呢？假設你有一個ul元素，底下有很多li，代表不同的 item。當你點擊任何一個li的時候，其實你也點擊了ul，因為ul把所有的li都包住了。
假如我在兩個元素上面都加了eventListener，哪一個會先執行？這時候呢，知道事件的執行順序就很重要。
另外，由於某些瀏覽器（沒錯，我就是在說 IE）的機制比較不太一樣，因此那些東西我完全不會提到，有興趣的可以研究文末附的參考資料。
前陣子在研究跟 HTTP Cache 有關的一些東西，看得眼花撩亂，不同的 Header 愈看愈混亂，像是Pragma, Cache-Control, Etag, Last-Modified, Expires 等等。找了許多參考資料閱讀之後才有了比較深刻的理解，想說若是從一個比較不同的角度來理解 Cache，說不定會比較容易了解這些 Header 到底在做什麼。
在之前查的資料裡面，很多篇都是逐一解釋各個 Header 的作用以及參數，而我認為其實參數講多了容易造成初學者混淆，想說怎麼有這麼多奇怪的參數，而且每一個看起來都很像。所以這篇文章嘗試一步一步藉由不同的問題來引導出各個 Header 使用的場景以及出現的目的。還有，因為這篇是給初學者看的，所以不會講到所有的參數。
其實關於 Cache 這一部分，很多網路資源的說法都不太一樣，如果碰到有疑義的地方我會盡量以 RFC 上面寫的標準為主。如果有錯誤的話還麻煩不吝指正，感謝。