Guide pratiche ed evergreen per sviluppatori. Ognuna parte da comandi reali ed esempi funzionanti, e dice chiaramente quando non usare lo strumento che spiega.
Qui sotto trovi tutto, dal piu recente.
Guide pratiche ed evergreen per sviluppatori. Ognuna parte da comandi reali ed esempi funzionanti, e dice chiaramente quando non usare lo strumento che spiega.
Qui sotto trovi tutto, dal piu recente.
Chiedi a un modello di rispondere in JSON e nella maggior parte dei casi json.loads() funziona senza problemi. I casi che ti costano una sessione di debug sono altri: un commento su una riga dentro l’oggetto, un code fence markdown che lo avvolge, una chiave scritta userEmail quando il tuo codice si aspetta user_email. Un prompt più rigido (“rispondi SOLO con l’oggetto JSON, nessun altro testo”) rende questi casi più rari. Non li rende impossibili, perché il modello può comunque ignorare la richiesta. Con l’output strutturato la richiesta diventa superflua: passi all’API un JSON Schema, che vincola il campionamento dei token del modello così che la risposta debba rispettarlo. ...
Scrivi .sidebar .card { color: blue; }, carichi la pagina e la card è ancora rossa, per colpa di una regola aggiunta un’ora prima: .card { color: red; }. La nuova regola viene dopo nel file. Perde comunque. Il browser confronta i due selettori con un sistema a punti fisso, e .sidebar .card ottiene un punteggio più alto di .card, indipendentemente da chi è stato scritto per ultimo. Quel sistema a punti è la specificità. Una volta che sai calcolarla a colpo d’occhio, “perché il mio CSS non si applica” diventa aritmetica. Non ha niente a che fare con il layout: Grid o Flexbox decide dove si posiziona un elemento, la specificità decide quale regola ne imposta colore o dimensione quando due regole sono in conflitto. ...
Cerca una chiave in un dict Python con dieci elementi e ci metti lo stesso tempo che cercarla in un dict con dieci milioni. Non è un caso dovuto a un linguaggio veloce. Il dict di Python, la HashMap di Java e la Map di JavaScript sono tutte hash table, e l’intero design esiste per far girare lookup, inserimento e cancellazione in O(1) in media. La notazione Big O chiama questa lookup “tempo costante”. Ecco il meccanismo che se lo merita. ...
Un programma in C che libera un buffer e continua a leggerlo compila comunque. Poi corrompe la memoria, a volte subito, a volte tre richieste più tardi, in una parte di codice che quel buffer non lo ha mai toccato. Rust rifiuta quel programma già al cargo build, senza alcun garbage collector di mezzo. Il compilatore tiene traccia di chi possiede ogni valore e di chi può accedervi. Questo tracciamento si chiama ownership e borrowing. ...
Un test per place_order ha bisogno di un gateway di pagamento, un client SMS e un calcolatore delle tasse. Se collegassi quelli veri, ogni esecuzione del test addebiterebbe una carta e manderebbe un SMS a un numero reale. Un test unitario deve girare in pochi millisecondi, senza rete, quindi tutti e tre vanno sostituiti con qualcos’altro. Quel “qualcos’altro” si presenta in cinque forme — ognuna risolve un problema diverso — e trattarle come intercambiabili è il motivo per cui le discussioni “basta mockarlo” in code review girano in tondo. ...
Salvi un file, Prettier lo riformatta, ed ESLint segnala subito un errore sulla riga che Prettier ha appena toccato. Entrambi gli strumenti sono configurati, entrambi sono attivi, e invece di aiutarti si combattono a vicenda. I due strumenti fanno lavori diversi. Il problema è che hanno entrambi un’opinione su una cosa sola: come deve apparire il codice sulla pagina. Cosa controlla davvero ESLint ESLint analizza il codice in un albero di sintassi astratto e applica regole sulla sua struttura. Il suo contributo più utile sono le regole che individuano bug reali: una variabile mai definita, un return irraggiungibile dopo un altro return, un import rimasto inutilizzato dopo un refactoring, una chiave duplicata in un oggetto che sovrascrive la prima in silenzio. Sono controlli semantici: ESLint legge cosa fa il codice. ...
Perché un bonifico bancario richiede più di due UPDATE Sposta 50€ da un conto a un altro. Nella versione naive bastano due istruzioni: sottrai dal conto A, aggiungi al conto B. Eseguile separatamente e, se il processo va in crash o la connessione cade tra le due, il denaro è sparito da A e non arriva mai su B. Il database ha fatto esattamente quello che gli è stato chiesto, due volte. Il business ha perso 50€ comunque. ...
Perché “sembra giusto” non è un test per un prompt Stringi il testo di un prompt che instrada i ticket, lo provi sui tre esempi che hai aperti nel tuo notebook e lo metti in produzione. Una settimana dopo, i reclami di fatturazione che prima finivano nella coda giusta cominciano a finire in “domanda”. Non i tre casi che hai controllato: gli altri quattrocento che non hai controllato. Niente va in crash. Non c’è nessuno stack trace. Il prompt, letto ad alta voce, suona ancora bene. ...
Un componente di chat riconnette il suo WebSocket ogni volta che scrivi una lettera in una casella di ricerca che non ha niente a che fare con la chat. Un altro componente si ri-renderizza in loop finché la tab si blocca. Un terzo registra il suo useEffect due volte al montaggio, ma solo in sviluppo. Nessuno di questi è un bug di React. I primi due sono l’array delle dipendenze che fa esattamente quello che gli hai detto di fare, e il terzo è la Strict Mode che verifica che il tuo effetto sappia pulire dopo di sé. ...
<.+> contro <b>bold</b> and <i>italic</i> non trova <b>. Trova l’intera stringa, dal primo < all’ultimo >. Non c’è nessun bug. È esattamente quello che un quantificatore greedy deve fare, ed è anche il bug più comune in assoluto quando “il regex matcha troppo”. Una volta capito cosa fa il motore mentre legge il pattern, questo bug e i suoi parenti smettono di essere misteriosi. Come un Motore Regex Legge il Pattern Un motore regex non confronta il pattern con la stringa come si confrontano due stringhe per uguaglianza. I motori che usi ogni giorno (re di Python, RegExp di JavaScript, PCRE, .NET, Java) sono regex-directed: scorrono il pattern da sinistra a destra, token per token, e per ogni token provano a consumare caratteri dalla stringa nella posizione attuale. Quando un token trova corrispondenza, il motore avanza sia il puntatore del pattern che quello della stringa. Quando un token fallisce, il motore fa backtracking: torna all’ultimo punto in cui aveva una scelta, come un quantificatore che poteva fermarsi prima o un ramo di un’alternanza non ancora provato, e prova l’altra opzione. ...