Vista vs. XP
About a month ago, I finally gave in and upgraded my main dev machine. It was getting a little slow for the my various build tasks and running multiple instances of LFS for my test environment just didn't work. That Bioshock had just been released had nothing to do with it, really!
Anyway, I didn't actually upgrade as much as build a new machine and use my old dev as another test target. So I figured I might as well go for Vista on this machine. I'd heard plenty of anecdotes, usually sticking to one end of the love/hate spectrum or the other and I wanted to find out where i'd fit.
Well, it's been a month with Vista, but with regular excursions to XP on other machines and overall I am right at the meh centerline of the spectrum. Vista gives me no trouble, anymore than any new OS install does until i tweak it to my liking. There are various UI aspects that I like. But if I was forced to use only XP, I'd just shrug my shoulders. I really can't find anything about the OS that I care deeply enough to make me prefer or dislike it more than XP.
So, no it's not the worst product MS has ever put out and clearly a sign that they're finally loosing the grip on the desktop stranglehold, as you will hear from one extreme, nor is it a next generation OS solving all the problems we've been having with the previous generation OSs. It's just another version of Windows, if you ask me. From my experience I just have to discount tales of massive downgrade rushes from users as FUD that's becoming somewhat self-fulfilling. Sure, you ought to have good hardware for Vista. But what software that is put out today doesn't work better on today's hardware vs. the machine you bought when XP was fresh.
Even for my latest Redhat Fedora install I finally had to admit that my trusty home server from 5 years ago was a bit too weak to handle it. Sure, proportionally Fedora needs much less hardware, but then I don't try to put it through heavy UI lifting, which is, imho, where most horsepower, for better or for worse, goes these days.
Labels: Vista, XP
Automatic properties syntax wish
Just a quick thought on on Automatic properties in C# 3.0 (.NET 3.5, Orcas, whathaveyou). I, like most .NET developers, have spent too much time writing
private string foo;
public string Foo
{
get { return foo; }
set { foo = value; }
}
This can now be replaced with
public string Foo { get; set; }
Now that's nice and all, but for the most part it doesn't seem like a big step up from just making your field public. Now, you do get the benefit of being able to use this property in places where reflection is used for exposing properties, i.e. in most data-binding scenarios, which don't accept public fields. And it let's you implement interfaces, since they also can't define public fields. But that's a lot more useful, at least to me is replacing
private string foo;
public string Foo { get { return foo; } }
with
public string Foo { get; private set; }
Now you can create those read-only properties with very simple, clean syntax. That'll clean up a lot of code for me.
But finally we still have the scenario where properties have side-effects, like calling the event trigger for
INotifyPropertyChanged. This cannot be expressed with automatic properties and we're back to defining a separate private field. What I would love to see is some syntactic sugar along the lines of
public string Foo
: private _foo
{
get;
set
{
string previous = _foo;
_foo = value;
if(previous != _foo)
{
OnPropertyChanged("Foo");
}
}
}
I know this doesn't buy that much in syntax terseness (the get is shorter and you don't have to define the type of _foo), but it means that the private storage used by the property is part of the property definition, which makes the definition that much more easy to read, imho. That, or allow pre and post conditions for
set in Automatic Properties, although the syntax i can think of for that doesn't seem cleaner than the above.
Labels: automatic property, c#, INotifyPropertyChanged
TDD & you can't test what you can't measure
Recently I've been dealing with a lot of bug fixing that I can't find a good way to wrap tests around. Which is really annoying, because it means that as things get refactored these bugs can come back. These scenarios are almost always UI related, whether it's making sure that widgets behave as expected, or monitoring the visual state of an external application I'm controlling (Live For Speed, in this case). What all these problems have in common is that the recognition of a bug existing can only be divined by an operator, because somewhere there is lack of instrumentation that could programatically tell the state I'm looking for. And to paraphrase the old management saying, "You can't test what you can't measure".
My best solution is the usual decoupling of business logic from UI. Make everything a user can do an explicit function of your model and now you can test the functions with unit tests. At least you business logic is solid, even if your presentation gets left in the cold. And depending on your UI layer, a lot of instrumentation can still be strapped on. WinForms controls are generally so rich that nearly everything you would want to test for you can probably query from the controls. But things that you can test and see within a second may be a lot of lines of code to test programatically and of course go right out the window when you refactor your UI. And if your trying to test the proper visual states of a DataGridView and its associated bindings, then you're in for some serious automation pains.
I know that business logic is the heart of the application, but presentation is what people interact with and if it's poor, then it doesn't matter how kick ass your back end is. So for the time being that means that UI takes a disproportionate amount of time to run through its possible states and it's something I would like to handle more efficiently.
Labels: .net, c#, LFS, tdd
