Is anyone working on let's name it CookHub already? So essentially GitHub for receipts. The nerd in me wants to fork receipts and share my small adaptations to the community.
That would be pretty cool. It would already work in github, but yeah a dedicated site would probably be better ;-). I'm afraid that the intersection of people interesting in cooking and people who know how source control works is likely pretty niche
The other problem I have with community cooking websites is that usually people always underestimate the cooking time and that's annoying as hell. Like people would say you need to cook onions for 10 minutes, while onions take close to 25 minutes to be cooked. On the French website marmiton, it was so ubiquitous that they have moderators come in and fix people's recipes.
My issue with recipe timings is that even if you cook things for as long as it says, the overall time to cook the recipe is always very "optimistic". I assume the issue is some combination of marketing and the fact that the test cook was done by a professional chef who can dice 10 onions in a minute.
The main problem for me (who am interested in cooking, as well as somewhat au fait with version control) is that at this point in my life, I could not for the life of me write down a recipe for almost anything that I cook, because it is all based on "enough" and "to taste", with cooking times being in the "well, you look at the ingredients and a cooking schedule effortlessly forms in your mind" (none, by the way, based on actual time), allowing me to do things like cooking things in the oven and three or four pots on the stove, and have everything ready at the same time, by staggering the start times.
And I literally cannot tell you how I do it, because at this point, I don't know. I do know how I got there, though. Cooking, lots of it, at various scales and in variously equipped kitchens.
Scale-wise, I have cooked for 1. And on the upper end, I have cooked for about 50.
Fantastic idea! Another benefit I can think of having such a repository combined with this markup language is powerful semantic searches - filtering by sets of ingredients, and perhaps adding the ability to add tags to the recipes
Yeah, the same here :-). We created a placeholder repo https://github.com/cooklang/recipes, but it still subject to workout structure and probably it makes sense to standardise units in some way.
I’m not sure you’d want to fork it like version control does. If someone makes a variation that is not a correction, you’d want to have that easily available on the main repo with a link back to the original.
https://www.cinc.kitchen/info/features lets you fork recipes. forkthekitchen.com (now dead) was another similar effort. So did diy.soylent.com (now dead as well).
hRecipe looks like it's just HTML/entirely web-based, and Schema seems like it covers way more than it reasonably should.
I personally think CookLang is the better of these, even this early on.
hRecipe is over 10 years old, and the point of microformats is to extract semantic data from HTML. It's not really solving the same problem as CookLang in the way HTML and JSON aren't solving the same thing.
While I don't know much about the history of Recipe in Schema, I find "covers way more than it reasonably should" to be an odd criticism of a format. I usually find it to be a mark of schema maturity. All concepts behind data formats have more complexity than an initial investigation would uncover (see also: Falsehoods Programmers Believe About Names[1]). If anything, it leads me to believe CookLang has a ways to go.
I've been working on a stove safety/smart cooking device which is based on the temperature of your pan [0]. There are a small number of recipes which it currently works with [1]. To do this we defined a JSON format for recipes [2] but if we could use something similar to the text format used by CookLang that would be amazing, as it's much easier to write than JSON and could also be automatically rendered into a web page. Currently we are writing it twice - once in JSON for the cooking app, and once in human readable form.
The newsletter pop-up made your site unusable on mobile. Hard to close, and then it kept coming back. Obnoxious and rage inducing. I hate your product now.
I'd be interested if there's research showing whether a one-off popup gives more signups or more annoyance. The marketing people seem to think it's better to have it there.
I agree it's hard to close, I'll see if I can do something about that. It shouldn't keep coming back once closed, which browser are you using? Although it does come back if you refresh the page. I might be able to do something about that as well.
I'd be interested in a paired device to interrupt the energy source to the stove. If danger is imminent and the operator hasn't responded in a certain timeframe, a connected valve would turn the gas supply off or a switch would trigger the electricity to turn off.
Growing up we had a sensor in the oven go out, causing the cookies to catch on fire inside the oven. We also had a control board on a Whirlpool dishwasher start smoking ~15 years ago. There was a class action lawsuit against Whirlpool, but we didn't have any documentation that showed the model and serial number of the unit, so we couldn't get the typical "$20 credit for your next appliance purchase" or whatever the compensation was.
In both cases, flipping the electricity off at the breaker prevented further damage.
Thanks for the suggestion! We did consider the idea of making it automatically cut the energy source. However at the moment, the install steps are: receive it in the post, pull out the battery tab, and stick it on your stove splashback with a strong sticky pad. Almost anybody can do it themselves. As soon as you need to cut the electricity/gas it requires a qualified engineer to go in and install it, making the install cost an order of magnitude larger. So this wouldn't be a part of the core product.
As an optional paired peripheral, it's a good idea, and perhaps we will look into it further if the main product has some success. If individuals consider it a valuable addition then they could pay to have it installed. A secondary drawback would be reduced battery life on the device, as it would be continuously paired over Bluetooth whenever the stove is in use - usually it is just passively advertising in case you are trying to connect through the phone app.
In terms of saving lives, the automatic cut-off would make a relatively small difference - fire department stats (on smoke alarms) show that having a loud beeping alarm is extremely effective at attracting attention and is enough for the user to go and turn it off manually, or to get out of harm's way if things have turned bad. Where the automatic cut-off would help is in reducing the chance of the house being damaged by smoke or fire when the user is out of range.
Actually, if one defined an XML or SGML DTD, you could inter-weave text and mark up seamlessly without having to create yet another markup language; another reason to standardize is not having to write readers/writers/converters again and again.
I'm curious - have you tested with oils with various smoke points? How does your device know which smoke point to monitor for? That's a 300F range (225 for Sunflower oil - which nobody should cook with, but if you want to prevent fires, look for the people doing things they shouldn't do, but that are convenient. 300F for butter, 520F for avocado oil)
Also, since I have a thing for flambee dishes - how does it deal with pyromanic chefs? ;)
It doesn't know which smoke point to monitor for. However, the aim (at least for the MVP) is for it to work the majority of the time for the majority of users - and critically to alert several minutes before there is any flame. So while sunflower oil may start smoking a small amount, it would be several minutes more getting to flame, by which time the alarm should have sounded.
If you put a frying pan on with oil in and leave it, the device will alert you at around 450F. This is a fixed threshold (along with some other checks, e.g. we also consider the rate of change of temperature). This gives reasonable behaviour in most cases, and ensures you don't get nuisance alarms when frying on high heat. In cases where individuals have an unusual cooking pattern which causes unreasonable false alarms we can adjust the model parameters to increase/decrease sensitivity in particular situations. In the future we may be able to adjust these automatically but for now there is not a great deal of automated "learning" involved.
If you're a pyromaniac chef, I think you would get some alarms from that! Again this is a bit of an edge case so we haven't but much effort into that for the first iteration of the product, definitely something for the future though - I can imagine it being a challenge to distinguish flambee and a real fire though, since flambee is real fire!
I was actually thinking about my wishlist for recipe apps the other day. Some key features:
1. Split up ingredients into more parts.
2 tbsp ground black pepper is actually:
Quantity: 2 tbsp
Ingredient: Black Pepper
Preparation: Ground
2 finely chopped scallions, just the white parts
Quantity: 2
Ingredient: Scallions
Preparation: Finely Chopped
Note: Just the white parts
Often you'll have apps (like plan to eat) that adds the preparation to the ingredient and makes shopping lists much harder to manage
2. Ingredient replacements. Often you'll see recipes calling for one ingredient and then has "You can replace this with x and y". It would be extremely nice to have this programmatically available. I know if I can't find scallions, I can replace it with garlic and onions.
3. Variants. Often I have the same core recipe in my recipe book with just different variants. Meringue cookies with different flavors. 90% of the recipe is all the same, but it's duplicated a dozen times for a dozen specific flavor add-ins. It would be extremely nice to have this somehow programatically available, so I can have the base recipe and all the variants with a reused core :)
I wrote a service called Zestful that does exactly this.[0]
It's an interesting problem. It's hard to train an ML system on the distinction between a preparation instruction like "finely chopped" and a note like, "just the white parts." My system treats "just the white parts" as a preparation instruction, but it throws away as irrelevant things like, "My favorite brand of black pepper is Smith's Fine Peppers." But I've looked at thousands of ingredients, and there are lots of wacky edge cases.
I created the service by adapting an open source project the NY Times published and then abandoned.[1] They were trying to index all of their old recipes for what would eventually become cooking.nytimes.com. Their repo felt very experimental and half-baked, so it was interesting to turn it into a production service. I wrote about the process of creating the service on my blog.[2]
Agreed - I've always wished recipes would have two ingredients lists: one for shopping and one for prep. Like some recipes will call for half a cup of diced onions... So do I buy one onion or two? And recipes that spread ingredient prep throughout the steps make it a pain if you want to prep up front. Having a semantic list of ingredients means you could display them in whichever format is more helpful in the moment.
My other gripe is when recipes tell you to prep 4 tbsp of an ingredient but aren't clear that you only use 3 in an early step and are supposed to save the other 1 tbsp for an end step. Not sure how this could be programmatically solved though
The amounts could just be tied to the steps. So maybe step 2 is to add 3 tbsp of ingredientX, and step 5 is to add 1 tbsp of ingredientX. So programmatically, the ingredients list would be the cumulative amounts of all ingredients described in each step, which would be 4 tbsp ingredientX.
2 and 3 certainly useful features and some day we'll have it in Cooklang.
As for 1. I had this before in spec:
> To modify the ingredient any other way, use parentheses.
> Add @onions{3}(finely chopped) to the mix...
After some testing, it turned out that it makes the overall cooking flow a bit convoluted. This modifier is an implicit step of the recipe. Imagine that we have this modified ingredient in the middle of a recipe. I have my frying pan full of things and next step is to add onions. But I suddenly realised that it's time to finely chop onions and I don't have time for that.
We can create these steps automatically and place them before everything else, but it may not be always the optimal way.
Note: this will significantly reduce the life of your oven. The self-cleaning cycle is torture for the oven components. They are not really built to withstand the heat.
Just out of curiosity, is there any interop that you'd personally benefit from? I'm unfamiliar with schema.org's more ephemeral schemas and how commonly they are used.
What's the markup for "unrelated long-winded story because I wanted to be a writer"? :) Great idea, and I agree with another commenter that a github-style recipe sharing/forking system would be a good addition.
The intro serves a couple purposes. It ensured the text of the recipe was "below the jump" on RSS readers, so the audience had to go to the original sites (and see ads). It helps detect and trap plagiarists - it's copywritable, while a recipe isn't. But it also contextualizes the recipe. It's really important for me to understand if I'm seeing an easy weeknight favorite or a labor-of-love Sunday meal.
Beyond just looking at the timing, I want to know how a cook thinks about the dish. If you open cookbooks, the intro spiel is common, and I often find it more helpful than the actual text of the recipe. There's a million places I can read a recipe for pad Thai, but Andy Ricker and Leela Punyaratabandhu have some deep insight that is very valuable.
Certainly some authors are crappy writers and don't add value here - I don't follow those people. Googling for recipes will turn those people up too often.
I heard that the long-winded stories also serve to make the text longer for SEO purposes. i could imagine that it makes you stay longer on the page, because you look for the recipe. Also, more text equals more opportunities to insert ads.
This is an unnecessarily harsh characterization. Recipe writers are constrained by economics, just like the rest of us. It's dismaying to see such cruel mockery on an industry forum. You may also want to look into Fundamental Attribution Error: recipe writers are "flawed", in your mind, but do you judge yourself so harshly? Likely, not. You probably excuse your own misbehavior as compelled by transient circumstance.
Readit News
Is anyone working on let's name it CookHub already? So essentially GitHub for receipts. The nerd in me wants to fork receipts and share my small adaptations to the community.
The other problem I have with community cooking websites is that usually people always underestimate the cooking time and that's annoying as hell. Like people would say you need to cook onions for 10 minutes, while onions take close to 25 minutes to be cooked. On the French website marmiton, it was so ubiquitous that they have moderators come in and fix people's recipes.
Edit: see https://slate.com/human-interest/2012/05/how-to-cook-onions-...
It's up to recipe author to define what they cook and how. If you think 25 min is better, fork it.
And I literally cannot tell you how I do it, because at this point, I don't know. I do know how I got there, though. Cooking, lots of it, at various scales and in variously equipped kitchens.
Scale-wise, I have cooked for 1. And on the upper end, I have cooked for about 50.
At least the JSON conversion would be nice to have, then I could XSL-T it into RecipeML.
https://github.com/sinker/tacofancy
Doesn't use recipe-lang though, just uses markdown.
http://microformats.org/wiki/hrecipe
https://schema.org/Recipe
Mandatory xkcd link: https://xkcd.com/927/
While I don't know much about the history of Recipe in Schema, I find "covers way more than it reasonably should" to be an odd criticism of a format. I usually find it to be a mark of schema maturity. All concepts behind data formats have more complexity than an initial investigation would uncover (see also: Falsehoods Programmers Believe About Names[1]). If anything, it leads me to believe CookLang has a ways to go.
1: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
[0] https://mypippa.me/ [1] https://recipes.mypippa.me/ [2] https://recipes.mypippa.me/schemas/cookMLSchema3.0.json
I agree it's hard to close, I'll see if I can do something about that. It shouldn't keep coming back once closed, which browser are you using? Although it does come back if you refresh the page. I might be able to do something about that as well.
Growing up we had a sensor in the oven go out, causing the cookies to catch on fire inside the oven. We also had a control board on a Whirlpool dishwasher start smoking ~15 years ago. There was a class action lawsuit against Whirlpool, but we didn't have any documentation that showed the model and serial number of the unit, so we couldn't get the typical "$20 credit for your next appliance purchase" or whatever the compensation was.
In both cases, flipping the electricity off at the breaker prevented further damage.
As an optional paired peripheral, it's a good idea, and perhaps we will look into it further if the main product has some success. If individuals consider it a valuable addition then they could pay to have it installed. A secondary drawback would be reduced battery life on the device, as it would be continuously paired over Bluetooth whenever the stove is in use - usually it is just passively advertising in case you are trying to connect through the phone app.
In terms of saving lives, the automatic cut-off would make a relatively small difference - fire department stats (on smoke alarms) show that having a loud beeping alarm is extremely effective at attracting attention and is enough for the user to go and turn it off manually, or to get out of harm's way if things have turned bad. Where the automatic cut-off would help is in reducing the chance of the house being damaged by smoke or fire when the user is out of range.
Buy @red pepper{2}.
versus
<recipe> Buy <ingredient amount="2">red pepper</ingredient>.</recipe>
For the latter, standard tools like xmlwf or any good Web browsers built-in XML viewer already exist and work right away.
In any case, double maintenance of JSON and human-readable text will eventually lead to inconsistencies.
Also, since I have a thing for flambee dishes - how does it deal with pyromanic chefs? ;)
If you put a frying pan on with oil in and leave it, the device will alert you at around 450F. This is a fixed threshold (along with some other checks, e.g. we also consider the rate of change of temperature). This gives reasonable behaviour in most cases, and ensures you don't get nuisance alarms when frying on high heat. In cases where individuals have an unusual cooking pattern which causes unreasonable false alarms we can adjust the model parameters to increase/decrease sensitivity in particular situations. In the future we may be able to adjust these automatically but for now there is not a great deal of automated "learning" involved.
If you're a pyromaniac chef, I think you would get some alarms from that! Again this is a bit of an edge case so we haven't but much effort into that for the first iteration of the product, definitely something for the future though - I can imagine it being a challenge to distinguish flambee and a real fire though, since flambee is real fire!
Just the safety thing alone has me hooked.
1. Split up ingredients into more parts.
2 tbsp ground black pepper is actually: Quantity: 2 tbsp Ingredient: Black Pepper Preparation: Ground
2 finely chopped scallions, just the white parts Quantity: 2 Ingredient: Scallions Preparation: Finely Chopped Note: Just the white parts
Often you'll have apps (like plan to eat) that adds the preparation to the ingredient and makes shopping lists much harder to manage
2. Ingredient replacements. Often you'll see recipes calling for one ingredient and then has "You can replace this with x and y". It would be extremely nice to have this programmatically available. I know if I can't find scallions, I can replace it with garlic and onions.
3. Variants. Often I have the same core recipe in my recipe book with just different variants. Meringue cookies with different flavors. 90% of the recipe is all the same, but it's duplicated a dozen times for a dozen specific flavor add-ins. It would be extremely nice to have this somehow programatically available, so I can have the base recipe and all the variants with a reused core :)
I wrote a service called Zestful that does exactly this.[0]
It's an interesting problem. It's hard to train an ML system on the distinction between a preparation instruction like "finely chopped" and a note like, "just the white parts." My system treats "just the white parts" as a preparation instruction, but it throws away as irrelevant things like, "My favorite brand of black pepper is Smith's Fine Peppers." But I've looked at thousands of ingredients, and there are lots of wacky edge cases.
I created the service by adapting an open source project the NY Times published and then abandoned.[1] They were trying to index all of their old recipes for what would eventually become cooking.nytimes.com. Their repo felt very experimental and half-baked, so it was interesting to turn it into a production service. I wrote about the process of creating the service on my blog.[2]
[0] https://zestfuldata.com/demo
[1] https://open.blogs.nytimes.com/2015/04/09/extracting-structu...
[2] https://mtlynch.io/resurrecting-1/
My other gripe is when recipes tell you to prep 4 tbsp of an ingredient but aren't clear that you only use 3 in an early step and are supposed to save the other 1 tbsp for an end step. Not sure how this could be programmatically solved though
As for 1. I had this before in spec:
> To modify the ingredient any other way, use parentheses.
> Add @onions{3}(finely chopped) to the mix...
After some testing, it turned out that it makes the overall cooking flow a bit convoluted. This modifier is an implicit step of the recipe. Imagine that we have this modified ingredient in the middle of a recipe. I have my frying pan full of things and next step is to add onions. But I suddenly realised that it's time to finely chop onions and I don't have time for that.
We can create these steps automatically and place them before everything else, but it may not be always the optimal way.
Here it was removed: https://github.com/cooklang/cooklang-org/commit/1bd2f54c3363...
This instruction in the Neapolitan Pizza recipe got me interested. Surely there is an upper limit?
Turns out the Wikipedia article about oven temperatures [1] has a dedicated entry:
> Neapolitan pizza: 905°F (485°C)
Which is way more than I expected. I guess this justifies the “set oven to max“.
[1]: https://en.m.wikipedia.org/wiki/Oven_temperatures
Here's an interesting discussion on the subject of ingredient quantities [1].
[0] https://schema.org/Recipe
[1] https://github.com/schemaorg/schemaorg/issues/882
I cook and I write code but never at the same time :)
Beyond just looking at the timing, I want to know how a cook thinks about the dish. If you open cookbooks, the intro spiel is common, and I often find it more helpful than the actual text of the recipe. There's a million places I can read a recipe for pad Thai, but Andy Ricker and Leela Punyaratabandhu have some deep insight that is very valuable.
Certainly some authors are crappy writers and don't add value here - I don't follow those people. Googling for recipes will turn those people up too often.