Ecco una lezione di umiltà per chi pensa che spendere miliardi risolva tutti i problemi: la missione Lunar Trailblazer della NASA, destinata a mappare l’acqua sulla Luna, è stata cancellata in un solo giorno. Cause? Errori di design e test che un qualsiasi maker avrebbe potuto evitare con un po’ di attenzione in più.

Immagino già i meeting di NASA: ‘Ok, lanciamo un satellite da 72 milioni senza testare abbastanza il software. Cosa potrebbe andare storto?’ Spoiler: tutto.

Il problema? Un bug nel sistema di comunicazione che ha fatto sì che il satellite non potesse più ricevere comandi. Niente di particolarmente complesso, ma abbastanza grave da rendere inutile una missione pianificata per anni. E qui veniamo al punto interessante: perché succedono queste cose?

Da smanettone, mi viene da dire che a volte la fretta di ‘lanciare prima degli altri’ (sì, anche nello spazio) fa dimenticare le basi. Testare, testare, testare. E poi testare ancora. Soprattutto quando si parla di hardware e software che non possono essere ‘aggiornati’ una volta in orbita.

Ma cosa significa per noi, che passiamo le notti a smanettare con Arduino e Raspberry Pi? Che anche i progetti più piccoli meritano la stessa attenzione. Un bug in un firmware può rovinare mesi di lavoro, e se non testate a dovere il vostro ultimo gadget, potreste ritrovarvi con un mucchio di componenti inutili.

E poi c’è la questione del vendor lock-in. La NASA usa sistemi proprietari? Probabilmente sì. E questo ci porta a un’altra lezione: quando possibile, preferite soluzioni open-source e ben documentate. Almeno se qualcosa va storto, potete metterci le mani dentro e provare a sistemarlo.

In conclusione: sì, la tecnologia è fantastica, ma senza una buona dose di prudenza e test, anche i progetti più costosi possono finire in fiamme (metaforicamente, speriamo). Quindi, la prossima volta che lanciate un satellite, o anche solo un drone in giardino, ricordate: testate, testate, testate.

E se proprio volete un consiglio extra: prima di inviare qualcosa nello spazio, fate un backup. Mai sa.

Source: The Stupidest Glitch Imaginable Killed a $72 Million Lunar Mission in a Single Day

Se pensavi che i tuoi Arduino fossero veloci, preparati a un bel sorpasso. OpenAI ha appena svelato GPT-5.3-Codex-Spark, un modello di codice che promette prestazioni da record grazie a chip che sembrano piatti da portata. 15 volte più veloce del precedente, dice la casa. Ma andiamo con ordine.

La notizia è che OpenAI ha deciso di non dipendere più da Nvidia per i suoi chip. Hanno sviluppato una soluzione custom che, secondo loro, è rivoluzionaria. I dettagli tecnici sono ancora un po’ nebulosi, ma sappiamo che questi chip sono grandi come piatti da dessert e consumano meno energia. Un bel passo avanti, soprattutto per chi come noi ama spingere i limiti del possibile.

Ora, io non sono un esperto di architetture di chip, ma so riconoscere un game-changer quando ne vedo uno. Se davvero questi nuovi chip sono così efficienti, potremmo vedere una rivoluzione nel modo in cui sviluppiamo e testiamo i nostri progetti. Immaginate di poter compilare codice complessissimo in frazioni di secondo, o di addestrare modelli di machine learning senza dover vendere un rene per pagare la GPU.

Ma attenzione, non è tutto oro quel che luccica. OpenAI è una compagnia chiusa, e i loro chip custom potrebbero diventare un altro esempio di vendor lock-in. Se diventano lo standard, saremo di nuovo dipendenti da un unico fornitore. E poi, chi ci garantisce che questi chip saranno accessibili ai maker e agli smanettoni? Il rischio è che diventino un altro giocattolo per le grandi corporation.

Per noi che amiamo mettere le mani nella roba, la domanda è: quando potremo metterci le mani su questi chip? E soprattutto, a che prezzo? Se OpenAI renderà questa tecnologia accessibile, potremmo vedere una nuova ondata di innovazione. Se invece la terranno per sé, sarà un altro esempio di tecnologia promettente sprecata.

In ogni caso, è sempre bello vedere qualcuno che osa sfidare il monopolio di Nvidia. E chissà, magari tra qualche anno saremo tutti a smanettare con piatti da dessert che eseguono codice. In bocca al lupo, OpenAI!

Source: OpenAI sidesteps Nvidia with unusually fast coding model on plate-sized chips

Sai quella sensazione quando apri il frigo e ti accorgi che hanno rilasciato un’altra versione di GPT? Ecco, è successo di nuovo. OpenAI ha presentato il GPT-5.3-Codex, e il mondo tech si è subito diviso tra chi urla al miracolo e chi alza gli occhi al cielo.

