Sviluppo software .NET, WEB e Mobile

Novità dal mondo .NET

Tue, 05 Sep 2017 20:46:00 GMT

Nelle ultime settimane le novità in casa .NET sono state tante, a cominciare dall'importante rilascio delle specifiche .NET Standard 2.0 seguite da .NET Core 2.0, ASP.NET Core 2.0, EF 2.0 e quindi da Visual Studio 2017 Version 15.3 (nonché dell'altrettanto importante ReSharper 2017.2) e C# 7.1.

Le novità sono importanti perché segnano un punto di consolidamento del nuovo .NET che ora espande notevolmente il supporto alle API della versione classica nonché il supporto a piattaforme non Windows. Nel video di presentazione Scott Hunter descrive con alcuni collaborati tutte queste novità, disponibili in dettaglio sui vari blog istituzionali di Microsoft:

E' naturalmente necessario scaricare lo SDK per il Core 2.0, anche se si aggiorna all'ultima versione di Visual Studio 2017:

Hunter si ritiene soddisfatto per i risultati della standardizzazione del .NET e per la svolta open source: il numero di pull request è aumentato di anno in anno e la .NET Foundation è supportata tra gli altri da Samsung, Unity, RedHat, Google e Qualcomm. Interessante il lavoro di Samsung per il proprio sistema Tizen, il sistema linux-based utilizzato da tutta la gamma smart dei propri prodotti.

Il .NET Standard è un insieme standardizzata di API da implementare in grado di omogeneizzare le implementazioni .NET per qualsiasi piattaforma evitando future frammentazioni.

Una chiara descrizione di che cosa sia .NET Standard è disponibile nel post di Daniel Crabtree: con un'analogia si potrebbe sire che è l'interfaccia implementata sia da .NET Core sia da .NET Framework. L'obiettivo è unificare le diverse piattaforme .NET e superare la precedente soluzione delle Portable Class Libraries (che rappresentava un'intersezioen delle API e richiedeva la ricoipilazione per ogni piattaforma). Con la versione 2.0 abbiamo, come accennato, il Compatibility Mode: la possibilitò di richiamare da un progetti .NET Starndard librerie NET Framework, a patto che utilizzimno solo API convogliarte nello stanrdard .NET.

Come si può notare in Visual Studio è possibie creare librerie .NeT Starndard ma non applicazioni: in questo caso bisogno utilizzare una piattaforma specifica, come .NET Core o .NET Framework. Quindi per l'applicazione si utilizzerà l'ultima ver5sione disponibile mentre per le librerie si potrebber unsare la versione più vecchia (a patto che esponga tutte le API di cui si ha bisogno).

Librarie .NET Framework non dovrebbero essere più create a maneno che non richiedano AAPI non sandard, come WPF.

Ecco alcuni appunti relativi alle novità della versione 2 del .NET Core:

È la versione del .NET più veloce di sempre (a questo proposito Hunter cita l’esempio di Raygun che passando al .NET Core da Node.js ha potuto gestire 20000 richieste per secondo rispetto alle 1000 gestite in precedenza).
Quasi il doppio delle API rispetto alla versione classica, tra cui il supporto a XML, Serialization, Networking, IO e Threading.
Compatibilità con i pacchetti creati con versioni precedenti del .NET se le API utilizzate rientrano nel nuovo .NET Standard 2.0 (si tratta di circa il 70% dei pacchetti NuGet). L’introduzione del cosidetto Compatibility Shim permette quindi di utilizzare le liberarie .NET Framework, in aggiunta naturalmente alle librerie .NET Standard e PCL.
Packaging semplificato (per ASP.NET Core è possibile sostituire i pacchetti Microsoft.AspNetCore.* con Microsoft.AspNetCore.All: in fase di pubblicazione saranno inclusi solo i pacchetti effettivamente utilizzati).
Supporto a più distribuzioni Linux e in particolare partnership con RedHat per la distribuzione [RedHat Enterprise][redhatloves.net]. .NET Core 2.0 treats Linux as a single operating system. There is now a single Linux build (per chip architecture) that works on all Linux distros
Several important improvements were made to .NET Core support for Docker during the 2.0 project.

Ma quali sono i sistemi su cui la nuova versione .NET può girare? Windows Client, Windows Server, Windows IoT, Red Hat Enterprise Linux (Centos and Oracle Linux), Fedora, Debian, Ubuntu, openSUSE, Tizen e Mac OS X.

L’aggiornamenti di Visual Studio 2017 Version 15.3 è dedicato in parte ad aumentare il supporto al .NET Core ed ora è possibile create qualsiasi tipo di progetto Core (naturalmente rimane il supporto ai tool a linea di comando). L’aggiornamento include comunque delle novità anche sulle funzionalità di Visual Studio, con maggiori strumenti dedicati al refactoring (la cui mancanza era sopperita da estensioni esterne come ReSharper).

Recentemente sono inoltre usciti due service pack per Visual Studio (siamo alla versione 15.3.3) e soprattutto l’aggiornamento di ReSharper che finalmente supporta il nuovo .Net Core e le nuove funzionalità del C#.

Non poteva mancare una versione aggiornata nel .NET Framework classico, che è ora disponibile in versione 4.7.1:

Supporto al.NET Standard 2.0.
Miglioramenti al Visual Tree per le applicazioni WPF.
Vari miglioramenti alle performance e all’affidabilità.

Per quanto riguarda ASP.NET Core:

Più veloce: ad esempio le pagine cshtml (e le nuove Razor Page) vengono precompilate per default alla pubblicazione.
Razor Pages: costruite su MVC ma più pratiche perché concentrano in un’unica struttura le tre componenti del Model View Controller.
Supporto al C# 7.1 di Razor.
Vi sono più Template (dedicati a Angular e React per creare selle SPA con il .NET Core come back end e alle nuove Razor Pages).

Abbiamo poi Entity Framework 2.0 che, essendo basato sul Core, può essere usato ovunque il .NET Standard sia supportato. Queste alcune delle novità:

Table splitting
Global query filter
Scalar database function mapping
LINQ implementation improvements (alcuni comandi che venivano eseguiti lato client sono ora tradotti in SQL)
Performance imporovemtne (DbContext pooling e explicit compiled qeuires)
Supporto a EF.Functions.Like(xxx, "a%")
Global query filters: modelBuilder.Entity().HasQueryFilter(p => !p.IsDeleted);
String interpolation in raw SQL methods

La roadmap di EF è comunque lunga: ad esempio il GroupBy viene eseguito in memoria e non sul motore di database (l’alternativa è chiamare un FromSql con una query composta manualmente).

PS. Non essendoci un logo ufficiale per il .NET Core ho utilizzato quanto creato da un fan e disponibile in GitHub.

Windows: ripristinare il tipo di una cartella

Sun, 03 Sep 2017 21:47:00 GMT

Un semplice appunto per configurare/ripristinare il tipo di una cartella, ad esempio dopo che Windows decide che un insieme di file è prevalentemente multimediale e quindi ne cambia il modello in Musica (esponendo le colonne traccia, artista e album). Basta modificarne le proprietà.

Questo è il tipico aspetto di una cartella con file musicali (non a caso la cartella Musica), con le colonne traccia, album e artista in evidenza rispetto alle classiche Data, Tipo e Dimensione:

Purtroppo anche una cartella qualsiasi può presentare le stesse colonne se Windows decide, in base al contenuto, che contiene file multimediali.

Per ripristinare il layout è sufficiente aprire le Proprietà della cartella, andare sulla scheda Personalizza e quindi scegliere il tipo più appropriato:

Spero sia utile.

15 anni di .NET

Tue, 14 Feb 2017 23:26:00 GMT

La prima versione di .NET è stata rilasciata 15 anni fa, proprio come parte di Visual Studio .NET. Due strumenti che hanno rivoluzionato il mondo dello sviluppo, in particolare per chi come me proveniva da VB. Tanta la strada fatta: oggi .NET è un ecosistema che copre ogni ambito dello sviluppo software. Quindi, Happy 15th Birthday .NET!.

È indubbio che il .NET abbia fatto passi da gigante assieme agli strumenti e ai linguaggi che da quel progetto sono nati, come il C# o a librerie come LINQ, EF, WPF, WCF, WF…. Fino al .NET Core e l’obiettivo di essere cross-platform e open-source.

Tantissima strada ne ha fatta la piattaforma Visual Studio, approdata nel cloud e diventato uno strumento a 360 gradi con Team Foundation System prima e ora Visual Studio Team Services.

Non utilizzo più l’ecosistema Java da più di dieci anni e non so quanto il .NET debba a quel progetto e poco importa: l’importante è avere sempre più scelte e poter contare sul loro continuo evolversi. Proprio quest’anno dedicherò del tempo a F#, visto che apprezzo molto le pratiche funzionali che in parte ho adottato in C#.

Che dire: è passato tanto tempo e tanti sono stati gli scogli incontranti sulla via del .NET, ma alla fine posso sempre contare su ottimi strumenti. Strumenti che permettono di creare soluzioni di tutti i tipi e di scegliere la propria strada, seppur alle volte con qualche imprecazione.

Ma alla fine tutto si riduce in una manciata di istruzioni e molta disciplina.

“An Exception has been occurred…” in Visual Studio

Sat, 10 Dec 2016 10:45:00 GMT

Di seguito riporto un messaggio di errore che si può verificare in Visual studio semplicemente aprendo il menu contestuale su un progetto UWP. Il problema, all’apparenza inspiegabile, è dovuto ad un errore in una estensione SyncFusion che è sufficiente disabilitare.

Questo il messaggio un po’ laconico che si ottiene nell’IDE premendo ad esempio il tasto destro su un progetto Universal Windows Platform all’interno del Solution Explorer:

Il testo non è molto significativo, “An Exception has been occurred while getting the Visual Studio Framework version of the project”, e viene ripetuto diverse volte.

Per scovare la causa, grazie a tristi esperienze del passato, ho incominciato a disabilitare le estensioni attivate di recente e tra le prime ho scovato questa estensione della SyncFusion, apparentemente causa del problema:

