One difficulty I had in the past was when I worked on multiple clients on my laptop, was setting one up could disrupt another. In the Ruby community this commonly was because different versions of gems were used and the different client applications wouldn’t specify them correctly. As you can imagine, this meant I had a huge productivity drain when I had to switch from project to project.

(This was pre-Bundler. But even now there are gem issues and other component issues that make this a time drain.)

Virtual Private (Development) Server

Then last Fall, in an effort to delay a new laptop purchase as long as possible, I decided to use a VPS as my development environment instead of my laptop. At the time my laptop was aging and I’d be running out of resources on a weekly basis (disk space, RAM). Add to that several years of client projects installed, uninstalled, and never fully purged and I was looking forward to using a clean VPS to develop on.

Since I have a puppet infrastructure setup already, including a CI server, taking the puppet configuration from other servers to spin up a development VPS was easy.

Seven months later, I can now say that using a dedicated VPS for a client project has been one of the best infrastructure decisions I’ve made in years. The benefits I get out of it are quite amazing.

Writing code in the cloud

With a VPS in the cloud, I can easily have other developers or my client connect to it to see the development versions of code I’m working on. I’ve had my client on the phone looking at my server while I made UI changes live, which is normally something you have to do in-person. I’ve also added a second account to do pair programming with another developer and it took all of five minutes.

Having the entire configuration (except for 2 manual steps) in puppet meant that I could destroy the server and get a fresh one with a little effort. One time my VPS started lagging pretty bad, even typing on the SSH console had a noticeable delay. So I make sure my changes were saved in Dropbox and rebuilt the server in under an hour (about 55 minutes of puppet and Ubuntu running, about 5 minutes of my actual time).

When doing my one week on schedule, I setup the server the Sunday before I start and destroy it at the end of the week. That not only decreases my costs but it also makes things a bit more secure since I don’t have a public server running with my clients’ code.

Scalibility

Using a VPS makes it easy to scale it up if I need to. One client’s application went through a major growth period where our test suite increased three-fold over a few weeks. Before I was using a small 1GB server for them but that became so slow that upgrading to a 2GB saved me at least a few hours each week. With physical hardware on my desk, that wouldn’t have been possible or it would have resulted in a few hours or days off while I move everything over. Total time upgrading the VPS, about 30 minutes.

Having my development environment in the cloud also gives me a bit of resiliency. Since all I need is SSH and a web browser, if something happened to my laptop I can easily grab another computer and get right back to work. Worst case I could run to Best Buy and buy a $400 laptop to get by. Although I haven’t tried it with a client project yet, I could in theory use my ipad too.

I also have another form of resiliency. If the VPS crashes or dies, I can spin up a new one and get back to work with a small delay. Since all of my code is in Dropbox and git, the server configuration is in puppet, and I dump copies of the database regularly I don’t have to worry about losing anything.

Isolation

Each client gets their own VPS so their applications are completely isolated. Not only in terms of gems, libraries, or system services but also in terms of legal boundaries. I haven’t seen a client NDA or contract that specified their code needed to be on an isolated system yet, but I have heard stories from other consultants where they are only allowed to work on a locked down client workstation.

Digital Ocean

At the moment I’ve had some great success with Digital Ocean’s servers. Since they bill by the hour, I’ve been ordering a 4GB server for my week on and spending about $10 each time. Compared to a week’s revenue from consulting, $10 is a pittance.

Vagrant and local VMs

Now that I’ve upgraded my laptop and have a lot more spare resources, I’m beginning to explore using Vagrant for my own projects. But having a remote VPS is still useful because it’s publicly demonstrable to people who aren’t physically with you. For Chirk HR and my other projects a local VM should work just fine. A nice bonus is that is I can use the same puppet configuration for both a VPS and a Vagrant VM.

Spread out or in large chunks

The spread out projects almost always require that I have multiple client projects running at the same time. That causes quite a bit of switching costs when I jump from project to project. This switching cost isn’t billable so I end up losing that time, and feel panicked since I now have to make up that time.

The large chunk of time projects don’t have as many switching costs, but they have their own problems. The two big ones for me are

1. burnout due to intense time demands and
2. fostering the feast-and-famine cycle (start/stop/start)

The burnout problem I’ve been able to work around by not over-committing and keeping my days short (no 12-hour billable days for me, thank you very much). The start/stop/start problem is worse though.

I’ve finally figured out how to market my client services, at least well enough that I can find some great clients when work slows down. The problem is, it takes me a month or two to scale up my marketing from a standstill. With a large chunk project, that means I don’t have the time to keep my marketing running, so at the end of each project I’ve had to reinvigorate my marketing yet again.

A better schedule

