views:

332

answers:

4
+6  Q: 

Debugging web apps

I've gotten pretty used to step-through debuggers over the years, both in builder, and using the pydev debugger in Eclipse.

Currently, I'm making something in Python and running it on Google App Engine, and I should add that I'm pretty new to developing any real web app; I've never really done much beyond editing HTML code.

So, I'm running Google's dev_appserver and viewing my work at http://localhost, dig, and right now, the only tool I'm using to identify issues is PMD (poor man's debugger). . .basically writing things to the html pages to see the value of local variables.

Is there a better technique for dealing with this?

+7  A: 

The dev_appserver is just a python script, you can simply use the pydev debugger on that script with the proper arguments as far as I know.

Here is a very detailed guide on how to do that:

http://www.ibm.com/developerworks/opensource/library/os-eclipse-mashup-google-pt1/index.html

Tomh
Oh, great link. I hadn't even thought about putting dev_apperver in the run config. I've just been running it on the directory with my application, but this looks like it should work.
Baltimark
+2  A: 

"Is there a better technique for dealing with this?" Not really.

"step-through debuggers" are their own problem. They're a kind of mental crutch that make it easy to get something that looks like it works.

First, look at http://code.google.com/appengine/docs/python/tools/devserver.html#The_Development_Console for something that might be helpful.

Second, note that --debug Prints verbose debugging messages to the console while running.

Finally, note that you'll need plenty of Python experience and Google AppEngine experience to write things like web applications. To get that experience, the print statement is really quite good. It shows you what's going on, and it encourages you to really understand what you expect or intend to happen.

Debuggers are passive. It devolves to writing random code, seeing what happens, making changes until it works. I've watched people do this.

Print statement is active. You have to plan what should happen, write code, and consider the results carefully to see if the plans worked out. If it doesn't do what you intended, you have to hypothesize and test your hypothesis. If it works, then you "understood" what was going on. Once you get the semantics of Python and the Google AppEngine, your understanding grows and this becomes really easy.

S.Lott
Thanks. No offense, but I was really looking for something like Tomh wrote. I've used step-throughs for a long time and I'm familiar with their benefits and shortcomings;I'm looking for that functionality in my app. That dev console seems pretty cool, though.
Baltimark
@Baltimark: no offense taken. Step through debuggers create more problems than they solve, but if you think they're helping, that's fine. They're not helping, but it's your opinion of your development that counts here, not my experience.
S.Lott
+4  A: 

I would suggest to use logging statements instead of prints though as you can control them better. Python has a quite good logging library included.

For logging from Google App Engine to e.g. Firebug there is also some handy tool called FirePython. This allows to log to the firebug console from within your Django or WSGI app (it's middleware).

MrTopf
A: 

My debugging toolbox for GAE:

  • standard Python logging as a substitute for print statements
  • Werkzeug debugger if I do not want to go to the console log on each error (not everything works, most notably interactive interpreter session)
  • interactive console at http://localhost:8080/_ah/admin/interactive (not as good as Django's python manage.py shell but still...)

Symbolic debuggers are not so valued as elsewhere, possibly because Python's superior introspection and reflection mechanisms.

zgoda