What do you consider when building a new application?

When you’re starting a new project and thinking about what you’re going to use in your application, what factors do you consider? Sometimes this depends on what your role is, like a developer might jump straight in with just use X coding language and continue on their way. Whereas others might want to play with whatever the new and latest technology is. Then there is people like myself, that likes to think about the whole picture, and so here are some of the key factors I consider when building a new application.


Code Repository

This one should just come hand in hand with your company, as there should already be a standard of where and how you store your code. However there’s a lot of ‘should’ in that sentence, as some junior companies don’t have this thought through yet, or you could be doing it alone, or even the company might have something in place but you are thinking of exploring new technologies and new grounds.

The big factor to consider with a repository is the company that is holding that information. It starts with where the code will be held for legal laws, security and for access. Now you might think access is a silly thing to think about in this, as it is just all done over https on your computer isn’t it?, but you might need to consider if you are going through a proxy so security might lock you down unless it is a secure root. You also might put the repository on premise due to the value of the code you are storing, which might also be the reason for your choice on the company to store your code. If you think that the company storing your code will be going after 2 years, then you might want to think about either a different company or a good get out plan just in case. These days there a few big players that just make clear sense, so after this it would come down to the cost of that companies services for the level you require.

The other factor is how it is stored and retrieved from the repository with things like GIT, as this is another technology that you will depend on. You will need to consider what learning curve will others need to undertake if they are to use this Version Control System and again like the storage factor, will they still be around in as few years’ time?

Linked from this would be what tools you are thinking of using later in the thought process for build, test and deployment, as these might be harder work for you to move code between locations and tools. For example if your repository is on premised behind a firewall and security, but your build tool is in the cloud with one company and then the test scripts are stored in another companies repository.



You might have an easy job with choosing a language if you are a pure Java house or PHP only then that is what you will be using, as you can only do what you know. However, if you want to branch out or you do have more possibilities then the world can open up for you.

A bit higher level than choosing the language you want, but design patterns do come into this. I have seen where someone would choose a .NET MVC language for their back end system, but then put a AngularJS front end  framework on top. What you are doing here is putting an MVC language design on top of an MVC language design, which causes all types of issues. Therefore you need to consider, if you are using more than one language then how do they complement each other. For instance in this circumstance you could either go for the AngularJS MVC with a micro service .NET backend system, or have the .NET MVC application with a ReactJS front end to enrich the users experience.

As I said before, you might already know what languages you are going to use as that is your bread and butter now, but if it is not then you need to think about the learning curve for yourself and other developers. If you are throwing new technologies into the mix then you need to be sure everyone can keep up with what you intend on using, or you will become the Single Point Of Failure and cause support issue when someone is off.

As well as thinking about who will be developing the technology, you need to think about who will be using the technology. This can either be from an end users experience or even the people controlling the data like content editors, if this is that type of system. If you would like a fast and interactive application then you will want to push more of the feature to the client side technologies to improve the users experience, but you might not need to make it all singing and dancing if it is an console application running internally you want to just do the job. Therefore the use case of the language has an importance to the choice.



Testing is another choice in itself, as once you know your language you know what testing tools are available to use, but they then have all the same consideration as what coding language you want to use, as you will still need to develop these tests and trust in their results.

I add this section in though, as it is a consideration you need to have and also how it factors into giving you, the developer, feedback on your test results. These might run as part of your check in or they might be part of a nightly build that reports back to you in the morning, so how they are reported instantly to the develop depends on how fast they can react to them.

As part of the tooling for the tests you will need to recognize what level of testing they go down to, for example unit tests, integration tests, UI tests or even security testing. These then need to consist of what tools you can integrate into your local building of the application, to give you instant feedback, for example a linter for JavaScript which will tell you instantly if there is a conflict or error. This will save you time of checking in and waiting for a build result, which might clog up the pipeline for other checking in.


Continuous Integration(CI) and Continuous Delivery(CD)

This is a little out of touch with what application you are building as another person in the DevOps roll might be doing this and it should have no major impact on your code, as this is abstract to what you are developing. However the link can be made through how you are running this application on your local machine. You could be using a task runner like Gulp in your application to build and deploy you code on your local machine, which then makes sense to use the same task runner in the CI/CD.

Therefore you need to think about what tooling can and will be used between the your local machine and the CI/CD system to have a single method of build and deployment. You want to be able to mirror what the pipeline will be doing, so you can replicate any issue, plus also the other way round as it will help that DevOps person build the pipeline for you application.


