WordPress REST API – Part 3 – Ionic 1


Code Run Through

This post follows on from posts about hybrid mobile app development using the new WordPress REST API and Ionic: Part 1, Part 2

What follows is a run through of the import parts of the code, for the application shown in Part 2.

By now you should have a [very basic] Ionic app running in your browser. The app will allow you to:

  • Log into your remote, WordPress REST API enabled, website.
  • Make a post from the mobile app to your WordPress site.

Pretty simple stuff.

The code that performs the magic is pretty simple too.

*I have created both an Ionic 1 and Ionic 3 repo for the App code. However, below I describe the structure for the Ionic 1 repo only.

Ionic Project Structure (Ionic 1)

Ionic 1 Folder Structure

Ionic Folder Stucture

As you can see from the folder structure below there are quite a few folders in our Ionic App.

However, the important files and folders are as follows:

  • www/js: This folder contains all the Javascript code for the app.
  • www/js/app.js: The main entry point for the app. Things like routes are configured here.
  • www/js/controllers.js: The logic behind what happens on the screens is placed inside this file e.g. what should happen when the login button is pressed.
  • www/js/services.js: Reusable services to perform business logic e.g. authentication and connection to WordPress
  • www/templates: This folder contains the html for screen in the app.
  • ionic.config.json: This file contains configuration options for the app. In Part 2, we changed a setting in this file to point to our WordPress site.

The folder structure is much like any other Angular application, so we will head straight to the code to see what the key lines are:


In app.js we configure the Angular app before it runs.

In this file we state:

  • What our routes are i.e. what are the urls for our app, what html should be loaded and what Javascript files should control the html.
