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:

1 - Product Challenge - To create a platform, or product that could redefine media consumption.

2 - Creative Challenge - A user-generated experience using Astro’s Assets.

The build could be an app or web-based and they let the competitors define the platform.

They feverishly worked into the night, honing their development skills, whilst nibbling on pizza  when they had chance.

Day 2: Pitching sessions - Sunday afternoon

Sunday evening drew the long competition to a close.

Well deserved drinks and cakes were on the menu, to celebrate all the hard work that these talented techies went through this weekend! 

It’s the taking part that counts, right?

Goinnovates’ 2014 Hackathon encourages skilled people from all over Malaysia to get involved, learn from one another and share experiences, so taking part does count! A 48-hour hack event however, wouldn't be complete without some prizes now, would it?!

A panel of judges picked the most creative ideas and offered several cash prizes with a sum of RM 50,000 (£9,500)! There was one final winner and 1st and 2nd runner-up.

Fancy your chances next year? Keep an eye out for 2015’s competition announcement at http://www.astro.com.my/goinnovate

sharri.morris@7digital.com
Tuesday, April 28, 2015 - 16:27

Why metrics? Since I joined 7digital I've seen the API grow from a brand new feature side by side with the (then abundant) websites to be the main focus of the company. The traffic grew and grew and keeps on growing in an accelerated pace and that brings us new challenges. We've brought the agile perspective into play which has made us adapt faster and make fewer errors but:

sharri.morris@7digital.com
Tuesday, March 17, 2015 - 12:49

I wanted to start looking at alternatives to our current set of cucumber feature tests. At the moment on the web team we're using using FireWatir and Capybara. So I though I'd take at look at what was available in Node.js. Many people think it's strange that a .Net shop would use a something written for testing Ruby or even consider something that isn't from the .Net community. Personally I think it's a benefit to truly look at something form the outside in.  Should it matter what you're using to drive your end product or what language your using to test it? Not really. So what are the motivations for moving away from Ruby, Capybara and FireWatir? In a word 'flaky', we've had heaps of issues getting our feature tests, AATs and smoke tests reliable. When it comes to testing, consistency should be king. They should be as solid as your unit tests.  If they fail you want to know that for definite you've broken something, rather than thinking it's a problem with the webdriver. It is with this aim in mind that I started looking at the following. Cucumber.js is definitely in it's infancy, there's lots of stuff missing but there's enough there to get going. Zombie.js is a headless browser, it claims to be insanely fast, no complaints here.

sharri.morris@7digital.com
Tuesday, March 17, 2015 - 12:44

After seeing some relative success in our Solr implementations xml response times by switching on Tomcats http gzip compression, I've been doing some comparisons between the other formats solr can return. We use Solrnet, an excellent open source .NET Solr client. At the moment, it only supports xml responses, but every request sends the "Accept-encoding:gzip" header as standard, so all you have to do is switch it on on your server and you've got some nicely compressed responses. There is talk of supporting javabin de-serialisation, but it's not there yet. I've decided to compare the following using curl with 1000 rows and 10000 rows in json, javabin, json/gzip compressed and javabin/gzip compressed.

anna.siegel@7digital.com
Wednesday, March 11, 2015 - 12:27

 

Following changes to our Catalogue API, we are releasing a change to the Basket API to support premium quality formats.

This release adds a package element below basketItem in all basket responses. This is to support the sale of music in different audio formats.

An example response would now look like this: