If we don’t adhere to the SRP then we are likely to end up with code which does more than it should, this means that altering one part of that code could negatively impact a seemingly unrelated part of the same snippet. It also makes our code a lot less flexible in that we find our code is trying to do too much; it is too specific in its job to be portable and reusable. Abstracting chunks of functionality into several responsibilities means we can reuse a lot more of our code and recombine it over and over with other similarly abstracted chunks.

We work a 4-day week (M-Th, 9-6) because we think that information work isn’t like manufacturing. Another hour at the MacBook won’t yield another $1,000 in profit. We believe that smart folks can get five days of work done in four days. Simple as that.

Tinycon allows the addition of alert bubbles and changing the favicon image. Tinycon gracefully falls back to a number in title approach for browsers that don't support canvas or dynamic favicons.

Alerts in the favicon allow users to pin a tab and easily see if their attention is needed.

Scriptular is a javascript regular expression editor. Inspired by Rubular it gives you a simple way to test javascript regular expressions as you write them.

Douglas Crockford has been teaching a useful singleton pattern for achieving this discipline, and I thought his pattern might be of interest to those of you building on top of YUI. Douglas calls this the “module pattern.” Here’s how it works:

commonly used features in a side-by-side format

I love Django’s documentation. It clocks in at about 700 pages printed, and most of it is clear, concise, and helpful. I think Django’s among the best documented open source projects, and nothing makes me prouder.

If any part of Django endures, I hope it’ll be a sort of “documentation culture” — an ethos that values great, well-written documentation. To that end, I’m writing a series of articles laying out the tools, tips, and techniques I’ve learned over the years I’ve spent helping to write Django’s docs.

This advice will mostly be targeted towards those documenting libraries or frameworks intended for use by other developers, but much of it probably applies to any for of technical documentation.

JavaScript is a Gestalt language.

One's sentiment toward JavaScript flips between elegance and disgust without transiting intermediate states.

The key to seeing JavaScript as elegant is understanding its warts, and knowing how to avoid, work around or even exploit them.

I adopted this avoid/fix/exploit approach after reading Doug Crockford's JavaScript: The Good Parts.

Doug has a slightly different and more elaborate take on the bad parts and awful parts, so I'm sharing my perspective on the four issues that have caused me the most grief in the past:

how to fix broken block scope with with;
the four (not three!) meanings of this;
promoting arguments to an array; and
avoiding truthiness.

Over the last few years we've developed a number of techniques that allow a database design to evolve as an application develops. This is a very important capability for agile methodologies. The techniques rely on applying continuous integration and automated refactoring to database development, together with a close collaboration between DBAs and application developers. The techniques work in both pre-production and released systems.

I follow a style of development that greatly reduces the risk of big projects like Storm. I call this style "suffering-oriented programming." Suffering-oriented programming can be summarized like so: don't build technology unless you feel the pain of not having it. It applies to the big, architectural decisions as well as the smaller everyday programming decisions. Suffering-oriented programming greatly reduces risk by ensuring that you're always working on something important, and it ensures that you are well-versed in a problem space before attempting a large investment.

I have a mantra for suffering-oriented programming: "First make it possible. Then make it beautiful. Then make it fast."

I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented. For this system to work, you first need to declare a public API. This may consist of documentation or be enforced by the code itself. Regardless, it is important that this API be clear and precise. Once you identify your public API, you communicate changes to it with specific increments to your version number. Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

I love the font Inconsolata. At bigger sizes and higher resolutions, it looks incredibly smooth and clear, and avoids the messy sort of feeling that Monaco gains as text density increases.

One thing that bothered me about Inconsolata, however, was the fact that its single and double quotes were slightly slanted or curly. It especially bothered me when using single quotes and commas, as the two looked visually similar, and my eye kept jumping levels.

As such, I made my own modification using the Font Forge source script, and named it: Inconsolata-dz

Korma is a domain specific language for Clojure that takes the pain out of working with your favorite RDBMS. Built for speed and designed for flexibility, Korma provides a simple and intuitive interface to your data that won't leave a bad taste in your mouth.

Nat was in town, and he stopped by to say hi and chat, and he said, "So we've got this big pile of code we're going to release, and we're going to build an open source groupware system! It's going to be awesome!"

way cooler identicons

No program can say what another will do.
Now, I won’t just assert that, I’ll prove it to you:
I will prove that although you might work til you drop,
you can’t predict whether a program will stop.