WebAppConf - il giorno dopo


Turin_monte_cappuccini

Ieri ho avuto il piacere di essere ospite alla WebAppConf a Torino. I ragazzi di Corley confermano essere degli ottimi organizzatori e hanno per l’ennesima volta prodotto un evento degno di nota, con grande seguito, e con alcune novità interessanti.

Andiamo con ordine, il materiale della mia sessione introduttiva, molto introduttiva, su GraphQL è on line.

Il formato 30 minuti, o 45 al massimo, mi piace sempre di più. Obbliga ad essere sintetici e a rimuovere tutta la fuffa di contorno. Offre anche molta più varietà ai partecipanti perché permette di raddoppiare gli argomenti trattati offrendo una maggior possibilità di essere soddisfatti. È anche possibile fare qualcosa di approfondito in 30 minuti, non è facile ma si rivela una bella sfida per lo speaker.

La novità a questo giro sono state le sessioni di mentoring, speaker e mentor erano a disposizione per sessioni di 10 minuti con i partecipanti. Sessioni il cui formato era il seguente:

  • 2/3 massimo per i partecipanti per esporre il loro problema
  • Il resto del tempo per intavolare una discussione
  • Divieto assoluto di cercare di vendere qualcosa

Ne ho fatte tre, sono state interessanti e spero efficaci per chi partecipava. Io dal canto mio le ho trovate formative.

By the way:

  • l’evento era a pagamento e nonostante questo è andato sold-out in pochissimo tempo, con un drop rate pari a zero.
  • La sessione che mi è piaciuta di più è stata quella di Andrea De Carolis, meritava di essere usata come sessione di apertura. Zero tecnologia e tanta ispirazione. Ottimo lavoro.
  • “Purtroppissimo” a sto giro non posso essere parte della CloudConf 2018, ma è certo che non mi faro sfuggire le prossime edizioni.

author: Mauro Servienti | posted @ Friday, November 17, 2017 1:49 PM | Feedback (0)

Esiste solo one-way messaging


2000px-MUTCD_R6-1R.svg

Molti di quelli che si approcciano al fantastico mondo della architetture distribuite basate su messaggi partano da un presupposto che non trova conferma e che tende ad essere fuorviante specialmente in fase di design.

Non esiste 2-way messaging

Spesso e volentieri quando si parla di messaggi si parla di pattern come request/response, request/reply e/o pub/sub. Nello specifico i primi due sono quelli che corrono il maggior rischio di essere fraintesi.

Se osserviamo come funziona un’infrastruttura di messaggistica, broker o code che siano, non esiste alcuna implementazione di request/* ma esiste semplicemente “request”, o più grezzamente esiste semplicemente la possibilità di inviare un messaggio. Se proprio vogliamo essere ancora più precisi non esiste neanche questo, piuttosto quello che le infrastrutture di messaggistica vi offrono è:

  • Accetta questo messaggio il cui destinatario è XYZ, e, se lo supporti, dammi conferma di averlo accettato (non consegnato, solo accettato).
  • Cortesemente, garantiscimi che se non riuscissi a consegnare il messaggio lo metti in un posto in cui non da fastidio, ma sia accessibile. L’importante è che non perdi il messaggio.

Fine.

Ogni altro tentativo di fare qualcosa di più sofisticato implicherebbe il noto problema dei due generali e l’unica possibilità di evitarlo sarebbe una simpatica transazione distribuita tra mittente, infrastruttura di messaggistica e destinatario. Cosa che ovviamente ci fa inorridire perché è uno dei motivi per cui abbiamo scelto un sistema di messaggistica.

In soldoni questo significa che da parte del mittente è impossibile sapere se il messaggio sia stato consegnato al destinatario. Non ci sono vie d’uscita, facciamocene una ragione.

Se osserviamo le due regole base di cui sopra, il massimo a cui possiamo aspirare è che o il messaggio è nella coda di destinazione, ma nulla ci può dire che sia stato processato correttamente, o nella peggiore delle ipotesi sta in una coda di errore, poison queue.

Questo comporta quindi che data una request che si aspetta una response non c’è nulla che garantisce che quella response sarà mai inviata, semplicemente perché non c’è nulla che garantisce la request sia mai andata dove speriamo che vada.

Vogliamo disaccoppiamento? Ci dobbiamo portare a casa anche le rogne del disaccoppiamento.

Questo principio fondamentale è quello che ci deve far sempre e solo dire: design for failure.

Nelle prossime puntate cercheremo di capire:

  • Il perché tecnologico di quello che abbiamo detto guardando a come funzionano i due principali modelli di messaggistica: store & forward e broker
  • Che cosa sono quindi pattern come request/* e pub/sub
  • Che cosa vuol dire di conseguenza “design for failure”

author: Mauro Servienti | posted @ Wednesday, November 15, 2017 10:25 AM | Feedback (0)

La collaborazione è più importante della produttività


team-1928848_1920

Internamente stressiamo moltissimo su quelli che comunemente vengono definiti soft skills, ad un punto tale che più volte è stato dichiarato che la collaborazione è più importante della produttività, la maggioranza dei nostri processi sono orientati a favorire la collaborazione e la comunicazione piuttosto che la produttività. Che in altre parole può essere letto come: ci interessa essere più efficaci che efficienti.

Nel nostro scenario distribuito la collaborazione assume ancora più valore, se fossimo orientati all’efficienza (e quindi fossimo troppo attenti a quanto produciamo) rischieremmo con facilità di orientare i processi a quello con la spiacevole, e presumo inevitabile, conseguenza che collaborazione e comunicazione morirebbero soffocate dalla produttività.

Nel nostro mondo in cui l’intelletto la fa da padrone e non siamo macchine non senzienti c’è comunque un alto rischio di scivolare troppo verso la produttività, dimenticandosi i soft skills, anche in realtà non necessariamente estreme come la nostra.

In questo senso vorrei una standing ovation per questo tweet:

image

E voi che realtà vivete?

author: Mauro Servienti | posted @ Monday, November 13, 2017 3:58 PM | Feedback (0)

All about Docker - @klabcommunity - UrbanHub Piacenza


5884963322_469e3670ed_b

Tornano gli incontri di KLab, questa volta in una sede diversa, UrbanHub a Piacenza. L’argomento trattato sarà il mondo container e in particolare Docker. Si partirà con un’introduzione a Docker, e all’ecosistema container e orchestratori, fatta da Roberto Messora, per poi proseguire con Nicola Baldi e Luca Milan che parleranno di Function as a Service e testing con Docker. Infine un bel buffet.

Io dal canto mio vengo a fare il curioso, di Docker so poco. Poi…mangiare mi piace sempre ;-)

Maggiori informazioni e iscrizioni: https://www.eventbrite.com/e/klab-2017-6-tickets-39721647517

Image credits: https://www.flickr.com/photos/datmater/5884963322

author: Mauro Servienti | posted @ Friday, November 10, 2017 1:40 PM | Feedback (0)

Un professionista deve saper dire di no


Audio-Music-Professional-Speaker-Music-Studio-1221152

Preparatevi perché quello che arriva è un “piccolo” rant. Sono sinceramente stufo dei professionisti che dicono di si a tutti e poi si rivelano inadeguati. È molto peggio, molto.

Non c’è nulla di più frustrante che rivolgersi ad un professionista, o presunto tale, esporre il problema che vogliamo risolvere, ovviamente pagare, per poi scoprire che il professionista in questione semplicemente era quello sbagliato, lui (o lei) lo sapeva ma ben si è guardato dal consigliare che sarebbe stato meglio rivolgersi ad altri.

Se qualcuno venisse da me e mi chiedesse consulenza in merito a sicurezza in infrastrutture di rete come potrei dire si? Mi porterei a casa la prima giornata di consulenza, forse intera, e poi? Poi nella migliore delle ipotesi vengo cacciato, nella peggiore verrei anche, giustamente, sputtanato.

Ecco io sono stufo di quelli che dicono di si a tutto, stufo perché oltre a sprecare i miei soldi sprecano soprattutto il mio tempo e la mia fiducia.

author: Mauro Servienti | posted @ Wednesday, November 8, 2017 2:32 PM | Feedback (2)

Quando l’attenzione ai particolari fa la differenza: Il setup di un nuovo device iOS.


og

Sono un felice possessore di un iPad mini 2 da più di due anni e mezzo, zero problemi, funziona, fa quello che deve fare, lo fa un gran bene e la batteria è ancora oggi un gioiellino. Il tempo passa, nuove feature arrivano e la performance inevitabilmente ne soffrono. È ancora utilizzabilissimo, ma ad esempio Slack è una mezza pena. Colpa di Slack, direte voi, e io non posso che condividere. Ma non è questo l’argomento del contendere :-)

Sta di fatto che complice un OnePlus One che ha cominciato a dare segni di cedimento, anch’esso dopo quasi tre anni di onorato servizio e nonostante una batteria che tira ancora 2 giorni, mi sono comperato (noleggiato per essere precisi) dei device Apple nuovi.

La cosa che più mi ha lasciato basito è la qualità, e semplicità, del setup inziale del device se già se ne possiede uno con iOS 11. Basta metterli uno vicino all’altro e seguire le istruzioni semplicissime, a prova di mia madre. In men che non si dica avevo un nuovo device configurato con lo stesso Apple ID, senza la menata colossale della mia password complessissima e di 2FA, ma semplicemente con una fotografia, con le stesse app installate pronto per essere usato.

Il mio approccio ai device è ormai da utente consumer, non mi interessa “smanettare”, mi serve che funzioni e basta. In questo senso l’ecosistema Apple è molto avanti.

author: Mauro Servienti | posted @ Monday, November 6, 2017 11:11 AM | Feedback (0)

Il processo di review visto dal reviewer


Nick Youngson - http://nyphotographic.com/

Quando ogni cosa che cercate di modificare deve essere revisionata da qualcuno prima che possa essere accettata è abbastanza ovvio che la figura del revisore diventa cruciale, se non altro perché rischia di diventare il collo di bottiglia di tutto il processo. A tal pro casca a fagiolo la domanda di Mr T. che chiede:

Ciao Mauro, avrei una domanda su PR e qualità del codice con GitHub: attualmente in azienda uno dei miei compiti è fare review delle pull request. Questa operazione riesco a farla sempre subito quando la PR viene aperta, quindi non ci sono periodi di attesa prima che la persona cominci a lavorare su nuove cose. Anzi spesso la facciamo insieme così revisioniamo insieme le cose da migliorare. Quando però il numero di PR cresce, perché aperte da più persone entra in gioco l’attesa della code review di una PR. Mi interessa capire, se vi capita, come gestiste questa cosa (ovvero generalmente è una operazione che fate subito?). Oltre a questo, lo sviluppatore che deve continuare il proprio lavoro e a cui magari gli serve ciò che ha sviluppato nel precedente branch feature, da cosa farà partire il prossimo branch? Voi generalmente come fate?

La risposta è articolata, ma cominciamo dalle cose base:

  • Se uno dei ruoli che una persona ricopre è quello di fare review, allora probabilmente ha senso che le review stiano in alto nella sua lista di priorità. Io ad esempio dedico un paio d’ore al giorno alle review, la prima ora della mattina e la prima del pomeriggio di solito. La finalità è quella di sbloccare il lavoro agli altri;
  • Aggiungiamo che se le PR sono abbastanza piccole, o piccole il giusto, ci vuole veramente poco a fare review e quindi non possono essere di certo un problema;
  • Ovvio che se la review arriva inaspettata allora sta in basso nella lista delle priorità, ed è giusto così, chi apre la PR deve sapere che se chiede lavoro extra non pianificato/concordato avrà vita difficile;
  • Inoltre se tutti sono coinvolti in un modo o nell’altro nel fare review, tutti diventano familiari con molte parti della codebase e quindi possono sempre di più fare review. È un circolo virtuoso a cui val la pena dedicare tempo e risorse.

Capita di dover aspettare? Certo che si, apri una PR e la review viene fatta 12 ore dopo, per noi è normalissimo. Del resto siamo anche sparpagliati su 17 time zone. Fa parte del gioco, siamo grandi e vaccinati e sapendo che tutti siamo impegnati facciamo in modo di avere altro da fare mentre siamo in attesa della review. Inevitabilmente paghiamo lo scotto del context switch, ma abbiamo deciso che nel nostro caso efficacia e collaborazione vengono prima dell’efficienza.

La seconda parte della domanda è altrettanto interessante:

Oltre a questo, lo sviluppatore che deve continuare il proprio lavoro e a cui magari gli serve ciò che ha sviluppato nel precedente branch feature, da cosa farà partire il prossimo branch? Voi generalmente come fate?

Ora, qui potremmo essere di fronte ad un problema di design o di processo, e quello descritto essere un sintomo. Se la PR è ben fatta i tempi di attesa devono essere brevi altrimenti significa che abbiamo un problema di congestione che va oltre la questione review. Quello a cui mi potrei trovare di fronte è un problema di design/processo, supponiamo di avere una nuova feature XYZ:

  • abbiamo una branch feature/xyz
  • nella branch ci sono 3 commit che compongono XYZ:
    • funzionalità A
    • funzionalità B
    • funzionalità C
  • la Pull Request è in attesa di review

Il team nell’attesa vuole andare avanti e per andare avanti con feature 123 ha bisogno del codice “funzionalità A” committato nella branch di cui sopra. GitFlow nasce esattamente per risolvere situazioni come questa:

  • una branch funzionalità A viene aperta da develop
  • contiene un solo commit funzionalità A
  • la Pull Request viene revisionata
  • e mergiata su develop

A questo punto feature/xyz può iniziare e anche feature/123 può partire in parallelo, develop è il bandolo della matassa: develop è sempre rilasciabile come beta. develop + funzionalità A è rilasciabile? certo, essendo una beta è accettabile che funzionalità A, se visibile/fruibile sia poco utile. È funzionale a sbloccare altre parti. In uno scenario come questo quindi la necessità di avere review fluide aiuta a strutturare il progetto e il codice in funziona anche di quello, con tutti i vantaggi che ne conseguono.

Spero che Mr. T. sia soddisfatto ;-)

Credits: Review Image - Nick Youngson - http://nyphotographic.com/

author: Mauro Servienti | posted @ Friday, November 3, 2017 11:50 AM | Feedback (0)

Controlled Folder Access: che cosa è? e rudimenti per la sopravvivenza dello sviluppatore


Ransomware-pic

I ransomware sono la nuova peste, sono molto più subdoli dei virus perché fondamentalmente non fanno altro che quello che l’utente fa di solito, scrivono documenti. Vero lo fanno in massa, ma fanno una cosa lecita, anche Dropbox scrive documenti in massa a volte. Fare quindi prevenzione è molto più difficile, educare gli utenti lo e ancora di più perché, secondo me l’informatica è ancora molto lontana dall’utente comune. Ma questa è un’altra storia.

Please welcome Controlled Folder Access

Controlled Folder Access è una nuova funzionalità di Windows 10 Fall Creators Update, da poco disponibile gratuitamente per tutti gli utenti Windows 10, che fa una cosa molto semplice quanto efficace: ci consente di definire delle cartelle, e con esse tutte le sotto cartelle, che possono essere modificate solo ed esclusivamente da un set noto di programmi, una sorta di white list su cui abbiamo parziale controllo. Parziale perché tutta una serie di programmi noti, e firmati digitalmente, come ad esempio la suite Office o appunto Dropbox, sono già nella lista e li restano. La chiave in questo caso è la firma digitale.

Ritengo di far parte degli utenti attenti, ma:

  • Prevenire è meglio che curare
  • Non sono l’unico in famiglia che usa il computer

Quindi ho deciso di attivare Controlled Access Folder per:

  • La cartella di Dropbox
  • La cartella dove ci sono tutti i sorgenti

È paranoia perché entrambe hanno fior di copie online e backup off-site, ma la paranoia aiuta a combattere la sfiga che come sappiamo ci vede benissimo. Attivare Controlled Folder Access è facilissimo, basta andare da Defender e tra i Virus & threat protection settings:

image

attivare Controlled Access Folder:

image

appena fatto come più o meno mi aspettavo sono iniziate le rogne, che poi tanto rogne non sono. Git ha, come mi aspettavo, immediatamente smesso di funzionare:

image

La vera rogna è capire chi non può scrivere, cioè quale sia l’eseguibile che sta fallendo, perché l’informazione è annegata nell’Event Viewer di Windows e precisamente in questo log: Microsoft-Windows-Windows Defender/Operational, li sono elencate le applicazioni che sono state bloccate. Una volta noto l’eseguibile bloccato il gioco è semplice, basta aggiungerlo all’elenco delle applicazioni autorizzate:

image

Ho scelto Git come esempio rognoso non a caso, sulla mia macchina ci sono 11 git.exe sparsi in varie folder e non mi sembrava il caso di ciecamente abilitarli tutti. In altri casi altri programmi potrebbero dare errori strani durante il tentativo di scrittura se non sono autorizzati. Ad esempio Windows Live Writer fallisce miseramente nella creazione dei file temporanei prima ancora del salvataggio vero e proprio del post, e quindi l’errore è un po’ criptico.

author: Mauro Servienti | posted @ Wednesday, November 1, 2017 7:42 AM | Feedback (3)

WebAppConf 2017, Torino #webappconf17


torino-1072877_1920

Ultimo appuntamento “conferenziero” dell’anno. Il 16 novembre avrò il piacere di essere ospite della WebAppConf 2017 per parlare di GraphQL:

GraphQL. Where are you from? Where are you going?

GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.

Maggiori informazioni: https://milestone.topics.it/events/web-app-conf-2017.html

Biglietti: https://www.eventbrite.it/e/webappconf-2017-tickets-37993276914

Ci si vede a Torino?

author: Mauro Servienti | posted @ Monday, October 30, 2017 7:09 AM | Feedback (1)

Dare un senso alla giornata, quando un senso non ce l’ha


decisions-407750_1920

È uno dei motivi per cui ho deciso di provare ad introdurre la “retrospettiva” a fine giornata. La realtà lavorativa che vivo è molto particolare, non la cambierei, ma nonostante abbia una serie lunghissima di pregi ha anche i suoi difetti. Uno su tutti è la difficoltà di concentrarsi pochi, magari uno solo, macro-task. Capita spessissimo di arrivare a fine giornata e avere la sensazione di aver concluso molto poco: moltissimi micro-task, in apparenza, e poco più.

Non è molto diverso dalla situazione proposta da Mariano:

Premessa: Anche io adoro l'impatto psicologico della spunta su carta e vedere tante spunte a fine giornata dà una certa soddisfazione.
Il "fare" però (per svariati motivi), potrebbe essere un'attività di cui conosci poco o nulla.. In quei casi ti tocca lavorare in maniera più esplorativa e meno razionale, la suddivisione dell'attività in task non è (ancora) fattibile.
A fine giornata avrai sicuramente un quadro più chiaro della questione ma la sensazione di avere un po' perso tempo resta...
Ti ci trovi mai in questa situazione? come la affronti?

Immaginative un problema che non sapete risolvere, spendete la giornata facendo mille prove, studiando e analizzando il problema, a fine giornata continua ad essere irrisolto. Frustrante perché la sensazione è di aver concluso poco o nulla del resto il problema è ancora li. Ma se ci pensate siete avanzati di mille micro-passi, domani avrete mille micro-prove in meno da fare, etc..

Diciamo che la mia giornata è quasi sempre così. Anche quando sono coinvolto in qualcosa di medio grosso il fatto di lavorare con colleghi che stanno in una time zone diversa fa si che spessissimo arrivo ad un certo punto, micro-task, e poi devo aspettare qualcuno che sta 8 ore dietro di me, o peggio 6 ore avanti, il che comporta spesso una giornata intera.

La mia giornata è quindi spesso organizzata in funzione di questa cosa, ma ovviamente rischia di generare frustrazione. Nel mio caso l’agenda e la retrospettiva aiutano ad accettare uno stato delle cose che mi va molto bene e che non vorrei cambiare. Ne parleremo.

Quindi tornando alle domande:

Ti ci trovi mai in questa situazione? come la affronti?

Spessissimo, e non la affronto la accetto. Quello che tendo a fare è avere un progetto importante a cui sto lavorando, e una quantità notevole di micro-task che uso da tappabuchi nelle inevitabili pause del progetto. Ovviamente bilanciare è un’arte funambolica e spesso mi ritrovo ad aver detto di si a troppe cose, ma questa è un’altra storia.

author: Mauro Servienti | posted @ Friday, October 27, 2017 7:34 AM | Feedback (0)