EdgeCase - Home

Make Ajax File Uploads Sexy (screencast)

2009-06-25T00:40:00Z

Last week I showed you how to perform file uploads via Ajax, but the result was too ugly for my taste. Today we're going to make it sexy. Check it out.

The source code for the example app is here.

Next week I plan to dive into using Flash to enable selecting and uploading mutiple files with progress indication. Stay tuned.

Ajax File Uploads Made Easy (screencast)

2009-06-15T14:18:00Z

Here is my second screencast for the EC blog, this time talking about Ajax file uploads in Rails using jQuery. Let me know what you think in the comments.

A Non-Flash version is available here. The plugin discussed is on Github.

update: I decided to turn this into a series of screencasts on how to handle file uploads on the client side. Part two is now available, which builds on this example.

A Rant About Testing

2009-06-02T13:51:00Z

Time to stir up some controversy. It’s been a while since I’ve posted, so why not come back with a bang. Disclaimer, though: these are only the opinions of me, Adam McCrea, and not of EdgeCase.

TATFT

There’s a meme going around for a while that’s gained a lot of popularity, and I for one would like to say that I do not, nor do I have any desire to Test All The Time. Being religious about testing is a recipe for brittle tests, wasted effort, and a false sense of security. I’d rather shift from religion to pragmatism. This means thinking hard about what and when we test.

In a few recent projects, I’ve begun heavy integration testing. No, I’m not breaking any new ground, but the fact is prior to these recent projects, I had no integration tests. I was a bad, bad little programmer. That aside, I have to say that it’s been incredibly eye-opening.

I like to test as far up the stack as I can, getting as close as possible to the end user. Right now that means using Webrat to mimic actual clicks and form interaction to navigate the app. Sticking to this approach, I can change the internals of the app however I want as long as the generated HTML for links and form fields remains untouched. If you had told me a few months back that I could substantially refactor my code and not change one test, I would have thought you were crazy. But integration tests make that possible.

Less testing

But how does that reduce waste? For starters, I no longer write controller (or view) tests. And neither should you. Seriously, just stop. You’re not only wasting your time, but also every future developer who touches that code and has to maintain your useless tests. This assumes two things: that you’re thoroughly integration testing your app, and that your controllers are as skinny as possible. If you still think you need controller tests, you’ve probably got crap in your controllers that shouldn’t be there. Get it out, and stop writing those tests.

I’ll proudly admit that I’m also testing my models a lot less. Seriously, what’s the point of testing things like attribute readers/writers and associations if I’ve got a full suite of integration tests? If my comments don’t belong to posts, I’ll get yelled at, and it’s not going to take long to pinpoint the problem. So, I’m really only unit testing substantial model and helper methods. Everything else gets hit at the integration level only.

What about coverage?

I still think coverage is important, but only at the integration level. Whether or not a piece of code is unit tested is purely subjective, but every line of code must be tested from the point of view that matters most – the user’s. 100% integration test coverage is no guarantee that you’ll catch every possible bug, of course, but anything less would indicate that you wrote some code without thinking about how it will be used.

So is Cucumber the answer?

Honestly, it just doesn’t matter. Just test your code from as far up the stack as possible using whatever tool you prefer. Cucumber, Rails integration tests, Selenium, well-trained monkeys, whatever. Go for it. I do like Cucumber, though, so it’s certainly worth a try if you’re new to full-stack testing.

Ideally, JavaScript would be included in these tests, I just haven’t found a solution yet that makes it practical. It would require a masochist to get 100% coverage with Selenium, but Culerity is one promising option that has popped up. I haven’t had a chance to check it out, though.

This approach certainly isn’t for everyone, but the current wave of TATFT is in desperate need of a counterpoint. If you like to use unit tests as a way to design your code, you probably think I’m way off base. That’s fine. We don’t all have to play by the same rules. Hell, even I still TDD, just not at the unit level. The point here is to make sure you’re very conscious of what, when, and why you test, and that you’re getting enough value from them to justify the time spent.

Bookmarklets 101

2009-05-11T12:37:00Z

