Salve a tutti e ben tornati dalle vacanze!Per riprendere un po’ il ritmo con il blog vi propongo dei mini-post che rispondono velocemente ai più comuni problemi di compilazione ed esecuzione di programmi.

Il primo problema che risolveremo è il seguente

A chi non è capitato almeno una volta nella vita?

PREMESSA:

Ogni applicazione sul vostro sistema usa delle librerie. Una libreria non è altro che un insieme di codice già pronto e compilato che esegue delle funzioni specifiche. Questo permette ad ogni sviluppatore di non reinventare la ruota ogni volta ma di utilizzare il codice già scritto da altri.

Una libreria può essere statica (.a) o dinamica (.so o .dll su Windows). Nel primo caso la libreria viene inglobata nell’eseguibile in fase di compilazione, nel secondo invece la libreria è un file separato che viene agganciato all’eseguibile durante il caricamento del programma da un componente del sistema operativo chiamato linker dinamico.

Ovviamente le librerie dinamiche ottimizzano meglio le risorse evitando che del codice uguale venga replicato inutilmente in ogni eseguibile.

CAUSA:

Il messaggio di errore non lascia alcun dubbio: la libreria dinamica non è presente nel sistema o il linker dinamico non riesce a trovarla.

SOLUZIONE:

Se la causa è semplice la soluzione è altrettanto semplice.

Per prima cosa accertiamoci che la libreria sia installata e presente nel nostro sistema. Possiamo verificarlo agilmente con

locate libXXX.so

Che restituirà il percorso della libreria.

Se la libreria è stata installata durante la sessione corrente allora dobbiamo forzare l’aggiornamento del database con

sudo updatedb

A questo punto probabilmente la libreria si troverà in un percorso non standard. Non ci resta che aggiungere questo percorso nella lista dei percorsi scandagliati dal linker.

Per fare questo apriamo il file /etc/ld.so.conf (o creiamo un file nella cartella /etc/ld.so.conf.d/) e inseriamoci dentro il percorso della libreria, ad esempio:

/usr/local/lib.

A questo punto chiamiamo

sudo ldconfig

per aggiornare la cache del linker.

E il gioco è fatto.

Fra le parole più abusate su internet un posto d’onore va a programmatore (o developer e varianti). Forse secondo solo a “H4ck3r”. In ogni caso, programmatore fa fico, creare programmi e dire alla gente “questo l’ho fatto io” non ha prezzo.

Ma la realtà è ben diversa. Spesso molti di questi individui sono programmAttori e nulla più. Molti conoscono la programmazione sciamanica, l’arte di scrivere mantra tantrici su dei file .c o .py e passarli ad un compilatore per ottenere qualcosa in cambio. Questa non è programmazione, almeno non al suo livello più nobile. Il web è pieno di questi arroganti developer. Vediamo come disinnescarli.

1 – Programmare non significa assemblare

Se trovate persone che vi propinano programmi scritti da loro il primo modo per verificare la potenza della loro capacità. Verificate il numero di librerie e cosa fanno. Molto spesso troverete programmi assemblati. I programmi assemblati sono i software semplici costruiti a partire da un numero enorme di librerie (che fanno tutto il lavoro sporco) che vengono assemblate dal programmatore. Un esempio di questi programmi sono player musicali o programmi di pulizia del sistema. In realtà tali programmi usano librerie grafiche, librerie audio e collegano il tutto in modo piuttosto lineare.

Questo è essere programmatori allo stesso modo di come cucinare un piatto leggendo una ricetta da un libro di cucina usando prodotti surgelati fa di noi degli Chef.

È una programmazione hobbistica, che ha il suo rispetto, la sua dignità e spesso sforna programmi utilissimi. Ma i programmAttori te lo spacceranno come una meraviglia dell’informatica e pretenderanno, alla luce di ciò, di parlare alla pari con un developer del kernel.

2 – Programmare non significa sapere un linguaggio

Un programmatore non conosce il C, non conosce il Java, non conosce il Python: li conosce tutti. Un programmatore esperto non ha paura di imparare un linguaggio nuovo perché con venti minuti di letta al manuale del linguaggio entra già nel meccanismo. Questo perché sa che cos’è la programmazione al di là del singolo linguaggio, ha appreso i concetti informatici che stanno dietro ai linguaggi di programmazione e sa riconoscerli in tutti i linguaggi del mondo.

