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

Alessandro Melchiori

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

  • Blogging with octopress on windows

    Come ha già anticipato emaqui, il blog di codiceplastico ha subito la prima di una lunga serie di modifiche a cui sarà sottoposto (spero) nei prossimi mesi. Per ora stiamo parlando solo di “modifiche” infrastrutturali: è stato spostato da una server virtuale su Aruba, a github.

    Ma la modifica più sostanziale è stata quella relativa alla scelta del blog engine: abbiamo deciso di migrare dal famoso wordpress ad una engine ben più light, ma più in linea con le nostre esigenze…octopress

    Perchè questo “cambio di direzione”? Essenzilamente perchè eravamo alla “ricerca della semplicità” :)

    Per quale motivo abbiamo bisogno di un db, pagine dinamiche (and so on) per un blog engine, quando una volta scritto un post, altro non è che una pagina statica che non cambierà mai e poi mai, ma che anche in caso di cambiamento possiamo facilmente rigenerare? Avere “il sorgente” dei nostri post non all’interno di un database (con tutte le operazioni di maintenance che ne conseguono), ma in semplici file *.markdown, nel caso di octopress, salvati su file system, ancora più facilmente backuppabili, è stato un altro dei capisaldi della scelta.

    Detto questo, sul sito di octopress ci sono tutte le indicazioni per il setup su mac o linux, ma su windows? Funziona tutto anche lì? Anticipo la risposta: ovviamente sì, visto che io sto proprio bloggando da lì
    Essenzialmente octopress, banalizzando molto, altro non è che una serie di rake task che ci permettono di configurare, generare, deployare il nostro blog. Quindi diciamo che il primo passo è avere ruby, o meglio, la versione supportata di ruby (1.9.3) installata.

    Come fare? Ho trovato un bel progetto open source che simula, anche sul SO di casa Microsoft, i comportamenti di rbenv o rvm. Ecco a voi: yari

    I passi per il setup sono veramente rapidi ed indolore:

    • clone del repository di yari (per esempio in d:\tools\yari)
    • aggiunta di d:\tools\yari\bin al path
    • installare la versione desiderata di ruby con il comando: yari 1.9.3

    Fatto questo siamo a metà dell’opera: ora possiamo clonare il repository di octopress e seguire le istruzioni che troviamo sul sito per configurare il blog e iniziare a bloggare. Ci sono una serie di plugin già pronti all’uso, come l’integrazione con twitter, con disqus, e chi più ne ha più ne metta.

    Tutto ha funzionato al primo colpo, nessun problema di setup o altro, bisogna solo imparare un po’ la sintassi di markdown per scrivere e presentare il post in un modo decente :), ma con una console e un editor di testo siete up&running in pochi minuti.

    Unica piccola nota: potrebbe capitare che uno dei task ruby, quello per la generazione vera e propria del sito, faccia “a cazzotti” con il code-page della vostra console, generando un errore del tipo

    Liquid Exception: incompatible character encodings: UTF-8 and IBM437 in index.html   
    
    

    Per ovviare a questo problema basta cambiare il code-page di default, ad uno che sappia digerire i caratteri UTF, con il comando

    chcp 65001
    
    

    Fatto questo dovrebbe essere tutto ok :) Che altro dire…happy blogging!!!

  • I prossimi appuntamenti...e quelli appena passati

    Nell’ultimo periodo siamo stati parecchio presi con diversi progetti che hanno finalmente preso la luce…purtroppo il blog ne ha risentito. Cerchiamo di rimediare fin da subito…partendo dalla fine :)

    La scorsa settimana ho avuto il piacere di partecipare ai CommunityDays e l’onore di poter dare il mio (piccolo) contributo in qualità di speaker. L’evento è stato, come al solito, “impareggiabile”: organizzazione impeccabile, più di 700 partecipanti, sessioni e speaker di altissimo livello.

    La mia sessione era incentrata su due “tecnologie” che, nell’ultimo anno, mi hanno e mi stanno particolarmente appassionando: Azure e MongoDb. Abbiamo avuto modo di vedere la (relativa) facilità con cui è possibile fare setup di un ambiente che gestisca caratteristiche di high availability e automatic failover, tramite le repliche e scalabilità orizzontale tramite lo sharding, il tutto condito con l’enorme vantaggio della scalabilità offerta da Azure. Insomma ci siamo parecchio divertiti…

    Ed eccoci arrivati ai next step :)

    • domani sera ci sarà il tradizionale appuntamento organizzato da webdebs, il famoso brainpirlo, in cui avrò l’occasione di parlare di DDD, CQRS ed event sourcing. La “platea” è solitamente molto esigente, spero di esserne all’altezza. L’idea della serata è di mostrare un caso reale, in pieno spirito “for-real”, di come, in codiceplastico abbiamo gestito e gestiamo scenari più o meno complessi, in cui i behaviour in gioco sono l’emblema del sistema e l’interazione tra le parti, semplice o complessa che sia, concorre al risultato finale.

    • tra due settimane è già ora di codemotion e anche in quell’occasione dovrete sorbirvi un po’ dei miei vaneggiamenti. La sessione sarà incentrata sulla parte più “bistrattata” di CQRS, ovvero la “R”, la lettura. Vedremo come possiamo trarre vantaggio da alcune caratteristiche di MongoDb per la parte di denormalizzazione senza rinunciare a scalabilità e HA, caratteristiche insite nell’engine del famoso database documentale.

    Altre cose bollono in pentola, sempre su #azure, #mongodb, #nosql, #cqrs/es/ddd…alcune community si muovo in questa direzione e noi assecondiamo. Quindi stay tuned, l’anno è da poco iniziato, ma mi sto già divertendo come un matto.

  • Query polimorfiche con il table storage

    Il table storage è l’implementazione, messa a disposizione da Windows Azure, di un datastore NoSQL, ideale per lo storage di dati strutturati, che non necessitano del concetto di “relazionalità”.

    Con la nuova versione della “client library” per .Net sono state introdotte diverse feature interessanti. Fra queste la possibilità di interagire con la “pipeline” di serializzazione/deserializzazione di un’entità.  Questa possibilità apre scenari che prima di questo rilascio non erano (facilmente) implementabili.

    In questo post vedremo come supportare, con poco sforzo, query polimorfiche con il table storage.

    In prima battuta, ridefiniamo per la root della nostra gerarchia, il metodo di serializzazione, aggiungendo, oltre all’implementazione “standard” che prevede la serializzazione di tutte le property pubbliche, anche una nuova property “calcolata” che corrisponde al tipo concreto che stiamo persistendo:

    
    

    …ed ora, innestiamoci effettivamente nella pipeline, con un’implementazione ad-hoc del delegate EntityResolver:

    
    

    In questo modo possiamo scrivere una query polimorfica, sfruttando il fatto che, prima dell’ “idratazione” delle property della entity, possiamo utilizzare una logica custom (tramite una factory o altro), per la creazione del tipo concreto, ottenendo, con poco sforzo, il risultato cercato:

    
    
  • Il processo di bootstrapping di un'applicazione WPF con Radical

    In questo post vedremo, alla stessa stregua di quanto fatto in un post precedente, il dettaglio delle operazioni da eseguire per avere un’applicazione WPF up-and-running sfruttando Radical come toolkit di supporto.

    Per prima cosa installiamo, tramite nuget, tutti i packages necessari al corretto funzionamento del toolkit. Il root-package è Radical.Windows.Presentation.CastleWindsor

    A differenza di Caliburn.Micro, il “dependencies-tree” è assolutamente più corposo. Radical fin dall’inizio introduce il concetto di IoC container, fornendo un’implementazione out-of-the-box basata su Castle.Windsor. Il partizionamento dei progetti e delle dipendenze però sembra (e verificheremo nei prossimi post che è effettivamente così) ben fatta, garantendo potenzialmente un alto grado di customizzabilità.

    Radical, così come abbiamo già visto per Caliburn.Micro, basa il suo funzionamento di default su un motore di convenzioni che dovrebbe garantire una curva di setup dell’applicazione molto bassa, se sfruttato nella sua configurazione standard. Anche per Radical la coppia view+viewmodel è la base di partenza, con il pattern che abbiamo visto essere valido anche per Caliburn.Micro. Per fare in modo però che i componenti in gioco (view e viewmodel) siano correttamente registrati all’interno del container, devono appartenere ad un namespace che soddisfa il seguente pattern : “*.Presentation”. Per soddisfare questo requisito, basta creare una folder “Presentation” all’interno del progetto che funga da aggregatore per View e ViewModel, come mostrato nell’immagine seguente:

    Fatto questo, basta attivare il bootstrapper, nel code behind dell’applicazione, come mostra lo snippet seguente:

    
    

    Quello che fa, dietro le quinte, il toolkit è quello di creare l’entry point dell’applicazione (la view indicata nel tipo generico), creare il relativo viewmodel, e agganciare quest’ultimo al DataContext della view stessa in modo da avere la garanzia che tutto sia correttamente setuppato prima dell’avvio dell’applicazione.

    Pochi istanti e, anche con Radical, l’applicazione è “runnabile”.