A fistful of tomatoes

One of the innovative aspects of KitchenPC is its ability to convert and aggregate ingredients from one form into another.  For example, chopped tomatoes and whole tomatoes can be tallied up and added to a shopping list expressed in weight.  Since a grocery store sells tomatoes by weight, you probably want that on your shopping list and not “5 cups chopped tomatoes.”  This “form conversion engine” is essential to not only accurate and meaningful shopping lists, but the meal planner as well.  If I say I have 3 tomatoes that I want to use up, the modeler can consider recipes that use tomatoes in chopped form, whole, or by weight.  Without this collection of ingredient metadata, KitchenPC would be relegated to your average recipe database with wanna-be shopping and planning tools that don’t really work.

The first version of the form conversion engine was extremely basic, and provided just enough functionality to prove the initial concept of a recipe website that innovated around this sort of ability.  However, the engine lacked certain functionality.  Primarily, it was only able to represent conversion ratios through weight.  For example, a form (1 cup of chopped tomatoes) would have a weight, always expressed in grams.  Since tomatoes were sold in weight, we could calculate how many “grams” of tomatoes you’d have to buy so that, when chopped, would give you x cups.  This worked for units as well, such as “1 slice of cheddar cheese” weighs about 28 grams, thus if you needed 4 slices of cheese, we can add this ingredient expressed in weight to your shopping list.

However, this design didn’t support the less popular conversions, such as items sold in whole unit or in liquid form.  I could not represent “two scoops of vanilla ice cream is equal to one cup. ”  If there was an ingredient used by weight but sold in volume (I have no idea what this would be!), then that sort of conversion path could not be represented either.

Earlier this week, I took some time to improve the conversion engine to allow these sorts of conversions.  The database can now store conversion coefficients in any unit (weight, volume or whole unit) and convert to any other unit, as long as a conversion path can be found.  This allows me to add some new units such as “squirts of Hershey’s Syrup” and “splashes of soy sauce.”  Though the database doesn’t yet make much use of this far more powerful conversion engine, you can expect some new unit types for the more popular ingredients in the near future.

Going through this code (which was among the oldest code in the KitchenPC source depot) also gave me the opportunity to do a lot more testing on the less common conversion paths.  I noticed converting from volume to whole unit (such as 1cup chopped onions = x whole onions) simply never worked, it just happens that this conversion path is not surfaced through any current ingredient in the database.  I wrote several new unit tests that now offer complete code coverage for every conversion type (no matter how silly) by mocking up fake ingredients and forms to convert.

If I did my job right, you won’t notice any change at all in KitchenPC.  Your shopping list will be as accurate as it’s always been, and digging up meal plans based on what’s in your pantry should be as smooth as ever.  Keep an eye out for new units being added to existing ingredients, and let me know if you notice any problems or have any feedback on how I can improve the existing database.