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 - 31452
  • Articles - 310
  • Comments - 99758
  • Trackbacks - 226486

Bloggers (posts, last update)

Latest Posts

Services Composition: ViewModel(s) Composition - Take 4

image

È tanto che non parliamo di Services Composition e mi sono appena reso conto che abbiamo lasciato il discorso in sospeso. L’ultima volta che abbiamo toccato l’argomento abbiamo delineato cosa succede quando componiamo informazioni che provengono da più servizi e lo scopo è visualizzare un singolo elemento, come ad esempio 1 prodotto. Cosa succede se dobbiamo visualizzare una lista?

Sia nello screenshot di cui sopra, che nel seguente, stiamo visualizzando un insieme di elementi, tutti a loro volta frutto di un processo di composizione.

image

Salta probabilmente subito all’occhio il potenziale problema in cui possiamo incappare: SELECT N+1 over HTTP. Il rischio è, se applicassimo un processo di composizione come quello che applichiamo al singolo elemento, di produrre un tornado di richieste verso i servizi. Data una lista di 10 elementi dove ogni elemento è composto da 5 servizi avremmo 50 richieste. Inaccettabile.

Se guardiamo entrambi gli screenshot di cui sopra ci rendiamo però conto che in entrambi gli scenari (e direi in tutti gli scenari) c’è un owner, nel primo è il prodotto selezionato, nel secondo il carrello.

Possiamo quindi dire che la composizione di una lista è un processo in 2 passaggi:

  • L’owner intercetta la richiesta (ad esempio /shopping-cart)
    • va dal suo back-end
    • recupera la lista di id che devono essere visualizzati (gli ID dei prodotti in questo momento aggiunti al carrello)

image

  • recuperati gli ID si limita a comunicarlo a tutti gli “attori” potenzialmente interessati

image

  • Utilizzando in soldoni un “evento” in-memory e sincrono alla richiesta HTTP (del resto altro non potrebbe essere, forse… ;-P )
    • L’evento porta con se la lista degli ID caricati
  • Gli interessati gestiscono l’evento…

image

  • …e altro non fanno che andare dai loro servizi di back-end e recuperare le informazioni relative agli ID da “comporre”…

image

  • e il cerchio si chiude, abbiamo composto una lista garantendo che il numero di chiamate ai servizi di back-end sia sempre limitato al numero di servizi coinvolti, quindi 5 servizi, 5 chiamate a prescindere da quanti elementi visualizziamo

Per approfondire potete consultare e giocare con l’esempio disponibile online.

Post in questa serie:

posted @ 10/23/2017 11:29 AM by Mauro Servienti

Prossime sessioni in calendario… ovvero, dove venire a incontrarmi e salutarmi!

Un breve post per segnalarvi i prossimi eventi dove terrò delle sessioni:

- Sabato 28 Ottobre, Pavia, Startup Weekend, nel pomeriggio terrò una sessione sul public speaking con un tema un po’ particolare: fare in modo che il messaggio di business arrivi in maniera efficace.

- Venerdì 10 Novembre, Milano, Codemotion, nel pomeriggio terrò una sessione sul serverless computing in Azure, Functions, Logic Apps, annessi e connessi Smile

- Sabato 18 Novembre,Venezia Mestre, Xe One Day, nel pomeriggio terrò una sessione sul public speaking dedicato ai geek!

- 28-29-30 Novembre, Milano, WPC 2017, avrò due sessioni, una sul public speaking e una su Azure assieme al mitico Vito!

- Mercoledì 6 Dicembre, Brescia, ci sarà un “brainpirlo” dove parlerò di public speaking… e poi spiedo bresciano!

Per il 2017 dovrebbe essere tutto… Winking smile

posted @ 10/23/2017 11:09 AM by Lorenzo Barbieri

Qwant

motore di ricerca tutto europeo che rispetta al 100% la tua privacy....

https://www.qwant.com

posted @ 10/22/2017 1:56 PM by Alessandro Gervasoni

mongobooster


https://mongobooster.com

MongoBooster is a shell-centric cross-platform GUI tool for MongoDB

posted @ 10/20/2017 4:09 PM by Alessandro Gervasoni

Cosa vuol dire che una Pull Request deve essere “piccola”

image

Roberto, che ovviamente è il benvenuto fa una domanda molto interessante:

Mini pull request: ma che dimensioni avranno?

La domanda è un po’ rognosa, perché è un po’ come chiedere quanto deve essere grosso un microservizio, la risposta ovviamente è quella odiosa in stile consulente: dipende :-)

Facciamo un esempio per capire quale è il problema:

  • stato creando una nuova demo
  • la nuova demo è composta da una decina di progetti C#

Il primo approccio:

  • scrivete tutto
  • aprite la Pull Request

un vostro collega arriva e si ritrova con

  1. circa 400 file
  2. una quarantina di commit

È un’impresa veramente ardua, anche se avesse piena padronanza del contesto. Figuriamoci se non l’ha.

Tenendo come esempio qualcosa di completamente nuovo, come una nuova demo, vediamo come internamente ci aspettiamo che le cose funzionino.

Collaborazione

Ovvio che il primo muro da abbattere è quello che ha portato alla richiesta di review solo alla fine. È quindi fondamentale che chi sta costruendo la demo in questione inizi a committare  e richiedere review il prima possibile.

Questo impone un’organizzazione mentale e pianificazione del lavoro molto rigorosa perché ovviamente ogni commit deve essere in qualche modo auto-consistente e revisionabile.

Consistenza

La consistenza è il secondo punto fondamentale, se in un commit ci sono modifiche non coese tra loro, ma che toccano parti del codice totalmente indipendenti chi fa review fa molta più fatica a capire cosa sta succedendo.

Dimensioni

Queste prime due pratiche aiutano ad alleviare il problema da cui siamo partiti, ma ovviamente se arrivassero ad un certo punto del processo un altro paio di occhi siamo da capo a piedi.

Mergiamo, è tanto tempo che non lo facciamo… (cit.)

Paradossalmente dopo che ogni commit è stato revisionato potremmo mergiare la branch su cui stiamo lavorando sulla linea principale. Il che ovviamente introduce il problema che rischiamo di rompere la catena di deploy perché non c’è scritto da nessuna parte che quello che stiamo sviluppando sia rilasciabile.

Ecco quindi che ha molto senso introdurre il concetto di linea non di produzione (develop) o addirittura di linee dedicate a funzionalità specifiche (aka feature-branch). Cosa ci impedisce di avere:

  • Branch: develop
  • Branch: demo-fantastica (aperta da develop)
  • Branch: infrastruttura-demo-fantastica (aperta da demo-fantastica)
  • Una piccola serie di piccoli commit coesi
    • 3/4 commit nel nostro caso è un buon numero
    • 5/6 file toccati per commit nel nostro caso è un buon numero

Ogni volta che il reviewer dice che va bene mergiamo la branch su cui stiamo lavorando su demo-fantastica e ne apriamo una nuova, con un nome sensato, per andare avanti. Questo ci garantisce che quello che sta su demo-fantastica sia stato sottoposto a review, non è completo e magari non funziona ancora ma la review iniziale è stata fatta.

Diciamocela, se non riusciamo a tenere le cose in piccolo e per introdurre una modifica siamo obbligati a toccare un sacco di roba probabilmente abbiamo altri problemi, che ricadono sotto il simpatico cappello chiamato “debito tecnico”.

posted @ 10/20/2017 11:39 AM by Mauro Servienti

Il lavoratore remoto: lunga vita alle review

Icon_stamp_under_Review_textured_askew.svg

Nella nostra esperienza il “pair programming” da remoto è compito arduo, gli strumenti se si trovano sono estremamente acerbi, e la semplice condivisione dello schermo non ha neanche lontanamente lo stesso effetto dell’essere seduti uno di fianco all’altro. Se in più ci mettete l’ovvia magagna delle time zone il disastro è servito.

Il nostro strumento prediletto sono quindi diventate le code review.

  • Se fai push su master o develop direttamente ti tagliamo “i ditini”: apri una pull request, per tutto.
  • Se la pull request è troppo grossa qualcuno molto rapidamente te la falcerà.
  • Se la pull request contiene commit che non ci azzeccano uno con l’altro, verrai cazziato e qualcuno molto rapidamente te la falcerà.
  • Se fai merge delle tue pull request ti tagliamo “i ditini”: qualcun altro farà review e approverà la PR.

