This document discusses the Don't Repeat Yourself (DRY) principle of software development. It advocates separating business logic code from technical code to allow each to evolve independently and enable reuse. Attributes and domain-specific languages can be used to describe aspects to a technical engine that automates common functions, preventing redundant code and maintaining independence between layers. Maintaining orthogonality and identifying invariants are keys to enabling reuse according to the document.

1. Taking DRY seriously
@FredyFadel
Aspectize.com

2. Without data
you are just another person
with an opinion.

3. Without opinion
you are a person just
with another dataset.

8.  From punch cards to Javascript
 more than 35 years of daily programming
 Co-Founder of two companies :
 Winwise (1993-2008)
 Aspectize (2007- always running)
 @FredyFadel
 http://www.scoop.it/t/web-tools-and-technologies

9. Code
DRY
Technical
NonTechnical
Separation

10. The thing, the job and it’s problems

11. Do we have any ?

12. …

13. Trying hard to do things right
but
We are not doing the right thing

14. It’s difficult.

15. HUMANS MACHINES
Ambiguities

16. Automating
As much as possible but not more
Human  Machine
Valuable information  Irrelevant details

17.  The computer revolution hasn't happened yet.
 OOPSLA - Alan Kay : 1997
 The real computer revolution hasn't happened yet.
 Education - Alan Kay : 2007
 Software is eating the world (Marc Andreessen : 2011).
 Books, Music,Video, Entertainment, Photography, Recruitment…
 And it’s just the beginning.
 First time in history we have a global many to many communication system
and it’s software.

18.  While describing your job, would you use the word growing ?
 Do you grow software ?
 Things that grow
 Cities, plants…
 Networks :The internet, theWeb, communication end points…
 Data : it’s shape, it’s volume
 Ceremonial complexity : Often due to code it’s shape, it’s volume
 Cars don’t grow : they are “born” dead

19. I'm not against types, but I don't know of
any type systems that aren't a complete
pain, so I still like dynamic typing.
Actually I made up the term "object-oriented",
and I can tell you I did not have C++ in mind.
Alan Kay

20. Dynamic
Slow
Continuous
Non stop
Class
Code

21. Deliverable at any time
Never finished

22. Is about automating
What is repeatable and valueless
Machines are good at repeating
Valuable best practices
It could be business oriented or technical.
But yet not interfering with intelligent choices
It’s distinguishing the invariant from the variable.

23. Eliminating
Waste
Cumbersome work
It’s about removing “redundancies”
Logical redundancies
It’s not about factoring code

24. Work less, do moreAutomation
It’s not about code
it’s about connections

25. Have nothing to do with code

26. Solving the puzzle
Rotating sides

27. Directing the flow of
information between humans
and machines

28. Reuse, DRY andWET

29. Do you have the impression of repeating yourself ?

30.  Repeating can be fun and lucrative
 You gain knowledge and expertise (at least in the beginning)
 You can maintain an impression of knowledge and expertise
 The widespread Not Invented Here syndrome
 You can easily mess up reuse
 left-pad story in node community
 “A little copying is better than a little dependency”

31. Write Everything Once
Is as dumb as
WET ==Write EverythingTwice

32. Is reusable what is reused
We reuse every day
tools, ideas, code others have written, resources…
We reuse because it’s seamless and has value

33. Habit
Even when it’s not seamless
Changing habits is expensive
Imitation
Surfing the buzz waves

34.  Best example
 Operating system
▪ Language independent
▪ Code independent
 Even better example
 Browser
▪ “Language independent”
▪ Operating system independent

35. Every piece of knowledge must have a
single, unambiguous, representation
within a system.
The Pragmatic Programmer

36. Taking Orthogonality Seriously

37.  Reuse is impossible if the reusable is not identified
 If the invariant is not identified
 If the independent is not identified
 Orthogonal is just a fancy way of saying independent
 The reusable won’t be reused if reuse is not more or less
seamless

38.  The invariant is what can be reused if it’s totally separated
from the variable (from the non reusable)
 The reuse of the invariant can be automated to make it
seamless
 AOP is a technique of automating the invariant.

39.  Separating what
 Business oriented code
 Technical code
 Because they are clearly independent
 Each have their own invariants
 Each evolve in their own pace

40.  Some technical invariants
 Network, bytes and clicks
 JSON, HTTP, SQL,Authentication, Browsers, Devices…
 Some business variable
 UX
 Data (it’s shape)
 Processes

41. HOW ?

43. Don't
call us
We'll
call you
Technical code calls business code

44.  Some history
 1997 MicrosoftTransaction Server (MTS)
▪ Declarative runtime attributes
 2000 COM+
▪ More attributes
 2002 .net
▪ Declarative and programmable attributes

45.  Attributes
 Create your own or use existing
 Tying
 the attribute to your code
 Engine (middle ware)
 to operate the magic (to automate)

46.  Some existing examples
[Conditional("DEBUG")] voidTrace (string msg) { …; }
[PrincipalPermission (SecurityAction.Demand, Role = "Admin")]
public DataSet LoadAdminData () { …; }
[assembly:InternalsVisibleToAttribute("YourAssembly, PublicKey=8b…ff")]
 Some potential examples
[DateValidator("yyyy-MM-dd")]TextBox birthDay = newTextBox ();
[Command(BrowserCacheDuration = "30 Minutes")]
doubleTemperature (string city);

47.  The mighty TransparentProxy
 A transparent proxy is an object that can simulate any interface !
 Easy to implement
▪ Less than 50 lines of C#
▪ You just need to implement it once in your life
 Enables you to intercept all calls and provide valuable orthogonal
technical services through aTechnical Engine.

48.  .net attributes are fine for technical aspects that require a
small amount of information
 For more sophisticated aspects a DSL can be used to load
information into theTechnical Engine.
 DSL example : Gherkin in Cucumber.

49.  Integrated inVisual Studio
 Graphical DSL for describing
▪ The shape of Data
 Textual DSL for describing bindings
▪ Data
▪ Command
▪ Layout

50.  A JavascriptTechnical Engine that automates
 Producing HTML in the browser
 Sending/Receiving Data
 Manging State
 A .netTechnical Engine that automates
 Reading/Writing Data
 Azure integration

51. Load Information
Payment
Save Information
Business operation
Technical
Engine
Load Information
Payment
Save Information
Business operation
Technical
Engine

52. http://www.meetup.com/fr-FR/Aspectize-Paris-Meetup/
Next one is on may 19th @ 5:30pm hosted by Microsoft
Issy les Moulineaux