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

Alessandro Melchiori

  • Bentornato SQL Server

    E’da un po’ di tempo che ho in mente di scrivere questo post. Come al solito, sono in ritardo :)
    Vediamo di rimediare…

    Chi mi conosce sa che, fin da tempi non sospetti, sono stato un “acceso” sostenitore di mongodb.
    Al tempo mi aveva attirato per la sua semplicità di utilizzo, dall’installazione all’interazione stessa: un veloce download e l’esecuzione dell’engine è a distanza di un click.

    Prima che orde di DBA inferociti mi rincorrano alla prossima conferenza, ci tengo a sottolineare che comprendo perfettamente la necessità di un’installazione e configurazione accurata di qualsiasi strumento, database in primis. Ciò non nega il fatto che, in fase di sviluppo, un processo di setup molto lungo/complesso o un’interazione non ottimale introducono una frizione che impatta sulla produttività stessa del team.

    Tornando a noi…negli ultimi anni MS, con SQL server, ha fatto un lavoro incredibile, migliorando di versione in versione l’engine, e introducendo una serie di feature che hanno fatto scalare a SQL Server la mia personale classifica, portandolo nuovamente nelle primissime posizioni.

    SQL Server e docker

    Con l’introduzione e il supporto a docker, in un colpo solo, MS ha risolto tutte le mie frustrazioni per un’installazione silent di SQL, in modo automatico tramite per esempio vagrant. Chiunque ci abbia mai provato, sa di cosa sto parlando…potrebbe essere il topic per un nuovo post.
    Con la possibilità di eseguire l’engine di SQL all’interno di un container docker, la frizione per un nuovo dev che deve fare setup dell’infrastruttura prima di poter fare F5 è a distanza di uno script.

    SQL Server e il supporto a json

    Altra “frustrazione frustrante” per noi dev è la famosissima impedence mismatch tra modello relazionale e modello object-oriented, che ci ha portato, nel corso degli anni a provarle un po’ tutte, passando da StoredProcedure agli ORM più o meno light e a…chi più ne ha più ne metta.
    Il modello documentale, tipico di MongoDB e altri db no-sql, risolvono up-front questa difficoltà: niente tabelle e relazioni, ma documenti.
    Da un paio di versioni, però, anche SQL Server ha il supporto nativo a json, con la possibilità di indicizzare attributi del documento a diverso livello di profondità garantendo al contempo un modello diverso da quello relazionale (quello documentale, appunto) e ottime performance.

    SQL Server e il modello a grafo

    Un nuovo modello si è aggiunto a quelli supportati: il modello a grafo. L’engine è lo stesso ma l’approccio è sostanzialmente differente: anche in questo caso vige la regola per cui diversi scenari hanno necessità differenti e soluzioni/tool diversi.
    Il fatto di avere un’unica tecnologia che li supporti tutti è un grande vantaggio, perchè permette di limitare le componenti infrastrutturali del sistema e quindi abbassare il costo della manutenzione e del monitoring.
    Nulla vieta ovviamente di valutare ulteriori tool qualora lo scenario da approcciare sia così specifico da non potere essere risolto con una tecnologia “cross”. A questo punto il costo di un nuovo componente è assolutamente compensato dalla specificità dello scenario e dai benefici introdotti da un tool specifico.

    SQL Server e Azure

    Ho lasciato volutamente per ultimo questo punto, ma ciò non significa che abbia meno importanza dei precedenti. Anzi…assume un ruolo cardine nelle mie scelte quando l’applicazione che sto progettando e su cui sto lavorando deve “funzionare nel cloud”.
    In questo scenario avere SQL Server, in modalità PaaS è “tanta roba”: significa potersi dimenticare di configurazione e monitoraggio perchè forniti direttamente dalla piattaforma. Significa poter sfruttare tutte le metriche raccolte dalla piattaforma stessa su tutti i servizi SQL Database attivati da tutti gli utenti, per ottimizzare o suggerire ottimizzazioni sulla nostra istanza. Significa avere un livello del servizio difficilmente ottenibile in uno scenario on-premise.

    Tante altre sono le caratteristiche interessanti di SQL Server (infatti non abbiamo parlato di In-Memory OLTP o Columnstore indexes)…diciamo che il pretesto del post era di riportare nella giusta prospettiva il mio modo di vedere e approcciare l’utilizzo di SQL Server.
    Che posso dire: “Welcome back SQL Server”…certi amori non finiscono, fanno dei giri immensi ma poi ritornano :D

  • CodicePlastico e il nostro processo di hiring

    Ho letto con molto interesse il post degli amici di Gummy con un po’ di suggerimenti su cosa non fare per aumentare le proprie possibilità di essere presi in considerazione durante il loro processo di recruiting.

    Ci sono diversi passaggi che condivido in pieno e che si sposano perfettamente anche alla realtà che vivo tutti i giorni, quella di CodicePlastico:

    …siamo un team piccolo, ogni persona che aggiungiamo cambia la nostra struttura in modo sostanziale…

    …scegliere le persone è veramente difficile. È un processo faticoso e la possibilità di sbagliare è altissima…

    Con questi presupposti, il processo di hiring assume un ruolo fondamentale e in CodicePlastico, di iterazione in iterazione, stiamo cercando di renderlo sempre più affidabile, attingendo anche da esperienze personali, come per esempio quello che ho potuto “toccare con mano” collaborando con i ragazzi di Particular per circa un anno.

    Il nostro processo di hiring è generalmente suddiviso in diversi step:

    Un primo colloquio conoscitivo, per le dovute presentazioni. In questo modo il candidato può raccontarci un po’ di lui, spiegarci le sue eseperienze, sottolineare cosa gli piace fare e cosa no. E’un modo, anche per noi, per presentare il nostro team, per spiegare come lavoriamo e in quali scenari, quali tecnologie utilizziamo e quali ci piacerebbe utilizzare.
    Come scriveva Mauro in un suo post, obbiettivo di questo “incontro” è quello di trovare i no secchi.
    Quindi “caro candidato” se ti presenti con mezz’ora di ritardo al colloquio, se chiacchierando mi dici che sei un buon grafico/designer perchè conosci abbastanza bene jQuery, oppure se fai scena muta e non sei capace di gestire una conversazione (non tecnica)…bhe, allora non dare colpa alla crisi.

    Al termine del primo incontro, se c’è interesse reciproco a continuare (si, reciproco…ad alcune persone non sempre possiamo andare a genio) scegliamo un kata su cui il candidato potrà lavorare da casa, senza fretta, con la tecnologia che preferisce, con gli strumenti che preferisce. Senza pressione.
    Terminato l’esercizio, basta pushare quanto prodotto sul proprio account github e mandarci una mail per dare il via al prossimo step.
    Quindi “caro candidato” se quando ti diciamo di pushare su github ci guardi come se ti avessimo detto una parolaccia, se ti lamenti del fatto che ti facciamo lavorare fuori dall’orario lavorativo, se dopo cinque mesi stiamo ancora aspettando la mail con il link al tuo lavoro…bhe, allora non dare colpa alla crisi.

    Terzo step: se hai concluso il kata (e soprattutto ci hai mandato la mail per dircelo) c’è sempre un terzo step. Hai lavorato? E’ giusto confrontarci per capire il tuo approccio alla soluzione, farti le nostre domande e osservazioni.
    Questo passaggio è per noi fondamentale perchè permette di iniziare a conoscere la persona che abbiamo di fronte: il nostro è un lavoro di team, è impensabile poter inserire in modo proficuo una persona che non accetti, per esempio, osservazioni/domande sul proprio operato.
    Al termine di questa prima review, passiamo ad un esercizio pratico, un nuovo kata, da fare insieme. Questo ci permette di capire un po’ di più sul reale livello tecnico del candidato, la sua “dimestichezza con la tastiera” e soprattutto il “livello di connettività” tra il cervello e le mani, considerando nella valutazione anche la variante “pressione”.
    Al termine di questo step c’è la prima, vera scrematura. Obbiettivo di questo incontro è trovare i probabili sì

    Ultimo incontro: bhe se sei arrivato qui, diciamo che abbiamo alte possibilità di essere compatibili, almeno dal nostro punto di vista.
    L’ultimo incontro è più una chiacchierata, non solo tecnica. Potrebbe capitare di pensare insieme ad una soluzione, anche architetturale, ad uno dei problemi su cui stiamo lavorando, oppure parlare di metodologia, oppure di panzerotti.
    Sicuramente in questo incontro si parla di soldi e di tutto quello che ci serve per formalizzare una “lettera d’intenti”.

    Questo è il nostro processo. Può essere migliorato? Sicuramente sì…ci sono già nuove idee in cantiere. Per esempio coinvolgere anche il resto del team nella valutazione, cosa che adesso avviene solo raramente (se io o emanuele non siamo presenti). Magari fare il kata in pair con uno “di noi”, oppure…

    Tutto il processo richiede un po’ di tempo. Nè troppo, nè poco. Ma è un investimento. E’una cosa di cui non possiamo fare a meno, per abbassare, almeno un po’, le possibilità di errore.

    Ah dimenticavo…se sei interessato, noi siamo sempre alla ricerca di nuovi super eroi :)

  • Global Azure Bootcamp 2017 e non solo...

    La scorsa settimana ho avuto il piacere e l’onore di partecipare al Global Azure Bootcamp a Pordenone organizzato dagli amici di Innova. Un evento sul cloud, un evento su Azure. Un evento ricco di spunti interessanti e anche la consueta occasione per rivedere vecchi amici e incontrarne di nuovi.

    Nel corso della mattinata ho avuto l’occasione di parlare di docker e di come sfruttare i servizi messi a disposizione da Azure per poter ottimizzare “l’esperienza del dev” nel corso di tutto il ciclo di sviluppo di un’applicazione.
    Abbiamo quindi parlato di Azure Container Registry per la persistenza e la gestione delle immagini docker prodotte. Abbiamo visto Azure Container Service come piattaforma per il deploy e la gestione di un cluster docker, con Docker Swarm. Abbiamo “chiuso il cerchio” definendo una pipeline di CI/CD con Visual Studio Team Services: dalla modifica del codice, al deploy in un click.

    Questa volta non ero il solo (pazzo?) a parlare di docker :) Maksim Sinik ha tenuto un bellissimo talk su kubernetes e sulla sua intgrazione con Azure Container Service.

    La sensazione è che in Italia si parli, e soprattutto si utilizzi, ancora poco docker. Attenzione, non è sicuramente la panacea a tutti i mali: se una codebase è un colabrodo, con docker la situazione non migliora, anzi…
    Ma non si può pensare di vivere in “questo mondo” e non essere a conoscenza di questo potente strumento (my 2 cents)

    Ed ora? Non ci si ferma mai…la prossima settimana, con gli amici di UgiDotNet saremo a Milano con un evento interamente dedicato al cloud.
    L’agenda non è per nulla male e copre diversi aspetti dell’ecosistema “cloud”: dai dati alla parte compute, dai container alle strategie di migrazione…insomma tutti gli ingredienti per trasformare una semplice giornata in una giornata interessante e proficua.

    Insomma…vi aspetto!!!

  • Docker & Azure

    Venerdì 10 febbraio sarò a Roma dagli amici di DomusDotNet e GetLatestVersion per una ricca giornata di contenuti sul tema DevOps.

    Nel mio piccolo terrò una sessione su Docker e Azure. L’abstract è abbastanza esplicativo (almeno credo):

    Hai visto un paio di tutorial introduttivi su docker? Sai come avviare un container o come creare una nuova immagine partendo da una gia’ presente sul docker hub? Ma vuoi saperne di piu’…questa e’ la sessione che fa per te: analizzeremo casi reali di utilizzo congiunto di docker e Azure, quali per esempio l’integrazione nella pipeline di Continuous Integration, come creare un hub privato o come supportare scenari di scale-out.

    L’idea non è quella di un tutorial passo-passo e introduttivo sul mondo dei container e di Docker nello specifico. Vuole portare la mia esperienza in uno scenario mediamente complesso su cui stiamo lavorando in CodicePlastico e su come, Docker e Azure, possono semplificare la vita del team, sia nella fase di sviluppo, sia nella fase di operation e di gestione dei deploy.

    Non è la prima volta che tengo questo talk, ma non è mai successo che due sessioni consecutive avessero lo stesso contenuto: l’ecosistema di Docker e il supporto che Azure ne dà sono in continua evoluzione. Ad ogni “giro” una nuova versione di Docker o un nuovo servizio di Azure a mantenere vivo (spero) l’interesse di chi partecipa e la necessità da parte mia di aggiornare slide e demo :D

    Se non ti sei iscritto, forse sei ancora in tempo: https://www.eventbrite.it/e/biglietti-devopswork-2017-30931208076

    Vi aspetto!!

  • La ricerca non è solo una ricerca

    Ultimo post datato: 07/10/2015…direi che è ora di ricominciare a bloggare, anche per evitare che @mauroservienti possa continuare indisturbato la sua serie di post su Service (UI) composition senza qualcuno che faccia da bastian contrario :)
    Non raggiungerò mai il suo rate di post, ma qualcosina da dire o aggiungere sull’argomento lo possiamo di sicuro trovare.

    Partiamo da questo post di Mauro in merito alla “ricerca”. Nulla da eccepire su quanto ha scritto, ma mi piacerebbe vedere “una semplice search” anche sotto un altro punto di vista, soprattutto nel mondo del commercio elettronico, contesto dal quale Mauro ha preso spunto per i suoi post.
    Siamo davvero sicuri che la ricerca sia sempre e “solo” una ricerca? Cerco di dettagliare meglio la domanda: siamo proprio sicuri che la ricerca fatta da un utente percorra il lato “di lettura” dei nostri due mondi (command & query)?
    Secondo me no o almeno non sempre.

    La ricerca di un utente porta con se una serie di informazioni semantiche molto importanti ed è fondamentale non perderle nascondendole dietro una, più o meno complessa, “query”. Ma non solo: in determinati scenari l’esecuzione di una ricerca non solo potrebbe, ma deve cambiare lo stato del sistema, entrando di diritto nella categoria dei comandi.

    Ok, prendiamo un bel respiro e cerchiamo di capire cosa intendo, per evitare di fare confusione: il fatto che l’utente Mauro abbia ricercato un portabanana in una certa data sono informazioni importanti che cambiano per forza di cose lo stato del contesto funzionale della ricerca ed influenzano potenzialmente anche altri contesti. Mantenere queste informazioni potrebbe aiutare il contesto del marketing a “suggerire” agli utenti del sistema prodotti che potrebbero essere di loro interesse. Queste informazioni nel contesto di sales potrebbero essere molto utili per gestire le politiche di pricing…e chi più ne ha più ne metta!

    Ma facciamo un ulteriore passo.

    Non è solo la ricerca in sè ad essere importante, ma anche il risultato della ricerca stessa contiene implicitamente informazioni che non possiamo disperdere: per esempio una ricerca che non produce risultati o che produce un numero di risultati inferiori ad una certa soglia ha un altissimo valore di business. Perdere un’informazione del genere impedirebbe al business di sapere cosa gli utenti stanno cercando e non trovano perchè, per esempio, non disponibili a catalogo negando di fatto delle potenziali vendite.

    Lo scenario della ricerca è uno di quei contesti in cui è molto semplice per la nostra mente prendere velocemente la tangente tecnologica, pensando a quale strumento “cool” del momento possiamo utilizzare per fare ricerche full-text o aggregazioni (stile facet) molto performanti, perdendo di vista gli scenari di business hidden che si nascondono solo qualche passo più in là.

    I principi di Domain Driven Design, ma soprattutto l’approccio pratico e diretto di Event Storming aiutano molto a far emergere scenari di business che molto spesso lo stesso business non sa di avere :)

    Nel post di Mauro c’è una frase che ha dato origine a questi miei pensieri, che riporto testualmente:

    Ma cosa c’è di male a buttare tutto in un bel robo fatto con Elastic Search?
    E la risposta sarebbe: nulla, non c’è nulla di sbagliato.
    La cosa sbagliata è pensare che l’unica soluzione sia buttare tutto in un robo fatto con Elastic Search.

    Parafrasando Mauro:

    La cosa sbagliata è pensare che la ricerca sia solo una “semplice” lettura

    Molto spesso dietro una ricerca si nasconde un bounded context inesplorato, che ha una dignità propria e che detiene un ricco contenuto informativo utlie anche al resto del sistema.

    Come al solito le risposte valide in questo contesto sono due: “dipende” e “42” :)