Crad's .NET Blog

Premessa: ciò che scriverò è una banalità, ma secondo me in tanti non ne sono al corrente o non ci pensano. Di cosa parlo? Di cose del genere:

public const int MyConst = 10;

Il danno potenziale che le costanti pubbliche possono creare alla stabilità delle nostre applicazioni è enorme.

Why? Perché le costanti non sono altro che placeholder risolti in fase di compilazione. Questo vuol dire che, finché non si ricompila, il valore non viene aggiornato.

Implicazioni?

1. Assembly A che definisce una costante MyConst = 10
2. Assembly B che referenzia Assembly A e ne utilizza MyConst
3. Assembly A cambia MyConst a 15
4. Finché non ricompilo Assembly B, questo continua a vedere MyConst = 10

Ogni tanto mi capita di trovare righe di codice simili a quella in alto, con seguenti bug "strani" e dolori per scovarli. Ecco perché cerco sempre di abituare i junior che lavorano con me alla regola:

Le costanti devono essere sempre private o internal. Se serve esporle allora si utilizzino dei field readonly.

Augh!

Dopo il mio precedente lavoro su NHibernate, oggi Aspitalia.com ha pubblicato un mio nuovo articolo sul multithreading.

Grazie mille a Daniele per lo spazio che mi ha concesso e a Ricky per la pazienza nel correggerlo!

Chi l'avrebbe mai detto che un programmino fatto in un weekend per utilizzo personale riscuotesse tutto questo successo... L'hanno provato Simone e addirittura Phil Haack, e entrambi ne hanno parlato benone nei loro blog, convincendomi a farlo diventare un progetto open source a cui si sono aggiunti come committer!!

Detto, fatto, lo trovate su Google Code, rinominato per l'occasione come Blog Commander (BlogManager era già utilizzato e faceva anche un filo schifo!!). Chi vuole apportare migliorie, mi droppi una mail!

Ciao!

Bene, allora la nuova versione di Blog Manager (il nome è uno schifo, lo so) fa per voi! Qualche post fa, se ricordate, vi ho raccontato di un piccolo tool realizzato dal sottoscritto che, grazie ad un'interfaccia simil-Explorer, consente di riorganizzare velocemente tutte le categorie del blog facendo uso dei MetaWeblog API.

Mi è sembrato così comodo che, dopo essere stato lì a compiacermi come un fesso (e senza cambiare le categorie), mi son detto: "ma perchè non fare lo stesso anche per i Technorati Tags, che son così pallosi da inserire nei post vecchi che ne sono sprovvisti? In questo modo potrei sfoggiare una rigogliosa Tag Cloud e il mondo sarebbe finalmente mio!!"

Da questo vero e proprio documento dei requisiti, ho partorito la versione 1.1, che offre uno stupendo e alquanto esplicativo Tab

Come funziona? Selezioniamo nella toolbar il numero di post da scaricare e poi click sul pulsante Download.

A quel punto, grazie ad una serie di Regex, tutti i tag contenuti nei post scaricati verranno elencati nella CheckedListBox in basso, mentre i post appariranno nella ListView a destra, con tanto di Tooltip con il contenuto.

Ora basta selezionare un po' di post, e spuntare i checkbox relativi ai tag desiderati e poi premere il button Salva sulla Toolbar in alto.

Attenzione! A differenza delle categorie, la funzione dei Technorati Tags lavora per forza di cose tramite regex, perchè devono essere estratte dal body del post; pertanto potrebbe esserci un certo margine di errore nel match del pattern utilizzato. Io l'ho provato in diversi casi e lo stesso ha fatto il bravo Simone Chiaretta che mi ha dato una mano con i test, e non abbiamo evidenziato problemi. Sarebbe comunque opportuno effettuare un backup dei post per sicurezza. Per chi, come me, ha un blog su uno spazio condiviso e non ha accesso al database, ci sono due alternative

