James Wilding's Weblog

You want to run Rails 3. You want to use the excellent Paperclip plugin to mess with your attached files. Not a problem.

It Just Works

Paperclip on Rails 3 now just works.

Back in February 2010, I wrote about how to use Paperclip on an early beta release of Rails 3 — back then, a few small hacks were required to get Paperclip running. Now Rails 3 is at beta 4, and it’s safe to assume that we’re as close as we can be to an official Rails release — minus a few last minute tweaks, of course — and both the framework itself and the Paperclip plugin are more stable and more compatible. The good news, then, is that it’s very easy to use the Rails 3 and Paperclip together.

How To Use Paperclip With Rails 3

These instructions are good for Rails 3 beta 4, and Paperclip 9223a917. They’ll probably work on other versions of Rails and Paperclip, too.

1. Install Rails 3
2. Create a new Rails app
3. Install Paperclip
4. Create a model
5. Create a controller and views
6. Define your routes

You can find the important files (controller, model, views, and routes) in this gist, and the full application code is available on Github.

Install Rails 3

Install the latest prerelease of Rails with the following:

$ gem install rails --pre

Create a new Rails app

The command for creating Rails apps has changed in Rails 3. In the bright new future, everything is done using “rails” ¹:

$ rails new paperclip_example

Install Paperclip

Paperclip’s master branch is now good to go with Rails 3. Install from Github thus:

$ rails plugin install git://github.com/thoughtbot/paperclip.git

Create a model

In order to work with Paperclip, your model needs a few special database columns. In this case, I’m creating a User class which will have an attached avatar image.

$ rails generate model User \
avatar_file_name:string \
avatar_content_type:string \
avatar_file_size:integer \
avatar_updated_at:datetime
$ rake db:migrate

I use Paperclip’s has_attached_file method to define my avatar attachment:

class User < ActiveRecord::Base
  has_attached_file :avatar, :styles => {
    :thumb => '50x'
  }
end

Create a controller and views

I’m setting up a simple UsersController with index, new, and create actions (and corresponding routes). You’ll probably want to go further, but if all you’re interested in is proof-of-concept then this is enough.

$ rails generate controller Users

See this gist for the code in my UsersController, and the HTML in my views.

Define your routes

In config/routes.rb:

PaperclipExample::Application.routes.draw do |map|
  resources :users, :only => [:index, :new, :create]
  root :to => 'users#index'
end

Lastly, if you’re mapping your app’s root to a controller, remember to delete public/index.html.

And You’re Done

That’s really all there is to it. Use rails server to start your app and view the results. Did it work for you?

Update: you should read this more recent article for an explanation of how to use Paperclip with the latest beta release of Rails 3.

I got Paperclip working on Rails 3 today. Here’s how.

First, I found (by accident) a branch in the Paperclip repository on Github called “Rails 3″. Call me crazy but I thought that might be worth a try.

Normally you’d install Rails 3 plugins using rails plugin install, but in this case I used git submodule:

These two commands checkout the rails3 branch of Paperclip into vendor/plugins/paperclip, as a Git submodule. If you don’t understand Git submodules, you can read about them here.

I also found that Paperclip wasn’t properly handling image styles; the ‘Paperclip’ section of this post explains how I fixed this (a word of warning: it’s a simple one-line edit which solved my problem but is untested with regard to the rest of Paperclip).

As always, feel free to post questions or feedback in the comments. Good luck!

So it’s Sunday, and rather than go to church I decided to take Rails 3 for a test drive. As you do. How did it go? In the main, very smoothly — a couple of bugs, which you Googlers might find it useful to know about, and some nice new stuff.

Bug: the rails command

