Immaginate di aver appena finito di compilare un kernel custom o di aver fatto girare un modello di IA locale su un vecchio hardware ricavato da un Mac Studio dismesso: quel senso di trionfo che svanisce istantaneamente quando il database principale inizia a implodere sotto il carico di troppe connessioni simultanee.

Se siete come me, avete passato ore a ottimizzare query e a limare ogni millisecondo di latenza, ma c’è un limite fisico a quanto un singolo nodo PostgreSQL possa reggere prima di iniziare a lanciare errori che farebbero piangere un sysadmin senior. È qui che entra in gioco PgDog, e la notizia è che hanno appena ottenuto i fondi per scalare seriamente.

Per chi non mastica database tutto il giorno, PgDog non è solo un altro tool nel mucchio. Si presenta come un connection pooler, un load balancer e un proxy per lo sharding di PostgreSQL. In parole povere? È il pezzo di infrastruttura che promette di far scalare Postgres orizzontalmente senza costringervi a riscrivere l’intera logica della vostra applicazione. Se il vostro progetto sta crescendo e non volete passare le notti a implementare una logica di sharding manuale che sembra uscita da un incubo di un programmatore degli anni ’90, questa roba potrebbe essere la vostra ancora di salvezza.

Da smanettone, la cosa che mi eccita di più è l’idea di poter gestire carichi pesanti mantenendo l’architettura pulita. Non c’è niente di peggio che vedere il proprio codice trasformarsi in un groviglio di workaround per gestire la distribuzione dei dati. L’idea di avere un proxy che si occupa della parte sporca del load balancing e dello sharding è pura poesia per chi ama la pulizia architettonica.

Certo, come sempre nel mondo del software, bisogna mantenere un briciolo di sano scetticismo. I finanziamenti sono un’ottima notizia per la sopravvivenza del progetto, ma portano con sé la classica pressione: l’hype deve trasformarsi in stabilità. Non vogliamo un tool che ci promette il paradiso e poi ci lascia in mano un sistema instabile che richiede più manutenzione di una vecchia stampante dot matrix.

In conclusione, per noi che amiamo smontare processi e costruire sistemi che funzionino senza troppi fronzoli, PgDog è un progetto da tenere d’occhio sul radar. Se riusciranno a mantenere la promessa di scalabilità senza aggiungere strati di complessità inutili (quel tipico ‘bloat’ che odiamo), potrebbero diventare un pilastro fondamentale per chiunque stia costruendo qualcosa di serio. Incrociamo le dita e speriamo che il prossimo aggiornamento non rompa i nostri script di automazione!

Source: PgDog is funded and coming to a database near you

Immaginate di passare da un set di attrezzi già pronti e super efficienti, dove tutto si incastra alla perfezione senza troppi sbatti, a una officina piena di torni a controllo numerico, saldatrici a induzione e calibri digitali che richiedono una laurea in ingegneria solo per essere accesi. Ecco, questo è esattamente il mood di chi decide di migrare da Go a Rust.

È uscito un nuovo articolo che analizza questo passaggio, e non è la solita solfa da hype-festing per convincerti che ‘Rust è più veloce’. Se fosse solo una questione di performance, avremmo già migrato tutto il web. Il punto è molto più profondo e, onestamente, molto più interessante per chi non si accontenta del ‘funziona e basta’. Si parla di garanzie di correttezza, di gestione chirurgica del runtime e di quella soddisfazione quasi erotica che si prova quando il compilatore ti dice che il tuo codice è sicuro, invece di lasciarti scoprire un memory leak alle tre di notte mentre cerchi di far girare un vecchio emulatore.

L’autore chiarisce subito una cosa fondamentale: questa non è la guida per chi scrive firmware embedded o motori grafici (anche se lo sappiamo tutti che Rust lì è il re). È una guida per chi vive nel mondo dei servizi backend, dove Go è attualmente il re indiscusso grazie alla sua semplicità, ai binari statici minuscoli e a una libreria standard che ti risolve la vita senza chiederti il permesso.

Il mio punto di vista? Se sei un maker che ama smontare i processori o che passa le serate a modellare componenti in Blender per poi stamparli in 3D, il passaggio a Rust è una sfida intellettuale pazzesca. È come passare dal montare un kit LEGO a forgiare i tuoi stessi mattoncini partendo dal metallo fuso. C’è più fatica, c’è più frustrazione quando il Borrow Checker decide di farti il mazzo, ma il controllo che ottieni sul sistema è di un altro livello.

Per noi che amiamo ‘mettere le mani in pasta’, questa migrazione non è solo un refactoring del codice, è un cambio di filosofia. Significa accettare che la comodità di Go (che è fantastico, non fatevi strane idee) a volte può essere un limite quando vuoi che il tuo software sia una macchina perfetta, priva di bug latenti e ultra-efficiente.

Insomma, se state cercando la via più breve per consegnare un progetto prima di cena, restate su Go. Ma se volete costruire qualcosa che sia una vera opera d’ingegneria, dove ogni byte è pesato e ogni allocazione è sotto il vostro comando, allora preparate il caffè forte: il viaggio verso Rust è appena iniziato.

Source: Migrating from Go to Rust

