日本自駕

沖繩

這篇想要記錄一下第一次去日本自駕,就前陣子去了沖繩一趟,當然就選擇租車自駕,這篇用條列式記錄一下:

  • 租車公司是 OTS,因為第一次的關係,所以就盡量走大眾路線
  • 不過 OTS 因為比較大間,位置離機場也比較遠,其實比較花時間
  • 租的車款是 Toyota C-HR,看到有特價加上早鳥,不過也還是比一般車款貴
  • 不免俗的離開租車公司時要刷一下雨刷
  • 大約第二天就不太有左右駕習慣問題了,回國後也沒有左右問題
  • 沖繩比較偏遠,部分路段的路面狀況其實也不好
  • 幾乎所有路口都可以右轉,有右轉道,可能是沖繩才這樣
  • 晚上山路其實沒什麼路燈,交通號誌反光效果超強的,強到覺得會刺眼
    不過一部份應該是因為車燈很亮,倒是號誌都很乾淨是真的
  • 以後應該還想要東北、北海道也去試試看自駕

針對 Toyota C-HR 的部分:

  • 後座空間真的小、後座車窗也小
  • 四人三個行李箱有點勉強,後行李箱只能放兩個中 size 的行李箱
    一大一中也不行,剩下一個大的是把後座一個位子拉倒才放進去
  • 有個自動切換遠光燈(AHB)的功能,正確性很高,實在很方便
  • 不過車門在開動車子後不會自動上鎖
  • 開鎖的時候地上會有投影,有點騷包(?)
  • 開起來感覺其實是還不錯啦

沖繩 okinawa,


My First Contribution to Nginx

nginx conf

因為工作上的需要,所以其實我還蠻常會編輯 nginx configuration file 的,理所當然的編輯器是用 vim,然後就會對 nginx 設定檔的支援有意見,一般人用的 nginx 設定檔的 vim script 其實是 nginx repository 的 contrib 目錄裡面的那份,這份 vim script 其實本來也是獨立的,不過原作者好像把他捐進去 nginx 裡面,之後就一直都在裡面了,也因此之後更新就很不頻繁。

然後因為檔案都放在 nginx repository 裡面,Vim 要使用其實不太方便,所以 Github 上還看的到不少人單獨抽出來,我一開始也是 forkmosky的來用,後來就直接在自己的 repository上面修改了,改一陣子之後就開始想要推回 upstream,也就是 nginx 的程式庫,然後就開始了這段協工旅程(?)。

要發修改上 upstream,第一步自然是看一下如何貢獻,節錄這邊幾個重點:

  1. nginx-devel這個 mailing list 做討論
  2. 發 patch 前有一些注意事項,不過我改 vim script 比較沒關係
  3. Patch 也是用 email 發到 nginx-devel,有範例
  4. 推薦用patchbomb
  5. 要先簽CLA(不過目前這條已經不見了,改成最後說發 patch 等於同意用他們專案的 LCIENSE)

總之我就照這份,先去訂閱了 nginx-devel 觀察一陣子,然後就直接把我的修改整個丟上去了,一開始是直接用 Gmail 發,把 patch 檔內容直接複製貼過去,產生 patch 檔的方法是:

hg export > something.patch

hg export會直接輸出最後一個 commit 的 patch 內容到 STDOUT,然後就直接用 Gmail 發過去,結果 review 的Maxim Dounin說他沒辦法 apply patch,可能是因為我的 mail client 的關係,建議我用patchbomb發,所以就研究搜尋了一下,發現他是直接發 email 的機制,所以要把帳號密碼都寫到設定內,找了一篇 Gmail 的設定範例,搭配 Google account 的應用程式密碼,設定範例如下:

[extensions]
hgext.patchbomb =

[email]
from=othree <othree@gmail.com>
to=nginx-devel@nginx.org
cc=othree@gmail.com
method=smtp

[smtp]
host=smtp.gmail.com
port=587
username=othree@gmail.com
password=[gmail_password]
tls=True

把這些資訊填入.hg/hgrc這個檔案內,然後就可以用hg email -o --test來測試看看,這個指令會把完整的原始信件內容,包括 header 等都顯示出來(丟到 STDOUT),如果正式要發就把--test拿掉就好了。

確認一切沒問題後,我就改用 patchbomb 發 patch 到 nginx-devel 了,結果還是被拒絕了,問題主要是這個 patch 一次修改太多,理想上應該是不同目的的修改放到不同 patch 內,當然這和我一開始的預想不一樣就是了,我一開始的想法是因為 contrib 這邊的東西,相對於 nginx 本體的原始碼來說比較次要,所以盡量減少 commit 數,其實如果我有先去問過應該是可以少繞這段路,總之,為了一個一個修改送出,我又開了一個 github repository,叫做nginx-contrib-vim-patch,想要慢慢把我的 nginx-contrib-vim 內的更動搬過去,接著開始的,就是漫長的 review 和溝通了。

其實我完全沒想到 Maxim Dounin 會這麼認真的 review,不止會看我這樣改是要達到什麼目的,還有認真測試,結果被抓出一堆問題,雖然都是奇妙的 conf 寫法,合語法,但是應該不會有人這樣寫的 case,這些 case 我也開始慢慢收集到 github 上的nginx-conf-test,方便之後測試用,總之來回許久,終於有一部分比較簡單的東西先進去 nginx repository 了,然後我發現外部貢獻者都會在change log那邊被感謝,我貢獻進去的目前應該都在 1.11.11 那版,其實只有把新的 directive 補上(core modules, 3rd party modules)和幾個 protocol 參數的 highlight,至於其他的修改還進不去,目前看起來會是一場長期抗戰,主要是因為 reviewer 對於期望的目標和我不一樣,目前大概會維持兩個版本吧,一邊弄自己希望的,一邊抽東西送回去 upstream,不得不說主事者控制太緊會讓貢獻者動力被削減不少。

貢獻 nginx 的過程讓我體會到以前的開源協做的模式(應該是吧?),用 mailing list 溝通,發 Patch、code review、做討論,這些點來看,nginx 的流程其實是非常老派,和現在用 Github 做溝通、協做 的流程差很大,門檻也高不少,當然這不一定是壞事,還是要看專案性質,在 Github 這類平台上做這些協做流程的話,門檻降低了,其實可能隨之而來的問題就是太多人進來造成貢獻品質落差很大,反而會吃掉主力人員的時間,剛好今天也看到知乎上有一篇「維護一個大型開源專案是怎樣的體驗?」,裡面就有提到 VSCode 的狀況,變成還需要排人專門處理 issue 和 PR,感覺就很可怕。

順帶一題,nginx 的固定貢獻者當中不少中國人啊。


日本跨年

八坂神社,

去年年底臨時冒出了個去日本關西跨年的行程,由於之前有聽聞日本新年可能會變空城,所以就認真的研究了一下行程,主要擔心的是 12/31 和 1/1 兩天,這趟住的地點是在大阪,考慮了幾個行程,其中 12/31 的選項是:

  • 晚上早點買超市的晚餐回飯店看紅白,要跨年再看要不要去神社參拜
  • 去京都一天,因為 12/31 到 1/1 終夜交通不會中斷,所以還可以考慮跨年參拜完才回來

1/1 則是:

  • 環球影城玩整天
  • 去看還很白的姬路城,1/1 有特別免費開放

後來的決定是 12/31 去京都一天,不過結果沒待到跨年,大概十二點前就回到大阪了,然後 1/1 去姬路城,因為環球影城 1/1 預期人會很多,連 pass 都買不到了,加上以後來應該也還不會有損失,但是姬路城應該只會越來越不白,不過後來才發現環球影城有顆金氏世界記錄的聖誕樹最後一年展出...

總之,以下是 12/31 的清水寺:

閱讀「日本跨年」全文

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 員工。


➡ 看看其它文章