A little background: Before I started studying full-stack web development in earnest at Flatiron School’s Access Labs Initiative, I dabbled very briefly in a number of programming languages over the years. The language where I got the furthest was probably C++ back in college. We studied from a textbook called Starting Out With C++ from Control Structures to Objects by Tony Gaddis (which I HIGHLY recommend—and I don’t think I’ve ever said that about a textbook).

That single semester of C++ probably did more to prepare me for my future programming endeavors than any of the other languages I’ve studied. While experienced programmers may balk at the idea that C++ is a low-level programming language, it certainly operates at a lower level of abstraction than many popular languages used today (Python, Swift, Ruby, etc). This is extremely useful in helping you understand how computers “think” and what actually goes on under the hood.

After spending some time immersed in Ruby and now JavaScript, I decided to venture back into some lower-level systems programming territory. Except this time, I decided to go to the granddaddy of many modern programming languages: C. Why, you ask?

Abstraction is great! It can help you write functioning code very, very quickly. But I have to be honest: I kind of miss seeing what’s going on under the hood. I want to gain a better understanding of how the computer processes instructions. Finally, I want to learn how to write systems from the ground up with fast, powerful code. First things first, though: we need to start with basics.

Should you be intimidated by C?

No!! Look—if you’re like me, coming from a language like modern JavaScript where it’s relatively simple to do very complex things, I don’t want to understate the differences. There are very big differences. C doesn’t come with as much “out of the box.” C is not interpreted; you MUST compile your code in order to run it. It doesn’t support many of the nice high-level data types you’d expect from a high-level language these days; for instance, there’s no structure that’s quite like a JavaScript object with key/value pairs, and “string” is not a data type—it’s just an array of characters that’s terminated with the null character!

BUT! Certain fundamental programming concepts will have familiar implementations in C, and for writing basic programs, it’s not nearly as unapproachable as you may think. I realized this very quickly when I started reading The C Programming Language, 2nd Edition, by Brian W. Kernighan and Dennis M. Ritchie. The following is a simple program from Chapter 1 which converts Fahrenheit values into their corresponding values in Celsius, with some basic output formatting:

#include <stdio.h>
 
/* print Fahrenheit-Celsius table
   for fahr = 0, 20, ..., 300 */

main()
{
  int fahr, celsius;
  int lower, upper, step;
 
  lower = 0;      /* lower limit of temperature table */
  upper = 300;    /* upper limit */
  step = 20;      /* step size */
 
  fahr = lower;

  while (fahr <= upper) {
    celsius = 5 * (fahr-32) / 9;
    printf("%d\t%d\n", fahr, celsius);
    fahr = fahr + step;
  }
}

What really struck me about this code is how similar a JavaScript implementation could be! In fact, to get a similar result in JavaScript, we need only make a few small modifications.

function fcConvert()
{
  let fahr, celsius;
 
  const lower = 0;
  const upper = 300;
  const step = 20;
 
  fahr = lower;

while (fahr <= upper) {
    celsius = 5 * (fahr-32) / 9;
    console.log(`${fahr}\t\t${celsius}`)
    fahr = fahr + step;
  }
}

Compare the JavaScript code above with the C example. They’re incredibly close. Let’s highlight the main differences:

• C has this weird #include <stdio.h> line at the beginning. What gives? This line is called a preprocessor directive. There are several steps to compiling a C program that we won’t get into here, but this line is basically telling our C compiler, “In the process of compiling this application, be sure to include the standard library functions for input and output.” This is what allows us to use printf() to get formatted output in the terminal (another one of our differences with JavaScript).
• Wait, does that main() look like a function definition?? Yup. When we work with C, main() is always first thing that gets run when we compile and execute our application. In larger applications, we won’t write all of our code inside this function, but will define other functions and call those from within main().
• In C, we have to declare our variables as a specific type from the very beginning; in this case, as integers. This is different from JavaScript where we can put pretty much whatever we want, any time we want, inside of a variable.

That about covers it! In a later example, the C code above is modified to use a for loop, and to calculate floating point numbers rather than integers.

#include <stdio.h>
 
/* print Fahrenheit-Celsius table */

main()
{
  int fahr;

  for (fahr = 0; fahr <= 300; fahr = fahr + 20)
    printf("%3d %6.1f\n", fahr, (5.0/9.0)*(fahr-32));
}

The code inside our for loop is a single line and thus, in C, we do not need to enclose it within curly braces. Aside from that, the syntax for our for loop is exactly what we’re used to with JavaScript! Our conditional expression contains an initializer, a condition to test, and an increment. That’s it!

Wait, but what about that compilation stuff!?

The one additional thing you’ll have to figure out is how to compile your programs. If you’re using Bash on macOS/Linux/BSD, here are a couple of pointers:

