CloudFlare 在台灣的節點上線了

前兩天開始就開始在社群網站還有通訊軟體群組上看到在傳 CloudFlare 的系統狀態監測頁面 “CloudFlare system status” 上多了 TPE – Taipei, Taiwan 的結點
status

CloudFlare 的 CEO 也在 Twitter 上間接證實了這件事:

稍為搜尋了一下,能找到這個點的最新公開紀錄只有在 CloudFlare system status 4/6 上的一個 DNS Propagation delays in APAC, Incident Report for CloudFlare 裡面看到,明確的建置以及上線時間就不知道了:

cloudflarestatus-incidents-rz5h7qnb94v3-DNS-Propagation-delays-in-APAC

根據在 CloudFlare support 上面的文章:Which CloudFlare data center do I reach?,每個節點都是使用 Location Code: City, (State,) Country 這樣的格式來表示,而 location code 是使用最靠近的主要國際機場的 IATA 代碼 ( Each location code is the IATA code of the nearest major international airport.),冷知識一下,雖然上面也寫著 Taipei,不過 TPE 是桃園國際機場 Taiwan Taoyuan International Airport 的代號,也許外國人比較認得台北認不得桃園吧?

昨天看的時候看起來只有免費方案的流量會倒到台灣的點去,應該可以算是初期的測試,而付費流量像是 cdnjs.com, digitalocean.com 以及 cloudflare.com 都還是繼續倒到香港,而今天早上看的時候發現付費用戶的流量都已經改倒到台灣了,看圖:

cloudflare-trace-tpe.png

Trace 可以看到是 TPE 的字樣,先前都是 HKG (香港)

目前看起來從台灣學術網路、中華電信、遠傳、亞太的追蹤結果都是走到 TPE 上面去的,有興趣了解自己使用的網站 / 線路使用的是哪一個節點,可以在網址的 hostname 部份後面接上 /cdn-cgi/trace 就會看到類似上面那張截圖的結果 (前提當然是該網站有使用 CloudFlare ,其他 cdn 業者作法可能不盡相同),這邊是一些範例:

截至目前為止,CloudFlare 的 network map 上還無法看到台灣的節點,推測因為還在測試階段:

network-map

https://www.cloudflare.com/network-map

繼續閱讀

cdnjs git repositories visualization using gource

Gource is a famous version control visualization tool, supports git, svn, hgbzr and cvs2cl, I tried to use gource to visualize the CDNJS development history, and here are the videos I uploaded to youtube.

CDNJS main repository:
(https://github.com/cdnjs/cdnjs)

CDNJS new-website repository:
(https://github.com/cdnjs/new-website)

繼續閱讀

What have we done in cdnjs in last year (2015)?

Merry Christmas and Happy New Year!

Thanks all the users, developers and the contributors! We did a lot of things in 2015, though there are still many issues that waiting to be solved, we’ll keep working on it, at the end of year 2015 and the beginning of year 2016, let’s have a fast review of the changes and rising in cdnjs during 2015!

cdnjs_2015_merry_christmas_and_happy_new_year

  • We now got more than 3.3k stars and about 2.5k forks on GitHub
  • We had 9339 commits in the beginning of 2014, became more than 10k commits since Feburary, and now about 18200 commits
    • 8892 commits were committed in last year!
  • We have more than 1000 contributors in 2015! (Sorry that I don’t remember the contributors count at the beginning of last year)
  • We had only 1220 libraries hosted on cdnjs, but 1669 libraries been hosted now!
    • 449 new libraries added in 2015!

(PS: Above data only calculated the cdnjs main repository, we have some other repos here)

繼續閱讀

善用 Git 的 sparse checkout 跟 shallow clone/pull 來提高工作效率

當初也是因為在摸cdnjs才開始接觸到的東西,不過貌似大家平常用不太到,所以很多人不知道有這樣的功能,也是做個筆記,有人問的時候可以直接丟這篇 …

先講shallow clone/pull:

man git-clone理面的說明:

–depth
Create a shallow clone with a history truncated to the specified number of revisions.

簡單來說就是把太久以前不需要的歷史給丟掉,大於給定數量以前的commit紀錄就會被忽略,進而省下clone時頻寬、空間及時間,這點在數千到數萬個commits以上的repository理面效果會非常明顯,像travis-ci在做CI build的時候預設的clone depth就是50,很久以前是100,缺點除了git log只看的到一定數量的提交紀錄外,git blame跟bi-sect等會需要trace先前紀錄的功能都會變的不可靠或不可用就是了。

另外一個就是sparse-checkout了,這個功能的作用是只checkout出我們想要的檔案,以cdnjs為例,.git資料夾也才600多MB而以,可是整個專案的資料夾卻高達13GB左右,由於理面的檔案大多是非常容易壓縮的source code(文字檔),所以就會有.git資料夾明明占用很少空間,可是實際上整個專案占用的空間卻非常龐大的現象,而這麼大的專案,很可能會有檔案系統操作的效率低落的問題(尤其在rebase等操作),在我們已知只需要取得某專案某些目錄或檔案的情況下,根本沒必要把所有檔案都checkout出來,這時候就可以使用sparse-checkout,在送pull request到不是自己常態性參與的專案時很好用!

用法大概是這樣(步驟3~5順序可換):

  1. 建立一個空的git專案:
    $ git init new.cdnjs && cd new.cdnjs

  2. 在專案裡面啟用sparse-checkout
    $ git config core.sparseCheckout true

  3. 設定你要checkout哪些檔案(直接寫到.git/info/sparse-checkout,多個規則可寫多行),例如我只要ajax/libs/jquery/底下的所有檔案
    $ echo '/ajax/libs/jquery/*' >> .git/info/sparse-checkout

  4. 設定remote(要從哪裡clone/pull?)
    $ git remote add origin git://github.com/cdnjs/cdnjs.git

  5. 然後就可以開始pull了(這邊可以加上前面說的shallow pull,加上–depth=n)
    $ git pull origin master

到這邊就結束了,整個專案所占用的空間應該會小非常多,這邊以jquery搭配shallow clone depth=10為例,看一下空間使用:
$ du -d 1 -h

18M ./ajax
587M ./.git
605M .

總共605MB而已

而原本的長這樣:
$ du -d 1 -h

682M ./.git
43M ./scratch
16M ./node_modules
12G ./ajax
24K ./test
32K ./build
13G .

cdnjs_github_sparsecheckout_comparasion
高達13GB …

摁 … 少了12GB的checkout快很多啊 …

如果之後想改變要checkout的檔案呢?

就直接更改專案底下的.git/info/sparse-checkout檔案,改好之後做一次git reset –hard即可
(記得更改之前確認沒有未儲存的修改即可)

範例:

/ajax/libs/jquery/*
/build
/CONTRIBUTING.md
/MIT-LICENSE
/README.md
/sparseCheckout.md
/auto-update.js
/circle.yml
/CONTRIBUTING-WIP.md
/package.json
/update-script.sh

有一點要注意就是檔名前面代表專案根目錄的斜線不要省略,若非要checkout所有同名檔案,就要把完整路徑寫清楚,例如/package.json如果寫成package.json,則所有的package.json都會被checkout出來

git push在處理branch name的小技巧

把程式丟到heroku跑的話預設是要用master才會run/build你的app,不過有些東西其實不適合放到master branch,例如cdnjs/new-website理面的meta data,之前因為用機器人(其實只是crontab)去更新這些資料,生了上萬個commits出來,多了一堆不必要的log,也淡化contributors list理面真正的contributors的貢獻量

剛剛花了一些時間把那些commits通通清掉,現在大概剩下兩百出頭的commits,雖然還是有一些沒拔乾淨,不過已經無傷大雅了,接下來的meta data就會丟到meta這個branch,不過問題來了,把這些資料直接push到heroku上面(因為一些原因所以不是用GitHub webhook而是自己push)會得到這樣的訊息:

Pushed to non-master branch, skipping build.

目前想的到最簡單的解決方法是這樣:
git push heroku meta:master

也就是在branch名稱後面多了一個:master,意即把本機的meta分支push到heroku這個remote上的master branch

同理也可以在pull的時候這樣做:

git pull upstream master:base

意即把upstream上面的master分支拉到local的base分支上

然後 … 就沒有然後了,滿簡單好用的方法@@