Strongly-typed ints

Weird title, no? I couldn’t think of a snappier one, I’m afraid.

I’ve been thinking of a way to ensure that this sort of subtle bug/typo doesn’t happen:

public void MyMethod(int useCaseId)
    // Do something with the useCaseId

public void SomeOtherMethod()
    int userId = 12;
    int useCaseId = 15;
    MyMethod(userId); // Ooops! Used the wrong value!

This bug would be hard to find because there’s no compile-time error, and you wouldn’t necessarily even get an exception at run-time. You’d just get "unexpected results".

To resolve this in a simple way, I’ve experimented with using empty enum definitions. Effectively making a user id a data type (without going quite as far as a class or a struct):

public enum UseCaseId { // Empty… }
public enum UserId { // Empty… }

public void MyMethod(UseCaseId useCaseId)
   // Do something with the useCaseId

public void SomeOtherMethod()
   UserId userId = (UserId)12;
   UseCaseId useCaseId = (UseCaseId)15;
   MyMethod(userId); // Compile error!!

What d’you think?

Tip for debugging console applications in C#

Sometimes in a C# console application, you want to output text to the console window for release builds, meaning Debug.WriteLine() is out of the question.  Maybe you also want the output in some sort of log file?  It would also be handy to be able to indent the output to make it clearer what your application is doing.  This makes simple Console.WriteLine() impractical, too.

If it’s an enterprise application you’d probably look at Log4Net or similar, but if it’s just a little something you’ve knocked up, then that might be overkill so try this at the start of your application:

Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));

The documentation for Trace and Debug gives more detail, but the great thing with this approach is you can now format your logging output in a more clear way:

Trace.WriteLine("Starting loop...");
foreach (string name in names)
Trace.WriteLine("Completed loop");

Like I said, I’m not proposing it as best practice for large-scale production systems, but for those occasions when you need to see into your application without debugging it, it might prove useful.

Too Hard == Broken?

I’ve spent a few hours over the last couple of days trying to get NHibernate to work. I failed. As soon as I call Configuration.Configure() I get an exception. I’ve tried various combinations of app.config and hibernate.cfg.xml files etc to no avail. I give up.

And this isn’t the first time I’ve had this. I’ve started to think, that if I can’t get something to work, its effectively a fault. A bug, no less. I’ve blogged about the risk of learning a new framework, and this proves my point perfectly.

I’ve taken to giving up on things like this.  I have better things to do with my time than work through problem after problem after problem trying to get something working.  I even recently uninstalled Resharper, because while it was very good, it stopped my solutions opening quickly. Sometimes entirely.  Again, broken.

So I’m going to look for an alternative to NHibernate that I can get running, and therefore “works”. It’s official – NHibernate is broken.

Unless you can help me out…

FogBUGZ 6.0 Case Web

In addition to my previous thoughts on the truly excellent FogBUGZ, what I’ve just realised I’d love to see is some kind of graphical display, showing me cases that are linked together.

The phrase “Case Web” springs to mind, but essentially it’s a spider diagram that would allow zooming, dragging, etc. Look at and you’ll see what I mean.

I’m thinking literally small boxes with the case number in (hover over and you get the mini-preview like in the single case view) with lines joining them together. I might try and knock up a desktop app as a prototype to see how it looks.

Also, I’d really like to see the concept of packages of work in FogBUGZ. A release may contain a number of cases, but a group of those cases might be the “new editing screens” cases, and the only way I can find to link them together is to add “case xxx, case yyy” etc to every case in the group, which is unmanageable when you want to add a new case to that package of work. Am I missing something?

Is one in the hand worth two in the bush?

Here’s the scenario:

You’re working on some software. You need to add some new functionality to it, and in looking through existing stuff you see the methodology in place. You don’t think it’s the best way to do it (or maybe it’s objectively incorrect for some reason), so what do you do?

a) Spend a lot of time re-working the existing stuff into a “better” way of doing it, then quickly add in your new stuff now that the framework is in place.

b) Write in the new methodology and supporting classes etc, then add your new stuff in and comment the old stuff with // @TODO: Update to new methodology.

c) Just write your new stuff in the old “incorrect” or less preferable way, sigh, and get on with the next task.

Answers on a virtual postcard please.

Personally I’ve done all three of these, with no particular favourite. That might be the answer in fact, that different situations and time pressures require you to take the easy option. I know that re-working existing code into a nice framework will provide a good footing for my new functionality, but it’s at the risk of changing or breaking existing functionality that shouldn’t have been affected.

This probably doesn’t just apply to software development, either. This year I’ve been renovating our kitchen. At one point we had the decision on whether to take the old water-damaged ceiling down or not. My options were:

a) Rip the old ceiling down, re-do all wiring in the kitchen (lights and power), put new plasterboard up, new fittings, have it plastered and paint it.

b) Put new plasterboard up over the top of the existing ceiling, have it plastered, paint it. Thus keeping the old lighting locations and meaning I couldn’t redo the electrics or put outside lights in.

c) Paint the old ceiling and get on with my life.

I went for a). Turns out that was the right thing to do, because now we have outside lights, new spotlights replace the old striplight, and we have loads more plug sockets (removing some dodgy wiring in the process), but I didn’t know that before I started.

Have I just answered my own question?

The Evil of Implicitness

I really dislike things that are implicit. Okay, it doesn’t help that I’m the most forgetful person I know, but still.

I’m a believer that if you want something done, you should do it. Use a framework if you like as a tool, but explicitly ask that tool to perform the task. Things shouldn’t be hidden away, doing as they please.


Post build steps
I’ve mentioned it before, but I really do like my build process to explicitly do everything I need, in one place.

My boss gave me a tip yesterday. He says that for things like this:

insert into a_table (id, the_value) values (1, 11)

He sometimes cheats and does this:

insert into a_table select 1, 11

I think that’s dead clever (because I thought you had to specify the columns you want to insert into), although I’d personally never run it on a production database, and it would only be for quick and dirty test code on a database I control. The problem is (and to be fair he admitted this), if someone changes the schema of that table, things can get messy very quickly. I’m more anal so my first thought was that I just like to know what columns I’m editing without having to investigate that table schema before I run it.

Of course we all know the evils of:

select * from a_table_that_might_have_columns_added

Which speaks for itself, so let’s not dwell on that.

Attack of the Scheduled Job
I personally dislike any kind of scheduled task. It makes me nervous to think that there’s an unknown cloud of processes that I don’t know about that might be editing my data without me knowing.  Also, you lose a bit of the “realtimeness” of information with scheduled jobs. Of course sometimes this is necessary, as in the case of maintenance tasks.

So I like to do things by hand a lot of the time. I don’t like to write classes that do work in constructors, I prefer instead to use factory methods or create static methods called “Load” which create the object and populate it for me. Right or wrong is tough to decide, and is probably a religious issue as much as anything else. But “better safe than sorry” and “keep it simple, stupid” are principles that make applications easier to maintain, because you avoid more issues from happening, and make it easier to find and fix those that do appear.

Where to get good eye-candy?

I’m working on a new project, which is a web app for appointment booking. I want some slick icons and images to go in it, to give it a web-page feel, rather than the drab look it has now.

Thing is, while I can take photos and use Photoshop to spice them up, fade them, give them reflections and so on, icons are actually really hard. I’ve found a Photoshop tutorial that looks really good, but this isn’t my strongest area, and since it’s a spare-time project for a friend I might consider buying something.

I also saw the Crystal Clear icon set at Wikimedia Commons. It’s exactly the kind of thing I’m looking for, but doesn’t have some of the more specialist things I’m looking for. Maybe I need to employ the services of a freelance graphic designer for this, but I’m not sure that’s going to give me good value for money, as I won’t need hundreds.

Maybe I should just learn to do it myself?

Left and Right, or backwards and forwards?

Wizards. For better or worse, they are here to stay. You can name them something else (enter “Guidance Packages” stage right) but they’re a staple of modern applications. Personally I’m in two minds about them.

They guide you through an unfamiliar process, often skipping the finer details completely.

The guide you through processes you already know well, skipping finer details you want to change.

Wizards need strong guidelines if they are to be useful, but they’re not always adhered to. The truth is, good wizards are hard to design.

I was looking at the other day, and when I saw the homepage, I felt like I was in the middle of a wizard. Why? Because they had two links at the bottom of the page, one pointing left, the other pointing to the right.

However, on closer inspection (read: opening my eyes and turning my brain on) I realised that both links take you forwards. This has got me thinking. What if you designed software that would navigate you through it’s processes one decision at a time? Of course, the RPG world has had this for some time, but in business and home software terms it’s not something I’ve come across.

Now many systems might find it hard to keep each “screen” to 2 choices – left and right, but some sort of multiple choice (must be lean on the choices though) would still work.  Of course it has to be graphical so you feel like you’re actually moving around in the software, and maybe a breadcrumb trail would be helpful to review the choices you’ve made.

Has anyone worked on anything like this already?

The Right Answer

While on the subject of frameworks, think about this. I used to work in Java, and found that my choice of frameworks and technologies was staggering. I had EJBs, Hibernate, Spring you name it, I could use it.

But this I actually found quite daunting. How am I supposed to choose between them? When I made the move to .NET, I found that actually, the Micro$oft monopoly helped me out a bit. Suddenly there was an objective statement: “This is how we expect you to develop software using our tools”. These methodologies were built right into the IDE, ready and waiting.

With The Antitrust Case, building IE into Windows was a good move and a bad one for Microsoft. It got them mass exposure, and IE became the default web browser for the masses. They built their own tools right into the OS, thus making the OS more functionally rich out of the box. This meant that the average new computer user would never have to look past the end of their nose for most things. It was only when the competition realised how difficult it was to get people to make the switch that this began to change.

So with that in mind, surely we should be thinking that the prescription approach is a bad one – after all, it’s hard to argue that NHibernate doesn’t beat the built-in DataSet designer hands-down, but in terms of the all important usability stakes, the DataSet designer takes the chequered flag.

So, another case of wrong is better? It certainly buys time to work out your version 2 with the fancy NHibernate database-independant data access layer, but to get your version 1.0… Well, let me know what you think.