di .NET e di altre amenità

Eccomi, reduce di una serata trascorsa in una città che non mi appartiene, che non comprendo ma che rispetto nella sua grandiosa bellezza carica di storia.

Napoli è per me un enigma.

Una città piena di vita, ma così morta, piena di energia ma così scarica. Giri le sue strade e vedi quello che non vorresti fosse la tua città, contornato di splendide bellezza di un valore culturale inestimabile, ma così buttate via. Vedi le strade in decadenza che conducono migliaia di persone lungo i percorsi della loro vita. Vedi la gente che sopravvive a questo stillicidio dei piccoli crimini quotidiani, dal semaforo bruciato alla corsa senza casco, dal borseggio in destrezza a qualcosa di più, senza considerare che il piccolo che ammettono, giustificano e commettono è l'humus per i crimini, quelli veri. Loro la città la vivono, orgogliosi, perchè pensano di averla domata, ma in realtà non la sanno controllare.

Napoli è una splendida città.

L'aria calda a Dicembre, l'odore del mare, lo sporco nelle strade, il disordine, e... La cortesia impagabile della gente, di quella che noi Veneti non riusciamo nemmeno ad immaginare. La veracità delle voci nei cortili e nelle strade, l'amicizia che lega le persone che si salutano dalla macchina. Qui tutti si conoscono, si incontrano pigliano u' cafè, e ne fanno il centro della loro vita che vivono con un'ironia impareggiabile. E poi la grandiosità dei suoi palazzi, che sono sopravvissuti ai secoli. Quasi intuisco l'appartenenza che lega la gente di questo luogo ad esso. 1

Eppure non la capisco.

Probabilmente è perchè mi sento straniero in un luogo che non conosco. Tutto sommato, che c'è di diverso nella medesima sensazione che sento quando vado a Milano. Ma Milano è diversa. E' una città che è plagia i suoi abitanti, per soldi, che li prende per la gola e li stritola. Napoli la fanno i napoletani, loro la spendono, non la comprano, loro se la mangiano e non ne sono divorati.

Vi prego, non prendete sul serio questo post. L'ho scritto all'1:00 di notte, in una camera di albergo dove manca la mia vita e non so nemmeno se riuscirò a postarlo dato che il mio cellulare non ha campo. Ma spero di essere riuscito in queste poche parole a descrivere la gioia e la tristezza che mi dividono. Non chiedetemi se Napoli e Milano mi piacciono. Ho solo tanta nostalgia di casa.

powered by IMHO

Non mettere mai un GradientPanel della SyncFusion come background di una Form soprattutto se la distribuite in Terminal Server.

Lo scrivo perchè questa cosa mi ha fatto perdere un intero weekend di riposo. Se capita anche a voi, una form che durante il rendering conta tanti flash come si possono trovare solo alla notte degli oscar, per almeno una ventina di secondi consecutivi, ricordatevi di questo:

1) non mettete il GradientPanel di sfondo perchè a quanto pare costringe il contenuto ad essere ridisegnato decine di volte

2) Createvi un panel DoubleBufferPanel come il seguente:

Il flag in questione faranno si che il flickering sia praticamente ridotto a zero:

I ringraziamenti ovviamente al maggico Raffaele.

powered by IMHO

La settimana sarà anche di fuoco, ma l'organizzazione è predisposta.

Portatile al seguito, chiavetta bluetooth e cellulare carico...

Nel Weblog si posta lo stesso.

powered by IMHO

Quella entrante non si può dire che sarà una settimana tranquilla.

Stasera alle 19:00 si prende il volo diretto a Napoli, dove domattina mi attende la prima demo del prodotto che sto sviluppando. Naturalmente oggi, non poteva essere una giornata di pura routine, ma la sindrome da predemo doveva far sentire il suo imperativo.

Mercoledì, mi aspetto una giornata di full immersion in riunione a trarre le conseguenze

