SVILUPPIAMO APPLICAZIONI WEB SORPRENDENTI, CON TECNOLOGIE OPEN-SOURCE

 

 


 

 

TECNOLOGIE OPEN SOURCE

“Ciao a tutti là fuori, sto facendo un sistema operativo libero per 386 (e compatibili) – solo un hobby, non sarà grande e professionale come gnu”, Linus Torvalds

“Una volta scritto GNU, ognuno potrà avere liberamente del buon software di sistema, così come può avere l’aria”, Richard M. Stallman

 

Tecnologie Open SourceLE FONDAMENTA SULLE QUALI COSTRUIAMO LE NOSTRE APPLICAZIONI SONO LE TECNOLOGIEOPEN-SOURCE

Sin dal ’97, per realizzare i nostri sistemi prediligiamo la tecnologia “open source”, ovvero utilizziamo piattaforme, linguaggi e sistemi operativi che vengono distribuiti gratuitamente, liberamente consultabili e modificabili.

Il termine open source si riferisce a qualcosa che può essere modificato perchè il suo design è accessibile pubblicamente.

Sebbene il termine abbia avuto origine nel contesto dello sviluppo software, oggi il termine “open source” designa un insieme di valori. In generale, i progetti, i prodotti e le iniziative open source sono quelli che abbracciano e celebrano uno scambio aperto, una partecipazione collaborativa, la prototipazione rapida, la trasparenza, la meritocrazia, e lo sviluppo comunitario”. [1]

Le tecnologie open-source tipicamente non necessitano di acquisto di licenze per l’uso commerciale, consentendo, quindi, che il costo delle realizzazione di un sistema informativo sia relativo unicamente alla sua complessità funzionale. Internazionalmente riconosciute, esse hanno i loro emblemi nel sistema operativo Linux, nel linguaggio di programmazione Java e nel Apache Software Foundation.

Come pubblicato in [2], questi sono i vantaggi che il codice open source offre rispetto al codice “closed source”:

  • Affidabilità (bug fixing): quando viene individuato un bug in software proprietario, le uniche persone che possono risolvere il problema sono gli sviluppatori originali. Nel software open-source un gran numero di utenti può accedere e modificare il codice, quindi i bug tendono ad essere più visibili e corretti più rapidamente;
  • Personalizzazione: il software open-source può essere personalizzato da chiunque abbia l’abilità necessaria;
  • Multi-lingua: avendo accesso al codice sorgente è facile tradurre in tutte le lingue l’interfaccia software;
  • Evitare lock-in: le organizzazioni si definiscono “locked-in” di prodotti software quando i costi del passaggio ad eventuali alternative risultano proibitivi. Colore che realizzano software proprietario possono “costringere” gli utenti ad utilizzare solamente i loro prodotti, facendo in modo che questi siano difficilmente compatibili con potenziali software rivali;
  • Mitigazione del problema del fallimento del venditore (o della sospensione dell’evoluzione del prodotto): i fornitori di software commerciali possono fallire o essere di volta in volta acquistati da altri. Quando questo accade, non vi è alcuna garanzia che i loro prodotti software continueranno ad essere disponibili, supportati e aggiornati;
  • Imparare dagli esempi: il codice open-source fornisce un’eccellente risorsa da cui imparare;
  • Essere parte di una comunità: quando si adotta il software open-source si diventa parte di una comunità di utenti e sviluppatori che hanno interesse a lavorare insieme per aiutarsi reciprocamente e migliorare il software;
  • Costi: molti programmi open-source possono essere ottenuti senza alcun costo o ad un costo molto basso.

 

 


 

 

VERIFICARE IL SOFTWARE (TEST)

“Il solo criterio che fa avanzare i progetti sono i test”,ELISABETH HENDRICKSON

“Build giornaliere del software sono il minimo”, MARTIN FOWLER

 

Test Driven Development - semaforoTESTARE IL SOFTWARE NON È UNA FASE… … È UNO STILE DI VITA!

Il test del software è il processo di valutazione di un sistema o dei suoi componenti, con l’intento di scoprire se soddisfa o meno i requisiti espressi. Tale attività si traduce nella comparazione tra valore reale prodotto e risultato atteso. In parole semplici un test è l’esecuzione di un sistema al fine di individuare eventuali lacune, errori o requisiti mancanti in contrasto alle reali esigenze.

Secondo lo standard ANSI/IEEE 1059, il testing del software può essere definito come “un processo di analisi di un elemento software per rilevare le differenze tra le condizioni esistenti e richieste (cioè difetti/errori/bug) e per valutare le feature del prodotto software”.

