Airbrake Tips from Railsware

This is a guest blog post from Leonid Shevtsov, Software Engineer at Railsware, premium software development consulting company, focused on delivering great web and mobile applications. 

 
No software is complete without bugs and no Rails application is complete without proper exception tracking. In most cases we choose Airbrake to collect those exceptions for us. Here’s a couple of tips to make Airbrake more useful.

SERVER-SPECIFIC ENVIRONMENT NAMES

Here at the Playhem team we have multiple independent staging servers for testing multiple features simultaneously. If all the staging servers use the same Rails environment, Airbrake’s exception logging becomes messed up, because it categorises errors by Rails environments; it isn’t always clear as to which server and feature is the exception related to.

We could use a separate Rails environment for each staging server, but since they are otherwise identical, there is a simpler solution. Airbrake has custom environment_name setting, which can be set manually to whatever you want. I chose to customize the environment name using server-specific configs and our wonderful multi-deploy tool, but you could also use the server name, or any environment variable.

Airbrake.configure do |config|
  config.api_key = 'myapikey'
  config.environment_name = `hostname` # or whatever else
end

The best practice is to use a unique Airbrake environment_name for each server to avoid any confusion as to where did the exception happen.

Another important benefit of using server-specific environment names is that the “mark exceptions as resolved upon deploy” setting doesn’t make sense when the environment_name is not tied to the actual server.

SEPARATING JAVASCRIPT EXCEPTIONS INTO A SEPARATE PROJECT

Capturing Javascript exceptions can prove to be useful over time to pinpoint browser-specific errors that the QA rounds have missed. Unfortunately, enabling Javascript error notification usually brings you an enormous number of errors (and a lot of them unfixable, such as when a user on a faulty connection gets a Script load error). These errors flood out Rails exceptions and make Airbrake tough to use, so most people turn Javascript error notification off and forget about it.

Most, but not us! I added a separate js_api_key Airbrake configuration option that allows you to direct Javascript exceptions to a second Airbrake project.

Airbrake.configure do |config|
  config.api_key = 'myapikey'
  config.js_api_key = 'myjsapikey'
end

After that you can make use of the Airbrake error aggregation to see what exceptions are most common — and then you can start fixing them.

Have fun squashing those bugs out there!

Learn about Continuous Delivery

Production Monitoring: The Key Step Towards Continuous Delivery

This Wednesday at 11am PT / 2pm ET, we’re co-hosting a webinar on continuous delivery with the Assembla team.

Continuous Delivery is about delivering code continuously so you can gather feedback and innovate in real time. But you can’t get there all at once.

We say: If you can take only one step today towards Continuous Delivery, it should be production monitoring.

Production monitoring systems give you a real-time view of usage and errors in your system. Tools like Airbrake improve your response time by aggregating errors, so that you can see specific issues and respond in real-time. Real-time monitoring and response will give you the confidence and tools to release more frequently and move to Continuous Delivery.

In this webinar Michael Chletsos and Justin Mares will answer questions like:

  • What is Continuous Delivery, and how can it produce faster feature releases, improved quality and higher customer satisfaction?
  • How do Continuous Delivery and production monitoring fit together?
  • How can you collect and use error data and feedback effectively?
  • Can Continuous Delivery with production monitoring actually decrease developers’ stress levels and increase stability?

You can sign up for this free, 60-minute webinar here. Look forward to seeing you there!

If you have any questions you’d like us to cover during the webinar, email justin@airbrake.io with feedback.

What Triggers an Error Notification?

Something we’ve noticed lately is some confusion about what actions lead to an error notification. This is important because certain errors do not count towards your rate limit. This limit is the number of errors Airbrake will catch per minute, and scales based on the plan you’re on.

When a new error comes in, Airbrake reviews information about the error to determine whether it’s a new exception, or just another occurrence of a previous error. The factors Airbrake looks at to make this determination are below:

  • The error class of the error
  • The file in which the error occurred
  • The line number at which the error occurred
  • The action that was running when the error occurred
  • The controller that the action is in
  • The RAILS_ENV that was set when the error occurred

Missing emails?

We also explicitly do not send emails for the following errors, as they are far too common and would just become noise:

  • ActiveRecord::RecordNotFound
  • CGI::Session::CookieStore::TamperedWithCookie
  • ActionController::InvalidAuthenticityToken
  • ActionController::RoutingError
  • ActionController::UnknownAction

Resolved notices

If you “resolve” an error group from within the application, don’t worry — if it comes in again, we’ll “unresolve” it, and send you another email to indicate that it’s been re-opened. This is part of the benefit and purpose behind the resolved feature. You should be able to remove from your immediate view anything you believe is dealt with, but have the confidence to know that you’ll see it again if there are future problems.
Have further questions we didn’t address with this post? Shoot me an email – justin@airbrake.io.

How Does Environment Affect Developer Productivity?

Increasing productivity is probably the thing you worry about the most, as a product manager. You have pressures from above, in the form of time and budget constraints, and, if you’re a youthful, optimistic startup, the ever-looming threat of everything just falling apart. Fun.

There’s a lot of wisdom and a lot of conflicting Gospel Truth out there about how to make your developers the most productive. And it’s not easy to sort through when you only have one go at this. Do you ascribe to the Google philosophy that everyone is striving to emulate? The wide open football fields of office space and chairs made out of rowboats and plants and free food and M&Ms and massage tables?

Google Office

Or do you agree with Joel Spolsky of Joel on Software (and his favorite book Peopleware), in the belief that the best environment for programmers is a closed office and peace and quiet?

The idea behind the Google format is that open space leads to open communication, and a freer, more organic flow of ideas and creativity. “We believe that great, creative things are more likely to happen with the right company culture–and that doesn’t just mean lava lamps and rubber balls. There is an emphasis on team achievements and pride in individual accomplishments that contribute to our overall success,” says Google’s company page.

But Joel Spolsky refers to this open-floor idea as “folk wisdom,” saying, “There’s a strong culture in Silicon Valley that requires you to jam a lot of programmers into a big open space, despite a preponderance of evidence that private offices are far more productive.” He advocates for peace and quiet and closed doors for his developers, and ascribes the success of his company, Fog Creek Software, to this workplace philosophy.

The Google formula goes back to Mel Conway’s seminal 1967 article “How Do Committees Invent”, in which he presented what later came to be known as Conway’s Law:

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Google’s aim is a suite of products that are organic and seamlessly integrated with your daily life, so they’ve created an organic workplace that’s intimately integrated with the daily lives of their employees. Find an organization structure that makes you feel good, and you will produce a product, a piece of software, that makes you feel good.

