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.

A closure stores information. It can have access to a single parameter given to it at runtime; or to an internal data structure it can use to make decisions; or even to large chunks of your program’s state, letting you pass behavior without needing to pass information. In this post, I’ll show you how to use closures to work with arrays: in a few lines of code, you can grind a nested data structure down to just a handful of targeted values. With a few more, you can transform them into anything you need. And with a pinch of closure fairy dust, you can make those filters and transforms magical, building powerful and intelligent functionality up from a few lines of initializer code. The results will fascinate and horrify. But mostly fascinate.

In the previous post, we looked at how anonymous functions can simplify code structure, but we skirted around their most powerful capability. An anonymous function can hold additional data, beyond what it gets from its arguments, and it can use that data in its work.

By holding extra data, an anonymous function can be custom-designed, on the fly, to perform a specific duty; it can apply special logic it normally couldn’t have access to; it can access application state; it can even “transform” other functions, changing their behavior, without needing access to their internals, through a sneaky substitution known as “wrapping”; but before we can put closures to work, we need to understand what makes them tick.

In ActionScript, functions are objects which can be stored in variables and passed as arguments, just like any other value. Since functions are treated just like any other object—like “first-class citizens,” if you will—AS3 is said to have “first-class functions.” This lets us do stuff that would be cumbersome in other languages, but it also throws a whole new set of potholes in our path. This post shows how to use first-class functions for state-based event handling, user input interpretation, and array filtering, but I’ll begin with something you’ve seen a million times before: the lowly event listener.

underscore.as is an ActionScript 3.0 port of Jeremy Ashkenas’s excellent underscore.js library. Like its JavaScript original, underscore.as provides a quick syntax for functional programming concepts. Unlike the original, underscore.as is not idiomatic: it doesn’t look like the kind of ActionScript you probably write every day. You may have to adjust your programming style to take full advantage of it. I hope this quick introduction will explain why you should bother.