In the 21st century successful teams are data-driven. We’ll present a complete introduction to everything you need to start monitoring your service at every level from business drivers to per-request metrics in Rails/Rack, down to server memory/cpu. Provides a high-level overview of the fundamental components that comprise a holistic monitoring system and then drills into real-world examples with tools like ActiveSupport::Notifications, statsd/rack-statsd, and CollectD. Also covers best practices for active alerting on custom monitoring data.
by Yehuda Katz
When Ruby on Rails burst onto the scene in 2004, it excited web developers by showing that you could build next generation apps quickly and efficiently. Rails was one of the first frameworks to embrace Ajax, giving everyone the power to do partial page updates and whiz-bang effects in a conventional, effortless way.
In 2007, the Rails team embraced RESTful conventions, making API development a no-brainer for new applications. Because RESTful JSON is so easy in Rails, Rails applications tend to implement APIs on balance.
Then it was time to polish. Both the 2.0 and 3.0 releases cleaned up the code-base and found ways to take emerging conventions and make them easier to use.
But now, like in 2004, another revolution is brewing. Increasingly, developers are moving their view layer from the server into the client, using RESTful JSON and client-side templating to increase responsiveness and bring applicable aspects of desktop applications to the web.
Like last time, not every application needs to jump head-first into this new world. But just as in 2004, Rails has an opportunity to embrace the future, and bring its ruthless insistence on convention over configuration to bear on this problem.
Rails already has the plumbing to be a fantastic conventional JSON server. The question is: will we take the challenge, or will we desperately cling to the past, hoping that the future will never come?
Redis is a darling of the NoSQL crowd and for good reasons. It's easy to setup and has blazing fast performance. In this talk, drawn on real production experience and real code straight out of the DueProps codebase, Obie will introduce and demonstrate key Redis application patterns vital to today's Rails developer. Emphasis will be placed on real-world constraints and how to leverage Redis to improve scaling and performance over plain-vanilla ActiveRecord applications.
Heard about the big Basecamp launch this March? Wondering what's new, how it's shaping Rails, and the tech behind it? We're going to go over some the practices and patterns in the new Basecamp's code base and you can learn how to improve your app with them.
Some of what we'll go over:
by Kenta Murata
Chanko provides a simple framework for rapidly and safely prototyping new features in your production Rails app, and exposing these prototypes to specified segments of your user base.
With Chanko, you can release many concurrent features and independently manage which users see them. If there are errors with any chanko, it will be automatially removed, without impacting your site.
Chanko was extracted from Cookpad.com where the team uses it daily to test new features live, in production, on the largest Rails site in Japan which serves 500 million page views a month to a user based of over 15 million highly engaged uses.
by Lance Ball
Even the simplest of Rails applications can eventually grow into a twisted mess of complexity. At some point you will need a background task, or a long-running service, or a scheduled job, or all of the above and more. All of these little bits of functionality added to an application ad hoc can keep you up at night with cold sweats and nightmares. But it doesn't have to be that way.
In this presentation, we will examine a complex Rails application - complexity that is eventually common to most modern Rails apps: background tasks, scheduled jobs, WebSockets, long-running services, caching and more. We will look at the challenges inherent in these features for both development and deployment. Then we'll look to TorqueBox for simple solutions to these complex problems. You'll never have that long-runing service using the wrong Ruby code again; no more environment variable nightmares in your cron jobs. You can sleep better now.
TorqueBox is a Ruby application server that is built on JRuby and JBoss AS7. It provides asynchronous messaging, scheduled jobs, long-running processes, caching, simple deployment, and much more. TorqueBox is designed to bring the power, scalability and stability of these time-tested JavaEE services to Ruby applications through a simple and expressive Ruby interface.
You know 'em, you love 'em -- five-minute talks by attendees on topics that they're passionate about. We'll have a signup sheet available from the start of the conference, so start thinking of ideas today!
by Jared Ning
MiniTest is the no-nonsense testing framework you already know how to use. If we strive for cleaner and simpler code in our own work, wouldn't it be nice to have that in our test framework too? Whether you're a Test Unit fan or RSpec fan, you'll feel right at home using MiniTest. Its simplicity makes it fast, easy to use, extendable, and maybe most importantly, easy to understand. Plus, Rails 4 uses MiniTest.
Other programming languages have powerful features that are often enviable while working in Ruby: Python’s function decorators, Scala’s partial evaluation, and Haskell’s lazy evaluation, among others. Fortunately, Ruby’s metaprogramming facilities give us the ability to add these features to Ruby ourselves, without the need for the core language to be changed.
This talk will walk through adding simple (yet functional) versions of the previously mentioned features to Ruby, using Ruby, and discuss the dos and don’ts of responsible Ruby metaprogramming.
by Noel Rappin
There’s all kinds of discussion on how to make test processes work, and how to make tests fast, but it sometimes seems like there’s not much discussion on how to make tests useful. What makes a BDD test valuable, in that it will save more time that it will cost in maintenance? I’ll claim that there are five things that you should look for in your tests: independence, repeatability, clarity, conciseness, and robustness. These features will make the tests easier to write, easier to verify, and easier to keep consistent as your application becomes more complicated. You’ll leave this talk ready and able to write great tests.
“A testing tool by any other other name would assert as truthy.” – some guy. You’ve seen Rails’ built-in Test::Unit in the morning session. This afternoon, we’ll introduce RSpec, another popular testing tool. We’ll overview basic structure, contexts, “should” expectations, mocking and stubbing. We’ll also cover Rails model, view, controller, routing, helper, and request specs.
23rd–25th April 2012