Ho aperto la segnalazione alla SyncFusion che ricordo distribuisce la sua completa suite di controlli gratuitamente tramite una classica licenza Free Community License.

Le basi dell’OOP e i vasi di Pandora

Sat, 05 Nov 2016 08:22:49 GMT

Alle volte ci si ritrova a perdere molto tempo per implementare una funzionalità all’apparenza banale ma che se inserita in un codice privo di architettura può provocare diversi mal di pancia. È come aprire un vaso di Pandora: tutto e il contrario di tutto rendono ogni modifica instabile come quelle che l’hanno preceduta.

Se la prima regola è quella di evitare un frettoloso refactoring e dedicarsi all’urgenza, la seconda è quella di non fare la fine del gatto che si morde la coda. Prevenire è sempre meglio che curare. Ma come evitare queste spiacevoli e fin troppo frequenti situazioni?

Due sono le regole che potrebbero aiutare e che si possono applicare durante la ristrutturazione del codice (parlare di refactoring è alle volte troppo benevolo e ricorda pratiche di miglioramento del codice e non di sopravvivenza):

Evitare il più possibile l’uso di flag (i mitici interruttori che determinano una funzionalità piuttosto che un’altra, cari alla flag oriented programming e spesso suggeriti dal richiedente con quell’innocua espressione del tipo: “a me basta solo un flag”).
Evitare il più possibile i cicli e le condizioni: sono difficili da leggere, rendono il codice complesso e sono il luogo perfetto per la proliferazione di bug.

Stiamo quindi parlando dei costrutti su cui si basano la maggior parte degli applicativi e gli unici che vengono affrontati a scuola. If, switch, for, while traboccano anche dei testi più attuali di programmazione, ma in realtà dovrebbero essere usati con cautela perché la programmazione ad oggetti (OOP) offre alternative molto più flessibili e semplici.

Oltre ai tanti principi e ai tanti pattern di cui ho in parte discusso in altri articoli, possiamo semplicemente partite dalla base di tutto: l’oggetto.

Un oggetto è un’entità definita da un tipo e che è in grado di incapsulare dati ed esporre proprietà e metodi. Questi membri lavorano direttamente sui dati dell’oggetto e quindi, rispetto alla programmazione procedurale, i dati sono legati alle operazioni e entrambi hanno un significato particolare proprio perché appartengono ad uno specifico tipo.

Il definire gli oggetti con i dati e le operazioni che devono viverci dentro è già un compito non banale, anche se il salto di qualità è pensare in modo più astratto e dinamico.

Comunque, sarebbe già un successo suddividere veramente in oggetti senza far diventare una classe una mera raccolta di procedure che col tempo diventano mastodontici vasi di Pandora.

Ma il vero vantaggio dell’OOP risiede nella possibilità di cambiare a runtime non solo l’oggetto in uso ma anche le sue operazioni: queste non sono staticamente fissate nel tempo ma possono essere determinate a runtime in base alle necessità (grazie al polimorfismo oppure tramite delegati).

È soprattutto un lavoro di concetto, di design: non basta avere un insieme di classi, che col tempo ingrassano diventano meri pezzi di codice procedurale, ma bisogna individuare la giusta forma delle entità e dei processi, entrambi rappresentabili da singole parti combinate a runtime.

Passando ad un esempio pratico e banale, diciamo di un applicativo in grado di avviarsi sia connesso ad un server sia in modalità stand-alone, trovare più volte i seguenti costrutti è sintomo di una lunga storia di smartellate:

if(session == null) { … } else { … }
if(IsOffline) session.DoThis(); else DoThat();
var appIcon = (session == null) ? Resources.ClientIcon : Resources.OfflineIcon;
if(session != null && session.IsLogged) { … }

Molto meglio creare un’astrazione sulla sessione. Una ISession con due implementazioni: una per la modalità client/server e una per la modalità offline. Quindi ISession esporrà l’icona corretta mentre DoThis e DoThat saranno lo stesso metodo ma implementato in modo differente. Un concetto abbastanza banale che se non affrontato per tempo può creare un pesante debito nel codice.

Il primo vantaggio dell’astrazione ISession è il non dover mai verificare se session è nullo. Un riferimento nullo è il male. Il secondo vantaggio è evitare continui blocchi condizionali. Il terzo è una semplificazione del codice e quindi della possibilità di completare un fix prima delle 18 di venerdì. Il quarto è che è semplice creare una nuova implementazione per affrontare nuovi requisiti senza toccare quanto già fatto.

Quelle condizioni viste poco più sopra possono (e lo fanno regolarmente) sfuggire di mano e moltiplicarsi senza controllo. Ad esempio, nel caricamento dei dati: in un caso tramite chiamata remota nell’altro con accesso ad una cache locale. Moltiplicate il tutto per un applicativo di medie dimensione e otterrete una buona metà di codice spazzatura.

Qualcuno potrebbe obiettare che nell’implementazione della ISession molti membri risulterebbero vuoti. Ma questo non significa che l’idea sia sbagliata: semplicemente la Session ha troppi compiti e deve essere suddivisa.

Si ritorna sempre al principio fondamentale di limitare la responsabilità di ogni oggetto e questo porta a dover utilizzare di volta in volta l’oggetto appropriato.

Con un codice mal strutturato va da sé che molta logica viene scaricata sul consumer e questo provoca delle duplicazioni irritanti. Il client non deve avere alcune responsabilità nell’uso del codice. Le responsabilità vanno nelle nostre classi.

I consigli sono sempre gli stessi: concentrarsi sugli oggetti, evitare i blocchi condizionali, evitare i cicli, nascondere i dettagli, usare oggetti immutabili. Attuare pratiche di defensive programming.

Modelli personalizzati in Word 2016

Fri, 04 Nov 2016 22:04:36 GMT

Word è uno strumento dalle mille funzionalità ma alle volte per usarle bisogna andarle proprio a scovare. Dopo un precedente post dedicato ai modelli ecco qui un’altra semplice tip: abilitare i modelli personalizzati in fase di creazione nuovo documento.

I modelli personalizzati si trovano in un’apposita cartella predefinita, più o meno con questo percorso (da modificare il nome dell’utente):

C:\Users\fulvio\AppData\Roaming\Microsoft\Templates

Qui si trovano ad esempio il modello Normal.dotm e gli altri modelli base per gli applicativi Office.

Anche copiando in questa posizione i propri modelli questi non verranno visualizzati nella pagina di creazione documento.

È necessario andare in Opzioni, nella scheda Salvataggio e indicare il percorso predefinito modelli personali:

Consiglio di utilizzare un percorso diverso da quello di default, magari una cartella su OneDrive per mantenere i modelli sincronizzati e al sicuro nel cloud.

Ecco apparire la scelta del tipo di modello nella pagina di creazione nuovo documento:

Buona scrittura!

VSO e le autorizzazioni sulle Aree

Tue, 24 Nov 2015 22:18:35 GMT

Visual Studio Online è uno strumento fantastico per organizzare il proprio lavoro e ad ogni aggiornamento offre piccole e grandi novità. Una di queste l’ho scoperta incontrando un problema banale: non riuscivo a gestire i miei item nel backlog.

In pratica potevo creare e vedere gli item nelle query, ma alcuni item non apparivano nel backlog e una volta assegnati manualmente ad una feature o epic non potevo riordinarli:

D’altronde il messaggio di VSO tramite tooltip è abbastanza chiaro: “This item cannot be reordered because it is owned by another team”. Ma quale altro team se ne ho definito solo uno?

Il problema riguarda l’autorizzazione sulle aree: non avevo abilitato il team corrente ad accedere alle sotto aree, semplicemente spuntandone il nome. Quindi gli item associati ad una certa area risultavano di competenza di qualcun altro (sebbene non definito).

Un semplice problema che mi ha fatto scoprire come VSO evidenzi graficamente il fatto che un elemento sia gestito da qualche altro team, utile per progetti grandi o articolati.

Elogio al TDD

Wed, 30 Sep 2015 21:01:20 GMT

Il TDD è una pratica molto affascinate perché permette agli sviluppatori, propensi più a scrivere codice che a valutarne gli effetti, di fare quello che preferiscono: scrivere codice, appunto. Il TDD coinvolge tanti concetti in un unico e continuo processo di sviluppo... Un'esplosione di creatività, insomma.

Avere sviluppatori che perdono tempo ad avviare un intero sistema per verificare anche la più piccola modifica ha un costo enorme e non sempre è possibile o sostenibile poter verificare un sistema utilizzando il lavoro dei tester. Inoltre, considerando un test manuale, è assai improbabile che possa coprire tutte le possibilità che un software mediamente complesso ha: di qui la necessità di creare test automatici, ripetibili e indipendenti, necessità che un bel po' di tempo fa ha portato all'idea delle Unit Test: codice ripetibile e automatizzabile per verificare il proprio software.

L'evoluzione di questa visione ha portato al Test Driven Development, che più che una pratica di testing è una metodologia di sviluppo, una pratica di design. Con design non si intende naturalmente la progettazione a 360° dell'applicazione e della sua architettura. Si intende il design di quella parte di codice necessario per soddisfare un insieme di requisiti, generalmente collegato ad una singola funzionalità ma non necessariamente: è possibile eseguire il design a partire da una visione di più alto livello e scendere via via nei dettagli delle singole classi.

Uno degli aspetti più interessanti del TDD è la possibilità di intervenire su un sistema senza aver paura di rompere il suo attuale stato. In pratica di avere a disposizione tutto un insieme di regression test che permette di aggiungere una nuova funzionalità senza comprometterne altre… e se i test esistenti falliscono si apre la necessità di un re-disegn di una parte del sistema per accogliere le nuove richieste. Il fatto di scoprirlo durante l’implementazione e non in produzione è notevole....

I regression test sono particolarmente utili durante il fixing degli errori: non è raro che il fix di un bug ne generi un altro. Situazione paradossale e tragica che il TDD allevia. Tra l’altro creando la UT per tracciare un bug e disegnare la sua risoluzione, permette di evitare spiacevoli ritorni.

Comunque, il TDD ha come scopo principale quello di guidare lo sviluppatore nella realizzazione del sistema, cercando di farlo concentrare su un singolo problema alla volta: spesso la smania del creare si protrae oltre al necessario.

Ciò che si ottiene, fin dalla prima release, è un software di alta qualità. Difficile che non abbia alcun tipo di problema e la perfezione come si dice non è di questo mondo. Ma dover spendere un intero ciclo di sviluppo per correggere la prima release è una procedura che dovrebbe appartenere al passato. La seconda release, come predicano le metodologie agili, dovrebbe portare miglioramenti e nuove funzionalità, inserite nel sistema senza compromettere l'esistente.

Siccome sono anni che sviluppo software conosco perfettamente la frustrazione di dover andare in produzione con codice abbozzato velocemente e conosco anche la frustrazione di dover correggere un errore già risolto in passato. Proprio per questo posso garantire che le più moderne metodologie di sviluppo possono fare la differenza e permettere agli sviluppatori di dedicarsi al miglioramento dell'applicazione, del processo di sviluppo e di se stessi.

Dimentichiamo quindi la consuetudine di sopravvivere: alle nuove richieste, agli inspiegabili errori e alla disorganizzazione. Il consiglio è seguire quelle pratiche, come il TDD, che tracciano un solco entro cui muoversi al riparo da consuetudini maligne.

Sempre dalla mia esperienza so che la documentazione relativa all'analisi, al progetto e all'implementazione sono una chimera e se dovessero mai esistere, nel senso di essere utili in qualche modo, allora è quasi certo che dopo un po' di tempo tale documentazione diventi obsoleta. Le vari forme di automatic testing permettono di creare una documentazione direttamente nei sorgenti: il semplice uso di nomi parlanti per le Unit Testing piuttosto che forme più evolute come il BDD e derivati, permettono di indicare chiaramente cosa ci si aspetti dal software. E siccome il cosa ci si aspetta può cambiare nel tempo, è probabile che la documentazione non cambi ma il codice sì e quindi, in presenza di Unit Test, anche le cosiddette specifiche integrate: si parla di documentazione viva, molto utile anche per metter mano a codice esistente scritto da altri o da passare ad altri.

Mi è già successo di dover metter mano a del codice difficile da comprendere... magari codice scritto proprio dal sottoscritto qualche anno prima. Il TDD allieva questi tipi di problemi, assieme all’applicazione dei principi SOLID, all’uso dei design pattern e al clean code in generale. In realtà, una delle forze del TDD è che la sua adozione porta necessariamente ad utilizzare tali tecniche, altrimenti risulta totalmente impraticabile: il TDD porta al cosiddetto well-crafted code, perché testare una classe che ha troppi compiti ed fortemente accoppiata con altre classi è improponibile.

Dimentico sempre di fare una puntualizzazione: nessuno scrive codice perfetto e anche quando si conoscono e si applicano tante utili nozioni bisogna scontrarsi con tanti fattori che possono dar vita a codice migliorabile. Succede. Il refacotring è proprio un processo che ben si sposa con il TDD, perché lo si può affrontare con sicurezza grazie ai regression test e applicando sempre la pratica first test: scrivo il test, modifico, verifico, miglioro.

Se poi si hanno la forza e la costanza di affiancare altre due tecniche importanti come le code review e il pair programming i risultati sono garantiti.

Refactoring Essentials: best practice in VS2015

Tue, 08 Sep 2015 21:40:00 GMT

Refactoring Essentials è un interessante Analyzer e Code Fixer per Visual Studio 2015 disponibile come estensione e, per il processo di build, come pacchetto NuGet. In arrivo la versione 2.0 con nuove regole e best practice.

Il progetto è nato alla fine del 2014 ma è ufficialmente disponibile dalla metà del 2015. Sviluppato dalla stessa community di SharpDevelop, NRefactory e ILSpy. E’ un ottimo strumento per analizzare e migliorare il proprio codice grazie ai suggerimenti e alle best practice include nell’analizzatore. Viene utilizzato ad esempio dal progetto xUnit.

E’ un progetto gratuito, open source e supporta sia il C# e VB.NET, anche se la maggior parte delle funzionalità è dedica al primo linguaggio (circa 200 regole). Ecco alcuni esempi di regole, approfonditi sul sito ufficiale:

L’estensione per Visual Studio integra l’analizzatore e le funzionalità di refactoring direttamente nell’IDE, mentre il pacchetto NuGet offre l’integrazione nel processo di build. Da notare che il cuore del progetto è comunque una PCL che può essere utilizzata su altre piattaforme (come avviene in MonoDevelop).

La versione 2.0 è alle porte con fix e miglioramenti vari, tra cui nuove regole per l’analizzatore C# e VB.NET.

Podcast per sviluppatori

Tue, 14 Jul 2015 23:38:00 GMT

Non sono mai stato un fan dei podcast tecnici ma ultimamente li ascolto spesso per sfruttare anche il tempo speso per i trasferimenti: sono utili compagni di viaggio per ottenere qualche spunto di riflessione e approfondimento. Tanti e famosi quelli in lingua inglese mentre in italiano possiamo vantare l'ottimo dotNET{podcast}.

Prima di vedere quelli più famosi a livello internazionale è doveroso citare dotNET{podcast}, l'utilissimo servizio gestito da Roberto Albano, Antonio Giglio e Massimo Bonanni. Sono arrivati da poco alla puntata numero 50 e gli argomenti trattati non toccano solo il mondo Microsoft/Windows/.NET ma anche argomenti come Acrhitettura, Startup, Agile, Database, Docker...

Lasciando l'Italia, ecco una lista dei Podcast più famosi:

Uno dei più famosi è certamente Hansel Minutes il cui motto è Fresh Air for Developers. Tante chiacchierate con ospiti di diverse competenze e gli argomenti spaziano da IoT ad Azure, passando dal mondo .NET. Interessantissima la puntata su Akka.NET.
Hallway Conversations: A Podcast by Developers for Developers recita il motto. Sebbene gli aggiornamenti non siano frequenti, gli argomenti sono interessanti e ben trattati. Per ogni puntata il sito riporta link e dettagli vari.
{CodingBlocks}.NET: argomenti di diverso genere dall'interviste di lavoro allo sviluppo web. Gli argomenti sono pratici ma non mancano panoramiche e discussioni generali. Ogni podcast è accompagnato da note e dettagli sul sito ufficiale.
Software Engineering Radio: molto meno pratico e più teorico, con panoramiche su design e metodologie di sviluppo. Link di supporto direttamente sul sito. Interessante la discussione con lo scopritore del teorema CAP.
.NET Rocks!: naturalmente dedicato al mondo .NET è aggiornato settimanalmente ed è uno dei più famosi. Informazioni e dettagli sul sito ufficiale.
MS Dev Show: podcast dedicato agli sviluppatori Microsoft. Tratta molti argomenti con ospiti famosi: Azure, Windows, Windows Phone, .NET, Visual Studio e framework vari. Anche in questo caso i dettagli degli argomenti trattati sono disponibili sul sito.
HerdingCode: trasmissione che può vantare tra gli ospiti Scott Allen, Kevin Dente, Scott Koon e Jon Galloway. Sul sito il dettaglio delle puntate con la scaletta al minuto degli argomenti trattati (molto comoda).

Una raccolta di questi e altri podcast è disponibile su The Sound Of .NET: è quindi possibile sottoscrivere il loro feed per ricevere in un colpo gli episodi da più fonti. Un altro aggregatore è Player.fm per la categoria Microsoft.

Naturalmente di sorgenti c'è sono parecchi e alcuni offrono agli sviluppatori tanti consigli e spunti senza essere troppo tecnici. Ad esempio, un’ottima risorsa per la categoria soft skills, è il podcast Simple Programmer curato da John Sonmex. Sempre Hanselman pubblica riflessioni generali sul suo This Developer’s Life.

Abstract Factory Pattern

Sat, 27 Jun 2015 12:12:15 GMT

Un importante pattern introdotto dalla Gang of Four per affrontare il problema della creazione degli oggetti è l’Abstract Factory Pattern. Il problema obbliga un client a conoscere a priori le classi che andrà a creare limitando l'estendibilità e creando un accoppiamento forte tra classi, soprattutto quando si parla di famiglie di oggetti.

Un buon esempio è disponibile su Wikipedia e considera un’applicazione portabile su più piattaforme, in cui verrà utilizzato un insieme di classi dedicate alla UI specifico per ogni sistema. Avrò quindi delle classi pulsante e link per Windows e altrettanti classi per OSX.

Il client che andrà ad utilizzare tali controlli non dovrebbe gestire la creazione delle classi controllo, altrimenti si legherebbe a n classi: l’insieme dei controlli moltiplicato per le piattaforme disponibili. Inoltre, all’aggiunta di nuove piattaforme sarebbe necessario modificare anche il client e tutti gli altri utilizzatori.

L'Abstract Factory, conosciuto anche col nome di Kit, offre una soluzione semplice ed efficiente, naturalmente grazie alle astrazioni. Stiamo parlando di un pattern creazionale in cui un insieme di factory viene astratto da un'unica interfaccia dando la possibilità al client di utilizzare la factory più corretta per la creazione di oggetti, nel nostro esempio una factory per ogni piattaforma. Si parla di famiglie di oggetti: ogni factory permette la creazione di oggetti in relazione tra loro.

Per garantire l’uso di più factory è necessario astrarre anche gli oggetti creati: i pulsanti saranno definiti da un’astrazione e i link da un’altra. Quindi la factory astratta esporrà due metodi per creare tali oggetti. Questo lo schema proposto da Wikipedia:

Il risultato è una netta separazione tra l'uso e la creazione degli oggetti. L’applicazione di questo pattern si rivela assai utile quando si vuole rendere un sistema indipendente dalle modalità di creazione, composizione e rappresentazione degli oggetti costituenti, rendendo note unicamente le interfacce e non le implementazioni concrete.

L'abstract factory viene usato ad esempio nella definizione di librerie: all'utilizzatore interessa una certa interfaccia non quale classe venga effettivamente creata. E la creazione può dipendere da diversi fattori. Nell’esempio precedente anche la creazione della factory può essere vincola da una configurazione o dallo stato dell’applicazione o dalla piattaforma in uso.

Diventa semplice creare ed inserire nell’applicazione una GUIFactory dedicata a Linux: il client richiede la factory e in modo del tutto trasparente verrà ritornata quella del sistema in uso. La definizione della GoF è abbasta chiara a proposito:

Fornire un’interfaccia per creare famiglie di oggetti in relazione o dipendenti tra loro, senza indicarne la classe concreta

Lo schema proposto da Wikipedia è una buona panoramica di questi concetti:

Abbiamo quindi i seguenti partecipanti:

L'AbstractFactory definisce una classe in grado di creare degli oggetti definiti tramite astrazione (AbstractProduct).
L'astrazione può essere implementata in varie classi concrete (ConcreteFactory)
Il client utilizza AbstracFactory per ottenere degli AbstractProduct.
La factory crea su richiesta un ConcreteProduct per soddisfare il client.

Dallo schema si nota che il client utilizza solo due gruppi di interfacce: AbstractFactory e AbstractProduct. Ad ogni AbstractProduct corrisponde di solito un metodo della classe factory, anche se è possibile applicare altri pattern per rendere ancor più estendibile la creazione.

Anche per questo pattern vengono applicati i principi OO di base: l'incapsulamento e il principio di programmazione verso l'interfaccia e non verso l'implementazione (perché per creare altri tipi di oggetti basta cambiare la factory, che generalmente è una singleton).

Un ulteriore vantaggio è quello di creare un insieme di oggetti in relazione e coerenti tra loro: se un insieme di oggetti forma una famiglia significa che sono stati studiati per lavorare tra loro, quindi una factory dovrebbe ritornare oggetti della stessa famiglia. Inoltre si centralizza la creazione di oggetti omogenei in un unico punto.

Lo svantaggio principale di questo approccio riguarda la modifica della factory: se devo aggiungere una nuova tipologia di Product allora dovrò modificare l’astrazione e tutte le classi derivate. L’insieme delle tipologie è infatti fisso e corrisponde generalmente ai metodi esposti dalla factory.

Ricapitolando vi sono diversi scenari tipici per l’utilizzo di tale pattern:

Il sistema necessità di essere indipendente dalle modalità di creazione degli oggetti che utilizza.
Il sistema lavora con più famiglie di prodotti.
I prodotto di una famiglia sono progettata per lavorare esclusivamente assieme.
E’ richiesta la creazione di un libraria di prodotti per la quale è rilevante solo l’interfaccia. Quindi l’implementazione è incapsulata.

Generalmente una factory viene creata come singleton per poter essere riutilizzata e, come visto nell’esempio precedente, la creazione potrebbe considerare la configurazione dell’applicazione o lo stato del sistema.

In fase di refactoring il pattern risulta utile per concentrare in un unico posto la creazione degli oggetti: si cerca quindi la presenza di new nelle varie classi per passare poi come dipendenza l’astrazione della factory e centralizzare la creazione degli oggetti. Tra l'altro questo è il tipico lavoro svolto da un Inversion Of Control Container (IoC).

Alcuni riferimenti:

Liberare spazio in Windows

Tue, 23 Jun 2015 21:25:00 GMT

Seppur nel loro insieme risultino ottimi prodotti, molti tablet di fascia medio-bassa sono dotati di dischi di piccole dimensioni e dopo poco tempo lo spazio inesorabilmente finisce. Tra i vari accorgimenti per risparmiare qualche megabyte vi è la pulizia della cartella degli aggiornamenti di Windows.

Il piccolo ma versatile Asus T-100TA in mio possesso ha sulla carta 32 GB di disco ma in realtà la partizione di rispristino è una ROM non cancellabile, il che fa scendere di ben 8 GB lo spazio realmente disponibile.

Poi ci sono il sistema operativo e Office, entrambi non particolarmente leggeri e basta installare qualche App particolarmente pesante e ci si ritrova con pochi megabyte a disposizione. E’ possibile espandere il disco con una memory card, ma non vi è un modo semplice e sicuro per installarvi le applicazioni se non quelle desktop.

In rete si trovano molti consigli per liberare spazio, ma in generale si tratta di piccoli accorgimenti: per provare a liberare molto spazio è possibile agire sulle cartelle utilizzate da Windows per l’installazione degli aggiornamenti.

Dopo alcuni mesi di utilizzo ho liberato circa 7 GB, ma la dimensione dipende dallo stato del proprio sistema e se si è eseguito l’aggiornamento da Windows 8 a Windows 8.1. La cartella da svuotare è:

Una nota importante: gli aggiornamenti sono fondamentali per garantire la stabilità e la sicurezza del sistema. Vanno quindi installati regolarmente e la procedura descritta non ne influenza l’installazione ma piuttosto ne impedisce il rollback (la possibilità di disinstallare un aggiornamento).

Un'altra cartella che occupa un po’ di spazio è la WinSxS: si trova direttamente sotto C:\Windows e non è da cancellare. E' possibile ripulirla tramite appositi comandi, come descritto nella guida presente su Technet. Ecco due utili comandi da avviare da una console amministrativa:

Il primo analizza la cartella e verifica la sua dimensione effettiva e indica se è possibile eseguirne la pulizia. Il secondo esegue effettivamente la pulizia. Ciò che si guadagna dipende molto dal proprio sistema, ma in situazioni di emergenza ogni byte...

Lanciare i tool di pulizia di Windows è anche un’altra utile pratica: basta andare in Impostazioni PC e quindi Spazio su disco. Per il desktop è possibile lanciare Liberare spazio su disco eliminando i file non necessari (cioè il vecchio Pulizia disco). Naturalmente è possibile installare tool più evoluti come CCleaner o System Mechanic per raffinare la pulizia e ottenere qualche funzionalità in più.

Quale interfaccia usare per ritornare un insieme?

Fri, 19 Jun 2015 20:44:00 GMT

Una buona pratica quando si ritorna un insieme da una funzione è quella di limitarsi alle interfacce base offerte dal .NET: IList, ICollection, IQueryable, IEnumerable o IReadOnlyList. In realtà la regola “accettare il minimo che si può, ma restituire il massimo” pone alcuni vincoli.

IEnumerable e IReadOnlyList sono in generale le interfacce utilizzate in questi contesti. E' interessante notare che IReadOnlyList non è molto diversa da IEnumerable ma permette di essere più espliciti nella dichiarazione della propria funzione. In realtà IReadOnlyList deriva sia da IEnumerable sia da IReadOnlyCollection ed espone sia Count sia Item(int index).

Ritornare un IEnumerable permette di utilizzare yield in fase di creazione, inoltre espone un insieme non modificabile. In realtà, se l’enumerazione deriva direttamente dal sorgente dati, è possibile fare un cast dell’oggetto. Inoltre, se si ritorna direttamente il sorgente dati, bisogna fare attenzione agli eventuali aggiornamenti che invalidano l’enumerazione. Di alternative non ve ne sono molte: o si crea un nuovo insieme (magari con un semplice ToArray()) oppure si utilizzano dei lock.

Comunque, utilizzare IEnumerable sul sorgente effettivo permette di evitare duplicazione dei dati, tipico delle liste e degli array, e al chiamate di richiedere solo i dati che gli servono interrompendo la richiesta appena possibile. Questa valutazione lazy funziona in particolare con yield:

Vale poi la pena di sottolineare la differenza tra ICollection e IList: la prima permettere di azzerare l'insieme, aggiungere un elemento in coda oppure di eliminarne uno specifico. L'altra permette inserimenti e cancellazioni anche indicando la posizione dell'elemento.

AddRange non è invece implementato in nessuna delle due interfacce anche se alle volte risulta comodo, ma un'interfaccia deve essere la più semplice possibile ed è facile creare un’estensione:

In tutti i casi parlo delle versioni generiche, perché è sempre il caso di ritornare collezioni tipizzate e con il tipo più alto possibile, liberando il client dalle verifiche sul risultato.

IQueryable è l'interfaccia fondamentale per l'uso di LINQ e permette ad un query provider di eseguire lato server il cosiddetto albero delle espressioni. Questo non è un vincolo dell’interfaccia ma la tipica implementazione per i sorgenti dati, come quelli esposti tramite Entity Framework che traduce la query LINQ in comandi specifici per l’effettivo data storage utilizzato.

Su MSDN è presente una pagina dedicata alle linee guide per le collection:

Ritornare collection tipizzate, possibilmente con il tipo più forte possibile (quindi non uno dei tipi base).
Non ritornare ArrayList o List nelle API perché sono ottimizzate e pensate per un uso interno.
Non ritornare Hashtable o Dictionary, ma eventualmente IDictionary.
Sullo stesso tipo non implementare sia IEnumerator sia IEnumerable.
Per insiemi read/write, preferire Collection o derivate per i valori di ritorno.
Per insiemi read-only preferire ReadOnlyCollection.
Considerare di creare collezioni personalizzate per una maggiore estendibilità (da derivare dai tipi base) o per poterne cambiare l’implementazione in futuro.
Considerare KeyedCollection per insiemi con chiave univoca.

La regola generale è quella di richiedere, come parametri, il tipo più debole che si ha bisogno e di ritornare il tipo più forte che si ha. Ad esempio, si dovrebbe accettare un IEnumerable e ritornare una Collection. Si dice: permissivi in entrata, specifici in uscita.

Infine, è buona norma non ritornare null ma piuttosto un insieme vuoto. Il chiamante deve poi usare Any() per verificare se vi sono elementi e non il più costoso Count() == 0.

Introduzione a MongoDB

Tue, 16 Jun 2015 21:23:58 GMT

MongoDB è un database document oriented. Nelle prime posizioni per popolarità in compagnia di tanti database relazionali, offre i tipici vantaggi della famiglia noSQL. La sua alta flessibilità e robustezza ne fanno un ottimo candidato per molte tipologie di applicazioni, non solo nell’ambito dei grandi volumi tipici del cloud.

