C’è qualcosa di profondamente poetico, quasi tragico, nel vedere il repository di tutto il pianeta che decide di prendersi una pausa improvvisa proprio quando il mondo ha più bisogno di push e pull.

Se avete lavorato su qualche progetto importante o se semplicemente la vostra pipeline di CI/CD è configurata per dare i nervi rotanti, sapete esattamente di cosa parlo. Il 17 agosto scorso, GitHub ha deciso di andare in modalità ‘offline’, lasciando migliaia di sviluppatori a fissare lo schermo con l’espressione di chi ha appena scoperto che il server di produzione è stato cancellato da uno script Python scritto in preda alla stanchezza.

Il team di GitHub ha rilasciato un aggiornamento ufficiale per spiegare il perché di questo blackout e, come da tradizione, il tono è quello tipico di chi cerca di rassicurare senza però promettere miracoli. In sostanza, si parla di problemi di affidabilità che hanno colpito i servizi core. Per noi che mastichiamo codice tutto il giorno, il termine «reliability issues» suona un po’ come dire che la tua vecchia Panda ha avuto un problema con il carburatore: non è che sia esplosa, è solo che non ti porta più a destinazione quando ne hai bisogno.

La cosa interessante, e qui serve un po’ di analisi critica, è come queste infrastrutture centralizzate siano diventate il singolo punto di fallimento (Single Point of Failure) di tutta l’industria. Siamo tutti lì, comodamente seduti, a delegare la nostra intera esistenza digitale a un unico grande fornitore. È un po’ come vivere in una città dove l’unico supermercato apre solo quando decide lui: comodo finché tutto funziona, un incubo quando scatta il glitch.

Certo, l’aggiornamento promette passi concreti per migliorare la stabilità e la trasparenza, e onestamente, se i fix funzionano, va bene così. Non siamo qui per fare i puristi dell’autosufficienza estrema (anche se un buon server locale o un mirror non si nega mai), ma pretendiamo che lo strumento che usiamo ogni giorno non decida di andare in vacanza senza preavviso.

In conclusione: GitHub sta cercando di rimediare, e noi, come sempre, continueremo a fare commit sperando che la prossima volta l’unico crash che vedremo sia quello del nostro codice spazzatura e non dell’infrastruttura globale. Nel frattempo, teniamoci pronti un piano B, perché l’unica costante nel software è che l’imprevisto è solo un bug che non abbiamo ancora patchato.

Source: The August 17 outage

Avete presente quella sensazione di quando un tool che amate inizia a espandere le proprie frontiere in modo un po’ troppo aggressivo, quasi come un supervillano della Marvel che sta cercando di conquistare l’intero universo Marvel? Ecco, Cursor ha appena fatto un passo decisamente audace.

Non si limita più a scriverci il codice (che tra l’altro lo fa bene, non possiamo negarlo), ma ora vuole ospitare anche il nostro codice. Sì, avete letto bene. È nato Origin, il nuovo servizio di code hosting di Cursor, e l’obiettivo è chiaro: trasformare l’editor in una piattaforma all-in-one che può potenzialmente rendere superfluo GitHub.

Il lancio è in fase beta per chi ha già un piano a pagamento e, per ora, si concentra sulle basi: repository, pull request, browsing del codice e una sincronizzazione con GitHub che promette di non farci impazzire. La cosa interessante è l’approccio «agent-native». L’idea è che il codice non sia solo un insieme di file statici da guardare, ma un ambiente vivo dove gli agenti IA di Cursor possono navigare, rispondere a domande, fare modifiche e persino gestire le PR. Immaginate un team di developer dove l’IA non è solo un plugin che suggerisce la riga successiva, ma un membro del team che ha accesso diretto al repo e ai processi di CI/CD.

C’è anche una parte di integrazione che fa sorridere i maker: puoi collegare Vercel, Depot o Buildkite. Se fai un merge su Origin, la pipeline parte e il deployment avviene quasi in automatico. Un ecosistema che sembra progettato per creare una bolla di produttività talmente perfetta da farti dimenticare dove avevi lasciato i dati originali.

Naturalmente, come ogni maker che si rispetti, non posso fare a meno di notare come questo nuovo ecosistema stia tessendo una rete sempre più fitta e difficile da abbandonare. Se metti il codice su Origin, usi i loro agenti e colleghi i tuoi servizi di deployment preferiti su Cursor, quanto è difficile un domani decidere di spostare tutto altrove? È un ecosistema che ti avvolge con la morbidezza di un mantello di supereroe, ma che ti rende anche molto, molto dipendente dalla loro infrastruttura.

Per noi che amiamo la libertà dell’open source e la modularità, è una notizia che va analizzata con un occhio critico. Da un lato, è una figata pazzesca vedere l’IA che interagisce nativamente con i processi di sviluppo; dall’altro, vedere i grandi player cercare di creare dei giardini recintati sempre più impenetrabili fa un po’ riflettere.

In sintesi: se siete utenti paganti di Cursor, andate a testarlo. È tecnologia d’avanguardia, è potente e promette di velocizzare il lavoro in modo impressionante. Ma tenetevi sempre una copia del codice altrove, giusto per quando il supervillaggio deciderà di cambiare le regole del gioco.

Source: Cursor launches Origin, GitHub alternative

Un tempo, quando si parlava di Single Point of Failure, pensavamo ai server di una banca o a una centrale elettrica, non al posto dove teniamo tutto il nostro codice sorgente.

Se avete seguito le ultime discussioni su Hacker News, avrete capito che l’aria si sta facendo pesante. GitHub, il gigante che dovrebbe essere la roccia su cui poggia l’intero ecosistema dev, sta mostrando segni di cedimento che non sono più giustificabili con un semplice «stiamo lavorando al problema». Negli ultimi mesi, i blackout e le instabilità sono diventati la norma, trasformando ogni ‘push’ in una sorta di sessione di roulette russa.

La domanda che sta facendo saltare sulla sedia migliaia di developer non è solo «perché succede?», ma soprattutto «quando è il momento di scappare?». Il dibattito è acceso: ha senso migrare tutto su GitLab, Codeberg o magari gestire un proprio server con un’istanza self-hosted di Gitea?

Certo, parliamoci chiaro: per noi che mastichiamo Linux e adoriamo l’open source, l’idea di avere il controllo totale sui propri repository è il sogno proibito. Non c’è niente di più frustrante che trovarsi con i ferri combinati quando hai una deadline e il tuo repository principale decide di andare in modalità ‘vacanza’. Tuttavia, c’è un elefante nella stanza: la comodità. Migrare non significa solo spostare file, significa riconfigurare CI/CD, gestire webhook, spostare i permessi e, in breve, rimettere in piedi un’infrastruttura che avevamo dimenticato che esistesse.

E poi, restiamo in Italia: qui siamo abituati a gestire sistemi che sembrano reggere in piedi solo grazie alla forza di volontà e a qualche script legacy scritto nel 2005. Se siamo capaci di far funzionare software critico con risorse minime, l’idea di gestire un’alternativa distribuita o decentralizzata non dovrebbe spaventarci.

Non stiamo parlando di una rivoluzione politica o di nuove leggi europee che limitano la privacy (anche se il controllo dei dati è sempre un tema caldo), ma di pura sopravvivenza tecnica. Se il servizio che dovrebbe essere la tua ‘fonte di verità’ è inaffidabile, la tua fiducia è andata.

Quindi, alla community chiedo: siete pronti a sporcarvi le mani con una migrazione massiva o preferite continuare a pregare davanti al monitor sperando che il server di Microsoft faccia il suo dovere? Io, onestamente, sto già preparando un backup su un server locale. Meglio un po’ di fatica in più oggi che un crash totale domani.

Source: Ask HN: Alternatives to GitHub

Speriamo che nessuno di voi avesse in programma un merge critico o un deploy d’emergenza proprio in queste ore, perché il destino — o forse un bug nel sistema di routing — ha deciso diversamente.

Se siete stati cercando di pushare codice, scaricare un repository o semplicemente capire perché la vostra dashboard sembra un sito web degli anni ’90 che non carica le immagini, non siete soli. GitHub ha deciso di alzare bandiera bianca con un incidente che sta facendo saltare i nervi a metà della comunità dev globale.