Per quanto tempo si spenda per pianificare e gestire le aspettative, lo sviluppo del software non funziona se non è sostenuto da un solido insieme di pratiche dell’ingegneria del software, come lo unit testing automatizzato. [3]

I test unitari sono piccoli test, a livello di metodo, che gli sviluppatori scrivono ogniqualvolta eseguono una modifica al software, per dimostrare – in primis a se stessi – che i cambiamenti che hanno operato rispettano le aspettative. Un test unitario è quindi un pezzo di codice esattamente come il vero codice, ma non è codice che verrà realmente eseguito in produzione, bensì è codice di test che verifica, che il codice che realizza le feature effettivamente utilizzate dagli utenti, funziona come previsto.

Più alto è il code coverage, “la misura utilizzata per descrivere il grado in cui il codice sorgente di un programma viene testato da un particolare gruppo di test”, minore è la possibilità che il software contenga difetti. [4]

Spot Test Driven Development TechnologiesLAVORANDO CON UN APPROCCIO“TEST-DRIVEN” NON ABBIAMO PAURA DI SVILUPPARE CODICE

Il Test-Driven Development (TDD)è un processo di sviluppo del software che si basa sulla ripetizione di un breve ciclo di sviluppo: in primo luogo lo sviluppatore scrive una suite di test automatizzata (che inizialmente fallisce), che definisce un miglioramento o nuova funzione desiderata, quindi produce una quantità minima di codice per passare questi test, ed infine re-ingegnerizza il nuovo codice per farlo aderire allo standard qualitativo previsto”. [5]

Il Test Driven Development sviluppato e diffuso da Kent Beck, fa parte delle 12 regole alla base dell’Extreme Programming (XP) [6].

In sostanza l’approccio proposto con il TDD consiste in tre semplici passaggi eseguiti ripetutamente:

  • ROSSO: prima di tutto, scriviamo una suite di test che insiste sulla prossima funzionalità che desiderate aggiungere al vostro sistema: ovviamente, il test avrà esito negativo perchè il codice effettivo non è ancora implementato;
  • VERDE: secondo, scriviamo il codice funzionale fino a quando i test non danno esito positivo; a questo punto siamo certi che una nuova piccola funzionalità è stata aggiunta correttamente al sistema;
  • RIFATTORIZZAZIONE: terzo ed ultimo, eseguiamo il refactoring del vecchio e del nuovo codice per renderlo ben strutturato.

spot-ciPRONTI A RILASCIARE SOFTWARE IN PRODUZIONE TUTTI I GIORNI

L’Agile Software Development è costruito da una serie di brevi cicli iterativi. Per ridurre al massimo l’ampiezza delle iterazioni, gli ingegneri del software hanno ideato nel corso degli anni diversi strumenti e best pratices. Tra questi, laContinuous Integration (CI) è senza dubbio essenziale.

Nell’Extreme Programming c’è un detto che afferma che la produzione inizia il primo giorno del progetto. Dal giorno in cui scriviamo la prima riga di codice, trattiamo il progetto come se fosse in produzione […]

Questa nozione di software “sempre pronto per la produzione” porta i team a concepire ogni modifica che si intende attuare, come applicata, sempre, ad un sistema in produzione, piuttosto che considerare il rilascio del software ed il suo esercizio un evento lontano nel futuro.

La Continuous Integration (CI) è l’atto di prendere, in maniera continuativa, le modifiche apportate al software dagli sviluppatori ed integrarle assieme ininterrottamente durtante tutta la giornata” – Jonathan Rasmusson, “The Agile Samurai” [7].

Come pubblicato in [8] da Martin Fowler, ci sono diverse attività necessarie per a funzionare, in modo automatizzato, una build giornaliera:

  • Mantenere tutto il codice sorgente in un sol luogo (source repository), a cui chiunque può accedere per ottenerne la versione più recente (e quelle precedenti);
  • Automatizzare il processo di compilazione e “impacchettamento”, in modo che a chiunque basti utilizzare un unico, semplice comando per costruire il sistema, partendo dai sorgenti;
  • Automatizzare i test in modo da poter eseguire, in qualsiasi momento e con un unico comando, una suite di test completa sul sistema;
  • Assicurarsi che chiunque può ottenere l’ultima versione eseguibile, di cui si è certi essere al momento quella migliore.

Il beneficio fondamentale derivante dalla Continuous Integration è la rimozione di sessioni durante le quali le persone trascorrono il loro tempo a caccia di bug, che si verificano quando il lavoro fatto da una persona si sovrappone a quello fatto qualcun altro, senza che nessuno dei due si renda conto di quello che è successo.

 

 


 

 

RILASCIO CONTINUO

