Thursday, 7 August 2014

Am I becoming an Apple Fan boy?

We are going to leave Nerf guns and office battles to one side for this blog post. It is nice that my colleagues (and even my boss) read the blog as they all commented on it.

Today, I am planning to talk about what made me purchase my first ever Apple product the wonderful MacBook Pro Retina 13".

So lets talk about the journey to this purchase. 

I say journey as those people who know me personally and read this blog know that for many years I disliked, maybe even hated all things Apple! To be honest, I am not sure where this dislike came from as many of the principles Apple holds in its products do appeal to me, such as making the complex simple, beautiful and elegant design and so on.

It wasn't until my long time girlfriend moved in with me that I had Apple products in the house. I begrudgingly even let her install iTunes on my Windows PC! I had never used an Apple product as they were far to expensive but she brought her iPhone and iPad. Slowly, I fell in love (and not only with the girl!). This prompted me to read the outstanding biography of Steve Jobs by Walter Issacson which I have blogged about in the past. What a visionary Steve Jobs was by the way!

Anyway, over time I have increasingly wanted to purchase a Mac and experience what it was all about. So when Apple announced they had updated the MacBook Pro and lowered the price that was it, I was ready to make the commitment and buy my first Mac, in fact I actually bought two!

WOW! What a great product! It is without doubt the best laptop I have ever owned and I can say hand on heart I don't use my Windows PC anymore at all. In fact when Apple get around to releasing the new Mac Mini, that will be replacing it!

To anyone reading this who is thinking, why pay £999 for a laptop you could buy for £600? I say this. 
Yes, you could buy a laptop with the same parts for £600 but then you'd miss the experience it gives you! And yes, it is an experience. The ease of use, comfort, and so on. This experience is absolutely priceless!
Come on in, the water is lovely.

P.S. I wrote this on my Mac!

Sunday, 20 July 2014

Do Nerf guns matter?

Last Friday (18th July) we were having one those typical Friday afternoon chats where we were discussing the pros and cons of introducing Nerf guns into our office. 

I know its an odd conversation but hey it was late on a Friday afternoon and actually it was more a discussion about the type of working environment we are wanting to create.

Recently where I work people are beginning to bring in Nerf guns and shoot each other. We also have some XBox consoles and a table tennis table. I love the XBox and Table Tennis as sometimes having that 20 mins of mindless fun when I get bogged down on a development problem can help me refocus but I am beginning to think the Nerf guns are a step too far and actually though well intentioned are the wrong solution to a perceived problem.

One colleague of mine (in our chat) was very keen on it, saying that on his floor (which is full of technical staff) it had been a great success and provided some light relief. On the floor I work on, there are not as many technical people and most of my colleagues around me are "business types" with suits and formal working styles. We were saying that the Nerf guns would come across as a distraction and could cause issue with how the development team is seen by other teams.