Possiamo sintetizzare MongoDB dicendo che permette la memorizzazione di documenti in insiemi (detti collection) in cui non è necessario mantenere lo stesso schema per ogni elemento. Ogni documento ha un proprio id univoco che ne permette il rapido recupero.

Per documento non si intende un file nel senso comune del termine, ma una struttura dati simile ad un dizionario in cui le coppie nome/valore, detti field, definiscono un’entità. Nella stessa collezione, come detto, ogni documento può avere il suo insieme di field e un field con un certo nome può essere, in documenti diversi, di tipo diverso. Molto importante è il fatto che ogni documento può contenere altri documenti e, oltre ai tipi di dati primitivi, è possibile definire un campo come array. Gli array possono contenere qualsiasi altro tipo, compresi altri array e documenti. Questo offre una struttura dati molto completa e flessibile che in parte compensa le funzionalità dei database tradizionali che Mongo non può offrire.

Come per gli altri database noSQL non esiste il concetto di relazione e di transazione tipica dei database tradizionali, perché non vi sono relazioni tra i documenti che normalmente porterebbero a creare lock di scrittura che si propagano su più tabelle e righe. In MongoDB l’atomicità delle scritture è solo sul documento in modifica. In particolare non vi è un lock tra collezioni diverse. Ad esempio, non è possibile forzare l’eliminazione di documenti presenti in una collezione alla cancellazione di documenti presenti in un altro insieme: sarà compito dell’applicazione garantire la consistenza dei dati.

Altra importante caratteristica riguarda il fatto che il modello di coerenza non è rigido. Come discusso nell’ambito del teorema CAP un database distribuito deve sacrificare la consistenza per offrire disponibilità o viceversa. Il team di MongoDB ha cercato di offrire un compromesso davvero interessante tra la possibilità di gestire enormi quantità di dati e la loro coerenza: per comprendere la complessità di tale architettura si pensi ad un database suddiviso in centinaia di server che concorrono contemporaneamente a rispondere il più velocemente possibile ad un’altrettanta enorme mole di richieste.

Come è possibile gestire questa mole di dati e richieste? Offrendo un’incredibile supporto alla scalabilità orizzontale e alla robustezza: sia duplicando i database tramite repliche sia suddividendo le collezioni in parti (dette sharding). Le repliche garantiscono la disponibilità dei dati anche in caso di crash di un server, mentre i sharding permettono l’esecuzione di query in parallelo anche su server diversi. Non c’è limite al numero di server utilizzabili.

In un sistema noSQL, nato soprattutto nell’ambito distribuito come il web/cloud, si sacrifica coerenza a favore della disponibilità. Quindi in generale un client può aggiornare i dati ma vi è un certo periodo in cui il dato non risulta sincronizzato su tutte le repliche. Le modifiche vengono infatti accettate solo dal database primario e poi propagate sui database replica. Durante questa diffusione i dati risultano non coerenti: un client che accede ad una replica potrebbe ottenere una copia non aggiornata del documento. Si parla di eventual consistence, quindi di coerenza non immediata.

In MongoDB questo processo è ampiamente configurabile specificando il livello di Write Concern. Se un client richiede la modifica di un documento, tale operazione verrà eseguita in modo atomico sul server. Ma il flusso di una richiesta di modifica comporta diversi passi e MongoDB può essere configurato per indicare in quale punto si ha il ritorno del risultato al client:

In modalità fire and forget, detta anche relax, il client invia la richiesta e il server la prende in carico liberando subito il chiamante. In questo caso la modifica si trova nella cache del server che viene poi elaborata periodicamente. Quindi, in caso di errore, il dato potrebbe non essere nemmeno stato salvato sul server primario.
In base alla configurazione il client potrebbe attendere almeno la conferma del salvataggio effettivo del dato nello storage fisico, ma verrebbe liberato dall’attesa della replicazione sui nodi secondari.
L’ultima possibilità è quella di attendere sia la ricezione della richiesta, sia la persistenza sia la replicazione. In questi casi è possibile indicare il livello di replicazione, ad esempio indicando di attendere l’aggiornamento della maggioranza dei nodi.

Si parla di consistency e durability: la prima riguarda la coerenza dei dati tra nodo primario e secondari ed è un coerenza non immediata (Eventual Consistency), la seconda riguarda l’effettiva persistenza dei dati su dischi del nodo primario. Infatti un particolare sistema di cache, necessario per garantire elevati prestazioni, razionalizza l’accesso al disco.

Questi sono solo alcuni appunti relativi a MongoDB e l’intenzione è quello di introdurre alcuni concetti base. I vantaggi di MongoDB riguardano:

La scalabilità, quindi la distribuzione dei carichi di lavoro su più server.
La velocità, in particolare là dove è possibile accedere tramite chiave primaria.
L’integrazione diretta con il proprio modello Object Oriented, quindi nessun impendance mismatch e una maggiore velocità di sviluppo.
La possibilità di configurare il livello di coerenza, sia a livello di database, sia di collezione e sia di singola operazione.
La semplificazione della migrazione dei dati in caso di aggiornamento del modello dati.
La semplificazione della collaborazione nel team: è più semplice "visualizzare" un database MongoDB che un classico database relazionale.
La possibilità di estendere il proprio modello in modo più semplice grazie al polimorfismo dei dati e alla mancanza di schemi (un partner potrebbe salvare dati aggiuntivi nei documenti senza dover metter mano al database).
Il supporto ai dati di grandi dimensioni (tramite GridFS).
E’ un progetto in continua evoluzione: con la versione 3.0 è stato introdotto un nuovo motore che permette prestazioni e compressione dati notevolmente superiori rispetto alla precedente versione.
Tale le risorse a disposizione tra libri, presentazioni, meetup, webinar… Fondamentali l’Univerità MongoDB e la documentazione ufficiale.

MongoDB è un progetto Open Source scritto in prevalenza in C++. E’ distribuito come release stabile oppure in versione beta con compilazioni notturne. E’ disponibile per Windows, Linux, Mac OS X e Solaris. Il sito ufficiale è MongoDB.org mentre esistono molti servizi business per il supporto o l’hosting, in particolare MongoLab e MMS.

Infine, è interessante notare come MongoDB sia il database noSQL più richiesto nelle offerte di lavoro ed è, attualmente, il quinto database più popolare nella classifica di db.engines.com.

Build Tour Milano 2015

Wed, 10 Jun 2015 21:50:00 GMT

Oggi ho partecipato (dal vivo) all’evento //build/tour organizzato a Milano da Microsoft. Ottima l’accoglienza e l’organizzazione, per un evento gratuito condotto da speaker brillanti che hanno ben introdotto le tante novità legate a Windows 10.

E’ stata una bella esperienza e se all’inizio ero scettico sulla possibilità di partecipare dal vivo e abbandonare lo streaming, devo dire ora che la partecipazione di persona è di gran lunga più bella, grazie anche alla simpatia degli speaker e alla gentilezza e disponibilità di tutti.

Tanti gli argomenti a partire proprio dalla piattaforma Windows 10 in grado di rendere unica l’esperienza utente su dispositivi molto diversi tra loro e che vede nelle Universal Windows App il punto di arrivo di un percorso iniziato con gli aggiornamenti di Windows 8.1 e Windows Phone 8.1.

Si è parlato di Continuum, con la possibilità ad esempio di estendere il proprio smartphone con monitor, tastiera e mouse esterni sfruttando così la sua potenza in una postazione di lavoro vera e propria (sebbene non in modalità full desktop).

Si è parlato tanto di Cortana e di come sia semplice integrarlo nelle proprie applicazioni e di come sono migliorati i servizi di riconoscimento e sintetizzazione vocale.

Di come il nuovo browser Microsoft Edge, disponibile solo per Windows 10, offra prestazioni ed esperienze all’avanguardia (sarà possibile tra l’altro creare estensioni in Javascript e HTML, come succede per Chorme e Firefox).

Si è visto poi come sia possibile creare Web App in modo rapido a partire da un sito web e di come utilizzare da Javascript le potenzialità delle Windows API.

Si è quindi parlato dell’unificazione dello Store e delle tante funzionalità aggiuntive che offrirà: come la gestione dell’advertising, degli strumenti di analytics, delle sottoscrizioni IaP e delle campagne pubblicitarie.

Di come Microsoft Hello permetterà di abbandonare le vecchie password in favore del riconoscimento visivo e di come i servizi cloud di ultima generazione permettano proprio elaborazioni di immagini avanzate (si veda ad esempio How-Old).

Si è parlato anche del nuovo Azure, dei tanti strumenti disponibili e di come sia completamente aperto a tecnologie fino a poco tempo fa estranee se non nemiche (il mondo Linux, Apache, noSQL…). In particolare nel cloud sono disponibili i nuovi Azure App Service in cui confluiscono i servizi Web, Mobile, Logic e API.

Si è parlato delle tante innovazioni di Visual Studio 2015 e dell’arrivo di Visual Studio Code, il tool multipiattaforma per chi si dedica soprattutto alla scrittura del codice (con il linguaggio che preferisce). Si è parlato di .NET Native che permette di ottenere, con un flag, grandi prestazioni dalle proprie applicazioni .Net.

E poi ancora di Beacons, di Http2, di SVG, di Design, Web Audio API, TypeScript... e tanto altro.

Molto bella la closing note da parte di Fabio Santini di Microsoft Italia, che in pochi minuti ha parlato in modo molto chiaro dei cambiamenti avvenuti in Microsoft nell’ultimo anno e mezzo. Cambiamenti decisamente vistosi iniziati grazie all’avvento di Satya Nadella che, contrariamente a Balmer, è cresciuto in Microsoft come figura tecnica.

La visione di Nadella è ben espressa da una sua frase diventata il motto di questo processo di innovazione:

Our industry does not respect tradition, it only respects innovation.

Puoi quindi aver creato i software più utilizzati del mondo ma se non riesci ad innovare cogliendo le opportunità che il mondo IT crea e richiede, allora sei destinato a rimanere indietro. Come è successo a Microsoft nel campo del Web e del Mobile.

Microsoft è passata da un core business basato principalmente sull’accoppiata Windows/Office ai servizi Enterprise e quindi al Cloud, accogliendo e sfruttando i tanti strumenti non Microsoft disponibili, per offrire allo sviluppatore un’esperienza completa.

L’innovazione è quello che chiede il mercato ed è alla base di quella rivoluzione tecnologia che, pare, Nadella abbia sintetizzato in questo disegno:

Un mondo in cui i software sono ovunque, dai grandi data center del Cloud ai piccoli sensori dell’IoT… Miliardi e miliardi di dispositivi che raccolgono o consumano un’enorme quantità di dati che hanno portato allo sviluppo delle tecnologie Big Data e la cui elaborazione è una delle sfide del presente. Tanti strumenti e tante opportunità che rendono questo lavoro ancor più entusiasmante.

Un grazie quindi a tutti per l’ottimo evento, in particolare ai tre speaker (Andrew Wigley, Nikola Metulev e David Rousset) che grazie alla loro simpatia hanno donato all’evento un po’ della leggerezza necessaria per reggere una così lunga giornata ricca di informazioni. Naturalmente un grazie a tutto il team di Microsoft Italia e a tutti coloro che hanno lavorato all’organizzazione.

Rimando per un'ulteriore panoramica all’articolo di WebNews.

Lunga vita alla linea di comando

Sat, 30 May 2015 21:55:00 GMT

Gli strumenti grafici a disposizione degli sviluppatori sono molti e sempre più evoluti. Alcune attività risultano comunque più efficienti se eseguite tramite linea di comando, modalità che Windows supportava malamente fino all'avvento di potenti strumenti come PowerShell e tool come cmder.

In questo post parlerò di cmder, un tool che rivitalizza la linea di comando di Windows, mentre affronterò il potentissimo PowerShell in un altro articolo. In entrambi i casi si tratta di strumenti spesso sottovalutati dagli sviluppatori (e purtroppo non solo da loro), ma che permettono di aumentare la propria produttività, di automatizzare task ripetitivi e alle volte di trovare soluzioni altrimenti non disponibili tramite i normali tool di amministrazione e sviluppo.

La linea di comando diventa importante nel momento in cui si utilizza Git, che esprime le sue massime potenzialità tramite shell (inoltre la maggior parte delle guide e degli esempi disponibili usa questo metodo). Anche le nuove generazioni di ASP.NET offrono alcuni utili strumenti via linea di comando, quindi facilmente automatizzabili. Vi sono poi tool come Chocolatey o il prossimo OneGet che permettono di automatizzare l’installazione e l’aggiornamento dei pacchetti presenti sulle proprie macchine.

Automatizzare, schedulare, concatenare e ripetere comandi rappresentano le vere potenzialità della linea di comando.

Cmder è un emulatore della console di Windows che unisce molti strumenti nati nella comunità e disponibili come progetti open source. E’ disponibile come applicativo portabile, sia in versione ridotta (circa 7 mb) sia in versione completa (circa 250 mb): quest’ultima include i tool di supporto a Git.

Se l’avvio fallisce con un messaggio del tipo “The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer" allora è necessario installare Visual C++ Redistributable for Visual Studio 2015 (64-bit).

Cmder è tecnicamente un terminale che permette l'avvio di più shell, generalmente interpreti a linea di comando come Powershell e cmd.exe. Nulla vieta di avviare altri applicativi: è disponibile ad esempio la guida per integrare Sublime Text. Per chi vuole invece creare un ambiente linux-like è possibile configurare Cygwin, un vasto insieme di strumenti GNU per portare alcune funzionalità di Linux in ambiente Windows. Qui la guida.

All'avvio di una console PowerShell verrà eseguito, per attivare alcune utili configurazioni, lo script profile.ps1 presente nella cartella Vendor. Se l'esecuzione dovesse fallire con l'errore about_Execution_Policies allora dovrete cambiare le policy di esecuzione degli script. La policy di default è permettere l'esecuzione di comandi ma non di script (il comando Get-ExecutionPolicy dovrebbe infatti ritornare Restricted). Per modificare usare set-ExecutionPolicy Unrestricted.

Dietro le quinte Cmeder utilizza una cmd.exe nascosta e le funzionalità di tre progetti completamente integrati:

ConEmu: è una console multi scheda con tante funzionalità per rendere la shell più user friendly.
Clink: che offre le funzionalità di modifica della linea di comando disponibili in nella shell Bash tipica dei sistemai *nix.
Msysgit: che offre in ambiente Windows tutti i comandi del più diffuso sistema di Source Control Management.

L'applicativo è altamente configurabile e permette di definire i task associati all’apertura delle schede. Predefiniti sono i task per cmd.exe e Powershell, che possono essere duplicati e avviati con specifici argomenti. Per PoSH è possibile indicare un proprio script di avvio, come visto con profile.ps1.

E’ inoltre possibile definire degli alias tramite il comando alias. Quelli predefiniti si trovano nel file config/alias. Ad esempio:

ls=ls --show-control-chars -F --color $*
clear=cls
e.=explorer .

Nell’ultimo caso basta quindi scrivere e. per far partire il file explorer posizionato sulla cartella corrente.

E’ possibile definire molti shortcut, nonché l’aspetto delle finestre. Nella sezione App Distinct è anche possibile associare ad ogni applicativo specifiche caratteristiche come il colore di sfondo della shell.

Sono supportate le tipiche combinazioni veloci:

Ctrl + n: per passare alla scheda in posizione n.
Ctrl + Tab: per ciclare tra le tab.
Ctrl + w: per chiudere il tab corrente.
Ctrl + t: per arpire un nuovo tab.
Shift + Alt + n: per aprire rapidamente cmd (1) o PowerShell (2).
Alt + Enter: per la modalità a tutto schermo.
Right Click: copia il testo presente nella cliboard.
Ctrl + r: ricerca nell’history dei comandi.

La selezione con il mouse, una volta completata, copia direttamente negli appunti: una finezza molto utile.

Altre caratteristiche:

Supporto al copia e incolla da tastiera
Sono disponibili comandi unix del tipo ls, mv, cp, grep, cat (comandi).
L'utilizzo di segnali acustici nel testo permettere di ottenere delle notifiche nell'output.
E’ possibile avviare una task (ad esempio la shell di PS) con privilegi di amministratore senza uscire da cmder.
La configurazione dell’applicazione, sia nell’aspetto sia nelle funzionalità, è facilmente modificabile e condivisibile essendo salvata nelle cartelle dell’applicazione.
E' possibile avviare cmder con alcune opzioni, tra cui -k "command", che permettere di avviare il tool, eseguire il comando indicato e lasciare aperta la console.
E' possibile cambiare il Code Page (di default è ANSI)
E’ possibile includere nel menu di contesto del file explorer la voce “Cmder here” semplicemente eseguendo come amministratore il comando cmder.exe /REGISTER ALL.

Perché preoccuparsi della linea di comando? Naturalmente PowerShell ha migliorato decisamente l'approccio a linea di comandi in Windows, ma cmder permette di combinare un insieme di strumenti in un'unica console e di utilizzare comandi tipici di altri sistemi come quelle presenti nei sistemi unix like.

I database noSQL

Wed, 27 May 2015 22:00:46 GMT

I database noSQL sono una famiglia di database che comprende sistemi molto diversi tra loro. Ciò che definisce queste diverse tipologie una famiglia è in generale l’assenza di schemi rigidi e di relazioni. Sono nati per coprire le mancanze dei database classici in un’ottica in cui la scalabilità è un requisito fondamentale.

In realtà i database noSQL si sono poi evoluti per affrontare molte altre sfide e adesso ne esistono decine con molte caratteristiche e una vasta gamma di opzioni che ne aumentano l'appetibilità.

Scrivere applicazioni web e cloud implica dover affrontare i problemi legati alla rete e ad un volume dati/richieste molto elevato. Da qui la necessità di scalare orizzontalmente e, come discusso nell’articolo dedicato al teorema CAP, la scalabilità implica scegliere tra coerenza dei dati e disponibilità del sistema. Questo ha portato le soluzioni noSQL ad abbondonare concetti come transazioni e relazioni: garantire entrambe in un database distribuito è improponibile se si vuole offrire la massima risposta.

Un altro problema affrontato dal movimento noSQL riguarda la rigidità degli schemi dati dei database tradizionali. Ad esempio, le entità cosiddette social, come friends, follower e comment sono tipici esempi di polimorfismo delle entità. Tale problematica è affrontabile anche con database relazionali, si pensi ad esempio alle colonne XML, ma essendo by design nei database noSQL la flessibilità e l’efficienza risultano migliori.

La mancanza di schemi permettere di velocizzare lo sviluppo e questo ben si adatta alle moderne metodologie agili. Infatti, da un punto di vista object oriented, c'è una sfasatura tra le strutture del linguaggio e quelle del database (il cosiddetto impedance mismatch), mentre in noSQL è possibile una mappatura diretta. Certamente gli ORM semplificano l’utilizzo dei database relazionali, ma si è sempre vincolati dalla classica struttura tabelle/relazioni.

Fondamentalmente l'architettura dei database noSQL è un'architettura key/value: ad una chiave si associa un valore. Una struttura semplice che però diventa molto flessibile e efficiente: il recupero tramite chiave è rapidissimo e la chiave e i valori possono essere di tipi diversi come primitivi, documenti, array e hash.

Questo è una rappresentazione valida di un documento memorizzabile con un singolo comando in MongoDB:

Ecco cosa si intende per schema non rigido: in un insieme (un contenitore di dati) possono coesistere dati con strutture diverse. Non c'è una rappresentazione rigida come quella tipica basata sulle righe e colonne. Ecco quindi che nello stesso insieme in cui è presente la scheda di John Doe possiamo memorizzare il suo omonimo italiano:

I database noSQL possono essere di tipologie molto diverse in relazione ai casi d'uso che devono affrontare: si va da database super scalabili per la gestione di volumi enormi di dati a database specializzati alla gestione dei dati in memoria. Tante sono le caratteristiche dei database e ogni database offre molte opzioni per adeguarsi alle esigenze dell’applicazione.

