Mai come in questo periodo mi sono trovato a scrivere codice e leggere codice (il mio e quello degli altri). Ho dovuto rimettere mano a vecchio codice prodotto, a piccole librerie create in passato (che a distanza di anni non valuto certo con voti altissimi). Mi sono ritrovato a confrontare un vecchio lavoro con quelli attuali, notando incredibili differenze in fatto di qualità del codice, prima ancora delle qualità delle conosocenze. A quel punto è stato facile derivare un paio di fattori chiave che potrebbero distinguere un buon programmatore da un ottimo programmatore, in attesa di capire la categoria nella quale sistemarmi. Sperando di poter regalare al lettore qualche utile consiglio.

1. Documentare il codice

Scrivere chiari e precisi commenti è impagabile. Permettono di leggere più facilmente il codice senza impazzire dietro ad algoritmi o funzioni o parametri conditi di mistero e di cui se ne disconosce la funzione, il significato e il motivo della loro esistenza. Gli stessi commenti devono essere scritti con coscienza, senza badare troppo alla forma magari, ma senza rinunciare a una certa formalità e un certo stile. Bisogna cercare di essere sempre chiari nelle spiegazioni e di non dare nulla per scontato. Prolissi e completi quando è rischiesto dal contesto, concisi quando è inutile divagare o spiegare cose ovvie e facilmente deducibili. Quando a distanza di tempo ci toccherà rimettere mano a un codice che abbiamo scritto di nostro pugno e di cui non ricordiamo molto, una veloce lettura dei commenti ci permette in pochi secondi di ritornare nella dimensione di quel progetto. Una buona documentazione del codice permette un alto livello di maintainability dello stesso. Nel caso, poi, ci fosse la necessità di collaborare con altri sviluppatori, il non dover chiedere costantemente chiarimenti su una funzione o un parametro permette di velocizzare il lavoro e migliorarlo sotto tutti i punti di vista, in quanto troveremo tutte le risposte dentro i commenti.

E’ possibile, in ultimo, estrarre dal codice sorgente i commenti formattati in un certo modo e produrre così un manuale per gli sviluppatori o una reference. Tutto in modo automatico ed evitando un doppio e tedioso lavoro. Uno strumento molto apprezzato, in tale contesto, è phpDoc (facile immagine per quale linguaggio).

Ultima raccomandazione, che a molti potrà suonare strana o esagerata. Se pensate che il vostro codice possa essere degno del panorama internazionale, cioè di un pubblico non solo italiano, allora è bene cominciare a prendere confidenza con l’inglese-scritto e commentare il codice in questa lingua.

2. Scrivere buon codice

E’ difficile in poche righe capire cosa significa “scrivere buon codice”, ma ci provo. Fra l’altro è una delle prime cose che uno studente si sente dire da un buon professore. Il pieno significato di un simile avvertimento dal sapore di consiglio lo si coglie solo quando si lavora seriamente a qualche progetto. O quando ci si confronterà con altri sviluppatori. Scrivere buon codice significa scrivere i nomi delle funzioni scegliendo i migliori termini, i più espressivi in assoluto. Conviene eliminare inutili abbreviazioni, solo per risparmiare qualche carattere e guadagnare qualche decimo di secondo in più sulla digitazione. Significa scrivere un codice la cui sola lettura è bastevole per capirne l’implementazione. Generalmente una funzione chilometrica è sintomo di scarsa progettazione del codice, il che non vuol dire che poi le cose non funzionano. La migliore palestra, in tal senso, è la lettura di codice dei migliori programmatori che potete trovare in rete e l’analisi di progetti dal codice aperto.

3. Framework e librerie

Spesso ci si trova a riscrivere del codice che in realtà esiste già e probabilmente risulta più completo del nostro, oltre che più efficace. Pertanto prima di buttarsi a capofitto nella scrittura di nuove classi occorre capire cosa offre Internet. Esistono diversi utilissimi siti dove poter trovare del buon codice (citiamo su tutti Sourceforge). Ed esiste Google per cercare eventuali librerie già pronte per essere usate nei nostri progetti. Se nulla ci soddisfa allora non resta che scrivere quanto abbiamo di bisogno. Se abbiamo intrapreso quest’ultima strada è buona cosa pensare non al progetto in sé, quanto piuttosto ai problemi generali che intendiamo risolvere. E’ questo infatti il caso migliore per pensare a una libreria riutilizzabile pure in altri progetti. Se poi siamo soliti lavorare su applicazioni che in qualche modo hanno molte somiglianze fra di loro, beh allora conviene pensare a qualche framework. Generalmente una grande società di software ne progetta uno e provvede a usarlo nei vari lavori. Uno sviluppatore indipendente può lanciare a se stesso la stuzzicante sfida di costruirne uno nuovo, o studiare per bene un framework esistente.

In tal senso un buon framework (Rails per i programmatori Ruby, Zend o Symfony per i programmatori PHP, Django per gli appassionati di Python) potrebbe essere una ottima base per sviluppare una grande applicazione. Ma occorre valutare per bene ogni fattore. Spesso un framework rischia di appesantire lo sviluppo e se non riusciamo ad ottimizzarne la configurazione rischiamo pure di ottenere un prodotto dalle scarse performance. E’ opportuno inoltre non focalizzarsi soltanto su un prodotto, ma studiarne più di uno per capire realmente benefici e svantaggi di ognuno di loro. A quel punto, e solo a quel punto, conviene sceglierne uno e provare a padroneggiarlo al meglio. In altre parole: non limitarsi a leggere qualche articolo su Internet (raramente ho scovato delle analisi pienamente oggettive sui software e sui framework), ma sperimentare le soluzioni. Quindi specializzarsi su un prodotto.

4. Standard e best practices

I design pattern vanno studiati, compresi e quindi usati. Spesso ci si accorge che bravi programmatori li disconoscono ed è un male. Pattern quali MVC offrono una potenza incredibile. E numerosi altri pattern offrono una soluzione ottimale a ricorrenti problemi per quanto riguarda la programmazione (che è poi la definizione di Design Pattern).

Quando parliamo di best practices ci riferiamo a delle esperienze che altri hanno già maturato in qualche settore professionale e nelle quali hanno raggiunto ottimi risultati. Potete pensare a delle regole generali, più o meno formalizzate, o a degli esempi opportunamente descritti e commentati. Per quanto mi riguarda mi sono stati utilissimi i libri di ingegneria del software che ho letto e sui quali ho trovato diversi riferimenti a ulteriori libri e articoli. Potete recuperare su internet diverse interviste a eminenti sviluppatori che raccontano le loro esperienze e le loro idee.

5. Pensare. Poi scrivere codice

Lontano da una schermo e una tastiera si riesce meglio a programmare. Sembra un paradosso, invece è la pura realtà. Provate a pensare alla vostra architettura fuori da una finestra di Mac o di Windows o di Linux. Fogli di carta, penna, matita e idee. Non è tempo sprecato, anzi tutto il contrario. Uno schermo con icone e testo, una tastiera e un mouse possono risultare degli elementi destabilizzanti e di distrazione. Si è tentati di scrivere subito del codice funzionante, salvo poi scoprire che una funzione poteva essere scritta meglio, o un insieme di classi poteva essere progettato in modo più intelligente. A quel punto tornare indietro è complicato. Rifattorizzare equivale a partire da zero (e a un livello iniziale non si parla certo di refactoring) e, si realizzerà con estremo rammarico, di aver buttato via preziose ore di lavoro.

Ponderare bene le scelte: tracciare diagrammi, appuntare note e idee, provare a scrivere un piano di sviluppo. Anche senza badare alla forma, una sorta di brainstorming solitario. Fate una lista dei problemi da risolvere, delle possibili soluzioni cui avete pensato e, dopo una pausa lontano da tutti e tutto, rileggete con attenzione quanto avete scritto e cercate di capire se è l’ora di mettersi a scrivere codice o conviene dedicare ancora qualche minuto a questa meditazione pre-sviluppo.

