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 - 31301
  • Articles - 310
  • Comments - 91886
  • Trackbacks - 239154

Bloggers (posts, last update)

Latest Posts

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: