Una delle features più interessanti di Lightswitch è la sua possibilità di effettuare il deploy direttamente sul server Web da cui poi sarà fruibile. Una comodità che fa piacere ai developer meno skillati, e che accelera il lavoro ai developer più esperti.

Il server Web può essere locale, all’interno della vostra LAN oppure esposto su Internet. In quest’ultimo caso, è necessario che il provider abbia installato tutti i pre-requisiti di Lightswitch. Come avevo citato nel mio primo post dedicato a Lightswitch, le possibilità di deploy messe a disposizione sono due:

1. Deploy diretto da Visual Studio 2010
2. Generazione in locale sul proprio PC un file di package (che non è nient’altro che un file zip), da importare sul server Web tramite la console IIS installata localmente sul proprio PC

Nel mio caso specifico, con www.winhost.com, sono obbligato a seguire la procedura (2). Non sto qui a scendere nel dettaglio: vi basti sapere che da VS2010 producete un file di package (.zip), che contiene tutti i files necessari per deployare l’applicazione: files, script SQL, parametri per la creazione dell’applicazione sotto IIS, etc. etc.

L’applicazione su cui sto lavorando per Brain-Sys fa utilizzo anche dell’autenticazione offerta dal Membership Provider. In questo caso, nel momento in cui effettuate l’installazione dell’applicazione su IIS, il wizard vi chiede, tramite una dialog dedicata, anche username & password dell’utente Administrator, per fare il primo login e procedere alla creazione degli altri utenti & ruoli, etc. etc. Per motivi che onestamente non siamo riusciti a capire, a me questa dialog non compare. Risultato? L’applicazione veniva deployata senza alcun problema, e raggiungendo il suo url (esempio: http://www.dominio.it/Nomeapp) appariva la form di login, ma non essendoci utenti configurati (ripeto: nemmeno l’Administrator) … difatto l’applicazione rimaneva inutilizzabile.

Ma abbiamo trovato una soluzione, spiegata in questo thread.

In pratica, tutta la struttura del database è ok: quello che manca è un bel record all’interno della tabella aspnet_Users (e qui ovviamente stiamo parlando di Membership Provider). Escludiamo a priori di aggiungere manualmente un record: non si fa, non si fa, non si fa. E quindi, cosa si fa? Semplice.

Se avete installato Lightswitch sul vostro PC, andate nella directory:
C:Program Files (x86)Microsoft Visual Studio 10.0LightSwitch1.0Tools

All’interno di questa directory trovate il file Microsoft.LightSwitch.SecurityAdmin.exe. E’ sufficiente eseguire da command-line questo comando…
Microsoft.LightSwitch.SecurityAdmin.exe/createadmin /user:Admin /password:pwd /fullname:Administrator /config:C:Documentiweb.config

…per ottenere il vostro utente Administrator. Qualche precisazione:

• /user:nome_utente (va specificato lo username dell’utente che volete creare)
• /password:password_utente (va specificata la password dell’utente che volete creare)
• /fullname:nome_completo (va specificato il nome completo dell’utente)
• /config:filepath (va specificato il percorso completo del web.config sul vostro PC, che contiene la stringa di connessione che punta al database che vi interessa)

Se il comando non vià segnala alcun errore, significa che l’utente Administrator è stato creato con successo. Potete loggarvi all’interno della vostra applicazione Lightswitch. Se fatta a dovere, la vostra applicazione vi mette a disposizione tutti gli strumenti per creare altri utenti, altri ruoli, e per effettuare l’assegnamento di ruoli ai singoli utenti.

Et voilà, problema risolto!

Send to Kindle

www.microsoft.com/visualstudio/en-us/lightswitch/overview/comparePochi giorni prima delle mie ferie, esattamente il 27 Luglio scorso, ho seguito un evento in streaming dedicato interamente a Microsoft Lightswitch 2011, organizzato dalla community italiana dedicata proprio a questo nuovo prodotto. Per chi se lo fosse perso, le registrazioni alle varie sessioni sono disponibili a questo indirizzo (attenzione, dovete essere utenti registrati per visionarli).

Fino a quel giorno avevo sentito parlare poco di Lightswitch 2011. Qualche tweet, qualche news, qualche post da parte del nostro amico Alessandro Del Sole. L’evento, molto interessante, ha messo in mostra le caratteristiche principali del software, partendo dai concetti più semplici fino alle features più avanzate. Non so perchè, deve essere stato una sorta di sesto senso, ma sentivo che Lightswitch potesse essere un cavallo su cui puntare, e sono riuscito a trasmettere questo interesse internamente a Brain-Sys. Ho seguito l’evento, sessione dopo sessione, ho twittato i contenuti che trovavo più stuzzichevoli e ne sono uscito con una determinazione che mi ha fatto dire: “Cascasse il mondo, devo provarlo e studiarlo almeno un po’!”.

Ma torniamo un po’ all’inizio. Cos’è esattamente Microsoft Lightswitch? Definirlo è forse un po’ complicato. Le caratteristiche che lo contraddistinguono sono:

• Strumento di sviluppo RAD (Rapid Application Development)
• Viene di fatto installato all’interno di VS2010, comparendo come nuovo tipo di progetto (nota: Lightswitch è utilizzabile anche come prodotto stand-alone, vedere in fondo al post)
• Ideale per applicazioni data-centriche
• Generazione automatica di tabelle ed interfaccia utente Silverlight 4 (applicazione desktop OOB oppure fruibile via browser)
• Infrastruttura n-tier con WCF RIA Services
• Deploying automatico su un server Web (esempio: un server Web locale, oppure remoto in hosting come winhost.com, etc.)
• Supporto per le autenticazioni e autorizzazioni tramite Membership Provider
• Estendibilità tramite controlli custom
• Al 100% mi sto dimenticando di qualcosa: vi consiglio di googlare o di visitare il sito Web ufficiale per tutte le info
  

Il fatto è che se dovete creare un’applicazione Web in breve tempo per costruire anagrafiche, un piccolo gestionale, una rubrica, un archivio di qualche tipo, qualsiasi cosa che lavori sui dati, probabilmente Lightswitch 2011 fa al caso vostro. Il database è completamente auto-generato in base alle entity che disegnate, la UI è auto-generata in base a ciò che stabilite all’interno dello Screen Designer, potete inserire regole di validazione, potete avere la UI localizzata, potete scrivere codice custom (ad esempio per aggiungere calculated property, per aggiungere alla UI Button custom, per validare entity), potete creare controlli Silverlight da incorporare in Lightswitch. Insomma, il vostro lavoro può partire considerando Lightswitch come un ambiente di sviluppo “sempliciotto” e molto RAD, ma vi posso assicurare che, spremendolo a dovere, potete ottenere degli ottimi lavori.

Parliamo di deploy. Quando la vostra applicazione è terminata, dovete ovviamente deployarla da qualche parte. La procedura di publishing di Lightswitch fa in modo di semplificare il più possibile il compito al developer (assumendo che non abbia skill a sufficienza) e può avvenire secondo due metodi:

1. Deployare direttamente da Visual Studio 2010 sul server Web (locale o remoto)
2. Generare in locale sul proprio PC un file di package (che non è nient’altro che un file zip), da importare sul server Web tramite la console IIS installata localmente sul proprio PC

In ambedue i casi, ovviamente, dovete avere i permessi e le credenziali adeguate. Non solo: se stiamo parlando di deployare su un vostro hosting (come nel mio caso http://winhost.com o http://discountasp.net), dovete assicurarvi che questi supporti Lightswitch, con tutta una serie di pre-requisiti. Il provider può adeguarsi in modo piuttosto semplice usando il Web Platform Installer, che fa tutto in automatico. E se invece cercate un hosting già pronto per Lightswitch, il sito Microsoft riporta qualche informazione in merito a questo indirizzo. Ultima menzione: Lightswitch supporta anche il deploy su Azure. Mica male, no?

Per concludere, in circa una settimana di lavoro ho messo in piedi un prodotto che – se fatto da zero ed a parità di complessità tecnologica – avrebbe richiesto sicuramente molto, molto, molto più tempo. Trattandosi di un progetto reale non posso in questo momento scendere nel dettaglio, ma vi posso assicurare che la produttività è stato altissima, al punto che abbiamo già deployato una versione beta da far vedere al cliente.

Ultimissime note: grazie ad Alessandro Del Sole per il suo costante impegno ad aiutare il prossimo, e grazie a tutta la community italiana www.lightswitch.it, che si dimostra attiva e di buon livello, considerando che si tratta di un prodotto appena uscito sul mercato.

Giovedì 1 Settembre 2011, 22:24 – Aggiornamento dell’ultim’ora. Giustamente, mi è stata fatta notare una cosa importante su Microsoft Lightswitch. Se già possedete Visual Studio 2010, Lightswitch si installa all’interno di questo ambiente di sviluppo – come già ho detto prima, lo avete come un nuovo tipo di progetto. Se non possedete Visual Studio 2010, niente paura: Lightswitch è anche un IDE separato, per cui potete tranquillamente utilizzarlo anche in questo modo. Qualche info in merito la trovate qui (comparazione tra Lightswitch stand-alond e Lightswitch con VS2010).

Send to Kindle

Il titolo non potrebbe essere più esplicativo. Per lo stesso progetto che ho accennato nel mio post di ieri ho dovuto cercare una soluzione per:

1. sfruttare il drag’n’drop nella UI dell’applicazione WPF
2. fare in modo che tale meccanismo non sia troppo invasivo, e non mi costringa a riscrivere da zero i miew ViewModel già pronti
3. fare in modo che tale meccanismo utilizzi i Command già predisposti nei miei ViewModel
4. il drag’n’drop deve poter utilizzare gli stessi Command già funzionanti per la parte non drag’n’drop

Mi spiego meglio sul punto (4). Ho sempre preferito fare in modo di adattare la stessa UI, in modo tale che possa essere usabile in diversi modi, facendo in modo che l’utente possa scegliere istintivamente quello che preferisce. Quindi, supponiamo di avere questa interfaccia utente:

E’ una cosa piuttosto semplice: sulla sinistra abbiamo un elenco di nomi, a destra abbiamo una TextBox che mostrerà la persona che abbiamo scelto. In questo caso voglio dare la possibilità all’utente di scegliere una persona dall’elenco in due modi differenti:

• selezionandola dall’elenco e poi cliccando sul bottoncino con la freccia “—>”
• trascinandola dall’elenco sopra la TextBox

Sebbene si trattino di due interazioni diverse, vorrei poter riciclare gli stessi Command (sia per quanto riguarda la parte Execute, che la parte CanExeCute)

Sul Web, googlando, ho trovato un po’ di soluzioni, ma lo ho scartate tutte quante, un po’ perchè invasive (soprattutto per essere inserite su un progetto già avviato), un po’ perchè complesse (capire decine, decine e decine di linee di codice non tue può rivelarsi poco piacevole). Quindi mi sono messo di buona lena ed ho realizzato una classe DragService (283 linee di codice ben formattate) che soddisfa tutti i miei requisiti.

Vediamo quindi come si utilizza questa mia classe.

Come utilizzare VivendoByte.WPF.DragService
Lo screenshot qui sopra è ovviamente un’applicazione WPF, implementata secondo i soliti metodi richiesti dal pattern MVVM:

xmlns:l="clr-namespace:DragAndDropDemo"
xmlns:drag="clr-namespace:VivendoByte.WPF.DragService;assembly=VivendoByte.WPF.DragService"

Innanzitutto, ho dichiarato i namespace che mi servono: “l” è l’assembly locale, mentre “drag” fa riferimento all’assembly VivendoByte.WPF.DragService. Il ViewModel viene inserito fra le risorse della Window corrente; il DataContext della Grid prende questo ViewModel e fa in modo di governare la view.

<Window.Resources>
    <l:MainViewModel x:Key="vm" />
</Window.Resources>
    
<Grid DataContext="{StaticResource vm}">
...
</Grid>

La prima parte interessante riguarda la ListBox posizionata a sinistra sulla finestra:

<ListBox Grid.Row="0" Margin="4" ItemsSource="{Binding Persons}"
            Background="LightGoldenrodYellow"
            SelectedItem="{Binding DraggingPerson}">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock
                    Text="{Binding Fullname}" FontSize="24"
                    drag:DragService.SourceCommand="{Binding
                        RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=Grid},
                        Path=DataContext.DragCommand}"
                    drag:DragService.SourceCommandParameter="{Binding}" />
            </StackPanel>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

