Sessions at RailsConf 2012 on Tuesday 24th April

BohConf is a hacking-centric event that will include community code drives featuring well-known OSS authors, barcamp-style discussions, and more.

We've got 2 rooms reserved for everybody's favorite unconference. No RailsConf badge required. Please register on EventBrite (http://bohconf-railsconf2012.eve...).

Follow @bohconf for the latest news.

When he isn't ruining people's lives by writing software like phuby, enterprise, and neversaydie, Aaron can be found writing slightly more useful software like nokogiri. To keep up his Gameboy Lifestyle, Aaron spends his weekdays writing high quality software for ATTi. Be sure to catch him on Karaoke night, where you can watch him sing his favorite smooth rock hits of the 70's and early 80's.

There are many people in the Ruby/Rails world who contribute to our community and rarely receive any recognition or payment for their work.

They create educational content, develop plugins & gems, contribute to open source projects, and even put on events which help educate and make our lives as developers easier.

Ruby Heroes was created to show some gratitude and give these people the recognition they deserve. Hopefully the type of recognition that keeps them doing what they’re doing, and continuing to make our community stronger.

I regularly write code that does something great but is slow as a dog. Denormalizing / pre-computing / backgrounding are all fine, but they're all an investment and they leave tentacles all through the code. I want to be able to try out slow but very useful code in my app without the friction of performance concerns, but also without worrying that my ops engineer is going to kill me in my sleep.

Wouldn't it be nice to add one line to our models that takes care of caching, cache keys, backgrounding, dog-piling, and cache warming? Oh, and it should give the UI clear consistent hooks so that it's clear whether the data is ready so the UI can render a spinner or disable a feature until the computation is complete.

We'll take a look at a series of techniques that we use at PatientsLikeMe to allow us to safely and quickly put some very expensive queries on the website so that we can evaluate whether it's worthwhile to create longer term solutions. The solution we've come up with is a lot of gloss over memcache and resque that makes it feel like we can memoize any method in our application and lets us focus on the goals of the algorithms rather than their performance and architecture.

This talk will feature: memcache, resque, a bit of metaprogramming, a look at caching in the wild and code that fixes some usual problems, and a fairly epic SQL query with some nice Postgres features you should know about.

You should come if: you want to take a look at some practical solutions that we use in production to be able to roll out computationally expensive features.

Every young company expects to grow quickly, but is your engineering team really ready for it? In 3 years, iTriage went from a kitchen table to one of the leading mobile consumer healthcare apps with over 5 million downloads. Staying ahead of this growth didn't just mean hiring more Rails engineers.

Patrick will discuss what iTriage did (and continues to do) to stay ahead of our growth, including:

• Technical architecture, including use of Rails Engines to enable a modular, RESTful service-based design
• Enabling high quality iPhone, Android and Web apps
• Development and release management processes
• Recruiting and hiring approaches

Presenter and Decorators are design approaches that can be used in Rails applications outside of the standard Models, Views and Controllers. These approaches are becoming more and more popular as teams search for new ways to identify and manage the complexity within their applications.

In this session Mike Moore will defined the Presenter and Decorator approaches using simple and clear terminology. Common design problems in Rails applications will be shown using real-life code examples and refactored toward Presenters and Decorators. Code will be improved and strengthened by identifying and respecting the dependencies within large applications.

Done with Rails for Zombies but can't stop the craving for a second corpse? We’ll pickup where Rails for Zombies 1 leaves off and jump into the topics listed below. All you need to bring is a laptop with Wi-Fi and a browser which isn’t Internet Explorer. All coding will be done through our web application, and there will be plenty of lab assistants to help you if you get stuck along the way.

Topics covered:

• How to create a Rails app, the command line, database migrations, the Ruby 1.9 Hash Syntax, Bundler, and Database configuration.
• Named Scope, Callbacks, Include, has_many, and has_many :through relationships.
• REST principles, view forms, nested resources, and view partials.
• Sending email from our Rails app and the Rails 3.1: the Asset Pipeline.
• Controller rendering options and custom RESTful routes. Design an API with Rails and respond to AJAX requests.

Are you having trouble launching new features because of friction between development and operations? At CustomInk, we've reduced this friction by making changes to our teams, processes, and tools. Come find out what we've been up to and learn how you can implement similar changes in your own environment.

There's always a bit of tension when getting features from idea to production. In this talk, we'll look at some of the changes CustomInk has made to reduce this friction and keep the new features coming. Gone are the days of bi-monthly deploys, office pools dedicated to guessing when this deploy will be rolled back, and the ceremony surrounding the deploy-rollback-fix-deploy cycle. Today, ideas flow from product managers to developers to production with ease thanks to a number of changes that we've made to our teams, processes and tools.

During this talk, we'll look at:

• How product managers drive the release cycle
• Ideas and customer feedback
• Prioritizing development requests
• Managing branch merges and deployments (yes, product managers can help here!)

• How operations enables developer productivity
• Spinning up development environments - Vagrant, Chef
• Infrastructure Automation - Chef
• Enabling Continuous Deployment - Capistrano and caphub
• Failing gracefully - Fault-tolerant load balancing with ldirectord

• How developers get their code running in production
• Staging environments
• Continuous Integration - Jenkins, Green Screen
• Staying on topic: Deploying changes when they're ready

• Getting rid of the over-the-wall mentality - Dev & Ops working together
• Enabling developers to do it themselves
• Pair programing infrastructure automation
• Keeping the process light and the communication flowing

Google loves speed, and we want to make the entire web faster - yes, that includes your Rails app! We'll explore what we've learned from running our own services at scale, as well as cover the research, projects, and open sourced tools we've developed in the process.

We'll start at the top with website optimization best practices, take a look at what the browser and HTML5 can do for us, take a detour into the optimizations for the mobile web, and finally dive deep into the SPDY and TCP protocol optimizations.

We'll cover a lot of ground, so bring a coffee. By the end of the session, you should have a good checklist to help you optimize your own site.

This talk applies the concepts of chaos theory to software development using the Bak–Tang–Wiesenfeld sand pile model as the vehicle for exploration. The sand pile model, which is used to show how a complex system is attracted to living on the edge of chaos, will be used as a both a powerful metaphor and analogy for building software. Software, it turns out, has its own natural attraction to living in its own edge of chaos. In this talk, we'll explore what this means and entertain questions for what to do about it.

The speaker's hypothesis is that by understanding how complex systems work we can gain insights to better understand and improve the act of building software. By looking through the lens of the sand pile model we'll explore the following:

• what the sand pile model can tell us about software development
• how software is naturally attracted to its own chaos
• the impacts on software living perpetually on the edge of chaos
• how existing software practices can be used to detract software away from chaos
• what this means not only for our software, but for our teams, and ourselves individually

This thought-provoking perspective will leave you with new ways to think about software. You’ll walk away having learned a little about chaos, complexity, and how they apply to software with a thought-provoking perspective and inspiration for thinking about software in new ways.

Rails is so popular to be used to fast build a website, at the beginning we sometimes write codes too fast without considering code quality, but after your company grows fast, you have to pay more attentions on code review to make your website more robust and more maintainable.

In this talk I will introduce you a way to build a semi automatic code review process, in this process a tool will analyze the source codes of your rails project, then give you some suggestions to refactor your codes according to rails best practices. It can also check your codes according to your team's rails code guideline. So engineers can focus on implementation performance, scalability, etc. when they do code review.

A recent report by Veracode (http://www.veracode.com/reports/...) found cross-site scripting in 68% of surveyed web applications and SQL injection in 32%, even though these are well-known, easily preventable, and easily detectable vulnerabilities. As applications grow larger, it becomes harder and harder to manually verify that every line of code is adhering to security guidelines - even given the built-in protection available with Ruby on Rails.

Brakeman (http://brakemanscanner.org/) is an open source static analysis tool which provides painless vulnerability scans of Rails code from "rails new" through deployment. Running Brakeman as a part of continuous integration provides feedback during all stages of development and can alert developers immediately when a potential vulnerability is introduced. Bringing security testing as close to the developer as possible (even scanning as files are saved) means security problems are caught faster - and the sooner problems are found the cheaper they are to fix.

As a static analysis tool, Brakeman can be run without worrying about deploying the whole application stack: no webserver, database, configuration, or application dependencies required - not even Rails itself. This allows fast, easy vulnerability scans on any Rails project.

We talk a lot about testing in the Ruby and Rails community, but somehow security testing is passed over. This needs to change!

This talk will cover how to incorporate Brakeman into Rails development and how it can improve application security, as well as a look into how Brakeman works internally.

Schemaless database are a joy to use because they make it easy to iterate on your app, especially early on. And to be honest, the relational model isn't always the best fit for real-world evolving and messy data.

On the other hand, relational databases are proven, robust, and powerful. Also, over time as your data model stabilizes, the lack of well-defined schemas becomes painful.

How are we supposed to pick one or the other? Simple: pick both. Fortunately recent advances in Postgres allow for a hybrid approach that we've been using at Heroku. The hstore datatype gives you key/value in a single column, and PLV8 enables JavaScript and JSON in Postgres. These and others in turn make Postgres the best document database in the world.

We will explore the power of hstore and PLV8, explain how to use them in your project today, and examine their role in the future of data.

Rails is huge. Even if you have worked with it for a long time, it's unlikely that you have stumbled across everything yet.

Do you really know what all of the built-in Rake tasks do? Have you seen all of the methods ActiveSupport makes available to you? Are you aware of all the queries ActiveRecord is capable of?

In this talk, I'll dig into the extras of Rails and see if I can't turn up some features that you don't see all of the time, but that might just be handy to know about anyway. I'll make sure you come out of this able to impress your friends at the hackfest.

Anyone who develops with Rails uses the Rake tool all the time. Rake will run your tests, migrate your database, and precompile your assets. But did you know you can define and build your own Rake tasks? This short talk will cover the basics of using Rake and writing simple automation tasks to make your development process smother.

Rails 3 and above includes a powerful instrumentation system, ActiveSupport::Notifications, which can be used to track performance and event information for all aspects of your application. Notifications are light-weight, easy to setup, and can be consumed by multiple subscribers (logs, audit trails, consolidated metrics, other parts of your application).

In this session we’ll start with the basics of ActiveSupport::Notifications and work our way to powerful advanced use cases. Topics we’ll explore include:

• How to set up and use notifications
• Logging what you want from any tier of your system
• How to capture and aggregate performance/business data for the metrics you care about most
• Conditional monitoring in production: flag on and off data by system or customer to get to the root of problems more quickly
• Using ActiveSupport::Notifications in non-Rails applications and your own libraries

While Node.js is the hot new kid on the block, evented libraries like EventMachine for Ruby and Twisted for Python have existed for a long time. When does it make sense to use one over the other? What are the advantages and disadvantages to using node over ruby? In this talk, you will learn how to get the same power of concurrency enjoyed by Node.js while continuing to write in the language you know and love. Topics covered will include pubsub with redis or faye, building evented rack applications, and running evented applications alongside existing Rails apps.

Ruby on Rails claims to be "optimized for programmer happiness and sustainable productivity." I strongly disagree with the latter assertion. In this talk I will channel my half decade of industry Rails experience into expounding this position and providing constructive feedback as to what needs to change---in both the framework and the community---before we can support this claim. I'll also cover practical techniques you can use to be sustainably productive on your own projects in the meantime.

There’s no need to reinvent the wheel. There are over 30,000 RubyGems available on just RubyGems.org, alone. But with so many out there, it must be impossible to find the right one, right? In this talk we’ll learn about some resources which help you find the right gems, as well as how to intelligently decide if a library is right for your project.

Building safe web applications isn’t always easy. The good news is that Rails provides a lot of features that will help you along the way. Aaron will walk you through the common mistakes made by web developers, and how to account for them while working with Rails. He will also walk you through some tools you can use to make securing your applications much much easier.

"Stack Smashing" refers to an internal project where I took our production Rails application environment down from over 100 virtual machines to 2 physical machines. Our application environment for Major League Gaming consists of 13+ inter-connected applications with millions of users to provide functionality such as single-sign on, online video (both video on demand and UGC), news and live competition information, photo galleries, profiles, and much more. We simply needed a simpler infrastructure in which to develop and deploy our applications. In this talk, we will cover the following:

• Network topology before and after, as well as the makeup of our virtual and physical machines.
• Detailed discussion of Chef recipes, NGINX, HAProxy configurations and updates to standard configurations.
• Application and service monitoring and configuration.
• Application migration from the old stack to the new stack.
• Rails 3 to Rails 3.1 upgrade insights.
• Unicorns!
• Strategies for service configuration to handle failure.
• Offline processing with queueing and queue management.
• Simplifying, standardizing and sexy-fying your Capistrano-based deployment tasks into a reusable gem.
• Behavior driven infrastructure monitoring and validation.
• Adopting an opt-in continuous deployment strategy that is integrated with our continuous integration environment.

This will be a very code and example-focused talk. Come and learn about the ways that you can simplify your existing infrastructure.

Rails got much more modular after 3.0 rewrite. But do you know how to use specific rails elements outside Rails? What if you would like to use ActionView with some other library (like webmachine)? Have you ever needed to render view with layouts outside of the rails stack? Or maybe you wanted to build some kind of system that fetches templates from database rather than from files? Router anyone? You know that you can use it outside rails too?

In this talk I will dive into Rails internals and will show you what's there and how you can use it outside rails.

Although I will focus on using those parts standalone, this knowledge will most likely help you also build your apps if you ever need something sophisticated that requires modification of regular rails behavior.

Although XMPP is most often used as a chat protocol, it can also provide a robust asynchronous communication channel in other application scenarios. In this presentation, we will provide introduction to Strophe.js, XMPP4R, and ejabberd, which are the XMPP components that we use to integrate our device automation framework and living room devices under test. By using these off-the-shelf components, we addressed our needs for getting around internal firewalls, application security (based on SASL), and asynchronous command-response handling.

What does it take to deploy an application without any downtime?

More than most Ruby developers would expect, turns out; what is aggravated by the lack of documentation and other resources on this topic.

In this talk we'll dive into both development practices (hot compatibility, database migrations, caching) and deployment setup (Heroku, Unicorn, HAProxy), covering everything you need to know in order to ship code without affecting a single customer.

In this talk we will explore the best practices in using interfaces as the foundation for designing object oriented applications in Ruby and Rails. We will talk about some of the techniques that make it possible to write loosely coupled components that can be easily extended to respond to requirement changes.

David Cohen is the founder and CEO of TechStars. Previously, David was a founder of several software and web technology companies. He was the founder and CTO of Pinpoint Technologies which was acquired by ZOLL Medical Corporation (NASDAQ: ZOLL) in 1999. You can read about it in "No Vision, All Drive". David was also the founder and CEO of earFeeder.com, a music service which was sold to SonicSwap.com in 2006. He also had what he likes to think of as a "graceful failure" in between.

David is a active startup advocate, advisor, board member, and technology advisor who comments on these topics on his blog at DavidGCohen.com. He recently co-authored "Do More Faster" with Brad Feld. He is also very active at the University of Colorado, serving as a member of the Board of Advisors of the Computer Science Department, the Entrepreneurial Advisory Board at Silicon Flatirons, and the Board of Advisors of the Deming Center Venture Fund. He is a member of the selection committee for Venture Capital in the Rockies, and runs the Colorado chapter of the Open Angel Forum. His hobbies are technology, software/web startups, business history, and tennis. He is married to the coolest girl he's ever met and has three amazing kids who always seem to be teaching him something new.