前言

最近 YDKJS(You Don’t Know JS 的縮寫,中譯版翻成:你所不知道的JS)有了第二版,名叫 YDKJSY,Y 是 Yet 的意思(中文版可能可以翻叫:你還是不知道的 JS)。這個第二版還沒全部完成,但在 GitHub 上面已經公開了最前面的一些章節。

搶先讀了一下第一章,在講與 JS 相關的歷史,其中提到一段讓我很感興趣的議題:

As such, sometimes the JS engines will refuse to conform to a specification-dictated change because it would break that web content.

In these cases, often TC39 will backtrack and simply choose to conform the specification to the reality of the web. For example, TC39 planned to add a contains(..) method for Arrays, but it was found that this name conflicted with old JS frameworks still in use on some sites, so they changed the name to a non-conflicting includes(..). The same happened with a comedic/tragic JS community crisis dubbed “smooshgate”, where the planned flatten(..) method was eventually renamed flat(..).

大意是在說有時候 JS 的規格必須跟現實(已經存在的那些舊的實作)妥協。例如說原本 Array 要加上一個叫做 contains 的 method,但因為會有問題所以改叫 includes,flatten 也改名叫做 flat。

還有一個上面特別標起來的詞「smooshgate」,用這個當關鍵字去找才發現是去年三月左右發生的事件,至於發生了什麼,底下會詳述,跟上面提的 flatten 有關。看到有這件事的時候我第一個反應是:「咦,我怎麼什麼都不知道?」,查了一下繁體中文的資料,大概也只有這篇有提到:SmooshGate,以及[筆記] 3 種 JavaScript 物件屬性的特性這篇有擦到邊而已。

在仔細研究了一下事情的來龍去脈之後,覺得是個滿有趣的議題,因此寫了這篇跟大家分享。

閱讀更多

前言

在這兩三年之間,「刷題」似乎成為了一種風潮。本科系要去面試大公司的時候要刷題,非本科系出去面試也要刷題,好像只要沒有刷題就會落後他人,就會被公司刷掉。

其實我一直不是很喜歡「刷題」這個詞,主要是因為「刷」這個字。不知道大家對這個字的解讀是什麼,但我會認為有種「為了寫題目而寫題目」的感覺,就好像題海戰術那樣。雖然說題海戰術用得好的話成效滿顯著的,但總感覺很多人刷到最後會變成「看過的題目就會,沒看過的就一定不會」,如果是這樣子的話,那我覺得不是一件好事。

之前我有寫了一篇文章:當我們在學程式時,要學的到底是什麼?,稍微談了一下這件事情。

總之呢,比起刷題這個詞,我更喜歡用「程式解題」四個字來表達我想表達的意思。

閱讀更多

前言

如果要舉出一個在 JavaScript 裡面很重要也很常用,但新手常常搞混的概念,那「非同步(Asynchronous)」當仁不讓,絕對是第一名。跟其他那些 thisclosureprototype 或是 hoisting 比起來,非同步在實際開發的時候用到的頻率高太多了,而且是初學者常常會踩坑的地方。

非同步真的那麼難嗎?

我相信不是的。只要循著一個正確的脈絡前進,就可以循序漸進理解為什麼需要非同步,也能知道在 JavaScript 裡面是怎麼處理這種操作的。

類似的主題我其實在四年前就寫過,但現在回頭看實在是寫得滿差的,所以四年後重新挑戰這個主題,希望能寫出一篇品質不錯的文章,把非同步這件事情講清楚。

在寫這篇文章之前,參考了 Node.js 的官方文件,發現在非同步的講解上其實做得不錯,因此本文會以類似的切入點開始談這個問題。如果不會 Node.js 也沒關係,我底下會稍微做點介紹。

建議閱讀本文以前需要具備 JavaScript 基礎,知道如何使用 JavaScript 操作 DOM,也知道什麼是 ajax。

接著就讓我們開始吧!

閱讀更多

大約在一年前的時候,我把 Blog 直接放在 GitHub Issues 上面。雖然說台灣很少人這樣做,但有許多中國的開發者都利用這個方式來架 Blog。

那時我會想採用 GitHub Issues 的原因很簡單,就是因為方便。

  1. GitHub Issues 完美支援 Markdown 語法。
  2. 上傳圖片超方便
  3. 當別人也用 Issues 提到你的文章時,會自動產生 reference
  4. 留言系統超方便
  5. 可以按 Emoji
  6. GitHub repo 可以按 watch 來關注,更新時會收到通知

