rockym93 dot net

archive · tags · feed

Grocery Package Management

24 September 201106:10AMthings

Shopping needs a solid dependency resolution system.

If you're familiar with Linux then you're probably nodding right now. If you're not familiar with Linux, that might take a little explaining.

This is dependency resolution in a nutshell: When you install software on most Linux distributions, the installer ("package manager") automatically hunts down all the other software you need to run it ("dependencies"), and all the dependencies for the dependencies, and for the dependencies of the dependencies of the dependencies, and so on. This (in theory) means that your system will always work perfectly, but won't have any extraneous software.

Before dependency resolution, you would install packages hapazardly, not knowing if you had everything you needed to make your program work, and not knowing if you had packages installed which did absolutely nothing. This meant that having a working system required experience and a fair whack of research.

And this is still the way shopping works. Think about it. You make a list, with a vague idea of what you want to cook for the week. You wander around the store, grab what you think you need, and some things which look good, and some things which are on special, and then wander out again and discover you've forgotten something important. And yes, I'm sure an experienced shopper/cook can work this stuff out from memory and research, but then again, an experienced sysadmin can do the same with software. What about the rest of us?

Here's how I'd do it.

1. Starting from scratch, through trial and error, establish a 'core' list. These are staples: things like bread, and milk, and butter, which aren't specific parts of meals but nevertheless get used up. Measure the average rate of consumption, and have the software track when these staples are running low, and add them to the list. This list shouldn't be fixed, since staples vary by household - for example, I've used almost no eggs while housesitting, whereas at home we go through a packet a week easily.
2. Establish 'packages' of related goods: for example, a sandwich fillings package, a breakfast package, a fruits package, and so on. This is for stuff which, like staples, will just get 'used up' but isn't necessarily the same every time. The software can again track rates of consumption and calculate package sizes so that they all run out simultaneously. Then, when they do run out, either randomly select or ask the user to choose a package. Packages could also be weighted by price, seasonality, and tastes, so you always get something which is cheap, fresh and tasty.
3. To this so far automatically generated list, add 'meals'. These are individual main meals (lunch or dinner, depending on culture) with their own specific ingredients list. Have the computer track quantities required for each recipe, so if (for example) two recipes require mince it can be purchased in bulk, and if you need tamarind paste and there's already an unexpired packet in the fridge, you can avoid purchasing duplicates.
4. The system can then calculate an ideal shopping frequency, based on how often you run out of stuff, use-by dates (realistic ones, not necessarily the lawsuit-preventative ones printed on packets*) and which days of the week and shopping locations are cheapest. It will auto-generate a list, and send it to your email, phone, or printer prior to your shopping day.

5. The potential for expansion is significant. For example, dietary constraints, weekly budgets, and other conditions could easily be established. Likewise, there's a potential for integration with online services, existent or otherwise:

6. Integrate with online banking and make a certain amount of money available.

7. Use GPS data to weigh cost savings against travel time.
8. Creation of a user-generated database of prices, expiry dates, recipes, and so on. This will probably be the most important.

There are two problems with this, as far as I can see. The first is that a piece of software like this, while not necessarily complex (it's basically just a database and calendar, with some maths sprinkled on top) it's still a long way beyond my programming ability (though that doesn't mean I'm not going to try.) Secondly is the vast quantities of data needed to make anything beyond basic functionality work. Sure, rates of consumption tied to names isn't difficult, but categorising expiries, seasonality and prices? That's a lot of data, which is where some kind of online repository would be useful - but that in itself requires a nonzero adoption rate, and we're back to square one.

Ultimately, it's a bit of a pipedream: it's a lot of effort to go to, and you have to use it for literally everything in order for it to work. But there's no reason it couldn't be implemented without using software. Track consumption rates on a sticky note on the fridge, plan recipes beforehand, categorise your shopping and actually know what's in your fridge and you'd be most of the way there without writing a single line of code.

Oh, and if anyone wants to actually build this? Go for it. It would be awesome. You could call it shop-get. Or shoptitude. shopman. The Ubuntu Shopware Center. Grocerymerge, which compiles from sauce. Or hey, how about yum? It's got the name down already.

Okay, I'll stop now.

*My milk 'expired' a week ago, and it's still fine.