Firebelly Design

June 08, 2010 by Brandon Weiss

Today I had a need to get the name of a month by its number. So if I had the number ‘6’ I would want to be able to get ‘June’.

This is not a particularly complicated problem; there are myriad ways to accomplish this, but all of them are rather kludgey, and Ruby being such a magical language I was sure there must be a method built-in. Or at the very least there would be a helper for it in Rails.

But after checking the docs for both I couldn’t find anything. Google also returned nothing except the kludgey ways I already knew how to do. So I gave up and wrote this:

month = 06
date = Date.parse("2010-#{month}-01")
month_name = date.strftime("%B") # => "June"

As I said it’s very simple to do, but seems so unnecessarily roundabout. Parsing a string to a Date object and then using the date formatter method to get the name? That doesn’t smell anything like Ruby.

I could create my own array or hash to map them, which is slightly more elegant, but more lines of code, and still rather roundabout.

So I took one more look at the docs, and while I was reading them it occurred to me that if the strftime method can do it, Ruby must have some internal way of mapping month numbers to names. So I took a look at the actual source for strftime and found the answer.

Although I’ve been to the doc page for the Date class hundreds of times, I’d never really used it except to reference particular methods, so I’ve always just skipped right by the constants section at the beginning. But in it there’s a MONTHNAMES constant, and on the first line in the section, no less.

So to get the month name from a number, all you have to do is¹:

Date::MONTHNAMES[6] # => "June"

Ruby really is made out of unicorns.

¹ As an added bonus, since arrays start with 0, they’ve shifted the array values up one by starting the array with nil at index 0, so you can get the actual month name of a number without having to manually subtract 1 from that number.

Comments

March 02, 2010 by Brandon Weiss

The biggest hurdle in my quest to get our site running on Heroku turned out to be asset uploading. Because of the way Heroku is architected, each application instance is read-only. You cannot just upload files and write them to disk, and even if you could, they would only be available to the instance you uploaded them to; none of the others would be able to see them.

Heroku is cloud-based hosting, so the solution is cloud-based storage. Any service will do, but I’d recommend Amazon S3. If you aren’t using it already, now is as good a time as any to switch. The benefits of having a fast, scalable storage system in the cloud are almost too many to count.

Unfortunately our site wasn’t using S3 yet, so the first step was to migrate all the uploaded assets to it. Luckily, if you’re using a file attachment library like Paperclip (which we are), that part is actually pretty easy.

Paperclip filesystem to Paperclip S3

To start, create an s3.yml and put it in config/. Here’s what’s in mine:

access_key_id: xxxxxxxxxxxxxxxxxxxx
secret_access_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
bucket: firebelly

If you like, you can also specify different accounts/buckets for development and production like you do for databases.

Then in your model change your attachment method from something like this:

has_attached_file :photo

To this:

has_attached_file :photo,
  :storage => :s3,
  :s3_credentials => "#{RAILS_ROOT}/config/s3.yml",
  :path => ":attachment/:id/:style.:extension"

Then migrate the files themselves over to S3, and either change the structure to match your :path, or change the :path to match your directory structure. Be sure to set the access permissions correctly; you want Read set for all users, or the files won’t be viewable. Future file uploads will have permissions automatically set by Paperclip, but when you upload them manually the permissions must be set manually as well.

The Plot Thickens

I thought I was done, but then I saw it, lurking in the corner: attachment_fu. Some of our models were sadly still using attachment_fu, and while there’s nothing necessarily wrong with attachment_fu, Paperclip is just more modern and has become the de facto standard for file attachments. Plus, we definitely shouldn’t be using two different libraries in the same app; that’s just ugly. So I have to migrate all the models using attachment_fu to use Paperclip instead.

I had a feeling this was going to be really, really painful, so I hit up Google first to see if maybe someone else had written about it and I could save myself some trouble. But surprisingly, even though many people must have done this before me, I could only find one halfway decent guide for migrating from attachment_fu to Paperclip written by James Stewart. And just my luck, it didn’t work for me. I’m sure it must be something related to my particular setup, because it seemed to work for everyone in the comments, but I just got a bunch of errors that I couldn’t figure out. So instead I hacked James’ script to get around the errors. Here’s what I did:

Attachment_fu filesystem to Paperclip S3

First, grab a copy of the Paperclip migration script that I forked and modified (yay, GitHub) and put it in lib/.

Now make a new migration:

script/generate migration convert_project_slides

And edit it:

class ConvertProjectSlides < ActiveRecord::Migration
  include PaperclipMigrations
  
  def self.up
    add_paperclip_fields :project_slides, :photo
    
    ProjectSlide.reset_column_information
    
    ProjectSlide.all.each do |project_slide|
      populate_paperclip_from_attachment_fu(project_slide, project_slide, 'photo', '/project_slides/')
    end
  end
  
  def self.down
    remove_paperclip_fields :project_slides, :photo
  end
end

Let me break down what’s happening in this migration.

1. You have to include the paperclip_migrations.rb script in your migration.
2. Then the columns Paperclip uses need to be added to the project_slides table.
3. The arguments that have to be passed to populate_paperclip_from_attachment_fu is where I got a little confused. The first one is the model you’re sending to, the second is the attachment you’re sending from. In this case they’re the same thing. The third one is the prefix you specified in add_paperclip_fields, and the fourth is the directory where the attachment_fu files are.

The original script didn’t have that fourth argument because it can be gotten from attachment_fu, but inexplicably that wouldn’t work for me, so I had to disable attachment_fu and specify it manually.

But before you run the migration, you have to take out attachment_fu’s has_attachment declaration in your model. Now would also be a good time to replace it with Paperclip’s declaration. So just like before, something like this:

has_attachment :content_type => :image, 
  :storage => :file_system,
  :path_prefix => 'public/project_slides',
  :resize_to => '345x285>',
  :thumbnails => { :thumb => '135x135!' }

Becomes something like this:

has_attached_file :photo,
  :styles => { :thumb => '135x135!' },
  :storage => :s3,
  :s3_credentials => "#{RAILS_ROOT}/config/s3.yml",
  :path => ":attachment/:id/:style.:extension"

One more thing before you run the migration. When attachment_fu creates thumbnails I guess the way it links them back to the original is by creating a new record in the table, and referencing the original record in a parent_id column, creating a tree structure. But I only want the migration to run on the original attachments, not thumbnails, so I deleted them from the database with something like:

DELETE FROM project_slides WHERE parent_id IS NOT NULL

That SQL query will delete any rows that have a value in the parent_id field (which means they aren’t originals).

OK, all set, now you can run the migration:

rake db:migrate

Assuming everything worked, you might want to drop attachment_fu’s various columns from your table. The ones I had were:

size
content_type
filename
height
width
parent_id
thumbnail

Lastly, just upload the photos to S3 like before, set the permissions and you’re done.

Comments