The past, present, and future of RubyGems.org and what you'll see from the Ruby community's package manager site. Oh, and some GIFs too.

Rubygems 2.0 had partial Gemfile support, with Rubygems 2.2 almost all of functionalities ofBundler can be replicated with Rubygems, lets stop using extra layers when the core already does what we want to achieve.

The world of programming is changing. It's becoming clear that functional languages are the new mainstream. But how do you write code without objects and classes? For the answers, we can look both forwards and backwards, looking at the functional ideas of transformation, combined with some cool techniques from programming's adolescence. 

Creating games is crazy-fun and dirt simple with Ruby. If you can make a web app, you can make a game. This session will introduce basic concepts of game programming and show how to implement them using the Gosu library. This includes the game loop, sprites, animation, etc. And it will be fun!

Peter briefly built Rails apps for a living, but quickly discovered the beauty of using Ruby as a catch-all "Swiss Army knife" for jobs all over the place. In his talk, he'll look at how Ruby can be rapidly put to work doing all sorts of random things that help in other types of day to day work.

Right next to your app is a world of software you probably don't think about: app servers, Rack interfaces, reverse proxies and load balancers. Starting right next to your app, we'll look at how Ruby web apps are built. Which pieces do you control as the developer? Which pieces are traditionally owned by ops? What do they do?

We'll (quickly) talk about the standard software for these pieces -- Passenger, Puma, Unicorn, Thin, Rack, NGinX, Apache, HAProxy and Varnish, where they fit together, and why you might choose one or another.

At the end of the talk you'll know what you can put in your Gemfile to choose these, how production is different from development, and the beginning of how you'd set this all up on your own if you needed to. You'll also know why you'd have to choose one piece of software over another, versus when it's basically your call.

Design has often been cut off from the development side of the house, creating static images that are then handed off to developers to build. Invariably, this waterfall approach leads to unhappy designers and frustrated programmers, and often a product that misses the mark. Agile Development has solved many of the issues, but in many cases, designers still sit on the outside.

We’ll look at integrating your design team (even if it’s a team of one) into an agile development organization while still pushing user-centric design. We’ll study successes and failures from both consultancies (InfoEther, Hyphenated People, Meticulous) and product companies both large and small (LivingSocial, CargoSense). We’ll talk about strategies for getting your design and development teams aligned and working like a well-oiled machine.

This session will discuss:

* Integrating design into an agile development team

* What processes work well

* What processes lead to problems

* Things to take back and try on their teams

Hundreds of books are available to help you write Ruby source code and there are multiple large disciplines about how to structure the concepts within your code. But when you execute your code it ceases to be source and begins life as a unix process alongside other processes on a piece of hardware somewhere in the actual world.

I'll walk us through how to reason about your process, how to know what it's doing and what resources it's using and how to determine whether it's healthy.

We'll learn about what you can add to your source to make debugging easier, how to debug your code as if it were merely a C program, and what kinds of unique behaviors MRI, Rubinius, and JRuby have that are distinct from processes written in other languages.

BigData is a buzz word right now and there's a lot of cool things that people are doing. In this talk I'll show you some simple ways you can use Ruby and Google's data tools to explore big data.

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".

You may have struggled with TDD on these two issues, leading to giving up, or winding up with "uncanny valley" tests that are hard to maintain but don't provide support for change. Using a puzzle problem, we'll show how to expand on Red Green Refactor, so you can take advantage of the code-quality benefit of TDD.