1. Se si utilizza Subtext, esportare i post su BlogML tramite l'apposita funzione nella sezione Admin;
2.  Utilizzare le funzionalità di Backup e Restore (quest'ultimo spero di no ) che si trovano in Blog Manager nel menu Tools.

Ovviamente, come per la volta precedente, vale la seguente regola ferrea:

Questo software è rilasciato gratuitamente "AS IS". L'autore (cioé il sottoscritto) non è in alcun modo tenuto a fornire assistenza né tantomeno potrà essere ritenuto responsabile per eventuali problemi inerenti il suo utilizzo. In altre parole, se vi si sminkia (questa volta con la "K") totalmente il blog o il sistema operativo, se un hacker accede al vostro conto in banca, ecc.ecc., non bussate alla mia porta!

E chi non è d'accordo, eviti di utilizzarlo. Cosa manca? Ah sì, i link: qui per i sorgenti (rigorosamente Visual Studio 2008 ma su .NET 2.0) e qui l'eseguibile.

Ogni feedback è prezioso come un litro di birra ghiacciata nel deserto.

Ciao

La scorsa domenica ho dedicato un paio d'ore di tempo alla realizzazione di un piccolo tool per la gestione delle categorie sul blog, di cui parlerò più approfonditamente tra un paio di giorni (appena riesco ad ultimarlo).

Come sa chiunque utilizzi abitualmente Windows Live Writer, SubText, il vecchio .Text e altri blog engine espongono una serie di servizi remoti chiamati MetaWeblog API (qui un piccolo white paper), raggiungibili all'URL

http://[blogurl]/services/metablogapi.aspx

Il protocollo utilizzato è XML-RPC (qui maggiori informazioni) ed è basato su uno standard di comunicazione estremamente più semplice dei Web Service tradizionali. Non trattandosi di SOAP, però, essi non sono direttamente utilizzabili all'interno di un'applicazione .NET tramite l'introduzione di una Web Reference.

Come fare dunque? Beh, Windows Live Writer ha un suo provider interno di interfacciamento; io, per evitare di riscrivere tutto, ho usato XML-RPC.Net, che è gratuito e funziona benone.

Per utilizzarlo è sufficiente creare un'interfaccia con i metodi desiderati, che devono essere poi mappati sulle corrispondenti procedure esposte dal servizio tramite un custom attribute:

1 public interface IMyService : IXmlRpcProxy
2 {
3     [XmlRpcMethod("nomeDelMetodoRemoto")]
4     string RemoteMethodThatReturnsAString(int parametro1, MyType parametro2);
5 }

Nel caso in cui i tipi coinvolti (siano essi parametri o valori di ritorno) siano tipi complessi, come MyType nello snippet precedente, è sufficiente definire opportune struct, avendo cura di esporne i relativi membri come field pubblici:

1 public struct MyType
2 {
3     public int booleanField;
4     public string stringField;
5     public OtherType complexField;
6 }

A questo punto, per invocare il servizio è sufficiente costruire un proxy ed eseguirne i metodi:

1 IMyService proxy = XmlRpcProxyGen.Create<IMyService>();
2 proxy.Url = "http://urldelserivizio";
3 string res = proxy.RemoteMethodThatReturnsAString(...parametri...);

La generazione dinamica del proxy avviene tramite Reflection.Emit, ed è quindi piuttosto veloce. A questo link trovate un esempio di utilizzo di XML-RPC.Net proprio per invocare le MetaWeblog API.

Sciaooo :-)

E' sicuramente una best practice quella di chiudere un datareader quando questo è stato utilizzato. Consideriamo però il seguente snippet di codice:

DBConnection connection;
using (connection = factory.CreateConnection())
{
    DBCommand cmd = connection.CreateCommand();
    // some code
    DBDataReader dr = cmd.ExecuteReader();
    // some code
}
Console.WriteLine(connection.State);

Il cursore non viene esplicitamente chiuso, questo è vero, ma viene comunque invocata la dispose della connection verso il DB.

Con SqlClient questo snippet funziona come previsto, stesso dicasi per OleDbClient e per Oracle.DataAccess: lo snippet stampa "Closed" sulla console e, se si disabilita il connection pool, si può notare come all'esterno del blocco using non ci sia alcuna connessione attiva presso il DB Server.

Con System.Data.OracleClient, invece, si verifica un comportamento anomalo: nonostante la connection risulti comunque chiusa, fisicamente al termine dello snippet si può verificare come rimanga una connessione appesa e quindi non riutilizzabile neanche dal connection pool. Questo non accade chiudendo esplicitamente il datareader, con una leggera variante allo snippet di prima:

DBConnection connection;
using (connection = factory.CreateConnection())
{
    DBCommand cmd = connection.CreateCommand();
    // some code
    using (DBDataReader dr = cmd.ExecuteReader())
    {
        // some code
    }
}
Console.WriteLine(connection.State);

Ovviamente me ne sono accorto in produzione :-(

Vediamo se riesco... dato che comunque mi sembra piuttosto simile al vecchio 70-316 che ho superato circa un annetto fa, ho pensato di dare un'accelerata drastica ai miei studi e sostenerlo entro il mese di gennaio. Chissà se ce la farò!

In ogni modo, ho appena acquistato i test su MeasureUp; cavoli, certo che 55€ per la versione online di 30gg non è proprio a buon mercato!!

Prendo spunto dai post di Lorenzo e di Raffo per segnalarvi un bell'articolo di MSDN Magazine di Gennaio di James Kovacs a proposito dei memory leak che possono verificarsi nelle nostre applicazioni .NET se scritte "male", anche nel caso di solo codice managed.

Credo che ogni sviluppatore di buon livello debba annoverare, nel suo bagaglio culturale, la conoscenza di come funzionano le cose a basso livello, perché in alcuni casi bisogna implementare IDisposable (tempo fa ho scritto qualcosa in proposito qui), cosa sono boxing e unboxing, cosa succede quando scriviamo

myButton.Click += new EventHandler(myButtonClickHandler);

o qual è l'overhead di lavoro a cui costringiamo il CLR nel caso in cui chiamiamo un metodo marcato come virtual.

Quindi... comprate tutti CLR via C# di Jeffrey Richter, da bravi!

powered by IMHO 1.3