Category Archives: MailingDevLeap

Post inclusi in newsletter tecnica DevLeap

Report Builder per tutti!

Ottima notizia oggi: sembra che Report Builder sarà incluso in tutte le versioni di SQL Server 2005 (tranne la Express). Report Builder è un tool che consente agli utenti di disegnarsi i propri report, senza ricorrere a Visual Studio.


Questo significa che Reporting Services si diffonderà ancora di più. Tempi duri per chi fa prodotti in questo mercato, che dovrà giustificare il costo di un prodotto con funzionalità molto sofisticate. A questo punto mi sembra più sensato, per chi è in quel settore, considerare Reporting Services come la piattaforma di riferimento e scrivere dei componenti che vi si integrino.


Credo sia una decisione molto utile alla strategia di MS, che vuole fare di SQL Server (e prodotti collegati) la piattaforma di riferimento per la BI. Utile anche agli utenti, che abbassano i costi. Un po’ meno divertente per chi fa prodotti come Crystal Report – ma parliamo di Business Objects, sapranno difendersi.

VS2005 e SQL2005 escono nel 2005

Sono appena stato confortato dalla notizia che Visual Studio 2005 e SQL Server 2005 usciranno nel 2005. La settimana del 7 novembre 2005 è previsto il lancio dei due prodotti. Al di là delle facili ironie, ormai qualcuno poteva iniziare a dubitare dell’uscita entro l’anno: uscire a novembre è molto al limite (le versioni localizzate probabilmente usciranno nel 2006, credo…) ma in qualche modo sembrano avercela fatta. Ricordo che nel 2004 c’erano molti molti dubbi sull’allineamento tra SQL Server e Visual Studio, per tutti i problemi di interdipendenza che si erano venuti a creare. In qualche modo se n’è venuti fuori, ma al prezzo (anche) di qualche ritardo.


Da oggi è disponibile anche la CTP June di SQL Server 2005, che in pratica è una sorta di Beta 3 finalmente completa di tutte le funzionalità. Da provare.

Macintosh su Intel – scenari futuribili

Non posso fare a meno di fare qualche considerazione a caldo sull’annuncio di Steve Jobs che è appena avvenuto: il 6 giugno 2006 (06/06/06… magie del marketing…) avremo tra noi il primo Macintosh basato su processori Intel. Da 5 anni esiste una versione di Macintosh che gira su Intel. Le applicazioni in codice binario per PowerPC saranno emulate su Intel. Pare che esista un developer kit che alla modica cifra di 999$ fornisce un Mac Pentium 4 a 3.6GHz, da restituire il 6 giugno 2006 (chissà se l’offerta è valida anche per l’Italia).


A questo punto uno direbbe: finalmente qualcuno sta facendo concorrenza a Microsoft sul suo terreno (il software a pagamento). In realtà molti software per Mac sono prodotti da Microsoft e all’annuncio era presente anche Microsoft, lì a spiegare che anche Exchange sarà più facilmente fruibile sui nuovi Mac.


La notizia è molto più ampia di quello che si potrebbe immaginare. Da una parte Apple smette di fare software che gira solo sul proprio hardware. Dall’altra Apple smette di fare hardware con cui gira solo il suo sistema operativo. (sicuramente qualcuno potrà smentirmi su entrambe le affermazioni, ma vediamo la cosa dal lato business e non da quello meramente tecnico). Apple forse aveva già cambiato il suo modello di business con iPod e iTunes. Ora cambia definitivamente e, in un certo senso, rilancia.


Sì, perché in un mondo dove sullo stesso PC possono girare sia Mac che Windows, sia Tiger che Longhorn, la competizione è più forte e la competizione aiuta a migliorare i prodotti. Il passo successivo è l’interoperabilità: se un dual boot è il primo passo, le macchine virtuali sono quello immediatamente successivo.


