Archive | Development

Golden Hour comes to iPhone

Golden Hour comes to iPhone

Mindsizzlers have released their latest iPhone application. The Golden Hour app’ puts a sun clock in your pocket and allows you to plot the position of the sun for any location on earth and time of year. Of particular interest to photographers, the application highlights the so-called “Golden Hour” much appreciated by cinematographers and photographers alike.

Featuring a comprehensive database of over 45,000 locations around the world, accurate astronomical calculations and different views of the data, both graphical and numeric, the application is designed to accompany and augment the existing website at

Full Features;

Next event alert for the current location.

Sun clock display showing not simply the day-night terminator, but a coloured shadow highlighting the areas of the planet currently in golden hour, civil twilight, nautical twilight etc. Click on the map to instantly change locations.

Sun Angle display showing the Azimuth and Elevation for any time on the current day.

Golden Hour display, familiar to website users this is the core display of the solar altitude during the day. Users can scroll through the year or nudge the current date up/down with a tap. From this screen users can also access a comprehensive numeric data view showing the full range of astronomical,nautical and civil twilight times.

Huge drill down location database complete with full colour flags of the world for each country and population data for each city, town or village.

Particularly noteworthy is that the application does not require any network access and is therefore perfect for iPod touch users.

Posted in Featured, iPhone Development, News, Products0 Comments

Note to Jonathan Ive…

We’re quite excited about the launch of the iPad. Yes it’s the subject of much controversy (isn’t it just a tablet PC nearly 10 years on from Microsoft’s first announcement? Is it a computer or an oversized phone? Won’t it be useless without a keyboard? …and many are uncomfortable with its closed software model), but for me it’s exciting because it looks set to take this form to a wider market than ever before. What’s the point of the iPad? I can’t tell you right now, but by creating a broad market, the market will define its purpose, and in turn will spur innovation across portable computing. The iPad may not be obvious today, but I am willing to bet it will have a significant impact on the PC market over the next decade.

Jonathan Ive is the darling of the product design world – he is credited with a host of innovative designs that have characterised the Mac world from the late 1990′s, including the iMac, iPod, iPhone and now iPad. For a designer to have created one of these ranges of technology would be an achievement, but to be able to wow the world time after time requires genius! Product design is all about solving problems that the end user never even knew existed; Ive does that so magnificently that he wraps his solutions in forms that are also highly desired.

I like the iPhone, it’s a great device, but there’s a design flaw that bothers me, and from the pictures released of the iPad to date, it looks as if it is about to be repeated! I’m going to call it the ‘orthogonal interface transform paradox’ partly because that sounds grand, but also because the flaw is difficult to summarise briefly! Maybe the problem has been identified before and described elsewhere – I’d be interested to hear comments from product designers who might know? It’s not peculiar to the iPhone, but this is how it manifests itself on this device…

Volume on the iPhone is controlled with a ‘volume rocker’ situated on the top left of the device as you hold it upright. Press the top to increase volume, and the bottom to decrease volume. So far, so good: up is louder, down is quieter – and that’s what common sense dictates. One of the neat things about the iPhone is it’s ability to detect which direction the interface is oriented – rotate the phone sideways and in some applications, the display rotates with you.

The natural orientation for video playback on the iPhone is in a landscape mode. In iTunes you can rotate either clockwise or anti-clockwise and the video player rights itself accordingly. On other applications that play video, the natural orientation requires an anti-clockwise twist to view correctly. Unfortunately, an anti-clockwise transformation now sees the volume rocker working paradoxically – now you have to press left to go louder and right to reduce volume. The onscreen volume control works as you would expect – drag right for loud and left for quiet. Suddenly there are two volume controls available to the user, but ‘loud’ and ‘quiet’ operate in opposite directions on each.

