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 - 31305
  • Articles - 310
  • Comments - 92061
  • Trackbacks - 239154

Bloggers (posts, last update)

Latest Posts

Azure Chat Talk, Mercoledì 1 marzo a Milano

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

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

Ci vediamo li?

posted @ 27/02/2017 16.00 by Lorenzo Barbieri

Letter

Letter is a simple, highly customizable tool to create letters in your browser

https://github.com/bastianallgeier/letter

posted @ 27/02/2017 12.58 by Alessandro Gervasoni

“Azure Chat Talk” @ Microsoft

Mercoledì avrò il piacere di essere ospite nella nuova sede Microsoft come uno dei moderatori, insieme ad un bel gruppo di personaggi, della Azure Chat Talk, meetup in stile unconference organizzato da DotNetLobardia.

Lo scopo è molto semplice: una chiacchierata molto informale sul mondo Azure. Domande, risposte (speriamo) e tante discussioni. Gli argomenti possono spaziare dall’architettura a questioni tecniche molte di nicchia.

Venite attrezzati di domande, tante domande. Basta e avanza :-)

posted @ 27/02/2017 9.09 by Mauro Servienti

Semantic Versioning, cui prodest?

Quale è il vantaggio di adottare Semantic Versioning?

Abbiamo fatto una brevissima e del tutto non esaustiva introduzione a SemVer, ma la domanda è comunque valida.

Il cliente ha sempre ragione

Detto a cui siamo più o meno tutti, dalla nascita, assuefatti e che man mano cresciamo ci rendiamo conto di quanto sia deleterio.
Proverbi a parte, SemVer è solo ed esclusivamente un “favore” che state facendo al vostro cliente. A noi fornitori complica solo la vita ;-)

Perché si

I vantaggi per l’utilizzatore finale di una libreria sono notevoli perché garantire che tra la release 1.5.1 e la release 1.6.0 non ci sono breaking change rende l’adozione di nuove versioni un processo più semplice.

Il mondo Javascript è forse quello dove il problema è più sentito. Il vostro scopo è liberarvi dall’angoscia che l’aggiornamento delle dipendenze porta con se, tipicamente la domanda ricorrente è: chissà cosa si spacca a sto giro.

Perché inevitabilmente qualcosa si spaccherà e sapete già che sarà un’epopea capire cosa e soprattutto capire come metterlo a posto.

Se chi produce la libreria in questione segue SemVer questo diventa un problema minore:

image

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

Perché no

Detto perché ha molto senso rispettare SemVer, cerchiamo di capire dove stanno le magagne. Semplicemente una ed una sola magagna: rispettare SemVer è molto difficile.

Vi lascio con qualche esempio di subdola breaking change in C#:

Prima

Dopo

void Foo()

->

int Foo()

enum Bar{ Coffee, Tea }

->

enum Bar{ Coffee, Cappuccino, Tea }

void FooBar()

->

void FooBar( int arg: 10 )

Tralasciamo poi tutte le breaking change nel comportamento.

Cercheremo prossimamente di capire cosa, da produttori di una libreria, possiamo fare per semplificarci la vita, e quindi rendere migliore quella del nostro cliente.

posted @ 24/02/2017 9.43 by Mauro Servienti

Creare un’applicazione Aurelia con la dotnet CLI e i JavaScriptServices

Buone notizie per chi come me ha scelto Aurelia come framework di riferimento per scrivere Single Page Application. Un po' alla volta la creatura di Rob Eisenberg si sta ritagliando il suo spazio ed è ora un firstclass citizen nell'ultima versione della dotnet CLI, quella disponibile nella SDK 1.0 rc4 build 004771.

Per i pochi che si trovassero spaesati, stiamo parlando del tool a riga di comando (CommandLine Interface) che consente di eseguire tutte le operazioni legate alla generazione, esecuzione e pubblicazione di un applicativo basato su .NET Core.

