幹壞事是進步最大的原動力
花了些時間研究如何把 rTorrent 丟進 Docker 裡跑，對應的設定都放在 GitHub 上的「gslin/rtorrent-docker」這邊。
使用的方式是傳入使用者的 uid 與 gid (-e USER_GID 與 -e USER_UID)，以及預期的 port (有兩個地方，一個是 -e PORT，另外一個是 -p 開 port forwarding，不然外面沒辦法直接連進來)，然後把 TERM 變數丟進確保 console 的操作。剩下來把對應的目錄掛進 container 讓他可以寫入 (-v 的部份)：
docker run \
-e PORT=6991 -e TERM=${TERM} \
-e USER_GID=`id -g` -e USER_UID=`id -u` \
-i -p 6991:6991 -t -v "`pwd`:/srv/rtorrent" \
gslin/rtorrent:latest
自己用這樣應該是夠用了... 把這串命令放到 shell 的 alias 裡面用就好了。
三個月前 Pinterest 提到對 InnoDB 壓縮的改善，講到透過字典的改善方式：「Pinterest 在 InnoDB Compression 的努力」。
而在「Evolving MySQL Compression - Part 2」這邊繼續說明要怎麼生出對 Pinterest 比較有效的字典內容，作者把計算的工具放到 GitHub 上讓其他人可以用 (用 Python 寫的)：「pinterest/mysql_utils/zdict_gen/」。
可以看出來又增加不少壓縮率，這算是針對資料庫壓縮從 A 到 A+ 的行為吧...
kernel.org 將關閉 FTP 服務：「Shutting down FTP services」。
三月將關閉 ftp://ftp.kernel.org/，而 12 月將關閉 ftp://mirrors.kernel.org/。現在透過 HTTP 更新已經是主流了，對於 firewall 設定與 cache 都有比較好的支援。
Amazon Redshift 支援 Zstandard 壓縮資料：「Amazon Redshift now supports the Zstandard high data compression encoding and two new aggregate functions」。
Zstandard 是 Facebook 的人發展出來的壓縮與解壓縮方式，對比的對象主要是 zlib (或者說 gzip)，官網上有不少比較圖。目標是希望在同樣的壓縮處理速度下，可以得到更好的壓縮率。
Redshift 支援 Zstandard 等於是讓現有使用 gzip 的使用者免費升級的感覺...
看起來是因為 Trump 就職的關係，讓《一九八四》登上 Amazon 的銷售排行榜第一名：「George Orwell’s 1984 Is Now the #1 Bestselling Book on Amazon」。
在 Best Sellers in Books 這邊可以看到：
這篇的標題真直接 XDDD：「Disable Your Antivirus Software (Except Microsoft's)」。
其實差不多跟作者提到的一樣，防毒軟體的功用真的很少。真的要執行來路不明的檔案時 (或是確定會有一堆 malware 的中國軟體時 XDDD)，應該要丟到其他的 vm 裡面隔離，甚至是另外一台實體機器，而非靠防毒軟體擋下。
實在是有太多防毒軟體來亂了，為了達成目的把本來的安全設計打掉，然後再加上自己有問題的設計...
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」解釋這個新功能。
所以之後規劃前後端的架構時又有東西要考慮進去...
Percona 的人對 MySQL 5.7 的 OLTP RW 測試中，Performance Schema 的各種不同的功能對效能帶來的影響：「Performance Schema Benchmarks: OLTP RW」。
原文章裡有定義這些分別是打開哪些功能，這邊就跳過去... 重點是 default 值對效能的影響其實不算高，所以除非是想要壓榨每一分效能，不然其實可以考慮打開 (針對 OLTP RW 類似的應用)：
影響比較大的是 Stages 與 Waits 的部份。而 Mark Callaghan 在 comment 提到在 Performance Schema Event Timing 這邊有相關的資料... 看起來應該可以降低對 Stages 與 Waits 的效能衝擊。
Facebook 也支援 U2F (Universal 2nd Factor) 了：「Security Key for safer logins with a touch」。
之前買 Yubico 的 Yubikey 好像不支援 U2F (很久前買的版本)，好像該買幾顆玩具看看了... 剛剛翻了翻 Amazon，好像不少家都有支援 U2F，也許不一定要買 Yubico 的產品 :o
AWS CodeDeploy 推出了 BlueGreenDeployment 的功能：「AWS CodeDeploy Introduces Blue/Green Deployments」。
BlueGreenDeployment 的目的不計成本想辦法把上線的 downtime 壓到最低，而且當出問題時 rollback 的時間壓到最低的方法：
One of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. You usually need to do this quickly in order to minimize downtime.
Blue-green deployment also gives you a rapid way to rollback - if anything goes wrong you switch the router back to your blue environment.
其實就是直接跑兩個環境 (所以成本比較高)，一套跑舊的一套跑新的，然後在前面的 load balancer 切換：
The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible.