This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you. By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

When picking iteration length for an agile project, there are mainly two forces that you have to balance: The rate of learning is proportional with the number of iterations, rather than the length of the project. This means that shorter iterations help you get better faster. But each iteration has some overhead with sprint reviews, retrospectives and planning. You don’t want this overhead to dominate the effort spent on the project.

If you wonder why this blog has been so quiet lately, it not (just) that I’m getting lazier. Together with several of my colleagues at Steria Norway, I’ve started up a blog at http://sterkblanding.no. “Sterk blanding” is Norwegian for “potent mix”, and we hope that as representatives for several disciplines, we will be able to give a broad perspective on IT and management issues. I’ve not yet decided what posts to publish here and what posts to publish on Sterk Blanding.

I’ve pair programmed the Java EE spike kata in Eclipse with a number of people, I’ve found that a number of keyboard short cuts and preference settings recur as useful new information. I’ve compiled the most popular ones in this article. The article is subject to change, but I won’t change the number of shortcuts. Top five shortcuts There are some keyboard short cuts that everyone who uses Eclipse should know:

As it turns out, one of the least used practices of agile development is also one of the most powerful. Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I’ve experienced real pair programming, I never want to give it up. Pair programming offers benefits to many stakeholders:

After seeing some of the great examples of coders working on practiced problems on KataCasts, I decided to try make my own. I am not happy with the pacing of the video. I’m about a minute too early relative to the music. But I thought I’d post the video here, to see what you all think. Comments are welcome! I hope the video will demonstrate how to use refactoring effectively to drive the design of a program.

Lately, I’ve been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I’ve chosen are: Java EE Spike: An application that stores People with names to a database and lets me search for them. I’ve repeated this pair programming with several different programmers. Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,… you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with “coconut”.

For å bli bedre må man trene. For å bli bedre med avanserte ting, må man forstå de grunnleggende tingene bra. For å vite hvorfor man bruker avanserte verktøy, må man prøve å jobbe uten dem. Derfor har jeg de siste ukene trent mange ganger på å lage en veldig enkel webapplikasjon i Java. For hele applikasjonen har jeg startet med å skrive testene før koden som implementerer funksjonaliteten. Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang.

En kollega spurte i dag om mine topp tips når det gjelder databaserefactorings. Her var mitt svar: Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite) Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren.

Lately I’ve been thinking a lot about how easy it is to lose sight of the goal of the project and instead focus on whatever means someone first thought was a good starting point when the project was first conceived of. And I think it all comes down to words. The first years I was working in this business, I didn’t see any distinction between “the user” and “the customer”. Once I started seeing the distinction, I started to understand that the person who is going to use the system we’re developing is not the person who defines what the system should do and neither of these is usually the person that pays me to develop the system.