Categoria: Informatica per script kiddies

Informatica per script kiddies 15 – Versionamento e git

Eccoci con il quindicesimo Informatica per script kiddies, in cui parleremo di uno degli strumenti più utili nella programmazione di software (ma anche nella vita in generale, ne sogno un’applicazione ai codici legislativi), che per qualche motivo è anche uno dei meno conosciuti ai programmatori in erba: il controllo versione.

Parlerò poi nello specifico delle basi (ma proprio basi-basi) di git, il sistema di controllo versione ideato e usato per il kernel Linux ed estremamente popolare. Ne parlo perché è davvero molto diffuso e perché è quello che conosco meglio (assieme a svn ormai obsoleto, grazie al cielo). Sono ben consapevole che ne esistono altri, spesso migliori sotto alcuni aspetti, e invito i loro sostenitori a parlarne nei commenti (anche perché poi me li curioso).

Cercherò di essere un po’ più breve e semplice del solito, che a questo giro il tempo è limitato (grazie, OVH, avevo bisogno di una bella botta di disaster recovery), ma alla fine è una cosa così facile che lo permette anche.

Cosa è il versionamento

Quando si scrive un programma – e qualsiasi altra cosa – ci si accorge ben presto che è di grandissima importanza mantenere diverse versioni di quello che si sta facendo.

Si scrive una funzionalità, va alla grandissima, le si aggiunge un pezzo, non funziona più niente. A questo punto, ricordarsi cosa si è cambiato da quando funzionava e tornare al punto in cui funzionava è praticamente impossibile.

Questa dura esperienza di vita è la madre della cosa più orrenda che si possa trovare su un PC: le cartelle contenenti cartelle chiamate programma_funzionante, programma_funzionante_definitivo, programma_funzionante_definitivo_nuova_versione e via dicendo.

Il versionamento è l’automazione, fatta con criterio, di questa cosa.

Come funziona

L’idea alla base del versionamento è estremamente semplice. Chi usa un sistema di questo tipo, si cura di salvare come “nuova versione” il suo lavoro ogni volta che fa un set completo, ma anche non completissimo (sul lavoro dipende tanto dai gusti del PM o del tecnico che ne fa le veci), di modifiche.

Il sistema si curerà, mentre tu lavori sempre sugli stessi file senza farne copie, di salvarsi una traccia di cosa è cambiato nei file dall’ultima versione a quella corrente, e permetterà in qualsiasi momento di tornare a una versione precedente del lavoro (e di tornare poi alla corrente, o a qualsiasi altra).

L’atto di salvare una nuova versione del lavoro si chiama commit (e per estensione viene chiamata così anche la versione, che tecnicamente si chiama revisione). Ogni commit va accompagnato da una descrizione di cosa si è fatto, breve quanto basta a renderla utile e facile da consultare.

I sistemi di versionamento in genere dispongono di una serie di strumenti, a volte parte del sistema e a volte esterni, per consultare comodamente la lista di tutte le revisioni e le differenze tra l’una e l’altra, rendendo comoda l’analisi delle cose fatte e il debug in caso di problemi.

Cos’altro può fare

Dato il loro grande utilizzo nell’ambito della programmazione software, i sistemi di versionamento devono supportare una caratteristica importante di questo ambiente: i software vengono quasi sempre scritti in più persone.

Questi sistemi, quindi, di solito e in maniera più o meno efficiente, permettono a più persone di creare versioni parallele degli stessi file, occupandosi poi di ricongiungerle in maniera semiautomatica con la creazione di un nuovo commit che descriva le differenze tra le versioni parallele.

Questo li rende al momento uno degli strumenti più potenti per permettere la scrittura a più mani di programmi, e il principale motore dell’innovazione del modo in cui si scrive software. Cose oggi diffusissime, come le tecniche di agile development, sarebbero ai fatti impossibili senza dei robusti sistemi che permettano di avere traccia delle revisioni e di collaborare senza pestarsi eccessivamente i piedi.

Come funziona Git

Git, come detto, è uno dei sistemi di versionamento più diffusi oggi. Coprirne ogni aspetto è praticamente impossibile in un articolo come questo, e coprirne le tecniche di utilizzo è poco utile (ne esistono di standard, ma ai fatti ogni PM ha le sue e le adatta alla struttura organizzativa dei singoli progetti), ma cercherò di spiegare le basi a chi ci si approcciasse ora.

Il suo enorme successo è legato a doppio filo sia al fatto che è utilizzato per Linux (ed è ideato dalla stessa persona, Linus Torvalds), all’effettiva grande efficienza nel gestire codebase di grandi dimensioni, e al successo di GitHub, un server Git diventato sostanzialmente il principale social network di sviluppatori di software libero.

