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 - 31271
  • Articles - 310
  • Comments - 91070
  • Trackbacks - 239185

Bloggers (posts, last update)

Latest Posts

Messaggi e gestione degli errori: transient errors

MD1ihgJ

Non tutti gli errori nascono uguali. Abbiamo visto cosa sono i permanent error, ma non sono l’ unica forma possibile di errore.

Transient Error

Un problema tipico caratteristica dei sistemi distribuiti è la disponibilità ballerina delle risorse. I sistemi distribuiti mettono in luce molto rapidamente la così dette fallacies of distributed computing, è quindi cosa più che normale che il database, o una risorsa qualsiasi di cui abbiamo bisogno, anche la rete stessa, non sia disponibile nel momento in cui ne abbiamo bisogno.

Sempre tipico dei sistemi distribuiti è che se riproviamo poco dopo tutto fila liscio come ci aspettiamo perché la risorsa in questione è nuovamente disponibile.

Si parla in questo caso di errori transienti, che sono quindi quegli errori che si risolvono da soli “semplicemente” riprovando.

Responsabilità

In questa direzione è interessante notare come il modello di comunicazione scelto modifichi radicalmente responsabilità e conseguenze.

Il modello RPC impone che l’onere del riprovare sia carico del chiamante e qualsivoglia problema il destinatario abbia impatta di conseguenza anche il chiamante. Il modello asincrono basato sui messaggi e code sposta la responsabilità del riprovare sul destinatario, come è giusto che sia per certi versi. Inoltre eventuali problemi del destinatario non impatto diretto sul chiamante.

Ovviamente dobbiamo accettare che il modello di sviluppo sia asincrono e fire & forget.

Adesso che finalmente Ale ha bloggato posso tornare alla mia serie su Services UI Composition, ma prima un ultimo post sulla gestione degli errori di business ;-)

posted @ 20/01/2017 15.50 by Mauro Servienti

Un po’ di tutto tra App, Privacy e Big Data

Interrompo il mio letargo per segnalare che il 24 febbraio parteciperò alla giornata di formazione Join the Expert: App Day organizzata da UGIdotNET per parlare delle problematiche privacy legate allo sviluppo di app. Segnalo inoltre, per chi fosse interessato al tema, che su Mokabyte è uscito il mio secondo breve contributo sugli aspetti legali dei Big Data .

Andrea Palumbo

posted @ 19/01/2017 22.28 by Staff Lex101

Messaggi e gestione degli errori: permanent errors

20150326_095931_server_error_msg

Abbiamo detto che ci sono errori ed errori. Un permanent error, nel mondo della messaggistica, si verifica (tipicamente) quando un messaggio non può essere processato.

Spesso nel mondo della messaggistica si sente parlare anche di poison message, i due vanno a braccetto. Un poison message è una forma di permanent error.

OK, ma che cosa significa?

Significa ad esempio avere un messaggio in una coda di ingresso e il messaggio è malformato. Il fatto che il messaggio sia malformato comporta che la deserilizzazione fallisca ad ogni tentativo. Non è molto diverso da un documento di Word corrotto su disco, Word cerca di aprirlo, ma fallisce ogni tentativo.

E quindi?

Ovviamente un messaggio di questo genere non lo possiamo semplicemente lasciare nella coda, sarebbe un buon modo per fare Denial of Service. Un messaggio allo stesso tempo non può essere perso, ha quindi molto senso spostarlo in un altro storage persistente in modo da permettere intervento umano finalizzato, per esempio, a un tentativo di recupero.

Generalmente i trasporti hanno un concetto chiamato Dead Letter Queue (DLQ), il cui scopo è proprio permettere di fare persistenza in maniera permanente se servisse die poison message. Una DLQ è quindi una coda come tutte le altre con un compito ben preciso: conservare i messaggi che non possono essere processati.

Ma non tutti gli errori nascono uguali

Oltre alle DLQ i sistemi di messaggistica si appoggiano anche alle così dette code di errore. che hanno uno scopo leggermente diverso.

Alla prossima :-)

posted @ 18/01/2017 7.27 by Mauro Servienti

Opera Neon : the future of web browsers ?

https://www.opera.com/it/computer/neon

posted @ 16/01/2017 17.02 by Alessandro Gervasoni

…e se i messaggi falliscono?

3415590901_b3fb25fcca_b

Abbiamo già detto per cosa non ha senso usare un messaggio. Una cosa fondamentale da comprendere, se il vostro sistema è basato su messaggi e code, è i messaggi non possono essere persi. Perdere un messaggio equivale a corrompere il sistema.

Errori

Ci sono tre tipologie di errore:

  • permanent: un messaggio non può essere processato, ad esempio la deserializzazione fallisce;
  • transient: un messaggio può essere processato ma una risorsa necessaria non è disponibile, riprovare potrebbe essere la soluzione;
  • business: un messaggio può essere processato ma viola le regole di business;

