Writing aframework for fun  @jhugman – James Hugman
Not him again    • Software Engineer in industry for      10y+    • Written:      • Compilers, Reasoning Engines,        E...
Contents    • Why should I care    • Words shape thought    • Rules for enablers    • Developers are users too@jhugman
Anti-Contents    • A specific technology    • The importance of encapsulation    • An exhaustive list of anything@jhugman
Why should I care?      Why would I want to write a framework?@jhugman
Your role changes    • Tool user    • Tool maker@jhugman
@jhugman   Status
Architect@jhugman   Status
What happens at@jhugman  work…
What happens at@jhugman  work…
@jhugman   It feels like…
@jhugman   It feels like…
Words Shape            Thought     Identifiers, Little Languages and Patterns@jhugman
Words shape             thought    • Find language that describe the      concepts    • Break concepts into smaller nouns ...
Words shape             thought    • Make your code out of this language      e.g. identifiers    • Build your code bottom ...
Words shape             thought    • Over-generalizing is double-plus-      ungood      • process()      • apply()      • ...
Words shape             thought    • Wrong words require double-think@jhugman
Why Language             Matters    • Thought-to-code gap    • More readable code    • Better intra-team communication    ...
Other People’s               DSLs    • Integrate existing little languages      with your framework      • e.g. SQL, XPath...
Definitional            Interlude    • Framework vs Toolkit   (Hollywood Principle)@jhugman
Extendable systems    Architect like you have a plugin mechanism@jhugman
Plugin systems    • Modularity above the package level    • Assume you have a plugin system,      even if you don’t@jhugman
Rules for Enablers    • Invitation Rule – Whenever possible, let others      contribute to your contributions    • Fair Pl...
Rules for Enablers    • Explicit API Rule - separate the API from      internals.    • Defensive API Rule - Reveal only th...
Architect for            Participation    • Requirements change, new features      added    • Multiple uncoordinated teams...
Example           Architecting for growth@jhugman
House Numbers    • Physical world example      • A street, where houses will be      • How should we number the        hou...
House numbers   •Sequential   •Row at a time   •Simple at     1   2          3   4    build time            road   •Not   ...
House numbers   •Sequential   •Odds/Evens   •Extendable in 1   3          5   7    one direction         road   •Assumes n...
House numbers   •Distance    from one end   •Large scale                   10300             17010   •Navigable           ...
Developer UX            Developers are users too@jhugman
Developer pain kills    • Everything should be obvious    • A good mental model@jhugman
API Usability    • Design APIs upfront (almost BDD for      APIs)    • Seek feedback from real developers    • Prototype, ...
Related    • Paper prototyping      • README driven development      • Commit-log driven development@jhugman
Summary    • Words shape thought    • Build in extensibility, early    • Think hard about developer      experience@jhugman
Further Study    • Graduates/Juniors:      • Effective Java   Josh Bloch      • Huston Design Patterns                  (a...
Further Study    • Principles of Newspeak            George Orwell    • Growing a Language         Guy Steele    • The Art...
Podcasts    • Java Posse    • this developer’s life    • Hacker News Pod    • Software Engineering Radio@jhugman
Thanks           @jhugman – James Hugman@jhugman
Discuss             AMA@jhugman
@jhugman
Upcoming SlideShare
Loading in...5
×

Writing Frameworks for Fun and Profit

296

Published on

This was a presentation given at Droidcon India 2012. It was by request of the organizers as a masterclass in writing frameworks and toolkits.

It turned out to be quite a reflective talk on software design and its philosophy as discovered by the author.

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

  • Be the first to like this

No Downloads
Views
Total Views
296
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • This is not just about encapsulation.\n
  • This is not just about encapsulation\n\n I’ve learned over my career, distilled into an early morning talk.\n
  • \n
  • \n
  • * Day-to-day: Tool-user --> Tool maker.\n * Status/Prospects: Jobbing builder --> Architect\n * Type of work: Soldier --> Scientists.\n * How I feel: Soldier ant --> Really Happy Dolphin\n
  • If status is all you care about, we have a different problem.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Notice this is quite top-down. But we can do this for even low-level sub-systems.\n
  • Find language that describes the concepts of what you're doing.\nMake your code out of this language. \nNever settle for the over genral. process() apply() execute() doStuff() giesPeas()\nBreak down the concepts into smaller nouns.\nName your identifiers to follow this.\nBuild little languages.\n
  • Never settle for the over general. process() apply() execute() doStuff() giesPeas()\n\nNewspeak joke\n\n
  • When identifiers and concepts are not closely matched, you need to have two different (and perhaps conflicting) ideas in your head at once.\n
  • Using the right words\n\nBugs are harder to write because\n * tests are easier to write, \n * the code is more readable.\n\nThis can apply to any layer of abstraction.\n
  • Design patterns are explicitly designed to provide a shared vocabulary\n\nIntegrate: you don’t have to re-invent everything.\n
  • Now we know the importance of words :)\n
  • There are some technical differences between extensions, modules, plugins extension points\nbut I don’t want to go into them here.\n
  • \n
  • These changed my code style. Overnight.\n\nEspecially the Fair Play Rule - I have to expose enough API to build the system.\n
  • \n
  • Open beats closed.\n
  • We’re inviting extensions into our framework.\nNeither the framework or the extension know what order they are going to be built.\n
  • \n
  • Fixed size housing\nNot extendable.\n
  • Assumes:\n * no space between houses\n * fixed sized houses\n * house build order is fixed\n \n\n
  • House number determined by 10s of meters from one end. (e.g. Melbourne to Adelaide)\nNo assumption of a house building order. \nHouses can be as big or small as you want.\n
  • \n
  • Principle of least surprise, \nEvery roadblock is an opportunity not to use your framework, or hate you, or both.\n * Installation\n * Common use-cases should be bug free.\n * Documentation\nMental model (i.e. the model of your framework in the user’s mind):\n * re-enforced by a clean API\n * does not need to bare any relation to the implementation. \n * a non-leaky abstraction.\n
  • \n
  • \n
  • This is not just about encapsulation.\n
  • Patterns should be on here, but I’m assuming this is a university book\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Writing Frameworks for Fun and Profit

    1. 1. Writing aframework for fun @jhugman – James Hugman
    2. 2. Not him again • Software Engineer in industry for 10y+ • Written: • Compilers, Reasoning Engines, ETL systems, evolutionary algorithms, cross-platform mobile frameworks@jhugman
    3. 3. Contents • Why should I care • Words shape thought • Rules for enablers • Developers are users too@jhugman
    4. 4. Anti-Contents • A specific technology • The importance of encapsulation • An exhaustive list of anything@jhugman
    5. 5. Why should I care? Why would I want to write a framework?@jhugman
    6. 6. Your role changes • Tool user • Tool maker@jhugman
    7. 7. @jhugman Status
    8. 8. Architect@jhugman Status
    9. 9. What happens at@jhugman work…
    10. 10. What happens at@jhugman work…
    11. 11. @jhugman It feels like…
    12. 12. @jhugman It feels like…
    13. 13. Words Shape Thought Identifiers, Little Languages and Patterns@jhugman
    14. 14. Words shape thought • Find language that describe the concepts • Break concepts into smaller nouns & verbs@jhugman
    15. 15. Words shape thought • Make your code out of this language e.g. identifiers • Build your code bottom up@jhugman
    16. 16. Words shape thought • Over-generalizing is double-plus- ungood • process() • apply() • execute()@jhugman
    17. 17. Words shape thought • Wrong words require double-think@jhugman
    18. 18. Why Language Matters • Thought-to-code gap • More readable code • Better intra-team communication • Bugs are harder to write@jhugman
    19. 19. Other People’s DSLs • Integrate existing little languages with your framework • e.g. SQL, XPath, Javascript • Design patterns provide a vocabulary@jhugman
    20. 20. Definitional Interlude • Framework vs Toolkit (Hollywood Principle)@jhugman
    21. 21. Extendable systems Architect like you have a plugin mechanism@jhugman
    22. 22. Plugin systems • Modularity above the package level • Assume you have a plugin system, even if you don’t@jhugman
    23. 23. Rules for Enablers • Invitation Rule – Whenever possible, let others contribute to your contributions • Fair Play Rule – All clients play by the same rules, even me. • Explicit Extension Rule – Declare explicitly where a platform can be extended. • Diversity Rule – Extension points accept multiple extensions.@jhugman
    24. 24. Rules for Enablers • Explicit API Rule - separate the API from internals. • Defensive API Rule - Reveal only the API in which you are confident, but be prepared to reveal more API as clients ask for it.@jhugman
    25. 25. Architect for Participation • Requirements change, new features added • Multiple uncoordinated teams can work concurrently • Plugins limit negative impact of change • Containment of unpredictability@jhugman
    26. 26. Example Architecting for growth@jhugman
    27. 27. House Numbers • Physical world example • A street, where houses will be • How should we number the houses@jhugman
    28. 28. House numbers •Sequential •Row at a time •Simple at 1 2 3 4 build time road •Not 5 6 7 8 extendable •Not very navigable@jhugman
    29. 29. House numbers •Sequential •Odds/Evens •Extendable in 1 3 5 7 one direction road •Assumes no 2 4 6 8 space between houses@jhugman
    30. 30. House numbers •Distance from one end •Large scale 10300 17010 •Navigable road 15705 •No fixed 19010 construction order@jhugman
    31. 31. Developer UX Developers are users too@jhugman
    32. 32. Developer pain kills • Everything should be obvious • A good mental model@jhugman
    33. 33. API Usability • Design APIs upfront (almost BDD for APIs) • Seek feedback from real developers • Prototype, review, iterate@jhugman
    34. 34. Related • Paper prototyping • README driven development • Commit-log driven development@jhugman
    35. 35. Summary • Words shape thought • Build in extensibility, early • Think hard about developer experience@jhugman
    36. 36. Further Study • Graduates/Juniors: • Effective Java Josh Bloch • Huston Design Patterns (a website with GoF patterns) • Programming Pearls Jon Bentley • Pragmatic Programmer Andrew Hunt & Dave Thomas •@jhugman
    37. 37. Further Study • Principles of Newspeak George Orwell • Growing a Language Guy Steele • The Art Of War Sun Tzu • Unwritten Rules Of Engineering Skakoon & King • Developer UX@jhugman
    38. 38. Podcasts • Java Posse • this developer’s life • Hacker News Pod • Software Engineering Radio@jhugman
    39. 39. Thanks @jhugman – James Hugman@jhugman
    40. 40. Discuss AMA@jhugman
    41. 41. @jhugman
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×