Monitoring and logging

Part of the journey of your code, is not just what you are building and deploying, but also what your code is doing after that in the real world. The best thing to help with this is logging for reviewing past issues and monitoring to detect current or coming issues.

For your logging I would always encourage 3 levels of logging Information, Debug and Error, which are configurable to turn on or off in production. Information will help when trying to source where the issue happens and what kind of data is being passed through. It will be medium level of output as to not fill up your drive fast, but to give you a lot of information to help with your investigation. Debug is then the full level down, giving you everything that is happening with the application and all the details, but be careful of printing GDRP data that will sit in the logs and to not crash your drives from over filling. Errors are then what they say on the tin, they will only get reported out when there is an error in the application, which you should constantly check to make sure your remove all potential issue with the code. The considering factor with this for your application is technology and implementation to your code. We have recently changed a logging technology, but how it was implemented made it a longer task then it should have been, which can be made easier with abstraction.

Monitoring depends on what your application is doing, but can also expand past your code monitoring. If you have something like message queue’s you can monitor the levels or you could be monitoring the errors in the logs folder remotely. These will help pre-warn you if there is something going wrong before it hits the peak issue. However the issue might not be coming from your code, so you should also be monitoring things like the machine it is sitting on and the network traffic in case there is an issue there. These have an impact on the code because some monitoring tools do not support some languages, like .NetCore which we have found hard in some places.



Document everything is the simple way to put it. Of course you need to do it in a sensible manner and format, but you should have documentation before even the first character of code is written to give you and others the information you have decided above. Then you will need to be documenting any processes or changes during the building for others to see. If you know exactly how it all work then someone else takes over while you are away, then you put that person is a rubbish position unless they have something to reference to.

These need to have a common location that everyone can have access to read, write and edit. However a thought you could try is using automated documentation draw from the codes comments and formatting, so you would need to bear this in mind when writing out your folder structure and naming convention.

You can go over board by documenting to much as somethings like in the code or the CI/CD process should be clear from the comments and naming. However even if documentation for tools like GIT have already been written, it is helpful to create a document saying what tooling you are using from a high level, why you are using this and then reference their documentation. It gives the others on the project a single point of truth to get all the information they require, plus if the tooling changes you can update that one document to reference the new tooling’s, and everyone will already know where to find that new information.



In the end what we have just gone through is the DevOps process of Design, Build, Test, Deploy, Report and Learn.

  • You are currently looking at the design point while looking at what languages and tools you would like to use.
  • We are going to get a language to build the new feature or application.
  • There will be a few levels of testing through the process of building the new project.
  • The consideration of CI and CD gets our product deployed to new locations in a repeatable and easy method.
  • Between the Logging and Monitoring we are both reporting information back to developers and business owners, who can learn from the metrics to repeat the cycle again.


Reference: https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0

Should you unit test CSS?

When I told a college I was going to write some unit tests for CSS they went crazy, and I do see why, however I think it can be valuable in the right way. I would like to describe to you why I think doing unit tests on CSS can be worth your time as a developer and also beneficial to the project.

Why oh why you may ask would you unit test CSS? Styles change so often, the style might be abstract from the code and they can be hard to test. You can’t test just the code, you have to test it for what it is, which is User Interface(UI) coding. Therefore you need to test it through the UI with something like Selenium, that boots up a browser and checks the UI. Though even if you use this technology then testing literally the size of the font and the colour of the background, which have no variable changes, you not testing properly.

Normally when you are unit testing, it is on something that can change depending on multiple variables, so testing the font size isn’t that. When you are testing them things they can only change if you want them to, so you not testing the code, you’re testing that you remembered to update the test. For example, if you have a ‘h1′ with a font size ’14px’ and write a unit test to check the browser has rendered a ‘h1’ with that size, then you have a change come in. You change the font size and now your unit test fails, so you update the test case, but what have you just shown to the project? You have proved that the font has been updated in both places.

It also gets hard when you are testing with browsers, as each browser will interpret the CSS in different ways. They render different, so when you test ‘1em’ is ’14px’ you might get a different answer in another browser.

Therefore why do I think you should unit test CSS?

Well that’s more because I am not saying to test the CSS purely, but to test modular items. In the project I work on there are modules in the site that share classes. Things like a promotion box with a background colour and a banner with the same background colour. We use the CSS pre-processor called LESS, so the background colour is stored in a variable shared across the code base. If a developer decides to change that variable for the banner, we want the unit test to flag that changing this colour effects the promotion box as well.