Approfondiremo il cosa, il come e il perché, nei prossimi post.

posted @ 16/01/2017 11.05 by Mauro Servienti

I primi candidati sono stati selezionati… con un piccolo rimpianto.

Dovrei aver risposto a tutti (accettati e non), se non siete stati ricontattati fatemi un ping.

Ho tenuto uno slot libero, visto che magari qualcuno non ha visto il post/tweet durante le feste… ma bisogna veramente meritarselo!!!

Cercherò di tenervi aggiornati sull’andamento dell’esperimento di mentoring a distanza, sicuramente condividendo i miei punti di vista (in forma completamente anonima e previa approvazione delle persone coinvolte Smile), e se loro vorranno, anche i punti di vista di chi parte per quest’avventura insieme a me.

Il rimpianto, non tanto piccolo in effetti, è che al momento non si è candidata neanche una donna. Ma non dispero di poter colmare il gap nel prossimo futuro. Dopotutto non è vera crescita se non ci si confronta con persone che hanno prospettive molto diverse dalle nostre.

posted @ 06/01/2017 11.03 by Lorenzo Barbieri

Il linguaggio è importante.

Alessandro Melchiori da qualche settimana millanta che avrebbe scritto dei post inerenti all’argomento Services UI Composition, ecco millanta :-D

Forza Ale pubblica qualcosa!

Per cercare di smuovere ancora un po’ le acque sto preparando una nuova sessione che al momento è così definita:

Tutti i nostri aggregati sono sbagliati

Inizia sempre tutto bene, il requisito è semplice e l'implementazione procede senza intoppi. Poi i requisiti aumentano e ci ritroviamo con una strana sensazione allo stomaco e con la necessità di introdurre alchimie tecnologiche che non ci piacciono, ma non sappiamo perché.

Prenderemo una funzionalità tanto semplice, quanto usata, come il carrello di un e-commerce e proveremo a capire se è veramente così semplice. Guarderemo il problema tecnico che volgiamo risolvere e poi sposteremo l'attenzione sui requisiti di business. Requisiti che una volta compresi a fondo ci porteranno a capire quali sono le vere responsabilità del dominio.

Diciamo che il primo obiettivo è stimolare il solito Melchiori a scrivere, il secondo è più nobile e parte dal seguente snippet di codice:

var order = repository.GetById<OrderAggregate>( 44 );
order.Ship();
repository.CommitChanges();

Non vi suona male?

Provate a leggere in italiano quello che c’è scritto li, io leggo:

Archivio dammi l’ordine 44, ordine 44 spedisciti.

Quel design secondo me è conseguenza di un errore. L’errore di fondo è che pensiamo prima al problema tecnologico e poi forse a quello di design.

Diciamocela tutta: un ordine non si spedisce da solo.

Quando ci hanno detto Data & Behavior la & ci ha fatto sbombare il parser e ci siamo fermati a Data, un po’come i famosi hack dei CSS per far digerire a IE robe che non digeriva :-)

Inoltre quel design, dal punto di vista SOA, comporta un altro problema: mischia le carte in tavola in termini di responsabilità. Supponendo che un ordine sia in grado di spedirsi da solo, al fine di poterlo fare dovrebbe:

  • sapere dove spedirsi e a chi
  • sapere come spedirsi

Entrambe le cose non credo siano di competenza dell’ordine.

Obiettivo della sessione sarà proprio spingere l’acceleratore su come SOA disegna il modello di dominio.

posted @ 06/01/2017 10.28 by Mauro Servienti

Aurelia e ASP.NET Core: binding di base in Aurelia

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core.

Al termine del post precedente ci eravamo lasciati con la necessità di idratare la nostra View con i dati provenienti dal ViewModel utilizzando un meccanismo detto binding. Vediamo quindi quali strumenti Aurelia ci mette a disposizione per gestire questa operazione.

Attribute binding, event binding e string interpolation

Riprendiamo quindi il nostro template e vediamo in che modo dobbiamo modificarlo per aggiungere la sintassi relativa al binding caratteristica di Aurelia:

Cominciamo da title (1) e master (2) per i quali utilizzeremo la string interpolation. Come suggerisce il nome, si tratta di una sintassi particolarmente utile nelle situazioni in cui si voglia usare testo dinamico proveniente dal ViewModel eventualmente insieme a testo statico inserito direttamente nella View. Non sorprenderà che Aurelia gestisca questo scenario facendo riferimento agli standard ES2015 per la string interpolation, cioè con la sintassi ${expression} in cui expression è una qualsiasi espressione JavaScript. Ad esempio <div>static text ${game.description} more static text </div> per inserire il valore della proprietà description in un div intercalandolo con del testo statico. Nel nostro caso avremo quindi:

