phot.us
I had thought about making a ‘simple, egotistical photo gallery’ for literally years before making phot.us. It’s an incredibly simple site, which would seem like kind of a disappointment if it were the ‘result’ of these years, but it’s really the result of a weekend of coding and a few weekdays of tweaks. And it isn’t groundbreaking, but I think it’s pretty neat.

Photo galleries are still mostly bad
There are certainly some sites for photos, especially Flickr, which, despite its rather slow development cycle recently, deserves a place in the internet’s hall of fame for doing things mostly right even after its market was supposedly saturated.
And there are lots of things you can download and set up, and have a cool looking photo gallery in a relatively small amount of time. Unfortunately, upon googling for these things, people will often find Gallery2, a terrible monster of feature-bloat and code-bloat, with terribly ugly themes to match.
phot.us
phot.us was, as I said, a weekend project, because of a few reasons: one of the biggest is the fact that it doesn’t use a database because, currently, it doesn’t need one. Instead it uses a disk cache for API calls, which works quite well, and short URLs are generated by simply re-encoding the photo’s ID in base63 – instead of 0-9, it’s encoded in a-zA-Z0-9, so it can
be significantly shorter.
Another thing is that there is no interface – you just go to a URL. I’ll be adding an interface soon, but begrudgingly. Having just URLs means that you have to think of the non-API site as a web service, which has the cool side effects like the fact that everything on the site is a short URL.
The full source code to phot.us is available on GitHub and is BSD-licensed, with the additional clause that you have to tell me if you do anything cool with it.
Notes on Building
Use libraries and frameworks when they become requirements. Previously I found myself essentially loading up jQuery, jQuery UI, Blueprint CSS, etc., before any real code had been written, just expecting them to be necessary, but in the end I would often write unnecessary features and spend too much time learning their interfaces instead of writing real code. Use frameworks, of course, and especially when writing dangerous code like authentication and validation, but use them because you need to, rather than because you think you should.
blog comments powered by Disqus