The Rails Edge Sessions
Buried Treasure: Hidden Rails Tips
Dave Thomas
While writing the second edition of the Rails book, I've come across dozens of little, hidden Rails tips and techniques. They may not be obvious when you read the API documentation, or they may apply in different ways than you'd think. But they're more than curiosities—each of these tips and techniques has saved me time (or saved my butt) while writing real Rails applications.
From unexpected uses of with_options() to new kinds of rendering, from console tricks to TextMate addons, we'll have some fun while digging for treasure in Rails and Ruby. (And bring your own secrets too—there'll be time to share.)
Xen and the Art of Rails Deployment
Ezra Zygmuntowicz
Rails deployment has been somewhat of a black art for many people. Rails makes developing applications very fast and pleasant, but it requires a fairly complex server setup with multiple moving parts. Once you learn the theory behind deploying Rails, choosing a best practice deployment stack is fairly easy. Deploying Rails on Mongrel servers behind a front end proxy server from the start makes it easy to scale your application to multiple server as your traffic grows. Combine this with a sweet multi server automation toolkit like Capistrano and things get really interesting.
This talk is about the search for the holy grail in Rails deployment. What kind of Rails apps are easy to scale? What kinds are not? Which webserver works best these days? We will discuss the lessons learned in the deployment trenches. We will cover the common pitfalls and how to avoid them as well as little known optimization tactics and when to use them.
Live Code Review
Chad Fowler and Marcel Molina Jr.
Rails and its community are reaching a new level of maturity. In the not-so-distant past, most Rails developers were concerned with simply how to get tasks done. As Rails matures, the more relevant question is now how to get things done right.
In this session, we will take a real application and perform a live, on-projector code review. We'll shine a light on best practices and walk through potential problem areas and possible refactorings.
In the process, we'll also show you our process for performing code reviews on Rails applications, so you can go back and use the same techniques on your applications to come.
Intro to Active Resource
Chad Fowler
Since David Heinemeier Hansson's RailsConf 2006 keynote, REST has taken the Rails world by storm. You can't attend a user group meeting or spend much time on a Rails-related mailing list without REST and its architectural and design ramifications eventually dominating the discussion.
Not surprisingly, most of the discussion so far has been focused on the parts of the Rails REST stack which were released first: respond_to, CRUD conventions, and RESTful routing. These technologies all influence how you write RESTful server code in Rails.
But with the Rails REST conventions, we now also have a powerful tool at our disposal for writing client applications: Active Resource.
This talk will walk through the basics of Active Resource. We'll look at how to write clients in Active Resource, how it works, and when and where you should use it.
DSL: Speaking the Lingo
Jim Weirich
The biblical story of the "Tower of Babel" tells of a united people who decide to build a tower to the heavens. All the best architects and designers and workmen from the land come together and cooperate in the colossal task of constructing this great tower. When God decides to punish the people for this arrogance, rather than destroying the tower, he merely confuses the language of men so each man is speaking a different language. With the people unable able to communicate, the project fails.
The development community faces its own "Tower of Babel" today. As developers, we are well versed in the language of the computer. We understand how to instruct the computer in performing the most arcane tasks and are conversant in algorithms and patterns.
On the other hand, users don't care about variables and controls structures, but speak their own language that is centered upon their business domain. They use terms like "account" and "debit", or terms like "delivery routes" and "schedules". And although they don't know a bubble sort from a hash table, they do know about the bottom line and what makes their business work.
Domain Specific Languages (DSL) bridge the language barrier between users and developers. A DSL isn't concerned with variables and control structures like most computer languages, but uses terms and constructs from the language domain of the user.
You can build a DSL in many ways, but Ruby turns out to be a very good base for constructing "embedded DSLs," domain targeted mini-languages embedded within a larger general purpose language. This talk will look at various techniques for constructing embedded DSLs using Ruby.
Quick and Clean: Well-factored Rails
Chad Fowler
Rails is all about speed. It has been said that Rails programmers can develop software ten times faster than those programming in technologies such as .NET or J2EE. Rails itself is evolving at the speed of light.
But, to paraphrase Martin Fowler's RailsConf 2006 keynote, with Rails we don't have to choose between Quick and Dirty and Slow and Clean. With Ruby, and therefore Rails, we can have both speed and maintainability.
With Rails, the speed comes naturally. As it turns out, the cleanliness often doesn't. This talk will show you tips, tricks and heuristics for keeping your applications both quick and clean. We'll look at lots of real-world code and demonstrate how to clean it up using repeatable techniques which you can take back and apply to your projects.
The Streamlined Framework
Justin Gehtland
Streamlined is a framework, built on top of Rails, for quickly creating CRUD interfaces and an application wireframe based on your ActiveRecord models. With the announcement of Streamlined 1.0, we've released an entirely re-written architecture for Streamlined that is serving as the basis of several commercial applications for our customers.
During this talk, we'll learn how to:
- use acts_as_streamlined in a controller to provide a CRUD interface and controller backend for a model
- represent model relationships through Streamlined's Association Controls architecture, using one of the 10 built-in controls or by extending it with your own
- override the default views, both generally and in model-specific instances
...and more! The best part is we'll do it all through live coding, starting with only an empty Rails application.
Metaprogramming Ruby
Dave Thomas
Ever wonder just how Rails declarations such as "has many" and "belongs_to" work? Ever wished you could write your own code that worked the same way?
It turns out that this style of programming, often called metaprogramming, is easier than you might think. In this talk we'll see how Ruby's open classes, compile-time execution, and full meta-object model make it easy to write your own extensions. After this talk, you'll know how to adapt Ruby to express your intent directly, making your programs easier to write and maintain.
Rake: Building Up Ruby
Jim Weirich
Most people have used rake in passing as part of a Rails project. What you might not realize is that Rake is a general purpose build tool that can do more than just automate simple tasks in Rails. Rake allows you to define complex task relationships and makes sure that everything gets done, in the right order, just in time as you need it. Best of all, the Rake recipe file (known as a Rakefile) is just pure Ruby, so you already know most of what you need to put Rake to good use.
This session will cover the basics of writing your own Rake tasks, creating dependencies, and managing your software builds. We will cover how to dynamically generate tasks at runtime and how to write rules that will allow Rake to automatically infer tasks when given the right hints. We will also see some some advanced features such as multitasking jobs and creating Rake plugins.
Rake is a powerful tool to have in your toolkit. By the time we are done, you will be able to use it effectively.
JRuby
Justin Gehtland
The last two years have seen the explosion of alternate runtimes for Ruby: YARV, JRuby, Rubineus, Ruby/CLR, and others.
JRuby itself is a two-edged sword. On one side, it provides a comfortable yellow brick road for Java-centric development teams to adopt Ruby. On the other side, it gives Ruby-centric development teams access to the vast array of Java libraries, including features we don't currently have natively in Ruby like native threads and database drivers for obscure databases.
In this session we'll be looking specifically at JRuby, but we'll start with a brief comparison of the states of the various runtimes and how JRuby stacks up. We'll show how to get started using JRuby, and walk through writing simple programs, running and monitoring their execution in the JVM, accessing existing Java libraries and running a Rails application on the JVM. In addition, we'll talk about what the team at Sun is working on to finalize JRuby and provide tools to appeal to both the Ruby- and Java-centric developers who will come to use the runtime.
Red, Green, Refactor
Jim Weirich
One of the most practical practices coming out of the XP movement is the notion of Unit Tests. Whether you are actually doing some form of Agile development or not, unit tests are an important part of writing your software. The XP approach to writing unit tests is more than just writing the tests before you write the code. We like to call it "Test-Driven" because we use the unit test to incrementally drive the design and form of the production code.
The TDD approach is to write a little bit of unit test (that fails, hence "red"), then write only enough production code to make the test pass (that's the "green"). Then we examine the code and look for ways to improve it (finally "refactor"). The whole cycle from failing tests to passing tests to improved code is very short, often on the order of minutes.
This presentation will be a live demonstration of the Test Driven Design technique. We will use TDD to develop a small piece of functionality by following the Red, Green, Refactor cycle.
Mongrel: Learning how to walk the dog
Ezra Zygmuntowicz
All the cool kids are using Mongrel to run their Rails applications these days. And sometimes Mongrel itself gets so tightly coupled with Rails in peoples thoughts that they don't realize that Mongrel is something they can use outside of Rails to build their own fast, custom HTTP servers.
The web is moving towards a world of resources and services. Rails is the tool of choice for building these web 2.0 applications. But sometimes you have a critical section of your application that Rails is just too slow at serving, or you need to be able to support many concurrent users in portions of your site. Learning how to build custom Mongrel handlers will help you scale these performance critical areas of your application.
In this talk we will explore how to make your own hybrid Application Server with a custom Mongrel handler and some Ruby code. We will cover building a standalone custom Mongrel server as well as how to integrate custom handlers into your Rails applications using Mongrel's "stackable" handlers and URI classifier.
The Presenter Pattern
Marcel Molina Jr.
Keeping templates simple by extracting reused view logic into helpers is a good thing, but as your Rails application grows, so too will your helper files. After a while, it feels like you are trading off one evil for another as application_helper.rb balloons to hundreds of lines.
And a big helper file isn't your only problem. Some view logic gets sophisticated enough to require a handful of helpers to accomplish a single task, that themselves call there own set of helpers. These groups of methods also often need to pass some shared state around, and the functional nature of helpers makes for a clumsy experience. Now you not only have a big helper file, but its methods accomplish many unrelated tasks. Comprehending which methods accomplish what task and where becomes a lot of work. Refactoring gets harder and harder. Soon enough you have a real mess on your hands and you so you leave it be as Good Enough.
Rails is about making it simple to do the right thing, so from this pain, the Presenter pattern has emerged as a nice solution to combat the complexity of view logic. In this talk we'll take a quick look at the Presenter pattern: what it is and how it can be used to encapsulate sophisticated view logic. The Presenter pattern is shaping up to maybe be one of the next big extractions in Rails core. The jury is still out, but it's looking promising.
Rails: The Rich Internet Experience
Justin Gehtland
Rails was one of the frameworks that helped propel Ajax into the public consciousness. With its Yellow Fade Technique and the drag-and-drop lists showcased in Tada List, it brought the idea of easily providing rich user feedback through server-side code. Over the years, the details of the story have changed, but the theme remains the same.
This talk will examine the de-facto Ajax libraries of Rails: Prototype and Script.aculo.us. We'll take a brief look at the origins of Ajax in Rails, the helper methods that let you write Ruby in your .rhtml files but emit JavaScript. We'll then move on to the modern style of Ajax integration: RJS.
With RJS, you can use either in-controller Ruby or specialized template files (.rjs) to access new, powerful abstractions through the JavaScriptGenerator class hierarchy. We'll look in depth at the available methods and properties and talk about how the JavaScript proxies work. We'll talk about the respond_to operation for determining the type of inbound request and how to respond, and we'll look at the impact of Rails 1.2 routing changes on our Ajax code. At the end of the talk, you'll know four different ways to create dynamic, rich apps in Rails.
Amazon's S3 Web Service
Marcel Molina Jr.
Amazon's S3 web service is starting to get a lot of attention from people building applications that need to store and serve up lots of data. S3 is inexpensive, robust and simple. The headache of administering file servers appears to soon be a thing of the past.
In this talk we'll learn the basic concepts of S3 then take a look at how you can integrate S3 into your Rails application.
Domain-Driven Design in Ruby
Stuart Halloway
People sometimes contrast "quick and agile" with "scalable, complex, and enterprise." If you believe this, you may also believe that some technologies, like Ruby and Rails, are agile. Others, like JEE and model-driven architecture, are enterprise, and never the twain shall meet.
This distinction is silly. Agile processes are not worthy of the name if they cannot build large, complex things. Enterprise technologies, for their part, need to know how to start small and grow big where big is needed.
The trick that brings agile and enterprise together is good design. A lot of good thinking about design has been captured in an approach called Domain-Driven Design (DDD). DDD can make Rails apps better, and Ruby-centric thinking is a powerful way to approach DDD. Ruby provides a set of powerful abstractions that can keep your code in sync with your mental model, including:
- dynamic typing
- blocks, procs, and closures
- open classes
- easy reflection
- execution environment fully available
- easy Domain Specific Languages (DSLs)
We will look at how these language features enable key DDD patterns such as:
- Generic Subdomains
- Segregated Core
- Declarative Style
- Standalone Classes
- Intention-Revealing Interfaces
DDD will let you build Rails applications that can scale in every sense of the word. If your project needs to deal with complex problems, support high volumes, and continue to be adaptable, DDD can take you to the next level.
Agile Enterprise Ruby and Rails
Stuart Halloway
If you think that "Enterprise" software development and agile Ruby on Rails are opposites, you can find plenty of poor Enterprise architecture to support your point of view. But the reality is that many enterprises are trusting agile practices for critical business functions, and some are quietly adopting Ruby on Rails.
In this talk you will learn why agile is a good fit for enterprises, and how Ruby on Rails makes the fit even better. We will look at particular facets of Ruby that make agility easy:
- Ruby has excellent support for code level testing and mocking.
- Ruby's continuous integration support is improving rapidly.
- Ruby's facility for Domain Specific Languages helps keep business people and developers on the same page. Rails shows you how, with mini-DSLs such as ActiveRecord's declarative relationships and validations.
We will also look at some of the risks of agile Ruby, and how to mitigate them:
- Agile Ruby requires a high level of programmer skill.
- In Ruby, TDD is more important than you think it is.
Finally, we will look at how you can help shift your organization's culture to embrace agility, Ruby, and Rails. (Languages do not write software, people do.) We will dismantle the standard, content-free arguments against agile Ruby, so that your team's methodology choice can be based on substantive analysis.