I’ve been out of the web development loop for a while, and so coming back, as always in the web development world, I’m faced with an astounding array of technology choices. Here is a summary of what I chose, and why.
This project is half-something-useful, half-an-excuse-to-get-back-in-the-game. With that said, the itch I decided to scratch is to have an editor that will help me write a novel (or a zero-draft of one) in the upcoming NaNoWriMo. In NaNoWriMo, the philosophy is “no editing, no deletion, keep moving”. The classical NaNo philosophy is also “no planning”, but I do not subscribe to that part. My editor is meant to be aware of the concept of “outline”. I write my outlines as chapters, and then sections inside the chapters. Each section is meant to account for 500 words, which means my outline has to have at least 100 sections.
Because there is no editing and no deletion, I chose to leave that functionality out. There’s a way to add chapters, a way to add a section to a chapter, and a way to add content to a section. On too long idle time, or opening another content editor in some other section, or re-opening content editor in the same section, the content gets saved. There is no way to remove content. There is at least “export to HTML”, which exports this to one big HTML, with H1 for the book title, H2 for the chapters, and H3 for the sections. There is no way to format the thing other than textual notes.
The database I chose to use is Redis, just because I wanted to see how this whole NoSQL thing works, and it’s my company‘s product. Redis does not have a formal schema, as such, but it does have a convention that keys are made of colon-separated strings. I chose to have every book identified by a unique, unguessable string, and to have all keys related to a given book (list of chapters, sections, content-snippets) begin with that key, followed by a colon.
The backend is a Twisted server, serving up JSON in response to REST-style requests. The only REST verbs I use are GET and PUT (no DELETE — see above). The structure of the REST request begins with “/<unguessable book key>/” for every request related to the book. Inside the server, each such book is an object, and when creating that object, I check first the book’s title exists. This means that my security is very simple:
- There is no way to create new books.
- If you know a book’s key, you can add to it.
I will, at some point, have a UI to create new books, but this means that all security concerns have to exist within that UI (I will need to make some changes to the core backend if I want to add revocable rw and ro access, but those changes are fairly minor and right now I’m YAGNIing).
Front end — CSS
I’m designing my application to be mobile-web friendly. This means that I am using the viewport command to indicate there should not be any zoom-out, and also (to a lesser extent) trying to follow a mobile aesthetic. Those of you who know me are probably chuckling right now when I said “aesthetic”. I will probably ask for some design help at some point.
I heard enough good things about Bzr that I chose to give it a go. I’ve used it for pico-projects in the past, and liked it. I am still getting used to it!
Public source control
After some debate, I have settled on Launchpad. It seems to have all the features I need and is Bzr-friendly.