Chapter 1 - Define Programming

Programming isn't hard. All it is really is a set of instructions we give the computer to be executed at a later time. This means a few things:

We need to be damn specific about our instructions.

Think about something you do. Like blowing your nose. Seems pretty easy, right? Well try to break it down into pieces of actions as far as you can. The steps involved in blowing your nose may seem at first like grabbing a tissue and just going for it. Well, there's a lot more to it. Imagine you had to describe how you would blow your nose to an alien -- another being that doesn't share all this common knowledge with you. Aliens, for the sake of this example, don't know where a nose is located. Hell, they probably don't know what a nose is. So how do you go about describing such a mundane task to someone who's never seen a nose before? Whatever you come up with is still going to fall short of an exhaustive instruction set for a computer to work off of. If it were easy, we would have robots to blow our noses for us. Maybe. But steps to describe what a tissue is, where you can find it, all the movements necessary to get to your nose, etc. This could easily take up our entire book, but gladly it won't 'cause we're lazy. Onward!

We have to be accurate, or else the computer will fuck it up (also: always blame the computer, he's heartless).

You want something done right, do it yourself. Well, for the first time, at least. Consider our previous blowing-your-nose example. Imagine your description of a nose was insufficient. Instead of describing a nose, you were reckless enough and described a weenus (look it up). Great, genius. What do you think is going to happen? You need to do it right. The benefit, at least, is that you need to do it right once.

Our instructions are documented in writing and are not subject to misinterpretation.

"You say Po - tay - to, I say po - tah - to". NO! There is no room for your malfunctioning human interpretation, my friend. A nose is a nose. Not a weenus. Not a forehead. It will always mean the same thing. And that is gold. It means get your description right once and it will be documented forever. Any computer at any time that will have to work based on your instruction set to blow someone's nose, will do so correctly.

That seems like a lot of pressure on you, the programmer, to get it right the first time, otherwise you're going to be stuck with a computer that blows weni (plural for weenus?) all day long. The good news is you can debug your instruction set as many times as you want. You can test and modify, make changes and try it on different noses until you're certain your instructions are good enough for your computer to find anyone's nose.

So by now it should be clear that programming differs a lot from human forms of communication and it's a good thing and a bad thing at the same time. For one, it's bad because we're humans and it can be difficult for us to communicate on such a high level of specificity, but it's also great since there is no room for misinterpretation. The computer will always perform the set of instructions the same way. And think how powerful that is -- we have a machine that we can instruct once to do one thing and it will always do that thing the same way! We as humans sure aren't that predictable -- we suck! I've been climbing stairs for over 20 years and I still slip every once in a while. Pretty flawed if you ask me.

So let's talk about instruction sets. Instructing the computer is not hard. We're going to dive straight into real code because there is no reason to waste any more time. By showing you the end product and making our way back from there, I think you'll have an easier time learning. All you need to be responsible for is not getting frustrated, do as I say, and look pretty. The rest will just happen magically. Trust me on this one.

Set it Up, Yo!

For the sake of uniformity, and since it's my preferred language these days, we will use the JavaScript programming language (JS) throughout this book.

We're going to use JS also because you can execute it from within your browser. To do so in Chrome (my browser of choice) from any webpage you're on, simply hit the keys Cmd + Option + I if you're on a Mac. If you're on a Windows/Linux machine, it is most likely Ctrl + Shift + I, but since you're used to by now to taking the difficult path, I'm sure you can figure it out by yourself. For mouse lovers (kinky), you can right click anywhere on the webpage, and then choose "Inspect Element" from the dropdown menu. From the tabs in the DevTools (Web Inspector) choose "Console" and now you've got yourself a Console running at the bottom of your screen where you can execute some real good JavaScript. Boom.

A Console, in this case at least, is just a REPL. While you probably preferred to just stick with the word "Console," REPL stands for "Read Evaluate Print Loop." And that's exactly all it is. The REPL (read: "computer" for now) reads your input, it evaluates it, then it prints it to your screen, then repeats the whole thing again. Everything you type in your Console gets evaluated and then immediately printed to your screen once you hit the Enter key.

To test this whole REPL thing, type this in your Console verbatim and hit the Enter key:

console.log('Hello, World');

What happened? The Console spat out the string "Hello, World" at you? Look at you programming! This is the first application you're supposed to learn when programming anything. That's how it is in computer-land and I'm not here to change it. If you give a shit, it turns out it became a thing when it was used in the book The C Programming Language, according to this Wikipedia article.

Note that if you were to type multiple lines in our Console you'd have to press Shift + Enter combined instead of just Enter in order to break into a new line. If you just hit Enter, the computer will get confused and think you wanted it to execute (evaluate) the code you've entered immediately. For when you mess up and hit Enter prematurely, use the up/down arrow keys to navigate through your previously typed code. It will save you time and frustration.

So when doing Shift + Enter all the time gets too cumbersome for you (and it will soon when you write more and more code), you are more than welcome to open a new file in a non rich-format text editor (Microsoft Word for example is going to add some meta data to the file that will fuck with you, so choose a basic one like Notepad on Windows or TextMate on Mac) and when you save it just give it an html extension. So when you're done editing your file, naming it something like test.html is totally kosher.

Note to Mac users: When I tried using the built-in text editor, TextEdit, I struggled with some formatting the editor forced on me. I eventually figured it out (because I'm so smart), but for your sake, just use TextMate instead if you can. Windows users: I don't know what Notepad is like anymore, but I can only imagine it's being at least as much of a pain as I had with TextEdit. If it's the case, just google an alternative, or use Notepad++ which seemed to have come up several times in my search for you. Either way, there are plenty of free alternatives.

When you have a text editor all set up for your coding adventure, all you need to do to run your HTML file in your browser is to make sure that the first line in it is <script> and that the last one is </script>. Those are just plain HTML tags to let your browser know that it needs to parse the text in between those two script tags as JavaScript and not as anything else. Every time after you save your HTML file, if you open it in your browser (most likely it is going to be the default behavior once you double click it. If not, open Chrome, go to "File" in the top menu, and choose "Open File") your program should execute immediately. After each time you save your file, simply refresh the page (Cmd + Shift + R) and it should reflect your changes and get executed immediately.

As an example, our previous "Hello, World" application, if it were to live inside an HTML file, would look like this:


console.log('Hello, World!');


The file could be called something like hello\_world.html. Now open the file in Chrome, open the Console (Cmd + Shift + I, then click "Console"), and you should see "Hello, World!" printed in it.

So now that we're all on the same page (and it's important that we are), let's program our first (real) application. I'm going to show you in a few lines of JavaScript how to get the current weather in your location from a free and awesome service called the Open Weather Map. Keep in mind you are not expected to understand any of the following code, but you should try to understand all of it. Try hard, even if it hurts; that's the only way you'll learn.

  Filename: weather_app.html
  Find me on GitHub:


  1. Declare variables containing the URL for the Open Weather Map
     API, and your API Key
var apiUrl = '';

var apiKey = 'fa32f';

  2. Declare a function that is responsible for getting the weather
     for a given coordinate
function getWeather(coordinate, callback) {
  var url = apiUrl +
    '?appid=' + apiKey +
    '&units=imperial' +
    '&lon=' + coordinate.longitude +
    '&lat=' + coordinate.latitude;

  makeRequest(url, function (responseText) {
    response = JSON.parse(responseText);

  3. Declare a function that is responsible for making the HTTP
function makeRequest(url, callback) {
  var xhrObject = new XMLHttpRequest();
  xhrObject.onload = function () {
  };'GET', url, true);

  4.  Declare a function that is responsible for getting our user's
function getUserCoordinates(callback) {
  navigator.geolocation.getCurrentPosition(function (position) {
    if (position.coords) {

  5. Declare a function that is responsible for the mundane task of
     printing the temperature onto the user's screen.
function printWeather(weatherData) {
  var currentTemperature = weatherData.main.temp;
  console.log("The current temprature at your location is: " +

  6. Declare a function that is responsible for putting all of this
     together (i.e. execute all the other functions in the correct
     order), and is gonna be the entrance point to our application.
function weatherForMyLocation() {
  getUserCoordinates(function (coord) {
    getWeather(coord, printWeather);


Now this is a shit-ton of information even though it looks concise. But don't you worry, we're going to dissect this code in the rest of the book.

First thing to note is that in the code above, the text between the /* ... */ is comments for humans only and the computer doesn't care one bit about them when executing our application.

Now here's a quick overview of the entire application we just wrote as noted in the comments preceding our functions above:

  1. Declare variables containing the URL for the Open Weather Map API (Application Programming Interface -- more information about APIs later) and your API Key.

  2. Declare a function that is responsible for getting the weather for a given coordinate.

  3. Declare a function that is responsible for making the HTTP requests (HTTP stands for HyperText Transfer Protocol, you curious bastard).

  4. Declare a function that is responsible for getting our user's coordinate.

  5. Declare a function that is responsible for the mundane task of printing the temperature onto the user's screen.

  6. Declare a function that is responsible for putting all of this together (i.e. execute all the other functions in the correct order), and is going to be the entrance point to our application.

Beer. Get me one too.

Now let's run this beast.

In order to do so you will have to copy and paste the code above into its own file like I explained earlier. If you're lazy, simply download the file from this book's GitHub repository here and save it with an html extension.

Before you go any further, go to the Open Weather Map site (we'll use it to get our weather data) and sign up for a free account here. Following your registration you should get an API Key which will be used to identify our application and ensure we don't abuse their services. Copy it and paste it where it says <REPLACE WITH YOUR KEY> in the code we wrote above. So for example, if the API key we got from the site was: fa32f (in reality it'll be longer), then we would write this in our application:

var apiKey = 'fa32f';

Now open our application in Chrome (double click the HTML file or refresh the page if it's already loaded) and you will have our script loaded in the browser. Make sure to have it wrapped in <script> tags like we mentioned before. But what's that? It seems like our page is clear and it has absolutely nothing on it! Oof. Well in order for it to work we need to just call (run) our main function, weatherForMyLocation which is now loaded and declared on the page. So simply open your Console on the page, (Cmd + Shift + I) and type the function's name followed by parentheses and hit Enter.

So in order for us to get our application to finally do something, we will have to invoke our main function by typing the following in the Console and then hit Enter:


Again, following our main function's name (weatherForMyLocation) with a pair of parentheses means we want it to execute the code that we typed inside it earlier. The semicolon following it is just a good practice for now which we will discuss in more detail later.

A few moments after invoking our function, if everything worked as planned, we should see in the Console a bit of text telling us the temperature in our current location.

Now, there is a good chance this didn't work for you. This could be due to many different reasons. Welcome to the world of programming. Your job now is to debug (fix a bug) your application and make it work. Find a thread of evidence as to why things have gone awry, and go from there. You should go back and repeat the steps we've covered above. Try a different setup (browser/computer/Internet connection/pants). Try to see if you have any error shown in the Console; if you do, google it and try to look for a solution. If you're still clueless, keep reading -- we're going to cover some nifty ways of debugging your code later.

In the meantime, let's begin breaking our application down to its bits and pieces.

Table of Contents