Ovviamente sto esagerando, ma un programmatore esperto può semplicemente imparare un linguaggio nuovo in due ore (se rientra nei paradigmi che conosce, altrimenti un paio di giorni).

Il programmatore farlocco invece no. Se gli dici “facciamo un progetto XYZ” non ti dirà di farlo nel linguaggio più adatto allo scopo bensì nel linguaggio che conosce.

Si può essere più programmatori scrivendo in pseudocodice su carta che scrivendo uno script di pulizia in bash.

3 – Programmare non significa fare finestre

Altro comportamento classico del programmatore wannabe è il classificare come più dignitose le applicazioni grafiche rispetto alle applicazioni a riga di comando. Se sentite frasi del tipo “io faccio programmi con le finestre, mica quelle schifezze a riga di comando” accendete l’allarme: è molto probabile che vi troviate di fronte ad un programmAttore montato dei più classici.

Le finestre sono un aspetto (minimale) dell’intera programmazione. Nonostante nell’uso desktop utilizziamo quasi tutte applicazioni a finestra queste rappresentano solo una minima parte del lavoro che milioni di programmatori fanno ogni giorno (ad esempio scrivendo librerie come quelle che loro usano per fare le amate finestre). Quindi scusate se mi innervosisco ma uno che si vanta di fare programmi a finestra invece di altro non solo non è programmatore: è un mentecatto.

Un programma come Gazebo, tanto per dirne uno che sto usando ora, è un programma estremamente sofisticato e complesso dato che serve a simulare insiemi di Robot in ambienti 3d. Eppure è un programma a riga di comando. Il tanto amato dpkg di Debian è a riga di comando eppure svolge tutto il lavoro pesante dell’installazione dei pacchetti.

Inoltre, se vogliamo dirla tutta, la programmazione una finestra grafica non è complessa (in generale), si va dalla quasi banalità del Visual Basic e del Gambas alla media complessità di Gtk e Qt. Saper fare finestre grafiche significa studiare e conoscere bene una libreria fra le infinite disponibili, non conoscere la programmazione nel suo complesso.

4 – Programmare non significa conoscere HTML e CSS

Fra i programmAttori web spesso giara questa balla. Io conosco HTML e CSS quindi sono un programmatore. Sbagliato. Al massimo sei un Web Designer ma non un programmatore.

La ragione è semplice: HTML e CSS non sono linguaggi di programmazione e, se non il presunto developer non sa questo allora è garantito che non è un developer. Essere esperti di HTML equivale ad essere esperti di CSV, LaTex e altre metodologie di formattazione dei dati. Potete fare un ciclo in HTML? No. E quindi non è chiaramente un linguaggio di programmazione.

5 – Programmare non significa scrivere codice

O almeno non significa solo quello. La programmazione è una cosa più vasta di cui lo scrivere codice è probabilmente la cosa più noiosa. L’atto di sviluppare un’applicazione parte da prima, da quando si analizzano gli aspetti di ciò che si vuole fare e si progetta l’applicazione, e arriva fino alla fase di test. È la progettazione soprattutto, la sensazione di analizzare un problema, smontarlo e risolverlo che fa di noi un programmatore. Non ha ancora scritto una riga di codice ma nella sua mente il programma è già scritto e questo, vi assicuro, da una bellissima sensazione.

Il programmAttore invece scrive codice su codice spesso in mega malloppi di file per nulla modulari e invece di lamentarsi di come sta gestendo il suo progetto probabilmente si lamenterà del linguaggio (che secondo lui non permette di fare la cosa X o la cosa Y).

6 – Programmare significa progettare strutture dati

Probabilmente, se non vi siete mai trovati a progettare una struttura dati o almeno a pensare a quale struttura dati sia migliore per la vostra applicazione, non siete veri programmatori. L’unica cosa che fanno i programmi è manipolare l’informazione e l’informazione è manipolata e memorizzata nelle strutture dati. Quindi programmare È fare strutture dati.

Molti linguaggi coprono molte funzioni base. In Python per fare una lista dinamica non ci vuole certo un tecnico esperto, ma per programmi complessi anche il Python necessita di un po’ di progettazione nelle strutture dati (anche solamente organizzare gli oggetti che popoleranno la nostra applicazione).

Tutti i programmatori che conosco e che stimo almeno una volta hanno avuto la necessità di scrivere manualmente una lista, un array, un heap e così via. Anche io ne ho avuto bisogno. Credo che tutti ne abbiano bisogno prima o poi.

