News, ideas and randomness

Simple iPhone & iPad Video Streaming with Streamory

Posted: April 20th, 2010 | Author: Andrew Gleave | Filed under: Company, iphone, mobile, portfolio, streamory | Tags: , , , | 2 Comments »

For the last couple of months we’ve been working on technology to enable anyone to stream live and pre-recorded video to iPhone, iPad and iPod Touch devices.

Today, we’re pleased to announce Streamory, our in-alpha service which lets users easily stream their own video and audio to the iPhone with only a couple of clicks. Streamory takes the hard work of configuring and setting up a streaming infrastructure, and instead lets you simply upload a video or input stream and, with a single click, publish a stream for use in your site or iPhone / iPad app.

Simple iPhone and iPad media streaming service

You can check our simple web-based demo iPhone app on the Streamory site – make sure you’re using an iPhone or iPad for best experience, though! The demo app demonstrates some different types of output Streamory can generate, as well as adaptive bandwidth streams which give you higher or lower quality content automatically as available bandwidth changes.

We’ve already got some great ideas to make it easy for users to create iPhone-ready video streams without the fuss, but we’d love to hear what you think so get in touch and let us know! :)

We’re not ready for beta testers yet, but if you’d be interested in participating, drop us a line and we’ll get back to you when we’re ready.

Andrew Gleave is the lead developer of iPhone and mobile apps at Red Robot Studios. Considering developing a mobile app? Contact Red Robot Studios to see how we can help.

The Enterprise Ready iPhone

Posted: April 9th, 2010 | Author: Andrew Gleave | Filed under: iphone, mobile, mobile app | No Comments »

Yesterday Apple announced the fourth release of the iPhone OS. There are a lot of changes to the platform but some of the less-discussed improvements are ones which bring ‘enterprise-ready’ features to the iPhone. These features really open up the potential for using iPhone and iPad devices securely in a business context.

With iPhone OS 4, iPhone and iPad now support:

  • SSL VPN Support
  • Multiple MS Exchange Accounts
  • Mobile Device Management Remotely configure, update and wipe devices
  • Data Encryption
  • In-House App Distribution – Distribute and update your enterprise apps to company devices wirelessly

All of these are important features for most medium and large businesses, but being able to remotely update and sync your company iPhones and iPads is a real clincher. The ability for an enterprise to write and deploy its own apps (not distributed with the App Store) to staff devices wirelessly over WiFi or 3G, is the only reliable way of making sure all your devices are up to date: waiting for users to sync with iTunes mean it could takes weeks for all devices to get an update.

Add the ability to encrypt user data, access your network securely though a VPN and remotely manage and wipe devices, and you’ve got a pretty good case for building mobile apps which help you to do business, and that don’t give the Sys Admins a security and management headache.

I’ve only had a cursory look over the new SDK but the thing which stands out is that it really feels like a mature platform: there aren’t as many missing or restricted APIs and many of them have been massively expanded. This release will give rise to a whole host of apps just not possible before.

I can’t wait to take a closer look at the SDK in the next couple of days!

HTTP Live Streaming for the iPhone

Posted: March 17th, 2010 | Author: Andrew Gleave | Filed under: iphone, mobile | Tags: , , , | 1 Comment »

There are many types of live streaming technology, some with wider adoption than others. Currently, the most widely used platform for streaming media is Adobe’s Flash technology, and is what sites like YouTube, BBC iPlayer and use to stream their video content.

However, to watch the stream you need to have Flash Player installed. This isn’t a problem for typical computers – approx. 90% of all computers already have Flash installed – but if you’re an iPhone user, you’re out in the cold. Apple have been very public in their criticism of Flash, and some well-known Apple fans have claimed that it is the “leading source of application crashes on Mac OS X”.

Whether on not this is the case is beside the point, but what is interesting is the technology Apple have developed as an alternative to Flash streaming, for both the iPhone and, more generally, the web as a whole. Not only is it built on existing and well-established protocols and technology, it’s a proposed standard and headed off to the IETF for approval. The best bit of all: it’s very simple.

The technology is called HTTP Live Steaming and is fundamentally very straightforward to deploy. There’s no special / expensive kit required to deploy the stream, and instead uses standard web servers with minor modifications.

