luglio 2003 - Posts
Microsoft
assumerà 5000 persone nei prossimi 12 mesi, aumentando la sua forza lavoro del 10%. Investirà 6.9 miliardi di dollari (che al cambio attuale fa circa 6 miliardi di euro... 12.000 miliardi di vecchie lire... una manovrina finanziaria, per capirci).
Casomai a qualcuno fosse sfuggito, Microsoft ha circa 50 miliardi di dollari di cassa (o investimenti a breve), che divisi per 50.000 dipendenti fa circa un milione di dollari per dipendente. Chiaramente è difficile capire le dimensioni di questi numeri... ma provate a prendere la società per cui lavorate o una società che conoscete... moltiplicate il numero di dipendenti per un numero equivalente di milioni di euro... immaginate di avere una capacità di investimento di tali proporzioni...
Credo di non conoscere nessun'altra azienda con simili capacità di investimento (in rapporto alle sue dimensioni).
Vertigo ha fatto il porting di
Quake II su .NET: a parte l'aspetto ludico, è interessante leggere il documento che riassume gli interventi che sono stati necessari al codice per far funzionare il tutto.
Lezioni da trarre: il costo in termini di performance dei continui passaggi da codice managed a codice unmanaged è minimo, e il codice managed non è così male; se il software è scritto bene (in questo caso è sufficientemente modulare) modificarlo, estenderlo e portarlo su un nuovo compilatore non è un'impresa ma diventa quasi routine.
Mi capita spesso di sentire usare il termine "Metaframe" al posto di "Terminal Server", come se quest'ultimo non esistesse. Questo
documento ne riassume le differenze (attenzione, è un documento di Citrix). Interessante la possibilità di limitare l'utilizzo della CPU di Metaframe XP, sarei curioso di provarlo.
Come passare qualche giorno di vacanza? Ovviamente leggendo qualche libro!
Quello che sto leggendo adesso è un testo sulla gestione di un progetto software, "Under pressure and on time", scritto da Ed Sullivan, project manager per NuMega per anni. Chi, come me, ha usato con grande soddisfazione prodotti come Bounds Checker, non può che rimanere piacevolmente sorpreso dal sapere cosa c'è dietro prodotti simili.
Al di là di questi aspetti nostalgici, il libro è sicuramente di grande valore, ed è applicabile anche in realtà medio-piccole come quelle che tipicamente si trovano in Italia.
Creatività, eccellenza, estro, qualità, ma anche disciplina, comunicazione, partecipazione, poca burocrazia che però quando c'è serve e va rispettata, controllo e reazione immediata ai problemi che si incontrano per strada. Ma molti altri dettagli, come la priorità e l'ordine con cui pianificare lo sviluppo delle funzionalità di un prodotto. Questi alcuni dei "segreti" che si nascondono dietro un prodotto di qualità realizzato nei tempi previsti.
Presumo che praticamente nessuno in Italia scriva software seguendo una metodologia efficace quanto quella descritta in questo libro. Sono anzi quasi certo che non lo sia nessuno dei software "gestionali/di contabilità" che ho avuto il (dis)piacere di conoscere finora (tutti di costo inferiore a 5.000 euro).
varrebbe la pena tradurlo per fare proselitismo :-)
Nei giorni del TechEd ho segnalato il sito
TechEdBloggers.net, pensando fosse un'iniziativa di Microsoft... ma oggi ho scoperto che non è così! Il sito nasce dall'iniziativa di
Drew Robbins e altre
due persone. Microsoft non ha fatto altro che dare un minimo di risalto alla notizia.
E' interessante analizzare l'architettura della soluzione (
prima e
seconda parte): il mondo SOA (Service Oriented Architecture, che ora va tanto di moda) non è solo Web Service.
Ora ho capito perché i blog apparivano con un certo ritardo... per colpa del fuso orario!! Siccome la pubblicazione avveniva con un sistema di autorizzazione manuale, e siccome la persona che gestisce il sito vive negli Stati Uniti e ha sposato una ragazza giapponese (sorry, mi ero perso nel suo sito cercando di trovare informazioni su TechEd Bloggers e mi sono ritrovato nelle foto di sua moglie...), il tutto era legato al suo tempo libero e alla sua buona volontà...
Il TechEd europeo del 2003 è finito e si può fare qualche bilancio. Io ho deciso di seguire sessioni sulle ultime tecnologie, quindi prevalentemente Yukon, Reporting Services, Office 2003 e SharePoint. Sentendo i feedback di altri partecipanti sono contento della scelta, perché nelle sessioni su .NET non c'era molto di nuovo da dire e probabilmente mi sarei annoiato.
I prodotti all'orizzonte cominciano a presentare i vantaggi dell'integrazione con .NET: i primi due sono SharePoint e Reporting Services, visto che Office è ancora scritto in modo "tradizionale" e dovremo aspettare ancora prima di vederlo "pienamente integrato" in .NET, anche se per quello che c'è da fare con Office l'uso di Interop per ora è sufficiente.
I prodotti che mi hanno impressionato di più sono SharePoint e Reporting Services: il primo, abbinato a Office 2003, può veramente cambiare la vita in un'azienda dove gli "information worker" devono lavorare in team. Noi di DevLeap inizieremo ad usarlo proprio per la nostra situazione che è "distribuita" sul territorio, anche se siamo pochi... Reporting Services è qualcosa che manifesterà tutto il suo potenziale con Yukon, ma iniziare a usarlo adesso (quando arriverà, a settembre la prima beta pubblica) può già dare dei risultati tangibili, e nel frattempo ci si prepara alla "rivoluzione" di Yukon...
Bene, domani giornata da turista e domenica ritorno in Italia. Appena avrò altri elementi, scriverò qualche articolo più completo su queste tecnologie, sempre dal punto di vista dello sviluppo.
L'ultima sessione del TechEd è relativa alle funzioni di gestione di Reporting Services: l'amministrazione al momento è interamente basata su un'applicazione Web, mentre con Yukon ci sarà anche un'applicazione Win32. E' ormai chiaro che la versione che sarà in beta pubblica a breve di Reporting Services è un sottoinsieme delle funzionalità che ci saranno in Yukon... però è già qualcosa di molto appetibile e copre una zona (generazione di report, anche via web) che fino ad oggi non era in alcun modo coperta con prodotti Microsoft.
La possibilità di centralizzare l'amministrazione degli utenti, di scegliere cosa possono vedere e cosa possono fare, di definire (con un sistema basato sui ruoli) politiche di security molto personalizzate consente di realizzare, in parole semplici, una sorta di Intranet che offre servizi di reporting anche piuttosto sofisticati. In questo senso è un po' difficile vedere Reporting Services come un motore locale per applicazioni stand-alone, un po' come si è abituati a pensare nei confronti di Crystal Report. In fin dei conti, però, se c'è un SQL Server da qualche parte... se ci sono pochi utenti, quella macchina può ospitare Reporting Services (non ho sentito nessuno dire che ci sono problemi con MSDE, quindi...). Bisogna capire se senza SQL Server Agent funziona lo stesso (alcune funzionalità di schedulazione dipendono da questo servizio), però architetturalmente non vedo grossi problemi in questo senso. A questo punto dovremo aspettare di leggere la licenza d'uso....
SharePoint Portal Server ha la tecnologia e i componenti necessari a realizzare dei portali aziendali (tipicamente per una intranet) che si integrano con software di ERP come SAP, Siebel e PeopleSoft.
Entro fine luglio (o al massimo agosto) su MSDN Dev Center sarà pubblicato un esempio basato su SAP, chiamato SAP PayStub: per chi usa questo sistema (e in Italia sono in molti) è un ottimo punto di partenza per capire come realizzare delle soluzioni personalizzat e in tempi ridotti ma con tutta la flessibilità di SharePoint (grazie alle Web Part).
Proprio una WebPart usata nelle demo è molto interessante: si tratta di WebCapture, che consente di specificare un URL e da qui scegliere una parte della pagina che deve essere presentata nella Web Part. Per realizzare portali personalizzati che riassumono in una pagina dati provenienti dalle fonti più disparate, anche pagine web non progettate per fornire dati in modo strutturato, è veramente l'anello mancante. Tra l'altro, il sito dei
blogger di TechEd sembrerebbe fatto con questa tecnologia (per lo meno, è stata fatta una demo su questo, poi non so se è quello in produzione...).
Bene, dopo una settimana sono riuscito a capire come descrivere SharePoint in poche parole, senza usare troppa terminologia marketing-Microsoft: la soluzione per fare intranet aziendali e di community, senza limiti (praticamente con ASP.NET si può fare tutto quello che eventualmente manca, dalle Web Part a intere pagine) e con una serie di servizi e di componenti già pronti per l'uso.
Lo stato attuale di Yukon è Release Candidate per la Beta 1 (che sarà limitata e non pubblica). La RTM è prevista per la seconda metà del 2004.
Si parla di una stretta integrazione tra Whidbey (prossima versione di Visual Studio .NET) e SQL Server - mi è parso di intuire che la cosa riguardi anche un sistea di VCS (Version Control System) basato su SQL Server.
T-SQL esiste ancora, è potenziato e potrà essere usato a fianco di qualsiasi linguaggio .NET; il codice .NET dovrà essere verificabile. La cosa interessante sarà la possibilità di scrivere stored procedure, funzioni e aggregazioni in .NET: in altre parole, si può costruire in C# (o in VB.NET, o in un linguaggio .NET) una funzione di aggregazione da usare in una query SQL.
Restando sull'integrazione con .NET, è possibile estendere il type system di SQL Server con dei tipi definiti in .NET: questi avranno comunque pari dignità rispetto ai tipi nativi di SQL Server (per esempio, saranno indicizzabili).
Lo speaker ha fatto tutte le demo con Notepad, per non far vedere la stretta integrazione con Whidbey. Grossa enfasi sula security, che in sostanza è basata su CAS (Code Access Security) di .NET.
Vediamo come si importa un assebly:
CREATE assembly sqlmaths
FROM '\\mypc\c%\yukon\demos\sqlmaths.dll'
a questo punto l'assembly
sqlmaths.dll è copiato nel database corrente, in modo che sia disponibile anche facendo un backup/restore del database e non dipenda dalla configurazione esterna al database.
L'assembly precedente potrebbe contenere questo codice VB.NET:
Imports System
Public Class CSQLMaths
Public Shared Sub Add( ByVal In1 As Integer, ByVal In2 As Integer, ByRef answer As Integer )
answer = In1 + In2
End Sub
End Class
La classe precedente è referenziabile da SQL Server come se fosse una stored procedure in questo modo:
CREATE PROCEDURE uspmaths( @In1 int, @In2 int, @Answer int output) AS
EXERNAL name [sqlmaths]:[CSQLMaths]::[Add]
Analogamente, è possibile scrivere una funzione in una classe .NET e richiamarlo all'interno di una SELECT in SQL. Interessante anche la dichiarazione di un trigger, che sfrutta gli attributi.
[SqlTrigger( "CardEncrypter", "custoer_info", "FOR INSERT")]
public static void CardEncrypter() {
SqlConnection connection = SqlContext.GetConnection();
SqlCommand command_1 = SqlContext.GetCommand();
command_1.CommandText = "SELECT * FROM INSERTED";
SqlResultSet r = command_1.ExecuteResultSet(0);
SqlString updatecmd = new SqlString("");;
SqlCommand command = SqlContext.GetCommand();
while (r.Read()) {
command.CommandText = "UPDATE ..."; // update logic
command.ExecuteNonQuery();
}
r.Close();
}
Il supporto per HTTP/SOAP e Web Services non dipende da IIS (non è abilitato per default, ma se lo si abilita non richiede IIS).
Il supporto a XML è "bidirezionale": si possono definire XML View su dati relazionali, ma si possono fare anche interrogazioni SQL su dati XML (!!). L'idea è di creare la massima interoperabilità tra Yukon e XML: questo significa un ampio supporto a XML, XPath, XQuery, DML, XML Views, Web Service (HTTP/SOAP, WSDL). La colonna di una tabella può essere di tipo XML: apparentemente è quasi come un campo di testo, ma le colonne XML possono essere sottoposte a interrogazioni XQuery all'interno di una query SQL!
SELECT [LastName],
[FirstName],
RiderInfo::query['/root/events'] as [Events],
RiderInfo::query['/root/url'] as [URL],
RiderInfo::query['/root/contactInfo'] as [ContactInfo]
FROM Riders
Si può anche fare l'incontrario, cioé vedere le colonne SQL come elementi da mettere in un risultato XML (non ho fatto in tempo a trascrivere il codice). In altre parole, del contenuto XML può essere messo all'interno di un campo, ma non è più solo testo, è un'entità che può interagire (interoperare) col resto del motore relazione di SQL Server. L'ovvia domanda a questo punto è: a che costo in termini di prestazioni? Ma su questo è acora presto fare supposizioni...
Un'altra innovazione è quella relativa all'aggiornamento della cache: in un'applicazione ASP.NET la cache è disconnessa, ma Yukon può generare degli eventi per notificare il cambiamento dei dati all'applicazione che detiene una cache, grazie ad appositi eventi di notifica (si può fare anche oggi, ma bisogna aspettarsi un'integrazione migliore (con ADO.NET v2), che richiederà meno sforzi dal punto di vista della programmazione).
Tra i tanti dettagli, la conferma che Object Spaces (persistenza degli oggetti) sarà integrato in Yukon e Service Broker (visto solo in slide, nessuna demo), che è una sorta di strato sopra Message Queue (anche se non si capisce se si basa su Message Queue, ma dovrebbe...) per realizzare applicazioni "loosely-coupled".
La mattina è iniziata con un Don Box in grande spolvero, che in un'ora e venti minuti ha definito i concetti e l'importanza di un'architettura basata sui servizi.
Difficile riassumere quello che lo stesso Don sintetizza in poche parole: less is more. Meno complessità, meno astrazione, questa è la strada per realizzare servizi solidi che durano nel tempo.
Sul lato tecnico, molto interessante è stato il confronto tra delegate e interfacce: un'interfaccia con un metodo è funzionalmente equivalente a un delegate (è un contratto per un solo metodo), ma l'interfaccia aggiunge un livello di astrazione completamente inutile e che crea più legami difficili da mantenere se il publisher e il consumer cambiano nel tempo.
Ultima nota, la slide su WSE, che riporto integralmente in foto :-)
Finalmente siamo riusciti a riunirci per una foto ufficiale. Da sinistra a destra: Roberto, Marco, Paolo, Silvano e Luca.
Ieri sera il party per festeggiare i dieci anni: diciamoci la verità, non è stata una festa all'altezza delle aspettative per un decennale...
Un dettaglio delle coriste.
Altra sessione di InfoPath, con scenari d'utilizzo e deployment. In effetti ci sono diversi contesti in cui è utilizzabile in tempi brevi. Lo speaker ne individua tre (team collaboration, IT department, IT applications), secondo me il punto intermedio tra team collaboration (uso di sharepoint e utenti medio-avanzati, almeno per il disegno) e IT department (autoatizzazione di piccole procedure realizzate da una struttura di IT, come rimborsi spese, bug report, piccoli form di consultazione su un DB) sono effettivamente percorribili e presentano un rapporto costo-benefici veramente ottimale.
Ma la cosa che mi ha colpito di più è la funzione di aggregazione: si prendono N documenti XML, si chiede di fare l'aggregazione... e voilà, i dati sono aggregati in maniera coerente allo schema di appartenenza. E' una cosa da provare: immaginate di avere tre documenti contenenti le risposte a un form di rimborsi spese, vendite effettuate e commenti... il documento aggregato contiene una tabella di rimborsi spese, una di vendite effettuate e i commenti elencati sequenzialmente... in un formato stampabile e coi totali giusti per le tabelle interne... Non so se mi sono spiegato, ma vedere sfruttare così bene XML fa veramente impressione!
Il supporto di XML da parte di Excel è migliorato ulteriormente. La cosa più significativa è la generazione dinamica di uno schema partendo da un file XML senza XSD collegato: magari non è perfetto ma è molto efficace.
Comincio a vedere Excel sotto una luce nuova: ci si può fare (per i file XML) quello che si faceva con Access per manipolare tabelle di dati correlate tra loro (magari importate da file CSV).
Impressionante la demo di accesso al Web Service di Amazon, però vorrei vedere quanto codice c'è sotto... Domani c'è una sessione più avanzata, se non ho conflitti con altre sessioni andrò a vederla.
Due foto di ieri sera al party degli italiani al TechEd. L'ingresso...
Questa era l'orchestrina tutta per noi.
La sessione sul miglior supporto ISO C++ di VS.NET 2003 è l'occasione per ripetere alcuni link citati durante la sessione.
Librerie basaste su template:
www.boost.org, che è una libreria assolutamente da vedere (se non la si vuole usare) anche perché è supportata da membri del comitato di standardizzazione di C++. La licenza è open source, per qualche azienda potrebbe essere un problema usarla all'interno di propri prodotti. Altra libreria significativa è
Loki, con molti design pattern già pronti.
Libro da leggere:
Modern C++ Design di Andrei Alexandrescu.
More Posts
Next page »