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

Alessandro Melchiori

  • 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”.

  • Il processo di bootstrapping di un'applicazione WPF con Caliburn.Micro

    Nel post precedente abbiamo elencato una serie di framework/toolkit utili per il supporto allo sviluppo di applicazioni WPF/SL/WP/W8. Tutti questi framework, tranne MVVM-Light se non sbaglio, hanno il concetto di bootstrapping dell’applicazione, ovvero di setup, configurazione e avvio.

    Questa funzionalità è tanto importante, quanto critica: maggiori sono le facilities che il toolkit ci mette a disposizione, molto meno codice di plumbing siamo costretti a scrivere. Questo però è uno dei primi punti che possono darci feedback immediati su quanto bene possa essere scritto un toolkit. Il framework scelto deve essere a supporto e non vincolare in scelte/implementazioni. Già da questo, come ho avuto modo di scrivere già in passato (qui), Prism se ne esce con un “rating” non del tutto sufficiente (visti i tentativi falliti riportati qui e qui)

    In questo post, vedremo come Caliburn.Micro approccia il problema.

    Per prima cosa installiamo, tramite nuget, il package “Caliburn.Micro”

    Creiamo ora una coppia “view” - “viewmodel”, ponendo particolare attenzione al fatto che i nomi devono, se vogliamo sfruttare out-of-the-box il sistema di convenzioni messo a disposizione dal toolkit, seguire il pattern “XxxView” - “XxxViewModel”. Nel nostro caso ShellView e ShellViewModel, come mostrato nell’immagine seguente:

    Caliburn.Micro, così come Radical, sfrutta pesanetemente il paradigma “convention over configuration” per semplificare drasticamente la vita allo sviluppatore, fornendo, praticamente a costo zero quasi tutta l’infrastruttura per fare wire-up dell’applicazione. Questa feature, è una delle discriminanti che ci hanno fatto preferire questi toolkit agli altri. Il livello di customizzabilità delle convenzioni, che valuteremo nei prossimi post per entrambi i toolkit, è uno dei parametri che ci permetteranno di valutare la bontà (o meno) dei framework in oggetto.

    Tornando a noi, manca vermante poco, per poter avviare, finalmente, la nostra applicazione: il bootstrapper. Con il seguente snippet di codice e la customizzazione dello xaml dell’applicazione abbiamo soddisfatto i requisiti minimi per poter integrarci e iniziare a sfruttare le potenzialità di Caliburn.Micro

    
    
    
    

    Premiamo F5, et-voilà l’applicazione magicamente parte senza aver fatto o configurato nulla di particolare.

    Nel prossimo post della serie vedremo se e come approcciare lo stesso problema con Radical