E-Scribe News : a programmer’s blog

About Me

PBX My name is Paul Bissex, and e-scribe.com is my consulting business. I build web applications using as much open source software as possible. From September to June I teach web design and other important non-photographic professional skills to photographers. In the '90s I wrote technology commentary and reviews for magazines, newspapers, and web publications, including Wired, Salon.com, FamilyPC, the late lamented Web Review, and the Chicago Tribune. Feel free to email me.

Book Project

I'm co-authoring a book, "Python Web Development with Django", with Jeff Forcier and Wesley Chun. It will be published by Prentice Hall in July 2008, but is available for pre-ordering on Amazon now.

Colophon

This site is built on a fresh trunk checkout of Django, running on Python 2.5.1, served by Apache and mod_python. The database is SQLite. The operating system is FreeBSD, on a VPS hosted at Johncompanies.com. Comment-spam protection by Akismet. Vintage topo imagery from the Maptech archive.

Pile o'Tags

ajax apple blogs browsers business design django ebay fp fun google hardware haskell intellectual property iphone javascript linux media mobile open source os x oscon oscon2007 palm php programming python rails rants reading risks ruby site spam textmate the well tips vcs web development web frameworks webservers wmassdevs

Stuff I Use

Akismet, del.icio.us, Django, dpaste.com, Emacs, FreeBSD, Freenode, jQuery, LaunchBar, MacPorts, Markdown, Mercurial, OS X, Postfix, Python, SQLite, Subversion, TextMate, Trac, Ubuntu Linux, wmii

A Django site.
(Finally!)

Copyright 2008
by Paul Bissex
and E-Scribe New Media

Django development tips

Working on a couple Django projects in tandem has me tuning my approach to using the built-in development server. I thought I'd share some of the techniques I'm using.

Here are the commands I'm going to talk about. If you understand it all from these lines, you're done! 

screen -S projectname
./manage.py runserver |& tee -a logs/devserver.log
tail -f logs/devserver.log
screen -r projectname
screen -list

Using screen

screen -S projectname

The GNU screen command is incredibly useful for all kinds of things, including longish-running processes that need to be checked and tweaked and stopped and started -- like your Django development server. (Read more about screen if this is new to you.)

The -S option allows you to name your session, so that you can recall it by name later. This is handy if you're running multiple screens (and you probably will be).

Starting the server

./manage.py runserver |& tee -a logs/devserver.log

The first part of this command, up to the pipe, is as usual (you'll want to add a port number if you're testing more than one project on the same IP). The rest:

Keeping an eye on things

tail -f logs/devserver.log

After you detach from your screen session (ctrl-a, ctrl-d), it keeps chugging along in the background. If you want to watch the log for a minute, just issue this tail command, which displays new log entries as they come in. Cancel with ctrl-c.

This is better than sitting there watching the same stuff inside your screen session, because if you lose your connection to your server (which I do on a regular basis) you may find your screen session is hard to reconnect to, or, in some cases, that your runserver process has stopped. Plus, the log will keep track of everything; by default, screen has a fairly small buffer.

Reconnecting

screen -r projectname

If you need to manually futz with the server process (e.g. if you need to restart it because you've done something traumatic that its normal auto-reload can't handle), reconnect with screen -r projectname, where "projectname" is whatever you named the session (obviously, I tend to name my session after the project).

If you can't remember what names you've used for sessions, screen -list will list them.

That's all

If you have alternate suggestions, or corrections, feel free to post them to the comments.

Tuesday, February 14th, 2006
+ + +
11 comments

Some related posts: Handling legacy URLs with Django • Moving the blog to Django • The twenty-minute trouble ticket system • Django: less (magic) is more • Soft launch • YAPWF: Aaron Swartz's web.py released • Django Docs in Plucker format • A minimal wiki in Django • Controller freaks • Python web framework mania
• Comment from Andrew, later that day

I never even thought of that. I did notice that I was starting and stopping the server a lot. I guess I'll have to fix my screen install on Mac OSX, somethings buggy.

• Comment from tabo, later that day

I use screen too but I have this scheme for developing django apps:

screen 0: django's runserver screen 1: some template screen 2: models screen 3: views screen 4: urls screen 5: django's shell screen 6: psql screen 7: svn screen 8+: random stuff

I use the exact same scheme for all my django projects. First thing I do in the morning is reattach the django screen session from my dev server (I never close it).

I don't store django's runserver logs, when I test stuff I just CTRL+a 0 and read the logs in real time. Any reason to keep this dev logs in disk? (other than historical reasons of course).

• Comment from Doug, later that day

An alternative to "tail -f" that I prefer is to open the log file in less and then hit "F" (shift-F) which will take you to the bottom of the log file and continually load the new stuff just like "tail -f".

The benefit from using "less" instead of "tail -f" is that you can hit ctrl-C and you're back in normal less operation -- you scroll back in the buffer easily, search for text, etc. Hit "F" again and you're looking at the latest stuff.

I still run it inside screen. screen rocks.

• Comment from Paul, later that day

Tabo: Very cool, you're clearly a screen ninja. The main reason I currently use a logfile instead of keeping the screen session open all the time is that I often am on flaky wireless connections, and in the past have had trouble reattaching to stranded screen sessions.

Doug: Thanks for the less tip, that's excellent.

• Comment from rezzrovv, later that day

I just keep a terminal tab devoted to the runserver (versus screen) as I like to insert "import pdb; pdb.set_trace()" quite often in my own code and sometimes in core django code as well.

I also use a lot of print statements which are printed to the console. Not sure why not just stay attached to the console?

• Comment from Aaron , 1 day later

I also use a similar layout, but I recommend running it behind apache using mod_proxy.

its only takes a second to setup and you can spin up django's dev server from any directory and insert into your staging environment.

• Comment from Paul, 1 day later

Yeah, in fact I use Apache mod_rewrite proxy rules to the same effect. With domain wildcarding I can use a subdomain for each project under development, e.g. wiki.django.e-scribe.com.

• Comment from Denis, 1 week later

I wonder which shell do you use? I tried `|&'' in bash and it says "bash: syntax error near unexpected token&'" Im using GNU bash, version 3.00.0(1)-release

• Comment from Paul, 1 week later

Sorry, I should have noted that I'm using tcsh.

• Comment from germ, 7 weeks later

I have a setup similar to tabo's, which can be found here: http://germ.wordpress.com/2006/04/07/django-screen-environment/

• Comment from germ, 7 weeks later

oh yeah... Paul, "autodetach on", might help with your reattach problem after your disconnects.

Post a comment

Comments use Markdown syntax. Your comment will not appear until approved, which may take a few hours or more. Spammers will be torpedoed.


(Will not be shared)

(Optional)