Non esiste un libro delle soluzioni in informatica. Esiste però una quantità smisurata di handle di soluzioni. Queste maniglie altro non sono che il codice e gli applicativi che altri programmatori hanno già realizzato e rilasciato. Dare uno sguardo all’interno del codice scritto da terzi (e dovete ovviamente scegliere i migliori terzi, perché conviene imparare soltanto dai migliori) si rivelerà presto preziosa lettura e fonte di soluzioni. Il che non vuol dire che dovete copiare, ma certamente ispirarvi. O, più umilmente, imparare.

Voglio Joomla! E’ la richiesta espressa da un cliente. I colloqui iniziali sono molto interessanti e mi aiutano a capire molto della persona che ho di fronte, più che del committente. Si ragiona, si discute e, se si può, si opera direttamente a computer. La gente tende a usare quello che conosce e il cambiamento non è contemplato. Questo però vale solo per le persone testarde e poco informate, o per le persone stupide. Sebbene sia una cosa normale affidarsi a quanto già si conosce, è bene pure prendere in considerazione quanto ti viene detto da gente esperta, o quanto meno più esperta di te. Ragionevolmente si riesce sempre a fare un bilancio dello stato dell’arte e se, tu sviluppatore, riesci bene a giocarti la carta del convincimento-per-fatti allora il discorso può continuare in modo proficuo e si riesce a lavorare davvero molto bene. Durante l’ultimo incontro è saltata fuori una domanda: “ok, che CMS mi suggerisci?”. Rispondere non è semplice perché la situazione va studiata a fondo e quindi bisognerà adattare un prodotto già esistente o costruire un applicativo ex-novo (problema del make or buy, presente in tutti i libri di testo di Ingegneria del Software). Prima che riuscissi a rispondere mi viene detto “che ne pensi di Silverstripe?”. Lo confesso, non lo conoscevo, avendone sentito parlare soltanto su questo post. Ho bluffato e ci siamo promessi di fissare un nuovo incontro per andare più a fondo. Intanto però, ho provato Silverstripe.

E’ un CMS molto interessante. Il fatto che abbia vinto il Most Promising Open Source CMS di per sé non dice nulla, oppure può dire tanto. E’ leggero e senza fronzoli, con un numero discreto di plugin e template (certo non l’esercito di materiale a disposizione per Joomla o WordPress, tanto per citare due concorrenti). La cosa più stimolante di Silverstripe è Sapphire, il framework usato per costruirlo e che ogni sviluppatore dovrebbe studiare per estendere l’applicazione. Il framework, interamente implementato in PHP versione 5, è davvero ben fatto e consente di modellare in lungo e largo Silverstripe adattandolo al problema. Dentro trovate un po’ di tutto, ovviamente ORM e MVC. Assolutamente da provare.

Lo sviluppo di software è un’arte e come tale viene insegnata nei corsi universitari; poi però l’ambiente di produzione reale è leggermente diverso. Benché le nozioni rimangano inalterate, nella sostanza dei fatti a uno sviluppatore viene richiesto anche altro, pur avendo come obiettivo primario costruire un prodotto efficace e potente. Ciò vale pure per sviluppatori che lavorano in proprio. Quell’altro cui accennavo prima è la rapidità con la quale si riesce a completare la scrittura del codice. Nel mondo informatico di oggi, così frenetico e dove il tempo non presenta mai pause, la velocità di produzione è una caratteristica spesso determinante.

