Doug McInnes

I made a post on the Gem Install That blog detailing the simple_admin plugin which adds a simple authentication scheme to your Ruby on Rails application.  It stores usernames and passwords in a YAML file to make it extra easy.

Reid also posted on Gem Install That about another plugin we worked on, Subselector, which extends ActiveRecord to give it subselection capibilities.

Another Ruby on Rails plugin that I’ve developed at the Los Angeles Times is cached_resource.

In a nutshell cached_resource automagically caches ActiveResource response objects in a memcached instance.  The plugin requires cache_fu for memcached configuration goodness.  See also: Kickin’ ass with cache-fu.

The code for cached_resource is also up on GitHub along with a many other Los Angeles Times plugins and other tidbits.  You can find it here: http://github.com/latimes/cached_resource/tree/master

So, how do you get it to work?  After dropping the plugins in vendor/plugins, set up your cache_fu configuration then drop this single line in any of your ActiveResource models:

class MyClass < ActiveResource::Base
  cached_resource
end

The cached_resource call also takes normal cache_fu options:

class MyClass < ActiveResource::Base
  cached_resource :ttl => 15.minutes
end

So now every time you run a .find() on MyClass the results will be cached for the next time you do the same kind of find.  The cache key is the URI of the ActiveRecord generated REST query.

In addition, if you do MyClass.find(:all) or the like to get a list of resources, individual instances in the returned list will be cached separately and the list itself will be distilled down to IDs before it’s stuffed in its own cache bucket.  When pulled from the cache the list will be reconstituted by pulling the individual objects from the cache by ID or making additional ActiveResource queries to get objects that have fallen out for one reason or another. The upshot of this is you’ll have less of a chance of stale data between mixed finds.

The cached_resource plugin makes some assumptions about how your REST service is set up.  If the REST service you’re pointing to with ActiveResource are wacky, i.e. not conforming to exactly what ActiveResource expects its URLs to be, this plugin will probably not work for you.  That said, if you can do normal finds with IDs, like MyClass.find(123), you’ll probably be fine.

This plugin was written before memcached support was baked into Rails 2.1 so if anyone wants to fork and get it working please be my guest!  I’ll be happy to pull it back in

Credit where credit is due: Josh Kleinpeter originally came up with the cached_resource concept and Subba Rao helped to lay the groundwork.

This is the first of hopefully many (a few?) Ruby on Rails plugins I’ve created as a developer for the Los Angeles Times.

This one is called Craken.  In a nutshell it manages and installs rake-centric cron jobs.  Coupled with Capistrano goodness it is the answer to your recurring task needs in Rails.

It’s up on GitHub: http://github.com/latimes/craken/tree/master

Here’s the deal: with many web applications comes the need to do recurring tasks on the servers the application runs on.  These sorts of tasks can range from running backups, clearing caches, emailing notices and other such maintenance-y things.

Who manages these tasks?  Ideally the task code as well as configuration and timing should be kept with the source code of the application itself and not as part of some further set of scripts that reside in a dubious location in your source control.  This is what Craken does.

The tasks are defined as rake tasks within the application.  Craken itself is a rake task that sets up a crontab for defined tasks based on your current application configuration.  The plugin also includes a Capistrano recipe that runs the Craken rake task on remote servers making deployment a breeze.

Craken, by default, looks for recurring task definitions here:

RAILS_ROOT/config/craken/crontab

You can also define tasks for a particular machine by prefixing the machine name (separated with an underscore):

RAILS_ROOT/config/craken/MyMachineName_crontab

The file format is modeled after crontab:

30 1 * * * thing:to_do

In this case thing:to_do is a rake task.  It will run at 1:30 AM every morning (take a look at the crontab format if this makes no sense).

The command to install the cron job locally:

% rake craken:install

If you’re using Capistrano for deployment (and you really should) a recipe is provided to run craken:install on remote machines.  Your Capistrano configuration needs to define a :cron role so the recipe knows which machines it should run the command on.

% cap craken:install

Ideally you can make craken:install part of your deployment configuration, :after_deploy would be a good place to put it.  Craken overwrites the existing configuration for the application on the machine so running it multiple times is not a problem.  Running multiple apps on the same machine or cron jobs placed by hand?  No worries, Craken delimits the lines it generates in crontab with comments and doesn’t disturb existing entries.

For more information about the plugin, peruse the README file.

If you have any questions/comments/suggestions about Craken please leave a comment!

The name “Craken” generously suggested by Giles Bowkett.

The LED Flowerpot!

This is a little project I built as a gift for the Wife for the combined 5-year being together anniversary/Valentine’s Day. I did most of the work on the weekends, soldering and gluing in the back yard out of sight from prying wifey eyes.

The circuit is not terribly complicated, it’s a modified version of Wilf Rigter’s Quad LED Fader circuit (specifically QLF6) I found on the BEAM robotics community server. It uses a 74C14 Schmitt triggered inverter chip as a bank of five oscillators fed into a LM339 quad comparator to generate four slow wave forms to drive four banks of LEDs. The 74C14 was provided by my good friend and chip dealer, Mr. Bunt. The major addition I made to the circuit was a voltage regulator to change its power supply to use a wall wart scavenged from a defunct answering machine that I haven’t seen in years. A 9-volt battery, its package being the ideal size to fit in the flowerpot base, unfortunately drained quickly with the number of LEDs I wanted to use.

Soldering the circuit itself onto the prototype board wasn’t much of a chore but as you can see, I do needs me some practice at circuit layout. The most irritating thing was wiring up all the LEDs. There’s 34 of the little buggers and each one had to be hot glued in and wired up to their brethren and the circuit. The result of which is the rat’s nest you see before you. I only have black wire, OK?

The prototype board rests on the sides of the pot, stuffed down below the “dirt’s” surface. The surface itself is made from a round cut from a cheap cutting board that was too crappy to actually use as a cutting board. Scraps left over from the same were hot glued to the sides of the pot to hold the surface at the desired depth.

The LEDs were hotglued into position before being wired up for action. First I had to make holes in the cutting board round to stuff the LEDs through. I originally intended to use a drill to create the holes, but quickly found that my smallest drill bit opened cavernous orifices compared to the width of the leads on your average LED. In the end I used a needle heated with a lighter to pierce the holes. Not only was the pierced diameter perfectly suited for LED leads, I found the process of holing plastic with a glowing-hot needle extremely satisfying for some strange reason. It did take a while though.

After the LEDs were in place and the circuit was working, the next step was to decorate the “dirt”. I used soil-colored foam turf I found at a model railroad store along with “scenic cement” to fix it in place. The added details were bits of bark and very small rocks I found in our real plant pots and about the yard; without them the scene didn’t look terribly realistic. Not that LEDs sprouting out of a fine soil-filled pot is firmly grounded in reality or anything.

When I turned from using a 9V battery fueling the circuit to a wall wart, I had intended to drill a hole in the side of the pot near the bottom to pass the power cable through. After a couple of attempts, the near hideous scratching of the pot’s green glaze and a paralyzing fear of causing it to shatter I decided to use the pot’s drain hole as mother natured intended. Its hole-ness beckoned to me. Besides the socket I had fit almost perfectly. Unfortunately the pot can’t rest on its base anymore; it requires I use a stand as you see in the first picture. The current stand is a opened leatherman knock-off because it was the first thing I had on hand that fit the bill. It was a poor knock-off so it makes a better stand anyway.

Since pictures don’t show off its glow-y goodness, here’s a video I took of it doing its thing (in the dark so you can see it better):

So where did I get the idea to do this? I was playing around with the circuit on a breadboard and a little garden of LEDs glowing and fading in and out when the wife came by and said “Ooooo! Mushrooms!”. The idea for the finished product was a short hop away from there.

If you’re going to see any Obama video see this one. I thought I liked him before!