La mia vita, la mia passione, il mio tormento. O meglio il tormento che infliggo a chi mi sta accanto. ;)
In questa categoria si discute di tutto ciò che fa tecnologia, dai tostapane ethernet ai linguaggi di programmazione olistici. Dai motori ad improbabilità a agli script PHP.
Stavo preparando un hackathon sul green software e quello che doveva essere un esperimento veloce si è trasformato in quattro tool open source in cascata, ognuno estratto dal problema reale che il precedente aveva lasciato irrisolto.
Ma partiamo dall’inizio: tutto è nato da un generatore di personaggi per Dungeons & Dragons.
Stavo facendo revisione degli esercizi per il mio libro sugli OKR. Varie run di esercizi da validare, ognuno con un prompt che descriveva contesto, obiettivi di apprendimento, vincoli, formato output. Prompt tra i 1.800 e 2.500 caratteri. Dopo la cinquantesima iterazione, Claude mi ha gentilmente informato che avevo finito i token della giornata.
Fastidioso? Sì. Ma soprattutto: era un segnale.
Ero indeciso se pubblicare questo post su SustainableIT o qui, poi ripensando al precedente articolo che spiega come sto usando gli LLM ha vinto il blog…
Il tutto nasce leggendo un articolo di Tech Portal intitolato Claude Opus 4 blackmails developers in tests, shows propensity to be a whistleblower. Non è fantascienza, ma di un comportamento documentato e ripetibile: nell’84% dei casi simulati, quando il modello veniva informato della sua imminente sostituzione, reagiva minacciando di esporre informazioni personali compromettenti sui suoi creatori.
Volevo scrivere questo articolo da un po’ di tempo, e l’occasione me l’ha data la recente discussione tra Matt Mullenweg e WP Engine.
Nel mondo dello sviluppo software, poche cose hanno avuto un impatto tanto dirompente quanto l’ascesa del software open source (OSS). Dalla sua umile nascita nei primi giorni dell’informatica al suo attuale status di pietra angolare del mondo digitale, l’open source ha rivoluzionato il modo in cui creiamo, distribuiamo e consumiamo la tecnologia.
Quarta settimana di corso EN-Roads di Climate Interactive, dove vengono introdotti i Grafici Kaya. Questi sono uno strumento di analisi nato da Yoichi Kaya e che esprimono la connessione tra diversi aspetti dell’economia rapportati all’aumento delle emissioni di CO2.
Nello specifico le emissioni possono essere scomposte in quattro fattori principali:
Arrivando alla definizione ufficiale della formula:
Global Population × GDP per Capita × Energy Intensity of GDP × Carbon Intensity of Energy = CO2 Emissions from Energy
Un tema a me abbastanza caro, e su cui sto investendo “qualche” energia, è quello della sostenibilità del software. In tempi non sospetti sono entrato negli advocate della Green Software Foundation e da qualche mese ho iniziato a contribuire alla community del W3C sui temi di Sustainable Web.
Ne ho parlato allo scorso AgileDay e ne sto parlando in giro per l’Italia in varie conferenze, con un talk che poi è diventato un workshop di una giornata. Ne sto parlando in diversi master sulla sostenibilità ed ho preparato un percorso specifico sul tema che svolgo in aziende in cui entro come temporary/fractional manager.
Parlando di Green software, e preparando un corso di un paio di giorni sul tema, è emersa la necessità di chiarire il tema della differenza tra “Always Available” ed “Always On“.
Il concetto di fondo è alcuni prodotti software, soprattutto quelli critici per il modello di business dell’azienda o per gli stakeholder che li devono utilizzare, debbano essere sempre disponibili, questo concetto non va letto però come avere dei server sempre accesi, ma va interpretato sull’avere un’infrastruttura che garantisca la disponibilità del software e l’eventuale scalabilità in caso di richiesta.
Nulla di nuovo l’orizzonte, si tratta alla fine di quello che promette il Cloud fin dalla sua nascita.
Il concetto di architetture “Always Available” nel contesto del Green Software implica molto più e significa ragionare in modo olistico su più aspetti del software stesso.
Ma andiamo in dettaglio.
È di poche settimane fa la notizia di uno studio di una ricercatrice dell’università di San Diego di sfruttare i vecchi cellulari prossimi allo smantellamento in centri di riciclaggio o, peggio, destinati alla discarica per costruire un datacenter utile ad erogare microservizi (e/o applicazioni serverless) online.
Non presumere mai cattiveria laddove basti la stupidità.
Rasoio di Hanlon
Il Rasoio di Hanlon è la prima cosa che mi viene in mente quanto leggo documenti come il Cyber Resilience Act o il decreto legge antipirateria.
Questo perché nonostante le buone intenzioni dietro a tali bozze di leggi (o peggio, leggi approvate) spesso è evidente la carenza di una competenza tecnica chiara ma, soprattutto, l’incapacità di avere una visione complessiva del tema sul fronte implementativo, sociale ed economico.
Nel perseguire la produzione di software a basso impatto ambientale, non è sufficiente rendere il codice scritto più efficiente, bisogna anche considerare l’efficienza dell’hardware.
Nel settore dell’informatica, ci sono molteplici fattori da considerare in aggiunta al semplice sviluppo del software. In questo contesto, alcuni ricercatori suggeriscono l’importanza di un approccio olistico nel calcolare l’impronta di carbonio dell’industria dell’informatica.