Another RailsConf has come and gone and everyone has gone back to their hometowns and offices. New Relic was lucky enough to have RailsConf in Portland, Oregon this year, which is our intergalactic engineering headquarters. We worked hard to make everyone who came to the conference feel welcome and get those extra opportunities to learn and interact with the Rails community.

All the Content!
Once again there was an abundance of great content at the conference, from entertaining keynotes to domain-challenging technical deep dives. We helped contribute with three separate presentations:

* Sam Goldstein and Ben Weintraub presented on the New Relic Performance Code Kata. Their slides can be found here. The goal of this Kata is to get your mind wired into performance-driven development. We’ll explore, diagnose and fix a variety of performance problems to reinforce your skills as a user of New Relic.

* Chris Kelly spoke on how many of the same principles that guide our software design can guide our software architecture. To review or learn more, see the slides.

* Andrew Bloomgarden and Julian Giuca gave a tour of our experience upgrading to Rails 3 (like changing the wheels of a bus going at 80 mph!). Slides are here.

We believe that videos of the presentations will be posted at ConFreaks, so keep an eye on this site.

With our new space in Portland, we were able to host the conference with live streaming for those who missed out on tickets for the sold-out show. Over four days, people gathered at New Relic to watch the videocast and learn and laugh together, depending on the speaker and content.

All the Parties!
No conference is complete without some great parties. And New Relic helped create some memorable events for RailsConf 2013!

The first event was on Sunday night to help the speakers of the conference prepare for the week. The second event, ‘A Night in the Ruby Sky,’ was open to all attendees — and the food and conversation carried on for hours.

Trivia Contest

We had a fun trivia contest at the after party. Here’s the trivia information and results! (Congrats to our winner, Paul Simpson from Harvest, who snagged an iPod mini.)

Q. In 2005, what did David Heinemeier Hansson create in 15 minutes, which helped kick start the popularity of Rails?
A. A blog

Q: What major feature was recently pulled from Rails 4.0?
A: The Queue API

Q. What version of Rails first included support for Rack?
A. Version 2.2 (We also accepted Version 2.3)

Q. What Ruby web framework joined forces with Rails 2 to create Rails 3?
A. Merb

Q. How many Ruby core classes were monkey-patched by Rails’ first public commit?
A. One: cattr_{reader,writer,accessor} are added to Class

All the New and Exciting!
Besides the parties, we also celebrated by publishing six blog posts that highlighted what’s new and exciting in the world of New Relic’s Ruby support. If you have not yet read the series, here’s the complete list:

* Cross Application Tracing
* Thread Profiling
* Living on the Edge with Rails 4 & Ruby 2
* Thread Safe APIs & Sidekiq Support for Your Threading
* Security Banners (For If You Forgot to Apply the Latest CVE Patch)
* Debugging Stuck Ruby Processes – What to do before you kill-9

Since RailsConf, we’ve released support for Sequel. The support includes capturing SQL calls and model operations in transaction traces, and recording slow SQL calls. See these docs for full details.

You can still try New Relic Pro free for 30 days. For more information, see our RailsConf page. Here is to another great year ahead. See you in Chicago for RailsConf 2014!

The post RailsConf 2013 Review appeared first on New Relic blog.

So, how do we test code that’s heavily dependent on other components? How do we validate different combinations of frameworks that can occur in the wild? Read on for the nitty gritty of testing the Ruby agent in multiple environments.

The Uncertainties of Life (and Testing)
Before coming to New Relic, I was an app developer. At that time I never realized how much simpler life was when you could choose 1) what dependencies to take, 2) how the production environment was configured and 3) the fundamentals, like language versions. Unfortunately, library authors don’t get these certainties.

The richness of the gem ecosystem keeps the Ruby agent team on our toes. We support at least six different Ruby versions (depending on exactly how you count), eight versions of Rails, and a pile of other frameworks. If you ever need to be sure your code runs against Rails 2.0 and Ruby 1.8.6, I’ve got the test suite for you!

At the highest level, we follow a standard unit / functions (or integration) test breakdown. Let’s take a look at the unit tests first.

Unit Testing
Unit tests are the front line of our testing. They run quickly (about 10 seconds locally for the full suite of > 1000 tests), with the lightest dependencies. We execute them across the broadest number of combinations of Ruby and Rails versions.

