This event will be streamed live starting at 6:00. Tune in at ustream.

Most projects consist of code that the team writes and third-party code that the team purchases or obtains from an open source provider.

Average developers conceptualize third-party code as a fixed entity to call upon and use. Good developers usually become experts with the third-party components they use.

Great developers view code they didn’t write as an open and modifiable resource (assuming the code is open source). Great developers aren’t reluctant to look behind interfaces and fully understand, or even modify, the implementation.

The perspective difference is elegantly described by Robert M. Pirsig in Zen and the Art of Motorcycle Maintenance.

I’ve noticed that people who have never worked with steel have trouble seeing this… that the motorcycle is primarily a mental phenomenon. They associate metal with given shapes… pipes, rods, girders, tools, parts… all of them fixed and inviolable, and think of it as primarily physical.

But a person who does machining or foundry work or forge work or welding sees “steel” as having no shape at all. Steel can be any shape you want if you are skilled enough, and any shape but the one you want if you are not. Shapes, like this tappet, are what you arrive at, what you give to the steel. Steel has no more shape than this old pile of dirt on the engine here. These shapes are all out of someone’s mind.

I was pleased when Andy Keller’s recent Software GR talk hit upon the mindset of ownership for the code you buy or use from a third-party provider. When something goes wrong with your product, your customers don’t care if you wrote the code or got it from someone else. As a steward of your product, you have the responsibility to expediently fix issues that occur.

When issues do occur with a third-party component, great developers are worth their weight in gold.

A great developer will expose third-party bugs with automated tests and then create and submit a patch back to the provider.

Anecdotal forum browsing will show that average developers post questions and wait for an expert to do the thinking. Average developers may be blocked for days while they wait for an expert to investigate the issue and provide a solution.

Even though open-source resources allow average teams to be greatly productive, when quality and dependability matter, there is no substitute for great teams.

Average developers can become great developers by adopting the mindset of ownership and a perspective of fluidity towards third-party code. Don’t look at code you work with as a fixed entity. Understand the ideas and intent behind the code and craft it back into shape when necessary.

Do you have a story to share where you or your team stepped up to solve a problem with third-party code?

The first step of bringing Backbone Support into your project (after including the JavaScript file) is to extend the SwappingRouter in all of your routers. The SwappingRouter needs to know an element to grab hold of to place rendered views into. Whenever you want the router to show a new view, all you have to do is to new one up and pass it to @swap() for display. When @swap() is used, it unbinds and removes the previous view, to allow for garbage collection. Here is a sample:

TestApp = Support.SwappingRouter.extend(
  initialize: (options) ->
    @el = $(".random_element")

  routes:
    foo: "index"
    bar: "bar"

  index: ->
    view = new TestApp.Views.FooIndex()
    @swap view

  bar: ->
    view = new TestApp.Views.Bar(model: new Baz())
    @swap view
)

The example uses CoffeeScript. You can see a little more about using Backbone.js and CoffeeScript in a previous post.

The next step is to extend Support.CompositeView to your views to provide supporting methods for managing child views. The methods provided help render and append child views to an element on the page via @renderChildInto() or appending it to the view’s element itself with @appendChild(). It also provides a @leave() method to allow the view to unbind and remove itself from the page.

For more information, give the Backbone Support github page a read. If you are in need of a more in-depth set of functionality, like @appendChildTo() or @prependChildTo() to place children within a specific element in the view, take a look at the fork from GitHub user domchristie.

One area I have quite a bit of exposure to is healthcare software. The more I think about it, the more the distinctive traits of healthcare lend themselves to agile methodology.

Healthcare has a critical need for their software to work flawlessly. Every time a bug is discovered that may affect patient care, a tremendous amount of time and energy must go into fixing the bug for all affected versions of the software. This is to say nothing of the risk to health and safety that such bugs may inflict. So the software better work. Given the mammoth size and incredible configurability of enterprise-scale healthcare software products, the only way to have a prayer of accomplishing this is through tests.

Within testing, of course I would advocate the usual battery of unit, integration, and system tests. I want to make specific mention of continuous integration testing, or regression testing. A software product that touches every aspect of the healthcare industry is inherently huge. Even with the fastest machines on the market, running every test locally is probably impractical. So it falls to the continuous integration server to catch regressions and cases where seemingly unrelated code changes interfere with each other. Furthermore, the QA on staff at a company big enough to write and maintain this software always has their hands full. Any time and mental energy wasted testing a feature that clearly doesn’t work is a big loss for the company.