È da qualche giorno disponibile una serie di pacchetti NuGet che estende i template di default della CLI consentendo di generare SPA basate sui principali framework presenti sul mercato. Accanto ad Angular e React fa bella mostra di sé anche il template per generare applicazioni basate su Aurelia. Vediamo cosa dobbiamo fare per utilizzarlo.

Come prima cosa dobbiamo assicurarci di avere installata la versione di SDK corrispondente alla build 004771 o superiore che potete eventualmente scaricare dal link precedente:

Dopo averlo installato, aprendo un prompt dei comandi e digitando dotnet --version dovreste ricevere l'indicazione 1.0.0-rc4-004771. A questo punto possiamo digitare dotnet new --help per verificare quali siano i template disponibili per la creazione di un nuovo progetto. Se avete appena installato la CLI potreste dover attendere un po'per il popolamento della cache locale:

Di base dovreste avere disponibili di seguenti template:

Per cui potremmo ad esempio digitare dotnet new web per creare una nuova applicazione ASP.NET Core vuota da usare come base per i nostri sviluppi.

Per installare i template dedicati alle applicazioni SPA dobbiamo invece digitare dotnet new --install Microsoft.AspNetCore.SpaTemplates::*:

Dopo aver installato un po' di package assortiti (nel mio caso 111) i nuovi template dovrebbero essere a vostra disposizione:

Proviamo subito a vedere "l'effetto che fa". Spostiamoci nella cartella dove vogliamo creare il progetto e digitiamo prima dotnet new aurelia e quindi dotnet restore. Il primo comando crea il progetto a partire dal template, il secondo effettua il restore dei due pacchetti NuGet utilizzati (NodeServices e SpaServices):

Il template contiene al suo interno il file di configurazione project.json che elenca tutti i pacchetti NPM necessari. Per ripristinarli è sufficiente digitare npm install dallo stesso prompt dei comandi. Dopo un po' di attesa abbiamo finalmente il nostro progetto pronto e possiamo lanciarlo con il comando dotnet run. Per default il progetto creato si mette in ascolto sulla porta 5000 ed è quindi sufficiente digitare http://localhost:5000 in un qualsiasi browser per navigarlo:

Ci sono alcune differenze da notare rispetto al progetto che sto portando avanti nella mia serie su Aurelia:

  • Il progetto generato dal template è per Visual Studio 2017. Come conseguenza il file di progetto xproj è stato sostituito dal file csproj e il file project.json è sparito. Per modificare il progetto potete quindi usare Visual Studio 2017, Visual Studio Code o ovviamente il vostro editor preferito. Il progetto è inoltre basato su ASP.NET Core 1.1 (invece che sull'1.0 come nella mia serie), ma questo è un aspetto che non al momento ha impatti e che affronteremo a breve anche noi;
  • Come si vede nello screenshot, il progetto così lanciato gira in ambiente di produzione, a differenza di quanto succede lanciando il progetto da dentro Visual Studio. Questo è dovuto al fatto che Visual Studio definisce per noi la variabile ASPNETCORE_ENVIRONMENT e la imposta al valore Development. Per ottenere lo stesso comportamento a riga di comando dobbiamo definire manualmente la stessa variabile, andando nell'apposita sezione del pannello di controllo o utilizzando il comando setx ASPNETCORE_ENVIRONMENT "Development" (in questo caso è necessario aprire un nuovo prompt dei comandi per "vedere" la nuova variabile);
  • Come avevamo avuto modo di dire, Aurelia supporta diversi package manager. Nella nostra serie stiamo usando JSPM mentre il progetto generato dal template per uniformità tra i vari framework utilizza invece Webpack. Il progetto include anche i concetti di bundling e minification che ancora non abbiamo affrontato nella serie, e potrebbe quindi essere un po' spiazzante il fatto di non trovare nella cartella wwwroot nessuno dei ViewModel e delle View che ci aspetteremmo di trovare (a dire il vero i file html mancano del tutto). Non è il momento di spiegare nel dettaglio il funzionamento di Webpack, in ogni caso se volete modificare il progetto i file che vi interessano si trovano nella cartella ClientApp;
  • Il progetto usa TypeScript invece che ES2015 per definire i ViewModel. Come vedrete se vi addentrerete tra i file, le differenze sono minime e si concretizzano soprattutto nella possibilità di tipizzare variabili e parametri. Se guardate in wwwroot vi accorgete che gli unici due file JavaScript (oltre a essere apparentemente incomprensibili) sono invece caratterizzati da una sintassi ES5. Questo è il risultato dell'uso del bundling di Webpack per ottimizzare prestazioni e compatibilità. Per capire meglio di cosa parlo provate a confrontare il tab Network dei Developer Tools (cioè l'F12) del vostro browser preferito: la differenza tra il numero di file caricati dal progetto della nostra serie e quelli di questo progetto vale più di mille parole (ma non disperate, ci arriveremo a suo tempo);
  • Il bundling di Webpack viene gestito attraverso un middleware ASP.NET Core dedicato che si trova nel package NuGet SpaServices referenziato nel progetto. Tale middleware è caricato nella pipeline di ASP.NET Core solo in ambiente di sviluppo ed è per questo che è fondamentale impostare la variabile ASPNETCORE_ENVIRONMENT come prima descritto. In caso contrario le vostre modifiche ai file presenti in ClientApp non sarebbero prese in considerazione da Webpack e i file in wwwroot rimarrebbero quelli originali
    ;
  • In teoria i JavaScriptServices supportano l'Hot Module Replacement ma in pratica, come si vede nello screenshot qui sopra, questa opzione è disabilitata nel template di Aurelia per via di un problema con il plugin che consente di fare funzionare il framework con Webpack. Intanto che il problema viene risolto cerchiamo di capire cosa ci stiamo perdendo: abbiamo detto in precedenza che, quando facciamo una modifica ai nostri file di progetto (html o js/ts), Webpack si occupa di aggiornare i file presenti in wwwroot che saranno poi quelli serviti al client. In un'applicazione SPA questo non è sufficiente per "vedere" la modifica nel browser. La coppia View/ViewModel è stata infatti già richiesta al server e da quel momento in poi il framework SPA la riutilizza per ridurre la necessità di effettuare richiesta al server. Per ottenere la vista modificata dobbiamo aggiornare l'intera pagina (in genere con F5, presupponendo di avere la cache del browser disabilitata) ma questo vuol dire ovviamente perdere completamente il contesto di esecuzione del nostro test, ritrovandosi con una nuova istanza applicativa. Ecco l'HMR vuole risolvere appunto questo problema, iniettando html e js aggiornati nella SPA senza perdere il contesto di esecuzione corrente.

Happy coding!

posted @ 24/02/2017 9.15 by Giorgio Di Nardo

GitBook e la documentazione

La documentazione di Radical è stata finalmente migrata dal Wiki di GitHub ad uno strumento pensato per gestire la documentazione: GitBook.

Il risultato è disponibile qui: https://docs.radicalframework.com/.
I sorgenti sono invece su GitHub: https://github.com/RadicalFx/documentation.

Perché migrare.

Tre motivi principali:

  1. Il Wiki di GitHub è molto limitato in termini di feature, struttura della documentazione stessa e gestione degli asset
  2. L’aspetto collaborativo tipico di un progetto open source è monco. Ad esempio non c’è supporto per le PR, limitando quindi di fatto la possibilità che la community partecipi
  3. Originariamente Radical era un singolo progetto in un singolo repository e il Wiki soddisfava le necessità del tempo. Il progetto è evoluto, adesso ha la sua Organization su GitHub e il codice è stato separato in diversi repository. A questo punto ci siamo trovati in una situazione alquanto scomoda perché il repository originale non conteneva più tutto il codice ma conteneva tutta la documentazione.

La decisione è stata quindi quella di trovare una soluzione che cercasse di risolvere tutti i problemi.

Requisiti

