How This Website Works is served with the paste webserver. The [composite:main] directive is used to combine server WSGI webapps to make

static file server and presentation of directory structure: /
my repository of code and configuration using the hgpaste factory for mercurial's web service: /hg
my blog using a blog engine I wrote: /blog
paste .ini section:
use = egg:Paste#urlmap
/ = decoupage
/hg = hg
/blog = bitsyblog

Why decoupage?

Decoupage provides views into the filesystem. It is a good solution for a personal website as allows content management to take place on the filesystem with all of the superior tools already written for file manipulation. Decoupage allows me to organize the content as documents on my filesystem so that I can selectively present them. This has the added benefit that by organizing my website, I am also organizing my files, and vice versa. I find that the use and understanding of information is in direct proportion to the organization and presentation of the information.

Decoupage serves files using contenttransformer, which is used to transform raw contents, like Restructured Text or Graphviz files, into HTML or images if the filename matches the configuration found in that directory, or passing through to Paste FileApp if transformation is unnecessary.

Filesystem Layout

My website directory is laid out like the following:

all stuff on my website and also a virtualenv
bistyblog files
various paste .ini scripts, including mysite.ini which runs the website
paster PID file
paster log file
genshi overrides for decoupage templates (I also use site-nav.html for bitsyblog's header)
static files for decoupage (maps to '/')
my picture galleries
gallery of miscellaneous pictures
source of software used in my website


I also use SilverMirror to mirror files between computers. This allows me to have filesystems which are in sync and to be able to work on canonical documents whereever I am.

Current, SilverMirror is a poor from end to unison, but I hope to make it a unified from end for unison, mercurial, and other pluggable back-end mirroring mehodologies each having differen capabilies that are made accessible in a unified way to the user.

About this about

This document serves as an example of how a document-oriented website may be deployed. One purpose is to teach what you need to know to create and maintain your website with the utmost control over your work.

About this Portfolio

I use a document-oriented approach to my portfolio. For my software, I categorize my software by type of work. Each project gets a brief description, a list of resources, and possibly a screenshot or a date if applicable. The point is not to provide a thorough description of the software, but to give a high-level overview with extensive hyperlinking to relevent resources.

The advantage of a document-oriented approach for this project, which in this case is straight HTML files, is that the portfolio may be presented as desired, independent of other resources and with no database required. The document, if written semantically, can be programmatically manipulated through inclusion of a JavaScript file.

Unlike typical programming, which aims towards modularity for ease of consumption and reuse, a document-driven software portfolio should be as interlinked as possible so that the reader can follow the associations present in one's software development process (and, at the meta- level, one's thought process). This manner of saturated hyperlinking turns a set of documents into a complex directed graph with a high degree of informational density which may be extracted and presented programmatically. In addition to being an expose of one's work, a software portfolio should illustrate patterns emergent from experience in software development and information management.