April Developer Challenge: Feature Development With Pull Requests

Note: This was originally posted to the Dynamo Blog.

This month’s Dynamo Developer Challenge has been inspired by our own Daniel Wright—more about that in the moment.

In a nutshell, for the month of April we will be experimenting across the studio with using Pull Requests to develop a new features. We are moving beyond simply using them as a Code Review tool, as we have in a past challenge.

Over the last few months, Daniel has been religiously using Pull Requests to push new features. As I’m a bit of GitHub stalker I love seeing this, as it gives me a chance to provide feedback on commits and putting Code Reviews into practice. However, these Pull Requests were created once the feature was deemed “done.”

After viewing Zach Holman’s slides from a talk titled GitHub: Behind the Feature, Daniel began creating Pull Requests at the start of a new feature. And I’ve been impressed by what I have seen so far! But I don’t want to get a head of myself; I’ll share some observations at the end of this challenge.

So, how does this all work?

Here’s some steps, based on the write-up Daniel did for his current project:

1. Choose a feature to implement, and create a new Git feature branch for it.
2. Once you’ve selected your feature to work on, you’d create a new branch for it: git checkout -b features/your-new-feature
3. Now do a very small amount of work, just enough that you can commit it. For example, you might create the view-template you’re going to use (e.g. app/views/pages/about.html.haml).
4. Now commit it! git add . && git commit -m "Adds about page template"
5. Push your branch up to GitHub: git push -u origin HEAD
6. Finally, visit the project page on GitHub and create the pull request. Since you just pushed the branch, the project’s landing-page should prompt you to create the pull request. Give it a descriptive title, and describe what you’re planning to accomplish with the PR. For a simple integration job, this should be fairly straightforward, but you can be as descriptive as you like.
7. Submit the pull request!

So, the April challenge has been posted for our Dynamo-Devs, but we encourage you to join us too. Are you up for the challenge? Please share you experiences in the comments along with our team’s.

For a little more background on this development strategy, checkout the slides below:

Developer Challenges: Helping Us to Improve Our Craft

NOTE: This was originally posted to the Dynamo Blog.

We’re sharing an initiative that we’ve been experimenting off and on over the last year called “Improving Your Craft”, a.k.a Dynamo Developer Challenges.

These began as weekly challenges to help the team members and the team as a whole to improve development practices and increase developer happiness. Admittedly, when I was first driving this initiative, I was infrequent in posting these challenges, and the weekly schedule was a little too ambitious. Based on feedback from the team, we reduced the frequency to a monthly schedule, and I’m more disciplined in posting challenges each month—a calendar reminder really helps!

Here are some examples of the challenges posted to date:

• Self-Directed Morning Code Review
  Inspired by Jason Fried’s post Morning tells the truth, this challenge asked developers to review their commit log from the previous day as a self-directed code review.
• Pull Requests for Code Reviews
  This time it was Zach Holman’s talk How GitHub Uses GitHub to Build GitHub. The driver for this challenge was to encourage developers to review each others code, pollinating knowledge across projects. If you’re not currently using pull requests, GitHub has some great documentation on the topic.
• In-Person Peer Code Reviews
  As an extension to the previous challenge, developers were asked to sit down with a peer for a 30-minute code walkthrough. It’s amazing how much the author of the code learns by just walking someone else through it.
• Automation
  A final example was encouraged developers to start thinking what they can do to optimize their workflow. Too often we run the same set of commands everyday, when a simple shell alias can save us from repetitive typing or making a time-consuming mistake.

Hopefully this gives you a feel of the type of challenges that the team has been working on. And we would love if you joined us! Previously, these challenges have been posted to our Basecamp account, but we will now be posting them to the blog. I encourage you to share your experiences in the comments and the team will be sharing their as well, either as comments or blog posts (hint, hint!).

Although I’m a little late this month for April’s challenge, please be on the lookout tomorrow.

Have you tried ctags with Vim?

