Abbiamo parlato di test: una panoramica su come le pratiche di testing automatizzato possano aiutare gli sviluppatori a mantenere sotto controllo il proprio progetto. La sala era piena e lo è rimasta fino alla fine ( buon segno ). Andrea al suo esordio ha tentennato solo per qualche secondo poi ha preso coraggio ed è stata una passeggiata.

Ecco le slide del talk

Per chi si fosse collegato solo ora:

The Doctrine Project is the home of a selected set of PHP libraries primarily focused on providing persistence services and related functionality. Its prize projects are a Object Relational Mapper and the Database Abstraction Layer it is built on top of….

Doctrine è l’organizzazione sotto la quale sono raccolte tutte le migliori librerie (in PHP) che riguardano la persistenza dei dati. Esempi sono ORM per i database relazionali, così come gli ODM per i database documentali.

Il progetto di cui sto parlando si chiamava Orient, ora rinominato orientdb-odm. Una libreria scritta in PHP per interfacciarsi con OrientDB. Il primo commit risale ormai a circa due anni fa, quando Alessandro, ancora ignaro del grande risultato che avremmo raggiunto, cominciava a buttare giù qualche riga di codice. Non ci è voluto poi molto prima che mi tirasse dentro al progetto.

Già ancora prima di essere inglobati, avevamo avuto l’opportunità di presentare la nostra libreria in diverse conferenze come il codemotion, la poland phpconf e altre minori. Avevamo avuto più volte la sensazione che la qualità del codice scritto fosse molto alta e attendibile, ma quest’ultimo evento ce ne dà la conferma.

Ringraziamento dovuto anche al nostro terzo compagno d’avventura Daniele, portato a noi grazie a github. Non siamo riusciti ancora a vederci in faccia … ma è uno dei prossimi obiettivi .

Il 2012 è finito alla grande. Di cose da fare ce ne sono ancora molte. Vedremo cosa ci porterà il 2013

L’alternativa è che se fosse “molto facile” cambiare la versione del PHP sulla propria macchina di sviluppo, allora far girare di tanto in tanto i test dell’applicativo anche su questa istanza non sarebbe così complicato, nulla di impegnativo, ma almeno si potrebbe sapere fin dall’inizio in caso di incompatibilità, di cosa si tratta e scegliere come comportarsi.

Bhe questo modo “molto facile” esiste. Io l’ho trovato sul Mac attraverso un comando di brew. Sicuramente questo comportamento esisterà anche su Linux.

Comunque tornando a noi. E necessario aver installato php53 e php54, come si farebbe con i normali pacchetti (ormai uso brew praticamente per tutto) :

brew install php53

poi

brew install php54

Ed è a questo punto che scatta la magia. Utilizzando il comando switch, brew è in grado di scambiare la versione del pacchetto scelto. È quindi sufficiente eseguire:

brew switch php53 5.3.15

per passare alla versione 5.3.x. Se controlliamo infatti il puntamento degli eseguibili, questo è quello che scopriamo:

/usr/local/bin/pear -> ../Cellar/php53/5.3.15/bin/pear
/usr/local/bin/peardev -> ../Cellar/php53/5.3.15/bin/peardev
/usr/local/bin/pecl -> ../Cellar/php53/5.3.15/bin/pecl
/usr/local/bin/phar -> ../Cellar/php53/5.3.15/bin/phar
/usr/local/bin/phar.phar -> ../Cellar/php53/5.3.15/bin/phar.phar
/usr/local/bin/php -> ../Cellar/php53/5.3.15/bin/php
/usr/local/bin/php-config -> ../Cellar/php53/5.3.15/bin/php-config
/usr/local/bin/phpize -> ../Cellar/php53/5.3.15/bin/phpize

A questo punto se volessimo passare alla 5.4 sarebbe sufficiente eseguire:

brew switch php54 5.4.5

Il risultato sarebbe il seguente:

/usr/local/bin/pear -> ../Cellar/php54/5.4.5/bin/pear
/usr/local/bin/peardev -> ../Cellar/php54/5.4.5/bin/peardev
/usr/local/bin/pecl -> ../Cellar/php54/5.4.5/bin/pecl
/usr/local/bin/phar -> ../Cellar/php54/5.4.5/bin/phar
/usr/local/bin/phar.phar -> ../Cellar/php54/5.4.5/bin/phar.phar
/usr/local/bin/php -> ../Cellar/php54/5.4.5/bin/php
/usr/local/bin/php-cgi -> ../Cellar/php54/5.4.5/bin/php-cgi
/usr/local/bin/php-config -> ../Cellar/php54/5.4.5/bin/php-config
/usr/local/bin/phpize -> ../Cellar/php54/5.4.5/bin/phpize

Praticamente brew utilizza dei link simbolici per mantenere tutto completamente trasparente. Ovviamente questo comando può essere eseguito per qualsiasi programma. A me per esempio è stato molto utile nel caso di Node.

ps: purtroppo il loadModule di apache non si aggiorna da solo, ma è l’unica pecca. Bisognerà switchare a mano tra queste due linee nel file httpd.conf

LoadModule php5_module /usr/local/Cellar/php53/5.3.15/libexec/apache2/libphp5.so
#LoadModule php5_module /usr/local/Cellar/php54/5.4.5/libexec/apache2/libphp5.so

Bene, non è la prima volta che parlo di CI e soprattutto non è la prima volta che la metto in pratica per un progetto delicato. Ma questa volta c’è qualcosa di diverso, qualcosa di semplice, una mossa in più (anzi, due) che cambia tutto.

I risultati migliori si hanno sempre per caso e così anche questa volta. È un caso che abbia una macchina inutilizzata, ma sempre pronta, sempre connessa. E allora l’idea: la macchina è accesa, tanto vale farne un’utilizzo.

Colleghiamoci uno schermo per mostrare una sola ed unica cosa: il monitor di jenkins.

Il monitor di jenkins non è nient’altro che una schermata full screen che mostra il risultato dell’esecuzione della suite di test. Di monitor vecchi ce ne sono tanti basta trovarne uno funzionante in magazzino ed il gioco è fatto. In poco tempo sulla mia scrivania c’e un monitor in più, verde o rosso a seconda dello stato del progetto. Basta un colpo d’occhio ed è facile capire se le varie persone del team hanno introdotto bug o errori di regressione.

Monitor dedicato a Jenkins

Ora, prima di questa volta, Jenkins eseguiva le sue verifiche in modalità temporizzata. Il che significava 2/3 volte al giorno pianificate da un cron Job. Da qui l’altro passo:

invece di renderlo temporizzato, facciamolo partire subito dopo che il sistema di versionamento (svn, git) ha ricevuto un commit.

Ecco che un sistema, che nasce così senza molte pretese, cambia completamente l’approccio. Ora, ogni volta che qualcuno esegue un commit, Jenkins non solo si mette al lavoro, ma il risultato è li a portata di mano. Quando lo schermo diventa rosso il riscontro è inevitabile.

Prima di posizionare un monitor, veniva semplicemente inviata una mail con la consapevolezza di non avere un riscontro live, soprattutto quando si è immersi nel lavoro. Il rischio è che i componenti del team, ignari (ma non assolvibili) dei failed-test, potrebbero procedere nel lavoro, o peggio passare ad altro, senza essersi resi conto che le modifiche appena apportate hanno scaturito degli errori. Il vantaggio sta proprio nell’avere un’informazione invasiva (come dice Jacopo). Il monitor è diventato rosso, è inevitabile ignorarlo. Cercando i dettagli della build, è possibile individuare l’autore del commit in fail e i test che sono falliti. Di conseguenza diventa più facile risolvere i problemi generati senza ulteriori propagazioni. L’utilità aggiuntiva dello schermo, è diventata un must senza la quale ora mi sembra impossibile pensare al work flow del passato.

Perché se come è vero che l’obiettivo della CI è scoprire i problemi il prima possibile, in pieno stile Agile, l’utilizzo di questi due accorgimenti ci permetterà di farlo ancora prima.

L’evento è stato molto ben organizzato ed i talk sono stati tutti di grande livello. Un evento veramente ben riuscito. Spero di poter partecipare attivamente anche l’hanno prossimo, magari con la libreria Orient conclusa.

ps: non ne ho parlato bene solo perchè poi ho vinto il premio dell’estrazione …

[update]: ora abbiamo anche il video.

Sono le 6 di mattina, già 12h di fila che stai davanti a quello schermo. La stanchezza si fa sentire … e ormai già da più di qualche ora. I caffè non fanno praticamente più effetto e quando sei li li per chiederti chi te l’ha fatto fare, le carte in tavola cambiano: I componenti che i vari reparti del team stanno progettando cominciano a dialogare tra di loro. Ci siamo, “funziona”, beh ci vuole ancora qualche ritocco ma “funziona”.

Ecco, quello è stato il momento in cui le cose sono cambiate: la stanchezza è passata, l’adrenalina è entrata in circolo e tutto quello che prima sembrava opaco adesso non lo è più. Anzi è tutto molto chiaro come se aveste aggiustato la messa a fuoco del vostro obiettivo.

L’Euhackaton non comincia di certo in questo modo, anzi. A dire il vero comincia con una stretta di mano. La presentazione con il team. Non ci conosciamo, qualcuno a parte, siamo tutti nuovi l’un l’altro. Ci siamo sentiti molto spesso durante le ultime settimane per discutere del da farsi, ma parlare tramite skype e postarsi messaggi per mail non è proprio come lavorare insieme per 24h di fila.

Una cosa è certa: nessuno di noi si è messo in viaggio per vincere il premio. Abbiamo tutti partecipato solo ed esclusivamente per sfamare la nostra voglia di tecnologia e dare sfogo alla nostra passione, alla nostra necessità di metterci continuamente in gioco. Perché siamo tutti alla continua ricerca di quella sensazione che ti sà appagare più di qualsiasi altra cosa: il momento in cui quel qualcosa che tanto ti ha fatto penare per essere messo in piedi comincia a prendere forma e quindi a funzionare!

In quel momento ti senti appagato, soddisfatto, hai quel qualcosa in più che ti permette di andare avanti in quello che stai facendo e soprattutto, ti ricordi della prima volta che hai provato quella sensazione, quando hai capito che sarebbe stata la tua droga.

E man mano che vai avanti scopri i tuoi colleghi che prima erano solo dei nomi, poi dei volti, subito dopo diventare qualcuno di cui ti fidi e che stimi. Perché sono lì, lavorano (nonostante il sonno) e ci mettono la stessa passione che ci metti tu. E la conferma ce l’hai quando alla premiazione tutti insieme scopriamo che in realtà il premio era in denaro ed era anche una somma considerevole… Ma noi di certo non eravamo li per quello.

Ci siamo classificati terzi … ed io in realtà non dovevo neanche partecipare, ma questa è un’altra storia.

Il mese prossimo, molto probabilmente, sarà in onda anche sul canale del pug Roma. Intanto metto le slide in questo articolo.

Come ci dobbiamo comportare se dall’analisi di fattibilità del nostro progetto scopriamo che i dati da persistere sul db vanno oltre le features messe a disposizione da un db relazionale, anzi si comportano proprio come una rete di contatti … un grafo. Possiamo prendere in considerazione due tipologie di comportamenti.

Il primo insiste sul db relazionale. Nonostante non sia stato pensato per risolvere questa tipologia di problematiche troviamo dei workAround per fargli fare quello che non sarebbe in grado di fare. Un esempio pratico è la rottura dell’integrità referenziale. Quando abbiamo la necessità di aggregare dati eterogenei, le “foreign Key” non possono più aiutarci, si introduce all’interno dei campi di una tabella il campo che indica il nome della tabella correlata al quale fa riferimento l’id del campo a fianco.

A questo punto il db non sà più fare il suo lavoro  poiché non è più in grado di conoscere la tipologià di informazione estratta. Il che significa che, per far funzionare le cose,  dobbiamo integrare la logica( che normalmente sarebbe gestita dal db) della nostra applicazione di queste informazioni aggiuntive.

La seconda scelta consiste nel prendere in considerazione un prodotto studiato appositamente per risolvere questa tipologia di problematiche. Ed è proprio la soluzione che vogliamo valutare.

A questo punto ci siamo spostati nel dominio NoSql, quel ambito nel quale i database non sono solo relazionali. Si può spaziare da database key-value come Redis, a Documentali come Couch DB e Mongo DB. Tra questi ce ne sono anche alcuni che si occupano di prendere in considerazione strutture dati a grafi. Wikipedia ne mette in mostra molti, ma quello che  ci interessa è OrientDB.

OrientDB è in grado di garantire altissime prestazioni, è orientato al Documento (Document Oriented) è schema full/less/mixed, è affidabile (ACID), ha una sintassi di quering molto simile a quella SQL ed è molto semplice fare le traversal (attraversamento dei nodi)

Ecco una presentazione di Orient DB direttamente dal suo Lead developer

Da qualche mese a questa parte Alessandro (il mio collega) ed io, abbiamo cominciato a scrivere una libreria in PHP per interagire con OrientDB. L’esigenza è stata percepita principalmente quando ci siamo scontrati con la progettazione di un CMF, nella necessità di un grafo per persistere le nostre strutture dati.

La libreria si trova su github è un componente del CMF che stiamo progettando ma è assolutamente indipendente e puo essere utilizzata anche esternamente.

Si compone di tre componenti software:

1. binding: di piu basso livello è la libreria di base che permette di collegarsi a Orient attraverso uno dei due protocolli disponibili HTTP (sempre fatto da noi) e binario
2. query-builder: una libraria ad oggetti che mette a disposizione dei metodi per la creazione di query, un po come avviene con quelle di Doctrine/Propel
3. mapper: la libreria di piu alto livello, prende spunto sia in architettura che in funzionalità  dall’ODM di docrine per mongo che ha le seguenti caratteristiche
• mappa i campi da persistere nel db attraverso l’utilizzo di annotation
• Idrata gli oggetti con i risultati ottenuti dal db
• Persiste i dati sul db

I primi due componenti sono già funzionanti (test di integrazione compresi) e ci stiamo accingendo a concludere anche il terzo che è quello con complessità un po’ più elevata. Il passo conclusivo consisterà nell’incapsulare questa libreria all’interno di un bundle per il nuovo Symfony2.

Quindi ben presto anche gli sviluppatori PHP, e soprattutto quelli che hanno cercato in tutti i modi di far cambiare natura ai database relazionali (mySql per esempio), potranno lavorare con database a grafo e riuscire a trarre vantaggi da questo tipo di tecnologia.

Nei prossimi articoli verrà mostrato come interagire con questa libreria. Dimenticavo, se volete dare il vostro contribuito…benvenuti.

Sono stato molto felice di poter partecipare come speaker ed anche se non ho parlato esplicitamente di PHP spero che la mia presentazione abbia aiutato i presenti a capire qualcosa di piu su questo “nuovo” trend.

Ecco le slide della mia presentazione.

Sono ormai da qualche anno un soddisfatto cliente H3G. Ho sottoscritto il piano Power 800 almeno 3 anni fa quando era così composto:

1. 800 minuti di telefonate al mese
2. 400 sms/mms al mese
3. 10Gb di traffico internet al mese
   Tutto a €29 + €5 (tassa di concessione governativa)

Ieri, per la prima volta, mi contatta il customer care con una fantastica promozione per me, mi vogliono far passare ad un altro piano tariffario. Innanzi tutto ci tiene a precisare che c’e la possibilità di prendere un iPhone4 (che già ho) a costo zero e poi mi elenca il nuovo piano

1. 800 minuti al mese
2. 200 sms/mms al mese
3. 2Gb di traffico internet al mese
4. iphone 4 a costo zero
   Tutto a  €44 con un vincolo di 30 mesi

Dice: “Signor Funaro, che ne pensa?”
C’è poco da pensare, pago €10 in piu, ho 200 sms in meno, 8Gb di traffico in meno, ed in piu sono vicolato con voi per 30 mesi. A me sembra proprio che la promozione sia per loro non per me.

Anche perche a conti fatti, faccio prima a comprarmelo direttamente un iPhone4:

10€ in piu al mese X 30 mesi = €300
200 sms X 0,10 (costo sms) X 30 mesi  = €600
senza calcolare gli 8Gb siamo molto fuori…

Mah, sono sicuro che richiameranno, prima o poi, chissà quale altra promozione vorranno chiedermi

AGGIORNAMENTO: qualcuno mi fa notare che forse ho tralasciato un dettaglio. La chiamata non era casuale, il tizio con cui ho parlato sapeva benissimo che tipo di piano avessi e che tipo di consumi facessi. Quindi l’obiettivo della telefonata era proprio quello di tentare di farmi abbandonare una tariffa ormai non più offerta dal gestore.