RailsConf 2007

Below is a collection of links and notes from RailsConf this year. A lot of the slides from the various presentations can be found here. Enjoy!

Keynotes

Below are some notes from a couple of the keynote speeches. Some of the keynotes were basically done by sponsors, so I don't include notes about them below. O'Reilly taped all of the keynotes, so they'll be available at some point in the future.

David Heinemeier Hansson

DHH's talk was about Rails 2.0. He felt that there was no need to announce some show-stopping, world-changing feature of the next big release of Rails, but instead that Rails 2.0 should be about improving what's already there.

Key upcoming features in Rails 2.0:

1. ActiveResource
2. HTTP performance
   • caching JS and CSS files
   • concurrent downloads on pages (using asset_hosts)
3. Query cache
4. MIME types split up for clarity
   • foo.rhtml -> foo.html.erb
   • foo.rxml -> foo.xml.builder
5. Better configuration
   • Clean up config/environment.rb by creating a new config/initializers directory
6. HTTP authentication
   • Built into controllers
   • Used for applications that know about it (RSS, Atom, Curl, etc.)
7. MIT assumption
   • Plugin generators now include the MIT license
8. Spring cleaning
   • All of the methods that were deprecated in 1.2 will be removed

Check out this blog entry that includes a bit more detail.

Jamis Buck, Michael Koziarski

These two talked about The Rails Way of doing things. Here are a few notes:

• Skinny controller, fat model
• models do not have to be associated with database tables
• test your models independently of your controller
• avoid using with_scope; use additional attribute readers instead
• don't use DRY if it makes your code unreadable
• don't use associations more than necessary; if you have two-way associations, only implement the stronger of those two because they're equivalent
• the bang-bang (!!) trick is hard to read; use something else

Some other tips and tricks:

• use map.with_options to clean up your config/routes.rb
• overwrite ActiveRecord's to_param method if you need to do something special with parameters

See their blog for more information.

Avi Bryant

Unfortunately I missed most of this keynote. From what I gathered he talked about Dabble DB and Smalltalk. He said that Smalltalk is almost exactly like Ruby but has been around 20 years longer, and he predicted several things that would happen to Ruby in the future, using Smalltalk as a reference. There is a Rails-like framework for Smalltalk called Seaside.

Ze Frank

This was more of a comedy routine than a keynote. This guy is hilarious. Check out his stuff at http://zefrank.com.

Dave Thomas

This was a sort of reflective keynote. He warned us not to blindly follow the Rails methodology, bringing up the cargo cult science analogy. There was also several humorous bits in his keynote.

Tutorials

Here are notes on the tutorials I took during the tutorial day.

Test-Driven Development

This tutorial was essentially about how to employ extreme programming techniques with Ruby. The idea is that every single line of code you write comes from a test first; you actually test the method you want to create before it even exists.

We did some pair programming, a technique that involves two programmers sharing the same workstation. In pair programming, you take turns writing tests that fail and then fixing that test. For example, if you want to create a Person class, the first programmer writes a test to make sure that the Person class exists. The test is run, which fails because there is no Person class. Then the other programmer comes in and only does the bare minimum to make that test pass, then he or she writes another test that will fail, and so on.

The presenter, David Chelimsky, also talked about RSpec, a test framework for Ruby and Rails. It's a DSL that lets you document your tests at the same time you write them. Here's an example:

describe "a pet with no name" do before(:each) do @pet = Pet.new end

it "should have no name" do @pet.name.should be_nil end

it "should get a new name" do @pet.set_name("Spot") @pet.name.should == "Spot" end end

Pretty cool stuff. RSpec has a Rails plugin that you can use to incorporate RSpec tests with your Rails framework.

There was also some talk about programming conventions you should use. One of which is, "Tell, Don't Ask". Write classes in such a way that you tell them what to do instead of asking for their data. Also, don't expose your class data for the sole purpose of testing it.

For example, let's say you have a user/role system. Users belong in roles, but you don't really care about how many roles they belong in. You have methods like User#belongs_to? that will tell you if a user is in an individual role. What if you want to add a user to two roles? How do you actually make sure that they're in both roles? The easy thing to do is expose your @roles variable and call length on it, but if you do that then you're exposing your data unnecessarily. There are other ways to test these things.

He also talked about how to refactor your code if you need to add new features. The important thing is to test everything during the refactoring process. One method is running your tests after every little change you make; that way if something breaks, you know exactly which change caused it to break.

Streamlined

slides

Streamlined is a scaffolding plugin for Rails that gives you a really good web interface out of the box. It's skinnable and customizable, so you can get a Rails app off the ground quickly. The simplest way to use it is to just add acts_as_streamlined to each controller you want to use the scaffolding.

Sessions

Here are some details about sessions that I went to.

respond_to :voice

description

This was a really cool demonstration about how to interface Rails applications with the telephone by using Asterisk, an open source PBX. The idea is that using the phone is just another way to view your application's content, and you can use the respond_to method to hook it up. During the demo, he used a phone to call the application, and he could create new records by hitting the keys. Pretty amazing. The plugin is called Telegraph and can be found at RubyForge.

Clean Code

slides from java version | description

This was about the benefits of clean code and how to get there.

What to do when you have bad code.

• The grand redesign. - not an optimal solution
  • have to rebuild the system while integrating new features that are implemented in to old one.
• Incremental improvement. - a better solution.
  • Fix the problems that you find when you are working on the code.
  • test every step of the way. - this provides the necessary flexibility to improve the code with out braking something else.

Arguments for clean code

• exploration of a mess that got cleaned.
• functions should be simple.
• duplication is bad.

Open Close principle

A program should be open for extension but closed to modification.

• refactor early and often
• don't make massive changes in the name of improvement.
• keep the tests running at all times.
• every tiny change must not break the program.
• separate volatile and non-volatile code.

Dinner Parable

The fastest way to finish dinner is to get up and walk away from the table. But the accumulation of dirty dishes makes subsequent dinner production a much harder process.

Doing REST Right

slides | description

This session was about what REST really is. The main idea behind REST is that you decide on a standard set of principles to use, and then you implement those principles across your entire application. HTTP is a good example of a RESTful protocol, because it groups all tasks under GET, POST, PUT, or DELETE.

Another part of REST is statelessness. Each request should contain all the information required to process that request. This makes it difficult to do authentication RESTfully. Storing session information on the server in combination with client-side cookies is not RESTful, because each request isn't fully self-sufficient.

In REST, methods should be safe and idempotent. A method is safe if it has no significant server-side effects (such as GET). A method is idempotent if it produces the same result for each subsequent call (e.g. abs(-10) = 10; abs(10) = 10; abs(10) = 10; etc). PUT and DELETE are idempotent; you should be able to DELETE the same thing over and over again (should return OK even after the thing is deleted). POST is sort of the odd man out; it takes some thought make POST safe and idempotent (or as close as possible).

All of the guidelines in REST center in some way around "resources". A resource is basically anything that can be named, which is pretty broad. RESTful applications display representations of resources, which isn't the same thing as the resource itself. A resource can be represented as CSV, XML, HTML, etc.

That's the gist of it. Check out the slides for more information.

Video Transcoding with Rails

description

This session was about how to use Rails to build a video transcoding service (similar to YouTube). Users upload videos, and your application transcodes them into a more compressed/portable format to publish on the web.

Some ways to handle uploads:

• Mongrel (doesn't block)
• Java/Flash (for more advanced uploads)

Using asynchronous processing will allow the user to continue using the application after uploading. There are a few ways to handle this:

• database polling
• message queue polling
• reactor pattern (event-based system)

Hosting solutions:

• local (not scalable)
• dedicated transcoding farm
• Amazon EC2

The transcoding process is a mile wide and a mile deep. There are lots of codecs and formats out there. He presented several different options and played clips to compare them. The most portable format is flash, but there are only two available codecs for it (H.263, VP6). If you want users to be able to play back video from your app, use flash or quicktime. Otherwise you can use some of the other available codecs (such as DivX or Theora). You also have to consider how much bandwidth you have and how much quality you want when you pick a codec/format.

Just as there are tons of codecs and formats, there are tons of tools to transcode video. There are two good open source tools to do this (ffmpeg and mencoder), and there are commercial tools available also.

Check out Jonathan Dahl's blog here.

Rails in Higher Education

description

This session about programming in a higher education environment. He also talked about the development of the program that he is working on.

• lines of code is a bogus measure of code -- more lines means more problems.
• reduced learning curve is very important when using transient works like student work/study workers.
• The IP Dragon
  • Universities are getting more interested in IP potential of software projects
  • If your projects are successful, you'll be asked for input.
    • This can be very draining to your productivity.
  • Technology transfer

• Types of IP
  • Copyrights
  • trademarks
  • Patents
    • be careful to not restrict your research.
      • he has a project that was canceled because it was working with concepts that were being patented.
    • if you are working with grad students university can prevent publication of articles, thesis until patent has been aproved

Fixtures: Friend or Foe

description

Fixtures are great, but once your application gets more complicated, fixtures become brittle. Changing fixtures around can result in test failures, and adding new fixtures can result in really long fixtures files that can cause slowdowns in testing.

Tom Preston-Werner wrote a plugin to address these problems. FixtureScenarios lets you group your fixtures into different scenarios, so that you only load certain fixtures based on whatever you're testing at the time.

Full-stack Accessibility

description

This application was about writing Rails applications that people who are disabled can use. More info on this later.

Birds of a Feather Sessions

These were informal get-togethers headed by various people that went to RailsConf.

#rubyonrails IRC

This BoF was a small gathering of folks who chat in the #rubyonrails IRC channel on Freenode. We made a Podcast out of it, since one of the guys brought a microphone.