Ugo Lattanzi

Quattro chiacchiere su ASP.NET vNext

2015-01-19T00:00:00+00:00

Poco prima delle vacanze natalizie ho partecipato alla registrazione di un Podcast tecnologico riguardante ASP.NET vNext.

Devo dire che è sempre un piacere poter condividere la propria passione, specie se poi ti trovi a farlo con degli amici come quelli di dotNET{podcast}.

Durante la chiacchierata abbiamo toccato tutti i punti più importanti del nuovo ASP.NET, come Mono, ASP.NET Core, MVC6, Linux e molto altro ancora (qui ho scritto un po' a riguardo).

Se siete interessati ad approfondire l'argomento potete ascoltare l'episodio a questo indirizzo http://www.dotnetpodcast.com/show/card/19. Un consiglio: iscrivetevi al feed ed ascoltate anche gli altri podcast (alcuni davvero davvero interessanti).

Buon ascolto

P.S. non sparate sul pianista

ASP.NET vnext

2014-05-23T00:00:00+00:00

Poco più di una settimana fa Scott Hanselman ha annunciato tramite il suo blog alcune delle più importanti novità che riguardano la prossima release di ASP.NET, conosciuta con il codename Project K.

Le novità sono veramente tante: alcune di grande impatto a livello strutturale e di framework, altre che vanno ad impattare sulla scrittura del codice ma in maniera meno invasiva. Ma partiamo con ordine.

La prossima release sarà rilasciata sotto licenza .NET Foundation ed il codice sarà disponibile su Github qui.

Questa release lavorerà side by side con .NET Native (un compiler .NET che promette performance alla c++ ma con la produttività del c#), .NET Compiler Platform ("Roslyn") (compiler-as-a-service) e Nextgen JIT (un JITter ottimizzato per i nuovi processori).

Un'altra importantissima novità riguarda il CLR (Common Language Runtime); la prossima release non avrà più una dipendenza da esso come le precedenti release, ma avrà un runtime tutto suo.

Quest'esigenza nasce dalla voglia di incrementare sensibilmente le performance delle applicazioni. Il CLR del .NET è lo stesso per tutte le applicazioni, siano queste Windows Application, Windows Phone o ASP.NET. Ovviamente questa versatilità ha un costo in termini di memoria e performance, così il vnext utilizzerà il K Runtime fortemente ottimizzato per il web.

Il CLR sarà ottimizzato in base all'environment dove verrà "deployata" l'applicazione (Cloud, Premise, ...) e verrà rilasciato via NuGet. Quest'ultimo assume un ruolo sempre più importante nel mondo Microsoft: inizialmente era rivolto solo alla distribuzione di librerie .NET, successivamente è stato utilizzato anche per il setup di Visual Studio, per arrivare ora al vnext di ASP.NET.

Rimanendo in tema di CLR, va menzionata anche la nuova modalità di compilazione. Le dll ed il compilato delle view Razor non saranno più presenti nella classica folder bin o nella Temporary folder di ASP.NET, bensì in memoria. Anche questo cambiamento è rivolto esclusivamente alle performance, riducendo drasticamente la lettura/scrittura su disco, lavorando così in RAM. Questo apre anche un altro scenario di non poco conto, ossia la possibilità di cambiare il codice on-fly (sfruttando Roslyn per la compilazione), senza dover ricaricare dll sul server.

A completare quest'importante carrellata di novità si aggiunge la compatibilità con Mono e la conseguente possibilità di eseguire le proprie applicazioni ASP.NET vnext anche su sistemi operativi non Microsoft (Linux, Unix e Mac OsX). Questo cambiamento era facilmente intuibile con l'introduzione di OWIN e Katana, che annunciavano la scissione tra IIS e ASP.NET (vedi slides di una mia presentazione qui).

MVC, Web API e SignalR

Tutti e tre i Framework convergeranno in un unico pacchetto chiamato MVC 6, uniformando così namespace e parte di codice. Di fatto Controller, Action, Routing e Model sono più o meno presenti su tutti e tre i Framework, ma su librerie differenti con Namespace differenti.

Ora un Controller, che sia questo un API Controller o un normale Controller MVC, erediterà sempre dalla stessa classe Microsoft.AspNet.Mvc.Controller (precedentemente si aveva System.Web.Mvc.Controller per MVC e System.Http.Controller per le API) ed il codice rimarrà uguale a quello che si è già abituati a scrivere:

Esempio di un controller MVC

using Microsoft.AspNet.Mvc;

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

Esempio di un controller WEB API

using Microsoft.AspNet.Mvc;

public class ValuesController : Controller
{
    // GET /values
    public string Get()
    {
        return "Values";
    }

    // GET /values/1
    public string Get(int id)
    {
        return "Value " + id.ToString();
    }

    // POST /values
    public ActionResult Post()
    {
        return new HttpStatusCodeResult(201);
    }
}

Esempio di una serializzazione JSON

using Microsoft.AspNet.Mvc;

public class MoviesController : Controller
{
    public ActionResult Get()
    {
        var movie = new Movie
        {
            Title = "Maximum Payback", Year = 1990, Genre = "Action"
        };
        return Json(movie);
    }
}

È stato introdotto anche il supporto ai POCO (Plain Old C# Object) Controllers, in modo da avere classi "pulite" senza la necessità di ereditare da classi base:

public class HomeController
{
    private IActionResultHelper resultHelper;

    // La dipendenza arriva tramite il container della DI
    public HomeController(IActionResultHelper resultHelper)
    {
        this.resultHelper = resultHelper;
    }

    public ActionResult Index()
    {
        return this.resultHelper.Json(new { message = "That's a 'Poco' controller!" });
    }
}

Quest'ultimo scenario è molto interessante perchè introduce un'altra novità sulla vnext, ossia la Dependency Injection (io ne sono addicted) che si potenzia ancor di più e mette a disposizione un set di librerie che "wrappano" i Framework più comuni come Autofac, Ninject, Structuremap, Unity ed il mio preferito (ed inimitabile) Windsor Su github trovate il sorgente di queste librerie.

Rimanendo sulla parte di sviluppo, le Aree di MVC, che nella versione precedente venivano registrate invocando il metodo

AreaRegistration.RegisterAllAreas

ora vanno registrate tramite routing ed un apposito attributo, come mostrato di seguito:

Routing:

//UseMvc è un extension method legato ad OWIN
app.UseMvc(routes =>
{
    routes.MapRoute(
        name: "AreasRoute",
        template: "{area}/{controller}/{action}");

    routes.MapRoute(
        name: "Default",
        template: "{controller}/{action}/{id?}",
        defaults: new { controller = "Home", action = "Index" });
});

Registrazione Area:

namespace MySample.Areas.Controllers
{
    [Area("Books")]
    public class HomeController : Controller
    {
        // Books/Home/Index
        public ActionResult Index()
        {
            return View();
        }
    }
}

Alcune risorse utili

Durante il Tech-ed sono state mostrate alcune di queste funzionalità, come potete vedere nei due video di seguito:

Di seguito invece trovate una serie di link con degli esempi di applicazioni sviluppate con il vnext:

Che dire? Veramente tante novità, bisogna solo trovare il tempo di gioarci un po'. Have fun.

Codemotion 2014

2014-03-31T00:00:00+00:00

Per la prima volta quest'anno ho la fortuna ed il piacere di partecipare come speaker al Codemotion Roma. Per chi non lo conoscesse è una delle più importanti conferenze europee (Madrid, Telaviv, Milano, Matrid ed ovviamente Roma) rivolte agli sviluppatori.

Ovviamente non potevo che non parlare di qualcosa riguardante lo sviluppo web ed in questo caso Web API.

Arrivo a questo evento molto carico, con parecchia voglia di condividere un'esperienza che mi ha occupato negli ultimi sei mesi, di cui la gran parte sullo sviluppo di API.

L'agenda è molto ricca e piena di colleghi super bravi e di argomenti super cool, quindi direi che non potete mancare.

Ci si vede a Roma!

Utilizzare CORS con Web API 2.0

2014-02-18T00:00:00+00:00

Con la versione 2.0 delle Web API è stato introdotto il supporto alle richieste cross domain, più comunemente chiamate CORS (Cross-Origin Resource Sharing).

Normalmente non è possibile effettuare richieste HTTP via Javascript da un source il cui dominio è differente da quello dell’endpoint chiamato. Tradotto in soldoni, se il nostro Javascript si trova su http://www.miosito.it/Index.html non è possibile chiedere informazioni al sito http://www.tuosito.it/.

I motivi sono semplicemente di sicurezza, e servono ad impedire che qualcuno possa attingere a informazioni personali tramite un JS “maligno”.

Chiarito il perché di questo blocco, a volte può risultare necessario effettuare questo tipo di chiamate, e le strade possono essere diverse a seconda dei browser che si vogliono supportare. La prima ed universale soluzione è comunicare via JSONP. Questo approccio è molto facile da utilizzare e tutti i browser lo supportano; l’unico incoveniente è il VERB della chiamata http che può essere solo in GET, con il conseguente limite dei caratteri utilizzabili.

Se, al contrario, vogliamo inviare parecchie informazioni non possiamo utilizzare questo approccio (una soluzione in questo caso è “proxare” lato server le chiamate JS e ribaltarle all’endpoint).

Un'altra soluzione è l’utilizzo del CORS, che da il titolo a questo articolo. In pratica la comunicazione CORS stabilisce, tramite delle recole che vedremo più avanti in questo articolo, che un client può accedere a delle informazioni da un dominio differente a condizione che il server lo consenta.  Ovviamente per far ciò è necessario che il browser permetta questo tipo di chiamata, cosa che purtroppo non è del tutto scontata. Internet Explorer in questo è stato fermo per molto tempo e, solo a partire dalla versione 10, ha introdotto il supporto completo a questo meccanismo di comunicazione.

La tabella seguente (http://caniuse.com/cors) mostra il supporto al CORS dai vari browsers

ci sono dei workaround che permettono di sfruttare CORS anche con IE 8/9 ma con alcuni limiti sui VERB della chiamata (maggiori info qui )

Ora che abbiamo chiarito cos’è il CORS, è arrivato il momento di configurarlo utilizzando uno tra questi browsers: IE10/11, Chrome (tutte le versioni), Firefox dalla 3.5+ e Safari 4+.

A questo punto abbiamo bisogno di due progetti, uno per il client ed uno per il server, entrambi “hostati” su domini differenti (nel mio esempio ho sfruttato i websites di azure, quindi ho http://imperdemo.azurewebsite.net per la parte server e http://imperclient.azurewebsite.net per la parte client).

Applicazione Server

Una volta creato il nostro progetto, come prima cosa è necessario abilitare il CORS per i domini che riteniamo "trusted", quindi nel mio esempio imperclient.azurewebsite.net, nel Global.asax.cs

Se avete utilizzato il template di default di Visual Studio, il vostro golbal.asax.cs dovrebbe essere più o meno come questo.

public class WebApiApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();
        GlobalConfiguration.Configure(WebApiConfig.Register);
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
    }
}

Da qui il file da modificare è quello contenente la configurazione delle Web API, quindi "WebApiConfig.cs" contenuto nella folder "App_Start".

N.B.: Prima di moficare il codice è necessario installare il corretto NuGet Packages; di fatto il template di Visual Studio delle Web API "as is" non contiene il package per il CORS, che va quindi installato manualmente.

PM> Install-Package Microsoft.AspNet.WebApi.Cors

Una volta che tutti gli "ingredienti" sono pronti, non ci resta che abilitare il CORS a livello applicativo e specificare per ogni singolo controller i "trusted" domain così:

using System.Web.Http;

namespace imperugo.webapi.cors.server
{
    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            // Web API configuration and services
            config.EnableCors();

            // Web API routes
            config.MapHttpAttributeRoutes();

            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }
    }
}

Mentre il nostro ValueController risulta così:

using System.Collections.Generic;
using System.Web.Http;
using System.Web.Http.Cors;

namespace imperugo.webapi.cors.server.Controllers
{
    [EnableCors(origins: "http://imperclient.azurewebsites.net", headers: "*", methods: "*")]
    public class ValuesController : ApiController
    {
        // GET api/values/5
        public string Get()
        {
            return "This is my controller response";
        }
    }
}

La parte importante di quest'ultimo blocco di codice è l'attributo EnableCors dove viene specificato l'url accettato per la richeista, gli headers ed i vari metodi.

Se non si vuole "aprire" un intero controller a delle chiamate Cross Domain, è possibile utilizzare l'attributo anche solo sulla singola Action oppure lasciare l'attributo sul controller e disabilitare una singola Action tramite l'attributo DisableCors

Applicazione Client

A questo punto, dato che la parte server è stata completata, non ci resta che creare un'altra applicazione con il compito di chiamare le nostre API appena create e deployate sul nostro server.

Il codice sottostante è un semplicissimo codice javascript, quindi può risiedere anche su una semplice pagina .html, senza la necessità di creare un'applicazione server side.

La pagina HTML sarà così composta:

<div class="jumbotron">
    <h2>Test CORS (Cross-origin resource sharing)</h2>
    <p class="lead">
        <a href="#" class="btn btn-primary btn-large" id="testButton">Test it now&raquo;</a></p>
    <p>
    <p id="response">
        NoResponse
    </p>
</div>

con il seguente codice javascript:

<script language="javascript">
    var feedbackArea = $('#response');
    $('#testButton')
        .click(function () {
            $.ajax({
                type: 'GET',
                url: 'http://imperdemo.azurewebsites.net/api/values'
            }).done(function (data) {
                feedbackArea.html(data);
            }).error(function (jqXHR, textStatus, errorThrown) {
                feedbackArea.html(jqXHR.responseText || textStatus);
            });
    });
</script>

Se abbiamo fatto tutto correttamente, non ci resta che deployare l'applicazione server e quella client. Se utilizzate il template di Visual Studio, quest'ultima dovrebbe apparire così:

Il tutto dovrebbe dare un risultato tipo il seguente:

Al contrario se qualcosa non va, è necessario ricontrollare i punti sopra.

Come funziona

Il funzionamento del CORS è un semplice gioco di HEADERS tra il chiamante ed il server che riceve la risposta.

Il browser (il client) aggiunge nell'header della chimata un'informazione riguardo al dominio corrente (imperclient.azurewebsites.net nel mio caso) con la chiave Origin.

Il server a sua volta verifica che tale valore sia tra quelli trusted e risponde con un'altra informazione (sempre nell'header) con la chiave Access-Control-Allow-Origin

