雞肋功能:AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists,就不需要自己在 security group 裡面針對一堆 IP 設重複的設定:「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了:

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用,主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響,如果沒有開 support ticket 調高限制,預設值是:

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時,需要設定「裡面會包含的最大數量」(可以到 1000),是一個你不知道為什麼要設定的東西,然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的),結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule,而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list,改成 15 條後,就可以在 security group 上面掛四次 prefix list (不同的 port),剛好吃完 60 條規則,第五個設定就完全掛不上去... (無論是用 prefix list,或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用:

  • 一開始就要設計好 prefix list 內的最大筆數,如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則,而是以最大筆數佔用,prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎,因為你可以設計機制,改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量,不會有浪費),然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到,都已經用 Terraform 這種工具了,加上你又不是只佔一條規則,我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

雲端免費服務的整理

在「free-for.dev」這邊看到的資料,裡面提到了「Free for developers」這個網站。

很多雲端服務都有提供 free tier,有些是一段期間免費,但有些是終身免費。光是用這些終身免費的部份,就能夠弄出不少東西了,只是很多人不知道有這些服務... 這個網站提供的列表則是很清楚的整理出來重點。

然後剛剛才發現 Amazon SES 服務本身每個月有免費的額度的 (頻寬另計):

When you call Amazon SES from an application hosted in Amazon EC2, you can send 62,000 messages per month at no charge. This Free Usage Tier benefit does not expire.

而且列表裡列的豐富度,看起來可以取代掉之前我很喜歡翻的 ToolsOfTheTrade,至少可以當作互補...

找數列的平均值

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

在 AWSUG Taiwan 上講的「用 AWS CodeDeploy 解決程式佈署」

前幾天在 AWSUG Taiwan 上講了「用 AWS CodeDeploy 解決程式佈署」,連結是投影片網址,因為在 Speaker Deck 上找不到 embed code 了,只好這樣連結過去。

話說回來,要上傳投影片的時候才發現,這兩個投影片 hosting 服務都跟微軟有些關係... 首先是 SlideShare 在 2012 被 LinkedIn 買下,然後 LinkedIn 在 2016 年賣給了微軟。

SpeakerDeck (或者說,Ordered List 這家公司) 本來在 2011 年賣給了 GitHub,但今年六月的時候被買回去了:

不知道買回去是不是跟微軟要買 GitHub 有關...

用郵件訂閱 Google Groups 上的 Mailing List

除了註冊 Google 帳號外,另外一個方式是透過 e-mail 直接登記。在這篇有人問到類似的問題:「How can I subscribe to a Google mailing list with a non-Google e-mail address?」。

不是 Accepted 那個答案,而是 c33s 給的答案:

Look for group email address in the heading of “Group email”, it will look like: Group email (Group Name)@googlegroups.com or visit the group web page on Google Groups, and click on “About this group”.

Send an email to (Group Name)+subscribe@googlegroups.com. +subscribe is the key, which is appended to the end of group’s email address. (Group Name) is the name of the group. Space is substituted by “-” (hyphen).

如果是 trac-announce 這個群組,就寄到 trac-announce+subscribe@googlegroups.com 這個位置,他會寄一封信回來確認,你把整封信回回去就可以了... (信裡有 auth key,寄回去就可以通過)

這個技巧在官方文件裡沒出現過... 但一直都是有效的 :o

Linus (又) 不爽了... XD

看得出來 Linus 對於 Intel 的行為很不爽:「Re: Avoid speculative indirect calls in kernel」。

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

那個 possibibilities 應該是 typo,但不知道為什麼看起來很有味道 XDDD

在 Trac 裡把參與者自動加到 cc list 裡面的 plugin

之前在 Trac 裡會想要達成「當使用者參與這張票時,自動加到 cc list 讓他收到後續的更新」這樣的功能。之前沒有仔細研究要怎麼在 Trac 裡面實踐,就直接在 template (也就是 site.html) 裡面用 javascript 在 client 做掉...

先拉出 authname

<script>
(function() {
    window.authname = "${authname}";
})();
</script>

然後再攔截網址裡有 /ticket/ 的頁面,當 form 符合條件時攔截 submit 事件,在 cc list 裡面沒有自己時把自己加進去:

// Add myself into cc list, if I am not in cc list now.
(function() {
    if (-1 === document.location.href.indexOf('/ticket/')) {
        return;
    }
    var cc_list = jQuery('input[name="field_cc"]').val().split(/[ ,]+/);
    for (var i in cc_list) {
        if (window.authname === cc_list[i]) {
            return;
        }
    }

    jQuery(function() {
        jQuery('form#propertyform').submit(function() {
            var cc = jQuery('input[name="field_cc"]');
            cc.val(cc.val() + ',' + window.authname);
        });
    });
})();

這樣是可以達成目的啦,但有種惡搞的感覺... 所以這次還是寫了個 Trac plugin 來解決,這樣不用擔心當網頁界面改版時會產生問題:「104corp/trac-addtocc-plugin」。

AWS Price List API

AWS 把價錢資訊也 API 化了:「New – AWS Price List API」。

除了可以透過 API 取得資訊外,還可以透過 Amazon SNS,在價錢有變動時得到通知:

You can also elect to receive notification via Amazon Simple Notification Service (SNS) each time we make a price change.

讓 billing 的各種計算變方便。

限制 WeeChat 中 buffers.pl 的寬度

WeeChat 上的 buffers.pl 是個很好用的套件,可以在側邊列出 channel,像是這樣:

weechat_bar_buffers_2008-09-02

其中一個特點是,左側的 channel list 會自動伸展到目前最長的 channel name。由於我用 WeeChat 連 Slack 提供的 IRC Gateway,加上最近提供多人交談的功能,就產生出這樣的 channel name:

#mpdm-gslin--persona--personb--personc--persond--persone----1

解法是限制側邊的寬度,用 /set buffers.look.name_size_max 32 後再 /save 存起來就可以了。是在「[buffers.pl] name_size_max adding crop suffix too soon in certain cases」這邊找到的關鍵字。

把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content,瀏覽器預設值不會直接全部擋掉,而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換,讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後,接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了,接下來要不要進 HSTS Preload List 就看大家自己的想法了。