Partiamo dalle basi: GPT-5.3-Codex è l’ultimo figlio della famiglia di modelli linguistici di OpenAI, quello che dovrebbe farci codeare come dei dio in pigiama. Promette di capire meglio il contesto, generare codice più pulito e, naturalmente, farci risparmiare ore di debug. Ma, diciamocelo, dopo GPT-4, GPT-4.5, GPT-5 e ora questo mezzo punto in più, siamo un po’ stanchi di vedere numeri che salgono come la febbre a Natale.

Da smanettone a smanettone, però, devo ammettere che questa versione ha qualche miglioramento concreto. Per esempio, gestisce meglio le dipendenze tra package e sembra meno propensa a inventarsi funzioni che non esistono. Inoltre, ha un nuovo sistema di suggerimento per l’ottimizzazione del codice che, se usato con criterio, può davvero essere utile. Ma attenzione: non stiamo parlando di magia. Anzi, se hai mai provato a fargli scrivere un driver per un Arduino esotico, sai già che è meglio tenerlo alla larga da certi compiti.

Il problema grosso, come sempre, è il vendor lock-in. OpenAI continua a spingere i suoi modelli come se fossero l’unica opzione possibile, e questo fa male alla community. Se sei uno che ama sperimentare con modelli open-source o vuole evitare di finire nella lista nera di qualche corporation, forse è il caso di guardare altrove. E poi, ammettiamolo: pagare per ogni richiesta inizia a pesare, soprattutto quando metà delle risposte sembrano uscite da un tutorial di Stack Overflow tradotto male.

Ma non tutto è perduto. Se sei uno di quelli che passa le notti a programmare con Arduino o a fare reverse engineering di vecchi videogiochi, GPT-5.3-Codex potrebbe comunque darti una mano. Provalo con i tuoi progetti più pazzi, vediamo se riesce a reggere il confronto. E se invece si blocca su un loop infinito, beh, almeno avrai qualcosa di nuovo da postare su Reddit.

In conclusione, GPT-5.3-Codex è un passo avanti, ma non la rivoluzione. Usalo con intelligenza, non farti abbindolare dallo hype, e soprattutto: non dimenticare che il vero potere sta nelle tue mani, non nei numeri di versione.

Source: GPT-5.3-Codex

E se ti dicessi che i log possono essere più colorati di un arcobaleno in un giorno di pioggia?

Sì, lo so, sembra una promessa da venditore di cialde per la stampante 3D, ma fidati: ho appena vibe-codato un log colorizer e ora mi sento come un bambino che ha scoperto come far suonare il campanello del vicino con un circuito fatto in casa.

La storia parte da un articolo su Ars Technica, dove un autore (probabilmente dopo aver bevuto un po’ troppo caffè) ha deciso di condividere le sue riflessioni su come gli LLMs stanno invadendo la sua vita. E, tra una cosa e l’altra, ha creato questo tool per rendere i log più… vibey. Insomma, un po’ di colore per quelle righe grigie e noiose che passiamo ore a debuggare.

Ora, io non sono uno che si impressiona facilmente. Ho visto Raspberry Pi trasformati in server, Arduino che controllano interi impianti di illuminazione, e ho persino provato a far parlare tra loro due vecchi modem con un cavo telefonico. Ma questa cosa dei log colorati mi ha fatto sorridere. Perché, diciamocelo, chi non vorrebbe che il proprio terminale sembri un festival di luci?

Ma veniamo al punto: cosa significa per noi, che passiamo le notti a smanettare con circuiti e codice? Beh, innanzitutto, è un’altra prova che la tecnologia può essere divertente. Non dobbiamo sempre prendere tutto sul serio. A volte, un po’ di colore (letteralmente) può rendere il lavoro meno monotono.

E poi, ammettiamolo: i log sono il pane quotidiano di chi programma. Li odiamo, li amiamo, li malediciamo. Ma se possiamo renderli un po’ più piacevoli, perché no? Certo, non è la rivoluzione del secolo, ma è un piccolo passo verso un mondo in cui anche il debugging può essere un po’ più cool.

Ora, qualche critica: sì, potremmo discutere del vendor lock-in, della privacy, e di tutte quelle cose noiosissime che ci fanno venire il mal di testa. Ma oggi, per una volta, lasciamo perdere. Godiamoci il momento.

E poi, chi lo sa? Magari tra un po’ scopriremo che anche i nostri Arduino possono avere log colorati. E allora sì che sarà il vero paradiso per gli smanettoni.

