stephanie writes code

(For People Who Read English Good)

Easy Analogies to Demistify Web Application Jargon

I’m starting to think that colorful metaphors and super literal blog post titles pair best together.

With that said (disclaimer: I’m feeling a little dotty on this foggy Halloween day), here are some ‘colorful’ metaphors and analogies to help lift the proverbial fog from some web-application jargon…

1. ERB (Embedded Ruby)

ERB is little more than HTML with superpowers. You know it’s ERB (as opposed to plain old HTML) — largely — when you see these <%= something here %>. And what are those? Interpolation points, much like these in basic Ruby #{}. They’re kind of like little portals through which you can make contact with and access the resources of another planet (i.e language, i.e Ruby). Think Stargate.


Seriously, why do they all have to sound the same?! Especially when they’re all such distinct entities. Guess we should start with Sqlite. Thanks to Scott C. Reynolds for the following analogies.


This is a database management system, or DBMS. It like, lets you store and save stuff and delete stuff (also known as ‘data persistence’ and CRUD). In the context of Halloween, since it’s Halloween today, Sqlite is a garage littered with knick knacks that you’re further using to store Halloween decorations. Other similar DBMS’ that fit this analogy include MySQL and PostgreSQL (not a very pretty but still helpful comparison between the two). To make a distinction, however, if Sqlite is a 2-car garage, then MySQL is a 10-car garage.

SQL (Structured Query Language)

As its full name suggests, SQL is a language. Just like HTML and Ruby and Python and Javascript are languages — so is SQL. It is not a gem. It is not the database itself. SQL IS A LANGUAGE. You’re using SQL when you type stuff like SELECT * FROM <table_name>. And to continue the Halloween/garage analogy, hard coding SQL to get stuff in and out of your database is a little like going out of your way to poke around through all the crap sitting in your garage to find and retrieve a ball of tangled Halloween lights. There’s a need to get the lights (i.e the data), yes, but this way of doing it is tedious.


And this is where Sequel comes in. Sequel is an ORM, or Object Relational Mapper, which is just a fancy way of saying ‘the common ground between two different languages’ — namely, SQL and Ruby. Other ORMs include ActiveRecord and DataMapper (a helpful comparison between the two). Sequel is just another one of these ORM things. And to beat the Halloween analogy to death, using Sequel in place of SQL is like relaxing on your porch with a pumpkin beer while you get the neighbor kid to go into your garage, find the lights, and bring them out to you nice and untangled. You don’t care how he did it — all you know is you asked the kid to do something, and it was done. Nice.

3. M-V-C (Model View Controller)

I don’t have a Halloween analogy for this.

Jeff Atwood actually has a great explanation of the Model-View-Controller paradigm right here. To summarize his version, the model contains the logic and data of your web application; the view is how you display your data and web application; and the controller, though a little more complicated, is the link between the user and the system behind your web application. How it all works together? I like to think of the M-V-C model as an elaborate and meticulously-arranged domino chain that behaves in an expected way from one trigger or initiation point. If you’ve designed and coded all your moving parts to work properly together, then one file with a single command should be able to kickstart the whole application. Your finger pushing that first domino would be the equivalent of a runner file, or something similar.

I’m going to keep adding to this list as I feel inspired.

At the very least, I hope you’ll come away from this post feeling confident that you’ll never confuse Sqlite, SQL, and Sequel EVER AGAIN!