agosto 2005 - Posts
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/adotonet.asp
Ho visto questo articolo su MSDN e non ho resistito a citarlo. L'articolo in se presenta un semplice e classico caso da convertire dal VB6 a VB.NET 2005.
Francamente credo che per passare a .NET, partendo da VB6 o ASP3, ci voglia un certo impegno e una buona assistenza. D'altra parte bisogna farlo e più si rimanda, più sarà impegnativo fare il doppio tuffo carpiato, il giorno in cui si deciderà di farlo!
Trovo che per seguire un percorso di migrazione reale e ben fatto non si debba partire cercando di "riprodurre" qualcosa di uguale a quanto si faceva già in VB6, a che servirebbe allora passare a .NET?
Penso sia molto meglio capire il perché di .NET (pensando ai limiti di VB6 e di COM), poi il per come delle sue fondamenta (CLR, JIT, Garbage Collector) e ancora prima provare a comprendere il valore e il significato della OOP.
Affrontati questi veri e propri scogli, almeno per quello che vedo di ciò si tratta per molti sviluppatori VB6 (lo ero anche io, badate bene ... quindi mi ci metto dentro senza fare troppi complimenti), allora si può iniziare a lavorare sul "pezzo" e il pezzo per me è .NET. Punto! Non è VB.NET o C# o J# o altro.
Da oggi è disponibile per gli abbonati ad MSDN il download di WinFS Beta1 e della sua documentazione.
Maggiori dettagli dopo che l'avrò installato e usato un pochino...
http://blogs.msdn.com/harsh/default.aspx
In alcuni problemi e soluzioni segnalate mi ci rivedo abbastanza.... quindi lo segnalo per chi fosse interessato.
Per chi dovesse essere interessato alla struttura del field tp_ACL della tabella Lists di WSS (uno alla volta, non tutti insieme ;-) !!!!) ecco qui qualche dettaglio:
http://weblogs.asp.net/paolopia/archive/2005/08/25/423624.aspx
Su Internet non ho trovato nulla su tp_ACL e molto poco sullo schema del Content DB di WSS in generale.
Mi sono quindi armato di pazienza e birra :-) e in questi 2gg ho spulciato per bene la struttura del Content DB di WSS, per fare (ahime!) delle query dirette, saltando il modello ad oggetti che mi stava "stretto".
Non fatelo! E se lo fate dovete avere davvero una buona ragione per farlo!
In questi ultimi 5 o 6 giorni ho approfittato del fatto che siamo ancora in clima di vacanze per sperimentare/approfondire alcuni servizi di VoIP sia gratuiti che a pagamento. L'ho fatto per passione, per interesse (mi servono per una nuova società che ho costituito e di cui sentirete parlare a breve :-) ...) e perché voglio installare solo servizi Ethernet nella nuova casa dove andrò a vivere il prossimo anno.
Devo dire che sono rimasto positivamente colpito dalla qualità che questa tecnologia già oggi raggiunge. In particolare ho scelto di attivare il servizio Squillo. Non me ne frega nulla di fare pubblicità :-) e non mi pagano per farlo, ma volevo condividere con voi la scelta e confrontarmi, se altri hanno già fatto analisi e valutazioni come quelle che ho fatto io in questi giorni.
La spinta finale ad attivarmi sul serio come utente di servizi VoIP me l'ha data PDC, perché voglio evitare di spendere centinaia di € per telefonare a clienti, morosE :-) e familiari da Los Angeles.
Sino ad oggi avevo sempre utilizzato Skype o MSN Messenger. Li trovo molto comodi e molto validi per la comunicazione PC-to-PC. In particolare mi piace molto Skype!
Per la comunicazione PC-to-Phone e Phone-to-PC però avevo bisogno di qualcosa di più:
- numero di accesso urbano raggiungibile da chiunque (in pratica uno SkypeIn, che però in Italia non c'è ancora!)
- tariffa flat per le chiamate urbane verso tutta italia (anche quando sono all'estero of course)
- possibilità di chiamare sia con il PC che con telefoni VoIP (a tal proposito se volete farvi del male :-) nel senso buono guardate qui che bei giochini che ci sono sul mercato. Mi fanno letteralmente impazzire i telefoni VoIP cordless WiFi !!!
- segreteria telefonica con recapito in email dei messaggi
- eventuale number portability dal fisso al VoIP (se decido di fare il grande salto ... come se non avessi ancora deciso :-) !!!!)
Bello! Veramente bello! Appena se ne accorgeranno in tanti (parlo degli utenti finali, non di noi malati di blog e tecnologia che tutto sommato siamo in un certo senso "operatori del settore") sarà l'inizio della rivoluzione del WiFi !!!!! Non vedo l'ora!
Ma ci pensate?! Girare per la città con un telefono VoIP in WiFi che risponde ad un numero fisso urbano, cambiare città, cambiare nazione e continuare a rispondere allo stesso numero, chiamando sempre con tariffe urbane?!!
Ok ... torno a programmare :-) !
Dopo il mio post di qualche settimana fa, raccolgo e segnalo volentieri anche lo sfogo di Daniele :-) sempre sullo stesso tema e sempre sullo stesso tono anche se lui è stato più passionale di me ... ma si sa... lui è un uomo del Sud :-D e noi Padani siamo meno passionali!
Mi permetto di scherzare perché so che Daniele su queste cose sta allo scherzo :-) ... ma seriamente trovo che le sue considerazioni su Ajax siano in gran parte condivisibili.
Almeno adesso potrò dire che siamo in due ad essere scettici su Ajax.
Annuncio con piacere la disponibilità di un nuovo corso DevLeap: "WCF (Indigo) Preview" .
La soddisfazione è doppia, sia per l'argomento, al quale sono particolarmente legato (dovreste ormai averlo capito :-) !), sia per il fatto che per la prima volta il corso è proposto anche in lingua inglese!
Bridge The Gap!
Ecco un interessante relazione, proveniente dal mondo universitario, che svolge un'analisi sulla sicurezza di .NET confrontata con quella di Java (tratto da http://blogs.msdn.com/shawnfa/archive/2005/08/17/452760.aspx):
http://www.cs.virginia.edu/~nrp3d/papers/computers_and_security-net-java.pdf
Curiosi anche i commenti al post del blog che mi ha reso nota la relazione.
Personalmente ho sempre ritenuto poco efficaci le estionsioni alle applicazioni web, diverse dal codice HTML (o DHTML in casi particolari).
Le applet Java, gli ActiveX Controls, i Windows Forms Controls e qualsiasi altra alchimia passata o futura non vanno bene nei siti web, se non in rarissimi casi.
Impuntarsi sulla sicurezza o non sicurezza del sandboxing all'interno di un browser mi sembra sterile, considerata la % di utilizzo che ne viene fatto rispetto al resto delle applicazioni.
Considero molto più importante la sicurezza del codice eseguito al di fuori di un container come può essere un browser.
Interessante il riassunto nelle conclusioni del documento di analisi:
"Where Java evolved from an initial platform with limited security capabilities, .NET incorporated more security capability into its original design. With age and new features, much of the legacy code of Java still remains for backwards compatibility including the possibility of a
null SecurityManager, and the absolute trust of classes on the bootclasspath. Hence, in several areas .NET has security advantages over Java because of its simpler and cleaner design."
Parafrasando l'estratto: .NET pare essere più sicuro di Java, ma è anche vero che Java esiste da più tempo, mentre .NET ha potuto beneficiare dei bug e dei problemi emersi in Java, per evitarli.
Leggo stamani dal blog di Alessandro Perilli che è stata creata da VmWare una community per sviluppatori, tipo MSDN di Microsoft. Il prezzo sembra interessante 299$, quindi potrebbe valerne la pena, soprattutto per avere le immagini già pronte e installate delle macchine virtuali.
Leggo anche che esiste un tool per convertire le macchine virtuali in reali e viceversa, passando anche da tool intermedi come Ghost. Se funziona :-) è una gran cosa!
Dal blog di Scott Woodgate il rimando alla notizia che saranno disponibili nuovi adapter per BizTalk Server, in realtà acquisiti insieme alla società IWay.
Sono da anni convinto che BizTalk Server sia un prodotto molto valido, seppure abbastanza complesso e quindi non banale da utilizzare.
Il fatto che Microsoft continui ad investire sul prodotto e sulle sue estensioni mi fa ben sperare per un domani in cui le aziende smetteranno di farsi in casa mini-programmini ad hoc e inizieranno ad utilizzare framework come BizTalk. In fin dei conti la versione più "schiscia" di BizTalk costa meno di 900€ (mi riferisco alla versione Partner che consente di creare 3 orchestration con un massimo di 3 partner e costa 999$).
Dall'area MSDN dedicata a
Windows Vista un
articolo su Windows Presentation Foundation.
Da segnalare il fatto che pare che la prossima versione di Terminal Services supporti il trasferimento delle immagini vettoriali, cioè se ho un applicativo Avalon invece di trasferire sul client la bitmap, trasferirò solo le informazioni vettoriali e l'immagine sarà poi costruita direttamente sul client, ovviamente se il cliente sarà dotato del motore di rendering appropriato.
Luka è sicuramente più esperto di me su questi temi, ma nel mio piccolo :-) trovo che questa sia una ragione fondamentale per passare ad Avalon nelle applicazioni del domani (... non troppo lontano per altro!).
Interessante da guardare durante l'estate e a prima vista utile. Mi segno il link:
http://lab.msdn.microsoft.com/teamsystem/workshop/gat/download.aspx
Sto approfittando delle vacanze per leggermi un po' di normativa relativa agli aspetti "tecnologici" della gestione delle aziende, anche da un punto di vista burocratico e legale.
Mi riferisco ai decreti, alle leggi e ai regolamenti di applicazione delle direttive per la posta elettronica certificata (PEC), per la fatturazione digitale, ecc.
Sono argomenti che mi interessano molto e che mi piace, quando ho tempo, tenere sotto controllo.
Mi è venuta in mente questa sera un'associazione di idee, che probabilmente già in molti avranno fatto. I documenti inviati con la PEC hanno valore legale (badate bene che si parla di valore pari a quello di una scrittura privata ... da quel che ho inteso). Per esempio se mando una fattura elettronica PDF via PEC questa ha valore legale e posso utilizzare la data di invio come data dalla quale far decorrere eventuali inmteressi di mora. Ho pensato: e se mando un messaggio SOAP via SMTP tramite PEC?
Devo capire bene se ci sono vincoli alla natura del messaggio inviato tramite PEC, ma se non ve ne sono, in particolare sul content/type, allora mi vengono in mente molte applicazioni furbe di BizTalk Server, per l'invio di fatture tramite servizi SOAP over SMTP con tanto di WS-Security in caso di necessità!
Proseguo nello studio e se arrivo a qualcosa di più concreto e/o maggiormente certo mi farò nuovamente sentire su questo tema. Se nel frattempo qualcuno vuole aiutarmi a capire/approfondire il discorso ... come sempre i commenti sono aperti.
Questa sera ho visto segnalato sul blog di Alberto Falossi un tool per eseguire delle stime di sizing di soluzioni Sharepoint 2003.
Il tool in sé è un'ottima idea e tra l'altro è anche sviluppato in .NET. Bene! L'ho subito scaricato e provato.
Purtroppo ho avuto un'amara sorpresa: dall'idea il produttore del software non ha mai svolto test di utilizzo del suo tool con un utente non-admin, quindi devo dedurre che anche lo sviluppatore che ha realizzato l'applicazione utilizza il suo PC come utente admin, altrimenti se ne sarebbe accorto!
Tentando di utilizzare il software con il mio account personale, che è uno User del mio PC e non un Administrator, ho ottenuto una serie di Exception. Cito per esempio:
System.UnauthorizedAccessException: Access to the path "c:\program files\hewlett-packard\sps 2003 sizing and configuration tool - v2.0\MseAppLauncher.cfg" is denied.
System.UnauthorizedAccessException: Access to the path "C:\Program Files\Hewlett-Packard\SPS 2003 Sizing and Configuration Tool - V2.0\MseAppLauncher.settings" is denied.
System.UnauthorizedAccessException: Access to the path "c:\program files\hewlett-packard\sps 2003 sizing and configuration tool - v2.0\sps2003sct.settings" is denied.
Inoltre ho dovuto risolvere dei problemi di autorizzazione nell'accesso via HTTP al server di update del client, che in un certo senso voleva essere una sorta di "Smart Client".
Poi arrivato in fondo al wizard del sizing tool, questo cerca di salvare un file temporaneo su HD, sempre nella Program Files:
Ovviamente sistemando qua e là i problemi poi il tool ha funzionato. Trovo però grave che ancora oggi, a distanza di 2 anni da quando Microsoft ha iniziato a spendere fior di soldi per formare e informare sulla sicurezza delle applicazioni (io e Marco abbiamo fatto un roadshow di 12 tappe nel 2004. Raffaele ha rifatto un roadshow quest'anno. Solo per citare l'Italia), ci siano ancora sviluppatori che lavorano come Administrator e che non si pongono nemmeno il problema di testare il loro software con utenti diversi da loro, in termini di privilegi. Se poi chi commette questi errori è un programmatore che lavora per una grossa azienda ... mi dispiace ma rimango ancora più deluso.
Dopo lo sfogo .... pensavo che ormai anche i muri :-) avessero imparato che non si devono mai e poi mai utilizzare i folder della Program Files per persistere i file di configurazione locali all'utente particolare, qualora questi debbano essere non solo letti ma anche modificati. La cartella Program Files è di default in sola lettura per gli Users, è modificabile per i Power Users ed è Full Control solo per gli Adminstrators. Con .NET i file di configurazione locali al singolo utente devono essere salvati o nell'Isolated Storage (scelta furba se si vuole creare un vero Smart Client con installazione automatica anche via web ... aspettando ClickOnce) oppure nella Document and Settings. Inoltre non si deve mai chiedere più di quello che serve. Ho il sospetto che alcuni di quei file siano richiesti in lettura/scrittura, ma non debbano realmente essere scritti, al software basterebbe leggerli!
Voto 7 all'idea del programma in quanto tale.
Voto 3 alla qualità del codice della sua implementazione.
Ovviamente ho già segnalato via email al produttore il problema.
Spulciando con .NET Reflector il codice di Indigo mi sono imbatttuto in un attributo .NET 2.0 decisamente interessante:
InternalsVisibleToAttribute
Il suo scopo è, a prima vista, consentire la visibilità dei membri marcati come "internal" anche ad altri assembly da considerare "amici" ed è dichiarato a livello di assembly.
Per esempio per dichiarare che un mio assembly di nome DevLeap.DataLayer ha i membri marcati come internal che devono essere visibili anche all'assembly DevLeap.BizLayer devo dire:
[assembly: InternalsVisibleTo("DevLeap.BizLayer, PublicKeyToken=c03d3f7f11d50a3a")]
per esempio nel file AssemblyInfo.cs del mio progetto DevLeap.DataLayer.
More Posts
Next page »