Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, look for the Aggregate skin folder in the Skins directory.

To learn more about the application, check out the Subtext Project Website.

Powered By:
Powered by Subtext

Blog Stats

  • Blogs - 714
  • Posts - 31419
  • Articles - 310
  • Comments - 97142
  • Trackbacks - 228553

Bloggers (posts, last update)

Latest Posts

Quanto mi piace il nuovo project system di Visual Studio 2017

Visual Studio 2017 introduce un nuovo project system, i famosi file “proj” a cui siamo abituati. Il nuovo modello è obbligatorio per i progetti .NET Core/.NET Standard mentre è opzionale, e purtroppo la conversione è a manina, per tutti (o quasi) i tipi di progetto tradizionali.

Perché mi piace tanto?

Prendiamo come esempio la persistenza di NServiceBus su RavenDB, questa è la diff tra il prima e il dopo: –187 righe. Devo aggiungere altro?

Un’altra cosa che mi piace molto è che potete eliminare il file “packages.config” perché i pacchetti Nuget diventano first class citizen tra le reference del progetto. Inoltre finalmente potete costruire un pacchetto Nuget direttamente in fase di build senza pressoché fare nulla. Finalmente tutti i file presenti in una directory sono inclusi per definizione in un progetto, portando praticamente a zero le merge e le rogne in fase di evoluzione massiccia di un progetto.

Ultima cosa che trovo fantastica è che potete esternalizzare in file “Directory.*.proj” parti di configurazione che sono comuni a più progetti che vivono nella stessa folder, o solution. Mi piace poco invece la sintassi usata per escludere contenuti, me ne farò una ragione, anche se è veramente triste.

Provatelo ne vale la pena, vale anche la pena investire tempo per convertire progetti esistenti perché non siete obbligati a passare a .NET Core, l’unico vincolo è Visual Studio 2017.

posted @ 8/22/2017 5:16 PM by Mauro Servienti

Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

376102567_46d54e403f_b

Mi è capitato spesso di assistere a situazioni in cui ci fossero forti pressioni “dall’alto” perché un problema venisse risolto  e venisse risolto alla svelta. Il team si dannava, faceva le notti, accumulava frustrazione, per poi scoprire che la soluzione implementata non era quella desiderata.

L’inghippo, se di inghippo e non di miopia si può parlare, è abbastanza semplice: La fretta genera l’errore in ogni cosa.

Qualcuno, spesso qualcuno in alto nella gerarchia e guarda caso anche molto distaccato dal mondo reale, lamenta un problema e data la sua posizione di potere ne pretende la soluzione. Nella catena di schiavi nessuno ha il coraggio, se lo sa, di dirgli che quello non è il vero problema ma è solo il sintomo. E il team si ritrova a fare le notti.

In retrospettiva posso dire che noi spendiamo tantissimo tempo, dato un presunto problema, per comprendere a fondo se quello è veramente il problema da risolvere o se invece è solo un sintomo.

Identificare il vero problema da risolvere innesca due cose interessanti:

  • Molte meno discussioni interne perché una volta identificato il problema vero siamo tutti orientati nella stessa direzione; tant’è che uno dei metri di misura che ci fanno dire “forse è il problema sbagliato” è quando il dibattimento sulle soluzioni si trascina, e spesso le soluzioni proposte sono diametralmente opposte.
  • La soluzione si rivela essere una soluzione di (più) lunga durata e questo gratifica, con tutto quello che ne consegue.

Prima di iniziare a pensare ad una soluzione concentratevi sul problema.

Post in questa (mini) serie:

posted @ 8/17/2017 8:01 AM by Mauro Servienti

Windows 10 - Controlled Folder Access

controlled-folder-access

Una* delle macchine che uso quotidianamente per lavoro è nel programma insider, slow ring, e da un po’ è stata aggiornata a Creators Update. Una delle feature che aspettavo era il “Controlled Folder Access”.

Quello che potete fare è definire una o più cartelle (e di conseguenza le relative sotto-cartelle) come “controllate”. Questo fa si che fondamentalmente solo i programmi autorizzati possono apportare modifiche a quelle cartelle. Ovviamente la cosa che salta subito all’occhio è che un ransomware non risulta tra i programmi autorizzati e quindi problema risolto.

