City Utilities at its finest

So Laura and I woke up at 3am to somebody pounding on our door. I grudgingly got out of bed, looked to see who it was, disarmed the alarm and open the door a crack. It was some random guy who was taking a walk (at 3am) letting me know that a water main burst outside our house. I stepped out on the front porch and saw it; sure enough, it was flowing water out of it, and you could hear it, too.

Great.

So I called City Utilities, got ahold of the water staff, and told them about it. They dispatched somebody an hour later. Which was finally when I was able to get back to sleep (because some random stranger pounding on our door in the middle of the night kinda scares the shit outta me. I was able to fall asleep again amidst the pounding, but it was the drilling this morning that woke me up.

And we’re without water this morning, which sucks really bad because we can’t brush our teeth, wash our faces, use the toilet, etc. We had to empty water bottles laying around the house into the coffee pot so we could have enough coffee.

This is the third time this has happened in a year. I’m not a big fan of living on my street.

Bitten by a nasty Django trunk change

http://code.djangoproject.com/ticket/12521

I checked out the latest build of django-trunk today and ran into a nasty change regarding how forms are validated when they’re based on models (thus, ModelForms). I have a ModelForm with fields specified as excluded (a Boolean flag, and a text field that never needs editing), and when I send form data to that model form from a template using POST data, it complains about not having those excluded fields (it throws me a UnresolvableValidationError). There’s a ticket on the Django Trac about it and whether or not it should be introduced in 1.2 (as it breaks a ton of existing code… including mine :)). Essentially, it’s been introduced to fix errors when form data is validated agains a ModelForm that may not be valid against the model from the database.

This came into play for me when I had a field, department_text, that the model said is required, but the ModelForm had it excluded in the form’s Meta class. That was probably a bad design decision on my part, so I set the model field to accept blank values, and set the form where it was required (a public facing form) to be required (by specifying an overridden form field for it).

But here lies another problem: my BooleanField. It’s set as True when a confirmation email has been sent regarding a particular checkout ticket. Otherwise, it’s defaulted to False. It’s not something a user needs to edit in a form, so it’s disabled in the ModelForm. Since it’s not present in the ModelForm, it’s not present in the template as well as the POST data that comes from that template. I then get the UnresolvableValidationError stating that the BooleanField must either be True or False. Setting it to a NullBooleanField didn’t work either. Wonderful. >_<

Temporarily, I removed it from the ModelForm’s excluded list and added it into the form in its current state (a checked or unchecked checkbox, depending on the data). A less than desirable solution to be sure… but for now that’s all I could figure out. If anybody else has an idea on how to tackle it, I’m all ears.

That is, until the Django developers decide what to do about it.

Commenting is a-go

I’ve enabled Disqus commenting on this here blog, and it’s now styled accordingly as well. Enjoy!

New Tumblr is up and running

I’ve got my Tumblr style right where I want it — for now — and I’m working on getting my domain names transferred over to this blog. I’ll try to start posting more things here, more often. Look for them!

Note: search isn’t working yet and I don’t quite know why.