1. Extreme Abstraction

2. If you give a man a fish he will eat for a day. … But if you teach a man to fish he will buy an ugly hat. … And if you talk about fish to a starving man then you're a consultant. -Dogbert

3. Abstraction  Dealing with classes and patterns rather than particular instances  Types/Levels  “Copy and Tweak” – Easy to copy, but lots to change  “Copy and Paste” …and you’re fine if nothing changes Abstracted – copy and paste, AND make changes in one place as needed

4. WET vs. DRY – our philosophy  “We Enjoy Typing” vs. “Don’t Repeat Yourself” (Thank you, Jason Young!)  Use DRY methods for things that should change universally  Use WET methods for things that should change only for particular instances

5. Examples/Demo

6. xBase Intro – some background  Basis for dozens of solutions  Core “DRY” functionality, with ability to create “WET” (“damp?”) customizations  Drawing the line is key  Administration, navigation, contacts, activities  NO “customers”, invoices, stock, etc.  Naming conventions are established, predictable and parsable

7. xTag and xScript  Dealing with classes and patterns rather than particular instances  Creates single points to effect universal changes  Processes are unique, but there are and should be patterns in the Functions  (In the same way that scripts are unique, but the steps perform consistently)  DRY script(s), WET parameters

8. xLink  Dealing with nuances and details that would be impractical with solely WET development  Allow the user to select one or more records  Why not just a value list?  Get actual keys  Prevent duplicates – help the user pick existing record(s), and make them check  Deal with duplicates that already exist – “which John Smith do you mean?”  Add new if the record doesn’t exist

9. Universal Drill-Down Button  Paste  Determines find parameters based on RelationInfo  Accommodates navigation rules and procedures, current and future  Parameters are all custom functions, which can be changed in one place

10. Goals of Abstraction  Easier re-use with less typing (“Don’t Repeat Yourself”)  A way to “hold what you’ve got” and not “reinvent the wheel”  Create single points to effect universal changes  Deal with nuances and details that would be impractical with solely WET development  Create consistency for the user (not just the developer)

11. Foundational Techniques  Naming Convention – parsable and meaningful  Name all objects  Idiomatic Development – Consistent patterns  Add meaning – standard TLA’s, “main” layouts, easy-to-identify primary keys…  Think a LOT about scope. What does your code “stick to”?  Favor abstractable functions – Find instead of GTRR, for instance  Copy more than you create

12. Discussion