This site, mfischer.com, will return to its roots as the personal blog about Mike Fischer. To publish my technology articles I’ve created a new blog under a new domain: thelastpixel.net. I’ve just gotten started with it, but plan to post regularly on software development and other technology issues. If you’re interested, check it out and sign up for the RSS subscription! If not, just keep watching here for more non-technical news from my life…

haml and sass

I was sold on Sass from the first few minutes I used it. Sass lets you write CSS using a simplified abstraction format, and compiles your sass code into CSS. Best of all, it can be used without Rails (or Ruby), so I’ve been using it with static web pages as well. Here’s an excellent example from the sass web site:

Haml does the same for HTML. It took me a little longer to get used to, probably because it’s actually a replacement for HTML and Embedded Ruby (ERB). Haml really cuts down on the amount of typing needed to generate HTML, auto-closes tags (based on indentation), and makes it far easier to see the structure of your document. This snapshot from the haml page is a great demonstration:

friendly_id

This extends Rails’ RESTful resources by making URLs look “friendlier”, using a user-specified attribute of a model instead of the auto-generated numeric ID. In other words, by simply adding a statement like has_friendly_id :name to a users model, friendly_id converts URLs from http://my.site.com/users/17 into the much nicer http://my.site.com/users/mike.

Authlogic

This is the leading user authentication framework for Rails. It you need to allow users to register, sign in, change passwords, use OpenID, user LDAP, etc., this is the plug-in for you. It takes some time to learn how to integrate it, since each web site’s implementation is going to be a little different.

mislav-will_paginate

This makes it dead simple to take a model with many records, and display it in pages, where you can control how many are displayed per page, and the style of the page links:

thoughtbot-paperclip

I’ve researched and tried many file upload/attachment gems but Paperclip is the one I settled on. It seems to be the most actively maintained, and one of the most flexible. File uploading is still not as easy as it should be, especially if you want to provide feedback during upload (usually via a Flash plugin) or allow multiple attachments to a model (usually with an associated polymorphic upload model). Paperclip doesn’t do these things out of the box, but it’s possible to wrangle it into submission…

unobtrusive_date_picker

These days there’s no reason to make your users select a month, day, and year from three separate drop-down boxes, or type a date in some pre-determined format. This plug-in automagically adds a pop-up calendar to your date selection input fields.

jRails

When I started learning Javascript a few years ago, it was a huge pain in the neck. I quickly came across Prototype, which made my life much easier. Before I got too far along with that however, I found jQuery and fell instantly in love. This was clearly the way Javascript programming was meant to be. I used it for everything. Then last year when I started learning Rails, I was a little disappointed to find that the javascript library built-in to Rails was Prototype. Fortunately, others apparently had the same complaint, and created JRails, which integrates jQuery with Rails.

Others

There are a few other gems and plugins I use, but not as frequently. They include: Maruku, acts_as_audited, mechanize, and hpricot.

Am I missing out on any must-have gems or plug-ins? Let me know in the comments!

The main problems I encountered were:

1. There are several attachment uploading plug-ins for Rails, like attachment_fu, Paperclip, or UploadColumn, with various features and complexities, but none had good references on handling multiple uploads associated with one model instance.
2. To add multiple attachments to an object requires a separate model for attachments, associated with the main model via a has_many/belongs_to relationship. This isn’t hard if the model views are kept separate and RESTful (create a new dog, then add a photo, then add another photo, etc). That’s not a good user experience however — I want to be able to add a new dog, and upload many associated photos at the same time.
3. It turns out that complex forms to handle multiple associated models is pretty tricky in Rails (but should get better with Rails 2.3, coming soon).
4. I also wanted to let the user manually crop the photos after upload, to just select the dog’s face for example.

After several weekends of experimenting, reading lots of blogs and tutorials, and playing with various plug-ins, I finally have a working solution I’m pretty happy with. Here’s what I ended up doing:

• I’m using the Paperclip gem to handle the actual uploads. The main reason I chose this over other options was that Paperclip lets me easily create additional “styles” of an uploaded photo, like a small thumbnail, a page-sized version, etc.
• I’m using the attribute_fu plug-in to handle the multi-model forms so I can upload any number of images at the same time as a new dog is created.
• I’m using the jsCropperUI JavaScript library to let the user select an area to crop.
• Since Paperclip requires ImageMagick to do its resizing, I installed RMagick and use that for my cropping.

Getting started

I have two models: “Dog” and “Upload”. I started by calling my second model “Attachment”, but after running into problems, I learned that Paperclip uses that name internally and will not work correctly if you name your model “Attachment”.

$ rails dogs
$ cd dogs
$ script/plugin install git://github.com/giraffesoft/attribute_fu.git
$ script/generate model dog name:string
$ script/generate model upload description:string dog_id:integer \
         photo_file_name:string photo_file_size:integer