Abbiamo quindi posto alcuni paletti:

  • Il repository deve essere un repository di GitHub
  • Il formato della documentazione deve essere
    • markdown
    • il più indipendente possibile dal tool usato per pubblicare la documentazione stessa
  • Supporto per la ricerca
  • Supporto per ToC

Il primo tentativo è stato fatto costruendo una roba completamente custom con Jekyll ma la ricerca e la generazione della ToC sono una rogna, insormontabile la prima, e noiosissima la seconda soprattutto considerando le limitazioni imposte dall’hosting di Jekyll nelle GitHub Pages.

Il secondo tentativo è stato Read the Docs che al primo colpo ha funzionato bene, poi le build hanno cominciato a fallire senza motivo. Il problema è che far gira tutto in locale, come ad esempio si fa con Jekyll, è abbastanza rognoso su Windows e la difficoltà di debug era tale che ho pensato di cercare altro.

Benvenuto GitBook

Alla fine devo dire che nel complesso l’esperienza GitBook è buona:

  • La sorgente primaria delle informazioni è GitHub
  • Tutto il flusso di GitHub è rispettato. Quindi una eventuale PR al momento della merge avvia la build della documentazione, etc
  • il linguaggio è markdown senza nessuna estensione particolare
  • c’è il supporto per la ricerca e la generazione della ToC

Ci sono anche dei bonus come ad esempio il fatto che GitBook abbia un editor markdown online che funziona molto bene e abbia un concetto simile a quello delle PR ma orientato ai non dev e quindi la barriera d’ingresso è inferiore. GitBook fa anche tante altre cose, che al momento a noi non servono. Ma, mai dire mai.

posted @ 22/02/2017 13.44 by Mauro Servienti

NeDB : A Lightweight JavaScript Database


http://stackabuse.com/nedb-a-lightweight-javascript-database/

posted @ 22/02/2017 12.42 by Alessandro Gervasoni

Join the Expert: App Day lunedì 27 febbraio a Milano

Logo UGIdotNETLunedì prossimo ci sarà una giornata completamente dedicata allo sviluppo delle app multipiattaforma, dove si approfondiranno sia le tematiche “server”, partendo dalle basi come HTTP, il backend ASP.NET e l’utilizzo di Azure come piattaforma per la gestione di servizi come, notifiche, autenticazione, integrazione con servizi terzi, servizi cognitivi, integrazione con Office 365, etc…, siaa le tematiche “client” con argomenti come Xamarin, la progettazione di interfacce “inclusive” per tutti gli utenti, le interfacce “conversational” (ad esempio i bot), fino a coprire gli aspetti più sottovalutati, come ad esempio la privacy e le nuove normative europee.

Trovate qui tutte le informazioni, l’agenda dettagliata e il link di iscrizione. Il posto poi è comodissimo da raggiungere, attaccato alla stazione Centrale.

Sono molto contento di tornare a parlare in un evento UGIdotNET dopo la sessione che ho fatto quest’estate per il compleanno (sul Desktop Bridge) e la sessione ai Community Days di questo autunno. E di farlo in compagnia di tanti amici, che non vedo da un po’!

Naturalmente dopo l’evento ci sarà la cena… anche se non so ancora dove… che altro dire? Sbrigatevi, che i posti stanno finendo velocemente Smile

posted @ 21/02/2017 14.15 by Lorenzo Barbieri

Introduzione a Semantic Versioning (SemVer)

Semantic Versioning (SemVer) è un modello di gestione del versioning finalizzato a rendere esplicito, grazie al modo in cui il numero di versione di una dipendenza evolve, quale sarà l’impatto che il fruitore deve aspettarsi installando una nuova versione della dipendenza.

Non sto qui a raccontarvi i dettagli del funzionamento, semver.org descrive tutto molte bene e in maniera sufficientemente concisa da non poter addurre la lunghezza come scusa.

TL;DR;

Per farla breve se sviluppate un libreria non potete non adottare SemVer, è una questione di buon costume e di rispetto degli altri.

