Doug McInnes » Los Angeles Times http://dougmcinnes.com Chuckle and Chortle Tue, 25 May 2010 07:52:12 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Javascript Love http://dougmcinnes.com/2008/11/13/javascript-love/ http://dougmcinnes.com/2008/11/13/javascript-love/#comments Fri, 14 Nov 2008 07:17:55 +0000 Doug http://dougmcinnes.com/?p=23

I’ve been a busy bee releasing stuff into the wild lately. Most of them have been Ruby on Rails plugins but I’ve also been doing some Javascript work. Here’s two tidbits that I developed at the Los Angeles Times.

Inplace_preview

Inplace_preview is the first. It monkeypatches Scriptaculous‘ InPlaceEditor to give it a preview mode. It also includes an ability to do an ajax call for rendering the preview. It comes in handy when using an InPlaceEditor for editing HTML but with the ajax rendering anything would be possible.

Here’s an example (if you save you’ll get a big-ol error since we don’t actually save here):

Click Here to Edit…

Gallery_scroller

Gallery_scroller is small Javascript library for creating a scrolling gallery that we’re using on more projects then I expected. It requires Prototype and Scriptaculous effects.js libraries.

Here’s an example:

The documentation on both of these goes into detail on how they work, so check out their github sites!

]]> http://dougmcinnes.com/2008/11/13/javascript-love/feed/ 0 Couple of Railsy Tidbits http://dougmcinnes.com/2008/11/10/couple-of-railsy-tidbits/ http://dougmcinnes.com/2008/11/10/couple-of-railsy-tidbits/#comments Mon, 10 Nov 2008 19:30:43 +0000 Doug http://dougmcinnes.com/?p=19 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.

]]> http://dougmcinnes.com/2008/11/10/couple-of-railsy-tidbits/feed/ 0 cached_resource http://dougmcinnes.com/2008/10/30/cached_resource/ http://dougmcinnes.com/2008/10/30/cached_resource/#comments Thu, 30 Oct 2008 21:13:06 +0000 Doug http://dougmcinnes.com/?p=16 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.

]]> http://dougmcinnes.com/2008/10/30/cached_resource/feed/ 0 Craken http://dougmcinnes.com/2008/07/14/craken/ http://dougmcinnes.com/2008/07/14/craken/#comments Mon, 14 Jul 2008 18:53:09 +0000 Doug http://dougmcinnes.com/?p=14 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.

]]> http://dougmcinnes.com/2008/07/14/craken/feed/ 8