Passiamo al button per unirsi ad una partita (3) e al link per partecipare ad una sessione di gioco (4). In questo caso abbiamo due problemi da risolvere: dobbiamo rendere visibili i due elementi a seconda del valore delle proprietà canJoin e canPlay, e dobbiamo eseguire il metodo join in seguito al click sul button. Per risolverli useremo le altre due sintassi previste da Aurelia, attribute ed event binding, più un'altra particolarità estremamente flessibile e potente di Aurelia: i custom attribute.

L'attribute binding è caratterizzato dalla sintassi attribute.command="expression". Dato un qualunque attributo (attribute), è possibile valorizzarlo con in risultato di un'espressione JavaScript (expression) attraverso l'applicazione di uno tra i comandi supportati (command). Approfondiremo il concetto dei comandi (che servono per definire direzione e frequenza degli aggiornamenti) in un prossimo post, per ora accontentiamoci di usare il comando generico bind che determina in maniera intelligente il tipo di comando specifico da applicare (con una modalità detta binding adattativo che è caratteristica di Aurelia). Potremmo ad esempio scrivere <a href.bind="game.url">Vai alla partita</a>. per utilizzare il contenuto della proprietà url come destinazione del link Vai alla partita.

Nel nostro caso abbiamo però un altro problema. In HTML5 non esiste (ovviamente) un attributo specifico che specifichi se vogliamo includere o meno un certo elemento nel DOM della pagina. Essendo una questione centrale in un'applicazione SPA, ogni framework che si rispetti ha dovuto affrontarla e risolverla. Invece di inventare una sintassi proprietaria (e magari astrusa) come per altri framework, Aurelia cerca come al solito di rimanere il più possibile aderente alle specifiche HTML5 e mette a disposizione degli attributi custom con cui poter decorare gli elementi del DOM per ottenere comportamenti personalizzati. Non solo Aurelia è fornito di alcuni custom attribute out-of-the-box, ma ci mette a disposizione l'architettura per poterne definire a nostra volta con una semplicità disarmante. Per oggi però non affronteremo questo tema ma ci limiteremo ad usare due di questi attributi builtin. Il primo è l'if è serve appunto a discriminare la presenza o meno di un elemento nel DOM a seconda dell'espressione utilizzata nel bind. In breve <div if.bind="expression"> rende il div parte della pagina o meno a seconda del risultato di expression.

Risolto il problema della visibilità, passiamo all'esecuzione del metodo join. In questo caso di tratta di reagire ad un evento del DOM per invocare un metodo del ViewModel. Per questo scenario Aurelia mette a disposizione l'event binding.

