Get this @!#$ing thing out the @!#&ing door already!

Wow, it’s been awhile since I’ve blogged at all.  As you can probably imagine, the final KitchenPC UI has arrived and, as tends to usually be the case, integration work took far longer than originally estimated.  The good news is that everything came out absolutely gorgeous and the folks at Merix were nothing short of a pleasure to work with.  Their code is clean and organized, and very easy to plug data into.  The problems I found, which were all fairly minor, were addressed promptly and they always fixed the problem on the first attempt.  They also came within the original budget estimate, even though a few design requirements were changed here and there.  If KitchenPC takes off, I’ll definitely be going back to them for any new UI designs I need to implement.

The second piece of big news is I finally feel confident announcing an official release date; KitchenPC will go live during the first week of October, 2010.  This is actually a conservative estimate, and if everything goes smoothly I should be wrapping stuff up late next week.  However, I decided to give myself a bit of wiggle room just in case any issues creep up.

Here’s a brief overview of the remaining work items before release.

Last minute bug fixes and cleanup

During UI integration, a few minor issues were discovered throughout the site.  These were issues that were small enough that I could justify putting aside for the sake of getting each page integrated with the new user interface quickly (Since Merix was waiting for their final payment.)  However, I’ll be spending Monday, Tuesday and Wednesday going through these items and finding solutions to most of them.  I also hope to find the time to integrate my auto-complete wheel with the ingredient picker, however I can’t promise this will make it in for the first release.  On Thursday and Friday, I’ll be out of town climbing up Mt St Helens (for the second time), which will be a nice “relaxing” break from KitchenPC (“Relaxing?  Climbing an 8,000 foot mountain?”)

Final Testing

When all known bugs are fixed, I’ll be going through each page with a fine tooth comb testing each feature and coming up with as many test cases as I can for each scenario.  This includes weird edge cases, looking for bad error handling, and just all around trying to break things.  Any bugs I find will be logged and triaged accordingly, and hopefully I can fix any major ones quickly.  I’m guessing this work will take up the first half of next week.

Performance Profiling

I hate to use the word “perf testing” here, as I feel performance is something built into the product from the early stages, however I feel it necessary to run some jMeter tests to get a good feeling of the hardware requirements needed to run KitchenPC.  I don’t estimate any database level bottlenecks as I’ve already done extensive testing with large amounts of data when designing the original database schema, and I’m pretty sure Postgres will have no problems even under high server load.  Hoewver, I do want to see how many users a typical web server can handle at once, and at what point it breaks (or response times get slow enough to annoy people.)  I think this will give me a good idea for figuring out what KitchenPC will cost to run depending on user estimates.  Apparently, investors like to know these sorts of details.  I’ve used jMeter before and simulating realistic user load is pretty easy.  There’s also a few websites I’ve run across that will pound your server with as much simulated traffic as you want.  Either way, I’ll spend the latter half of next week on this effort.

Server Setup

This work item should only take a day or two, and will include things like DNS configuration, setting up operating system images on the remote servers, and also investigating setting up multiple front end servers if necessary.  More on this in a bit.

Change in Plans?

I’ve also been putting in some serious thought into modifying my original beta rollout strategy.  My initial plan was to open up the site to 1,000 beta testers using an invite code strategy.  In fact, the invite code mechanism is complete and has been successful in the private alpha release.  However, my impatient side has waged war on my cautious, logical side (when did this blog turn into a Frosted Mini Wheats commercial?) and has nearly convinced it to drop the whole idea to skip right to a full on public beta release.  Here’s a few arguments in favor of such a ballsy decision.

• It gets right to the punch. This is either a product people want, or a product they don’t.  Just let people use the thing and see.
• Invite Codes are egotistical. When you’re a company like Google, you can entice people with your shiny new product, because you’re already all the rage anyway.  Geez, people eBay Google Voice invites.  No one has heard of me, so the sooner I get something real out there, the better.
• The Dot Com world waits for no one. With so many new recipe based websites springing up every month, the sooner you get a product out the better.  There might be a product just like mine around the corner, and the longer I wait, the sooner someone could beat me to the punch.  Not that first to market always wins, but you also can’t wait around too long.
• Server traffic is not the enemy. The original justification behind an invite code system was to gradually allow people to sign up and allow me to maintain control of server load as my budget and resources allow.  I had a fear of winding up at the top of Digg and getting a million hits and everything crashing, thus souring everyone’s initial opinion of KitchenPC.  I think this fear is justified but can probably be mitigated with cloud technology and proper planning.

To elaborate more on the last bullet point, I think if my servers did get flooded with a wave of “curious cooks” wanting to check out the next thing, that would be a problem I would want to have.  I would be quite the optimist to expect a huge onslaught of users on day one, as my blog has yet to get over 53 views in a single day, but worst case I could setup ten virtual servers and hack together a simple round robin load balancer or even use DNS to point to a random server as a temporary solution for a few days until things calmed down.  Ten servers would cost about $800 bucks to run for an entire month, but running them for only a few days then shutting down unneeded resources sounds like a worthwhile expensive to me.

In other words, using an invite code strategy would probably be a good idea for a website running on “real” server hardware, but when you can spin up new instances for 10 cents an hour, you can take a lot more precautions to counter unanticipated server load.  It is this reason I mentioned my plans to investigate load balancing technology and running on multiple servers.  My website is designed to be totally stateless, so any request can be answered by any server without any need for session state or anything.  I’d rather not look into SQL level load balancing, but I’m quite certain Postgres will be yawning quietly even if I get a ton of users.  The site simply isn’t database intensive, especially with the current side of the DB (I think it’s like 4 megs right now, yes megabytes.)  Fault tolerance is, of course, a whole other animal but during a beta, I don’t consider uptime critical enough to worry about.

With that said, I’ll be happy to get 100 signups on the first day.  If all my servers crashed under the massive load of anxious meal planning soccer moms, I’d be jumping for joy and calling all my friends, as I spun up a bunch of new virtual servers to handle the load.

The other big reason is pure media punch.  It seems so much more satisfying to announce the launch of a product.  “Here’s my product, go to this site, sign up or just logon with your Facebook account, and check it out.”  I really want to issue a press release and try to grab some media attention, or at least some mentions from the techie bloggers (who I’m sure I’ll be spamming post-launch as well.)  Doing a private beta release and then, a few months later, transitioning that into a public release creates a publicity gap.  Finally, having a public beta version out there creates that intangible satisfaction of being a real, legit company owner.  No longer is your idea “vaporware” or “I can’t show you yet”, but it’s released for all the world to see and judge and tell their friends about.  I can’t wait to switch my employer on Facebook over to “KitchenPC,” even if I’m technically just an LLC registered in Washington, paying myself a salary of one dollar per year.

Barring any huge disappointments during stress testing (such as finding out a server can only handle 10 users at once and there’s no easy fix,) this will probably be the route I go.  Anyway, I’m super excited and I think I know how an eight-month-pregnant mother feels.  The last few weeks have been crazy stressful and involved little sleep, but I’m proud of what I’ve created and for the first time, look at the site and am convinced that it’s going to be hugely useful to a whole lot of people.  From here, it’s just a matter of getting the word out and getting people to check it out, give me some feedback, and then turning this project into a viable, money-making business.

That’s it for now, back to work for me!