RailsConf Keynote: David Heinimer Hanson

Short Version: Think before you code. If you think clearly about your domain problem – the answer is much simpler.


Before DHH’s keynote, rails conf 2007 was announced:

RailsConf 2007 will be done in partnership with O’Reilly & Associates!
may 17th-20th in Portland, OR

DHH talks about his very strong opinions. About bending the outside world to our way, not the other way around.

In “The Real World” You’re weighed down by decades of practices.

The Japanese version of Agile Web Dev sold over 7,000 copies in the first few weeks.

43 Things does 3.5 million rails page views a day now.

h3. Create Read Update Delete (CRUD!)

It is the baseline of most of the work we do in the Rails world.
What they told you about CRUD:
* Simplistic
* Unfulfilling
* Unworthy
* Shameful


h3. “How I learned to stop worrying and love the CRUD”

His old way of doing things

POST /people/create
GET /people/show/1
POST /people/update/1
POST /people/destroy/1

This makes him queasy now
His new ideal:

POST /people
GET /people/1
PUT /people/1
DELETE /people/1

The problem with the new way is, even though it’s part of the HTTP Spec, it doesn’t translate well to HTML.

ActionController::Routing::Routes.draw do |map|
map.resources 'person'

Rails is all about making a magical world where things just apply – like mapping HTTP verbs not used very much. Even though HTML doesn’t do it, RAILS does (1.2)!

By using a hidden value, @:method => :put@ becomes @input type=”hidden” name=”_method” value=”put”@.

h4. Why Bother?

It’s a lot of work. Why should Rails go through all the trouble of making this work right?

* Consistency
Some of DHH’s code for controllers are a bit of a mess. Sprawling is the right word.
The more decisions you can take out, the more you can get done.
* Simplicity
* Discoverability

h4. Constraints are liberating

The real power of crud is building our your DSL(Domain Specific Language)
With the new ideas – you can do many to many’s for free. Updates, etc.

Which gets us to “Memberships”

h3. “If you want to indulge in insanity, it should HURT” – DHH.

h3. CRUD is not a goal, it’s an apiration – a design technique.

15 actions in a controller is way too many.

h3. Simply RESTful

by using the extension of the request, you can “force” mime-types. Not just for GETs but POSTs as well

h3. Active Resource

RailsConf Panel: Homesteading: A Thriver’s Guide with Nathaniel Tallbot


h3. Train

c.1870 Bobby – a shop manager. Knows the ins-and-outs of the shop, but doesn’t own it. He is starting to hear things about the new frontier and how much opportunity is out there. Also, the homesteading act has just come into being (about 10 years previously). The homesteading act was the ability to stake off a large plot of land (400 or so acres), if you lived on it for 4 years and built a house the land was yours, free and clear.

In the 21st century, Homesteading is building small, sustainable business that we own (or own a piece of them).

The Train part of the talk is about why you SHOULD go out and do your own thing. Opportunity cost is how much it would cost to move on to the next thing. Some of which are not monetary. Learning, quality-of-life etc.

Live as risk management. Everyone has risk, and risk is tied to time. The amount of certainty is inversely relational to time, the longer the time, the less is known about what’s going to happen.

You only get to choose what you do right now. But what you do right now will affect what options you have in the future.

The one point to take away is that we are ALL at risk. Make sure you admit them, and weigh them out.

h3. Land

Bobby does some research. He bought the ticket, and his ticket is all the way to the west coast. Does some research on figuring out where he’s gonna stop along the way.

Figure out where you are, figure out what tools and actions you need to get there.

h3. Sunrise

Time management.
Time is our biggest non-reneable resource

h3. Community

On the frontier without other people, you’re in big trouble.
Good fences make good neighbors. Set rules and boundaries.

h3. Tools

Plowing the field is hard without an ox.

Internal and external tools – basecamp, iconbuffet, your private tools, websites, etc.

h3. Sunday

Bobby, even though he worked his butt off, still rested on sundays.

Rest allows us to do more.

h3. Inheritance

What is the value of what Bobby is doing? He is creating not only for himself, but for his future generations.

Wealth is more then monetary.

h3. Love

after 5 years, Bobby looks back and recognizes how great it is!

h3. Weather

Stuff you can’t control, but need to react to.

h4. Death

Bobby’s dead (well, he never really existed.)