L'event binding sfrutta la stessa sintassi dell'attribute binding per consentirci di intercettare gli eventi che vengono lanciati dagli elementi del DOM. Le uniche differenze sono nei comandi supportati (trigger e delegate per l'event binding) e nella proprietà speciale $event che può essere usata nell'espressione JavaScript per ottenere un riferimento al DOM event originale. Anche in questo caso rimandiamo l'approfondimento dei due comandi, utilizzando al momento il delegate in maniera del tutto fideistica. Ad esempio <button click.delegate="run()">Esegui</button> per eseguire il metodo run in risposta al click sul button Esegui. Nel nostro caso quindi:

L'ultima cosa che ci resta da fare per completare la "tile" della partita è colorare il panel di verde o di rosso. Si tratta in questo caso di aggiungere il class panel-success o quello panel-danger al div che definisce la "tile" (cioè quello con class panel). Per farlo useremo ancora una volta la string interpolation utilizzando in questo caso un'espressione:

Ora che il frammento di HTML che descrive la partita è completo, non ci resta che iterare tutti gli elementi che compongono il nostro array e clonare il frammento iniettandolo di volta in volta nel DOM. Come già detto nel caso della visibilità, HTML non fornisce ovviamente un supporto nativo per questo scenario; non esiste quindi un attributo o un tag specifico per gestire questa operazione. Ecco che arriva in nostro soccorso il secondo custom attribute cui facevo riferimento in precedenza. Si tratta del repeat.for, per mezzo del quale possiamo indicare al framework una collezione su cui vogliamo iterare usando (manco a dirlo) la sintassi standard di ES2015 per il comando for, ossia item of collection. Aurelia prende automaticamente l'elemento del DOM su cui abbiamo apposto l'attributo come template per i vari elementi della lista e si occupa di clonare e iniettare nel DOM l'HTML risultante. In definitiva:

Non ci resta che il button che determina la creazione di una nuova partita. Anche in questo caso possiamo usare l'event binding scrivendo:

Prima di poter eseguire il nostro codice c'è un'altra operazione che dobbiamo portare a termine. Nello screenshot del post precedente abbiamo visto che ho utilizzato Bootstrap per migliorare un po' (nei limiti imposti dalla mia incompetenza di grafico) il look dell'applicazione. In primis dobbiamo quindi importare il relativo package da JSPM seguendo la procedura già descritta per i package di Aurelia. Fatto ciò dobbiamo fare in modo che il css di Bootstrap sia caricato insieme alla nostra applicazione. Possiamo ottenere questo risultato in tre modi:

  1. Aggiungendo un tag link che punti al css nella pagina principale index.html in modo che sia caricato non appena atterriamo sull'entry point della nostra applicazione:
  2. Usando un tag require che punti al css all'interno della nostra View app.html in modo da comunicare ad Aurelia (e quindi a JSPM) che abbiamo bisogno di quel file e che deve essere dinamicamente caricato (se non è già stato fatto):
  3. Specificando il css come risorsa globale durante la configurazione di Aurelia:

Trattandosi di una risorsa non specifica della View, ma piuttosto necessaria a livello di intera applicazione, la soluzione ideale sarebbe la terza (in realtà ci sarebbe anche una quarta opzione ma non facciamo confusione al momento). Visto però che non abbiamo ancora approfondito la configurazione, andrò per ora con la seconda soluzione.

Ed ora, F5 e via!

Prima di concludere voglio spendere due parole sul frammento di HTML che abbiamo usato come template della partita. Abbiamo visto in un post precedente che ogni View in Aurelia è un template HTML5 introdotto dall'apposito tag template. Nulla ci vieta, e anzi in alcuni casi prossimamente useremo proprio questo approccio, di estrarre il div che descrive la partita in un file esterno, strutturato a sua volta come template HTML5 (cioè incorporato in un tag template). A questo punto possiamo istruire Aurelia ad usare quel template per popolare la parte di pagina relativa alla partita, potendo allo stesso tempo riusare lo stesso file in altre pagine in cui abbiamo bisogno della stessa UI (con un meccanismo in parte simile a quello delle partial view di MVC). Questo meccanismo è detto in Aurelia composition e, come vedremo in un prossimo post, consente di comporre la propria pagina con un alto grado di flessibilità.

Happy coding!

P.S. Il codice sorgente è disponibile su GitHub, basta scaricare la release con lo stesso nome del post (Binding di base in questo caso).

posted @ 05/01/2017 13.27 by Giorgio Di Nardo

Coraggio, dove siete?

Dopo aver pubblicato ieri il post Cerco sempre nuove opportunità di crescita… aiutatemi! ho ricevuto varie risposte, alcune molto “ermetiche”, altre molto “efficaci”, alcune dettagliate, altre con offerte che non posso rifiutare Smile, non sarà facile scegliere…

Però… c’è un però… Tutte le “candidature” sono arrivate da persone che conosco già molto bene, che ho frequentato, che appartengono ad una cerchia abbastanza ristretta.

Mi chiedo se l’idea di un meeting regolare una volta al mese in cui crescere insieme su temi legati a delle soft-skill fondamentali interessi solo a persone che già frequento perchè:

- mi circondo solo di persone molto simili a me…

- chi non mi ha già frequentato non pensa di ottenere nulla di utile…

- incuto timore alle persone (questa me l’hanno già detta in tanti, ma non sono cattivo, è che mi disegnano così… Smile)

- pensate di non aver nulla da offrire…

- veramente non ve ne frega nulla del tema… proponete qualcosa voi Thumbs up

- varie ed eventuali (come ogni buona lista deve includere quest’ultima frase Smile)

Beh… se pensate di non aver nulla da offrire, ricredetevi… ho bisogno di conoscere prospettive nuove, di parlare con gente nuova, di confrontarmi con idee nuove e diverse dalle mie, magari anche solo perchè parlate bene inglese e quindi, possiamo conversare nella lingua di Albione Smile

Cosa aspettate… la mail è sempre geniodelmale chiocciola outlook punto com… non mordo… prometto!!!

p.s. ricordo che non accetto candidature nei commenti, su twitter o facebook, solo mail con indicato chi siete, cosa vorreste approfondire e perché dovrei scegliervi. Grazie mille!

posted @ 05/01/2017 11.48 by Lorenzo Barbieri

Nuovo Ask Me Anything con il team di GetLatestVersion il 31 gennaio.

Il 31 Gennaio 2017 GetLatestVersion organizza un nuovo AMA (Ask Me Anything) online. Per chi non lo sapesse l'AMA è un appuntamento in cui chiunque può partecipare e chiedere quello che si vuole sull'argomento in discussione ed il team di GLV cercherà :) di rispondere.

L'argomento come sempre è ALM su piattaforma TFS/VSTS, metodologie Agili e DevOps.

Potete registrarvi a questo indirizzo http://bit.ly/2hPgjgc

Vi aspettiamo.

Il Team di GetLatestVersion

posted @ 05/01/2017 9.32 by Gian Maria Ricci

Un messaggio non è per…

Quando si parla di messaggi, intesi come messaggi su una coda, c’è una cosa molto importante da comprendere:

I messaggi sono sempre e solo one-way, fire & forget.

A prescindere dal pattern di alto livello che stiamo usando, sia esso pub/sub o request/response, il mittente parla con una coda, il destinatario parla a sua volta con una coda, ma mittente e destinatario non sanno nulla l’uno dell’altro.

Two Generals' Problem

