ema.blog

Back to basic: TDD (4)

ema — Fri, 23 Mar 2012 14:32:14 +0000

Continua la serie, per piccoli passi.

La storia che implementiamo oggi è la seguente:

Dato un carrello posso sapere il prezzo totale degli articoli presenti.

Da un po’ di analisi emerge che il prezzo degli articoli è una cosa che cambia spesso anche per eventuali promozioni, saldi, ecc…quindi nasce l’esigenza di un servizio che si occupa dato un articolo di restituire il prezzo corrente (se questo non emergesse subito, no prob, si potrà fare refactoring in futuro).

Come al solito partiamo da un test per ragionare un po’. Quello che voglio è che l’oggetto CartItem utilizzi un servizio per sapere il prezzo del’articolo aggiunto, detto in C#:

[Fact]
public void GetTotal_OneItem_ShouldAskToPriceListServiceTheItemPrice()
{
var priceListService = new Mock<IPriceListService>();
var cart = new ShoppingCart(priceListService.Object);

cart.AddItem(99);

priceListService.Verify(p => p.GetCurrentPriceFor(99));
}

Questo test è diverso da quelli scritti fin’ora. Prima di tutto viene usato un mock object (priceListService) invece del vero oggetto in modo da avere uno unit test nonostante le dipendenze e poi non vengono fatte asserzioni sullo stato ma sulla collaborazione tra l’oggetto CartItem e il servizio.

Questo tipo di test si chiamano test di interazione a differenza di quelli fatti fino ad ora che erano test di stato. I test d’interazione verificano che 2 o più oggetti collaborino in modo corretto chiamando i giusti metodi con i giusti parametri. Nel nostro caso vado a verificare che il metodo GetCurrentPriceFor venga chiamato con il valore 99, se ciò avviene il test passa altrimenti fallisce. Non mi interessa lo stato dell’oggetto CartItem tant’è che non faccio alcuna asserzione su di esso.

La cosa interessante è che nel test sopra sto introducendo una nuova classe della quale vado a definire la competenza e parte dell’interfaccia ma non mi occupo dell’implementazione che demando in un secondo momento.

Il test è definito quindi posso passare alla fase rossa. Per compilare aggiunto al costruttore di ShoppingCart il parametro di tipo IPriceListService, aggiungo l’interfaccia e il test è già rosso.

Il messaggio di errore mi dice che il metodo GetCurrentPriceFor non è stato chiamato correttamente, quindi l’interazione prevista tra ShoppingCart e il servizio non è avvenuta. Per farlo diventare verde aggiungo in fondo al metodo AddItem la seguente riga di codice (_priceListService è l’istanza del servizio passata a ShoppingCart):

_priceListService.GetCurrentPriceFor(itemId);

Il test d’interazione è verde ma la storia non è ancora completa, quello che chiedeva era di esporre il prezzo totale degli articoli del carrello, quindi devo esporre una proprietà che mostri il prezzo calcolato tramite il servizio. Aggiungo un test:

[Fact]
public void GetTotal_OneItem_ShouldSetTheTotalValue()
{
var priceListService = new Mock<IPriceListService>();
var cart = new ShoppingCart(priceListService.Object);

priceListService.Setup(p => p.GetCurrentPriceFor(99)).Returns(100m);
cart.AddItem(99);

Assert.Equal(100m, _cart.Total);
}

Questo test sebbene simile al precedente torna a valutare lo stato dell’oggetto indipendentemente dalla collaborazione con il servizio. Ho aggiunto un test perché rispetto al precedente sto testando un’altra cosa sebbene nel contesto della stessa storia.

Da notare che in questo test l’oggetto priceListService funziona da Stub e non da Mock (non verifica la collaborazione ma risponde con il valore 100 ad ogni chiamata del metodo).

Al momento il test è rosso, quindi modifico il metodo AddItem nel seguente modo:

public void AddItem(int itemId)
{
CartItem item = _items.SingleOrDefault(i => i.Id == itemId);
if (item != null)
item.AddOne();
else
_items.Add(new CartItem(itemId));

Total = _priceListService.GetCurrentPriceFor(itemId);
}

Come vedete ho fatto un piccolo passo, al posto di = avrei potuto scrivere direttamente un +=. Vi invito a non fare passi troppo lunghi e a cercare di soddisfare sempre solo ciò che il test richiede.

Per arrivare all’implementazione finale e completare la storia basterà aggiungere un altro test che aggiunge 2 item e che verifica che il totale sia la somma dei prezzi. Per questo vi rimando al sorgente presente sul repo per non allungare troppo questo post.

Back to basic: TDD (3)

ema — Mon, 12 Mar 2012 10:57:00 +0000

Nei primi 2 step abbiamo introdotto una piccola funzionalità che permette di aggiungere un articolo al carrello. Continuiamo sullo stesso tema introducendo la seguente funzionalità:

Quando aggiungo 2 item uguali, deve aumentare la quantità dell’item.

Nello step 2 abbiamo gestito l’aggiunta dello stesso articolo per 2 volte oggi gestiamo la quantità e questo ci porta alla creazione di una nuova classe che rappresenta l’articolo aggiunto.
Proviamo a scrivere un test per decidere l’interfaccia che vogliamo usare e come vogliamo operare:

[Fact]
public void AddSameItemTwice_TheItemQuantityShouldBe2()
{
var cart = new ShoppingCart();
cart.AddItem(new CartItem(99));
cart.AddItem(new CartItem(99));
Assert.Equal(2, cart.Items[0].Quantity);
}

Questa implementazione non mi piace molto perché ci costringe a sapere dell’esistenza della classe CartItem che al momento non serve se non per gestire la quantità. Inoltre è meglio non esporre pubblicamente la lista dei CartItem altrimenti si potrebbero aggiungere item senza passare dal metodo AddItem o si potrebbero fare operazioni non consentite.

Quindi modifico il test per nascondere l’esistenza di CartItem e per esporlo sotto forma di IEnumerable cosi che la collezione non sia modificabile ma sia in sola lettura.

[Fact]
public void AddSameItemTwice_TheItemQuantityShouldBe2()
{
var cart = new ShoppingCart();
cart.AddItem(99);
cart.AddItem(99);
Assert.Equal(2, cart.Items.ElementAt(0).Quantity);
}

In questo modo la creazione degli oggetti CartItem è demandato all’interno della classe ShoppingCart (che diventerà molto probabilmente l’aggregate root…ne parleremo più avanti).
Una possibile implementazione è la seguente:

public class ShoppingCart
{
private readonly List<CartItem> _items;

public ShoppingCart()
{
_items = new List<CartItem>();
}

public IEnumerable<CarItem> Items
{
get { return new ReadOnlyCollection<CartItem>(_items); }
}

public int ItemCount { get { return _items.Count; } }

public void AddItem(int itemId)
{
CartItem item = _items.SingleOrDefault(i => i.Id == itemId);
if (item != null)
{
item.Quantity++;
}
else
{
item = new CartItem(itemId);
item.Quantity = 1;
_items.Add(item);
}
}
}

public class CartItem
{
public int Id { get; private set; }
public int Quantity { get; set; }

public CartItem(int id)
{
Id = id;
}
}

Con questa implementazione i test diventano tutti verdi.
Dedichiamoci al refactoring che questa volta serve.
Non mi piace inoltre il fatto di dover impostare nel metodo AddItem il valore di Quantity a 1, quindi sposto la definizione della quatità sull’oggetto CartItem. Non mi piace neppure che Quantity sia esposto in scrittura, quindi aggiungo un metodo AddOne:

public void AddItem(int itemId)
{
CartItem item = _items.SingleOrDefault(i => i.Id == itemId);
if (item != null)
{
item.AddOne();
}
else
{
_items.Add(new CartItem(itemId));
}
}

mentre la class CartItem:

public class CartItem
{
public int Id { get; private set; }
public int Quantity { get; private set; }

public CartItem(int id)
{
Id = id;
Quantity = 1;
}

public void AddOne()
{
Quantity++;
}
}

Così le cose sono un po’ meglio anche se, si potrebbe provare ad eliminare l’if nel metodo AddItem, ma per ora ci tappiamo il naso e continuiamo, vediamo cosa succede.

Un mese di pomodoro

ema — Sat, 10 Mar 2012 06:53:27 +0000

Da circa un mese in CodicePlastico abbiamo deciso di adottare la tecnica del pomodoro come strumento per misurare la durata delle nostre attività.
La sua introduzione è nata dall’esigenza di creare dei dati storici di misurazione dei tempi di un progetto e dal tentativo di ridurre le interruzioni sia interne al team che esterne.

Cosi abbiamo deciso di provare seriamente per un mese la tecnica del pomodoro per ogni attività. La mattina, arrivati in ufficio, ognuno di noi compila il proprio elenco dei task che intende fare durante la giornata e per ogni attività stima quanti pomodori impiegherà a completarla. Quando tutti sono pronti si fa partire il pomodoro. Abbiamo deciso di utilizzare un pomodoro unico per tutto il team così da poter sfruttare le pause (sincronizzate) per eventuali richieste di informazioni o anche solo per scambiare due parole.

Com’è andato questo mese?

Ho fatto 82 pomodori (interi), nei primi giorni ne facevo 5-6 interi poi sono migliorato arrivando a 10-12 pomodori al giorno che vi garantisco non sono male. La cosa che mi ha dato più valore è la lista giornaliera delle attività, quella è veramente utilissima e permette di non scordare le cose da fare e soprattutto di rimanere focalizzati sulle cose che vanno fatte tralasciando o posticipando quelle meno importanti. Nella mia lista dei task ci sono anche pomodori dedicati a rispondere alle email, alla fatturazione, alle riunioni interne al team….quindi ogni tipo di attività è stata tracciata e misurata.

Il fatto di sapere di essere sotto pomodoro limita al minimo le distrazioni dovute a twitter, giornali, ecc….e di conseguenza migliora di molto la qualità generale del lavoro, vi garantisco che 25 minuti sono davvero tanti e se ben usati si riescono a fare un sacco di cose.

Quindi il context switch è stato ridotto tantissimo e così anche le interruzioni all’interno del team (la classica: “…scusa Ale come si faceva quella cosa…”), se davvero mi serve il supporto di un collega, posso, alla pausa successiva, chiedere un pomodoro in pair.
Non ha funzionato benissimo il pomodoro unico, spesso le pause tra uno e l’altro si prolungavano per aspettare il collega che tornasse alla scrivania o per altri motivi, quindi abbiamo deciso di provare ad usare ognuno il proprio pomodoro e se proprio qualcuno è bloccato perché serve l’aiuto di un collega non deve far altro che aspettare che il collega finisca il pomodoro.

Quindi, al di la del pomodoro in quanto tale, credo che una qualsiasi tecnica di time boxing unita ad un todo list con le attività da svolgere aiuta tantissimo a rimuovere le distrazioni sia interne che esterne, ad aumentare la produttività e soprattutto a sapere esattamente quanto tempo si è impiegato su un progetto. Per ora continuiamo e nel prossimo step integriamo la kanban board segnando sui post-it i pomodori impiegati per le attività. Vedremo se la qualità del nostro lavoro riesce a salire ancora un po’.

Back to basic: TDD (2)

ema — Thu, 01 Mar 2012 13:40:52 +0000

Andiamo ancora piano piano…nel post introduttivo avevo evidenziato alcuni benefici del TDD mettendo in risalto il fatto che ti obbliga a pensare e ad essere sicuro di aver capito cosa vuole il committente. Di solito alla fine di ogni test mi chiedo se la funzionalità è davvero completa e se ci sono casi limite che vanno gestiti e in tal caso aggiungo altri test per capire come comportarmi in questi casi.

Tornando al codice della puntata precedente, quello che mi viene da chiedere al product owner è : cosa succede se aggiungo lo stesso item più volte? Naturalmente se il problema è emerso in fase di analisi so già come procedere altrimenti mi fermo e chiedo delucidazioni.

[nda: ho visto che i vari siti di ecommerce si comportano in modo diverso, per alcuni il numero di item nel carrello è il numero di prodotti univoci per altri è il numero di articoli presenti.]