After reading Mislav Marohnić's excellent post on Vim, I decided to add ctags to my development environment. What does it buy you? It allows you to jump to method or class definitions with these commands:

Setup is pretty easy:

You can generate tags with:

But you probably won't want to do all that manually. As Mislav points out in his post, Tim Pope shows us how to automate tag generation with git hooks.

I've been using ctags this afternoon and already it has turned Vim into a completely different editor for me.

Using Google Site Search for Content Sites: Things to Keep in Mind

I've used Google Site Search for a couple of unstructured content sites (opposed to applications or structured content such as catalogs) and pretty happy with it, but there a certainly some things you should be aware of before committing to this service:

• The service's crawler works the same on Google.com. This means, it will only index publicly available pages that it can access. So you cannot use it on password-protected staging sites.
• If you consider removing the password from the staging site you won't want to do that either, as your site must be registered with Google Webmaster tools, so your staging site will eventually end up in the Google.com index. But there's also another issue.
• Indexes to URL's contain the domain of your site, so you can't index your staging site, then hope to use that index in your live site.

If you're re-launching an existing site -- your only option is to enable search after you have made that site publicly available via the production domain. If it's a new site, and you have the option, make the site publicly available a couple of days before hand and index the site. Google Site Search provides on-demand indexing, updating the index within 24 hours.

When indexing the site, you have three options for supplying URL's:

• Individual URL's only
• URL's linked from a specific page or Sitemap
• URL's in a Sitemap only

Again, you must have your site registered with Google Webmaster Tools for the indexing to work.

For more information on indexing checkout Custom Search Help documentation.

Domain Patterns are Alexandrian Patterns

It's been a while since I have posted on this blog. So just to let you know that I'm still alive, this is what has been keeping me occupied. It's best summed up by a quote from the book Object Thinking by David West. This is a must read for any Rails developer who is following the object-oriented Rails culture.

Patterns most useful to object thinkers should be derived from the problem domain, just as objects are. They should facilitate thinking about co-ordination and scripting of objects or about useful ways of assembling objects into components or applications. They could be considered Alexandrian patterns. Few of the patterns (about 6 of the 23) presented in the GoF book satisfy this demand. Martin Fowler’s book on Analysis Patterns presents examples derived from a domain and is much closer to Alexander’s intent than the GoF book.

My intent is to post more on Domain Patterns in a Rails context in the near future. We'll see.

Testing Terminology: Spies, Stubs and Mocks

When referring to the definitions of Spies, Stubs and Mocks I like to return to XUnit Test Patterns:

• Test Spy: "We use a Test Double to capture the indirect output calls made to another component by the SUT for later verification by the test."
• Test Stub: "We replace a real object with a test-specific object that feeds the desired indirect inputs into the SUT."
• Mock Object: "We replace an object the SUT depends on with a test-specific object that verifies it is being used correctly by the SUT."

You may have noticed that a Spy and Mock seem to have similar definitions, and do serve similar purposes, however Mocks specify expectations up-front and don't require assertions in contrast to Spies, that verify after the fact. Here's an example that compares Rspec Mocks with Bourne's Spies:

SUT is an abbreviation for System Under Test.

The above patterns are collectively know as Test Doubles: "We replace a component on which the SUT depends with a test-specific equivalent." Rspec's built-in mocking library includes a double method/alias, see An Example using RSpec double, mock, and stub.

Double-Ruby (RR) is another example of a test double framework implemented in Ruby.

Heads up: Use spork-rails if you want to use spork 1.0rc in your Rails project

If you are using Spork 1.0rc in your Rails project and wondering why your controllers etc are not reloading, it's because this functionality has been extracted to the spork-rails plugin gem. Remove the spork reference from your Gem file and add 'spork-rails' instead. spork-rails will include spork 1.0rc as a dependency. This follows the convention for other gems such as rspec-rails and factory_girl_rails. Note spork-rails follows the versioning of minor Rails versions. For example, the current version is 3.2.0, compatible with Rails 3.2.x down to 3.0.0.