Historically Rails has been a big focus for the agent, so the unit tests run in the context of a Rails application. While most of the agent’s unit tests could run without any external dependencies, we’ve encountered many subtle bugs from interesting intersections between Rails (I’m looking at you, ActiveSupport) and the various flavors of Ruby. Running the unit tests under Rails helps flush out these odd interactions. For example, we found one problem with subtly incompatible versions of the to_json method floating around during the 2.x versions of ActiveSupport.

Which version of Rails do we run against? Well, if you download the agent source and run the unit tests, you’ll see this:

♥♥♥~/source/newrelic/ruby_agent [1.9.3] [release]:rake test

/Users/jclark/.rbenv/versions/1.9.3-p374/bin/ruby -I"lib:/Users/jclark/source/newrelic/ruby_agent/test:/Users/jclark/source/newrelic/ruby_agent/lib" -I"/Users/jclark/.rbenv/versions/1.9.3-p374/lib/ruby/gems/1.9.1/gems/rake-10.0.3/lib" "/Users/jclark/.rbenv/versions/1.9.3-p374/lib/ruby/gems/1.9.1/gems/rake-10.0.3/lib/rake/rake_test_loader.rb" "/Users/jclark/source/newrelic/ruby_agent/test/new_relic/**/*_test.rb"

Running tests in standalone mode.
Run options:

# Running tests:

...more dots...

Finished tests in 8.206038s, 129.6606 tests/s, 338.4094 assertions/s.

1064 tests, 2777 assertions, 0 failures, 0 errors, 0 skips

The line ‘Running tests in standalone mode’ hints at what’s going on. In ‘standalone mode’ we construct a tiny Rails app in the agent that – by default – runs a Rails 3.2 app.

But what about all those other versions of Rails? That’s where rpm_test_app comes in. It’s a full, separate application with branches for each flavor of Rails we support. These get stitched together with some Rake goodness to run the unit tests for newrelic_rpm in rpm_test_app’s context:

Rake::TestTask.new(:newrelic) do |t|
  t.libs << "#{agent_home}/test"
  t.libs << "#{agent_home}/lib"
  t.pattern = "#{agent_home}/test/new_relic/**/*_test.rb"
  t.verbose = true
end

With `rake test:newrelic`, our CI system can run the gambit of Rails and Ruby versions. Jenkins configurations let us dictate which combinations make sense given that, for instance, you can’t run Rails 3.x and greater on Ruby 1.8.6.

Not All About Rails
That’s all good, but there’s much more to Ruby than just Rails. With the rich variety of frameworks to support, we needed an approach to mix and match dependencies.

This need led to our functional/integration testing layer, affectionately referred to as the ‘Pangalactic Multiverse’ tests.

At heart, Multiverse is a series of suites, each representing a collection of dependencies. We have one for Sinatra, one for Resque and one for ActiveRecord outside of Rails. The exact versions are specified by an Envfile:

suite_condition("Sinatra not compatible with 1.8.6") do
  RUBY_VERSION != '1.8.6'
end

gemfile <<-RB
  gem 'sinatra', '1.3.3'
  gem 'rack-test', :require => 'rack/test'
RB

gemfile <<-RB
  gem 'sinatra', '1.2.8'
  gem 'rack-test', :require => 'rack/test'
RB

Multiverse reads the Envfile and generates a Gemfile for each call to `gemfile`. It will bundle install those dependencies and run the suite’s tests in a separate child process.

Unlike the unit tests that focus on individual classes, Multiverse tests run a full agent cycle – starting up, monitoring work, shutting down and transmitting data. They even run a fake service endpoint so data flows over HTTP, keeping as close to the runtime reality of the agent as possible.

With the additional environment spin-up and running our full stack, Multiverse tests are slower, but vital for coverage. We can easily write targeted automated tests against multiple different versions of individual frameworks, and validate that the agent works with new releases as they come out.

The Envfile lets each suite run multiple sets of dependent versions. And our CI system takes care of running Multiverse against various Ruby versions, too. So many combinations!

The Hard Part
Testing always presents unique challenges. And a library like the Ruby agent introduces its own set of fun twists.

It’s About the Environment
A lot of the work on our testing system has gone into getting environment setup scripted, both locally and in CI. We’re currently using a solution with Vagrant and Puppet that lets us spin up consistently formatted build boxes.

Leaky Test State
Testing needs to mimic reality to find some types of problems. This presents difficulties for the Ruby agent.

In production, the agent starts once per process. However, in a test run, the agent might restart hundreds of times. We’ve had to take care to avoid a leaking state between tests. Otherwise we could be faced with tests that work fine in isolation, but break when run in the suite. However, an upshot of this pain is the test_bisect gem my coworker Jon wrote. If you’ve ever suffered from leaky tests you should check it out.

Timeliness Counts
It’s also hard to write good tests for monitoring time and the underlying system. It’s much easier to write brittle timing tests that run fine locally, but break when deployed to the slower VM-based CI system under heavy load. Given how much of the Ruby agent’s functionality is about accurate timing, this is a continuing pain point we wrestle with in testing. In general, we’ve moved toward stubbing time values in unit tests and applying thresholds or percentage comparisons rather than strict timeframes whenever possible in functional tests.

Need for Speed
Running Multiverse is relatively slow. So, we’ve worked hard to prune that time. Two major approaches were: a) keeping suites coarse grained and b) applying local bundling. Both of these hinged off the setup being the slowest part of Multiverse.

In the first case, our early experience saw new Multiverse suites cropping up per feature. Often these would just copy an existing environment with minimal tweaks. Merging those suites along the lines of their gem dependencies gave a huge performance bump. Getting the right granularity for grouping tests was a big win.

Second, the Multiverse setup tries to bundle without contacting RubyGems, but re-runs a full bundle if that doesn’t work. Less network chatter = faster setup = faster tests.

Conclusion
That’s how we deal with testing multiple frameworks and Ruby environments on the Ruby agent team. It’s given us a nice balance of having our fast unit tests against the most common cases, with easy access to full-stack Multiverse tests to cover other configurations.

Are you a gem author who tests against different frameworks and Ruby implementations? Got a trick (or two) that’s helped you keep your dependency testing under control? Tell us about your experiences in the comments below.

The post Test All the Combinations! appeared first on New Relic blog.

Here’s an example of Green Code in Ruby:

class Customer < ActiveRecord::Base
  has_many :orders
end

In this code snippet, has_many is ActiveRecord’s Red Code. There’s a lot of machinery backing the has_many code that the Green Code doesn’t need to concern itself with.

You’ll often find Red Code in frameworks, APIs and DSLs. There are numerous examples including Gradle, Geb, jQuery, Mocha, Rake, Rails, RSpec, and Spock. And depending on the language, Red Code typically makes heavy use of some of the more powerful language features (e.g. meta programming in Ruby, byte code manipulation in Java).

However, the Red Code / Green Code concept isn’t a new one. In his book On Lisp, Paul Graham referred to this as Bottom-Up Programming. Graham encouraged his readers to increase the expressiveness of the language (Red Code) in order to make their code shorter and more readable (Green Code).

Depending on the task you’re trying to solve, you’ll probably want to be careful about writing any Red Code as it is apt to violate the principle of least surprise. For example, in Java you may come up with a clever solution using reflection. But reflection is unusual enough that it will likely trip up unsuspecting navigators of the code. As a good rule of thumb, candidates for Red Code are areas of your code that would make good open source libraries. To be worthwhile, the benefit of the Red Code has to outweigh the cost of discovering the unusual behavior, learning its proper usage and maintaining the more complex solution.

To illustrate this, take a look at the code behind Backbone.js. It’s very much Green Code and there are no big surprises. Then compare it with Angular, where there’s clearly Red Code under the hood. When you use the frameworks,  you’ll notice the difference, too. Backbone.js is easier to get into, but you need to write a fair amount of boiler place code. On the other hand, Angular has ‘magic’ conventions that take time to get use to. But once you’ve adjusted to how it work, you’ll benefit from the reduced boiler plate code.

Do you have experiences working with or writing Red Code and Green Code? Tell us about your experiences in the comments below.

The post Red Code, Green Code appeared first on New Relic blog.

RailsConf 2013 has begun! To celebrate, we’re publishing a series of blog posts that highlight what’s new and exciting in the world of New Relic’s Ruby support. Don’t forget to check out the entire series so far: Cross Application Tracing, Thread Profiling, Living on the Edge with Rails 4 & Ruby 2, Thread Safe APIs & Sidekiq Support for Your Threading, and Security Banners (For If You Forgot to Apply the Latest CVE Patch).