Sembrerebbe una introduzione avulsa dal testo che tratta di Django e fondamentalmente di Python, invece quanto detto ha molta attinenza con l’argomento del libro di Holovaty e Kaplan-Moss. Alla base della creazione di Django c’è infatti quanto espresso nelle primissime righe di questa recensione: arte, potenza e velocità. Le prime due caratteristiche sembrano discendere direttamente dal linguaggio di riferimento e cioè Python. Molto si è detto e molto si è scritto su questo favoloso strumento e recentemente abbiamo pure recensito uno dei migliori libri in circolazione.

[...]

In definitiva il libro di Holovaty e Kaplan-Moss è certamente la prima fonte di informazioni per chi intende approcciarsi a Django. Lo stile è di quelli che permettono al lettore di iniziare subito a sperimentare, senza noiose e interminabili letture, alla fine delle quali spesso ci si dimentica di nozioni e dettagli. Manca all’interno del testo un progetto completo, ma a conti fatti non mi sembra un punto a sfavore. D’altra parte il libro risulta particolarmente prezioso anche quando bisogna velocemente rivedere qualche dettaglio di implementazione. Il testo si riferisce alla versione 1.1 del framework.

[Via Programmazione.it]

Come si costruiscono applicazioni web potenti? E magari di pari valore a quelle desktop e tradizionali? Generalmente la risposta a queste domande fa uso di qualche buon framework che permetta di risolvere comodamente tutta una serie di compiti. SproutCore è molto potente. Supporta HTML5 e costruisce codice Javascript che renderà il nostro prodotto funzionante e performante. La Apple lo ha scelto recentemente per sviluppare la parte online di iWork e MobileMe. Una sicurezza.

SproutCore non è una semplice libreria al pari di jQuery o Prototype, ma di qualcosa di diverso e di ancora più potente: lo sviluppatore potrà gestire eventi complessi come per le applicazioni desktop. Per il salvataggio dei dati lato server il framework fa uso di chiamate AJAX.

[Via Programmazione.it]

Un’idea tutta italiana. Un framework che ha la parvenza di essere molto di più. Orientato al Web, sfrutta le recenti tecnologie in ambito Internet per offrire un supporto potente per quanti vogliono costruire la propria web-application. Di qualunque genere e complessità. Ne avevo già parlato in un recente articolo, ma la curiosità non si è esaurita. Così mi sono tuffato sul sito ufficiale alla ricerca di quanto più materiale possibile. Alla fine ho deciso di fare la cosa che mi è sembrata più logica: tributare gli autori di JAMP con una intervista.

Non posso non partire dalla presentazione iniziale. Non facco fatica a nascondervi il mio stupore quando ho scoperto il team che sta dietro a JAMP. Mi aspettavo una lunga lista, alla luce dello sforzo incredibile che sta dietro questo progetto, invece ho appuntato due soli nomi. Da chi è composto, allora, il team di JAMP? Qual è il vostro background e quale il vostro lavoro?

I fondatori e sviluppatori di JAMP siamo Ruben Patanè e Giampiero Ancilletta. E’ comunque corretto da parte nostra ringrazie le molte persone che nel corso della nostra avventura ci hanno dato e continuano a darci una mano in consigli, segnalazioni bug e supporto morale che non guasta mai.

Ruben: fino a 19 anni ho vissuto a Torino dove mi sono diplomato perito elettronico, ho iniziato come sistemista presso il Ministero di Grazia e Giustizia e da sempre sono stato uno sviluppatore indipendente, da circa otto anni lavoro presso STMicroelectronics di Catania.

Giampiero: ho conseguito il diploma di perito informatico e poi la laurea di primo livello in ingegneria elettronica, dopo pochi mesi ho iniziato a lavorare come programmatore nell’ambito dei sistemi informativi. Dal 2004 lavoro presso la STMicroelectronics sede di Catania ramo IT.

Nel 2006 Io e Ruben abbiamo fondato l’ ALYX SOFTWARE INNOVATION, azienda che si occupava di programmazione e configurazione di reti e servizi nell’ambito dell’open source. Infine, da circa un’anno e mezzo è nata l’avventura di JAMP.