Key differences:

  • No streaming software required.
  • No extra ports have to be opened on your firewall as they do for RTSP / RTP.
  • Clients can make use of standard HTTP constructs like caching, load-balancing and expiry headers to optimise delivery to clients.
  • Only needs a standard web server. No extra modules necessary: just add the mime types to your config and you’re done.
  • Clients can dynamically switch between streams of different quality depending on available bandwidth. If you’re on a WiFi network you can be watching a HD-quaity video stream; move to the garden (and 3G) and it can automatically switch to a lower quality stream with no interruption.
  • Can support both live and VOD (Video on Demand) streams.
  • The stream can be encrypted. Therefore, you don’t need access restrictions on the content itself. An authorised client is served a key which enables it to decrypt the stream on the fly. If someone gets hold of the stream but don’t have a key, it’s totally useless.

For the iPhone, or any other mobile device, this is all a great win: you can be on the move, your phone dynamically switching from 3G to EDGE to WiFi as you move around, and your stream will intelligently adapt to give you the best broadcast quality with no drops or stalls. Perfect.

Actually, this is where HTTP live streaming differs from the “progressive download” model where the client incrementally downloads the content as it the stream is being watched: with a progressive download you’re stuck with whatever resolution you chose when you started watching the stream, and if your bandwidth decreases, you stream will stall.

The only real downside is that it’s currently only supported on the iPhone and Mac OS 10.6. However, I can see Apple implementing it in its Windows version of QuickTime and Google implementing it for the Android platform so this shouldn’t be a limitation for long.

Another tangible advantage for this technology is that WebKit has native support for HTTP live streams being used as the source for <video> and <audio> elements. This means you can use live streamed content in your web app as well as in native iPhone applications without the need for any external plugin.

This all adds up to a pretty attractive package, with minimum fuss on both the client and server sides.

Get in touch to find out how we can help you stream audio and video to your iPhone app.

Web or Native: Mobile Application Decisions

Posted: February 20th, 2010 | Author: Andrew Gleave | Filed under: mobile | Tags: , , | 4 Comments »

Since the debut of the iPhone in 2007, mobile computing has really taken off and we’re now at the start of a trend which will shape the future of computing, and one that will likely have a greater effect on people’s day-to-day lives than the internet experience of today.

Mobile phones have had the ability to use the internet in a primitive way for 15 years or so, but it wasn’t until Apple released the iPhone SDK in 2008 and the subsequent development frenzy that ensued, that the surge in mobile internet use really began.

Today’s smartphones transcend simply retrieving email, sending SMSs and making calls and instead enable users to transform their phone in to whatever they want: a gaming machine, a sat nav, or a sleep cycle alarm clock; all with the download of an application. This shift has fundamentally altered the way consumers think about what a phone is and how they use it, so much so, that often its function as a phone becomes secondary.

The current darling of this revolution is Apple’s iPhone which currently has about 140,000 applications on its App Store, and with over 3 billion downloads is easily the most developed marketplace for mobile applications. In fact, stats gathered at the end of 2009 showed Apple captured 99.4% of the mobile application market!

Apple aren’t the only ones driving this push in to mobile application use. Google, Nokia, Palm, RIM (with their Blackberry) and  Microsoft all have their own platform, all offering similar features, but all mostly incompatible.

So with apps being a hot (and potentially lucrative) market and a number of competing platforms to choose from, how do you go about developing and deploying mobile applications?

It boils down to two choices:

  • A native application – A native application is one which is installed and runs on the device and is developed using the device’s SDK. Native applications only run on one platform so you need to develop a different application for each platform. Once built, the app can be sold on its respective marketplace such as the App Store, Android Marketplace or Nokia’s Ovi store.
  • A mobile web app – A mobile app is a web-based application which runs in the browser of the device. There’s no special deployment necessary, it only requires a browser to use it. The goal is to build a web app which is usable by most, if not all, of the different types of device. However, in practice this isn’t particularity easy – yet.

Actually, if you just require a mobile version of your site, you have the option of doing nothing and hoping that your site is useable enough as it is for users browsing on their mobile device. This depends on how your site was built and the browser which is being used, so there could be a large number of users who may get a less than ideal experience.

Both web and native apps have their pros and cons and the choice often comes down to what you want the app to do, and what your users will expect.

Going Native

The Apple's App Store and Google's Android Marketplace are two of a number of outlets for native applications

Developing a native application will provide benefits in its performance and tight integration with all the device’s features and APIs. A native application will give your users the best experience by taking full advantage of the full capabilities of the device.

Advantages like :

  • They can use all of the device’s features such as its camera, GPS, compass, file system etc.
  • They can be sold through a marketplace such as the App Store or Android Marketplace
  • They have superior performance compared with a typical web app
  • Don’t necessarily need to be connected to a 3G or WiFi network to function *
  • They’re not running in a browser so there’s no restriction on the types of application that can be developed

