Wow – I’m really glad I learned about this performance hit on the Django list today.
Turns out that in the process of attempting to give back from really nice error messages from the default AddManipulator’s in Django 0.95, it has a HUGE performance impact that is documented, but man – I would’a easily missed it. The default value for “raw_id_admin” on a ForeignKey model in Django is False. Turns out the implications of that are that when you invoke an AddManipulator for an object with a ForeignKey relationship somewhere, it attempts to load up all potential values into memory and check against them… Yuck!
I really couldn’t believe this, so I went home and using the models from that mail thread, I created a test app and ran some time. Here’s what I got:
Yeah – that’s something like near linear growth of the time it takes to add a new object with the number of potential relationships.
Update: I posted the test case I created as bug #2638
Good lord, I’ve got to wonder if this is real?
Testimony that a guy was hired to “rig the elections” with voting machines?
It sure sounds like legitimate testimony, but there hasn’t been anything in the major news outlets. You’d rather think there would be…
Seattle Mind Camp 3.0 – coming this November…
You had a good time putting one back at Zeitgeist. See – here you are with a few of your favorite thugs!
(sorry it took so long to post)
As seen on the Maven2 user’s mailing list: Source Control: Anything But SourceSafe
And yes, that means I “get” to deal with VSS upon occasion.
Ah, this is a brilliant bit of work: How to write unmaintainable code
(and yes, it’s a commentary on what NOT to do when coding…)
In the 0.95 release code, the model valdiation logic can be a little shakey. In particular, I ran into this traceback today while doing a little code conversion:
Traceback (most recent call last):
File "manage.py", line 11, in ?
line 1319, in execute_manager
line 1243, in execute_from_command_line
line 1003, in validate
num_errors = get_validation_errors(outfile)
line 933, in get_validation_errors
if not hasattr(cls, fn):
TypeError: hasattr(): attribute name must be string
Turns out this code is much happier in the trunk version than the 0.95 release, but the error ultimately means that I messed up and what was returned in an Admin list_display entry wasn’t a list or tuple, but something else.
In particular, this model code:
cat_type = models.CharField(maxlength=25)
threw the error – it was that nasty little comma at the end of list_display…
I hadn’t read much of anything by Vernor Vinge until just recently, but man – I’ve sure been hearing the name about. When I was last in Queen Anne Avenue Books, I just went ahead and picked up a few titles.
I’ve just finished The Peace War. He’s quite an exceptional writer – at least by judging off this novel. Very engaging with characters that have a nice arc, a flip or two of science and the social implications – a very well rounded piece.
For the next one, I have a copy of Rainbow’s End waiting for me to spend some quality time with it. I think it’ll be a little bit, because his books are engaging enough to not really want to put down once you start – a dangerous thing for weekday evening.
If you haven’t checked him out (and you enjoy SciFi), he’s worth a read.
Wow – this is a beautifully detailed example of the security hole that existed in Rails version 1.1.4. I live more in the Django world, but I wouldn’t swear to anyone that similiar holes couldn’t be found there. Jeez, I more than just hope not! But the overview is a great detail for anyone interested in looking at their own code for how it could be abused.
I think that’s almost the key to developing. When you’re coding, you think about what it should do. It’s relatively uncommon to think about what it shouldn’t do – or how it should break. It’s a shame to some extent, but that is exactly what something like test driven development helps to resolve – getting people to think about the failure modes. The analog in security realm would be to think about how this code could be abused – and code defensively.
In the world of C, I know a fair number of folks who complain that they don’t want to use strlcpy() method because it “breaks” things that have already been written using strcpy(). Man, I think – take the hit. Suck it up, repair the off-by-one index errors and assumptions. It’s better than an open invitation to code abuse. Besides, it’s way easier to fix your code than to prove that your error could never be used against you.
Maybe it’s the weather, or the water, or .. hell, I dunno. But I think Chris has it pretty nailed when he called out the huge number of indie and professional mac programmers in the Seattle area in his WWDC decompression post.
Reflecting back on the week, now that I’ve had a little more sleep, a touch of coffee, and no alcohol for a few days – there is a fair bit that stands out from the WWDC information. Time machine and Core Animation are clearly going to be the two big gorillas in the cage making their presence known. The 64bit all-the-way through support is in many respects a whole OS upgrade in and of itself.
The reality behind the brief mention of code refactoring support in XCode is nice, and hopefully will get even better. A lot of Mac coders I talked to briefly hadn’t worked with refactoring support – so I rather hope it will become another in the secret-weapon productivity arsenal that you get when programming on MacOS X. There are some new libraries that I think will also fit into the “secret weapons” category that aren’t mentioned on Apple’s Leopard site, so I’ll have to keep otherwise mum about them.