blog.josephhall.com

You may remember a while ago when I talked about certain idiots that seem to feel that caloric intake defines the healthfulness of a food. As it turns out, calories are important, but they're not the only thing that tells us about the health content of our food. There are other important factors, such as the amounts of protein, fat, carbohydrates, sodium, etc. Even the types of carbs or fat are important, so much in fact that companies who sell packaged food (in the US, at least) are required to list these and other data somewhere on the package.

The problem is, this kind of data isn't easy to calculate. Large manufacturers possess the resources to do this, but what about restaurants? The big chains also have the ability to do this, but what about the mom and pop places? Even popular restaurants with only one or two locations have difficulty doing this. And unfortunately, there are some loose cannons out there in our local and national governments that are trying for force restaurants to do these things. If these places are unable to do so, then they will be forced to close their doors. It's the sort of legislation that seems to be designed to hurt the big guys, but is really more effective at killing the little guys.

Eventually, the loose cannons may win. And when they do, the little guys need to be able to conform in order to stay in business. Fortunately, some of the smarter parts of the US government have provided us with various resources to do so. One of the more important resources is called the USDA National Nutrient Database for Standard Reference, and is available as a free download from the USDA website. If you want something a little easier to use than the raw data, you can also search the database online, or download an application to let you search on your home computer (Windows or Linux with WINE) or on your Palm OS device.

A lot of companies are already using the Standard Reference, which at the time of this writing is at Release 20. As it turns out, most of these companies aren't in the business of providing nutritional analysis (such as on the side of a package) are they in the business of providing diet software and services. While some packaged foods are listed, much of the database contains information about individual ingredients. Information for an ingredient's raw state is almost always there, but sometimes information for that ingredient is listed for frozen, steamed, packaged in various states, etc. Information is also listed for various serving sizes, with 100 grams almost always being present. If you use their software, you can also specify your own serving sizes, which is really just an abstracted view of the database.

There are three types of downloads available: Full, Abbreviated and Update Files. The Full version is available in ASCII and MS Access formats. Abbreviated (which contains all of the products, but not all of the nutritional data such as alcohol, caffeine, theobrimine, etc) is available in ASCII and MS Excel formats. The Update Files (ASCII only) are designed to update from one release to the next (such as from SR19 to SR20). Because the ASCII files are viewable on all platforms, and most people are interested in the entire database, I will focus on the Full ASCII files (available packaged together in a .zip file).

There are several files that belong to the standard reference. Many of the files refer to each other, kind of like a pseudo-relational database. In fact, using a simple filter, the data in these files is pretty simple to import into an actual database. The files are:

FOOD_DES.txt    Food Description File
FD_GROUP.txt    Food Group File
NUT_DATA.txt    Nutrient Data File
NUTR_DEF.txt    Nutrient Definition File
SRC_CD.txt      Source Code File
DERIV_CD.txt    Derivation Code File
WEIGHT.txt      Weight File
FOOTNOTE.txt    Footnote File
DATA_SRC.txt    Sources of Data File
DATSRCLN.txt    Data Source Link File

The files are tilde-delimited, but not in the way you might think. Each field has a tilde (the ~ character) on either side of it. If the field is empty, it will have a caret (the ^ above the 6 key) in it. For instance, the first line of the FOOD_DES.txt file looks like this:

~01001~^~0100~^~Butter, salted~^~BUTTER,WITH SALT~^~~^~~^~Y~^~~^0^~~^6.38^4.27^8.79^3.87

The first field in this file is the NDB_No, the 5-digit unique identifier for the food item. The second field is the FdGrp_Cd, a 4-digit unique identifier for the food group that the item belongs to (as laid out in the FD_GROUP.txt file). The third and fourth fields are long and short descriptions, and so on. Full descriptions for each of the fields is available in the SR20_doc.pdf packaged in the accompanying .zip file, starting on page 22.

Of particular interest is the NUT_DATA.txt file, which contains the bulk of the data. There are several rows for each ingredient, each of which represents a particular nutrient (as laid out in the NUTR_DEF.txt file). Some of the nutrients available (from NUTR_DEF) are:

~203~^~g~^~PROCNT~^~Protein~^~2~^~600~
~204~^~g~^~FAT~^~Total lipid (fat)~^~2~^~800~
~205~^~g~^~CHOCDF~^~Carbohydrate, by difference~^~2~^~1100~
~207~^~g~^~ASH~^~Ash~^~2~^~1000~
~208~^~kcal~^~ENERC_KCAL~^~Energy~^~0~^~300~
~209~^~g~^~STARCH~^~Starch~^~2~^~2200~
~210~^~g~^~SUCS~^~Sucrose~^~2~^~1600~
~211~^~g~^~GLUS~^~Glucose (dextrose)~^~2~^~1700~
~212~^~g~^~FRUS~^~Fructose~^~2~^~1800~
~213~^~g~^~LACS~^~Lactose~^~2~^~1900~
~214~^~g~^~MALS~^~Maltose~^~2~^~2000~
~221~^~g~^~ALC~^~Alcohol, ethyl~^~1~^~18200~
~255~^~g~^~WATER~^~Water~^~2~^~100~
~257~^~g~^~~^~Adjusted Protein~^~2~^~700~
~262~^~mg~^~CAFFN~^~Caffeine~^~0~^~18300~
~263~^~mg~^~THEBRN~^~Theobromine~^~0~^~18400~
~268~^~kj~^~ENERC_KJ~^~Energy~^~0~^~400~
~269~^~g~^~SUGAR~^~Sugars, total~^~2~^~1500~

Let's take for instance Red Bull:

~14154~^~1400~^~Energy drink, RED BULL, with added caffeine, niacin, pantothenic acid, vitamins B6 and B12~^~ENGY DRK,RED BULL,W/ ADD CAFFEINE,NIACIN,PANTO,VIT B6 & B12~^~~^~Red Bull North America/Red Bull GmbH~^~Y~^~~^0^~~^6.25^4.00^9.00^4.00

The nutrient data line for the caffeine looks like this:

~14154~^~262~^30^2^^~13~^~AI~^~~^~~^1^29^31^1^^^~~^

These rows are defined for 100 gram portions. This particular product has 30mg of caffeine per 100 grams. The gram weight of a can of Red Bull is 255, which means that each little 8.3oz can of Red Bull contains 76mg of caffeine.

Lost? Do what I did: go to the online search form and look up Red Bull. The file format is pretty difficult to read manually, and not really easy to work in programmatically. When I'm working with my own import of the database, I use the online search form to check my work, to make sure I'm doing it right.

So if the database is such a pain to work with, why bother? Because, as the name implies, it's a Standard Reference. There are a lot of companies (not just online diet services) that use this database. The important thing is not how easy the raw data is to read. Raw data was never meant to be used like that. What we need is an abstraction. The online search form is an abstraction. The software available for Palm or Windows is an abstraction. It's something that's easier to read and understand.

The database is also considered to be very accurate. And it's updated on a regular basis. When I first started playing with it, it was at SR15. And most importantly, it's free! Why bother spending loads of cash on a book that will be out of date in a few months anyway? Once you understand how to import the main database, importing the updates is trivial.

I'll be taking a closer look at the database in future posts, but I wanted to make people aware of what it is, and what it's about first. Feel free to take a look at the docs, but unless you're techincally inclined, they probably won't do you much good. But the online search form is useful for pretty much anybody.

Labels: cooking, nutrition, open recipe format, orf, recipes

There is a fair amount of software these days that takes into account the fact that sometimes, people want to include a photo (or two or three or more) with their recipe. And why not? Some people are pretty proud of their creations and they want to show them off. But it goes a little deeper than that.

Professional chefs need the ability to store and share recipe photos as well. Many chefs have very specific plating techniques that they want to be able to disseminate to their cooks. It's important for those cooks to have the ability to reference those techniques even when the chef is out of the kitchen. Usually just one photo is enough, but sometimes more than one is required. If you look at some professional cookbooks, you might see various techniques displayed step by step, photo by photo.

Sometimes, somebody may want to distribute other media with the recipe. I don't see a whole lot of recipes calling for audio-only files, but I do see the occassional instructional video distributed. Sometimes it really helps to have accompanying text with the video. The video may demonstrate a lot of good things that are hard to get across on paper, but once a person has seen the video enough times, they may only be interested in the recipe itself.

Recipe software needs to account for users wanting to include media with their recipes. It would also be nice if that media was supported outside of the software's internal recipe database. A lot of people would be interested in distributing their media-laden recipes, given the opportunity.

Labels: cooking, open recipe format, orf, recipes

Back when I actually baked professionally, we used to keep our recipes in binders around the bakery. These binders would be labelled with things like, "Breads", "Cakes and Cookies", and the aptly-named "Odd Stuff". The recipes in these binders were on standard 8.5" x 11" paper, hand-written into photocopied forms, and then stuffed into plastic protector pages. When a recipe was needed, it would be extracted from the binder, and the plastic protector page would keep the recipe from getting gross and icky as it was inevitably splashed with cream, melted butter, egg whites and the like. When we were done, we would wipe off the plastic and put the recipe back in the binder.

This was a fine system, except for one problem: the recipes were hand-written. Some were easier to read than others, and those which were faxed from one lodge to another were especially difficult to deal with. The executive pastry chef apologized at the beginning of the ski season for the hand-written recipes, and promised that solutions were being looked at. Many of you are thinking, what's the big deal? Why not just type up and print out the recipes like normal people?

