Blizzard of great new stuff for today, summarized nicely by ScottGu.
The new Parallel FX stuff is really quite cool. It’s a cliche to say that the number of CPUs in a typical machine is increasing while each individual CPU is not actually faster. But it’s great to see Joe Duffy release Parallel FX and PLINQ to to actually address the challenge.
All very cool can’t wait till next week for ASP.NET MVC.
1 Comment | 
Ajax, Architecture, code, Development, finance, Microsoft, ScottGu, SilverLight, Visual Studio, Web, WPF, xml | 
Permalink
Posted by Jan Bannister
I went to Mix:UK last week and have waited a while to let my impressions gel. I find that live blogging this type of thing just makes you a part of the echo chamber.
A number things stick in my mind from Mix:UK
I must say that Software Transactional Memory (STM) is the thing that sticks in my mind. WPF was very cool, VS2008 had excellent new improvements and the sneak peeks (including a WPF MRI visualizer) were excellent but STM lingers in my mind.
STM has a great appeal because it is a truly revolutionary idea that cuts to the root of a problem. Just as the call stack revolutionised modern programing; I’m sure STM will be the first step into a new concurrent software revolution.
Haskell already has an implementation so I’d love one for the CLR from Simon at MS Cambridge 
Leave a Comment » | Architecture, business, code, Data Structures, Development, Microsoft, ScottGu, SilverLight, Visual Studio, Web, WPF | Permalink
Posted by Jan Bannister
I recently came apon one of my recurring peeves: XmlSerializer. It’s one of those classes that just bits you again and again. It has a number of annoying behaviours but the worse has to be it propensity to write to disk. Why? Why, of all classes, would you choose XmlSerializer to perform file IO?
It’s lunacy since the class is typically used in scenarios where you’re in executing from inside a sandbox, like XBAP, Silverlight or other partial trust settings. And then WHAMO your auto generated SOAP proxy… writes to disk!
It just makes no sense. However I know why XmlSerializer writes to disk; because it uses Reflection. Which ‘emits’ a dynamic assembly , again, to disk. Which in itself is further lunacy, is it not? I’m dynamically building an object, I know, lets write to disk.
.Net is capable of loading Assemblies from MemoryStreams, I’ve done it, so why default to writing to disk? It’s like the bank teller going to The Vault to get you a fiver: time-consuming and insecure.
Has anyone got a defence for XmlSerializer? … It better be sturdy 
3 Comments | Architecture, code, Development, Microsoft, xml | Permalink
Posted by Jan Bannister
I’ve seen my fair share of code; some written by me, some written by vast teams; and a lot in-between. And I’ve learned many of ways to spot Garbage. That is, rubbish code. Code that will bring you pain and will be the source of ‘Magic’ to the less experienced.
And I’m going to share with you a simple trick to help you spot it; meaningless class names.
Granted this is not new, Steve McConnell of Code Complete fame extols the virtue of good class names as do, no doubt, many others. But where they tell you to think hard about naming your classes, I give you the taxonomy of other people’s smells. And we all prefer to gloat than code carefully…so hear goes.
Manager
Any class with manager in it is a sure sign it was written in a hurry to fill some gap. Manager? What is it managing? Is it a collection? Does it construct objects? Dose it run salary reviews for it’s managed objects? Who knows?
If you see ‘managers’ in your code ask yourself if what they actually do could be expressed more clearly. Replace ConnectionManager with ConnectionPool, ConnectionLookupTable, OpenConnectionSource or (if you must) ConnectionFactory. Each of the later class names gives you a better idea of what the ‘Manager’ actually does.
Helper
Any class with helper in it is a sign that it was written to do some random look-up or complex object manipulation. This is sure sign that the Object hierarchy sucks in some profound way or that similar concepts are implemented differently.
Look in classes called helper and try and see why you need their help. Then change your class structure so you don’t need it.
Handler
Similar to Manager and acceptable in event handle nomenclature, but not for a class. Way too vauge.
Executor
Another meaningless ‘do-something’ word I’ve seen a few times. Typically used to name classes that should be called something like ThreadPool, MessageDispatcher or BackgroundDownloader.
Manipulator
Usually comes in the form of DataManipulator. Great indication that similar but not identical structures have been used to model the same thing in different places.
Object
This one really confuses me. But I’ve seen EmailMessageObject and the like. ‘Object’ is totally redundant, we know it’s an object. I’ve not seen a class with Class in its name yet but I’m sure I’ll find one.
Array
Every time I’ve seen a MessageArray or similar the class itself has implemented some odd data structure that was definitely not and Array. If it really is an array, you don’t need a class to represent it. And it if your ‘Array’ is doing something odd see if it fits into an existing Collection type there are many to choose from.
Incidentally the one I see most often re-implemented is dequeue which actually does not have a .Net standard library implementation, which is a pity, but LinkedList is semantically very similar.
Data
Data Access Layers abound and having a class called DataAccessLayer is OK, I guess. Buy you only get one! Every other class should specify what data it intends to represent or operate on.
OK mini-rant over.
If you have any other rules of thumb or you think mine a themselves rubbish I’d like to hear.
3 Comments | Architecture, code, Data Structures, Development | Permalink
Posted by Jan Bannister