Poi Giovedì arriva il sole, e si parte per Milano (ok, ma il sole lo lascio qui... a Milano sapete ancora cos'è?), dove sarò presente al Workshop dell'UgiDotNet. Nemmeno questa una giornata rilassante, ma è la più attesa.

Forza... non fa male!

powered by IMHO

Viste le richieste che mi sono state fatte nei commenti al mio precedente post, ho deciso di dare qualche dettaglio in più sulle tecniche di refactoring che ho utilizzato nella realizzazione di IMHO.

Occorre innanzitutto tenere presente che nelle fasi iniziali di sviluppo ho installato il Resharper. Questo tool, prodotto dalla stessa azienda che ha realizzato uno degli IDE più famosi per Java (IntelliJ IDEA), fornisce un bel po' di strumenti utili per rendere più agevole la scrittura del codice in VS.NET 2003 e per fare del vero e proprio refactoring. Quella che preferisco in assoluto è la possibilità di aggiungere gli using automaticamente quando si inseriscono delle classi che non sono mai state utilizzate. Tuttavia dopo pochi giorni di lavoro mi sono visto costretto a disinstallare il tutto. A quanto pare Resharper ha la brutta abitudine di fagocitare quanto più RAM possibile e rende instabile e inutilizzabile Visual Studio. Questo probabilmente perchè ha la pretesa di sostituire totalmente l'intellisense di VS, invece che semplicemente aggiungere le funzionalità mancanti.

Quindi in breve mi sono trovato nudo. Nessuno strumento per poter fare del refactoring assistito, e la necessità come si suol dire ha aguzzato l'ingegno. La chiave di tutto si chiama CTRL+SHIFT+B. Per i due che non sanno di cosa parlo, questa è la combinazione di tasti che compila la solution. Tutta la tecnica, che nel titolo ho sintetizzato con un pomposo Error Driven Refactoring, si basa sul provocare errori di compilazione. Facciamo qualche esempio:

Cambiare il nome ad una variabile, ad un tipo, oppure a un metodo, è il caso più banale. Si va sul membro che si desidera cambiare, lo si cambia e si compila. A questo punto, nel Task Panel si presenteranno un certo numero di errori, talvolta qualche centinaio. Non sempre serve risolverli tutti, perchè se avete mai fatto caso il compilatore più di qualche volta genera due o tre avvisi per lo stesso errore. La mia tecnica prevede di risolvere al massimo la prima decina e poi ricompilare. E avanti così finche il codice non da più errori. Sembra una attività ingrata, ma una volta che si è presa confidenza è più veloce di quello che si possa immaginare. Non è detto che a questo punto il codice compilato funzioni. Ad esempio se usate la reflection per istanziare un tipo è probabile che in fase di compilazione non ci sia alcun errore, mentre quando lo eseguite ovviamente solleva una eccezione. Una bella ricerca testuale non guasta.

Cambiare la firma di un metodo è un'altra cosa abbastanza facile. Analogamente al caso precedente si provoca l'errore cambiando la firma. Talvolta conviene dapprima cambiare il nome del metodo e completare il primo passaggio. Poi si cambierà il tipo di ritorno oppure i parametri e si procede nuovamente alla compilazione. In questi casi occorre avere la cautela di accorgersi quando si cambia il tipo di un parametro con uno che sia compatibile, ad esempio con una classe padre. Il compilatore in questi casi non ci viene in aiuto, ma se contestualmente create una errore fittizio inserendo un carattere estraneo nel nome del metodo è più facile che si ritrovino tutte le chiamate. Inoltre bisognerà avere la cautela di capire che cosa succede nel corpo del metodo. Anche qui un carattere estraneo nel nome del parametro che occorre modificare aiuterà a trovare tutti gli usi che sono stati fatti e a verificare che non vi siano anche errori logici oltre che sintattici. In questo caso non occorre nemmeno ricompilare perchè sarà l'intellisense a indicarci l'errore con una simpatica sottolineatura.

Accomunare alcune classi con un'unica classe padre. Tipicamente in questi casi, si parte dapprima con la realizzazione della classe base vuota e immediatamente la si sostituisce a object nelle classi che dovranno estenderla. Nessun errore dovrebbe presentarsi. Però se si accomunano pià classi significa che si intende spostare uno o più metodi e proprietà ad un livello più basso. Perciò mano amano si fà cut & paste e si trasportano tali metodi nella nuova classe. Ad ogni spostamento si compila e così si individuano ad esempio i membri privati che sono referenziati da tali metodi e si trasportano anch'essi. In breve la classe dovrebbe cominciare ad indicare che alcuni metodi sono sovrascritti e che occorre l'uso dell'operatore new. Questi sono i metodi che sono rimasti nelle altre classi e vanno del tutto cancellati assieme ai membri privati che sono i più difficili da scovare, perchè non danno errore. Ad accomunare spesso è un'interfaccia o una classe astratta. Ne pimo case non c'è alcun problema perchè quando l'interfaccia è finita la si fa implementare alle classi e nel digitare Visual Studio autonomamente creerà i metodi e ad accorgersi se esistono già. Con le classi astratte è un po' più complesso. Si aggiungono i metodi astrtti e quindi si dovranno aggiungere gli override dove mancano oppure creare i metodi vuoi facendosi aiutare dagli errori e dall'intellisense.

Estrapolare delle classi da un progetto per crearne uno nuovo. Questa è la forma di refactoring che mi piace di più. Occorre tenere presente sempre che alcune classi possono essere usate da altri assembly, e che talvolta il codice che si scrive diventa un buon candidato al riutilizzo. Perciò trasportarlo in un altro assembly è vitale. Quindi si crea il nuovo progetto. Io ho l'abitudine di dare al progetto il medesimo nome del namespace che contiene. Questo è di enorme aiuto ad orientarsi nel trovare quello che si cerca. Tornando al problema a questo punto usando il Drag & Drop si trascinano le classi da un progetto all'altro e contestualmente si aggiunge la nuova reference. I progetto dovrebbe compilare immediatamente perchè nelle classi spostate è rimasto il namespace originale. Quindi occorre un bel replace. Si evidenzia il namespace da cambiare e si premo CTRL+H. Quindi ci si assicura di avere lo scope di progetto e si sostituisce con il namespace nuovo. Finalmente il compilatore comincia a dare errori. Questi potranno essere causati dalla mancanza di una reference oppure da uno using sbagliato. Non resta che aggiungere quello che serve e la solution tornerà a ricompilare.

Quelli che ho indicato sono solo alcuni dei casi da gestire. Indicarli tutti mi sembrava improponibile. Quello che mi interessa far capire è che non serve avere dei tool molto evoluti per potersi dedicare alla tecnica del refactoring. A mio parere nessun tool potrà mai arrivare a fare tutto ciò che ci serve, ma con un po' di fantasia si arriva a trovare una soluzione efficace.

Ora non avete più scuse. Refactor your life.

powered by IMHO

Oggi le statistiche mi hanno segnalato che per la prima volta da quando le ho attivate, i visitatori affezionati hanno superato quelli nuovi. Senza trascurare il fatto che ho battuto tutti i record di presenza.

Un grande grazie a tutti e 181 .

powered by IMHO

Ho acquistato da poco il DVD di "The Day After Tomorrow", e tralasciando ogni considerazione sulla bontà della pellicola vorrei far rilevare un atto che io considero di vera pirateria legalizzata.

Quando si inserisce il DVD parte uno spot di 2/3 minuti che invita a non duplicare il DVD per questo e per quel motivo. A prescindere gli argomenti più o meno validi a favore o contro la pirateria che personalmente mi trovano molto dubbioso, trovo veramente pirata il fatto che io debba per forza sorbirmi ogni volta questo spottino perchè il lettore si rifiuta di saltarlo. A ben guardare, il fatto stesso che io veda quello spot è indice che il DVD l'ho comprato e quindi non vedo perchè debba essere penalizzato in questo modo assurdo.

Chi intente fare il mio stesso acquisto tragga le proprie conclusioni.

powered by IMHO

Ho già avuto modo di esprimere il mio disappunto nel notare che sarò costretto a scegliere tra le sessioni da frequentare al prossimo workshop, ma alla fine ho compreso i problemi che hanno portato a questa soluzione e ritengo che sia stato fatto un buon lavoro.

Perciò ho investito qualche minuto nel ragionare obbiettivamente su quali siano gli argomenti che veramente mi interessano e ho buttato giù il mio personale calendario. Sia chiaro che il calendario deriva esclusivamente dal mio interesse sugli argomenti e non ha nulla a che vedere con le persone che tengono gli interventi.

Ecco quindi il calendario

1) ore 10:00 Agile Methodologies (Marco Abis)

