100% homemade

After few hours of code improvement, the blog is now in a much better state. The biggest things missing are the RSS feeds and the wiki text engine, but apart from those, this is shaping to be a blog that i can finally use.

Compared to the hundreds of codebase for blog software, one might wonders why did i need to re-invent a new software or if it's just one a NIH syndrome. There's at least 2 features that were necessary, before i could actually have a blog productively:

• just text files: this is the biggest feature for me, since i want to be able to write my blog posts in vim or a curse interface on local files then synchronize the whole lot to the server that display them to the world. I also believe relational database are way overkill for basic usage like a personal website, but are also much slower [1] than a custom solution
• completly written in haskell: I'm more and more careful about what are serving things to the outside world, and that's why i'm phasing out all dynamic languages (python, perl, ruby, php) that need to be throughly tested and re-tested after every modifications. Not only that but those language are magnitude slower than Haskell. I'm also still learning Haskell, hence that's a really good test bed for me.

Haskell is absolutely amazing at everything i've tried so far. embedded parsing is a delight thanks to parsec, the static typing increase the productivity massively, and the rich library / expressiveness makes all those software design easy to shape.

This blog software is also one of the software brick for something bigger.

[1] whilst it's hard to judge the whole performance issue, I think the main issue with available database are the layer on top of the filesystem and the SQL engine.

Comments on this blog hasn't been implemented yet, however I'm close to finish the design of how they work. Long story short, the comments and tracebacks will not change anything on the server side, but will be sent to a queue for moderation/acceptation that can be processed locally on the machine where I do the actual posts.

The benefit for this approch are mainly:

• server-side data stays read-only from the webserver point of view.
• all comments/tracebacks are to be approved before actually posted: net effect on reducing spams.
• duplicated and OT comments can be filtered out.
• comments related to post update (something missing in the post for example) doesn't have to be posted, but just acted on.

As a simple prototype, my initial queue design is going to be on top of SMTP and email. Each time a comment or traceback is receive, instead of modifying a file or a database on the server side, a simple email will be sent to a mailbox after basic checked where issued (spam checking mostly).

As this point i can just process the queue of comments with favorite $MUA. The acceptation process is simply piping the email through a special adding comment binary, that will add the comment to my local data. All this just a simple $MUA macro that does the piping with a simple and swift keybinding. At this point the comment is not visible but will be as soon as I push the data back to the server.

Eventually, new queueing system can be developped on top of XMPP, AMQP. Also the queue processing could be done by a simple bot when the data doesn't have to be moderated.