def combine[T](sets: List[List[T]]): List[List[T]] = sets match {
case List(l1, l2) => l1.flatMap(i1 => l2.map(List(i1, _)))
case head :: tail => combine(tail).flatMap(set => head.map(_ :: set))
case _ => sets
}
{ apple, banana }
{ milk, cheese, yogurt }
{ nuts, legumes }
— would result in —
{ apple, milk, nuts }
{ apple, milk, legumes }
{ apple, cheese, nuts }
{ apple, cheese, legumes }
{ apple, yogurt, nuts }
{ apple, yogurt, legumes }
{ banana, milk, nuts }
{ banana, milk, legumes }
{ banana, cheese, nuts }
{ banana, cheese, legumes }
{ banana, yogurt, nuts }
{ banana, yogurt, legumes }
I’m not an expert in inventory systems, warehouse management, production or product distribution of any kind. However, as ROSA LOVES continually evolves I will probably become one (or at least in certain areas). At ROSA LOVES our inventory is currently simple: we sell shirts. When we originally launched, everything came together extremely quickly, mainly because it had to. As it has become better known we’ve experienced various growing pains, one of them being inventory management. Now there are many pains we experience in this area, but I’m going to focus on the problem from the perspective of the store/inventory management software, as well as the underlying database schema. On to the problem.
As I said, ROSA LOVES sells shirts. However, it may not always be so focused, and the various options for shirts may change. The problem of products and their myriad of possible options is a well-navigated space, however I’ve not run across any public discussion from a developer’s point of view (hence my urge to post).
With any product to be sold, there are typically various options that must be managed at an inventory (and often a pricing) level. Consider, for example, the Hope Transfusion t-shirt. If you’ve never ordered a shirt from the site, a quick glance at that page will show you that it is available in one of two “styles” (men’s and ladies’), and in turn, one of several sizes.
A narrow-minded model of this then would express each of those options directly as tables (and associated software objects). So there might be 3 main tables: products, styles, and colors. And then there would be join tables binding the options into quantifiable items (ie, Hope Transfusion in ladies’ small, men’s large, etc).
This works fine until we either want to add a new kind of product or another set of options. It doesn’t scale well at all, so let’s abstract it a bit. In reality, what we’re talking about are products and their options. Specifically, what we call a “product” (like the Hope Transfusion shirt) is more of a parent entity, and each possible combination of options is a “child.” You can’t buy a Hope Transfusion, but you can buy a ladies’ medium. Recognizing and dealing with this addresses the problem of options, and we’ll expand on this later.
However there’s still one more problem: a store may very well contain many different kinds of products. Addressing the issue of combined product options works as long as you can assume the different kinds of options. The reality is of course, that you can’t. It makes sense for a t-shirt to have a group of options in the “style” realm, but that group might not apply to something like a pair of jeans, shoes, and probably not something even more removed like a camera. What emerges here is the notion of a product type, and not necessarily a type as in a class in object-oriented programming. I’ve started referring to this as a product’s stereotype.
Here’s where we’ve arrived:
In the next post I’ll get into a few specifics, as well as provide an example database schema and object model.
I’m a twitter user, you can follow me here. I’m also the nerd side of ROSA LOVES, and I do most of the tweeting for it as well. We’ve recently started sending out a newsletter via email quite regularly, and have been trying to combine that in various ways with our tweeting. A few days ago I realized I could easily create link that, when clicked on, would lead the user to their twitter homepage with the status text already completed with whatever text I chose.
Pretty cool and not sleazy, as it doesn’t actually tweet, it just makes it easier for a user to do it. This is accomplished by providing a GET variable “status” to the twitter home url, like so: http://twitter.com/home?status=hello. If you click on that link and are logged in to twitter, you’ll immediately see the results I described. If you’re not logged in, you will be guided to the login page and, upon successful login, taken to your profile with the status populated as described.
Useful for what we’re doing I thought, but I was wanting to step it up a notch. One of the major factors of the web 2.0 culture is the ease with which information can be created, spread or otherwise affected by general users. Think of how huge digg was (is?), how second-nature social bookmarking is, and how commonplace things like the Share This widget have become. What I wanted to create was a link that, when clicked, would result in a ready-to-tweet message as above, with the addition of link that would replicate the behavior tacked onto the end.
And so, I present to you this link. Click it. Go ahead. It’s a URL shortened via bit.ly that expands to a twitter message populating link. That link, in turn, contains another link by this same URL. The hope then is that a user will use it to tweet a message, and then his/her followers will see it, like it, and just click the link to propagate the tweet to their own profile. And so on, so forth.Here’s a quick and dirty howto:
Now you can use that URL directly in your browser to generate the twitter message with the embedded, recursive “tweeting” link. When posted, followers will see “Hello there (tweet: http://bit.ly/hellothere)”, and the link will propagate that exact message to their twitter status window when clicked. All they need do is click “update.”
