關注 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 上面寫的標準為主。如果有錯誤的話還麻煩不吝指正，感謝。
老實說 JavaScript 的原型鍊一直是我很懼怕的一個主題，理由很簡單，因為真的不太好理解。光是一堆名詞跟錯綜複雜的關係就可以把你搞瘋，例如說prototype, __proto__, constructor, Object.prototype, Function.prototype, new等等。
可是呢，這又確實是 JavaScript 很重要的一部分，而且是面試的必考題，就算現在不懂，以後遲早有一天要把它弄懂，不然的話永遠都沒辦法把自己的技術能力往上提高一個檔次。
有關原型鍊的文章你可以在網路上搜到一大堆，每一篇的理解方式都不太一樣，有些直接搬出一大堆專有名詞，嚇都把你嚇死了。而我也是一直到最近，看了幾篇我覺得切入角度比較不錯的文章，才真正對原型鍊有比較深刻的理解。
就趁著現在這個機會，讓我們多瞭解一點 JavaScript 的原型鍊吧！這篇適合對 JavaScript 有一點概念但又不是很清楚的人觀看，如果文章中有講錯的地方，也麻煩不吝在評論中指出，感謝。
幾個禮拜前我在工作上碰到了一些跟 Cookie 有關的問題，在這之前，我原本想說：Cookie 不就那樣嘛，就算有些屬性不太熟悉，上網找一下資料就好了，哪有什麼跟 Cookie 有關的難題？
然而事實證明我錯了。我還真的碰到了一個讓我解超久的 Cookie 問題。
相信看到這邊，很多人應該躍躍欲試了，那我就先來考一下大家：
什麼情形下，Cookie 會寫不進去？
像是語法錯誤那種顯而易見的就不用說了，除此之外你可能會答說：寫完全不同 domain 的 Cookie。例如說你的網頁在 http://a.com 卻硬要寫 http://b.com 的 Cookie，這種情形當然寫不進去。
或者，你可能會回答：不在 https 卻想加上 Secure flag 的 Cookie。
沒錯，像是這種情形也會寫不進去。
除了這些，你還能想到什麼嗎？
如果想不太到，那就聽我娓娓道來吧！