DigitalOcean 送出 Form S-1

Hacker News Daily 上看到的消息,DigitalOcean 送出 Form S-1:「d898181ds1.htm」,在 Hacker News 上也有不少討論:「DigitalOcean S-1 (sec.gov)」。

這個消息跟 2020 年年初的裁員也可以交叉看一下:「DigitalOcean 裁員」,另外在 TechCrunch 上也有報導:「DigitalOcean’s IPO filing shows a two-class cloud market」。

Hacker News 上蠻多人在抱怨 DO 的產品,像是機器的效能,操作界面的穩定性,還有客服的反應... 不過這些跟 IPO 倒是沒什麼關係,重要的是每年的營業額有做出來:

Per its S-1 filing, DigitalOcean generated $203.1 million in 2018 revenue, $254.8 million in 2019 and $318.4 million in 2020. The company closed 2020 out with a self-calculated $357 million in annual run rate.

自己用的話應該還是偏好 VultrLinode...

GET 與 POST 的差異

看到這篇在講 HTTP (& HTTPS) 裡面 GET 與 POST 的差異,剛好把一些標準的定義拿出來翻一翻,算是複習基本概念:「Get safe」。

第一個基本概念主要是 idempotence (& idempotent),重複被呼叫不會造成狀態的再次改變:

Idempotence ([...]) is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application.

數學定義是這樣跑:

An element x of a magma (M, •) is said to be idempotent if:

x • x = x.

If all elements are idempotent with respect to •, then • is called idempotent. The formula ∀x, x • x = x is called the idempotency law for •.

這點在 HTTP 標準 (RFC 7231) 裡面的定義也類似:

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

第二個基本概念是 Safe method (也是在同樣的 RFC 裡被提到),主要的思想是 read-only,這也是文章作者的標題要講的事情:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

然後標準的 HTTP method 是有定義的:

   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+

不過文章裡面提到的第一個例子並沒有很好,POST 不保證 safe 沒錯,但不代表 safe operation 就不能用 POST。

這邊用 URI resource 的概念 (以及 SEO?) 或是用 Post/Redirect/Get 的概念來說明會比較好:

<form method="get" action="/search">
<input type="search" name="term">

不過文章後續提到的問題的確就是我自己都會犯錯的問題:

“Log out” links that should be forms with a “log out” button—you can always style it to look like a link if you want.

“Unsubscribe” links in emails that immediately trigger the action of unsubscribing instead of going to a form where the POST method does the unsubscribing. I realise that this turns unsubscribing into a two-step process, which is a bit annoying from a usability point of view, but a destructive action should never be baked into a GET request.

這兩個動作都會造成 server 端的狀態改變,不應該用 GET,而我自己常常忘記第一個... 這邊其實可以用 form 產生 POST 需求,並且用 css 效果包起來,達到看起來跟一般的連結一樣。

寫起來讓自己多一點印象,之後避免再犯一樣的錯誤...

AirBnB 送出 Form S-1

Hacker News Daily 上看到 AirBnB 送出 Form S-1 了:「d81668ds1.htm」,在 TechCrunch 上面也有一系列的文章可以看...

印象中差不多試 2018 年就有一些傳言了,結果在 2019 年的時候沒看到,到了 2020 年被 COVID-19 重挫... 但長期來看是個成功的商業模式,所以 2020 年不論是有要上還是沒有要上都不意外,現在丟出 Form S-1 給了個答案。

接下來就是等開張那天的股價了...

五家公司提出 Form S-1:Asana、Unity、Snowflake、sumo logic、JFrog

Hacker News 上看到五家公司都準備要上市而丟出 Form S-1 的情況頗熱鬧的,申請文件可以在「ASANA, INC. (d855753ds1.htm)」、「UNITY SOFTWARE INC. (d908875ds1.htm)」、「Snowflake Inc. (snowflakes-1.htm)」、「Sumo Logic, Inc. (d821436ds1.htm)」與「JFrog Ltd. (d841831ds1.htm)」這邊翻到。

