Parallel Pair Programming

I’ve spent a bit of time working with Les recently and it’s been quite interesting working out the best way for us to pair together as he’s working as a front end developer on the team which means he’s best utilised working on the CSS/JavaScript/HTML side of things.

Having said that there are often features which require both front end and backend collaboration and we’ve been trying to drive these features from the front end through to the backend rather than working on the backend code separately and then working with Les later on to hook it all up to the frontend.

As a result we’ve found that it seems to be most effective to prototype any backend code that we write while working together such that we just write enough code to allow us to see that everything is hooked up correctly.

Once we’re happy that we’ve got that working correctly then we split up and work side by side, effectively parallel pairing as Vivek Vaid describes it.

At this stage I would focus on driving out the backend code properly with a more test driven approach and Les works on tidying things up from a front end perspective and ensuring that the feature’s look and feel is consistent across browsers and doing any other front end related functionality.

The benefit that we’ve seen from doing this is that we’re able to work together on the code where we get the most value from doing so and then split up to work on the other things where we wouldn’t add as much value to each other in a pair programming situation.

Since we’re working directly together at the beginning of a story we also get the benefit of iterating/talking through the potential approaches that we can take and I’ve often found that I take a better approach to solving a problem when working with a pair than when working alone.

The thing that we have to be careful about when doing this is ensuring that we’re not treading on each other’s toes because we are working around the same part of the code base and often on the same files.

This means that there is a bit of merging to do but as we’re also sitting next to each other it hasn’t proved to be too much of a problem. I think using a source control tool like Git or Mercurial with their merging capabilities would probably make this a non issue.

It seems to me that we’re still getting the benefits of pair programming with this approach and I’m more convinced that this might be a useful approach in other situations as well.

node.js: First thoughts

I recently came across node.js via a blog post by Paul Gross and I’ve been playing around with it a bit over the weekend trying to hook up some code to call through to the Twitter API and then return the tweets on my friend timeline.

node.js gives us event driven I/O using JavaScript running server side on top of Google’s V8 JavaScript engine.

Simon Willison has part of a presentation on slideshare where he describes the difference between the typical thread per request approach and the event based approach to dealing with web requests using the metaphor of bunnies. He also has a blog post where he describes this is more detail.

Another resource I found useful is a video from where the creator of node.js, Ryan Dahl, explains the philosophy behind event driven I/O and gives several examples using node.js.

These are some of my thoughts so far:

  • I’m not used to have so many callbacks spread all around the code and I’m still getting used to the idea that they aren’t executed until the event actually happens!

    I often find myself looking at a piece of code and not understanding how it can possibly work because I’m assuming that the function passed in is executed immediately when in fact it isn’t.

  • If you make a web request the response comes back in chunks so the callback we setup to capture the response will be called multiple times with different parts of the response message.

    For example I have this code to call Twitter and return all my friends’ status updates:

    var sys = require("sys"),
        http = require('http')
    exports.getTweets = function(callBack) {
        var twitter = http.createClient(80, "");
        var request = twitter.request("GET", "/statuses/friends_timeline.json",
                                      {"host": "",
                                       "Authorization" : "Basic " + "xxx"});
        request.addListener('response', function (response) {
            var tweets = "";
            response.addListener("data", function (chunk) {
                tweets += chunk;
            response.addListener("end", function() {
      , tweets);

    I originally thought that the listener for ‘data’ would only be called once but it gets called 8 times sometimes so that I’ve created the ‘tweets’ variable which allows us to wait until we have the full response before firing the callback when the ‘end’ event is fired.

    I’m not sure whether I’m missing the point a bit by doing this and I think I possibly need to get more used to designing functions which can deal with streams rather than expecting to have all of the data.

  • It seems like node.js would be perfect for a version of my colleagues Julio Maia and Fabio Lessa’s http-impersonator which is a Java application used to record and replay requests/responses made across http-based protocols.

    I haven’t quite worked out the best way to test the above code – ideally I want to stub out the HTTP request so that the test doesn’t have to go across the wire. Micheil Smith pointed me towards fakeweb which allows the faking of HTTP requests/responses in Ruby so I’ll probably have a go at creating something similar.

So far node.js seems really cool and writing code using it is really fun. I’m still not sure exactly where it will fit in some of the architectures that I’ve worked on but the model it encourages feels really natural to work with.

A reminder of the usefulness of Git

Despite the fact that none of the projects that I’ve worked on have used Git or Mercurial as the team’s main repository I keep forgetting how useful those tools can be even if they’re just being used locally.

I ran into a problem when trying to work out why a Rhino Mocks expectation wasn’t working as I expected last week having refactored a bit of code to include a constructor.

I wanted to include the Rhino Mocks source code in our solution before and after the refactoring and step through the code to see what was different in the way the expectations were being setup.

My initial thought was that I could just check out the repository again in another folder and then include the Rhino Mocks source code there and step through it but unfortunately we have all the projects set up to deploy to IIS so Visual Studio wanted me to adjust all those settings in order to load the solution in the new checkout location.

I probably could have gone and turned off that setting but it seemed a bit too much effort and I realised that I could easily use Git to help me solve the problem.

I took a patch of the changes I’d made and then reverted the code before checking it into a local Git repository.

I updated the solution to include the Rhino Mocks code and then created a branch called ‘refactoringChanges’ so that I could then apply the patch that I’d created with my changes.

It was then really easy to switch back between the two branches and see the differences in the way that the Rhino Mocks was working internally.

The actual problem eventually turned out to be the way that the code calls Castle DynamicProxy but I didn’t get the chance to look further into it – we had learnt enough to know how we could get around the problem.

I’m in the process of including the source code for all the 3rd party libraries that we use in the solution on a separate Git branch that I can switch to when I want to debug through that code.

Sometimes I end up having to close down Visual Studio and re-open the solution when I switch to and from that branch but apart from that it seems to work reasonably well so far.

Preventing systematic errors: An example

James Shore has an interesting recent blog post where he describes some alternatives to over reliance on acceptance testing and one of the ideas that he describes is fixing the process whenever a bug is found in exploratory testing.

He describes two ways of preventing bugs from making it through to exploratory testing:

  • Make the bug impossible
  • Catch the bug automatically

Sometimes we can prevent defects by changing the design of our system so that type of defect is impossible. For example, if find a defect that’s caused by mismatch between UI field lengths and database field lengths, we might change our build to automatically generate the UI field lengths from database metadata.

When we can’t make defects impossible, we try to catch them automatically, typically by improving our build or test suite. For example, we might create a test that looks at all of our UI field lengths and checks each one against the database.

We had an example of the latter this week around some code which loads rules out of a database and then tries to map those rules to classes in the code through use of reflection.

For example a rule might refer to a specific property on an object so if the name of the property in the database doesn’t match the name of the property on the object then we end up with an exception.

This hadn’t happened before because we hadn’t been making many changes to the names of those properties and when we did people generally remembered that if they changed the object then they should change the database script as well.

Having that sort of manual step always seems a bit risky to me since it’s prone to human error, so having worked out what was going on we wrote a couple of integration tests to ensure that every property in the database matched up with those in the code.

We couldn’t completely eliminate this type of bug in this case because the business wanted to have the rules configurable on the fly via the database.

It perhaps seems quite obvious that we should look to write these types of tests to shorten the feedback loop and allow us to catch problems earlier than we otherwise would but it’s easy to forget to do this so James’ post provides a good reminder!

Does an organisation need to be fully committed to agile/lean/scrum?

Alan Atlas has a recent blog post where he discusses agile, lean and scrum and suggests that you can’t truly achieve agility unless your company is fully committed to it which differs slightly from my experiences.

Alan makes a valid point that we’re not really following an approach just because we use all the practices:

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.”

It’s quite easy to put our work up on a story wall, run a daily standup and unit test our code and not really get the full benefit that those practices are supposed to give us.

As I’ve mentioned before though I think it is part of the learning process that we start out focusing on practices and not principles.

However, at some stage we need to start thinking for ourselves about the value those are giving and making adjustments to them if we’re not seeing much value i.e. we need to look beyond the practice and to the principle or outcome that we are trying to achieve by using that practice.

The part of the post which is different to my experiences is this bit:

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.

I haven’t heard conversations like this before but I think it is still possible to deliver software in a team working in an ‘agile’ way even if the rest of the organisation which that team operates in follows a different approach.

It won’t be as smooth sailing as if the whole organisation buys into the lean/agile approach and there will still be some reporting and bureaucracy that you need to deal with but it’s not a lost cause.

My colleague Lindy Stephens and a couple of others covered some of the issues around project governance in the enterprise in a ThoughtWorks QTB in Sydney last year. The slides from that presentation are available on slideshare.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

Even if an organisation decides that it wants to be agile I think it still takes time to get used to the approach and it always seems to take a few successful deliveries to see that some of the worries that heavy weight processes and paperwork try to protect you against are not necessarily valid.

I’ve spent a lot of time being indignant that people didn’t buy into the agile approach but the more I spend time in different organisations the more it becomes clear that even for the people with the best intentions in wanting to learn this approach it will still take time to get there.

I’m coming to the conclusion that it’s a good thing that people have some level of skepticism because it forces you to really understand why an agile approach is more effective and then try and persuade other people of that.

It’s also helpful to note that it makes sense to vary our approach depending on the context that we’re operating in. For example if the team is distributed across different cities then we might have more written documentation than with a co-located team.

It’s very rare that an organisation or group of people will just ‘get it’ straight away – in many ways it’s quite an iterative/incremental journey.

Javascript: Function scoping

My colleague John Hume wrote an interesting post about his experience with the ‘const’ keyword in ActionScript where he describes the problems with trying to capture a loop variable in a closure and then evaluating it later on in the code.

Since ActionScript and JavaScript are both dialects of ECMAscript, this is a problem in JavaScript as well, and is due to the fact that variables in JavaScript have function scope rather than block scope which is the case in many other languages.

This problem would tend to reveal itself in code where we try to capture a loop variable in an anonymous function and use it later on, like so:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       x[i] = function() { return i; }
    return x;
var values = getValues();
for(var j=0; j < values.length; j++) {

We might expect that to print the sequence of numbers 0-9 on the screen but what we actually get is ’10’ printed 10 times.

There are a couple of things that I initially found strange about this:

  1. Why doesn’t it print out the numbers 0-9?
  2. Given that it doesn’t do that why does it print out ’10’ 10 times instead of ‘9’ 10 times?

The answer to the first question is that ‘i’ gets assigned a new value on each iteration of the loop and we don’t evaluate ‘i’ until we evaluate the anonymous function on line 11.

The value when we do evaluate it would be the last value that it was set to by the loop which in this case that would be ’10’ because that’s the value that ‘i’ has to be in order for the loop to terminate.

This is actually a problem in C# as well – the following code will output ’10’ 10 times as well:

public void ClosureOnTheSameValue()
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
        values.Add(() => i);
    foreach (var value in values)

Again we capture ‘i’ inside a closure and since we only evaluate that value when it’s actually used it will always refer to the last value that ‘i’ was set to which in this case means that it will always output a value of 10.

To fix this in C# we could just create a temporary variable – something which Resharper will actually suggest to us:

public void ClosureOnDifferentValue()
    var values = new List<Func<int>>();
    for(int i=0; i < 10; i++)
        var idash = i;
        values.Add(() => idash);
    foreach (var value in values)

This works in C# because variables have block scope which means that we have a new version of ‘idash’ for each of the functions that we add to the ‘values’ collection.

Sadly the same trick doesn’t work in JavaScript because variables have function scope in Javascript:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
       var idash = i;
       x[i] = function() { return idash; }
    return x;
var values = getValues();
for(var j=0; j < values.length; j++) {

The ‘idash’ temporary variable that we created to try and solve the problem gets assigned a new value in each iteration of the loop because that variable is only declared once for the whole function.

The code above could be written like this to make that clearer:

function getValues() {
    var x = new Array();
    var idash;
    for(var i=0; i < 10; i++) {
       idash = i;
       x[i] = function() { return idash; }
    return x;
var values = getValues();
for(var j=0; j < values.length; j++) {

As John points out:

Here’s something I either never knew or at some point forgot about JavaScript: variables are lexically scoped, but only function bodies introduce new lexical scopes.

In this case we actually end up printing ‘9’ 10 times because that’s the maximum value that gets assigned to ‘idash’.

One solution is to create a temporary variable inside an anonymous function that we execute immediately, like this:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) {
        (function() {
            var idash = i;
            x[i] = function() { return idash; } })();
    return x;
var values = getValues();
for(var j=0; j < values.length; j++) {

Now ‘idash’ is scoped inside the anonymous function and we therefore end up with a new value each time like we want.

Raph pointed out that we could achieve the same thing in a simpler way with the following code:

function getValues() {
    var x = new Array();
    for(var i=0; i < 10; i++) (function(i) {
        x[i] = function() { return i; };
    return x;
var values = getValues();
for(var j=0; j < values.length; j++) {

Here we define a for loop with just a single statement so we can lose the ‘{}’ and just call an anonymous function passing in ‘i’.

Of course this example is truly contrived but I wanted to pick something simple enough that I could try and follow exactly how it worked.

I’m not entirely sure of the terminology around closures and scoping so if I’ve described anything incorrectly then please correct me!

Pair Programming: Some thoughts

Mark Wilden pointed me to a post he’s written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations.

When you pair program, you’re effectively joined at the hip with your pair. You can’t pair if only one of you is there.

I’ve previously written wondering what we should do if our pair isn’t around where I was leaning more towards the opinion that we should try to continue along the same path that we were on when working with our pair if they’re gone for a short amount of time and to find a new pair or work alone if they’re gone for longer.

On the projects I’ve worked on we’ll still have times working alone when there’s an odd number of people around or if someone just feels like working on their own and I think that’s fine as well. I don’t think we need to pair 100% of the time.

You have to be able to think out loud – 8 hours a day. Then you have to type in code while someone is watching you. They’ll catch your typos (hopefully after giving you a chance to spot them yourself) and they’ll see when you’re floundering for how to do something.

I find that this is quite a useful practice for explaining things to yourself although I can see how it would initially exhausting.

Even now there are times when I just want to write some code instead of having to explain what I want to do to someone else. Sadly almost every time I explain something it turns out that my pair has a better idea of how to do it than me so I’m always glad pairing encourages this conversation.

Pair programming doesn’t encourage quiet reflection and exploration. You can’t just sit back and read some code. You can’t just sit and think. I mean, you can, but then your pair is just sitting there.

This is a bit of a double edged sword – pair programming does encourage us to get things done but it’s also true that sometimes we need to get the whiteboard out.

Often just sketching out the problem on a piece of paper to check your understanding is enough to trigger a conversation which might result in a better solution.

It does tend to need one person to drive this process though. I haven’t seen it just happen organically.

We rarely pair 100% of the time so there are often times when you get a bit of time to play around a bit with the code and see whether specific approaches would work out and I often use this time for reflection and exploration.

One thing which a couple of the commenters on the original blog suggested is that perhaps more rotation was needed to help overcome some of the problems and from my experience it’s vital that we do rotate otherwise the pair will end up hating each other!

I recently worked on a story with 3 other people across its life and each person pointed out something that I hadn’t previously considered and which led to an eventual output that was much better than it would have been otherwise.

I think rotating different people onto a story can help lead to more innovative design as long as we have people working together who are relatively flexible and open to trying out new ideas.

Mark’s post is certainly interesting though and helps identify some of the things we need to be aware of when pair programming – we don’t just want to follow the practice blindly.

Getting real: Book review

I recently came across 37 Signals ‘Getting Real‘ book where they go through their approach to building web applications and there have certainly been some good reminders and ideas on the best way to do this.

These are some of my favourite parts:

  • Ship it!

    If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

    Often on projects I’ve worked on we’ve taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.

    In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.

    Prioritize your bugs (and even ignore some of them)

    Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

    I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.

  • Fix Time and Budget, Flex Scope

    You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

    From my experience a lot of times we end up implementing features just because that’s what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn’t really that useful anymore.

    It becomes even more problematic if we get to the stage where it’s not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.

  • Choose any enemy

    Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

    This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you’re working in the same area.

    The problem with that approach of course is that when you do copy you have no actual vision of what you’re doing with your application anyway so you’ll always be playing catch up.

  • Don’t overcomplicate the application

    There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:

    The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

    Keep it small. Keep it simple. Let it happen.

    Andrew Hunt, The Pragmatic Programmers

    The users can then decide for us where we need to fill in more details:

    Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

    In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.

  • Scaling an application

    You don’t have a scaling problem yet

    “Will my app scale when millions of people start using it?”

    Ya know what? Wait until that actually happens.

    On several projects that I’ve worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.

  • Write less software

    A common theme throughout the book is that of writing less software to achieve our goals:

    The best designers and the best programmers…are the ones that can determine what just doesn’t matter.

    That’s where the real gains are made.

    Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

    Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

    Throw away customer feature requests – if they’re really important then they’ll come back anyway

    Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.

    The authors ideas around preferences were particularly interesting to me:

    Preferences are also evil because they create more software.

    More options require more code. And there’s all the extra testing and designing you need to do too.

    I hadn’t appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.

    It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it’s not the core idea of the application.

    I also quite liked the following and I think it’s something that we need to do more often on teams:

    Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

  • Decisions are temporary so make the call and move on

    So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

    Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

    I think a big part of this is getting the mentality that it’s fine to make changes after we’ve ‘finished’ something. Any other approach doesn’t work from my experience.

  • Reduce meetings

    Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

    I find it interesting that they prefer communicating by email because I’ve often found that it’s not the best communication mechanism since it’s really easy to misinterpret what people mean.

    Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.

  • Design the interface before you start programming

    Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

    I’ve certainly fallen into this trap a lot but I’ve been trying to follow the outside in approach more strictly recently and so far I’m finding that it reduces the feedback cycle quite substantially which is only a good thing.

  • Design for regular, blank, and error states

    For each screen, you need to consider three possible states:

    The screen people see when everything’s working fine and your app is flush with data.

    The screen people see when using the app for the first time, before data is entered.

    The screen people see when something goes wrong.

    I’d never even though of this at all and I’m certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.

  • Tear down the walls between support and development

    In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

    My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.

    The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I’ve not done it as yet.

Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it’s strange that we often don’t do all of them.

The 37 Signals guys also have a new book coming out in the UK tomorrow titled ‘Rework‘ which sounds like it could be quite a good read as well.

Javascript: The ‘new’ keyword

I came across an interesting post by John Resig where he describes a ‘makeClass’ function that he uses in his code to create functions which can instantiate objects regardless of whether the user calls that function with or without the new keyword.

The main reason that the new keyword seems to be considered harmful is because we might make assumptions in our function that it will be called with the new keyword which changes the meaning of ‘this’ inside that function.

For example in my Bowling Game example I assume that the ‘BowlingGame’ function will be called with the new keyword.

I wanted to see if I could refactor that code to use the module pattern instead so as a first step I changed the instantiation of the ‘bowlingGame’ variable in the tests to not call the function with ‘new’ to see if it would make any noticeable difference:

Screw.Unit(function() {
	describe("bowling game scorecard", function() {
		var bowlingGame;
		before(function() {
	    	     bowlingGame = BowlingGame();

There is no noticeable difference in the way any of the tests work but in fact all of the functions I defined have been added to the global object (in this case window) instead of onto ‘BowlingGame’.

I changed one of the tests to check that this was the case…

			it("should score a single throw", function() {
				(19).times(function() { gutterBall(); });
				expect(bowlingGame.score()).to(equal, 5);

…which logs ‘undefined’ to Firebug if the new keyword is used to instantiate ‘bowlingGame’ and ‘function()’ if it wasn’t.

The danger here is that you could change the meaning of the ‘roll’ function outside of the ‘BowlingGame’ if you wanted to.

To give a contrived example perhaps we could change ‘roll’ so that it actually called the original function twice instead of once:

			it("should score a single throw", function() {
				var originalRoll = window.roll;
				window.roll = function() {
					originalRoll.apply(this, arguments);
					originalRoll.apply(this, arguments);
					console.log("roll isn't what you'd expect anymore")				
				(19).times(function() { gutterBall(); });
				expect(bowlingGame.score()).to(equal, 5);

In this case you would probably never do that because it’s just a small bit of code but you wouldn’t want to add random functions to the global object in any reasonably sized javascript application.

Shog9 points to a bit of code which allows us to stop users from calling constructor functions without the new keyword:

BowlingGame  = function() {
	if ( !(this instanceof arguments.callee) ) 
	   throw Error("Constructor called as a function");

When ‘BowlingGame’ is called without the new keyword then ‘this’ will refer to ‘window’ which means that it won’t be an instance of ‘arguments.callee’ which in this case is the ‘BowlingGame’ function.

Functional C#: Using Join and GroupJoin

An interesting problem which I’ve come across a few times recently is where we have two collections which we want to use together in some way and get a result which could either be another collection or some other value.

In one which Chris and I were playing around with we had a collection of years and a collection of cars with corresponding years and the requirement was to show all the years on the page with the first car we found for that year or an empty value if there was no car for that year.

We effectively needed to do a left join on the cars collection.

This is an imperative way of solving the problem:

public class Car
     public int Year { get; set; }
     public string Description { get; set; }
var years = new[] { 2000, 2001, 2002, 2003 };
var cars = new[] { new Car { Year = 2000, Description = "Honda" }, new Car { Year = 2003, Description = "Ford" } };
var newCars = new List<Car>();
foreach (var year in years)
    var car = cars.Where(x => x.Year == year).FirstOrDefault() ?? new Car  { Year = year, Description = ""};

We can actually achieve the same result in a more declarative way by making use of ‘GroupJoin‘:

var newCars = years.GroupJoin(cars, 
                              year => year, 
                              car => car.Year,
                              (year, theCars) =>  theCars.FirstOrDefault() ??  new Car { Year = year, Description = ""  });

‘GroupJoin’ is useful if we want to keep all of the items in the first collection and get a collection of the items in the second collection which match for the specified keys.

In this case it allows us to identify where there are no matching cars for a specific year and then just set a blank description for those years.

One nice side effect is that if we later want to include multiple cars for a year then we shouldn’t have to change the code too much to achieve that.

Another example which I came across is where we have one collection which contains filter criteria which it needs to apply against the other collection.

We have a collection of years and need to indicate whether there is a matching car for each of those years.

public void JoinExample()
    var years = new[] { 2000, 2003 };
    var cars = new[] { new Car { Year = 2000, Description = "Honda" },
                       new Car { Year = 2003, Description = "Ford" },
                       new Car { Year = 2003, Description = "Mercedes"}};
    Assert.That(AreThereMatchingCars(years, cars), Is.True);
public bool AreThereMatchingCars(IEnumerable<int> years, IEnumerable<Car> cars)
    foreach (var year in years)
        if(cars.Where(c => c.Year == year).Count() == 0)
            return false;
    return true;

We can rewrite this function like so:

public bool AreThereMatchingCars(IEnumerable<int> years, IEnumerable<Car> cars)
    var distinctCars = cars.GroupBy(x => x.Year).Select(x => x.First());
    return years.Join(distinctCars, y => y, c => c.Year, (y, c) => c).Count() == years.Count();

This actually become more complicated than we expected because we were working out if there were matching cars for each of the specified years by checking the number of filter items and then comparing it to the number of items when we joined that collection with our collection of cars.

If we have more than one car for the same year that logic falls down so we needed to get just one car per year which is what the first line of the function does.

I can’t decide whether or not the code is easier to read and understand by making use of these functions but it’s an approach that I picked up when playing around with F# so it’s interesting that it can still be applied in C# code as well.