La ListBox è bindata ad un elenco di persone (proprietà Persons del ViewModel); l’elemento selezionato è bindato sulla proprietà DraggingPerson. All’interno della ListBox ho definito un semplice DataTemplate, per permettere di mostrare ogni elemento in modo più furbo: usando la proprietà Fullname esposta da Person. E qui arriva il barbatrucco.

Sulla TextBlock ho bindato un Command, comprensivo di parametro. Siccome ci si trova all’interno di un DataTemplate, ho dovuto utilizzare RelativeSource per permettere al motore di WPF di navigare il logical tree della Window, raggiungere la Grid su cui è impostato il DataContext e – finalmente – prendere il Command interessato (nel nostro caso DragCommand). La cosa interessante è questa:

• Nel momento in cui parte la nostra operazione di drag su un elemento della ListBox viene eseguita la CanExecute del Command associato; se la CanExecute fallisce (ritorna false) il drag non parte nemmeno
• Se invece la CanExecute ritorna true, parte l’operazione di dragging

La stessa cosa bene o male accade per la TextBox, che è la destinazione del drag’n’drop. Invece di utilizzare SourceCommand e SourceCommandParameter, devono essere utilizzate TargetCommand e TargetCommandParameter.

<StackPanel Grid.Column="1" Margin="4">
    <TextBlock Text="Trascina una persona" FontSize="24" Height="40" />
    <DockPanel>
        <Button Content="-->" Margin="8" Width="32" Command="{Binding DropCommand}" />
        <TextBox Background="LightGoldenrodYellow" Text="{Binding SelectedPerson.Fullname,Mode=OneWay}"
                    FontSize="24" Height="40"
            drag:DragService.TargetCommand="{Binding DropCommand}" />
    </DockPanel>
    <Button Content="Rimuovi persona" Margin="8" Command="{Binding ClearPersonCommand}" FontSize="20" />
