Sand Piles and Software - Madison Ruby Conference

1,098 views

Published on

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.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,098
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
9
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Sand Piles and Software - Madison Ruby Conference

  1. 1. Sand Piles and SoftwareZach Dennis
  2. 2. Part I
  3. 3. Bak-Tang-WiesenfeldSand Pile Model
  4. 4. macro from the micro
  5. 5. What eventuallyhappens if you keep dropping grains of sand?
  6. 6. It la nd sl id e s.
  7. 7. Systems can only sustain so much stress.
  8. 8. self-organized criticality A property of a system that has a critical state (point) as an attractor.
  9. 9. Complexity critical point FunctionalitySoftware is attracted to its critical point.
  10. 10. software is not linear X
  11. 11. Complexity critical point FunctionalitySoftware is attracted to its critical point.
  12. 12. software is non-linear
  13. 13. Software feeds back into itself Sx = ... (Sx - 1)
  14. 14. 0.2 compared to 0.2000000001
  15. 15. Complexity critical point Functionality
  16. 16. What we don’t want.
  17. 17. Balanced and Distributed
  18. 18. Sand Piles and Sand Boxes
  19. 19. Complexity critical point The Vicious Stop n Go. Functionality Vicious Stop / Go Cycle
  20. 20. Complexity critical point The Vicious Stop n Go. Functionality More effort initially.
  21. 21. small app large appComplexity critical point The Vicious Stop n Go. Functionality Smaller apps get away with it.
  22. 22. Performance = Complexity(Process) * Team * Tools
  23. 23. bad processes amplify complexity good processes dampen it
  24. 24. How do wekeep softwareaway from itscritical point?
  25. 25. Part II
  26. 26. Optimizeddecision making pathways
  27. 27. def solve_problem(problem, knowledge) if quick_fix(problem).possible? quick_fix.go! else solve_problem problem, learn(problem) endend
  28. 28. Problem Good None Little A lotUnderstanding Amount Random Intentional Nailed it Solution Quick fix Attempts
  29. 29. If you do ______________ today,you’ll likely do ___________ tomorrow.If you don’t do ______________ today,you’ll likely won’t do ___________ tomorrow.
  30. 30. Our brains don’t compute probabilitiesand then choose the best possible outcome when it can avoid it.
  31. 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. 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. 33. Let’s improve our decision pathways
  34. 34. Domain complexityConceptual complexityCode complexity
  35. 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. 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. 37. Not very cohesive
  38. 38. Separating out concepts
  39. 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. 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. 41. Being explicit Making concepts and abstractions in your application (technical or domain related) first-class citizens.
  42. 42. Extracting a Conceptw/a distinct responsibility
  43. 43. Explicit abstractionshttps://github.com/raganwald/homoiconic/blob/master/ 2009-10-08/metalinguistic.md
  44. 44. Rake ActiveModel::Validations ActiveRecord::RelationActionController filters (orthogonality) Whenever (gem) Capybara
  45. 45. Directed Acyclic Graphhttp://en.wikipedia.org/wiki/Directed_acyclic_graph
  46. 46. TestabilityTestable components are typically simpler components.
  47. 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. 48. Testability
  49. 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. 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. 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. 52. Identify collaborators Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Primary collaborators Secondary collaborators
  53. 53. Identify boundaries Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Unit testing scope
  54. 54. Identify boundaries Load Cheeps from FileSystem Cheeps Mobile Push DailyCheeper Library Person Subscription Unit testing scope
  55. 55. Naming, Concepts- Semantic CustomersController#create- Appropriate for level ofabstraction Customer#create- Classes, modules, methods, ConnectionPool#connectionvariables- Avoid redundancy, ambiguity MySQLAdapter#insert_sql
  56. 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. 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. 58. Ruby module pattern example
  59. 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. 60. Boundaries example (Web App, generic) Application Domain Delivery ORM Domain Services Application Services Infrastructure
  61. 61. Request comes in to find an Order Application Domain Delivery ORM Domain Services Application Services Infrastructure
  62. 62. Request comes into to process batch oforders Application Domain Delivery ORM Domain Services Application Services Infrastructure
  63. 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. 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. 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. 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. 67. Values overP r a c t i c e s
  68. 68. If you actively seekways to exploit yourvalues, practices will come naturally.
  69. 69. <insert here>good bad
  70. 70. Practices change more oftenthan values.
  71. 71. Complexity critical point The Vicious Stop n Go. Functionality More effort initially.
  72. 72. May the landscape of yoursoftware be smooth rolling hills. twitter: @zachdennis github: zdennis mutuallyhuman.com Sand Piles & Software Article in April PragPub

×