Skis / Toys / Fun

Not technology startups, but human startups (aka small business).  At one level you can look around the Silicon Valley and see strip malls full of stores, but if you look closely you’ll see that there is very little variety.  Here’s two examples:

• Furniture
• Outdoor Gear

In the furniture case, there is almost no variety of stores in the area.  You either have Ikea, Ethan Allen, or some other chain retailer or you have a strip mall store that’s importing some low cost furniture from the pacific rim (almost all of these stores have the same selection).   What we don’t have is any mid-range dealers, who have broad selection.  What’s different is that when I’m in Reno there are at least a dozen furniture stores that have a variety of choices (from pacific rim to high end).  How can a city of about 200,000 people have better choices than an area of 5M?

Some insight might be gained by looking at outdoor gear, another speciality area.  Here I can name the stores in the area off the top of my head:

• REI
• Mel Cotton’s
• Sports Basement
• Sun Valley Ski & Patio
• Any Mountain

If you’ve been paying attention I’ve been looking for some Ski gear in July, which means that outside of being impossible, it’s almost pointless to go shopping locally.  However, in talking with people at work about the problem I did make the following observation, which is:

     Why does Reno have more independent retailers of outdoor & ski gear than the Silicon Valley?

The two theories come to mind:

• Cost of Labor
• Cost of Land

Most non-box retailer operate on fairly small margins, so the ability to find and maintain a staff who has some expertise in the goods that you’re selling is going to be very difficult if the cost of labor is high.  In theory in Reno you can make a living working at a sporting goods store or a furniture store.  However in the Silicon Valley that’s impossible!  So, not only are you now faced with hiring sub-standard help (think Fry’s) which really doesn’t serve your customers well.  You’ll also be faced with the double whammy that the cost of land (rent is ~$2-$3 /sqft) is so high that you’re unable to pay a premium for better talent.  Thus you end up in a vicious cycle where you’ve got low margins, high cost of labor and land and as soon as a week month or two come by, you’re dead.

The inability of the Silicon Valley to create a true diverse startup culture, limited to high margin ideas is a true cost.  We tinker but don’t foster tinkers.

Tags:

Can’t be just the high price of gas!  It’s Wednesday and there very little traffic and a pleasant 70 degress outside!  Track was a blast yesterday and not only did I run well (quite a few 75second 400’s) but I’m not sore today and …

IT’S A NICE DAY!

Tags:

It’s really hard to find ski gear in the middle of summer…

REI sucks, not only is 90% of the clothing closeout, but there isn’t anything outside of rain gear to be found.

Tags:

Found this on a old blog that I’m decommissioning — insight from an old WSJ article.

• Tip 1: Don’t slap your name on just anything to make a buck.
• Tip 2: Find weaknesses with existing products and fix them. The you can charge more.
• Tip 3: But raise prices cautiously; make consumers feel they got more than expected and don’t hide company inefficiencies behind price hikes.
• Tip 4: Seek new consumer bases, and design for them.
• Tip 5: Invest in products that consumers will always need.

Tags:

I’ve run into this problem a few times, but I’m putting out a call to see if anybody has some great insight into a good solution. To date, I’ve come up with three different approaches to handling user settings, but none of which I’m in love with. Other ideas, other comments, other ways?

Working assumptions

• It’s handy to access specific elements outside of the database (e.g. who has XYZ preference set)
• Databases appear to be better at storing small data than large (varchar < 255 vs. BLOB of 64k)
• There is no right answer

Small records only

First encountered this at Excite with Excite Mail, since we were using OpenWave as the backend we could store 255 bytes in one of their database tables, and it became a preferences store. Though of course it was a bit more restrive than the below SQL, it got the job done. With a bit of class wrapping ontop, it really works.

Pro:

Only one record type

Con:

End up with a chained dkey (signature_0, signature_1, etc.)

CREATE TABLE IF NOT EXISTS setting (
    account_id      int unsigned NOT NULL,

    dkey            varchar(20) NOT NULL,
    data            tinyblob NOT NULL,
    created_on      TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

    PRIMARY KEY     (account_id, dkey),
    FOREIGN KEY     (account_id) REFERENCES account(account_id) ON DELETE CASCADE
) ENGINE=InnoDB;

Small and Big records

Ok, so when you don’t want to deal with chaining of records you can create a BIG and SMALL store of data.

Pro:

No chaining of records

Easily delete keys (just delete from both and ignore errors)

Con:

Lots of extra model level helpers to determine where data should go

CREATE TABLE IF NOT EXISTS user_data (
    user_id         varchar(16) NOT NULL,

    dkey            varchar(20) NOT NULL,
    dtype           int DEFAULT 0,
    data            tinyblob,

    created_on      TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    PRIMARY KEY     (user_id, dtype, dkey),
    INDEX           (user_id, dtype),
    FOREIGN KEY     (user_id) REFERENCES user(user_id) ON DELETE CASCADE
) ENGINE=InnoDB;

CREATE TABLE IF NOT EXISTS user_data_big (
    user_id         varchar(16) NOT NULL,

    dkey            varchar(20) NOT NULL,
    dtype           int DEFAULT 0,
    data            blob,

    created_on      TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    PRIMARY KEY     (user_id, dtype, dkey),
    INDEX           (user_id, dtype),
    FOREIGN KEY     (user_id) REFERENCES user(user_id) ON DELETE CASCADE
) ENGINE=InnoDB;

Blob of doom

What about the idea that you don’t want your SQL store to have a clue, so save settings in one big blob (json, xml encoded, etc.)

Pro:

All the parsing is at code level, record management is easy (1 per user)

Con:

it’s a blob, you can’t really access it easily outside of your program

CREATE TABLE IF NOT EXISTS user_blob (
    user_id         varchar(16) NOT NULL,

    data            blob,

    created_on      TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    INDEX           (user_id),
    FOREIGN KEY     (user_id) REFERENCES user(user_id) ON DELETE CASCADE
) ENGINE=InnoDB;

Any other ideas? Cool suggestions, the magic solution I’ve forgotten?

Tags:

I bike… I bike more than average…  While a Poseur Jersey would be fun, I was thinking on my ride to work today that a shirt/jersey that said (primarily on my ride to work):

     The more I bike
     The less gas I use
     The more there is
     The cheaper it is
     The happier you are

Maybe then a few cars would be a bit more considerate.

Tags:   bicycle poetry