studio_title

We recently updated ShowCaster Studio to give users the ability to customise how they embed the ShowCaster player. This has become a common feature amongst some online services, however everyone seems to have their own interpretation of how to present this information to the user.

We approached this task as we do all of our user interface designs: the goal is to only present critical information to users and minimise their cognitive load. This combined with traditional UI design principles forced us to consider presenting the embed code alongside a responsive preview of the embed itself. The idea was to add a few options that would tweak the look and feel of the player and have the preview automatically update to reflect those settings. We also added tabs to differentiate between the major layouts, giving the user quick access to a variety of common embed types. The result of this design looks like this:

embedBuidler

A crucial part of the work was to make our embed player flexible in terms of its layout and presentation, however in this post I only focus on the builder and not the embed. A follow up post will touch on how we implemented a flexible embed player.

The main technical challenge of this implementation came from the interactive preview that we chose to implement as an iframe pointing to our embed player. In order to keep a consistent feel and not throw off the page layout, the iframe width should remain the same at all times but we also wanted the preview to be interactive in terms of size. This can be easily be achieved through dynamic scaling of the iframe to always fit the allocated space using CSS3.

.embedPreview iframe {
  transform-origin: top left;
  -moz-transform-origin: top left;
  -webkit-transform-origin: top left;
  -o-transform-origin: top left;
  -ms-transform-origin: top left;
}
var scale = (iframeContainer.width()) / iframe.width();
iframe.css("transform", "scale(" + scale + ")");
iframe.css("-webkit-transform", "scale(" + scale + ")");
...
iframe.css("-o-transform", data);
// Resize height of the container to fit the transform
iframeContainer.css("height", height * scale);

The main problem now came from detecting the new width and height of the iframe once its contents had been reloaded. This was slightly more complex since we cannot query the contents of an iframe on a different domain to adjust the scaling and height of the preview.

We used HTML5 messages to pass the size parameters of the iframe contents once it had finished loading.

// Code on the embed client page (embed player)
// Fire load event to parent once the document is loaded
$(window).load(function() {
  var data = new Object();
  data.type = "embedLoaded";
  data.eventId = ;
  data.contentWidth = $(document).width();
  data.contentHeight = $(document).height();
  data.layout = "";

  window.parent.postMessage(JSON.stringify(data), "*");
});

We can then listen for those messages on our Studio page and adjust the scaling and height accordingly.

// Code on the Studio page (embed buidler)
$(document).ready(function() {
 // IE8 handle
 if (typeof window.addEventListener != 'undefined') {
   // Add event listener for onLoad event of the embedded iframe
   window.addEventListener("message", onIframeLoad, false);
 } else if (typeof window.attachEvent != 'undefined') {
   window.attachEvent("onmessage", onIframeLoad);
 }
});

function onIframeLoad (pEvent) {
  var data = JSON.parse(pEvent.data);
  var width = data.contentWidth;
  var height = data.contentHeight;
  ...
}

It is important to note here that we are passing the object as a string and not simply as an extended JSON object. The reason for that being due to IE not having access to any other attributes than the event data, i.e. the string.

Hope you guys found this post useful and you now have a better idea of how to improve your embedding experience. Happy coding! :)

ShowCaster

pinterest

Less than a year ago, I wrote a post on the different DB solutions available that are ‘cloud-ready’. For those who are still struggling with the decision of which database solution to use and want some real-life examples, I recommend reading this recent post on Pinterest’s infrastructure architecture.

Key notes from the article:

Choice of DB: MySQL + Redis over MongoDB or Cassandra
Reason for DB: Sharding over Clustering – because of maturity and ease of hire
Number of DBs: 88 Master + 88 Slaves (cc2.8xlarge = $2.700 per Hour = $1944 per Month per Server = $342,144 per month for just MySQL)