Il report ufficiale ci dice che stiamo assistendo a un tasso di errore del 20% sulle esperienze web e sulle API. Ma il vero dramma è per chi ha bisogno di recuperare i dati: i download di archivi e contenuti raw stanno toccando picchi del 50% di errore. Praticamente, metà delle volte che clicchi, il server ti risponde con un silenzio tombale o un errore criptico. E se pensavate che il problema fosse solo visivo, preparate il caffè: l’autenticazione SAML e OIDC è andata in vacca. Se la vostra azienda usa l’integrazione Single Sign-On per gestire i team, preparatevi a un pomeriggio passato a fissare lo schermo aspettando che il login funzioni.

Per chi non mastica il gergo enterprise, parliamo di un malfunzionamento che colpisce proprio i pilastri della gestione identità e sincronizzazione dei team. È quel classico scenario in cui tutto il muchachia tecnologico che abbiamo costruito attorno a un unico grande provider decide di collassare in modo coordinato.

Non è una notizia che riguarda solo la Silicon Valley; qui in Italia, dove spesso lavoriamo su progetti critici con workflow che dipendono totalmente da questi servizi, un downtime del genere significa ore di produttività bruciate e deadline che iniziano a ballare pericolosamente.

Al momento le indagini sono in corso. Non sappiamo ancora se sia un problema di infrastruttura, un aggiornamento andato male o se qualcuno abbia accidentalmente premuto il tasto ‘delete’ sul database centrale. L’unica cosa certa è che, finché non tornano i parametri normali, la nostra unica opzione è aspettare, sperando che il loro team DevOps sia più sveglio del nostro in questo momento. Nel frattempo, se avete un clone locale aggiornato, pregate che sia l’unica cosa che funziona ancora.

Source: Incident with Github.com

C’è un momento preciso in cui ti rendi conto che non sei tu a gestire la tua infrastruttura, ma è l’infrastruttura che gestisce te. È quel secondo di puro shock quando apri il sorgente del tuo sito — magari un bel progetto minimalista, ultra-leggero, senza una riga di JavaScript per non disturbare nessuno — e trovi magicamente del codice che non hai mai scritto tu.

Recentemente, un utente su Hacker News ha scoperto che Cloudflare, nel momento esatto in cui ha spostato i suoi nameserver verso il loro servizio (probabilmente per sfruttare le comodità degli R2 bucket), ha deciso di fare il bullo. Senza chiedere il permesso, senza un popup di ‘accetto i termini’, ha iniettato silenziosamente uno snippet di analytics nel suo HTML. Il tutto in un sito che, per inciso, era nato proprio per essere privo di script e super pulito.

La cosa surreale? Per rimuovere questo ‘regalino’, l’utente non doveva semplicemente disattivare un flag, ma doveva prima aggiungere il sito alla dashboard di Analytics e *solo dopo* procedere alla disattivazione. Un loop degno di una missione impossibile di Mission Impossible, ma con molta meno classe e molta più cattiveria.

Non stiamo parlando di una questione che scuote le fondamenta del GDPR europeo o che cambierà la vita dei sysadmin in Italia — le leggi sulla privacy qui da noi sono già un labirinto sufficiente di per sé — ma il principio è quello che fa venire il mal di testa a chiunque abbia un briciolo di rispetto per l’integrità del proprio stack. Il concetto di ‘opt-out’ invece di ‘opt-in’ è la firma digitale di chi vuole espandere il proprio ecosistema di dati a ogni costo, ignorando la volontà di chi sta solo cercando di far girare un servizio senza troppi fronzoli.

È la classica deriva da ‘Platform as a Service’ che si trasforma in ‘Platform as a Spyware’. È comodo, certo. È scalabile, indubbiamente. Ma quando la comodità del cloud inizia a riscrivere il tuo codice sorgente a tua insaputa, il confine tra ‘servizio essenziale’ e ‘ospite molesto’ diventa pericolosamente sottile. Se state configurando i vostri DNS, un consiglio: fate un controllo al sorgente. Non lasciate che il vostro sito inizi a parlare lingue che non avete insegnato voi.

Source: Tell HN: Cloudflare silently injects its analytics when you switch nameservers

Avete presente quella sensazione di euforia che provate quando trovate un nuovo tool su GitHub, con una star rating che sale come un razzo e una documentazione che promette di risolvere tutti i vostri problemi esistenziali? Ecco, dimenticatela. Quella non è innovazione, è solo un biglietto di sola andata per un incubo di debugging alle tre di notte.

