GOV.UK 拔掉網頁上的 jQuery

英國政府的網站拔掉 jQuery 了:「GOV.UK drops jQuery from their front end.」,Hacker News 上的討論也可以看一下:「Gov.uk drops jQuery from their front end (web.dev)」。

當年會選擇用 jQuery 大概有幾個原因,第一個是當年 (很舊的 browser 版本) 對 DOM 的操作非常的混亂,像是:

而 jQuery 在那個年代就已經把這堆 DOM operation 都窮舉支援了 (可以直接看「Category: DOM Insertion, Around」、「Category: DOM Insertion, Inside」、「Category: DOM Insertion, Outside」這三個大分類),可以注意 jQuery 1.0 就已經把基本界面都弄出來了,而 jQuery 1.0 是 2006 年八月出的,另外 IE7 是在 2006 年十月出,也就是說在 IE6 的年代就提供一整套完整的方案。

另外 jQuery 幫忙處理了早期 IE 與 W3C 標準的不一致行為,像是經典的 attachEvent (出自 DOM events):

Microsoft Internet Explorer prior to version 8 does not follow the W3C model, as its own model was created prior to the ratification of the W3C standard. Internet Explorer 9 follows DOM level 3 events, and Internet Explorer 11 deletes its support for Microsoft-specific model.

就功能面上來說,jQuery 提供的 Sizzle engine 也提供了 CSS selector 的能力,這在早期還沒有 querySelectorAll() (IE9+) 的時候方便不少,而且就算有了 querySelectorAll(),Sizzle 支援的 CSS selector 更完整。

上面提到的解決 browser 早期的各種亂象,jQuery 其實也帶入了不少好用的 pattern,其中一個是 fluent interface 讓人寫起來很舒服:(這個範例只是要介紹 fluent interface,不要管實際上在亂搞什麼 XD)

$('#foo').html('<p>bar</p>').css('width: 100px;');

另外就是不需要對 null object 做太多處理:

$('#foo').css('width: 100px;');

與這樣比較:

let elem = document.querySelector('#foo');
if (elem) {
    // ...
}

不過在這些年,負面的部份已經大幅改善了,所以也陸陸續續可以看到很多人在討論要怎麼拔掉 jQuery。而這次英國的 GOV.UK 拔掉 jQuery 有看到一些效果:

  • Less front end processing time overall.
  • 11% less blocking time at the 75th percentile.
  • 10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

但說實話,~10% 左右的 performance 改變比預期中少很多耶?可以看出來 John Resig 當年在上面為了效能花了多少功夫...

這次的結果反倒是讓我在思考,如果可以用 jQuery 降低開發的瓶頸,我還蠻偏好就拿 jQuery 進來用...

在 .gitignore 裡面忽略掉 .gitignore...

Hacker News 上看到「Git ignores .gitignore with .gitignore in .gitignore」這個搞事的功能,可以在 .gitignore 內把 .gitignore 忽略掉 XDDD

這真虧作者想的到這樣的玩法 XDDD

在 Hacker News 上也有看到一些有趣的東西,像是 globally ignore list 之類的:「Git ignores .gitignore with .gitignore in .gitignore (rubenerd.com)」。

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap:

就算是使用 EBSgp2 或是 gp3,甚至是其他 VPS,我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB,無論記憶體有多大),這算是我自己的 best practice 了,這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心,需要去改設定...

NVIDIA 開源 Linux GPU Kernel Driver

NVIDIA 宣佈開源 Linux 下的 GPU Kernel Driver:「NVIDIA Releases Open-Source GPU Kernel Modules」。

從一些描述上可以看出來,應該是因為 Datacenter 端的動力推動的,所以這次 open source 的版本中,對 Datacenter GPU 的支援是 production level,但對 GeForce GPU 與 Workstation GPU 的支援直接掛 alpha level:

Which GPUs are supported by Open GPU Kernel Modules?

Open kernel modules support all Ampere and Turing GPUs. Datacenter GPUs are supported for production, and support for GeForce and Workstation GPUs is alpha quality. Please refer to the Datacenter, NVIDIA RTX, and GeForce product tables for more details (Turing and above have compute capability of 7.5 or greater).

然後 user-mode driver 還是 closed source:

Will the source for user-mode drivers such as CUDA be published?

These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit.

nouveau 來說,是可以從 open source driver 裡面挖一些東西出來用,不過能挖到跟 proprietary 同樣效能水準嗎?

Cloudflare 的 D1 (SQLite as a service)

Hacker News Daily 上看到 Cloudflare 推出了新產品 D1:「Announcing D1: our first SQL database」,在 Hacker News 上對應的討論在「D1: Our SQL database (cloudflare.com)」這邊可以看到。

就如同 Hacker News 上的討論提到的,這篇文章不像一般的 Cloudflare 文章會帶有很多技術上的說明 (尤其是在描述技術產品),這篇算是非常的行銷導向的文章,目前大家只能靠「猜」的去理解:

For a Cloudflare article, this one is surprisingly light on technical details. And for the product where it most matters.

翻了一下這兩個屬名的作者,Rita Kozlov 是 Director of Product at Cloudflare,而 Glen Maddern 是 Systems Engineer at Cloudflare。

目前知道的是,D1 是架構在 SQLite 上面:

D1 is built on SQLite.

然後從範例的程式碼內可以看到,在 JavaScript 裡面的用法是透過 await env.DB.get() 操作:

export default {
  async fetch(request, env, ctx) {
    const { pathname } = new URL(request.url)
    if (pathname === '/num-products') {
      const { result } = await env.DB.get(`SELECT count(*) AS num_products FROM Product;`)
      return new Response(`There are ${result.num_products} products in the D1 database!`)
    }
  }
}

然後從 screenshot 上沒有看到 region,但是 class 那邊出現了一個 tokyo3 不知道是什麼東西:

目前看到的就這些,沒提到 replication 機制 (這其實還蠻重要的,某些資料是有法規限制的),另外開發者會很在意的 performance 或是 latency 也沒提到 (所以可以預期應該不會太好?)。

另外在 RDBMS 內很重要的 ACID 特性與分散式系統中 CAP theorem 的性質也都沒有分析。

可以先放著看看就好...

關於阻擋 cookie consent window (會問你同意 cookie 的視窗)

看到「It’s time we fix the unethical design of cookie consent windows」這篇,我這邊不是要討論那堆 dark pattern 以及對應的法律問題 (像是先前提到的「Google 在歐盟的服務將提供 Reject All Cookies 的按鈕」),而是想要提一下有對應的 filter rule 專門在擋這類東西的。

uBlock Origin 內的列表有個「Annoyances」的清單可以選:

主要就 AdGuard AnnoyancesFanboy’s Annoyance 以及 uBlock filters – Annoyances 這三個,這樣會讓你在使用網路順不少...

Tor 0.4.7.7 支援 congestion control

Tor 首度在協定內支援了 congestion control:「Congestion Control Arrives in Tor 0.4.7-stable!」。

這個新功能會帶來效能的提昇:

Tor has released 0.4.7.7, the first stable Tor release with support for congestion control. Congestion control will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays. It will result in significant performance improvements in Tor, as well as increased utilization of our network capacity.

之所以沒有辦法直接利用 packet loss 的方式讓 TCP network stack 直接判斷 congestion control,是因為這樣會產生 side channel:

Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.

所以 Tor 得自己實做 congestion control 演算法,選擇的演算法是結合了 Vegas 的 Tor-Vegas,可以看到在實驗中,德國與香港的 exit node 效率大幅提昇:

另外也因為 0.4.7.7 也出來一個禮拜了,也可以看到 Advertised Bandwidth (算是 Tor network 觀察到的 bandwidth) 開始成長:

另外一個重要的點是 UDP 的支援計畫,看起來在這次改善後也比較有可行性了:

The astute reader will note that we rejected datagram transports. However, this does not mean that Tor will never carry UDP traffic. On the contrary, congestion control deployment means that queue delay and latency will be much more stable and predictable. This will enable us to carry UDP without packet drops in the network, and only drop UDP at the edges, when the congestion window becomes full. We are hopeful that this new behavior will match what existing UDP protocols expect, allowing their use over Tor.

Amazon RDS for PostgreSQL 可以掛 155 台 Read Replica

看到 AWS 推出的新「功能」,可以讓 Amazon RDS for PostgreSQL 的 read replica 掛到 155 台:「Amazon RDS for PostgreSQL supports cascaded read replicas for up to 30X more read capacity」。

作法是透過三層架構,每台機器可以堆五台 replica:

Amazon Relational Database Service (Amazon RDS) for PostgreSQL announces support for PostgreSQL 14 with three levels of cascaded read replicas, 5 replicas per instance, supporting a maximum of up to 155 read replicas per source instance.

需要 PostgreSQL 14.1 或是之後的版本:

Starting with Amazon RDS for PostgreSQL 14.1 and higher, read intensive workloads such as data analytics can now benefit from up to 155 cascaded read replicas that offer up to 30 times higher read capacity versus previous versions of PostgreSQL, thereby reducing the load on source instance.

我記得 Amazon RDS for PostgreSQL 的 replica 是 EBS block-level replication,這種搞法還蠻有趣的 XDDD

在 PostgreSQL 上直接掛 ML extension

Hacker News 首頁上看到「Show HN: PostgresML, now with analytics and project management (postgresml.org)」這個專案,可以在 PostgreSQL 上面直接掛 extension 跑 ML algorithm:「PostgresML - an end-to-end machine learning solution」,從 GitHub 上可以看到大多數是 Python 的程式碼。

從 GitHub 頁面上面可以看到這個專案還在比較早期的階段:

This project is currently a proof of concept. Some important features, which we are currently thinking about or working on, are listed below.

如果是目前要用的話,主要是方便看一些東西吧?可以想到的是掛個 replication 出來跑一些 query,這樣不會影響到 production database 的效能,應該還行...

另外看了一下支援的演算法,主要是以經典的 ML 演算法為主,而且就是套用 Python 上面的套件:XGBoostscikit-learn

這些演算法算是很好用了,而且掛到 PostgreSQL 裡面會讓使用上方便很多 (少了倒資料的動作,不過就得小心處理 dirty data 了),然後專案也附上一個 UI 界面可以看一些資料,不過我猜還是用其他生 visualization 的工具會比較豐富一點:

另外一個想法是拿來學習還不錯?老師在上課的時候拿來示範一些演算法,就不用自己再刻很多程式碼...

畫 Python 下記憶體使用情況的 Flamegraph:Memray

前幾天的 Hacker News Daily 上看到的東西,是由 Bloomberg 開發出來的工具 Memray,這個工具是一個 Python 套件:

Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself.

套件有多種輸出,其中一種是可以產生出記憶體使用情況的 flamegraph,轉成圖檔後像是這樣:

官方支援 Python 3.7+:

Memray requires Python 3.7+ and can be easily installed using most common Python packaging tools.

用法看起來也很簡單,之後如果有需要看 memory footprint 的情況好像可以拿來用看看...