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 - 714
  • Posts - 31149
  • Articles - 309
  • Comments - 111780
  • Trackbacks - 583156

Bloggers (posts, last update)

Latest Posts

Raccontare una storia

Avete presente quel momento in cui siete al cinema e il film non vi piace? e vi rendete conto che il film non vi piace perché la storia non sta insieme, non ha ne capo ne coda, è congegnata male, o semplicemente non funziona.

La storia è tutto

La storia che vogliamo raccontare è tutto, sia un film, una pubblicità, un post come questo, una serie di post o una presentazione. Quindi perché vi fate del male e:

  • Le slide? mezz’ora prima della sessione.
  • Gli esempi? ma si li costruisco al volo durante le demo

Tutto sbagliato

Sapete perché? perché si percepisce. Esattamente come quando siete al cinema e vi annoiate e vorreste uscire se la presentazione è raffazzonata in qualche modo si capisce, le persone si annoiano, vogliono uscire e la volta dopo non tornano. Questo impatta su chi presenta ma anche su chi organizza la conferenza oltre che ovviamente su chi viene per ascoltare.

La preparazione è tutto…

…e alla base di una buona preparazione c’è una buona storia. Non solo, chiedetevi perché lo volete raccontare, a chi lo volete raccontare e come lo volete raccontare. Mi sono reso conto che da un po’ ho messo in atto quello che Lorenzo chiama procrastinazione creativa. Le slide le preparo fisicamente comunque molto tardi, di solito qualche giorno prima, ma la storia nasce, si modifica, si distrugge, e rinasce a volte, per settimane in alcuni casi mesi prima dell’evento.

Un esempio

Ai Community Days parlerò di lavoro da remoto, è la terza volta che erogo quella sessione, sarà per la terza volta una sessione completamente diversa. La storia che voglio raccontare sta cambiando nella mia testa, ma soprattutto sta cambiando il modo in cui la voglio raccontare perché le prime due volte che l’ho raccontata il messaggio che ho comunicato non mi ha soddisfatto. Fondamentalmente perché, a parer mio, in un caso la storia era debole e nell’altro mal orchestrata.

La preparazione è tutto; e preparazione e allenamento vanno a braccetto, sempre.

posted @ 26/08/2016 10.47 by Mauro Servienti

La definizione del problema.

Avete presente quelle “amene” situazioni in cui le discussioni si protraggono all’infinito senza alcuna apparente possibilità di soluzione?

Tipicamente diciamo che siamo in stallo o in conflitto….in realtà il problema potrebbe essere un altro. Spesso quello che succede è che i contendenti non stanno discutendo dello stesso problema o il problema di cui stanno discutendo è troppo ampio.

Quello che succede nel primo caso è che qualcuno solleva un problema, magari un po’ vago, dai contorni non ben definiti o mal descritto. Qualcun altro interviene e dato che il problema non è ben definito interpreta la questione generando un punto di vista diverso, leggermente o abissalmente, rispetto a quello di chi ha sollevato il problema.

A questo punto il consenso è pressoché impossibile perché non stiamo discutendo della stessa cosa.

Il secondo scenario è una variazione del primo: se il problema è troppo ampio/vasto è molto facile che i punti di vista divergano rapidamente generando ancora una volta stallo o conflitto.

Lo stallo o il conflitto sono quindi un buon indicatore, non sempre ma spesso, del fatto che probabilmente quello che manca, o che non è abbastanza chiaro, è la definizione e condivisione del problema che vogliamo risolvere.

Val la pena quindi in situazioni di stallo o di conflitto fermarsi un attimo ed essere certi che si stia discutendo della stessa cosa.

posted @ 24/08/2016 8.45 by Mauro Servienti

“starters” e “finishers”

Non esistono persone sbagliate, esistono persone al posto sbagliato. Ci sono persone molto brave ad iniziare le cose e ci sono persone molto brave a portare avanti fino alla fine le cose iniziate da altri. È più difficile trovare una persona che sia brava, ho detto brava non in grado, a gestire da sola tutto la genesi e la produzione di qualche cosa.

A mio modo di vedere questo è il motivo per cui è molto importante lavorare in team, conoscere molto bene le caratteristiche delle persone che compongono il gruppo e mixare le persone con caratteristiche complementari.

Il sottoscritto ad esempio è un pessimo “finisher”, il sottoscritto perde entusiasmo una volta che il problema è stato identificato e concettualmente risolto. Questo non vuol dire che non sia in grado di portare a termine le cose vuol dire che mi devo concentrare più di altri, che probabilmente non sono così interessati a smontare a rimontare i problemi. Io, a differenza di altri, adoro avere a che fare con i problemi. Altri adorano una vita tranquilla fatta di routine derivante dal fatto che gente come me ha preso di petto il problema e magari ha preso anche qualche schiaffone per capire come affrontarlo.

Sono io meglio degli altri? Sono gli altri meglio di me?

Siamo due lati della stessa medaglia, complementari. Gli uni senza gli altri non serviamo a nulla, o nella migliore delle ipotesi in un primo caso produciamo soluzioni lente e che si trascinano mentre in un secondo produciamo soluzioni che non sono necessariamente quelle del problema che vogliamo risolvere.

Questo apre ad un interessante problema :-) stay tuned :-P

posted @ 22/08/2016 9.44 by Mauro Servienti

Novità di VSTS nell’aggiornamento del 17 Agosto

Anche se molti saranno in vacanza, gli aggiornamenti di VSTS non si fermano, ed il 17 agosto è stato rilasciato il nuovo sprint. Come sempre i dettagli si trovano nel sito ufficiale a questo indirizzo https://www.visualstudio.com/en-us/news/2016-aug-17-vso.

In questo aggiornamento sono state fatte numerose modifiche alla UI ed alle funzionalità delle pull request, ad indicare come Git è sempre più importante nel processo di sviluppo. Una delle modifiche più carine riguarda la possibilità di visualizzare tutte le modifiche fatte ad un file durante una pull request.

Viewing changes on a pull request

In questo modo è immediatamente evidente il lavoro che viene fatto durante la pull request, in modo da verificare che eventuali suggerimenti o richieste fatte, siano effettivamente portate a conclusione.

La possibilità di commentare inline il codice è decisamente interessante, e finalmente si ha la possibilità di utilizzare Markdown e quindi anche di poter inserire snippet di codice, funzionalità decisamente interessante quando si sta commentando del codice, perché è utilissima per fornire alternative.

Comments

Tra le altre novità interessanti vi sono i Template per i Work Items, funzionalità raggiungibile direttamente dal Work Item

image

Come potete vedere si può creare un nuovo template partendo da un Work Item oppure direttamente gestirli dalle configurazione del progetto. Il capture template vi permette di partire da un Work Item già popolato e scegliere quali campi includere nel template.

image

Una volta che il template è stato creato, vi viene proposto immediatamente il link per il template, tramite il quale è possibile andare a creare un work item basato su quel template.

image

Tutti i template possono essere comodamente gestiti dalla pagine di amministrazione del progetto.

image

Queste sono le due funzionalità più interessanti a mio avviso, ma vi suggerisco di andare a leggere l’articolo ufficiale per una descrizione completa https://www.visualstudio.com/en-us/news/2016-aug-17-vso .

Happy VSTS.

posted @ 19/08/2016 10.26 by Gian Maria Ricci

“Everybody, all together, from the early on”

Sempre Luigi:

image

Quoto, e rilancio con pre-sales e supporto all'utente finale ;-)

DevOps e' l'anello tecnico di un processo di business piu' complesso, che include dinamiche economiche e politiche, oltre che puramente tecniche o funzionali.

Ho avuto la fortuna di lavorare in aziende piccole, dove oltre a dover gestire la parte tecnica (sviluppo, ops), mi sono trovato dover vendere il prodotto e il progetto di turno, a discutere di requisiti in termini di costo e di opportunita', oltre che di fattibilita' tecnica, a parlare con il Direttore di X di turno della grande azienda cliente (anche quando ero un junior con un anno di esperienza) e a gestire gli utenti incazzati perche' il sistema era andato giu' sotto carico.

Sono straconvinto che senza questa palestra non tecnica le mie skill di sviluppatore oggi sarebbero molto piu' limitate

Prima o poi mi piacerebbe sentir parlare di passaggio da DevOps a Dev+, ossia un profilo professionale di estrazione tecnica, ma che e' in grado di capire e gestire il processo di business a 360 gradi

Lo scrivevo e ne parlavo all’Agile Day, con Timothy, nel 2012: Everybody, all together, from the early on”.

posted @ 17/08/2016 9.40 by Mauro Servienti

Pillole di TFS/VSTS: pubblicazione risultati test in una build

Dall’introduzione del Visual Studio Test Runner, estendibile con plugin, non si ha più la difficoltà di eseguire Unit Test differenti da MSTest durante una build. Tradizionalmente le difficoltà incontrate erano due

-) Eseguire i test a riga di comando con una personalizzazione della build
-) Convertire il risultato dei test nel formato MSTest affinché potesse essere incluso nel risultato di una build.

Ora che i test NUnit o xUnit possono essere eseguiti direttamente con il test runner standard, si può utilizzare l’azione di esecuzione test nella build, avendo l’accortezza di avere incluso il package Nuget per il test runner apposito nel progetto di test.

image

E’ sufficiente aggiungere il package Nuget del test runner ad un progetto di test ed utilizzare il task build standard Test Assemblies per eseguire gli Unit Test durante la build.

Nel nuovo TFS / VSTS, la parte di esplorazione dei risultati dei test è stata molto migliorata, ed è quindi fondamentale che il risultato degli Unit Test sia correttamente associato alla build.

image

Ma cosa succede se per qualsiasi ragione non sia possibile utilizzare l’azione standard di esecuzione test? Ad esempio i test potrebbero essere eseguiti in altre macchine direttamente da riga di comando con esecuzione remota, oppure i test potrebbero essere eseguiti con un framework custom.

Nel nuovo sistema di build è presente un task dedicato appositamente all’upload dei risultati di test verso VSTS / TFS, chiamato appunto Publish Test Results.

image

L’aspetto più interessante di questo task è che comprende molteplici formati di output, tra cui NUnit JUnit e XUNit nativo.

image

