The class has proven to be very motivating.

Although my current role is MySQL DBA, I have been a professional web developer since 1995. I was really amazed by what I was able to do with Django by the end of this class. I have gone on to learn about Python in general.

I was able to take what I learned about Python and modify this open source script for uploading to Flickr so that I can use it as a plug-in to export from Bibble to Flickr in a batch workflow.

I have been reading Learning Python, and am really looking forward to using Python and Django both personally and professionally.

Generic views

We finished up newforms today and also covered generic views.

I love, love, love generic views. The less code we have to write, (and thus the less code we have to test), the better and more effecient we'll be.

Juan made a really good observation/training point I hadn't thought of: the CRUD generic views all use oldforms.

I hadn't really dug into the CRUD generic views until the class and I had previously thought how easy/great it'd be to have generic CRUD views. But upon further reflection in class the CRUD views have two things going against them:

* They use old forms
* If your exposing a CRUD function to the public, then you probably need really fine grained control over that controller/workflow.

That said, the rest of the generic views are great, and I'm a huge fan of wrapping generic views if they only get you "part of the way" there.

What a day

It's the end of the second day and we covered a lot of ground -- admin, views, templates and newforms.

The biggest knowledge gain for me was newforms -- they're very nice. I'm no slouch when it comes to HTML, but this is one task I'm glad Django automates for me. I've spent enough time debugging/writing code to handle form input/form generation -- this is really one area where I think Django shines above Rails (not that they're competing against each other... they're just the two "next gen" frameworks I've tried).

One thing that did bug me is that there must be a better way to remove the "------" choice from a Django ForeignKey <select> representation than my way:

    good_choices = []
    for choice in Form.base_fields['todo_list'].widget.choices:
        if choice[0]:
            #Cuz if it's false, it's probably the stupid -------- choice
            good_choices.append(choice)

    Form.base_fields['todo_list'].widget.choices = good_choices

Tomorrow is Forms Part II....

So far, so good

It's still the middle of our first day of training, but it's going well.

Our instructor, Juan Pablo-Claude, did a good rundown of what Django is -- probably could use a bit of background on its history, but maybe later as we get into specific design decisions the core team made.

Our first day, so far, has been setup and install of Python, the DB drivers, Django, etc. Personally, I've realized how quasi-painful that can be (esp. when I sat down with our summer intern to do this the other day) -- I'm thinking it'd be cool I could build a Parallels image (maybe VM?) of something like Ubuntu/CentOS that has everything you need and the ability to mount it onto your Mac as a filesystem, so you can use your favorite Mac text editor (Textmate, presently).

Also, Juan's done a good job of pulling together some Python basics for folks new to Django (and thus Python) -- though I may be biased as I've got about 4+ years of Python experience...