Quitting, Per the Plan

Back in 2005 I had an idea to create a site that allows artists to sell their wares through the site, with me collecting a small fee for each sale. As I outline in this post, I made some mistakes in my approach that ultimately resulted in other companies beating me to market with the same idea. For a few years following I sporadically worked on the site and concept but never with any real vigor or drive.

About two years ago I decided that the idea still had merit but that I’d need to focus on a specific market that would give me an edge. Given that I planned on launching with my wood turning products and the fact that I know that art very well, I naturally decided to focus in on that niche. I put a plan into place for how I was going to market the site, how I was going to maintain it, and when I was going to call it quits.

To arrive at my plan I stepped back and asked myself what I wanted to achieve with the site. I decided that what I really wanted was an outlet to sell the products I make anyhow, while making a little bit of money, and the ability to allow other artists to do the same, should they choose to do so. It was never intended to be anywhere near capable of producing enough money to support me and could not interfere with my day job or family life.

Having that concept as my base, the rest of the planning was pretty easy:

  • I wanted the site to handle most of the day to day operations itself – sale notifications were automated, the site was designed so that customers could use self service features, other artists could interact through the site without my involvement (aside from the fee), etc. This would require a little bit more coding to automate some things that previously were manual, but not too much. In the end I basically had to drive products to the post office and the site handled the rest.
  • I wanted to limit the amount of money I put into it as I didn’t foresee a huge return. I arbitrarily landed on $500 seed money. Once that money was gone, no more could be put in. Any profit made from the site would be added to the pot as operating cash.
  • Once the money was gone OR one year passed by without starting to see at least a modest uptick in sales, I’d pull the plug. My choice which.

I was off and running.

As of today I am about a month shy of the 1 year mark. I’ve spent almost all of the money – a small chunk went to domain registration and hosting fees and the rest went to my marketing campaigns. The sales were able to cover the spread for a few months but haven’t averaged out enough to keep cash balances moving in the right direction. As of today, the site has $38.

So I’m sticking to the plan and calling it quits. Kind of.

I’ve been toying with the idea of pulling the plug for a few weeks now. While the site is pretty much fully automated, I still have to log in periodically to check security, logs, and other maintenance items, which takes up time that is in high demand right now. After thinking through the problems and my desire to still have an outlet to sell the art that I will make anyhow, I came to the realization that I should pull the plug on the site, but not the concept (yet).

I’ve decided to invest my remaining $38 into Etsy, the very company who beat me to the punch with the idea I was working towards back in 2005. With my product set it will cost me $7 to post my inventory for 4 months. If nobody buys anything at all, I can run Tanglewood for another 24 months ($38 / $7 = 6 payments [I’ll chip in a few bucks…]; 6 payments * 4 months each = 24 months) without having to worry about any sort of site maintenance at all.

Tonight I set up an Etsy storefront, shut Tanglewood Turnings down, and set up an automatic redirect from Tanglewood over to the Etsy storefront.

Was pulling the plug on my site hard? Of course. Was it the right decision? Absolutely. I made an objective line in the sand before I started and am sticking to it. Trying to trudge forward based on my emotional ties to what I’ve created simply doesn’t make sense. It isn’t hitting the business targets I set, thus it is failing. Bail out.

In this case I just happened to find an option that would allow me to extend the concept a little longer, while still not violating my objective exit strategy. The original Tanglewood site is sleeping now. In 24 months if I have no sales the Etsy Tanglewood store will be too.

Why I don’t use UPS