$ script/generate controller dogs
$ script/generate controller uploads

Models

The Dog model just has a name for now. The Upload model will represent each uploaded photo. It has a description which the user can enter, a dog_id foreign key, and two attributes for Paperclip: a photo_file_name string and a photo_file_size integer. See the Paperclip documentation for more details on how these (and other) special attributes are used.

# models/dog.rb
 
class Dog < ActiveRecord::Base
  has_many :uploads,
           :attributes => true,
           :discard_if => proc { |upload| upload.photo_file_size.nil? }
end

I updated the Dog model to have many uploads. The “:attributes” parameter is part of attribute_fu, and lets the Dog controller create associated models at the same time a new Dog is created. The “:discard_if” tells attribute_fu not to create an associated model if certain conditions are met — in this case, if there’s no file that was uploaded. This is needed because we may put many file upload fields in the “new Dog” form, but a user may only select one or two photos. In that case, all the blank form elements would be submitted too, and created as empty Upload instances.

#models/upload.rb
 
class Upload < ActiveRecord::Base
  belongs_to :dog
  has_attached_file :photo,
                    :styles => {
                      :thumb => ["100x100", :jpg],
                      :pagesize => ["500x400", :jpg],
                    },
                    :default_style => :pagesize
end

This Upload model belongs_to a dog, to match the has_many association above. “has_attached_file” is part of Paperclip, and the “photo” attribute must match the prefix of the database fields above (e.g. photo_file_name). Paperclip can automatically re-size photos and keep multiple versions, based on the “styles” hash. Here we create a small thumbnail, and a version good for embedding in web pages. In both cases, the photo is converted to a JPEG if needed. The original photo is stored with a style of “original”.

Views

The main view we’re concerned about is the “new dog” view. This will give the user a form to add a new dog, and upload photos to associate with the dog.

# views/dogs/new.html.erb
 
<h1>New dog</h1>
 
<% form_for @dog, :html => { :multipart => true } do |f| %>
  <%= f.error_messages %>
 
  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
 
  <div id='uploads' style='border: 1px solid silver'>
    <%= f.render_associated_form(@dog.uploads, :new => 5) %>
  </div>
 
  <%= f.add_associated_link('Add another photo', @dog.uploads.build) %>
 
  <p>
    <%= f.submit "Create" %>
  </p>
<% end %>

The first part of the above view gives us a form for a new dog instance. It also calls attribute_fu’s “render_associated_form” to create a nested form for upload instances. Here we create five blank instance forms. The instance forms are generated by a partial named after the associated model… in this case the partial is _upload.html.erb (below). We also add a link to create additional file upload forms on the fly via attribute_fu JavaScript with the “add_associated_link” call.

# views/dogs/_upload.html.erb
 
<p class='upload'>
  <label for="upload_description">Description:</label>
  <%= f.text_field :description %>
 
  <label for="upload_photo">Photo:</label>
  <%= f.file_field :photo %>
 
  <%= f.remove_link "remove" %>
</p>

The partial is pretty standard, just a field for our photo description, and a file upload field. The only unusual part is attribute_fu’s “remove_link” JavaScript call, which lets the user remove one of the photo upload forms.

Here’s what the completed form looks like:

Controllers

The nice thing about attribute_fu is that no special controller logic is needed! The dog controller is just a standard RESTful controller! When the form is submitted, the dog instance is created, and all the associated upload instances are created simultaneously:

# controllers/dogs_controller.rb
 
class DogsController < ApplicationController
 
  def index
    @dogs = Dog.find :all
  end
 
  def show
    @dog = Dog.find params[:id]
  end
 
  def new
    @dog = Dog.new
  end
 
  def create
    @dog = Dog.new params[:dog]
 
    if @dog.save
      flash[:notice] = 'Dog was successfully created.'
      redirect_to @dog
    else
      render :action => "new"
    end
  end
 
end

Image cropping

The last feature to add is the image cropping functionality. We’re going to do this in the “edit upload” action. The edit form will show the image, and let the user drag a rectangle around the region to crop. The form will return the rectangle coordinates, and we’ll override the standard update_attributes method of the Upload model, to perform the crop.

In the main view template, I’m including the jsCropperUI JavaScript code and its dependencies. The scripts go in the public/javascripts directory when you install the jsCropperUI code.

# views/layouts/application.html.erb
 
<%= javascript_include_tag 'cropper/lib/prototype.js' %>
<%= javascript_include_tag 'cropper/lib/scriptaculous.js?load=builder,dragdrop' %>
<%= javascript_include_tag 'cropper/cropper.js' %>

The “edit upload” view is a little complex. Here’s how it’s put together:

# view/uploads/edit.html.erb
 