In questo modo, anche se avete un framework di Unit Test custom per soddisfare esigenze particolari è sufficiente ad esempio fornire un output standard di tipo NUnit (https://github.com/nunit/docs/wiki/Test-Result-XML-Format) per poterlo associare direttamente alle vostre build.

Gian Maria.

posted @ 16/08/2016 11.47 by Gian Maria Ricci

Typora: Electron / take 2

Gli editor, decenti, di file Markdown languono nel mondo Windows. E no VS Code non è, ancora, un editor decente.

Please Welcome Typora

image

Typora è il primo che posso ritenere decente, grazie al mio collega John per la dritta, decente ovviamente in base all’uso piuttosto intenso che facciamo di Markdown.

Il vero merito di Typora però è un altro, dimostrare quanto tecnologie come Electron possano essere una scelte vincente per abbracciare mondi che altrimenti rischiano di essere lontanissimi tra loro.

Un’altra cosa che mi piace molto di Electron è che porta la qualità del design, tipica del mondo Mac, anche su Windows a costo zero. Il che mi fa restare su Windows anche se di motivi ne ho ben pochi.

Inoltre Electron, ovvia conseguenza direi, fa si che Mac, Linux e Windows possano essere visti come una sola piattaforma dal punto di vista dello visto di certe applicazioni.

posted @ 12/08/2016 8.39 by Mauro Servienti

La lettura da ombrellone: ecco i vincitori del Big Brother Awards tedesco!

Come sempre dal 2000, anche quest’anno sono stati assegnati in Germania i prestigiosissimi Big Brother Awards, premi attribuiti a chi, in ambito economico, politico o finanziario, si sia distinto per aver messo a rischio la privacy dei cittadini.

Senza volervi rovinare la sorpresa, vi segnalo che in questa tornata gli ambiti riconoscimenti, a mio parere non sempre condivisibili, sono stati attribuiti a servizi segreti, multinazionali del settore IT, importanti portali web, etc.

Buona lettura.

Andrea Palumbo

@ndrea_palumbo

posted @ 11/08/2016 10.21 by Staff Lex101

Services UI Composition - tecniche di recupero delle informazioni: IT/Ops

Nei nostri esperimenti con UI Compostiion fino a questo momento abbiamo dato per scontato che ci sia un solo modo per “parlare” con i servizi di backend, come potete immaginare non è proprio così. Di seguito l’elenco dei post che trattano l’argomento:

Questo post sarebbe dovuto arrivare prima del “recap”, chiedo perdono, ho bisogno di ferie :-)

Abbiamo i servizi

Quando abbiamo a che fare con una UI che deve visualizzare informazioni che provengono da sorgenti fisicamente diverse il nostro primo obiettivo deve essere quello di tenere sotto controllo il numero delle richieste che le parti della UI faranno ai vari (micro)servizi. È importante perché è molto facile che la cosa ci sfugga di mano generando problemi molto simili, ma potenzialmente su scala più ampia, a quelli che genera quello che ricade sotto il nome di “SELECT N+1”.

Vediamo un esempio in cui il problema emerge immediatamente, usiamo il solito mock-up che ci ha guidato fino ad oggi:

image_thumb
image_thumb

Ma…diciamo che gli elementi sono una lista. Se un elemento da solo genera un minimo di chiamate pari al <numero-di-servizi>, quello che non vogliamo è che una lista generi ( <n-elementi-lista> * <numero-di-servizi> ) + 1. Quello che vogliamo ottenere è invece in questo scenario che la nostra formula sia ( <numero-di-servizi>  + 1 ).

( <numero-di-servizi>  + 1 )

Il nostro obbiettivo è aggregare le richieste in uscita verso i servizi in modo da fare solo le seguenti operazioni:

  1. recuperare la lista degli “Id / chiavi primarie / identificatori univoci” delle cose che dobbiamo visualizzare
  2. Andare da ogni servizio con la lista degli “Id” recuperare tutte le informazioni in un solo colpo
  3. Una volta che le informazioni sono sul client ri-suddividerle tra i vari attori che vivono nel client

Abbiamo fondamentalmente due strategie per farlo, entrambe con pregi e difetti.

IT/Ops

Nel mondo SOA ricadono sotto il nome di IT/Ops quei componenti infrastrutturali che si occupano di aggregazione delle informazioni, o disaggregazione delle informazioni (capiremo cosa significa disaggregazione quando affronteremo il discorso scritture). Il modello IT/Ops mima esattamente quello che abbiamo appena delineato come strategia, a prescindere da dove questo avvenga, client o server, quello che succede è:

  1. Ottengo la lista delle chiavi degli elementi che devo visualizzare
  2. Preparo un contenitore per i dati, ad esempio un “dictionary”
  3. Notifico i componenti di IT/Ops che la lista è pronta
  4. Ogni componente aggrega la lista come meglio crede e chiede al suo servizio i dati che gli servono
  5. Ottenuti i dati, che ovviamente sono una lista, li disaggrega in modo da relazionarli con le chiavi di cui al punto 1 e riempie il dictionary
  6. A questo punto abbiamo una lista i cui dati sono composti da informazioni che provengono da servizi diversi

Tutto questo, che sembra molto complesso, in realtà è piuttosto semplice e può essere graficamente rappresentato come segue:

image

L’unico vero difetto di questo approccio è che è invasivo, impone cioè che tutto lo stack, dal componente della UI in giù sappiano come parlare con i servizi di back-end. Se ci pensiamo questo impone che anche chi, quindi persone, si occupa di UI sappia abbastanza bene come funziona tutto il giro, cosa non necessariamente desiderabile in team grandi.

Batching

Il sogno sarebbe poter dire al client, fai quello che vuoi come l’hai sempre fatto, per capirci meglio immaginate uno scenario basato su una Single Page Application, quello che sarebbe bello è evitare di avere per forza il concetto di IT/Ops nel client e lasciare che il client possa emettere tutte le richieste http che vuole e queste vengano in qualche modo raggruppate come meglio possibile.

