Welcome to
Ruby on Rails
Kevin Lawver | June 25, 2009
http://uplaya.com
Friday, June 26, 2009

Hi, I’m Kevin Lawver
Chief Architect at Music Intelligence Solutions
- http://uplaya.com (it’s a Rails app)
Worked at AOL for 13 years, launched two
public Rails apps. Spent a lot of time on
AOLserver using Tcl and Tomcat writing JSP’s.
Just launched http://ficly.com with a friend as
an “art project” (also on Rails)
Friday, June 26, 2009

What is Ruby?
Object-oriented
Interpreted
Expressive
“principle of least surprise”
Friday, June 26, 2009

“They are focusing on machines. But in fact we
need to focus on humans, on how humans care
about doing programming or operating the
application of the machines. We are the masters.
They are the slaves.” -- Matz
Friday, June 26, 2009

Everything’s an
Object
This confuses everyone at the beginning.
Everything in Ruby is an object.
There are no primitives, they’re all objects!
For example, you can do things like 15.times or
24.hours.from_now
It makes for compact, human-readable code.
Friday, June 26, 2009

What’s Rails?
Web framework written by DHH in 2003 at
37signals for Basecamp
Takes most of the “grunt work” out of building
web apps
MVC
“Optimized for programmer happiness and
sustainable productivity”
Friday, June 26, 2009

Who Uses It?
37signals: Basecamp, Backpack, Ta-da Lists, etc
Twitter
Yellowpages.com
iLike (and Jango too)
Hulu (and Vimeo)
And thousands of other sites...
Friday, June 26, 2009

Why Use It?
Convention over configuration
Quick prototyping - can turn into the “real”
project without starting over
Convention makes it easy to share code and
quick to get started
Because it’s Ruby, you can turn it into anything
you want
Friday, June 26, 2009

Rails’ Components
ActiveRecord
ActionController
ActionView
ActiveResource
ActiveSupport
Friday, June 26, 2009

ActiveRecord
The “M” in MVC
Rails’ crown jewel - a great database abstraction
layer.
Makes it really easy to work with databases.
In Rails, your models should contain 95% of
your business logic.
Friday, June 26, 2009

ActionController
The “C” in MVC
Handles routing requests and processing them.
In Rails, your controllers should be light
Friday, June 26, 2009

ActionView
The “V” in MVC
Where you do all your HTML and most of
your XML.
I’ve used a dozen different template systems
over the years and Rails’ is by far my favorite.
Friday, June 26, 2009

ActiveResource
Rails’ built-in support for RESTful API’s
Makes it easy to do REST the right way
Provides a lot of the wrappers, error cases and
connection code you need to do RESTy stuff.
Friday, June 26, 2009

ActiveSupport
All the extensions to Ruby’s base classes
A lot of “glue” for JSON and other things that
don’t belong in the other pieces
Friday, June 26, 2009

My Favorite Things
About Rails
I can go from idea to “real” in hours instead of
days.
It’s easy to refactor single pieces without
affecting the whole app.
Plugins solve major problems without
requiring rewrites (see cache money)
Community is helpful and responsive
Friday, June 26, 2009

Getting Started
I don’t use Windows, so you’re on your own
there.
If you use a Mac and have Leopard, you
already have Ruby and Rails.
Linux? There are dozens of tutorials for your
distro, don’t worry.
Friday, June 26, 2009

The 20 Minute
Blog
Sorry if you’re following along online, I’m
heading to terminal now.
Friday, June 26, 2009

What we’ll be doing
Create a new Rails app for our awesome new
blog
Build a model, controller and view for it
Look at some helpful gems and plugins
Make a feed for it
Talk a little about ActiveRecord callbacks
Friday, June 26, 2009

What we won’t be
doing
Talking about tests (they’re important, but I
hate writing them)
Spending a lot of time on configuration
Friday, June 26, 2009

What we’ll be doing
(redux)
Create a new Rails app for our awesome new
blog
Build a model, controller and view for it
Look at some helpful gems and plugins
Make a feed for it
Talk a little about ActiveRecord callbacks
Friday, June 26, 2009

Wasn’t that fun?
now let’s talk about myths!
Friday, June 26, 2009

Some Rails Myths
“Rails doesn’t scale”
“Ruby (or Rails) is too slow”
“Rails locks you into doing it its way”
“X is better!” (where X = “Python”, “PHP”,
“Java” or whatever)
Friday, June 26, 2009

Myth: “Rails
Doesn’t Scale”
Friday, June 26, 2009

Maybe 3 Years Ago
Back then, we had to use FastCGI or Mongrel.
Now, though, we can use Phusion Passenger!
It’s an Apache plugin that does a great job of
managing Rails instances.
And Ruby Enterprise Edition makes Rails use
less memory and run faster.
Brilliant!
Friday, June 26, 2009

Live-World Examples
uplaya.com handles tens of thousands of
requests a day on a couple tiny Amazon EC2
instances (we could do everything on one with
room to spare, but I like having backup).
ficly.com handles tens of thousands of requests
a day on a single quad core server - that’s not
even breaking a sweat yet.
hundreds of other sites handle a lot more traffic
with minimal hardware or fuss.
Friday, June 26, 2009

You will probably
never need to
scale.
Friday, June 26, 2009

