Reflections on building software for, and with, people.


What do you have to say? If you don’t know, there’s not much use in adding all that other cruft. Just start with one page, with a single focus. Write it and publish it, and then iterate on that. Every time you’re about to add something, ask yourself: does this help me communicate better? Will that additional styling, image, or hyperlink give my audience more understanding? If the answer’s “no”, don’t add it.

Like Justin Jackson, whom I just quoted, I too was impressed—no, that’s the wrong word, maybe “inspired” in the sense of being literally filled with fresh air—with Jason Fried’s homepage for 37 Signals’ new service, Know Your Company. One page, with lots of words, and they’re great ones. We’ve become so obsessed with connecting things by collecting and liking and associating that it’s easy to forget how people have been connecting for all time: by talking to one another. The internet’s still pretty damn good for that, even as it becomes good for so much more.

Via Jeremy

Continue reading...

Dynamic Error Pages With Rails 3.2

I’ve long struggled with how best to implement dynamic error pages in Rails. The default solution, simply rendering static HTML files from the public root, is appropriately simple for 500 errors where your app may not be capable of rendering a dynamic page, but falls short for less grave errors, especially the common 404. I’ll often want to render a 404 using my application’s layout so as not to confuse users, include partials such as for a search form, and I recently worked on an internationalized app where I wanted to translate the 404 message. Rails will serve localized static pages (e.g. 404.en.html,, but I’d rather keep everything in my locale YAML files and render it with I18n.t('not_found').

Continue reading...