In vari casi un database noSQL permette di evitare la gestione delle relazioni, la cancellazione a cascata e pesanti lock. In un database document-ordiented è possibile ad esempio includere in un documento eventuali sotto documenti (come Address negli esempi precedenti). E' possibile ma non è sempre opportuno: dipende dal ciclo di vita di questi sotto oggetti (in pratica bisogna chiedersi quando vengono caricati e salvati: se sono entità indipendenti).

I tipici documenti gestibili efficientemente da database noSQL, oltre alle entità social, sono le configurazioni, gli indirizzi, le note, le schede prodotto. Perché? Perché se la struttura di questi oggetti cambia non è necessario migrare i dati esistenti e l’impatto sul codice è relativamente basso.

La struttura che si ottiene è più flessibile e permette di arricchire il proprio data model con funzionalità aggiuntive che altrimenti richiederebbero più passaggi. Se un ordine include già le righe dei prodotti allora l'ordine può esporre una proprietà per il calcolo del totale.

C'è un altro aspetto interessante delle tecnologie noSQL: una diversa prospettiva nel design dell’applicativo. Non è detto che un database noSQL sia la scelta più giusta per il proprio progetto, ma spesso permette di svincolarsi dalla rigidità dei database tradizionali che limitano il design. Ancora oggi molti sviluppatori sono troppo data-centric: definiscono l'applicazione partendo dal design delle tabelle e delle relazioni.

Un aspetto importante delle tecnologie noSQL riguarda proprio il fatto che è lo storage ad adeguarsi alle nostre strutture dati e non viceversa. Con i database noSQL lo storage diventa uno strumento al servizio dello sviluppatore e non un vincolo.

La mancanza di relazioni significa niente normalizzazione delle tabelle, niente chiavi esterne, niente Join. E i dati sono spesso trattati in task non transazionali: la modifica è atomica per singoli elementi/documenti, ma non è garantita l’atomicità di un processo che coinvolge più elementi/documenti. Se per un catalogo di prodotti non vi sono particolari problemi, per un processo di vendita non è possibile non garantire l’aggiornamento complessivo del conto cliente e del magazzino.

Tanti sono gli aspetti del mondo noSQL. Ad esempio, il cosiddetto Eventual consistency, indica come vengono gestite le azioni di modifica richieste da un client. Per poter offrire disponibilità e scalabilità un database noSQL potrebbe richiedere un attesa sull'esecuzione delle modifiche sul cluster corrente (si parla di durabilità) e tra cluster secondari (si parla di replicazione). In pratica si dice al server voglio salvare questo oggetto e non si aspetta alcun processo completo: non solo che il data sia replicato ma alle volte anche che sia stato effettivamente salvato su disco.

Cambiano anche i metodi di interrogazione: non a caso si parla di "no SQL". Le query non sono dichiarative ma si scrivono come codice procedurale, tramite un paradigma imperativo. Il chiamate dice esattamente come devono essere trattati i dati e non solo cosa vuole ottenere. Ma questo, come tanti altri aspetti, dipende dal database in uso. Nella sezione Data sono disponibili le panoramiche ai database noSQL più diffusi e interessanti.

DigitalOcean: VPS e Linux a portata di mano

Thu, 14 May 2015 21:39:00 GMT

Grazie alle molte piattaforme cloud nate negli ultimi anni gli sviluppatori hanno a disposizione tanti strumenti per il test e la prototipazione. DigitalOcean è un provider di Virtual Private Server con sede a New York che offre a prezzi contenuti server con sistemi Linux, attivabili in meno di un minuto.

Il processo di registrazione è semplice e veloce, ma è necessario fornire una carta di credito o versare 5$ tramite PayPal. Con una breve ricerca in Internet è anche possibile trovare un coupon per ottenere un credito di almeno 10$ (personalmente ho usato il codice ALLSSD10) o farsi referenziare da qualcuno per ottenere un credito di benvenuto sempre di 10$ (se avete bisogno inviatemi una mail).

In pochi minuti si può creare un server virtuale con sistema operativo Ubuntu, utile per lo sviluppo e la prototipazione di applicazioni che richiedono servizi installabili solo su piattaforme *nix o che è meglio testare anche sul sistema del pinguino. Per un paio di ore il costo non arriva nemmeno ad un euro. Interessante è anche la possibilità di provare applicativi .NET tramite Mono, senza dover installare nulla in casa.

Tra le distribuzioni disponibili: Ubuntu, Debian, Fedora, CoreOS, FreeBSD, CentOS. Tutti i piani includono dischi SSD. Il pagamento è orario e i prezzi relativamente bassi: il profilo più economico costa 5$ al mese offre un server con 512 MB di RAM, 20 GB SSD, 1 CPU e una banda di trasferimento di 1 TB. Il costo è comunque orario e un'ora costa effettivamente $0.0074.

Per fare un semplice paragone, l’offerta più bassa disponibile in Azure costa più del doppio. Certamente Azure è ben altra cosa con la sua molteplicità di servizi, ma la specializzazione di DigitalOcean ha prodotto un servizio molto professionale: lo si può notare consultando la knowledgebase, ricca di guide e tutorial, con tanto materiale anche per chi è alle prime armi con sistemi linux e server virtuali.

Il piano tariffario è chiaro e scalabile in base alle proprie esigenze. Le prestazioni buone e il pannello di controllo semplice ed intuitivo. Qui i server virtuali sono definiti droplet. E’ disponibile un backup manuale tramite snapshot oppure un backup automatico tramite una procedura che viene avviata ogni due giorni. Entrambi i backup possono essere riutilizzati per creare nuovi droplet.

Altri importanti aspetti:

E’ possibile configurare il DNS della macchine come indicato da questa semplice guida.
E’ disponibile un’API pubblica che mette a disposizione le stese funzionalità del pannello di controllo.
Per la sicurezza è possibile abilitare una chiave SSH.
Attenzione al fatto che spegnere un server non significa non spendere: bisogna creare uno snapshot e quindi distruggere il droplet.
Di default non è attivo alcun firewall che è consigliato configurare nel proprio server.

Creare un Droplet con MongoDB

Vediamo come creare un macchina Ubuntu per attivare un server MongoDB:

Dopo la registrazione avviare la procedura di creazione Droplet.
Indicare il nome del server e quindi selezionare una delle grandezze.
Selezionare la regione (tra cui Amsterdam, Francoforte e Londra)
Attivare varie opzioni (provate networking, IPv6 e Backups)
Selezionare l’immagine del sistema da installare (e la versione specifica: nel mio caso Ubuntu 14.04 x64).
Selezionare le applicazioni da installare (nel nostro esempio MongoDB, ma ve ne sono 24 tra cui Cassandra, Ruby on Rails, WordPress, Docker).
Avviare la creazione: in 90 secondi la macchina è pronta.
Per questa demo non utilizzerò una chiave SSH ma per altri usi è consigliata.

Sempre da pannello di controllo è possibile avviare la console tramite VNC: l’IP e l’account per accedere arriveranno via e-mail in un paio di minuti. In Windows è meglio utilizzare PuTTY.

E’ naturalmente consigliato creare un nuovo utente e non utilizzare l’utente root,: questo obbliga a inserire sudo prima di ogni comando amministrativo. Qui la guida per creare un nuovo utente, assegnargli diritti root e abilitare SSH.

Avendo scelto l’installazione di MongoDB in fase di creazione non è necessario fare nulla di particolare: il servizio di MongoDB è già attivo. Infatti, è sufficiente avviare la shell mongo:

Per accedere in remoto, ad esempio dalla propria macchina dove presumibilmente vi è un po’ di codice per utilizzare Mongo, è necessario abilitare l’accesso tramite internet nella configurazione di MongoDB, memorizzata nel file /etc/mongod.conf. Con l’editor di testo predefinito modificare tale file:

vi /etc/mongod.conf

Cercare il valore di bind_ip e sostituire all’indirizzo locale predefinito (127.0.0.1) l’indirizzo del server:

Usare vi: dopo aver avviato vi attivare l’inserimento del testo premendo il tasto Ins. Sostituire l’ip locale (per incollare da clipboard premere il tasto destro del mouse), quindi uscire dalla modalità inserimento premendo ESC, infine digitare “:wq” (modalità comando a cui si passa write e quit). Se si vuole uscire senza salvare le modifiche usare q!.

Per rendere effettive le modifiche è necessario riavviare il daemon:

sudo service mongod stop
sudo service mongod start

Per arrestare il server e poter creare uno snapshot scrivere:

sudo shutdown -h now

Non dimenticate di distruggere la macchina se non la utilizzate! A proposito, ecco qui il costo del server utilizzato per più di un'ora:

Conclusione

Naturalmente avviare una macchina Linux per installare un database non è un'operazione così difficile e non è nemmeno richiesto ad uno sviluppatore di diventare un sistemista, ma poter utilizzare strumenti semplici e veloci come quelli offerti da DigitalOcean può essere di grande aiuto.

Per i progetti reali bisogno poi affidarsi ad un team più ampio e multiforme, proprio per poter meglio sfruttare le caratteristiche che la tali strumenti offrono: tra l’altro le offerte disponibili sono molto flessibili e scalabili.

Il teorema CAP

Wed, 13 May 2015 19:31:41 GMT

Il teorema CAP afferma che un sistema informatico distribuito, quindi anche un database distribuito, non può soddisfare contemporaneamente le tre garanzie coerenza, disponibilità e tolleranza al partizionamento. Il problema riguarda l’instabilità della rete che collega i diversi nodi del sistema.

Per sistema distribuito si intende un sistema suddiviso in più nodi (server) in una rete di grandi dimensioni, eventualmente globale. Tale distribuzione consente di non affidare ad un unico server la stabilità del sistema e consente di suddividere i carichi di lavoro.

E’ una configurazione tipica del cloud: più server soddisfano le tante richieste e la rottura di un server non implica la caduta dell’intero sistema. Inoltre, nel contesto di reti di grandi dimensioni, avere più nodi consente di avvinarsi ai client riducendo i tempi di risposta.