As I mentioned, this isn’t the first technical device to suffer the ‘orthogonal interface transform paradox’. The paradox arises because a fixed physical interface doesn’t adjust to a dynamic display of information. I first noticed this with television remote controls. TV remotes have a channel rocker – press the top to go up a channel, and the bottom to go down. If they don’t have a single ‘rocker’ button, they will have two separate ones to navigate up and down through channels. If you are watching BBC1 and wish to navigate to Channel 5, you simply press ‘Channel Up’ four times. To flick back to ITV1, click ‘Channel Down’ twice. That seems pretty logical – BBC1 – UP – BBC2 – UP – ITV1 – UP – Channel 4 and so on… However, bring up the onscreen channel guide, and channels are listed with BBC1 at the top. Place the TV pointer on BBC1 and in order to get to Channel 4 you now have to press ‘Channel DOWN’: BBC1 – DOWN – BBC2 – DOWN – ITV1 – DOWN – Channel 4. The interface is completely reversed.

This isn’t a hugely serious issue, it’s unlikely that it’s led to loss of life, but it is a problem that product designers should look to solving in order to give a consistent interface experience. Furthermore, should such flaws ever be resolved, then we will all forget that they ever existed. As you can see, there’s little ‘thanks’ returned to the good product designer – all the problems were resolved before we were ever aware of them and the genius of the likes of Jonathan Ive goes largely unnoticed. Perhaps a future version of iPhone or iPad will switch the behaviour of the volume rocker in software as the device is rotated, then it’ll just be another neat feature designed into the device that is lost on most of the punters!

Posted in iPhone Development, Personal0 Comments

SQLite, Firefox and Vacuuming Databases

As I mentioned in my post on persisting data on iPhone, Firefox uses SQLite under the bonnet for a variety of tasks.  I use Firefox on all platforms and from time to time I find that it gets sluggish.  Unfortunately this is largely down to SQLite.  As with any database, even SQLite needs managing over time, and this is something that Firefox doesn’t seem to do well.

To write data into a row, a database will allocate some space and then write into it.  As a database grows, so this hapens over and over.  Usually a table will have grabbed a volume of space when it was created and initially rows are written sequentially into this block.  When it fills, a new block is added and so on.

To retrieve information, your RDBMS will seek through the records stored in those blocks of data, scanning through record by record, unless of course your data is indexed in which case it can jump much more accurately to the correct location.

When you delete a row of data, the information is dropped from your database, but the space allocated to that row remains in place.  When the database scans through, there is an overhead to recognise that space and jump on to the next location.  Also over time, the blocks of data dedicated to each group of rows in your table get dispersed over your disk.  This all makes for higher overhead when you come to read your data.

Just as most disk drives need the occasional ‘defrag’ run on them, so a database does too.  In PostgreSQL and SQLite this is achieved using the ‘vacuum’ command, simply:-

vacuum myTable;

or just:-


…to defragment the entire database.   MySQL also requires defragmenting but this is done using the ‘optimize’ command.  This process will rewrite your data into a new, sequential block, clearing out any space left by redundant data.  After a vacuum you should see a reduction in the storage space allocated to each table.

Returning to the point of this post, Firefox can get quite tardy if it is not periodically vacuum’d.  To manage this, on Windows and Linux download and install the SQLite command line tool, go to the directory where your profile is stored and then issue the following command (for Linux/Mac):-

for i in *.sqlite; do echo "VACUUM;" | sqlite3 $i ; done

or Windows:

for %i in (*.sqlite) do @echo VACUUM; | sqlite3 %i

Another option is to go into Tools -> Error Console and paste in this line:-


…and click ‘Evaluate’. The interface will freeze for a few seconds while the vacuum is perfomed, then the console will close to signal completion.

A tip for using Firefox on Mac, make sure that you clean your ‘Downloads’ list regularly, letting this list grow can also bring Firefox to a standstill!  You don’t need to move the files, just clear the list from the Downloads window.

If things had become sluggish then hopefully you’ll notice an improvement!  From a development perspective, if you use SQLite in your own projects, make sure you manage the database by issuing the occasional vacuum on it!  Done frequently, a vacuum takes almost no time at all.  Left for a long time, this process can lock up the database for a noticeable time.

Posted in Development, SQL0 Comments

Data Persistance on the iPhone

If you’re writing apps for the iPhone, sooner or later you will want to be able to persist data between sessions. You might want to store hi-scores, preferences, favorites, log metrics or achieve some other task. The iPhone supports three main interfaces for persisting data, ultimately they all write out to disk. In time you will probably find you use all three methods, each one suits different tasks.

Property Lists

Property lists, or plists, offer a way to write a dictionary of data (key – value pairs) out to a file. The native format is XML file, but you don’t need to load the file and parse it, you can simply read the file and de-serialize the information back into objects. To write out, you just create your dictionary object and serialize it to a file. Plists offer a lightweight method to store data and work well when you have a clearly defined set of objects to persist, perfect for hi-scores, favorites and preferences. Read the data in your application delegate in applicationDidFinishLaunching, and write it back out in applicationWillTerminate.

Reading and writing to Plists is pretty trivial. Once your ‘favorites’ data is stored in a dictionary:-

- (void)writeToFavorites: (NSDictionary *) myFavorites
    NSString *path = [[NSBundle mainBundle] bundlePath];
    NSString *filePath = [path stringByAppendingPathComponent:@"favorites.plist"];
    NSMutableDictionary* plistDict = [[NSMutableDictionary alloc]
    [plistDict setValue:myFavorites forKey:@"Favorites"];
    [plistDict writeToFile:filePath atomically: YES];

…and to read it back in again:-

- (NSDictionary *) readFavorites
    NSString *path = [[NSBundle mainBundle] bundlePath];
    NSString *filePath = [path stringByAppendingPathComponent:@"favorites.plist"];
    NSMutableDictionary* plistDict = [[NSMutableDictionary alloc]
    NSDictionary *myFavorites = [plistDict objectForKey:@"Favorites"];
    return myFavorites;

Plists support various data types including strings, numbers, arrays and dictionaries, so they can be used to store complex data structures and best of all, there’s no parsing to do!


For more complex data interactions, nothing beats a good old fashioned database.  SQLite has been available on iPhone since its launch and historically was used in Apple’s core applications.  SQLite is available across platforms and is the workhorse for tasks inside many applications, for example Firefox uses  SQLite for tracking downloads, bookmarks, history and other tasks.

SQLite offers a lightweight SQL interface to your data.  Your application must create tables and write data into them using SQL commands.  As it’s name suggests, SQLite is ‘lite’ – although it offers RDBMS functionality, it has some quirky features when compared to traditional RDBMSs such as Oracle, Microsoft SQL Server, MySQL or PostgreSQL.  For example, most data formats boil down to a string representation, this leads to the dynamic typing capabilities of Perl or PHP!  Binary data can be stored in SQLite databases which means that whole objects can be stored out in much the same way that Plists can store data objects.

Working with SQLite on iPhone requires tools to support being able to view the state of your data as you develop your application.  Because of the app’s sandbox environment, you will need to store your database in the Documents folder inside your app directory.  There are a number of viewers for SQLite databases, I use the SQLite Manager plugin for Firefox which is perfectly adequate. When compiling for iPhone simulator you can drill down into the application directoryand view your database in situ,  To view a database on your iPhone, first you must pull the SQLite file onto your Mac using Xcode’s Organiser.  Download the database to your local disk and then open in the manager.  Be aware that each time you compile your app for Simulator, the app id changes, moving the database location with every run.

In order to use SQLite in your own projects, you must add the framework into your project in Xcode.  Right click on the Frameworks folder in your Xcode project and choose ‘Add existing framework…’.  SQLite is located at:-


Make sure that you select ‘libsqlite3.0.dylib’ as this always points to the latest build of the version 3 framework.

The main SQLite website offers full documentation, learn more there about what SQL features are and are not supported.

Core Data:

This Cocoa framework was made available to iPhone OS 3 and is Apple’s preferred way to persist data.  Under the bonnet, Core Data actually uses either SQLite or Plists to store your data – it makes the choice.  Although this is Apple’s preferred method for persisting data, it may not be yours!

As with SQLite you must add the Core Data framework to your project – this is located with the other Cocoa frameworks.  Use Xcode’s Data Modeller to create your data structure, this is much like creating a SQL database with a GUI tool.  Once you’ve done that, Core Data methods give you a powerful interface to your data.

One good reason to favour SQLite over Core Data is that SQLite is more portable, and if you are looking to migrate your app between iPhone and Android, then you’ll be able to share code more easily.  Core Data does give you some pretty compelling features should you need them – undo capabilities in your app, spell checking and it automatically looks after persisting your data to disk.

- (void)readPlist
    NSString *filePath = @"/System/Library/CoreServices/SystemVersion.plist";
        NSMutableDictionary* plistDict = [[NSMutableDictionary alloc] initWithContentsOfFile:filePath];

        NSString *value;
        value = [plistDict objectForKey:@"ProductVersion"];

        /* You could now call the string "value" from somewhere to return the value of the string in the .plist specified, for the specified key. */

Posted in Development, iPhone Development, Objective-C0 Comments

Why you need to de-fluff your Javascript

I don’t know if it’s the same for you, but in recent times I’m finding that the number of javascript files my projects rely on is growing arms and legs. It’s not uncommon to discover that you’re soon using maybe a dozen jQuery components, the excellent shadowbox plugin (complete with multiple javascript files) and more often than not, some mapping (cue the very handy geoxml project). That’s before we even start with the code we will be writing. Things got so bad on a recent project (23 – yes TWENTY THREE included javascript files) that I decided it really was time to get a grip on things.

The mission was on to a) cut the bandwidth taken up in delivering these files to the users’ browsers b) reduce the number of HTTP requests and thereby improve page loading times and c) potentially help out with SEO by getting content closer to the top of the page.  That last one is a bit of a reach, but it never does any harm for a page to have a higher proportion of real content nearer the top.

