Brian's place to dump random thoughts on life and code

2013 in Review


Inspired by several similar sorts of posts (and the realization that this will be only my second post this year), it feels like a good time to look at 2013, as well as to look forward a bit at some things I’d like to change next year.

Board Gaming Nights


TL;DR: Board games are fun. If you live in ABQ, we should play more. I have an idea on how to do that. If you don’t live in ABQ and/or aren’t interested in board games, you should probably skip this post.

Breakpoint Actions in JavaScript


Earlier today, I filled out the Chrome DevTools Survey & Feedback (which you should too, if you’re a web developer), and near the bottom of the survey, there was a question:

Are there any tools or features you think are missing that would better help you develop your webapps?

My initial answer was No, there wasn’t anything I felt was missing. DevTools are awesome, and there hasn’t really been anything I’ve felt like I needed.

Later in the day, I ran into a very common scenario: I was debugging something where I wanted to observe a value at a particular line of code. There are a couple of ways to approach it:

  • Drop in a debugger statement or set a breakpoint to stop execution and use the console and/or watch statements to observe the value
  • Inject some console.log statements to write the value out to the console

In this case, the console.log approach would be ideal. However, I didn’t have access to modify the code directly, and while I could have used the live editing features, it was also minified code, meaning that live edit was an ugly option.

Thinking back to the survey question, I now had an answer: Wouldn’t it be nice if there was some way to have some sort of action kicked off, breakpoint-style, where I’m not editing the code directly?

I asked some friends, and it turns out, other development environments have a similar concept. Xcode has Breakpoint Actions (as do some other IDEs) which look to be exactly what I wanted. While bouncing this idea around, I realized that I could actually fake it in the browser, right now.

Chrome supports conditional breakpoints. Adding them is easy. First, find the line you want to set a breakpoint on, and click the line number to apply a breakpoint like normal:

Then you right-click on it, and select “Edit Breakpoint”:

You’re presented with your cursor in a field like so, where you can define an expression. If the expression evaluates to a truthy value, execution will break here.

It’s not uncommon to set simple expressions like someObj.id === '1', but I realized that any valid JS expression would be evaluated any time this line was hit – including the console.log statement I wanted to add!

This approach works quite well. Looking over at the console after moving my mouse around a bit on this page (which happens to be the Chrome DevTools Breakpoints page), you can clearly see the added console.log firing:

Since console.log doesn’t have a meaningful return value, the undefined means the conditional breakpoint won’t pause execution, and the code moves on. It’s just like a coded console.log statement, without having to actually modify the code.

Using a conditional breakpoint like this feels horribly hacky, and yet, I love this idea. It achieves the exact goal that I wanted. It’s not elegant, it’s not by design, but it gets the job done, like so many other things in web development.

As an added note, Firebug supports conditional breakpoints in much the same way, and this approach totally works there as well. In both cases, it’s working simply because you’re just evaluating the expression, and only pausing execution if it evaluates to a truthy value.

Hopefully you’ll find this useful at some point! I already have.

Callbacks and Promises


Anyone who’s written even a little bit of JavaScript is likely familiar with the callback pattern. Even if you don’t know it by that name, you’ve probably written code using it. When calling a function, we’ll pass it another function as an argument, which will be used to let us know that something has happened. In particular, callbacks are frequently used for responding to things that happen asynchronously.

For example, event handling is based on this pattern. We take a DOM node and provide it with a callback function so that when the associated event occurs on that node, it has a way of letting us know what’s going on.

Full Reboot


So, I said that I was going to be using WordPress and not using OctoPress but after I got things all set up back in WP, I found the experience of writing to be kind of frustrating. I’d written some post drafts in Markdown, and have really been enjoying that format. I also don’t like not having version control in play. I was able to use Markdown for my WP posts, but having to edit in Vim and then copy/paste over and preview, it got kind of annoying.

While OctoPress is definitely a bit more manual than something like WP, it turns out that I’m okay with that. I’ve taken a little time in the evenings after my brain is burnt out on other things and used it to poke and prod OctoPress into doing what I want. This new site is the end result.