Selected Sessions from RailsConf 2007


Published on

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

Published in: Technology
  • Impressive presentation on ’Selected Sessions from RailsConf 2007'. You’ve shown your credibility on presentation with this slideshow. This one deserves thumbs up. I’m John, owner of . Hope to see more quality slides from you.

    Best wishes.
    Are you sure you want to  Yes  No
    Your message goes here
  • thanq its really good and useful to me in thinking about innovation comes along with think of that.... really good work.... tanq for this.....
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Selected Sessions from RailsConf 2007

  1. 1. Selected Sessions from RailsConf 2007 Jerry Richardson, Chief Technologist, iBlinkink
  2. 2. Clean Code • incremental improvement • always check code in better than you checked it out • never let the sun set on bad code • test first => quot;test obsessedquot; • provides the necessary flexibility
  3. 3. Robert Martin “I am not allowed to make a change that breaks the system. Every tiny change I make will keep that system working.”
  4. 4. 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
  5. 5. 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.
  6. 6. Professional Behavior • The quot;Green Bandquot; • 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
  7. 7. Doing REST Right Recognize 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)
  8. 8. 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.
  9. 9. REST isn’t... • Pretty URLs • CRUD • respond_to • map.resources • a protocol - http • an architecture
  10. 10. REST is... • the architectural style of the web • Roy Fielding's Hierarchy • Abstract => Communication Theory • REST • Web Architecture • Concrete => Implementation
  11. 11. 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.)
  12. 12. 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)
  13. 13. Post • post is neither safe nor idempotent => reserve it for when you need it
  14. 14. 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
  15. 15. Adding Tests to Legacy Rails Apps Most 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.
  16. 16. 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.
  17. 17. 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)
  18. 18. 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
  19. 19. Build Tests from Logs • Parameters then reproduce actual requests.
  20. 20. What To Test • right response code • correct template • variable assignment • assignment of desired object
  21. 21. Me. Questions?
  22. 22. Image Credits • DHH • Robert Martin • Scott Raymond • Evan (Rabble) Henshaw-Plath • Me