3 ms·

We wrote our own version of this which took about 2 minutes to write. 1. Client hits /support/client-info which generates a specific system error with a unique

by meaty 14y ago

We wrote our own version of this which took about 2 minutes to write. 1. Client hits /support/client-info which generates a specific system error with a unique ID (right 6 digits of a GUID) and pumps browser, error and user context information via log4net into our logging system. Client tells us the error ID. 2. Open monitoring system, type error ID in. It's all there. Not only that, we use it for error monitoring too.

davidw 14y ago
Seems kind of awkward. Thinking about it offhand using some Rails terminology, let's see. * Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic. * Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This way you can not only check what they're using right now, but what they were doing yesterday when they did something that caused your site to go haywire. * I'm sure the above can be improved on: it'd be nice to package it up as a gem. This is not rocket science. Looking in the logs is easy enough, but it's data that should be very easily available to support people, and they probably should not have ssh access to the server...
- mgkimsal 14y ago
  " save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic." Probably really wouldn't be that slow, unless done really naively - much of that information is already being written to a web server logfile in most cases, and that doesn't slow things down too much. Send the info to a separate logging server/db. If you're getting a lot of traffic, you're possibly doing a lot of queries anyway - one more is incrementally painful, but shouldn't be a killer.
- meaty 14y ago
  That's naive and inefficient. We only care if there is a system error, if the user phones up or they fill in the online support form. This is only to satisfy the path of the phone call. Everything else is passed around with context. For the phone call, our logging system has a web interface (log4net appender -> postgres -> asp.net web forms page). you just visit a web page and copy and type the error ID in and you get everything from the entire context, session and client info to the stack dump.
  - davidw 14y ago
    > That's naive and inefficient. So is having a user read stuff over the phone that you already know.
    - meaty 14y ago
      Some people like to call up and chat or vent. We give them the choice.
kmfrk 14y ago
Does it account for users who change their user agent string like those using Opera, though?
- meaty 14y ago
  No and I really don't care about those users - it's entirely their problem. We support vanilla IE7-10, Firefox 6+, Chrome 10+. Any anti-virus, content filters, other browsers etc are up to the user to sort out - it's in their contract.
MicahWedemeyer 14y ago
I appreciate that it's not exactly an earth-shattering problem, but "about 2 minutes" is a huge underestimation. I think "an hour or so" is still pretty optimistic but at least possible. At that point the $10/mo for the Pro plan starts to look pretty competitive to writing your own.
- koide 14y ago
  How come $10/mo is competitive with one hour ONCE?
  - MicahWedemeyer 14y ago
    $150/hr for a good developer means this thing can run for a year and still be cheaper. Any improvements or enhancements they add you basically get for "free" over that time. Plus, I have yet to see the feature that requires coding once and never needs touching again. When I upgraded my app from Rails 2 to Rails 3, there were all sorts of 1-offs like this that I had to tweak and fiddle to get working right again. It takes well over an hour just to remember what you were thinking when you originally wrote it.
    - meaty 14y ago
      Not if you design it well and comment it properly...
- meaty 14y ago
  Versus piss around with integration (any software engineer knows this is a time sink), breaking API changes, subscription management and billing, PATRIOT act data protection issues (what happens if PI data is in the request?) as we're in the UK, the risk that one day you disappear off the planet and finally actually throwing client confidential information by email. It actually took 47 minutes looking at my work log and if I remember a lot of that was making the error page look nice. It doesn't add up. sorry. In the build vs buy debate the time versus money theory rarely applies.

by meaty 14y ago

davidw 14y ago

Seems kind of awkward. Thinking about it offhand using some Rails terminology, let's see. * Naive version: save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic. * Slightly less naive version: check to see if current_user.browser_info has changed compared to the current request in an after_filter or other hook. If so, save it in the DB. This way you can not only check what they're using right now, but what they were doing yesterday when they did something that caused your site to go haywire. * I'm sure the above can be improved on: it'd be nice to package it up as a gem. This is not rocket science. Looking in the logs is easy enough, but it's data that should be very easily available to support people, and they probably should not have ssh access to the server...

mgkimsal 14y ago
" save user information after every request via after_filter or some other hook. Probably slow for sites that get a lot of traffic." Probably really wouldn't be that slow, unless done really naively - much of that information is already being written to a web server logfile in most cases, and that doesn't slow things down too much. Send the info to a separate logging server/db. If you're getting a lot of traffic, you're possibly doing a lot of queries anyway - one more is incrementally painful, but shouldn't be a killer.
meaty 14y ago
That's naive and inefficient. We only care if there is a system error, if the user phones up or they fill in the online support form. This is only to satisfy the path of the phone call. Everything else is passed around with context. For the phone call, our logging system has a web interface (log4net appender -> postgres -> asp.net web forms page). you just visit a web page and copy and type the error ID in and you get everything from the entire context, session and client info to the stack dump.
- davidw 14y ago
  > That's naive and inefficient. So is having a user read stuff over the phone that you already know.
  - meaty 14y ago
    Some people like to call up and chat or vent. We give them the choice.

kmfrk 14y ago

Does it account for users who change their user agent string like those using Opera, though?

meaty 14y ago
No and I really don't care about those users - it's entirely their problem. We support vanilla IE7-10, Firefox 6+, Chrome 10+. Any anti-virus, content filters, other browsers etc are up to the user to sort out - it's in their contract.

MicahWedemeyer 14y ago

I appreciate that it's not exactly an earth-shattering problem, but "about 2 minutes" is a huge underestimation. I think "an hour or so" is still pretty optimistic but at least possible. At that point the $10/mo for the Pro plan starts to look pretty competitive to writing your own.

koide 14y ago
How come $10/mo is competitive with one hour ONCE?
- MicahWedemeyer 14y ago
  $150/hr for a good developer means this thing can run for a year and still be cheaper. Any improvements or enhancements they add you basically get for "free" over that time. Plus, I have yet to see the feature that requires coding once and never needs touching again. When I upgraded my app from Rails 2 to Rails 3, there were all sorts of 1-offs like this that I had to tweak and fiddle to get working right again. It takes well over an hour just to remember what you were thinking when you originally wrote it.
  - meaty 14y ago
    Not if you design it well and comment it properly...
meaty 14y ago
Versus piss around with integration (any software engineer knows this is a time sink), breaking API changes, subscription management and billing, PATRIOT act data protection issues (what happens if PI data is in the request?) as we're in the UK, the risk that one day you disappear off the planet and finally actually throwing client confidential information by email. It actually took 47 minutes looking at my work log and if I remember a lot of that was making the error page look nice. It doesn't add up. sorry. In the build vs buy debate the time versus money theory rarely applies.