In poche righe ho cercato di sintetizzare quello che JAMP rappresenta, sicuramente voi farete meglio. Quindi: cosa è JAMP? Cosa si può fare con la vostra creatura e perchè uno sviluppatore dovrebbe decidere di scaricare il vostro codice e studiarne l’accurata documentazione?

JAMP è una struttura a supporto dello sviluppo di applicazioni web. Lo scopo principale del framework è in generale quello che hanno, o dovrebbero avere, tutti i framework: fornire classi e metodi avanzati per facilitare il lavoro di programmazione, riducendo di conseguenza tempi e costi di produzione, ma anche quello di offrire delle soluzioni più robuste grazie alla risoluzione di problematiche comuni. In alcuni casi abbiamo potuto constatare che si può arrivare a risparmiare circa l’80% del codice necessario a scrivere un’applicazione. Ci sono altre importanti caratteristiche che JAMP pensiamo possieda e non sempre sono contenute negli altri framework, o almeno non tutte insieme:

1. Flessibilità: un elevato livello di flessibilità data dal fatto che lo sviluppatore ha la possibilità di aggiungere liberamente il proprio codice PHP e JavaScript. Naturalmente la massima utilità nell’utilizzo del framework la si ottiene quando si utilizzano le funzionalità automatiche che il framework offre oppure interagendo con le funzioni già esistenti.
2. Facile: un aspetto che ci viene spesso riconosciuto da molti utenti e che spesso porta a sceglire JAMP è sicuramente la sua facilità di apprendimento unita ad una discreta documentazione. Questo dà modo anche ad utenti meno esperti di avvicinarsi al framework ma permette anche ad utenti più esperti di avere maggior cognizione e controllo delle operazioni svolte dal framework.
3. Modulare: ogni oggetto svolge un determinato compito. Questo ha permesso facili integrazioni di nuove funzionalità.
4. Performance: le applicazioni sviluppate con JAMP non risentono della presenza del framework, cosa che invece spesso accade in altri framework i quali non sempre puntano all’ottimizzazione del codice necessario e ciò rallenta l’esecuzione dell’applicazione.
5. Licenza libera: JAMP è distributito con licenza GPL e quindi si ha la completa libertà di analizzare e/o modificare il codice.

Non si arriva a sviluppare un codice di simile portata senza una causa scatenante. Cosa vi ha spinto ad accettare questa sfida?

JAMP nasce innanzitutto da una nostra esigenza di programmatori. Volevamo un valido strumento per poter sviluppare in maniera veloce e robusta applicazioni web.

Nel corso della nostra carriera abbiamo provato diversi framework, ma sfortunatamente – o fortunatamente, dipende dai punti di vista – non ne abbiamo mai trovato uno che realmente ci soddisfacesse e quindi abbiamo deciso di scriverlo noi.

Nel momento in cui ho preparato questa intervista, l’homepage di JAMP recitava questo numero: 8877. Sono le ore che sono servite per costruire JAMP, con tutte le attività connesse alla semplice scrittura del codice ovviamente. Quante energie sono servite per sviluppare JAMP? Quante ne servono per continuarne lo sviluppo? Inoltre, quale è il vostro modello di lavoro? E come organizzate le vostre giornate?

Sicuramente le energie e gli sforzi messi in campo sono stato notevoli perchè, come ricordavi tu, il lavoro è stato svolto da due sole persone. Da sottolineare che JAMP lo abbiamo sviluppato al di fuori del nostro normale orario di lavoro.

Nel corso di questi circa 18 mesi dalla nascita di JAMP ci piace ricordare che oltre al framework, alla documentazione, al sito, al forum e alla partecipazione ad eventi, abbiamo parallelamente sviluppato diverse applicazioni come jpresenze, jfood e jestionale che vengono regolarmente utilizzate da nostri clienti. Tali applicazioni da un lato sono state utili per trovare spunti e testare le funzionalità del framwework, dall’altro sono servite per dimostrare che è possibile sviluppare applicazione complete. Probabilmente infatti, se non avessimo avuto JAMP a supporto avremmo speso questi 18 mesi solo per sviluppare tali applicazioni.

