Dino Esposito

Alla mia età comincio a provarci gusto a stare davanti ad una telecamera. Avevo cominciato lo scorso anno con un paio di interviste in qualità di esperto IT (una al TechEd USA) e continuo adesso con un vero e proprio video corso in uscita da AppDev dal titolo "Exploring Silverlight 2". Senza il classico "La vendetta" finale ...

E così finalmente posso dare un volto al gobbo (che dal nome pare tanto una forma di dissacrante ironia alla romana). In realtà in inglese si chiama tecnicamente teleprompter che fa capire esattamente a cosa serve e come abbia fatto per anni--uno a caso--Schifani (prima dell'upgrade a seconda carica...) ad avere quell'espressione falsamente naturale di fronte ad una telecamera. Come se dicesse cose spontaneamente. Oddio, erano sempre le stesse

In ogni caso, come il mio allievo prediletto Giorginho, mi aveva avvertito i video corsi sono DURI indipendentemente dall'argomento e da quanto lo si conosca. Bene, confermo. Che fatica. Tentando di analizzare scientificamente, direi che è ancora un altro mestiere rispetto allo scrivere articoli, scrivere libri, fare corsi/conferenze, o fare il programmatore/architetto. E' un po' come fare l'attore ...

Ma la cosa più difficile per me è stata dover "fare una presentazione PowerPoint" sempre allo stesso modo e senza improvvisare ogni volta. All'inizio di questa carriera mi sconvolse assistere a quello che per me fu un fenomeno. Vedere uno speaker di un roadshow VB usare ripetere una sessione ed usare esattamente le stesse parole, lo stesso passo, le stesse pause e la stessa varianza di intensita. Incredibile, ma è quello che ci vuole per un video corso.

E' violenza costringermi a "leggere" e "interpretare" la slide un bullet-point alla volta seguendo lo stesso ragionamento mentale che ho fatto quando le ho scritte ... La prossima volta vado con lo script slide x slide già pronto.

Ma se non altro ieri ho potuto ripetere tante di quelle volte un concetto base sul security model di Silverlight che val la pena ripeterlo. La sicurezza c'è ma non si vede. E questo è il punto chiave. Non c'è possibilità di sbagliare: configurazione, API, evidence. E' la CLR che fa tutto e senza ausilio esterno. E' un po' come la ricetta per l'AIDS.

CAS = non procedere con pratiche pericolose e usare dispositivi di sicurezza
Silverlight = non procedere. Punto.

Mi piace molto l'idea di codice diviso (a vedere della CLR) tra application e platform. E solo quello platform può eseguire codice safe-critical (che è l'unico abilitato a fare cose full-trust). Bene, la domanda sorge spontanea, dov'è il problema? Scriverò codice platform e bello che ti frego i discendenti di BillG.

Il codice platform, in quanto tale, non si può scrivere. Platform è solo il codice che arriva da una particolare directory MS e con una particolare firma MS. Non qualsiasi firma o certificato autenticato. Solo quello MS.

D'altra parte, il resto del modello permette eredità e override di metodi e interfacce safe-critical. Tanto tutto quello che in una classe è critical ha proprio l'attributo che dice alla CLR di non far eseguire dal normale codice application.

Direi quasi che è geniale. Di sicuro e' semplice ed efficace. Ricordo di aver sentito alcune delle considerazioni alla base del security model di Silverlight in una presentazione di Raf. Che sia proprio così?

Si lo sto diventando pigro ... e mi limito a puntare a post in inglese invece di almeno provare a scrivere in italiano. E' l'età ed è appena passato il mio compleanno.

Dal mio blog in inglese, ecco un post su Silverlight 2.0 e il threading. Si parla del nuovo oggetto Dispatcher che associato alla classe UserControl permette di eseguire del codice sul thread di interfaccia utente. Automaticamente e senza sforzi per il programmatore. Questo comportamento è nascosto nella classe BackgroundWorker del .NET FX 3.5, ed è diventato esplicito nel .NET FX di Silverlight 2.0.

PS1: la pronuncia milanese non sarà proprio granché ma rende l'idea

PS2: Managed Design ha per il momento a calendario solo una data (24-25 giugno 2008) su Architettura delle Soluzioni .NET e nulla su Silverlight e/o ASP.NET AJAX. Stiamo ragionando su una data nella seconda metà dell'anno, diciamo più inverno che autunno. Chi fosse interessato e avesse feedback (date, ma anche argomenti) non sia timido