Yes, they could do that. It would be a lot of work, probably taking up a week or so of a single baker's time, and when you're only open for 4 1/2 months out of the year, you tend to focus your energy during that time on managing the rest of the bakery. When the season is over, the majority of bakers leave town, often to work at another resort across the country or world until the next ski season. The skeleton crew that is left focuses their resources on other events for the next several months. And yet, that wasn't really the problem.

The problem had to do with how the recipes were laid out. Let's take my basic cheesecake for example. Sometimes, the bakery only needs to produce one cheesecake. This isn't often, but it happens. More often, something like eight cheesecakes would need to be made. Sometimes only four. Sometimes as many as twelve. With experience, these numbers were somewhat predictable.

We need the recipe for a single cheesecake. Even if we never make just one, this is the basis for which all other amounts will be calculated. We have eight spring form pans, but we rarely need to bake more than five cheesecakes at once. Except in the busy seasons, anything more than five would result in a shelf life longer than a week, which would result in a loss of quality. During the busy weeks, we may need to make eight cheesecakes at a time, and we may need to do so every other day. So we need, at the very least, ingredient lists printed up for 1, 5 and 8 cheesecakes. It would be nice to have them all printed up on the same page, mostly for manageability. And it would also be nice to have at least one or two extra columns on that page, just in case a new amount needs to be calculated (for instance, we buy another 8 spring form pans).

Going from memory (and likely leaving out some subtle details), the form (complete with the aforementioned cheesecake recipe) looked something like this:

			Oven Temp	275F
		Oven Fan	Low	High
Ingredient	1	5	8
cream cheese	2 lbs	10 lbs	16 lbs
white, granulated sugar	1 cup	5 cups	8 cups
large eggs	4	20	32
vanilla extract	2 tsp	3 Tbsp + 1 tsp	5 Tbsp + 1 tsp
1. Preheat oven to 275F. 2. Allow the cream cheese to warm up to room temperature. 3. In a mixer, cream together the cream cheese and the sugar with the mixer's paddle attachment until light and fluffy. 4. Add the vanilla. 5. Add one egg and mix on low speed. When it is fully integrated, stop the mixer and scrape down the sides and the paddle with a rubber spatula. 6. Continue adding eggs the same way, one by one. 7. When the mixture is smooth and there are no lumps, pour it into a prepared 9-inch round cake pan. 8. Move to a 275F oven and set the timer for 1 hour. 9. After an hour, jiggle the pan a little. If the center still seems liquid, close the door and wait a few minutes before checking again. 10. When the center is only a little wiggly (but no longer liquid), turn the oven off. 11. Leave the oven door open for 1 minute, and then close it again. 12. Allow the cheesecake to sit in the oven for 1 more hour as both the cheesecake and the oven cool. 13. Move the cheesecake to the refrigerator and chill for at least 6 hours (overnight is better) before attempting to cut and serve.

You'll notice that I've abandoned the format suggested in my post about standardizing recipes. I hope that I made it clear in that post that that particular format was not applicable to every kitchen. In the case of this bakery, it would only serve to add confusion and leave no room for multiple scalings.

Take note of the multiple scalings. First of all, this bakery would never have stuck with volume measurements. They would have been converted to weight almost immediately. You'll notice that each column is simply laid out, and easy to follow. Some bakers, to make sure that they don't accidentally look at the wrong column, would cover up the others with masking tape until they were done with the recipe. If they needed a temporary scaling, they would cover the last (blank) column with masking tape and write the new amounts on it. If they used it enough, they would pull out the actual paper and fill in a new column.

I added a couple of other things that I have not yet mentioned. The oven temp is clearly noted at the top of the page, so that the baker can set the oven without having to search the instructions for the temp, and then start to gather ingredients. There's also a place where the baker can circle whether they set the oven fan to high or low. Many professional bakeries make use of convection ovens which have only two fan settings: low and high (but not off). In retrospect, I think the bakery would rather have had a temperature setting for low, and another one for high. Maybe even a third one for "no fan", for their older ovens.

I do not know of any recipe software on the planet that takes all of these things into account. And from talking to other bakers, cooks and chefs, this feature is sorely needed. The corporation that owned that ski resort had spent years trying to find suitable software, and had come up empty-handed. The last I heard, they were working on building something in-house, and it did not look promising. The bakery was not interested in investing any time in typing recipes until the software was made available. Any significant difference in how they typed them and how the new software would handle data entry could represent days worth of lost time and duplicated efforts.

Let's say we got software that supported printing out multiple scalings one a single page. There's another problem here: saving the multiple scalings. Some of you are thinking, "why not just save the amounts for a single cheesecake, and then choose other amounts just before printing?" Let me ask you: have you ever made rice before?

