Note di Matteo

p99 0 ms* autocomplete for 240 million domain names. Strategia interessante per autocompletare un nome di dominio nella UI nel minor tempo possibile.

Telegram ha presentato silenziosamente Telegram Serverless, che permette di create bot senza gestire infrastruttura, con il codice eseguito su infrastruttura di Telegram. È inclusa la persistenza SQLite. L'accesso è limitato per ora.

Telegram Serverless lets you run backend code for your bot and Mini App directly on Telegram's infrastructure — no servers to provision, no containers to keep alive, no scaling to think about. You write plain JavaScript modules, deploy them with a single command, and Telegram runs them in a fast, isolated V8 sandbox that sits right next to the Bot API and a built‑in database.

Molto interessante per semplici bot.

Two database migrations and a divorce. Jack Ellis di Fathom Analytics spiega la migrazione di 65 miliardi di righe da SingleStore (database OLAP+OLTP) a ClickHouse (ClickHouse Cloud) per OLTP + MySQL/Vitess (PlanetScale) per OLAP, con un risparmio molto significativo e maggiore flessibilità.

I now periodically find myself reviewing a younger dev's code, leaving comments to teach some engineering - only to eventually realize I'm actually reading just yet another Claude's subpar output...

So who am I actually contributing my comments, suggestions, and knowledge to? Will they go back to Claude? Into the training set for the next frontier LLM? Or will at least some of it stick in the dev's mind? This is deeply demotivating, how did we end up like this...

Aleksandr Shvedov, JetBrains

