The slides from my presentation are attached here.

I’m a believer of the expression “you can’t manage what you don’t measure”. In the last couple of years, I’ve done a decent job of measuring exercise volume (thanks to Nike+), but not the other elements of healthy living. So, this year, my goals are basically to improve the one area I have already been measuring and start to measure other things I think will lead to overall health:

1. As previously committed, I’m setting a goal of improving my Nike+ workouts by 50% this year – from 58 to 87 runs.
2. I’m also resolving to post monthly counts of four other things that affect my overall health – physical and mental: healthy meals (currently defined as those that meet the “Michael Pollan test”), runs or other form of exercise, hours of television watched, and books completed.
3. Finally, I’m going to keep private counts for a couple things of a spiritual nature (e.g. days where I read scripture). I’m not a very public person in this regard, so I won’t be posting about it. But I want to count my progress anyway.

Of course, merely keeping track of counts of things and posting (some of) them regularly isn’t much of a chore. But, I’m obviously planning that this will be something of a trick I play on myself. If I have to come clean about how many of my meals are good, I’m hoping I’ll make better choices about what I eat. Furthermore, if I fall off the wagon for a bit, this will be easier to get back on.

That’s the theory anyway.

The site is in an alpha state right now. That means it basically works but it’s not hard to find bugs or opportunities for improvement. There’s a saying in the startup world – if you’re not embarrassed/worried by the first release of your product, you waited too long to release. I also like what Paul Graham had to say in his essay on what startups are really like:

It’s so important to launch fast that it may be better to think of your initial version not as a product, but as a trick for getting users to start talking to you.

Alright users – speak up!

The past year and change has really been a whirlwind. It actually all started in April of 2008 when Mike Blackwell and I decided we wanted to form a company together. We just needed to figure out what it was to do. I could not ask for a better person to go through my initial startup experience with than Mike. As the former CEO of ShareThis along with getting in on the ground floor of a prior startup that crashed and burned, Mike knew the ropes and was able to properly set my expectations and helped us to focus on the right things. He is also a great guy who has an integrity and perspective on life that I really admire.

Over the course of the past year, we’ve had several other folks come along and join the team in one way or another. Once we had settled on the right business idea (after many false starts), Bob Kington and LJ Freeman got involved as co-founders of the company in May of this year. In July, Sara Gibbons joined us and in November, Kevin Munc became employee #6. Gina Winkler also spent a fair amount of time on our project as did several other friends. And we could not have done this without the help of the guys at Edgecase, most especially Adam McCrea.

So, come and check us out and let us know what you think. Yes, I’m slightly embarrassed about the site’s flaws and shortcomings, but I guess that means we released in time. The next several months are going to be extremely busy (just as the past several have been) while we react to feedback and make improvements. I take it as a good sign that there’s a big part of me that wants to get started on those right now. But, it is Christmas time and rest and family time are also important. Have a Merry Christmas everyone and may your 2010 find you as excited by life’s opportunities as I am.

There are several good reasons to like Braintree as a processor for your site:

• They allow you to treat payment processing and merchant account handling (two separate things) as if they were one.
• They relieve you of the requirement to hold sensitive data (i.e. credit card numbers) in your database, thereby making PCI compliance much less of a headache than it need be
• They have a well documented and relatively simple API to develop to that is a piece of cake to integrate into a Rails app
• They have some folks on staff who are Columbus Ruby Brigade alumni

So, after a brief survey and at the suggestion of colleagues, we decided to use Braintree for our site. We’re not yet live on that site, so I’ll keep details of it somewhat private at this point. But you can think of the site as one that uses a model similar to StubHub or Glyde (sexy UI by the way fellas) but in the travel/vacation industry. Watch this space over the next couple weeks for more details.

At any rate, we first contacted Braintree about 2 months ago and began a dialog about engaging their services. This included a discussion of our business model, anticipated transaction volumes, revenue projections, and the like. Given that we were not yet done with development, we did not submit a formal application with them at that time. Instead, we continued work on the items we knew Braintree wanted to see (e.g. clear communication about pricing, customer support contacts, terms of service, etc.) as well as the more core features of the site. During this time, Braintree allowed us to develop against their development gateway and occasionally asked us if we had any questions (we did not – it all appeared straight forward to us).

