So, this thing (I don't know what to call it; is it a website?  a "web-app"?  Something else?) is basically a clone of Flickchart for albums.  Or, if you prefer, a clone of the Facemash thing that Zuckerberg did in The Social Network with albums instead of girls.

I realize that a sane person who had the goal of making such a thing would have used something like PHP or a real web framework like Rails, Django or something like that.
But, I don't think that the end product was/is really my goal -- I've just always found this project to be a pretty interesting thing to kind of idly hack on.

As with my Tetris project, I've tried to stick to a limit of 50-or-so lines per file, which has caused the same proliferation of files and subpackages as it did there.  At the time of writing there are a few files that I don't really think are up to snuff so far as prettiness, but I'm pretty happy with the project as a whole.  I've broken the project down into subpackages as follows:

the 'server' package contains the HTTP server.  DynamicGuts has a HashMap of String -> String -> PageHandler, which is used to invoke the proper PageHandler for each 'page' -- handlers are dispatched by HTTP method and first-part-of-path (more on this in DynamicGuts.java).  This package is the foundation of the project -- it depends on no other packages within the project and all other packages either directly or indirectly depend on it.

the 'util' package contains various miscellany that I haven't yet categorized well.  A lot of the files in this package are only used in one place, and some of them might be completely unused -- left over from previous implementations.  HTML and URLParse are just containers for static methods that do boring things regarding HTML entities and passing parameters in URLs.  Pair is a straightforward class containing two objects -- it is used only in NoncePool.  NoncePool ('nonce' meaning 'number used once') is basically a HashMap that generates its own random keys.  This class is used to generate most of the links that actually change things regarding program state -- specifically the 'victory links' that notify the server of a particular user's choice.  Since each request that actually changes state is associated with a unique 64-bit integer, spam-voting is not viable.  PageTemplate is used to 'fill in' the HTML pages with dynamic content.

the 'game' package contains various classes that, together, comprise the infrastructure of the project.  Album represents an album, User represents a user, Scoreboard manages an Album -> Integer ratings-map -- this is where the Elo rating system is all happening.  LastAPI deals with the Last.fm API.  At the time of writing, it's one of my least favorite files in the project, chiefly because the string manipulation that 'parses' the XML is extremely inelegant.  GameRuntime is perhaps another of my least-favorite files, because it's pretty much just the place where all the globals live.  It manages all the users and also handles the global scoreboard, things like that.  I'm not really sure that it can be any other way, but I'm still not especially happy with it.  Finally, the Main file that sets up everything and reads input from the keyboard is also here.

the 'handlers' package contains all the classes that implement the PageHandler interface, defined in the 'server' package.  These handlers pretty much directly correspond to either user-facing pages, or URLs that are GET'd to change program state.  ShowHandler is another ugly file -- it should really somehow be using the templating system I already have in place, but I can't at the moment figure out how to integrate them.  UserHandler is what does the significant work -- it calls on the user's scoreboard to pick a match, and then fills in and sends the proper page down the wire.  However, it's not really user-facing, in that it's never added to the map in DynamicGuts -- it exists to be called by GameHandler.  VictoryHandler and BanHandler don't generate responses, they exist handle the AJAX GET requests that are send by the Javascript in the generated pages (see match_template.html) to reflect the scoreboard(s) following a user's decision, and remove an album from a user's rotation, respectively.  That leaves FileHandler, which just ignores its arguments and serves a file.  It is used to show the front/gateway page.

the 'serial' package contains all the code handling serialization.  ProfileReader and ProfileWriter read and write User objects, and Persist writes and reads the entire program state.  No file format in particular is used; I just write stuff separated by newlines and read it with the Scanner class.