gennaio 2017 Blog Posts
Risolvono un problema che in realtà ci creiamo da soli, e ne aggiungono altri. Questa è una vista minimale di uno dei miei account di Slack: “All Threads” si aggiunge a “All Unreads” come posto dove controllare cosa mi sono perso mentre ero offline, dispersione delle informazioni. Ovviamente il problema che i “thread” puntano a risolvere è legato alla confusione che si crea in un canale quando ci sono molte persone, ma il problema è tipico di qualsiasi modello di conversazione dove ci sono troppe persone. Se osservate quello che avviene nella realtà di tutti...
È un paio di giorni che sono in modalità polemica, Nik sarebbe fiero di #MrFail. Oggi come oggi non fare continuos integration o continuos deployment, o entrambi, non può avere scuse tecnologiche e/o legate agli strumenti. Radical, ad esempio, ma anche tutti i prodotti Particular, gira intorno a un migliaio e passa di test, un processo di CI basato su AppVeyor, SemVer gestito con GitFlow e GitVersion. Prepararlo e oliarlo ci è costato nel complesso un paio di giornate di lavoro di due persone. Quindi voi mi state dicendo che per 4 giornate lavorative preferite...
Dal 22 al 25 marzo avrò il piacere di essere a Roma per l’edizione 2017 di Codemotion. Il 22 avrò l’onore di presentare nuovamente il workshop “Microservices Development Deep Dive”. Sarà un’edizione completamente nuova rispetto a quella di Milano, stesso programma ma nuova struttura dei contenuti, nuove demo e nuovi esercizi. Insomma sotto la stessa pelle una bestia diversa. Venerdì 24 invece mi cimenterò in una sessione introduttiva a SOA e alle architetture basate su messaggi: The road to a Service Oriented Architecture is paved with messages. L’early bird finisce oggi, non è il caso di farci...
Sabato 11 febbraio sarò a Vimercate al Mini Agile Day organizzato in collaborazione con Nokia. Racconterò di come siamo organizzati in Particular e di come gestiamo la quotidianità: Croce e delizia del lavoro da remoto Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di...
Abbiamo parlato di permanent errors e transient errors, c’è un’ultima categoria di errori che dobbiamo prendere in considerazione: gli errori di business. Gli errori di business non esistono Supponiamo uno scenario di questo genere: Il servizio X invia il comando CreaUtente con annessi tutti i dettagli, il servizio Y prende in carico il messaggio e la validazione delle regole di business fallisce perché un utente con la stessa mail esiste già. In un caso come questo, e potete immaginarne infiniti altri: Ha senso riprovare il messaggio...
Non tutti gli errori nascono uguali. Abbiamo visto cosa sono i permanent error, ma non sono l’ unica forma possibile di errore. Transient Error Un problema tipico caratteristica dei sistemi distribuiti è la disponibilità ballerina delle risorse. I sistemi distribuiti mettono in luce molto rapidamente la così dette fallacies of distributed computing, è quindi cosa più che normale che il database, o una risorsa qualsiasi di cui abbiamo bisogno, anche la rete stessa, non sia disponibile nel momento in cui ne abbiamo bisogno. Sempre tipico dei sistemi distribuiti è che se riproviamo poco dopo tutto...
Abbiamo detto che ci sono errori ed errori. Un permanent error, nel mondo della messaggistica, si verifica (tipicamente) quando un messaggio non può essere processato. Spesso nel mondo della messaggistica si sente parlare anche di poison message, i due vanno a braccetto. Un poison message è una forma di permanent error. OK, ma che cosa significa? Significa ad esempio avere un messaggio in una coda di ingresso e il messaggio è malformato. Il fatto che il messaggio sia malformato comporta che la deserilizzazione fallisca ad ogni tentativo. Non è molto diverso da un documento di...
Abbiamo già detto per cosa non ha senso usare un messaggio. Una cosa fondamentale da comprendere, se il vostro sistema è basato su messaggi e code, è i messaggi non possono essere persi. Perdere un messaggio equivale a corrompere il sistema. Errori Ci sono tre tipologie di errore: permanent: un messaggio non può essere processato, ad esempio la deserializzazione fallisce; transient: un messaggio può essere processato ma una risorsa necessaria non è disponibile, riprovare potrebbe essere la soluzione; business: un messaggio può essere processato ma viola...
Alessandro Melchiori da qualche settimana millanta che avrebbe scritto dei post inerenti all’argomento Services UI Composition, ecco millanta :-D Forza Ale pubblica qualcosa! Per cercare di smuovere ancora un po’ le acque sto preparando una nuova sessione che al momento è così definita: Tutti i nostri aggregati sono sbagliati Inizia sempre tutto bene, il requisito è semplice e l'implementazione procede senza intoppi. Poi i requisiti aumentano e ci ritroviamo con una strana sensazione allo stomaco e con la necessità di introdurre alchimie tecnologiche che non ci piacciono, ma non sappiamo...
Quando si parla di messaggi, intesi come messaggi su una coda, c’è una cosa molto importante da comprendere: I messaggi sono sempre e solo one-way, fire & forget. A prescindere dal pattern di alto livello che stiamo usando, sia esso pub/sub o request/response, il mittente parla con una coda, il destinatario parla a sua volta con una coda, ma mittente e destinatario non sanno nulla l’uno dell’altro. Two Generals' Problem Questa puntualizzazione è molto importante perché introduce il noto problema dei due generali. Che in soldoni ci dice che il mettente non...
Questo va un po’ nella stessa direzione dell’ascoltare per rispondere. Qualcuno racconta quello che per lui è un problema L’interlocutore si mette immediatamente in modalità soluzione …è tutto finito :) Il mettersi in “modalità soluzione” comporta un problema interessante: non analizziamo il problema, diamo per scontato che quello che ci è stato raccontato sia il vero problema che deve essere risolto. Non sto parlando in nessun modo di malafede: chi racconta, racconta la sua visione del mondo e in quanto tale la sua verità, ma non sta scritto...