StormBase.Net

This morning I read this post by Alfred Thompson about whether we are Software Engineers or something else. I can’t help but agree with him, as I don’t feel we are engineers (yet), our discipline is a little fuzzy to be classified as engineering I think.

However I think we are not alone in this boat. Not all engineering disciplines are quite so well cut. My father is an Engineering Pattern Maker. Yet a large proportion of his work involves hand tools to create his forms. Maybe the designing of the Pattern is engineering, but the creation of it is defiantly crafting as so much practical skill is involved in the creation. If instead of him making it, the design was given to a nice brainless CNC to make, would that CNC be as skilled and thus a craftsman(machine?), or would it magically become engineering due to the lack of a CNC's skills?

The same goes for science in my mind. This might be due to Robert M. Pirsig's excellent book [Zen and the Art of Motorcycle Maintenance], where he goes to explain that science is about having a theory(s) then proving or disproving it, and continuing until all theories have been eliminated. At this point you have 'fact', or have missed some theories. His main point on this was 'where do theories come from? If you are sat there with no theories, and then you suddenly think of one, where did it come from? It certainly does not seem like a scientific method of theory discovery' (I don’t have the book to hand, so can’t find the exact quote. I will update later when I get home). So science is a bit 'fuzzy' too?

This also applies to art. If a sculpture is to be created, it needs to be structurally sound, else it just won’t work. So some engineering is involved there too. And possibly science of materials too.

I think my point is that we are just trying to label everything into distinct categories, which just isn’t going to work, unless your categories are so wide that they might as well not exist.

There seems to be a lot of negativity towards the #Region in .net at the moment, with many people hating them and calling all usages of them 'retarded'.

I can see their point, especially when you see the odd class with regions like this:

Class Foo
{
  #Private Members
  #Protected Members
  #Friend Members
  #Public Members
  #Private Constructors
  #Protected Constructors
  #Friend Constructors
  #Public Constructors
  #Private Methods
  #Protected Methods
  #Friend Methods
  #Public Methods
}

Clearly the person who wrote this was ill at the time (I hope...), and besides, where would Protected Friends go? Hmm?

I however find regions useful, especially when writing objects (see what I did there?). Now while an object might have might be DRY and only have a Single Responsibility, it might also have many properties. What I tend to do with regions is hide my getters and setters:

Class Bar
{
  Member1
  ...
  Member2

  #Region Properties
    //....
  #End Region

  Method1(){/* */}
  ...
  Method1(){/* */}
}

This way I am hiding standard boiler plate code, and everything that actually matters is visible. If you don’t like hiding properties that have a lot of code in them, then your problem may be the fact that you have lots of code in the properties. Something like PostSharp could allow you to inject all your properties with the common code such as PropertyChanging(sender, e), PropertyChanged(sender, e).

If you need lots of specific code in a property, then it is surely under unit test? If it isn't, why not? And if it is, does it matter that you can’t see the property without clicking the little + sign?

One other slight point: with my method of #region usage, if you don’t like regions, you have one click to expand it (or if you don’t like clicking, Ctrl+M, Ctrl+M in VS will expand/collapse whatever is at the cursor position), so it really is not that difficult to cope with.

Like all technologies, use it when it makes sense. No Regions can be just as bad as many Regions.

I like fluent interfaces. I find them easy to read, and nice to program with. However the more I write them the more I notice there is a cost associated with them. It’s not much of a cost, but it is there none the less. To demonstrate say we have a class called Animator. It has the following properties and methods on it:

+ Control
+ Distance
+ DistanceType
+ AnimationType
+ Direction
+ Time
+ Algorithm
- Animate()

Now while you could just set all the properties and then call Animate(), a Fluent Interface makes thing nicer:

Animate
    .Control(Button1)
    .Slide
    .Right
    .By(60)
    .Using(New ExponentialAlgorithm)
    .Start()

To make the interface more constrained, there are about 4 classes being used:

Static Class Animate
  - AnimationExpression Control(Control con)

Class AnimationExpression
  - DirectionExpression Slide()
  - DirectionExpression Grow()
  - DirectionExpression Shrink()

Class DirectionExpression
  - DistanceExpression Up()
  - DistanceExpression Down()
  - DistanceExpression Left()
  - DistanceExpression Right()

