Per chi è abituato a lavorare con sistemi centralizzati, costituiti ad esempio da una applicazione monolitica dotata di un unico database relazionale, la realizzazione di un sistema distribuito si presenta ricca di insidie. Ne facevo cenno già in un precedente post in cui cercavo di far luce sui problemi che l’astrazione offerta dai moderni strumenti riesce a nascondere ma non a risolvere del tutto. Uno di questi problemi è legato al concetto di consistenza dei dati sparsi in un sistema distribuito.

Qualche giorno fa un collega mi ha chiesto consigli su come disaccoppiare il codice che gestisce la logica di business dal codice che produce eventuali “reazioni” del sistema all’operazione eseguita. La sua necessità sorgeva dal fatto che l’applicazione su cui sta lavorando, realizzata con Spring framework, sarebbe stata utilizzata da diversi clienti, ciascuno dei quali avrebbe potenzialmente richiesto, per la medesima operazione principale, l’esecuzione di differenti operazioni secondarie. Una soluzione a questo problema è l’introduzione nel sistema degli eventi di dominio.

Ho appena finito di leggere, anzi, di divorare, il libro “High-Performance Java Persistence” di Vlad Mihalcea. Molte recensioni positive mi hanno spinto ad acquistarlo, nella versione cartacea attraverso Amazon, ma non mi aspettavo un testo al contempo così pragmatico, accessibile, dettagliato, scientifico ed in certi punti anche illuminante. L’autore, che tra l’altro è uno degli sviluppatori di Hibernate, in questo testo analizza i molteplici fattori che influenzano le performance del layer di persistenza dei dati in una applicazione Java.

L’argomento in questione è di grande attualità in ufficio ed è per questo che mi sento in dovere di condividere in questo post la mia visione sull’organizzazione ideale dei team di sviluppo, frutto di un decennio di osservazioni delle dinamiche lavorative. Il mio ragionamento parte dalla costatazione che la suddivisione dell’intero organico in diversi gruppi è necessaria ed inevitabile, e non per ragioni organizzative ma antropologiche. I gruppi sociali si formano spontaneamente, pertanto è meglio crearli secondo logiche di produttività.

Prima di continuare a leggere questo post, provate a dare una risposta. Secondo vuoi cos’è l’architettura di un software? Non si tratta di un discorso meramente teorico, finalizzato a trovare una definizione sterile. Al contrario, abbiamo bisogno di trovare una risposta perché da questa dipende la nostra capacità di valutare la bontà di una architettura. In altre parole abbiamo bisogno di sapere cos’è l’architettura di un software per avere un criterio che ci guidi nell’effettuare corrette scelte architetturali.

A scuola abbiamo imparato che per risolvere un problema è utile creare un modello, ovvero una astrazione semplificata della realtà in esame, che contempli solo gli elementi necessari alla descrizione del problema in questione. Ristretto il cerchio alle poche entità che costituiscono il modello individuato, sarà più facile individuare le logiche che ne governano il funzionamento e quindi risolvere il problema. Ma è proprio necessario che il modello attorno al quale realizziamo una applicazione debba essere costruito sul dominio del problema?

Fatemelo dire a chiare lettere: nell’industria IT non c’è più spazio per gli sviluppatori nerd. Mi riferisco a coloro che sono attratti dalle soluzioni complesse, dagli hack, dalle over-ingegnerizzazioni e da tutto ciò che, per essere compreso, richieda un QI elevato e, al contempo, mostrano seri problemi nelle relazioni interpersonali. KISS La letteratura dell’ingegneria del software parla chiaro, basta citare il principio KISS (Keep It Simple, Stupid) con cui si esorta a mantenere il codice sorgente semplice, lineare e comprensibile.

In questo ultimo post sul modello REST voglio provare a rispondere ad una semplice domanda: perché dovremmo rimanere fedeli al modello REST quando realizziamo applicazioni web? Per farlo dobbiamo partire dagli obiettivi che questa architettura si pone: scalabilità geografica; adozione di interfacce generiche (es.: HTTP, URI, ecc.) condivise tra tutti i client e server; deploy indipendente dei componenti (es.: siti web, web app, browser, motori di ricerca, ecc.); adozione di middleware per ridurre la latenza delle interazioni (es.

Nel precedente post vi ho raccontato delle vicende che hanno portato alla definizione del modello REST. Non è il caso di entrare nel merito della descrizione, piuttosto formale, che ne fa l’autore nella sua tesi di dottorato. Vediamo invece quali sono i concetti chiave di questa architettura e come questi siano riscontrabili nel Web e più di recente abbiano ispirato i servizi RESTful*. Risorse e identificativi Nel modello REST si parla di risorse e dei relativi identificativi, che corrispondono nel Web ai documenti (html, jpg, css, ecc.

Chiacchierando tra colleghi mi sono accorto che chi viene dal mondo SOAP e si avvicina ai servizi RESTful commette spesso l’errore di pensare che la principale differenza tra i due approcci sia solo la notazione utilizzata per lo scambio dei dati, XML per i servizi SOAP e JSON per quelli RESTful. Per avere un’idea più corretta sui concetti alla base di questi servizi è necessario fare un salto nel passato e seguire la nascita del Web per come lo conosciamo adesso.