Debugging JS Part Two, "Console"

Debugging JS Part Two -- Console

The console in chrome (or firefox) is incredibly useful for debugging and writing code, and I use it constantly.

Open the developer tools in Chrome with F12

I generally use the console in the drawer (under Sources, with the symbol that looks like this:
This allows you to use both Sources and the Console, which work quite well together. Here are some of the things you can do in the console, but first, a quick tour.

In the drawer mode you'll see tabs labeled console, search, emulation, and rendering. Console is what we want. Search will search your source code (which can be handy), emulation allows for, well, emulation of user environments (like different web browsers, screen sizes, etc), and rendering enables some debug view options, that, for our project, don't work (except for the FPS meter).

Beneath that are buttons to clear the console output, filter to exclude certain things (like to show only warnings/errors), and a button labeled <top frame> which I've never used and isn't useful for Automaton.

Test an expression or syntax before putting it in your code

Suppose you took a week off for spring break, and you come back, and can't remember whether obj.foo works like obj[foo], (hint: only sometimes) or you want to know what the prototype (parent) of an object is. Or you want to try out a math expression. You can do all of those things, and more, in the console, which makes it a good way to quickly test something you're unsure of, especially if it could take a while to get it right by writing it, saving it, refreshing the browser, and then manually testing.

Test an entire function, or plug parts of your codebase together 'interactively'

This is one of my favorite things about the console: you can write functions in it, then test those functions, and plug them together with your existing code, or plug parts of code together that haven't been "wired up" internally just yet. Maybe you have some type safety concerns, or maybe you're creating mock objects for testing. This can be a good way of doing that. If it's a unit test that you want to repeat, you're better off just making unit tests.

Because functions are first-class functions, we can do all kinds of nutty things in JS. Just be careful to NOT use recursion, because it's a great way to freeze your web browser.

Dynamically inject code and inspect properties

If you pause your code, your console will have visibility of the current scope. So, if you put a breakpoint on a line where a variable, x, is set to something else, call it y, you can use the console to get the current value of y dynamically. You can even set x to something else! You can do all of this without pausing - as long as the objects are global. this allows you to test and modify instance variables, or look inside of inner loops to see what the devil is going on. It can be faster than using watch expressions, and much more flexible.

You can even call functions at certain points inside the code, internally. Be cautious, because this can still cause side effects, and the results might be completely, utterly wrong, because suddenly the browser is executing code out of the order it was intended to be executed in!



The console is a great tool in Chrome, and has some features not found in most consoles - and therefore worth writing about here. In particular, the ability to wire together system components with puppet, "tonka toy" parameters or values, and check that they work before committing to writing the full-on system is an invaluable tool. I use the console regularly for all of these things. It saves a lot of time spent writing and then checking - especially since, in Javascript, runtime errors are the best you can hope for.

Debugging JS: Part One, "Sources"

Debugging JS Part One -- Sources

Debugging is vital to success in just about any language. Odds are, eventually you'll want to investigate the contents of something or watch the step-by-step execution of your program. I'll show a few of the debugging tools available to the JS programmer in the Chrome console.

There are two main views you'l want to familiarize yourself with for basic debugging: Sources and Console. The former allows you to place breakpoints, watch expressions, and step through code line-by-line like in the Eclipse Java debugging suite. The latter allows you to rapidly test your functions, type safety, and more. Between the two of them and Google, there's virtually no bug in JavaScript you can't solve.

Open the developer tools in Chrome with F12

The first of a three part series.

Part One, "Sources"
Part Two, "Console"
Part Three, "Profiling"

Sources

After opening the developer tools and clicking on sources, you should see something like this:

There are some components of this UI that will be skipped for this basic overview. We'll cover the watch expressions, call stack, scope variables, breakpoints, and the symbolic buttons on the upper right, as well as the source panel itself.

Clicking on the small button in the upper left (the one that looks like a "play button" triangle) should show something like this:

Here, you can browse the document hierarchy. A side benefit of this is that it only has access to the loaded source files, so if you want to check if a .js file is even being loaded, this is a good place to check quickly (or, of course, the html page in question).

Opening a file, we can view it. Next, click the Play/Pause button; the one in the upper left of the right-hand pane of this view, that's highlighted in blue below. This will cause the script to pause (if you have an update loop, as in this example, it is virtually guaranteed to always stop in code that is "close to" the browser-level code. In this case, the code we arrive at after pausing is the function that's used as a callback with the requestAnimationFrame function.

From left to right, the buttons in the cluster with the play/pause button, are the step over, step into, step out, deactivate breakpoints, and pause on uncaught exceptions buttons. You can also use the F-keys to step through the code. Note also the call stack: right now, we're in engine.frame. This can be extremely useful information, knowing where we came from. The scope variables section shows all of the variables visible in the current scope. Breakpoints is empty because we didn't pause on a breakpoint; we just told the code to stop.

Let's create some breakpoints. We can do this by clicking on the line number next to a line of code:

Here, we have two breakpoints. Inside the Breakpoints section, we can see both are "checked". If we uncheck one, it will temporarily disable it without removing it entirely. You can click again on the line number or right click the breakpoint in the breakpoints list to remove it entirely. It works pretty much the same way as it does in a proper IDE.

Here's adding a couple of variables to watch in the watch expressions panel:

Note that the difference between a watch expression and a scope variable is that you can make a watch expression be anything. This means you can "tunnel" several layers deep, like watching foo.bar.goo.gah.boof.x, or evaluating a function, like watching the return value of foo(x,y). Note that, if you have side effects of functions, odd behavior may occur, so use this technique with some amount of caution!

Finally, if you click the "show/hide drawer" button (highlighted in blue below), you can have your console and search bars show up inside the sources pane. If you have the screen real estate for it, I recommend doing debugging in this way.

Next up: We look at the Console functionality, learn how to write code on the fly and insert it into our application, and use the console to test code!

MS Surface Pro 2: Preliminary thoughts, concerns

So, after much contemplation, I decided to get a surface pro 2, for a number of reasons; one of the top three reasons was this class. Being "grounded" to a desktop rig is becoming more and more inconvenient as my school career progresses in general, but having to do a "large scale" software project with a team really demands some kind of portable computer. The other two top reasons are general convenience and general school.

Thoughts:

1. I can't comment as to developing Java or C++ on it, but so far, C# and Javascript have been a breeze.
2. Wifi adapter is very well-made. Other mobile devices and laptops I've used get far weaker signals than this thing does.
3. The tiny keyboard is surprisingly easy to use. I keep hitting " ` " instead of " esc ", though.
4. The touchscreen is also surprisingly intuitive. I find myself using it all the time to select text and scroll through doc pages instead of using my wireless mouse.
5. Not needing a wireless mouse is nice; I loathe trackpads.
6. The battery life is good; not amazing, but then this is a quad core computer.
7. This gives me a convenient platform to test our game for touchscreen devices; since our game is so similar to SpaceChem, and since SpaceChem is easy to use with a touchscreen, it seems natural we'd want support too.
8. Works well for drawing things; UML and Google vector graphics, as well as drawing applications.

Concerns:

1. Annoying trackpad.
2. Potential stability issues on the battery saving mode; I think what happens is the hard drive stops getting enough power to operate stably, or it cuts the RAM it can use and is constantly reading/writing to virtual memory; either way, the result is insane thrashing, resulting in a basically unusable computer. Switching off of battery saving mode fixes instantly.
3. Windows 8

So far, the pros vastly outweigh the cons; though I will concede the cons are fairly significant. It's looking to be a nifty little mobile software development platform.