So your startup got selected for an incubator…

Getting selected for an incubator is both great and scary, especially if you’re already employed in a cushy job! My startup, now called Revisu, was selected for the Portland Incubator Experiment (PIE) in early September. Obviously, we were ecstatic — but we didn’t really know what to expect.

We tried searching Google and crawling through Hacker News to figure out what to expect, but real actionable data was lacking. Here are a few tips on getting started at an incubator.

1. Don’t worry, no one else knows what they’re doing either.

At PIE there was a real mixed bag of startups in terms of progress. Going in to PIE some were really far along, some (most) were just very basic prototypes with unproven marketability, and some were just ideas and two cool guys.

All of them, though, didn’t know what to expect from an incubator. And you really can’t find out, either, until you go through it as each incubator is different.

2. Figure out what your startup is about — quickly.

By “what you are about” I mean write down — on paper — the answers to some very basic questions. What are your goals? What is your (hopefully market driven) problem hypothesis? Why are you in an incubator? What do you hope to have done by the end? What do you hope to learn from it? The sooner you do this, the more successful you will be as all of your decisions should hinge on those answers. Any decisions you make without this data are just shots in the dark.

As of now, we’re about half way through the program and we just now figured out the answers to these questions. We’ve got a lot of work ahead of us to make up for that lost time. Oh yeah, and these can change at any time, too.

3. You’re probably wrong and that’s OK.

This point gets harped on a lot but it’s one of those things that people still fail at realizing when they’re actually put in the position, when they’re actually wrong about something. And you could be wrong about anything and everything — technological viability, marketability, your ability to reach customers, anything!

The best entrepreneurs are the ones that realize they’re wrong the earliest because they can figure out how to fix the problem. Again, this is something we’re just now learning!

4. You’re about to learn a lot.

You’re going to meet people that have expertise in fields that you didn’t even know existed  and are very important to building a company.

PR was a field that I didn’t consider to be important. “it’s just something big companies use for damage control,” I thought. It wasn’t until someone explained to me what PR was that I understood how important it is because I (obviously) didn’t understand it.

5. The most valuable advice you’re going to get will come from…

Previously successful founders. The real bitch of an incubator is that there is too much data being thrown at you.

You’re going to hear from experts in all fields — marketing, PR, sales, product management, technology, design, UX, and a bunch I’m sure I’m forgetting. Each person you talk to will tell you how important their respective field is and how if you concentrate on this one thing you’ll be successful.

The only people that really know what is important to starting a company are the people who have done it. Even then, realize that it’s different for everyone to a certain degree and highly subjective to how far along you are.


Always check error type when using raise_error matcher

We all know rspec is sweet. There are a few gotchas, though, that everyone should be aware of. One of them shows up when using the raise_error matcher.

Consider the following bit of code with spec:

class User
  attr_accessor :username

class Project
  attr_accessor :users

  def add_user(user)
    raise "User is already on project" if user.users.include? user

it 'should not allow you to add multiple users to a project' do
  user =
  project =

  lambda {
  }.should raise_error

In this obviously contrived example an error will be raised…but it won’t be the error you expect. You’ll get a NoMethodError! rspec lets you check the type of error raised, so here is a better alternative — notice the differences on linew 1, 11, and 21.

class DuplicateUsersError < StandardError; end

class User
  attr_accessor :username

class Project
  attr_accessor :users

  def add_user(user)
    raise DuplicateUsersError, "User is already on project" if user.users.include? user

it 'should not allow you to add multiple users to a project' do
  user =
  project =

  lambda {
  }.should raise_error DuplicateUsersError

Now the spec will properly fail as the wrong type of error was raised!

A sneaky Rails 3 bug in logging

When locally debugging a production issue today I kept getting this message when starting the server:
Rails Error: Unable to access log file. Please ensure that /path/to/rails/app/log/production.log exists and is chmod 0666. The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.

Despite the fact that the file was indeed present and accounted for (permissions-wise — not exactly 0666 but perms matched other log files):
-rw-r--r--   1 brad  admin        0 Jun 26 13:07 production.log

As it turns out, there is a “bug” in Rail’s logger configuration code such that if an exception is thrown during configuring the logger it just tells you it couldn’t get to the file. This isn’t so much a bug as just a poorly-worded error message.

The Fix

The root cause of my issue was that in configs/environments/production.rb I was configuring logging like so (legacy Rails way, apparently):
config.log_level = Logger::WARN

When I should be configuring it thusly:
config.log_level = :warn

After changing configuration, everything worked just dandy.

How was this bug originally manifested?

Interestingly, I originally started looking in to this because (surprise surprise) logging wasn’t working in production! This fixed the issue.

Notes on working with Resque in Rails 3 and Ruby 1.8

Resque is really great. It’s super easy to set up, (pretty) well documented, and damn fast. I’ve set it up for two — going on three — projects here and I’ve gotten stuck on two points twice now.

Add the Resque tasks to your Rakefile

Herp derp. I have no idea how I missed this twice. Make sure you include the rake tasks in your rake file by adding

require 'resque/tasks'

