Chrome JS Console Basics

My Flatiron cohort has switched from “Ruby mode” to “Javascript mode” for the second half of our program, and among the many changes that come with programming in a different language, one that immediately stood out to me was my set of debugging tools.

Using debugger to pause my functions or console.log to print variable values isn’t so different from Pry and “puts” in Ruby, but the Chrome console–where I have been spending lots of time lately–is quite a change from the Terminal.

There’s a lot to take in when you first open the Chrome Javascript DevTools (press cmd+option+j while in a Chrome window)–html elements, a console, network status codes–all crammed into a side panel. So far, I’ve only made use of a small portion of its functionality, but this weekend I discovered Google’s extensive DevTools guide, and ran through some basic tools that I can make use of right away.

The Google guide is an excellent resource, so I’ll just focus on a few features that help illustrate the power and ease-of-use of some of the basic debugging tools: breakpoints, event listener breakpoints, and step buttons.

A breakpoint can be used to pause the code (just like debugger), but can be set without typing debugger into the js file, refreshing the page, and running the code.

set-breakpoint

In the above example, my code is paused in a debugger that I wrote into my js file. At this point, I can set a new breakpoint on line twenty by simply clicking on the line number. The line will be flagged in blue when the breakpoint is set. I can then press play to resume script execution until it hits my breakpoint. Play to next breakpoint.png

Once paused at a breakpoint, I can click the console tab and check the value of this.currentRound, for example.

The step buttons allow me move through the code without setting breakpoints. The down arrow steps into the next function call, which means that if the next line of code is a function call, the script will execute and stop at the first line of that next function.

The up arrow steps out of the current function, meaning that it executes the remainder of the function that it’s in, and then stops at the beginning of the next statement after the function call.

The step over (curved arrow) function call executes whatever happens on the next line and moves to that line. Step through.png

Aside from setting breakpoints at specific lines or using step buttons to traverse code, breakpoints can also be set with triggering events, such as a mouse click, or DOM mutation. In my below example, I’m creating a breakpoint to be set upon a timer being fired off.

Set timer.png

The script executes until it hits my function called “countdown” being fired from a setInterval method. From there I can click over to the console tab and do some debugging!

hit event.pngAs I mentioned, these are just a few of the available tools in the Chrome JS console. I highly recommend going through this demo for getting started with debugging JavaScript in Chrome DevTools, which goes through some of the topics I covered here, as well as introducing “watch,” another useful feature for checking changes in a variable.

 

Intro to APIs

Over the holidays, I built a mini Rails app using OMDb, a movie database, to find a summary, IMDb rating, and genres for a movie based on its title. Choosing an API for this project took a lot more work than I had expected. I had no idea how many APIs were out there and the variety of purposes they can serve. So I decided to look into what exactly an API is and how they came about.

First, what is an API?

An API (Application Program Interface) is code written for use by other applications, so that functionality and information can be reused or reinterpreted. The Google Maps API, for example, has been used to build applications such as a Zombie Outbreak Simulator and PlaneFinder, an app that shows realtime air traffic.

APIs provide information in a simplified format, such as JSON (JavaScript Object Notation), defined by W3Schools as, “a syntax for storing and exchanging data.”

“Unlike Web applications themselves, APIs are built for computer consumption rather than direct user interaction.” -Meg Cater,  A Brief History of API-Based Web Applications

And how did APIs come about?

In some ways, it seems counterintuitive for a company to give away their product for others to use. First, I’ll say: not all companies are “giving away” their product; there are plenty of APIs with monthly fees.

In regards to free APIs though, I’ve identified three forces (there are probably more) that push companies to offer them. One, the ethics of open data that has been embraced by tech companies probably more than any other major industry. Two, unofficial APIs often pop up when official ones don’t exist. And three, the API itself is now seen as a valuable asset that makes a product like GoogleMaps the web’s default map provider.

Some of the earliest APIs to launch were Salesforce and eBay, both in 2000 (though this Quora post indicates that the topic is up for debate). Flickr, Twitter, Amazon, Facebook, and Google soon followed.

“The Google Maps API launched was just shy of 6 months after the release of Google Maps as an application, and was in direct response to the number of rogue applications developed that were hacking the application.” –History of APIs, apievangelist.com

APIs are becoming more widespread and essential to web applications, which more than ever integrate multiple technologies. In 2009, the US government launched the website, data.gov, a major push toward open government data.

Social media APIs, such as Twitter, are some of the best known, but APIs are becoming more ubiquitous across all types of applications. Right now there are around 16,541 APIs listed in the directory Programmable Web.

For a further introduction to APIs, I recommend checking out the five-part blog series on Programmable Web entitled, What are APIs and How do They Work?. Programmable Web is also a great source for discovering APIs through their API directory.

Resources