Per il nostro esempio il product owner ci dice che aggiungere 2 volte lo stesso articolo non fa aumentare il numero degli item, ma la quantità dello stesso (gestiremo la quantità successivamente).

Quindi il nostro test sarà:

[Fact]
public void AddSameItemTwice_TheItemCountShouldBe1()
{
var cart = new ShoppingCart();
cart.AddItem(99);
cart.AddItem(99);
Assert.Equal(1, cart.ItemCount);
}

che compila ma al momento è rosso, visto che non vengono fatti controlli sull’item aggiunto.

Per farlo diventare verde modifico il metodo AddItem di ShoppingCart

public void AddItem(int itemId)
{
if (!_items.Contains(itemId))
_items.Add(itemId);
}

e, come al solito, valuto possibili refactoring. Quell’if appena introdotto non mi piace ma per ora lo lascio vedremo con le prossime funzionalità se si potrà rimuovere.

Quindi in questo caso non sono state aggiunte nuove funzionalità, abbiamo solo verificato che quello che avevamo scritto nella puntata precedente rispondesse in tutto e per tutto al requisito gestendo un caso non emerso subito in analisi. Quindi vuol dire che in TDD si alternano fasi di TDD vero (ossia fasi in cui si aggiungono funzionalità tramite un test) a fasi di assestamento in cui si vanno a scrivere Unit Test per verificare che in ogni caso previsto le cose funzionino.

Come al solito trovate il codice su github.

Back to basic: il contesto e il primo test

ema — Fri, 24 Feb 2012 13:15:53 +0000

Per partire con la serie di post sull’applicazione del TDD dobbiamo prima identificare un contesto che sia abbastanza semplice da capire ma anche abbastanza complesso da implementare.

Quello a cui ho pensato è un’applicazione di e-commerce, alla amazon (con molta fantasia) e vorrei partire proprio dalla gestione del carrello, credo sia capitato a tutti di fare almeno un acquisto online e quindi il dominio dovrebbe essere noto.

Alcuni disclaimer: non voglio implementare un’intera applicazione di ecommerce, e, almeno per ora, non voglio tirare in ballo la UI, frameworks, persistenza ecc….quindi sebbene le storie per essere completate necessiterebbero di tutta la filiera che va dalla UI fino al database (nel caso si decidesse di usare un db) farò delle enormi semplificazioni e mi limiterò all’implementazione del domain model. Se poi ci sarà la voglia di continuare in futuro monteremo una UI adatta alle operazioni implementate.

Iniziamo piano, a piccoli passi e la prima storia che andremo ad implementare è un semplice punto di partenza, il minimo per avere un qualcosa su cui ragionare, aggiungeremo successivamente funzionalità più avanzate.

Come utente che sta navigando sul sito posso aggiungere un articolo nel carrello

Partiamo con la scrittura del primo test:

[Fact]
public void AddItem_TheItemIsNotYetInTheBasket_ShouldAddItToTheBasket()
{
var cart = new ShoppingCart();
cart.AddItem(99);
Assert.Equal(1, cart.ItemCount);
}

Questo semplice test che può risultare perfino banale ma ci permette di posare la prima pietra e ci obbliga a decidere alcune cose: il nome delle classi in gioco e una prima parte di interfaccia che, in questo caso la classe ShoppingCart, dovrà esporre.

Vorrei riflettere un attimo sul metodo di verifica che abbiamo scelto di utilizzare: verificare il valore della proprietà ItemCount. ItemCount è stata introdotta solo per poter testare l’applicazione, almeno per ora non ha altri scopi, quindi non sono sicurissimo che questo vada bene.
Se ragioniamo a livello funzionale, servirà sicuramente un qualcosa che ci permetta di sapere quanti articoli sono presenti nel carrello (almeno per esporlo vicino all’icona del carrello), ma al momento non ci serve.

Un’alternativa sarebbe stata quella di usare un DomainEvent per notificare al resto del mondo il fatto che un articolo è stato inserito, il test avrebbe potuto sottoscriversi all’evento e fare li l’asserzione.
Per ora teniamo buona l’implementazione più classica, vedremo in futuro se spostarci verso una soluzione ad eventi.

Quindi adesso abbiamo un test che non compila. Primo step: facciamolo diventare rosso.

Quindi implemento la classe ShoppingCart in questo modo

public class ShoppingCart
{
public int ItemCount { get { return 0; } }

public void AddItem(int itemId)
{
}
}

La fase “rossa” è molto importante perché è l’unico feedback che abbiamo sulla bontà del test, se il test è rosso e il messaggio d’errore è coerente stiamo con buona probabilità testando la cosa giusta.

Quindi è giunto il momento di farlo diventare verde:

public class ShoppingCart
{
private IList<int> _items;
public int ItemCount { get { return _items.Count; } }

public void AddItem(int itemId)
{
_items = new List<int>();
_items.Add(itemId);
}
}

Ora la barra è verde. Refactoring? Al momento non ne abbiamo bisogno, per ora può bastare, abbiamo scritto un primo test, abbiamo una semplicissima funzionalità, poca cosa, ma comunque un punto di partenza. Le cose importanti che abbiamo fatto sono state decidere il nome della classe e definire l’interfaccia del metodo per aggiungere un articolo. Notate come per ora non abbiamo introdotto una classe Product, per ora ci limitiamo ad usare l’id di un ipotetico prodotto.

Trovate il codice sorgente del progetto su github

Back to Basic: TDD

ema — Mon, 20 Feb 2012 13:47:01 +0000

Nonostante parlo di TDD da anni, e alcuni cominciano anche ad annoiarsi, ancora oggi mi rendo conto che è una pratica che non è molto utilizzata e apprezzata come meriterebbe, molti ne parlano, ma pochi la usano.

Sicuramente la sua difficoltà principale è nell’imparare a farlo con profitto, e in quella sensazione che all’inizio sia come programmare con il freno tirato, sai esattamente dove vuoi arrivare ma il fatto di dover scrivere i test rallenta le operazioni. Se siete in questo stato dovete fare ancora un po’ di strada, quel “sapere esattamente dove arrivare” è probabilmente sbagliato e il TDD dovrebbe servire a scoprire dove realmente dovete arrivare.

In questo post voglio riassumere quello che secondo me il TDD insegna.

Pensa poi scrivi

Pensare alla prossima mossa, pensare prima a cosa vogliamo implementare senza interessarci al come. Essere obbligati a scrivere un test prima del codice ci obbliga ad avere ben chiaro cosa dobbiamo fare, se non riusciamo a scrivere il test ci fermiamo, chiediamo chiarimenti e solo dopo torniamo al codice. Senza TDD, il fatto di non aver capito emerge dopo, magari dopo aver già scritto svariate righe di codice che dovranno essere adattate o buttate.

Outside-in

L’altro punto molto interessante è l’approccio. Per me se prima del TDD era bottom-up è diventato outside-in, parto da una funzionalità, da come la voglio dare all’utente, dalla ui e poi entro nei layer della mia applicazione. Questo porta ad avere API migliori, più mirate al business.

Prima il comportamento

Facendo TDD si è obbligati ad implementare prima il comportamento delle classi e solo dopo si pensa ai dati.

Piccoli passi

Si procede a piccoli passi, ogni test aggiunge una piccola funzionalità all’applicazione e gli altri test verificano che tutto continua a funzionare.

Limito il contesto

Il TDD usato con i mock object mi permettere di tenere il focus sulla classe che sto testando, introducendo le dipendenze solo sotto forma di interfaccia che si andranno ad implementare in un secondo momento. Non stupisce quindi che si può implementare completamente un controller senza aver scritto una riga di codice dei servizi da cui esso dipende, di quelli abbiamo però già disegnato le interfacce.

Questi sono i principali effetti del TDD, ho tralasciato quelli più scontati e noti: meno bug, migliore design ecc…perché la mi sensazione è che dipendano da questi…il design è migliore perché mi concentro su una classe alla volta, la disegno pensando all’interfaccia e penso al comportamento.

Ma il TDD non si impara leggendo un libro o seguendo un corso (nemmeno il mio ), si impara facendolo. Per questo voglio provare a scrivere una serie di post sul TDD per mostrare come un’applicazione può nascere test dopo test. Mi permetto di chiamare la serie “Back to basic” rubando il titolo alla keynote che Paolo Polce ha tenuto all’agileday del 2011.

Perchè UGIALT.net ha chiuso?

ema — Tue, 24 Jan 2012 14:30:28 +0000

Sabato 21 gennaio si è tenuta l’ultima ugialt.net conference, ultima nel senso che non ce ne saranno altre. Basta. Finito. Chiuso.

C’è un filo di dispiacere come per ogni cosa che finisce ma io, Simone e Claudio crediamo che sia stata la cosa più naturale da fare.

UgiALT.net è nata nel 2008, ricordo che nella prima conf eravamo circa una dozzina, Simone ci spiegava il nuovo ASP.NET MVC e Antonio ci parlava di metriche del codice, pochi ma molto attivi e con interessanti discussioni.

Così è nato il gruppo e negli anni è cresciuto tanto dal punto di vista della partecipazione alle conferenze ma non è mai cresciuto dal punto di vista della community visto che a “fare le cose” siamo sempre rimasti in 3. Non c’è polemica, davvero, sappiamo bene che il tempo è sempre meno di quello che si crede e l’organizzazione di una conferenza ne richiede parecchio e chi sceglie di farlo è perché ha una propensione naturale per questo tipo di attività e lo fa divertendosi senza volere ritorni. Poi però un giorno ci si sveglia stanchi e si comincia a pensare ad altri modi per riempire il tempo libero e si devono abbandonare alcune cose a favore di altre.

Poi il ALT.NET è morto. Nessuno più ne parla per la gioia di chi in questi anni ha solo criticato il movimento, le mailing list una volta attivissime oggi vengono riattivate solo grazie a qualche messaggio di spam. Quindi di fatto non ha più senso parlare di ALT.NET. Molti iscritti al movimento sono migrati su altre piattaforme altri invece hanno accettato quei piccoli miglioramenti di Microsoft e sono rientrati nel comodo nido.

In Italia non so che effetti ha avuto il movimento ALT.NET, non sono in grado di misurarlo, spero solo che grazie alle numerose conferenze qualcuno sia riuscito ad avere una visione di cose c’è oltre .NET e magari sia riuscito anche a scrivere un programma su una piattaforma diversa. Se non altro sono sicuro che siamo riusciti a far nascere nuove amicizie e collaborazioni e siamo riusciti a far parlare i fanatici di .NET con persone che la pensano diversamente da loro (ad esempio sabato, è stato bello vedere Ugo che è rimasto affascinato dalla sessione su node.js).

Infine l’ultimo motivo della chiusura è legato alla sostenibilità delle nostre conferenze. UgiALT.net ha sempre cercato di essere una community indipendente e crediamo di esserci riusciti, ci siamo sempre sentiti liberi di parlare di qualsiasi tematica senza avere influenze da sponsor o partner. Ma organizzare una conferenza costa e le donazioni non funzionano.

Giusto per fare 2 conti e per chiarire a tutti come funziona, quest’anno abbiamo raccolto circa 650 euro di donazioni per 190 iscritti, di cui partecipanti circa 150. Se teniamo conto che il GRUSP ha donato 150 euro senza di fatto partecipare vuol dire che ogni partecipante ha donato mediamente poco più di 3 euro. In realtà non hanno donato tutti ma solo 40 persone tra cui numerosi speaker.

A cosa sono serviti i soldi? Abbiamo regalato una maglietta a quasi tutti i partecipanti, abbiamo speso 15o euro per gli adesivi e qualche altra decina di euro per la cancelleria e abbiamo pagato il pranzo e la cena agli speaker. Questo, ancora una volta non è polemica, ma una considerazione che dimostra che una conferenza “gratuita” per noi non è sostenibile. E consideriamo che Avanade ci ha ospitati gratuitamente nella loro sede altrimenti sarebbero servite altre migliaia di euro per affittare le sale.

La morte di UgiALT.net non implica che non ci saranno più conferenze con quel taglio, durante la keynote abbiamo di fatto nominato i nostri eredi e siamo certi che saranno all’altezza. Per quanto mi riguarda avrò più tempo da dedicare a WebDeBs che sta già lavorando sodo e alcune iniziative verranno pubblicate presto.

Professionisti del web: ecco cosa abbiamo fatto noi

ema — Fri, 20 Jan 2012 15:43:53 +0000

Il post sui pagamenti ha fatto un po’ di rumore ed era quello che volevo, i pensieri che ho raccontato sono il sunto di mesi di osservazioni e di situazioni che sono peggiorate col tempo. Verso la fine dello scorso anno abbiamo preso alcuni provvedimenti che vorrei condividere con voi a partire dai contratti.

La prima cosa che abbiamo fatto è stato contattare un avvocato per formalizzare i nostri contratti. Sono più di 5 anni che lavoro come freelance/imprenditore e i miei rapporti con i clienti sono sempre stati regolati da offerte scritte di nostro pugno che spesso non venivano neppure firmate dal cliente. Quindi si basava tutto sulla parola di gentiluomini…e oggi ce ne sono pochi. A ottobre abbiamo contattato un avvocato per capire se c’erano margini di miglioramento. Ci ha ribaltato! Abbiamo fatto 2 o 3 incontri, gli abbiamo spiegato il tipo di attività che facciamo e i problemi ai quali andiamo incontro. Nel giro di poche settimane ci ha preparato una serie di documentazione che ad ogni offerta va allegata a quella che noi chiamiamo documento tecnico. Sono parecchie pagine, condizioni generali, particolari, clausole, ecc…scritte in legalese, e che il cliente deve firmare e mandarci via fax (no email, l’email, purtroppo in italia non ha valore legale) per accettare il tutto. Se anche voi volete rivolgervi ad un avvocato (cosa che consiglio) assicuratevi che abbia un minimo di competenza nel settore informatico altrimenti non sarà facile spiegare cosa fate e cosa vendete.

Avere un contratto di questo tipo ci da una certa tranquillità in quanto li è scritto esattamente quali sono i nostri doveri e i doveri del cliente, ad esempio c’è scritto che se è previsto un acconto, noi non iniziamo a scrivere una riga di codice se non vediamo l’acconto sul nostro conto corrente, c’è scritto che se c’è un giorno di ritardo nei pagamenti ci sarà un ritardo nella consegna del software, c’è scritto che se il cliente non risponde alle nostre domande non potremo continuare lo sviluppo, il tutto in un linguaggio serio e formale che permetterà, sperando che non succeda mai, ad un giudice di decidere chi ha ragione.

Formale, parola che a noi dev puzza ma che è un’altra cosa che dobbiamo imparare. Nel nostro settore è abitudine diventare amici dei clienti fin dal primo incontro, ci si da del tu ancora alla prima telefonata. Questo però rende difficile il rapporto professionale e le eventuali discussioni con il con cliente. Tenere un rapporto più distaccato aiuta tutti a rispettare le posizioni e gli impegni presi e questo non vuol dire essere scortesi ma solo rispettarsi a vicenda: i clienti non sono amici con i quali uscite nel weekend.

Questa formalità insieme ai contratti da un senso di professionalità, fa bene a noi e fa bene al cliente che capisce fin dal primo incontro che non sta avendo a che fare con dei ragazzini inesperti ma con persone che hanno esperienza che sanno il fatto proprio e questa esperienza si ripercuote positivamente anche sul lavoro che faremo. Non nego che alcuni clienti, visto tutto il “malloppo” di carta che devono firmare si sono spaventati ma hanno comunque firmato e rispettato gli impegni.

Professionisti del web…ribellatevi!

ema — Thu, 12 Jan 2012 10:14:22 +0000

Il 2011 è stato un anno particolare: la crisi, la situazione europea, il cambio di governo in Italia hanno mosso le coscienze dei cittadini che sembrano aver iniziato un percorso verso l’acquisizione di un nuovo senso civico (io ci voglio credere )

Da più fonti però si capisce che le cose non vanno benissimo, alcuni fatti.