Recentemente è riemerso un pensiero che, sebbene non sia una news dell’ultima ora, è più attuale che mai in un’era di hype incontrollato: l’arte di scegliere la tecnologia noiosa. Sì, avete letto bene. La vera maestria non sta nel configurare l’ultimo cluster Kubernetes super-stratificato con tre database NoSQL sperimentali, ma nel saper usare ciò che già funziona, ciò che è solido, ciò che è, appunto, noioso.

L’idea è semplice, quasi zen: ogni azienda ha un budget limitato di «token di innovazione». Immaginateli come i punti esperienza di un RPG. Se spendete il vostro unico token per implementare un sistema di service discovery che è uscito dal forno ieri, vi siete appena tolti la possibilità di innovare dove conta davvero, ovvero sul prodotto. Se volete rivoluzionare il modo in cui la gente paga online, perché dovreste sprecare energie a reinventare il protocollo SSH o a scrivere un database custom? È una follia.

Scegliere la tecnologia «noiosa» non significa scegliere quella mediocre o scadente. Non sto parlando di usare software legacy che non riceve patch dal 1998. Parlo di strumenti come Postgres, Python, PHP o Memcached. Sono tecnologie che hanno già affrontato il test del fuoco. Conoscono i loro punti di forza, ma soprattutto conosciamo i loro modi di fallire. Quando un database tradizionale va in crash, sappiamo dove guardare. Quando il nuovo database ‘disruptive’ basato su un algoritmo di cui nessuno ha mai sentito parlare decide di andare in allucinazione durante un picco di traffico, siete fritti. Avete degli «unknown unknowns», ovvero problemi che non avevate nemmeno considerato perché non sapevate che potessero esistere.

Il vero obiettivo di un ingegnere senior non è accumulare un catalogo di linguaggi diversi nel proprio CV, ma risolvere problemi di business. Il ‘bagaglio’ che portiamo con noi — monitoraggio, test, deployment, manutenzione — aumenta esponenzialmente ogni volta che introduciamo un pezzo nuovo nello stack. Se ogni sviluppatore nel team decidesse di usare il proprio framework preferito, finiremmo in un caos polyglot che richiederebbe un esercito di DevOps solo per tenere in piedi le infrastrutture.

Quindi, la prossima volta che un collega vi propone di migrare tutto su una tecnologia ‘rivoluzionaria’ solo perché l’ha vista in un webinar, provate a chiedervi: «Possiamo risolvere il problema con quello che abbiamo già?». Se la risposta è sì, restate sul sicuro. Lasciate che l’hype bruci se stesso e concentratevi sulla cosa più importante: spedire codice che funzioni e che non esploda alla prima pressione di un tasto.

Source: Choose Boring Technology (2015)

Vi è mai capitato di tornare dalle vacanze e scoprire che il vostro repository sembra il set di un film post-apocalittico? Non parlo di qualche piccolo merge confusionario, ma di quella situazione in cui qualcuno ha deciso, senza consultare nessuno, che Kafka era assolutamente necessario per gestire una coda di tre messaggi e ha aggiunto altre cinquanta tabelle al database solo perché «era più facile così».

Fino a poco tempo fa, c’era un limite fisico alla velocità con cui un team poteva fare danni. C’era la fatica di scrivere il codice, la noia della documentazione, il tempo necessario per rifletterli. C’era una sorta di ‘freno a mano’ naturale che proteggeva la qualità del software. Ma nel 2026, quel freno è saltato. Con gli agenti AI e i nuovi strumenti di automazione, la velocità di implementazione è decollata, ma insieme a lei è esploso il debito tecnico.

Il problema non è l’AI in sé – anzi, quando usata per automizzare task ripetitivi è una manna dal cielo. Il punto è che oggi chiunque può generare una Pull Request da venticinquemila righe di codice in un pomeriggio. Sembra una figata, vero? Un trionfo della produttività! Peccato che, se non hai la capacità critica di capire cosa sta facendo l’agente, ti ritrovi con un sistema così intricato e stratificato che nessuno nel team sa più come fluiscano i dati.

È un po’ come comprare una supercar a rate: vedi la carrozzeria lucida, ma non ti accorgi che sotto il cofano c’è un debito che ti sta mangiando vivo. Se ti chiedi «da dove arriva questo dato?» e la risposta del tuo collega è un link a una chat di Claude che spiega una decisione architetturale presa dopo venti round di correzioni, allora siamo nei guai.