Last week I showed you a bookmarklet that lets you edit your CSS live in any browser. Today, I want to dive into the details of how to create a bookmarklet. But first, the basics:

What is a bookmarklet?

A bookmarklet is a small snippet of JavaScript crammed into a URL. Nothing else. That's not very helpful, though, is it? All it means is this: instead of using the http: or ftp: protocol for a URL, we use the javascript: protocol. And when this URL is invoked (perhaps by clicking a bookmark in your browser's bookmark toolbar) the remainder of the URL is executed as JavaScript. What this means is that we can execute any arbitrary JavaScript within the context of any site we please. And we can package it so that it can be shared and reused easily. But...

What is the point?

In general a bookmarklet will either alter the current page in some way, or make use of the context of the current page in concert with some other service. Some examples of the former are edit CSS, jQuerify, Firebug Lite, and 960gs grid overlay. These are usually only useful to developers. Some examples of the latter are URL shorteners, post to delicious, Amazon wishlist, and Instapaper. These are much more useful to consumers. Both kinds of bookmarks use the same technology, though, so the approach to developing them is basically the same.

The "Hello World" bookmarklet

Create a bookmark, and give it the following URL:

javascript:alert('hello%20world');

Now click the bookmark. Yep, that's all there is to it. Notice that we replaced the space with %20. That's important, and there are a few more rules that we need to keep in mind when creating bookmarklets.

Gotchas & Tips

URL length limit

I'm not sure what the definitive answer is on this. IE is (unsurprisingly) the limiting factor here, but I've heard conflicting information on what the actual limit is. I haven't bothered to test it since that would mean firing up Windows and opening IE, which I avoid at all costs. So, just keep it really really short, m'kay?

Cheat the URL limit

Most bookmarklets try to do way more than is possible within the URL limit I just described, so of course there is a way to cheat the rule. Just host an external JS file that gets dynamically required by your bookmarklet. Here is an example. The bookmarklet just appends a SCRIPT tag into the HEAD of the document, which requests and executes the external JS file.

Don't return a value

If your bookmarklet code returns a value, that value will find it's way to the browser's address bar. This is most likely not what you want, so you have two weapons to use against this. You can append a void() call at the end of your JS code:

someCode();void(0);

Or you can wrap your JS in an anonymous function. The added benefit here is that any variables you define are not polluting the global scope:

function(){someCode()}();

Don't depend on a JS library

Probably an obvious one, but you can't assume that jQuery, Prototype, or any other library is included in the page where your bookmarklet will eventually be run. I got around this in my Edit CSS bookmarklet by dynamically including jQuery and running it in noConflict mode. See the code for that here.

Next steps

If you want to write a bookmarklet that integrates with a Rails application, definitely check out John Nunemaker's screencast. Also dig into the bookmarklets that I linked to earlier in the article. If you have a favorite bookmarklet or want to know more about bookmarklets, please join the discussion below.

Edit CSS in Any Browser With the Click of a Button

2009-05-04T12:22:00Z

So, a few weeks back I showed you how you could see your CSS changes in real-time in any browser. That was cool and all, but I haven’t found myself using it simply because of the convenience factor. The script (along with jQuery) had to be included in the page, whereas I could just fire up Web Developer Toolbar in an instant.

Today I’m introducing the bookmarklet version of that same script. It no longer requires jQuery, so just drag the link below up to your bookmark toolbar, and you’ll have this functionality one click away.

Edit CSS

I’ve also put together a short (3-minute) demo below. Enjoy.

Non-Flash version of screencast is available here (the Files and Links section in the sidebar).

The source for this is on Github, so please add issues there and fork away.

Best CMS For Developers? Rails.

2009-04-27T12:36:00Z

The site you’re looking at right now (unless you’re reading from RSS) is old, ugly, and busted. Yes, the EdgeCase site – and blog – are in desperate need of an overhaul. While @nummi kicks around some design ideas, I’ve started looking into how to power our future home on the web.

Our needs are pretty simple. We need a collection of pseudo-static pages (occasional updates, but with some dynamic content), and a blog. This sounds like a simple CMS to me, and CMS solutions are supposed to make sites like this completely painless, right?

Yes, I am that delusional.

You see, I’ve never actually used a CMS. Everything we’ve built at EdgeCase has been far too custom to be considered a CMS, so until last Friday, I’d really only heard about them. Unfortunately, what I discovered after looking at some popular Ruby CMS solutions (Radiant and BrowserCMS) is that I hate CMS systems.

A CMS might make a lot of sense for a business of non-techies – regular folks who need to manage their content without calling up the “web guy”. But that’s certainly not us. We’re an entire company of “web guys”. At this point you might be thinking I’m ignorant for not realizing we’re outside the target audience for a CMS, and you’re right. But I didn’t realize this, so I’m going to rant for a bit on why CMS systems suck for developers.

The problem is that the benefits regular users get from a CMS just don’t apply to developers, and in fact they often cripple us. Take the most obvious CMS feature of editing your site content within a browser. Is there a developer out there who is as comfortable in an HTML textarea or a Word-like WYSIWYG as they are in their preferred text editor? But really this is the tip of the iceberg, a minor issue that I can get over, and I also can’t deny the convenience of committing a content change with the click of a single submit button.

But going a step further, most CMS systems also make the templates available for editing within a browser. This is where real pain sets in for me, and for two reasons: bastardized templating languages, and lack of a real editor. As a Rails developer, I’m very comfortable with ERB, and even more so with HAML. I should not have to learn a new templating language just to build my simple website. And regardless of which language I use, I simply don’t have the patience to code HTML in a textarea. I may not be a fan of editor wars, but I at least need an actual text editor if I’m building a website.

Other CMS niceties… Content versioning? If the content is part of the code base, I get that for free with Git. Permissions? Our needs are simple – if you have access to edit the code, you have access to edit the content. Plugins? Rails certainly has plenty of plugins, and with Rails 2.3 supporting Rails Engines and Rack middleware, the possibilities are endless.

So where does this rant leave me for the EdgeCase site? A Rails app, of course – custom built, because I’m not convinced that anything pre-built is actually going to make my life easier.

For the blog component of the site, I’ve got a lot of options to explore. I could, of course, build something from scratch. This might not be a bad idea, since our needs are pretty simple. But there are also some blog engines out there that could be worth checking out: Marley and Scanty are a couple that look very interesting. I’d love to see an engine-style Rails plugin that provides a blog, but I haven’t come across one yet. Perhaps we’ll just have to build one ourselves. After all, a blog can be built in 15 minutes, right?

Follow me on Twitter if you want updates on what direction we take. Or you could just wait for the redesigned EdgeCase site. It should arrive on or before 2011.

Debugging jQuery Events

2009-04-22T12:49:00Z

When an app reaches a certain level of complexity, particularly with regards to JavaScript, you’re probably going to have events bound and triggered all over the place. Events are a powerful thing, but they can be a bitch to debug.

This didn’t use to be the case. Back when we were all setting events inline, all you had to do was look at the HTML to know what events are bound to to an element:


<form onsubmit="if (!validate(this)) return false;">...</form>

I’m going to give you the benefit of the doubt that you’re not doing this anymore. I’ve been writing (and evangelizing) unobtrusive JavaScript for years now, but I have to admit this is one aspect of inline event handling that I really miss.

Take this scenario:

You’ve given a form a class of “ajax”, and you’ve got the following jQuery in place to make sure that all forms with a class of “ajax” are submitted via Ajax.


$('form.ajax').ajaxForm();

Unfortunately, when you try to submit the form, nothing happens. Nothing at all. No Ajax. No form post. No errors.

What do you do?

In the past, I’d start sticking console.log statements in my JS, or maybe debugging directly in Firebug. Recently, though, I found a better way. I was fumbling my way through the event code in jQuery, and I discovered that event data is easily accessible through the element itself. Here is how a Firebug session might look as I dig into these events:

The first thing I do is grab the form element, and see what it has in the “events” data (if you’ve never messed with the data() method before, you should ). I see that there is at least one handler assigned to the “submit” event, so I iterate through each of them and call toString() on each function so I can see the actual code.

