Thursday, 31 January 2008

A WTF in a parcel

A friend was cruising around for some info on how different courier companies allow people to track parcels, and came across this true gem of a statement on ParcelForce's website.

Links to this website

You may not create a link to any page of this website without Royal Mail's prior written consent. If you do create a link to a page of this website you do so at your own risk and the exclusions and limitations set out above will apply to your use of this website by linking to it.


WTF? Seriously - what does that mean, and what purpose can a statement like that possibly serve?

See it for yourself, just scroll down to the "Links to this website" and "Links from this website" sections. The genius that came up with this text ought to be congratulated.

Wednesday, 30 January 2008

Rather scathing about UML

Every used UML to model software you're building or will build? Ever tried to?

Personally my only brush with UML was at university where it was a set topic of study. I've not touched it since and I'll be careful about drawing too many conclusions from my limited exposure. I'll just say this: Visual modeling of software is difficult and any method or process is bound to have limitations and flaws. But that doesn't render this post about UML any less humorous.

Are you happy where you work?

Today I happened upon some interesting reading. There's a software company in New York called Fog Creek Software that has a very unique way of looking at employees, hiring processes, office layout and company structure.

I cannot say I condone everything I read on Fog Creek's site, but there were many things that certainly rang true. I've worked a couple of places where I felt that the pool of IT talent was going to waste either because upper management saw the programmers and other IT staff as "the people who know how to deal with the ones and zeros" or because there were really clear lines drawn (in the sand!) as to what's allowed and what's not in terms of technology, methodology, tools and software. These things are just crippling to creativity, and really limiting when it comes to building new skills within an IT team.

I really recommend reading what the owners of Fog Creek have to say. Read the About page, the bit about the Development Abstraction Layer, and the spiel on how to treat developers. The description of the office alone makes me want to move to New York.

It was actually the article about the Fog Creek office that made me so enthusiastic about what these guys have to say. Fog Creek really appears to invest heavily in their developers. Seriously. Some of the figures seem just crazy at first glance. Just take the $800 chair that everybody sits in. Or the $700 per-developer-per-month cost of the office. I'm sure most CFOs would cringe just at the thought. But the idea, Fog Creek's idea, is that this investment in people means highly motivated workers, better focus, higher productivity, higher quality - and the end result is of course better products that sell better than the competition's.

This just makes me think of jobs I've had in the past where software development is at the centre of what the business does, yet programmers and IT staff are sidelined in every way possible. Take for example the digital agency I worked for in Sydney that had an awesome building in a top location, with a huge bar with perfect views of that spectacular harbour. Yet when the company expanded, who were the ones that were pushed - literally - to the very back of the office to sit directly underneath the central air conditioning vents, where by 11am your fingers would be numb with cold? Or take a more recent job in London where the offices were also very flash and modern, yet the IT department was placed closest to the office entrance so that there was constant traffic of people coming and going. Hardly an ideal location for the hard thinkers of the company, the people who kept the "shop open" 24/7.

The difference between those companies and Fog Creek is pretty clear. Fog Creek understands its own business and who make it happen - and they invest in that, convinced that this investment in people is what will increase profits.

I'm a developer so it's no mystery that I like reading about a company that puts proigrammers in the spotlight. But it's the same for everybody - we want recognition that the job we do - our individual contribution - is important to the company we work for. So I encourage all of the CEOs, MDs, CTOs and CFOs out there to take a look at what Fog Creek does and try to apply some of the tips in their own companies. Of course, the CEOs, MDs, CTOs, and CFOs don't read my blog - so forward them the link to this post :-)

Sunday, 27 January 2008

Throw your own SqlException, part 2

Last year I wrote a very short post on a technique for creating and throwing a SqlException instance. The post links to a solution on another blog. Since I have been doing a bit of work using reflection lately I thought I should follow up on the original post and explain exactly what the problem is, how it's solved, and also include the full source code (in case the original post on the other blog is lost).

So, here we go. My original problem was that I needed to be able to throw an instance of SqlException with a specific error code. SqlException cannot be instantiated directly, however, because its constructor is marked as private. The only way to get around this is to use the very useful tools in the System.Reflection namespace and get at the private constructor via exploration of the metadata emitted by the System.Data assembly.

Before I go on, if you are not familiar with what reflection is I recommend that you first read about it here. Also, when working with reflection to discover and create types Lutz Roeder's Reflector is invaluable. Download it!

Now we're equipped for the task at hand. Using Reflector we'll first inspect the SqlException class to discover what's required to create an instance, and then we'll use the System.Reflection namespace to write a set of methods that allow us to create a SqlException instance with the required state. It really isn't difficult, but writing this kind of code (using System.Reflection) does not feel natural at first pass, so I'll go through it here step by step.

