Assuming you’re actually bothered by the non-arrival of your desired improvement, it’s very important that you set a cut-off date for it to occur by. Not only that, you also should define what action you’re going to take when that date arrives; typically, that’d be “leave”.

Without a cut-off you can meander on, days turning to weeks, weeks to months, and months to years. Before you know it years have passed without any actual changes having occurred, only the constant dangling carrot of hope.

I’m not advocating that everyone quit their job just because they don’t get to do everything they want. This is about when you’ve done everything in your power to improve things, to instigate change, and when that still has no effect.

You have to know when something has become a lost cause, and when it’s time to move on.

Symptom 1:
Very poor performance. I’m talking 10+ seconds per page load, with no more than 5 queries being executed by NHibernate.

Symptom 2:
Empty log files. None of our log files had any data in on the live server, but they did on our other systems.

I decided to investigate the second symptom first, as it may be causing the first (ends up it was).

Firstly, I noticed that our logging was set to DEBUG. Must’ve been a leftover from when we first deployed NHibernate, very sloppy, I know. So I reset that to WARN, but it had no effect.

When files aren’t being written to, you should always check the directory permissions. Low and behold, it was a permissions problem. Our test server had different users allowed to write to the Logs directory than our production server. I granted the same users access, NETWORK SERVICE and IUSR_MACHINENAME in our case.

After I recycled the IIS worker processes, we were flying again. We’re back to having < 1sec page loads.

This is pure speculation, but what I believe was happening is this: Logging was set to DEBUG, so it was logging a lot. With each log call, the logger was failing to get write access to the files and throwing an exception, that exception would probably have propagated a bit too. The combination of the sheer amount of data being written to the log, and an exception per log call, were responsible for the severe slowdown.

So in short: Always make sure NHibernate has write access to its own log directory!

This is my account of how I freed the model from the web-service.

public class vehicle_info
{
    public int vehicle_id;
    public string vehicle_name;
    public string vehicle_manufacturer;
    public DateTime vehicle_manufactured_date;
    public int vehicle_number_produced;
}

That’s the existing model. You can see that these have some nasty naming conventions that I just can’t live with anymore.

A large problem with pushing your model out to the web-service consumers is that I can’t refactor the classes without breaking their implementations; if I rename a field in my model, the consumers will have to update their code to deal with it. This is an issue because not all the consumers are able to update their code. So we’re stuck with how the classes were built years ago, with awful naming conventions, and no ability to change.

What’s the ideal setup then? It’s my opinion that we should be using specialised DTOs (Data Transfer Objects) for this purpose, they’ll exist solely to be the transport mechanism for the web-service. With DTOs you’re separating what your service pushes out from what you use internally, which allows you to refactor your internal design without any problems with integration.

public class VehicleWebServiceDto
{
    public int vehicle_id;
    public string vehicle_name;
    public string vehicle_manufacturer;
    public DateTime vehicle_manufactured_date;
    public int vehicle_number_produced;
}

There’s an issue with using DTOs in an existing web-service environment, it’s unlikely your DTOs will be named the same as your original objects (if they do, you’re fine). We can’t just swap it out with a DTO, because the signatures won’t match in the WSDL.

When we change the web-service to return those DTOs instead of the original classes, we end up with this mismatch in the output:

<vehicle_info>
  <vehicle_id>int</vehicle_id>
  <vehicle_name>string</vehicle_name>
	...

<VehicleWebServiceDto>
  <vehicle_id>int</vehicle_id>
  <vehicle_name>string</vehicle_name>
	...

How can we get around this? Make the signatures match.

You can control the way objects are serialized by the web-service through the serialization attributes; namely the XmlRoot and SoapType attributes are the ones you’re looking for, these allow you to override what name is output in the xml for your class. Slap on those attributes, one for the standard HTTP usage and the other for SOAP, and give them your old class name; then as far as the consumers of the webservice can see, you’re giving them the same old classes. Now you have a separate DTO from your domain layer, but without breaking the schema.

These are the updated DTO objects:

[XmlRoot("vehicle_info"), SoapType("vehicle_info")]
public class VehicleWebServiceDto
{
    public int vehicle_id;
    public string vehicle_name;
    public string vehicle_manufacturer;
    public DateTime vehicle_manufactured_date;
    public int vehicle_number_produced;
}

Which now produce this xml:

<vehicle_info>
  <vehicle_id>int</vehicle_id>
  <vehicle_name>string</vehicle_name>
	...

We are now free to refactor our code as much as we like, without affecting the output of the web-service.

public class Vehicle
{
    public int ID { get; set; }
    public string Name { get; set; }
    public ManufacturingDetails ManufacturingDetails { get; set; }
}

public class ManufacturingDetails
{
    public Manufacturer Manufacturer { get; set; }
    public DateTime ManufacturedDate { get; set; }
    public int NumberProduced { get; set; }
}

public class Manufacturer
{
    public int ID { get; set; }
    public string Name { get; set; }
}

Magic.

If you’re presented by a form, which asks for your friends name, e-mail address and some form of comment from yourself, what would you put in the name field? Common sense says that you should put their full name in, as generally that’s what people want; not these people though! Over 50% of the recommendations were supplied with first names only or nicknames – the most wonderful being “MUM”; yes, block capitals too.

So we have a nice collection of recommendations along the lines of:

1. George
2. Sally
3. Geoff
4. liz
5. MUM

How very helpful.

They’ll love the targeted e-mails they’re bound to receive too; “Dear MUM, we think…”.

The reason we had to work the weekend was down to us launching (re-launching actually) a product for the Swift Group’s extranet, something that a lot of people had been rather worried about. Mainly because, apparently, the previous time this product was launched it corrupted important data for six months without anyone noticing. Wonderful.

Something I wasn’t too happy about when I first inherited this project is that it was my sole responsibility. Slowly I came around to the idea though, it would be all my fault if everything went wrong, true, but it’d also be all down to me if everything went well; looks pretty good being responsible for a whole project only 10 months into a job.

Anyway, this is now day 1 of the launch at an end and a few niggling things aside, everything went swimmingly. No show stopping bugs at all, only minor things that took barely more than a minute to fix. I can safely say I’m in the good books.

Here’s to day 2 going as well as day 1.

The big problem with it was that it replaces the Request.ApplicationPath in any requested path with a blank string to remove any unnecessary parts of the path; “SwiftLeisure2006/Caravans/Abbey” became “Caravans/Abbey”. This worked fine on our local setup but we didn’t account for possible changes in the Request.ApplicationPath when the site is situated directly in the root instead of a sub-folder. The Request.ApplicationPath became just “/” which means “/Caravans/Abbey” became “CaravansAbbey” instead of “Caravans/Abbey”. Simple fix once we figured this out and found any similar sections throughout our controls.

Live and learn, live and learn.

I worked for quite some time trying to create a Logging system that would cater for my needs, and I got quite close to doing that. I created a small go-between object for the Trace and Debug logging and wrote that to my own XML file. The idea behind it, of course, was to make it easier for my self in debugging problems, if I could supply my self with all the data that I know I would require to trace an issue then, in theory, I could correct it much more quickly. This took me quite some time to create and of course was not perfect.

There were a few major (a.k.a. Huge) issues with my system, firstly the logger would only interact with your code wherever you explicitly told it to. Basically you had to write extra code wherever you wanted to log an exception. This was neither friendly nor desirable. The next issue was access rights for the XML files; this reared its head in a few shapes and forms. One of the instances didn’t occur very often but was a pain when it did; the writer was rejected write access due to another instance of itself actually writing to the file. I remedied this by making the writer wait until the other was done; this of course had performance implications though, having to stop everything within a page while the log writer sits idle. The other time it was an issue was whenever I wanted to archive the logs I had to wait until no other instances were accessing it, this also involved waiting but it takes longer to rename a file and create a new one than it does to simply amend a file.

The problem of having to explicitly declare any usage of the writer was the deciding factor in me binning my writer. Sad as it is to see something that I spent a fair amount of time creating deleted, it’s always slightly reassuring when you’re moving onto a product that is fully tested and working and also includes all source code! More on that soon though…

As you’d probably expect, I’m not really supposed to talk about what I do for security reasons of course. It’s mostly working for the Swift group (caravans, motorhomes) doing their internal systems and web sites. Other things as well, but it’s mainly that. It’s all very interesting, a big change from serving customers in a supermarket thats for sure. It’s a really strange feeling actually going to work and learning something, I generally come home every night having picked something new up.

Since I started the job I’ve learnt that my coding abilities are much better than I thought they were, having being subjected to the woes that are legacy code. Definetly a nice feeling, it’s always rather hard to rate your abilities when you have nothing to compare them against. For better or for worse I’ve been developing in VB.Net, something I tried to stay away from when coding for my self but haven’t been able to avoid recently. Not my cup of tea really but it’s another addition to the CV. Speaking of legacy code, there’s been some serious Daily WTF material lying around. A prime example was this beauty:

Sub Function GetTime(ByVal hours, ByVal minutes)
    Dim hours
    Dim minutes
    Dim yHours

    yHours = hours * minutes

    GetTime = (yHours / minutes) + (hours * minutes)
End Sub

Really interesting! Note the lack of any variable type declarations as well! It hasn’t all been like this, but there certainly a lot of amusing things.

One resource I’ve found invaluable since starting to code professionally is Scott Hanselman’s utilities list, there are so many handy little tools there that I can’t believe I’ve managed to live without! Some perfect examples are Lutz’s Reflector and Jeff Key’s Screen Ruler. A tool for “reverse engineering” compiled .Net assemblys and a floatable screen ruler respectivly.

Hopefully I’ll be getting back into this properly soon, until then, have fun.

I’m now a ‘New Media Developer’, nicer than ‘Checkout Assistant’ if I do say so my self. It’s very strange to be in a real job, doing something that I actually want to do (and like doing). This is going to take some getting used to…