*Improvements brought in with HTML5 will help web apps in some respect

Because a native app isn’t restricted to running in a browser they can do some pretty intensive things such as an augmented reality app to show you a data overlay on top of live video or full full 3D games. Neither of which would currently be possible with a web app.

But there are downsides, too:

  • Typically higher development cost and longer lead time.
  • Very little portability across platform – if you want your app to run on both the iPhone and Android it means building two separate versions.

So if you want to do anything that takes full advantage of a device’s capabilities, or do anything custom or unique, you’re likely looking at a native app. However, the issue of building and deploying to many different devices mean the overall cost can be high.

And this is where web-apps can really start to look like a great alternative: A web-based app should be able to run on any device with a browser, right?

Well, sort of.

The Mobile Web

Everything which you interact with on the internet (except the most basic of web pages) is a web app in one form or another: Facebook, Twitter, Flickr, your favourite blog – all in a broad sense are web apps.

The major advantage of web apps are that they can be used wherever you are, from any computer, via almost any browser. No downloading, no software updates and no uninstalling – just open a browser window, type the URL and hit Enter. Add that to fact that all devices have a web browser means that you have a potentially large number of users who are already familiar with how to get to and use your app.

However web development for mobile devices is still developing and it can be difficult to do things which would be straightforward in a native application. John Gruber has a great article on building iPhone Web Apps as an Alternative to the App Store which covers the topic nicely.

Even though currently it’s not possible to build a web app that will do everything a native app does, for some situations a mobile app is perfect. There’s some great work going in with jQTouch which is a tool that makes it easier to build  mobile web apps for both the iPhone and Android, that look and feel more like a native application. There’s also PhoneGap, which enables a web app to be packaged up and deployed as a native application for the iPhone, Blackberry and Android and sold on their respective marketplace / store.

With these types of tools emerging, and the devices themselves becoming more powerful, it’s not long before web apps become the choice for a larger proportion of mobile applications. The fact that Apple (iPhone), Google (Android), Palm (Pre), Nokia and just announced RIM (Blackberry) are all backing the open source WebKit engine to power their web browsers, it’s a major step in getting a consistent experience across multiple devices. Knowing that an app will look and perform the same manner on all these devices is the Holy Grail of web development: write once, run anywhere.

The Webkit browser engine which powers a lot of modern smartphone browsers

Add to this HTML5 and the rapid development of browser technology and we’re closely approaching the point where we can use standard web technologies to build advanced mobile applications. In the next couple of years most, if not all, mobile platforms will have support for the following advanced features all of which will drasticly change both what web apps are capable of and what users will expect from them:

  • Pure web-based 3D graphics via WebGL – enabling 3D games and modelling
  • Standardised 2D graphics and animation – slick animation and graphics are trademarks of native applications’ rich interfaces
  • Standardised video and audio support – no more plugins to watch movies or listen to streaming music
  • Communication improvements
  • Geolocation support – enable the browser to access your location
  • Local storage and SQL databases – meaning data can be stored within the web application itself so you don’t always require an internet connection to use it. Google Apps provide this features already using Google Gears.
  • Manifests and offline resource caching – movies and photos are still accessible even if you go offline

The future is looking bright for mobile web app development, and as the tools and browser technology get better, development will shift from native to web-based applications. The overall trend is that the “Internet is the platform” that all applications rely on – and not just the mobile ones.

“…development for a platform is a distraction. It’s taking our eyes off the ball, and ignoring the bigger shift that’s happening beneath our feet.”

Chris MessinaReferring to the fact that we should be developing for the web rather than for a single platform.

These types of device and the market for mobile applications in general is still young and it’s going to take a while for the game to play out. Native mobile applications, with their superior performance, slickness and better capabilities are going to be the choice for demanding or cutting edge applications – at least for the forseable future – but one thing you can bank on is that the web isn’t going anywhere. The web is the inevitable platform, and that means that we’ll see huge growth in web-based apps in the coming years.

Andrew Gleave is the lead developer of iPhone and mobile apps at Red Robot Studios. Considering developing a mobile app? Contact Red Robot Studios to see how we can help.

Even Easier Job Boards

Posted: June 9th, 2009 | Author: Andrew Gleave | Filed under: Easy Job Boards | Comments Off

Easy Job Boards, our simple–to-use hosted job board application, has just been updated and we’ve completely removed the requirement that you create an account before you are able to create a job board.

We wanted to make it as simple as possible for people to create a job board, and that means doing something about the need for you to already have an account before being able to try out the service.