Just having a huge array of tests is not sufficient, though. They also have to be the right tests. One of the most valuable traits of a successful developer working on large-scale software is the ability to understand the business domain. This gets put to use in feature design, in meetings with the customer, and of course while actually writing code. How much better to also use this knowledge in unison with test driven development! If developers start by asking “What could go wrong with patient care if we mess this code up?” and then write those tests, then those errors will never happen.

Of course, no one person could be expected to predict every possible bug or issue with the code – which is why it would be quite helpful to have another expert in both the domain and the code sitting there. Keeping track of how the code might inadvertently affect patient care is really just another hat for the non-typing pair to wear, and it meshes well with keeping an eye on the 30,000 foot view.

In my opinion, those are the big ticket items where Agile process would help improve the way complex, safety-critical software like healthcare software is written.

Where have you seen a need for Agile in an industry where it isn’t generally applied?

The following example shows how this works with C++ using Cucumber-Cpp (thanks Paolo Ambrusio) and an example that comes bundled with it.

Features are written in Gherkin, just like standard Cucumber tests. Gherkin is a business-level DSL (Domain-Specific Language) that allows test to be written in high level terminology. This allows tests to be written and understood by non-developers, thus facilitating the conversion of what done should mean for a given feature. Below is a feature definition and scenario for a simple calculator application to validate division:

Feature: Division
  In order to avoid silly mistakes
  Cashiers must be able to calculate a fraction

  Scenario: Regular numbers
    Given I have entered 3 into the calculator
    And I have entered 2 into the calculator
    When I press divide
    Then the result should be 1.5 on the screen

The implementation of the step definitions for all features and the corresponding support for setting up the test fixture are contained in a C++ file. Below is the source file that implements all the needed step definitions for the feature file above, though it also includes step definitions for the rest of the feature files in the test suite. At the top of the file is the implementation of the Context class that is instantiated prior to executing each feature scenario, and is destroyed when the scenario terminates. In the current implementation of Cucumber-Cpp, exceptions (including those in test assertion frameworks) cannot occur in the Context constructor nor destructor. There is a request to in to resolve this limitation.

#include <gtest/gtest.h>
#include <cucumber-cpp/defs.hpp>

#include <Calculator.h>

struct CalcCtx {
    Calculator calc;
    double result;
};

GIVEN("^I have entered (\\d+) into the calculator$") {
    REGEX_PARAM(double, n);
    USING_CONTEXT(CalcCtx, context);
    context->calc.push(n);
}

WHEN("^I press add") {
    USING_CONTEXT(CalcCtx, context);
    context->result = context->calc.add();
}

WHEN("^I press divide") {
    USING_CONTEXT(CalcCtx, context);
    context->result = context->calc.divide();
}

THEN("^the result should be (.*) on the screen$") {
    REGEX_PARAM(double, expected);
    USING_CONTEXT(CalcCtx, context);
    EXPECT_EQ(expected, context->result);
}

Wire communication is done via a simple protocol encoded in JSON. Executing the feature file above yields the output below, which is the same output you would get from a true Cucumber test. Although, the C++ step definitions  get annotated with the source file and line number for cross referencing.

Feature: Division
  In order to avoid silly mistakes
  Cashiers must be able to calculate a fraction

  Scenario: Regular numbers                     # division.feature:6
    Given I have entered 3 into the calculator  # CalculatorSteps.cpp:11
    And I have entered 2 into the calculator    # CalculatorSteps.cpp:11
    When I press divide                         # CalculatorSteps.cpp:22
    Then the result should be 1.5 on the screen # CalculatorSteps.cpp:27

4 scenarios (4 passed)
16 steps (16 passed)
0m0.073s

Adding some debug output to Cucumber shows how the execution happens across The Wire:

Scenario: Regular numbers # division.feature:6
> ["begin_scenario"] # Cucumber sends this message to the Wire server to start the scenario
< ["success"] # Each message sent to the Wire server is acknowledged, and may include response data as well
> ["step_matches", # Cucumber sends the first step of the scenario
    {
      "name_to_match":"I have entered 3 into the calculator"
    }
  ]
< ["success", # The Wire server responds with the regular expression that matches the specified step, including the extracted parameter and location of the step definition
    [
      {
        "regexp":"^I have entered (\\d+) into the calculator$",
        "args":[{"val":"3","pos":15}],
        "id":"1",
        "source":"CalculatorSteps.cpp:11"
      }
    ]
  ]