La cosa è possibile anche se la mia esperienza dice che è esageratamente complessa e rognosa da gestire sul lungo periodo. Nel prossimo post vedremo quali sono le tecniche di batching, cosa risolvono e cosa complicano.

posted @ 11/08/2016 8.53 by Mauro Servienti

Nessuno dice che sia facile. Tutt’altro.

Nazareno, ma quanto parla Nazareno :-D, commenta:

image

Tu vedi un lato della medaglia... io l'altro... continuo a vedere team che non si spostano da quello che conoscono e "accettano" di "morire di manutenzione" per evitare di uscire dalla loro zona di confidenza: "in VB6 usavo il Recordset foward-only, read-only... ma non trovo il Recordset in .NET"

Come al solito "in media stat virtus"... non bisogna andare dietro solo al proprio ego, come non bisogna sedersi su quello che già conosciamo.

Fino a un po' di tempo fa pensavo che tutti i dev fossero proattivi da questo punto di vista... mi sbagliavo... purtroppo...

Ma i risultati di questo "immobilismo" o "troppa figagine" che comunque si ribalta sull'utente finale penalizza tutta la "nostra categoria".

My2Cents

Sono due problemi molto diversi quando parlo di “sincero fastidio” mi riferisco a quella attitudine, fastidiosa per me, che spinge lo sviluppatore a inventare feature che nessuno gli ha chiesto e a arzigogolare soluzioni ingegneristicamente notevoli a problemi che tipicamente hanno soluzioni molto più semplici ma molto meno allettanti. In una parola: sovra-ingegnerizzazione.

L’immobilismo è un problema molto diverso, meno fastidioso secondo me per certi versi, ma che comunque va affrontato.

Paura?

Cosa genera immobilismo? Credo (e se ci sono altre motivazioni fatevi sotto) sia la paura del cambiamento, cambiare è difficile, ci vuole coraggio e bisogna essere pronti a fallire. Tutte cose ovviamente non facili, ma nessuno ha mai detto che sia facile.

L’immobilismo probabilmente in una prima fase ha senso, ho creato, funziona, adesso lo uso per un po’ così. Ecco quando “per un po’” diventa “per un po’ troppo” scivoliamo dall’ammortizzare l’investimento all’immobilismo.

Essere pronti a fallire per imparare.

Cambiare significa principalmente essere pronti a sbagliare e fallire. Nessuno dice che sia facile, se però partiamo dal presupposto che il fallimento è un risultato accettabile la nostra prospettiva cambia radicalmente.

Si potrebbe quindi cambiare la prospettiva e dire:

quale è l’errore più piccolo che posso fare nel più breve periodo possibile per imparare il più possibile sul percorso che sto intraprendendo?

Necessita un profondo cambio della mentalità aziendale che deve essere pronta ad abbracciare il fallimento come uno dei mezzi per perseguire il successo.

posted @ 08/08/2016 8.29 by Mauro Servienti

DevOps significa (anche) condivisione delle conoscenze

Un giorno di qualche tempo fa in una conversazione tra dev:

Utilizzando HTTP si possono scambiare facilmente informazioni tra servizi remoti. Il limite è che il client deve sapere innanzitutto dove si trova (IP) il server, problema risolvibile con un file di configurazione. Un altro problema è come possiamo inserire altre macchine in modo che le richieste vengano bilanciate. Diventa necessario far si che il client sappia quante e quali macchine server sono disponibili e quando sono disponibili.

E così la conversazione continuava.

Ora lasciamo perdere per un secondo l’assurdità della conversazione, DNS, Load Balancer e Cluster, questi sconosciuti e immaginiamo che sia sostenibile pensare di essere un Dev che non ha nozioni di Ops, la frittata seguendo la conversazione di cui sopra è fatta: sovra-ingegnerizzazione alle stelle.

DevOps è anche una strada per abbracciare semplicità, per avere diversità di vedute nel team, vedute che possono portare sul piatto soluzioni a cui da soli non avremmo potuto pensare.

Dove da soli significa anche circondati e sostenuti da gente che vede il mondo con un paraocchi uguale al nostro.

posted @ 06/08/2016 17.06 by Mauro Servienti

DevOps e la prima linea

image

Possiamo generalizzare il commento di Luigi? Nello specifico mi riferisco a questo passaggio:

I giovani facciamoli sbagliare e divertire (e lasciamogli manutenere i loro mostri, cosi' "imparano") ;-)

È una delle cose che mi piacciono di più dell’esperienza DevOps che ho vissuto e per certi versi vivo a tutt’oggi:

Prendi il team che produce il codice e rendilo reperibile (“on call” nel mio gergo) di notte, durante i fine settimana e durante le festività.

Scommettiamo che la qualità cresce, i bug diminuiscono e i mostri pian piano spariscono?

Quando è qualcun altro che si alza di notte perché la produzione è crollata e il problema arriva sulla nostra scrivania con calma la mattina ci preoccupiamo meno rispetto al caso in cui sia il nostro fine settimana che va alle cozze.

DevOps è anche questo, DevOps è tanta cultura aziendale basata su concetti semplici come la collaborazione verso un fine. O forse DevOps è solo questo ;-)

posted @ 05/08/2016 9.44 by Mauro Servienti

Sincero fastidio…

…per l’incapacità del dev di immedesimarsi nei bisogni dell’utente. Sto generalizzando ovviamente.

Troppe volte mi ritrovo a chiedere il perché di certe scelte e troppe volte la risposta è: non lo so, mi piaceva così.

Mi spiegate a che diavolo serve?