Non esiste un modello di lavoro o di organizzazione della giornata: tutto è lasciato libero per dar spazio alla creatività. Le ore presenti nel sito hanno valore indicativo, in realtà possono esserci giorni in cui dedichiamo un’ora al progetto, altri molte di più. Ammetto che il fatto di essere stati solo in due a sviluppare il framework ha avuto almeno il vantaggio di aver facilitato molto il lavoro di coordinamento. Adesso però che la struttura di JAMP è più matura desideriamo coinvolgere sempre più persone in modo da far evolvere il progetto.

Ogni sviluppatore si affeziona nel corso della sua vita professionale a determinati ambienti e strumenti. Quali sono i vostri software preferiti? E quali servizi web usate a supporto di JAMP?

I software che utilizziamo sono molti e tutti quasi esclusivamente open source. Operiamo in ambiente Linux, testare il funzionamento di JAMP in altre piattaforme  preferiamo usare Virtual Box e le sue macchine virtuali. Per ospitare il sito di JAMP utilizziamo un normale servizio di hosting. Per lo sviluppo abbiamo un nostro server dedicato nel quale installiamo un pò di tutto in base all’occorenza: alcuni servizi base sono sicuramente la connessione ssh con chiave pubblica, apache, php, mysql, ldap.

Avendo una passione sfrenata per il movimento del software libero non ho potuto che apprezzare la scelta di rilasciare JAMP sotto licenza GPL. A quanti ancora faticano a comprendere un simile pensiero, potreste spiegare le motivazioni che vi hanno spinto a condividere i principi del free software?

Nel corso della nostra vita di programmatori la vera crescita professionale la si ottiene grazie all’analisi di software scritto da programmatori esperti. Questo è possibile quando chi sviluppa il proprio codice decide di renderlo pubblico ed accessibile a tutti. Per noi è stato così e dunque  la scelta di rilasciare JAMP con licenza GPL ci è sembrata scontata.

Ringraziandovi per il tempo che mi avete dedicato e augurandovi le migliori fortune, chiudo questa piacevole chiacchierata con quest’ultima domanda: cosa volete fare da grandi? E quali novità dobbiamo aspettarci da JAMP?

Quando abbiamo inziato il progetto JAMP avevamo tre sogni nel cassetto: creare un framework web utile a noi e ad altri programmatori, generare interesse verso il nostro prodotto attirando l’attenzione di professionisti ed aziende del settore, infine creare l’associazione ALYX aperta a tutti coloro che amassero la programmazione ed il software libero. I primi due desideri si sono già realizzati e adesso stiamo lavorando affinché lo sia anche il terzo.

Ti ringraziamo per l’intervista e per l’importante lavoro di informazione che svolgi.

Il progetto è assolutamente interessante, l’implementazione mi pare pure buona. Ho dato uno sguardo sommario e letta la documentazione. Un grande sforzo, una grande idea tutta italiana.

Tecnicamente JAMP è un framework per sviluppare applicazioni web, sfruttando quindi le attuali tecnologie che hanno reso grande Internet. Nella pratica, JAMP è anche qualcosa di più: è un vero e proprio ambiente di sviluppo, completo e potente; fornisce tutti gli strumenti essenziali per costruire la nostra applicazione, di qualunque genere e complessità essa sia.

JAMP è perfettamente compatibile con i maggiori browser oggi in commercio; oltre a essere multipiattaforma JAMP porta con sé il grande pregio di non richiedere alcuna forma di installazione. Basta infatti scaricare il package dal sito ufficiale e scompattarlo nella root del nostro server per iniziare lo sviluppo.

[Via Programmazione.it]

Se qualcuno l’ha usato in progetti seri mi faccia uno squillo!