TurnKey Linux Virtual Appliance Library

Neat trick: invoking a Python debugger at an arbitrary point in your program

Do you find yourself occasionally wishing you could freeze a misbehaving program at an arbitrary point in time and then examining what was going on interactively?

That's exactly what the debugger is for, but sometimes it's just too much of a bother to run your program inside it, you have to set breakpoints, etc.

Well there's a really simple alternative: call the debugger from an arbitrary point in your program, like this...

Growl type notifications in Django

First, a little background

Django has an excellent messages framework which provides support for cookie and session-based messaging, for both anonymous and authenticated users.

The messages framework allows you to temporarily store messages in one request, and retrieve them for display in a subsequent request (usually the next one). Every message is tagged with a specific level determining its priority (e.g. success, info, error).

Prevent double click on form submission

Recently I've been going over the Hub logs and fixing issues which have caused exceptions to be raised in the application.

One in particular had me stumped for a while. An exception was being raised in an attempt to unregister a server from the Hub, but the server did not exist in the database - in theory this is impossible and should never happen.

A lazy yet surprisingly effective approach to regression testing

To regression test, or not to regression test

Building up a proper testing suite can involve a good amount of work, which I'd prefer to avoid because it's boring and I'm lazy.

On the other hand, if I'm not careful, taking shortcuts that save effort in the short run could lead to a massive productivity hit further down the road.

For example, let's say instead of building up a rigorous test suite I test my code manually, and give a lot of careful thought to its correctness.

Right now I think I'm OK. But how long will it stay that way?

Python performance tests reaffirms "premature optimization is the root of all evil"

"Premature optimization is the root of all evil"

Today while programming I found myself thinking about the performance impact of various basic Python operations such as method invocation, the "in" operator, etc.

This is a mistake because you really shouldn't be thinking about this stuff while programming. The performance impact of doing things one way vs another way is usually so small that you couldn't measure it.

Practical guidelines for beautiful Python code

Every now and then Liraz and I find ourselves chatting about how much we love Python, but more so the lessons we have learned from coding, and how to apply them to create beautiful Python code. I've tried to refine some of the "lessons" into practical guidelines that I apply religiously to all new code I write, and the refactoring of old code I written.

Git - Fixing commit mistakes

I use Git. I use it a lot. I basically use it for everything I do, from code revision control to revisioning my notes, my journal, even my email archive (don't ask, it's a long story).
As with anything you do, you are bound to make mistakes.

Tweaking Django exceptions with custom middleware

When settings.DEBUG is set to False, exception tracebacks will be sent to settings.ADMINS. To make it simpler to track down how and why the exception was raised, it's beneficial to know which user caused the exception.

It's quite simple to do this using some custom middleware. In the Hub, we include the associated users email address in the exception with the following:

Programming insight that helped unblock me

I'm finding a big part of the context switch involved in getting back to a high level of productivity on my programming is relearning old lessons.

In particular one of the most important lessons is to figure out how to systematically break down different goals into separate steps in a way that allows you to concentrate your full brain power on each of those steps in succession rather than trying to get it all done at once.

To Lisp or not to Lisp, that is the question.

Musings on Lisp by a routinely Pythonic programmer

Last week I did some maintenance on various Python projects I haven't touched in years (literally), and I was surprised by how easy, almost trivial it was to reorient myself and make the necessary changes.

That observation came at the right time because I've been reading up on Lisp dialects for a while now and questioning whether or not I should be programming in Lisp instead. Lisp enthusiasts (converts?) certainly make persuasive arguments, typically advocating Lisp as the one-true-language with near religious zeal.