But since the source is open and available from gitHub.com I simply pulled a version down and tried to debug the code.
And before long I found the solution. SpecFlow (now 2010-12-16) uses .NET framework 3.5, but my specifications were written using .NET 4.0. There are some reflection going on inside the step definition report code and that doesn’t work very well (loading assemblies from different framework versions).
OK – I simply change the .NET framework to 4.0 and compiled myself a local version and tried the command against that version. And ... it worked!

If, like me, you are using SpecFlow to do .Net-style BDD under .Net 4 Framework, you might have been scratching your head about why the Step Definition Report doesn't work.

Well, Marcus Hammarburg took the time to actually pull the source code and figure it out.

Thanks, Marcus!

A lightweight, modular JavaScript game engine to easily produce high quality games.

Includes a large variety of components such as animation, event management, redraw regions, collision detection, sprites and more.

//setup the Crafty game with an FPS of 50 and stage width
//and height
Crafty.init(50, 580, 225);

//create a player entity with premade components
var player = Crafty.e("2D, DOM, gravity, controls, twoway, image")
        .attr({x: Crafty.viewport.width / 2, w: 16, h: 16})
        .gravity("floor")
        .twoway(2)
        .image("favicon.png", "no-repeat");

//create an invisible floor entity
var floor = Crafty.e("2D, floor")
        .attr({x:0, y: 225, w: 580, h: 5});

Run Code

One to watch in 2011 if you're into Javascript game development. A great architecture has been designed, now just depth is needed. But I love the jQuery-like approach to components and extensions.

Hiring: We're looking for another web-app interface designer Jason F. Dec 06

13 comments Latest by Levi Figueira

We’re looking for another excellent web-app UI designer to join our team.

Besides having great visual taste and talent, you must code well-structured HTML/CSS. Basic Javascript or Rails skills are a plus, but not required. Great writing skills are required.

UI designers at 37signals are always working on different things. You may be working on polishing up an existing feature in Basecamp or designing the UI for a brand new feature in Highrise. You may be revamping Backpack or fundamentally rethinking some UI in Campfire. Or maybe you’re involved in designing a brand new product (we’d like to explore two in 2011). You may be asked to come up with something no one has ever seen before.

At 37signals you’ll be working on products that people rely on to get their job done. Your work will impact millions of interactions. You’ll be working with some of the best designers, programmers, dev ops folks, and customer support people in the industry. Our team is top notch and we want you to make it even better.

Our projects are always focused on solving real problems. When the problem goes away we know the design is right. Your job, as a designer at 37signals, is to make our customers’ problems go away.

At 37signals, designers lead the teams. Each development team is made of up three people – two programmers and one designer. The designer also manages the project. In addition to designing the screens/elements, you’ll keep the team focused and make calls about what’s important. You’ll be the go-to person on the project.

We’re not looking for a certain design style, we’re looking for a certain design approach. Simplicity isn’t enough – clarity is where it’s at. You think about how people interpret the objects on the screen. What they think about, what moves them, what frustrates them, what makes them happy. You know that the right design decision can make all the difference.

You’re excited to discover a better solution, even well into a project. You don’t mind throwing something out in favor of a better idea or implementation. Projects at 37signals start with real code. Feedback from an evolving prototype guides the team. While we’re very pragmatic about code, it is important that your design/code is easy to change in response to feedback.

Lastly, you understand that copywriting is design. The words matter as much as the pixels. Great visuals with weak words are poor designs. You should care about how things are phrased as much as you care about how they look.

CHICAGO PREFERRED: Since two of our dedicated UI designers are outside of Chicago, we’d prefer if you were in Chicago to balance things out. If you think you’re perfect for the job, and not in Chicago, we still want to hear from you. We want the best we can find. If you’re the right fit, we’re open to relocation as well. We have an open desk for you in our new office.

How to apply

Send relevant work samples, and anything else that will make you stand out, to jointheteam@37signals.com. Include [UI DESIGN] in the subject of the email.

It doesn’t matter where you went to school, or if you even graduated. It doesn’t matter if this is your first job or your fifth. Doing great work and being driven to improve yourself and everything you touch is what matters.

If we think you may be a good fit we’ll be back in touch with step two of the application process.

Application deadline

We’ll be accepting applications for this position until December 20, 2010.

We look forward to receiving yours.

Everyone should write job posts like this. Who wouldn't want to work for 37signals after reading this?

Job posts shouldn't be bullet lists. They should be love letters.

I read about the Ultimate Clean Up Day at TargetProcess. For those living under a different rock than I do, they make some great agile project management software (http://www.targetprocess.com/).

In the article (which you should read), MIchael Dubakov reports that their Planned queue sometimes has 20-50 items in it. So they had an all-hands "clean up" day, moving a whole bunch of items from Planned the whole way across their Kanban board.

Sounds great, sounds fun, and I think as an infrequent fun team-building exercise, it is probably a good thing to do. Imagine the team "opening the floodgates" on the backlog, cherry picking some easy, fun things to take to completion in a day!

But - I think there is a bigger opportunity here, and that's to right-size the Planned queue limit.

20 items in planned is way too many if, as Michael reports, that many stories are stuck in Planned for weeks at a time. *tsk tsk* Michael - you make software that lets you set a queue limit, so please use it!

I would add up the queue limits on queues between Planned and Done. For instance, In Dev + Ready For Test + Tested = 5.

Then, set a matching queue limit on the Planned queue, then watch how stories flow across the rest of the board.

Unblock anything that jams up the flow. If any story sits in the same queue for more than 1 work day, that is a "jam" even if other stories are flowing through the queue around it. I would do a quick analysis and either un-jam that story, or reject it back into the backlog for additional product management care.

TargetProcess supports all of this and more. If you are doing Scrum, XP, or Lean, or some combination of them, TargetProcess should be on your review list.

One question though - I wonder what is in all of those trash bags? :|

Only increase the limit if