Quindi, se anche tu hai voglia di aggiungere un po’ di colore alla tua vita da maker, perché non provi a fare qualcosa di simile? E se non funziona, beh, almeno avrai passato una serata a giocare con il codice. E questo, in fondo, è già una vittoria.

Source: So yeah, I vibe-coded a log colorizer—and I feel good about it

Avete presente quando ti dicono che un robot ti sostituirà nel lavoro? Ecco, OpenAI ci ha appena mandato un altro segnale con la Codex App.

Sì, avete letto bene: un’app che scrive codice per te. Ma prima di farvi venire l’ansia da obsolescenza, diamo un’occhiata a cosa combina davvero questa nuova creatura dell’hype AI.

La Codex App è l’ultima evoluzione del modello Codex di OpenAI, quello che già alimenta GitHub Copilot. Promette di generare codice, debuggare, ottimizzare e persino suggerire soluzioni a problemi complessi. In pratica, è come avere un collega virtuale che non si lamenta mai… almeno finché non si pianta.

Per noi che passiamo le notti a smanettare con Arduino o a debuggare un script Python, la domanda è: quanto è davvero utile questo tool?

Da una parte, è figo ammetterlo. Scrivere “crea un algoritmo per ordinare una lista di numeri” e vedere il codice che appare come per magia ha un certo fascino. Per i principianti, potrebbe essere un ottimo modo per imparare sintassi e strutture di base. Ma attenzione: l’AI non sostituisce la comprensione profonda del coding, e se non sai cosa stai facendo, rischi di diventare uno di quei “copy-paste programmers” che girano su Stack Overflow.

Poi c’è la questione del vendor lock-in. OpenAI non è proprio famosa per la trasparenza, e usare la Codex App significa affidarsi a un servizio chiuso. Niente open-source, niente possibilità di modificare il modello. Se vi piace avere il controllo totale sui vostri strumenti, questa potrebbe essere una ragione per tenersi alla larga.

E che dire della privacy? Se siete abituati a scrivere codice su progetti sensibili o prototipi segreti, caricare tutto su un servizio cloud gestito da OpenAI potrebbe non essere la scelta più intelligente.

In conclusione, la Codex App è un altro tassello nel puzzle dell’AI che invade il nostro mondo. Utile? Sì, in certi casi. Rivoluzionaria? Non ancora. Sostituirà il nostro lavoro? Solo se glielo permettiamo.

E voi, la provereste o restate fedeli al buon vecchio vim e al vostro cervello?

Source: The Codex App

Sapete quella sensazione quando apri un sito web e ti accorgi che sotto il cofano c’è ancora jQuery? Ecco, i suoi creatori evidentemente non vogliono che questa sensazione svanisca mai.

Con grande stupore (e un pizzico di sarcasmo), il team di jQuery ha annunciato la versione 4.0.0, un aggiornamento che promette di “rivoluzionare” il mondo del JavaScript. Ma dopo anni di oblio, è davvero il caso di festeggiare?

Per chi vive nelle grotte (o chi semplicemente ha smesso di usare jQuery nel 2015), ricapitoliamo: jQuery è quella libreria che ha reso il DOM gestibile in un’epoca in cui ogni browser aveva il suo modo di fare le cose. Oggi, con ES6 e moderni framework, sembra quasi un fossile. Eppure, eccolo qui, più vivo che mai.

La versione 4.0.0 introduce alcune novità interessanti: miglioramenti nelle performance, un sistema di plugin più flessibile e supporto ufficiale per i moderni browser. Ma la domanda che tutti gli smanettoni si pongono è: “Perché?”

Da un lato, è ammirevole che un progetto così datato continui a evolversi. Dall’altro, sembra quasi un atto di disperazione. In un mondo dominato da React, Vue e Angular, jQuery 4.0.0 è come vedere un Walkman in un negozio di cuffie wireless: tecnicamente funzionale, ma un po’ fuori luogo.

Per noi che amiamo smanettare, la notizia ha un significato pratico: se state ancora usando jQuery, forse è il momento di aggiornarsi. Se invece siete tra quelli che hanno abbandonato la nave, questa notizia vi farà solo sorridere. In entrambi i casi, una cosa è certa: jQuery non ha ancora detto la sua ultima parola.

E voi, userete jQuery 4.0.0? O preferite lasciarlo al passato come un vecchio disco rigido IDE?

Source: jQuery 4

Avete notato che le risposte su StackOverflow sono diventate più lente ad arrivare? O che a volte, semplicemente, non arrivano proprio? Non siete soli. Un grafico recente (link in fondo, se siete coraggiosi abbastanza da disabilitare l’ad-blocker) mostra un calo significativo nel numero di domande mensili su StackOverflow. E no, non è colpa del nuovo anno, la tendenza è in atto da un po’.

