the lake

• the source of a photo can be a local file or somewhere in the network. when instantiating a photo object, the only mandatory parameter is the source, which should be a valid uri. currently only http and ftp are supported over the network.


• try to extract as much metadata as possible from the file (reading the exif data), but allow this to be overridden. if overridden, rewrite the exif data in the web version of the photo.


• use the file attributes to figure out the date and author. again, allow this to be overridden.


• there is a difference between shooting date (from the exif data) and publishing date (from the file attributes). an entry will have its date set to the latter, while displaying the former in its metadata section.


• the default for “web ready, don’t convert” (but copy, never touch the original file) will be 800x533 @ 72dpi (configurable).


• 800x533 @ 72dpi will also be the target for the large display version. the medium display version will be 600x400 @ 72dpi.


• adjust these values to respect the original file’s width/height ratio.

when rui released yaki, we ran a small experiment: he deployed a yaki installation, made a mercurial repo out of it and 4 people cloned it. then everyone made local changes, creating and modifying entries, and commited them upstream, where it was turned into a web site. this was mostly prompted by a post pedro wrote: long story short, wikis are mainly inefficient, glorified versioning systems with a web interface and sitting atop a database, and people keep re-writing them over and over again (i’ve been meaning to talk to you about this for a long time, kake). we can drop the versioning bit and do it properly with a real vcs, and we did just that using yaki and mercurial.

what i’m getting at is that there will be no user interface for publishing in yeti, at least from the start or written by me. what there will be is a library containing the basic publishing functions, which you’ll be able to use in your web app or what have you. this library will provide the following:

• going over the data repo and (re-)generating webspace stuff


• checking for additions and/or changes


• sorting through the arrivals and classifying them (more on this later)

this leads to user authentication and authorization: ssh keys are pretty much painless, and something everyone uses every day. so, for each author, just stick an ssh key in the repo and that’s that sorted out. from that moment on she can publish via scp or using any modern vcs. the latter gives me two things for free:

• an exact copy of the live website on any of my computers, where i can try things out, without having to deploy another install.


• offsite backups guaranteed to be in sync.

oh, did i mention a vcs? yes, i’ll be able to roll back changes in a cinch.

• yeti must support albums, or sets in flickrese. it must also support sets of sets (collections in flickrese)


• from a low-level perspective, a set will be just a directory with links to the original files. it follows that a collection will be just a directory with links to other directories.


• the original files might not be files at all, they can be anywhere in the network.


• should yeti be extra-lazy and allow external sets as well? (e.g., pointing to a flickr set)


• set metadata is kept in a file sitting in the set’s directory (the same for collections).


• yeti is to be kept off webspace. it will generate all web-related content (html, feeds, css, thumbnails, low-res versions of images, etc) from its configuration and data repositories, and then move it into webspace.


• the natural organisation is the trivial yyyy/mm/dd/epoch. this allows for easy creation of archives and also makes it easy to search for things in the backend.


• changes are to be recorded in a file which is read every time yeti runs (fseventsd or auditd considered, but in the real world they are too hard to setup, and might even be impossible).


• in the default mode of operation, the data repositories will hold high-quality versions of the images, and yeti will generate low-res versions and thumbnails which will live in webspace.


• yeti should be smart enough to figure that something in the repository is not high-res, and use it as is. this threshold should be defined in the configuration.

to get the ball rolling:

• it’s called yeti, because i’ve been looking for something like it for a long time (and will be for some time more, i suspect). it stands for yeti eats teh images, in case you’re wondering what cunning recursive name i came up with. it’s also an (unimaginative) jab at yaki, which i pondered using for this, but i think that yaki 1) is too complex and 2) still leaves a lot of work to the user, despite all the nifty automation tricks rui has thrown in.


• the first thing i did after a whole 2 minutes thinking about this was designing an entity-relationship diagram. it was very pretty, except i don’t want yeti to be database-driven. the relationships present are very simple, and the filesystem has served me well for the past 15 years, it will do nicely for this.


• if everything is a file, get as much information as possible from the file attributes.


