E-Scribe : a programmer’s blog

About Me

PBX I'm Paul Bissex. I build web applications using open source software, especially Django. Started my career doing graphic design for newspapers and magazines in the '90s. Then wrote tech commentary and reviews for Wired, Salon, Chicago Tribune, and others you never heard of. Then I built operations software at a photography school. Then I helped big media serve 40 million pages a day. Then I worked on a translation services API doing millions of dollars of business. Now I'm building the core platform of a global startup accelerator. Feel free to email me.

Book

I co-wrote "Python Web Development with Django". It was the first book to cover the long-awaited Django 1.0. Published by Addison-Wesley and still in print!

Colophon

Built using Django, served with gunicorn and nginx. The database is SQLite. Hosted on a FreeBSD VPS at Johncompanies.com. Comment-spam protection by Akismet.

Pile o'Tags

Stuff I Use

bitbucket, Django, Emacs, FreeBSD, Git, jQuery, LaunchBar, Markdown, Mercurial, OS X, Python, Review Board, S3, SQLite, Sublime Text, Ubuntu Linux

Spam Report

At least 236509 pieces of comment spam killed since 2008, mostly via Akismet.

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

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.

Comments are closed for this post. But I welcome questions/comments via email or Twitter.