/script/backup_db:

#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'erb'
require 'yaml'
 
unless config = YAML::load(ERB.new(IO.read(RAILS_ROOT +
"/config/database.yml")).result)[RAILS_ENV]
   abort "No database found for environment '#{RAILS_ENV}'"
end
 
db_out_path = File.join(RAILS_ROOT, 'tmp', "dbdump_#{RAILS_ENV}.sql")
system "mysqldump -u #{config['username']} --password=#{config['password']}
 #{config['database']} >; #{db_out_path}"

To run your backup, just execute this from your rails root:

script/backup_db RAILS_ENV=production

Working in an agency setting, where the crispness and clarity of your images is extremely important, writing web systems that automatically generate thumbnails can be problematic. When resizing images downwards, as is often the case in thumbnail generation, pixel values are approximated from their original size. These approximations can result in thumbnail images which are blurry and difficult to read. The bigger the change in pixel size, the more dramatic the effect. So if you resize a 900×900px image into 120×120, you will see a major difference in clarity.

Photoshop has several methods for dealing with these approximations when resizing images – namely the Bicubic Sharpening interpolation method and the Unsharp filter. Both of these methods help improve image quality when resizing downwards.

The best way to see what I’m describing is through example:

Example of image sharpening in action

If we rely on out-of-the-box image resizing methods typically available, we usually end up with thumbnails that look like the upper right photo: blurry and unclear. However, we can easily have our applications automatically apply an unsharpening mask when we generate thumbnails. For instance a common image library used in online applications is ImageMagick – which has all sorts of features which can help our images maintain quality at smaller sizes.

In a recent project, I was tasked with creating a portfolio system which would be used to showcase work. The requirements were that the system should upload an image file and automatically generate several sizes of thumbnails to be used throughout the website. However, the thumbnails need to have the same crispness of their original full-size counterparts.

The Solution

The solution is in fact amazingly simple. Here are some quick assumptions:

• The platform where we’re running our web app has “ImageMagick”:http://www.imagemagick.org/script/index.php installed
• We’re using the “Papercilp”:http://www.thoughtbot.com/projects/paperclip plugin to handle uploading and thumbnail processing

Here’s the code we place at the top of our model which will be responsible for accepting uploaded photos:

class Project < ActiveRecord::Base
   has_attached_file :hero_shot,
     :styles => { :large => "500x500",
     :medium =>; "300x300>",
     :thumb => "100x100>" },
     :convert_options => { :all => "-unsharp 0.3x0.3+5+0" }

With the above declaration in our model, Paperclip will create 3 thumbnails in 3 different sizes. The :convert_options hash is where we define how the photo will be processed and is responsible for performing the unsharpening. Passing the :convert_options hash allows us to specify specific instructions to ImageMagick – just like if we were using the ImageMagick library from the command line. Let’s take a look at the code which provides the unsharpening:

-unsharp 0.3x0.3+5+0

So where did we come up with this strange looking command? Essentially this is the same as executing “convert -unsharp 0.3×0.3+5+0 IMAGE.jpg NEW_IMAGE.jpg” from the command line. The :convert_options hash is basically a list of parameters that Paperclip will be passing to the ImageMagick “convert” command. The command above is telling ImageMagick to unsharpen each of our photos. If you want a more detailed explanation, please see this great blog post about fine-tuning this command. As is shown here, this command is performing an unsharp mask of a radius of 0.3 pixels, with an amount of 5.0 applied to it (in relation to the Photoshop effect, this is equivalent to an amount value of 500% at 0.3 pixel radius).

That’s it – now when we upload a photo, Paperclip will automatically resize and unsharpen our photos. The result is thumbnail photos which are more clear and truer to the original image.

Resources

• Paperclip plugin/gem
• Railscasts – Paperclip
• Unsharpening with ImageMagick

Before going much further, I should state that I enjoy programming just about anything and in about any language. A good weekend for me almost always includes compilation of source code and a strong beer–the order and frequency of the two being highly dependent on the preceding 5 days. But take my opinions with a grain of salt. These opinions are from a geek working in the ad world where development cycles are extremely tiny and our requirement list is often very different from software development studios.

1. Rails deployment are now almost as easy as PHP deployments

It used to be that Rails’ biggest hurdle was deployment. Having set up many mongrel-based deployment schemes, I can understand why Rails scared away a lot of people. However, with stability of “Phusion Passenger”:http://www.modrails.com/, setting up a Rails app is now just as trivial as PHP. If you’re worried about stability, it may be worth it to know there are a handful of large websites now using Passenger, including “Shopify”:http://www.shopify.com and even “NY Times”:http://www.nytimes.com. We deploy all of our Rails sites through Passenger and have not had one major problem yet.

2. Test like a pro

If you enjoy working within the MVC paradigm and you feel guilty about writing code before you write a test, Rails provides a wealth of features proven in the .NET and Java enterprise landscape, and adapts them to the flexible Ruby language. Test and Behavior driven development approaches are easy to follow in Rails.

3. You want easy object relational mapping

ActiveRecord is a thing of beauty. Does it work for every possible situation? Nope, but it gets you pretty darn close. The first time I made a database query in Rails, my jaw dropped.

User.find(:all, :conditions => [ 'created_at < ?', Time.now - 1.days])

Even if you haven’t used Rails before, what that tiny command does is probably pretty obvious. While ActiveRecord is not an excuse for any developer to forget SQL entirely, it helps us with the low hanging fruit in our systems and lets us spend more time where we should really be using our brains.

4. You’re really tired of FTP

I have a confession – you don’t need to use Rails to take advantage of automated deployments with the amazing “Capistrano”:http://www.capify.org/ tool. Launching new deployments of client websites is now as easy as executing the following command from the command line:

cap production deploy

This line, after some configuration of course, will completely deploy my application from a repository, run any database migrations, reset my daemons, and keep a copy of the last version in case something is botched. Rolling back is easy:

cap production deploy:rollback

Boom! I’m right back to the last version before the client even saw the nasty 500 error header on their contact page. Whew! (Not that this ever happens of course…eh-hem).

5. You want easier maintainability

There is no such thing as a sealed class in Ruby. That means if I don’t like Ruby’s String class, I can easily rewrite it to suit my needs (otherwise known as *monkey-patching*) at any time throughout a program’s execution. This is both very dangerous and a very awesome for some fairly obvious reasons. If we have interoperability between 2 different software libraries, we can easily patch the deficiencies ourselves while keeping the original libraries intact. If you don’t like how Rails handles error messages, you can easily override the offending method or patch the functionality how you see fit.

Is this approach to software development raising some red flags? It should, but there’s a way to make ourselves feel better. With a strong system of unit tests in place, we give ourselves an easy way to assure that functionality remains unchanged when software updates roll out, or requirements of a component change. While the dynamic aspects of Ruby can cause us some serious headaches if we abuse this power, we can save ourselves significant work by writing small patches instead of modifying many different source files.

Conclusion

I talked about a lot of different things, and admittedly, didn’t go into a lot of depth. But if you’re curious about what it’s like to develop in Rails, check out some of the things I’ve pointed out above. For me, these 5 points have made Rails my preferred web platform of choice for small to medium-sized, database driven websites.5