"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:
Find CPU-intensive hotspots
Measure memory and object allocation
Monitor query count and duration
Isolate data-store bottlenecks
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.
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."
(Talk given by Dan Yoder, CTO of spire.io, and Carlo Flores, Director of Operations at spire.io and co-founder of the LA DevOps meetup.)
We've all seen the monolithic Rails model, pages and pages of methods all dumped into one class. Inevitably someone starts moving things around just to feel better about the loc count without making any real difference. How can we reify actions on an object and simplify our classes?
In this talk we'll examine Rack middleware as a general purpose method of object composition, see examples of it at work in Vagrant, and use these ideas to simplify an existing application.
"The best minds of my generation are thinking about how to make people click ads." â€“ Jeff Hammerbacher http://buswk.co/eCdfFp We can rewrite Jeff's quote like this: "The best programmers of my generation are working on solutions to problems that do not matter." The crux of it is you are better than your job. You have a greater potential than your job is realizing. You can do more than you think. You are worth more than your job is paying you. You can make the world a better place. You don't have to be limited to building mobile/geo-based/social/ad-driven/gamification-influence/fully-buzzword-compliant bullshit to get people to buy things they don't need while giving up more privacy to corporations and becoming less happy in the process. You're better than that. Quit your job. Build your dreams. Change the world. Srsly.
Rails did a lot to bring REST to developers, but its conception leaves the REST devotee feeling a bit empty. "Where's the hypermedia?" she says. "REST isn't RPC," he may cry. "WTF??!?!" you may think. "I have it right there! resources :posts ! What more is there? RPC? Huh?"
In this talk, Steve will explain how to design your APIs so that they truly embrace the web and HTTP. Just as there's an impedance mismatch between our databases, our ORMs, and our models, there's an equal mismatch between our applications, our APIs, and our clients. Pros and cons of this approach will be discussed, as well as why we aren't building things this way yet.
As we enter a decade of applications developed with Ruby on Rails, many teams are starting to feel growing pains relating to design decisions that were made in the past. Development slows down, and morale declines. Fresh competitors without the cruft of legacy code slowing them down easily deliver new features.
This change of speed is not a natural part of the growth of a software project, but a common symptom of the design decisions made, and techniques practiced, to develop the software in the first place.
In this talk you will learn how to identify common (and not so common) issues that teams face as their applications age. You will learn about principles of software design, techniques, and practices to solve these problems. You will also gain valuable knowledge about how to make your software more maintainable and extensible to ensure you don't run into these problems in the future.
Life as a startup, whether a bootstrapped company or an experimental project within an enterprise, is hard. You have to struggle to earn success. Lean, pivots, minimal viable products, and other buzzwords all steps along this journey. The struggle makes the eventual success that much sweeter. But it can also lead to suboptimal code, confusing logic, and general friction to getting things done.
In this talk I'll discuss ways to identify areas of your Rails app improve and strategies for improving the quality over time. I'll share insights
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.
I've been writing Rails for near on five years, and there are some things that really grind my goat. Rails is great, but there are so many things we get wrong, both as a framework and a community. In particular, for applications that have grown beyond an initial prototype (if you earn a salary writing Rails, this is probably you), many Rails Best Practices are actively harmful to creating solid, robust, and enjoyable applications. I'll talk about testing, data modelling, code organisation, build systems, and more, drawing from a large pool of things I have seen done wrong and also personally failed at over the last half decade. Of course I'll be providing suggestions for fixing things, also.
It's more of a freight train, see.
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?