Quello che volete evitare come la peste è di trovarvi in situazioni inutilmente tediose in cui siete obbligati a fare debug di codice altrui per capire perché ad un vostro cliente si è spaccato tutto.

image

La mossa del client di RavenDB di spostare delle API pubbliche in una minor change è una breaking change bella e buona che se fosse stata documentata correttamente non avrebbe causato i problemi che ha causato.

Se ci pensate diventa ovvio che il problema maggio, oltre a dover rispettare SemVer che è decisamente complesso, è che dovete separare il concetto di release commerciale da quello di release tecnica. Ne parleremo.

Avete mai pensato di usare SemVer? Se l’avete scartato quali sono stati i motivi?

posted @ 20/02/2017 8.31 by Mauro Servienti

End-to-End Javascript Testing a DevOps@Work 2017

Sono ora disponibili slide (su docs.com) e demo (su GitHub) della sessione End-to-End Javascript Testing che ho presentato all'evento DevOps@Work 2017 di inizio febbraio.

Nel README, associato al repository sulla branch master, ci sono le istruzioni da seguire per far funzionare la demo. Potete navigare tra le tre branch per trovare il codice iniziale e quello delle due demo (la prima senza usare il pattern Page Object, la seconda usandolo).

Per qualsiasi problema non esitate a contattarmi via email o Twitter.

Colgo l'occasione per ringraziare tutti i partecipanti per l'attenzione e l'interesse che mi hanno dimostrato pur essendo a fine giornata. Come promesso ai tanti cui - vista l'ora tarda - non ho potuto dare risposta dopo la sessione, nelle prossime settimane affronterò qui sul blog alcuni dei temi che non abbiamo avuto modo di trattare nel corso della sessione.

Happy coding!

posted @ 18/02/2017 12.55 by Giorgio Di Nardo

Nuovo deploy per VSTS

Con la solita cadenza tri-settimanale ecco le release notes del nuovo sprint rilasciato su VSTS. La nuova funzionalità su cui mi voglio soffermare è il cambio di licenza / uso per i build agent. Tradizionalmente infatti VSTS permetteva di usare un agent on premise gratuitamente, e per ogni agent in più era necessario pagare un abbonamento mensile.

Con il nuovo update la situazione è cambiata, nella parte di amministrazione del vostro account è ora presente un menu dedicato alle Build and Release dove potete vedere le Resource Limits.

image

Di base avete solamente una free pipeline, il cui significato è discusso in questo articolo. Senza entrare nel dettaglio il concetto è che potete installare quanti agent volete, ma se avete una sola pipeline attiva, solamente una build o una release attiva possono coesistere contemporaneamente. Questo significa che anche se avete agent liberi, se una build è in corso le altre verranno accodate.

Questa situazione è molto più desiderabile rispetto alla gestione classica, perché in questo modo voi potete deployare quanti agent volete, senza doverli ogni volta attivare o disattivare, e lasciare che sia il sistema a gestire il throttling. Se vi rendete conto che una sola pipeline non vi basta, potete acquistarne altre, ma nel frattempo potete installare agent su linux, windows, mac senza dovere impazzire.

Gian Maria.

posted @ 18/02/2017 10.49 by Gian Maria Ricci

ServiceLocator: sei il male assoluto!

Sono sempre stato un gran fan e pure un po’ talebano di IoC e DI tant’è che già nel 2008 ne parlavo ampiamente ai Community Days con una sessione introduttiva su IoC e i vari pattern di contorno.

Ho sempre pensato che usare ServiceLocator equivalga ad andare in vacanza portandosi dietro tutta la casa, ma proprio tutti mobili compresi, come bagaglio. Neanche mia moglie che è un gran visir del bagaglio esagerato ci riesce.

Abbiamo costruito Radical con la convinzione che ServiceLocator non serva, e ci siamo riusciti senza fare pressoché nessun magheggio particolare.

Mi rendo conto che ci sono scenari, ben precisi, in cui IoC è un desiderata ma la piattoforma non aiuta, come ad esempio ASP.Net WebForms. Ma in tutti gli altri casi?

