Sunday, 4 December 2016

Test-Driving JavaScript Applications

Venkat Subramaniam
ISBN-13: 978-1680501742

I wanted to start this review simply with "Wow! Just wow!", but that’s not really going to cut it. It’s true to say that when I first learned that there was going to be a book published called "Test-Driving JavaScript Applications" I was sure it was going to be the book I had been waiting for since at least late 2007 when I was forced to write JavaScript in production for the first time. It’s publication date was pushed back and back, so it really felt like I was being made to wait. However, I wasn’t disappointed and this book was everything I hoped it would be and more.

We all know JavaScript is evil, right? Why is it evil? It’s the lack of a decent type system, the forgiving nature of the compilers and an inability to write meaningful unit tests, especially for the UI (User Interface). It’s difficult to do a huge amount about the first two points, but now JavaScript can be meaningfully unit tested, even in the UI context, with Karma, Mocha and Chai. Test coverage can be measured with Istanbul and System Tests (referred to by Subramanian as Integration Tests - this is my one bugbear with the book) written with Protractor. All of this is described in Test-Driving Java Applications.

I think it’s important to read all of part 1, Creating Automated Tests. The chapters cover everything you need to know to get started writing unit tests for both server side code and UI code, how to test asynchronous code (very important in JavaScript) and how to replace dependencies with test doubles such as fakes, stubs and spies. It’s all demonstrated with a completely test first approach with excellent commentary about how this leads to good design.

I cherry picked from part 2, Real-World Automation Testing. I was only really interested in how to write automated tests for the DOM and JQuery and how to write ‘Integration’ tests. Other chapters included how to write tests for Node.js, Express and two versions of AngularJS. The DOM and JQuery chapter was excellent showing me exactly how to take advantage of test doubles to write fully tested JavaScript without having to fire up a browser, resulting in something I can make immediate use of.

The Integrate and Test End-to-End chapter, which describes how to use Protractor, was almost enough to encourage me to abandon Java (Selenium) for System Tests and move to JavaScript. However, while looking at the latest version of Selenium, there are some other things I want to investigate first.

The final chapter, Test-Drive Your Apps is the equivalent of Pink Floyd playing Run Like Hell at the end after Comfortably Numb. It’s still good, but is really there to help you wind down from the climax and could just as easily have been omitted, but it would feel a bit odd if it was.

If there was one more thing I could get from this book it would be how to send test and coverage results to SonarQube.

If you want to use JavaScript, intend to use JavaScript or are forced to use JavaScript, get this book and automated the testing of your JavaScript.

Friday, 2 December 2016

Naked Element produce a more efficient client-facing web presence for Bluemoon College


Bluemoon Investigations are a long established company, specialising in covert inquiries for both public and private concerns. From providing evidence to the court in cases of fraud, to tailing cheating spouses across the globe, Bluemoon have had over thirty years experience in getting to the truth. They also run a College training people how to become professional private investigators. They came to Naked Element with a desire to have a better and more efficient client-facing web presence for the College.

Online marketing agency Clark St. James had been working with Will Clayton, Director of Bluemoon, to improve their web search rating, and recommended Naked Element to him for a new website. “Our old website wasn’t branded, slow and not working for us, we needed a whole new design to improve communication, speed and our web presence to potential business.” Our designer Shelley took on the challenge and worked closely with Will to get the result Bluemoon wanted. “The process was easy and straightforward – Shelley made design suggestions, and we approved those we liked, and the build was quick and painless! We’ve received prompt help and support for the small changes we’ve requested since the site went live too. There were some style changes I wanted to make, which Shelley explained could be difficult, but Naked Element worked hard to resolve them and give me what I wanted.”

The result is a responsive website that welcomes potential clients and provides Bluemoons’ service details in a clear and user-friendly way. From Shelley’s point of view the process was mostly plain sailing. “The only challenge I had was super tiny – it was to do with text layout on one page. Most people approach web design like magazine design (which has a fixed size and layout), so they assume you can be pixel perfect. Due to different screen sizes, that’s not always possible, but there are always workarounds so it was a case of trying to get the right balance across all screen sizes.”

“Will can be a bit of a perfectionist, which is really nice actually – he’s not at all picky but is great at noticing detail. Working with him was nothing but a pleasure.” And from Will’s point of view? “I haven’t had to be involved much with Naked Element in all honesty – the whole process has been painless and relatively easy, which is exactly how it should be.”


A class what I wrote

