entrepreneurship. technology. hustle.

Gift to My Girlfriend and Now to You

My girlfriend recently had ankle surgery.

The actual procedure was not terrible (as surgeries go), but the recovery process was, shall we say, not super fun. She was required to stay off her feet for 3ish weeks. During that time she was restrictued to sitting on the couch, day in and day out.

I tried to help take her mind off of things when I could and her friends sent her a lot of very thoughtful presents. (Thanks again, by the way!) However, I did have to go to work and couldn’t be around all the time.


A night or two into it, I had a thought: What if I could bring her a little happiness throughout the day even when I’m not around. An idea rushed into my brain. I ran over to my desk, cracked open my laptop, and begin furiously coding. 2 hours later, Hourly Puppy was up and running.

Version 1.0

The core concept was every hour, on the hour, show her a cute puppy. Deliver a little happiness every sixty minutes, even when I’m not around. She loved it. I’d get emails from her showing me her favorite of the day. (Her favorite of all time is this one.) Other times I’d be in the other room and hear a burst of laughter and joy when the hour flipped. I was thrilled.

Now For Everyone

A few weeks later I was chatting with a friend of mine and mentioned the idea. He (yes, he) loved it too. So I decided to polish it up so everyone could enjoy it.


I’ve had a few people ask why I’ve dedicated time to such a silly project. My response is why not?. Development work doesn’t always have to be about making money or building a business. I work on plenty of those types of projects through my consulting company.

One of my favorite recent quotes is from Twitter creator and Square CEO Jack Dorsey where he urges you to bake in some fun and whimsy into your projects. While HourlyPuppy might take this to an extreme, building and managing it has been immensely rewarding:

  • I made my girlfriend’s recovery easier, even if just a little
  • Each morning, I get to wake up and look at puppies as I load up the day’s queue
  • Random people send me really excited emails and pictures of their puppies
  • I learned a lot working on the site’s design and backend (especially the queuing system, which I’ll cover in a future post)

HourlyPuppy started out as a small gift to my girlfriend as a way to help her get through a difficult time. I hope it can bring a little happiness to your day as well, one hour at a time.

Penalty Blox Chrome Extension

Whether it is a designer ultra-tweeting about some conference she is at or a venture capitalist intensely describing his pursuit of the always-elusive “inbox zero”, sometimes you just want to mute someone you follow on Twitter.

This extensions allows you to do just that. You can easily put accounts that you follow in the penalty box, where they will be silenced and feel shame. When you have deemed their sins absolved, you can let them out, free to fill your Twitter stream again.

Penalty bloxed people are not notified in any way that they have been temporarily removed from your timeline.

Do You Test?

Note: this was in response to a question asked on the Dallas.rb group regarding if, how, and why you write tests (or specs, or whatever you want to call them).

Definitely test. It will feel weird / slow at first, but it helps you write much cleaner, more modular code. I initially hated it when I was forcing myself to adopt it, now I feel naked without it. For me, I find testing important for a few reasons:

  • It helps me think through what I want the app to do should do from a stakeholders standpoint.

  • It helps me and anyone else working on my app from a dev standpoint know how my app and its components should behave - specifications should do just that: specify what certain things should do! I try to always ask myself “What should you do, Mr. Object” and then write a spec around that.

    For example, take a look at this:

    You can see what I’d expect if you were to write User#full_name. It says: “Show me the full name when available, or its parts, or default to the email address, which is ensured to be present, if all else fails.” Perhaps we drew up this specification when determining how we should handle displaying a “Hi, #{current_user.full_name}” in our UI for the different cases our app might encounter. Or perhaps #full_name was the failing part of our acceptance test when we were writing the code that we wish he had. (See The RSpec Book for this reference and a very informative read.)

  • It’s an insurance policy and time saver. Anytime you change your app you can be confident that other areas still behave as expected. My workflow before TDD / BDD was:

    1. implement some new feature
    2. think through all other parts that could be effected
    3. pop open my dev env and manually test each to make sure things were working.

    This was a waste of time and exposed me to my own human error: perhaps I forgot to do a certain thing or whatever. The computer is your friend (and worker), make it do the checking for you. My workflow is now:

    1. implement some new feature
    2. initiate tests
    3. go make a sandwich, return and see what passed what needs fixing.

    I found writing expressive and clean unit tests much easier than acceptance tests. If you are using Cucumber, check this out: Imperative vs Declarative scenarios in user stories and try to avoid using the pre-packaged web-steps when possible.

DRYing Up Those Controller Specs

I recently had a bunch of duplicate code in my controller specs and wanted to share a solution I arrived at that DRYed things up significantly. Feel free to use it and abuse it and if you have recommendations on how to improve it, let me know.

First, the quick requirements and background: all controller methods must explicitly demonstrate that guests do not have access to certain resources and are told, upon any attempt to access them, that they must login in order gain access.

The first pass was to write the tests, get all to pass, then look to consolidate and improve the suites. Here’s the first pass:

These specs duplicate an awfully large amount of code. This is an issue because more lines of code translate into more maintenance, more potential areas to make mistakes, and more places that need to be updated when things change. (For example, what if we want to flash an alert of “OH NOZ, SIGN IN FIRST PLZ”? I could find and replace, but that should be handled in one place.)