I think I’ve found a better way to schedule client work though. One that works well with my schedule, my marketing, and my product development. That schedule is what StatusPage names the “one on / three off” schedule.

Basically, instead of working part-time on client projects and your product or doing full-time bursts of client projects with an idle gap in-between projects, you schedule projects so you work full-time but only for a week each month (the one on part). The other three weeks of the month you can work on other things: marketing, building products, vacations.

I’ve tried this for about two years now, with a few different clients. I have to say, I love it and it’s my favorite scheduling mechanism.

Why?

My clients like it too, despite the drawbacks at the first glance.

The 3 weeks off

As I mentioned earlier, the biggest benefit for me is that I can schedule around my week of client work. So if I need to build up Chirk HR or another product, I have 3 weeks to work on it. Or if I’m going to be scaling up my client services marketing again, I’ll have time to get it going before it’s critical.

Focus 100% on my client

With a solid FT week of client work, it’s also easier for me to focus and get into the flow with them. Usually a few hours is needed on Monday to ramp back up and see what’s changed in a month but my mid-morning Monday I’m already cranking away. That usually doesn’t stop until Friday afternoon. This means my attention stays at it’s peak and I don’t get distracted by other clients or other projects.

Time-boxed

The nice thing about being on for a week from the client’s perspective, they will know when I will be working and (based on previous estimates) can predict how much I’ll get done during that week. That means the week before they can do all of their planning, get ready for me, and then just check back at the end of the week. Some clients will take a more active role in the project, wither it’s to attend a daily check-in meeting with me or to schedule open office hours for me to come to them with questions. Either way, since I’m only on for a week at a time their commitment levels are limited to that week too.

Emergencies and fire-drills

One downside I thought would hurt this schedule would be that my clients would need me during my off-weeks. Though they have needed help for emergencies, for the most part they haven’t had to contact me or schedule any non-standard days. With a few exceptions, most of the emergency fire-drills in projects are caused by someone rushing to do something that isn’t really urgent.

So that’s my one-on, three-off schedule I’ve been using. Since I already have a happy client, I’m not accepting anyone new right now but I might re-open it again this August or September (2013). If you’d like to know when I do open it back up or if you’d like to hear more about my business and what goes on behind the scenes, signup for my newsletter.

http://theadmin.org/feed/

The very best way to keep updated on any posts or events is to subscribe by email on the sidebar to the right. My email subscribers usually get more information that whats posted on the site alone.

Make sure to update your RSS subscription today.

Eric Davis

But after a few months of running ChirkHR as an applicant tracking system, I think I made a mistake.

The Sales Safari

This lingering doubt caused me to go back to the market research to see what my potential customers were actually doing (this is part of the 30×500 Sales Safari, which I hope Amy Hoy releases outside of 30×500…). Anyways, mid-February I spent a few dozen hours researching, reading, and digging though the HR market to see why ChirkHR wasn’t working as well as I hoped.

I eventually came to the realization that an applicant tracking system was useful to them (good) but it became clear that it wouldn’t be a good fit for me and my company (bad). Needless to say, that week was a very depressing week.

But there was a glimmer of hope…

As part of my research Amy taught me to mark down topics and pains that came up over and over. From this I started to spot a new topic that I was both energized about but (more importantly) was something that I felt that would be a great fit for me.

This topic was employee training and development. Specifically, how human resources manages and makes decisions about training.

The Pivot

With this new topic, I dived deeper into my research and refined my vision of what ChirkHR would become. After reviewing my notes, I decided to pursue this new opportunity and pivot ChirkHR.

Code-wise this change was almost a complete rewrite of the software behind ChirkHR. The only parts I’ll be keeping from the old system was the account management system and the overall UI layout (present tense because I’m still running the old version for some customers behind a feature flipper).

Even though it’s a rewrite, since ChirkHR was little more than a MVP there wasn’t a lot of code I had to change for the pivot. This which allowed me to move fast and after a couple weeks of development, I released the new ChirkHR training features to the servers.

The business side of ChirkHR is pivoting too, but it’s less of a change than the software side. Yes, ChirkHR will be solving a different problem for a different set of customers but they are similar enough that much of the existing business systems will still work exactly as before. The biggest risk, as always with a young business, will be reaching potential customers.

The Next 6 months

I’ll be honest, I don’t know what the next six months will bring for ChirkHR. I have several changes I’m thinking about for the software and I’m starting to scale up the marketing machine again. But other than those vague directions, there is a lot of unknown out there for me.

With the birth of Piper and entering a busy period in Little Stream Software’s client services, I’m finding that I’m placing a higher standard on how I spend my time. Which means that my non-fiction reading list isn’t getting as much time as it used to.

