Technology Experience
Hardware

Surface 2 ed il servizio di assistenza

Ebbene sì: senza indugiare troppo, ho aprofittato dell’offerta di Mediaworld per acquistare il nuovo Surface 2 con in bundle un Nokia Lumia 520, che ho ceduto a mia madre, che era ferma ad un vecchio Nokia con Symbian.


(immagine gentilmente presa da questo articolo)

Felice dell’acquisto io, molto, molto contenta mia madre, sia per il tablet di Microsoft che per lo smartphone di Nokia. Davvero: mia madre non è mai stata molto avvezza alla tecnologia, e vederla adesso ogni sera navigare su Internet oppure giocare con Surface, mi rende un pochino felice.

Ma come in tutte le migliori storie, anche qui abbiamo dovuto combattere un pochino, perchè a circa una settimana dall’acquisto, ho scoperto un dead pixel sullo schermo, nel quadrante in basso a destra. Prima ho tentato di risolvere il problema da solo, con qualche app scaricata dallo Store per tentare di risvegliare il pixel, ma chiaramente…nulla da fare. Sinceramente mi stavo intristendo, perchè so benissimo che per un pixel bruciato nessuno ti sostituisce il prodotto.

Nessuna, tranne Microsoft (ad essere onesti, qualcun’altra ce n’è: me l’hanno detto via Twitter, ma in questo momento non ricordo quali siano). Aggiungo: per sostituire un iPad con pixel bruciati, Apple vi dice che ne deve avere almeno 4. Questa cosa mi è stata detta da un tizio presso un Apple Store a Milano (ho chiesto apposta per evitare di scrivere cose inesatte), anche se poi, googlando, vedo versioni differenti su questa questione. Può essere benissimo che la politica delle varie case produttrici sia cambiata nel corso del tempo.

Ma torniamo a noi. Ecco bene o male ciò che ho fatto.

  1. Ho registrato Surface 2 sul sito http://www.microsoft.com/surface/it-it/support (chiaramente indicando il serial number del prodotto)
  2. Indicando di avere un “Problema con un dispositivo”, ho successivamente espresso di avere un “Problema dello schermo”. Qui ho descritto a parole mie il problema.
  3. Siccome in quel momento non sapevo che un pixel bruciato fosse sufficiente per la sostituzione in garanzia, ho richiesto una telefonata con un tecnico, perchè volevo togliermi il dubbio prima di fare qualsiasi altra cosa. Telefonata che praticamente arriva un secondo dopo aver cliccato “Invia” sul form Web. Quel click secondo me fa partire una telefonata da Microsoft verso il numero di telefono che avete indicato, in modo tale che la telefonata non sia a carico vostro.
  4. Parlo per 30 minuti buoni con Valeria, una ragazza cordiale, simpatica e soprattutto molto molto competente. Non appena gli do il mio Microsoft Account, si spaventa per tutte le subscription che ho attivato, di ogni tipo, sia da user che da developer. A parte questo, mi spiega la procedura da seguire, per filo e per segno.

In pratica mi spiega che Microsoft sostituisce il mio Surface 2 a costo zero, anche con un solo pixel bruciato sullo schermo. Tutto questo avviene il 12 Novembre scorso, martedì. Valeria apre una pratica di assistenza a nome mio: pochi minuti dopo aver chiuso la telefonata, via mail mi arriva un’etichetta elettronica per UPS, che dovrò attaccare sul pacco per spedire il Surface 2. Chiamo UPS per prenotare il ritiro, specificando di avere un’etichetta elettronica. IMPORTANTE: nel pacco devo mettere solo il tablet, senza alimentatori e senza usare la scatola originale. All’ora di pranzo del 13 Novembre, mercoledì, passa il corriere UPS e Surface 2 parte in assistenza. Eccezionale, davvero, tutto il meccanismo, perchè ho il tracking number della spedizione, per cui posso seguire passo passo dove si trova il mio Surface 2. Arriverà a destinazione (Olanda) due giorni dopo, il 15 Novembre, venerdì.

Il 18 Novembre, lunedì mattina, ore 8:30 circa, ricevo una mail di notifica da Microsoft, che mi dice, più o meno: ok, abbiamo ricevuto il tuo Surface 2, gli daremo un’occhiata entro i prossimi 2 giorni. Sempre lunedì mattina, due ore più tardi, ricevo un’altra mail da Microsoft, che più o meno mi dice: ok, abbiamo dato un’occhiata al tuo Surface 2, ti stiamo spedendo il nuovo Surface 2. Evidentemente, in Microsoft sono riusciti a comprimere 2 giorni in 2 ore: geniali. In questa mail è contenuto il tracking number della spedizione di ritorno. Figata. Ma non figata tanto per dire, perchè questo trattamento è rassicurante. Sì, rassicurante è la parola esatta.

Surface 2 arriva a casa mia il giorno dopo, 19 Novembre, martedì, nel tardissimo pomeriggio. Praticamente 5-6 giorni lavorativi in tutto. Chiaramente, è stato sostituito, e quello nuovo non ha più il pixel bruciato e funziona a meraviglia.

Esperienza eccezionale, insomma. Un servizio di assistenza semplicemente sublime, in ogni più piccolo dettaglio. Valeria gentilissima, paziente, con una bella voce squillante come piacciono a me, mi ha seguito nelle varie fasi; nell’arco di questi 5-6 giorni mi ha telefonato altre 2 volte per assicurarmi che l’avessi spedito, che fosse tornato, e che quello nuovo fosse ok. Siccome l’avevo informata del mio blog, le avevo promesso che avrei scritto un articolo su questa vicenda, come ho fatto in passato per altri casi che ho vissuto in prima persona.

Detto questo, qualche piccola considerazione:

  1. Microsoft dovrebbe occuparsi con lo stesso stile anche dell’assistenza su Windows Phone: darebbe la birra a tutti quanti
  2. Ci sono servizi di assistenza migliori, come Dell ad esempio, ma è in quel caso sono servizi a pagamento, e non di certo per un pubblico meramente consumer
  3. Apple, oggettivamente e probabilmente, fa meglio: grazie alla presenza degli Store un po’ ovunque, può sostituire un iPad danneggiato sul posto, senza spedizioni e relativi tempi di attesa. Ma un iPad costa decisamente di più (un Surface 2 con 32GB costa 439 euro; iPad Air WiFi con 32GB costa 569 euro – anche il Mini costa di più); inoltre, lo ribadisco, con un solo pixel bruciato Apple col cavolo che mi avrebbe sostituito l’iPad. E non venitemi a dire che iPad fa molto di più, perchè nel mio caso non è assolutamente vero. Grazie
  4. Complimenti al personale dell’assistenza: non so se sono stato fortunato io. Nel caso sia così, quando chiamate l’assistenza, chiedete espressamente di Valeria e siete in buone mani

Ottimo lavoro, insomma. Lo so, forse sono di parte e fan di Microsoft, come sono fan delle tastiere Logitech, di Steam, di Canon, di Mediaworld, di Amazon, di tanti altri brand che sono i miei preferiti quando devo fare un acquisto. E non ci vedo nulla di male. Se Microsoft continua a trattarmi come ha sempre fatto negli ultimi 15-20 anni, continuerà a vedermi come suo cliente ancora per molto tempo!

Send to Kindle
My daily work

Brain-Sys ed il suo evento di Event Storming dell’8 Novembre scorso

Di cosa si tratta?
Venerdì 8 Novembre scorso ho vissuto un evento aziendale, interno alla società in cui lavoro, Brain-Sys, davvero molto, molto interessante. Qualche premessa prima di cominciare. Brain-Sys è una società magari-piccola-nei-numeri, ma eccezionale per altri motivi: innanzitutto crede nel telelavoro, perchè permette a ciascun dipendente di lavorare da casa propria. Per questo motivo, fisicamente ci vediamo poco, anche perchè siamo distribuiti geograficamente in posti differenti: chi in zona Lodi come me, chi in zona Pavia come i capi e chi in Valtellina. Abbiamo clienti altrettanto distribuiti geograficamente, con i quali riusciamo a lavorare perfettamente con tutta una serie di strumenti, dal meno tecnologico (telefono) al più tecnologico (Office 365, Lync, Skype, etc.). Personalmente è tre anni che lavoro in questo modo: i clienti che seguo sono piuttosto soddisfatti, io altrettanto, e credo che tutta Brain-Sys tragga vantaggio da tutto questo. Ed io pure.

Tutto questo per dire che l’evento dell’8 Novembre è stata anche un’occasione per ritrovarci tutti quanti, per conoscerci ancora meglio e per conoscere qualche nuovo componente che da poco si è aggiunto alla famiglia Brain-Sys.

Ma è stata anche un’importante occasione per lavorare, chiaramente, e per mettere in pratica una tecnica (metodologia?) di cui avevamo letto io e Gabriele nelle settimane/giorni scorsi. Questa tecnica viene denominata “Event Storming”, ed abbiamo preso spunto dalle sessioni e dai post di un certo Alberto Brandolini, alias @ziobrando su Twitter).

In pratica, ci siamo ritrovati tutti in una location molto raffinata (per la cronaca: Cascina Scova, a Pavia, un hotel 4 stelle con annesso centro benessere) e….Fermi!!! Tutti chi??? Per assurdo che sia, una delle cose che mi ha più colpito è proprio questo “tutti”. Normalmente, infatti, quando si tratta di sviluppare un software, succede più o meno la seguente cosa: un gruppo di persone si riunisce e decide vita, morte e miracoli di questo software. Normalmente, questo “gruppo di persone” include il cliente, un’analista ed un gruppo di commerciali. Rarissima volte il developer viene coinvolto in questa fase: a lui arriva una mazzetta di fogli, o al massimo una mail, con il contenuto riassunto di quella riunione.

Quando si applica Event Storming, invece, quello che accade è che viene organizzata una riunione a cui partecipano tutti quanti gli attori (numericamente, ci si aggira – dice @ziobrando – intorno alle 6-8 persone: l’importante è che siano diversi “punti di vista” attorno allo stesso problema): il cliente (che espone ciò di cui ha bisogno), il developer, un moderatore, l’esperto di dominio, magari un commerciale e così via. Questo è un vantaggio impressionante, di cui secondo me ci si rende conto solo a fine giornata: tutto il team coinvolto ha ragionato sullo stesso problema, ed una volta “educato” anche con la stessa terminologia (ubiquitous language), e ciascuno ha imparato dagli altri qualcosa. Un vero e proprio brainstorming, insomma, una tempesta di cervelli che alla fine i suoi frutti li dà eccome.

Facciamo un passo indietro.
Event Storming è un workshop con una struttura ben precisa.

Ci si ritrova in un certo numero di persone, ci vuole un bel rotolo di carta da appendere alla parete, ci vogliono post-it di diverso colore, penne, matite, scotch, etc. etc. Il cliente espone inizialmente il problema che ha, e che teoricamente il nostro software dovrebbe risolvere. Perchè si chiama Event Storming? E’ semplice: perchè la prima cosa che il team deve fare è pensare agli eventi che accadono all’interno del sistema. Nella vita reale, ciascuno di noi “fa qualcosa” in reazione “a questa cosa che è accaduta”. La stessa cosa deve accadere nel software. Gli eventi devono essere espressi con il “participio passato”, perchè un evento è avvenuto, punto e stop. Un evento non si può annullare, viene persistito, da questo non si scappa. Gli eventi vengono rappresentati da post-it di un colore ben preciso, che vanno attaccati al rotolo di carta sulla parete. E vi posso assicurare che, in base alla composizione del team che avete riunito, i risultati possono essere buoni o cattivi: noi ci siamo trovati alla grande. Nel nostro gruppo c’erano developer junior e senior, c’erano almeno due persone che con la programmazione non c’entravano nulla, eppure hanno partecipato ugualmente con produttività, per esempio. Una volta definiti gli eventi, siamo passati ai comandi, che possono scatenarsi da: un evento utente (click di un bottone, per esempio), dal semplice trascorrere del tempo (se entro le ore XX non è accaduto questo, avviene questo evento), oppure come semplice conseguenza di un altro evento. Ed ovviamente anche i comandi sono stati rappresentati sul foglio di carta con altri post-it, di un colore diverso. Poi gli aggregati, i domini, i bounded context, tutti concetti derivanti da Domain Driven Design (per gli amici DDD). I primi (aggregati) rappresentati ancora da post-it, gli altri da linee di separazione sulla carta, con diversi stili.

Chiaramente, Event Storming non serve e probabilmente non è utile per tutti i progetti. Dà il meglio su progetti complessi, perchè è molto utile per:

  1. uniformare il linguaggio (ubiquitous language): alla fine della giornata, tutti noi (il cliente, i developer, il grafico, l’esperto di dominio, chiunque) eravamo allineati sulla terminologia da utilizzare (vocabolario), evitando ambiguità, fraintendimenti, conflitti vari. Fidatevi, per una volta: vi posso assicurare che una semplice parola, a cui voi attribuite un significato chiaro e limpido, per altri può significare una cosa completamente diversa. E’ importante uniformarsi, creare un ubiquitous language che sarà utilizzato nel codice, nella documentazione, sulla UI, in qualsiasi riunione con il cliente
  2. team building: la giornata personalmente mi è piaciuta molto, perchè tutti noi abbiamo collaborato strettamente, di persona, per cui alla fine tutto ciò aumenta il feeling con gli altri componenti dell’azienda. Abbiamo scherzato, e lavorato, ci siamo presi in giro ed abbiamo discusso, abbiamo avuto idee che non avremmo mai pensato di avere all’inizio della giornata. Sì: come succede spesso in Brain-Sys abbiamo lavorato divertendoci.
  3. chiarezza del progetto: forse, inerente il punto (1). Al di là del linguaggio, tutti noi abbiamo le idee chiare su ciò che dovrà fare il progetto, dalla A alla Z. Sappiamo i confini entro i quali si estende il dominio, abbiamo per certi versi separato le responsabilità, identificato ciascun bounded context

Da quella giornata, siamo tutti tornati a casa molto, molto soddisfatti. Prima di lasciare la location (davvero spettacolare!), abbiamo ovviamente ripulito tutto quanto, ed abbiamo scattato foto al rotolo di carta prima di staccarlo, per avere anche in futuro la nostra modellazione a portata di mano, come documentazione. Pian piano, il progetto sta prendendo vita anche dal punto di vista del codice.

Qualche ringraziamento!!
Beh, l’elenco può essere lungo.

  1. Innanzitutto, ai capi: Gabriele Gaggi ed Alessandra Maggi, perchè oltre ad essere i capi, sono amici e persone sempre disponibili, non solo rendendomi partecipe della vita dell’azienda, con i giusti limiti, ma anche dal punto di vista personale
  2. A Nazareno Manco, che si è mosso dall’est dell’Italia, per raggiungerci, portando con sè la sua famiglia, la sua simpatia, e la sua competenza durante l’Event Storming. Persona bravissima, in gamba, e competente. Ed anche un amico, soprattutto per il supporto morale di questa estate, che non dimenticherò mai, probabilmente. Ok, scusate l’OT
  3. Ad Andrea Barbaini, anche lui si è imbarcato in un lungo viaggio da Roma per essere dei nostri. Non è da tutti!!!
  4. Posso ringraziare ancora qualcuno? Ok, grazie. Aggiungo allora l’intero staff di Managed Designs, Andrea Saltarello e Mauro Servienti in primis, che nel corso del tempo mi hanno fatto entrare in testa i concetti di CQRS, Event Sourcing, e soprattutto DDD, metodologie e tecniche che non riguardano solo il mero sviluppo del codice, ma aiutano a pensare meglio, da molto prima di cominciare a scrivere il codice, al progetto software in cui ci si sta imbarcando
  5. All’intera famiglia Brain-Sys, cioè a tutti noi, perchè siamo (anche) bravi. E come dicevo alla nostra Chiara durante l’evento “Certo che noi della Brain-Sys siamo proprio belli!”!!!!
Send to Kindle
.NET World

Uploadare/Scaricare files da Windows Phone 8 su Skydrive

Una delle features a mio avviso che è poco sfruttata all’interno delle app Windows Phone è quella di poter uploadare/scaricare files dallo smartphone sul cloud (nel caso specifico Skydrive). A cosa potrebbe servire? Beh, immaginatevi un’app di qualsiasi tipo, che abbia impostazioni, files, fotografie, audio, qualsiasi contenuto. Se comprate un altro telefono Windows Phone, oppure se resettate il telefono, quei contenuti li perdete, perchè erano inclusi nell’Isolated Storage di quell’app specifica. Esempio concreto: immaginate Rowi, uno dei client Twitter più importanti ed utilizzati: voi lo acquistate la prima volta, lo impostate con i vostri account, e regolate le impostazioni come piacciono a voi. Poi sostituite il telefono, oppure resettate l’attuale, e perdete tutto quanto, e siete costretti a reimpostare daccapo tutto quanto. Oppure un gioco come Angry Birds: tutte le volte che lo installate, non c’è alcun modo per recuperare le partite che avevate. E così via, in generale il discorso si può applicare a bene o male tutte le app Windows Phone.

Grazie al Live Connect SDK, possiamo sfruttare le potenzialità del cloud Skydrive all’interno delle nostre app Windows Phone. Quindi: all’interno di una nostra app possiamo:

  • inviare su Skydrive qualsiasi files che abbia un senso (impostazioni, file di dati dell’utente, etc.)
  • scaricare i files per recuperare i vecchi contenuti

Il livello base l’ha già spiegato l’amico Matteo Pagani, in questo post sul suo blog in inglese. Qui viene spiegato quali reference aggiungere al progetto, come aggiungere il pulsante di login, e come inviare/scaricare files. Il tutto riguarda Windows Phone 7, ma va benissimo anche per Windows Phone 8: possiamo però sfruttare qualche miglioria, che ai tempi della stesura del post non esisteva (esempio: possiamo utilizzare le tecniche async/await, evitando le varie callback che complicano la leggibilità del codice). Però il 95% va più che bene.

Quello che non mi piace è che quel codice salva i files alla root di Skydrive.

Questo comporta che l’utente potrebbe inavvertitamente cancellare i files, perchè non li riconosce. Oppure potrebbe capitare che più app vadano a scrivere sugli stessi files: cosa un po’ assurda da pensare, ma mica tanto: non è poi così assurdo pensare che le impostazioni di un’app vengano salvate in un file chiamato Settings.xml, tramite serializzazione/deserializzazione. E quindi è assolutamente una cosa da evitare (almeno io la penso così).

La conclusione di tutto ciò è che si comincia a lavorare con i folder su SkyDrive.

Quindi, supponiamo: stiamo sviluppando un’app chiamato “La mia bella app”, che intenda inviare/scaricare files su Skydrive, dentro un folder chiamato “La mia bella app”. Cosa si realizza tutto ciò? Io mi sono inventato questo metodo helper, che in pratica fa una cosa molto semplice: dopo che ha ottenuto l’accesso al vostro account Skydrive, legge la root, e scansiona tutte le directory presenti, alla ricerca di quella che si chiama “La mia bella app”. Se la trova, ne recupera il Folder ID; se non la trova, la crea e ne recupera il Folder ID. Tramite questo Folder ID, possiamo utilizzare gli stessi metodi spiegati da Matteo Pagani nel suo post, solo che invece di lavorare alla root, lavoriamo all’interno del nostro folder.

private async Task EnsureSkyDriveFolderExists(string folderName)
{
    this.SkyDriveOperationWaiting.IsIndeterminate = true;
    this.SkyDriveOperationDescription.Text = "Controllo cartella su SkyDrive";
    var response1 = await client.GetAsync("me/skydrive/files");
    List<object> items = response1.Result["data"] as List<object>;

    foreach (object item in items)
    {
        IDictionary<string, object> directories = item as IDictionary<string, object>;

        if (directories["name"].ToString() == folderName)
        {
            this.SkyDriveOperationDescription.Text = "Cartella su SkyDrive ok";
            ApplicationContext.Instance.FolderIdSkyDrive = directories["id"].ToString();
            App.SaveSettings();
            return;
        }
    }

    this.SkyDriveOperationDescription.Text = "Creazione cartella su SkyDrive";
    
    var folderData = new Dictionary<string, object>();
    folderData.Add("name", folderName);

    var response4 = await client.PostAsync("me/skydrive", folderData);
    ApplicationContext.Instance.FolderIdSkyDrive = response4.Result["id"].ToString();
    App.SaveSettings();

    this.SkyDriveOperationDescription.Text = "Cartella su SkyDrive ok";
}

 

Il codice va un po’ ripulito, perchè ci sono riferimenti a controllo sulla UI, come ProgressBar e TextBlock, che mantengono informato l’utente su ciò che sta accadendo. La logica è questa:

  1. Grazie al path “me/skydrive/files” recupero l’elenco di file e directory presenti alla root di Skydrive
  2. Ottenuto l’elenco, lo ciclo alla ricerca della directory chiamata “folderName”, che è una stringa che arriva in input a questo metodo
  3. Se la trova, salva il Folder ID da qualche parte (io la memorizzo in una classe singleton AppicationContext), salva le nuove impostazioni ed esce
  4. Se il folder non viene trovato, allora viene creato (metodo PostAsync), viene recuperato il Folder ID, il tutto viene salvato e si esce dal metodo

Una precisazione è d’obbligo.

Teoricamente parlando, il codice potrebbe salvarsi il Folder ID al momento della prima generazione della cartella, in modo tale che si eviterebbe ogni volta di controllare se esiste oppure no. Sbagliato! Ricordiamoci che l’utente potrebbe cancellare il folder su SkyDrive (attraverso il sito, oppure attraverso una qualsiasi app Windows Phone, Windows 8, etc.). Quindi è importante andare a controllare l’esistenza del folder, ogni volta.

Una volta che si esce da questo metodo, si è pronti per inviare files all’interno di questo folder:

await client.UploadAsync(ApplicationContext.Instance.FolderIdSkyDrive, s,
    stream, OverwriteOption.Overwrite);

 

Il primo parametro del metodo UploadAsync è proprio il Folder ID che abbiamo ottenuto. Matteo nel suo post indicava “me/skydrive”, per uploadare nella root. Indicando il Folder ID, i files vengono uploadati all’interno del nostro folder.

Scaricare un files è un filo più complesso. Con questo metodo:

var response2 = await client.GetAsync(
    string.Format("{0}/files",
    ApplicationContext.Instance.FolderIdSkyDrive));

recuperiamo l’elenco dei files contenuti nel folder indicato da Folder ID. Una volta che abbiamo l’elenco, dobbiamo ciclare la lista e scaricare solo quello che ci interessa (oppure banalmente implementare un foreach per scaricarli tutti quanti). Per scaricare un file, si utilizza questo metodo:

var response3 = await client.DownloadAsync
    (string.Format("{0}/content",
    fileId));

Il risultato di tutto questo giro di codice è che sulo Skydrive del nostro utente ci sarà un folder chiamato come vogliamo noi, con tutto ciò che abbiamo deciso di uploadare. Se abbiamo dato un nome chiaro al folder, l’utente lo riconoscerà senza problemi: potrebbe decidere di cancellarlo oppure no (questo è chiaramente al di fuori del nostro controllo, per cui non ci dobbiamo fare troppo affidamento).

Send to Kindle
Software

Avviare Internet Explorer con più siti aperti, da command line

Tutti sappiamo che Internet Explorer (IE) può essere avviato da command-line, con un parametro che specifica l’unico ed il solo sito web che si desidera aprire. Ad esempio…

“C:Program FilesInternet Explorerexplore.exe” http://www.facebook.com

…avvia IE direttamente sulla pagina di Facebook. Notare l’uso degli apici per gestire i path che contengono spazi, come in questo caso.

Ieri mi sono posto la domanda: e se volessi avviare una sessione di IE dedicata al mondo social, e quindi aprire contemporaneamente Facebook, Twitter e magari Yammer? Oppure una sessione IE dedicata alle notizie, e quindi aprire Repubblica, Il Cittadino (quotidiano di Lodi) e La Gazzetta dello Sport? Da command-line non è possibile specificare più siti da aprire. Fortunatamente, una googlata ed il problema si è risolto da sè. E’ necessario creare un file, che chiameremo social.js:

var navOpenInBackgroundTab = 0x1000;
var objIE = new ActiveXObject(“InternetExplorer.Application”);
objIE.Navigate2(“http://www.facebook.com”);
objIE.Navigate2(“http://www.twitter.com”, navOpenInBackgroundTab);
objIE.Visible = true;

Queste poche righe di JScript avviano una nuova istanza di IE, ed aprono i siti indicati, uno per tab, chiaramente. Molto comodo. Purtroppo, però, il semplice doppio-click sul file .js non ne scatena l’esecuzione, ma vi chiede un qualche editor con cui aprire il file (o almeno: sul mio PC succede questo). Come risolvere? Basta passare il .js come parametro di input a wscript.exe, e quindi:

wscript.exe social.js

Questo comando esegue lo script contenuto in social.js. Notare che siccome il folder C:WindowsSystem32 (path in cui si trova wscript.exe) è contenuto nei path predefiniti del sistema, non è necessario specificarne il path. Semmai, sarà necessario specificare il path del vostro file social.js. Ovviamente, potete predisporre più files .js, ciascuno dei quali…come dire…tematico, tagliato su misura in base a ciò che vi serve.

E se avete una tastiera gaming come la Logitech G510?
Potete associare l’esecuzione di ciascuno dei files .js ad uno tasti G sulla tastiera.

Quindi: premete G1 e si apre IE sui social, premete G2 ed andate sui siti di news, oppure su qualsiasi altro sito (o gruppi di siti) che vi servono. Il tutto in modo estremamente intuitivo e rapido (una volta che avete messo a punto tutto il meccanismo).

Cool! Sinceramente non so come ho potuto farne a meno fino ad oggi!

Send to Kindle
Hardware

La mia prova del Nokia Lumia 1020

Grazie a Nokia Italia sono riuscito a provare uno degli ultimi smartphone Windows Phone 8, il Lumia 1020 un vero gioiello di tecnologia, soprattutto per quanto riguarda la fotocamera da 41 Megapixel (non è un errore di battitura, sono proprio 41!).

Ho ricevuto il telefono il 27 Settembre e l’ho restituito al mittente esattamente una settimana dopo, il 4 Ottobre: sette giorni in cui ho portato sempre con me il Lumia, scattando foto, twittando, giocando, ascoltando (poca) musica, facendo tutte le attività che era già abituato a fare con gli altri due smartphone Windows Phone in mio possesso: un (vecchio) HTC HD7 ed un Nokia Lumia 920 (aziendale).

In questa recensione non vi parlerò, per quanto possibile, del sistema operativo di Microsoft, per un semplice motivo: Windows Phone 8 gira allo stesso modo su tutti i Lumia. In questa recensione mi piacerebbe focalizzarmi su ciò che differenzia il Lumia 1020 da tutti gli altri Windows Phone 8 sul mercato (non solo quelli di Nokia, ma anche quelli di HTC e Samsung): quindi principalmente le differenze a livello di hardware.

Credo infatti che uno dei grandissimi vantaggi del mondo Windows Phone sia le differenziazione dell’hardware, in grado di coprire diverse fasce di prezzo: in base a ciò che si vuole fare e a ciò che ci si aspetta di voler fare, una persona può spendere il giusto e prendersi un Windows Phone “ritagliato su misura”. Ci sono Windows Phone con una fotocamera così così (senza flash, come il 520), ci sono quelli con più memoria, con display più piccoli e più grandi, quello più leggero o più pesante, quello con la batteria integrata, oppure no, e poi ci sono quelli con…

…una fotocamera davvero spettacolare!!!
Inutile negarlo. Il vero pezzo forte del Nokia Lumia 1020 è la fotocamera da 41 Megapixel.
Per poter gestire foto di questa dimensione, Nokia ha sviluppato un’applicazione specifica, Nokia Pro Cam. Windows Phone 8 permette di impostare quale app fotografica volete avviare quando tenete premuto il tasto della fotocamera, quindi è tutto molto istintivo. Siete in giro, vedete qualcosa di interessante, tenete premuto per 2 secondi il tasto fotocamera, inquadrate e scattate. Il Nokia Lumia 1020 in realtà scatta due fotografie: una a 5 Megapixel, l’altra a 41. La prima è quella che viene utilizzata per tutte le attività su Windows Phone (condivisione sui social network, per esempio); l’altra è visibile solo usando l’app Nokia Pro Cam, oppure collegando il telefono al PC. Usando Nokia Pro Cam, potete fare pan all’interno della fotografia, ritagliare porzioni di foto, zoomare, il tutto in modo molto fluido, e rendervi conto di ogni più piccolo dettaglio di ciò che avete inquadrato (e da qui il significato dell’hashtag #aworldofdetails usato su Twitter).

Fisicamente parlando, la fotocamera è ben visibile ovviamente sul retro dello smartphone, con un grande “occhio” (come l’ho battezzato io), che mi è piaciuto per diversi motivi. Innanzitutto è impossibile che si sporchi, perchè è stato costruito in modo da risultare ben protetto, evitando che prima o poi ci si infili un po’ di polvere. Esteticamente è molto bello a vedersi, e dà al Lumia 1020 una certa personalità (anche perchè è di colore nero, e spicca sui colori vivaci – il mio era giallo, per esempio). Inoltre, il fatto che l’occhio sporga in modo “smussato” dalla scocca del telefono, senza fastidiosi spigoli, aiuta in un certo qual modo la presa dello smartphone (come il 925, per capirci, ma la cosa qui è più marcata). E’ un po’ difficile da spiegare, e probabilmente dipende dalle dimensioni delle vostre mani: io mi sono trovato davvero comodo. Infine, piuttosto figoso il tick che si sente quando la fotocamera viene attivata.

Il flash ricorda molto quello delle reflex professionali: è davvero molto potente. Accanto al flash vero e proprio, accanto Nokia ha posizionato una luce led che si attiva su richiesta (agendo sulle impostazioni di Nokia Pro Cam), lampeggiando, per aiutare la messa a fuoco. Ottime, chiaramente, le foto anche al buio: il software installato su Windows Phone alza gli ISO – inevitabile la comparsa di artefatti, amen – ma la foto la fate, e pure bene. Molto, molto meglio di quanto possiate fare con un iPhone (su questo non voglio nemmeno discutere: qualche foto con iPhone in passato l’ho fatta, e vedendo quelle condivise dagli amici un’idea me la sono fatta). Dal punto di vista della qualità fotografica, l’intera gamma Lumia è decisamente sopra la concorrenza, e questo 1020 è l’apice. Ottimo lavoro, Nokia!!

30 grammi più leggero rispetto al Nokia Lumia 920
Il mio telefono aziendale è un Nokia Lumia 920. Il 1020 è più leggero del 920 di circa 30 grammi, che si sentono abbastanza. Mi piace, questa cosa. Non so esattamente da cosa dipenda questa differenza di peso (non credo proprio che dipenda dal wireless charging presente sul 920 di default), però si fa sentire positivamente. Ho sempre pensato che il 920 fosse un pochino troppo pesante. E’ anche un filino più sottile del 920. Anche da questo punto di vista, insomma, il Lumia 1020 mi ha convinto moltissimo.

Capienza della batteria: spettacolare!
Ora, prendete queste dichiarazione con le pinze. Penso che sia molto difficile giudicare in modo oggettivo la capienza di una batteria, perchè dipende molto da un certo numero di fattori, complicati da misurare. Mi spiego: ci sarà chi vi dice che la batteria di un Lumia dura un giorno, oppure 4 ore, oppure 2 giorni. Dipende da cosa fate con il vostro smartphone: quanto tenete lo schermo acceso, se avete attivato il 3G oppure no, se avete attivato Bluetooth o il WiFi, o il GPS, quanta musica ascoltate, quanto giocate e soprattutto quali giochi usate. Insomma, un gran casino. E quindi ognuno ha la sua percezione della durata della batteria, un po’ difficile da misurare in modo oggettivo.

Fatta questa premessa, trovo che il Lumia 1020 abbia una batteria impressionante, molto migliore del 920 (ho il 920 da fine agosto, quindi penso che la batteria integrata non si sia deteriorata granchè). Domenica 29 Settembre ero in fiera a Novegro (Milano), come espositore. Quel giorno ho staccato dalla corrente il Nokia Lumia 1020 alle 7:50 del mattino, e mi è durato fino alle 22:30 dello stesso giorno. Cosa ci ho fatto? Un mucchio di roba: ho scattato tante foto a 41MP, ho consultato moltissime volte Twitter con l’app Rowi, ho registrato tre video in HD (circa un paio di minuti l’uno), ho condiviso via NFC & Bluetooth uno di questi video e qualche foto, ho navigato, ho preso la posta, ho condiviso le foto su Twitter. Quel giorno non ho giocato, non ho ascoltato musica. Una cosa davvero incredibile! Il 920 molto probabilmente mi avrebbe richiesto una ricarica nel tardo pomeriggio. O magari, chissà, è solo una mia impressione.

Camera Grip
Nokia Italia mi ha mandato anche il Camera Grip, che è in pratica un “guscio” per il Nokia Lumia 1020, che trasforma lo smartphone in una vera e propria fotocamera. Al suo interno, il Camera Grip contiene una batteria aggiuntiva, da caricare separatemente: quando inserite il 1020, la batteria del Camera Grip ricarica lo smartphone.

Oltre a questo, il Camera Grip vi mette a disposizione un pulsante per la fotocamera decisamente più corposo ed a misura di dito; le dimensioni del guscio sono generose, e vi permettono di maneggiare il Lumia in modo più deciso, più “muscoloso”, senza preoccuparvi troppo pensando di aver fra le mani un costoso giocattolo hi-tech. Nella confezione del Camera Grip è incluso anche un laccetto da farvi passare intorno al polso per maggior sicurezza.

Sistema operativo: Windows Phone 8
Due righe veloci veloci sul sistema operativo, Windows Phone 8. Come dicevo all’inizio, il sistema operativo è in comune con qualsiasi altro smartphone. Quello che Nokia aggiunge – e dici poco – è tutta una serie di servizi: Nokia Maps, Nokia Drive (un navigatore che non richiede la connettività Internet, e che mette a disposizione un gran numero di mappe in tutto il mondo), più tutta una serie di app esclusive, che gli altri vendor si sognano. Sempre parlando del mondo Windows Phone, ero un fan dei prodotti HTC, ma di fronte a ciò che ha fatto Nokia, non vi è nient’altro che la resa incondizionata. Nokia ha e sta contribuendo alla crescita di Windows Phone, sotto tutti i punti di vista.

Per quello che mi riguarda, Windows Phone 8 è un ottimo sistema operativo. Veloce, fluido, pratico, semplice, assolutamente non complicato. Sento spesso parlare di amici con smartphone Android che si lamentano del fatto che quando si aggiungono foto, il telefono rallenta: questo – ve lo posso assicurare – con Windows Phone non accadrà mai. Che abbiate installato 5 app oppure 1000, un telefono Windows Phone non perderà mai lo smalto del primo giorno, e sogghigno sempre quando sento gli altri lamentarsi che “all’aumentare del numero delle app, o delle foto, o video”, il loro smartphone perde colpi, rallenta, si inchioda. Ed onestamente non ne capisco la ragione: francamente non mi interessa nemmeno approfondire. So che il mio Windows Phone non mi abbandonerà mai.

Ok, pare che sia una figata, ma la fregatura dov’è?
Nonostante mi abbia colpito in modo eccezionale, è giusto che vi segnali anche qualche piccolo dettaglio che mi ha fatto riflettere.

Innanzitutto, l’occhio della fotocamera, sebbene mi piaccia davvero molto, è sporgente rispetto alla scocca del telefono. Questo significa che quando lo mettete su una superficie piana, il Lumia 1020 non appoggia completamente in modo piatto sulla scocca: sta leggermente inclinato, e tende a ruotare se si tenta di interagire con il display (e lavorando qualche volta mi capita). Inoltre, mi preoccupa solamente il fatto che l’occhio, nel punto in cui tocca la superficie, alla lunga potrebbe rovinarsi un po’. Ma è solo una sensazione: bisognerebbe provare ad avere il 1020 per un tempo più lungo di una settimana, e magari a maltrattarlo un po’. Qui sopra ho messo una foto che spero illustri quello che ho cercato di spiegarvi a parole.

Un’altra piccola cosa è il Camera Grip, che non ha alcun problema quando deve essere innestato sul Lumia 1020. Invece dà qualche pensiero in più quando lo si deve staccare: gli agganci sono robusti e solidi, ed evitano che il telefono cada rovinosamento per terra. Ottimo, però alo stesso tempo richiede un bello sforzo per essere sganciato, e – insomma – si ha sempre un po’ paura, perchè si comincia a pensare che si stia manovrando nel modo sbagliato. Magari bisogna farci un po’ la mano – indubbiamente.

Ultimi consigli
Non fate l’errore, secondo me, di dire: “Prendo un Nokia Lumia 1020 perchè ha una fotocamera meravigliosa”. Considerate anche che ha più RAM rispetto al 920 ed ha un nero più nero (sempre paragonato al 920 – li ho accesi uno accanto all’altro, con lo schermo impostato alla stessa luminosità). E’ più leggero e maneggevole. Se non vi interessa il wireless charging del 920, puntate dritti al 1020, mettendo sulla bilancia anche il fattore economico. Ad oggi giustamente il 1020 costa di più, ma per quello che mi riguarda ha qualche marcia in più rispetto al 920.

Send to Kindle
Software

Perchè 15 caselle di posta in Outlook?

Il mio post di ieri sera, relativo all’occupazione di RAM di Outlook 2013, ha scatenato il solito dibattito, sui social network. Chi come me ha lo stesso problema, chi invece lo tiene aperto per ore senza che accada nulla di anomalo, etc. etc. Poi è saltato fuori che utilizzo Outlook 2013 con 15 caselle di posta, e che quindi il problema potrebbe essere tutto qua. Innanzitutto preciso una cosa: il fatto che Outlook 2013 mi arrivi ad occupare 2GB di RAM, alzando allo stesso tempo il carico sulla CPU, non è sistematico: a volte accade, a volte no. Quindi non può essere solo un problema riguardante le 15 casella di posta, altrimenti accadrebbe tutte le volte, invece no.

Ma arriviamo al dunque. Perchè gestisco 15 casella di posta elettronica. Voglio spiegarvelo, per un motivo molto semplice: ho voglia di scrivere e credo di darvi qualche spunto su cui ragionare.

Di queste 15, una è quella relativa al mio Microsoft Account.

Un’altra è quella lavorativa, della mia azienda, insomma.

Ne rimangono 13. Cercherò di elencarvele, una ad una.

  • una è la mia personale, quella che utilizzo più spesso, per scrivere ad amici, o comunque ogni qualvolta la persona dall’altra parte deve leggere il nome “Igor” riconoscendomi senza sforzi
  • una è quella che utilizzo per gli acquisti (ad eccezione di Amazon, vedere dopo): qui ricevo le ricevute di pagamento di tutto ciò che acquisto online (da Steam, per esempio, a via via tutti gli altri siti su cui bene o male si possono fare acquisti)
  • una è quella dedicata a tutto ciò che è “community”: con questa casella mi sono registrato su Facebook, su Twitter, su Foursquare, su Pinterest, e via dicendo. Qui ricevo tutte le mail di notifica: nuove amicizie su Facebook, qualsiasi forma di interazione su Twitter (nuovi follower, miei tweet retwittati, e via dicendo). Spesso queste mail sono poco importanti, per cui ogni tanto spazzolo via tutto senza curarmene più di tanto
  • una è quella interamente dedicata al NAS della mia rete locale: se qualcosa va storto qui ricevo una mail di warning o di allarme. Effettivamente potrebbe essere eliminata ed accorpata con qualcos’altro
  • una è dedicata alla ricezione di qualsiasi newsletter a cui mi sia sottoscritto. Promozioni, offerte, sconti, volantini, viaggi last minute. Anche queste sono mail davvero poco importanti, però mi è utile avere una casella dedicata da spulciare in modo spensierato
  • due di queste caselle sono dedicate a Piloti Virtuali Italiani: una mi permette di seguire la mailing-list interna all’Associazione (decine, decine e decine di mail ogni giorno). L’altra è più legata al mio software VivendoByte Fsx Logger, ed è una casella su cui ricevo notifiche varie ogni volta che qualcuno termina e pubblica un volo virtuale. Queste due caselle generano molto, molto traffico ogni giorno, e non potrei farne a meno. Senza impazzirei in tre minuti
  • una è dedicata al supporto tecnico di tre cose: il mio software Fsx Logger, le app Windows Phone e le app Windows 8. E’ la mail che indico nelle app, insomma, su cui qualsiasi utente delle mie app mi può scrivere per segnalarmi qualcosa che non va
  • una è dedicata al mio TFS locale (quando ce l’avevo e lo utilizzavo). Effettivamente ad oggi potrei eliminarla senza problemi
  • una è dedicata alle fatture Telepass. Anche questa effettivamente ad oggi potrei eliminarla senza problemi, non ho idea sinceramente del perchè abbia deciso di creare una casella di posta dedicata. Ho fatto questa cosa anni fa, e non ricordo più il motivo reale
  • una è dedicata agli acquisti Amazon. Qui ricevo tutte le mail sui miei ordini: quando un pagamento viene completato con successo, quando un ordine viene spedito, etc. etc. Ma non solo: è la casella che ho autorizzato come mittente per inviare ebook sul mio Kindle

Se ho contato bene, sono arrivato a 11. Ne mancano 2: due caselle che effettivamente potrei spazzare via. Ok, potrei scendere da 13 a 11, e forse qualcosa meno, togliendone un altro paio. E’ evidente che io abbia esagerato un po’, ma francamente è un metodo che mi piace e che trovo molto molto utile.

Ma mi piace sinceramente avere caselle dedicate, perchè mi permette di organizzare meglio tutta la posta che ricevo: ogni casella ha un suo compito preciso. Ogni casella è molto specifica, e soprattutto nel caso di spamming posso chiudere temporaneamente la casella senza troppi problemi (e mi è successo: se avessi avuto una sola casella sarei stato in grossi guai).

Spero di essermi spiegato!!

Send to Kindle
Software

Quella brutta bestia di Outlook 2013

A Luglio di quest’anno ho cambiato PC. Adesso il mio desktop è un Intel i7 con 16GB di RAM, monta un SSD ed una ATI Radeon HD6870. Ciò nonostante, Outlook 2013 è un virus talmente potente che riesce a metterlo in crisi. Ecco il mio aneddoto.

Nel BIOS della mia mainboard ho attivato un po’ di allarmi a livello hardware. Essi sono di due tipi:

  1. se una qualsiasi delle ventole montate nel case smette di girare
  2. se la temperatura della CPU supera i 60°C

Ieri pomeriggio, lavorando, sento partire il beep dalla mainboard, che dura un paio di secondi. Nel giro di 3-4 secondi apro il case, convinto che una delle ventole si fosse improvvisamente fermata. Invece no. Dopo aver rimosso il pannello laterale, vedo tutte le 4 ventole girare senza problemi: quella della CPU (soprattutto!!) e via via tutte le altre. Sul momento non ho pensato alla temperatura della CPU. Ho pensato ad un problema un po’ casuale, per cui non gli ho dato troppo peso.

Questo pomeriggio il fenomeno si ripete. Sto lavorando ed improvvisamente parte il BeeeEEEEeeeeeP dalla mainboard, e si ferma quasi subito. Avvio Open Hardware Monitor (OHM), che mi permette di tenere d’occhio un sacco di parametri del mio hardware (carico della GPU, giri/minuto di ogni ventola, temperatura di CPU, hard-disk, scheda grafica, frequenze di clock, e via dicendo). Torno a lavorare, tenendo aperto OHM. Quando il beep ritorna, do subito un’occhiata ai valori da OHM: vedo la CPU intorno ai 60-62°C, per cui capisco che il problema sta tutto lì.

Indago indago, apro il Task Manager di Windows. Outlook 2013 sta occupando 2,1 GB di RAM (su 16 totali disponibili), e la CPU è sopra il 60% di carico. Chiudo Outlook 2013, ed ovviamente la RAM viene liberata, la CPU torna intorno al 2-3%, e la temperatura del processore torna su valori accettabili, intorno ai 29-32°C. Per quello che mi riguarda, considero Outlook 2013 come un virus vero e proprio: se lo lascio aperto (o se me lo dimentico – cosa che accade molto spesso), so per certo che finirà per occupare tutte le risorse di sistema.

Quella brutta bestia di Outlook 2013 ha colpito ancora, insomma.
Ancora una volta.

Send to Kindle
Hardware

Lumia 1020 in prova per una settimana

Grazie all’iniziativa di Nokia Italia, che qualche settimana fa aveva pubblicato un tweet attraverso il suo canale ufficiale, riceverò tra qualche giorno un meraviglio Nokia Lumia 1020, un Windows Phone vero autentico gioiello di tecnologia, soprattutto grazie alla incredibile fotocamera da ben 41 Megapixel.

Ieri ho completato la parte burocratica di questa cosa, ed oggi ho ricevuto l’SMS che mi comunica che riceverò lo smartphone entro 48 ore. Spero che arrivi presto, spero che arrivi sano e salvo. Mi vedrete twittare e fare sfoggio di quello che può fare e non fare. Ed aspettatevi anche una bella recensione qui sul mio blog.

Switch To Lumia, Stay tuned.

Send to Kindle
.NET World

WCF Service e Dependency Injection con Castle Windsor

Supponiamo di avere un servizio WCF, molto semplice in questo esempio, la cui interfaccia è la seguente:

[ServiceContract]
public interface ICalculation
{
    [OperationContract]
    int Calculate(int a, int b);
}

C’è un unico metodo che prende due interi e ne restituisce un terzo. Supponiamo adesso di scrivere il servizio WCF vero e proprio, cablando la logica del metodo Calculate per farlo funzionare come somma. Quindi:

public class Calculation : ICalculation
{
    public int Calculate(int a, int b)
    {
        return a + b;
    }
}

Primo refactoring. Spostiamo la logica della somma in una classe dedicata, che magari a sua volta implementa un’altra interfaccia che chiameremo IOperation.

public class Calculation : ICalculation
{
    public int Calculate(int a, int b)
    {
        IOperation operation = new SumOperation();
        var result = operation.Calculate(a, b);

        return result;
    }
}

Quello che accade è che ogni volta che viene invocato il metodo Calculate sul servizio WCF, viene creata una nuova istanza di una ipotetica classe SumOperation, che implementa IOperation, che effettua il calcolo ed il tutto torna al client. L’interfaccia IOperation è identica alla ICalculation, in questo caso, ma potrebbe avere una definizione diversa.

La cosa bella di questo approccio è che a questo punto posso creare classi come MultiplyOperation, SubtractOperation e così via. Basta cambiare il tipo istanziato nel servizio WCF, mentre tutto il resto rimane identico.

Passiamo al secondo refactoring.

public class Calculation : ICalculation
{
    IOperation calculationEngine;

    public Calculation()
    {
        this.calculationEngine = new MultiplyOperation();
    }

    public int Calculate(int a, int b)
    {
        var result = this.calculationEngine.Calculate(a, b);

        return result;
    }
}

Evitiamo di istanziare la classe ad ogni chiamata di Calculate. Definisco un field di tipo IOperation, la cui istanza concreta viene creata ed assegnata nel costruttore. Nell’esempio qui sopra creo un’istanza di MultiplyOperation, giusto per far capire che volendo posso switchare da un comportamento all’altro senza troppi problemi.

Quarto refactoring. Usiamo un motore di Dependency Injection, il cui scopo – detto in breve – è rimuovere tutte le new inserite nel codice (LoL).

Quello che mi piacerebbe ottenere è un codice come questo:

public class Calculation : ICalculation
{
    IOperation operationEngine;

    public Calculation(IOperation operation)
    {
        this.operationEngine = operation;
    }

    public int Calculate(int a, int b)
    {
        var result = this.operationEngine.Calculate(a, b);

        return result;
    }
}

In questo caso il costruttore stesso del servizio non è più parameter-less, ma prende in input un’istanza di un oggetto IOperation. Qualcuno deve fornire al servizio WCF questa istanza, e questo qualcuno è proprio un motore di Dependency Injection, nel nostro caso Castle Windsor.

La cosa non è così immediata, tra l’altro, perchè se provate adesso a mandare in esecuzione il servizio WCF qui sopra, sia attraverso il tool WcfTestClient.exe, oppure se tentate di raggiungere l’url del file .svc via browser, giustamente vi viene restituito un errore, perchè manca un costruttore parameter-less e quant’altro.

Quindi, ecco la soluzione.

  1. Con NuGet installate i pacchetti Castle Windsor e Castle Windsor WCF Integration Facility
  2. Al progetto aggiungete il file Global.asax

Modificate il codice della classe Global come segue:

public class Global : HttpApplication, IContainerAccessor
{
    public IWindsorContainer Container { get; private set; }

    protected void Application_Start(object sender, EventArgs e)
    {
        ServiceMetadataBehavior metadata = new ServiceMetadataBehavior();
        metadata.HttpGetEnabled = true;

        var Container = new WindsorContainer(new XmlInterpreter())
            .AddFacility<WcfFacility>()
            .Register(Component.For<ICalculation>()
            .ImplementedBy<Calculation>());
    }
}

La classe Global implementa l’interfaccia IContainerAccessor (di Castle Windsor), che richiede l’implementazione di una proprietà IWindsorContainer, che difatti abbiamo aggiunto. Nel codice di Application_Start viene istanziato il container di Windsor, e viene registrato il tipo ICalculation (l’interfaccia del servizio WCF), ed il tipo concreto Calculation. Il fatto di aver specificato XmlInterpreter nel costruttore del container ha un significato molto semplice: le registrazione dei tipi viene fatta leggendo il file web.config, che dobbiamo ancora gestire. Queste righe di codice vengono eseguite una sola volta, ovvero quando il servizio WCF parte.

Il web.config ha la seguente struttura:

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="castle"
         type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
  </configSections>
  <castle>
    <components>
      <component id="calc" service="CalculationEngine.IOperation, CalculationEngine"
                 type="CalculationEngine.SumOperation, CalculationEngine" />
    </components>
  </castle>
  <appSettings>
    <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5"/>
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <protocolMapping>
        <add binding="basicHttpsBinding" scheme="https" />
    </protocolMapping>    
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <directoryBrowse enabled="true"/>
  </system.webServer>

</configuration>

Nulla di complicato. Abbiamo definito una sezione dedicata a Castle Windsor, e poi abbiamo registrato i tipi che vogliamo che vengano gestiti da questo motore di DI. Nel nostro caso il tipo è uno solo, quello a cui fa riferimento l’interfaccia IOperation. Lo riporto qui sotto per chiarezza:

<castle>
  <components>
    <component id="calc"
                service="CalculationEngine.IOperation, CalculationEngine"
                type="CalculationEngine.SumOperation, CalculationEngine" />
  </components>
</castle>

L’attributo service indica il nome completo dell’interfaccia. L’attributo type indica il tipo concreto che implementa l’interfaccia. Da questo momento in poi Castle Windsor sa risolvere questa dipendenza: ogni volta che nel codice il costruttore di una classe richiederà un’istanza di IOperation, verrà restituita la classe SumOperation. Chiaramente, possiamo modificare questo setting e specificare qualsiasi altra classe che implementi quell’interfaccia, senza ricompilare il nostro codice.

L’ultima cosa da fare è editare il file .svc, impostandolo come segue:

<%@ ServiceHost Language="C#" Debug="true" Service="CalculationEngine.Calculation"
    Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory, Castle.Facilities.WcfIntegration"
    %>

Qui è importante il parametro Factory, dove abbiamo specificato la factory che Castle Windsor utilizza per i servizi WCF. Basta, abbiamo finito.

Proviamo ad eseguire?

Se adesso proviamo ad eseguire il nostro progetto, vedrete che tutto funziona bene. Cosa intendo? Intendo che parte il browser, potete navigare verso il file Calculation.svc, e quindi il servizio WCF è pronto all’uso. Questo significa che per esempio possiamo utilizzare il tool WcfTestClient passandogli l’url del servizio. Quello che accade è che Castle Windsor:

  1. Legge il file web.config e registra i tipi nel suo container, così è pronto per risolvere le dipendenze
  2. Sa che deve istanziare il servizio WCF: quando tenta di farlo, trova un costruttore che richiede un’istanza di qualcosa che implementi IOperation. Sa risolvere questa dipendenza, per cui passa al costruttore un’istanza di ciò che è specificato nel web.config (nel nostro caso SumOperation)

Fine. Il WCF si mette in attesa di qualcuno che invochi il metodo Calculate. Quando qualcuno lo fa, viene effettuato il calcolo. Ovviamente, è sufficiente modificare il web.config, specificando un altra classe IOperation, per cambiare il comportamento della nostra classe senza ricompilare nulla.

Magie della Dependency Injection!!

Qualsiasi commento e/o correzioni è sempre ben accetta.

Download della solution con Visual Studio 2012.

Send to Kindle
.NET World

Migrare dalla vecchia versione di Lightswitch a quella nuova

Mi spiego meglio. Quella vecchia è quella usabile da Visual Studio 2010, la versione 1.0. Quella nuova è quella integrata in Visual Studio 2012.

In Brain-Sys abbiamo sviluppato un gestionale per un nostro cliente, proprio con la versione 1.0 di Lightswitch. Inutile dire che lo sviluppo è stato estremamente rapido, ed il deploy altrettanto. Seguire le continue richieste del cliente (compreso qualche leggero bug-fixing) è sempre un’operazione piuttosto semplice, compreso aggiornare l’applicazione sul server di produzione. Penso che Lightswitch sia lo strumento di sviluppo più RAD che abbia mai visto, dai tempi di…Access. Eppure le differenze con Access ci sono eccome, perchè in realtà l’interfaccia utente dell’applicazione web (che gira in browser in un’applicazione Silverlight) comunica con il database attraverso un servizio WCF, mettendo così in piedi – in modo totalmente automatico – un’applicazione three-tier. Ovvio che il servizio WCF è consumabile anche da app di altra natura (è un servizio esposto via http), come Windows Phone o Windows 8, e quindi…lascio immaginare a voi quali sono le piacevoli conseguenze di tutto questo.

Ma torniamo a noi.

In questi giorni ho dovuto affrontare un problema che magari potrebbe capitare anche a voi. Lo scenario è il seguente: supponiamo di aver sviluppato e messo online, un anno fa, un’applicazione Lightswitch 1.0, che il cliente ha cominciato ad usare con successo, riempiendo il database con anagrafiche, fatture, eccetera eccetera. Dopo un anno, oggi appunto, il cliente vi chiede una piccola modifica. Peccato che l’applicazione venne creata e compilata con VS2010, mentre oggi voi volete gestire il tutto con VS2012. Perchè? Per una serie di motivi, il più importante dei quali si può riassumere nella seguente frase.

In Brain-Sys crediamo fermamente che sia importante utilizzare gli strumenti di sviluppo più recenti, per non rimanere tagliati fuori, per usare sempre l’ultimo .NET Framework disponibile. Se si aspetta troppo, se si perde l’onda, se si lasciano “decantare” troppo le tecnologie, esse finiranno per diventare obsolete. Ed arriverà il momento in cui sarà troppo tardi, e magari dovremo ricreare l’applicazione da zero. Chiaramente questa filosofia si scontra con la pratica, con il web-server a disposizione, con le richieste del cliente, con vincoli e requisiti entro i quali dobbiamo stare. Ma facciamo di tutto per farcela, insomma.

Beh, insomma, come ho risolto la migrazione dell’applicazione Lightswitch 1.0 alla 2.0, senza perdere i dati del cliente, e facendo in modo che per lui sia stato tutto trasparente? Ecco una piccola scaletta.

  1. Backup dell’applicazione attuale (database SQL Server e file system)
  2. Conversione dell’applicazione Lightswitch 1.0 con Visual Studio 2012
  3. Deploy dell’applicazione sul vostro IIS locale
  4. Restore in locale del database del cliente e aggiornamento schema
  5. Test in locale dell’applicazione
  6. Messa in produzione della nuova applicazione

Dettagli punto (1)
In breve: ho un bel folder sul proprio PC con il .bak del database SQL Server corrente (pieno di dati dell’utente) e tutti i files che compongono l’applicazione (xap, dll, web.config e via dicendo). Ovviamente tutto questo è l’applicazione alla versione 1.0 di Lightswitch. Così in caso di problemi potremo tornare indietro senza troppi danni.

Dettagli punto (2)
Nulla di particolarmente complicato, in apparenza. Aprite la solution con VS2012: lui si accorgerà che l’applicazione è stata creata con una versione precedente di Lightswitch e vi proporrà la conversione. Accettate e siete a posto. Attenzione: assicuratevi di aver installato le stesse extension Lightswitch che avevate usato all’epoca, ed assicuratevi inoltre che esse siano compatibili con VS2012. Se tutto va bene, riuscirete a compilare e ad eseguire l’applicazione da Visual Studio con un semplice F5. Se questo avviene, siete già a buon punto, perchè forse è la parte più critica.

Dettagli punto (3)
Io mi sono trovato comodo così, ovvero: ho installato IIS sul mio PC locale, e da Visual Studio 2012 ho deployato l’applicazione Lightswitch in locale, quindi ad un url tipo http://localhost/mia_applicazione. Ricordo che Visual Studio deve essere avviato come Administrator. Il wizard si occuperà di chiedervi tutte le informazioni necessarie, compreso il database da utilizzare. Io ho utilizzato l’istanza di SQL Server Express locale, fornendo le connection string di un database completamente vuoto. Il wizard crea lo schema del database. Fatto questo, potete aprire un browser, navigare all’url, avviare ed usare l’applicazione Lightswitch installata localmente sul vostro PC. Chiaramente il database sottostante è completamente vuoto, perchè è stato appena creato ex-novo da Visual Studio. E’ ora di importare i dati del cliente!

Dettagli punto (4)
Ok, allora. Prendete il .bak di cui avete fatto il backup al punto (1) e restoratelo sul database che avete creato al punto (3). Attenzione, però. C’è una piccola ma grande differenza tra una tabella creata da Lightswitch 1.0 e da Lightswitch 2.0. Ogni tabella contiene un campo RowVersion di tipo timestamp. Quindi, per esempio, se nella vostra applicazione Lightswitch 1.0 avevate un’entità Person, con Surname e Name, la tabella conterrà i campi ID, Surname, Name. La stessa entità creata con Lightswitch 2.0, oltre a questi campi, ha anche RowVersion.

Quindi, facciamo mente locale. L’applicazione Lightswitch deployata sul vostro IIS è alla versione 2.0, quindi si aspetta che tutte le tabelle abbiano questo famigerato campo RowVersion. Ma il database che abbiamo appena restorato ha uno schema che fa riferimento a Lightswitch 1.0, per cui quello che dobbiamo fare è banalmente andare ad aggiungere il campo con una semplice ALTER TABLE:

ALTER TABLE [dbo].[NomeTabella]
ADD [RowVersion] [timestamp] NOT NULL
GO

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Io ho creato uno script che fa questa semplice operazione su tutte le tabelle che compongono la mia applicazione. Ho preferito uno script perchè verrà molto, molto comodo quando sarà il momento di mettere on-line la nuova applicazione Lightswitch, perchè basterà eseguirlo per aggiornare il database.

Dettagli punto (5)

Fatto questo, siete a posto. Avete migrato l’applicazione da Lightswitch 1.0 a Lightswitch 2.0, con tutti i vantaggi del caso, e senza perdere alcun dato inserito dal nostro cliente. Provate l’applicazione in locale, fate tutte le prove possibili ed immaginabili. Tanto state usando un database locale, sul vostro PC, perciò niente danni per il cliente, no? Se siete soddisfatti, potete mettere tutto on-line davvero.

Dettagli punto (6)

Ok, come si aggiorna l’applicazione Lightswitch sul server di produzione? Come qualsiasi altra applicazione .NET, ovvero: aggiornando un po’ di files sul server, magari trasferendoli via ftp. Io di solito sto molto attento a questo. Non faccio un “seleziona tutto”, “trasferisci”. Copio le dll, il nuovo xap, etc. etc. Evito il web.config (che magari contiene qualche configurazione particolare, soprattutto le connection string). Prima di provare l’applicazione, ricordatevi il database. Eseguite lo script con le ALTER TABLE sul database di produzione, che andrà ad aggiungere il campo RowVersion su tutte le tabelle: esattamente ciò che avete fatto prima sul vostro database locale.

Un’ultima osservazione 

Ho notato una cosa strana. La nostra applicazione chiede un login, all’avvio. Con Lightswitch 1.0, la pagina Silverlight che permette il login è piuttosto spartana. C’è una casella per l’inserimento del nome-utente, una per la password ed un bottone Accedi. Basta. Niente loghi, niente immagini. Essenziale, diciamo. Una volta migrata l’applicazione in Lightswitch 2.0, questa pagina è cambiata, ed a me appariva un enorme rettangolone giallo, che proprio non ho capito da dove arrivasse. Praticamente occupava il 90% della pagina, giusto sopra le due caselle sopra citate. Alla fine ho capito. Sono andato nelle proprietà del progetto Lightswitch, sotto “General Properties”, e qui c’è una voce “Logo image”, che puntava ad un file “ResourcesBackground.png”. E guarda caso questa immagine .png era proprio un rettangolo giallo. Ho sostituito questa png con qualcosa di più gradevole (ad esempio…il logo dell’applicazione, il logo dell’azienda del cliente) et voilà: a questo punto la pagina di login non mostra più il rettangolo giallo di prima, ma la nuova immagine che abbiamo impostato.

Direi che la missione è compiuta!!

Send to Kindle