Si è scritto e letto molto a proposito di cosa sia LINQ-to-SQL. E a cosa serva. Io stesso non ho fatto segreto di considerare LINQ-to-SQL soprattutto uno strumento buono per il DAL, ovvero una specie di ADO.NET object-oriented.

Ma ti ricordi improvvisamente di aver parlato una volta nella vita con Don Box. E ti ricordi di cosa disse quel santuomo in un pomeriggio olandese del luglio 1999--prima apparizione su un palco a parlare inglese. Per giunta, al TechED Europe. Quando mi disse che era lì per conoscere finalmente questo Dino Esposito di cui si leggevano meraviglie (che ci posso fare se "wonders" significa proprio questo...) ma che nessuno aveva ancora visto di persona (mai uscito di casa...) gli chiesi cosa c'era di vantaggioso per lui ad assistere alla mia presentazione su OLE DB. Il senso che Don apparentemente non colse era "potresti per cortesia accomodarti fuori, visto che già me la faccio sotto da solo senza che la tua onorevole presenza mi aumenti la ... tensione?"

Ma Don mi prese sul serio e rispose alla domanda su OLE DB dicendo "It's all about perspective, right?" Già si può sentire parlare di cose risapute ma la prospettiva "unica" di chi parla spesso ci da un valore aggiunto che talvolta ci apre la mente.

Giorni fa, assisto in quel di Varsavia ad una presentazione introduttiva su Entity Framework fatta da uno del team. Nessuna speranza di trarne vantaggio, ma alla fine ci faccio due chiacchiere e mi viene spontaneo pensare a LINQ-to-SQL sotto una luce diversa. E se lo potessimo considerare un O/RM, certo con una serie di limitazioni ma non per questo una roba da buttare via?

Ci ho preso gusto e ne sono venute fuori alcune considerazioni che, se vi va, potete leggere qui su DotNetSlackers.

Mi sono sempre chiesto a cosa servisse la proprietà BehaviorID nei controlli dell'AJAX Control Toolkit. E ho persino rischiato qualche figuraccia nei corsi quando mi appariva, inattesa, dentro un IntelliSense. E' una stringa che identifica univocamente un componente. Che differenza fa con l'ID? Se usata, la proprietà BehaviorID si usa per recuperare via script l'istanza del componente:

var extender = $find("...");

Se BehaviorID non è specificato bisogna passare a $find l'ID del controllo. Ma questo nel caso di master pages è una stringa ardua da ricordare. Allora si deve far ricorso al seguente codice:

var extender = $find("<%= Extender1.UniqueID %>");

Per evitarlo, è preferibile impostare BehaviorID il cui valore non è influenzato dalla presenza di master pages.

Nel FX 3.5 i servizi WCF sono stati estesi per supportare JSON e in generale uno schema di chiamata non-SOAP. E' stato perciò introdotto un nuovo binding noto come webHttpBinding. Si tratta di una estensione di basicHttpBinding con preimpostazione di MessageVersion a None e un po' di security.

Ecco, la security.

Quando si disegna un'applicazione AJAX (che non sia banalmente partial rendering) si ha bisogno di uno strato di servizi ad uso "esclusivo" dell'interfaccia Web. Per far contento Andrea <g>, chiamiamolo AJAX Service Layer (ASL). Si tratta di uno strato superficiale che nulla ha a che spartire con il service layer in cima al middle tier. Da questo, anzi, può anche essere fisicamente separato, passando su un altro tier.

I servizi dell'ASL (ahia ahia) sono pubblici--battuta facile facile, e sono ... cessi

Dicevo, i servizi dell'AJAX Service Layer sono pubblici nel senso che sono endpoint HTTP potenzialmente a disposizione di chiunque abbia voglia e tempo di invocarli. Questa roba si chiama (sia pure con trillioni di varianti) cross-site scripting. Della possibilità di iniettare codice script in pagine inconsapevolmente vittima di cattivi si sa abbastanza. La domanda è: questo script iniettato è in grado di chiamare un servizio pubblico? Risposta NO. O almeno credo. Diciamo che il dubbio dipende dal codice effettivamente iniettato. Se è un "semplice" <script src=...> allora NO; se fosse proprio un JS studiato per benino che conosce a menadito il proxy JS del servizio e se ne serve, allora direi che la cosa è possibile.