Failed completely :) Rails my_app fails with “no value provided for required arguments ‘app_path’”. The solution to this is easy, though: first, get a local copy of Rails 3 (I cloned the Rails repo: git clone git://github.com/rails/rails.git) and then use this command instead:

The rubygems require is necessary for Rails 3 to load all the gems it needs to run.

Thoughts

The Rails command

In Rails 3, the rails command replaces script/console, script/server, etc. This is nice: commands are more meaningful (run the rails server with “rails server”), and easier to type.

ActiveRecord’s new finder syntax

ActiveRecord’s new finder syntax is lovely, and has some nice performance gains which you can read about on other blogs. Named scopes look good:

I’m going to write more about this soon.

Speed

Call me crazy but Rails 3 seems faster. Maybe this has something to do with the fact that it uses Erubis instead of ERB, or maybe I’m just easily impressed :)

Paperclip (tiny bug)

Paperclip has a branch called Rails3: I went out on a limb and guessed that was for Rails 3. It almost just worked, except for one thing: custom attachment styles weren’t being created.

If you’ve used paperclip, you’ll know you can do this:

Well, those :medium, :wide, and :small variations weren’t being created. I didn’t have time to investigate properly but this seemed to have something to do with Paperclip’s callbacks (which were returning false even when they shouldn’t be): my one line hack/fix for this:

I freely admit that this might break other parts of Paperclip, but it works for me.

Conclusions

Overall, Rails 3 feels very nice. As you’d expect from a beta it almost just works, and I’ve made a working app with it in a day. Super easy! Next up: deploying to Heroku.

Some lessons I’ve learnt working on my latest Rails project, a piece of tidy-and-fix work on an existing Rails application. Working on this project has really taught me a lot about the right and wrong ways to use Rails.

1. Routes are important

The app that I was asked to rebuilt had no routes. Nothing.

That’s not to say that no URLs worked with the app, just that the mappings between URLs and controllers/actions was defined in the code itself — mostly using the old Rails convention:

This makes it very difficult to discover how a Rails app responds to a particular URL, without hunting through the controllers to find a corresponding action. It also makes working with REST a nightmare!

Lesson learnt: use routes.rb

2. Conventions are important

Rails is all about convention over configuration, of course. But when you’re coding a Rails app — especially if you’re new to Rails — it’s easy to ignore those conventions, or just be plain unaware of them.

This leads to a lot of unnecessary work. I’ve spent a lot of time over the past few months translating unconventional code into code that more closely fits the Rails way of doing things: the result is code that’s easier to test, easier to maintain, and much, much faster.

Lesson learnt: take some time to understand Rails’ conventions

3. Simplicity is important

The more I write code, the more I find myself thinking: complicated code is a Bad Thing. Of course, as a kind pedant once told me, there’s a difference between complicated and complex.

(If you don’t have a dictionary handy, “complicated” roughly means messy, difficult to understand; “complex” means many interconnected parts, or a large system. The key difference is that complex systems can be well designed: complicated systems are not.)

OK, dictionary rant over :) Messy, complicated Rails applications come about when a developer doesn’t take the time to think things through. Simplicity is normally easy if you take some time to plan your work upfront — messy code happens when things are rushed or not thought through.

Lesson learnt: think before you start coding

4. Ruby is important

Obvious, but very true: Ruby is important to Rails applications. If you’re new to coding, or new to Rails, then take some time to learn Ruby first: otherwise, you’ll miss out on the power (and beauty) of a great language and a great framework.

Lesson learnt: learn Ruby and Rails, not just Ruby on Rails!

You are important, too

Conclusions? All of the above (and more) is important when you’re developing a Rails app. And you, the developer, are important too — have fun, keep learning, and don’t work too hard. Rails should be fun :)

tr.im is closing down, and the blogs are a-chatter about why URL-shortening services are probably a bad idea if you care about your links, and why you should roll your own service if you can.

Which is where Rails comes in.

(more…)

It’s really simple to get a Rails application to serve custom views to an iPhone or iPod touch: so simple, in fact, that in a spare half-an-hour I wrapped the necessary code up into a tiny plugin, which will do all the work for you!

Update: if you’re using the plugin, have questions, or have found this post useful, take a moment to send me a message on Github, or email me (james at this domain). It’s always great to know how people are using my work :)

(more…)

Well, I’ve been away from WordPress for a while thanks to flu (swine? maybe), and I thought a good way to break the silence would be with a post on the upcoming release of Rails: version 3.

(more…)