New Year, New Post

As is traditional at this time of year, and since this is my first blog post of 2009, I would like to lay down a list of 'New Years Resolutions'. And afterall, who am I to be different, so why not a list of my own? Oh, how convinient, here is such a list:

 

  • Post at least once a month in this blog (yes god damn it this counts as this months post)
  • Start a photoblog
  • Purchase a film camera Already done, I did it whilst I was typing this (an old school Lomo Holga 120N from ebay, £21 delivered))
  • Record a song on guitar
  • Make a start on learning 2 new foreign languages (my Audible subscription should help me greatly with this, they have a fantastic selection of language books)
  • Finish my degree with a 1st
  • Learn to drive

And if you think you're getting any more content out of this post, you are sadly mistaken, as its 5:30am.

 

January 9th, 2009 6:24 am
8 comments filed

Real Simple Test Driven Development in Visual Studio

 

Step 1

Decide the feature you need to implement. In this case I have decided that my DefaultNewsProvider class needs a method for returning a single news item when passed its Id.

 

Step 2

Open your test file that is responsible for testing the DefaultNewsProvider class (in this case it is in my Keima.Website.Data.Test/NewsProviderTests).


Step 3

Write the test with the expected result. I know that in my database their exists a news item with an Id of "tag:keima.co.uk,2008-06-26:Composer 2.0 Launch", therefore I construct a a test that calls the new GetNewsItem method with the Id, then compares the result to check we have been given the correct item back.

 

Step 4

We have hit a problem, this method does not actually exist despite having the test for it. So, bring up the code helper and generate the method stub.

Step 5

Test the code. Go on. Watch it fail.

 

Step 6

Make it pass. In this case its easy, a sort of 'fill in the blanks'. So back to DefaultNewsProvider it is and the implementation is finished off.

 

Step 7

Re-run the test, watch it pass. All is well, the code has been added, a test has been created, and if in the future the method breaks due to other code changes you will know immediatly.

 

List of reasons why test driven development can help you:

 

+ Allows your code to be maintainable, shows the exact point of failure of a program, none of this nasty debugger related stack tracing and breakpointing anymore
+ Forces you to focus upon the expected usage of a function, not the specifics of its implementation. Once you get in to the TDD mindset this allows you to be more concerned with the abstract ideas of how the project should be designed and structured with maintainability in mind as opposed to language specific implementation details (e.g. "I need a function that returns a file handle given a file name or null on an invalid file" rather than "What calls need to be made inside C# to open a file?"
+ At any one time, your code WORKS. Ensuring that code is correctly covered by tests allows you to guarantee that at any one time your project can be built and shipped to a customer. 
Your tests are more accurate (bold assumption I know, but here me out). Designing the code by considering how it will be used, and ensuring that tests are constructed at the beginning is much more preferable to designing tests once a project is finished, where code may be missed, meanings of code blocks forgotten about or motivation does not allow for proper testing.

 

A few other notes
+ Name your tests properly. GetNewsItemReturnsCorrectItem is much more imormative than GetNewsItem, especially in large applications where there can be tens of thousands of tests, it just makes finding the cause easier.
+ You _will_ be writting more code.
+ For each function, class and library you have have a matching Test function, class and library.
+ Try and have three tests for each function, a test that returns the correct result (like show above), a test which tries to break it (an invalid id) and a test which is just plain wrong (passing null in for example).

 

As ever address any personal experiences, observations, suggestions or death threats through the comments.

July 6th, 2008 2:13 am
2 comments filed

Code Reduction in C# 3

C# 3.0 is god like. Undeniably. The ability to reduce your code is amazing. Now, I understand the code zealots out there will say "Yeah, but X language has been able to do this for years". Well I don't really care about X language truth be told. The .NET platform is so widely deployed and supported now I don't really see why in 9/10 cases I should use language X.

Consider the following basic example, of calculating an Inverse Distance Weighted plot of signal strength of a given location given a set (plots) of locations and their corresponding signal measure.

The formula is simple, for a given point x, the strength is the sum of wk(x) (one over the distance between the two points to the power of a fixed parameter p) times uk (the value at k) over the sum of wk(x):

 

Traditionally, this would yeild the following code:

double sumWkUk = 0;
double sumWk = 0; 
 
foreach(Location loc in plots)
{
sumWkUk += wk(x, loc) * loc.Value;
sumWk += wk(x, loc);
}
 
x.Value = sumWkUk / sumWk;

 

Not too much code, but this can be reduced a lot. Consider using the C# 3.0 sum operator:

 

x.Value = plots.Sum(xk => wk(x, xk) * xk.Value)
/ plots.Sum(xk => wk(x, xk));

 

Wait, what, did we just reduce that to ONE LINE of code? Shit.

Are you listening Java? No, thought not, no wonder you are still losing the great programming race (or maybe I am just bitter).

Summary:

- Less code to maintain is good.

- Gives us less chances for errors

- makes it easier to read and understand (in this case at least)

 

Opinions? Discuss? Don't care? Don't even know what you are doing here?

May 2nd, 2008 6:21 pm
2 comments filed

Microsoft gave me free Ice Cream

I dont really know why everyone bashes Microsoft so, I mean after all, they gave me a free lunch, and free ice cream! Oh, and all the free stuff in this picture. Well, apart from the book on LINQ and C# 3, but then I did get those at 40% off retail. Which is pretty reasonable when you think about it.

Wait, maybe I need to backtrack and explain exactly WHY I got free ice cream. I went to the MSDN Roadshow, its basically a tour where they give presentations on four key topics to do with MSDN, and generally Microsoft software development. The bill was pretty interesting today, the line up was something like:

  • ADO.NET
  • ASP.NET
  • Silverlight
  • Team Foundation Server
Lets talk about them in the order of interesting, since I am le tired and I'll probably be bored of typing by the time I get to the end of this paragraph. Silverlight is probably the most interesting by a mile. Not so much the fact that you can embed .NET code straight in to your browser, but the fact that it forces the use of XAML. XAML is great. Its like XML, but for describing the layout of your interface. It compiles in to form code exactly as the same as code inside Visual Studio does, and its easy, simple and clean to code. No more messing about managing instances of Form or Button.
ASP.NET is the next entry down the list, its not really much of an improvement over .NET 2 really, apart from this stupidly lame attempt at creating an MVC. I mean, once you get in to it, I'm sure its great, but I just really can't get in to it.
ADO.NET and TFS don't really deserve any kind of words at all. They are interesting if you love your data modeling (actually its quite neat, but it just doesn't excite me), or if you love unit testing your databases, but its not for me.
Oh, and this post *is* a week old, but being as lazy as I am, I totally forgot to finish or publish it. So there you go.

April 29th, 2008 12:51 pm
1 comment filed