Se il vostro interlocutore tentenna sulla struttura firstchild-nextsibling di un albero probabilmente siete davanti ad un programmAttore.

Per concludere. Forse ci sarebbe molto altro da dire e molte altre cose che al momento mi sfuggono ma il punto credo sia chiaro: per chi, come me, ama questa disciplina è fastidioso veder impazzare per il web tanti tromboni che vantano una conoscenza di programmazione accademica e danno la colpa dei loro fallimenti sempre a qualcos’altro. È irritante sentire cose stupide come quelle al punto 3.

C’è chi studia anni, legge libri su libri per apprendere una tecnica, che scrive tonnellate di righe di codice praticamente inutile solo per implementare e mettere a punto una particolare struttura dati o un particolare algoritmo che ha studiato. Poi arriva il ragazzino di turno che ti sbatte in faccia l’ennesimo programma con GUI per pulire il tuo sistema e pretende di parlarti alla pari.

Vorrei che tutti questi individui imparassero l’umiltà e capissero, come me, che abbiamo ancora molto da imparare. Molto.

Ultimamente, lo ammetto, sto scrivendo parecchio meno del solito. Sono oscillazioni naturali, non si possono avere sempre cose intelligenti da dire e in questo caso è meglio tacere piuttosto che scrivere diecimila post uguali sull’ultima emissione gassosa di Google o di chissà quale altro software. Ho passato le ultime settimane per lo più a studiare (anche se non al ritmo che mi aspettavo causa mancanza di fonti e concentrazione) e ad approfondire alcuni miei interessi. Siatene giulivi poiché dispenserò a breve tale conoscenza a fiotti sulle vostre menti assetate.

Ma torniamo a noi. Nell’ultima settimana mi sono trovato a mettere le mani sul sorgente di KPackageKit. Questo sorgente è un vero lavoro machiavellico di ingarbugliamento di idee, completamente privo di documentazione e saltuariamente infarcito di commenti di poco aiuto come granella di nocciola sul gelato. Allorché, in preda al deliro causato dall’essermi letto migliaia di righe di codice senza averci capito quasi nulla, se non a grandi righe, mi è venuta l’idea di buttare due righe su come NON si programma.

Ci sono infatti una manciata di cose che un programmatore non deve mai fare. Una lista di COSE DA NON FARE che troppo spesso vengono fatte al grido di “tanto funziona” e “tanto si capisce”. Risulta quindi più facile spiegarvi cosa non fare piuttosto che insegnarvi il contrario.

1) NON DOCUMENTARE IL CODICE

La risposta del tizio di KPK alla richiesta di documentazione è stata:

I don’t create documentation for KPackageKit because I think libs needs to be docummented, and if you read the lib’s docs you will understand KPackageKit

Permettetemi di dissentire. E’ normale che un programmatore debba conoscere la documentazione delle librerie Y alla base di un progetto X, ma ciò non toglie che anche il progetto X debba essere documentato! La documentazione di X infatti serve, come minimo, a spiegare come viene utilizzata la libreria Y all’interno di X. La documentazione serve per aiutare chi mette le mani sul codice per la prima volta, fornisce un filo rosso da seguire per muovere i primi passi all’interno del codice senza perdersi e in modo efficiente, spiega quali sono i moduli, il loro funzionamento e come sono relazionati fra di loro. Tutte cose che si possono apprendere dal codice ma che necessita di un enormità di tempo.

Questo fa quindi perdere tempo al novello programmatore e spesso perdere tempo significa far perdere la voglia.

2) DESCRIVERE IL CODICE

Altro errore frequente è quello di descrivere il codice nei commenti. I commenti devono descrivere le intenzioni di un passaggio non tutti i dettagli. Dovete infatti assumere che chi legge il codice conosca il linguaggio e gran parte delle librerie sottostanti.

/* COMMENTO ERRATO:

 * Se a è maggiore di b restituisce a, altrimenti b.

 */



/* COMMENTO GIUSTO:

 * Restituisce il più grande fra a e b.

 */

if (a > b)

    return a

else

    return b

Ora, quello sopra era un esempio piuttosto idiota ma spero sia chiaro il concetto. In sintesi i commenti dovrebbero descrivere tutto ciò che non è chiaramente intuibile leggendo il codice nei dintorni.

3) USARE CONVENZIONI AD-PERSONAM

