rakeshpai

5 ms·

1.
Stack Traces, window.onerror, and the future(blog.errorception.com)
1 points by rakeshpai 13y ago|0 comments
2.
by rakeshpai 13y ago
I think I might have 2c to clarify the OP's stand, having worked on a mobile XMPP client before. This is with regards to his point about bandwidth and battery usage on mobile. XMPP is a connection-oriented stateful protocol. The connection
3.
CPU core estimation with JavaScript(blog.wg.oftn.org)
44 points by rakeshpai 13y ago|43 comments
4.
Your JS errors are now just an API call away(blog.errorception.com)
13 points by rakeshpai 14y ago|0 comments
5.
Catching Cross-Domain JS Errors(blog.errorception.com)
3 points by rakeshpai 14y ago|0 comments
6.
JavaScript's "Script error" on line 0(blog.errorception.com)
5 points by rakeshpai 14y ago|1 comments
7.
by rakeshpai 14y ago
I would, but I'm not sure if Firefox is "wrong". That may be a subjective opinion, though.
8.
by rakeshpai 14y ago
It isn't possible to have a single "wrapper" try/catch in JS, because of the event-loop nature of most JS hosts. This is because functions that are scheduled to run on the event loop (say, using a button click, or a ajax call), aren't in th
9.
by rakeshpai 14y ago
Yes there are. Google Closure compiler does export this thing called Source Maps ( http://www.html5rocks.com/en/tutorials/developertools/source... ) which is very exciting. If it weren't for the fact that we don't get column numbers in wind
10.
by rakeshpai 14y ago
The developer of Errorception ( http://errorception.com/ ) here. "Script Error" at line 0 only occurs in Firefox - I know, I'm in the business of collecting errors ;). It seems to happen when the JS file couldn't be parsed correctly. The ca
11.
by rakeshpai 14y ago
This is what I meant, though I guess I could've used a better term than "code paths". Thanks for clarifying this anyway. :)
12.
by rakeshpai 14y ago
You aren't wrong if you are looking at the server's resource consumption. However, the need to buffer the errors is so that we can minimize network overhead, from the client's perspective. It's to reduce the number of HTTP connections, even
13.
by rakeshpai 14y ago
If this is happening in Firefox, it's usually because the JS file couldn't be parsed correctly. In my experience this is usually because of partial/interrupted download of the code.
14.
by rakeshpai 14y ago
Link about v8 performance cost of try/catch. http://floitsch.blogspot.in/2012/03/optimizing-for-v8-introd... "It turns out that some constructs are not yet supported by Crankshaft. In particular, try/catch turns off all optimizations in a
15.
by rakeshpai 14y ago
I'm the developer of Errorception ( http://errorception.com/ ), and wanted to jump in to talk about some of the points raised on the thread here. As chrisacky mentioned, making one HTTP post for every error is very wasteful. It's much bette
16.
by rakeshpai 14y ago
That's likely too. It could be the Chrome sync thing that must've spread the extension across to Mac and Windows.
17.
The Tale of an Unfindable JS Error(blog.errorception.com)
24 points by rakeshpai 14y ago|2 comments
18.
Writing Quality Third-Party JS - Part 3: Planning for an API(blog.errorception.com)
2 points by rakeshpai 15y ago|0 comments
19.
Writing Quality Third-Party JS - Part 2: Loading Your Code(blog.errorception.com)
17 points by rakeshpai 15y ago|1 comments
20.
by rakeshpai 15y ago
>> No. Monosyllabic answer is monosyllabic. You only state that you disagree, not why you disagree. Doesn't help take the discussion forward. >> if you are going to try to come off as an authority Why would you think I want
21.
by rakeshpai 15y ago
"use strict" is a good idea to ensure quality of your code, no doubt. However, the point I was making was about global pollution. Though "use strict" will help in ES5 browsers, a lint is the only comprehensive way to make sure there's no gl
22.
by rakeshpai 15y ago
Haha. Good catch. I'll reword that a bit.
23.
by rakeshpai 15y ago
Thanks. Fixed.
24.
by rakeshpai 15y ago
Thanks for pointing this out. I've fixed the FAQ to be more recent - what you saw was from an older time. Thanks again.
25.
by rakeshpai 15y ago
That's a neat suggestion, though it may be hard to distinguish between developer errors and library errors. It's definitely something to aspire for. Great to know you are liking the service. Cheers!
26.
by rakeshpai 15y ago
Hey Greg, The challenge you have mentioned is real, and is hard to crack. I certainly haven't solved the problem to my satisfaction yet. However, I'm rather far along the way. A lot of errors are classified as being irrelevant (I call it "m
27.
by rakeshpai 15y ago
I've heard about Muscula (and I'm reasonably sure they've heard about Errorception - it's a smallish world :) ), and I'm curious to know more about how they do what they do. That said, the architecture isn't too different. Errorception is a
28.
by rakeshpai 15y ago
bdg, I mean no disrespect, but the matter is honestly not that trivial. Ultimately, you are right - it does come down to getting some queries right, but you quickly discover that it's an ongoing effort. Three months since I'm doing this, an
29.
by rakeshpai 15y ago
Haha. Thanks for this feedback. I really have to work on my (non-existing?) marketing skill.
30.
by rakeshpai 15y ago
Thanks for taking the time for the comment, bdg. About the pitch/technology/complications: You are right - everyone here too has echoed that I should clarify how the tech works, why it isn't really trivial, and generally improve the marketi

More ›