Your SlideShare is downloading. ×
  • Like
  • Save
Better Ruby Through Design Principles
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Better Ruby Through Design Principles


A talk given at Mountain West Ruby Conf 2012 about software design in Ruby.

A talk given at Mountain West Ruby Conf 2012 about software design in Ruby.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Apps change because their requirement change.
  • This is why you should pay attention to design, it pays off in the long run.So if you feel like your app is going to not be around that long then you can stop listening.
  • Show file_processor2.rb and file_processor2a.rb.
  • These are principles, not hard and fast rules.Sometimes they conflict with other principles or just don’t make sense.
  • Thanks to the conference organizers.Thanks to you all for listening.Thanks to the Boulder Ruby Group, especially David Hassler, for improving this talk via feedback.


  • 1. Better Ruby Through Design Principles@mikegehard Lead – User AcquisitionLivingSocial
  • 2. "Nothing endures but change.”Heraclitus of Ephesus (c.535 BC - 475 BC)
  • 3. Thats great but how does that applyto Ruby?
  • 4. Is my application going to change?
  • 5. How is your application going to adjustto change?
  • 6. What decides how your app is going torespond to change?
  • 7. The design (1)
  • 8. The interactions between classes (2)
  • 9. Im using Rails so I dont need to do design
  • 10.
  • 11. Processing Requirements1.Parse a CSV file2.Report status of the parsing via email
  • 12. Processing Requirements Week Two1.Parse either CSV or TSV file2.Report status of the parsing via email
  • 13. What is the difference?
  • 14. FileProcessor is no longer responsiblefor file parsing.
  • 15. FileProcessor can parse new file typeswithout having to change.
  • 16. Testing of parsing can be done inisolation.
  • 17. Processing Requirements Week Three1.Parse either CSV or TSV file2.Report status of the parsing via Email or SMS
  • 18. What is the difference?
  • 19. Each class is responsible for one thing.
  • 20. Reporters are functionallyinterchangeable and reusable.
  • 21. Contracts between FileReporter andsupporting objects are small and easyto learn.
  • 22. Testing of reporting can be done inisolation.
  • 23. Future Processing Requirements1.Download file from FTP site or Dropbox.2.Parse either CSV, TSV or PDF files3.Report status of the parsing via Email, SMS or Nagios.
  • 24. SOLID
  • 25. Single Responsibility Principle
  • 26. Open for extensionClosed to modification
  • 27. Liskov Substitution Principle
  • 28. Interface Segregation
  • 29. Dependency Inversion
  • 30. Your mileage may vary (3)
  • 31. Image Attributions(1)••••••
  • 32. Any questions? (4) @mikegehard