Interesting points:

  • Algorithm for placing data is very simple. The main reason. Has a SPOF, but it’s half a page of code rather than a very complicated Cluster Manager. After the first day it will work or won’t work.
  • Can’t perform most joins.
  • Lost all transaction capabilities. A write to one database may fail when a write to another succeeds.
  • Reports require running queries on all shards and then perform all the aggregation yourself.
  • Joins are performed in the application layer.
  • When the Pin table went to a billion rows the indexes ran out of memory and they were swapping to disk.
  • If your project will have a few TBs of data then you should shard as soon as possible.
  • Architecture is doing the right thing when growth can be handled by adding more of the same stuff. You want to be able to scale by throwing money at the problem by throwing more boxes at the problem as you need them. If you are architecture can do that, then you’re golden.

My thoughts:

Firstly, thank you Pinterest for showing us your infrastructure architecture. With so many choices of DBs available (NoSQL vs SQL vs NewSQL), it is very insightful and helpful for others in a position to choose which DB strategy path to follow. After analysing the post, I feel that for a small team / startup and for future proofing, a fully managed DB is a better option. Small teams don’t usually have the necessary man power to maintain and branch out new MySQL shards. What they should do instead, is to concentrate on delivering quality software and if traffic increases, to have the flexibility to push a button and let a DaaS take care of the scaling ala DynamoDB or Instaclustr or MongoHQ.

Their decision to shard MySQL meant that:

a) they can horizontally scale
b) they can run flexible (but limited) queries

however, sharding MySQL had drawbacks too:

a) you can no longer have JOINS – one of the main strong points of having SQL
b) no longer fully transactional – again, another strong point for choosing SQL over NoSQL
c) operational burden for manual sharding – your team needs to be 100% on top of data size as well as when the need to re-shard

It does feel to me that there is quite a lot to work with (though they have the man power to do so 44 engineers). But then again, they’ve done it and proved it to work – so surely it’s can be considered a winning strategy?

Thoughts?

@munwaikong

Infrastructure

Android-logo-007

Back in June 2012, when Android Jelly Bean was released, I wrote a post on streaming video on the Android platform. Streaming video to Android at that time was a challenge, but 8 months later, have things progressed? Check out the link below to find out what the guys at Longtail found.

http://www.longtailvideo.com/blog/31646/the-pain-of-live-streaming-on-android

@munwaikong

Development Streaming

ShowCaster’s success is down to its ability to scale up and down and meet the varying demands of live events – sometimes during short periods of time (typically around an hour) we will receive bursts of hundreds of thousands of users interacting with our platform concurrently (eg. when promoted on a mainstream TV channel).

We’ve just completed a project rebuilding our auto-scaling infrastructure – consisting of 2 weekends creating ShowCaster Tools. ShowCaster Tools keep track of the health and usage of our servers as well as demand-based auto-scaling, wrapped in a simple GUI .

Let’s get technical

In order to automate this process, we needed to integrate our system with Rackspace Cloud APIs. The brief was to create a simple web interface for anyone in the team to use (both techies and non-techies). Seeing as we (the techies) are always up for challenges and exploring the world of languages & tech, we thought that this would be a great opportunity for us to try a different tech stack from our usual Java.

Ruby as a replacement for our perl scripts

We currently write all our scripts using Perl. So far it has done the work without issues. However, everyone who has used Perl knows that it’s not the easiest to learn. Every time a new developer joins our team, it takes a while until they fully understand the language and how to make the most out of it.

Ruby on Rails as the MVC framework for the front-end

At the same time we were learning Ruby for the server side interactions, we thought that the best tool to create the web GUI was Ruby on Rails. This is one of the most famous MVC frameworks out there for web development. We always have read that the the different helpers offered by Rails together with Ruby increases the productivity of any web development so we decided it was the right time to give it a try.

The architecture