Ho pubblicato un articolo su DMARCwise (Why DMARC's new "np" tag can fail with DNSSEC) che evidenzia come rilevare se un dominio esiste o meno è più complicato di quello che la RFC di DMARC suggerisce quando c'è di mezzo DNSSEC. Molti grossi provider DNS, come Cloudflare, NS1, AWS Route 53, Azure DNS, Oracle Cloud DNS e Bunny DNS, usano il metodo NSEC "black lies" o "compact denial of existence" (RFC 9824) per semplificare la generazione della risposta DNS negativa, rinunciando però così al codice di risposta NXDOMAIN, che è il metodo con cui storicamente si rilevava la mancata esistenza di un dominio.

Visto che di questi tempi serve dirlo, ho scritto l'articolo di 3.500 parole a mano impiegandoci più di 8 ore di lavoro. Ho usato Codex con GPT-5.5 per revisionare typo, sintassi, grammatica e correttezza del contenuto, applicando qualche correzione qua e là.

L'ho pubblicato ieri su Hacker News, dove di domenica è più facile ottenere attenzioni, e ora ha 50 punti e 20 commenti. Posizione massima in homepage, numero 10:

Il traffico è stato di circa 1.000 visite ma con un impatto essenzialmente irrilevante sul resto del sito (zero nuove iscrizioni):

Powering Evernote AI features with vLLM. Ludovico Papavassiliou di Bending Spoons spiega come sono state implementate alcune feature AI di Evernote (9 miliardi di note, 100 milioni di note aggiunte ogni anno), in particolare per quanto riguarda la trascrizione audio (800mila trascrizioni audio al mese più altre 200mila con riconoscimento speaker). Sono passati da WhisperX a vLLM, sull'infrastruttura interna condivisa tra i prodotti (K8s GCP), e il costo giornaliero è sceso da picchi di 1000 $ al giorno a poco più di 100 $ (solo 0,03 $ per ora di audio). Per le trascrizioni con diarization usano invece ElevenLabs scribe-v2 perché la qualità giustifica il costo.

Making Electron apps feel native on Mac. Segnalibro per una lista di trucchi per rendere un'app Electron il più vicina possibile al feeling nativo.

Stop Using Conventional Commits. Ah, finalmente ho trovato il mio club. I conventional commit sono inutili nella maggior parte dei casi.

Agentic AI is a fascinating mirror. It can code as well as the user who drives it. If that user is a junior engineer, now you have a faster junior engineer. If the user is a staff engineer, now you have a faster staff engineer.

What agentic AI doesn’t do is magically convert a junior engineer into a staff engineer, because the user driving it still needs enough experience to know what a good solution looks like.

A staff engineer in the US at a large company a The Pragmatic Engineer.

It used to be if you found a GitHub repository with a hundred commits and a good readme and automated tests and stuff, you could be pretty sure that the person writing that had put a lot of care and attention into that project.

And now I can knock out a git repository with a hundred commits and a beautiful readme and comprehensive tests of every line of code in half an hour! It looks identical to those projects that have had a great deal of care and attention. Maybe it is as good as them. I don’t know. I can’t tell from looking at it. Even for my own projects, I can’t tell.

Simon Willison in Vibe coding and agentic engineering are getting closer than I’d like.

Idempotency Is Easy Until the Second Request Is Different. Deep dive nell'implementazione di idempotency nelle API HTTP.

Leggo cose buone su RWX, nuova piattaforma di CI/CD pensata per velocizzare i processi nell'era dell'AI engineering, con parallelizzazione automatica, esecuzione delle pipeline prima del commit e altre ottimizzazioni.

Imagine if this is as good as AI gets. If this is where it stops, you'd still have models that can almost code a web browser, almost code a compiler—and can even present a pretty cool demo if allowed to take a few shortcuts. You'd still get models that can kinda-sorta simulate worlds and write kinda-sorta engaging stories. You'd still get self-driving cars that almost work, except when they don't. You get AI that can make you like 90% of a thing!

90% is a lot. Will you care about the last 10%?

I'm terrified that you won't.

I'm terrified of the good enough to ship—and I'm terrified of nobody else caring. I'm less afraid of AI agents writing apps that they will never experience than I am of the AI herders who won't care enough to actually learn what they ship. And I sure as hell am afraid of the people who will experience the slop and will be fine with it.

[...]

I'm terrified that our craft will die, and nobody will even care to mourn it.

Dima Konev, software engineer, in (AI) Slop Terrifies Me.

It feels to me that a good part of the industry is using token count numbers similarly to how the lines-of-code-produced metric was used years ago. There was a time when the number of lines written daily or monthly was an important metric in programmer productivity, until it became clear that it’s a terrible thing to focus on. A lines-of-code metric can easily be gamed by writing boilerplate or throwaway code. Also, the best developers are not necessarily those who write the most code; they’re the ones who solve hard problems for the business quickly and reliably with – or without – code!

Similarly, the number of tokens a dev generates can easily be gamed, and if this metric is measured then devs will indeed game it. But doing so generates a massive accompanying AI bill!

Gergely Orosz in The Pulse: ‘Tokenmaxxing’ as a weird new trend.

I tre tipi di software engineer secondo The Pragmatic Engineer:

• Builders: those who care about quality, good architecture, following good coding practices, and who talk about the craft of software engineering, etc.

• Shippers: those who primarily focus on outcomes for a product, features, testing, and experimenting with users. A fair number of leaders, managers, and engineers who were more hands-off with coding before AI tools are in this category, as are product engineers.

• Coasters: engineers who are not considered particularly good or great engineers, but they get the work done. They often do this without much taste or concern for quality, and seem to be mostly coasting along and doing what they’re told.

Con l'AI, queste categorie restano ma con diversi livelli di entusiasmo e pro/contro. Il resto nell'articolo.

Le cit. su questo sito hanno un nuovo stile.

Prima:

Dopo:

DNSimple spiega come gestiscono le repository GitHub con Terraform. Quando iniziano a diventare centinaia, gestirle manualmente genera inconsistenze:

• Repositories had different settings, even when they should have been identical
• Labels for issue triage varied from repository to repository, making cross-project tracking difficult
• Some repositories had issue templates, while others didn't
• Permission management was manual and error-prone
• Security features like vulnerability alerts weren't consistently enabled
• Pull request templates were copy-pasted (when they existed at all)

Dopo un tentativo con Repocop, per automatizzare il setup, hanno deciso di usare Terraform con aggiornamento delle configurazioni tramite Pull Request e Terraform Cloud.

Ho aggiunto il supporto all'autenticazione a due fattori su DMARCwise e ho fatto fatica a trovare informazioni su best practice attorno alla 2FA con OTP, per cui segno quello che ho scoperto qui.

Intanto, l'algoritmo si chiama Time-based One-Time Password (TOTP) e permette di generare un codice di N cifre ogni T secondi partendo da un secret. Non tutte le app "authenticator" supportano tutte le configurazioni, per cui la più comune è:

• Codici di 6 cifre.
• Intervallo di tempo T di 30 secondi.
• Algoritmo HMAC-SHA1.

Il secret nella maggior parte dei casi è di 20 byte (160 bit) e viene codificato in Base32 (es. CVEBO7GKWLFDRBJRPPTOZ7I6VEPDIGIT). Va generato diverso per ogni utente.

Per la verifica del TOTP la RFC consiglia di usare una tolleranza (drift window) di +/- un intervallo di tempo T (quindi vale sia il codice precedente che quello successivo).

Il secret andrebbe cifrato prima di essere inserito nel database. Nel mio caso ho scelto AES-256 GCM. Nel db vanno quindi salvati il secret cifrato (Base64) più il nonce e il tag AES.

Per la validazione dei codici ho usato la libreria Otp.NET per .NET/C#. Per AES ho usato l'implementazione nativa di .NET.

Per la configurazione iniziale del secondo fattore, all'utente vanno forniti il secret e i vari parametri menzionati sopra (o anche no, dato che quelli indicati qui sopra sono di solito il default), oppure un QR code che contiene un URI con questo formato (inizialmente definito da Google ma ora standard de facto):

otpauth://totp/{label}:{accountName}?secret={secret}&issuer={issuer}";

I parametri vanno URL encoded. La prima etichetta viene mostrata nella UI dell'applicazione authenticator di turno (Google Authenticator, Ente Auth, ecc.) assieme al nome dell'account, mentre l'issuer dovrebbe essere a uso interno.

Il codice QR lo genero server-side in SVG con ZXing.QrCode e lo ritorno nella risposta JSON delle API. Probabilmente si può fare anche client-side, ma avevo già generato QR in C# in un altro progetto per cui ho riciclato il codice.

Per confermare l'abilitazione della 2FA l'utente deve inserire un primo codice TOTP generato dall'app authenticator. C'è la possibilità che l'utente abbandoni il processo a metà, per cui ci vuole un cleanup delle configurazioni che non sono ancora state abilitate dopo 24/48 ore.

Andrebbero poi generati e forniti dei codici di backup/recupero. Nel mio caso sono 10 codici di 8 caratteri presi dall'alfabeto ABCDEFGHJKLMNPQRSTUVWXYZ23456789 (es. BVEZ-MMWP). Sono hashati con Argon2id, come le password, e salvati in una tabella del db. Di conseguenza nel momento della verifica del backup code bisogna verificarli tutti uno a uno per trovare se c'è un match, e poi segnare il codice individuato come già usato.

Come si implementa la verifica del secondo fattore in fase di login? Il login restituisce un token di tipo TwoFactorPending e il frontend fa redirect alla pagina di verifica. Questo token temporaneo permette di usare solo l'endpoint di verifica 2FA. Se il codice inserito dall'utente è corretto viene invalidato il token temporaneo (che ha comunque scadenza breve, es. 5 minuti) e ne viene creato uno nuovo "standard".

La disattivazione del secondo fattore deve richiedere la password dell'utente, mentre la rigenerazione dei codici di backup deve richiedere un codice TOTP valido (per verificare che l'utente sia effettivamente ancora in possesso del secondo fattore).

Bonus: il 95% del codice è stato scritto da Claude Code e dall'inizio alla fine ci abbiamo impiegato circa 3 giorni (progettazione, implementazione di 6 endpoint backend, integration test e tutta la UI con SvelteKit).

Ho pubblicato certs.email: un mini-servizio per essere notificati all'avvicinamento della scadenza dei certificati SSL/TLS dei propri domini.

È gratis e open source e in realtà mi serve prevalentemente per avere un dominio in più che invia email, per poter testare meglio DMARCwise.

Segmentation fault in una build TypeScript mi giunge nuova:

EDIT: era colpa di una libreria con binding Rust, il che ha ancora meno senso in realtà.