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.

As I previously posted Amazon have announced that persistent storage is on it's way for EC2. Sadly the public launch date has not yet been disclosed - it's "coming later in the year". In the meantime this leaves the question of what to do when you need data to persist?

There are a number of options, especially when you start to consider scalability and fault tolerance. I won't dare claim I've considered all the options out there - I've simply started to look at what the immediate options are for persistent storage.

Without further ado, then, on to the technology. I've found a number of choices - rather than this being a 'how to' then it is more about the solutions I have found so far and that are on my list for consideration. Hopefully, if one of the options fits my needs then I will provide a guide at a later date!

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.

So today I found myself in need of a WYSIWYG editor for the admin pages of the site I’m currently working on. I’ve used FCKEditor and Scott Rutherford’s Rails plugin before and Chris has recently been using TinyMCE for a few of our other projects but both of them seemed too heavy, especially when the project requirements only stated a need to apply simple formatting like bold, italic and headings.

There's a few things on my to-do list that repeatedly get pushed to the bottom - one of which is to give OpenSolaris a try - I ordered a Starter Kit a while ago and it popped through the door this morning.

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.

I’ve said it before and I’ll say it again: attachment_fu is great Rails plugin! If you’ve never used it before then Mike Clark’s tutorial is the place to start. However there is one problem with attachment_fu that has been bugging me lately and it relates to mass-assignment.

Back in December I posted about ImageScience and RubyInline on Windows. Turns out I wasn’t the only one trying to get this combination working: according to Google Analytics it has become our second most popular blog entry (for the naturally curious this is the most popular).