Possibile che esista ancora gente con la testa fissa su Visual Basic 6?

Oggi, parlando con un mio amico, vengo a sapere che si è appena iscritto e ha iniziato a frequentare un corso di Visual Basic.
Gli chiedo:

visual basic e basta o visual basic .net?

Ed ecco la sua risposta:

visual basic e basta...
il punto net ha detto che per ora è ancora presto...
per una serie di motivi...
il principale è che è appena uscito e non è ancora molto stabile...
parole sue...
visto che lo usa da 20 anni credo che sappia quel che dice...

Mi chiedo: ma com'è possibile che puntino ancora a fare formazione su vb 6?
Quello che mi da fastidio è che parlino male di .net invece di dire realmente come stanno le cose.
E' appena uscito?! E' pubblico dal 2001 (e dico pubblico).
Non è stabile ?! Siamo alla versione 3 e è usato in moltissime applicazione, e di ogni tipo.

Che dire... sono rimasto davvero senza parole nell'aver sentito tutto ciò e specialmente di come un insegnante faccia pubblicità (negativa) al Framework .NET.

E che dire a chi ha speso 200€ per quel corso?!
Ma gli hanno avvisati che Microsoft non supporterà ancora per molto vb6?

Nel frattempo lo ho invitato a casa mia, così gli mostrerò una parte del mondo .NET, e poi lascio a lui tirare le somme. Credo che fargli vedere come si sviluppa usando il Framework 2.0 (o magari con il 3.0) sia la soluzione migliore per fargli aprire un pò gli occhi.

Avete letto giusto, "oggi è il mio giorno".

