Your SlideShare is downloading. ×

Selected Sessions from RailsConf 2007

2,118
views

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

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

2 Comments
2 Likes
Statistics
Notes
  • 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 www.freeringtones.ws/ . Hope to see more quality slides from you.

    Best wishes.
       Reply 
    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.....
    Anisa
    http://financejedi.com http://healthjedi.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,118
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
58
Comments
2
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Selected Sessions from RailsConf 2007 Jerry Richardson, jerry@jerryr.com Chief Technologist, iBlinkink
  • 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. 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. 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. 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. 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. 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. 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. REST isn’t... • Pretty URLs • CRUD • respond_to • map.resources • a protocol - http • an architecture
  • 10. REST is... • the architectural style of the web • Roy Fielding's Hierarchy • Abstract => Communication Theory • REST • Web Architecture • Concrete => Implementation
  • 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. 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. Post • post is neither safe nor idempotent => reserve it for when you need it
  • 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. 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. 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. 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. 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. Build Tests from Logs • Parameters then reproduce actual requests.
  • 20. What To Test • right response code • correct template • variable assignment • assignment of desired object
  • 21. Me. Questions?
  • 22. Image Credits • DHH http://flickr.com/photos/x180/503574487/ • Robert Martin http://flickr.com/photos/x180/503608084/ • Scott Raymond http://flickr.com/photos/keeg/511239686/ • Evan (Rabble) Henshaw-Plath http://flickr.com/photos/x180/474128166/ • Me http://flickr.com/photos/jackdanger/502998700/