Git è un sistema di versionamento distribuito, che permette di mantenere sulla macchina di ogni collaboratore a un progetto una sua versione dello storico delle modifiche. Per semplicità, però, inizialmente, fingiamo che sia utilizzabile solo da un singolo utente.

Le basi

Una volta installato Git, per iniziare ad usarlo sui file presenti in una directory basta dare, in quella directory, il comando git init. A questo punto, Git considererà quella directory (e tutto il suo albero) un repository, ovvero un set di file di cui manterrà la versione.

Un file, agli occhi di Git, può essere in diversi stati. Quelli che ci interessano al momento sono:

  • Untracked, ovvero non sotto controllo versione
  • New ovvero sotto controllo versione e non presente nell’ultima revisione
  • Modified ovvero sotto controllo versione e diverso dall’ultima revisione
  • Tracked ovvero sotto controllo versione e identico all’ultima revisione

I file, se non sono Untracked, possono essere Staged e Not staged.

L’operazione di commit, che si fa con il comando commit -m "Commento", provvede a salvare nella nuova revisione i file Staged, ignorando quelli Unstaged.

Far diventare un file Staged è molto semplice: git add nomefile. Tirarlo fuori dallo stage è invece una cosa che dipende un po’ da dove vuoi metterlo, e git status spiega come fare per ogni gruppo di file.

I branch

Git prevede che sia possibile ramificare lo sviluppo su più linee, dette branch.

Questa funzionalità è molto comoda: si inizia a lavorare su un ramo principale (il ramo iniziale di default si chiama master). Se per qualche motivo si deve interrompere il lavoro per sviluppare una parte collaterale del software, come ad esempio una specifica funzionalità, si può creare un branch che sarà il clone del principale e lavorare su quello.

In qualsiasi momento si può poi saltare da un ramo all’altro, tornando ad avere il codice come lo si aveva prima di iniziare il lavoro collaterale. Quando si è finito di lavorare sul branch, lo si può riunire al principale.

Un utilizzo molto basilare e molto classico è quello di tenere sul ramo solo i rilasci veri e propri del software, per poi svilupparlo su uno o più branch secondari. A ogni rilascio, si riuniscono tutti i branch secondari sul principale. In qualsiasi momento, è possibile così saltare dalla versione “di sviluppo” del software all’ultima rilasciata.

Per creare un branch, si dà il comando git branch nome_del_branch, mentre per passare a un branch il comando è git checkout nome_del_branch. Il comando git checkout si può utilizzare anche per saltare a una qualsiasi revisione (i branch non sono altro che etichette sull’ultima revisione di un ramo), dando come nome l’id della revisione ottenuto con git log.

Per riunire due branch, invece, si può, essendo in quello di destinazione, dare il comando git merge sorgente. Git tenterà di riunire automaticamente i due branch, richiedendo di fare operazioni a mano sui file, che marca come In conflitto, quando non riesce.

L’utilizzo da parte di più utenti

Dicevamo che Git è un sistema distribuito. Ogni utente, infatti, può possedere il suo repository dello stesso progetto e fare i suoi branch e i suoi commit indipendentemente da quello che fanno gli altri.

A livello logico, ogni copia di ogni utente funziona come un branch a sé. Gli utenti possono fare una coppia di operazioni per tenersi sincronizzati con un server centrale.

Il pull (git pull) è un’operazione che permette di scaricare da un server (detto remote e gestibile con i comandi git remote) lo stato più aggiornato che ha per quel repository, e il push (git push) serve a caricare su un server la propria versione.

La procedura per aggiornarsi è quindi fare pull per ottenere le ultime modifiche. Git a questo punto tenterà un merge automatico, richiedendo di fare le operazioni manuali se fallisce. Aggiornato il proprio repository con le modifiche correnti, si può fare push per caricare sul server comune le proprie revisioni.

Queste sono più o meno le basi. Mi aspetto domande sul post Reddit, ché stavolta di cose per scontate ne ho date un po’ più del solito.

Informatica per script kiddies 14 – Le tastiere meccaniche

Un po’ in ritardo, questo quattordicesimo Informatica per script kiddies è un po’ atipico. Non parliamo infatti di una cosa strettamente informatica, ma della tastiera, una periferica che per forza di cose chi si occupa di informatica utilizza abbastanza da finire per chiedersi se ci sia di meglio di quelle fornite con i PC. E sì: c’è di meglio: le tastiere meccaniche.

(altro…)

Informatica per script kiddies 13 – Le API REST e quel mondo lì

