gundy dot org

OK, so that’s a little dramatic, but still, my blog’s google placement for certain keywords has suffered sorely and it troubles me.

It all started with comment spam. I installed a spam eating plug-in to keep the flood from pouring over my blog, and it worked well - too well. At first, I was delighted to see that my INBOX was no longer filled with emails alerting me to the fact that posts needed moderating. After a while, it seems that they tapered off all together. “Great!” I thought, “This thing must really be learning what spam looks like.”

After some time, I googled “AGI” and noticed my site wasn’t in the result list. I thought that was odd as the keyword “AGI” had always included my blog in the top 10 or so (this is just a guess as my vanity googling was never very formal). I thought my page rank must have gone down, so I checked…

“Ahhh! Blank pages everywhere!”

Somehow the plug-in had jacked the WP “loop” and the result was blank pages - lots of them. For some reason, the problem didn’t manifest itself until sometime after installing the plug-in.

I’m no PHP hacker, but I did my best to follow the code. I was never able to figure out what was happening; I suppose if I knew more about WordPress, I could’ve figured it out as the PHP was fairly easy to follow. I didn’t want to dive into WP more then I already had (I’m going to replace it with a homespun Django blog anyway), so I decided to just update it to the latest WP version and see if that would fix it. It did.

Now, I find that google has nearly dropped my blog off the face of the earth. Check the search results…

Gundy 1st — 6th
Gabe Gunderson 1st — 340th
Gunderson ~15th — 392nd
Gabriel ~35th — 931st
Gabe ~35th — 871st
AGI ~10th — 291st
Asterisk C# 1st — 313th

The traffic graph seems to back it up:

Anyway, If I’m not in your blogroll, you can add me to it and help stop this search engine injustice! Or, if you need less lofty motivation, you can just do it to throw a dog a bone!

P.S. I’m now using Akismet to fight spam (on the recommendation of others).

Today’s screenshot is brought to you by the Django Admin interface:

For those of you who don’t recognize this, it’s the GNOME System Monitor applet. The dark blue basically represents CPU usage for Django (more accurately - caused by Django). The model validates [1] and the tables/Models are shown in the front page of the Admins interface. Most of the Models are represented well and work as one would expect. However, there is one table/Model that doesn’t work as expected. It works OK when you go to add an additional record [2], but when going to view items before changing them [3], it causes the CPU to spike and three minutes later I have my results. Before I edited the table/Model to remove one of the ForeignKeys, I would get a PostgreSQL error because Django passed it a SELECT statement with *over* 1664 entries [4]! Well, it seems that by editing the table I was able to keep the entries under the 1664 limit and PostgreSQL would process the SELECT, but it takes forever to finish it.

I guess that technically, the CPU is being eaten up by PostgreSQL, but that’s not really the point. The point is that Django really doesn’t have any business sending it a SELECT statement with some 2000+ entries in it (especially for such a simple, simple request.) OK, so maybe it has a bug, limitation or whatever, I’m cool with that - it happens. The frustrating part is that I can’t confirm that this is a known problem or find the answer. The answer I’m looking for should be simple, but I have not been able to find it. IRC and #django was a bust and the mailing list yields nothing yet.

I was pretty enthusiastic about Django, but maybe it’s to soon. It’s a cool project and I wish them luck. I’m just wondering if all the time spent so far porting one of my apps to the Django framework was time wasted or not.

1) -
./manage.py runserver
Validating models…
0 errors found.

2) http://localhost:8000/admin/App/Model/add/

3) http://localhost:8000/admin/App/Model/

4) -
Request URL: http://localhost:8000/admin/core/stagedorder/
Exception Type: ProgrammingError
Exception Value: ERROR: target lists can have at most 1664 entries SELECT