2010: Hello, Operator

Joe Moore

Thursday, July 8, 2010

Interesting Things

The << operator in Rails has_many relationships acts strangely, such as silently failing validations when performing a save. Watch out!
RSpec has overloaded the =~ operator as an order-independent equality, so [1,2,3].should =~ [3,2,1] will succeed.
Tired to opening tab after tab in OSX Snow Leopard just to perform the same action? Label your tabs instead and reuse the same one for the same actions or tailing that one log: CMD+i => Info => Title => escape.
Progress on Cedar, our BDD framework for iPhone development, is rolling right along: read all about Cedar device specs and CI.
We noticed that the new RubyMine 2.5 ERP no longer gives us useful stack traces in Rspec; we reverted back to an earlier build. It has awesome features, though.

Cedar device specs and CI

Adam Milligan

Tuesday, July 6, 2010

One of the most common complaints I’ve read about OCUnit, the unit testing framework built into Xcode, is that the tests you write with it won’t run on the device. In addition, I personally have found the process of setting up a target for tests that depend on UIKit confusing and onerous. So, one of our goals for Cedar was to make testing UI elements easy (or easier), by making it easy to run specs in the simulator or on the device.

Probably the second most common complaint I’ve read about OCUnit is that the tests run as part of the build. This makes the test output difficult to separate from the build output, and makes it impossible to use the debugger when running tests. So, in addition to making it easy to run specs on the device, we wanted to be able to run them as a separate, debuggable executable.

Finally, we consider it important that our specs run in our CI system. That means we wanted to be able to run Cedar specs from the command line, and get an exit code signifying success or failure. At the same time, some of us appreciate the value of the green/red feedback for specs passing and failing, so sometimes we like a nice UI. As of today, Cedar will accommodate all of these various requirements.

If you have simple tests that don’t depend on iOS, you can simply link the Cedar dynamic framework into an OS X command line executable build target, write your specs, and run. Running from inside Xcode should give you output that looks something like this:
Xcode spec run pass

For specs that do depend on iOS frameworks, such as custom views or view controllers, you can link the Cedar static framework into an iOS executable, use the Cedar-specific application delegate (CedarAppDelegate), and you get something that looks like this:
Xcode UI spec run pass

The elements in the table represent the top-level specs that you have written. You can click on each one to drill into the state of each of its children, and its childrens’ children, etc.

Of course, those nice green bars aren’t terribly useful for the CI build, so if you’d prefer to skip the UI you can set the CEDAR_HEADLESS_SPECS environment variable, and then running the specs on the simulator (or device) reverts back to the dots:
Xcode headless UI spec run pass

Notice that we’ve created rake tasks for running the specs on the command line, for the sake of simplicity and ease of integration with CCRB. The Rakefile is available in the Cedar project, and does little more than set environment variables and execute bash shell commands. If you’d prefer to use your own bash script, or something similar, feel free to copy and paste your way to happiness.

I’ll spare you another screenshot, but you can see the results and build logs for the Cedar CI build here, and its current status is always displayed on our public CI Monitor page.

The last piece of the testing puzzle for iOS is full-stack integration and lifecycle testing (à la Selenium), which should be possible with Apple’s new UI Automation tool. Unfortunately, Apple hasn’t yet provided a way to run UI Automation tests, or get test results, from the command line. Hopefully we’ll find a way soon; their JavaScript DSL for iOS testing combined with Jasmine could be a potent combination.

Standup 07/06/2010

Joe Moore

Tuesday, July 6, 2010

Interesting Things

Here’s something funny… literally: our very own Will Read‘s sketch-comedy troupe, Reply All, will be performing at The Clubhouse this Friday, July 9. RSVP here to see the show.

UPDATE: now with less inaccurate info! GoGaRuCo dates were wrong. Stay tuned!

Github service hook for Pivotal Tracker

Dan Podsedly

Tuesday, July 6, 2010

With Github’s help, we’ve added Pivotal Tracker to the list of Github’s built in service hooks, making it easier to tie commits to Tracker stories.

To set it up, go to the Repository Administration section of your Githup repo, click on Service Hooks on the left, and choose PivotalTracker from the list. Enter your API token, and you should be good to go.

More on Tracker commit hooks on the API help page.

Pivotal Tracker Pro Tip: Parallel Tracks with Labels

Joe Moore

Sunday, July 4, 2010

A frequent feature request for Pivotal Tracker is support for parallel tracks of development for multiple pairs of developers (you are pair programming, right?) It’s true that Tracker does not fully support parallel tracks within the same Project, but you can get most of the way there by doing what we do on many Pivotal Labs projects: use labels to identify multiple tracks of development. With labels, you can easily visualize and manage parallel development tracks while keeping your team’s work in one Pivotal Tracker Project.

A Tale of Two Pairs

It is a common scenario to have two pairs working on two unrelated feature sets. For example, your application will allow users to shop for and purchase products, and also have many administrative/back-end features. The team has identified that there are too many dependencies to have both pairs working on the shopping portion: one pair can’t work on credit card refunds if the other is in the middle of implementing credit card purchases. Thus, the team decided that one pair will focus on the shopping features while other pair works on important admin tools.

Parallel Tracks

“If it’s the most important story, put it at the top of the backlog” has long been one of our go-to suggestions. This is more difficult with parallel-track teams, as you have multiple number-one priorities. Labels to the rescue! Notice that we’ve labeled all of the shopping-related stories with a shopping label, and the administrative stories with an admin label:

Now click on the shopping label. Notice that we grow a new Search Results column for stories labeled shopping which has several interesting properties:

The number of stories labeled shopping.
The number of points estimated for all shopping stories.
Their normal prioritized order.
Just like normal Tracker columns, the stories update if team members edit them.

