為線上環境而最佳化的 Ruby:Fullstaq Ruby

最近看到的「Fullstaq Ruby」,專為線上環境最佳化的 Ruby

Fullstaq Ruby is an MRI-based Ruby distribution that's optimized for server production use cases.

目前主要是使用 jemalloc (超萬用) 以及 malloc_trim patch:

It is compiled with the Jemalloc and malloc_trim patches, allowing lower memory usage and higher performance.

其中看了一下 malloc_trim patch 的介紹還蠻有趣的:「What causes Ruby memory bloat?」,這篇主要是在討論記憶體用量的問題,以及目前常見的 workaround。

這個 patch 是針對 Ruby 在 full mark GC 的情境後,增加呼叫 malloc_trim(0); 以釋放記憶體,作者發現這樣可以省下了大量的記憶體空間:

然後作者預期效能應該會有影響 (畢竟多做了一些事情),所以找了有在做 Rails benchmark 的人幫忙測試,結果發現反而變快了:

這樣看起來有可能官方會考慮把這個 patch 直接包進去?不過這看起來是在使用 jemalloc 的前提下?不知道如果使用標準的 glibc 會怎麼樣...

Amazon 需要對賣出去的產品造成的傷害負責

前幾天還蠻引人注目的案件,Amazon 被判決要對平台商家透過 Amazon 平台賣出去的產品負責:「Federal appeals court says Amazon is liable for third-party sellers' products」。

這個案例裡面是消費者透過 Amazon 的平台,向上架的商家購買 hoverboard (懸浮滑板?),結果把消費者家給搞爆了:

Last year, a judge in Tennessee ruled the company was not liable for damages caused by a defective hoverboard that exploded, burning down a family's house.

目前最新的判決中指出,Amazon 在合約裡面簽訂消費者必須透過 Amazon 的平台跟賣家溝通,使得賣家與消費者之間沒有直接的管道可以處理爭議,所以 Amazon 不能免責:

"Amazon fails to account for the fact that under the Agreement, third-party vendors can communicate with the customers only through Amazon," the ruling states. "This enables third-party vendors to conceal themselves from the customer, leaving customers injured by defective products with no direct recourse to the third-party vendor."

這個判決看起來會影響蠻大的,因為這些條款就是希望維持平台業者可以從中獲利,現在反過來殺傷自身... 看起來上訴是跑不掉的?等幾個月後再回來看...

GitLab 12.1 之後放棄支援 MySQL

GitLab 打算在 12.1 之後放掉 MySQL 的支援:「Why we're ending support for MySQL in 12.1」。

GitLab 在說明裡給了不少原因,但看了看以後還是覺得 GitLab 每次在做技術決策時給出來的理由都很... 有趣?XD

每次看這三家提供的技術工具或是技術決策都很有趣... (另外兩家是 UberYahoo!)

移除 Blog 上的 Google Analytics,改用 Matomo

跑了快一個月了,大概整理一下...

一直都有在規劃降低對 Google 服務的依賴性,最主要的是使用 DuckDuckGo 替代 Google Search (但搜尋的品質還是差一截,所以寫了一些工具幫助我在不滿意的時候可以快速切到 Google 搜尋:「在 DuckDuckGo 搜尋頁快速切換到 Google 的套件」)。

而最近在研究的另外一個服務是 Google Analytics,我只用很基本的功能 (像是熱門文章,作業系統與瀏覽器的比率這些很基本的資料),不需要對於觀看客群有了解 (這個需要像 Google Analytics 跨站蒐集資料),所以替代方案應該不難找...

憑著印象與一些關鍵字,找到了 Matomo,這是一套 open source 的 web analytics 服務,以前叫做 Piwik (參考「Piwik is now Matomo - Announcement」),整個系統用 PHP + MySQL 就可以打發 (反正量不大的東西不需要拿什麼神兵利器出來,MySQL 硬塞硬算就可以了),接著把本來 Google Analytics 的 js 換掉就行了...

跑了快一個月後感覺還 ok,基本的資訊都有...

補上 WordPress 編輯器的 accesskey

WordPress 編輯文章時我還是習慣用傳統編輯界面自己修改主要的 html tag,像是這樣:

上面那些按鈕在很久以前的版本透過 accesskey 用鍵盤快速輸入各種連結與效果,但後來就被拿掉了... 不過可以在「Adding WordPress Custom QuickTags」這邊看到一些文章有提到過。

研究了一下 WordPress 的 minimal plugin 有哪些東西,看起來也不難寫,就花了些時間用 js 操作,這樣編輯起來方便多了... 程式包起來放到 gslin/wp-editor-accesskey 上,有需要的也可以拿去用,不過我猜現在還這樣寫文章的人不多了...

把 HTML 資料都塞到 URL 裡的服務

如標題說的,專案叫做「URL Pages」,是一個把 HTML 的原始碼都放到 url string 裡的服務。服務本身可以在 http://jstrieb.github.io/urlpages 這邊使用。

現在網路上有很多地方可以塞 demo page (像是 GitHub 自己提供的 GitHub Pages),這個方式需要依賴 JavaScript 提供各種轉換機制,應該會有不少 side-effect bug,看起來會有不少技術瓶頸,就當作是個實驗性質的專案來看,真的需要放 demo page 的還是可以隨便找空間放比較簡單,像是前面提到的 GitHub Pages 其實可以直接在 GitHub 的網頁上操作...

JavaScript 的 sort 變成 stable

看到「Stable Array.prototype.sort」這篇在講 JavaScript 規格書裡的 sort...

本來 JavaScript 的規格書裡,各種 sort 都沒有保證 stable,而在「[Normative] Make Array.prototype.sort stable #1340」與「[Normative] Make %TypedArray%.prototype.sort stable #1433」這兩個地方則有了變化,提案在規格裡加入 stable 的要求,可以減少開發者因為不知道 unstable 而造成的問題...

Firefox 則是很久前就決定使用 Merge sort 了 (看了一下,當時還在從 Firebird 轉換名稱到 Firefox 的時期):「Array.sort isn't a stable sort (switch to MergeSort)」。

另外這篇也剛好提到了 V8 使用 Timsort 當作 stable sorting algorithm,之前就有看到但發現沒在 blog 上提過...

Timsort 是 1993 年發明出來的演算法,與 Merge sort 的情況類似,除了 stable 外,還可以保證最差的情境下的時間複雜度是 O(n*log(n))

Timsort is a hybrid stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data.

這個演算法的重點是善用已經排好的子序列,藉此降低記憶體操作次數而提昇效能,符合真實環境裡常見到的資料:

The algorithm finds subsequences of the data that are already ordered, and uses that knowledge to sort the remainder more efficiently.

除了 V8 採用這個演算法以外,其他常見的包括了 PythonAndroid 上的 Java SE:

Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7, on the Android platform, in GNU Octave, and Google Chrome.

robots.txt 的標準化

雖然聽起來有點詭異,但 robots.txt 的確一直都只是業界慣用標準,而非正式標準,所以各家搜尋引擎加加減減都有一些自己的參數。

在經過這麼久以後,Google 決定推動 robots.txt 的標準化:「Formalizing the Robots Exclusion Protocol Specification」,同時 Google 也放出了他們解讀 robots.txt 的 parser:「Google's robots.txt Parser is Now Open Source」,在 GitHubgoogle/robotstxt 這邊可以取得。

目前的 draft 是 00 版,可以在 draft-rep-wg-topic-00 這邊看到,不知道其他搜尋引擎會給什麼樣的回饋...

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

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

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

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

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

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

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

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