We considered integrating OpenID with our registration system – which we may implement at some point – but decided that it would be far nicer if we could do away with the user having to provide any details at all.

You can now just go straight to the create a job board page, give your board a name, and that’s it – your own job board created in record time, and you haven’t even needed to give your email address!

If you decide that you want to give your job board a proper spin and publish your board and its jobs live on the internet, you can then create an account and start a 14-day free trial.

Hopefully, by leaving the requirement to register until the last moment, it helps newcomers get a feel for their job board quickly, and with minimum fuss.

Easy Job Boards: Now with themes, colours and roles

Posted: March 26th, 2009 | Author: Andrew Gleave | Filed under: Easy Job Boards | Comments Off

We have just released the first major update to Easy Job Boards since its launch and have introduced a number of requested features:

  • Custom Themes and Styles and user-defined job roles – Enabling users to choose custom colours and themes for their board and to add custom job roles so jobs can be categorized for easy browsing and filtering.
  • Custom domain support – You can now specify a custom domain for a job board so if you own, you can now run a job board directly from that address. Or, if you already have a company website, you can use a jobs subdomain like

To keep up to date with the changes and improvements we’re making to Easy Job Boards, check out the Easy Job Boards blog.

Djangogigs and Red Robot Studios

Posted: January 26th, 2009 | Author: Andrew Gleave | Filed under: Djangogigs | Comments Off

Djangogigs is the primary job board for developers who use the Django web development framework and are looking for freelance or permanent work.

It was launched in September 2007 and was designed to give employers and developers a central location to list and respond to job listings, and quickly became popular within the Django community.

Since then, we’ve had about 550 gigs and nearly 800 developers submitted to the site. And even during the downturn in the job market, we’re still getting a similar number of gig submissions as last year – good news for django developers.

Since Scott and I formed Red Robot Studios last year, we wanted to take Djangogigs under the Red Robot Studios banner and take some time to add long-awaited features. Between setting up the company and releasing easyjobboards, this is the first chance we’ve had to dedicate some time to djangogigs and add some much-requested features. This is only the tip of the iceberg and we want to grow and improve the site to help fulfil the community’s needs and make it more useful to all.

New Features

  • Gigs can now be edited and removed
  • We’ve given the interface a refreshed and made it clearer and more consistent
  • You can now use Markdown syntax to structure gig and developer descriptions
  • Added dynamic address and location lookup by integrating with Google maps
  • Lots of internal improvements to how gigs and developers are approved and managed

We’ve also moved to a faster server and added a feedback widget to help and encourage people to get in touch.

Since we’ve integrated with the Google Maps API, the location details of gigs and developers is now in a common format which will allow us to split, cluster, map and filter listings, making it easier to find what you’re looking for. For example, we will be able to provide fine-grain control: just jobs in San Francisco, and conversely filter by continent or country.

We’ve only added initial support for this (at the country level), but we’d love to hear what you would find useful.

We have lots planned for the future, and intend to integrate parts of our easy-to-use job board application in to djangogigs in the future.

We’d especially like to hear your feedback as to what you think needs to be improved upon to make the site more useful to both developers and employers.

You can send all feedback, issues or suggestions to us at our support page along with anything else you’d like us to address.

Thanks for your support.

Andrew and Scott
The guys from Red Robot Studios

Versioned Media and Expires Headers in Django

Posted: December 18th, 2008 | Author: Andrew Gleave | Filed under: Django | 2 Comments »

We try to make our sites as responsive as possible, and as part of our testing, we realised that we should do the right thing and add Expires Headers to our static media. Our web servers are configured so when a client requests an image, stylesheet or JavaScript file, it is returned along with a far-future expires header. This tells the client not to ask for that file again, but to cache it for a month or more.

Encouraging Caching with Expires Headers

Without an expires header, the client will request media files each time it loads a page. Using if-modified-since and etag headers, the server usually doesn’t return the media files, but instead returns a 304 Not Modified response. Not resending the data is good. Not having to deal with the request at all is even better – that’s what expires headers offer.

Of course, if you tell clients not to request your stylesheet again for a month, what happens when you change your stylesheet? The client won’t know and won’t get the changes. That’s pretty disastrous. What we need is a way of changing the URL when our media changes so that clients will pick up the new version.

Changing URLs when Content Changes

There are a number of ways to serve your media so you can specify far-future dates in the expires header, but still have the client pick up new versions. We refer to this as versioned media.

One common scheme is to put the modification date of the file in its URL. When the file date changes, the URL changes and clients request the new version. The URL might look something like /media/main.css?200812180930 or /media/main-2008-12-18-0930.css. The former is easier because the querystring is ignored by the web server and the file returned as normal.