I think Alton Brown summed this up nicely in the landmark Good Eats episode, Power to the Pilaf. Most rice packages instruct you to use one part rice to two parts water, by volume, regardless of how much rice you're actually making. But as he points out, you can actually cook one cup of rice in a cup and a half of water. Two cups of rice will cook nicely in 2 3/4 cups of water. And Three cups of rice will cook properly in 3 1/2 cups of water.

As much as we (especially programmers) would like to think that food fits neatly into our carefully-calibrated mathematical world, it does not. Food is organic. It is grown, largely by a set of rules that we still don't completely understand. No cup of rice is the same, no pound of flour. All that we can do, even in the best of times, is approximate. Doubling recipes will often work, to a certain degree. But there will be a point in which our ingredients will rebel against us, and only the hand of an experienced cook or baker will be able to control the chaos. And when that cook or baker discovers that their approximation has changed because of the sheer amount of food that they are making, they make a note of it. And if you think they want to figure it out every time, or let the next guy figure it out from scratch, you're out of your mind.

Recipe software needs to have the ability to not only scale properly, but also record the (user-adjusted) changes based on amount, and optionally print it out on the same sheet, with easy to reference columns side-by-side for the cook or baker's convenience. We don't currently have software that supports this. We, as home cooks, may not need it. But our professional counterparts do.

Labels: cooking, open recipe format, orf, recipes

Knowing what HACCP is is all well and good, but unless you know how to use it, it doesn't really do you any good. If we want to know how to add HACCP support to our software, we need to know what a finished HACCP recipe looks like. I'm going to incorporate the points laid out in my HACCP post with the layout that I used in my post about standardizing recipes.

For brevity, I'm not going to post the original recipe first this time. I'm going to use an old recipe that I posted some time ago for Kai Yang. If you would like to look at the original, complete with all of the flaws that I've talked about, go for it.

2 tablespoons minced fresh ginger 2 tablespoons chopped fresh lemongrass 2 tablespoons chopped fresh cilantro 1 teaspoon sugar 1 tablespoon ground black pepper 2 tablespoons curry paste 1/2 teaspoon sriracha 1 tablespoon fish sauce 1 cup lite soy sauce 1 cup veggie stock	Combine all ingredients in a blender. Mix well.
2 pounds dark chicken meat, in pieces	Add chicken and other ingredients to a resealable container.
	CCP: Chill to a temperature of 139F for a period of 6 hours.
	Halfway through the refrigeration process, turn the meat over.
	Remove the meat from the liquid.
	CCP: Because the liquid contained raw meat, discard the liquid as quickly as possible to avoid cross-contamination.
	Mark the chicken on the grill, then place on a sheet pan and move to a 400F oven.
	CCP: Bake the chicken until a thermometer placed into the deepest part of the meat reads 165F.
	CCP: Keep chicken at a temperature of at least 140F until it is served.
	CCP: If chicken is to be stored for service at a later time, chill to a temperature of 139F or lower as quickly as possible, and freeze or refrigerate no warmer than 139F.
	CCP:Chicken that has been chilled for storage should be heated to at least 165F before service, and then kept at a temperature of at least 140F until it is served.
	CCP:Chicken should not be chilled at reheated more than once. If chicken is not consumed after being chilled and reheated once, then it should be discarded.

That's a lot of critical control points, isn't it? And believe me, there could be more. I've decided to simplify, for the purpose of instruction. If NASA was sending my kai yang recipe into space, they would likely have several more steps marked CCP.

You'll notice that many of the CCPs focus on temperatures. This is one of the more critical components of food safety, and something likely to appear in almost every HACCP plan. I've also pointed out things like cross-contamination, and only reheating the product once. Technically you could probably get away with multiple reheatings, but the quality would suffer, and each trip between 41F and 140F (both cooling and heating) would accumulate as additional time that the food spent in the danger zone.

This is just a brief overview of what a recipe with integrated HACCP instructions might look like. Any serious commercial software should take such recipes into consideration, and possibly seek additional information from more experienced sources.

Labels: cooking, open recipe format, orf, recipes

I've spent a good bit of time talking about recipes. I'd like to take a moment now to deviate somewhat from that discussion to give some background information on something called Hazard Analysis and Critical Control Points, or HACCP (pronounced "hassup").

Back in the 60's, when NASA was getting ready to send people up into outer space, they realized that they had a problem on their hands. If astronauts got sick while in the air, their ability to receive medical attention would be severely limited. The obvious solution of course, was to do whatever they could to prevent the astronauts from getting sick in the first place. One of the most crucial elements of this was exacting a level of control over the food that was sent up with them that would eliminate the chance of food poisoning.

Pillsbury was contracted to design, manufacture and provide the first space meals. HACCP was developed in order to keep food preparation well-within safe limits. It has proven to be very effective, and has since been adopted into other concerns outside of food, such as pharmaceuticals and cosmetics.

HACCP is based upon seven principles:

Principle 1: Conduct a hazard analysis
Procedures must be carefully inspected to discover at which points an unsafe practice may be introduced into the process. In terms of recipes, one may look at factors such as raw meat or eggs. If there is some item that may cause unsafe conditions to occur at any point, it should be noted.

Principle 2: Identify critical control points
A critical control point (CCP) is any step in the process when a control can be applied to limit, and hopefully eliminate unsafe actions. For instance, meat and poultry being cooked to a certain temperature to prevent salmonella, e. coli and other food borne illnesses.

Principle 3: Establish critical limits for each critical control point
This is the minimum and/or maximum limit to which a hazard must be controlled in order to ensure that it is at an acceptable level of safety. For example, poultry and ground meat should be cooked to at least 165F to kill off any pathogens that may be lurking within.

Principle 4: Establish critical control point monitoring requirements
We need to determine how to monitor the controls that have been identified to this point. Will a thermometer be required? Or is there some other mechanism that needs to be in place. In terms of meat and poultry, an accurate thermometer should be used to ensure that the inner meat has reached the appropriate level.

Principle 5: Establish corrective actions
If the above steps have been followed properly, then we shouldn't need to perform any corrective actions. But they do need to be in place, so that when something does go wrong, we have something to fall back to. If a pot of soup has dropped below 140F, then it needs to be removed from service until it has been properly heated to the correct temperature. If that soup has spent more than 4 hours (cumulatively, not at a time) under 140F, then it needs to be removed from service and discarded. If the time at which it has remained under 140F cannot be established, then it needs to be removed from service and discarded.

Principle 6: Establish record keeping procedures
This principle actually serves two purposes. If you've been able to keep proper records, then there will be no question as to how long that soup has been sitting out at under 140F. It's another layer of control that allows you to know, from start to finish, what the status (both safe and unsafe) of your product is at. If something goes wrong, this principle also provides you with proof (which may be helpful and/or necessary for legal reasons) that you either did something correctly or incorrectly.

Principle 7: Establish procedures for ensuring that the HACCP system is working as intended
It's all well and good to have a system in place. But if you have no way of knowing whether it's actually doing what you want it to do, then it's largely useless. Once you have your plan in place, you need another plan to make sure that the first one will work... before you even implement it. In fact, some organizations will not approve your plan without having this benchmark already in place. You may also find as you develop these additional procedures that there are holes in your HACCP plan. These procedures will let you know for sure one way or another.

Why have I made a point to explain HACCP? Many organizations are legally required to abide by these rules, and have their own HACCP plan in place. In fact, meat packers, egg farms and the like fall into this category. The corner bakery may not have the resources to implement and enforce their own HACCP system, but the hotel bakery probably will. And the corner bakery probably should, as soon as they're able. Recipe software that is expected to be used commercially needs to have features in place to accommodate such operations if it is ever to be seriously considered for use.

Labels: cooking, haccp, open recipe format, orf, recipes

Having a properly-written recipe is an excellent step in the right direction. And for most home cooks, that's going to be good enough. But for professional kitchens as well as for control freaks such as myself (I'm a nerd, it comes with the package), there's still plenty of work to be done.

Standardizing recipes offers many advantages in a professional environment. When every recipe in the chef's binder looks the same, his or her cooks and/or bakers don't need to guess at things. As you know from my previous post, clear and concise instructions are a must. But having recipes that compliment the flow of the kitchen will convert time wasted thinking about what to do into time used doing what needs to be done.

One of my favorite styles of formatting recipes combines a neatly-ordered and easy to access list of ingredients alongside the applicable instructions for each ingredient, or group of ingredients. Let's use my suspiciously-familiar chocolate chip cookie recipe as a starting point:

1 cup (2 sticks) unsalted butter
3/4 cup granulated sugar
3/4 cup + 1 tablespoon packed dark brown sugar
1 teaspoon vanilla extract
2 large eggs
2 1/2 cups bread flour
1 1/2 teaspoons baking soda
1 teaspoon salt
2 cups chocolate chips

1. Preheat oven to 300F.
2. Allow butter to warm up to room temperature.
3. In a mixer, cream together the butter and the sugars with the mixer's paddle attachment until light and fluffy.
4. Add the vanilla extract.
5. Add one egg and mix on low speed. When it is fully integrated, stop the mixer and scrape down the sides and the paddle with a rubber spatula.
6. Continue adding eggs the same way, one by one.
7. When the eggs are fully integrated, stop the mixer.
8. Whisk together and then sift the flour, baking soda and salt into the bowl.
9. Mix at the lowest speed with the paddle attachment until the dry ingredients are just barely mixed in, scraping as necessary.
10. Stop the mixer and add the chocolate chips.
11. Mix at the lowest speed for just long enough to mix in the chips.
12. Scoop onto cookie sheets with a #40 scoop, leaving room between the cookies to allow for spreading.
13. Move to a 300F oven and set the timer for 12 minutes.
14. After 12 minutes, look at the cookies. When they are just starting to brown on the edges, remove from the oven and allow to cool.