總結以上,當時選擇了 GitHub Issues。

但最近發現一個很大的問題,當初沒有注意到,那就是 GitHub Issues 的 SEO 極差。你直接拿 Issue 的標題去 Google 搜尋,還不一定能搜得到。

因為這問題挺大的,所以最後還是搬回了 Hexo。

兩年前其實我就已經搬過一次家了,從 Logdown 搬到 Hexo 去。但那時我沒有繼續使用 Hexo,因為我覺得那個部落格的版面不太好看。

而這次重新搬回來,很大一部分是因為看到了 Askie Lin 的部落格,我看到的時候驚為天人,想說:「哇,這部落格也做得太漂亮了吧!」,後來得知是使用現成的主題 Minos 來改的,於是我就想說可以換成這個主題試試看。

今天經過一整天的調整,自己修了滿多東西,試著把這個版型修成自己想要的樣子,發現還滿順利的。可能是因為原本的 code 就寫得不錯,基本上修起來沒有太大問題,改了一下字體大小以及分類跟文章列表顯示的樣子,其他都沒什麼動。

沒什麼意外的話,以後就決定在這邊紮根了,原本 GitHub 那邊就當作備份文章的地方好了。

Hexo 萬歲,Minos 萬歲 🎉

簡介

近幾年前端框架大放異彩,許多新手才學沒多久的 JavaScript,就直接學習三大框架了(雖然 React 不是框架,但整個生態系其實就跟框架沒兩樣,因此我覺得歸類在框架也不是不行)。

而這三大框架通常都是拿來寫 SPA(Single Page Application)用的,我一直認為在學習這些框架前應該要具備一些基礎知識,尤其是對於前後端的理解,否則一定會遇到很多不知道從何解起的問題。

因此,本文舉出一個我自己曾經碰過,學生也常常跑來問我的問題當作範例,大家也可以先想一下自己能不能回答出這個問題:

假設今天我有個 SPA,搭配某些 router 的 library 來實作路由,所以 /list 會連到列表頁,/about 會到關於我的頁面。

可是奇怪了,當我把 SPA 上傳到 GitHub Pages 之後,首頁是好的,我從首頁進去 /list 也是好的,可是當我在 /list 重新整理的時候,卻顯示 404 not found,這是為什麼呢?

要回答這個問題,必須先來複習一下前後端相關的網路基礎知識。

閱讀更多

(原文寫在 Medium,順便在這邊備份一下)

雖然說我一直很清楚自己目前偏好的學習方法以及路線,並且把我認為適合的路徑都變成上課的大綱拿去教學,但一來好像沒多少人會去看那個大綱,二來大綱並沒有詳細解釋背後的原因。因此我才覺得自己有必要寫這一篇,來寫一下自己認為比較「紮實」的網頁前端學習路線。

閱讀更多

前言

這是一系列共三篇的文章,我稱之為 Session 與 Cookie 三部曲。系列文的目標是想要由淺入深來談談這個經典議題,從理解概念一直到理解實作方式。這是系列文的最後一篇,三篇的完整連結如下:

  1. 白話 Session 與 Cookie:從經營雜貨店開始
  2. 淺談 Session 與 Cookie:一起來讀 RFC
  3. 深入 Session 與 Cookie:Express、PHP 與 Rails 的實作

第一篇以白話的方式來談 Session 與 Cookie,全篇沒有談到太多技術名詞;第二篇直接去看 Cookie 的三份 RFC 來理解到底什麼是 Session,也補齊了一些 Cookie 相關的知識。而這一篇則是要深入 Session,一起帶大家看看三種不同的 Session 實作方式。

這三樣分別是 Node.js 的 Web 框架 Express、PHP 以及 Ruby on Rails。會挑選這三個是因為他們對於 Session 機制的實作都不同,是我覺得很適合拿來參考的對象。

閱讀更多

前言

前幾天的時候我在 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。

前陣子花了點時間研究一下整件事情的來龍去脈,在整理的過程中也發現無論贊成或是反對,這其中的理由都很值得我們去思考,因此在此總結成一篇文章跟大家分享。

閱讀更多

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×