This week, the time came to actually begin the formal application process. Which is when we ran into problems. As mentioned above, one of the things Braintree does for its customers is handle the merchant account setup. It turns out that this was a more significant step than I thought. Once the underwriters saw our site, they declared it a high risk site and refused to underwrite the creation of the merchant account for us. It’s not clear why we were considered high risk when other sites with essentially identical business models in different industries are allowed to proceed. The message given to us is that our customer guarantee (which currently looks SHOCKINGLY like StubHub as we refine it for our specific case) was something they didn’t want to cover. But, they let us know, they’d be happy to work with us if we changed our business model in fundamental ways.

So, I was frustrated with Braintree for a few reasons:

• The risk issue was not detected by them in a timely fashion.
• Resolution of the issue was poorly handled. For example, we didn’t get a chance to talk directly to the underwriter to make sure they were clear on the model and risks (or lack thereof in our case)
• The only suggested remediation was to fundamentally change our business model. I have to believe we could have perhaps explored intermediate options (e.g. holding some reserves in the merchant account) but Braintree did not make those available to us.
• In the end, I just believe that Braintree didn’t necessarily do a good job at being an advocate for us in one of their core value propositions (i.e. setting up the merchant account)

Of course, we’re not without blame in this too. One of the great things about working in a startup is that you learn things at such an insane pace. Here are my lessons learned, hoping the future entrepreneurs might avoid some of the mistakes we’ve made:

• Don’t under-estimate the merchant account creation process – especially in this economy with banks still being fairly risk averse
• Always have a backup plan. We didn’t in this case, and now we’re scrambling to get another solution in place
• Don’t let it get you down and tweet out of frustration. After all, a bad day at a startup is still better than most days in a big company.

So, I hope that didn’t come across as too whiny or unfair to Braintree. I definitely think they could have done better and hope they’ll do a better job with future customers. But I know too that most people who use them still think very highly of them. Sadly though, that won’t be with us.

http://www.youtube.com/watch?v=H9TVd3lqLng

Like many new to git, it took awhile to get past the centralized mindset that had been pounded into my brain by years and years of thinking of CVS and SVN as the be-all and end-all of how you did these things.  Solving my problem of switching machines without impacting my teammates is one of those things that helps to rewire my thinking.  I how have four git remote’s that I use regularly.  The first three were set up for me more or less without me knowing what was really going on:

origin – aka github.com – the main point of sharing by the development team and where RunCodeRun watches for updates to verify as part of the continuous integration process

staging – hosted on the outstanding Heroku platform, this is where code goes when we’re ready for review by our business stakeholders

demo – also on Heroku, this is an environment that is intended to be more stable than staging.  While staging changes daily (perhaps multiple times), we generally rev demo only once ever couple of weeks

The fourth remote is the subject of this post however.  It’s called “justme” and is actually hosted on my laptop.  I use it to shuttle code back and forth between my laptop and desktop machines.  I can use this to commit all of the sins I used to commit when only I was working on the project.  For example, if I’m working out somewhere on my laptop on some feature and don’t quite get done before I get home.  And now I want to finish up my work on the desktop machine which has significantly better hardware.  Tests not passing?  No problem – just “git push justme mydevbranch” on the laptop and then “get pull justme mydevbranch” on the desktop.  Once my work is finished and I verify tests are passing, I can share the code with my other team members from the desktop with “git push origin somebranch” (or just “git push” for some branches like master).

To set this up on a Mac:

1. On the laptop, create a bare repository somewhere.  For example

mkdir $HOME/src/justme

cd $HOME/src/justme

git clone –bare git@github.com:username/projectname.git projectname.git.

2. On the laptop, go to your normal working directory and add a remote to this new area with something like:

git remote add justme $HOME/src/justme/projectname.git

3. On the desktop, add the remote with something like:

git remote add justme userid@laptop.local:src/justme/projectname.git

4. Make sure ssh access is enabled on your laptop (Remote Login option of the Sharing Preference Pane under System Preferences)

5. Make sure the git directory is in your PATH for SSH users on your laptop.  For me, this meant adding this to my ~/.bashrc file:

export PATH=$PATH:/usr/local/git/bin

And you should be good to go.

As I said before, embracing the distributed nature of git is not something that comes easily – especially if you cut your teeth in a world where everything was centralized.  But, once you understand how it works and can put it to your advantage, you really appreciate the benefits of git.

These steps fall into three basic categories:

1. Object creation step(s)
2. Debugging steps
3. Semantic markup checking steps

Object creation steps

In our project, we have fairly complex sets of ActiveRecord models and associations.  Trying to do acceptance testing proved challenging because several tests require non-trivial amounts of setup to work.   Consider for an example an application that helps you find restaurants with foods that enable you to lose weight. In this kind of application, you might have models for Food, Restaurant, Brand, and Location. And you need to tie these together in your features as in this example:

  Given the following foods exist
    | food   | calories | fat_calories |
    | eggs   | 200      | 180          |
    | burger | 350      | 200          |
    | salad  | 100      | 80           |
  And the following restaurants exist
    | brand     | location   | foods         |
    | mcdonalds | chicago il | eggs, burger  |
    | panera    | chicago il | eggs, salad   |
    | mcdonalds | dallas tx  | burger, salad |
  When I fill in "city" with "chicago"
  And I select "under 100" from "calories"
  And I press "search"
  Then I should see "panera"

Creation of restaurants in this example is fairly complicated (and maybe over-complicated):
- the base Restaurant object is probably created with FixtureReplacement, FactoryGirl, Object Daddy, Fixjour, or something similar, but:
- the associated brand might have to be grabbed using Brand.find_by_name to make use of a db:seed kind of table
- the associated location could be created with whatever Factory mechanism you’re using with only a single string param being enough to make it interesting
- the associated foods come from objects created in the prior step

Getting these steps with the cukesteps gem installed is a matter of doing the following in your features/support/env.rb file for cuke:

require 'cukesteps'
include CukeAssociationHelpers

cuke_association_attributes(:brand => :name,
                            :location => :address)

The use of cuke_association_attributes causes the brand and location columns in the second step to be treated special. Instead of being treated as simple attributes, they instead are found or built. If a result of find_by_attribute_name (e.g. find_by_name for brand or find_by_address for location) returns non-nil, then that object is used as the associated object. Otherwise, the object is created using a create_model-style factory method. The foods column is also special in that it refers back to the Food objects created in the prior step.

Debugging Steps

The cukesteps gem provides four basic debugging steps:

1. Then I debug
2. Then save_and_open_page
3. Then n foos should exist
4. Then dump all foos to standard output

These steps are not ones you’d leave in your feature file for any length of time, but they can come in handy for chasing down problems you encounter along the way.

Semantic markup checking steps

These steps help encourage use of semantic IDs and Class Names in your markup. The use of the articles “a” and “the” represent a class and ID respectively. For example, “I should see a photo in the search-results” ensures that the the page contains an element of class photo inside an element of ID search-results. The steps available here are:

1. Then I should see the foo (e.g. Then I should see the search-results)
2. Then I should see a|an foo (e.g. Then I should see a listing)
3. Then I should see a foo in the bar (e.g. Then I should see a listing in the search-results)
4. Then I should see the foo in the bar (e.g. Then I should see the map in the search-results)
5. Then I should see n foos in the bar (e.g. Then I should see 4 listings in the search-results)
6. Then I should see n to m foos in the bar (e.g. Then I should see 3 to 5 listings in the search-results)
7. Then the baz in the bar should contain a foo (e.g. Then the map in the search-results should contain a resizer)

The negation of each of the above is also available (e.g. Then I should not see a listing in the search-results)

Installation

To use this gem, just do the following:

gem sources github.com
gem install mdoel-cukesteps

Feel free to fork away and send me feedback.

Progress always involves risk; you can’t steal second base and keep your foot on first.

Fred Wilcox

For Christmas this year, my wife got me a copy of The Winners Manual by Jim Tressel – head coach of the Ohio State football team.  It’s a fantastic book, written in a style that is well suited to digesting it in small bits of 5-7 pages at a time.  Given the author, you might be surprised to find that there’s really very little football in the book.  Instead, it’s a book that helps you to realize the big picture parts of your life – your life’s purpose and the goals you set for yourself.  Reading a chunk is now a part of my morning ritual for getting the day started.

The quote at the start of this post comes from the beginning of chapter 3 – “Attitude”.  I found it particularly relevant to my current situation.  It was a year ago that I left AOL and the comforts of a steady paycheck.  The past year has been eventful (more on that in a future post), but the professional part of it has largely been a search for the right entrepreneurial business opportunity with some consulting work done along the way.

Well, we finally feel like we have the right business model to pursue and have started working on that over the last couple of weeks.  The thing is, pursuing this opportunity means more time with, uh, shall we say a non-ideal income model (on the positive side – income taxes are low).  And in the last couple of days, I’ve had someone approach me about an opportunity that is very tempting.  It would be a 40 hour per week position that brought in a nice income stream.  And in case you haven’t been paying attention to the news lately, this could come in handy.  But it would almost certainly put a serious crimp in our ability to execute on the new business.

Which brings me back to The Winners Manual and that quote.  I guess every entrepreneur eventually reaches a gut-check moment where you move from chicken to pig.  Well, oink oink – this pig is off first and running hard for second.