h4. Buy The Ticket

RailsConf Panel: Testing Rails apps with Mike Clark

A awesome panel. Nice and slow!

h3. Unit tests

* go with one model

validates_presence_of :title
validates_uniqueness_of :title
def validate
errors.add(:price, "should be positive") if price.nil? || price > 0

Our test

def test_validate
product = Product.new

assert !product.valid
assert product.errors.invalid?(:title)
assert product.errors.invalid?(:price)

product.title = "Something cool"
price.price = 1234
assert product.valid?, product.errors.full_messages

(you can run tests from TextMate!)
Same for postive checking @def test_price_should_be_positive@

To test for uniqueness, we need some data

h4. Fixtures

YAML by default – one per model.
They are eval’d by erb

price: < %= ([1,2,3,4].map &1.method(:+)).join %>

fixtures :products
def test_unique_title
product = Product.new(copy!)
assert_equal ActiveRecord::Erors.default_error_messages[:taken]

with fixtures, it loads the data, isolates it in a commit, then rolls it back so each test is atomic (new on 1.1)

h3. Functional Tests

You need to figure out what to test – good test cases
Again, you should use your fixtures in your functionals

fixtures :users
def test_good_login
dave = users(:dave)
post :login, :name => dave.anme, :pasword => 'secret'
assert that it worked

RailsConf Panel: Universal design

h3. What is universal design?

Getting your design to the WIDEST range possible as is viable in busines

h4. Accessiblity is for

* people with disabilities
* sensory
* motor
* cognitive

h4. people with technical or cultural disadvantages

* Old computers or slow internet connections
* English as a second language

h4. Accessible tech

h4. Nielsen in usability engineering cites 5 factors:

* Learnablity
* Efficiency
* memoraiblity
* errors
* satisfaction

h4. Epicenter design

* 37signals
“Start from the core of the page”
* Microsoft

h4. Steve Krug’s Trunk test

If I took a user out of a trunk, will they understand it?

* What site is this
* What is this site for
* …4 more

h4. Tog’s First principals

Fitt’s law – the closer and bigger the target is, the easier it is to hit.

h3. Why is Accesibility important

* laws
* by 2020 estimates are 40 million americans will have a visual disabillity

h3. How do we accomodate users?

* Sensory – Standars XHTML+CSS. Transcriptions of podcasts and movies
* Motor – assistive hardare
* Cognitive – not much we can do.
* Cultural – page optimization, alt text (if they turn off images), etc. / standardized access keys etc.

Rails Conf Panel: iBatis for ruby with Badrinath Janakiraman


h3. When NOT to use ActiveRecord

h4. AR has some limit

* One class per table
* Primary key has to be id
* no composite primary keys
* Foreign keys are table_name_id

h4. iBatis as a datamapper – a different mapper for data -> objects

It uses the “DataMapper” pattern

h3. RBatis

* ruby implimention of iBatis
* written by “Jon Tirsen”:jutopia.tirsen.com
* less then 500 lines of code
* 3 files
* “rbatis”:https://svn/apache.org/repos/asf/ibatis/trunk

built around the data mapper pattern
a statement understands executable sql
a resultmap understands a translation from a recordset to a model

h3. Rails integration

it’s a mix-in repos like behavior to a model

class Product < RBatis::Base
attr_reader :product_id
resultmatp :default,
:product_id => [

What about updating methods? They are added by RBatis – things like .save .delete

It DOES Support active record validations!

RailsConf Panel: Metaprogramming Writertopia with Bill Katz

aka. “Some things I learned when trying to build my program up toward a DRY domain-specific language”

Short version: Very very dense talk, but great stuff. I think I’ll grok it at a later date.



h3. Bottom-up Design

“It’s OK to look like a fool.” – Paul Graham from yesterday. That was on a slide – AGILE!

h3. “What I wanted”

His goal was to have a DSL inside of rails that allowed him to do thigs like
@current_user.has_role? “moderator”@, etc.

h3. Our Tour

* Authorization DSL
* Objects classes and singletons
* Authorization Plugin
* Identity Plugin

def secret_info
permit "(matz or dhh) and interested in Answers" do
render :text => "Then Answer of Life = 42"

h4. How do we “permit”

insert class method “permit”. Needs to filter all instance methods, before_filter is similiar (so it’s a clue)
insert instance method “permit”

In the init.rb – send include into actioncontrolelr::base_send and actionview::base.send
(I need to get these slides, they are DENSE. They will be online.)

h4. How do we do this?

Insert class method which insert required methods



Then for authorizable, it’s kind of the same thing.

RailsConf Panel: Lessons from Blinkasle and IconBuffet with Scott Raymond

One of the coolest things about this panel is that I was sitting next to “DHH”:http://www.rubyonrails.com
Even cooler – he released Rails 1.1.2 sitting next to me :)