Questa puntualizzazione è molto importante perché introduce il noto problema dei due generali. Che in soldoni ci dice che il mettente non ha nessun modo di sapere con certezza se il messaggio sia stato consegnato al destinatario. Non esiste un concetto di ACK da parte dell’infrastruttura, e se anche lo inventiamo, sarebbe a sua volta un messaggio che a sua volta potrebbe non arrivare.

Perché vi sto dicendo tutto ciò?

Perché mi capita spesso, troppo spesso, di vedere cose del tipo:

queue.Send( message );
locker.Lock( message.id );

locker.Lock crea e usa un manual reset event, a questo punto questo thread è a tutti gli effetti congelato. E da qualche altra parte:

var message = queue.Deque();
locker.Unlock( message.id );

O, forse peggio, cose come:

var message = new QueryCustomers()
{
   Filter = ….
};
queue.Send( message );
locker.Lock( message.id );

Vengono quindi usati messaggi e una coda per leggere informazioni, a tutti gli effetti eseguire query. Oppure come nel primo caso vogliamo a tutti i costi metterci una coda ma non siamo disposti a ripensare il processo per essere totalmente asincrono, e ci inventiamo pastrocchi tecnologici per mimare un approccio procedurale.

Due ordini di problemi

Il problema dei due generali ci dice chiaro e tondo che potremmo aspettare a vita. Il destinatario potrebbe essere giù, o fallire nel processare il messaggio e spostarlo in una coda di errore, di fatto non rispondendo mai.

Il secondo problema, tipico dell’usare messaggi per leggere informazioni, è derivante dall’infrastruttura e dal concetto di quota. Come ci dicono chiaramente le 8 fallacies of distributed computing la latenza non è zero e la banda non è infinita, ergo i trasporti devono proteggersi dalle cazzate degli sviluppatori e impongono limiti, spesso molto stringenti, sulle dimensioni dei messaggi. Ne consegue che aspettarsi di poter ritornare i risultati di una query non è cosa buona e giusta.

Concludendo

Non usate request/response, e in generale una coda e messaggi, per leggere informazioni. Ci hanno dato HTTP, e tanti altri bei trasporti e protocolli  per farci qualche cosa, usateli :)

Lo scopo di messaggi su una coda è altro: è inviare comandi e notificare variazioni di stato pubblicando eventi.

posted @ 05/01/2017 7.16 by Mauro Servienti

GenFu

GenFu is a library you can use to generate realistic test data.

link

posted @ 04/01/2017 21.09 by Alessandro Gervasoni

Accedere a siti su IIS Express dall’esterno

Come sapete non è possibile, salvo configurazioni un pò macchinose, accedere a siti ospitati su IIS Express dall'esterno (altri PC\VM\dispositivi). Esiste tuttavia un modo molto più semplice, che richiede l’installazione di un proxy via NPM npm install -g iisexpress-proxy Una volta installato, basta eseguire il comando iisexpress-proxy 51123 to 3000 Dove
  • 51123 è la porta IIS a cui il sito è raggiungibile (che è dinamica)
  • 3000 è la porta al quale il sito risponderà all’esterno, usando l’ip della scheda di rete primaria.
Se l’ip del mio PC è 192.168.230.126, Il sito sarà ora raggiungibile dall’esterno all’indirizzo: http://192.168.230.126:3000 Su GitHub trovate i dettagli del progetto.

posted @ 04/01/2017 16.40 by Martino Bordin

Cerco sempre nuove opportunità di crescita… aiutatemi!

I product team di Microsoft hanno un modo di dire “eating your own dog food”, che in parole povere vuol dire “usa i software che stai creando fin da subito” per capire se ci sono problemi, per migliorarli, etc… etc… Da li il termine “dogfooding” che indica i programmi di beta interni per i colleghi.

In questo periodo sto cercando di crescere molto sulle tematiche del public speaking, del coaching (sono ai primi passi), della creatività, del professional networking, etc...

Ho deciso di provare ad applicare il dogfooding a quello che sto facendo, per cui pensavo di dedicare un’ora al mese (per il tempo che serve) ad una persona che abbia questi stessi interessi, una specie di mentorship reciproca via Skype, un’opportunità per applicare quello che sto preparando, ma soprattutto per crescere entrambi.

Vi interessa? Mandatemi una mail a geniodelmale chiocciola outlook punto com, indicando in poche righe chi siete (se non ci conosciamo), perché dovrei scegliervi, su cosa volete crescere e cosa potete offrire nella discussione, che vi ricordo, deve essere di crescita reciproca.

Naturalmente non garantisco nulla, il feeling deve essere reciproco, per cui la cosa potrebbe terminare dopo alcuni tentativi, ma credo che potrebbe venir fuori qualcosa di interessante.

Non lasciatemi i vostri contatti e le vostre motivazioni qui, via twitter, facebook o altro, accetto solo mail.

p.s. un’ora al mese per persona, ma almeno per ora ho banda per più di una persona, per cui fatevi sotto, non abbiate paura!

 

