Il lavoratore remoto e la qualità della connettività.


Sembra una cosa scontata, ma non lo è per nulla. Perché il lavoro da remoto possa anche solo essere preso in considerazione la presenza di connettività è un requisito fondamentale. Direi lapalissiano.
Quello che forse è meno scontato è la frustrazione e lo stress elevatissimo che una qualità scadente della connettività può generare, sia da parte del lavoratore che da parte del datore di lavoro.

Banda, velocità nominale e qualità

La velocità della connessione è un fattore che ha un peso limitato sulla qualità complessiva percepita, e di conseguenza su stress e frustrazione. Paradossalmente è meglio una buona, e mediocremente veloce, ADSL rispetto ad una nominalmente veloce connessione WiMax (o tecnologie simili). Questo perché, nella media della giornata lavorativa, conta di più la stabilità della linea rispetto alla velocità di picco.

Mi è capitato di riuscire a fare, con buoni risultati, conference call su una schifosissima ADSL con 3.0Mbit in download e 0.2Mbit in upload e allo stesso tempo di letteralmente impazzire con una presunta blasonata connessione Eolo da 30/10Mbit con banda minima garantita.

Velocità. Upload delle mie brame.

Certo una bella fibra FTTC, se non migliore, vi garantisco che cambia drasticamente la qualità della vita del lavoratore remoto. La banda in upload è poi, in alcuni momenti, un fattore essenziale oltre che una soddisfazione. Vedere l’upload di circa 200Mb metterci meno di 30 secondi è un piccola goduria.

Si, ma perché?

Se non fosse ovvio il motivo è uno ed uno solo: evitare l’isolamento. Non è detto che abbiate bisogno di connettività costante e costantemente di alta qualità, per lavorare da remoto. Ne avete però bisogno per stare in contatto, quando e come volete con i vostri colleghi. L’aspetto forse più importante del lavoro remoto è evitare l’isolamento sociale.

author: Mauro Servienti | posted @ lunedì 20 marzo 2017 9.18 | Feedback (0)

Il lavoratore remoto


Lavoro, da remoto, come Solution Architect per Particular Software da circa 3 anni. In questi tre anni ho, e abbiamo anche come azienda, sperimentato parecchio in ambito “lavoro da remoto”.

Da un annetto a questa parte parlo pubblicamente di come siamo organizzati. Il talk, “The agony and the ecstasy of working remotely (from cogs to Nirvana)” , è focalizzato sulla struttura organizzativa e sul processo evolutivo che l’azienda ha intrapreso.

La nuova categoria “remote working”, di cui questo è il primo post, nasce invece per raccogliere tutta una serie di suggerimenti e accorgimenti (tips & tricks) per me essenziali per rendere efficace, efficiente ma soprattutto divertente la vita del lavoratore remoto. Sia dal punto di vista del lavoratore che del datore di lavoro.

Il primo consiglio? leggete Remote-First vs. Remote-Friendly di Zach Holman.
Il secondo consiglio? rileggetelo.

author: Mauro Servienti | posted @ venerdì 17 marzo 2017 9.30 | Feedback (1)

La complessità è importante. Accettatela.


Una delle regole non scritte dei sistemi distribuiti, in stile Fight Club, è: non distribuire.

Ci devono essere validissimi motivi per scegliere di costruire un sistema distribuito. Come sappiamo, ma forse troppo facilmente dimentichiamo, la soluzione di tutti i mali non esiste. Un’architettura distribuita risolve un sacco di magagne ma inevitabilmente ne porta con se altre, diventa quindi importante valutare bene queste altre per essere sicuri che il gioco valga la candela.

L’altro ieri parlando di Enel scrivevo:

La cosa che più mi fa imbestialire è che un mondo complesso come quello di Enel è forse il mondo in cui sarebbe più semplice risolvere il problema di cui sopra.

In un sistema inevitabilmente complesso come quello di una grande realtà un’architettura distribuita è paradossalmente molto (più) facile da implementare. Il sistema è distribuito per natura dal giorno zero. La complessità è elevatissima. Tutte le magagne introdotte dal distribuire sono ampiamente annullate dai vantaggi.

