Esegui 0.1 + 0.2 in una shell Python e non ottieni 0.3. Ottieni 0.30000000000000004. Prova in JavaScript, Java, Go, C o Rust e trovi la stessa coda di sedici cifre. Ognuno di questi linguaggi fa esattamente quello che impone lo standard hardware. Un numero che richiederebbe infinite cifre binarie viene compresso in 64 bit, e qualcosa deve cedere. Perché 0.1 non si può memorizzare esattamente in binario I computer memorizzano i numeri in virgola mobile in base 2. In base 2, la frazione 1/10 ha uno sviluppo periodico, proprio come 1/3 si ripete all’infinito in base 10 (0.3333...). Scritto per intero, 0.1 in binario inizia così: ...

Un endpoint di login restituisce un JWT, e hai tre posti dove metterlo: un cookie, localStorage o sessionStorage. Scegli quello sbagliato e succede una di due cose: un bug XSS si porta via il token, oppure il token non arriva mai alla tua API. Tutti e tre salvano stringhe nel browser. Cambiano su chi può leggerle, quanto durano e se il server le vede o no. Che differenza c’è tra localStorage, sessionStorage e cookie localStorage e sessionStorage sono la stessa API, l’interfaccia Storage: setItem, getItem, removeItem, clear, chiavi e valori sempre stringa. La differenza è la durata. localStorage sopravvive alla chiusura del browser e al riavvio della macchina, e resta finché qualcosa non lo svuota. Safari è l’eccezione: con la tracking prevention attiva, elimina lo storage scritto da script per un sito con cui l’utente non ha interagito da sette giorni. sessionStorage appartiene a una singola tab e muore quando quella tab si chiude. Digiti lo stesso URL in una seconda tab e ottieni un sessionStorage nuovo e vuoto; solo “Duplica tab” lo copia. ...

Una lookup su un dizionario Python impiega circa 100 nanosecondi, che il dizionario contenga 1.000 chiavi o 1.000.000. Un doppio ciclo che cerca duplicati in una lista impiega mezzo millisecondo su 200 elementi e 136 millisecondi su 3.200. Sedici volte l’input, quasi 280 volte l’attesa. Stessa macchina, stesso Python. La notazione Big O è il nome di quella differenza. Cosa misura la notazione Big O Big O descrive come cresce il tempo di esecuzione (o l’uso di memoria) di un pezzo di codice all’aumentare dell’input. Non è una lettura al cronometro e non le importa se il tuo portatile è veloce o lento. Le interessa la forma della curva di crescita: raddoppiando l’input, il tempo raddoppia, quadruplica, o si muove appena? ...

Esegui git reset --hard su un commit che il tuo team ha già scaricato e la tua storia smette di corrispondere alla loro. Esegui git revert su un typo che non hai ancora pushato e aggiungi un commit inutile al log. Git ha quattro comandi per annullare le cose: restore, reset, commit --amend e revert, e non sono intercambiabili. Scegli quello sbagliato e il risultato è che non succede niente, oppure succede molto più di quanto volevi. ...

Una JOIN scritta male non genera un errore. Viene eseguita, restituisce un risultato, e le righe sono sbagliate: clienti che mancano, totali gonfiati, record orfani invisibili. Nella maggior parte dei casi la query ha chiesto esattamente quello che ha ottenuto, e chi l’ha scritta ha scelto il tipo di join sbagliato, oppure ha filtrato nel punto sbagliato. Una join combina le righe di due tabelle in base a una condizione che scrivi tu. Quali righe sopravvivono dipende dal tipo di join, e i sei tipi descritti sotto danno sei risposte diverse partendo dalle stesse due tabelle. ...

Ecco una classe che non puoi testare senza un database live e un server SMTP funzionante: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService costruisce da sé SqlOrderRepository e SmtpEmailSender con new, connection string compresa. Ogni test che tocca PlaceOrder richiede un vero database Orders e un vero server di posta, altrimenti fallisce prima ancora che la tua assertion venga eseguita. La logica che vuoi testare sta in due righe: salva l’ordine, invia la conferma. Ma è saldata a due classi concrete che non puoi sostituire. ...

Installa due progetti Python sulla stessa macchina e il secondo può rompere il primo. Uno richiede requests==2.28, l’altro requests==2.32, e pip ha un’unica cartella site-packages di sistema in cui scrivere. L’ultima installazione vince, in silenzio. Te ne accorgi quando l’altro progetto comincia a lanciare errori che non hanno nulla a che fare con il codice che hai appena modificato. Un ambiente virtuale dà a ogni progetto il proprio site-packages. Il venv non tocca nulla a livello globale, e due progetti possono dipendere da versioni incompatibili della stessa libreria senza che nessuno dei due se ne accorga. ...

Una funzione può avere il 100% di copertura dei test unitari e la pagina che la chiama può comunque restituire un 500 in produzione. Non è una contraddizione. Test unitari, test di integrazione e test end-to-end controllano cose diverse, e una suite pesante su uno e leggera su un altro ha un buco specifico e prevedibile. Cosa controllano test unitari, di integrazione ed end-to-end Prendi una funzionalità di registrazione: una funzione valida l’input, scrive una riga su un database e invia un’email di benvenuto. Tre test possono coprirla, e ognuno risponde a una domanda diversa. ...

Esegui questo snippet in Node o nella console del browser: 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); L’output è 1 4 3 2. Un setTimeout con un ritardo di 0ms viene eseguito comunque dopo il callback della promise, ed entrambi partono solo dopo che tutto il codice sincrono, incluso quello scritto più avanti, è terminato. async/await si basa su questo stesso ordine, non introduce un meccanismo nuovo. La maggior parte dei comportamenti sorprendenti nel JavaScript asincrono nasce dal trattare await come se sospendesse l’intero programma, quando in realtà sospende solo la funzione in cui si trova. ...

Su una tabella da un milione di righe, la stessa SELECT può richiedere cinquanta millisecondi oppure molto meno di uno. L’unica differenza è se il database legge riga per riga per trovare quelle che hai chiesto, oppure salta dritto a quelle giuste. Un indice è ciò che gli permette di saltare, e lo paghi a ogni scrittura. Concretamente, un indice è una seconda copia ordinata di una o più colonne, salvata accanto alla tabella e aggiornata automaticamente ogni volta che la tabella cambia. Il database la usa per raggiungere le righe corrispondenti senza toccare il resto. ...