nick.recoil.org

I use git, and from time to time I use the ‘stash’ feature. This is a boon when performing certain tasks, but can also get you into trouble if you don’t carefully manage what you’ve stashed. To this end, I modified my bash shell prompt to help me remember.

Normally my shell prompt gives me fairly standard information. Current working directory, time, hostname and current user.

[nick@20:47:31] dusk : ~/Work
$ 

When I’m inside a git repository, I see something like this.

[nick@20:47:31] dusk : ~/Work/git/MacRuby (master) [2]
$ 

The bracketed ‘master’ shows me what branch I have checked out, and the red ’2′ shows me that I have two stashed change-sets. This is accomplished by the following bashrc/profile code:

function parse_git_branch {
  ref=$(git symbolic-ref HEAD 2> /dev/null) || return
  echo "("${ref#refs/heads/}")"
}
 
function parse_git_stash_size {
  lines=$(git stash list -n 100 2> /dev/null) || return
  if [ "${#lines}" -gt 0 ]
  then
    count=$(echo "$lines" | wc -l | sed 's/^[ \t]*//') # strip tabs
    echo "["${count#}"]"
  fi
}
 
export PS1="[$red\u$NC@$green\t$NC] \h : $cyan\w $yellow\$(parse_git_branch) $RED\$(parse_git_stash_size)\n$NC\$ "

This has been invaluable in helping me keep track of what I’m working on, and helps me make fewer mistakes when managing git repositories.

We’ve started using Rackspace’s CloudSites at BERG, and one of the problems we’ve been tackling is how to make deployment a painless process. Uploading to CloudSites is only allowed by FTP/SFTP, and is very slow at times, so we wanted to use a “maintenance” mode approach that is common in the Rails and Capistrano world.

CloudSites has some very customised Apache configuration, and we found that the standard mod_rewrite approach didn’t work. There was no mention of a solution within their support wiki, so for anyone else looking for a similar solution, I’m placing ours here:

RewriteEngine on
RewriteBase /
RewriteCond %{ENV:PHP_DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{REQUEST_FILENAME} !/maintenance.html
RewriteRule ^.*$    /maintenance.html [L]

We found that when checking the DOCUMENT_ROOT environment variable, it didn’t get the correct path to test for the presence of the maintenance.html file, but using ENV:PHP_DOCUMENT_ROOT, it did.

In the last few months, I’ve made time to migrate some old RubyCocoa code to the latest and greatest version of MacRuby. Not only did I see a huge performance increase across the board, I found I could also create a stand-alone binary which could easily be distributed to end users. The entire framework is fast becoming a first class citizen on Mac OS X.

It was during the porting process that I ran into a small issue when attempting to read ID3 tags from mp3 files. I’d previously used the native Ruby gem ruby-mp3info, but this had some compatibility issues with MacRuby 0.6, and refused to install. After hacking around with the gem source, I worked around the issues, but the resulting performance was awful, so I reviewed my choices:

1. Investigate the cause of the performance problems in ruby-mp3info
2. Switch to using id3lib-ruby
3. Investigate bundles and use a C/C++ library directly

I didn’t sink a lot of time into fixing ruby-mp3info’s specific problems on what is still a relatively niche platform, and I felt that using id3lib-ruby would complicate my ability to create standalone binaries. id3lib-ruby is so named because it depends on the libid3 C++ library, which would introduce another layer of complexity into the build process. Lastly, the id3lib gem didn’t support the latest version of ID3 tags, and wasn’t under active development.

That left the last option, which I had always wanted a good excuse to investigate. I had originally looked into this when I originally started looking at RubyCocoa in Summer ’09, but linking with native Objective-C seemed excessively difficult and poorly-documented.

One of the many improvements that the MacRuby project brought over RubyCocoa was to make this functionality as easy as loading bundles in native Objective-C applications. This is achieved with use of the NSBundle class, so I thought all I needed to do was to take a C or C++ ID3 library, and wrap it in a very small Objective-C wrapper. Through the magic of runtime introspection, all of the wrapper’s methods would become available when you loaded the bundle into the MacRuby environment.

After reading up on existing tutorials, I managed to get this to work, and because it’s using the native compiled code, it’s extremely fast. This process of using interpreted Ruby code with compiled C/C++/Objective-C code is tremendously powerful, and allows for a mix and match approach to development that enables both rapid prototyping, and an ability to optimise for performance, from within a single codebase.

So powerful is this technique that I wanted to write up my experiences for others, who like myself, had maybe had just enough experience with Ruby (through Rails) and iOS development to feel that merging them together might be fun. With Mac OS X as my primary desktop environment, I’ve now achieved a triumvirate of control:

1. I can write web-based code that lives in the cloud and is available from anywhere in the world.
2. I can write mobile applications that I can carry with me at all times.
3. I can write larger, more flexible and powerful applications when a desktop environment is appropriate.

I can remember buying my first Powerbook back in 2002 and getting the distinct feeling that Mac OS X had successfully channeled all of the potential energy that the original NeXTSTEP had so successfully created. That this was a futuristic platform that eagerly awaited the craftsman’s touch. Something that could be deftly moulded it into whatever shape you could conceive, if only you invested a little time in the tools.

Eight years on, the choice has grown richer. MacRuby occupies a unique place within the spectrum of development tools on the Mac, offering a high level ease in harnessing low level power. If you haven’t looked at it yet, I can recommend a good tutorial.

Since November 2009, I have been working with the talented people at BERG London on a variety of projects, two of which I want to mention in more detail here.

Michel Thomas on the iPhone

The first project was the Michel Thomas iPhone app. This is one of the most well-rounded apps I’ve implemented, and proves that you don’t need a large team in order to produce an intricate and attractive application. BERG’s supremely talented designer, Matt Brown, designed the visuals, and I worked on the iOS implementation. Between us we came up with a product we’re both very proud of, and it’s now the flagship mobile application of Hodder Education.

Since its launch, the Learn a language with Michel Thomas application has been steadily gathering interest, and It has recently taken the top spot in the Free Education category of the App Store, both in the UK, and in the USA and Australia.

There are more details of the design process in the “Behind the scenes” post that Matt Brown wrote up for the BERG Blog, and a comprehensive Flickr image set of the sketches we created during the design and development process.

In my view, one of the standout feature is the playfulness we worked into the interactive audio player. We went through a number of design iterations, many of which were discarded because the technical implementation didn’t capture the feeling of the original design sketches. Our final design struck a great balance between gorgeous design and the constraints of the real-time rendering power on iOS devices.

At the height of the work on the audio playback, I listened to the same phrases so many times that Michel Thomas percolated through into my subconscious. At one stage, during a particularly intense week of work, he took a starring role in a dream, chatting up girls at a party in his uniquely accented Spanish!

Popular Science+ for the iPad

The second application we worked on was Popular Science+ for the iPad. BERG had previously worked with Swedish publisher Bonnier in late 2009 on an exploration of the future of digital magazines. Very shortly after the Mag+ video had been released, Apple announced the existence of the iPad, and Bonnier, along with BERG, were invited to create the magazine experience that had been conceptualised in the earlier work.

The challenge of bringing Mag+ into the world in only 8 weeks made it an extremely ambitious project, which took a great deal of concentrated effort from many people across numerous timezones (London, Sweden and Florida, USA). Thankfully I was joined by another developer, Lei Bramley, who really pulled out all the stops to get everything in place on time.

After a fevered period of development, we submitted the first version of Popular Science+ to the App Store for the launch of the iPad, and Steve Jobs himself had very nice things to say about our work:

Somebody snapped this picture of the street-level advertising of Popular Science+ while out and about in Manhattan:

The sheer ambition and timescale of the project saw everyone involved in the project raise their game, and it was a fantastic experience to have been part of the iPad product launch.

Mill Colour

Lastly, a small update concerning Mill Colour. What began as a small project to give people a taste of professional colour grading, has gone on to be a big success worldwide. It has been downloaded over half a million times to date.

Viva Mill Colour!

Over the past few months I’ve been working on developing professional iPhone and iPod Touch applications with a number of clients, and I wanted to mention the first one, which has had a great 6 week run at the top of the free photography apps chart.

My very first public iPhone project has been Mill Colour, for world-renowned visual effects company The Mill. The idea behind this app is to offer users a means of  manipulating their pictures in a simple way, with built-in looks. It also offers the more adventurous user direct control over the Lift, Gamma, Gain and Saturation in their picture. These controls are the same as the Colourists at The Mill would use when colour grading video footage.

An important feature of this app was to offer users a learning curve suitable to the immediacy of mobile applications. Our goal was for the user to be able to see results within roughly 30 seconds of launching, but to offer additional controls which extend the learning curve, and offer a deeper experience for those who want to invest time. To achieve this, the simple built-in looks and the more direct controls interact with each other, offering a large combinatorial set of possible ways to alter the image.

Another interesting aspect of the project was the toolset I specifically built to capture the lookup tables for the looks. Each of the looks available within the app is based on a famous advert that The Mill have graded. To capture these looks, I wrote a program which would read and write the colour values from RGB ‘ramp’ images. This allowed the Colourists to apply the same colour transform to the ramp image as they had done to the original source image. The tools then read this image back in and created a lookup table which could be applied to any image. This saved us a great deal of time in the early stages of the development process.

It has an active Flickr group, and by adding pictures to the pool, you can get entered into a competition to win time at The Mill, and get taught directly by their award-winning Colourists.

There are more applications in the pipeline, and I’ll post about them closer to the release date.