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

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

In today’s world of software engineering, traditional relational databases (RDBMS) like MySQL or PostgreSQL databases are no longer the ‘de facto’ choice for a database system. Since the increase in popularity of cloud computing, NoSQL databases have risen to play an important part in data architecture in the cloud. Cloud servers no longer guaranteed dedicated performance (disk io / cpu / memory) as well as a 99.99% uptime. The best approach of designing software in the cloud is by designing the application to expect failures. This proves to be an issue as databases are usually the living heart and soul of any data-driven application. Without data, the application cripples.

Because Cloud Computing provides the ability to scale server resources up/down easily and quickly, the database design will also need to respond to the change in traffic load and scale accordingly. Most databases will have replication features, which you can setup a master-slave network of databases to help ease the load of a high-read application. But what about a high-write application – would you need to consider sharding?

The key point to take away from this post is that although there are many databases available that you can choose from (MySQL, PostgreSQL, Redis, Riak, MongoDB, CouchDB, HBase, Cassandra, Neo4j, etc.), there is no such thing as the ‘best database for the cloud’. In order for you to choose the ‘best’ database, you must first identify the needs of your application. If you are familiar with the CAP Theorem (Consistency, Availability, Partition Tolerant), different databases are designed for different combinations of CAP. Although there are many blog posts on the interweb comparing the different variations of databases, you should not base your choice solely from these results. For example, although big corporations like Twitter and Facebook use HBase for some of their products, doesn’t mean that you should implement HBase on your design. Perhaps a less complex setup is key and therefore a database like CouchDB is more suitable. So below are a few of the key questions you should try and answer which should help you narrow down the choices so that you can then focus on the details of the databases and then ultimately choose the ‘best’ database for your application.

Is your application read or write heavy? or both?

  • Read-Heavy – [DBs with Replication feature i.e. almost all] most databases provide master-slave (or even master-master) replication. Replication will have handle the load of read-heavy applications.
  • Write-Heavy – [DBs with Sharding feature i.e. MongoDB, HBase, Cassandra, Riak] whilst you can have a master-slave setup, all writes (i.e. inserts / updates / deletes) will be directed to the master. In order to take some of the load off the master, you need sharding
  • Both – [DBs with Replication and Sharding feature i.e. MongoDB, HBase, Cassandra, Riak]

Do you have an ops team to help with the complex setup / management of db clusters?

  • Databases like MySQL, CouchDB are very easy to get started with on a single server. They provide easy to use GUI / admin tools that you can experiment around with. Others like HBase, Cassandra and MongoDB will require more planning and architecture design to get an optimized setup.

Does your data need guaranteed durability?

  • Databases like MongoDB and Redis are known for their blazing speed because they first store values onto memory which then gets flushed to disk periodically. However as a trade-off to speed, they are a threat for data not being persisted given a DB failure event.

How big is your data?

  • Databases like Cassandra and HBase are designed for ‘Big Data’ ground up. However the ability to handle huge data comes at a cost: complexity

What is your primary goal and what does your application dataset resemble?

  • Are you building a write-log type system, or a read-cache reference type system, or a write-analyse analytics type system? Does your application natural fall under a key-value (Redis, Riak) / document orientated (MongoDB, CouchDB) / relational (MySQL, PostgreSQL) / columnar (Cassandra / HBase) or graph (Neo4J) type data model?

Do you need features like map-reduce / secondary indices / REST interface / views or stored procedures?

  • Some databases provide a subset of features where others don’t. For example, if you need a feature like secondary indices, you would choose MongoDB over CouchDB.

There are many other questions you should ask yourself but the bottom line is: there is no ‘right or wrong’ database. Instead there are ‘suitable and less suitable’ ones. In fact, you don’t even have to choose just one – a combination of multiple databases could as well, yield the best result.

@munwaikong

Infrastructure