Sessions at RailsConf 2012 on Wednesday 25th April

BohConf is a hacking-centric event that will include community code drives featuring well-known OSS authors, barcamp-style discussions, and more.

We've got 2 rooms reserved for everybody's favorite unconference. No RailsConf badge required. Please register on EventBrite (http://bohconf-railsconf2012.eve...).

Follow @bohconf for the latest news.

Ruby's favorite podcast comes to RailsConf! Join the Ruby Rogues (David Brady, James Edward Gray II, Avdi Grimm, Josh Susser, and Charles Max Wood) for this live episode on What Rails Developers Should Care About.

If you've listened to the show, you probably know that the Rogues favor:

• Good Object Oriented design
• Patterns
• Test Driven Development
• The Law of Demeter and Tell, Don't Ask
• Open source
• Beautiful code
• Pair programming
• Code metrics
• Scaling performant code
• and more

Since this is a live episode, we want to interact with the audience. Each Rogue will give a brief introduction on what's important to him as a Rubyist on Rails, then we will turn the session over to your questions. We will take them over the Internet and/or live, before and during the show.

All that AND we promise to wear amazing hats!

TBD

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.

So you’ve got the basics of Rails down, but you haven’t really done any testing. Never fear, this course will lead you through everything you need to know to start testing your Rails apps. All you need to bring is a laptop with Wi-Fi and a browser which isn’t Internet Explorer. All coding will be done through our web application, and there will be plenty of lab assistants to help you if you get stuck along the way.

Topics Covered
* Test Unit basics
* Testing Rails models, using fixtures, and validation testing.
* Improving our testing code with macros, shoulda basics, and setup/teardown.
* Mocking and Stubbing with Mocha
* Testing the whole Rails stack with Capybara Integration tests
* Using Factory Girl to replace Fixtures

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.

Concepts covered:

• Adding Redis-based flags and other properties to ActiveRecord objects
• Event tracking with Redis sets
• Graphing relationships between (User) objects with Redis sets
• Time-ordered activity feeds with Redis sorted sets
• Applying security restrictions to display of activity feeds with intersection of Redis sorted sets
• Aggregating group activity feeds with union of Redis sorted sets
• Applying Redis sorted sets to scoring and leaderboard programming
• Integrating Redis with Rspec and Cucumber
• Debugging tactics for when things go wrong or are unclear

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:

• Employing concerns to share code across models/controllers
• Stacker, the CoffeeScript component behind the "page" based layout
• Why polling for updates still works at scale
• Client side testing without the hassle
• Using jbuilder to keep view data out of models
• Keeping your team's sanity with a single setup script
• Debugging painful JavaScript performance slowdowns
• How to keep your app alive even if external dependencies like Redis are down
• Why tagged request logging and action/controller SQL query logging can make finding bugs easier

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.

This talk will explore the story of Ezra's travels through the history of ancient Rails 0.6 when he first picked it up in 2004 all the way through current times and extrapolate out to the future of the Rails and Ruby platform and how much of a success it has been. We will talk about the twisting path from way back then to now and beyond and explore what Rails was, is and will be as time keeps on slipping into the future.

This talk will be chock full of aqdvancxed tech as well as ramblings of a Rails industry Vet who has been "On the Rails" for *8* long years now and has played a major part in shaping what has been, is and will be(at least in his own mind where he is absolutely a legend, in reality he's just a schmuck who hacks ruby)

I want to share with the Rails community my story and experiences and hopefully impart some wisdom and some hard learned lessons about life, liberty and the pursuit of a rails app that doesn't use 400Mb of RAM per process ;)

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!

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.

Unless you have been living under a rock for the past year you might know of Travis CI, the continuous integration service for the open source community.

Travis started as a single GitHub project which was a rails app and a resque background task. Compare that to 12 months later where Travis is now four separate deployable apps, uses two different rubies (1.9.2 and jruby), and comprises a total of 10 GitHub projects.

Apart from looking at how Travis works now, we will also look at how it got there, and how we broke Travis up into smaller more manageable, more concise encapsulated services.

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.

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.