Home

I’ve many a time asked myself the question: “What Makes a Great Front-end Developer?” – its quite frankly a loaded question, even at first glance.

The position of Front-end Developer is gradually becoming more and more broad. In my own career alone, Im constantly finding that I’m transitioning more and more to the backend: Setting up virtual machines, updating apache, configuring SSL certificates, the list goes on and never seems to get bored of itself. Its can be really daunting.

So, now that the lines are blurred, how do you measure the skill-set and experience of a true Front-end Developer? Are they specific to the front-end? Or should they maintain and nurture the skills required to understand important back-end functionality as well. That’s what I’m here to discuss, so let’s get into it!

An all rounder

I’ve always seen true back-end developers as incredibly knowledgeable. The more experience they have behind them, the more they tend to amaze you. That being said, they seem to be almost “stuck” on some level when it comes to being complete all-rounders – they shiver at the thought of HTML markup and CSS and the fact that it needs to be arranged and structured in such a way that makes for a pleasant user experience. Forgive me if I seem to be generalising here, but for the most part, back-end developers are only concerned with one thing: functionality.

As a front-end developer I’ve always felt that I’ve had to account for aesthetic as well as functionality. Think about it for a minute. Building an AJAX contact form is about as functional as you can get. JS passing to PHP, passing back to JS etc,etc. Its not there to make you feel like you’ve contributed to making the site aesthetically pleasing, more a way of introducing sleek and seamless interfacing and functionality to the user, thus contributing to the user experience. The example I’ve provided is just one occurrence of this.

Front-End Developers, having learnt HTML, CSS and JS, are forced to take functionality into account when creating user experiences or making sure that the two disciplines work as one from a development perspective. They become all-rounders, having to understand what is actually happening between the AJAX data and the PHP file that’s sending off a mail or returning errors.

A good Front-end developer understands this relationship and can see functionality, interface and aesthetic as 3 different entities that combine to provide one great experience.

Conveyers of Meaning or Conveyers of Code?

Front-end Developers don’t quite seem to fit into the programming boat do they? Or do they? Javascript is a programming language is it not? If you can program Javascript does it make you a programmer? Well, I don’t know to be honest. The web world is changing. Knowing Javascript now for interaction design, web apps, even databases has become possible very quickly. Isn’t it fascinating that now, a front-end developer with plenty of experience with JS can take his web projects / skills / ideas to life without the need of PHP or MySQL? One language that can suffice for the back-end and front-end for the development of sophisticated and light-weight web apps. I think that makes you a programmer. Its often said that HTML and CSS are not programming languages. They most certainly do not meet the functional specifications to be programming languages.

That being said, i’ve always thought that when it comes to semantics (HTML) and aesthetic / colour / layout (CSS) – you are in fact programming on some higher level, after all, programming is about logical instructions to a computer that has no real way of understanding other than compiling that information into binary. With HTML and CSS we’re programming structure, scaffolding and meaning to a world of human beings that need to take from it the intended communication, the instructions and compute / compile that in their own minds which are filled with way more arbitrary information than a machine…food for thought.

I think what makes a great Front-End Developer is the fact that they can have deep programming experience, yet can still see where programming and user-experience meet. Its such a fine line, and the lines constantly blur, but being able to decipher those blurs is where true talent lies.

Automation

Programmers are nifty. A truly seasoned developer will know that having the choice of performing manual tasks compared to writing a script that will automate them is where the gold lies. We see it every day, from version control, continuous deployment and unit testing.

A good Front-end Developer should take this into account with his own workflow. While using the Front-end Stack, developers haven’t had much to play with in terms of automating tasks as this usually happens on a server of some kind. With the addition of Node.js and NPM this has dramatically changed. Packages like Gulp, Grunt and Bower have made some huge automation changes to our workflows. Automatic browser refresh, SASS to CSS compilation, minifying, concatenating and more. It saves untold hours.

A great front-end developer knows what tasks take time, and find ways to optimise them. Most importantly the redundant ones like refreshing the browser after saving. This is especially important when it comes to Git and version control. I’ve seen Front-end developers build amazing scripts, frameworks and scaffolds that speed their projects along, whether its boilerplates, SASS variable guides or scripts that automatically fill in accessibility attributes. 

The SEO-miser

