前言

前幾天的時候我在 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，要付出的成本可能比你想像中要大得多。

閱讀更多

前言

以 CSS 架構方法來說，主流的大概可以分成三個：OOCSS、SMACSS、BEM，這些架構的提出都是為了讓 CSS 更好維護，這幾個的介紹以及差異可以參考 @arvinh 寫過的 淺談 CSS 方法論與 Atomic CSS。

但我們今天要談的不是上面提到的這三種，而是另外一種相較之下沒那麼主流（但好像有慢慢流行的趨勢），而且很少人第一眼看到就會贊同的方法：functional CSS。

閱讀更多

前言

前幾天看見 Redux 作者 Dan Abramov 寫的這篇：Things I Don’t Know as of 2018，看了之後其實滿有感觸的，前些日子也在思考這種跟自信相關的事情，也做了個簡單的總結，寫下了兩年過後，我能夠被稱為資深工程師了嗎？。

無獨有偶地，這幾天也看到一些 2019 年更新版的學習路線圖，下面依舊有些留言在說「怎麼前端要學那麼多東西」、「怎麼學的完」、「前端好難啊」等等之類的，雖然這兩件事看似沒有關連，但我覺得其實是相關的。

閱讀更多

前言

在兩年前我寫了這篇一個資淺工程師年末的自我省視，內文主要是檢視自己那年學到的東西以及抒發心得感想，並提出一些對於自己職涯發展上的疑問。

標題之所以是打「資淺」工程師，是因為那時覺得連資深的邊都沾不上，所以用了資淺這個字來形容自己。

兩年過去了，職稱從工程師變成資深工程師，甚至還再往上變成了 Front-end Team Lead。雖然職稱本來就不代表一切，但我認為它至少「代表著什麼」，你到了那個位子就必須負起責任，如果覺得自己能力未及，就必須盡力去追趕，直到自己能擔起那個責任為止。

這篇會先回顧我這兩年來的發展，最後再分享一些自己的心得感想。

在這之前一樣先預祝各位讀者新年快樂！

閱讀更多

前言

請先原諒我用了一個比較聳動的標題，因為實在是想不到還有什麼標題好下，最後選擇了一個可能比較有爭議的標題，但能利用這樣的標題激起討論也是滿有趣的，何況我說這話也是有根據的。

在觀看此篇文章之前請先看過上一篇：我知道你懂 hoisting，可是你了解到多深？，因為文章內容有部分相關，所以必須先有 Execution Context 以及 Variable Object 的觀念以後，才能夠吸收這篇文章的東西。

如果你只對文章標題的那句：「所有的函式都是閉包」有興趣，那可以直接往下拉，因為要講閉包就必須先從作用域開始講起，所以這篇文章按照慣例不會太短，前面也會有一定程度的鋪陳。

好，讓我們從作用域開始吧。

閱讀更多