dangerous lives of alter boys
a cross between igby goes down and american splendor. good.
a cross between igby goes down and american splendor. good.
i can’t say i cared for this movie. in fact, we turned it off about halfway through. it felt too much like a play (i know, surprise, surprise).
ingredients:
cover and bake at 350 degrees for 25 minutes.
this a very different movie than the first volume — much less gory, and with a different (slower?) pacing. right after it finished, i was pretty sure i wasn’t a fan of the movie, but a few days worth of reflecting on the movie have left it with a much more favorable impression. i will certainly see it again, at some point, and i’m confident i’ll enjoy my second viewing.
running across a 100 peep eating challenge page today reminded me of a similar page that i wrote up nine years ago. so, i guess i’ve been coding webpages for nine years. also, that homepage of mine that lives over on the stolaf servers is pretty hott.
what i want in a web photo gallery (in rough order of importance to me):
it should be easy to look up photos in different ways, specifically, by date, subject (this includes people in the photo), event, or possibly some other ways i haven’t yet thought about. all of these types of groupings should be easily accessible from the front/first page of the photo system. it should also be easy to jump between all these quickly, thus, if a photo belongs to a certain date (which it always will), subject, or event, all of these should be linked to from the photo’s display page. have some easy way to turn any grouping of photos into an RSS/Atom feed, e.g. “last 10 st. paul photos.”
it should have some kind of clever way of dealing with metadata. figuring out what to call the metadata is at least half the problem. should photos have optional captions or descriptions? would people in the photo fall under a people category, or subject, or just the generic keyword? also, all the metadata should be searchable, even if just by some sort of power-user feature.
it should be easy to import new photos into the system. this step can be especially problematic when it comes to metadata that is not obtained “for free” (i.e. EXIF information that a camera provides). there should, at the bare minimum, be some sort of queue or method to allow quick entry of the photos and/or associated metadata into the system. also, it should create any necessary thumbnails and medium-sized images as necessary during an import stage, check for duplicate photos, rename photos, consolidate the photos into a centralized location in a reasonable matter, etc. all of these things should be configurable (see the installation requirements below).
it would be nice if anybody could contribute photos and metadata to the system (so, not just the website’s maintainer). this would require some sort of user system. it might also require some sort of moderation system, so that the system didn’t get spammed with bum content. allow user favorites, and possibly photo rating.
it should be skinnable, i.e. easily changed to fit into an existing website. perhaps use some sort of template system; at worst, just make a very modular main index file, and try and separate out the html as much as possible. do the html using divs and css, and that way css can be used to replicate the look-and-feel of the site.
it should have pretty URLs. use apache redirect to allow things like “/photos/events/montana” or “/photos/album/graveyard”, “/photos/date/2004/04/01/” or perhaps “/photos/2004/”, or “/photos/people/seth” or even “/photos/search/devil’s lake”. ideally, all the page requests go to one central control location on the backend (a sort of main.php), and it runs the show.
it should not be a collossal pain to install. it would be nice if the system didn’t have too many dependencies on specific languages and/or libraries, though they are sometimes necessarry. this, though, is relatively low priority, since i would be more than willing to install any number of libraries to get a photo system that did all the above mentioned things well. more importantly, there should not be any hardcoded paths, SQL table names, magic numbers, etc.
it should be maintainable. i want to be able to have at least a basic understanding of how the code works, and if possible, it’d be nice to be able to tweak it to my liking.
support movies. i don’t really have any of these yet, but it’s worth thinking ahead.
note to self: i should discuss a specific photo system or two (i.e. gallery, and dave’s photo system), and how they handle / do not handle each of these methods.
note to others (especially dave): i’ll probably update this post as i go along in the process of trying to build a web photo system. if anyone else (that is, other than dave: you’re already involved, like it or not) wants to enter in to this discussion, drop me an email.
as i write this, i am sitting on a lawn chair out on my patio, barefoot, drinking a beer. what’s the temperature there, in frozen wisconsin, you ask? why, it’s 71 degrees right now. a little cloudy and windy, perhaps, but this is one gift horse i’m not particularly prone to look at in the mouth.
another good, old movie. it is, however, somewhat obnoxious when the final five minutes of the movie are jerky and barely readable by my computer. are you listening to me, studio execs? stop garbling up my movies on purpose. on an unrelated note, i once ate at the mildred pierce cafe (review) in st. paul. kristian suggested we go there after seeing this movie in a film class, or something. i had the hanger steak. it was awesome. so, the moral of the story is: this movie’s good, but the hanger steak is even better.