GitHub Pages Custom Domain HTTPS

GitHub Pages

等了好久終於出來的功能,追了蠻久,昨天 DK 也有提到,其實正式發佈前就看到有人已經可以用了,不過總之這篇稍微記錄一下如果已經是舊有的 GitHub Pages 還不能用可以怎麼處理,不過不完全有效,舊有的專案在設定看起來會像是:

GitHub Pages

下面有寫說因為用了 custom domain 就不能用,這時候把 custom domain 刪除,然後儲存重新加回去就會變成:

GitHub Pages

然後就等,我大概是等到隔天就有了(變成第一張圖的狀態),不過這幾天剛好完全沒空,到現在才有空檔紀錄一下。


TFN 域名轉出

dig markdown.tw,

我的 markdown.tw 在 TFN 註冊的,其實一直很想轉出,但是很怕轉的過程出意外,遲遲沒動手。不過剛剛看到 GitHub Pages 用 custom domain 也正式支援 HTTPS 了,如果是設定 A record 的話需要更新 DNS 設定,於是我就決定認真的來處理這件事,不意外的介面很難理解,決定記錄一下幫助眾生~

閱讀「TFN 域名轉出」全文

Accessibility Object Model

很久以前介紹AMP的時候,有提到標準內的 HTML attribute,都是有其意義和用途,而當然 WAI-ARIA 的那堆aria-*屬性也是,不過以前那堆東西的介面在 web 開發端是碰不到的,不過前陣子在看Chrome Platform Status的時候,發現到了一個新的標準草稿叫做Accessibility Object Model,中文可以叫做親和力物件模型吧,還很早期不過 Firefox 有一些基本實做,預設關閉,掛在他們的Accessiblity API下面。

這個標準目前規劃四個階段,目前有內容的只有前兩個,分別要做的事情是:

  1. Accessible Property,建立存取親和力相關屬性的標準界面,包括了rolearia-*,目前的草案不是直接把這些屬性放在 ElementNode 下,而是在 ElementNode 新增一個accessibleNode
  2. Accessible Action,建立和親和力相關的事件,擴充accessibleNode並且讓它會接收到這些親和力相關事件;
  3. Virtual Accessibility Node,讓開發者可以產生虛擬的accessibleNode,然後這些虛擬的 node 也有前兩個階段的能力,所以可以預期像是用 canvas 畫的介面也可以生出介面讓數位輔具可以溝通;
  4. Computed Accessibility Tree,提供 Accessibility Tree 的介面,目前,Accessibility Tree 也還是網頁開發者碰不到的。

目前這份草稿還在 WICG,不過已經開始有些實做了,除了 Firefox 之外 Chrome 也有,我看作者是 Mozilla、Google、Apple 的人都有,之後應該會慢慢發展成統一的數位輔具介面吧。


WebDriver Level 2

Chrome DevTool Protocol,

這超新的,新到其實什麼都還沒有,不過總之記錄一下,有兩條路線匯流:

第一條是 E2E 測試,E2E 測試比較早期是 Selenium 一家獨大,以前不知道是用什麼方法控制瀏覽器,就我瞭解應該不是太正規的方式,後來到 Selenium 2 開始發展 WebDriver,而且各家 browser vendor 都還蠻支持的,也朝向標準化的方向前進,標準文件現在也已經是CR了,由Browser Testing and Tools 工作小組在維護,不過看了看 mailing list,該工作小組目前活躍度好像不高。標準化的好處就是大家都可以照著做,除了 Selenium WebDriver 之外的實做,現在還有WebDriverIO這個 nodejs 環境的實做,理論上可以只用 WebDriverIO 加上瀏覽器各自的 driver 而不用透過 Selenium 來做自動化測試

另外一條路線是 remote debugging,這個一開始是為了 debug 手機上的瀏覽器,後,讓手機上的 browser 傳送訊息到桌機上,用桌機瀏覽器的開發工具來顯示資訊,方便除錯,發展到後來,變成開發工具和瀏覽器之間的溝通協定都走同一套,也就是說現在桌機瀏覽器也是用 remote debugging 同樣的溝通方式在跟自己的開發工具溝通,兩者耦合就這樣拉開了,我最早知道可以這樣拆開的是 Opera 以前的Dragonfly,然後可以想見每家瀏覽器的協定內容不一樣,然後就有一位Kenneth Auchenberg的人出來說這應該要有個標準!然後弄了個remotedebug.org,初期計畫是希望大家都有個 adapter 可以轉譯自家的協定到公用的協定,像是 Mozilla 的Valence,然後接著就開始有一些利用這些協定的各種發展,像是幫 Node 程式除錯、或是 iOS App、Electron 應用程式的除錯,甚至是除錯工具的開發也是用除錯工具自己 remote debug 自己,同時 Kenneth Auchenberg 也在推動 W3C 的標準化,一開始(約三年前)就是找上 Browser Testing and Tools 工作小組,不過一開始不太順利,因為那邊的都是自動化測試專門的人,和除錯工具關係其實不大。