“Una tematica comunemente affrontata nei nostri progetti è la riduzione del tempo che intercorre tra un’idea ed un software utilizzabile”, MARTIN FOWLER

“Quanto impiega la vostra organizzazione per distribuire una modifica al software che coinvolge una sola singola linea di codice? Lo fate in modo affidabile e ripetibile?”, MARY and TOM POPPENDIECK

 

Ciclo di deliveryIL SOFTWARE NON FORNISCE ALCUN BENEFICIO FINTANTOCHÈ NON VIENE RILASCIATO AI SUOI UTENTI

In molte organizzazioni, il “cycle time” viene misurato in mesi o addirittura semestri. Per cicle time si intende il tempo che si intercorre tra l’attimo in cui si comprende di aver bisogno di qualcosa di nuovo e quando questo è effettivamente in produzione.

Solitamente i nostri team effettuano rilasci in produzione ogni 2 settimane, che diventano anche giornalieri quando l’applicazione entra nella fase di mantenutenzione evolutiva (application maintenance).

La Continuous Delivery (CD) è un’altra pratica essenziale per le società che intendono abbracciare l’Agile Software Development. Ancora una volta, la chiave è l’automazione.

Con la CD rilasciare diventa routine: questo è possibile grazie all’introduzione di un processo completamente automatizzato, ripetibile ed affidabile, attraverso il quale si applicano i cambiamenti nelle varie fasi di sviluppo del software (compilazione, installazione, testing e rilascio). […]

La precondizione per attuare la CD, almeno per il team di sviluppo, è la Continuous Integration. La Continuous Integration mantiene sincronizzato tutto il team di sviluppo, rimuovendo i ritardi dovuti a problemi di integrazione. Tuttavia, la Continuous Integration rappresenta solamente il primo passo: il software che è stato integrato con successo in una stream non è ancora un software rilasciato produzione che sta facendo il suo lavoro. […] La CD automatizza l’ultimo miglio, quello in cui il codice integrato si trasforma in software in produzione.” – Martin Fowler, “Continuous Delivery” [9].

Come pubblicato in [10], un rilascio regolare offre al business i seguenti vantaggi:

  • Costruzione del prodotto corretto: la CD consente al team di ottenere feedback continui dai colleghi del reparto business, da coloro che rappresentano gli utenti, e idealmente direttamente dai veri utenti finali;
  • Anticipo dei benefici: anticipare quanto prima possibile i benefici attesi può implicare la generazione di nuove entrate, o una riduzione dei costi;
  • Capacità di reagire rapidamente e rispondere al cambiamento: la CD permette di reagire ai cambiamenti, limitando al massimo la quantità di tempo e denaro investita sul lavoro “in progress”;
  • Innovazione: combinando la CD con frequenti feedback da parte degli utenti, è possibile avere gli sviluppatori più che mai vicini ai clienti e utenti finali, creandosi in questo modo le opportunità per fare innovazione;
  • Affidabilità e stabilità: apportare delle modifiche per passi incrementali molto piccoli riduce significativamente il rischio che si verifichino problemi e, qualora accadano, rende decisamente più semplice individuarli e correggerli, riducendo così al minimo il tempo durante il quale questi hanno un impatto sul sistema;
  • Più efficienza e risparmio di tempo: la CD porta con sè molta efficienza e permette al team di risparmiare molto tempo, che può quindi essere speso per sviluppare nuove significative feature per gli utenti, fornendo in definitiva più valore di business;
  • Impatto strategico: quale impresa non vorrebbe disporre di tutti i benefici sin qui elencati? Per questo motivo la CD deve essere considerata una questione fondamentale non solo per gli sviluppatori, ma anche e soprattutto per la direzione, che la deve annoverare tra le questioni di business di importanza critica.

Infine, va considerato che l’approccio “una consegna per anno” crea un divario tra sviluppatori e team operativi e che, al contrario, la CD lavora per unire queste due squadre – un precursore del crescente movimento DevOps. [11]

 

 


 
CITATIONS:

REFERENCES

1. https://opensource.com/resources/what-open-source
2. http://oss-watch.ac.uk/resources/whoneedssource
3. http://it.wikipedia.org/wiki/Unit_testing
4. http://en.wikipedia.org/wiki/Code_coverage
5. http://it.wikipedia.org/wiki/Test_Driven_Development
6. http://www.extremeprogramming.org/rules/testfirst.html
7. http://pragprog.com/book/jtrap/the-agile-samurai
8. http://martinfowler.com/articles/originalContinuousIntegration.html
9. http://martinfowler.com/books/continuousDelivery.html
10. http://www.allaboutagile.com/7-reasons-why-continuous-delivery-needs-to-be-a-business-initiative
11. http://it.wikipedia.org/wiki/Devops