2016 Year-in-Review

By Derek Bullet_white Comments Comments

We've pushed a lot of features this year at Scout. Here's a look back at what we've added to app monitoring in 2016:

Read More →


There's a Slim Linter in your Atom

By Matt Bullet_white Comments Comments

One of the technical bits I learned when joining Scout was Slim, a lightweight templating engine. I was a quick convert: Slim eliminates boilerplate code while making it easy to "break away" when full HTML markup is needed.

I'm a big fan of Linters, especially when learning a new syntax/language. It's like having a soft code review before the real thing. To assist with my conversion to Slim, I created an Atom package for slim-lint: linter-slim-lint. linter-slim-lint provides a lightweight interface inside of Atom to the output of slim-lint's analysis.

Read More →


Coming Soon: your Rails app performance trends & outliers, via email

By Derek Bullet_white Comments Comments

I follow a simple rule before configuring a monitoring alert: if I receive this alert at 3am, will I act on it?

If not, it shouldn't be an alert.

Few performance-related alerts meet this criteria. For example, if our app is running 25% slower, it's not worth a hasty 3am fix, but it is worth a first-thing-in-the-morning effort.

That's the drive behind a feature we'll make available soon: The Digest Email. Available in daily or weekly editions, the Digest Email summarizes your app performance and directs you to bottlenecks with ease:

Digest Email

Read More →


Elixir foundations for Ruby Devs: transforming data

By Tomasz Bullet_white Comments Comments

This is a guest post by Tomasz Kowal, a software developer currently working full time with Elixir at ClubCollect. He started with Erlang 6 years ago and is still amazed by the power functional languages provide. In his free time he likes tinkering with flying robots.

Have you ever reached for a drink of water, then realized, half-way through your first sip, it was Sprite? I like Sprite, but that first sip of a similar-looking, but very different liquid is a shock.

That's how Elixir can feel if you're coming from Ruby. The syntax looks similar, but Elixir is different from the first sip. For a smooth transition, you need to (a) learn some functional programming patterns and (b) unlearn some Object-Orientated habits.

A core design pattern of Elixir is the focus on data transformations: you'll see it in libraries like Ecto.Changeset, Ecto.Multi, Plug.Conn and built-ins like Enum. Let's dive in.

Read More →


Introducing GitHub-enhanced Deploy Tracking

By Derek Bullet_white Comments Comments

We're happy to introduce a lightweight addition to Scout: GitHub-enhanced deploy tracking.

​Deploy tracking makes it easy to correlate deploys to your app's performance. Scout's deploy tracking goes beyond chart markers: enable our GitHub integration to see which branch or tag was deployed, the team members that contributed, and a diff summary of what changed.

Enable deploy tracking

The latest version of the scout_apm gem tracks your deploys without additional configuration if you are running Capistrano. If you aren’t using Capistrano or deploying your app to Heroku, see our deploy tracking configuration docs.


  • DelayedJob - we've added DelayedJob instrumentation, which provides the same level of detail on DelayedJob as you've come to expect on your web requests. Update to the latest agent version to enable.
  • ScoutProf - looking for more insights on your traces? Try our ScoutProf beta.
  • Heroku Addon - featured in last month's Heroku newsletter, the Scout Addon makes provisioning Scout on Heroku even easier.

DevTrace and the Art of Staying the F*** Out of the Way

By Andre Bullet_white Comments Comments

DevTrace is a performance widget for your Rails applications in development. It sits unobtrusively in the corner of your page, just waiting to drop insight on your application:

See stack traces, SQL timings, and more with just a click!

This kind of insight is powerful. You can see how your app executes, and head off performance issues before they get to production.

But what I want to cover here is how DevTraces stays out of the way -- how it's simultaineously powerful and unassuming.

1) Installed via Gem only

There's only one thing to install, which is a gem in your application's Gemfile. Earlier iterations needed a Chrome extension to instrument background Ajax requests. But installing the chrome extension was annoying, and it limited who could use DevTrace. So we figured out a way to instrument Ajax calls in Javascript only, by adding hooks to the browser's XMLHttpRequest prototype.

2) Visually Lightweight

DevTrace shows up as a small, semi-transparent badge displaying your page load time. It's placed in the lower left corner of your page, to stay out of the way of navigational elements. Since your eyes natually move from the upper-left to the lower-right of a page, DevTrace is only there if you look for it. Finally, we added subtle animations for Ajax requests -- enough to notice, but not enough to be distracting.

3) HTML Hygene

HTML hygene (AKA staying the f* out of your markup as much as possible) is important. We know that — as a developer — you'll be inspecting your source, and don't want to see extra cruft from your performance tools.

DevTraces injects as little as possible into your page (we do have to add something though):

  • a <script> tag to load the needed JavaScript
  • a <style> tag, with classes carefully scoped to our namespace
  • finally, for HTML pages, a JSON data structure with the trace information for the page

4) Keeping Ajax / JSON Payloads Clean

Modern apps do lots of work via post-pageload Ajax requests, and visibility into those requests is important. DevTrace instruments those calls as well. However, we can't add profiling information to the payload itself - it would stomp on the expected payload structure. So we have a sneaky side-channel to move traces down to your browser in this case: we add a custom header to Ajax responses containing the trace information, then intercept that header & grab the payload in Javascript. It's all transparent to you as a user, and it provides critical visibility.

6) Staying out of your Javascript Namespace

Nobody wants to include a tool which litters the Javascript namespace with variables and functions. DevTrace puts exactly one variable into your addressible namespace, which is a reference to a closure containing the entire DevTrace implementation.

The DevTrace widget does a lot visually: rendering its UI, animating the badge on incoming AJAX requests, etc. To enable this UI goodness without polluting your namespace, we place a copy of MinifiedJS (a very lightweight jQuery-type library) inside the closure. MinifiedJS helps make the rest of the widget code concise and maintainable. Completely encapsulating it inside our closure means it can't interfere with other libraries or JS code on your page. Another key benefit is DevTrace makes no assumptions about which Javascript library your app uses.

6) Development Environment Only

Profiling in development is different from profiling in production. Always-on tracing works in development, because traffic is limited to just you (the developer), and overhead is less of a concern. In contrast, production environments require a smart sampling approach (which we're perfecting in Scout APM). No need to worry about leaving DevTrace on in the wrong environment: even if you accidently configure it for production, it won't even insert its rack middleware into your application in a non-development environment.

Staying out of the Way While Giving you What you Need

A Javascript widget needs to be a good houseguest. It doesn't put its feet up on the furniture or spread its stuff out all over the kitchen. DevTrace goes to great lengths to be a welcome guest in the host application, while also giving you what you need: performance traces at your fingertips, line-of-code tracing, memory usage metrics, and insights on database queries.

Learn more about DevTrace here.


Older posts: 1 ... 8 9 10 11 12 ... 68