Javascript quality analysis with SonarQube

At Surevine SonarQube plays an important part in ensuring our development teams produce software of good quality. We use SonarQube as part of our continuous integration setup, ensuring that we automatically get the latest view of the quality of our projects, accessible via an easy-to-read web interface at a well-known URL. SonarQube also centralises our quality profile / rule configuration which is really handy when working across multiple projects. Overall, we’re fans of the system and I’d thoroughly recommend checking it out if you haven’t already.

Historically, we’ve used SonarQube analysis primarily for backend components based in Java and PHP. More recently, we’ve wanted to apply the same quality checks to our front-end components, as they too should meet our expectations of quality. Here’s how I added Javascript analysis to our SonarQube setup.


  • SonarQube installation
  • Javascript based project to analyse

SonarQube Javascript plugin

The first step is to install SonarQube’s Javascript plugin, which essentially informs the system about the Javascript language and provides a set of rules to enforce.

Follow SonarQube’s official instructions on how to install a plugin.

Sonar Scanner

The next step is to configure your software project to invoke Sonar Scanner (the SonarQube component which performs the code analysis).

There are various ways to do this depending on your technology stack.

The most tech-agnostic way of doing this is to directly download the scanner, create a properties file and invoke the binary manually (as described here).

Alternatively, there are wrappers available for most of the popular task runners / build systems, which will be much more convenient to setup and use if you already have a runner in place. The project I was using to test the setup used grunt for task management, so I opted to use the grunt wrapper. The instructions below reflect this, but the process will be much the same if using another wrapper.

Grunt Wrapper

To install the (grunt wrapper)[] of the scanner, invoke the following command from within the project’s root directory:

npm install grunt-sonar-runner --save-dev

Next we need to load the plugin by adding the following line into our Gruntfile.js:


Finally, we need to configure the scanner, providing details on the location of SonarQube, as well as the source files we want it to analyse. To do so, we need to add a sonarRunner configuration object following options to our Gruntfile.js.

