Raspberry Pi 上面直接對 Framebuffer 與觸控介面操作

清 tab,看到這個 2019 年的文章:「Writing GUI applications on the Raspberry Pi without a desktop environment (2019) (avikdas.com)」,原文在 Raspberry Pi 上面希望操作觸控螢幕,但不想要把整包 X.Org 都裝起來,所以直接操作了 Framebuffer,並且自己處理了觸控介面的事件:「Writing GUI applications on the Raspberry Pi without a desktop environment」。

這看起來是作者的成品:

當年作者用 Raylib 實作,不過 2024 年的 Hacker News 倒是提到了不少 library 可以用,之後如果有遇到需求可以當作切入點去研究...

在 PostgreSQL 裡,當 UUID 當作 Primary Key 時要怎麼處理

繼續清 tab,在「PostgreSQL and UUID as Primary Key (maciejwalkowiak.com)」這邊看到的,原文是討論 PostgreSQL 要怎麼處理 PK 是 UUID 的情況:「PostgreSQL and UUID as primary key」。

文章開頭作者就說了,這篇不是要戰 PK 要不要用 UUID,而是已經決定要用了 (i.e. 通常不是你決定的),在接手以後要怎麼用比較好:

Considering the size of UUID it is questionable if it is a right choice, but often it is not up to us to decide.

This article does not focus on "if UUID is the right format for a key", but how to use UUID as a primary key with PostgreSQL efficiently.

首先是 PostgreSQL 從 8.3 版 (2008 年) 就支援 UUID 的資料型態了,這點從 release note 可以看到:「PostgreSQL 8.3.0」,所以要當 PK 的話沒什麼道理不考慮他。

UUID 的空間上就是 128-bit data (16 bytes),相比於 TEXT 會省蠻多的,尤其 PK 常常會被其他表格 reference 到 (像是 foreign key) 會在其他表格也省下來:

Table that uses text is 54% larger and the index size 85% larger.

第二點則是考慮到 UUID 本身的特性,以前的 UUID 因為是亂數生成的 (通常會用 UUIDv4),對寫入 B-tree 類的資料結構不是很有效率,改用 UUIDv7 (差不多是這兩年陸陸續續發展出來的規格) 會得益於與 timestamp 有關,對 B-tree 寫入的效率會好很多:

Random UUIDs are not a good fit for a B-tree indexes - and B-tree index is the only available index type for a primary key.

B-tree indexes work the best with ordered values - like auto-incremented or time sorted columns.

UUID - even though always looks similar - comes in multiple variants. Java's UUID.randomUUID() - returns UUID v4 - which is a pseudo-random value. For us the more interesting one is UUID v7 - which produces time-sorted values. It means that each time new UUID v7 is generated, a greater value it has. And that makes it a good fit for B-Tree index.

作者的測試可以看到寫入速度與 UUIDv4 相比比快不少:

BUT we can clearly see, that inserting UUID v7 is ~2x faster and inserting regular UUID v4.

總結來說,當 PK 已經決定是 UUID 後,主要就是這兩個重點可以注意的,當然 Hacker News 上更熱鬧的是兩派人馬在吵要用 integer 類的 SERIAL/BIGSERIAL 還是用 UUID,那又是另外一個話題了...

如果早個二十年前對 memory size 斤斤計較的情況下,答案鐵定是 integer 類的,但年代不同了...?

lite-youtube-embed

繼續清 tab,在「YouTube embeds are heavy and it’s fixable (frontendmasters.com)」這邊看到的是提出改善 YouTube 的外嵌功能 (embed),因為 loading 太肥了。原文在「YouTube Embeds are Bananas Heavy and it’s Fixable」,裡面提到一個只有 YouTube 的 embed (iframe) 頁面就抓了 1.3MB 的資料:

On a page with literally nothing at all on it other than a YouTube Embed, we’re looking at:

32 requests
1.3 MB of data transfer
2.76s to load the page on my current WiFi connection

而「One YouTube Embed weighs almost 1.2 MB」這邊更提到了這邊的 resource 會線性疊加不會共用的:

The weight also grows linearly with every embed—resources are not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB (you get the idea).

測了一下 https://home.gslin.org/tmp/ytembed.html 這個,是 1.2MB transferred:

如果放兩個一樣的影片,也就是 https://home.gslin.org/tmp/ytembed2.html 的話,變成 2.4MB transferred:

所以不共用的部分的確超大,懷疑 iframe 之間不共用資源是不是跟 cache partition 的實作有關:「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」。

Anyway,所以作者提案用 lite-youtube-embed 這個套件改善:

Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster.

不過這種事情你想得到,Google 也一定想得到,全篇只講 lite-youtube-embed 的好處一定哪邊有問題。

所以翻一下 Hacker News 上,在 id=40897582 這邊就有人提到缺點了,很明顯 lite-youtube-embed 的載入速度比較慢:

The author says they don't believe that a lighter version has been shown to reduce engagement.

I, on the other hand, fully believe that.

The recommended lite-youtube-embed project page has a demo of both lite and regular players [0], and the lite version takes noticeably longer to start playing the video.

Every additional millisecond of load time will reduce engagement, and here the difference is more on the order of hundreds of milliseconds or more.

[0] https://paulirish.github.io/lite-youtube-embed/

yeah,這樣就合理了。

即使 embed 吃超多資源,但因為 YouTube 是影音網站,主要的流量還是影音的部分,利用這個方法增加載入速度,在成本結構上面可以接受,而且還可以拿到更多瀏覽資料?

但對於網站端以及使用者端就不是什麼愉快的事情,所以網站端要不要用這個套件就是看各自的取捨了。

C++ 實作高頻交易程式的技巧

看到「C++ patterns for low-latency applications including high-frequency trading (arxiv.org)」這篇,原文是 2023 年九月上傳到 arXiv 的 paper:「C++ Design Patterns for Low-latency Applications Including High-frequency Trading」。

有點 LLM 的文字感,在 Hacker News 上有人有提到這點,另外有一些圖表的錯誤,像是這兩份資料可以發現對不上,label 有標錯:

主要還是看列出的方法在自家專案上嘗試,不能直接把他們的數據拿來參考,在自家專案還是得在自家專案上面 benchmark 才知道有多少效益。

不過裡面提到蠻多有趣的作法,很多都是「知道」但沒有放在心上的...

Overleaf

線上 TeX 協同編輯工具 Overleaf 有印象用過幾次,不過 Hacker News 上看到 AGPLv3 版的專案才發現他們有開源:「Overleaf: An open-source online real-time collaborative LaTeX editor (github.com/overleaf)」,對應的 GitHub 專案在 overleaf/overleaf 這邊。

掃了一下 Hacker News 上的討論,大家都是提到在學校時協同修改論文的情況還蠻好用的,尤其是數學公式... 但也反應了出社會後 Google Docs 還是比較好用一點,如果只是要寫東西的話...。

另外一個會吸引的點大概就是字型排版的問題了,這也是為什麼我自己的 cv 一直都是用 TeX 寫 (然後套 Git 管理版本),輸出 PDF 後就是比較舒服。

dotenvx

清一清 tab... 兩個禮拜前還在日本時在 Hacker News 的「Show HN: From dotenv to dotenvx – better config management (dotenvx.com)」看到的東西,原文在推廣 dotenvx:「From dotenv to dotenvx: Next Generation Config Management」。

GitHub 的文件上可以看到幾個用法,一種是直接用,像是一般的 dotenv 的用法:

// index.js
require('@dotenvx/dotenvx').config()
console.log(`Hello ${process.env.HELLO}`)

另外一個是當 wrapper 用,像是這樣:

$ dotenvx run -- node index.js
Hello World # with dotenvx
> :-D

然後後者可以指定不同的 .env 多環境使用:

$ dotenvx run -f .env.production -- node index.js
[dotenvx][info] loading env (1) from .env.production
Hello production

另外還支援了 encrypt/decrypt 的能力降低 secret 的風險?不過這應該已經不是目前比較安全的方法了,這十年下來已經知道把 secret 放在環境變數裡太容易洩漏。

環境變數在呼叫外部程式時會被繼承,算是常見的 leaking 管道,另外就算不考慮外部程式,也會遇到環境變數算是一種全域變數,在寫測試時也很頭痛。

目前被提出來比較好的方法是把 secret 都放到 vault service 裡面,由 vault service 給一把讀取用的 API key,放進 dotenv 或是其他地方 (被稱為 secret zero)。

這樣這把 API key 去 vault service 抓取真正的 secret 放到程式內的物件取用 (像是資料庫的帳號密碼),而不是環境變數。

這樣做的 threat model 在 Hacker News 上有對應的討論,另外 AWS 的服務其實也做了類似的事情:「Amazon EC2 的 IMDSv2 計畫」。

所以 dotenvx 大概就看看,有個印象就好?

直接在 library 層將 MongoDB 用法轉換成 PostgreSQL 底層的 Pongo

看到這個「Mongo but on Postgres and with strong consistency benefits (github.com/event-driven-io)」算是另外一種用 PostgreSQL 取代 MongoDB 的嘗試,先前其他的方案是 proxy server 的方式實作 (像是 FerretDB),也就是 TCP 裡面傳的東西還是 MongoDB protocol,然後 proxy server 會轉譯成 PostgreSQL 的 SQL 語法。

這個作法的好處是不用管既有 application 是什麼程式語言開發的,另外改動比較少 (改個連線資訊 + 然後把目前還不支援的功能改寫),但缺點是多了一組 service 要維護 (如果是 HA 的話又還要設定 failover 或是 load balancer 的機制)。

Pongo 的作法則是移到 library 這邊做掉,所以就有程式語言的限制了:這個專案是用 TypeScript 開發,所以會是 JavaScript + TypeScript 生態系的方案。

不過好處就很明顯了,少了一組 service 要維護 (如果包括 HA 機制的話可能是兩組或三組),另外因為轉譯的部分在 application 端處理,沒有了 proxy server 也等於少了一個可能的 bottleneck。

這幾天上 Hacker News 後看 commit 頗熱鬧,從 Releases 頁可以看到連續出新版本。

不過... 不考慮直接用 PostgreSQL 嗎?

Reddit 的 robots.txt 要求阻擋所有機器人

在「Reddit's Robots.txt Changed (reddit.com)」這邊看到的,可以看到現在 https://www.reddit.com/robots.txt 的內容變成 (刪掉註解的部分):

User-agent: *
Disallow: /

這個改變倒是沒預料到的... 來觀察看看 HN 上後續的討論?

使用 SQLite 實作出 API 相容 Amazon SQS 的 SmoothMQ

在「Show HN: Drop-in SQS replacement based on SQLite (github.com/poundifdef)」這邊看到的,就如同標題所提到的,是個 Amazon SQS 的相容 API 實作,專案在 GitHub 上的「SmoothMQ」這邊。

底層是 SQLite,實作語言是用 Go,然後有 web interface 可以觀察與管理。

不過 Amazon SQS 的 API 層有特別優秀嗎...?而且大多數的情況都不是直接呼叫,應該是透過 message queue sdk 處理,像是作者自己寫的 sample code 用 Celery?如果是 Celery 的話後面應該有很多 backend 可以抽換...

也許在測試的角度用的到?

Lazybird 瀏覽器計畫在 2026 夏天推出 Alpha 版

在「Welcome to Ladybird, a truly independent web browser (ladybird.org)」這邊看到的,指到官網 Ladybird 上。

最主要的資訊應該是這個日期,目前計畫是 2026 夏天在 LinuxmacOS 上推出 alpha 版:

We are targeting Summer 2026 for a first Alpha version on Linux and macOS. This will be aimed at developers and early adopters.

也就是大約再兩年,看起來得花不少時間開發... 畢竟是要完全獨立開發不使用現有瀏覽器的 code。