There really isn't one canonical, linear way to march through all of the material that's required to arrive at a complete understanding of the Web of today, but there are layers of abstraction built on top of each other.

We will be starting at "the bottom" to the degree that is absolutely necessary and then work our way up as thoroughly as possible until we've built a basic version of this very web application.


Keep in mind that I will generalize a fair amount and say things like "[A] and [B] are essentially the same" and I will be more or less telling the truth, but if you go around parroting those declarative sentences, you just might offend somebody (or be judged), because people in this field tend to be huge fans of veracity rather than approximation. In fact, they essentially get paid for it.

There, "essentially", I just did it.

Oh, and this text here is an aside. I'll be using this format throughout the book to comment on things that are related but not critical to the point of the section.

I'm not doing this approximating to roundaboutly get you (or myself) shouted at, but I am doing it intentionally, and for two reasons:

  1. To give you a breadth of knowledge
  2. To equip you to go on and more deeply question what I've approximated

That you may then know the truth for yourself.

So there it is, my disclaimer.


While this book is structured specifically to help tie everything together, don't beat yourself up if you don't understand everything the first time. If you understand what is generally going on, you're good.

The brilliant thing about the written word is that you're able to go back and re-read things that you didn't get the first time around. In fact, you'll probably get more out of reading the book through the second (or third) time once you already have a loose understanding of what's going on.

So feel free not only to keep moving, but also to come back!

I'm as guilty of not re-reading as anybody, but every time I do choose to re-read a programming book (or even a chapter of a programming book), I'm pleased to find that there's more for me to learn and that I am now more able to learn it.


There are plenty of things that will be defined as we go, but let's take care of a few up front.

Source code is what you and I know as "code", but it is not exactly what computers actually execute (run).

Unless of course you're particularly comfortable with 1's and 0's, in which case, you and the computer speak the same language.

Here is an example of some Ruby source code:

first_name = "Brad"

This code is syntactically correct, meaning it follows Ruby syntax which defines what is properly formed Ruby code.

As a counter-example, here is some syntactically incorrect Ruby source:

first_name = "Brad

Notice the missing " after Brad.

If we tried to run this line, the Ruby interpreter would throw an error, because the code does not follow Ruby syntax.

So remember how we said that this code isn't exactly what your computer executes? Well, Ruby is an interpreted language, which means that Ruby source code is run through a program called an interpreter which generates some kind of binary format that the computer then executes.

Binary here meaning a series of 1's and 0's.

As the interpreter moves through the source code, it is said to be parsing the code, walking through it and figuring out what it means so that it can convert it into something your computer can understand.

There are also compiled languages where this process is a little different, but we won't be seeing any of those in this book.

And when a computer is executing any kind of program, it does so within a process.

Right now, there are probably all kinds of programs running on your computer. For instance, you're viewing this page inside of a web browser and that web browser is running inside of a process.

We won't need to be particularly concerned with most of these concepts, but they do come up and so they're good to understand.

The term open source means that the developers of a given project have opened its source code to the public, usually so that others are free to make use of that code but also so that others can contribute their own fixes and improvements.

After we write a lot of code, we might realize that we're doing something inefficiently or in the wrong place. In this case, we'd want to refactor our code, which means that we'd want to preserve the functionality of our code (i.e. what it does), but change the implementation (i.e. how it does it) in order to improve efficiency, readability, or both.

As we work, we'll want to try to stick to best practices, which are the means and methods that the community agrees are the best way of doing things.

Sound subjective? It can be.

Similarly, you probably also hear terms like "good practice" and "bad practice" used.

And when we save our source code, we'll have to save it to a file and that file will live inside of a directory.

Which is just another word for "folder". I'll use both terms, but I tend to favor "directory".

When you run a program, the means by which you interact with it is called a user interface (UI). Most UI's today will be graphical user interfaces (GUI).

Specific examples of GUI's would be a Facebook profile page and a video game main menu.

Then there are some terms that aren't specific to computing, but that are used frequently in a computing context. Be sure you know the following and think about the relationship between the pairs:

  • local / remote
  • absolute / relative
  • static / dynamic
  • explicit / implicit

Control versus Command

I will be referring to the Ctrl key throughout this book, because that's what I grew up with and what I use now. If you're a user of Linux or Windows, you won't have a problem with this nomenclature, but if you're on a Mac, this will be the Command key for you.

Potentially obvious, but worth mentioning.

First Chapter