I’ve seen plenty of Front-end developers get serious slack for this. Most of the time they are to blame for poor markup, and its really something to take into account when developing. The essential rules and principles of HTML are often forgotten. Semantics go out the window and developers get a mild case of laziness because who’s really looking at your code right? Well Google is, and Google doesn’t like you very much for being lazy. The semantics and information hierarchy of HTML is not to be taken for granted. Its a front-end developers responsibility to make sure that meaning is conveyed in the most semantic way possible. If not, what are you really trying to do?

A great front-end developer can begin a project with a number of facets in mind:

– meaningful semantics

– A clear information hierarchy

– Easy, accessible content

You can see with in minutes when a lazy developer has taken charge. Great developers follow guidelines, follow structure, follow the purpose of HTML, create clear, semantic, structural information for both humans and robots alike.

Forever Learners

Often, Front-End Developers are left with more than their skill set even allows for. Sometimes moving a site over to a server doesn’t work? Maybe the .htaccess has a strange rewrite rule? What the hell is the .htaccess anyway? Its seemingly obvious, yet seemingly subtle issues like this is what determines your truly great front-end developers. You spend hours researching concepts, functions, and more on topics that you didn’t even know existed. Acronyms popup all too often relating to server scripts and work-arounds. Its truly overwhelming. That being said, a great front-end developer doesn’t shy away from this. They put their most important organ into first gear: Their brain. That smart organ that has got them this far, allows them to look at the situation as not so much as problem but something to be learned, to be gained and to conquer, so that next time they won’t ask for help or spend hours on Stack Overflow looking for losely related answers.

A truly great Front-end developer knows when not to quit, when not to give up, when to learn, when to conquer and when to persevere through a lot of uncharted territory that is constantly facing them.

In this post, I’ll show you how to get Grunt up and running with regards to your front-end web development. I’ll take you through the whole process and make your development a hell of a lot easier. What’s more, I’ll show you how to manage the files that Grunt outputs with Git in mind so that you don’t “git” those nasty merge conflicts. Grab a coffee, sit back and let’s do this.

Installing Grunt

First things first, you need to install Grunt, Grunt runs off of NPM so if you don’t have Node or NPM installed, here’s how:

Node.js

Visit: https://nodejs.org/en/download/ – select your operating system and download the installer. If you’re on Mac OS X it will be a .pkg file. Once done, simply double-click and let the installer do the hard work. It may take a bit of time, but it’s usually pretty quick. To verify that Node is installed, fire up your Terminal and hit:

node -v

If its successful, the Terminal will return the version of node you have installed.

P.s if you have trouble installing the next part, prefix the commands with sudo – this allows the terminal to run as administrator, and will ask you for your password if necessary.

Fantastic. Next up is NPM.

NPM

NPM is a package manager for Node. Much like Bower for Front-end dependencies like jQuery or Bootstrap or Composer for PHP. Moving on! Let’s get NPM running, we’ll install it globally so you can use it from within any folder on your system, if you still have the command line open, type:

sudo npm install npm -g

This will install NPM on your system. Plenty of libraries require NPM, so its a great tool to have installed on your system even if you don’t think you’ll use it all that much.

Grunt

So what exactly is Grunt? In its most basic form, Grunt is a Javascript Task Manager, it lets you automate and run a bunch of redundant tasks that front and back-end developers really don’t want to do every 5 minutes. It runs off of NPM and its core files are written in Javascript and JSON.

We’ll want to install Grunt globally much like we did NPM, so go back to Terminal and type:

sudo npm install -g grunt-cli

This installs Grunt globally and allows you to run it from the command line.

Alrighty, we now have all our dependencies (Node, NPM) as well as Grunt installed and we can get into the nitty gritty work. Before we move on, it’s important to understand how Grunt works, so we’ll cover that next.

How Grunt Works 

Grunt uses two files right from the get go. Namely package.json and Gruntfile.js. The package.json contains meta-data about the project such as name, version, npm dependancies, authors and more. We’re going to write our own one in a bit. The Gruntfile.js is where we call the package.json and initiate settings and what are called “Grunt plugins” to make sure they do what we need them to do. Once we have set this all up, all we need to do is cd (change directory if you’re a noob at the command line) into the folder we’re going to create and type:

grunt

…into the command line and Grunt will start working its magic.
Before all this can happen we need to make sure our package.json is filled out as well as our Gruntfile.js. We’ll start with a simple empty directory.

