TortoiseSVN tip for “blaming” on historical versions

I found this today, and I’m sure the last to realise, but it is helpful.

Most people already know about TortoiseSVN’s blame feature, which gives you a view of the code, with the revision/author against each line:

Example (taken from the TSVN Blame page linked above):

However, what you might not have known, is that you can right-click in the Revision/Author area for a given line of code, and select Blame Previous Revision.

This will open another TSVN Blame window, with the selected revision’s changes.  You can keep doing this, going back in time to see a picture of the updates that have been layered on a code file.

Of course, this could get a little unwieldy, but if you’re only checking the last few commits, it could prove useful.

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?

Shadow copies? More like “phantom” copies…

I’ve just run into a strange issue.  It’s the end of the day so I’ll leave it for tomorrow to work it out.

I have some code that is reading a config file, but when I open the file in TextPad, I see different values than my application does.  I checked it with Notepad.  Notepad agrees with my application, TextPad shows something else.

So I’ll tackle this in the morning, but it is pretty weird.  I think it might be a shadow copy issue (I’m running Vista).

Interesting times.

My Opinions on “Test Driven Development: By Example” by Kent Beck

I’m trying to get into TDD, and to this end I’m halfway through reading this book: http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

I’m not sure I agree with *all* the principles in it though.

Beck proposes a roughly three-step method:

1. Write a test.
2. Write whatever it takes in the least amount of time to get the stuff to compile and run successfully (a.k.a “get to a green bar as quickly as possible”).  This apparently can include hard-coding values (gulp).
3. Refactor to fix up your deliberately dodgy code “remove duplication”.

I understand the concept of test-first, but as a singularly scatterbrained individual, I can’t bring myself to go with “fake it ’till you make it” and “speed is more important than correct code (but only for a short while)”.  How will I remember/find those horrible bits of hard-coded code and ensure I’ve made them correct?  I think the trick to this (though it’s not said in as many words) is to write more tests that test the code from different angles until you get tests that fail with those hard-coded values, and fix them.  As a beginner of TDD, I don’t think I can be sure I’d do this effectively.  Essentially it is suggested that I write bugs into my code deliberately.  Eeeek!

What’s the point of a successfully run unit test if you know it’s testing broken code?  If you write any old code that will get the test working, you’ve totally negated the reason for the test in the first place.

Unit Test + Correct Code should equal Green Bar

Unit Test + Incorrect Code should equal Red Bar

not

Unit Test + Broken Code = Green Bar

I want tests that fail unless the code is correct.  While this isn’t always easy, I can’t bring myself to deliberately write incorrect code just to get a sucessful test.  If I have a green bar, what’s left to tell me what I need to do next?  As I said, apparently you just write more tests.

I prefer a different method:

1. Write a test.
2. Write the code that makes the test work.
3. Refactor if I change my mind about that code, safe in the knowledge that as long as the test passes, the code is okay.

To his credit, Beck does suggest in his book that the whole idea is that you gradually learn how big your changes in-between running tests should be.  That it is a learning process.  When you know what you need to make a given test pass, you are allowed to write that “Obvious Implementation”.

I’m basically not sure I like the recommendation that the process be quite so iterative.  If you have to run your tests after each tiny change, you’re effectively introducing a compilation tax which will quickly get frustrating.

I’d love you hear how you’ve interpreted Beck’s advice for your own TDD process.  I’m sure I’m just missing the point, so enlightenment is always welcome :).

My Ego is Bigger than your Ego

There’s no doubt that ego plays a part in software development.  We’re all in competition with each other.  Not just for work, but in terms of “geek points”.  I am unashamedly egotistical when it comes to software development.  I love to point out how clever I am and tell people about this crappy wonderful little class I just wrote, or how I found a bug in so-and-so’s code that made a really big issue go away.  I can say this safe in the knowledge that I probably cause as many problems as I fix.  I know that never a day goes by when one of my colleagues in either this or a past life comes across some code I wrote and sighs quietly to themselves before taking a sip of a caffeine-infused drink and “refactoring” it.

Much as I’d like to be, I’m not the world’s greatest software developer.

I am, however, a geek.  This is where the competition and virtual chest thumping really comes from.