Vitruvian man – DaVinci’s famous drawing of a man in a circle in a square. Described by the “first architect” Vitruvious – an ancient Greek.

h3. The Three Laws of architecture via. Vitrivus and why they apply to software.

* Firmitas
“Firmness”, strength, durabililty, etc.
* Utilitas
Utility – fitness for a given purpose.
* Venustas
“delight” / beauty or grace.

h3. Firmatias

Firmness doesn’t mean rigidity. Buildings and software need to be flexible as well as strong.
h4. Working with designers

* Templates first
* Mockups directory
* Tight loops
* Talk first

Then start testing

def test_bar_markup
get :bar

He made sure that it always validated.

h3. Utilitas

An example from IconBuffet. Using ajax (rjs) to make a much nicer experience for the buyer.
Fitness for a purpose – here’s an example of a church site done in Rails – Jacob’s Well.

h3. Venustas

Delight or Beauty
Our Apps should be physically beautiful (urls, design, ui, etc), but as developers we should have beautiful code.
Showing blinksale stuff

Out of Battery :(

RailsConf Panel: Thoughtworks on Rails with. Obie Fernandez

“Obie Fernandez”:http://obiefernandez.com


h3. What is Thoughtworks

A large “Enterprise” (700+) that does consulting on large projects

Roy’s Social Experiement
* Employ high level talent
* Grow a large org without hierarchy
* Give people info

Cast of characters (Some thoughtworks employees)
* “Martin Fowler”:http://www.martinfowler.com/
* Aslak Hellesoy
* Jon Tirsen
* Neal Ford
* Jay Fields
* Michael Schubert
* Kent Spillner
* Carlos Villela
* “Obie Fernandez”:http://www.jroller.com/page/obie

h3. First Project – ThoughtWorks Interactive eXchange (TWIX)

It’s major function was to get people in ThoughtWorks excited about Rails. Never really finished.
A social network with tagging where you can enter your interests and it would match you up with like-minded people also inside the company

They met with DHH because of the app, and they asked him what he really wanted, his response: “I want to change the world” – This got TW very excited about rails in general

h3. The Deere Project (The tractor folks)

Proof of concept site for supply-chain. In 6-weeks in Java. At some point, Obie saw an opportunity to use rails in the project. Obie ended up writing a totally separate part of the project (not even their work) in rails. It ended up making test data for their other project (the Java one). This turned into another project because he heard someone say “Yea, that’s neat, but what we really need is THIS” Those are magic words.

h3. The Deere COA project

They used task-modeling and paper prototyping and Task modeling.
Figure out who the users are, and what “tasks” they need to accomplish.
They had a Deere memeber on their team – what a cool idea.

h3. Wotif

“wotif.com”:http://www.wotif.com – an aussie-based travel site
A RoR site that is a hybrid J2EE – Rails app.
Don’t use rxml and AR when you have a lot of data flowing in. It’s too much of a hit (I’ve seen this myself).

h3. Kiosk App to count money

Instead of a Flash front end with a java backend, they used RoR with script.aculo.us. Instead of writing the interface to the usb coin-counter in C, they used ruby. It gave them the agility to explore more options. 1:1.1 test ratio.

h3. PCS Project (He can talk about this one the most)

Started in Chicago in Feburary 2006. Then kicked off in Delaware.
Blog about your work!

h3. Other TW Side projects / ex-TWers

* Stockhive by Yogi in India (uses ploticus)
* Revoo by “Ben Griffiths”:http://www.reevoo.com/blogs/bengriffiths/ (thanks for the correction ben!)
* Squisher Kurt Scharader

* “thoughtworks.com”:http://thoughtworks.com
* “blogs.thoughtworks.com”:http://thoughtworks.com
* “obiefernandez.com”:http://obiefernandez.com
* “jayfields.com”:http://jayfields.com