GitHub 的 Webhook IP 增加網段

GitHub 發出的 Webhook 的來源位置增加網段了:「Webhook IP addresses are changing」。

目前是 192.30.252.0/22,在 2019/04/09 後將會增加 140.82.112.0/20,如果有用防火牆的人需要修改設定,把多的這段加上去。

去年就把這個網段放進 API 裡,但一直都還沒啟用,所以如果你有透過 API 動態更新防火牆規則的話就沒問題,現在是最後登機廣播了:

This block of IPs has been in the /meta API endpoint since May 2018, but we wanted to announce this update in case you missed it.

Word2Vec:透過向量猜測其他詞彙的意思

2013 年時在「Automatic Translation Without Dictionaries」這邊看到關於機器翻譯時的自我學習方式,裡面提到了「How Google Converted Language Translation Into a Problem of Vector Space Mathematics」這篇報導,而裡面提到的論文則是 Google 發表在 arXiv 上的「Exploiting Similarities among Languages for Machine Translation」這篇。

最近看到「The Illustrated Word2vec」這篇,把五年多前的記錄交叉拉出來看... 這個算式算是給了大家基本的想法,透過公式來解釋文字的意義:

拉出這樣的關係後,就有機會學習新的詞彙... 進而用在其他語言的翻譯上。

AWS 推出更便宜的儲存方案 Glacier Deep Archive

AWS 推出的這個方案價錢又更低了:「New Amazon S3 Storage Class – Glacier Deep Archive」。

在這之前在 us-east-1S3 最低的方案是 Glacier Storage,單價是 USD$0.004/GB (也就是 $4/TB)。

而這次推出的 Glacier Deep Archive Storage 在同一區則是直接到 USD$0.00099/GB ($0.99/TB),大約是 1/4 的價錢。

Glacier Deep Archive 在取得時 first byte 的保證時間是 12 小時,另外最低消費是 180 天:

Retrieval time within 12 hours

先前就有的 Glacier Storage 則是可以在取用時設定取得的 pattern (會影響 first byte 的時間),而最低消費是 90 天:

Configurable retrieval times, from minutes to hours

Pricing for each of these metrics is determined by the speed at which data is requested based on three options. "Expedited" queries <250 MB are typically returned in 1-5 minutes. "Standard" queries are typically returned in 3-5 hours. "Bulk" queries are typically returned in 5-12 hours.

多一個更便宜的選擇可以用。

Amazon Aurora with MySQL 5.7 支援 GTID

雖然在 AWS 上服務的 HA 大多都不需要自己管理,但備份機制 (甚至異地備援) 還是要自己規劃,Amazon Aurora with MySQL 的 GTID 功能算是讓這塊多了一個選擇:「Amazon Aurora with MySQL 5.7 Compatibility Supports GTID-Based Replication」。

公告裡面有提到 Aurora 自己的 replication 還是用自己的機制,而非透過 GTID 做的:

This provides complete consistency when using binlog replication between an Aurora database and an external MySQL database. Your replication won’t miss transactions or generate conflicts, even after failover or downtime. (Note that replication within an Aurora cluster doesn't use binlog files, so the GTID feature doesn't apply.)

不過就 Aurora 的架構來說,整個 cluster 比較像是看作一個整體,用 binlog + position 應該是夠用的?也不會有 failover 時的 conflict 問題?不確定用 GTID 的好處會在哪邊,還得再想看看...

FTC 找了七家 ISP 業者要研究隱私問題...

FTC 要研究 ISP 手上有哪些客戶的資料,然後提供給誰:「FTC Seeks to Examine the Privacy Practices of Broadband Providers」。

The Federal Trade Commission issued orders to seven U.S. Internet broadband providers and related entities seeking information the agency will use to examine how broadband companies collect, retain, use, and disclose information about consumers and their devices.

包括了這七家,裡面的六家都算大業者,被 FTC 納入不算意外,第七家包括了 Google Fiber Inc.,到時候不知道會有什麼資訊出來:

The orders were sent to: AT&T Inc., AT&T Mobility LLC, Comcast Cable Communications doing business as Xfinity, Google Fiber Inc., T-Mobile US Inc., Verizon Communications Inc., and Cellco Partnership doing business as Verizon Wireless.

看了一下 PDF,應該是 45 天後要回覆,加上整理的時間,應該是下半年會看到一些整理?

找數列的平均值

2016 年的文章,不過算是經典的題目,所以最近又冒出來了。要怎麼找數列的平均值:「Calculating the mean of a list of numbers」。

You have a list of floating point numbers. No nasty tricks - these aren’t NaN or Infinity, just normal “simple” floating point numbers.

Now: Calculate the mean (average). Can you do it?

