幹壞事是進步最大的原動力
這兩天又遇到一次，這應該是 Laravel 裡設計比較奇怪的地方，既然是跑 PHPUnit 的環境，為什麼不預設在錯誤發生時把完整的 stack 拋到 console...
這邊的解法是參考「Laravel: How to enable stacktrace error on PhpUnit」這篇的解答。
舊版需要自己丟 handler 進去 (5.4 以及之前的版本)，在 5.5+ (寫這篇時最新的穩定版本已經是 5.6) 有內建 withoutExceptionHandling() 可以用，所以在 tests/TestCase.php 內搞定 setUp()：
protected function setUp()
{
parent::setUp();
$this->withoutExceptionHandling();
}
不知道有沒有機會直接進 Laravel 的 package 設定裡面...
上一篇「PChome 24h 連線會慢的原因...」寫到 DNS resolver 會倒在路邊，但沒寫會怎麼倒... 因為規格書上沒有寫當問不到要問的東西時要怎麼處理，所以每一家處理的方式都不太一樣。
我把對各 DNS resolver 查詢 100 次的結果放在 GitHub Gist 上：「Query 24h.pchome.com.tw」，大家都是回 SERVFAIL，只是時間不一樣 (最後一個 x.xxxx total 的部份表示實際秒數，wall clock)。
先看這次的主角好了，HiNet 的 168.95.1.1 與 168.95.192.1，同時也應該是 PChome 24h 服務使用人數最多的 DNS resolver。
這兩個 DNS resolver 在遇到問題時不會馬上回 SERVFAIL，加上業界有小道消息說中華自己改了不少 code，所以跟一般的 open source software 行為不太一樣。由於看不到 PChome 端的 DNS packet，所以只能就行為來猜... 應該是在第一輪都查不到後，會先 random sleep 一段時間，然後再去問一次，如果第二次還是失敗的話才回應 SERVFAIL。
這個 random sleep 看起來可能是 10 秒，因為數據上看起來最長的時間就是這個了。
SEEDNet 的 139.175.1.1 以及 Google 的 8.8.8.8 都沒這個問題，都會馬上回應 SERVFAIL。
前陣子新出的 9.9.9.9 (參考「新的 DNS Resolver：9.9.9.9」) 則是有些特別的狀況，可以看到前面有三個 query 很慢 (第 2、3、5 三行)，但後面的速度就正常了。可能是新加坡那邊有三台伺服器在服務 (目前我這邊測試的機器到 9.9.9.9 會到新加坡)，在第一次遇到都沒有答案時會有特殊的演算法先確認，之後就會 cache 住？
所以各家 DNS resolver 反應都不太一樣，然後最大那家有問題 XD
24h.pchome.com.tw 慢一次，ecvip.pchome.com.tw 再慢一次，圖片的 a.ecimg.tw 再慢一次，一個頁面上多來幾個 domain 就會讓人受不了了 XD
其實我只要改成 8.8.8.8 或是改走 proxy.hinet.net 就可以解決啦，但還是寫下來吧 (抓頭)。
在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題：
除了可以在維基百科上面看到外，比較正式的說明可以參考 RFC 6555：「Happy Eyeballs: Success with Dual-Stack Hosts」，其中在「6. Example Algorithm」就有提到 Google Chrome 與 Mozilla Firefox 怎麼實做 Happy Eyeballs：
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.
- Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
- Initiate a connection attempt with the first address in that list (e.g., IPv6).
- If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
- The first connection that is established is used. The other connection is discarded.
If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
Other example algorithms include [Perreault] and [Andrews].
可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來，就會儘快往另外一個 address family 嘗試)，而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。
這次的情況是 DNS query 很慢，就會導致還是一開始就很慢，Happy Eyeballs 沒辦法解決這個問題。
不過話說回來，我是有印象知道有這個演算法，但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)
Stack Overflow 的內文其實有點奇怪的誤導... 主要是分析在 Stack Overflow 上 Python 成長的趨勢：「The Incredible Growth of Python」。
但一開始的分析是做高收入國家的部份：
但如果你捲到最下面，即使是非高收入的國家也是一樣急遽成長，只是沒那麼明顯：
Anyway，回到高收入國家的部份，如果用模型預測的話：
另外列出 YoY 成長：
這篇用高收入這個分法有種在炒話題的感覺...
最近在 The Workplace Stack Exchange 上還蠻火紅的一篇文章：「Is it unethical for me to not tell my employer I’ve automated my job?」。
作者的全職工作是從系統上抓資料出來，貼到 spreadsheet 上 (也許是 Excel？)，這份工作的薪資還不錯，然後作者寫程式自動化掉後發現他每禮拜只需要做一兩個小時了：
There might be amendments to the spec and corresponding though email etc, but overall, I spend probably 1-2 hours per week on my job for which I am getting a full time wage.
然後在糾結要不要跟雇主講，跑上來發文 XDDD 有興趣的人可以去圍觀看一看下面的回應...
看到「The OpenVPN post-audit bug bonanza」這個只有苦笑啊...
作者在 OpenVPN 經過一連串的安全加強後 (包括 harden 計畫與兩個外部單位的程式碼稽核找到不少問題)，決定出手挖看看：
After a hardening of the OpenVPN code (as commissioned by the Dutch intelligence service AIVD) and two recent audits 1 2, I thought it was now time for some real action ;).
然後就挖出不少問題了...
可以看到作者透過 fuzzing 打出一卡車，包含了不少 crash XDDD：(然後有一個是 stack buffer corruption，不知道有沒有機會變成 RCE)
用 HTTPS Everywhere 沒什麼感覺，但對於一般人應該不簡單，所以 Nick Craver (根本就是他們家非正式的 PR Engineer XDD 他這幾年寫了不少內部的資訊...) 寫了一篇關於上 HTTPS 的故事：「HTTPS on Stack Overflow: The End of a Long Road」。
其中他們為了支援舊設備 (沒有支援 SNI 的)，決定直接把所有 wildcard 類的 SSL certificate 都包進去 (另外找 DigiCert 處理)：
然後中間提到這個真的頗無奈的，抱怨 SVG 的 XML... XDDD：
Finding and killing these was a little fun because you can’t just search for "http://". Thank you so much W3C for gems like this:
<svg xmlns="http://www.w3.org/2000/svg"...
一條辛苦路 XD
被拿出來當 PR 宣傳了：「Stack Overflow: Helping One Million Developers Exit Vim」。
由於 Vim 是 Unix-like 系統一定會內建的 editor，所以常常被拿來放在 tutorial 裡面 (考慮到普及性，但完全不熟的初學者就...)，或是不小心在輸入 vipw 或是 visudo 之類的指令就中獎了：
可以看到 pageview 破一百萬次了 XDDD 而且流量也都很穩定：
依照地區來拆開的話：(不過沒有照人口數正規化...)
然後做交叉分析，看這些卡在 Vim 的人平常是看什麼其他的文章：
回到資料分析的角度來看，這些東西可以透過有 cookie 的 access log 做到。有 access log 後可以用 Google Cloud 的 BigQuery，也可以用 AWS 家的 Amazon Athena 做。
在「About the security content of iOS 10.3.1」這邊的說明：
Available for: iPhone 5 and later, iPad 4th generation and later, iPod touch 6th generation and later
Impact: An attacker within range may be able to execute arbitrary code on the Wi-Fi chip
Description: A stack buffer overflow was addressed through improved input validation.
CVE-2017-6975: Gal Beniamini of Google Project Zero
這描述看起來就不太妙...
Update：被提醒後仔細看了一下，是 1.8 預設生效 (但保留選項切回來 debug)，如果沒問題的話 1.9 把舊的方式拔乾淨：
Assuming things go smoothly, we will remove stack re-scanning support when the tree opens for Go 1.9 development.
標題就不改了... 以下原文。
在「Sub-millisecond GC pauses」這邊看到的。Golang 想辦法將 GC 造成的影響降低：「Proposal: Eliminate STW stack re-scanning」。
目標是解決最大的 GC pause 來源：
As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.
然後拿新的解法來戰，目前初步的測試看起來可以降到 50µs (== 0.05ms)：
We propose to eliminate the need for stack re-scanning by switching to a hybrid write barrier that combines a Yuasa-style deletion write barrier [Yuasa '90] and a Dijkstra-style insertion write barrier [Dijkstra '78]. Preliminary experiments show that this can reduce worst-case STW time to under 50µs, and this approach may make it practical to eliminate STW mark termination altogether.
在「runtime: eliminate stack rescanning · Issue #17503 · golang/go」這邊可以看到進度，現在已經在 master branch 上了，看起來會在 1.9 的時候被放出來... 不過 worst case 的時間上修了 XDDD
The high level summary is that this reduces worst-case STW time to about 100 µs and typical 95%ile STW time to 50 µs (assuming, of course, that the OS doesn't get in the way and that the system isn't otherwise overloaded).
但看起來應該還是很大的效能改善，尤其是 CPU bound 的應用？