sonarRunner: {
    analysis: {
        options: {
            sonar: {
                host: {
                    url: ''
                login: 'sonar-user-name',
                password: 'sonar-user-password',
                projectKey: 'project-key',
                projectName: 'project-name',
                projectVersion: '1.0.0',
                sources: ['src'].join(','),
                language: 'js',
                sourceEncoding: 'UTF-8'

Of course you will need to adjust the values you use to reflect your SonarQube installation and project.

Its worth noting the documentation for the wrapper is missing some important details around authentication. In order to populate SonarQube you will need to provide login & password properties using the username and password of a valid SonarQube user (as shown above). Alternatively, you can use a login property alone, and provide a SonarQube auth token as the value (in which case no password required).


Once configured, you can invoke the analysis by performing the following command from the root directory of your project:

grunt sonarRunner:analysis

Once Sonar Scanner was configured, all that remained was for me was to hook this up to our CI server. We use Jenkins for our CI, so a quick modification of the project’s JenkinsFile (groovy script) to invoke the new grunt task (shown above) was all that was needed. We now have static analysis of the Javascript in our front-end component being performed on every commit.

The next steps for us will be to add code coverage reporting into this setup, which I will follow up on in another post.

Successfully working from home

I’ve been working from home for approaching 5 years now at Surevine, a fully distributed software development company. Home-working is a major part of the company culture, and is one of the main things many of us love about working there.

I somewhat accidentally fell into working from home, it was never a huge ambition of mine. When I joined Surevine that aspect of the job was actually a deterrent of sorts - I was concerned about the impact it would have on my professional development. Nevertheless, I decided to give it a go, and five years down the line, I haven’t looked back.

Many of my friends state that they could never do it. They ask “How do you avoid just watching TV all day?”. Perhaps it’s true that home-working isn’t for everyone, some people absolutely need the hustle and bustle of an office (or maybe even the commute!?). For me, the pro’s far outweigh the con’s; the 30 second commute, an improved work/life balance and greater control over my working environment all contribute to a more enjoyable work life. The reduced commuting costs are also pretty nice too. As for the TV thing, if your work is interesting enough then it won’t even be on your mind.

It’s easy to see why more and more companies are offering this to their employees in whatever capacity they can. However, I don’t believe that successfully working from home is as straightforward as some people assume. It’s taken quite a while to get to the point where I feel my setup and patterns are “just right”. I’ve been refining my home-working setup since I joined Surevine, and I’ve made some mistakes along the way.

Below are some of factors & habits that I think have been important in making this way of working a success for me. Some of these will probably seem pretty obvious, but I’ve seen people falling foul of them in the past so I’ll include them anyway.

Key factors

I believe that the most crucial factor in a sustainable home-working life is to dedicate a space (preferably a room with a door) to your work. This brings enables a clear separation between your work and personal life. When you shut the office door at the end of the day you know you’re done (if you want to be). I’m lucky enough to have an office separate from the house, so having to go outside between the two adds a further disconnect which I find helpful (and also means family members are less likely to come running in).

Coupled with this is the rule I have to only work when I’m in my home office. This makes it far easier for me to relax of an evening when I’m in my living room, as my surroundings are not synonymous with work. Likewise, its easier for me to focus on work when I’m in the office as its the only thing I do there - there is no crossover of habits / mental modes.

The second factor may or may not be relevant depending on your personal circumstances, but establishing clarity with family members about what it means to work from home is really important. When many people hear the phrase “works from home” they think “works for themselves” or maybe even “doesn’t really work” (which is certainly not the case). In turn, they can assume that you have complete freedom to do any number of social activities at the drop of a hat. Of course the reality is that whilst home-working does introduce greater flexibility to interact with family and friends, there are still meetings to attend and deadlines to be met.

Clear conversations to dispel these myths are important in avoiding awkward scenarios (such as when family members drops in for a coffee at no notice when you are in the middle of a meeting with your boss). The specifics of what you need to say will come down to your own job and preferences, but covering your regular work schedule and what this means for availability is probably a reasonable start.

The next factor is one which may not be entirely under your control. It is important that the company you work for is properly prepared for home or remote working practices. From tooling to culture, remote workers needs to be first class citizens, equal to their in-office counterparts (if applicable) in every way. It sucks to be working remotely and be omitted from conversations you care about because your colleagues forgot to dial you in to a meeting, or the technology failed in making it happen.

Software can make a big difference here. Having the right set of tools for communications is essential in preventing people from feeling disconnected. I don’t think that email alone will cut it. At Surevine our primary means of communication is Skype, with a policy to use video calls wherever possible - it’s suprising the difference that seeing people’s faces makes! We also have an internal micro-blogging platform which serves as the cultural heartbeat of the company, and is actively used by everyone.

Importantly, these tools and methods are the same for everyone in the company, regardless of whether they are working from home, at one of our offices or on the road. Everyone is using the same platforms to communicate.

Working for a distributed company like Surevine means that the focus on accommodating remote-workers is more likely to be in place - as the company simple wouldn’t function if we couldn’t easily interact with each other, but it’s definitely achievable for “standard” employers too.


Along the home-working journey, I’ve also formed some habits or patterns that have made it more enjoyable (and maybe even more sustainable) for me.

The first of which is to ensure I go outside every day, regardless of the weather. This probably sounds bizarre to some of you, but in the early days I could go 2-3 days without leaving the house as I had everything I needed at home. If I didn’t have plans with friends then this could happen quite easily. I found that this left me feeling strangely insular, and when I did interact with people I wasn’t quite myself. Whether its a walk around the village at lunch, or a run after work - leaving the house every day seems to prevent this feeling.

Something I’ve introduced more recently is to wear certain clothes “to work” (in my case this is generally tech t-shirts), then change into different clothes when I finish. This helps my mind to reset, which I suppose is similar to the dedicated working space factor described above. I’m aware that this is an entirely artificial process, which isn’t necessary at all, but has helped me maintain the separation between work and home life.

During the day I’ve started to have podcasts or audiobooks running quietly in the background. I find the ambient noise helps to stop me feeling too isolated or disconnected from the wider world, whilst not being too distracting. I can’t be sure but I’d guess that this also helps with my productivity too. I think that some people use music to fill this void, but I prefer the conversational tone on podcasts/books and appreciate the occasional learning snippets it can provide.

Finally, I’ve learned to be mindful of what I eat at lunch. Being at home with a full kitchen (and freezer) is both a blessing and a curse. When it comes to choice and cost its great, but this has meant that from time to time I’ve eaten far more than I probably should have for days on end, without the exercise to go with it. This might not be something high up your priority list, which is fair enough, but for me, I like to be reasonably healthy and so needed to make adjustments. I still benefit from a vast amount of choice, but tend to opt for something on the lighter side for lunch, and try to limit how often I open the ever-tempting biscuit tin.

So those were some of the things that I’ve put in place to help make my time working from home an enjoyable and hopefully successful one. I’d like to stress that the contents of this post are just what works for me. It’s clear from a glance into my colleagues’ offices via Skype that the optimal home-working setup varies tremendously between individuals. If you are considering working from home I think its worth spending some time planning the transition, and iterating thereafter to make it work for you. Firing up a laptop on the sofa in the corner of the living room might work for the odd day, but I seriously doubt it will be sufficient in the long run.

If you’ve read this post and are already working from home, I’d be interested to hear about any tips or habits you have picked up along the way.

Getting Started With Yarn

A couple of weeks ago Facebook released Yarn, and alternate package manager for the web that is compatible with npm repositories.

When I first heard about it, my initial reaction was along the lines of “is this really necessary?”, npm works ok and is now commonplace. Do we really need another component in an already complex Javascript ecosystem? However, I believe that there is always room for improvement, and anything that aims to make a developer’s life better is worth looking at.

Yarn is a drop-in replacement for the npm client, and supposedly improvement upon it in various areas including:

  • Performance
  • Security
  • Reporting

For more details on Yarn’s features and advantages, please read the official documentation or this comparison post.


For OSX/MacOS, the recommended method is to install using homebrew:

brew install yarn

Its also possible to install with npm, but this feels somewhat wrong.

npm install -g yarn


Once installed, you’re able to use yarn for both new projects, and existing ones that currently use npm for package management. For the latter, (where you already have a package.json), you simply need to invoke the following command from your project’s root directory.

yarn install

It’s as easy as that. This will instruct yarn to fetch all of the required dependencies for your project. If the process was successful, you should find a yarn.lock file in your project’s root directory. This is the equivalent of the package.json from npm that you’re probably familiar with.

For a new project, you’ll need to initialise Yarn in much the same way you would with npm, by executing the following command from the root of your project:

yarn init

Once Yarn has been initialised, it is ready to manage your project’s dependencies. The CLI commands differ slightly in places to their npm counterparts, but they remain intuitive and easy to remember. I won’t duplicate the entire API in this post, but the core commands are as follows:

yarn add <package> // adds a new package dependency
yarn update <package> // updates an existing package dependency
yarn remove <package> // removes a package dependency

No suprises there, which should make the transition from npm to yarn a smooth one.

First Impressions

It’s early days for Yarn, and I haven’t really had enough time to cast too much of judgement on it yet, but so far it seems pretty good. It’s quick to set up and transition to for an npm-based project (as you can hopefully see from above).

I’m particularly fond of the improved output/reporting, especially during a yarn install. I think it’s much more readable, and provides a better picture of what it is currently doing / how much it has remaining.

Whilst some of the security improvements are less headline-grabbing to most of us, they are essential and we would feel the pain badly if they weren’t in place.

I believe that performance will ultimately be where this battle is won or lost. Lengthy npm install’s have become notorious, and if Yarn can make a serious dent in them then I can see it being very popular.

It will be interesting to see how this influences the npm client moving forward. I for one really hope that the npm compatibility is retained. If this is lost, it will be more effort for developers when publishing or retrieving packages to/from multiple repositories, which would be a backwards step in my view.

For the latest updates on Yarn, follow @yarnpkg on Twitter.

Angular Connect 2016

A couple of weeks ago I attended Angular Connect at the Excel arena in London. This was my first time at Angular Connect (or any AngularJS conference for that matter), and having watched the 2015 sessions on YouTube I was extremely excited to attend. As it turns out, this was pretty much the perfect time to attend an Angular conference, with 2.0 final being released just days beforehand.

Personally I haven’t yet used 2.x in anger as the last couple of projects I’ve worked on have required more stability than the beta period offered. During the weeks leading up to the conference I played catch-up and spent some time learning the 2.x ropes through various online tutorials. The jump from Angular 1.x to 2.x is huge - which is great as many changes were needed to bring it up to date, but also somewhat intimidating. I’m glad I spent the time to do this as otherwise the more technical talks may have been overwhelming. I plan to write a separate post on my forming thoughts on Angular 2 as a newcomer.

The conference offered 2 standard “speaker” tracks, as well as a mini-workshop track, an office-hours track and a panel Q&A track. I mostly focussed on the main speaker tracks as I find I get the most out of these, and wanted to cover as much ground as possible as I’m still getting up to speed.

The schedule was really well assembled, and across the two days there were very few slots that I wasn’t excited for. Far more common was a tricky decision about which track to attend. There were talks covering the entire gamut of front end development from UI design and animations, to the CLI and performance optimisations. Generally, each talk covered how to use the feature(s) and what was new/coming soon in the given area (some of which is really exciting). It was particularly good to see more specialist areas such as application security also getting coverage.

I also sat in on some non-technical talks, including a very funny one by Shai Reznik on the strength of the Angular community - which felt somewhat comforting given the negativity which seems to surround AngularJS at times. If Connect was anything to go by then I’d have to agree that the community is awesome and the framework is pretty great too.

Without exception each talk I attended was compelling and well delivered. The majority of the speakers were either core-team developers or prominent community members, which ensured the content was accurate and insightful. If you didn’t attend, I’d encourage you to take a look at the YouTube channel - tracks one and two were both recorded and I believe that all sessions have now been uploaded - well worth a watch.

Overall I thought this was a brilliant conference, the best I’ve been to by some way. The speakers were great, the event ran to schedule, and the food was awesome – it even had its own beer. Without a doubt I’d highly recommend it to anyone even remotely interested in the Angular framework, there’s something for everyone in there across the various tracks. Hopefully see you there next year!