Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了

Twitter 上看到的:

WoSignStartCom 的移除會發生在 61 版,而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明,stable 應該會在九月出 61 版而生效:

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

美國政府暗中介入好萊塢的劇本,影響大眾對戰爭的看法

透過 Freedom of Information Act (FOIA) 取得的資料顯示美國政府 (包括了五角大廈、CIA、NSA) 如何介入好萊塢,影響大眾對於戰爭的看法:「EXCLUSIVE: Documents expose how Hollywood promotes war on behalf of the Pentagon, CIA and NSA」。

灰標「US military intelligence agencies have influenced over 1,800 movies and TV shows」可以看出影響的層面。

The documents reveal for the first time the vast scale of US government control in Hollywood, including the ability to manipulate scripts or even prevent films too critical of the Pentagon from being made — not to mention influencing some of the most popular film franchises in recent years.

從很意想不到的地方介入... 引用其中一個說明:

Jon Voight in Transformers — in this scene, just after American troops have been attacked by a Decepticon robot, Pentagon Hollywood liaison Phil Strub inserted the line ‘Bring em home’, granting the military a protective, paternalistic quality, when in reality the DOD does quite the opposite.

用照片打鑰匙的服務

Bruce Schneier 的 blog 上看到 KeyMe 這個服務:「Now It's Easier than Ever to Steal Someone's Keys」。

你把鑰匙的照片拍下來,透過 app 上傳付款後,他就把鑰匙寄給你 XDDD

查了一下資料,在五年前 (2012) 的時候就有人做遠距離攻擊的研究了:「60 公尺外,拍照攝影就可以重製鑰匙...」,所以有好的方面,也有邪惡的方面...

用 awk 取代 grep 的工作

在「SKIP grep, use AWK」這篇看到關於使用 awk 取代 grep 的介紹。

作者提到這樣的替換:

$ [data is generated] | grep something | awk '{print $2}'
$ [data is generated] | awk '/something/ {print $2}'

還有這樣直接替換 grep 的方式:

$ [data is generated] | awk '/something/'

以及 -v 的替換:

$ [data is generated] | awk '/something/ {next} 1'
$ [data is generated] | awk '! /something/'

不過感覺還好耶...

GitHub 引入 Code Owner 的概念

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:

Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了

Let's Encrypt 把時間表喊出來了,預定在 2018 年年初開放使用:「Wildcard Certificates Coming January 2018」。

Wildcard SSL Certificate 會需要走新的 ACME v2 協定認證:

Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

跟前陣子提到的「ACME v2 API Endpoint Coming January 2018」是相同的時間。

這好讚...

「把工作自動化」的討論

最近在 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 有興趣的人可以去圍觀看一看下面的回應...

Microsoft Blogs 上 TDD 的戰文...

文章標題就直接寫「#NoTDD」的戰文 XDDD

列了 Pros (一行) 跟 Cons (超長 XDDD):

Pros

  • We end up with tests that verify the behavior of the code and help prevent regressions

這個是 TDD 的目的。而 Cons:

Cons

  • It takes us longer to write code using TDD
  • The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class works, I often have to fix tests for other classes.
  • Because I don’t have low coupling, I need to use mocks or other tests doubles often. Tests are good to the extent that the tests use the code in precisely the same way the real system uses the code. As soon as I introduce mocks, I now have a test that only works as long as that mock faithfully matches the behavior of the real system. If I have lots of mocks – and since I don’t have low coupling, I need lots of mocks – then I’m going to have cases where the behavior does not match. This will either show up as a broken test, or a missed regression.
  • Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design.

這四個問題講的是時間與能力兩個因子的作用,轉一個角度來討論其實是:如果 junior engineer 可以寫出好的測試,他們就不叫 junior engineer 了... 而 senior engineer 是稀缺資源,讓他們多花時間寫出「好的測試」未必是划算的。

反而是另外一種常見的方式常常跟 TDD 在對抗:透過 QA team 在完成後測試,尤其是用手動測試的 QA team XDDD

這個方法很簡單,而且行之有年。而且很無奈的,跟一般軟體工程所期望的相反,junior engineer 就可以做的不錯,所以人力的部份相當好 scale,而品質也有不錯的水準 (畢竟是直接測實際的功能了)。

剛好前陣子有提到另外一篇論文也在討論 TDD 的效果 (參考「又一篇戰文:討論 TDD 的過程」這邊),也有類似的反思。

前陣子在 Twitter 上看到這則也是很有趣,拿來當結尾 XDDD: