Ooochie: A Ruby Developer’s Journal

I've recently been using Rick Olson's plugin, acts_as_paranoid, to mark records as deleted rather than actually destroying them. When I had my model acting very paranoid, I found myself wanting to ignore the 'deleted' records when validating newly created records. For instance, I have an Account model:

class Account < ActiveRecord::Base

acts_as_paranoid

#Validations
validates_uniqueness_of :subdomain
end

As it stands, when I create a new account object with a subdomain of "foo" and try to save it, it will be invalid even if the existing record with the "foo" subdomain has been marked as deleted. I needed to treat the deleted records as if they no longer existed. To remedy this problem, I overwrote validates_uniqueness_of inside acts_as_paranoid to take an option to exclude deleted records.

So after updating the plugin, I can pass the :without_deleted => true option to validates_uniqueness_of and the record will be valid if no other active records have the same subdomain. Here's the whopping 1/2 line change to the model:

class Account < ActiveRecord::Base

acts_as_paranoid

#Validations
validates_uniqueness_of :subdomain, :without_deleted => true
end

And that's it! Pretty simple change, but I found it useful. I don't know if this is something anyone else needs to do, but feel free to grab my version of acts_as_paranoid from my github repository if it helps.

Courtesy of Jade. :)

Just recently, I learned how to write my own rake tasks. My co-worker, Matt Heidemann, was nice enough to walk me through it after work one day. Everyone who is reading this probably already knows how to do this, but I figured I'd write about it anyway just for fun. My first rake task was very simple and just used system calls to tar and gzip a folder in my /vendor directory. Here's what I did to write it. (Note: the names of my folders and tasks have been changed to protect the innocent.)

First I created the rake file in my /lib/tasks directory, let's call it mytasks.rake. The first thing I want to do is describe what my rake task is going to do. Do this by adding desc before the task. Next, define the task with task :task_name and a block containing what the task will do.

Wow, that was easy. Now this task can be run by calling rake folder_zip at the command line. Sweet.

A couple things to note:
In order to access your models in a rake task, just add "=> :environment" after the task name; like this:

You can add a namespace block around your tasks if they fit into one category. So then you can call your tasks like this: rake folder:zip, rake folder:someothertask, etc.

So that was pretty darn exciting for me, since rake tasks used to be a such a mystery. There is a nice rake tutorial here that gives a much better explanation than my simple overview.

At Integrum, we do "tech-talks" every Tuesday and Thursday. A member of the team gives a short presentation about something technical so as to share his or her knowledge with everyone else. I personally enjoy these talks because it gives me an extra opportunity to learn cool stuff from my oh-so-brilliant co-workers.

This past Tuesday, it was my turn to present during tech-talk time. I never know what to talk about, so when Josh suggested that I talk about Runt, I ran with it. Last week I was introduced Runt while trying to incorporate recurring events into a project. Runt is a gem that implements recurring event patterns as described in a paper by Martin Fowler. It allows you to easily define a temporal expression, which represents a set of dates and/or times that an event will occur.

The basic idea is to define a temporal expression using one or many of Runt's temporal expression classes and then use the include? method to ask the expression if it includes a particular date. In the example below, I created a temporal expression for an event that happens every week on Thursday.

I definitely recommend taking a look at Runt if you need to work with recurring events. Below are the slides from my presentation, and here is the rubyforge site for Runt.