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, edit the default.aspx page in your Subtext installation.

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

Powered By:

Blog Stats

  • Blogs - 715
  • Posts - 31325
  • Articles - 310
  • Comments - 93044
  • Trackbacks - 237997

Bloggers (posts, last update)

Latest Posts

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.

posted @ 20/03/2017 9.18 by Mauro Servienti

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.

posted @ 17/03/2017 9.30 by Mauro Servienti

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.

posted @ 15/03/2017 8.45 by Mauro Servienti

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.

posted @ 14/03/2017 9.57 by Mauro Servienti

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.

posted @ 13/03/2017 19.12 by Mauro Servienti

Screen Resolution Debian (guest) su Hyper-V

Se si ha una macchina virtuale Debian come guest su Hyper-V e si ha la necessità di cambiare la risoluzione dello schermo, dopo averle provate tutte, provare anche questa Smile.

Come riportato su uglygizmo.blogspot.ch i passi da seguire sono veramente pochi, per convenienza li riporto qui:

  1. Edit the grub configuration file, for example:  sudo vi /etc/default/grub
  2. Find the line starting with GRUB_CMDLINE_LINUX_DEFAULT, and add "video=hyperv_fb:1680x1050" (or your custom resolution) in between the quotes. For example: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1680x1050"
  3. Save and exit 
  4. Run sudo update-grub
  5. Restart your computer

Nel mio caso finalmente sono riuscito ad impostare la risoluzione desiderata.

posted @ 12/03/2017 11.02 by Pietro Libro

Dubbio del sabato mattina…

Ma chi vede i link al blog dai social ha letto il post di ieri o ha apprezzato solo la vignetta? Smile

In ogni caso voglio testare le nuove impostazioni di https://dlvr.it Thumbs up

posted @ 11/03/2017 10.36 by Lorenzo Barbieri

Make an impact.

Rendete straordinaria la vostra vita

https://youtu.be/L7maQfH0lMs

posted @ 10/03/2017 17.33 by Mauro Servienti

IronPdf


http://ironpdf.com/
ironpdf makes it easy to generate pdfs in your .net apps & websites.

posted @ 10/03/2017 14.41 by Alessandro Gervasoni

“wherever dev go, future follows”

Questa frase è veramente molto interessante e profetica. L’ho sentita al meeting con James Whittaker, non so se è sua o se era una citazione, non lo ricordo. So solo che fa il paio con “l’unico modo di conoscere il futuro è crearlo”.

Penso spesso al potere che abbiamo noi Dev, se gestito bene. Non basta saper programmare, bisogna saper sfruttare al meglio le opportunità che ci sono, bisogna non focalizzarsi “esclusivamente” sulla parte tecnica, ma capire che comunicazione, affidabilità personale, gestione delle proprie risorse, interazione con gli altri, networking, e tante altre soft-skill che spesso sottovalutiamo sono indispensabili.

Prendiamo il parlare in pubblico, tema che mi interessa ormai da molti anni. Molti pensano che parlare in pubblico sia solo tenere corsi o fare il relatore ad una conferenza. Si, ma non solo.

Parlare in pubblico è esporre un progetto al proprio capo, al direttore della propria divisione, parlare durante uno stato avanzamento lavori cercando di guidare attivamente il discorso e “tramettendo” il valore del proprio lavoro, fare un pitch per la propria startup, affrontare con successo un colloquio individuale o di gruppo, stare in mezzo agli altri da protagonista e non da semplice osservatore. Parlare in pubblico è convincere il proprio capo che meritiamo un aumento.

E no, non voglio dire che non c’è futuro per il mestiere di dev, e che il dev deve prima o poi diventare un trainer, PM, analista o altro per avere successo… tutt’altro.

Dico però che se il dev vuole uscire dallo stereotipo del supertecnico incapace di comunicare deve alzarsi, fare uno sforzo, e capire che basta veramente poco.

Risultati immagini per how users see geeks

Ho fatto una scommessa tempo fa sul fatto che si possa parlare di “public speaking” ai geek, ai tecnici, alle persone introverse. Che si possa passare da sentire persone incapaci di comunicare a interagire con persone che comunicano efficacemente. Ho fatto sessioni, sto preparando un sacco di materiale, ho iniziato una serie sul mio profilo linkedin (interrotta prematuramente, a proposito di affidabilità…).

Devo dirvi che ho avuto risposte buone in teoria, ma che poi hanno portato a poco.

Sto cercando di vincere la scommessa, in collaborazione con Codemotion abbiamo preparato un workshop di una giornata interamente dedicato ai dev, ai geek, ai tecnici, meglio se introversi Smile

Per i lettori del blog c’è la possibilità di iscriversi al workshop allo stesso prezzo dell’early bird scaduto a fine gennaio, fino al 16 marzo, basta contattarmi a nome PUNTO cognome CHIOCCIOLA outlook PUNTO com per avere il codice.

Se vogliamo creare il futuro dobbiamo essere in grado di raccontarlo. Vi aspetto.

posted @ 10/03/2017 14.18 by Lorenzo Barbieri

Fable

Fable: An F# to JavaScript Compiler

posted @ 09/03/2017 17.43 by Alessandro Gervasoni

Add REST Api Client: Unable to resolve dependency…

Se avete intenzione di utilizzare lo strumento “Add REST Api Client” di Visual Studio (2015/2017 poco importa):

image

e vi “scontrate” con l’errore “Unable to resolve dependency ‘Microsoft.NETCore.Platform ….’

image

Un “workaround” veloce è installare il pacchetto “Microsoft.Rest.ClientRuntime”:

Install-Package Microsoft.Rest.ClientRuntime

Attendere il tempo necessario (scarica un po’ di pacchetti di contorno Smile) e poi riprovare l’aggiunta del client REST, questa volta con successo:

image

posted @ 09/03/2017 15.53 by Pietro Libro

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:

posted @ 08/03/2017 8.15 by Mauro Servienti

Visual Studio 2017 Officially Released

https://www.visualstudio.com/it/vs/whatsnew

posted @ 07/03/2017 22.58 by Alessandro Gervasoni

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

posted @ 06/03/2017 7.26 by Mauro Servienti

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.

posted @ 03/03/2017 12.13 by Mauro Servienti

Page speed optimization

https://varvy.com/pagespeed/

posted @ 02/03/2017 17.36 by Alessandro Gervasoni

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 ;-)

posted @ 01/03/2017 9.00 by Mauro Servienti

Casi d’uso, architettura e tecnologia - @CodemotionIT Roma, marzo 2017

La tecnologia è importante, ma da sola non risolve nulla. Allo stesso modo l’architettura è importante ma da sola risolve veramente poco.

Una volta compreso il dominio, i problemi che vogliamo risolvere e come li vogliamo risolvere concettualmente ha molto senso capire quali siano le scelte tecnologiche perfette per quei casi d’uso.
Durante il workshop discuteremo molto di tecnologia, spingendoci a prendere in considerazione graph database, ad esempio, o ad approfondire perché in certi scenari avere Elastic Search o un database che supporti atomic increment/decrement possa essere la scelta vincente.

È solo a questo punto che potete cominciare a fare dei compromessi:

  • Ho capito a fondo quale sia il problema
  • Ho capito come modellarle la soluzione
  • Ho capito quale sia la tecnologia ideale per il problema e la soluzione

Quando è tutto chiaro, posso ad esempio fare una scelta tecnologica diversa sapendo a quali potenziali effetti collaterali o problemi vado incontro e perché.

Se la prima volta che sentite parlare di questo workshop, qui di seguito una breve introduzione ai 4 macro argomenti che tratteremo:

Maggiori informazioni: http://rome2017.codemotionworld.com/workshop/microservices-development-deep-dive/

posted @ 28/02/2017 12.20 by Mauro Servienti

Azure Chat Talk, Mercoledì 1 marzo a Milano

Ci sarò anch’io tra i partecipanti del meetup di DotNetLombardia il 1 marzo dalle 16.30 alle 18.30 (e cena Smile) nella nuova sede Microsoft di Via Pasubio a Milano, vicino alla stazione di Porta Garibaldi.

Non c’è un’agenda precisa, voi portate le domande, e insieme vedremo se riusciremo a dipanare tutti i dubbi.

Ci vediamo li?

posted @ 27/02/2017 16.00 by Lorenzo Barbieri

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