Occhio perché al momento non è tutto oro quel che luccica

La cosa funziona e funziona bene. Microsoft dichiara, nella UI di Defender, che Windows contiene una lista di applicazioni note che sono autorizzate a prescindere. Ad esempio sulla mia macchina Visual Studio Code fa tutto quello che deve fare senza problemi, Excel no, Word si. Misteri della fede e delle versioni insider, quindi non è che mi possa lamentare.

Ma non è questo il problema. La cosa noiosa è che le applicazioni si comportano in maniera alquanto strana, rendendo difficile anche per l’utente esperto capire, cosa sta succedendo.

Excel, ad esempio, apre i file senza problemi ma poi fallisce miseramente con un errore totalmente scorrelato al momento del salvataggio. Il problema di fondo è che Excel non essendo tra le applicazioni autorizzate sulla mia macchina, non riesce a creare il file temporaneo necessario per gestire le modifiche e quindi in seguito non riuscirà a salvare.

Non ho fatto esperimenti, ma presumo che il sistema operativo rimbalzi l’applicazione con un errore ben preciso, che al momento l’applicazione semplicemente non sa gestire. Nel mio piccolo mi ero dimenticato di averle attivate e quindi ci ho messo un po’ a capire cosa stava succedendo.

L’altra cosa ad oggi noiosa è che non è sempre facile capire quale sia l’eseguibile che dovete autorizzare, se usate molti tool da command line succede che voi interagite con xyz.exe che a sua volta invoca un altro eseguibile che viene bloccato da Defender, generando il perfetto yak shaving.

* Una sola perché fidarsi è bene, ma… devo lavorare :-)

posted @ 8/15/2017 10:20 AM by Mauro Servienti

I “virgoletti” di WhatsApp…

…ci seppelliranno. Avete anche voi amici e/o parenti che sono ossessionati dai “virgoletti”, così li ho sentiti chiamare, di WhatsApp?

Per uno che la prima cosa che fa è disabilitare tutte le notifiche, compresi i virgoletti maledetti, e se non può disabilitarle rimuove l’app, capirete che è incomprensibile. Quello che mi meraviglia di più è che tutta questa gente è spesso nata in un tempo in cui non esistevano neanche i cellulari e se avevi bisogno di qualcuno o di qualcosa la cabina telefonica e il gettone erano il massimo che potevi desiderare. Se non ti rispondeva nessuno te ne facevi una ragione e andavi avanti. Oggi come oggi ci sono coppie che scoppiano o amicizie che vanno in frantumi perché le “virgolette blu”.

Sinceramente non ho parole, se non: provate ad essere irreperibili e felici. È agosto, fa caldo, tra qualche giorno torno a parlare di cose normali e la pianto con gli sproloqui ;-)

posted @ 8/14/2017 7:45 AM by Mauro Servienti

[OT] xkcd


A webcomic of romance,sarcasm, math, and language.

https://xkcd.com

posted @ 8/8/2017 2:10 PM by Alessandro Gervasoni

Rider : New cross-platform .NET IDE

https://www.jetbrains.com/rider

JetBrains Rider is a new cross-platform .NET IDE based on the IntelliJ platform and ReSharper.

posted @ 8/8/2017 10:29 AM by Alessandro Gervasoni

Ipocrisia 2.0

image

Lo lascio qui, così come riflessione.

  • Capezzoli no, razzisti si
  • Capezzoli no, nazifascisti si
  • Capezzoli no, Salvini si (è una specie speciale dei due punti precedenti)
  • Capezzoli no, fakenews come se non ci fosse un domani

Marchino Zuckerbino…sei ridicolo e anche un po’ bigotto.

posted @ 8/8/2017 7:02 AM by Mauro Servienti

Processi (tanti), non risultati.

Parmigiano_reggiano_factory

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eliminate la fortuna dall’equazione

Senza processi i risultati possono solo essere controllati dalla fortuna, se siamo fortunati il formaggio quest’anno viene buono altrimenti buttiamo via tutto e imprechiamo contro qualche cosa a caso cercando di trovare un colpevole.

