I’m a big fan of Jon Bentley, the author of Programming Pearls. In this book, he discusses elegant solutions to problems that have irritated programmers for years. (I was in Europe for 6 weeks last year, and this was the one book that remained consistently in my bag throughout the whole trip. I’m not joking.)
In chapter 3 of the second edition, Bentley demonstrates how “form letters” (another name for templates) can be used to solve some particularly tedious programming problems.
Like most web frameworks, Django (everyone’s favorite web stack) ships with its own template engine. In pretty much any Django tutorial, you’ll find a section on how to use templates to implement the dynamic pages on your website. This can lead to a sort of tunnel-vision that causes you to forget that templates exist outside of the world of dynamically generated HTML.
However, as Bentley was so kind to remind me, templates are good for so much more than generating HTML pages to be served over HTTP. I often find myself attacking ugly problems with a silly custom solution until I have that aha! moment in which I realize that templates are the perfect answer.
A couple of examples:
Email templates:
I do contract web development here and there. About a year ago, I was working on a client site that sent automated plain-text emails to users in response to certain events. The site owner wanted an easy way to edit these emails. I won’t tell you how silly my first solution to this problem was.
Luckily, I was quick to realize that plain text can be templated just as easily as HTML can. So, I made a template directory specifically for these emails, and documented the variables that would be passed into each template in comments at the top of each relevant file. The code to send the emails involves querying the relevant information from the database, producing a dictionary of key-value pairs from this data, and feeding this into the appropriate template to produce the email text.
The best part was that when the site owner decided that he also wanted to maintain HTML versions of his newsletters, I was able to use template inheritance to keep all of the text for both plaintext and HTML versions of each newsletter in one place.
XML API responses:
My masters thesis was in data management. If you had walked by my desk on any given day when I was working on my thesis project, you probably would have heard me muttering “I hate XML” as I stared maniacally into my editor window.
The StopFinder XML API was one of the last features to be implemented before our 1.0 release. I was starting to get a wee bit tired. Coffee was becoming more of a dependency than a performance enhancer. You know how it is. The last thing I wanted to do was mess around with code to build XML responses. Parsing it is bad enough.
After about five minutes of reading about different Python modules that can build XML documents programmatically, I had the predictable aha! moment. Why not just use a template to specify how the response should look? My favorite thing about using templates to implement XML responses is that the document structure is very obvious to maintenance programmers, in comparison to some nasty module that uses the DOM to build a document in code.
One word of warning with this approach: The natural way to implement an XML API from here is to write a vanilla view function to accept POST requests, or something like this. However, if this view function is in the same app as the rest of your site’s functionality, an out-of-control API consumer could potentially bog down the performance of your entire site. A better thing to do would probably be to run a seperate Django instance specifically for your API. Of course, if the API hits a shared database really hard, you’re probably going to be in trouble no matter what. But that’s a story for another article.
So, the lesson of the day is to remember that templates are a general purpose tool. This is probably obvious to most clever folks, but the slow ones like me occasionally need to be reminded.
As we’ve proudly stated in our site footer, StopFinder is built on a host of technologies that we think are really awesome. These include Python, Django, MochiKit, postgresql, Google Maps, and probably some more I’ve already forgotten about.
However, we weren’t completely familiar with all of these technologies when we started out. We learned quite a few lessons along the way. And now, we’d like to share these lessons with the interested folks in the audience.
So, while we’re working on the next set of StopFinder features, we’re going to take some time out now and again to post technical articles that we think will be of interest to the people out there who are building their own web apps. In fact, I’m working on the first one right now.
Stay tuned! We hope you enjoy them!
The StopFinder team has been hard at work on the new features that have been suggested to us by our users. However, that’s not all we’ve been up to! Our goal was to have more than 200 lots available by the end of April, and we’ve cleared that mark by a long shot — as of right now, we have 226 lots on record.
Most of the lots we’ve added recently are in the downtown core. We’re going to start focusing on other regions of the city next.
In the meantime, enjoy the new deals we’ve found for you!
The team would like to thank all of those who have sent us tips about parking lots and transit stops so far! Since we’re trying to make your lives easier, we’ve dedicated ourselves to finding as much parking lot rate information as we can on our own. However, we’d of course really love any help that we could get!
So, we’d like to ask all of you parkers out there to keep an eye on the amount you’re paying when you park! We’ll take any information we can get, so even if you can only tell us about the rate that was in effect when you parked there (and perhaps the hours that the rate is in effect) that would be awesome!
Also, we’ve tried to keep it simple and easy to send us parking rate information by just having you write an email to us or use the feedback form. Would you like to see something more specialized for this purpose?
If you’d just prefer that the StopFinder just do all the investigating ourselves, it would be helpful to know that too.
Let us know!
Many thanks to Sameer Vasta (http://eloquation.com) for his great StopFinder article on BlogTO this morning!
If you live in Toronto and you’re somehow unaware of BlogTO, you shouldn’t be. Especially if you occasionally find yourself unoccupied on a weekend or weeknight and are convinced that there’s nothing to do in the city…
The StopFinder team was at TransitCamp on Saturday, and as we expected, it was predictably awesome.
I’ve been to many events like this in the past, but the great thing about the TransitCamp crew is that the emphasis is definitely on fixing problems instead of just airing them. There is the very strong impression that people are going to leave the meeting and immediately start working on concrete projects that are meant to address the problems discussed throughout the day.
To get an idea of the scope of the issues that were discussed on Saturday, check out the TransitCamp wiki. I attended four sessions in total, and they were extremely diverse. However, the one overarching theme that I was able to take away was this: If we want to work on solving any complex problem that has a number of stakeholders involved, we need to be able to understand and effectively communicate what it means for a design to be of high quality. This became clear to me in a session on walkable communities, as we were talking about how many suburban landowners tend to cringe away from the word ‘density’, even though a high-quality suburban community will be designed with a specific density in mind (so that transit options, community cohesion, proximity to services, etc. can be sustainably supported).
This is certainly a theme that the our team holds dear, and one that we’ll continue to emphasize as StopFinder evolves.
We’re looking forward to the next TransitCamp, and we encourage our users to get involved if they can! Check out http://metronauts.ca to see how you can participate.
The awesome folks at StartupNorth posted an article on StopFinder this morning.
One of the reasons we built StopFinder is that we felt the existing parking apps out there weren’t answering the questions we wanted answered, and that they were instead adding all sorts of features that we didn’t find useful. I think this quote from the article demonstrates that we’ve managed to hit a sweet spot here:
Finding parking was never the problem for most of us, it turns out that it was knowing when to take a car and when to take transit. Even I didn’t know that until I experienced the solution, but I can tell that StopFinder will become a part of my toolkit from now on.
We couldn’t have said it better ourselves.
Many thanks to StartupNorth for this fantastic article, and for their continued service to Canadian innovation! If you’ve never visited the site, we strongly recommend that you make it part of your regular reading.
The StopFinder team is going to be at TransitCamp on Saturday, and we’re looking forward to contributing to the event in whatever way we can.
One of our main topics of interest is obviously the idea of unifying and presenting transit and driving information in order to help people make effective decisions about transportation. However, there are tons of other ideas being tossed around that are extremely interesting to us as well, so it promises to be a great time!
For those of you who are attending — we’ll see you there!
StopFinder has officially been live for eight hours now, and we’re already getting lots of great feedback from people. Thanks to all who’ve gotten in contact with us!
I was asked today about the concrete ways in which StopFinder is going to help improve mobility in Toronto. I have multiple answers to this question, but here’s a really obvious one.
I discovered Bern Grush’s blog this morning through the metronauts website, and saw that he had posted this Time Magazine article on traffic congestion. In a survey of a gridlocked area of New York, 45% of drivers interviewed stated that they were on the road because they were looking for a parking spot. Now, if you do some homework before you leave the house, we feel like you’re much more likely to quickly find a spot when you arrive, yes?
Before StopFinder came along, there really wasn’t an especially good way of finding a Toronto parking lot on the web. With StopFinder, you can find one in less than a handful of seconds. So, now you have no excuse 
And that’s one simple way in which we think StopFinder is going to help out.