The second function listed is the actual code for the ajaxForm() method, so it’s cool. The first one, though, is the culprit I’m looking for. This handler is being bound to my form’s submit event somewhere, and it’s calling stopImmediatePropagation() which prevents any other handlers from being called. Then it’s just a matter of searching for that exact code in the project, removing or fixing it, and beating the developer who put it there (which is usually me).

I admit this is not as easy as glancing at the HTML and seeing the event handler code inline, but it at least gets the job done. Any other tips for debugging events, please share in the comments!

Show Off Your Mockups

2009-04-14T19:44:00Z

Whether you’re a do-it-all designer/developer or if those roles are separate, odds are your typical workflow involves taking a static HTML mockup and wiring it up with all your crazy codes.

So, maybe you’ve got an HTML file with a bunch of dummy data in it that you need to demo for a client. You probably stuck it somewhere in /public because it’s easy. It’s probably got a list of copy-and-pasted garbage in there, too, so it looks like a “real” page with lots of data. And of course there’s the header, footer, and other layout cruft you had to add so it fits the look of the rest of the application.

You’ve gotten some feedback from your client, and made some tweaks to the design. It’s looking pretty good. You’re feeling pretty good. Now it’s time to wire that page into the application.

Still feeling good?

This is the part that sounds so easy until you have to dive in and do it. It’s painful and tedious, but the good news is, it doesn’t have to be. It’s time to let Showoff come to your rescue.


  script/plugin install git://github.com/adamlogic/showoff.git
  script/generate showoff

This plugin is an extraction from a recent project where I got tired of dealing with this same old scenario. I wanted a place where I could stick mockups without thinking about it. I wanted my mockups to use the same layout, CSS, and JavaScript that the rest of my application does. I wanted to be able to use Ruby in my mockups to have access to looping, variables, and data generation (Faker). I wanted partials in my mockups. And I wanted a single place to go where the client and development team could see all of the mockups.

After installing and generating Showoff, navigate to /mockups in your app to see some examples. To make your own, just create a file in app/views/mockups. You can use HTML, ERB, or any other templating language (such as HAML) that your application supports. Yes, it really is that simple.

Here is an example in a fresh Rails app with Ryan Bates’ nifty_layout applied:

I’m sure Showoff isn’t the first plugin to attempt to simplify this process, but I can tell you that it’s working really well for us. Check it out and let us know what you think.

Update: I should also add that this plugin requires Rails 2.3, since it makes use of an engine-style plugin. This basically lets you embed one “mini app” inside of your main app. It’s pretty powerful, and I’ll write more about my experience of extracting this plugin in a a future post.

See Your CSS Changes in Real-Time in Any Browser

2009-04-06T18:53:00Z

I’ve wanted to scratch this itch for a while, and this morning I decided to steal a few hours to give it a shot. Most of my CSS authoring and editing takes place in Firefox, using Web Developer Toolbar. For me, seeing CSS rendered in real-time is the only way to write it. (This is one reason I had to pass on Sass, even though I love Haml, but that’s a topic for another time.)

This has come major shortcomings, though, since Web Developer Toolbar is not intended to be a text editor (nor should it be). The biggest pain is saving your changes. A save button is provided, but you have to navigate through your filesystem to find the right location. If you’re lucky this location will be remembered next time you save. Support for find and undo is shaky at best, and as a Vim user, there about a thousand other features that I “need” in my text editor.

The other problem with Web Developer Toolbar is that it is Firefox-specific. On days that I have to debug my CSS in IE (my “hating life” days), I’m back to the refresh button.

Today I may have found a solution.

I say “may” because I literally just wrote this. I’ve tested it a little bit, but I can’t claim to have used it for real project work. Nonetheless, I’m pretty damn excited. Twenty minutes ago I had three browsers open (IE, Safari, and Firefox), and saw all three of them update as I saved my CSS file in Vim.

Check it out on Github and let me know what you think. As long as you’re using jQuery, using it is as simple as dropping in the .js file and calling $.autoUpdateStylesheets.

My next steps are to pull this into a bookmarklet and remove the jQuery dependency. Then it’s just a matter of pushing a button and editing away in your favorite text editor. Enjoy.