• try to be as portable as possible, but not in the “runs on windows” sense. i will write yeti in perl, because that’s what i know best, but this really means “it should be easy to re-write in python or ruby”. keep the language-specific cleverness to a minimum, or avoid it if possible. python because it’s what app engine supports, ruby because of that rails thing.


• burn everything. have as little client-time processing as possible. keep the raw content away from the web, by the way.


• an entry can be a photo, a text, a link or a combination of the above. the source of a photo can be anywhere in the network, the image doesn’t have to be in the disk.


• support for markdown. i can’t live without it.


• publish locally, or remotely through scp or a web service.

these are the starting points, much more will follow, i’m sure. in particular, i’ve been thinking about the management interface and authentication / authorization, to start with, and have a (fairly) long list of what i think should be available to people publishing photos.

i’ve finally caved in and decided to write my own photo album software. i’ve been using birch for the past two years at too many lights, and it has served me well, but now i want some more functionality and it isn’t there. you could argue that i should just add it to birch, but the code is based around the cgi paradigm and i don’t want to go there. it will be easier to write something new.

having looked around, i find it surprising that there’s so little offer in this area. there seem to be two popular alternatives:

• people have bent movable type to do their bidding. this is mostly done through templates, and while it does take care of the publishing bit, it still knows nothing about the specifics of photography.


• pixelpost. it’s written in php, enough said.

so i’ll be rolling my own. this post is the first of a series on the design and the ongoing implementation. all these notes will be available with the code, in github.

and now for something completely different.

update: i'll be using lighthouse to track the development (and try it out). so far it's pretty amazing (a part of that is the automagic integration with github).

The true Bletchley Park Story is more incredible than fiction. A desperate race against time, pitting Britain’s best brains against Hitler and his chief commanders. The WW2 codebreakers’ mission was to crack the German Enigma machine and decode other seemingly unbreakable messages. Against them? Odds of 158 million million million. Their reward? ‘Ultra’ Intelligence that saved Allied convoys carrying essential supplies from U Boat wolfpacks on the prowl, and played a major part in the North African and other military campaigns. So effective was Bletchley Park that the decoded messages sometimes reached the Allies before the enemy Generals.

The astonishing achievements of the codebreakers are believed to have shortened the war by two years saving countless lives.

Today, Bletchley Park Trust is a charity; conscious of the debt we owe to the brilliant, unsung intellectual warriors among whom Turing and Welchman were pre-eminent. The mission of the Trust is to build a world class Heritage Site and Educational Centre but it receives no ongoing public funding and relies heavily on its revenue streams from conferences, weddings and heritage visitors, as well as from its Science and Innovation Centre, where Bletchley Park has returned to world-leading research after 60 years.

In addition to the Science and Innovation Centre in Blocks A and E, restored and refurbished in partnership with Milton Keynes Capital Partners, the Bletchley Park Trust has also restored Block B, as its main museum area, and Hut 8, former workplace of Alan Turing. It has established an American Garden Trail; a number of new and fascinating exhibitions and developed unique mathematics learning resources for students and educators. The National Museum of Computing will open later this year in the newly refurbished Block H and a Sculpture Trail is being developed in the grounds.

Heritage Visitor numbers at Bletchley Park are better than ever before, having increased by 40% over the last two years; the Science and Innovation Centre is thriving and the conference and wedding business, in partnership with Zest Leisure Group, is steadily growing.

But now is the time to act to help save Bletchley Park and the Trust are currently in talks with the Heritage Lottery Fund and other potential funders. Some of its remaining buildings, where the most important work of the twentieth century took place, are in urgent need of repair. The iconic Victorian Mansion requires in the region of £1,000,000 for repairs to the roof and some of the symbolic Codebreaking Huts are in a desperate state of decay.

Simon Greenish, Director of Bletchley Park Trust urges people to visit the Park, saying, “The site is unique and one of the most important remaining from World War Two. We have exciting plans to develop the Park and save it for future generations. The more visitors we have helps us to realise those plans.”