Services UI composition @ UGIdotNet


Fantastica giornata, veramente, quindi in primis grazie ad Andrea per il solito, enorme, sforzo organizzativo.

Il materiale della mia sessione è online:

Nelle prossime settimane riprenderò il discorso “Services UI composition” perché è tutt’altro che esaurito, abbiamo visto la punta dell’iceberg ma resta il piccolo dettaglio di tutto il mondo che potremmo includere sotto il cappello chiamato: scritture.

Cosa succede e come gestisco le scritture in un mondo distribuito dove quella che per l’utente è una singola operazione in realtà dietro le quindi è gestita da più servizi che devono in qualche modo coordinarsi e cooperare.

author: Mauro Servienti | posted @ giovedì 21 luglio 2016 8.51 | Feedback (0)

“anche oggi ho fatto”


Una delle cose a cui ho accennato quando parlavo di disciplina è il tener traccia di quello che ho fatto oggi. L’aspetto fondamentale non è tanto la traccia quanto piuttosto avere una lista da guardare a fine giornata, qualsiasi sia la fine della giornata, e poter dire: OK, ho fatto abbastanza per oggi, sono in pace con me stesso.

Stress

Il problema che non volete avere è lo stesso per cui ho disabilitato in toto tutte le notifiche.

  • colleghi sparsi su 17 time zone
  • colleghi che vivono e lavorano in Israele dove
    • Il weekend è venerdì e sabato (quindi lavorano di domenica)
    • Le festività a cui siamo abituati noi non esistono (Natale è un giorno come un altro)
  • colleghi ortodossi per cui alcune delle festività esistono si ma in date diverse

Oltre a tutto questo aggiungete adesso che avete totale flessibilità di orari, quindi anche qualcuno che sta nella stessa vostra time zone può decidere di lavorare di notte e non di giorno o un po’ e un po’ senza dir nulla a nessuno.

La conseguenza di tutto ciò è uno strano effetto psicologico che porta a lavorare come dei muli per tempi lunghissimi perché si ha sempre la sensazione che gli altri lavorino più di voi, ma è solo una sensazione che purtroppo porta inevitabilmente al senso di colpa.

Ecco che il tener traccia e spuntare le attività del giorno lavorativo aiuta sia ad essere produttivi ma anche a dire a se stessi: anche oggi ho fatto il mio dovere.

DevMarche: Social Skills Afternoon

Se volete saperne di più o anche solo fare quattro chiacchiere sul tema venerdì sono ad Ancona, venite a trovarci.

author: Mauro Servienti | posted @ mercoledì 20 luglio 2016 9.39 | Feedback (2)

Disciplina


Quando gli orari lavorativi sono estremamente fumosi come abbiamo detto la disciplina è tutto.

Nel mio piccolo adoro la carta, mi sono dotato di piccola “agendina gialla” che mi serve per pianificare la giornata e tenere traccia di tutto ciò che voglio fare e che ho fatto.

IMG_20160322_081337

Il funzionamento, se così si può definire, è piuttosto semplice:

  • segno tutto ciò, ma proprio tutto compresa l’andata in palestra e la scrittura di questo post, che voglio/devo fare
  • riporto dal giorno precedente tutto ciò che avevo segnato ma che non ho fatto
  • mano a mano che si presentano nuovi task li aggiungo
  • mano a mano che faccio le cose le spunto

Il giochetto è abbastanza semplice e ha due scopi:

  • avere un posto unico in cui tener traccia delle cose da fare oggi
  • a fine giornata, qualunque sia la cosa che identifica il fine giornata, avere un posto in cui guardare e avere quella sensazione di: anche oggi ho fatto.

“anche oggi ho fatto”

Questa è forse l’aspetto più importante. Ne parleremo in maniera più approfondita.

author: Mauro Servienti | posted @ lunedì 18 luglio 2016 8.58 | Feedback (1)

Orari: croce e delizia


Non avere orari lavorativi è fantastico ma porta con se un sacco di piccoli problemi e soprattutto tante responsabilità.

Partiamo dall'inizio: cosa significa non avere orari?

Significa letteralmente che puoi fare quello che vuoi, quando vuoi, senza avvisare nessuno. Se hai un impegno pianificato con i colleghi ovviamente non è che puoi non presentarti senza preavviso, ovviamente il rispetto prima di tutto. Ma se non hai qualcosa di pianificato con qualcuno sei liberissimo di fare quello che vuoi.

Vediamo come si è svolta la giornata di ieri:

  • 6.30 sveglia, caffè, cazzeggio leggendo notizie qua e la
  • 7:00:
    • giro su Slack per capire cosa è successo nel pomeriggio americano e nella mattina australiana
    • Controllo della posta per le notifiche di GitHub
  • 7:30 circa serie di meeting con alcuni colleghi, la maggioranza australiani
  • 10:00 porto avanti i lavori che sto seguendo
  • 11:00 piscina :-)
  • 12:30 porto avanti i lavori che sto seguendo
  • 16:30 me ne vado a Milano per incontrare un po' di amici, chiacchiere di tecnologia e cena