It's certainly much easier to reference here than in my tutorial, isn't it? This recipe serves as nothing more than a set of instructions for somebody who, presumably, already knows what they're doing in the bakery. They may not have seen this recipe before, but they can easily follow it.

Note the order in which I have the ingredients. Because the butter and sugars will be used first, they have been listed first. Wet ingredients are listed next, and then dry, because that's the order in which they will be added to the mixer.

In the instructions, you'll notice that I started with the oven temperature, since preheating it what will likely take the longest. In a professional bakery, the oven will likely already be preheated, but may not be at the correct temperature. Letting the butter soften takes a long time too, so it goes next.

This is a good recipe, but it we can improve upon it for professional use. Those of you that are deeply concerned about HACCP will appreciate these improvements.

	1. Preheat oven to 300F.
1 cup (2 sticks) unsalted butter	2. Allow butter to warm up to room temperature.
3/4 cup granulated sugar	3. In a mixer, cream together the butter and the sugars with the mixer's paddle attachment until light and fluffy.
3/4 cup + 1 tablespoon packed dark brown sugar
1 teaspoon vanilla extract	4. Add the vanilla extract.
2 large eggs	5. Add one egg and mix on low speed. When it is fully integrated, stop the mixer and scrape down the sides and the paddle with a rubber spatula.
	6. Continue adding eggs the same way, one by one.
	7. When the eggs are fully integrated, stop the mixer.
2 1/2 cups bread flour	8. Whisk together and then sift the flour, baking soda and salt into the bowl.
1 1/2 teaspoons baking soda
1 teaspoon salt
	9. Mix at the lowest speed with the paddle attachment until the dry ingredients are just barely mixed in, scraping as necessary.
2 cups chocolate chips	10. Stop the mixer and add the chocolate chips.
	11. Mix at the lowest speed for just long enough to mix in the chips.
	12. Scoop onto cookie sheets with a #40 scoop, leaving room between the cookies to allow for spreading.
	13. Move to a 300F oven and set the timer for 12 minutes.
	14. After 12 minutes, look at the cookies. When they are just starting to brown on the edges, remove from the oven and allow to cool.

You'll notice that everything is in exactly the same order as before, but the ingredients are listed next to the steps that require them. This way we still have easy access to the ingredient list for shopping purposes and so on, without needing to read through the entire recipe to get everything. Also, the reader now has hints at a glance as to where exactly to expect the ingredient to be needed. This can help them prepare mentally in the middle of the actually cooking or baking process.

This recipe formatting may be overkill for most home cooks and bakers. But it may be helpful, if not essential, in many professional kitchens and bakeries. And quite honestly, it doesn't hurt the home cook either. In fact, they may come to like it.

Of course, this formatting will not necessarily be applicable to every professional kitchen. It may be that what we started out with is perfect for your operation. You need to analyze the needs of your staff and consider the other variables in the equation, such as kitchen layout, the ingredients that you work with, which equipment you have available, and so on.

The professional kitchen that wants to adopt this or similar formatting will want to make sure they do so for all of their recipes. You're not really standardizing anything until you do so. But having all of the recipes laid out in the same way, and having that way be efficient and easy to use will increase productivity.

Labels: cooking, open recipe format, orf, recipes

If you're a regular reader here, then you will probably notice by the end of this post that I have broken almost every rule set forth in it, and still do so on a regular basis. I'm trying to get better. Whenever I get around to setting up an actual database of recipes from my blog, I hope to have time to rewrite them in accordance with these guidelines.

Consider the following set of instructions:

Mix together 2 pounds of cream cheese with a cup of sugar, using the paddle attachment. Add four eggs, 1 at a time, with 2 tsp vanilla. Pour into crust, bake at 275 degrees for 1 hour, then turn off oven and let cool inside for another hour. Chill for no less than 6 hours before serving.

Many of you might recognize this as a recipe for a pretty basic cheesecake. But it (the recipe) has a lot of problems, especially for commercial use. Ignoring for now the lack of instructions for the crust itself, let's take a look at a few of the problems.

First of all, there is no ingredient list. This is reminiscent of my earlier posts, where my intent was to tell a story, not necessarily provide a reference of any sort. If you want to find out what to shop for, you need to read the entire recipe and make your own list. Granted, you should read the recipe anyway before doing anything with it, but this adds an extra layer of work.

You may also notice that in some places numbers are spelled out, whereas in other places actual numerals are used. This makes it difficult for somebody to pick out measurements in a hurry. Speaking of measurements, you may also notice that full spellings and abbreviations are intermixed. This causes the same problem. It may be okay for emailing to cousin Vinny, but it'll never fly in a professional operation. "275 degrees"? Fahrenheit or Celsius? Probably Fahrenheit, but they should have specified.

