Ogni tanto mi capita di trovarmi immischiato nella discussione che da anni tormenta programmatori e informatici di ogni nazione ed etnia: meglio usare un linguaggio tipizzato dinamicamente o staticamente?
Senza pretese di scientificità o di dogma o di starvi a rivelare chissà quale verità arcana nascosta, vi dirò la mia sull’argomento. Continue reading »
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.
Nulla è più importante di quello che è racchiuso nelle parentesi graffe. Se dovessi scegliere una frase per descrivere Lua sceglierei proprio questa. Volevo parlarvi di come utilizzare il paradigma a oggetti con Lua ma, rileggendo vari appunti, mi sono accorto che non posso assolutamente tralasciare una parte vitale del linguaggio: le tabelle.
Se in Lisp il tipo di dato base del linguaggio è la lista, se in Python è l’oggetto in Lua è la tabella. Non esiste nessun’altra struttura dati in Lua all’infuori della tabella: niente array, niente vettori, niente liste, solo ed esclusivamente tabelle.
C’è un principio molto noto dell’informatica che spesso viene dimenticato dagli sviluppatori tutti. Tale principio recita più o meno così: se una cosa è a 3 schermate di distanza allora non esiste. È un principio basilare nell’usabilità del computer per l’utente medio: se una cosa necessita di più di 3-4 click e si trova oltre i 3 passaggi allora, indipendentemente da quanto sia importante, per l’utente finale, non esiste.
Al riguardo ci sono un po’ di considerazioni da fare.
Perché viene dimenticata?
Il motivo è semplice: i programmi vengono scritti dai programmatori. Non è un gioco di parole, è la verità. Ai programmatori piace la soluzione arguta, l’opzione contorta, l’arzighigolo programmativo. Non possono farci nulla, è più forte di loro. Non di rado quando parli dell’usabilità d’uso di un programma con un programmatore ricevi come risposta cose tipo “vabbè è semplice. Basta che aggiungi /percorso/assurdo nella variabile ENV e avvii il programma con nomeprogramma -opzione1 -opzione2 -opzionen=boh e ottieni quello che vuoi!”. E tutto ciò è normale: se non gli piacessero le cose complicate non sarebbero programmatori.
Tutti se le dimenticano?
No. Ovviamente in molti programmi ci sono persone incaricate appositamente di frenare l’indole complicatrice degli sviluppatori. Ma allora perché troviamo ancora questi grossolani errori? Alcune volte per disattenzione e altrettante per malafede. Un esempio? Le impostazioni della privacy di Facebook. Quanti click servono per arrivarci? Sono tre per visualizzarle e 4 + n per modificarle a piacimento, tutto questo attraversando 2 schermate e un menù piuttosto dimenticato.
Solo malafede?
No. A volte nascondere una possibilità oltre la soglia dei 3-4 passaggi è una “features” che permette allo sviluppatore di evitare la scrittura di complicati meccanismi di blocco, criptaggio, ecc, contando sui grandi numeri.
Un esempio è dato da un applicazione Android per impostare lo sfondo del terminale. L’applicazione da accesso a una sterminata galleria di sfondi ma, ovviamente, non da la possibilità diretta di scaricare tali sfondi. Il motivo è che, giustamente, lo sviluppatore vuole che tu apra il programma ogni volta che vuoi cambiare sfondo: se te li facesse scaricare facilmente l’utente se ne scaricherebbe 30 nel giro di due minuti e poi si dimenticherebbe dell’applicazione!
Tuttavia per impostare uno sfondo è necessario scaricare l’immagine. Come fa il programma? La scarica e la imposta. Quando cambiate sfondo, cancella la precedente e la sostituisce con la nuova.
Ora capirete che è ancora teoricamente possibile scaricarsi 30 sfondi e buttare l’applicazione, basta copiarsi in una cartella l’immagine scaricata ogni volta che il programma la scarica. Ma quanti passaggi necessita? Troppi. Non tanti, ma troppi, più di 3-4. E così statisticamente il 99% delle persone utilizzerà il programma nel modo voluto dallo sviluppatore nonostante sia teoricamente fare diversamente.
Altri esempi?
Google. Fate una ricerca su Google e notate a che pagina desistete dalla ricerca. Sono quasi sicuro che smettete di cercare entro la 3° 4° pagina, se arrivate a 6 siete parecchio insistenti, a 10 significa che siete disperati (come io quando cerco tutorial su roba strana).
Se il vostro blog cade oltre la 4° pagina non esistete. È come se fosse alla pagina 100 mila.
Quindi?
Quindi pensateci. Tutto qui. Se programmate qualsiasi cosa che non sia destinata ad altri programmatori, fate caso a non collocare nulla oltre la soglia dei 4 click/schermate. I vostri utenti ne gioveranno e voi pure.
Se avete visto l’ultimo articolo sui venti linguaggi di tendenza forse avete notato una triste assenza. Nella top-50 infatti manca completamente l’accoppiata Vala/Genie. Se non l’avete notata allora è il momento che vi presenti questi due giovani virgulti.
Chi o cosa sono Vala e Genie?
Vale e Genie sono due linguaggi di programmazione OpenSource ad alto livello ed orientati agli oggetti portati avanti dalla fondazione di GNOME. La raison d’etre di questi due linguaggi, la loro missione, consiste nel limitare la diffusioni di linguaggi controversi come C# e le librerie Mono nel mondo Linux. Non credo serva ripetere quali sono i problemi di Mono in un ambiente open con Linux.
Oh no! L’ennesimo linguaggio fotocopia!
In realtà Vala e Genie sono qualcosa di più che una copia di C#. Ma partiamo dall’inizio.
La sintassi di Vala è presa quasi interamente da C# ma adattata alla struttura degli oggetti GObject (strutture dati ancestrali della programmazione Gnome). La sintassi di Genie invece ricopia la sintassi del Python.
Quali sono i vantaggi rispetto a usare C# o python?
Potrei elencare una lista di piccoli vantaggi. Tuttavia preferisco dirvene uno enorme: Vala e Genie sono compilati in C. Nessuna macchina virtuale, nessuna interpretazione del linguaggio, bensì tutta la potenza binaria del C. Volendo Vala e Genie vi forniscono anche il file .c e l’header .h in modo tale da poter integrare librerie in Vala all’interno di progetti in C.
Ovviamente il codice è meno prestante di un codice scritto in C nativamente (e scritto per bene) ma è comunque più veloce di una versione interpretata da una macchina virtuale.
Bellissimo! Un esempio?
Vala nasce dal progetto GNOME ed è quindi naturale che integri un supporto praticamente nativo con le librerie Gtk. Le Qt purtroppo non sono ancora supportate. Come esempio creiamo quindi una bella finestra in Gtk (l’esempio è preso da Wikipedia).
Il programma può essere compilato con:
Il risultato sarà un file binario perfettamente funzionante.
Mi piace! Ma funziona solo su Linux?
Vala e Genie sono nati per Linux. Esiste tuttavia un porting sperimentale per Windows.
E come mai questi due linguaggi tanto promettenti non sono nella top 50?
La risposta è una: gioventù. Il fatto che sia un linguaggio nato per linux da poco più che un anno sicuramente non aiuta. Tuttavia le premesse sono ottime.
Sono interessato. Da dove comincio per programmare in Vala?
Il vala non è molto diffuso e informazioni specifiche scarseggiano. Potete innanzitutto cominciare dal sito ufficiale.
Io, personalmente, non ho in programma di scrivere nulla su Vala e Genie. Per SlashCode nel prossimo periodo ho intenzione ancora di trattare Lua, l’AI e alcune cose di simulazione fisica. Comunque, se mi capiterà di trovare libri, siti e guide interessanti non mancherò di linkarle.
Buon Vala a tutti. 
Intanto che rifinisco l’ltimo articolo di Lua o mi viene in mente qualcosa di intelligente da dire, vi presento i venti linguaggi più quotati nel mese di giugno 2011 così come rilevati da TIOBE.
1 – Java
Conoscete già tutti Java, uno dei linguaggi più fastidiosi della storia (almeno secondo i miei canoni xD) che però detiene la prima posizione per due motivi: l’uso aziendale intensivo e il fatto di essere il linguaggio di programmazione nativo per Android.
2/3 – C/C++
Aggrego queste due posizioni in una a causa della strettissima correlazione fra i due linguaggi. Il fatto che siano nelle parti alte della classifica non sorprende.
4 – C#
Il clone (migliorato) di Java targato Microsoft è competitivo. Non avevo dubbi, molte aziende utilizzano il framework .net per le loro applicazioni.
5 – PHP
PHP è il linguaggio di scripting più usato del Web. Dopo anni ancora nessun linguaggio riesce a competere in modo significativo con questo mostro sacro dei linguaggi (anche se, la sintassi del PHP sembra fatta apposta per rendere il codice illeggibile).
6 – (Visual) Basic
Qui c’è la prima sorpresa. Il Visual Basic, per chi bazzica la rete, è praticamente un linguaggio morto e solo un pazzo consiglierebbe a qualcuno di mettersi a studiare il Basic. Tuttavia è bene ricordare che VB era usato massicciamente per uso aziendale circa dieci anni fa e che il mondo aziendale è dannatamente lento. Ed è anche comprensibile: quale azienda spenderebbe tempo e denaro per riconvertire migliaia di linee di codice che in VB funzionano perfettamente ai loro scopi?
7 – Objective-C
Questo stupendo spin-off del C/C++ è il linguaggio di programmazione usato per iPhone e iPad, motivo per cui mi verrebbe la voglia di comprarmi un suddetto dispositivo e programmarci su. L’Objective-C è un estensione ad oggetti del C, come il C++, ma da un punto di vista sintattico rispetto a quest’ultimo sembra più organico e versatile. L’uso nei dispositivi di casa Apple è sicuramente la causa principale del suo successo.
8 – Python
Onestamente il Python me lo immaginavo più alto. Il linguaggio di scripting più famoso e chiacchierato del decennio si ferma a 8 perdendo una posizione rispetto ad un anno fa.
9 – Perl
Perl è un linguaggio che ha perso un po’ di fama e notorietà negli ultimi anni spodestato da linguaggi più complessi e completi come Python. Tuttavia, a livello di script di sistema, ci sono ancora tonnellate di script che utilizzano Perl. Dopotutto la sua integrazione nativa con le espressioni regolari lo rendono adattissimo allo scopo.
10 – Lua
Scalando ben 10 posizioni in un anno Lua arriva dalla ventesima alla decima posizione! Se non conoscete l’esistenza di Lua dopo gli articoli che ho fatto vi picchio! 
Questa è la novità più rilevante del rapporto tant’è che TIOBE gli dedica un approfondimento. Il motivo? Semplice, un anno fa Apple ha deciso di permettere l’esecuzione di Lua su iOS.
11 – JavaScript
Incremento per JavaScript. Il motivo a mio parere può essere solo uno: HTML5. Con i nuovi browser e le meraviglie che si possono fare con HTML5 e JavaScript quest’ultimo ha beneficiato di un notevole interesse da parte della comunità. Ricordo ancora quando il JavaScript veniva dato per morto a causa di Flash e altre tecnologie emergenti ora superate.
12 – Ruby
Ruby è un linguaggio di scripting strano: o lo si ama, o lo si ignora. Questo perché non offre molto più di un Python qualunque ma allo stesso tempo ha una sintassi molto piacevole. Un motivo per cui si mantiene attorno alla dodicesima posizione è la presenza del framework web RubyOnRails.
13 – Delphi/OjectPascal
Lo usavo a undici anni. Poi, ovviamente, è quasi scomparso dalla programmazione mainstream. Comunque, nonostante abbia perso ben 4 posizioni ancora rimane nella top 20. Il motivo per la sua permanenza è comunque storico e legato all’uso aziendale.
14 – Lisp
Questo meraviglioso linguaggio funzionale di “nicchia” è in posizione 14. Ho fatto qualche guida al suo dialetto Scheme che potete trovare nell’archivio di Slashcode.
15 – Pascal
È stupendo notare che un dinosauro dell’informatica come il Pascal sia ancora nella top 20. Il Pascal ha smesso di essere usato come linguaggio didattico già da anni eppure, a quanto pare, l’impatto che ha avuto negli anni 90 è stato talmente elevato che può vivere ancora di rendita.
16 – Assembly
Con Assembly TIOBE aggrega tutti i vari linguaggi macchina. L’uso di tali linguaggi è fondamentale per la programmazione di OS, Driver e altri moduli di bassissimo livello.
17 – Transact-SQL
Transact balza di 4 posizioni ed entra nella top-20. Questo linguaggio è un estensione proprietaria targata Microsoft del classico linguaggio SQL. Tuttavia, a differenza di SQL è Turing completo e quindi può essere considerato linguaggio di programmazione.
18 – RPG (OS/400)
Sale di ben 7 posizioni RPG. RPG è un linguaggio ad alto livello della IBM dalla sintassi scoppiacervello (tenete conto che è un evoluzione di un linguaggio pensato per schede perforate). Onestamente potete ignorarlo e vivrete comunque felici.
19 – Ada
Noto con piacere che un linguaggio dal nome così evocativo sia tornato nella top-20. Ada infatti prende il nome da Ada Lovelace la prima programmatrice del genere umano (ebbene si, era una donna). Ada si ispira molto alla sintassi del Pascal.
20 – Scheme
Dialetto del Lisp. Per cui valgono le stesse considerazioni del suo papà.
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.
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
| © 2008-2012 SlashCode | Suffusion theme by Sayontan Sinha |
Recent Comments