After this discussion I decided to look on-line and see what others thought about such things and I came across an interesting post on the subject by Mike Crittenden (@mcrittenden) "Nerf guns don't matter" (

I agree with many of the points Mike makes, I agree with the main aim of work should be to do the work and as such the work should be rewarding and challenging meaning toys are not needed. Personally, I like where I work and I am lucky as I have said before to work with some very smart and interesting people. On my project, I work with some excellent modern technologies and I find the majority of my work rewarding and challenging. However, I am sure some of my colleagues on legacy projects wouldn't agree that their work is rewarding to them, in terms of enhancing their skill set.

The company I work for is not a software company. I work in a development department within a company those main focus is working with data, displaying this data and providing insight to customers, many of whom work in financial services where formality can make the difference between getting and not getting a contract. 

Within the company the development team do want to create a bit of a "start-up" feel within the team but I feel this might affect how other teams (who are much more formal) view us and then ultimately interact with us. I mean what would you think if you brought a client to look around the office to find development having a nerf war with the testing team (

Please understand, I am not saying I want to turn where I work into a "sweatshop" with no fun at all, extremely formal processes and wearing suits all the time. I try to avoid wearing a suit as much as possible but I accept at times I might have to. I decided to work for a respected Data/Financial services company, as a developer this comes with many pros and some cons. If the cons (such as formal working style) outweighed the pros then I would leave, but it seems we are trying to turn where we work into something it isn't (i.e. a software start-up). 

I am not saying we shouldn't tweak some things, such as not wearing suits to work and coming "smart causal", but we must be mindful of the other teams we work with and their needs. I would say if people want this start-up feel and the freedom that brings go work for one with the risk that involves, it seems that some developers are trying to have their cake and eat it.

Rather than toys, lets spend our time making ALL the projects rewarding and challenging. Lets keep all the developers motivated and engaged by enabling them to produce great work, this is where we add value to the other teams and thus the company we work for. 

Ultimately we must remember...


Tuesday, 1 July 2014

DevOps: My Thoughts

I have received a lot of feedback about my blog post and twitter comments about "How 'DevOps' is Killing the Developer".

I thought I would write a post summarising my current thoughts about DevOps.

I'll be honest before it was introduced at work, I knew nothing about it. I hadn't heard the term before so like all new things I was interested in finding out more. Like, many people I used the internet to do some initial research and I am nervous about what I have read. 

When I Googled the term:
 "What DevOps means for developers?" 
 The first article was a Wikipedia link, which stated that:
The goal is to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.
And I was thinking this can only be a good thing. I doubt anyone (not even me) could disagree with this. The next article was more information from a website called The Agile Admin which I only really glanced as it was a bit long but the parts I read seemed to positive.

The next article was the blog post, I linked in my last blog post. 

"How 'DevOps' is Killing the Developer" and I was thinking this must be an alternative point of view, which in my book can only be a good thing. Thus the reason I posted the link on this blog. Anyway, as I read it, I was fearful that "DevOps" could be misinterpreted to mean that developers do all the work. 

Having worked in the Software Development industry for many years, I have experience of good ideas been misinterpreted and causing much angst. You know what they say:
"the road to hell is paved with good intentions"
At this point let me be very clear, I like where I work and I don't think this will happen as I am lucky to work with some excellent and very skilled people. But the seed had been sown in my mind.

The only bit of the blog post I disagreed with was the section called the "The Totem Pole" as I thought it is a bit arrogant to put developers at the top and suggest they are the most important members of the team. 

ALL the team members are vital to the successful implementation of the project. Each member brings a skill set and a view point which when combined successfully can make wonderful products.

The purpose of this post is to say I want to understand more about DevOps and how it could work at my workplace. Initially, I am a little nervous about what it might mean for me as a developer. Anything that reduces the amount of time I am developing, I think, is a bad thing. When I am developing software I am adding business value and that's what I want to do!

I agree with the goals I read in Wikipedia and want to try and achieve them in my development work. This will enable me to add even more business value and that keeps me in work, which is a good thing!

EDIT: This is quite a nice summary about the "How 'DevOps' is Killing the Developer" blog post. It covers many of the points raised and offers some counter points. Interesting stuff.

Why DevOps Matters To Developers - another nice blog too, worth a read.

How DevOps is killing the developer!

Where I work at the moment, there is a current drive to introduce "DevOps". 

In our local development blog posted the post below:
I know this post will not be popular as it goes against the current in fashion stuff and people will say "Oh, here goes Scott again!" but if you believe in something strongly enough then you should be happy to discuss it and at times defend it. 
I have always wanted to be a developer and I find it insulting that some people seem to think this is not enough!

In the post I loved the example he gave about his father a dentist and I feel this sums this up perfectly: 
"My dad is a dentist running his own practice. He employs a secretary, hygienist, and dental assistant.

Under some sort of "DentOps" movement, my dad would be making appointments and cleaning people's teeth while trying to find time to drill cavities, perform root canals, etc. My dad can do all of the other jobs in his office, because he has all the specialized knowledge required to do so.

Such a movement does a disservice to everyone involved, except (of course) employers. What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work) and lower-level positions simply don't exist." 
The truth is when I read this post it summed up what I think. I am sorry about that but we don't have to always agree, that's what makes a team great!
What do you think? Am I wrong? Have I misunderstood what "DevOps" is? Do you feel the same?

I'd love to know. 

Wednesday, 11 June 2014

Shaping up with Angular.js

It has been a while since my last post, and I am working on a blog post showing the testing of chained promises in Angular.js using Jasmine. 

Until then, if you are interested in learning about Angular.js then CodeSchool have introduced this wonderful interactive course. 

I came across this by accident and I cannot say I have watched all of it but the bits I have seen it looks good, especially if (like me) you like interactive learning.

Whilst we are on the topic of learning about Angular, I highly recommend watching the excellent introduction video by Dan Wahlin called AngularJS Fundamentals In 60-ish Minutes, the video is embedded below or linked here.

Happy Coding

Saturday, 3 May 2014

Javascript Testing using Node.js, Karma, Jasmine and PhantomJS: Part Two - Configure Karma and Running some (simple) tests

Hopefully you are reading this having managed to successfully set up the environment, so now I am going to describe how I got it running some (really) simple tests.

[If you haven't got it running then a guide of how to do this is here]

In a later post we will look at some more detailed examples using angular but I felt that I wanted to cover a simple example to show you how easy it is to get this working.

Code Under Test

We are going to write a simple Person class in JavaScript and have the following folder structure for our project:

Person Project (root folder)
person.config.js - karma configuration file (more on this later)
\js - JavaScript source files (Person.js)
\js\Spec - Jasmine Spec files (Person-spec.js)

For the purpose of this blog we have written a simple test class.

 function Person(gender) {  
      this.gender = gender;  
 Person.prototype.gender = '';  
 Person.prototype.getGender = function(){  
      return this.gender;  

This is a very simple JavaScript file, which allows you to construct Person objects with a given gender and view that gender using the getGender method.

We want to test that we can construct Person objects with a given gender and then we also want to test we can get that gender via the relevant method.

 describe("Person", function() {  
   it("create a man", function() {  
     var man = new Person("male");  
   it("create a woman", function() {  
     var woman = new Person("woman");  
   it("get a persons gender", function() {  
     var man = new Person("man");  
This is a fairly standard Jasmine file, in which we have three tests. In the first two we create Person objects for a "man" and "woman", the third test creates a "man" and then calls the getGender method and checks its result.

How do I test this in Karma?

Now we have written our code we want to run our tests and check everything works as expected. To do this we need to open a command prompt at the Person Project (root folder) and type the following command:
karma init person.config.js
This will ask you a series of questions and then generate the person.config.js file. When running this command you are free to name your config.js file whatever you want to call it.

Once you have completed the questions, it will generate the file for you but before we are ready to run our tests there are some tweaks we will need to make. Or alternatively you can just write your own config.js file.

1:  // Karma configuration  
2:  module.exports = function(config) {  
3:   config.set({  
4:    // base path that will be used to resolve all patterns (eg. files, exclude)  
5:    basePath: '',  
6:    // frameworks to use  
7:    // available frameworks:  
8:    frameworks: ['jasmine'],  
9:    // list of files / patterns to load in the browser  
10:    files: [  
11:            'js/*.js',  
12:            'js/Spec/*-spec.js'  
13:    ],  
14:    // test results reporter to use  
15:    // possible values: 'dots', 'progress'  
16:    // available reporters:  
17:    reporters: ['dots'],  
18:    // web server port  
19:    port: 9876,  
20:    // enable / disable colors in the output (reporters and logs)  
21:    colors: true,  
22:    // level of logging  
23:    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG  
24:    logLevel: config.LOG_DISABLE,  
25:    // enable / disable watching file and executing tests whenever any file changes  
26:    autoWatch: false,  
27:    // start these browsers  
28:    // available browser launchers:  
29:    browsers: ['PhantomJS'],  
30:    // Continuous Integration mode  
31:    // if true, Karma captures browsers, runs the tests and exits  
32:    singleRun: true  
33:   });  
34:  };  
In this file you will need to add/change the following
  1. Add/Check your files in the list (see lines 10-13)
  2. Check browsers make sure you select "PhantomJS" (line 29)
  3. Set "singleRun" to true (line 32)
Feel free to add and configure this file as you like. There are lots of examples on the internet of this file.

Running the tests

Now we have the code, the tests and we have configured Karma we are ready to run the tests, to do this we enter the following command:
karma start person.config.js
Using the config.js file above that will produce the following output on the command prompt:

Basically, that is it! Simple.

You can play around with the settings in the config.js and this will effect the output in the command prompt window. In my experience with this, it is very easy to include this stuff into your automated build and if your tests fail you will get good feedback. 

Below is an example when I failed a test and what feedback you get:

Another thing I found to be excellent about this stuff, is how quick it is. In these examples, which I know are not the best, they show how quick these tests run. This is why I prefer "headless browsers" as the tests would run well in Chrome, Firefox and alike but they would be slower. Even for this simple example.

I know its not very scientific but when I ran these tests 3 times for PhantomJS the average was 0.007 seconds but in Chrome the average was 0.032 seconds, still really quick but much slower that PhantomJS.

I really like headless browsers but Karma is great as you can use other browsers if you want. You can even use more than one browser so you could use both Chrome and PhantomJS if you wanted to. This works by running the tests in the first browser then running them again in the other.

We have only scratched the surface with stuff! Exciting huh!

Happy coding, happy testing, happy days!

Friday, 2 May 2014

JavaScript Testing using Node.js, Karma, Jasmine and PhantomJS: Part One - Setup Environment

Recently at work I've been and still am working with the wonderful AngularJS framework. I say wonderful as I think it is awesome. The learning curve has been and still is steep but I think I am helped by having limited JavaScript experience in the past, so most of my experience with JavaScript has been when I have been using Angular. I am still learning about this stuff and we will cover that some other time.

Anyway, has part of this work I needed to set up a framework to test our angular code, when I was doing this I had to look around the internet to set this stuff up so this blog is aiming to provide a step by step guide of how to configure these tools to save others some time based on my experiences.

So lets look at the tools we are installing:
  • Node.js - this will be the 'engine' on which we run our JavaScript based tools and code.
  • Karma - this is the test runner which will be using to run our tests.
    • With Karma will be using Jasmine (BDD testing framework) and PhantomJS (headless browser)
I selected these tools based on an excellent guide I read about best practices for unit testing angularjs by Andy Shora. It also talks about Integration Testing as well, but I haven't got to that point yet with my own learning but I do believe the tools we install during this guide can be used for integration testing as well.

(This guide is based on my experiences installing these tools on a Windows 7 and Windows 8 machines, sorry to those who use other environments but I think the bits that just use Node to perform the installs still might be relevant, if not then I apologise.)

Installing Node.js

To begin you will need to get the Node.js .msi file from their website. This is done by going to the site and clicking the "Install" button. This will trigger the download of the installation file (at the time of writing) this was called:
node-v0.10.27-x64.msi - I assume that because both my machines are 64 bit it selected the 64 bit install. I would think if you click the link using a 32 bit machine you'd get the relevant installer.
Now you have the installer all we need to is run it. I personally kept all the default settings and if you are new to this stuff (like me) I would suggest doing the same.

To check the install, open a command prompt and type "node":

If this doesn't work and you get a message saying "node" not a command or something like that then we need to add the SYSTEM PATH.

There are two ways to do this:
1. In the command prompt enter: SET PATH = C:\Program Files\Nodejs 
2. In System, edit the Environment Variables by adding the path to Nodejs as above or whatever the path is on your machine. (I think this option is preferred as in my experience it is permanent)
Running node in the command prompt will start the nodejs command prompt, in to which we can enter JavaScript and it should evaluate it. To exit the node command prompt use Ctrl+D

Configure Node Package Manager

Now we have installed Node.js we can use it to install some of the packages we want to use. If you are planning to use Node.js on a machine behind a proxy server (common at places at work) then you will need to first configure the node package manager to deal with the proxy:
npm config set https-proxy "proxy-ip-address-here"

Installing Karma

To install just enter the follow command into the prompt:
npm install karma -g
This should then install the Karma test runner but I also found a useful tool meaning you can use the "karma" keyword in the command prompt, to install the karma-cli package then enter the command below:
npm install karma-cli -g
To check this has all worked, type "karma" in the command prompt and you should see something simliar to the image below:

Just a quick note on Karma, the documentation on their website is excellent. From what I understand Karma will let you run tests in a variety of different browsers such as Chrome, Firefox, PhantomJS and (if you must) IE. The reason we have selected a headless browser is that I plan to include the unit tests I generate in an automated build, so a headless browser seems the best option. When you run Karma using a browser that browser pops up and we didn't want that behaviour on your build machines, however you might! In a later post when we do some actual tests I will show you how to configure which browser you want to use in Karma.

Installing PhantomJS

When I was first configuring all this stuff on my work machine, this next step was one that took the most time and caused the most frustration but when I did this step on my home laptop it just worked!

To install PhantomJS type the following at the command prompt:
npm install phantomjs-g
If this is successful then you can skip this next section, however as I said at the beginning of this section I did have some problems here. The issue I had on my works machine was that the installer couldn't download and extract the phantomjs-"version_no" file.

To get around this issue I downloaded this zip file via the PhantomJS website download page. Once downloaded I then copied this file to the following location:
Then I ran the installer again via the command prompt and this time it was successful. I am not sure why there was an issue here as on my home machines it just worked.

Install Karma plugins for Jasmine and PhantomJS

To use Jasmine and PhantomJS with Karma, I found we needed to install a could of Karma plugins:
  • karma-phantomjs-launcher
  • karma-jasmine
To do this we simply need to enter the following commands into a command prompt:
npm install karma-phantomjs-launcher -g
npm install karma-jasmine -g
Assuming these are successful then we are set up and ready to beginning writing some unit tests which use the tools we have installed.

In the next post I will show you how to do this with a benefit of a simple example, however, if you're reading this and I haven't got around to preparing the example yet then I am sure you'll find some on-line.

Happy Testing!

UPDATE: On my home computer, I found I had to ensure phantomjs (the one the karma-phantomjs-launcher uses) was not blocked or disabled by my local firewall. To find where this is on your local machine, in the karma.config.js turn the logLevel to LOG_DEBUG and it should tell you where when its accessing PhantomJS.

The problem was PhantomJS would just hang and time out. Anyway, I allowed it in my antivirus/firewall software and were all set. I found this whilst getting some things ready for the next post, coming very soon.....