p.p.s. alcuni di voi sono arrivati su questo post grazie ad alcune condivisioni su Facebook, Twitter e LinkedIn. Per chi non mi conosce sono Cloud Solution Architect di Microsoft, ex-evangelista, trainer, consulente e negli ultimi anni mi occupo tantissimo di argomenti legati al public speaking, alla creatività, alla creazione e alla divulgazione di presentazioni tecniche e non. I miei contatti sono: @_geniodelmale su twitter, Genio Del Male Fan Page su Facebook e questo è il mio profilo LinkedIn.

Qui trovate i video della serie “public speaking for geeks” che ho registrato sul sito Microsoft Channel 9.

posted @ 04/01/2017 16.29 by Lorenzo Barbieri

&what;

Discover your character

http://www.amp-what.com

posted @ 03/01/2017 14.58 by Alessandro Gervasoni

js-cookie

A simple, lightweight JavaScript API for handling browser cookies

https://github.com/js-cookie/js-cookie

posted @ 03/01/2017 12.41 by Alessandro Gervasoni

E anche quest’anno parte stampando yearplanner.xlsx

No, non ho intenzione di fare un post per ogni file che stamperò, è solo che questo è uno dei file più importanti di tutto l’anno.

image

In questo foglio segno i giorni in cui faccio almeno 30 minuti di attività fisica, indipendentemente che siano feriali o festivi. Mi segno le ferie e le trasferte (in cui faccio fatica a mantenere il proposito di fare attività costantemente), i giorni di malattia e altro, ma soprattutto lascio bianche le caselle in cui, per un motivo o per un altro, avrei potuto fare attività ma non l’ho fatta.

Questo mi ha aiutato tantissimo nei due anni passati, devo dire che il 2015 c’è stata molta più costanza, ma alla fine da fine marzo a metà dicembre 2016 sono stato abbastanza costante.

Potevo fare di meglio, CERTAMENTE, ed è quello il punto. Questo foglio non mi serve per vedere i fallimenti, mi serve per capire che ogni giorno è il giorno buono per fare iniziare una serie, dopotutto se nel 2015 sono riuscito a fare CENTO giorni consecutivi, posso rifarlo quando voglio. Non è facile. Ma si può fare.

Ho tanti amici e colleghi che fanno sport più o meno seriamente e mi stimolano molto a non lasciarmi andare, anche se loro probabilmente non lo sanno. Ma è questo foglio a ricordarmi tutti i giorni che c’è una casella bianca, e che tocca solo a me riempirla, possibilmente con una X e non con una scusa, più o meno importante (certo, prendere un aereo alle 6.30, girare tutto il giorno come una trottola e rientrare a mezzanotte è una scusa valida Smile).

Se siete arrivati fino a qui a leggere e siete “nativi digitali” vi chiederete perché non uso una delle varie app di tracking, con i suoi avvisi, i suoi grafici, etc… Uso anche Mi Fit in questo periodo, dopo aver usato Microsoft Health per una vita, ma l’app non mi motiva. La casella bianca si.

Una serie di caselle bianche ancora di più. Una riga intera, ancora di più. L’importante è sapere che ogni giorno si parte da capo, con la propria casella bianca che deve diventare una X.

Buon anno a tutti, e, se volete mantenere i buoni propositi che avete fatto, scriveteli, che siano sempre visibili e con voi. Fate in modo che diventino un automatismo, non uno sforzo.

posted @ 03/01/2017 11.23 by Lorenzo Barbieri

Solution mode, ovvero: quanto è importante comprendere il problema.

Questo va un po’ nella stessa direzione dell’ascoltare per rispondere.

  • Qualcuno racconta quello che per lui è un problema
  • L’interlocutore si mette immediatamente in modalità soluzione
  • …è tutto finito :)

Il mettersi in “modalità soluzione” comporta un problema interessante: non analizziamo il problema, diamo per scontato che quello che ci è stato raccontato sia il vero problema che deve essere risolto. Non sto parlando in nessun modo di malafede: chi racconta, racconta la sua visione del mondo e in quanto tale la sua verità, ma non sta scritto da nessuna parte che il punto di vista di chi racconta sia quello giusto, sia esaustivo, e soprattutto abbia preso in considerazione tutte le circostanze e possibilità.

È quindi essenziale dedicare tanto, ma veramente tanto, tempo a comprendere a fondo il problema prima di iniziare a pensare a una soluzione. Rischiamo di risolvere il problema sbagliato, o peggio risolviamo quello che non è un problema.

Quante volte mi capita di ascoltare tecnici che dicono una cosa del tipo:

Il processo (inteso come processo di business) che abbiamo implementato:

  1. Non può funzionare in nessun modo senza transazioni
  2. Non è possibile che i messaggi arrivino senza un ordine noto

Spesso quelle affermazioni nascondono un problema più profondo: il processo non è stato compreso a fondo e le alchimie tecnico/tecnologiche ne sono la conseguenza.

posted @ 03/01/2017 7.19 by Mauro Servienti

Aurelia e ASP.NET Core: fondamenti di binding

Questo post fa parte di una serie dedicata ad Aurelia e ASP.NET Core.

Se fino ad oggi abbiamo navigato sotto costa, è arrivato il momento di rompere gli indugi e puntare la prua al largo. Nel proseguo della nostra esplorazione dell'universo Aurelia proverò a costruire un'applicazione concreta, per evitare di cadere nel solito tranello delle presentazioni apparentemente perfette che poi crollano al primo caso reale. Io realizzerò un'applicazione per supportare on-line un gioco di ruolo, voi potete ovviamente seguire la stessa strada o realizzare qualcosa di diverso.

I requisiti della nostra applicazione

Prima di buttarci nel codice, devo necessariamente spendere due parole per chiarire il dominio applicativo: per chi non lo sapesse un gioco di ruolo è quello in cui una serie di giocatori si calano nella parte di personaggi immaginari e vivono le avventure (generalmente in stile fantasy) narrate da un altro giocatore, detto master, che rappresenta il deus ex-machina della storia. Nel mio caso sto parlando del GdR "originale", in cui i giocatori si riuniscono attorno ad un tavolo e il master racconta la storia e dipana le vicende. Si dà però il caso che nel frattempo i giocatori hanno messo su famiglia e non possono più vedersi con la facilità di prima. Urge quindi trasformare le sessioni reali in sessioni virtuali (su Skype) e urge un supporto informatico per tenere traccia dell'evoluzione dei personaggi (l'equivalente digitale della scheda cartacea).

Ora che abbiamo chiaro il contesto, vediamo quali sono i primi requisiti dell'applicazione:

  • Come ospite, voglio diventare membro della community per poter giocare;
  • Come membro, voglio autenticarmi per poter accedere ai miei dati e alle mie partite;
  • Come utente, voglio vedere la lista delle partite cui sto partecipando;
  • Come utente, voglio iniziare una nuova partita come master;
  • Come utente, voglio unirmi ad una partita in corso come giocatore.

Cominciare gli sviluppi dai primi due requisiti, oltre che essere tremendamente noioso, ci obbligherebbe ad un nuovo percorso teorico di studio delle modalità di autenticazione/autorizzazione di una SPA, tenendo anche conto che non ho alcuna intenzione di gestire registrazioni, nomi utenti e password ma voglio invece sfruttare i servizi offerti dai principali provider di autenticazione (Facebook, Google, Microsoft, …). Dato che vogliamo fermamente mettere un primo abbozzo dell'applicazione sotto l'albero di Natale, daremo i primi due requisiti per acquisiti e cominceremo a sviluppare dal terzo.

Per iniziare assumiamo quindi di avere un utente registrato ed autenticato che nella sua home page voglia: a) vedere la lista delle partite cui è coinvolto; b) dare inizio ad una nuova partita e c) unirsi ad una partita in corso.

Per quanto detto fino adesso, dovrebbe essere ormai chiaro che un'applicazione Aurelia si compone di due componenti: la View, che contiene il template grafico da utilizzare, e il ViewModel, che contiene i dati con cui idratare tale template per comporre la pagina finale. Un'ipotetica pagina di visualizzazione di un utente, ad esempio, avrà un certo template grafico (sempre uguale) che sarà poi riempito di volta in volta con i dati specifici del particolare utente.

Nel nostro caso, come prima cosa abbiamo quindi bisogno di un file JavaScript che conterrà le informazioni sulle partite, e di un file HTML che avrà lo scheletro della UI da far vedere all'utente. Abbiamo visto che per convenzione Aurelia carica una pagina che corrisponde alla coppia app.js/app.html. Non ci vogliamo ancora addentrare nei gorghi della configurazione, quindi per ora ci limiteremo a riusare gli stessi due file dell'esempio precedente, semplicemente aggiornandone il contenuto.

Il primo ViewModel

Se vogliamo mostrare un elenco di partite, un buon punto di partenza è avere un array contenente i dati delle stesse. In futuro tali dati arriveranno da una chiamata ad un apposito servizio ASP.NET Core, per il momento è più che sufficiente dichiarare un array hard-coded nel costruttore della classe che rappresenta il nostro ViewModel usando la sintassi ES2015:

Cominciamo con il descrivere una partita con un modello molto semplice che arricchiremo nel corso del tempo: Un identificativo univoco della partita (id), il nome della stessa (title), il nome del giocatore che svolge le funzioni di master (master) e due flag che ci dicono se possiamo unirci (canJoin) o se possiamo partecipare alla sessione di gioco corrente (canPlay).

Come vedete non c'è alcun obbligo di chiamare la classe con lo stesso nome del file (anche se è buona norma per i ViewModel per non generare confusione). Dato che già so che "a regime" la nostra coppia si chiamerà games.js/games.html, ho chiamato la classe direttamente Games.

