thewebfellas - ruby on rails development specialists uk

When the default session store for Rails was changed to use cookies last year it caused quite a furore: "It’s not secret! It’s not safe!" The truth is it was never meant to be: in most circumstances you shouldn’t really be storing data in cookies that need to be protected so strongly. But I don’t really want to re-open that can of worms! Instead I want to look at a different cookie-related situation that arose during some optimisation work I’ve been doing on an existing Rails application.

The scenario is straightforward enough: the application stores a numeric record ID in a persistent cookie that, while perfectly safe to be seen by users, shouldn’t be changed by them. The solution currently used in the application is equally straightforward: the data is encrypted (using the EzCryto gem and AES encryption) before being written to the cookie, and then decrypted when the data is read back in.

In situations where cookie contents really shouldn’t be seen by users then encryption is the way to go (unless of course you can find a way of not using a cookie at all), however for a simple numeric ID where tampering is the only thing we need to protect against then it seems like overkill. A better solution is to take inspiration from the Rails cookie session store and use a HMAC.

Rails 2.1 has just been out a week and so far something that seems to have passed most people by is that it now includes much better caching capabilities, including built-in support for memcached.

Last week I reached the point with an application where I needed to cache some models in memory to get a performance boost and decided to check out the current status of plugins like cache_fu and CachedModel to make sure they’d work with Rails 2.1. It was completely by accident that I stumbled across this innocent looking commit by DHH from start of this year and realised that Rails already had everything I needed!

Ok, so I’m starting a new Rails application, I’ve spent some time refining my database, I’ve considered storage requirements and performance when choosing the data types for my fields and now I’m ready to create some migrations to implement my design.

And then I’m reminded that, lovely though Rails migrations are, there are two things that really bug me about them: they create signed primary keys and they don’t allow me to easily create unsigned integer columns.

It’s been discussed before, dismissed as an ‘uncommon requirement’ (probably because MySQL is, as far as I know, the only database that uses unsigned integers) and, as far as I can tell, not a lot more has happened. So, while sat out in the garden, enjoying a sunny Saturday afternoon, I grabbed edge Rails from GitHub and decided I’d see if I could do something about it (how’s that for geekyness?!)

Following on from Rob's Rails plugin round-up a few months back then another plugin has repeatedly found it's way into our projects - sql_logging.

The default Rails behaviour for highlighting form fields with errors is to wrap them in a div, so:

<div>
  <%= f.label(:email) %>
  <%= f.text_field(:email, :size => '30') %>
</div>

Becomes:

<div>
  <div class="fieldWithErrors"><label for="user_email">Email</label></div>
  <div class="fieldWithErrors"><input id="user_email" name="user[email]" size="30" type="text" value="" /></div>
</div>

This is great when knocking together a quick prototype but as your site evolves you’ll probably want to customise it. This can be done very easily by using ActionView::Base.field_error_proc, assign a Proc to it either in your environment.rb or, if you’re a modern thinker, in an initializer and you’re good to go.

Good news - persistent storage for EC2 is on it's way - it's already in private beta and will be 'publicly available later this year'.

About a month ago Gregory Brown created a buzz with his blog post about working on open source projects for money. Gregory opens with a "Here’s a crazy idea" - but then outlined an idea that was pretty fresh, and not crazy at all (in my book!). This evolved into a wiki around the subject - an interesting read.

As is usual, it created a lot of discussion on blog sites and also fed into talks of a similar nature that had been happening at TheWebFellas HQ.

We're currently working on a project where we handle a lot of images and videos. Rather than handle these ourselves, we wanted to make use of the heavyweight's infrastructure where possible - this meant Flickr for images and YouTube for video.. but there was one snag - we couldn't upload video via the API. There were 'hacks' available, but we don't like to build solutions on unsupported features.