Archive for July, 2012

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

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


People Tag:

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



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



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.