Reduce. Reuse. Rehacktor.

First Post


The road to digital hell is paved with abandoned blogs. Hopefully this is the time I stick with it. I had a blog on Posterous. And, even though I only occaisionally posted to it, I must admit I was a bit taken aback when Posterous announced they were closing up shop. Their backup system worked very well, but it made me think about the nature of blog content and why RDBMS based systems are the de-facto back-end for nearly every blog on the planet.

I think the most common, simple answer is that it's easier to implement a dynamic CMS using a database than with a text file-based system. It is certainly possible to create a content management system with a WYSIWYG editor that saves articles to disk in a human-readable format such as markdown. But it's just that little bit more complicated and it depends on the hosting environment to have file permissions setup just right. Otherwise a user could conceivably use the file editor to modify files all over the file system. But why a WYSIWYG editor at all? Why a dynamic system for what is primarily static content?

I have dabbled in DotNetNuke, Drupal and Wordpress at various times. And I usually end up wondering who these systems serve? When family and friends ask me about setting up a website or a blog, the conversation usually starts with questions about one of those three systems or another like it. Recently my father has started using Google Sites (which is a topic for another day). But even he asked if he should maybe be on Wordpress instead. In all these cases, I try to convince the person that a website isn't that complicated. It only seems that way because systems like Drupal and Wordpress and tools like Dreamweaver and Expression Studio apply layers and layers of noise over the top of a process that should focus on getting content into the system and displaying that content in a way that pleases the author. It doesn't require a full MySQL database or fifteen nested HTML tables with unintelligible, computer generated IDs and classes to pull that off.

In our pursuit to get people contributing content online, we developers have been giving out fish rather than teaching people how to catch them for themselves. There may have been a time and place for that, but it's gone now.

Most everyone who uses a computer or a smartphone can wrap their brain around giving a portion of text special meaning in a computer. The @ and # tags on Twitter have seen to that. It's not that much of a leap to think that those same people could learn the high points of markdown syntax in an afternoon. Combine that with a quick tutorial on the care and feeding of a simple, single branch git repository and maybe a Heroku build-pack containing a simple text-based blog engine like Poet or just a Github account and content creators would really become masters of their own destiny.

The benefits of managing text files with git are many. Keeping the content in a text format means it can never be locked up by a piece of software. And the content will be easier to migrate to a new distribution system as technology moves on. Using git to manage versions and releases means there should always be multiple copies of the content so total loss is unlikely. It also makes it easy to share content creation duties with other people because it's just a pull-request away. Developers know this. It's why we have Github.

I believe that version control is an essential skill for the future. I'm betting that in five or ten years, not being able to wrap your brain around version control concepts and usage will be as big of a disadvantage as being illiterate is today. If you know how to use git or mercurial please take the time to teach someone else how to use it as well. And if someone asks you for a recommendation about how to get a website setup, please encourage them to use Github. We need more fishermen and women on the world wide web.