Note di Matteo


#dev

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.

#198 /
3 dicembre 2025
/
23:39
/ #dev#reti


Review your own git pull requests

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)

#161 /
17 novembre 2025
/
22:56
/ #dev#git

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)

#151 /
15 novembre 2025
/
16:16
/ #dev#git


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.

#147 /
14 novembre 2025
/
10:02
/ #google#android#dev



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.

#125 /
1 novembre 2025
/
13:41
/ #dev#ai

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).

#120 /
30 ottobre 2025
/
11:32
/ #dev

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.

#108 /
26 ottobre 2025
/
14:21
/ #dev

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!

#91 /
21 ottobre 2025
/
15:19
/ #dev



GitHub Pages infrastructure

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.

#83 /
18 ottobre 2025
/
13:28
/ #dev#cloud

Lavorare con Safari è una pena:

  • i cookie Secure non vanno su localhost perché Safari non supporta Secure Context come gli altri browser.
  • i sottodomini di localhost non funzionano fino a macOS 26, da cui starò alla larga per un po'.
  • nella scheda Storage -> Cookies non si vedono i cookie di terze parti o dei sottodomini??? come in tutti gli altri browser.
  • al momento non riesco a far funzionare un semplice cookie SameSite=Lax del tutto, su localhost con HTTPS. Nella risposta c'è, ma non lo salva. Con gli altri browser funziona.
  • ok, non sono l'unico. Rinuncio.
#82 /
18 ottobre 2025
/
10:08
/ #dev#security#browser

Defunte definitivamente quasi tutte le iniziative di Chrome per uccidere i cookie di terze parti (Privacy Sandbox), restano solo i cookie partizionati e poco altro:

CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements. We'll also maintain Private State Tokens and explore additional approaches to help developers reduce fraud and abuse.

After evaluating ecosystem feedback about their expected value and in light of their low levels of adoption, we've decided to retire the following Privacy Sandbox technologies: Attribution Reporting API (Chrome and Android), IP Protection, On-Device Personalization, Private Aggregation (including Shared Storage), Protected Audience (Chrome and Android), Protected App Signals, Related Website Sets (including requestStorageAccessFor and Related Website Partition), SelectURL, SDK Runtime and Topics (Chrome and Android). We will follow Chrome and Android processes for phasing out these technologies and share updates on our developer site.

#81 /
18 ottobre 2025
/
09:46
/ #dev#security#browser

TIL in PostgreSQL ALTER DEFAULT PRIVILEGES si applica solo agli oggetti creati dal ruolo che ha creato i default privileges. Di default è il ruolo attualmente connesso, ma si può specificare:

ALTER DEFAULT PRIVILEGES
FOR ROLE prod_dmarcwise
IN SCHEMA public
GRANT SELECT ON TABLES TO prod_pgdump;
#79 /
17 ottobre 2025
/
09:36
/ #dev#database

SameSite e protezione CSRF con Sec-Fetch-Site

Un po' di risorse sulle tecniche moderne per la protezione da CSRF:

#75 /
16 ottobre 2025
/
21:34
/ #dev#security#browser

TIL Argon2 per le password non è più sicuro di bcrypt come si pensa:

[...] Me (@jmgosney) and @Sc00bzT were both on the experts panel for the Password Hashing Competition, and both of us will tell you not to use Argon2 for password hashing. It is weaker than bcrypt at runtimes < 1000 ms.

Yep, we basically completely failed. We set out to identify The One True PHF and instead we selected yet another KDF. We also placed way too much emphasis on "memory hardness" when we should have been emphasizing "cache hardness."

(@TerahashCorp)

#69 /
14 ottobre 2025
/
21:07
/ #dev#security

Pagina 1 di 2 Successiva →