Sinceramente, avete così bisogno di soddisfare il vostro ego personale da introdurre una valanga di problemi? Perché ovviamente ogni volta che “consegniamo” qualcosa che nessuno ci ha chiesto poi dobbiamo fare manutenzione, dobbiamo fissare bug perché ovviamente qualcuno userà quel qualcosa come non abbiamo previsto, dobbiamo decidere come deprecare la cosa quando questa ci scoppierà in mano…

Cosa c’è di così difficile?

Nel decidere di dare priorità ad una cosa per il problema che risolve e non per la cazzutaggine della soluzione ingegneristica con cui il problema viene risolto, problema che spesso in questo secondo scenario non esiste proprio.

Spiegatemelo, perché io sinceramente non riesco a capacitarmi della cosa.

posted @ 03/08/2016 11.26 by Mauro Servienti

Backlog e reminder

Sempre il buon Nazareno:

domanda: reminder diciamo che è una sorta di backlog con una data a in cui guardarci... e dopo che ci hai guardato? Insomma hai un calendario delle cose da fare nei prossimi giorni? Perchè questo non c'è nella tua definizione di calendario qui sopra... o sbaglio?

Come dicevo uso principalmente i reminder di Google Inbox, ma poco importa il tool secondo me. Diciamo che quando penso al concetto di reminder mi vengono in mente le seguenti possibilità:

  1. Voglio ricordarmi un’idea o di qualcosa che prima o poi dovrò fare o prendere in considerazione: Reminder di Google Inbox, tipicamente lo creo o lo pianifico (Snooze) immediatamente al giorno in cui so che vorrò guardarci; faccio la stessa cosa con le mail a seguito delle quali devo fare un’azione
  2. Mi viene in mente e lo devo fare oggi o è correlato a qualcosa che devo fare oggi, se sono davanti all’agendina finisce li sopra altrimenti reminder di Google Inbox senza snooze, quando sono davanti all’agendina trascrivo ed elimino il reminder nella Inbox
  3. Devo pianificare qualcosa che richiede tempo e concentrazione e ha pure una scadenza, come ad esempio preparare una sessione per una conferenza: alloco del tempo nel calendario, qui lo scopo è sapere che sarò libero, principalmente da meeting
  4. Ci sono scadenze che sono molto distanti nel tempo e che magari richiedono più di un passaggio per essere portate a termine, uso il rinnovo della patente come esempio: Wunderlist, in cui posso dire entro quando deve per forza essere fatto e quando voglio essere avvisto, ad esempio 45 giorni prima
    1. Quando scatta l’avviso pianifico i vari step, ad esempio prenoto e segno la visita medica
    2. mi segno sull’agendina di fare le foto nuove
    3. etc…
    4. Quando tutto è completato spunto la roba in Wunderlist e se serve ripianifico la scadenza successiva

Mi sono perso qualcosa per strada?

posted @ 02/08/2016 13.35 by Mauro Servienti

“Get things done”: le mie prime due fasi.

Nazareno chiede:

Una domanda rispetto l’agendina delle attività: Ma tu ci scrivi solo le attività della giornata o tutte le attività in backlog e poi spunti e quello non fatto passa al giorno dopo?

C’è una logica di prioritizzazione delle cose? O questo va su altri “strumenti”?

Insomma è una sorta di “cose da fare” come nella tecnica del pomodoro ma senza pomodori o un backlog sempre in divenire o un mix?

Getting things done” è una tecnica arcinota che io non uso assolutamente :-) Il Pomodoro è altrettanto una tecnica arcinota che io non uso più.

Come dicevo la disciplina è fondamentale, ma anche il conforto personale è fondamentale.

La prima fase

All’inizio segnavo sull’agenda, o qualsiasi tool di gestione delle cose da fare vi venga in mente, tutto quello che dovevo fare in ambito lavorativo. Tutto significa tutto, quindi non solo quello che dovevo fare oggi ma anche quello che sapevo già che prima o poi era da fare.

Ecco, così non funziona: arrivate a sera che avete smarcato poche cose, siete comunque stressati, non siete andati in palestra e non avete scritto questo post.

La seconda fase, quella attuale

Ho quattro principali strumenti di pianificazione:

  • Il calendario: tipicamente ci sono solo i meeting e le cose personali come andare dal parrucchiere
  • Wunderlist: tutte le attività, tipicamente personali, ricorrenti che hanno una scadenza, come ad esempio ricordarsi del bollo auto
  • I reminder di Google Inbox: tutto ciò che mi passa per la testa che deve essere prima o poi fatto. Creo un reminder e lo pianifico al volo in una data/ora in cui so che potrò guardarci con calma
  • L’agenda: il mio programma di oggi

Il programma di oggi

Questa è la cosa fondamentale: scope. La pagina dell’agenda è quello che voglio fare oggi, e contiene tutto quello che voglio fare oggi compresa la piscina e questo post sul blog. Più che quello che voglio fare è un elenco di composto da due macro categorie:

  • Quello che devo per forza fare
  • Quello che voglio fare

L’elenco ha una caratteristica: è sostenibile. Col tempo sono diventato abbastanza bravo e riesco a spuntare quasi sempre tra il 90% e il 95% delle attività quello che non spunto finisce sulla pagina del giorno dopo.

Disciplina

La prima cosa alla mattina, molti consigliano di farlo la sera prima, è redigere l’elenco; passo quindi in rassegna i quattro strumenti di cui sopra e trascrivo tutto sulla pagina di oggi. Perché trascrivo tutto? Perché voglio arrivare a sera e avere un solo posto in cui guardare e vedere cosa ho fatto ed essere soddisfatto.