Remote debug protocol 的資訊種類和訊息量其實都很大,目前看起來也只有 Google Chrome 的DevTool Protocol整理的比較完整,而 Firefox 的 Valence 其實已經沒維護了,他們的 README 上說要盡量相容 Chrome 的 protocol,這點讓我有點失望也不太意外,一來是擴充套件的API已經被 Google帶著走了,二來是 debug 用的資訊太多太雜,不好維護,而且這樣似乎也是比較快可以統一的方式。而標準化的工作其實在去年有點進展,也就是 Browser Testing and Tools 工作小組 終於接納,要把他放進 WebDriver Level 2 裡面了,這其實是去年十月底的消息,在 remotedebug 的twitter上有發消息,也有工作小組章程修改的commit連結證實,接下來就看他們要怎麼標準化了,畢竟複雜度比 WebDriver Level 1 複雜許多,還有些部分是不穩定可能隨時會變動的。



a11y

Pa11y Dashboard,

標題的 a11y 其實是 accessibility (親和力)的縮寫,現在英文世界似乎很大量的使用這個簡稱,今年的 JSConf EU 前陣子放出演講錄影,其中有一場是在講網路親和力的議題「YES, your site too can (and should) be accessible.」:

講者是 Laura Carvajal,在Financial Times工作,而這場演講就是他們改進 ft.com 網站親和力的過程和一些想法,我覺得精華在後半,前面是介紹自動化工具Pa11y,a11y 是 accessibility,至於首字母的 P,看 README 應該是 pal 的意思;他們把這個自動化工具整合進他們的開發流程,然後慢慢的修改,直到把回報的問題都修完,其實現在自動化工具已經很強了,連顏色對比度夠不夠都能算出來(瀏覽器的開發工具以後也會有相關資訊),不過要驗證親和力做的如何,還是有很大量的驗證其實是需要手動測試。

手動測試的部分他們是請了DAC(Digital Accessibility Centre) 來做,演講中還有一些測試者的測試影片,每位測試者都會先說他身體有怎樣的障礙,然後他邊測試會邊口述他在做什麼,遇到怎樣的問題,建議可以怎麼處理,感覺就是很專業的測試員。總之,在他們處理完所有 Pa11y 檢測到的問題後,才請 DAC 做親和力評估驗證,結果還是收到了一份兩百多頁的測試報告,回報了各種 ft.com 網站上的親和力問題,之後又花了幾個月的時間來處理這些問題,最後終於得到 DAC 的認證,這份認證資訊還蠻完整的,還說明了他們認證時網站的狀況,還有哪些問題待解決,甚至連可能會使用到但是還沒處理過親和力問題的同組織的網站(服務)都有列出來,另外在 ft.com 的親和力聲明也可以看到 DAC 的認證。

接著 Laura Carvajal 介紹到如何實際體會(參與)這些親和力問題,其中一個很經典的狀態就是只用鍵盤做所有的控制,他提供了一些強迫自己只能用鍵盤操控的方法,並且在這種狀態下工作,其它還有像是使用 Mac 的 VoiceOver 做為 ScreenReader、使用 Windows 的高對比模式等等,他建議可以實際自己去體驗看看的,甚至強迫自己使用一陣子,會對這些問題更有體會,除此之外,他還透過一些活動來讓其他公司內的人也來參與,像是模擬一個障礙者會面臨的環境,以他的例子來說是把網頁模糊化,模擬視力障礙的使用者狀態,然後在這個狀態下請人去完成一些任務,像是填一個表單,並且有提供些獎勵增加參與人數,記得他們是提供 Amazon Credit,這樣可以讓更多人體會到需要依靠輔具來上網的不便,長久下來也可以讓這些工作的推動更加順利。

這幾天我也試著裝起了Pa11y Dashboard開始做些檢測,看到的 Error 加上 Warning 數量真是有點驚人,再來慢慢處理吧...


Telegram Instant View

Telegram Instant View,

Telegram 前幾天發佈了 4.0,有幾個比較大的功能,包括了Video MessagePayment for Bots還有就是Instant View準備要開放給所有網頁使用了,Instant View 目的和 Facebook 的 Instant Article 以及 Google 的 AMP 一樣,都是為了提升使用者體驗,讓使用者能夠快的看到文章的內容,不過之前沒有開放,所以一直不知道背後的運作原理是怎樣,直到這次 4.0 發佈才得以一窺其原理,和 Instant Article 與 AMP 不一樣,不再是提供另一個新的版本,而是透過一種新的 template 語言來協助 Telegram service 把自己的網頁內容轉譯成 Instant Article 的內容(Instant View page object),不完全算是程式語言,裡面比較像是一些定義,加上用XPath來做文件內容的選取,蠻意外會用 XPath 的,還好我對 XPath 有點經驗,就花了一點時間研究了一下,也把自己 blog 的 tempalte 基本版做出來了:

