Web Log di Adrian Florea

"You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away." Antoine de Saint-Exupery
posts - 440, comments - 2715, trackbacks - 3944

My Links

Archives

Post Categories

Image Galleries

.RO Blogs

.RO People

.RO Sites

Blogs

Furls

Links

vinCitori

aprile 2004 Blog Posts

KB818803 patch download

Per chi non vuole chiamare MS PSS per risolvere KB 818803 in .NET 1.1. le patch si possono scaricare da InstantASP  per Windows 2000 e per Windows 2003 Server

posted @ venerdì 30 aprile 2004 11:35 | Feedback (11) | Filed Under [ Carillon .NET ]

Page 23

1. Grab the nearest book.Building An ASP.NET Intranet2. Open the book to page 23.Eccola qui...3. Find the fifth sentence. unu, doi, trei, patru, cinci... conto più veloce in romeno :-)4. Post the text of the sentence in your journal along with these instructions."The most basic requirement here is having the .NET Framework installed."E sì, eh... :-)

posted @ lunedì 26 aprile 2004 14:43 | Feedback (11) | Filed Under [ Varie ]

Ward @ Microsoft

Per chi non lo sapesse ancora, dal dicembre scorso un altro peso massimo, Ward Cunningham, ha deciso di lavorare per la Microsoft come architect nel gruppo PAG (Prescriptive Architecture Guidance). Chi manca ancora? :-)

posted @ domenica 25 aprile 2004 17:01 | Feedback (15) | Filed Under [ Pattern Dappertutto ]

Workaround per Infragistics.WebUI.UltraWebNavigator.UltraWebMenu

Per chi lavora con Infragistics NetAdvantage 2004 Volume 1 e vuole utilizzare Infragistics.WebUI.UltraWebNavigator.UltraWebMenu non solo in maniera drag-and-drop del componente, un workaround per evitare System.NullReferenceException è questo: sostituire la riga:   string appDir = Page.Request.ServerVariables["APPL_PHYSICAL_PATH"];nel metodo:   public int ReadXmlFile(string, bool, bool)della classe:   Infragistics.WebUI.UltraWebNavigator.UltraWebMenu ("UltraMenu.cs")con:   string appDir = System.Web.HttpContext.Current.Request.ServerVariables["APPL_PHYSICAL_PATH"];

posted @ sabato 24 aprile 2004 17:04 | Feedback (43) | Filed Under [ Carillon .NET Bugs? ]

Sealing for flexibility! Inheriting for flexibility!

Tante volte forse avete associato l'eredità con la flessibilità. Qui di seguito un punto di vista diverso ma altrettanto interessante:"Sealing members or leaving them non-virtual also allows you more flexibility in changing your class's implementation in the future, by limiting users' points of customization."(Brian Grunkemeyer, SLAR p. 72) E se vi chiedete cosa vuol dire "begrudgingly" in inglese (nella stessa p. 72) , eccola qui spiegata :-) Pensavo che fosse una parola un po' begrunkemeyeriana... :-)

posted @ sabato 24 aprile 2004 13:57 | Feedback (12) | Filed Under [ Pattern Dappertutto Varie ]

Design patterns nel Framework .NET - 5

Continuo la serie con un esempio di uno Strategy (pp. 315-323 in GoF):8. la classe astratta System.Array, l'interfaccia System.Collections.IComparer e le classi che implementano questa interfaccia fanno lo Strategy dove:- System.Array fa la Context;- System.Collections.IComparer fa la Strategy;- le classi che implementano System.Collections.IComparer fanno le ConcreteStrategy;- il metodo Compare fa l'AlgorithmInterface;- i metodi BinarySearch e Sort fanno il ContextInterface.

posted @ sabato 24 aprile 2004 02:36 | Feedback (11) | Filed Under [ Pattern Dappertutto ]

ECMA TR/84

Joel Marcey, che firma la prefazione del libro di Brad Abrams, è anche l'autore di questo piccolo e simpatico tool di cui racconta nella prefazione, scritto in C# (un'unica classe, Intel.DSL.ECMA.DocGen) per trasformare le specifiche CLI da XML a Word. Adesso si chiama, un po' pomposo :-), ECMA TR/84 e lo trovate qui (20,2 MB), sorgenti compresi (31,1 KB) :-)

posted @ venerdì 23 aprile 2004 23:43 | Feedback (10) | Filed Under [ Carillon .NET ]

Linee guida - archivio completo

Gianluca segnalava qui oggi le prime quattro parti della serie di post "On Designing Good Libraries" di Brad Abrams. La serie completa però finora comprende anche due post di commenti per le parti II e III. I post di questa serie sono in realtà appunti di un corso interno che Brad tiene agli sviluppatori del framework. L'archivio completo delle sue linee guida (non solo di questa serie) qui. Tanto che ci siamo date un occhio anche su FxCop Design Rules Index

posted @ mercoledì 21 aprile 2004 13:45 | Feedback (11) | Filed Under [ Pattern Dappertutto ]

"Patterns are discovered rather than written"

"Patterns are discovered rather than written" - dice James W. Cooper nel suo libro (pag. 6) - una frase che mi piace molto. Perché infatti così è nato quell'all-time bestseller che ormai tutti chiamiamo GoF: dalla tesi di dottorato di ricerca di Gamma, tesi in cui analizzava dei pattern all'interno di un framework (ET++). C'è un articolo classico di Ralph Johnson (il terzo del Gang) "Documenting Frameworks using Patterns" pubblicato in quei primissimi tempi (1992) che vede i pattern come un mezzo importante per la documentazione di un framework. Lo trovate qua.

posted @ martedì 20 aprile 2004 01:45 | Feedback (10) | Filed Under [ Pattern Dappertutto ]

Factory Method all'interno di .NET

Il mese scorso avevo iniziato una serie di post dove individuavo (non in modo automatico) delle classi che implementano dei pattern (alcuni presi da GoF, altri da Fowler). Poi ho pubblicato un articolo che individua in modo automatico le classi singleton e sto lavorando ad un altro per l'individuazione di quelle che implementano il pattern Strategy. Fin quando non avremo metodi automatici per queste individuazioni, ci accontenteremo di scoprirle ad occhio.C'è un articolo di cui vi ho parlato (ieri e oggi) per niente male. Quello che vi presento qui di seguito è solo per fare un po' di ordine negli...

posted @ domenica 18 aprile 2004 23:26 | Feedback (9) | Filed Under [ Pattern Dappertutto ]

Piccolo errore

Nell'articolo su cui ho postato ieri, che individua alcune classi che implementano il pattern Factory Method all'interno del Framework .NET, c'è un errore: il FactoryMethod di cui parla non è GetApplicationInstance bensì GetNormalApplicationInstance. Comunque sia, non aspettatevi in questo caso un pattern Factory Method tanto classico.Sto organizzando gli esempi dell'articolo (togliendone alcuni e aggiungendone altri) in una tabella, spero più chiara, che la posterò stasera :-)

posted @ domenica 18 aprile 2004 19:54 | Feedback (8) | Filed Under [ Pattern Dappertutto ]

Dottore in dotcctor :-)

Per essere ancora più dottori in dotcctor (.cctor è l'abbreviazione di costruttore di classe), a parte la lettura del post di Brad Abrams segnalato oggi da Corrado e degli articoli di Jon Skeet e Satya Komatineni, otterrete un'immagine completa su questo argomento leggendo 4 pagine (pp. 187-190) nel libro di Richter e 3 (pp. 60-62) nel libro di Box e Sells. E se dopo ne avete ancora voglia e desiderate andare veramente fino in fondo, leggete per ultimo questo post del micidiale Chris Brumme. Molto interessante una delle proposte di Jon Skeet alla fine del suo articolo:"An attribute would be a perfectly reasonable solution...

posted @ domenica 18 aprile 2004 17:55 | Feedback (16) | Filed Under [ Carillon .NET ]

Concorso scaduto :-)

Bella notizia sul concorso di PC Professionale con dei premi veramente interessanti. Peccato però che su UGIdotNET è apparsa solo oggi (18/04/04) e l'applicazione con qui partecipare doveva essere inviata più di un mese fa (15/03/04)...

posted @ domenica 18 aprile 2004 17:06 | Feedback (28) | Filed Under [ Varie ]

TypeNamesHaveOnlyShortAcronymsAllCaps

La regola "Type name acronyms of three or more characters are Pascal-cased" già esiste nell'FxCop. Cercherò allora un'altra per iniziare a giocare con Reflection Engine SDK.In un post precedente, segnalavo una trentina di classi che non rispettano questa regola. Michael Fanning risponde così:"The MS Design Guidelines were developed concurrently with the framework"alla domanda:"Why analysis of a Microsoft assembly such as System.dll results in 1161 violations of which over half are errors. Do Microsoft not use this tool or consult their own guidelines internally?"

posted @ domenica 18 aprile 2004 02:09 | Feedback (6) | Filed Under [ Pattern Dappertutto ]

"Qualche" classe che non rispetta i naming patterns :-)