Example CSS:

@bg-color: #66bb6a;

.banner { background-color:@bg-color;}
.promo { background-color:@bg-color;}

This is why we should unit test, because we want to know if a classes style changes then what else does it effect. Imagine the above CSS lines were in separate files. You change the ‘@bg-color’ as you want the banner to be a different colour and then the unit test flags that the promotion box is incorrect. The value from this means the developer can find out what breaking changes they have introduced, which helps them decide it should all change or no I need a new class.

There is also testing where it takes graphical images and compares the two, but this is browser and code structure dependent. You can to make sure you can test the code in all situations and that’s why a banner for example is better than a whole page.

In our organisational structure then CSS is in a separate code base as the HTML it is running on, due to the CSS project being used in multiple projects. Therefore, we can’t test against the project’s code base, instead we need to create a running example each time. This has it benefits as we then have a working example to demo to the HTML developers.

This is where and why I think there is value in doing unit testing on CSS, but what do you think? Do you do it already or do you think it is a waste of time?

Learn a Framework not a Language

I listened to a podcast that said you should learn a coding framework first not a language. Now this might seem weird and confusing to existing developers as we were brought up with the basic languages and then frameworks have become a trend, but that’s because we are old. New developers are coming into the industry and frameworks are the top dog thing to know and use. You can’t see a job without one these day, so is it better to learn the framework first or should you go back to basics first?


When you learn the language you are learning like a baby. You start from small works like ‘var’, ‘string’ and don’t forget the bloody semicolon. From this you then build on these like bricks on a house, slowly building the finished product of a complete application. Now this seems smart as you start from the beginning to the end and you understand everything about the language. It can help a lot when you come across a new problem, search for it, get the answer and now you can understand what they are on about. I think learning like this will build you up to be a great developer in that language as you are learning everything about it.


However because you are learning everything about it, you also learning the rubbish you don’t need. A lot of languages will teach you fundamental code, but somethings are just not good practice and not how the real world works. The tutorials will tell you how to code in a perfect world from an application built from scratch, which isn’t bad as that is how you should be coding. The problem is most companies have an existing infrastructure and procedure to work with, therefore perfect world doesn’t help. For example when you are doing CSS and you build this perfect world style sheet, then you open it up in IE… enough said really! Maybe learning the language would be better if they also showed you common issues and how to fix them instead of just showing you what it will and will not work on.


Before I said that learning a language first is like building a house from the ground up. Well learning a framework first is like building the roof for the house before the house is built. The idea is if you learn to build the roof perfectly, then as you do this you will also slowly be building the house bricks at the same time. As you learn a feature of a language to say convert a string to an integer, you will also be learning what a string, a integer, a variable and a function is at the same time.

The issue with this can come that you are only learning what you need for the framework, so when you come across an issue with the language, not only do you need to understand the issue, you may have to read up to learn what the code is that fixes the issue, causing more work. Also you are not learning what is going on behind that framework you are using, which could be a debate that do you need to know, but for example if you only use Jquery then to display an element you would only know…




However you can either think this is magic or you can find out that this is what it is doing in plain JavaScript…


Document.getElementByClass('class').display = 'block';


This also plays into the real world working because at the moment frameworks are the hot thing. Therefore only knowing the framework might not be a bad thing. If the customer wants a pie, you give them a pie, you don’t need to know or care about the ingredients. This is why cutting out the middle man can be a good idea especially for the new developer on the block trying to get a job. You give what the recruiter is looking for.


So after all of that, what do I think?… I think for new developers coming out of university or just starting out this can be a great idea to learn the framework first. Your trying to get into the business, so you need to be the developer they want not what you think they need. If you learn the hottest techniques and code that is required in the industry you want to get into, then you have more chance of getting a job quick. Once your in, then your in, so from therefore can continue learning that path on the job while also back filling the spaces you didn’t get to learn.


However the older generation nearer the end of there career I wouldn’t suggest. At this point the younger person has the best opportunity to get the job and that is what you are competing at. Its not to say you are extinct, but to say that you are valuable how you are. The young generation can chase the rabbit of keeping up with the trends and the new troubles, all the while you are the tech support for the legacy technologies you know like the back of you hand. Developers who can keep the company running are getting paid more than the young guns, because no one knows what they know and no one wants to learn what they know, therefore your safe until the end.


There you have it my opinion that the young learn the new framework and the old stay comfortable with what they know, but what is your opinion? Tell us below in the comments.

My Grunt Worker

I thought it would be a good idea to share how I have set up one of my Grunt Files. This follows on from the style guide post where I described why use style guides and also what one I use.

In the configuration there are some shared properties and settings, so to start my Grunt file I have set up some variables to store the string locations. This then saves on them having to be repeated between modules and when there is a folder change or an update then it is one change for all.

I have mainly used the Grunt JS set up for the JavaScript processing, for which I have started with the linter for my projects. I like to follow the Airbnb style guide for both the JavaScript and the CSS, so this is the guide I have made the linter follow. The linter I have chosen to use is the JS Hint as it is very well supported and works with the Airbnb guide, however I use the JS Hint for Visual Studio full code editor only and then I use the eslint (link eslint)with Visual Studio Code (VS Code). This is because I started with the eslint with VS Code, but found that JS Hint worked better with the full edition.

To set this module up you can use the ‘jshintrc’ file, but to save on loading and maintaining multiple files I decided to drop the settings in the Grunt file directly. The source for the configuration is here on the Airbnb Github.

After the files have been checked for formatting errors, I wanted to collect all the small JavaScript files and concatenate them together. Therefore I decided to use the ‘grunt-contrib-concat’. This simple module gathers all the JavaScript files from a configured location and concatenates them into a single location. There are two issues with this method and why I don’t tend to use this all the time. One is that it concatenates from top to bottom of the files, so unless your desired order is alphabetical then this create a requirement issue. For this I tend to use RequireJS being one of the best method to save on loading time and create a simple configuration. The other issue is that once it concatenates the sources into a single file, and you run it again, it doesn’t clean out the previous run. Instead it keeps on concatenating the sources, so you start to get duplications of source. To tackle this you can use the ‘grunt-contrib-clean’ to clear out the previous content. Pass this module the concatenated file location and run it before the ‘grunt-contrib-concat’ to have a clean source location.

Just to get the file size even smaller, the last module I use is the ‘grunt-contrib-uglify’. This is set up basically the same as the previous concatenate module with source and its destination. The module will take the single concatenated file and then minify it to the chosen location.

Finally for the JavaScript is the QUnit module, and you can put this in between any of the modules before. I like to test it on the file I am going to be using in the production site to test on what will be used. The QUnit module requires the PhantomJS Node package to run the test, so this will need to be installed but you can check out the version in my example files. I again like to use this module as it is well supported and also easy to use. For the Grunt configuration the test needs to be in a HTML file formation, which you can read more at QUnit JS.

The CSS modules are much smaller and also simpler to use, because instead of using any minifies, concatenates or other modules I just use a pre-compiler.  The pre-compiler will do all the above except the minimisation, but this is up to you if you need it done.

The only thing I have got in the Grunt file for CSS is the linter. As mentioned before I use the Airbnb style guide, so I have of course use this guide with the preferred linter. The linter used is ‘grunt-stylelint’ that pulls in the configuration file from a JavaScript directory. The only other configuration needed is to tell the linter where to lint.

So now all the configuration is set up and ready, but without running this file manually the Grunt Worker won’t be working. Therefore we need something to keep an eye on the files for if anything changes and for that we have the ‘grunt-contrib-watch’. In the configuration of this module, point it to the folders you want it to watch and then set up what you want it to do. In the tasks you enter a string array of the modules you want to run if a file changes and also the order to do them in.

This is then the finished product of how I have configured my Grunt file. Depending on different projects, editors and languages this can differ, but it is a base to start. Please feel free to share how you configure your Grunt files.

Here are links to all the grunt Git Hub:

Here is my grunt configuration:

// Generic File Variables
const BaseDirectory = 'assets/';
const WildCardFolder = '**/';
const MainLocation = 'main/';
const MainFile = MainLocation + 'main';

// JavaScript File Variables
const FileDirectoryJs = BaseDirectory + 'core/js/';
const WildCardFileJs = '*.js';
const FileLocationJS = FileDirectoryJs + WildCardFolder + WildCardFileJs;
const FileDirectoryJsUnitTest = ['core/js/JsUnitTest/QUnit.html'];

// CSS File Variables
const FileDirectoryCss = BaseDirectory + 'core/css';
const WildCardFileCss = '*.css';
const WildCardFileLess = '*.less';
const FileLocationCSS = FileDirectoryJs + WildCardFolder + WildCardFileCss;
const FileLocationLess = FileDirectoryJs + WildCardFolder + WildCardFileLess;