?exists:  //article/div[@id="comments"]

author:  "othree"
channel: "@othree"

body:     //article
title:    $body//h3[1]

cover: $body/section[@itemprop="articleBody"]/p[1]/a[@itemprop="image"]/img

published_date: $body/header/time[@itemprop="datePublished dateModified"]/@datetime

@remove: //article/header
@remove: //article/footer
@remove: //article/div[@id="comments"]
@remove: //noscript
@remove: //a[has-class("dsq-brlink")]

語法還算蠻好理解的,官方也提供了幾個有完整註解的範例,仔細一看似乎之前其實也只有 medium 是非官方有支援的網站,也因為這個實做方式,對不同的網站就要有不同的 template 來處理,所以官方辦了個競賽,搶先替清單上的網站做出可用的 template 就會有獎金,目前個人網站雖然已經可以在官方的 editor 做 template、驗證並發測試連結,不過還要等 domain 被加進白名單後才會真的啟用,目前這個關卡還沒開放就是。

其實我是比較喜歡這種實做方式的,不用為了增加支援一個新的網路服務就多做一個版本,不會影響原本的網頁原始碼,不會讓<head>越來越肥大,當然缺點就是網站改版,HTML 結構有變化的話就要跟著修改 template,不過我是認為這個實做方法對於網路生態是比較好一些的。


MovableType and CommonMark

Typora