<h1>Editing upload</h1>
 
<% form_for(@upload) do |f| %>
  <%= f.error_messages %>
 
  <p>
    <%= f.label :description %><br />
    <%= f.text_field :description %>
  </p>
 
  <!-- CROP FORM -->
  <div id='cropwrap'>
    <%= image_tag @upload.photo.url, :id => 'cropimage' %>
  </div>
 
  <div id='cropresults'>
    <%= f.label 'x1' %>
    <%= f.text_field 'x1', :size => 6 %>
    <br />
    <%= f.label 'y1' %>
    <%= f.text_field 'y1', :size => 6 %>
    <br />
    <%= f.label 'width' %>
    <%= f.text_field 'width', :size => 6 %>
    <br />
    <%= f.label 'height' %>
    <%= f.text_field 'height', :size => 6 %>
    <br />
  </div> <!-- cropresults -->
  <!-- END CROP FORM -->
 
  <p>
    <%= f.submit "Update" %>
  </p>
<% end %>

In addition to the edit field for our model’s normal attributes (“description”, in this case), we also have fields for the geometry of our crop rectangle. These fields will be filled in automatically by the jsCropperUI. We also need to display the image we’re cropping, and identify it with a CSS ID so the jsCropperUI can attach to it. To attach the jsCropperUI, we need to add some JavaScript to the page:

# view/uploads/edit.html.erb
 
<script type="text/javascript" language="JavaScript">
function onEndCrop( coords, dimensions ) {
  $( 'upload_x1' ).value = coords.x1;
  $( 'upload_y1' ).value = coords.y1;
  $( 'upload_width' ).value = dimensions.width;
  $( 'upload_height' ).value = dimensions.height;
}
 
Event.observe( window, 'load', function() {
  new Cropper.Img('cropimage', {
    minWidth: 50,
    minHeight: 50,
    displayOnInit: true,
    onEndCrop: onEndCrop
  } );
} );
</script>

This attaches the jsCropperUI to the photo we want to edit, identified by the “cropimage” CSS ID. It also sets up a callback function to set our form fields with values based on the crop coordinates. Check the jsCropperUI documentation for more details.

Here’s what our page looks like:

There are two other things to be aware of here:

First, the “image_tag” is displaying the “:default” style of the uploaded image. If you look back to the Upload model code above, that means it’s an image that’s been scaled down to at most 500×400 pixels. This is important, since we don’t want to display a full-sized image if someone’s uploaded a giant photo from a 10 megapixel digital camera!

Second, we’re telling the form helpers to create form fields for attributes like “x1″ and “width”, which aren’t attributes of our Upload model. To make this work, we need to add some virtual attributes to the model (virtual, because they’re not associated with any fields in our database table):

# models/upload/upload.rb
 
attr_accessor :x1, :y1, :width, :height

Now, when the form is submitted, the standard “update” action in the uploads controller will call “update_attributes”, just like any other form and controller:

# controllers/uploads_controller.rb
 
def update
  @upload = Upload.find params[:id]
  if @upload.update_attributes params[:upload]
    flash[:notice] = 'Upload was successfully updated.'
    redirect_to @upload
  else
    render :action => "edit"
  end
end

To make this actually crop the image, we need to override the update_attributes method in the upload model:

# models/upload.rb
 
require 'RMagick'
 
def update_attributes(att)
 
  # Should we crop?
  scaled_img = Magick::ImageList.new(self.photo.path)
  orig_img = Magick::ImageList.new(self.photo.path(:original))
  scale = orig_img.columns.to_f / scaled_img.columns
 
  args = [ att[:x1], att[:y1], att[:width], att[:height] ]
  args = args.collect { |a| a.to_i * scale }
 
  orig_img.crop!(*args)
  orig_img.write(self.photo.path(:original))
 
  self.photo.reprocess!
  self.save
 
  super(att)
end

What’s going on here? We want to crop our original, high-resolution image, but we used a scaled down version in the jsCropperUI to select our crop rectangle. To adjust for that, we need to check the pixel width (“columns”) for the original and scaled images, and compute a scaling factor. Next we prepare the four arguments for the RMagick crop function, which expects x1, y2, width, and height. We create an array with the arguments, convert to integer (they’re still strings, since they came from a text field in the form), and scale them. We can pass multiple arguments to a method by prefacing an array with an asterisk. That’s something new I came across in this project, and I suspect may come in handy again some time. The image is cropped, and then written back to disk, replacing the original.

“reprocess!” is a Paperclip method to re-generate thumbnails and other scaled versions of an image from the original. And finally, we call the true “update_attributes” method to handle things like the “description” or other actual attributes of our model.

So there you have it… a framework to deal with multiple image uploads to an associated model, with user-selected cropping.

