麻豆约拍

Hi I'm Duncan Fortescue the technical lead for the 麻豆约拍s .

Last month saw a major milestone for our team here in in Salford as we launched the Connected Red Button on its first platform ().

See 聽post聽for more information.

This has been a fairly long journey for us in terms of the use of in a technology project so I'll attempt to give you the what, why and how of the project from a technical point of view.

Techies like requirements

The project team responsible for this first iteration (or version) of the Connected Red button is a dozen strong multi-disciplinary software engineering team but due to the nature of the project many other areas of the 麻豆约拍 have been involved in a design or engineering capacity.

The high level requirements for the Connected Red Button were outlined by .

In short it had to:

鈥� Be multiplatform

鈥� Be accessible from the red button on remote controls

鈥� Overlay broadcast

鈥� Be contextual to broadcast

These requirements sound quite simple but it鈥檚 not all as trivial as it first appears.

Put it on the telly

From the beginning the requirement for multiple TV platforms dictated some of our architectural choices.

platforms on the market in the UK today come in several different breeds and flavours including many different client presentation technologies (examples include and Flash).

Even when the technology is the same there are often different implementations from one manufacturer or operator to another.

Regardless of which platform came first it was blatantly obvious to us that we must create the vast majority of the application logic as a common service and allow it to be used by many applications.

This gave us a very simple Client-Server architecture with the ability for multiple client implementations to be driven by the same data.

The client implementation just provides the user interface 'paint' to present the content to the user.

Now we have one server side for multiple client implementations we can just build more clients right? Well, not quite.

The different platforms have different requirements from a performance and optimization point of view. For example ActionScript based devices perform best interpreting , but HTML devices tend to perform best with .

There are also other subtleties such as slightly varying channel line ups and reliance on different streaming technologies.

This forces us to identify the client implementation on each request made to the server side for us to be able to provide the correct data.

Data, data, everywhere...

The data that 麻豆约拍 Future Media produces is enormously varied and contains a huge amount of information. As it is domain specific data looks quite different to data which again looks different to data and so on.

This variety led to our next significant architectural decision - domain providers.

For each section we created a provider service that is aware of the source data for that particular domain.

Each provider can then transform that data into a structure common across all Connected Red Button providers and decorate it with all the information a client will need to render it.

In order to tie these providers together we created another provider for the navigation. This means that any client implementation only needs to know how to request its navigation and the navigation provider can then tell the client how to access the rest of the data.

Press what?

We have to be able to launch our app from the red button on TV remote controls. But how do you launch an app that needs linear broadcast for the product to make sense in the world of app stores?

You can鈥檛. The whole 鈥楶ress Red鈥� paradigm is fantastically simple for our audience but causes us real headaches in a software world 鈥� particularly in a 鈥楻equest 鈥� Response鈥� model as we are here.

Launching applications from the red button varies from platform to platform. This requires us to have mechanisms specific to the client implementation.

In a /HTML world an MHEG application must use a specific resident program to launch the HTML Browser at a specific URL. This is only just appearing in UK smart TVs.

What happens when a flagship show鈥檚 presenter says 鈥淣ow press red for more鈥︹��? Well a proportion of the current audience on that channel will press red within a very short space of time.

Up until now our trigger mechanisms have all been broadcast over the rather than IP so we have no really accurate figures for exactly how many requests could be made and in what time period.

We have implemented a significant caching strategy including a serve stale while revalidate mechanism that ensures the user gets a quick response while our service gets new data.

In short we鈥檙e monitoring it very closely to make sure we can always cope as the demand increases.

鈥榯is but a scratch

Showing an error message on a TV is something we really want to avoid.

From an operations point of view we can turn on and off sections individually without releasing new software. This is fine but we prefer to build in preventative steps to stop that being an issue.

For example we have built in default images for when none exists and employed robust detection and degradation for data errors.

Developing for constrained devices also requires we monitor system resources very closely.

We perform extensive profiling during the development process to identify bottlenecks such as load times and this allows us to reorder events to give an improved user experience whilst still doing the same amount of work.

This profiling also shows us where memory is being used and more importantly when it is released.

Baby Steps

Even though the Connected Red Button was only launched to the public last month we鈥檝e had it running on a select few set top boxes in people鈥檚 homes for many months.

Like most software projects at the 麻豆约拍 we work using agile development methods incrementally adding small features to the product.

Our first version of the product had just two buttons and all it did was launch iPlayer over broadcast.

But this was enough to be able to see it work on a set top box and then iterate adding functionality at every sprint.

Our team tends to work in a scrum framework predominantly using two week sprints but this varies depending on the features being developed.

For each sprint our product owner and stakeholders from around the 麻豆约拍 can see the new features developed in that sprint and decide if it should be released.

Now we have released the first version we are continuing this methodology so you鈥檒l see features coming fairly frequently and enhancing the service.

Building the Vision

Like other software teams at the 麻豆约拍 we have recently adopted behaviour-driven development (BDD).

This practice involves our product owner sitting down with a tester and developer to write the acceptance criteria for each feature in English but with a strict syntax describing the scenarios of how the software will behave.

We then use this 鈥榝eature file鈥� as the basis for our testing. This testing can be manual but is increasingly automated and triggered to run as part of our continuous integration process.

These automated acceptance tests provide us with an integration test suite that we can run on devices and show the software works at a fundamental level allowing the testers to use their expertise to stress the system in other ways.

This process is augmented using test-driven development (TDD) at the unit test level.

TDD allows the pairs of engineers to have a huge degree of confidence when writing new code and performing small refactors. The automated test suite extends that safety net to larger scale refactors and regression testing.

To Infinity and Beyond

The future holds more great 麻豆约拍 content on more platforms supporting Connected Red Button.

Both the and indicated that we鈥檒l be rolling Connected Red Button out on smart TVs later this year. What you鈥檝e seen so far is only the beginning.

Duncan Fortescue is the technical lead for the 麻豆约拍s Connected Red Button.