Quella di ieri è una giornata, non quella tipo, ogni giornata funziona a modo suo.

Quale è il problema?

Il problema vero è che per arrivare li, dove li è godere della flessibilità al massimo e comunque essere produttivo e non stressato, ci sono voluti circa due anni, due anni di "sofferenza" per cercare di capire come far funzionare le cose.

Un passo indietro

Facevo il consulente, 40.000 km/anno in macchina, tanti treni e un discreto numero di aerei. La giornata tipo era concentrata su quello che c'era da fare con il cliente di turno, la notte tipo era dedicata a preparare le cose per il cliente della settimana dopo. Ritmi serratissimi, tanto stress e poco tempo per pensare allo stress e ai ritmi.

Poi un giorno basta, lavori da casa e puoi fare quello che vuoi, il risultato è che ti ritrovi a lavorare 16 ore al giorno e non te ne accorgi neanche, inoltre pensi che devi "educare" quelli intorno a te che sei si a casa ma non significa che sei libero.

In realtà se hai libertà di orari, come ho io, è tutto sbagliato.

Quello che devi capire è che tu vieni prima, che sei estremamente fortunato se puoi mettere te stesso davanti a tutto ciò che è lavoro.

Ci vuole tempo e disciplina ma alla fine riesci ad organizzare la tua vita lavorativa intorno a quella privata e il gioco è fatto. Vai in piscina, dici alla moglie che la puoi accompagnare dove vuole a metà pomeriggio, e scegli quelli che ritieni siano i momenti, e i luoghi, più produttivi per dare il massimo e lavorare.

È tutto tranne che facile e non è detto che funzioni, non tutte le mie giornate sono perfette o molto “libere”, ci sono giornate con ritmi serrati e un po’ (poco a dire il vero) di stress, ma nel complesso funziona tutto molto bene.

Ho colleghi che alla fine si sono affittati un ufficio, fanno orari più da ufficio e usano la “scusa” dell’ufficio (che banalmente significa uscire di casa) per aiutare la propria auto-disciplina, non c’è la formale perfetta, c’è quella che funziona per ognuno di noi.

author: Mauro Servienti | posted @ venerdì 15 luglio 2016 12.17 | Feedback (0)

Diversity e non quote, giusto per essere chiari.


image

Anche qui conta solo la meritocrazia e quando parliamo di diversity non parliamo mai e poi mai di "quote".
Il problema che abbiamo bisogno di risolvere è che:

A tutt’oggi il mondo del “Software engineering” è un club esclusivo, è fondamentale lavorare per farlo diventare mostruosamente più inclusivo.

Un club esclusivo porta necessariamente a uniformità di pensiero e l’uniformità di pensiero porta alla stagnazione e all’incapacità di vedere al di la del paraocchi che ci sta facendo vede una sola strada.

Diversity non vuol dire più donne, o non vuol dire solo più donne, vuol dire principalmente riconoscere che ogni individuo è unico e che questa unicità va esaltata e non tarpata. E per farlo devi per forza spingerti verso ciò che è diverso da te, che può voler dire avere più donne nel team, oppure avere più gente con un background culturale non ingegneristico ma magari umanistico, etc…etc…

Aggiungo: non vogliamo “garantire” nulla, vogliamo semplicemente che sia nella natura delle cose.

author: Mauro Servienti | posted @ giovedì 14 luglio 2016 7.49 | Feedback (0)

Diversity


Ci stiamo provando con tenacia, ma al momento stiamo facendo veramente tanta fatica. Ma cosa significa “diversity”?

It means understanding that each individual is unique, and recognizing our individual differences. These can be along. the dimensions of race, ethnicity, gender, sexual orientation, socio-economic status, age, physical abilities, religious beliefs, political beliefs, or other ideologies.

A tutt’oggi il mondo del “Software engineering” è un club esclusivo, è fondamentale lavorare per farlo diventare mostruosamente più inclusivo.

Se volete approfondire: “Software engineering diversity” - https://kateheddleston.com/blog/how-our-engineering-environments-are-killing-diversity-introduction

author: Mauro Servienti | posted @ mercoledì 13 luglio 2016 10.59 | Feedback (1)

Il valore percepito.


Trovo affascinante come troppo spesso le scelte di design, architetturali o addirittura di funzionalità siano guidate dal valore percepito da parte di chi le produce e non da parti di chi le consuma.

È fondamentale rendersi conto che il valore percepito dal consumatore, inteso come colui che consuma non necessariamente l’utente finale, dovrebbe essere la linea guida principale, se non l’unica, per le nostre scelte in quanto produttori.