Abbiamo sempre detto e accettato per buona la stessa cosa quando si parla di Domain Driven Design.

La cosa importante da comprendere, evidenziata molto bene da Weronika ad Amsterdam, è che la complessità esiste sempre. I business sono (quasi) sempre complessi, noi tecnici siamo stati educati con la forza a cercare di renderli semplici con la tecnologia.

Mai errore fu più nefasto. Fuggire la complessità può solo portare a spostare la stessa in un campo di battaglia più ostico: quello tecnologico.

Così per dire…La mail non è ancora arrivata.

--

With Ginger help.

author: Mauro Servienti | posted @ mercoledì 15 marzo 2017 8.45 | Feedback (2)

Ginger


Da qualche giorno sto usando, con soddisfazione, Ginger come tool di supporto per la scrittura. I ragazzi di Ginger mi hanno offerto una licenza full che abilita tutta una serie di funzionalità interessanti.

Di base Ginger è un “correttore” multilingua che oltre ad avere il classico supporto per grammatica e ortografia vi da anche un discreto supporto per la costruzione logica della frase, molto utile quando si ha a che fare in particolare con una lingua straniera.

La cosa che mi piace di più in questo momento è la varietà di strumenti messi a disposizione. Si integra con il browser (Chrome nel mio caso) in due modi:

  • Direttamente in line mentre si scrive nei vari textbox e taxtarea

image

  • Con una semplice estensione che è possibile usare come applicazione per creare bozze

image

Infine è possibile installare un’applicazione stand alone da usare come vero e proprio editor di testo. Non male.

Mi sembra anche di poter dire, in maniera molto empirica e poco scientifica, che è decisamente poco esoso in termini di risorse.

author: Mauro Servienti | posted @ martedì 14 marzo 2017 9.57 | Feedback (0)

Tutto è una macchina a stati: la tecnologia al servizio dell’utente.


In questi ultimi giorni ho, volente o nolente, parecchio a che fare con Enel. L’esperienza utente con i sistemi Enel spazia dal piuttosto pietoso al disastroso.

Lasciatemi usare l’ultima cosa che mi è appena successa come spunto per una riflessione:

  • alle 17.50 mi arriva un SMS che mi informa di controllare la mail
  • secondo loro dovrei cliccare sul link presente nella mail per completare la procedura di attivazione della bolletta online
  • alle 18.43 la mail non è ancora arrivata

E uno si chiede: come credi si possa sentire un non informatico in questa situazione? Come minimo brancola nel buio. Tra un’oretta comincia a chiedersi dove ha sbagliato; infine domani mattina chiamerà il servizio clienti.

Ovvio che è sbagliato

Lo sottolineo giusto così per precauzione, un approccio come il seguente è sbagliato, ripetete con me sba | glià | to.

using( var tx = new TransactionScope() )
{
   UpdateCustomerStatus(123, true);
   SendMail(MailType.OnlinePaymentActivation);
   SendSMS(SMSType.OnlinePaymentActivation);
}

La cosa che più mi fa imbestialire è che un mondo complesso come quello di Enel è forse il mondo in cui sarebbe più semplice risolvere il problema di cui sopra.

Un errore terribile

In sistemi complessi le parti sono tante, le applicazioni ancora di più i servizi di appoggio non si smette mai di censirli. In sistemi complessi la comunicazione non può essere sincrona e lo snippet usato come esempio nasconde un errore terribile.

Nasconde la convinzione che farsi un bus fatto in casa ricada sotto il vecchio adagio: ma si, che ci vuole.

Quel codice esprime un intento che dovrebbe essere:

using( var tx = new TransactionScope() )
{
   UpdateCustomerStatus(123, true);
   QueueSendMail(MailType.OnlinePaymentActivation);
   QueueSendSMS(SMSType.OnlinePaymentActivation);
}

Nel qual caso diventerebbe ovvio che accodare l’invio dell’SMS è pericoloso perché se il servizio di invio mail è giù generiamo immediatamente il pastrocchio di cui sopra.

Tutta la nostra vita è una macchina a stati

Quindi perché fare tutti questi sforzi per negarlo? Non sarebbe molto più semplice prendere atto della cosa e progettare il software con questa innegabile verità come linea guida?

  1. Aggiorno lo stato del cliente
  2. Pubblico un evento significativo
  3. Reagisco all’evento e invio la mail relativa
    1. Attendo conferma che la mail sia sul server di posta del destinatario*
  4. Pubblico un evento significativo
  5. invio l’SMS

Sono le 19.11 e della mail ancora nessuna traccia.

* che è quello che fa Amazon, non è al 100% affidabile ma abbatte il numero di casistiche di inconsistenza, e di conseguenza il numero di chiamate al servizio clienti.

author: Mauro Servienti | posted @ lunedì 13 marzo 2017 19.12 | Feedback (0)

Make an impact.


Rendete straordinaria la vostra vita

https://youtu.be/L7maQfH0lMs

author: Mauro Servienti | posted @ venerdì 10 marzo 2017 17.33 | Feedback (0)

Commit o no delle dipendenze?


Quando ci siamo chiesti a chi conviene/interessa seguire SemVer abbiamo usato questo screenshot:

image

E abbiamo anche detto:

Nel caso specifico Alessandro si riferisce ad un problema leggermente diverso legato alla gestione delle dipendenze, lo affronteremo.

Gli sviluppatori .NET sono abituati a Nuget e a non committare le dipendenze, il motivo è abbastanza semplice: il comportamento del package restore è predicibile. Se nel mio packages.config locale c’è una versione della dipendenza il package restore ripristinerà quella versione anche se ne esiste una superiore.

La predicibilità è fondamentale, altrimenti rischiate che su due macchine due package restore distinti producano due risultati diversi. Cosa inaccettabile.

Cosa che si verifica tranquillamente con i package manager per Javascript in cui potete specificare che le versioni delle vostre dipendenze sono fluttuanti. In questo caso avete due scelte:

  1. Come dice Alessandro non lo fate, ma semplicemente mettete una versione fissa. Fine dei giuochi.
  2. Fate commit delle dipendenze e quindi il package manager trovandosele già in locale quelle usa.

1 tutta la vita :-) Ovviamente non sottolineo il dettaglio che in ogni caso package restore ha bisogno di connettività. Cosa in alcune zone del mondo rara e preziosa.

In questa breve, e conclusa, serie:

author: Mauro Servienti | posted @ mercoledì 8 marzo 2017 8.15 | Feedback (0)

Una chiacchierata introduttiva a GraphQL @CodemotionIT


Siete curiosi di scoprire cosa sia GraphQL e perché sia Facebook che GitHub sembra non ne possano più fare a meno?

Venerdì 10 marzo, alle 14, sarò ospite di un webinar gratuito, organizzato da Codemotion, durante il quale faremo una chiacchierata introduttiva a GraphQL, ponendo l’accento sulla interessante relazione che ci può essere con un’architettura SOA.

GraphQL and Microservice Architecture

Come possiamo progettare la comunicazione tra UI e back-end quando quest'ultimo è composto da decine (se non di più) di Microservices? Abbiamo la giusta separazione e autonomia lato back-end, ma tutto alla fine deve tornare insieme lato front-end. Come evitiamo che si trasformi nel solito caos di spaghetti code? Come evitiamo che operazioni semplici si trasformino in un tornado di web request? Durante questo webinar introdurremo i concetti base di GraphQL e vedremo come si sposa con la Services UI Composition al fine di comprendere come progettare e implementare con successo una UI per i nostri Microservices.

Maggiori informazioni e iscrizioni: https://attendee.gotowebinar.com/register/155986996187235841

author: Mauro Servienti | posted @ lunedì 6 marzo 2017 7.26 | Feedback (0)

Le sessioni, i titoli e gli abstract.


So che questo appello potrebbe cadere nel vuoto ma sia da partecipante che da speaker mi sento in dovere di farlo.
Mettiamola così: andate al cinema a vedere “Trainspotting”, comprate il vostro biglietto e tutti eccitati vi sedete nella sala giusta in pole position. Inizia il film e vi fanno vedere “50 sfumature di grigio”.

Per chiunque sarebbe inconcepibile.

Il pubblico

È la stessa esperienza che un partecipante ad una conferenza, o evento in generale, fa quando i titoli o gli abstract, se ci sono, non coincidono con quello che poi succede durante la sessione.

Si, perché non solo capita che i titoli, o gli abstract, non abbiano nulla a che spartire con l’argomento poi trattato, ma succede anche che gli abstract siano un laconico e deprimente “TBD…”.

A casa mia è una pura e semplice questione di rispetto.

Lo speaker

Preparare una sessione, un titolo, e un abstract, è uno sforzo non indifferente, specialmente se lo dovete fare in una lingua diversa da quella nativa. Non farlo, oltre a essere irrispettoso nei confronti della nostra ragione di esistere, il pubblico, ci priva anche di un’interessante opportunità.

Ci sono due importanti componenti, oltre alla storia, in un talk:

  • Thesis
  • Call to Action

Riuscire a costruire un abstract, che allo stesso modo di un pitch, racchiuda in poche righe entrambe le cose è difficile. Quando ci riuscite diventa un perfetto faro che vi guida nella creazione dei contenuti del talk stesso. Vi permette di capire cosa è in tema e cosa no. Vi aiuta a garantire che da spettatore non vi sentiate davanti al film sbagliato.

È giusto che sia molto faticoso.

author: Mauro Servienti | posted @ venerdì 3 marzo 2017 12.13 | Feedback (1)

Semantic Versioning: come?


Prendiamo come esempio il bug generato dalla breaking change di RavenDB, bug che abbiamo usato come incipit di questa discussione.

È possibile prevenirlo?

Si, e pure con estrema facilità. Uno degli step del nostro processo di build consiste nel far girare un tool che confronta l’API pubblica di due assembly e in base alla versione degli assembly decide se far fallire o meno la build nel caso in cui SemVer non sia rispettato.

Il tool, a fini di test, è esposto anche come web server, potete quindi provarlo voi stessi:

http://apicomparer-preview.particular.net/compare/ravendb.client/3.0.30165...3.5.2#.NETFramework,Version=v4.5

La chiamata di cui sopra altro non fa che:

  • recuperare i pacchetti nuget referenziati nell’URL
  • spacchettarli
  • confrontare le API pubbliche a fronte di un set di regole

E…boom. Tra la 3.0 e la 3.5 ci sono una quantità spaventosa di breaking change.

Se non fosse che è molto costoso dovremmo sottoporre al nostro simpatico ApiComparer anche tutte le dipendenze.

Nota

ApiComparer è open source: https://github.com/ParticularLabs/APIComparer

Test, test, test e ancora test

I tool, essendo robi automatici e molto poco senzienti, fanno tanto ma hanno tanti limiti. La seconda cosa da fare è quindi scrivere tanti test che garantiscano che il comportamento atteso sia rispettato. Questa seconda parte è forse la più difficile.

Perché la più difficile? perché è molto complesso (al limite dell’impossibile secondo me) prevedere tutti gli usi possibili che il vostro utente farà dell’API che gli fornite.

Una strategia

Alla lunga mi sto rendendo conto che una strategia, figlia sia del lavoro in Particular, ma anche dell’aver manutenuto Radical per circa 10 anni, è quella di ridurre all’osso la superficie dell’API pubblica. Tutto è internal per definizione e quando avete voglia di metterlo public fatevi delle domande.

Proprio al fine di garantire il più possibile il rispetto di SemVer ogni volta che in Particular qualcuno ha bisogno di un API pubblica ci si ferma e si fa un lungo ragionamento finalizzato a capire come ottenere lo stesso risultato senza un’API pubblica.

La breaking change sono il nostro incubo, e nonostante tutto quello che facciamo ad ogni major release siamo di fronte alla dolorosa necessità di introdurne. Miglioriamo sempre di più, ma la perfezione è utopica oppure ha un costo insostenibile ;-)

author: Mauro Servienti | posted @ mercoledì 1 marzo 2017 9.00 | Feedback (0)