Alieniloquent

I just wanted to poke my head in and say that I’m still around, and still working on/thinking about the erlang project. I am, after all, still giving the talk next month.

I am, however, getting super busy with school. So, I’m having to sit down and schedule all of my non-work programming time. It’s looking like the erlang project isn’t going to get much love until after the end of September.

That said, when I get a few free moments this week, I’ll post some code I’ve already written that makes a nice interface around shelling out from erlang.

It was suggested that I use CouchDB as the storage engine for blogerl. I’m not going to be using CouchDB for this project, and I would like to explain why.

My reason for choosing Git over CouchDB is really just a preference. I think Git is neat, and I want to use it in a novel way. I’d like to demonstrate how it is a very powerful tool and can be used to do more that just version software. I think CouchDB is cool, and at some point, I’ll probably do a project with it. But, for this project, it’s not what I want.

In my previous post, I discussed the goals and priorities for blogerl. This time I am going to brainstorm some stories and prioritize them. Then I’ll select the first few from the prioritized list to be my first iteration. The goal is to have something I can deploy so I can get the blog started as soon as possible.

My philosophy for stories is to give them titles that are short. The story names are simply mnemonics to assist with recalling conversations and other details. Since I’m a team of one, the only conversations will be those I have here with you. But after this post, I’ll probably just refer to the stories by their title.

Here are the stories in priority order:

Storage

I need some way to store my posts. I’m not very choosy about how this is done. But, because I am in an experimental mood, I’m going to opt for using Git. I’m probably going to end up using Grit via erlectricity. There’s already been a wiki built on top of Git, why not a blog?

RESTful interface

Like I said before, I don’t want to compose my posts in a <textarea> but I do need to be able to get content into my application somehow. So, I’m going to design a RESTful interface to my data store. This is going to have to include an authentication mechanism, since I don’t want just anybody to be able to update or edit my blog.

Emacs mode

My preferred program for editing anything is Emacs. So it seems only natural that I’d choose to write my first REST client as an emacs mode.

Index

A front page that shows the posts in reverse chronological order. Should be paginated with 10 posts to a page.

Single

Permalinked pages for each individual post.

RSS

Add an RSS feed for the main index.

Atom

Add an Atom feed for the main index.

Archives

Provide archives based on year and month.

Templates

Templates for each of the views. Not YAWS pages. This will involve creating my own template language. I don’t like ErlTL for this as it is too programmery.

Caching

Keep rendered content in a cache with a TTL. Expire the cache for the index page if a post is added, edited or deleted. Expire the cache for a single post if it is edited or deleted.

Tags

Be able to specify an arbitrary number of tags to associate with a post. Provide archive pages for each tag.

Comments

Provide comments. They do not need to be threaded. Plain, flat comments are sufficient.

Trackbacks

Provide the ability for other blogs to post trackbacks.

Post-dating

Give the ability to submit a post that will be published at a later date.

Markdown

Add support for formatting a post in the Markdown formatting language.

Textile

Add support for formatting a post in the textile formatting language.

Formatting default

Add a configuration option specifying the default formatting (which starts out as plain HTML).

The first six are going to be what I aim to complete before I tag an 0.1 and deploy to my webserver. That’ll give me a means to share my blog posts with people as a stream or individually via their browsers or via RSS feeds.

First off, I’ve decided on a name for my project: blogerl. I will be hosting the source code here on GitHub.

With that bookkeeping out of the way, I’ll get to the meat of the post. I want to include you in my brainstorming process as I figure out what my goals are with this project. In my next post I’ll brainstorm features that will help me meet these goals and select a subset of those features to implement initially.

Before I can start brainstorming features, I need to figure out an overall vision for what I am trying to build. So the first thing I want to describe is the primary goal of this system, and possibly some secondary goals as well.

I want a system that will manage the storage and presentation of my blog content. That content will be primarily textual, and may be annotated with various pieces of meta-data (e.g. date, title, or tags).

That’s pretty vague, and I can design several extremely different systems that will deliver on that, so I’m going to provide some additional goals, in priority order, to narrow the design down.

Adding or editing content should be easy.

So many blogging tools are a pain to use. I’ll be honest, I’m not the biggest fan of the web application. Especially not for things like writing. I intend for Omniloquent to frequently have essays, and I don’t really like doing massive amounts of writing in a <textarea>.

Viewing the website should be fast.

This isn’t usually a problem in most modern blogging tools. However, I’m writing this one from scratch, so it’s going to be a little less modern at first. I don’t want people to be sitting around waiting for my content to load. I want it to be snappy. The closer to static content it feels, the happier I’ll be.

Adding or editing content should be fast.

The converse of the previous goal: I don’t want posting to take forever. This is why I hate Movable Type. The idea that I should have to rebuild dozens of pages when I just update a single post is ridiculous. However, I am willing to suffer a little, as I recognize that I’d rather it take me a second or two to post but have the blog be lightning fast for my readers. That said, the closer to instantaneous posting I can get, the happier I’ll be.

On October 14th, I will be giving a talk at ODYNUG about advanced erlang. Unlike my previous talks, this one is going to delve into the code of a real application. I’ll be discussing the architecture of the application and the reasons behind the design decisions.

Of course, in order to do that, I need an application. More specifically, I need an application for which I know all the reasons behind the design decisions. So, I’m going to write one, and I’m not a person to buck a tradition, so I’m going to write a blog.

I’ll be documenting the process here, and you can see the blog live here.