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


When is it time to launch your new business?

There are countless articles out there on this topic, none of which will help you actually make a definitive decision for when the right time to launch is. The reason they won’t help you is because launching a new business is intrinsically subjective. There are so many variables that go into launching and running a business that even the best articles can provide only guidelines.

I’ll sum up most of the articles out there on this subject: Launch as soon as you can.

If you look past the simplicity of it, the answer and advice is dead on. It is important get your name out there and start building a relationship with customers. You can’t really do that unless you are live.

So, diving in deeper, what constitutes being ready? That depends on you, your business, your market, and your goals for the company. I can’t provide the answer to you but I can tell you what drove my decisions for my recent launch, Tanglewood Turnings.

Tanglewood Turnings started out entirely different from what it is today. Back in 2005 I had an idea for a website where artists from around the world could come together to sell their products without having to worry about all the technology setup and headaches of running a website – they could simply focus on their art. The site was going to be called TanglewoodArts.com and was going to become the de facto place for artists to sell their wares.

It didn’t work out that way.

I kept tinkering with the code and kept adding “just one more feature” and adding “just one more cool technology” until it was too late and Etsy had burst onto the scene and carved out a place as the leader in this market. I waited too long and lost my opportunity.

I viewed the software I was writing in light of things I’d like to see go into the product and the technologies I’d like to use instead of things that will allow the business to start operating. In hindsight I didn’t need 90% of the crap that I wrote, at least not for launch. While much of it is useful and may eventually get some use, the only thing I needed for day 1 was a way for artists to upload their products, a way for users to look at the art, and a way to process payments and orders. Instead, what I was building was a complex system that gave artists and admins fine grained control over all sorts of different aspects – artist profiles, preferred shipping methods, custom order request capabilities, etc.

I missed the mark and I lost my opportunity to corner the market before Etsy did. I failed because I couldn’t draw a line in the sand and say, “these are the only things we need for day 1 and no more.”

The entire time I was adding feature after feature, Etsy was gaining market share and becoming a household name. What’s worse is that I didn’t realize my mistake until it was too late.

After my realization that I missed my window of opportunity I let the code float for a long time – multiple years. I’d write a little code here and there but it was never with the goal of launching anything. Instead, I wrote code because it kept my skills up to date and gave me a good opportunity to stay abreast of the latest happenings in the constantly evolving world of Ruby.

Last year I decided that I wanted to spin the idea up again. In thinking this through I decided to focus on a niche market that I knew well – wood turning. So I started doing research and found that while there are a bunch of sites out there that sell hand turned pens, pencils, bottle stoppers, etc., there are none that a) allow multiple turners to sell through the same site and b) provide a real time custom product builder. I decided that those were my differentiating features. The multiple artists at one site I had. I had already started on the concept of a much more generic custom product builder. I had a working shopping cart, order, and product system.

So I drew my line in the sand. I would launch as soon as the custom product builder was ready in its most basic form. I did. (Note that I did take a brief hiatus to pursue another project, otherwise this timeline would have been more like 2 months instead of 8.)

Now, I have a name out there and I have actual paying customers. I’ve got an offering that is truly unique, allowing me to build a customer base in areas that other sites and vendors can’t fulfill.

Is the site done? Hell, no. I’ve got a list of an additional 50 features or improvements I’d like to make to the site. Right now I have to manually process payments for artists, when it could be automated. Right now users simply get the lowest shipping rate available when I’d like for them to have an option so they can dictate preferred shipping speed. Today I have to manually update various data points such as prices, availability, etc. change in the market when this really should be automated. The custom product builder currently has the capability to support things like accessories, however I’ve not loaded any into the system. The list of things that would make the site better, but weren’t necessary for go live goes on.

Unfortunately it took me losing a really good business opportunity to realize that I didn’t need all the crap that I was writing in order to start the business. What I needed was quite simple but I made it much more complex because I liked writing the code.

Your case is likely no different. Put all the items you want for your product in a list. Now go through each item and individually decide if that item is an absolute must for go live. These are things that your site simply cannot function without or things that you’ll miss out on differentiation without. Once you finish this process you should have a much shorter list. Now do it again with that shorter list. When you are done with that, do it again. Keep doing it until you are sure that you have carved as much fat as possible. Now, when that list is coded and tested, you are ready to launch.

This is the process I followed for Tanglewood Turnings, which worked well. This is NOT the process I followed for Tanglewood Arts, which resulted in failure.