// Ionic uses AngularUI Router which uses the concept of states
// Learn more here: https://github.com/angular-ui/ui-router
// Set up the various states which the app can be in.
// Each state's controller can be found in controllers.js
 .state('login', {
 url: '/login',
 templateUrl: 'templates/login.html',
 controller: 'LoginCtrl'
 .state('report', {
 url: '/report',
 templateUrl: 'templates/report.html',
 controller: 'ReportCtrl'
 // if none of the above states are matched, use this as the fallback
  • Any injectors/interceptors we want to use. We will see later that, when we get an authentication token, we want this to be automatically passed to every subsequent HTTP call we make. An interceptor is a way of achieving this.


The controllers.js file contains the logic for the Login and Report screens.

The LoginController has one function: try to login when the user clicks the Login button

$scope.login = function () {
 // contact our login service with the data from the username and password fields
 LoginService.loginUser($scope.data.username, $scope.data.password).then(function (data) {
 // if it is a success, go to the Report screen
 }, function (data) {
 // if there is an error pop it up onscreen
 var alertPopup = $ionicPopup.alert({
 title: 'Login failed!',
 template: 'Please check your credentials!'


The ReportController has a single function too: try to post the score and report data to WordPress (though our WordPress service).

$scope.createReport = function () {
 // show a saving... message while we contact the service
 template: 'Saving...'
 // pass through the values from the score and report fields to the service
 WordPressService.createReport($scope.data.score, $scope.data.report).then(success, failure);

Both controllers are very simple, it is in the Services.js where the real work is performed.


The services.js is the work horse of the app, it contains 3x services:

  • LoginService. This service is used to contact a WordPress REST API end point and request a JWT authentication token.
// the important bit, contact the end point and ask for a token
 $http.post('/server/wp-json/jwt-auth/v1/token', data).error(function (error) {
 }).success(function (data) {
 // you are now logged in, save to session storage, the auth interceptor will pick up
 // and add to each request
 $window.sessionStorage.token = data.token;
  • WordPressService. The WordPress service contacts our WordPress REST Api and tries to create a post.
var data = {
 title: score,
 excerpt: report,
 content: report,
 status: 'publish'
 // the important bit, make a request to the server to create a new post
 // The Authentication header will be added to the request automatically by our Interceptor service
 $http.post('/server/wp-json/wp/v2/posts', data).error(function (error) {
 }).success(function (data) {
  • AuthInterceptor. The interceptor service checks localstorage to see if we were given a token, if we have, then it adds it to every Http request.
request: function (config) {
 config.headers = config.headers || {};
 //if there is a token, add it to the request
 if ($window.sessionStorage.token) {
 config.headers.Authorization = 'Bearer ' + $window.sessionStorage.token;
 return config;

Any Questions?

That’s basically all there is to it.

If you have any questions, or any amendments that I can make to the Github repo, then please comment below….

WordPress REST API – Part 2


This post follows on from a previous post, espousing the virtues of the WordPress REST API for hybrid mobile app development.


At the 2016 WordCamp in Belfast, I gave a talk about using the WordPress REST API for mobile development. I gave two code walk throughs at the conference; what follows is a walk through of the football mobile app.

The football app uses Ionic to create a cross platform mobile app that:

  • Connects to a remote, REST API enabled, WordPress site.
  • Authenticates a username and password from the device (using JWT – JSON Web Tokens).
  • Shows a ‘Result’ screen. The screen allows users to input a score and match report.
  • Posts this ‘Result’ to the remote WordPress site.

N.B. All the Ionic 1 code is available on Github. There is also an Ionic 3 code repo available here.

The steps to create a shiny new mobile app, which allows soccer coaches to post match results from their phones, is as follows:

Ionic 3 to WordPress

Ionic 3 to WordPress

WordPress Site

We need to first create a WordPress website which will act as our back end engine to our app.

*Also on some servers you will need to enable http auth in your .htaccess file

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

Mobile App

  • Install Node on your machine.
  • Install Ionic and Cordova using the following NPM command/cmd:
    npm install -g cordova ionic
  • Download the github code (cd to the folder you want to put it in first)
    git clone https://github.com/conorw/wp-rest-api-ionic.git

    Or for Ionic 3

    git clone https://github.com/conorw/wp-rest-api-ionic2.git
  • Using the command line navigate (cd) into the created directory
cd wp-rest-api-ionic
  • Get node to install Install the projects dependencies
npm install
  • Change the ionic.config.json file to point to the URL of your new WordPress site
     "name": "teamthingmobile",
     "app_id": "",
     "proxies": [
     "path": "/server",
     "proxyUrl": "https://thenameofyoursite.com"
  • Start Ionic to show a web verison of your app
    ionic serve


    You should now have a working mobile app, executing in your browser, which you can now use your WordPress credentials to login.

If not? Give me a shout below…….

In the next post I will highlight the important code in the sample, and explain what it means.

*For an Ionic 3 version of the code see this post.

WordPress REST API – Mobile Apps


WordPress, not just for bloggers

I love WordPress!

Unfortunately, in my everyday job as a software engineer, I don’t get to use it much.

However, with the availability of the WordPress REST API, there are more and more reasons to use it on “real” software projects.

The WordPress REST API, in very simple terms, is a way for apps and other websites to communicate with the powerful WordPress “engine”.

Pic’N’Mix WordPress

With the WordPress REST API you can use WordPress as an ‘Application Framework’. With an application framework you can ditch the heavy blog website concept and just use the great bits of WordPress that you need in your shiny, light-weight app or website. Give your new app or website a head start by harnessing dependable WordPress engine features like user authentication, content management, media management, extensions, SEO, translations etc.

A great use case for the WordPress REST API is to use it to supercharge Mobile App development. By Pic’n’Mixing the best parts of WordPress with your mobile development technology of choice, you can rapidly get an app up and running.

Pick and mix WordPress

Pic’n’Mix WordPress

You can use WordPress as a dependable back end to your Mobile App. The mobile app stays light-weight, the only thing it needs to utilize WordPress is a Http client. If your app can make a web call, you’re all set.

But it’s not used in production apps, right?

There are some fantastic examples of apps, out in the wild, which use WordPress as a powerful back end. 3Advance were quick to recognize its utility and have created two apps already which use WordPress in the background:

Launch Alert: Meg Bitton Live iOS App gets 148 ⭐️⭐️⭐️⭐️⭐️ reviews in just 12 hours!

Launch Alert: Apps Developed to Watch and Stream Portrait Masters

3Advance are notorious for quickly turning app ideas into reality. They found the WordPress community and REST API perfect for rapid application development.

Getting Started

To get started using WordPress as your next application framework is as simple as installing a normal self-hosted WordPress site or create a site on WordPress.com.

The REST API is enabled by default on self-hosted and WordPress.com sites.

Check it out for yourself; go to your favorite WordPress site and add “/wp-json/wp/v2/posts” to the web address to see a REST API call in action e.g.


There are numerous examples on the internet of how you can start integrating the data returned from the REST API with your app. So instead of rehashing yet another example, here are some links below.

WordPress REST API Documentation: https://developer.wordpress.org/rest-api/

Used with a progressive web app: /wordpress-rest-api-part-2/

Used with React:


Used with Vue.js


Hybrid Apps – Productivity Nirvana


So much code, written so many times

Android, IOs, Windows Phone, Web, Responsive Web; customers don’t really understand, they want their app in ALL the places. “Surely it’s the same functionality, just make it work on a different device, how hard can it be?!?”.

Unfortunately, plenty hard.

Different programming languages, different screen sizes, different App stores and different hardware makes multi platform development a pain for mobile developers. What we end up doing is re-writing the same functionality in different bespoke apps, using different languages, for each of the hardware devices; not ideal, but sometimes unavoidable. Writing the same code, multiple times is something that many of us unfortunately have to swallow.

Server Side API

There are some things we do to try to minimize the amount of code we need to duplicate on each device.

One of the approaches, to reduce code duplication, is to create a comprehensive set of web services. Using services, we can implement most of the data retrieval/manipulation and business logic, server-side. All the devices will now be able to access and use these services; code once, use everywhere.

However, these services only get us partially on the way to eliminating code duplication.

Hybrid Apps

One increasingly popular solution, to making apps that can be written once and run anywhere, is by using ‘hybrid’ development i.e. write the app in a non-native language that can be ran on ‘all’ devices. There are a slew of hybrid approaches available for developers to use e.g. ReactNative, Telerik, ManifoldJS and Ionic.

Pecheersrsonally, I have not used all of them. They all look promising, and they all have their pros and cons. However, recently, I started using Ionic (as it suited my situation perfectly) and am wholly impressed by what Hybrid development offers.

Ionic To The Rescue

My situation entailed a large SPA website, written mostly in Angular, requiring a mobile app to be created that mirrored some functionality of the website.

The thought of having to duplicate the website features, using multiple languages, and then having to support all these codebases, was horrific. We had moved as much logic to the server side as possible, but there was still a great deal of functionality in the website that could not be moved and needed to form part of the mobile app; cue Ionic.


Iconic is a hybrid mobile platform which basically embeds a website inside a mobile app. The website in the mobile app can be a normal responsive html/css/js website but can also utilize various native functionality (e.g. camera, GPS, senors etc) by calling a layer, that sits on top of the native system, called Cordova.

Since Ionic allows you to create functionality in Javascript, and we had lots of Javascript (Angular) to utlilize, Ionic was a perfect fit for us.

Rapid Application Development

Never before I have been so productive developing mobile apps. The productivity gains from using Ionic have been immense:

  • We have been able to share Angular components and services with our web AND mobile apps.
  • If we find a component or service that cannot be easily shared, it forces us to refactor and break down the item into more reusable parts.
  • Quite a bit of CSS can be re-used too (if refactored well enough) to make styling consistent, across not only mobile devices, but web too.
  • We are maintaining and testing a ‘largely’ single code base using a pervasive coding language (Javascript). A problem found on one of the form factors is fixed once and deployed everywhere.
  • One of the biggest productivity gains is with the workflow. Most of the development/debugging can be performed through a web browser. Using Ionic you are able to change your Html/Js/Css and automatically see live changes. No need to start an emulator or wait on the IO between desktop and device. Sometimes, you absolutely need to test something on a specific device, but I find, that for most work, the ‘webview’ suffices.


Not Quite There Yet

There are some trade offs with using hybrid development in preference to native development, not least performance. But for most ‘line of business’ applications the performance is ‘good enough’.

Ionic itself is great and getting better, but has some limitations. Cordova has its limits and ‘idiosyncrasies’ and can be a pain to work with. However, just having to maintain one single codebase between the mobile platforms (with web thrown in for good measure), coupled with an awesome workflow, on apps which are ‘good enough’ for most business needs, and gets an app in clients hands sooner, makes Cordova’s ‘idiosyncrasies’ bearable.


Alternative Viewpoints?

This form of hybrid development has worked well for me but there are so many other workflows and frameworks out there. Has anyone any experience with the other frameworks?

Premature Optimization – My Embarrassing Problem


I have a confession, I prematurely optimize.

Looking for efficiencies in some code you have just splurged seems like too much fun. We have all done it; one moment we are motoring along, knocking features out left right and center, next minute you disappear down the rabbit hole looking for optimizations.

It feels productive though.

What if my app needs to handle 1m users? What will 0.2ms extra download time do to my SEO rankings? Will users go somewhere else if my code is not running as fast as it could?

These are all semi-legitimate concerns, but at what stage does it become essential to address them?

YAGNI (You Aren’t Gonna Need It)

The truth is, most of the times, there are plenty of more fundamental issues to address, most of them related to the question “What do users really care about?”. Optimization is only important after users decide your product is actually worth using, not before.

YAGNI - premature optimization

If anyone asks, in principle, I am totally for the essence of YAGNI (You’re Not Gonna Need It), in practice, however, my track record is mixed. Theory says we should develop minimum viable products, get these products to customers without delay, defer commitment as late as possible for irreversible decisions, reduce waste, reduce inefficiencies etc etc. But far too many times I have spent hours optimizing something which:

  • Delays the time it takes to get to the customer, thus reducing time for feedback.
  • Makes technology selections too early based on optimization concerns.
  • Creates deep and incomprehensible inheritance models, because that’s what a book told me to do.
  • Introduces unnecessary complexity to the solution which developers behind me have to take even more time to learn (decipher).

All on things that:

  1. Weren’t eventually even used in production.
  2. Didn’t need as optimized as much as they were. Not now. Not ever.

This is time I could have used discovering what users actually liked or disliked.

Permission Granted

Hopefully by confessing my problem to you that it is the first step in my rehabilitation. Next time you see me pre-optimizing you have my permission to slap me, Batman style, and shout “YAGNI”.

Deploy a Developer


Most software projects inevitably suffer, especially in the humanitarian domain, unless the huge gap between developers and end users is recognized and addressed.

One of the best ways to do this (reduce the gap between these two diametrically opposed groups) could be by actually embedding a developer in your core team on your next mission or assignment.

Why Do Projects Fail?

Over a 15 year career as a software developer I can attest to the fact that poor requirements definition is the chief culprit for failing projects. I have developed mobile, desktop and server applications, worked for several companies ranging from large corporate companies to small start up companies, in a number of diverse sectors, and the single most challenging problem with creating great software is a reoccurring one; requirements definition. End users and developers can’t, won’t and don’t communicate effectively and efficiently leading to the poor definition and implementation of requirements.


As you can see from the above diagram, the main reason projects fail, by a large large margin, is poor requirements definition; finding our what users need and translating this into solutions.

What’s the Big Problem?

In my experience this big problem could largely be solved by bridging the gap between the two groups at either end of the process: those who make the software and those who the software is bring made for.

But it should be easy right? We are all humans, end users are human, software developers are human (mostly).

How could there be much of a problem of communicating ideas from one group to another?

Well, it turns out, there are two big issues: developer apathy and the requirements gathering process itself.

Issue #1 : Lack of Empathy

The first issue is that transposing the ideas from a non-technical user to a technical/techhie developer (who is more comfortable talking to code than people) is a big challenge. A challenge that the software industry has still failed to adequately address and affects software projects again and again and again.

The problem is that there is a huge gulf in experience, skill sets, even the language used for the same things, between a non-technical ‘ordinary’ user and the people who sit behind desks and write code. Software developers lack the empathy to adequately understand the domain and the users.

Ordinary end users talk a completely different domain language and can have completely different experiences than desk-ridden developers.


End users, come in many shapes and sizes. They can range from the very technical to the not quite so technical.


On the other hand, Software Developers are generally desk ridden, highly technical and actually take pleasure from being able to talk a different language from mere mortals.

How many times have you talked your IT department and felt like they were taking pleasure in talking down to you using highly technical terms?

I will let you into a secret, we absolutely do that on purpose!

Do not underestimate the apathy (and even contempt) that developers have for end users. We view users as inferior beings. Even when users tell us directly that they have problems using something we have built, our first instinct is to scoff and assume it is user error and they should be smarter to use it correctly.

This is genuinely what we think you are doing when you ring us with a problem.

This is genuinely the kind of thing we think end users are doing when they ring us with a problem.

Issue #2 : Noise & Barriers

So with issue #1 the problem is that the two groups have often completely different perspectives and find it difficult communicating with one another. Issue #2 is that, in most software projects, there are numerous barriers placed between the developers and end users by the actual requirements gathering process.

The two groups don’t actually get even the chance to miscommunicate directly. There are layers upon layers to make ensure that, even if a clear message is stated by end users on their requirements, by the time this reaches the developer, it has been changed into something different (a bit like a game of Chinese whispers that a lot of us played in the playground as kids).


The Requirements Gathering Process

Take the above simplified example of a requirements gathering process. We just want to get information from end user to developer in a clear efficient way.

At the start we have the user telling a requirements gatherer of their issues.

The gatherer generally translates these findings using their own domain knowledge into a series of documents.

These documents are reviewed by a ‘middle manager’ who filters and translates the raw requirements, again using his/her own judgement.

The middle manager produces a set of faceless requirement documents which are passed to the developer to develop.

At each step some ‘understanding’ of what the end user wanted to express is lost or mistranslated by people and paperwork.

Then, when refinements are needed, the process starts all over again.

The problem?, too many steps and too many intermediaries.

Lets get these two groups talking to, and understanding each other, a bit more. Wouldn’t it be far more effective and efficient if these two groups were allowed to communicate directly with one another?

Of course it would, but because of Issue #1: the fact that they don’t even know how to talk to one another, it is also pretty impractical.

So how do we make it practical?

Turning Apathy Into Empathy

I am not saying it is easy to achieve.

Developers don’t necessarily want to come face to face with users.

Users may feel frustrated with the prospect of having to communicate with (sometimes) abrupt and condescending developers, but, from experience, the most productive and effective projects that I have worked on have involved the end user communicating directly with the developers from day 1.

Not only is it more productive for the two groups to communicate directly but it also increases the chances that the solution produced will be usable (i.e usable by the end user), useful (actually solves a stated problem) and used (not thrown in the bin like so many other projects by users. Users will have actively participated in the creation of the solution, and have a stake in the solution created.

So here my tips, based on experience, of how to help bridge the gap between developer and end user.

  • Get developers out of the office (Genchi genbutsu). Get developers out of their comfort zone. Consider deploying them on your next mission to get them to start to understand the domain and gain empathy with users. We need developers to attempt to understand users better, having empathy with end users not only increases the understanding of the domain but also gives developers incentive to make better choices during the development stage. Giving a human face to a requirement, as opposed to a faceless requirements document is hugely influential on the decisions that developers make. This type of understanding and empathy should not be understated in affecting the quality of solution your developers produce!


  • Use Visuals. Using visuals, rather than language and documents to share ideas cuts out a lot of the potential miscommunication issues and helps to speed up the software development process. Best to use visuals and prototypes, both developers and uses both speak this language!


  • Develop a common domain language. Right from the beginning set out a Common language for communication, try to find a common denominator to terms and phases used by both sides.


  • Regular Feedback & Pilot Exercises. Fail Fast. Fail Often. Facilitate a consistent, regular, and always open, channel of communicating. Frequency is key here. For example have a weekly show & tell from developers on progress and the direction they are currently taking, allow feedback from end users that will be allowed to have an impact of the future direction of the solution. Build it, scientifically measure the feedback, and learn from the lessons end users are teaching you.


  • Customer Champion. It may be impractical to keep going back to all the end users regularly, but at least make sure that you have a representative user who can be called upon regularly to give feedback on choices and solution direction.


  • Hire a Software Developer with domain experience. Find a ready-made developer who already understands the domain. If you are lucky enough to find a developer with domain experience, hire them, your project will thank you for it.


  • Consider an Innovation Hub. Bring the development team permanently closer to your organisation by housing them beside your team. See Andrej Verity’s recent blog post for some great advice on how to do this in a humanitarian context.

A Challenge to You

So the challenge I put to you is, “will you consider deploying a developer with your team on your next assignment?”

Are you willing to stand up to your own IT department or IT contractors and demand a more closer working relationship?

Are you willing to drag developers kicking and screaming away from their desks and into the field? Believe me, as a developer myself, you will face resistance with this!

That is the challenge to you, it would not be a challenge if it wasn’t challenging, if it wasn’t difficult!

Procrastination is productive


“Procrastination is productive”

Sounds crazy right? But my experiences with software development has shown me time and time again that procrastination on certain tasks can be the ‘correct’ and productive way to approach even crucially important tasks.

Please let me explain. I usually organize all my development tasks on some sort of Kanban board ordered by priority. Normally the advice is to take the top item off the list or to choose the biggest, nastiest task/’frog’. This type of approach is advocated by Brian Tracy in the mostly awesome book ‘Eat That Frog‘), and, in general, this is solid advice.

However there are times when I look at the top task and lose the will to live! Sometimes the problem seems too difficult/long/important to solve immediately. Rightly or wrongly, what I tend to do is to leave this nightmare task at the top of the list and ignore it. Instead choosing a much easier, but related, task, further down the list i.e. procrastinate.

Why? Because experience has taught me that these kind of tasks will bog the project down. I am not ready for it yet. The project is not in the right state yet. Things change. Requirements change. This is not a ‘quick win’. The decision to act on this task needs to be deferred until I am older and wiser.


Defer Important Decisions Where Possible

Now, I am not advocating always doing nothing, these tasks are usually fundamental tasks that need consideration. When a fundamentally important decision can be deferred I usually will defer. By waiting until the last minute to make a decision not only gives maximum flexibility to the project but it is also made when more knowledge about the problem has been gained. For example, if the task is a fundamental one like ‘Choose a database technology’ this raises alarm bells immediately. When the full extent of the expected solution is not known and an obvious choice is not prevalent, then this a risk which should be deferred. If I can choose not to address this task now, then I wont. For me, a solution in a case like this would be either not to choose a technology at all yet or choose a technology that I am familiar with but make sure that any implementation can be swapped out with another technology at any point i.e. procrastinate but engineer some ‘wriggle room’ (please please read Mary and Tom Poppendieck’s book ‘Lean Software Development: An Agile Toolkit‘ for some fantastic practical advice on what software development priorities should be).

Eat That Frog?

So what should one do? In software development, should we follow Brian Tracy and Eat the largest ‘frog’ (task) first or should we eat smaller, tastier ones until we get good at eating frogs and make sure that the bigger one isn’t poisonous?

Email Vs Slack


Email Deluge

My email inbox is an embarrassment; with almost 3000 unread emails I can safely say that I am at my least productive (and most depressed) when I log into this shambles.

I am not quick-witted enough, or know enough small talk, to hold regular snappy, productive telephone calls. Email allows you the time to reflect on what I need to say and the ability to reply at my own leisure, but there must be a more productive way of communicating ?!?.email vs slack

There is a lot to be said for new social media channels for receiving and sending information, but email still remains the most popular medium for sending and receiving work related information (with most of us spending around 13 hours of our work week using it). However is this trend changing with tools such as Slack and HipChat gaining popularity?


Slack FTW

The short answer seems to be ‘No’; email is here to stay (it is too big to fail), either start managing your email better, use some productivity add-ons to help sort out your email mess, or integrate your email channels into an awesome tool like Slack. The ‘Slack’ way of communicating is ‘better’ than email but email is so ingrained within homes and businesses that tools such as Slack must ‘adapt or die’ rather than the other way around.

How does everyone else cope? Do you have a favorite add-on to help sort through your email? Has anyone successfully transitioned over to Slack or Hipchat?

Clean Code Tools


Writing code is an inexact science, imperfections in your code are inevitable and add up.

Having a tool that constantly nags you to strive for perfect code is a must have for flawed [see human] developers.


Compiled Code

Where code analysis tools really excel is with compiled code.

With compiled code, the clean code tools not only analyse the quality of your code but also automatically fix and style it!. With compiled code you get piece of mind when these ‘automatic’ changes are made because the compiler is there to reassure you.

Thank God for Resharper!

I use these type of productivity tools religiously; in particular, for any C# or JS code that I write, I always use/need Resharper from JetBrains.

resharper_stylecop clean code

Some people might say that it is ‘lazy’, letting a productivity tool ‘automagically’ do what you should be doing out of hard learned habit. I agree, it is lazy, and I am often sloppy with my code knowing that my ‘magic helper’ will clean up after me. But, I have found that, after a while, I start incorporating the suggestions and changes that the tools give me into my ‘unclean’ code, so that the tools have less work to do and my code becomes cleaner ‘naturally’.


resharper uninstall clean code

Too much of a good thing?

However, you can go too far with these tools.

Not only do you start to rely heavily on these types of tool to do a lot of the basic coding for you but also some of the suggestions it make for code changes can lead to your code becoming less ‘human readable’. It is soooo tempting to accept the suggestions to lambdify or linq entire sections of your code just because Reharper tell you to do it and it compresses your code to a single line. I thoroughly recommend watching the clean code Pluralsight course or reading Robert Martin’s (uncle Bob) book on clean code, to understand why human readable code is so important.

resharper - clean code


Interpreted Code

Things get more trickier with interpreted code e.g. Javascript. With interpreted code you do not have the compiler to reassure you that any ‘automagic’ changes are ‘safe’. For this reason, most clean code tools for interpreted code will give advice, rather than make changes for you. However, the ‘linting’ tools for interpreted code (JS in particular) have come a long way and are an essential part of any coder’s utility belt. For instance, when writing Javascript code I now rely [heavily] on Douglas Crockford’s JSLint to tell me that have been a naughty boy (I would highly recommend all Javascript developers to read Douglas’s book: Javascript The good parts and watch his talk on pluralsight) about Javascript.

jslint - clean code

What lint/analysis/style/refactoring tools do you use everyday and cannot live without? Leave a comment below:




Some much to learn, so little time.

Apart from ‘dark matter programmers‘, most developers are faced with the uphill struggle to find the time to continuously keep up to date with the industry. To paper over my (many) technical shortcomings I tried out some of the prominent online course providers and was extremely impressed.

The software industry moves so fast that keeping up to date with the latest tech and processes is virtually impossible; unless you do it virtually.

Brave New World of E-Learning

When I first tried online learning I was a bit skeptical that it could match the learning potential of ‘traditional’ methods. However, mainly due to the way you can learn at your own pace, I now would not want to learn any other way.

Institutions have big reputations from years of delivery. However, in this brave new world the methods of delivery are changing and new reputations are being formed.

Using this type of learning has a number of benefits for time starved developers:

Flexible. Finding spare time as a software developer is not always easy. We are fortunate enough to be in an industry which is currently booming and that means there is plenty of work to be done. Online courses are perfect for time-constrained individuals as most courses allow you to work, more or less, at your own pace and at hours of your choosing

– Accreditation. Many of the providers now offer “recognized” accreditation on completion of a course. How “recognized’ the qualification is largely depends on who is judging. For example, your next potential employer might not have heard of Pluralsight and its qualifications but might be a personal user of Coursera and is well aware of its merits/shortcomings.

Wide Variety. The course providers currently have a huge library of every type of subject and there libraries are expanding every year as e-learning becomes more popular.

Cost. Some are free but the rest are paid for. On the whole though, e-learning courses are generally cheaper. If you compare the cost of ‘taught’ industry courses that require you to travel to the trainer’s location, there is no comparison.

What I didn’t like

This type of virtual learning is not everyone’s cup of tea. Quite a few people can be put off by the impersonal nature of the courses. Without a lecturer to interact with and a physical text book, some just do not see anything else as ‘learning’. Most of the online course providers do try to simulate these inter-personal connection with the student, but in reality it is half-baked at best.


I personally had trouble making sure that I kept enough time free in my schedule to make sure I completed the courses fully. Sometimes I really needed was a lecturer or dean making sure I kept on track.

Despite the disadvantages I can thoroughly recommend trying some sort of online learning; there is a surprisingly diverse catalog of courses out there, most of them very well thought out content and delivery.

Horses for courses

However, not all the online providers have the same range of courses, I find that some providers are better for certain topics than others.

The providers that I regularly use for different topics are as follows:

Pluralsight – Great for technical training such as web and server training.

Coursera – Great for specialized accredited courses from recognized universities.

Udemy – Great for social/personal development type courses.


Other providers do exist and i would be interested in hearing what else is available and your experiences with them?