But at the same time I don’t want to stop growing my knowledge…

3 Book Diet

Then I came across a post (event?) by Chris Brogan called the 3 Book Diet. Basically for an entire year he is limiting himself to only reading 3 books. This means he will be reading each book multiple times and digging deeper into each one (and theoretically putting the book’s ideas into action more).

My changes

I’ve decided to do the 3 Book Diet, with a few modifications:

• I’ve picked 3 non-fiction books I can read.
• I can only read those non-fiction books for the next few months (3? 6? I don’t know how long yet).
• I can read unlimited fiction or novels. These are pleasure reading and how I fall asleep.
• An exception will be made for two non-fiction baby books I have. I’ve already started them and one is a month-by-month book.

My 3 books

After a few weeks of thinking about my picks, the three books I decided on:

1. Power of Habit by Charles Duhigg. I’ve read this book already and I really enjoyed the mechanical aspect of building habits. I’ve been adding and removing habits for a few years now but like most people I struggle with them. I’m hoping by digging deep into the Power of Habit, I can build the habit of habit change. #meta
2. How To Win Friends & Influence People by Dale Carnegie. This book is a classic but I last read it back in 2001 or 2002. The title is a bit off-putting but the content is great, especially if you have to communicate or work with humans.
3. 30×500 lessons by Amy Hoy. Yes, this isn’t technically a book but there is more meaty content here than many “real” business books. I’m hoping by revisiting these lessons I’ll improve my product building skills and figure out why Chirk HR isn’t growing like I planned.

I have high hopes for this little experiment. Worst case, I’ll get bored of reading 3 great books and want to read something new when it’s over. Best case, by really mastering what each book teaches I’ll be able to make dramatic improvements in those areas of my life.

Stay tuned, I’d like to revisit this post with some results later.

I’ve noticed a few different types of code reviews, all based on what the goal of the review is.

Getting to Know You Code Review

The Getting to Know You code review is done so you can understand what the code is doing in general. Typically these are done on an entire application or library as a whole, where there is a large volume of code to review.

The goal of this is to get to know the code and be able to navigate around. What I try to do is to get a good understanding of the major components and how they interact. For Ruby on Rails applications this means the relationship between:

• the urls (routes) and controllers – how the users will see the application’s workflows
• the controllers and the models – how the data will be retrieved and updated
• the models to other models – how the data is related

A few things to watch out for are God Objects, too many classes, two few classes (both symptoms of design problems), and a lack of tests.

We Have a Problem Code Review

The We Have a Problem code reviews are a different beast. These come up because of a specific problem in the application: maybe there is a bug, performance has degraded, or a (human) process has gone bad.

This type of code review is very similar to the process you use when trying to reproduce a bug, in fact I’d consider reproducing a bug to be a code review of sorts. Typically these code reviews follow a process like:

1. Create a hypothesis of the cause of the problem,
2. attempt to either prove or disprove the hypothesis through experiments,
3. review the results,
4. Refine the hypothesis and iterate or discover of the bug’s root cause.

(This is similar to the Scientific Method)

Typically you’d start with a very broad hypothesis and narrow it down as you cycle through the steps. Finally you’d hone in on the problem areas and then have enough to be able to come up with a solution.

When you compare this type of review to the Getting to Know You, the We Have a Problem has a few major differences:

• the goal of this is to find a problem so it can be fixed
• the code needs to be understood just enough to solve the problem
• the review starts very broadly and then narrows down its search quickly

So in this case, the code review is merely a means to an end, fixing the problem.

The Refresher Code Review

The Refresher code review is designed to get back up to speed on how some code works. You might have written the code in the past, or maybe it is some code you’ve used before. In either case, the code is familiar but you need to do a quick review to become reacquainted with it. Typically these reviews are short, very informal, and most developers do them without thinking about them. Whenever you open up a class and scan through its methods and data, you’re doing a Refresher code review.

There isn’t much to say about the Refresher. It’s a lot like the Getting to Know You in that it can be broad, but it’s like the We Have a Problem in that you might only focus on a few classes or objects.

The important thing to remember is that the Refresher’s goal is to help you understand a section of code again so you can work on something.

Many Subtypes

These are a few different types of code reviews that I do and have seen other people do. They encompass many of the different reasons someone will want to do a code review and there are a few subtypes of code reviews that are used in specific cases. Like starting a rescue project (Getting to Know You) or a security audit (We Have a Problem). There are probably other major types of code reviews but these are the ones I come across again and again.

There is one final type of code review that I think developers should do more of (no, not a dramatic reading of the code)…

One Last Type, For Fun

