Sessions at Frozen Rails 2011 on Wednesday 21st September

Build features fast. Ship them. That's what we try to do at GitHub. Our process is the anti-process: what's the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It's not just features, either: faster development means happier developers.

This talk will dive into how GitHub uses GitHub: we'll look at some of our actual Pull Requests, the internal apps we build on our own API, how we plan new features, our Git branching strategies, and lots of tricks we use to get everyone — developers, designers, and everyone else — involved with new code. We think it's a great way to work, and we think it'll work in your company, too.

Ruby might be slow, but bad code only makes it worse. This talk will teach you how to use powerful tools to see how your code is executed, so you can understand, debug and optimize it.

The talk will cover techniques that can be used to troubleshoot production ruby deployments from three perspectives: the operating system and process, the C code VM, and the Ruby code in application itself.

Each tool will be presented with a variety of real-world examples of how it was used to solve problems in a popular library or application.

In this talk I will take a deep look into 2 common performance problems web developers face. We will consider these problems and then I will show solutions to these problems. From here we can generalize the solution into a pattern I call: The Worker Pattern.

Problem 1
While AJAX is a good first step, we must consider performance of our AJAX requests. I will show you how to use caching strategies that are compatible with all browsers and environments. I will also show you how to setup background jobs to quickly process the AJAX request.

Problem 2
Some code will always run slow. I will show you how to solve the problem by not solving the problem. In stead of focusing on the individual job itself, we will look at how to leverage a whole host of cloud nodes to execute our jobs. I will provide real world example (stuff we run into at Heroku).

APIs are often one the most powerful vectors for driving product adoption, but are often times bolted onto a SaaS offering as an after-thought. There are many different interpretations (some much looser than others) of what makes an API “RESTful”. At Librato we practice “API-first” development where our API’s are specified, tested, implemented, and finally used to add new features to our own products prior to providing them to our users.

A Rubyist looking for information today on implementing a RESTful API from scratch will find a set of largely incomplete and often conflicting blog posts and articles that really only scratch the surface. We spent a lot of time searching for the right answers when we first started building our API. This talk will distill the essence of what makes an API RESTful and a set of best practices to design/test/implement a RESTful API in Ruby, ensuring your users find your API easy and enjoyable to use.

Topics covered will include:
* README-Driven API design
* Securing and authenticating API calls
* Proper use of HTTP codes for error scenarios
* Handling different input/output formats
* TDD with rack-test
* Decoupling common patterns such as pagination
* Implementing the API with Ruby and Sinatra
* API Versioning

Computers are being built with more and more CPUs and those CPUs in turn have several cores. Powerful calculations are now performed either on many-cored machines, or on distributed systems.

In this context, it’s in the developer’s interest to start thinking about concurrent programming. But concurrent programming with mutable is tricky. The last few years have conclusively shown that very few developers get this right when faced with conventional shared state threads.

One of the ways to simplify concurrent programming is the actor model. In the actor model, programs are made of actors sending each other messages, and acting on the messages they receive. The actors don’t share any state.

This talk will explore several ways to implement the actor model in Ruby.

The talk will also allude to the fact that threads in Ruby should ideally have separate state, so that all programs using threads could also use the actor model (or other similar concurrency models).