Note di Matteo

Nuovo mini progetto work in progress:

Un sito ben fatto, Logging Sucks, per spiegare due concetti di logging nelle applicazioni:

• Structured logging, cioè spezzare il messaggio testuale nelle sue componenti in modo che siano filtrabili (ogni log line è un oggetto JSON, in pratica).
• Wide events, cioè avere una singola log line per ciascun evento nel senso più ampio possibile. Ad esempio una richiesta HTTP produce un log che contiene tutte le info di contesto su ciò che è successo durante l'elaborazione, al posto di avere le informazioni sparse tra più righe di log.

Molto d'accordo sul primo (anche se preferisco una forma ibrida con messaggio formattato + variabili scorporate), meno sul secondo. Righe di log separate con un id di correlazione lo troverei più comodo (a meno di logging su scale enormi che finora non mi sono capitate).

Postmortem di Railway, la creazione di un indice PostgreSQL ha tirato giù tutto:

A routine change to this Postgres database introduced a new column with an index to a table containing approximately 1 billion records. This table is critical in our backend API’s infrastructure, used by nearly all API operations.

The index creation did not use Postgres’ CONCURRENTLY option, causing an exclusive lock on the entire table. During the lock period, all queries against the database were queued behind the index operation. [...] Manual intervention attempts to terminate the index creation failed.

Le misure:

We’re going to introduce several changes to prevent errors of this class from happening again:

• In CI, we will enforce CONCURRENTLY usage for all index creation operations, blocking non-compliant pull requests before merge.
• PgBouncer connection pool limits will be adjusted to prevent overwhelming the underlying Postgres instance's capacity.
• Database user connection limits will be configured to guarantee administrative access during incidents, ensuring maintenance operations remain possible under all conditions.

Oui oui baguette 😂

How we deploy the largest GitLab instance 12 times daily. La strategia di deployment di GitLab, interessante per la scala, per la progressività con canary e la strategia di migrazione del db.

Ottimizzazioni di un'altra era nell'app Facebook:

In 2012 we took this wild ride at mobile infra at Facebook when trying to reduce the several-seconds long load time for “Newsfeed”. A few people worked on different approaches. Something we quickly realized was that setting up a connection with TCP and TLS was incredibly slow on mobile networks at the time. The fix was to have just one, keep it alive and multiplex. Shaved a whole second off. But it was still slow. Several people were convince that us sending JSON was the problem, so two different teams started to work on compact binary encoding. After a lot of experimentation what actually worked out best was to send JSON with ordered fields and a compile-time generated parser. Turns out both our iOS and Android app would do something silly like: 1) read all JSON data from server into a buffer, 2) decode that buffer with a generic JSON decoder into lists & dicts, 3) traverse those structures and build the final struct/class tree. Oh and another neat thing we eventually did—when the network connection needed to be setup—was to send an optimistic UDP packet to the server saying “get started fetching data for the following query”; once the real connection was established, TLS handshake completed and user session authenticated, the response was already ready to be sent back.

Browser Score permette di verificare se il proprio browser supporta determinate feature di CSS.

When you create a pull request in GitHub, click on the Files changed tab, and scroll through the diff. Anywhere you’ve done something new that’s not already explained by in-code comments, add a comment in the GUI about what you did and why.

• Often, it’s stuff that’s not important enough for in-code commentary, but is useful for the reviewer to know.
• Sometimes, it’s stuff that should actually be documented in the code, and this is a good time to go back and add it.
• Every now and then, you’ll notice a bug in your own code because you’re reading it with fresh eyes, in a different format than your text editor.

It’s a simple behavior change that adds maybe 5 or 10 minutes to the time it takes to setup a PR, but it’s saved me so many headaches, and makes life for whoever reviews your PR a lot easier, too!

(Chris Ferdinandi)

TIL con un file .git-blame-ignore-revs si possono ignorare determinati commit dall'output "blame" su GitHub (o con git blame --ignore-revs-file .git-blame-ignore-revs), utile quando si fanno refactoring o si modifica la formattazione ma non la funzionalità.

(fonte, esempio)

Performance Improvements in .NET 10: notevolissimi miglioramenti di prestazioni (CPU e memoria) in .NET 10, anche con ottimizzazioni delle espressioni regolari compilate.

Google sta riscrivendo pezzi di Android che prima erano in C++ in Rust, con notevoli risultati dal punto di vista della sicurezza:

With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).

Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.

Nei Dev Tools di Chrome sarà possibile applicare il throttling solo a una richiesta specifica, utile!

oklch.fyi. Ottima spiegazione dello spazio colore OKLCH in ascesa nello sviluppo web ultimamente.

Interessante 0github.com:

To try it, replace github.com with 0github.com in any GitHub pull request url. Under the hood, we clone the repo into a VM, spin up gpt-5-codex for every diff, and ask it to output a JSON data structure that we parse into a colored heatmap.

TIL le build del toolchain Go sono riproducibili al byte:

They made it so every version of Go starting with 1.21 could be easily reproduced from its source code. Every time you compile a Go toolchain, it produces the exact same Zip archive, byte-for-byte, regardless of the current time, your operating system, your architecture, or other aspects of your environment (such as the directory from which you run the build).

At Netflix, we’d often find that backend services had slow memory leaks, which took a long time to discover and fix because instances rarely lived longer than 48 hours, due to autoscaling policies. If we had chosen to focus on memory leaks instead of autoscaling, Netflix would have been unable to scale to meet demand, and would’ve been a much smaller business.

Matthew Hawthorne, ex ingegnere Netflix.

GitHub ha un nuovo capo prodotto, Jared Palmer, ex Vercel, e dice che GitHub implementerà le stacked PR/stacked diff (stile Graphite.dev):

RE: Stacked Diffs on @GitHub

After discussion w @ttaylorr_b, we can implement stacked PRs/PR groups already (in fact we kind of do with Copilot) but restacking (automatically fanning out changes from the bottom of the the stack upwards) would be wildly inefficient. To do it right, we need to migrate @GitHub to use git reftables instead of packed-refs so that multi-ref updates / restacking will be O(n) instead of ngmi.

This will take some time but has been greenlit.

Molto interessante!

How to win at CORS. Una buona risorsa completa per capire CORS (Cross-Origin Request Sharing).

How TimescaleDB helped us scale analytics and reporting. Recente articolo molto interessante di Cloudflare su TimescaleDB, estensione PostgreSQL e alternativa molto più semplice a ClickHouse per gestire dati di analytics, quando PostgreSQL semplice non ci sta più dietro.

GitHub Pages, our static site hosting service, has always had a very simple architecture. From launch up until around the beginning of 2015, the entire service ran on a single pair of machines (in active/standby configuration) with all user data stored across 8 DRBD backed partitions. Every 30 minutes, a cron job would run generating an nginx map file mapping hostnames to on-disk paths.

There were a few problems with this approach: new Pages sites did not appear until the map was regenerated (potentially up to a 30-minute wait!); cold nginx restarts would take a long time while nginx loaded the map off disk; and our storage capacity was limited by the number of SSDs we could fit in a single machine.

Despite these problems, this simple architecture worked remarkably well for us — even as Pages grew to serve thousands of requests per second to over half a million sites.

Hailey Somerville sul blog GitHub.