This page explains why this site exists, how it was made, why it was designed the way that it was, what I have planned for it, and so on.

Introduction

This is my main website, so I store as much of my work here as I can: I use it almost like a public home directory, and since it's public I try to make sure that people can access all the data I've published. For example, a lot of the site is backed by CGIs, but none of the sources of these were available, so I wrote a service to expose all the innards of the site. Also, for every .tar.gz file that I upload, a script munges it on the fly giving you HTTP POST access to each of the files within the archive without having to download it first. I've also made a little script that does nothing but list the directories and files in the site (so nothing is hidden), and even made all of my .htaccess files public after deciding that they don't pose a security risk.

History

I'd previously been using infomesh.net as my main site, but by 2004 that'd gotten really messy, so I decided to start over again. Aaron Swartz and Christopher Schmidt offered to host the new site on their servers, so I set about thinking up a new domain name. I take naming rather seriously, so it took me probably a couple of months before I finally settled on inamidst.com, on April Fool's Day 2004 (see more about the name). To complement the name, I designed a simple logo for the site too, and settled on a style for the home page which now has echos throughout the site.

Principles

There are several principles that inamidst.com adheres to. The first is that the site is to be static, which means that no CGIs or anything else are to write to the filesystem. This enables much easier backup and syncing between boxen. The second is that, as described above, as much of the underlying data and scripts should be exposed as possible. The third is that the styles should be clean and modular, exposing as many patterns as possible. (@@ More.)

Servers

The site has been hosted on the following servers:

@@ This should be an illustration, with horizontal bars indicating the spans of each server's use.

Workflow

Usually I edit files on a locally maintained mirror of the site, and then rsync it to the server or servers using rsync -avz. I have a secret directory within inamidst.com itself where I work on things before releasing them publically, and often have more going on in there than in the rest of the site, because I tend to be a bit of a perfectionist about releasing things.

@@ Friends, server information, etc.

(The following was written earlier, and should be moved to its own page and updated.)

How This Site is Organised

“The clutter is inherent in the organism”

—William Loughborough, noets 35

For most people, the problem of organization and taxonomisation is a tedious one which is forced upon them. For other weird folk, however, it's a joy. I fall in-between the two categories: I think it's an unfortunate necessity, but it's an interesting task. As with all topics, the extent to which is is boring is relative to the beholder, so I'll just rant about it regardless.

There were a few obvious possible approaches for organizing this site:

• a) date-stamped hierarchies, a la the W3C;
• b) randomly named directories up the wazoo (er, that is, a profliferation thereof...), named as appropriately as possible;
• c) a Borgesque Emperor's Animals classification;
• d) a Thesaurus or Library catalogue based hierarchy;
• e) the unix FHS.

Previous sites of mine have tended towards a combination of a) and b), but I've decided to go for b) with some e) instead.

I decided against datestamped directories specifically because whilst they scale well to large site where many people may be contributing, for a small site they get confusing quickly. Some people are terrible at remembering dates, so it's best to avoid them where possible. PURL don't use datestamped folders, and no one complains; in fact, not many people do other than the W3C. They're also rather culturally dependent: people think of our calendar as pervasive and rigid, but it isn't really.

Since I've chosen the b) and e) combination, I've had to contrive a style guide for the site to adhere to as best I can: keep names short and as unique as possible; give more important things shorter names (e.g. use /misc a la /usr in the FHS); group things together in folders only when necessary; make names generic, leaving information out where possible. (Or, as I put it on #disobey: the usual taxonomization tips: keep it brief, keep it generic, leave information out, keep your URIs short and readable, no file extensions, group by the most important features, most important stuff should be closer to the root).

One problem with these tips is that it's difficult to know in advance just how important something is going to be, which is essential in publication since you need to know how close to the root to put it. So if you write a piece of code called "yay", do you put it at /yay/ (popular) or /proj/miscellaneous/yay/ (not so popular)? One of the ways that I've got around this is to let things simmer in the /dev/ directory for a while before moving them to the rest of the site; and having /misc/ as a more public staging post, though I've only moved a few things from there so far, e.g. /misc/updates which proved to have needed to be at /updates given its utility.

I've also pondered using strange keyword mod_rewrite to CGI mapping systems, but for portability's sake, a static approach is preferable.

Issues: Stuff You Can Help Me With

@@ Not sure how documentation should be arranged. For example, if I publish the args parsing script at /args.py, does the document go at /args-doc? Or do I have redundancy with /args for the documentation and /args/args.py for the script?

@@ More generic names: "flotsam", "jetsam", "stuff", "general", "data", "things", "sundry", "trove", "etcetera", "oddments" (C18), "symposia", collectanea (instructional anthology), analecta (collection of literary fragments), delectus (classics instruction book)...

@@ This site uses a mixture of en-GB and en-US; should there be some language code that describes the union? Just en?

Feedback

You can send feedback (or ask questions, report bugs etc.) by using the following form:

You may also email me.