1. Fire up Terminal if you haven’t already got it running.
2. Make sure you’re in the Home folder of your computer, it will most likely be named after you. If you’re unsure, type pwd (present working directory) and it will give you a file path as to where you are. Mine currently says /Users/Daine
3. Next, we’ll change directory into the desktop, so type: cd Desktop
4. Next, lets create a folder to store our files, type: mkdir yourfoldername
5. Finally cd  into your new folder, type: cd yourfoldername

P.s yourfoldername here is obviously whatever name you choose.

Cool. Lets do some grunt work.

Package.json

Im going to show you how to create a package.json using the command line, it provides a nice walkthrough for you. Once you’ve done this process once or twice, just duplicate your package.json for future projects, making sure you change the values of particular properties.

If you’re in your project folder on the command line type in:

npm init

This will initialise a wizard for you that will take you through the steps of creating the file.

Fill in the following:

name:
version:
description:
author:

Leave the rest blank by just hitting Enter on your keyboard. Terminal will ask you if you are happy with what you have so far and just hit Enter again. If you go look back at your folder, you’ll see a brand spanking new package.json file is present. Well done! Next, we will have to tell package.json what dependencies / plugins we wish to use, here’s how we do it!

Heres how our final gruntfile.js will look:

{
 "name": "my-projects",
 "version": "1.0.0",
 "description": "A project to teach people how to grunt"
 "author":"Daine Mawer"
 "devDependencies": {
   "grunt": "~0.4.5",
   "grunt-contrib-watch": "~0.6.1",
   "grunt-contrib-sass": "~0.8.1",
   "grunt-contrib-concat": "~0.5.0",
   "grunt-contrib-cssmin": "~0.10.0",
   "grunt-contrib-uglify": "~0.6.0"
 }
 }

So what are we doing here? Where we see “devDependencies” is an indication of what plugins we’re using. There are hundreds in the Grunt Plugin repository, the ones here are some of the nifty ones for your most typical development environments. “grunt” is the actual grunt frameowrk that allows us to use the task manager. “grunt-contrib-watch” automatically refreshes the browser when we save a certain file or files. “grunt-contrib-sass” allows us to use the CSS preprocessor: SASS in our workflow, if you don’t know a lot about SASS or why you should be using it, you can view more about it here. “grunt-contrib-concat” takes a group of files of the same type, say .css or .js and merges them into one file. Its really useful, and lessens server load. “grunt-contrib-cssmin” minifies CSS files and “grunt-contrib-uglify” minifies Javascript files.

Alright, now that we have that setup, we need to jump back to the command line and type:

npm install

NPM will now install these dependencies from the Grunt repository for you and store them in a file called node_modules, it can take sometime. All grunt plugins are curated by the Grunt community and they all have plenty of documentation as to how they work and what they can do.

Great, we’re nearly there. Next up is the Gruntfile.js

Gruntfile.js

This file can be a little intimidating, generally people break it because they forget their {} or comma’s, so lets go through it step by step.

Our first line is this:

module.exports = function(grunt) {
};

This function contains all the logic that Grunt uses to run your plugins. Everything we do from here on out must be with in this function otherwise your Grunt won’t work.

Next we’re just going to keep things simple and reference our package.json:

module.exports = function(grunt) {
      grunt.initConfig({
      pkg: grunt.file.readJSON('package.json'),
})
};

The part we just added essentially imports the JSON data in our package.json and uses it as a reference for our project and dependencies. Great, now we’re going to work a little back wards, we’re going to use a couple methods called .loadNpmTask and .registerTask to get our Grunt plugins initiated before we set their options.

module.exports = function(grunt) {
      grunt.initConfig({
      pkg: grunt.file.readJSON('package.json'),
});
grunt.loadNpmTasks('grunt-contrib-sass');
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-concat');
grunt.loadNpmTasks('grunt-contrib-cssmin');
grunt.loadNpmTasks('grunt-contrib-uglify');

grunt.registerTask('default', ['watch']);

};

What this does is references the plugins we specified in our package.json – essentially loading them once the options have been defined. The .registerTask() which uses ‘default’ (needed) runs the “watch” task every time we save a file (we’ll set the options now). Don’t worry too much about this, it will all make sense in a minute.

Grunt still won’t work until we have set up each plugins options. Each plugin option forms a JSON object that lives within the initConfig() function. Make sure when following along with this next section that all your code lives with inside the initConfig(), otherwise your Grunt will give an error.