> ["invoke", # Cucumber now tells the server to go ahead and execute the step
    {
      "args":["3"],
      "id":"1"
    }
  ]
< ["success"] # The server responds with the result
 Given I have entered 3 into the calculator # CalculatorSteps.cpp:11 (This is the normal formatted output that appears on the console after a step is executed)

As you can see, the protocol and data exchange is pretty straight-forward. In addition to Cucumber-Cpp, there are Wire implementations for other languages as well.

This was, in fact, what had led me to become a developer. Growing up, the sense of joy and accomplishment I felt as I wrapped mind around concepts like recursion or object-oriented programming was good enough to be a drug. Coupled with my attention to detail and proclivity to idealism, I found myself focusing intensely on learning a particular language and set of frameworks that I found most elegant.

Eventually, I found myself well-versed in the idioms and practices of the language. This was the goal, after all. I wanted to master the tools I had chosen with a deep, technical understanding and a solid grasp of their design philosophies.

However, it turned out that the journey was more satisfying than the destination. I found that, over time, programming became less thrilling and intrinsically motivating. This was because, by effectively living in a monoculture, I had inadvertently isolated myself from exploring new idioms and ideas from other languages and environments. I was accidentally limiting my ability to discover and learn.

I’m proud that, at Atomic Object, we are generalists. By using many different technologies, and picking up new ones regularly, we keep the passion for development alive because we never stop learning. And the cross-pollination of ideas from the variety of tools we use inevitably leads to the improvement of not only ourselves as developers, but our craft as a whole.

One of the first things I do in the morning is plug in an external video camera and join our project specific Hangout. Once the team has joined, we leave a live video stream going throughout the day. This makes it easy to share thoughts and ideas, as well as reinforce the sense of team across the miles. Google Hangouts also makes it easy to share a screen, online documents and other collaborative tools.

We’ve weathered some of the early adopter pain (UI changes, feature changes, etc), and made the Hangout a daily part of showing up at the office. What tools and resources do you use to help connect with remote teammates?

C++ does not have support for parsing XML data in the standard libraries. I started with a typical Google search, “C++ XML Parsing”, which returned a large number of results… of course. My goal was to find something really lightweight and simple to use. All I wanted to do was iterate over the tree, identify nodes and read attributes. I skimmed through several README files, downloaded a couple libraries and finally stumbled upon RapidXml.

As stated in the project documentation, “RapidXml is an attempt to create the fastest XML parser possible, while retaining usability, portability and reasonable W3C compatibility.” Sounded great to me! I gave it a try and the results were very positive. The library is composed of 4 files, the total size of which is 141KB.

Demonstration

To demonstrate its functionality, I created a sample XML file which contains information about a few breweries that I have visited. It looks like this:

<?xml version="1.0" encoding="utf-8"?>
<MyBeerJournal>
    <Brewery name="Founders Brewing Company" location="Grand Rapids, MI">
        <Beer name="Centennial" description="IPA" rating="A+" dateSampled="01/02/2011">
            "What an excellent IPA. This is the most delicious beer I have ever tasted!"
        </Beer>
    </Brewery>
    <Brewery name="Brewery Vivant" location="Grand Rapids, MI">
        <Beer name="Farmhouse Ale" description="Belgian Ale" rating="B" dateSampled="02/07/2015">
            This beer is not so good... but I am not that big of a fan of english style ales.
        </Beer>
    </Brewery>
    <Brewery name="Bells Brewery" location="Kalamazoo, MI">
        <Beer name="Two Hearted Ale" description="IPA" rating="A" dateSampled="03/15/2012">
            Another execllent brew. Two Hearted gives Founders Centennial a run for it's money.
        </Beer>
    </Brewery>
</MyBeerJournal>

The code below simply reads in the data from the XML file and outputs easily readable text describing the data.

#include <string.h>
#include <stdio.h>
#include <iostream>
#include <fstream>
#include <vector>
#include "rapidxml-1.13/rapidxml.hpp"

using namespace rapidxml;
using namespace std;