One of the first things we realized when we started to architect the application was that there is no direct support for multithreading within Ruby on Rails. There are some “hacks” but none of them were appealing to us. For this reason, we ended up splitting our application into two main components. The first component was entirely implemented with Ruby and is in charge of all the business logic of the application. Things like:

  • Multithreading
  • Rackspace APIs interactions
  • Server monitoring and management

The other component was built with Ruby on Rails and looks after the user interface. This provides two main benefits:

  • Split the logic from the view (MVC)
  • If we decide that Ruby on Rails is not for us, we can easily bin it and start from scratch with another framework

The conclusion: Ruby yes, Rails not so much

After creating ShowCaster tools, Ruby has impressed us – especially for its SPEED. Other reasons:

a) The number of lines of Ruby code is significantly less – meaning a faster development cycle, less bugs and easier maintenance resulting in increased productivity.

b) We liked the simplicity of Ruby when integrating with other libraries – thanks to their valuable gems. We installed the Rackspace Cloud gems for their load balancers and servers and within 5 minutes we were ready to make requests to their APIs.

Ruby on Rails provided a good implementation of the MVC pattern, awesome helpers to speed up the entire development, and we easily understood how using it would improve long term productivity.

Working with the Rails ActiveRecord helper was a great experience compared to similar frameworks – we’re very familiar with Hibernate for Java and ActiveRecord was far simpler, better and faster in terms of data definition and usage than Hibernate.

In order to take full advantage of Rails, you really need to make complete use of all their helpers and tools – but in most of our user interfaces these helpers and tools wouldn’t be applicable, losing some of the potential of Rails.

Based on this experience, we’ll use Ruby to replace all our Perl scripts over time, providing us with benefits in the long term.  Rails won’t replace the web development tools used on our core products but it will definitely be considered on future projects where the potential of Rails can be used to its maximum.

@isaacmartinj

Development Infrastructure ShowCaster

hiring

Bring on 2013.

2012 has been a hell of a year for the team @ Orca Digital. We have achieved amazing feats for our products i.e. ShowCaster and VoiPay and pushed hard to get the products to a level where they are now. But we’re not stopping there – in fact, 2013 will be even more of a rock’n’ roll year. We’re expanding the team further to cope with the increase in demand and new features we want to pump out into our products.

What are we looking for?

UI/UX designers, Java Developers, Web Developers, Server-side Gurus and Javascript wizards – these are all standard roles that you normally find in organisations hiring into their engineering / technical departments. However, the startup world is a little different. In a startup environment, we want all those skills bundled up into one, and more. What else more, you ask? A term that is floating around the industry is ‘Growth Hacker‘. That doesn’t mean we want sloppy devs that can only hack code around. What we want is a class above, someone who knows the trending topics of the industry, who has a solid foundation of programming with a great understanding of user experience. Someone to take ownership over their work and believe in what they are doing. In a startup culture, a candidate with the ability to spot trends and drive external interest to their own products is more valuable than an experienced old school Java Enterprise guru who knows the SOAP protocol by heart. I’ve recently read an article written by Elli Sharef for VentureBeat on the 5 things you need to know before working at a startup.

Even though Orca Digital was founded in 2006, we like to treat each of our products as separate entities or ‘companies’ (similar to Spotify). Each product is lead by a small team of engineers which takes the product forwards – driving product development and user interests back to the product they’ve just built. Do you have what it takes or know someone who does? Take a look at the job opportunities at Orca Digital and ShowCaster.

Happy (belated) New Year!

@munwaikong

Team

The brief

The team @ShowCasterTV has recently completed a make over of its interactive polls feature. ShowCaster Polls enables user to run live interactive polls across the web, tv, tablets and phones and is a great use for 2nd screen applications. ShowCaster is used by a large TV broadcasters such as Channel 4 and Sky so scalability is a key consideration – all features need to support extreme load from large numbers of concurrent users.