Secondo voi quali sono buone motivazioni per usare ServiceLocator?

posted @ 17/02/2017 19.51 by Mauro Servienti

Tutti i nostri aggregati sono sbagliati - @CodemotionIT Roma, marzo 2017

L’edizione romana del workshop “Microservices development deep dive” punta a rivoluzionare il vostro modo di pensare ad un aggregato, introducendo il concetto di componente autonomo.

Una delle cose che affronteremo nel dettaglio, con anche tante demo, è proprio cosa significa modellazione di dominio quando si parla di servizi e componenti per SOA. Se siete quindi curiosi di capire perché come abbiamo immaginato gli aggregati fino ad oggi non è detto che sia il sistema migliore questo è il workshop che fa per voi :-)

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

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

posted @ 16/02/2017 10.23 by Mauro Servienti

“Lo so che lo sai, ma lo fai?” (cit.)

KEEP CALM AND DO IT!Ho provato a cercare di chi è questa frase, ma non ho trovato nulla. Ma non importa.

So di essere un osso abbastanza duro per chi tiene dei corsi, perché tendo ad ascoltare attentamente (anche se a volte faccio anche altro in parallelo) ma sono poco incline agli esercizi. E forse questo è un difetto più grave di quello che ho sempre pensato. Soprattutto quando poi, dall’altra parte della barricata, sono abbastanza inflessibile con i partecipanti… Smile

Comunque, sto approfittando di questi cinque giorni di corso interno molto intensi per cercare di applicare molto di più quello che imparo nell’immediato, per cercare di fissarlo con un po’ di pratica.

Non è facile per uno come me, come non è facile per molti di quelli che partecipavano ai miei corsi. Ma alla fine paga.

Per cui si, lo faccio, o almeno ci provo! Open-mouthed smile

posted @ 16/02/2017 8.50 by Lorenzo Barbieri

Couchbase Lite for .NET

Couchbase Lite for .NET
This project is a port of the Couchbase Lite portable Java codebase, ported to C#. Couchbase Lite is a fully functional, on-device, lightweight, native, embedded JSON database. With Couchbase Lite, you have the full power of a Couchbase database locally on the device. You can create, update, delete, query, sync and much, much more.

posted @ 15/02/2017 19.20 by Alessandro Gervasoni

DDD Europe, alla ricerca di nuovi stimoli.

DDDEurope2017-436

Un paio di settimane fa sono stato ad Amsterdam per DDD Europe, non per mia scelta. La spinta ad andarci è stata l’opportunità di aiutare Udi durante il workshop su Microservices.

Per uno annoiato a morte dalla tecnologia trovare nuovi stimoli non è facile e la frizione ad accettare di stare lontano 5 giorni dalla famiglia è molto alta. L’opportunità era comunque ghiotta e la scelta finale è stata restare ad Amsterdam anche per i due giorni di conferenza, oltre ai due di workshop.

Così così.

Avere a che fare con uno annoiato è molto difficile, me ne rendo perfettamente conto. Nell’insieme la conferenza è stata interessante, diciamo che se avessi dovuto pagare mi sarei lamentato.

Ripeto è il mio punto di vista, quello di uno annoiato alla ricerca di nuovi stimoli.