But if you do...
Friday, June 26, 2009

The Data Layer
Your database will fall over before your web
server does.
Optimize your connection, queries and indexes
Protect your database by using memcached
between your front-end and database
Friday, June 26, 2009

Cache, Cache, Cache
memcached is your friend
Disk-based caches don’t work once you grow
beyond one server - same thing for in-memory
caches
Caching hides a world of programming sins,
and saves you from having to do ugly things
like sharding.
Friday, June 26, 2009

You Don’t Want...
to be both read-heavy and write-heavy
to have complex queries that can’t be cached
to have to do multiple selects on a single
request
Friday, June 26, 2009

The Most Important
Thing
is to launch! If you never launch, you’ll never
have users. If you never have users, you’ll
never have to scale.
Rails helps me get from nothing to launch
faster than anything else I’ve tried.
It helps me get from launch to scale pretty
quickly as well.
Friday, June 26, 2009

Typical Rails Stack
Apache w/ Passenger
*x
MySQL Master memcached * y
Slave Readers * z
Writer
Friday, June 26, 2009

Myth: “Ruby is
too slow!”
Friday, June 26, 2009

But, it’s fast
enough for the
web.
Friday, June 26, 2009

For all of my sites...
No request takes longer than 1 second
On uPlaya, the average time per request is 217
milliseconds.
On Ficly, the average time per request is 165
milliseconds.
That’s more than fast enough for the web.
Friday, June 26, 2009

The “Slow” in Rails
Is the same slow anywhere else:
Database
The Internet
CPU, Disk or RAM
Friday, June 26, 2009

Those factors
affect everyone,
not just Rails
Friday, June 26, 2009

Performance Gotchas
Database indexes. If you’re selecting or sorting
by a column, it should have an index! You
won’t know you need them until it’s too late.
Compression and Caching. Make sure you set
up mod_deflate and set up reasonable expire
times for static assets. It helps a LOT with
perceived performance!
Selects. Tune your cache so you can average
zero reads per page view, if possible.
Friday, June 26, 2009

Myth: Rails
makes you do
things its way
Friday, June 26, 2009

It doesn’t make
you.
Friday, June 26, 2009

It encourages
you.
Friday, June 26, 2009

Plus, Rails’ way
probably is the
right way.
Friday, June 26, 2009

And if not, you
can write a
plugin to make it
do it your way.
Friday, June 26, 2009

For example, things I
don’t like...
Rails’ built-in javascript stuff. I prefer jQuery,
and RJS gives me a headache
Routes, especially the name convention for
generated routes
Friday, June 26, 2009

But...
I happily use jQuery with Rails. I just don’t
use the javascript helpers. And now there’s a
plugin that let’s you use the helpers with
jQuery. Win!
I can live with the the route naming
convention. It makes sense, even if I don’t like
it. I could easily write a plugin to reverse route
names if I strenuously objected.
Friday, June 26, 2009

Myth: “X is
better!”
Friday, June 26, 2009

Your point is?
Friday, June 26, 2009

Religious battles
over
programming
languages are
stupid.
Friday, June 26, 2009

Use what makes
you happy and
productive.
Friday, June 26, 2009

Why You Shouldn’t
Use Rails
You have a legacy database that you can’t
change. You could make it work with Rails, but
it probably wouldn’t be much fun.
You’re happy with what you’ve got and hate
learning.
You don’t ever talk to a database. Rails pretty
much is ActiveRecord, so if you’re not using it,
you might be better off with something else.
Friday, June 26, 2009

Ruby-based
Alternatives
Camping: http://wiki.github.com/why/
camping/
Sinatra: http://sinatra.rubyforge.org/
webby: http://webby.rubyforge.org/
Halcyon: http://halcyon.rubyforge.org
Friday, June 26, 2009

Gems!
gem sources -a http://gems.github.com
Pagination: mislav-will_paginate
Faster URLs: pauldix-typhoeus
Twitterness: hayesdavis-grackle
Faster XML or HTML parsing: nokogiri or
hpricot
Friday, June 26, 2009

Rails Plugins FTW!
cache-money: a write-through cache for
ActiveRecord.
attachment_fu: great for handling uploads and
storing them on s3
smurf: automatic minification of javascript and
css
openid_enabled: just what it says, painless
OpenId.
Friday, June 26, 2009

To Wrap Up
Rails is fun to work with. I’m way more
productive now than I was before, happier too.
Rails is more flexible than it gets credit for.
It’s great for teams because it encourages good
behavior
Friday, June 26, 2009

And now, a word
from our sponsor:
We’re looking for interns! Development,
design or office management, we want ‘em! So
if you know any, please have them e-mail
jobs@uplaya.com!
We’re also looking for a front-end developer
and a Flash AS3 developer. If you know any of
those, please have them send their resume to
jobs@uplaya.com too!
Friday, June 26, 2009

And if you know
anyone in a band
Friday, June 26, 2009

Please send them
to...
Friday, June 26, 2009

uplaya.com!
Friday, June 26, 2009

Questions?
Friday, June 26, 2009

Thank you!
Friday, June 26, 2009

Contact Info
kevin@uplaya.com
@kplawver on twitter
http://uplaya.com
http://lawver.net
Friday, June 26, 2009