Se c’è una cosa che mi fa sudare freddo da hacker, è quando un colosso come Google decide che sa come funziona la navigazione web. Siamo abituati a smontare le cose, a vedere il codice che c’è sotto il bel resto, ma a volte sembra che ci stiano mettendo delle cinghie per i polsi digitali.

L’ultima notizia è arrivata da Google Search: stanno rafforzando le policy anti-spam per un fenomeno che chiamano «back button hijacking». Spoiler: è una roba che fa impazzire chiunque abbia mai provato a fare un *tinkering* sul codice di un sito. In soldoni, si tratta di siti che interferiscono con il pulsante Indietro del tuo browser, rompendo l’aspettativa fondamentale dell’utente: clicchi Indietro e torni esattamente dove eri.

Il concetto è semplice, ma il dibattito è pesante. Questi siti, per qualche motivo (forse vogliono venderti un NFT che non ti serve, o magari vogliono che tu guardi una pubblicità su un argomento che non ti interessa), ti deviano la rotta. Invece di tornare alla pagina A, ti buttano sulla pagina B, o ti bombardano di raccomandazioni che non hai chiesto. Google dice che questo è un comportamento manipolatorio e, perciò, un’infrazione di «malicious practices».

E qui arrivo io, con la mia solita dose di cinismo da nerd. Naturalmente, quando sento parlare di «user experience» e «malicious practices» con quel tono quasi evangelico, mi viene da fare un colpo di tosse. È il classico *corporate-speak* che maschera un semplice desiderio di controllo algoritmico. Non è tanto che il pulsante Indietro sia magico, è che rappresenta la *libertà di errore* del web. Il bello di un sito, soprattutto per noi che amiamo fare esperimenti, è che a volte rompe, a volte ti porta fuori strada per un secondo, e va bene così. È il caos che ci ispira.

Per noi maker, hacker e sviluppatori, questo significa che il confine tra «interferenza utente» e «interazione creativa» si sta assottigliando pericolosamente. Siamo costretti a scrivere codice non solo per far funzionare un’idea, ma anche per dimostrare a un algoritmo che non stiamo manipolando l’utente. È un livello di *gatekeeping* che ci fa venire voglia di rispolverare il vecchio terminale e tornare al periodo d’oro del retrocomputing, quando l’unica cosa che contava era che il codice compilasse, punto.

Quindi, cosa fare? Per chi di noi sta lavorando a qualcosa di sperimentale, che magari sfrutta un *redirect* o un *event listener* un po’ più aggressivo per un effetto visivo o un *flow* narrativo complesso, preparatevi. Dovrete rivedere ogni singola linea di codice che tocca la navigazione utente. Non si tratta solo di pulizia tecnica, è un cambio di mentalità: il codice deve essere trasparente, prevedibile e, soprattutto, *non deve nasconderti nulla*.

In sintesi: il web si sta rendendo troppo ordinato. E se c’è una cosa che amo, è l’imprevedibilità. Ci vediamo nel *terminale*, dove le regole sono solo un suggerimento, non un decreto.

Source: A new spam policy for “back button hijacking”

Ammettiamolo: negli ultimi anni, fare il web developer era diventato un po’ come costruire un castello di sabbia durante una tempesta. Ogni volta che pensavi di aver finito una parte, ne spuntava fuori un’altra da rifare, con un nuovo framework, un nuovo bundler, un nuovo modo di fare le cose.

Io mi sono ritrovato a passare più tempo a configurare Webpack che a scrivere codice vero e proprio. E non parliamo della complessità del frontend: Core Web Vitals, SEO, responsive images… sembrava di dover essere un mago per far funzionare tutto correttamente. Ricordo ancora con affetto i tempi del PHP 4 e di jQuery, quando un sito lo tiravi su in un weekend e non dovevi preoccuparti di millemila librerie e dipendenze.

Certo, la tecnologia è progredita, e questo è positivo. Ma la complessità è cresciuta a un ritmo spaventoso, superando la mia capacità di seguirla. Mi sono specializzato nel backend, abbandonando il frontend perché non riuscivo più a stare al passo con l’evoluzione dei tool. Come molti di voi, immagino.

Ma ora, finalmente, c’è una speranza. L’AI è entrata in gioco, e sta cambiando le regole del gioco. Ho provato Claude e Codex, e devo dire che sono rimasto impressionato. Mi hanno dato la spinta di produttività che mi mancava da anni. Posso tornare a gestire l’intero stack, con più sicurezza e meno stress.

Non è magia, ovviamente. L’AI non è perfetta, e bisogna comunque controllare il codice che genera. Ma mi permette di automatizzare le attività ripetitive, di risolvere i problemi più velocemente, e di concentrarmi sulla parte creativa del lavoro. Posso andare da un’idea all’esecuzione in pochi giorni, invece che in settimane o mesi.

E non si tratta solo di scrivere codice. L’AI può aiutarmi a replicare gli standard di codifica, il tono di voce, le tattiche e i processi di altri sviluppatori. È come avere un team di esperti a disposizione, pronto a darmi una mano quando ne ho bisogno. Per noi che amiamo smanettare, significa poter sperimentare di più, provare nuove idee, e aggiungere quel tocco di qualità in più che fa la differenza.

Certo, c’è sempre il rischio del vendor lock-in e della dipendenza da queste piattaforme AI. Ma per ora, mi godo il momento. Web development è tornato ad essere divertente, e questo è un bene per tutti noi.

Source: Web development is fun again