Stiamo assistendo a una polarizzazione brutale del mercato. Da una parte ci sono i ‘vibe coder’, quelli che spingono tasti sperando che l’output sembri funzionante. Questi, purtroppo, stanno diventando una voce di costo insostenibile per qualsiasi azienda seria. Dall’altra, ci sono gli ingegneri che sanno interpretare, validare e governare l’AI.

Il valore non sta più nel tradurre una specifica in codice – quello lo fa la macchina. Il vero valore è nel giudizio, nella capacità di dire «no», nel saper mantenere la semplicità e nel capire le implicazioni a lungo termine di una scelta. In un mondo dove scrivere codice è diventato commodity, saper decidere *cosa* scrivere è l’unica vera skill che conta. Se pensate che basti saper scrivere un buon prompt per sopravvivere, preparatevi: la selezione naturale del software sta per iniziare.

Source: AI is removing the middle class of software engineering

Immaginate di svegliarvi una mattina e scoprire che il vostro intero ecosistema aziendale non è più solo un insieme di server, database e script sparsi qua e là, ma un unico, grande, coerente organismo digitale. Sembra la trama di un episodio di Black Mirror, vero? Eppure, Cloudflare ha deciso di lanciare la sua bomba: Cloudflare OS.

Per chi non mastica il marketing delle Big Tech, non si tratta di un vero e proprio sistema operativo da installare su un vecchio ThinkPad che trovi in soffitta. No, è una piattaforma open-source pensata per far girare agenti, app e automazioni, con l’idea di creare uno strato che ‘conosce’ come funziona la tua azienda e gestisce l’accesso ai sistemi interni in modo sicuro.

L’idea di base è piuttosto potente: invece di avere mille microservizi che non si parlano e VPN che sembrano reliquie dell’era analogica, avresti una piattaforma che orchestra tutto. La parte figa? È open-source. Questo significa che, almeno sulla carta, possiamo sbirciare sotto il cofano, capire come gestiscono la logica e, soprattutto, non siamo solo spettatori passivi di una scatola nera proprietaria.

Certo, c’è un piccolo ‘ma’ che non possiamo ignorare. Sebbene il codice sia aperto, l’infrastruttura che fa girare tutto questo è, beh, Cloudflare. È quel classico dilemma del mondo moderno: ti do gli strumenti per costruire il tuo castello, ma le fondamenta, le mura e la guardia alla porta sono tutte gestite da me. Se decidi di costruire tutto il tuo workflow aziendale su questo framework, potresti ritrovarti con le mani legate se un giorno decidessi di cambiare fornitore. È un po’ come il supereroe che ha poteri incredibili, ma solo finché resta all’interno della città protetta dal suo stesso muro.

In Italia, poi, siamo abituati a gestire infrastrutture un po’ più… diciamo, ‘artigianali’. Spesso ci troviamo a combattere con configurazioni legacy che sembrano sopravvissute alla caduta dell’Impero Romano. Un approccio del genere potrebbe essere una manna dal cielo per standardizzare i processi, a patto di non trovarsi a dover pagare un abbonamento astronomico per ogni singolo automazione che decidiamo di far girare.

In sintesi: Cloudflare OS è un progetto da tenere d’occhio con estremo interesse. Se riusciranno a mantenere la promessa di un ecosistema realmente flessibile e non solo un’estensione del loro controllo sul traffico web, potrebbe essere una svolta per il modo in cui concepiamo il lavoro digitale. Se invece diventerà solo un modo più elegante per renderci dipendenti dal loro stack, beh… avremo visto abbastanza film di fantascienza per capire come va a finire.

Source: Cloudflare OS: an open platform for agents, apps, and work

Chi non ha mai desiderato un tasto ‘Undo’ per la propria intera vita professionale? Probabilmente tutti noi, mentre cerchiamo disperatamente di capire perché quel container in produzione stia consumando RAM come se fosse un supercomputer della NASA.

Recentemente su Hacker News è spuntato un progetto che promette di risolvere il caos del lavoro moderno: Superlogical. Il loro obiettivo? Costruire un ‘multiplexer per tutto’. In pratica, vogliono prendere i flussi di lavoro interattivi, quelli automatizzati e quelli di produzione e sbatte tutto dentro un unico sistema composibile, sicuro e operativo. Un’idea che suona decisamente ambiziosa, quasi quanto cercare di spiegare a un cliente perché il ‘piccolo cambiamento’ richiesto richiede tre giorni di refactoring.

