Finalmente ho trovato il tempo di installare il nuovo fiammante Visual Studio 2005 sul mio portatile e dopo aver disinstallato un bel po' di spazzatura per fargli spazio (peraltro alla fine ho eliminato anche GoogleDesktop che aveva creato ben 700MB di indici ) ho potuto provare l'ebbrezza "dell'amore non protetto" da una virtual-machine-preservativo. Ora, non vi so dire se la mia è una illusione dovuta all'aver sopportato per lunghi mesi la lentezza allucinante della virtualizzazione, ma la prima impressione che ho avuto è che sia velocissimo!!! Molto più anche del vecchio vs.net 2003 alla cui lentezza ero oramai abituato.

Manco a dirlo, la prima prova reale è stata la ricompilazione totale di IMHO "pellestrina", che a parte un problemino dovuto al caching application block (che tra l'altro avevo già deciso di rimuovere) è divenuto funzionante al 100% in pochi minuti. Ora mi rimane il problema delle librerie esterne che avevo deciso di usare, iBatis, log4net e i componenti della SyncFusion. Tutte queste infatti girano con la 1.1 e quindi rendono il software ibrido, e mi sto chiedendo a che problemi possa portare questo. Sono in attesa delle Syncfusion in versione 2.0-compatibile e mi solletica l'idea di scaricare i sorgenti di iBatis e log4net e provare a ricompilare anche quelli con VS.2005.

In effetti suppongo che per un po' di tempo questa problematica affliggerà un po' tutti e penso sarebbe molto interessante leggere quelche articolo sull'argomento. Mi metto in caccia e non appena troverò qualcosa non mancherò di informarvi.

powered by IMHO 1.3


Nel numero di ottobre di Computer Programming sarà pubblicato il primo articolo di una serie dedicata a ASP.NET 2.0. L'argomento della prima puntata saranno le Membership API con un esempio di creazione di Custom Membership Provider e Role Provider. Nei mesi prossimi la serie continuerà toccando altri argomenti di ASP.NET 2.0 come le MasterPages, i Temi, e i nuovi WebControls. Curiosamente in questi giorni è uscito un analogo articolo di Andrea Saltarello, ma per chi non mastica bene l'inglese, oppure, come me, non ama scervellarsi a tentare di comprendere un testo in tale lingua, il mio articolo sarà sicuramente gradito.

Buona lettura!

powered by IMHO 1.3


Da un blog su msdn ho notato che è stata rilasciata la CTP2 di un application block che pare davvero interessante. Si tratta di una serie di classi che dovrebbe aiutare a sviluppare interfacce a componenti, consentendo lo sviluppo e il test separato delle varie componenti per poi arrivare ad un assemblamento finale. Ho solo visto qualche spezzone di codice, ma quello che ho visto mi ha parecchio incuriosito. Chissà se sono riusciti a superare la fastidiosa complessità dell UIP.

Link: Composite UI Application Block Home

powered by IMHO 1.3


Chi ha mai provato a sviluppare una applicazione Localizzata quando addirittura non Globalizzata , si sarà reso conto di quanto sia noioso mano a mano che si sviluppa porre nei file di risorse le stringhe che poi dovranno essere tradotte nelle varie lingue. Mi riferisco soprattutto alle stringhe perchè in realtà sono quelle che riguardano almeno l'80% della fatica necessaria. Personalmente trovo questa attività molto deconcentrante. Tipicamente mentre sto scrivendo una porzione di codice, dover copiare una stringa nel file di risorse per poi referenziarla mi fa perdere il filo di quello che stavo realizzando, mentre lasciare le stringhe ad un passaggio successivo fa sì che me dimentichi sempre qualcuna. Per questo ho elaborato un metodo che sto usando proficuamente con IMHO 2.0, e che riesce a salvare le proverbiali capra e cavoli. Il mio metodo si basa sulla seguente classe:

using System.Reflection;
using System.Resources;

namespace Elite.Imho2.Resources
{
    
public sealed class Strings
    {
        
private static readonly ResourceManager mResourceManager =
            
new ResourceManager(
                "Elite.Imho2.Resources.Strings", 
                Assembly.GetExecutingAssembly());

        
private Strings()
        {}

        
public static string Get(string name)
        {
            
string resValue =
                mResourceManager.GetString(name) as string;

            if (resValue != null)

                
return resValue;
            
            
return name;
        }
    }
}
 
La classina, un po' banale se vogliamo è un singleton che permette di accedere ad un ResourceManager creato al primo accesso. La particolarità della classe è che il metodo Get() qualora non trovi una risorsa corrispondente a "name" ritornerà "name " stesso come stringa invece che sollevare un'eccezione. In queso modo, con un po' di astuzia si potranno scrivere delle righe che usano questa classe come in questo eempio:
 
 
MessageBox.Show(Strings.Get("IMHO 2.0"), Strings.Get("Please enter the title"));
 
 
In questo modo l'applicazione sarà popolata con delle stringhe reali anche durante lo sviluppo e in fase di localizzazione sarà molto semplice tradurre le stringhe senza dover rincorrere astruse sigle in giro per il codice.

powered by IMHO 1.3


Questo pomeriggio, in un minuto di tempo libero, ho avuto l'idea di andare a curiosare in quelli che sono i numeri dell'applicazione gestionale che io e i miei collaboratori stiamo sviluppando. Ho cominciato curiosando con qualche query nel database oracle, e poi preso dalla curiosità ho fatto qualche conteggio anche sul codice realizzato in C#. Ecco i numeri per i curiosi:

DATABASE:

  • 304 tabelle
  • 1040 procedure
  • 39 trigger
  • 131 sequenze
  • 4 tablespace

SORGENTE:

  • 71 assembly
  • ~1055 classi (a titolo di paragone vale la pena considerare che il framework .net ne contiene 2882).
  • 1760 file
  • 18,9 MB di file sorgente

Se non lo vedevo con i miei occhi non ci avrei creduto.

[now playing: My Friend (05.02) Goodbye Country - Groove Armada]

powered by IMHO 1.3


Gli utenti di IMHO, già conoscono e forse apprezzano la caratteristica tray icon con cui il software rivela la sua presenza. Nella versione 2.0 di IMHO, questa icona sarà ancora presente, ma la sua funzione è stata notevolmente potenziata. Essa, oltre che un rapido punto di accesso al programma, ora rivela anche informazioni sullo stato del server cui si è collegati, e fornisce messaggi come quello visibile nello screenshot riportato a fianco, che mostra l'esito di un tentativo di logon ad un server. Personalmente il giorno in cui ho iniziato a scrivere IMHO sono partito immediatamente con una idea precisa in testa, ovvero che la tray bar dovesse consentirmi facilmente di accedere al programma proprio per semplificare al massimo l'attività di editing dei post, perciò giocoforza il passaggio alla versione 2.0, costruita su una architettura client-server, doveva mantenere questa importante funzionalità. Diversamente da quello che succedeva in IMHO 1.2 però, la nuova tray icon non fa capo ad una form, ma semplicemente ad un processo realizzato estendendo la classe ApplicationContext, che consiglio a tutti di prendere in considerazione per la realizzazione di applicazioni form-less. Questa scelta è stata dettata dalla necessità di diminuire il più possibile il footprint nella ram dell'applicazione minimizzata che da alcuni test ora si aggira intorno ai 14MB contro i 40MB della precedente versione (rilievo effettuato solo con il TaskManager). Ora l'applicazione per girare non ha bisogno di alcuna form, e la speranza è che questo aiuti a renderla più leggera e quindi che convinca i più a tenerla sempre attiva. Attualmente le funzionalità della tray icon non sono complete. Ancora mancano le attività di polling del server collegato che penso realizzerò solo verso la fine, perciò è probabile che nelle prime versioni rilasciate queste ancora non siano presenti.

powered by IMHO 1.2


Stamane a pranzo, una interessante discussione con un collega appartenente al "lato oscuro della forza", ci ha visto scambiarci strali tra un boccone e l'altro di un'ottima pasta con il pesto, pomodori e caciotta. Si è parlato di Ruby, di Linguaggi di programmazione, e poi man a mano la discussione è scesa giù giù fino al boxing/unboxing, ai tipi primitivi, e così via.

Una normale discussione insomma, se a parteciparvi fossero stati solo due programmatori, magari al lume di candela, ma è curioso il fatto che in ascolto delle nostre erudite dissertazioni vi era Giulio, il mio collega grafico, che pur essendo un vero css-master, di programmazione ne mastica il mimino indispensabile.

Alla fine, in uno di quei rari momenti di silenzio che si inframezzano in una appassionata discussione, il buon Giulio ci ha fulminati con la sua sottile ironia sbottando:

Beh, io eviterei il boxing con un tipo primitivo...

E ora confessatelo: in quanti l'avete capita?

powered by IMHO 1.2


Ed eccolo infine. La migrazione all'indietro da Community Server verso .TEXT mi ha messo nella necessità di adattare il codice del Replicator per Community Server all'engine di .TEXT. Lo scoglio da superare è stata la mancanza di un sistema di scheduling che consenta di eseguire dei Job ad ogni periodo di tempo determinato. Ne è uscito un bel pezzo di codice, che ovviamente come ormai vi ho abituato metterò a disposizione entro breve, non appena lo avrò testato per bene. Il replicator per .TEXT contiene al suo interno un piccolo scheduler, basato su un HttpModule per evitare di dover ricompilare tutto l'engine. Alla prima chiamata viene avviato un processo che periodicamente verifica se uno dei Job registrati nel web.config è scaduto e in questo caso lo esegue per poi azzerarne il contatore. Credo che una feature del genere possa essere molto utile anche ad altre applicazione ASP.NET. Se a qualcuno interesa il meccanismo di funzionamento, consiglio la lettur di questo mio articolo.

powered by IMHO 1.2