Eccoci con Informatica per script kiddies, che è arrivato al tredicesimo numero! Insomma, sì, nasceva un anno fa e non mi aspettavo di essere ancora qui a scrivere dopo un anno. Vi ringrazio per l’entusiasmo, che mi ha dato la voglia di continuare a scrivere questi articoli, e ringrazio u/Sudneo, che ha scritto l’ottavo numero permettendomi di riprendere un po’ il fiato (e che spero di rivedere presto, magari assieme ad altri, in questa rubrica).

(altro…)

Informatica per script kiddies 12 – I formati per lo scambio dei dati

Eccoci un po’ in ritardo con Informatica per script kiddies, il dodicesimo numero! Qualche settimana fa, un bell’articolo del Post mi ha fatto venire voglia di parlare di questo argomento che è molto parte del mio lavoro, e che purtroppo non è chiarissimo non solo a molti che all’informatica ci si avvicinano, ma anche a tantissimi che si trovano a dirigere, più o meno direttamente, branche Information technology di aziende.

(altro…)

Informatica per script kiddies 11 – Le comunicazioni sicure

Questo mese un Informatica per script kiddies un po’ più nello spirito dei primi, che viene dritto da dubbi che ho visto in giro di recente.

Parliamo in termini molto generali di come avviene una comunicazione sicura, e di cosa significhi “sicura”, con qualche riferimento ai sistemi tutti italiani di comunicazione certificata che sono molto utili in questo periodo e che, con serie colpe da parte dell’amministrazione pubblica, sono stati compresi pochissimo.

(altro…)

Informatica per script kiddies 10 – I sistemi operativi

Eccoci al nostro appuntamento mensile con Informatica per script kiddies!

Oggi parliamo dei sistemi operativi, quei software che utilizziamo tutti i giorni e delle cui funzioni, nonostante questo, tendiamo ad avere un’idea un po’ fumosa.

I sistemi operativi infatti, nonostante siano dei programmi a tutti gli effetti, vivono in quel limbo che sembra sempre un po’ essere a metà tra hardware e software, e non sentiamo quasi mai di starlo direttamente utilizzando.

(altro…)

Informatica per script kiddies 9 – I linguaggi di programmazione, una panoramica

È il terzo mercoledì del mese, ed eccoci con Informatica per script kiddies!

Oggi proviamo a dire qualche parola di orientamento sulle caratteristiche dei linguaggi di programmazione, ovvero delle lingue che utilizziamo per spiegare al computer cosa fare.

(altro…)

Informatica per script kiddies 8 – Containers, cosa e perché

Oggi Informatica per script kiddies ospita finalmente un articolo di u/Sudneo invece che del solito u/LBreda. Siamo sempre alla ricerca di collaboratori, scrivete pure a LBreda se volete dare una mano! Trovate qui tutti gli articoli della rubrica.

L’argomento di oggi è qualcosa che da un paio di anni a questa parte è sulla bocca di tutti: i containers. C’è chi ne ha sentito parlare riguardo Docker, chi magari ha sentito parlare di Kubernetes, Podman o chissà cos’altro. Tutto si basa però su dei concetti che generali, che tenteremo di trattare in quanto tali.

(altro…)

Informatica per script kiddies 7 – Che succede quando andiamo su un sito

Eccoci di nuovo qui! Trovate qui tutti gli articoli della rubrica.

Oggi, invece, parliamo un po’ di come è fatto il web. Le cose possono ovviamente essere molto più semplici o molto più complesse di come le mostrerò qui, ma cercherò di dare un buon inizio per capire meglio come funzioni tutto l’accrocco, che non è sempre troppo chiaro.

Il web infatti nasce con un’idea molto semplice: dare a ogni risorsa un indirizzo composto dall’indirizzo del computer su cui risiede e dall’indirizzo della risorsa specifica. Digiti l’indirizzo in un browser (o clicchi su un link), e ottieni la risorsa. Le cose si sono però rapidamente fatte più complicate, principalmente perché i volumi di richieste sono diventati rapidamente molto grandi. Ma vediamo un po’ come funziona tutto.

(altro…)

Informatica per script kiddies 6 – Arduino, Raspberry Pi e quelle cose

Eccoci di nuovo la nostra rubrica mensile preferita. Ci siamo spostati sul blog di ItalyInformatica, dove prossimamente metterò in copia gli altri articoli per avere tutto insieme. Trovate qui tutti gli articoli della rubrica.

Oggi parliamo di cose che molti percepiscono come “schede piccole con cui fare cose strane”, e nemmeno a torto, ma che vengono di solito chiamati col nome piú tecnico di “sistemi embeded”.

(altro…)