"...Using the paddle attachment..."? Those of you with stand mixers know what's going on here, but what about everyone else? Most of these instructions are pretty vague. Who knows how that vanilla is really supposed to be added? In fact, it's almost like a reminder for somebody that's made this recipe hundreds of times, rather than a helpful set of instructions for somebody who's never made it before. It's almost as bad as some of the old Unix/Linux man pages. Then again, I've also seen some recipes who's instructions are little more than "creaming method".

Let's examine another version of the recipe:

2 lbs cream cheese
1c sugar
4 eggs
2 tsp vanilla

1. Cream together the cream cheese and sugar. Add eggs one at a time.
2. Slowly add in the vanilla with the eggs.
3. Pour into crust and bake at 275F for one hour.
4. After an hour, give the pan a shake. If it still looks liquid in the center, close the door and check again in a few minutes. When it just barely wobbles in the center, turn the oven off. Leave the cheesecake in the oven for another hour as the oven is cooling.
5. Let chill for at least 6 hours before cutting and serving.

Well, at least we have an ingredient list now. But what the heck is "1c sugar"? Probably a cup. Most people can figure that out. I say most, because some people (especially a more timid cook) may be confused and/or intimidated by that notation. Everything else in the ingredient list looks good though.

Step 1 already presents a problem. It should have been divided into two steps. And Step 2 isn't really any clearer than before. Step 3 should also be divided into separate steps, one of which should have started the recipe: "1. Preheat oven to 275F." By Step 4, we've pretty much given up on trying to divide up steps. The cook might have thought that it was pretty clear as one step, but when a single step is more than three times longer than any other single step, there's a good chance it needs to be rethought.

The recipe, unfortunately, still tends to be vague in some places and somewhat clearer in others. When you write a recipe, you should assume that the next person who looks at it has never seen it before. Don't try to give a cooking lesson in the recipe itself. If you need to tell a story, make sure you list the recipe outside the story as a separate entity. But if there is some subtle nuance, make sure to note it. Too many recipes have caveats that the creator knew about, and then assumed everyone else knew about too.

Let's consider a more properly-written recipe:

2 lbs (four 8 oz pkgs) cream cheese
1 cup white, granulated sugar
4 large eggs
2 tsp vanilla extract

1. Preheat oven to 275F.
2. Allow the cream cheese to warm up to room temperature.
3. In a mixer, cream together the cream cheese and the sugar with the mixer's paddle attachment until light and fluffy.
4. Add the vanilla.
5. Add one egg and mix on low speed. When it is fully integrated, stop the mixer and scrape down the sides and the paddle with a rubber spatula.
6. Continue adding eggs the same way, one by one.
7. When the mixture is smooth and there are no lumps, pour it into a prepared 9-inch round cake pan.
8. Move to a 275F oven and set the timer for 1 hour.
9. After an hour, jiggle the pan a little. If the center still seems liquid, close the door and wait a few minutes before checking again.
10. When the center is only a little wiggly (but no longer liquid), turn the oven off.
11. Leave the oven door open for 1 minute, and then close it again.
12. Allow the cheesecake to sit in the oven for 1 more hour as both the cheesecake and the oven cool.
13. Move the cheesecake to the refrigerator and chill for at least 6 hours (overnight is better) before attempting to cut and serve.

