Introduction

When I was growing up I was sitting in front of a computer every chance I got. Not because I was programming, but because I was fascinated by what was possible with this amazing machine. I grew up as a computer user using ICQ, Winamp, and Napster.

As I got older I spent more time playing video games on the computer. At first I was into first-person shooters and eventually spent most of my time playing real-time strategy games. And then I discovered that you can play these games online! Throughout my youth I was a ‘computer guy’: I knew how to use computers, but I had no idea how they worked under the hood.

The reason I’m giving you my background is because I want you to know that I was not a child prodigy. I did not teach myself how to program Basic at age 7. When I took my first computer programming class I was not teaching the teacher and correcting his mistakes.

It wasn’t until my second year of a University degree that I really came to love programming as an activity. Some may say that I’m a late bloomer, but I have a feeling that I’m closer to the norm than you may think.

Although I came to love programming for the sake of programming itself I still didn’t have a good grasp of how the computer was working under the hood. If you had told me back then that all of my code ran inside of a process I would have looked at you sideways.

Fortunately for me I was given a great work opportunity at a local web startup. This gave me a chance to do some programming on a real production system. This changed everything for me. This gave me a reason to learn how things were working under the hood.

As I worked on this high-traffic production system I was presented with increasingly complex problems. As our traffic and resource demands increased we had to begin looking at our full stack to debug and fix outstanding issues. By just focusing on the application code we couldn’t get the full picture of how the app was functioning.

We had many layers in front of the application: a firewall, load balancer, reverse proxy, and http cache. We had layers that worked alongside the application: job queue, database server, and stats collector. Every application will have a different set of components that comprise it, and this book won’t teach you everything there is to know about all of it.

This book will teach you all you need to know about Unix processes, and that is guaranteed to improve your understanding of any component at work in your application.

Through debugging issues I was forced to dig deep into Ruby projects that made use of Unix programming concepts. Projects like Resque and Unicorn. These two projects were my introduction to Unix programming in Ruby.

After getting a deeper understanding of how they were working I was able to diagnose issues faster and with greater understanding, as well as debug pesky problems that didn’t make sense when looking at the application code by itself.

I even started coming up with new, faster, more efficient solutions to the problems I was solving that used the techniques I was learning from these projects. Alright, enough about me. Let’s go down the rabbit hole.