Monthly Archives: June 2013

Making Django runserver more awesome

I’ve recently found Dave Cramer’s awesome devserver and it already feels like an essential part of my Django toolkit. It’s a drop-in replacement for the default Django development server

./ runserver

But with a whole host of seriously useful additions if you care about what’s going on behind the scenes:

  • Log of SQL queries issued
  • Cache hits/misses
  • Werkzeug  debugger
  • Memory usage

And loads more. A picture’s worth a thousand words, so here goes:

[sql] SELECT ...
 FROM "polls_numericpoll"
 INNER JOIN "polls_event" ON ("polls_numericpoll"."event_id" = "polls_event"."id")
 WHERE ("polls_event"."slug" = doi
 AND "polls_numericpoll"."enabled" = TRUE
 AND "polls_event"."enabled" = TRUE)
 ORDER BY "polls_event"."start_time" DESC, "polls_numericpoll"."order" DESC LIMIT 1
 [sql] SELECT ...
 FROM "polls_numericpoll"
 INNER JOIN "polls_event" ON ("polls_numericpoll"."event_id" = "polls_event"."id")
 WHERE "polls_numericpoll"."id" = 2011343691
 [sql] 2 queries with 0 duplicates
 [cache] (3ms) 32 calls made with a 83% hit percentage (5 misses)
[05/Mar/2012 17:08:27] "GET /api/1.0/show/doi/state HTTP/1.1" 200 1179 (time: 0.15s; sql: 0ms (2q))

[cache] (1ms) 7 calls made with a 83% hit percentage (1 misses)
[05/Mar/2012 17:09:21] "GET /api/1.0/show/doi/state HTTP/1.1" 200 1179 (time: 0.01s; sql: 0ms (0q))

The [sql] lines show how the DB was hit on the first pass, and the second request shows that the caching is working perfectly – everything is then served from cache. Having tracked down several scaling issues where something was secretly doing database calls, this is just great for quickly identifying what’s going on. The best bit? Installation is trivially simple:

  1. Install via pip
    pip install git+git://
    INSTALLED_APPS = ( 'devserver', ....)

After that, there’s a bunch of useful extensions to make things even better – head over to the project page for all the details.


Sniffing iOS and Android HTTP traffic

Sometimes when you’re debugging a problem with a remote server, only seeing the actual bits on the wire is good enough. Recently I needed to do this to confirm whether it was my app or the server that was causing a bug.

In the past I’ve used HTTPScoop and Wireshark to debug this sort of problem, but recently I’ve discovered a much better option for anything that’s passing over HTTP – which these days is most things.

My new go-to tool is Charles. This is a great cross-platform (Mac, Windows, Linux) logging HTTP proxy with all sorts of nice features – including SSL proxying, so you can see what’s going to/from Facebook or other web services over https!

Here’s a step by step on getting Charles working with your iOS or Android phone, including the SSL proxying. Continue reading