Giocando un pò con i prodotti live, sopratutto con Virtual Earth, ho trovato ques'utile tool:

http://www.codeplex.com/VEJS

Google si sta muovendo per la produzione del suo Sharepoint?
Link

Martin Fowler: "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior"

Chi tra voi non ha mai lavorato su un vecchio codice, di un vecchio progetto?!?!

Beh beati voi... a me, purtroppo, è capitato spesso.

In questo contesto il refactoring si fa strada, per rimuovere duplicati di codice, semplificarne la complessità logica e per chiarire il codice esistente.

Possiamo fare del refactoring su grossi pezzi di codice o solamente sul nome di una variabile, importante è che il tutto migliori la comprensione del codice.

Ricordiamoci che è buona norma effettuare refactoring a piccoli passi anche di grossi pezzi di codice e di farsi aiutare dai test, affinchè possiamo capire subito se stiamo introducendo degli errori.

Le motivazioni tipiche che spingono al refactoring:

• Semplificare la scrittura di nuovo codice
• Migliorare il design del codice esistente
• Migliorare la capacità d'espressione del codice affinchè chi lo legge riesce a capirlo. E' inutile inserire dei commenti nel codice
• Rendere meno noioso lavorare sul progetto

Refactoring to patterns
Refactoring to patterns è il processo che unisce il refactoring del codice ai patterns.

Ciò non significa che ogni qual volta vediamo un pezzo di codice da sistemare dobbiamo per forza applicare un pattern.

Non so quanti di voi l'hanno già fatto, ma vi consiglio di vedere i video su:

ASP.NET Dynamic Data

Proprio l'altro giorno, mentre facevo la demo per LINQ, mi domandavo perchè ancora si usasse Northwind come database per fare le demo.

Oggi ritrovo questo bellissimo post.

Guardando un pò di video in rete ho potuto scoprire una funzionalità di LINQ che non conoscevo per nulla.

LINQ offre la possibilità di creare file XML "al volo" specificando la sorgente dei dati.
Tutto questo è fattibile grazie alle seguenti nuove classi:

I seguenti esempi si basano sul database di esempio AdventureWorksDB.msi installato SQL Express.

Creazione di un file XML da una sorgente dati.

Una volta creato il DataContext tramite il file dbml (chiamato per l'occasione AdventureWorks), ho importato la vista vEmployee:

Fatto questo si procede con il seguente codice:

            AdventureWorksDataContext db = new AdventureWorksDataContext();
                                                                           
            db.Log = Console.Out;                                          
                                                                           
            XElement xel = new XElement("Result",                          
                from c in db.vEmployees                                    
                where c.City == "Seattle"                                  
                where c.FirstName.Length >= 5                              
                select new XElement("Employee",                            
                    new XAttribute("EmployeeID", c.EmployeeID),            
                    new XElement("FirstName", c.FirstName),                
                    new XElement("JobTitle", c.JobTitle)                   
                    ));                                                    
                                                                           
            FileStream fs = File.OpenWrite("Result.xml");                  
            StreamWriter sw = new StreamWriter(fs);                        
            sw.Write(xel.ToString());                                      
            sw.Close();                                                    
            fs.Close();                                                    

Il codice di sopra genererà i file xml Result.xml che conterrà un set di dati:

Per un'esaustiva spiegazione della classe XElement, fate riferimento alle MSDN.

Join fra dati ottenuti da file xml.

Importo nel mio DataContext altre due tabelle presenti nel database AdventureWorks:

• SalesPerson
• Contact
• Employee

LINQ, quando vengono importate delle tabelle, si occuperà della gestione delle relazioni.
Quindi, una volta portate le due tabelle nel vostro file dbml, vedrete graficamente la relazione tra la tabella SalesPerson, la tabella Contact e la tabella Employee:

Le relazione sono basaste, per Employee con il campo EmployeeID con il campo SalesPersonID della tabella SalesPerson.
E la tabella Employee con la tabella Contact tramite il campo ContactID.

Genero tre file xml che conterranno i dati presenti nelle tabelle e che ci serviranno per la dimostrazione:

• SalesPersons.xml

            AdventureWorksDataContext db = new AdventureWorksDataContext();
            XElement xel = new XElement("SalesPersons",                    
                from c in db.SalesPersons                                  
                select new XElement("SalesPerson",                         
                    new XElement("SalesPersonID", c.SalesPersonID),        
                    new XElement("SalesLastYear", c.SalesLastYear)));      
            FileStream fs = File.OpenWrite("SalesPersons.xml");            
            StreamWriter sw = new StreamWriter(fs);                        
            sw.Write(xel.ToString());                                      
            sw.Close();                                                    
            fs.Close();                                                    

• Contacts.xml

            AdventureWorksDataContext db = new AdventureWorksDataContext();
            XElement xel = new XElement("Contacts",                        
                from c in db.Contacts                                      
                select new XElement("Contact",                             
                    new XAttribute("ContactID", c.ContactID),              
                    new XElement("FirstName", c.FirstName),                
                    new XElement("LastName", c.LastName),                  
                    new XElement("EmailAddress", c.EmailAddress)));        
            FileStream fs = File.OpenWrite("Contacts.xml");                
            StreamWriter sw = new StreamWriter(fs);                        
            sw.Write(xel.ToString());                                      
            sw.Close();                                                    
            fs.Close();                                                    

• Employees.xml

            AdventureWorksDataContext db = new AdventureWorksDataContext();
            XElement xel = new XElement("Employees",                       
                from c in db.Employees                                     
                select new XElement("Employee",                            
                    new XAttribute("EmployeeID", c.EmployeeID),            
                    new XElement("LoginID", c.LoginID),                    
                    new XElement("Title", c.Title)));                      
            FileStream fs = File.OpenWrite("Employees.xml");               
            StreamWriter sw = new StreamWriter(fs);                        
            sw.Write(xel.ToString());                                      
            sw.Close();                                                    
            fs.Close();                                                    

Adesso, ipotizziamo che questi tre files non sono stati creati da noi ma sono stati mandati da un nostro cliente tramite dei vecchi applicativi, questo ci chiede di creare un nuovo file xml dove, in base al SalesPersonID del primo file, può ritrovare dati presenti nel file Contacts.xml e Employess.xml, ecco come LINQ ci verrà in aiuto:

            XElement employees = XElement.Load("Employees.xml");                        
            XElement contacts = XElement.Load("Contacts.xml");                          
            XElement salesPersons = XElement.Load("SalesPersons.xml");                  
                                                                                        
            XElement xel = new XElement("NewContacts",                                  
                from s in salesPersons.Elements("SalesPerson")                          
                join e in employees.Elements("Employee")                                
                on (int)s.Element("SalesPersonID") equals (int)e.Attribute("EmployeeID")
                join c in contacts.Elements("Contact")                                  
                on (int)e.Attribute("EmployeeID") equals (int)c.Attribute("ContactID")  
                select new XElement("NewContact",                                       
                    e.Attribute("EmployeeID"),                                          
                    c.Element("FirstName"),                                             
                    c.Element("LastName"),                                              
                    c.Element("EmailAddress"),                                          
                    e.Element("Title"),                                                 
                    s.Element("SalesLastYear")));                                       
            FileStream fs = File.OpenWrite("NewContacs.xml");                           
            StreamWriter sw = new StreamWriter(fs);                                     
            sw.Write(xel.ToString());                                                   
            sw.Close();                                                                 
            fs.Close();                                                                 

in pratica, come prima utiliziamo gli XElement come sorgenti dati e facciamo le join che ci servono per poter ottenere i dati dai vari file xml.

Il risultato ottenuto sarà:

Strabiliante :D

Per qualsiasi dubbio vi consiglio di far riferimento a questo video:

http://www.microsoft.com/emea/msdn/spotlight/sessionh.aspx?videoid=317

Buon divertimento!!!

Quando si dice "il buon giorno si vede dal mattino", ecco questa mattina il buon giorno.

E' stata rilasciata la Beta2 di Silverlight.

Per maggiori approfondimenti:

http://weblogs.asp.net/scottgu/archive/2008/06/06/silverlight-2-beta2-released.aspx

Motivazione al refactoring:
Sviluppare una classe con più costruttori creerà qualche disagio allo sviluppatore che dovrà decidere a quale costruttore affidarsi per istanziarla; questo comportà un certo tempo di studioe dei parametri dei costruttori e/o magari del codice stesso dei costruttori.

Più costruttori abbiamo nella nostra classe più sarà complicato capirne il comportamento.

Per di più, spesso, molti dei costruttori che creeremo non verranno mai utilizzati appunto per via della complessità nel doverne studiare il comportamento.

Soluzione:
Il Creation Method può aiutare a rendere il tutto più semplice.
Il Creation Method è un metodo statico o non statico utilizzato per creare una nuova istanza.

E' bene chiamare il metodo in maniera chiara, in modo che si capisca immediatamente cosa crea (creaConnessioneFtp(), creaConnessioneHttp() ... etc).

Come fare il refactoring:

1. Trovare un punto dove la classe viene istanziata.
   A questo punto bisogna estrarne il codice e creare un metodo publico e statico.
   Questo sarà il nostro creation method.
   
   (compilare e testare)
   
   
2. Trovare tutti i costruttori che istanziano la classe usando il costruttore di prima, cancellare l'istanza ed usare il nuovo creation method.  
   
   (compilare e testare)
   
   
3. Se il costruttore scelto per il refactoring è chiamato da un'altro costruttore, modificare il costruttore inserendo il creation method
   
   (compilare e testare)
   
   
4. Ripetere i punti da 1 a 3
   
5. Se un costruttore non viene utilizzato fuori dalla classe, renderlo non pubblico
   
   (compilare e testare)

Variante:
Se durante la crazione dei creation methods vi ritrovate a lavorare con molti creation method, tipo 25, potrebbe essere noioso.
In tal caso è meglio creare un factory che ritorni l'istanza appropriata.

Eh un periodo che, ovunque mi giro, mi chiedono di tirar giù almeno 120.000 records da macchine web server basate su un PIV...

Ho risolto il problema ma adesso devo leggere bene questo articolo:

ASP.NET: 10 Tips for Writing High-Performance Web Applications

Spero vi torni utile anche a voi.

Stavo facendo il merge di dati. Alcuni presenti in un db ed altri presi da un XML.

Entrambi sono un elenco di Provincie.
Ho bisogno di sapere se quelle presenti nel db sono presenti nell'XML.
Così ho fatto:

                MyDataContext mdc = new MyDataContext();
                var Provincia = from db in mdc.tblProvincies
                                select db.Provincia.Trim().ToUpper();
                XDocument xdoc = XDocument.Load(strFilePath);
                var xProv = from x in xdoc.Descendants("location")
                            where x.Element("Prov") != null
                            select x.Element("Prov").Value.Trim().ToUpper();
                var joined = Provincia.Except(xProv);

Il risultato ottenuto è:

Local sequence cannot be used in LINQ to SQL implementation of query operators except the Contains() operator

Facendo un paio di ricerche sulle msdn ho risolto in questa maniera:

                MyDataContext mdc = new MyDataContext();
                var Provincia = from db in mdc.tblProvincies
                                select db.Provincia.Trim().ToUpper();
                XDocument xdoc = XDocument.Load(strFilePath);
                var xProv = from x in xdoc.Descendants("location")
                            where x.Element("Prov") != null
                            select x.Element("Prov").Value.Trim().ToUpper();

                IEnumerable<string> xObjProv = (from xp in xProv select xp).OfType<string>();
                IEnumerable<string> objProv = (from prv in Provincia select prv).OfType<string>();

                var joined = objProv.Except(xObjProv);

Note e consigli, sempre ben accetti.

Grazie

Appena tornato da Londra...

Cavolo se ci vivrei :D

Passerò per stupido ma debuggando di quà e di là mi è capitato di notare che, una volta instanziata la DataContext, avevo tutti i dati del db in memoria.

Mi domandavo ... come mai?

In più aggiungo... come usereste LINQ per creare un bel test dei dati appena inseriti?

Scusatemi sono un coglione... grazie Davide

Seguendo il consiglio di Davide (cazzo io e quando dimentico il profiler) ho attaccato il profiler.

I dati vengono scaricati quando con l'IntelliSense si prova a visualizzarli -_-

Nuovi video sulla sicurezza postati su asp.net (security) (tnx Scott Mitchell).

Ed altri due video da Lamees Ayman:

• Encryption
• Export and Import Certificates

Un'altro link che potrà tornare in aiuto per le applicazione WCF su Vista:

http://blogs.msdn.com/amitlale/archive/2007/01/29/addressaccessdeniedexception-cause-and-solution.aspx

Se ricevi un errore 404.3 dalla tua neo applicazione wcf leggi il seguente post:

http://blogs.msdn.com/davidwaddleton/archive/2007/11/02/wcf-and-404-3-errors.aspx

Per chi fosse interessato, al seguente link si possono trovare i video delle sezioni del Mix08: http://sessions.visitmix.com/

Sono un appassionato delle metodologie xp, e per questo continuo a studiarle e provare ad applicarle un pò per volta.
Una domanda che è nata in questi giorni è stata: 

• Quali sono le differenze tra SCRUM e XP?

Rileggendo un articolo di Martin Fowler ho trovato la risposta:
http://martinfowler.com/articles/newMethodology.html

Martin dice che le più grandi differenze sono:

• Scrum concentrates on the management aspects of software development
• Scrum dividing development into thirty day iterations (called
  'sprints') and applying closer monitoring and control with daily scrum
  meetings
• Scrum places much less emphasis on engineering practices

Continuo a preferire XP perchè mi piace l'approccio TDD.
Cosa ne pensate?

A questo indirizzo: http://www.visifire.com/silverlight_charts_gallery.php

Potete trovare vari charts con d'esempio, sviluppati in Siliverlight.

Veramente carini.

ASP.NET offre la possibilità di criptare i dati all'interno della ViewState in moda da incrementare la sicurezza.

Per far ciò abbiamo due possibilità:

1 - Tramite il file web.config, abilitiamo il criptaggio della ViewState per tutta l'applicazione:
  <configuration>
      <system.web>
      <pages viewStateEncryptionMode="Always" />

2 -  Solo per una pagina specifica:

<%@ Page Language="C#" Trace="false" ViewStateEncryptionMode="Always" %>

Se la tua applicazione non usa le session puoi migliorarne le prestazioni della tua applicazione disabilitando le sessioni.

Le sessioni si possono disabilitare, per tutta la sezione inserendo la seguente opzione nel file di web.config:

    <system.web>
    <sessionState mode="Off" />

Oppure su una singola pagina:

<%@ Page Language="C#" Trace="false" EnableSessionState="False" %>

Leggendo Refactoring to Patterns sono venuto a conoscenza dell'iniziativa che ha avuto l'autore, ormai anni fa (nel 1995), nel creare dei Gruppi di Studio dove vengono analizzati/discussi/utilizzati i vari patterns, tutto orientato al refactoring e al miglioramento del design di un applicativo.

Non sarebbe un'iniziativa carina a cui pensare?

So solamente che una solution con un'applicativo Silverlight e un servizio WCF, attualmente, non è la cosa più stabile al mondo ... o almeno a quest'ora si ha qualche problema :D

Spero di poter pubblicare la demo il prima possibile.

Per chi potesse interessare, Microsoft ha messo a disposizione: Microsoft Silverlight Streaming

Ragazzi perchè non creiamo un gruppo su linkedin? :o

E' fondamentale ai fini della sicurezza implementare dei tools propri o utilizzare tools di terze parti che possono analizzare l'applicativo prodotto.

E' altrettanto fondamentale utilizzare gli ultimi compilatori/linker/framework rilasciati e non utilizzare metodi bannati.

I compilatori di ultima generazione (C e C++) tendono a scrivere un messaggio di warning nel caso in cui il metodo che stiamo utilizzando non è sicuro (vedi i vari: strcat, sprintf etc)

Ricordiamoci comunque che tutti i tools che utilizzeremo non potranno mai analizzare il codice come un essere umano, sicuramente potranno venirci incontro con la maggior parte di bugs (almeno quelli più grossolani).

E' utile avere una secure coding checklist dove appunteremo i passi da seguire per ottenere almeno un risultato minimo in termini di sicurezza.

Test

Utilissimi per capire lo stato della nostra applicazione sono i test.
E' indubbio che scrivendo codice seguendo la metodologia agile del TDD porta ad avere codice testato almeno in fase di implementazione.

Ma è utile anche implementare dei test del tipo:

• Fuzz
• Penetration
• Run-time

Fuzz

La metodologia del Fuzz Tesing si basa nel creare un dato mal formattato che il nostro applicativo dovrà analizzare.
Solitamente questi dati possono esser di tre tipi:

• File
• Network protocol parsers
• APIs and micellaneous parsers

In tutti e tre i casi la procedura rimane la stessa.
Creare un dato mal formattato (dimensioni, dati sporchi, crc errato, file di grosse dimensioni etc) e darli in pasto all'applicativo a run-time.

Come fare è solamente questione di fantasia.
Possiamo avere una collezione di file errati, o possiamo creare un metodo che manda un pacchetto mal formattato etc.

Se l'applicativo muore durante questa fase di test, abbiamo trovato un bug e molto probabilmente un bug di sicurezza.

Penetration

In un test di tipo Penetration, viene simulato un attacco da parte di un'entità esterna al sistema.
Ovvero ci fingeremo cracker ed andremo ad analizzare il sistema dall'esterno alla ricerca di eventuali falle e, una volta trovate, si inizierà una fase di studio su com'è possibile sfruttarle.

Una volta capito come è possibile sfruttare la falla potremo scegliere la contromisura da usare.

Run-Time

Questa è l'ultima fase di test dove andremo ad usare applicativi come AppVerif per verificare i bugs presenti nella nostra applicazione.

Un tool simile che mette a disposizione Microsoft è Driver Verifier (Verifier.exe).

A questo punto del progetto dovreste aver pronto un prodotto con pochi bugs e un pò di tools che avete creato per testare il vostro software (o che magari avevate già).

Affinchè il vostro cliente utilizzi in maniera corretta l'applicativo, dovremo rilasciare un pò di documentazione affinchè possiamo rendere noti le scelte fatte per rendere il software sicuro.

Setup documentation

E' il tipo di documentazione dove andremo a scrivere informazioni quali:
quale porta e quale protocollo utilizzeremo, perchè le utilizziamo, su che tipo di restrizioni di accesso deve avere la nostra applicazione, che restrizione dovremmo avere nella subnet.

Si continuerà con evidenziare quali sistemi operativi possono supportare il nostro applicativo e perchè.

Ad esempio, se registriamo dei dati sensibili ed utilizziamo un servizio di crittografica dobbiamo renderlo noto all'amministratore.

Mainline Product Use Documentation

Chiamatelo pure User Manual.

Quì annoteremo informazioni come i pericoli che si possono incorrere se abilitiamo una feature che di default è disabilita. Specificando perchè è disabilitata, cosa bisogna fare per abilitarla e cosa fare, comunque, per ridurne i rischi.

Non aver paura di dire chiaramente qual'è il punto debole dell'applicazione

Si consiglia anche di indicare, in un sol punto, l'elenco di tutte le miglior soluzioni per rendere il software più sicuro.

Help Documentation

Solitamente è meglio inserirla all'interno dell'applicazione stessa.
Si pigia <F1> è l'utente può subito venir a conoscenza di informazioni riguardanti il task su cui sta operando.

Developer Documentation

Se rilasciate API o un framework è utile includere informazioni riguardo la sicurezza dei metodi sviluppati e come utilizzarli nella miglior maniera.

Alcune di queste informazioni vengono rilasciare anche dal compilatore nella vostra finestra di build (provate ad usare dei metodi C++ come: sprintf, scanf, etc)

Creating tools

Creare dei tools di sicurezza e' il massimo aiuto che possiamo dare ai nostri clienti.

Pensate quanto Microsoft sta investendo in questo campo.

Conclusione

Ricordiamoci di specificare tutto il più chiaramente possibile e nella maniera più sintetica.
Una lunga documentazione non verrà mai letta anche se ben realizzata.