Introducing Benchy

Oct 25, 2011

Benchy is an open source .net tool for benchmarking the execution speed of sections of code after each build. Benchmarks are graphed so that changes to performance characteristics in builds can be easily visualised.

I created Benchy because I wanted to do some performance tuning, but I was reluctant to start without having a reliable way to measure the results of my changes over time. I also wanted to be able to see when changes were introduced that had negative impacts on performance. Benchy is my first complete and released open source project. Starting things is hard, finishing things is even harder.

It was fun to be able to start a fresh green fields project that has potential to be useful. As Benchy is a simple system and a new project, I found it was pretty straightforward to write tests first and do Test Driven Development. (TDD with .net, it exists!) I often feel uneasy making things more complex than they need to be, so I was glad that I used Moq for the tests. I really liked not having to add a whole bunch of extra cruft to mock out dependencies during testing.

I shamelessly stole most of the framework concepts from nUnit.

I used flot for graphing the benchmark results.

Read all about it on its dedicated page at http://www.keza.net/benchy/

Or have a look at the source at https://github.com/kezakez/Benchy

Thanks to the company I work at for supporting my ideas and open source.

Client Side Validation of Dynamically Loaded Input Fields in MVC3

Sep 12, 2011

In MVC3 it’s possible to enable client side validation of dynamically loaded input fields by marking up the associated models with attributes via unobtrusive javascript. The result is validation code that is executed straight away on the client side to give the user feedback as well as on the server side to stop bad data from being entered. This approach is a double edged sword, since on one hand you get client and server side code for free, but you’re also limited to a few different kinds of input validation. The other catch associated with this approach is if you are dynamically loading form fields into your page that you want validated, it will not work automatically. 

To understand why, let me tell you a story that explores the depths of your model’s views and controllers as well as the life of your page.

First, your controller is accessed by the incoming request.

Then your controller will load up a model that has properties marked up with validation attributes.

The model is passed to the view.

When the view engine starts pumping out the resulting html it sees the attributes and the unobtrusive javascript settings and adds extra attributes to your html.

The request is fulfilled and the page content is loaded into the browser.

When the page is loaded the unobtrusive and validation javascript scripts are loaded and the validation script adds event handlers to the fields on the page.

It’s at this point that validation should work as expected.

However, if you make an AJAX request that gets a different form or more fields to show on the page, the new content will not run the client side validation.

This is because the content we loaded via the AJAX request is not hooked up like the fields that were there when the page first loaded.

So to get around the issue, all we really need to do is hook up the fields that were dynamically loaded into the page. This can be achieved by adding a bit of javascript to where you are dynamically loading your new fields:

$("#contentid").load("/ContentUrl", postData, function (responseText, textStatus, xmlhttpRequest) {
  if (textStatus == "success") {
    jQuery.validator.unobtrusive.parse("#contentid");
  } else if (textStatus == "error") {
    $("#contentid").html(responseText);
  }
});

The important bit in this code snippet is where we call jQuery.validator.unobtrusive.parse, this hooks up the validation functions to the control events that are required for unobtrusive validation. Now that you can validate input, don’t be a validation nazi.

Game of Life in NodeJS

Sep 7, 2011

Last weekend I went to Brisbane coding event called code smash. It coincided with node knockout. The event was provided us with a space to work, people to work with and pizza. What we did at the event was up to us. In the spirit of node knockout I was keen to do some serious team coding and get results. Luckily I managed to team up with Andrew who had similar goals. Andrew works with ruby on rails full time and I work on asp.net mvc full time. So clearly the sensible thing to do was to write a Game of Life in NodeJS. Just to keep us on our toes.

We had slightly less than 5 hours. So we decided to take a client side javascript version of the game of life that was already written and make it shared from the server side. We got it running on the server first. That was pretty straightforward as the client side javascript was well-written. Then we got the game displaying as quickly as possible by having clients poll the server. Then we added the ability for formations of cells to be added to the game, so it would be more interesting. Andrew seemed to know a bit about the Game of Life, and was aware of interesting formations that would travel. So we added some of these as possible formations that could be added to the game. We got it working and had something to show; we were happy with the day.

This weekend I was still energetic about the project. So I

  • Changed the polling to push based sockets using socket.io;
  • Made the packets a smaller;
  • Made the field size as big as I could;
  • Switched out the heavy duty game library and did the painting with jCanvas; and
  • Gave our Game of Life a home.

I’m not usually a big fan of games like I used to be back in the day. This is probably because I lack the time. This game is a set-and-forget sort of game, there’s no big time investment required. I’m still thinking about how to make it more interesting by adding to the multi-player aspect of the game.

The game suffers from entropy over time and relies on people visiting to add cells to make the result dynamic and interesting.

I have though of a few other interesting possibilities, that could still be explored:

  • Calculate a big field and be able to zoom and scroll around parts of it.
  • Be able generate a still image of a big field frame of the game. Maybe keep some cell history and heat map the image if it’s sparse.
  • Introduce colours to the cells that mix as cells reproduce.
  • Introduce a multi-player aspect where each player can add spawn points that emit predetermined cell formations.
  • Make the server send only the unpredictable state updates, and get the clients to do the other predictable calculations related to display.
  • Be able to have an infinite sized field that scales as servers are added to calculate more of the field.

The code is on github.