alessandro melchiori
() => melkio.OnStage();

Alessandro Melchiori

  • Arrivederci CodicePlastico

    Questo e’ un post un po’ particolare, non tecnico come solitamente faccio su questo blog, ma piu’ personale.
    Quello che sta per iniziare e’ un mese “strano”, il mio ultimo mese in CodicePlastico…e’ da un po’ che valutavo questa possibilita’ stufo di dover combattere con la burocrazia italiana, con la difficolta’ (impossibilita’?) di fare impresa in Italia. Sapevo che prima o poi sarebbe successo, sapevo che sarei arrivato ad un punto di non ritorno….lo so, mi conosco. Quando alla mia porta si e’ presentata una grande possibilita’, ho pensato che fosse almeno arrivato il momento di provare a cambiare.

    Va be…non voglio dilungarmi troppo…l’obiettivo del post e’ un altro: volevo usare questo canale per ringraziare Emanuele, amico e collega di questi ultimi 6 anni. Ci abbiamo provato, ci siamo anche riusciti, ma alla fine, anche a causa di “visioni” differenti abbiamo deciso “di rimanere solo amici” :) Non posso che augurare a lui e a tutto il team di CodicePlastico di continuare sulla strada tracciata: la strada della qualita’, del desiderio di fare sempre meglio, del volersi sempre migliorare.

    Cosa mi aspetta ora? Non posso ancora dire l’azienda in cui andro’ per problemi di NDA, almeno fino alla firma effettiva del contratto. Mi trasferiro’ a Zurigo, prima io e, spero presto, anche il resto della mia famiglia. Nel mio prossimo futuro vedo tanto javascript, ma tanto, tanto, tanto…

    Ciao super-eroi! E’ stato un piacere fare parte della vostra squadra. In bocca al lupo

  • My road to F#

    Sono da sempre innamorato di C# e del suo essere un linguaggio “fresco e pulito”, ma non posso che affermare che questa feature vale il prezzo del biglietto:

    let (success, value) = Int32.TryParse("10")
    

    Mai piu’ ‘out’ in vita mia :)

  • Io, me e R#

    Sono sempre stato un grande fan di R#: il giusto completamento di un ottimo IDE come Visual Studio.
    E’ vero, nei suoi primi anni di vita, le performance non erano delle migliori e l’utilizzo delle risorse particolarmente “esoso”. Con il passare del tempo grazie alle ottimizzazioni apportate al tool e alla possibilita’ di sfruttare macchine sempre piu’ carrozzate (RAM e SSD in primis) il peso si avvertiva sempre meno.

    Circa un anno fa, pero’, mi sono accorto di alcuni spiacevoli side-effects nell’utilizzo di R#:

    • facendo spesso mentoring, quando mi trovavo a lavorare con sviluppatori che non avevano/potevano installare il tool, la produttivita’ ne risentiva pesantemente, rischiando di farmi fare la parte del “dislessico da tastiera”
    • lavorando su una soluzione piuttosto corposa, che utilizzava pesantemente pacchetti Nuget, per la gestione del versioning e delle reference cross-modulo, R# aveva (ha?) lo spiacevole vizietto di aggiungere le reference, con un semplice Alt+Enter, ma non attraverso il pacchetto nuget, bensi’ agganciando la prima versione che trovava in una qualche folder di output di progetto creando non pochi problemi a catena…oltre a quelli che nuget genera di suo…ma questa e’ un’altra storia :)

    Ma la cosa piu’ spiacevole di cui mi sono accorto e’ che il tool, di cui continuo a ritenermi uno “sponsor”, sembra spegnere la testa di (alcuni) dev: a colpi di Alt+Enter e Alt+Ins si creano classi e costruttori, si aggiungono reference o si “iniettano” dipendenze alla velocita’ della luce, limitando qualsiasi pensiero di buon design.
    E’ troppo semplice, con pochi shortcut, delegare al tool la scrittura di un “botto” di codice. E’ talmente veloce che non si ha quasi nemmeno il tempo di pensare…e poi ci si ritrova, per esempio, con classi con 10 dipendenze…
    Se ci pensiamo bene non veniamo pagati per quanto veloce pigiamo sulla tastiera, ma per la qualita’ del lavoro che facciamo e quindi del codice che produciamo…o almeno cosi dovrebbe essere. Lo so, essendo in Italia, sono un inguarible idealista…

    E allora mi sono deciso a disinstallarlo. Vi lascio solo immaginare cosa ha comportato, in termini di produttivita’ all’inizio, ma poco a poco mi sono adattato ai (pochi) shortcut integrati nell’IDE, ma me li sono fatti bastare.
    Ogni singola operazione mi costa, potenzialmente, di piu’, ma proprio per questo extra-time (si parla di 1 o 2 secondi) ho avuto modo di poter pensare una volta di piu’ a quello che stavo facendo…e vi posso assicurare la qualita’ del codice prodotto ne ha giovato…o almeno cosi’ mi sembra

    Ok, detto questo, credo che lo reinstallero’ :) E sapete perche’?
    Perche’ qualsiasi tentativo di trovare un “runner” per i test all’altezza di quello integrato in R# ha dato esito negativo: sia in termini di velocita’ di esecuzione, sia nella fase di discovery dei test, sia nel livello di dettaglio dell’output e in tanti altri piccoli aspetti.
    Per intenderci, se ogni volta che lancio un test devo aspettare un paio di secondi per avere un feedback, oltre che della produttivita’ ne va anche della mia salute mentale.

    Vi assicuro che l’unico motivo per cui, penso, reinstallero’ R# e’ proprio questo. Per il resto, si puo’ fare (cit.), si puo’ vivere senza R#: “Sono Alessandro, un dev, e da piu’ di un anno lavoro senza R#”…pero’ forse lo reinstallo :)

  • Eventual consistency...ma de che?

    Ma cos’e’ questa benedetta “eventual consistency” di cui tanto si parla? Inizio fermamente a credere che sia la nuova buzzword per classificare i failure dei sistemi come “feature by design” :)

    Ma cosa significa veramente “eventual consistency”? Potremmo discuterne per un tempo infinito colorando la definizione con tante sfumature diverse e tutte potenzialmente corrette. L’unica cosa di cui sono certo e’ che non vuole dire vedere/usare dati “ad minkiam” (cit.)

    Quando si ha a che fare con un sistema distribuito, non si puo’ spingere indiscriminatamente sull’acceleratore nelle tre direzioni: consistency, availability e partition tolerance. Da qualche parte bisogna rilassare i constraint, e una di queste possibilita’ e’ quella di sposare il concetto di “eventual consistency”.
    Ma dove/quando questo ha senso? Dove possiamo permetterci di non avere dati consistenti? E poi cosa significa avere dei dati “potenzialmente non consistenti”?
    In tutto questo marasma il concetto di aggregate tanto caro a chi, come me, bazzica il mondo DDD e’, per me, stato fondamentale: un aggregate, essendo l’unita’ minima di consistenza del mio sistema, non puo’ mai essere in uno stato inconsistente: o c’e’ o non c’e’. In un dato istante temporale, un ordine con tutti i suoi item o c’e’ o non c’e’, ma di sicuro non ho l’ordine con alcuni degli item si e altri no, giusto per fare un esempio.

    Quando siamo in un ambito distribuito, ne siamo consapevoli e, soprattutto, ne abbiamo veramente bisogno il design e l’infrastruttura del sistema devono essere consci di questo piccolo particolare e poter, eventualmente, compensare e gestire situazioni di consistenza eventuale.
    Non sto dicendo che e’ una cosa semplice, ma in certi scenari non si puo’ proprio fare diversamente. Il sistema (potenzialmente) e’ piu’ complesso, ma non per questo deve risultare non affidabile.

    Ovviamente il design e il partizionamento devono essere fatti “cum grano salis”: sono le logiche di business, una giusta definizione dei confini di ogni bounded contex, per tornare in tema di DDD, e la nostra esperienza che ci guidano in questa attivita’ tanto critica quanto fondamentale. La scelta corretta ci permette veramente di rilassare (un po’) i vincoli piu’ stringenti e garantire comunque la correttezza del sistema.

    Ultima domanda/considerazione che cerco sempre di tenere in considerazione quando ho a che fare con questi scenari: ma per quanto tempo sono eventualmente consistente?. Tendenzialmente la risposta e’ sempre un…“tanto casino per nulla”

  • DDDHandsOn - (quasi) un mese dopo

    Dopo il necessario mese di decompressione delle idee e delle sensazioni (o meglio questa e’ la scusa migliore che ho trovato per giustificare il ritardo del post) posso dire che l’esperimento che abbiamo provato con lo [@ziobrando] (http://twitter.com/ziobrando) e il [team di Avanscoperta] (http://www.avanscoperta.it/en) e’ assolutamente riuscito. Come “quale esperimento”? Ma il [workshop su DDD] (http://www.avanscoperta.it/it/training/hands-on-domain-driven-design-workshop-2014-2/)

    Il tema era ovviamente uno di quelli a me tanto cari: Domain Driven Design, ma visto con gli occhi dello sviluppatore e soprattutto con “le mani” di chi, ogni giorno, deve “pigiare tasti” e risolvere problemi.

    Tutto parte da una giornata “preliminare” di [#eventstorming] (http://ziobrando.blogspot.it/2013/11/introducing-event-storming.html#.U1jA1_mSyrI) in cui, con la “schiettezza” di un approccio visuale, si sviscera un (qualunque) processo di business, evidenziando cio’ che accade (o dovrebbe accadere) nel sistema e facendo emergere ogni possibile criticita’, garantendoci, “out-of-the-box” una visione molto dettagliata di quello che dovremo andare ad implementare. Nei due giorni seguenti si passa alla fase operativa.

    In prima battuta, per l’appuntamento di Roma, si era pensato di partire da una infrastruttura di base minimale, ma che permettesse a tutti di avere gia’ del codice su cui lavorare durante i giorni del workshop, in modo da non doversi soffermare solo su dettagli tecnici, ma potersi spingere un po’ piu’ a fondo nei meandri di una possibile implementazione di CQRS, di un EventStore, e magari, perche’ no, arrivare a capire/intravedere quali sono gli approcci da seguire, gli scenari e le problematiche in cui ci si imbatte nel momento in cui si ha a che fare con un sistema veramente distribuito.

    Nella seconda puntata, quella di Bologna, abbiamo fatto un passetto indietro: zero codice preparato, si crea tutto “from scratch”. Questo ci ha permesso di coprire una platea tecnologicamente piu’ eterogenea (java, .Net, nodejs…) e permettere ad ognuno di rimanere nella propria comfort zone tecnologica. Mani sulla tastiera, in (quasi) modalita’ randori e…l’approccio si e’ rivelato assolutamente vincente.
    Essenzialmente per due motivi: non essendoci una guideline da seguire, ognuno aveva carta bianca sulle possibili soluzioni. E quando metti nella stessa stanza otto teste pensanti quello che ne “salta fuori” e’ sicuramente una due giorni di qualita’…e poi, in questo modo, io non ho dovuto preparare nulla :)
    Evento dopo evento, comando dopo comando, ma soprattutto test dopo test, abbiamo iniziato a dare risposte a quello che il business, evidenziato nella prima giornata, ci chiedeva.

    Come al solito, in questi casi, le parti a corollario (colazione, pranzo e cena) non sono meno importanti: insomma una 48 ore non stop su DDD, CQRS ed EventSourcing (e MongoDB, Azure, RabbitMQ, ServiceBus, sistemi distribuiti…) che mi hanno veramente soddisfatto. Mi sono divertito un sacco e sentirsi dire “ma allora si puo’ fare” e’ stata la soddisfazione migliore. Abbiamo centrato il bersaglio.

    Che dire poi del “compagno di merende”? @ziobrando lo conoscete: divertente, simpatico, chiacchierone…ah si, dimenticavo…e’ anche un sacco preparato sull’argomento :)

    Presto si replica e altre cose interessanti sono in cantiere…quindi, che dire: stay tuned!!!