Ha fatto scalpore, ma non abbastanza, la notizia del suicidio dell’imprenditore veneto che non riusciva a riscuotere i crediti per 200k euro.
Si è parlato molto su twitter di questo post in cui noi italiani siamo dipinti come eroi perché riusciamo a sopportare ritardi enormi nei pagamenti, e nonostante questo ce la facciamo (ma non sempre come abbiamo visto).
Cris ieri su twitter ha scritto: “sono indeciso se cambiare la mia mission in “banca”, visto che sto continuando ad anticipare lavoro (quindi soldi) ai miei clienti. #shit“
In CodicePlastico abbiamo chiuso un buon 2011 dal punto di vista del fatturato ma circa il 40% lo dobbiamo ancora incassare.

A me tutto questo fa molto incazzare, il nostro lavoro è principalmente di tipo intellettuale, fortunatamente non dobbiamo investire soldi in macchinari costosi ma questo non vuol dire che non c’è un’investimento alle spalle. Per poter fare una consulenza su ASP.NET MVC devo passare giornate a studiare, provare, formarmi, tutto tempo che *investo* per poi potermi vendere come consulente alle aziende che ne hanno bisogno. E siccome il mio cliente ottiene valore immediato dalla mia consulenza, io voglio essere pagato immediatamente.

Il proposito per il 2012 che io faccio, ma che vorrei che tutti i professionisti del web facciano, è quello di non concedere termini di pagamento lunghi e lasciar perdere i clienti che vogliono pagare a più di 30 giorni. Io nelle prossime settimane, abbandonerò alcuni clienti che seppur validi, hanno tempi di pagamento a 60 o 120 giorni. Lo faccio per me stesso e invito anche voi a farlo, e più siamo ad imporci più la qualità del nostro lavoro può migliorare.

Per chi non è ancora convinto di quello che ho scritto lo invito a guardare questo video dal titolo esemplare: Fuck you, pay me.

Lascio infine un paio di link sempre sul tema pagamenti, ritardi e pigrizia di Francesco Fullone: uno e due.

Le cose possono cambiare.

Uno sguardo sul mio 2011 da programmatore

ema — Fri, 16 Dec 2011 20:34:34 +0000

Come ogni anno questo è un periodo di bilanci sull’anno trascorso e di propositi per quello nuovo. Oggi sono andato a rileggermi la lista dei todo che a fine 2010 avevo scritto per il nuovo anno e posso dire con orgoglio che ho fatto quasi tutto quello che mi ero ripromesso di fare.

La lista conteneva MongoDb, un nuovo linguaggio di programmazione e partecipare ad un progetto open source.

MongoDb l’ho usato in un paio di piccoli progetti uno in C# e uno in RubyOnRails, in entrambi i casi ho amato la sua immediatezza e libertà nello schema dei dati, devo ancora capire e ragionare su come va modellato l’uso delle collezioni, degli embedded documents e delle relazioni, sono agli inizi, lo strumento è molto promettente (soprattutto in ottica DDD) ma come per tutti i db no-sql vanno affrontati i problemi derivanti da una mentalità relazionale.

Il nuovo linguaggio di programmazione è Ruby, ho scritto parecchio su questo tema, ho fatto un paio di progetti durante l’anno. Ruby è un linguaggio stupendo, di una semplicità elegante, sintetico ma leggibile, e poi c’è la community di Ruby che è attivissima, sforna gemme alla velocità della luce e realizza cose veramente interessanti. Non conosco ancora Ruby come vorrei, anche qui i miei legami con i linguaggi statici rallentano il salto verso il vero potere di ruby che sta nella metaprogrammazione.

Sul progetto OpenSource ci sto ancora lavorando, da un lato è nato conf-oo il sito usato per la ugialt.net che è disponibile su github, è molto prototipale, ha alcune buone idee ma ci si deve lavorare, è nato in fretta in queste ultime settimane vedremo di fare refactoring appena prendiamo fiato. Poi c’è un altro progetto in porto che però è ancora top-secret.

Questi sono stati i 3 todo “consegnati” a fine anno, ora è tempo di pensare al 2012.