</StackPanel>

La TextBox è bindata al comando DropCommand. Questa volta il binding è diretto, dal momento che non ci si trova più dentro un DataTemplate, e quindi il riferimento al DataContext della Grid è diretto. Anche in questo caso:

• Nel momento in cui passiamo sopra la TextBox durante il drag’n’drop, viene eseguita la CanExecute. Se ritorna false, l’icona del mouse diventa il classico divieto. Se ritorna true, tutto bene: sul controllo appare l’Adorner ed il drag’n’drop può concludersi
• Se rilasciamo il tasto del mouse sopra il controllo, viene eseguito il command

Notare che il Button è bindato allo stesso comando DropCommand. Difatti, l’utente può draggare una persona dalla ListBox, o semplicemente selezionarla e poi cliccare il bottone.

Ultime piccole osservazioni

Provate a selezionare o a draggare l’elemento “Sabrina Pedretti”. E’ minorenne, e siccome la CanExecute del DragCommand impone che la persone sia maggiorenne, ecco che su questo elemento l’operazione di drag’n’drop non avviene. Davvero molto comodo: possiamo annullare il drag’n’drop nel momento in cui l’utente tenta di cominciarlo, sfruttando i Command e quindi rispettando appieno il paradigma M-V-VM. Il button “—>” anche in questo caso di spegne, per lo stesso motivo: lo stesso metodo CanExecute che impedisce il drag’n’drop fa spegnere il Button, perchè il command DragCommand non è disponibile.

I Command del ViewModel sono implementati attraverso la libreria Galasoft, di Laurent Bignon. Sono supportati sia il RelayCommand normale, che quello tipizzato. Nel progettino demo, il comando DragCommand è tipizzato sulla classe Person (nello XAML è stato specificato il SourceCommandParameter), mentre il comando DropCommand no (per capire quale elemento sto draggando utilizzo la proprietà DraggingPerson del ViewModel, impostata all’inizio del drag’n’drop).

Il Button indicato come “Rimuovi persona” svuota semplicemente la TextBox per ricominciare un’altra operazione di drag’n’drop. E lo fa agendo sulla proprietà SelectedPerson esposta dal ViewModel.

Disponibile attraverso NuGet!

Se utilizzate NuGet per la gestione degli assembly all’interno delle vostre solution VS2010, sappiate che potete trovare la libreria VivendoByte.WPF.DragService, scaricabile gratuitamennte e pronta all’uso. Ringrazio Alessandro Melchiori per la sua sessione presso l’ultimo workshop UGIdotNET, dove ha illustrato NuGet da diversi punti di vista, compreso quello del developer, ovvero come pubblicare proprie librerie sul repository pubblico.

Download del progetto demo

Se invece siete interessati al progetto demo, piccola applicazione WPF da cui è stato tratto lo screenshot sopra, è scaricabile dal mio account SkyDrive.

Send to Kindle

Oggi riprendo in mano Windows Live Writer per parlarvi di un’esigenza nata nei giorni scorsi, e che ho risolto (almeno tecnicamente) questa notte, anche se ho dovuto fare le ore piccole.

In questo momento, sul marketplace per Windows Phone 7 ci sono 21 applicazioni I Love Qualcosa (dove “Qualcosa” sta per Milan, Juventus, Roma, Palermo, Inter, etc. etc – il numero è disparsi perchè ho creato anche I Love Foppa, dedicata alla Foppapedretti Bergamo, squadra femminile di pallavolo). Le app sono ovviamente già disponibili da parecchio tempo (qualche mese) e nei giorni scorsi mi son posto la domanda: cosa dovrei fare se volessi ricompilarle tutte in modo massivo? Dal punto di vista tecnologico:

1. E’ ovviamente un progetto di tipo Windows Phone 7
2. E’ organizzata come unica solution ed unico project
3. Esiste un file AssemblyInfo*.cs specifico per ogni squadra (quindi AssemblyInfoMilan.cs, AssemblyInfoInter.cs, e così via)
4. Esiste un file WMAppManifest*.xml specifico per ogni squadra (quindi WMAppManifestMilan.xml, WMAppManifestInter.xml, e così via)
5. I files dei punti (3) e (4) sono inclusi nel progetto (per maggiore facilità nella loro gestione) in folders dedicati, ed impostati come Build Action a None (in modo tale che non finiscono nel file .xap, il compilato finale)

Quindi, vi chiederete voi, come si fa ad ottenere I Love Milan piuttosto che I Love Inter?

Fino ad oggi questi passaggi li ho fatti manualmente. Supponiamo di voler generare ILoveMilan.xap.

1. Copiavo il file AssemblyInfoAssemblyInfoMilan.cs in PropertiesAssemblyInfo.cs
2. Copiavo il file WMAppManifestWMAppManifestMilan.xml in PropertiesWMAppManifest.xml
3. Modificavo il file MainPage.xaml.cs per modificare una variabile stringa contenente il nome della squadra
4. Entravo nelle proprietà del progetto per specificare il nome del file di output (in questo caso ILoveMilan.xap)

Tutto qua: poi lanciavo la compilazione e mi trovavo il file da inviare sul marketplace. Da notare che i files indicati ai punti (1) e (2) contengono una serie di importanti informazioni per l’app: titolo, descrizione, quali icone usare nelle varie dimensioni, etc. etc. Di fatto, sostituendoli, vengono sostituite informazioni essenziali dell’app stessa.

Quello che ho fatto stanotte è quindi automatizzare i quattro passaggi, inizialmente tentando di fare tutto con MSBuild.exe, poi rinunciando (causa scarsa conoscenza dello strumento) per passare ad una più “tradizionale” console application. C’è da dire questo: penso che non ci sia una soluzione unica e che vada bene per tutti, perchè ovviamente il tutto dipende da come avete strutturato la vostra solution. Vi racconto come ho fatto io.

Qualche dettaglio sulla console application
Il discorso è molto semplice. Ho creato un metodo generateTeam:

   1:  static void generateTeam(string team)

   2:  {

   3:      string path1;

   4:      string path2;

   5:   

   6:      path1 = baseDir + @"AssemblyInfoAssemblyInfo" + team + ".cs";

   7:      path2 = baseDir + @"PropertiesAssemblyInfo.cs";

   8:      File.Copy(path1, path2, true);

   9:   

  10:      path1 = baseDir + @"WMAppManifestWMAppManifest" + team + ".xml";

  11:      path2 = baseDir + @"PropertiesWMAppManifest.xml";

  12:      File.Copy(path1, path2, true);

  13:   

  14:      string mainPage = getResource("ConsoleApplication1.MainPage.xaml.cs1") + team + getResource("ConsoleApplication1.MainPage.xaml.cs2");

  15:      path1 = baseDir + "MainPage.xaml.cs";

  16:      File.WriteAllText(path1, mainPage);

  17:   

  18:      string csproj = getResource("ConsoleApplication1.ILoveFootballTeam.csproj1") + team + getResource("ConsoleApplication1.ILoveFootballTeam.csproj2");

  19:      path1 = baseDir + "ILoveFootballTeam.csproj";

  20:      File.WriteAllText(path1, csproj);

  21:   

  22:      msbuildClean();

  23:      msbuildCompile();

  24:   

  25:      path1 = baseDir + @"binReleaseILove" + team + ".xap";

  26:      if (File.Exists(path1))

  27:      {

  28:          path2 = @"X:OutputILove" + team + ".xap";

  29:          File.Copy(path1, path2, true);

  30:      }

  31:  }

Scusate la qualità del codice, ma alle 2 di notte non sono granchè!

Alle righe 6-8 aggiorno e sovrascrivo il file AssemblyInfo.cs.

Alle righe 10-12 aggiorno e sovrascrivo il file WMAppManifest.xml.

Alle righe 14-16 sovrascrivo il file MainPage.xaml.cs, sfruttando un meccanismo “balordo” (ma che funziona!) con files Embedded Resource.

Alle righe 18-20 aggiorno il file .csproj, anche qui usando come template dei files inclusi come Embedded Resource.

Alla fine chiamo due metodi, msbuildClean() e msbuildCompile().

   1:  static void msbuildClean()

   2:  {

   3:      ProcessStartInfo start = new ProcessStartInfo();

   4:      start.FileName = @"C:WindowsMicrosoft.NETFrameworkv4.0.30319msbuild.exe";

   5:      start.Arguments = @" /p:Configuration=Release /t:Clean ILoveFootballTeam.csproj";

   6:      start.UseShellExecute = false;

   7:      start.WorkingDirectory = baseDir;

   8:      start.WindowStyle = ProcessWindowStyle.Normal;

   9:   

  10:      Process process = new Process();

  11:      process.StartInfo = start;

  12:      process.Start();

  13:      process.WaitForExit();

  14:  }

   1:  static void msbuildCompile()

   2:  {

   3:      ProcessStartInfo start = new ProcessStartInfo();

   4:      start.FileName = @"C:WindowsMicrosoft.NETFrameworkv4.0.30319msbuild.exe";

   5:      start.Arguments = @" /p:Configuration=Release ILoveFootballTeam.csproj";

   6:      start.UseShellExecute = false;

   7:      start.WorkingDirectory = baseDir;

   8:      start.WindowStyle = ProcessWindowStyle.Normal;

   9:   

  10:      Process process = new Process();

  11:      process.StartInfo = start;

  12:      process.Start();

  13:      process.WaitForExit();

  14:  }

IMPORTANTE: attenzione a NON usare l’msbuidl.exe contenuto in C:WindowsMicrosoft.NETFramework64v4.0.30319, perchè NON compila. Io stesso ho perso un sacco di tempo nel cercare di capire il perchè. Evidentemente, e probabilmente, il .NET Framework a 64 bit non c’entra nulla con wp7.

Eseguo msbuild.exe in due step separati: il primo fa la Clean della nostra binRelease, il secondo per effettuare la compilazione vera e propria.

Se tutto è andato a buon fine, prendo il file .xap generato e lo copio dove voglio io (righe 25-29 del primo blocco di codice).

Questo è il meccanismo che sta alla base. A questo punto è possibile chiamare generateTeam(“Milan”), generateTeam(“Cesena”), generateTeam(“Inter”), generateTeam(“Fiorentina”) per ottenere in una directory tutti gli .xap generati.

E adesso che abbiamo gli xap, come faccio ad inviarli sul marketplace?

Qui arrivano le note dolenti. E’ vero che in un battito di ciglia abbiamo le nuove versioni delle nostre app, ma per inviarle al marketplace occorre fare tutto manualmente, e qui non ci sono storie. Bisogna avere le icone nelle varie dimensioni, gli screenshots della nostra app, i testi e le descrizioni, etc. etc. E se avete 70 applicazioni (come l’amico Matteo), siete proprio fregati!

Domande? Sono tutt’orecchi.

Send to Kindle