Chi fa review sviluppa uno skill detto “gran scassa…”, soprattutto quando subite le prima review. Poi:

  • I coding standard vengono pian piano assorbiti da tutti
  • Lo stile di scrittura del codice si uniforma
  • La dimensione delle PR è sempre piccola e la PR sono ben strutturate in modo da semplificare al massimo la review
  • La conoscenza inevitabilmente si diffonde

Alla fine vi ritrovate ad apprezzare l’immenso favore che vi ha fatto chi vi ha fatto le prime review. Oppure diventiamo tutti dei “gran scassa…” e non ce ne accorgiamo più ;-)

posted @ 10/18/2017 11:57 AM by Mauro Servienti

Il lavoratore remoto: la diversa-socializzazione

group of monkeys

Il lavoratore remoto, a differenza di quello colocato, non socializza, o fa molta più fatica a socializzare, proprio perché non c’è un “posto” di lavoro che ne favorisca il processo. È quindi facile diventare l’orango di turno che, come in natura, vive la sua vita in solitaria. Solo che il buon orango ha uno scopo ben preciso nello star da solo, mentre sappiamo che l’essere umano molto rapidamente si trasforma in uno strano mostro alienato dalla società.

Il lavoratore remoto deve quindi fare qualcosa di proattivo per stimolare socializzazione dato che non è immerso in un contesto che la favorisce.

Approfittiamone

Tempo fa abbiamo parlato di diversity e della sua importanza in funzione della diversità di pensiero. Il lavoratore remoto ha un’occasione d’oro per cominciare un processo che lo porta ad ampliare le sue vedute. La necessità di cercare socialità principalmente al di fuori del nostro ambiente lavorativo ci può spingere a fare nuove conoscenze, ad andare a più conferenze, ad cercare uno user group vicino a noi (o magari non troppo vicino), e perché no dopo un po’ a cercare stimoli anche in quella che non è la nostra comfort zone.

Insomma non chiudetevi in casa. Non fa bene a noi, ma non fa bene neanche ai nostri colleghi.

posted @ 10/16/2017 7:21 AM by Mauro Servienti

Serilog

Flexible, structured events — log file convenience.

https://serilog.net

posted @ 10/13/2017 2:58 PM by Alessandro Gervasoni

Announcing Microsoft Edge for iOS and Android, Microsoft Launcher

posted @ 10/11/2017 10:26 PM by Alessandro Gervasoni

Il lavoratore remoto: demo, tutorial, e tanto tanto materiale scritto.

typewriter-1462564916ktC

Se da un lato scrivere è attività da ponderare, dall’altro per il lavoratore remoto è attività fondamentale. Ogni volta che dovete condividere qualcosa con i colleghi in un modello colocato sareste portati ad indire una riunione. Quando lavorate da remoto è molto facile transitare da una riunione ad una conference call, peccato che questa invada lo spazio e l’autonomia di tutti gli invitati come farebbe un lock pessimistico in uno database con alto traffico.

Un disastro insomma. Non che in uno scenario colocato non lo sia, anzi.

La soluzione alla condivisione di materiale è, ad esempio, preparare demo, tutorial e documentazione, con tutti i vantaggi del caso. Ci sono dei casi in cui, sempre di più ultimamente, in cui ad esempio registriamo delle demo e poi le condividiamo internamente attraverso Slack. In soldoni facciamo la conference call con noi stessi, da soli, la registriamo e la rendiamo disponibile ai colleghi da consumarsi in maniera asincrona. Allo stesso modo l’eventuale Q&A può avvenire in maniera asincrona.

Come per la documentazione, il dover preparare una presentazione, una demo, o un tutorial che possa essere consumato da altri in maniera asincrona ne aumenta inevitabilmente la qualità. Perché è molto più semplice, e immensamente meno efficace, parlare a casaccio in maniera sincrona con dei colleghi di qualcosa, invece che organizzarsi perché il contenuto non abbia bisogno di chi l’ha prodotto perché possa essere consumato. Oltre al dettaglio che mantiene il suo valore nel tempo.

posted @ 10/11/2017 10:03 AM by Mauro Servienti

Nuova azienda, nuovo blog



Ho realizzato non tutti sanno che da qualche tempo mi sono messo dinuovo in proprio, ho aperto la mia azienda, e ho creato un blog aziendale.

Questa è la mia nuova avventura: http://www.smharter.com/

