Lately my favorite way to create objects in my spec suite is to use an object mother pattern. There are a number of object mother libraries to choose from (see ruby toolbox for a few), but it's such an easy pattern to implement that lately I've just been rolling my own. In this post I'll describe what I've been using recently and why I've chosen it over using gems.

I recently worked on a project that had Users who were members of Groups, and we had to figure out how to get a list of all Groups that a User was not a part of. In this post I'll describe two ways of accomplishing this: one with a subquery, and one without.

Removing subqueries may, in some cases, increase the performance of the query. If you have a subquery in an SQL statement and the query optimizer is telling you that the subquery is expensive, you can probably accomplish the same thing with regular joins and improve things a bit. The only way to tell is to run them on realistic datasets.

In my experience cross joins aren't very common, but very powerful and performant when used correctly. In this post I'll describe one example of where cross joins, also known as cartesian joins, can improve performance of your app while also improving maintainability.

In this post I will describe one way to write Jasmine tests in Coffeescript, and test javascript files written in Coffeescript that are served as part of Rails 3.1's asset pipeline.

I recently wanted to make it easier for contributors to ActiveHash to test their changes against multiple versions of Rails, with multiple versions of Ruby. My stories looked like this:

As a contributor
I want to be able to run `bundle install`, then quickly run the suite spec suite against the latest released version of rails
So that I can develop quickly using a familiar workflow

As a gem maintainer
I want to be able to run the spec suite against 3 different versions of ruby, each with 5 different versions of rails
So that I can release the gem with confidence that I'm not going to break people's apps

In this post I'll explain how I did that with a (relatively) simple shell script.

Most of the apps that I work on involve dealing with money in some form. I'm a big fan of the Money gem, which allows you to store currency values in cents in an integer column in the database, then turn it into a easy-to-user Money object. One problem I have with the Money gem is that when it converts strings to a Money object it doesn't store the original value, which makes it hard to show friendly validation messages to users.

In this post I'll explain how you can make the Money gem a bit friendlier to use. The story goes something like this:

As a customer
When I enter "$21.045" in to a money form field
I want to see a validation error saying it's an invalid amount
And I want to see "$21.045" in the form field
Because my credit card cannot be charged fractional cents
And I most likely made an error

I recently worked on an app where an admin user needed to be able to tweak an app-wide configuration settings. For example the default title for HTML pages, or the default commission for newly hired sales people. Some settings were text values, some dates, some numbers, and all had different validations.

In this post I'll explain how you can easily solve this problem using unique STI (Single-Table-Inheritance).

When I made the transition from an ASP.NET developer to a Rails developer, one of the biggest changes I noticed was that the vast majority of Rails developers I worked with paid no attention to referential integrity at the database level, and relied solely on Rails to make sure things worked as expected. Predictably, one of the biggest issues I've seen across all the production Rails applications I've worked on is data integrity - especially duplicate data in rows that should be unique, and orphaned records.

To their defense, it's actually quite difficult to add support for referential integrity with Rails, and support for it in common gems is limited. In this post, I'll explain how to:

• create foreign keys, views, procedures, functions and triggers with migrations
• call routines from Rails
• use views to back ActiveRecord objects
• hack rake db tasks to dump and load a proper schema file
• test using fixtures
• work with FixtureBuilder

In this post I'll make the case for why form-backing objects help keep your app's codebase clean and maintanable, and I'll show how to create, use and test a form-backing object.

I recently released active_hash-0.9.0 which should work with Rails 3 / ActiveModel.

If you use previous versions of Rails (down to 2.2.2) it should continue to work as before. If you have any issues, with backward compatibility or otherwise, please report them on GitHub.