approaching infinity

Dealing with multiple Django versions

2009-05-20T10:49:00.000-07:00

More than a few Django websites I built in the past two years are still live and active. And because they were made at different times, they were built against different Django versions.

If a (virtual) web host accidentally imports a different version of django, the site will completely break at best... or exhibit subtle, hard-to-discover runtime errors at worst. Guard against this by placing a version check in settings.py:

from django import VERSION as DJANGO_VERSION
assert (1,1) == DJANGO_VERSION[:2], DJANGO_VERSION

(If, for example, this web site is built for version 1.1. Change the tuple in the assert statement to match whatever version is required.)

This will cause the host start-up to immediately fail, loudly and visibly, if the incorrect Django version has been imported.

Django: AttributeError: 'str' object has no attribute 'resolve'

2009-04-07T19:18:00.001-07:00

Here is today's obscure error message and its solution.

Say you are working on a Django project, using its development web server, and you get this exception when you try to load a page in the browser:

AttributeError: 'str' object has no attribute 'resolve'

It's because you forgot to type the word "patterns".

Specifically, in some url.py, you typed something like this:

urlpatterns = ('',
  (r'^$', direct_to_template, {'template' : 'a.html'}),
  # ...

when you should have typed this:

urlpatterns = patterns('',
  (r'^$', direct_to_template, {'template' : 'a.html'}),
  # ...

See the difference? In the first one, I'm incorrectly assigning urlpatterns to be a tuple. In the second, I'm correctly using the django.conf.urls.defaults.patterns function.

File this under "issues that cost me an annoying amount of time to solve, and which I'm documenting so it doesn't have to happen to anyone else."

How To Build an Automated Testing System

2009-04-04T22:42:00.000-07:00

What is the value of automating your software testing as much as possible?

At a talk I gave once to a large room of software engineers, I asked for a show of hands: how many write unit tests all the time? And, how many use version control for nearly all their code? Almost every hand went up on both counts. I was proud of them for this, and told them so!

A little later in the same talk, I asked how many had use a code coverage tool on their code in the past week. Only fifteen percent! A tiny fraction. And these were undeniably excellent engineers. What would the ratio have been for a more mediocre group?

Automation is a form of leverage. If each attendee's organization had an automated QA system that simply did a source checkout each night, and executed all tests within a code coverage tool while everyone slept, then everyone would have been able to raise their hands... even if they did not know how to invoke the tool!

This situation demonstrates why an automated testing system is important. By silently working for you and your team, all measurable metrics are just there and available. You won't use them all the time. That's fine. They are there when you need them, without distracting you from more important matters.

A great automated quality assurance system will have a number of good ingredients. Let's look at them.

(And by the way, this list is unapologetically opinionated. It's not necessary to agree with each item. But everything is there for a reason. I urge you to at least understand the rationale behind it. Then you are well equipped to decide whether to do it this way or another way. Send questions and/or criticisms to amax@redsymbol.net.)

Read the full version of Building an Automated Testing/Quality Assurance System

Does it take money to make money?

2008-11-14T19:43:00.000-08:00

Let's talk about a phrase you have heard before:

"It takes money to make money."

Like many aphorisms, it must be handled with great care. It can be amazing that the words you listen to can affect what you believe, and thus how you act.

"It takes money to make money." One could use this idea to keep themselves poor, reasoning that they can never afford to become wealthier than they are now.

I would prefer that this not happen to you. So let me suggest a different wording that may be more profitable.

"It takes SOME money to make MORE money."

And very importantly,

"You can create SOME money out of nothing."

Is this dual aphorism true? Just as true as the original, perhaps more.

If you have money, can you utilize it to create even more? Yes, absolutely. Can you create money out of thin air? Yes, there are many ways. One way is to sell your time and labor to those who will pay for it. There are other ways.

Some recommended reading:

Django and Lighttpd: one niggling fastCGI detail

2008-10-03T12:06:00.000-07:00

If you are setting up a Django website using the lighttpd web server, one of the easiest ways to configure it is via fastcgi, which lighttpd has built-in support for. As I write this, the official Django FastCGI docs do a very good job of explaining everything, provided you read the whole document. (Don't just skip to the lighttpd section - relevant info is contained earlier, perhaps even in the Apache sections.)

The docs skimp over one detail that happened to affect me, however, which I'd like to document here in hopes that it will save you some time: the FORCE_SCRIPT_NAME setting. At first, when I called up the admin site and clicked the submit button to log in, I got a 404 error, for a url like "/mysite.fcgi/admin/". mysite.fcgi (not its real name :) is the url prefix I configured for the fastcgi rewrite rule in the lighttpd configuration.

After much research and fruitless tweaking of the config files, I thought to look at the HTML source of the admin login page (which served just fine). Turns out the action attribute of the login form element was set to "/mysite.fcgi/admin/", not "/admin/" or ".", like it should be. At the tail end of the above docs, I got a clue as to the cause. Long story short, defining FORCE_SCRIPT_NAME to the empty string in settings.py solved the problem.

There... hope this saves someone an hour or two!

Crash course in Applied Functional Programming

2008-07-15T18:59:00.000-07:00

If you're a software developer, something interesting has been happening in your field lately. Mainstream programming languages are starting to gain features from what used to be a decidedly academic domain: so-called functional programming.

Now, I'm sure you are a programmer just like me, who works in C or C++ or Java or Python or Ruby or Javascript or, God help you, PHP. And also just like me, you probably spend much of your free time reading math books.

What? Oh, right, that's not normal - I keep forgetting. The point is, more and more, languages that you actually use are picking up some rather theoretical ideas from computer science, and incorporating them very directly into the syntax of the language...

Read full version of Crash course in Applied Functional Programming

Three Things I Love About Git

2008-04-23T16:40:00.000-07:00

git-commit --amend

One of the benefits of using version control is organization. When you commit a set of changes, you are implicitly marking that set as defining a certain feature set, or otherwise having something in common.

Have you ever committed something, then realized you forgot to include something with it? Maybe it's a new file, or maybe it's an extra small change you forgot to make.

Enter git-commit --amend. The amend option adds to the tip of the current branch, and actually replaces the last commit with the combined change! It even seeds the message editor with the last commit's description, so you don't have to type it in again.

Find out two other lovable git qualities in the full version of Three Things I Love About Git

High-level Language Features and Testing

2008-01-16T21:16:00.001-08:00

When I first started doing test-driven development as a PHP coder, our development shop used Marcus Baker's excellent SimpleTest framework. I liked it a lot. Since then I've used unit test frameworks in C, Perl, Java, and Python, and SimpleTest is still my overall favorite in any language.

As I became more ~~obsessed with~~ interested in automated testing, however — reading books and blog articles, experimenting with new testing patterns, getting xUnit tattoos — I sometimes felt frustrated. Often I would want to write some kind of test in the framework and language, but one or both was just not powerful enough to express the idea cleanly.

It wasn't until I started coding a lot in Python that the cause hit me. Most xUnit frameworks, particularly if they provide good mock objects, are more than adequate in themselves to support any testing pattern I could come up with. SimpleTest certainly is. The problems I ran into came from the language itself...

Read more about how a language's features affect the tests you write in the full version of High-level Language Features and Testing

Using Gnu Emacs With SCMUtils

2007-06-15T01:17:00.000-07:00

If you are interested in both physics and computer science, there is a real treasure of a book you owe it to yourself to check out. It's called Structure and Interpretation of Classical Mechanics. The full text is online at that link, and you can also buy a physical copy. I won't describe it further in this post; good summaries can be found in the reviews on Amazon. Accompanying the text is an open-source numerical and symbolic math library called "scmutils", meant to be run in MIT's version of Scheme. (download and install instructions) MIT Scheme includes an Emacs-like editor and execution environment called "Edwin", which acts as an interface to the whole system. Edwin has some nice features, including a user-friendly debugger and symbol completion. Most of the time, however, I prefer to use full-fledged Gnu Emacs as the interface. Setting this up is actually pretty simple, once you have downloaded and installed scmutils. Just include the following in your .emacs file:

(defun mechanics ()
  (interactive)
  (run-scheme 
    "ROOT/mit-scheme/bin/scheme --library ROOT/mit-scheme/lib"
  ))

Replace ROOT with the directory in which you installed the scmutils software. (Remember to replace it in both places. If it is installed differently on your system, just make sure the string has the form "/path/to/mit-scheme --library /path/to/scmutils-library".) Restart emacs (or use C-x C-e to evaluate the mechanics defun), and launch the environment with the command M-x mechanics. There are a few nice Emacs and scheme-mode features you can use. A handy way to work in the environment is with two buffers open at once. One buffer will be in the mechanics enviroment (i.e. scheme interpreter) launched with the mechanics command; we'll refer to this as the "mechanics" buffer. The other buffer will be open to a file containing Scheme/Scmutils code. The idea is that you write your code in the file, save it, then tell the scheme process to load the file. You do this by switching to the mechanics buffer, then typing C-c C-l. (That's "L", not "one"). You will be asked for, and must specify, the file to load the first time. It is remembered on subsequent invokations, so after making a change to the file and saving, you can just switch to the mechanics buffer and type C-c C-l [ENTER] to reload. It's very simple and fast. In the mechanics buffer - which happens to be in the normal Emacs scheme interaction mode - a command history is kept. You can cycle up and down through the command history with C-up and C-down. If you make a mistake and get to the error prompt, or start a calculation that is taking too long, you can abort and return to the normal prompt by typing C-c C-c. Other useful commands can be found from M-x describe-mode .