I’ve packaged up the example code into a GitHub repository. It’s a fully functional Rails 2.2.2 app, assuming you have the Paperclip gem and RMagick already installed.

Comments and improvements are welcomed.

I did a fair bit of Google research into memory usage and garbage collection in Rails, but couldn’t find any smoking gun. I did come across a really tiny Memory Usage Logger for Rails, that just adds the process memory size to the server log after each request. I added this handy code, and used the Apache Benchmarking Tool to send several hundred web requests to my app, and graphed the results. Memory was definitely increasing linearly with the number of requests.

After doing some basic troubleshooting and code analysis, I was getting nowhere. Instead, I created a new, simple Rails app. Just an empty app, with one model and controller generated with Rails’s scaffolding and default views. This exhibited the same ever-growing memory problem. Weird. Rails is used widely for major web sites, so I knew this couldn’t be a widespread problem. I next installed Ruby Enterprise Edition, which was fortunately a fast and painless process. When I restarted my application and re-ran my stress test, memory was completely flat!

I notice now that although both versions of ruby (standard and Enterprise Edition) are version 1.8.6, they are different patchlevels, so I’m not sure if the memory fix is due to REE or due to some more recent ruby patches. Either way, I’ll probably stick with REE in the future.

So what’s been going on? Three things mostly: work, xbox gaming, and Ruby on Rails programming. I’m happy to say I’ve finally got RoR pretty well figured out, and have created some pretty neat stuff with it so far (mostly around xbox social networking). My long-term goal is to use it the next time I re-design the Lab Rescue web site.

I’m off work this week, and it’s nice to relax at home, see family, visit friends, and generally relax.

Merry Christmas, Happy New Year!

A few minutes later, Kathie returned from Scott and Sue‘s, and announced that the hard disk in Scott’s MacBook had just died. Interestingly, the hard disk in my MacBook (purchased the same day as Scott’s) failed about two months ago, a couple weeks before the 1-year warranty ended.

So, while anxiously waiting for my new 1 TB disk to ship so I could start keeping backups again, today another disk in the Linux server failed. This time it was one of the two 250 GB disks. Now, I have no backups, so the data is gone. I did get lucky though, since it was the disk containing my music archive, which means all I have to do is re-rip 600 CDs into FLAC format. Not fun, but also not very urgent. The other 250 GB disk has all the important stuff… years of documents, photos, software I’ve developed, etc. If that disk had failed instead of the music disk, I’d be in sad shape right now.

So, I spent the evening frantically backing up everything I could from the “important” disk to various other places in the house (spare space on the desktop Mac, laptops, etc.). That’s done, so I’m at least going to sleep knowing I have a backup of the important stuff “just in case”. I also ordered a second 1 TB disk which I’ll be putting in Scott’s house as an off-site backup. Considering the cost of hard disks these days, it doesn’t hurt to be overly cautious.

• 35 Beautiful Music Album Covers
• (Really) Stunning Pictures and Photos
• 10 Principles Of Effective Web Design
• Top 10 CSS Table Designs
• Framewords Round-Up: When To Use, How To Choose?
• 55 Free High Quality Icon Sets

Enjoy!

There are hundreds of Rails tutorials all over the web, but they’re all very similar to each other, and just cover the basics. I’ve come to the conclusion that at least part of my problem is that I don’t have a good learning and reference book. Agile Web Development with Rails is the definitive work, but the currently available edition only covers an old version of Rails, and the updated edition won’t be printed until October. So, until then I’ll continue stumbling through my first project, learning a little bit at a time.

On the bright side, I’ve seen enough to be confident that once I do become proficient, I’ll be able to use Rails to develop web applications more easily (and with less errors) than I did in the past with PHP.

Since I know most Mac people use Safari, and a fair number of “people who know what they’re doing” use it, I’m going to give it another try. One of my favorite things about Firefox is its plug-in architecture, allowing anyone to develop very useful add-ins to the program. Firebug is essential for any web developer, so unless Safari has something similar, I’ll still be falling back on Firefox for development.

Do you have any preferences one way or another?

$x = open(can_of($worms));


Anyway, the real point of this post is to share how sad I am at the Frankenstein user-interface of the new Office… a half-MacOS interface with a half-Vista interface glued on. This on the same day that I read an article about glow-in-the-dark cats being bred by inserting jellyfish genes into their DNA. I don’t think the cats or the software are better off. And what’s with that floppy-disk “save” icon?? Has anyone even seen a floppy disk in the last 8 years? What makes this more amusing is that the Office team did change the floppy disk icon as compared to the previous version of Office for Mac, and compared to the latest Windows Office: the new floppy icon is anatomically correct, whereas the previous versions had the aluminum access door on the wrong side as compared to a real disk. Well, all I can say is I’m glad they got that fixed!