(oh, and this should work with Sass, too, so I guess it’s time for me to take another look.)

Seeding Your Development Database with Faker and Factory Girl

2009-03-30T17:41:00Z

For the longest time, I’ve used fixtures as a means to seed some basic data in my development environment. The goal is to put the application in a useable state without having to manually create data (such as users or anything else required to run the app). In my most recent project, however, I’ve completely abandoned fixtures, and I doubt I’ll ever look back.

I felt two kinds of pain with fixture data – the pain of maintaining it and the lack of quality data.

The pain of maintaining fixtures was usually bad enough (and I was lazy enough) that I typically just ignored it altogether. With every change to the schema, more data had to be added or changed. And not just one place, since a fixture usually contains several records. I just don’t have the patience for it.

Due to my lack of patience, fixture data in any of my projects has been completely unreliable. I’ll leave out fields that end up being required. Or I’ll only put one record in a fixture file because I’m too lazy bother with more.

I put up with this pain for too long. The ability to quickly seed a development database with valid, useable data is a big deal, and I was done ignoring the problem. Enter Faker and Factory Girl.

You probably already know what Factory Girl is, but in case you don’t, it’s just another factory implementation, and it happens to be my preferred implementation at the moment. If you prefer another, I’m sure it will work just as well with what I’m describing here.

Faker is a Ruby library for generating pseudo-random data. Typically, this is exactly the kind of data that I want in my development database. Repeatability isn’t that important. Faker will generate names for people and business, addresses, phone numbers, Lorem text, BS, and more. I use Faker in my factories as a template for pseudo-random models:


Factory.define :user do |u|
  u.email { Factory.next :email }
  u.email_confirmation { |u| u.email }
  u.password 'test'
  u.password_confirmation { |u| u.password }
  u.first_name 'Test'
  u.last_name 'User'
end

Factory.define :user_sample, :parent => :user do |u|
  u.first_name { Faker::Name.first_name }
  u.last_name { Faker::Name.last_name }
end

Here, the ‘user’ factory is used in tests. It doesn’t use Faker, because I need my tests to be consistent and repeatable. The ‘user_sample’ factory, however, inherits the ‘user’ factory and uses Faker to generate the name.

Once I have my factories ready to go, I create a custom Rake task to seed my development database:


namespace :db do
  desc 'Provide a base load of randomly generated (but valid) data for development'
  task :seed => [:reset, 'fixtures:load'] do

    # generate users
    users = []
    6.times { users << Factory(:user_sample) }

    users << Factory(:user, :email => 'user@edgecase.com', :role => 'user')
    users << Factory(:user, :email => 'admin@edgecase.com', :role => 'admin')

    # generate orders
    20.times { Factory(:order_sample, :user => users.rand) }

    # login instructions
    puts "\n**************\n\nThe following accounts are available for use:\n\n" 
    puts '  user@edgecase.com (password: test)'
    puts '  admin@edgecase.com (password: test)'
    puts "\n**************\n\n" 

  end
end

With this in place, I can run rake db:seed, and I’ll get a nicely bootstrapped development database to poke around in. Each order will belong to a random user with a random name. It’ll be different every time you run it. It’s like a box of chocolates. Or something.

Want more users? Change 6 to 60. Lovely.

Notice that db:seed still has db:fixtures:load as a prerequisite. This means that fixtures are still an option if I want to combine them with my custom seed task. Nice as that sounds, I haven’t used it. Fixtures are, for me, but a memory.

Better Flash and Validation Messages

2009-03-23T16:15:00Z

In Rails, there are two common types of messages that we show on a page. Flash messages, which are page-level messages telling the user that something has happened. And validation messages, which are specific to a form that the user filled out (actually, they are specific to a model, but we’ll focus on the user’s point of view).

I rarely see these messages presented in a way that satisfies me. My two big complaints are separation and language.

Separation

I’ve always been bothered at typical Rails apps (including many of ours) that separate flash messages from validation messages, often with completely different styling. In my mind they are slight variations of the same thing: informational messages for the user. They should be shown together, in a consistent location, and with the same styling.

