When you're using SQLAlchemy you sometimes get into a fog where everything's so abstracted away that you forget there's a regular old PostgreSQL or SQLite instance under there. Thing is, there *is* a PostgreSQL instance under there, and if you use a Float data-type for your code, it will work perfectly well under SQLite (which is storing the values as strings), but blow up in weird and wonderful ways under PostgreSQL, which uses a 4-byte float by default.

Pythonistas, of course, sometimes forget that float means a 4-byte value in most of the programming world... I obviously haven't done enough PyOpenGL lately to remind myself of that...

In other blindingly-obvious-once-you-take-some-time-off-to-work-on-paying-client-stuff news, ChatTrack was so painfully slow because I was trying to have the clients track channels on a message-by-message basis; the idea being; you see something you want to follow (however that shows up, with the idea that you might have extremely complex logic managing how interest was established) and the client just adds it to its interest set... problem is, this is a long-polling streaming implementation, and new messages are showing up 20 per second during the tests... that means each open client was more-than doubling the number of requests/second with their cancel and then re-poll for each new message (DUH!). Since they are all running on the same machine, the JS-heavy rendering/plumbing code was also gumming up the works. It was in setting up the area-of-interest code that I discovered the little 4-byte float issue above.

Have been working on finalizing the form of the presentation (as well as continuing to tinker with the content) for PyCon and PyGTA. I'm seriously considering using Slidy (HTML+CSS slides), with the ChatTrack surveys embedded in the page (in IFrames). Would really like to get the sort-by-votes view done for that... and need to get the user view re-wired for the new area-of-interest stuff... ah, so much to get done so few days.