January, 2010

Time for a change

Submitted by Bevan on Fri, 29 Jan 10 - 9:51pm

I hope you like the new look for the site - I thought it was time for a change.

If you spot anything untoward, please let me know!

A Boys Club?

Submitted by Bevan on Thu, 28 Jan 10 - 8:00am

You don't have to go very far to see the extent to which women are underrepresented in the IT industry - especially as software developers. Recently, I've started to ponder the reasons why - and, to quote Walt Kelly: We have met the enemy, and he is us

Sometimes, the answer is simple

Submitted by Bevan on Mon, 25 Jan 10 - 2:18pm

Saw something interesting at church the other morning, as the speaker was preparing her message.

A set of PowerPoint slides, for display alongside the message itself had been saved on a USB key, and needed to be loaded on to the A/V computer used during the service. However, when the key was inserted, it didn't appear under My Computer, making it kinda difficult to access the files.

The immediate response of the person driving the computer was to dive into the control panel, clicking things at random, looking for something wrong.

Improving on POCO Associations

Submitted by Bevan on Thu, 21 Jan 10 - 8:00am

Building on our past discussion (see Improving on POCO Properties and Improving on POCO Collections), let us look at how we can improve the implementation of associations between our domain objects.

In a standard POCO domain model, associations are handled as simple object references, or as lists of object references:

class Customer
{
    Person PerformedBy;
    IList<Orders> PlacesOrders;
}

Dude, you're working too hard

Submitted by Bevan on Wed, 20 Jan 10 - 10:50am

Sometimes I look at a piece of code and find it hard not to sigh, especially when the developer has done something the hard way.

Take this piece of code, for example:

var key = EntityKeyFactory.CreateKey<ITsClassKey>(
    new object[]
    {
        aItemRequest.ItemName,
        aItemRequest.SystemName
    });

For reference, here's the declaration of the CreateKey function:

public static T CreateKey<T>(params object[] aKeyValues)

Do you see the problem?

CI, Builds and NAnt

Submitted by Bevan on Fri, 15 Jan 10 - 4:57pm

The ISerializable blog post "The difference between continuous Integration tools and automated build tools" has a good breakdown of the difference - one does the build, the other triggers the build.

At the moment, I'm using TeamCity and NAnt for my builds.

Range Properties

Submitted by Bevan on Thu, 14 Jan 10 - 8:34pm

A common need in domain modelling is to specify a range - of dates, of prices, or some other numeric measure. Typically, we model this with a pair of properties, as in this example:

class MarketingCampaign
{
    DateTime? EffectiveFrom;
    DateTime? EffectiveUntil;
}

Improving on POCO Collections

Submitted by Bevan on Fri, 8 Jan 10 - 5:13pm

In my previous blog entry, Improving on POCO Properties, we looked at the benefits we can reap for our domain objects if we represent properties with dedicated helper objects instead of restricting ourselves to the usual C# syntax.

As you may have guessed by now, there are improvements that can be made in other areas as well. In this post, the focus will be on composite objects.

Improving on POCO Properties

Submitted by Bevan on Fri, 1 Jan 10 - 6:11pm

Plain Old CLR Objects (POCOs), along with their close cousins POJOs (Plain Old JVM Objects) are often held up as the ideal for use when modelling our problem domains.

The arguments in favour of using POCOs are compelling - including independence from any particular object relational mapper (ORM), avoidance of the need to implement a specific interface or to have a certain ancestor object. In fact, the arguments are so compelling that large sectors of the development community take it as a matter of faith that there is no better way.