to the top of your Rakefile. If you don’t rake won’t know how to start the Resque worker.

/www/integrand [ master* ] $ QUEUE=* rake resque:work
(in /www/integrand)
rake aborted!
Don't know how to build task 'resque:work'

(See full trace by running task with --trace)

Add a script to start your Resque worker

The syntax to start Resque workers is (marginally) verbose. Make your life easier by adding a script to your script folder. All you really need is the following:

QUEUE=* VVERBOSE=1 rake environment resque:work

The VVERBOSE argument, not suprisingly, tells Resque to use very verbose logging to the console. The “environment” argument has Resque load the full Rails environment (read: Your models!) for it’s jobs.

Process Overload Mitigation: Modify existing processes before adding new processes

No one likes process — well, maybe the pointy hairds do, but hopefully they’re not looking while you’re reading this. Anyway, everyone wants to minimize process. One way to do so is, when something comes up that dictates a change in process, to concentrate on modifying existing processes before adding new processes.

An example would be a hand off process I’ve been helping refine. One team writes features/modifies functionality for an automation process and the other is responsible for the management/operations of said automation. For whatever reason, the ancients dictated that the maintenance team must write the configuration files for the automation.

Hind sight is more probably like 20/120 when dealing with process

Obviously, it’s been a bumpy road any time there is a hand off between the maintenance team and the operations team. The short-sighted process that dictated the maintenance team must maintain configs resulted in a healthy dose of environment-related problems — files in different locations than anticipated, missing metadata in various places, etc.

After the two teams got fed up with bickering about who broke what the proposed solution was a “handoff checklist.” For whatever reason people default to adding documents when something goes all wonky. While it seems like an “easy” fix, man, that’s such a pain in the ass. To get a new document in place the teams must agree upon a strategy for where they should be stored, what format to use, how they will be maintained, who will maintain them, how to backfill for existing artifacts, and a whole bunch of other scenarios.

Avoid process-overload by modifying existing processes

That’s a lot of man hours and added frustration to fix the core issue: Operations should maintain the configuration. It’s their environment, it’s their automation process. By modifying the existing process (in this example, forcing poor ops to maintain the config) you can save a lot of energy.

Installing sqlite3 on Linux (Ubuntu) for Ruby on Rails

I’ve been doing rails dev in my spare time lately and decided that I was going to migrate to Linux for that. Thankfully, I’m a linux vet so that didn’t scare me one bit!

The install steps were pretty much the same as on windows:

  1. Install Ruby (sudo apt-get install ruby)
  2. Install Ruby Gems (sudo apt-get install rubygems1.8)
  3. Install rails (sudo gem install rails -v=3.0.3)
  4. Get your app outta git
  5. Install required gems with bundle

Unfortunately, step 5 isn’t quite so simple. The sqlite3 gem — which is pretty much mandated by default by RoR — requires some native extensions to be built.

To actually get the damn gem to install

All you have to do is as follows:

  1. sudo apt-get install sqlite3
  2. sudo apt-get install libsqlite3-dev
  3. sudo apt-get install sqlite3-ruby
  4. Re-run bundle

You wouldn’t believe how long that took me to work out for some reason.

Lets Forget the Golden Path

A good friend of mine (whom I owe quite a bit to with regard to my interest in the start up world) and I frequently have arguments about various aspects of start ups. My friend is business savvy and I’m tech savvy; although, I’m always trying to look more business savvy and he’s always trying to look more tech savvy. We frequently have differences of opinion on many topics.

One of the (rather broad) topics that’s often brought up: What’s the Right Way(TM) to do a start up?

One thing that I’ve become aware of thanks to my friend is that I don’t do enough reading. Sure, I catch up on Eric Reis‘ blog posts and Steve Blank‘s latest stuff thanks to Hacker News but really I don’t do any deep-dive reading. I will admit it: I haven’t read Four Steps to an Epiphany cover-to-cover.

I do know this: There is no golden path to start up success.

One thing that intelligent people understand is that in order to succeed it’s best to learn from other peoples’ successes. Why else do you think there is such a market for start up founders’ memoirs? Do you think they’re genuinely interesting or something? Nope, the reason people read these things is because they want to be the authors.

Businesses are dynamic and, as they say, no two are alike. So why do people think that emulating others’ path to success will make them successful themselves?

Tools of the trade != scripture

What I like about the lean mentality is that it’s about developing and evangelizing tools that start ups need to succeed. Did you read that? Tools. Not methodologies or practices or kattas or exercises but tools. I’m sure you agree that to call them anything else would be disingenuous.

Unfortunately, people don’t want tools — they want a checklist. What they want is a short cut or a magic pass phrase or something. So what happens with these tools? They get strung together in to steps. People publish generic plans.

Lets drop the pretense…we shouldn’t be worshiping them.

Please, stop with the lists. If you want to be successful you need to learn to think critically (remember that stuff they made you do in school?) about your business, your market, your product, and your capabilities to execute. Come up with your own plan based on those factors, don’t try to lean on other people’s ideas.

Does that necessarily mean you need to throw out their suggestions? Well, no, but don’t take it as gospel either! Think for yourself, mate.