Il passaggio da un ambiente LAMP a un laboratorio con macchine virtuali e modelli linguistici cambia gli strumenti, ma conserva una domanda: riesco a capire perché il sistema funziona e a ricostruirlo quando smette di farlo?
Nel mio percorso, dallo sviluppo ai ruoli di CTO e poi a Romiltec, fondata nel 2023, il laboratorio è diventato un posto dove verificare le decisioni prima di trasformarle in impegni verso un cliente. Il suo valore dipende da ciò che riesco a imparare e documentare, più che dalla quantità di hardware acceso.
La base: seguire il percorso di una richiesta
LAMP mette insieme Linux, Apache, MySQL e PHP. È un ambiente utile per imparare a seguire una richiesta: risoluzione del nome, connessione, web server, esecuzione del programma, accesso al database e risposta. Un errore in uno di questi passaggi può sembrare, dal browser, semplicemente un sito che non si apre.
La mia formazione in ingegneria a Catania, conclusa nel 2010, comprendeva anche una tesi in ambito robotico con wxPython e XML-RPC. Il collegamento che mi interessa oggi è il lavoro sui confini tra componenti: un’interfaccia può inviare il comando giusto e ricevere comunque una risposta che deve saper interpretare.
Questa abitudine torna nello sviluppo web. Prima di cambiare framework o aumentare le risorse, cerco il passaggio che non rispetta il comportamento atteso. Una traccia riproducibile aiuta più di una spiegazione elegante ma non verificata.
Con la virtualizzazione entra in gioco il ciclo di vita
Creare ambienti separati rende più facile provare configurazioni e versioni. Introduce però un secondo livello di responsabilità: oltre all’applicazione devo conoscere rete, storage, backup e dipendenze del sistema che la ospita.
Uso Proxmox anche per questo tipo di lavoro. La documentazione ufficiale è il riferimento per le funzioni disponibili nella versione installata; il mio runbook deve invece spiegare le scelte specifiche dell’ambiente. Sono documenti complementari.
Un esperimento diventa utile quando ne restano prerequisiti, passaggi e risultato. Se una seconda persona deve indovinare quale disco ho usato o quale variabile mancava, la configurazione non è ancora trasferibile. Anche uno snapshot, utile per tornare indietro in alcune condizioni, non sostituisce una copia recuperabile dopo la perdita dello storage.
Con gli LLM la demo non basta più
Un modello locale può produrre una risposta plausibile pur sbagliando il compito. Perciò devo verificare sia il servizio sia il contenuto: memoria disponibile, tempi di risposta e stabilità da una parte; correttezza, rispetto dei requisiti e uso degli strumenti dall’altra.
Nel confronto tra modelli locali riporto una prova CPU documentata e ne delimito il significato. Il benchmark del runtime misura prestazioni in condizioni definite: non certifica che un refactor sia corretto.
Questo cambia anche il modo di prendere appunti. Registro la revisione dei pesi, la quantizzazione, il comando e il carico. “Girava bene sul mio computer” non permette di valutare se una configurazione sia adatta a un altro progetto.
Un laboratorio deve avere un confine
Non trasferisco automaticamente un esperimento in produzione perché ha superato una serata di prove. Prima servono un responsabile, aggiornamenti gestibili, ripristino provato e una risposta agli errori prevedibili. Il costo comprende anche il tempo necessario a mantenere queste condizioni.
Allo stesso modo, non considero l’homelab un requisito per essere un buon sviluppatore. Si può imparare su ambienti di lavoro, macchine temporanee e progetti condivisi. Mi interessa che una persona sappia formulare un’ipotesi, cercare prove e spiegare i limiti del risultato.
Per scegliere da dove partire ho raccolto i criteri pratici per un homelab. Il primo acquisto può aspettare finché non è chiaro quale esperimento deve rendere possibile.