你有一串浮點數 (沒有 NaN 與 Infinity),要怎麼找出平均值。要考慮的包括:

  • 第一個要處理的就是設計演算法時各種會 overflow 的情況。
  • 降低誤差。
  • 合理的計算量。

好像很適合拿來 data team 面試時互相討論的題目?因為「平均值」是個商業上本來就有意義的指標,而且從 time-series events 灌進來的資料量有機會產生各種 overflow 情境,或是精確度問題,所以這個問題其實是個在真實世界上會遇到的情境。

想了一下,如果是 integer 的確是簡單很多 (可以算出正確的值),但如果是 float 類型真的難很多:

It also demonstrates a problem: Floating point mathematics is very hard, and this makes it somewhat unsuitable for testing with Hypothesis.

馬上想到的地雷是在 IEEE 754 的 float 世界裡,2^24 + 1 還是 2^24

#include <math.h>
#include <stdio.h>

int main(void)
{
    int i;
    float a;

    for (i = 0; i < 32; i++) {
        a = pow(2, i);
        printf("2^%d     = %f\n", i, a);

        a += 1;
        printf("2^%d + 1 = %f\n", i, a);
    }
}

然後在這邊可以看出差異:

2^23     = 8388608.000000
2^23 + 1 = 8388609.000000
2^24     = 16777216.000000
2^24 + 1 = 16777216.000000

Zoom 也要 IPO 了...

最近的資訊網路圈子 IPO 案子好多,其中一個比較值得注意的是 Zoom:「Zoom, a profitable unicorn, files to go public」。

這家公司不像 PagerDutyPinterest,這兩家是沒賺過錢就丟單子出來了,而 Zoom 是有賺錢還打算出來 IPO:

Zoom, which raised a total of $145 million to date, posted $330 million in revenue in the year ending January 31, 2019, a remarkable 2x increase year-over-year, with a gross profit of $269.5 million. The company similarly more than doubled revenues from 2017 to 2018, wrapping fiscal year 2017 with $60.8 million in revenue and 2018 with $151.5 million.

啊不過 Zoom 真的蠻好用的,一群人在不同地方要討論事情時,用電子白板或是分享畫面都還不錯... 這幾天跟不是資訊圈子的人在用也都有很正面的 feedback。

Cloudflare 自己用 Rust 寫了一套相容 WireGuard 協定的軟體

Cloudflare 發現目前符合他們條件的 WireGuard 軟體效能不夠好,所以就用 Rust 寫了一套出來:「BoringTun, a userspace WireGuard implementation in Rust」,軟體在「BoringTun」這邊可以看到。

Cloudflare 的條件是 userspace 以及多平台,市面上有 wireguard-go 符合這兩個條件,但效能不太好,所以就下去寫了。

GitHub 的頁面上可以看出還在剛開始的階段,很多頁面都還只有個雛型... 等這幾天陸陸續續更新後再回來看好了。

被動靈氣加成:用 git rerere 解決同樣的 conflict 問題

Git 上一個很好用的設定,不需要改變原來的工作模式,有種「被動靈氣」的感覺 XD

Twitter 上看到這則推:

裡面提到了 git rerere 這個指令,投影片裡面雖然有給方法,不過一時間沒看懂... (oops)

找了一下官方文件與其他文件後發現其實意外的簡單,就是在 .gitconfig 設定檔內開啟個 flag 後就沒事了,其他的動作照以前的方式走。Git 的被動技能就是在每次遇到 conflict 以及解決的時候就會記錄下來,當下次遇到同樣的情況就自動幫你解。

先開起來再說,之後來看看有什麼副作用再來抱怨 XDDD

在 Galera Cluster 上的 DDL 操作 (e.g. ALTER TABLE)

Percona 整理了一份關於 Galara Cluster 上 DDL 操作的一些技巧,這包括了 Percona XtraDB ClusterMariaDB 的版本:「How to Perform Compatible Schema Changes in Percona XtraDB Cluster (Advanced Alternative)?」。

在不知道這些技巧前,一般都是拿 Percona Toolkit 裡的 pt-online-schema-change 來降低影響 (可以降的非常低),所以這些技巧算是額外知識,另外在某些極端無法使用 pt-online-schema-change 的情境下也可以拿來用...

裡面的重點就是 wsrep_OSU_method 這個參數,預設的值 TOI 就是一般性的常識,所有的指令都會被傳到每一台資料庫上執行,而 RSU 則是會故意不讓 DDL 操作 (像是 ALTER TABLE) 被 replicate 到其他機器,需要由管理者自己到每台機器上執行。

利用這個設定,加上透過工具將流量導到不同後端的資料庫上,就有機會分批進行修改,而不需要透過 pt-online-schema-change 這種工具。