This is why I don’t use UPS for Tanglewood Turnings:

  • 4/2/12: Opened a new account and requested shipping api credentials.
  • 4/13/12: Finally gave up on getting WORKING credentials for the shipping api. Multiple calls, multiple emails, still not working. FedEx and USPS were both a matter of an email or web form.
  • 4/13/12: Closed account via web.
  • 8/13/12: Received invoice for $306.42 for shipping a package from China to Idaho.
  • 8/14/12: Called UPS.
    • Talked with 3 different people who all transferred me to someone else before the 4th person was the right area.
    • Each person needed only my 6 digit account number to verify who I was – there were NO authentication questions whatsoever.
    • The final person picked up the line, was silent, and only responded with “UPS.” when I finally said, “Hello?”.
    • After investigating my account the representative started explaining that the receiver had accidentally transposed some digits and proceeded to tell me what their shipping number is.

I decided not to use them originally because of their inability to supply me with some simple, working api credentials. I refuse to use them going forward because of their total neglect for basic security protocol.

There is no way that I should be able to authenticate to a point where I can make changes or bill charges to my account with just my six digit shipper number. This is easy to obtain and by no means guarantees my identity.

There is no way that any representative should EVER give me information about someone else’s account. Had I been a hacker I could have easily written down the six digit number and started shipping goods (or illegal materials) using the shipping number for this company in Idaho.

There is no way that a company should be able to fat finger their account number and result in the charges going to someone else. There should be at least two levels of authentication on this. At the very least the account name should be entered to avoid fat fingering (thought this would do nothing to prevent true fraud).

If you use UPS now take these things into consideration:

  • They make it easy to get your information or to use your account to ship things. While the charges are easily reversed you have to consider what is being shipped. Are they using it to ship drugs? Arms? Black market goods? Funding, plans, or materials for terrorists? Your name is on it so if it gets picked up, who do you think the feds are going to come for? Even if there are no legal ramifications, do you want that on your social conscience?
  • They make it easy to get your information. A series of phone calls to various departments would give a hacker the ability to get enough information to open accounts in your company’s name, yet because of the way they have their departments broken up, there would be no easily traceable trail of the hacker’s actions.

Rails Data Migrations Made Easy!

Introducing ActiveDataMigrations!

From the README file:

ActiveDataMigrations is a Ruby gem that allows developers to set up multiple migration locations, each of which can be run independent of one another. This library sits on top of ActiveRecord so all standard migration features remain available.

This is particularly useful in cases where you want to separate your data migrations from your schema migrations or where you have multiple steps in your migration process that must have other steps invoked throughout.

I’ve always felt that Rails migrations came up short in the area of data seeding and data migration. While you can use the standard schema migrations to manage your data it is a recipe for disaster.

For example, I’ve got my Tanglewood Turnings site that is now in production. I’ve got live customer and order data in the system so I can no longer simply apply a seed or global data update when I push updates out to production. Yet I still have a need to enter large amounts of new data.

In researching the problem on the interweb, the common answer in the Rails community seems to be to either add the data to your migrations files or to create a sql file and apply the changes directly. I personally make it a practice to avoid direct interaction with the database so I explored the migrations route. The problem was that my tests were failing due to the extra and unexpected data. So I added ” unless Rails.env == ‘test’ ” to the end of the data blocks. That stinks. As in bad code smell. Not a good option. The other alternative was to update my tests to accommodate the new data. That would have me updating test cases every time I updated production data. That also stinks.

So I decided to write a solution. I started out with this grandiose idea of somehow abducting the ActiveRecord::Migrator class, while still having it work within the Rails context, and twisting it to meet my own needs. Oh yeah, I also wanted to figure out how to do this without monkey patching. Figuring out how exactly to do this seemingly mundane task took me relatively deep into the Rails and ActiveRecord rabbit hole. While down there I realized that I was vastly over-complicating things and that I could achieve what I wanted with a couple lines of code and a new Rake task. The result was a Ruby Gem that is easy to use, easy to integrate, easy to maintain, and delegates 99.999% of its functionality right back to ActiveRecord, leaving it with the power and reducing my support overhead.

You can install it using:

gem install active_data_migrations

You can read the full write up, view the source, and get more information by visiting the git repository, here:

https://github.com/finn0013/active_data_migrations