on creating nebula

I have a pattern of hating any program that I could “easily” write myself. It ultimately means that I spend a lot of my time writing code for solutions that already exist in some form. In the past, this came to light when I created a chat plugin for the bukkit, which was, at the time, the de-facto choice for managing multiplayer minecraft servers. I called it suckchat and claimed that all of the other chat plugins sucked. Sure, mine did too, but I had created this one and was free to do whatever I wanted with it.

My frustration with other peoples’ tools has led me to my latest endeavor: a project which I have very descriptively named nebula. Boiled down, it’s probably a website management platform. The main goal of it is… nebulous. I now work on it as an experimental/hobby project. This post is the first time I have been able to use it as a way to show anything to the public which means I have finally shipped a minimum viable product. Getting here has been hard though. My hobby projects tend to become abandoned as I lose interest in them, their requirements tend to grow as I pull in dependencies, begin to hate them, and decide that I could write something better. I suspect that is not a unique problem to me.

the stack

This instance of the site is served behind an nginx reverse proxy. nebula itself acts as a hub for interaction between the plugins which are used. The plugins used to serve cosban.net are as follows:

  • magnetar: an application for serving dynamic and static web pages.
  • sol: a user registration/management plugin. All it does is handle the login and registration of users.
  • rover: used to send emails to users (especially for registration)
  • aurora: a user permission manager
  • stasis: the tool which allows me to write blog and wiki entries in markdown

All of these plugins depend on common interfaces which have been defined in my core library which should probably be broken up even more than it currently is. Maybe I’ll get to that.

Further behind the scenes is persistence which I have developed out of my frustration for other database interacting libraries. I use it as a query builder/ORM to interact with postgres.

Usually the software I write is available for use under the MIT license

future goals

  1. The entire project seems to not use a lot of resources. As of writing, it appears to be using 36KB in memory. It should probably remain lightweight in that way.
  2. It should be able to handle a high load. It’ll probably need to support distribution at some point in order to do this.
  3. persistence needs to become fully featured. It currently works for most of my use-cases, but not all of them.
  4. support for metrics gathering would also be nice as I currently have no way of auditing anything that happens.

Maybe now that this is in the public eye (to be fair, no one is looking anyway) I’ll be motivated to continue working on this. Even if a gradually more usable product is developed, over a long period of time, I will consider that a success.