There are loads of ways to earn geek points.  Having a blog is one way but a bit obvious.  Better is to use Twitter or FriendFeed.  How about an account on StackOverflow.com?  You might have an iPhone* or contribute to an open source project.  Hell, you might even have a “There’s no place like 127.0.0.1” t-shirt in a different colour for each day of the week.  You should also use the word grok a lot.

An ego in software development, like competition in any other area, is a good and healthy thing.  It’s what drives us to create something better, cooler, faster, more reliable than our peers.  Developers love nothing more than to write software for developers.  I believe this is both because we are writing it for ourselves, but also because we know that other developers are the only people who will really grok (+1 point) what we’ve done, and appreciate what it took to get there.  Other developers are the ones that will spot the bits where the mouse pointer didn’t turn to a wait cursor.  They’ll notice if your app becomes unresponsive and suggest clever things like multithreading and BackgroundWorkers.  You respond by saying “yeah, this is just the first version – that’s all part of the plan”.  We want our peers to say things like “Dude, that is so cool”.

This attitude isn’t necessarily what our employers are looking for, however.  There are those out there that can afford to let developers experiment, of course (Google is probably the best known for this), but most companies need to earn money.  They’re not interested in your implementation of Castle Windsor or ASP.NET MVC, and will struggle to be sympathetic with your reasoning.  “Because it’s so cool” doesn’t cut it.

Also, when you have multiple egos in a team, it can be mildly unproductive.  Software developers are intelligent people for the most part but that in itself can be the problem.  Put some together in a room and most will have their own variation on the solution.  At some point someone needs to step up and say “Okay, that’s all great stuff, and we’re going to do it like this…”.  Bear in mind that this doesn’t have to be the right solution.  Software and opinions can be changed.  You just need an agreed spokesperson or lead to make the decision so you can break the tie and each get back on with developing.  Of course, secretly knowing you had the best idea all along…

* And for bonus points you should have a 2G *and* a 3G version.

I want on the netbook bandwagon!

I really want a netbook.  I think I first heard about them on Dave Winer’s site, scripting.com, but dismissed them at first.  However, having seen them “in the flesh” in the shops, I’ve totally fallen in love.  They perfectly fill the gap between what I can accomplish on my phone (I don’t have a fancy smartphone) and what I need to be in front of a PC for. 

1. Great battery life.  I’ve heard of getting over 5 hours on one charge.  That’s great!  I don’t know if those figures are for HDD/SSD and whether they include wi-fi usage, but they’re still impressive.
2. Size and weight.  These things are seriously small.  I’m a fully-paid up member of the man-bag club.  I tend to have my rucksack with me most of the time because I carry a camera, moleskine and diary most places.  A netbook would fit perfectly in a man-bag (or handbag, of course), just waiting for those visits to the local Starbucks for a coffee and a bit of blogging.
3. Usable keyboard.  Phone keyboards are crap.  Palm top keyboards are crap.  I’ve not used it but the lack of tactile feedback means the laser projection keyboard is probably crap, too.  There just aren’t any solutions for mobile keyboards, but while the netbooks are small, they seem to have usable keyboards.  You’re not going to get the same words-per-minute rate as on a full-size keyboard, but it won’t be too bad once you’ve had a practice.
4. Wi-fi.  How cool to go shopping, see stuff you like, and go online to check the prices on Amazon?  Check your email while you drink your coffee, Sir?
5. Fast boot time.  I don’t know how this is achieved.  Even if they’re cheating and using some sort of hibernate functionality I don’t care.  These things need to go on and off really, really quickly.  You want to sit down, take it out, open it, use it, shut the lid and put it away again.  You want 95% of that time to be using it, not waiting for it to boot.  It needs to be as close to opening/closing a browser on your PC as possible.
6. Price.  Cheap, cheap, cheap.  Well, reasonable.  For “cheap” you can get a netbook, but don’t expect XP, SSD or a big screen (for small values of big).  For around £300 you can get a decent spec device.  To be fair, the Linux-based ones look okay.  They seem to come with OpenOffice and FireFox.  I only want more because I’m a Windows guy and software developer.  I will want to see what I can get it to do for me.

So, I’m saving up for one.  It’s my birthday in March so I’ll be saving any pennies I get towards a netbook.  I just hope it’s not a case of “never meet your heroes”…

GTD – Outliners for thoughts

I think in trees.  I relate almost everything in one way or another in terms of some sort of hierarchy.  Trees and hierarchies feel elegant to me, and it shows in the way I make notes.  It’s really a more orderly way of displaying a mind-map.

