Agile 2009 - Developer Jam

Mission Impossible: TDD and JavaScript

jsuchy — Wed, 04 Mar 2009 04:00:25 +0000

JavaScript has earned a special, dark place in most programmer’s hearts as it is a necessary evil for making the web experience dynamic. You are test-driving your JavaScript, aren’t you? If not, why not? If the reason is that you don’t know how, or haven’t taken the time to learn the various testing frameworks, then this session is for you. We will briefly explore the various testing frameworks, build our own lightweight framework, and then test-drive a small bit of functionality using it.

Ruby Kata and Sparring

slagyr — Tue, 03 Mar 2009 14:32:50 +0000

All respectable software craftsmen make efforts to keep their coding claws sharp. And solely working 9-5 on business applications will dull one’s whit. In this session we will broaden your coding horizons with some Ruby Kata and test your skills will some Ruby Sparring.

Test Driven Development on the iPhone

paytonrules — Sun, 01 Mar 2009 17:26:54 +0000

Currently, the iPhone is the hottest platform for mobile development, with everyone wanting to develop on it. Test Driven Development is a proven technique for developing high-quality software, but isn’t encouraged by the iPhone development platform. Open Source developers have stepped in, creating Unit Test Libraries for the iPhone. We’ll show you how to get started, run your first tests, put tests in your build, and touch on advanced techniques like mock objects and dependency injection. Perfect for the Agile Developer looking to get started on iPhone.

System Metaphor Revisited

Joshua Kerievsky — Fri, 27 Feb 2009 00:35:13 +0000

System Metaphor was and is an elusive practice of the original XP. It has largely been forgotten over time.

Yet in the past few years, my colleagues and I have discovered the stunning power of a genuine System Metaphor on our own shipping product. This makes us wonder why System Metaphor ever went out of vogue.

This session will explore why Metaphor matters. We’ll examine how our own Music Metaphor reshaped our flagship product, even our company, and how the right metaphor can supply the driving beat that can turn your product into a hit.

Clean Code Clinic: Refactoring Fest

naresh — Thu, 26 Feb 2009 04:56:49 +0000

Intent

Provide the participants with a hands-on-experience of real world refactoring by taking an open source project and refactoring it.

Summary

Refactoring is a very well established practice not just in the Agile Community, but outside as well.

This session is an attempt to help the development community understand refactoring a little better. It will provide a hands-on opportunity for developers to explore these concepts in action. This session will try to amplify the participant’s learning process by pairing them with other practitioners and peers.

Styles of TDD: First Tests

naresh — Thu, 26 Feb 2009 04:48:52 +0000

It’s easy to speak of test-driven development as if it were a single method, but there are several ways to approach it. In our experience, different approaches lead to quite different solutions.

In this workshop, we’re not trying to decide which approach is best. Rather, we’ll use concrete examples to explore

What goes into the moment of decision when a test is written?
How do you think about the problem you’re trying to solve?
What strategies or techniques help you write the first few tests?

This workshop is targeted at TDD/BDD Practitioners.

We Didn't Quite Get It

BrianHV — Mon, 23 Feb 2009 18:51:47 +0000

What do you get when two developers try to implement agile without having experienced it? A 90 minute session on all the mistakes that were made.

What can you do to avoid the same fate? We needed an agile coach, but want to help you do without. We’ll present techniques you can use immediately.

In this session, we examine the problems created by implementing an agile process incompletely and describe solutions to those problems. We offer the perspective of developers who learned what commitment really means and that there’s more to agile than TDD and small releases.

Build Engineer Bootcamp: Builds As Code

PaulJulius — Sat, 21 Feb 2009 23:07:55 +0000

Bad build practices take a hidden toll on teams. It is not uncommon for a new developer to take days or even weeks to establish a functioning workspace. Good build engineers can make all the difference. By treating the build framework with the same respect as other source code they can help prevent these problems. In this clinic we will show how to refactor your build approach to end up with sustainable practices that get new people up and running quickly and set the stage for long term productivity. While the workshops are in Ant, the concepts are portable.

Treating Errorhandling as a First Class Consideration in Design

michaelfeathers — Thu, 19 Feb 2009 16:59:03 +0000

It is unfortunate, but true: for many teams error handling is an afterthought. They design the main flows of their system and then they think about where they need exceptions and logging. However, the error cases are extremely important. When we consider them along with the normal cases, we an often find ways to arrive at better design. In this workshop, we will pursue design a series of solutions to the same problem with the error cases considered early and late. Then we will compare and contrast solutions and see how early consideration of cases can affect the growth of a design.

Exploring Synergistic Impact Through Adventures In Group Pairing

lokean — Mon, 16 Feb 2009 20:10:22 +0000

As Agile practitioners, a great deal of our time is focused on having targeted, directed impact. But sometimes we miss opportunities to repurpose our efforts into syngergistic, many-pronged effects. Not multi-tasking — multi-EFFECTing, from one piece of effort. This talk will explore this topic, both in theory and in practice. We will examine a particular client case-study, where two disparate 6-person developer teams, with minimal pairing and TDD experience, were developed into highly-productive “gelled” teams, through “Group Pair Programming” — 6 individuals, 1 workstation.