Wednesday, 10 September 2014

Were Apple being silly on September 9th?

Before we begin lets make it clear, I am a NEW fan of Apple. I recently bought a wonderful MacBook Pro Retina and I blogged about last time, it is a wonderful product.

Anyway, now I have made that clear, lets get on with today's blog. 

I have just watched the wonderful TimmyTechTV on YouTube on which he posted what I thought was an interesting piece about why he won't be buying the new Apple 6 Plus and iWatch. 

When I watched it I found I agreed with some of it but not all of it so this is my two pence (or three cents) worth on the subject.

Please watch this video (be warned there is some bad language in it). 

The reason I ask you to watch this video before continuing is that the points I cover below will make more sense.

Point one: "Apple is just really a recipe company"

I can see and understand the point he is making. I guess I would ask, what is wrong with that?

Timmy says (quoting someone else) that Apple "take proven things that other people have done, package them in a nice bundle and sell them to you at an overpriced price"

Stepping back a moment lets take Timmy's statement and break it down and cover each point by point. 
"take proven things that other people have done, package them in a nice bundle..."
I think this is meant to be a criticism but to me it is one of Apple's strengths. I am a software engineer, most of my work involves doing this, it doesn't make me bad at my job. In fact it is a real skill to be able to do this well and in the past Apple have been fantastic at doing this. 

For example, things such as MP3 players, tablets etc. Have been made better and more accessible for people to use. I would argue that the Apple Watch could be the next example of this, but we will see.
"...sell them to you at an overpriced price"
Apple products are obviously much more expensive. With regards the latest iPhone, I agree with this statement in that it is way overpriced for what you are getting from a technology perspective. I own a Nexus 5 phone which I bought SIM free in the UK for £250, its a great phone. Timmy talks about the One Plus that he has ordered, I think these also look great.

However, when you have such a brand name and reputation as Apple have you can charge top prices. I mean the reason the Nexus is so cheap is that Google wants market share so it probably sells these handsets at a loss. One Plus, is also after market share and that is the reason I would guess their products are competitive on price.

A lot of Apple's consumers are not that into technology, generally they just want something that looks great and works! [Android is getting way better with this, Android KitKat is a nice system] Generally, these people are still willing to pay that bit extra for ease of use, they want to take it out the box and get it going in 5 minutes. They don't want to tweak it or set it up. Apple know this and they charge a premium for it. Again, I don't think that is such a bad thing. They know their consumer and target their products accordingly. They are amazingly good at this.

Point Two: "You can only watch Apple events on Safari"

I agree again this is a bit silly, but it comes back to my earlier point about knowing your market. The majority of people who are keen to watch these events generally own multiple Apple products so this is not such an issue.

Timmy continues about the "elitist mentality" and Apple are not the "king" anymore. I sort of agree and disagree with this. I think this mentality comes more from "Apple fanboy's" than from Apple. The "fanboy's" bang on about how Apple is the best and everything else is rubbish. I joke about becoming a fanboy but I don't think I will buy every Apple product.

In Apple's defence, I think Apple have realised that for many consumers who shop based on price they will never appeal to them, so they appeal to this small section who are willing to pay top money for the ease of use and often these people will already be using many products in the Apple eco-system.

Point Three: "Apple under Tim Cook is not doing the right thing"

I don't know about this, only time will tell.

Tim Cook couldn't win in this situation as Steve Jobs was a rare type of visionary who cannot and will not be replaced. Apple struggled before when Jobs was fired and it might do again. the jury is out.

I will say this, Steve Jobs made Apple successful by creating great products that people wanted because he loved to create great products and make the complex simple. For him, I really think it was a passion and part of who he was. He knew he needed to make money to be successful, but he measured success by how good the product was, how easy was it to use and so on, then the money looked after itself.

I think that Tim Cook measures success by how much profit it might generate, and I feel this is the reason Apple might fail.


I think a lot of the points Timmy makes in this video are very valid and do create some good discussion, some of which I have tried to cover today. I think a lot of the frustrations actually come from not really understanding what Apple's position is now in the marketplace.

In my opinion Apple cannot compete with companies such as Google, Samsung etc on pure market share, Apple know this, they might not say it but it is clear they have accepted that they will appeal to a small but committed minority who are willing to pay top prices so they charge top prices.

Apple products to me have always been quality products for which you pay a premium. Apple don't innovate, they copy and tweak to serve their consumers and whether you like it or not, they do this very well. The iPhone 6 and iPhone 6+ will sell very well, people will queue outside the stores and the media will cover it all.


Were Apple being silly on September 9th 2014? 

Probably, but they were targeting their core market and they succeed in generating the buzz they needed to maintain profits and market share!

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!