I’m a bit delirious from late nights and early mornings and lots of code talk. We all went out to Pratt’s Ale House the night before and weren’t our usual chipper selves this morning. Nonetheless, this is the first official day of RailsConf so let’s do it.

Note: I just want to get this stuff out there while it’s fresh in my mind. Once I catch up on everything I will refactor this.

Keynote: DHH

The grand master of ceremonies kicked off the day with an inspiring round of a very opinionated list of the best of the best features in Rails 3. And the winners are:

• Bundler
• ActiveRecord queries (chainable and lazily evaluated)
• routes (nicer API)
• ActionMailer (total rewrite)

Keynote: Michael Feathers

I hadn’t heard of Michael before, but he seems to be big in the industry. Wrote a book called “Working Effectively with Legacy Code”. He was a very sensible, even-keeled speaker. He spoke rationally, calmly and intelligently about his experiences working on various projects and things he’s learned to utilize and things he’s learned to avoid. One example of the types of wisdom droplets he disseminated:

“Novices start out writing good code, but as they become experts they write complex code as they understand too much.”

Interesting take on an effect I’ve definitely seen. Novices write better (in terms of clarity to others) code than the dude who has been developing on the project for 5+ years.

Check out Michael’s book, and @mfeathers on Twitter.

And Now The Real Presentations Start…

Building an API with Rails

This talk was a panel format composed of @joeferris (Thoughtbot, representing Hoptoad), @bitsweat (37 Signals), @noradio (Twitter), @technoweenie (GitHub) and @nytimes.

I chose this talk mainly based on the members of the panel. It was loosely moderated and had the feel of a political debate. The moderator would give a topic, then the members took turns rambling about their take on how to handle whatever the current topic was. My notes sum up their responses pretty well:

Authentication

Pretty much everyone agrees that oAuth is the way to go here, and all favored oAuth 2.0 over 1.0, though Twitter will continue to support oAuth 1.0 as well as 2.0 for now.

Response Formats

Hoptoad

• only accepts xml
• reasons are how write-heavy and data-heavy the API is

NY Times

• an unordinary use case, but since NY Times has desirable data, there are lots of sites that aggregate that data and do refreshes every night which consists of hitting all parts of the API to download new data.
• supports xml and json

Twitter

• their ideal is to only support json
• fragment caches responses in memcached
• caches subfragments of fragments, think something like text of a tweet that will never change, but # of retweets does change, so they can cache the text as a subfragment and reload the retweet count more often

Versioning

Twitter

• versioning is hard
• main questions are how to split logic within the app and how to alter request params to signify version

37 signals

• advocates for not needing versioning, calls it over-engineering
• rely on devs to update their stuff to make things work with new versions

NY Times

• no versioning, more dev-centric crowd

Scaling

• varnish for cache invalidation
• http cacheing – expires headers

Code Separation

• GitHub uses separate controllers for API
• also might move API to sinatra
• Twitter used to have API, mobile and web req’s all in same controller action, but found the different requests required diff logic so code got complex, as conditionals were added for each variation. The conclusion was that it’s ok to have duplication in basic controller logic in order to separate the API out.
• 37 Signals advocates for golden path approach, responds_with(@resource), and life is really that simple

Security

• Twitter failed to sanitize string when eval’ing JSON response from API and got XSS’ed. (crazy, what?)
• authentication vs authorization – 37 Signals made a point of realizing the difference between these two.

Dev Communication

• good to have a status page
• keep docs up to date
• use your API, helps to fine tune documentation
• build community around API, GitHub

Don’t Repeat Yourself Repeat Others – John Nunemaker

This was the second time I’ve seen a presentation from John, so I knew it would be good. John is energetic and passionate but the best trait about him is his ability to explain fundamental programming concepts in ways that aren’t demeaning to newcomers, but also provide value to more experienced devs. For example, even while teaching us what include and extend do, he gave anecdotes about the stumbling blocks he went through when learning Ruby, which every developer can relate to and possibly even learn new ways to tackle future obstacles. The theme of this talk was something along the lines of: I wrote MongoMapper and learned a ton of stuff about ActiveRecord and even though people thought I was reinventing the wheel it was totally worth it so reinvent the wheel for your own self betterment.

Here’s from my notes.

Some highlights

• autoload Person, 'path/to/person'

  lazy loader used in Rails and MongoMapper