The reason they are typically separate is purely implementation. Flash messages are set in controllers in usually spit out in an application layout file. Validation messages come from model objects and are usually spit out within forms. Rails makes it very easy to do this, and many Rails tutorials promote this separation.

Come together, right now…

Just because it’s easy doesn’t make it right, but I’d much rather have both. Recently I’ve found the message_block plugin that combines flash and validation messages and spits them out in a single div. It’s easy to use and does exactly what it claims. The README is pretty self explanatory, so go check it out.

Language

The validation messages that come packaged with Rails are very convenient. Purely based on the column name and the validation method, Rails can generate an error message that is logically correct. Unfortunately, they are rarely user-friendly.

“User Experience is invalid.”

“Please is not included in the list.”

“Context can’t be blank.”

These are all examples of out-of-the-box validation messages. If you don’t see a problem with them, I probably can’t convince you there is. It’s totally a matter of personal preference.

Now, you’re probably thinking that there is a built-in way to customize validation messages, and you’re half right. The problem is that you can’t customize the full message.

validates_presence_of :city, :message => 'Please enter the city.'

This code will produce the following message:

“City Please enter the city.”

Uh oh. Rails only lets you customize the latter half of the error message. In many cases, and for many developers, this is good enough. But not me. Much like a designer wants control over every pixel, I demand control over every word. Enter custom-err-msg. With this plugin, I can have full control over the message by prepending ’^’.

validates_presence_of :city, :message => '^Please enter the city.'

Problem solved.

These are two plugins I’ll be using in every project from here on out. I think my users will appreciate it.

Learning Ruby Through Testing

2009-01-26T20:54:00Z

We have finally published the Ruby Koans to github at edgecase/ruby_koans If you do not have a github account or use git, do not worry, you can click the download button on that page to receive a zip file containing the latest version of the source.

The idea was born thanks to Mike Clark’s blog post about learning Ruby through unit testing. It teaches both language and culture in a self-paced manner.

We look forward to comments and any feedback you have. Enjoy!

CodeMash wrap up coming

2009-01-14T01:58:00Z

We promised a posting on our Ruby stuff from CodeMash and it is not here yet. We are polishing a few items for the Koans and will post them up when they are finished.

If they are not up by Friday you have permission to harass us :-).

When Burnt Out

2008-12-12T21:53:00Z

Goof off. It helps.

Written by me. Firefox 3 only. Control and shift for the left paddle, arrow keys for the right paddle.
download src (html and javascript)

Damn The Standards And Full Read The Documentation!

2008-10-31T13:12:00Z

Do not let conventions prevent correct behaviour.

Often within an ActiveRecord::Base model, statements of a certain ilk are grouped together. For example the single line validations are often in the same place. It is tempting to place additional statements such that the model file is consistent. One might put all the before_destroy callback macros near the before_save or after_save statements.

Without loss of generality the following example models illustrate a behavioural anomaly that was encountered.

ActiveRecord::Schema.define(:version => 1) do
  create_table "accounts", :force => true do |t|
  end

  create_table "invoices", :force => true do |t|
    t.integer "account_id" 
  end

  create_table "receipts", :force => true do |t|
    t.integer "account_id" 
  end
end

class Account < ActiveRecord::Base
  has_many :receipts, :dependent => :destroy
  has_many :invoices, :dependent => :destroy
  before_destroy :ensure_no_invoices
  def ensure_no_invoices
    return true if invoices.empty?
    false
  end
end

class Invoice < ActiveRecord::Base
  belongs_to :account
end

class Receipt < ActiveRecord::Base
  belongs_to :account
end

The intent is to prevent the destruction of an account and related models when the account still has at least one invoice. The above code is how not to do it. The following sandboxed example demonstrates that the account will not be destroyed but that associated models will be.

test_before_destroy> ./script/console --sandbox
Loading development environment in sandbox (Rails 2.1.1)
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 1>
>> account.invoices.create
=> #<Invoice id: 1, account_id: 1>
>> account.receipts.create
=> #<Receipt id: 1, account_id: 1>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
=> false
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 0, 0]

The Rails documentation on before_destroy can be found on the callbacks entry. There is a vital clue stated there.

