class MyModelOptions(admin.ModelAdmin):
    list_display = ['fk_field__fk_attribute']  # ILLEGAL

There has been extensive discussions on the tracker (https://code.djangoproject.com/ticket/5863) and on the mailing list (http://groups.google.com/group/django-developers/browse_thread/thread/790484bfbe1b421f). It seems unlikely that this will be possible to do before hell freezes over (although someone commented that it works in Django 1.2 here: http://stackoverflow.com/questions/163823/can-list-display-in-a-django-modeladmin-display-attributes-of-foreignkey-field).

Luke Plant has suggested a solution using callables, which I personally find ugly, but YMMW:

def foreign_field(field_name):
    def accessor(obj):
        val = obj
        for part in field_name.split('__'):
            val = getattr(val, part)
        return val
    accessor.__name__ = field_name
    return accessor

ff = foreign_field

class MyAdmin(ModelAdmin):

    list_display = [ff('foreign_key__related_fieldname1'),
                    ff('foreign_key__related_fieldname2')]

The code from @lukeplant does all the work in the ModelAdmin, which keeps the Model class free of extra methods for the admin. This is generally a good idea, however I just had a use case where adding accessors made working with the model much easier.

The model in question looks like this:

class DailyEmployeeProjectHours(models.Model):
    employee = models.ForeignKey(Employee)
    empday = models.ForeignKey(EmployeeDay)
    project = models.ForeignKey(Project)
    seconds_worked = models.IntegerField(default=0)

The code was littered with “deph.employee.user.username”, “deph.empday.date”, and “deph.project.name”…

We needed something that could define an accessor/property, that would automagically be sortable in Django’s admin interface… which sounds like the job for a descriptor:

class FkeyLookup(object):
    def __init__(self, fkeydecl, short_description=None, admin_order_field=None):
        self.fk, fkattrs = fkeydecl.split('__', 1)
        self.fkattrs = fkattrs.split('__')

        self.short_description = short_description or self.fkattrs[-1]
        self.admin_order_field = admin_order_field or fkeydecl

    def __get__(self, obj, klass):
        if obj is None:
            return self  # hack required to make Django validate (if obj is None, then we're a class, and classes are callable <wink>)

        item = getattr(obj, self.fk)
        for attr in self.fkattrs:
            item = getattr(item, attr)
        return item

Usage:

class DailyEmployeeProjectHours(models.Model):
    employee = models.ForeignKey(Employee)
    username = FkeyLookup("employee__user__username")

    empday = models.ForeignKey(EmployeeDay)
    date = FkeyLookup("empday__date")

    project = models.ForeignKey(Project)
    name = FkeyLookup("project__name")

    seconds_worked = models.IntegerField(default=0)

and in admin.py::

class DailyEmployeeProjectHoursOptions(admin.ModelAdmin):
    list_display = "username date name hours".split()

    def hours(self, obj):
        return '%.2f' % round(obj.seconds_worked / 3600.0, 2)
    hours.admin_order_field = 'seconds_worked'

The admin list for EmployeeProjectHours now has columns named “Username”, “Date”, “Name”, and “Hours” — and all of them will be sortable! (if you’re on an ancient version of Django, you’ll need to apply r9212 from Django trunk, only the changes in contrib/admin/views/main.py are needed if you’re lazy).

In addition the DailyEmployeeProjectHours class now has a number of new properties…

deph = DailyEmployeeProjectHours.objects.get(...)
assert deph.username == deph.employee.user.username
assert deph.date == deph.empday.date
assert deph.name == deph.project.name

It’s cute and it uses descriptors…

I’m assuming you’ve used Google’s geo-coding, or geonames.org’s postal code search, etc., and now have locations with lat and lng attributes.

The Earth isn’t a perfect sphere, among many non-spherical properties, it’s actually fatter around the equator than between the poles: The algorithm doesn’t take any of this into account, and instead uses a single value for the Earth’s radius. Assuming you’re not going very far (i.e. “halfway around the globe”, the result will probably not be too far off, YMMV of course).

Module haversine.py:

import math

def cosrad(n):
    "Return the cosine of ``n`` degrees in radians."
    return math.cos(math.radians(n))
    
def haversine((lat1, long1), (lat2, long2)):
    """Calculate the distance between two points on earth.
    """
    earth_radius = 6371  # km
    dLat = math.radians(lat2 - lat1)
    dLong = math.radians(long2 - long1)

    a = (math.sin(dLat / 2) ** 2 +
         cosrad(lat1) * cosrad(lat2) * math.sin(dLong / 2) ** 2)
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a))
    d = earth_radius * c
    return d

def distance(a, b):
    "Return the distance between two points that have .lat and .lng members."
    return haversine(
        (float(a.lat), float(a.lng)),
        (float(b.lat), float(b.lng)))

For those unfamiliar with autodoc, a simple declaration in your documentation file:

.. automodule:: test.sphinxtest
   :members:
   :undoc-members:

will automatically document your module, pulling in docstrings automatically:

At first glance that’s nice, but after having used it for a while it becomes clear that your eyes are drawn away from the content and onto the “packaging”, like the headers/TOC/etc. It is also difficult to tell which level you’re at since all headers start flush left.

The choice of fonts for describing classes also seems a bit unusual — at least for first time readers:

There are other themes to choose from, but if you’re going to customize you might as well create your own theme — especially since it’s really easy.

I’ll use our dktheme as an example, the finished product looks like this:

To start, create a folder (dktheme) to hold your theme files. I chose to put it in the documentation folder. Change your conf.py file to reflect the new folder:

html_theme = 'dktheme'
html_theme_path = ['.']

Create a theme.conf file in the folder and provide a few basic configuration settings:

[theme]
inherit = default
stylesheet = dktheme.css
pygments_style = sphinx

inherit declares which theme you want to use as a base (they exist in site-packages/sphinx/themes). pygments_style defines which syntax highlighting color scheme to use.

Create a directory dktheme/static, and put a file named dktheme.css_t in it. Notice the _t suffix. This file corresponds to the stylesheet setting in the dktheme/theme.conf file.

Define your own css rules inside dktheme.css_t, but begin by importing the css file of the theme you’re inheriting from:

@import url("default.css");

Firebug/Webdeveloper/etc. are useful for finding the correct selectors to override:

@import url("default.css");

html, body, h1, h2, h3, h4, h5, h6 {
  font-family: 'Ubuntu', 'Trebuchet MS', sans-serif !important;
}

html,
.bodywrapper,
.documentwrapper,
.footer,
.footer a,
.related,
.related ul,
.related ul li a  {
    background-color: #c0c0cf !important;
    color:#808080 !important;
}

.related ul {
  max-width:900px; margin-left:250px !important; font-size:smaller
}
.related ul a {  background-color: transparent !important;}

.body {
  -moz-box-shadow:0px 0px 12px #666;
  -webkit-box-shadow:0px 0px 12px #666;
  box-shadow:0px 0px 12px #666;
  margin:15px 25px 15px 0px;
  margin:0px 25px 0px 0px;
  border:9px solid white;
  -moz-border-radius:14px;
  -webkit-border-radius:14px;
  border-radius:14px;
  max-width:900px;
}

.sphinxsidebar a,
.sphinxsidebar h3,
.sphinxsidebar h4,
.sphinxsidebar h5 { color:#555 !important }

.sphinxsidebar .searchtip { color:black; }

.body h1,
.body h2,
.body h3,
.body h4,
.body h5,
.body h6 {
  margin-left: 0px !important;
  margin-right: 0px !important;
  padding-left:0 !important;
  background-color: white !important;
}

.body h1 { padding-top:17px !important; }

.section .section { margin-left:14px }

.class big { font-size:85%; }
.class em { font-size:85%; }

.class .property,
.class .descclassname,
.class .descname { font-size:100%; line-height:100%; }

.class .property {
   font-style:normal;
   font-weight:bold;
   color:#1D599F;
}

.descclassname { font-size:100% !important; font-family: Tahoma; }
.descname { color:#041F3F; font-size:100% !important; font-family: Tahoma; }

dl.method::before {
    content:"def";
    float:left; margin-right:0.5ex;
    font-weight:bold; color:#222;
}

dl.attribute::before {
    content:"@property";
    font-size:85%;
    float:left; margin-right:0.5ex;
    font-style:italic;
}

dd > p { font-size:85%; }

I’ve used ::before rules to e.g. insert the word def before method definitions.

At the top I’ve listed the preferred font as being Ubuntu, which is a very clean font that Google has made available as a webfont (www.google.com/webfonts).

To use the Ubuntu web font, you’ll need to add a link to its css file in the <head> section of your html.  To accomplish this, you’ll need to add a final file to your theme, dktheme/layout.html, with the following content:

{% extends "default/layout.html" %}

{% block extrahead %}
<link href="http://fonts.googleapis.com/css?family=Ubuntu:300,300italic,regular,italic,500,500italic,bold,bolditalic" rel="stylesheet" type="text/css">
{% endblock %}

What this does should be obvious to anyone familiar with Django templates (although these are Jinja templates).

I’m not a graphical designer, but to my development eyes the documentation is much easier to use with the new theme

If you can disregard IE6 (and perhaps IE7… at least IETester doesn’t like it), then a hbox can be as simple as:

  .hbox {
    overflow-x:auto;
  }
  .hbox > * { display:table-cell; }

Then the markup:

  <div class="hbox">
    <div>A</div>
    <div>B</div>
    <div>C</div>
  </div>

Adding some debugging markup to show what’s going on:

  .hbox { border:3px solid green; border-spacing:3px; }
  .hbox > div { border:1px solid blue; padding:5px; }

and you get:

You can use other table-css on the .hbox selector as well, e.g. border-collapse.

ImageMagick to the rescue!

I was doing this on windows, so I first had to download Ghostscript (http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl900.htm).  For some reason I already had ImageMagick installed…. (hmm).

Then the magic incantation:

convert -density 200x200 minuet-g.pdf minuet-g.jpg

ImageMagick automatically splits the pdf into individually numbered .jpg files. The -density argument was necessary to get all the lines to show up.

Everything is now switched over to bluehost.com, and hopefully things will converge on normality.  It took a little less than 20 minutes of downtime to do the entire switch, and it could probably have gone even faster if I knew what I was doing.  Big thanks to bluehost for their excellent documentation and for answering their phone almost immediately (no more “your expected wait time is 11 minutes”…!).  Big thanks also to the WordPress team for making it so easy to transfer an entire blog!

Load times are now in a sane range from 328 ms to 1830 ms (the larger numbers are all from Europe).

Having spent a lot of time on archive.org and in the google cache, I managed to salvage some of the old posts, but it was a tedious manual process.  To speed up some of the mundane work, I wanted to turn on ssh access.  Should have been an easy option to enable from the settings menu in hosting manager, however, it told me my account had to be transferred to “newer” servers.  To do that I had to delete my blog (after exporting it) calling support, having them put in a service order, and waiting several days.

At my day job, I use www.pingdom.com to monitor the uptime on our servers, and naturally I’ve added this blog to the list.  Not long after the upgrade to the ssh-enabled account, I started getting text-messages saying the blog was down.  Turns out it mostly wasn’t down, it just had response times of over 30 seconds(!)

Below is the pretty graph from pingdom.com, with average response times per day, for the last month for access to the http://blog.tkbe.org page:

The only advice from GoDaddy support… turn off all the WordPress plugins (which I’ve done without seeing any improvement whatsoever).

 print "hello world" 

which was accomplished by simply writing

1print "hello world"

Everyone seems to be using Alex Gorbatchev’s JavaScript code (http://alexgorbatchev.com/SyntaxHighlighter/) wrapping it in various ways.  The WordPress team uses (created?) a plugin named SyntaxHighlighter Evolved, which is what I’m using here.

create table customer (
 id int identity primary key,
 ...
)
create table foo_orders (
 orderno int identity primary key,
 customerid int,
 ...
)

after various failed attempts at “alter column”, “add constraint”, etc. I finally found the correct incantation

alter table foo_orders with nocheck add foreign key(customerid)
references customer(id)
on delete no action
on update no action

In (other) words:

• in the foo_orders table
• create a new foreign key
  • from the customerid field
  • to the id field in the customer table
• don’t check existing data in the table (with nocheck)
• if the customer is deleted, keep the foo_orders record (on delete no action)
• if the id field in the customer table changes, then do nothing (on update no action)

(at least that’s what I’m pretty sure it means

Why the no action clauses? The foo_order table records info we send to external entities, and is part of the historical record.  Any changes should never happen automagically.