Chovy's Blog

Start deploying your application immediately…even if it is just from your local development environment to a QA environment. You’ll save yourself the headache of having to learn all that when you’re ready to release to production.

Always use source control, like subversion or git. This is a no-brainer, but people still ask why. You’ll be happier when you start deploying with revision control in place.

Always backup your files and databases — another silly mistake often overlooked.

MVC (Model View Controller) is a great way to ensure maintainability on a progressively complex web application project.

Small revisions are great for saving on debugging time required…many refer to this as “iterative development”. Fix a broken link or image, add one or two useful features, then test and deploy.

Writing version 1.0 before ever deploying to a different environment will ensure you’ll spend a few days debugging things you never thought were a problem on your local environment.

Validating your form fields and user-supplied data is mandatory in the age of web vulnerabilities and XSS (Cross Site Scripting) exploits.

REST is a great convention enabling your web apps to be relatively static in the URLs they generate.

Do not wait long periods of time between releases. RoR is a fast, dynamic framework that has a very aggressive time line. Even a month after you’ve got your environment setup and working, things can (and will) change in the next release. Stay on top of these releases as appropriate — make sure your production server is up to date as well. For shared hosts, don’t upgrade past the version they support unless you’re ready to jump through hoops.

Example 1: Writing your own sort routine

I originally tried ‘sort_by’, but that only works for existing attributes and apparently in only one direction.

My ‘is_default’ attribute is setup as a boolean and is almost always false, except where I define an image as being the default for a given product.

Converting a boolean to a string and then sorting alphabetically in reverse order is not something I liked nor recommend, but it was the first thing that I got working.

The Admin helper:

module AdminHelper
  def sort_my_pictures(pics)
    pics.sort {|a,b| b.is_default.to_s  a.is_default.to_s }
  end
end

Example 2: Define your own sort method available from the object instance

Defining a method on the model itself is was an improvement over Ex. 1, but still rather cumbersome to have to call it everywhere to get the sorted list of pictures. Definitely starts to break the DRY principle.

I like this method as an alternative because it can be a convenient way to override default sorting as defined in Ex. 3.

The Picture model:

class Picture  'created_at DESC, title DESC, filename ASC')
end

Example 3 (best): Define the ordering when declaring the relationship

I was positive there was a one-liner to do what I wanted, but could not figure out how to word my question or search to reflect what I needed.

FYI: “How do I define the order when declaring a has_many relationship between models with Rails?” would have worked well. Hindsight is 20/20.

The convenience of MVC is starting to come to light!

The Product model:

class Product  'is_default DESC, title'
end

Capistrano is one of those problem solving apps that can be tricky to setup at first, but is a no-brainer once you’ve deployed with it.

I added a few notes about hosting on Dreamhost because they only support rails 2.2.2 at the time of this writing. My current app is actually developed under 2.3.2.

With Dreamhost, you only get a RAILS_ENV=’production’ setup on Passenger hosting…but that is good enough. I prefer to run test.the-app.com locally anyway.

If an app of mine gets popular, I would move it off of dreamhost regardless ( security, reliability, etc ). Try slicehost or linode if you’re looking for a more professional web hosting solution.

#create the_rails_app_production database
#setup db.the-rails-app.com db server
#setup domain the-rails-app.com to look in ./current

#!/bin/bash
cd ~/the_rails_app
mkdir config/deploy
for e in 'staging production testing'; do touch config/deploy/$e.rb; done;

echo '#!/bin/bash' > script/spin
echo 'touch tmp/restart' >> script/spin && chmod 755 script/spin

# dreamhost only:
# change config/environment.rb to require rails 2.2.2
# change config/database.yaml (production:) and delete the socket ref for mysql
# add symlink to older application.rb controller

svn ci -m 'initial capify'

capify .
cap deploy:setup
cap deploy:check
cap deploy:update #fix all errors until this succeeds
cap deploy:migrate #initial migration of db
#if using 2.2.2 be sure to symlink application_controller.rb to application.rb

cap deploy:start

# if you modify anything, be sure to checkin and deploy:update again

I have tried both mongrel and passenger rails hosting on Dreamhost.

Here are some pitfalls I found:

• no clustering (mongrel_cluster not installed)
• one proxy per app
• one mongrel per app
• apache + fastcgi works fine on the shared host plan
• PrivateSersver is 3 times the cost for 1/4 the performance
• your rails environment is *always* production
• they refuse to switch people back to shared.

I have about 30 domains, not a huge amount of traffic, well under “unlimited” … and now I’m paying $30-60/month for what cost me $10 before, nothing much gained from a rails standpoint, because I can’t host multiple environments anyway. The default environment supported for Passenger implementations is “production” — you could override that in the application’s configuration file, but it goes against the principle of easy deployment to any environment.

The disk reports as full at my usage of 6.1 gigs out of my 351 gigs allowed and I’m constantly getting “DISK QUOTA” errors to which they reply — “Naah…check your again.” After repeated emails, they ask what the command was again that caused the error (pasted in original ticket).

I have since started developing a rails app for Link directories on a Slicehost server instead, although the basic package is fairly limited (256mb ram) it handles pretty well with low traffic.