Rails gives us M, V, C, routes, and helpers. Some people add observers and concerns, among others. We've standardized on presenters. Service objects are gaining popularity. Uncle Bob wants you to add interactors, request models, response models, and entities.

That's a lot of stuff! Let's step back: ideally, how do all of these things fit together? Does it make sense to have so many different components? How do different web frameworks project these onto actual components? Most importantly: how does this explain the tangled mess in Rails controllers and how we might fix it?

Building distributed systems is hard, but you don't have a choice: any non-trivial production system will be a distributed system. After you've resigned yourself to this eventuality, how do you deal with it? With practical insight into building fault-tolerant, self-healing distributed systems, Rein will show you the next steps to take your current system and make it fail less, recover more quickly, and get you to the pub on time.

Software maintenance often gets a bad rap.

It doesn't have to be this way. Shouldn't it be just as interesting and exciting to add new features to existing software? To put your mark on a product that already has a thriving user base?

Everyone draws inspiration and motivation from different sources.

For most, it's often frustration.

We make life decisions, define new features, or refactor code when we get too annoyed by current circumstances. This is where I admit that I have a low tolerance for frustration. Having been frustrated a great deal during my career, I'm going to discuss several anti-patterns that I've seen in code and how to use the Dark Side of the Force (frustration, anger, and rage) to escape from them.

Engines are a new-to-Rails feature that really isn't all that new-to-Rails. The concept has been around for a very long time, it's just only now that they, the Rails Core Team, has Done It Right(tm). In this talk, I go through the lessons learned while developing not just one but two engines.

I also provide more documentation than Rails has at the moment on engines *in one talk*.

When we last left our heroes they were perilously close to succumbing to the likes of the villainous Rein Henrich and his hoard of Rubyists intent on drowning them in Ales.

Will they recover their senses? Will they stop Henrich's evil plot? Will they remember to finish their talk this time? Stay tuned!

The cloud is great. It has lowered the bar for deploying applications. The cloud has encouraged experimentation which has lead to innovation. But what happens when an application's needs grows beyond what simple cloud services can offer?

In this riveting presentation Mike will discuss systems architecture and strategies for growing apps. He'll share specifics about the challenges Bloomfire met by making key changes to their infrastructure, including how network topology was used to solve critical issues with no changes to the application code.

Dave introduced Redis (via Resque) to Groupon back in January 2010. Since then, Groupon has taken advantage of Redis to solve a bunch of different problems that aren't a good fit for their busy MySQL servers. These problems include:

* Killing race conditions with incr/decr
* Storing transient data with expiresat
* Scaling horizontally with Redis::Distributed
* Integrating apps and services using pub/sub
* Tailored solutions with sets, sorted sets, hashe

Dave will demonstrate how Groupon uses Redis, and leave some time for Q&A.

Next, they will cover how they made Bundler significantly faster in version 1.1 by worked with the gemcutter team to add an API to rubygems.org and building support for it.

Finally, they will cover how Bundler 1.2 is going to make Ruby application development even easier.

Let Akira introduce you to some great software made in Japan.

You all know Ruby originally came from Japan, but he's not talking about that.
There's also many Rails related gem libraries made in Japan, and actually used in there that you've probably never used or even heard of.

This is partly because Japan has unique and separated Ruby / Rails culture and community.
Akira is going to show you some very useful gems with a live demonstration and real world examples.

Timmy's personal sweet-spot of hacking is found where multiple passions of mine collide. He is going to cover his happy place of hacking and will include all aspects of the Ruby on Ales Lifestyle: Ruby, Beer, and the pursuit of Snow through them both.

He will discuss finding a niche where your passions combine, discovering a need for a business/service, and going for it. All the while finding a way to give back to OSS and your community.

After working with C++ in the early 90s, I ended up on a project on NeXT for two years. The programming language on NeXT was Objective C which seemed like C++'s weird uncle. Java came along and kept me busy for the next several years while Apple simultaneously built Mac OS X atop NeXTStep. In 2006, I heard on the Java Posse podcast about Ruby on Rails. Compared to Java EE, Rails was a dream come true. After spending several years with Rails and simultaneously finding my way into Mac and iOS development, I started to understand why Objective C was much cooler than I had realized.

Users want a responsive web app, but that twisted mess of Javascript you wrote is impossible to maintain. A new crop of client-side MVC frameworks are a good way to start untangling it, but watch out: there are strong opinions, broken promises and loads of boilerplate code ahead.

In this talk, we'll look at three popular choices: Backbone, Spine and Ember. What problems do they solve, and which do they introduce? We'll cover core concepts, determine strengths and weaknesses, discover some useful patterns, and find out which is right for your project.

Every experienced Rails developer understands the need to break that monolithic application into smaller, manageable components. How do we build a confederation of systems without falling into the same traps that gave the phrase SOA such a bad name? We'll look at the following topics: * Knowing when it's appropriate to build as an SOA * The pitfalls of maintaining distributed systems. * Decoupling services through queues and gateways. * Clear patterns for painlessly testing services. * Using the right framework (and language) for the job. * The importance of service and resource discoverability. This talk is a distillation of our experiences running a large distributed system at both the Southern California Earthquake Detection System and the Engine Yard Cloud platform.