One way is to call the API, sleep, and then run the test. The problem with this is that you have to wait the entire sleep duration for every test run, even if the results are ready before the sleep is done. RSpec’s and Ruby’s flexibility allow you to avoid this situation by writing a helper function:

def wait(time, increment = 5, elapsed_time = 0, &block)
  begin
    yield
  rescue Exception => e
    if elapsed_time >= time
      raise e
    else
      sleep increment
      wait(time, increment, elapsed_time + increment, &block)
    end
  end
end

To use this function, you pass your test to it as a block. The wait function will immediately try the test. If a failure is reported – which in RSpec is just an exception – the function catches the failure and sleeps. The assumption is that a failure means the API that is called into has not yet completed the action that is being waited upon. The wait function continues to retry the test until the test either passes or until it reaches the timeout that was passed to it, at which point it will raise the last error it caught, which will be the last failure of the test it ran.

The wait function has the benefit of returning successes as soon as they are encountered, so the tests don’t have to sleep for the entire duration specified. However, it still has to wait the entire sleep period for a failure, because it can’t distinguish a legitimate failure from the API service not yet returning the correct results.

Using the wait function in an RSpec test looks like this:

describe "a test" do
  before :each do
    insert_user_remote_service("user")
  end

  after :each do
    delete_user_remote_service("user")
  end

  it "should receive the results it expects from the api" do
    wait 30 do
      search_for_user_in_remote_service("user").should == "user"
    end
  end
end

It’s useful if you collect a bunch of git repos in one master folder (say ~/src, for instance) and want to be able to scan the current state of each repo easily.

You can also pass the script the -b or –branch option and it will report the current branch of repos that don’t have any modified files, in addition to those that branches that do have modified files.

Chef has a major pain point in the Ruby community: ActiveSupport.

ActiveSupport is a library of useful functions that was born from Rails, adding into Ruby all sorts of helper functions. It does so by monkey patching core classes. The monkey patching makes it easy to not even realize you’re using ActiveSupport.

ActiveSupport works great in Rails – because Rails was built from the ground up to use ActiveSupport. Where ActiveSupport falls down is in projects not built from the ground up to use it. Chef is one of those projects.

Chef does not use ActiveSupport. If you run Chef there is no need to install ActiveSupport and Chef will not install ActiveSupport. However, one of the great features of Chef is that you can use any Ruby code of your choosing in the cookbooks – including ActiveSupport, or more insidiously, a gem that pulls in ActiveSupport.

When ActiveSupport gets into Chef’s load path, it has the potential for insidious harm, due to the monkey patching it performs. With Chef this particularly strikes around json operations. Chef does a fair amount of serializing to and from json, using the json gem to accomplish this. ActiveSupport has its own opinions on how json should be serialized/deserialized and will override the json gem.

The Rails team is aware that ActiveSupport interferes with the json gem and has provided ways to defer to it. These work great, so long as you have consciously made the decision to load ActiveSupport and to tell it to use the json gem. What if your project is like Chef, which doesn’t need or want ActiveSupport, but might find it loaded? It is difficult to undo monkey patching once it is present, especially if you want to be a good citizen and not interfere with ActiveSupport when something else might be relying on it.

Opscode has tried to devise fixes that work around ActiveSupport when it is present, without changing the behavior of ActiveSupport. These should go out in a future Chef release. My recommendation is, even after the fixes go out, to run Chef without ActiveSupport. If you must use ActiveSupport and you see an error that can be traced to strange json, try setting ActiveSupport to use the json gem for its backend. It’s also possible that you won’t notice anything wrong with ActiveSupport present, as Chef is fairly promiscuous in the json it allows and will often correctly interpret the json.

If all else fails, file a bug with Opscode and we’ll do our best to keep working around ActiveSupport, since it isn’t going away anytime soon.

First clone the repo if you haven’t:

git clone url-to-repo-you-want

Clone has already checked out the branches, but it only initially creates the master branch. You have to tell it to create the other branches you might want.

To do that:

git checkout -t origin/branch-name

This will checkout and create a branch that has the name branch-name and that tracks the remote branch at origin/branch-name.

If you want your branch to have a different name from the remote branch:

git checkout -t -b your-branch-name origin/branch-name

This creates a branch with your-branch-name that tracks the branch at origin/branch-name.

Because these commands uses checkout you will then have the new branch as your current working branch. You can use git branch with the -t (–track) flag to create the branch without switching to it.

If you’re working in a repo you’ve already cloned and want to checkout a newer branch, it maybe necessary to do a git fetch first to make sure your local checkout knows about the remote branch before you create a local branch.

© 2001.

Only ten years ago the agile movement formally started. I’m sure it was around informally before then. Now it’s an institution that is embodied in methodologies and programs from XP to Scrum.

It good to read the manifesto that started it all. To see the simplicity that launched a movement. Because overtime, as is human nature, we keep adding on facets, until we forget what the original item looked like. This can be for better or worse (think a person from the 50s would recognize a TV today as a TV, if it wasn’t on?).

One facet we’ve added is the concept of velocity. Jim Highsmith details nicely how the concept of velocity has been stretched so it chokes the agile process. A key quote:

Compounding the problem, the Agile movement has focused on high levels of customer involvement—basically a good thing—but we’ve gone too far. A large number of Agilists decry that they can’t get organizations to focus on technical practices—but why should that be a surprise when we encourage product managers/owners to make all the priority decisions and then measure performance using velocity?

This point is spot on. In my experience, product owners are often given complete control over priority, so technical optimizations or necessary muck work aren’t prioritized. Going back to the agile manifesto, read over the names of the original signers. They all have experience in the technical and the business sides of the equation. They intuitively know how to balance both. Now that agile has gained widespread adoption, teams do not necessarily have this experience.

The idea of the self organizing team needs to return to the agile movement. The team doesn’t have to be self organizing in that team members constantly change. That becomes too disruptive. The team needs to be self organizing in that the team picks the order of the work they will complete. The product owner might set priority, but it is the team that takes on the work and the order they complete it. There is obviously back and forth between the team and the product owner, but as the manifesto says: people over process. We trust that the team will organize itself, taking into consideration the wishes of the business, so that the work gets done as quickly as possible with the highest quality.

I think people often forget that agile is not a rigid system to be followed. It is simply a belief that change is constant, so we should favor a way of doing things that makes change easy.

In short, do what works for you so that you develop quality software on time. That’s the definition of agile, with all the trappings stripped away.

And so development starts / CC License