Taming Hydra (and Rails)

A call to action for addressing the meta-problems of software development in ProjectHydra.

Transcript

1. Taming Hydra and Rails
2. Introduction Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io This presentation is available http://goo.gl/1T3aJg
3. Rails: Convention over Configuration Hydra: Conforming to Standard Patterns Curate: Consensus Driven Features LDCX: Are We Doing a Good Job Sharing? Background Creative Commons Image: https://www.flickr.com/photos/sunshinecity/
4. Background / Rails “Follow a carefully curated set of opinions on how best to develop web applications with Rails and trust that it'll be good. Just like Rails itself is a carefully curated collection of APIs and DSLs.” David Heinemeier-Hansson http://david.heinemeierhansson. com/2012/the-parley-letter.html Emphasis is mine Creative Commons Image: https://www.flickr.com/photos/nomadic_lass/
5. Background / Hydra “We hope that by conforming to standard patterns it will be possible for you to maybe adopt further developments with a minimum of pain” – ProjectHydra.org http://projecthydra.org/design-principles- 2/ Emphasis is mine Creative Commons Image: https://www.flickr.com/photos/psilver/
6. Background / Curate “Curate is a Rails engine leveraging ProjectHydra and ProjectBlacklight components to deliver a foundation for an Institutional Repositories.” github.com/projecthydra-labs/curate Creative Commons Image: https://www.flickr.com/photos/jonmcgovern/
7. Background / LDCX 2014 “We are creating and sharing things and we don't know what we are receiving.” “One of the biggest benefits of Open Source is that you can fail fast.” “The path to sustainability for the Hydra Project is to embed our work in what people are actively doing.” “There are only a few people that know the core code well enough to make contributions to it. This raises the barrier of entry.” From LDCX 2014’s “Are We Doing a Good Job Sharing?” http://goo. gl/7y9wGK Creative Commons Image: https://www.flickr.com/photos/ticklefish/
8. It is “free” as in “free kittens,” not “free beer” – you still have to maintain it, and that’s where the overhead with software comes in. – K.G. Schneider http://freerangelibrarian. com/2006/10/16/south-africa-slis-follow- up-1-michael-stephens-web-20-and- libraries/ Observations Creative Commons Image: https://www.flickr.com/photos/ticklefish/
9. We Shall Not Be Crazy Cat People “And you may ask yourself Well...How did I get here? And you may say to yourself yourself My God!...What have I done?!” Talking Heads "Once in a Lifetime" Creative Commons Image: https://www.flickr.com/photos/dbarefoot/
10. As a software developer, I am charged with exploring and crafting solutions to problems. Can We Admit We Have a Problem? Creative Commons Image: https://www.flickr.com/photos/fmf0/
11. Determine What Is Our Problem Creative Commons Image: https://www.flickr.com/photos/sharynmorrow/1952092252 What are Project Hydra’s Problems? • Documentation? • Updatability? • Reusability? • Fragmentation? • Training? • Direction?
12. Single responsibility Open-closed Liskov substitution Interface segregation Dependency inversion Lets Have a Quick Solid Talk Creative Commons Image: https://www.flickr.com/photos/martyn/
13. “A class should have one, and only one, reason to change.” – Robert Martin http://www.butunclebob. com/ArticleS.UncleBob. PrinciplesOfOod Single Responsibility Principle Creative Commons Image: https://www.flickr.com/photos/oringebob/
14. “You should be able to extend a classes behavior, without modifying it.” – Robert Martin http://www.butunclebob.com/ArticleS. UncleBob.PrinciplesOfOod Open Closed Principle Creative Commons Image: https://www.flickr.com/photos/joybot/
15. “Derived classes must be substitutable for their base classes.” – Robert Martin http://www.butunclebob. com/ArticleS.UncleBob. PrinciplesOfOod Liskov Substitution Principle Creative Commons Image: https://www.flickr.com/photos/maenie/
16. “Make fine grained interfaces that are client specific.” – Robert Martin http://www.butunclebob.com/ArticleS. UncleBob.PrinciplesOfOod Interface Segregation Principle Creative Commons Image: https://www.flickr.com/photos/goingslo/
17. “Depend on abstractions, not on concretions.” – Robert Martin http://www.butunclebob.com/ArticleS.UncleBob. PrinciplesOfOod Dependency Inversion Principle Creative Commons Image: https://www.flickr.com/photos/fdecomite/
18. Determine What Is Our Problem Creative Commons Image: https://www.flickr.com/photos/sharynmorrow/1952092252 Now back to Project Hydra’s Problems… Let’s dive into Upgradability
19. Upgradability “There’s still a lot of noise in the view, mostly related to conditions and computations on the model objects. Let’s pull some of that into the model.” – Jamis Buck http://weblog.jamisbuck. org/2006/10/18/skinny-controller-fat- model Creative Commons Image: https://www.flickr.com/photos/chikawatanabe/
20. “Unfortunately we often find that developers try to treat [Active Record] data structures as though they were objects by putting business rule methods in them. This is awkward because it creates a hybrid data structure and an object.” -- Martin, Robert C. "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" Upgradability Creative Commons Image: https://www.flickr.com/photos/darwinbell/
21. Upgradability “Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions. The complement is also true: Procedural code makes it hard to add new data structures because all the functions must change. OO code makes it hard to add new functions because all the classes must change.” – Martin, Robert C. "Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)" And by extension, a thing that is both procedural code and OO code is going to a nightmare.
22. Upgradability “Using [app/concern mixins] is akin to “cleaning” a messy room by dumping the clutter into six separate junk drawers and slamming them shut. Sure, it looks cleaner at the surface, but the junk drawers actually make it harder to identify and implement the decompositions and extractions necessary to clarify the domain model.” – Bryan Helmkamp http://blog.codeclimate.com/blog/2012/10/17/7- ways-to-decompose-fat-activerecord-models/ Creative Commons Image: https://www.flickr.com/photos/candyheartsandpaperflowers/
23. “Many hands make light work.” – John Heywood Upgradability Creative Commons Image: https://www.flickr.com/photos/luxenography/
24. Upgradability Name and categorize things: • Models • Views • Controllers • Presenters • Forms • Policies • Services • Queries • Runners • Workers • ValueObjects Use your dictionary! Creative Commons Image: https://www.flickr.com/photos/wiertz/
25. Upgradability “Favor composition over inheritance.” – Eric Freeman, Elisabeth Freeman, Sierra Kathy, & Bates Bert “Head First Design Patterns” Creative Commons Image: https://www.flickr.com/photos/question_everything/
26. If your class inherits from another, you are signing a contract stating that when the ancestor changes, your class will also change. In other words, your object, begins life with with one reason for changing. And the Single Responsibility Principle says an object should have one reason to change. Therefore… Upgradability Creative Commons Image: https://www.flickr.com/photos/potatojunkie/
27. Upgradability “You gotta keep’em separated.” – The Offspring “Come Out and Play” Creative Commons Image: https://www.flickr.com/photos/tobifirestone/
28. Further Reading and Information Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin The Clean Coder: A Code of Conduct for Professional Programmers by Robert Martin ConfidentRuby.com by Avdi Grim Growing Object-Oriented Software, Guided by Tests by Steve Freeman & Nat Pryce’s Head First Design Patterns by Eric Freeman & Elisabeth Freeman Naught gem by Avdi Grim RubyTapas.com by Avdi Grim Practical Object-Oriented Design in Ruby by Sandi Metz Understanding the Four Rules of Simple Design by Corey Haines Writing Solid Ruby Code presentation by Jim Weirich Wyriki Rails application by Jim Weirich
29. Thank You Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io This presentation is available http://goo.gl/1T3aJg