I recently started using PHP’s built-in syntax checker on a more regular basis - it cuts down that whole eyeball-ing routine where you think you know that there is a missing semi-colon, and you insist on searching for it all over the place, or you’re confident you can find the extra closing parentheiss, and you waste time scanning the page.

I set up two tools (basically launchers) in UltraEdit to launch php -l (small L).

One of them to syntax-check 1.) the Active File, (if you’re not setting this up in UltraEdit, which I assume the majority, just basically just call php -l filename.php)

One of my favorite things about Django are the collection of different debugging features. As long as you have DEBUG = True in Settings, you pretty much have the cause of the error spoon-fed to you, whether it’s what line of python in the views or a model file, or if it’s a template tag error, the offending tag is bolded for you to see.

But the thing is, in my newest Django Web App, http://fridgeclick.com, a grocery list management app,  there are more Ajax-based editing and deleting functionality, than there are standard editing and deleting done with submission forms (if a user doesn’t have js enabled, it will still be a usable app, but barely).

So I’ve got a lot of function-calling going on behind the scenes, and when something goes awry, all I get to see on the console (which is what is running when running the development server), when something goes wrong is:

2 solutions come to the rescue:

1. IPython - python.scipy.org - an application that gives you what you would see if you simply typed “python” alone at the command line - but then also leaves you the kitchen sink along with it.

To make this applicable to a Django programmer specifically, the IPython Api is used for such things as automatically importing all of the modules such as form and model classes, so that you don’t have to manually go through this rigmarole, before you even start running the specific tests (which usually involves running specific db queries that you suspect are the cause of the Ajax transaction failing )

2.django logging - code.google.com/p/django-logging

I really like being able to eliminate dependence on getting error feedback from the console. As mentioned above, all you’re going to get, anyway, when you’re testing your Ajax functionality is the one liner feedback above, so having a way to log your variable outputs and sql results is a boon to debugging productivity.