Continuous Integration con Code Coverage e Code Quality, gratis. Troppo bello per essere vero.

travis_codecov_codacySpesso capita di vedere, ancora oggi, lo sviluppo del software affidato a sistemi di versioning (per così dire) del tutto improvvisati come una cartella di rete dove sono depositati una serie di eseguibili con nomi nel rango di:

  • application.jar, 2014/05/01 12:00
  • application_FIX.jar, 2014/05/02 12:30
  • application_FIX_NON_TOCCARE.jar, 2014/05/02 12:31
  • application_FIX_PRODUZIONE_PORCA_PUTT.jar, 2014/05/03 03:31

Da questo si evince anche che la prassi di testing, in questo caso, è:

Fai il deploy in produzione e vedi che succede

Analizziamo un attimo ciò che sembra essere successo in questo caso.

application.jar è stata ultimata e nemmeno mezz’ora dopo abbiamo già un nuovo deploy per un qualche bug, nemmeno un minuto dopo ecco una nuova versione FIX_NON_TOCCARE, evidentemente il fix ha introdotto una regressione, prontamente sistemata. Successivamente alle tre e passa del mattino capita il classico “fix in produzione”. Alzi la mano chi non si è mai trovato in scenari simili. A me personalmente è capitato diverse volte in passato.

Cosa è successo qui? Andiamo per ordine:

  • il primo fix è sintomo di un qualche corner case non individuato in precedenza o anche semplicemente una svista.
  • il fix FIX_NON_TOCCARE è sintomo di mancanza di test (JUnit ad esempio) perchè il fix precedente ha semplicemente rotto i contratti o la business logic.
  • per ultimo, il FIX_PRODUZIONE_PORCA_PUTT capita spesso a causa di test d’integrazione deboli, se non del tutto assenti, con i componenti che poi interagiscono in produzione.

Come possiamo ovviare, o almeno mitigare, tutti i rischi di questo ciclo?

  • Versioning prima di tutto usando SVN, Git, CVS o chi per esso.
  • test unitari e comportamentali durante lo sviluppo, in ambito Java possono essere JUnit e JBehave ad esempio.
  • Continuous Integration, con questi sistemi (ad. es. Jenkins) siamo sicuri che il codice introdotto ad ogni merge non “rompa” la build.
  • Test Coverage per assicurarci che i test coprano correttamente il codice.
  • Code Quality, spesso una semplice analisi statica del codebase è sufficiente per inviduare bug, bad practices o peggio, come ad esempio risorse non rilasciate o flussi di controllo che portano a stati instabili.

Versioning

Non mi addentrerò in modo particolare su questo tema, in rete è disponibile una vasta pletora di articoli, tra i miei preferiti riporto questo. In breve si tratta di usare le rame di feature per le nuove funzionalità. Quando queste vengono ultimate si esegue un merge verso “develop” (preferibilmente con pull request e code review) per poi finalmente far confluire tutti i cambi di develop a “master” e poter così procedere ad una release di una nuova versione.

Testing

Inizialmente scrivere i test unitari può sembrare una sciocchezza. Perchè scrivere un test di un POJO che ad esempio non può accettare un parametro con valore null? È ovvio che non arriverà mai null e nel resto dei componenti farò in modo che non accada mai.

Tutto vero, fino a quando non succede. A volte può succedere perchè non si sono individuati tutti i corner case in fase di stesura del test, altre volte può succedere perchè cambiano le condizioni al contorno quali, ad esempio, il cambio dell’ora legale in un server remoto.

Un altro grosso vantaggio dei test è quando si riprende in mano una codebase per estenderla a distanza di settimane se non mesi. Dopo tutto quel tempo è difficile introdurre cambi e spesso si finisce per rompere funzionalità già esistenti, introducendo quello che in gergo di ingegneria del software si chiama “regressione”.

Un valido punto di partenza per TDD (Test Driven Development) e BDD (Behavioural Driven Development) è lo stub di wikipedia.

Per quanto riguarda il test coverage, in ambito Java, abbiamo vari plugin maven, uno su tutti è Jacoco. Spesso anche gli IDE consentono di valutare la copertura del codice.

Continuous Integration

Il modello di sviluppo con Git, dove ciascun sviluppatore lavora nella propria rama, fa in modo che si possa parallelizare il più possibile lo sviluppo. Successivamente i cambi verranno integrati (attraverso il merge) in una singola branch (develop). Qui viene in aiuto il Continuous Integration (CI).

Il grosso vantaggio del CI è quello che ci evita portarci in locale i cambi delle altre branch in locale per eseguire una build (ad. es. con maven), se invece portiamo tutti i cambi in una singola branch il CI si occuperà di eseguire tutti i test (ed i cambi della codebase) che le varie branch si portano dietro. Nel caso i test siano tutti ok (green in gergo) si può anche procedere successivamente a migrare la rama master con develop e rilasciare una nuova versione (release) con tutti i cambi.

Normalmente per avere un CI è necessario avere in loco una istanza di Jenkins o simili. Oggi però abbiamo anche servizi sulla nuvola e persino free per codice open source quali ad esempio Travis CI. Per una carrellata di altri servizi si può partire da GitHub.

L’utilizzo di Travis è veramente semplice. Si tratta di loggarsi con la propria utenza GitHub ed aggiungere i repo che si vogliono includere nel ciclo di continuous integration. Per questo è sufficiente copiare un file di nome .travis.yml:

sudo: false
language: java
jdk:
  - oraclejdk8

A questo punto basta un commit e push del proprio branch per vedere i risultati nelle console di travis. L’esempio sopra informa travis semplicemente che il linguaggio è java e che va usato l’Oracle JDK.

Tests run: 25, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- jacoco-maven-plugin:0.7.5.201505241946:report (report) @ life-game ---
[INFO] Analyzed bundle 'life-game' with 18 classes
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.086 s
[INFO] Finished at: 2015-12-27T19:38:51+00:00
[INFO] Final Memory: 19M/344M
[INFO] ------------------------------------------------------------------------

Travis offre molte opzioni di configurazione per l’esecuzione dei test, possiamo avere ad esempio un’istanza mysql, un virtual framebuffer per le applicazioni con GUI e persino firefox se si vogliono svolgere frontend test con selenium. La documentazione è ricchissima e vi invito a leggerla. RTFM, sempre. 🙂

Code Coverage

Come detto prima ci sono molti tool che consentono di valutare la copertura dei test, sia in fase di build che dentro il proprio IDE. Alcuni tool però ci consentono di andare un po’ oltre e producono analisi e suggerimenti su dove intervenire.

Uno di questi strumenti, del tutto gratuito per software open source, è Codecov. Come per Travis CI l’installazione è triviale. Si tratta di collegarsi con il proprio profilo di GitHub e associare i vari repo e successivamente potremo avere i report sul code coverage dopo ogni commit o durante una pull request verso master o develop. Qui vediamo alcune schermate:

codecovcodecov_suggPer far si che il codice sia analizzato basta aggiungere qualche riga al nostro .travis.yml:

sudo: false
language: java

jdk:
  - oraclejdk8

before_script:
  - pip install --user codecov

after_success:
  - codecov

Una feature molto pratica è che codecov-io inserisce un commento in fase di pull request indicando i cambi nel code coverage per la PR. Qui vediamo un merge particolarmente riuscito 🙂

codecov_commentQuesti due tool, di per se, sono già un validissimo complemento per evitare lo scenario iniziale ma ci resta ancora un’arma.

Code Quality e Code Review

Tutti commettiamo errori mentre programmiamo, nessuno escluso. In questo molti compilatori ci aiutano con analisi statiche del codice direttamente dall’IDE o con strumenti esterni come FindBugs o il sempre verde SonarQube.

Ma oltre a commettere errori a volte siamo anche distratti e ci dimentichiamo di eseguire un check. Altre volte il tempo non ci permette di analizzare il codice e altre volte ancora gli errori arrivano a develop perché non si fanno le code review per mille ragioni, spesso per motivi di tempo, è sempre difficile concordare con il management uno slot di tempo dove chiudere quattro developer in una stanza per una code review. I developer vedono un’ora, un manager vede 4 ore/uomo “sprecate”.

