@unignorant are you the dude in the demo video? I haven't met a more modle-esque JS developer.
Yes, I am.
Awesome~
Show HN: Proxino -- Monitor and Debug your JavaScript
41–49 of 49 posts
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#42Who made your demo video? It is quite good.
Thank you :) It was an in-house production.
I'm curious how much effort it needed. The images where beautiful and professional. Excellent work.
The voice was lacking some testosterone, but it's a detail. I'm sorry about the critics on the technical aspect of your app. There are indeed some true JS hackers around. I hope you get over it and collect all the good ideas to enhance your product.
I'm no JS hacker and I wasted allot of time trying to figure out why m app wasn't doing what I expected it to do. There is a problem there that needs a solution. As you see hackers have their own tricks to get around this problem. Collecting them and offering them in one plug and play product would be very usefull for all the people out there who aren't hackers.
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#43For hackers: window.onerror = function(m, f, l){ var err = JSON.encode({ message:m, file:f, line:l }) (new Image).src = '/errors?e='+err } For Google Analytics users: window.onerror = function(m, f, l){ var err = [f, l, m].join(' : ') _gaq.push(['_trackEvent', 'Errors', 'App', err, null, true]) } Analytics will allow you to filter by OS, browser, and all the other environment data it already captures. And nice graphs…
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.on…
> How do you keep a nefarious script kiddie from filling up your logs with bogus data?
You don't. Such a behavior is boring to them, so most won't. It does not provide money nor a way into the server, so no motivation.
If they want to DOS you they have many possible methods, adding this doesn't really change anything.
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#44Earlier quoted context omitted.
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 e…
Currently it's usually easier to decode JSON than to parse a query string. Modify to taste. You don't need to encode the strings, the browser will do that for src.
> Currently it's usually easier to decode JSON than to parse a query string.
I don't see how that could be when you anyway have to parse the query string to get the e parameter. It costs nothing extra to get additional parameters.
> You don't need to encode the strings, the browser will do that for src.
Not in my testing - if the error message includes an & it will appear to the webserver as a new url parameter.
And actually that's a bug in your JSON version as well - you need to encode it before sending it.
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#45Earlier quoted context omitted.
Currently it's usually easier to decode JSON than to parse a query string. Modify to taste. You don't need to encode the strings, the browser will do that for src.
> Currently it's usually easier to decode JSON than to parse a query string. I don't see how that could be when you anyway have to parse the query string to get the e parameter. It costs nothing extra to get additional parameters. > You don't need to encode the strings, the browser will do that for src. Not in my testing - if the error message includes an & it will appear to the webserver as a new url parameter. And…
Yes, I overlooked that. The way I'm doing that right now is with a route /errors/$message, so there's no query string parsing going on.
I also typed encode instead of stringify, and forgot to add a semi-colon after wrapping new Image in parentheses...
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#46doesn't work with mobile browsers(most of them) that don't support window.onerror
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#47Does 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.
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#48How 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.
Re: Show HN: Proxino -- Monitor and Debug your JavaScript
#49How does this compare with http://errorception.com/ ?
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.