A poll’s functionality by design is quite simple – a single question and a few options to choose from. Its simplicity should also be reflected on the user interface in order to deliver a good looking, yet focused poll-driven experience. The task at hand was to give the previous design a make over, but at the same time ensuring its simplicity remains intact, as well as ensuring the new UI adapts nicely across the multitude of screen sizes and applications that ShowCaster integrates with and is embedded into.

The challenge

The challenge was small – choose a design that will fit across multiple screen sizes and render the experience nicely across all platforms. However, the bigger challenge was the fact that our UI designer had decided to leave the country and begin his adventures elsewhere. This then lead to a bunch of hardcore engineers used to writing awesome code, instead spending time scratching our heads staring at something called a paintbrush tool. It wasn’t going to work, but we needed to refresh the UI quick.

The saviour

So, after looking around for help, we stumbled across something we were on more familiar grounds with. Twitter? Good. Framework? Good. Open-source? Good. Twitter’s open-sourced UI framework? Awesome.

With Twitter’s Bootstrap UI framework, we were able to use predefined UI elements, which come with all the bells and whistles i.e. nice CSS3 features like border radius, box shadows, transitions, and it includes all the browser specific shims and prefixes – all supplied by Bootstrap! Not only does it render well, it all works beautifully by simply adding a predefined style or data class to an HTML element – well, with exception to IE8 – but since no one uses IE8 anymore cause its crap, we’re fine right? :)

Responsive UI

For those who know a little about Bootstrap, the scaffolding structure is pretty neat – especially since it works nicely when enabled with ‘responsive features‘. With the responsive features enabled, Bootstrap adjusts the scaffolding structure to stack when the screen width is less than 767px using CSS3′s media queries. As powerful as it is, we have disabled it on our design because the simple design of the Polls concept needed the page to be ‘adaptive’ (to grow and shrink with the page) rather than responsive (stacking elements / increase element visible measurements).

So, without further ado, below are some screenshots of what we were able to churn out within a couple days.


Want to see the whole thing in action? Sign up for ShowCaster (free) and try it out yourself.

@munwaikong

Oh… and btw, looking for a design role? We’re hiring!

Design ShowCaster

Hooray!

After working ridiculously hard for the past few months, I’m proud to give you myVoiPay. Not only can you can now add and manage VoiPay Calls & MicroPayments services from a slick and simple user interface, myVoiPay also provides up-to-date analytics for all your services. From the dashboard of myVoiPay, you can set up new services and start generating revenue within minutes. The dashboard also features a simple graph and summarised table data to show you how your services are performing at a quick glance. Need a more detailed view? No worries – you can also download the raw detailed data into a csv file and query the data as you wish.

 

 

The brief of the project was to keep it slick, simple and clean. It is easy to clutter a self serve portal with configurations that no one really understands and will never really use, so we wanted a self serve portal where you can do everything all from the same page. i.e. create, edit, delete, clone services all from the same dashboard that displays your analytics data.

Another neat feature we implemented is service sharing – enabling you to share  analytics data for certain services with others (for example sharing with affiliates or partners) or allow others to manage your services on your behalf – all without giving up your username and password. This can be done by sharing the service(s) with other user(s) with permissions of ‘Admin’ or ‘Viewer’.

Is there more?

We have lots of exciting new features planned for myVoiPay in the near future – so stay tuned for more. i.e. you might find a feature to run promotions in the near future (you didn’t hear it from me).
So… what are you waiting for? Sign up for free and give it a whirl.

Props to the individuals involved in delivering this milestone – Go Team VoiPay!

@munwaikong

VoiPay

VoiPay is a premium web telephony platform  - brought to you by @OrcaDigital. In simple terms, VoiPay allows developers / webmasters to charge a premium rate for any telephony service globally by embedding a few lines of code. Using VoiPay’s single sign-on wallet and credits system, end-users from around the world benefit with VoiPay’s single login across multiple VoiPay enabled sites, as well as the ability to pay for content via multiple payment options such as credit card and premium rate numbers.

