Event-driven programming is a flexible weapon… like a whip. Design things right, and a flick of the wrist can roll down the length of your architecture and knock a cigarette out of a man’s mouth with a supersonic snap. Design wrong, and a half-hour later you’re in the emergency room with a wadded up T-shirt clamped to your forehead.

As a front-end developer, I’ve whipped myself in the forehead more times than I care to count. Do that often enough, and you start to get an intuition about things. I’ve got a theory about event handling: make your decisions at the right level of abstraction.

Maybe this is old hat. It should have been old hat to me, too, but you can’t see how old a hat is when you’re wearing it. But first let’s talk about kinds of events.

Like a lot of folks these days, I use OSX at work. There’s a lot to love there. If I can get over the sticker shock, I’ll probably get a Mac myself on the next go-round. But for now, my personal laptop is a Thinkpad T520i running Xubuntu. If you’re on the same train, you might have noticed that ever since the 12.04 update, sometimes your laptop doesn’t quite sleep right. You close the lid and that crescent moon just sits there blinking quietly, and when you open it back up, the entire desktop has crashed, dropping you to the login screen. You log back in, nothing works right. You check the error report, and it says xorg crashed; you go deeper, and you find an error handling SIGABRT. What does it mean? You tell me.

I wrote a post about pry earlier, but at the time, I didn’t realize just how much muscle Pry was packing. Install two simple plugins and one builtin function, and you turn Pry into a stepping debugger. It can pause at a breakpoint, step through code one line at a time, and even shuttle up and down the call stack; and since you never lose your Pry superpowers, you can rummage around your state to your heart’s content.

A quick and easy way of commenting or uncommenting large blocks of code in languages with multiline comments, such as the /* wing comments */ found in C-like languages:

1
2
3
4
5
6
7

/* DEBUG: display complicated logging data
$.log("Baking.Cookies.recipe.build:",
  "recipe_id => ", recipe_id,
  "; recipe_contents => ", $.extend(true, {}, recipe), // deep clone
  "; options => ", options
);
// */

Right now the whole block is commented out; but when you cap the top wing comment, you get this:

1
2
3
4
5
6
7

/* DEBUG: display complicated logging data */
$.log("Baking.Cookies.recipe.build:",
  "recipe_id => ", recipe_id,
  "; recipe_contents => ", $.extend(true, {}, recipe), // deep clone
  "; options => ", options
);
// */

Your code editor certainly provides a way of toggling comments, but over large code blocks this may involve making a large selection first. With this technique, adding or removing just two bytes can toggle comments on a block of any length.

We recently completed a major feature at Paperless Post: a full undo/redo system. The post covers the Command pattern, and how easy it is to implement in both JavaScript and ActionScript… and how hard it is to apply that implementation to a large living application. I’ll be posting some specific war stories in the future, but for now, click through and enjoy.

Every day or so, there’s a new front-page HN article about Git. New GUIs, for those who find the command line ugly or abstruse. New CLIs, for those who find Git confusing. New workflows, for those who can’t quite get Git to fit their style. New tutorials, for the long tail of new Git users. New deep-dive technical articles, for those who can’t get enough of SHAs and refs.

Here’s where to start, if you’ve got a few hours to burn; but if you want my opinion, you don’t need any of that. I use Git to get work done, and here’s how.

I used to use Python for my everyday scripting tasks, but since I started working at Paperless Post, a Rails shop, I’ve felt like investing some skill points in Ruby would be a wise investment. Ruby is fun to write, but my workflow suffered from a severe lack of interactive programming support. No, irb doesn’t cut it, not for someone used to the mighty Dreampie. I was heartbroken… until I discovered an alternative. It’s not a single powerful app, like Dreampie — instead, I had to stitch together several tools to get the same effects. But it makes exploratory programming a breeze, and that’s more than I can say for irb.

To build this interactive-programming Frankenstein’s monster, you’ll need three tools: vim, tmux, and Pry.

Documentation sucks.

The process of documentation sucks, so developers resist doing it. Hacking on a library is fun, but explaining precisely how to use the library is not. Perhaps an early run-in with the keyhole essay imbued the coder with a lifelong distaste for exposition; perhaps blank-page syndrome attacks the would-be documentor the moment he loads README.md into Sublime Text 2; or perhaps it is simply that instructing the computer comes more naturally than educating humans.

When there is a stab at documentation, it is often halfhearted. API docs generated from code which has no doc comments, sparsely commented example apps with no explanation of the underlying concepts, a one-page “quick start” with no further elaboration: these sins are widespread, and although they may be widely scorned, they are also widely duplicated.

But somehow, documentation for open web technologies is worse.

The previous version of this site was built on Django, mainly so I could try it out. Django impressed me with its powerful templating, admin, and plugins, but I think I tried to get too cute with it: I had a test subdomain with its own database, I had multiple settings files for different contexts, I had custom comment display and submission forms, and on and on, and simply put, I wasn’t writing.

Modern JavaScript is firmly on the side of magic. Why write a hundred-line set of meticulous loops when you can write a ten-line filter chain? Why invoke a factory object dozens of times when you can write a map function? And if you want your application’s behavior to change from moment to moment, why use explicit states, or a Strategy pattern, or reference a global flag, when you can just swap out the functions themselves?

And why swap functions yourself? Let the functions do that for you. Wind them up. Let them run.