The best damn Ruby conference in Oregon
March 1st - 2nd 2012
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?
Software maintenance often gets a bad rap.
Many developers look down their nose at "maintenance programmers", and will shy away from maintaining existing code. Most programmers prefer green field projects, and avoid the tired old code of their predecessors. When a new person or team looks at existing software, it is not uncommon for the subject of a rewrite to come up: After all, a rewrite will fix all of the existing problems without introducing new ones.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.
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.