• hash1 = {:foo => :bar}
  hash2 = hash1.clone
  hash2[:foo] = "surprise!"
  hash1[:foo]
  => "surprise!"
  

  The reason for this is that clone and dup do a shallow copy so the internals of both hashes point to the same instances.

• 2 book recommendations “Ruby Design Patterns” and “Refactoring”
• MongoMapper plugin architecture is cool
• Plucky, the underlying class that translates MongoMapper finder calls into queries
• Writing/blogging is super important. It forces you to recollect, rethink, and solidify your understanding of whatever you are writing about

John’s slides [link coming soon]

The Present Future of OAuth – Michael Bleigh

OAuth is mysterious, Michael came up with an analogy that totally made it click for me. Here’s how it works. We’ll use the Twitter API as an example. Say you want to allow users the option to authorize your app to pull in their friends timeline. This requires an authenticated API call to Twitter. Using OAuth the steps are:

1. User clicks “login” or “authorize” from your app and is redirected to Twitter. With this request are passed along a client id and a client secret that identifies your app to Twitter.
2. User logs into Twitter and chooses to accept or deny access to your app.
3. Twitter creates a key card (like a hotel) and gives it to your app.

Why is it a key card? Really it’s a token that you can pass back to Twitter when you want to make authenticated API calls, but you can think of it as a key card because it’s only valid as long as Twitter keeps it around. They can choose to invalidate your card at any time, but while it is active it is your key to gain special access.

OAuth 2.0 > OAuth 1.0

No one should be using OAuth 1.0 any more. The biggest part of OAuth 2.0 is supporting multiple flows that accommodate granting authorization from multiple devices like phones, native apps, xbox 360, etc. There are 6 flows available, some of them are:

• user agent flow (your app authenticates itself using a client secret, but you don’t require user authorization)
• device flow (xbox – oauth provider sends back code that user has to then enter into browser)
• password flow (request user password, send to app, app sends back key card)
• assertion (you have a certificate)

Michael then walked us through an example of creating an OAuth 2.0 consumer and an OAuth 2.0 provider. Here’s the GitHub repo for that example.

Beyond Git Push Heroku: Battle Stories from Cloud Samurais – Teich (Heroku), Morten Bagai (Heroku)

Heroku is awesome. Use it. For those that don’t know, Heroku makes deploying your app as easy as:

git push heroku master

Here are some cool apps on Heroku: * scvngr – came out of nowhere, grew fast * Syphir – define more complex filters for gmail, nicer UI, delayed mail (awesome) * CloudApp – makes file sharing easy, take screenshot, app uploads to s3 in background and creates short url, paste url to your friend

Heroku add-ons

Heroku will be launching a way for developers to build add-ons. Some examples of ones currently available are Memcached and MongoDB.

Cloud Keiretsu FTW (small independent parts working together).

ZOMG: Domain-driven Test-assisted Production Rails Crisis Interventions – Rick Bradley

This talk was all about the steps to take when being contracted onto a project that is in a “rescue mission” state * start by doing light fixes, ui bugs and whatnot, easing your way in * always commit something cleaner than how you found it * don’t dig deeper than absolutely necessary * acts_as_ass (avoid “the guru”, funny story, i’ll tell you about it later)

The rinse and repeat process is: Reason the code, characterize the code (via code comments) and refactor the code. There are no giant “fix everything” style commits, it’s a process of characterizing the code bit by bit until you understand it and then refactoring.

When coming into an untested project that you know will be refactored, they drop in an rspec extension to add a currently method to specs, so you know what functionality will be disappearing.

currently('it does this crazy thing') do

  CrazyThing.crazy?.should be_true

end

Rick’s slides

Closing Keynote

Yehuda gave a talk about how to contribute to Rails and the reasons people shy away from it. It can be as simple as removing warnings. The #6 top committer to Rails did nothing but focus on removing the warnings that Rails was generating.

2010 Ruby Heroes are:

• Jose Valim – agnostic generators, responds_with
• Nick Quaranto – RubyGems.org
• Xavier Noria
• Aaron Patterson – nokogiri
• Wayne Seguin – RVM
• Gregory Brown – prawn, ruby mendicant

BOF Talks

Finally, I attended talks on Spree, Restfulie and an ActionPack deep dive lead by Yehuda. No time to write about these now as I have to head back to the convention center.