E questo è il blog aziendale. Qui pubblico guide o post sul tema lean-agile IT/Business/Coaching, che a differenza di questo mio blog in UGIdotNET più riflessivo e personale, li i post sono piu pensati e con il lettore in mente: http://www.smharter.com/blog/

Accetto volentieri commenti e feedback.




posted @ 10/10/2017 1:17 PM by Luca Minudel

Il lavoratore remoto: Arrabbiato? non scrivere

cat-1865546_1920

È probabilmente un consiglio che vale sempre, ma ancor di più per il lavoratore remoto: quando sono le emozioni a guidare non usate comunicazione scritta.

WhatsApp è causa della rottura di una quantità abominevole di rapporti, lo so è triste e anche un po’ deprimente. Ho assistito personalmente ad amicizie di lunghissima data andate in frantumi per un’interpretazione sbagliata di un messaggio scritto. E attenzione, non c’è faccina che tenga, se poi ci mettiamo che c’è gente che si è nascosta molto bene quando hanno cercato di insegnarli grammatica, ortografia e l’uso dei famigerati puntini di sospensione…siamo a posto.

Polemiche a parte: Scrivere è difficile, comunicare emozioni scrivendo lo è ancora di più, essere diplomatici mentre si è guidati dalle emozioni e nello stesso tempo si sta scrivendo è compito assai arduo.

Gli strumenti di comunicazione del lavoratore remoto sono nella maggioranza dei casi basati sulla scrittura, vuoi che sia una mail, la chat aziendale o un artefatto di qualsivoglia genere. Ci sono tanti momenti nella quotidianità lavorativa in cui vi girano, non è mica un peccato, o momenti che sono comunque guidati dalle emozioni. Ecco, se dovete esternare qualcosa in questi momenti fate il possibile per non farlo per iscritto, vis-a-vis è nettamente meglio.

Le parole saranno supportate da tutta la comunicazione non verbale e le reazioni del vostro interlocutore vi aiuteranno, spesso inconsciamente, a gestire la situazione.

Questo è ancor più importante se la comunicazione è pubblica, come ad esempio nel nostro caso dove moltissimi degli scambi di opinioni avvengono in commenti su GitHub in repository pubblici, dove molti degli osservatori sono anche totalmente a digiuno del contesto.

posted @ 10/9/2017 7:51 AM by Mauro Servienti

[OT] Scriptd - Read books, audiobooks, and more

posted @ 10/6/2017 12:13 PM by Alessandro Gervasoni

Il lavoratore remoto: Nessuno lo sa se non lo dici

2017-05-23-16-13-10

Le dinamiche del lavoro colocato non si possono applicare al lavoro remoto, questo credo sia ormai chiaro. Ne stiamo parlando da un po’ e con i ragazzi di dotNetPodcast stiamo anche registrando una serie di puntate sul tema.

In un ambiente colocato l’ambiente vi osserva, i vostri colleghi vi osservano, il vostro capo vi osserva. In un ambiente in cui c’è contatto fisico con le persone il linguaggio non verbale è una componente importantissima. Questo significa che la comunicazione può essere in qualche modo passiva, non siamo noi a dover per forza iniziare una comunicazione, ma possono essere gli altri sulla base dell’osservazione a decidere che è il caso di iniziarla.

Questa dinamica è totalmente inesistente per il lavoratore remoto, diventa quindi fondamentale essere proattivi, molto proattivi, nella comunicazione con i colleghi.

Non aspettate che la gente venga da voi, andate voi da loro.

Questo vale per qualsiasi cosa: dubbi, problemi, comenti, critiche, stato avanzamento lavori e anche sfoghi e frustrazioni. Non c’è nessuno che ci osserva e che percepisce i nostri sbuffi o malumori non verbali, diventa quindi importante, anche se tutto tranne che facile, essere proattivi.

La considerazione ovvia, leggendo quanto sopra, è che una realtà in cui alzarsi e parlare non è ben visto non è di certo un ambiente che stimola la proattività. Ne consegue che probabilmente non sarà un ambiente adatto al lavoratore remoto.

posted @ 10/6/2017 9:15 AM by Mauro Servienti

RFC: Request for Comments

consent-2052051_960_720

Un po’ di tempo fa ci siamo lasciati dicendo che il consenso non funziona. Mettere d’accordo le persone è impresa ardua e complessa, metterne d’accordo tante è molto faticoso, metterle d’accordo tutte è impossibile.

