Tag Archives: resource

Facebook 的招募狀況

Facebook 的各種醜聞知道招募變難 (而且醜聞沒停過),但變得多困難則是第一次看到報導:「Facebook has struggled to hire talent since the Cambridge Analytica scandal, according to recruiters who worked there」。

新鮮人的接受從 85% 掉到 35%~55%,依據不同的學校而有差異:

Among top schools, Facebook’s acceptance rate for full-time positions offered to new graduates has fallen from an average of 85% for the 2017-2018 school year to between 35% and 55% as of December.

Among top schools, such as Stanford, Carnegie Mellon and Ivy League universities, Facebook’s acceptance rate for full-time positions offered to new graduates has fallen from an average of 85% for the 2017-2018 school year to between 35% and 55% as of December, according to former Facebook recruiters. The biggest decline came from Carnegie Mellon University, where the acceptance rate for new recruits dropped to 35%.

工程師則是從 90% 掉到 50%:

The company has seen a decline in its job offer acceptance rates to software engineer candidates from nearly 90% in late 2016 to almost 50% in early 2019.

Facebook 發言人 Anthony Harrison 否認,不過沒有給出說明:

After the publication of this story, Harrison contacted CNBC to say "these numbers are totally wrong."

Facebook disputed the accuracy of the recruiters' accounts, but declined to point out any specific points that were wrong.

Hacker News 上的討論也蠻有趣的:「https://news.ycombinator.com/item?id=19931977」,有不少其他的觀察。

Amazon Lightsail 試用兩天的心得...

前幾天在「Amazon Lightsail 降價...」這篇文章提到了 Lightsail 這波降價還蠻有競爭力的,但之前看過「Is the fact that Lightsail instances are just renamed T2 instances that run on CPU credits actually documented anywhere?」這篇,大概知道 Lightsail 後面其實就是 t2 系列的機器,只是在這次 t3 出來後的改版不知道有沒有順便一起改...

前幾天直接把 blog + wiki 整個搬過去看看。本來在 Vultr 的主機是 1GB RAM,就挑了對應的方案搬過去... 如果還是 t2 的話,應該就會是 t2.micro 的機器。

由於搬家前面一天都在弄各種環境,所以應該累積了不少 CPU credit,實際的情況還是要等 DNS 指過來超過一天後才會知道。在剛剛跑了一整天,把 CPU credit 吃差不多後確認了,應該還是 t2.micro,baseline 在 10% (被降速了):

這樣的話就維持在 Vultr 好了... CPU 資源看起來還是用超過了。

nginx 的 HTTP/2 要支援 Server Push 了

Twitter 上看到 nginx 的 HTTP/2 也要支援 server push 的消息了:

看起來是只要送出對應的 HTTP Header,後續 nginx 就會幫你處理...

這功能總算是要進 nginx 了... 像是透過 cookie 判斷使用者是第一次瀏覽,就透過 server push 預先把 css/js 丟出去,加速頁面呈現。

CPU 成為現代網站的速度瓶頸

在「Tracking CPU with Long Tasks API」這邊提到的現象,雖然是在提新的 API,不過裡面提到了很重要的問題。

以前的網站因為 js 都沒有用的那麼多,所以主要的瓶頸在於網路速度。所以大家最佳化的方向都是往「如何讓傳輸量變小」的方式進行,像是各類 js 的 minify,甚至是對 Gzip 演算法的暴力改善 (維持相容的 Zopfli,以及新的 Brotli):

In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.

而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動),於是對於 CPU 的能力就愈來愈要求:

According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.

而手機也愈來愈普及,CPU 的能力相較起來就更嚴峻了...

利用 pop 視窗藏起來的挖礦腳本

即使把主頁面關掉後,會因為藏起來的 popup window 而繼續挖礦:「Websites use your CPU to mine cryptocurrency even when you close your browser」,原文的 GIF 圖片就可以看出來怎麼做的了:

我是因為用了 One Window 可以避免有 pop window 產生 (都會被這個 extension 轉成 tab),另外用像是 hoshsadiq/adblock-nocoin-list 的 block ruleset 也不錯...

Amazon EC2 推出 T2 Unlimited,可以付費超量使用 CPU

Amazon EC2t2 系列的機器上推出 T2 Unlimited:「T2 Unlimited – Going Beyond the Burst with High Performance」。

這不是新的機種,而是現有的機器上可以超量使用 CPU credit,AWS 會另外收費。


us-east-1 來算,其實相當便宜,看不出什麼 penalty fee:t2.micro 的 CPU credit 是 10% baseline,每小時單價是 $0.0116,所以先有個 100% 數字是 $0.116 的概念 (如果所有東西都是十倍)。

us-east-1 的 T2 Unlimited 是 $0.05 vCPU-hour,這樣看起來其實不賴?風險應該是在於不保證可以拿到多的 CPU resource...

可能要重新算一下 c4c5 的使用方式了...

另外雖然文章後面寫了一大串,但對照 region 表後,看起來是所有的區域都支援了:(美國政府的 region 除外)

You can launch T2 Unlimited instances today in the US East (Northern Virginia), US East (Ohio), US West (Northern California), US West (Oregon), Canada (Central), South America (São Paulo), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Mumbai), Asia Pacific (Seoul), EU (Frankfurt), EU (Ireland), and EU (London) Regions today.

Facebook 與 Google Chrome 以及 Firefox 的人合作降低 Reload 使用的資源

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: immutable header.

Firefox 的人也寫了一篇「Using Immutable Caching To Speed Up The Web」解釋這個新功能。


CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.


  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

新的 AWS 帳號將會自動啟用 Long EC2 Resource ID

新的 AWS 帳號將會自動啟用長版的 Resource ID:「New accounts default to long EC2 resource IDs on March 7」。

還是可以 opt-out 改回來,不過官方還是建議儘量用長的 ID 測試,因為今年年底將全面強迫使用:

We recommend testing longer IDs before transitioning; however, if you have not yet tested your systems for compatibility with the longer format, you still have the option to opt out and receive shorter IDs until early December 2016.

Amazon API Gateway 支援 CORS 了

在「Enable CORS in Amazon API Gateway」這邊看到 Amazon API Gateway 支援 CORS (Cross-origin resource sharing) 了,這樣前端頁面就可以直接 call 進去使用了...

文件可以在「Enable CORS for a Method in API Gateway」這邊看到,主要就是這個頁面的設定:

看起來是個小功能,但卻影響很大... 這代表又有一大塊開發者會進去研究。