Provate a fare un esercizio: ogni volta che volete introdurre una novità, ogni volta che volete sistemare un bug, ogni volta che volete cambiare architettura, ogni volta che lo fate mettete il cappellino del consumatore e chiedetevi quale è la percezione di valore che il consumatore ha di questa volta, provate a dimenticare la vostra percezione in quanto produttori.

author: Mauro Servienti | posted @ lunedì 11 luglio 2016 8.06 | Feedback (2)

Ruoli: il "Solution Architect"


Il mio lavoro è affascinante e continua ad esserlo, evolve cambia e si contorce a volte ma sempre affascinante resta. Il mio ruolo in Particular è estremamente flessibile e cangiante, ne parleremo sia ad Ancona che ai Community Days a settembre.

Tecnicamente faccio il Solution Architect, come dice il biglietto da visita:

IMG_20160709_145529

Ma che vuol dire?

Vuol dire che, come generalmente dico, dal punto di vista del cliente, quindi dall’esterno, sono uno dei riferimenti che il cliente ha per le scelte di design e architetturali, per le review e i kick-off di progetto, il cliente vede me e i miei colleghi come quelli che hanno tutte le risposte. Cosa che vi garantisco, vista la dimensione di certi clienti, è tutto tranne che simpatica, affascinante e impegnativa non c’è che dire.

Internamente invece i ruoli non esistono, ci sono solo cose che devono essere fatte, che spaziano dall’organizzazione aziendale ai processi alla progettazione alla manutenzione e infine anche al supporto. Questo vuol dire che chiunque può fare tutto e il contrario di tutto, e come potete capire non è detto che sia un bene.

Dal canto mio mi sto dedicando principalmente a due attività che non avrei mai immaginato essere così assimilabili al concetto di architettura del software:

  • processo, inteso ad esempio come governance;
  • studio delle problematiche legate alla prioritizzazione di un backlog, quindi come far funzionare la product ownership (nel senso SCRUM della cosa) in una realtà multi prodotto e multi servizio;

Se siete curiosi fate un salto a trovarci ad Ancona o Milano :-)

author: Mauro Servienti | posted @ sabato 9 luglio 2016 15.26 | Feedback (0)

Services UI (de)Composition @ UGIdotNET


Quest’anno è il compleanno di UGIdotNET, e sono 15, per festeggiare ci regaliamo una giornata all’insegna di quello che UGI ha sempre saputo fare molto bene: condividere esperienze.

Il sottoscritto vi parlerà di Services UI Composition:

Un'architettura basata sui comandamenti di SOA genera e guida verso sistemi basati sulla decomposizione dei servizi e sul disaccoppiamento del dominio al fine di creare componenti autonomi. Purtroppo, dato che la UI è il luogo dove aggreghiamo tutte le informazioni per l'utente, ci ritroviamo ad accoppiare nuovamente e spesso velocemente di nuovo tutto. Obiettivo della sessione è di sviscerare il problema fino alle sue radici e proporre alcuni possibili approcci per risolverlo.

In realtà si parlerà anche di “Decomposition” che è argomento di una breve serie di post su questo blog (il requisito, un tentativo e i modelli), diciamo che l’obiettivo ambizioso della sessione è quello di sviscerare i primi due argomenti del workshop che abbiamo tenuto ad NDC Oslo poche settimane fa.

Che dire quindi se non che vi aspettiamo numerosi? Le registrazioni direttamente su Eventbrite: http://www.eventbrite.it/e/biglietti-buon-compleanno-ugidotnet-26284333148

author: Mauro Servienti | posted @ giovedì 7 luglio 2016 8.46 | Feedback (0)

GitHub WIP Pull Request & “Do Not Merge WIP”


Le pull request sono una delle funzionalità di GitHub e Git che amo di più, o forse una delle poche che amo dato che ho un interessante rapporto di odio/amore (più odio che amore) con Git*.

Comunque, una delle cose per cui usiamo moltissimo le PR in Particular è per discutere potenziali modifiche. In questo caso una cosa che volete assolutamente evitare come la peste è che un maintainer passi via e faccia il merge di una PR che non deve in nessun modo essere mergiata.

Al fine di garantire che ciò non avvenga abbia un concetto chiamato “WIP PR” che si traduce molto semplicemente nell’usare il prefisso “[WIP]” nel titolo della PR, questo segnala a chiunque lo scopo della PR.

image

Al fine di comunque garantire che la merge non avvenga per errore è sufficiente installarsi una simpatica estensione per Chrome: Do Not Merge WIP for GitHub

image

Che una volta attiva altro non fa che disabilitare il bottone merge per le WIP PR.

image

Comodo, semplice e a prova di distrazione.

author: Mauro Servienti | posted @ lunedì 4 luglio 2016 9.07 | Feedback (0)