Tuesday, May 19, 2009

Ajax and Web 2.0 Programming (with Passion!) Certificate

Another addition to my collection... Mr Sang Shin has just published the Certificates for the Ajax and Web 2.0 Programming (with Passion!) free online course, and mine is one of them.

Now I have a problem, as I'm running out of Sang's courses to follow... By the way, as always, I really want to thank him again for the great work he does for all of us.

Passion!

Wednesday, May 13, 2009

Become fluent with fluent interfaces

It's been a while since I first read about fluent interfaces, and of course it's been a while I've been using them too, like every test infected guy.

Yesterday I finally decided to give them a try and implement one for a Builder: implementing a fluent interface is embarassingly easy, as basically all you have to do is create setters that return the builder itself and a method that returns the object you're creating.

To give the simplest example that comes to my mind, if you wanted to create an order you could write someting like
OrderBuilder.createOrder()
.forCustomer(customer)
.with(STEAK, 1)
.with(FRIES, 1)
.with(BEER, 3)
.build();
The builder actual code might look something like this:
public class OrderBuilder {

private final Order order;

private OrderBuilder() {
this.order = new Order();
}

public static OrderBuilder createOrder() {
return new OrderBuilder();
}

public OrderBuilder forCustomer(Customer customer) {
order.setCustomer(customer);
return this;
}

// ...similar setters ...

public Order build() {
// ...maybe perform some validation
return order;
}
}
After playing with my code for a while I discovered that implementing a good fluent interface is not as easy as it might seem at first: you have to carefully think about what you really want to do (program by intention), how to clearly express it, and have your APIs reflect it. Nevertheless I think I'll experiment with them a little, they could be another nice trick in my toolbox.

Friday, May 8, 2009

Scrum for non software projects

I have written several times that I normally use Scrum for the manteinance works my house requires, never going down to the nuts and bolts of it. Starting from a discussion initiated from Terry, I finally decided to jot down something.

Sprints are necessarily timeboxed, as every iteration can only be run during weekends. My wife is the Product Owner, and I play the double role of Scrum Master and Team Member (or just team, as I'm practically the only one that gets his hands dirty...).

We have a ever growing product backlog that we (or should I say she) prioritize, extracting the sprint backlog - which is the stuff we plan to do for the weekend at hand. The product backlog includes things like installing the watering system for the garden, hanging pictures and mirrors, cleaning the garage, and so on and so forth.

During the week I, as a SM, try to remove the impediments, e.g. we know we will be needing a wheelbarrow so I have to borrow one. On Saturday and Sunday morning we have the standup meeting (actually it is a sitting meeting, as it happens at breakfast). Then, while she keeps an eye on the kids, I switch role and start working.

Then, tipically on Monday evening, we hold a retrospective.

It works great. And if you think that Scrum is not appropriate because the domain does not implies uncertainity and frequent changes, well, you're wrong as it really does!