Perché any fa perdere il tipo che hai passato? Tipizza un parametro come any e TypeScript smette di controllare tutto ciò che esce dalla funzione: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, va in crash a runtime Tu sai di aver passato un array di numeri. Il compilatore no, perché any gli dice di smettere di guardare. n torna come any, quindi chiamare un metodo di stringa su un numero compila senza problemi e lancia TypeError: n.toUpperCase is not a function quando viene eseguito. ...

Apri un file che non esiste in Python e open() lancia un FileNotFoundError che risale fuori dalla tua funzione. Fai la stessa cosa in Go e os.ReadFile ti restituisce un valore error accanto a uno slice di byte nil. Stesso fallimento, due forme di codice completamente diverse attorno ad esso. La differenza non è estetica. Decide se chi chiama la funzione può ignorare il fallimento per errore, e se il compilatore se ne accorge quando succede. ...

Sei a metà di un feature branch, tre file modificati e niente ancora committato, quando un collega ti scrive per un crash da null pointer in produzione. La mossa classica è git stash, checkout di main, risolvi, pusha, poi git stash pop sperando che il lavoro a metà non dipendesse dai file da cui sei appena scappato. git worktree salta tutto questo. Fa il checkout del branch di hotfix in una seconda cartella, accanto al tuo feature branch, entrambe appoggiate sullo stesso repository. ...

Un client bloccato in un retry loop senza backoff può generare, in un minuto, più carico sulla tua API di quanto ne generino insieme altri diecimila client. Visto da te non sembra un attacco: sembra un bug dalla loro parte, che diventa un incidente dalla tua. Un rate limiter blocca quel client prima che arrivi a quel punto. Cosa decide davvero un rate limiter? A ogni richiesta, il limiter si pone una sola domanda: questa chiave ha fatto troppe richieste nella finestra attuale? Tre scelte trasformano quella domanda in qualcosa che puoi implementare. ...

Cosa fa davvero il function calling negli LLM Chiedi a un modello “che tempo fa ad Austin in questo momento” senza nessuna connessione con il mondo esterno, e hai due opzioni: dire che non lo sa, o inventare qualcosa. Il function calling offre una terza opzione. Il modello descrive cosa gli serve, passa quella descrizione al tuo codice e aspetta una risposta vera prima di rispondere. Il nome è un po’ fuorviante. Il modello non chiama niente. Emette un blocco di dati strutturati che dice quale tool vuole e con quali argomenti, e la tua applicazione decide se eseguirlo e cosa fare con il risultato. “Tool use” è il termine più accurato, ed è quello usato nella documentazione di Anthropic; OpenAI e Google parlano quasi sempre di function calling. Il meccanismo è lo stesso sotto entrambi i nomi. Il modello produce solo una richiesta, mai l’effetto collaterale. ...

Un listener scroll su window può scattare centinaia di volte durante un singolo swipe. Se ad ogni evento esegui getBoundingClientRect() su tutte le card di un feed, bastano cinquanta immagini per inchiodare la pagina. La Intersection Observer API toglie quel controllo dal percorso dello scroll: registri quali elementi osservare e il browser ti avvisa quando la loro visibilità cambia davvero. Come funziona IntersectionObserver Un observer osserva uno o più elementi target rispetto a un root (di default il viewport) e invoca una callback ogni volta che un target supera una soglia di visibilità. ...

Apri un file salvato come UTF-8 in uno strumento che assume una codifica diversa e café diventa café. I byte sul disco non sono cambiati. È cambiata solo la regola usata per trasformarli di nuovo in caratteri, e le due regole non sono d’accordo su cosa significhi il byte 0xC3. La maggior parte dei bug da “caratteri strani” — nomi di file corrotti, moduli web illeggibili, emoji che fanno fallire un insert nel database, due stringhe identiche all’occhio ma diverse nel confronto — nasce dalla stessa confusione tra due cose distinte: Unicode e UTF-8. ...

Cos’è una closure in JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter viene eseguita una volta, restituisce una funzione, e la sua chiamata finisce lì: lo stack frame non esiste più. Eppure ogni chiamata a counter() legge e aggiorna count, una variabile dichiarata dentro una funzione già terminata. count non torna a 0, e non viene copiata. È la stessa variabile, ancora viva, tre chiamate dopo. ...

Un test scritto dopo il codice tende a verificare quello che il codice fa, non quello che doveva fare. Il test-driven development risolve il problema invertendo l’ordine: scrivi il test, guardalo fallire, poi scrivi il minimo codice che lo fa passare. Dato che il test esiste prima del codice che controlla, non può confermare silenziosamente qualunque cosa il codice restituisca. Kent Beck ha formalizzato questo ciclo come red, green, refactor nel suo libro del 2002 Test-Driven Development: By Example. Il nome è rimasto. ...

Lancia npm install su un progetto, poi pnpm install sullo stesso package.json: ottieni due alberi node_modules diversi e due lockfile diversi. Aggiungi un collega che usa Yarn e il repository finisce con tre lockfile nella sua storia, ognuno con un albero delle dipendenze leggermente diverso. Tutti e tre leggono lo stesso package.json e scaricano dal medesimo registro npm. Il punto su cui i tre non sono d’accordo è cosa scrivere su disco. ...