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.

One of the more enjoyable parts about writing my current Django app is thinking about all of the ways that Ajax could
make using it more painless for users who hate to wait for a page to reload.

I’m thinking, if the technology is there, and there are libraries available such as jQuery that make doing this client side magic so much easier, then it makes the most sense to pull the pressure off of the server, and “spread” more of the processing demands to the users’ own PC (i.e., their browser).

Read the rest of this entry »

Before purchasing my Asus Eee, I knew that one of the primary uses was going to be as a portable Internet radio to listen to my favorite L.A. radio stations ( I’m originally from SoCA).

Now  I’m thinking that the highest value I get from it,  is to be able to kick back on the couch and read online documentation that I previously had to sit up at the desk and read on the desktop monitor.

I make it a point to spend at least 15/20 minutes a day reading jQuery and/or Django documentation, checking out API specs and features that don’t relate to any specific task I currently have.  While reading, I never fail to complete some “click” in my brain as to how something works under the hood, or to discover some super-useful or powerful feature in Django pertaining to using forms, or templates.

Read the rest of this entry »