AngularJS – Why?

Why Angular?

AngularJS is written in Javascript and is a HTML compiler. It was written by developer, Misko Hevery who originally built AngularJS as a solution for building HTML components with functionality. It is now a fully fledged open source framework. It allows you to build complete applications.

It is very easy to learn and you will find a team of developers will quickly get up to speed. It is extremely popular and backed by Google so there are plenty of blogs, solutions and discussions out there.


Angular reduces time building an application compared to other mvc frameworks and thus saves money.

Two way binding is one of the most important features Angular provides. It enables real time updating of a model as soon as the variable binded to the scope is changed.

Similiar to jQuery, Angular allows you to write code on a higher level than as if you were writing raw Javascript.

Accessibility and locality is also supported. The ngAria module automatically makes most of your site accessible.

Currency, Dates and Number data types are localized out of the box. For the String data type, you will have to manage locals yourself. There are several 3rd party libraries out there that can help you with this.

Testing is what angular is all about. There are several frameworks created by the team at Google that allows you cover all aspects of testing. ngMock is used for unit testing, Protractor is used for end to end testing and Karma is an automation test tool.

AngularJS 1.4 – Declaring a Controller

I’ve been following a few tutorials that describe declaring a MainController. However the tutorials a pre AngularJS 1.3x and are no longer valid. Previous AngularJS allowed you to define a controller globally . As of 1.3x this is no longer the case and you must declare your Controllers inside angular modules. Here’s an example:

var githubViewerApp = angular.module('githubViewer', []);

Declare a new module and give it a unique name. Then assign module to a variable.

var MainController = function MainController($scope, $http) { }

Create your MainController. This is where all your functions and service calls will sit.

githubViewerApp.controller("MainController", ['$scope', '$http', MainController]);

Now bind the MainController variable to the module variable. The variables with $ signs are included in the function parameters to help support minification. Without this minifiers would rename the variable and angular would be unable to bind the parameters to the view.

Javascript – Revealing Module Pattern

This Javascript pattern allows you to define a piece of code with a private scope but have it accessible with a public method. Easy to implement and simple to understand.
var createWorker = function() {</code>

var task1 = function() {

var task2 = function() {

return {
job1: task1,
job2: task2

var worker = createWorker();

<code>task1</code> and <code>task2</code> functions are confined to the scope of the <code>createWorker</code> function.

In order to make them public to the outside scope, the <code>return<code> method ties public accessors to the inner scoped functions.</code></code>

<code>worker.job1();</code> calls job1

Web Performance – IIS GZip Compression

There’s nothing like performance tuning your website and watching benchmarks better themselves. Sometimes it can be tricky but fortunately this is one of the easier fixes. YSlow and Chrome Dev tools recommend gzip compression and you are looking at around a 70% reduction in file size for your static and dynamic resources. Great! So how do we do it?

First of all this blog post applies to IIS7 and above. IIS7 has Dynamic Content Compression un-installed so install it by heading to Windows Features.


In your solution, add the following config to your web.config:

<urlCompression doDynamicCompression="true" />

You can check your dynamic content is now being compressed with gzip by looking at the response header in fiddler, firebug or chrome developer tool:


New Marie Curie ‘In Your Area’ Search Functionality

For the past two weeks here at Marie Curie we’ve been working on new functionality for searching for Marie Curie services across the United Kingdom. It has just today finally gone live and now we can serve our supporters with better information about the key services and events in their area.

‘In Your Area’


On launch we have included the following:

  • Fundraising Groups
  • Fundraising Offices
  • Marie Curie Shops
  • Marie Curie Hospices
  • Events we run

Results are ordered by distance from the location you have entered and can be navigate by either the result list of the result map. Clicking on a result item on one result section, highlights it’s twin in the other.

The page is also fully responsive allowing you to view the search results and map as separate views.


Click here to go to the live search

Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.


Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way 🙂

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.


We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test on feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as we rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Property Injection & Action Filters in EPiServer 7 CMS

I spent a bit of time putting in some custom implementation to support Property Injection on to my Action Filters before realizing that EPiServer 7 already provides this functionality for me. Doh.

In order to take advantage all you need to do is set your DI controlled interface to the generic type property of the Injected class. This will lazily set the interface when the property is used…awesome.

public class CustomFilter : ActionFilterAttribute
public Injected<IService> Service { get; set; }