If you’ve spent enough time working with a production system (or even just a continuous integration server), you’ve surely encountered a Ruby process that was ‘stuck.’  You know the type – not crashing, but not making any real progress either. And giving you no obvious indication of what it was doing.

When finding a stuck process, your primary goal usually is to just get the wheels of progress turning again. And the quickest path to that goal is usually to `kill -9` the stuck process and restart it.

But I want to you to make your future self a promise. The next time this happens, don’t just kill that stuck process and move on. Dig in and figure out what’s really going on. You might just discover the root cause of your problem, hone your debugging techniques or discover a clue that helps you fix that tricky bug in your favorite open source project that no one has been able to pin down.

Since encountering a stuck process (especially in production) is often stressful, I find it helps to think about the debugging steps you plan to take ahead of time. Create a ‘checklist’ of things to run through so you don’t forget anything or skip any steps. Failing to capture enough information to reproduce a bug usually means you’ll hit it again. So make sure you seize the opportunity when it’s available.

Here are the steps I follow when debugging a stuck Ruby process:

Who Said What?
First, figure out exactly what process is stuck. This sounds trivial, but it’s especially important for systems like Unicorn, Passenger, Resque, etc. where the system is composed of multiple processes that have different roles (often a single master process plus a number of workers).

Identifying exactly which process is stuck is important in order to get a full picture of the behavior of the system as a whole. The trusty ps utility is usually my first stop here — a quick `ps aux | grep <process name>`.

I like to keep a transcript of the exact commands I’ve run, along with their output. And the ps aux output is usually the first thing that goes into that transcript.

Tools like htop and pstree can also be useful here. They give you a visual tree of the relationship between the stuck process, its sibling and its parent process (e.g. a Unicorn master and its workers).

Grab Any Logs that are Available
Again this may seem obvious, but the goal of the checklist is to remind you of everything you need to track. This will give you the best possible chance of debugging the problem offline. Before getting started, consider these questions:

* Where is STDOUT of the stuck process being sent?

* Where is STDERR of the stuck process being sent?

* Are there any other log files created by the stuck process? Check the command line and config file used for the process. Did either specify a log path?

* Are there any other log files created by processes related to the stuck process?

Other Non-Invasive Basics
Try gathering the following before you move into the more invasive actions:

* Grab the list of open files and sockets from the process using lsof -p <PID>

* If you’re on Linux, poke around in /proc/<PID> and consider gathering:

* cmdline contains the command line that was used to launch the process

* cwd is a link to the current working directory of the process

* environ is a list of environment variables set for the process

Check the CPU Usage of the Stuck Process
There are two basic flavors of hangs: static and dynamic. (Note: This is my own terminology, but I think it’s a useful taxonomy.) In a static hang, the threads of the stuck process are stuck in the same exact state for an extended period of time. Examples include traditional deadlocks and processes blocked for extended periods in system calls (often things like `read`, `select`, etc.). In a dynamic hang, the threads of the stuck process are changing state, but are caught in some kind of loop that prevents them from making progress (this is sometimes called a ‘livelock’).

The techniques used to debug the two types of hangs are different. So it’s useful to be able to differentiate between them in the wild. A quick heuristic for doing this is to check the CPU usage of the stuck process. Static hangs will generally result in processes with no CPU usage, whereas dynamic hangs will result in processes with non-zero CPU usage (often very high, if the process is stuck in a tight loop).

There are a variety of tools you can use to do this, but a quick look at `top` or `ps -o cpu <pid>` is often enough.

Static Hangs
For static hangs where the stuck process demonstrates no CPU usage, gather information on the backtraces of all threads in the stuck process. This is often the most important data. Since the threads aren’t changing state, a single snapshot of thread backtraces is usually sufficient.

There are a variety of different tools for accomplishing this goal, depending on the platform you’re running on and the Ruby implementation you’re using, but I’m going to focus on what is perhaps the most common case: MRI on a Linux host.

`gdb` is a time-tested and widely available tool that can be used to interrogate a running process on a variety of UNIX-ish platforms. You can attach to a running process with gdb by using the -p option, like this:

```
gdb -p
```

Once gdb has successfully attached to the target process, it will drop you at a prompt. The very first thing you should do here is to gather C-level backtraces for all threads of the stuck process, like this:

```
(gdb) t a a bt
```

