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.

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.

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.

The other day on Twitter, I was discussing workflow with my friend Geoff, and I mentioned that I use Git Flow for some of the work that I do. He mentioned that he’s a solo developer on most of his projects, and so he’s more of a GitHub Flow kind of guy. I’ve read Scott Chacon’s post on GitHub Flow in the past, and it’s a nice and light system. However, I find that Git Flow gives me some great power, and it seems worth discussing how it helps me as a solo developer.

I really appreciate the feedback on my Split Personality post. I got some good comments via a wide variety of channels, which kind of made me realize that really, I’m way the heck overthinking it and it’s okay to have some level of crossover.

I decided as a part of the process of figuring out what to do in moving forward, I’d look back. That’s when I read over all 688 posts I’d written on this blog. A few things stuck out at me:

• I was way oversharing things, especially in those first few years
• It was often way too wall-of-texty over mundane stuff
• No, seriously, overshare ahoy
• It’s funny to see how much tech has evolved in the ten years I’ve been running this thing
• Several posts were little one-off throwaways that are now tweets or Facebook posts
• There was way too much discussion about posting or lack of posting or other meta crap that meant something to me but is relatively meaningless to everyone else (in a sense, much like this post)