Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.

 

Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.

 

Processes like Behaviour Driven Development (BDD) have attempted to bridge the gap between craftsman and customer, giving developers processes to guide software development based on the desired behaviour of the system rather than through more traditional software engineering disciplines.

 

Tools, such as Cucumber, actualise this process. Cucumber (and similar, older tools such as Fit, Fitnesse and Storyteller) provides an interface between the customer and the developer by providing a human readable specification of the software that is also understood by the computer. Based on the description, the computer executes the software accordingly.  The customer can then see immediately if the software behaves according to the specification.

 

Of course, translating human text into instructions for a computer isn’t easy. While modern programming languages on the surface do read like English, and tend to use English words, it takes a certain amount of experience to appreciate what the actual behavior of a piece of software is just by reading the code. The skill in using tools like Cucumber is in translating what the customer understands into something the machine can interpret.

 

If you’ve been looking for some time for a resource that offers a good grounding in using a tool like Cucumber then you’ll be pleased to hear that one has arrived courtesy of Matt Wynne and his Cucumber School.

 

The Cucumber School is a series of video tutorials for learning and practising how to do this. Matt Wynne takes you on a journey from the initial planning session with the customer through developing an application (‘Shouty’ - a social networking app). Throughout he highlights potential pitfalls that many teams using this tooling hit the first time they try it out. He does this with wit and aplomb. The videos are lovingly animated and include advice that Matt has built up from his many years of using and contributing to Cucumber. All this advice is condensed into six 20 minute chapters and it is advice that would otherwise take you hours and hours of trawling through blog posts and talks to discover.

 

Cucumber School covers just about everything you would want to tell developers about BDD in a little over 2 hours. To get a flavour of the style of the course the first video is available for free at the Cucumber School website and in itself demonstrates the power of BDD as a communication tool.

 

At the heart of successful software development is constant communication between the development team and customers with a business problem to solve. Cucumber provides an effective way of taking these conversations and turning them into a set of automated specifications that describe the software built. Introducing Cucumber to your development process can initially seem daunting so to get you started try The Cucumber School, which will help you to get well on the way to making it a useful and valuable part of your development process.

 

 

About the author:

For nearly two decades Leon Hewitt has been creating software to solve people's problems. He has worked at 7digital since 2012. When he's not waxing lyrical about software you can hear him chat about his favourite television programme Doctor Who on the Never Cruel or Cowardly podcast. @DocLeon

 

Tag: 
Cucumber
Learning
Code Learning
Test Framework
sharri.morris@7digital.com
Thursday, May 8, 2014 - 17:28

Astro Malaysia held it’s annual GoInnovate Challenge Hackathon on the 10th-12th October at the Malaysian Global Innovation & Creativity Centre (MaGIC).

Hopefuls from all over Malaysia massed together for an exciting challenge set by Astro - to build a radio streaming demo. The demo product was meant to redefine the way we watch, read, listen and play with content in two unique hacks to be completed within a 48 hour deadline. Astro offered substantial rewards to those whose ideas that came out on top!

Day 0: Demo - Friday evening

Attendees ranged from junior developers to start-up teams, so long as you’re 18 years old, you can take part!

To begin the Hackathon, entrants were fully briefed and given access to the APIs of both 7digital and music metadata company, Gracenote.

7digital’s lead API developer, Marco Bettiolo, flew in to act as Tech Support for the hackathon.

This photo shows Marco presenting a demo of a radio style streaming service he had previously built.

Day 1: Get Building!

According to the brief, hackers had to choose one of two innovative challenges:

sharri.morris@7digital.com
Tuesday, May 6, 2014 - 17:43

Managing session lifecycle is reasonably simple in a web application, with a myriad of ways to implement session-per-request. But when it comes to desktop apps, or Windows services, things are a lot less clear cut.

Our first attempt used NHibernate's "contextual sessions": when we needed a session we opened a new one, bound it to the current thread, did some work, and unbound the session.

We accomplished this with some PostSharp (an AOP framework) magic. A TransactionAttribute would open the session and start a transaction before the method was called, commit the transaction (or rollback if an exception had occurred), and dispose of the session after the method had completed.

It was a neat solution, and it was very easy to slap the attribute on a method and hey presto - instant session! On the other hand it was difficult to test, and to comprehend (if you weren't involved in the first place), and to avoid long transactions we found ourselves re-attaching objects to new sessions.

These concerns made us feel there was a better solution out there, and the next couple of projects provided some inspiration.

sharri.morris@7digital.com
Thursday, August 8, 2013 - 16:04

Last year we published data on the productivity of our development team at 7digital, which you can read about here.

We've completed the productivity report for this year and would again like to share this with you. We've now been collecting data from teams for over 4 years with just under 4,000 data points collected over that time. This report is from April 2012 to April 2013.

New to this year is data on the historical team size (from January 2010), which has allowed us to look at the ratio of items completed to the size of the team and how the team size compares to productivity. There's also some analysis of long term trends over the entire 4 years.

In general the statistics are very positive and show significant improvements in all measurements against the last reported period:

sharri.morris@7digital.com
Friday, July 19, 2013 - 14:55

Blue and green servers. What?

As part of the 7digital web team's automated deployment process, we now have “Blue-green servers” It took a while to do, but it's great for continuously delivering software.

This system is also known as “red/black deployments” but we preferred the blue-green name as “red” might suggest an error or fault state. You could pick any two colours that you like.

How it works is that we have two banks of web servers – the green servers, and the blue servers. Other than the server names, they’re the same. Only one of these banks is live at any one time, but we could put both live if extra-ordinary load called for it. A new version of the site is deployed to the non-live bank, and then “going live” with the new version consists of flipping a setting on the load balancer to make the non-live bank live and vice-versa.

Why?

Why did we do this? Mostly for the speed. The previous process of deploying a new site version was getting longer. The deployment script would start with a server, upload a new version of the site to it, unpack the new website files, stop the existing web site, configure the new website and start it. Then move on to the next server and do the same.