Luca Vetti Tagliati

Luca Vetti Tagliati

Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.

Articoli pubblicati da Luca Vetti Tagliati:

n 192 febbraio 2014

Use Case vs. User Story

I parte: I requisiti funzionali

Con questo primo articolo avviamo una miniserie dedicata a un argomento infuocato, fonte di continue diatribe tra gli adepti delle varie 'religioni' delle metodologie di sviluppo del software: similarità e differenze tra la notazione dei casi d'uso e quella delle storie utente. Tuttavia, prima di addentrarci nel dibattito è necessario chiarire definizione e struttura dei requisiti con particolare riferimento a quelli funzionali. Solo alla fine di questo breve percorso sarà possibile addentrarsi del dibattito, chiarendo pro e contro di ciascuna notazione per comprendere appieno vantaggi e svantaggi. Ma iniziamo con i requisiti funzionali.

n 190 dicembre 2013

Il teorema CAP... in Brewer

V parte: L'implementazione CP in MongoDB

Con questo quinto articolo concludiamo la serie dedicata al teorema CAP, più precisamente alle sue ripercussioni sulle architetture distribuite, illustrando le scelte operate dal team di MongoDB per far fronte all'impossibilità di fornire contemporaneamente le tre feature di totale Consistenza, continua disponibilità (Availability) e tolleranza alle Partizioni, come sancito dal teorema.

n 189 novembre 2013

Il teorema CAP... in Brewer

IV parte: I database NoSQL

In questo quarto articolo della serie dedicata al teorema CAP, iniziamo l'esplorazione di MongoDB non prima però di aver ricapitolato alcune informazioni sui database NoSQL. In coerenza con gli obiettivi della serie, lo scopo di questo articolo non è la presentazione dettagliata di MongoDB, ma fornire una serie di informazioni finalizzate alla trattazione dettagliata dei compromessi derivanti dal teorema del CAP. Discussione che però avrà luogo nel corso del prossimo articolo.

n 188 ottobre 2013

Il teorema CAP... in Brewer

III parte: Aspetti tecnici nella gestione del grid

In questo terzo articolo della serie dedicata al teorema CAP o di Brewer, concludiamo la trattazione su Oracle Coherence, entrando in particolari tecnici della gestione del grid e mostrando nei dettagli come la scelta operata di continua disponibilità e consistenza (AC) sia stata ottenuta, giocoforza, a discapito della tolleranza alle partizioni. Nei prossimi numeri, comunque, continueremo il discorso sul principio di Brewer mostrando invece una soluzione basata su un compromesso di tipo AP.

n 187 settembre 2013

Il teorema CAP... in Brewer

II parte: Le caratteristiche di Oracle Coherence

Continuiamo la serie dedicata al teorema CAP, o di Brewer, approfondendo la cache distribuita Oracle Coherence. In particolare, dopo aver ripassato il teorema nel corso dell'articolo precedente, in questo presentiamo Oracle Coherence nelle sue caratteristiche. Nel corso del prossimo articolo illustreremo dettagliatamente le soluzioni architetturali e le scelte di disegno originate proprio dal teorema CAP.