Perché non è possibile nel caso di un "semplice" <script src=...>? Perché il tag esegue una GET e non imposta content-type particolari. I servizi WCF di ASP.NET AJAX richiedono (di default) POST e application/json.

Bene. Cosa mi preoccupa allora?

Il fatto che qualcuno si scriva un programmino .NET e usando System.Net chiami il mio servizio. Questo è possibile. Altro che.

E allora? Il servizio pubblico solitamente non espone codice "pericoloso" e "critico" e questa è la miglior prevenzione possibile. Direi che ad oggi non si è mai andati oltre questo scenario. Ma se guardiamo oltre ad applicazioni PURE pensate col modello AJAX, beh signori, dobbiamo porci il problema di avere nel ASL del codice banale ma anche del codice "pericoloso", tipo metodi che finiscono per fare Update/Delete sul core system dell'applicazione.

Ergo pensiamo agli utenti, ma anche agli hacker. Poverini

Ne parliamo in Microsoft 31 marzo/2 aprile nel corso ASP.NET AJAX+ Silverlight. Prezzi modici, qualità alta. (s

Nella foga maniacal-erotico-provereccia scatenata dalle release a getto continuo di MS, ben due mesi di silenzio (meta dicembre/inizi marzo) hanno esasperato la gente. Al punto che uno si butta pesce su Silverlight 2.0 o MVC Preview 2 a seconda dei gusti e smanetta smanetta. E poi ti arriva l'hello-world precoce--la nuova malattia del secolo.  Ti viene fuori una cosa che è troppo presto per darti gusto e se la guardi un secondo dopo ti delude e magari deprime pure.

Se poi l'hello-world oltre a essere precoce è pure un mezzo fallimento, allora ci sta che uno cominci ad invocare santini e santarelli come fossero servizi pubblici.

[Questa dei servizi pubblici per smadonnare è una libera rielaborazione di una storiella raccontata nel libro "Why Software Sucks" di David Platt. David racconta di suo padre che avrebbe consigliato ad una societa dei telefoni di mettere su un numero verde da chiamare per lamentarsi. Del tipo: Prema 1 per dire "l'anima de li ... tua". Prema 2 per dire "Fan..lo te e tutta ..." Prema 3 per dire "...". Infine resti in linea per dirlo a voce all'operatore.]

Ieri alle prese con le slide e gli esempi del Silverlight 2 mi è scappato un hello-world precoce più che altro dovuto ad una forma cronica di documentatio-retardata di MS. Perché Silverlight 2.0 funzioni come ci si aspetta in un'applicazione IIS sembra che bisogna configurare IIS per riconoscere il MIME type XAP. Dettagli e oltre li trovate qui. [E io mi sono risparmiato un post.]

Adesso ce l'abbiamo, almeno in Beta1 e al TechED (inizio giugno) ce l'avremo col GoLive. Possiamo cominciare a ragionarci sopra.

Controlli e WPF
Per creare una interfaccia realmente accattivante come quelle che ci propinano ci vorrà sempre e comunque una schiera di grafici di professione. Ma per fare frontend di gestionali può bastare un misero programmatore e i controlli cominciano ad esserci

Networking
Il plug-in può chiamare chi vuole e usando un buon numero di protocolli. Sia chiaro che: le chiamate client DEVONO andare su un service layer APPOSITO, che filtra e non fa danni. O li riduce. Mi resta sempre difficile da dimostrare l'assoluta "sicurezza" di un approccio su servizi scriptabili; ma è il Web baby. Il rischio non sono le iniezioni di codice, ma il replay (automatico) di chiamate non autorizzate. Uno strato nel mezzo protegge ma non garantisce. Ma qui non è Silverlight il problema; sono i servizi pubblici

Cross-domain
Già si comincia a sentire dubbi sul cross-domain di Silverlight 2.0. Ma avete mai usato i frame? Avete mai usato Flash? E perché vi spaventa Silverlight? Preoccupazioni sul cross-domain hanno un senso sullo script; ma qui c'è la CoreCLR e la sua sicurezza.

Sicurezza
Ogni istruzione che la CoreCLR esegue deve essere eseguibile in un contesto di partial trust, a meno che il metodo sia marcato SafeCritical. Ma il programmatore NON può scrivere codice e marcarlo SafeCritical. Solo MS può farlo (firma digitale) e solo un assembly scaricato dal server MS può contenerlo. Uploadate se ci riuscite ...

Se avete ancora dubbi, l'appuntamento è per il 31 marzo in MS con il corso ASP.NET AJAX + Silverlight.

Da qualche giorno è disponibile la versione inglese del libro Programming ASP.NET 3.5 Core Reference. I sorgenti sono liberamente scaricabili dal seguente URL. Nel pacchetto non c'è la libreria AJAX Control Toolkit (v3.5) che va scaricata a parte. Nella directory Bin del progetto con i sorgenti del libro va poi copiata la DLL ajaxcontroltoolkit.dll.

Da quanto ne so, il libro uscirà in italiano da Mondadori dopo l'estate.

Mentre nel mondo si attende frementi il rilascio della beta di Silverlight 2.0 (settimana prossima, se non mi sono perso niente), e ci si domanda come disegnare e architettare nuovi front-end grafici per gestionali, nel puro mondo Web (dove la parola plug-in equivale a orticaria) le cose sono statiche statiche.

I paradigmi cambiano, le soluzioni aumentano (le tecnologie restano quasi obbligatoriamente le stesse ...), ma sono sempre troppi i siti che fanno sempre pena. E frustano gli utenti--altro che frustrazione ...

Hai voglia a dire AJAX; hai voglia a dire Silverlight o Flex; hai voglia a dire cross-platform o accessibility. Ce ne sono troppi che fanno proprio schifo. Ma mi irrita soprattutto la considerazione NULLA per l'utente. Alla faccia (anzi all'ìinterfaccia) della sbandierata user experience.

Stamattina ho chiari sintomi di acidità dunque me ne vengo con gli ultimi due tragici e fantozziani esempi in cui mi sono imbattuto. Con tanto di nomi e cognomi. E poi ho anche altri obiettivi

Ufficio Italiano Cambi
Pagina che offre i cambi fiscali giorno per giorno. Mi sarei aspettato la possibilità di scaricare un foglio Excel e lavorare offline.  Niente. Mi sarei aspettato di poter scegliere un periodo e fare un roundtrip solo. Niente. Bisogna procedere un giorno alla volta. Vabbé. Mi sarei aspettato una banale drop-down list con le divise possibili contro euro. Niente. Bisogna tirare su un pop-up (che tira su con mooolta fatica una pagina JSP) che ti fa scegliere "Dollaro USA" o quello che vuoi e poi se ne resta lì a coprire il campo di input finché non ti viene il sospetto che forse la devi chiudere/spostare da solo). Poi scegli il giorno--e miracolo della tecnologia--c'è un calendario JS. Poi finalmente puoi cliccare. Dopo 2 (due) minuti arriva la risposta. E si ricomincia.

A parte che è sempre la rete che fa schifo "a prescindere", non sarà che pure JSP è un pochinino più lento, "a prescindere", da ASP.NET?

Unicredit/Bancaroma Home Banking
Servizio di stampa fai-da-te dei famigerati F24. Il buon Visco, o chi per lui, dopo aver reso di fatto "obbligatorio" versare un obolo alle banche per l'home banking al solo scopo di pagare le tasse, ci faceva "di fatto" pagare pure la spedizione da parte della banca della quietanza. Senza della quale NON HAI PAGATO ovviamente, nonostante le evidenti tracce bancarie per le quali lo stesso Visco, o chi per lui, ha richiesto l'home banking. Poi passatasi una mano sulla coscienza, dice alle banche di mettere online un PDF quietanza (3 gg lavorativi dopo--ma con che cosa li producono i PDF? Artigianalmente?) che il ligio contribuente si stampa e allega alla documentazione fiscale. Bene, finalmente una buona notizia.
Poi lo fai con la suddetta banca e ti becchi una classica pagina con seleziona il periodo. Ma DEVI OBBLIGATORIAMENTE inserire data iniziale e data finale. Non vi è traccia di default.

Bisogna soffrire per pagare e dimostrare di avere pagato.

Alla faccia del Web, delle tecnologie e dei paradigmi. Quanto un po' di AJAX aiuterebbe quelle povere paginette ...

E infine dedicato agli sviluppatori di questi siti (e a tutti gli altri), dal 31 Marzo al 2 Aprile, venite a sentire dei pattern più idonei per AJAX e Silverlight. Certo visti gli standard dei costi Internet della PA e affini, il corso costa decisamente troppo poco. Ma volendo possiamo metterci d'accordo sul prezzo.