Archive for the ‘Development’ Category


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.


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.


Development Infrastructure ShowCaster

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!


Development VoiPay

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



Ok, I will admit it. I had recently fallen in love with Javascript. So much so, that I went back and refactored a whole bunch of code and made it all pretty, and easy for others to read, learn and use.

As part of my love for javascript, today I would like to share some of the things I have done – with hope that in the future, it might be useful for you.

1) Encoder.js – A simple webcam encoder / browser-based stream publisher

Encoder.js is a simple JS API that configures a simple lightweight AS3 Flash application and streams your webcam to a streaming server of your choice. Below’s an example of how easy it is to get started with just a few lines of code:

<script type="text/javascript" src=""></script>
<script type="text/javascript">
			// The div to insert the webcam preview
			container: '#holder',			
			// Setting the preview width
			previewWidth: 800,			
			// Setting the preview height
			previewHeight: 480,					
			// Setting the Encoder configuration
			config: {							
				streamServer: "rtmp://",
				streamName: "example",
				bitrate: 800,
				videoWidth: 640,
				videoHeight: 360,
				fps: 15,
				keyFrameInterval: 30
			// Setting up event listeners
			events: {
				onReady: function() {			
					// Auto-start

There is still room for improvement (like a full documentation of the JS API) but you can start and have a play with it by adding

<script type="text/javascript" src=""></script>

to your html file.

2) Log.js – Simple Javascript Logger / Debugger

Log.js is a simple lightweight ‘library’ that I find very useful, and that should be included in any javascript enabled web-based project. This is not as full-featured the Log4X libraries i.e. Log4JS but it does the job. Note that this logger relies on the ‘console’ object being present – hence it works on modern browsers like Chrome, Safari as well as plugins like Firebug for Firefox.

// How to configure the logging level
Log.configure("info"); // Logging Levels [VERBOSE, DEBUG, INFO, WARN, ERROR]

// How to log to console
Log.verbose("tag", "This is the verbose log"); // This won't be displayed
Log.debug("tag", "This is the debug log"); // This won't be displayed"tag", "This is the info log"); // Prints "This is the info log"
Log.warn("tag", "This is the warn log"); // Prints "This is the warn log"
Log.error("tag", "This is the error log"); // Prints "This is the error log"

// How to filter the logs for a specific TAG

Download the source code of the library here. (Only 120 lines non-minified)

3) Data.js – Data / Storage Helper Library

Data.js is another simple and lightweight ‘library’ that could be useful if you would like to store key-JSON (an extension of plain text key-value) pairs either temporarily or permanently for your web-application. It provides two different types of data store: ‘TempStore’ and ‘PermStore’. The TempStore stores your JSON data (with your key of choice) temporarily – i.e. if the user refreshes the page, the data is lost. This is useful to store temporary information from AJAX calls to be referenced later. The PermStore stores your JSON data ”permanently – using HTML5′s localstorage. Data is only lost if the user ‘resets’ their browser or clear any browser data and cache.

Another neat thing about this library is that it provides a ‘expiry’ feature, where by if you would like, you could expire the stored data after X period of time.

Let’s have a look at how to use it:

// Store a response from an ajax call (using jQuery)
	url: "webservice.php",
	dataType: "json",
	success: function(data) {

		// Store the response JSON object Temporarily
		Data.TempStore.set("response", data);

// Store your own JSON data object

var data = {
	"name" : "mun",
	"age" : 26,
	"location" : "london"

// Store the data in the PermStore 'forever'
Data.PermStore.set("myself", data, Data.EXPIRES_NEVER);

// Read the data from the PermStore
Data.PermStore.get("myself");		// prints {"name" : "mun","age" : 26,"location" : "london"}

// Store the data in the PermStore until 30 mins later (i.e. 1800000 millis)
Data.PermStore.set("myself", data, Data.EXPIRES_(1800000));

// Read the data from the TempStore
Data.TempStore.get("myself");		// prints undefined - since 'myself is stored in the PermStore instead of the TempStore

Download the source code of the library here.

So hopefully you will find these simple libraries useful to you as well. Enjoy and as always, feel free to leave a comment of what you think about these libraries.




If you are a developer dealing with iframes and cookies, then you would probably know this, but if not, then here is something to think about:

If website A ( is hosting an iframe whose url is website b (, and website B attempts to write a cookie – either via HTTP headers or javascript – it will work on Chrome and Firefox but not Safari (and IE actually).

*Note : The scenario described above is only true for the default settings of each browser. Unlike Chrome and Firefox, Safari by default sets its privacy setting to ‘Block cookies from third parties and advertisers. Obviously setting your privacy settings to ‘always accept cookies’ will mean that you won’t encounter the problem described above.

There are solutions / hacks that bypasses Safari’s privacy settings (like posting the iframe to itself) but sooner or later these loop holes will be fixed and closed by Apple. Perhaps this doesn’t affect you, since your application doesn’t rely on cookies (say for example a static html or image) however for the rest of us – this behaviour is bad news.

But what about HTML5′s localstorage? Why don’t we use that instead? Well, if the use of cookies is controlled by your application – i.e. you need to store “remember_me=true” locally on the client browser – then localstorage would be a good place to do this. However, that doesn’t solve all the issues as there are other types of cookies that are transparent to your application. Let’s look at 2 examples.

1) Session cookies – If you’re using a dynamic programming language that supports sessions (like jsp / php / asp / etc.) then the server will most likely insert a session cookie seamlessly on your behalf (i.e. a JSESSIONID or PHPSESSIONID).

2) Load Balancer cookies – Most load balancers (physical or cloud based) use cookies to track and manage a persistent connection. The load balacer will seamlessly add an extra cookie to the HTTP response (i.e. X-Mapping-abcdefg) which is used to determine which server to route all future requests to.

Putting the above into context, if your session-dependent web application is spread across multiple servers via a load balancer and is situated within an iframe in another domain, then any new Safari user visiting that site for the first time will have:

a) a different session id each time – since the session id cookie was blocked by Safari’s default privacy setting

b) a different server serving its requests each time – since the load balancer’s x-mapping cookie was blocked by Safari’s default privacy setting

This will then lead to unexpected behaviours like being logged out repeatedly or session data inconsistency (i.e. data across different servers is different). So how do we go about fixing this issue? Well, there are some work arounds available on the interweb. However, a workaround is only a short term solution and will work only until All Mighty Apple decides to shut it down. Therefore the best solution to this is to know the limitations of Safari (and its iOS webkit browser cousins) and then architect your applications to expect the behaviour where cookies can not be stored. For example, use localStorage where applicable, or don’t depend on the use of cookies, or don’t use iframes, or even better – inform users Safari’s not supported. :)

Let us know what you think of Safari and its default privacy settings.