ideato - web ideas for sale - sviluppo applicazioni web / content management / esperti in php e symfony / corsi di formazione

Dare una stima dei costi per il refactoring di un progetto, senza prima averlo analizzato sarebbe come cercare di curare una malattia senza investire tempo e denaro in analisi mediche.

Fullo, mail a cliente anonimo

Sempre più spesso in Ideato ci arrivano richieste per riprogettare, rifattorizzare ed ottimizzare software già in produzione. Ovviamente chi chiede informazioni sui costi si ferma ad un misero «ma quanto mi costa?» senza però ascoltare le due/tre cose che sappiamo sull’argomento (mica ci abbiamo scritto un libro sul refactoring per hobby, no?).

Uno degli ultimi casi che mi è capitato riguarda la riprogettazione (a tutti i livelli, dall’UX alla sistemistica) di un portale da fare in partnership con altre aziende con cui stiamo lavorando già da tempo. Solo la fase di preventivazione di massima è costata a tutti parecchio tempo perchè, come al solito, non c’erano idee chiare da parte del cliente che è stato accompagnato mano nella mano in tutta l’attività.

Il quale, però, è ovviamente caduto dal pero vedendo che nel preventivo di analisi mancava la stima dei costi per il refactoring.

Ecco quindi spiegata la metafora che introduce questo post.

Read more...

Dopo il bellissimo regalo che ideato mi ha fatto il giorno del suo compleanno, ho iniziato ha studiare come poter scrivere applicazione su iphone senza conoscere objective-c.

Cercando un po’ su internet ho trovato due progetti molto interessanti:

• Phonegap
• Titanium

Entrambi si presentano come tool di sviluppo rapidi per creare applicazioni native per dispositivi mobile (iphone, android, blackberry) in html + javascript + css. Conoscendo molto bene questi tre linguaggi, ho pensato di iniziare a studiare questi tool per vederne le capacità.

Con la regola dell’80-20 che applichiamo in ideato (in pratica ogni sviluppatore può utilizzare il 20% dei suo tempo per studiare, fare prototipi, ecc), insieme con Michele e Fullo, abbiamo deciso di sperimentare entrambe le librerie per creare la nostra prima applicazione per iphone e android.

L’idea è quella di creare un’applicazione che, interfacciandosi con il servizio web Joind.in, faccia vedere i talk “on air” durante un evento. L’obiettivo è quello di lanciare l’applicazione durante il phpday 2010 che si terrà il 13, 14 e 15 maggio a Corropoli (TE).

Vi terremo aggiornati sull’applicazione su questo blog.

Se volete seguirci da più vicino abbiamo creato un repository GitHub, dove metteremo tutto il codice.

Read more...

• L’azienda che vorrei dovrebbe mettere le persone davanti a tutto, renderle partecipi di come l’azienda sta andando e perchè.
• L’azienda che vorrei dovrebbe perseguire il profitto, non solo quello economico, ma anche sociale ed intellettuale.
• L’azienda che vorrei dovrebbe permettere ed invogliare la crescita personale, dando a chi lo vuole la possibilità di fare nuove esperienze, anche collaterali al lavoro svolto in ufficio.
• L’azienda che vorrei dovrebbe far si che i dipendenti abbiano assistenza e rimborsi per le spese mediche, perchè la loro salute è anche salute dell’azienda.
• L’azienda che vorrei dovrebbe dare spazio alle persone di dire la propria, proporre idee ed avere un piccolo budget per portarle avanti.
• L’azienda che vorrei dovrebbe fare della propria forza la traparenza e la consapevolezza che il cliente fa parte del team di sviluppo.
• L’azienda che vorrei dovrebbe rendere gli straordinari un evento straordinario, e non una consuetudine.
• L’azienda che vorrei dovrebbe avere dipendenti che affermano che farsi oltre 40km per andare in ufficio tutte le mattine non pesano affatto.

Fortunatamente questa azienda la ho.

Read more...

Qualche settimana fa, una coppia di sviluppatori del team nel quale lavoro, mi ha chiesto:

“Ciccio, ma quali sono le regole del Pair Programming? Facciamo Pair Programming da alcuni mesi, ma a volte non ci sentiamo molto efficaci, perchè discutiamo troppo nel prendere decisioni condivise e perchè il nostro livello di conoscenza non è lo stesso.”

Quando dal team emergono queste domande, i miei occhi si illuminano, perchè solo di fronte alla consapevolezza si possono dare piccole regole per migliorare se stessi.

Di fronte alle loro domande non ho risposto subito, ho rinviato la discussione ad un dojo interno, che organizzeremo in ideato a breve tempo.

Tuttavia, oggi, vorrei raccontarvi quando secondo me il Pair Programming è efficace.

La metafora che uso spesso per far capire il Pair Programming è quella dei guidatori di rally, chi scrive codide è il guidatore, chi sta a fianco e osserva è il navigatore. Se il guidatore non si fida del navigatore, dove va a finire l’auto?

Come in ogni coppia anche nel Pair Programming si è efficaci se si rispettano i ruoli.

1. Il guidatore si deve fidare del navigatore.
   Nella coppia ci deve essere fiducia. Il punto di vista predominante deve essere quello del navigatore. La coppia non può discutere ogni piccola decisione. Il guidatore si deve occupare di fare bene quello che gli viene detto dal navigatore. L’obiettivo è la risoluzione del problema. Se il guidatore non è d’accordo con il design emerso potrà fare refactoring quando sarà lui il navigatore, se necessario.
2. Il guidatore deve stare attento alla tattica.
   Il compito del guidatore è quello di porre attenzione a quello che gli viene detto dal navigatore e al coding style.
3. Il navigatore deve stare attento alla strategia.
   Il compito del navigatore è quello di indicare la strada al guidatore. Il navigatore deve guardare più avanti e scegliere quale strategie attuare. E’ il navigatore che fa emergere il design del codice.
4. Per discutere si chiama un Time-Out.
   Durante la sessione di Pair Programming, se la coppia è in disaccordo, si possono chiamare dei Time-Out. I time out servono a discutere insieme quale strada percorrere e come risolvere un certo problema, o per chiedere aiuto a qualcuno se si è bloccati. Il numero massimo di time out che si possono chiamare durante una giornata non dovrebbero essere più di quattro. La durata di un Time-Out non deve essere superiore al pomodoro.
5. Cambiarsi i ruoli.
   E’ molto importante che nella coppia i ruoli vengano scambiati frequentemente. Un tempo ideale potrebbe essere ogni uno o due pomodori.

Nel dojo che organizzeremo in ideato, vedremo come rendere ancora più efficace il Pair Programming attravero il Ping Pong Pair Programming.

E tu ti fidi del tuo navigatore?

Read more...

Anche un altro anno sta finendo e si lascia alle porte molte belle eperienze vissute e passate.

Ho partecipate alle seguenti conferenze:

• eZ International Winter Conference – 29, 30 Gennaio 2009, Barcelona
• PHPCon Italia 2009 – 18 – 20 Marzo 2009
• PHPDay 2009 – 15, 16 Maggio 2009, Verona
• PHP Test Fest – 19, 20, 21 Giugno 2009, Cesena
• eZ Conference & Awards 2009 – 24, 25, 26 Giugno 2009, Parigi
• Javascript Camp – 25 Settembre 2009, Cesena
• HTML 5 Dojo – 18 Dicembre 2009, Cesena

Ho tenuto i seguenti talk:

• PHPCon Italia – Extreme Programming and PHP
• PHPDay – Spaghetti Code Refactoring
• Javscript Camp – Unit test con javascript

A fine ottobre inoltre è uscito il mio primo libro “eZ Publish 4: Enterprise Web Sites Step By Step” ed ho iniziato a scrivere il mio secondo libro “Pro PHP Refactoring with Test-Driven Design“.

Inoltre con la mia azienda ho lavorato ai seguenti progetti:

• Tripshake.com
• eHarmony.it
• TopGirl.it
• Casa Vinicola Zonin e tenute
• Planetek Italia

e alle seguenti estensioni open source:

• eZ Deploy – Deploy automatico con eZ Publish
• eZ Test Browser - Test funzionali con eZ Publish

Ho cercato di migliorare ogni giorno il processo produttivo all’interno di ideato, studiando e mettendo in pratica le metodologie agili.

Dire in conclusione un anno molto produttivo, ora vediamo che cosa il 2010 si riserverà.

Auguri a tutti e felice anno nuovo.

Read more...

Partono in ideato i corsi di formazione. Il primo corso di formazione si intitola “PHP Refactoring” e mi vedrà coinvolto come insegnante.

PHP Refactoring
Molte aziende ed organizzazioni hanno applicazioni business critical che dipendono da codice obsoleto e di difficile manutenzione.

Le ragioni dietro a questo genere di problema possono essere molte, dalla perdita di know-how relativo a chi ha sviluppato il prodotto, alla mancanza vera e propria di progettazione fino alla totale assenza pratiche di sviluppo che non hanno seguito pattern riconosciuti
e consolidati.

Con questo corso si imparerà ad identificare questi problemi ed aggiornare, o creare, applicazioni più efficienti utilizzando pratiche di Test Driven Design.

Il corso di Refactoring di codice PHP obsoleto sarà basato sul libro, di prossima pubblicazione, scritto da Francesco Trucchia e Jacopo Romei intitolato ”Pro PHP Refactoring with Test-Driven Design“ e tenuto dagli stessi autori.

durata: 2 giorni
maggiori informazioni: http://www.refactoring.it

Se siete interessati a partecipare o volete avere maggiori informazioni contattateci all’indirizzo formazione@ideato.it.

Read more...

Non sono mai stato un esperto di arti marziali, quello che però mi ha sempre affascinato di queste discipline è la necessità di viverle come uno strumento necessario al continuo miglioramento.

Un miglioramento necessario, negli anime a combattere il nemico più forte (la cosiddetta sindrome da DragonBall), ad affrontare i nuovi ostacoli che ci si pongono davanti con rinnovato vigore, non solo fisico ma soprattutto, psicologico.

Alcune pratiche di Extreme Programming riprendono questi concetti stravolgendoli, rimasticandoli e facendoli propri, ed ecco quindi che possiamo affermare che:

• i Kata, o meglio i Code Kata, sono espressione di miglioramento attraverso il perfezionamento di quello che si conosce,
• il Kaizen è la pratica di continuo accrescimento attraverso nuova conoscenza e riduzione degli sprechi
• ed infine il Bunkai è lo strumento di comprensione del problema suddividendolo ed affrontandolo in ogni suo più piccolo aspetto (= TDD?).

L’esperienza del Code Kata su Javascript di Gabriele, durante il JavascriptCamp, ha fatto rinascere in me la voglia di combattere il cattivo più grosso. Ma non da solo, bensì insieme ad un piccolo Dojo di Geek, in quella che potrebbe essere una nuova forma di BarCamp più vicina al mio desiderio di accrescimento.

Ho deciso quindi che i prossimi BarCamp Kaizen Dojo (letteramente “luogo del miglioramento“) che organizzerò (o a cui parteciperò), dovranno essere sullo stile del JavascriptCamp. Eventi con pochi iscritti, ma molto attivi e propositivi al miglioramento che offriranno sia presentazioni che Code Kata.

Cibo per la mente e palestra per il cervello.

ciuaz

Read more...

Inizia oggi per me e per Jacopo una nuova avventura. Saremo gli autori del nuovo libro dell’Apress “Pro PHP Refactoring with Test-Driven Design“.

Dopo il mio debutto con “eZ Publish 4: Enterprise Web Sites Step-by-Step“, del quale siamo nella fase di revisione tecnica, molto presto verrà pubblicato, ecco che ho deciso di buttarmi in una nuova sfida.

Credo che oggi come non mai ci sia interesse verso il valore del software. Io e Jacopo con questo libro cercheremo di spiegarvi come è possibile far crescere il vostro software php senza fallire e perderne valore.

Pro PHP Refactoring with Test-Driven Design

Many businesses and organizations depend on older high-value PHP software that risks abandonment because it is impossible to maintain. The reasons for this may be that the software is not well designed; there is only one developer (the one who created the system) who can develop it because he didn’t use common design patterns and documentation; or the code is procedural, not object oriented. With this book, you’ll learn to identify problem code and refactor it to create more effective applications using test-driven design.

What you’ll learn

• What refactoring is and why you need to refactor code
• What test-driven design is and why you need to test your code
• How to write unit and functional tests with PHPUnit and Selenium Remote Control (RC)
• How to detect “bad smells” in PHP code, and refactor them using test-driven design
• How to refactor a large procedural application affected by many bad smells

Who is this book for?

This book is for PHP developers, businesses, and developers relying on legacy PHP apps.

Read more...

Ho rilasciato la versione 0.1 stabile della libreria eZ Test Browser che permette di eseguire test funzionali con eZ Publish.

Insieme alla versione stabile è stata rilasciata anche la documentazione che insegna come installare ed usare l’estensione.

L’estensione è rilasciata con licenza GNU GPL 2.

Ringrazio i miei due compagni di viaggio Jacopo e Michele che hanno sviluppato con me l’estensione, ed ideato per aver finanziato questo progetto che sarù utile a tutta la comunità.

Read more...

In natura il cambiamento viene dimostrato dal confronto di due misure.

Ad esempio, se voglio dimostrare che il peso di un palloncino è diverso se riempito con acqua o con aria, eseguirò i seguenti passi:

1. peso in una bilancia il palloncino pieno di acqua
2. peso nella stessa bilancia il palloncino quello pieno d’aria
3. confronto i due pesi

se la differenza è diversa da zero, significa che il palloncino pieno d’acqua pesa di più del palloncino pieno d’aria:

Cambiamento = PesoPalloncinoAcqua - PesoPalloncinoAria

Questa dimostrazione è possibile grazie alla bilancia che è il nostro strumento di misurazione tarato sull’unita di misura del peso, il grammo.

Quindi se il palloncino è la nostra applicazione, l’acqua la nostra vecchia feature che deve essere sostiutita con l’aria, come faccio a dimostrare che il codice è cambiato se non riesco a misurarlo?

Con i test automatici.

Il test automatico è in grado di misurare il nostro codice e dimostrarne in maniera oggettiva il cambiamento.

E voi misurate il vostro codice? con quale unità di misura?

Read more...