When I was a member of the ACCU their regular publications always appealed for people to write articles for them. There were a few suggested topics, but the one which stuck in my mind was to write about a class you'd written. I often used to wonder about doing this, but it's quite difficult as I rarely wrote a class which was stand alone enough to write about, without having to write about a load of other classes too. Maybe that's a symptom of a design which is not loosely coupled, but I'll leave that for a late night discussion with Kevlin Henney.

Today I wrote such a class, and was very pleased with it as it reduced a lot code which was repeated in a number of methods down to a single line of code - it even manages a resource! Here's the code I started with:


try
{
    final OutputStream os = response.getOutputStream();

    try
    {
        IOUtils.write(JsonTools.toJson(...), os, "UTF-8");        
        response.flushBuffer();
    }
    finally
    {
        os.close();
    }
}
catch (IOException e) 
{
    log.warn(e);
}  

It's Java. It gets an output stream from a HttpServletResponse instance passed into a Spring MVC controller method, writes some JSON to it, flushes the buffer and cleans up. If there's an error and an exception is thrown, the output stream is still cleaned up, the exception is handled and logged. All reasonably simple and straightforward.

With the class that I wrote, it's reduced to:

try
{
    new ServletResponseWriter(response).write(JsonTools.toJson(...));
}
catch (ServletResponseWriterException e) 
{
    log.warn(e);
}

An instance of the class is initialised with the HttpServletResponse instance and a single method called to write the JSON to the output stream. If an error occurs and an exception is thrown, it's handled and logged, just as before.

There is far less code to maintain by using the class instead of repeating the original code.

Let's take a look at the class itself, ServletReponseWriter:

public class ServletResponseWriter
{
    private static final String UTF8 = "UTF-8";
    
    private final ServletResponse response;
    
    public ServletResponseWriter(ServletResponse response)
    {
        this.response = response;
    }
    
    public void write(String data)
    {
        write(data, UTF8);
    }
    
    public void write(String data, String encoding)
    {
        try
        {
            final OutputStream os = response.getOutputStream();

            try
            {
                IOUtils.write(data, os, encoding);                
                response.flushBuffer();
            }
            finally
            {
                os.close();
            }
        }
        catch (IOException e) 
        {
            throw new ServletResponseWriterException(e.getMessage(), e);
        }
    }
}

Let's start at the top and work our way down. The constructor takes a ServletResponse which is an interface implemented by HttpServletResponse containing the getOutputStream method. The ServletResponse is saved within the class as an immutable field.

The first of the write overloads allows the user of the class to write to the output stream using UTF-8 without having to specify it every time. It calls the second overload with the UTF-8 encoding.

The second write overload is much the same as the original code. It gets an output stream from the response and writes the supplied string to it, flushes the buffer and cleans up. If there's an error and an exception is thrown, the output stream is still cleaned up, the exception is handled, translated and re-thrown.

The keen-eyed among you will have noticed that there are two new classes here, not just one. I'm not a fan of Java's checked exceptions. They make maintenance of code more  laborious. So I like to catch them, as I have here, and translate them into an appropriately named runtime exception such as ServletResponseWriterException.

ServletResponseWriter implements the finally for each release pattern of the original code and the common pattern implemented by classes such as Spring's JDBCTemplate which wraps it in a reusable class intended to manage resources for you.

Resource management is vital, but the real advantage here is that the code is more concise, more readable and reusable. And, I've had the chance to write about a class I once wrote.



Sunday, 20 November 2016

Norfolk Developers Event: Breakfast with Clive Lewis MP


What: NorDev Breakfast with Clive Lewis MP

When: Friday, 9th December 2016, 7.30am to 8.30am

Where: The Maids Head Hotel, Tombland, Norwich, NR3 1LB

How much: £11

RSVP: https://www.meetup.com/Norfolk-Developers-NorDev/events/232228431/

Clive Lewis MP will lead a general discussion about what the tech scene needs in Norwich to grow, employ more people and provide opportunities for young people from non-traditional backgrounds.

MAKE YOUR VOICE HEARD AND BE PART OF TECH NATION 2017!



Tech Nation 2016 provided the most detailed analysis to date of how the digital sector is driving economic growth, showcasing the innovation and energy of tech hubs across the UK.


In 2017 Tech City UK will take an even more in-depth look at how the digital economy is evolving, giving a greater voice to the UK’s tech communities and highlighting the considerable progress they are making.

To do this we need to hear from everyone who works or operates within the sector. So whether you’re part of a tech business, an academic, investor or another member of the ecosystem please take just seven minutes to complete the survey and share the link with your network.


Around 40 companies who complete the survey will be featured within the report as a case study! Thank you for your time.

Sunday, 30 October 2016

The Forever War: Forever War Book 1

Joe Haldeman
ISBN-13: 978-0575094147

