Browse Tag: software development

A high level look at Angular 2

Developed by Google, Angular 2 is the newest version of the popular Single Page Application (SPA) framework. Angular 2 is a step in a new direction compared to previous versions, but has keep all the best characteristics and “lessons learnt” to deliver a fast, fully featured and rich ecosystem.

About Angular 2

Angular 2 impacts your whole application, or at the least, a section of it, rather than specific pages. Angular 2 is best suited to new (“greenfield”) development, as it can be relatively tricky to migrate legacy code (Angular 1.x code) to the new version. Angular 2 has new concepts, syntax, methodologies, and opinions, but is comparable to as previous versions in the way it works.

If you have been following Angular development since “the early days” of beta 1, then its been a very rocky road for you. Even now (this post was written around the release of RC5), the API is still evolving and new features are being added. Whilst this experience has been hard for early adopters, I believe the end result will be a fantastic, easy to use, and performant framework with a lower barrier to entry for all.


The purpose of this post is to discuss the core concepts of Angular 2. We’re not looking to dive into the details at this point, a follow up post on that will come later. We will discuss; pre-processors, build tools, components, dependency injection, interpolation, pipes, directives, event bindings, two way data binding, lifecycle hooks, routing, services and the HTTP client.

I have a side project on Github, named Angular2Todo, which is an Angular 2 todo application written with Angular 2, Universal Angular, and ASP .NET Core. If you’re interested in server side rendered Angular, please check that out.

This post is based on my own experience with Angular 2, and most of the knowledge has come from developing real world applications, including this one on Github.

Going forward, we will refer to Angular 2 simply as “Angular”. Old versions of Angular will be referred to by their version number explicitly.

TypeScript, Babel, ES6/ES5

It is hard to talk about Angular 2 without discussing TypeScript (See TypeScript playground for a live interactive demo). Angular was originally written using AtScript, which was an extension of TypeScript (TypeScript with additional functionality). However, after much collaboration between the Angular team and the TypeScript team, it was decided to use TypeScript exclusively instead.

Angular is written using TypeScript, however, you don’t necessarily have to write you Angular code using TypeScript, you could use; Babel, ES5 or ES6 if you prefer. If you are familiar with Google Dart, that is also supported.

I believe that Angular 2 applications are most commonly being developed using TypeScript, so I’ll use TypeScript throughout this post. If you need a summary of TypeScript, check out my TypeScript Beginners Guide on this website,

At a high level, TypeScript is JavaScript. You can convert all your existing JavaScript code to TypeScript as easily as changing the file extension from JS to TS. The most useful feature of TypeScript is its transpiler, which takes your TypeScript code (which is basically ES6), and converts it into ES5. Why would you want to do this? Most developers will want to utilise the new language features of ES6, ES7 and beyond, whilst not having to worry about cross browser compatibility. Support for ES6 is shaky at best on the desktop (Microsoft Edge, I’m looking at you), and very poor across mobile devices. TypeScript takes this pain away by converting your code to ES5, which is stable and does have excellent support.

Build tools

As we’re working with TypeScript, and potentially other tools as well, it makes sense to use build tools like Webpack or Gulp. Build tools can automate repetitive tasks, such as; transpiling the code (TypeScript to ES5), bundling (taking all your individual assets and merging them into one big file), minification (compressing that file for faster delivery to the client), and injection (referencing the new resource in the HTML).

Build tools can also watch your changes, and automatically build and refresh the browser automatically, so that you can focus on writing code and developing your application.

The Angular documentation, once you get beyond the absolute basics, encourages you to split your components (we will discuss these more next) into individual concerns. Your JavaScript, styles (CSS) and markup (HTML) are to be placed in individual files (component.js, component.css, component.html). This results in a lot of “chatter” between the client and server and can slow down the user experience (particularly on slower, mobile devices). Build tools can solve this problem by automatically injecting the markup and styles into your JavaScript files at compile time. This is certainly not a task you would want to perform manually!

Personally I have worked with both Gulp and Webpack when developing Angular applications. I prefer Webpack for how well it works, but I do not like the configuration aspect. Gulp is much easier to configure, but not as powerful (my feeling) as Webpack.

I have an example Gulp and Webpack configuration file on GitHub, that have both been used in real world applications.


Components are the basic building blocks of all Angular applications. Components are small and have their own state per instance (meaning you can reuse the same component many times on a single page without it colliding with other instances). Components closely follow the open standard for Web Components, but don’t have the same pain of cross browser support (the Web Components standard has not been finalised yet). Components are a group of directly related JavaScript (logic), CSS (style) and HTML (markup), which are largely self contained.

Components in Angular are defined using the @Component class decorator, which is placed on a class, and take “metadata” which describe the component, and its dependencies.

A component might look like this;

import { Component } from '@angular/core';
import { ROUTER_DIRECTIVES } from '@angular/router';

    selector: 'my-app',
    directives: [...ROUTER_DIRECTIVES],
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.css']
export class AppComponent {


This is ES6/TypeScript code. We create a class, called AppComponent using the class keyword. The export keyword makes the class “public”, so that it can be referenced elsewhere throughout the application.

The @Component directive takes an object that describes the component.

  • Selector: This is used in your markup. The selector is how you refer to the component in HTML. In this example, the code would be; <my-app></my-app>
  • Directives: These are other components that you want to utilise in the components markup
  • TemplateUrl: The path on the file-system to the markup
  • StyleUrls: A string array of all the CSS files used to style the component

There are many values that can be passed in here, the main values are displayed.

About styling

Why does Angular load the styles in this manner? Take the following markup (I’ve trimmed this slightly for simplicity);