Apple potrebbe aumentare la sua penetrazione, sia come hardware (io lo comprerei un PC fatto da Apple) sia come software (perché non avere OsX sul proprio PC in dual boot?). Ma Apple potrebbe anche perdere completamente la sua identità. Vedremo. Un anno è lungo, tra un anno avremo un Longhorn quasi-finito, nuovo hardware in arrivo per supportarlo e sicuramente grandi fanfare per il nuovo Mac. A questo punto mi aspetterei un Visual Studio for Macintosh con una versione di .NET dedicata: avrebbe un senso, soprattutto in chiave di differenziazione rispetto a Linux (non mi aspetto una versione .NET per Linux da parte di Microsoft almeno per i prossimi 5 o forse 10 anni).


Ho detto la mia, l’argomento è caldissimo, i commenti sono aperti.

Generazione chiavi surrogate con SSIS

Ho scritto un post su SqlJunkies relativo alla generazione di chiavi surrogate con  SSIS che può essere interessante per chi si occupa di Data Warehouse e vuole capire l’approccio di SSIS, diverso da DTS, in merito a questo tipo di problematiche. L’articolo è in inglese, purtroppo in questo periodo non ho il tempo di tradurlo (già tanto che l’abbia scritto!).

Perché la security non è solo firewall+antivirus

Da sempre (e soprattutto dall’anno scorso) spiego come non sia possibile pensare di essere “al sicuro” solo per il fatto di aver installato un firewall e un antivirus, pur mantenendoli aggiornati.


Il pericolo numero uno per la sicurezza è l’utente, che quando ha diritti amministrativi può installare qualsiasi tipo di software sul proprio computer. Anche a sua insaputa. Il famoso motto “usate il computer senza essere amministratori della macchina” ha radici molto fondate.


Nel tour di MSDN dell’anno scorso dedicato alla security e nel .NET Security Day di quest’anno a Zurigo ho sempre illustrato come sia possibile scrivere del software “su misura” che non viene intercettato da nessun firewall e da nessun antivirus, spiegando anche come, nell’informatica, se qualcosa è possibile qualcuno probabilmente l’ha già fatta. Stamattina ho letto questa notizia su Punto Informatico che, semplicemente, fa venire alla luce il primo caso di questo tipo: sicuramente ce ne sono altri che non vengono pubblicizzati e magari nemmeno scoperti (in questo caso, infatti, la scoperta è avvenuta per caso e in modo anche un po’ indiretto). In breve, un programmatore israeliano metteva la sua capacità di “virus writer” al servizio di agenzie investigative dedite allo spionaggio industriale.


Quello che colpisce è la cifra relativamente esigua (3.000 euro per ogni virus/trojan creato) richiesta dal colpevole. Da un punto di vista meramente economico, queste tariffe “abbattono il livello di ingresso nel mercato” da parte di chi non si fa troppi problemi per acquisire i segreti della concorrenza. Difendersi è assolutamente più caro, più che altro perché richiede un po’ di cultura della sicurezza che non si può semplicemente comprare.


Vedendo la cosa da un punto di vista più generale, la considerazione che mi viene da fare è che la sicurezza in senso assoluto non è perseguibile, quindi è più sensato, arrivati a un certo punto, tracciare informazioni che consentano di risalire al colpevole in caso di “attacchi”, oltre ad avere una qualche forma di intrusion detection system che consenta di analizzare le situazioni sospette. Se poi il sistema investigativo e giudiziario faranno il loro dovere, il rapporto rischio-benefici sarebbe spostato a sufficienza per dormire sonni un po’ più tranquilli. Se ci pensiamo è lo stesso per l’antifurto di una casa: la sirena è ormai del tutto inutile, molto meglio un sistema di allarmi mirati (telefono, sms, ecc.) e una bella ripresa dell’intruso. Privacy permettendo, ovviamente.


PS: Ma la privacy di un ladro è più importante dell’inviolabilità della propria abitazione? Domanda interessante…

BeginInvoke e QueueUserWorkItem

Don Box rettifica alcune affermazioni del suo libro rispetto all’uso di BeginInvoke, EndInvoke e QueueUserWorkItem. La morale è che l’ultima opzione risulta preferibile, in quanto richiede meno risorse e non obbliga a una chiamata finale (EndInvoke) una volta esaurita la chiamata asincrona.


Anche nel mio libro ho commesso un errore simile, nel senso che non ho precisato che la EndInvoke fosse obbligatoria. Comunque il problema viene da lontano, visto che non era chiaro neanche a molti sviluppatori del Framework quanto questa cosa fosse importante.


In .NET 2.0 gli anonymous methods danno una mano a evitare di rimpiangere la comodità di BeginInvoke per il passaggio dei parametri. Adesso bisogna che qualcuno scriva un libro “definitivo” su tutta la materia…

Primo corso su Avalon

Da oggi è disponibile il primo corso su Avalon di DevLeap. Credo sia il primo anche in Italia, ma in realtà è sempre pericoloso dire di essere i primi… comunque i commenti sono aperti e potete segnalare se c’è già qualcosa in giro. Il docente di riferimento è Luca Regnicoli, che scrive poco ma studia molto (con questo non vorrei dire che chi scrive studia poco… spero di non darmi la zappa sui piedi…) e su Avalon ha speso ormai un bel pezzo di vita.


Sinceramente è una scommessa pensare che (in Italia) ci siano molte realtà interessate ad approfondire Avalon oggi. Però comprendere Avalon può essere strategico per chi vuole scrivere oggi con Windows Forms e passare domani ad Avalon senza rifare tutto. Il gestionale su Avalon potrebbe avere molte carte in più da giocare rispetto a quello su Windows: qualcuno (e un po’ anche io) pensa che passando dall’interfaccia carattere a quella Windows si sia perso qualcosa in termini di velocità di inserimento (infatti esistono ancora delle interfacce a carattere che resistono, e non è per obsolescenza); Avalon, sotto certi aspetti, consente di superare questa difficoltà, anche se interpretarlo nel modo corretto per trarne tutti i benefici è tutt’altro che semplice, tanti software dovranno nascere e morire prima di trovare la via giusta.


Spero di non rileggere questo post tra 3 anni e dovermene pentire…

SQL Injection, Reporting Services e sp_executesql

Ultimando la preparazione di un corso personalizzato su Reporting Services ho indagato sulle possibili vulnerabilità ad attacchi di tipo SQL Injection fatti ai danni di un report parametrico. Una volta tanto buone notizie, ma vale la pena di ricordare come si possono scrivere query dinamiche senza rischiare di lasciare delle porte aperte.


Reporting Services consente di scrivere query SQL parametriche. Quando queste vengono inviate a SQL Server attraverso il managed provider di SQL Server, il codice generato è una sp_executesql che contiene la parte parametrica separata da quella costante. In altre parole, se si definisce:

SELECT * FROM Customers WHERE CustomerID = @CustomerID

quello che viene inviato a SQL Server è:

exec sp_executesql ‘SELECT * FROM Customers WHERE CustomerID = @CustomerID’, ‘@CustomerID nvarchar(4000)’, @CustomerID = ‘ABC’

Questo uso di sp_executesql consente di avere il vantaggio e la flessibilità di una query dinamica e di avere la sicurezza di un report parametrico, dove il contenuto di ogni parametro non può modificare la semantica dell’espressione di query. Ovviamente bisogna scrivere un minimo di codice in più rispetto alla semplice concatenazione di stringhe che è il modo “normale” (ma insicuro) di affrontare il problema, però cercando sulla rete si trova facilmente qualche esempio efficace, come questa macro per CodeSmith (editor di testo) da cui si ricava facilmente del codice .NET (l’esempio è in VB.NET ma in C# cambia solo la sintassi, la logica resta identica).


Credo di non averne parlato in passato nel blog e questa era una buona occasione. Che mi dà modo anche di ricordare che ci sarà un Developer Security Tour di MSDN che tra maggio e giugno 2005 toccherà Roma, Torino, Bologna, Bari, Udine e Palermo. Gli speaker sono Fabio Santini e Raffaele Rialdi. Spero che quest’anno ci sia una sensibilità più alta di quella che abbiamo riscontrato lo scorso anno (io e Paolo Pialorsi abbiamo toccato 10 città più una giornata a Milano) dove in alcuni casi la partecipazione fu molto al di sotto delle aspettative. Ma chi legge questo blog è già stato sensibilizzato alla cosa in passato (nessun sviluppa più con un utente amministratore, vero?).


ATTENZIONE: è sempre possibile usare Reporting Services in modo “non standard” e forzare la creazione di query dinamiche che non usano la parametrizzazione delle query: si possono creare espressioni (o funzioni VB.NET) che manipolano la stringa della query direttamente, per esempio per parametrizzare un TOP n di una SELECT o per modificare la clausola di ORDER BY o altro ancora, dove la parametrizzazione di una query non può arrivare. Ma il mio post non era inteso a enfatizzare la sicurezza di Reporting Services (anzi, fate attenzione e seguite bene i consigli di Hitchhiker’s Guide to SQL Server 2000 Reporting Services), quanto a ricordare come si possano creare query dinamiche in maniera più sicura (ma per ciò che non è parametrizzabile non basta e quindi bisogna sempre validare l’input prima di concatenarlo a una stringa SQL…).

SQL Server 2000 SP4

Da ieri pomeriggio è disponibile SQL Server 2000 SP4. L’ho già installato e ho verificato che il bug che avevo segnalato in beta (editor package DTS) è stato risolto. Non ho avuto particolari problemi a installare SP4 su un SP3, su un SP4 beta e su un RTM.


Ricordo che il SP4 è presente anche per Analysis Services (stessa pagina ma download separato) e che quest’ultimo richiede poi l’aggiornamento dei client (PTS, PivotTable Service, trovate il file PTSFULL.EXE nella directory C:\SQL2KSP4\msolap\install\PTS se scompattate il SP nella directory di default).


Ultima buona notizia: anche la versione italiana è già disponibile.

Generics, Collection e prestazioni

Rispondendo a una mail questa sera ho rovistato un po’ di codice delle classi Collection. Probabilmente è una questione di cui avevo anche già letto da qualche parte, ma ribadire il concetto male non fa.


In .NET 1.x la classe ArrayList è molto comoda per fare array dinamici. Per iterare un array è comodo usare foreach, che in realtà genera codice che richiede un Enumerator alla classe Collection; poiché durante l’uso dell’oggetto Enumerator (durante l’iterazione nella lista) il contenuto della lista stessa potrebbe cambiare (aggiunta/cancellazione di elementi), ArrayList mantiene un numero di versione incrementato a ogni aggiunta/cancellazione e tale numero è copiato nella classe Enumerator quando quest’ultima viene creata (cioè quando parte foreach) controllando poi che a ogni iterazione (MoveNext su Enumerator) il numero di versione sia ancora uguale tra Enumerator e ArrayList corrispondente.


Pare (ma non ho misurato personalmente) che questo controllo sia piuttosto pesante rispetto ai tempi della sola iterazione (ma bisogna ricordare che in un ciclo poi farete pur qualcosa, che spesso è molto molto più costoso del costo della sola iterazione) e sarebbe bello poterlo eliminare.


In .NET 2.0 la classe ArrayList non cambia ma abbiamo i generic e la corrispondente classe è la List<T>. Usando tale classe è possibile usare il foreach vecchio stile, che però chiede un Enumerator e procede operativamente nello stesso modo descritto per ArrayList. Se però si usa il metodo List<T>.ForEach( Action<T> ) si evita tale overhead, perché il ciclo for interno a tale metodo si “adatta” a eventuali cambiamenti della dimensione della lista durante l’iterazione.


Che poi questa ottimizzazione sia vitale nella maggior parte dei programmi, ho i miei legittimi dubbi (misurare, misurare, misurare…) ma indubbiamente in qualche caso il miglioramento sarà apprezzabile. Usare i generic non è solo una questione di forma (o vogliamo dire stile?) ma anche di sostanza (prestazioni).