Man mano che la giornata avanza, se esce qualcosa di nuovo che non è pianificabile nei giorni a venire, lo scrivo sulla pagina di oggi e ci provo. Siccome il centro della giornata sono io l’elenco contiene anche tutte le cose personali come la piscina, la palestra o qualcosa che devo fare con la famiglia.

C’è un altro interessante vantaggio di questo modello, in cui per certi vedersi potete paragonare la pagina di oggi ad una rudimentale board con le attività. La vostra lista di cose da fare è un ottimo modo per gestire le emergenze altrui, senza una chiara visione su quello che voi volete ottenere oggi è facilissimo dire si a qualsiasi cosa sia un’urgenza per qualcun altro, con l’ovvio e spiacevole effetto collaterale che la vostra giornata diventa un disastro. Ovvio che questa disciplina comporta anche difendersi dagli scocciatori seriali.

Le domande

Tornando quindi alle domande:

Una domanda rispetto l’agendina delle attività: Ma tu ci scrivi solo le attività della giornata o tutte le attività in backlog e poi spunti e quello non fatto passa al giorno dopo?

Solo la giornata, quello che alla sera non è spuntato finisce al giorno dopo, dopo un po’ti stufi di riscriverlo e lo fai :-)

C’è una logica di prioritizzazione delle cose? O questo va su altri “strumenti”?

Nessuno strumento per la pianificazione, nessuna prioritizzazione, non voglio essere raffinato e non voglio perdere tempo per esserlo motivo per cui carta e penna; non voglio essere schiavo di app che non fanno quello che voglio o di batterie che si scaricano.

Insomma è una sorta di “cose da fare” come nella tecnica del pomodoro ma senza pomodori o un backlog sempre in divenire o un mix?

È la lista di cose da fare senza come nella tecnica del pomodoro ma senza pomodori e senza le regole della tecnica del pomodoro. Semplice lista nuda e cruda.

Evolverà in una terza fase? perché no :-)

posted @ 01/08/2016 8.53 by Mauro Servienti

“il senso di colpa”

“anche oggi ho fatto” solleva un’interessante problema, evidenziato anche da Roberto nei commenti:

Però sono anche interessato ai risultato lungo termine per cercare di capire se per me potrebbe andare bene, in quest'ultimo post che hai scritto, stanno uscendo fuori un pò di considerazioni che trovo molto interessanti... "il senso di colpa", sarebbe un argomento bello da approffondire, professionalemnte ti conosco e credo che tu sia una persona molto brava, precisa e preparata , ma se anche tu "vivi" a volte questa sensazione (che non è facile da placcare), potrebbe significare che questo modo di lavorare potrebbe incentivare questi aspetti ?.

Quando vivete senza manager il senso di colpa (e non solo) sono spettri sempre in agguato, pronti a rovinarvi la giornata. Un manager, anche nella sua accezione negativa agisce per certi versi da chioccia creando una sorta di alone protettivo. Può essere quello che in maniera autoritaria, e quindi negativa, prende decisioni per voi e impone il da farsi, ma anche in questo caso elimina il problema del senso di colpa o del sentirsi spaesati, un po’ pesci fuor d’acqua.

In una realtà collettiva senza manager non volete assolutamente che l’anarchia e il senso di non-appartenenza prendano il sopravvento. Quali strumenti quindi per eliminare o se non altro controllare il “senso di colpa” prima che si imbocchi una strada senza ritorno?

  • Il primo e forse più importante è il tuo mentor ti permette di “mettere in fila le cose”, di ragionare a mente fredda su quello che fai, succede, subisci: è la tua chioccia personale che però (cosa molto importante) non è il tuo capo;
  • Il secondo è essere mentor di più di una persona: ti permette di avere il polso della situazione, di capire al volo che qualcosa a qualcuno sta sfuggendo di mano e intervenire di conseguenza (cercheremo di capire cosa vuol dire intervenire);
  • Il terzo è sapere che vivi e lavori in un ambiente fatto di maturità e responsabilità, in cui tutti sono pronti ad intervenire per il bene comune perché sono guidati da una mission e da un insieme di valori
  • Ambiente in cui sai che può sbagliare perché non lavori mai da solo
  • Infine c’è il processo di feedback, di cui parleremo tra un po’

Tutte queste belle cose, filosofeggianti forse ma molto concrete se applicate, e tanti piccoli accorgimenti come la mia agendina e tanta disciplina, fanno si che il “senso di colpa” non sia più un problema.

Mi permetto di darvi un piccolo schiaffo

Se leggendo avete detto: si tutto bello…ma…noi…no…perché…certo…ma voi…

BALLE e SCUSE non vi portano da nessuna parte

I cambiamenti sono difficili, quelli radicali lo sono ancora di più, ma stare seduti nel proprio inferno personale a piagnucolare non fi farà di certo cambiare. Bisogna voler cambiare, questo è il primo e fondamentale passo.

posted @ 29/07/2016 11.17 by Mauro Servienti

Services UI Composition: recap

Al compleanno di UGI parlando di “Services UI Composition” ho sottolineato un dettaglio che a pensarci bene è di una banalità disarmante, banalità che a volte è meglio ripetersi un paio di volte di troppo al fine di evitare fantasmagorici castelli di carta, o come dicono i francesi “seghe mentali” :-)

