http o https?
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:
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.
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:
.mycssclass { background: url(//mysite.com/myimage.jpg); }
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
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!
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
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
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
La compilazione di ASP.NET
Il web.config è sicuramente familiare a tutti noi sviluppatori web, ma ci sono alcuni attributi che valgono la scrittura di un post ad hoc.
Oltre al classico connectionstrings e appsettings, in tutti i file di configurazione per applicazioni web esiste una sezione chiamata “compilation”, che permette di impostare un set di parametri che andranno ad influenzare la compilazione delle nostre pagine web.
Alcuni di questi attributi parlano da soli - inutile spiegare a cosa serve l’attributo debub=”true” - , ma ce ne sono altri che spesso si tralasciano o non si conoscono affatto.
Per esempio recentemente ho scoperto l’esistenza dell’attributo optimizeCompilations che, se impostato su true, può aumentare in maniera significativa i tempi di compilazione delle pagine web (maggiori informazioni qui http://blogs.msdn.com/b/davidebb/archive/2009/04/15/a-new-flag-to-optimize-asp-net-compilation-behavior.aspx).
Anche l’attributo batch ha lo scopo di migliorare le performance di compilazione ma, a differenza dell’attributo optimizeCompilations, questo è impostato di default su true, quindi possiamo omettere questo attributo nel nostro file di configurazione.
Un altro interessante attributo è numRecompilesBeforeAppRestart che, se impostato con dei valori corretti, può evitare alcuni noiosi restart dell’applicativo.
In ogni caso il mio preferito resta l’attributo tempDirectory 
. Questo attributo permette di specificare la directory dove verranno salvati i file temporanei di compilazione.
Il perché mi piace particolarmente questo attributo è dovuto al fatto che uso un RAM Disk (personalmente uso questo http://memory.dataram.com/products-and-services/software/ramdisk) e, impostando la compilazione dei file di ASP.NET su questo particolare drive, si ottengono delle performance notevoli, specie in fase di startup.
Concludo con un pezzo della mia configurazione :
<compilation tempDirectory="G:\aspnet.temp\"
optimizeCompilations="true"
batch="true"
debug="true"
defaultLanguage="c#"
numRecompilesBeforeAppRestart="250"
targetFramework="4.0">
<assemblies>
<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</assemblies>
</compilation>
Ciauz!
Alcuni webcast su ASP.NET MVC e molto altro.
Con il mio consueto ritardo (scusate ma è un periodo pienissimo), volevo postare alcuni webcast miei e di Simone Chiaretta riguardanti il mondo del web developer in generale.
Gli argomenti trattati infatti coprono la parte di sviluppo, ma anche argomenti come SQL CE con Entity Framework Code First ed IIS Express.
Come sempre feedback e domande sono i benvenuti, anche in base alle vostre esperienze!
Buona Visione
IIS Express
ASP.NET MVC Razor
ASP.NET MVC 3 - Dependency Injection(DI)
ASP.NET MVC 3 - SQL CE 4
ASP.NET MVC 3 - Le novità
E son Tre!
Nonostante lo scherzetto di Google (vedi immagine sotto), anche quest’anno ho ricevuto la mail che mi comunicava il rinnovo dell’Award Microsoft MVP su ASP.NET/IIS.
Inutile parlare ancora di quanto è un piacere per me far parte di questo gruppo che, oltre ad essere un insieme di professionisti, si sta dimostrando anche un insieme di amici.
Un super grazie al mio lead ed amico Alessandro!
Grazie ancora a tutti.
Troppe novità tutte insieme (2 di 2)
Nel precedente post avevo elencato le principali novità presentate durante la keynote del primo giorno del //build, conferenza di Microsoft orientata principalmente su Windows 8, ma non solo.
Anche con questo post arrivo in netto ritardo rispetto a molti altri blogger, ma purtroppo non ho avuto modo di vedere la presentazione prima di oggi; quindi eccomi qui a parlare di Azure, MVC4 e Visual Studio 2011, i protagonisti della seconda Keynote.
MetroUI+Azure
La prima demo ha mostrato come lo sviluppo di applicazioni Metro UI non si limiti al semplice HTML+JS o C#, ma è possibile sfruttare le potenzialità del Cloud Computing (Azure nel caso di Microsoft) per creare applicazioni molto più spinte. Nell’esempio è stato mostrato un gioco in cui i due giocatori utilizzavano come device un computer da una parte ed un Windows Phone dall’altra, il tutto in tempo reale. Direi una demo davvero sbalorditiva in quanto apre scenari sicuramente interessanti.
Visual Studio 2011
Già un po’ se ne parlava in rete, però qui viene effettivamente mostrato e le novità sono molte.
In primis i Productivity Power Tools sono integrati nella versione finale di Visual Studio, al contrario di oggi che sono scaricabili come plugin separatamente.
Un’altra interessante feature è il “find matching clones”, che ha lo scopo di trovare blocchi di codice duplicati. Devo dire che questa feature mi incuriosisce veramente tanto: vorrei capire lo scope in cui effettua le ricerche, e di conseguenza capire se si sovrappone ad un qualcosa di molto simile offerto da Resharper.
ASP.NET
Nell’ambito web ci sono veramente tante novità, alcune di notevole interesse, come la possibilità di affiancare del codice Server Side con del codice renderizzato.
Funzione sicuramente utile a capire dove stiamo sbagliando nella costruzione del markup.
Altra caratteristica molto importante è la possibilità di effettuare il minify dei file .js e .css, semplicemente aggiungendo come risorsa la folder: come per magia, a runtime verrà creata un'unica risorsa contenente tutti i file presenti all’interno della folder. In questo modo l’unica accortezza che si deve avere è la creazione delle folder in maniera razionale rispetto alle risorse necessarie.
ASP.NET MVC 4 Developer Preview
Come per Visual Studio e Windows, la next release di ASPNET MVC è ricca di novità, a partire dai nuovi template per il mondo mobile (utilizzando jQuery Mobile) e dal supporto per View differenziate semplicemente utilizzando l’estensione .mobile.cshtml.
Un’altra interessante novità è il supporto alla keyword async di C# 5.0 che, tramite degli attributi, risulta facilmente estendibile e configurabile.
Download:
- ASP.NET MVC 4 for Visual Studio 2010
- ASP.NET MVC 4 for Visual Studio 11 Developer Preview.
- Microsoft® Visual Studio® 11 Developer Preview (Web Installer)
- Windows Azure SDK 1.5 (September 2011)
Troppe novità tutte insieme (1 di 2)
Che il //build fosse una conferenza dalle grandi novità ce lo aspettavamo un po’ tutti, ma che oltre a Windows 8 fossero mostrate tutte le next release dei principali tool e framework mi ha lasciato un po’ spiazzato; talmente spiazzato che questo post esce in ritardo rispetto a molti blogger in quanto ho dovuto metabolizzare tantissime informazioni J.
In ogni caso procediamo con ordine e vediamo tutte le novità lato dev che ci riguardano:
Retrocompatibilità
Steven Sinofsky durante la keynote ha dichiarato che tutte le applicazioni funzionanti in Windows 7 saranno funzionanti anche nella prossima release del sistema operativo. Questo vuol dire che, nonostante le importanti novità che elencherò di seguito, non dobbiamo allarmarci J.
Metro UI, Store ed altre novità
Sicuramente come news principale c’è la nuova Metro UI, ossia una nuova interfaccia inizialmente pensata per il mondo touch, ma poi effettivamente utilizzabile anche da chi come me non ha un device touch. A dimostrazione, il menù start non esiste più e, premendo il pulsate cuore di Windows, si accederà direttamente alla nuova Metro UI, dove è possibile effettuare ricerche o eseguire applicazioni.
Inizialmente questo nuovo comportamento può lasciare l’utente un po’ spiazzato ma poi, una volta abituatisi, risulta molto comodo e pratico.
Oltre ad essere molto reattiva, la parte Metro si può “unire” al classico desktop creando così un’ibrido dove, sulla parte sinistra possiamo tenere un’applicazione Metro Style e dall’altra una comunissima applicazione o il desktop stesso. Oltre a ciò è possibile “pinnare” sulla Welcome Page (e quindi la Metro UI) un po’ tutto, da applicazioni Metro a Visual Studio, un po’ come avviene per Windows Phone.
Per quanto riguarda la parte desktop, rimane (per ora) un po’ tutto come prima, ci sono alcune novità ma diciamo pure che l’habitué Windows non si troverà spiazzato.
Oltre alle novità legate alla UI, ne sono state mostrate parecchie altre: lo Store App (non ancora disponibile se si installa Win8), il Sync dei Settings (sfruttando Windows Live si avranno a disposizione le stesse cose per i differenti device, tablet, pc, phone, etc), Hyper-V direttamente nel sistema operativo, mount delle iso (stile Daemon Tool per intenderci), supporto al multi-monitor migliorato, controllo ortografico su tutto il sistema operativo, un minor consumo della ram (circa il 20% in meno rispetto a Windows 7), un avvio in pochi secondi (dai 4 agli 8 a seconda dell’hardware), un nuovo task-manager e, grazie ad una sorta di hibernate delle applicazioni (zero cicli di clock ma l’applicazione rimane aperta) sembra che la durata della batteria sia migliorata.
Sviluppo.
Con Windows 8 è stato introdotto un nuovo stack chiamato Metro Style che, come è facilmente intuibile dal nome, serve a realizzare applicazioni per la UI Metro. Ovviamente, per garantire la retro compatibilità sopra citata, il classico stack Win32/.NET rimane, ma non sarà possibile realizzare un’applicazione che utilizzi entrambi gli stack. Questo vuol dire che se si vogliono coprire entrambi gli scenari, Metro e Win32, è necessario realizzare due applicazioni.
C/C++, XAML, C#, VB, HTML, Javascript
Chi più ne ha più ne metta! Sono questi i Framework/linguaggi che si possono utilizzare oggi per sviluppare applicazioni metro style, e tutti fanno capo ad un “sotto strato” chiamato WinRT (Windows Runtime) che altro non è che un set di API verso il kernel di Windows.
La slide seguente mostra un po’ più nel dettaglio come è strutturato lo sviluppo in Windows 8.
Come potete vedere, lo XAML ora non è più parte del .NET Framework ma è presente direttamente nel sistema operativo, offrendone così la possibilità di utilizzo anche da linguaggi unmanaged come il C, o il C++.
Un’altra novità che mi ha colpito in questa slide è l’assenza di Silverlight per lo sviluppo di applicazioni Metro Style, rilegandolo così nell’angolino in basso a destra.
HTML + Javascript
Direi che è il vero protagonista (devside)! Di fatto ha molto più spazio ed importanza rispetto a Silverlight e apre nuove opportunità a tutti gli sviluppatori di frontend (HTML/Javascript). Ad oggi conosco diversi sviluppatori di frontend che, dopo la presentazione di Windows 8, si sono dimostrati interessati a sviluppare applicazioni per Windows.
Quale linguaggio scegliere?
Beh difficile dirlo. In primis lo skill la fa da padrone. Se si è abituati a scrivere solo codice C# (non tutta la BCL è disponibile per le Metro Apps) e non si conosce il Javascript, la risposta vien da sola J.
Personalmente vedo una grande crescita del C++ nello sviluppo di applicazioni Windows e, volendo azzardare un po’, scegliere il Javascript+HTML5 per applicazioni che non necessitano di performance o calcoli troppo complessi, ed il C++ per le applicazioni in cui la velocità è il primo pillar, può essere la scelta giusta.
Un altro vantaggio del C++ e della coppia HTML+JS è la non necessità del .NET Framework. Questo offre vantaggi in fase di deploy e dipendenze.
WinRT
Sopra ho accennato di cosa si tratta, ma è giusto approfondire un po’, riportando alcuni punti scritti da SuperRaf in questo post.
-
È il Windows Runtime che espone le funzionalità del sistema operativo in modo Object Oriented.
-
Non è codice managed e non necessita del .NET Framework. (Javascript, HTML, C e C++ non lo richiedono)
-
Ha delle "Projection" che permettono ai vari linguaggi di interagire con il sistema operativo (C++, C#, VB.Net, Javascript)
-
I linguaggi managed sopra WinRT hanno sempre bisogno del CLR e il Framework fornito con Win8 è la versione 4.5
-
WinRT è costruito con tecnologia COM e conserva tutti i relativi meccanismi (IUnknown, AddRef/Release, Apartment per i modelli di threading, la message pump per gestire le STA).
-
È possibile estenderlo, ma solo per una singola applicazione e quindi non condivisibile.
-
Il versioning di WinRT è basato sui concetti COM e prevede le estensioni che verranno nelle future versioni del sistema operativo
Domande, dubbi e perplessità:
- Ma WPF che fine ha fatto?
- Perché Silverlight è stato escluso dalla parte Metro UI?
- Il .NET non la fa più da protagonista come prima?
Un grande passo in avanti e veramente tante novità...non saprei da dove partire! Anzi si, dal download disponibile qui e dalle sessioni qui.
Archive