Ruby on Rails
The first version of Rails was released back in 2004. Embodying the idea of "convention over configuration" it grew rapidly, attracting followers who had become weary of repeating the mundane tasks required by other frameworks. Combined with the highly dynamic nature of the Ruby programming language, the Rails conventions made for a very productive development environment.
There's no shortage of useful documentation, tutorials and blogs for you to read, but these sites stand out as being worthy of note...
One of ActiveRecord's less well known features is the
default_scopeclass method. I've just added support for deleting cards to Agile Planner. Rather than destroy users' data immediately when they click the delete button, I wanted to give them an opportunity to recover from mistakes, but it doesn't feel like the right time to implement a full undo system just yet.
On the face of it, deploying a Rails app to Heroku is very simple. You just push your Git repository to Heroku, then sit back and watch. Unfortunately it's not quite that simple when you need to put the site into maintenance mode, migrate the database, and then disable maintenance mode again.
I just deployed an app to Heroku that needs to read its data from a local YAML file in order to function. It runs fine on my Mac, but fails with a nasty exception on Heroku. Luckily, it's an easy fix...
minitest is the hot new Ruby testing framework that's included with Rails 1.9 (so actually, it's not that new, but it is hot). I've been using it with Rails for the first time, and have found it a joy to work with. In this post I'll briefly cover how to set it up, and explain why I've been enjoying it so much.
Bundler is a great way to control the versions of the gems that are used in your Ruby application, but it requires you to run Ruby scripts and tools (such as
heroku) by prefixing them with an extra command (e.g.
bundle exec rake). This is a pain, can be easy to forget, and can cause no end of subtle bugs if the script that you're running can be found outside of the bundled application, in your shell's PATH.
If, like me, you've recently discovered the wonderful speed of the
acksearch tool, you may be frustrated to find that it ignores some of your source code. Files that you know should be appearing in your search results just don't show up, as
.scssfiles to be worth searching. Well, we can fix that.
A user recently reported poor performance on one of our Rails apps. I pulled up New Relic's performance graphs and checked what was happening around the time that we received the email. Sure enough there was a massive spike over a 10 minute period in the time taken to serve a request.
The biggest news in Rails 2.3 is its support for Rack, the WSGI inspired Ruby web server interface. Of all the Rack goodness that has come along lately, the one that has me the most excited is Bryan Helmkamp's Rack::Test library, of which Bryan said "Basically, I extracted Merb’s request helper code into a small, reusable, framework agnostic library."
Many web sites are built using a variety of web applications, using different web frameworks. These sub sites share the same branding and ought to re-use the same CSS and images. How do you re-use these files within your Rails application, without the maintenance overhead of copying and pasting the code into each new application?
It's generally acknowledged to be good practice to keep your production
database.ymlfile away from your version control system. Why? So that people snooping around your version control system don't find your database password. There are plenty of examples out there that tell you how to set your production password with Capistrano, but I'm talking about the
database.ymlfile used during development.
I've been trying to persuade
git-svnto work properly with Rails plugins that are installed via
svn:externals. Whilst working out how to do it I stumbled across several great articles, but I couldn't get any of the solutions presented to work perfectly.
After a bit of head scratching I got it sorted, and wrapped the process up in a little utility called git-me-up.
God is a very neat piece of software, frequently used by Rails developers to monitor mongrel servers, and restart them if/when they crash or use up too many system resources.
Its use isn't limited purely to monitoring web servers though; you can monitor pretty much anything you like. Read on to see how to configure it to monitor the Ruby job processing daemon, BackgrounDRb.