Io il formaggio non l’ho mai fatto, in compenso sto lavorando per essere in grado di percorrere una lunga distanza in bicicletta (in una sola uscita ovviamente :-P ). Non ci si improvvisa ciclisti e neanche formaggiai. C’è una scienza dietro la lunga e complessa preparazione per percorrere lunghe distanze in bicicletta, e non basta improvvisarsi ciclisti, uscire tutti i giorni e semplicemente pedalare.

Le ricette

I processi aziendali sono le ricette per fare il formaggio o le tabelle di allenamento per andare in bicicletta. Un processo vi permette di:

  • eliminare fortuna dall’equazione
  • evitare la caccia alle streghe quando le cose vanno male

Ovviamente i processi non devono essere scolpiti nella pietra, ma quando le cose vanno male ci possiamo concentrare su cosa non ha funzionato nel processo, cosa possiamo modificare in quello che abbiamo fatto affinché il problema non si ripresenti. I processi vanno quindi oliati e manutenuti nel tempo, adattandoli alle nuove esigenze e ai nuovi scenari.

Post in questa (mini) serie:

posted @ 8/2/2017 9:37 AM by Mauro Servienti

"Learning is working"

education-1959551_1280

In un commento su LinkedIn al post Il lavoratore remoto: la flessibilità, diritto e un dovere, Massimo chiede:

ciao, ti seguo da tempo, mi spieghi come fai ad essere sempre aggiornato, lavorando tutto il giorno?

Ammetto che la domanda mi ha fatto specie, è un problema che non mi sono mai posto. Semplicemente studio, e dedico anche molto tempo allo studio. Come dicevo nella mia risposta probabilmente, perché non l’ho mai misurato, dedico circa una giornata alla settimana allo studio.

Incuriosito comunque dalla domanda sono andato a curiosare tra le nostre policy se c’era qualcosa al riguardo, ed ho trovato questo:

Learning is working: Further education is considered part of your job and not your free time. Use our flexible hours and free time off policy to find a time that works for you.

Direi che non devo aggiungere altro. Fa parte di quelle cose che aiutano a creare un ambiente in cui fallire non è un problema, avere il tempo di prepararsi è un requisito fondamentale per affrontare qualsivoglia problema.

posted @ 7/31/2017 8:21 AM by Mauro Servienti

Meet{cast} - Advanced .NET Frontend - #AperiTech

image

Con mio grandissimo piacere a settembre sarò a Roma ospite, insieme a Michele Aponte, di un AperiTech organizzato dai ragazzi di dotNetPodcast, si parlerà principalmente di front-end.

Io nel mio piccolo vi racconterò come approcciare l’interfaccia utente in un mondo basato su Microservices costruendo un reverse proxy con .NET Core, quindi:

  1. se vi interessa il mondo Microservices…
  2. …o se non ve ne frega nulla ma siete curiosi di scoprire qualche dettaglio sugli internals di .NET Core…

Venite a trovarci :-)

Michele invece mi sa che darà vita definitivamente ad Inception, generando un framework per generare una SPA basata su un framework. Forza gente, accorrete numerosi.

Ovviamente, dopo perché durante dicono che faccia brutto ;-), che la gricia sia con noi.

posted @ 7/26/2017 10:23 AM by Mauro Servienti

ownCloud

https://owncloud.org

Access & share your files, calendars, contacts, mail & more from any device, on your terms

posted @ 7/25/2017 5:15 PM by Alessandro Gervasoni

Fiducia, fiducia e ancora fiducia.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Abbiamo parlato (male) di manager e (bene) di leader, di quanto le metriche possano essere problematiche e di come le persone debbano lavorare in team e non sole.

La domanda che probabilmente in molti (spesso manager) si fanno è:

come posso non gestire le persone, smettere di misurarle e controllarle e in più lasciarle lavorare in gruppo ovviamente riducendo la produttività, perché in gruppo ci si imbosca meglio?

Fidandosi

