Oggi pomeriggio ho ricevuto un’e-mail da un tizio, di cui manterrò segreta l’identità. Vi riporto il testo direttamente con uno screenshot dal mio Outlook di qualche minuto fa…

In poche parole, nel registry di questo utente compare il mio nome e quindi si chiede cosa possa aver installato!!! E lo chiede a me???

Non ho proprio idea di come sia finito il mio nome nel suo registry. Un dubbio piccolo piccolo ce l’ho: che Keyzard ci abbia messo lo zampino? Adesso gli rispondo e vediamo un po’ cosa mi dice. Vi farò sapere. Nel frattempo, fate una piccola prova anche voi: aprite regedit e cercate un po’ “Igor Damiani” – non si sa mai che sia finito per caso anche nel vostro PC!

Technorati Tags: Registry

Send to Kindle

Questa volta faccio parlare un altro. Ecco il link da cui ho tratto queste riflessioni.

The browser and all the baggage associated with it is the #1 reason I pushed for and we chose WPF over ASP.NET. ASP.NET was not the issue, the browser is.

Questo punto mi piace particolarmente. I veri problemi della programmazione Web non sono dovuti ad ASP, oppure ad ASP.Net, a PHP, a JSP o al framework di programmazione. Il vero problema è il browser, ovvero il cuore del Web, il mezzo attraverso il quale lo viviamo.

What happens after we deploy an application with 500 forms? We will always have the ongoing headache of customers reporting that, “I just installed (new O/S, new browser, service pack, etc.) and the page does not render as before.” Can you imagine having to touch 500 forms or even 200, just so we can support 2-5 versions of IE?

WPF solutions, like WinForms are not affected by the hosting system. So two, three or four years from now, our WPF application will run just like it did the day the customer received it.

Ci sono degli spunti su Visual Studio e sulle tecnologie, ma preferisco sorvolare.

Do I need to say anything here? Rich interactivity, resolution independence, super fast UI.

WPF takes full advantage of the user’s hardware, especially the monitor. Didn’t think I would list the monitor first, eh? Think user!

With a web application, you really need to “target” a screen resolution. Most of our pages are business forms that users interact with. If we target 1024 x 768 and Mr. Smith gets a new computer with a 22″ wide screen monitor (less than $300 today), his web application will be displayed in the upper left of his screen. Bummer.

With WPF just ViewBox it and boom, the same information displayed utilizing his full screen and he can see the form much better AND without any hacks, or lots of code to make this happen. This is a major selling point for us, considering our target market.

WPF takes full advantage of the users CPU/GPU for processing. Today all our customers can afford an Intel 2 Core Duo system. As all readers of this know, these babies are super fast.

Questo qui sopra è fantastico. Bocciatura completa del Web: dipendenza dalla risoluzione grafica, nessuna possibilità di usare la potenza delle GPU moderne, etc. etc.

With ASP.NET, our customers have to maintain an Intranet site.
With WPF this requirement is removed from the equation.

Fantastico. Preferisco fermarmi, perchè il post originario è davvero lungo, me lo sono letto tutto e sottoscrivo in pieno. Al di là di quello che viene detto, mi piace la logica che ci sta dietro: dal punto di vista dello scrittore del post, il Web non è la piattaforma migliore per deliverare applicazioni, per tutta una serie di motivazioni intrinseche al Web stesso, motivazioni verso le quali non si può fare nulla. Sia chiaro: le cose che dice lui e che io sottoscrivo possono anche essere viste positivamente, ma io proprio non ce la faccio. E’ più forte di me.

Technorati Tags: Web

Send to Kindle

Gli extension method sono una delle novità puramente sintattiche del .NET Framework 3.5. Mi piace chiamarle sintatticamente perchè tecnicamente parlando è possibile ottenere lo stesso risultato con le vecchie versioni del framework. Facendola breve, utilizzando gli extension method è possibile “estendere” un tipo, dotandolo di uno o più metodi, senza creare nuovi tipi, senza la necessità di mettere mano a codice sorgente che magari non avete e – in fin dei conti – senza modificare il tipo originale. Maggiori dettagli su questa pagina di MSDN.