*IMPORTANT:* In order for inheritance to work for the callback queues, you must specify the callbacks before specifying the associations.  Otherwise, you might trigger the loading of a child before the parent has registered the callbacks and they wonâ€˜t be inherited.

The documentation mentions only “inheritance” but further experimentation reveals that the desired behaviour of not destroying a model and related models is obtained when the documentation is heeded.

class Account < ActiveRecord::Base
  before_destroy :ensure_no_invoices
  has_many :receipts, :dependent => :destroy
  has_many :invoices, :dependent => :destroy
  def ensure_no_invoices
    return true if invoices.empty?
    false
  end
end

Here the before_destroy macro is written before the associations. This is how to do it.

test_before_destroy> ./script/console --sandbox
Loading development environment in sandbox (Rails 2.1.1)
Any modifications you make will be rolled back on exit
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 2>
>> account.invoices.create
=> #<Invoice id: 2, account_id: 2>
>> account.receipts.create
=> #<Receipt id: 2, account_id: 2>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
=> false
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]

Interleaving the before_destroy macro between the associations allows the destruction of one associated model but not the other.

class Account < ActiveRecord::Base
  has_many :receipts, :dependent => :destroy
  before_destroy :ensure_no_invoices
  has_many :invoices, :dependent => :destroy
  def ensure_no_invoices
    return true if invoices.empty?
    false
  end
end

test_before_destroy> ./script/console --sandbox
Loading development environment in sandbox (Rails 2.1.1)
Any modifications you make will be rolled back on exit
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 3>
>> account.invoices.create
=> #<Invoice id: 3, account_id: 3>
>> account.receipts.create
=> #<Receipt id: 3, account_id: 3>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
=> false
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 0]

class Account < ActiveRecord::Base
  has_many :invoices, :dependent => :destroy
  before_destroy :ensure_no_invoices
  has_many :receipts, :dependent => :destroy
  def ensure_no_invoices
    return true if invoices.empty?
    false
  end
end
test_before_destroy> ./script/console --sandbox
Loading development environment in sandbox (Rails 2.1.1)
Any modifications you make will be rolled back on exit
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 4>
>> account.invoices.create
=> #<Invoice id: 4, account_id: 4>
>> account.receipts.create
=> #<Receipt id: 4, account_id: 4>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
=> false
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 0, 1]

Note that when the before_destroy macro is declared after the associations and the specified check raises an exception, the script/console sandboxed environment does not rollback the destruction of the associated models because of the transactional nature of the entire script/console session.

class Account < ActiveRecord::Base
  has_many :receipts, :dependent => :destroy
  has_many :invoices, :dependent => :destroy
  before_destroy :ensure_no_invoices
  def ensure_no_invoices
    return true if invoices.empty?
    raise RuntimeError.new('Attempted to destroy account that still had invoices!')
  end
end
test_before_destroy> ./script/console --sandbox
Loading development environment in sandbox (Rails 2.1.1)
Any modifications you make will be rolled back on exit
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 5>
>> account.invoices.create
=> #<Invoice id: 5, account_id: 5>
>> account.receipts.create
=> #<Receipt id: 5, account_id: 5>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
RuntimeError: Attempted to destroy account that still had invoices!
        from ... (irb):6>> [Account.count, Invoice.count, Receipt.count]
=> [1, 0, 0]

When script/console is executed without the sandbox option, the effects of a rollback can be observed upon the attempted destruction of an account with invoices.

test_before_destroy> ./script/console          
Loading development environment (Rails 2.1.1)
>> [Account.count, Invoice.count, Receipt.count]
=> [0, 0, 0]
>> account = Account.create
=> #<Account id: 6>
>> account.invoices.create
=> #<Invoice id: 6, account_id: 6>
>> account.receipts.create
=> #<Receipt id: 6, account_id: 6>
>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]
>> account.destroy
RuntimeError: Attempted to destroy account that still had invoices!
        from ... (irb):6>> [Account.count, Invoice.count, Receipt.count]
=> [1, 1, 1]

Read the documentation.

Put the before_destroy macro before associations.

The sandbox option in script/console may mask rollbacks.