Using the date is good if you want more granular per-file versioning, but it seems a little messy. We decided to use a version number in the URL instead, e.g. /media/v123/main.css. To make this work we need to put a version number in the templates and have our web server ignore the version number and just serve the file.

Versioned Media Context Processor

Typically, Django-based sites use the MEDIA_URL context processor to include external resources such as Javascript and images in to their templates. We expanded on this idea by having VERSIONED_MEDIA_URL which puts the version number in as well.

Remembering to update a version number would be error prone, so we wanted to transparently support any updates to media. We use Subversion for version control, and figured out that we could use the versioning metadata of our media directory to help us generate a unique path, which would change as the media was updated. That’s exactly what we needed, and would allow us to specify expires headers on all paths which include a version number but still ensure that users would receive new copies of files if any changed.

from django.utils.version import get_svn_revision
from django.conf import settings


def get_versioned_media_url():
    if hasattr(settings, 'MEDIA_VERSION') and settings.MEDIA_VERSION is not None:
       version = 'v%s' % settings.MEDIA_VERSION
        revision = get_svn_revision(settings.MEDIA_ROOT)
        version = revision.replace('SVN-', 'v')
    return u'%s%s/' % (settings.MEDIA_URL, version)

def versioned_media(request):
    """Adds versioned media url to the context."""
        VERSIONED_MEDIA_URL = get_versioned_media_url()

You can see from the code that we’ve added a MEDIA_VERSION setting which is either manually set, or can be set by a deployment script. We make use of django’s get_svn_revision method to pick up the version number from our MEDIA_ROOT and we then append our version number to our MEDIA_URL, adding it to context as VERSIONED_MEDIA_URL.

It’s convenient to update code on your server with a simple svn up, but serving from a working copy may have security issues. Instead, we have a deployment script which updates a working copy then copies the files (excluding .svn directories) to the directories used by the web server. It finds the revision number and writes that to the settings file so our version number is still updated automatically.

Configuring Expires Headers in Nginx

Now that we have a version-specifc URL for all our media, we need to configure the webserver to add an Expires Header to any requests which are destined for a versioned URL. We use Nginx, but the theory applies to any webserver.

location /versioned-media {
    expires 90d;
    alias   /srv/www/live/thebarbershop/site/media;

location /media {
    rewrite /v(?:\d+)/(.*) /versioned-media/$1;
    rewrite /vunknown/(.*) /media/$1;
    root   /srv/www/live/thebarbershop/site;

We configure our /media URL so that any request which matches the version string created by our context processor is forwarded to the /versioned-media path, which then applies the expires header and sets the expiry date to 90 days in the future. Any request path without a version number simply gets served without the expires header.

One drawback: committing a change means that all versioned media URLs change, not just the one for the file that changed. However, we feel this is only a small drawback given the advantages this gives for the common case of a high-traffic site with relatively infrequent changes to the base media.

When you couple adding Expires Headers with other techniques like:

you can dramatically reduce both the number and size of requests to your application, and give users a more responsive experience.

Getting Satisfaction from Red Robot Studios

Posted: December 2nd, 2008 | Author: Andrew Gleave | Filed under: Ethos | Comments Off

When we started Red Robot Studios earlier this year, we had a couple of guiding principles we wanted to make our core philosophy:

  1. Build great software
  2. Keep everything simple until we know what to make complex
  3. Let customers and the community guide the direction of the company and its products

With these principles in mind we built our first application Fuselagejobs which is based, in part, on work we did for Djangogigs last year. Fuselagejobs is comfortably lightweight at the moment and performs its core function of managing jobs listings pretty well. However, we’re very much aware that users will want more features and functionality as time goes on. Hence, the need for us to keep in touch with the community’s wants and needs.

I’ll admit it now: we’re not psychic. As we work on products for Red Robot Studios, we can’t know for sure what features people want or expect. The best we can do is to make something we think is good, and ask you for your feedback so we can learn what we did right and what we need to become better at.

So, we’ve started using Get Satisfaction as a way to gather feedback and keep in touch with our customers and the wider community. We hope to get ideas and suggestions as well as address any problems or grievances, and build products which you the community help to direct.

It’s all done “in the open” so we can be transparent and approachable instead of some faceless corporation hiding behind a website.

We will be writing frequently on our blog, and you’re more than welcome to follow us on Twitter too (Andrew and Scott).

So, if you’ve got anything you’d like to discuss, we’d love to hear from you.

Looking for a job board? Try Fuselagejobs.