Cosa sta succedendo? Beh, ci sono diverse teorie. La più ovvia è l’ascesa di ChatGPT e altri modelli di linguaggio. Perché chiedere a un umano quando puoi ottenere una risposta (spesso) decente da una macchina in pochi secondi? Certo, la risposta di ChatGPT potrebbe essere completamente sbagliata, ma hey, chi controlla più?

Scherzi a parte, questo è un cambiamento importante. StackOverflow è stato per anni la nostra bibbia, il luogo dove trovare soluzioni a problemi che ci facevano impazzire a tarda notte. Adesso, sembra che la community stia diventando meno attiva, e le risposte più superficiali o generate automaticamente. E questo, amici miei, è un problema.

Perché? Perché StackOverflow non era solo un database di soluzioni. Era un luogo di apprendimento, di condivisione, di confronto tra appassionati. Era il posto dove potevi chiedere aiuto e ricevere una spiegazione dettagliata da qualcuno che aveva già affrontato il tuo stesso problema. Un bot non può darti questo.

Cosa significa per noi che amiamo smanettare con Arduino, Raspberry Pi e tutto il resto? Significa che dobbiamo diventare ancora più autonomi. Dobbiamo imparare a debuggare da soli, a cercare soluzioni alternative, a costruire una community ancora più forte e collaborativa. Dobbiamo tornare alle origini, al vero spirito hacker: “Do it yourself” (e magari documenta tutto su GitHub).

E poi, diciamocelo, StackOverflow negli ultimi anni ha fatto scelte discutibili. Troppa pubblicità, troppi contenuti sponsorizzati, un’interfaccia utente che sembra uscita dagli anni ’90. Sembrava più un business che una community. Forse questo calo è anche una conseguenza di queste scelte. Un po’ di sano darwinismo tecnologico non fa mai male.

Quindi, StackOverflow sta morendo? Forse no. Ma sta sicuramente cambiando. E noi, come maker e hacker, dobbiamo adattarci e trovare nuovi modi per condividere la nostra conoscenza e supportarci a vicenda. E magari, chissà, costruire la nostra versione di StackOverflow, gestita dalla community e senza interessi commerciali. Un sogno? Forse. Ma sognare è gratis (e a volte anche divertente).

[Link al grafico: https://data.stackexchange.com/stackoverflow/query/1926661#graph]

Source: Total monthly number of StackOverflow questions over time

WTF?! Ho appena letto un articolo che essenzialmente dice “Python, vattene”. Seriamente. Non è un rant di qualche tizio arrabbiato perché il suo script impiega un’eternità ad avviarsi (anche se, ammettiamolo, capita), ma un’analisi abbastanza articolata del perché, nel 2025, Python sta iniziando a mostrare la sua età.

La notizia, presa da Hacker News, sottolinea come la performance di Python sia diventata un collo di bottiglia in molti scenari. Certo, è fantastico per lo scripting veloce e il prototyping, ma quando si tratta di applicazioni che richiedono potenza di calcolo, beh… lascia che vi dica, non è proprio un fulmine di guerra. E non parliamo della GIL (Global Interpreter Lock), quella bestia che impedisce al codice Python di sfruttare appieno i core multipli del nostro amato hardware.

Ma non è solo questione di velocità. La complessità di Python è aumentata a dismisura negli anni, con un ecosistema di librerie che a volte sembra più un labirinto che uno strumento utile. E poi, la dipendenza da librerie esterne introduce sempre il rischio del vendor lock-in: un aggiornamento sbagliato e il tuo progetto va in crash. Bello, no?

Cosa significa per noi che amiamo sporcarci le mani con Arduino, Raspberry Pi e progetti folli? Beh, significa che forse è il momento di guardare oltre. Go, ad esempio, sta guadagnando terreno grazie alla sua velocità, concorrenza nativa e semplicità. Rust, con la sua attenzione alla sicurezza e alle performance, è un’altra alternativa interessante, anche se la curva di apprendimento è un po’ più ripida. Non dico che dobbiamo abbandonare Python da un giorno all’altro (sarebbe un suicidio per molti progetti esistenti), ma iniziare a sperimentare con alternative non fa mai male.

Personalmente, trovo che Python sia stato un ottimo punto di partenza per imparare a programmare. Ma come diceva il mio vecchio prof: “Il primo linguaggio lo impari per capire *come* programmare, il secondo per capire *come* programmare *bene*.”

Quindi, Python, grazie per i bei momenti. Ma forse è ora di lasciare spazio a qualcosa di più… efficiente. E per favore, smettetela con l’hype e concentratevi sulla performance reale. Seriamente.

Ah, e controllate sempre i vostri script per i punti e virgola mancanti. Non si sa mai…

Source: Go away Python