Paul Hammond's Journal
Some things of interest to Paul Hammond, arranged in a reverse chronological order with a feed
Behind the scenes, Minimuni is written in Python and hosted on Google App Engine.
My initial impressions of App Engine have been good. Really good. Everything just works good.
Like Rails, Django and Merb you're up and running in minutes. But unlike those frameworks, once you're done building an app there's no long complex deployment tutorials to follow, you just type appcfg.py update and your app is live.
The tutorials and documentation are also clear and easy to follow. I spent much longer remembering how Python works than I did learning the nuances of the AppEngine APIs. I wish more developers (particularly the Ruby crowd) remembered how important documentation is; it doesn't matter how awesome a library or framework is if nobody can work out how to use it.
The only problem I had was that the process to get things running under my own domain was stupidly over-complex. This is mostly because the flow was set up to sell me Google's domain groupware hosting, even though I'm just not interested in it. This is big company thinking in action - making individual products worse in an attempt to cross promote, and forcing code reuse even when it doesn't make sense. Compare it to Tumblr's awesome implementation of custom domains to see how easy this process could be.
Minimuni is deliberately not a complex application. It stores no data behind the scenes, so I've missed some of the problems other's have had with App Engine. On the other hand, I've developed plenty of small one-off applications over the years, and I'm bored of running a server underneath them. Every time I upgrade Apache or MySQL or a random Perl module something breaks in another project which I then need to fix. Of course, the App Engine API is going to change over the years, but hopefully in a much more controlled and backward compatible way.
App Engine is pretty much perfect for apps like this, and I can see me using it a lot more in the future...
Posted on Friday 5th December
I live near Duboce Park in San Francisco:
Every SF Muni streetcar line runs within walking distance of my house, but they all stop in different places. I can't wait in one place and be sure to catch the next train that goes past.
I used leave the house and hope that I wouldn't have to wait too long for a train to turn up. I'd often get to Duboce Avenue just in time to see a train disappear into the tunnel. I'd then end up waiting 10 minutes at the corner of Duboce and Church for the next J or N, wondering the whole time if I should walk to Church station and catch a K, L or M.
That got a bit much for me, so I made this:
It puts arrival information for all the stops near me on one page, and puts the emphasis on when I need to leave the house to catch a train. It tells me whether I need to get going right now, or whether I have 5 minutes to play with my kid before leaving.
I've had a beta version running for a few weeks, and it's completely changed my mornings. I'm getting to work earlier and a lot less stressed.
As the about page says, if you live exactly 6 minutes from Sunset Tunnel East Portal, 8 minutes from Duboce and Church, and 10 minutes from Church Station you may find it useful too.
Posted on Wednesday 3rd December
“Management’s job is not to prevent risk but to build the capability to recover when failures occur.”
— Pixar (via Timo)
Posted on Tuesday 28th October
If you use this HTML:
<!--[if IE ]>
<body class="ie">
<![endif]-->
<!--[if !IE]>-->
<body>
<!--<![endif]-->
with CSS that looks something like:
div.foo {
color: inherit;
}
.ie div.foo {
color: #ff8000;
}
then you get all of the advantages of using conditional comments to work around problems in Internet Explorer, without the extra HTTP request of an IE-only stylesheet.
Posted on Thursday 16th October
A few weeks back I spoke at Web 2.0 Expo in New York about the Flickr Stats project.
The talk covered the whole development cycle, from initial design sketches to post launch administration tools.
I focused on the problems you get when trying to engineer a system like this to work at scale, and some of the common solutions used by the Flickr engineering team, including sharding, denormalization, the flickr offline tasks system and batch processing.
I also had a chance to talk about the surprisingly large number of ways you can generate graphs online, including a little bit about the sparklines on the new Flickr homepage.
The slides are, of course, available for download in a 37meg PDF file.
Posted on Wednesday 1st October
A lot has happened in the 2 years since I last wrote anything here. I guess a brief catchup is needed.
In February 2007 we took a one way flight to San Francisco and haven't really looked back. Around the same time my group at Yahoo metamorphosed itself into Yahoo Brickhouse and launched Yahoo Pipes.
Shortly after that I joined the Flickr team, then spent a few months building Flickr Stats. These days I head up the PHP engineering team at Flickr, which includes some of the most talented developers I know.
I spoke at XTech 2007 on the difficulties of GeoLocation. I organized a panel at South By Southwest 2008 about working in multidisciplinary teams. And a few weeks ago I did a session at Web 2.0 Expo New York about that Flickr Stats thing. I'm hoping to get all the slides for these talks online in the not-too-distant future.
I'm somehow still married, and still a dad. My kid continues to challenge and amaze me every single day.
Oh, and I learned how to snowboard.
So that's what I've been up to. Question is, where next?
Posted on Monday 29th September