Questo si traduce in un semplice usate le convenzioni del linguaggio. Questo va fatto sempre. Anche se una cosa è sintatticamente corretta non vuol dire che lo sia. Se nel linguaggio le classi cominciano per maiuscola NON fate classi che non cominciano per maiuscola. Questo serve a far subito capire ad altri programmatori il significato di una parola all’interno del codice. Se io leggo in un codice C++ la parola supereroe io penso che sia una variabile e non una classe. Se invece scrivete SuperEroe allora è chiaro che tale parola si riferisce ad una classe. Semplificando di molto il mio lavoro.

Oltre a questo le convenzioni di un linguaggio indicano la via corretta per molti altri aspetti. Se avete intenzione di infrangere delle convenzioni documentatelo. Come, ad esempio, fa Google con le linee guida per python.

4) NON MANTENERE UNA COERENZA INTERNA

Cosa più semplice a farsi che a dirsi ma che spesso viene del tutto ignorata. Un esempio di coerenza interna è la posizione dei parametri di un metodo o di una funzione oppure il nome delle funzioni. Se decidiamo che tutte le funzioni che accettano in ingresso un vettore finiscano con la lettera v allora dobbiamo accertarci di seguire questa regola per tutto il progetto. Se decidiamo che il primo parametro delle funzioni che si riferiscono ad una Persona sia il nome allora dobbiamo accertarci che sia sempre così.

5) LASCIARE BOLLE DI CODICE SOTTO COMMENTO

Può capitare che, nel corso della scrittura di un programma si commentino grandi parti di una funzione o interi metodi. Questo può servire ad isolare del codice buggato o a nascondere funzionalità incomplete. Tuttavia, sebbene questo vada bene in rami locali personali non dovrebbe mai essere lasciato in rami pubblici. Se una funzione funziona bene, altrimenti la togliamo. Queste bolle di codice creano gran confusione  e soprattutto un programmatore intento a modificare il codice se le ritrova in mezzo alle scatole senza sapere se le può togliere oppure no.

6) CHIAMARE LE VARIABILI CON UNA LETTERA O CON NOMI A CASO

I nomi delle variabili dovrebbero essere piuttosto esplicativi. Ad esclusione di contatori ed iteratori, una variabile non dovrebbe mai avere un nome di una sola lettere. A meno che l’oggetto a cui si riferisce non sia proprio un qualcosa identificabile da una lettera (ad esempio le coordinate x e y di un punto). Non vedo dove sia il problema a scrivere variabili di una decina di caratteri considerando che tutti gli editor hanno l’auto-completamento.

7) ORGANIZZARE IL CODICE SENZA CRITERIO

Il codice va diviso e organizzato in macro-moduli (o package, come si chiamano in molti linguaggi) che siano coerenti fra loro. Questo per consentire un rapido accesso all’insieme dei moduli che gestiscono una data funzionalità. Questi macro-moduli vanno assolutamente documentati.

8 ) SCRIVERE CODICE SENZA PROGETTO

Questo è il punto fondamentale. I programmi vanno prima scritti a computer spento. Non fatevi prendere dalla fretta di scrivere e compilare perché al 90% esce un casino. Questo può andare bene per piccoli progetti e roba semplice ma per qualunque cosa di complesso è un suicidio. Programmate tutto su carta. Scrivete le classi di cui avete bisogno, le relazioni fra le stesse, le operazioni salienti, i moduli da fare e i package in cui suddividerli. Dopo un paio di giorni di analisi a computer spento vedrete che con mezza giornata scriverete migliaia di righe di codice come se fossero sonetti in rima baciata.

Ovviamente mentre scriverete e proverete il codice sul serio salteranno parecchie cose di cui non avevate tenuto conto o errori di progetto. Ma non fa nulla. Questa è la prassi, è il modo in cui vanno fatte le cose.

CONCLUSIONE

Ora spero che appenderete questi 8 punti sulla vostra parete perché io non ho più voglia di impiccarmi mentre leggo del codice scritto e documentato da un macaco. Se seguite i miei consigli e non fate questi 8 punti (in realtà potrebbero essere di più ma oggi sono buono) vedrete che sarà tutto più facile per voi, sia per chi ha intenzione di aiutarvi.

Buona giornata.

A parte il titolo stupido di questa “rubrica” volevo pubblicare la risposta ad una domanda che mi è arrivata da Facebook. La domanda è la tradizionale “Come faccio a programmare come un Dio?”. Domanda la cui risposta basterebbe da sola a riempire corsi e tonnellate di guide. Tuttavia ho scritto un mezzo poema e, unito al fatto che la risposta può servire anche ad altri, mi sembra sprecato lasciarla nella mia casella di posta in uscita.

La domanda era la seguente:

io avrei bisogno di un consiglio se possibile: vorrei sapere come sei arrivato e dove hai imparato a fare queste cose cosi complesse?io provo provo e provo ma fallisco miserabilmente.

Ed ecco la risposta.

Mi fanno in molti questa domanda e difficilmente riesco a dare risposte soddisfacenti.

Per primo credo che sia necessario apprendere una forma mentis che va al di là del linguaggio usato per programmare. Questo permette di passare facilmente da un linguaggio ad un altro e di “progettare” un applicazione ancor prima di scrivere una sola riga di codice.

Tale impostazione è la cosa a mio avviso più importante. Bisogna imparare a trattare le cose che vogliamo fare come entità matematiche perché , fondamentalmente, i computer sanno fare solo calcoli matematici.

Il problema è, come sempre, trovare il modo per entrare in quest’ottica. Il primo modo è avere una preparazione matematica basilare: la matematica è di per se un “linguaggio” e conoscerlo aiuta molto. Secondo c’è il lato puramente informatico. Riguardo a questo ci sono un paio di consigli che con l’esperienza mi sento di dare:

1) Scegliersi un linguaggio e concentrarsi su quello. Non cambiare quindi linguaggio nella speranza che vada meglio: le basi concettuali sono sempre le stesse.

2) La scelta del linguaggio è molto importante: linguaggi troppo “severi” rischiano di farti concentrare troppo sul lato “macchina” del linguaggio, linguaggi troppo “di bocca buona”, al contrario, astraggono talmente tanto la programmazione che difficilmente si imparano i suoi aspetti fondamentali. Io quindi solitamente consiglio delle buone vie di mezzo come C# o Java (tanto per usare i più famosi). Python è molto facile ma lo trovo “poco istruttivo”: è molto più facile passare da C# o Java ad un altro linguaggio piuttosto che passarci da Python.

3) Perseverare. Una volta appresa la sintassi di un linguaggio non si sa programmare. A programmare si impara programmando: piazzarsi un obbiettivo non troppo elevato e iniziare a portarlo avanti. Anche abbandonarlo se si rivela troppo alto ma l’importante è provarci. Il 90% delle cose che ho imparato le ho imparate sbattendoci la testa, cercando soluzioni su Google, chiedendo a gente più esperta. Quindi ti consiglio caldamente di imparare la sintassi di un linguaggio e di usare quello per realizzare piccoli progetti personali. Roba anche inutile ma utile per imparare. Ad esempio scoprirai che è molto istruttivo cercare di implementare una specie di rubrica da terminale.

4) Ultimo consiglio: le librerie. Quando si padroneggia un linguaggio è giunge il momento di imparare qualche libreria: interfacce grafiche (Gtk o QT ad esempio), sistemi audio (gstreamer o Xine), per l’interazione col web, e così via… Questa è l’unica parte veramente difficile E a questo punto non puoi far a meno di chiedere e domandare in giro e dovrai pensarci solo a tempo debito.

Mi sono dilungato anche troppo. Ti ringrazio per la domanda che mi ha spinto a una piccola riflessione e spero che tu possa continuare a provarci. Per ogni domanda che ti verrà in mente durante il tuo percorso puoi sempre trovarmi su Slashcode o chiedere sul forum di LinuxQualityHelp.

Stavo attrezzando un piccolo progettino scemo sulle OpenGL (più didattico che altro) e così ho pensato di condividere quelle regole non scritte che servono ad organizzare e gestire un progetto software. Sono piccole “tips”, struttura delle cartelle e file che non devono mai mancare. Presenterò anche altri strumenti, come ho fatto per Python, ma questa volta saranno strumenti “generici”, ovvero utilizzabili con qualunque linguaggio.

Questo perché tenere in piedi un progetto male organizzato è come costruire un castello di carta. Ci vuole una base forte per rendere il più accogliente possibile il progetto per le persone interessate a collaborare, sia per i membri del vostro team (se ne avete uno).

STRUTTURA CARTELLE

Le cartelle vanno organizzate in modo piuttosto coerente. È importante non mischiare tutto in poche cartelle confuse specialmente per progetti destinati a crescere rapidamente. Una struttura minimale è la seguente:

• src – La cartella src contiene il codice sorgente. Il codice al suo interno può essere organizzato come si desidera in accordo con le convenzioni del linguaggio. L’importante è che contenga solamente il codice del programma/libreria.
• test – La cartella test contiene il codice sorgente dedicato ai test. Il codice di test serve a provare il corretto funzionamento delle classi sviluppate o di alcuni moduli software oppure possono essere semplicemente test prestazionali.
• build – La cartella build contiene tutti i file ottenuti come residuo di una compilazione. Possono essere moduli parziali C/C++ (.o), classi Java (.class), file python compilati (.pyc) e così via. La cartella va a sua volta divisa nelle varie configurazioni di compilazione (ad esempio ci potrebbe essere una configurazione Debug con compilati ottimizzati per il debug e una configurazione Release con compilati ottimizzati per le prestazioni).
• dist – La cartella dist contiene il prodotto finito. Può essere il programma eseguibile, un file .jar, una libreria .so e così via. Tutto quello che sta in dist deve essere pronto per essere eseguito e distribuito.
• doc – La cartella doc contiene la documentazione dettagliata. Tale documentazione è per lo più la specifica dettagliata delle API la quale è solitamente auto-generata.

FILE MUST

Nella cartella radice sono necessari alcuni file. Necessari è una parola grossa in quanto solitamente il programma funziona benissimo anche senza, ma sono un tocco di classe e di umanità verso chi vuole accedere ai sorgenti della vostra applicazione.

• Tool di compilazione - Sia Makefile, o Cmake o qualunque altro tool utilizzate… DEVE esserci uno strumento per la configurazione e la compilazione. Molti IDE possono anche auto-generare roba simile.
• README – Il readme deve dire vita morte e miracoli sull’applicazione. Deve spiegare come può essere compilata  l’applicazione, quali sono le dipendenze, i bug noti, etc..
• README.src – Per applicazioni il cui README è eccessivamente complesso è bene separare le informazioni per sviluppatori in un file a parte. Il file README.src deve spiegare come è organizzato il codice, quale IDE si è usato (se si è usato), quale librerie di sviluppo servono, quale strumenti si sono usati per generare la documentazione, per i test e per altro. Insomma… tutto ciò che può essere utile per chi è interessato alla modifica del codice.
• COPYRIGTH - Il file che contiene le informazioni sulla licenza del progetto.
• CHANGELOG – Il file che contiene la lista dei cambiamenti apportati al programma nel corso della sua storia. Questo file può essere auto-generato da alcuni sistemi di CVS.

DOCUMENTAZIONE

Scrivere a mano la documentazione è sempre l’ultimo dei problemi. Nonostante ci siano molte cose che debbano necessariamente essere scritte a mano, per le API è possibile usare dei tools automatici. Abbiamo visto Epydoc per python. Bene, per tutto il resto c’è Doxygen. Doxygen è un programma di auto-generazione della documentazione utilizzabile per una miriade di linguaggi.

CVS

Il programma per CVS è essenziale se programmate in gruppo ma è molto utile anche se programmate da soli. Vi permette di manipolare il codice con molta disinvoltura navigando fra branch diversi in modo del tutto trasparente.

Potete usare quello che vi pare come CVS anche se io consiglio sempre GIT. Lo trovo molto più veloce ed elastico dei concorrenti. Se volete convincervi potete sempre andare su http://it.whygitisbetterthanx.com/

MESSAGGISTICA

Ebbene si. Se avete un gruppo di persone con cui lavorate insieme non potete prescindere da un sistema rapido e veloce per lo scambio di informazioni, siano esse “OMG! Non funziona una cippa!” o messaggi più tecnici.

A questo punto avete le basi. Non vi resta che seguire questi consigli e lanciarvi nel tempestoso mondo del software libero sperando che il vostro progetto non sia un castello di carte spazzato via dal vento.

Segnalo ancora un nuovo aggiornamento. Arrivato in ritardo ma è arrivato. Purtroppo sono stato distratto da interessanti argomenti di Intelligenza Artificiale e mi è passato tutto il resto di mente!

Fra le modifiche che ho fatto segnalo che ho completato la parte sui modelli astratti di algoritmi (forse approfondisco un po’ le macchine a registri) e ho corretto alcune sviste.

Ecco il solito link:

DIGITAL MIND

Alla prossima.

Avevo promesso aggiornamenti settimanali ed eccomi qui. Il capitolo sulla logica booleana è grossomodo terminato. Mancano degli esercizi che inizierò a mettere presto. Inoltre c’è anche la prima parte del capitolo sugli algoritmi.

Come al solito sono gradite segnalazioni di errori, commenti e richieste di maggiori chiarimenti su parti della guida che ho involontariamente lasciato troppo fumose.

Trovate tutto al solito link: DIGITAL MIND

Ciao

La maggior parte dell’opera non consiste nel vedere se una cosa smetterà di funzionare bensì nel pensare a cosa fare quando quella cosa smetterà sicuramente di funzionare.

Questa cosa è presente anche nell’informatica e nelle telecomunicazioni: ad esempio non possiamo garantire che le trasmissioni attraverso un canale siano perfettamente prive di errori, anzi, gli errori sono sempre dannatamente frequenti se paragonati alla quantità di dati che attraversano la rete e alla precisione che ci aspettiamo in uscita.

Scarichiamo solitamente file di un paio di mega, circa 2 milioni di byte che corrispondono a 16 milioni di bit. Anche solo un errore su 100.000 bit inviati (una percentuale di errore dello 0.001%) si ripercuoterebbe nel file per 160 volte e sappiamo che, specialmente in file eseguibili, basta anche un solo bit fuori posto per mandare all’aria l’intera applicazione.

Il metodo più utilizzato per ovviare al problema è senza dubbio la ridondanza ovvero la ripetizione delle informazioni nella speranza che, anche nel caso in cui un pacchetto di informazioni venga danneggiato da un errore di trasferimento, il ricevente abbia sempre a disposizione una “copia di riserva” da cui recuperare l’informazione.

La ridondanza viene solitamente applicata su più livelli e nella pila protocollare ci sono almeno 2-3 meccanismi di ridondanza più un meccanismo di “rinvio”. Quindi possiamo dire che nel traffico di rete l’informazione utile è meno della metà del totale dei bit in transito.

Al livello più basso il meccanismo di codifica più basso e semplice che possiamo immaginare è quello di duplicare brutalmente l’informazione: se dobbiamo inviare la sequenza di bit 011010 invieremo, per sicurezza, 000111111000111000. In questo modo anche se abbiamo un errore all’interno della tripletta di bit sapremo sempre qual’era il messaggio originale. Infatti se riceviamo la tripletta 010 sappiamo che in realtà la tripletta originale era 000 e non 111 per il semplice fatto che la probabilità di un errore è molto più alta che la probabilità di due errori nella stessa tripletta! Ovviamente non abbiamo la garanzia assoluta ed è per questo che ci sono meccanismi di ridondanza anche ad alto livello.

Ma perché abbiamo messo triplette invece di coppie? Semplicemente perché la tripletta ci permette di eseguire sia la rilevazione che il recupero dell’errore. Supponendo infatti di inviare coppie quali 00 o 11 alla presenza di un errore, mettiamo 01, non possiamo distinguere se ci sia stato un errore nel primo bit (e quindi l’originale era 11) oppure l’errore fosse del secondo bit (e quindi l’originale era 00). In questo caso possiamo solamente rilevare l’errore ma non possiamo recuperarlo.

Questo fatto è indicato dalla distanza di Hamming la quale indica il numero di “errori” necessari per convertire una stringa di bit in un altra. Il primo codice che abbiamo usato ha una distanza fra i suoi elementi (ovvero fra 000 e 111) di 3. Il sistema quindi sceglierà, in caso di errore, la stringa che dista di meno da quella ricevuta. Nel nostro esempio la stringa 010 dista 1 da 000 e dista 2 da 111. Scegliendo quella a distanza minore scegliamo proprio 000.

Notiamo quindi che scegliere un codice che abbia distanza di Hamming dispari fra i propri elementi garantisce sempre il recupero dell’errore perché il sistema ha sempre una parola di codice più vicina di un altra. Una distanza di Hamming pari fra le parole invece presenta sempre, seppure improbabili, delle stringhe ricevute che distano in egual misura da due parole distinte. In questo caso il sistema è solo in grado di rilevare l’errore e non di correggerlo.

