The State of Ruby and Testing

At the May 2011 Indy.rb meetup, I suggested creating a survey to figure out what versions of Ruby people were using, and what testing stacks they use and would like to use. I created this survey and tweeted it out, and was impressed with the results! Over a hundred people filled out the information, from several continents and numerous countries. Thanks to everyone who participated!

The questions and their results

  • What versions of Ruby have you ever tried out?
  • What versions of Ruby do you currently use in production or for real apps?
  • What testing frameworks are your active projects using?
  • If you were starting a new Rails project right now, what testing frameworks would you use?
  • What mocking/stubbing frameworks are your active projects using?
  • If you were starting a new Rails project right now, what mocking/stubbing frameworks would you use?
  • What do your active projects use to populate testing data?
  • If you were starting a new Rails project right now, what would you use for populating testing data?

What versions of Ruby have you ever tried out?

Summary: a wide variety of Ruby versions used. What the heck is kiji, you might ask? This was a useful post on kiji.

What versions of Ruby do you currently use in production or for real apps?

Read on →

Ruby Filter Script

It’s pretty easy to use a ruby script as part of a Linux or Unix pipe process to filter output of another script or set of commands. You can just use something like the following:

#!/usr/bin/env ruby

while line = STDIN.gets
  puts "filtered: #{line}"
end

The STDIN.gets is the magic. It just takes whatever the output of the preceding scripts and pipes it in. Then you can make the script executable and run it. If this script is named filter.rb, then you could run something like:

Read on →

April 2011 Customer Discovery Day

If you read through this post, you’ll see some sweet pictures and figure out a potential new way to get cookies and brownies.

I got together with Alex Toumey, Kyle Shipley and Wes Winham on April 16 for an event practicing lean startup concepts.

We started off by pitching ideas that we thought were interesting and needed some validation. At one point, we riffed on one of the ideas by coming up with “Etsy for baked goods.” The idea seemed kind of hokey at first, but the more we talked about it, the better it seemed. We put aside the other ideas for future exploration, and talked about our thoughts on the idea. We came up with a quick description to make sure everyone was on the same page: a marketplace for people to buy and sell local baked goods. Seemed good. What better time to test this idea against cold, harsh reality? :)

Brownies, or bullshit?

Next, we sketched out some basic hypotheses and some questions to test these hypotheses, and contacted friends and family to get some feedback. Someone took pictures of these, I’m sure, but I can’t seem to find them, or I’d post them.

Read on →

Startup Weekend Patterns

Summary: I have done a few startup weekends and customer discovery events in total and have found some common patterns.

Pregame

Make sure you have alerted friends and acquaintances about the weekend so that they know they probably won’t see much of you. This helps clear any potential distractions. It definitely helps to clear your plate as much as possible. At one of the competitions I had to fix something at work that couldn’t wait, and it took half of Saturday up. As you can imagine, it was frustrating for me and I wasn’t much help to the team.

Before the event might be a good time to start eliciting help for electronic voting. Something along the lines of, “hey, I’m doing a business competition this weekend, and part of our final score comes down to people texting a certain number.”

For the sake of everyone at the event, if you are pitching an idea, do some basic groundwork on the idea. Nobody wants to hear your pitch if the idea has already been done or is way too big for a startup weekend or is mumbled. You are just wasting everyone’s time. If you have an original take on an existing idea, fine. Just make sure you know enough about the environment you are considering working in to actually know about prior art. An hour of your time saves sixty people from hearing and voting on a minute pitch. It might sound equivalent, but it’s a net gain in terms of attention and energy. There were about forty pitches at the last startup weekend that needed to later be voted on, which took time.

Pitches

Along the same lines, when at the pitches, listen for ideas that are pretty well-defined and that preferably have some sort of validation already. About the worst thing you can do is spend half of the weekend figuring out what you actually want to work on. About as bad is trying to do something for awhile and then basic research suggests that the idea has already been executed well by someone else. At that point the team flails for a few hours. Not a good start.

Read on →