That’s a philosophy that makes a lot of sense psychologically, and Google obviously has done well with it, so no wonder everyone is trying to copy that. But do the numbers back it up? Spolsky’s blog continuously affirms that they do not (http://www.joelonsoftware.com/items/2005/10/16.html).

I think that, like most things, this requires balance. Conway is probably right, in that better communication leads to better forward progress towards a mutual goal. Google is right in that an open, even-playing-field workplace without boundaries leads to an increased sense of mutual ownership over the project and the company as a whole. When you feel ownership over something, you want to make that thing great. Developers are creators, after all.

Spolsky is also right, because, let’s face it: if your work is building software, you can’t possibly be productive if you’re listening to someone chat about the deep philosophical implications of open-source software while munching on free M&M’s. Yes, an appreciation for the greater impact of your work is important. But so is doing your work.

Your job as a manager is to pay attention to everyone, to get inside their heads, understand how they work best, and facilitate that environment springing up in a way that seems organic. You can’t be too overbearing and mar the sense of control that your developers crave. You can’t be too laissez faire and risk people getting off-task.

So, lighten up, read some books on psychology, talk to people about what they want, observe people’s behavior to figure out what they really need to be productive, and try things out until you find that sweet spot that works for your team.

Airbrake Gem 3.1.12 with Rails 4 support.

RubtyGem312

With Rails conf currently underway and Rail 4.0 getting increasing interest, we’re excited to announce full Rails 4 (beta 1) support with our latest Airbrake gem, version 3.1.12.

Download from http://rubygems.org/gems/airbrake

 

 

Version 3.1.12 - 2013-04-29 18:48:40 +0200
===============================================================================

Arvind Kunday (1):
      Removing the .erb template handler

Hrvoje Šimić (8):
      introducing null logger for fallback
      add missing logger requirement
      being careful with silencing of rake backtrace in the airbrake:test task
      support for Rails 4.0
      start using remote XSD file when verifying XML in tests
      throw a warning for unsupported user attributes
      updating outdated step definition for current user feature
      speeding up the test by using 'runner' instead of 'server'

knapo (1):
      Fix Airbrake::Sender#log to log messages when logger is not passed to options.

Found a bug? Want a feature? Create an issue on Github.

applicake-hack

Software Development and Pirates

This is a guest post from Nick Urban. Full bio at the bottom.

Guiding Stars

One of the great discoveries of modern business is that even small decisions can be made empirically, by means of simple experiments.

The act of starting a business is hence transformed from divination to navigation. Diviners who found water by ‘signs’ may or may not have been frauds, but their methods were certainly not as robust as the compass and sextant. Similarly, web designers who change their sites based on gut feelings will not be as effective as those who use analytics to measure user behavior, and base their decisions on that.

The recognition of the importance of empiricism in business is the basis for powerful practices such as A/B testing, and at a broader level for the whole philosophy of “ship early, ship often”. Both are ways of incorporating feedback into the decisionmaking process as soon and as frequently as possible. In deference to navigation, I call these techniques “guiding stars”.

Warning Bells

Where guiding stars tell us if we’re going the right way, warning bells help us avoid dangerous obstacles. We say “due west” or “rename column” and they cry “here be dragons!”.

As developers, our most comprehensive warning bell is integration testing. It tells us whether our program works, almost as if someone were actually using it. If we’re very clever, we might use integration testing as part of a Behavior-Driven-Development process, which would help ensure not only that we arrive safely, but that we arrive at the right port. Integration testing encourages us to think at the level of use cases, and hence doubles as a guiding star.

Unit testing, likewise, is mandatory for any sailor worth his salt. Unit testing checks the implementation details of a project and the edge cases that integration tests doesn’t reach. It makes us look at our interfaces as skeptical buyers rather than proud parents. From that perspective, it’s obvious where we tied a square knot and where a granny.

Fire Alarms

It’s a sad fact, but the dragons of our lives do not always stay within the bounds marked for them on our painstakingly-drawn maps. Luckily, most “dragons” are merely little drakes or pitiful whelps of a missing semicolon. The worst they do is cough sparks and rattle the china. Yet if we don’t notice them, they may still fire the ship. That makes the job of fire-watch an important one. Luckily for us, some clever tinkerers have invented a mechanical parrot that squawks when it smells smoke. It’s called an “exception tracker”, and our hosts today are the purveyors of some of these fine talkers. I’ve used Exceptional‘s tracker for several months, and their alerts have saved me on many occasions.

Unforeseen Treasures

Once you’ve followed your guiding stars, heeded the warning bells, and fed your fire alarm, you’ll be in pretty good shape. You’ll know where you’re going and how to stay out of trouble. But if you’re still not sold, here’s a benefit you may not have thought about.

From time to time, when you’re sailing the ocean of entrepreneurship, you’ll get wind of a chest of doubloons buried in some nearby sandbar. All you have to do is sail over and dig it up. But what if there are pirates? What if you can’t make it to port? Or worse, what if there were tranquil seas and clear sailing, but you acted the coward and crept home when you could have been playing the Count of Monte Cristo?

If the hatches are battened and your parrot’s been freshly oiled, then you’ll likely have the confidence to seize that gold. And if there’s trouble, you’ll be in good shape to handle it. As Seneca says, luck is the crossroads of preparation, opportunity, and havin’ some powder in yer pistol.

Build quality, feel confident, act boldly.

That may not be the motto of the Queen’s Navy, but it works for me.

 

Nick Urban is Chief Engineer at Bespoke Post, a philosope, and a baritoneFind him online at nickurban.com

 

 

 

Airbrake to join the Rackspace Family

As part of todays Exceptional acquisitions, we’re proud to announce our Airbrake will be joining the Rackspace family along with Exceptional.

ballons

Exceptional could not be more excited to announce that we are joining Rackspace! Our team has tripled in size in the past year to keep up with demand for Exceptional’s products. But with over 30,000 active customers, we were surfing Nazaré in barrel. Rackspace lives, breathes, eats and sleeps doesn’t sleep when it comes to delivering Fanatical Support–and leveraging our combined strengths is a win for us, Rackspace and you, our customers.

We’ve had the challenge–and also the good fortune–to be living in the crosshairs of many technology shifts:

Our team has tackled big data and open cloud for the past few years. As we scaled we’ve tried every programming language, database and host under the sun, but there has always been one host that has truly stood out: Rackspace, with its Fanatical Support and robust open cloud. Exceptional is delighted to announce its range of products has been acquired by Rackspace. Our products and our team are ecstatic be joining the Rackspace family. This acquisition gives us the chance to put rocket fuel behind our suite of developer tools.

Exceptional has constantly focused on building tools for modern developers, with two error tracking products https://airbrake.io http://exceptional.io, uptime monitoring http://ranger.io and the operation of a database as a service product, RedisToGo http://redistogo.com .

This post continues on the exceptional blog…
Continue reading

How to Use Airbrake with your WordPress Site

Using Airbrake on your WordPress site just got a whole lot easier. Where once you had to download third-party zip files from Github and manually upload them to your server root, now it’s as simple as installing a new plugin. You don’t need to know any code or even what an API key is to use it.

Step #1: Mosey on over to Airbrake and click on the friendly orange “Start Your Free Trial” button to get going. Choose the plan that fits your needs, and fill out a simple form to create your account.

AB airbrake.io front page

 

Step #2: When you log in for the first time, Airbrake will prompt you to create your first project. You can put in all your Github information if you want, but it’s not necessary for now.

AB new project

 

Step #3: Go to your WordPress Dashboard and go to Plugins and Add New. Search for Airbrake– the one and only! Or just check out the page here. Install it, activate it, and you should see a friendly, simple control panel that looks like this:

airbrake plugin control panel

Step #4: Now we need your API key. Go back to your Airbrake account and make sure you’ve clicked on the project you’re currently working with. Your API key will be easy to find, in the upper left-hand corner. Fill in the API key in the WordPress plugin, and make sure you’ve changed the Status from “Disabled” to “Enabled” (this is crucial). Save Changes.

AB homepage sidebar

Step #5: Now go back to your Airbrake account again, and click on Simulate Exception–it’s right underneath your API key in the sidebar.

Not Even a Step: You’re done. Sit back and wait for your first exception notification to pop up in your inbox. Don’t get too comfy, though! It’s gonna show up in a matter of nanoseconds.

If you want to get into the nitty gritty about using Resque, ignoring certain exceptions, etc., all the code is up on Github.

The Definitive Collection of XKCD Comics for Programmers

If you’re a geek (or a nerd) worth your salt, you’re definitely a fan of xkcd. The only legitimate reason for not liking it is jealousy that you can never be as clever as Randall Munroe, the genius behind xkcd. And even then, you know you secretly love it. And so, I present, for your reading enjoyment, the definitive collection of the best xkcd comics for programmers.

It demonstrates how programming can be useful in everyday situations:

RTL

 

And about how programming can cause problems in everyday life:

Swiftkey

 

It puts our work into a larger context:

Skynet

And plays anthropologist, exploring the complex issue of identity-formation in the culture of the programmer:

Real Programmers

 

And it tackles what we here at Airbrake care about the most:

error_code

 

 

And, the best classic xkcd programming comic of all time:

compiling

Here’s the rest of the catalog, in no particular order:

x11     workflow     wisdom_of_the_ancients     virus_venn_diagram (2)

turtles     tech_support     TCMP     tags

tar     supported_features     sharing     server_problem

rtfm     s_keyboard_leopard     permanence     old_timers

password_strength     perl_problems     manual_override     Microsoft

hotels     geohashing     identity     iso_8601

mac_pc     game_ais     crowdsourcing     contextbot

 

 

binary_heart