Home » Posts tagged "github"

在 DuckDuckGo 搜尋頁快速切換到 Google 的套件

DuckDuckGo 的英文搜尋算是還堪用,而中文的話很慘,需要很精確的搜尋字才有辦法找到 (同義詞有點少),但為了想辦法在 Google 少留一些記錄,就還是把預設引擎設在 DuckDuckGo 上,另外寫了一個這個套件可以快速切到 Google 的搜尋引擎上,這樣在 DuckDuckGo 發現一看就知道不行時可以馬上切過去:「Press 'g' from DuckDuckGo's search result page to Google's.」。

GitHub 頁面上有放安裝連結,就請自取吧...

GitHub 也 open source 自家的 Load Balancer 了...

GitHub 也 open source 自家的 load balancer 了:「GLB: GitHub's open source load balancer」。

如果翻一下歷史就會發現,夠大的單位都會遇到不同的 balancing 問題,然後都會開發自己的 load balancer,像是 Google 放出來的 SeesaweBay 放出來的 Neutrino (程式的 repository 在 eBay/Neutrino),Facebook 放出來的 Katran

經濟規模夠大就能夠自己搞,然後針對自家的問題客製化去解... open source 能對社群帶來多大好處就未必了,主要還是做名聲而已,實際上大家還是繼續用 nginxHAProxy,或是買商業方案來先撐著。

GitHub 的網站拿掉 jQuery 了...

Twitter 上看到 GitHub 把網站上的 jQuery 都拔乾淨了。因為現代瀏覽器大多都可以直接來,或是有其他方案可以用:

querySelectorAll 是 IE9+ 我可以理解,不過 Fetch 查了資料發現是 Edge 才支援的 (而且還要新一點的 Edge),找 GitHub 文件看到「Supported browsers」這篇,看起來 GitHub 網站直接放掉 IE 啊,另外 Firefox ESR 也是 best effort 而已,能這樣規劃跟網站性質有關係,一般網站還是得考慮 IE11 (因為 Windows 7)...

DefaultCcPlugin 改 Component 不會增加 Cc 列表的問題...

TracDefaultCcPlugin 裡有個很喜歡用的 feature:改 component 後會自動增加該 component 的 cc list。但這在 Changeset 13747 被「修正」掉了:

0.3dev: Only append to CC field when ticket is created. Fixes #11624.
Previously the CC field would be modified on Preview and during any ticket change, however these would often go undetected since the field is de-duplicated on save.

而這個 plugin 還是用 Subversion 管理,本來找了一堆 svn2git 的工具,後來發現 Git 所以靠 git-svn 拉下來再改,然後再丟出來:「gslin/defaultccplugin」。

所以雙方都公開承認 Microsoft 併購 GitHub 了...

MicrosoftGitHub 兩邊的新聞稿都出來了:「Microsoft to acquire GitHub for $7.5 billion」、「A bright future for GitHub」。

隔壁棚 GitLab 在前幾天有消息時就先恭賀了 (畢竟同個業界的,可以驗證消息的來源比我們多):

另外也馬上就提供 migration 促銷:

然後從 GitLab 的 GitHub Importer (Grafana) 上面也可以看到湧入大量的 GitHub 使用者 (這個站的流量太大,圖表有時候會出不來),可以看出不少人搬家... 不過我覺得這只是搬到另外一個坑啊。

我是比較正面看待這件事情... Microsoft 遲早會搞爛 GitHub,然後 Git 逐漸回歸分散式的本質,而不是現在 GitHub 這樣高度集中。

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt,參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇),但測了一下不是我想要的效果,就找了一下網路上的資源,結果有找到還算可以的方案...

  • 先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
  • 然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt,會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係,可以之後再開。)
  • 然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME,一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理,而且有蠻多 header 可以設定,其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的),可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header,當設定 HSTS 之後,SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day),不過只拿來做 redirect 應該還好...

PS:如果有人要推薦其他的組合也歡迎...

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域,現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了:「Custom domains on GitHub Pages gain support for HTTPS」:

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準,也稱為 ANAME,有些 DNS provider 有支援,主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record,則是需要更新 IP 位置:

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項:

以前 HTTPS 還得自己弄伺服器處理,現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構,IP 是 Fastly 的,所以應該是跟 Fastly 合作,但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證,或是 Fastly 提供 Port 80/443 的 TCP Proxy?

AWS 文件丟上 GitHub 讓大家可以提供意見

AWS 宣佈把文件丟上 GitHub 讓大家參與修改:「AWS Documentation is Now Open Source and on GitHub」,整包放在「Amazon Web Services - Documentation」這邊。

看了一下授權的部份,文件大多是 Creative Commons Attribution-ShareAlike 4.0 International Public License (在 SUMMARY 的部份會寫「Creative Commons Attribution-ShareAlike 4.0 International License」),而 sample code 用的授權看起來有點像 MIT license 或是 ISC license,但比對了一下好像不是這兩個...

這樣做另外的好處是有歷史記錄,要查一些歷史故事的時候比較好查...

GitHub 在 2/28 遭受的攻擊...

GitHub 在 2/28 遭受 DDoS 攻擊,蠻快就把事故報告丟出來了:「February 28th DDoS Incident Report」。

不過跟 GitHub 其他文章不太一樣,這篇算是 PR 稿吧,簡單來說就是花錢買 Akamai Prolexic 的過濾服務解決... Akamai 方的 PR 稿則是在「Memcached-fueled 1.3 Tbps attacks - The Akamai Blog」這邊可以看到。

17:21 UTC 發現問題,然後判斷超過 100Gbps,所以 17:26 決定讓 Akamai Prolexic 接管過濾:

At 17:21 UTC our network monitoring system detected an anomaly in the ratio of ingress to egress traffic and notified the on-call engineer and others in our chat system. This graph shows inbound versus outbound throughput over transit links:

Given the increase in inbound transit bandwidth to over 100Gbps in one of our facilities, the decision was made to move traffic to Akamai, who could help provide additional edge network capacity. At 17:26 UTC the command was initiated via our ChatOps tooling to withdraw BGP announcements over transit providers and announce AS36459 exclusively over our links to Akamai. Routes reconverged in the next few minutes and access control lists mitigated the attack at their border. Monitoring of transit bandwidth levels and load balancer response codes indicated a full recovery at 17:30 UTC. At 17:34 UTC routes to internet exchanges were withdrawn as a follow-up to shift an additional 40Gbps away from our edge.

就這樣而已,完全就是 PR 稿 XDDD

Archives