Before we held regular hack days, we would down tools at 5pm each day to work on personal development activities. Back in February 2013 we thought it would be a good idea to team up on a fun internal project to practice some new methodologies such as behaviour driven development (BDD), have a bit of fun whilst learning new stuff and end up with something great to show off as a result.
Hatching a plan
One area on our site we had big ideas for was our footer which contained some interesting stats, including a counter of how many cups of coffee we drink during the week. We thought we could make more of this, not only visually, but hook up a physical interface next to the coffee machine which when pressed would push the data up to our webserver. So, we purchased an Arduino board starter kit and set about planning our new project.
Initially we got together to discuss what we were trying to achieve and define a ‘common’ project goal that we could all understand. Once agreed, we got creative, spending a few minutes writing down on post-its all the things we could think of that would help us achieve our goal. Each item was then introduced to the team by the author of the item and discussed one at a time to loosely group common themes and throw out duplicates. We then agreed which items we would commit to the product backlog and converted them to user stories.
Before we got started we discussed a few things that we wanted to get out of the project that weren’t necessarily part of the agreed project goal – these were akin to ‘learning objectives’. This is a really important element of an internal project as it provides an opportunity for us to experiment with different technology and ways of working that will make us better at what we do. We identified the following items and agreed a ‘learning budget’ for each:
- Lightweight php framework: we regularly use Symfony2, the bigger cousin of Silex, but we wanted to understand a bit more about Silex as a potential framework for lighter weight projects
- Continuous integration: we wanted to introduce CI into our workflow and liked the look of Jenkins CI but needed to look more thoroughly into other tools to understand them a bit more before making a choice
- Dynamic data visualisation: our Digital Designer wanted to research how other designers and front-end developers tackled data visualisation. Her research could feed into this project as well as future projects – making sure she wouldn’t be designing something that’s impossible to implement
Following our initial research we took the decision to ditch the Arduino in order to concentrate on the learning goals of the project: a physical button to increment the coffee stats on our webserver database left the front-end pretty static and not as useful for Ryan to test his BDD skills against, so we decided to allow users to login via a mobile interface to record how many coffees they’ve just made. This increased the workload on the front-end, and enabled us to capture richer data for our statistics.
As we’d changed our plan to feature more data for our statistics, our Digital Designer got to work on visualising our coffee consumption, using her research to ensure that it could be implemented by our front-end developers:
Minimum viable product
One of the purposes of the project was to practice what we preach to our clients and that is to go for the lean approach. We had a backlog of 14 user stories, but we released the first version of our mini project by completing 3 out of 14 user stories. Our MVP consisted of:
Learning new tech
Our first release was over a year ago, and since then, our frontend development has changed dramatically with the introduction of AngularJS and added maturity of Cucumber, and we’d been using Node.js for a number of applications. When James joined us as our Frontend Developer we saw it as the perfect opportunity to bring the project in line with our new MEAN development stack, and to finally implement all of the lovely data visualisation.
We’ve given the admin area a new look, with a nifty user interface:
And using D3 meant that we were able to bring the designs to life with more interesting visual representations of our data. We’d love to know what you think?
“I rebuilt the project with AngularJS, using Karma, Mocha, Chai and sinonChai to build the application with unit testing. We replaced the Symfony backend with a lightweight Node.js API which communicates with an external Mongo database. I approached the project from a BDD perspective: it’s the first project at UVD where I was involved from the beginning so I learned how best to kick off a project and how important it is to always review and refactor my code. Introducing D3 into the project allowed me to produce swish animated charts and was another good library to get stuck into. We now have a much more interesting application, that shows our coffeestats in more engaging ways for end users.”