You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’ve been making “template recipes” for a while and perhaps we should have a conversation about what they are and are for.
Recipe Types
I propose that each recipe be designed with a specific goal in mind: A recipe is either “Pedagogic”, “Realistic” or “Performance” :
A Pedagogic Recipe has a clear Educational purpose:
“This recipe shows how to populate connect Contacts to Programs with Program Engagements randomly”
“This recipe shows how to read a CSV file to populate Users”
More likely to only contain required fields
A Realistic Recipe is appropriate for doing demos of products. It should be considered from the point of view of someone who wants to try out a product and has no data for their trial.
Performance recipes will not usually be created by the Open Source community. They are for stress-testing specific features by making large and potentially quite unrealistic datasets..
A Markdown or HTML document could link to all of the recipes.
On The Question of Code Reuse
I propose that we do not worry, for now, about the role of Code Reuse. Every recipe will be standalone except the few which are designed to demonstrate code reuse, or situations where for our own internal recipe-building purposes it seems easier to reuse code.
Here are some arguments against a focus on reuse:
It is really hard to predict what kinds of “knobs and levers” a reusable recipe should provide for customization. Should the skew between two objects be hard-coded or configurable? Should the name template be hard-coded or configurable, etc.
Making a recipe very reusable means adding the knobs and levers which also make it hard to read and hard to use for pedagogy.
random_reference probably won’t do what you want if you have a bunch of different kinds of Account or Contact or whatever and construct a recipe from components.
On the question of complexity
It may be useful to identify recipes that employ advanced snowfakery features such as:
For the community owned recipe repo, we should try to use these features only when strictly necessary, as they introduce complexity that is harder to maintain and more difficult for end users to run smoothly without support.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
What is a “Template Recipe”
We’ve been making “template recipes” for a while and perhaps we should have a conversation about what they are and are for.
Recipe Types
I propose that each recipe be designed with a specific goal in mind: A recipe is either “Pedagogic”, “Realistic” or “Performance” :
A Markdown or HTML document could link to all of the recipes.
On The Question of Code Reuse
I propose that we do not worry, for now, about the role of Code Reuse. Every recipe will be standalone except the few which are designed to demonstrate code reuse, or situations where for our own internal recipe-building purposes it seems easier to reuse code.
Here are some arguments against a focus on reuse:
random_reference
probably won’t do what you want if you have a bunch of different kinds of Account or Contact or whatever and construct a recipe from components.On the question of complexity
It may be useful to identify recipes that employ advanced snowfakery features such as:
For the community owned recipe repo, we should try to use these features only when strictly necessary, as they introduce complexity that is harder to maintain and more difficult for end users to run smoothly without support.
Beta Was this translation helpful? Give feedback.
All reactions