1. Inspect SqlException with Reflector.
Open Reflector and load the System.Data assembly. Expand the System.Data.dll node, and then the System.Data.SqlClient node. Scroll down until you find the SqlException node and expand this also. When you expand this node you'll find that the SqlException class has two constructors (both private), three methods (one public, one private, one internal), and several public properties.

One of the private constructors takes a string (an error message) and a SqlErrorCollection instance as parameters. This is the constructor we'll be working with. Using System.Reflection we'll create an instance of SqlException by passing in a string of our choosing, plus an instance of SqlException that we'll also create. But before we get carried away, let's have a look at the SqlErrorCollection class.

2. Inspect SqlErrorCollection with Reflector.
SqlErrorCollection is listed just above SqlException in the node list. Expand it and you'll find one internal constructor that takes no parameters (how useful for us!), one internal Add(SqlError) method (probably a bit more useful), three public methods, two public properties, and two inherited properties.

So, in order to create an instance of SqlErrorCollection for our SqlException constructor it seems we'll have to utilise System.Reflection a bit more. Now, an empty SqlErrorCollection is probably not going to be that useful to us either, so we'll have to create an instance of SqlError and add it to the collection using the Add(SqlError) method.

3. Inspect SqlError with Reflector.
SqlError is listed just above the SqlErrorCollection in the node list. When you expand it you'll see that it is quite simple, with an internal, seven-parameter constructor, and a single public method (overriding Object.ToString()).

Armed with this knowledge, the list of steps to complete our task is as follows:
  1. Create a SqlError with an appropriate error message and error code.

  2. Create a SqlErrorCollection and add the SqlError instance from step 1.

  3. Create a SqlException instance by passing in an error message and the SqlErrorCollection from step 2.

Almost there, but not quite. How exactly do we go about doing this? Before we carry on, it's time to have a look at the System.Reflection namespace. Put simply the System.Reflection namespace allows you to discover the internal structure of a type, invoke methods, properties or constructors, and even create types during runtime. All of this is accomplished through the use of special purpose classes, some of which we will use here (I'm not going to discuss System.Reflection more in-depth here as it really deserves a long post on its own).

Specifically we will be making use of the ConstructorInfo class (for calling constructors) and the MethodInfo class (for calling methods). Instances of these classes are returned by calling GetMethod() or GetConstructor(), respectively, on a type. For example, calling typeof(SqlErrorCollection).GetConstructor(...params...) returns an instance of ConstructorInfo that we can use to invoke the constructor. In fact, the parameters we pass to GetConstructor performs a search on the type (in this case SqlErrorCollection) and returns a ConstructorInfo instance that corresponds to the constructor found in the search. (If the constructor is not found, the ConstructorInfo instance returned is null.)

Let's a have a bit of a closer look. GetConstructor() has three overloads, but I will only look at the second overload here as it is exactly what we need. The method takes four parameters: BindingFlags, Binder, Type[], and ParameterModifier[]. The first parameter is a bitmap constructed of stringing together individual BindingFlags that we use to indicate what type of constructor we're after (e.g. a non-public constructor). The second parameter, Binder, allows us to pass in a special instance of a Binder class that can be used to select a specific overload etc. The third parameter is an array of Type, and this array specifies the types and number of the parameters in the constructor declaration. The fourth and last parameter is an array of ParameterModifier - each ParameterModifier in this array can be used to specify which parameters are to be passed by reference and so on.

We only need to worry about two of these parameters, namely the BindingFlags and the Type array. The two others we'll pass in as nulls and let the framework use the built in default behaviour.

GetMethod() is similar to GetConstructor() but has a string parameter that can be used to pass in the name of the method to find. If the method we're looking for has no overloads we only need to specify the BindingFlags for the method and we're done! Otherwise we can also pass in a Type array to specify which overload, exactly, we're after.

Now we're both armed with knowledge and equipped with some nifty tools to get the job done. Let's get started on our first task, creating a SqlError instance.

Creating the SqlError instance.
The constructor on SqlError takes seven parameters of different types. To search for this constructor using the GetConstructor() method we'll have to declare at Type array that defines these types in the correct order. Also, when it comes to actually invoking the constructor we'll need to pass in some actual parameters, and we'll have to declare these in an array of Object. Then we'll get a reference to the SqlError constructor by calling GetConstructor() on its type, and finally create an instance of SqlError by invoking the constructor with our parameters. Put together in a method it looks like this (there are some default parameters used here; you can replace these with something more dynamic if you like):

private static SqlError GetError(int errorCode, string message)
{
object[] parameters = new object[] { errorCode, (byte)0, (byte)10, "server", message, "procedure", 0 };
Type[] types = new Type[] { typeof(int), typeof(byte), typeof(byte), typeof(string), typeof(string), typeof(string), typeof(int) };
ConstructorInfo constructor = typeof(SqlError).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, types, null);
SqlError error = (SqlError)constructor.Invoke(parameters);

