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.
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.
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 would help with code structure and organization, at the cost of flexibility.
I like to go one step further and simply add a global event delegate to transparently tie DOM elements into a UI controller scoped to a particular portion of the application (to account for sidebars acting differently than the main content). Since 95% of the events handled are click events, it saves a lot of time.
The whole thing ends up being about ten lines of code to implement and handles event binding for practically the entire application. Literally ends up cutting out thousands of lines of boilerplate in larger applications.
I've also found that the actual event object is only useful in a very small amount of cases (drag events and such), to the point where if I ever really need to pass it along, I'll just write a custom event controller for it (using data-handler to specify the custom controller).
When I have too much free time on my hands, I cut out the data attributes entirely and instead route using good old normal hrefs, which as a bonus can render on their own if something goes wrong with the JS.
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).
... and since they can't know what those actions are (since it's up to the user-agent), we're at an awkward nonstandard cat-and-mouse game. Long live ze veb!
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?
It's dead easy to accidentally add (or remove) trailing whitespace, which you find out at git diff time. Unless you want to have whitespace changes in your commit, you have to manually revert those edits back.
Having the editor just trim those automatically is just delegating the trailing whitespace care to a piece of software with a simple rule: no whitespace allowed.
If the entire team working on a project agrees to this rule, everything's peachy, and it's really easy to convert an existing repo to it - whenever you touch a file, if there are whitespace changes, commit them to a separate commit.
At the end of the day, it's just standard, so doing invasive changes to a project that doesn't follow that standard (as in the pull reqs you descibed) is wrong, but that doesn't mean the rule itself is bad.
As for ST2, it allows easy per-project settings so you can easily enable it globally and disable on a specific project if needed (or vice versa).
Have you spent any time working out the total market size for your app? Doing some basic modeling might help you make your decision!