sass: {
 dist: {
    files: [{
      expand: true,
      cwd: 'build/sass',
      src: ['*.scss'],
      dest: 'css',
      ext: '.css'
      }]
     }
 },

To explain: dist stands for distribution, we want the way SASS is compiled to be in expanded format, not nested for instance. In other words, this will just look like regular CSS formatting. The working directory (cwd) should be located in a folder called build, in a folder called sass. We want the sass to be compiled from any (*) .scss file we use in the build/sass folder, the destination (dest) once compiled to a certain file is a folder called “css” and the extention of that file will be a .css. Easy?

Next up is the concatenation plugin

concat: {
    basic: {
      src: ['css/styles.css', 'css/normalize.css', 'css/bootstrap.css'],
      dest: 'css/production.css',
    },
extras: {
      src: ['js/scripts.js', 'js/bootstrap.js'],
      dest: 'js/production.js',
 },
},

With this plugin we can set and array of files that we wish to concatenate into one single file and specify its destination at the same time. You’ll notice that src (where the files are located) and dest (where they must be sent to) are the same for basic and extra’s. Its important to note that the order in which your CSS and its cascade works is still the same when you concatenate the file.

Next we’ll tackle CSSmin and Uglify:

cssmin: {
    options: {
     keepSpecialComments: 0
   },
    combine: {
      files: {
        'css/production.min.css': ['css/production.css']
       }
     }
  },
 // UGLIFY
 uglify: {
    my_target: {
    files: {
     'js/production.min.js': ['js/production.js']
    }
  }
 },

Cssmin creates a .min version of our production.css file. While uglify does the same for our javascript file. This helps web developers a lot. As we write CSS and JS, our minified version is always kept up to date and we can push it to the production server.

Finally, we have watch

watch: {
 scripts: {
   files: ['**/build/sass/*.scss', '**/js/*.js', '**/*.html', '**/*.php'],
   tasks: ['sass', 'concat', 'cssmin', 'uglify'],
    options: {
    spawn: false,
    livereload: true
   },
   },
 }

The watch task is probably the most important. What we’ll do is tell Grunt to run all of the above plugins on file save, which will compile the SASS, concatenate the CSS and JS files, minify them and reload the browser all at the same time! You’ll notice that in the files property we have an array in which we tell Grunt the files we want to constantly watch for changes. When grunt picks up that we’re using a specific file, we tell it to run the sass, concat, cssmin and uglify tasks, and state that livereload in the browser is true. 

Your gruntfile.js therefore should look like this:

module.exports = function(grunt) {
grunt.initConfig({
 pkg: grunt.file.readJSON('package.json'),
// SASS TO CSS COMPILING
 sass: {
    dist: {
     files: [{
       expand: true,
       cwd: 'build/sass',
       src: ['*.scss'],
     dest: 'css',
     ext: '.css'
     }]
    }
 },
// CONCAT JS AND CSS
 concat: {
basic : {
 src: ['css/style.css', 'css/normalize.css'],
 dest: 'css/production.css',
 },
extras : {
 src: ['js/scripts.js', 'js/boostrap.js'],
 dest: 'js/production.js',
 },
},
// CSS MIN
 cssmin: {
    options: {
    keepSpecialComments: 0
    },
    combine: {
     files: {
     'css/production.min.css': ['css/production.css']
      }
    }
 },
// UGLIFY
 uglify: {
    my_target: {
    files: {
     'js/production.min.js': ['js/production.js']
    }
   }
 },
watch: {
 scripts: {
   files: ['**/build/sass/*.scss', '**/js/*.js', '**/*.html', '**/*.php'],
   tasks: ['sass', 'concat', 'cssmin', 'uglify'],
 options: {
   spawn: false,
   livereload: true
 },
 },
 }
});
// Load the plugin that provides the "sass" task.
 grunt.loadNpmTasks('grunt-contrib-sass');
 // Load the plugin that provides the "watch" task.
 grunt.loadNpmTasks('grunt-contrib-watch');
 // Load the plugin that provides the "concat" task.
 grunt.loadNpmTasks('grunt-contrib-concat');
 // Load the plugin that provides the "cssmin" task.
 grunt.loadNpmTasks('grunt-contrib-cssmin');
 // Load the plugin that provides the "uglify" task.
 grunt.loadNpmTasks('grunt-contrib-uglify');
// Default task(s).
 grunt.registerTask('default', ['watch']);
};

Well done, your final step, jump back to the command line and in the folder that we have been working in, type in

grunt

—

For those of you that use Git, I’d like to point your attention to a few things, if you are working collaboratively, then you will want to be specific in your .gitignore about which files to push and pull. I have found that committing the production.min.css / production.css  and production.min.js  / production.js files cause problems. Ideally, you only want to commit your source files. In your .gitignore type the following:

js/production.js
js/production.min.js
css/production.css
css/production.min.css
node_modules/*

Your team mate should run npm install and grunt on their own development environment to install the plugins and compile CSS and JS. When you pull, you will only pull updates made on their SASS and CSS files, not their final production files.

That’s it! You have setup Grunt! I’ve created a Github repository for you, with HTML5 Boilerplate and Bootstrap as a template that you can use for beginning any project from scratch with Grunt integrated and setup. Please do let me know your thoughts on Twitter at @dainemawer

Developing a Healthy Lifestyle

Its been a while since I wrote a post. As usual, life takes over, clients get demanding, you take on more freelance work because you think you can actually get through it all, you drink more coffee than the average human does in a week; exercise less than the average human does in a year and eat whatever food that can get you back to your desk in the shortest amount of time possible.

I’ve spent the majority of my freelancing years in this complete insanity. Inevitably, burn out catches up with you. You either get sick and work through it, or have a complete nervous breakdown, cry, realise that life must be more than just web development and consider numerous options including knitting.

It was only the other day that after having worked for 6 months straight, no weekends and no evenings that I realised the hell I was putting not only my body, but my mind through. I’d like to explain my experience here and hopefully help some of you that can relate to me from a career-driven approach about getting a little more healthy.

The Career Mind-Set

As a chronic workaholic, I know what you’re thinking right now if you’re the same as me. You eat and breathe success. You want more clients, you want to learn more, absorb more knowledge, more experience, develop your projects to be more semantic, solid, intelligent and robost.

Career people are always looking forward to the next milestone, and usually they are the ones that people look at and think — “ You should really go spend more time with the giant ball of fire in sky”, they cant understand why they are not binge-drinking, going to wine festivals, declining invites and avoiding monotonous social behaviour. Its quite simple really. You cant have both. You are either a social butterfly, or a career driven individual that learns every single day that hard-work is the way to get further. You’ll pick up friends on the way, but being part of 5 Whatsapp groups is definitely not your priority in life.

Because of this behaviour, career-centric people tend to build their entire world and behaviour around their work. If work is okay, you’re okay. If work is falling apart, you’re probably having a mild heart attack. Work becomes the soft, comfy place that is rewarding, yet challenging and stimulating.

Web Developers in particular have an addition to this “syndrome”. Essentially Web Developers are problem solvers. Thats all programming is really about at the end of the day. Problem X needs solution Y and we need to find a way to get there.

A day full of constant problem solving is a challenging feat for any human in the 21st Century, as most of our problems get solved for us all the time. This adds extra pressure, especially considering the external development environment that web developers are faced with. An array (no pun intended) of specific and generic problems hit you when you’re not even expecting them. Few people have a super-detailed understanding of the Internet. Once the problem is solved, you feel like you’ve just solved global warming or world hunger and you wait for some instant gratification from people that really have no fucking clue what you’re getting so excited about that never comes.

Thus, you treat yourself after a hard day’s work. A beer, a pizza, those burgers you love at your favourite hipster restaurant. It all eventually adds up and after pushing your brain and body to the limits, your body simple gives you an error that many developers are quite familiar with:

fatal error on line 2344.

You’ll also find that you get another common error:

301 — Permantly Redirected

Yes, your motivation to get up and code goes to shit, your creativity disappears and you’re as bout as useful as “Ctrl + Alt + Delete” on a Windows program that has stopped behaving as it should.

A Simple Equation

So now that I’ve blurted on about how terrible web developers treat themselves, I’d like to provide a simple equation for you all that sums up what I’m trying to say:

Input = Output

One of the most important programming conventions ever created. As you can see, what you input is what you output. If your input is negative you will have a negative output.

This is where health comes in, so this third and final section is somewhat of a framework to get you going — “The Bootstrap of Web Development Health”

No More return null;

This has been my plan lately. But first lets look at our environment on a day to day basis:

• You spend roughly 8–10 hours working each day
• Most of that time is in front of a screen, figuring out code related problems.
• You take minimal lunch / coffee breaks
• When you get home, you work some more.
• You sleep a maximum of 5–6 hours a night.
• You most likely suffer from extreme stress and / or anxiety
• You like to reward yourself with nice (bad) things after a days work for the sake of unwinding.
• You probably have some bodily ailments: allergies, headaches, fatigue, grumpiness, anger, shortness in breath etc.

Before I continue, I’d like to point out, Im not a health freak — I dont have a gym membership, I dont follow health blogs, Im not concerned with how many carbs I eat, or how much I can bench press. This is about being healthy in relation to what you do, if you’re a health freak, gym bunny reading this article you’re probably going to get disgruntled, so go run on the treadmill if you get frustrated.

Food

Cut out dairy and wheat as much as you can. Stop eating grilled cheese sandwiches on white bread. Right NOW. Dairy and wheat not only produce lots of mucus in your sinuses, limiting the amount of oxygen getting to your brain for healhty brain activity, but they can also influence more headaches and sluggishness as well as disturb your train of thought and concentration. If you’re having a 4PM crash each day, its largely due to the amount of carbohydrates you’re consuming which sitting at a computer is not being burnt off.

Eat more fruit and vegetables. I know, I sound like your mother. If you’re not fan of eating vegetables and fruit that gets stuck in your teeth and makes your fingers smell like orange for the next 3 hours, I have an alternative for you in the section below.

Eat Oats for Breakfast

• Half a cup of rolled oats
• Cup of water
• Microwave for 1;30mins
• Add some Peanut Butter, Natural Honey and a Bannana

Its low GI so it will keep you sustained with energy until lunch-time. Instead of coffee, drink hot water with a slice of lemon. The medicinal properties of that drink is crazy, from increasing healthy enzyme activity to stimulating the nervous system. Just take my word on it and do it.

Tuna or Chicken on Rye for Lunch

If you can find a way to get your hands on some Tuna or Chicken for lunch, do it. They are light proteins which your body can digest easily. The fibre in rye will also help you keep your energy sustained.

Drink

Cut out the coffee. Caffiene dehydrates you, makes you more anxious and can overwhelm you when the pressure starts to get tough. Coffee can also lead to chronic halitosis (you know, when people cant talk to you because your breathe is so stale they want to pass-out or find another job.), quicker temper and more frustration. You cant think clearly if your mind thinks its under attack due to the surge in nervous system activity that caffeine creates.
Start drinking more water. Water is paramount to good body functioning. The more you consume the lighter you will feel.

Juice! Buy a juicer. Take carrots, apples, beetroot, cucumber and whatever else you like and get those oxidants into your body, all the vitamins you need are in there, and you’d be surprised how much better you feel. One juice a day gives you plenty of vitamins.

If you are going to cut back on coffee, and you’re on 4 a day, cut back to 3, then 2, then 1. You’ll find that eating a little better and kicking a juice every now and then, will keep your energy up and you wont need the “fake” energy that coffee gives you. Also, drink your coffee with Soy Milk. It tastes a little different, but its much better for you, and doesn’t give you a thick post-nasal drip like dairy does. Most coffee shops are willing to give it to you as free alternative to normal full-cream or skim.

Exercise

I struggle with this one, Im not jock, so pushing weights isn’t the most important thing in my life and neither is body image. I have a brilliant mind like most web developers do and thats enough to attract secure and intelligent women. I’ve found that running — not on a treadmill — theres this thing called fresh-air you dont get inside a humid, smelly, indoor gym that does wanders for you. I run 20mins / 2–3km every second day for 2 days in a row, in other words:

Sat, Sun, Tues, Wed

Mon, Thurs and Fri I keep off just so my body can relax and it doesn’t effect my weekly schedule too much.
This helps clear my mind, and to be honest you can draw a lot of parallels between running and development, so give it a go and see how it works for you.

All in all, divide some of your attention on getting these things right and you’ll start feeling better in a couple of days. Going out can be a little bit of a problem. Beer and Wine can also have effects for people who have sinus and allergies. Stick to gin if you can, it will burn calories for you. I tend to eat Vegetarian Sushi when I go out with minimal soya sauce. Otherwise wheat free burgers / pizza’s do wonders and salads. But Im sure you have your own preferences. Again, this is not about transforming your entire life, do it bit by bit, and see how it goes.

One last challenge. Do what I’ve said above for 3 days, then go eat a greasy meal. You will notice the difference after eating, I’d dig to know how it goes so give me a shout on Twitter — @dainemawer and let me know!