Sipity: Patron Oriented Deposit

Sipity is a patron-oriented deposit interface into CurateND. At least that is what it started out as...

Sipity is an evolving modular workflow tool for Notre Dame’s library; And I hope others.

Presented at LDCX 2015

Transcript

1. Sipity: Patron Oriented Deposit
2. Introduction Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io Presentation at http://goo.gl/4g44F4
3. Sipity is a patron-oriented deposit interface into CurateND. At least that is what it started out as... Sipity is an evolving modular workflow tool for Notre Dame’s library; And I hope others. What is Sipity?
4. But What Does Sipity Do? Receive Notification Complete Todo Items Mark Items as Completed
5. But What Does Sipity Do? Sipity guides a group of collaborators: depositors, approvers, catalogers, etc., through the preparatory steps of depositing a work wortem PCDM work.
6. Technical Demo A Quick Technical Demo…see the lightning talk
7. The Workflow untitled https://www.flickr.com/photos/76804652@N02 Rapid Workflow Development
8. Regardless of planning, our shared understanding of the workflow kept drifting The Workflow “planning poker warm up” https://www.flickr.com/photos/fsse-info
9. As it drifted I had to keep updating the • working prototype • documentation I hate updating “what is happening” documentation Because I see the code as the authority on what is happening The Workflow “I said “I'm busy!”” https://www.flickr.com/photos/stitch
10. The Workflow “Fortune Telling Wax Robot Gypsy Grandma 4296” https://www.flickr.com/photos/93779577 No matter how hard our team tried, our understanding of what is needed for the workflow kept changing overtime. We needed to reduce the impact of those changes on our development process.
11. The Workflow The workflow’s state machine – states, actions, guards, and permissions – are defined by several database entries. The diagram on the right is the state machine for our ETDs: $ rails runner scripts/processing_to_dot.rb > etd-workflow.dot $ open etd-workflow.dot
12. The Workflow What happens for a given action is still defined within the code: • Required fields • Related data should be updated/changed • Who receives what notification ‡ ‡ This is moving to the database
13. Users, Groups, Collaborators “Immigrants Arriving at Ellis Island 1911” https://www.flickr.com/photos/83508181@N00 People and Groups of People
14. Users, Groups, Collaborators “Many mani” https://www.flickr.com/photos/roberto_ferrari Collaboration of Different Units • Individuals • Groups • Non-university individuals All at differing degrees of participation And at differing times
15. Users, Groups, Collaborators No matter how hard our team tried, our understanding of what is needed for user permissions kept changing overtime. We needed to reduce the impact of those changes on our development process.
16. Users, Groups, Collaborators “Actor” https://www.flickr.com/photos/47476117@N04 Enter stage left, the processing actor: A proxy for something that can participate in the workflow process of Sipity.
17. Users, Groups, Collaborators “Boundary” https://www.flickr.com/photos/batiks In creating the processing actor, Sipity exposes a narrow interface to allow us to introduce our own: • User management system • Group management system • User’s that act on behalf of someone And swap in an upcoming new system
18. Users, Groups, Collaborators
19. The Design “Actor” https://www.flickr.com/photos/47476117@N04 No matter how hard our team tried, our understanding of what is needed keeps changing overtime. We need to reduce the impact of those changes on our development process.
20. The Design https://speakerdeck.com/jeremyf/taming-hydra-and-rails From Hydra Connect Remember this presentation ? goo. gl/CCNHNx
21. The Design “NYC - Queens - LIC: 5 Pointz - You're Entering a World of Pain” https://www.flickr.com/photos/wallyg We spent time looking at the pain points of our previous projects and collaborations. And I’d like to show you some of our reflections.
22. The Design “Painful Stab Wounds Heal My Soul, I Beg for Mercy” https://www.flickr.com/photos/thirtyfootscrew Conjecture: That which is painful to test is painful to change. Therefore, reduce the pain in testing.
23. The Pain Exhibit 1: A somewhat typical Rails controller’s action
24. The Pain “090820-A-4902A-154” https://www.flickr.com/photos/usag-miami Who likes testing Rails controllers?
25. The Pain “junk drawer - before“ https://www.flickr.com/photos/merrymishaps Controllers have too many responsibilities. Lets go through them.
26. The Pain Authentication Who am I?
27. The Pain Authorization What can I do?
28. The Pain Request parameters What am I allowing and expecting to receive?
29. The Pain Collaboration with domain model What is the interaction with the underlying domain?
30. The Pain Content Negotiation What will the requesting agent accept in response?
31. The Pain Before Action What needs to happen before a public method is called?
32. The Pain Human vs. Machine Response What is the HTTP status? What is the message to send to the user?
33. The Pain Cache Control What are the etags and cache headers that we want to set?
34. The Pain This is a far cry from Single Responsibility… It is the intersection of numerous disparate concerns.
35. A Solution to the Pain “The Corner of Church and State” https://www.flickr.com/photos/wy_jackrabbit Decompose the Responsibilities
36. A Solution to the Pain The controller negotiates HTTP inputs and outputs
37. The runner composes: - authentication layer - authorization layer - repository layer It is HTTP agnostic A Solution to the Pain
38. And so on…composing many collaborators that implement and interact with narrow interfaces A Solution to the Pain
39. How about an Entity Relationship Diagram Here’s an ERD http://ndlib.github.io/images/sipity-processing-erd.png
40. We can dive deeper into the code if you are inclined? Or answer questions? Further Down the Rabbit Hole “Has he gone yet?” https://www.flickr.com/photos/jm999uk
41. Thank You Jeremy Friesen Digital Library Frameworks Specialist University of Notre Dame jfriesen@nd.edu @jeremyfriesen github.com/jeremyf ndlib.github.io This presentation available at http://goo.gl/4g44F4