我這邊用的 blog 系統是MovableType不是新聞了,然後也因為用 MovableType 我一直都只能用最初版的 markdown 引擎,沒錯,就是 Daring Fireball 作者 John Gruber 的那一版,這個版本其實已經可以滿足我大部分的需求了,不過當我想要用Typora寫文章的時候,就遇到問題了,Typora 在輸出成 Markdown 文件時,code block 只支援三個 ``` 包起來的Fenced Code Block,而不支援Indented Code Block,剛好初版的 Markdown 格式只有 Indented Code Block,兩者其實要比的話,我是比較喜歡 Indented Code Block 的,比較符合 Markdown 的 sense,不過用 Fenced Code Block 有個優點是可以指定程式碼的語言,也因此才能夠有 syntax highlight 的效果。

總之,因為這個原因,用 Typora 寫技術文章對我來說就很不方便,一直以來都有想解決這個問題,前兩天還去 Typora 發 issue 說希望他們可以支援 Indented Code Block,結果發完沒多久,躺在床上快要睡覺的時候突然想到,CommonMark 這麼多語言有實做,搞不好有 Perl 的啊,結果快速搜尋了一下,還真的有一個perl-commonmark,橋接 Perl 和cmark,也有發佈到 CPAN 上,當下心裡就盤算著,隔天起來要來把它接到 MovableType 去看看。

結果隔天實做起來是沒花我太多時間,雖然對 Perl 不熟,但是可以直接拿初版 Markdown.pl 來修改,原本的 Markdown.pl 這個檔案裡面實際上自己是一個 Markdown 的 Perl Package,同時也可以作為 MovableType 的 plugin script,我只需要把 plugin script 的部分留下,然後把最後做轉換的 function 換掉就好了,當然系統要裝好 cmark 和 Perl 的 CommonMark,cmark 應該很多環境都有了,我在 archlinux 上是直接用 pacman 裝:

pacman -S cmark

然後 CommonMark 是用 CPAN 裝,本來要用 cpanminus 的不知道為何用它會抓不到 package:

sudo CPAN CommonMark

我的 nginx 跑 CGI 時用的 perl 不是系統預設位置的,所以 CPAN 執行檔的路徑我是特別指定給他的,這樣 MovableType 執行的時候才找的到 CommonMark Module,實際上沒花多少功夫,我就把 MovableType 和 CommonMark 串起來了,當下心情真的是非常難以言喻,一來是這個問題其實存在已經許久了,二是我竟然把第一個支援 Markdown 的部落格系統接上 2017 年最新的 CommonMark 實做,雖然現在應該是也幫不到什麼人了。不過沒高興多久,就發現在 UTF-8 字元似乎有些狀況,有中文的文章會爛掉,或是 Dashboard 那頁的文字會變亂碼,後來為了這個問題又弄了好幾個小時,推測問題應該是因為 cmark 那邊回來的字串已經失去編碼的 metadata,所以在做 summary 切文字的時候,就會出現切錯地方的狀況,花了很多時間交叉比對和測試,最後的結果只是用 Perl 的 Encoding 把 cmark 傳回來的字串重新 encode 過而已,其實很簡單。除此之外,我其實還有試著想接看看cmark-gfm,因為它還多支援了 Table,不過幾次測試都不太順利,就沒繼續嘗試下去了。

目前的成果放在 GitHub 上,取名叫MT-CommonMark,附上簡單的安裝說明,暫時是沒打算發去 movabletype.org 那邊。

做好之後 MT-CommonMark 之後,我就開始在部落格上測試程式碼的 syntax highlight了,研究一陣子之後選擇的是prismjs,選擇它的原因很多,不過有兩個是比較主要的:

  • 作者有Lea Verou
  • 支援的 class name 格式剛好和 cmark 輸出的一樣

結果兩者也很順利的搭配起來,中間就沒有再遇到什麼問題了。


GitHub Flavored Markdown 標準規範

Github Markdown Cheat Sheet

前陣子看到 DK提到GitHub 的 Markdown:GitHub Flavored Markdown發表正式的 spec了,當時有大概看了一下內容,不過昨天才有空寫出來(然後今天也看到碼天狗有提到這件事),基本上這份spec是基於CommonMark的,只是多了一些語法,包括:

  • 刪除線
  • 表格
  • 待辦清單
  • 自動連結(包括網址和 email)
  • Raw HTML 黑名單:
    • <title>
    • <textarea>
    • <style>
    • <xmp>
    • <iframe>
    • <noembed>
    • <noframes>
    • <script>
    • <plaintext>

新增的部分都有很顯眼的標註,其中 Raw HTML 黑名單的 HTML 標籤的<都會被轉成 entity,基本上看起來是安全性考量,不過不太確定為何有些很老的標籤出現,感覺上和安全性比較沒關係。另外我還注意到emojireference link沒包含在這份 spec 內,emoji 或許是因為實做上的問題,轉成 unicode 字元相容性不好,要用 img 會有不少相依性問題,而 reference link 大概是因這是比較針對 GitHub 網站的特性。

GitHub 轉換 Markdown 引擎的過程也有在文中說明,這次 Markdown 引擎是從Sundown(更早是 Ruby 實做的redcarpet的樣子)改成cmark,當然為了這些新語法,他們 fork 了自己的版本出來,然後在真的套上 GitHub 本站前,有先做過測試,結果發現有 1% 的文件(所有的 Markdown 文件,包括 user comment、issue...etc)會受到影響,而且判斷方法不是單純 diff 輸出結果,而是 diff 正規化過的 HTML 文件樹,不過即使只有 1% 的文件,那也是很大量,後來他們又更仔細分析,發現會受影響的幾乎都是 issue、user comment 之類的內容,是存放在 GitHub 資料庫內的,而不是 repository 內的文件,所以他們可以直接修改,如果是 repository 內的文件,因為要看 sha1 hash,所以是改不了的,後來他們魔改 Sundown,讓它吃舊文件然後吐出符合新 spec 的 Markdown 文件,接著跑了幾天把全部需要修改的舊文件(1%)都轉完,所以現在除了少數文件外,剩下的文件都是符合 GFM spec 的文件了。


GitHub 提供專案授權簡介與概要

Do What The F*ck You Want To Public License,

大概上週看到有人在 Twitter 講到 GitHub 現在會在專案上顯示該專案所使用授權條款的摘要,長的像是上面那樣,官方也有發表公告,其實這個修改是結合之前的授權偵測Choose a License

Choose a License 也是一個 GitHub 的附加服務,用來協助使用者挑選適合的授權條款,現在在 GitHub 建立新的專案時,可以順便初始化專案,包括建立 README、產生.gitignore和挑選要使用的授權條款:

Initialize Project

授權條款旁邊的 i 點下去其實就會送到 Choose a License 網站去了(不過兩邊沒有連動接起來就是),Choose a License 網站則針對每種條款都一份重點摘要,分為 Permissions、Conditions 和 Limitations 三個區塊,分別條列出該條款可以做什麼(例如商業使用)、有什麼條件(例如需要也使用相同條款授權)和條款的限制(例如免責),而現在 GitHub 上顯示的條款摘要其實就是這邊的資訊搬過來的:

Choose a License

Choose a License 網站其實有很多授權條款的整理,而不是只有常見的幾種,可以看appendix頁面有完整清單,可惜裡面沒有Vim License,另外特別想說的是 GitHub 自己(應該沒錯)提供的Unlincense,相似於創作領域的CC0,就類似丟到 Public Domain 的意思,不過保留了免責條款,講到免責聲明,就還要順便提一下WTFPL,它其實也是超自由的 License,差別就是連免責聲明都沒,其實是更加接近丟到 Public Domain 吧?

最後想說的是 GitHub 用來判斷專案使用的授權,用的是licensee這個 Ruby Gem,看起來完全就是為了做這些事情寫的,我看好像也沒其他類似功能的專案,作者 Ben Balter 其實也是 GitHub 員工。


此類別所有文章