This is short for `thread apply all backtrace`. Copy this output and save it to your transcript file, even if it’s not immediately informative.

Sometimes C-level backtraces are all you need in order to debug a hang. In other cases though, you really need a Ruby-level backtrace to see what’s going on. Luckily, gdb can help you generate those, too.

Getting a Ruby Backtrace with gdb
Getting a Ruby backtrace out of gdb involves interacting with the Ruby interpreter in the running process that you’ve attached to. And to get that, the interpreter needs to be in a semi-working state.  If the root cause of the issue is a Ruby bug, the process may be stuck in such a way that it isn’t possible to get the backtrace at all.

That said, it’s always worth trying. Here’s the technique I use:

Most mechanisms for dumping Ruby backtraces will output them to stdout or stderr. It’s fine if you know where the stdout and stderr for your process is going, and you have access to it. If not, first you’ll need to redirect the output streams to an accessible location.

To do this, we rely on POSIX conventions and some trickery. stdout and stderr are file descriptors 1 and 2 on POSIX-compliant systems. We want to close these file descriptors, and reopen them attached to files that we can actually read from. Closing is easy:

```
(gdb) call (void) close(1)
(gdb) call (void) close(2)
```

The call command tells gdb to invoke close from within the target process. Next, we need to re-associate file descriptors 1 and 2 with a file we can actually read from. We could use a file on the filesystem, but it’s even more convenient to see the output directly in gdb. To do that, we want to figure out the device file corresponding to our current TTY and open it twice. Since file descriptors are assigned sequentially, descriptors 1 and 2 will end up being re-associated with our TTY device. Here’s how this looks:

```
(gdb) shell tty
/dev/pts/0
(gdb) call (int) open("/dev/pts/0", 2, 0)
$1 = 1
(gdb) call (int) open("/dev/pts/0", 2, 0)
$2 = 2
```

Now, any output generated by the target process will be echoed directly to our console so we can see it in our gdb session.

Finally, we need to get the Ruby interpreter in the target process to spit out a backtrace. There are many ways to do this. But the easiest way is just to use gdb to call the rb_backtrace() function from the Ruby interpreter directly:

```
(gdb) call (void)rb_backtrace()
```

With luck, you’ll see a Ruby backtrace dumped to your console.

Digging Deeper with gdb
If you know what you’re looking for in the stuck process, there’s a lot more you can do with gdb. Jon Yurek at thoughtbot has a great post on this topic that explains how you can get gdb to evaluate arbitrary Ruby code in the target process to inspect the values of Ruby variables, get backtraces for all threads and any number of other things

Dynamic Hangs
A stuck process that shows high CPU usage is likely stuck in a tight loop. This means that the exact backtraces you get out of it may vary from one sample to the next, but backtraces can still be very helpful to point you in the right direction.

If you find a stuck process with high CPU usage, it may be worth gathering backtraces 2 or 3 times to get a more representative sample. (You can use gdb’s continue command to resume the process after you’ve attached).

You can also use other tracing tools to examine the behavior of the looping process. On Linux, strace -p <pid> allows you to view the system calls being made by the process. If you’re on an OS that has dtrace available, you can use dtruss -p <PID> instead to get a similar output.

Thanks, from your Future Self
You might not always have the luxury of being able to spend time debugging a stuck process. But when you do dive in, you’ll probably be glad you did. I’ve only scratched the surface of the tools available for analyzing problems like this, but hopefully I’ve given you enough information that you’ll be comfortable doing more than just sighing, SIGKILL-ing, and waiting for your problem to reappear.

Bonus: Mac OS X
If you happen to be debugging a stuck process on Mac OS X, check out this sample utility (a handy tool that ships with OS X). It will automate the collection of multiple C-level backtraces, aggregate them together and print out a nicely formatted call tree report showing where the stuck process is spending most of its time.

At RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Debugging Stuck Ruby Processes – What to do Before You Kill -9 appeared first on New Relic blog.

RailsConf 2013 is right around the corner! And to celebrate, we’re publishing a series of blog post that highlight what’s new and exciting in the world of New Relic’s Ruby support. Don’t forget to check out the entire series so far: Cross Application Tracing, Thread Profiling, Living on the Edge with Rails 4 & Ruby 2, and Thread Safe APIs & Sidekiq Support for Your Threading.

