Live data from Hacker News

Show HN: Stop asking your clients "What browser are you on?"

browser-details.com

81–85 of 85 posts

Re: Show HN: Stop asking your clients "What browser are you on?"

#81
post #80

Earlier quoted context omitted.

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.

How come $10/mo is competitive with one hour ONCE?

$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.

Re: Show HN: Stop asking your clients "What browser are you on?"

#82
post #79
post #72

Earlier quoted context omitted.

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 ge…

> That's naive and inefficient. So is having a user read stuff over the phone that you already know.

Some people like to call up and chat or vent. We give them the choice.

Re: Show HN: Stop asking your clients "What browser are you on?"

#83
post #36

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 to…

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.

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.

Re: Show HN: Stop asking your clients "What browser are you on?"

#84
post #80

Earlier quoted context omitted.

How come $10/mo is competitive with one hour ONCE?

$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 t…

Not if you design it well and comment it properly...

Re: Show HN: Stop asking your clients "What browser are you on?"

#85
post #24

Earlier quoted context omitted.

Tricky one. I don't think there's any way to solve that, other than creating certificates for every CNAME - which is too expensive and complicated for your clients. I've run into this with Campaign Monitor and they simply don't do SSL for CNAMEs. Since they do everything else perfectly, I'm assuming there's no way to solve this problem.

You can solve this problem by using a "wildcard certificate". It's like 300$ more expensive than a normal one. You can test how it works creating your own: http://www.justinsamuel.com/2006/03/11/howto-create-a-self-s...

http://www.instantssl.com/wildcard-ssl.html Presently we are using this and good to use it!
Post reply on HN