Nel mondo dei database si ha un partizionamento per suddividere i carichi di lavoro, per avvicinare la fonte dati ai client e per mantenere più copie dei dati. In generale una replica viene definita come primaria e ogni scrittura su quel nodo viene propagata alle altre partizioni.

Per coerenza (consistency) di intende la capacità del sistema di poter rendere disponibili i dati più aggiornati a qualsiasi client che ne faccia richiesta, indipendentemente dal nodo a cui la richiesta è stata fatta. In pratica un’operazione di modifica è completa quando ogni nodo è stato aggiornato e durante questa operazione la lettura è sospesa.

La disponibilità (availablility) garantisce che il sistema sia in grado di rispondere ad una chiamata, in particolare un client potrà aggiornare i dati senza ritardi, anche in presenza di errori di comunicazione tra le repliche. Il client invia la sua richiesta di aggiornamento senza attesa e quindi successive letture potrebbero ritornare dati non coerenti per la lentezza della propagazione o per errori nel sistema o per ritardi nell’effettivo salvataggio dei dati.

La tolleranza di partizione (tollerance partion) garantisce che il sistema rimanga funzionante nonostante la perdita di messaggi: in questi casi alcuni nodi possono rimanere isolati dagli altri e non avere più informazioni aggiornate (sono partizionati).

Il teorema afferma che non è possibile soddisfare contemporaneamente le tre garanzie, ma bisogna sceglierne due a discapito di quella esclusa. La regola è tanto più importante quanto la rete diventa meno affidabile e la comunicazione tra le partizioni del sistema diventano un problema. La questione è: offrire il più alto grado di disponibilità oppure di coerenza dei dati? Dipende dal tipo di applicazione.

Coerenza significa che una scrittura viene accettata se replicata ovunque senza errori, quindi una modifica può essere rifiutata perché la propagazione è fallita anche su un singolo nodo. Disponibilità significa accettare una scrittura ancor prima che venga propagata, quindi è possibile che quella modifica non sia (immediatamente) disponibile e addirittura che non sia mai disponibile. Comunque, la maggior parte dei database permette di configurare il grado di garanzia offerto.

Ad esempio, in MongoDB, questa configurazione può essere fatta per l’intero sistema, per un certo database, per una certa collezione di dati o per una singola operazione.

E’ comunque importante capire che non è possibile ottenere contemporaneamente massima disponibilità e massima coerenza. Sebbene questo valga in un sistema distribuito, i concetti descritti sono comunque utili in diversi contesti. Bisonga inoltre dire che l’affidabilità delle reti è sempre maggiore, così come la disponibilità di strumenti la cui combinazione permette di gestire opportunamente gli errori (ad esempio utilizzando le code di messaggi).

E’ certamente un discorso che riguarda la scalabilità: se voglio garantire la massima consistenza e la massima disponibilità allora un singolo processore è la scelta da considerare e la scalabilità sarà verticale (le capacità del singolo server vengono aumentate). Se la scalabilità verticale non è possibile o non adeguata al sistema, allora la scalabilità orizzontale (con l’aggiunta di più server al sistema) deve fare i conti con il teorema CAP.

In generale, abbiamo da una parte i sistemi di database relazionali (RDBMS) che garantiscono disponibilità e coerenza, e dall’altra le diverse tipologie di database noSQL che coprono le altre due casistiche. In realtà i database noSQL possono essere configurati in base alle esigenze e database come CouchDB, Neo4j e MongoDB possono garantire coerenza dei dati (ovviamente a scapito delle altre caratteristiche).

La combinazione di queste garanzie nell’ambito dei database è ben esprimibile da questo schema:

Abbiamo quindi le seguenti combinazioni:

CP: coerenza e tolleranza di partizione, come in MongoDB, HBase, BigTable.
AP: disponibilità e tolleranza di partizione come in CouchDB, Riak, Cassandra.
CA: coerenza e disponibilità, come nei RDBMS in cui il sistema non è distribuito.

Considerando un sistema distribuito rimane quindi da scegliere cosa sacrificare: la consistenza o la disponibilità. Sostanzialmente se devo garantire la consistenza è possibile che in un dato momento un'informazione non sia disponibile perché è in aggiornamento e tale aggiornamento implica l'aggiornamento di tutti i nodi del sistema. All'inverso, se devo garantire una rapida risposta non posso bloccare il sistema in caso di scrittura: quindi parte dei dati messi a disposizione dei client potrebbero non essere coerenti.

Il cosa sacrificare dipende dal tipo di applicazione: se devo gestire i commenti in un sito di social network, il fatto che alcuni utenti non visualizzino i commenti più recenti non ha molta importanza. Se invece devo gestire il magazzino di un e-commerce è fondamentale che lo stato dei prodotti sia sempre aggiornato.

Come detto se si vuole la massima consistenza allora la disponibilità viene meno, ma se si vuole la massima disponibilità la consistenza non è garantita. Si parla di eventual consistency (nel senso di non immediata): ogni nodo del mio sistema è disponibile a rispondere ad una richiesta ma i dati che espone non è detto che sia aggiornati, perché la propagazione dei dati è lenta. D’altra parte la scrittura dei nuovi dati non ha bloccato l'intero sistema che può reagire alle richieste velocemente.

Un classico esempio di sistema distribuito è il DNS che mappa gli indirizzi IP con i domini: la propagazione di una modifica può impiegare diverso tempo, ma sostanzialmente il sistema risponde comunque ai client e ad ogni istante le informazioni sono sempre più coerenti tra loro.

Stack Overflow Developer Survey 2015

Tue, 12 May 2015 23:21:00 GMT

I risultati del sondaggio proposto da Stack Overflow offrono diversi spunti per alcune considerazioni sullo sviluppo software e sulle molte comunità che permettono un continuo, prolifico e utile scambio di informazioni e opinioni. In questo post riepilogo i risultati che mi sono parsi più interessanti.

Partiamo dalla fonte: più di 26.000 persone da 157 paesi, con un’età media di 28,9 anni. 92% maschi. Ma i numeri di StackOverflow sono ben maggiori: più di 30 milioni di visitatori ogni mese, di cui 25 milioni di ritorno. La media di visite per ogni visitatore è di circa 6 volte al mese: confesso che avrei giurato per una media giornaliera… e infatti due terzi visitano il sito più volte al giorno.

Mi sorprende che solo il 25% degli sviluppatori abbia una esperienza di più di 10 anni. Forse molti sviluppatori si occupano di tecnologie non attive nelle comunità… oppure il numero di sviluppatori è aumentato esponenzialmente negli ultimi anni.

Comunque, è più interessante notare che quasi la metà dei miei colleghi non è laureata. Parte della formazione viene fatta al lavoro e come auto didatta… in quest’ultimo caso penso sia fondamentale la passione per il lavoro che si fa: non a casa circa il 70% degli intervistati spende (o investe…) almeno 2 ore alla settimana per progetti open source o per hobby. La media è di un impegno di circa 7 ore extra-lavorative settimanali.

Naturalmente il linguaggio più popolare è Javascript, mentre la parte server è dominio di Java (il C# ha una popolarità del 30%).

Sempre considerando gli intervistati, Windows è il sistema operativo più diffuso e iOS sembra aver superato Linux: immagino per il grande contributo dato dallo sviluppo App per iPhone e iPad.

I cosiddetti full-stack developers utilizzano come editor testuali Notepad++ e Sublime Text, che invece vengono usati singolarmente e rispettivamente da sviluppatori desktop e sviluppatori web front-end. Vim domina tra i DevOps e i Sys admins.

Gli strumenti di Source Control sono ormai uno standard ma ben il 10% degli intervistati non ne fa uso. Cosa alquanto strana considerando i tanti vantaggi e la facilità d’uso che i moderni strumenti offrono, anche online e gratuitamente. Comunque, Git copre il 70%, seguito da SVN con il 37% (!) e TFS con il 12%.

La lunga e sanguinosa diatriba sull’uso degli spazi o delle tabulazioni vede vincere questi ultimi. Ma non è un caso che all’aumentare dell’esperienza e della reputazione (su StackOverflow), gli utenti preferiscono gli spazi 3 volte su 1.

Poco meno del 10% di chi ha indicato l’area di attività si è definito sviluppatore mobile. La maggior parte per Android e quindi alternativamente per iOS, mentre un 20% non ha un’unica piattaforma di riferimento. Windows Phone è al 2%.

Per quanto riguarda gli stipendi medi si assiste a un dimezzamento progressivo dagli Stati Uniti all’Europa Occidentale e quindi all’Europa Orientale. Ad aumentare di molto lo stipendio sono le tecnologie emergenti e di nicchia, oppure il cloud computing e i big data. Pare quindi che essere specializzati in certe tecnologie porti notevoli vantaggi: sarà per la minor concorrenza, sarà per le particolari doti necessarie per approfondire certe tematiche, sempre e comunque mantenendo competenze necessariamente ampie. Tra le tecnologie più pagate: Cassandra, Spark, F#, Scala, Rust, Hadoop, Cloud, Redis, Go e Clojure.

Ecco quindi la cosa più interessante, che in parte giustifica, soprattutto dall’altra parte dell’atlantico, l’impegno di molti sviluppatori nelle comunità e in particolare su StackOverflow: pare che all’aumentare della reputazione, per i punteggi ricevuti in base alle domande e alle risposte, aumenti anche lo stipendio in modo progressivo fino a un 135% rispetto al salario medio. Non so dire se ciò valga anche per l’Italia…

Si è inoltre assistito ad un aumento del lavoro remoto: dal 21% dell’anno scorso al 29% di quest’anno. Inoltre, gli sviluppatori con reputazioni oltre i 5.000 punti indicano, con percentuali doppie rispetto agli altri sviluppatori, che il lavoro remoto non è negoziabile.

In generale gli utenti di StackOverflow sono soddisfatti degli aiuti ricevuti dagli altri utenti: l’86% hanno trovato la piattaforma utile. Aggiungerei anche indispensabile.