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?
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.
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:
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.
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:
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. 
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:
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:
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.
| © 2008-2012 SlashCode | Suffusion theme by Sayontan Sinha |
Recent Comments