In DDD esiste il concetto di Ownership, in SOA esiste il concetto di Ownership, quando si parla di sistemi di messaggistica, Command e Pub/Sub, esiste il concetto di Ownership. Quando si parla di UI? silenzio…

In realtà se ci pensiamo bene ogni volta che la UI fa un’azione quell’azione è responsabilità in primis di qualcuno e solo in seguito alla reazione dell’owner altri attori possono reagire e contribuire. Questo è vero anche per le letture: voglio l’elenco degli ordini. Vado da chi gestisce gli ordini, mi faccio dare l’elenco e poi lo arricchisco con le informazioni che mi servono.

Ovviamente immediatamente tutti abbiamo, me compreso, pensato: voglio l’elenco degli ordini per i clienti che vivono in questa regione e che hanno acquistato il prodotto xyz negli ultimi 6 mesi. Sono due use case radicalmente diversi e il secondo nello specifico probabilmente è una questione di “reporting”, ma è un’altra storia, ci arriveremo.

Tornando a noi: Ownership

Questo è il principio alla base di tutto quello che abbiamo detto fino ad oggi quando abbiamo parlato di “Services UI Composition”, di seguito un breve riepilogo dei post:

Se vogliamo possiamo visualizzare quello di cui abbiamo discusso fino ad ora nel seguente modo:

image

I vari “Actor” si registrano in base al compito che vogliono svolgere, nell’esempio di cui sopra Marketing è l’owner della query mentre gli altri reagiscono all’evento che notifica che la richiesta inziale è stata esaudita e fanno il loro lavoro per arricchire il modello e renderlo un “Composed ViewModel” che la UI sia poi in grado di visualizzare.

OK, tutto bello direte voi, e come abbiamo già detto un esempio lo trovate qui: https://github.com/mauroservienti/Services-UI-Composition

E le scritture?

To be continued…

posted @ 27/07/2016 12.56 by Mauro Servienti

Http performance in browsers (+Angular2)

