Parte 13

Costruite una biblioteca personale: trasformate lavoro utile in mestiere trasferibile

A questo punto il terminale smette di essere un elenco di comandi. Diventa una raccolta di metodi di cui vi fidate: così analizzo questo problema, così trasformo questi file, così impacchetto il progetto, così verifico un versione pubblicata, così ricostruisco l’ambiente.

Conservate i metodi in una biblioteca, non nella memoria

Create cartelle per scopo — checks, deploy, media, migration, diagnostics — e tenete un breve script o nota per ogni routine provata. Il nome della cartella deve dire quando cercherete quello strumento tra sei mesi.

Una semplice cartella privata trasferita tra progetti è già un ambiente personale portabile. Conserva anni di piccole decisioni che altrimenti andrebbero riscoperte ogni volta.

cd lil-playground

md library

md library/checks

md library/deploy

md library/media

Preferite ricette piccole che possano comporsi

Una buona routine risponde a una domanda o esegue una trasformazione limitata. hosting-baseline.lil, package-project.lil e network-check.lil sono più facili da fidare di un enorme script che modifica config, carica file, cambia permessi e tocca un database tutto insieme.

La composizione rende visibile il rischio. Un file lineare #lil può chiamare comandi normali; un flusso run può richiamare flussi secondari quando servono decisioni. Mantenete chiari i nomi, i dati attesi in ingresso e i risultati prodotti.

Registrate la differenza, non solo il file finale

diff trasforma due stati di testo in un cambiamento revisionabile e può salvare una patch. Spesso è più informativo di una seconda copia chiamata final-final-2.txt, perché il cambiamento stesso diventa ispezionabile.

Abbinate hash agli artefatti di versione pubblicata. Una patch spiega che cosa è cambiato; un impronta dice più tardi se i byte sono ancora identici. Nessuno sostituisce un backup, ma insieme rendono handoff e verifica molto più tranquilli.

echo "status=review" > library/routine-v1.txt -r

echo "status=done" > library/routine-v2.txt -r

diff library/routine-v1.txt library/routine-v2.txt

diff library/routine-v1.txt library/routine-v2.txt -o library/routine.patch

Piccole utility esatte evitano codice usa e getta non necessario

rand genera interi sicuri, token e UUID; math esegue calcoli e conversioni validati. Sono utili quando un flusso di lavoro richiede un valore esatto e uno script PHP temporaneo aggiungerebbe più superficie che valore.

Un valore casuale crittograficamente sicuro non è comunque un sistema di gestione dei segreti e una calcolatrice non è un motore di regole applicative. Usate strumenti piccoli per compiti piccoli e mantenete esplicite le regole importanti nel flusso di lavoro.

rand -uuid

rand 1 100

math clamp 105 0 100

math round 82.456 1

Mantenete lo strumento prima che un’emergenza renda urgente la manutenzione

Ogni tanto eseguite core, doctor -q e upgrade -c quando l’ambiente è sano. Imparate così come appare la “normalità” e notate aggiornamento o dipendenze mancanti prima di un incidente in produzione.

La manutenzione è più facile quando è prevedibile. Usate consapevolmente il repository, revisionate le modifiche, conservate i backup e annotate le poche decisioni locali che rendono questo host diverso da un altro.

core

doctor -q

upgrade -c

Sapete resettare un livello senza bruciare tutto l’ambiente

clear resetta solo ciò che vedete. I moduli si disinstallano singolarmente. L’interfaccia opzionale può essere resettata a parte. Il livello extensions può essere rimosso lasciando Core. Il kill completo esiste, ma è l’ultimo confine, non un riflesso di troubleshooting.

Questo modello a livello è una buona abitudine terminale generale: identificate lo stato minimo davvero rotto e resettate solo quello. Distruggere raramente sostituisce diagnosticare.

clear

Concludete con un flusso di lavoro il cui risultato può essere provato

L’esempio finale verifica che il workspace esista, lo archivia, testa il TAR, ispeziona l’artefatto e calcola un impronta. Ogni passo stabilisce una precondizione o produce prova per il successivo.

Eseguitelo prima con -n, poi con -v. Cambiate root e archive solo dopo aver compreso il risultato. Lo scopo non è questo particolare archivio, ma l’abitudine di costruire procedure che si spiegano da sole.

run library/release-check.lil -n

run library/release-check.lil -v

La vera abilità è il metodo, non il vocabolario dei comandi

Linux, macOS, Windows e gli ambienti di esecuzione dell’hosting non sono uguali, e lil-terminal non finge che lo siano. Ciò che si trasferisce è il metodo: ispezionare lo stato, fare un cambiamento limitato, verificare il risultato e salvare la parte ripetibile.

Quando diventa naturale, un nuovo terminale non è più un muro di syntax sconosciuta. Avete domande da porre, prove da raccogliere e routine da adattare. Questo è il senso dell’introduzione: non finire di imparare, ma rendere la command line un posto in cui sapete lavorare.

Conservalo come script

Salvate il flusso di lavoro finale come library/release-check.lil. Non conosce il vostro progetto applicativa: mostra la forma riutilizzabile di un versione pubblicata punto di controllo — verificare workspace, creare archivio, testarlo, ispezionarlo e registrare un impronta.

set root lil-playground
set archive lil-playground-checkpoint.tar

if dir "$root"
    dir "$root" 1 -G
    tar "$root" "$archive" -f
    tar "$archive" -t
    stat "$archive"
    hash "$archive"
else
    stop "Workspace is missing"
end