cold cuts combo @ 01:25 pm
Dear Lazyweb,
I am becoming the sort of person who needs to carry their calendar with them. This isn't a terribly complicated adjustment to make, but for the fact that I have this belief that all calendars should be able to sync to something with an iCal view, and Slingshots do not have digital interfaces. My current cellular plan won't even work with Google calendar's SMS functions.
So I'm in the market for another gadget, and I'm asking you for recommendations. It seems like the most straightforward thing to do would be to pick up something like a refurbished Palm Z22. But in this age of the convergence device, do I really want to carry a PDA and a phone? I guess that would hardly be worse than carrying a Slingshot and a phone.
On the other end of the spectrum there's the iPhone. That would, I assume, require me to switch to a more expensive calling plan, but maybe I should just suck it up and deal. I'm trending toward using more phone minutes anyway.
My criteria seem to be lightweight=good, recurring costs=bad. Advice?
artichoke @ 01:16 pm
Sometimes the software we run generates errors.
I mean, it'd be nice if it didn't, but it does, and so what we hope for is that the error report includes enough information about the conditions that led to the error for us to track it down and fix it. Generating a report for a particular error is something pretty well understood; we generally use some variation on stack traces and core dumps, which works well enough.
The part I don't manage so well is what you do when you're receiving these errors from not just a single customer working with your application, but from the global set of all your users at once. (This problem is most obvious in web applications, but plenty of desktop applications have "report crash to developer" functionality now as well.) The approaches I've seen so far are
- show an error message to your user, and leave it to them to figure out how to communicate the error to you. I trust I don't need to go in to all the ways in which this sucks.
- dump everything into a log file, which is easy to do, but has insufficient structure to get a high-level view of what the current state of things is.
- send an email with every error, which works fine in many cases, but it makes bad problems worse, because now in addition to dealing with a bug that needs fixing, you now have to deal with a torrential flow of emails (with large chunks of debugging data attached) clogging your developers' inboxes.
The balance I need is to be informed of a new type of error as quickly as possible, but to not be flooded with redundant reports. I need to know if the problem is affecting 80% of our users, or just one in a thousand. I need all the debugging information stored somewhere for inspection if I need it, but not all pushed down to my email/phone/jabber/whatever in case I don't. I want to classify reports by exception type, code path, and perhaps other random details (browser version, IP address, etc).
I know I'm not the only one with these requirements, so I'm sure an application for managing this exists somewhere, I just haven't found it yet. What is it?
tomato curry [company lunch] @ 02:30 pm
I've been working with Ruby on a semi-regular basis for a while now, and there's something that's still bothering me. Well, to be honest, there are a number of things, but one of them in particular seems like it should be solvable.
Here's the last few frames of a typical Ruby on Rails traceback:
And here are the last few frames of a typical Nevow traceback in Python:
It's not just the web environment either, you can make similar comparisons between ipython and irb.
Is there any help to be had? Or should I tell my office manager to get one of those inflatable punching bags to smash the next time someone sends me one of these stupid crippled ruby tracebacks?