return error;
}

Creating the SqlErrorCollection instance.
This is a simpler task than creating a SqlError instance because the SqlErrorCollection constructor doesn't take any parameters. All we have to do is get a reference to the constructor and then invoke it. Later we'll invoke the Add() method to add the SqlError instance returned by the method we wrote in the previous step. A method to create a SqlErrorCollection instance looks like this:

private static SqlErrorCollection GetErrorCollection()
{
ConstructorInfo constructor = typeof(SqlErrorCollection).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, new Type[] { }, null);
SqlErrorCollection collection = (SqlErrorCollection)constructor.Invoke(new object[] { });
return collection;
}

Creating the SqlException instance.
This step basically does the same as what we've seen in the previous two steps, with the difference being that we invoke a method, and we use the instances of SqlError and SqlErrorCollection created by the two methods that we have already written. In short, we create an instance of SqlErrorCollection, an instance of SqlError, call GetMethod() on the SqlErrorCollection type to get a reference to the Add() method, then add the SqlError instance to the collection. Finally we wrap it all up by instantiating a SqlException by getting a reference to its constructor and passing in an error message along with the SqlErrorCollection. As a method it looks like this:

public static SqlException CreateSqlException(string errorMessage, int errorNumber)
{
SqlErrorCollection collection = GetErrorCollection();
SqlError error = GetError(errorNumber, errorMessage);

MethodInfo addMethod = collection.GetType().GetMethod("Add", BindingFlags.NonPublic | BindingFlags.Instance);
addMethod.Invoke(collection, new object[] { error });

Type[] types = new Type[] { typeof(string), typeof(SqlErrorCollection) };
object[] parameters = new object[] { errorMessage, collection };

ConstructorInfo constructor = typeof(SqlException).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, types, null);
SqlException exception = (SqlException)constructor.Invoke(parameters);
return exception;
}

And that's it. Putting it neatly together in a class, we've got ourselves a little SqlExceptionStub that is very handy for testing certain expected database exceptions. The complete code is below.

And that's that!


using System;
using System.Data.SqlClient;
using System.Reflection;

namespace SnowValley.Tools.Tests.Utility
{
public class SqlExceptionStub
{
public static SqlException CreateSqlException(string errorMessage, int errorNumber)
{
SqlErrorCollection collection = GetErrorCollection();
SqlError error = GetError(errorNumber, errorMessage);

MethodInfo addMethod = collection.GetType().GetMethod("Add", BindingFlags.NonPublic | BindingFlags.Instance);
addMethod.Invoke(collection, new object[] { error });

Type[] types = new Type[] { typeof(string), typeof(SqlErrorCollection) };
object[] parameters = new object[] { errorMessage, collection };

ConstructorInfo constructor = typeof(SqlException).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, types, null);
SqlException exception = (SqlException)constructor.Invoke(parameters);
return exception;
}

private static SqlError GetError(int errorCode, string message)
{
object[] parameters = new object[] { errorCode, (byte)0, (byte)10, "server", message, "procedure", 0 };
Type[] types = new Type[] { typeof(int), typeof(byte), typeof(byte), typeof(string), typeof(string), typeof(string), typeof(int) };
ConstructorInfo constructor = typeof(SqlError).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, types, null);
SqlError error = (SqlError)constructor.Invoke(parameters);

return error;
}

private static SqlErrorCollection GetErrorCollection()
{
ConstructorInfo constructor = typeof(SqlErrorCollection).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, new Type[] { }, null);
SqlErrorCollection collection = (SqlErrorCollection)constructor.Invoke(new object[] { });
return collection;
}

}
}

Saturday, 19 January 2008

Usability. 16 things to avoid.

Why do we write software? Aside from the obvious "we get paid to do so" and "I just love that caffeine-induced kick when it builds man!", we build software because other people need it.

It's an overstated fact, but everywhere you turn now there's software servicing people and helping people out. This is great! What still surprises me, though, is how badly designed much of it is. I'm not talking about software architecture, I'm talking about usability and interface design. Let's face it, some of what's out there is just shocking.

A colleague of mine sent me two links to articles (part 1 and part 2) about 16 things to avoid when designing the registration or sign-up process for a web site. It's a really good read and there are quite a few "oh-no-they-didn't!" moments.

Personally, when it comes to sign-up/registration I would want more retailers to allow people to shop without registering. Sure, I can understand that all that registration data makes for wonderful marketing information - but it's such a hassle to register when all you want from a retailer is a single product that you choose to purchase from that particular retailer solely because it's cheaper than at any other retailer.

Anyway, rant over. This year is about making better software and that doesn't just mean software that's faster, more maintainable, and well structured. It's about software that's usable to the people that matter: the customers and end-users.