Development Blog: Viget Labs

Justin Marney, Web Developer, January 08, 2009 0

What is outside.in?

Outside.in is a hyperlocal news and information service:

Hyperlocal means news and information on a level beyond what traditional media provides. Until now, most "local" sites didn’t actually get more, well, local than cities or towns. They assumed that just because you live in a specific city or town you are looking for the same news as everyone else. Hyperlocal content gives you the news and information for the area right around where you are, like the block around your office or the neighborhood where you live.

What is outside.in Radar?

outside.in Radar is the first local news experience that puts you at the center of the action. It is customized to exactly where you are and what’s going on right around you.

Examples include tweets, news stories, and blog posts in your immediate area (surrounding blocks or neighborhoods).

What is the outside.in Radar API?

The outside.in API is a means by which developers can easily integrate Radar results into their own applications. Send it a latitude and longitude and get back stories, tweets, and other outside.in user-generated content for the surrounding area. A sample query returns XML that looks like:

Continue reading "Radarb: A ruby gem that makes using the outside.in API simple."

David Eisinger, Web Developer, January 05, 2009 5

Here’s a quick tip that came out of a code review we did last week. One easy way to add caching to your Ruby app is to memoize the results of computationally expensive methods:

def foo
  @foo ||= expensive_method
end

The first time the method is called, @foo will be nil, so expensive_method will be called and its result stored in @foo. On subsequent calls, @foo will have a value, so the call to expensive_method will be bypassed. This works well for one-liners, but what if our method requires multiple lines to determine its result?

def foo
  arg1 = expensive_method_1
  arg2 = expensive_method_2
  expensive_method_3(arg1, arg2)
end

A first attempt at memoization yields this:

def foo
  unless @foo
    arg1 = expensive_method_1
    arg2 = expensive_method_2
    @foo = expensive_method_3(arg1, arg2)
  end
  @foo
end

To me, using @foo three times obscures the intent of the method. Let’s do this instead:

def foo
  @foo ||= begin
    arg1 = expensive_method_1
    arg2 = expensive_method_2
    expensive_method_3(arg1, arg2)
  end
end

This clarifies the role of @foo and reduces LOC. Of course, if you use the Rails built-in memoize method, you can avoid accessing these instance variables entirely, but this technique has utility in situations where requiring ActiveSupport would be overkill.

Mark Cornick, Web Developer, December 08, 2008 2

Many development projects start as scratches for a developer’s itch. We do something enough times to decide that not only must there be a better way, but that we’re going to find it.

At Viget, we’ve mostly sworn off fixtures for our test suites. Instead, several of our recent projects have used Thoughtbot’s Factory Girl as a fixture replacement, for which it works very well. However, the Rails generators are not aware of its presence—they still generate fixtures, which we don’t use, and end up deleting. As Clinton has said, you should be automating anything you do repeatedly, and the Rails generators help meet that goal. So, it would be nice if the Rails model generator would stop creating these unused fixtures, and maybe create factories instead.

A new version of Factory Girl dropped at the end of November. Near the top of its change log is this encouraging snippet:

Factory definitions are now detected in subdirectories, such as
  factories/person_factory.rb (thanks to Josh Nichols)

It might not seem like much, but when I read this, a thought entered my mind. Instead of creating one fixture file per model in the generator, what about creating one factory file? After discussing it with other Viget developers on Campfire, the itch was ready to be scratched—we were going to have a model generator that creates factories instead of fixtures.

Less than a day later, the first version was done. It’s literally the same model generator that ships with Rails 2.2.2, but with all the fixture references changed to factories. Not a monumental display of skill, perhaps, and the point about how open source makes all this possible is obvious and oft-repeated. But, still, an itch scratched, and one less thing that’s not fully automated. 

Do you have some itch that bugs you in development? Think about taking an hour or two and scratching it with some code. If it saves you effort and makes your development process easier, it’ll be time well spent.

Tony Pitale, Web Developer, November 26, 2008 8

When outputting sets of data that may or may not be present it is valuable to have some default to display in the cases when that data does not exist.  As this set grows to the point where detection becomes unwieldy, perhaps as new fields are added, having complex conditionals in your view code is typically not the best solution. In this example, Dining & Kitchen and Appliances have no information.

Listing Price Information

• Original Price: $239,999.00
• Low Price: $139,000.00

Dining & Kitchen

Appliances

Bedroom Information

• Main Floor Beds: 2

Enter jQuery: with a simple statement we can easily detect which elements on our page are empty, and fill them with some default value to notify a user of that case.

$('ul').each(function() {
  if(jQuery.trim($(this).html()) == "") {
    $(this).html("<li>No information available</li>");
  }
});

The above code checks every unordered list element on the page to see if the html within is empty. If so, it adds a simple list item with a default value to inform the user that the section on the page has no information, instead of simply being empty. The end result is below.

Listing Price Information

• Original Price: $239,999.00
• Low Price: $139,000.00

Dining & Kitchen

• No information available

Appliances

• No information available

Bedroom Information

• Main Floor Beds: 2

This solution has the benefit of speed, and a fairly accessible global reach, while keeping view code and helpers free of potentially gargantuan if statements.

Mark Cornick, Web Developer, November 13, 2008 0

OAuth is, according to its creators, “[a]n open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.” It accomplishes this primarily by passing various tokens and secrets between the API provider and the application wishing to access it. Understanding what happens with these tokens and secrets (which I will call “credentials” for the sake of clarity) makes OAuth slightly less “simple” to comprehend at first. Fortunately, it’s not too hard, and in this post I’ll share what I learned when implementing an OAuth-speaking client application.

Continue reading "OAuth By Example"