Il giorno in cui tutto va per il verso giusto. Il giorno in cui parecchie cose che erano solo speranze si avverano... per voi magri sembrerà una banalità, ma ho finalmente la ADSL a casa mia (e credetemi che è stata un'avventura) e in più oggi mi è stata attivata l'abbonamento MSDN che Davide mi ha regalato.

Per quanto riguarda l'ADSL sono stra felice perchè è da un mese che tartasso quelli della Telecom perchè è dal 26 ottobre che mi hanno allacciato la linea telefonica e non ha MAI funzionato. Ho chiamato molte e molte volte il 187, ma solamente oggi, dopo quasi un mese, un tecnico si è degnato di uscire e risolvere un problema in cabina.

Per quanto riguarda la MSDN, avevano avvisato approsivativamente 4 settimane di attesa per l'attivazione, e sono stati puntualissimi, perchè le 4 settimane sono scadute ieri.

Ecco il perchè di tutta questa mia gioia!!

Per un pò rimarrò ancora tra le nuvole, in questo stato di massima felicità, ma tranquilli che prima o poi ritorno con i piedi a terra.

Ma spero proprio per un poi molto lontano.

Se volete localizzare le date a seconda della culture del client, dovrete impostare su Default il campo Language che stà tra le proprietà del report.

Ho perso parecchio tempo nel capire il perchè le date non fossero localizzate nei miei report, e tutto questo perchè questo campo Language è impostato di default (nel mio caso) a "English (United States)".

Ecco i link che mi sono serviti per approfondire i ReportingServices e che ho trovato di utile spunto per preparare la mia sessione, gli elenco qui nel caso a qualcuno servissero.

Per quanto rigurda il controllo ReportViewer, che è il controllo che ho utilizzato durante la sessione per visalizzare i reports all'interno delle pagine ASPX, il maggior sito di riferimento è
http://www.gotreportviewer.com/

Recupero dati da oggetti di business usando un'ObjectDataSource associata ad un local report.
http://www.gotreportviewer.com/objectdatasources/index.html

Recupero dati da file XML.
http://msdn2.microsoft.com/it-it/library/ms159741.aspx

Recupero dati da Web Services, l'uso di un Web Services come fonte dati e chiamata di un metodo specifico usando parametri dinamici.
http://prologika.com/CS/blogs/blog/archive/2005/11/20/695.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/RepServXMLDS.asp
Per quanto rigurda la Custom Data Source, l'unico link interessante che io abbia trovato è
http://www.microsoft.com/italy/msdn/library/net/adonet/RSDSetEx3.htm

Eccomi qui a commentare la sessione che ho tenuto ieri sera al meeting XeDotNet. E'la prima volta che mi trovo a parlare in pubblico ad un meeting e a dover trasmettere parte di quello che ho appreso a riguardo di Reporting Services.
Fino all'ultimo (e in parte ancora ora) avevo la paura che la mia sessione potesse essere pallosa, visto il SOLO codice da presentare. Prima di iniziare il mio intervento, e anche nei primi 5 minuti, non vi nascondo che mi tremavano le gambe, ma poi tutto è filato liscio, mi sono trovato tranquillo a parlare di un argomento che so di conoscere, non vedevo il pubblico (e non per colpa delle luci basse), ero sicuro di me, e fortunatamente tutto è andato liscio.

Mi è piaciuto sentire che ci sono state domande, questo vuol dire che l'argomento ha interessato, e spero con la mia sessione "un pò particolare" di aver trasmesso che reporting services non vuol dire sempre e solo SQL.

Mi piacerebbe sapere come sono apparso, se sono riuscito a trasmettere qualcosa, perchè questo è quello che conta... ma vi assicuro che pian piano indago.

Un grazie a Andrea Boschin e a Davide Senatore per l'ottimo meeting che siam riusciti a metter su.

Impostando Height="100%" nel controllo ReportViewer (in ASP.NET) vi potrà accadere la stessa cosa successa a me, e cioè che quando visualizzate una pagina con il controllo così impostato al suo interno, vi apparirà solamente la barra e non vedrete il vostro report.
Accade che il controllo si setta con un'altezza pari alla sola barra.
Non immagino il perchè di questo anomalo comportamento, ma lo posto qui, così che non perdiate anche voi lo stesso tempo che ho perso anch'io nel capire il perchè i dati non comparivano.

Perciò attenzione nel mettere Height="100%" al controllo ReportViewer.

Lo posto con un giorno di ritardo... Tanti Auguri a me!! Ieri, 1 novembre ho compiuto 24 anni!!

Ed ecco il resoconto...di questi 24 anni non posso lamentarmi proprio di niente, ma anzi, trovo giusto ringraziare tutte le persone che mi hanno fatto diventare quello che sono:
I miei genitori per tutto l'impegno che ci hanno messo (e che stanno mettendo) per avermi dato le basi per essere ciò che sono ora. Un grazie per non aver mai mollato e per essere stati dei genitori stupendi!
La mia ex ragazza Roberta per avermi regalato 3 anni pieni di sentimenti ed emozioni che non potrò (e non vorrò) mai dimenticare. Roberta, un grazie immenso per tutto ciò che mi hai dato.
La mia compagnia, Jack, Cipri, Biz, Loris e Svelto, grazie perchè siete sempre presenti.
E un grazie a tutti quelli che ho incontrato in questi 24 anni che anche con un sorriso mi han regalato sicuramente qualcosa.

Sono cresciuto, sono maturato, ho fatto errori ma ho anche imparatato a non ripeterli.

In un giorno così, ci si guarda indietro, si guarda il passato e si guarda il presente e si immagina come possa essere il futuro,
ma al futuro non voglio pensarci ora, al futuro ci penserò più avanti!

Ed ecco che su XeDotNet esce un mio nuovo tip, ma questa volta a rigurado delle Membership di ASP.NET.

Questo tip descrive come forzare la modifica della password di un MembershipUser da codice senza conoscere la precedente.

Nel progetto a cui stò lavorando mi trovo a sbattere la testa anche in cose che sembrano banali come questo tip, ma che per risolverli ci si impiega molto tempo, ed ecco perchè condivido queste mie piccole "scoperte".

Dopo vari tips scritti per XeDotNet, ecco uscito il mio primo articolo e vi riporto qui una breve descrizione:

L'articolo descrive come poter consumare dinamicamente un Web Services a runtime, dando così maggiore flessibilità alle applicazioni

Lo trovate a questo link http://www.xedotnet.org/40/section.aspx/300

Ho usato "dinamicamente" nel senso che non è necessario ricompilare l'applicazione se si vuole modificare alcuni dati del WebService.
Personalmente non mi è mai piaciuta l'idea di vincolare un'applicazione, o una parte di applciazione a dei web services prestabiliti. Anche perchè nella fase di sviluppo di un'applicazione e magari del relativo servizio, il web service può subire mille variazioni, dal nome dei metodi, al namespace, e quant'altro e non mi andava di ricompilare ogni volta il client e allora ho cercato una possibile soluzione.
Quella pubblicata nell'articolo è la prima fase di questa ricerca, infatti mi appoggio ad un'utility framework Wsdl.exe che si occupa di generare un file *.cs con i metodi e le proprietà per accedere e consumare il servizio.
Quello che stò cercando di fare ora è quello di riuscire ad emulare quello che fa wsdl, e magari sarà fonte per un prossimo articolo.

Oggi è un giorno veramente stupendo, uno di quei giorni in cui rimani proprio senza parole...
Voglio ringraziare Davide Vernole per il regalo inaspettato che mi ha fatto oggi....una licenza di Visual Studio Team Suite con MSDN premium Subscription.
Non vi nascondo la mia felicità nell'averla ricevuta, e chi non lo sarebbe?! Da quando ho cambiato lavoro e mi sono ritrovato a sviluppare (per mia fortuna) al 100% in .NET, posso ammetere di essere cresciuto parecchio e di aver acquisito davvero molte capacità.
Questo regalo mi sprona a voler imparare sempre di più e ad impegnarmi a trasmettere il mio know how, almeno per quelle che sono le mie capacità. Grazie ancora Davide (e continuerò per molto a dirtelo) ...stai certo che spremerò e sfrutterò quest'occasione fino in fondo. ...e anche la mia autostima ne ha avuto guadagno!