by Jeff Casimir
"Ruby can't scale."
Tell that to LivingSocial, GroupOn, Gowalla, Sony, and the rest of our community pushing millions of requests per day. Scaling an application isn't about piling up hardware and dropping in the newest database fad, it's the combination of design and refinement.
In this session, we'll look at refining Ruby code using tools to:
This is not about info-porn. It's about finding the 1% of your code that, through optimization, can dramatically improve performance.
In the wide world of web service development, Ruby is rarely the first pick as a platform to build on. Slowness and scalability are usually the reasons given to go with Java or something less friendly. However, language is rarely the bottleneck in a web application. Using a service at ATTi as an example, we'll look at how most service applications can be built and scaled in Ruby, and how to avoid common pitfalls.
by Dan Yoder and Carlo Flores
We've all seen load tests of a single "hello world" HTTP server using tools like ab or httperf. But what about load testing for real world Web applications and testing architectures that go beyond a few processes on a single machine? What about testing elastic "on-demand" architectures that add capacity as load grows? How does testing in the cloud affect your results? At what point does bandwidth become a bottleneck instead of CPU or memory? And what are we really measuring? What is the difference between connections and request per second? And how do those ultimately relate to infrastructure cost, which is the real bottom line?
We're going to try and answer some of those questions. In building spire.io, we wanted to simulate real use and validate that our cutting edge architectural decisions were really going to pay off. Along the way, we ran into some significant obstacles and some surprising results. Among other things, we built an easy-to-use node.js HTTP client that addresses a big gap in the Ruby toolkit - a fast, flexible HTTP client - that makes it much easier to generate massive amounts of load. We'll also talk about our work on Dolphin, a soon-to-be-released library for simulation-based load testing. We'll conclude with some candidates for best practices for doing load testing "with a vengeance."
by Ben Scofield
If you take a look at software today, you'll see more smart people building things than there ever have been before. The problem? They're all working in different languages, on different platforms, with different concepts. To take advantage of the full breadth of work that's being done, we need to stay on top of things happening in other communities, and we need to bring good ideas back to Ruby. In this session, we'll look at how to identify great code and concepts, and how to bring them back to our community.
Let's be honest, Ruby became mainstream a few years back and it isn't the cool underground programming language it once was. It's quite likely that your cousin's boyfriend who's "into computers" knows what Ruby on Rails is. There are hundreds of books, conferences, training and meetups for Rubyists. Recruiters fight to hire whoever knows how to generate a scaffolded Rails app. But now cool kids can't stop talking about node.js, CoffeeScript, Clojure, Haskell and pushing code to the UI layer. What does it mean for the new, existing and prospecting Ruby developers? Is it time to jump ship and move on to something else?
2nd–4th February 2012