Supponiamo di aver definito un tipo Holiday come segue:

public class Holiday
{
    public string Name { get; set; }
    public DateTime When { get; set; }
}

La classe Holiday espone due proprietà Name e When. Implicitamente il compilatore crea un costruttore parameter-less. Ora: supponiamo di voler esporre un metodo IsPassed(), che ci dice se una certa festa è già passata nell’anno in corso. Se avessi il sorgente della classe, non avremmo problemi: si crea il metodo IsPassed che ritorna bool e siamo a posto. Supponiamo però di non avere il codice sorgente, oppure di non poter estendere la classe Holiday perchè è sealed o per chissà quale motivo. In una situazione di questo tipo, l’unica possibilità che avete è definire un extension method per il tipo Holiday. Guardate il seguente codice:

public static class HolidayExtensionMethod
{
    public static bool IsPassed(this Holiday holiday)
    {
        return holiday.Name.Length > 0;
    }
}

E’ una classe statica HolidayExtensionMethod, che espone un metodo pubblico IsPassed che prende in input un’istanza di Holiday. Notare la keyword this fra i parametri di input. Questa è la definizione di un extension method. L’utilizzo è banalissimo: l’Intellisense ci aiuta, perchè il metodo IsPassed() viene visto come se fosse esposto dal tipo Holiday.

        static void Main(string[] args)
        {
            Holiday h = new Holiday();
            h.Name = "Natale";
            h.When = new DateTime(2007, 12, 25);

            bool isPassed = h.IsPassed();
        }

Tutto qua.

Technorati Tags: .NET Framework Programming visualstudio

Send to Kindle

XamlPad ha fatto qualche passo in avanti rispetto a quello che usavo io quando ho studiato WPF. Qui potete trovare la versione 3.0 del tool. Mettiamola così: si tratta sostanzialmente di un blocco note avanzato, che fa il parsing dello XAML che digitate che viene renderizzato immediatamente a video man mano che lo scrivete. Comodo per le cose semplici, e forse un po’ ostico per chi non conosce XAML o se dovete fare particolarmente complesse.

Le features sono salvataggio/caricamento dello XAML su disco, il supporto per plugins e – non ho potuto trattenere un WOW – lo splash screen durante il caricamento iniziale!!!!

Link : http://blogs.msdn.com/llobo/archive/2007/12/19/xamlpadx-v3-0.aspx

Download diretto : XamlPad 3.0

Technorati Tags: Programming wpf tool

Send to Kindle

All’ultimo workshop UGIdotNET del 13 Dicembre, Dino Esposito ha illustrato al meglio, e in un modo che solo lui può ottenere, qual’è il trend delle applicazioni future sul Web. Questo trend prende il nome di Silverlight. So poco o nulla di queste tecnologie Web, ma un’idea ce l’ho e non riesco a non dirvela più di tanto. Oggi è il 19, sono passati 6 giorni dal workshop e non ce la faccio più a stare zitto.

La morale è che nelle versioni future, che oggi non sono nemmeno in alpha, Silverlight richiederà l’installazione del .NET Framework 3.0 sul PC client. Questo per avere TUTTE le potenzialità di WPF al 100%: tutti i tipi di panel, tutti i tipi di controlli, supporti per stili, data-binding, etc. etc. Tutto meraviglioso, io per quel poco che utilizzo WPF, so le sue potenzialità che sono assolutamente devastanti. Con tutta la potenza di fuoco di WPF, le applicazioni Web saranno in grado di dare agli utenti una user-experience mai provata prima. Ma non può essere tutto oro quello che luccica.

L’installazione del .NET Framework su ogni PC è un elemento a mio avviso bloccante. Sarà ovviamente un sottoinsieme del .NET Framework. Si parla di un plug-in di 13Mb. Ora: non è tanto il peso in Mb in sè, quanto la sensazione di invasività – passatemi il termine – che questo può creare. Non parlo di me che lavoro con il framework tutti i giorni, e non parlo nemmeno della maggior parte di voi che leggete il mio blog, ma parlo di tutti quelli che odiano il framework, o comunque di tutti quelli che non voglio installarlo per tenere pulito il PC. Uno dei motivi di successo di Google è – oltre all’ovvia efficienza del motore di ricerca – anche la leggerezza delle pagine, compresa la home-page. Quanti di noi installiamo le toolbar per IE o per Firefox? Quanti di noi fanno le installazioni custom degli applicativi al fine di essere il più leggeri possibile? Quanti di noi vanno nelle impostazioni di IE per disabilitare questo o quel plug-in per rendere più sicuro il sistema?

Dico chiaro e tondo quello che penso: pochi si installeranno 13Mb per avere Silverlight sul sistema. Dino ha fatto un ottimo esempio, quando ha parlato del buon vecchio ActiveX, che all’epoca (era pre-2000) doveva portare sui client un vero ambiente dove far girare le applicazioni, scritte con linguaggi seri ed attraverso componenti COM. Fallì, secondo me, non perchè era in anticipo sui tempi come ha detto Dino, quanto perchè era troppo invasivo sul PC dell’utente: c’era da scaricare un ocx o una dll, che girava in una sandbox sicura, etc. etc. Questo non cambia affatto con Silverlight: si scarica un assembly, e tale assembly gira attraverso il CLR lato client. Chiaro, è l’unica soluzione plausibile, ma è una cosa che gli utenti non digeriranno mai. E’ ovvio che attualmente è l’unica soluzione per liberarsi da Javascript (l’assembly è scritto in linguaggio managed, e su questo nessun problema), ma non è una strada percorribile. Non sono in grado di dire qual’è una strada migliore, ed è il motivo per cui oggi – più che in passato – odio tutti gli strumenti/tools/framework/tecnologie che hanno a che fare con lo sviluppo Web. Scusatemi, non voglio offendere nessuno. Se qualcuno mi dicesse: “Se uno sciocco se sviluppi per smart-client, o per palmare!”, la mia sicurezza è tale che gli risponderei pregi e difetti, e perchè mi piace, e perchè ritengo che quella è Vera Programmazione e le altre no. Quelli per Web sono solo un’accozzaglia di strumenti che tentano di unirsi fra loro per raggiungere un risultato finale decente. Contenti voi. Se sapessi una strada migliore, probabilmente non sarei qui a scrivere sul mio blog ma sarei da qualche parte a diventare ricco. Davvero.

Andiamo avanti.

Senza contare che il .NET Framework significa ad oggi compatibilità solo con il mondo Windows. Diciamo poco. Chiunque abbia programmato un sito Web appena più che decente sa che è assolutamente necessario coprire la maggioranza degli utenti, quindi prevedere tutti gli OS, tutti i browser, tutte le versioni, etc. etc. E voi mi venite a dire che Silverlight gira solo con il .NET Framework? Assurdo. Ok, si potrebbe obiettare, Microsoft rilascerà il framework anche su MAC, ed in futuro il progetto Mono arriverà a portare il framework anche su Linux. Sì, certo: adesso appena esco compro un X-Wing e vado a distruggere la Morte Nera, prima però passo a prendere Penelope Cruz che mi sta aspettando qui sotto per andare a mangiare una pizza. Siamo realisti, per favore. Secondo me, non è nemmeno questione di tempo. Anche se il framework sarà davvero disponibile su tutte le piattaforme, vorrei sapere chi davvero lo installerà. O comunque, vorrei sapere chi fra i Grandi del Web (Amazon, Ebay, etc. etc.) si azzarderà a costruire il proprio portale in Silverlight.

Ultima cosa: con Silverlight potremo visualizzare video. Il plug-in penserà a tutto. Io ho già raccontato la mia esperienza: WPF richiede Windows Media Player 10 per poter visualizzare certi tipi di video. Non posso affermare con certezza che il plug-in permetta davvero di vedere ogni tipo di video: secondo me, allo stato attuale delle cose, WMP è richiesto. Questo è un altro elemento bloccante, perchè WMP oggi significa solo Windows.

Meglio starò lontano dallo sviluppo Web, e meglio mi sentirò (cit.).
Oddio, che mal di testa. Ditemi quello che volete.

Technorati Tags: .NET Framework Web wpf Silverlight

Send to Kindle