I don’t remember who it was, but someone suggested I read The Forever War when I got into the Space Operas of Alastair Reynolds. I couldn’t find it on the kindle for ages, so a hard copy of the omnibus edition sat untouched on my shelves for quite a while. Then it became available on the kindle.

The Forever War Book 1 is good, I enjoyed it. I liked the characters and the first person style works really well. I am sure in the 60s it was revolutionary maybe even shocking, but, as with a lot of old sci-fi, it is of its time and feels antiquated next to the technology we have today.

In terms of scope, it’s nowhere near as vast as anything by Alastair Reynolds and I think this was my biggest disappointment. I was interested to read that a lot of the inspiration for the story came from the author's experience in the Vietnam war. If it hadn’t been mentioned I certain wouldn’t have known. I did spend a good deal of my reading time trying to see how the futuristic battles and enemy might relate to the Vietnam war.

The two sequels were written much later. I’m hoping they’ll be better.

Sunday, 16 October 2016

Norfolk Developers: How email works... & Fabric

James Taylor


What: How email works... & Fabric

When: Wednesday, 9th November 2016, 6:30pm to 9:00pm

Where: The Union Building, 51-59 Rose Lane, Norwich, NR1 1BY

RSVP: http://www.meetup.com/Norfolk-Developers-NorDev/events/233466373/

How email works... and why you should care. 
Steve Engledow (@stilvoid)

A brief history of some of the aged protocols that underpin the internet and email in particular, a look at the security implications of the way email works, and some steps you can take to improve your safety.



Fabric: Fast one line consistent deployments across multiple servers 
James Taylor (@jmons)

For small organizations, or even hobbyists, deploying modern systems can become annoyingly complex. There are several solutions which we’ll look at briefly, before doing a deep dive and demonstration of how I use “Fabric” to do controlled continual deployments with no stress and maximum fun. In this session we will be doing a live-code demonstration, as well as taking continual questions and heckling is encouraged. Even if you can’t code, but manage sysops or coders, hopefully you’ll get to see what low stress deployments can look like.

James Taylor

