In a previous post, I explained the fundamentals of database design. This guide will cover the second half of that topic: how to make the database work with Rails. Before reading this you should have a good understanding of what a database is and how to organize one.

Rails is a framework that sits on top of the programming language Ruby. The framework speeds up web development by filling in code that you'd otherwise write from scratch on every new project. A component of this is ActiveRecord, a subset of Rails that acts as the bridge between your database and your Ruby code.

There are many ways to cache data in a Rails application. (The official Rails Guide explains the different approaches well.) Heroku allows you to easily take advantage of Rails caching by connecting your application to Memcached servers through the Dalli client gem.

This drop in solution is simple, but there's one glaring problem. Memcache does not support expiring cache keys with regex. This means if you need to delete keys beginning with "user-1" but not keys beginning with "user-2", you're out of luck. Or so it seems...

If you've ever wanted to know what a database is, how a good one works, and how it hooks up with Rails, you are a nerd. And you've come to the right place. I gave a beginner talk about the subject at our recent hackfest and thought a blog post might be helpful for any beginners out there struggling with these concepts. Let's dive in.

If you've ever used a spreadsheet, you've used a database. Consider this table that tracks a bookstore's inventory:

We recently worked on a mapping application that lets users monitor their driving habits using real time data from their cars. The data came in the form of latitude/longitude points, from which we would build a trip and calculate statistics for that trip (speeding, distance, etc).

Because the car sends lat/long data every second, a Trip object can contain thousands of points. Each of these points in turn stores the standard rails timestamps, the latitude and longitude themselves, and some relational keys.

Classes are among the murkier programming concepts in JavaScript, but they're as useful here as they are in other languages like Ruby. It's true that JS lacks a native class implementation, but there are easy ways to mimic the functionality of a solid class hierarchy system.

But first off, what the heck is a class? Put simply, classes describe the ingredients of your application. If you're writing a program for a library, you might have a book class, a customer class, and an event class.

Creating an authentication system from scratch is simple with Rails 3.1, thanks to these two RailsCasts. What's left unexplained, however, is how to take advantage of this in your controller and model tests.

We recently inherited a legacy Rails 2 app in sore need of an upgrade. Here are some of our favorite takeaways. (We'll cover the back-end gains here; the front-end post will come shortly.)

I recently read JavaScript: The Good Parts by Douglas Crockford. The book attempts to teach JavaScript by extracting its good qualities as a programming language, and by leaving its dirty bits to rot unused on the floor. I, however, found the bad parts much more interesting. Here are six of those curiosities.

Last Wednesday was our monthly hackfest, with a theme focusing on API mashups. Despite a healthy turnout, only 6 projects were turned in when the 9 pm deadline hit, 5 of which were from Quick Left employees.

The new Google Maps API, while much improved and streamlined, sacrifices some important features for the sake of a lighter footprint. After fighting with the service for several hours, I wrote a helper framework that simplifies the one action I was attempting over and over: dropping markers on a map.

After the initial call to the server to get the latitudes and longitudes for our model, I rendered them to the DOM like this: