Rails 3.2.13 was released yesterday, containing some important security fixes, but it is causing headaches for many developers.

After some recent well documented rails vulnerabilities, many developers are making sure to upgrade their rails versions as soon as security patches are released, but you might consider holding off until 3.2.14 comes out, or risk running into the following performance regressions and bugs:

Broken action_missing

The action_missing function, which is a Rails controller's equivalent of ruby's method_missing was completely broken in 3.2.13. See this issue and the attached pull request for details:

https://github.com/rails/rails/issues/9799

Broken ActiveRecord Scopes

This issue has been well documented, since GitHub ran into an embarrassing bug caused by the scope behavior change. Basically, certain scoped database query parameters can be overwritten by later chaining operations in certain situations.

https://github.com/rails/rails/issues/9813

Performance Regressions

There are performance regressions in 3.2.13 for both view loading and asset loading. Rails 3.2.13 changed the way assets paths are resolved, handing that task to Sprockets instead of resolving internally, which seems to be the cause of the performance issues.

@quamen @charliesome confirmed here as well, got like 5 second page loads going on

— Charlie Somerville (@charliesome) March 20, 2013

For more details, check out the following GitHub issues: https://github.com/rails/rails/issues/9803, https://github.com/rails/rails/pull/9820

More ActiveRecord Regressions

There are a bunch more ActiveRecord issues relating to database encoding and relations, so make sure to check out the full list of open rails issues to check which 3.2.13 regressions will affect your apps.

What's Different About This Release?

It looks like there were a total of 296 commits that went into Rails 3.2.13, so it is easy to see how multiple issues crept into this release. Compare that to the 7 commits that made up 3.2.11.

A "security fixes only" release would have gone a long way to avoiding the complexity that caused these issues to slip in.

How Can I Help?

Thanks to the Rails team for staying on top of recent security issues and being proactive in fixing them. If you'd like to help, there are a few things you can do:

• Check out the Rails Issues on GitHub and submit additional diagnostic information or pull requests.

• Follow the Rails Blog and help out by testing release candidate builds of rails in your staging or production environments.

Today, by popular demand, we are pleased to announce Asana integration for Bugsnag! If you enable Asana in your Bugsnag dashboard, we can automatically create Asana tasks when an error is detected in your applications.

Asana is a great way to manage your projects and other tasks, so we've made it super easy for your app's errors to be part of your existing workflows.

Thanks to all the Bugsnag customers who requested this Asana integration, enjoy!

We've just released a feature that we know many of you have been waiting for, you can now search for errors stored in Bugsnag.

From your project dashboard you can search for errors based on where they occurred, the type of error and the error message.

We are planning on adding additional data to our search, so if there is anything in particular you would love to be able to search for, get in touch and we'll see what we can do.

There are a ton more awesome Bugsnag features in the pipeline, keep an eye on our blog and follow @bugsnag on Twitter for updates.

Today we are pleased to announce the release of the official Bugsnag PHP Notifier. The Bugsnag PHP Notifier gives you instant notification of exceptions thrown by your PHP apps.

Automatic Error Handling

The Bugsnag PHP Notifier comes with full support for automatic error and exception handling, since we provide handler functions that can be passed directly to PHP's built-in set_exception_handler and set_error_handler functions.

// Initialize Bugsnag with your API key
Bugsnag::register("your-api-key-here");

// Attach the automatic error handlers
set_error_handler("Bugsnag::errorHandler");
set_exception_handler("Bugsnag::exceptionHandler");

See the Bugsnag PHP Notifier docs for more information about the full capabilities of the notifier.

Manual Error Handling

For user-defined errors, you can also notify Bugsnag manually using the Bugsnag::notifyError or Bugsnag::notifyException functions.

// Notify Bugsnag manually of an error
Bugsnag::notifyError("PaymentFailedError", "The payment failed due to missing name");

// Notify Bugsnag manually of an exception
Bugsnag::notifyException(new Exception("Something bad happened"));

You can find more details about this and other functions in the Bugsnag PHP Notifier docs.

Send Application-Specific Data With Errors

Bugsnag already collects and displays as much information as possible to help you debug your exceptions, including HTTP params, app environment and number of unique users affected, but as a developer you’ll know exactly which pieces of application data are most important to you.

To send custom data from your PHP apps, you can use setMetaDataFunction, for example:

// Tell Bugsnag to use a metadata function
Bugsnag::setMetaDataFunction("bugsnag_metadata");

// Define the bugsnag metadata function
function bugsnag_metadata() {
    return array(
        "user" => array(
            "name"  => "Bob Hoskins",
            "email" => "bob@example.com",
            "role"  => "Super Mario"
        )
    );
}

Adding custom data will give you more insights into your exceptions, which should ultimately allow you to resolve them faster.

Thanks

We'd also like to say a big thanks to Taylor Otwell for making his unofficial PHP notifier available before this release!

We've just released a new feature on Bugsnag that allows you to comment on errors inside your dashboard. Commenting allows you to collaborate with your team and solve errors faster.

There are a ton more awesome Bugsnag features in the pipeline, keep an eye on our blog and follow @bugsnag on Twitter for updates.

In our latest Bugsnag Notifier for Ruby release, we've added much better support for sending custom data with your exceptions. You can now provide callbacks to add any custom data to every exception that happens in your app.

Exceptions are always going to happen in your apps. It is important that you know when and how your exceptions happen so you can fix them and make sure your happy customers stay happy.

Why send custom data with exceptions?

Sometimes the exception class and stacktrace is not enough.

Bugsnag already collects and displays as much information as possible to help you debug your exceptions, including HTTP params, app environment and number of unique users affected, but as a developer you'll know exactly which pieces of application data are most important to you.

By sending custom data with each exception, you'll immediately be able to answer the most important questions, for example:

• Was the person signed in?
• Is there something special about the user, are they a paying customer?
• What company does the user work for?
• What is the best way to reproduce this error?
• How can I contact the person affected by this error?

How to send custom data from your Rails apps

In any rails controller you can define a before_bugsnag_notify callback, which allows you to attach additional data to the exception notification and have it displayed in a tab on your Bugsnag dashboard.

class MyController < ApplicationController
  # Attach the callback
  before_bugsnag_notify :add_user_info_to_bugsnag

  # controller code...

  private
  def add_user_info_to_bugsnag(notification)
    # Add some app-specific data which will be displayed on a custom
    # "User Info" tab on each error page on bugsnag.com
    notification.add_tab("User Info", {
      :name => current_user.name
    })
  end
end

How to send custom data from other ruby apps

If you aren't using Rails, you can still define callbacks, but you'll need to explicitly clear the callbacks before your next request or whenever appropriate:

# Set a before notify callback
Bugsnag.before_notify_callbacks << lambda {|notification|
  notification.add_tab("User Info", {
    :name => current_user.name
  })
}

# app code...

# Clear the callbacks
Bugsnag.before_notify_callbacks.clear

Send data from your libraries using Bugsnag middleware

Callbacks are implemented internally in the ruby library using our own middleware stack. Our middleware stack works in a similar way to Rack middleware, allowing you to chain together code which runs before and after Bugsnag is notified about an exception.

You can write your own middleware class by following the following pattern:

class MyMiddleware
  def initialize(bugsnag)
    @bugsnag = bugsnag
  end

  def call(notification)
    # Do some "before notify" work

    @bugsnag.call(notification)

    # Do some "after notify work"
  end
end

You can then add your middleware to the stack by calling:

Bugsnag.configure do |config|
  config.middleware.use MyMiddleware
end

To view the current Bugsnag middleware stack for your app, you can run rake bugsnag:middleware:

> rake bugsnag:middleware
Bugsnag::Middleware::Callbacks
Bugsnag::Middleware::RackRequest
Bugsnag::Middleware::Rails3Request

