HN user
I'm somewhat biased, but you should consider using a crash monitoring tool like Bugsnag (https://bugsnag.com) to help you find and fix the bugs :)
Have you spent any time working out the total market size for your app? Doing some basic modeling might help you make your decision!
Bugsnag - San Francisco, CA
We're helping product teams focus on building great software by building automated crash monitoring for web and mobile apps. Half of a typical developer’s time is currently spent finding and fixing bugs; we aim to bring that number as close to zero as possible, by automating the entire error monitoring process.
* Senior Software Engineer - https://jobs.lever.co/bugsnag/624cabdc-3233-42ab-8ff3-024486...
* Operations + Enterprise Lead Engineer - https://jobs.lever.co/bugsnag/96421958-f597-46e3-b12e-ae2184...
* Lead Communication Designer - https://jobs.lever.co/bugsnag/35cc821c-c233-4ae3-85d2-1cdc51...
* Enterprise Sales (1st sales hire) - https://jobs.lever.co/bugsnag/940475cc-15aa-4a20-b398-81e9c6...
We already work with some of the world's fastest growing and most innovative companies like Square, GitHub, Mashable, Goodreads, Buffer, Heroku (and thousands more). We’re currently doubling revenue every 3 months and we're now expanding our team of 6.
Email me (james at bugsnag.com) to talk more!
James from Bugsnag here, our notifer is fully open source (https://github.com/bugsnag/bugsnag-js) would gladly merge a pull request!
You could trivially restructure the code to factor out global page actions into an object, like this:
// Make a global page actions object
PageActions = {
selectAll: function (event, context) {...},
nextPage: function (event, context) {...},
prevPage: function (event, context) {...},
};
// Hook up clicks to global actions
// Eg: <a href="#" data-action="selectAll">All</a>
$("[data-action]").click(function () {
var action = $(this).data("action");
PageActions.selectAll("click", this);
});
// Hook up keypresses to global actions
Mousetrap.bind("a", function () {
PageActions.selectAll("keypress", this);
});
This is actually a really good point, I've seen many sites take the approach of adding keyboard shortcuts but avoiding the main "default" actions, (eg. space bar, up, down).
we're hiring engineers right now, let me know if you want to know more!
Bugsnag co-founder here. Let me know if you guys have any suggestions or feedback for the API.
James from Bugsnag here, we're constantly rolling out tons of new features to speed up the find/fix/deploy bug hunting cycle. I'm surprised so many people are still using emails for error monitoring, using a hosted service like Bugsnag/airbrake/rollbar will massively help with productivity and actionability.
We've been using Inc in beta at Bugsnag for the last couple of weeks, super useful product. HipChat integration is the best feature. Integrating with existing workflows a far better solution to inbox overload.
The number of pull requests I get where the diffs are completely unreadable because someone has this feature enabled is insane. On certain whitespace dependent languages (I'm looking at you Python) simply supressing the whitespace in the diff is not an option.
What are the arguments for having whitespace removal as a coding standard?
Congrats to the Exceptional team!
For anyone looking to switch from Airbrake/Exceptional to a more modern/reliable error tracking product, check out our product Bugsnag (https://bugsnag.com).
James from Bugsnag here. We make sure to reply to people asap, we've set up Help Scout (https://www.helpscout.net) to manage the replies to these emails, so even if I'm out of the office, my co-founder can jump on and reply.
Our target is to reply within 10 minutes, unless we are asleep :)
For those asking "why is HipChat better than X", one of the big reasons lies with the number of integrations with other products.
Our product Bugsnag (https://bugsnag.com) has HipChat integration, so you can instantly see errors from your apps appear in your chat room. We've also set up curl scripts to post into chat whenever there is a deploy, or push to GitHub.
I completely agree with this. We (bugsnag) are running on rails 4 beta right now to help iron out any production issues before that is released.
We didn't, however, realize that "patch" releases also have release candidates. I'd recommend following the rails blog (http://weblog.rubyonrails.org/) which announces release candidate builds too.
Please stop feeding this obvious troll
I completely agree, huge barrier to entry.
Huge congrats to the Crittercism team. My company Bugsnag (https://bugsnag.com) also provides error monitoring for mobile apps, but it is interesting to see Crittercism's shift in focus towards performance monitoring.
There's no such thing as a quick DNS change.
Python has ConfigParser which parses ini-style config files, I assume it uses some standard grammar.
Seems to use a different approach to Stripe, using encryption rather than API hooks/callbacks.
finance
The most interesting thing about this for me is the YC company vs. YC company fighting.
"If you want to log exceptions and data from your web applications you have to install a client for your language. (Python, Ruby, PHP, Node.js)"
There seems to have been an explosion in error monitoring apps recently, competition in this market is great.
If you are checking out other services, our product Bugsnag (https://bugsnag.com) looks pretty similar to raygun, with more platforms supported, chat/sms notification and automatic issues/ticket creation.
It is also important to note that at least the 3.2.12 release forces you to upgrade rack too. This is due to seperate vulnerabilities reported in rack recently (see http://rack.github.com/).
The EU does a pretty good job of freedom of movemove, enshrined as one of the "Four Freedoms" of the EU: http://en.wikipedia.org/wiki/Four_Freedoms_(European_Union)
This diagram misses out a ton of other immigration routes, including the O1 visa (aliens of extraordinary ability, http://en.wikipedia.org/wiki/O_visa).
The "Overcommit Memory" issue has bitten me in the past on production, we were running close to the wire on redis memory usage, and Redis' fork that occurs to perisist your data to disk meant that the kernel killed our main redis process.
pry-rescue (https://github.com/ConradIrwin/pry-rescue) is also worth checking out for starting a repl when there is a crash.
Bugsnag (http://bugsnag.com) is awesome when debugging production errors.