That’s doing a code review for fun, enjoyment, and to learn. Sitting down with a chunk of code, a tasty beverage, and spending an hour reading and reasoning through some code just for the fun of it. I’ve done it with prototype.js, Rails, and capistranio in the past and that knowledge is still helping me today.

They don’t take a lot of time and you can do them with very little equipment (I’ve printed out code before and also read some on my iPad).

Even though I only budget one hour to the learning, I end up using two to four hours for everything. Reviewing my results, writing about the results, and recording a screencast of the final app takes a lot of time to put together. It’s fun, just time consuming.

Just this week I booked my last client which effectively takes up all of my time for the next few months. Actually, I’m a bit overbooked. This means that I have to cut back on anything that isn’t 100% essential until I can get some things off my plate (I’m talking with a VA to have some help with administrative tasks).

Until I can get everything squared away, I’m going to postpone my tech learning series. I’m hopeful I’ll be able to start it back up once things have settled down.

It’s that time of the year. No, not when little ghouls and goblins are running around begging for candy (though that time is coming up).

It’s time for my birthday and this year I decided to give you a gift instead.

This gift is coupons.

(You should imagine a cake here with life sized coupons jumping out of it)

Save $10 on any of my ebooks

Today from 10am EDT until 10pm PDT you can any or all of my three ebooks for $10 off each.

• Refactoring Redmine for $29 (use code BIRTHDAYRR)
• Redmine Tips for $39 (use code BIRTHDAYTIPS)
• Authoring Ebooks for $39 (use code BIRTHDAYBOOK)

(Sorry the coupon codes are different. It’s complicated.)

If you’ve been waiting for the right time to pick up your copy of Refactoring Redmine, Redmine Tips, or Authoring Ebooks — then now would be a good time.

Already got your copy? First off, you’re awesome. Second, why not email this page to a friend? Friends like gifts too.

Why all the 10s?

You might have noticed all of the 10s above. Please allow a bit of backstory.

I was born on a stormy night (or a calm day, I don’t really know and my mom isn’t answering her phone) on October 10th (10th month). Weighing in at a scale-crushing 10 pounds and 10 ounces, I was one of the big boys in the nursery that night (or day). Ever since then, 10 has been my lucky number.

That’s also why I go by edavis10 everywhere. It’s my way of making a common name like Eric Davis be unique… in my own special way.

So yea. Today. Coupons. All ebooks $10 off. 10am EDT to 10pm PDT only. Links and coupons above. Enjoy.

Eric Davis

P.S. This page will self-destruct after 10pm October 10th. I will not be held liable if you left your browser open when it happened and you lost all 37 of your tabs in the process. (I will say sorry if that happens though… Sorry)

Ideal Authentication Test

As part of my testing habits, I try to really exercise important methods. Authentication is definitely one of them. Authentication is also tricky because many of the authentication libraries give you helper methods that bypass some of the actual logging in process (e.g. open login page, enter username, enter password, submit). For this reason I try to test my authentication at the integration level:

1. Load login form
2. Enter authentication data and submit
3. Verify login was successful

My integration tool of choice is capybara. Its DSL is high level enough for me to model how a visitor behaves without being too complex.

Testing HTTP Basic Authentication

One feature of capybara is that it supports different drivers. A driver is a way to actually request and parse the HTTP request/response. It’s best to think of them as separate browsers. There are text-only ones, ones that embed an entire WebKit browser with JavaScript support, and ones that drive an actual FireFox process inside the GUI.

The problem with supporting different drivers is that the capybara can only abstract so much, as each browser supports different features such as HTTP basic. Fortunately, with Ruby it is easy to inspect each driver’s methods and call its version of HTTP basic as needed. By abstracting these into a method, our tests now have a clean way to use HTTP basic with capybara.

require 'test_helper'
 
class Admin::CohortTest < ActionDispatch::IntegrationTest
  def basic_auth(name, password)
    if page.driver.respond_to?(:basic_auth)
      page.driver.basic_auth(name, password)
    elsif page.driver.respond_to?(:basic_authorize)
      page.driver.basic_authorize(name, password)
    elsif page.driver.respond_to?(:browser) && page.driver.browser.respond_to?(:basic_authorize)
      page.driver.browser.basic_authorize(name, password)
    else
      raise "I don't know how to log in!"
    end
  end
 
  test "should block access without invalid HTTP auth" do
    visit '/admin'
 
    assert_equal 401, page.status_code
  end
 
  test "should show the page" do
    basic_auth('edavis', 'password')
 
    visit '/admin'
 
    assert_equal 200, page.status_code
    assert has_content?("Cohorts")
  end
 
end

Looking back at the ideal authentication test we can see that this is very close to fulfilling the behavior we want.