This recipe is a lot easier to handle. The ingredients are clear, and specific. The steps are all reasonably small, and have only one actual instruction per step. Each step is reasonably clear, and while it does not explain what might go wrong if you ignore the instructions (that's what cooking classes are for), it does give you the proper instructions with the nuances noted (such as scraping the bowl and the paddle). It could probably still use a bit of improvement, but at this point it's in pretty good shape.

Like I said, most of the recipes on my blog are not this well-written. It's pretty painful for me to go back and look at a lot of my earlier material. But it's even more painful for me to think about changing an entry, at least without some sort of revision control to save the old format, as a reminder of how I used to write. But one day I do plan on rewriting as many recipes as possible and making them available in a much easier-to-use database.

When you start publishing recipes of your own, you'll want to take these guidelines into consideration. I'll refer to them in upcoming posts, which will make them just that much more relevant.

Labels: cooking, open recipe format, orf, recipes

One of the biggest problem I've seen with commercial recipe software is in scaling recipes. Say you have a recipe that yields four portions. This is normally perfect for your family, but you have extended family coming over this weekend and you need eight portions. Just double it, right? No problem.

What if you've managed to track down a recipe that normally feeds 50, and you need it to feed your small family of four. What do you do now? That's easy. Just plug it into your home recipe program and suddenly that cup of Worcestershire sauce becomes... 0.08 cups? How the heck are you supposed to measure that? Such a pain. How about if I told you that 0.08 cups was equal to 0.64 fluid ounces? Is that any easier to deal with? Not really. What if I told you that was roughly the same as one tablespoon plus one teaspoon? Okay, we can handle that.

What recipe software needs to do is give us answers in terms of fractions and measurements that may have different names that what we entered, if necessary. For instance, we entered cups, but what we needed back were teaspoons and tablespoons. Decimals are fine for scientists and maybe wholesale food operations, but not for home users, and not even for most professional kitchens.

First of all, we need a basic breakdown. How many of X are in Y? Note: These measurements are standard US (imperial) measurements. Metric is easier, but not as common in my country.

1 tablespoon	=	3 teaspoons
1 fluid ounce	=	1 tablespoon
1 cup	=	8 fluid ounces
1 pint	=	2 cups
1 quart	=	2 pints
1 magnum	=	2 quarts
1 gallon	=	4 quarts
1 peck	=	2 gallons
1 bushel	=	4 pecks

Okay, so magnums are usually only used in winespeak. And pecks and bushels aren't all that common, even in commercial kitchens. The highest they usually go is gallons, though at that level of production, they usually measure by weight. But that's another topic altogether.

It should also be noted that we occassionally measure in fractions. Most home and professional kitchens have both measuring cups (usually 1 cup, 1/2 cup, 1/3 cup, 1/4 cup) and measuring spoons (usually 1 Tbsp [tablespoon], 1 tsp [teaspoon], 1/2 tsp, 1/4 tsp). Oddly, 1/2 Tbsp, 1/3 Tbsp and even 1/3 tsp are pretty uncommon. Then again, we already know that 1/2 Tbsp = 1 1/2 tsp and 1/3 Tbsp = 1 tsp. 1/3 tsp gets left in the cold. Also, many cooks refer to a dash and a pinch as roughly 1/8 tsp, where a dash is for liquid ingredients and a pinch is for dry.

So we need software that will give us measurements using the smallest and/or easiest version of the following measurements:

• 1/8 teaspoon
• 1/4 teaspoon
• 1/2 teaspoon
• teaspoon
• tablespoon
• fluid ounce
• 1/4 cup
• 1/3 cup
• 1/2 cup
• cup
• pint
• quart
• gallon

Other measurements are nice, but these will be sufficient for most operations. But that still doesn't help us in terms of actually setting up software. We need a common measurement that is easy to work with, that everything else can be converted to and from. Fortunately, in this measurement system (for both weight and volume) we have ounces. Every whole measurement larger than an ounce can be calculated in terms of full ounces, and everything smaller than an ounce can be calculated in terms of fractions of an ounce. But that still doesn't solve the decimal problem.

When it comes to decimals, we're going to have to do some rounding. I would personally prefer my software to tell me both the decimal value, and the approximate fraction(s) that that relates to, and let me choose. I suspect most bakers would start off wanting just the fraction, and after a week of failed pastries demand to know what the decimal would have been, so that they can adjust accordingly. Most cooks (non-bakers) would likely be fine with the approximations.

Note: this table will attempt to be conservative, for instance, only covering the values up to half an ounce. That should be sufficient for our needs. Since you would not normally be hard-coding values, I'll also include the fraction of an ounce. If you can't figure out how to convert fractions into division in your code, it's time to pick up a new hobby/career.

1/8 teaspoon	=	0.020833333 oz (1/48 oz)
1/4 teaspoon	=	0.041666667 oz (1/24 oz)
1/2 teaspoon	=	0.083333333 oz (1/12 oz)
1 teaspoon	=	0.166666667 oz (1/6 oz)
1 tablespoon	=	0.5 oz (1/2 oz)

This tells us exact values. Unfortunately, few of our recipes will scale to exactly these amounts. So we round.

1/8 teaspoon	=	0.020833333 oz (1/48 oz)
		0.03125 oz (1/32 oz)
1/4 teaspoon	=	0.041666667 oz (1/24 oz)
		0.0625 oz (1/16 oz)
1/2 teaspoon	=	0.083333333 oz (1/12 oz)
		0.125 oz (1/8 oz)
1 teaspoon	=	0.166666667 oz (1/6 oz)
		0.25 oz (1/4 oz)
1 tablespoon	=	0.5 oz (1/2 oz)

Anything smaller than 0.03125 oz is considered 1/8 teaspoon (a pinch or a dash), anything between that and .0625 is considered 1/4 teaspoon, and so on.

This is a pretty basic operation. Many years ago I had a Perl subroutine that did this for me (with a good bit of help from Harley), and I've managed to lose it. One day I'll write it again, unless somebody else beats me to it. But it seems to me that any recipe software worth using would take the above information into account.

Many thanks to TuxGirl for helping me with the math, since I'm so horrible at it myself. Yet another reason why I need my software to do my thinking for me.

Labels: cooking, open recipe format, orf, recipes