Class DistanceExpression
  - DistanceExpression Taking(int time)
  - StartExpression To(int position)
  - StartExpression By(int distance)

Class StartExpression
  - StartExpression Using(IAlgorithm algorithm)
  - void Start()

The first class (Animation Expression) creates an instance of the Animator class, and then that is passed into the constructor of the other classes, after having a property set e.g.:

DistanceExpression Up {
    _animator.DirectionType = Animator.DirectionTypes.Up
    return new DistanceExpression(_animator)
}

So when you use the Fluent Interface, you end up with around 6 extra instances created rather than just 1 (the animator). This might not be much of an overhead as each class is fairly small, but if you are doing a lot of animations, it is going to add up (depending on how often the GC sees fit to destroy them).

Compare this fluent interface to the one created for parameter validation by Rick Brewster that uses Extension Methods so that he creates no extra instances unless there is an error detected.

I am not entirely sure how much of an impact this would have on a program, but its defiantly something worth remembering when writing fluent interfaces for your classes.

When I was at college studying Electronics and Computer Engineering, we used a piece of software called Proteus. This software took a long time to get used to due to its interesting key bindings and mouse usage.

To select a track in Ares (PCB Layout package) you Right Click on it. Hmm not too standard, but okay, I can live with that. Now what happens if you were to right click on that track again? That’s right it deletes it. Here is roughly my thought train while using it (just having deleted a track by accident):

Uh oh, I didn’t mean to do that. Ctrl+Z...nothing, Ctrl+Z...Ctrl+Z Ctrl+Z Ctrl+Z. Still nothing...Oh yeah, undo is U in this program...

It also broke convention on Saving (S), Loading (L), and Printing (P) amongst others. Admittedly these are kind of logical, but then again I could never remember whether R you Reload or Redo (I still can’t remember).

Whenever I needed to make a PCB at university, we used software called OrCad. This software is immensely powerful, and can do more things in simulation that I can possibly think of. However it uses standard key bindings. And even after several years of not using Proteus, you know what? I still tried to double right click to delete things, S to save et all.

When I needed to make a PCB and the lab was unavailable, I download the latest demo of Proteus, installed it on my laptop and fired it up. Straight away I notice it’s slightly different. Right click is still select, however a second right click now brings a context menu up. And a third right click deletes. Hmm. Ok I can cope with triple right clicking to delete. But the real change was the keyboard bindings, which had changed to standard windows style. Ctrl+S saved. Ctrl+O opened. It was amazing. It did however take me ages to de train my old habits. Sometimes I still hit U to undo.

The real revelation was that a company decided to change something that was obviously a specific decision, and make their product conform more to what is expected. This software was a bit of a pain to use, but simple once you got past the keyboard bindings. Now it is standard the difficulty users may have experienced has gone, making it a much better product overall.

Well done Labcenter! Now if only other vendors could be so thoughtful.

I have been a fan of CI (Continuous Integration) for a long time now, and ever since I started with CI I have been using CruiseControl.Net. CCNet is incredibly powerful; you can make to do practically anything, and writing plugins for it is a breeze.

However, I do find that the config files get rather messy. I have tried many things and the current best solution seems to be to have one 'master' config file with a set of includes to other files. While this splits it all out nicely I find my config files are all very similar especially for projects which I build in Debug mode and in Release mode. These configs are identical bar Build Location, and the /p:Configuration=Debug flag passed to MSBuild. I have been reading about Dynamic Parameters and I think I can solve the problems with that, however time is a little short at work, so that is defiantly on the back burner.

I have also been reading a lot of good things about Hudson which while being a Java aimed CI Server, can be used with MSBuild through Nant, or plugins to let you use MSBuild directly (a nice guide is at [redsolo's blog]). While I also have not had the time to have a proper play with it, I must say it does look very good.

It may still have messy configs (I don’t know yet, haven’t really looked), but as everything is done through a nice web interface rather than a CLI, who cares? I was very impressed with how quick it was to get running too: java -DHUDSON_HOME=data -jar hudson.war. It uncompressed itself, and got going straight away. No messing with installers. Very nice.

The only thing I dislike so far is the background picture in the web interface. So I deleted it. Other than that (very) minor niggle, I think I like Hudson a lot, and look forward to playing around with it in the future.