Why wrap everything in json? Then you'll just have to decode it on the other end. Just use url parameters, it's what they are for:
(new Image).src = '/errors?m='+encodeURIComponent(m)+
'&f='+encodeURIComponent(f)+'&l='+encodeURIComponent(l);
This way it also works on browsers that don't have native JSON (old IE mainly, but also firefox before 3.5). And those are also exactly the browsers where you are likely to get errors since you are probably not testing using them.
How do you keep a nefarious script kiddie from filling up your logs with bogus data? My thoughts were this:
1. Set the window.onerror to immediately push errors to an array
2. Load a small unique script that will create a basic sendError function to post the onerror arguments to an endpoint with a unique csrf set.
3. Loop through the arguments that are queued up and send them to the endpoint.
4. Replace the window.onerror with the sendError function.
Your endpoint can be an API that will log the data to either something like Graylog2 or whatever your favorite logging system is. Not 100% bullet proof but better then nothing.
For some reason I thought they were doing more than this, like proxying your JavaScript (hence PROXino), instrumenting it with try/catches to provide robust stack traces, but apparently not: https://www.proxino.com/p.js
There are already services (like Sentry) that track errors well. I want a service that focuses on the non-error logging part.
I typically develop my JS with a lot of console.log calls. Let's say a hundred at page load, and more for each user action, and when there's new data coming down from the server. I'm trying to fix a bug that my friend is having on my new project, but I can't reproduce it locally. I want to see those console logs from her sessions. There's no tool that's designed for this right now. For example, most analytics platforms send an HTTP request on every event.
I'm already using this wrapper http://paulirish.com/2009/log-a-lightweight-wrapper-for-cons..., which wraps console.log and keeps a history client-side. That would be a good starting point. Just push that history up to the server, up to once a second or so.
I should be able to filter by user and browser window session, and ideally other features of the client or log contents, but really the user+browser session are the most important.
Not feasible for most apps, but if you already have a websocket open, just stream the logs back to the server. Be prepared to store massive amounts of data even for a few hundred clients.
In the Proxino video, I believe it said you can log arbitrary messages which can then be accessed via the web backend. You could probably just make a wrapper for console.log which both pushes the message to Proxino and logs it in the console.
Personally, I use Loggr (http://loggr.net) for tracking errors and events. You can tag your events however you want so it is really easy to track user sessions and so on.
Wow. jQuery is 80% or more of the whole file. It could be loaded asynchronously, and completely avoided if it's already loaded (which is very likely).
Worst of all, it uses exactly one function, jQuery.ajax, which could be replaced with a `new Image; image.src = message` call or a 10 line XHR wrapper.
I think you could better communicate potential objections and overcome them with your copy/video.
One I have is, how's this going to impact performance?
Also, once I sign up for the free trial, I'm presented with an account screen but not really told what to do next. Sure, I figured it out, but I think it should be more welcoming.
One more suggestion, don't send emails from [email protected]. Especially considering that your registration email comes from here, and is sent to potential customers who may have a quick question before buying.
noreply@ says you don't want to talk to me.
Make is easy to answer questions and help people. Utilize a tool like Zendesk, if needed.
I've only played with both for a few days, but to summarise: Proxino's UI is drastically nicer, whereas errorception has been around longer and is more reliable.
Proxino is still in beta, so I wouldn't use it for mission-critical websites yet. But Proxino seems to be fixing problems and iterating quickly.
Looking forward to trying it out, but the fact 'localhost' is not changeable is tough since nothing I build is direct on 'localhost'. typically it's site.dev or a local version of the site.com hostname, sometimes with a port to better simulate the real project. any chance you can add the option to change the 'localhost' on the fly in your console?
How does this work with minified/obfuscated production code? Some of the other comments suggest that proxino is listening to and logs on 'window.onerror'. If that is the case, I don't think you can get stack traces in all browsers, and the line number for a minified file will alway be 1.
Hmmm. Didn't this launch like a year ago? I remember emailing them about some questions I had a couple times and never got a reply, I assumed they shut down. Too bad since during this time a few competitors have come up: Sentry, ExceptionHub, etc
Does this handle cross domain errors? We're currently doing this in house but some of our script errors are very nondescript as some of our JS is hosted on another domain.
[+] [-] ricardobeat|14 years ago|reply
[+] [-] ars|14 years ago|reply
[+] [-] DevMonkey|14 years ago|reply
1. Set the window.onerror to immediately push errors to an array 2. Load a small unique script that will create a basic sendError function to post the onerror arguments to an endpoint with a unique csrf set. 3. Loop through the arguments that are queued up and send them to the endpoint. 4. Replace the window.onerror with the sendError function.
Your endpoint can be an API that will log the data to either something like Graylog2 or whatever your favorite logging system is. Not 100% bullet proof but better then nothing.
[+] [-] tlrobinson|14 years ago|reply
[+] [-] bdr|14 years ago|reply
I typically develop my JS with a lot of console.log calls. Let's say a hundred at page load, and more for each user action, and when there's new data coming down from the server. I'm trying to fix a bug that my friend is having on my new project, but I can't reproduce it locally. I want to see those console logs from her sessions. There's no tool that's designed for this right now. For example, most analytics platforms send an HTTP request on every event.
I'm already using this wrapper http://paulirish.com/2009/log-a-lightweight-wrapper-for-cons..., which wraps console.log and keeps a history client-side. That would be a good starting point. Just push that history up to the server, up to once a second or so.
I should be able to filter by user and browser window session, and ideally other features of the client or log contents, but really the user+browser session are the most important.
Does a good solution exist?
[+] [-] ricardobeat|14 years ago|reply
[+] [-] sim0n|14 years ago|reply
[+] [-] nealerickson|14 years ago|reply
[+] [-] gzavitz|14 years ago|reply
[+] [-] cheeaun|14 years ago|reply
[+] [-] ricardobeat|14 years ago|reply
Worst of all, it uses exactly one function, jQuery.ajax, which could be replaced with a `new Image; image.src = message` call or a 10 line XHR wrapper.
[+] [-] unignorant|14 years ago|reply
[+] [-] lucasjans|14 years ago|reply
[+] [-] RoboTeddy|14 years ago|reply
[+] [-] septerr|14 years ago|reply
[+] [-] unignorant|14 years ago|reply
[+] [-] lucasjans|14 years ago|reply
One I have is, how's this going to impact performance?
Also, once I sign up for the free trial, I'm presented with an account screen but not really told what to do next. Sure, I figured it out, but I think it should be more welcoming.
Good luck! I may use this.
[+] [-] lucasjans|14 years ago|reply
noreply@ says you don't want to talk to me.
Make is easy to answer questions and help people. Utilize a tool like Zendesk, if needed.
[+] [-] aristidesfl|14 years ago|reply
[+] [-] lucajona|13 years ago|reply
Proxino is still in beta, so I wouldn't use it for mission-critical websites yet. But Proxino seems to be fixing problems and iterating quickly.
[+] [-] nodesocket|14 years ago|reply
[+] [-] unignorant|14 years ago|reply
[+] [-] noinput|14 years ago|reply
[+] [-] unignorant|14 years ago|reply
[+] [-] delambo|13 years ago|reply
[+] [-] manuelflara|14 years ago|reply
[+] [-] unignorant|14 years ago|reply
[+] [-] joshstrange|14 years ago|reply
status: "That domain isn't registered..."
And I don't really feel like paying $10 to TEST if the tool really works, let alone if I want to use it. Working demo please.
[+] [-] unignorant|14 years ago|reply
[+] [-] dwynings|14 years ago|reply
[+] [-] c-oreills|13 years ago|reply
[+] [-] leandono|14 years ago|reply
[+] [-] thepumpkin1979|14 years ago|reply
[+] [-] MarxGames|14 years ago|reply
[+] [-] ryanstout|14 years ago|reply