近幾年前端框架大放異彩，許多新手才學沒多久的 JavaScript，就直接學習三大框架了（雖然 React 不是框架，但整個生態系其實就跟框架沒兩樣，因此我覺得歸類在框架也不是不行）。
而這三大框架通常都是拿來寫 SPA（Single Page Application）用的，我一直認為在學習這些框架前應該要具備一些基礎知識，尤其是對於前後端的理解，否則一定會遇到很多不知道從何解起的問題。
因此，本文舉出一個我自己曾經碰過，學生也常常跑來問我的問題當作範例，大家也可以先想一下自己能不能回答出這個問題：
假設今天我有個 SPA，搭配某些 router 的 library 來實作路由，所以
/list會連到列表頁，/about會到關於我的頁面。可是奇怪了，當我把 SPA 上傳到 GitHub Pages 之後，首頁是好的，我從首頁進去
/list也是好的，可是當我在/list重新整理的時候，卻顯示 404 not found，這是為什麼呢？
要回答這個問題，必須先來複習一下前後端相關的網路基礎知識。
這是一系列共三篇的文章，我稱之為 Session 與 Cookie 三部曲。系列文的目標是想要由淺入深來談談這個經典議題，從理解概念一直到理解實作方式。這是系列文的最後一篇，三篇的完整連結如下：
第一篇以白話的方式來談 Session 與 Cookie，全篇沒有談到太多技術名詞；第二篇直接去看 Cookie 的三份 RFC 來理解到底什麼是 Session，也補齊了一些 Cookie 相關的知識。而這一篇則是要深入 Session，一起帶大家看看三種不同的 Session 實作方式。
這三樣分別是 Node.js 的 Web 框架 Express、PHP 以及 Ruby on Rails。會挑選這三個是因為他們對於 Session 機制的實作都不同，是我覺得很適合拿來參考的對象。
這是一系列共三篇的文章，我稱之為 Session 與 Cookie 三部曲。系列文的目標是想要由淺入深來談談這個經典議題，從理解概念一直到理解實作方式。這是系列文的第二篇，三篇的完整連結如下：
前幾天的時候我在 Medium 上發了這篇文：Medium 中文寫作者追蹤人數排名與不專業數據分析，內文是我用 Node.js 寫了一個簡單的 Medium 爬蟲之後整理出來的數據。
在原本那篇文章裡面有簡單提到爬蟲的資料來源，但是對技術的部分沒有太多著墨。事實上，在寫 Medium 爬蟲的時候其實踩了一些坑，與其教大家寫一個 Medium 爬蟲，不如讓大家跟我一起走過這些坑，盡可能地還原我當初在寫這個爬蟲時碰到的障礙以及解決方法，我覺得這樣會更有趣一點。
因此，這篇就是用來記錄我寫這個 Medium 爬蟲的經過，其中也會有點教學的成份在，所以看完之後你應該也能夠寫出一個類似的爬蟲，或至少你看到 source code 的時候不會一頭霧水。
雖然說最後寫出來的是這個跟使用者資料有關的爬蟲，但我一開始其實是先從文章列表開始的，因為那時候剛好有一個需求，想要把自己的文章全部爬下來。
會有這個需求是因為 Medium 內建的功能其實滿爛的，你很難找到一個作者 po 過的所有文章，或者是說很難一目瞭然。所以早期的文章除了透過 Google 以外，是很難被找到的。
所以我後來就手動做了一個文章的索引，自己整理了以前發過的所有文章。但是身為工程師，這明明就是一件可以寫程式來做的事啊！所以想嘗試看看能不能先寫一個文章列表的爬蟲。
有許多的 HTTP Status Code 大家都耳熟能詳，例如說 404 Not Found、500 Internal Server Error 以及 200 OK 等等。
在眾多的狀態碼之中，有一個擺明就是來搞笑的：418 I’m a teapot。
但你知道嗎，它不在 HTTP 標準裡面，所以根本不是標準的 HTTP 狀態碼。你可能會想說：「我都看過 RFC 了，怎麼會不是？」。但那份 RFC 也跟 HTTP 一點關係都沒有，不過滿多人都沒注意到這點。
我一開始也沒注意到這件事，以為 418 是 HTTP 標準的其中一部分，一直到 2017 年 8 月時有人在 Node.js 的 GitHub 發了一個 Issue：418 I’m A Teapot 我才注意到。
Issue 裡面提到希望能移除對 418 的 support，而發起 Issue 的作者在被人告知 Go 也這樣搞的時候，也跑去 Go 發了一個 Issue。
那時候這起要求移除 418 狀態碼的事件其實引發了不小的風波，而大部分人其實是反對移除這個狀態碼的。甚至還有人做了一個 save418.com，想要拯救 418。
前陣子花了點時間研究一下整件事情的來龍去脈，在整理的過程中也發現無論贊成或是反對，這其中的理由都很值得我們去思考，因此在此總結成一篇文章跟大家分享。
前陣子我為了幫自己的學生們更熟悉 HTTP 以及 API 的串接，寫出了一個小遊戲：Lidemy HTTP Challenge，需要根據每一關的說明取得正確的 token，一共有十五關，前十關基本，後五關進階。
經過了一些朋友的測試之後，慢慢調整、改善，最後讓學生測試發現反應都不錯，於是就在前端社群正式對外公開這個遊戲，讓大家也能一起參與。
如果你還沒玩過，那強烈建議你不要看這篇文章，因為這篇文章會破壞你遊玩的興致（大概就跟電影爆雷一樣）。建議可以先去玩一下，等全破了再回來看這篇文章，會得到一些不同的收穫。
接下來我會講一下這個遊戲誕生的歷程以及每個關卡的設計。
最近又開始了自己的教學計畫，第一期的時候寫了這篇：利用 Github Classroom 加 Travis CI 打造改作業系統，第二期寫了這篇：AWS Lambda + GitHub API + Google Sheet = 自動化簽到系統，都是利用現成工具來快速湊出符合自己需求的系統。
而第三期開始前我希望課程能有個討論區，讓學生們可以在上面很方便地問問題。一直以來都是用 Slack，但 Slack 最大的缺點就是免費版會吃訊息，很多不錯的資訊被洗掉就覺得滿可惜的，希望能有個論壇或是討論區之類的地方會比較好。
在兩年前我也寫過一篇：自架論壇的解決方案：flarum, github issue, nodeBB, discourse，研究了幾套方案，最後選擇 GitHub Issue。因為最簡單、最方便，但最大的缺點是學生好像不太習慣，因為左看右看上看下看其實都不像是個論壇。
前陣子有個學生跑來問我一個問題，說他在寫 React 的時候分不清楚 keyPress 與 keyDown 這兩個事件，還有 keyCode 跟 charCode 這兩個東西，有時候拿得到值，有時候卻拿不到，覺得十分困惑。
我原本以為是 React 做了一些處理，所以去看了一下原始碼。後來發現 React 的確有做一些處理，但實際上這個問題跟 React 沒什麼關係，而是 keyPress 跟 keyDown 這兩個原生的 JavaScript 事件本來就有差異。
所以他碰到的問題跟 React 一點關係都沒有，只是對這部分的事件機制不熟而已。
儘管如此，能夠藉由一個實際的問題來參考一下 React 的實作還是件很不錯的事，而且 React 的註解寫得很好。
因此，這篇會先帶大家來看這兩個事件的不同，最後再來看 React 裡面怎麼做一些處理。
在 JavaScript 裡面，有一個令新手十分頭痛，老手也不一定能完全理解的主題：「this 是什麼？」。身為一個以 JavaScript 當作吃飯工具的前端工程師，我也被這個問題困擾了許久。
我原本以為我這輩子都不會寫有關於 this 的文章。
原因有兩個，第一個是講解 this 的文章已經超級無敵多了，而且每一篇都寫得很不錯，之前看完 What’s THIS in JavaScript ? 系列之後覺得講解的很完整，若是沒有把握自己能夠講得更清楚或是以不同的角度切入，似乎就沒必要再寫一篇文章；第二個原因是若是想要「完全」搞懂 this，要付出的成本可能比你想像中要大得多。