Il punto di partenza è un terminal multiplexer. Se usate tmux o screen, sapete di cosa parlo: sessioni persistenti che vi permettono di staccarvi dal server, chiudere il laptop e riprendere esattamente da dove avevate lasciato. La novità qui è che Superlogical vuole modernizzare il tutto, portando l’accesso via web e app native per macOS e iOS, con una funzione di ‘sharing’ integrata per collaborare in tempo reale sulla stessa sessione. Sembra la fine del mal di testa con lo scrollback che non funziona o con le selezioni di testo che sembrano un gioco di prestigio fallito.

Detto questo, manteniamo un po’ di sano scetticismo da maker. L’idea di un sistema che unifica tutto è affascinante, ma c’è sempre quel rischio latente: l’idea di creare un ecosistema dove tutto dipende da un unico, enorme e centralizzato orchestratore. Se tutto passa per lo stesso ‘multiplexer’, cosa succede quando quel componente decide di avere un momento di crisi? E poi, l’integrazione nativa con ecosistemi chiusi come quello Apple potrebbe rendere la cosa meno ‘libera’ di quanto sembri.

Per noi che viviamo di terminale, script e automazioni, l’idea di avere strumenti che parlano la stessa lingua è fantastica. Se riusciranno a risolvere i classici ‘papercuts’ (quei piccoli fastidi che ti fanno saltare i nervi ogni giorno) senza trasformare il tutto in un monolite proprietario e pesante, allora potremmo trovarci davanti a qualcosa di veramente rivoluzionario. Per ora, restiamo in attesa di vedere se questa visione diventerà realtà o se resterà un bellissimo manifesto scritto tra una tazza di caffè e una riga di codice.

In bocca al lupo, Superlogical. Ma non aspettatevi che vi regali subito il mio file .zshrc.

Source: Superlogical

C’è un motivo per cui i migliori script Python vengono lanciati alle tre del mattino, mentre noi cerchiamo disperatamente di capire perché quel modulo non si importa della nostra sandbox.

Se siete come me, avete passato ore a configurare task scheduler, cron job su server Linux dimenticati o script che si interrompono perché qualcuno ha resettato la sessione SSH. La buona notizia? Sembra che Kimi abbia deciso di risolvere questo dramma con il lancio di «Kimi Work». Non è la solita supercazzola di marketing per vendere abbonamenti cloud, ma un tentativo di integrare un motore Cron robusto direttamente nel workflow degli LLM Agent.

In parole povere: l’idea è quella di far girare tutto in background, 24/7. Immaginate di impostare un agente che, ogni mattina alle 07:00, si sveglia, mastica i dati del vostro database, analizza i log e vi prepara un briefing pronto per la colazione. Oppure, se siete dei veri maker che amano processare dataset massicci, potete lanciare script Python che si auto-eseguono a mezzanotte senza che dobbiate restare svegli a fissare una barra di caricamento.

Il concetto di «Set It & Forget It» è affascinante, ma sappiamo tutti che nel mondo tech il «forget it» spesso si traduce in un alert critico che ti sveglia durante una serata di gaming. Però, l’integrazione di un motore Cron all’interno di un ecosistema di agenti è una mossa intelligente. Automatizzare non significa solo far girare un comando, ma dare una logica temporale a entità che possono effettivamente «ragionare» sui task.

Naturalmente, c’è sempre il solito tema: tutto questo avviene dentro il loro ecosistema. E noi sappiamo bene che quando i processi diventano troppo integrati e automatizzati, uscire da quel perimetro diventa un’impresa degna di un film di spionaggio della Guerra Fredda. Se il vostro workflow diventa dipendente da un motore interno, la libertà di migrare tutto su un server self-hosted in garage diventa un po’ più complicata.

Detto questo, l’idea di avere un orchestratore che non richiede che io stia lì a fare da babysitter ai miei script è decisamente allettante. Se riusciranno a rendere la gestione dei task fluida e non troppo ancorata ai loro standard proprietari, potrebbe essere lo strumento definitivo per chi vuole automatizzare la parte noiosa del lavoro per concentrarsi su quella divertente: rompere le cose e cercare di ripararle.

Source: Kimi Work