Frozen Rails 2011

Thank you to all the speakers, the sponsors, and of course all the attendees.


Sessions

Geoffrey Grosenbach

Keynote speaker

Company:
Peepcode
@topfunky
Website:
blog.peepcode.com

Geoffrey Grosenbach designs, produces, and publishes the acclaimed PeepCode Screencasts for web developers and alpha geeks. PeepCode publishes cutting edge training videos on jQuery, Git, Ruby on Rails, RSpec, and iPhone development.

He holds a degree in Philosophy and has taught computer-related concepts to people of all ages including business-people in Seattle, grade school students in Taiwan, and Ruby developers in the USA, UK, Canada, and Australia.


Code & Creativity

How does one start with nothing and make something? When we write computer programs, we start with only our thoughts. One can improve one's skills and write better programs by using techniques well known to creative artists: scratchpads, prototypes, thought streams, side projects.


Richard White

Keynote speaker

Company:
UserVoice
@rrwhite
Website:
height1percent.com

Richard White is the founder and CEO of UserVoice, a company which was born out of Richard White's frustration trying to understand his customers. UserVoice empowers customers to speak and companies to understand "by actually giving a #*$&".

Richard loves orange and not only has it in the company logo, but also wears orange shoes and rides an orange bike.


Josh Kalderimis

@joshkalderimis
Website:
blog.cookiestack.com

Josh is a top 30 Ruby on Rails contributor and has been working with the framework since 2008. He maintains a bunch of open-source Ruby projects, including multi_json, linkedin, faraday_middleware and his own completeness-fu. He's also one of Amsterdam.rb's organizers, and an integral part of the core Travis-CI team.


Travis CI - Distributed, Continuous Integration for the Ruby community

Co-presented with Sven Fuchs

“The future is already here — it's just not very evenly distributed.” (William Gibson)

The Ruby community is where a lot of this future already happens. We not only set the bar higher and higher every day, we've also built most of the infrastructure use day to day. Twitter, Github, Gemcutter, Pusher to just name a few projects that changed the world, the way we live and work.

With Travis CI, an open source continuous integration service for the Ruby community, we are going pushing our limits even further. We are going to build the test and integration infrastructure you are dreaming of: The vision behind Travis CI is to become for builds what Rubygems is for distributing libraries.

In this talk Josh and Sven, two of the core members of the developers team, will talk about Travis CI and introduce you to the vision behind it and the way it is implemented.


Sven Fuchs

@svenfuchs
Website:
svenfuchs.com

Sven Fuchs, pronounced [sfɛn fʊks], is an experienced software developer and open-source enthusiast currently based in Berlin.

While focusing on Ruby/Rails development for the last four years, he published a good number of Ruby and Rails projects, tools and libraries. Consistently amongst the top 30 on Rails-ranking sites, Sven is probably best known for leading the Ruby I18n project, the Ruby gem that is shipped with Rails to provide internationalization support.

Together with Josh Kalderimis, he now leads the Travis CI project, an open-source continuous integration service for the Ruby community. The product will revolutionize the way you deal with testing your code.

Travis CI - Distributed, Continuous Integration for the Ruby community

Co-presented with Josh Kalderimis, see the description above.


Zach Holman

Company:
GitHub
@holman
Website:
zachholman.com

Zach works at GitHub. When he's not doing that, he's blogging, hacking on open source, and filming screencasts that are anything but "traditional" screencasts. He attracted national media fame and glory when he built Facelette, a ridiculous three-hour experiment, and lost all of it again after admitting he sometimes stays home on Friday nights and replies to support emails.


How GitHub Uses GitHub to Build GitHub

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.


Nick Sieger

Company:
Engine Yard
@nicksieger
Website:
blog.nicksieger.com

JRuby, Rails, Open Source, Engine Yard, Family, Foodie. Not always in that order.

Nick Sieger is an engineer at Engine Yard, working on JRuby and leading the effort to make the Java Virtual Machine a robust yet easy-to-use deployment platform for Rails and Ruby web applications.

He created and co-maintains the JDBC adapter for ActiveRecord that JRuby on Rails uses for database connectivity, as well as the Warbler tool and JRuby-Rack library for dealing with Java application server deployment.


From Java to Rails: Techniques for Adding Ruby Agility to Your Java Web Stack

The Ruby programming language makes for great integration glue in enterprise applications. With JRuby, the Ruby implementation that runs on the JVM, and Rails as our glue for web applications, we can inject a high degree of flexibility into an existing Java web application. And we can do it in a way that cohabitates with legacy code and does not require significant rewriting of existing functionality.

We'll present strategies for incrementally taking advantage of the productivity of Ruby and Rails in a legacy Java environment. We'll also highlight new features of the latest version of Rails that can be applied to take productivity to new levels once you've begun to harness the power of Ruby and Rails in your existing application.


Joseph Wilk

Company:
SongKick
@josephwilk
Website:
blog.josephwilk.net

Joseph Wilk lives in London where he works as a software gardener for Songkick, a startup founded in 2007 focusing on live music.

Outside work he spends his time mastering the arts of Go and Chess, watching foreign films, reading profusely, learning Japanese, listening to music with strings, going to the theatre and ballet and working on open source projects.

He is a member of the Cucumber development team, suffers from test obsession, and has given up hope of any treatment.


Jeff Casimir

Company:
Jumpstart Lab
@j3

Jeff has been writing Ruby and Rails since 2005 and teaching Computer Science to kids and adults since 2003. He started Jumpstart Lab in the summer of 2009 and trains individuals and companies on how to build amazing web applications with Ruby/Rails.

Jeff has spoken at RubyConf, Mountain West RubyConf, and RubyNation in addition to many user groups.


Blow Up Your Views

Whether you're new to Rails or have been around few years, chances are that your views are primitive. Detonate what you know about how views are written and let's start over.

In this session you'll learn:

  • Why your views suck
  • Guidelines for view code quality
  • Kill Helpers and work with Objects
  • Instance Variables are Stupid
  • Embracing Rails 3's intelligence
  • JavaScript is not a four letter word

By the end you'll be dying to blow up your views.


Aman Gupta

Company:
GitHub
@tmm1
Website:
github.com/tmm1

Aman is a systems hacker who spends his days writing Ruby and C at GitHub.


Debugging Ruby Performance

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.


Elise Huard

Company:
Jabberwocky
@elise_huard

After her studies in metallurgy, Elise realized job in that area were not her cup of tea, and she looked for jobs in an earlier interest, software.

Since then, she’s been rolling through jobs in C, C++, Java, a masters in AI, before falling in love with Ruby and going freelance. 10 years of software have helped her get a firm understanding on what works, what doesn’t, and what will make you cry blood and tears on nights before deadlines.

She’s a jack of all trades, loves reading, tinkering, food, travel, learning, and people out of the ordinary.


Ruby goes to Hollywood

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).


Jarkko Laine

Company:
O'Design
@jarkko
Website:
jlaine.net

Jarkko Laine was one of the earliest Rails evangelists in Europe, giving presentations about the framework when only few people knew it even existed. He has written two Rails-related books, “Unobtrusive Prototype” and “Beginning Ruby on Rails E-Commerce”.

When not running aimlessly around the woods, Jarkko works as a developer for Wildfire App and as a Ruby and Rails trainer/consultant at his own company, O’Design.


Full Frontal for the Backend Pack

Is JavaScript still a bastard child in your playbook? Do you use strict BDD on the backend but just quickly hack something together for the view code? Do you still think Alan Cooper makes hockey sticks and that Donald Norman sells anti-virus software? Shame on you.

As web developers we cannot collectively put our heads in the sand when the user interface is concerned. Whether you liked it or not, we have to emerge from our caves and up the ante, because the UI of the vast majority of web apps still sucks balls.

This talk will be a full-on rant about the state of the union on the face of today’s web, with simple, pragmatic tips on how to easily rise above the masses.


Joseph Ruscio

Company:
Librato
@josephruscio
Website:
joseph.ruscio.org

Joseph Ruscio was a member of the founding team and is the Chief Technology Officer at Librato, Inc. He’s responsible for the company’s technical strategy, architecture, and general hacking on all levels of the product. He’s a Ruby enthusiast and the author of the aggregate and rack-test-rest gems.

Joe has over ten years of experience developing software in startup, enterprise, and advanced academic settings. He brings in-depth knowledge of systems programming, scalable web applications, and high- performance computing systems. Joe holds a B.S. in Computer Engineering from Illinois Institute of Technology and an M.S. in Computer Science from Virginia Tech.


Implementing a RESTful API with Ruby the Right Way

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

Ryan Smith

Company:
Heroku
@ryandotsmith
Website:
ryandotsmith.heroku.com

Ryan's educational background consists of Computer Science and Mathematics. He has contributed to projects like: ActiveMerchant, Gemcutter and others. These days he crafts code on the API Team at Heroku. Each day he solves problems using parallel algorithms and cloud infrastructure. Ryan believes this to be a fundamental concept in modern web development and thus he has a passion for teaching other developers how to best apply this concept.


THE WORKER PATTERN: SCALING HORIZONTALLY

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).