Questa è stata la decisione più sofferta, perchè l'intervanto di Lorenzo era di estremo interesse. Però in questo momento ritengo più utile per me comprendere meglio gli argomenti dell'Agile Development prima di altro.

2) ore 11:15 Refactoring applied (Luca Minudel)

Non fosse altro per capire se la mia interpretazione di refactoring come l'ho spiegata in un mio recente post, ho l'obbligo morale di seguire questa sessione. Mi spiace per i Design Pattern che amo estremamente, ma Andrea mi vedrà comunque nel suo successivo intevento

3) ore 12:30 Pranzo

LOL... potrei mancare?

4) ore 14:00 .NET e lo Unit Testing (Andrea Saltarello)

Lo unit testing è un altro obbligo morale. Ho parecchi dubbi su questa materia, e sono sicuro che Andrea saprà chiarirmeli tutti. Nulla contro Adrian, ma il suo intervento esce del filone che ho deciso di seguire per scegliere gli interventi.

5) ore 15:15 Pattern and Practice & Application Blocks: cosa sono e come si usano (Lorenzo Barbieri)

Questa sessione non me la perdo per nulla al mondo, anche perchè sto lavorando da svariati mesi ad una serie di articoli che probabilmente vedranno la luce il prossimo gennaio, sulle pagine di una nota rivista e che riguarda proprio gli application blocks. Pazienza per l'UML, soprattuto quello real world che è di sicuro interesse.