Se i due valori "matchano" allora il browser utilizza la risposta, altrimenti si avrà un errore.

In questo screenshot potete vedere l'header della richiesta e della risposta http, con evidenziati i valori utilizzati per il confronto

Di seguito invece il classico errore che restituisce Chrome nel momento in cui il CORS non funziona correttamente

Conclusioni

Per me che amo "spezzare" le mie applicazioni con un layer di API tra il front-end ed il backend, il CORS è una gran comodità, peccato purtroppo la non completa compatiblità con tutti i browser.

La demo di questo sito è disponibile qui

I'm back!

2014-01-27T10:08:10+00:00

Ultimamente ho ritrovato un po’ la passione ed il tempo per lavorare sul blog, specie quello italiano. Devo ammettere che è passato davvero molto dall’ultima volta che ho scritto, e di cose ne sono successe: un ruolo nuovo a lavoro e un bambino fantastico.

Quindi si riparte, ho aggiornato il blog (nell’aggiornarlo ho cancellato i commenti per sbaglio, sorry) e gli ho dato una nuova veste grafica. Nelle prossime settimane pubblicherò diversi post sullo sviluppo web, la mia passione da sempre, ma non volevo riaprire il blog italiano subito con qualcosa di tech senza prima “chiacchierare” e, se volete, ripresentarmi.