The strategy was;

1) Ensure Javascript was being served compressed (g-zip/deflate)

2) Minify / Pack / otherwise compress the source javascript

3) Suture the compressed javascript files together into one large file

1) The starting point was to ensure that Apache was correctly serving javascript in compressed form to compatible browsers.  This can bring dramatic benefits and research shows an average 75% SAVING in bandwidth for html/css and javascript when delivered in compressed form. It’s easy, it’s an instant fix and you really ought to be doing it. Sadly some hosting companies out there still won’t turn on compression for you and use some lame excuse or another – find a better host I say!

2) The next step was to reduce the source file sizes before they are served using various compression techniques. You have probably come across this before – either as minified jQuery files, or perhaps as javascript that has been packed using the dean edwards tool, but because I wanted to script the conversion on my own server, I chose the excellent Javascript::Packer CPAN module by Merten Falk. The nice thing about this module is that I can choose from different sorts of compression – minify and pack being but two of them.

OK so by now we’re making improvements, but not actually addressing the main problem. Our files are much shorter (90% shorter in some cases) having been minified. They are reaching the user faster that before as we have tuned our webserver to deliver the javascript in compresed form, but we still have a huge number of files being downloaded and that means additional HTTP requests and THAT is the real performance killer. Remember, between 40% and 60% of visitors to your site are likely to have an empty cache, so this is a very important issue – in fact it is the most important issue affecting page performance.

So onto;

3) Suture the files together into 1.

And this is where all my problems began.

The site stopped working.  Or at least various bits of it did. I could often control which bits worked by swapping the order of the stitched files and then I twigged that perhaps the minimising or packing was failing in some way and that when the files were all together in one file, this was being highlighted.

And this is the crux of the matter and the point of my post. NOT ALL FILES WILL SURVIVE being minified or packed. The process of removing white space which is inevitably part of the compression process can semantically change the meaning of a poorly written javascript and result in it breaking, despite it running as desired on the target browser.

So what to do … ?

This is what led me to discovering the joys of JSLint, a tool that you can run over your javascript to give it a clean bill of health – or otherwise. Indeed it’s the “or otherwise” most of the time to be honest as the default options are rather strict, but the great thing about JSLint is that it will tell you exactly what coding rules are being broken AND (usually) how to fix them.

After working through all the files and correcting all the faults as reported by JSLint (barring some stylistic ones I chose to ignore), the files are now all minified / packed and correctly sutured together into one large file. The site works as intended and page loading times have been plunged by almost 70% for new visitors on a decent connection.


JSLint might seem a bit pointless at first, all it does is nag you about lots of seemingly petty coding rules, but I would say BEAR WITH IT, learn why it is making the suggestions it is making and if needs be, turn off some of the stricter rules if you can justify why. Your patience will be rewarded as your files will now survive minifying and packing and you will be able to stitch them all together into one large file to dramatically improve your website performance.


Posted in Development, Javascript0 Comments

Mindsizzlers launch first iPhone application!

Mindsizzlers launch first iPhone application!

Following on from our news about the launch of, we’re delighted to announce the release of our first iPhone application which complements the site by tracking users’ walks and giving them access to a special mobile web version of the website.

Written entirely in native objective-c for the iPhone, this is the first of a range of iPhone applications that Mindsizzlers has planned for the coming months, but if you have a project you would like to see realised on the iPhone, please don’t hesitate to get in touch as this is very much a space we are now confident working in.

Launch Screen

Launch Screen

Posted in Development, Featured, iPhone Development, Products0 Comments

Memcached and Clouds

Memcached and Clouds

I’ve been spending a lot of time with Amazon’s cloud database SimpleDB recently and was invited to give a presentation in July on how Memcached and SimpleDB work really well together. We’ve made a copy of the presentation available online and you can view it below. If you want a PDF copy of the presentation, you can order it for free on the same page.

Posted in Cloud Computing, Development, Featured, News, Presentations0 Comments

Boost performance with LibXML

We’re working on a project at the moment that has a lot of XML flying about, for example we wrap data coming out of Amazon SimpleDB in XML and then consume that data in the rest of the program.

I’ve been using XML::XPath to extract the data from the xml, so I can write this sort of thing;

my $xp = XML::XPath->new( xml => $xml );
foreach my $walk ($xp->findnodes('/walks/walk'))
my $walkid = $walk->findvalue('./@itemname');
etc ...

It’s easy to write, easy to read and works well. However recently I’ve begun noticing that the project has become a bit, well, sluggish. I was kind of hoping that XPath would be using the C (and hence very fast) LibXML under the hood since I had recently installed that parser on the system, however the lack of speed led me to think this might not be the case.

Reading around, I discovered that there already is XPath support built in to LibXML and so I was able to rewrite my code as follows;
my $parser = XML::LibXML->new();
my $doc = $parser->parse_string($xml);
my $xp = XML::LibXML::XPathContext->new($doc->documentElement());

foreach my $walk ($xp->findnodes('/walks/walk'))
my $walkid = $walk->findvalue('./@itemname');
etc ...

Note how it is just the setup that has changed, the actual data processing stays the same (in most cases).

This makes things *MUCH* speedier as you would expect. My perception is perhaps as much as 10 times faster for large XML files, but I haven’t done any quantitative analysis.

BEWARE though, it’s not a completely transparent drop-in as the parser in LibXML has some quirks. For example if there is a namespace declared in the xml file, then you will get no data returned unless you correctly attach this to the context.

For example, when writing an Atom parser, note the registerNs line

$PARSER = XML::LibXML->new();
$DOC = $PARSER->parse_string($xml);
$XP = XML::LibXML::XPathContext->new($DOC->documentElement());
$XP->registerNs( xatom => "" );

foreach my $data ($XP->findnodes('//xatom:entry/xatom:content[@type="text/xml"]'))

This despite the fact that inside the atom feed, NO namespace is explicitly used in elements. The atom file contains <entry> and NOT <xatom:entry> but you MUST attach a namespace to be able to read the data. You could choose any namespace, I picked xatom but it could just as well have been fred. Go figure …

Posted in Development0 Comments

KML Parsing

We’re working on a consumer project at the moment that makes heavy use of mapping technologies. We built the project with google maps, but ran into a deal breaker where placemark links in parsed KML always open in a new browser window, rather than the same window that is sometimes preferable.

Google seem to have acknowledged this is an issue, but they acknowledged it 2 years ago and have done nothing since – presumably for their own good reason – however for someone developing tools against the API, it can be a real headache.

Enter the open source community and a great product by Lance Dyas called GeoXMLwhich is a new parser you can use for KML files (and much more) within the Google Maps API. And the BEST feature … well for us, it DOES allow you to open links in placemark info windows in the SAME browser window. Great!

Beware that sadly the project lacks any real documentation and getting started can be rather hard. The documentation for another project EGeoXML is a useful starting point.

Posted in Development0 Comments


For more information about our services…

Contact Us

Wordle of the Day

Image from software at
Data by Web Trends Now