Troubles upgrading to Leopard?

I had few troubles upgrading to Leopard.
Basically the Mac didn’t start anymore(*).
The problem was on the hard disk nodes, so I reckon a disk check before trying to upgrade. If there are problems, the Mac disk utility will not help you, better to try with DiskWarrior.

If you’re reading this post because it’s too late and you’re in troubles, I fixed the system installing Leopard to my firewire disk, installed there DiskWarrior and fixed the disk from there. (credits to Luca for the pragmatic solution).

(*) I was sweating blood since the Lacie Backup utility “forgot” to backup all my iTunes library! :’-( Now I feel much safer with the time machine, great app.

What is a mature team?

On the italian XP mailing list, Tommaso Torti asked an interesting question to the list few days ago.

When do you define a team ‘mature’?

Translating myself, my reply was something like:

A mature team is a team that implements at its best the theories written on books, that makes concrete what’s on paper in value for the client.
It’s cohesion and communication.
A team that’s mature is a team that hasn’t nothing to do anymore, it’s mature, can still improve?
In my very personal opinion it’s a death team, the mission is achieved, it’s time to change, it’s time to shuffle the cards. Roll in new people, change.

Some other interesting replies to the question:

PierG wrote:

A mature team is a team robust to change, wich means that it’s able to change without crumbling the process.

Francesco, being a strong XPer wrote:

A mature team is a team that doesn’t need a manager, a project leader, an architect or a designer in order to produce results. It’s able in an autonomous way to increase its own productivity.

Luca Minuduel quotes from the website of Joseph Pelrine:

* Flexible and responsive to changing organisational conditions and wider environments.
* Able to work with pressure, uncertainty and disagreement.
* Able to be self-organising and self-regulating.
* Maximise the strengths and creativity of each team member.
* Satisfies both organisational and individual needs

and Marco:

A system in equilibrium naturally tends to resist to change and that’s why we need to apply a force (questions/retrospectives/etc for people, splitting for stories, refactoring for code), because we need to take the system at the edge of chaos to facilitate the emergence of a new, spontaneous configuration.

Definitely a nice conversation, and for you what’s a mature team?

On the anti-if campaign, the double dispatch service locator example

I had a good number of jokes and questions since the announcement of the anti-if campaign.

Do you want to remove all these if? What’s wrong with the ifs?

So, it’s better to clarify something.

First of all it’s not about removing every single if, it’s about having a more flexible, maintainable and readable code.

A long case (or if then else) statement can be difficult to read and follow, maintenance can be painful.

The first category of if to get of rid of, the most immediate it’s the type based if.

There is clear: something is wrong, the responsibility is not where the if is but in the class itself.

So, an example.

On a project (in a Domain Driven Architecture) we had a fairly long “if type then, else if type then, etc…”

The if chain was on different Tasks Types in a workflow engine.

Let’s imagine that the workflow is an engine for a touch-less car wash system.

So you have, for example:

InsertCoinTask
2-StepHeatedPreSoakTask
HighPressureTouchFreeWashTask
Tire&WheelCleanerTask
HighPressureRinseTask and so on.

Every task depends on the completion of a previous one and might need a run time configuration.

So, the code was something like this:

if (task is InsertCoinTask)

{ Configure(task as InsertCoinTask) }

else if (task is StepHeatedPreSoakTask) {

Configure(task as StepHeatedPreSoakTask) }
...
Inside of a class called TaskServiceConfigurator, were for example a Configure method was implemented like:

private Configure(Tire&WheelCleanerTask task)
{
task.TirePosition = touchFreeWashTask.LastCarPosition;
}
The different configure methods inside that class (then private!) were setting previous tasks settings, values and so on.

So, pain points:

- The long if: you can easily forget to configure when adding your task to the workflow to add it there

- Private configuration methods: difficult to test, not only the configuration but also when testing the task itself

- Public setters on the tasks: since each task is configured inside the TaskServiceConfigurator all the setting came from there

Solution to this has been a double dispatch.

We added on the Task Interface a method Configure with the ITaskServiceConfigurator as a parameter, like this:

ITask
{
Configure(ITaskServiceConfigurator configurator)
}

Tire&WheelCleanerTask is an ITask and the Configure implementation might look like:

Configure(ITaskServiceConfigurator configurator)
{
tirePosition = configurator.LastCarPosition;
...
}

The above example probably is too stupid, but the key point is that the LastCarPosition depends on other task (performed or not) it’s really a run-time configuration, a real time dependency between tasks.

I found easier to test the tasks, passing a stubbed configuration and the configuration itself had a definitely better code coverage.

Any better solution to this code redesign is more than welcome.

(Task names are taken from this page: http://www.autec-carwash.com/ )

How do you build your projects?

Recently we migrated all our build scripts from a combination of bat files + msbuild to a couple of NAnt build files.

There are some reasons for this and some nice outcomes.

Reasons

First of all we wanted to have the same build scripts for Development, CI, QA, UAT and production Environment.

On the Dev machines we need to build, test and install few services (ms services, a web service and a web app).
On Cruise same as above but no installation of the services and, indeed some publishing of the artifacts.
The QA environment is as close as possible as the UAT/Production: it just needs installation scripts and a way to get the latest artifacts published by Cruise.
Using the same script gave us a great confidence when going to production: scripts were used every day by the QA, no surprises when going live.
We got completely rid of all the .bat files for 2 main reasons: they become messy after 1 year of patches/fixes/modifications and we can’t really achieve the goal of one script for all as we wanted.

After a short investigation on alternatives to bat+msbuild (boobs and rake) we went for nant.
We found boobs quite difficult to use and install (you need to build some libraries, install boo, etc…), in other words it does not came for free. Rake is a cool solution, we didn’t choose that cos 1) we were too lazy to install ruby everywhere (in production especially could be a problem) 2) our build, even if includes a client app, four services, a web app and a web services is fairly simple.

Nant is really a good translation from the Java Ant. It’s actually more than a one to one translation, it has more features and it’s somehow more powerful.

I really liked the functions for example. And the contrib project is plenty of nice, useful tasks ready to use.

Another important improvement on the build scripts was on the database scripts.
Again, migrated from few bat files to one script for all the needed tasks.
We had a lot of satisfaction using dbdeploy.net, it really speeds up the work, especially in the QA environment migrating the DB schema to the latest version keeping the data in.

Outcomes

Life easier for everybody: instead of calling a bat files with some parameters we had a file of properties (not a lot of properties, convention over configuration!) for each environment, it’s now harder to fail an installation. It’s also more clear of what’s going on thanks to the nant output log.

Maintenance it’s easier. There are only two files that you need to know. Tasks are pretty short and responsibilities isolated.
We kept also a low lever of dependencies avoiding imports and more than two level of dependency.

Sometimes rewriting everything from scratch is much easier than refactoring / patching.
It has been also interesting to write a build file after one year of development, usually it’s one of the first things you do in your project.

My suggestion is: if your build script causes problems, waste of time or if it just smells and it’s not clear what’s doing, try to spike out a different solution, the benefit could be enormous.