1. The basic_auth method enters the authentication data and submits.
2. visit tries to open a HTTP basic protected page, which opens the login form.
3. The final assert has_content?("Cohorts") verifies that the login was successful.

Because of how HTTP basic works the flow is a bit different in that we are setting the authentication first and then loading the page. It’s not ideal but for something quick I think it’s understandable enough.

Ideally, you’d extract the basic_auth method to the test helper so you can reuse it in other tests.

Gotchas

There are a few gotchas to be aware of when using and testing HTTP basic this way:

• With HTTP Basic, authentication is passed in the clear to the server. Depending on your application this might be a problem. On Chirk HR I’m using SSL for everything so the HTTP Basic headers are encrypted there. For something stronger than HTTP Basic, try using HTTP Digest or a full authentication system.
• The test is calling methods on the underlying driver which could break if you switch capybara drivers. You’ll want to standardize on one or two drivers for you application to keep things simple.
• Also if the drivers change their HTTP basic APIs in the future then your tests might start failing.

Using and testing HTTP Basic authentication in Rails doesn’t need to be difficult. While it isn’t as fully featured as full authentication systems like devise or sorcery, HTTP Basic could be a good enough system for you to use in your application.

Thanks to the Stackoverflow post where I learned this.

This week I decided to learn a bit more about Redis. I’ve used Redis in Chirk HR already but only as part of a non-critical service to see how it performs under load (I’d like to screencast this later). Today I wanted to use Redis as an actual data store but first, what is Redis?

What is Redis?

Redis is an open source key-value store. I think of it as a light nosql database with a lot of flexibility.

Today’s application

My idea for today was to build my running journal but this time as a CRUD style web app. I want to stay close to the metal so I can really see how Redis works so I picked my second favorite web framework: Sinatra.

Basically I wanted to mimic a Rails scaffold inside Sinatra using Redis as the data storage. I’m also using the redis gem because it is very similar to the actual Redis API. This means I’ll be implementing the data layer myself, without an ORM.

(Normally I’d use ActiveRecord or Datamapper for production applications instance but I’m more concerned with learning and exploration with this.)

Since I will be doing a lot of data layer work I’m also opting for heavy TDD with this app, using minitest and autotest.

Here is the Gemfile I ended up with:

source :rubygems
 
gem "sinatra", :require => "sinatra/base"
gem "shotgun"
gem "redis"
 
group :test do
  gem "minitest"
  gem "rack-test"
  gem "autotest"
  gem "autotest-notification"
end

Use TDD for the application behavior

After getting everything hooked up I decided to split the tests into two files:

1. test_redis_running.rb to test the RedisRunning Sinatra application at the integration layer. This would be the controller and view if you’re thinking about it as a MVC app.
2. test_run.rb to test the Run class, which is used as the data layer between the application and Redis.

I like to start with integration testing and write pending tests for each major workflow or feature. I came up with the following integration tests to get started with:

• test_get_root_response
• test_get_root_list_runs
• test_get_root_add_form_present
• test_post_new_with_valid_run
• test_post_new_with_invalid_run
• test_get_edit_response
• test_get_edit_show_form
• test_put_update_with_valid_update
• test_put_update_with_invalid_update
• test_delete_response
• test_delete_should_delete_record

This is very similar to Rails scaffold except I decided to put the new form on the list of runs (:index) and to skip the details of a run (:show). With such a small data model, a list provides a perfect summary.

The first test I wrote was to check that getting the index was successful, which isn’t about Redis at all so I won’t bore you with the details of it.

The second test on the other hand (test_get_root_list_runs), is the important one (and as you’ll see later is all that I had time for). Here I wanted to do a few things:

1. Create a few runs and save them to Redis
2. Load the index page
3. Check that the runs were displayed

In order to implement this test I have to do a full cycle of saving and loading runs from Redis. This meant I’d need to build the data layer now.

Here is the full integration test.

  def test_get_root_list_runs
    run1 = Run.new(:date => "2012-09-28",
                   :distance => "3mi",
                   :duration => "30:00",
                   :pace => "10:00",
                   :comment => "A run")
    assert run1.save, "Save failed"
 
    run2 = Run.new(:date => "2012-09-29",
                   :distance => "3mi",
                   :duration => "27:00",
                   :pace => "9:00",
                   :comment => "Another run")
    assert run2.save, "Save failed"
 
    get '/'
 
    assert last_response.body.include?("A run")
    assert last_response.body.include?("Another run")
  end

RedisRunning Data Layer

The integration test needed three things from my Run class:

1. Create an object with some attributes
2. Save the object to Redis
3. Load the saved object out of Redis

I started with the first, using standard Ruby accessors.

Run accessors and attributes

A run has five attributes that a user should be able to set:

1. date
2. distance
3. duration
4. pace
5. comment

Additionally, I’m going to need some way to uniquely identify each run. In Postgres I’d just use an id field as a primary key but from what I see, Redis doesn’t have primary keys. Only keys.

At first I thought of using the date as the primary key, but many runners will run multiple times per day so that won’t work. I could use a combination of the date and another field like distance or duration but there is also a chance those will conflict also (e.g. two runs per day, around a 1 mile track at a specific pace).

Redis doesn’t have primary keys so you might need to roll your own.

So I’ll need to be creating my own unique ids for each run. I’ve used UUIDs before and they seem like a good fit here.

So using attr_accessor and initialize I can easily fulfill these requirements.

The test:

class RunTest < MiniTest::Unit::TestCase
  def test_has_attributes
    run = Run.new
 
    ['date','distance','duration','pace','comment'].each do |attribute|
      assert run.respond_to?(attribute), "Run does not respond to #{attribute}"
      assert run.respond_to?(attribute + "="), "Run does not respond to #{attribute}="
    end
 
  end
 
  def test_should_allow_setting_attributes_on_initialize
    run = Run.new(:date => '1', :distance => '2', :duration => '3', :pace => '4', :comment => '5')
 
    assert_equal '1', run.date
    assert_equal '2', run.distance
    assert_equal '3', run.duration
    assert_equal '4', run.pace
    assert_equal '5', run.comment
  end
end

The implementation:

class Run
  attr_accessor :id
  attr_accessor :date
  attr_accessor :distance
  attr_accessor :duration
  attr_accessor :pace
  attr_accessor :comment
 
  def initialize(attributes={})
    attributes.each do |attribute, value|
      setter = "#{attribute}="
      self.send(setter, value) if self.respond_to?(setter)
    end
  end
end

Generating unique ids with UUID

I’ve used some libraries to generate UUIDs in Ruby but I just found out that Ruby 1.9.3 now has UUID support in the standard library as part of SecureRandom. This makes the UUID code simple.

The test.

  def test_id_should_be_a_uuid
    run = Run.new
 
    assert run.id.is_a?(String)
    assert_equal 36, run.id.length
    assert_equal 4, run.id.count('-')
  end

The implementation.

# Way up top outside the Run class...
require 'securerandom'
 
# In the Run class...
  def id
    @id ||= SecureRandom.uuid
    @id
  end

By using ||= I can make sure that if a Run already has an id then I won’t generate it again (existing record).

I also wrote a brute force test to make sure Ruby’s UUIDs were unique and that I wasn’t misreading the docs. It’s not really production quality but good for exploration of a new API:

  def test_id_should_be_unique
    # Lets create a bunch of runs and check their uniqueness.
    # TODO: not the best solution but time is limited
    runs = 100.times.collect { Run.new.id }
 
    assert_equal 100, runs.uniq.length, "Duplicate ids found"
  end

Saving a run to Redis

Now that I have a data format in Ruby, I need to save it to Redis. Since Redis is a key value store, I decided to save my runs where the key is the id (uuid) and the data is a hash of strings. This way it would be easy to load the data back into a Ruby object.

Since the integration test uses the #save method, that’s what I need to implement first. After writing two quick tests I’m ready to figure out how to save to Redis:

  def test_save_with_valid_attributes
    run = Run.new(:date => "2012-09-28",
                  :distance => "3mi",
                  :duration => "30:00",
                  :pace => "10:00",
                  :comment => "A run")
 
    assert run.save, "Save failed"
 
    assert $db.keys.include?(run.id), "Run not found in Redis"
  end
 
  def test_save_with_mostly_empty_attributes
    run = Run.new(:date => "",
                  :distance => "",
                  :duration => "",
                  :pace => "",
                  :comment => "")
 
    assert run.save, "Save failed"
 
    assert $db.keys.include?(run.id), "Run not found in Redis"
  end

Redis uses a #set method to save data. It takes the key and value of the data and will return an “OK” when it succeeds.

One thing that tripped me up for a minute was that if I just sent a Ruby hash to Redis it would get saved but as the string interpolation of the hash like

'{"f"=>"g"}'

This wouldn’t work because I’d need to use eval to turn that back into a Ruby hash if I wanted to load it into a Run object.

So I turned to my old standby, JSON. By calling #to_json on the Ruby hash before sending it to Redis, I can be sure that I can unserialize it on the way back out. This is what Redis stored when I encoded the hash above into JSON.

'{"f":"g"}'

That figured out, the #save method became easy. Just use #set to save the JSON using a run’s uuid as the key.

  def save
    response = $db.set(id, {
                         "id" => id,
                         "date" => @date,
                         "distance" => @distance,
                         "duration" => @duration,
                         "pace" => @pace,
                         "comment" => @comment
                       }.to_json)
 
    return response == "OK"
  end

Why not use the native hash support in Redis?

Redis natively supports hashes with operations like hset, hget, and hkeys. I probably should have use them instead of JSON but I forget all about them until after I was done. Switching to a native Redis hash wouldn’t be difficult at all, because all of that logic is hidden inside two methods of the Run class. The Sinatra application itself doesn’t even know that Redis is used at all.

Loading a Ruby object out of Redis

The next step in the integration test is to load an object out of Redis and into Ruby, to be used by erb when creating the HTML page.

Mimicking ActiveRecord’s API again, I decided to name this method #find and only support finding a run by it’s uuid. The test is simple:

1. Create a run object
2. Save it to Redis
3. Load the run object out of Redis
4. Make sure its data is correct

  def test_find_existing_run
    run = Run.new(:date => "2012-09-28",
                  :distance => "3mi",
                  :duration => "30:00",
                  :pace => "10:00",
                  :comment => "A run")
 
    assert run.save, "Save failed"
 
    redis_run = Run.find(run.id)
    assert_equal run.id, redis_run.id
    assert_equal "2012-09-28", redis_run.date
    assert_equal "3mi", redis_run.distance
    assert_equal "30:00", redis_run.duration
    assert_equal "10:00", redis_run.pace
    assert_equal "A run", redis_run.comment
  end

Notice how I’m using an actual run object and its attributes this time instead of a raw hash from Redis. This is what the Run data model class is providing me.

Thinking about the #find method, it needs to do two things:

1. Load the raw data from Redis, if it’s available
2. Convert the raw data into a Run object

Loading the data is quite easy. Redis uses the #get method to fetch a single object, all you have to do is give it the key. If it finds an object, it is returned. If Redis doesn’t find the object, you’ll get a nil back. This makes it simple to use an if statement for control flow between these two cases.

Since the raw data is JSON, I needed to feed it through a JSON parser to convert it to a Ruby hash. This isn’t all I needed though, I wanted a Run class so I can interact with it right away. Since my earlier work created an initialize method that could set attributes based on a hash, I could easily send the data there and get a Run object back out.

In less words, here is the code:

  def self.find(uuid)
 
    record = $db.get(uuid)
 
    if record
      return new(JSON.parse(record))
    else
      return nil
    end
  end

Where are we now?

Going back up the stack to the integration test, the data layer (Run) works for initialing, saving, and loading a record. That means all I have to do is to load all of the Runs from Redis and show them on the index page.

But, I’m out of time now.

I already have an idea of how I’d go about listing the Runs, using Redis’s keys method which returns all keys and then using mget to get multiple keys in one call. After that it’s just a delete action and the HTML.

Summary

Even though I didn’t get any user interface written, I created most of the data model and had some good tests to make sure the data was behaving the way I wanted. Finishing up the application would be straight-forward and would just take some more time than I have available.

Like I said in the introduction, I have Redis running in production for Chirk HR while I test how easy it is to keep running. As of this writing, the Redis server has been online and receiving data for over 16 days and 16 hours with no downtime (probably longer, my monitoring system lost its network connection for a bit).

Given this exploration and my production test I’ve gotten very comfortable with Redis and will be adding it to my developer toolbox for future apps. I think it’s great when you need a simple and stable key/value store.

Screencast

Full code

Gemfile

source :rubygems
 
gem "sinatra", :require => "sinatra/base"
gem "shotgun"
gem "redis"
 
group :test do
  gem "minitest"
  gem "rack-test"
  gem "autotest"
  gem "autotest-notification"
end

RedisRunning Sinatra application

require 'rubygems'
require 'sinatra'
require 'securerandom'
require 'json'
 
$db = Redis.new
$db.select(1) # To get a different database
 
class Run
  attr_accessor :id
  attr_accessor :date
  attr_accessor :distance
  attr_accessor :duration
  attr_accessor :pace
  attr_accessor :comment
 
  def initialize(attributes={})
    attributes.each do |attribute, value|
      setter = "#{attribute}="
      self.send(setter, value) if self.respond_to?(setter)
    end
  end
 
  def id
    @id ||= SecureRandom.uuid
    @id
  end
 
  # Save a run to Redis
  def save
    response = $db.set(id, {
                         "id" => id,
                         "date" => @date,
                         "distance" => @distance,
                         "duration" => @duration,
                         "pace" => @pace,
                         "comment" => @comment
                       }.to_json)
 
    return response == "OK"
  end
 
  def self.find(uuid)
 
    record = $db.get(uuid)
 
    if record
      return new(JSON.parse(record))
    else
      return nil
    end
  end
end
 
 
class RedisRunning < Sinatra::Base
  get '/' do
    "Hi"
  end
end

Application tests

require 'rubygems'
require 'bundler'
 
Bundler.require
 
require './redis_running'
require 'minitest/autorun'
require 'rack/test'
 
ENV['RACK_ENV'] = 'test'
 
class RedisRunningTest < MiniTest::Unit::TestCase
  include Rack::Test::Methods
 
  def app
    RedisRunning
  end
 
  def setup
    # Select a test database and clean it
    $db.select(2)
    assert_equal "OK", $db.flushdb
    assert_equal [], $db.keys
  end
 
  def test_sanity
    assert_equal 2, 1 + 1
  end
 
  def test_get_root_response
    get '/'
 
    assert last_response.ok?
  end
 
  def test_get_root_list_runs
    run1 = Run.new(:date => "2012-09-28",
                   :distance => "3mi",
                   :duration => "30:00",
                   :pace => "10:00",
                   :comment => "A run")
    assert run1.save, "Save failed"
 
    run2 = Run.new(:date => "2012-09-29",
                   :distance => "3mi",
                   :duration => "27:00",
                   :pace => "9:00",
                   :comment => "Another run")
    assert run2.save, "Save failed"
 
    get '/'
 
    assert last_response.body.include?("A run")
    assert last_response.body.include?("Another run")
  end
 
  def test_get_root_add_form_present
    get '/'
 
    assert last_response.body.include?("form")
    assert last_response.body.include?("Add a new run")
  end
 
  def test_post_new_with_valid_run
  end
 
  def test_post_new_with_invalid_run
  end
 
  def test_get_edit_response
  end
 
  def test_get_edit_show_form
  end
 
  def test_put_update_with_valid_update
  end
 
  def test_put_update_with_invalid_update
  end
 
  def test_delete_response
  end
 
  def test_delete_should_delete_record
  end
end

Data storage tests

require 'rubygems'
require 'bundler'
 
Bundler.require
 
require './redis_running'
require 'minitest/autorun'
require 'rack/test'
 
ENV['RACK_ENV'] = 'test'
 
class RunTest < MiniTest::Unit::TestCase
  def setup
    # Select a test database and clean it
    $db.select(2)
    assert_equal "OK", $db.flushdb
    assert_equal [], $db.keys
  end
 
  def test_has_attributes
    run = Run.new
 
    ['date','distance','duration','pace','comment'].each do |attribute|
      assert run.respond_to?(attribute), "Run does not respond to #{attribute}"
      assert run.respond_to?(attribute + "="), "Run does not respond to #{attribute}="
    end
 
  end
 
  def test_should_allow_setting_attributes_on_initialize
    run = Run.new(:date => '1', :distance => '2', :duration => '3', :pace => '4', :comment => '5')
 
    assert_equal '1', run.date
    assert_equal '2', run.distance
    assert_equal '3', run.duration
    assert_equal '4', run.pace
    assert_equal '5', run.comment
  end
 
  def test_id_should_be_a_uuid
    run = Run.new
 
    assert run.id.is_a?(String)
    assert_equal 36, run.id.length
    assert_equal 4, run.id.count('-')
  end
 
  def test_id_should_be_unique
    # Lets create a bunch of runs and check their uniqueness.
    # TODO: not the best solution but time is limited
    runs = 100.times.collect { Run.new.id }
 
    assert_equal 100, runs.uniq.length, "Duplicate ids found"
  end
 
  def test_save_with_valid_attributes
    run = Run.new(:date => "2012-09-28",
                  :distance => "3mi",
                  :duration => "30:00",
                  :pace => "10:00",
                  :comment => "A run")
 
    assert run.save, "Save failed"
 
    assert $db.keys.include?(run.id), "Run not found in Redis"
  end
 
  def test_save_with_mostly_empty_attributes
    run = Run.new(:date => "",
                  :distance => "",
                  :duration => "",
                  :pace => "",
                  :comment => "")
 
    assert run.save, "Save failed"
 
    assert $db.keys.include?(run.id), "Run not found in Redis"
  end
 
  def test_find_existing_run
    run = Run.new(:date => "2012-09-28",
                  :distance => "3mi",
                  :duration => "30:00",
                  :pace => "10:00",
                  :comment => "A run")
 
    assert run.save, "Save failed"
 
    redis_run = Run.find(run.id)
    assert_equal run.id, redis_run.id
    assert_equal "2012-09-28", redis_run.date
    assert_equal "3mi", redis_run.distance
    assert_equal "30:00", redis_run.duration
    assert_equal "10:00", redis_run.pace
    assert_equal "A run", redis_run.comment
  end
 
end