22
Selected Sessions from RailsConf 2007 Jerry Richardson, [email protected] Chief Technologist, iBlinkink

Selected Sessions from RailsConf 2007

Embed Size (px)

DESCRIPTION

Notes from my test-heavy track of RailsConf 2007 sessions, as presented to the SouthBend.rb ruby and rails user group on May 29, 2007

Citation preview

Page 1: Selected Sessions from RailsConf 2007

Selected Sessions from RailsConf 2007Jerry Richardson, [email protected]

Chief Technologist, iBlinkink

Page 2: Selected Sessions from RailsConf 2007

Clean Code

• incremental improvement

• always check code in better than you checked it out

• never let the sun set on bad code

• test first => "test obsessed"

• provides the necessary flexibility

Page 3: Selected Sessions from RailsConf 2007

Robert Martin

“I am not allowed to make a change that breaks the

system. Every tiny change I make will keep that system

working.”

Page 4: Selected Sessions from RailsConf 2007

Let’s Refactor

• Principle of least surprise

• tiny steps => change each variable type, then run the tests

• shrink the granularity of your development

• create a barrier between things that change and things that don't

Page 5: Selected Sessions from RailsConf 2007

Is it worth it?

• crafting good solutions

• clean it up as soon as it gets messy => the dinner parable: get up and walk away from the dinner table or keep your dishes clean all the time

• bad schedules, requirements, team dynamics can all be fixed but bad code rots, ferments and becomes an inexorable weight that drags the team down.

Page 6: Selected Sessions from RailsConf 2007

Professional Behavior

• The "Green Band"

• Professionals write their tests first

• Professionals keep their code clean

• Professionals know that the only way to go fast is to go well.

• making things a little bit nicer => the check-in rule

Page 7: Selected Sessions from RailsConf 2007

Doing REST RightRecognize rest principles in what you're

already doing. Apply them to your whole process.

Orthodoxy (right teaching, right beliefs, right thoughts) versus Orthopraxy

(right practice)

Page 8: Selected Sessions from RailsConf 2007

Orthodoxy

• Roy Fielding's Thesis defined REST (Representational State Transfer)

• All models are wrong but some are useful. - George Box

• Leaky Abstractions

• Diagrams are wrong but useful in representing complex, real-world systems. Same thing with abstractions.

Page 9: Selected Sessions from RailsConf 2007

REST isn’t...

• Pretty URLs

• CRUD

• respond_to

• map.resources

• a protocol - http

• an architecture

Page 10: Selected Sessions from RailsConf 2007

REST is...

• the architectural style of the web

• Roy Fielding's Hierarchy

• Abstract => Communication Theory

• REST

• Web Architecture

• Concrete => Implementation

Page 11: Selected Sessions from RailsConf 2007

REST is...

• A resource is anything that can be named

• A resource is an object with a couple of contraints - can only implement a very small number of methods, same for all resources

• you don't access a resource -- you access a representation of it. (respond_to with format.xml, format.txt, etc.)

Page 12: Selected Sessions from RailsConf 2007

Orthopraxy

• Identification - URL

• Interaction (Method or Verb)

• Safety - has no side effects, incurs no obligations (get is the only method that is safe by definition)

• idempotent -- applying a function once returns the same value as applying it multiple times (get, put and delete)

Page 13: Selected Sessions from RailsConf 2007

Post

• post is neither safe nor idempotent => reserve it for when you need it

Page 14: Selected Sessions from RailsConf 2007

Content, Body of Request

• REST pushes all of the complexity into content, out of identification and interaction

• messages should be use standards and be self-descriptive, like html

• look for content types that map to your application domain - instead of to_xml, use an established type for users => do vcard instead of your arbitrary user xml

Page 15: Selected Sessions from RailsConf 2007

Adding Tests to Legacy Rails AppsMost first-time Rails apps are built

before a developer understands their importance. Testing is painful in many frameworks and ignored when many

people switch to using rails.

Page 16: Selected Sessions from RailsConf 2007

Starting

• Don't do it all at once. It won't work.

• first, run rake

• mysqladmin -u root create appname_test

• Use Migrations

• Scaffolding is broken => those tests don't work.

Page 17: Selected Sessions from RailsConf 2007

One Step at a Time

• find a bug, write a test

• refactor a method, write a test

• treat each method as a box - don't get pulled in to testing everything

• test one thing at a time

• Test: what goes in? what comes out? (returning something in the method)

Page 18: Selected Sessions from RailsConf 2007

Rake or Direct Testing

• rake or direct testing

• rake testing: rake test:uncommitted

• direct: ruby test_file.rb -n test_name to run one test in a specific file

Page 19: Selected Sessions from RailsConf 2007

Build Tests from Logs

• Parameters then reproduce actual requests.

Page 20: Selected Sessions from RailsConf 2007

What To Test

• right response code

• correct template

• variable assignment

• assignment of desired object

Page 21: Selected Sessions from RailsConf 2007

Questions?

Me.