Costruendo un percorso di assunzione che miri a cercare le persone giuste, persone che condividono i valori dell’organizzazione, persone mature e responsabili e concedendo loro fiducia dal primo momento. La fiducia viene sempre ripagata, e in un contesto l’organizzazione stessa si auto controlla, facendo emergere e correggendo quei comportamenti che sono, o possono essere, lesivi per l’organizzazione stessa.

L’organizzazione si rende conto che i vantaggi sono talmente tanti, e i benefici pure, che lasciarsi sfuggire tutto questo bengodi sarebbe semplicemente stupidissimo.

Post in questa (mini) serie:

posted @ 7/24/2017 11:33 AM by Mauro Servienti

BabylonJs

https://www.babylonjs.com

A complete JavaScript framework for building 3D games with HTML5, WebGL, WebVR and Web Audio

posted @ 7/24/2017 10:30 AM by Alessandro Gervasoni

Il lavoratore remoto: la flessibilità, diritto e un dovere

Se lavorate da remoto e state facendo 9/18 con 1 ora di pausa pranzo state sbagliando tutto. Il lavoratore remoto è diverso, deve essere diverso e deve giovare dell’essere diverso.

Forse qualcuno avrà notato che ho cambiato la cadenza dei post, non ce ne sono più il venerdì. Perché? Semplice sono in ferie tutti i venerdì fino a fine agosto. Anche quest’anno per ora niente ferie lunghe e consecutive, ma lo stress e la fatica si accumulano comunque, la flessibilità che ho mi permette con tranquillità di prendermi 14 venerdì di ferie.

Allo stresso tempo visto che fa caldo, troppo caldo perché le mie sinapsi producano qualcosa di intelligente, la flessibilità di cui sopra mi permette di cambiare la mia giornata e spaccarla in due in maniera completamente diversa. La mattina inizia presto, 6.30, finisce verso le 11, piscina, piscina, piscina. Il pomeriggio inizia tardi, verso le 15.30 e finisce tardi.

Nel nostro caso specifico ottengo il vantaggio che ho più sovrapposizione con i colleghi australiani e americani, ma è un dettaglio. Il tutto è permesso dal fatto che la struttura organizzativa e i processi sono pensati con la flessibilità come uno dei punti cardine, nel nostro caso perché è un requisito ovviamente, ma nel vostro?

Se siete un lavoratore 100% remoto e siete obbligati al 9/18 con 1 ora di pausa pranzo, fatevi delle domande, probabilmente c’è qualcosa di profondo che non va e quella è la punta dell’iceberg, o l’effetto collaterale. Uno scenario potrebbe essere che l’organizzazione non è strutturata per il lavoro remoto, ma le percepisce solamente come un benefit (se volete leggere contentino fate pure ;-) ) e come tale lo tratta.

posted @ 7/19/2017 11:24 AM by Mauro Servienti

Le persone vanno unite, non divise.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

Eroi solitari

Ho spesso la sensazione che si tenda a promuovere una cultura in cui l’eroe solitario, che arriva e risolve tutto, sia la cosa da favorire. Certo dal punto di vista dell’eroe è bello pensare di essere la figura indispensabile, senza la quale non funziona nulla. Quello con il numero 11 sulla maglia. Allo stesso tempo l’eroe è il perfetto capro espiatorio, se ha successo verrà osannato, ma se fallisce abbiamo la figura su cui puntare il dito, quello da punire e castigare.

Cui prodest?

La mia esperienza dice che tutto ciò è figlio di una cultura che premia, o punisce, il risultato. Una cultura focalizzata sul cosa si ottiene e non sul come. In tutto ciò ovviamente il manager, quello nell’accezione negativa, ci sguazza con gioia perché in questo modo detiene potere.

Se al contrario facessimo lavorare, sempre, le persone in team (diciamo in tre)? cosa otterremmo?

  • Diversità di pensiero
  • Lo stimolo a trovare un modo per raggiungere il consenso
  • La nascita, spesso inaspettata, di nuovi leader
  • La scoperta che alcune persone sono dei perfetti avvocati del diavoli
  • Lo stimolo a crescere e alla sfida costante