Quindi, dato che ho già detto cosa mi è successo in questo anno fantastico, ho deciso di cominciare facendo un po’ di “pubblicità” al mio amico Matteo, che ha scritto un libro spaziale sullo sviluppo Windows Phone. Sottolineo la parola spaziale perché è riuscito a far capire ad uno come me, che di sviluppo mobile sa praticamente nulla, come fare un’app su Windows Phone (sinceramente mi ha anche aiutato a capire alcuni aspetti dello sviluppo su Windows 8).

Normalmente non amo i libri di molte pagine, perché a volte una tecnologia diventa obsoleta prima che finisco di leggerlo (ammetto che è un mio limite). Sono pochi i libri di un certo peso (inteso come numero di pagine) che sono riuscito a leggere con costanza e voglia.

Questo sicuramente è uno di quelli (insieme ai libri del mitico Dino Esposito).

Se siete anche solo minimamente interessati al mondo mobile, specie su tecnologia Microsoft, non potete non leggerlo.

Ovviamente lo trovate su Amazon qui.

override.tostring.it

2012-06-19T16:15:00+00:00

Anche se non come speravo, ce l’ho fatta. Il mio blog in inglese è ufficialmente online.
Il dominio è alquanto particolare per noi tecnici: override.tostring.it . Lo stile del blog è lo stesso, quindi principalmente web, ma con la speranza di tornare a bloggare con la stessa frequenza di un anno e mezzo fa.