Over the last few months there’s been a lot of traffic on the rubyonrails-security list. High profile remote code execution exploits were found in both Rails and Rack, which heightened the focus on security in the community. It’s also brought increased scrutiny from security researchers probing for more vulnerabilities. Overall this will lead to more secure versions of Rails and other frameworks. The discussions also help more people consider their own applications’ security.

However, there’s the lurking issue of unpatched applications. Lots of people have Rails apps deployed they may not realize are vulnerable. It could be that small app a consultant installed two years ago that’s been chugging away untouched since. Or maybe it’s an experiment that got uploaded to a cloud service last year before being forgotten. It’s easier than ever to lose track of applications, and depending on your configurations and infrastructure, one insecure app can impact far more than just that app’s functionality.

New Relic’s Ruby agent has always reported the gems active in the application’s environment. That information has been useful for debugging and guiding us toward other libraries to instrument.

Brand new in time for RailsConf 2013 we’re taking advantage of that information to notify you of vulnerable versions of Rails and Rack. For Rails we check against versions 2.3.x and 3.x. Rack gets checked across versions 1.1.X through 1.5.X.

When we find a vulnerable version of these gems, you’ll see a banner in the New Relic UI pointing to the application and problematic gems. Additional links to the relevant development groups online will also let you dig further into the issues and learn more about the vulnerabilities.

Here’s to a more secure future!

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Security Banners (For If You Forgot to Apply the Latest CVE Patch) appeared first on New Relic blog.

RailsConf 2013 is right around the corner! And to celebrate, we’re publishing a series of blog post that highlight what’s new and exciting in the world of New Relic’s Ruby support. Don’t forget to check out the entire series so far: Living on the Edge with Rails 4 and Ruby 2, Cross Application Tracing and Thread Profiling.

A few years ago multi-threading support in Ruby was flaky or nonexistent. The Ruby agent came of age in that world, where the only real option for concurrency was running multiple processes. Recent versions of JRuby and MRI have changed that landscape. With Rubies providing OS-backed support for concurrency primitives, libraries and servers are taking advantage of threads like never before.

In light of this, we’ve done a significant rewrite – focused on thread safety – to how the Ruby agent accesses its metric data structures. All the agent internals now work through a set of methods which ensure concurrent reading and writing of metrics is safe. In the past highly threaded applications could encounter inaccurate monitoring or contention issues, but those should no longer be a problem for the Ruby agent.

As an added bonus, revising the APIs also let us update them for consistency and usability. Users doing more sophisticated custom instrumentation will benefit from the cleaner API, along with the thread safety it provides. Taking advantage of the agent’s thread safe internals, we’ve responded to a common customer request by adding support for Sidekiq. Sidekiq is a background task framework similar to Resque. Where Resque uses a forking model, Sidekiq approaches this problem by executing jobs concurrently on multiple threads per worker process. Keeping fewer worker processes means less startup time, less memory consumption, and more sharing of resources between jobs. While it requires a keen eye toward concurrency issues in your code, for certain types of jobs Sidekiq’s multi-threaded approach can be a big performance win.

Sidekiq monitoring is enabled automatically by the New Relic Ruby agent starting with version 3.6.0.

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Thread Safe APIs and Sidekiq Support for Your Threading appeared first on New Relic blog.

We want New Relic’s Ruby agent to work best with the latest Ruby libraries and implementation. Sure, we still support Ruby 1.8.6 and Rails 2.0, but most people have moved on. And that’s what we focus on.

We were proud to provide Ruby 2.0.0 compatibility from the day it was released, thanks to a pull request from charliesome in Melbourne, Australia. ”Ruby 2.0.0 is the first stable release of the Ruby 2.0 series, with many new features and improvements in response to the increasingly diverse and expanding demands for Ruby.”

We’ve also kept the agent compatible with Rails 4 development, including rails 4.0.0.beta1. Rails 4 provides updated versions of the ActiveSupport::Notifications libraries, which generate a queue of events containing performance timing information. The latest versions of the Ruby agent subscribe to these event streams, allowing us to integrate more seamlessly into the framework and avoid excessive monkey-patching. The highlights for Rails 4 include strong parameters, turbolinks, and Russion doll caching. See the Rails 4 release notes for all the coolness.

Not too long ago, our own Jon Guymon released metriks-reporter-newrelic_rpm for feeding data from Metrik’s API into New Relic. Metriks is a well thought out open source API for measuring aspects of your Ruby app.

We’ve also been investigating the best way to measure the performance of Rails 4 Ajax features like Turbolinks. Ben Weintraub recently pull requested an additional JavaScript event into the Turbolinks gem, and we’ve been experimenting with approaches for monitoring JavaScript and Ajax performance.

See the following for more information on New Relics support for Rails 4 and Ruby 2:

* Come & Get the Latest New Relic Ruby Agent
* Ruby Agent Installation Documentation
* https://github.com/newrelic/rpm/pull/104
* Metrik’s API

Tune in tomorrow for the next blog post in our RailsConf series!

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Living on the Edge with Rails 4 & Ruby 2 appeared first on New Relic blog.

RailsConf 2013 is right around the corner! And to celebrate, we’re publishing a series of blog post that highlight what’s new and exciting in the world of New Relic’s Ruby support. Don’t forget to check out yesterday’s post on Cross Application Tracing.

New Relic tries to bubble up the most significant performance data from your apps like database queries and response times. But sometimes you need to deep dive into how your code is executing to solve a problem.

For times like this, the New Relic Ruby agent provides a low overhead sampling profiler that collects call graphs for running production apps. These can be triggered on demand from the New Relic UI.

The Thread Profiler works by spawning a background thread that takes snapshots of other threads’ backtraces at regular intervals. Over time, the profiles builds up a good representation of where your application is spending most of its time down to the method call level. New Relic’s web UI visualizes Thread Profiles in an interactive hierarchical tree format, highlighting the ‘hot’ methods where the app is spending the most time.

Our own Jason Clark gave a talk on this subject recently at Mountain West RubyConf. His session, DIY::Thread.profile — Light-Weight Profiling in Pure Ruby, described the techniques he used to write this pure Ruby profiler.

For more information on our Thread Profiling feature, see our Thread Profiler documentation.

Next up: Living on the Edge — Rails 4 & Ruby 2

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd t-shirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/railsconf.

The post Thread Profiling: See Exactly What Your App Is Doing appeared first on New Relic blog.

RailsConf 2013 is right around the corner! And to celebrate, we’re publishing a series of blog post that highlight what’s new and exciting in the world of New Relic’s Ruby support.

If you’re a Rails developer, you know that developing a great web app is a straightforward process. While that offers many advantages, some apps grow too large and become hard to manage.

This means you’ve mostly likely had at least one encounter with a huge monolithic Rails application. And breaking up these apps has become a common topic at Ruby conferences this year. At Ruby on Ales, Software Developer Brian Morton explained how Yammer breaks applications into services. (He’ll be giving the same talk next week at RailsConf.)

To help you stay in control of your applications, New Relic’s Ruby Agent now provides Cross Application Tracing (CAT) which tracks and visualizes how different services in your infrastructure communicate. In addition to tracking across Ruby apps, we can trace API calls made to Java, Python, PHP, or .NET apps. For example, you can use CAT to see related Transaction Traces between a Rails application and a high performance Java service.

Use CAT to get some good insight into how data is flowing between your applications. It’s been helpful to us for breaking apart our own gigantic Rails app.

For more information on New Relic’s Ruby agent, check out:

* rubygems.org
* github.com
* newrelic.com

Next up: Thread Profiling: See Exactly What Your App Is Doing

Headed to RailsConf 2013? Stop by our booth to see the New Relic Ruby Agent in action, pick up your free Data Nerd tshirt and more. You can even try New Relic Pro free for 30 days. For more information, go to newrelic.com/rubyconf.

The post Cross App Tracing: Time to Break Up that Huge Rails Application? appeared first on New Relic blog.

* Spotify shares its manifesto to create alignment and direction for its improvement work.

* Ilya Grigorik has an overview of WebP.

* Kris Gale, VP of Engineering at Yammer, argues the key to building fast lies in small teams.

* In this video from Waza, Matz talks about the recent release of Ruby 2.0.

* Guy Podjarny takes a look at real world Responsive Web Design performance.

* Joshua Bixby asks when it comes to big data, how big is big enough.

* Rich Pareta explains how to get hired into a collaborative engineering team.

* Colin Ihrig discusses the challenges in scaling Node.js applications.

* Etsy’s Lara Swanson explains why website performance begins with design.

The post Community News: An Overview of WebP, Matz Talks About the Release of Ruby 2.0 & More appeared first on New Relic blog.