When Systems Go Wrong; an Unprogress Bar; Where’s the Next Update?

When Systems Go Wrong

My support system: try to send a helpful reply within 24 hours.

Problem case #1: The recipient’s spam filter eats my message. So he writes again. I answer again, this time writing in simpler terms, assuming he didn’t understand my last message. He writes again, now getting shirty because it seems I’m ignoring his e-mails.

Problem case #2: The recipient’s inbox is full and bouncing messages. Some people have tight e-mail inbox quotas. If this is you, please sign up with Google Mail. It’s free. It’s good. It has huge quotas, currently 7 gigabytes.

These things – and many others – thwart my support system. I don’t really have a good way to handle these. The first case I can solve by trying to send from my personal e-mail address, which I don’t really like doing. The second case is tough.

An Unprogress Bar

When is a progress bar not a progress bar? When it doesn’t progress. This happened last week to all of Poker Copilot’s progress bars, progress circles, progress indicators. It took me the best part of two frustrating days to solve the problem. It was evidence of a threading problem, so it needed to be solved. The culprit? Me, of course. A combination of changing a non-modal window into a modal window and not disposing of resources.

Where’s the Next Poker Copilot Update?

It’s more or less ready to go, except I’m not happy with the performance of loading 300K hands or more. I added lots of database indexes to make querying as fast as I can. This has led to slower hand history loading. So I’m investigating anything I can do to improve this. The time trials for this are very time-consuming. When I make one tiny tentative tweak, it takes an hour to find out whether hand loading is slower or faster after the 300K point.

Maybe I need to follow the golden rule in database work: users will tolerate slow database writes and fast database reads more than they will tolerate fast writes and slow reads.