"So, are you ready for the snow storm?"
I looked at my driver for a moment before replying. "Yeah, I guess I heard it was going to snow today or tomorrow."
When I had approached the front desk this morning to ask for a shuttle ride to the training center, the girl behind the counter was bundled up in what looked like a very warm coat, and she was still shivering. For my part, I was wearing my leather jacket, but the front was open and I felt entirely comfortable. I asked her perhaps a bit incredulously if she was actually cold.
"Oh yeah", she answered. "I'm freezing. It's so cold in here!"
I paused for a moment before telling her, "I was just in Utah. We got close to a foot and a half at my house last week. It's not cold here."
Now my driver was asking if I was ready for the storm. I'm in Atlanta. From what the locals tell me, in the years that it does snow, it rarely sticks. Ice is still a big concern, but the snow is never more than a dusting.
My sister used to live in Atlanta. I remember visiting her here close to a decade ago. She informed me that Atlantans are generally good drivers, but when it rains, they forget how to drive. Unfortunately, as she pointed out, it rains every other day in Atlanta. The locals I've met this time around have agreed with that statement fully. They also tell me that if a single snowflake ever comes within sight of Atlanta, the city is paralyzed. And now we had "a snow storm" on its way. You can imagine my excitement.
I wasn't the least bit surprised on the ride home today when traffic was even more of a mess than usual. It took close to twenty minutes to leave the parking garage. One of my students was staying at the hotel one block past mine, so he had offered me a ride. As we listened to the radio, the DJ talked about how it was too early just yet to predict school closures. Looking out the car window, I could see that the snow was sticking to the plants, but doing nothing to the roads other than making them wet.
Once we finally got out of the parking garage, it didn't take long to get back to the hotel, which was less than a mile away. It was cold outside, don't get me wrong. But compared to Utah this time of the year, it felt almost tropical to me.
Right now I'm waiting for traffic to die down a little bit, so that I can gas up my own car at the CostCo down the street. I have a rental car here, but I'm not bothering to use it for anything other than getting to and from the airport. I figure if the shuttle bus decides not to get me, I can use the walk. During rush hour in Atlanta, it may actually be faster.
Wednesday, January 16, 2008
Wednesday, January 9, 2008
A Tale of Two Waitresses
I got an interesting email today from my Zagat subscription. It linked to a story about two similar experiences that somebody had in Vegas, back to back, with two different waitresses.
In the first experience, the customer asked for a strip of undercooked bacon to be made "crispy", an act that would likely take a matter of only another minute or so for the cook. Not only did the waitress give them grief before finally relenting, when the bacon came back it was technically "crispy", but also "stiff as a board".
In the second experience with a different waitress, the customer asked for their eggs to be served separately, and halfway across the room (their daughter apparently greatly dislikes the smell of eggs). This waitress didn't even blink, and in fact asked whether they wanted the eggs or the rest of the meal served first. When asked if that was the strangest request she'd ever gotten, she replied, "This isn't strange. Honey, it doesn't even come close."
A comparison is to be made between the two waitresses, one of which is obviously unreasonable, and one of which obviously cares deeply about her customers, or at the very least doesn't mind the occasional odd request. Is it a valid comparison? Not quite, in my opinion.
If I were cooking bacon at home for my family, and my daughter (who is not, at the time of this writing, actually old enough to eat bacon) asked me to take a floppy piece of bacon and make it crispy, it wouldn't be a big deal. Presumably, it should also not be a big deal for a professional kitchen at a high end restaurant who, I might note, likely has to serve breakfast for anywhere from dozens to hundreds, to perhaps even thousands of guests in a very small space of time. When thought about it in that sense, the cook has to take extra time and resources to handle just another request which, in all likelihood, they don't actually have time to handle.
The waitress knew this. It had probably been burned into her skull by the kitchen staff every time she agreed to make a special request for a customer. This can be confirmed by the fact that she informed the customer that "the kitchen won't like that". She apparently handled the situation with rudeness. I don't know if she was actually rude, or if her initial refusal was only interpreted as such by the customer. I'm guessing that she was only trying to deflect what was about to become grief from the cook who had to handle the request. In an act of relentment to provide customer service (or at least avoid having the customer ask for the manager), she finally agreed.
The customer notes their mental response to the waitress: "The kitchen won't like that? Excuse me. Is the kitchen paying for the meal? Does the kitchen really care about cooking bacon a little longer?"
Yes. In fact, they probably do care about cooking the bacon a little longer. How did the cook handle the request? He apparently did fulfill the customer's request. He may have been belligerent with it, apparently cooking the bacon to a level of crispness that he knew nobody would ever be happy with, but he did fulfill the request. He might have even seen the extra crispiness as a sort of revenge, and for the customer's sake, I hope that's the only sort of revenge that he decided to exact upon her (though I doubt it).
He could have handled it differently. He could have just set the bacon aside on the griddle, let it cook a little longer while he did his other duties, and then when it was done, moved it back to the plate, and the plate back to the heat lamp, where it would be brought back to the customer. It would still have been an annoyance, but he could have done it. He apparently decided to teach what he considered to be an unreasonable customer a lesson in the process.
How does this compare to the second experience? The customer wanted their eggs to be served separately, and at a different interval from the rest of their meal. This request requires no extra involvement from the kitchen. The waitress could easily ask for two different plates (one with the egg and one with everything else) as if they were two different orders, and then handled them as such herself. Waitresses do this sort of thing on a regular basis, and the kitchen (who, again, was likely swamped) would never know about it.
She could also have involved the kitchen, and this is where a difference could be apparent. If she involved the kitchen, she certainly didn't mind doing so. Perhaps she has a better working relationship with the cooks. Perhaps she knows how busy the kitchen is (or isn't) and doesn't mind bullying a cook to get things done. I have often seen this willingness to bully the cooks define a waitress that refuses to place any priority above customer satisfaction.
I'm guessing that she chose not to involve the kitchen any more than necessary. She was obviously experienced enough at her job to have seen a lot of strange things. This tells me that she was probably also experienced enough to be able to handle such a request on her own. While each request likely carries equal weight in our own home kitchens, the request involving the egg is drastically easier to manage in a high-production environment such as one might see in Las Vegas, America's playground.
What is the point of all this? Unless you have worked in a restaurant, there is no way you can possibly know how difficult it is to do so. You may think you know how reasonable a request is, but until you're the person fulfilling the request, you probably don't.
Why do I bring this up? I eat out a fair amount when I travel (about 2 - 3 weeks a month), and occasionally when I'm in my home state. I see a lot of examples of customer service, both good and bad. And I see a lot of reactions from my peers, both good and bad. I've cooked in kitchens and I've waited tables. My first inclination is to put myself in the shoes of the serving staff and the kitchen staff. If my food is late, I know that it's likely (though not always) a problem in the kitchen. I don't start mentally subtracting pennies from the server's tip, unless I have a really, really good reason. In fact, I'm more likely to start mentally adding pennies to the tip based upon how good the service is.
I can only recall one instance in my life where a server was so utterly incapable of providing decent enough service that I felt they deserved to be tipped less than 15%. In fact, she was reportedly fired less than two weeks later. I prefer to tip at least 20% (despite being from Utah), and often tip more if the service was excellent.
Next time you're in a situation like that, think a little bit about what you're asking for. Is your server being unreasonable, or are you? Take a few hints from them. If they tell you that "the kitchen won't like that", they're likely telling the truth. Deal with it. I don't want to hear your whining unless it really is warranted.
In the first experience, the customer asked for a strip of undercooked bacon to be made "crispy", an act that would likely take a matter of only another minute or so for the cook. Not only did the waitress give them grief before finally relenting, when the bacon came back it was technically "crispy", but also "stiff as a board".
In the second experience with a different waitress, the customer asked for their eggs to be served separately, and halfway across the room (their daughter apparently greatly dislikes the smell of eggs). This waitress didn't even blink, and in fact asked whether they wanted the eggs or the rest of the meal served first. When asked if that was the strangest request she'd ever gotten, she replied, "This isn't strange. Honey, it doesn't even come close."
A comparison is to be made between the two waitresses, one of which is obviously unreasonable, and one of which obviously cares deeply about her customers, or at the very least doesn't mind the occasional odd request. Is it a valid comparison? Not quite, in my opinion.
If I were cooking bacon at home for my family, and my daughter (who is not, at the time of this writing, actually old enough to eat bacon) asked me to take a floppy piece of bacon and make it crispy, it wouldn't be a big deal. Presumably, it should also not be a big deal for a professional kitchen at a high end restaurant who, I might note, likely has to serve breakfast for anywhere from dozens to hundreds, to perhaps even thousands of guests in a very small space of time. When thought about it in that sense, the cook has to take extra time and resources to handle just another request which, in all likelihood, they don't actually have time to handle.
The waitress knew this. It had probably been burned into her skull by the kitchen staff every time she agreed to make a special request for a customer. This can be confirmed by the fact that she informed the customer that "the kitchen won't like that". She apparently handled the situation with rudeness. I don't know if she was actually rude, or if her initial refusal was only interpreted as such by the customer. I'm guessing that she was only trying to deflect what was about to become grief from the cook who had to handle the request. In an act of relentment to provide customer service (or at least avoid having the customer ask for the manager), she finally agreed.
The customer notes their mental response to the waitress: "The kitchen won't like that? Excuse me. Is the kitchen paying for the meal? Does the kitchen really care about cooking bacon a little longer?"
Yes. In fact, they probably do care about cooking the bacon a little longer. How did the cook handle the request? He apparently did fulfill the customer's request. He may have been belligerent with it, apparently cooking the bacon to a level of crispness that he knew nobody would ever be happy with, but he did fulfill the request. He might have even seen the extra crispiness as a sort of revenge, and for the customer's sake, I hope that's the only sort of revenge that he decided to exact upon her (though I doubt it).
He could have handled it differently. He could have just set the bacon aside on the griddle, let it cook a little longer while he did his other duties, and then when it was done, moved it back to the plate, and the plate back to the heat lamp, where it would be brought back to the customer. It would still have been an annoyance, but he could have done it. He apparently decided to teach what he considered to be an unreasonable customer a lesson in the process.
How does this compare to the second experience? The customer wanted their eggs to be served separately, and at a different interval from the rest of their meal. This request requires no extra involvement from the kitchen. The waitress could easily ask for two different plates (one with the egg and one with everything else) as if they were two different orders, and then handled them as such herself. Waitresses do this sort of thing on a regular basis, and the kitchen (who, again, was likely swamped) would never know about it.
She could also have involved the kitchen, and this is where a difference could be apparent. If she involved the kitchen, she certainly didn't mind doing so. Perhaps she has a better working relationship with the cooks. Perhaps she knows how busy the kitchen is (or isn't) and doesn't mind bullying a cook to get things done. I have often seen this willingness to bully the cooks define a waitress that refuses to place any priority above customer satisfaction.
I'm guessing that she chose not to involve the kitchen any more than necessary. She was obviously experienced enough at her job to have seen a lot of strange things. This tells me that she was probably also experienced enough to be able to handle such a request on her own. While each request likely carries equal weight in our own home kitchens, the request involving the egg is drastically easier to manage in a high-production environment such as one might see in Las Vegas, America's playground.
What is the point of all this? Unless you have worked in a restaurant, there is no way you can possibly know how difficult it is to do so. You may think you know how reasonable a request is, but until you're the person fulfilling the request, you probably don't.
Why do I bring this up? I eat out a fair amount when I travel (about 2 - 3 weeks a month), and occasionally when I'm in my home state. I see a lot of examples of customer service, both good and bad. And I see a lot of reactions from my peers, both good and bad. I've cooked in kitchens and I've waited tables. My first inclination is to put myself in the shoes of the serving staff and the kitchen staff. If my food is late, I know that it's likely (though not always) a problem in the kitchen. I don't start mentally subtracting pennies from the server's tip, unless I have a really, really good reason. In fact, I'm more likely to start mentally adding pennies to the tip based upon how good the service is.
I can only recall one instance in my life where a server was so utterly incapable of providing decent enough service that I felt they deserved to be tipped less than 15%. In fact, she was reportedly fired less than two weeks later. I prefer to tip at least 20% (despite being from Utah), and often tip more if the service was excellent.
Next time you're in a situation like that, think a little bit about what you're asking for. Is your server being unreasonable, or are you? Take a few hints from them. If they tell you that "the kitchen won't like that", they're likely telling the truth. Deal with it. I don't want to hear your whining unless it really is warranted.
Tuesday, January 1, 2008
Nutritional Information for Recipes
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:
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:
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:
Let's take for instance Red Bull:
The nutrient data line for the caffeine looks like this:
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.
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.
Friday, December 28, 2007
Recipes with Media Content
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.
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.
The Happs
I think I've managed to confuse a lot of people lately. The comments that I've been getting on my recent posts confirm that. First, without any warning whatsoever, I start posting all of these articles about what recipe software needs to be like. I didn't explain why I was doing it, I just did it. And then in the middle of it all, I disappear for a while. What's up with that?
Let me explain the easy one first. I was in Mountain View, California the week before Christmas. The training center that I was teaching at was on Castro Street (which is not the same Castro Street as in San Francisco). Castro Street in Mountain View is a center of cultural diversity. I was within walking distance of Thai, Japanese, Chinese, Vietnamese, Korean, Indian, Indian-Chinese fusion, Irish, Greek, Scottish (?) and a few other types of restaurants. For the record, I don't recommend the Greek place. It was worse than crap.
Anyway, the point is, I didn't really spend much time on my computer in the evenings. And when came home, we had no Internet. Fortunately, the holiday season managed to distract me enough that I didn't miss it too terribly until today, when I finally got around to talking the new landlord into hooking up the wireless again.
As to the recipe software. Some of you may recall some time ago when I was working on something called the Open Recipe Format (ORF). Long story short, people got busy the project was back-burnered for a while. I still had it in the back of my mind, expecially lately. Then a couple of weeks ago, Tuxgirl was asking me some questions about recipe software. I got a wild hair and decided to start talking about what I wanted to get out of recipe software. I figured it would be the best way to explain to other developers why I want to do the things I want to do.
If somebody else takes a look at my articles and decides to write their own software, so be it. At least somebody is doing it. I didn't have a whole lot of time then, especially since it was really a bad idea to work on it at work. I work for a completely different company now than I did when I started ORF, and my free time is different. I still refuse to work on it while I'm in the classroom, but I'm starting to have plenty of time when I get back to my hotel at night. I'm hoping to spend some serious time working on it again.
In the mean time, I still have a lot to say about recipe software and I'm gonna keep saying it. It's great having your own blog, isn't it? I also have a couple of dishes that I've cooked and taken pictures of, so if that's what you read this blog for, stay tuned.
Let me explain the easy one first. I was in Mountain View, California the week before Christmas. The training center that I was teaching at was on Castro Street (which is not the same Castro Street as in San Francisco). Castro Street in Mountain View is a center of cultural diversity. I was within walking distance of Thai, Japanese, Chinese, Vietnamese, Korean, Indian, Indian-Chinese fusion, Irish, Greek, Scottish (?) and a few other types of restaurants. For the record, I don't recommend the Greek place. It was worse than crap.
Anyway, the point is, I didn't really spend much time on my computer in the evenings. And when came home, we had no Internet. Fortunately, the holiday season managed to distract me enough that I didn't miss it too terribly until today, when I finally got around to talking the new landlord into hooking up the wireless again.
As to the recipe software. Some of you may recall some time ago when I was working on something called the Open Recipe Format (ORF). Long story short, people got busy the project was back-burnered for a while. I still had it in the back of my mind, expecially lately. Then a couple of weeks ago, Tuxgirl was asking me some questions about recipe software. I got a wild hair and decided to start talking about what I wanted to get out of recipe software. I figured it would be the best way to explain to other developers why I want to do the things I want to do.
If somebody else takes a look at my articles and decides to write their own software, so be it. At least somebody is doing it. I didn't have a whole lot of time then, especially since it was really a bad idea to work on it at work. I work for a completely different company now than I did when I started ORF, and my free time is different. I still refuse to work on it while I'm in the classroom, but I'm starting to have plenty of time when I get back to my hotel at night. I'm hoping to spend some serious time working on it again.
In the mean time, I still have a lot to say about recipe software and I'm gonna keep saying it. It's great having your own blog, isn't it? I also have a couple of dishes that I've cooked and taken pictures of, so if that's what you read this blog for, stay tuned.
Wednesday, December 19, 2007
Same Recipe, Multiple Scalings
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:
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.
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.
Tuesday, December 18, 2007
Adding HACCP to 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.
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.
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.
Subscribe to:
Posts (Atom)