Per chi mi segue, il blog in inglese non sarà una replica di quello italiano, quindi potrete trovare contenuti esclusivi della versione inglese e viceversa.
Purtroppo il tempo non mi permette di scrivere un post in entrambe le lingue, ma di sicuro alcuni post saranno presenti in forme differenti su entrambi i blog.

Purtroppo il blog gira su Wordpress. Dico purtroppo non per parlare male di Wordpress ma perché non sono riuscito a trovare il tempo di creare una build stabile di Dexter.
Spero di trovare il tempo (o i collaboratori) per arrivare ad una buona build e migrare il tutto.

Tornando al blog, le idee sono tante e le scoprirete nei mesi a seguire, quindi…. Stay tuned!

Website: override.tostring.it
Rss: http://feeds.feedburner.com/override/tostring/it

Here we go….Web.NET Conference Europe

2012-04-23T15:55:53+00:00

Dopo l’annuncio, prima via Twitter e poi tramite il blog di Simone, eccomi qui a “sponsorizzare” la mia prima conferenza da organizzatore e non da speaker.

Se siete appassionati di web e volete vedere/conoscere come il mondo dello sviluppo web si sta evolvendo, non potete mancare.

Salvo cambiamenti nei prossimi giorni la conferenza si terrà ad ottobre - non abbiamo ancora le date ufficiali per via della location - e al 95% siamo su Milano.
La conferenza è Europea, quindi le sessioni saranno in Inglese, e dovrebbero esserci diversi speaker internazionali.

Giusto per darvi un assaggio di cosa si parlerà, eccovi un estratto:

“Advanced JavaScript frameworks, HTML5, REST frameworks, cloud, lightweight http servers, real-time web, low-cerimony web frameworks, and much more...
both on .NET and other technologies”