Il nostro processo decisionale è basato su alcuni principi cardine:

  • Sbagliare è umano, e non è un problema
  • Prendere decisioni in solitaria è molto più rischioso che se condivise con un gruppo
  • Prima di prendere una decisione è fondamentale:
    • capire quale sia il problema (o oggetto del contendere)
    • essere certi che il toro che stiamo prendendo per le corna non sia troppo grosso, nel qual caso spezzettare il toro in sotto-problemi, e ricominciare, è cosa buona e giusta

Fatte queste premesse quando dobbiamo affrontare un nuovo compito quello che succede in soldoni è:

  • Un gruppo di persone (task force, TF), diciamo da tre a cinque, si compone al fine di gestire/risolvere il compito in oggetto (il toro)
  • La TF comincia una prima fase di analisi del problema e conferma di avere tutti gli skill necessari alla soluzione/gestione. Nel caso in cui così non fosse ha due opzioni:
    • rinunciare, e smantellarsi
    • contattare degli specialisti al fine di “comperare” (come se fossero consulenti esterni, ma in realtà possono essere anche colleghi) consulenza, conoscenza ed esperienza
  • Ogni volta che la TF è in procinto di prendere una decisione viene iniziate una fase, la cui durata è a discrezione della TF, chiamata RFC:
    • La TF annuncia l’RFC
    • l’RFC, è un documento, dettaglia il contesto, le soluzioni prese in considerazione, pro e contro, e l’attuale proposta o direzione che la TF vorrebbe prendere
  • Chiunque ha la possibilità di commentare
  • Al termine della finestra di RFC la TF può valutare i commenti/suggerimenti/critiche. Non è obbligata a prenderli in considerazione
  • La TF è pronta per procedere e se necessario in uno stadio successivo fare un’altra RFC.

Chiunque, con buone e solide motivazioni può bloccare tutto in qualsiasi momento (stop the line) se ritiene che le scelte che la TF sta facendo siano sbagliate. Con buone e solide motivazioni.

posted @ 10/4/2017 7:32 PM by Mauro Servienti

draggable

a lightweight, responsive, modern drag & drop library



https://shopify.github.io/draggable/

posted @ 10/4/2017 5:41 PM by Alessandro Gervasoni

12 minuti ben spesi: Why good leaders make you feel safe

image

Parafrasando:

Un buon leader si sacrifica per salvare gli altri, non sacrifica gli altri per salvare se stesso.

Manager con i macchinoni, i bonus e le posizioni acquisite: meditate.

Versione integrale: https://www.ted.com/talks/simon_sinek_why_good_leaders_make_you_feel_safe

posted @ 10/2/2017 6:23 AM by Mauro Servienti

Lo strano concetto di sicurezza di ATM

Ci risiamo :-) La sfortuna vuole che mi sono dimenticato la password per accedere al sito ATM, lo uso per poter acquistare i biglietti dei mezzi di Milano direttamente dall’app.

image

Mi sembra normale che siccome puoi usare l’app per spendere del denaro:

  • la password te la mandano per e-mail, che sappiamo essere sicurissima
  • la password non deve essere cambiata al primo accesso…WAT?
  • non vi è nessuna possibilità di avere una sorta di, o una vera che sarebbe meglio, 2 Factor Authentication

Grrrr…

posted @ 9/29/2017 11:01 AM by Mauro Servienti

https://www.codetee.com

posted @ 9/28/2017 10:43 PM by Alessandro Gervasoni

Quando la UX toppa alla grande

Qualcosa di diverso oggi. Ho aggiornato l’iPad ad IOS 11, mi piace, funziona bene nonostante l’iPad in questione abbia ormai quasi 3 anni, ma una cosa mi ha sorpreso (o deluso se volete) parecchio.

Domanda: quante applicazioni ho in esecuzione in questo momento?

2017-09-25 21.19.46

La risposta è 5, perché la UX corretta di quella schermata sarebbe dovuta essere la seguente:

2017-09-25 21.19.54

Che fa capire al volo che quello che vedo non è tutto, la UX attuale obbliga a tentare di scrollare verso sinistra sempre perché non si ha idea se vi sia qualcosa.

E dire che “altri” ci avevano pensato qualche anno fa…A buon intenditore poche parole.

posted @ 9/27/2017 10:19 AM by Mauro Servienti

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