Adding custom data will give you more insights into your exceptions, which should ultimately allow you to resolve them faster.

We wanted a pricing plan that was fair and transparent, so rather than having a complex bracketed pricing plan, we’ve set it up so that you'll pay only for what you use. We've also created a free plan, so that smaller developers can enjoy Bugsnag.

New Plans

Full Plan

$29/month, includes 25,000 exceptions, 25¢ per 1,000 additional exceptions. This plan includes all of our premium features, unlimited users and unlimited projects.

Free Plan

Includes 2,000 exceptions/month, one user and unlimited projects. Premium features such as chatroom notification, ticket creation, error resolving and deploy tracking are not included.

More detailed information on our plans is available on our pricing page.

At Bugsnag we use SPDY on our production rails application. For our users who run modern browsers, this can make the site feel much faster and more responsive. Want to get SPDY working on your production rails app? Read on.

What is SPDY?

SPDY is a modern networking protocol for the web which has been designed from the ground up to reduce page load times and latency, as well as improve security. The SPDY protocol was developed by Google, and is a candidate to be used as the basis for HTTP/2.0.

Is SPDY Ready for Production Use?

Major sites, including Google and Twitter are using SPDY right now, and Facebook are currently in the process of implementing SPDY.

The latest stable versions of modern web browsers, including Chrome and Firefox, already support SPDY. In fact, if you are using Google Chrome and you head to a SPDY-enabled website, your browser will automatically use SPDY, falling back to HTTP if SPDY is not supported.

You can track which browsers currently support SPDY, but with the transparent fallback to HTTP, you can use SPDY right now. Think of it as progressive protocol enhancement.

Short answer: YES.

Adding SPDY Support to Your Rails App (Nginx+Passenger)

I'm going to discuss Bugsnag's production setup, as it is one of the most common production configurations for rails apps, and it is very easy to add SPDY support.

Bugsnag uses Nginx with the Phusion Passenger module to serve our rails app. Since Passenger is implemented as an Nginx module, by adding SPDY support to Nginx, you will automatically get SPDY support on your rails apps.

To add SPDY support to Nginx, you'll have to apply the Nginx SPDY patch to a development version (1.3.x) of Nginx. Both the Nginx development branch and the SPDY patch are considered experimental, but we have been using them both in production for months with no issues.

The following script automatically builds Nginx with Passenger and SPDY support:

Configuring Nginx to Use SPDY

Most browsers with SPDY support require that SPDY uses SSL. If your production site is not already SSL compatible (or even SSL-only) you will first have to obtain an SSL certificate and configure Nginx to use SSL.

Setting up SSL is outside the scope of this blog post, but I recommend getting a free SSL certificate from StartSSL and following Simon Westphahl's excellent Setting up HTTPS with Nginx and StartSSL guide. You can also check out the official Nginx SSL documentation.

Once you have got your app working with SSL/HTTPS, enabling SPDY is as simple as adding the spdy configuration flag to your Nginx server directive:

For more details about Nginx SPDY configuration, check out the Nginx SPDY README.

Testing & Benchmarking SPDY on Your Site

Once you have installed Nginx+Passenger with SPDY support, and updated your Nginx config files, you should be ready to (re)start Nginx and test that SPDY is working.

For an instant yes/no answer, I recommend installing the Chrome spdy indicator extension which will show a green lightning bolt in your address bar if SPDY is active on the current page:

You can also type about:net-internals into Chrome's address bar to see more detailed information about active SPDY sessions.

If you would like to benchmark your shiny new SPDY setup, check out the Chrome benchmarking extension or Google's Speed Tracer.

Monitoring SPDY in Production

Since SPDY-compatible browsers should automatically fall back to HTTPS when SPDY is not available, you can continue to use your current production site monitoring systems such as Monit or Pingdom.

If you would like to have SPDY specific monitoring, consider writing a Monit monitoring script which uses the spdycat tool from spdylay. Pingdom does not currently support monitoring the SPDY protocol.

SPDY on Rails Without Nginx

If you are using Apache, check out mod_spdy. It doesn't look like Unicorn supports SPDY right now, but it might be possible to use a SPDY proxy.

Conclusion

• SPDY is ready to use right now
• It is easy to get your rails apps using spdy with nginx + spdy patch + passenger
• Falls back to plain HTTP, progressive protocol enhancement

Today we are pleased to announce the release of the official Bugsnag Python Notifier. The Bugsnag Python Notifier gives you instant notification of exceptions thrown by your Django or Python app. The notifier will automatically notify your Bugsnag project of any uncaught exceptions.

Django Support

The Bugsnag Python Notifier comes with full support for Django applications. Using the Bugsnag Django middleware, you can see the full request, session and Django environment that was affected by the exception. Integrating the notifier into your Django application takes less than five minutes, so you can quickly start to realize the benefits of using Bugsnag to track your errors.

Other Python Frameworks

We are planning to add deeper support for other major Python frameworks in the near future, including Tornado and wsgi middleware so that we can bring official Bugsnag support to more applications.

For the latest updates, you should follow us on twitter.

Over the past couple of weeks we've been busy working on two great new features which we think you'll love, error resolving and deploy tracking.

Marking Errors as Resolved

Last week we rolled out support for marking your errors as "resolved". This helps you to focus only on current errors and gives you a warm fuzzy feeling when you manage to resolve every error :)

You can resolve errors by clicking the resolve button on each error page, or you can batch resolve errors using the checkboxes on error list pages.

Errors marked as resolved will be automatically unresolved when a new exception of the same type occurs in a new version.

Deploy Tracking

We've also just rolled out support for tracking deploys in your applications! By sending the source revision or application version to Bugsnag when you deploy a new version of your app, you'll be able to see which deploy each error was introduced in, and even auto-resolve all unresolved errors each time you deploy.

So you can notify us about your deploys, we've created a simple Deploy Tracking API that you can call from your deploy scripts.

We've also updated the Bugsnag Ruby Notifier to contain rake and capistrano tasks allowing you to automatically notify us of deploys.

To automatically mark all production errors as resolved after you notify us of a deploy, simply enable the checkbox under the "Deploy Tracking Settings" section in your Bugsnag project's settings page.

Over the next few weeks, we will be adding more ways to see how your deploys relate to exceptions in your applications, so you can focus on finding and fixing your errors as quick as possible.

Today we are excited to announce the Beta of Bugsnag! Bugsnag captures errors in real-time from your web, mobile and desktop applications, helping you to understand and resolve them as fast as possible.

Get notified about all errors, even in production

As an app developer, one of your most important tasks is making sure your users have a good experience when using your product. Tracking errors and exceptions that occur in your application will help you to eliminate crashes and other bad experiences, ensuring your users can focus on enjoying your app.

Bugsnag's error notifier libraries run safely and silently in your app, even in production, meaning you will be notified whenever a user encounters an error or crash.

Open source plugin architecture

We have developed open-source libraries for most common languages and frameworks that you can include in your applications to automatically capture and report any errors or exceptions, meaning you’ll know when every single error happens in production.

Bugsnag can notify you by email when an error occurs, send a notification into your chat room or even automatically create a ticket using our open-source notification plugins. If we don’t support your chat room or ticketing system, you can even build your own plugin!

Intelligent grouping, at a glance indicators

Capturing errors and exceptions is only one part of the story. Bugsnag intelligently groups similar errors together, shows how many users are affected by each error and highlights errors which are new or have unusual spikes in occurrences. Using bugsnag, you can easily focus on finding and fixing the most urgent errors first.

More features, frameworks coming very soon

This is just the beginning. Stay tuned for wider support for your favorite languages and frameworks, and features to help you identify and fix errors quickly. Get in touch if you have any ideas or suggestions on how we can improve bugsnag, we’d love to hear from you. For the latest updates, you should follow us on twitter.