In ogni caso, per chi non vuole limitarsi alla semplice analisi statica del codice dall’IDE (che comunque spesso trascura molti errori ovvi) ci sono strumenti che ci consentono di scrutinare il nostro codebase in maniera automatica ed asincrona. Per il momento mi sto affidando a Codacy.

Ancora una volta la configurazione è abbastanza triviale, si tratta di loggarsi con il proprio profilo di GitHub e iniziare ad associare i repo che si vogliono analizzare.codacyPer ogni repo possiamo configurare parametri quali tipi di issue da ignorare, altre da abilitare, cartelle da trascurare (ad esempio non vogliamo “inquinare” i nostri risultati con i problemi di altre librerie quali bootstrap, jquery, etc).

Anche qui possiamo vedere tutta una serie di statistiche per ogni commit, quali file sorgente presentano problemi e persino ottenere un “voto” (come a scuola) 🙂 per ciascun repo fino all’atomicità di un voto per commit.

codacy_commitConclusioni

Abbiamo visto una veloce carrellata di strumenti che consentono di migliorare notevolmente il processo e la qualità del codice, tutto con strumenti gratuiti e online, senza quindi dover installare server o software (oltre a git!) sulla propria macchina.

Naturalmente gli strumenti di cui sopra si possono usare con molti altri linguaggi e per alcuni di essi ci sono alternative più valide, come scritto prima un ottimo punto di partenza è la pagina di integrazioni su GitHub.

Buon coding!

Spark, un interessante java micro framework

Ultimamente sto lavorando parecchio con API REST e per una prototipazione rapida sono comodi alcuni micro framework Java, uno dei più interessanti a mio parere è Spark (da non confondersi con Apache Spark, forse la scelta del nome non è delle più felici).

La documentazione non è delle più esaurienti e gli esempi disponibili non sono molti ma per un programmatore più o meno navigato il suo utilizzo è semplice.

Se vi siete stufati di Spring e usare JEE a volte è come usare una BFG9000 per aprire noci date uno sguardo a Spark, ha i suoi pregi.

#bandalarga? #certo, #lavoltabuona

Prendo spunto da Punto Informatico che ha riportato un interessante studio sulla situazione broadband in europa.

Il primo dato interessante è che la velocità media Europea è superiore a quella US, la grossa differenza è che loro scaricano in media al 101% della velocità contrattata mentre da noi si riduce al 63%. Insomma, ci mentono bellamente e paghiamo malamente.

La solita questione della “banda garantita” (o SLA), grande invenzione delle telco per proteggersi il fondo schiena.

La sezione più interessante comunque riguarda la copertura con livelli oltre 30Mbps, desolazione. Non servono ulteriori commenti.

broadbandcoverage
Fonte: Digital Agenda for Europe

JitPack, come usare maven e github

Integrare un progetto GitHub con Maven ora é diventato facilissimo, basta andare su JitPack e cercare il git repo che si vuole includere, successivamente si tratta di aggiungere poche righe al proprio pom.xml. 

<repository>
    <id>jitpack.io</id>
    <url>https://jitpack.io</url>
</repository>

e successivamente:

<dependency>
    <groupId>com.github.User</groupId>
    <artifactId>Repo name</artifactId>
    <version>Release tag</version>
</dependency>

Come indicato nello stesso sito, se il progetto non ha nessuna release si può applicare uno specifico commit id.

Feature Creep

Dopo anni di sveglie puntuali e brutali maltrattamenti la mia sveglia ha tirato l’ultimo sospiro (o si è suicidata magari). Trattandosi di un articolo semplice mi reco al primo negozio di elettrodomestici con l’idea di trovare qualcosa con un design gradevolmente moderno e che magari abbia più di una sveglia programmabile, magari con orari diversi per giorni diversi e, se possibile, con pannelli solari così da non dover pensare e comprare le batterie. Non hanno svegie, solo TV al plasma 4k, tv curvi, frigoriferi che fanno il ghiaccio, il ghiaccio tritato, rasoi a 77 velocità e altre cose che non svegliano. “Prova da mediaworld” mi dicono.

Primo giro al mediaworld. Nulla. Mille sveglie con differenti modalità per vedere il meteo dentro casa e fuori, per vedere il meteo da quattro fonti diverse, che proiettano l’ora sul tetto, in casa del vicino o su uno schermo 4k (Chuck Norris ne ha uno a 5k), altre che si collegano al telefono (per fare cosa non mi è chiaro), altre con radio, con radio e previsioni meteorologiche, con radio e tv, con radio e mp3, se cercassi bene troverei alcune anche con connessioni dirette a youporn.

Nessuna che faccia la sveglia programmabile però. Niente che possa fare solo da sveglia e con un (uno, uno soltanto) bottone ben grosso per poterla zittire. Niente di tutto questo. Sveglie atomiche e meteorologiche sincronizzate con Francoforte ma con il tasto “snooze” (la funzione primaria di qualunque sveglia!) ben piccolo e sulla parte posteriore della sveglia.

Passiamo da FNAC. Solo radio sveglie. Una sveglia di 4 metri quadrati con design radio anni ’40, sveglie con i digiti rossi che alla bisogna si possono usare anche come fendinebbia e altre due con una miriade di tastini piccolissimi per programmare mille funzioni, tranne le sveglie.

Torno al mediaworld ed alla fine in mezzo al marasma prendo un coso nero orribile che fa anche il meteo e lo porto a casa. Apro il pacchetto ma, per mia sorpresa, non ha la funzione sveglia. Ebbene si, la fantastatica Oregon Scientific BAR806 fa mille idiozie con il meteo, con l’allineamento da una radiofrequenza in Germania, si possono scegliere i °F o °C, previsioni meteo, vedere la temperatura massima e minima della giornata, umidità e chissà che altra futilità nascosta nelle 30 pagine del manuale. Ma non fa la sveglia. Eppure era messa nello scaffale delle sveglie. In compenso ho un LED bello grosso che mi avvisa del pericolo ghiaccio. Peccato che a Barcellona non sia una funzione molto utile. 59.99€ sprecati, la lascio a mia madre che adora sapere il meteo e le previsioni. Io preferisco guardare fuori o aprire la finestra.

Più tardi torno comunque al centro commerciale perché in ufficio la storia della sveglia rotta può funzionare per una settimana ma usare il cane come sveglia, che puntualmente verso le 8:30 piagnucola per mettersi a letto, non è un sistema affidabile. Da mediaworld e FNAC ci sono già stato e girando a casaccio trovo un “mirò” dove hanno finalmente quel che cerco. Una banalissima sveglia Daewoo con un grosso bottone “SNOOZE”. Esteticamente di mio gusto ma non è programmabile con più sveglie su basi giornaliere, comunque ormai ho le palle talmente piene e decido di farmela stare bene per un totale di 14€ e monetine varie.

Alla fine della storia mi è venuto in mente la storia del “What the customer really wanted” e di quanto sia vera quella striscia ancora oggi, spiego quindi perché il post è categorizzato come “Programmazione”.

L’altro giorno abbiamo raccolto una decina di sviluppatori software (tra frontend, backend, QA e UX) per una semplice applicazione CRUD. Una semplice pagina per creare, leggere, aggiornare e cancellare record di un database. Una cosa semplice. Invece in un attimo il tutto è degenerato con notifiche, paginazione della tabella, gestione omonimi, sort vari della tabella, che database scegliere, questo o quello non si può testare, politiche di sicurezza e bagni di sangue vari.

Il Feature Creep è veramente un pericolo molto reale nel quale è facilissimo cadere. Basta aprire iTunes per avere un esempio brillante. O cercare una sveglia.

Java su Synology

A volte può essere comodo avere Java sul proprio NAS Synology e provare piccoli sviluppi software java o magari su tomcat o jetty.

Un bel post su PC Load Letter illustra le operazioni da fare. E’ importante conoscere quale CPU monta il proprio NAS. Funziona perfettamente sul mio DS110J ma non aspettatevi prestazioni da brivido per la JVM, in fondo si tratta di un NAS di 5 anni fa.

Non ho provato ad installare Glassfish o JBoss perché già Tomcat sembra essere al limite su questo NAS, sicuramente con i Synology più recenti la situazione sarà migliore. Onestamente non saprei nemmeno dire se gli application server prima elencati possano funzionare con Java SE Embedded, ma poter avere un Tomcat è una buona cosa.

Italia e tecnologia

Il rapporto degl’italiani con la tecnologia è un problema culturale.

in Brasile, nel 1985, iniziai a programmare a scuola. con dei vecchi apple II. Logo e basic. Fino al 1990, data del mio sventurato trasloco in italia. niente programmazione fino al 1993 quando a scuola s’iniziò con il pascal. primo mondo.
poi l’università, ingegneria informatica ovviamente. siamo già nel ’96. un po’ di C, un po’ di matlab, fortran e tutta programmazione “astratta”. analisi numeriche, algoritmi per trovare lo zero di una funzione e tutta robaccia priva di qualunque senso, c’era l’esplosione del web in quel periodo ma nemmeno un vago accenno a cosa sia apache, http, a come mettere in piedi un database su un server, ma guai a me a non saper dimostrare le equazioni di Maxwell. (se già l’ha fatto lui che cazzo lo devo fare io a fare?)
giusto un corso, validissimo ma comunque troppo teorico, di basi di dati e qualche cenno su intelligenza artificiale, il resto è stato tempo sprecato, come dover ripetere in tre esami diversi che un hardisk ha le tracce, settori, cilindri, tempi di accesso e idiozie simili.
veramente tempo e fatica sprecati, il luogo dove il facile diventa difficile attraverso l’inutile diceva un mio amico. la cosa più importante che mi è rimasta non era sui libri, ma è il metodo. se una cosa non la so c’è di sicuro al mondo un libro che la spiega, continua a sbatterci il cranio e ti entrerà in testa, questa è l’unica cosa che mi è rimasta dell’università. non è roba da poco ma, in ogni caso, niente di vendibile su un cv. Continue reading Italia e tecnologia

Diario di un lamer

Alzi la mano chi non si rivede, anche solo vagamente. Mi ricorda i miei primi esperimenti con linux…

Giorno 1

Oggi ho deciso di installare Linux. Non si può essere un vero hacker se non si usa Linux, e io voglio essere un vero hacker. Soprattutto per far colpo sulle ragazze. Ho chiesto a quelli che conoscevo ed ho scoperto che Giovanni usa Linux; stranamente ha gli occhiali spessi, è sovrappeso, non si lava molto, non si rade e non conosce nessuna ragazza. Mi aspettavo qualcuno di più figo, con gli occhiali scuri anche al chiuso e il trench di pelle. Probabilmente si traveste per non dare nell’occhio. Una doppia vita! Che cosa emozionante diventare un hacker. Mi ha consigliato la Debian dicendo che è la “distruzione di Linux” per veri duri. Io sono un duro. Uso il computer da quando ero piccolo; sempre Macintosh, ma quando uno sa usare un computer, li sa usare tutti! Pensa: l’hacker di “Independence Day” entrava nel sistema operativo di una nave aliena: figata! Chissà perché si chiama “distruzione di Linux”. Dovrò chiedere. Che nome da duro!

Giorno 2

Giovanni mi ha spiegato oggi che la Debian è una DIS-TRI-BU-ZIO-NE di GNU/Linux. Non distruzione. Dice che è molto importante che si dica GNU/Linux, se si dice solo Linux la Microsoft (che dovrei scrivere Micro$oft o Microsuck, non so perché) prenderà il controllo del pianeta, provocherà l’Apocalisse, spegnerà il sole, farà piangere Gesù Bambino e impedirà che ci siano giochi recenti per GNU/Linux. In questo ordine (di importanza). Giovanni dice che GNU vuoi dire “GNU Non è Unix”, però Linux è Unix e Giovanni dice che è da queste contraddizioni apparenti che si capisce chi è un vero hacker. Tutti gli altri sono dei perdenti che si meritano che un Virus spedisca alla nonna pezzi di E-Mail pornografiche scambiate con la morosa. Io non posso essere un perdente perché mia nonna è tetraplegica e non sa usare il computer; oltre tutto, non ho mai avuto la morosa, anche se ho scritto dei racconti un po’ spinti su Kaori della pubblicità del Philadelphia. Sto già diventando un vero hacker.

Giorno 3

Ho smesso di fare domande a Giovanni, perché il suo travestimento da non-figo puzza davvero tanto e non riesco a concentrarmi trattenendo il fiato. Chissà dove si procura il suo “odore di ascella non lavata da quindici giorni”, è DAVVERO realistico. Un altro segreto hacker, immagino. Ho comprato una rivista con i CD della Debian. Da questa notte il mondo sarà mio: devo solo installarla, poi sarò un vero hacker. Nella rivista non ci sono donnine nude: un vero hacker si eccita con le immagini dei computer nudi (smontati), o con il “codice sorgente”. Ci ho provato, ma ho ancora molto da imparare.

Giorno 4

Non trovo setup.exe nel CD. Sarà rovinato. Domani lo vado a cambiare.

Giorno 5

Non c’è il setup.exe! È tutto molto semplice: si inserisce il CD a computer spento, si seleziona da BIOS di boot-are (un modo di dire inglese che vuoi dire “stivalare”, ah! gergo hacker!) da CD, e si installa. Facilissimo. Ci ho messo solo 3 ore a capirlo. Ora devo solo scoprire come invocare il BIOS.

Giorno 7

Sono fortunato! Il BIOS nel mio computer si invoca semplicemente premendo i tasti CTRL-ALT-SHIFT-CANC-Q-W-E-R-T-Y-1-2-3-4-5 contemporaneamente nei 4 microsecondi in cui avviene il check della memoria. Pensa che nel computer di uno che conosco è possibile invocarlo solo nelle notti di luna nuova, dopo la mezzanotte, se si rimane all’interno d’un pentacolo tracciato per terra col sangue d’un gallo nero. È destino che io diventi un hacker. Continue reading Diario di un lamer

eBay hack, niente da vedere

Il database di eBay è stato compromesso di recente, da un articolo su ArsTechnica si legge che è la solita tecnica del compromettere account dei dipendenti, la solita sindrome di Fort Apache insomma, ci si protegge contro tutto dal di fuori ma il problema è sempre dentro la propria struttura.

Come si legge nel comunicato di eBay “Financial and credit card information was apparently not affected as it is “stored separately in encrypted formats.”

Bullshit, pura bullshit.

Oggi come oggi qualunque informazione è di carattere finanziario. Si possono dare (o subire) tante fregature anche solo avendo indirizzo, telefono, nome e cognome di una persona. Provare (o subire) per credere.

Il problema serio è proprio questo. Ogni database utenti/clienti che ho visto contiene in formato criptato solo i dati finanziari o password degli utenti. Invece tutti i dati utenti dovrebbero essere in formato criptato, compreso indirizzo, telefono, età, data di nascita, tutto quanto, nemmeno gli operatori di ebay dovrebbero poter vederli ma se fosse così come potrebbero le varie aziende passare ore e ore ad analizzare il proprio customer database per poter spammare e scambiare dati con altri…non lo accetterebbero mai.

 

Apple, un desktop, per favore

iMac or Mac Pro.

Ci sarebbe anche il Mac mini ma non ne ho mai trovato un senso. Il MacPro, in un ambito casalingo non ha proprio senso ed un prezzo proibitivo.

Rimane solo l’iMac, già avuti in passato ma alla lunga non ho resistito con il display lucido ed il singolo disco fisso, all’epoca gli SSD erano troppo cari e poco diffusi, avevo optato per un MacPro (quando i prezzi erano ancora umani) e vivevo felicemente, fino a quando per lavoro non è dovuto diventare un MacBook che è veramente perfetto per quel che devo fare (java, sql, unix, virtual machines e compagnia).

Rimane solo un problema, il gaming occasionale che con il MacBook proprio non s’ha da fare. Per quanto sia valido il lavoro fatto da intel con i chipset Iris semplicemente non funzionano con i giochi, basta un semplice anti alias a 2x ed ecco che il sistema si scalda tantissimo. Continue reading Apple, un desktop, per favore