Elenco qui di seguito cosa ho seguito e ci metto qualche considerazione in merito.

  • Microservices workshop: gli argomenti li conosco a menadito, ho partecipato alla preparazione di tutto il materiale, la cosa per me molto interessante è stato vedere Udi in azione per due giorni;
  • Let's be open about failure and learn from it: ma anche no. Potrei parlare per ore di tutto quello che c’era di sbagliato in quella sessione senza toccare minimamente i contenuti che si faceva molta fatica a scovare;
  • The Language of Actors: noiosa e molto (troppo) base come livello, mi aspettavo molto molto di più da un super famoso;
  • To DDD or not to DDD? What to do if your domain is boring?: alla prima esperienza, brava. Argomento mainstream ma ben trattato e molto ben esposto;
  • If (domain logic) then CQRS, or Saga?: fenomenale, non tanto per i contenuti che conosco molto bene e sento quasi tutti i giorni, piuttosto per la qualità dell’esposizione e della struttura della storia che ha raccontato;
  • Modelling with strangers: è un’iniziativa molto interessante, ho partecipato a 3 sessioni, di cui 2 molto stimolanti. In una delle due Balducci ha dato sfoggio delle sue capacità;
  • DDD patterns that were not in the book: teribbbile, sembrava di leggere un GoF scritto male;
  • Design Matters: senza capo ne coda;
  • La keynote di Eric Evans: non avevo mai avuto il piacere e direi che va bene così, alcuni spunti interessanti o poco più;

In generale nutro un profondo fastidio per le sessioni senza abstract, e in questo caso mancava persino per alcune keynote, il che a mio modo di vedere è più grave.
Aggiungo: se una keynote deve essere inspiring qui ne hanno toppate 3 su 4.

Non voglio essere frainteso, quindi ripeto: è un giudizio personale, influenzato dal fatto che sono perennemente annoiato e quindi svegliarmi dal torpore è molto difficile.

posted @ 15/02/2017 9.00 by Mauro Servienti

Imparare dai maestri: James Whittaker

James è uno dei miei maestri, leggo tutto quello che scrive, blog e libri, ha ispirato un sacco di cose che ho scritto e un sacco di sessioni che ho preparato, cerco di seguire tutte le sue sessioni che trovo online, e quando posso vado a vederlo di persona dopo essere rimasto letteralmente folgorato dalla sessione sul “growth mindset” che ha fatto l’anno scorso al TechReady a Seattle, la conferenza riservata ai soli tecnici Microsoft.

Finora l’ho sempre visto all’opera in sessioni di fronte a moltissime persone, ma oggi ho avuto l’occasione di vederlo all’opera in una classe di una cinquantina di persone, in cui mi sono letteralmente “intrufolato” Smile (sono quello in basso a destra nella foto presa da questo tweet), fortuna che ho sempre con me il “blue badge”!

“The Storyteller's Spellbook”, mai titolo fu più azzeccato, eravamo tutti ipnotizzati, ma credo fosse l’effetto di questo incantesimo

Un’esperienza che oserei definire “mistica”, un’ora e mezza sullo storytelling fatta di tante storie, alcune le conoscevo già, altre nuove, di interazione con il pubblico, di slide che mi hanno ispirato, di creatività, un po’ di “sana” autopromozione, il rapporto con il proprio lavoro “ufficiale”, l’importanza delle storie nella carriera di una persona.

Nonostante conoscessi molto bene il lavoro di James, devo dire che dal vivo è DECISAMENTE un’altra esperienza, l’interazione che ha avuto con la classe, tutta la classe, mi è stata d’ispirazione.

La differenza tra raccontare storie divertenti e raccontare barzellette, l’importanza di essere se stessi e di dire quello che si pensa, a costo di perdere follower, come mai ha lasciato Google per tornare in Microsoft, l’importanza di essere sempre pronti a raccontare la PROPRIA storia, per essere più credibili quando si parla del proprio lavoro, del proprio prodotto o della propria azienda.

Ecco, sull’ultimo punto devo lavorare ancora parecchio. Ma forse ero solo veramente emozionato. Ma questo non deve essere un limite, devo veramente fare in modo di averla sempre pronta, non si sa mai quando e dove servirà. E si che è una delle cose che James ripete continuamente e me l’ha pure ricordato Nicolò prima di arrivare Disappointed smile

Peccato che non ha potuto fare la sessione su “conquering the stage fright”, un tema che mi interessa molto Smile

Quest’estate ho fatto una scommessa con me stesso e l’ho persa, ma devo dire che oggi ho posto almeno in parte rimedio a quell’errore di valutazione.

Se volete vedere la “vecchia” versione della sessione chiamata “the art of storytelling” la trovate qui: