Web 2.0.11562 beta

OK for a current project I needed to have attached photos for stores. I could have chosen to use attachment_fu, but after seeing the excellent Railscast, I was eager to try paperclip. My opinion – a bit disappointing really, as it was so effortless I didn’t actually learn much at all. No looking through lots of plugin code, no spending hours of googling – no pain!
I grabbed the plugin code since the GEM seems to be out of date? How easy was it? Keep reading.

First I installed the plugin then I ran the migration. Four columns added to my stores table for filename, size, type and timestamp. Frankly I could live without all four, but some projects are gonna use these I suppose.

Next I added a line to the model to which I wanted to have an attachment:

I could have also specified multiple different file sizes to save, like 150×200, 400×300, etc.like this:

Then I added a couple lines to validate the things I cared about:

There’s one “gotcha” in here, in that to change your new and edit forms to work with binary attachments you’re gonna have to change the form action to be mixed/multipart

Next I went to the view and just refer to the attachment as @store.exterior.url (my stores controller serves up @store), and if I had saved thumbnails and large versions I could have specified which one I wanted to display.

Now I am saving these store images in a shared directory. So when I deploy, I have a task defined in capistrano that runs right after the deploy:symlink that also puts symlink in the public/images/stores directory pointing to this shared store photo store (pun intended) But I need to run a background task to back up those images periodically, or I’ll forget about them until one day…..

Long story short, I decided to see how easy it was to tell Paperclip to save them in my Amazon s3 account instead of the filesystem. Yeah you guess it – pretty tame. Here’s the revised store.rb snippet:

Don’t ask why I am using such a ridiculously named bucket, but I am. Anyway the 2 keys for s3 are kept in a YAML file as you can see. I treat it just like my database.yml file, and don’t version it, but simply keep in :rails_root/shared/config/ and create a symlink to it on every deploy.
Now you may ask, how can this be such a happy plugin experience. Well if I have to criticize, it would be that I see it added 4 columns to my stores table. In my case I could get by with less. But I think the main point is if I had a half dozen attachments per model, like for a real estate app with exteriors, kitchens, family rooms, etc. then this table could not be allowed to grow that wide.

But hey, if the app is featuring photos as a central item, shouldn’t you have a model just for your attachments? Add one column to refer back to the model it belongs_to and you’re golden. That’s really not so terrible.

Tonight’s Boca Ruby meetup was the best one I’ve been to so far. We were graced with a presentation given by Jason of RailsEnvy fame on changes to the upcoming release of Rails 2.2. Jason covered a lot of material you’ll surely see in the near future at envycasts.com. It was grouped into sections, like changes to ActiveRecord, and gave code examples for each. Of course there were slick effects from Keynote ™ and great explanations given by Jason.

Well I’m ready to report on my experience with using linode.com for hosting ruby on rails apps. In a word, it’s great.

I didn’t actually have any serious problems with which to judge their customer support, but in general I think that if everything just seems to work fine it ought to count as good. In other words, I got a reply when I filed a support request, I just never encountered a situation where I really needed help. Reliability and lack of problems are the pre-emptive hosting company’s version of good customer support. After all, even if I’m trying to assess their support, if I don’t need it that’s just as positive as a good support experience.

I recommend linode.com for your rails hosting needs.

OK so I’m now a fanboy. I resisted for oh-so-long, but now that I’ve converted I’m enjoying building things so much more. Used to be, I’d spend 1/3 of coding time re-inventing easy wheels, because I knew how and they were easy. Another third was surfing the web looking through other people’s code with an eye toward integrating it into my project.

Downsides:

• it’s still early in the game and things are really still in flux,
• deploying and hosting is still evolving and new tools are emerging
• still looked upon with suspicion in the enterprise

Upsides: (see downsides)

Want to write a quick WP plugin for a blog? PHP is still the weapon of choice, and it will remain so for some time to come for many things. But for a lot of database-driven website development and web applications Ruby on Rails seems perfect.