Ma la ridondanza non viene solamente utilizzata per rilevare e correggere errori. Anche le prestazioni di un programma possono beneficiarne. Supponiamo ad esempio una classe Triangolo che mantiene al suo interno informazioni sui tre angoli interni dello stesso. Notiamo subito che potremmo operare in due modi: creare tre attributi che mantengono i tre angoli, oppure mantenere solo 2 angoli e ricavare il 3° tramite una funzione. Se scegliamo di inserire il terzo angolo inseriamo una ridondanza. Se abbiamo un triangolo con due angoli di 45°sappiamo automaticamente che il terzo dovrà essere di 90°. Facendo così risparmieremo sì spazio ma renderemo la classe triangolo più onerosa dal punto di vista della CPU.

Questa cosa è sempre vera, anche nel caso della rilevazione dell’errore. Quando scegliamo di utilizzare la ridondanza scegliamo di sacrificare lo spazio per guadagnare tempo. E’ questa la grande coperta dell’informatica: dobbiamo sempre saper scegliere se il sacrificio di spazio dia guadagni in tempo significativi o, viceversa, se risparmiare spazio non faccia perdere troppo tempo.

E’ un concetto sottile ma essenziale per progettare sistemi ad alta efficenza e soprattutto adatti all’ambiente che vogliamo utilizzare.

Dato che alcuni me l’hanno chiesto e datoche non ho molto tempo ultimamente posto qui di seguito una seconda bozza della versione PDF della guida. Ancora molto incompleta ma spero lo prendiate come un gesto di impegno. Non è un progetto abbandonato.

SCARICA IL PDF

Penso abbiate tutti presente l”utilissima funzione “man”. Man sta per manual anche se io spesso penso derivi da manna in quanto il 90% dei problemi li risolvo grazie a lei. In GNU/Linux la totalità dei programmi ha la sua manpage associata e, grazie ad essa, possiamo sapere vita morte e miracoli di ogni eseguibile o comando sia presente sulla nostra macchina. Ma non solo! Man racchiude anche la sintassi e la semantica completa di praticamente tutte le funzioni e le system call unix. Indispensabile per chi programma in C/C++.

Così noi stiamo preparando il nostro programmino. E perché il nostro dovrebbe essere da meno? Perché il nostro applicativo non deve avere la sua manpage? Perché gettare nella disperazione i nostri utenti?

Infatti non dobbiamo. Impariamo quindi a fare la manpage per il nostro programma!

Creare una manpage è decisamente semplice. Innanzitutto impariamo quelle 7 istruzioni di markup che ci servono:

• .TH – Indica il titolo della manpage
• .SH – Indica il titolo della sezione
• .SS – Indica il titolo della sotto-sezione
• .pp – Indica l’inizio di un nuovo paragrafo
• .B – Mostra il testo in grassetto
• .I – Mostra il testo in corsivo
• .” – Indica che la riga corrente è un commento (non viene visualizzata nel manuale)

Ora siamo praticamente pronti. Sappiamo tutto quello che ci serve. Apriamo il nostro editor di testo e iniziamo a scrivere la nostra manpage come in questo esempio:

.TH MioSoftware
.SH NAME
MioSoftware Super Calculator
.SH DESCRIPTION
.I MioSoftware
è un programma troppo bello!
.SH URL

http://www.linuxqualityhelp.it

E così via. Fate attenzione che ogni tag deve capitare come primo comando della riga.

A questo punto salviamo il nostro file come, ad esempio, mioprogramma.txt

Adesso dobbiamo copiarlo nella cartella di sistema affinché venga rilevato dal sistema. In debian questa cartella è /usr/share/man

All’interno di questa cartella sono presenti diverse sotto cartelle per indicare le varie “categorie” di manuali. Queste cartelle sono segnate da man1, man2, man3 e così via. Le categorie associate ad ogni numero variano da sistema a sistema ma generalmente sono:

• 0 – File Header
• 1 – Comandi Standard (quindi i normali eseguibili)
• 2 – Kernel System Call
• 3 – Funzioni Standard della libreria C
• 4 – Device speciali
• 5 – Formati di file e convenzioni
• 6 – Giochi
• 7 – Varie, ad esempio informazioni sugli standard (ISO)
• 8 – Comandi root
• 9 – Dettagli  del Kernel

Noi per esempio inseriremo la nostra man page nella categoria 1. Per farlo basta dare da root:

# cp mioprogramma.txt /usr/share/man/man1/mioprogramma.1

A questo punto abbiamo finito. Per vedere il risultato basta dare:

$ man mioprogramma

E crogiolarsi nella senzazione di “professionalità” che la manpage da al vostro software.