Investimenti di Microsoft

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).

Porting da C a Managed C++: Quake II .NET

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.

Gestire progetti di qualità stando nei tempi…

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 🙂

TechEd Blogger – dietro le quinte

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à…

Bilancio di TechEd 2003

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.

Amministrazione e Deployment con Reporting Services

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, SAP, Peoplesoft e Siebel

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.

Yukon – programmabilità

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”.

DevLeap e il party per 10 anni di TechEd

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.