I’ve finally got around to setting up my Arduino Uno, a few minor teething problems and I’m away!

I love seeing some of the projects other people have done by using an Arduino. I can’t wait to get that good and be creative with it. For example, check out this secret knock detecting door lock

The first step was to get the Arduino IDE. As I’m working on Ubuntu and still a Linux newbie this in itself presented me with some challenges. My first attempt was was by using the Ubuntu package manager. However I realised that the packaged version of the IDE was quite old. At the time of writing this post, the apt-get package was 1.0.5, but the version available for download was 1.6.7. So I decided to manually install the IDE.

As the Arduino tar came with an install script I didn’t have to run configure and make. So after moving the extracted folder to the /opt folder, I was able to give the install script executable permission and run it. I found this set of instructions very useful.

Pretty impressively, the Arduino IDE comes pre-loaded with a quite a few examples. The setup example I was working through pointed me towards the Blink example.

Initially I was getting an error when trying to upload onto the board;

ser_open(): can’t open device “/dev/ttyACM0”: Permission denied ioctl(“TIOCMGET”): Inappropriate ioctl for device

I found another very helpful article here. By following the instructions on the article I was able to add my user to the dialout group and change the filer permissions on /dev/ttyACM0. After this was done the blink example uploaded just fine. While this isn’t the most exciting thing in the world you can do with an Arduino. It was awesome to know that I had successfully uploaded my first program to my board.

Interestingly, once I had uploaded blink, I then wondered “how do I stop it?”. It turns out that there isn’t such a thing as stopping the Arduino. So unless a stop was part of the program (where it wasn’t in blink) it would just keep going until the power supply is stopped.

Now to move on to more interesting lessons!

As I’m trying to improve my Javscript knowledge I’ve started working my way through Nodeschool’s Workshoppers. If you haven’t come across the Workshoppers before, they are brilliant. They are self contained Javascript (among other things) lessons that come in the form of a Node module. If you are anything like me, actually doing, really helps to make the lessons sink in rather than just reading.

For example, run the below commands and you are up and running;

npm install -g scope-chains-closures
scope-chains-closures

Lesson 1 - Scopes

So a pretty straight forward one here, setting a variable within the scope of a function. However, one of the things I liked about this module is that they also give information as well as set the challenge for the lesson.

So it was nice to learn that scoping with a function is actually called lexical scoping. Also, that ES6 has block scoping but you use “let” rather than “var”.

Solution

function foo(){
    var bar = 1;
}

Lesson 2 - Scope Chains

Here we are looking at how scopes can be nested and that a variable from an inner scope will have access to an outer scope but not vice versa.

Solution

function foo(){
    var bar = 1;
    function zip(){
        var quux;
    }
}

Lesson 3 - Global Scope

It was interesting to see how forgetting to declare a variable with “var” would create that variable globally. With my background in C#, this seemed pretty strange to me and will be something to be careful of.

Solution

function foo(){
    var bar = 1;
    function zip(){
        var quux = 1;z
    }
    quux = 2;    
}

Lesson 4 - Closures

Closures are a term that I have heard of before in Javascript but never really known what they are, so it was nice to find what they actually were.

When an inner function references a variable from up the scope chain, its closes over it and is a closure. The closure and the variable are maintained even if the inner function isn’t called immediately, and the function can be passed around.

Solution

function foo(){
    var bar = 1;
    quux = 2;    
    
    function zip(){
        var quux = 1;
        bar = true;
    }
    
    return zip;
}

Lesson 5 - Garbage Collection

Obviously Chrome dev tools is something I use all the time, but this lesson showed me tools in there that I haven’t used before. Recording the memory profile on the timeline tab to see where garbage collection took place was very interesting. Its always useful to have another technique to help analyse site performance.

If you want to get my solutions to ths Node School module, you can get them from my repository here.

If you’ve not heard of sphero then I recommend you go check them out now. They are a remote controlled sphere with a bluetooth connection and they are a lot of fun. There are plenty of apps available to control a sphero and its nice to see that there are even some for Windows phone. Unsurprisingly though the majority of apps are available for ios. They do look cool though, you can draw with the sphero, shoot aliens and play golf just to name a few. However I wanted a go at making my own controller.

Orbotix have made loads of SDKs available. Ruby, Python, Arduino, PhoneGap, OSX, Node, Unity, Android and more. I decided to use sphero.js as I’m still teaching myself Node as well. Installation of sphero.js was pretty straight forward by following the instructions on the github page. As I’m currently using Ubuntu, I did have to do the extra steps to allow the dialout group permissions to the bluetooth port.

The only problem I had, was that I had to use sudo when running node app.js due to the elevated permissions. May be obvious to others but as an Ubuntu newbie, had me stumped for a bit. If you are also on Ubuntu I would also defintely suggest getting the Blueman Blutooth Manager rather than the built in bluetooth app.

After getting up and running, I decided that I was going to focus on controlling the colour of sphero to start with. Making it zip around was fun, but I was too lazy to keep getting up and retrieving sphero from under the couch. If you have more energy than I do and want to get the full list of commands commands available on Javascript API the docs are available here.

I built a simple Express app that connects to the sphero on start up. As with most of my simple Express apps, I went with EJS for the rendering engine over Jade. Not because I have a problem with Jade, I just find the straight markup in EJS a little bit easier to work with usually.

