Sand Piles and Software - Madison Ruby Conference
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Sand Piles and Software - Madison Ruby Conference

on

  • 840 views

This is a slightly varied version my previous Sand Piles and Software talk for the Madison Ruby Conference. Instead of including slides on the values, it incorporates a second part which is dedicated ...

This is a slightly varied version my previous Sand Piles and Software talk for the Madison Ruby Conference. Instead of including slides on the values, it incorporates a second part which is dedicated to decision making and some concrete areas where we can learn to help improve how we make decisions with code.

Statistics

Views

Total Views
840
Views on SlideShare
838
Embed Views
2

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 2

http://www.hanrss.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Sand Piles and Software - Madison Ruby Conference Presentation Transcript

  • 1. Sand Piles and SoftwareZach Dennis
  • 2. Part I
  • 3. Bak-Tang-WiesenfeldSand Pile Model
  • 4. macro from the micro
  • 5. What eventuallyhappens if you keep dropping grains of sand?
  • 6. It la nd sl id e s.
  • 7. Systems can only sustain so much stress.
  • 8. self-organized criticality A property of a system that has a critical state (point) as an attractor.
  • 9. Complexity critical point FunctionalitySoftware is attracted to its critical point.
  • 10. software is not linear X
  • 11. Complexity critical point FunctionalitySoftware is attracted to its critical point.
  • 12. software is non-linear
  • 13. Software feeds back into itself Sx = ... (Sx - 1)
  • 14. 0.2 compared to 0.2000000001
  • 15. Complexity critical point Functionality
  • 16. What we don’t want.
  • 17. Balanced and Distributed
  • 18. Sand Piles and Sand Boxes
  • 19. Complexity critical point The Vicious Stop n Go. Functionality Vicious Stop / Go Cycle
  • 20. Complexity critical point The Vicious Stop n Go. Functionality More effort initially.
  • 21. small app large appComplexity critical point The Vicious Stop n Go. Functionality Smaller apps get away with it.
  • 22. Performance = Complexity(Process) * Team * Tools
  • 23. bad processes amplify complexity good processes dampen it
  • 24. How do wekeep softwareaway from itscritical point?
  • 25. Part II
  • 26. Optimizeddecision making pathways
  • 27. def solve_problem(problem, knowledge) if quick_fix(problem).possible? quick_fix.go! else solve_problem problem, learn(problem) endend
  • 28. Problem Good None Little A lotUnderstanding Amount Random Intentional Nailed it Solution Quick fix Attempts
  • 29. If you do ______________ today,you’ll likely do ___________ tomorrow.If you don’t do ______________ today,you’ll likely won’t do ___________ tomorrow.
  • 30. Our brains don’t compute probabilitiesand then choose the best possible outcome when it can avoid it.
  • 31. Dependencies Cheeps Data StructureFile System Person Subscription DailyCheeper #cheep!Mobile Push Library - know about where and how to load cheeps data - know about how person is related to - know about subscriptions - know about time zone conversion - know about about to use mobile push library - localizations???
  • 32. Dependencies after balancing responsibilities Person Subscription DailyCheeper #cheep! - knows how to determine eligibility based on subscription - knows how to use cheeps data Mobile Push - knows how to use Person Cheeps File System Library interface to find eligible subscribers - knows how to use mobile push - message_for_day library - localization for accessing cheeps
  • 33. Let’s improve our decision pathways
  • 34. Domain complexityConceptual complexityCode complexity
  • 35. Properties and conceptsfor practical applicationCohesion Exposing Crisp Abstractions / Responsibility /Coupling Concepts Dependencies /Connassence Testability Collaborators /Entanglement Boundaries Naming, Concepts Composition Shared Understanding Inheritance Pattern Language Mixins Reflection
  • 36. Cohesion the focus of an individual software component given its function or purpose to exist Array#push Cheeper#delivery_daily Cheeps#load Array#pop Cheeper#delivery_weekly Cheeps#add Array#[] Cheeper#deliver_monthly Cheeps#save Array#count Cheeps#remove Array#<<
  • 37. Not very cohesive
  • 38. Separating out concepts
  • 39. Coupling The relationship between software components, theextent to which a component of our software depends on other components. Cheeps Data StructureFile System Person Subscription DailyCheeper #cheep!Mobile Push Library
  • 40. Connassence a single measure combining coupling and cohesion,measured in terms of strength or weakness (preferred) weaker Name Type Meaning Position http://en.wikipedia.org/wiki/ Connascent_software_components Algorithm Execution http://vimeo.com/10837903 Timing http://onestepback.org/articles/connascence/ Identity index.html stronger
  • 41. Being explicit Making concepts and abstractions in your application (technical or domain related) first-class citizens.
  • 42. Extracting a Conceptw/a distinct responsibility
  • 43. Explicit abstractionshttps://github.com/raganwald/homoiconic/blob/master/ 2009-10-08/metalinguistic.md
  • 44. Rake ActiveModel::Validations ActiveRecord::RelationActionController filters (orthogonality) Whenever (gem) Capybara
  • 45. Directed Acyclic Graphhttp://en.wikipedia.org/wiki/Directed_acyclic_graph
  • 46. TestabilityTestable components are typically simpler components.
  • 47. Testability - simpler objects - simpler interfaces - lower number of unnecessary dependencies - push external system interaction to the edge, isolate when possible - remove unnecessary conditionals when possible - promotes simpler code and more distributed, balanced set of responsibilities - stub less, mock less, spy only when necessary
  • 48. Testability
  • 49. Responsibility / Dependencies /Collaborators / Boundaries - Write a statement describing the responsibility a class or module. If there are a bunch of ANDs consider it suspicious. - Identify “what” your object needs to fulfill that responsibility - Identify your collaborators to meet those needs - Identify boundaries for primary dependencies and everything else
  • 50. Good statement:## The DailyCheeper is responsible for sending mobile notifications via SMS# to people have subscribed to them.#Suspicious statement:## The DailyCheeper is responsible for sending mobile notifications via SMS# to people have subscribed to them, building reports around cheeps statistics,# subscribing users to cheeps, and updating/saving cheeps.#
  • 51. Dependencies list: - find people who are eligible and have subscribed to receiving cheeps for given time - take into account timezones - find out if locales/translations are necessary - get/retrieve access to today’s cheep to send - mobile library for sending out cheeps - access to device_id (can get off from person)
  • 52. Identify collaborators Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Primary collaborators Secondary collaborators
  • 53. Identify boundaries Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Unit testing scope
  • 54. Identify boundaries Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Unit testing scope
  • 55. Naming, Concepts- Semantic CustomersController#create- Appropriate for level ofabstraction Customer#create- Classes, modules, methods, ConnectionPool#connectionvariables- Avoid redundancy, ambiguity MySQLAdapter#insert_sql
  • 56. Shared Understanding /Pattern Languages- Make conventions and patterns an explicit part of yourvocabulary- Make them up, or re-use useful patterns, etc you’ve found- Evaluate, share, teach, learn
  • 57. A few we use: - Ruby module pattern for inheritance (for chaining behavior in a loosely coupled way, ie: ActiveRecord uses this pattern a lot when for #save) - Constructor injection (for providing defaults but allowing object to be more easily testable) - Boundaries (for creating a clear distinction between one part of the application and another, ie: Api, Kernel, and Border) - Splatting/flattening conditionals (to indicate a conditional, branch of code, should not exist, investigate ways to remove it) - Everything’s private until it’s public - No class variables (they should be banished)
  • 58. Ruby module pattern example
  • 59. Boundaries example (API/Library) Intuit::Api Intuit::Kernel Intuit::Border Customer Customer Customer Employee Employee Employee Vendor Vendor Vendor Configuration QueryDSL Connection ... ... QBQL ... Mapping, additional Public API for Barebones Intuit Definitions functionality, Intuit Consumers fixes
  • 60. Boundaries example (Web App, generic) Application Domain Delivery ORM Domain Services Application Services Infrastructure
  • 61. Request comes in to find an Order Application Domain Delivery ORM Domain Services Application Services Infrastructure
  • 62. Request comes into to process batch oforders Application Domain Delivery ORM Domain Services Application Services Infrastructure
  • 63. Request comes into to process batch of orders,then notifies customer who placed order. Application Domain Delivery ORM Domain Services Application Services Infrastructure
  • 64. Classes, Mixins, Inheritance, andComposition - Classes are great for representing entities and things which have instances (Well-Grounded Rubyist) - Mixins are great for characteristics or properties of entities, cross-cutting concerns, explicit grouping of functionality - Composition is a often under-used. You create a new class/ object and pass in an existing one as a collaborator/dependency.
  • 65. Composition- full control over your object and API- reduces the ripple effects of change if the API of theobject you’re composing changes- removes dependencies on parent objects you may ormay not own- simplifies testing because you own it and itsdependencies
  • 66. Reflection - Give yourself time to reflect - Personal growth - Make mid-course corrections - Keep complexity down - if you’re only focused on add, add, add, then you don’t give yourself time to do that
  • 67. Values overP r a c t i c e s
  • 68. If you actively seekways to exploit yourvalues, practices will come naturally.
  • 69. <insert here>good bad
  • 70. Practices change more oftenthan values.
  • 71. Complexity critical point The Vicious Stop n Go. Functionality More effort initially.
  • 72. May the landscape of yoursoftware be smooth rolling hills. twitter: @zachdennis github: zdennis mutuallyhuman.com Sand Piles & Software Article in April PragPub