    <td>{{asDate( | date}}</td>
    <td>{{asDate(calibrationDue.expiration) | date}}</td>

This is pre-compiled markup. The compiled, rendered markup looks something like this (again trimmed for simplicity);

<tr _ngcontent-dqf-10="" class="pointer">
    <td _ngcontent-dqf-10=""></td>
    <td _ngcontent-dqf-10="">Sep 29, 2014</td>
    <td _ngcontent-dqf-10="">Sep 29, 2016</td>
    <td _ngcontent-dqf-10="">AA11AA</td>
    <td _ngcontent-dqf-10="">John Smith</td>
    <td _ngcontent-dqf-10="">John Smith Transport</td>
    <td _ngcontent-dqf-10="">Ford</td>

Notice this rather auto-generated looking attribute that has been added to the markup? Well, it was auto-generated by Angular. The same attribute was also injected into the CSS. Why? to scope the CSS, to prevent it from having any effect on any other aspect of the site outside of the component itself. Any CSS you write in your CSS file, which is referenced by a component, cannot affect any other component or any other part of the site. The styles only affect the component itself. This is tremendously powerful and will result componentized CSS, but CSS that effectively does not cascade.

Angular 1.5+

Components were introduced in Angular 1.5 to help ease the transition (the upgrade path) from Angular 1 to Angular 2. If you are writing Angular 1 code currently and are looking to migrate to Angular 2 in the future, then consider re-writing your existing controllers into components to make your migration simpler in the future.

Dependency injection

Dependency injection in Angular is similar, in my experience, to dependency injection in many other languages/frameworks. Angular takes over managing the lifecycle of a components (or services) dependencies, and dependencies of those dependencies.

When you need to use a dependency, a service for example, you inject it into your component through the constructor. Dependency injection example;

import { Component, OnInit } from '@angular/core';
import { TodoStore, Todo } from '../services/todo.service';

  selector: 'app-footer',
  template: require('./footer.component.html')
export class FooterComponent implements OnInit {
  constructor(public todoStore: TodoStore) {

In the above example, our component needs to ues the TodoStore. Rather than creating a new instance of it inside the constructor, we add it as a parameter to our constructor. When Angular initialises our component, it looks at these parameters, finds an instance, then supplies it to the component.

Dependency injection in Angular is hierarchical. When the component needs a dependency, Angular looks to the components ancestors (parents, grandparents etc) until an instance is found. Depending on how you construct you application, dependencies can be (and probably will be) singletons. However, as dependency injection in Angular is hierarchical, it is possible to have multiple instances of the same service. When dependencies are defined at the “root level” of the application, the service will always be a singleton.

Angular takes care of initialising the dependency, and the dependencies of the dependency, so you only need to worry about using the dependency and not worry about managing it.

In the above code example, we are “referencing” each dependency using its type, therefore we don’t have to concern ourselves with making our code “minification safe”. In Angular 1, we define all our dependencies in a string array ($inject) so that Angular knows the names of each dependency at run time even after the code has been mangled. This step is no longer necessary.


Why would you want to handle dependencies in this way? Code complexity is reduced, and we can make our unit tests simpler. How? When using testing we can tell Angular to inject mock versions of our dependencies, to speed up the tests and ensure we’re only testing our own code and not Angular itself.

If you inject HttpClient into a service, for example, you would not want to make real HTTP requests to the server when running your tests. Instead, you inject a mock version of the HTTP client and simulate the request/response, for faster, consistent results.


Perhaps the most familiar concept in Angular, interpolation. Interpolation is the means of evaluating expressions, and displaying the results.

Take the following example;

<div class="view">
  <input class="toggle" type="checkbox" (click)="toggleCompletion(todo)" [checked]="todo.completed">
  <label (dblclick)="editTodo(todo)">{{todo.title}}</label>
  <button class="destroy" (click)="remove(todo)"></button>

The interpolation code is on line 4, {{todo.title}}. There is an object on the component, called todo. The object is a complex object, so it has many properties (and functions). In this case, we want to display the title of the todo to the user. Angular looks at this expression, determines the value of todo.title and renders it on the view. Whenever the value changes, that change is evaluated and displayed automatically.

You can display the results of practically any expression. Take another example; {{2+2}}. The result is 4, so 4 will be displayed on the view.

It is also permitted to invoke functions in interpolation expressions. The following code is perfectly valid;

{{ getTheCurrentDate() }}

As long as the component has a function called getTheCurrentDate, Angular will invoke it and display the result. You should avoid calling functions when possible as Angular will evaluate them more frequently than you expect, which can hurt performance when the functions do a lot of work. Instead, favour properties that do not change frequently.

Angular has a dependency on another open source project, called Zone.js. Zone.js handles change detection, and informs Angular when changes occur. Talking about Zone.js is out of scope of this post.


Pipes are usually used in conjunction with interpolation. Pipes, known as filters in Angular 1, are used to format data.

For example;

    {{todoStore.todos | json}}

The above code takes the array of todos, and converts it to a string and displays that result in the view.

The following are pipes built in to Angular;
* Async – Automatically subscribe to observables, which are used extensive in Angular (Angular has a dependency on RxJS).
* Date – Used to format a date object. For example; Sunday 21st August 2016.
* Percent – Used to display a number as a percentage, can pass in the number of decimal places to show.
* JSON – Used to “toString” JavaScript objects
* Currency – Format numbers as currencies ($10.99 or £10.99)

Notice there is no OrderBy pipe in the list, like there was in Angular 1. That is because ordering was a particular pain point in Angular 1. Because of the way that Angular 1 detected changes, the ordering would often occur multiple times, which when working with large data sets killed performance. The Angular team have excluded the OrderBy pipe in favour of ordering being done by your code, within the component or service.

There are some other less important pipes, but generally there is significantly less built in pipes than in previous versions. This was a deliberate choice to keep the code base lean and clean.

Structural Directives

Structural directives directly affect the structure, or the elements within, the DOM (Document Object Model). Structural directives can add DOM elements, remove them and modify them.

The most commonly used structural directives are;

  • ngFor, which is used to loop through items in an array
  • ngIf, which adds/removes an element to/from the DOM depending on the result of an expression

The syntax for structural directives is different from the norm. Structural directives are prefixed with an asterisk (*). Take the following code;

<footer class="footer" *ngIf="todoStore.todos.length > 0">
    <span class="todo-count"><strong>{{todoStore.getRemaining().length}}</strong> {{todoStore.getRemaining().length == 1 ? 'item' : 'items'}} left</span>
    <button class="clear-completed" *ngIf="todoStore.getCompleted().length > 0" (click)="removeCompleted()">Clear completed</button>

The structural directive is shown on line 1. *ngIf="todoStore.todos.length > 0". If the expression evaluates to true, then the footer is rendered, and all expressions within are rendered too. When the expression evaluates to false, the DOM element and all of its children are thrown away, removed from the DOM. This is to save Angular from having to evaluate code that the user is never going to see.

Below is an example of ngFor;

<ul class="todo-list">
    <li *ngFor="let todo of todoStore.todos">
        <app-todo [todo]="todo"></app-todo>   

On our component, we have a collection of todo, which contains zero, one or more items. For each todo in the collection, a new <li> is created. Angular scopes the <li> with the todo, so that any child element within the <li> can make use of the todo. In this example, the todo is passed to another component, called TodoComponent, whose responsibility is rendering single todo‘s to view.

In a nutshell, ngFor is a loop. Each iteration of the loop creates a new element which “knows” about the current item.

Attribute Directives

Next, we have Attribute Directives, which are responsible for changing the appearance of DOM elements. When using this square-brackets syntax, it “feels” like manipulating the DOM in JavaScript.

Consider the following code sample;

    <p [style.background]="backgroundColor">Hello,!</p>

The backgroundColor is a property on the component. In code, we can set the value of backgroundColor to be a color (yellow, or #ffff00 for example). The end result will be an inline style being applied, with the background property set to yellow.

Here is a screenshot on the compiled code at run time;

Angular 2 - Attribute directive run time example

You are not limited to manipulating the style of the element, you can change just about any property of the element.

Take another example;

<li *ngFor="let todo of todoStore.todos" [class.completed]="todo.completed" [class.editing]="todo.editing">
    <app-todo [todo]="todo"></app-todo>   

In this example, we are adding the CSS classes completed and editing to the element when todo.completed or todo.editing is true. Likewise, when false, the classes are removed.

Again, we could control the checked state of a Check Box (input field with a type of checkbox).

<input class="toggle" type="checkbox" (click)="toggleCompletion(todo)" [checked]="todo.completed">

When todo.completed is true, the Check Box is checked, otherwise, it is not checked.

Event Bindings

Event bindings are used to listen for user interactions, or events that get raised when the user interacts with the page or an element. Some events you may be interested in responding to; clicks, mouse moves, focus, blur, etc.

Event bindings are added to DOM elements and are denoted with brackets. Angular keeps an internal list of all the events it understands. If you try to listen for an event that it doesn’t map, Angular will look to your code instead (you can define your own custom events).

When an event occurs, typically a function on your component is invoked. You can pass arguments to the calling fuction, such as state, the event object, DOM elements, arbitrary values and more. It is also possible to pass state from one component to another using this mechanism.

Take the following example;

<label (dblclick)="editTodo(todo)">{{todo.title}}</label>

When the user double clicks on the label, the editTodo function is invoked. In this example, this element has a todo in scope, which is passed as an argument to the function.

Another example;

<input class="edit" *ngIf="todo.editing" [(ngModel)]="todo.title" (blur)="stopEditing(todo, todo.title)" (keyup.enter)="updateEditingTodo(todo, todo.title)"

In this example, we are responding to the blur event (when the control loses focus) and key-presses (enter, escape) so we can perform an appropriate action when the user presses these keys on their keyboard.

Two way data binding

Two way data binding is primarily used when binding input controls to properties on the component. When using a two-way data binding, when a user interacts with a form (types data into a text field) that change is automatically reflected on the component. Likewise, if a property that is bound to an input field is changed in code (either by the component itself, or by something else, say an Observable being resolved) that change is reflected in the view immediately. Two way data binding is a mechanism for synchronising data between the view and the component.

To utilise two way data binding, you use ngModel. The syntax for correct use of ngModel is known as the banana in a box syntax (click the link for a full explanation as to how the name came about).

In reality, the banana in a box syntax is an amalgamation of and attribute directive and an event binding (and combination of the two). Banana in a box syntax is syntactic sugar for two mechanisms being used together, which helps you write less code.

Take the following example;

<input class="new-todo" placeholder="What needs to be done?" autofocus="" [(ngModel)]="newTodoText" (keyup.enter)="addTodo()">

When the value entered into the input field changes, the property newTodoText is automatically updated.

Now consider the long hand version of the same code;

<input class="new-todo" placeholder="What needs to be done?" autofocus="" [ngModel]="newTodoText" (ngModelChange)="newTodoText=$event" (keyup.enter)="addTodo()">

A separate event is needed to assign the new value to the property on the component ($event).

By combining the attribute directive and event binding, the code is more readable. The less code we can write, the easier our application will be to maintain over time.

Lifecycle Hooks

Lifecycle hooks can be thought of as events that get raised at key points during your components lifecycle. Lifecycle hooks are callback functions that are invoked by Angular when the component is in various transitional events.

Put another way, lifecycle hooks help you to execute code at the right times during the initialisation and destruction of your components.

Lets say your component needed to request some data from a HTTP endpoint. Where do you put code like that? In the constructor? No, ideally the constructor should be kept as clean as possible and should only initialise variables at the most. Having your constructor do a bunch of work will probably make your application run more slowly. Ideally what you need is a “load event”. Lifecycle hooks provide this. Lifecycle hooks help you execute code at the right time.

The most commonly used lifecycle hooks;
* ngOnInit: The “load event”
* ngDoCheck: Raised when Angular is running its internal change detection
* ngAfterViewInit: Raised when the component view has finished initialising
* ngOnDestroy: Called when the class is being destroyed/cleaned up

Side note; TypeScript has a construct called interfaces. If you come from a .NET background, interfaces in TypeScript are the same as what you already know. For everybody else, interfaces can be best thought of as “contracts”, which promise that the class that implements the interface also implements all the properties/functions defined on the interface. If a class implements an interface, and that interface has a function defined called ngOnInit, then the compiler can guarantee that function has been implemented on the class. (If not, a compile time error is emitted). Angular exposes an interface, called OnInit, that has a single function defined, called ngOnInit. Implementing this interface is best practice, but not mandatory. Just having the function in your class is good enough.

Example usage:

import { Component, OnInit, Input } from '@angular/core';
import { TodoStore, Todo } from '../services/todo.service';

  selector: 'app-todo',
  template: require('./todo.component.html')
export class TodoComponent implements OnInit {
  ngOnInit() {
      //"load" logic goes here

Some time after the instance of the component has been created, Angular will invoke the ngOnInit function, assuming it exists, enabling you to run custom logic (and call that HTTP endpoint, if that is what you need to do).


Routing is how the user gets around your Angular application. Routing is navigation between views/components. State, in the form of parameters, can be passed between views and can be injected into your components. A route is a combination of a path and a component. Routes are referred to by their path in your markup using the routerLink attribute directive.

Example usage;

<a routerLink="home" routerLinkActive="active">Home</a> | <a routerLink="about" routerLinkActive="active">About</a>

The above code sample also shows the use of the routerLinkActive attribute directive. This directive applies a CSS class to the element it is applied to when that route is active. The routerLinkActive directive works in conjunction with the routerLink directive, so that when the route referenced by the directive is active, the custom CSS class (in this case, called active) is applied to the element. Typically, you would want to change the visual appearance of the DOM element to indicate to the user that they are on a particular page.

Routing in Angular has been on a roller-coaster ride of changes throughout the alpha, beta and release candidate (RC) phases. The current iteration of the router uses a hierarchical router configuration approach to define routes, child routes, and to enable deep linking. For the sake of simplicity, we won’t discuss hierarchical routing/deep linking in this post, but be aware that it can be achieved by having multiple route configuration files at different levels of your applications. Child routes are extensions of their parents route.

Router configuration

To define the main routes of the application, we create a RouterConfig object, which is an array of routes. Most routes consist of a path and component. Other routes can have additional properties, like wildcard routes, which decide what to do when the user navigates to a path that does not exist (using the redirectTo property).

Example usage;

import { RouterConfig } from '@angular/router';
import { HomeComponent } from './components/home/home.component';
import { AboutComponent } from './components/about/about.component';

export const routes: RouterConfig = [
    { path: '', redirectTo: 'home', pathMatch: 'full' },
    { path: 'home', component: HomeComponent },
    { path: 'about', component: AboutComponent },
    { path: '**', redirectTo: 'home' }

Here we have four routes defined;

  • Default route: No path is defined, so when the user hits the page with no route parameters, they are redirected to ‘home’ (defined next).
  • Home route: Displays the HomeComponent.
  • About route: Displays the AboutComponent.
  • Wildcard route (**): When the route is not recognised, the user is redirected to the ‘home’ route. This is a catch-all.

The RouterConfig object is then referred to in the applications bootstrapper (loads the application and its component parts, called bootstrap).

Example usage (some code omitted for brevity);

import { provideRouter } from '@angular/router';
import { routes } from './routes';

bootstrap(AppComponent, [

The provideRouter function is exposed by the Angular router, and takes the RouterConfig object we just created.

More router directives

Angular also helps control navigation with several additional directives.

  • routerOutlet: Tells Angular where to put the view/component (used within the application shell, typically the AppComponent).
  • CanActivate: Allows navigation to be cancelled (useful for restricting access to certain pages under certain circumstances, like trying to access a page when the user is not logged in).
  • CanDeactivate: Runs before the route is changed, and can also cancel navigation (useful when, for example, prompting the user to save changes they have made to a form).

Angular does not “just know” about these directives, as everything router related lives within its own module. You must import the directives into your AppComponent‘s directives array;

import { Component } from '@angular/core';
import { ROUTER_DIRECTIVES } from '@angular/router';

    selector: 'app',
    directives: [...ROUTER_DIRECTIVES],
    template: require('./app.component.html'),
    styleUrls: ['./app.component.css']
export class AppComponent {


The ROUTER_DIRECTIVES constant is a shortcut (an array, which includes all the directives previously discussed) to keep the code a bit cleaner.


To end on a lighter note, services a reasonably straightforward in Angular. Services are classes that have the @Injectable decorator applied to them. The @Injectable decorator tells Angular that the class can be injected into components/directives/other services etc.

Services are used to share and abstract common functionality between one or more components. Services can help reduce code complexity and duplication. Depending on the configuration of your application, (remember the hierarchical dependency injection?), services can be singletons and maintain state over the lifetime of the application. Services can also have their own dependencies, which is handled the same way as how dependencies for your components are handled.

Example usage;

export class TodoStore {
    //Implementation omitted   

I like to use services to add additional abstraction to some built in Angular services. Why? If the Angular API changes (and it has changed a bunch in the past), I have a single place where I have to make changes and get back up and running quicker.


Angular 2 is an opinionated web application framework for developing single page applications (SPA’s), and is actively developed by Google. Angular 2 is a move away from the original framework, it introduces and syntax’s and a “new way of doing things”. Important problems with past versions have been overcome (change detection/dirty checking was a major flaw of Angular 1) and the framework is taking a new direction. Whilst it is possible to write Angular 2 code in many ways, the preferred approach is to use TypeScript. There is a learning curve involved, the tooling especially is very much in its infancy, but once over the initial hump Angular 2 can be a fantastic framework when used in the manner it was intended for.

Why I don’t want to be a front-end web developer

The job title isn’t representative of my skill set

As a front-end developer, you portray yourself as having a narrow set of skills. This probably isn’t the case.

I did a quick search on a popular job forum for front-end developer jobs, and there is a clear recurring theme as to what skills are required to be a mid-level/senior front-end developer;

  • Backbone, Angular, Knockout.
  • Responsive web design (I’m assuming Bootstrap knowledge, Foundation etc).
  • Adobe Photoshop, Magento.
  • Knowledge of source control and some form of client side unit testing.

My perception of these skills;

  • HTML has remained relatively unchanged since it was invented in 1990. If you don’t agree, just take a look at the source code for the first web page. HTML is easy, whatever the flavour. That’s actually is greatest strength, no barrier to entry for new developers.
  • CSS is easy to learn, impossible to be great at. Thankfully tools such as SASS/SCSS and LESS are eliminating the pain. A web developer of any skill level and experience can learn to use these CSS pre-processors in 60 minutes or less. They’re simple. They just work.
  • If you’re good at responsive web design, this is a valuable skill. Thankfully, if, like me, you’re not strong with design… front-end frameworks, such as Bootstrap and Foundation, help most developers sweep this skill gap under the rug.
  • Photoshop is in a world of its own. Its ridiculous level of complexity is only matched by its mind boggling feature set. Kudos if you can even get it to install and run.
  • Source control. All you need to know; git push and git pull.

These are, of course, tongue-in-cheek observations. What I’m trying to say is that a full-stack developer can be strong in all of these areas with minimal exposure and experience. These are not specialist skills. This generalisation I think applies to JavaScript development too. After 3 months of constant exposure to AngularJS, for example, you should have a good (if high level) understanding of how it works, how to use it, when to use it, and most importantly, when not to use it.

I don’t want to be a front-end developer because I have broader range of skills and I don’t want to undersell myself.

From a consultants perspective

Portraying yourself as a front-end developer might make sense in the short term. Developers in general at the minute are in high demand. In the UK especially there is a clear skills shortage, so presenting the image of being an expert or specialist in this field might help you land a lucrative role.

Rather than pitching as a front-end developer, however, I see more value in pitching yourself as a front-end developer with extenstive full-stack experience. That way you’re still ticking the boxes on the potential employers checklist, whilst making clear that your skill set goes much deeper.

Front end development is moving too fast

Sorry but it is. It feels like every day there is some new shiney JavaScript framework or “must have” tool that I “must have” (although if I really “must have” it is often debatable). The web is becoming more and more mature as a platform and I see this trend continuing, but we’re still some way away from being there. Yesterday all the cool kids were using PHP, then ASP .NET MVC, then AngularJS/KnockoutJS/WhateverJS. Tomorrow, ReactJS will (probably) be the framework of choice (or perhaps Aurelia will emerge as a viable competitor).

There is also and endless list of web development tools; Visual Studio, Code, Sublime, Webstorm, Dreamweaver (joking, who uses that?!), Eclipse, Netbeans, arguably Notepad++, VIM, EMACS … and infinitely more.

The net result is that I’ve spent literally hundreds of man hours learning FrameworkX (and probably a decent amount of money too) just for it to be superseeded or even die a painful death literally overnight. (Silverlight…remember that?, AngularJS 1.x according to many). It often feels like despite my best efforts, and regardless of how many hours of effort I put into my own education, my skill level is actually declining.

The pace needs to slow down and things need to stabilise before I can even consider specialising as a front-end developer.

I don’t want to be a front-end developer because I can’t (and don’t want to) half kill myself trying to keep up with the trend setters.

Front-end developers are probably not designers

I’ve found through experience that generally technical people fall in to one of two categories. I agree that this is not true in all cases.

  1. You are either a logical thinker aand prefer to write code
  2. You understand how to make things look beautiful.

Typically you don’t get too many coders with excellent design skills and vice versa.

Speaking personally, I’m a strong coder and always have been. I can scrape by when it comes to design, usually be utilising frameworks such as Bootstrap or Foundation, but I don’t excel at this.

There is a perception that front-end developers are good coders and good at design (take a look at the aforementioned job advertisement skill list, specifically the mention about Adobe Photoshop knowledge). Employers are hiring front-end guys and expecting them to be good at writing code and designing pretty websites. I think this is a mistake and the roles should be seperate.

I don’t want to be a front-end developer because I’m not a strong enough designer, and don’t claim to be. Employers have unrealistic expectations about what they will get from a front-end developer.

Front-end developers earn less money

Its true.

Developer vs Front-end Developer

£10k difference. That’s quite a gap. And that’s just one example.

I don’t want to be a front-end web developer because I want to reach my full earnings potential.


I don’t want to be a front-end developer because I don’t want to undersell myself, because I want to reach my full earnings potential, and because I don’t want to half kill myself trying to keep up with industry trend setters.

Agree or disagree… leave a comment.

Every developer must be proficient at these 7 things…

In 2015, it is as important as ever for developers of all levels of expertise and experience to re-train and update their skills.  In the fast moving world of technology, failure to do so can result in career stagnation and ultimately not reaching your full earnings potential.

This post is an update to the popular post 10 things every software developer should do in 2014.  All of the points made in that post are still relevant and valid so I recommend you take a look.

This post is entirely based on my own opinion and I highly recommend you use this to figure out your own learning plan, based on your own level of skills an expertise.

1. Source Control

Lets start simple.  You must be using source control.  There is literally no excuse.

99% of companies today are using some form of source control, and its becoming expected that you have at least a basic understanding of how source control works.  Most source control systems have the ability to create branches, view history, merge changes, and display differences between revisions.  You should be familiar at least at a high level, how to perform each of these actions in at least 2 different solutions.

As a minimum, I strongly recommend that you learn how to use the basics of Git and TFS Version Control (TFSVC), as these seem to be the most popular in most circles today (especially if you are a .NET developer.

You may also want to learn more about SVN and Mercurial just to ensure that you have most bases covered.


2. CSS Pre-processors

There is a lot of debate on the web about CSS pre-processors and if you should/shouldn’t be using them.

Lets rewind a second. A CSS pre-processor is basically a scripting language that is complied down into plain old CSS by some external tool.  The scripting language is typically an abstraction that can reduce the complexity of the underlying CSS and add additional features.  The scripting language compiles into plain CSS, which a web browser can understand.

The general argument about CSS pre-processors between developers is that CSS should be simple and if your CSS is not simple, then your doing it wrong.  If your CSS is simple, then a pre-processor should be redundant.

My argument is that whilst this is generally true for very small applications, once you start working in a team where everybody has their own way of doing things, or the application generally starts getting larger, then this breaks down.  You usually end up with super long CSS files full of duplication and even worse, inconsistencies.

There are three main CSS pre-processor players; LESS, SASS, Stylus.  The main goals of each of these projects is as follows;

  1. Reduce length and complexity of CSS files.  Usually through partials that are merged together at compile time.
  2. Reduced maintenance through less duplication.
  3. To organise your CSS through nesting.
  4. To introduce variables and operators for calculating sizes etc.

I personally am I big fan of both LESS and SASS, and I’m currently migrating from the former to the latter.  I highly recommend that you have at least a high level of understanding of one or the other.


3. JavaScript Supersets/Trans compilers/Pre-processors

Fundamentally the same as CSS pre-processors.  A JavaScript pre-processor is a tool that provides you with some higher level language that ultimately compiles back down to JavaScript.

I’m particularly fond of TypeScript right now.  TypeScript has a slightly steeper learning curve than something like CoffeeScript or LiveScript.

Some features of TypeScript;

  1. Static typing…l types are known or inferred, so compile time checking informs you of any errors.
  2. Strong typing…prevents incompatible types from being passed between functions.
  3. Familiar constructs such as classes and interfaces.
  4. Reduced complexity compared to plain JavaScript.
  5. Decent IntelliSense (if you are a Visual Studio developer), even for third party libraries.

At this point, I feel that JavaScript pre-processors are still in their infancy.  I would still strongly recommend learning JavaScript in its pure form as it will no doubt still be around for at least the next 10 years, but if you can, have a look at TypeScript or CoffeeScript.  I suspect both will grow exponentially over the next year.


4. Your primary (code) language

This (might) be a slight generalisation, but most people feel most comfortable when writing one or two languages.  That doesn’t mean they’re not very good at other languages, but that generally they learnt to write one or two languages in particular before branching out.

Personally my first programming language was VB 6 way back in the day, but since then I’ve spent most of my time writing C#.  Whether it be Windows Forms, WPF, ASP .NET or just general back end development.  I know that I can achieve anything I want with C# with relative ease.  When I’m having a conversation with peers, or interviewers, or whomever I’m talking to at that time I’m secretly hoping that they will ask me questions about C# so that I can demonstrate my knowledge.  I have completed many Microsoft exams and gained a tonne of accreditation in the subject.  More importantly I have completed dozens of projects for customers, clients, colleagues and friends so I know how to see it through to completion.

My point is, you should have your own C#.  It doesn’t have to be C# it can be whatever language you want.  JavaScript, HTML, Ruby, Java, C++, or anything you like.  The point to take away is that you should know a language inside out, including its strengths, weaknesses, and especially when you should and shouldn’t use it.

Probably the best way you can really master a language is to start teaching it to others.  You might want to write a blog, give presentations to your colleagues, or attend local user groups and share your knowledge to strangers.  Teaching forces you to look at something thoroughly and in-depth to broaden your understanding, mostly because of the fear that if you don’t you will be caught out by a tricky question from an audience member.


5. How to interview well and how to make your CV stand out

This one is so obvious, I almost didn’t include it.

You would be amazed at how many developers submit CVs to potential employers littered with spelling mistakes, incomplete or untrue information, and just plain messy by design.

I don’t claim to be an expert in this field.  I have been for a lot of interviews and I have sent my CV to many, many employers.  I have also had a lot of feedback from friends, family, recruiters and indeed interviewers too.

Here are my top tips for a solid CV;

  • Get the basics right.  Ensure you CV is 100% free of spelling and grammatical errors.  Even the smallest mistakes will guarantee your CV is relegated to the bottom of the pile.
  • Keep the design simple.  Personally I use only a single font face, with 2-3 different sizes and minimal formatting. If you are more design oriented, you might want to do something a little more creative, and that’s fine too…but don’t be too creative.
  • Don’t tell lies.  You will be found out.
  • If you are including links to your portfolio, make sure those links are appropriate to the job your interviewing for.  No potential employers want to see your Geocities website from the late 1990’s.  (Yes I’ve seen somebody actually do this! Needless to say, they didn’t get hired)

As for interviewing, again its all in the basics.  Make sure you prepare well before the interview, read the job description thoroughly and think about what skills/experience you have that the company are specifically looking for.  And as you are a developer, you’ll probably want to brush up on your technical skills too, and read some common interview questions so that you aren’t caught by surprise.

For more information on how to boost your career, I highly recommend checking out an awesome book by John Sonmez, Soft Skills: The software developer’s life manual.


6. Relational database alternatives

I’ve touched on this previously in a related post, 8 things every .NET developer must understand.  However, I cannot emphasise the point enough.

Relational databases are not the be-all-and-end-all.  Its not sufficient in todays world to only having an understanding of Microsoft SQL Server or MySQL databases and how they work.  More and more companies are relying on No-SQL databases to improve performance of persisting and retrieving highly volatile data.

No-SQL databases typically lack any formal structure and typically consist of some sort of list of key-value pairs.  At first this may seem a bit bizarre, but there are many benefits to structuring data like this;

  • Easy to develop with.  Either no or few joins.  No complex new language to learn.
  • Horizontal scaling
  • Schema-less
  • Supports large objects
  • Low or no licensing costs.

For a more comprehensive look at the benefits of No-SQL databases, take a look at Adam Fowlers blog post on the subject.

RavenDB, MongoDB, and Windows Azure Blob Storage are the big players at the minute.  Each has a relatively low learning curve and are becoming widely adopted by companies.  I would suggest you take a look at each.


7. DevOps

Another industry buzz word that seems to be confusing people, myself included.

What is DevOps? Simply put, an effort to improve collaboration between the software development and IT support teams (referred to as operations).

Traditionally, the role of the software development team within a company is to develop new functionality and generally “make changes” to a system.  That system might be internal or external, and it might be desktop or web based software.

The role of operations is to ensure stability of systems.  The biggest risk to stability is change.

DevOps is a concerned effort to improve the way in which the two teams communicate with each other to ensure continuous deployment whilst minimizing disruptions.  We have in the past, myself very much included, typically taken the attitude that once we make a change or develop a new feature and commit to source control then its “done”.  Its then becomes operations responsibility to deploy the change and “handle that side of things”.

You should at least know what DevOps is, and how you can get more involved in it within your own company.  If your company does not currently employ a DevOps mentality, perhaps you could introduce it.  Get rid of the “them vs. us” culture and gain some respect in the process.

I highly recommend look at What is DevOps by Damon Edwards on Dev2Ops for more information.



2015 is yet another year of rapid change for our industry and developers alike.  There are clear trends towards pre-processors, non-relational databases, JavaScript frameworks, cross platform development should not be ignored.

8 things every .NET developer must understand

You’ve been in your current job for a while now, and you’re really starting to get good at what you do.  You’re perhaps thinking about finding something new, and you’re wondering what sort of questions a potential new employer might ask.  I’ve been interviewing a lot recently and I have noticed there are 8 questions that get asked a lot.  Spend some time and make sure that you understand each point in turn, doing so will help make that dream job become a reality.

SOLID Principals

The ultimate acronym of acronyms.  You’ve heard of it, but do you know what it stands for? Do you really understand what each principal means? Yeah thought so.  This awesome video by Derick Bailey will clear things up a lot for you;

Garbage Collection & IDisposable

One of the best features of developing with any .NET language is the lack of effort you have to put in to garbage collection.  You generally don’t have to care too much about 1st/2nd/3rd gen collection cycles, de-allocating memory or anything like that.  Its still a very important topic, however, and every .NET developer should understand how it works.

Once you become a more experienced developer (and I’m especially talking to WPF developers here) you quickly learn that memory management isn’t a forgotten topic.  Failure to unsubscribe from events, failure to close streams, and keeping hold of large objects (say instantiating them in a loop that never ends) is a sure-fire way to balloon up your apps memory usage eventually resulting in a crash (commonly referred to as Memory Leaks).

A useful way of ensuring that managed resources are correctly cleaned up in a timely manner is to implement the IDisposable interface (and actually use it within a using block) on your objects.  Make sure you understand how this works how to implement it.


private Boolean disposed;

protected virtual void Dispose(Boolean disposing)
    if (disposed)

    if (disposing)
        //TODO: Managed cleanup code here, while managed refs still valid
    //TODO: Unmanaged cleanup code here

    disposed = true;

public void Dispose()


Code snippet taken from SideWaffle.  Its not enough to simply implement IDisposable, you have to take it a step further by adding a second Dispose method to ensure that both managed and unmanaged resources are properly disposed.

Useful resources:

Three Common Causes of Memory Leaks in Managed Applications (DavidKlineMS)

Garbage Collector Basics and Performance Hints (MSDN)

Writing High-Performance .NET Code (Ben Watson)

Explain why you might use MVC over WebForms?

Another curve ball that employers might throw at you is “Why might you decide to use ASP .NET MVC over something like WebForms”.  I stuttered for a good 30 seconds before I eventually came up with a decent answer to this one, because simply saying “because MVC is better” is not a good enough argument.

Here are some things that come to mind;

  • MVC generates much simpler HTML code, which will be easier to style and maintain over time.
  • MVC arguably has a smaller learning curve, because Razor is very intuitive and developers get to reuse their existing knowledge of HTML/CSS without having to learn how specific user controls work.
  • Due to MVC’s simplified page lifecycle, overhead on the server is reduced potentially resulting in better performance.

There is endless argument about this on the web (the only example you need). I think in reality the employer is trying to establish two things here;

  • How well do you know your frameworks
  • But more importantly, can you assess the benefits and drawbacks of different frameworks and make an informed, unbiased decision regarding which one to use.  I.e. don’t just use it because everybody else is.

No-SQL databases

If you think that SQL server is the be-all-and-end-all, then its time to wake up! Its the year 2014 and the tech world has moved on.  I’m not suggesting for a second that companies are abandoning SQL Server, I believe that it will continue to play a major role in our industry for at least the next 5 years.  However, No-SQL databases are gaining massive traction because of their general speed, ease of use, and scalability benefits (not to mention the fact that SQL Server is very expensive, whereas RavenDB and MongoDB are much more affordable).

I’d recommend that you look at, and understand, each of the following;

Boxing and Un-boxing

It simply amazes me just how many developers don’t understand boxing and un-boxing.  Granted, its been less of an issue since generics was introduced in .NET 2.0 but done wrong, your application’s performance and memory usage will be seriously affected. 

Useful resources:

Also note, when a prospective employer asks you to explain this problem, they may also ask you to explain the difference between reference types and value types.  Reference types of course are classes, whereas value types are structs.  A value type can be thought of as the actual value of an object, whereas a reference type typically contains the address of the actual value, or null (value types are not nullable).

Hoisting and Closures

Developers now are required to have a broader range of skills than has typically been the case.  Its usually not enough to have just SQL and C# on your CV, employers are increasingly looking for more well rounded developers, with a range of skills including (but not limited to); HTML, CSS, JavaScript, KnockoutJS, TDD, AngularJS and so on.

You may never have realised it, but when writing JavaScript code variable scope is not exactly black and white.

Take the following example (pinched and adapted from here)


    x = 5; 

    var x;


What is the value of x? No tricks here, the answer is of course 5, but why does this work?  Because the variable declaration is pulled (hoisted) to the top of the current scope.  So regardless of where you declare your variables inside a function, they will always be hoisted to the top.  Be sure that you understand this, as its a basic concept but often misunderstood.

Similarly, closures are another confusing concept of JavaScript that you may be asked about.  In the simplest terms, when you have a function inside another function, the inner function has access to any declared variables in the outer function. 



    var x = "Hello";

    var f = function(){
        alert(x + ", World!");



What is the result? Hello, World! of course, again no tricks.  The code in the inner function always has access to variables declared in the outer function.

That explanation should pass the Albert Einstein test.

If you can’t explain it to a six year old, you don’t understand it yourself.

Is a string a reference type or a value type?

The one I used to dread the most, until I learnt it properly and understood it.  A string is a reference type, but it behaves like a value type!  Unlike most other reference types, a string is immutable, meaning that the object itself cannot be changed.  When you call a method such as Remove or Substring, you are creating a copy of the string with the new value.  The original string remains intact until it is de-referenced.

The primary reason for this is because the size of strings means that they are too big to be allocated on the stack.

As a side note, take the following code;

string c = "hello";
string d = "hello";

Console.WriteLine(c == d);

Why is the result true?  Well this is a .NET optimization to reduce the memory footprint.  Under the hood each variable has the same pointer (0x021x15ec in this case) to the actual value.  You should always use String.Equals when comparing strings to ensure that the actual value of each string is equality checked, instead of the pointer.


We looked at 8 concepts that every decent .NET developer should understand, especially when interview for a new role.  Whilst these may seem like simple concepts, they are often misunderstood and this will quickly be picked up by even the most inexperienced interviewer.  It’s important for .NET developers to know their language and their tools inside out to ensure that they have every chance of landing that next dream job.

Publish your website to an IIS staging environment using Microsoft Web Deploy

One of the simplest and quickest ways to publish your website to a staging environment is, at least in my opinion, using Microsoft Web Deploy.  This post is about how you approach this, a future article will discuss why you probably shouldn’t do this.

Key points;

  1. The remote server should be running Internet Information Services (IIS) 7.0 or later.
  2. You can use the Microsoft Web Platform Installer to install all the extra bits you need to make this work.
  3. You need to set appropriate permissions to allow remote publishing.

Windows Server 2012 R2

On my local machine, for testing purposes, I have a Windows Server 2012 R2 virtual machine which is bare bones configured.

The first thing you need to do is install IIS.  You can do this using the Server Manager;

Open the Server Manager > click Add roles and features > select Role-based or feature-based installation > select the target server > and finally, select Web Server (IIS) and Windows Deployment Services.  Feel free to drill into each item and ensure you have the following selected (as well as whatever the defaults are);

  • Basic Authentication (very important)
  • ASP .NET 3.5 / 4.5
  • .NET Extensibility 3.5 / 4.5
  • IIS Management Console and Management Service (very important)

Once installed, you should be able to open IIS Manager by opening the Start menu, type inetmgr and press enter.

When IIS Manager opens (referred to herein as IIS), you should be prompted to download Microsoft Web Platform installer.  Ensure you do this.  Use the Web Platform installer to ensure you have all the following installed;

  • IIS 7 Recommended Configuration
  • IIS Management Service (should already be installed)
  • IIS Basic Authentication (should already be installed)
  • Web Deployment Tool (The current version is 3.5 at the time of writing, I also like to install Web Deploy for Hosting Servers as well)
  • Current version of the Microsoft .NET Framework
  • ASP .NET MVC 3 (as we will be publishing an ASP .NET MVC website)

I like to do a restart at this point, just to ensure that everything is tidied up (although I don’t think its 100% necessary, just ensure you restart IIS at the very least).

Enabling web deployment

The next step is to “switch on” the web management service.  This will allow remote users to connect up and deploy the website.

For the sake of simplicity, we will use basic authentication.  There are other means of authenticating users, but that is out of the scope of this tutorial.

AuthenticationIn IIS, select the server level node and then select the Authentication module (under the IIS grouping).

Simply right click on Basic Authentication, and the click Enable.

Next we need to configure the web management service to accept incoming connections.  Again, select the server level node, and select Management Service.

If the management service is already running, you need to stop it before continuing.  To do this, go to the Start Menu and type services.msc.  This will open the Services manager.  Search for Web Management Service, right click, and click Stop.  I ran through this process twice from scratch and the first time the service wasn’t running and the second time it was.  I not sure what triggers it to run.

Tick Enable Remote Connections and feel free to accept the default settings for now.  You could always revisit this later.  Click Start on the right hand side to start the service.

Configure your website

I’m sure you’ve done this many times before, so I will not regurgitate the details here.

Add a new website, give it a host name if you like, and specify the physical path (remember this).  Please ensure that you set the application pool to .NET CLR Version 4.0.30319 to avoid errors running the website further down the line.

Set the appropriate permissions for IIS_IUSRS

IIS requires read permissions to access the files that make up your website.  The simplest way is to head over to the physical folder for your website (that path you’re remembering from earlier), right click the folder, click Properties > Security > Edit > Add.  Type IIS_IUSRS then click Check Names.  Click OK, then OK to close the properties windows.

Create a Web Deploy Publish Profile

Finally, you can create a web deploy publish profile (simply an XML file with a few basic settings)  which you can import into Visual Studio to save you the hassle of having to type anything.

imageHead back over to IIS, right click on your website, click Deploy > Configure Web Deploy Publishing.

You can (and definitely should) create a restricted user account and grant permission to publish to that account (either an IIS account of a Windows authentication based account).

Once you have selected a user, click Setup.  A message should appear in the Results text area;

Publish enabled for 'WIN-DLICU73MRD0Jon'
Granted 'WIN-DLICU73MRD0Jon' full control on 'C:inetpubwwwroottestwebsite'
Successfully created settings file 'C:UsersJonDesktopWIN-DLICU73MRD0_Jon_TestWebsite.PublishSettings'

Success! This is your publish profile that you can import into Visual Studio.

Import your publish profile into Visual Studio

To import your publish profile, open your web solution and from the Build menu select Publish [your website].

PublishWebOn the Profile tab, click Import… and browse to the publish profile you just created.  Once imported, switch to the Connection tab and type the password for the account you selected earlier on the Configure Web Deploy Publishing dialog you saw earlier.

If you’re feeling lucky, hit the Validate Connection button.  All should validate properly.  If not, please refer to this little hidden gem from the IIS team to help troubleshoot any error messages you might be receiving.

Browse to your website using the host name you specified earlier (don’t forget to update your hosts file if you are “just testing”) and congratulations, after the initial feels like a lifetime compilation period, all should be good.

Next time you’re ready to publish, simply open the Publish dialog in Visual Studio, go straight to the Preview tab and hit Publish.  No more manual deployment for you my friend!


The Microsoft Web Deployment tool is a quick and convenient way to publish your website to a staging area for further testing.  You use the web deployment tool to generate a publish profile which can be imported into Visual Studio (saving you the hassle of having to type all that connection info)  and then call that service and pass it a package which will automatically deploy your site to the appropriate folders.