I added a few colour buttons for control, good old bootstrap to the rescue for button styling! When each button is pressed it fires a basic jquery ajax post to a pre-defined route wich in turn changes the colour of the sphero. I went for an ajax call so the page didn’t have to refresh each time the sphero changed colour.

To know that the call had fired and just to make the controller look a little nicer I put a css circle with a gradient on to change the same colour as the sphero. On app start I had the sphero turn white so its clear everything is connected properly. To make the css circle look a little bit more like a sphero I used this nice article for how to apply 3D gradients to circles.

The next thing I aim to do is turn the controller in to a memory game where you have to copy the list of colours that the sphero flashes. If you want to keep track of my controller, you can find the repo here

As a developer it can be very useful to use principles such as SOLID and the Four Rules of Simple Design to help me write better code. But it struck me that it might be helpful to apply the SOLID principles to writing effective user stories.

SOLID Principles

So a quick recap of what the SOLID Principles are firstly. They are a list of principles to help create easily maintainable object-orientated code introduced by Robert Martin. Thanks Uncle Bob!

• Single responsibilty principle
• Open/closed principle
• Liskov substitution princple
• Interface segregation principle
• Dependency inversion principle

Single Responsibilty Principle

A class should only have one responsibility.

It struck me that user stories can become overly complicated and try to cover too many requirements. If a user story is broken down to its smallest possible size I think it helps the story to move across a kanban board more easily.

The developer working on it will have a clearer idea of what is expected of them. Testing time should shorter as it will be clearer if it has succeeded or not. Risk of deployment should also be reduced smaller changes will be going to production.

Just as a single class can have many tests, a single responsibilty user story can have many acceptance criteria.

If a user story adds value once complete, then I can’t really see how a user story could ever be too small. For example if a form is required, I would be tempted to identify which fields are absolutely required then they would be one user story. Each added value such as email validation or user name checking should be a user story in their own right. This is because value can be gained without them and more value will be gained with them.

Open Close Principle

A software entity should be open to extension but closed to modification.

So new features in software should be able to be implemented by adding new code to extend the currect functionality, by using inheritance for example. You shouldn’t need to modify the existing code.

I think user stories can behave in a similar fashion. When slicing a new feature each story should keep adding value on top of the value from previous tickets. If a user story conflicts with a previous story and means a previous story needs to be modified then waste is being created.

Liskov substitution princple

The Liskov substitution principle states that if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering the properties of the program.

While this doesn’t directly compare with user stories, I feel that user stories can often extend other stories. As in, build upon or modify existing functionality. When creating user stories that do this, it may be helpful to keep the Liskov substitution principle in mind. By thinking if the modification in the new user story will alter or conflict with existing functionality, unpredicted and undesirable side effects may be avoided. That isn’t to say that changing functionality is a bad thing, just that as you move towards more granular user stories, taking a step back and thinking of the wider user story can be useful.

Interface segregation principle

Its better to have many specific interfaces than one large general one.

By following this principle, code can be much easier to read as the smaller, specific interfaces are much better at conveying the intent of the code over a large interface with many methods that might not even be used. Furthermore, the increased coupling that will come from a large interface will make the software less flexible.

Larger user stories can come with the same issues as large interfaces. When there are multiple requirements the intent of the story can become confusing. Smaller user stories better convey the intent, and will be easier to assess if the desired value has been achieved.

Also, smaller and separate user stories have less chance of coupling the solutions together. Much in the same way as to pass a unit test you should do the smallest amount necessary, you should also do the smallest amount needed to get the value from a story. If more requirements arise, these should form new user stories.

Dependency inversion principle

Dependency inversion means that high level components should not have dependencies on lower level components. This inversion can be achieved through abstracting the lower level components behind interfaces.

While user stories don’t have dependencies in the same way that a class can, I think it could be helpful to ensure higher level user stories don’t have reference to and depend on lower level stories. For example, a user story for a new checkout form to increase conversion wouldn’t need the details of a lower level story for the email validation on the form. If it did, it would be over complicating the form story and slowing down getting value. However the lower level story would obviously need to have knowledge of the higher level story.

SOLID User Stories?

After thinking how the SOLID principles can be applied to user stories I can’t see them becoming the new standard to assess user stories anytime soon. However, thinking of why the SOLID principles are useful has definitely made me think more about what makes a good user story and how I can improve ay I write in the future.

Project Oxford is a collection of really cool APIs that Microsoft have been working on and expanding.

They include APIs that cover all sorts of facial recognition, image evaluation and speech tools. Its pretty impressive stuff, they can tell what an image is of, read somebody’s emotions, process natural language and more.

All the documentation is straight forward and they have generous free tiers for most of the APIs with limits of 5,000 calls or more a month.

You can check out just how easy it is to make use of these APIs in my sample project. Its just a simple Express app using ajax to make the calls. Its nice to see that Microsoft haven’t restricted use of them to just Nuget and C#. My example makes use of the Face API and the Emotion API to get gender, age and emotion levels from a photo of a face.

There is an app gallery showing off some of the cool stuff that can be done with the collection of APIs. Annoyingly though, when I wanted to get one for my Windows phone the app only works on Android!