thewebfellas - ruby on rails development specialists uk

For well over a year now attachment_fu has been my plugin of choice for adding file uploads to our Rails applications, but recently my fellow WebFellas have been raving about Paperclip from the clever guys at thoughtbot. As I’ve just started yet another new project I figured it was time to take Paperclip for a spin.

I’ve always enjoyed a kind of love/hate relationship with JavaScript, something which I think stems from my early exposure to using it on Microsoft platforms in the late 90’s, using half-baked debuggers, inconsistent browsers and a huge degree of trial and error. It’s not that I can’t write clever things in JavaScript, just that it’s not my most favourite job: if I can delegate to someone else I usually will!

Last week I was left with no choice but to roll up my sleeves and get coding: I was putting together a financial trading application prototype for one of our new clients and wanted to use JavaScript and JSON to periodically update pricing information.

Did you know ActiveRecord includes support for aggregations? If you did, have you ever used them? Despite being part of Rails from the start composed_of tends to lurk in the shadows while newer features like named_scope steal the limelight. It’s time to give composed_of some love again!

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.

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.