當然很多人都有類似的疑問,就是為什麼大家突然都急著要 IPO,在「Ask HN: There are 5 S-1 posts on the front page, what explains the rush?」這邊有些討論,而且也提到了一些有趣的現象,像是這五家公司到目前都是虧錢的,不過這已經是這幾年的常態了,倒是沒什麼需要大驚小怪的:

Asana lost 120m last year
Snowflake lost 350m last year
Unity lost 160m last year
Sumo Logic lost 43m last year
Jfrog lost 400k last year

Out of curiosity, is it normal for companies to IPO this far away from profitability, or is this a recent tech thing? I feel like it was a big deal when uber IPO'd so far away from profitability, now it seems standard.

有人猜測跟美國選舉有關,不過也就只有帶出來猜測...

Cloudflare 遞出 S-1

Cloudflare 遞出 Form S-1:「S-1」。TechCrunch 有些整理:「Cloudflare files for initial public offering」。

一樣是燒錢狀態上市,不過相較於其他家燒的速度算是慢的,但成長速度很驚人:

As far as money goes, Cloudflare is — like other early-stage technology companies — losing money. But it’s not losing that much money, and its growth is impressive.

預定在 NYSE 上使用代碼「NET」:

The company will trade on the New York Stock Exchange under the ticker symbol “NET.”

不知道為什麼有種泡沫感...

Slack 丟出 S-1 要 IPO...

最近一波 IPO 潮,現在輪到了 Slack

Form S-! 的資料可以在「slacks-1.htm」這邊抓到,裡面有些數字可以看看,懶的看的話可以看 TechCrunch 的整理:「Slack files to go public, reports $138.9M in losses on revenue of $400.6M」。

算是相當快的,2013 年八月到現在還不到六年...

PagerDuty 向 SEC 遞出 S-1 了 (IPO)

在「pagerdutys-1.htm」這邊可以看到 PagerDuty 遞出 Form S-1 了,翻了一下 TechCrunch 也有報導:「PagerDuty just filed its S-1」。

PagerDuty 主要的服務是監控服務回報狀況後的後續流程,在組織大一點的公司會拿來用,不過不怎麼便宜... 印象中服務品質沒有拉開差距,而同質性的服務低他不少價錢。

有幾個數字可以看,先是估值:

PagerDuty was valued at $1.3 billion last fall when it closed on $90 million in Series D funding led by T. Rowe Price Associates and Wellington Management. Earlier backers Accel, Andreessen Horowitz and Bessemer Venture Partners also joined the round, which brought the company’s total funding to $173 million.

然後 VC 持股 55%:

According to the S-1, venture investors currently own about 55 percent of the company. Andreessen Horowitz owns the biggest stake, with 18.4 percent of its shares sailing into the IPO. Accel meanwhile owns 12.3 recent, Bessemer owns 12.2 percent, Baseline Ventures owns 6.7 percent, and Harrison Metal owns 5.3 percent.

以及獲利問題:

PagerDuty, which employed 500 employees as of last fall, has never been profitable according to its filing, which says it generated a net loss of $38.1 million for the fiscal year ended January 31, 2018. (It saw revenue of $79.6 million during the same period.)

S-1 文件裡有張圖裡也有相關的營運數字:

在 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」。

利用隱藏的 form input 加上自動完成功能取得敏感資料

anttiviljami/browser-autofill-phishing 這邊示範了怎麼用隱藏的 form input 與自動完成功能取得敏感資料。在這邊可以看到示範 (把 POST 丟到 httpbin 上看 response)。

想法不算困難,但好像也不是很好防... 關掉 autofill 是比較簡單的解法 (我是裝好瀏覽器就會關掉,不過好像很多人都喜歡用這個功能),所以這個問題就丟回給這些 browser vendor 想了 :o