Disconnetti un utente da un’app basata su sessione e il server lo dimentica alla richiesta successiva. Disconnettilo da un’app basata su JWT e, a meno che tu non abbia costruito un meccanismo apposito, il token che ha in mano resta valido finché non scade. Questa è la vera decisione dietro “JWT vs sessione”. Il resto ne consegue. Cosa memorizza davvero una sessione Una sessione mantiene lo stato dell’utente sul server e al browser passa solo una chiave di lookup. ...

Cerca “cucciolo” in un sistema che confronta solo le parole chiave e un documento sull’addestramento dei cani non comparirà, anche se chiunque legga entrambi li definirebbe strettamente collegati. La ricerca per parole chiave confronta stringhe di testo. Non sa che “cucciolo” e “cane” significano quasi la stessa cosa. Gli embedding risolvono proprio questo. Trasformano un testo in una lista di numeri, un vettore, posizionato in modo che testi con significato simile finiscano vicini ad altri testi con significato simile, indipendentemente dalle parole usate. ...

Avvolgi una chiamata fetch() in un try/catch, chiama un endpoint che risponde con un 404, e il blocco catch non si attiva mai. La promise si risolve. res.json() analizza qualunque corpo il server abbia restituito, spesso un payload di errore come {"error": "user not found"}, e il resto della funzione lo tratta come il record che aveva richiesto. Nessuna eccezione, nessun avviso in console. Il dato sbagliato continua a propagarsi finché qualcos’altro non va in errore per colpa sua. ...

Una funzione che richiama se stessa ha una profondità massima, ed è più piccola di quanto la maggior parte delle persone si aspetti: 1.000 chiamate in CPython di default, circa 10.000-15.000 in Node e nei motori dei browser, a seconda di quanto pesa ogni frame. Superarla non significa che il programma rallenta: crasha. Python solleva RecursionError: maximum recursion depth exceeded; JavaScript solleva RangeError: Maximum call stack size exceeded. Entrambi gli errori hanno la stessa causa, e una volta vista capisci subito quando la ricorsione è lo strumento giusto e quando diventa un rischio. ...

Stai costruendo una dashboard: un header, una sidebar, un’area di contenuto principale, un footer. Scegli Flexbox perché è lo strumento di layout che conosci, e venti minuti dopo ti ritrovi con tre container display: flex annidati, una sidebar che non mantiene la sua larghezza senza un numero magico, e un footer che fluttua a metà pagina quando il contenuto è poco. Niente di tutto questo è un bug di Flexbox. Stai usando uno strumento monodimensionale su un problema bidimensionale. ...

Metti go davanti a una chiamata di funzione e quella funzione parte in concorrenza col resto del programma, gestita dal runtime di Go invece che dal sistema operativo. Avviarla è la parte facile. La parte difficile è far passare un risultato tra due goroutine senza che si pestino i piedi a vicenda sullo stato condiviso, e quel lavoro lo fanno i channel. Cos’è una goroutine? Una goroutine è una funzione che corre in modo indipendente da quella che l’ha avviata, gestita dal runtime di Go e non dal sistema operativo. Un thread del sistema operativo riserva un megabyte o più di stack e costa al kernel tempo reale per essere pianificato. Una goroutine parte con uno stack di circa 2KB che cresce secondo necessità, e il runtime moltiplexa molte goroutine su una manciata di thread del sistema operativo. Avviarne a migliaia è normale. ...

Una classe che salva un utente nel database, gli manda un’email di benvenuto e formatta una ricevuta è a una modifica di distanza dal rompere due funzionalità con cui non ha niente a che fare. Tocchi il template dell’email e rischi la scrittura sul database. Tocchi il layout della ricevuta e rischi l’email. SOLID sono cinque regole che attaccano questo tipo di groviglio da angolazioni diverse, e condividono un’idea sola: una classe deve cambiare per un solo motivo, e il resto del codice deve dipendere da cosa qualcosa promette di fare, non da come lo fa. ...

Due richieste arrivano sullo stesso endpoint “preleva 100€” a mezzo millisecondo di distanza. Il conto ha 150€. Entrambe le richieste leggono quel saldo, entrambe vedono fondi sufficienti, entrambe approvano, entrambe sottraggono 100€. Il conto finisce a -50€, e nessun ramo del codice avrebbe dovuto permetterlo. Questa è una race condition: il risultato dipende da quale operazione finisce prima, e quel “prima” non lo decide il codice. Cosa causa una race condition? Servono due ingredienti insieme: stato condiviso mutabile, e più di un percorso di esecuzione che lo tocca senza coordinarsi. I percorsi possono essere thread, task async, processi, o due server che colpiscono la stessa riga di database. Togli uno dei due ingredienti e il bug scompare. Un singolo thread non può entrare in race con se stesso, e uno stato immutabile non si corrompe anche se viene letto più volte. ...

Una casella di ricerca che lancia una richiesta a ogni tasto premuto manda cinque richieste per “redis”, e quattro arrivano scadute prima che torni la risposta. Un handler di scroll che ricalcola il layout gira centinaia di volte al secondo e fa scattare la pagina. Stesso problema in entrambi i casi: l’evento del DOM si attiva molto più spesso di quanto serva alla funzione. Debounce e throttle lo risolvono in due modi diversi. ...

Cosa fa davvero un decoratore alla tua funzione Vuoi misurare il tempo di ogni funzione che chiama un’API esterna lenta. Puoi incollare chiamate a time.perf_counter() in ognuna, oppure scrivere la misurazione una sola volta e applicarla ovunque. Un decoratore è la seconda opzione: è una funzione che prende un’altra funzione, la avvolge in un comportamento aggiuntivo e restituisce la versione avvolta con lo stesso nome originale. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # al posto di una chiamata di rete return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed sopra def fetch_price è l’abbreviazione di fetch_price = timed(fetch_price). Python chiama timed una sola volta, subito dopo la definizione di fetch_price, e ricollega il nome fetch_price a quello che timed restituisce. Tutto quello che fa la @ è questo. ...