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.
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.
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
debuggerstatement or set a breakpoint to stop execution and use the console and/or watch statements to observe the value
- Inject some
console.logstatements 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
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 doesn’t have a meaningful return value, the
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.
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.
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.