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:


Implementing UAT into Scrum

Definition of uat

User acceptance testing is an a process that validates the deliverable conforms and meets the business requirements initially laid out.


Proposed Agile Process with UAT

Support Process - Support Process (1)

This proposal introduces a period of time after the sprint has ended to allow for UAT. It provides business analysts, product owners and stakeholders to look at the feature before going live on to the production website.

This also gives them the opportunity to raise bugs which we can triage and categorize into either an immediate hotfix or to be put into the backlog.

Current Issues & resolutions to those by using the proposal


Testing within the sprint


The awaiting approval status within the sprint against user stories is effectively forcing business analysts to perform UAT within the sprint.

This caused numerous problems because the features crossing multiple stories were being tested and bugs were being raised despite the entire feature not being complete.

Additionally business decisions were being made within the sprint without the knowledge of the product owner or stakeholders.


Introducing UAT after the sprint ends allows not only business analysts but the product owner and stakeholders to look at the features together once we have declared them as finished.

We will only release completed features for UAT once the develop team has completed all user stories associated with that feature and are satisfied any major bugs have been resolved.


Stakeholder Involvement


Features were going straight into LIVE without allowing the stakeholders to accept with them first.

There were numerous example of the SCRUM team developing features against user stories but once going live, the stakeholders raised complaints about missing components or incorrect assumptions. The scrum team then had to work on hotfixes within the active sprint and forced us to drop some user stories.


Any bugs found within UAT and are deemed critical should be raised as a P1 within the active sprint. They must be worked on immediately on a hotfix branch.

25% of the active sprint time should be allocated to each team member to allow us to fix any issues raised from UAT.


Technical Actions needed to adopt the proposal

We will now need to extend our use of development branches in order for the proposal to run smoothly.

In addition to our current workflow with branches we will now introduce Release branches.

These are created from the develop branch and represents the latest code ready for UAT. This will happen at the end of the sprint. Any left over work will require the developer to work on this branch and allow other developers to work on the develop branch for the next sprint.

Bug fixes are worked on this branch. They can be re-merged into develop at any time.

If accepted then it is merged into Master ready for deployment to Production.

The Master branch is also tagged for future reference.

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 Service { get; set; }

Architect – Technical Design Workflow for Creating New Fundraising Page using JustGiving API

JustGiving provides an API that allows charities to create fundraising pages from their own website. Charities benefit from this by being able to integrate this functionality into their own user journeys.

I designed a user journey workflow for a user to create a JustGiving Fundraising Page in remembrance of someone for where I currently work.

From a technical perspective I worked on this taking into consideration the capability and limitations of the JustGiving API. This is so I could empower our UX guys with the right information in order to make the user journey as efficient at possible and not to get hindered by technical limitations later on in the process.

My initial thought was I needed to create a journey that allowed the user to take a minimum amount of actions to get to the end goal of creating a fundraising page. Anything after that could be included as an enhancement or additional requirements from the business that hold value else where.

This what I took into consideration is:

  • You require an active Just Giving account to create a fundraising page. The workflow supports users who do and do not have a pre-existing account.
  • At this point (as standard with any account functionality) the workflow it forks out and forks back in again ending up with the user that is logged in with an account.
  • We then describe the required fields we must expose and the optionals ones that we could take advantage of.
  • Each relevant step also mentions the correct API call that is needed.

Architect - Design Workflow for Creating New Fundraising Page using JustGiving API

Manipulating an EPiServer Page Programmatically

Creating a Page

Here’s how you can create a page in code from a page type you’ve already defined.

First create a new instance of the page type under another page in the form of a link:

var newBlogPost = ContentRepository.GetDefault<BlogPostPage>(parentLink);

Then set whatever properties you wish to the newBlogPost object.

newBlogPost.Subject = "Creating an EPiServer Page Programmactically";
newBlogPost.Content = "Meta";

Finally call the Save method on EPiServer’s content repository.

ContentRepository.Save(newBlogPost, SaveAction.Publish)

Updating a page

The structure to updating a page is thankfully very similar to creating one.

Load the page you wish to update from the Content Repository. 5 is the id of the page.

var contentReference = new ContentReference(5)

Create a writeable clone of the update. This allows you to update it’s properties:

var clone = (BlogPostPage)page.CreateWritableClone();

Update a properties of the cloned page

clone.Subject = "Creating an EPiServer Page Programmactically";

Call the Content Repository to Save the page and public it at the same time:

ContentRepository.Save(clone, SaveAction.Publish);


When creating a new page and / or block you may get the following exception:

The INSERT statement conflicted with the FOREIGN KEY constraint 'FK_tblContent_tblContentType'. The conflict occurred in database ' ', table 'dbo.tblContentType', column 'pkID'.

This commonly gets throw when there are two developers working against the same database but have different versions of the page / block you are trying to save.

HTML with in-line Razor

This little gotcha keeps biting me in the ass every time I move away from Razor for a while. So I’ve decided to blog so this time I’ll remember.

When you want to insert some razor syntax in-line within a HTML tag. Make sure you include the @ delimiter on any further statement.

Following example attempts to add a class based on a bool value in the model.

The class show does not render:

<div class="@if(Model.Show) { Html.Raw("show") }"> 

The Html.Raw helper method is returning a MvcHtmlString however it will not output the value unless you tell it to by prefixing the statement with @. Now it renders !

<div class="@if(Model.Show) { @Html.Raw("shoe"); } }">

EPiServer 7 CMS – Import and Exporting Content between Environments

At Marie Curie we have several environments that sit across our infrastructure. Occasionally we get a requirement to shift content from one environment to another. This could be because we’ve auto generated pages via scheduled job or that QA have created a string of pages and want it replicated in another environment without having to key them all in again. Here are the basic steps required to do this.

Export Data

The EPiServer admin section exposes two tools which allow you to do this, Import Data and Export Data. On your source environment navigate to the Export Data tool.

EPiServerAdmin Import Export Data

Content items, content types even property definitions can be exported. What we are interested in is Export Content Items. Tick this box then hit the lookup button. This will make a pop up window appear with your website’s tree structure. Choose the page you are interested. Hit Select then hit Export.

EPiServerAdmin Import Export Data

The export data screen will show in real time the number of items that have been exported and your browser will automatically down a zip file.

EPiServerAdmin Import Export Data

Import Data

Switch to your target environment and once again head to the admin section but this time click on Import Data. here you can select the zip file you just exported and destination of the content. When you are ready click Begin Import.

EPiServerAdmin Import Export Data

Done! You will see that all the content items have been successfully imported.

EPiServerAdmin Import Export Data

I would not recommend this method as part of a permanent solution. It should be used for more one off circumstances. Remember that the target and source environment should have matching content types and property definitions otherwise you may not get all the data transferred correctly. Enjoy!