Abbiamo creato una pagina di lancio dove è possibile registrarsi (grazie alle quasi 120 persone che lo hanno già fatto), un account Twitter @webnetconf (l’hashtag è #webnet12) ed una pagina Facebook.
Nei prossimi giorni comunicheremo location e date ufficiali.

Se vi sentite parte del futuro del web, preparate le vostre proposte perché la Call For Paper sta arrivando.

Stay tuned!

There's an app for that

2012-04-19T16:00:00+00:00

Negli ultimi tempi, non essendo riuscito a bloggare con constanza a causa dei molti impegni, non ho avuto modo di comunicare l’esistenza di un’applicazione di tostring.it per Windows Phone.

L’applicazione è nello store da diversi mesi, è ovviamente gratuita e la potete scaricare qui. Quello che offre è piuttosto prevedibile: gli ultimi post e le stupidaggini che scrivo su Twitter J.

L’app è “Mango enabled” ed offre la possibilità di avere le notifiche “tile” e “toast” con un check periodico del feed del blog (ovviamente potete disabilitare il tutto).

Questa applicazione non esisterebbe se non fosse per il buon Matteo, quindi un grazie è d’obbligo.
Cosa curiosa, che ovviamente mi ha fatto molto piacere, è stato scoprire che oggi (quindi ieri per chi legge il post) l’applicazione è tra le feature app del marketplace, come potete vedere dallo screenshot seguente:

Qui alcuni screenshot dell’app:

Buon download!

I Bundle di ASP.NET MVC 4

2012-04-17T16:00:00+00:00

L’ultima release (attualmente in beta) di ASP.NET MVC, di cui abbiamo visto alcune novità qui e qui, introduce veramente molte feature interessanti, una delle quali è rappresentata dai Bundle. Ormai noi tutti conosciamo l’importanza di ridurre al minimo il numero di richieste dal client verso il server. Quando parliamo di riduzione delle richieste, includiamo un po’ tutto: dai fogli di stile, ai javascript, e magari anche i dati tramite l’utilizzo di AJAX.

Per i primi due viene utilizzata la tecnica del “combine” e “minify” di più file in un’unica richiesta. Questo approccio consiste nel raggruppare tutti i files dello stesso tipo in un unico file, e nel rimuovere tutti gli spazi e commenti non necessari.

Tradotto in soldoni, tutte queste richieste che abbiamo nella pagina :

[xml] <script src="/Scripts/jquery-1.6.2.min.js"></script> <script src="/Scripts/jquery-ui-1.8.11.min.js"></script> <script src="/Scripts/jquery.validate.min.js"></script> <script src="/Scripts/jquery.validate.unobtrusive.min.js"></script> <script src="/Scripts/knockout-2.0.0.js"></script> [/xml]

Diventano una sola

<script src="/Scripts/combined.js"></script>

Ovviamente lavorare con un file unico, che sia questo un file javascript o css, risulta un po’ scomodo e, proprio per questo motivo, esistono diversi tool/framework che agevolano la creazione di un unico file a runtime o compile time.

Con ASP.NET MVC 4 effettuare il “combine” e “minify” è veramente semplice: basta utilizzare un apposito metodo ed il gioco è fatto.

Guardiamo il seguente codice:

[xml] <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/css")" rel="stylesheet" type="text/css" /> <script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Scripts/js")"></script>[/xml]

È importante sapere che non tutti i files presenti nella folder specificata saranno inclusi nell’output del file, ma bensì solo quelli registrati nel bundle. In un prossimo post vedremo come creare bundle custom in modo da includere differenti file in differenti folder.

Stay tuned!

Il 3D sbarca anche sul web

2012-04-06T16:00:00+00:00

Questa volta non stiamo parlando di animazioni 3D per il web, bensì per lo sviluppatore e non servono gli occhialini J.

Per molti anni Firebug è stato sicuramente lo strumento più apprezzato dagli sviluppatori front end. Ad oggi tutti i browser integrano un qualcosa di simile e, nell’ultima versione, Firefox ha aggiunto un’interessantissima novità, la visualizzazione 3D della struttura del sito.

Per capire a cosa mi sto riferendo, guardate questo screenshot :

Per attivarla basta fare tasto destro sulla pagina, “Inspect Element” e premere il pulsante 3D come da screenshot:

Una volta entrati nella modalità 3D è possibile “zoomare”, ruotare e selezionare elementi con il semplice utilizzo del mouse.

Ciauz

Il Tilde Slash di Razor V2

2012-04-04T16:00:00+00:00

Su segnalazione del buon Andrea, ho scoperto che, oltre ai “conditional attributes”, Razor introduce un’altra novità chiamata “Tilde Slash” ossia “~/”.

Il concetto è simile a quello espresso in un mio vecchio post su Spark (vedi qui), con la differenza che in Spark si può specificare un dominio differente (molto comodo se si usa CDN).

In ogni caso l’utilizzo del Razor, con il Tilde Slash, aiuta lo sviluppatore nella scrittura del codice prendendosi in carico l’onere di risolvere automaticamente la url, eliminando così le noiose ripetizioni del ResolveUrl.

Dando un occhio al codice, questo markup

<img src="@Url.Content("~/Content/mylogo.png")" />

con Razor v2 diventa semplicemente questo

<img src="~/Content/mylogo.png" />

Beh comodo no?

What’s new in Razor v2

2012-04-03T16:00:00+00:00

Nel rilascio di ASP.NET MVC 4 è inclusa anche la nuova release dell’ormai diffusissimo Razor View Engine. Per chi non lo sapesse Razor è un “framework” che offre la possibilità di scrivere il codice presente nelle view con una sintassi differente da quella delle classiche pagine ASP.NET.

Prima di Razor, nel mondo Microsoft, l’utente era abituato ad utilizzare il WebFormViewEngine anche sotto ASP.NET MVC ma, essendo MVC molto orientato al testing, la scelta di creare un’alternativa è quasi d’obbligo.

Di fatto Razor non ha più una dipendenza verso System.Web.UI.Page, e di conseguenza dall’ HttpContext, Web Server (IIS), etc.

Questo permette allo sviluppatore di poter scrivere unit test anche per le View (quanti di voi lo hanno mai fatto?).

Dopo questa premessa sulla storia di Razor, andiamo a vedere cosa offre la nuova release J.

Al momento l’unica novità di rilievo che ho riscontrato è quella che dal team viene chiamata con il nome “Conditional Attribute”, ossia la possibilità di renderizzare o no un determinato attributo, il cui valore è dinamico, e quindi legato ad una variabile.

Per renderla più semplice, diamo un’occhiata al seguente codice:

<!-- Nome della classe css presa da una variabile -->
<p class="@myCssClass">.....</p>


<!-- markup necessario in caso la variabile sia nulla -->
<p>.....</p>

Come potete vedere, la variabile myCssClass viene utilizzata per impostare la classe css appunto, in base ad un qualcosa (un evento, un settaggio, etc) gestito server side.

Ma cosa succede se dovete gestire anche la possibilità di non impostare la classe?
Precedentemente a Razor V2 l’approccio sarebbe stato più o meno questo:

@{
    var myCssClass = (bool)ViewBag.IsBol ? "boldClass" : null;
}

@if(myCssClass != null){
    <p class="@myCssClass">@ViewBag.Text</p>
}
else{
    <p>@ViewBag.Text</p>
}

Al contrario, con la nuova release di Razor, diventa tutto più semplice. Se impostate il valore della variabile myCssClass a null l’attributo non viene renderizzato, in caso contrario si.

<p class="@myCssClass">@ViewBag.Text</p>

Bisogna prestare attenzione al fatto che il contenuto string.empty (nel caso di una stringa) renderizza ugualmente l’attributo, quindi solo null impedisce il rendering.

Nel caso di value type tipo il booleano, la situazione non cambia molto. In questo caso il true renderizza l’attributo checked, mentre il false no.

<!-- codice con -->

@{
    ViewBag.IsBol = true;
}

<input type="checkbox" checked="@ViewBag.IsBol" />

Razor Rulez!

Review: Architecting Mobile Solutions for the Enterprise

2012-03-15T16:30:00+00:00

È la prima volta che mi capita di fare la review di un libro e, per essere alla prima esperienza, devo dire che ho l’opportunità di farlo per uno dei migliori autori internazionali che il mondo tecnico possa avere, il Super Dino Nazionale aka Dino Esposito.

Il libro in questione è “Architecting Mobile Solutions for the Enterprise” e, come potete intuire dal nome, parla di mobile application.
Nonostante io abbia una predilezione verso le applicazioni web, questo libro mi ha subito affascinato perché affronta tematiche molto web oriented come HTML5, jQuery, etc per sviluppare applicazioni mobile.

Nell’ultimo periodo in azienda sono stato coinvolto nello sviluppo di applicazioni con queste caratteristiche (nel mio caso Sencha Touch al posto di JQuery Mobile, ma poco cambia) ed ho avuto modo di toccare con mano quanto Dino spiega.

Tornando al libro ho letto il capitolo sul responsive design, sia client-side tramite le media queries che server side con l’utilizzo di Wurfl, e devo dire che mi è piaciuto parecchio.

Dino è riuscito come sempre ad arrivare in profondità di concetti complessi, spiegandoli tuttavia in maniera del tutto semplice, il che rende ancor più appetibile il libro.

Purtroppo non posso entrare molto nei dettagli in quanto il libro non è ancora disponibile, ma potete effettuare il pre-ordine da qui.

Problemi con Razor e Visual Studio 2011

2012-03-12T17:05:00+00:00

Chi come me si sta divertendo nel testare ASP.NET MVC 4 e lo sta facendo con Visual Studio 2011, avrà sicuramento riscontrato dei problemi di stabilità da parte dell’editor Razor che causa continui freeze della UI.

Tale problema non si verifica ogni qualvolta si cerca di editare una view realizzata con Razor, ma quando si cerca di indentare il codice HTML.
Inizialmente avevo attribuito il problema a Resharper, in quanto la versione installata è una super preview ma, una volta disinstallato quest’ultimo, ho notato che il problema persisteva e a quel punto è scattato il piano B: Google.

A primo colpo ecco la soluzione:

Basta andare su Tools => Options => Text Editor => HTML => Tab ed impostare l’indenting option su Smart.

A questo punto Visual Studio torna a funzionare senza particolari crash e con Resharper J

Fonte: http://blogs.msdn.com/b/webdevtools/archive/2012/03/06/visual-studio-11-beta-razor-editor-issue-workaround.aspx

Internet Explorer si aggiorna

2012-02-23T18:00:00+00:00

Oggigiorno siamo circondati da una quantità di device a dir poco imbarazzante, dalle centinaia (ed anche troppe) distro di Android, fino ad arrivare a computer Windows based. All’interno di ognuno di questi device è presente un browser che, a causa della velocissima crescita dell’HTML5, richiede continui aggiornamenti per stare al passo con le specifiche che si stanno man mano stabilizzando all’interno del W3C.

Tempo fa Google con Chrome ha introdotto una sorta di “Silent update”, che consiste in un “servizio” Windows che ha il compito di controllare ed installare eventuali aggiornamenti del browser.
L’aspetto positivo di questo approccio è che l’utente non deve preoccuparsi di verificare se esiste una patch o una nuova versione del browser, mentre il lato negativo è il non controllo di ciò che avviene sulla nostra macchina (l’utente non riceve notifica di nessun aggiornamento).

Questa strada si è dimostrata molto positiva, e di fatto tutti gli utenti con Chrome hanno installato l’ultima versione (17.x in questo momento), tant’è che Microsoft ha deciso di intraprendere lo stesso percorso aggiornando automaticamente tutte le versioni di Internet Explorer alla 9 in maniera del tutto automatica.

Tale aggiornamento offre sicuramente un set di vantaggi lato utente indiscutibili, dalle performance alla sicurezza (Internet Explorer 9 si è dimostrato il browser più sicuro), oltre al supporto per HTML5.

Personalmente sono molto curioso di sapere se Microsoft sfrutterà questa tecnica anche per aggiornare IE9 con un subset di features HTML5 che questo non supporta. Di fatto Microsoft ha deciso di intraprendere una strada diversa da altri vendor tipo Google, implementando solo le specifiche mature i cui cambiamenti da qui alla chiusura dell’HTML5 saranno minimi se non nulli.
Fortunatamente/sfortunatamente (a seconda dei punti di vista) dall’uscita di IE9 molte features (websocket, fileapi, offline, input type, etc) sono “salite di grado” e risultano ora mature, tanto da poter essere promosse su un browser con IE9. La casa di Redmond ha dimostrato il suo interesse verso queste feature, e di fatto possiamo testarle su IE10 e Win8, quindi non mi stupirebbe se ci fosse un upgrade anche verso questo aspetto.

Maggiori informazioni su IE9 e l’auto update sono disponibili in questo bellissimo post.

Ciauz

http o https?

2011-11-04T17:15:00+00:00

Quando ci troviamo a navigare pagine web con connessione protetta - e per connessione protetta intendo tramite il protocollo https - ed alcune delle sue risorse (immagini, javascript, css, etc) non puntano ad un indirizzo sicuro, rischiamo di avere una fastidiosa notifica da parte del browser che ci obbliga a dare il consenso per mostrare i contenuti non sicuri.

Diamo un occhio all’html seguente per capire meglio di cosa stiamo parlando:

<meta name="description" content="" />
    <meta name="author" content="" />
    <link rel="stylesheet" href="http://mysite.com/css/mystyle.css" />
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js" type="text/javascript"></script>
    <script type="text/javascript" src="http://mysite.com/js/libs/modernizr-1.7.min.js?v=1.5.0.21"></script>

Finché navighiamo la pagina sopra in http non c’è nessun problema ma, se proviamo ad aprire la stessa pagina in https, un buon browser dovrebbe notificarci il rischio a cui andiamo incontro (sia il css, sia jquery puntano ad una connessione http e non https).
Per evitare il problema ci basta cambiare le url da http://.... ad https://..... nel caso la connessione corrente sia in https, e viceversa.
Ovviamente questo cambio deve essere automatico e, riempire il codice di html di if che cambiano il protocollo, non è la soluzione corretta!

Fortunatamente esiste un rimedio più semplice e pulito che consiste nella rimozione dall’url della parte relativa al tipo di protocollo; quindi dobbiamo rimuovere http: o https: e lasciare semplicemente il // come mostrato di seguito.

[xml] <meta name="description" content="" /> <meta name="author" content="" /> <link rel="stylesheet" href="//mysite.com/css/mystyle.css" /> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js" type="text/javascript"></script> <script type="text/javascript" src="//mysite.com/js/libs/modernizr-1.7.min.js?v=1.5.0.21"></script> [/xml]

A questo punto sarà il browser a “switchare” in automatico dalla connessione http/https in base a quella corrente.

Questa tecnica prende il nome di “network-path reference” (maggiori info qui) e funziona anche per i css, come potete vedere sotto:

[css].mycssclass { background: url(//mysite.com/myimage.jpg); }[/css]

Inoltre questo approccio funziona egregiamente con tutti i browser, tranne che con Internet Explorer 7 e 8 dove, solo per i tag o @import, il download della risorsa avviene due volte (maggiori info qui).

Figo no?

Attenzione al %20 nelle url

2011-11-02T17:15:00+00:00

Giorni fa ho avuto a che fare con un piccolo problema riguardante le url di una mia applicazione web. In pratica mi trovavo con delle richieste verso un indirizzo tipo il seguente “/mycontroller/myaction/myid%20” (per chi non lo sapesse %20 equivale allo spazio) che, non per volere mio, restituiva sempre un 404 invece di dirottare la chiamata verso il mio controller.

Come si può ben immaginare il problema è dovuto a quel %20 che, per qualche strano motivo, non viene digerito dal sistema di routing di ASP.NET 3.5 SP1.

Ovviamente un url del genere può sembrare raro in un’applicazione web, e molti di voi si chiederanno il perché di tale indirizzo, quindi provo a spiegarlo di seguito .

La settimana scorsa mi trovavo a sviluppare un textbox autocomplete con jquery per un’applicazione ASP.NET MVC; sfortunatamente le features richieste non erano coperte dalle migliaia di esempi presenti in rete, quindi mi sono dovuto armare di coraggio e, a colpi di javascript e json, sono riuscito a realizzare la textbox che trovate qui.

All’apparenza il funzionamento è identico a quello di tutte le textbox con autocomplete. Per capire il problema sopra mostrato, non è necessario addentrarsi nel codice javascript o nel modo in cui ho implementato la textbox, ma basta capire cosa fa per mostrare i suggerimenti all’utente.

Nel momento in cui l’utente digita qualcosa, questo qualcosa viene inviato ad una Action di un controller MVC che non fa altro che eseguire una query con un like e restituire i primi 7 elementi. Questo vuol dire che ogni volta in cui l’utente digita una lettera all’interno della textbox, via javascript viene inviato il testo digitato per eseguire l’operazione sopra descritta.
Passando alla pratica, quando l’utente digita “Mario”, una chiamata tipo la seguente “/Search/PersonSuggestion/Mario” viene effettuata.

Supponiamo ora di voler raffinare la ricerca in quanto troppe persone si chiamano Mario, e noi vogliamo trovare il classicissimo Mario Rossi.

Nel momento in cui l’utente deve aggiungere “ Rossi” (spazio Rossi), la chiamata diventa più o meno così:

“/Search/PersonSuggestion/Mario%20Rossi”

Ovviamente prima di arrivare a digitare Rossi c’è uno spazio, quindi verrà effettuata una chiamata come questa: “/Search/PersonSuggestion/Mario%20”

Ed eccoci arrivati al problema iniziale: il 404 da parte del server.

Il motivo risiede nel fatto che il runtime di ASP.NET effettua una validazione delle url in entrata, applicando le stesse regole del filesystem. Questo vuol dire che, così come non possiamo creare una folder con lo spazio alla fine (quindi “Mario “), non possiamo neanche avere un url con lo stesso spazio.

Ovviamente questo tipo di validazione è “aggirabile” grazie ad una proprietà dal curioso nome “RelaxedUrlToFileSystemMapping”, da aggiungere alla sezione HttpRuntime del web.config come mostrato di seguito.

<system.web>
    <httpRuntime 
            requestValidationMode="2.0" 
            executionTimeout="20" 
            requestPathInvalidCharacters="" 
            relaxedUrlToFileSystemMapping="true" />

Ciauz

WPC 2011. Save the date!

2011-10-28T16:30:00+00:00

Anche quest’anno (per il terzo anno consecutivo), ho la fortuna di partecipare come speaker alla più importante conferenza italiana sul mondo Microsoft e non solo.
Specifico il “non solo”, perché proprio io sarò lì per parlare di HTML5 che, come tutti sappiamo, non è una tecnologia Microsoft, ma è sicuramente un percorso importante per il futuro delle applicazione web e non.

Anche il “e non” non è a caso J. Oltre ad una sessione full immersion su HTML5 in cui mostrerò tutto ciò che ad oggi possiamo utilizzare e cosa arriverà a breve, parteciperò sempre come speaker ad un’altra sessione sul data entry in Windows 8 dove, insieme al mitico Salvuzzo, mostreremo come accedere e mostrare dati in un’applicazione Metro UI con C# e HTML5+JS.

Direi che di motivi per non mancare ce ne sono tanti. Se non vi bastano date un’occhiata agli speaker e all’agenda, aggiungeteci che l’early bird è stata prolungata fino al 31 ottobre, e a questo punto non avete proprio più scuse

See you there!

Sincronizzare più folder con DropBox

2011-10-26T16:30:00+00:00

Chiacchierando con amici e colleghi, ho notato che molti fanno uso di DropBox come tool/repository per condividere e “backuppare” le informazioni più importanti. Uno dei motivi per cui ritengo DropBox un ottimo tool è sicuramente il buon funzionamento ed il supporto praticamente a tutte le piattaforme (Windows, Mac, iPhone, Android, etc).

Tuttavia uno dei più grandi limiti di DropBox è la folder di Sync. Una volta installato si ha la possibilità di effettuare il sync ed il backup solo della folder creata dal client, con l’obbligo di copiare tutti i nostri file al suo interno, rinunciando alla struttura presente nel nostro Hard Drive.

Fortunatamente è ora possibile aggirare questo problema scaricando “Drop Box Folder Sync” da qui http://wiki.dropbox.com/TipsAndTricks/SyncOtherFolders

Una volta installato il client, possiamo aggiungere e togliere tutte le folder che preferiamo in qualsiasi parte dell’hard-disk; infatti, cliccando con il tasto destro su una cartella, si noterà l’aggiunta di due nuove voci di menù:

Sync with DropBox;
UnSync with DropBox;

Inutile spiegarne il significato.

Ciauz

Dominio stai lontano dalle mie View

2011-10-25T16:30:00+00:00

Tutti i giorni mi capita di consultare esempi e progetti fatti da altri, sia nel mondo dell’open source che nel mondo del lavoro.

Moltissime volte ho visto applicazioni MVC che hanno il “vizietto” di utilizzare le classi del dominio direttamente dentro le View. Devo ammettere che anche io in passato sono stato tentato - a volte ho anche ceduto - di percorrere questa strada per accorciare i tempi di sviluppo ma, ancora una volta, mi trovo a blaterare su questo errore.

Partendo dalla premessa che noi siamo pagati per sviluppare del buon codice (non credo che mai nessuno vi abbia mai detto – “ti pago, ma scrivi un codice di merda!”), e che non dobbiamo scrivere il codice a nostra comodità perché siamo pigri, volevo ricordare alcuni dei problemi che si posso incontrare utilizzando il dominio nella view:

La view può avere maggior complessità (non è detto che l’entity abbia le info come le vuole la view, e quindi questa deve recuperarle ed adattarle): questo rischia di creare scenari la cui testabilità della view può diventare difficile, se non impossibile;
Query inaspettate. Spesso le entity di dominio sono “proxate” da un O/RM, questo vuol dire che colui che realizzerà la view potrà accedere ad una property che scatenerà a sua volta una query onerosa (magari vuole mostrare il numero di prodotti e fa un count su IList<Product>, finendo con il caricare tutti i prodotti);
Problemi di balancing. Per lo stesso motivo di cui sopra (proxy dell’O/RM), le entity di dominio possono non essere serializzabili, escludendo così la possibilità di effettuare caching sui dati delle view.
Crescita applicativa bloccata. Se all’improvviso, per imposizioni del client o per scelte architetturali, ci si trova nella situazione in cui tutta la logica di accesso ai dati finisce in un servizio e le view non possono arrivare direttamente all’O/RM, siamo costretti a riscrivere tutta la parte dinamica delle view attingendo ai DTO restituiti dal servizio.

Capisco la comodità e la velocità nell’utilizzare il dominio nella view, ma fidatevi, alla lunga paga la strada corretta!

Ciauz