6) ore 16:30 Coffee Break

Sempre che le discussioni con gli oratori non mi impegnino troppo.

7) ore 17:00 Visual Studio 2005 Team System (Francesco Albano)

Parteciperò almeno alla fase iniziale dell'intervento, anche se temo che ad un certo punto dovrò andarmene per non arrivare a casa (350km più a est) troppo tardi. Spero almeno di arrivare alla fine dell'intervento e allontanarmi durante il q&a.

Questo mio calendario ha il solo scopo di far sapere ai partecipanti dove mi potranno trovare, se mi cercheranno, e non esprime in alcun modo un giudizio sugli oratori ne tantomeno un suggerimento. Spero vivamente che il materiale delle sessioni sia reso pubblico così da poterlo leggere con comodo, anche se la mancanza dell'oratore si farà sicuramente sentire.

Mi raccomando, venite in massa. A presto

powered by IMHO

Non credo propio di riuscire a raggiungere il livello dei Quiz# di Adrian Florea, ma voglio provare anche io a proporre il mio quiz.

Eccolo di Seguito:

Data una variabile inputValue che può assumere i seguenti valori: 1, 2, 128, 256, 4096, realizzare una formula che converta in una sola volta tale valore in una sequenza di questo tipo: 1 diventa 0, 2 diventa 1, 128 diventa 2, 256 diventa 3, 4096 diventa 4. In particolare a me questa formula è servita per convertire un dato che proviene dal database in un indice di un array che contiene i dati peculiari di ogni valore. Ho dovuto usare una formula perchè essa viene eseguita in una colonna calcolata di un DataTable.

Sono ammessi tutti gli operatori ammessi in una espressione C# ad esclusione dei costrutti ternari ( condizione ) ? vero : falso. Fate attenzione che si tratta di formula e non di algoritmo, perciò for, if, while, switch qui non contano

Usare pure i commenti per le risposte.

powered by IMHO

Ho appena terminato di scrivere un post per il weblog che elenca le sessioni cui parteciperò e i motivi delle scelte. Non so se postarlo subito, o attendere dopo il workshop, perchè non vorrei che qualcuno se la prendesse a male.

Che fare?

powered by IMHO

Visti gli svariati problemi che mi sono stati segnalati con il CVS di sourceforge, ieri sera ho provveduto a rilasciare uno zip contenente tutti i sorgenti di IMHO.

powered by IMHO

Sono lieto di annunciare che sono appena riuscito a sistemare le cose per fare in modo di essere presente il 2 dicembre al workshop dell'UgiDotNet. Mi interessa talmente tanto che temo di essermi iscritto addirittura due volte.

Non vedo l'ora.

powered by IMHO