幹壞事是進步最大的原動力
在「Homebrew Analytics Install On Request Events — Homebrew」這邊，Homebrew 利用了傳回來的資訊算出 2016/07/14 到 2017/07/14 的安裝套件次數，列出前一千名。(我是把他關掉，因為隱私問題不想要傳出去... 參考「Homebrew 會將安裝資訊送到 Google Analytics 上」這篇。)
比較有趣的是第一名的 node 超級多，比第二名加第三名的 git + wget 還多...
拿來翻一翻還 ok，順便看一下大家用什麼...
在 nginx 1.13.4 出的新功能，ngx_http_mirror_module：
The ngx_http_mirror_module module (1.13.4) implements mirroring of an original request by creating background mirror subrequests. Responses to mirror subrequests are ignored.
範例其實就講的還蠻清楚的：
location / {
mirror /mirror;
proxy_pass http://backend;
}
location /mirror {
internal;
proxy_pass http://test_backend$request_uri;
}
如果拿 nginx 當 load balancer 的人，可以用這個功能做些事情...
AWS 的 Lambda@Edge 宣佈 GA 了：「Lambda@Edge – Intelligent Processing of HTTP Requests at the Edge」。
最直接的應用就是在 CloudFront 的 edge 上執行一小段 code，修改 HTTP request 或是 HTTP response 了，不過可以看到一些限制：
不過要用來解哪些問題要再想一下...
GitHub 推出了 Code Owner 的概念：「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的：
The code owners feature was inspired by Chromium's use of OWNERS files.
檔案名稱是 CODEOWNERS，可以放在根目錄或是 .github/ 下，可以針對不同的目錄設不同的人：
To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]
這樣一來，在 pull request 的時候就會跳出來：
另外也可以設定需要 code owner 同意才能 merge：
GitHub 推出了抓人來 review 的功能：「Requesting reviews from repository teams」。
在「Requesting a pull request review」這邊說明的更多一些。這樣就更方便了些...
Facebook 花了不少時間對付 reload 這件事情：「This browser tweak saved 60% of requests to Facebook」。
Facebook 的人發現有大量對靜態資源的 request 都是 304 (not modified) 回應：
In 2014 we found that 60% of requests for static resources resulted in a 304. Since content addressed URLs never change, this means there was an opportunity to optimize away 60% of static resource requests.
而 Google Chrome 很明顯偏高：
於是他們找出原因後，發現 Google Chrome 只要 POST 後的頁面都會 revalidate：
A piece of code in Chrome hinted at the answer to our question. This line of code listed a few reasons, including reload, for why Chrome might ask to revalidate resources on a page. For example, we found that Chrome would revalidate all resources on pages that were loaded from making a POST request.
然後在討論後認為這個行為不必要，就修掉了，可以看到降了非常多：
We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional.
但還是很明顯比起其他瀏覽器偏高不少，在追問題後發現當輸入同樣的 url 時 (像是 Ctrl-L 或是 Cmd-L 然後直接按 enter)，Google Chrome 會當作 reload：
The fact that the percentage of conditional requests from Chrome was still higher than other browsers seemed to indicate that we still had some opportunity here. We started looking into reloads and discovered that Chrome was treating same URL navigations as reloads while other browsers weren't.
不過這次推出修正後發現沒有大改變：(拿 production 測試 XDDD)
Chrome fixed the same URL behavior, but we didn't see a huge metric change. We began to discuss changing the behavior of the reload button with the Chrome team.
後來是針對 reload button 的行為修改，max-age 很長的就不 reload，比較短的就 reload。算是一種 workaround：
There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones.
Google 也發了一篇說明這個新功能：「Reload, reloaded: faster and leaner page reloads」。
當 Facebook 的人找 Firefox 的人時，Firefox 決定另外定義哪些東西在 reload 時不需要 revalidate，而不像 Google Chrome 的 workaround：
Firefox chose to implement this directive in the form of a
cache-control: immutableheader.
Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。
所以之後規劃前後端的架構時又有東西要考慮進去...
有些人認為儘量保持原狀，但有些人認為儘量維持 tree 的乾淨，而這次推出的 rebase 則是把後者的需求補上了：「Rebase and merge pull requests」。
GitHub 的新功能，在 pull request 後修改 target branch，這樣可以做後續討論或是調整，然後再 merge 回 dev 或是 master branch 上：「Change the base branch of a Pull Request」。
依照慣例，security issue 都會取個名字，這次叫做 httpoxy：「A CGI application vulnerability for PHP, Go, Python and others」。
事情發生在兩個命名變數上的衝突：
Proxy 欄位放到環境變數裡的 HTTP_PROXY。HTTP_PROXY 當作 proxy 設定。這件事情 2001 年在 libwww-perl 就有發生過 (並且修正)，curl 也發生過 (然後修正)，2012 年在 Ruby 的 Net::HTTP 也發生過 (也修正了)。
然後在 2016 年還是被發現有很多應用程式會中獎... 這頭好痛啊 :o
Dropbox 將本來的 SPDY 切換到 HTTP/2 後整理了不少資料：「Enabling HTTP/2 for Dropbox web services: experiences and observations」。
大多數都是效能的改善，但「Increased latency for POST requests.」這段頗有趣的，找出了 nginx 的 bug：
POST 的 latency 大約增加了 50%，而實際追蹤問題發現是 nginx 中 SETTINGS_INITIAL_WINDOW_SIZE 預設值的問題，然後提出 patch 改善：「[nginx] HTTP/2: rewritten handling of request body.」：
There is a small issue with setting `SETTINGS_INITIAL_WINDOW_SIZE` to 0: now when client tries to POST data it needs to wait for an additional RTT(between `send HEADERS` and `recv WINDOW_UPDATE`) to start sending data.