int main(void)
{
	cout << "Parsing my beer journal..." << endl;
	xml_document<> doc;
	xml_node<> * root_node;
	// Read the xml file into a vector
	ifstream theFile ("beerJournal.xml");
	vector<char> buffer((istreambuf_iterator<char>(theFile)), istreambuf_iterator<char>());
	buffer.push_back('\0');
	// Parse the buffer using the xml file parsing library into doc 
	doc.parse<0>(&buffer[0]);
	// Find our root node
	root_node = doc.first_node("MyBeerJournal");
	// Iterate over the brewerys
	for (xml_node<> * brewery_node = root_node->first_node("Brewery"); brewery_node; brewery_node = brewery_node->next_sibling())
	{
	    printf("I have visited %s in %s. ", 
	    	brewery_node->first_attribute("name")->value(),
	    	brewery_node->first_attribute("location")->value());
            // Interate over the beers
	    for(xml_node<> * beer_node = brewery_node->first_node("Beer"); beer_node; beer_node = beer_node->next_sibling())
	    {
	    	printf("On %s, I tried their %s which is a %s. ", 
	    		beer_node->first_attribute("dateSampled")->value(),
	    		beer_node->first_attribute("name")->value(), 
	    		beer_node->first_attribute("description")->value());
	    	printf("I gave it the following review: %s", beer_node->value());
	    }
	    cout << endl;
	}
}

and here is the output:

I have visited Founders Brewing Company in Grand Rapids, MI. On 01/02/2011, I tried their Centennial which is a IPA. I gave it the following review:
“What an excellent IPA. This is the most delicious beer I have ever tasted!”

I have visited Brewery Vivant in Grand Rapids, MI. On 02/07/2015, I tried their Farmhouse Ale which is a Belgian Ale. I gave it the following review:
This beer is not so good… but I am not that big of a fan of english style ales.

I have visited Bells Brewery in Kalamazoo, MI. On 03/15/2012, I tried their Two Hearted Ale which is a IPA. I gave it the following review:
Another execllent brew. Two Hearted gives Founders Centennial a run for it’s money.

Overall, I found that RapidXml works very well and is simple to use. One complaint is that if there is a syntax error in the XML file, it doesn’t give you much indication as to what the problem is. But, I suppose that is one of the tradeoffs of using a lightweight tool. The next time you need to parse some XML, from C++, you should give RapidXml a try!

Wait. What? Why am I writing this from Sweden? It’s because I’m fortunate enough to be wrapping up the first Citerus – Atomic Object craftsman exchange.

Why?

I already wrote about the why of the craftsman exchange in my part 1 blog post, but the gist is this: Citerus and Atomic Object are two innovation services firms that value their employees’ professional development. Programming on the side, researching new technologies, and participating in conferences are all great ways to grow. And I’ve done plenty of that. The craftsman exchange is a more interesting and exotic opportunity for growth and to and follow through on my passion for software product development.

Last month we began the exchange by having one of Citerus’s consultants, Mattias Holmqvist, visit us in Grand Rapids; Mattias wrote about his experience after he got home.

Crafting software

The exchange began with four days working on a customer project with Patrik Fredriksson and Håkan Jonson. Patrik met me early on Monday and showed me to the customer’s office, located in the Gamla Stan region of Stockholm, with a beautiful view over the water.

Toward the beginning of the week we focused on tightening up the application for an important demo to the customer’s board of directors. The project is relatively new, and this was the first demo, so we wanted to make it as best as we could. We didn’t need to put a lot of work into it – the application was already in a good state – but we still invested a little time in tweaking the colors, logos, presentation, etc.

Later in the week we started working through a thorny user experience problem. I feel pretty good about user experience now that I’ve had a lot of experience with it on Atomic projects, but I must say that this particular problem is going to be quite difficult to solve! Without getting into details, the problem is this: sometimes the user wants to completely invest themselves into thinking as one role, while sometimes the user needs to back up a bit and evaluate across a dozen or more roles.

Thankfully the team is composed of people who want to collaborate and solve problems, as opposed to people who want to bunker into their own world and throw work over the wall. After some discussion and confusion, we got together and did some quick team sketching and paper prototyping exercises. This was good in that it brought out some new ways of thinking about the problem. And even for those of us who didn’t generate amazing sketches, the visualizations allowed us to understand how the others were thinking and then provide more insights and feedback.

Photo credit: Simon Collison

We did not reveal the best solution (is there one?), but the team is now well positioned to continually iterate over better and better solutions. Best wishes on your problem, Håkan and Patrik!

Meeting Citerus

Working on challenging problems is good, but the exchange isn’t only about work – it’s about also meeting new craftspeople and trading ideas. Citerus is a company full of craftsman and craftswomen, and I’m glad I got to meet most of them throughout the week.

