1.2. A Recipe for Recipes

There are two useful places to start when planning a Rails application:

• You can start from the front-end and move backwards by thinking about what actions or activities your users will perform in the site.

• You can start from the back-end and move forwards by thinking about what kind of data you will need to be storing.

The two directions feed back and forth on each other, of course, and there's no particularly correct way to go about site design. Rails is extremely good at supporting incremental development, so starting in one small place and gradually increasing functionality is a perfectly valid design process.

For the purposes of the book, I'd like to start with a brief description of user activities, but work in earnest with the initial data structure and administrative side, catching up with the user activities in future chapters. For me, at least, since Rails is so good at quick-and-easy data creation support, it feels more direct to start with that part, get some quick success under my belt, and then start designing the front end with some actual data to look at.

So, here's a quick description of user activities. Soups OnLine is intended to start as a recipe repository, where users can upload recipes, find recipes that match various categories or criteria, and comment on recipes. More advanced uses might include the capability to make and receive recommendations, information about various techniques or ingredients, and the capability to purchase equipment, ingredients, or even premade soup.

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.