James works at Proxama by day inventing new and interesting methods of payments, and works on various startups at night (@getimperium, tether). He despises all programming languages, but some more than others, and is currently the NorDevCon "Just a Minute : Technical Edition" reigning champion (mainly due to a rant about PHP). (This profile contains an annoying mismatched bracket.

Saturday, 15 October 2016

Good Code: Kevlin Henney Full Day Workshop


What: Good Code: Kevlin Henney Full Day Workshop

When: Wednesday, 23rd November 2016, 10am

Where: The King's Centre, King Street, Norwich, NR1 1PH, Norwich

How much: £35.00

RSVP: http://www.meetup.com/Norfolk-Developers-NorDev/events/233531472/

Good Code 
Kevlin Henney (@kevlinhenney)

We often talk about good code — that we would like to write it, that there isn't enough of it, that it should not be considered an optional attribute of a codebase. We often talk about it but, when it comes to being precise, we don't always agree what constitutes good code, nor do we necessarily share a common view on its value.

This one-day tutorial and workshop explores what properties we want from a codebase and, therefore, what we can deduce to be good. These conclusions can sometimes be surprising and counter-intuitive! This session will explore some common guidelines on what is considered good, from expression to subsystem, from naming to tests, from fluent to SOLID. We will look at the consequences of good and not-so-good code from point of view of economics, day-to-day work, people and runtime performance and reliability.

Kevlin Henney

Kevlin is an independent consultant and trainer based in the UK. His development interests are in patterns, programming, practice and process. He has been a columnist for various magazines and web sites, including Better Software, The Register Application Development Advisor, Java Report and the C/C++ Users Journal. Kevlin is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of the 97 Things Every Programmer Should Know book.

Saturday, 8 October 2016

Naked Element’s software for Fountain reduces processing time by 95%


Fountain Partnership Limited are a digital marketing company based in Norwich, established in 2008. With a team of experts, Fountain are able to identify a company’s growth opportunities and build a customised strategy for the best results and command market share. Their strategies drive browsers to client’s websites, increasing opportunities to convert browsers into customers and then increase customer value by testing and measuring. In order to do this, they specialise in the optimization of search engines and conversion rates, as well as pay per click advertising. In order to do this, Fountain uses a combination of pay-per-click advertising, search engine optimisation and conversion rate optimisation.

The problem Fountain were faced with was a time consuming one. When advertisements needing changing or updating it was a painstaking process. They had to upload a new set of adverts from a spreadsheet, going through each one manually to pause all of the old adverts in order to make room for the new ones. it would take days in some cases.

“What was taking 20 hours of work is only now taking an hour.”

Naked Element were chosen to build a script which would allow Fountain to manage one of their largest clients in Google AdWords, saving time and ultimately money. This particular client currently had 75 individual accounts. What the Fountain team were doing to update these was logging into an account, creating the new adverts, then log out of that account, then log into the next one 75 times over!

So what was Naked Element’s solution? In simple terms a script was created that allowed the user to specify AdWords accounts, campaigns and ad groups and then to enter a search, replacing each with a phrase or word. When running, the script would look through all of the ad groups in the campaigns specified and would copy the ads found with the search phrase, update the field with the updated phrase and pause the previous ads.

For example: A client has a campaign called ‘Car Sales’ with three ad groups – blue, red and black. Within those groups there are ads with the description “newest model”. The search phrase “newest model” is entered, followed by the update phrase “drive away today” and the script is run. All of the previous ads with “newest model” will be paused and replaced with the new ads containing the phrase “drive away today”.

“By developing this software to improve process efficiency, Naked Element has saved us four weeks worth of work per year!” said Laura Jennings, Strategic Director at Fountain. “The script they built us is saving up to 95% of our processing time. What was taking 20 hours of work is now only taking an hour – a big saving. ” When software produces such immediate benefits, the advantages are clear.

“The process of working with Naked Element was really straightforward, they tried hard to extract the correct information from us. Lewis, the developer, came out to see us several times. Documentation was also really easy to understand.” The only issue Fountain had was during the creation of the script, as it didn’t always work quite as expected. “However Lewis was quick to identify and resolve the problems. It was never too much trouble to sort out an issue and assistance was always available via telephone.”

Sunday, 2 October 2016

Ever wondered what an algorithm is?

Algorithms are everywhere. Our children are even taught about them at school, but have you ever found yourself wondering what an algorithm actually is? Maybe you’ve thought they’re something used by computers and created by computer programmers, but don’t really know what they are?

The dictionary defines  an algorithm as:

“A set of rules for solving a problem in a finite number of steps.”

Algorithms come in all shapes and sizes. They can be extremely complicated, but they can also be very simple and easy to understand.

Examples of more complex algorithms include those used to price financial products in a bank or to determine the best route between two points in a satellite navigation system. Simpler algorithms include those used to sort lists of numbers, such as Bubble Sort.

Bubble Sort

Bubble Sort is one of the easiest algorithms to understand. As its name suggests, it’s an algorithm used for sorting. Often the easiest list of things to sort are numbers. Bubble Sort works by comparing each number in the list to the number next to it and swapping them with each other if the numbers are in the wrong order. This process is performed again and again until a pass over the list requires no swaps. At this point the list is sorted. Knowing when to stop sorting the list is just as important as knowing how to sort the list. As we know when to stop (when a pass has no swaps), Bubble Sort can be used for lists of any size.

The easiest way to demonstrate Bubble Sort is with a simple example. Take the list of numbers:

3, 2, 1

We can use Bubble Sort to reverse the list. The first time we pass over the list the first two numbers are 3 and 2. 3 is greater than 2 so we swap them over:

2, 3, 1

Next we compare 3 and 1. 3 is greater than 1, so we swap them over:

2, 1, 3

There are no more pairs of numbers to compare on this pass and there were two swaps (3 & 2 and 3 & 1) so we pass over the list again. The first two numbers on the second pass are 2 and 1. 2 is greater than 1, so we swap them over:

1, 2, 3

Even though we have successfully reversed the list, we’re not finished. Next we compare 2 and 3. 2 is not greater than 3 so we don’t swap them. There are no more pairs of numbers to compare on the second pass and there was a single swap (1 & 3) so we pass over the list again.

1, 2, 3

The first two numbers to compare are 1 and 2. 1 is not greater than 2, so we don’t swap them. Then we compare 2 and 3. 2 is not greater than 3 so we don’t swap them. There are no more pairs of numbers to compare on the third pass and there were no swaps so we’ve finished and successfully reversed the list.


Sorting Algorithms in the Real World

Bubble Sort is taught to trainee software engineers as it’s easy to understand and implement. However, it’s rarely actually used in the real world as it’s inefficient and there are other more efficient sorting algorithms, such as Quicksort, which are only a little more difficult to understand implement.

Sorting occurs in all sorts of systems in the real world. One example is in the software used to sort mail into the order a postman will deliver it as he walks along his round. Postcodes and other address elements are read into the system and sophisticated algorithms used to sort the mail into the correct order.

The next time someone mentions algorithms to you, remember it’s a set of rules for solving a problem in a finite number of steps.