Be Prepared

I like Flask. No, really, I do. Yesterday, during a lightning talk, I claimed that I love it, and if I don't love it, then at least I love the form and function of it. I wouldn't marry it, since I don't think being married to a microframework for Web applications would provide any tax benefits. Maybe I'm getting off-topic?

Flask is built on Werkzeug, and directly uses Werkzeug routes for view lookup and URL building. As a result, anything that can be done to Werkzeug can be done to Flask. A little-known ability of Werkzeug is the ability to add new URL converters. An example and explanation is provided in the Werkzeug documentation on converters. I decided to build some cool converters which would automate some of the work I have to do when working with certain objects.

Without further ado, I would like to present ModelConverter, a class which can convert a segment of a URL representing a text field on a model into an instance of that model, and vice versa.

from __future__ import with_statement

from werkzeug.routing import BaseConverter, ValidationError

from sqlalchemy.orm.exc import MultipleResultsFound, NoResultFound

class ModelConverter(BaseConverter):
    Converts a URL segment to and from a SQLAlchemy model.

    Rather than use an initializer, this class should be subclassed and
    have the `model` and `field` class attributes filled in. `model` is
    the Flask-SQLAlchemy model to use for queries, and `field` is the
    field on the model to use for lookups.

    The field to use should be Unicode or bytes.

    def to_python(self, value):
                obj = self.model.query.filter_by(**{self.field: value}).one()
        except (MultipleResultsFound, NoResultFound):
            raise ValidationError()

        return obj

    def to_url(self, value):
        return getattr(value, self.field)

This particular flavor uses an inheritance-based approach in order to avoid clobbering BaseConverter's initializer, but a compositional approach works too. A make_model_converter convenience method can provide the glue needed to specialize the converter. To apply it to the Flask application, merely modify the URL map after application creation:

from converters import make_model_converter
from models import Character

app = Flask(__name__)

app.url_map.converters["character"] = make_model_converter(app, Character,

And now you can create cool things along the lines of:

def character(c):
    return render_template("character.html", c=c)

There is one caveat with this technique: the model instances retrieved this way will be detached from SQLAlchemy and the current session will not know about them. If you need to look up any lazily-loaded data on the models, you will need to add them to the current session first. For example, assuming Character.friends is a lazily-loaded one-to-many mapping:

def character_and_friends(c):
    return render_template("friends.html", c=c, friends=c.friends)

Today's snippets are all real-world snippets from DCoN, and can be seen in the and source files.

~ C.

Last modified on 2012-02-15 20:34:00

Japanese Standing Cat

I recently purchased and installed a standing desk. While I normally don't blog about things in my personal life, I figured that this was permissible since it directly affects my ability to write code.

My standing desk, fully loaded

This standing desk is a Fredrik "computer work station," but let's be honest, here: it's a standing desk. It's pretty sturdy and removes the need to hack together various Ikea desks to produce reasonably-scaled tabletops. Pictured here is my desk, in its natural habitat. My workstation and hacked-apart AGP box both have their own monitor, and there is plenty of tabletop room for anything I need to have at my hands.

For those in the audience who aren't yet aware of standing desks, and don't want to read Wikipedia on standing desks, here are the abridged notes:

  • Pros
    • Reduces back stress and pain after a few months
    • Reduces risk of DVT
    • When monitors are elevated, reduces neck stress and pain
  • Cons
    • Slightly more expensive than sitting desks
    • Hard to find
    • Causes foot and ankle stress for the first few weeks
    • Turns one into a hipster programmer

So, on the bright side, this desk has definitely improved my back pain. But, if I start writing Node.js code soon, we'll all know who to blame.

~ C.

Last modified on 2012-01-31 11:42:00

A Little Bit is Better Than Nada

It is a running joke in the X.Org community that X12 development will commence as soon as all of the X11 bugs in the bug tracker have been closed. When I first heard this, my reaction was, of course, "Challenge accepted!" But where to start?

There were about 10,000 bugs open on the tracker at that point, a few years ago. We're definitely improving; there are about 9180 bugs open (at the time of writing) which could be considered relevant to any kind of desktop development. Many of those don't belong to anything in X11, but assuming they did...

Pretend that all of the card-carrying members of X.Org closed 92 bugs. That would be 1% per person. We could be done with X11! So, during XDC 2011, I pulled out my netbook, and started closing bugs. I picked, as my targets, things that nobody would miss, like Xprint.

I closed some Xprint-related bugs, before simply shuttering everything in the Xprint product. I also picked up a couple of stray bugs. Finally, with maintainer permission, I closed everything still assigned to xf86-video-nv.

The results:

  • 24 Xprint-related bugs
  • 37 bugs in Product: xprint
  • 42 bugs in Component: driver/nv
  • 37 bugs in Component: driver/nVidia (open)
  • #9455, #28657, #29832, #30129

A total of 144 bugs. We can do this, guys!

~ C.

Last modified on 2012-01-22 12:00:00

Valid CSS!