Pin It!

After clicking the shopping label, pin it by clicking the little push-pin icon in the upper-right corner of the search results column. Now you can perform another search, or click another label, without losing your shopping column!

Go ahead and click the admin label after pinning the shopping label.

Now you have easy to visualize tracks of stories, priorities, and estimations, side-by-side.

Limitations

The label trick is a very handy tool for managing parallel tracks of development on your project, but it isn’t perfect. Ideally, if the shopping features are the most important for your project, everyone possible should be working on them. Implications of parallel development tracks in Pivotal Tracker include:

Harder iteration planning: Tracker fills your iterations with the highest priority stories, but with parallel tracks you have multiple high priorities. In our example, Tracker fills the top of your backlog with shopping stories first and admin stories afterwards. The burden is on the team to either interweave the two tracks in each iteration, or group all of the similar stories together and “just know” that your admin stories are not actually weeks away but are indeed being worked on now.
Predictability: Depending on how you use Release markers, some charts, such as the Release burn-down chart, become less useful. For example, some teams might create Release markers for shopping and admin as a way of grouping these stories together, but the burn-downs will be less accurate if teams are working on both sets of stories.
Slightly harder to manage: One thing you’re sure to notice is that you cannot drag-and-drop within the search results panels, which means that you cannot re-prioritized the stories within the shopping and admin columns, though you can drag items from search results into the backlog. Also, if you add or remove labels, or re-prioritize, you will have to perform the search again refresh the column.
Anti-pattern?: Some schools of thought, such as followers of kanban, might consider parallel tracks of development an Anti-pattern. Definitely weight the impact of fracturing your development efforts.

UPDATE: fixed wonky images.

Objective-C exceptions thrown inside methods invoked via NSInvocation are uncatchable

Adam Milligan

Thursday, July 1, 2010

Whether you’re using Cedar or not, if you’ve upgraded to the iOS 4.0 SDK you may have run into some odd behavior with exception handling blocks not catching exceptions. Strangely, the problem isn’t due to the exceptions themselves (at least not in any obvious way), but with how you call functions that raise exceptions. An exception thrown from within a method you invoke directly will function as expected. However, if you invoke that same function indirectly using NSInvocation any exception thrown becomes uncatchable, crashing the current process regardless of any exception handling code.

This happens only when running against the currently available iOS 4.0 SDK. Exception handling for both direct and indirect invocations performs as expected when using the OS X 10.6 SDK and previous versions of the iPhone SDK.

You can reproduce this problem yourself easily enough. Just create any old iPhone project, and add the following code in a method you know will run (e.g. viewDidLoad on the main controller):

@try {
    NSException *exception = [NSException exceptionWithName:@"foo" reason:@"bar" userInfo:nil];
    [exception raise];
} @catch (NSException *x) {
    NSLog(@"========================> %@", x);
}

Works, right? Now try this (which should be functionally identical):

@try {
    NSException *exception = [NSException exceptionWithName:@"foo" reason:@"bar" userInfo:nil];

    SEL selector = @selector(raise);
    NSMethodSignature *signature = [exception methodSignatureForSelector:selector];
    NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:signature];

    [invocation setTarget:exception];
    [invocation setSelector:selector];
    [invocation invoke];
} @catch (NSException *x) {
    NSLog(@"========================> %@", x);
}

BOOM! Stack trace. Sad face.

Unfortunately, the OCHamcrest matcher library uses indirect method invocations to raise matcher failure exceptions. So, with iOS 4.0 rather than getting failure messages in your test output, you now get a stack trace and potentially a bunch of un-run tests.

Hopefully Apple will fix this soon.

Pair Benefit #458: Choice

Will Read

Thursday, July 1, 2010

Though I am certain someone could do it, it is hard to dispute the connection between having choices and control over your daily work and overall job satisfaction. The people with more power to govern themselves will typically report that they are more satisfied with their jobs. This is why pairing can play a huge part both with picking who you work with and what you work on.

The difference between a 1 pair project and a 2 pair project is 3 choices vs. no choices in who you work with. You can like everyone on your team and be pleased with their work, but you can only sit side-by-side with one guy for so long. When you go up to two pairs, you suddenly have a choice that wasn’t there before, and it is there in a big way. Tired of Joe? No problem, you and Rachel haven’t paired in a while, so make that happen.

The reason people don’t need “pet projects” is because we get to pick who works on what at the top of the backlog. Yes, I have to do some grunty work, but I also get to side-step some things that I’d rather not do. More importantly, you pick what it is you work on. So now you’re doing something you chose, vs. something that was assigned to you. You as an individual have a personal investment in seeing that task through.

The work place can be filled with all kinds of challenges, and can seem oppressive if you can’t exact any control over it. By pairing and having an option to rotate, you get to pick your work and pick your coworker every single day. And choice is a great way to stay happy at work.

Standup 7/1/10 – Caching Apache images that have ?123456789

David Goudreau

Thursday, July 1, 2010

Help

Does anyone know how to set a caching header for urls that end with a cachebusting string (e.g. ?123456789)? Apparently you’re not allowed to get the query string when mucking with rewrite rules. A couple of people think that you are able to get your hands on it…somehow.
How do you do a screen capture from the Mac command line? We want to do a screen capture of a running emulator. Maybe something like this?

Interesting Things

Rails 2.3.8 – for nested attributes, ‘_destroy’ is the new ‘_delete’. Looks like the Rails team is on top of it. Use

@foo.update_attributes(:foo_attributes => {'0' => {:id => '1',  '_destroy' => '1'}})

instead of

@foo.update_attributes(:foo_attributes => {'0' => {:id => '1',  '_delete' => '1'}})