• For simple programs, you can create a single file ending in a .c extension, open it up in your code editor of choice, write your code, and save.
• You can compile in a terminal using gcc or clang—the syntax is similar. As an example, if I were in a directory with a file I created called main.c, the simplest syntax I could use would be something like clang main.c. By default, this generates an executable named a.out which I can then run like any other.
• A common thing to do is to change the name of the executable which the compiler outputs. For instance, say that instead of a.out I would like my executable to be called app. I could run clang main.c -o app.

If you’ve been thinking about playing around with C, I hope this convinces you to just dive in and give it a go. The C Programming Language which I mentioned earlier is widely considered to be one of the best resources when starting out, and I highly recommend it!

At first we struggled to understand the MTA’s feeds and their respective formats; the first real time feed we encountered used a protocol called GTFS Realtime, which is an extension of the existing GTFS format using Google’s protocol buffers (this is will probably be the topic of a future blog post).

Ultimately, we realized that we spent a bunch of time trying to parse the wrong feed. The MTA’s line status feed uses a protocol called SIRI (Service Interface for Real time Information). This protocol is based on XML, which is easier to parse compared to the binary protocol buffers.

At first, we tried using Nokogiri to parse the XML. I started going through the documentation, but I had a hard time just figuring out how to traverse the structure. As we were in a time crunch, I wasn’t very keen on reading deeply into the documentation. I wondered if there was a gem that would convert an XML document into a Ruby hash so that I could work with a structure I already knew. Enter XmlSimple.

As a disclaimer, use of XmlSimple is generally discouraged, as XML and hashes are somewhat dissimilar ways to structure data. However, for our purposes, it worked beautifully.

One thing to note is that XmlSimple enables an option called ‘ForceArray’ by default, meaning the resulting hash is a little bit ugly as it contains a bunch of single-element arrays. You can turn this option off, but this is also not recommended as it helps to retain the parent-child structure present in XML.

Once we had our XML parsed into collections of collections, we traversed the collections using standard hash and array notation to get the relevant information. We then passed that information into status objects associated with subway line objects, giving us the structure and relationship information we needed to report back to the user.

Unfortunately, these features often confuse developers who are just starting out. In particular, the ‘self’ keyword trips many people up. So what is ‘self’? Honeybadger’s ‘self’ cheat sheet puts it succinctly:

self is a special variable that points to the object that "owns" the currently executing code.

But what does that actually mean? Let’s dive into the most basic of code and have a look using Pry:

Some people might be thinking, “Why couldn’t we just use IRB?” I do it this way to illustrate that we are not within any class or class instance. This is the entirety of our Ruby code. So what happens when we execute this code and type ‘self’ into our console?

As we can see, ‘self’ in this context refers to Ruby’s ‘main’ object, or the top-level scope of our program. This is what we’d expect, as this is where we’ve written our code. Now, let’s create a class, define some methods, and create some instances to play with.

Yes, this code is pretty useless and yes, we normally wouldn’t cram everything into a single file. But for the purposes of illustration, this should do just fine. The first thing you may notice is ‘plural’ and ‘where_go?’ are defined as both instance and class variables.

Now, let’s pry into our code and see what happens when we call our methods:

So what exactly is happening here? Let’s put in some more calls to Pry:

Now that we can get into our ‘where_go?’ functions, let’s take a look inside.

Above I’ve called .where_go? on the Dog class. As we can see, while inside of .where_go? (which is a class method for the Dog class), self refers to the Dog class. Easy peasy. Now let’s look at the #where_go? instance method:

Here inside of our instance method, ‘self’ refers to the particular instance of the Dog class on which we called our method, in this case ‘lassie’. This is where the usefulness of ‘self’ really shines. Let’s call our #where_go? method on a couple of other instances:

When working with instances, ‘self’ allows us to work on any instance of a class without needing to know in advance what that instance will be called. We don’t know in advance what our instances will be named; the possibilities are infinite. Using ‘self’ means that we don’t need to know in advance what instances might be created.

Okay, so what about our #plural and .plural functions? They both call a method ‘name’. What is ‘name’ being called on? This is the implicit self. If we call a method without specifying the object on which it should be called, Ruby will call the method on ‘self’. If we changed ‘name’ in these methods to ‘self.name’, they would work just the same.

One pitfall to watch out for when using the implicit self: when Ruby has multiple options in deciding where to look for a method or variable, it will go from greatest to least specificity. In other words, imagine we define our ‘plural’ methods with an argument we call ‘name’. The method would then interpolate whatever we pass in as our ‘name’ argument. For example, if we were to call Dog.plural and pass in “turtles” as an argument, our result would be, “All turtles go to heaven.”

Hope this helps someone! Please do comment if anything is unclear or if you have any questions.