module.exports = function (grunt) {
jshint: {
files: [FileLocationJS],
options: {
* =================
* Source: https://github.com/airbnb/javascript/blob/master/linters/.jshintrc

// Define globals exposed by modern browsers.
'browser': true,

// Define globals exposed by jQuery.
'jquery': true,

// Define globals exposed by Node.js.
'node': true,

// Allow ES6.
'esversion': 6,

* =================

// Force all variable names to use either camelCase style or UPPER_CASE
// with underscores.
'camelcase': true,

// Prohibit use of == and != in favor of === and !==.
'eqeqeq': true,

// Enforce tab width of 2 spaces.
'indent': 2,

// Prohibit use of a variable before it is defined.
'latedef': true,

// Enforce line length to 100 characters
'maxlen': 100,

// Require capitalized names for constructor functions.
'newcap': true,

// Enforce use of single quotation marks for strings.
'quotmark': 'single',

// Enforce placing 'use strict' at the top function scope
'strict': true,

// Prohibit use of explicitly undeclared variables.
'undef': true,

// Warn when variables are defined but never used.
'unused': true,

* =================

// Suppress warnings about == null comparisons.
'eqnull': true
concat: {
all: {
src: [FileLocationJS],
dest: FileDirectoryJs + MainFile + '.js'
uglify: {
all: {
src: [FileLocationJS],
dest: FileDirectoryJs + MainFile + '.min.js'
[FileDirectoryJs + MainLocation + WildCardFileJs]
qunit: {
all: FileDirectoryJsUnitTest
stylelint: {
options: {
configFile: 'stylelint-config-airbnb.js',
syntax: 'less'
src: [FileDirectoryCss + WildCardFileCss,
FileDirectoryCss + WildCardFileLess, CardFileLess]
watch: {
files: [FileDirectoryCss, FileDirectoryJs],
tasks: ['clean', 'concat', 'stylelint', 'jshint', 'qunit', 'uglify']



Display flex back to old browsers

CSS3 and HTML5 has brought us a host of new and exciting features, but then the party poopers come and tell use we need to make sure everything works on the older browsers. At this point we realise these older browsers need some hammering to make sure the new toys still work. One of these features is the display property’s value ‘flex’.

First we need to know what the flex property does and that is, it bring everyone together. By this we mean when the parent has this property on it, all the children fall inline and to the same height. This is close to replicating the table cell attributes and elements as they will shrink and expand equally. This is also the same for the height, as if one child’s content expands more then the other, then they all expand.

There of course is more properties and values that can determine the sizes, directions and wrapping etc. You can find out more about these property at either W3School or CSS-Tricks

This is a great tool as we can keep the properties of the current element type, but give it all the fun of thing like tables. However, the fun stops when you use older browsers like IE8 or any thing less then the ones described below:

Internet Explorer

21.0 -webkit-


10.0 -ms-


18.0 -moz-


6.1 -webkit-


What we need to do for these browsers then, is force the child items to be a division of the parent element and all the same height. This isn’t the most complex thing to do, but here is how I did it.

The first thing we need to do is check if the browser supports the ‘flex’ value or not, as we don’t want to effect the browsers that do. We can do this by checking the CSS property ‘flex’ of the selected item, which if it is supported then it will return a value. If the browser doesn’t then it will be undefined and that we can test with the ‘typeof’ operator.


if (typeof $('.ElementClass').css('flex') == 'undefined' )


If ( typeof document.getElementById('ElementID').style.flex == 'undefined' )

Once we know ‘flex’ is not compatible, we can activate our dynamic copy. You can see from the example below that for the width, we get the total amount of children and divide 100 percent by that number. This will then give us an even percentage on each child to fill the total parent container.

For the height, we just loop through all the children to determine which is the tallest container, then we can set the height of all the others to that same height.

//Get the longest height
var heightTop = 0;
for (var i = 0; i < $(el).length; i++) {
$($(el)[i]).height() > heightTop ? heightTop = $($(el)[i]).height() : '';

//Set the height and width
$(el).width((100 / $(el).length) + '%');  

This can then all be put in the on document ready method and the on window resize, so it runs when it loads and also when the window is shrunk.


$(document).ready(function(){ /* Add Method Here */ }); $(window).resize(function(){ /* Add Method Here */ });


window.addEventListener('resize', AddMethodHere, false);

Check out the full solution here on the Pure Random Code CodePen.

Comment below what you think of it and how you work with browser compatibility.