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.

Checking out a branch from Github

© 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

The Trappings of Agile

It turns out that in my fourth year out of college I am already working at my fourth job. I intend to stay at this one for a while. While I enjoyed my time at iContact and thank them for everything they did for me, on October 17th I started work for Opscode, the company behind Chef.

The Opscode team is an amazing group and I lept at the chance to go work for them. It’s a change to go from scaling email sending to infrastructure automation, but I’m excited at the challenge. It’s yet another interesting problem to vex me until I conquer it.

It’s time to further sharpen my skills and help companies Rule the Cloud.

Knives / CC License

Becoming A Chef

All the rage in entrepreneur circles at the moment is the concept of the Lean Startup. The term, coined by Eric Ries, is a startup that achieves validated learning through the build-measure-learn loop. What is validated learning? Learning what the customer actually wants so that a useful product and a sustainable business model are built.

It may not appear that the Lean Startup and DevOps are related. Obviously, with a statement like that, I’m now going to tell you how they are. It starts with small batches.

Small batches are the practice of having cross-functional teams work together on the smallest units of work possible while pushing that work to the customer as soon as possible. In working this way, the product gets to the customer quickly, allowing the business model or product direction to be validated.

The common model today is large batches. Instead of a small team working cross-functionally to push a product in front of a customer, the team specializes, with various team members completing their phase of the product before passing it on to the next person in the chain. If at any point a fault is found, the product has be sent back down the chain while those up stream ideal, waiting for the product to reach them. All the while nothing is getting put in front of the customers, so no feedback is being gained. Eventually the product will reach the customer, but if any flaws are found or the customer rejects the product, the entire process is repeated, leading to long lead times before customer behavior can be learned.

Contrast this with the small batch process, where small changes are continually pushed to the customer. This leads to quick feedback and rapid turn around times, resulting in a better product.

Lean startups embrace small batches as I’ve just described. DevOps is the same. DevOps is about embracing small batches, but the batch in this case is a narrow part of the overall process: pushing a product from development to deployment to seeing it in use.

DevOps is about allowing production behavior to quickly feed back to developers so that development can adjust quickly to situations in production. Often times the fastest way to make this happen is to have developers occasionally serve as, or even to be, the operations team. As with the lean startup, the potential efficiency of an individual unit (developers, operations) might appear to be undercut, but the efficiency of the system as a whole (developing products that work in production) is sped up.

When developing a system it is easy to envision how a system should run, but that doesn’t mean that is how the system will run. Often unavoidable differences in hardware and traffic lead to differences in how the system actually performs with how it was envisioned to perform.

DevOps is about tightening the same loop as the Lean Startup: the build-measure-learn loop. The only difference is the narrower focus of DevOps. With the loop as tight as possible, knowledge gained from the actual system is fed back into the next iteration of the product so the system becomes better in small, but tight, increments.

DevOps is a subset of the Learn Startup. Both are a reaction to today’s fast changing world and the need to create a system that can optimize the whole quickly, even if that means undercutting what appears to be the efficiency of the individual unit.

Both DevOps and The Lean Startup are about eliminating waste.

Waste / CC License

I’ve only touched the surface of the Lean Startup and DevOps movement. For more on DevOps and to read the article that inspired this one, see the Ars Technica article Google CIO and others talk DevOps and “Disaster Porn” at Surge.

For more on the lean startup, read Eric Ries’ blog on the topic, or read his recently published book, The Lean Startup.

DevOps and The Lean Startup

These are the directions of how I did that.

These steps can be found in other places, but my hope is that by collecting them all in one place I make it easier for others.

First stop, Java.

Java 7 is not yet officially out for Lion, but it is possible to install a Mac OS X port early release version without too much trouble.

The directions are available on the OpenJDK Mac OS X Port page.

First make sure you meet the prerequisites, such as having a 64 bit capable machine, having Lion, having the latest Xcode installed (Version 4.1, available through the Mac app store for free).

Once you’ve verified the prerequisites and installed Xcode 4.1 if you need it, you’ll need to download Apple’s preview of Java 7. This doesn’t install Java 7, but it is necessary so that you have the proper APIs for Java 7 to work on the Mac.

To download it, go to connect.apple.com.

You will need to log in using your Apple Id and password. You can register if you don’t have one.

Once in, navigate to the Java section. You’ll then want to download the latest disk image for Lion, which as of this writing is Java for 10.7 – 11M3504 (Disk Image).

Once the download is complete, run the disk image and install it.

Next you’ll need to follow further directions from the Mac OS X Ports page, found here.

The directions will tell you how to install a preview version of Java 7 on Lion. You can either build it from source or download an unofficial build. I opted to download the latest unofficial build, which is OpenJDK-OSX-1.7-universal-20110822.dmg at the time of this writing.

Once downloaded, install it.

Now Java 7 is on your system, but it won’t be the default Java. To make it the default Java, launch:

/Applications/Utilities/Java Preferences.app

and drag both of the OpenJDK 7 entries to the top of the list. Then close the Java Preferences app. Java 7 is now installed on your system and is the default.

To make sure Java 7 is the default, launch a terminal and run java -version.

You should see output that looks similar to this:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

It’s onto JRuby.

Download the latest JRuby from jruby.org (as of this writing, it is 1.6.4).

I downloaded the tar ball. Extract it. It will place a jruby-1.6.4 folder wherever you extracted it to.

Move the folder to the location you want it on your system, if it isn’t already there.

Add the bin folder from the jruby folder you extracted to your system path. Good directions can be found at Hathology.com. Note that those directions modify the path for every user on the system, not just a single user.

Once that is done, close and restart any terminals you have open. Then type jruby -v and you should see this:

jruby 1.6.4 (ruby-1.8.7-p330) (2011-08-23 17ea768) (OpenJDK 64-Bit Server VM 1.7.0-internal) [darwin-x86_64-java]

Success. You’re now running JRuby with Java 7 on Mac OS X Lion.

Since the Java 7 isn’t an official version, I can’t promise there won’t be bugs or other weirdness, but that’s the fun of living on the edge.

JRubyConf Post Design / CC License 

Installing Java 7 and JRuby on Mac OS X Lion