Farò per l'ennesima volta il pignolo (Uuuhhh...) ma ieri sul treno leggo il post di Brad Abrams "On Designing Good Libraries" dove nella sezione "Naming Patterns" trovo:"Abbreviations of more than 2 letters are cased as words, otherwise ALLUPPER (IO vs. Html)"e oggi incontro nel Framework un sacco di classi che non rispettano questo pattern - solo se ci limitiamo al namespace System.Security.Cryptography guardate quante sono: CryptoAPITransform, DES, DESCryptoServiceProvider, DSA, DSACryptoServiceProvider, DSASignatureDeformatter, DSASignatureFormatter, HMACSHA1, MACTripleDES, PKCS1MaskGenerationMethod, RNGCryptoServiceProvider, RSA, RSACryptoServiceProvider, RSAOAEPKeyExchangeDeformatter, RSAOAEPKeyExchangeFormatter, RSAPKCS1KeyExchangeDeformatter, RSAPKCS1KeyExchangeFormatter, RSAPKCS1SignatureDeformatter, RSAPKCS1SignatureFormatter, SHA1, SHA1CryptoServiceProvider, SHA1Managed, SHA256, SHA256Managed, SHA384, SHA384Managed, SHA512, SHA512Managed, TripleDES, TripleDESCryptoServiceProvider, DSAParameters, RSAParameters. Viva l'IntelliSense!!! :-)Se non vi...

posted @ sabato 17 aprile 2004 19:24 | Feedback (7) | Filed Under [ Pattern Dappertutto ]

Factory EndoMethod?

Nell'articolo "The Factory Design Pattern", Amit Goel individua all'interno del Framework .NET delle classi che implementano il pattern Factory Method (GoF, pp. 107-116). Uno dei suoi esempi riguarda le classi del namespace System.Security.Cryptography. Se si analizza con attenzione, per esempio il "ramo" SymmetricAlgorithm-DES-DESCryptoServiceProvider, si trova il pattern in una variante non molto ortodossa. L'abbiamo chiamata Factory EndoMethod per il fatto che il FactoryMethod della classe Creator restituisce sempre Creator e non Product come nella variante originale del pattern e il FactoryMethod della classe ConcreteCreator restituisce a sua volta ConcreteCreator e non Product (mi sono ispirato al termine endomorfismo che i...

posted @ sabato 17 aprile 2004 18:09 | Feedback (4) | Filed Under [ Pattern Dappertutto ]

I metodi della classe interna System.__Filters non sono ancora static

Nel commento della classe interna System.__Filters si può leggere: "The following are the built in filters defined for this class. These should really be defined as static methods. They are used in as delegates which currently doesn't support static methods. We will change this once the compiler supports delegates." o in quello del costruttore static della classe System.Type: "Because the current compiler doesn't support static delegates the _Filters object is an object that we create to contain all of the filters." Lo so, è un'osservazione un po' da pignolo :-) ma i metodi di questa classe (System.__Filters) sono ancora instance (dal luglio 1998...) e...

posted @ lunedì 12 aprile 2004 00:25 | Feedback (7) | Filed Under [ Pattern Dappertutto Bugs? ]

Sean O'Driscoll e la danza del drago :-)

Essere direttore worldwide del programma MVP a volte vuol dire fare la danza del drago - non era il drago, simbolo di forza e benevolenza, così come lo sono gli MVP? :-)

posted @ domenica 11 aprile 2004 23:27 | Feedback (9) | Filed Under [ Varie ]

/win32res via IDE

In VJ# è possibile tramite VS passare /win32res al compilatore. In VC#, proprio no...

posted @ giovedì 8 aprile 2004 00:57 | Feedback (3) | Filed Under [ Carillon .NET ]

Utilizzare file di risorse unmanaged in applicazioni managed

Per chi, come me, deve utilizzare file di risorse unmanaged (Win32) in applicazioni .NET, questo articolo di Kenny Kerr, "Icon Browser: An Exercise in Resource Management" sarà di grande aiuto.Nel mio progetto, un porting di un prodotto client/server scritto in VB6 in un'applicazione web scritta in ASP.NET e C#, devo utilizzare le icone di un file .RES (non è proprio banale)

posted @ mercoledì 7 aprile 2004 14:11 | Feedback (9) | Filed Under [ Carillon .NET ]

Non esistono delegate singlecast

Per vedere se un tipo t è delegate o no, basta verificare se deriva da System.MulticastDelegate: t.BaseType != null && t.BaseType.Equals(typeof(System.MulticastDelegate)) cioè non è necessaria la verifica singlecast (System.Delegate). La storia strana che spiega tutto ciò la potete leggere nel libro di Richter (pp. 375-376 per la traduzione italiana) e nel post di Brad Abrams.

posted @ domenica 4 aprile 2004 20:14 | Feedback (9) | Filed Under [ Carillon .NET ]

Un altro singleton di .NET: si chiama Greg :-)

Appena uscito il mio articolo sui singleton all'interno di .NET, ecco che ne ho trovato un altro: si chiama Greg - Greg Singleton :-) - ed è PM nel CLR Team for the .NET runtime's configuration infrastructure and administration tools.A parte gli scherzi, sono contento che ad alcuni è piaciuta l'idea dell'articolo e spero che verso la fine di questo mese ne sarà pubblicato un altro (sempre qua)

posted @ sabato 3 aprile 2004 00:16 | Feedback (9) | Filed Under [ Pattern Dappertutto Varie ]

Powered by:
Powered By Subtext Powered By ASP.NET