hack 24 logo

This Spring, on the 2nd and 3rd of May, 7digital are proudly sponsoring a new hack day, set up by the Tech Nottingham community - Hack24.

During this 24 hour coding competition, teams of 4 compete to win exclusive prizes, by showcasing their innovative ideas and raw tech talent!

Set in Nottingham's Creative Quarter, this will definitely be an exciting Hackathon to be a part of.

How to get involved?

7digital folk listen up, now we've set an API challenge as described below; we're looking for 4 people to form a team - it doesn't matter what your specialism is, what department you're in, a team formed of product, systems, data and dev people might be just as good as 4 hardcore h4xx0rs.
 
Challenge: Build a context-based or thematic music application, service or store using the 7digital API augmented with data or APIs from at least one other source.

Context is key to the new wave of music applications. All you can eat music or massive download catalogues are hard to navigate and only let people discover what the retailers think they should. With the onset of wearable technology, open access to contextual data from the internet of things and the general increase in availability of processable data, we can now inform decisions in real-time based on the context in which that person, action or event exists.

Imagine that your music choices could be informed by the weather, or the city you're currently in, or the fact that your friends are all talking about the latest band. What if your music app knew you were running, or cycling, or dancing? Consider that you might want to only listen to rock, or classical, or Christian music or music from bands formed in Nottingham. We have 32 million available tracks to play, but you'll not want to listen to all of them (that's about 369 years of listening) so picking themes is important, and playing them based on the listeners current situation makes them even more important.

The 7digital API allows you to search, list by genre, purchase, preview and stream from our worldwide music catalogue. Couple this with another API or data source, using our partners like MusicBrainz, our matching API, or by combining another API through text searching, and you should be able to create something unique.

Entrance is FREE, we'll take care of the logistics, so all you have to do is sign up for the Hack here!

 

Tag: 
Hackathon
Hack
music app
app
API
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.