Wednesday, 5 March 2014

4 Places to load JavaScript

I watched Enough with the JavaScript Already by Nicholas Zakas the other day and one thing that stuck with me was him outlining 4 places within your page to load JavaScript

  • In <head>
  • Before </body>
  • After page load
  • On demand

Nicholas points out that you don’t just have to load JavaScript in one place, you need to think about what your users will do on the page and this should guide where you load your script.

He then went on to offer some guidance on common things you’d load in each place:

In <head>
To determine how your users are using the site you need analytics, often those scripts state they have to be in the head e.g. Google Analytics. If you are going to put something here it should be absolutely minimal such as boot strap code. 

Before </body>
You should add scripts here that control functionality that users do immediately the page is loaded.

After page load
Once your page is loaded then load scripts that control functionality that the user may do shortly after the page is loaded scripts needed soon after page load

On demand
This is loading a script when needed specifically relating to what the user is doing. The functionality this relates to is code that is used infrequently by the majority of the users of your site (<25%).  Nicholas mentioned a blog post by Alex Sexton which talks about doing this amongst other things (also a good read).


What I specifically took away from this part of his presentation was that all too often before </body> becomes a dumping ground with scripts being put there with no real thought as to what is actually needed on the page.

Something else that crossed my mind is if you’re building a SPA you may think you’re already doing this using require.js or similar mechanism, loading only scripts as you need them, but it may pay you to take a closer look and work out exactly what is loaded and when, perhaps its not being as efficient as you think.

Friday, 21 February 2014

LondonJSConf 2014

Thursday 12th February I attended the inaugural London JS Conf held at the Prince Charles Cinema in Leicester Square which was organised by the team behind London JS.
Turning up at the venue I was greeted by a short queue of fellow attendees and whilst queuing I looked at the cinema posters and noticed that each talk had its own poster.
It didn’t take me long to get inside where registration was easy although I did hear that not long after I got in the queue was right down the street.

Thursday, 30 January 2014


One of the things you hear when developing software, especially in an agile environment, is ensure that you are delivering business value .

But what is business value?

Does your team understand “the value” that a piece of work will provide? I suspect not but here’s the dirty little secret in most companies neither do the business.

Friday, 24 January 2014

Journey into JavaScript

This post is long overdue since I decided to get to grips with JavaScript at the beginning of last year but generally due to being busy at work and learning JavaScript I never got around to actually blogging about it.

Step back in time…

So its January 2013 and the current work I’m doing has a lot of existing JavaScript (JS), its a mature codebase so the work is more maintenance and extension rather than creating from scratch, so well within my existing skillset, but with interest in JS increasing I figure it would be a good idea to look deeper into the language.

Tuesday, 7 January 2014

Moving into 2014

As per previous years I’m doing this as a retrospective on the previous year and trying to plan for the year to come

2013 goals

For 2013 I reduced the number of goals I had to give me a better chance of achieving them:

  • Make better use of personal time
  • Learn JavaScript
  • Investigate Software Craftsmanship
  • Code

Monday, 9 December 2013

Entity Framework Database Migrations are broken for teams

So one of the things that came out of the Entity Framework (EF) model first was migrations, the ability to update your upgrade your database as your model evolved and even better can do this for you automatically.  Sounds like nirvana for developing against RDBMS.

Its just a shame that is fundamentally flawed if you have more than one person in your team making changes to the db at the same time.

The cause of the problem

The reason the migrations are broken is due to how EF Migrations creates a migration (be it automatic or code).

When you create a new migration via the Package Manager EF looks at that database and stores a hash of the schema and then when it comes to include the migration if the hash doesn’t match what it expects it won’t use it, and there’s nothing you can do about it.

What I don’t understand is that like many other migration frameworks EF Migrations have a table in the database to record which migrations have been run

Types of Migration

Before we get into the why the migrations are broken a little background on the different types of migration

Automatic migrations

Automatic migrations create a migration with no input needed from the developer, it looks at your model and previous migrations and works out what’s needed.

Only problem is that even automatic migrations can’t do everything needed for a migrations e.g. column renames and MS themselves recommend you don’t use them in team environments.  If you Google EF Migrations you’ll find other blog posts that tell you not to use automatic migrations at all, they’re great for demo’s but beyond that you’re better off leaving them alone.

Code migrations

Code migrations are where the developer creates the migration themselves and provide the necessary functionality to both apply and reverse the changes to the database.

Doing this gives the developer controller over the changes which can be made via the objects EF Migrations exposes or by being able to issue Sql statements directly at the database allowing for those tricky scenarios which can’t be handled through the objects.

The cause of the problem

The reason the migrations are broken is due to how EF Migrations creates a migration (be it automatic or code).

When you create a new migration via the Package Manager EF creates a hash of the model that the migration was created against, this hash is what causes the problem since the model of each developer creating a migration won’t match after they have applied the migration and whoever merges last will lose out.

Try it for yourself

You can try this out for yourself, yes the example is a little contrived but its the easiest way to deliberately cause the problem. To make it eaier to reproduce I have prepared a repository that has an initial migration to create the database which has a couple of code branches which you use to create the migrations.

  1. Clone repository
  2. on master branch in Package manager console run the following command: 
    Update-Database -TargetMigration:'AddPostClass'
  3. Switch to BreakMigration branch
  4. In the Package manager console run following command: Add-migration ‘AddBlogAbstract’
  5. Save all and then commit the changes
  6. Swap to master branch
  7. In the Package manager console run following command: Add-migration ‘AddPublishedDate’
  8. Save all and then commit the changes
  9. Merge BreakMigration branch into master
  10. In Package manager console run: Update-Database

You’ll then be presented with a message :

Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
You can use the Add-Migration command to write the pending model changes to a code-based migration.

At this point if you are the person trying to apply the migration your heart falls and you set about trying to rectify the situation.

When you hit this the easiest way I’ve found to sort the problem is to delete the migration you are trying to apply, run the Update-database command and then re-run Add-Migration <migration name> –IgnoreChanges, hopefully you only created 1 migration before this happened.

Should you use EF Migrations?

EF Migrations are a full featured migration framework and have a lot of good things going for it, especially if you are using Code-First, but if I was working in a team environment with multiple developers making changes to the database I would look at alternatives to avoid the issue altogether.

Further reading

There are various blogs I found about this but the best is a very in-depth article on MSDN Data Developer Center which explains how the migrations work at a low level, why they use the hash and a couple of options to resolve the issue if you run into it.

Wednesday, 13 November 2013

Running MS Test on Team City without installing Visual Studio

One of the challenges if you are using MS Test has always been being able to run the tests on your Team City server without installing Visual Studio.

The reason for this is that MS Test expects assemblies in the GAC, registry entries, as well as other assemblies outside the GAC.

Now it is possible to pick apart what’s needed and install it all manually (as this post details) but that’s a lot of effort and it only takes one thing to be wrong and nothing’s going to work.

In the past I was faced with this challenge and started down the route of doing the manual install (which went wrong) and then I discovered Visual Studio Agents.

Visual studio agents are what you would use if you had on premise TFS Build server and wanted to add additional servers to support the build, the agent doesn’t contain the entire Visual Studio but does have just the bits you need to run things such as MS Test.

There are versions of the agents from VS2008 through to VS2013 so you should be covered whatever version of VS you are using.

Yes for the purists out there this does mean there is more on your CI server than just what’s needed to run your code, but we are talking about MS Test here Winking smile