Development Blog: Viget Labs

Clinton R. Nixon, Senior Developer, August 17, 2008 1

I’ve been training a new Rails developer recently, and I’ve found it rewarding. His questions are great: without already-built habits, he thinks of ways to do things I never would.

Last week, he said, “I need to test this view with some real data to make sure it looks OK. We have all these factory methods to use in our unit tests. Can we use those in development?” I almost said no, but then I realized it was a pretty great idea.

We’re using FixtureReplacement on this project, but this technique will work with any factories. We opened script/console and typed the following:

require 'fixture_replacement'
include FixtureReplacement
require RAILS_ROOT + '/db/example_data'

With that, I could use, for example, our create_completed_order method to make a purchased cart with multiple items in it so we could see how the admin interface was looking. It’s no replacement for good testing, but for quick view checks, it’s a pretty cool trick.

Brian Landau, Web Developer, August 12, 2008 0

On a project I’ve been working on recently, I wanted to be able to enter in Markdown text to a field and convert it into HTML in a view. Having read about BlueCloth’s performance problems though, I didn’t want to use the built in markdown helper in ActionView.

So I decided to give RDiscount a try, but I wanted to have the value for the column stored as a RDiscount Markdown object in the model object. So I started by creating an acts_as_markdown class method that took a list of columns to be represented as markdown objects. Quickly, my fellow Vigeteers and I realized it would be useful for a bunch of other markup languages as well, along with other Markdown libraries.

Continue reading "Introducing ActsAsMarkup: A Markdown, Textile, Wikitext, and RDoc Plugin for ActiveRecord"

Brian Landau, Web Developer, August 07, 2008 3

When working on high-traffic Rails sites, it often becomes necessary to find ways to improve performance with caching. One place we’ve found this is most convenient and easy-to-do is by caching an ActiveRecord result set for models that change rarely or not at all. An easy example of this is a Category model.

Often times, you have a categorization hierarchy that will never or rarely change over the life of an application. Ideally you would fetch the results once from the database and never have to again. So how do we go about caching this? First let’s look at our model and create a named_scope for it:

class Category < ActiveRecord::Base
  acts_as_tree
  named_scope :find_top_level, :conditions => 'categories.parent_id IS NULL',
                              :order      => 'categories.name'
end

Next, we need to create create a method that fetches the results for our new scope and caches it in a class variable. It should also only do caching if in production environment (alternatively or additionally, we could use the ActionController.perform_caching config value), as this can cause problems in tests.

def self.top_level
  unless ('production' == RAILS_ENV) && ActionController.perform_caching
    @@top_level_cache = self.find_top_level
  else
    @@top_level_cache ||= self.find_top_level
  end
end

Finally, we need to create a method to invalidate our cache when records are saved or deleted. Since we know this isn’t happening often (if at all), this should rarely be performed but is a good safeguard so we know our cache is current.

after_save :reset_cached_finder
after_destroy :reset_cached_finder

def reset_cached_finder
  @@top_level_cache = nil
end

This is something that we could easily see doing in a number of models for a number of finders. Since this involves a lot of similar code, it would be great if we could create some meta code that would allow us to define these caches with a simple one liner.

Continue reading "Named Scope Caching"

Matt Swasey, Web Developer, August 04, 2008 4

The first ruby hack night was a success, so lets have another.  Good idea?  It’s going to be August 13th 7pm @ Murky Coffee in Arlington.  We’re going to trying and make these a monthly gathering, second Wednesday of every month.

Here is the upcoming entry, a small website will soon follow!

As before, bring your personal project ideas, or open source project experience, and be willing to share with the rest of us what you are planning on hacking, and what others could do if they wish to join your efforts.  It’s a casual environment, anyone is welcome, so please join us August 13th at 7pm.

I hope to see you there!

David Eisinger, Web Developer, July 31, 2008 0

On my latest project, the client is using EmailLabs to manage their mailing lists. To simplify interaction with their system, we’ve created EmailLabsClient, a small Ruby client for the EmailLabs API. The core of the program is the send_request method:

def self.send_request(request_type, activity)
  xml = Builder::XmlMarkup.new :target => (input = '')
  xml.instruct!
  xml.DATASET do
    xml.SITE_ID SITE_ID
    yield xml
  end
  Net::HTTP.post_form(URI.parse(ENDPOINT),
    :type => request_type, :activity => activity,
    :input => input)
end

Then you can make API requests like this:

def self.subscribe_user(mailing_list, email_address)
  send_request('record', 'add') do |body|
    body.MLID mailing_list
    body.DATA email_address, :type => 'email'
  end
end

If you find yourself needing to work with an EmailLabs mailing list, check it out. At the very least, you should get a decent idea of how to interact with their API. It’s up on GitHub, so if you add any functionality, send those patches our way.