Now with the latest release, VoiPay adds MicroPayments to its feature set – enabling developers, webmasters and content owners to charge for content using the same VoiPay wallet and credits system. VoiPay end-users can now purchase content from a website by using the same account and credits they currently own.

MicroPayments is designed for ease of integration and minimalistic setup so you don’t need programming knowledge in order to use it. However, if you are a developer or have knowledge in that area, MicroPayments also provides an advanced developer API which provides a richer set of features – such as the Notification API and custom parameters – for a tighter integration with VoiPay MicroPayments.

Want to deploy a premium rate support helpline? Want to charge for access to your website? Try VoiPay and MicroPayments for free now - simply drop us a line and tell us what you need or sign-up and try it for yourself now!

@munwaikong

Development VoiPay

Every year, the team @ Orca Digital set out for an entire day’s worth of adventures, where by they have to leave their comfort zone and explore what the world has to offer. In 2010, we brought the team to a tree climbing / zip lining activity - Go APE! and in 2011 we went for a 80 lap endurance karting event. This year, it was Thorpe Park, to face the dreadful rides of Saw, Stealth, Colossus, Nemisis and the latest addition – The Swarm. Check out the pics below for some of the action shot on that day.

 

PS: There’s more too – check out the facebook album here


@munwaikong

People Tag:

@willneale @stephenmgeorge @munwaikong @cbaorambo @slaweklatka @jonasnode @kika_santamaria @sebkabuto @princemule @zahra289m @streamaxion

 

Team


Google’s latest dessert on the menu was shipped with flagship device Nexus 7: Android 4.1 Jelly Bean. Whilst you can find all the new features and fixes of this software release here, what’s more interesting for the engineering team @ Orca Digital is what it means for the future of video on android.

There are multiple ways of delivering video to Android devices: RTSP, Progressive Playback / Download, via alternative components (i.e. Flash or YouTube) and since Honeycomb (3.0) – HLS (HTTP Live Streaming). For VOD (Video-on-Demand) media, progressive playback / download is by far the easiest option – allowing for static mp4 / mov files to be consumed via a native app or in-browser (using HTML5 video tags). For LIVE media however, it is harder. Native apps and browser sites rely on RTSP and Flash (and HLS since Honeycomb) to deliver their rich video content.

However, as some of you may know, Adobe had announced back in November last year that it will stop supporting future iterations of the Android OS after 4.0 (Ice Cream Sandwich). In June, they made their position clearer by stating that they will be removing the Flash Player application from the Google Play Store after August 15. This meant that although Flash is a prominent platform for delivering video on the web, its a completely different story for the mobile space (no flash on iOS and Android 4.1+). This narrows the choices of video delivery down to RTSP, Progressive and HLS (only 3.0 and above). Furthermore, for live video, progressive download is not an option, hence RTSP and HLS are the only options.

In summary, due to the fragmentation of Android devices (in terms of OS versions and device variations), application and website developers will now have to re-consider their approach towards delivering video to android devices. Flash is becoming obsolete in mobile, Google is jumping on the HLS bandwagon, but at the same time existing 2.3 users (Gingerbread and below) can only consume RTSP content as HLS is not available. Good luck!

Update (2012-08-22): Also to note – since Jelly Bean will use Chrome as the default browser and ditch the ‘Internet Browser’, the H.264 codec support will also be dropped and so only WebM videos can be consumed on Jelly Bean’s Chrome HLS video playback. (What were they thinking?)

Update 2 (2012-09-28): Here’s a link to the how the BBC dealt with the changes for their native iPlayer application. In summary, the BBC has (interestingly) decided to still bet its cash on flash – by building a ‘player’ application (written using Adobe AIR) which will accompany the standard application. In a good way, it does ensure that the majority of the phones all share the same user experience

Update 3 (2012-10-17): Here’s also a good read about video on android

@munwaikong

Development