settembre 2004 - Posts
In SQL Server 2005 (nome in codice Yukon) il DTS (Data Transformation Services) cambia nome e diventa SQL Server Integration Services. L'annuncio è stato dato ieri alla PASS.
Diciamo subito che il nome non mi piace, più che altro per l'acronimo risultante (SSIS) però il cambio di nome è utile a indicare la "rivoluzione" portata da questo componente di SQL Server. Una delle mie sessioni a TechTalk è dedicata proprio a DTS (ci vorrà un po' per chiamarlo SSIS) su SQL Server 2005 e posso confermare che il cambiamento non è soltanto il nome. Dopo metà ottobre cercherò di scrivere qualche articolo sull'argomento.
Ho appena letto un post di Don Kiely che informa dell'interessante politica di marketing che Business Objects sta facendo con Crystal Report (che ha acquisito recentemente): non solo vuol far pagare una licena in funzione del numero di utenti a cui viene inviato un report in formato PDF o Excel (!!), ma vuole farlo retroattivamente (!!!!).
Prima di continuare, premetto che non ho verificato bene come sia la questione delle licenze... però è vero che, come comportamento generale, chi realizza software per la produzione di report (relazionali o multidimensionali, vedi anche i vari ProClarity e Panorama, tanto per citarne un paio) adotta delle politiche di licensing che in genere sono penalizzanti sia per chi ha pochissime (una o due) installazioni, sia per chi ne ha molte (da cento in su). Vero che le varie versioni "developer" consentono in alcuni casi di contenere i costi, ma solo su progetti di una certa dimensione (e solo per alcuni prodotti). A ciò bisogna poi aggiungere il fatto che spesso questi prodotti non eccellono per la qualità (bug, patch non tempestive, documentazione carente, supporto non sempre competente). Rapporto qualità/prezzo decisamente insoddisfacente, insomma.
Piccola malignità: forse che il problema sia un costo troppo elevato dei tanti uffici marketing coinvolti in questa impresa?
Stamattina ho dato un'occhiata alla presentazione del nuovo ProClarity Analytics Platform 6 (con tanto di dominio dedicato, www.sixisnow.com) e devo dire che le animazioni sono carine, la grafica superba e le demo live sembrano promettere bene, ma... è praticamente impossibile:
- trovare delle schede tecniche del prodotto
- avere una demo scaricabile
- conoscere i prezzi
Magari sono io che non sono capace, ma credo siano le informazioni che dovrei trovare prima per un prodotto... Mi dà l'idea che qualcuno voglia vendere software come si vendono le automobili, dove linea, immagine, appeal e moda possono contare di più dei fattori tecnici. Un software lo si dovrebbe comprare prima di tutto per le funzionalità e per il rapporto qualità/prezzo. Una Cinquecento e una Ferrari forniscono le stesse funzionalità di base (andare dal punto A al punto B) con prestazioni, confort ed esclusività diverse; differenza ancora più piccole per due automobili della stessa categoria. Si può dire altrettanto per il software? Credo proprio di no. Dunque, adottare le stesse "tecniche di marketing" per due prodotti così diversi mi lascia veramente perplesso.
Se usate MapPoint e volete georeferenziare dei dati statistici, l'unico modo per farlo in automatico senza correre il rischio di vedere una dialog box all'utente in caso di dubbio è quello di utilizzare il nome esatto usato anche all'interno di MapPoint. Per farlo bisogna però avere l'elenco dei nomi usati da MapPoint, così che dall'esterno i dati possano essere normalizzati rispetto ai nomi attesi da MapPoint (che non sempre sono quelli dei db ufficiali Istat, tanto per capirci). Se vi fermate al nome dei comuni, ecco l'elenco di comuni/province/regioni usati da MapPoint Europe per l'Italia.
Non chiedetemi da dove arriva ma dovrebbe avere corrispondenze al 100%. Io lo sto usando per testare la Fuzzy Lookup dei DTS di SQL Server 2005 (dovrebbe essere una demo anche per la sessione sui DTS che terrò a TechTalk).
Il metodo File.OpenText restituisce uno StreamReader in sola lettura. La documentazione spiega chiaramente che non fa altro che chiamare il costruttore di StreamReader passando il parametro così com'è; tale costruttore, però, pur aprendo il file in sola lettura specifica come modalità di share la sola lettura. In pratica questo significa che il file viene aperto in sola lettura ma nessuno può aprirlo anche in scrittura. Un problema se il file è già aperto da programmi come Excel...
Per aggirare il problema è necessario chiamare il costruttore di FileStream e passare l'oggetto ottenuto al costruttore di StreamReader. Ho pensato di scrivere un post perché può sembrare poco intiuitivo come comportamento di default, anche se è "cautelativo" rispetto ad altri errori che uno potrebbe commettere nella logica di un programma.
Quindi, se volete lasciare accesso condiviso in lettura e scrittura mentre leggete un file, invece di:
StreamReader s = File.OpenText( path );
usare:
FileStream f = new FileStream( path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite );
StreamReader s = new StreamReader( f );
Microsoft ha reso disponibile una documentazione sul Service Pack 2 di Windows XP per un totale di 228 pagine (!) che mi sembra indispensabile per comprendere tutti i cambiamenti apportati da questo aggiornamento. Gli argomenti sono divisi in 8 capitoli e c'è un discreto livello di dettaglio tecnico (voci di registry comprese) senza che per questo si perda in facilità di lettura (l'organizzazione è molto lineare, per ogni elemento c'è scritto perché il cambiamento è importante, a cosa serve, che problemi può creare e come risolverli.
Lettura obbligatoria per programmatori e sistemisti!
In attesa del telefono assoluto (il Motorola MPx... ma chissà quando esce) ci si può consolare con il VOQ, Smartphone a tutti gli effetti ma dotato di tastiera integrata.
Il VOQ costa meno (ma sempre 550€ ci vogliono) ed è disponibile subito (anche in Italia). Il Motorola costerà di più e non si sa quando esce (doveva arrivare a Natale ma ci sono molti dubbi in proposito, ho letto in giro). Peccato che il VOQ arrivi a pesare quasi quanto il Motorola e non abbia il Bluetooth (incredibile ma vero) e il WiFi (ma questo è comprensibile).
Aspetterò ancora MPx prima di cambiare il mio attuale Smartphone, ma è sempre più difficile...
La notizia riportata da TechWorld che ho trovato citata in Bink.nu è interessante: Microsoft sta valutando delle acquisizioni importanti (sopra il miliardo di $) e contestualmente ipotizza una logica di "produzione" più distribuita (uscendo dalla logica per cui il "core business" è a Redmond e gli altri centri di sviluppo nel mondo rivestono ruoli marginali).
L'argomento ripropone il ragionamento che facevo già a Marzo (in occasione del processo antitrust dell'Unione Europea) considerando l'aspetto più politico della centralizzazione a Redmond di tutta la parte produttiva. Anche se il software è un bene immateriale, la delocalizzazione nella produzione è una realtà in tutti i settori industriali e non può non diventarlo anche nelle opere d'ingegno. La cosa non riveste soltanto logiche prettamente economiche (costo del lavoro, dei servizi, tasse, ecc.) ma anche politiche e di immagine, nonché di apertura nei nuovi mercati. La presenza "produttiva" consente di presidiare meglio i mercati regionali. Anche se materialmente non ce ne sarebbe bisogno (con Internet i bit arrivano presto ovunque) sotto tutti gli altri aspetti una multinazionale ha bisogno di ragionare in maniera "distribuita".
A questo punto, però, sono curioso di sapere cosa bolle in pentola... Se volete fare le vostre speculazioni, su questo post ho abilitato i commenti (così vediamo anche se funzionano).
Jeffrey Richter
segnala che Microsoft produrrà una versione "embedded" del CLR: tutto in un chip, come ne esistono anche per Java. Non c'è niente di sensazionale dal punto di vista tecnico, ma è interessante pensare di poter progettare il proprio hardware programmando tutta la parte di controllo in C# con il proprio Visual Studio (debugger remoto compreso). Certo, bisogna poi vedere se quando si tratta di andare real-time (per davvero) non ci sia bisogno di tornare al buon vecchio C o a parti di Assembler, ma questo non giustifica di solito fare il 100% del software in assembler.
Ho provato a installare Firefox, possibile alternativa a Internet Explorer.
Impressioni positive:
- Download piccolo
- Setup facile
- Legge tutte le impostazioni di Internet Explorer
- Toolbar di ricerca integrata (va su Google, Amazon, eBay, Yahoo ma è configurabile, io ho aggiunto wikipedia)
- Tabbed browsing
- Configurabilità: si può personalizzare all'inverosimile
- Download manager integrato
- Image manager (attivazione download bitmap sito per sito, sarebbe utile quando si va via modem ma non si può configurare per distinguere la connessione in uso e quindi la banda disponibile)
- Page Info - informazioni un po' tecniche sul contenuto della pagina, sui link... utile per chi sviluppa o chi vuole indagare su come è fatta una pagina.
Impressioni negative:
- Prestazioni: nonostante sia più piccolo... è più lento; consuma più CPU a parità di pagina, io lo sto provando su un notebook con P4 2.4GHz, probabilmente con un processore più veloce va meglio, ma su uno più "vecchio"? Da verificare...
- Controlli non standard? Il menu probabilmente è rifatto e non usa quello di Windows, anche se visivamente è quasi identico si ha una strana sensazione di risposta lenta. Fastidiosa.
Veramente un buon concorrente di IE. Peccato per le prestazioni. E' una cosa che si fa notare, forse su un destkop ben carrozzato va meglio, non saprei dire. Però se lo ottimizzassero un po'...
NOTA: quando ho scritto questo post ho installato la versione 1.0 Preview Release. Riproverò Firefox quando uscirà la versione finale.
Ieri Andrea Benedetti ha segnalato la disponibilità della documentazione di VS.NET 2005 on-line. Un aspetto interessante è che questa è la prima uscita pubblica di MSDN2, il nuovo motore di MSDN completamente rifatto.
Anche se non ci sono ancora tutti i contenuti di MSDN (sul nuovo motore) il sito promette bene: le pagine arrivano prima, la ricerca è veloce e, soprattutto sembra più accurata. Non parliamo ancora di Google, ma il salto in avanti è notevole.
Nella vita di un programmatore bisogna avere poche certezze.
Ho un DTS particolarmente lento. In realtà deve trasferire una gran mole di dati, ma il tempo complessivo di elaborazione risulta piuttosto lungo. Bene, mi sono detto, anche se DTS è veloce si può fare di meglio, magari scrivendo un programma ad-hoc. Inoltre il DTS richiede una manutenzione piuttosto corposa anche se deve solo trasferire delle tabelle senza fare troppe trasformazioni (anche se qualche trasformazione VBScript in mezzo la si trova), quindi un programma molto specializzato per questo tipo di attività poteva avere senso.
Dopo aver analizzato tutte le possibilità di accedere alla fonte dati (ODBC e driver nativi) e alla destinazione (interfaccia BCP e SqlProvider) mi sono messo al lavoro. Il risultato prestazionale è stato un miglioramento veramente marginale rispetto a quanto già faceva DTS, ma la manutenzione è ora più semplice e quindi almeno un risultato è stato raggiunto. Però ci sono molte lezioni da trarre.
- DTS è veloce; non sottovalutare mai le prestazioni di DTS, anche se bisogna conoscerlo a fondo per trarne il massimo
- .NET è veloce, fino a che tratta dati managed
- Quando arrivano delle stringhe ANSI (8bit) come nel caso di un driver ODBC o nativo, in .NET qualsiasi cosa facciate prima di tutto la stringa passa in UNICODE (come stringa managed)... per poi magari tornare a essere ANSI se la sua destinazione è un VARCHAR. Tutto ciò ha un prezzo, ed è un prezzo molto molto alto se l'applicazione fa solo copia di stringhe o quasi
- Il problema del marshaling è, da un punto di vista prestazionale, molto pesante. Un aspetto non secondario probabilmente lo gioca anche il fatto di essere multithread, con allocazioni prevalentemente dinamiche. Con un profiler si scoprono cose bizzarre, come per esempio il costo esorbitante di lstrlen usata per verificare la lunghezza di una stringa ANSI prima di convertirla in stringa managed.
- DTS di SQL 2005 è tutto managed... saprà fare di meglio? DTS di SQL 2000 va molto veloce perché riduce le conversioni al minimo. Potenzialmente in .NET il problema del marshaling è sempre alle porte.
- In .NET per le prestazioni a volte bisogna commettere dei piccoli delitti: leggere dei campi privati, chiamare direttamente funzioni ODBC bypassando la classe managed, fare un po' di "spaghetti-code" per evitare il boxing, tanto elegante quanto costoso.
Ok, non sto suggerendo di abbandonare .NET, sto solo testimoniando che in casi neanche troppo estremi è necessario scendere a qualche compromesso di troppo. In un mondo 100% managed tutto questo sparirà, ma ci vorrà ancora qualche anno.
Segnalato nientemeno che da Chris Anderson, il blog MiniMicrosoft è un blog scritto da un dipendente di Microsoft che vuole cambiare la compagnia dall'interno. In sintesi i suoi obiettivi principali sono:
- ridurre i dipendenti in Microsoft
- fermare le assunzioni
- meno ricerca, più prodotti
- Win32 e C++, meno CLR
- tornare alla carica su Internet Explorer
Per quanto si possa essere più o meno d'accordo con queste idee, è sempre interessante leggere qualche voce fuori dal coro, anche per capire meglio altri fenomeni. Non è un blog con molto traffico, provo ad aggiungerlo agli altri 100...
In questi giorni sono troppo impegnato per riuscire a scrivere sul blog cose interessanti... ma una piccola segnalazione ci può stare: ci sono i primi prezzi negli USA per il Motorola MPx220 (grazie a Cristian Civera per il link): un listino di 1.800 US$ mi pare veramente un po' troppo, anche se con un po' di sconto si arriva a 1.500$ (che in Euro potrebbe 1.200/1.300€, ma aggiungendo l'IVA sempre lì arriviamo). Se questo è il prezzo di un MPx220, quanto potrà costare l'MPx Pocket PC?
Sono veramente un po' perplesso, va bene spennare i tecno-entusiasti, ma a questi livelli forse si esagera un po'...
Definitivamente archiviato il capitolo ferie 2004 (quest'anno spezzettate in più periodi), smaltendo un po' di mail sono incappato in un bug di NEO (Nelson Email Organizer) che però mi ha fatto scoprire una funzionalità eccellente e finora sconosciuta: il sistema di bug report.
Certo, Microsoft ha fatto dei grandi passi avanti, ma la distanza è notevole rispetto a questa dialog box, comparsa dopo la segnalazione di un errore da parte di NEO.
Il piacere ancora più grande per aver visto che il problema è già stato risolto (ma non potevano dirmelo subito invece che farmi compilare il form? ma a pensarci mi viene in mente che così verificano quanto sia grave il problema per l'utente...)
La tecnologia usata da Microsoft per fare la stessa cosa è simile, ma già solo per il fatto di aprire Internet Explorer e andare su un po' di pagine Web (anche solo per dire che il problema è già stato risolto) è molto meno user-friendly. Un esempio da imparare: un'applicazione .NET potrebbe catturare tutte le eccezioni altrimenti non gestite per realizzare una diagnostica simile per l'utente...