In order to remedy these issues, I added a controller macro that includes #it_should_block_access_to(action, options = {}), which is passed an action (:index, :create, :update), maps each to a default method (:get, :post, :put) if none is specified, and generates the appropriate routing (member vs collections). It also handles format specification, such as :json, or setting any other arbitrary params via the options hash.

Here’s the refactored code:

The controller specs are cleaner, a big chunk of code duplication has been removed, and there is a main handler for these tests that does not (in my opinion) add too much complexity into the testing suite.

Kevin Costner Is Full of Sh*t

Kevin Costner is full of sh*t … when it comes to startups at least. Build it and they will come. I implore you, do not listen to this man! This line of thinking is out in left field.

I have to admit, I used to subscribe to this tag line. A few years back, I felt that if the idea was there, all that was barring a venture from success was time, effort, and determination. As a result, several of my early projects were drastically over engineered and tragically under utilized.

Case in point, in a 2005 project I wrote an entire professional network platform. It was Facebook meets LinkedIn (this was back when FB was still only for college kids and LinkedIn was lame). I was going to make the professional network that young professionals wanted and needed to join. I would monetize it somehow, but with the eyes and ears of tomorrow’s top earners, I felt this would “fall into place”. I wrote over 50,000 loc. It did everything: secure login, password reset, profile creation, group formation, group messaging, secret groups, public groups, photo upload, friend requests, etc. I saw about 150 members over the next few months with few sticky members. The issue wasn’t that I had built a bad product or service, but more that I hadn’t done my homework and gathered real world data before setting up shop.

What could I have done differently? I should have given a big middle finger to Kevin Costner and incrementally tested my thesis: young professionals (especially those in major urban environments a la New York City, Boston, DC, and so on) need a better way to network in the work place. At the very least, before I wrote a single script, I should have sent out an email to my friends and asked if this perceived pain point was a reality. If yes, did my proposed solution solve the problem? Make it worse? After passing these first sanity checks and receiving some initial buy in, I could have then produced a vastly trimmed down initial service (minimally viable product) to test actual adoption and utilization and gone from there. These would have been intelligent, no-brainer steps to have taken. But as developers we often don’t do this. We get into the groove and let the code fly. Projects like this burn you out both emotionally and entrepreneurially. You only have so much fuel for the furnace and hours in the day, so choose wisely.

This insight sprung up in my head over the past week when discussing a friend’s startup idea. He had built a great product and wanted me to test it out. I told him I’m not going to likely be one of his early adopters and to go to a popular blog dedicated to people he’d likely want to start off with. There he should start recruiting people and see if they are interested. If so, why? If not, why not? Which of the first features did they think were absolutely necessary, which were nice-to-haves, and which were unnecessary?

When giving a startup a go, you certainly have to have that optimistic dedication and drive to succeed as Kevin Costner demonstrated in Field of Dreams. But rather than going whole-hog right out of the gate, leveling his entire farm, and hoping for the best, Mr. Costner likely should have only hashed out a pitchers mound, picked up a few bats, and laid down some old shirts as bases. Then he could see if a any corn stalks began to rustle at night, or if that voice in his head starts to whisper further instructions, like “now add bench seating, we want bench seating” or “no, I meant build a basketball court, dummy!”.

Austin by Apple

I just visited Austin, Texas. Before making the trip, I had been told that Austin was “amazing”, “the coolest place ever”, “better than chocolate ice cream rainbows” (I have strange, overly descriptive friends).

Well, you know what? Austin is better than chocolate ice cream rainbows … that can breath fire … and can fly … and beat Chuck Norris in a fight.

First off, Austin looks like it was designed by Apple.

Austin Apple

Every restaurant is cool as all hell, as are the cafes, the book stores, and the grocery stores. Every building has something unique, beautiful, and funky about it. Even the electric power plant is sweet. When a town makes its public utilities buildings gorgeous, you know you are dealing with some sort of unstoppable design force.

Not to be out done by their day-time counter parts, each Austin bar promises an interesting and exciting experience. There is everything from ol’ Southern Saloons, Irish Pubs / Boston-ish Sports Bars (pronounced Bahs), New York City-ish lounges, and good old live-music venues. You can dance on roofs to DJs, you can hippie-groove to local vocalists, you can play pool and mini-shuffle board, square dance, or frat it up if all else fails. The extreme attention to detail and “weirdness” that you find in every single establishment is unparalleled.

The lucky inhabitants of Austin are really what makes the city what it is. All are friendly and a bit “weird” themselves, in a very, very good way. The uniqueness of each individual is projected into all the brick, mortar, cardboard, and clay that make up the infrastructure of Austin. No wall goes unpainted, no blank space goes without a sculpture.

The city also seems to be fueled by no more than sun, music, and bikes … and possibly bats. It’s Texas, so it’s dry, hot, and sunny. Austin is known as the music capital of the United States and the sheer quantity of music present in Austin is awe-inspiring. There is always some sort of festival or concert taking place. Everyone you come across seems capable, upon request, of banging out a drum beat, belting out a few home made lyrics, or producing a concealed guitar that can be dangerously rocked out on.

And the bikes. Everyone loves their bikes, and for good reason! They are good for the environment, get you from point A to point B, plus provide a workout in the process. And when you have no reason to ever leave the Austin City limits, who cares about the restricted travel radius!

Austin is truly a unique place. The city has gone local and emphasized culture, music, art, and eco-friendliness, yielding a marvelous gem. I will be visiting again soon, and I urge you to as well, especially if you never gotten weird in Austin before!