Prendendo spunto da ultime attività lavorative, vorrei evidenziare (molti lo sapranno) come il numero di chiamate http parallele eseguite da un browser (browser != istanza di browser) verso lo stesso server (stesso dominio) sia in numero finito e ridotto, e che la cosa possa peggiorare la performance del vostro applicativo web [http://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser].

Partiamo cronologicamente al contrario:

1 - Angular2

Angular2 è la nuova versione del framework di google, scritta in typescript, ed "enormemente" modulare; basti pensare che:

  • ogni "view" può essere composta dalla definizione di “component" scritto in typescript (=> js), un css e un html ad esso collegato. Questi possono essere embeddati nel file typescript, ma personalmente preferisco tenerli separati.
  • angular promuove la modularizzazione, anche per questioni di performance dovute a shadow dom, change detecion stragegy.. (http://blog.thoughtram.io/angular/2016/02/22/angular-2-change-detection-explained.html)
  • l’accoppiata di dependency injection di ng2 e l’import di moduli esterni con ES2015 è una __FIGATA PAZZESCA__. Ed ora si scrive molto più C#-like (interfacce, classi, ereditarietà ... il tutto per il single responsibility principle).

Bene. Ottimo. Fantastico:

many_requests

Il problema è semplice (e di facile risoluzione). Ci sono troppi file da caricare (650+) e… ogni browser può effettuare un massimo di connessioni verso lo stesso dominio (chrome per esempio un massimo di 6).
Tutte le chiamate http vengono dispacciate da questo numero limitato di connessioni, il che rende lungo (9+ secondi) il caricamento dell’applicativo (insieme ovviamente all’elevato numero di handshake).

Soluzione semplice: BUILD (fatelo ‘sempre’ e, soprattutto, pensateci in tempo)

Ad oggi vi sono numerosi strumenti per effettuare la build di un’applicativo web javascript (grunt, gulp, broccoli, webpack…), personalmente mi sto affezionando a webpack, con il seguente risultato:

low_requests

Perfetto. Numero di richieste ridotte al minimo, quantità di dati ridotta, tempi di caricamento abbassati.

2 – Data recomposition

Un altro applicativo web a cui ho/sto lavorando, molto dinamico, permette ad ogni utente di comporre la sua UI in base alle proprie preferenze.
L’utente può decidere

  • quanti grafici aggiungere alla pagina
  • per ogni grafico, quante serie mostrare.

A complicare le cose, i grafici vengono aggiornati in realtime.
Per rendere il tutto il più modulare e indipendente possibile, abbiamo architetturato l’applicativo in modo da recuperare ogni serie con una chiamata http separata. Massima flessibilità ma… alcuni dati:

  • In media (a spanne) un utente apre 2-4 grafici per pagina
  • ogni grafico ha 6 -12 serie scelte dall’utente
  • un utente può aprire apre anche più tab con la stessa applicazione (anche 2 o 3 per pc) su diversi monitor (ok, il contesto è un pò particolare)

Risultato:

  • una connessione utilizzata da signalR (SSE) per tab aperto
  • Le chiamate http, anche se su server è stata implementata una cache abbastanza intelligente, possono richiedere tempo per essere evase. Il tempo di risposta occupa la connessione, non permettendo ad altre serie di essere recuperate velocemente da parte del browser.
  • E’ anche capitato (numero eccessivo di tab aperti) che un tab smettesse di recuperare dati da server finché l’utente non ne chiudesse un’altro.

Soluzione: dipende. Come sempre non c’è una verità. Ci stiamo spostando verso la definizione di “view model” che incapsulino più serie, in modo tale da raggruppare e quindi recuperare più serie in un unica chiamata http. Parrebbe inoltre che i websocket non utilizzi connessioni http (https://samsaffron.com/archive/2015/12/29/websockets-caution-required). Altre idee sono ben accette.

I sistemi software sono complicati, e la conoscenza è oro.

posted @ 26/07/2016 0.10 by Roberto Sarati

Mentor (was: Sempre al lavoro)

Prendo spunto dal commento di Roberto ad un precedente post:

image

Ci sono delle domande molto importanti li in mezzo, e di certo non sono io la persona giusta per dare risposte:

Essere sempre a lavoro anche non fisicamente, potrebbe essere a lungo termine deleterio?

Il non separare gli spazi mentali ma anche fisici a lungo andare potrebbe essere più dannoso o faticoso?

La risposta breve è si e si, quella lunga è disciplina e disciplina. Non c’è la formula magica, volevo scrivere questo post stamattina alle 8, sono le 12.15 e non ho ancora finito, è successo di tutto nel frattempo. La disciplina che mi impongo (a volte con molta fatica) mi sta facendo scrivere questo post e mi farà andare in piscina a breve, altrimenti non ci andrò, non scriverò questo post e la giornata finirà con molta insoddisfazione.

La questione è molto semplice: diamoci delle regole, rispettiamole e facciamo si che anche gli altri le rispettino.

Patti chiari amicizia lunga, alla prima volta che non rispettate voi stessi (e lasciare che qualcuno violi le vostre regole è a sua volta non rispettare voi stessi) è finita. È come decidere di smettere di fumare e poi dopo un paio di settimane dire…ma si… una che vuoi che sia.

Rispetto.

Per esempio io quando ho una giornata storta a lavoro a volte sfogo a casa (sbagliando) a volte scarico le brutte sensazioni e mi riempio di quelle belle con famiglia e figlioletto, in un mondo life-working come si potrebbero gestire i risultati delle quotidianità che questo approccio porta?

Qui la questione è più complessa, e ha risvolti psicologici più importanti.

Mentor

In azienda abbiamo un programma apposito, ognuno può scegliere un mentor, io ad esempio faccio da mentor a tre colleghi e ho il mio mentor. Il mentor è la persona da cui vai a sfogarti, quella con cui parli dei problemi (lavorativi e non) che ti affliggono. La persona che fa da specchio il cui ruolo è essere un amico in grado di dirti stai facendo una cazzata. Il mio mentor è quello che fa che non porti i miei problemi lavorativi o le frustrazioni fuori a cena con mia moglie.

Questo mi permette di chiacchierare si con mia moglie di problemi e frustrazioni ma senza scaricarli sulla famiglia.

posted @ 25/07/2016 12.25 by Mauro Servienti

Web scraping e raccolta di dati on line: alcuni chiarimenti da parte del Garante

Probabilmente molti la conoscono con nomi diversi, web-scraping, web-harvesting o web data extraction, ma la sostanza è, essenzialmente, la stessa: è l’attività di raccolta di dati personali da pagine web liberamente accessibili.

In un mondo in cui ciò che conta, che ha valore, sono i dati degli “utenti-consumatori”, la raccolta di informazioni on line è un’attività ormai diffusissima, in particolare tra le società che svolgono attività di marketing e di analisi dei dati (ad es. business intelligence), che possono così lavorare su database notevolmente più grandi, su dati più ricchi, più aggiornati e, soprattutto, più facilmente reperibili rispetto al passato.

Purtroppo, però, non è tutto così facile come sembra. Ce l’ha ricordato il Garante Privacy con una recente comunicazione, passata colpevolmente in sordina, in cui l’Autorità ha chiarito quali sono i limiti (per il vero molto stringenti) entro i quali è possibile raccogliere in rete dati personali. La vicenda da cui prende spunto il Garante riguardava una società italiana rea di aver creato (e reso accessibile agli utenti del proprio sito) un vero e proprio elenco telefonico (contenente dati quali nome e cognome, indirizzo, recapito telefonico, numero di cellulare o indirizzo email) relativo a più di 12 milioni di soggetti. La raccolta dei dati veniva effettuata attraverso l’utilizzo di script automatici, senza che però fosse stato richiesto il consenso agli interessati o che questi ne fossero stati informati. Il Garante, intimando alla società l’interruzione dell’attività, ribadiva che la raccolta e il trattamento di dati su siti pubblici (social network compresi) deve essere effettuato sulla base di consenso libero, informato, specifico per ogni finalità che si intende perseguire e acquisito in via preventiva. I dati raccolti in violazione di questo chiaro principio, non solo espongo a sanzioni amministrative chi viola la normativa, ma non sono in alcun modo utilizzabili o cedibili e devono essere immediatamente cancellati.

Il diritto alla protezione dei dati personali, sancito dal Codice della Privacy, non tutela la riservatezza delle informazioni, ma garantisce a ciascun individuo il diritto ad avere un pieno ed effettivo controllo sui propri dati, prescindendo dalla loro natura pubblica o privata. L’attività di web-scraping, quindi, non è da considerarsi di per sé vietata, ma deve essere realizzata nel rispetto dei principi previsti dalla normativa: da un lato, per tutelare gli interessati e, dall’altro, per consentire a chi raccoglie i dati di disporne lecitamente, anche per finalità commerciali.

Andrea Palumbo

posted @ 22/07/2016 16.05 by Staff Lex101

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