Ruby Meditation #15 May 13, 2017 Dnipro, I Coworking Hub

1. Tricks for Isolated
Architecture in Ruby
Ruby Meditation #15, May 13 2017

2. I am Sergiy
And I’ve been searching a silver bullet for a while
BTW, my twitter is @sergey_kukunin
Hello!

3. I work at , Lviv

5. The Humble Programmer
“we shall be able to design and implement the
kind of systems that are now straining our
programming ability, at the expense of only a few
percent in man-years of what they cost us now,
and that besides that, these systems will be
virtually free of bugs”
by Edsger W. Dijkstra, 1972, http://bit.ly/2pHGbhF

6. The Humble Programmer
● intellectually manageable programs
● proof of correctness
● the amount of intellectual effort depends on
the program length
● the influence of the tool we are trying to use
upon our own thinking habits
● hierarchy

7. The Humble Programmer
“In computer programming our basic building
block has an associated time grain of less than a
microsecond, but our program may take hours of
computation time. I do not know of any other
technology covering a ratio of 1010
or more”

8. Two values of software
The secondary value of software is its behavior.
1
Defined by Uncle Bob Martin in episode 9 (‘The Single Responsibility
Principle’) of his CleanCoders video series

9. The primary value of
software is that it’s soft.
The ability of software to tolerate and facilitate such ongoing change is
the primary value of software.
2

10. Conclusions
● Programming is complicated
● Programming is risky
● Programming is expensive
That’s why we should care about what we write.

11. Symptoms of Rotting Design
◉ Rigidity - the tendency for software to be difficult to change
◉ Fragility - the tendency of the software to break in many places every
time it is changed
◉ Immobility - the inability to reuse software from other projects or from
parts of the same project
◉ Viscosity - two forms: viscosity of the design, and viscosity of the
environment
http://bit.ly/2rawutr

12. Other criterias
◉ Deployability
◉ Developability
◉ Comprehensibility

13. Every technique has own advantages and
overhead. Sometimes, a technique doesn’t fit.
You’re the one who is solely responsible for
the code quality of your project.
Disclaimer:

14. “
The main enemy of software is
complexity. To remain
maintainable, software should be
simple.

15. Complexity grows as
application grows1

16. The biggest impact is made
by solution modularity

17. Analyze of Sorting algorithms
Bubble sort = O(N2
)
When N = 60, N2
= 3600
If we divide an array into two halves
we’ll have 2 * (N/2)2
= 2 * (302
) = 1800

18. Divide and Conquer

19. Divide and Conquer

20. Single Responsibility Principle
● Definition of responsibility
○ Should have only one reason to change file
● Works on class level as well as on module level
● + Decreases rigidity
● + Necessary step for modularity

21. Examples of SRP
● Localization
● Thread handling
● HTML/CSS/JS
● Interactors

22. Rely on interface, not on
implementation

23. Example of interface

24. The less a module knows about siblings,
the more independent it is.
Keep encapsulation

25. Law of Demeter
might indicates that current class knows too
much. Does this look better?

26. Dependency Inversion Principle
● High-level policy should not be dependent
upon low-level detail
● Main trick for decoupling
● + Decreases rigidity
● + Improves modularity/deployability
● + Better testing
● - Lines of code overhead

27. How it works: DI

28. How it works: DI

29. Dependency Injection

30. Isn’t this violation of
encapsulation?

31. Integration of modules

32. IoC
1 ● Separates the application from the main.
● Fixes dependencies order.
● Decouples modules and classes.
● Decreases rigidity of the application.

33. Should be iterative, small and often
Constant Refactoring

34. Boyscout Rule

35. Functional programming

36. Because functions are data
First-class functions

37. Composability

38. Immutability

39. First-class tests
● Tests are proof of correctness
● They make you feel safe while refactoring
● Tests drive better design
● Tests should be trustful
● Tests should be fast

40. Test-driven development
1. You are not allowed to write any production
code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a
unit test than is sufficient to fail; and
compilation failures are failures.
3. You are not allowed to write any more
production code than is sufficient to pass the
one failing unit test.

42. “
The only way to keep it simple is
to make composition of
abstractions

43. Simple software is
readable software2
We read code even when we write code

44. Micro-level
◉ Small classes
◉ Small methods
◉ Intention-revealing
methods
◉ Consistent indentation
Readability
Macro-level
◉ Ubiquitous language
◉ Unified model
◉ Domain-driven design

45. DDD separates
domain-related code
from platform-related
2

46. Domain layer: dry-types
1 ● Prevention of illegal state
● Types algebra
● Immutability
● Blazing fast

47. Application layer: CQS
1 defines application boundaries: data inside are trusted

48. Infrastructure layer
1 ● Independent implementations of 3rd-party
services
● The easiest to extract to a gem
● Persistence is here

49. UI layer
1 ● An interface for interactive for the application
● HTTP delivery mechanism
● Validation is tied to an interface, not to an entity
● dry-validation

50. Persistence layer: ROM
1 ● Adapters
● Relations
● Mappers
● Repositories

51. Other advices
◉ Prefer instance methods over class methods
◉ Avoid singletons and global state
◉ Prefer pure functions

52. Real experience

53. Any questions ?
You can find me at
◉ @sergey_kukunin
◉ sergiy@maticinsurance.com
Thanks!