Kagi 常態公開他們的訂閱數量

在「Kagi Search Stats (kagi.com)」這邊看到 Kagi 公開了訂閱數量:「Kagi Search Stats」。在「Changelog」裡面可以看到發表的資訊,可以看到也沒有給太多解釋。

現在是 7945 users + 232 family plan 的收入 (但不確定到底是合併算還是分開算),另外大約是 150K/day (週間) 與 110K/day (週末) 的 query 量。

成長速度看起來不太快,目前看起來是一個禮拜大概多 100 users,如果等比例的話,一年大概多 5k users?

交叉看一下去年九月的時候寫的資料,差不多就剛好是一年前的文章:「Kagi status update: First three months」。

一年前支出的部分大約是 $26K/mo 左右;粗粗算一下現在的 query 量,假設還是一樣的成本結構,現在大約是 $50K/mo,但今年多了很多 AI 的 API cost,所以應該還會再加上去...

We are currently serving around 2.1M queries a month, costing us around $26,250 USD/month.

一年前提到有 2.6k users,當時只有單一方案 US$10/mo;現在是 7.9k users,不過方案比較多,而且後來進來的人費用有調漲,如果還是拿以前的單價來算的話大約是 US$79k。

Kagi search is currently serving ~2,600 paid customers.

當年提到 $26k/mo 的收入差不多就只能 cover 基礎建設,人事費用就還得從各種 funding 支付;現在應該是能夠額外 cover 一些些人事的部分?

Between Kagi and Orion, we are currently generating around $26,500 USD in monthly recurring revenue, which incidentally about exactly covers our current API and infrastructure costs.

二戰時德國坦克製造速度的估算問題

看到「The German Tank Problem」這篇在講二戰很有名的統計應用。這個主題在中文的維基百科寫得還蠻完整的,讀起來應該會更快一些:「德國坦克問題」:

在統計學理論的估計中,用不放回抽樣來估計離散型均勻分布最大值問題中著名的德國坦克問題(英語:German tank problem),它因在第二次世界大戰中用於估計德國坦克數量而得名。

如同上面所說的,這個方法是因為估算的準確度極高而知名:

對坦克車輪的分析產生了對使用中的車輪模具數量的估計。在與英國車輪製造商討論過後,他們估計了這麼多的模具可以生產多少車輪,進而是每個月可生產的坦克數量。對兩輛坦克(每輛32個車輪,總計64個車輪)車輪的分析的結果是1944年2月的生產數量估計在270左右,大大超出此前預期。

德國戰後公布的記錄顯示,1944年2月一個月的生產量是276輛。統計方法結果的精確度是常規情報收集方法所遠遠不能達到的,而「德國坦克問題」這個詞也成為了這種統計分析問題的標誌。

而且之後被拿來推敲經典的 Commodore 64 的數量也還蠻準的:

該公式在非軍事中也有使用,如估計Commodore 64計算機的總數,其結果(1.25億)與官方數字相當匹配。

對每個月一次的「Ask HN: Who is Hiring?」分析

timqian/hacker-job-trends 這個用 Node.js 開發的專案是針對 Hacker News 上的「Ask HN: Who is Hiring?」分析 (每個月一篇,拿來提供各家人馬留 comment 徵才的),把關鍵字丟進程式,程式就會分析每個月的出現數量,在 terminal 上產生趨勢圖表。而且支援加法或是減法計算,可以用在去掉重複的字 (像是 javajavascript)。

遠端工作的量慢慢增加:

而區塊練的量也在增加:

裝起來後看 php 的量好慘啊 XDDD

即將出版的 Xdebug 2.6 能觀察 PHP 的 GC 情況了

在「» Feature: Garbage Collection Statistics」這邊看到 Xdebug 2.6 將能夠收集 PHP 的 GC (garbage collection) 行為了:

Xdebug's built-in garbage collection statistics profiler allows you to find out when the PHP internal garbage collector triggers, how many variables it was able to clean up, how long it took, and how how much memory was actually freed.

這樣 profiling 看的東西就更準確了...

對於按讚數排名的方法

前幾天看到一篇 2009 年的老文章,在討論使用者透過「喜歡」以及「不喜歡」投票後,要怎麼排名的方法:「How Not To Sort By Average Rating」。

基本的概念是當使用者投票數愈多時就會愈準確,透過統計方法可以算一個信賴區間,再用區間的下限來排... 但沒想到公式「看起來」這麼複雜 XDDD

Score = Lower bound of Wilson score confidence interval for a Bernoulli parameter

但實際的運算其實沒那麼複雜,像是 Ruby 的程式碼可以看出大多都是系統內的運算就可以算出來。其中的 z 在大多數的情況下是常數。

require 'statistics2'

def ci_lower_bound(pos, n, confidence)
    if n == 0
        return 0
    end
    z = Statistics2.pnormaldist(1-(1-confidence)/2)
    phat = 1.0*pos/n
    (phat + z*z/(2*n) - z * Math.sqrt((phat*(1-phat)+z*z/(4*n))/n))/(1+z*z/n)
end

The z-score in this function never changes, so if you don't have a statistics package handy or if performance is an issue you can always hard-code a value here for z. (Use 1.96 for a confidence level of 0.95.)

作者後來在 2012 年與 2016 年也分別給了 SQL 以及 Excel 的範例程式碼出來,裡面 hard-code 了 95% 信賴區間的部份:

SELECT widget_id, ((positive + 1.9208) / (positive + negative) - 
                   1.96 * SQRT((positive * negative) / (positive + negative) + 0.9604) / 
                          (positive + negative)) / (1 + 3.8416 / (positive + negative)) 
       AS ci_lower_bound FROM widgets WHERE positive + negative > 0 
       ORDER BY ci_lower_bound DESC;
=IFERROR((([@[Up Votes]] + 1.9208) / ([@[Up Votes]] + [@[Down Votes]]) - 1.96 * 
    SQRT(([@[Up Votes]] *  [@[Down Votes]]) / ([@[Up Votes]] +  [@[Down Votes]]) + 0.9604) / 
    ([@[Up Votes]] +  [@[Down Votes]])) / (1 + 3.8416 / ([@[Up Votes]] +  [@[Down Votes]])),0)

而更多的說明在維基百科的「Binomial proportion confidence interval」可以翻到,裡面也有其他的方法可以用。

StackOverflow 成長數字 (Google Analytics) 與某些分析數據的比較...

Joel Spolsky 大概不太滿意這些詐騙集團 XD

他在「Stack Exchange Traffic Still Growing」這篇裡面直接拿最正確的 source 產生出來的 Google Analytics 數據 (畢竟是自己掛到自己站上的),讓人知道 StackOverflow 還在成長...

然後直接婊 Compete 給的數據:(這張圖原始檔名叫做 compete-is-rubbish.png)