Datasheet

Chapter 1: Building Resources
3
From the data perspective, the place to start is the recipe — that ’ s the main unit of data that the users will
be looking at. What ’ s the data for a recipe? Pulling out my handy - dandy Joy of Cooking (Simon & Schuster),
I see that a recipe consists of a title ( “ Cream of Cauliflower Soup ” ), a resulting amount ( “ About 6 cups ” ),
a description ( “ This recipe is the blueprint for a multitude of vegetable soups . . . ” ), some ingredients
( “ ¼ cup water or stock, 1 tablespoon unsalted butter ” ), and some directions ( “ Heat in a soup pot over
medium - low heat . . . ” ).
There are some interesting data representation questions right off the bat. To wit:
Should the directions be a single text blob, or should each step have a separate entry?
Should each ingredient be a single text string, or should the ingredients be structured with a
quantity and the actual ingredient name?
Is the ingredient list ordered?
The Joy of Cooking is unusual in that it actually interpolates ingredients and directions, which is
perhaps easier to read, and also enables lovely recipe visualizations such as the ones at the
website
www.cookingforengineers.com . Should you try to allow for that?
Sometimes an ingredient may itself have a recipe. Many soup recipes start with a standard base
stock, for example. How can you allow for that?
I find these decisions a lot easier to make with the understanding that they aren ’ t permanent, and that
the code base is quite malleable. Eventually, of course, there ’ ll be the problem of potentially having to
deal with a lot of data to migrate, but until then, here ’ s how I think the site should start:
Directions are a single text blob. There isn ’ t really any data to them other than the text itself, and
if you have a convention in data entry of using newlines to separate steps, it ’ ll be easy enough to
migrate should you choose to.
There will be structured and ordered ingredient lists. Usually ingredients are given in a
particular order for a reason. Adding the structure doesn ’ t cost much at this point, and will
enable some nice features later on (such as English - to - metric conversion). I also think that this
one would be harder to migrate to the structured data if you don ’ t start there — you ’ d have to
write a simple parser to manage that.
Interpolating ingredients and directions could be managed by adding directions to the
ingredient data, but doing so adds some complexity to the user display, and I ’ m not ready to
start with that. The idea of being able to do those shiny table visualizations is tempting, though.
This is a possibility for change later on, although I suspect that it would be nearly impossible to
extrapolate data from preexisting recipes.
Having ingredients themselves have recipes is a complication you don ’ t need at this point. In case it ’ s
not clear, I should point out that I ’ m doing this planning in real time. As I write the draft of this, I haven ’ t
started the code yet, so I could yet turn out to be dead wrong on one of these assumptions, in which case
you ’ ll really see how suited Rails is for agile development.
Having done at least a minimum of design work, it ’ s time to instantiate the data into the database.
You ’ re going to do that using the new - style REST resources with Rails.
❑
❑
❑
❑
❑
❑
❑
❑
c01.indd 3c01.indd 3 1/30/08 4:02:21 PM1/30/08 4:02:21 PM