Forse la cosa più importante è la spersonalizzazione della colpa, se sei solo e fallisci è per forza colpa tua, se sei un team e fallisci è colpa di tutto il team. Ebbene si, magari la colpa è di uno solo del team, ma gli altri lo hanno lasciato fallire portandosi a casa la loro fetta di responsabilità. Un team sano e coeso fa di tutto per auto-correggersi.

Ovvio che siamo in oligarchia, tutto ciò spaventa molto.

Post in questa (mini) serie:

posted @ 7/17/2017 9:23 AM by Mauro Servienti

Le metriche sono il male fatto a misura.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, ai colleghi e ai dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e poi infine dovete voler cambiare.

L’importanza delle metriche

Misurare è importante, misurare le cose sbagliate è deleterio. Imporre le misurazioni, giuste o sbagliate che siano, è altrettanto problematico. Basare il raggiungimento degli obiettivi sulla base delle metriche, magari sbagliate e imposte, è infine la ricetta per il disastro.

In scenari in cui le metriche scelte sono quelle sbagliate e/o sono imposte dall’alto e non condivise le persone tendono a lavorare principalmente per soddisfare la metrica. Se la metrica premia quanti support case chiudo in una settimana, il mio modello di relazione con il cliente sarà orientato a sbolognarlo nel più breve tempo possibile e non in primis a risolvere con qualità il suo problema.

Non misuravamo nulla

Quando abbiamo deciso di fare tabula rasa della struttura tradizionale dell’organizzazione abbiamo anche eliminato tutte le metriche, non misuravamo nulla. Il passaggio drastico è servito a resettare l’ambiente, a cambiare i parametri del successo e dell’insuccesso. Negli ultimi 6 mesi circa un paio di metriche sono state re-introdotte. Sarebbe meglio dire che sono state inventate dal basso al fine di soddisfare esigenze che le persone coinvolte nelle attività quotidiane hanno.

Quando la metrica emerge dal basso, è condivisa da tutti, è elaborata e costruita da tutti, è naturale vederne il valore intrinseco e non percepirla come un mero strumento di controllo finalizzato alla punizione quando questa non viene soddisfatta.

Concludendo

Come per tutti i processi aziendali, anche le metriche infine devono essere controllate, oliate e aggiustate continuamente, altrimenti diventano il nuovo Gantt scolpito nella pietra, che può solo generare problemi e frustrazioni. Possiamo quindi riassumere dicendo che le metriche:

  • in se non sono il male, ma è come vengono usate;
  • usate per elargire benefit o celebrare successi e punire insuccessi travieranno per forza le persone;
  • devono essere condivise e comprese a fondo da tutti, meglio se vengono dal basso;
  • devono essere costantemente monitorare e aggiustate in base al contesto;

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

posted @ 7/12/2017 11:10 AM by Mauro Servienti

GeoCoordinate

per ottenere la distanza in metri fra due punti geografici (lat,lng) in c#

var sCoord = new GeoCoordinate(sLatitude, sLongitude); 
var eCoord = new GeoCoordinate(eLatitude, eLongitude);
double dist = sCoord.GetDistanceTo(eCoord);

posted @ 7/11/2017 2:22 PM by Alessandro Gervasoni

Il manager non serve, trovate: leader, mentor e coach.

Nota per il lettore:

Questa (mini) serie di post non è una ricetta per trasformare un’organizzazione in un ambiente in cui fallire non sia un problema, mi spiace dirvelo: non esistono ricette o il manuale delle istruzioni. Quello di cui parlo in questi 6 post sono le cose principali che sono emerse nel lungo processo di trasformazione, iniziato ormai 3 anni fa, che hanno portato Particular Software ad essere quello che è oggi.

La vostra ricetta la potete trovare solo voi facendo quello che forse è il primo, e più difficile, passo: chiedendo a voi stessi, a colleghi e dipendenti che cosa non va bene e come lo cambierebbero. Ovviamente dovete ascoltare le risposte, criticarle e agire. Infine dovete voler cambiare.

Da Wikipedia:

A manager is a person who manages or is in charge of something. Managers can control departments in companies, or guide the people who work for them. Managers must often make decisions about things.

Abbiamo completamente eliminato i manager, le persone operative sono direttamente responsabili delle loro azioni, le persone sul campo sono quelle che prendono decisioni, tutte le persone coinvolte in un processo si assicurano che il processo sia ben oliato e funzionante, controllando che tutto funzioni come si deve.

Non ci serve un manager con il frustino che stia su un piedistallo a controllare che le risorse (perché così lui le chiamerebbe) stiano incollate davanti al computer almeno 8 ore, ne tantomeno ci serve qualcuno che ti faccia notare che insomma per oggi hai fatto solo mezza giornata, mentre i tuoi colleghi faranno anche 11 ore.

Quello che ci serve sono leader, che spronino le persone a fare scelte audaci e a mettersi in gioco, leader che allo stesso tempo sappiano insegnare alle persone trasferendo conoscenze ed esperienza. Infine siamo costantemente alla ricerca di punti di riferimento, di persone con cui confrontarci in merito alla quotidianità e perché no anche ai problemi lavorativi e non che ci attanagliano.

Come siamo soliti dire:

Non esistono persone sbagliate, ma solo persone giuste al posto sbagliato.

Un manager farebbe di tutto per liberarsene; leader, coach a mentor fanno di tutto per esplorarne il potenziale e trovare il posto giusto per massimizzarlo.

Post in questa (mini) serie:

  • Il manager non serve, trovate: leader, mentor e coach.
  • Le metriche sono il male fatto a misura.
  • Le persone vanno unite, non divise.
  • Fiducia, fiducia e ancora fiducia.
  • Processi (tanti), non risultati.
  • Basta! basta! basta! pensare alla soluzione non serve se non si è compreso il problema.

posted @ 7/10/2017 10:28 AM by Mauro Servienti

La coesione cambia, l’accoppiamento resta. Take 2

Quando abbiamo detto che la coesione cambia e l’accoppiamento resta abbiamo usato un esempio:

Se pensiamo ad un processo come ad una macchina a stati, in ogni stato del processo ci possono essere coinvolti uno o più servizi, coesi tra loro da quello specifico stato, ma non necessariamente nello stato successivo. Se non stiamo attenti e scivoliamo da coesione verso accoppiamento a questo punto ci ritroviamo che i servizi coinvolti in un processo sono per forza anche inutilmente coesi, proprio perché accoppiati, a prescindere dallo stato del processo stesso.

La macchina a stati

Un esempio minimalista potrebbe essere il seguente:

  1. Scelgo dal catalogo
  2. Aggiungo al carrello
  3. Inizio il checkout
  4. Imputo l’indirizzo di spedizione
  5. Scelgo il tipo di spedizione
  6. Imputo l’indirizzo di fatturazione
  7. Pago
  8. La merce viene reperita
  9. Il corriere espresso viene contattato
  10. La merce viene spedita
  11. L’ordine è evaso

Diciamo che dal punto 3 in poi è una tipica gestione ordini. Abbiamo vari servizi (logici) coinvolti, come Shipping, Finance, e Warehouse.

Un tentativo accoppiato

Un modo per modellare il processo di cui sopra potrebbe essere:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il checkout manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un comando a Finance per gestire il pagamento, Finance una volta gestito il pagamento manda un comando a Warehouse per iniziare la comporre l’ordine e infine Warehouse manda un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

Se rileggete quello che abbiamo appena scritto e sostituite tutti i “manda un comando” con “invoca” avete un bel flusso procedurale, accoppiatissimo e monolitico. Flusso in cui magari i service boundary sono chiari e definiti ma monolitico resta, se ci mettete una coda e dei messaggi ottenete due cose:

  • più complessità
  • il solo vantaggio che la coda vi fa off-loading del carico quindi se il passaggio X è particolarmente lento gli altri non ne risentono

L’orchestratore

A questo punto tipicamente il passaggio che si fa è: ma se l’ordine è a tutti gli effetti una macchina a stati, allora un orchestrator, o un process manager, o una saga sono il modello ideale. Del resto prima in un paio di punti sono stato obbligato ad usare il termine “gestore ordini”.

La trasformazione che quindi si applica potrebbe essere ad esempio:

Il carrello manda un comando al gestore ordini per iniziare il checkout. Il gestore ordini manda un comando a Shipping per far si che i dettagli della spedizione vengano definiti, Shipping quindi manda un messaggio al gestore ordini per informare che i dettagli della spedizione sono definiti, il gestore ordini quindi dice a Finance che può gestire il pagamento, Finance una volta gestito il pagamento manda un messaggio al gestore ordini per aggiornarlo sulla situazione. A questo punto il gestore ordini può mandare un comando a Warehouse per iniziare la comporre l’ordine e, dopo aver ricevuto conferma da Warehouse, infine mandare un comando nuovamente a Shipping per iniziare la spedizione, al termine della quale Shipping dice al gestore dell’ordine che l’ordine è completato e quindi evaso.

È cambiato qualcosa?

Secondo me è peggiorato, lo si evince anche solo leggendo:

  • Abbiamo sempre una sorta di comportamento procedurale, questa volta nelle mani di qualcuno di specifico: il gestore ordini
  • è ancora più complesso perché adesso abbiamo un nuovo attore: il gestore ordini
  • è molto verboso, o “chatty” come direbbero i miei colleghi

Perché quindi?

Spesso si finisce comunque per disegnare una soluzione come la seconda con la convinzione che risolva due problemi:

  • non è monolitica, ma è distribuita, scala ed è disaccoppiata (solo perché c’è una coda nel mezzo)
  • abbiamo un posto solo dove la UI può andare a leggere per riportare al lettore lo stato dell’ordine

Tada: “Riportare al lettore lo stato dell’ordine”

Questo è quello che ci sta fregando, questa necessità ci sta dicendo che una porzione del sistema, quella in cui facciamo reportistica all’utente, ha bisogno di informazioni aggregate sull’ordine. Il processo che gestisce l’ordine assolutamente no. I singoli servizi hanno bisogno delle loro informazioni interne per poter fare il loro lavoro. Shipping non ha bisogno di sapere quanto ho pagato o come ho pagato, ha solo bisogno di sapere che ho pagato.

Quindi abbiamo due informazioni importanti adesso:

  • La UI sta generano coesione, alcuni servizi devono in alcuni momenti essere in grado di riportare al lettore informazioni
  • Gli stati dei singoli servizi coinvolti nella gestione dell’ordine sono coesi al fine di risolvere il problema della gestione dell’ordine, ergo tutti prima o poi devono partecipare in qualche modo facendo la loro parte

Perché la coesione può cambiare?

Nel processo di cui sopra il carrello è coeso con la gestione dell’ordine? Solo al primo passaggio, quando iniziamo il processo di checkout, se lo iniziamo dal carrello, se lo iniziassimo da un ordine telefonico no non sarebbe coeso.

Allo stesso modo la coesione evolve o cambia con l’evolvere o l’avanzamento del processo di gestione dell’ordine, c’è un momento, ma solo quello, in cui Shipping probabilmente ha bisogno di Warehouse per capire dimensione e valore dei beni da spedire per organizzare la spedizione e capire se deve assicurarli.

Infine nuovi requisiti potrebbero cambiare gli attuali rapporti di coesione ma sarebbero un terremoto se ci fosse accoppiamento, uno su tutti: arriva uno stakeholder e vi informa che il business vuole vendere anche musica in formato digitale. Tutta la parte di spedizione scompare in un batter d’occhio. Se c’è accoppiamento sono dolori. Se c’è solo coesione c’è solo da introdurre il nuovo processo.

Ricordiamoci che:

Siccome l’accoppiamento è per sempre è bene lavorare per ridurlo al minimo indispensabile, ricordandoci che accoppiamento zero è impossibile. La strategia per ridurre all’osso l’accoppiamento tra le parti è identificare i service boundary seguendo la coesione che è una buona linea guida.

posted @ 7/8/2017 11:21 AM by Mauro Servienti

Your First TypeScript Angular 2 App

posted @ 7/7/2017 11:34 AM by Alessandro Gervasoni

Latest Images

From miscellaneous
From miscellaneous
From miscellaneous
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini