Technology Blog

In addition to JSON support we’ve also been hard at work improving the API itself. Here’s some of the changes that we’ve introduced to Catalogue API recently. But first 2 important upcoming changes:

“RRP” pricing on release/details

Historically the release/details endpoint provided recommended retail price (RRP) even for releases that didn’t actually have RRP supplied to us by content licensors (i.e. music labels). This typically applies to singles/EPs with 1-4 tracks who tend to have RRP specified only on track level.

In these cases the release RRP provided by the API was calculated as sum of track prices appearing on given release. But as this has been an ongoing source of confusion we’ve taken the decision that we will be more explicit and we will start indicating that a release doesn’t actually have a RRP by returning NULL as the RRP value.

This behaviour is consistent with our documentation  (see http://api.7digital.com/1.2/static/documentation/7digitalpublicapi.html#Price) but nevertheless we’ve set up a test endpoint where you can see how release with no RRP will look like in action:

http://api.7digital.com/1.2/release/details/beta?releaseId=2686113&oauth_consumer_key=YOUR_KEY_HERE

(Please note that this endpoint will be switched off once the changes have been made to the regular endpoint so make sure you don’t use it in any live applications)

Release “barcode” on artist/toptracks endpoint is being deprecated

We will also no longer be providing release barcodes in responses of artist/toptracks API endpoint (no other endpoints will be affected). In short term we will not be removing the entire “barcode” element from the response but it will be populated with an empty string. We recommend you to remove any dependencies on the barcode data for this endpoint as in the future we will be removing it completely (we will provide additional advance warning).

Both above changes are preliminarily scheduled to take place on June 3rd 2013. Please get in touch with us ASAP should you have any questions/concerns about this.

Release duration, release track count & track disc number

On the other hand we’ve been gradually adding the following information to relevant endpoints-

For releases:

• duration – total length in seconds of all tracks appearing on release
• trackCount - number of tracks appearing on release

At the moment these new fields appear at the end of release (or track) response but for readability we will be putting them in their logical order within the response,  e.g. so that trackNumber and discNumber appear next to each other. Now maybe a good time to double-check you don’t rely on order of the XML elements in API responses.

Pricing info available in more API endpoints

We’ve also added pricing information to more Catalogue API methods so that you don’t have to make multiple additional API calls e.g. to fetch prices for all tracks appearing in a chart.

All the following now provide prices:

artist/releases
release/details
release/tracks
release/search
release/chart
release/byDate
release/byTag/top
release/byTag/new
release/recommend
track/search
track/chart

More relevant API endpoints will be getting pricing info added in the near future.

Catalogue content filtering

Another functionality added to our API is content filtering which allows you to exclude certain types of content as you’re browsing the 7digital Catalogue API.

You can filter content from specific licensors or hide content not cleared for subscription based on-demand streaming services. Filtering can be handled by yourself using optional request parameters (e.g. see artist/releases documentation) or if you’re a Premium API user we can do the job for you and filter specific content for all requests by your API key directly on our servers.

We’re also planning to support additional content filters in the future (e.g. label, explicit content, format) please do let us know what you’d find most useful.

By popular demand we’re working on adding support for JSON response format to our API. We’re making a good progress and are now able to share some of it with you.

Please note that this is still work in progress and we strongly advise you not to use JSON responses in any production evironment yet as we might be making minor changes to the format of the responses based on your feedback. Please do let us know how you find it, either in our 7digital API Google Group or by contacting us directly at api@7digital.com

We’ll give everyone heads up once we’re happy the JSON support is stable enough to be used in live applications (at which point it will be also added to the API reference documentation).

Supported API endpoints

So far we have the following API endpoints already supporting JSON:

artist/chart
artist/browse
artist/releases
artist/search
release/byDate
release/chart
release/search
track/chart
track/search
tag
artist/byTag/top
release/tags

The remaining Catalogue API endpoints will be following shortly.  And based on your demand we will be adding JSON to other endpoints across the entire API through out 2013 (e.g. Locker API, Basket API, etc). Also any new API endpoints added to 7digital API will support JSON out-of-the-box.

Requesting JSON

You can ask for JSON responses by providing an Accept HTTP header with your API call, i.e.:

Accept: application/json

Curl example:

curl -H "Accept: application/json"
"http://api.7digital.com/1.2/artist/releases?artistId=1&oauth_consumer_key=YOUR_KEY_HERE"

Example structure of JSON responses: Don’t forget to let us know if you have any questions or feedback.

Last week was the annual open day for the 2^nd year group project at the Computer Science School at the University of Nottingham. The open day forms a significant part of the group project module as it calls for the groups to present the software they’ve built over the last few months at a mock trade show, complete with posters, demonstrations, branded t-shirts and plenty of attention grabbing cake or sweets.

7digital were represented at the open day by Leon Hewitt and Paul Shannon, which is 7digital’s second year in attendance,  except this time we were judging a slightly different prize. After previous prize sponsors decided to sponsor elsewhere we were asked, along with Esendex (a Nottingham based technology company and the UK’s leading specialist business SMS provider) to potentially provide some goodies. As we’re quite friendly with Esendex and share a similar approach and passion for software quality we thought the best solution was to pair up and jointly sponsor a prize looking directly at the quality of the software produced by the students.

The 7digital and Esendex Prize for Software Quality

We defined criteria based on the principles and practices that we use to make well crafted software. As this is the first time the students have to form a team to complete a project we didn’t just focus on the actual code either, looking at the following areas:

• Knowledge Sharing
• Team Organisation
• Code Quality
• Code Architecture
• Testing

Knowing that in previous years teams generally had 1 coder, 1 UI coder, 1 documenter and someone else to manage all the work, we’d hoped this emphasis on sharing might encourage better collaboration.

More details about the participants and prizes on the group project home page. Our full criteria for the prize is available too.

Our Findings

We had access to the reports and source code repositories of all 26 teams, splitting the work between the two judging companies to arrive at a short list of 4. We didn’t expect perfectly clean code with great test coverage and well prioritised work flows but we did see flourishes of quality software in various teams.

Overall the quality of the software was an improvement on previous years, reflecting the extra effort the school have been putting in to talking about quality practices and agile methodologies. I heard that using test driven development is now a requirement on one of the MSc modules which is a good step forward.

The Winners

Another prize on the day was given to the best overall project and that team produced a software version of a chain reactive performance arpeggiator. They also had well structured, tested code and used a Kanban tool to manage their work in progress but it wasn’t quite enough to snatch our prize.

The winners of the Prize for Software Quality though were a team of 5 that produced a Greenhouse Appliances Control System. They used unit testing and had well named classes in a decent project structure. The key part of their project that stood out for us though was the collaboration they’d had with their customers and how well the team had self organised. You could tell that the team, who didn’t previously know each other, had formed a great relationship which showed in the quality of the software they produced.

As I’d been talking about software development being as much about people as it is about the code, the fact the winning team had found a customer (their University’s bio-sciences department) that had an actual need for their software seemed to help them enormously around prioritising and delivering features. A key point I noted was that they delivered an early, working, version of the software before most other teams which allowed them to get feedback from their supervisor and new customer. This helped them only produce the features needed, and appeared to give them chance to spend time on making the parts they did make at a higher level of quality. They also managed some pair programming which was evident when you could ask any member of the team about the software and they could answer with confidence.

One final aspect of this project that we liked too was the greenhouse simulator they made to test the tool during development was then further evolved to be a part of the product – adding another dimension and use case to the tool as a whole.

Alumni Talks

While we’d been discussing the importance of software quality and the methodologies we use for some time at the university we’d never had the influence of some of the bigger partners the university has at the alumni talks. This year though was different. Well done to the organisers as they managed to get alumni from Facebook, Google and the BBC. The real coup d’état for us (and Esendex) was that they all spoke about test driven development and software quality – falling over each other to recommend JUnit and Moquito. With much more well known names repeating our message, it really increased the effect of our prize and our motivations for creating it.

Conclusion

We had a great day out and are really pleased to strengthen our relationship with the University of Nottingham. Seeing an emphasis in software quality making its way into the early days of people’s careers in the industry is refreshing and bodes well for the future. As an organisation with greater than 50% technical people we’re grateful that graduates have access to teaching and practice around this better way of writing software so that we can seriously consider expanding our team with even more graduates in the future. As a society though, given software is even more prevalent in almost every aspect of our lives, I’m really pleased that future software will be written with quality in mind as the next generation of developers are inspired by the examples they’re able to see at universities like this.

More pictures from the day can be found on here.

I arrived at DevOps Days Paris not quite knowing what to expect. I’d been introduced to DevOps Days at the London event about six weeks ago, where I was blown away by the abundance of ideas and energy, and I was curious to see how this would play out in a different country and culture. Coffee and croissant in hand, I took my seat for the introductions. First up, a presentation about CustomerOps: using the DevOps obsessions about  visibility, metrics and communication to improve the consumer experience.

Next up, How ops improved my dev: the benefits of the DevOps culture as seen from the development side. My favourite bit of this was describing the inverse relationship between implementation and operational complexity; that is, things that are easier to set up often turn out to be much harder to maintain and troubleshoot. There was a nice example about a pipeline where data needed to be imported, processed, and encoded. The dev approach would tend towards writing one program to do all three tasks, keeping the majority of the information in memory. The ops approach would tend towards having three separate programs each with a single task, then if one part failed not only was it much easier to identify why, but also the other two could continue unaffected.

After a short break, we had a couple more talks, one of which was Transforming devs into devops. Ignoring the abuse of the term DevOps, it was interesting to me coming from the ops world to see what ops skills are perceived as covetable by developers: apparently this includes using linux as a development environment, git versioning and branching, scrum methodology, unit and functional testing. Now at least half of those I would have put as primarily dev skills, but maybe that’s because we’re all agile at our place. I was also quite pleased to hear the phrase ‘pair-devopsing’, which is an ugly term for a nice type of inter-team collaboration, and something we’ve been trying a version of at 7digital for a couple of months now.

The afternoon was devoted to Open Space sessions, where anyone can propose a topic that they want to talk about – usually something they want to know more about, rather than something they’re already good at. I went to an interesting discussion about Vagrant that I came away with two pages of notes about things I want to try out, and sat in on some interesting discussions about the clashes between teams with different priorities.

Our evening event was a dinner cruise down the Seine, followed by drinks at Cafe Six in town. A free bar always makes the conversation flow, and I was thrilled to not only sail past the Eiffel Tower twice, but also to take some snaps without dropping my camera overboard.

Back at the conference the next morning, the hangovers made the mood a little quieter, but the first presentation of the day was the excellent How we release software for GOV.UK, a project that I have been enormously impressed with lately. Their attitude of ‘digital services so good that people prefer to use them’ has lately earned them Design of the year 2013, and are an exciting example of how successful the DevOps approach can be: API access for everything, urls appendable with .json for consumption, fast release cycles, open source everything, archived versions made publicly available, and very blurry lines between developers and operations interests and responsibilities.

A couple more presentations followed, then a few ignite talks, including one from the CFEngine folks which touched on the need to abstract complex systems in order to be able to view problems from different perspectives, and then lunch. More open space sessions followed after lunch, before the scattering of the participants to the wind. I left with pages of notes of things to read, install, write about, and experiment with. Now I just need to find the time to do all of these things. If only I didn’t need to sleep.

On a cold Thursday in March, 40 odd developers headed down to ‘devs in a ditch‘ to share their pain of living with legacy code and feast upon Pi controlled robots.

Living with Legacy Code

Dan Swain and Leon Hewitt kicked of proceedings with horror stories about living with legacy code.

Starting from Michael Feather’s famous definition of legacy code as “code without tests”, they explored the definition of legacy outside of software and what it means to have a legacy system in environments where test-driven development is embedded.

How would you define legacy code, would it be in terms of abandonment or simply as code you didn’t write and don’t want to be blamed for. What is its relationship to technical debt and when is legacy code technical debt and when is it simply a mess?

Physical Pi

Romilly Cocking then talked about his startup Quick2Wire and the similarities and differences between developing with software and hardware. He even demonstrated a ssh controlled robot housing a Raspberry Pi.

On Thursday 31st Jan we held our first Devs in the ‘ditch event of 2013.

Paul Shannon convinced us that hiring a trainee is a beneficial action for almost all companies as well as the greater good of our profession. Using stats which highlight the huge imbalance between roles requiring greater than 2 years experience and those requiring less, he asks where these candidates are going to come from? Trainees can also come from diverse backgrounds, not necessarily computer science students but those with a demonstrable aptitude for it, or even from within other departments. This diversity is a valuable asset and also helps retain staff with domain knowledge. Paul then gave us a rundown of how we at 7digital are implementing our Technical Academy.

After a short break, where we took a few minutes to grab another beer and eat one of the tasty vegetable samosas or onion bhajis,  Gus Power took to the stage armed only with a pen and a whiteboard.  Gus gave us a quick history lesson of Agile and how it changed the focus from fixed time cost and features, with variable quality, to fixed time cost and quality with variable features.  He stated that there are many ‘non-functional’ requirements missing from most specs as they are much harder to quantify.  Gus has promised to write up his talk for people to read, which I hope he does because I realise that I am failing at effectively summarising it.  There is a small discussion about it going on at the Meetup page.

We’re primarily driven by meeting 7digital’s goals and objectives

• Everything we do should be driven by clear business goals and objectives. Where they are lacking we should go and find them.
• We expect business needs to be provided as problems that need solving with clear expectations and measurables without prejudice towards the implementation.

Release Early and Often; Fail Early and LOUDLY!

• It’s essential we can respond quickly to changing business requirements. The best measure of our effectiveness in doing so is via frequent predictable releases through a steady rhythm of working. Things need to be easy to change (maintainable) and delivered at a sustainable pace.
• It’s far more preferable to get something in production as soon as possible and develop iteratively based on feedback than to get bogged down in speculative analysis or a fear of not making all the right decisions up front (be that regarding technology choices or requirements).
• Failures are expected, and welcome. When projects fail, we learn about other routes that might work. When software fails, it tells us about invalid assumptions we’ve made. The earlier and louder the failure, the more valuable that information is.

The best solutions come from everyone working together

• We do our best work when we work closely and collaboratively – within teams and across organisational disciplines.
• As much as we all have our specialities the most effective outcomes come from great collaboration and teamwork and rarely from deference to authority.
• We actively encourage a culture of healthy conflict and disagreement, but we also expect everyone to respect each other’s differences, to be looking to get the best out of each other and – when the consensus is against us – to work towards the chosen solution as if it was our own.

We prefer to solve problems that people haven’t solved before

• We prefer to use things that are already there. When faced with a challenge we should first be looking for – and evaluating – prior knowledge and implementations , whether that be internally, via open source software or 3rd party vendors.

• When we can solve problems using other people’s tools or software, we have a preference for things which are already used, already known, or already written … in that order.

We prefer not to do the same thing twice

• Repetitive manual tasks are cumbersome and prone to human error. If something needs to be done twice it should probably be automated.
• To aid this goal, when making choices we should lean towards those technologies that lend themselves to automation. These technologies often share characteristics such as having an API; being drivable from a CLI; not having licensing complications that require manual interactions; choosing to ask other services for information frequently rather than storing it internally.
• However, we’re aware of the desire to abstract solutions too early, in order to solve superficially similar problems with the same tool. We know this is both attractive and dangerous!

We make and use things which are discoverable and accessible by design

• Our applications and services, and information about their states, should be easily discoverable and accessible by services such as diagnostics, monitoring, other collaborating services, and the human eyeball.
• We should all work towards and comply with common shared standards, whether that be internal ones or industry best practice. Where those standards don’t exist we discover and implement them.
• We prefer 3rd-party technologies which are easily discoverable by design and best comply with our shared standards.

We are mindful of failure

• All our applications need to be resilient, robust and secure. To achieve this we should be preoccupied with all the ways our services can fail and design them in a manner that means they degrade gracefully, we’re alerted as soon as something is wrong and can quickly diagnose and rectify problems.
• We resist oversimplification and the urge to write off small problems as “business as usual”.
• We encourage a just culture where people can feel safe to report adverse events and near misses without fear of punitive action.
• We’re mindful of all the possible ways that our services could be exploited and have security front of mind with everything we do.

We don’t like inappropriate intimacy

• Applications or services should not have intimate knowledge about the innards of anything else.
• If one service fails this should not indirectly affect any of our other services.
• Tight coupling via unnecessary dependencies also causes business friction and slows us down.

On Monday 3rd and Tuesday 4th December Paris held host to the first international API focused event in Europe – APIdays.io.  Myself, and my colleague Hibri, eagerly took part and we gave a short presentation on how 7digital grew their public API, the lessons we learned and the effect it had on the way we work.  You can view the slides at the end of this post.

We received great feedback from our slides – it felt as if many people are just getting started in the world of APIs whilst 7digital have had their public API for many years and that they were very interested in hearing our real-world story.

The format of the event was a little odd, with talks in slots of less than 30 minutes, which on the plus side meant that we got to see a lot of different viewpoints and experiences but that there wasn’t enough time for anyone to get deep into a topic.  I’d like to suggest that a technical track has available 1 hour slots for anyone who wants to host a full-on technical presentation and debate – it felt like we barely scratched the surface in less than 30 minutes. It was a great couple of days, and the first time I’d ever been to Paris.  I’m hoping that this event becomes a regular conference and that next time we can get far more technical with the content and swap the really gritty stories of lessons learned.

(Cross-posted from my personal blog here)

A few weeks ago 4 developers from our team went up to the Museum of Science and Industry in Manchester to take part in Hackmanchester. This 24 hour coding competition was designed to get teams from various companies, user groups and universities to build a product or investigate an idea, in 24 hours, to meet various challenges.

We sponsored the event as we thought it was a good place to gain exposure both for our consumer brand and for our development team. We’ve struggled in the past to hire decent developers and spreading our catchment further north seemed to make sense.

Winning…

To cut a long story short, we won the challenge that we entered, as offered by Esendex

We want to see our simple APIs used in smart ways. We’ve got a handy Push Notifications service for receiving messages and status updates, and a REST API for sending (and everything else). Come up with a clever way of using them and there’ll be a cool prize for you and your team!

You can see the result of our labours on AppHarbor or in the expertly narrated demo video since we’ve turned the API key off now. We also conducted an interview for Esendex with a picture of the team displaying our well received prizes.

…with a Sustainable Pace

I don’t propose that we had some secret to winning but found that we weren’t as stressed, tired or panicked as other teams and we believe that was due to the way we worked during the event. We followed practices that we use every day, and that we know work well.

Early on we decided that it was folly to expect us to stay awake for 24 hours and still produce a quality product. Instead we decided to opt for a rough 2am deadline to go back to the hotel for sleep, before continuing the next day after breakfast. We also ensured that we had breaks for food and regular stops to the copious fruit, squash and sweet supplies. While some teams stayed awake all night long they said that they produced terrible code in the early hours, argued more, and changed direction due to lack of confidence. We maintain the quality of our code through ensuring we could focus and make clear decisions by calling it a night at 2am. We follow a practice of sustainable pace at work too, discouraging anyone from working late or at weekends and ensuring releases are done within set hours.

Release Early, Release Often

We had a working skeleton out within 40 minutes – it only had a “hello world” web page on it but it proved that we could easily commit changes and have them appear on our host. AppHarbor also provided a build history and post commit hook, which is why it was chosen initially. Now every commit would be built, tested and deployed allowing us to release roughly every 5 minutes. This constant integration and feedback meant we didn’t build on broken code and all commits could be tested. We used a Nexus 7 as a continuous integration monitor showing the build results on AppHarbor so we could react to any broken integrations – the key was visibility.

Prioritised Backlog

Before any code was written we’d discussed and written up, on simple index cards, the features that we thought we could build. We originally decided on two sites, both SMS driven, one for football and one for music, but once we’d prioritised the features we found we could provide more value by adding features to one site then by having two. It also simplified the architecture of the site, allowing us to deploy the web front end and API in one. We reviewed the features and priorities at regular intervals (roughly 4 hours) and had a code freeze 2 hours before the end of the programming session. The code freeze meant we could polish up the interface, fix little niggles and prepare demonstration too. Although we try to separate services during our day jobs, we do prioritise features and hold code freezes during times of high risk.

Pair Programming

A practice we couldn’t do without on the day was pair programming. The sharing of knowledge and ideas when building something some quickly meant we could add features quickly. As the night wore on it was also great for spotting mistakes and maintaining focus. We organised our pairs to play to people’s strengths too. I heard one team say they didn’t work well together as they were in different teams when at work – but so were we; 2 from the Locker Team, 1 from Media Delivery and an Assistant Director of Technology.

Simple Services over Tests

Although we had a test project early on we didn’t use test driven development. We started to regret this as the application got more complex and we’d started to introduce small bugs later in the day. We decided that keeping the services simple, and sticking to separation of behaviour should allow us to make changes with confidence.  The most risky part of the testing was the sending and receiving of SMS so decided not to automate that and simply use our application instead. This gave us the added benefit of user feedback as a side effect of our need to manually test it. As the code was to only live for 24 hours it made sense that we’d be able to cope with that risk but since we were asked to pass on our code for the Junior Hackmanchester attendees we wished we’d used TDD as the codebase would have been much easier to work with for newcomers. It also meant we did not refactor the code as much as we should have due to the additional cost of manual testing.

Conclusion

We’ll definitely be attending similar events again. We found they are good tests of both your programming and organisational ability. It might be good to adopt other practices and drop some we tried here to see if it makes a difference for such an event. We’ve also started working with Esendex and their local university to sponsor a code quality prize for their project module, more on that later.

It began with an off-hand comment on the ACCU General mailing list that at 7digital we release on average 50 times per week, across all of our products.  I thought nothing of it, virtually all of our products are web-based, which makes it relatively easy to deploy on a regular basis, but it seemed that others were interested in how we do it and so I was cajoled into giving my first presentation.

I began by explaining what we understand as Continuous Delivery – a set of repeatable, reliable steps which a change must go through before being released.  In our case most of these steps are automated.

I described where we came from and how we approached the change, in both a technical and business manner, and where we would like to see ourselves going.  I then included a flowchart of  A Day in the Life of a Change at 7digital, which Prezi allows me to ‘bounce’ around as we hit different stages in the pipeline.

I answered many questions clarifying how we handle rolling back a bad release (we actually ‘roll-forward’ with artifacts of the previous ‘good’ release), whether our QA team are comfortable with the process (yes, they help write the criteria),  and how large pieces of work are tackled (we try to break them down into deployable pieces no bigger than a day).

Here are the slides:

(cross-posted on my personal blog)