Ooochie: A Ruby Developer’s Journal

I'm using the Workling Plugin with Starling on my project at Boost to run processes in the background. Recently, we deployed 2 projects on the same server, and rather than run 2 separate instances of Starling, we just let both apps talk to the same Starling instance. All was well with the world until I noticed that one of my apps was mysteriously creating records in the other app's database. Burn! It appeared that Starling didn't know which app the processes belonged to, so it was always running them on 1 app and never the other one. Eeek!

Thankfully, this was easily remedied by revisiting the options for my workling.yml file in the Workling README:

Workling copies a file called workling.yml into your applications config directory. 
The config file tells Workling on which port Starling is listening. 

Notice that the default production port is 15151. This means you'll need to start 
Starling with -p 15151 on production. 

You can also use this config file to pass configuration options to the memcache 
client which workling uses to connect to starling. use the key 'memcache_options' for this. 

You can also set sleep time for each Worker. See the key 'listeners' for this. 
Put in the modularized Class name as a key. 

    development:
      listens_on: localhost:22122
      sleep_time: 2
      reset_time: 30
      listeners:
        Util:
          sleep_time: 20
      memcache_options:
        namespace: myapp_development
        
    production:
      listens_on: localhost:22122, localhost:221223, localhost:221224
      sleep_time: 2
      reset_time: 30

See that key under memcache_options? Namespace to the rescue! If you set this in your workling.yml file, your Starling instance will never be confused again. Just a quick tip so you don't get burned like I did. Good luck!

Today is Ada Lovelace Day - "an international day of blogging to draw attention to women excelling in technology." I only just found out about it, so unfortunately I don't have an article prepared, but I wanted to help by raising a little awareness and inviting you to go read some of the articles that have been published today in honor of women in technology. Here are a few to get started:

• Ada Lovelace Day - Finding Ada by Desi McAdam
• Ada Lovelace Day heroine: Valerie Aurora by Mackenzie Morgan
• Celebrating Ada Lovelace Day by Audrey Eschright
• Ada Lovelace Day - Grace Hopper by Brenda Wallace
• Ada Lovelace Day by Liz Henry
• Ada Lovelace Day: Tribute to Suw Charman-Anderson by Kevin Anderson (Husband of Suw Charman-Anderson, creator of Ada Lovelace Day)

There are several more links to articles on the pledge website. Even if you don't sign the pledge or write a post, today I encourage you to think about all the tech women you know & celebrate them. :)

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.