Tuesday evening Karin, Citerus’s CEO, graciously hosted me for dinner at her beautiful home on Tranholmen. Then, after work on Wednesday, several of us met up for beers, where I got to meet Anton and Mikael. Beyond beers and dinner, we had an excellent conversation about Android testing; in particular, we discussed tactics for code design that avoid the need for PowerMock to mock Android SDK methods in unit tests.

But for me, the big event of the week was Friday’s Citerus Day. Most Citerus employees are working at a variety of customer sites, so about once a month they take the time to gather in either the Stockholm or Uppsala office. Thankfully my trip coincided with May’s Citerus Day in Uppsala and I got to meet most of the company.

Citerus Day begins with everyone taking a few to talk about how their project is going. This was an effective way to learn about what everyone is working on, what technologies they are using, identify opportunities for sharing, and, in my case, meet the people in the company. We then moved onto several short talks, including a presentation by Håkan and Patrik about their project. I also gave a talk, which I plan on presenting at Atomic next and then reformulating as a blog post.

After lunch we broke into a number of open spaces. Throughout the afternoon I participated in about three different conversations – continuations of thoughts that had come up in the morning status update, some technology demos, and other related topics. We concluded the day with some final remarks from Karin and myself about what I’d observed over the week.

The most striking thing I noticed over the course of the week, and especially during Citerus day, is how much Citerus’s and Atomic’s attitudes overlap with respect to Atomic’s four core values: give a shit, teach and learn, own it, and share the pain¹. In particular, when everyone was describing how their projects were going and how they felt about things, overall, it was evident that they all give a shit. They are not unhappy and demotivated butts-in-seats contractors. Citerus gives a shit.

Vacation

It’s not often (or until now, ever) that I’m in Sweden, so what better time to take a week vacation? It’s nice to finally visit Uppsala, the city I’ve heard so much about from Mary, Carl, Karlin, Mike, and Dave. I may be becoming addicted to trips like this, whether it’s visiting Bill in Ireland, picking up my new car with Carl in Germany, or participating in a craftsman exchange with a company in Sweden. I suppose the gentle encouragement to get out of North America is another unseen benefit of working with the great people at Atomic.

In conclusion, the first Citerus – Atomic Object craftsman exchange has been a great professional development opportunity for myself and Mattias. Outside of working on a project together, I can think of no better way for our two companies to build a strong relationship of mutual respect and learning. I hope further opportunities arise for us collaborate in the future.

I’d like to extend another huge thanks to Atomic and Citerus for providing this opportunity. And, Mattias, thank you so much for meeting me at the airport, helping me get around town, and connecting me with other helpful individuals. It made my two weeks in Sweden easy and enjoyable.

¹ I’ve found our four core values are best documented on our Detroit hiring microsite if you’d like to read more.

1. write high-level acceptance test
2. write unit test for a component
3. make unit test pass
4. go to 2 until acceptance test passes

This pattern has served me very well in the professional realm. However, when I sit down to play with personal game development project, gamebox, acceptance testing and BDD tend to go out the window.

I go into “let’s get a dragon in the game” mode. With two kids, a wife, and a home to maintain, my time is always fleeting. Naively optimizing for short-term results, I tend to write unit tests only for interesting code and rarely ever write acceptance tests.

As gamebox grew in complexity, I hit a point where a large refactor was required. I started using David Crosby’s conject gem. Conject takes over all of my dependency management and object construction, essentially touching every piece of the framework. I realized that in the current system, the only way I’d know that I had hooked up all the pieces correctly was to slowly update all the games that I had built using gamebox and see if they work. That approach sounded like a fail-train waiting to leave the station.

I finally sat down in the working system and wrote an acceptance test. The first test was the hardest. After writing a few helpers and moving things around I had a test that proved that a game object could be created, added, drawn, and receive keyboard input. The great thing about the testing harness that I had to write is that games built with gamebox can use them to acceptance test their games, as well. Double win!

  it 'creates an actor from within stage with the correct behaviors and updates' do
    game.stage do |stage|
      create_actor :mc_bane, x: 250, y: 400
    end
    see_actor_attrs :mc_bane, bullets: 50

    update 10
    see_image_not_drawn mc_bane_png

    draw
    see_image_drawn mc_bane_png

    see_actor_attrs :mc_bane, bullets: 40
    game.should have_actor(:mc_bane)

    release_key KbD

    # should have removed himself
    game.should_not have_actor(:mc_bane)

  end

Save yourself the headache. Start with the acceptance tests and drive from there. They improve your design and let you know when you’re done. I use them every day in the office, and now I play the home version, too. They can be real life savers.