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

Alessandro Melchiori

  • MVP su Azure...#estiqaatsi

    A conferma del periodo incasinato della mia vita, non solo lavorativa, mi ritrovo solo oggi, quasi una settimana dopo, a scrivere di quanto mi è successo la scorsa settimana. Giovedi scorso, 1 ottobre, ho ricevuto una mail "particolare": sono MVP su Windows Azure. Lungi da me il pensiero di fare un post auto celebrativo, ci mancherebbe...volevo solo ritagliarmi poche righe per i ringraziamenti, che di rito non sono mai.

    Essendo un premio che arriva dalle community, non posso far altro che ringraziare la community e in particolar modo la community di ugidotnet, che mi ha accolto ormai dieci anni fa, mi ha fatto crescere e mi ha dato l'opportunità di contribuire alla community stessa partecipando agli eventi in qualità di speaker o pubblicando articoli. Insomma, grazie ad ognuno di voi.

    Una piccola nota di "merito" va però a tre persone in particolare, che hanno avuto un ruolo importante nella mia crescita, non solo professionale. Li cito in ordine alfabetico per non fare differenze...non potete nemmeno immaginare come certi "guri" possano essere permalosi :)

    • @andysal74: è stato il mio primo contatto con la community, ad un evento UgiDotNet, ormai tanti anni fa. Durante la sua sessione (su domain model, lazy load, identity map...what else?) ricordo di aver ammirato questo "strano personaggio" che condivideva, "for free", la sua conoscenza con gli altri. Strano! In nessun altro contesto questa cosa sarebbe realizzabile. Riuscite ad immaginare un avvocato che fa lo stesso con i suoi colleghi/concorrenti? Vabbe...il problema è che questa cosa, questo desiderio di condividere, si è acceso anche in me e non si è più spento...non so se per voi è un bene o meno. Se sono qui, è anche perchè 10 anni fa ho avuto Andrea come primo esempio di cosa significa "essere" community. Nel frattempo è diventato pure un caro amico. Se non fosse interista sarebbe quasi perfetto ;)
    • @emadb: sono più di sei anni che si lavora e si cerca di costruire qualcosa di importante insieme. Sono più di sei anni che ascolta i miei deliri tecnologici riportandomi di tanto in tanto con i piedi per terra e condividendo con me il desiderio di crescere sempre. E' soprattutto grazie a lui che sono riuscito e riesco a ritagliarmi il giusto tempo da dedicare alla community. Insomma, detto in altre parole, ho trovato il modo di far lavorare qualcun altro al posto mio :)
    • @mauroservienti: che dire...quando lavori con Mauro capisci che hai un sacco di cose da imparare, ti rendi conto che la strada è ancora lunga e che c'è sempre qualcuno più avanti di te. Lavorando con lui ho imparato veramente tanto, non solo sotto il punto di vista tecnico, ma anche e soprattutto, il "gusto" e il piacere di migliorarsi per lavorare sempre meglio. E' stato veramente piacevole condividere con lui il lavoro su diversi progetti, chissà che in futuro non si possa tornare a lavorare a stretto contatto :)

    Tante parole per dire semplicemente...GRAZIE!

  • 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"