Flickr Five Years Old Today!

Today is Flickr’s fifth birthday. I’ve had a Flickr account for several years, and I use the site all the time. For sharing photos, finding photos to use on a website, or just to browse around it’s really unmatched.

Happy Birthday Flickr!

Rude Code

In this second part of my “Etiquette of Programming” series I’m going to talk about making sure your code fits in with the style of existing code, while helping to bring it up to best practice standards.

When you’re working on an existing codebase, either fixing bugs or enhancing features, you’ll be going into the code and adding more code. When someone has to come back to this section and improve the feature or fix more bugs (not that you would introduce any, would you?) they need to read both the original code and your code. If your code sticks out, or causes the reader to say “Whoa, what’s going on here?” then your code is rude, and no-one likes rude people do they?

Just like writing prose, everyone has a different style of writing coding. People prefer different programming paradigms, design patterns, variable naming schemes and have different aesthetic preferences for spacing their code out with white space. There are more differences, but these four are the main aspects that make up your style of code. I’m going to talk about all four aspects in turn, from rudest to nicest.

Most people code in an object orientated style, but most languages allow you to pick and choose between procedural and functional styles as you wish. Each style has its own benefits and drawbacks, and each should be used in the right place. What you should avoid is switching styles in the same section of code. The mental switch required for someone who is reading code written in multiple styles is too great for it to be an easy or enjoyable experience.

Using Django Forms For GET Urls

A regular occurance in writing webapps is the user will submit a form, and on the results page you’ll want to include a link which the user can click to resubmit the form. This lets users bookmark the page or you can add an extra parameter such as ‘format’ so they can download the results.

While Django forms contain several functions for converting the form to HTML, it doesn’t contain one to convert a bound form to url arguments.

Fortunately Python’s standard library module urllib contains a module which converts a dictionary to a properly formatted url argument string. We simply add a function, as_url_args, which passes the form’s cleaned data to this function and we get back a nice string we can add to a link.

Dynamic Initial Values in Django Forms

I recently had cause to create a form with two date time fields which had the default values of midnight seven days ago, and midnight this morning. Initially I thought this would be easy and created the following form.

from datetime import datetime, date, timedelta

class MyForm(forms.Form):
    date_from = forms.DateTimeField(label="From",
                               initial=(date.today() - timedelta(days=7)))
    date_to = forms.DateTimeField(label="To", initial=date.today())

This works fine except that when a process has been running across more than one day the initial values are no longer correct as they refer to the day the process started. Fortunately it appears that there is an undocumented feature where the initial value can be a function rather than an absolute value. This function is called each time the unbound form is displayed, so they are always correct.

Placing Django Models In Separate Files

Chris Petrilli has made a very useful post on placing Django models into separate files.

The first thing I do when starting a Django project is to delete the standard views.py file and replace it with a directory. It won’t take you long before you’ve written enough views that a single file becomes huge. The same is true of models.py. If you have ten or more models then the file can quickly become a thousand line behemoth. I’d tried to split the file into a directory before, but it never worked, and the error messages were never helpful.