Oltre ai dati sulle partite esistenti, per soddisfare gli ultimi due requisiti abbiamo bisogno dei due metodi per creare una nuova partita e per unirsi ad una partita esistente. Anche in questo caso ci limitiamo momentaneamente a due metodi fake con il solo scopo di verificare il funzionamento della pagina:

La prima View

Per capire come definire il template diamo prima un'occhiata al risultato finale che vogliamo ottenere:

Vogliamo quindi un panel bootstrap per ogni partita, il cui header sarà uguale al nome della partita (title) e il cui body riporterà il nome del master (master). Un button sempre nel body ci consentirà di unirsi alla partita (canJoin = true) o di accedere alla stessa (canPlay = true), mentre un altro button fuori dall'elenco permetterà di creare una nuova partita. Le partite "giocabili" saranno evidenziate in verde, le altre in rosso. Il frammento di HTML necessario ad ottenere il risultato di cui sopra (al netto delle informazioni sulle singole partite) è questo:

In questa porzione di HTML dobbiamo inserire il title (1) e il master (2). Dobbiamo inoltre fare in modo che il button (3) sia visibile solo se canJoin = true e che il suo click esegua il metodo join del ViewModel e che il link (4) sia invece visibile se canPlay = true. A seconda del valore di canPlay dobbiamo quindi aggiungere il class panel-success o quello panel-danger al panel (5). Tutto ciò va ovviamente ripetuto per ogni partita del nostro elenco duplicando l'intero div (6). Infine dobbiamo chiamare il metodo create del ViewModel al click sul button (7).

Cos'è il binding?

Il problema diventa quindi quale meccanismo utilizzare per gestire questo travaso di dati dal ViewModel alla View.

L'approccio più semplice è ovviamente dato da un'interazione "forte" tra le due parti. Il ViewModel conosce perfettamente la struttura della View ed è in grado di individuare le parti che devono essere idratate e di iniettare nelle stesse i valori presenti al suo interno (ad esempio utilizzando jQuery con una sintassi tipo $('#title').html(this.title). Questa operazione può essere tipicamente portata a termine al momento del caricamento, fornendo all'utente una pagina già completa di tutte le informazioni.

Le cose però si complicano quando dobbiamo gestire la visibilità di alcuni elementi o quando dobbiamo gestire una lista con la conseguente necessità di clonare e iniettare nuove porzioni di HTML. Ancor peggio quando il passaggio delle informazioni deve essere bidirezionale, quando cioè le informazioni aggiornate dall'utente sulla View devono essere ritrasmesse al ViewModel, tipicamente per dare avvio ad un processo di business o ad una semplice operazione di salvataggio delle stesse. Nasce infatti l'esigenza di individuare il momento in cui riportare le informazioni sul ViewModel, intercettando una serie di eventi sulla pagina (come il click sul pulsante di submit o la digitazione in un campo di input), e in breve tempo la gestione di questi scambi di dati può diventare molto complessa e tremendamente fragile per via dello stretto collegamento tra le due parti che costringe a tenere allineato il ViewModel ad ogni cambiamento della View.

Per ovviare a questa serie di problematiche, i framework che si basano sul pattern MVVM (come Aurelia) utilizzano un meccanismo detto binding. In cosa consiste? In parole povere si tratta di una sintassi specifica che consente di specificare all'interno della View i punti in cui è necessaria l'interazione con un corrispettivo elemento del ViewModel, che sia il valore di una proprietà che deve essere riportato sulla UI, un metodo che deve essere invocato al click di un pulsante o ancora un flag che determina la visibilità o meno di un elemento grafico. La sintassi è ovviamente riconosciuta dal framework che è quindi in grado di processare la View, individuare i punti di interazione e idratare la UI con i valori provenienti dal ViewModel. In aggiunta il framework si prende anche carico della successiva gestione della vita della View, intercettando gli eventi scatenati dall'interazione dell'utente, modificando il ViewModel e di riflesso aggiornando ulteriormente la View stessa. Tutto ciò potendo mantenere il ViewModel del tutto agnostico rispetto alla View.

Nel prossimo post vedremo quali strumenti Aurelia ci mette a disposizione per gestire il binding.

Merry coding and happy new year!

posted @ 01/01/2017 17.42 by Giorgio Di Nardo

Non ascoltare per rispondere

Ripete con me, almeno, una decina volte: Non ascoltare per rispondere.

Moltissime persone sono impazienti di dare una risposta, troppo impazienti. L’impazienza (spesso accompagnata dalla voglia di prevaricare) porta inevitabilmente a smettere di ascoltare chi parla. Ci concentriamo immediatamente sulla risposta, perdendo di vista quale è il verso scopo della conversazione:

Comprendere il punto di vista altrui.

Fate un favore a voi stessi, e al vostro interlocutore: ascoltate per comprendere, non per rispondere.

posted @ 30/12/2016 8.52 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