I’ve always made my notes in a standard A4 notebook.  Meeting notes for me look something like this:

Outline Notes

The trouble is written notes is that they aren’t typically very editable.

It occurred to me that computers are pretty good at this sort of thing, so I looked for a software outliner.  I tried a few desktop software options including Dave Winer’s opml Editor, and the supremely awful free version of NoteCase. but quickly decided that the web was the way to go.

I’ve used Evernote, but it was actually too complex for my needs.  It focusses on each note being like a rich text document.  I want the tree structure to *be* the notes, just like in my A4 book.  It does have tagging though which would be nice in the future when I have many notes.

I’ve tried various mind-mapping options, but the outliner tree style is much easier for me than a sprawling spiders web with the ideas on.  They’re really the same thing, just laid out differently.

Todoist was good, and one of my final two choices.  They have the indenting support, but in the end it was keyboard navigation that let it down.  You *can* move things around with the keyboard, but it wasn’t quite as slick as my final choice: Checkvist.

Despite a few teethinc troubles (a friend of mine lost a document because of a bug) it is very, *very* fast to add, edit and manouvre items around the tree.  The keyboard support is excellent, and there are very few actual features to bog it down.  It’s a simple, clean interface that feels and works like an editable notepad.  I might actually break my habit of “no laptops in meetings” to take electronic meeting notes…

Nobody builds bridges any more!

Once upon a time we had this thing we call the Industrial Revolution.  We did amazing things during this time.  We built steam engines, railways, bridges and canals.  These were massive projects that took years of blood, sweat and tears.  In the 20th century we had what some call the second industrial revolution.  The automotive industry appeared and began to thrive, information technology appeared and began to grow.

Watt Steam Engine

That was the revolution.  Since then there’s been some evolution of those existing ideas, but relatively few new genuinely ones.

No-one is building those fantastic railways and the amazing bridges that took them over seemingly impassable territory.

Why?

It could be funding, but where did the money come from in the old days?  Do we no longer have men like Brunel who will put everything on the line and strive to make these things happen?

Have we had the next revolution already?  If so what will the next iteration look like?  Will we even have one?  Are we instead going to maintain the current gentle evolution from one new idea to the next.  Assembly, C, C++, Java, .NET, JSP, ASP.NET, (N)Hibernate, ASP.NET MVC, jQuery and so on.   Building blocks built on building blocks.  Walls taken down, put up a different way.  An organic system where the latest trends flow and follow the current thinking the way a shoal of fish move together in the sea.

Computers as we know them appeared first with valves, then transistors, and progressed to microchips.  Then the microchips started getting smaller and faster.  But still microchips.  Now, I’m only 27, but I’m not convinced that computers have really fundamentally changed in the past 20 years or so.

In terms of software, the main operating systems as we know them today, and the companies that built them, were the last revolution.  We as software developers are really just building new trains to run on that old railway.  There’ll come a limit to what we can do, so while that’s a little way off, what’s the next “big leap” to take us onto greater things?  Let’s build a new railway that’ll cross new cravasses and take us new places.  Who’s the Brunel of our time?

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...");
Trace.Indent();
foreach (string name in names)
{
	Trace.WriteLine(name);
}
Trace.Unindent();
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.

Undo, UNDO!

There is little more frustrating when using a computer than message boxes.  Technical people ignore them because we think we know they don’t mean anything, and non-technical people just use a rule of thumb (always yes or always cancel).  No-one ever reads the small print.

There’s not much point asking users if they’re sure before letting them do something. They will be absolutely positively sure.  Until shortly after they’ve actually done it.  Instead, we should accept that users make mistakes.  Rather than blame them for blindly clicking OK on our message boxes, we should embrace the human condition and strive to try and provide rollback with *all* functions in our applications.

Instead of

“Are you sure you want to book 3000 items of stock in?”

try

“3000 items of stock booked in.” and offer CTRL+Z to simply remove those 3000 items again instantly.

This is a hard thing to get people to come round to.  It’s so ingrained to rely on confirmation *before* the action.  Maybe we should be more forgiving and provide a means to recover from their mistakes, rather than having them hit our call centre in a panic when something goes wrong?

UPDATE:

Note that I’m not saying you should never use messageboxes.  I’m just suggesting that the “Are you sure?” concept in particular be avoided.